[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.)

[blacksqr]

"What is Tcl"

http://wiki.tcl.tk/299

[lomnakkus]

If you take issue with my post, then please be specific rather than throwing a link to a big page at me.

Seriously, am I somehow supposed to divine your criticism of my post from that link?

[blacksqr]

I'm sorry you interpreted my attempt to provide you with additional information about why some people might see Tcl in a positive light as criticism.

[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.

[jerf]

If by the "ergonomics" of bash, e3b0c meant the interactive usage, I'd have to agree that bash is a much better interactive shell. Once you start programming it, though, it gets bad fast.

One of my heterodox opinions is that "shell" is actually two languages, an interactive language for moving around the system and executing commands, and a non-interactive language for programming system interactions, and they really shouldn't be the same thing because there's a list of things as long as my arm that should be one way for one case and the other way for the other. "Error handling", for instance, is an entire category on its own; what a human sitting at a shell wants and what a program wants are just night and day different, and at least one side is going to lose if you try to straddle the gap with one language.

[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.

[NoGravitas]

That's a ... terrifying way to think about HTML.

HTML is not a serialization of code objects. It is a document authoring format. The DOM is just a way of modeling the documents so that code can perform various transforms on them. But the document is the important part, not the model.

[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.

[arbie]

I have the great fortune of dealing with YAML every day. The sheer number of ways in which string literals can exist is eye-opening, as is the interpretation differences across libraries. That the YAML spec has not been updated in a decade is icing on top.

[crdoconnor]

I wrote this because while I like the basics of YAML, I think 95% of the spec is idiotic and needs to be tossed away:

http://hitchdev.com/strictyaml

Ideally there should only be one scalar type (strings), two ways to represent strings (simple | multiline), just one way to represent mappings and lists. No nodes/anchors, no "YAML is a superset of JSON" silliness and absolutely no implicitly typed scalar values.

[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.