7 ms·

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"

by pflanze 13y ago

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)

Argorak 13y ago
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?"
- skywhopper 13y ago
  I'm curious what features of Java would be worth stealing for Python or Ruby?
  - Argorak 13y ago
    Don't know, but it is a question I get from people coming from Java from time to time.
    - cgore 13y ago
      Real threads ... and ... that's probably it.
      - Argorak 13y ago
        Ruby has real threads now. Java had green threads back then.
        cgore 13y ago
        By "real", I mean native and multi-core. Does that exist now? I think it exists in JRuby, but in MRI?
        sluukkonen 13y ago
        All major Ruby implementations use OS threads, but the GIL still limits parallelism in MRI.
        Argorak 13y ago
        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.)
      - dragonwriter 13y ago
        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.)
        bad_user 13y ago
        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.
  - the8472 13y ago
    * 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
    - aaronblohowiak 13y ago
      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?
      - the8472 13y ago
        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.
        djur 13y ago
        But by the same measure, JRuby is part of the Ruby ecosystem.
  - rat87 13y ago
    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.
  - rat87 13y ago
    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]
- justizin 13y ago
  the creation of both happened without java, but both have been heavily influenced by java today.
- goggles99 13y ago
  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?
  - Argorak 13y ago
    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.
  - riffraff 13y ago
    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"
    - the8472 13y ago
      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.
krstck 13y ago
Don't forget Clojure, birthyear 2007.
tjr 13y ago
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.
gnu8 13y ago
Ada, 1980.
- crag 13y ago
  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.
xradionut 13y ago
Lua 1994 Icon 1977
- justincormack 13y ago
  no, Lua is 1993...
crag 13y ago
You forgot Ada, 1975. Mainly used by the military and contractors. Still in use today, by the way.
- riffraff 13y ago
  also still updated, there is at least an Ada 2012.
pflanze 13y ago
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.)

by pflanze 13y ago

Argorak 13y ago

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?"

skywhopper 13y ago
I'm curious what features of Java would be worth stealing for Python or Ruby?
- Argorak 13y ago
  Don't know, but it is a question I get from people coming from Java from time to time.
  - cgore 13y ago
    Real threads ... and ... that's probably it.
    - Argorak 13y ago
      Ruby has real threads now. Java had green threads back then.
      - cgore 13y ago
        By "real", I mean native and multi-core. Does that exist now? I think it exists in JRuby, but in MRI?
        sluukkonen 13y ago
        All major Ruby implementations use OS threads, but the GIL still limits parallelism in MRI.
        Argorak 13y ago
        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.)
    - dragonwriter 13y ago
      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.)
      - bad_user 13y ago
        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.
- the8472 13y ago
  * 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
  - aaronblohowiak 13y ago
    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?
    - the8472 13y ago
      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.
      - djur 13y ago
        But by the same measure, JRuby is part of the Ruby ecosystem.
- rat87 13y ago
  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.
- rat87 13y ago
  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]
justizin 13y ago
the creation of both happened without java, but both have been heavily influenced by java today.
goggles99 13y ago
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?
- Argorak 13y ago
  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.
- riffraff 13y ago
  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"
  - the8472 13y ago
    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.

krstck 13y ago

Don't forget Clojure, birthyear 2007.

tjr 13y ago

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.

gnu8 13y ago

Ada, 1980.

crag 13y ago
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.

xradionut 13y ago

Lua 1994 Icon 1977

justincormack 13y ago
no, Lua is 1993...

crag 13y ago

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

riffraff 13y ago
also still updated, there is at least an Ada 2012.

pflanze 13y ago

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.)