Hello It's Friday and... well... Two things about Tcl going through my mind this week, a nice anecdote and a eyebrow-rising thing on Wikipedia: Anecdote: Until three months ago I worked in a scientific institue where I wrote much software in Tcl, especially a big Build and Report System, some tools for automatic checking of coding style and other things. Tcl had a bad reputation there (not because of me... they dropped Tcl before I started there in favour of Joy, then JavaScript and now Python) and besides me, there was only one co-worker who appearantly writes some small Tcl-Scripts to support other researchers in their work. To get completely rid of Tcl, they even started to reimplement all things, I wrote in Tcl in Python just to have it in a language, that most of them know (which is a good decision on the one hand, but on the other hand, I think, it would be better to simply learn Tcl ;-), which made me a little bit sad. Now there is a new collegue who has to maintain some of the things I wrote. Comming from Perl he wasn't exactly enthusiastic when he heard, that he must maintain my old code in such an obscure language.. Two weeks ago, I got mail from him. He's just studying a complex system of scripts that are used for a sandboxed build system for source code which comes from external untrusted source and must be compiled and tested. Of course it's written in Tcl (and some bash-Scripting). He told me, that although he has never looked at Tcl before, he was amazed how simple and well documented the code was, and how he understood almost immediately, what it means. Tcl seemed to be crystal clear to him and now he *is* very enthusiastic about it, and learns programming in Tcl. What's my point here? Tcl speaks for itself, you just have to look at it... I was really touched by that. Wikipedia: The other day I was just browsing through the articles about different programming languages, programming paradigms and related stuff on wikipedia just for fun. I found the "Categorical list of programming languages" (http://en.wikipedia.org/wiki/ Categorical_list_of_programming_languages), where languages are sorted by paradigms or categories. Tcl (and XOTcl) can be found eight times in the list in different categories, which is pretty much, I think. But reading through the list and the descriptions of what the categories mean, I found that Tcl is missing in many of the categories, although it clearly should be there: - "Command line interface languages" for batch processing and job control. Tcl is perfect for that, especially if expect is used. - "Interactive mode languages" where you can programm interactively seeing immediate results. Python is listed (for good reason), but not Tcl... Especially using wish for interactive GUI-development is a killer-app from my point of view... - "Interpreted languages" at least early Tcl was pure interpreted and is also today if you use it interactively or if you do not use [proc]s. - "Little languages" at least in the sense of the word, Tcl definitely is small, containing only its few syntax rules. - "Metaprogramming languages" the desription of that category seems to me to be one of the most used programming styles in Tcl... Am I missing some categories or wrong about the five above? Besides: Perl is not listed in the category of "Esoteric languages". Why is that? ;-) Regards Stephan
On Jun 22, 12:40 pm, skuha...@web.de wrote: > Hello > > It's Friday and... well... > > Two things about Tcl going through my mind this week, a nice anecdote > and a > eyebrow-rising thing on Wikipedia: > Right now I would say that 90% of the software development projects run by large commercial organizations are written in either .Net or Java. This is mainly because those languages are fully integrated with the .Net and Java application servers that provide the infrastructure for large scale enterprise applications clustered across multiple servers The other languages have been relegated to niche markets i.e small non critical single server applications and system administration. In ten years time it is quite likely that development in languages such as Tcl, Python, Perl, Ruby etc will have ceased as everyone will be coding in Groovy or Java:).
On Jun 22, 8:39 am, Patrick Finnegan <finnegan.patr...@gmail.com> wrote: > On Jun 22, 12:40 pm, skuha...@web.de wrote: > > > Hello > > > It's Friday and... well... > > > Two things about Tcl going through my mind this week, a nice anecdote > > and a > > eyebrow-rising thing on Wikipedia: > > Right now I would say that 90% of the software development projects > run by large commercial organizations are written in either .Net or > Java. This is mainly because those languages are fully integrated with > the .Net and Java application servers that provide the infrastructure > for large scale enterprise applications clustered across multiple > servers The other languages have been relegated to niche markets i.e > small non critical single server applications and system > administration. > > In ten years time it is quite likely that development in languages > such as Tcl, Python, Perl, Ruby etc will have ceased as everyone will > be coding in Groovy or Java:). The company I contract for still codes a lot of their stuff on a mainframe in Cobol. "Big business" is always the slowest and last to adopt better technology, but they, like everyone, will be forced to change eventually. Why do you think they bought our software? They're replacing their old mainframe system. Java is big and clunky, and while they may teach it as the be all end all of languages now, they did the same with Pascal 15 years ago. Anyone writing some Pascal these days? Anyone? I'm not saying Java doesn't have its place, but it's pretty well worthless in a lot of arenas. The smart people have already moved on from Java and are heading towards Python and Ruby. Not Tcl, of course, because it has no object system, and it's old and a silly language. Whatever. It doesn't matter. You'll find that the edge companies are starting to ditch Java, while the "big business" just uses what the advertisers tell them to use. Ultimately, if you're given a project, and one language will take you 20 hours to write said program, and the other language will take you 80 hours to write the same, exact program, which one would you rather code in? In the example, guess which is Java and which is <insert dynamic language of choice here>. Computers get faster and cheaper every year. Programmers don't. D
At 2007-06-22 07:40AM, "skuhagen@web.de" wrote: > think. But reading through the list and the descriptions of what the > categories > mean, I found that Tcl is missing in many of the categories, although > it clearly > should be there: The wonderful thing about wikis is that anyone can edit them (hint, hint). -- Glenn Jackman "You can only be young once. But you can always be immature." -- Dave Barry
On Jun 22, 3:26 pm, Damon Courtney <d...@installjammer.com> wrote: > On Jun 22, 8:39 am, Patrick Finnegan <finnegan.patr...@gmail.com> > wrote: > > > > > The smart people have already moved on from Java and are heading > towards Python and Ruby. Not Tcl, of course, because it has no object > system, and it's old and a silly language. Whatever. It doesn't > matter. You'll find that the edge companies are starting to ditch > Java, while the "big business" just uses what the advertisers tell > them to use. > > Ultimately, if you're given a project, and one language will take you > 20 hours to write said program, and the other language will take you > 80 hours to write the same, exact program, which one would you rather > code in? In the example, guess which is Java and which is <insert > dynamic language of choice here>. Computers get faster and cheaper > every year. Programmers don't. > > D Tcl is a great language but it has no traction in the corporate world. Java programmers will move to Groovy rather than Python or Ruby. I see people starting out with Groovey and progressing to Java for more complex performant applications.
In article <1182529396.126408.290450@u2g2000hsc.googlegroups.com>, Patrick Finnegan <finnegan.patrick@gmail.com> wrote: . . . >Tcl is a great language but it has no traction in the corporate >world. Java programmers will move to Groovy rather than Python or >Ruby. I see people starting out with Groovey and progressing to >Java for more complex performant applications. > > Heck, I see organizations take working applications coded in Tcl, and rewrite them in Java to gain performance. In fact they *lose* performance and functionality, and the rewrite takes more time than the original development, but those weren't the intentions, so ...
Damon Courtney schrieb: [snip] > > Ultimately, if you're given a project, and one language will take you > 20 hours to write said program, and the other language will take you > 80 hours to write the same, exact program, which one would you rather > code in? In the example, guess which is Java and which is <insert > dynamic language of choice here>. Computers get faster and cheaper > every year. Programmers don't. > > D > Big companies work on a different mind-set: You got xxx people in your department, all of them need to do something in order to make their managers look busy... from a financial point of view xxx people cost *nothing*. As a manager the best way (to promotion) is to avoid software reuse -- inside and outside of your company ---maybe a little within the project itself--- -- , and use the same coding system everybody in the food-chain agrees with. Ever followed the acm studies about average software-development efficiency from circa 1995-2005? An nearly 10% DROP anual over 10 years! -roger
On Jun 22, 9:14 pm, cla...@lairds.us (Cameron Laird) wrote: > In article <1182529396.126408.290...@u2g2000hsc.googlegroups.com>, > Patrick Finnegan <finnegan.patr...@gmail.com> wrote: > . > . > . > > >Tcl is a great language but it has no traction in the corporate > >world. Java programmers will move to Groovy rather than Python or > >Ruby. I see people starting out with Groovey and progressing to > >Java for more complex performant applications. > > Heck, I see organizations take working applications coded in > Tcl, and rewrite them in Java to gain performance. In fact > they *lose* performance and functionality, and the rewrite > takes more time than the original development, but those > weren't the intentions, so ... Totally agree. But the Architects want all applications to run on the same application server platform. Very few companies mix and match .Net and Java apps let alone Java, Perl, Tcl etc. I know of a large ISP that is moving all it's Apps from Perl to Java in order to take advantage of the Java application server platform, Java tooling and development frameworks like Spring and Hibernate. It may be faster to develop in Perl but Perl does not have a clear design methodology or s standard enterprise development specification. Personally I think Tcl is in a better position than Perl because Tcl is recognised in the industry as a great tool for writing cross platform GUI interfaces and there are not many choices out there for those who want to write cross platform desktop apps.
On Jun 22, 6:40 am, skuha...@web.de wrote: > Hello > > It's Friday and... well... > > Two things about Tcl going through my mind this week, a nice anecdote > and a > eyebrow-rising thing on Wikipedia: > > Anecdote: > Until three months ago I worked in a scientific institue where I wrote > much > software in Tcl, especially a big Build and Report System, some tools > for > automatic checking of coding style and other things. Tcl had a bad > reputation > there (not because of me... they dropped Tcl before I started there in > favour of > Joy, then JavaScript and now Python) and besides me, there was only > one > co-worker who appearantly writes some small Tcl-Scripts to support > other > researchers in their work. To get completely rid of Tcl, they even > started to > reimplement all things, I wrote in Tcl in Python just to have it in a > language, > that most of them know (which is a good decision on the one hand, but > on the > other hand, I think, it would be better to simply learn Tcl ;-), which > made me a > little bit sad. > > Now there is a new collegue who has to maintain some of the things I > wrote. Comming from Perl he wasn't exactly enthusiastic when he heard, > that he > must maintain my old code in such an obscure language.. > > Two weeks ago, I got mail from him. He's just studying a complex > system of > scripts that are used for a sandboxed build system for source code > which comes > from external untrusted source and must be compiled and tested. Of > course it's > written in Tcl (and some bash-Scripting). He told me, that although he > has never > looked at Tcl before, he was amazed how simple and well documented the > code was, > and how he understood almost immediately, what it means. Tcl seemed to > be > crystal clear to him and now he *is* very enthusiastic about it, and > learns > programming in Tcl. > > What's my point here? Tcl speaks for itself, you just have to look at > it... I > was really touched by that. > > Wikipedia: > > The other day I was just browsing through the articles about different > programming languages, programming paradigms and related stuff on > wikipedia just > for fun. I found the "Categorical list of programming languages" > (http://en.wikipedia.org/wiki/ > Categorical_list_of_programming_languages), where > languages are sorted by paradigms or categories. Tcl (and XOTcl) can > be found > eight times in the list in different categories, which is pretty much, > I > think. But reading through the list and the descriptions of what the > categories > mean, I found that Tcl is missing in many of the categories, although > it clearly > should be there: > > - "Command line interface languages" for batch processing and job > control. Tcl > is perfect for that, especially if expect is used. > - "Interactive mode languages" where you can programm interactively > seeing > immediate results. Python is listed (for good reason), but not > Tcl... Especially using wish for interactive GUI-development is a > killer-app > from my point of view... > - "Interpreted languages" at least early Tcl was pure interpreted and > is also > today if you use it interactively or if you do not use [proc]s. > - "Little languages" at least in the sense of the word, Tcl definitely > is small, > containing only its few syntax rules. > - "Metaprogramming languages" the desription of that category seems to > me to be > one of the most used programming styles in Tcl... > > Am I missing some categories or wrong about the five above? > > Besides: Perl is not listed in the category of "Esoteric languages". > Why is > that? ;-) > > Regards > Stephan I had the same experience at one place I worked. The product was moving from Solaris 8 to Solaris 10 and they had lost the source to the antiquated perl interpreter that they were using so they had to upgrade a bunch of scripts to use what was being provided by Solaris 10. It was my job to do this but given perl's syntax and strange variable usage not a whole lot was apparent as to how the scripts were doing their job. I even went to the authors to explain to me what certain lines mean't and they could not tell me. If the original authors could not read their own code what chance did I have. The purpose of each perl script was known; so I rewrote all the scripts in Tcl in almost no time at all. Don't know why but this really bent a few noses. "Why didnt you do it in Perl?" was the constant question. I would tell them for ease of maintenance. You can see what's going on without having to constantly reference a text book. I would tell them other reasons but their mind was made up the instant they found out it was Tcl. If they don't see a language mentioned in their magazines every time they pick one up it can't be any good. Tcl does not have the PR machine that Java, .Net and others have and for that reason alone it suffers. Carl
Hello > The smart people have already moved on from Java and are heading > towards Python and Ruby. Not Tcl, of course, because it has no object > system, and it's old and a silly language. Whatever. It doesn't > matter. Reminds of a similar conversation some days ago. Someone came in, saying something like: "Ah you guys, programming tickle-tackle, ha ha... Did that ten years ago, very primitive language, doesn't even have an object system. I'm programming Python now!" But some simple questions revealed that he doesn't even really know, what object orientation is, and where the benefits really are (if any). So it really doesn't matter, what the language really is, as long as you have the right buzzwords to promote it. I'm sure, people like him would switch immediately to Tcl, if they never have heard about it before and would come with the right buzzwords... But theres hope. As I wrote in my OP, the former colleague of mine switched to Tcl just because he read some real Tcl source (not the two- line-examples from the ads of hyped languages...) and loved it. I don't think, there are many languages out there, who have this kind of quality... Regards Stephan
Glenn Jackman wrote: > The wonderful thing about wikis is that anyone can edit them (hint, > hint). Yeah, right, but I'm no native english speaker/writer and I have some problems simply to botch someone others article. Stephan
Cameron Laird wrote: > >Tcl is a great language but it has no traction in the corporate > >world. Java programmers will move to Groovy rather than Python or > >Ruby. I see people starting out with Groovey and progressing to > >Java for more complex performant applications. > > Heck, I see organizations take working applications coded in > Tcl, and rewrite them in Java to gain performance. In fact > they *lose* performance and functionality, and the rewrite > takes more time than the original development, but those > weren't the intentions, so ... The problem is, who works with a language and who decides, which one is used... Although where I'm currently working, we use Tcl for the whole project, except for some C-Extensions for Tcl, you can see, that many people are uncomfortable using it. Not that they know anything better really (which one can see after 30 Seconds of asking the right questions), but they don't hear about Tcl in the news, so it must be useless. But the nice thing is, we get things really done here. The Tcl parts of the software move really fast towards completion and although they never would admit it in the public (because you get instant bashed for not telling the same about Java/Python whatever instead), people here are kind of impressed of Tcls power. Regards Stephan
Arndt Roger Schneider wrote: > Big companies work on a different mind-set: > You got xxx people in your department, all of them need to do something > in order to make their managers look busy... from a financial point of > view xxx people cost *nothing*. I don't think so. Otherwise there would be no good argument to fire hundreds or thousands of people ("workers") in big companies every time they change some of their organisation. > As a manager the best way (to promotion) is to avoid software reuse -- > inside and outside of your company ---maybe a little within the project > itself--- -- , and use the same coding system everybody in the > food-chain agrees with. This I totally agree with: No software reuse! is the secret slogan, and it's so brainless, that it sometimes make me laugh. > Ever followed the acm studies about average software-development > efficiency from circa 1995-2005? An nearly 10% DROP anual over 10 years! Are these numbers available somewhere? I find that really interesting. Stephan
Bezoar wrote: > On Jun 22, 6:40 am, skuha...@web.de wrote: > I had the same experience at one place I worked. The product was > moving from Solaris 8 to Solaris 10 and they had lost the source to > the antiquated perl interpreter Lost their interpreter...? Cool... "I lost my interpreter, I don't know what anything means anymore..." > authors could not read their own code what chance did I have. The > purpose of each perl script was known; so I rewrote all the scripts > in Tcl in almost no time at all. Don't know why but this really bent a > few noses. "Why didnt you do it in Perl?" was the constant question. I > would tell them for ease of maintenance. You can see what's going on > without having to constantly reference a text book. I would tell them > other reasons but > their mind was made up the instant they found out it was Tcl. Exactly. It doesn't matter how efficient it is, or if it simply works or anything else, as long it not the "right" language. That you ported from Perl to Tcl is a funny coincidence, since in my story the programmer came from Perl and as he started working there, he told about the coolness and power of Perl. I'm having no problem with that (I love to look and learn about other languages and other ideas about programming), but now he learning Tcl. But before he really looked at Tcl, there would have been no chance to convince him, that its a really good language. "Tcl...? Outdated crap... Pajaverlython? Hype, really cool, must use!" Regards Stephan
> Personally I think Tcl is in a better position than Perl because Tcl > is recognised in the industry as a great tool for writing cross > platform GUI interfaces and there are not many choices out there for > those who want to write cross platform desktop apps. No one cares about Tcl vs Perl these days. The 'hot' languages are Python and Ruby, with some interest growing in things like Erlang. Java really isn't that hot, but because there are massive amounts of it deployed, it will be with us for years to come. Also, I think that while...yes, there is certainly still a (large) market for cross platform desktop applications, a huge number of people prefer the economics of web programming: You still have cross platform issues, but they're the same ones everyone else has, and are limited to more or less three browsers. You can update your applications immediately - no deployment hassles! That's really a big win for small shops who don't want to dedicate lots of support time to N versions of something on N platforms. If we conclude that Tcl doesn't have any major technical defects, (it does have a few, but so do most of the other scripting languages), then the only conclusion that we can really come to is that it's a marketing issue, and that we as a community have done a terrible job at that. Some day I think I will attempt to write a "chapter" for this book on Tcl (well, not really for that book, but inspired by it): http://www.squeezedbooks.com/book/show/10/in-search-of-stupidity-over-twenty-years-of-high-tech-marketing-disasters-second-edition
In article <1182757493.863041.164710@k79g2000hse.googlegroups.com>, davidnwelton@gmail.com <davidnwelton@gmail.com> wrote: . . . >Also, I think that while...yes, there is certainly still a (large) >market for cross platform desktop applications, a huge number of >people prefer the economics of web programming: > >You still have cross platform issues, but they're the same ones >everyone else has, and are limited to more or less three browsers. > >You can update your applications immediately - no deployment hassles! >That's really a big win for small shops who don't want to dedicate >lots of support time to N versions of something on N platforms. . . . AND the licensing complexities are arguably an order of magnitude less. It remains *very* common for shrink-wrapped proprietary products to demand more time/hassle/education/... in licensing than functionality. Web applications have authentication and accounting that's rational, by comparison.
Stephan Kuhagen wrote: > Yeah, right, but I'm no native english speaker/writer and I have some > problems simply to botch someone others article. But you can just add text and let others fix up the language bugs. Wikis are great like that. Donal.
Cameron Laird wrote: > Web applications have > authentication and accounting that's rational, by comparison. On the other hand, web application security is a subject that ought to scare you. The scariest part is cross-site scripting, which some people tout as a benefit (calling it "mashups"). Donal.
On Jun 25, 3:44 am, "davidnwel...@gmail.com" <davidnwel...@gmail.com> wrote: > No one cares about Tcl vs Perl these days. Well, as far as I can tell, "no one" (except, of course, those programming in them) cares about Tcl OR Perl these days, let alone "vs"... > The 'hot' languages are > Python and Ruby, with some interest growing in things like Erlang. Weird - I seldom, if ever, hear anyone mention python (well, except here on comp.lang.tcl, where people seem obsessed with it) and have never (again, except here) have I heard anyone mention Erlang. I do have developers stop by to ask about Ruby. I seldom, however, see references to any of these in newsletters or magazine front cover stories, etc. I _do_ regularly see people writing about Java, Groovey, PHP, and .Net... > > If we conclude that Tcl doesn't have any major technical defects, (it > does have a few, but so do most of the other scripting languages), > then the only conclusion that we can really come to is that it's a > marketing issue, and that we as a community have done a terrible job > at that. Some day I think I will attempt to write a "chapter" for > this book on Tcl (well, not really for that book, but inspired by it): How much "marketing" do you see concerning COBOL, FORTRAN, C, and assembly languages? And yet, thousands, if not millions, of developers every day are working on programs in those languages. What has happened is that the masses of writers have moved on to "the next great thing" while the current great languages continue to be used without complaint. The primary complaint that I know that I see is a general issue which cuts across ALL dynamic languages - a prejudice against "scripting languages" as not being "real programming languages" and scripts not being "real programs".
Larry W. Virden wrote: > Weird - I seldom, if ever, hear anyone mention python (well, except > here on comp.lang.tcl, where people seem obsessed with it) and have > never (again, except here) have I heard anyone mention Erlang. I do > have developers stop by to ask about Ruby. I seldom, however, see > references to any of these in newsletters or magazine front cover > stories, etc. I _do_ regularly see people writing about Java, Groovey, > PHP, and .Net... FWIW, for new development I see mainly Java and C# interest, with some Ruby but not that much. (The Ruby fans are regarded as something like heretics, but then a lot of what we do doesn't map nicely to the Rails environment and that's the biggest thing in Ruby's favour.) There's also lots of "legacy support", which round here means mainly Fortran, C and C++, plus some Perl. Tcl's very much a minority pursuit (along with many other languages too to be fair, including Python!) Most of the really advanced development I see takes place at levels of abstraction where conventional programming languages aren't used. I'm not sure that this is a long-term trend though; I suspect it's really a retrograde step that will be reversed in the future as people rediscover the expressiveness of languages. Donal.
On Jun 25, 2:26 pm, "Larry W. Virden" <lvir...@gmail.com> wrote: > On Jun 25, 3:44 am, "davidnwel...@gmail.com" <davidnwel...@gmail.com> > wrote: > > > No one cares about Tcl vs Perl these days. > > Well, as far as I can tell, "no one" (except, of course, those > programming in them) cares about Tcl OR Perl these days, let alone > "vs"... Precisely. Someone commented on some supposed advantage of Tcl over Perl, which is, at this point, not the right battle to be fighting. > > The 'hot' languages are > > Python and Ruby, with some interest growing in things like Erlang. > > Weird - I seldom, if ever, hear anyone mention python (well, except > here on comp.lang.tcl, where people seem obsessed with it) and have > never (again, except here) have I heard anyone mention Erlang. I do > have developers stop by to ask about Ruby. I seldom, however, see > references to any of these in newsletters or magazine front cover > stories, etc. I _do_ regularly see people writing about Java, Groovey, > PHP, and .Net... Java, .Net and PHP are languages that are already big (for that matter, Python isn't doing so bad either - Google uses it...). What I'm talking about are the languages with buzz and hype going for them. Ruby has this in spades. When you compare it to Tcl, it does ok - it's got some nice things, but it's not like it's an order of magnitude better: http://journal.dedasys.com/articles/2006/03/06/ruby-vs-tcl > > If we conclude that Tcl doesn't have any major technical defects, (it > > does have a few, but so do most of the other scripting languages), > > then the only conclusion that we can really come to is that it's a > > marketing issue, and that we as a community have done a terrible job > > at that. Some day I think I will attempt to write a "chapter" for > > this book on Tcl (well, not really for that book, but inspired by it): > > How much "marketing" do you see concerning COBOL, FORTRAN, C, and > assembly languages? What those have going for them are the lock-in effects associated with the switching costs of massive deployments of production systems, which are pretty much insurmountable for many systems and companies. That's not, however, the same thing as what people are using to write new code with. > The primary complaint that I know that I see is a general issue which > cuts across ALL dynamic languages - a prejudice against "scripting > languages" as not being "real programming languages" and scripts not > being "real programs". I guess... in some environments. Perhaps they're ripe to be beaten by a small, agile startup that doesn't care about fossilized attitudes. Like Damon said, the economics of more productive languages do count, in the end, once you've factored out other things.
skuhagen@web.de wrote: > > What's my point here? Tcl speaks for itself, you just have to look at > it... I > was really touched by that. This is one reason I am not terribly concerned with Tcl (or Tk) from a marketing standpoint. There will always be something more fashionable. I develop desktop GUI apps on Mac OS X, and I get nothing but grief from other Mac developers who consider Tk ugly and Tcl deficient because it doesn't have bindings to the flagship Apple framework, Cocoa. (Other scripting langauges, such as Perl, Ruby and Python, do.) The snobbery gets quite out of hand sometimes; the old stereotypes about the Mac being more about eye candy and aesthetics than utility do have a nugget of truth to them. :-) I don't think Tcl is the only language one should use, of course. I've added Python as a second main language because it does some things that Tcl simply can't do (such as writing an sftp client, which is on my list of projects). Python's large standard library make it a bit more robust than Tcl, and a nice complement to Tcl's compactness. It also matches Tcl for easy of deployment in terms of wrapping desktop apps (py2app/py2exe are pretty close to starkits and starpacks). Ruby, though more fashionable, and Perl, though it has a larger developer community, are actually conspicuously weak for deployment of standalone desktop apps, at least on the Mac. My point is, Tcl/Tk are here and are actively developed. As long as the community does a modest amount of marketing (and the recent update of http://www.tcl.tk is a good start), I think it will continue to attract developers. The resources that the community offers--such as c.l.t and the wiki--also help to ensure that it will remain viable. -- Kevin Walzer Code by Kevin http://www.codebykevin.com
On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote: > There will always be something more fashionable. I > develop desktop GUI apps on Mac OS X, and I get nothing but grief from > other Mac developers who consider Tk ugly and Tcl deficient because it > doesn't have bindings to the flagship Apple framework, Cocoa. So is there a _technical_ reason why Tcl doesn't have a Cocoa binding? > the old stereotypes about the Mac > being more about eye candy and aesthetics than utility do have a nugget > of truth to them. :-) Yep - same for Windows, GNOME, KDE, etc.... It wouldn't surprise me if 50% or more of the "I wish Tcl would do...." type conversations had more to do with a desire to justify one's choice in tools than with a real need for such features. > > it does some things that > Tcl simply can't do (such as writing an sftp client, which is on my list > of projects). Hmm - "can't" do? That seems a bit strong. There's some technical deficiency that makes it impossible to write such a thing in tcl? > Python's large standard library make it a bit more robust > than Tcl, and a nice complement to Tcl's compactness. I'd love to see a comparison of the python standard library and the tcl standard library, comparing what each has and each is missing, just to give some of those looking for useful areas to code something to aim towards.
Larry W. Virden wrote: > On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote: >> There will always be something more fashionable. I >> develop desktop GUI apps on Mac OS X, and I get nothing but grief from >> other Mac developers who consider Tk ugly and Tcl deficient because it >> doesn't have bindings to the flagship Apple framework, Cocoa. > > > So is there a _technical_ reason why Tcl doesn't have a Cocoa binding? Yeah. No one's written one. :-) > > >> the old stereotypes about the Mac >> being more about eye candy and aesthetics than utility do have a nugget >> of truth to them. :-) > > Yep - same for Windows, GNOME, KDE, etc.... > > It wouldn't surprise me if 50% or more of the "I wish Tcl would > do...." type conversations had more to do with a desire to justify > one's choice in tools than with a real need for such features. > >> it does some things that >> Tcl simply can't do (such as writing an sftp client, which is on my list >> of projects). > > > Hmm - "can't" do? That seems a bit strong. There's some technical > deficiency that makes it impossible to write such a thing in tcl? > I don't know if there's a technical reason or not. But there's a Python library called Paramikio which implements ssh in Python, including sftp; it builds on top of another library, pycrypto, which provides cryptography. No equivalent extension exists in Tcl to my knowledge. > > >> Python's large standard library make it a bit more robust >> than Tcl, and a nice complement to Tcl's compactness. > > I'd love to see a comparison of the python standard library and the > tcl standard library, comparing what each has and each is missing, > just to give some of those looking for useful areas to code something > to aim towards. I've just named a couple, in case anyone is interested. Alas I lack the C-level chops to do it myself. :-( -- Kevin Walzer Code by Kevin http://www.codebykevin.com
Kevin Walzer wrote: > Larry W. Virden wrote: >> On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote: >>> There will always be something more fashionable. I >>> develop desktop GUI apps on Mac OS X, and I get nothing but grief from >>> other Mac developers who consider Tk ugly and Tcl deficient because it >>> doesn't have bindings to the flagship Apple framework, Cocoa. >> >> >> So is there a _technical_ reason why Tcl doesn't have a Cocoa binding? > > Yeah. No one's written one. :-) > >> >> >>> the old stereotypes about the Mac >>> being more about eye candy and aesthetics than utility do have a nugget >>> of truth to them. :-) >> >> Yep - same for Windows, GNOME, KDE, etc.... >> >> It wouldn't surprise me if 50% or more of the "I wish Tcl would >> do...." type conversations had more to do with a desire to justify >> one's choice in tools than with a real need for such features. >> >>> it does some things that >>> Tcl simply can't do (such as writing an sftp client, which is on my list >>> of projects). >> >> >> Hmm - "can't" do? That seems a bit strong. There's some technical >> deficiency that makes it impossible to write such a thing in tcl? >> > > I don't know if there's a technical reason or not. But there's a Python > library called Paramikio which implements ssh in Python, including sftp; > it builds on top of another library, pycrypto, which provides > cryptography. No equivalent extension exists in Tcl to my knowledge. I *think* tls and trf get you most of the way there, it is just sftp protocol piece is missing. > >> >> >>> Python's large standard library make it a bit more robust >>> than Tcl, and a nice complement to Tcl's compactness. >> >> I'd love to see a comparison of the python standard library and the >> tcl standard library, comparing what each has and each is missing, >> just to give some of those looking for useful areas to code something >> to aim towards. > > I've just named a couple, in case anyone is interested. Alas I lack the > C-level chops to do it myself. :-( > -- +--------------------------------+---------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+
skuhagen@web.de schrieb: > Arndt Roger Schneider wrote: > > >>Big companies work on a different mind-set: >>You got xxx people in your department, all of them need to do something >>in order to make their managers look busy... from a financial point of >>view xxx people cost *nothing*. > > > I don't think so. Otherwise there would be no good argument to fire > hundreds or thousands of people ("workers") in big companies every > time they change some of their organisation. There are shareholder-reasons for this behavior. The people on the payroll represent fix-costs -- bad shareholder-vise. After the people got fired, new people are contracted back in, because these costs are now "investments". > > >>As a manager the best way (to promotion) is to avoid software reuse -- >>inside and outside of your company ---maybe a little within the project >>itself--- -- , and use the same coding system everybody in the >>food-chain agrees with. > > > This I totally agree with: No software reuse! is the secret slogan, > and it's so brainless, that it sometimes make me laugh. Precisly the field where scripting languages excel! > > >>Ever followed the acm studies about average software-development >>efficiency from circa 1995-2005? An nearly 10% DROP anual over 10 years! > > > Are these numbers available somewhere? I find that really interesting. > > Stephan > i did read this in the acm print-magazin -- don't press me for the actual year, though... (don't have them myself). Here's a similar piece: http://spot.pcc.edu/~mtrigobo/files/uncladEmperor.pdf "The Emperor with No Clothes" from Henry F. Ledgard .... happy hunting.
On Jun 25, 1:35 pm, Kevin Walzer <k...@codebykevin.com> wrote: > Larry W. Virden wrote: > >> Tcl simply can't do (such as writing an sftp client, which is on my list > >> of projects). > > > Hmm - "can't" do? That seems a bit strong. There's some technical > > deficiency that makes it impossible to write such a thing in tcl? > > I don't know if there's a technical reason or not. But there's a Python > library called Paramikio which implements ssh in Python, including sftp; > it builds on top of another library, pycrypto, which provides > cryptography. No equivalent extension exists in Tcl to my knowledge. I see in the descriptions of tclcurl http://personal1.iddeo.es/andresgarci/tclcurl/english/docs.html a reference to getting data via SFTP (among other) . This is via the binding to libcurl. >From my (admittedly brief) perusal of the web, it looks to me like there are sftp clients, and an sftp protocol. But I also seem to see discussions that the proposed standard for sftp the protocol has seemed to stagnent at version 6, and that sftp servers appear to be "stabilized" supporting either version 2 or 3 of the proposed standard. I'm uncertain exactly what, among all that chaos, you were seeking, but maybe tclcurl has enough support for what you want?
Larry W. Virden wrote: > On Jun 25, 1:35 pm, Kevin Walzer <k...@codebykevin.com> wrote: >> Larry W. Virden wrote: >>>> Tcl simply can't do (such as writing an sftp client, which is on my list >>>> of projects). >>> Hmm - "can't" do? That seems a bit strong. There's some technical >>> deficiency that makes it impossible to write such a thing in tcl? >> I don't know if there's a technical reason or not. But there's a Python >> library called Paramikio which implements ssh in Python, including sftp; >> it builds on top of another library, pycrypto, which provides >> cryptography. No equivalent extension exists in Tcl to my knowledge. > > > I see in the descriptions of tclcurl > http://personal1.iddeo.es/andresgarci/tclcurl/english/docs.html > a reference to getting data via SFTP (among other) . This is via the > binding to libcurl. > >>From my (admittedly brief) perusal of the web, it looks to me like > there are sftp clients, and an sftp protocol. But I also seem to see > discussions that the proposed standard for sftp the protocol has > seemed to stagnent at version 6, and that sftp servers appear to be > "stabilized" supporting either version 2 or 3 of the proposed > standard. > > I'm uncertain exactly what, among all that chaos, you were seeking, > but maybe tclcurl has enough support for what you want? > > I had forgotten about tclurl. However, there's a complex chain of dependencies at work here; curl itself must link to a non-standard library (libssh2) to get sftp support, and then one has to build Tclurl on top of that. Plus, since I'm doing this on the Mac, everything has to be built as a universal binary. Because there are so many moving parts, I've never gotten everything to build correctly. -- Kevin Walzer Code by Kevin http://www.codebykevin.com
On Jun 26, 1:40 am, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote: > Kevin Walzer wrote: > > Larry W. Virden wrote: > >> On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote: > >>> There will always be something more fashionable. I > >>> develop desktop GUI apps on Mac OS X, and I get nothing but grief from > >>> other Mac developers who consider Tk ugly and Tcl deficient because it > >>> doesn't have bindings to the flagship Apple framework, Cocoa. > > >> So is there a _technical_ reason why Tcl doesn't have a Cocoa binding? > > > Yeah. No one's written one. :-) > > >>> the old stereotypes about the Mac > >>> being more about eye candy and aesthetics than utility do have a nugget > >>> of truth to them. :-) > > >> Yep - same for Windows, GNOME, KDE, etc.... > > >> It wouldn't surprise me if 50% or more of the "I wish Tcl would > >> do...." type conversations had more to do with a desire to justify > >> one's choice in tools than with a real need for such features. > > >>> it does some things that > >>> Tcl simply can't do (such as writing an sftp client, which is on my list > >>> of projects). > > >> Hmm - "can't" do? That seems a bit strong. There's some technical > >> deficiency that makes it impossible to write such a thing in tcl? > > > I don't know if there's a technical reason or not. But there's a Python > > library called Paramikio which implements ssh in Python, including sftp; > > it builds on top of another library, pycrypto, which provides > > cryptography. No equivalent extension exists in Tcl to my knowledge. > > I *think* tls and trf get you most of the way there, it is just sftp > protocol piece is missing. > Except for the crypto parts, tls won't help much. Heck, tcllib already does blowfish, AES and DES, which covers the encryption mechanism used by SSH (SFTP is a subset of the SSH protocol). So you don't even need tls. We only need to implement the SSH protocol. OK, the digital certificates part can be taken from tls so tls would be helpful there.
Kevin Walzer wrote: > Larry W. Virden wrote: >> I'd love to see a comparison of the python standard library and the >> tcl standard library, comparing what each has and each is missing, >> just to give some of those looking for useful areas to code something >> to aim towards. > > I've just named a couple, in case anyone is interested. Alas I lack the > C-level chops to do it myself. :-( Even just the comparisons *from a script-level perspective* are valuable since they indicate areas where effort may be applied. And look, that doesn't require any knowledge of C. :-) Donal.
davidnwelton@gmail.com wrote: > What I'm talking about are the languages with buzz and hype going for > them. Ruby has this in spades. They're nicely placed in an area that's currently "hot" (server support for small webapps) that's all. Donal.
davidnwelton wrote: > Larry W. Virden wrote: > > How much "marketing" do you see concerning COBOL, FORTRAN, C, and > > assembly languages? > What those have going for them are the lock-in effects associated with > the switching costs of massive deployments of production systems, > which are pretty much insurmountable for many systems and companies. > That's not, however, the same thing as what people are using to write > new code with. I disagree. Well, I don't know about COBOL, that may be a lock-in effect (based on platform, as well as language). If I recall correctly, FORTRAN still does some very nice things with being efficient, over and above well-written C on the average compiler. (This may no longer be the case. It's been a while.) C and assembly certainly have a a place that is not simply retained by lock-in. There are still markets where the overhead of anything fancier is too expensive. There are still niche markets where 8-bit micros are used for cost considerations. As assembly goes, sometimes it's the only tool for the job. Admittedly, anyone who is running and maintaining a DBMS coded in assembly has either been subject to extreme lock-in, or is severely deranged. -- MKS
Melissa Schrumpf wrote: > Admittedly, anyone who is running and maintaining a DBMS coded in > assembly has either been subject to extreme lock-in, or is severely > deranged. If they're deranged like that, they'll be subject to a different sort of "extreme lock-in" involving padded cells... Donal.
On Jun 27, 1:13 am, "Donal K. Fellows" <donal.k.fell...@manchester.ac.uk> wrote: > Melissa Schrumpf wrote: > > Admittedly, anyone who is running and maintaining a DBMS coded in > > assembly has either been subject to extreme lock-in, or is severely > > deranged. > > If they're deranged like that, they'll be subject to a different sort of > "extreme lock-in" involving padded cells... > > Donal. Well, there's always the military. A friend of mine worked for the US Air Force in the late 1970s. They did inventory, using programs originally written in Fortran. The machines did not do multitasking. To compile, you first loaded the compiler and ran the source through. Then you loaded the assembler and ran the output of the previous pass through and got an object deck. Then you loaded the program and ran it, resulting in an output deck. Then you loaded the output deck and printed it. This procedure was so slow that before my friend got there they had ceased to modify the Fortran sources and just patched everything directly in machine language. Not assembler, machine language.
On Jun 27, 2:01 am, Melissa Schrumpf <m_schrumpf_at_yahoo_com_...@microsoft.com> wrote: > davidnwelton wrote: > > Larry W. Virden wrote: > > > How much "marketing" do you see concerning COBOL, FORTRAN, C, and > > > assembly languages? > > What those have going for them are the lock-in effects associated with > > the switching costs of massive deployments of production systems, > > which are pretty much insurmountable for many systems and companies. > > That's not, however, the same thing as what people are using to write > > new code with. > > I disagree. Well, I don't know about COBOL, that may be a lock-in > effect (based on platform, as well as language). If I recall correctly, > FORTRAN still does some very nice things with being efficient, over > and above well-written C on the average compiler. (This may no longer > be the case. It's been a while.) > C and assembly certainly have a a place that is not simply retained by > lock-in. There are still markets where the overhead of anything fancier > is too expensive. There are still niche markets where 8-bit micros > are used for cost considerations. Sure, FORTRAN and C have some good qualities, but they're not the only fast languages out there - just that they've come to dominate their niches. Because they're so widely used, they are the natural, default choices for an array of programming tasks. Tcl is not in that fortunate situation, so the original comparison "those languages don't need marketing" is not really relevant in any case.
Melissa Schrumpf wrote: > C and assembly certainly have a a place that is not simply retained by > lock-in. There are still markets where the overhead of anything fancier > is too expensive. There are still niche markets where 8-bit micros > are used for cost considerations. Plus, many of those microcomputers are designed to be programmed in a C-like language. One can build microcomputer CPUs designed to run (say) FORTH, with just as low overhead, on which C would run poorly. But since C might run poorly on such an architecture, they never really make it to wide-spread market adoption. -- Darren New / San Diego, CA, USA (PST) I bet exercise equipment would be a lot more expensive if we had evolved from starfish.
In article <f5t684$1mg8$1@godfrey.mcc.ac.uk>, Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote: >Melissa Schrumpf wrote: >> Admittedly, anyone who is running and maintaining a DBMS coded in >> assembly has either been subject to extreme lock-in, or is severely >> deranged. > >If they're deranged like that, they'll be subject to a different sort of >"extreme lock-in" involving padded cells... > >Donal. Do see, however, http://en.wikipedia.org/wiki/Charles_H._Moore.
Darren New wrote: > Melissa Schrumpf wrote: > > C and assembly certainly have a a place that is not simply retained by > > lock-in. There are still markets where the overhead of anything fancier > > is too expensive. There are still niche markets where 8-bit micros > > are used for cost considerations. > Plus, many of those microcomputers are designed to be programmed in a > C-like language. Strictly-speaking, are they, or have the embedded-target C compilers just been optimized for so long that they just happen to be the best tools available? > One can build microcomputer CPUs designed to run (say) > FORTH, with just as low overhead, on which C would run poorly. True. The first time I encountered OpenBoot, I was astonished that it handled what appeared to be a "remedial shell" so quickly. Until I learned that it was simply made to run forth, and about FCode. :-)~ > But since C might run poorly on such an architecture, they never really > make it to wide-spread market adoption. But it's not C itself that runs on the processor, it's the machine code to which it is ultimately converted. Isn't it more a matter that the optimal language for any system would be that which most closely reflects the underlying architecture, so that compiler abstractions need not be overly lossy? -- MKS
billposerwrote: > Donal K. Fellows wrote: > > Melissa Schrumpf wrote: > > > Admittedly, anyone who is running and maintaining a DBMS coded in > > > assembly has either been subject to extreme lock-in, or is severely > > > deranged. > > > > If they're deranged like that, they'll be subject to a different sort of > > "extreme lock-in" involving padded cells... > > Well, there's always the military. QED. > A friend of mine worked for the US > Air Force in the late 1970s. They did inventory, using programs > originally written in Fortran. The machines did not do multitasking. > To compile, you first loaded the compiler and ran the source through. > Then you loaded the assembler and ran the output of the previous pass > through and got an object deck. Then you loaded the program and ran > it, resulting in an output deck. Then you loaded the output deck and > printed it. But... that's more or less how compiling works, right? It's not so much a matter of multitasking as serial-tasking without intermediate output steps. Just that the machine didn't have appropriate temporary storage. > This procedure was so slow that before my friend got there > they had ceased to modify the Fortran sources and just patched > everything directly in machine language. Not assembler, machine > language. Sounds more fun that way, actually. -- MKS
Melissa Schrumpf wrote: >> Plus, many of those microcomputers are designed to be programmed in a >> C-like language. > > Strictly-speaking, are they, or have the embedded-target C compilers > just been optimized for so long that they just happen to be the best > tools available? I've worked with several mainframes that were unable to support C. They were some of the most powerful mainframes of their time. Try to sell any CPU nowadays that can't support C and see what happens. I'm not talking about just embedded stuff - to me, "microcomputer" includes anything not designed for I/O over compute speed. :-) (Of course you can support C on any machine by either writing an interpreter or letting undefined things really crash the machine. Not very efficient tho. Plus, of course, there are *some* really small "postage-stamp" style machines that (say) only run PIC-Basic or some such, but they really aren't too general purpose either.) >> But since C might run poorly on such an architecture, they never really >> make it to wide-spread market adoption. > > But it's not C itself that runs on the processor, it's the machine code > to which it is ultimately converted. Isn't it more a matter that the > optimal language for any system would be that which most closely > reflects the underlying architecture, so that compiler abstractions need > not be overly lossy? Well, take for example a Burroughs B-series machine. Each memory location was tagged with the type of data stored there. You couldn't take an integer and store it into a pointer variable. You couldn't have a union of a double and a long. You couldn't implement something like printf() that took variable types of arguments in different calls. The CPU "add" instruction just had the addresses of the operands to add, and took the types of the data stored at those addresses to figure out whether to add floats, add integers, etc. You could run C on such a machine only by writing an interpreter for it. OTOH, Pascal and Algol ran fine. C makes some assumptions about your architecture that, if your architecture doesn't support it, complex C programs won't run. That ints and pointers are interchangable, that there's an address type that can point to any address (i.e., that it's possible to have a void*), that it's possible to take the address of a function and branch to it, that all your data is in the same address space at the same time, and so on. I've used embedded systems where it wasn't possible to take the address of a function, for example, because each function was in its own address space due to address paging translation sorts of things. Or a machine that has a block of memory for integers, a block of memory for floats, etc. That would work fine for BASIC and APL (and maybe old FORTRANs?), and C just plain wouldn't run. You don't see those sorts of architectures any more. Nor do you often see architectures targeted at other languages, like having the COBOL-specific opcodes lots of mainframes used to have. Popular languages influence CPU design at least to that extent. -- Darren New / San Diego, CA, USA (PST) I bet exercise equipment would be a lot more expensive if we had evolved from starfish.
On Jun 29, 2:19 am, Melissa Schrumpf <m_schrumpf_at_yahoo_com_...@microsoft.com> wrote: > > > > If they're deranged like that, they'll be subject to a different sort of > > > "extreme lock-in" involving padded cells... > > > Well, there's always the military. > > QED. Joke of the month at least ! (Just imagine this with the voices of Homer and Marge...) -Alex
On Jun 28, 5:19 pm, Melissa Schrumpf <m_schrumpf_at_yahoo_com_...@microsoft.com> wrote: > But... that's more or less how compiling works, right? It's not so much > a matter of multitasking as serial-tasking without intermediate output > steps. Just that the machine didn't have appropriate temporary storage. > > > This procedure was so slow that before my friend got there > > they had ceased to modify the Fortran sources and just patched > > everything directly in machine language. Not assembler, machine > > language. > > Sounds more fun that way, actually. > > -- > MKS True, it isn't a matter of multitasking exactly. I was just listing archaic features of the machine. And I forget the linking pass. I actually learned to program this way. My high school was far from high tech, but was close to a major IBM site, so IBM gave the school an old computer and one of the math teachers learned to run it. We learned Fortran (like God meant it to be, not the almost bearable new- fangled kind) with input via punch cards. The machine had a disk, but it was full of school records so we weren't allowed to create disk files. In addition to our programming class (almost all guys) there was a vocational "data entry" class, all girls. Such were the priorities in our school that we were required to give up the card punch machine to the girls taking data entry whenever they wanted to use them. The card punch machine we had was the kind that didn't print the text on the card (model 028?). I'm not impressed by people who whine about the command line or how hard anything other than a Mac is impossible to use: I thought that the next model up (029?), which printed the text at the top of the card, was a huge improvement in user-interface, and later, when I got to use a terminal with a line- editor, that was hog-heaven!