Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why You Should Not Use Tcl (1994)

groups.google.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Why You Should Not Use Tcl (1994)

#21

Post by constantcrying »

thomasahle wrote: post #3
aragonite wrote: post #2

See also Ousterhout's reply: https://groups.google.com/g/comp.lang.tcl/c/7JXGt-Uxqag/m/vQ...

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 alone has very severe shortcomings, that make it totally unsuited for stand alone development.

Re: Why You Should Not Use Tcl (1994)

#22

Post by tverbeure »

d_tr wrote: post #17
tverbeure wrote: post #7

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…

I have hated industrial automation software from a particular manufacturer, but Structured Text, while a crappy language, was the least of my issues. The tools were really bad and the provided codebase amateurish. Maybe it's a similar situatuon with these expensive proprietary EDA tools often being quirky?

Proprietary and non-proprietary are quirky across the board. For any piece of software, you literally keep hundreds of official releases, sub releases and patch releases, and if the design support team knows what they're doing, they provide was to specify the right version for each design module.

I can live with it: these tools are very complex and they don't have a lot of users. It's hard to make the bug free.

But you don't make software buggy deliberately. It's different for Tcl. Some people made a conscious decision to create that POS language and others thought it was a great idea to add it to their software.

Re: Why You Should Not Use Tcl (1994)

#23

Post by f1shy »

thomasahle wrote: post #3
aragonite wrote: post #2

See also Ousterhout's reply: https://groups.google.com/g/comp.lang.tcl/c/7JXGt-Uxqag/m/vQ...

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…

Python is the glue. Many Python packages, which need performance, have big pieces in C. Just as he described.

Re: Why You Should Not Use Tcl (1994)

#24

Post by f1shy »

bdjsiqoocwk wrote: post #5
thomasahle wrote: post #3

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…

Stallman is always right, if you're willing to wait long enough.

Which means he is a real visionary, doesnt it?

Re: Why You Should Not Use Tcl (1994)

#25

Post by t43562 »

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 doesn't benefit from being compiled - that looks for a configuration file, reads and validates lines and calls functions to build initial datastructures...setup code, string handling. You save a millisecond or two by doing it in C++ but only once in a program that runs for hours - why waste all that dev/debug effort?

If you choose judiciously then you can end up doing a lot of your performance insensitive, setup-type code in TCL and a great deal of the time you'll be able to debug and fix bugs in an interpreted language without recompiling anything.

2. Python, though great, has a global interpreter lock. TCL fits in with threaded programs excellently. This can be a make-or-break feature.

3. TCL's syntax which I dislike, seems to map excellently into C - calling C from TCL just seems a lot easier than in python.

Re: Why You Should Not Use Tcl (1994)

#26

Post by IshKebab »

sitkack wrote: post #18
tverbeure wrote: post #7

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…

I understand how you feel, but if EDA had settled on Python, many of the same things we see would still be prevalent. They would be slightly reduced due to Python being a slightly less dynamic language than TCL but I am not sure it would matter. The problem with EDA automation software is that it has been historically written by people with low skill in software development. Their domain of expertise is hardware. The…

I dunno I think the actual EDA tools are pretty good (I've used VCS and Questa mostly). Bugs are quite rare, the GUIs are pretty sophisticated and surprisingly usable given how niche software it is. They're even starting to support recent OSes (though you have to use the lowest common denominator so we're still on RHEL 8).

I think they mainly just don't really care about improving the scripting interfaces. TCL is an industry standard at this point and it is a shit language but it's not the main thing you're doing.

In my experience it's really the customers have low skill in software, so they won't even be asking for anything better than TCL. Hacky Bash scripts are the standard here so if anything TCL is an upgrade.

This is an industry where CI is a novelty. I still have to deal with people who think CI should be a very quick sanity check and the testing should mainly be manual.

Re: Why You Should Not Use Tcl (1994)

#27

Post by pjmlp »

tverbeure wrote: post #7

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…

It was great for us, AOL and Vignette back in 1999.

But it is also the reason why I don't use any dynamic language without JIT for production code, unless I have no say in the matter.

We took advantage of being a MSFT gold partner, moved into .NET when it wasn't yet known to the world, and our founders eventually moved on, and OutSystems was born out of our learnings.

Re: Why You Should Not Use Tcl (1994)

#29

Post by EdwardDiego »

constantcrying wrote: post #21
thomasahle wrote: post #3

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…

So many citations needed.

Re: Why You Should Not Use Tcl (1994)

#30

Post by stevekemp »

fithisux wrote: post #10

Tcl needs to change to a Lisp Like syntax and add a package manager to survive. My thoughts.

It's funny to read that comment, when the argument includes:

      Tcl has a peculiar syntax that appeals 
      to hackers because of its  simplicity. 
      But Tcl syntax seems strange to most users.
That could be used to describe (emacs) Lisp too!
Post reply on HN