Slashdot Mirror
What I Hate About Your Programming Language
chromatic writes "Perl programmers like punctuation. Python programmers like indentation. Every programming language has its own syntax, stemming from its philosophy. What I Hate About Your Programming Language examines the issues that shape languages as they grow. It's not advocacy, I promise."
ASP isn't a language. You can use any number of scripting languages with it. Of course, most are done in VBScript, but many folks use JScript (javascript), because it is what they use for the client side script.
DO NOT DISTURB THE SE
I didn't list specific gripes about the languages you describe because I don't really have enough practical experience with them to analyze them well. I do discuss languages such as Lisp and Smalltalk in the analysis section though, just as you mention.
Just to be fair, though, one of my gripes with Lisp is the idea that reducing all syntax to a Lambda form makes up for moving all the remaining complexity to built-ins and extensions. I certainly don't think in trees -- a little syntactic sugar is tasty. That doesn't make Lisp wrong; it just doesn't fit my brain as well.
how to invest, a novice's guide
The syntax for working with anonymous data structures and structures by reference is ugly:
unless somewhere else in the code you've got a:this code will do nothing. and if you've got a mapping of names to numbers (and HACKERS must be numeric, since it's an array indice), you should be using a hash instead.
but of course, since this is perl, doing it correctly is even uglier
--BlueLines "The cost of living hasn't affected it's popularity." -anonymous
I love Squeak. It's SmallTalk, OO, Realtime, runs on anything, and is easy to cope with.
Check it out, if you are older, like me, and getting into programming but have never programmed much before:
http://www.squeak.org/
I looked at this article, and I was disappointed by what a limited set of languages chromatic had examined.
... other than to incompletely, idiosyncratically, and in biased form say "well, here's something I noticed that I disagree with".
Given the superficial and haphazard nature of the review, I was just as glad it didn't touch on those other languages. I really didn't get much of value out of the article and the only thing that would have been worse is an equally superficial treatment of my own languages of choice.
And anyway, one person's opinion is just one person's opinion. It's a pity the author didn't attempt to do any kind of survey. Even an unscientific survey might have been more interesting and/or informative than this was. In its present form, there's no way to detect hints of incompleteness, idiosyncracy, bias,
I'm sorry if these remarks sound critical, but the entire article came across to me as flamebait and I'm not sure what positive quality I can draw from it. It started off as a nice idea--that language philophy can influence syntax or vice versa. But it diverged about halfway through from that to random, unmotivated jabs at this and that language and really ended up going nowhere with few, if any, useful takehome messages.
Maybe I was also put off by the fact that the author's statement, that "Lisp is very much the lambda calculus". As a matter of history, several decades ago, it might have been reasonable to say that Lisp was "inspired by" ideas of the language calculus (though some might say "misunderstandings of the lambda calculus"), but the language was a whole is really enormously different than that now. It is often used as a teaching vehicle for esoteric things like the lambda calculus because other languages can't stretch that far, but mainstream Lisp does not look or feel much at all like the lambda calculus, any more than "modern music is very much that of Elvis Presley", however much his break from the past may have been a founding influence on modern music. This failed allusion injured the author's credibility with me within the article almost irreparably.
Kent M Pitman
Philosopher, Technologist, Writer
Bjarne wanted to put generics in from the very beginning.
Java "cleans up" nothing, it simply strips out all the more powerful features of C and C++ which novices tend to stub their toes on. Oh, and it adds one important feature: inner classes. Unfortunately the result is a language whose omitions actually make it more verbose and harder to maintain than C++.
Neither ObjC nor C# is an attempt to "fix" C; Objective C is an attempt to embed a Smalltalk object system in C, and C# is an attempt to fix Java. Neither of them are applicable to the same problem domains as C.
Everything in C++ belongs there, and most of it was intended to go in from a very early stage. The only thing that needs to be "cleaned up" is the C preprocessor. Templates could use easier syntax but no one has come up with anything signifigantly better than the current syntax.
--
CPAN rules. - Guido van Rossum
Yes, there are many situations where operator overloading is essential to writing concise and readable code.
* Streams. >> and graphically represent what is going on, and allow the chaining together of multiple elements.
* Strings. + represents concatenation better than a "concatenate" method could. Even Java agrees.
* Iterators. hasNext and Next is overly verbose and unnecessarily complicated, compared to ++ and *.
* Containers. Subscripting (a[i]) is a very common operation and looks much clearer with nte subscripts than a "at" method.
* Function objects. Having objects which can be called just like functions, "object(argument)", is crucial to creating generic algorithms.
* Assignment and Equality. Assigning from one class to another using = is better than an "assign" method. Testing for equality with == and != is much clearer than an "equals" method.
Anyway the whole "designing a new programming language" argument is wrong, because an operator is simply a function with a symbol and precedence. That is all. If operator overloading is defining a new language, then so is writing new functions.
Obviously people can misuse and overuse operator overloading, but that is true of any language feature and should be expected. You can design the perfect language, but it will always be possible for bad programmers to make a mess with it.
It seems that complex math is always the example people pull out to support operator overloading
// etc. etc. etc.
I was just thinking the same thing as I read the parent comment. Everyone uses complex numbers as an example. But, when programming in Java, it's not being able to overload == and != (and even sometimes [] if we're talking about collections) that drives me up a wall!
Take for example a class which contains both native types and objects. In order to implement the equals(object obj) method, you have to do the following:
return this.intType == obj.intType && this.objectType.Equals(obj.objectType) && this.byteType == obj.byteType && this.objectType2.Equals(obj.objectType2);
Yes... it's functional. No, it's not pretty. And that's where operator overloading is most sorely missed in my book.
The JScript engine is (was? it's been a while since I paid attention) faster than the VBScript engine.
And for that matter, VBScript is a horrible abortion of a language. Imagine, VB - but less graceful and powerful. Ugh.
A side note: I've seem to have commited the sin of misattribution. Waldemar Horwat is not the current driver (or a peer) of the JS module at Mozilla: Brendan Eich (the original author at Netscape) is. Mr. Horwat seems to have been one of the redactors of the ECMA standard, though.
So this probably won't see the light of day, but...
I thought that this was one of the best essays I've read in some time, even given its lack of technical substance.
The message of this article ultimately is that our languages of choice are often as much a matter of subjective personal preference as anything else.
A major theme of this article, then, was not to bash languages, but to celebrate the variety. The author's really trying to encourage us to explore our personal tastes.
Did anyone else note the link to pragmatic programmers, following admonishments to learn a new programming language each year?
How many on Slashdot try something like this? Maybe not every year, but on a regular basis? What's your experience been? Is it worth it? Anyone switch their language of choice because of it? Expand their respect for other languages?
I think you'll find this guy does know how to program.
As well as being well-respected within the Perl community (And possibly other languages too) he's the O'Reilly technical editor, the author of their "Extreme Programming Guide" and the chief author of "Writing Weblogs in Slash".
I have a feeling I may well have just been trolled, but I thought it worth dropping this here so people at least knew that this guy was not some random schoolkid knocking out half-formed opinionating.
My advice: Do a little research before posting
404 Not Found: No such file or resource as '.sig'
Scary thing is, all the things you mention are gone now in VB.NET.
AndAlso/OrElse for short circuits, subs and functions all take parens to call, real exceptions, variants are dead, and they took the VBScript IsNumeric oddities to the grave with them (though you were begging for pain when you relied on IsAnything with VBScript).
I mention this lest you think VB was crippled forever... Try the new stuff - it's like object oriented code with real words, instead of seventy different types of punctuation to make something simple look like some goddamn magic trick.
"Consider yourself a member of a virtual corporation with Mr. Torvalds as your Chief Executive Officer." - Linux Advocac
a[3] == &a + 3 == 3 + &a == b + &a == b[a]
Breaks for non-wordsized types.
Ada's actually quite nice - it was the teaching language at Adelaide University when I was there. Although even Defence don't use it much any more (so it doesn't translate directly into a gig), it teaches you good programming habits, and it's what Oracle used as a basis for PL/SQL, so you can use what you've learnt at any Oracle site without too steep a learning curve.
What a long, strange trip it's been.
Borland Delphi
Sure it's not BASIC, but then that's not exactly a bad thing.
Compiles down to a standalone executeable.
How about an array who's size you don't know until runtime?
If 'vector' is not enough for you, you can always typedef it(parentheses are used for illustration purposes only):
#include "vector";
typedef std::vector(int) IntArray;
IntArray intArray1;
but alot of things just don't have really elegant solutions
And what are those things ? you don't say. STL provides THE elegant solution. Remember, 'typedef' is your friend.
and the standard libraries are too sparse for what modern apps do with modern languages
I too wished that C++ had standards for gui, multitasking, databases, networking and other useful tasks. But... C++ is a language standard, it is not a run-time environment. If you want all this functionality, you can always use Qt(for example). C#, the specification is portable to other OSes, since it is an ECMA (?) standard, but the run-time isn't. So don't hold your breath taking your C# source code and compile it on Linux...on the contrary, any STL-based app will compile the same with almost every C++ compiler, and Qt is 100% source code compatible on every OS it supports.
Static Weak: C
Static Strong: ML
Dynamic Weak: Perl5 (just say no, kids!)
Dynamic Strong: Scheme, CL (well, CL is "optional static")
Common Lisp (CL) is also optionally dynamic, in the sense that a declaration is considered to be what I guess would be called in law a "prima facie" case (rebuttable presumption) of truth.
That is, if I say that X is an integer and the compiler cannot prove otherwise, it must believe me. That means it doesn't do either static or dynamic checking, and bad data can screw things up. But the power of this is that if the dataflow is such that it would be impossible for the compiler to prove the truth, I don't have to suffer with slow code (which I think outsiders naively assume I have to do when they hear "dynamic strong").
If the compiler is very smart, of course, it is welcome to disprove any stated declaration--the CMU CL compiler does a great deal of work in this regard, and the resulting feel is very interesting. What's important is that the compiler is not required to do such checking, but it's allowed to do as much as it wants, so the language embraces ongoing/future work in proof technology in a graceful way, yet never changes the meaning of correct programs. It was very exciting to us as language designers to see CMU CL take this idea and run with it--the results are quite interesting, and I'd love to see more of this. One problem with static inference is that the langauge must be designed around the set of inferences that are within the scope of existing technology at the time of the language design; new static inferencing rules require new languages.
Typically, in Common Lisp, one leaves in the dynamic checks that are not in performance bottlenecks, but does more careful by-hand data flow analysis in situations of critical performance and then declares things that one thinks the compiler might not easily deduce. The result is generally the best of both worlds--you aren't beaten down by making scads of unnecessary declarations in development, and you aren't held back from quite efficient programs in production. The main difference is that in C, every program is (at least superficially, ignoring issues of algorithmic complexity) efficient or you can't write it; in CL, you can write inefficient programs long enough to test them without fussing over tons of declarations that might never matter because you're just going to later discard the whole program. When you get to a program you're going to keep in CL, then you want to optimize it. But managers of CL programmers need to know to plan extra time at this point, rather than earlier in a project, or they will be surprised. If (just for seeing actual numbers) you assume that declarations double the time of any code-writing, and if you assume that the first phase of development costs time P (for "prototyping"), and the last phase of development costs time F (for "finalization"), and if you assume T prototypes are needed before finding the right prototype to finalize, CL will take P*T+2*F to develop a product, while C will take 2*P*T+F to develop a product. If you assume that P and F are roughly equal in time, or that T is large, then you can understand why CL programmers prefer not to write declarations. I don't raise these formulas to start a big advocacy dialog here, but merely to show that the shape of the development curve is different for the two languages; even if you disagree with my off-the-cuff formulas, if you agree that the languages have different formulas, you're seeing the real essence of what I'm saying.
This is an example of something 'material' that a paper that talks about the relationship of 'syntax' and 'culture' should have addressed.
Kent M Pitman
Philosopher, Technologist, Writer
That's because every Pascal-bashing geek is referring to ANSI Pascal which is very limited in its features. Very few people know that the current Pascal implementations (Delphi, Virtual Pascal and some others) are much closer to Ada than to (forgotten more than ten years ago) ANSI standard.
Of course, that syntax wasn't guaranteed to work until R5RS, and even then it was done to conform with IEEE's doing away with optional ("non-essential") features in their own standard.
Not to mention that even R5RS uses (define foo (lambda ...)) more often than (define (foo ...) ...)