Comment by pflanze | Hacker News Reader

Comment by pflanze | Hacker News Reader

I was a bit surprised about the age, and wondering where it fits into the timeline, so I put together the following list (years corresponding to the "appeared" indication taken from Wikipedia). (There will likely be nicer lists elsewhere..)

  1957 (57) Fortran
  1958 (56) Lisp
  1958 (56) ALGOL
  1959 (55) COBOL
  1964 (50) APL
  1970 (44) Pascal
  1970s     Forth
  1972 (42) C
  1972 (42) Prolog
  1972 (42) Smalltalk
  1973 (41) ML
  1975 (39) Scheme
  1978 (36) TeX
  1982 (32) PostScript
  1983 (31) C++
  1983 (31) Objective-C
  1984 (30) Common Lisp
  1986 (28) Erlang
  1987 (27) Perl
  1990 (24) Haskell
  1991 (23) Python
  1993 (21) Ruby (according to article)
  1994 (20) ANSI Common Lisp
  Mid 1990s Dylan
  1995 (19) Java
  1995 (19) Ruby (according to Wikipedia)
  1995 (19) JavaScript
  1996 (18) Ocaml
  2000 (14) C#
  2003 (11) Scala
  2003 (11) Factor
  2005  (9) F#
  2007  (7) Clojure
  2008  (6) Nimrod (according to speedydeletion.wikia.com)
  2009  (5) CoffeeScript
  2009  (5) Go
  2012  (2) Rust
  2012  (2) Julia

(edit: added Clojure, of course) (edit 2: added ObjC, Dylan, Nimrod, Go, Rust, Julia)

Ruby was first released in 1995, development started in 1993. So, both numbers are right. "Ruby's birthday" is traditionally the start of development. The most interesting info is: Ruby and Python are both not influenced by Java.

An easy answer to the question: "Why didn't they just steal that from Java?"

I'm curious what features of Java would be worth stealing for Python or Ruby?

Don't know, but it is a question I get from people coming from Java from time to time.

Real threads ... and ... that's probably it.

Ruby has real threads now.

Java had green threads back then.

By "real", I mean native and multi-core. Does that exist now? I think it exists in JRuby, but in MRI?

All major Ruby implementations use OS threads, but the GIL still limits parallelism in MRI.

MRI has native threads a GIL, but you can already release the GIL and run freely in native extensions.

And this is _not_ a property of native vs. green threading. (And shows how shallow the comparison is, given the number of languages that implement green threads mapped to native threads nowadays.)

Real (presumably, that means native) threads are an implementation detail and not a language feature, and both Ruby and Python use native threads in the current main implementation (and Ruby, and I believe Python, also have implementations that use native threads without a GIL/GVL.)

In both languages threads are an added after-thought and no, I disagree with you - multithreading is not an implementation detail. For example, why do you think classes in Java are immutable?

Also, I consider the standard library to be a part of the core language, because it is. Python doesn't have many concurrency primitives that are commonly used in Java, even really common ones, like AtomicReference or CountDownLatch. Heck, it doesn't even have volatile variables, let alone ForkJoinPool or other niceties. What's actually in the standard library? Well, the multiprocessing library is now baked in for doing "process-based threading", which really means stuff based on fork() that is unportable, because the language implementors gave up on threads a long time ago.

It doesn't stop at concurrency primitives though. For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work.

Add to that libraries like NumPy/Scipy that are basically unportable, or Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version, or the myriad other libraries in the ecosystem all written for CPython and expecting a GIL. Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.

Thats the case for python. Ruby actually shows that designing a language that runs both on and off the JVM is indeed possible.

> In both languages threads are an added after-thought

So?

> no, I disagree with you - multithreading is not an implementation detail.

Threading is a language feature, not an implementation detail. Whether threads are implemented by way of native threads on the underlying platform (as in JRuby, current CPython or MRI), or green threads in the runtime (as in old MRI, etc.), and, in the latter case, whether the green threads are mapped to native threads on an N:1 (as in old MRI) or M:N (as in the main Erlang implementation) model are implementation details.

> For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work.

Sure, it could, since you could obviously (at the cost of making interop harder) write a Python implementation with its own garbage collector that ran on the JVM or CLR. You might choose to sacrifice portability for better interop with the languages the platform was designed for, but that's a choice.

> Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version

Seems to me that's a problem either with Django or the pure python MySQL driver, but not with the Python language.

> Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.

Perhaps; I'm less familiar with Python's other implementations than with Ruby's (particular JRuby) which is definitely usable, and definitely uses native threads without a GIL.

I'd rather steal from Tcl/Lua/Go: coroutines+channels

Coroutines => Fiber[0] (since 1.9.stg)

[0]: http://www.ruby-doc.org/core-2.1.0/Fiber.html

* Threads without GIL (which also requires an explicit memory model) * concurrency libraries * Garbage collectors that scale to hundreds of gigabytes worth heap, are parallel and concurrent * JIT that performs within a small factor of C code * Tooling support, especially profilers and debuggers are lousy and frequently break in my experience * bytecode weaving/AST transforms at runtime. The whole refinements thing could have been done more cleanly with callsite and method entry/exit hooking

Talking about MRI here. I know rubinius and JRuby exist and offer some of those features

The creation/creators of Java are not responsible for most of the things you listed. They are attributable to HotSpot, built by the fine folks that brought you the best-of-breed Smalltalk implementation half a decade after Java's release.

HotSpot wasn't released until 1999. Prior to that Java did not have a JIT. Java used to be very slow compared to compiled code and HotSpot was a BIG DEAL when it was released in '99.

GC that scales to hundreds of gb? Do you mean Azul, the proprietary and expensive JVM implementation?

G1GC for dozens of GB, Azul (for now) for hundreds and in the future there'll be Shenandoah.

You're right that those features provided by hotspot. But it is the reference implementation for the JVM after all.

The point remains that the java ecosystem - which includes tooling like eclipse/netbeans/yourkit and JVM implementations - provides the things I've listed that I find lacking in ruby.

But by the same measure, JRuby is part of the Ruby ecosystem.

I think the new enums in python 3.4 are based on java enums(module for dynamic typing, for example I beleive comparing them to ints or adding them if they have int values will fail at run time as opposed to compile time) as opposed to enum as an alias for integers.

according to the wiki

> Python's standard library additions and syntactical choices were strongly influenced by Java in some cases: the logging package,[27] introduced in version 2.3,[28] the threading package for multithreaded applications,[29] the SAX parser, introduced in 2.0, and the decorator syntax that uses @,[30] added in version 2.4[31]

the creation of both happened without java, but both have been heavily influenced by java today.

Of course Ruby and Python are influenced by Java (there is hardly a maintained language that has not been). Not the initial release perhaps, but don't you think that Ruby has evolved over the 19 years since Java was released? This release alone has been influenced by Java (Generational garbage collection enhancing performance by as much as 100% in some cases)

A question for you is why do you care? If a Java programmer tries to rib you saying that Java is better because x feature was influenced or 'stolen' from Java, just laugh at them and tell them then C++ must be 'better' than Java huh?

I am speaking language design here. Ruby is a surprisingly conservative language when it comes to changing syntax and semantics.

Sure, runtimes always evolve and cross-pollinate.

I don't care, but as stated in another comment, you often get that question from people joining over from the Java camp.

how is generational GC a java thing? It's been around since the '80s [0]

[0] 1983 "A real-time garbage collector based on the lifetimes of objects"

Generational GC itself is not specific to java. But if you want to look at state-of-the-art collectors then you'll generally find them in JVMs.

I forgot Lua and PHP; I also didn't think of Ada. So, for whatever kind of completeness, here are some more:

  1975 (39) Modula      1988 (26) TCL
  1977 (37) Ada [1]     1990 (24) J
  1977 (37) Icon        1993 (21) Lua
  1985 (29) Miranda     1994 (20) Pike
  1986 (28) Oberon      1995 (19) PHP
  1987 (27) Clean       2002 (12) Io
  1987 (27) Self

[1] according to crag

I don't know birth dates for these:

  Agda, ATS, Felix, Idris

(I'm ignoring languages that are used only in a particular context, like R, shells, proof assistants; I made an exception for TeX and PostScript as these seemed particularly important.)

In this day of software developers seemingly needing to keep up with the latest technologies, it is interesting to realize that the languages I use most often are decades old.

You forgot Ada, 1975. Mainly used by the military and contractors. Still in use today, by the way.

also still updated, there is at least an Ada 2012.

Don't forget Clojure, birthyear 2007.

Lua 1994 Icon 1977

no, Lua is 1993...

Ada, 1980.

1975 (ok, release was 1977). Was in active development/production work in 1977. The DOD standardized on Ada in 1986 (I think). I was in the Army then writing Ada (and using Wang - remember Wang?).

Ada is still in use today. Besides the military, there are a lot of "mission critical" systems written in Ada.

Reply on news.ycombinator.com