"Java is the SUV of programming tools"
John D.
"A project done in Java will cost 5 times as much, take twice as long,
and be harder to maintain than a project done in a scripting language
such as PHP or Perl. People who are serious about getting the job
done on time and under budget will use tools such as Visual Basic
(controlled all the machines that decoded the human genome). But the
programmers and managers using Java will feel good about themselves
because they are using a tool that, in theory, has a lot of power for
handling problems of tremendous complexity. Just like the suburbanite
who drives his SUV to the 7-11 on a paved road but feels good because
in theory he could climb a 45-degree dirt slope. If a programmer is
attacking a truly difficult problem he or she will generally have to
use a language with systems programming and dynamic type extension
capability, such as Lisp. This corresponds to the situation in which
my friend, the proud owner of an original-style Hummer, got stuck in
the sand on his first off-road excursion; an SUV can't handle a true
off-road adventure for which a tracked vehicle is required."
Kent Paul Dolan
> http://blogs.law.harvard.edu/philg/2003/09/20#a1762
Sigh. As someone who came up through the computer graphics
community from when drawing meant creating your own bits one
by one to make an image, that fellow is _so_ out of line.
Java is the most productive out of the 12 dozen programming
languages I've learned, and mostly it's because so many wheels
I used to have to invent anew in each language are now library
calls.
xanthian.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
soft-eng
I think the author is very limited as a programmer. The point he
makes would only occur to somebody who had lots of theoretical
and gossiping knowledge, but no real experience with the technologies
involved. Take the reference to Lisp, for instance. It's
a very interesting language and an MIT cult. But his point,
such as it is, might have been much better made with other
languages (e.g. device I/O and C.) But presumably it would
not then sit as well with his in-crowd.
While the comments on using Java with SQL are valid
1) Assuming that's a very significant usage of Java these days
is not. Maybe in the heyday of dot-com era, it could have been.
2) A real programmer would have realized that while the
problems are valid, they do not have to remain big problems.
Typical solutions involve writing a wrapper package
that sits between the JDBC access and the rest of your code.
3) The comment about "reams of repetitive declarations at the
top of every script" shows a lack of even basic
code organization skills. He seems to be complaining
about import statements. But too many import statements
have no place in a JSP. It indicates the JSPs need to
access a lot of other code, i.e. they are doing
a lot of work. Most Java programmers would chunk
down the problem into various classes so the
scripts only need be a small front end. (If it's not
about import statements, it shows an even worse code
organization.)
Only somebody with an entirely scripting background would
think like the author of this blog seems to be thinking.
Of course, if all you have ever done is scripting, and
all the problems you have ever faced are VB or scripting
level problems (though you have may have gossiped a lot
about Lisp and other langauges,) clearly other languages
would appear wasteful.
For that matter, if all your problems are spread-sheet
problems, you will be much more efficient using
a spread-sheet. It would make no sense to write
Java problems to recalculate every spreadsheet.
Same way, it would make no sense to write Java
solutions for every simplistic scripting-level problem.
That doesn't mean Java is not suited for its own arena.
Jason Voegele
> "John D." <alx5...@yahoo.com> wrote:
>
>> http://blogs.law.harvard.edu/philg/2003/09/20#a1762
[snip]
> Java is the most productive out of the 12 dozen programming
> languages I've learned, and mostly it's because so many wheels
> I used to have to invent anew in each language are now library
> calls.
Have you used any of:
Smalltalk
Ruby
Python
Lisp
Eiffel
Perl
?
If so, do you really feel that Java is more productive?
Ruby programs, for example, are typically less than half the size of their
Java equivalents. In some cases Ruby code can be less than 10% of the size
of the Java code. Much the same can be said for the other languages I've
listed, even if not as extreme in some cases.
--
Jason Voegele
"We believe that we invent symbols. The truth is that they invent us."
-- Gene Wolfe, The Book of the New Sun
Isaac Gouy
> Java is the most productive out of the 12 dozen programming
> languages I've learned, and mostly it's because so many wheels
> I used to have to invent anew in each language are now library
> calls.
That's one aspect, it's why I first used Smalltalk, it's why Perl, and
Python, (and still Fortran) and ... are popular - the code libraries.
The conversation about productivity is quite different when you have
to write new code or maintain old code. Then, it's the language itself
that matters.
Tom Welsh
Kent Paul Dolan <xant...@well.com> writes
>"John D." <alx5...@yahoo.com> wrote:
>
>> http://blogs.law.harvard.edu/philg/2003/09/20#a1762
>
>Sigh. As someone who came up through the computer graphics
>community from when drawing meant creating your own bits one
>by one to make an image, that fellow is _so_ out of line.
>
>Java is the most productive out of the 12 dozen programming
>languages I've learned, and mostly it's because so many wheels
>I used to have to invent anew in each language are now library
>calls.
>
Btw, since when have Harvard lawyers become experts on professional
programming techniques?
--
Tom Welsh
Roedy Green
wrote or quoted :
> In some cases Ruby code can be less than 10% of the size
>of the Java code.
Is this because of the language being terser or their being more
useful class libraries?
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Tim Tyler
: Jason Voegele <ja...@jvoegele.com> wrote or quoted :
:> In some cases Ruby code can be less than 10% of the size
:> of the Java code.
: Is this because of the language being terser or their being more
: useful class libraries?
Ruby the language is pretty terse.
One of my friends joked that he could enter practically anything -
and it would be a valid Ruby program.
--
__________
|im |yler http://timtyler.org/ t...@tt1.org
Isaac Gouy
> makes would only occur to somebody who had lots of theoretical
> and gossiping knowledge, but no real experience with the technologies
> involved.
Real experience? Hmmm.
http://philip.greenspun.com/narcissism/resume-list
Thomas Gagné
>I think the author is very limited as a programmer. The point he
>makes would only occur to somebody who had lots of theoretical
>and gossiping knowledge, but no real experience with the technologies
>involved. Take the reference to Lisp, for instance. It's
>a very interesting language and an MIT cult. But his point,
>such as it is, might have been much better made with other
>languages (e.g. device I/O and C.) But presumably it would
>not then sit as well with his in-crowd.
>
>
Why don't we assume the author has enough experience to make the
observation? Why don't we wonder at the complexity of the other
projects and contemplate that perhaps he might have a point? Afterall,
how often are we able to watch three projects going on simultaneously in
three different languages with programmers of approximately equivalent
skill? If he does have a point, why might he have a case? Would you
suggest that Java is the most productive language and has the most
extensive and mature class libraries after less than 10 years?
>
>
--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org
Jason Voegele
> On Tue, 23 Sep 2003 09:24:41 -0400, Jason Voegele <ja...@jvoegele.com>
> wrote or quoted :
>
>> In some cases Ruby code can be less than 10% of the size
>>of the Java code.
>
> Is this because of the language being terser or their being more
> useful class libraries?
It is largely due to the language itself being much terser than Java,
although there is a large set of rich libraries for Ruby as well. Although
the number of classes included in the standard Ruby distribution is smaller
than the number provided with the JDK, the Ruby libraries tend to be richer
and more flexible. Dynamic typing provides a lot of this, but more
important are lexical closures, regular expressions, and 100% pure OOP.
There is also a large number of libraries available at
http://raa.ruby-lang.org
--
Jason Voegele
$ /usr/games/fortune -s
Love cannot be much younger than the lust for murder.
-- Sigmund Freud
soft-eng
Thanks for doing the research to prove my point.
Right at the top of the resume, there are half a dozen projects
that are standard database-backed-HTML projects. The guy has
been doing the same thing over and over and over. And over. No
wonder he thinks that's all there is to programming!
Throw in a bit of "high level" gossip with dedicated
Lispers who have a bit of dislike of Java simply because
it happens to be popular, and this blogger's thinking
becomes clear.
I have to admit, database-backed-HTML projects were so common that
they deserved specialized tools of their own. And some such
tools had started to appear. But Java isn't such a tool. If
you think it should be, and if that's your only way to
measure programming languages, of course you would find it lacking!
soft-eng
> skill? If he does have a point, why might he have a case? Would you
> suggest that Java is the most productive language and has the most
> extensive and mature class libraries after less than 10 years?
Hardly. But it's OK, which is the point.
The language is just a straight-line evolution of the concepts
that have proven successful in C and C++, with a heavy Lisp
influence.
The class libraries are fairly decent.
So it gets the job done. It is also fairly accessible, unlike
Lisp (which has a fairly high cutoff.) Performance is
acceptable for a very large number of projects (given the
improvements in hardware.)
Unlike narrowly designed scripting languages, it can
be used for a wide range of tasks, and won't be
outdated as quickly. (Of course, the tradeoff is
that there will be more work than the scripting
language.)
So all in all, it's a good practical choice of today.
My point was that the critic being quoted had a very narrow
set of criteria in mind, and was critiquing a whole language
from a very narrow experience base.
Bradley E. Rintoul
Hey, nice applet on that http://www.scorecard.org site...
James A. Robertson
wrote:
>ig...@yahoo.com (Isaac Gouy) wrote in message news:<ce7ef1c8.03092...@posting.google.com>...
>> softe...@netscape.net (soft-eng) wrote in message
>> > I think the author is very limited as a programmer. The point he
>> > makes would only occur to somebody who had lots of theoretical
>> > and gossiping knowledge, but no real experience with the technologies
>> > involved.
>>
>> Real experience? Hmmm.
>> http://philip.greenspun.com/narcissism/resume-list
>
>Thanks for doing the research to prove my point.
>
Has it occurred to you that Lispers - and Smalltalkers - and Python
developers - and Ruby developers - have tried Java, and noticed lower
productivity?
>Right at the top of the resume, there are half a dozen projects
>that are standard database-backed-HTML projects. The guy has
>been doing the same thing over and over and over. And over. No
>wonder he thinks that's all there is to programming!
>Throw in a bit of "high level" gossip with dedicated
>Lispers who have a bit of dislike of Java simply because
>it happens to be popular, and this blogger's thinking
>becomes clear.
>
>I have to admit, database-backed-HTML projects were so common that
>they deserved specialized tools of their own. And some such
>tools had started to appear. But Java isn't such a tool. If
>you think it should be, and if that's your only way to
>measure programming languages, of course you would find it lacking!
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
Dr Chaos
> Thomas Gagné <tga...@wide-open-west.com> wrote in message news:<3F70F1A...@wide-open-west.com>...
>
>> skill? If he does have a point, why might he have a case? Would you
>> suggest that Java is the most productive language and has the most
>> extensive and mature class libraries after less than 10 years?
>
> Hardly. But it's OK, which is the point.
>
> The language is just a straight-line evolution of the concepts
> that have proven successful in C and C++, with a heavy Lisp
> influence.
"heavy" Lisp influence? In what ways particularly Lisp as opposed to
other conventional object oriented languages, say Modula-3 or to
lesser extent (to Java's discredit) Eiffel.
It really just looks like C++ with pointers/references which
act more like ordinary langauges.
Many things Lisp does well, Java doesn't.
> The class libraries are fairly decent.
>
> So it gets the job done. It is also fairly accessible, unlike
> Lisp (which has a fairly high cutoff.) Performance is
> acceptable for a very large number of projects (given the
> improvements in hardware.)
>
> Unlike narrowly designed scripting languages, it can
> be used for a wide range of tasks, and won't be
> outdated as quickly. (Of course, the tradeoff is
> that there will be more work than the scripting
> language.)
My definition of a "scripting language": a language which basically
sucks, but "that's OK, it's only a scripting language". The process
of Desuckification turns it by fits and starts into HacLisp on a bad
parenthesis day.
soft-eng
> On 24 Sep 2003 06:20:37 -0700, softe...@netscape.net (soft-eng)
> wrote:
>
> >ig...@yahoo.com (Isaac Gouy) wrote in message news:<ce7ef1c8.03092...@posting.google.com>...
> >> softe...@netscape.net (soft-eng) wrote in message
> >> > I think the author is very limited as a programmer. The point he
> >> > makes would only occur to somebody who had lots of theoretical
> >> > and gossiping knowledge, but no real experience with the technologies
> >> > involved.
> >>
> >> Real experience? Hmmm.
> >> http://philip.greenspun.com/narcissism/resume-list
> >
> >Thanks for doing the research to prove my point.
> >
>
> Has it occurred to you that Lispers - and Smalltalkers - and Python
> developers - and Ruby developers - have tried Java, and noticed lower
> productivity?
Lispers tend to be extremely biased in favor of Lisp.
Getting an objective opinion out of them is practically
impossible (even with Roedy's racks.) So their "noticing
lower productivity" wouldn't mean much.
Thomas Gagné
>
>
>The language is just a straight-line evolution of the concepts
>that have proven successful in C and C++, with a heavy Lisp
>influence.
>
Where is Lisp's influence in Java?
Dr Chaos
> James A. Robertson <jar...@gosmalltalk.com> wrote in message news:<ggh3nvo863dstcmen...@4ax.com>...
>> On 24 Sep 2003 06:20:37 -0700, softe...@netscape.net (soft-eng)
>> wrote:
>>
>> >ig...@yahoo.com (Isaac Gouy) wrote in message news:<ce7ef1c8.03092...@posting.google.com>...
>> >> softe...@netscape.net (soft-eng) wrote in message
>> >> > I think the author is very limited as a programmer. The point he
>> >> > makes would only occur to somebody who had lots of theoretical
>> >> > and gossiping knowledge, but no real experience with the technologies
>> >> > involved.
>> >>
>> >> Real experience? Hmmm.
>> >> http://philip.greenspun.com/narcissism/resume-list
>> >
>> >Thanks for doing the research to prove my point.
>> >
>>
>> Has it occurred to you that Lispers - and Smalltalkers - and Python
>> developers - and Ruby developers - have tried Java, and noticed lower
>> productivity?
>
> Lispers tend to be extremely biased in favor of Lisp.
suppose for a minute, that programming hard things in Lisp
really were very productive compared to alternatives.
What would Lisp programmers think?
> Getting an objective opinion out of them is practically
> impossible (even with Roedy's racks.) So their "noticing
> lower productivity" wouldn't mean much.
Why would people have an unnatural attraction to something
which is obscure and unusual if it didn't have significantly
redeeming qualities.
soft-eng
> On 24 Sep 2003 16:00:19 -0700, soft-eng <softe...@netscape.net> wrote:
> > James A. Robertson <jar...@gosmalltalk.com> wrote in message news:<ggh3nvo863dstcmen...@4ax.com>...
> >> On 24 Sep 2003 06:20:37 -0700, softe...@netscape.net (soft-eng)
> >> wrote:
> >>
> >> >ig...@yahoo.com (Isaac Gouy) wrote in message news:<ce7ef1c8.03092...@posting.google.com>...
> >> >> softe...@netscape.net (soft-eng) wrote in message
> >> >> > I think the author is very limited as a programmer. The point he
> >> >> > makes would only occur to somebody who had lots of theoretical
> >> >> > and gossiping knowledge, but no real experience with the technologies
> >> >> > involved.
> >> >>
> >> >> Real experience? Hmmm.
> >> >> http://philip.greenspun.com/narcissism/resume-list
> >> >
> >> >Thanks for doing the research to prove my point.
> >> >
> >>
> >> Has it occurred to you that Lispers - and Smalltalkers - and Python
> >> developers - and Ruby developers - have tried Java, and noticed lower
> >> productivity?
> >
> > Lispers tend to be extremely biased in favor of Lisp.
>
> suppose for a minute, that programming hard things in Lisp
> really were very productive compared to alternatives.
> What would Lisp programmers think?
Yes, for an experienced Lisper, Lisp would be more
productive than Java. I was actually commenting
more on the blog referred by the OP. It seemed
doubtful that the blogger had actual production
experience even in Lisp.
> > Getting an objective opinion out of them is practically
> > impossible (even with Roedy's racks.) So their "noticing
> > lower productivity" wouldn't mean much.
>
> Why would people have an unnatural attraction to something
> which is obscure and unusual if it didn't have significantly
> redeeming qualities.
Lisp does have many good qualities. Also, Lisp programming
tends to be very undisciplined. If you are naturally
inclined to be undisciplined, and are sufficiently bright
to _get_ most of the concepts, you would like Lisp and
would want to defend it, because it lets you write
code in the undisciplined style you like. (Think
hack-of-the-hour club.)
There is some amount of ego-satisfaction too. Lisp
tends to have obscure but useful concepts, many
of which are difficult for average programmers.
This allows brighter-than-average programmers to feel
superior to average programmers, and is part
of the unnatural attraction.
soft-eng
> soft-eng wrote:
>
> >
> >
> >The language is just a straight-line evolution of the concepts
> >that have proven successful in C and C++, with a heavy Lisp
> >influence.
> >
> Where is Lisp's influence in Java?
Well, there is intern and gc and anonymous classes (as
opposed to function pointers to solve the same problem,
which would have been a C influence.)
Howard Ding <hading@hading.dnsalias.com>
That hardly seems like a heavy Lisp influence, especially as the first
two could as easily have been Smalltalk influences. (Note that though
the name intern could have come from Lisp, the Java concept of intern
seems closer to Smalltalk symbols than Lisp symbols, which are much
more than canonical strings.)
--
Howard Ding
<had...@hading.dnsalias.com>
Dr Chaos
> Dr Chaos <mbkennelS...@NOSPAMyahoo.com> wrote in message news:<slrnbn4b34.kfq.m...@lyapunov.ucsd.edu>...
>> >
>>
>> suppose for a minute, that programming hard things in Lisp
>> really were very productive compared to alternatives.
>> What would Lisp programmers think?
>
> Yes, for an experienced Lisper, Lisp would be more
> productive than Java. I was actually commenting
> more on the blog referred by the OP. It seemed
> doubtful that the blogger had actual production
> experience even in Lisp.
>> > Getting an objective opinion out of them is practically
>> > impossible (even with Roedy's racks.) So their "noticing
>> > lower productivity" wouldn't mean much.
>>
>> Why would people have an unnatural attraction to something
>> which is obscure and unusual if it didn't have significantly
>> redeeming qualities.
>
> Lisp does have many good qualities. Also, Lisp programming
> tends to be very undisciplined. If you are naturally
> inclined to be undisciplined, and are sufficiently bright
> to _get_ most of the concepts, you would like Lisp and
> would want to defend it, because it lets you write
> code in the undisciplined style you like. (Think
> hack-of-the-hour club.)
Lisp programming may be undiscplined (a bit) compared to Eiffel, but
surely it is nothing like Perl, and it is far more rational
than perl.
> There is some amount of ego-satisfaction too. Lisp
> tends to have obscure but useful concepts, many
> of which are difficult for average programmers.
> This allows brighter-than-average programmers to feel
> superior to average programmers, and is part
> of the unnatural attraction.
Perhaps brighter-than-average programmers are indeed superior
to average programmers, especially combined with Lisp.
Isaac Newton was superior to average natural philosophers of his time
when he had calculus (which he essentially kept secret for years) and
others didn't.
I think that attraction is fairly natural.
soft-eng
> Isaac Newton was superior to average natural philosophers of his time
> when he had calculus (which he essentially kept secret for years) and
> others didn't.
Until somebody else came up with it... Given his political
stature, all he had to do was say "I did it first". In
fact he didn't even had to do that, others claimed
it could only be him (based on his "lion's pawprint".)
All he had to do was sit tight and smile.
> I think that attraction is fairly natural.
Yes, bright people finding Lisp and SmallTalk good is
natural. My point was that then tend to not be
very objective when talking about it.
Thomas Gagné
>
>Yes, bright people finding Lisp and SmallTalk good is
>natural. My point was that then tend to not be
>very objective when talking about it.
>
That is a fascinating argument.
We're programming on ladders. Each of us tries to tell those on the
rungs below us how great the view is from the rung we're on. What's odd
is too many programmers ignore the urgings of those who have travelled
past their own spot on the ladder to higher rungs.
Apparently some have either grown weary of climbing or are uncomfortable
(paranoid) about climbing higher. What's really curious is how they
suspect those above them as being uppity.
If languages like Smalltalk and Lisp have a special attraction to
"special" programmers, why wouldn't others be interested in what that
appeal might be?
Martin Drautzburg
> Java is the most productive out of the 12 dozen programming
> languages I've learned, and mostly it's because so many wheels
> I used to have to invent anew in each language are now library
> calls.
Can you name a few of the 12 ? I'd really like to know.
No doubt someone will post a collection of languages that she claims
are more productive than Java. It'll be interesting to compare these
lists.
soft-eng
Well, I can't say for sure it's a Lisp influence -- even
the VM, the notion of a separate compilation step to
bytecode (and calling it compilation) etc could have
come from many language. Taken together, I thought
it had a Lisp programming feel to it. But then, I don't
have production level experience with Smalltalk, so
I could be mistaken.
soft-eng
> If languages like Smalltalk and Lisp have a special attraction to
> "special" programmers, why wouldn't others be interested in what that
> appeal might be?
Sure, they should. Depends upon your motivation, free time etc.
Personally, I think programmers should learn a wide variety
of languages.
What people should avoid, IMO, is to learn the biases
that some of these language seem to have as
part of an "in-culture". The languages are not
worth losing the open-ness of your mind.
Isaac Gouy
>
> >
> >Yes, bright people finding Lisp and SmallTalk good is
> >natural. My point was that then tend to not be
> >very objective when talking about it.
> >
>
> That is a fascinating argument.
>
> We're programming on ladders. Each of us tries to tell those on the
> rungs below us how great the view is from the rung we're on.
We can't see from one ladder to another - so there's no direct way to
compare the height of a rung on one ladder to the height of a rung on
another.
Some are shouting about the things they can see, but from this ladder
those things aren't visible - so maybe they're just suffering from
vertigo, or their heads in the clouds ;-)
Whatever - their shouting about how much better things are on their
ladder and how stupid we are for not moving to their ladder soon gets
tedious, and the view from here seems just fine.
We know some climb ladders faster than others, and some fall off more.
Is it really because some ladders are easier to climb, and some are
more slippery?
Or are some climbers stronger and some climbers careless?
> What's odd
> is too many programmers ignore the urgings of those who have travelled
> past their own spot on the ladder to higher rungs.
>
> Apparently some have either grown weary of climbing or are uncomfortable
> (paranoid) about climbing higher. What's really curious is how they
> suspect those above them as being uppity.
>
> If languages like Smalltalk and Lisp have a special attraction to
> "special" programmers, why wouldn't others be interested in what that
> appeal might be?
Others are more interested in the appeal of continued employment - so
they choose languages with the high name recognition.
Kent Paul Dolan
> "Kent Paul Dolan" <xant...@well.com> writes:
>> Java is the most productive out of the 12 dozen programming
>> languages I've learned, and mostly it's because so many wheels
>> I used to have to invent anew in each language are now library
>> calls.
> Can you name a few of the 12 ? I'd really like to know.
Read that again.
xanthian.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Russ
> developers - and Ruby developers - have tried Java, and noticed lower
> productivity?
Has it occured to you that when you switch from one mind set to
another, you are likely going to experience a tremendous dip in
productivity until you have learned the new tool?
For example, I could switch from the QWERTY keyboard to the Dvorak
keyboard. Statistically, I should get 30%-40% more productivity as I
type. But, when I first switch, I will have to "hunt and peck." Does
that mean that Dovrak is inferior or that I'm just not experienced
with it? (Remember, QWERTY keyboards were specifically designed to
reduce tying proficiency.)
Russ
James A. Robertson
>> Has it occurred to you that Lispers - and Smalltalkers - and Python
>> developers - and Ruby developers - have tried Java, and noticed lower
>> productivity?
>
>Has it occured to you that when you switch from one mind set to
>another, you are likely going to experience a tremendous dip in
>productivity until you have learned the new tool?
That must explain why - after 5 years of C programming - I gained a 2x
boost in Smalltalk within a week, and a 5x boost within a month. Back
10 years ago now.
Maybe going from Smalltalk or Lisp (or Python or Ruby) to Java, you
get that productivity drain....
>
>For example, I could switch from the QWERTY keyboard to the Dvorak
>keyboard. Statistically, I should get 30%-40% more productivity as I
>type. But, when I first switch, I will have to "hunt and peck." Does
>that mean that Dovrak is inferior or that I'm just not experienced
>with it? (Remember, QWERTY keyboards were specifically designed to
>reduce tying proficiency.)
>
>Russ
<Talk Small and Carry a Big Class Library>
DaiIchi
Kinda slow on the startup... but very flexible. A Java programmer
learns a skill that he can apply to multiple situations: he can build
web pages (ala JSP), server code, client code, phone code... with very
little relearning to do. Try to do that with Perl.
BTW, a good site to compare languages is :
http://www.bagley.org/~doug/shootout/ you quickly see that in many
cases, Java isn't the fastest--and it isn't the slowest. But it beats
out Ruby and Perl handily in many cases. Java code has a smaller
footprint and uses less memory. Go figure.
Jason Voegele <ja...@jvoegele.com> wrote in message news:<3f70480e$0$43874$a046...@nnrp.fuse.net>...
> Kent Paul Dolan wrote:
>
> > "John D." <alx5...@yahoo.com> wrote:
> >
> >> http://blogs.law.harvard.edu/philg/2003/09/20#a1762
> [snip]
> > Java is the most productive out of the 12 dozen programming
> > languages I've learned, and mostly it's because so many wheels
> > I used to have to invent anew in each language are now library
> > calls.
>
> Have you used any of:
>
> Smalltalk
> Ruby
> Python
> Lisp
> Eiffel
> Perl
> ?
>
> If so, do you really feel that Java is more productive?
>
> Ruby programs, for example, are typically less than half the size of their
> Java equivalents. In some cases Ruby code can be less than 10% of the size
> of the Java code. Much the same can be said for the other languages I've
> listed, even if not as extreme in some cases.
Martin Drautzburg
> BTW, a good site to compare languages is :
> http://www.bagley.org/~doug/shootout/ you quickly see that in many
> cases, Java isn't the fastest--and it isn't the slowest. But it beats
> out Ruby and Perl handily in many cases. Java code has a smaller
> footprint and uses less memory. Go figure.
This site does not talk about poductivity at all, with the minor
exception of listing lines of code and in that respect java does not
exactly shine. The benchmarks are typical micro benchmarks and it is
well known that Java does a decent job on micro benchmarks.
In my experience the single most important factor to achieve good
performace is maintainable elegant code (i.e. programmer performance)
and NOT a good micro benchmark rating.
Also neither Smalltalk nor Lisp is among the languages compared.
Then again I agree that Java is an acceptable general purpose
language. But considering what the computing world knew when Java was
invented it was not a big leap (at least not towards the cutting
edge).
Thomas Gagné
>>
>>
>Others are more interested in the appeal of continued employment - so
>they choose languages with the high name recognition.
>
Good points. In that case they should advocate the employment
opportunities of the language, but avoid comparing it to other
languages for anything other than employability.
Thomas Gagné
>>Has it occurred to you that Lispers - and Smalltalkers - and Python
>>developers - and Ruby developers - have tried Java, and noticed lower
>>productivity?
>>
>>
>
>Has it occured to you that when you switch from one mind set to
>another, you are likely going to experience a tremendous dip in
>productivity until you have learned the new tool?
>
That would make sense, except the people commenting on productivity are
not make those observations from the POV of trivial projects. Many are
easily as competent in multiple languages so can make those comparisons
credibly.
Insinuating their productivity is the result of incompetency in the
language is a weak argument. Perhaps they are equally incompetent in
Lisp or Eiffel but are still more productive than in Java.
Thomas Gagné
>Language snobs. Sheesh.
>
Snobbery has nothing to do with it. If someone is equally competent in
two languages and finds one more productive (significantly) than
another, isn't that worth sharing with others? Imagine how your life
might be if Gosling had kept Java to himself and you were still
stuggling with C++.
All languages are not created equal. Otherwise which one you use would
make /no/ difference to the result.
> Java is a great general purpose language.
>
Java is a general purpose language.
>Kinda slow on the startup... but very flexible. A Java programmer
>learns a skill that he can apply to multiple situations: he can build
>web pages (ala JSP), server code, client code, phone code... with very
>little relearning to do. Try to do that with Perl.
>
I haven't yet. But respectable sources advice against it.
>
>BTW, a good site to compare languages is :
>http://www.bagley.org/~doug/shootout/ you quickly see that in many
>cases, Java isn't the fastest--and it isn't the slowest. But it beats
>out Ruby and Perl handily in many cases. Java code has a smaller
>footprint and uses less memory. Go figure.
>
Productivity doesn't mean speed of execution--unless that is a primary
qualifer for your product. Currently, its less expensive to use a more
productive language and buy faster CPUs and more memory.
James A. Robertson
(DaiIchi) wrote:
>Language snobs. Sheesh. Java is a great general purpose language.
>Kinda slow on the startup... but very flexible. A Java programmer
>learns a skill that he can apply to multiple situations: he can build
>web pages (ala JSP), server code, client code, phone code... with very
>little relearning to do. Try to do that with Perl.
What you say above is true of Smalltalk, and Lisp, and Python, and
Ruby. I think you've found the language snobs, but not where you
thought...
>
>BTW, a good site to compare languages is :
>http://www.bagley.org/~doug/shootout/ you quickly see that in many
>cases, Java isn't the fastest--and it isn't the slowest. But it beats
>out Ruby and Perl handily in many cases. Java code has a smaller
>footprint and uses less memory. Go figure.
Look here:
http://lists.squeakfoundation.org/pipermail/seaside/2003-September/002132.html
smaller footprint and less memory? Certainly not the former, and I
doubt the latter.
>
>Jason Voegele <ja...@jvoegele.com> wrote in message news:<3f70480e$0$43874$a046...@nnrp.fuse.net>...
>> Kent Paul Dolan wrote:
>>
>> > "John D." <alx5...@yahoo.com> wrote:
>> >
>> >> http://blogs.law.harvard.edu/philg/2003/09/20#a1762
>> [snip]
>> > Java is the most productive out of the 12 dozen programming
>> > languages I've learned, and mostly it's because so many wheels
>> > I used to have to invent anew in each language are now library
>> > calls.
>>
>> Have you used any of:
>>
>> Smalltalk
>> Ruby
>> Python
>> Lisp
>> Eiffel
>> Perl
>> ?
>>
>> If so, do you really feel that Java is more productive?
>>
>> Ruby programs, for example, are typically less than half the size of their
>> Java equivalents. In some cases Ruby code can be less than 10% of the size
>> of the Java code. Much the same can be said for the other languages I've
>> listed, even if not as extreme in some cases.
<Talk Small and Carry a Big Class Library>
Markus Fritsche
> Java is the most productive out of the 12 dozen programming
> languages I've learned, and mostly it's because so many wheels
> I used to have to invent anew in each language are now library
> calls.
You couldn't have chosen them at random. Otherwise we should prepare for
a meteorite that will hit the earth in the next two days.
Regards, Markus
Isaac Gouy
-SNIP-
> BTW, a good site to compare languages is :
> http://www.bagley.org/~doug/shootout/ you quickly see that in many
> cases, Java isn't the fastest--and it isn't the slowest. But it beats
> out Ruby and Perl handily in many cases. Java code has a smaller
> footprint and uses less memory. Go figure.
That site is no longer updated.
The Win32 Shootout does get updated sometimes:
http://dada.perl.it/shootout/
and includes other languages (C#, Ada, ...)
Isaac Gouy
> Also neither Smalltalk nor Lisp is among the languages compared
Several Lisps and Schemes are represented (for at least some tests).
In fact, Stalin and Bigloo (Scheme) and Common Lisp are up with C on
one test http://www.bagley.org/~doug/shootout/bench/ary3/
I don't know whether any Smalltalk contributions were sent to Doug
Bagley, they have been provided to the Win32 Shootout - maybe one day
they'll appear.
The main problem has been that these are tests are intended to be like
command line utilities (originally it was a comparison of scripting
languages) and Smalltalk implementations haven't focused on this kind
of use. (Yes, it can be done but the build process is more involved.)
Isaac Gouy
> "Martin Drautzburg" <martin.d...@web.de> wrote:
>
> > "Kent Paul Dolan" <xant...@well.com> writes:
>
> >> Java is the most productive out of the 12 dozen programming
> >> languages I've learned, and mostly it's because so many wheels
> >> I used to have to invent anew in each language are now library
> >> calls.
>
> > Can you name a few of the 12 ? I'd really like to know.
>
> Read that again.
Hmmm, learned 144 languages?
Takes me at least a year of daily use before I start to think I've
learned a language (and usually another year realizing what I hadn't
learned).
Guess there are different ideas about when somethings been learnt.
Kent Paul Dolan
> Hmmm, learned 144 languages?
Yes. That's no big deal, though, I started in 1961.
> Takes me at least a year of daily use before I start to think I've
> learned a language (and usually another year realizing what I hadn't
> learned).
Same here, but it's quite possible to be learning three or four at the
same time. I managed seven my first year at one job, out of necessity,
they were already part of the software package whose upkeep I accepted
with the job, along with six others I already knew. One I learned from
scratch on a trans-Pacific airplane flight, and put to use when I
stepped off the plane; having a laptop along helped.
> Guess there are different ideas about when somethings been learnt.
I'll freely admit to mostly learning just the kernel parts of each
language. All imperative programming languages are pretty much alike,
once you realize the small set of things each of them must do. The rest
you get by reading the manual a couple of times to know that they are
present, then go back and "work from the book" those few times you need
a specialization of a particular language.
Isaac Gouy
> language. All imperative programming languages are pretty much alike,
> once you realize the small set of things each of them must do. The rest
> you get by reading the manual a couple of times to know that they are
> present, then go back and "work from the book" those few times you need
> a specialization of a particular language.
Know what you mean - on the other hand it's when I start to think
differently about programming that it seems I've learned, rather than
when I can program language X as though it were language Y.
You could give a short-form answer to Martin by answering the question
Jason originally put:
"Have you used any of:
Smalltalk
Ruby
Python
Lisp
Eiffel
Perl
If so, do you really feel that Java is more productive?"
Isaac Gouy
> Isaac Gouy wrote:
> >Others are more interested in the appeal of continued employment - so
> >they choose languages with the high name recognition.
> >
> Good points. In that case they should advocate the employment
> opportunities of the language, but avoid comparing it to other
> languages for anything other than employability.
That isn't the only consequence of high name recognition - there will
be more resources of all kinds (tools, third-party libraries, training
materials...), how much the network effects compensate or overcome
whatever indequacies exist in the language is a matter of debate ;-)
DaiIchi
> DaiIchi wrote:
<< ... SNIP ...>>
> >BTW, a good site to compare languages is :
> >http://www.bagley.org/~doug/shootout/ you quickly see that in many
> >cases, Java isn't the fastest--and it isn't the slowest. But it beats
> >out Ruby and Perl handily in many cases. Java code has a smaller
> >footprint and uses less memory. Go figure.
> >
> Productivity doesn't mean speed of execution--unless that is a primary
> qualifer for your product. Currently, its less expensive to use a more
> productive language and buy faster CPUs and more memory.
>
Actually, my intent was to put Java's productivity into a logical
light. First, one must establish that Java is a valid language to
produce quality code with (if it fails this test, then it doesn't
matter what the other attributes of productivity are, the project will
be worthless in the end). A few years ago, performance was one of the
major limiting factors, and when pitted against gcc and "iron"
languages, it still is.
The second part of my response addressed one aspect of productivity:
flexibility. In large development companies, specialization is an
easy thing to accomodate. In a small one, like mine, it's the death
knell of a programmer (as far as my company is concerned).
Particularly, if the guy is a perl programmer, he's probably just fine
as long as my company has web development jobs available. Java
programmers are easier to find work for. C/C++ programmers have the
easiest time. One reason I attribute to this trend is that languages
like Perl are highly specialized, Java is more flexible (especially in
the light of mobile phone apps). So how do you measure productivity?
How long it takes to code a method? An object? A program? A system?
Or maybe how many bugs are detected at lifecycle? Or how many
manhours it took to develop it? I simply posed a very personal way of
measuring productivity: what is it easiest for me to get paid for.
With Java, I've been paid for mobile development, web site
development, client/server development, enterprise integration, etc.
For me, it's a very productive language.
Kent Paul Dolan
> Have you used any of:
> Smalltalk
> Ruby
> Python
> Lisp
> Eiffel
> Perl
I've used Lisp and Perl, the latter with much more
expertise; I _have_ Ruby and Python, have not yet used
either; but the forced format of Python repels me, and I
don't yet know enough about Ruby to comment. However, I'm
not a fan of terseness for terseness' sake: I happen to be
a reasonably fast touch typist. I prefer a language that
any technically competent person can desk check with me.
Languages like Perl, Forth, C, and APL are famous for the
obscurity of code you can write with them, and I have. The
rest of that story is that they make programming in the
large a pain because only the original author can make
sense of all but the most deliberately self-documenting
code.
I'll probably never try Smalltalk, languages that promote
sloppiness by making nearly every statement execute whether
it makes sense as written or not have highly negative
effects on my productivity; I prefer the stricter languages
like Ada, Pascal, or Modula 2 that catch most of my logic
errors at compile time.
Eiffel I admire from a distance, programming by contract is
very attractive, and in some other language whose name I've
since forgotten. I've programmed with preconditions and
postconditions with good success.
However, an extremely offputting and shrill Eiffel advocate
spamming comp.lang.ada turned me off to the language for
political rather than technical reasons, much like the C#
proponents here.
In comparision to all the languages in that kit which I
_have_ used, and to a long list of others I'm sure I could
no longer reproduce accurately, Java is most productive for
programming tasks of the type I do today, heavy in human
interface construction and complex data structures with lots
of objects of short lifespans; for pure straightforward
math, on the other hand, I don't think APL can be beaten for
productivity and fit to the task at hand.
The sidebar to put a limit on how seriously this should all
be taken is that I'm strictly an imperative language
programmer; I have no "hands-on" knowledge of the
productivity of functional or equational languages in
current use. Also, there are literally thousands of
computer programming languages, and so my experience is
still just a tiny fraction of all there is to know.
James A. Robertson
<xant...@well.com> wrote:
>"Isaac Gouy" <ig...@yahoo.com> wrote:
>
>> Have you used any of:
>> Smalltalk
>> Ruby
>> Python
>> Lisp
>> Eiffel
>> Perl
>
>I've used Lisp and Perl, the latter with much more
>expertise; I _have_ Ruby and Python, have not yet used
>either; but the forced format of Python repels me, and I
IN what way is a tab different from a curly brace? Both are single
characters, and - arguably - a tab is better at conveying semantic
meaning to the person reading the code.
>don't yet know enough about Ruby to comment. However, I'm
>not a fan of terseness for terseness' sake: I happen to be
>a reasonably fast touch typist. I prefer a language that
>any technically competent person can desk check with me.
>Languages like Perl, Forth, C, and APL are famous for the
>obscurity of code you can write with them, and I have. The
>rest of that story is that they make programming in the
>large a pain because only the original author can make
>sense of all but the most deliberately self-documenting
>code.
>
>I'll probably never try Smalltalk, languages that promote
>sloppiness by making nearly every statement execute whether
>it makes sense as written or not have highly negative
You have no idea what you are talking about here. None, zero, zip.
If you send a message that is not understood in Smalltalk, you get a
well formed exception. Take C++ or C (please) - you'll actually get
an attempt to execute the blasted thing, followed by who knows what
kind of nasty blowback.
Yeah, static typing helps that problem loads. Not to mention that -
in 10 years of Smalltalk development, I've had an MNU in a deployed
application too few times to count. I've had about as many
NullPointerExceptions in deployed Java apps I've used, and far, far
more errors that cause crashes in C/C++ apps.
So what it boils down to is, you don't know Smalltalk, you refuse to
look at it, but you are convinced that it's a bad thing. Hmm....
<Talk Small and Carry a Big Class Library>
Dr Chaos
> Dr Chaos <mbkennelS...@NOSPAMyahoo.com> wrote in message news:<slrnbn6dg8.no0.m...@lyapunov.ucsd.edu>...
>
>> Isaac Newton was superior to average natural philosophers of his time
>> when he had calculus (which he essentially kept secret for years) and
>> others didn't.
>
> Until somebody else came up with it... Given his political
> stature, all he had to do was say "I did it first".
The modern conclusion is that it was a simultaneous independent
invention. But the total net achievement of Newton was much larger
than Leibniz.
> In
> fact he didn't even had to do that, others claimed
> it could only be him (based on his "lion's pawprint".)
actually that remark was in reference (by a colleague) of Newton
solving a mathematical problem which had eluded other mathemeticians
for months or years. Apparently Newton did it in a 12 hour
"all-nighter" after receiving it. Pompous prick that he was, he then
complained that if he had been as smart as he was when he was young,
it would have been 20 minutes or so.
It involved calculus of variations which is substantially more
subtle and deep than ordinary calculus. (because now
functions in their abstraction are the 'variables', but of course
this was done way before actual functoinal analysis was
formally conceived in the 19th century).
> All he had to do was sit tight and smile.
>
>> I think that attraction is fairly natural.
>
> Yes, bright people finding Lisp and SmallTalk good is
> natural. My point was that then tend to not be
> very objective when talking about it.
what do you mean by "objective"? Do the opinions of smart people with
experience with such technology count less than less clever people
without experience with it?
Dr Chaos
>
> Well, I can't say for sure it's a Lisp influence -- even
> the VM, the notion of a separate compilation step to
> bytecode (and calling it compilation) etc could have
> come from many language. Taken together, I thought
> it had a Lisp programming feel to it. But then, I don't
> have production level experience with Smalltalk, so
> I could be mistaken.
I think anything worth calling "a Lisp influence" would have had the
canonical innovation: a lambda.
But it didn't, at least not early. I think the notion of JVM was invented
first, and an average conventional language placed on top.
The closest parallel I woudl guess was the Bell Labs c@t thingy (???)
that had a major Usenet advocate many years abck.
Kent Paul Dolan
> "Kent Paul Dolan" <xant...@well.com> wrote:
>> the forced format of Python repels me
> In what way is a tab different from a curly brace? Both
> are single characters, and - arguably - a tab is better at
> conveying semantic meaning to the person reading the code.
Why do you try to put words in my mouth? I never made the
claim the issue was tab versus curly brace, yet in your
ignorance, that's all you can imagine. The issue is as
stated: a forced choice of format. I started my programming
career when fixed format languages were the only kind
around. I have no interest in going backwards to crippled
technology.
I format my own code in a two dimensional style that uses
many times the whitespace of the usual programmer's style,
and the whitespace is a resource to me used to make my code
better self-documenting; I have no more interest in
surrendering that resource to a language designer's
ideosyncratic taste than I have love for case insensitive
languages which nevertheless insist on uppercasing keywords
where my own usage is the opposite.
>> I'll probably never try Smalltalk, languages that promote
>> sloppiness by making nearly every statement execute whether
>> it makes sense as written or not have highly negative
> You have no idea what you are talking about here. None,
> zero, zip.
God I love it when the victim _runs_ into the trap.
A clueful person might have stopped to think that someone
with 42 years of programming experience might have read just
a bit about Smalltalk in all those years; might have
subscribed to SIGPLAN and SIGSOFT and TOPLAS and Byte for a
number of those decades. I've put Smalltalk on systems I
control several times, but it's never called out to be used.
> If you send a message that is not understood in Smalltalk,
> you get a well formed exception.
Which, of course, is exactly the contrapositive of the
problem area; your naivete' about programming is showing.
The problem with your hobby horse is that call compatibility
is defined at the method level rather than at the class
level, and so a call ("message") that matches the method
signature but was never intended for an object of that
class in the current semantic context is blithely and
silently executed, without the protection of static typing
to highlight the class mismatch error at compile time, and
with no protection at all at run time, and disaster typically
ensues swiftly. Smalltalk is hardly the only dynamically
typed language, after all, the problem is common to the
breed.
> Take C++ or C (please) - you'll actually get an attempt to
> execute the blasted thing, followed by who knows what kind
> of nasty blowback.
Exactly the case with Smalltalk as described above.
> So what it boils down to is, you don't know Smalltalk, you
> refuse to look at it, but you are convinced that it's a
> bad thing. Hmm....
Again, you are made a fool of by going on assumptions which
are all your feeble imagination can produce, instead of
thinking before you type. Thank you for this entertaining
example of why True Believers act as punching dummies in
newsgroups dedicated to competing technologies.
Have a nice rant in reply. I might even answer, if you say
anything intelligent, but I'm not hold my breath.
James A. Robertson
<xant...@well.com> wrote:
>"James A. Robertson" <jar...@gosmalltalk.com> wrote:
>
>> "Kent Paul Dolan" <xant...@well.com> wrote:
>>> the forced format of Python repels me
>
>> In what way is a tab different from a curly brace? Both
>> are single characters, and - arguably - a tab is better at
>> conveying semantic meaning to the person reading the code.
>
>Why do you try to put words in my mouth? I never made the
>claim the issue was tab versus curly brace, yet in your
>ignorance, that's all you can imagine. The issue is as
>stated: a forced choice of format. I started my programming
>career when fixed format languages were the only kind
>around. I have no interest in going backwards to crippled
>technology.
>
And you haven't answered my question. So you have to indent - in a
way that adds semantic meaning. This is bad how? In that it disturbs
your sense of esthetics somehow?
>I format my own code in a two dimensional style that uses
>many times the whitespace of the usual programmer's style,
>and the whitespace is a resource to me used to make my code
>better self-documenting; I have no more interest in
>surrendering that resource to a language designer's
>ideosyncratic taste than I have love for case insensitive
>languages which nevertheless insist on uppercasing keywords
>where my own usage is the opposite.
>
>>> I'll probably never try Smalltalk, languages that promote
>>> sloppiness by making nearly every statement execute whether
>>> it makes sense as written or not have highly negative
>
>> You have no idea what you are talking about here. None,
>> zero, zip.
>
>God I love it when the victim _runs_ into the trap.
>
>A clueful person might have stopped to think that someone
>with 42 years of programming experience might have read just
>a bit about Smalltalk in all those years; might have
>subscribed to SIGPLAN and SIGSOFT and TOPLAS and Byte for a
>number of those decades. I've put Smalltalk on systems I
>control several times, but it's never called out to be used.
>
I might, but <I'm talking to you>. Your ignorance shines through
quite strongly.
>> If you send a message that is not understood in Smalltalk,
>> you get a well formed exception.
>
>Which, of course, is exactly the contrapositive of the
>problem area; your naivete' about programming is showing.
>
>The problem with your hobby horse is that call compatibility
>is defined at the method level rather than at the class
>level, and so a call ("message") that matches the method
>signature but was never intended for an object of that
>class in the current semantic context is blithely and
>silently executed, without the protection of static typing
>to highlight the class mismatch error at compile time, and
>with no protection at all at run time, and disaster typically
>ensues swiftly. Smalltalk is hardly the only dynamically
>typed language, after all, the problem is common to the
>breed.
No, in fact it's not executed; thus your ignorance. The message is
sent to the object; it's not found. An exception is raised; the
exception is well understood, and can be handled. As a matter of
fact, for building proxy objects (to remote systems or database
objects), this is quite a powerful possibility; the proxy doesn't
understand much, but it grabs the MNU and forwards the message to the
actual intended recipient.
And this lack of static typing is not a problem; it's a feature. IME,
I got far, far more type errors in statically typed languages than I
do in dynamic ones. Why? Because the system forces me to remember
useless information.
>
>> Take C++ or C (please) - you'll actually get an attempt to
>> execute the blasted thing, followed by who knows what kind
>> of nasty blowback.
>
>Exactly the case with Smalltalk as described above.
>
Nope. Not even close. Thus, your ignorance of the subject. In C or
C++, the system attempts to execute the message, and blows (typically
with a core dump) in te attempt. In Smalltalk, the system is robust -
it handles the situation. Cleanly.
>> So what it boils down to is, you don't know Smalltalk, you
>> refuse to look at it, but you are convinced that it's a
>> bad thing. Hmm....
>
>Again, you are made a fool of by going on assumptions which
>are all your feeble imagination can produce, instead of
>thinking before you type. Thank you for this entertaining
>example of why True Believers act as punching dummies in
>newsgroups dedicated to competing technologies.
>
No, based on your post I was spot on. You have no clue how Smalltalk
works. You don't know a thing about method lookup in it, and you
don't understand the exception handling system <at all>. But you like
to think you do.
>Have a nice rant in reply. I might even answer, if you say
>anything intelligent, but I'm not hold my breath.
>
Try reading something about Smalltalk first, please.
James A. Robertson
<xant...@well.com> wrote:
>"James A. Robertson" <jar...@gosmalltalk.com> wrote:
>
>> "Kent Paul Dolan" <xant...@well.com> wrote:
>>> the forced format of Python repels me
>
<snip>
>> Take C++ or C (please) - you'll actually get an attempt to
>> execute the blasted thing, followed by who knows what kind
>> of nasty blowback.
>
>Exactly the case with Smalltalk as described above.
>
I explained in the other post how it's not the same thing at all.
Here's an example of how I often use this capability. Say I have a
domain object - let's call it Foo
The Foo object periodically sends change events off when interesting
state changes occur. Here's the kicker - Foo has no idea what other
objects may be interested, nor does it know (or care) which messages
those other objects may be interested in. So one of thos objects may
be Bar, and of all the events sent to it, he only cares about a
handful. Now, I'd rather not introduce a huge case statement into my
event handler - I'd have to revisit it every time I cared to handle a
new event. Instead, I write the handler like this:
update: anEventName with: aValue from: aModel
[anEventName isKeyword
ifTrue: [self perform: anEventName with: aValue]
ifFalse; [self perform: anEvent]]
on: MessageNotUnderstood
do: [:exception | exception return]
The upshot is, I send the inbound event name to myself (possibly with
an argument). If I don't implement a handler for that event, I get an
MNU - which I catch and just ignore. Ignoring is the correct
behavior, because I may get events I don't care about - and this
handily filters them out, while allowing my object to easily deal with
the ones it does care about.
I write event handlers like that a fair bit - and they take advantage
of this capability that seems to scare your socks off....
YGBKM
<xant...@well.com> wrote:
>I format my own code in a two dimensional style that uses
>many times the whitespace of the usual programmer's style,
>and the whitespace is a resource to me used to make my code
>better self-documenting;
Can everyone else read your whitespace-based-self-documenting code or
don't you care about that?
_______________________________________________________________________________
Posted Via Uncensored-News.Com - Accounts Starting At $6.95 - http://www.uncensored-news.com
<><><><><><><> The Worlds Uncensored News Source <><><><><><><><>
Isaac Gouy
years ago - not sure I ever will now.
> I'll probably never try Smalltalk, languages that promote
> sloppiness by making nearly every statement execute whether
> it makes sense as written or not have highly negative
> effects on my productivity; I prefer the stricter languages
> like Ada, Pascal, or Modula 2 that catch most of my logic
> errors at compile time.
Never did enough Ada to really get it, there's so much there.
Modula-2 I liked. Then there was a project that might need some kind
of AI approach, and before that could be tried it would rely on direct
manipulation of gantt charts and histograms - 15 years ago on a 286 PC
;-)
I saw an article about a Smalltalk system developed at Tektronix for
debugging oscilloscopes which combined graphics of where to set the
test probes with expert advice; a Smalltalk implementation appeared
for the 286 and I learnt that you can get an awful lot done with
Smalltalk ;-)
"making nearly every statement execute"
Don't know what you mean by this?
Are you just refering to lack of static type checking?
> In comparision to all the languages in that kit which I
> _have_ used, and to a long list of others I'm sure I could
> no longer reproduce accurately, Java is most productive for
> programming tasks of the type I do today, heavy in human
> interface construction and complex data structures with lots
> of objects of short lifespans
Moving from a limited language like Modula-2 or something as capable
as Ada, to Java - I can see that. Moving from Smalltalk to Java you
simply gave up productivity - partly language, partly tools, partly
libraries.
Happily some of the Smalltalk stuff has appeared in Java (refactoring
browser, xUnit) and, after a period of stagnation, there are "new and
improved" Smalltalk implementations.
> The sidebar to put a limit on how seriously this should all
> be taken is that I'm strictly an imperative language
> programmer; I have no "hands-on" knowledge of the
> productivity of functional or equational languages in
> current use.
Well, there's a language called Nice which brings some of the ideas
that have been developed in functional programming into an object
oriented language, that runs on JVM and interoperates with Java
classes and methods.
There are things about Nice that will appeal to you - it's intended to
be a safer language than Java - distinguishing between ordinary types
and Option Types which may include null, works wonders for
NullPointerExceptions; parametric classes remove the need for nonsense
casts; there's support for DbC.
For me, the appeal is that Nice is more expressive and has less
baggage - anonymous functions instead of inner classes, type inference
for method variables instead of redundant declarations, a type system
where int is a subtype of double...
Given that you favour static type checking, the modern pure functional
languages are quite a kick - you gotta love type inference ;-)
soft-eng
> I think anything worth calling "a Lisp influence" would have had the
> canonical innovation: a lambda.
That's how I read the anonymous classes -- a way to
do the type of things you typically end up using
raw lambda expressions for, in practical usage. (As
a chunk of code which you need to specify to something.)
But I realize that could be also like a Smalltalk block.
Kent Paul Dolan
> No, in fact it's not executed; thus your ignorance. The message is
> sent to the object; it's not found.
I'm sorry, I'm afraid dealing with deliberate stupidity on your part is
beyond me. That is not the scenario I described.
Kent Paul Dolan
> "Kent Paul Dolan" <xant...@well.com> wrote:
>> I format my own code in a two dimensional style that uses
>> many times the whitespace of the usual programmer's style,
>> and the whitespace is a resource to me used to make my code
>> better self-documenting;
> Can everyone else read your whitespace-based-self-documenting code or
> don't you care about that?
The words "self-documenting" aren't in your vocabulary?
Kent Paul Dolan
> There are things about Nice that will appeal to you - it's intended to
> be a safer language than Java - distinguishing between ordinary types
> and Option Types which may include null, works wonders for
> NullPointerExceptions;
This brings to mind one of Java's least successful endeavors: for a
language which claims not to _have_ pointers, finding the most common
way for software to die is via a _pointer_ exception is _way_
offputting. The Java compiler could do a lot more work to do path
analysis and warn the programmer if a way to achieve a null dereference
exists in the code, other language's compilers do; but perhaps the
tradeoff to do that much extra work against Java's currently blindingly
fast compilation speed is considered too grim. Still, a lint()-like
routine that spent the extra effort at the programmer's option to do
such path analysis would be a welcome toolkit member; does such exist?
Referring back to Nice, which I've looked at briefly, I suspect putting
the burden on the programmer to express the suitability of "null" as a
value for each object reference is entirely appropriate, and the markups
that Perl, for example, requires for the programmer to define the
intention of a token as a scalar, array, hash, or function name is
similar in impact: a slight mental adjustment and you're there.
You might want to look at OCaml, a strongly typed object oriented
version of Caml, a child of functional language ML, a child of Lisp, if
I have the story right. It is reported to be an extremely productive
language compared to the C family, and to create extremely tight code.
http://www.ocaml.org/ -- OCaml
http://caml.inria.fr/ -- Caml
http://www.faqs.org/faqs/meta-lang-faq/ -- good place to start ML
I'm a bit excluded by lacking more than a cursory idea of the
functioning of functional programming.
That's if you're still in the new language learning mode. Each new
one for me is becoming more and more of a struggle as I deal with the
problems of advancing age, and Java as a language system in the large
is growing faster than I can keep up, so far, which is actually praise.
James A. Robertson
<xant...@well.com> wrote:
>"James A. Robertson" <jar...@gosmalltalk.com> wrote:
>
>> No, in fact it's not executed; thus your ignorance. The message is
>> sent to the object; it's not found.
>
>I'm sorry, I'm afraid dealing with deliberate stupidity on your part is
>beyond me. That is not the scenario I described.
You said:
"> Take C++ or C (please) - you'll actually get an attempt to
> execute the blasted thing, followed by who knows what kind
> of nasty blowback.
Exactly the case with Smalltalk as described above."
It's not even close to the same situation as C/C++. As I said in my
post:
-- you don't understand Smalltalk method lookup semantics
-- you don't understand Smalltalk exception semantics
And yet, you <think> you do, and are willing to speak with assumed
authority on the subject.
Even worse, when called on your ignorance of the subject, you pretend
that the other person is ignorant and not worth arguing with. No
wonder you are unemployed; you must be a real joy to have on a
development team.....
Thomas Gagné
the transition and find value in doing so
<http://mindview.net/WebLog/log-0025> then it might be worth a 2nd look.
Who am I to be so rigid?
Kent Paul Dolan wrote:
>>
>>
><snip> I started my programming
>career when fixed format languages were the only kind
>around. I have no interest in going backwards to crippled
>technology.
>
>I format my own code in a two dimensional style that uses
>many times the whitespace of the usual programmer's style,
>and the whitespace is a resource to me used to make my code
>better self-documenting; I have no more interest in
>surrendering that resource to a language designer's
>ideosyncratic taste than I have love for case insensitive
>languages which nevertheless insist on uppercasing keywords
>where my own usage is the opposite.
>
>
--
Kent Paul Dolan
> "Kent Paul Dolan" <xant...@well.com> wrote:
>> "James A. Robertson" <jar...@gosmalltalk.com> wrote:
>>> No, in fact it's not executed; thus your ignorance. The message is
>>> sent to the object; it's not found.
>> I'm sorry, I'm afraid dealing with deliberate stupidity on your part is
>> beyond me. That is not the scenario I described.
> You said:
>> Take C++ or C (please) - you'll actually get an attempt to
>> execute the blasted thing, followed by who knows what kind
>> of nasty blowback.
> Exactly the case with Smalltalk as described above.
> It's not even close to the same situation as C/C++.
Nor did I claim so; had you bothered to _read_ the "as
described above", you would have noticed that I had turned
your bogus exoneration of Smalltalk around to point out the
situation where Smalltalk's vulnerabilities lie, which, when
provoked, cause exactly the same situation as with C/C++:
code is executed that has no business _being_ executed, and
the application goes crashy burny bye bye.
In the case of C/C++, that is because all function pointers
are interchangable; in the case of Smalltalk, that is
because all similarly-signatured methods are interchangable;
in each case, the weak typing allows entities that match by
coincidence the form of the entity the programmer actually
intended to address to be used in inappropriate situations
leading to program failure, in both cases, stronger typing
in better programming languages provides a way to catch that
kind of error at compile time.
As I said, I am simply incompetent to deal with you when
you are being deliberately stupid. Your attempts to
obfuscate Smalltalk's very obvious liabilities are every
bit the equivalent of YGBKM's similar intellectual
dishonesty on behalf of Microsoft.
It is far past evident that you are a full blown True
Believer that strong, static typing has nothing to offer
you. Having programmed extensively in both modes, I believe
I know better from experience, and I certainly know what
works better for me as a programmer of large (100M SLOC)
team-built software systems. I have no misimpression
that your mind is open to facts contradicting your
essentially illogical faith-based beliefs, and will not
waste the time trying to feed them to you.
James A. Robertson
<xant...@well.com> wrote:
>"James A. Robertson" <jar...@gosmalltalk.com> wrote:
>> "Kent Paul Dolan" <xant...@well.com> wrote:
<snip>
>> It's not even close to the same situation as C/C++.
>
>Nor did I claim so; had you bothered to _read_ the "as
>described above", you would have noticed that I had turned
>your bogus exoneration of Smalltalk around to point out the
>situation where Smalltalk's vulnerabilities lie, which, when
>provoked, cause exactly the same situation as with C/C++:
>code is executed that has no business _being_ executed, and
>the application goes crashy burny bye bye.
>
>In the case of C/C++, that is because all function pointers
>are interchangable; in the case of Smalltalk, that is
>because all similarly-signatured methods are interchangable;
>in each case, the weak typing allows entities that match by
>coincidence the form of the entity the programmer actually
>intended to address to be used in inappropriate situations
>leading to program failure, in both cases, stronger typing
>in better programming languages provides a way to catch that
>kind of error at compile time.
Ok, it's worse than I thought; you don't know styrong typing from weak
typing. Smalltalk is strongly, but dynamically typed. C and C++ are
weakly, but statically typed. In C or C++ - the system actually tries
to execute the non-existant code, and burns trying. In Smalltalk,
there is no such attempt. The system notes that the method cannot be
found, and raises an exception. In C or C++, there really isn't a way
to recover from this; you just die. In Smalltalk, this is an
exception like any other - and it can be caught. And handled.
And static typing does not guarantee that this gets caught at compile
time. In a loosely coupled system, where you load components
dynamically, one can easily get a bad version of a coponent which is
not api compatible with code that wants to talk to it - all it takes
is a deployment error, and - given human processes - that's possible.
>
>As I said, I am simply incompetent to deal with you when
>you are being deliberately stupid. Your attempts to
>obfuscate Smalltalk's very obvious liabilities are every
>bit the equivalent of YGBKM's similar intellectual
>dishonesty on behalf of Microsoft.
Incompetent is the right word all right. You completely don't
understand Smalltalk. It's not clear that you understand the
difference between strong and weak typing, since you seem to thing
"static" = "strong".
>
>It is far past evident that you are a full blown True
>Believer that strong, static typing has nothing to offer
>you. Having programmed extensively in both modes, I believe
Not nothing. I simply believe that the costs - in flexibility and
downstream maintenance - are higher than the benefits. That comes
from fairly long experience with both types of systems. Now, I
haven't tried out any functional languages with type inferencing -
those might offer benefits, but I haven't really looked.
>I know better from experience, and I certainly know what
>works better for me as a programmer of large (100M SLOC)
>team-built software systems. I have no misimpression
>that your mind is open to facts contradicting your
>essentially illogical faith-based beliefs, and will not
>waste the time trying to feed them to you.
You know from one thing - statically typed languages, and weakly typed
dynamic ones. You have no clear understanding of Smalltalk, and - as
stated above - your grasp of type systems is questionable
Kent Paul Dolan
> I had similar apprehensions about Python, but if Bruce Eckel can make
> the transition and find value in doing so
> <http://mindview.net/WebLog/log-0025> then it might be worth a 2nd look.
> Who am I to be so rigid?
Perhaps someone who has received the wisdom that you cannot test a
program into correctness? The blog entry makes the correct claim
that programming without unit testing is madness, but slides from
there straight to the incorrect claim that unit testing _replaces_
all the safety checks that strong typing provides. This is simply
not the case, and to promote working as if it were is a path to
software disasters.
In the case, and with the software industry's miserable current
record, choosing to opt out of some sorts of testing like compile
time type checking because they are "productivity destroying" is
to risk becoming another provider of the kind of worthless
rubbish currently infesting the Net. Programmers need all the help
they can get, especially as project complexity continues to grow
without visible limit, and static type checking is one such source
of help. One pays for that help in the time and effort exerted to
create the circumstances that make it available _beyond_ what one
exerts to create software without making it available.
"Quick and dirty" software development is almost overwhelmingly
seductive. Fred Brooks' "5 lines of delivered code per programmer
day" for software in the large drives budget writers to fits of
frothing madness. With the attitude that "we can do better with
just a few shortcuts" come the disasters that have so often recently
swept across the web.
Fact is, as events demonstrate again and again, we _cannot_ yet do
better than that mark, in safety, for all the same reasons it was
unassailable 40 years ago. It isn't a typing speed limitation -- any
fool with what Asimov called "good sitzfleisch"(sp?) can hack out a
working 600 line program in a day. It is a limitation on our ability
to organize humans to do complex tasks ungraspable in the whole by
any single person, cooperatively.
Bobby Parker
> record, choosing to opt out of some sorts of testing like compile
> time type checking because they are "productivity destroying" is
> to risk becoming another provider of the kind of worthless
> rubbish currently infesting the Net. Programmers need all the help
> they can get, especially as project complexity continues to grow
> without visible limit, and static type checking is one such source
> of help. One pays for that help in the time and effort exerted to
> create the circumstances that make it available _beyond_ what one
> exerts to create software without making it available.
I LOVE my immutable strings, dammit!
bp
Thomas Gagné
>"Thomas Gagné" <tga...@wide-open-west.com> wrote:
>
>
>>I had similar apprehensions about Python, but if Bruce Eckel can make
>>the transition and find value in doing so
>><http://mindview.net/WebLog/log-0025> then it might be worth a 2nd look.
>> Who am I to be so rigid?
>>
>>
>
>Perhaps someone who has received the wisdom that you cannot test a
>program into correctness? The blog entry makes the correct claim
>that programming without unit testing is madness, but slides from
>there straight to the incorrect claim that unit testing _replaces_
>all the safety checks that strong typing provides. This is simply
>not the case, and to promote working as if it were is a path to
>software disasters.
>
Considering we already have software disasters with the predominant
languages all supporting static typing suggests (at least) that
compile-time testing is inadequate to the task (I think we all agree on
this) but that testing is the only way to prove a system's /correctness/.
If the latter is the target and the former does not guarantee the
latter, then do we need the former? Does the flexibility forfeited to
the compiler pay for itself in hard or soft dollars (pick your currency).
>
>In the case, and with the software industry's miserable current
>record, choosing to opt out of some sorts of testing like compile
>time type checking because they are "productivity destroying" is
>to risk becoming another provider of the kind of worthless
>rubbish currently infesting the Net. Programmers need all the help
>they can get, especially as project complexity continues to grow
>without visible limit, and static type checking is one such source
>of help. One pays for that help in the time and effort exerted to
>create the circumstances that make it available _beyond_ what one
>exerts to create software without making it available.
>
There are probably all levels of programmers, just are there are in any
profession. Is it truly unimaginable that some programmers are capable
of delivering quality (tested) systems without the assistance of
compile-time type checking?
>
>"Quick and dirty" software development is almost overwhelmingly
>seductive. Fred Brooks' "5 lines of delivered code per programmer
>day" for software in the large drives budget writers to fits of
>frothing madness. With the attitude that "we can do better with
>just a few shortcuts" come the disasters that have so often recently
>swept across the web.
>
>Fact is, as events demonstrate again and again, we _cannot_ yet do
>better than that mark, in safety, for all the same reasons it was
>unassailable 40 years ago. It isn't a typing speed limitation -- any
>fool with what Asimov called "good sitzfleisch"(sp?) can hack out a
>working 600 line program in a day. It is a limitation on our ability
>to organize humans to do complex tasks ungraspable in the whole by
>any single person, cooperatively.
>
Which have been the predominant languages for the past 10, 20, 30 years?
Certainly not dynamically typed ones. C, C++, Delphi, and Java
constitute the majority of development since (at least) the early 80s,
all of them favor static typing (though I'm uncertain about VB--never
used it). Is there a correlation?
If insanity really is doing the same thing over and over again and
expecting a different result is it possible statically typed languages
and the assumptions about them have outlived their usefulness?
Why were he newsgroups misc.misc and talk.bizarre included on the
message? Is there a lot of Java and OO stuff over there?
Phillip Lord
>> Perhaps someone who has received the wisdom that you cannot test
>> a program into correctness? The blog entry makes the correct
>> claim that programming without unit testing is madness, but
>> slides from there straight to the incorrect claim that unit
>> testing _replaces_ all the safety checks that strong typing
>> provides. This is simply not the case, and to promote working as
>> if it were is a path to software disasters.
>>
Thomas> Considering we already have software disasters with the
Thomas> predominant languages all supporting static typing suggests
Thomas> (at least) that compile-time testing is inadequate to the
Thomas> task (I think we all agree on this) but that testing is the
Thomas> only way to prove a system's /correctness/.
Testing does not prove correctness. It can prove incorrectness if it
fails. Although of course the system could be right and the test
wrong.
Thomas> If the latter is the target and the former does not
Thomas> guarantee the latter, then do we need the former? Does the
Thomas> flexibility forfeited to the compiler pay for itself in hard
Thomas> or soft dollars (pick your currency).
Yes. Well I like it. As I can't think of a better way of testing it
than saying this, I'm not sure it helps though. Besides which I am not
certain that you do forfeit flexibility with static typing. Or rather
its clear that you have to write different code when you have static
typing. But surely the same is true if you write code that you mean to
unit test. Some code is easy to test, some not. Do you have to forfeit
any more flexibility when testing than with static typing?
Phil
Dr Chaos
> Dr Chaos <mbkennelS...@NOSPAMyahoo.com> wrote in message news:<slrnbnf00f.lk8.m...@lyapunov.ucsd.edu>...
>
>> I think anything worth calling "a Lisp influence" would have had the
>> canonical innovation: a lambda.
>
> That's how I read the anonymous classes -- a way to
> do the type of things you typically end up using
> raw lambda expressions for, in practical usage. (As
> a chunk of code which you need to specify to something.)
True, but that was a late and rather grungy add-on, and not central to
to the language.
The other key part of Lisp of course would be the ability to
manipulate internal program code as structured data.
Again, not much of this in Java.
> But I realize that could be also like a Smalltalk block.
Sometimes a cigar is just a cigar. Java was designed centrally as a
VM supporting downloadable bytecode.
This meant a certain attention to portability and garbage collection
to maintain stability.
Then a fairly basic and ordinary (and not that great) langauge was
made for it.
Eric Gunnerson
news:6c68a1c8.03092...@posting.google.com...
> For example, I could switch from the QWERTY keyboard to the Dvorak
> keyboard. Statistically, I should get 30%-40% more productivity as I
> type. But, when I first switch, I will have to "hunt and peck." Does
> that mean that Dovrak is inferior or that I'm just not experienced
> with it? (Remember, QWERTY keyboards were specifically designed to
> reduce tying proficiency.)
(brief aside)
There has been considerable controversy over the claims that Dvorak's key
arrangement produces the typing speed improvements that were claimed.
A decent discussion can be found at:
http://maccave1.freeyellow.com/dvorak.html
I now return you to your previous discussion.
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no rights.
Kent Paul Dolan
> Considering we already have software disasters with the
> predominant languages all supporting static typing
> suggests (at least) that compile-time testing is
> inadequate to the task (I think we all agree on this) but
> that testing is the only way to prove a system's
> /correctness/.
Bzzzt! The proof that proving a program's correctness by
testing is infeasible is an undergraduate computer science
exercise.
The only known way to _prove_ program correctness is by
formal mathematical validation methods, and because they
are not yet splendidly automated, they don't extend to
programming in the large economically feasibly.
Read the many writings of Edsgar Dijkstra on the subject.
> If the latter is the target and the former does not
> guarantee the latter, then do we need the former?
Nothing we can pay for "does the latter", we are in a mode
of trying to move to "doing the best we can" rather than
"doing the least we can".
You need the former because it takes out a whole class of
frequent errors quickly, automatically, and most important,
cheaply in comparision to formal SQA methods. In a large
programming effort, programmers are a small minority of all
salary costs, so having programmers work harder to save
overall costs makes economic sense.
> Does the flexibility forfeited to the compiler pay for
> itself in hard or soft dollars (pick your currency).
The "flexibility" you are "forfeiting" is the chance to make
stupid mistakes even an idiot machine could have caught; not
high on my hit parade.
On the issue of payback, read the publications of the
Software Engineering Institute, in particular their widely
used Capability Maturity Model book, and judge for yourself;
I lent my copy out and never got it back. Sigh.
http://www.sei.cmu.edu/publications/publications.html
> There are probably all levels of programmers, just are
> there are in any profession. Is it truly unimaginable
> that some programmers are capable of delivering quality
> (tested) systems without the assistance of compile-time
> type checking?
It is truly imaginable that anyone I have ever heard make
that claim for him or her self was just excusing bone
laziness. I have known half a dozen people with 180 IQs in
my life, and most likely each of them could pull it off, but
definitely each of them has better sense than to try, as
well. For the rest of us, yes, it is truly unimaginable, and
the record bears me out.
> Which have been the predominant languages for the past 10,
> 20, 30 years? Certainly not dynamically typed ones. C,
> C++, Delphi, and Java constitute the majority of
> development since (at least) the early 80s, all of them
> favor static typing (though I'm uncertain about VB--never
> used it). Is there a correlation?
No, because you have the wrong end of the stick; the problem
of creating software in the large is a problem in human
engineering, the failures of the past have not been, in any
great proportion, software development tool failures but
software management failures (read: Microsoftisms), and the
question is, does using tools less capable of assisting
correctness improve or damage the human engineering aspect?
Given that there is little choice in good times but to
employ programmers at all levels of competence, the question
of whether to give them all the double-checking help they
can get, whether they want it or not, has an obvious answer
if software quality and on-time deliver are important to
you as an employer.
> If insanity really is doing the same thing over and over
> again and expecting a different result is it possible
> statically typed languages and the assumptions about them
> have outlived their usefulness?
No, but it is possible you are slipping into ranting instead
of discussing. The human engineering aspects are slowly
being addressed (see the SEI CMM book), and there have been
some really excellent results in programs where loss of
human life was an issue in terms of delivered bugs per line
of code, most typically with Ada, as strict a taskmaster as
you could ask for in a compiler. The code came out no faster,
but its quality improved dramatically.
> Why were the newsgroups misc.misc and talk.bizarre included
> on the message? Is there a lot of Java and OO stuff over
> there?
Misc.misc because I always try to do so (see my recent note
in rec.games.roguelike.nethack on the subject "Posting to
misc.misc..."), and talk.bizarre because I send only my best
quality rants there to share with my peers(*), in this case
also to share your article URL with the software types
there. It also helps lure intelligent people to talk.bizarre,
though a lot of dead wood gets dragged along too.
xanthian.
(*) None of whom appreciate seeing those rants in the least:
it's an ego thingie, and they put up with me for the most
part, after 18 years to learn resignation.
Martin Drautzburg
> "Quick and dirty" software development is almost overwhelmingly
> seductive. Fred Brooks' "5 lines of delivered code per programmer
> day" for software in the large drives budget writers to fits of
> frothing madness. With the attitude that "we can do better with
> just a few shortcuts" come the disasters that have so often recently
> swept across the web.
A few weeks ago I made a strange observation. I had written a little
application in squeak (Smalltalk). It had taken me about a
week. Before I showed it to by colleagues I counted the lines of code
because I wanted to say: "see you can write that within a week and it
only takes 800 LOC".
To my surprize I counted 5000 LOC.
Isaac Gouy
> "Isaac Gouy" <ig...@yahoo.com> wrote:
>
> > There are things about Nice that will appeal to you - it's intended to
> > be a safer language than Java - distinguishing between ordinary types
> > and Option Types which may include null, works wonders for
> > NullPointerExceptions;
>
> This brings to mind one of Java's least successful endeavors: for a
> language which claims not to _have_ pointers, finding the most common
> way for software to die is via a _pointer_ exception is _way_
> offputting. The Java compiler could do a lot more work to do path
> analysis and warn the programmer if a way to achieve a null dereference
> exists in the code, other language's compilers do
Quite - all those runtime failures are a bit much after the sermons on
static type checking ;-)
> Still, a lint()-like
> routine that spent the extra effort at the programmer's option to do
> such path analysis would be a welcome toolkit member; does such exist?
Don't know.
> Referring back to Nice, which I've looked at briefly, I suspect putting
> the burden on the programmer to express the suitability of "null" as a
> value for each object reference is entirely appropriate, and the markups
> that Perl, for example, requires for the programmer to define the
> intention of a token as a scalar, array, hash, or function name is
> similar in impact: a slight mental adjustment and you're there.
> You might want to look at OCaml,
Thanks, last year I gave it a try and stumbled over my confusion about
OCamls ideas about subtyping. It seemed that there were more hoops to
jump through - that hasn't seemed to be the case with Nice.
> I'm a bit excluded by lacking more than a cursory idea of the
> functioning of functional programming.
It's hard to gain a new way to think about programming. I'm just
starting to grok simple algebraic datatypes and think about
programming as transformation.
> That's if you're still in the new language learning mode. Each new
> one for me is becoming more and more of a struggle as I deal with the
> problems of advancing age, and Java as a language system in the large
> is growing faster than I can keep up, so far, which is actually praise.
Doing more of the same had less and less appeal. Happily I stumbled
onto a purist functional language which forced me to think differently
about programming. Clean compiles to fast code, but it's definitely
more of an research language than OCaml.
Martin Drautzburg
> > There are probably all levels of programmers, just are
> > there are in any profession. Is it truly unimaginable
> > that some programmers are capable of delivering quality
> > (tested) systems without the assistance of compile-time
> > type checking?
>
> It is truly imaginable that anyone I have ever heard make
> that claim for him or her self was just excusing bone
> laziness.
In software laziness is a virtue not a vice.
> I have known half a dozen people with 180 IQs in
> my life, and most likely each of them could pull it off, but
> definitely each of them has better sense than to try, as
> well. For the rest of us, yes, it is truly unimaginable, and
> the record bears me out.
But then how could a handful of people possibly write most of an
operating system, a windowing system, a virtual machine an IDE
including the compiler and a debugger in a dynamically typed language
and that within just a few years ?
This is what happened with squeak (written mostly in itself). Dynamic
typing can't be all that bad if such things are possible.
How much does IBM spend on Eclipse ?
Tor Iver Wilhelmsen
> True, but that was a late and rather grungy add-on, and not central
> to to the language.
No, but backward-compatible since the compiler creates top-level
classes and any necessary accessors for private members. It lets you
write code in the context where it's used, but is really just
syntactic sugar for helper classes.
> The other key part of Lisp of course would be the ability to
> manipulate internal program code as structured data.
>
> Again, not much of this in Java.
Well that would be considered a major security hole in some contexts.
> Then a fairly basic and ordinary (and not that great) langauge was
> made for it.
And then it became very popular, and a lot of fans of niche languages
got envious. :P
The Ghost In The Machine
<nos...@stormwind-studios.com>
wrote
on Mon, 29 Sep 2003 13:33:01 -0400
<y9_db.29066$0Z5.24543@lakeread03>:
A trick that may make you wonder...
* * *
import java.lang.reflect.Field;
public class T1
{
public static void main(String[] args) throws Exception
{
String s1 = "Hello, world";
System.out.println(s1);
Field field = String.class.getDeclaredField("value");
field.setAccessible(true); // ??!
char[] v = (char[]) field.get("Hello, world");
System.out.println(v);
v[0] = 'G';
v[1] = 'o';
v[2] = 'o';
v[3] = 'd';
v[4] = 'b';
v[5] = 'y';
v[6] = 'e';
v[7] = ',';
v[8] = ' ';
v[9] = 'm';
v[10] = 'e';
v[11] = '!';
System.out.println(s1);
System.out.println("Hello, world");
}
}
* * *
Disclaimer: Anyone using this in a production program should
probably have their head examined. :-)
Nor am I the inventor of this; I'll admit I don't know now where
I got the idea from.
--
#191, ewi...@earthlink.net
It's still legal to go .sigless.
Kent Paul Dolan
> "Kent Paul Dolan" <xant...@well.com> writes:
[can anyone code better without doing the extra effort
needed for static type checking?]
>> It is truly imaginable that anyone I have ever heard make
>> that claim for him or her self was just excusing bone
>> laziness.
> In software laziness is a virtue not a vice.
That laziness captured in the aphorism "good programmers
write great code; great programmers *steal* great code" is
indeed a virtue; I've sat beside a colleague (Pedro Tsai)
who was twenty times as productive as those around him yet
rarely needed to write original code: it's a mindset.
That laziness which results in code suffering run time
failures that could have been caught in the compilation
stage is _not_ a virtue, it is a menace, much like the
habits of programmers who write code as if they were to
be its only readers.
Pithy saying need to be kept within the limits of their
applicability; if allowed to stray outside those limits,
and taken as universal truths, they trend to disaster.
>> I have known half a dozen people with 180 IQs in my life,
>> and most likely each of them could pull it off, but
>> definitely each of them has better sense than to try, as
>> well. For the rest of us, yes, it is truly unimaginable,
>> and the record bears me out.
> But then how could a handful of people possibly write most
> of an operating system, a windowing system, a virtual
> machine an IDE including the compiler and a debugger in a
> dynamically typed language and that within just a few
> years ?
Umm, writing an OS is a senior year one semester class one
person undergraduate programming chore the last place I took
classes. Again, stealing working code or design can make any
project go forward quickly. Speed is not a distinguisher
between the two coding styles. What you describe isn't
really that fast a pace, given that working examples of all
the parts in other applications were available from the
beginning.
> This is what happened with squeak (written mostly in
> itself).
The GNU Ada Translator, except for an initial bootstrap
version, is written entirely in Ada, a language with
severely strong typing, and is ported by cross-compilers
again written in Ada; so "written in itself" is not a
distinguisher between the two coding styles.
> Dynamic typing can't be all that bad if such things are
> possible.
You've lost track of the goal here, which was to improve
the *quality* of software widely distributed for direct
Internet interface use, to reduce the set of current
disasters from buggy code. As I've said at least three
times already in this thread, choosing the faster, less
secure coding style is exactly how that code gains
access to the outside world.
> How much does IBM spend on Eclipse ?
Why would I know or care? I write software with a text
editor, not a crutch.
xanthian.
Kent Paul Dolan
> A trick that may make you wonder...
[...]
> Disclaimer: Anyone using this in a production program should
> probably have their head examined. :-)
Oh, that's nasty. Reminds me of the proof of concept trojan installation
into an Ada(?) compiler, that in three recompilations of itself made the
sabotage invisible in the compiler source code.
James A. Robertson
<xant...@well.com> wrote:
>"Martin Drautzburg" <martin.d...@web.de> wrote:
>
>> "Kent Paul Dolan" <xant...@well.com> writes:
>That laziness which results in code suffering run time
>failures that could have been caught in the compilation
>stage is _not_ a virtue, it is a menace, much like the
>habits of programmers who write code as if they were to
>be its only readers.
>
10 years of Smalltalk development. I can still count - on one hand -
the number of times I've had such a type error. Now, in the last 10
years, with the fantastic help of your static type system, how many
such type errors has the compiler brought to your attention?
If it's more than a handful, you might want to ponder it.
>Pithy saying need to be kept within the limits of their
>applicability; if allowed to stray outside those limits,
>and taken as universal truths, they trend to disaster.
>
That's static typing and safety, in a nutshell. Note that static
typing didn't help the Ariane 5, but rigorous testing would have.
<Talk Small and Carry a Big Class Library>
Kent Paul Dolan
> "Kent Paul Dolan" <xant...@well.com> wrote:
>> That laziness which results in code suffering run time
>> failures that could have been caught in the compilation
>> stage is _not_ a virtue, it is a menace, much like the
>> habits of programmers who write code as if they were to
>> be its only readers.
> 10 years of Smalltalk development. I can still count - on
> one hand - the number of times I've had such a type error.
Umm, but of course, with dynamic type checking, it is your
customers who normally first encounter them, since after all
your code _passed_ your testing, and they often respond by
not bothering to return.
> Now, in the last 10 years, with the fantastic help of your
> static type system, how many such type errors has the
> compiler brought to your attention?
How many type errors has the compiler caught? Several per
hour of programming. In large part that is because I
program deliberately so that logic errors are caught as type
conflict errors whenever possible. My experience with Ada
has been that code that compiled with that development model
is code that executed correctly the first time it was
tested.
> If it's more than a handful, you might want to ponder it.
Sure. I don't have to claim to be a superman, and yet I
still get out more reliable code than you do. Not much to
ponder. My only delivered COBOL program ever, implemented
a small self-contained database with no outside DBMS; when
I delivered it I never heard back from the user, and thought
they'd decided not to employ it. When I asked why they
weren't using it, a few years later, they told me all 20 of
them used it daily, it just had never suffered a failure or
needed an interface improvement. Not bad for a language I
learned to write that one bit of code.
>> Pithy sayings need to be kept within the limits of their
>> applicability; if allowed to stray outside those limits,
>> and taken as universal truths, they trend to disaster.
> That's static typing and safety, in a nutshell. Note that
> static typing didn't help the Ariane 5, but rigorous
> testing would have.
Interesting choice of examples, since the Ariane 5 crash was
caused by a human engineering error, a decision to reuse
part of the nozzle control software without taking the expense
to re-analyze, rework, and retest it, and was completely
independent of the language used; Logo or BASIC would have
had the same nose first landing result. Making the choice to
avoid the "expense" of writing code in a language supporting
strong static typing, because that is a less fun programming
modality for the prima donna developers, is a similar human
engineering error, with similar results to be expected.
But hey, if your code doesn't do anything important, why do
you care? My COBOL program was used in an application where
human life and large property loss was at risk from software
errors, so I bothered to take the time to make sure it was
correct with every tool available, not just the fun to use
ones.
Thomas Gagné
>"Thomas Gagné" <tga...@wide-open-west.com> wrote
>
>
>
>>Considering we already have software disasters with the
>>predominant languages all supporting static typing
>>suggests (at least) that compile-time testing is
>>inadequate to the task (I think we all agree on this) but
>>that testing is the only way to prove a system's
>>/correctness/.
>>
>>
>
>Bzzzt! The proof that proving a program's correctness by
>testing is infeasible is an undergraduate computer science
>exercise.
>
Good point. Can we agree that testing gets us closer to delivering a
quality system than compiling and linking does?
><snip>
>
>
>>If the latter is the target and the former does not
>>guarantee the latter, then do we need the former?
>>
>>
>
>Nothing we can pay for "does the latter", we are in a mode
>of trying to move to "doing the best we can" rather than
>"doing the least we can".
>
>You need the former because it takes out a whole class of
>frequent errors quickly, automatically, and most important,
>cheaply in comparision to formal SQA methods. In a large
>programming effort, programmers are a small minority of all
>salary costs, so having programmers work harder to save
>overall costs makes economic sense.
>
I'd like to agree with you on the last point, but the offshore industry
would be less appealing were it true.
Our experience about compile time checking is from two different
universes. But it recently occurred to me why those types of errors are
less frequent (mostly absent) in Smalltalk than they are in Java, and it
has to do with idiom.
In Smalltalk, if I want a read or write stream on an object (a file or
an array) I ask the object to return me a stream of the proper type. I
don't have to know what the proper type is and be sure I pass it the
correct argument to its constructor. This is where /nearly all/ my type
errors come from in Java--parameters to constructors. I sometimes
reverse them (because I don't remember their order) or I forget an
argument (because I forget its there). This is another kind of error
that doesn't happen in Smalltalk because the method's signature suggests
both the number, types, and order of its parameters.
So James Robertson isn't blowing smoke on this, though I wasn't prepared
to offer any reasons why Smalltalkers don't appreciate the value of
compile-time type checking. Considering those reasons, Java programmers
are right, compiler errors are needed because Java programming is prone
to these kinds of errors.
But that's OK. It's what Java programmers want.
><snip
>
>On the issue of payback, read the publications of the
>Software Engineering Institute, in particular their widely
>used Capability Maturity Model book, and judge for yourself;
>I lent my copy out and never got it back. Sigh.
>
>http://www.sei.cmu.edu/publications/publications.html
>
Thanks for the link. I'll check it out. I've had books go unreturned.
I've started writing my name on the pages, inside the cover, everywhere
I can to make sure that if people don't return them to me, they at least
will be reminded of it everytime they look at the book.
>
>
>
>>There are probably all levels of programmers, just are
>>there are in any profession. Is it truly unimaginable
>>that some programmers are capable of delivering quality
>>(tested) systems without the assistance of compile-time
>>type checking?
>>
>>
>
>It is truly imaginable that anyone I have ever heard make
>that claim for him or her self was just excusing bone
>laziness. I have known half a dozen people with 180 IQs in
>my life, and most likely each of them could pull it off, but
>definitely each of them has better sense than to try, as
>well. For the rest of us, yes, it is truly unimaginable, and
>the record bears me out.
>
I've decided that I think you're right, but for different reasons. It
is possible to design a language and its class libraries that don't
*require* static typing just as it is possible to design a language that
does. I would never advocate removing compile-time checking from Java.
It just couldn't work no matter your IQ.
>
>
>
>><snip>
>>
>
>Given that there is little choice in good times but to
>employ programmers at all levels of competence, the question
>of whether to give them all the double-checking help they
>can get, whether they want it or not, has an obvious answer
>if software quality and on-time deliver are important to
>you as an employer.
>
Good point. It's too bad programmers as a whole are considered only as
competent as their weakest link, and there's more of them than there are
strong ones. But the market is determined by the masses... sigh.
>
>
>
>>If insanity really is doing the same thing over and over
>>again and expecting a different result is it possible
>>statically typed languages and the assumptions about them
>>have outlived their usefulness?
>>
>>
>
>No, but it is possible you are slipping into ranting instead
>of discussing.
>
Perhaps. I guess I was wondering out loud to myself. I can type nearly
as fast as I think, even on my QWERTY keyboard (another topic.. :-)
Thomas Gagné
So, don't keep us in suspense! How many type errors were there in a
week's worth of 5000 lines of Smalltalk?
It does seem like a lot of code for a week. Perhaps you didn't have
enough time to make it shorter?
Phillip Lord
Thomas> Martin Drautzburg wrote:
>>
>> A few weeks ago I made a strange observation. I had written a
>> little application in squeak (Smalltalk). It had taken me about a
>> week. Before I showed it to by colleagues I counted the lines of
>> code because I wanted to say: "see you can write that within a
>> week and it only takes 800 LOC".
>>
>> To my surprize I counted 5000 LOC.
Thomas> So, don't keep us in suspense! How many type errors were
Thomas> there in a week's worth of 5000 lines of Smalltalk?
I thought it was a nice story. "I'll just knock this up" are classic
famous last words. You often find that you have written more than you
think.
Phil
James A. Robertson
>> 10 years of Smalltalk development. I can still count - on
>> one hand - the number of times I've had such a type error.
>
>Umm, but of course, with dynamic type checking, it is your
>customers who normally first encounter them, since after all
>your code _passed_ your testing, and they often respond by
>not bothering to return.
Nope. With BottomFeeder - an RSS news aggregator - I get bug reports,
but they are typically related to either HTML display or RSS handling
issues. I've yet to get a bug report related to a type error. I run
the app on my desktop day in and day out, and that class of error just
doesn't come up. It's one static typing advocates <think> is common -
but when using Smalltalk, it just isn't.
>
>> Now, in the last 10 years, with the fantastic help of your
>> static type system, how many such type errors has the
>> compiler brought to your attention?
>
>How many type errors has the compiler caught? Several per
>hour of programming. In large part that is because I
>program deliberately so that logic errors are caught as type
>conflict errors whenever possible. My experience with Ada
>has been that code that compiled with that development model
>is code that executed correctly the first time it was
>tested.
That's because the compiler forces you to make premature - and mostly
useless - type decisions. Logic errors are simply not caught by
static typing. If you think they are, you are truly, truly naive.
>
>> If it's more than a handful, you might want to ponder it.
>
>Sure. I don't have to claim to be a superman, and yet I
>still get out more reliable code than you do. Not much to
And you base this on what? That you've compared your results to mine?
Heck, on that basis, I'll state that my employment status proves that
I produce better code than you. Not a fair measure, but every bit as
accurate as yours.
<Talk Small and Carry a Big Class Library>
Dr Chaos
>
> 10 years of Smalltalk development. I can still count - on one hand -
> the number of times I've had such a type error. Now, in the last 10
> years, with the fantastic help of your static type system, how many
> such type errors has the compiler brought to your attention?
But you know that's not fair, because in a statically
type constrained language, people use the type system to express
constraints and requirements which would be expressed in
different ways in a different language.
>>Pithy saying need to be kept within the limits of their
>>applicability; if allowed to stray outside those limits,
>>and taken as universal truths, they trend to disaster.
>>
>
> That's static typing and safety, in a nutshell. Note that static
> typing didn't help the Ariane 5, but rigorous testing would have.
static type proofs eliminate one category of errors.
but I think the more important part of type checks is not in initial
development, but when you (or somebody else) goes back to work with
code that they haven't used at least in a long time.
I find I make a number of silly errors in the initial stages
which type checks quickly find for me.
>>Why would I know or care? I write software with a text
>>editor, not a crutch.
and a visual editor like emacs is a crutch instead of
teco
and automatic static type checking is a crutch instead of
random errors.
Isaac Gouy
> Nor did I claim so; had you bothered to _read_ the "as
> described above", you would have noticed that I had turned
> your bogus exoneration of Smalltalk around to point out the
> situation where Smalltalk's vulnerabilities lie, which, when
> provoked, cause exactly the same situation as with C/C++:
> code is executed that has no business _being_ executed, and
> the application goes crashy burny bye bye.
>
> In the case of C/C++, that is because all function pointers
> are interchangable; in the case of Smalltalk, that is
> because all similarly-signatured methods are interchangable;
> in each case, the weak typing allows entities that match by
> coincidence the form of the entity the programmer actually
> intended to address to be used in inappropriate situations
> leading to program failure, in both cases, stronger typing
> in better programming languages provides a way to catch that
> kind of error at compile time.
Let's say we have 2 unrelated classes, Blob and Green, and we have a
method with the same signature that they (or a superclass) implements
- plang. Further, let's say that we have some arbitrary method with a
single argument and in that method we do this:
myMethod: someObject
someObject plang
It seems that you are pointing out that if (for whatever reason)
someObject is a Blob when it was intended to be a Green, then plang
will still succeed (and perhaps destructively change the Blob).
In contrast, if this was some statically checked language then we
would probably have one of these (assuming no common superclass or
interface) and the error would be detected at compile time:
void myMethod(Blob someObject){ someObject.plang };
or
void myMethod(Green someObject){ someObject.plang };
That seems correct as a statement of a possibly unsafe situation. (I
don't believe I've ever encountered that situation, but I probably
wouldn't remember and you're point was that it was possible not
common.)
Isaac Gouy
> You've lost track of the goal here, which was to improve
> the *quality* of software widely distributed for direct
> Internet interface use, to reduce the set of current
> disasters from buggy code.
AFAIK many of the widely reported problems (buffer overflows) result
from lack of run-time checks rather than lack of static type checks.
Tony Hoare on implementing Algol 60 (in 1961)
http://www.braithwaite-lee.com/opinions/p75-hoare.pdf
"(1) The first principle was security: ...
A consequence of this principle is that every occurrence of every
subscript of every subscripted variable was on every occasion checked
at run time against both the upper and the lower declared bounds of
the array.
Many years later we asked our customers whether they wished us to
provide an option to switch off these checks in the interests of
efficiency on production runs. Unanimously, they urged us not to -
they already knew how frequently subscript errors occur on production
runs where failure to detect them could be disastrous.
"
James A. Robertson
<mbkennelS...@NOSPAMyahoo.com> wrote:
>James A Robertson <jar...@gosmalltalk.com> wrote:
>>
>> 10 years of Smalltalk development. I can still count - on one hand -
>> the number of times I've had such a type error. Now, in the last 10
>> years, with the fantastic help of your static type system, how many
>> such type errors has the compiler brought to your attention?
>
>But you know that's not fair, because in a statically
>type constrained language, people use the type system to express
>constraints and requirements which would be expressed in
>different ways in a different language.
Why is it not fair? Xanthian's point is that w/o static typing, there
will be chaos - all manner of uncaught errors. The reality is, that
class of error is exceedingly rare in Smalltalk - rare enough that
it's not worth worrying about.
By contrast, in languages like Java, you get irritating "oops, it
wanted a long, not an int" errors on a regular basis. The system is
complaining about a problem that is effectively irrelevant (assuming a
decent type system). And yet there it is, wasting your time.
>
>>>Pithy saying need to be kept within the limits of their
>>>applicability; if allowed to stray outside those limits,
>>>and taken as universal truths, they trend to disaster.
>>>
>>
>> That's static typing and safety, in a nutshell. Note that static
>> typing didn't help the Ariane 5, but rigorous testing would have.
>
>static type proofs eliminate one category of errors.
>
>but I think the more important part of type checks is not in initial
>development, but when you (or somebody else) goes back to work with
>code that they haven't used at least in a long time.
>
I have far more trouble looking at C or C++ code - and I know both -
that I haven't had experience with than I have looking at Smalltalk
code I've never seen. By your reasoning, those type declarations
should help me. They don't; they are meaningless noise.
>I find I make a number of silly errors in the initial stages
>which type checks quickly find for me.
>
>>>Why would I know or care? I write software with a text
>>>editor, not a crutch.
>
>and a visual editor like emacs is a crutch instead of
>teco
>
>and automatic static type checking is a crutch instead of
>random errors.
If you actually got them enough to worry about, sure. Forcing
developers to make the declarations is the primary cause of the errors
found by the compiler. I'm sure it makes you happy, but it's not
accomplishing anything useful.
James A. Robertson
>"Kent Paul Dolan" <xant...@well.com> wrote
> -SNIP-
>> You've lost track of the goal here, which was to improve
>> the *quality* of software widely distributed for direct
>> Internet interface use, to reduce the set of current
>> disasters from buggy code.
> -SNIP-
>
>AFAIK many of the widely reported problems (buffer overflows) result
>from lack of run-time checks rather than lack of static type checks.
Yep. Years of developers worrying about exactly the wrong thing.
>
>
>Tony Hoare on implementing Algol 60 (in 1961)
>http://www.braithwaite-lee.com/opinions/p75-hoare.pdf
>
>"(1) The first principle was security: ...
>A consequence of this principle is that every occurrence of every
>subscript of every subscripted variable was on every occasion checked
>at run time against both the upper and the lower declared bounds of
>the array.
>
>Many years later we asked our customers whether they wished us to
>provide an option to switch off these checks in the interests of
>efficiency on production runs. Unanimously, they urged us not to -
>they already knew how frequently subscript errors occur on production
>runs where failure to detect them could be disastrous.
>"
<Talk Small and Carry a Big Class Library>
Martin Drautzburg
> >A few weeks ago I made a strange observation. I had written a little
> >application in squeak (Smalltalk). It had taken me about a
> >week. Before I showed it to by colleagues I counted the lines of code
> >because I wanted to say: "see you can write that within a week and it
> >only takes 800 LOC".
> >
> > To my surprize I counted 5000 LOC.
>
> So, don't keep us in suspense! How many type errors were there in a
> week's worth of 5000 lines of Smalltalk?
There were probably about as many error as there were lines of
code. Most of them typing errors. These were fixed within seconds. Er
- you asked for *type* errors not typing errors didn't you. Well I
didn't pay attention. I didn't know they were something special.
> It does seem like a lot of code for a week. Perhaps you didn't have
> enough time to make it shorter?
Absolutely right.
The Ghost In The Machine
<xant...@well.com>
wrote
on Tue, 30 Sep 2003 04:34:33 +0000 (UTC)
<07ef50ed52fc83a9747...@mygate.mailgate.org>:
> "The Ghost In The Machine" <ew...@sirius.athghost7038suus.net> wrote
>
>> A trick that may make you wonder...
> [...]
>> Disclaimer: Anyone using this in a production program should
>> probably have their head examined. :-)
>
> Oh, that's nasty. Reminds me of the proof of concept trojan installation
> into an Ada(?) compiler, that in three recompilations of itself made the
> sabotage invisible in the compiler source code.
>
> xanthian.
>
Fortunately, I think the Java example would be caught by SecurityAccess.
(I sure hope so! :-) ) But it is an interesting failure.
Tim Tyler
> I have far more trouble looking at C or C++ code - and I know both -
> that I haven't had experience with than I have looking at Smalltalk
> code I've never seen. By your reasoning, those type declarations
> should help me. They don't; they are meaningless noise.
If you pay attention they tell you the types of things.
That lets you know what you can do with them.
In dynamically typed languages, neither the compiler - nor often the
programmer - knows the type of the object they are dealing with ;-)
--
__________
|im |yler http://timtyler.org/ t...@tt1lock.org Remove lock to reply.
James A. Robertson
>James A. Robertson <jar...@gosmalltalk.com> wrote or quoted:
>
>> I have far more trouble looking at C or C++ code - and I know both -
>> that I haven't had experience with than I have looking at Smalltalk
>> code I've never seen. By your reasoning, those type declarations
>> should help me. They don't; they are meaningless noise.
>
>If you pay attention they tell you the types of things.
>That lets you know what you can do with them.
Not in any terribly useful way, no. Looking at senders/implementors
in a Smalltalk system gets me the same information w/o the burden of
typing
>
>In dynamically typed languages, neither the compiler - nor often the
>programmer - knows the type of the object they are dealing with ;-)
The developer - speaking from experience - almost always knows. And
if I don't, an inspector on the real live object will tell me
Dr Chaos
> On Tue, 30 Sep 2003 17:12:56 +0000 (UTC), Dr Chaos
><mbkennelS...@NOSPAMyahoo.com> wrote:
>
>>James A Robertson <jar...@gosmalltalk.com> wrote:
>>>
>>> 10 years of Smalltalk development. I can still count - on one hand -
>>> the number of times I've had such a type error. Now, in the last 10
>>> years, with the fantastic help of your static type system, how many
>>> such type errors has the compiler brought to your attention?
>>
>>But you know that's not fair, because in a statically
>>type constrained language, people use the type system to express
>>constraints and requirements which would be expressed in
>>different ways in a different language.
>
> Why is it not fair? Xanthian's point is that w/o static typing, there
> will be chaos - all manner of uncaught errors.
I don't agree with this. There will surely be errors caught somewhere
in any case, but where, and when?
> The reality is, that
> class of error is exceedingly rare in Smalltalk - rare enough that
> it's not worth worrying about.
type errors in one language will not be type errors in another,
so if you restrict yourself to only looking at one category it will
not be a fair comparison.
> By contrast, in languages like Java, you get irritating "oops, it
> wanted a long, not an int" errors on a regular basis. The system is
> complaining about a problem that is effectively irrelevant (assuming a
> decent type system). And yet there it is, wasting your time.
>
>>
>>>>Pithy saying need to be kept within the limits of their
>>>>applicability; if allowed to stray outside those limits,
>>>>and taken as universal truths, they trend to disaster.
>>>>
>>>
>>> That's static typing and safety, in a nutshell. Note that static
>>> typing didn't help the Ariane 5, but rigorous testing would have.
>>
>>static type proofs eliminate one category of errors.
>>
>>but I think the more important part of type checks is not in initial
>>development, but when you (or somebody else) goes back to work with
>>code that they haven't used at least in a long time.
>>
>
> I have far more trouble looking at C or C++ code - and I know both -
> that I haven't had experience with than I have looking at Smalltalk
> code I've never seen.
well using is more important than looking.
> By your reasoning, those type declarations
> should help me. They don't; they are meaningless noise.
C++ sucks, mkay?
>>I find I make a number of silly errors in the initial stages
>>which type checks quickly find for me.
>>
>>>>Why would I know or care? I write software with a text
>>>>editor, not a crutch.
>>
>>and a visual editor like emacs is a crutch instead of
>>teco
>>
>>and automatic static type checking is a crutch instead of
>>random errors.
>
> If you actually got them enough to worry about, sure. Forcing
> developers to make the declarations is the primary cause of the errors
> found by the compiler.
No I don't think so. It causes the point of detection of the error to
migrate to edges instead of internals. If you have an error in the
internal was it because of the wrong thing passed or wrong internal
code? Who (I mean literally if two people wrote the sections) is
responsible?
why should anybody declare names of arguments? Can't you
figure out what things are supposed to do from the context?
> I'm sure it makes you happy, but it's not
> accomplishing anything useful.
>
>
><Talk Small and Carry a Big Class Library>
> James Robertson, Product Manager, Cincom Smalltalk
> http://www.cincomsmalltalk.com/blog/blogView
--
---------------------------------------------
Matthew Kennel, mke...@ucsd.edu
Institute For Nonlinear Science, UC San Diego
---------------------------------------------
Dr Chaos
>
>>James A. Robertson <jar...@gosmalltalk.com> wrote or quoted:
>>
>>> I have far more trouble looking at C or C++ code - and I know both -
>>> that I haven't had experience with than I have looking at Smalltalk
>>> code I've never seen. By your reasoning, those type declarations
>>> should help me. They don't; they are meaningless noise.
>>
>>If you pay attention they tell you the types of things.
>>That lets you know what you can do with them.
>
> Not in any terribly useful way, no. Looking at senders/implementors
> in a Smalltalk system gets me the same information w/o the burden of
> typing
you can find out post-hoc what type an object actually is, not what type
the variable was probably supposed to be.
>>In dynamically typed languages, neither the compiler - nor often the
>>programmer - knows the type of the object they are dealing with ;-)
>
> The developer - speaking from experience - almost always knows. And
> if I don't, an inspector on the real live object will tell me
what it is is not the issue, what it should be is.
Isaac Gouy
> >> 10 years of Smalltalk development. I can still count - on
> >> one hand - the number of times I've had such a type error.
Let me suggest that has something to do with your expertise.
Maybe a more interesting question is how often does a Smalltalk newbie
make that mistake, or deletes a method without checking senders, or
...
Of course, now we all do TDD...
(I do agree that programmers experienced with dynamically checked
languages don't make the kind of 'type mistakes' that someone who has
only used a statically checked language might imagine. Part of the
reason is that they manually check what the methods will do, and
manually document the argument types. The usual problem is failing to
initialize dynamic data structures correctly.)
> >> Now, in the last 10 years, with the fantastic help of your
> >> static type system, how many such type errors has the
> >> compiler brought to your attention?
> >
> >How many type errors has the compiler caught? Several per
> >hour of programming. In large part that is because I
> >program deliberately so that logic errors are caught as type
> >conflict errors whenever possible. My experience with Ada
> >has been that code that compiled with that development model
> >is code that executed correctly the first time it was
> >tested.
>
> That's because the compiler forces you to make premature - and mostly
> useless - type decisions.
Languages without polymorphism force you to make premature type
decisions. Using a statically checked language that supports many
forms of polymorphism is very different from using a statically
checked language like Modula-2.
Anyway, given that we refactor like crazy in Smalltalk, perhaps we
should accept that if a premature type decision has been made then it
will be unmade when the code is refactored ;-)
Yes, there are false positives. They are errors that are purely an
artifact of the limitations of the particular type system - shouldn't
we be able to use int where-ever we use double?
> Logic errors are simply not caught by
> static typing. If you think they are, you are truly, truly naive.
That overstates the situation - some logic errors are revealed by
static type checking, even with something as simple as Modula-2.
-SNIP-
Isaac Gouy
Maybe you missed the Smalltalk joke -
> It does seem like a lot of code for a week. Perhaps you didn't have
> enough time to make it shorter?
The refactoring experience is to add functionality and reduce line
count, simultaneously ;-)
James A. Robertson
>James A. Robertson <jar...@gosmalltalk.com> wrote
>> On Tue, 30 Sep 2003 06:08:13 +0000 (UTC), "Kent Paul Dolan" >
>
>> >> 10 years of Smalltalk development. I can still count - on
>> >> one hand - the number of times I've had such a type error.
>
>Let me suggest that has something to do with your expertise.
>
>Maybe a more interesting question is how often does a Smalltalk newbie
>make that mistake, or deletes a method without checking senders, or
>...
>Of course, now we all do TDD...
I clearly recall not getting type errors of that sort when I started
with Smalltalk, and could barely find my way around a browser.
<Talk Small and Carry a Big Class Library>
Kent Paul Dolan
> I can type nearly as fast as I think
Man, if I could only think as slowly as I type, how much better
considered a set of thoughts I could produce.
Kent Paul Dolan
> Logic errors are simply not caught by
> static typing. If you think they are,
> you are truly, truly naive.
Or, not having put static typing to much
use, you don't know how to use it write
code whose logic errors are caught as
type conflicts, a possiblity that you
might consider, since my experience is
hardly rare in the Ada community.
Kent Paul Dolan
> That seems correct as a statement of a possibly unsafe
> situation. (I don't believe I've ever encountered that
> situation, but I probably wouldn't remember and you're
> point was that it was possible not common.)
Possible, yes. Uncommon? Humans are creatures of habit,
and I know I have multiple methods in multiple classes all
capable of returning their names as a string, and all named
"getName()". If I ask the object to return its name, but it
is an object of an unexpected class with a name in an
unanticipated format not captured as "signature", something
just broke when I go to use that name further.
In a "programming in the large" situation, where hundreds
(in the largest shop in which I've worked, bigger ones
exist) of worker-bee programmers add code to a common base,
the chances of method name and signature collisions
somewhere in the code base is essentially 100%. What are the
odds that an object of the wrong class but with the matching
method will be used as an argument? Larger if there is no
need for the class to be correct for the method to be
called. This is the environment and the situation where
static type checking is most needed: where programmers
unfamiliar with the entire code base (and in a shop of that
size, being so is humanly impossible) must depend on
namespace barriers such as class types to prevent
inadvertant successful use of inappropriately accessed
methods.