More interesting than LanguageDesigner and different from WritesCompilersAsaHobby.

The list:
* ThomasColthurst (OnceProgrammingLanguage)
* BradCox (ObjectiveCee)
* DougMerritt
* DanMuller?
* JonathanTang
* GunnarZarncke
* JohnKugelman
* PeriHankey

Questions (which should perhaps be refactored off this page)
about who qualifies as a LanguageDesigner :

''How are language designers and amateur compiler writers different?''

Amateur language designers design languages, and may never get around to actually
implementing them. And even if they do, it may be in the form of an interpreter,
not a compiler (which is fine, but that does contrast with '''compiler''' writer). Amateur compiler writers write compilers, often for pre-existing
languages.

Or put more bluntly, a LanguageDesigner is a type of InteractionDesigner. A compiler writer is a programmer.

''What was it that was fundamentally different about LarryWall / Perl that makes him a LanguageDesigner, not a programmer?''
* He's both. They're not mutually exclusive. And in fact, although one doesn't have to design languages to implement them, it's hard to do a good job at designing them if one doesn't know how to implement them. So it's a one-way dependency.

Only that Perl is a language, and that it didn't exist before LarryWall came along. I note in particular that LarryWall is in charge of the design of Perl 6, and it isn't very much involved in its implementation at all.

''Perhaps a HobbyistCompilerWriter is just the early stage of a LanguageDesigner? Or maybe a LanguageDesigner is just one whose language became famous?''

Certainly many HobbyistCompilerWriter s are primarily motivated by the desire to implement a language of their own design. Not all, though: some (''most, actually'') may be interested only in implementing a new optimization or parsing technique, or in targetting a new architecture.

Also, IMHO, your language doesn't have to become famous for you to be a LanguageDesigner; that merely makes you a FamousLanguageDesigner.

''People who are '''really''' interested in language design also inevitably study many many languages (to steal ideas :-), which is far less common amongst other programmers.''

----

I hope TomStambaugh have something to his credit other than Java. Because I see no evidence of design in that language. More like evolution.

	 :	''I claim no role in creating the Java '''language'''. My client (Sun) wanted Smalltalk semantics with a C-like language. We quickly confirmed that CeePlusPlus precluded this, and chose ObjectiveCee instead, with the full and enthusiastic support of Sun. Our contribution was the virtual machine, the environment, many or most of the semantics, and of course the demonstration that it was very possible. Our VM demonstrated multiple native types, we showed that "loose typing" worked just fine, we showed that the expressivity and interactivity of Smalltalk was not special magic available only to Xerox. As has been noted before, I am a Smalltalker and have always described the Java language as SmalltalkMinusMinus. -- TomStambaugh''
* Interesting. I guess we should copy this to the JavaHistory page, which gave me a different impression.

''No need for ad hominems. He created a safer, stripped-down version of C++ under contract to Sun. He gave the customer what they wanted. You should never blame a contractor for what the customer wants. Tom himself is a Smalltalk programmer, which presumably says something about his tastes in languages.''

''Also, although not even Sun claims that Java has any new features, that does '''not''' mean that it didn't take design to create it. It is tricky to design a language, even a non-innovating one like Java; one needs to make a lot of careful judgements, for it to be a usable language.''

''You might as well say that there's no creativity involved in writing genre novels (Westerns, Romance, Mystery, Science Fiction), because everything's been thought of before. Doesn't matter; it takes careful design to put the elements together workably, either in a novel or in a language.''

A comparison to Danielle Steele isn't exactly flattering.
* Yes, it is, but unless you have collected rejection slips for attempting to get fiction published in the big markets (or sold millions, of course -- fat chance), you wouldn't understand why that kind of elitism utterly misunderstands the topic.

* ''All right, maybe we're just not using the same meaning for the word. See, to me, design is a creative process. As opposed to engineering. So while DS' books might be very carefully engineered, I don't see a fat lot of creativity in them. But then, I wouldn't be an expert on her cause I haven't read a one. I just know that all romance books are alike, following extremely strict rules of plotting and character development which the authors are afraid to deviate from.''
** If you don't read many (or any) romance novels, then you of course have no basis for claiming they are all alike. That's just how it seems to you as an outsider. Outsiders say the same thing about science fiction. They don't know what they're talking about. They all (mostly) share certain features, which is why it can be identified as a genre in the first place. Those similar features do not constitute identity. Don't make claims about what you aren't familiar with.

** Whatever one thinks of DanielleSteele's work (and I certainly don't care for anything from the genre, but that's just me), calling the writing of pulp fiction "engineering" is a slur against our noble profession. :) Perhaps "manufacturing" is a better term for what Steele and her peers do? :)

* ''I read fanfic. So calling me a literary elitist is absurd.''
* If you sneer at DanielleSteele, you're an elitist. In fact, if you sneer at anything, you're an elitist. In any case, romance novels require creativity, and if you don't know anything about the genre, just drop it. Instead, look at fanfic. Outsiders would make every sneering comment about fanfic that you might make about romance. But *I* know that fanfic requires creativity.
* Anyway, that's all a digression. Non-genre popular fiction would have served to make the same point: novels require creativity. Critics often claim they don't. That's part of why critics have a bad reputation. It's easier to criticize (usually inaccurately) than to create. 

Ahem, Java did have new features, at least as of 1.1 : inner classes (anonymous and non-anonymous). The synchronized keyword and every object is a monitor also look pretty strong candidates for innovative features status although are less valuable . People who otherwise wouldn't dare to touch a threading API, now found an easy way to get themselves deadlocked.
'':)''


* '''Nope. Java invented none of these.''' Really, may we see some arguments about this ?
* Why? No one claims Java has invented anything, so why need I defend a position no one has argued? However:
** C++ has nested classes. A language I implemented in 1979 had them, and I didn't think it was anything remarkable even back then; it follows naturally from making everything first class and orthogonal whenever possible. And even more defensibly, you can write the below challenge easily in Lisp
*** (defclass Rectangle () () )
*** (defmethod Area ((r Rectangle)) (defclass foo ()()))
**** (setf x (make-instance 'Rectangle)) (Area x) (make-instance 'foo). Sorry. It looks to me like a convenient (confusing ?!) way to side effect the global namespace, it doesn't look like inner classes to me, maybe you can elaborate on what inner classes means in lisp, the appearance is that they are just global classes created from inside a method.
**** You're right, I screwed up. But obviously there's some way to do it; I know how to write an ultra-short macro that would then allow that. I just don't recall the standard way.

*** ''Nested classes != inner classes. The key difference being the implicit pointer to the enclosing scope; a nested class in C++ (whether nested inside another class, or inside a function, or somewhere else) has no such pointer--though you could certainly give it one explicitly. Java 1.0 didn't have inner classes either; though it did (I believe) have nested classes. Java inner classes do contain the implicit pointer--a limited form of delegation--and can also point to a function's ActivationRecord, though "final" variables only. (This allows making a copy of the activation record and thus not having to mess with CactusStack''''''s and the like).''
**** I've been thinking that the difference was a fairly trivial issue that was important only in dealing with the existing structure of Java when it was added, but you're saying it's non-trivial, and would be useful in a wide array of other languages? What's this about the ActivationRecord, what interesting thing can you do with an inner class that you can't do with a nested class? Static vs non-static didn't sound like a big deal.
**** ''I don't know where the border is drawn between "trivial" and "non-trivial"; it isn't hard to simulate inner classes bound to objects in a language which doesn't have them. They are useful SyntacticSugar in any case. Inner classes nested in (and bound to) functions, on the other hand, aren't easily fakable in C++. About the closest you could come is to replace your function with a FunctorObject, make its variables into instance variables of the functor, and make your inner class nested in that. But that gets real UgLy real fast.'' 

** Monitors were '''invented''' (by PerBrinchHansen) as a language feature, way back in 1970 or so, and implemented e.g. in Concurrent Pascal.
*** ''Didn't CarHoare first propose monitors? Or is my memory hazy?''
**** No, it was Per, but your memory isn't completely crazy: http://www.acm.org/classics/feb96/
**** You are of course correct. But PerBrinchHansen didn't have the (bad ?!) idea to make every object in his concurrent Pascal a monitor. Now that's the invention :) 
* This is all well known history, so Java fans should be careful to avoid being HostileStudent''''''s. If one doesn't know the history of something, one should not just assume. Java has its points, but those points involve creative selection of features, not introducing new language features never heard of before. The class libraries are, on the other hand, necessarily a source of innovation in some ways, for better or for worse.

* So does this leave the discussion to the point where java did have new features after all ? I know it's nice and dandy to bash Java, however ...
** I don't think it's "bashing" to state the historical record. Like I keep saying, Sun, Gosling, Bill Joy etc never claimed that Java invented new features; Java fans tend to '''assume''' that it did without any reason for assuming this (this tends to be true of fans of anything). I don't see anything above that is critical of Java, only of the baseless claims.
** Did Java introduce anything new after all? The one surviving claim that may be true is its distinction between an inner class and a nested class. To me, this still sounds closer to an idiom (something that fits nicely, like the right piece in a jigsaw puzzle, relative to the other language features) than to being a standalone language feature (one that might be useful in unrelated languages, for instance, Pascal's "with" was borrowed by VisualBasic, and would work just as well in some Lisp dialect; DoesNotUnderstand works well in any dynamically dispatched OO language; C's short-circuit '''and''' and '''or''' have been heavily borrowed in languages ranging from shells to Perl).
** ''Well, at least they invented the idiom, or whatever you want to call it. But it is a new and innovative feature. Steele could have easily added blocks but he came with this idea. There are languages who came with new inventions and languages that are totally non-innovative (like C for example). If the historical record shows that inner classes are a new feature that appeared in Java 1.1, than it should be granted without much ado. Just a few days ago I went through the ugly exercise of using "delegates" in C# with C# nested classes, and there's a world of difference. The mechanism can be very useful in all other class-based OO languages.''
** Fair enough; ok, given my current understanding, I grant inner classes as a new innovative feature. I can't really see Java fans waving this around as a banner for bragging rights, though. BTW you are mistaken that C was totally non-innovative, but perhaps the list of examples would be seen as similar to my comments about inner classes. I don't think so, but I'd rather find an existing analysis than attempt to wing it on the subject right now. 


Just try to write in another OO language

 .. myMethod( ... ) {
 class X {
 }
 }

Not even C# -- which was supposed to take advantage of Java experience -- managed to get it right (so far).

[Ahem! In PythonLanguage:

 class Dumb:
     print 'Dumb class'
     def method(self):
         print 'Dumb instance method'
         class Dumber:
             print 'Dumber class'
 d = Dumb()
 d.method()
outputs
 Dumb class
 Dumb instance method
 Dumber class
]

''That may be equivalent to Java's. But was it there before or after Java 1.1 ?''

''Wow. So when Smalltalk got blocks right the first time, like, way way back in the 70s, that musta been cause they were, like, way way more intelligent than we are. Like, Einstein, like.''
* Almost. Actually they refined them a bit in the early 80s, influenced by Scheme/Lisp.
* Closures and inner classes are very different animals.

* ''They're still not finished. ST blocks aren't full closures.''
** That overstates. In almost all versions of Smalltalk, they are full closures, your info is out of date. SmalltalkBlocksAndClosures

''Every object is a monitor is also dumb as an invention. When I first learned about monitors, I thought every object WAS a monitor. I wonder what "innovation" is supposed to mean exactly. Cause I understand invention but the other must be something else.''