[crncosta]

The "everything is a string" mantra Will be back!?! The Millenial programmer will try to comment out a line of code while the TCL interpreter Will insists that is a validade code...

Come on guys, let some technologies dies peacefully, Ok? We don't want those days back :)

[klausnrooster]

http://antirez.com/articoli/tclmisunderstood.html

[lomnakkus]

I skimmed it very quickly, but quite a bit of that 'defense' of Tcl seems to be assuming that the problem with "everything is a string" is performance. It isn't.

There are very good reasons that stringly typed programming is frowned upon and 'performance' is very seldom one of them.

There's also seems to be a weird assumption that everthing-is-a-string means that you don't have to think about types. It's actually the exact opposite since now you don't have types for the compiler/runtime to help you to combine values in well-defined ways.

(I realize that the thing was written ages ago and we/the author may have learned a thing or two in the mean time.)

[crdoconnor]

The problem with stringly typed languages is that they don't fail fast or clearly. You end up having to spend more time debugging and diagnosing weird behavior when things go wrong and less time actually productively writing code.

This is a problem with weakly typed languages in general, but stringly typed is the nadir of weakly typed.

The problem increases geometrically with the size of the software system - you can't make building blocks to build other software on because the foundations are too unstable, so the only thing that really works is short programs that don't do very much - or, as some people put it, "toys".

He mentions strict format checks as a way to offset that, but I don't think that's nearly enough.

[kees99]

Not to disagree with you, but - what "modern" alternative would you recommend as a replacement for "wapptclsh", which is a compact statically-linked binary with wapp and sqlite libraries baked in?

Binary "wapptclsh" + your .tcl script + optionally .sqlite file, just 2-3 files are sufficient to make an app chroot/jail/container, if I understood correctly section 2.0 here: https://wapp.tcl.tk/index.html/doc/trunk/docs/compiling.md

[jerf]

For those concerns, I'd say Go. You can statically link in any pure-Go library trivially. SQLite specifically may require a C file because of its nature, but for accessing databases that take network connections there's a pure-Go driver for most things you've heard of, and there are other static database options for Go if you want them (though they tend more towards NoSQL; if that's really a problem personally I'd just bite the bullet and include the SQLite's library).

[e3b0c]

I think that both languages for the large and for the small have their own places. Something optimized for the large-scale doesn't automatically work well for the small.

For example, I always feel that Tcl is better than Python for GDB scripting. At least, I really don't like typing parentheses in an interactive console. Also, there is no 'real' (read: general purpose) programming language that is able to beat BASH in terms of ergonomics, even though we all know BASH sucks when the program is getting large.

[yoz-y]

At the risk of sounding like a broken record, I'll say that Perl is better than bash for BASH like stuff in every possible way.

[ams6110]

In html, everything is a string.

[jerf]

There's a standard serialization of standardized DOM objects in which everything is a string. But the fact that the serialization is a string isn't very interesting, because pretty much everything has a serialization or easily could easily have a serialization where everything is a string; the underlying capabilities of what is being described is the interesting thing, and is where all the differences between data types and formats arise.

[jimbokun]

But not every string is HTML.

[mhd]

I really liked programming in Tcl way back when. The ease of producing utility UI programs with Tk was a benefit even if the main part of the program was purely server-based (I used it for data management, reporting etc.).

And while the language had its warts, the syntax was relatively easy to comprehend, so even if things went southwards, it didn't take long to see where you made your mistakes. As long as you didn't upvar and uplevel the heck out of it.

Also very easy to create DSLs with it and drop down to C if you needed a function to be a bit faster.

Tcl would be a lot more popular if it weren't for Sun's divided interests, and if they managed to get something CPAN/GEM/NPM-ish up waaaaaay earlier.

[nazri1]

> Gitk was the first graphical repository browser. It’s written in tcl/tk.

Source: https://git-scm.com/docs/gitk

Actual tcl source: https://github.com/git/git/blob/master/gitk-git/gitk

[setquk]

I was quite happy with those days!

[pjmlp]

Me too, it was the foundation ground of our .com wave startup.

[teh_klev]

Well, at least you know for sure it is a string, unlike with a couple of languages I've had the misfortune to use in the past year or so where you really do need to check what the hell you ended up with ;)

[cjalmeida]

YAML can be pretty confusing at times.

[pjmlp]

TCL 8 changed that to bytes, if I remember correctly (too lazy to search now).

[bch]

Tcl 8 brought “dual-ported values” (among other things) to the table. Values were stored in “objects” (not to be confused with object-oriented programming objects) whereby the “string representation” was always available (“everything is a string” (eias) is a core logical tenet of Tcl, and has not gone away), and a “native representation” is available for (context-dependant) performance reasons. What does this mean? If you have “set a 0.8657309”, and do math ops with it, backing object will have a native float type available to do its work by. Previous to Tcl 8, the logical language promise of eias held, but the implementation within the Tcl interp was a char* array of bytes, too. That was a long time ago, though.