|
... sorry, being human, meant to say 'is to embed artificial intelligence' ...
|
|
|
|
|
Sould note that when Programming (talking to) humans is much education between Chemists and physicists. Agree we need a pretty good AI to take over the details of creating a program and avoiding the failures of precision (as in missing commas etc.)but the AI needs to be able to learn how we think. And we write math using integer to real and back quite often and only occasionally blow the wad. Think about translating the gibs free energy - from chemistry - to the conservation of energy as in all else. Confuse those two and the barn goes up in a hot one. One damn smart computer to follow us into our thousands of specialties.
|
|
|
|
|
So I had a lot of practice spotting poorly placed operators. I would much rather spend one day every other year looking for a misplaced semi-colon than spend the time adding verbosity. Plus, in my opinion, the ability to see on screen without scrolling the maximum amount of logic is paramount in writing good systems. The eyes move orders of magnitude faster than scrolling. I have seen some beautifully written, well documented code that was nearly impossible to trouble shoot for all the novel in the code.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Plus, in my opinion, the ability to see on screen without scrolling the maximum amount of logic is paramount in writing good systems. The eyes move orders of magnitude faster than scrolling. I have seen some beautifully written, well documented code that was nearly impossible to trouble shoot for all the novel in the code.
I have seen all too much code that took most the screen to display a simple concept. E.g.,
if ( a = b )
{
c = d;
}
else
{
if ( p == q )
q = r;
};
This coder use spacing to up his LOC/day count. Comprehension....well...that leaves a lot to be desired.
And I agree about beautifully written code. I saw a 1000 character program written in one line with no white space. Couldn't begin to understand what it was doing.
Ennis Ray Lynch, Jr. wrote: So I had a lot of practice spotting poorly placed operators. I would much rather spend one day every other year looking for a misplaced semi-colon than spend the time adding verbosity.
If there is time, and no pressure, a misplaced semi-colon isn't a problem. But, add pressure, such as commodities trading, and you have 2 minutes to find and fix the bug, well....pass the Maalox please.
|
|
|
|
|
This is a major rant I have about default (e.g. StyleCop) formatting conventions. They waste so much space that you can't actually see what the code does.
|
|
|
|
|
|
Wow, at >8000$ for a smartphone resolution screen? Seriously? 
|
|
|
|
|
rjmoses wrote: trace their origins back to the days when terseness was a desirable quality.
It still is. A decent C# class uses less characters to convey the same info as written in Object Pascal. Less characters to convey the same info - do you really need a "begin" and an "end" block?
rjmoses wrote: Be clear and obvious in describing the functionality of the module.
When is something obvious? If you've ever hunted a swallowed exception in VB6, you'll know that this is not possible. Code should be unambigious, simple and clean. It should not become an exercise to omit documentation.
rjmoses wrote: 2) The language should be portable.
It's not the language that decides on what platforms it will be implemented. VB6 will never appear on Linux without starting a major war.
rjmoses wrote: 3) The code should be almost self-documenting.
Only if you're not coding, but scripting. That means that we'd limit this "programmer" to an IDE like MS Access. You'd never get InterOp or call the WinAPI. You'd never get a pointer.
rjmoses wrote: 5) The language should incorporate most commonly-used functionality.
I've yet to meet the (broadly used) language that doesn't. Type-safety is something valuable - suggesting to remove it would be a step back.
rjmoses wrote: 6) And, finally, it should be easily extensible.
A language? Please not; how would your old code react to changes? Can you oversee whether or not your change "breaks" something?
Sorry, but only MS Access has these properties. I don't see it being used in the same way we use programming languages.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I just did my 29th update to Firefox the other day. It took me about 3 hours to get it back to where it was. Windows 7 keeps bugging about "New updates are ready to install". And Adobe Acrobat keeps crashing....
My point is: How can the programming process be improved? Such that we don't have 29 versions of FF? Or weekly updates ready to be installed. Or "Should a crash report be sent..."?
|
|
|
|
|
rjmoses wrote: How can the programming process be improved?
First you identify whether you're attacking the right thing; it's not due to the language that Acrobat behaves the way it does.
rjmoses wrote: How can the programming process be improved?
Seriously?
- Start educating people. No, don't send them to an expensive 5-day course where they learn to parrot the most used words, but educate them.
- Kick marketing and sales out of the IT-room.
- Drop
agile ad hoc methods.
- Force the boss to use the product on a daily base just as an end-user would use it.
- Care about your product.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote:
rjmoses wrote: 2) The language should be portable.
It's not the language that decides on what platforms it will be
implemented. VB6 will never appear on Linux without starting a major
war.
Every language* is portable, but not every language gets ported everywhere.
* With the possible exception of the various assembly languages, but I suspect that even they could be compiled for a system they weren't intended for, perhaps with some limitations, but I'm no expert on that.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Portable assembler is known as plain C.
|
|
|
|
|
Eddy Vluggen wrote: A decent C# class uses less characters to convey the same info as written in Object Pascal. Less characters to convey the same info - do you really need a "begin" and an "end" block?
If you are looking for terseness, go APL.
On a more moderate scale: What is really the purpose of those parentheses around if conditions, while conditions and for loop specification? Pascal can make due without them. Why do you have to double up the equals sign? Pascal can make due without that. Why do you have to double up all logical operators? The answer: Because the language "designers" didn't have a clue about language design.
Why do you have this ugly try-catch mess? In Chill, any statement may include an exception handler before its closing semicolon; it doesn't have to be pre-announced. The presence of an ON clause implies exception handling; you don't need to pre-announce it.
Why do you have to explicitly declare that "this is the end of the handling of this alternative", when the specification of the next alternative follows immediately? In Pascal you don't.
Why do you have to enclose exception handling in braces? The braces must , unconditionally, be there, but Chill makes due without them. A general rule in Pascal and its derivatives is that {...} is a block, and a simple statement is a block, so wherever a block is called for, a simple statement can be used.
Why to you have to include the body of a switch statement in braces, creating two nesting levels (the second one is each of the alternatives) when there logically is only one?
etc. etc.
Terseness is to remove from the language selected keywords and markers on your private hate list. The keywords/markers on someone else's hate list that is not on yours, you might fiercely defend as a way to improve readability, provide redundance to catch errors etc etc. Very few people really sat down to "tersify" a language specification, removing ALL unneccessary blurb; they use terseness as an argument to defend their own hate list.
|
|
|
|
|
Let's see.. there must be a relevant XKDC... oh, yeah, this'll do: http://xkcd.com/927/[^] 
Such language should not be English-centric like most of today's languages; rather each developer should be able to view and edit the code in his own chosen language. (And formatted as the individual likes as well.)
In fact, I think a new language should be XML-based with the IDE applying styling and such as specified by the user.
Of course, I would never use such a language, I'd stick with good old C#.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Algol-67 was defined in terms of abstract syntax elements that could be represented using any suitable set of concrete symbols. I never saw much Algol-67 source code, but most of what I have seen used German keywords.
(Algol-67 never caugth on - it was way ahead of its time. Even today, 47 years later, it would definitely be descibed as a very advanced language. I haven't looked at the specification for a while, but I am sure that some of its useful features are still missing from today's languages.)
Maybe it was Algol-67 that inspired us when we as students made a Norwegian version of Pascal. It really was a simple word replacement program replacing MEDAN with WITH, BYRJ with BEGIN and STOGG with END (those who know Norwegian will see that we chose the dialect-based Norwegian variant), writing it to a temporary file and invoking the standard compiler on that temporary one. It worked perfectly as long as you in you user defined symbols stayed away from both the Norwegian and English reserved words.
|
|
|
|
|
Sounds like you really just want a compiler to be more helpful with errors. Tools like Resharper help with this in Visual Studio!
Hogan
|
|
|
|
|
(Not everyone uses Visual Studio.)
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
If it was easy, everybody could it it!
But on a more serious note, not using Visual Studio is a choice... For the hourly costs of developers (at least in the US), its worth the money to equip people with the best tools to accomplish work.
And before going off on costs, there are free versions of VS.
Hogan
|
|
|
|
|
snorkie wrote: not using Visual Studio is a choice
Exactly.
snorkie wrote: the best tools
What's that got to do with Visual Studio? 
Seriously, I use Visual Studio when I need to, but not when I don't. I have Ultimate at work and Express at home.
Use the right tool for the right job.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
snorkie wrote: If it was easy, everybody could it it!
Did Resharper help you fix that sentence? No? Then why didn't you use VS to write your posting? 
On a more serious note:
1. VisualAssist beats Resharper and (Un)Intellisense on C++ coding (at least unmanaged C++ - no experience wrt managed C++/CLI).
2. I do miss quite a few official standard C++11 features that VS still doesn't support. And I hate to figure out the exact syntax on certain template constructs with virtually no documentation on how to do properly (or at all)! (E. g. defining a template friend function inside a class)
3.snorkie wrote: And before going off on costs, there are free versions of VS.
... which don't support Resharper (or any other plugins)
I do agree that VS is a great tool. But for some people it may not be the right one.
|
|
|
|
|
In a way, yes!
What I'm really driving at is more along the lines of psychologically helpful.
I read a study not that long ago that the average programmer is now producing 1.2 lines of code per man-day. I don't know if this correct or not, but it causes me to wonder "why?" and what could be done to change it.
So my question becomes: What can we do differently?
|
|
|
|
|
There is no one party at fault here...
On the employee side, there is personal responsibility. There needs to be a desire to be a better developer and to work hard.
On the employer side, they need to be more organized. I've heard and experienced issues with companies (mostly large ones) who hire people but don't utilize them anywhere near a person's capacity. I spent a few weeks waiting to get access to systems and be assigned work to do. I left because the job was not fulfilling.
From my perspective, I should strive to be better each day. Secondly, mentor people around me that don't know as much. That was the main way I got up to speed.
Hogan
|
|
|
|
|
Programming languages are not for sissies.
Veni, vidi, vici.
|
|
|
|
|
Didn't he say it was a BASH script? Isn't that Klingon?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
At most he was.
Veni, vidi, vici.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
