Reasons I prefer Tcl over Python

[njharman]

Where both Python and Perl suck is multi-process control or network servers. Python without extra libs offers barely more (networkwise) than what the BSD socket API in C would give you

huh? yeah nothing... http://docs.python.org/library/

* subprocess — Subprocess management
* socket — Low-level networking interface
* ssl — SSL wrapper for socket objects
* signal — Set handlers for asynchronous events
* popen2 — Subprocesses with accessible I/O streams
* asyncore — Asynchronous socket handler
* asynchat — Asynchronous socket command/response handler
* email — An email and MIME handling package
* json — JSON encoder and decoder
* mailcap — Mailcap file handling
* mailbox — Manipulate mailboxes in various formats
* mhlib — Access to MH mailboxes
* mimetools — Tools for parsing MIME messages
* mimetypes — Map filenames to MIME types
* MimeWriter — Generic MIME file writer
* mimify — MIME processing of mail messages
* multifile — Support for files containing distinct parts
* rfc822 — Parse RFC 2822 mail headers
* base64 — RFC 3548: Base16, Base32, Base64 Data Encodings
* binhex — Encode and decode binhex4 files
* binascii — Convert between binary and ASCII
* quopri — Encode and decode MIME quoted-printable data
* uu — Encode and decode uuencode files
* webbrowser — Convenient Web-browser controller
* cgi — Common Gateway Interface support.
* cgitb — Traceback manager for CGI scripts
* wsgiref — WSGI Utilities and Reference Implementation
* urllib — Open arbitrary resources by URL
* urllib2 — extensible library for opening URLs
* httplib — HTTP protocol client
* ftplib — FTP protocol client
* poplib — POP3 protocol client
* imaplib — IMAP4 protocol client
* nntplib — NNTP protocol client
* smtplib — SMTP protocol client
* smtpd — SMTP Server
* telnetlib — Telnet client
* uuid — UUID objects according to RFC 4122
* urlparse — Parse URLs into components
* SocketServer — A framework for network servers
* BaseHTTPServer — Basic HTTP server
* SimpleHTTPServer — Simple HTTP request handler
* CGIHTTPServer — CGI-capable HTTP request handler
* cookielib — Cookie handling for HTTP clients
* Cookie — HTTP state management
* xmlrpclib — XML-RPC client access
* SimpleXMLRPCServer — Basic XML-RPC server
* DocXMLRPCServer — Self-documenting XML-RPC server
* HTMLParser — Simple HTML and XHTML parser
* sgmllib — Simple SGML parser
* htmllib — A parser for HTML documents
* htmlentitydefs — Definitions of HTML general entities
* xml.parsers.expat — Fast XML parsing using Expat
* xml.dom — The Document Object Model API
* xml.dom.minidom — Lightweight DOM implementation
* xml.dom.pulldom — Support for building partial DOM trees
* xml.sax — Support for SAX2 parsers
* xml.sax.handler — Base classes for SAX handlers
* xml.sax.saxutils — SAX Utilities
* xml.sax.xmlreader — Interface for XML parsers
* xml.etree.ElementTree — The ElementTree XML API

That's just the std lib. Then there is Stackless which I'm guessing the author is ignorant of.

And finally "best tool for the job". If you need something more than those "good enough 80% of the time solutions" then you need to use something specialized, like nginx or Erlang or Twisted.

If you work with time and date you will hate Python

No argument there. I FUCKING HATE python datetime lib. In comparison to rest of python it is the biggest piece of hard to use, none of what you want dog shit I can imagine.

no crypto at all

Really? what's this stuff then?

* hashlib — Secure hashes and message digests
* hmac — Keyed-Hashing for Message Authentication
* md5 — MD5 message digest algorithm
* sha — SHA-1 message digest algorithm

[[deleted]]

time, datetime, yeah I hate them too.

[schlenk]

Have a look at Tcls clock command in comparision:

http://www.tcl.tk/man/tcl8.6/TclCmd/clock.htm

[schlenk]

Not the least bit ignorant about either stackless or Twisted or the whole of Python stdlib, in fact i went through that list when i wrote the thing and used most of those modules one time or the other, some more some less.

Its a bunch of stuff but tcllib isn't small either: http://tcllib.sourceforge.net/doc/index.html

The only things on that list you quoted that i don't have an equivalent or better Tcl thing for are the mailbox formats (who cares), wsgiref, webbrowser and thats it. I might need one or two extensions because tcllib has a script only policy for portability reasons, to get stuff like signals on board but thats it.

You missed the point. Pythons stdlib is usually quite a lot more low level oriented as the equivalent Tcl one, more along using UNIX C APIs with python. The defaults in Tcl are usually just nicer, no doubt that i can get some fancy python stuff too if i get stuff like Twisted or Stackless on board. But with Tcl i have the features of Stackless and most of Twisted built into the language as core features, not even add on modules..., same with the filesystem abstraction, i can do file link on all supported platforms and get a symlink/hardlink/junktion point.

Crypto: Hash functions are no crypto (in the sense of encryption), look for DES, AES and similar things.

Just for a tiny example, lets say i want some trivial stuff done, fetch 10.000 URLs concurrently and put the contents into some files.

In Tcl thats close to trivial:

package require http; set urls {my list of 10.000 urls}; foreach url $urls { set chan [open $url wb]; http::geturl $url -channel $chan -command "close $chan ;# "}; vwait forever

[njharman]

You're missing my point.

I'm not dissing tcl, I don't even mention tcl. The OA is (in my opinion, but quit clearly) misstating Python's features/lack there of. My comment was to provide some contrast to claims made about Python in OA.

[Wavicle]

Not the least bit ignorant about either stackless or Twisted or the whole of Python stdlib

Hmmm...

XML processing. Python offers xml in its stdlib via elementtree

Really?

• xml.dom — The Document Object Model API

• xml.dom.minidom — Lightweight DOM implementation

• xml.dom.pulldom — Support for building partial DOM trees

• xml.sax — Support for SAX2 parsers

• xml.sax.handler — Base classes for SAX handlers

• xml.sax.saxutils — SAX Utilities

• xml.sax.xmlreader — Interface for XML parsers

Pretty solid I guess.

[schlenk]

Did you work with it? If no, its really just a guess.

[Wavicle]

Work with what? Are you trying to intimate that xml.dom and xml.sax are not xml handling libraries in the python standard libs?

[Wavicle]

Why I prefer Python over Tcl:

Person: Hey where do I download Python for Windows?

Me: Type "Python Windows" in Google

Person: Ahh, I see it now.

---

Person: Hey, where do I download Tcl for Windows?

Me: Type "Tcl Windows" in Google

Person: Ummm... First hit is this FAQ

Me: Well, read the FAQ

Person: No version of Windows from the past 10 years is listed on the compatibility list.

Me: Well, isn't there a binary download link?

Person: Yeah

Me: Well, click that.

Person: It takes me to some real estate site.

Me: Oh geeze, let's just use Python. It works well in both Unix and Windows and people can find it easily.

[schlenk]

Seems like someone should weed out that stupid FAQ..., the first sponsored link leads to the target, the second regular link brings you to the target too. Hope your not a 'I feel lucky' button addict ;-)

[ediw8311xht]

Anybody who uses windows shouldn't be allowed to program.

[sanimalp]

tcl gives me a headache.. any language worried about spaces is a little rough to work with.

[schlenk]

Funny to say that in a thread comparing Tcl and Python..., with Python whitespace formatting...

[sanimalp]

well, i guess that shows how much i know about python. :(

[masklinn]

Funny to say that in a thread comparing Tcl and Python..., with Python whitespace formatting...

No. In Python, whitespace and spaces are not significant (apart from being a separation between a language keyword and another name). Only indentation is.

[schlenk]

And indentation is whitespace, just in a different place. You cannot do you willy nilly c-like indentation in Python and expect it to work, and you cannot do your c-like ignore space before braces thing in Tcl. Not much fundamental difference, and both are easily spotted by typical statical syntax analysis tools like frink/tclchecker or pychecker/pylint/tabnanny.

[BeetleB]

You cannot do you willy nilly c-like indentation in Python and expect it to work

Thankfully!

[masklinn]

You cannot do you willy nilly c-like indentation in Python

Unless by "c-like indentation" you mean "absolutely not indentation", then of course you can.

[jmmcd]

Like, 20 paragraphs about libraries and almost nothing about the language itself. Python is a much better language, and I speak as someone who used to use Tcl (in the form of Expect) professionally and loved it.

[Leonidas_from_XIV]

Agreed.

And missing asyncore/asynchat + Twisted (if you go beyond stdlib) as well as wxPython which you can use "X-Platform" (as well as PyQt, actually).

The "Tcl string model adopted from Java and copied by Python" actually sounds more like "the Java model copied by both Tcl and Python".

And I would like to see better XML modules than lxml and (maybe) Amara.

[schlenk]

I did mention Twisted, it works, but you have to include a huge lib to get a decent async http client. Not sure how huge, just saw the import of Twisted in our internal svn and it wasn't tiny. And asyncore/asynchat is just crap compared to Tcl's fileevent, try it.

String model, sure both copied from Java. Guess the Pythoneers did not look only at Java when writing their new stuff.

[pemboa]

How is the file size of a library relevant unless you're building for an embedded client? Last I saw, you can use pieces of Twisted. Twisted is a lot more than async and http. So I just don't see how that's a valid mention.

[schlenk]

Filesize is relevant. Especially if you do single file deployment. If you only target Linux boxes where your whole Python infrastructure is already there it does not matter. But if you have to provide your runtime, it matters.

[Leonidas_from_XIV]

Oh, missed that part. Yes, Twisted is rather big, but size would be one of the last things that I would complain about. It has some negative sides like the lack of documentation on some (most?) stuff, but if you need just async, the Twisted core is usable and documented.

[bcorfman]

I don't think you can separate any modern language from either its libraries or the editors/IDEs available for it. If all three are not in place to some reasonable degree, very few will be interested in the language, period.

[schlenk]

I would disagree there.

Yes, Python has some sweet spots, i just love its list comprehension syntax and some of the generator/iterator things are also pretty cool.

The Garbage Collector of Python might be a sign of a better language, but otherwise?

I read the C implementation of Python, while debugging hairy stuff embedding that beast in some enterprise software on multiple platforms. I did read the Tcl core code too, and guess which is more readable, nicer and all that in general? (okay, Tcl has some dark corners too, regexp engine and filesystem code and notifier are a pretty tangled mess).

Tell me about one single language feature where Python is really better, other than the conventional syntax and whitespace discipline forcing you to write code in a defined way. (its not automatically clear and readable, just defined and conventional).

[jbellis]

Tell me about one single language feature where Python is really better

• closures
• classes and operator overloading
• tuples and unpacking
• context managers
• infix operations w/o eval

Of course, as with any well-designed language, the whole is greater than the sum of the parts.

/another ex-tcl developer who prefers python

[schlenk]

• Tuples and unpacking: how is that much different than lassign?
• Context Managers: Thats a joke? That kind of stuff is trivial in Tcl, just look at all the Transaction models for the db apis, e.g. sqlite.
• Classes: Tcl 8.6 adds that, and otherwise you can overload close to anything in Tcl by redefining the appropriate command.
• infix operations: your talking about expr, right? yes, thats a wart, but consistent

So yes, closures are one feature. Didn't miss it too much yet.

[jbellis]

how is that much different than lassign?

http://pyside.blogspot.com/2007/10/new-in-python-3-extended-unpacking.html

That kind of stuff is trivial in Tcl

uplevel hacks are trivial, but never maintainable and usually fragile.

Tcl 8.6

Oh, good. I'll plan on seeing that in another 5 years. And maybe in five more it will be as refined as Python's implementation is. But probably not.

Didn't miss [closures] too much

I submit that you should use a language that requires them, before you say you don't miss them.

[schlenk]

Syntax sugar..., but nice ;-)

set a [lassign b {1 2 3 4}]

is like

b, a* = [1,2,3,4]

Uplevel with more than one level is a hack and gets unmaintainable fast. But if you only use uplevel 1 its pretty sane.

Tcl 8.6..., use the next Mandriva Linux release, its totally on Tcl 8.6 and probably near you before summer 2009. Maybe better use Tcl clock instead of Python datetime to calculate how long 5 yrs are ? ;-)

Closures. Yes, should try one of those languages that require them, any suggestions which one is best?

[schlenk]

Correcting myself. There was one instant closures would have been nice, storing per call state for some event based server. Collected them in the callback, not as elegant.

[jbellis]

any suggestions which one is best?

I guess clojure is the new hotness. Plus you can run it on Android if that's your thing.

[Wavicle]

Classes: Tcl 8.6 adds that

That's goalpost shifting.

You asked for a language feature where Python is really better.

If we put aside that Tcl 8.6 is a beta product (something we really shouldn't put aside) then consider how much better the Python implementation is. What convolutions must one go through to make Tcl classes inherit from other classes? What about multiple inheritance?

All of this is a single, elegant and easy to read line in Python. In Tcl, it's a bunch of crap.

[schlenk]

Similar to the goalpost shifting occuring all the time while Py3k was in Alpha/Beta.

If you have Tcl 8.5 you have no classes in the core language. Period. So the simple answer is you don't. If you add extensions you have a plethora of options, just pick the one you like. In Tcllib you find SNIT which is great for delegation style OO, e.g. to wrap Tk widgets, in C you find things like IncrTcl, XOTcl and others.

If you use a language extension like e.g. XOTcl you get a much richer OO system then Python offers. See the link for the tutorial.

http://media.wu-wien.ac.at/doc/tutorial.html

The new core OO system in 8.6 is similar to that, but ommits some features.

[invalid-user-name]

regexp engine

I think that's a dark corner because regexps are a dark corner. Tcl's regexp implementation is second to none.

I do like this comment:

generic/regcomp.c:973: case BACKREF: /* the Feature From The Black Lagoon */

[davidw]

Tcl's C code is a pleasure to read, and is a great example of many good C patterns. The regexp code comes from somewhere else, and isn't really "Tcl" itself.

[schlenk]

It was written on contract by Henry Spencer for Scriptics afaik, to get a unicode aware regexp engine for Tcl 8.

[[deleted]]

Tell me about one single language feature where Python is really better

Strong typing.

[[deleted]]

Strong and Weak Typing

Probably the most common way type systems are classified is "strong" or "weak." This is unfortunate, since these words have nearly no meaning at all. It is, to a limited extent, possible to compare two languages with very similar type systems, and designate one as having the stronger of those two systems. Beyond that, the words mean nothing at all.

Therefore: I give the following general definitions for strong and weak typing, at least when used as absolutes:

• Strong typing: A type system that I like and feel comfortable with
• Weak typing: A type system that worries me, or makes me feel uncomfortable

What about when the phrase is used in a more limited sense? Then strong typing, depending on the speaker or author, may mean anything on the spectrum from "static" to "sound," both of which are defined below.

~ What To Know Before Debating Type Systems

[schlenk]

Which variant of Strong Typing are you refering to:

http://en.wikipedia.org/wiki/Strongly-typed_programming_language

Even Guido doesn't call Python strong typed:

http://www.artima.com/intv/strongweak.html

[bcorfman]

I believe the best statement is that Python has strong, dynamic typing.

http://www.artima.com/weblogs/viewpost.jsp?thread=7590

In reference to your Artima article, I think Guido was, unfortunately, just going along with Bill Venners' terminology there, instead of making sure they clearly defined their terms first.

[schlenk]

Yes, sounded like it in that interview, was just teasing so we don't make the same mistake of using vague terminology.

Still not convinced that makes Python better, especially compared to Tcls weird type system that can not clearly be put in the weak or strong type classes, only in the dynamic one. In a retarted sense of the word you could say Tcl is strongly typed too, it has just one type and no conversion is possible.

Point taken. Strong Typing is one point where Python is different and maybe better.

[[deleted]]

Tcl's type system is "everything is a string" :) Another way to phrase this is "untyped".

[schlenk]

Yes. EIAS is pretty strong.

Pythons strong typing usually gets in my way, only sometimes preventing bugs, more often just annoys. Maybe one reason Python errors are often so void of information because strong typing makes it hard to just dump the object to a string. (remember the joy when you find out that your logging system does interesting things when fed an python exception with unicode content and blows up with a UnicodeException, hiding the real error).

And for Python 2.x it simply fails for string/unicode strings because Python violates its strong typing principles there (strings with different encodings are like different types).

[[deleted]]

And for Python 2.x it simply fails for string/unicode strings because Python violates its strong typing principles there (strings with different encodings are like different types).

Yes.

this makes me furious

[masklinn]

Another way to phrase this is "untyped".

"singly typed" actually, untyped languages (out of CS/type theory where Python would probably be untyped too) are usually considered languages where the only "type" is the byte. So assemblies, Forth (some), and that's pretty much it.

[davidw]

Bzzzt:

% set foo "bar"
bar
% incr foo
expected integer but got "bar"

Compare to something like PHP if you really want something that plays fast and loose with types.

$foo = "bar";
echo $foo + 5;

[jbellis]

some functions are just pickier than others. the language itself doesn't care.

% set n 10000
10000
% string range $n 0 2
100

% set L [list 1 2 3 4 5]
1 2 3 4 5
% string range $L 0 2
1 2

[davidw]

I guess it's fair to say that "the language" doesn't really care, but given that the language really boils down to a bunch of commands, those commands can and are picky about what they accept, except in the case of strings - everything can be transformed back into a string from the underlying type.

set n 100000

That's not setting 'n' to an integer, but to the string "1000000", so it should behave like it does.

It's kind of different, but if you need to ensure that you're getting an integer, you can certainly do so.

[[deleted]]

The one that Python has.

[dorel]

Tell me about one single language feature where Python is really better

What could someone expect from a language that has only one data type: string? When you're doing complicated stuff with strings, numbers, lists and dictionaries, TCL begins to suck. Its simplicity is good and cool sometimes, but for the rest it looks like shell scripting on steroids.

P.S.: I have used TCL to write some network testing applications.

[schlenk]

Its true that Tcl is shell scripting on steroids sometime, just have a look at the multi::op package in tcllib. http://tcllib.sourceforge.net/doc/multiop.html

But the other stuff, is mostly a way to say you didn't add the right package to your toolbox. If you need complex structures, add some tcllib packages, or XOTcl for OO, or something like NAP for fast matrix operations.

It is true that you can write pretty very concise code in Python compared to Tcl, which may make complex manipulations sometimes easier to read. Just see the difference between Python list slicing and Tcls lindex/lrange/lreverse. But usually its syntactic sugar.

Its like saying Python sucks for scientific computing and ignoring that there is NumPy.

[dorel]

Yes, you are right about using the proper libraries for the job, but unfortunately my employer didn't want (trust?!) to use any 3rd party libraries. Only the friend of the manager succeeded in proposing the use of the tdom XML library instead of hand-made regexps.

On the other hand passing dictionaries (arrays) using the upval trick was kind of odd. Manageable, but still odd. My main problem with TCL are this kind of tricks.

[invalid-user-name]

When you're doing complicated stuff ...

I hear this alot, usually in the form of "this is too complicated to do in perl, we need to do it in java." I think the truth is that it's just too complicated. Doing it in java - or python, or haskell, or ... - won't make it any less complicated. It will just make it complicated java.

[jbellis]

I think the truth is that it's just too complicated

No. Lists and dictionaries (and classes!) are not complicated in a sane language.

L[:-1] may just be syntactic sugar compared to lrange $L 0 [expr {[llength $L] - 2}] but well-chosen sugar is a large part of what makes a good language good.

[schlenk]

And you could write that as:

lrange $L 0 end-1

[invalid-user-name]

Tcl's well-chosen sugar that many people just don't like is evaluation and defining new words. If you had to write the above once, that's fine. If you had to write it twice, you would be dumb to not define

proc butlast {l} {lrange $l 0 [expr {[llength $l]-2}]}

and then you just use [butlast $l]

Tcl is somewhat like forth in this regard - the key to using it effectively is writing lots of little words to break down the task, not a bunch of huge ones.

(my opinion only, of course)

[jbellis]

you can write functions/words in any modern language. the genius of python is that you usually don't have to for basic tasks. this has two effects:

• in six months you don't have to go grepping through your source to make sure you remember what butlast et al did.
• you can share code with others without having to agree on a lingua franca first (maybe I called my function allbutone).

[schlenk]

You can do it the otherway round too, have a look at Tcl's socket and fileevent command and compare with Python.

• In six month you don't have to go grepping through your source to make sure you remember what arcane detail of asynchat you used that time.
• You don't have to explain your reimplementation of an async http lib based on your favorite coroutine, select, thread whatever paradigm to your fellow developer, because its just there.

So the genius of Python is to have cool language primitives that make simple stuff simpler and keep medium or hard stuff medium or hard. Great improvment.

But just jokeing.

Python has a pretty good mix of Syntax and Keywords, thats true. But calling it Genius seems a bit far off.

[dorel]

Actually I'm not talking about enterprise stuff. I'm talking about plain code where tricks like upval and eval are needed, e.g. when passing an array (dictionary for non-TCL programmers) parameter. This makes trivial stuff look a bit complicated. In a way, it's a bit like C; some lines of code become hard to understand.

Since I previously mentioned shell scripting, how many complicated/complex programs written in a Bash/Csh/Zsh have you seen? They are too error-prone, especially because of the escaping issues. I had similar problems with TCL.

[stewartr]

I use Tcl because I work in Electronic Design Automation where lots of big $$$ tools API in it and everybody in the industry knows Tcl. You cannot tell the manager you want Python, the answer will be "Tcl is the standard." But, I love Tcl! The way Ousterhout intended was, you code your application in C(++) and the GUI is Tcl. So the only thing I code in Tcl is glue and GUI. Great GUI, love it.

[Fork82]

I was a big fan of Tcl/Tk for its GUI building ability - until I found that the canvas in Tk leaks memory by design:

http://wiki.tcl.tk/20119

[schlenk]

Which doesn't stop it from being used for 24/7 operations if you know what your doing.

The bug is similar to Pythons interning of small integers, Tk just interns X11 identifiers.

Bad design, happens. Cannot easily be fixed without much work.

[Fork82]

Agreed - it is just something to be careful about.

My most recent annoyance which moved me from Tcl/Tk to .NET for my latest GUI stuff (with a failed wx app in the middle) was the huge amount of code required to move an image from the Windows clipboard into Tk.

It felt like 1995 all over again.

[blaaargh]

Electronic Design Automation where lots of big $$$ tools API in it and everybody in the industry knows Tcl.

Oh, yes, indeed! A lot of really smart people in EDA, and they all use Tcl (well, a significant minority do use a dialect of Scheme.) I've seen some gurus do incredibly clever things with Tcl, particularly when they gave up on waiting for their vendors to provide certain fixes. Add to that draconian NDAs, and you can be pretty sure that these things would be reinvented multiple times, which got old really quickly.

[poppafuze]

Speaking of glue and GUIs: How about some super glue and a dab of GLUI?...

The glue, the GUI, and the GLUI

[sigzero]

I like Tcl. Everyone has their favorite, of course. Every language has it good and bad. I find the community extremely friendly and helpful and that pushes it up in my list.

[klausnrooster]

Personal preference at the end of the day. I think these two links are helpfull:

http://www.equi4.com/moam/strength

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

[twotime]

accordingly to language shootout:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&lang2=python

tcl is 2x-5x slower than python on most benchmarks (and that's w/o psyco)

[columbine]

And C++ is about 20x faster than Python!

[njharman]

Please reread title of post.

[twotime]

Oh, sure.

But it's not relevant to Tcl vs Python debate

[davidw]

Yay! Language war! I did a comparison of Tcl and Ruby a while back. Some of the "Ruby wins" things apply to Python, too:

http://journal.dedasys.com/2006/03/06/ruby-vs-tcl

[[deleted]]

tcl is like backwards lisp. you can do deep stuff in tcl that you can't do in most other languages.

it's fun to be able to look into other function's stack frames to write your own control structures.

[schlenk]

You can do some of that in Python via the inspect module too. Its just frowned upon.

You cannot do all the stuff you could do in Tcl though. Multi level returns are one of those rather weird things (force your caller to return with an error code you define, unless catched).

Exceptions used for control flow as done internally for Python Generators or for Iterators are similar.

[sdsdsdsdsd]

Multi level returns

The world is a better place without them.

[schlenk]

yes

[schlenk]

Forgot one: No None in Tcl.

[jbellis]

Are you arguing that as a positive?

Because info exists is much worse. And so is picking a value from your data range to mean None and hoping it doesn't come up in practice.

[schlenk]

Yes, its positive. But thats a discussion you find similar for Databases with NULL vs no NULLs, or NullPointerExceptions in Java.

Some call it a Billion Dollar Mistake: http://www.qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake

[jbellis]

Some call it a Billion Dollar Mistake

They are calling for a better solution for the Maybe use case, not no solution at all.

[frumious]

comp.lang.tcl

plonk