'''[Philip Quaife]''' ''11 Oct 05'' Whenever I present my opinion on a subject on this wiki, I try to provide the basis for that opinion. That is to say, I try to provide enough input for someone to provide a rational comment and thus engender a discussion. In the debate on OO for the core, I have not found any comments made by those people supporting the above so that there can be a rational discussion on the merits. I have started this page for those people to provide their basis for their viewpoint that: * Tcl needs to have OO in the core ---- '''TIP 257: Marketing''' 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: 1. Distribution. A formal method of making stand alone executables,. 1. Database interaction. 1. Web plugin. 1. 3D Graphics. ''??? 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 sponsers of tip257, they would have sponsered the above as TIP's if they had a genuine interest in marketing forces. I propose: * That the ''marketing'' argument is specious. [CMcC] Even if we stipulate that there are other facilities which would have marketing value to tcl, it does not follow that OO in core does not have marketing value to tcl. Therefore the argument is not specious. [DKF]: I actually would be quite happy to have more other "marketing" things in the core. But: 1. For distribution, there's excellent third-party solutions (and [trofs] is probably the way to move forward on this front). 1. 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... 1. 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. 1. 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. In all four cases, nobody's actually put a TIP together. I only have limited time and bandwidth myself... ---- '''There is a need for OO in the core''' 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. 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. [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''' Lets provide a simple definition of ''better''. If OO leads to less code, more stable applications, less effort for programmers, then we can generalise 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. The problem is providing concrete examples to provide as a comparison. This is the best I can come up with as a valid example. 1. TeX 2. Mozilla Both of the above applications have the same function. They take an abstract representation of the content of a document and create a formatted document for the purpose of viewing or printing. Both in the wider sense are still in development. Lets just take one aspect as proof of the point. 1. 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''. 1. Take the source code for the table layout of Gecko. If we compare these we find that there is more source code in the table layout code for Mozilla than there is in the entire TeX system! Since bugs are proportional to the number of lines of code, TeX must be more reliable than Mozilla. (''wow, that's a pretty big leap. TeX is almost certainly more reliable than Mozilla, but certain not simply because it has fewer lines of code...'') One of the tenents of OO is ''Code Reuse'', we should see that as more features are added to Mozilla, the less code is required. Since all new features are based on existing code, bug fixes in the old code should result in less bug fixes being required in the new code. From an OO point of view, there should be less code in Gecko than is required for TeX macros. The reverse situation is true. I propose that: * 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 maintaning Mozilla than there is in TeX. I propose from the above * TeX is more reliable than Mozilla. * pascal/C are ''better'' than C++ * Procedual 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. [http://www.science.uva.nl/~mes/jargon/t/troll.html] 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 OOfended 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. [jcw]'' [PWQ] ''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 cleary (from the replys) more than the supporters of TIP257 have. I posted a some points of view for the purpose of highlighting the inconsistant 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 need [DKF]: 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.[http://c2.com/cgi/wiki?TopMind] [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 syntex et al to be able to interface to. 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. ---- [[[Category Discussion]]]