41–50 of 55 posts
Earlier quoted context omitted.
So many citations needed.
For what specifically? Python is absurdly slow, for naive array task you can easily get a 100x to 1000x speedup compared to any native language. The GIL doesn't really help either... I think my comments are pretty well accepted and substantiated if you look at what people are actually using python for. Right now AI is big, Python is at the center of that, to glue C++ together...
I have to agree with RMS that 1994 Tcl was pretty terrible. I remember cursing the lack of structs while using it for a larger program. All of this has been largely fixed in more recent versions. On the other hand, 1994 Tcl/Tk was the best way to create simple user interfaces, and is (IMHO) much better than current tooling.
I have to agree with RMS that 1994 Tcl was pretty terrible. I remember cursing the lack of structs while using it for a larger program. All of this has been largely fixed in more recent versions. On the other hand, 1994 Tcl/Tk was the best way to create simple user interfaces, and is (IMHO) much better than current tooling.
It's worth noting that we're in 2024, not 1994. While it's true that writing extensions for Tcl is necessary for richer data structures, it's definitely not an impossible task. As a mediocre programmer myself, I've managed to write 15 extensions in the past year. I love Tcl and find its C API to be exceptionally well-written and user-friendly.
Earlier quoted context omitted.
For what specifically? Python is absurdly slow, for naive array task you can easily get a 100x to 1000x speedup compared to any native language. The GIL doesn't really help either... I think my comments are pretty well accepted and substantiated if you look at what people are actually using python for. Right now AI is big, Python is at the center of that, to glue C++ together...
Well you made a bunch of claims. So, any of them?
Follows from the others.
>Almost everywhere it is used (ML, Data Science, Scientific computing, etc.) it is used to call C or C++.
See the big libraries in those fields. Do you think tensorflow or numpy are native python. If you are using python for scientific computing you will be using libraries which call out to native code.
>The amount of serious Python software that doesn't makes extensive use of calling to other languages is very small.
Given the above and that Python is most prominently found in those fields it seems pretty certain. There is standalone Python software, but usually only as a replacement for shell scripts or for relatively small applications.
>Python alone has very severe shortcomings
To name a few: GIL, lack of common default types (e.g. C like integers), enormous interpreter overhead, no mandatory typing (which introduces a whole range of runtime errors impossible in strictly typed languages). These alone make it totally unusable for many applications, unless you call to an external library.
>that make it totally unsuited for stand alone development.
See above.
>Python is absurdly slow, for naive array task you can easily get a 100x to 1000x speedup compared to any native language.
Personal experience.
>The GIL doesn't really help either...
It really does not...
>Right now AI is big, Python is at the center of that, to glue C++ together...
See e.g. what numpy, tensorflow, pytorch are written in. Spoiler, the matrix multiplication isn't implemented in python.
My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passion. Other than that, it’s fine…
The other irony is, considering that article, that the Cadence analog tools (Virtuoso, Allegro) are using a nice Scheme dialect called "Skill" for that purpose. So not the whole EDA world is centered around Tcl.
I had to use TCL at a company where Prof. Ousterhout was on the board. I had used it a bit at university but I was coming from a Python job so, naturally, I hated its syntax BUT: 1. The project was in ancient C++ for many reasons and even the most modern C++ is at least 5x more difficult to write code in than TCL. So why write code that runs once in the life of the program in C++? There's often plenty of code that do…
Tcl's threading and event management are indeed standout features. It excels in threaded programs, thanks to its robust C API, especially functions like Tcl_ThreadQueueEvent ( https://www.tcl.tk/man/tcl9.0/TclLib/Notifier.html ).
I had to use TCL at a company where Prof. Ousterhout was on the board. I had used it a bit at university but I was coming from a Python job so, naturally, I hated its syntax BUT: 1. The project was in ancient C++ for many reasons and even the most modern C++ is at least 5x more difficult to write code in than TCL. So why write code that runs once in the life of the program in C++? There's often plenty of code that do…
At a former workplace we had a C/C++ application which allowed integration of customer code via TCL which worked well and had acceptable performance even with the TCL code in a hot path of the application code.
Inspired from this I once did a C/Perl integration, but the Perl code was minimal (just user exists with special case handling) and Perl is another language disliked by many today. But the program was written around the 2000 and Perl was more widespread without additional installations on the target systems and far better than any ksh/sed/awk combination.
But it worked well too.
[1] https://news.ycombinator.com/item?id=41006946
[2] https://www.maartenbreddels.com/perf/jupyter/python/tracing/...
Earlier quoted context omitted.
Ousterhout's main argument seems to be: > This is the proposition that you should use two languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions. Thankfully, today, we have great programming languages, like Python, tha…
>Thankfully, today, we have great programming languages, like Python, that people enjoy using both for large software systems Python is absolutely terrible to use as a stand alone language. Almost everywhere it is used (ML, Data Science, Scientific computing, etc.) it is used to call C or C++. The amount of serious Python software that doesn't makes extensive use of calling to other languages is very small. Python al…
Python seems to be used more often to call performance optimized libraries (NumPy, opencv, TensorFlow) and so on.
I have seen TCL and LUA more often used the opposite way around: A complied core (e.g. C or C++) which allows extensions to be written quickly in the scripting language.
Both seems to work well but the use case is a different one.
Of course, as programming language, Scheme is much better, and it is the language I use for day to day work. In that respect Stallman is right. However he missed a few important points and that is why Tcl is still so popular, probably more so than Scheme, if you just count users. Tcl didn't just bring a language to the table, it also has an excellent implementation which always was freely available and could be embedded into any software project. It has a nice range of very powerfull tools, Tk obviously the most fameous one. Still today it is one of the most popular GUI toolkits. And that is where Stallman with the GNU project failed. Had they at that time or in the following years provided a comparable Scheme implementation, it would have been extremely popular for application writers. Assuming of course, that it had been licensed under LGPL so that any application could use it. But it took most of the 30 years after this post for Guile becoming an option there.