> Somewhat related to the large Tcl vs small Tcl issue was one particular extension, or extensions to the language that was noticeably absent: a system for writing “object oriented” code. Tcl, at heart, will never be an OO language through and through, like Ruby or Smalltalk, but that doesn’t mean that an OO system for it is not a useful way of organizing larger Tcl systems. Indeed, Tcl’s syntax is flexible enough that it’s possible to write an OO system in Tcl itself, or, optimizing for speed, utilizing the extensive C API in order to create new commands. Over the years, a number of such systems have arisen, the most well-known being “Incr Tcl” (a play on the incr command, which is akin to += 1 in languages like C). However, none of these extensions was ever included with the standard Tcl distribution or somehow “blessed” as the official OO system for Tcl. This meant that a newcomer to Tcl wishing to organize their code according to OO principles had to pick a system to use from several competing options. And of course, newcomers are the least able to judge a complex feature like that in a language, making it a doubly stressful choice. Furthermore, even experienced Tcl programmers who wanted to share their code could not utilize an OO system if they wanted their code to work with just standard Tcl. Also, if their code had a dependancy on some OO system, it would require the user to download not only the extension in question, but the OO system it was built on, which, naturally, might conflict with whatever OO system the user had already selected! As of Tcl 8.6, thanks to the work of Donal Fellows, Tcl is finally integrating the building blocks of an OO system in the core itself, but this effort is probably something like 10 years too late.
This is not the same thing. You are talking about language extensions, I am talking about libraries. Features which require language modification/extension in other languages can usually be implemented as ordinary libraries in Haskell.
> Features which require language modification/extension in other languages can usually be implemented as ordinary libraries in Haskell.
Tcl can implement OO as a library. Granted that it's not "turtles all the way down OO" ala smalltalk, but it's good enough for code organization purposes.
Yes, and then you get several different and incompatible ways of handling errors, at least three different lens libraries... The resulting fragmentation is an issue. It is the same issue as Tcl.
Fragmentation is an issue with every mature, vibrant ecosystem. It's also a benefit in that it fosters innovation.
As for lens libraries? Edward Kmett's library[0] has taken over that space. The other libraries represent previous attempts at discovering the optimal API and mainly exist now for historical/compatibility reasons.
> Fragmentation is an issue with every mature, vibrant ecosystem. It's also a benefit in that it fosters innovation.
I get your point, but sometimes it can be better to have a somewhat less-than-optimal solution standardized rather than many "better" solutions. And while people obviously come up with different solutions to the same issue, it is important to distinguish critical systems (eg, error handling) from other systems which are specific to a few domains (eg, webservers). IMHO, the former absolutely need to be standardized.
> As for lens libraries? Edward Kmett's library[0] has taken over that space. The other libraries represent previous attempts at discovering the optimal API and mainly exist now for historical/compatibility reasons.
I get your point, but I'm sure you'll still find a number of libraries on Hackage depending on non-Lens packages. This is not a desirable state of affairs.
I get your point, but I'm sure you'll still find a number of libraries on Hackage depending on non-Lens packages. This is not a desirable state of affairs.
That's an issue of package curation. It has nothing to do with the merits or demerits of a language. When outdated/broken/abandoned software sits around it's always going to be a problem for beginners who don't know the difference.
http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-...
> Somewhat related to the large Tcl vs small Tcl issue was one particular extension, or extensions to the language that was noticeably absent: a system for writing “object oriented” code. Tcl, at heart, will never be an OO language through and through, like Ruby or Smalltalk, but that doesn’t mean that an OO system for it is not a useful way of organizing larger Tcl systems. Indeed, Tcl’s syntax is flexible enough that it’s possible to write an OO system in Tcl itself, or, optimizing for speed, utilizing the extensive C API in order to create new commands. Over the years, a number of such systems have arisen, the most well-known being “Incr Tcl” (a play on the incr command, which is akin to += 1 in languages like C). However, none of these extensions was ever included with the standard Tcl distribution or somehow “blessed” as the official OO system for Tcl. This meant that a newcomer to Tcl wishing to organize their code according to OO principles had to pick a system to use from several competing options. And of course, newcomers are the least able to judge a complex feature like that in a language, making it a doubly stressful choice. Furthermore, even experienced Tcl programmers who wanted to share their code could not utilize an OO system if they wanted their code to work with just standard Tcl. Also, if their code had a dependancy on some OO system, it would require the user to download not only the extension in question, but the OO system it was built on, which, naturally, might conflict with whatever OO system the user had already selected! As of Tcl 8.6, thanks to the work of Donal Fellows, Tcl is finally integrating the building blocks of an OO system in the core itself, but this effort is probably something like 10 years too late.