4 ms·

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

by bch 5y ago

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

bsder 5y ago
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.
- bch 5y ago
  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 https://www.tcl.tk/software/tcltk/8.0.html#incompatibilities
- nrclark 5y ago
  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?
  - lehenbauer 5y ago
    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.
wahern 5y ago
> 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.
- bch 5y ago
  > 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.
  - wahern 5y ago
    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.

by bch 5y ago

bsder 5y ago

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.

bch 5y ago
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 https://www.tcl.tk/software/tcltk/8.0.html#incompatibilities
nrclark 5y ago
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?
- lehenbauer 5y ago
  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.

wahern 5y ago

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

bch 5y ago
> 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.
- wahern 5y ago
  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.