I mentioned in one of my JavaScript posts that future iterations of that language would be picking up noteworthy features from other languages, like generators and iterators.
This, of course, further confirms that programming languages (and their underlying concepts) are, by and large, separated mainly by different holy books, priestly rites, and religious practices - and they all promise essentially the same thing; except they're not the same.
I recently came across an amusing article on the topic: the Semicolon Wars. Its (reasonably) accessible to the uninitiated, but with enough meat to make it fun for the ponytail-and-sandals set (you know who you are :P).
Enjoy.
7 comments:
"[...] the ponytail-and-sandals set (you know who you are :P)"
Those are pretty big words coming from the uber-preppy camp. :-)
Back to your original point, eventually seasoned programmers stop arguing syntax (sigh, boring) and instead argue semantic capabilities of programming languages. i.e., which languages support a proper mapping operator vs. which ones don't, and why the former are necessarily superior. c.f. Iterators: Signs of Weakness in Object-Oriented Languages
dossy - "uber-preppy" OOOOOUUUUcccchhh; doesn't code-slinging get me a little slack? :P
In terms of the iterator paper - yeah, co-routines are the schnizzle; I hadn't seen that article, and I largely agree - I've never been a big iterator fan. The move from "generators" to "iterators" in modern programming was a backslide IMHO.
The move to co-routines is a good generalization in the right direction, though asynchronous programming (events, threads, network i/o), etc. is still MUCH harder than it should be in most every language.
The closest solve I've seen has been with Finite State Machine lanuages, and Functional programming generally - but its really hard for developers to get their heads around it. There's a reason imperative programming styles are more broadly used.
Hmm... If your point is that different programming languages are fundamentally the same, I have to disagree.
I wouldn't want to build an OS with Javascript, wouldn't want to build a device driver with Java, and wouldn't want to build a lightweight web app with C. And I wouldn't want to build anything with a monster language like Ada - languages that are designed to fix every problem generally fail to be ideal for any problem.
There are fundamental differences in the philosophies behind these languages, and fundamental differences in the tasks to which they are best suited.
C'mon - You wouldn't want this?
Actually, I'd argue those are NOT language differences, but "execution context" differences. How would scripted C for web apps or compiled JS (with appropriate OS bindings ala ANSI lib stuff) be different, other than your comfort level?
I'm grossly oversimplifying of course (this is a blog, after all, not any form of reality :)) but I do think folks tend to unnecessarily conflate languages and their execution environments - sometimes for good reason, but mostly not.
That said, .NET tried to actually apply this philosophy, with mixed results.
There was a time when one couldn't imagine applications written in markup, either.
My point was that languages, in general, don't enable different capabilities - they enable ease of learning, scalability, and better maintenance/extension. The other stuff really is independent of the "language".
That said, .NET tried to actually apply this philosophy, with mixed results.
Sree, they still let you write code? If that's true, we should get you some sandals. :-)
It'll be a sad day when the closest you come to code is cutting and pasting snippets into a Powerpoint deck.
At least it seems we agree on something: the interesting discussions revolve around capabilities, not syntax.
Some various real differences between languages, that make them appropriate for different applications:
- Javascript supports self-modifying code. This is useful and powerful in a web app, but would be really painful in an OS, whether the language itself is scripted or compiled.
- Java has the basic philosophy of making things easier and less prone to error for the programmer, even at the expense of level of control over the environment or optimized performance. Several language features illustrate this philosophy. One example is that array bounds checking is always done when you reference an array element. If you have to do a pedal-to-the-metal application where complete control over the hardware environment is crucial, and you have to squeeze every last cycle from your hardware, you should not use Java.
- Some languages provide direct support for object orientation. I've done object-based programming in C - it is nowhere near as flexible as true object orientation in C++. If you're going to build an app where object orientation is a reasonable fit (e.g., ones heavy on user interface objects), then you'll be better off with a true OO language than one where OO has to be shoehorned in.
- Some languages provide solid support for large scale projects. These features include the classes of the object oriented languages, or the modules in languages like Modula2 and Ada. Writing a simple program in such a language is painful, because there's too much overhead. But if you are building truly large scale systems, those features are invaluable.
- None of this addresses the non-procedural languages. I'd much rather write database queries in SQL than C. And functional languages like APL, rule-based languages like Prolog, or imperative languages like Euclid all have their place, but that place is not going to be where you'll find most C, Java, and Javascript applications live.
Can you write any program in any language. Well, sure - pretty much all of these languages are Turing complete. But just because you can write a Turing machine to do anything, doesn't mean that it's going to be the best language for any particular application.
Post a Comment