Earlier quoted context omitted.
I think it's less relevant today, because we now have multiple languages running on the JVM - and I think that was always the most powerful feature of the Java program, the write once, run anywhere idea. Not so much the language itself, although at the time it was pretty good too.
IIRC Steele talks about languages which are extensible by users not just compiler writers. Although, JVM allows you to have multiple language implementation on top of JVM, it still doesn't make it easy to extend a language the way lets say Lisp can. He speaks of having primitives in language which allow programmers to extend language (macros?).
Growing a Language, by Guy Steele (1998) [video]
11–20 of 21 posts
Re: Growing a Language, by Guy Steele (1998) [video]
#12Earlier quoted context omitted.
IIRC Steele talks about languages which are extensible by users not just compiler writers. Although, JVM allows you to have multiple language implementation on top of JVM, it still doesn't make it easy to extend a language the way lets say Lisp can. He speaks of having primitives in language which allow programmers to extend language (macros?).
If macros and LISP on the JVM are what you're looking for, that already exists: https://clojure.org/
Re: Growing a Language, by Guy Steele (1998) [video]
#1320 years later. What does Guy Steele thing about how Java ended up? We still have no operator overloading, no value types. There are plans, sure, but Java grows very slowly. Good thing? Bad thing? Does anyone know if there is a follow up on this?
Re: Growing a Language, by Guy Steele (1998) [video]
#1420 years later. What does Guy Steele thing about how Java ended up? We still have no operator overloading, no value types. There are plans, sure, but Java grows very slowly. Good thing? Bad thing? Does anyone know if there is a follow up on this?
Thank goodness there is no operator overloading. I maintain 15 year old java codebases and am very happy they did not add user defined operators...
Often have I though "My good, if only the language had better supported what the programmer is trying to implement himself through horrible hacks, then I wouldn't be sitting here trying to wonder exactly what mistakes he made that casuses everything to crash inexplicably."
Re: Growing a Language, by Guy Steele (1998) [video]
#15Great talk, one of my inspirations. The "nub" (slightly edited): "A language design can no longer be thing. It must be a pattern, a pattern for growth". "My point is that a good programmer does not just write programs. A good programmer builds a working vocabulary. A good programmer does language design, though not from scratch, but building on the frame of a base language" https://youtu.be/_ahvzDzKdB0 Oh, the paper…
You see this more and more in "test languages" like cucumber. These languages more explicitly allow programmers to specify domain items and behavior, much more so then general programming languages like Jav, C#, js, etc. I'm currently experimenting with a piece of software that actually does have a specific domain language defined using ANTLR. I'm totally unsure of this will make any sense, but at least it is fun to do. One benefit I can see already is that I now have fully typed & typechecked logging :). Another aspect I'm experimenting with is using it as a replacement for sais "test languages".
You can find my grammar here: https://github.com/generateui/jsettlers-web/blob/master/jset...
Re: Growing a Language, by Guy Steele (1998) [video]
#16Earlier quoted context omitted.
Thank goodness there is no operator overloading. I maintain 15 year old java codebases and am very happy they did not add user defined operators...
I always find this an odd reason to be against usable features. I have inherited codebases in extremely confined languages as have I inherited codebases in very permitting high-level languages Python, and never have I though "Thank good this language decided to restrict its reach in order to confine the programmer to a smaller subset which made it harder for him to mess up." Often have I though "My good, if only the…
A second example of this culture is the go language. I read a few repo's, and the same style of programming is seemingly applied throughout.
For the Java case, I can actually see operator overloading going haywaire over many codebases. The same as overengineering is a typical trait associated with Java.
Re: Growing a Language, by Guy Steele (1998) [video]
#17Re: Growing a Language, by Guy Steele (1998) [video]
#18Great talk, one of my inspirations. The "nub" (slightly edited): "A language design can no longer be thing. It must be a pattern, a pattern for growth". "My point is that a good programmer does not just write programs. A good programmer builds a working vocabulary. A good programmer does language design, though not from scratch, but building on the frame of a base language" https://youtu.be/_ahvzDzKdB0 Oh, the paper…
Main Entry: bottom line
Part of Speech: noun
Definition: indispensable content
Synonyms: basis, conclusion, core, crux, determination, essence, fiber, final decision, fundamentals, income, key point, last word, loss, main idea, main point, main thing, meat and potatoes, name of the game, net, nitty-gritty, nuts and bolts, point
Re: Growing a Language, by Guy Steele (1998) [video]
#19Great talk, one of my inspirations. The "nub" (slightly edited): "A language design can no longer be thing. It must be a pattern, a pattern for growth". "My point is that a good programmer does not just write programs. A good programmer builds a working vocabulary. A good programmer does language design, though not from scratch, but building on the frame of a base language" https://youtu.be/_ahvzDzKdB0 Oh, the paper…
Re: Growing a Language, by Guy Steele (1998) [video]
#2020 years later. What does Guy Steele thing about how Java ended up? We still have no operator overloading, no value types. There are plans, sure, but Java grows very slowly. Good thing? Bad thing? Does anyone know if there is a follow up on this?
Thank goodness there is no operator overloading. I maintain 15 year old java codebases and am very happy they did not add user defined operators...