4 ms·
It baffles me whenever someone announces their discovery that Java didn't invent objects and garbage collection as though that invalidates the whole language.
by Stormbringer 16y ago
It baffles me whenever someone announces their discovery that Java didn't invent objects and garbage collection as though that invalidates the whole language. I wonder what rock they have been hiding under. How could any true language enthusiast not have an understanding of their language's history?
====
Java has very few original features. However, it did serve as a sort of 'feature aggregator', where it pulled in a very large pile of features from other languages and housed them all under one roof.
What I (vaguely) remember about Java from the early days as being it's (other) main advantages were:
(1) incredibly easy networking (compare sockets with C for example)
(2) applets (yes they suck(ed), but no other language had that browser adoption)
(3) it wasn't Microsoft (not such a big deal now, but back in the day Microsoft were a lot more aggressive)
(4) it was open(ish) (you could look at the library code to figure out how it was doing stuff) (compare with Visual Basic where everything either magically works or magically doesn't)
(5) Threads (compare again to semaphores)
(6) Free (as in beer)
In some cases, such as early Java, I think a feature most people don't really take into account is not what was put into the language, but what was left out. By hiding pointers behind the curtain, it made the language a lot easier. Easier to write, and easier to read. Even then it had its wrinkles, the people I know who were uber-productive in Java tended to use a small subset of the languages features.
Over the years of course feature creep has slipped in, so it now has bits of perl (regex) and bits of C++ (templates/generics). A lot more of the base code is a lot uglier than it used to be....
====
As for Lisp, I don't really buy the argument that lack of a good IDE held it back. I think the following reasons are more to the point:
A) butt ugly syntax (I'm talking about the random lengths of indents, not the ()s - to understand why this is bad, go learn you some usability)
B) greedy corporate interests (if the developer kit for Java had cost $10,000 no one would ever use it either) (early on)
C) language fracturing and speciation (there are too many 'little lisps' for any one of them to gain momentum) (later on)
D) lack of well written textbooks (compare to the veritable explosion of books for Java in its early days. Back when I was actually interested in Lisp I used to pick up books on it, and they'd invariably spend the first 2 pages showing some vague equivalency to lambda calculus and then it seemed as though they felt their teaching duty was done)
speaking of the lambdas...
E) programmers got better at naming variables and functions (having anonymous functions may be a neat party trick, but nowdays when we put on our big boy pants we like to name stuff)
F) missed the OO boat because they were too caught up in their own cleverness (early OO implementations in Lisp were butt ugly and broken (didn't do encapsulation and/or inheritance well)).
You may argue (as the author of the original article does) that currently Lisp does wonderful OO, but you have the same problem as say Java does, overcoming the slowness myth(s).
I wonder if it is possible to predict the critical junctures where the myths about a language solidify. In any case, it doesn't help to make a new lisp with more/better/faster features (in an attempt to create new myths), because that just feeds the confusion (see point C above)
edit for irony: missed a )
- kunjaan 16y ago> D) lack of well written textbooks 1. How do I program? I dont know how to build abstractions. I dont know how to write correct, modular and reliable codes. I'll start with "How to Design Programs" 2. I want to learn more about recursion. I want to master thinking recursively because I have found that they solve a lot of my problems. Let me see "Little Schemer". 3. I want to learn more powerful constructs like continuations, tail calls and what not. I want to learn to solve harder problems in Scheme. Let me pick up "Seasoned Schemer". 4. Wow macros are pretty nice. I want to learn more about them. Let me first see how to write unhygenic ones. Paul Graham's "On Lisp" is amazing! 5. Constructing higher levels of abstraction is something that I really want to master. What kinds of abstractions can I build? What are the ways to construct large programs? What is the way to organize programs? What is programming? Let me read SICP 6. What is a loop? Why doesn't scheme have it? How can I build it? How do I build these kinds of abstractions? Wand's EOPL is my bible at this stage. 7. Let me do something useful in Scheme. How do I write much more powerful macros? I love my types. I love my modules. I love my libraries. Racket, I think you are the most powerful thing out there.
- rednum 16y agoI don't know what was the programming like in the early days of java, but none of the original featurs of java is unique to java anymore - whereas lisp has some unique features. C is pretty bad language to compare Java to - they are designed to write different kinds of programs actually. It shouldn't be surprise that doing stuff with sockets is much harder in low level language as C. Also, threads and semaphores are two different things, (by the way, there is some threads support in C), so point (5) is simply invalid. Considering lisp - I don't see what is wrong with indentation - they actually have something to do with logical structure of code, (also I don't get whats wrong with their usability - for me this 'random indented code' is readable). Speaking of too many lisps - one could as well say that there are too many C-like languages : C, C++, C#, Objective-C. They are all different languages, no some forks of 'The Lisp'. Considering books - well, I've read few of them and none mentions lambda calculus (unfortunately, I'd eagerly learn something about that) - e.g. PCL, 'On lisp'. Also, I think you completely miss the point with lambdas - they are necessary when you are using higher-order functions and naming them would be pointless.