6 ms·

I think it is a testament to just how far good design choices can outweigh the decision of which language. Two lifetimes ago, I worked at a company that sells

I think it is a testament to just how far good design choices can outweigh the decision of which language. Two lifetimes ago, I worked at a company that sells testing software for CPE devices (consumer grade routers, et cetera). The entire core of that product is written in pure TCL - a fully tunable TCP stack with a knob for adjusting every metric, and a fully state driven architecture composed of TCL primitives that can emulate an entire ISP and a corporate LAN. There are so many languages that would be obvious better choices, but part of what allows a legacy of sledge hammered test cases to evolve is respecting the garden they are grown in - generally when you transplant a tree, you're going to kill it. Instead, a careful analysis of the existing implementation has allowed that product to continue, and grow, for many, many years.

vosper 7y ago
> here are so many languages that would be obvious better choices, but part of what allows a legacy of sledge hammered test cases to evolve is respecting the garden they are grown in - generally when you transplant a tree, you're going to kill it. Instead, a careful analysis of the existing implementation has allowed that product to continue, and grow, for many, many years. I love the way you put this. My team is in the middle of an IMO largely pointless port of working code from Scala to JS, because some senior people think Scala is icky... (Even though my team is a JS team, I don't think JS is a better language than Scala. To the objection I get: "we can't find Scala engineers" I point out that JS engineers on my team have had to learn to read Scala in order to port the code, so they're halfway there already...)
- goatlover 7y ago
  > "we can't find Scala engineers" Is there such a thing as a PL engineer? I thought it was software engineer, and the particular language matters less than general software principles and practices. Plus, any new employee is going to have to learn the code base regardless of whether they start out knowing the language. Any software engineer should be able to learn a new language. The idea that you have to higher engineers who already know the language, particularly a high level general purpose one, seems suspect. It's not like they're writing some low level Rust or C code. It seems like a poor reason to port a code base, but I guess it happens often enough.
  - vosper 7y ago
    > Any software engineer should be able to learn a new language. The idea that you have to higher engineers who already know the language, particularly a high level general purpose one, seems suspect. It's not like they're writing some low level Rust or C code. Yeah, I agree. And I'm doubtful that the time it would take for one or two competent people to come up to speed in Scala is less than the time we're spending to port the entire thing over to JS. It's months of engineering time. That time could have been spent improving the existing codebase rather than the much riskier option of porting to a new language. And then that team would have the Scala engineers it needs, for ongoing work. Or at least a shared resource to help out.
  - SaxonRobber 7y ago
    Most developers aren’t software engineers, they are coders who just jump on the hottest JS trend or are utterly content with Enterprise Java mediocrity. Their entire lens is warped by a narrow view of “coding” and are incapable of programming anything beyond that frame.
- blt 7y ago
  I'm sorry. It sounds like your management is misguided.
bch 7y ago
> good design choices can outweigh the decision of which language It sounds like you’re saying the project succeeded by good design despite Tcl (fair - I don’t know your project), but I’d argue Tcl itself is a fine example of good design. With a small amount of study you’ll be able to effectively reason about it. It’s extremely regular, composable, and interfaces well be it text manipulation, networking, filesystems, GUIs, ..., or indeed, itself - it’s well-established and takes compatibility seriously. I think I’m into it nigh 15 years, and it’s still a proper first-goto tool for me.
- digitalsushi 7y ago
  To TCL's defense, no, I was making a generic claim. TCL was a wonderful language to work with and no sleight was intended.
- tyingq 7y ago
  It has evolved some. Initially, TCL used C strings, and there was no way at all to use any binary data with a null in it. No copying binary files, no non-trival sockets work, etc. And lists being runtime parsed strings of "{blah {blah}} {\{blah}" remains slow and cumbersome. In the 90's, I switched to Perl to get past some of these things. Don't get me wrong, I love it too, but it has warts just like any other language. Ousterhout is clearly an outlier thinker though. Not just the father of TCL and TK but log structured filesystems, RAFT consensus, and more. I'd be excited if he jumped back into a new language project based on his reflective experience. I imagine a more pragmatic Perl 6 or similar.
  - bch 7y ago
    You’re right re: it’s early internals, and we probably both know people who still (mistakenly) complain about that. Conceptually the “everything is a string”(EIAS) model still holds though, even though it’s supported by dual-ported “objects” w native representation, and the running is often byte-compiled instead of string parsing. We’ve got early smart fans who saw the vision and possibilities like Karl Lehenbauer, Don Libes, Richard Hipp, and the current core team like Kevin Kenny, Don Porter, Donal Fellows, etc who deeply understand What Tcl Is, and strictly maintain it, even while pushing it ahead (TclObj, finally an in-core blessed object system, native database framework, Miguel Sopher’s(RIP) work on the stackless non-recursive engine (NRE) and coroutines that fell out of that work... Back to Ousterhout though, you might dig his “Philosophy of Software Design”[0] book, or talks associated with it[1]. Lots to like in this space... [0] https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201 https://www.amazon.com/Philosophy-Software-Design-John-Ouste... [1] https://youtu.be/bmSAYlu0NcY https://youtu.be/bmSAYlu0NcY

vosper 7y ago

> here are so many languages that would be obvious better choices, but part of what allows a legacy of sledge hammered test cases to evolve is respecting the garden they are grown in - generally when you transplant a tree, you're going to kill it. Instead, a careful analysis of the existing implementation has allowed that product to continue, and grow, for many, many years. I love the way you put this. My team is in the middle of an IMO largely pointless port of working code from Scala to JS, because some senior people think Scala is icky... (Even though my team is a JS team, I don't think JS is a better language than Scala. To the objection I get: "we can't find Scala engineers" I point out that JS engineers on my team have had to learn to read Scala in order to port the code, so they're halfway there already...)

goatlover 7y ago
> "we can't find Scala engineers" Is there such a thing as a PL engineer? I thought it was software engineer, and the particular language matters less than general software principles and practices. Plus, any new employee is going to have to learn the code base regardless of whether they start out knowing the language. Any software engineer should be able to learn a new language. The idea that you have to higher engineers who already know the language, particularly a high level general purpose one, seems suspect. It's not like they're writing some low level Rust or C code. It seems like a poor reason to port a code base, but I guess it happens often enough.
- vosper 7y ago
  > Any software engineer should be able to learn a new language. The idea that you have to higher engineers who already know the language, particularly a high level general purpose one, seems suspect. It's not like they're writing some low level Rust or C code. Yeah, I agree. And I'm doubtful that the time it would take for one or two competent people to come up to speed in Scala is less than the time we're spending to port the entire thing over to JS. It's months of engineering time. That time could have been spent improving the existing codebase rather than the much riskier option of porting to a new language. And then that team would have the Scala engineers it needs, for ongoing work. Or at least a shared resource to help out.
- SaxonRobber 7y ago
  Most developers aren’t software engineers, they are coders who just jump on the hottest JS trend or are utterly content with Enterprise Java mediocrity. Their entire lens is warped by a narrow view of “coding” and are incapable of programming anything beyond that frame.
blt 7y ago
I'm sorry. It sounds like your management is misguided.

bch 7y ago

> good design choices can outweigh the decision of which language It sounds like you’re saying the project succeeded by good design despite Tcl (fair - I don’t know your project), but I’d argue Tcl itself is a fine example of good design. With a small amount of study you’ll be able to effectively reason about it. It’s extremely regular, composable, and interfaces well be it text manipulation, networking, filesystems, GUIs, ..., or indeed, itself - it’s well-established and takes compatibility seriously. I think I’m into it nigh 15 years, and it’s still a proper first-goto tool for me.

digitalsushi 7y ago
To TCL's defense, no, I was making a generic claim. TCL was a wonderful language to work with and no sleight was intended.
tyingq 7y ago
It has evolved some. Initially, TCL used C strings, and there was no way at all to use any binary data with a null in it. No copying binary files, no non-trival sockets work, etc. And lists being runtime parsed strings of "{blah {blah}} {\{blah}" remains slow and cumbersome. In the 90's, I switched to Perl to get past some of these things. Don't get me wrong, I love it too, but it has warts just like any other language. Ousterhout is clearly an outlier thinker though. Not just the father of TCL and TK but log structured filesystems, RAFT consensus, and more. I'd be excited if he jumped back into a new language project based on his reflective experience. I imagine a more pragmatic Perl 6 or similar.
- bch 7y ago
  You’re right re: it’s early internals, and we probably both know people who still (mistakenly) complain about that. Conceptually the “everything is a string”(EIAS) model still holds though, even though it’s supported by dual-ported “objects” w native representation, and the running is often byte-compiled instead of string parsing. We’ve got early smart fans who saw the vision and possibilities like Karl Lehenbauer, Don Libes, Richard Hipp, and the current core team like Kevin Kenny, Don Porter, Donal Fellows, etc who deeply understand What Tcl Is, and strictly maintain it, even while pushing it ahead (TclObj, finally an in-core blessed object system, native database framework, Miguel Sopher’s(RIP) work on the stackless non-recursive engine (NRE) and coroutines that fell out of that work... Back to Ousterhout though, you might dig his “Philosophy of Software Design”[0] book, or talks associated with it[1]. Lots to like in this space... [0] https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201 https://www.amazon.com/Philosophy-Software-Design-John-Ouste... [1] https://youtu.be/bmSAYlu0NcY https://youtu.be/bmSAYlu0NcY