
The Tcl War (1994) - akkartik
http://vanderburg.org/old_pages/Tcl/war
======
Paul_S
1994? How about 2016 and I'm still living in a nightmare - my company uses tcl
("legacy" scripts). No matter how many times I tried to approach the language
with an open mind there is no other language that grinds me down as much. If
you think passing a variable name in a string to a function and then using
upvar to access it is an acceptable way of returning values then have I got
good news for you - we have languages with a sane way of doing it today (heck
we've had them for longer than tcl has been around for)! I die every time I
have to look up which order arguments come in because of how inconsistent it
is, and oh, is it append or lappend or some other crazy keyword? People at the
office had this for decades and they still have to use a cheat sheet. Why...
There's perl, python, bash, anything god, please, make it stop.

~~~
jt2190
[Warning: Personal anecdote... somewhat off topic.]

Around 2003 I was getting very heavily into what we used to call "Dynamic
HTML", which of course required programming in JavaScript. At the time
JavaScript was looked down upon by most professional programmers as a toy. A
toy that had buggy implementations in various browsers, that lacked the strict
typing of C++ or Java, that didn't have classical inheritance, that had no
good IDE, and, worst of all, that you could create some terribly confusing
bugs with.

At the time I'd moved to Fort Worth which let me attend the monthly Pragmatic
Programmers meetings/dinners at Spring Creek Barbeque in Addison, TX. This was
a meeting with a lot of polyglot programmers and "old timers", and there was a
prevailing attitude that programming languages were just tools, and a good
programmer learned to use many tools well.

Anyway, there I was one night ranting about JavaScript to someone I only
remember as Chris. I probably chewed his ear off for a long time about how
terrible JavaScript was. After what I'm sure was many minutes, I paused to let
Chris tell me how much he agreed that JavaScript was terrible. Instead, he
simply said: "You need to learn about prototypical inheritance."

This caught me off guard. I don't remember if it shut me up, but I hope it
did.

Fortunately I actually took Chris' advice. While I'd understood that
JavaScript had prototypical inheritance, I'd never really taken the time to
understand how it really worked. I'd also never really grokked how scopes
worked. As I properly learned these features, I started to gain a new respect
for the power of the language, and it quickly became my favorite.

So, now when I have a strong negative reaction to a new language or tool, I
ask myself if I'm reacting because of a fault in the language or if I just
don't like that feeling of being less productive because I haven't _learned_
the language yet. Usually it's the latter, which means I need to grit my teeth
and bend my brain and learn.

(P.S. Chris, if you're reading this: Thank you! I owe you a millions lines of
code in grattitude!)

~~~
glv
I'm pretty sure that was Chris Morris. (He and I were both regulars at that
group.)

~~~
jt2190
Hi Glenn :-)

I could have sworn it was a _different_ Chris. I remember someone with black
hair. He may not have frequented the meeting as much, because I don't remember
seeing him again after that.

(P.S. I've updated my profile.)

~~~
glv
Ah, OK. (And yes, I remember you. You ran the FW JUG for a while?)

~~~
jt2190
Yes, that was me.

------
drdoom
I have used Lisp, Scheme, Prolog (and multiple dialects of each) for extended
periods in large projects. Each was a pleasure to work with. They all have
their own advantages. I am not sure if there is value in arguing over x
feature of one language vs. y of another. As a matter of fact, it was fun to
write Prolog interpreters in Lisp, and Lisp interpreters in Prolog, for
example. (Many courses / textbooks (used to) present these as side projects to
do and the task is simpler than it sounds.) One could say Tcl is really an
extension of Lisp or Prolog in its core concepts of syntax, data and program
equality, style of interpretation, etc.

I agree wholeheartedly with the last paragraph of Mr. Ousterhout's reply here
- and I must say, a smart, classy and almost Tcl-ish way of a jab at its
distractors:

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

I came across Tcl/Tk while doing Motif in a large C-based project. I simply
couldn't believe how powerful, simple and succint Tk was compared to Motif (or
anything else since). And it ran on Windows, Unix, Linux and Mac OS, to boot.
It was too late for that project to switch, but all my other projects have
used Tk if they ever needed a UI.

Similarly with Tcl. I still think the best introduction is Mr. Ousterhout's
original Tcl/Tk book. It stands as one of the best language books on my shelf.
Combined with Tk, one can put together a working application prototype in no
time.

Of course, this was eons ago. Nowadays, Tcl offers one of the best
environments with a complete set of packages ranging from web servers to image
and sound processing. Plus, you can distirbute your program and all of its
media and support files easily as well.

I believe Tcl has been mischaracterized and has suffered in terms of open
popularity. But for insiders, it remains as one of those secret indispensable
Ninja tools that is used over and over again for competitive advantage.

~~~
Drdrdrq
A bit off topic: did you really use Prolog for something else than just
research? That is, did you write software that was used in production? I have
learned it many years ago but always had a nagging feeling that it is better
to use a "normal" language with AI libraries if you need the program to
actually do something... Did I miss anything?

~~~
drdoom
Most of my Prolog experience was in academics - for my own research as well as
for maintaining some existing packages. But I did get to use it outside as
well. There are many cases where a controlled language is needed or comes in
handy and solves a lot of issues. This is where Prolog shines - plus you get
to use a lot of the previous stuff you developed as well.

When it comes to an "AI" language vs. typical language with an "AI" library, I
will just repeat a phrase that is often used in the field: what you thinnk of
as an AI problem today will no longer be considered AI tomorrow, since it will
then be well-understood and implemented in many places. People used to say
that in response to the (seeming lack of) progress AI had made to date. A good
example of that is Siri or Amazon Echo. Not many people consider it an AI
problem anymore, or so it seems.

------
amelius
See also "Tcl the Misunderstood" [1]

An interesting discussion here: [2]

[1]
[http://antirez.com/articoli/tclmisunderstood.html](http://antirez.com/articoli/tclmisunderstood.html)

[2] [http://lambda-the-ultimate.org/node/3891](http://lambda-the-
ultimate.org/node/3891)

------
networked
Note that RMS almost certainly did not write the inciting post [1][2].

[1] [http://lambda-the-ultimate.org/node/3891#comment-58302](http://lambda-
the-ultimate.org/node/3891#comment-58302)

[2]
[https://web.archive.org/web/20110102015130/http://basiscraft...](https://web.archive.org/web/20110102015130/http://basiscraft.com/0800-0100-the-
tcl-war.html)

~~~
hyperpape
Dunno if I'm dense, but reading that second post, I can't figure out if he's
saying Lord's name was attached to RMS's post, vice versa, or some third party
attached both of their names.

I'm guessing you mean it's the second possibility, but I can't figure out how
you get to there from reading it.

~~~
glv
Two things about it make me think that RMS actually wrote it (probably after
consultation with Lord). The first is this sentence in that post by Lord: "Who
cares if a post occurs under my name that I didn't post so long as I more or
less agree with it -- this isn't about ego."

The second is writing style. The Tcl War post is classic RMS. Compare it to
this reminiscence from Lord and it's hard to imagine they were written by the
same person.

~~~
networked
When I wrote my comment above I skimmed through Thomas Lord's essay, found
that the parts I remembered being there were all in their place, pasted the
link and pressed "submit". In particular, I remembered the paragraph from
which you quote as written in a ironic manner, suggesting with a wink at the
reader that Lord actually wrote the post. Now that I've reread the essay, I
don't see that at all. I think in that paragraph he probably says what he
means. That, and you are right about the style.

In short, I retract my claim. Sorry to whoever I misled! My confidence was
completely misplaced.

~~~
gnufx
I should be wary of the account anyhow. For calibration: it's just false to
say egcs was due to "friends of Cygnus" and "hostile"; it was friends of GCC
with the intention it should turn out as it did, happily.

I can't find anything archived to check but, as I recall, Lord later posted a
bizarre sort of semi-retraction in rms' name, and rms fired him soon
afterwards, possibly as a result. Perhaps that's partly a source of rms-
didn't-write-it ideas? I don't remember the suggestion at the time.

------
rwmj
Having spent the past few weeks debugging a Gtk application, Gtk is such a
step _backwards_ from Tk. It's so difficult to predictably lay out a Gtk
application in code, things which Tk solved with the beautifully elegant pack
and later grid models.

The Tcl language OTOH .. awful once you tried to do anything mildly
complicated.

~~~
ArkyBeagle
Depends on what you mean by "complicated". My habit is to lay things out in
event cross state and for that, it's pretty even. IMO, FSM are awfully good at
reducing/decomposing complexity. An FSM in Tcl may look like:

array set FSM {

init {

    
    
        ... 
    
        set state two 

} two {

    
    
        ...
    

} }

...

set state init

...

eval $FSM($state)

I have just put together too many things that would have been severely
daunting in any other way in this manner to agree with you.

------
_ph_
I both like to use Tcl and Lisp. Tcl and Tk I use for smaller tools and Lisp
for larger application programming. While the Tcl syntax indeed is a big
rough, its also very simple - I can strongly recommend to read Ousterhouts Tcl
book for insights. It is also remarkable, that Tcl is one of the few languages
that like Lisp allow the user to define arbitrary syntax elements (e.g. you
could rebuild if, for, ...) in the language itself. This is a very powerful
feature which allows you to create new abstractions the original language
designer did not build in.

Beyond that, Tcl comes with a rather complete runtime, and using tclkit, you
can very easily create standalone and small (<2M) installation-free packages
out of your program. This is very valuable, especially if you have to
distribute to Windows. This is where Tcl easily pulls ahead of a lot of
languages.

And often I use Tk for the user interface of my Lisp programs via Ltk, which
brings both together.

------
glv
Heh. In a recent overhaul of my site, I considered taking these pages down.
But they do still get a reasonable amount of traffic, and I hate broken links.

Thanks to amelius for the "Tcl the Misunderstood" link. I agree with that, for
the most part. I haven't written Tcl in many years, but I don't think it
deserves the reputation that it has.

------
jrapdx3
To my mind, there's a tremendous irony in the 1994 flame war. A user of Tcl
since the 1990's I'd read, and been amused by, the hyperbole contained in
those long-ago comments a number of times. Not that flaming doesn't still
happen, such emotion isn't hard to find, though the subjects in dispute vary,
the form of battle remains the same.

Goes without saying that there's a nub of truth in those ancient rants. Tcl
can be kind of hard to catch on to, but then again, the Gnu "replacement", the
Guile implementation of Scheme, is also hardly a mainstream favorite. Plenty
of hate is expressed toward Lisp-derived fully parenthesized languages, Scheme
included.

The not-so-dirty secret in the "language war" is that Tcl is itself very much
a Lisp-like language, and over the years has increasingly adopted many
features that make it even closer to languages like Scheme.

Having become reasonably fluent in both Tcl and Scheme I see similarities that
outweigh syntactic differences. Not identical of course, but translating
programs across them is fairly straightforward compared to C-like code, e.g.,
Javascript.

Maybe Lisp derivatives are an acquired taste, or maybe there some inborn
twisted brain thing that entices some and repels others. At any rate, I'm
convinced Tcl and Scheme are very capable languages, admittedly different in
approach vs. more commonly used systems. Looking back it is ever so obvious
that the old war was fought between two sects of the same tribe, and isn't
that often the source of the fiercest rivalries.

------
DonHopkins
Around the time leading up to the TCL war, Lua was peacefully and quietly born
in a manger at the Pontifical Catholic University of Rio de Janeiro, Brazil:

"In 1993, the only real contender was Tcl, which had been explicitly designed
to be embedded into applications. However, Tcl had unfamiliar syntax, did not
offer good support for data description, and ran only on Unix platforms. We
did not consider LISP or Scheme because of their unfriendly syntax. Python was
still in its infancy. In the free, do-it-yourself atmosphere that then reigned
in Tecgraf, it was quite natural that we should try to develop our own
scripting language ... Because many potential users of the language were not
professional programmers, the language should avoid cryptic syntax and
semantics. The implementation of the new language should be highly portable,
because Tecgraf's clients had a very diverse collection of computer platforms.
Finally, since we expected that other Tecgraf products would also need to
embed a scripting language, the new language should follow the example of SOL
and be provided as a library with a C API."

[http://www.lua.org/doc/hopl.pdf](http://www.lua.org/doc/hopl.pdf)

------
NelsonMinar
The Guile vaporware was the first time I really lost respect for Stallman and
the FSF. It's incredibly damaging to say "don't use TCL use Guile instead" and
then never actually produce a useful Guile product. A similar pattern happened
in the same timeframe with the Hurd kernel.

I have an enormous amount of respect for the FSF. But it has been most
effective when it has working code, like gcc or emacs. The political
pronouncements not backed up by working code were actively harmful.

~~~
dleslie
IIRC, GnuCash and LilyPond use Guile. The project itself now has some good
maintainers, and has been making strides since its 2.0 release. Some parts of
the (small) Scheme community have taken notice, and new projects are popping
up; like GNU Artanis[0].

Oh ah, and there's Guix[1].

0: [http://web-artanis.com/](http://web-artanis.com/)

1: [https://www.gnu.org/software/guix/](https://www.gnu.org/software/guix/)

~~~
groovy2shoes
For a long time -- until Andy Wingo took over development -- Guile was kind of
a joke of a Scheme. It was horrendously slow and buggy, and it was updated
very infrequently. Since Andy took over, it's quickly become one of the better
choices for Scheme. Guile 2.0 is solid and reasonably fast. The 2.2 release is
shaping up to be even better and even faster. Andy has done a great job with
it, and he keeps his blog[0] updated with a lot of interesting posts about
Guile internals and development.

[0]: [http://wingolog.org/](http://wingolog.org/)

~~~
NelsonMinar
I appreciate the irony that TCL is basically a dead end but Guile development
continues. Thanks for giving context for why!

------
B1FF_PSUVM
tl;dr: John Ousterhout's reasonable reply:
[http://vanderburg.org/old_pages/Tcl/war/0009.html](http://vanderburg.org/old_pages/Tcl/war/0009.html)
, done

(Submitted page looks like an Usenet Who's Who index ;-)

~~~
shitgoose
yes, he is good. this is my favourite part:

"I didn't design Tcl for building huge programs with 10's or 100's of
thousands of lines of Tcl, and I've been pretty surprised that people have
used it for huge programs."

lots of Tcl criticism stems from the fact that people started using Tcl not in
the way it was intended.

~~~
ArkyBeagle
I have trouble finding things that require more than 10kloc of Tcl but Tcl has
been extended since Osterhout sorta faded on it.

It has features like namespaces and package management since at least 8.x .
Language comparison is always challenging. I've had less trouble with Tcl than
with just about any other language. But it rather requires thinking about the
problem in certain ways. The main thing it requires is adherence to an event
driven model.

------
gaius
Posting on a newsgroup for X that X sucks is the _very definition_ of
trolling. Since long before it came to mean "anyone who disagrees with me for
any reason".

------
agumonkey
Dived into tcl wiki after writing a program with tkinter (tk python bindings),
it's amazing to see a community speak about other paradigms. Reading how they
approached FP idioms for instance. I felt this way with perl too. These are
two old languages that are mostly ignored nowadays (except for the perl6 has
shipped) but they have very interesting ways.

~~~
david-given
If you're interested in Tcl, you might also like to look at TH1:

[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md](https://www.fossil-
scm.org/xfer/doc/trunk/www/th1.md)

It's a tiny Tcl subset, implemented in only a few kloc. It's used by Fossil as
a HTML templating engine but it's easily adaptable for other things. It's
small enough to be understood and does an excellent job of demonstrating the
core principles of how string-processing languages think.

~~~
bch
@david-given probably knows this, but that TH1 is Tcl-ish is no surprise,
given fossils founder/principle author is drh (Richard Hipp).

drh is a former Tcl Core Team member[0], and probably most famous as the
author of Sqlite, originally a Tcl extension that "escaped into the wild"[1].
Sqlite also has a comprehensive test-suite written in Tcl[2].

[edit: footnotes]

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

[1]
[http://www.sqlite.org/src/doc/trunk/README.md](http://www.sqlite.org/src/doc/trunk/README.md)

[2] [http://www.sqlite.org/testing.html](http://www.sqlite.org/testing.html)

~~~
agumonkey
How fun is history sometimes, would never have thought sqlite wasn't a
"standalone" first project.

------
blacksqr
It so happens that the 14th annual European Tcl/Tk users conference just took
place [1]. Quick perusal of the event site shows the breadth of uses Tcl is
still being put to (enthusiastically, by programmers who choose to use it):

* nuclear power plant operations

* high-performance visualization and analysis of microscopic images.

* design analysis of high-resolution camera light sensors.

* embedded programming of Cortex-M3 ARM v7-Microcontroller.

* satellite control systems.

* multi-platform/compiler automated C++ library compilation.

* customization of the Fossil VCS.

* scripting and visual programming on Android.

* communicating sequential process programming.

* Linux D-Bus scripting.

Slag Tcl all you want, but it's still being used every day by brilliant
programmers to ship real products, in environments where reliability is
crucial. How does Guile stack up to that? Or any other unfashionable
programming language for that matter?

Maybe more effort should be put into understanding what these programmers see
in Tcl that the critics can't.

[1]
[http://www.eurotcl.tcl3d.org/index.html](http://www.eurotcl.tcl3d.org/index.html)

------
qwertyuiop924
Coming in from the harsh fronts of YouTube, Reddit and 4Chan, this is an
awfully tame flame war.

In any case, a lot of good points are raised by both sides. As an Emacs user,
I appreciate Stallman's points, but he does make a fatal mistake, in that he
doesn't include popular extensions like itcl in his evaluation. That's like
evaluating lisp without considering popular macros, or the potential of
macros. While that doesn't alleviate the problems Stallman has with tcl's lack
of datastructures, those are not insurmountable with a couple of well-written
C-extensions, assuming that tcl's C interop is any good at all.

Also, tcl is a pretty terrible lisp, as although they have a lot on common,
the differences are substantial enough for fans of one to have some degree of
distaste for the other.

The most entertaining part is that Stallman criticises tcl for lacking common
datastructures, being slow, and having bizarre syntax that appeals to hackers
alone. ESR (and, I believe, Stallman, although I am unsure), goes on to note
the common use of dynamic scope, confusing quoting mechanism, and the horrors
of upvar and upvalue.

Gee. DOES THAT. SOUND. FAMILIAR?

If it does, it's because most of those problems also appeared in MacLisp, the
direct predecessor to Common Lisp. Many of them also appear in other lisps:

Linked lists, an unusual datastructure, are one of the few well supported by
Lisp. Lisp used to be quite slow, and many implementations still are. Dynamic
scope is still the default in elisp, and macros just barely hold the system
together when you're writing lots of code, a cicumstance that Stallman claims
elisp is actually better in than tcl. As for confusing quoting, `(there ,(is
'quite) ,@(a lot) of that in lisp). And upvar and upvalue are in some ways
less dangerous than macros.

Actually, lisp used to have its own version of upvar and upvalue, coupled with
a mechanism called the fexpr that let you get rid of a lot of the quotes.
These were not implemented in most later lisps, due to the fact that they are
nearly impossible to optimize well.

At the end of the day, whether you love or hate tcl and lisp, there are people
out there that are stuck using far worse extension languages. Like these poor
sods:
[https://gitlab.com/xonotic/xonotic/wikis/QuakeC/Introduction...](https://gitlab.com/xonotic/xonotic/wikis/QuakeC/Introduction_to_QuakeC).

------
SixSigma
Inferno, the Bell-Labs system, uses a Tk implementation to lay out the UI.

[http://doc.cat-v.org/inferno/4th_edition/limbotk/](http://doc.cat-v.org/inferno/4th_edition/limbotk/)

------
vram22
There was an interesting article by Ousterhout (Tcl creator) about scripting
languages versus system programming languages some years ago. I think I read
it in one of the print computer magazines that existed at the time - Software
Development Magazine, Unix Review, Dr. Dobb's Journal, C User's Journal, or
some such. I wonder whether he was inspired to write that article after this
post (mentioned elsewhere in this thread):

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

~~~
bch
Are you referring to this:
[http://www.tcl.tk/doc/scripting.html](http://www.tcl.tk/doc/scripting.html) ?

~~~
vram22
Just took a quick look at it. Need to read more, which I will, but pretty sure
it is that one. I doubt he would write more than one article on that topic,
also it is slightly long (about 24 PgDn keystrokes on my PC :), which I
remember from before.

Excellent. I thought of googling for relevant keywords to check if the article
was online (after posting my previous comment here), but you saved me the
trouble. Thanks!

------
rurban
The guile history also mentions the TCL war from their point of view:
[https://wingolog.org/archives/2009/01/07/a-brief-history-
of-...](https://wingolog.org/archives/2009/01/07/a-brief-history-of-guile)
although it misses the important technical details. Stallman was right with
his criticism, but could of course convince nobody to add the missing
features. Some of them came with 8.5 eventually but support for lexicals
(upvar) is still horrible.

------
nurettin
>> It lacks arrays; it lacks structures from which you can make linked lists.
It fakes having numbers, which works, but has to be slow.

Did I miss the rebuttal to this?

~~~
glv
There was a semi-rebuttal … I think in a post from Brent Welch. Tcl does have
things called "arrays", and you use them much as you'd expect. Tom Lord
confirmed later that what he and RMS meant by this was that it didn't have
"true arrays" that are laid out contiguously in memory, to be much more
efficient. That's a valid criticism: Tcl's arrays are basically dual-use hash
tables, much the same as JavaScript's arrays.

The other two things are totally valid. Tcl has no references, so you can't
build your own linked list. And all values are (at least semantically)
strings, so numeric operations are slow.

But of course, a lot can be done to optimize those things in the
implementation, and over time at least some of that optimization was done.

~~~
ArkyBeagle
Lists are a first-class object in Tcl, so it's not clear to me how much of a
deficiency not having linked lists is.

I've had cases where opening a 'C' program as a pipe and doing heavy number
crunching in the 'C' program outperformed native Tcl.

~~~
kazinator
> _Lists are a first-class object in Tcl_

Was that the case in 1994, or are you writing about the current state of Tcl?

~~~
ArkyBeagle
I believe it's been true since the language first saw light.

I didn't get to it until around v7.x around 1995 and lists feature prominently
in Osterhout's book.

------
SFJulie
I love how RMS always begin is war on language with "it does not have a
LISP/scheme syntax".

University coders and their obsession of purity of syntax (map/purity)
superior to actually dealing with the true problem of the hardware is looking
(territory/practicality) is looking for me like an Aristolecian argument of
superiority of the style over the «getting things done».

Well, as spotted in the answers, expect is a nice non university bred
innovation (is it?) that is still a de facto standard in handling interactive
session (stateful) with a simple syntax that helps getting things done with
maintainable code.

It is ported in Perl, python ... and I think this is probably a point for what
Tcl is worthy : getting things done.

Practicality beats purity.

And as of today it is still the most portable way to write embeddable
graphical user interface that have good FFI.

~~~
agumonkey
Lisp is close to syntaxless. What "lisp syntax" means is principled to the
bones systems, including syntax. The fact that everything in lisp was in
recursively defined lists meant you could reuse recursive thinking everywhere.
An `infinite` tower of reuse. You get genericity, pattern matching,
combinatorial generation for very low cost. It's not practical for people
crunching data or opening files .. but whenever you need to attack something a
little more complex the 'practicality' argument shift sides.

~~~
lawpoop
Well, if he meant "it doesn't have S-expressions", he should have said that.
That's not an unreasonable expectation for a guy who is otherwise a pedant in
almost all other areas of his life.

~~~
agumonkey
Fair point, and to be honest, it's a common problem in many places. People
enjoying a property often fail to communicate it clearly with those who never
did. Math, and I believe Lisp has many times more inherited math genes than
other languages, is especially guilty of this. It's often a lethal cultural
shock.

~~~
eru
S-Expressions are fun. When I first learned a Lisp, Scheme in my case, I found
them weird but could see the appeal.

When I learned Haskell afterwards, it was the opposite: I thought I'd miss
S-Expressions, but I learned to like its more baroque syntax.

S-Expressions have the chief virtue of making even the most crude macro look
no different from the most over-engineered builtin to the language from the
user's point of view.

And they clearly separate the syntactical space in the language, so that new
features (whether as macro or built-in) can always find a space. Compare to
the cracks of C they had to fit C++ into.

Haskell might be even worse. The chief obstacle to adding OCaml or-patterns to
Haskell ([https://stackoverflow.com/questions/24700762/or-patterns-
in-...](https://stackoverflow.com/questions/24700762/or-patterns-in-haskell))
seem to be finding a syntax that's both pleasant and fits between the strands
of the fine web in ascii space of already valid Haskell programs.

~~~
qwertyuiop924
...And I never grew to like Haskell. The syntax makes all of your programs
look very elegant, but there are no clear delimiters. The syntax for how
functions are delimited isn't clearly explained by most sources. And I don't
want to type my code and just hope that the magical compiler fairies deduce my
meaning. That kind of programming attracts bugs like a man covered in honey.

~~~
gnufx
I don't know what that means, but if the objection is to layout ("the off-side
rule"), that's just an alternative to the braces and semi-colons that you'd
typically use if it was machine-generated, for instance.

~~~
qwertyuiop924
The objection isn't so much to the layout, as it is to the fact that I can't
find any documentation as to what the layout is and how the compiler
interprets it.

~~~
eru
Interesting. I've never bothered to look up the formal specs, but it was never
a problem that lead to an ambiguous interpretation of my programs. (I
sometimes write programs that the compiler doesn't like. But seldom once that
the compiler interprets different from me.)

I usually give types for my top level functions. It's good documentation, and
also prevents most of these kind of issues. (For a similar example, human
mistakes with operator precedence usually lead to compile-time type errors in
Haskell, seldom to runtime problems like in C or C++.)

~~~
qwertyuiop924
It's not a huge problem, but lack of understanding of how the compiler
delineates blocks of code makes the code hard to reason about. I like to know
what the compiler will do with my code, and what is and isn't valid through
something other than trial and error. Scheme's perfect regularity makes that
easy. Haskell... doesn't.

I am aware that the information exists somewhere, and I think I got a link a
bit back, so I'll have to go track that down. But it is absolutely baffling
that people don't discuss it more. Would you be able to write Python if nobody
told you about the indentation rules? Of course not.

I'll have to find that link...

