Hacker News Reader

Comment by bch | Hacker News Reader

> Tcl (like Perl) shot itself in the foot right as the DotCom/DotBomb went off.

I don’t know what you mean “shot itself in the foot“ here. Some examples?

> Python was effectively completely stable through all this and gained a critical mass following.

I don’t know how much more “effectively stable” Python was than Tcl. Can you expand on this?

I personally see this largely as “luck of the draw”. It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL. Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that? We can see things now and say “popular languages are popular”, and that’s about it.

View on HN

> I personally see this largely as “luck of the draw”.

Not luck of the draw, it was because of the OOP craze in the late 1990s and early 2000s. In undergraduate school I took some introductory programming classes for an easy A, as I was already working as a web developer (like many in my generational cohort) for living expenses. (My degree program was entirely unrelated.) In one of those classes I just ended up as something of a [very poor] TA for the professor. At some point he told me that his department was looking to reorganize their curriculum to emphasize OOP and asked what I thought about Java and Python. I had never programmed in either, mostly working with Perl, JavaScript, PHP and ColdFusion. But I told him that Python was becoming popular in the open source space, and the simplicity of the language, including dynamic typing, and freely available tooling would likely make it more accessible.

I don't know if he took my advice, but in any event as I remember things Python eventually overtook Perl partly, if not largely, by riding the OOP wave. People like to say that it was because Python was simpler and more consistent (TOOWTDI instead of TMTOWTDI), but it was really only simpler and more consistent in the context of OOP programming. For quick, top-to-bottom procedural programming tasks Perl has always been simpler, IMO.

> Not luck of the draw, it was because of the OOP craze in the late 1990s and early 2000s.

Sure, but Tcl also had/has a well-regarded OO system, and Ruby was on the scene, so Python doesn’t actually stand out singularly.

Perl 5 also had OOP, but neither Perl nor Tcl could credibly claim "native" OOP during the relevant time frames. By contrast, one of Python's founding design goals was OOP.

Ruby didn't have very much mindshare in the U.S. during the relevant period. Which is a real shame. There's always been a significant amount of great work coming out of Japan that never gets popular attention elsewhere. Ruby is one of the notable exceptions, though it's break-out success came belatedly. (Wikipedia says the first English language Ruby mailing-list was created in 1999. AFAICT, O'Reilly's first Ruby book was "Ruby on Rails", published 2006. O'Reilly's "The Ruby Programming Language" wasn't published until 2008. All of these are indicative of an exceptionally late popular introduction to the English language programming community.)

I don't mean to imply that luck had nothing to do with Python's success. It's just that if you look at the contenders at the time and the qualities that people were (rightly or wrongly) looking for in a programming language, it's not at all surprising why Python gained popularity. To the degree luck had anything to do with it, it was largely the timing of those nexus of factors.

AFAICT, O'Reilly's first Ruby book was "Ruby on Rails", published 2006. O'Reilly's "The Ruby Programming Language" wasn't published until 2008.

O'Reilly published Matz's Ruby in a Nutshell in 2001, but it didn't sell very well. When I worked there, I encouraged more Ruby publishing but only after I published the "Rolling with Ruby on Rails" articles (January 2005) did that argument get much traction.

The Pragmatic Programmers released their first Ruby programming book in 2000, by way of comparison (and Dave introduced me to DHH in 2004, which is how I decided to seek out the Rails articles).

According to my recollection and accounts of others I've read, a huge part of Python's early success was the maintainers' decision to support a comprehensive "batteries included" distribution of extension modules, including binary compiled libraries.

Tcl made the crucial (in retrospect wrong) decision not to support a central extension package repository or well-stocked releases and chose to focus on the core. This forced users to scrounge the web for extensions and hope they compiled on their platforms, and depend on sketchy support from individual authors.

The OOP craze played a significant role as well I think. I recall that in the late 1990s Tcl was part of something of a renaissance of varied programming paradigms escaping academia and getting applied in the wild (partly in the form of clever Tcl extensions). But Java/OOP and WWW/server-client killed that movement dead.

Perl and Tcl carved themselves into incompatible versions (Perl 6 and Tcl 8) at a critical moment.

Python, on the other hand, felt like it was at version 1.5.2 absolutely forever.

> It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL.

Except that, in the late-1990s/early-2000s, it didn't matter. Scripting languages were slow relative to compiled languages. Multiple-threads effectively didn't exist. Hyperthreading didn't hit until 2003--after the DotBomb.

> Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that?

Gee, who could have guessed that a whole lot of scientists and engineers kinda liked Matlab the program but hated Mathworks the company and that providing somewhere for them to jump ship to would be popular? Like ... absolutely everybody?

Of course, just the idea isn't enough. The alternative has to be sufficiently capable.

Thus ... Enthought. Enthought personnel put in a lot of elbow grease and work to make Python a scientific computing go-to language.

As always, the best way to predict the future is to make it.

I wasn’t actually maintaining software across this divide, but I do still occasionally see Tcl 7.x installations in the wild and find it quite recognizable. It seemed to me the biggest changes from 7->8 were byte code interpreter and “dual ported” Tcl_Obj to store values vs naive C strings(which should have only exposed themselves as “improved performance”).

The release notes[0] for Tcl 8 seem to list minor-ish annoyances, but perhaps you did have to support something across the 7-8 divide; I won’t argue against your experience in that case.

> As always, the best way to predict the future is to make it

Truth.

[0] https://www.tcl.tk/software/tcltk/8.0.html#incompatibilities

Did TCL have a compatibility break with version 8? I've always perceived TCL as an incredibly stable language, with features added but rarely removed/changed. Is there a time when that wasn't true?

Correct, the move from Tcl 7 to Tcl 8 did not break Tcl code nor C extensions, and brought huge performance benefits. C extensions could be updated to use them, but the C string API continued (and continues) to exist.

Reply on news.ycombinator.com