As a license freedom fanatic, there are lots of reasons for me to like Tcl/Tk. As far as I can tell it's the oldest genuinely free scripting language, permissively licensed since 1988, with a copyfree high-level GUI toolkit, and it even uses fossil instead of git(hub). And it gives Stalinman hysterics, which is a great bonus!
But it lost popularity and hasn't been evolving much since the 90s... These days Lua runs circles around it in terms of popularity, performance, tooling, ease of embedding, and even module ecosystem copyfreedom percentage (1761 of 2106 or 83.618% Lua rocks are copyfree; compared to 174 of 236 or 74% for Tck gutter).
I find that general purpose scripting languages are more trouble than they're worth. It has been proven that static typing actually improves your productivity in the long run, especially on larger projects and especially with intelligent editors / IDEs. And of course the performance / bloat avoidance advantages of compiled native code languages are huge.
Modern FLOSS ecosystems have become a "multicultural" nightmare, with every tool written in a different language - with its own run-time requirements, build tools, security problems, and versioning hell. It's yet another SJW poison of our day - apparently criticizing the R-selected scriptkiddie "ruby girl" software makes you a nazi...
Once you have good flexible tools written in real programming languages, you don't need much more than ye olde shell script to automate and glue things together.
Im with you on shell can do most scripty things. Tcl seems like a step above and below shell. I agree general purpose high level scripting languges are not tje best at anything, but Tcl because of its support for C and playability with shell seems like a low level general purpose scripting lang. Im thinking a C-tcl-julia stack is where i want to go for data science, systems mgt, prototyping, and iot. Lua seems like a more powerful low-level scripter, but im not doing low level dev outside of C/circuits, where tcl shines. If the worst part of tcl is its lack of modern maintenace, I do see since many have stopped using it, it got OO and arrays recently. It seems like its the best old and overlooked langauge that is probably already on my router, atm, smartfridge, etc. If it had a stats package, id be certain I was uncovering a spaceship.
What we need is a well-organized well-funded project to build a proper Unix distro + desktop environment based on rational and consistent design principles. Choose one systems language that's safe, productive, and copyfree (I recommend Nim or D). Just like Microsoft uses .NET and Android / Oracle / IBM / etc use Java. You can also choose one scripting language for automation, but don't overuse the scripting languages for serious programming work.
Guaranteed to be installed by default on any POSIX system
By that logic you should be using ed as your sole code editor. 🤓
Maybe a better measure would be "minutes to install on my favorite POSIX system"?
Nim (my preferred systems language) and Korn shell (my preferred scripting language) have no dependencies, and are available as a package for all BSDs. OpenBSD uses pdksh by default.
Dynamic language interpreter in less than 300KiB of object code
mksh static is 178k on linux.
Compiles to fast machine code with a defined/stable ABI
That's a very long list that includes Fortran, Ada, etc - any my favorite, Nim.
Maybe a better measure would be "minutes to install on my favorite POSIX system"?
Sure, that's another metric with value, but it probably has a lot of overlap with the interpreter/stdlib size.
mksh static is 178k on linux.
mksh conforms to the POSIX sh spec, so I consider it included by the sh bullet point. Likewise for the other 20 or so POSIX compatible shells.
That's a very long list that includes Fortran, Ada, etc - any my favorite, Nim
That seems like a pretty short list to me. Nim gets it's well-defined ABI by virtue of compiling to C. Do they guarantee ABI stability?
Anyway, the overarching point of my comment was that most people overlook portability/size/stability when choosing a language, in favor of dumb hipster shit like "elegance" or "popularity".
Sure, that's another metric with value, but it probably has a lot of overlap with interpreter/stdlib size.
I agree, although library dependencies is probably the biggest issue, especially if you only count those not typically included in the base system. Some LLVM-based compilers require recompiling LLVM, even if it's included in the base system. Haskell, Rust, LDC, Julia, etc seem to take many times more CPU time to build from ports on a base FreeBSD system than Nim.
Anyway, the overarching point of my comment was that most people overlook subtle (but important) technical merits like portability/size/stability when choosing a language, in favor of dumb hipster shit like "elegance" or "popularity".
I agree with you, although I must confess that I'm addicted to some aspects of syntax "elegance" like Nim's brevity, off-side rule, UFCS, etc.
I've avoided using the word "elegance" ever since the CoffeeScript developers took to using it (and many others after them). It seems to be a catch-all term used to justify design choices in entirely subjective terms.
Languages are a human interface, so some degree of subjectivity is fair enough, but prioritizing eye candy over technical merits to logical extremes just produces awful languages like CoffeeScript. Some of it is good -- but as a sum of parts it's just an unreadable mess.
I've noticed another hipster trend lately around "safety". Rust people drone on and on about this like it will somehow turn bad programmers into world class experts. Memory safety is a good thing and compiler tracked object lifetimes are useful, but the Rust toolchain has so many other problems that it's basically unusable in the niches where it makes the most sense. Not to mention that its killer feature exists mostly for performance reasons (vs. using garbage collection) and yet its performance is extremely underwhelming.
14 comments
0 u/libman [OP] 01 Jun 2019 20:32
This comparison is pretty old, but not much has changed. Plain ol shell (ex. OpenBSD's Korn shell or mksh) can be the best scripting language for gluing together programs written in system languages like C/C++, Rust, D, Go, or Nim. That's what the Unix philosophy of building small interoperable programs is all about.
0 u/avgwhtguy1 01 Jun 2019 23:39
What yall think about tcl/tk? Seems good for iot and personal system mgmt..
0 u/libman [OP] 02 Jun 2019 00:40
As a license freedom fanatic, there are lots of reasons for me to like Tcl/Tk. As far as I can tell it's the oldest genuinely free scripting language, permissively licensed since 1988, with a copyfree high-level GUI toolkit, and it even uses fossil instead of git(hub). And it gives Stalinman hysterics, which is a great bonus!
But it lost popularity and hasn't been evolving much since the 90s... These days Lua runs circles around it in terms of popularity, performance, tooling, ease of embedding, and even module ecosystem copyfreedom percentage (1761 of 2106 or 83.618% Lua rocks are copyfree; compared to 174 of 236 or 74% for Tck gutter).
I find that general purpose scripting languages are more trouble than they're worth. It has been proven that static typing actually improves your productivity in the long run, especially on larger projects and especially with intelligent editors / IDEs. And of course the performance / bloat avoidance advantages of compiled native code languages are huge.
Modern FLOSS ecosystems have become a "multicultural" nightmare, with every tool written in a different language - with its own run-time requirements, build tools, security problems, and versioning hell. It's yet another SJW poison of our day - apparently criticizing the R-selected scriptkiddie "ruby girl" software makes you a nazi...
Once you have good flexible tools written in real programming languages, you don't need much more than ye olde shell script to automate and glue things together.
0 u/avgwhtguy1 02 Jun 2019 01:01
Im with you on shell can do most scripty things. Tcl seems like a step above and below shell. I agree general purpose high level scripting languges are not tje best at anything, but Tcl because of its support for C and playability with shell seems like a low level general purpose scripting lang. Im thinking a C-tcl-julia stack is where i want to go for data science, systems mgt, prototyping, and iot. Lua seems like a more powerful low-level scripter, but im not doing low level dev outside of C/circuits, where tcl shines. If the worst part of tcl is its lack of modern maintenace, I do see since many have stopped using it, it got OO and arrays recently. It seems like its the best old and overlooked langauge that is probably already on my router, atm, smartfridge, etc. If it had a stats package, id be certain I was uncovering a spaceship.
0 u/rcb 02 Jun 2019 02:47
Tcl has traditionally been string oriented, which would make it a terrible choice for heavy-duty calculations.
BTW https://archive.fo/lar6t#selection-1681.1-1681.63
0 u/rcb 02 Jun 2019 02:39
UNIX brought us "polyglot programming" as they call it nowadays, bring back lisp machines. UNIX Haters unite!
0 u/libman [OP] 04 Jun 2019 00:34
What we need is a well-organized well-funded project to build a proper Unix distro + desktop environment based on rational and consistent design principles. Choose one systems language that's safe, productive, and copyfree (I recommend Nim or D). Just like Microsoft uses .NET and Android / Oracle / IBM / etc use Java. You can also choose one scripting language for automation, but don't overuse the scripting languages for serious programming work.
0 u/rcb 04 Jun 2019 01:56
pick one
0 u/galabad71 02 Jun 2019 15:18
I really like running CSSCRIPT in Notepad++ for when I am working in windows.
0 u/HoneyTrap1488 03 Jun 2019 01:03
Specified by an open standard (POSIX) with about 20 different implementations (50 points):
☑ sh ☐ All the others
Guaranteed to be installed by default on any POSIX system (20 points):
☑ sh ☑ awk ☐ All the others
0 u/libman [OP] 04 Jun 2019 00:25
By that logic you should be using
edas your sole code editor. 🤓Maybe a better measure would be "minutes to install on my favorite POSIX system"?
Nim (my preferred systems language) and Korn shell (my preferred scripting language) have no dependencies, and are available as a package for all BSDs. OpenBSD uses pdksh by default.
mksh static is 178k on linux.
That's a very long list that includes Fortran, Ada, etc - any my favorite, Nim.
0 u/HoneyTrap1488 04 Jun 2019 02:16
Sure, that's another metric with value, but it probably has a lot of overlap with the interpreter/stdlib size.
mkshconforms to the POSIXshspec, so I consider it included by theshbullet point. Likewise for the other 20 or so POSIX compatible shells.That seems like a pretty short list to me. Nim gets it's well-defined ABI by virtue of compiling to C. Do they guarantee ABI stability?
Anyway, the overarching point of my comment was that most people overlook portability/size/stability when choosing a language, in favor of dumb hipster shit like "elegance" or "popularity".
0 u/libman [OP] 04 Jun 2019 16:22
I agree, although library dependencies is probably the biggest issue, especially if you only count those not typically included in the base system. Some LLVM-based compilers require recompiling LLVM, even if it's included in the base system. Haskell, Rust, LDC, Julia, etc seem to take many times more CPU time to build from ports on a base FreeBSD system than Nim.
I agree with you, although I must confess that I'm addicted to some aspects of syntax "elegance" like Nim's brevity, off-side rule, UFCS, etc.
0 u/HoneyTrap1488 04 Jun 2019 17:06
I've avoided using the word "elegance" ever since the CoffeeScript developers took to using it (and many others after them). It seems to be a catch-all term used to justify design choices in entirely subjective terms.
Languages are a human interface, so some degree of subjectivity is fair enough, but prioritizing eye candy over technical merits to logical extremes just produces awful languages like CoffeeScript. Some of it is good -- but as a sum of parts it's just an unreadable mess.
I've noticed another hipster trend lately around "safety". Rust people drone on and on about this like it will somehow turn bad programmers into world class experts. Memory safety is a good thing and compiler tracked object lifetimes are useful, but the Rust toolchain has so many other problems that it's basically unusable in the niches where it makes the most sense. Not to mention that its killer feature exists mostly for performance reasons (vs. using garbage collection) and yet its performance is extremely underwhelming.