- Tcl needs to have OO in the core
TIP 257
: Marketing edit
The TCT have made the statement that marketing forces are sufficient justification.If we take that as the basis, then I propose that there are more deserving marketing issues for Tcl, namely:- Distribution. A formal method of making stand-alone executables
- Database interaction
- Web plugin
- 3D Graphics
[someone comments] ??? I haven't seen any marketing justification for a web plugin. We've had the plugin off and on for years and there's been seemingly almost no interest in it. The "When will oo make it into the core" posts to c.l.t. outnumber the "when will we have a web plugin in the core" about 10,000,000 to 1
None of the above are included or even distributed with the core. Since the TCT are the sponsors of tip257, they would have sponsored the above as TIP's if they had a genuine interest in marketing forces.I propose:
- That the marketing argument is specious.
- For distribution, there's excellent third-party solutions (and trofs is probably the way to move forward on this front).
- DB interaction is fraught with problems due to partial availability and/or redistributability of libraries on which it would depend. This means that any approach to this problem is going to need to be a general framework; those frameworks I've seen have been OO based...
- The biggest problem with a web plugin is the installer for it. Apart from that minor (but total) sticking point, we could go with this very quickly. ActiveState do a free plugin already, Jeff having revamped the plugin for modern browsers.
- The closest-to-viable suggestion I've seen on the "3D canvas" front is Zinc. Last time I checked (a while ago now, admittedly) there were some license trickinesses.
There is a need for OO in the core edit
I need chocolate might as well be the phrase stated. There have not been any stated examples that show that Tcl would be better or that development in Tcl would be easier if OO was in the core.I propose:- That the need is emotional not factual.
CMcC At the risk of being repetitive, tcllib modules contain many reimplemented OO systems, it would surely have been easier to implement the OO systems if Tcl core supported OO better, it would also have been easier to implement the modules themselves if Tcl had one or several preferred OO systems. QED.
[Someone comments:] using that argument, then perhaps tips should be submitted for every library currently existant for Tcl, since surely it would be easier to implement extensions and applications if every extension were shipped within the tcl core (aka the Batteries Included approach).
One more time: The need for OO is demonstrated by the profusion of OO implementations. Whether the need is any more or less real because PWQ doesn't feel it is surely irrelevant. I don't even think it needs to be a demonstrable need, surely a widespread preference would be sufficient. After all, none of use need to use Tcl at all - we could use assembler, or PERL, or FORTRAN.
[Someone comments:] if the profusion of OO implementations were all done the same, then this argument would be much stronger. Given the radically different approaches, it would seem that providing something actually useful in the construction of all those OO extensions might be tough - and providing something that meets all the needs that each of those extension writers had when writing their own OO extension seems like a silver bullet.
DKF: I've been told that there's a need for OO in the core by multiple people for years. Some of these people have stopped using Tcl for production work because of this. Can I enumerate all the exact instances of the discussion? No. I have at least some life... ;-)
[Someone comments:] using that argument, then perhaps tips should be submitted for every library currently existant for Tcl, since surely it would be easier to implement extensions and applications if every extension were shipped within the tcl core (aka the Batteries Included approach).
One more time: The need for OO is demonstrated by the profusion of OO implementations. Whether the need is any more or less real because PWQ doesn't feel it is surely irrelevant. I don't even think it needs to be a demonstrable need, surely a widespread preference would be sufficient. After all, none of use need to use Tcl at all - we could use assembler, or PERL, or FORTRAN.
[Someone comments:] if the profusion of OO implementations were all done the same, then this argument would be much stronger. Given the radically different approaches, it would seem that providing something actually useful in the construction of all those OO extensions might be tough - and providing something that meets all the needs that each of those extension writers had when writing their own OO extension seems like a silver bullet.
DKF: I've been told that there's a need for OO in the core by multiple people for years. Some of these people have stopped using Tcl for production work because of this. Can I enumerate all the exact instances of the discussion? No. I have at least some life... ;-)
OO Programmes are Better edit
Let's provide a simple definition of better. If OO leads to less code, more stable applications, less effort for programmers, then we can generalize and say that overall we have a better situation. I would also say that adding features to a programme does not count as making it a better application. For example, FireFox is not better than Netscape because it has more features- it would be a better application if it took less code for the same features, was more reliable.[Someone comments] well, many people would say that FireFox is better because of it providing features that Netscape does not. Few users worry about "less code". Certainly reliability is an important factor though, as is more security. In the Tcl domain, though, what seems to be more important is more functionality being distributed with the core; as often (if not more so) as requests for OO has been requests for a Batteries Include core distribution, or a central repository of code... with the former being much preferred over the latter...
- TeX
- Mozilla
[Someone comments]] Say what? TeX and Mozilla have only minimal functionality overlap. Mozilla's functionality is hypertextual display and internation with multiple data types (Flash, Java, PDF, HTML, XML, etc.) in an interactive environment. Whereas TeX is a batch formatting of one formatting language, primarily (though not exclusively) for hard copy printouts.Lars H:It's an odd comparison, but both programs do a nontrivial "markup language" -> "rendered text" conversion. Neither input nor output formats are the same, but the complexities of these tasks are sort-of comparable, and since both tasks are of fairly high complexity one can expect that asymptotic terms should be dominant in the observed costs for programming. I think the point PWQ wants to make is that if the OO paradigm is much better (whatever that means) than procedural programming, then that should show up when comparing these two codebases.
- Take the source code for e-tex, add in the code for the macros. Now add in the code for the LaTeX macros. Also add in the code for Xdvi.
- Take the source code for the table layout of Gecko.
[Someone comments] - the only time less code is required is if the new features are somehow related to the old, and if the people writing the code know what they are doing. I don't know the Mozilla team, so I can't address the later, but certainly many of the features in Mozilla are not related, providing little reuse opportunity.
- The number of bug in mozilla is not reducing as OO design practices would dictate.
- The amount of source code (ie new classes) for new features for mozilla is not reducing as OO design practices would dictate.
- There is more effort required in maintaining Mozilla than there is in TeX.
- TeX is more reliable than Mozilla.
- pascal/C are better than C++
- Procedural is better than Object oriented
CMcC Firstly, I don't know if anyone has advanced the argument 'OO programs are better than non-OO programs' as a justification for tip #257. Secondly, I don't think anyone could argue that it's impossible to write a bad OO program, or a good non-OO program - so producing a bad OO program and a good non-OO program means nothing in terms of the tip. This really is a straw man argument, and even the straw man seems to be clutching at straws.DKF: OO programs are better for some things, especially when dealing with a situation where the problem admits a good object-oriented model. OK, that's just some things, but it's an important set of some things (there are significant parts of the computer industry where OO Design has ruled the roost for at least 15 years, possibly even 20).And TeX is more reliable than Mozilla in large part because it's much happier to throw problems in users' faces without useful recovery. Indeed, they're different classes of programs; when Don Knuth develops a browser for the WorldWideWeb, we can start to talk about doing sensible comparisons. Your proposals are predicated on a trivial logical fallacy. Might as well say "my orange is smaller than your truck, so all organic objects are smaller than all metal objects".Oh, and TeX isn't written in Pascal or C. Not that you should permit such facts to interfere with your specious reasoning.Lars H: Well, TeX is written in Web, but that's just Pascal-with-a-preprocessor, and most present TeX implementations have lots of glue code (e.g. for file handling) written in C, so I'd say "TeX is written in Pascal+C" is dead on for 99% of the computing community. Only the real afficinados would really object. OTOH, I think the pdfTeX additions are mostly written in C++ rather than C, so none of this says much about the OO/procedural controversy.That TeX is "happier to throw problems in users' faces without useful recovery" is also debatable. TeX can be run in "batch" mode in which it just happily chews on without saying anything, and in many cases that only leads to some piece of text disappearing where an error occurred, exactly as with many browsers. But yes, TeX code is probably more prone to errors that are unrecoverable than HTML code.DKF: I prefer \nonstopmode to \batchmode but there you go. In neither case is the recovery any good with moderately malformatted input (which is a nice and accurate description of virtually every web page ever created.) TeX input is really a programming language with a few extra goodies for formatting text attached, and the act of producing output is really the act of running a scripting language program (yes it is turing-equivalent). But this is all rather off-topic; let's just say that TeX and Firefox aren't meaningfully comparable and let it go at that.
aricb Dude, you are missing the point. The case for OO in the core is this:Lots of people want OO in the core because they want OO in the core. They can probably articulate a reason or two, but it ultimately comes down to personal preference, which needn't be subjected to silly debates. In the end, those same people will still want OO in the core, and you still won't.It seems silly to fight a TIP whose inclusion needn't affect the way you use Tcl. You can still go on writing procedural code if TIP 257 is accepted. If you're concerned about the impact of this TIP on the size of the Tcl executable, you still have the option of sticking to Tcl 8.4.
NEM Can we please stop using the wiki as a discussion forum? This page would be much better served as a thread on comp.lang.tcl. If you want to troll, Philip, then please, at least don't clutter up the wiki with new pages devoted to this nonsense.Please see e.g. [1] for a definition of "troll". For someone to actually be a troll, it would require that he really doesn't care about the matter he's discussing, but instead only wants to upset people. This does not seem to be the case here.(NEM I'd say this page fits the description pretty well.)CMcC I don't see that it matters, NEM. If PWQ has something eating him, I'd rather deal with it here in the open than leave it to fester.I'm not impressed by the calibre of PWQ's counter-arguments, though, and this page isn't so much a place for reiteration of arguments in favour of Tip #257, as a platform to expose fallacious counter-arguments. I've created [OO Killed My Brother] so OOffended people can really vent. ... and I removed it again, to prevent this. The wiki is for storing info and finding it back later. The c.l.t forum is for discussion, it's at least as public as this place. jcwPWQ 09 Oct 05, Hmmm. According to The purpose of this Wiki, this page fits the bill exactly.As for trolling, I assume that anytime a viewpoint is expressed that is contrary to those in control, it ceases to be valid and becomes a troll, flame, et al.As for calibre of counter arguments, At least I have an informed opinion on the subject, which is clearly (from the replies) more than the supporters of TIP257 have.I posted a some points of view for the purpose of highlighting the inconsistent nature at which the TCT chooses to add to the core. It is possible that others agree. I see from the posts that no-one else cares. Fine, it's your choice. I don't ask you you alter your opinion , nor do I tell you what you can and can't post. In ten years time, these posts my be useful for purposes that no-one has yet thought of.NEM This really isn't going anywhere. If you have real and serious reasons for opposing OO in the core, then please raise them on either clt or, preferably, on the tcl-core mailing list.SYStems 12 Oct 05 One of the good things about Tcl is the language minimality, Tcl in my opinion just defines how the command are being parsed/interpreted/understood everything else is up to the command, commands are grouped and packaged in libraries, since adding OO to the core doesn't change Tcl parsing rules, we are really merely discussing a packaging and distribution issue, Tcl is not really affected, so yes no need to worry if you don't like OO, they will be just few more commands, just ignore them, I think Tcl strongly support the C++ idiom that says that you don't have to pay for what you don't needDKF: Hardly my fault if we propose to take decisions someone doesn't like. That's why Tcl isn't managed by consensus of the whole community. Note that other communities have similar problems.[2]RLH: Thank goodness for that! I see no problem (except for bloat and that remains to be seen) with having oo:: in the core. Use it or not, it is the end users choice.RS: If Tcllib's "local OO" is rewritten in terms of #257, it might even lead to debloating. Also: can Tk profit from #257? If it supports megawidgets, it might simplify the code for normal widgets too...PWQ 12 Oct 05, The truth of the matter is that everyone will be affected by having OO in the core, and that parts of Tcl/Tk that everyone uses will have to switch to oo syntax et al to be able to interface to.NEM No! This is exactly what the TIP avoids! Tcl is far more dedicated to backwards compatibility than to any particular paradigm. The TIP proposes adding OO as a monotonic addition: nothing will be taken away. (BTW, to my eyes quite a lot of Tcl code already uses a OO-ish syntax to some degree, e.g. ensembles, Tk widgets, etc).PWQ (continued) The big picture that no-one wants to address is that there is:
wdb 2007/02/02 Not regarding the question if it is really desirable, introducing OO requires removement of the var/proc dichotomy.I've tried two OO systems, Itcl and Snit, and both of them use procs to form the objects. As far as I see, that's the only reasonable way to realize OO in Tcl (fix me if I have overlooked something). But procs are handled different from variables via set as they cannot be as private as variables inside a procedure. E. g. watch the body of the procedure itcl::local in Itcl, and you see, it is like Perl's local construct: created inside the closure, it is globally visible, and on leaving the closure, the object is destroyed.Watch pure OO languages such as Ruby and Smalltalk -- there, even local vars are objects. Consequently, in OO with Tcl, it should be the same. One first try in this direction was tcl9var which was discussed controversially.LV At what point, with all these changes, would Tcl quit being Tcl and become something else? And might it be better to create a language, from scratch, that has all these features that people require, rather than trying to wire them overtop of Tcl?escargo I agree. If you want a pure OO language, switch to one that is. What I like about Tcl is that there are things that take commands, not messages, and then exhibit behavior. It doesn't matter how those things got created as long as they take commands. (If there is one thing I want from an OO system in Tcl, is that everything that takes commands can respond with a "I Do Not Understand" error. Even better if they would all take an "info commands" command and respond with a list of commands that they do understand.) I have been tempted to learn python or ruby for their more purely OO orientation (or even Smalltalk or self), but Tcl seems closer to the way I think than any of these.
aricb Dude, you are missing the point. The case for OO in the core is this:Lots of people want OO in the core because they want OO in the core. They can probably articulate a reason or two, but it ultimately comes down to personal preference, which needn't be subjected to silly debates. In the end, those same people will still want OO in the core, and you still won't.It seems silly to fight a TIP whose inclusion needn't affect the way you use Tcl. You can still go on writing procedural code if TIP 257 is accepted. If you're concerned about the impact of this TIP on the size of the Tcl executable, you still have the option of sticking to Tcl 8.4.
NEM Can we please stop using the wiki as a discussion forum? This page would be much better served as a thread on comp.lang.tcl. If you want to troll, Philip, then please, at least don't clutter up the wiki with new pages devoted to this nonsense.Please see e.g. [1] for a definition of "troll". For someone to actually be a troll, it would require that he really doesn't care about the matter he's discussing, but instead only wants to upset people. This does not seem to be the case here.(NEM I'd say this page fits the description pretty well.)CMcC I don't see that it matters, NEM. If PWQ has something eating him, I'd rather deal with it here in the open than leave it to fester.I'm not impressed by the calibre of PWQ's counter-arguments, though, and this page isn't so much a place for reiteration of arguments in favour of Tip #257, as a platform to expose fallacious counter-arguments. I've created [OO Killed My Brother] so OOffended people can really vent. ... and I removed it again, to prevent this. The wiki is for storing info and finding it back later. The c.l.t forum is for discussion, it's at least as public as this place. jcwPWQ 09 Oct 05, Hmmm. According to The purpose of this Wiki, this page fits the bill exactly.As for trolling, I assume that anytime a viewpoint is expressed that is contrary to those in control, it ceases to be valid and becomes a troll, flame, et al.As for calibre of counter arguments, At least I have an informed opinion on the subject, which is clearly (from the replies) more than the supporters of TIP257 have.I posted a some points of view for the purpose of highlighting the inconsistent nature at which the TCT chooses to add to the core. It is possible that others agree. I see from the posts that no-one else cares. Fine, it's your choice. I don't ask you you alter your opinion , nor do I tell you what you can and can't post. In ten years time, these posts my be useful for purposes that no-one has yet thought of.NEM This really isn't going anywhere. If you have real and serious reasons for opposing OO in the core, then please raise them on either clt or, preferably, on the tcl-core mailing list.SYStems 12 Oct 05 One of the good things about Tcl is the language minimality, Tcl in my opinion just defines how the command are being parsed/interpreted/understood everything else is up to the command, commands are grouped and packaged in libraries, since adding OO to the core doesn't change Tcl parsing rules, we are really merely discussing a packaging and distribution issue, Tcl is not really affected, so yes no need to worry if you don't like OO, they will be just few more commands, just ignore them, I think Tcl strongly support the C++ idiom that says that you don't have to pay for what you don't needDKF: Hardly my fault if we propose to take decisions someone doesn't like. That's why Tcl isn't managed by consensus of the whole community. Note that other communities have similar problems.[2]RLH: Thank goodness for that! I see no problem (except for bloat and that remains to be seen) with having oo:: in the core. Use it or not, it is the end users choice.RS: If Tcllib's "local OO" is rewritten in terms of #257, it might even lead to debloating. Also: can Tk profit from #257? If it supports megawidgets, it might simplify the code for normal widgets too...PWQ 12 Oct 05, The truth of the matter is that everyone will be affected by having OO in the core, and that parts of Tcl/Tk that everyone uses will have to switch to oo syntax et al to be able to interface to.NEM No! This is exactly what the TIP avoids! Tcl is far more dedicated to backwards compatibility than to any particular paradigm. The TIP proposes adding OO as a monotonic addition: nothing will be taken away. (BTW, to my eyes quite a lot of Tcl code already uses a OO-ish syntax to some degree, e.g. ensembles, Tk widgets, etc).PWQ (continued) The big picture that no-one wants to address is that there is:
TOP.Tcl Oriented Programming. This is a unique way of coding that builds on the strengths of Tcl. Unfortunately few programmers have made the quantum leap and are stuck on last century's model of programming. Maybe you will be ready for this paradigm next century.CMcC Can I call 'empty rhetoric' on this?JBR No you cannot. Tcl like lisp and Forth are different. Many programmers use these languages just like C or perl or ... They never cross the bridge that lets them use the interpreter and never understand that code is data is code.DKF 2011/10/11: Revisiting this, I think the take-home messages are:
- You don't need to use OO in Tcl.
- You don't need to understand OO to use Tcl.
wdb 2007/02/02 Not regarding the question if it is really desirable, introducing OO requires removement of the var/proc dichotomy.I've tried two OO systems, Itcl and Snit, and both of them use procs to form the objects. As far as I see, that's the only reasonable way to realize OO in Tcl (fix me if I have overlooked something). But procs are handled different from variables via set as they cannot be as private as variables inside a procedure. E. g. watch the body of the procedure itcl::local in Itcl, and you see, it is like Perl's local construct: created inside the closure, it is globally visible, and on leaving the closure, the object is destroyed.Watch pure OO languages such as Ruby and Smalltalk -- there, even local vars are objects. Consequently, in OO with Tcl, it should be the same. One first try in this direction was tcl9var which was discussed controversially.LV At what point, with all these changes, would Tcl quit being Tcl and become something else? And might it be better to create a language, from scratch, that has all these features that people require, rather than trying to wire them overtop of Tcl?escargo I agree. If you want a pure OO language, switch to one that is. What I like about Tcl is that there are things that take commands, not messages, and then exhibit behavior. It doesn't matter how those things got created as long as they take commands. (If there is one thing I want from an OO system in Tcl, is that everything that takes commands can respond with a "I Do Not Understand" error. Even better if they would all take an "info commands" command and respond with a list of commands that they do understand.) I have been tempted to learn python or ruby for their more purely OO orientation (or even Smalltalk or self), but Tcl seems closer to the way I think than any of these.
