Two interesting tcl posts on reddit
in [TCL]
|
Prev: Text on canvas
Next: Global hotkeys under X11
From: David N. Welton on 31 Mar 2010 18:20 On Mar 31, 10:44 pm, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > The deep problem is a fundamental difference between Apache2's thread > model and Tcl's. (IIRC, they assume a shared memory model and Tcl uses > an apartment model.) That made porting Rivet to a more recent Apache > than it was designed for almost impossible. > > Or at least that was how I understood it. You can make Tcl work with Apache2 as long as you stick to the prefork model (Websh does this just fine), and you could probably get things working with threads if you put some serious effort into it, but it got to be something that was just not an itch I wanted to scratch by myself, and by the time others came along to work on it, I was already getting busy with other things. Incidentally, IIRC, Rasmus of PHP fame also was unenthusiastic about the threaded Apache2 hassle for a long time, and continued to recommend Apache 1.3 where at all possible. Along those lines, the trendy web server these days is nginx, which is an event-based system... Also, for Tom, Rivet was usable enough for Karl Lehenbauer to base this site/company on it: http://flightaware.com/ At least originally - I don't know what it's running these days, but there are still .rvt extensions here and there. Building a company on a "niche" technology is a much more sensible approach than trying to do consulting; you don't have to worry nearly as much about selling anyone on the technology, you just get on with making a product. I on the other hand was trying to both develop the underlying system, get people to use it, and do work based on it, which was just too much.
From: tom.rmadilo on 31 Mar 2010 21:03 On Mar 31, 1:44 pm, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > On 31 Mar, 17:20, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > > > The second article is only interesting as one person's opinion based > > upon a somewhat unsuccessful project: Apache Rivet...one of several > > not very usable Tcl engines for Apache, and also based upon his > > knowledge of public/open source projects. > > The deep problem is a fundamental difference between Apache2's thread > model and Tcl's. (IIRC, they assume a shared memory model and Tcl uses > an apartment model.) That made porting Rivet to a more recent Apache > than it was designed for almost impossible. My main point is that Rivet is embedded in Apache, which has a rather unfortunate API. This architecture, forked or threaded doesn't make good use of Tcl's model. If the article stuck to noticing that Tcl doesn't work very well with Apache, all is fine, but Tcl works well outside of Apache. Does PHP? If you use threads, how well do the other languages stack up? If one interaction requires multiple threads to communicate with each other before returning a response, is this possible with other languages? If you have multiple CPUs, can you take advantage of this within one application? Apache works great for 10k low volume independent hosts, but not so well for one high volume host that might even span many physical machines. Tcl is also a safe language. Part of this safely is gained by a hidden interface. It is hidden because nobody refers to it as an interface. This is the hash table. The hash table forces application code to use strings to look up references to objects which exist. Some languages allow you to make up a reference and possibly access non-application objects, or just crash the application. Tcl forces you to know the name of the resource as well as the domain. Files are stored in one hash table (domain), commands in another.
From: tomk on 1 Apr 2010 12:26 On Mar 31, 3:07 pm, "David N. Welton" <davidnwel...(a)gmail.com> wrote: > > The comments about Tk seems > > strange: it is so easy to use, there are too many examples of poorly > > designed applications floating around. > > It's not a problem limited to Tk. PHP has the exact same problem: it > made web stuff really easy, but gained a lot of users who did not > write good code. Lowering the barrier to entry is generally a > positive thing, but it often results in a lot of "marginal" > programmers and projects. Over time, with PHP, that has given the > resulting code a less than stellar reputation (and it doesn't help > that the language itself isn't really a thing of beauty, either). > It's something you have to manage, and in hindsight, the Tk community > probably ought to have done more to foster a culture of creating good > GUIs. If you look at otherwise excellent books, like Brent Welch's, > you'll find all kinds of details about how to use the Tk widgets, but > not much material telling the reader how to go about creating a "good" > GUI. > > The point is that "enabling" people isn't enough, you have to help > give them some direction too, which is ultimately a cultural thing, > rather than a technological thing. > > > Also not very clear why php is > > included in the list of languages. > > I'm not sure I follow you. PHP is a programming language that is very > widely used, which makes it quite sensible to compare it to Tcl. I wound up using PHP for my web applications (instead of tcl) mostly because it integrated well with MySQL. What I found interesting was how popular it was and yet how totally screwed up the language was. In particular the Class stuff was basically a joke that was unuseable. This was eventually fixed in a later major release but that release completely broke all my old code. I think the its popularity was a direct result of the batteries included++ approch used by the PHP community and the developers focus on web applications. A lot of the stuff that distributed may be broken but it gives new users the feeling that it is a serious language. I think both of these observations reinforce what David said in his article, but with a slight twist. I consider PHP to be a nich language that only competes for web application. Tcl on the other hand is a far more flexible language that can compete in virtually any application space but tends to be viewed poorly in most because it doesn't have "more" than anyone elses language in any of the application spaces. So to sum up, if you want to be a popular language: 1) focus on one application space 2) provide everything including the kitchen sink right from the start (even if they doesn't work) 3) make major changes to the language when substantive problems become apparent (even if it breaks backwards compatibility) Or you can take the slow and steady tcl approach. tomk
From: Robert H on 1 Apr 2010 18:47 On Mar 31, 6:20 pm, "David N. Welton" <davidnwel...(a)gmail.com> wrote: > > You can make Tcl work with Apache2 as long as you stick to the prefork > model (Websh does this just fine), and you could probably get things > working with threads if you put some serious effort into it, but it > got to be something that was just not an itch I wanted to scratch by > myself, and by the time others came along to work on it, I was already > getting busy with other things. > What was Rivet trying to solve that websh didn't do? Robert
From: David N. Welton on 2 Apr 2010 02:18
On Apr 1, 6:26 pm, tomk <krehbiel....(a)gmail.com> wrote: > I wound up using PHP for my web applications (instead of tcl) mostly > because it integrated > well with MySQL. What I found interesting was how popular it was and > yet how totally screwed up > the language was. In particular the Class stuff was basically a joke > that was unuseable. This This is part of what made me so curious about the situation. I still think of Tcl as a first-rate language developed by first-rate people. If you accept that, you have to look elsewhere, at human/marketing/ economics factors for its declining popularity. > 1) focus on one application space That's actually fairly similar to the strategy proposed in a well- known business book, "Crossing the Chasm": http://www.squeezedbooks.com/book/show/14/crossing-the-chasm > 2) provide everything including the kitchen sink right from the start > (even if they doesn't work) > 3) make major changes to the language when substantive problems become > apparent (even if it breaks > backwards compatibility) The backwards compatibility issue is tricky, and something I hinted at in the article that Erlang suffers from as well. Erlang had a big, important early adopter in Ericsson, which was good because they paid people to work on the language. It was also bad because they lost the freedom to radically modify their language fairly early on, and so it has some fairly odd warts that they will not be able to change easily. Managing that is certainly tricky. |