Quote:
Originally Posted by Another Kevin
I started replying to the screeds that Tcl is objectively bad, but decided that the posting was getting far too long for the forum, and dropped it over at http://dftscript.blogspot.com/2010/0...different.html instead.
The elevator-speech summary of the posting might be, "I happen to like Tcl, because it suits the way I think. If you find it unfit for purpose, I'd be happy to recommend other languages that I also use. Don't go calling it 'objectively bad' without data to support your claims."
|
You mention "objectively bad" in your blog, and the words belong to me. But I said TCL was objectively bad not for the reasons you stated:
Quote:
Last night, a colleague pointed me to a thread on linuxquestions.org that begins with a misunderstanding of how data are interpreted in Tcl, and diverts into a screed that Tcl is "objectively bad."
Fundamentally, the original misunderstanding appears to be one of notation. The original poster complains how Tcl is 'clumsy in dealing with binary data.'
|
I'm saying it is bad because it a true source code
interpreter.
...
You further quote me:
Quote:
Well, TCL is an objectively bad language because it is (used to be ?) a true source code interpreter. So, syntax errors are not found until containing them code is executed.
For example, in VLSI synthesis may take several days, and it's quite a pity if the whole process ultimately fails because of a silly syntax error at the script end.
That's why static TCL checkers have been invented ...
"Objectively bad?" Oh, my.
Given that static Tcl checkers like Nagelfar do exist, most of that poster's screed can be reduced to a complaint that Tcl doesn't force you to use them
|
No, I'm saying
TCL is bad by design. I.e. make that static checker part of the process - like in Perl/Python/Ruby. For that matter, Matlab/Octave/Scilab languages are
bad by design too. Because they are true interpreters.
...
If we are talking about strongly typed vs dynamically typed languages - both TCL and Perl 5 are
bad by design. Because they do not offer a choice (well, in Perl 5 there are attributes which can be used to imitate type checking at runtime).
For that matter if/when Perl 6 is out, it will be a better choice, because it offers a choice, i.e. the programmer can declare a variable as typeless or typed.