## Gosling vs. Dynamic Languages

I really don't want to start a LtU thread consisting of rants (or raves) about dynamic languages. This subject was discussed here more than a few times, and I am not aware of any new arguments that weren't discussed here before. Still, I think the recent brouhaha over statements from Gosling shoud be part of the historical record that is the LtU archive. And there's even a small chance some LtU readers haven't heard of this incident yet.

## Comment viewing options

### The good old

The good old static-VS-dynamic debate. This time however it's getting more and more focused on Ruby-VS-Java, which is overly simplifying the whole thing. If I would like to defend staticly typed language, the last thing I would do would be to pick Java as an example to convince people :)

### Exactly

Here's the condensed LtU guide to the static types vs dynamic types debate:

• Haskell-vs-Scheme is an issue on which reasonable people differ.
• Ruby-vs-Java is an issue on which unreasonable people differ.

Everything else is details. :-)

### Is that all Gosling said?

If yes, then it's just handwaving and there's not enough substance. I'd rather re-read the old LtU threads. At least there's more theory in those.

### Somehow...

…I expected something other than straw-mans and ad-hominems. Silly me. If only everybody would admit to the matter being a question of imprinting and personal preference and not so much about technical merit, all these discussions would go away.

I think the focus of us all sane, rational practitioners in both camps should be defusing such highly emotional, highly charged arguments. Labeling somebody you don't agree with as a "heathen" is, to me, intolerable.

More often than not, in commercial software development, the choice of platform and/or implementation language is fixed and determined by contextual factors having nothing to do with the technical merits of the language and the methodology employed. So why the byzantinism? If you can sell your preference to management, more power to you; if you can't, pay up or fold.

### Gossip == Traffic == Ad $afaict various selected "quotations" were cut & paste to create "a story". Apparently Mr Gosling has said "The quote is accurate, but incomplete and missing context". I expect we'll all find something to quarrel with once Mr Gosling publishes his views on his blog - let's wait until then. ### I'll Be the First to Admit... ...that Ruby really is better than Java in most application domains, IMNSHO. Maybe even in most of them. There. That oughtta be good for a nice long thread. ;-) ### Reminder... I really don't want to start a LtU thread consisting of rants (or raves) about dynamic languages. ### Point Taken And let me just add that I agree with your judgment call, and with those who are disappointed to find Mr. Gosling lapsing into common errors in the Java vs. current dynamic language debate. There are valid points on both sides in the general static vs. dynamic debate; unfortunately, neither side makes them in this article. ### what he said? disappointed to find Mr. Gosling lapsing into common errors in the Java vs. current dynamic language debate Would you like to be specific? (Someone in the audience asked a question) ### This isn't "static vs dynamic" This is "established player vs newcomer". "Toy", "not enterprise-ready" - we've heard it all about Java when it was the new thing. The old thing then was C++. The engineering issues then were "virtual machines vs. native compilation" and "garbage collection vs. manual memory management". ### "Toy", "not "Toy", "not enterprise-ready" - we've heard it all about Java when it was the new thing. if only we had listened.. ### Huh? Java is (and was from the start) so much more programmer-friendly than C++ that it isn't even funny. Garbage collection, real modules, Unicode strings, free stacktraces, safe casts, language support for multithreading... The industrial leap from C++ to Java was actually a lot larger than the leap from Java to Ruby. I admire Gosling for making it possible. ### overrated "industrial leap from C++ to Java was actually a lot larger than the leap from Java to Ruby" Marketing and hype-driven adoption Java was a toy for creating multiplatform web applets back then. Somehow, when M$ put the foot in the adoption of java as a client programming environment, people were able to push it behind the scenes and sell the technology as a heavyduty server platform, despite being dog-slow...

and you know? it worked...

I get annoyed when people talk about things java "brought out-of-the-box", like threading. It's a misconception, because java is a language + stadard libs + lots of good 3rd party libs + a runtime running all that code. If you wish to make a fair comparison to C++, choose a specific platform in the role of the VM and go from there, like: C++ + STL + Boost + POSIX platform + all available libs in said platform...

there you go...

### Yeah, see?

"You can't compare Rails to PHP, because Rails is a framework and PHP is a language. Throw in some PHP libraries for a fair comparison."

Said by... guess who... a PHP fan. Don't remember where exactly.

See, this isn't really a technical debate. This is a marketing debate, and all marketing debates in IT are pretty much isomorphic :-)

### True and false

It's a misconception, because java is a language + stadard libs + lots of good 3rd party libs + a runtime running all that code. If you wish to make a fair comparison to C++, choose a specific platform in the role of the VM and go from there, like: C++ + STL + Boost + POSIX platform + all available libs in said platform...

True and false.

I program in C++ and Java (among other languages). Once I have decided that a project will be written in C++ -- or once someone has decided this for me -- I still have to choose a core library for datastructures and i/o (STL ? ATL ? another template library ? a library without templates ?), a library for database, a library for ui, a library for threading, etc. Oh, and I have to evaluate these libraries for portability and compatibility with each other.

In Java, OCaml, Ruby, Python or just about any half-recent language, most of these things are part of the standard distribution. In any of these languages, unless my needs are so specific that I know exactly what I want, I will only ever use on array type, one container library, one threading library, etc. -- all of them portable. This will make my life easier. In addition, this helps with keeping third-party libraries somewhat compatible with each other.

So what ? Well, so nothing. Just I believe that naked languages, like base C++, or even C++ + STL, are a thing of the past.

### I agree

From a theoretical point of view the main question is whether a language provides sufficient features to build the rich libraries we've come to expect. But if you are interested in language success, it is quite important to think about the standard library. I think most language designers accept this fact (e.g., Ada2005 adds a standard container library, something I campaigned for in the past for exactly this reason).

Both these perspectives were discussed here in the past, by the way.

P.S.

Another reason to build good standard libraries is that this process can influence language design and evolution.

### Hmm

As far as I can see, in lots of interesting programming environments the standard library is not expressible in the language. Can I write a Web browser in Javascript? An HTTP server in PHP (well yeah, i could, but why?) A Flash player in ActionScript?

It seems to me that interesting languages emerge and gain popularity as scripting languages for interesting tools. Like Unix/C, or databases/SQL :-) Or we can say, for example, that Perl is a scripting language for a powerful text-processing tool (Perl). The rise of Java was due to applets, the rise of Ruby due to Rails...

### Ah

But you're confusing DSLs with general-purpose languages. Yes, many DSLs are interesting, but they are (I believe) outside the realm that Ehud was discussing.

It seems to me that interesting languages emerge and gain popularity as scripting languages for interesting tools. Like Unix/C, or databases/SQL

UNIX/C doesnâ€™t fall in this category. C isnâ€™t (and wasnâ€™t created to be) a scripting language for UNIX (perhaps UNIX/Sh would be a better example?). C was created to implement UNIX and hence became a popular language for writing UNIX programs (is this what you meant?).

I think I see your point. Would your point be more valid if it was â€œlanguages emerge and gain popularity as languages for interesting applications and domains?â€ By â€œapplications and domainsâ€, I mean in the big sense (systems languages, AI languages, web/network languages, etc. general purpose languages that specialize for writing applications in a specific domain), not in the classic DSL â€œsubdomainâ€ sense (a path finding language, which could be considered a subdomain of AI languages, perhaps). It is still important to be able to have a language that is flexible and expandable via a module/library system for these general purpose languages (especially since a general purpose language that specializes in a application domain would be great for creating DSLs in subdomains of that domain).

### Yeah, that's it

Exactly. It's very very hard to shove a new general-purpose language down people's throats. To become successful, a new language needs to pose as a DSL for some interesting value of D. Language quality (flexibility etc) only begins to matter on the next phase, when lots of people start to abuse it :-)

### 33:25 through 37:25 transcript

The transcript on Artima is similar to what's spoken on the flash video, 33:25 through 37:25

### Maybe he's just busy

Maybe he's just busy, and hasn't caught up on all his email yet.

### James Gosling writes about the "Scripting flamewar"

James Gosling writes about the "Scripting flamewar"

### Real PLs are .... (fill in the blank)

The same argument about efficiency was at one time used to make a language divide along the lines of native compilation vs. virtual machine/intermediate bytecode. A virtual machine just added too much dang overhead to be considered an industrial strength PL. It's interesting that the inventor of the PL that finally busted this myth (for the masses) is himself drawing another arbitrary line in the sand - though he makes sure to put Java on the side where VMs were once excluded.

And since he mentions ML, it's probably worth noting that many of the strong typing advocates believe that Java's static typing is not without its own share of runtime dynamic typing behavior (Java really being a mix of static and dynamic typing). And the solution of using silent typing based on assignment seems to be missing the main strength of type inference. Not having to declare types here and there does nothing for me if the type can not be made to polymorphically vary according to the input parameters. The strength of type inference is that functions can be reused with different types (generic programming). Just having the compiler always assign the silent type doesn't buy you much but a couple of keystrokes if the type being inferred can not vary.

### I agree but...

I agree with your statement on type inference, but you also get additional flexibility when refactoring your code. Let's say that you're spliting a class in two or just renaming it, using type inference you don't have to modify some types everywhere in your program.

Also, it's not only about keystrokes, but number of words to read when you're maintaining your program. Shorter is often better, although writing the types give you some useful hints when reading some code, but then again type inference doesn't prevent you from adding contraints as well.

### Keystrokes add up

As much as I like having parameterized types in Java 1.5, they have tipped the scale from "annoying" to "oppressive" when it comes to declaring all the redundant type info. I also agree with Nicolas that it makes programs harder to read.

### Java Generics

The problem of the generics in Java is well known. It's the kind of feature that's very nice and powerful, but it's better to have it from the beginning in the language, or else break backward compatibility.

Parametrized types with type inference are also very good friends, they are both very good type system features that help each-others.

### at one time

The same argument about efficiency was at one time used to make a language divide along the lines of native compilation vs. virtual machine/intermediate bytecode.
At one time, was that argument valid?
(iirc Java HotSpot really made the difference in those efficiency arguments.)

### Exactly

And this, I think, is the problem. Almost exactly zero programming languages fit into neat semantic categories. Prolog, for example, is definitely a logic language, but it's also imperative, impure and generally defined by its operational semantics rather than first-order predicate logic.

I forget who it was (possibly one of the Erlang luminaries) who coined the term "dominant paradigm". All non-domain-specific programming languages are multi-paradigm when you get down to it, but each has usually has one dominant paradigm. That's why it makes sense to talk of "Lambda the Ultimate Imperative": languages which are dominantly functional can still allow imperative programming.

All this goes back at least to Schopenhauer. He wrote an essay about "games". It turns out to be pretty much impossible to come up with a set of features that are common to all "games", includes card games, board games, the Olympic games, war games, mind games and so on. The best that you can do, he concluded, was to say "these are games, and things like them are games too".

In a similar vein, it doesn't make sense to say "if it has feature X but doesn't have feature Y, then it's a scripting language and not a general purpose language", because real programming languages defy that kind of categorisation. It makes more sense to say, "A, B and C are scripting languages, and so are languages which resemble them".

### [OT] subvert the dominant paradigm

Everything2 claims that the phrase comes from Kuhn's landmark 1962 book. I suspect that predates Erlang just a bit, though I'm not certain that specifically "dominant paradigm" came from there. And I'm even less sure who coined the "subvert ..." version.

### Sure, but...

...this is a different use of the term. In the programming language sense, it's the paradigm that dominates the language. The OO paradigm, for example, dominates Java, despite it being a fairly ordinary imperative language (with a not so ordinary portable virtual machine).

Say dominant style and avoid the tangential quarrels.

### He's right about the performance of php and ruby

Php and ruby are pretty slow right now. I mean.. there is no reason they can't be sped up by an order of magnitude in the future, but for now it is a problem.

They work quite well as glue code between a compiled code webserver and a compiled code database, but when you start putting more logic in the ruby layer you can feel the slowdown.

We've been doing projects in ruby lately, and sometimes you can feel it crawl. For simple text processing applications it can be almost an order of magnitude slower than perl. :( I know.. I didn't believe it either. It's an implementation issue, but it is unclear when it will be resolved.

It's frustrating for me, because I enjoy coding in ruby. It's as close to a functional language as I've gotten anyone to pay me to code in so far.

### php and ruby

From my experience, PHP can be made really, really fast. There are tools for that...

Ruby, OTOH, has some serious problems. I can say that as a longtime Ruby fan :-)

a) Slow - I guess there's no reason Ruby can't be made to run as fast as Perl, and Perl is fast enough for lots of big sites, e.g. LiveJournal.

b) No native threads - a serious one, but a non-issue for admin scripting and website development, which are Ruby's two main sweet spots.

c) Buggy GC in the presence of continuations - unfixable without a total rewrite of the interpreter, as Matz said somewhere.

### Ruby 2.0

YARV. It should do well enough for a first pass at a bytecode interpeter, if it doesn't JIT as well.

### Ruby 2.0

But when? :)

It's been 4+ years now since the hole Rite thing first came up. It was actually promised for last year at one time, and if it misses Christmas'06... then when?

And, at least for me, speed is the least of current Ruby's problems...

### perhaps...

...they're waiting for the Perl6 implementation on Parrot to show the way?

*ducks*

### Promsied?

"It was actually promised for last year at one time, and if it misses Christmas'06... then when?"

I have a hard time believing Matz ever promised YARV/Ruby 2.0 delivery for any particualr date. And if it wasn't said by Matz (or perhaps Koichi) then it doesn't count.

### â€œPromisedâ€

You're right, promised was too strong a word - my bad. On the other hand, this did have some (including me) believe that was in fact the master plan.

### Performances

That's true that most of so called "web languages" (perl, php, ruby) have pretty bad performances. It's not a surprise since they are interpreted. OTOH Python use an intermediate bytecode compiler and run a VM. I'm working on Neko which also have very good performances (and soon JIT) - especially compared to such other languages implementation.

However I would say that one of the biggest problems of theses languages is the fact that their compilers are written in C and are part of the VM/interpreter. It makes the whole thing monolitic, more difficult to maintain and a lot more bug-prone.

Since their performances are not so good (again it's not the fault of the languages but implementations), people tend to put even more things on the C side when they need reasonable speed, and it just creates even more problems.

BTW someone started to work on a Ruby compiler targetting Neko. That might be an interesting solution, and is actually the reason why Neko was created in the first place : to provide a common lightweight - still quick - runtime.

### Not to get too far off topic

Not to get too far off topic but how does Neko compare to Lua performance-wise? It appears to be about the same size as Lua so there isn't much to gain there. If it's not considerably faster then Neko is in trouble. ;) (also consider there is already LuaJIT)