
Where Tcl and Tk Went Wrong (2010) - smacktoward
https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/
======
tptacek
I spent a lot of time with Tcl, first at company some friends and I started in
the late '90s, and then at Arbor Networks, where I dragged it into their
service provider product.

In a Lisp, code is trivially parsed because everything is a tree of conses,
and the language derives tremendous power from that.

In Tcl, code is trivially parsed because everything is a string, and the
language is hamstrung by it; it's a little like trying to code a major project
in Bourne shell.

For a time, Tcl had the best C integration story of the scripting languages,
with a thoughtfully designed extension interface that was easy to use. But
every major scripting language has that now.

Tcl was early to what I guess I'll call mainstream metaprogramming (obviously,
Lisp got there first) with "upvar" and "uplevel" and [incr tcl]. But Ruby ---
which bears a lot of similarities to Tcl --- did all that stuff much better
and more cleanly.

~~~
mncharity
> a thoughtfully designed extension interface that was easy to use. _But every
> major scripting language has that now._

OP> Easily _embeddable_ /extendable.

Easily embeddable language implementations have regrettably remained more
uncommon. Sure, extending has gotten relatively easy, but it's still in that
"we own the world - you are welcome to visit, as long as you _fully_ respect
our partially-documented memory, stack, io, threading, whimsy, and other
disciplines" kind of way. And "feature: we're embeddable! (sort of, if you're
careful, sometimes, maybe)" toxic hairballs of surprise are still a thing.

~~~
rbehrends
Exactly. Tcl competes with Lua, not Python or Ruby. And Tcl and Lua both have
their respective advantages and disadvantages.

\- Lua has better support for handling non-trivial data structures, but Tcl
interop is a lot less cumbersome, as the host language only needs to know how
to pass strings back and forth, basically.

\- Tcl is more suitable for writing DSLs due to its homoiconicity, but Lua's
more conventional syntax is more suitable for traditional programming.

\- Tcl's command-oriented syntax makes it fairly easy to write an expressive
shell-like interface for your application (debugging, state inspection, expert
interface).

I'll note that via JimTcl [1], Tcl also has an additional niche for
bootstrapping software as a much saner replacement for /bin/sh programming,
such as in autosetup [2].

[1]
[http://jim.tcl.tk/index.html/doc/www/www/index.html](http://jim.tcl.tk/index.html/doc/www/www/index.html)

[2]
[https://msteveb.github.io/autosetup/](https://msteveb.github.io/autosetup/)

------
DonHopkins
I thought the time TCL went wrong was back in 1994, when Sun unilaterally
announced that TCL was going to be the official scripting language of World
Wide Web browsers, prompting RMS to kick off the TCL War by writing "Why You
Should Not Use TCL". [1] And then Sun changed their mind and decided that Java
was going to be the official scripting language of World Wide Web browsers.
And we all know how that turned out.

[1]
[http://vanderburg.org/old_pages/Tcl/war/0000.html](http://vanderburg.org/old_pages/Tcl/war/0000.html)

------
luckydude
We fixed the syntax problems if you like C better than Tcl.

[http://mcvoy.com/lm/L/L.html](http://mcvoy.com/lm/L/L.html)

Type checked, C like, structs, perlisms like if (buf =~ /re/), compiles to tcl
byte codes so that L can call tcl and tcl can call L, open source, liberal
license.

~~~
scriptproof
This seems to have evolved in Little. [http://www.little-
lang.org/](http://www.little-lang.org/) Or is it a different language? The
original name of Little is L.

~~~
luckydude
Same language, we called L because I'm Larry, then decided that was stupid and
renamed it little as in little language.

------
jrapdx3
As a long-time Tcl/Tk user it seems where some might think Tcl went "wrong"
was combining its Lisp-like semantics with C-style syntax. The "hybrid" was
confusing to many programmers, especially those coming from C and similar
tools.

The article mainly examines the corporate and marketing aspects of Tcl's
history, and not so much the technical merits of the language. True enough,
Tcl lost out to Java and other languages on that account but as the article
acknowledges Tcl still has quite a large community keeping it going.

On the technical side, the commentary about "everything is a string" has been
extensive discussed and IMO has been shown to be more than not a red herring.
In any case many of the "warts" that were prominent in 2010 have been at least
partially addressed. Notably in recent years Tcl as acquired many Scheme-like
features, an official OOP facility, and coroutines among other "modern"
features.

Tcl remains incredibly flexible and adaptable to diverse problem domains. I
wouldn't try to write a hardware driver in Tcl, but for many problems it's the
most productive tool in the toolbox.

------
makecheck
Tcl had been a pretty good way to create things like embedded command shells
for C-based programs, and this was great as long as people operated in fairly
sequential ways like “command1, command2, command3”.

The problems with Tcl start to show up when invariably somebody decides they
want something more logically complex than a sequence of commands. _Debugging_
Tcl is extremely difficult, which makes it a huge maintenance liability. For
example, a “line number” isn’t much help if the “line” refers to 90% of the
file and Tcl thinks all of that is essentially one statement (no matter how
many braces are in it). As another example, there are _tons_ of places where a
variable is referenced both like "$this" _and_ "this"; that is just a whole
series of accidents waiting to happen, especially when you consider that many
functions depend on argument order and they don’t necessarily produce obvious
malfunctions when variables are misused.

~~~
bch
> For example, a “line number” isn’t much help if the “line” refers to 90% of
> the file and Tcl thinks all of that is essentially one statement

I think this may have improved since you last looked:

    
    
      $ cat j
      #!/usr/bin/env tclsh
      puts [ set a [ expr { 9 + [set x]}]]
      $./j
    
      can't read "x": no such variable
          while executing
      "set x"
          invoked from within
      "expr { 9 + [set x]}"
          invoked from within
      "set a [ expr { 9 + [set x]}]"
          invoked from within
      "puts [ set a [ expr { 9 + [set x]}]]"
          (file "./j" line 3)
    
    

> there are tons of places where a variable is referenced both like "$this"
> and "this"

$this is essentially [ set this ], returning its value, or deferencing the
value, if you will. The entire set of rules that Tcl abides by are contained
entirely in a small document (here [0], with commentary). It's really not
difficult to figure out.

[0] [http://wiki.tcl.tk/10259](http://wiki.tcl.tk/10259)

~~~
makecheck
That trace is not as bad as I remember but if you write that in a nice long
multi-line series of if-statements (say) it’ll still print out the whole mess
and only tell you one useless line number. If there’s a "proc" it’s a little
better but it can only show the bad line number _relative_ to the "proc",
requiring you to do some manual work to find the function within the file and
then the offending statement line.

Also, I have no problem with the logical "$x" syntax; rather, the fundamental
flaw is that the _string_ "x" could be used to change the variable "x" without
_any_ clue in the syntax that this may happen (e.g. no "&x" like in C, no
"\$x" like in Perl; just "x", or worse "$y" that resolves to "x"). And don’t
even get me started on multi-level "upvar". This whole thing is a minefield,
especially if people use simple variable names that can’t be searched in a
code base. If you’re really unlucky, you accidentally swap the order of
parameters and it just so happens that your "$x" value is almost plausible so
you never notice the disaster you just created. It’s simply a “write once,
modify never” coding style: it saves the programmer 10 seconds and creates the
most brittle of code. I would never recommend it to anyone.

------
davidw
I wrote that... I think it's still pretty valid and encourage people to think
about some of the lessons rather than just like or dislike of Tcl.

~~~
dgsb
Hi David, Thanks for your article. As you chime here, do you think the dev
platform had also an impact on the language visibility (fossil vs github) ?

~~~
bonzini
Not David, but I think Tcl popularity was already going down way before GitHub
became as popular as now. Around 2005 most projects were on SVN, and Tcl was
already more or less "the language that you have to use together with Tk".

~~~
stevekemp
>Tcl was already more or less "the language that you have to use together with
Tk".

And "expect", which is the only reason I've ever touched TCL in my
professional career.

------
morganvachon
I'm not a programmer by any stretch, but back in the early 2000s I used Tcl/Tk
to create my own little scripts and utilities in Slackware, my everyday OS of
the time. It's simple to learn and use for the layman, but powerful enough to
do real tasks and automate workflows.

I have no real need for it these days, but I'm happy to see it is still in use
even if it's not as popular as it once was.

------
jpswade
Very little mention of Eggdrop.

Eggdrop was my first introduction to Tcl/Tk and though the learning curve was
harder than Perl, it was fascinating.

There was quite a lot to like about Tcl. Mainly that everything just worked.

Packages were solid, getting stuff off the web was easy.

It's a nice language. Try it.

~~~
jasongill
Between BitchX and Eggdrop development, I'd say that TCL was my most-used
language circa 1998-1999. Had totally forgotten about it until seeing this
post (for better or for worse!)

------
myspy
I'm having a look at Tcl at work due to legacy code and it's no language that
I find easily accessible. Especially when having not that much time and having
a large codebase.

The interpretation and the braces in braces parts are annoying. Not very
readable.

Modularization is not easy and other files can't be imported as fast as with
Python or ES2015.

Resources and tutorials are not readily available, there is no community I ran
into to ask stuff compared to the rest of the language world.

Finding a test framework or linting mechanisms is not easy either.

I'm no friend of Tcl at the moment, I'm not sure if that will change.

~~~
oblio
> I'm no friend of Tcl at the moment, I'm not sure if that will change.

Languages don't really seem to "come back" that much. At some point being for
too long out of the mainstream weighs against you.

~~~
santaclaus
> Languages don't really seem to "come back" that much.

Objective-C came back from obscurity with a vengeance.

~~~
oblio
Because Apple poured a 1 billion dollars into it and turned it into basically
the main programming language for 2 OSes.

------
tyingq
A fair amount of where tcl went wrong was the initial string type that
couldn't handle binary data. They did fix it, but the inability was a
showstopper for early adopters.

For strings, if a null was in the data, it truncated at that point, and there
wasn't an alternative type that could handle it.

------
cmacleod4
They're not dead yet :-) and a new book on Tcl just came out -
[https://news.ycombinator.com/item?id=14730316](https://news.ycombinator.com/item?id=14730316)

------
int_19h
Poor resource management model is my biggest personal turn-off. The post
actually mentions it when it talks about everything-is-a-string - the problem
with that approach is that handles for external resources are then also
strings, and this in turn kills any form of garbage collection (both tracing
and refcounting), because it is possible to construct a string that is a valid
handle out of various bits and pieces lying around. Thus, you have to manage
all resources manually. For a high-level scripting language, I consider that
unacceptable.

~~~
flafoar
I don't really have much of a need for garbage collection, but I did
investigate strong/weak references (which I would probably prefer over garbage
collection). See [http://wiki.tcl.tk/41605](http://wiki.tcl.tk/41605). That's
the best I could do with my limited knowledge of the Tcl internals. My
suspicion at the time was that if the Tcl core team really wanted to implement
strong/weak references, then they would probably be able to come up with a
proper way of doing that. And if they could do that they could do garbage
collection. But I don't really know ...

~~~
int_19h
I think the problem with such systems is that they have to contend with the
infinite varieties of ways references can be stashed away. When a local is
itself a reference string, that's well and good. What if it's a string that
has a reference embedded in it somewhere? But that effectively describes all
Tcl data structures...

~~~
flafoar
Yes, the way I was looking at strong/weak references was that strong
references could only be held as a value in local/global/class variables,
including in lists and dictionaries.

And converting a strong reference to a string would give you a weak reference.
So you wouldn't be able to, say, convert a list that included a strong
reference to a string, then convert the string back to list, and have exactly
the same list that you started with because the strong reference in the
original list would be a weak reference in the resulting list.

Strings can represent list and dictionary data structures, and combinations
of, but I'm not sure that strings represent all Tcl data structures in the
same way. I'm thinking of Tcloo and Tcl arrays - I don't use those and know
little about them.

------
TheAceOfHearts
I discovered Tcl and Tk a few months back. Spent a few days poking around and
experimenting. At first I was incredibly impressed, and amazed I hadn't even
heard of it before. But once I started digging deeper, the poor docs turned me
off.

If anyone is interested in seeing a recent app example, check out git-gui [0].
It's bundled with git.

[0] [http://repo.or.cz/w/git-gui.git](http://repo.or.cz/w/git-gui.git)

~~~
rkeene2
Could you provide more information on which documentation you found poor ? Tcl
certainly has a lot of it, in the official manual pages for everything as well
as the wiki.

~~~
TheAceOfHearts
Sure, but I'm mostly going from memory though.

I'm on macOS. Installing the latest version was confusing. There's a tcl-tk
package in homebrew-core, and a tcl package in homebrew-cask. The tcl package
is ActiveTcl. What's the difference? On the tcl.tk site, if you try getting
the binary it'll point you to ActiveTcl.

Diving into the wiki was very confusing. Lots of articles have comments by
random people, and it's not always clear if their comments are relevant or
outdated. There's dozens of links, and hard to discern which ones are worth
looking into. Lot of links are dead.

The differences between the different Tclkits is not obvious, too many
choices. And how do they relate to starkit? I think I remember having
downloaded an sdx compiled widget, and I couldn't find the sdx utility, so I
couldn't unwrap it.

Tons of dead links in the Great Unified Tcl/Tk Extension Repository [0].
Almost nobody puts up screenshots of their widgets.

It's also frustrating to find out that Tcl Dev Kit is a paid component. I'm
probably spoiled by other languages, so this might be pretty entitled of me,
but I'd consider the dev kit's tools to be essential. The most important tools
for me would be the debugger, linter, and inspector.

As a standalone user, I'm not going to pay $300 just to play around with a
programming language. It would be a huge improvement if they were made freely
available, even if under a non-commercial license. Then people can try it out,
and if they find a good use-case in their job, they might buy a license. I've
done that with other software. To give a concrete example: in a few college
projects and hackathons I used highcharts [1], a JS charting library. Since it
provides a free non-commercial license, I ended up learning how to use it
pretty well. Fast forward a bit, and the company I was with wanted data-dense
interactive charts. I evaluated a few options, but was most satisfied with
highcharts, so I happily convinced them to buy a license.

That's also similar to what Qt has been doing too, and it has been hugely
successful. You can use the free open source version, which is licensed under
GPL and LGPGv3. But if you want to keep things locked down, you can pay
~$3500/year for their commercial offering. Most humans probably won't pay for
the commercial version unless they're full time app developers, but businesses
tend to have much deeper pockets.

[0] [http://core.tcl.tk/jenglish/gutter/](http://core.tcl.tk/jenglish/gutter/)

[1]
[https://www.highcharts.com/products/highcharts](https://www.highcharts.com/products/highcharts)

~~~
rkeene2
This is great information. Thank you for putting it together I'll bring it up
on the Tcl'ers chat !

------
pera
I remember trying Tcl/Tk many years ago during high-school: the syntax was
interesting and building GUI applications was extremely easy. I don't know why
Tcl is not popular today, but there is one pretty cool Unix tool that
uses/extends it called Expect [1]

Expect lets you automatize user interaction with terminal applications. And
then there is DejaGnu, a testing framework, that uses Expect and Tcl. Probably
the most important software project using DejaGnu right now is the GNU
Compiler Collection. A not so significative project that also uses it is the
interpreter of my toy language :) it took me a little bit to understand how to
integrate it with Autotools but now I really like it (here is an example:
[https://github.com/pera/ad-
hoc/blob/master/testsuite/ahci/dg...](https://github.com/pera/ad-
hoc/blob/master/testsuite/ahci/dg.exp)).

[1] - [http://expect.sourceforge.net/](http://expect.sourceforge.net/)

[2] -
[https://www.gnu.org/software/dejagnu/](https://www.gnu.org/software/dejagnu/)

------
pjmlp
The first company I worked on was an heavy Tcl shop.

For me they went wrong on being a pure interpreted language, having to write
all performance critical parts in C wasn't scaling for us.

It was there that I learned only to use languages with JIT/AOT support.

Also having Tk stuck on a Motif look and feel wasn't appealing to us as a
mechanism to deliver good UI/UX to our customers, specially to the majority of
them on Windows.

------
neves
The greatest innovation of Tcl was how easy it was to extend with libs in C. I
still thinks that Tcl's author famous paper about using "glue languages" is
still one of the best ideas in software engineering.

Read about it in Ousterhout's Dichotomy:
[http://wiki.tcl.tk/9865](http://wiki.tcl.tk/9865)

------
KasianFranks
Beside Python, Tcl remains my language of choice when it comes to text mining
and ML/AI data engineering proof of concepts.

~~~
tejasmanohar

      Besides Python
    

So, when & why do you use Tcl over Python?

~~~
sigzero
Some of the UNIX systems I admin actually have Tcl installed by "default"
(Solaris and AIX) and no Python. So I use Tcl there when I want to do things
about shell.

------
gluczywo
Tcl is a great language and ecosystem. It fell victim to a few independent
political decisions that resulted in low popularity:

\- Sun's pushing Java and killing everything else

\- Stallman's distaste for anything non-GPL

EDIT: wording

~~~
luckydude
That's the first I've ever heard anyone say that Stallman had anything to do
with Tcl. Do you mean to imply that guile wouldn't exist if Tcl was GPLed? Or
something else?

~~~
sigzero
It's too hard to guess that even with hindsight. Stallman probably would not
have objected to Tcl at all if it was GPL and not BSD.

~~~
_delirium
I'm not entirely sure about that. While Stallman is most famous for his
license preferences, he has a longstanding, pretty strong pro-Lisp preference
as well, dating back to his early work on Emacs Lisp. Guile Scheme was created
as the official GNU extension language mostly because Stallman thought a
version of Lisp was the right language for a standard GNU extension language,
and Tom Lord convinced him that Scheme was the right version of Lisp for the
job. It wasn't a preexisting GPL'd interpreter that he just picked because of
its license.

~~~
sigzero
I was only talking to the point of Stallman dissing Tcl. Would Guile still
have happened? Maybe, and for the reasons you outlined.

------
systems
Tcl, is just not as nice a language as other dynamic languages

and it didn't have the ecosystem to justify it

I think Tcl fails on the basics, nothing too deep, subtle or obscure

------
samfisher83
Its used a ton in the EDA (Semiconductor) Industry. It has its uses for
scripting. Everything doesn't have to revolve around web programming.

~~~
PhantomGremlin
Decades ago Synopsys chose it for Design Compiler. Mostly Hobson's choice
(what good alternative did they have?)

But it was an awful language because it was so limited. Many commands in DC
naturally want to return objects. But those don't exist in Tcl (maybe they do
now?).

So DC had to invent "collections" to make up for the limitations. Which
confused the heck out of engineers. Resulting in Stack Overflow questions such
as this one:

[https://stackoverflow.com/questions/17864980/collections-
to-...](https://stackoverflow.com/questions/17864980/collections-to-list-in-
tcl)

So, yeah, EDA uses Tcl but its for historical reasons rather than because its
a good tool for that purpose.

------
neves
I had a little contact with the language. The article nails the biggest
problem with TCL:

"One actual technical problem that Tcl faces is the concept that all values
must be representable as a string. This is more or less ok for things like
lists, hash tables or numbers, but is problematic when the user wishes to
represent a value that simply isn’t a string."

~~~
wrenky
Thats actually not totally true. Internally, Tcl has two value types, string
representation and actual value representation. Everything DOES have a string-
representation though- some are made up (like file handles, fileX) and some
are just ASCII forms of the values underneath (like integers).

Tcl is cool because you can manipulate the string form of values incredibly
easily, but people confused this with "Everything is a string". It should be
"Everything can be manipulated like a string".

------
agumonkey
I used tkinter, after years seeing it in d2 nuke. It was very very
straightforward.

------
lucidguppy
Seems like the culture prunes back some languages and starts up new ones.

The only language that I think will escape this is JS due to the browser -
unless we make a new sandbox app container designed to run scripts (a la java
plugin).

~~~
gaius
In the near future - if not already - people will call writing JS without a
framework "bare metal".

~~~
lucidguppy
Are you referring to this talk?

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

------
lathiat
I got into Linux (and now a long systems administration career) quite
literally because I wanted to run eggdrop bots on a shell server. Programmed
in TCL :-)

Quirky bit of personal history that amuses me to no end.

------
dgsb
IMHO the lack of an official OO system has been one of the main drawback to
the language when at the same time python were rising.

~~~
bch
I can see that. There was (and is) a plethora of object systems, which could
be seen as a double (triple?) edged sword. It provided choice, with many
alternate features and methods (no pun intended), but perhaps at the expense
of developer clarity - which one best serves my needs? Will I end up in a dead
end? What are most others using? What serious problems might I be adopting?
The "third edge" though, is a positive, though took time to arrive: the TclOO
that was finally developed was informed by the technical and social impacts of
years of experience with various OO systems, and indeed emerged mature and
well-formed because of that. In fact, it was initially developed to only be an
underpinning for other flavours of OO sugar to be bolted on top, in support of
existing systems like [incr tcl] and Snit. It ended up being received as
system good enough to use directly, in it's own right.

~~~
dgsb
I've never have the chance to use the new core TclOO, but I really think
they've made mistake at that time by implementing another new object system
instead of promoting an existing one like [incr tcl] (even if not
perfect/incomplete).

~~~
bch
Certainly debatable. For those interested, see a description/discussion here
[0] and check it out in Tcl 8.6[1].

[0] [http://wiki.tcl.tk/18152](http://wiki.tcl.tk/18152)

[1]
[https://www.tcl.tk/software/tcltk/download.html](https://www.tcl.tk/software/tcltk/download.html)

------
igravious
Cuz no BDFL?

~~~
luckydude
I dunno why you got down voted, your point seems valid to me. Tcl thrived
under John, after him it was ok when Hobbs was the de facto leader, it's sort
of gone flat since he moved on. In my opinion.

~~~
ternaryoperator
Perhaps because lots of languages have done well without a BDFL. Look at the
top 10 languages in Tiobe or the RedMonk surveys, and the majority don't have
BDFLs.

~~~
igravious
Ok, let's do that:

    
    
        1	1		Java	12.961%	-6.05%
        2	2		C	6.477%	-4.83%
        3	3		C++	5.550%	-0.25%
        4	4		C#	4.195%	-0.71%
        5	5		Python	3.692%	-0.71%
        6	8	change	Visual Basic .NET	2.569%	+0.05%
        7	6	change	PHP	2.293%	-0.88%
        8	7	change	JavaScript	2.098%	-0.61%
        9	9		Perl	1.995%	-0.52%
       10	12	change	Ruby
    

Of TCL's brethren

Python, BDFL

PHP, BDFL

Perl, BDFL

Ruby, BDFL

The rest (even though you wouldn't compare them to TCL cuz they're not in the
same niche) have/had huge corporate sponsors and/or are entrenched industry
standards and have also had iconic/notable figureheads (Gosling, K&R,
Stroustrup, Hejlsberg, Eich).

~~~
chromatic
Perl probably shouldn't be in that list. It's arguable that Larry has had any
direct influence on it for at least ten years, perhaps 15.

------
gaius
More than anything, I would say that what "went wrong" is simply that the wind
changed. Tech is driven by fashion more than anything else, something becomes
"cool" and everyone scrambles to re-write perfectly good software in a new
language for no particular reason (other than keeping their CVs up to date).
Tcl is a powerful language that you can use to create complex systems with
simple code, the holy grail. But instead the industry took a massive step
backwards and said "event driven programming? let's use Javascript!"

~~~
toyg
Blame the browser. If Brendan Eich had tried to repurpose an existing language
instead of mashing together a new one; or if Microsoft had used their de-facto
monopoly in early '00 to push abetter language, JS wouldn't be as big as it is
today.

~~~
sametmax
This I'll never understand. Why, for god sake why, did he had to create such a
terrible scripting language while he had plenty of great open source existing
ones ? I mean:

\- lua appeared 2 years before

\- python 5 years before

\- perl 7 years

Instead we have this monstrosity with no namespace, terrible error handling,
pitiful stdlib, limited expressiveness, atrocious data structure and type
handling, so full of traps and gotchas we had to write a book about the part
of the languages not to use.

~~~
peatmoss
I've read that he'd wanted to just use Scheme, but that they needed the
language to have "Java" in the name, as well as curly braces. So, we got
Javascript.

Also, given that DSSSL was an early contender against CSS (and a great deal
more powerful), we could have basically had Scheme there too.
[https://blog.cloudflare.com/the-languages-which-almost-
becam...](https://blog.cloudflare.com/the-languages-which-almost-became-
css/?f)

Lastly, because S-expressions can represent everything that is representable
in SGML/XML/(X)HTML, but more succinctly, we could have basically had Scheme
instead of HTML.

Imagine if, instead of JS/HTML/CSS, we had... Scheme. I'm pretty sure that the
alter universes where this happened also all have peace, warp drives, and
working cold fusion.

~~~
mncharity
> Lastly, because S-expressions can represent everything that is representable
> in SGML/XML/(X)HTML, but more succinctly, we could have basically had Scheme
> instead of HTML.

I suggest (along with David Moon (Lisp Machine)) that a key disadvantage of
sexp with respect to *ML, is that there's no place to hang on "extra stuff".
Many lisps allow you to decorate the nodes with properties once the nodes are
read, but the properties lack a printed representation. It's a homoiconicity
fail. Sort of like not allowing comments in JSON might be, if a common case
was then to attach comments to the objects after they're loaded. That very
isn't common, so the restrictiveness is worth it. It's not clear that's the
case with sexp.

