I thought the same about Python but recently I read a good book about it (Dive into Python) and I think it has lots of features that outweigh this serious flaw (I still think whitespace for syntax is one).
I do not disagree with your statement that syntax is irrelevant. Many aspects of syntax are, but readability is an important aspect to understand what code does. Ruby is very good in that area, Python is after a while and in Perl you can (I wrote "can", I know it is possible to write better Perl Code) write things you won't understand yourself half an hour later. C-like languages and especially Java has problems in that departement as well IMHO.
I agree that Unit-Testing is a good idea, it is however a totally different kind of testing then the one you normally do with a debugger or with print statements which is the part where you try to understand the bug. With Unit-Testing you detect the presence or absence of bugs (you thought of/already encountered).
But the question is wether these complexity-reducing mechanisms should be built into the language (like modern scripting languages) or use the language (like IDE features).
Unfortunately for creating world peace we must somehow get rid of all the people (marketing, managers,...) that want these tools more than everyone else so when they finally arrive nobody is left that needs them.
Even if you have an upper limit of program size of 64k (your memory) and running all testcases would take only 1 second per program to test you would need 2^16777216 seconds to test all possible programs.
To do this it would be nice to have programming language versions so you could have a header in your files that your programs comply to definition 4 of and all parsers with the same or higher versions support this while at the same time the higher versions are developed without the flaws of the older ones. In other words: A language you can depend on to not break with every minor version AND being developed at the same time.
You broadcast your calendar with an entry "Away - Holidays" and all the nice people with the crowbars in the neighbourhood know where to break in with minimal risk.
Unix-like is not C-like.
And the last time I checked all the modern Scripting languages (developed Open Source afaik)have superior syntax AND use the strong points of Unix like e.g. the everything is a file paradigm or regexp. I think Unix has survived for 30 years for a reason:
simplicity
a "feature" most big companies seem to forget these times.
This is a common error. You only know how they look with your (or the default Windows) font settings,...
Try looking at them on a PC of someone with bad eyes who uses a double fontsize font and you will begin to love the dynamic dialogs (because you will be able to see more than half of your text)
Funny, in my experience high-level tools make me worry about code-level-problems more than low-level ones do. High-level-tools often do something almost but not exactly the way I need them done and then I spend more time on this small difference than I would have spend on the whole manual code writing thing. I think however that domain languages and special parsers for them are useful (like lex and yacc e.g.) if you can decide yourself when NOT to use them and when they integrate nicely with manual code-writing.
Why non-Java IDEs haven't caught up, I don't know.
Maybe Java has a language design so bad that you need these tools more than with other languages.
Java lacks a certain kind of consistency in is API that is sometimes called the Principle of least surprise. In Ruby e.g. you want to sort an array, you call arrayname.sort, in Java you call Collections.sort(arrayname) after searching the documentation where the latter is speed up by the use of an IDE but the problem wouldn't even exist if the language design wasn't flawed in the first place.
That would be a nice idea however I doubt that it will be integrated into programming languages/IDEs from people who think Javadoc is a good idea even though you can't navigate Sun's own Javadoc-Collection in a useful way without using google to search it (even concerning Classes that have similar functions like the different Time and Date Datatypes).
But Autogenerators seem to create bad code more often than not. You only have to look at the majority of auto-generated HTML-Code out there which is a far easier to generate than Code in a Programming Language to see that Autogenerators are still not there (and perhaps never will be).
If solving the problem is difficult in itself what do you think creating an automated solver for that problem will be...more or less difficult?
I never understood why someone would design a language with a C-like Syntax today. Okay, C has its uses but it definitely hasn't the best syntax I have ever seen. Most modern scripting languages like Ruby and Python have a relatively easy, short syntax and focus on integrating proven tools like regexp, xml-parsers,getopt... into the language to ease common tasks like string-parsing and config-file reading and writing. In Java most of these tasks still require pages of code which were spend better elsewhere with real problems.
Automation means Scriptability which is not possible in most IDEs I know. They let you use their integrated scripts but when you want to make a custom change no IDE-Developer thought of you are at the same point as in a simple text editor. With Emacs or make or the shell I can write small programs to make almost any change in my programs I want. That is true automation.
The problem here is that car mechanics still understand the whole engine of a modern car. Developers ARE the mechanics, not the normal people, if the developers don't know what's going on (or going wrong) we have too much abstraction.
We should remove some abstraction until a time where the lower abstraction levels are guarranteed to work 100% correct. Then we can start to build additional abstraction above them.
And then there are people like me prefering emacs (or another simple editor) over the feature-bloat of these graphical development tools and debugging mostly with print-statements which get the job done and can be used in any environment (and almost any language) without reading pages and pages of manuals to understand the debugger.
If you want Graphics, Sound, Input,... try SDL, you get an easy API AND support for more than one platform which is the absolute killer argument against DirectX IMHO.
Slashdot Mirror
I agree. You can do things on a (conceptually) 30 year old Unix commandline that are still practically impossible (to automate) in modern GUIs.
I thought the same about Python but recently I read a good book about it (Dive into Python) and I think it has lots of features that outweigh this serious flaw (I still think whitespace for syntax is one).
I do not disagree with your statement that syntax is irrelevant. Many aspects of syntax are, but readability is an important aspect to understand what code does. Ruby is very good in that area, Python is after a while and in Perl you can (I wrote "can", I know it is possible to write better Perl Code) write things you won't understand yourself half an hour later. C-like languages and especially Java has problems in that departement as well IMHO.
I agree that Unit-Testing is a good idea, it is however a totally different kind of testing then the one you normally do with a debugger or with print statements which is the part where you try to understand the bug. With Unit-Testing you detect the presence or absence of bugs (you thought of/already encountered).
But the question is wether these complexity-reducing mechanisms should be built into the language (like modern scripting languages) or use the language (like IDE features).
Unfortunately for creating world peace we must somehow get rid of all the people (marketing, managers,...) that want these tools more than everyone else so when they finally arrive nobody is left that needs them.
Even if you have an upper limit of program size of 64k (your memory) and running all testcases would take only 1 second per program to test you would need 2^16777216 seconds to test all possible programs.
To do this it would be nice to have programming language versions so you could have a header in your files that your programs comply to definition 4 of and all parsers with the same or higher versions support this while at the same time the higher versions are developed without the flaws of the older ones. In other words: A language you can depend on to not break with every minor version AND being developed at the same time.
What a nice idea.
You broadcast your calendar with an entry "Away - Holidays" and all the nice people with the crowbars in the neighbourhood know where to break in with minimal risk.
Unix-like is not C-like. And the last time I checked all the modern Scripting languages (developed Open Source afaik)have superior syntax AND use the strong points of Unix like e.g. the everything is a file paradigm or regexp. I think Unix has survived for 30 years for a reason:
simplicity
a "feature" most big companies seem to forget these times.
This is a common error. You only know how they look with your (or the default Windows) font settings,...
Try looking at them on a PC of someone with bad eyes who uses a double fontsize font and you will begin to love the dynamic dialogs (because you will be able to see more than half of your text)
Funny, in my experience high-level tools make me worry about code-level-problems more than low-level ones do. High-level-tools often do something almost but not exactly the way I need them done and then I spend more time on this small difference than I would have spend on the whole manual code writing thing. I think however that domain languages and special parsers for them are useful (like lex and yacc e.g.) if you can decide yourself when NOT to use them and when they integrate nicely with manual code-writing.
But Autogenerators seem to create bad code more often than not. You only have to look at the majority of auto-generated HTML-Code out there which is a far easier to generate than Code in a Programming Language to see that Autogenerators are still not there (and perhaps never will be). If solving the problem is difficult in itself what do you think creating an automated solver for that problem will be...more or less difficult?
I never understood why someone would design a language with a C-like Syntax today. Okay, C has its uses but it definitely hasn't the best syntax I have ever seen. Most modern scripting languages like Ruby and Python have a relatively easy, short syntax and focus on integrating proven tools like regexp, xml-parsers,getopt... into the language to ease common tasks like string-parsing and config-file reading and writing. In Java most of these tasks still require pages of code which were spend better elsewhere with real problems.
+1000 Insightful
Funny. CVS seems to work just fine when you use it from the commandline (which is REALLY easy btw)
IDE != Automation
Automation means Scriptability which is not possible in most IDEs I know. They let you use their integrated scripts but when you want to make a custom change no IDE-Developer thought of you are at the same point as in a simple text editor. With Emacs or make or the shell I can write small programs to make almost any change in my programs I want. That is true automation.
The problem here is that car mechanics still understand the whole engine of a modern car. Developers ARE the mechanics, not the normal people, if the developers don't know what's going on (or going wrong) we have too much abstraction. We should remove some abstraction until a time where the lower abstraction levels are guarranteed to work 100% correct. Then we can start to build additional abstraction above them.
After all there must be a reason lisp is one of the oldest programming languages still alive...
And then there are people like me prefering emacs (or another simple editor) over the feature-bloat of these graphical development tools and debugging mostly with print-statements which get the job done and can be used in any environment (and almost any language) without reading pages and pages of manuals to understand the debugger.
Not to mention the crappy HTML-Emails and Word-Generated HTML-Pages with so many tags you have to read it twice to find the first part of real text.
If you want Graphics, Sound, Input,... try SDL, you get an easy API AND support for more than one platform which is the absolute killer argument against DirectX IMHO.