Home > Archive > Tcl > June 2007 > How Tcl speaks for itself and how Tcl is not spoken for...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How Tcl speaks for itself and how Tcl is not spoken for...
|
|
| skuhagen@web.de 2007-06-22, 8:11 am |
| Hello
It's Friday and... well...
Two things about Tcl going through my mind this w , 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  .
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 ws 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_language
s), 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
| |
| Patrick Finnegan 2007-06-23, 4:18 am |
| 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 w, 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:).
| |
| Damon Courtney 2007-06-23, 4:18 am |
| On Jun 22, 8:39 am, Patrick Finnegan <finnegan.patr...@gmail.com>
wrote:
> On Jun 22, 12:40 pm, skuha...@web.de wrote:
>
>
>
>
> 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
| |
| Glenn Jackman 2007-06-23, 4:18 am |
| 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
| |
| Patrick Finnegan 2007-06-23, 4:18 am |
| 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.
| |
| Arndt Roger Schneider 2007-06-24, 8:11 am |
| 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
| |
| Patrick Finnegan 2007-06-24, 8:11 am |
| 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:
> .
> .
> .
>
>
> 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.
| |
| Bezoar 2007-06-25, 4:23 am |
| 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 w, 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 .
>
> 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 ws 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_language
s), 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
| |
| skuhagen@web.de 2007-06-25, 4:23 am |
| 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
| |
| skuhagen@web.de 2007-06-25, 4:23 am |
|
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
| |
| skuhagen@web.de 2007-06-25, 4:23 am |
| Cameron Laird wrote:
>
> 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
| |
| skuhagen@web.de 2007-06-25, 4:23 am |
|
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
| |
| skuhagen@web.de 2007-06-25, 4:23 am |
| 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  ness 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 , must use!"
Regards
Stephan
| |
| davidnwelton@gmail.com 2007-06-25, 4:23 am |
| > 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/s...-second-edition
| |
| Donal K. Fellows 2007-06-25, 8:10 am |
| 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.
| |
| Kevin Walzer 2007-06-25, 10:10 pm |
| 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
| |
| Larry W. Virden 2007-06-25, 10:10 pm |
| 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.
| |
| Kevin Walzer 2007-06-25, 10:11 pm |
| Larry W. Virden wrote:
> On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote:
>
>
> So is there a _technical_ reason why Tcl doesn't have a Cocoa binding?
Yeah. No one's written one. :-)
>
>
>
> 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.
>
>
>
> 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'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
| |
| Gerald W. Lester 2007-06-25, 10:11 pm |
| Kevin Walzer wrote:
> Larry W. Virden wrote:
>
> Yeah. No one's written one. :-)
>
>
> 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.
>
>
> 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|
+------------------------------------------------------------------------+
| |
| slebetman@yahoo.com 2007-06-26, 8:09 am |
| On Jun 26, 1:40 am, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
> Kevin Walzer wrote:
>
>
>
>
>
>
>
>
>
> 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.
| |
| Donal K. Fellows 2007-06-26, 8:09 am |
| Kevin Walzer wrote:
> Larry W. Virden wrote:
>
> 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.
| |
| Donal K. Fellows 2007-06-26, 8:09 am |
| 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.
| |
| Melissa Schrumpf 2007-06-27, 4:22 am |
| davidnwelton wrote:
> Larry W. Virden wrote:
[color=darkred]
> 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
| |
| billposer@alum.mit.edu 2007-06-27, 7:12 pm |
| On Jun 27, 1:13 am, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:
> Melissa Schrumpf wrote:
>
> 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.
| |
| Donal K. Fellows 2007-06-27, 7:12 pm |
| 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.
| |
| davidnwelton@gmail.com 2007-06-27, 7:12 pm |
| On Jun 27, 2:01 am, Melissa Schrumpf
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
> davidnwelton wrote:
>
> 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.
| |
| Cameron Laird 2007-06-28, 7:12 pm |
| In article <f5t684$1mg8$1@godfrey.mcc.ac.uk>,
Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
>Melissa Schrumpf wrote:
>
>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.
| |
| Melissa Schrumpf 2007-06-29, 4:20 am |
| Darren New wrote:
> Melissa Schrumpf wrote:
[color=darkred]
> 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
| |
| Melissa Schrumpf 2007-06-29, 4:20 am |
| billposerwrote:
> Donal K. Fellows wrote:
[color=darkred]
>
> 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
| |
| Alexandre Ferrieux 2007-06-29, 8:08 am |
| On Jun 29, 2:19 am, Melissa Schrumpf
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
>
>
>
> QED.
Joke of the month at least !
(Just imagine this with the voices of Homer and Marge...)
-Alex
| |
| billposer@alum.mit.edu 2007-06-30, 4:18 am |
| 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.
>
>
> 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!
|
|
|
|
|