Hello!
I need your advice! Last summer I took an introductory programming
course and learned a little bit of Scheme, even tho I didn't like it
too much...
HOwever, I realized that I want to be better at this stuff and learn
more about programming. It's fascinating. I talked to some of my
friedns and told them that I want to be a better programmer. I'm
thinking of learning a new programming language, but I do not know
which. Basically, I do not particularly care about the details, such
as if a language is windows-only. What I do care about is learning
something new.
So, one of my friends tells me that I should learn C++, because "it's
the best". But, seriously, he doesn't know anything but C++, so I'm
not too sure if he is qualified to give this type of advice...
Another friend tells me "define what you mean by 'better programmer'".
So, that guy wasn't too helpful either. So I thought about this A LOT,
and I'm wonderingif I could ask for advice on the internet.
Thanks in advance for your time...
"Scott" <·············@yahoo.com> wrote in message
> So, one of my friends tells me that I should learn C++, because "it's the
best".
The guy must be joking. HTML is the king. Learn it first.
Newbie wrote:
>
>
>"Scott" <·············@yahoo.com> wrote in message
>> So, one of my friends tells me that I should learn C++, because "it's the
>best".
>
>The guy must be joking. HTML is the king. Learn it first.
>
>
I hope you are joking. HTML is not a programming language.
"Peter Ward" <··@ha.ha> wrote in message
··························@news.demon.co.uk...
> Newbie wrote:
>
> >
> >
> >"Scott" <·············@yahoo.com> wrote in message
> >> So, one of my friends tells me that I should learn C++, because "it's
the
> >best".
> >
> >The guy must be joking. HTML is the king. Learn it first.
> >
> >
>
> I hope you are joking. HTML is not a programming language.
>
Alright, I'll take it back. Assembly is the king. Learn it first.
Newbie wrote:
> "Peter Ward" <··@ha.ha> wrote in message
> ··························@news.demon.co.uk...
>
>>Newbie wrote:
>>
>>
>>>
>>>"Scott" <·············@yahoo.com> wrote in message
>>>
>>>>So, one of my friends tells me that I should learn C++, because "it's
>>>
> the
>
>>>best".
>>>
>>>The guy must be joking. HTML is the king. Learn it first.
>>>
>>>
>>
>>I hope you are joking. HTML is not a programming language.
>>
>
> Alright, I'll take it back. Assembly is the king. Learn it first.
>
Is there a computer programming language for trolls? ;-)
White Wolf wrote:
> Is there a computer programming language for trolls? ;-)
Obviously not Lisp, because so many trolls seem to end up in comp.lang.lisp
bashing it. Probably Perl. That's because it's the programming language
for everyone, right?
faa
"Peter Ward" <··@ha.ha> wrote in message
··························@news.demon.co.uk...
> Newbie wrote:
>
> >
> >
> >"Scott" <·············@yahoo.com> wrote in message
> >> So, one of my friends tells me that I should learn C++, because "it's
the
> >best".
> >
> >The guy must be joking. HTML is the king. Learn it first.
> >
> >
>
> I hope you are joking. HTML is not a programming language.
>
But it is a good way to get your feet wet in programming.
Most people are familiar with a word processor, so learning "how" the text
changes from plain to bold to italic is a start.
Then once you understand how HTML formatting changes your code into
something the browser interprets, you can move into client side scripting
such as JavaScript.
The syntax is very close to C/C++/Java and others, and it already has a
large base of objects to play around with in the document object model.
Once you learn how to swap images or make a div fly around the screen, you
should be able to move comfortably into applications with a language that
can make applications.
From there, it's just time and experience before you can develop some things
on your own, or get enough practice to find a job and work your way into the
industry.
--Paul
Peter Ward <··@ha.ha> wrote:
> Newbie wrote:
>
> >
> >
> >"Scott" <·············@yahoo.com> wrote in message
> >> So, one of my friends tells me that I should learn C++, because "it's the
> >best".
> >
> >The guy must be joking. HTML is the king. Learn it first.
> I hope you are joking. HTML is not a programming language.
Yes it is. It's neither Turing complete, nor general purpose, nor very
well designed, but it's definitely a programming language.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3it15yjlk.fsf@cley.com>
* Michael Sullivan wrote:
> Yes it is. It's neither Turing complete, nor general purpose, nor very
> well designed, but it's definitely a programming language.
I think you are pushing it rather hard to count something with no
conditional, variable binding, iteration or recursion constructs as a
programming language.
--tim
Tim Bradshaw <···@cley.com> wrote:
> * Michael Sullivan wrote:
> > Yes it is. It's neither Turing complete, nor general purpose, nor very
> > well designed, but it's definitely a programming language.
> I think you are pushing it rather hard to count something with no
> conditional, variable binding, iteration or recursion constructs as a
> programming language.
Of course I'm pushing it. I certainly think the original person to
suggest it was either joking or trolling or both, and I'm being
extremely pedantic and half-joking myself.
But HTML does represent a language of instructions that an appropriate
interpreter/compiler can translate into computer actions.
In the most general possible sense, it is a programming language. Not
that I would use it for anything other than web-page markup, and that,
only because it's a standard.
This appears to be something of a religious issue among programmers,
many of whom want to set a line where scripting ends and programming
begins, or where usage ends and scripting/programming begins. I can't
say there's no point in trying to categorize like that, but it's pretty
clear that any line you try to draw on that continuum will necessarily
be *very* fuzzy.
The commonality of using certain complex programs and doing programming
was striking to me, who went from a CS curriculum in college, to doing
typesetting outside. Using something like TeX, typesetting clearly can
be programming, by any standard. But even in a GUI like QuarkXpress
before it was scriptable, I was surprised by how much my understanding
of programming abstraction and problem spec definition (learned studying
CS), ended up applying to preparing documents for maximum reuse
potential.
The intro to _How To Design Programs_ does a really good job of getting
the universality of programming as a skill across. Everyone programs,
in the most general sense, whether they realize it or not. The problem
with not realizing it is that you tend to do it badly.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
>>>>> "MS" == Michael Sullivan <·······@bcect.com> writes:
[...]
MS> Of course I'm pushing it. I certainly think the original
MS> person to suggest it was either joking or trolling or both,
MS> and I'm being extremely pedantic and half-joking myself.
It seems so.
MS> But HTML does represent a language of instructions that an
MS> appropriate interpreter/compiler can translate into computer
MS> actions.
As is the language of mouse movement and clicks.
MS> In the most general possible sense, it is a programming
MS> language. Not that I would use it for anything other than
MS> web-page markup, and that, only because it's a standard.
The point is not whether you would or wouldn't, but whether you could.
You most certainly cannot.
MS> This appears to be something of a religious issue among
MS> programmers, many of whom want to set a line where scripting
MS> ends and programming begins, or where usage ends and
MS> scripting/programming begins.
This is an entirely separate issue. Scripting languages are Turing
complete. HTML is not a scripting language.
MS> I can't say there's no point in
MS> trying to categorize like that, but it's pretty clear that any
MS> line you try to draw on that continuum will necessarily be
MS> *very* fuzzy. [...]
That continuum does not include HTML mark-up.
cheers,
BM
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey37khly950.fsf@cley.com>
* Michael Sullivan wrote:
> This appears to be something of a religious issue among programmers,
> many of whom want to set a line where scripting ends and programming
> begins, or where usage ends and scripting/programming begins. I can't
> say there's no point in trying to categorize like that, but it's pretty
> clear that any line you try to draw on that continuum will necessarily
> be *very* fuzzy.
I don't want to set a line between scripting and programming. I do
want to set a line between things that are programming languages and
things that are not. HTML is a grammar: it says that certain strings
are valid and certain are not, and it may also be assign a structure
(a parse tree) to the valid strings. Saying this is a programming
language is like saying that the *syntax* of C is a programming
language.
--tim
Tim Bradshaw wrote:
> * Michael Sullivan wrote:
>
>>This appears to be something of a religious issue among programmers,
>>many of whom want to set a line where scripting ends and programming
>>begins, or where usage ends and scripting/programming begins. I can't
>>say there's no point in trying to categorize like that, but it's pretty
>>clear that any line you try to draw on that continuum will necessarily
>>be *very* fuzzy.
>
>
> I don't want to set a line between scripting and programming. I do
> want to set a line between things that are programming languages and
> things that are not. HTML is a grammar: it says that certain strings
> are valid and certain are not, and it may also be assign a structure
> (a parse tree) to the valid strings. Saying this is a programming
> language is like saying that the *syntax* of C is a programming
> language.
...but you could also argue that HTML is a language that instructs a
computer to generate a certain kind of output on screen. So it could be
regarded as a domain-specific language for static web pages. (And, by
the way, HTML even has conditionals - if you include two forms with two
different submit buttons, then the page reacts differently depending on
whether you press the one button or the other. ;)
However, this whole discussion is mainly useless because the statements
are made in a vacuum. There are situations where it makes sense to view
HTML as a programming language, and there are other situations where it
doesn't. This only depends on the context, and I guess that the
different proponents in this discussion have different contexts in mind.
The reason for this is that there is no sharp boundary between
programming languages and "non-programming" languages, so we are dealing
with dialectics here. Just because there is no sharp boundary between
day and night we can still differentiate between these two states. It
just depends on the context where we draw the line. (For example, some
people have to get up early in the morning, so the day starts earlier
for them than for others. Someone who implements a parser generator
doesn't see any real difference between HTML and "real" programming
languages, but someone who wants to write some highly flexible,
AI-driven state-of-the-art software might regard anything below Lisp to
be far too restrictive. ;)
Pascal
In comp.lang.perl.misc Pascal Costanza <········@web.de> wrote:
> ...but you could also argue that HTML is a language that instructs a
> computer to generate a certain kind of output on screen. So it could be
> regarded as a domain-specific language for static web pages.
with that argument you could say also that anything written is
a programming language. my newsreader prints everything in green
which is preceeded by a starting "> ".
everything in a news-posting/email which comes before the first
empty line is recognized as a header and the newsreader/mail-client
displays it differently. vim displays everything in a config-file
with a starting "#" in a different colour.
but they all can't take any input or even calculate.
they *are* input for a program, in this case for
the browser, news-client, etc.
that "certain kind of output" you mention is not generated
by HTML but by the browser and is defined by a standard.
> (And, by
> the way, HTML even has conditionals - if you include two forms with two
> different submit buttons, then the page reacts differently depending on
> whether you press the one button or the other. ;)
no, the page doesn't react. the cgi-program on the server reacts...
> However, this whole discussion is mainly useless because the statements
> are made in a vacuum. There are situations where it makes sense to view
> HTML as a programming language, and there are other situations where it
> doesn't. This only depends on the context, and I guess that the
> different proponents in this discussion have different contexts in mind.
i agree with that the discussion might be useless (why am i
posting here, anyway? =)
you could also argue that even a program written in a certain
language is only a grammar/markup language if you feed it
into a parser.
but i often here from friends something like "today i learned
programming HTML". and this is just a big misunderstanding
IMHO. and because of that i'd always say that writing HTML
has got *nothing* to do with programming.
those friends might be good at HTML (I'm not...). but they
can't program which is a totally different thing.
but even a nice perl-script/C-/java-program is nothing
without its appropriate interpreter/compiler/virtual machine.
so maybe you can say a language is only a programming
language if there's something that can put it into machine
code. until then it's only grammar or "pseudo-code".
tina
--
http://www.tinita.de/ \ enter__| |__the___ _ _ ___
http://Movies.tinita.de/ \ / _` / _ \/ _ \ '_(_-< of
http://PerlQuotes.tinita.de/ \ \ _,_\ __/\ __/_| /__/ perception
* Pascal Costanza <········@web.de>
| ...but you could also argue that HTML is a language that instructs a computer
| to generate a certain kind of output on screen.
I believe the interesting difference is between languages that instruct a
very general-purpose engine to do specific things for which it was explicitly
designed or intended in the concrete sense on the one hand, and on the other
languages that are mere input languages to specialized applications that
affect how it does its one task, but cannot change that task in any useful
way. That is, HTML is a data language, while JavaScript is a programming
language.
| The reason for this is that there is no sharp boundary between programming
| languages and "non-programming" languages
Of course there is. It is not clear a priori, however, in which category
every language would fall. There is a difference between fuzzy categories
and things that do not fall neatly into only one of them.
| Someone who implements a parser generator doesn't see any real difference
| between HTML and "real" programming languages
That is obviously because he deals with the syntax of the languages, not
their semantics. Just as one who implements a file transfer protocol does
not see any real difference between HTML files and images.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On Sep 16, Michael Sullivan inscribed on the eternal scroll:
> But HTML does represent a language of instructions
No, it doesn't. It's adjectival (this is a paragraph, that is a list
item, this is a quotation by A.N.Other, that is an acronym which means
"garbage in, garbage out"). It doesn't generally give "instructions":
it supplies structural description.
> This appears to be something of a religious issue among programmers,
Oh, so that settles it once and for all, then. Call in the Spanish
Inquisition!
On Mon, 16 Sep 2002 22:55:02 +0200, "Alan J. Flavell"
<·······@mail.cern.ch> wrote:
>On Sep 16, Michael Sullivan inscribed on the eternal scroll:
>
>> But HTML does represent a language of instructions
>
>No, it doesn't. It's adjectival (this is a paragraph, that is a list
>item, this is a quotation by A.N.Other, that is an acronym which means
>"garbage in, garbage out"). It doesn't generally give "instructions":
>it supplies structural description.
>
>> This appears to be something of a religious issue among programmers,
>
>Oh, so that settles it once and for all, then. Call in the Spanish
>Inquisition!
>
I didn't expect the Spanish Inquisition.
--
Regards, Helgi Briem
helgi AT decode DOT is
A: Top posting
Q: What is the most irritating thing on Usenet?
- "Gordon" on apihna
> >> This appears to be something of a religious issue among programmers,
> >
> >Oh, so that settles it once and for all, then. Call in the Spanish
> >Inquisition!
> >
> I didn't expect the Spanish Inquisition.
Nobody expects the Spanish Inquisition!
Here in comp.lang.java.programmer,
"Michiel Konstapel" <···@me.nl> spake unto us, saying:
>> >> This appears to be something of a religious issue among programmers,
>> >
>> >Oh, so that settles it once and for all, then. Call in the Spanish
>> >Inquisition!
>>
>> I didn't expect the Spanish Inquisition.
>
>Nobody expects the Spanish Inquisition!
Of course not. It's chief weapon is surprise. :-)
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + BeOS + Linux + Win95 + DOS + PC/GEOS = PC Hobbyist Heaven! :-)
Applications analyst/designer/developer (13 yrs) seeking employment.
See web site in my signature for current resume and background.
Here in comp.lang.java.programmer,
"Michiel Konstapel" <···@me.nl> spake unto us, saying:
>> >> This appears to be something of a religious issue among programmers,
>> >
>> >Oh, so that settles it once and for all, then. Call in the Spanish
>> >Inquisition!
>>
>> I didn't expect the Spanish Inquisition.
>
>Nobody expects the Spanish Inquisition!
Of course not. Its chief weapon is surprise. :-)
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + BeOS + Linux + Win95 + DOS + PC/GEOS = PC Hobbyist Heaven! :-)
Applications analyst/designer/developer (13 yrs) seeking employment.
See web site in my signature for current resume and background.
········@visi.com (Richard Steiner) writes:
> Of course not. Its chief weapon is surprise. :-)
And fear! Fear, and surprise. :-)
From: Immanuel Litzroth
Subject: Re: becoming a better programmer
Date:
Message-ID: <m2elbrh6f5.fsf@enfocus.be>
>>>>> "Alain" == Alain Picard <·······················@optushome.com.au> writes:
Alain> ········@visi.com (Richard Steiner) writes:
>> Of course not. Its chief weapon is surprise. :-)
Alain> And fear! Fear, and surprise. :-)
Their two main weapons are fear and suprise and ruthless efficiency.
:-)
Immanuel
Immanuel Litzroth wrote:
>>>>>> "Alain" == Alain Picard <apicard+die-spammer-
>>>>>> ···@optushome.com.au> writes:
>
> Alain> ········@visi.com (Richard Steiner) writes:
> >> Of course not. Its chief weapon is surprise. :-)
>
> Alain> And fear! Fear, and surprise. :-)
>
> Their two main weapons are fear and suprise and ruthless
> efficiency. :-)
Their three weapons are fear, surprise, and ruthless efficiency
and an almost fanatical devotion to the Pope.
--
Jens Axel S�gaard
In article <·························@dspool01.news.tele.dk>,
Jens Axel S�gaard <······@soegaard.net> wrote:
>Immanuel Litzroth wrote:
>>>>>>> "Alain" == Alain Picard <apicard+die-spammer-
>>>>>>> ···@optushome.com.au> writes:
>>
>> Alain> ········@visi.com (Richard Steiner) writes:
>> >> Of course not. Its chief weapon is surprise. :-)
>>
>> Alain> And fear! Fear, and surprise. :-)
>>
>> Their two main weapons are fear and suprise and ruthless
>> efficiency. :-)
>
>Their three weapons are fear, surprise, and ruthless efficiency
>and an almost fanatical devotion to the Pope.
Don't forget the nice red uniforms.
"Jens Axel S�gaard" <······@soegaard.net> writes:
> Their three weapons are fear, surprise, and ruthless efficiency
> and an almost fanatical devotion to the Pope.
and nice red uniforms!
--
(espen)
On Wed, 18 Sep 2002, Espen Vestre wrote:
>"Jens Axel S�gaard" <······@soegaard.net> writes:
>
>> Their three weapons are fear, surprise, and ruthless efficiency
>> and an almost fanatical devotion to the Pope.
>
>and nice red uniforms!
Damn! I can't say it! You'll have to say it!
--
Jeff "japhy" Pinyan RPI Acacia Brother #734 2002 Acacia Senior Dean
"And I vos head of Gestapo for ten | Michael Palin (as Heinrich Bimmler)
years. Ah! Five years! Nein! No! | in: The North Minehead Bye-Election
Oh. Was NOT head of Gestapo AT ALL!" | (Monty Python's Flying Circus)
* Michael Sullivan
| Yes it is. It's neither Turing complete, nor general purpose, nor very well
| designed, but it's definitely a programming language.
* Tim Bradshaw
| I think you are pushing it rather hard to count something with no
| conditional, variable binding, iteration or recursion constructs as a
| programming language.
There appears to be a serious failure to understand the difference between
languages that general programs accept as input and languages that
compilers, interpreterrs, and other language processors accept as input.
Just because it is interpreted and produces some response in the interpreter
does not make it a programming language. From a Lisp perspective, the irony
in the failure to distinguish code from data is particularly enjoyable.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
> * Michael Sullivan
> | Yes it is. It's neither Turing complete, nor general purpose, nor very well
> | designed, but it's definitely a programming language.
>
> * Tim Bradshaw
> | I think you are pushing it rather hard to count something with no
> | conditional, variable binding, iteration or recursion constructs as a
> | programming language.
>
> There appears to be a serious failure to understand the difference between
> languages that general programs accept as input and languages that
> compilers, interpreterrs, and other language processors accept as input.
> Just because it is interpreted and produces some response in the interpreter
> does not make it a programming language. From a Lisp perspective, the irony
> in the failure to distinguish code from data is particularly enjoyable.
>
(Matt puts on his devils advocate costume with flame retardant underpants
and enters the fray)
A definition I found stated that a programming language is "a vocublary and
set of grammatical rules for instructing a computer to perform specific
tasks" (http://www.webopedia.com/TERM/P/programming_language.html). A
definition for an interpreter is "a program that executes instructions
written in a high-level language"
(http://www.webopedia.com/TERM/I/interpreter.html). Both of these suggest
that HTML is a programming language: it has a syntax, grammatical rules, and
an interpreter.
(Matt removes the stupid costume)
HTML is not a programming language. In fact, it's name tells you that:
Hyper-Text Markup Language. So it's a markup language, nothing more,
nothing less. The failure is not really to with knowing the difference,
it's all these damn acronyms and peoples inability to remember what they
stand for.
Having said that though, I do sometimes wonder if the line between languages
has not become a little blurred.
Matt (who now wonders if removing the underpants was a good idea)
p.s. To the original post about what makes a better programmer:
- Design Patterns
(http://www.amazon.co.uk/exec/obidos/ASIN/0201633612/ref=sr_aps_books_1_1/026-7069228-8312426)
- Extreme Programming
(http://www.amazon.co.uk/exec/obidos/ASIN/0201616416/ref=pd_sim_b_dp/026-7069228-8312426)
- High caffeine tolerance
On Mon, 16 Sep 2002 18:57:50 +0100, Matthew Denner
<····@noreply.denner.demon.co.uk> wrote:
>HTML is not a programming language. In fact, it's name tells you that:
>Hyper-Text Markup Language. So it's a markup language, nothing more,
>nothing less. The failure is not really to with knowing the difference,
>it's all these damn acronyms and peoples inability to remember what they
>stand for.
While I agree that HTMl is not a programming I language, I would
poiint to TeX. TeX is a markup language, which if not a programming
language, comes as close to a programming language as you can.
Thaddeus L Olczyk wrote:
> On Mon, 16 Sep 2002 18:57:50 +0100, Matthew Denner
> <····@noreply.denner.demon.co.uk> wrote:
>
>
>>HTML is not a programming language. In fact, it's name tells you that:
>>Hyper-Text Markup Language. So it's a markup language, nothing more,
>>nothing less. The failure is not really to with knowing the difference,
>>it's all these damn acronyms and peoples inability to remember what they
>>stand for.
>>
>
> While I agree that HTMl is not a programming I language, I would
> poiint to TeX. TeX is a markup language, which if not a programming
> language, comes as close to a programming language as you can.
>
TeX is in fact Turing complete.
--
Thomas Stegen
On Sep 16, Thaddeus L Olczyk inscribed on the eternal scroll:
> While I agree that HTMl is not a programming I language, I would
> poiint to TeX.
I was thinking of pointing to TeX to help demonstrate that HTML is
not a programming language.
> TeX is a markup language, which if not a programming
> language, comes as close to a programming language as you can.
But is a completely different solution to a completely different
problem.
I say again, HTML (now thankfully minus the excresences which the Big
Two foisted on it) is essentially _descriptive_ of the marked-up
content. Presentation suggestions come from the client software or
from accompanying stylesheets (which are not written in HTML).
TeX is a typesetting language, in the raw. (So is Postscript, by the
way, albeit used somewhat differently). There really is no comparison
with HTML, even if (for a wasted 2-3 years) a couple of powerful
players tried to convince us that HTML needed to be a typesetting/DTP
language. Well, history has proved something about that.
Thaddeus L Olczyk wrote:
>
> On Mon, 16 Sep 2002 18:57:50 +0100, Matthew Denner
> <····@noreply.denner.demon.co.uk> wrote:
>
> >HTML is not a programming language. In fact, it's name tells you that:
> >Hyper-Text Markup Language. So it's a markup language, nothing more,
> >nothing less. The failure is not really to with knowing the difference,
> >it's all these damn acronyms and peoples inability to remember what they
> >stand for.
>
> While I agree that HTMl is not a programming I language, I would
> poiint to TeX. TeX is a markup language, which if not a programming
> language, comes as close to a programming language as you can.
XSLT. Turing complete, but if you didn't know what you were looking for,
you could mistake it for HTML[1]
MP
[1] OK, if you weren't a programmer. But you know what I mean...
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3lm61vuo5.fsf@cley.com>
* mpjunk wrote:
> XSLT. Turing complete, but if you didn't know what you were looking for,
> you could mistake it for HTML[1]
Heh. Or the other way around:
(html
(head
(title "foo"))
(body
(h1 "foo")
(p "text")))
Just HTML, but if you didn't know what you were looking for, you could
mistake it for Lisp.
--tim
* Matthew Denner
| HTML is not a programming language. In fact, it's name tells you that:
| Hyper-Text Markup Language. So it's a markup language, nothing more,
| nothing less. The failure is not really to with knowing the difference,
| it's all these damn acronyms and peoples inability to remember what they
| stand for.
HTML is based in SGML, which is only a syntax. It has no semantics at all.
If you wanted to, you could implement a programming language with the syntax
of SGML (or XML). Some people who believe even harder in living forever
than I do so they do not have to prioritize anything in their lives, have
actually done this. HTML has chosen not to do one crucial thing for a
programming language: define user abstractions (like functions, macros).
Even XML alone falls short here, but a given XML application can of course
invent ways to define new elements and perhaps even what to do with them.
| Having said that though, I do sometimes wonder if the line between languages
| has not become a little blurred.
It has always been blurred, but all that means is that there exist languages
that are hard to categorize because they are viewed from several vantage
points, not that the categories overlap or are ill-defined concepts.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Friedrich Dominicus
Subject: Re: becoming a better programmer
Date:
Message-ID: <8765x55186.fsf@fbigm.here>
·······@bcect.com (Michael Sullivan) writes:
> Peter Ward <··@ha.ha> wrote:
>
> > Newbie wrote:
> >
> > >
> > >
> > >"Scott" <·············@yahoo.com> wrote in message
> > >> So, one of my friends tells me that I should learn C++, because "it's the
> > >best".
> > >
> > >The guy must be joking. HTML is the king. Learn it first.
>
> > I hope you are joking. HTML is not a programming language.
>
> Yes it is. It's neither Turing complete, nor general purpose, nor very
> well designed, but it's definitely a programming language.
Well counterexample write a loop in HTML.
HTML is *definitly* not a programming langauge.
Friedrich
In article <··············@fbigm.here>, Friedrich Dominicus
<·····@q-software-solutions.com> wrote:
> ·······@bcect.com (Michael Sullivan) writes:
>
> > Peter Ward <··@ha.ha> wrote:
> >
> > > Newbie wrote:
> > >
> > > >
> > > >
> > > >"Scott" <·············@yahoo.com> wrote in message
> > > >> So, one of my friends tells me that I should learn C++, because
"it's the
> > > >best".
> > > >
> > > >The guy must be joking. HTML is the king. Learn it first.
> >
> > > I hope you are joking. HTML is not a programming language.
> >
> > Yes it is. It's neither Turing complete, nor general purpose, nor very
> > well designed, but it's definitely a programming language.
> Well counterexample write a loop in HTML.
>
> HTML is *definitly* not a programming langauge.
Just a data point to inform the discussion:
Unmanned spacecraft are controlled using "command sequencing languages"
that do not have loops. This is intentional in order to prevent the
language from being Turing-complete and thus subject to the halting
problem, so that sequences can be statically analyzed for correctness
before being sent to the spacecraft. It is arguable whether these really
are "programming languages", but if you choose to view a sequencing
language as a programming language then you can't consistently view HTML
as not-a-programming-language simply because it contains no looping
constructs.
FYI, FWIW,
E.
In article <····················@k-137-79-50-101.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) wrote:
>In article <··············@fbigm.here>, Friedrich Dominicus
><·····@q-software-solutions.com> wrote:
>
>> ·······@bcect.com (Michael Sullivan) writes:
>>
>> > Peter Ward <··@ha.ha> wrote:
>> >
>> > > Newbie wrote:
>> > >
>> > > >
>> > > >
>> > > >"Scott" <·············@yahoo.com> wrote in message
>> > > >> So, one of my friends tells me that I should learn C++, because
>"it's the
>> > > >best".
>> > > >
>> > > >The guy must be joking. HTML is the king. Learn it first.
>> >
>> > > I hope you are joking. HTML is not a programming language.
>> >
>> > Yes it is. It's neither Turing complete, nor general purpose, nor very
>> > well designed, but it's definitely a programming language.
>> Well counterexample write a loop in HTML.
>>
>> HTML is *definitly* not a programming langauge.
>
>Just a data point to inform the discussion:
>
>Unmanned spacecraft are controlled using "command sequencing languages"
>that do not have loops. This is intentional in order to prevent the
>language from being Turing-complete and thus subject to the halting
>problem, so that sequences can be statically analyzed for correctness
>before being sent to the spacecraft. It is arguable whether these really
>are "programming languages", but if you choose to view a sequencing
>language as a programming language then you can't consistently view HTML
>as not-a-programming-language simply because it contains no looping
>constructs.
What HTML hasn't really got is explicit conditionals -- REFRESH makes a
perfectly good looping construct (or a recursion construct if you
prefer). Oh, yeah, and any way of calculating things explicitly, and no
useful state (which might make it a functional language if it were a
programming language). But part of what's going on here is that we don't
think of displaying web pages as *doing* something that's in the purview
of a programming language. The "languages" for programming calculators,
for example, follow the same kind of "do a bunch of things when the user
presses a key" paradigm as does html, but because what's being done
clearly constitutes calculation, many people are more willing to think
of that as "programming".
paul
Even the simplest programming languages have some version of
conditional execution
In comp.lang.lisp Friedrich Dominicus <·····@q-software-solutions.com> wrote:
: ·······@bcect.com (Michael Sullivan) writes:
:> Peter Ward <··@ha.ha> wrote:
:>
:> > Newbie wrote:
:> >
:> > >
:> > >
:> > >"Scott" <·············@yahoo.com> wrote in message
:> > >> So, one of my friends tells me that I should learn C++, because "it's the
:> > >best".
:> > >
:> > >The guy must be joking. HTML is the king. Learn it first.
:>
:> > I hope you are joking. HTML is not a programming language.
:>
:> Yes it is. It's neither Turing complete, nor general purpose, nor very
:> well designed, but it's definitely a programming language.
: Well counterexample write a loop in HTML.
I said I'd never post here again. But I guess I'm just stupid.
Here is a loop in HTML:
In a file called "loop.html".
------------------
<a href="./loop.html">This is a loop.</a>
------------------
Click on the link to go to the next "iteration".
I didn't say it was a *good* example of a loop.
--
-pete
E-mail address corrupted to stop spam.
Reply mail: psilord at cs dot wisc dot edu
I am responsible for what I say, noone else.
On Sep 16, Michael Sullivan inscribed on the eternal scroll:
> Peter Ward <··@ha.ha> wrote:
>
> > I hope you are joking. HTML is not a programming language.
Quite.
> Yes it is.
Not in any of the senses I've ever heard the term used, since I first
met a computer in around 1958.
> It's neither Turing complete, nor general purpose,
It's a markup language, for heaven's sake. It's a data format.
> nor very well designed,
That's irrelevant to the issue.
> but it's definitely a programming language.
You can call it a caterpillar, if you want, but that doesn't make it
so.
In article <······························@bcect.com>,
·······@bcect.com (Michael Sullivan) wrote:
> Peter Ward <··@ha.ha> wrote:
>
> > Newbie wrote:
> >
> > >
> > >
> > >"Scott" <·············@yahoo.com> wrote in message
> > >> So, one of my friends tells me that I should learn C++, because "it's the
> > >best".
> > >
> > >The guy must be joking. HTML is the king. Learn it first.
>
> > I hope you are joking. HTML is not a programming language.
>
> Yes it is. It's neither Turing complete, nor general purpose, nor very
> well designed, but it's definitely a programming language.
Interesting. I hadn't realized that.
Can you show me how to translate the following into HTML?
10 input "What is you name? ", n$
20 print "Hello ", n$, ", how are you?"
Thanks.
-- Bruce
Bruce Hoult <·····@hoult.org> scribbled the following
on comp.lang.java.programmer:
> Can you show me how to translate the following into HTML?
> 10 input "What is you name? ", n$
> 20 print "Hello ", n$, ", how are you?"
> Thanks.
<html>
<body>
<form target="/greet.cgi" action="greet">
What is your name? <input type="text" name="n">
<input type="submit" value="Submit">
</form>
</body>
</html>
Erm, how do I translate line 20 then?
OK, just joking. Of course I realise HTML is not a programming
language. Doesn't everyone?
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Normal is what everyone else is, and you're not."
- Dr. Tolian Soran
Scott wrote:
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
Good choice for a start. Maybe in time it'll even grow on you...
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which.
Being a programmer isn't about learning new languages. It's about
learning the ideas in computer science. I remember when one of my profs
said, "Have you ever missed having closures (aka lambda) in C? Of course
not, because when you code in C, you start thinking in C, and C has no
concept of closures, so how can you want something that you cannot
imagine?" So don't seek to learn languages - seek to learn ideas.
Languages just happen to be a suitable medium for doing so, but don't
get stuck on any one type of language either.
If you're completely stuck, just learn _something_. In the worst case,
you'll hate it and learn something different, and even that may not
necessarily be a bad thing.
> So, one of my friends tells me that I should learn C++, because "it's
> the best".
Languages are just tools. C++ is good for some tasks. Other languages
are better suited for others. Learn several, then learn to chose the
best one for the job.
Ilya
Scott graced us by uttering:
> So, one of my friends tells me that I should learn C++, because
> "it's the best". But, seriously, he doesn't know anything but
> C++, so I'm not too sure if he is qualified to give this type
> of advice...
A good point. As the (obscure) music
artist Steve Taylor once sang:
So they love Jerry Lewis in France...
Does that make him funny?
> Another friend tells me "define what you mean by 'better
> programmer'". So, that guy wasn't too helpful either.
Looks like he was thinking like a programmer.
To be a truly good programmer, you'll have to define what you
want down to the most seemingly insignificant details, since
computers have less than intuition than Alicia Silverstone.
(She's cute, but oh so dumb.)
> So I thought about this A LOT, and I'm wonderingif I could ask
> for advice on the internet.
HTH
Tim Hammerquist
--
If Microsoft built cars, the oil, gas, and alternator warning lights would
be replaced by a single "general car fault" warning light.
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
> not too sure if he is qualified to give this type of advice...
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either. So I thought about this A LOT,
> and I'm wonderingif I could ask for advice on the internet.
>
Read this book:
Code Complete
http://www.construx.com/stevemcc/cc.htm
On Sun, 15 Sep 2002 06:26:40 GMT, "Anony" <··········@notahost.org>
wrote:
>
>> So, one of my friends tells me that I should learn C++, because "it's
>> the best". But, seriously, he doesn't know anything but C++, so I'm
>> not too sure if he is qualified to give this type of advice...
>> Another friend tells me "define what you mean by 'better programmer'".
>> So, that guy wasn't too helpful either. So I thought about this A LOT,
>> and I'm wonderingif I could ask for advice on the internet.
>>
>
>Read this book:
>
>Code Complete
>http://www.construx.com/stevemcc/cc.htm
>
>
>
Excellent advice! Non-language-specific, clear, funny... My all time
favorite!
On Sun, 15 Sep 2002 02:44:54 -0400, chuck starchaser
<················@email.com> wrote:
>On Sun, 15 Sep 2002 06:26:40 GMT, "Anony" <··········@notahost.org>
>wrote:
>
>>
>>> So, one of my friends tells me that I should learn C++, because "it's
>>> the best". But, seriously, he doesn't know anything but C++, so I'm
>>> not too sure if he is qualified to give this type of advice...
>>> Another friend tells me "define what you mean by 'better programmer'".
>>> So, that guy wasn't too helpful either. So I thought about this A LOT,
>>> and I'm wonderingif I could ask for advice on the internet.
>>>
>>
>>Read this book:
>>
>>Code Complete
>>http://www.construx.com/stevemcc/cc.htm
>>
>>
>>
>
>Excellent advice! Non-language-specific, clear, funny... My all time
>favorite!
>
If you like to get advice on prgramming from a person who wrote for
a company that has a reputation of producing shody products, and
libraries that are poorly structured.
Thaddeus L Olczyk wrote ...
> >Excellent advice! Non-language-specific, clear, funny... My all time
> >favorite!
> >
> If you like to get advice on prgramming from a person who wrote for
> a company that has a reputation of producing shody products, and
> libraries that are poorly structured.
So? It's a good book. It gives good advice. Who cares whether the
author's employer follows that advice?
Chris Smith
"Thaddeus L Olczyk" wrote
>
> >> Code Complete
> >> http://www.construx.com/stevemcc/cc.htm
>
> If you like to get advice on prgramming from a person who wrote for
> a company that has a reputation of producing shody products, and
> libraries that are poorly structured.
Thaddeus, have you actually read the book "Code Complete" ?
If you have read the book, please tell us why you think the book
is not useful.
i did not like it either. nothing interesting. threw it in the garbage.
if only i could learn to look at books more closely before buying them.
the microsoft heritage showed, too.
fwiw
Anony wrote:
> "Thaddeus L Olczyk" wrote
>
>>>>Code Complete
>>>>http://www.construx.com/stevemcc/cc.htm
>>>
>>If you like to get advice on prgramming from a person who wrote for
>>a company that has a reputation of producing shody products, and
>>libraries that are poorly structured.
>
>
> Thaddeus, have you actually read the book "Code Complete" ?
>
> If you have read the book, please tell us why you think the book
> is not useful.
>
>
>
>
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> i did not like it either. nothing interesting. threw it in the garbage.
> if only i could learn to look at books more closely before buying them.
> the microsoft heritage showed, too.
As somebody else asked, what exactly was wrong with _Code Complete_?
grelbr
grelbr wrote:
>
> As somebody else asked, what exactly was wrong with _Code Complete_?
> grelbr
Nothing new inside. But come to think of it, maybe there was something
in there for a newbie, which was the question. I just meant it was all
old news to this old hacker.
kenny
clinisys
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d876bd5@news.tce.com>
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····················@nyc.rr.com...
> grelbr wrote:
> >
> > As somebody else asked, what exactly was wrong with _Code Complete_?
> > grelbr
>
> Nothing new inside. But come to think of it, maybe there was something
> in there for a newbie, which was the question. I just meant it was all
> old news to this old hacker.
I would agree that there is nothing "new". It has all been discussed before.
The problem is that little of it is followed or known to your average
programmer. Much of what is in there will probably be new to the reader.
I've been programming over twenty years and I just last week was looking
over Code Complete again and learned new things (in particular the quote
from Dijkstra's "The Humble Programmer", which said that most of programming
is an attempt to compensate for the strictly limited size of our skulls).
There are also many myths of programming that many take as rules. Code
Complete dispels many of those myths.
On the subject of learning to be a better programmer, I am currently reading
an interesting book, "Software Craftsmanship: The New Imperative" by Pete
McBreen. It argues against the software engineering methodology and suggests
that programming is really a craft much like being a blacksmith. He
advocates a craftsman style system for programmers including apprenticeship
as a means of learning it.
--
Dale King
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3lm60v4qz.fsf@cley.com>
* Dale King wrote:
> On the subject of learning to be a better programmer, I am currently reading
> an interesting book, "Software Craftsmanship: The New Imperative" by Pete
> McBreen. It argues against the software engineering methodology and suggests
> that programming is really a craft much like being a blacksmith. He
> advocates a craftsman style system for programmers including apprenticeship
> as a means of learning it.
Poo. I could have written a book arguing this when I realised it 13
years ago and got famous.
--tim
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> * Dale King wrote:
>
> > On the subject of learning to be a better programmer, I am currently reading
> > an interesting book, "Software Craftsmanship: The New Imperative" by Pete
> > McBreen. It argues against the software engineering methodology and suggests
> > that programming is really a craft much like being a blacksmith. He
> > advocates a craftsman style system for programmers including apprenticeship
> > as a means of learning it.
>
> Poo. I could have written a book arguing this when I realised it 13
> years ago and got famous.
>
> --tim
So why didn't you?
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey38z20urz9.fsf@cley.com>
* Ryan Breidenbach wrote:
> So why didn't you?
Well, why didn't the thousands of other people who knew this? It's
still annoying.
--tim
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * Ryan Breidenbach wrote:
>
> > So why didn't you?
>
> Well, why didn't the thousands of other people who knew this? It's
> still annoying.
So, in other words, if good practices in a given field are already known to
many of the experienced practitioners in the field, nobody should bother
writing a book describing them for the benefit of those newcomers who don't
already know them? Books should only be written about revolutionary new
ideas that no one ever thought of before?
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3u1knif4m.fsf@cley.com>
* Harlan Messinger wrote:
> So, in other words, if good practices in a given field are already known to
> many of the experienced practitioners in the field, nobody should bother
> writing a book describing them for the benefit of those newcomers who don't
> already know them? Books should only be written about revolutionary new
> ideas that no one ever thought of before?
Did I say that? What I actually meant was that it was annoying not to
have written such a book, not that it was annoying that such a book
had been written. I thought that was fairly clear, but evidently not,
sigh.
--tim
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * Harlan Messinger wrote:
>
> > So, in other words, if good practices in a given field are already known
to
> > many of the experienced practitioners in the field, nobody should bother
> > writing a book describing them for the benefit of those newcomers who
don't
> > already know them? Books should only be written about revolutionary new
> > ideas that no one ever thought of before?
>
> Did I say that? What I actually meant was that it was annoying not to
> have written such a book, not that it was annoying that such a book
> had been written. I thought that was fairly clear, but evidently not,
> sigh.
Oops. Sorry!
Thaddeus L Olczyk wrote:
>
> On Sun, 15 Sep 2002 02:44:54 -0400, chuck starchaser
> <················@email.com> wrote:
> >>Code Complete
> >>http://www.construx.com/stevemcc/cc.htm
> If you like to get advice on prgramming from a person who wrote for
> a company that has a reputation of producing shody products, and
> libraries that are poorly structured.
Another good related book is "Rapid Development". These books are in part
about getting a defined level of quality. Depending on the circumstances, a
poor level of quality may be what the company wants.
MSFT has a sophisticated system for monitoring the level of quality of systems
as they move through the development cycle. When the level of quality is
optimal for the company, they release. This does not mean the optimal level
for the customer though.
Time to market and competitive issues often take precedence over quality.
In a similar vein, ease of use take precedence over security, thus the many
Microsoft related viruses and security failures.
In summary, these are good books and you can use them to produce quality
systems, whatever your definition of quality is.
Tim Josling
chuck starchaser <················@email.com> writes:
> On Sun, 15 Sep 2002 06:26:40 GMT, "Anony" <··········@notahost.org>
> wrote:
> >> So, one of my friends tells me that I should learn C++, because "it's
> >> the best". But, seriously, he doesn't know anything but C++, so I'm
> >> not too sure if he is qualified to give this type of advice...
> >> Another friend tells me "define what you mean by 'better programmer'".
> >> So, that guy wasn't too helpful either. So I thought about this A LOT,
> >> and I'm wonderingif I could ask for advice on the internet.
> >Read this book:
> >
> >Code Complete
> >http://www.construx.com/stevemcc/cc.htm
> Excellent advice! Non-language-specific, clear, funny... My all time
> favorite!
I like this book and I'm a fan of the author's other books but I
disagree that this one is 'non-language-specific' e.g. the author
himself notes that the "Concepts [are] applicable to any procedural
language".
As an alternative you could try "Paradigms of Artificial Intelligence
Programming: Case Studies in Common Lisp" by Peter Norvig
Mark
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d909d61@news.tce.com>
"Mark Dalgarno" <·············@scientia.com> wrote in message
··················@scientia.com...
> chuck starchaser <················@email.com> writes:
>
> > >Read this book:
> > >
> > >Code Complete
> > >http://www.construx.com/stevemcc/cc.htm
>
> > Excellent advice! Non-language-specific, clear, funny... My all time
> > favorite!
>
> I like this book and I'm a fan of the author's other books but I
> disagree that this one is 'non-language-specific' e.g. the author
> himself notes that the "Concepts [are] applicable to any procedural
> language".
By procedural here I don't think he means it in the sense of procedural vs.
OO. It is more of procedural vs. functional or logic. Some of the material
is not applicable to LISP or ProLog.
--
Dale King
Dale King <·····@tce.com> scribbled the following
on comp.lang.java.programmer:
> "Mark Dalgarno" <·············@scientia.com> wrote in message
> ··················@scientia.com...
>> I like this book and I'm a fan of the author's other books but I
>> disagree that this one is 'non-language-specific' e.g. the author
>> himself notes that the "Concepts [are] applicable to any procedural
>> language".
> By procedural here I don't think he means it in the sense of procedural vs.
> OO. It is more of procedural vs. functional or logic. Some of the material
> is not applicable to LISP or ProLog.
In this case he has chosen his terms poorly. Procedural is indeed the
opposite of OO. The opposite of functional is "imperative".
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"We're women. We've got double standards to live up to."
- Ally McBeal
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d92147b@news.tce.com>
"Joona I Palaste" <·······@cc.helsinki.fi> wrote in message
·················@oravannahka.helsinki.fi...
> Dale King <·····@tce.com> scribbled the following
> on comp.lang.java.programmer:
> > "Mark Dalgarno" <·············@scientia.com> wrote in message
> > ··················@scientia.com...
> >> I like this book and I'm a fan of the author's other books but I
> >> disagree that this one is 'non-language-specific' e.g. the author
> >> himself notes that the "Concepts [are] applicable to any procedural
> >> language".
>
> > By procedural here I don't think he means it in the sense of procedural
vs.
> > OO. It is more of procedural vs. functional or logic. Some of the
material
> > is not applicable to LISP or ProLog.
>
> In this case he has chosen his terms poorly. Procedural is indeed the
> opposite of OO. The opposite of functional is "imperative".
I agree that his wording is poor assuming that is what he actually said.
Mark didn't post a reference to the quote so we cannot see what he actually
said in context.
But avoiding the nit picking about words, "Code Complete" is just as
applicable to OO as it is procedural (in other words imperative). Much of
what is discussed is on a small scale of a routine or less. Whether that
routine is a C function or an instance method in Java doesn't make much
difference to what is discussed. He certainly doesn't limit himself to
non-OO as he talks about OO and gives an overview of it. But he also doesn't
limit himself to just OO.
--
Dale King
From: Friedrich Dominicus
Subject: Re: becoming a better programmer
Date:
Message-ID: <87hegd44hi.fsf@fbigm.here>
"Dale King" <·····@TCE.com> writes:
> But avoiding the nit picking about words, "Code Complete" is just as
> applicable to OO as it is procedural (in other words imperative).
This is the point. The book is really excellent for C like, Pascal
like and simular languages but it does not cover any functional
progamming things. This is a really flaw IMHO. Just a somewhat strange
example chapter 16 Unusual Control Structures, among those you'll find
Recursion! Than I suggest reading chapter 20.6 Ideal Programming
Environment, you might get a d�ja vu sometimes. Another things which
is to be mentioned. Nowhere in the book is a Lisp or any functional
language even mentioned. The whole book is more or less about one
thing, procedural programming and a third of the book is about memory
handling ....
Friedrich
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d932f5e@news.tce.com>
"Friedrich Dominicus" <·····@q-software-solutions.com> wrote in message
···················@fbigm.here...
> "Dale King" <·····@TCE.com> writes:
>
> > But avoiding the nit picking about words, "Code Complete" is just as
> > applicable to OO as it is procedural (in other words imperative).
>
> This is the point. The book is really excellent for C like, Pascal
> like and simular languages but it does not cover any functional
> progamming things. This is a really flaw IMHO. Just a somewhat strange
> example chapter 16 Unusual Control Structures, among those you'll find
> Recursion! Than I suggest reading chapter 20.6 Ideal Programming
> Environment, you might get a d�ja vu sometimes. Another things which
> is to be mentioned. Nowhere in the book is a Lisp or any functional
> language even mentioned. The whole book is more or less about one
> thing, procedural programming and a third of the book is about memory
> handling ....
I don't disagree. It is not very applicable to functional programming. The
assertion that was made here was that it did not apply to OO programming,
which is false.
--
Dale King
"Dale King" <·····@TCE.com> writes:
> "Friedrich Dominicus" <·····@q-software-solutions.com> wrote in message
> ···················@fbigm.here...
> > "Dale King" <·····@TCE.com> writes:
> >
> > > But avoiding the nit picking about words, "Code Complete" is just as
> > > applicable to OO as it is procedural (in other words imperative).
> >
> > This is the point. The book is really excellent for C like, Pascal
> > like and simular languages but it does not cover any functional
> > progamming things. This is a really flaw IMHO. Just a somewhat strange
> > example chapter 16 Unusual Control Structures, among those you'll find
> > Recursion! Than I suggest reading chapter 20.6 Ideal Programming
> > Environment, you might get a d�ja vu sometimes. Another things which
> > is to be mentioned. Nowhere in the book is a Lisp or any functional
> > language even mentioned. The whole book is more or less about one
> > thing, procedural programming and a third of the book is about memory
> > handling ....
>
> I don't disagree. It is not very applicable to functional programming. The
> assertion that was made here was that it did not apply to OO programming,
> which is false.
But OO =/= procedural/imperative programming! Take a look at a lot of
Smalltalk code, and it's very much impure-functional in the same way a
lot of Lisp code is. From this thread it sounds like this book would
have a lot less to say to someone who uses a GC'ed language that views
higher-order methods and recursion as normal things; I have a hard
time considering something OO without these features.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Dale King" <·····@TCE.com> writes:
> "Joona I Palaste" <·······@cc.helsinki.fi> wrote in message
> ·················@oravannahka.helsinki.fi...
> > Dale King <·····@tce.com> scribbled the following
> > on comp.lang.java.programmer:
> > > "Mark Dalgarno" <·············@scientia.com> wrote in message
> > > ··················@scientia.com...
> > >> I like this book and I'm a fan of the author's other books but I
> > >> disagree that this one is 'non-language-specific' e.g. the author
> > >> himself notes that the "Concepts [are] applicable to any procedural
> > >> language".
> >
> > > By procedural here I don't think he means it in the sense of procedural
> vs.
> > > OO. It is more of procedural vs. functional or logic. Some of the
> material
> > > is not applicable to LISP or ProLog.
> >
> > In this case he has chosen his terms poorly. Procedural is indeed the
> > opposite of OO. The opposite of functional is "imperative".
>
>
> I agree that his wording is poor assuming that is what he actually said.
> Mark didn't post a reference to the quote so we cannot see what he actually
> said in context.
Sorry, the text is on p xiii in the section "Key Benefits of This
Handbook":
"Concepts applicable to any procedural language. This book describes
techniques you can use to get the most out of whatever language you're
using, whether it's Pascal, C, C++, Ada, Basic, Fortran, COBOL, or
another procedural language."
Mark
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d932f96@news.tce.com>
"Mark Dalgarno" <·············@scientia.com> wrote in message
··················@scientia.com...
> "Dale King" <·····@TCE.com> writes:
>
> > "Joona I Palaste" <·······@cc.helsinki.fi> wrote in message
> > ·················@oravannahka.helsinki.fi...
> > > Dale King <·····@tce.com> scribbled the following
> > > on comp.lang.java.programmer:
> > > > "Mark Dalgarno" <·············@scientia.com> wrote in message
> > > > ··················@scientia.com...
> > > >> I like this book and I'm a fan of the author's other books but I
> > > >> disagree that this one is 'non-language-specific' e.g. the author
> > > >> himself notes that the "Concepts [are] applicable to any procedural
> > > >> language".
> > >
> > > > By procedural here I don't think he means it in the sense of
procedural
> > vs.
> > > > OO. It is more of procedural vs. functional or logic. Some of the
> > material
> > > > is not applicable to LISP or ProLog.
> > >
> > > In this case he has chosen his terms poorly. Procedural is indeed the
> > > opposite of OO. The opposite of functional is "imperative".
> >
> >
> > I agree that his wording is poor assuming that is what he actually said.
> > Mark didn't post a reference to the quote so we cannot see what he
actually
> > said in context.
>
> Sorry, the text is on p xiii in the section "Key Benefits of This
> Handbook":
>
> "Concepts applicable to any procedural language. This book describes
> techniques you can use to get the most out of whatever language you're
> using, whether it's Pascal, C, C++, Ada, Basic, Fortran, COBOL, or
> another procedural language."
Then what he should have said was imperative language. Java is not mentioned
as the book predates Java.
--
Dale King
"Joona I Palaste" <·······@cc.helsinki.fi> wrote in message ·················@oravannahka.helsinki.fi...
>
> In this case he has chosen his terms poorly. Procedural is indeed the
> opposite of OO. The opposite of functional is "imperative".
Uh, procedural certainly isn't the "opposite" of OO, although in some
(not all) uses of the word, it's used to contrast with OO. In the sense
of "procedural vs. declarative" then OO is just a kind of procedural
programming. Likewise in "procedural vs. functional."
Marshall
Marshall Spight <·······@dnai.com> scribbled the following
on comp.lang.java.programmer:
> "Joona I Palaste" <·······@cc.helsinki.fi> wrote in message ·················@oravannahka.helsinki.fi...
>> In this case he has chosen his terms poorly. Procedural is indeed the
>> opposite of OO. The opposite of functional is "imperative".
> Uh, procedural certainly isn't the "opposite" of OO, although in some
> (not all) uses of the word, it's used to contrast with OO. In the sense
> of "procedural vs. declarative" then OO is just a kind of procedural
> programming. Likewise in "procedural vs. functional."
I agree with you mostly, but are you sure OO is just a kind of
procedural programming? Why can't there be declarative OO?
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"This isn't right. This isn't even wrong."
- Wolfgang Pauli
[XP,F'up c.l.functional]
Hello!
Joona I Palaste <·······@cc.helsinki.fi> wrote:
>[...]
>I agree with you mostly, but are you sure OO is just a kind of
>procedural programming? Why can't there be declarative OO?
Ever tried out o'hugs or ocaml?
Kind regards,
Hannah.
In article <············@oravannahka.helsinki.fi>,
Joona I Palaste <·······@cc.helsinki.fi> wrote:
> Marshall Spight <·······@dnai.com> scribbled the following
> on comp.lang.java.programmer:
> > "Joona I Palaste" <·······@cc.helsinki.fi> wrote in message
> > ·················@oravannahka.helsinki.fi...
> >> In this case he has chosen his terms poorly. Procedural is indeed the
> >> opposite of OO. The opposite of functional is "imperative".
>
> > Uh, procedural certainly isn't the "opposite" of OO, although in some
> > (not all) uses of the word, it's used to contrast with OO. In the sense
> > of "procedural vs. declarative" then OO is just a kind of procedural
> > programming. Likewise in "procedural vs. functional."
>
> I agree with you mostly, but are you sure OO is just a kind of
> procedural programming? Why can't there be declarative OO?
There certainly can be, and I do it in Dylan sometimes. You can get
almost all the advantages of OO while never modifying an existing object
-- instead of modifying it you copy everything except what you want to
modify. This is probably most convenient in a language that has keyword
arguments, so you can do things such as "copy(emp, salary: 1000)".
The main hassle is that you have to be careful with collections.
Hierachical structures such as trees are probably best, to keep the
number of things that have to be copied when you modify something down
to O(log n).
This makes updates a bit more expensive than normal, but in exchange you
get a complete version history and "undo" for free.
-- Bruce
Joona I Palaste wrote:
> Dale King wrote:
> > Mark Dalgarno wrote:
> >> I like this book and I'm a fan of the author's other books but I
> >> disagree that this one is 'non-language-specific' e.g. the author
> >> himself notes that the "Concepts [are] applicable to any procedural
> >> language".
>
> > By procedural here I don't think he means it in the sense of procedural vs.
> > OO. It is more of procedural vs. functional or logic. Some of the material
> > is not applicable to LISP or ProLog.
>
> In this case he has chosen his terms poorly. Procedural is indeed the
> opposite of OO. The opposite of functional is "imperative".
>
> --
> /-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
> | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
> | http://www.helsinki.fi/~palaste W++ B OP+ |
> \----------------------------------------- Finland rules! ------------/
> "We're women. We've got double standards to live up to."
> - Ally McBeal
--
Announcement in the Zoo:
"Please don't scare the ostriches! Cement floor!"
Dale King wrote:
> Mark Dalgarno wrote:
> > chuck starchaser wrote:
> >
> > > >Read this book:
> > > >
> > > >Code Complete
> > > >http://www.construx.com/stevemcc/cc.htm
> >
> > > Excellent advice! Non-language-specific, clear, funny... My all time
> > > favorite!
> >
> > I like this book and I'm a fan of the author's other books but I
> > disagree that this one is 'non-language-specific' e.g. the author
> > himself notes that the "Concepts [are] applicable to any procedural
> > language".
>
> By procedural here I don't think he means it in the sense of procedural vs.
> OO. It is more of procedural vs. functional or logic. Some of the material
> is not applicable to LISP or ProLog.
>
> --
> Dale King
--
Announcement in the Zoo:
"Please don't scare the ostriches! Cement floor!"
In article <·····················@sccrnsc02>, Anony wrote:
>
>> So, one of my friends tells me that I should learn C++, because "it's
>> the best". But, seriously, he doesn't know anything but C++, so I'm
>> not too sure if he is qualified to give this type of advice...
>> Another friend tells me "define what you mean by 'better programmer'".
>> So, that guy wasn't too helpful either. So I thought about this A LOT,
>> and I'm wonderingif I could ask for advice on the internet.
>>
>
> Read this book:
>
> Code Complete
> http://www.construx.com/stevemcc/cc.htm
>
Well my $0.02 is that to be a better programmer you need to get the
tools you need to program better in your toolbox(aka brain). The 2
big tools are:
1: the ability to manage complexity and keep track of the details that
you can not manage out of existance.
2: the ability to analize a problem and translate the solution to
something that a very stupid device(computer) can execute correctly.
To do this you need much more then knoledge of a given language. If
you look at CS education you do not get taught how to code, you are
expected to figure it out on your own. The hard stuff is what they
cover in class.
Here is an online book you might want to look at:
http://www.htdp.org/
and you can get the enviorment for the book at:
http://www.drscheme.org/
When you are starting out you should not spend a lot of time learning
a language but learning the tools that you need to implement your
solution in what ever language you are using.
good luck
marc
"Anony" <··········@notahost.org> wrote in message news:<·····················@sccrnsc02>...
> > So, one of my friends tells me that I should learn C++, because "it's
> > the best". But, seriously, he doesn't know anything but C++, so I'm
> > not too sure if he is qualified to give this type of advice...
> > Another friend tells me "define what you mean by 'better programmer'".
> > So, that guy wasn't too helpful either. So I thought about this A LOT,
> > and I'm wonderingif I could ask for advice on the internet.
> >
>
> Read this book:
>
> Code Complete
> http://www.construx.com/stevemcc/cc.htm
Thank you very much for your suggestion!
Do you think it is better to learn several languages at the same time
or to be more selective?
I would certainly like to know more languages rather than fewer, but I
thought that learning a new language is always a considerable effort.
Is it true that some languages are good for learning, while others
are better for real-wolrd programming?
If a certain language expresses programming paradigms better than
others, wouldn't it be a better choice for both learning and
real-world programming? If it is the case that , for example LISP is
better for learning, while C++ is better for real programming, would
the extra effor of learning C++ be justified if I do start with LISP?
On the other hand, would LISP's superiority for learning programming
be significant enough?
Thanks very much!
>real-world programming? If it is the case that , for example LISP is
>better for learning, while C++ is better for real programming, would
>the extra effor of learning C++ be justified if I do start with LISP?
>On the other hand, would LISP's superiority for learning programming
>be significant enough?
Lisp is powerful but uses too many parenthesis.. ;-) ) ) ) )
No, seriously. There's 2 big distinctions in languages:
Between Interpretive and Compiled
and
Between Procedural and Declarative.
The first distinction relates to the difference between, for example,
Basic and C. In Basic, you type the program, then you RUN it,
immediately. So it's quick for testing code, but the code runs slowly.
If you want to program a First Person Shooter game in 3D, you would
not use Basic, or Lisp. You'd want to use a compiled language that
produces optimized, small and fast executables. But if you want to
program interesting experiments in Artificial Intelligence, then,
definitely, Lisp is the way to go. Actually, what I'm saying is not
exactly accurate, since, nowadays, a lot of interpretive languages
have compilers available for them. But you'll always get best
performance from languages which are natively compiled.
Again, C++ is not the fastest language around, if you were to need
highest performance, C and FORTRAN beat C++ to a pulp; but at a huge
loss of power and expressiveness, by comparison.
The Procedural versus Declarative distinction is more or less like
this: In procedural languages like C, C++, FORTRAN, Eiffel, Basic,
etceteras, a = b means assign the value of b to variable a.
In a Declarative language, like Prolog, and to some extent in so
called 'functional' languages, a = b might simply be a statement of
truth, just so the program knows it. In a declarative language, you
typically inform the program about a lot of things relating to the
problem you're trying to solve, and, eventually, the program will know
enough to solve your problem (perhaps when you might have already
forgotten what the problem was.. :-)
So, take your pick.
At the beginning you might be fascinated by fancy features in
languages. Eventually, most of us end up marrying the language with
the least number of feature *** ommissions ***.
A few years ago I fell in love with Eiffel, (a procedural, compiled,
object-oriented to the core language). I still miss the clarity of its
keywords:
once
deferred
implies
is
precondition
postcondition
variant
invariant
real
integer
But it has no "unsigned char", which means that if I want to create a
type to express an RGBA color, it would take a whopping 16 bytes.
And it has no function overloading, meaning that initializers that
take different kinds of arguments, must all be named differently, for
example; and would not support the "visitor" pattern.
And it has no template specialization, which is a deadly crime.
And it has automatic garbage collection, which means that it has no
destructors, which means that many beautiful idioms that rely on the
constructor/destructor symmetry, cannot be implemented.
So, that's it for me.
C++ is neither the fastest language, nor the safest, nor the most
beautiful or expressive, nor the most powerful; but it has a half
decent amount of each of the above, which is, in itself, a feature no
other language can offer.
But then again, there's INTERCALC and QUANTUM INTERCALC; search for
them. That may be the way of the future... ;-)
In comp.lang.lisp, chuck starchaser <················@email.com> writes:
> No, seriously. There's 2 big distinctions in languages:
> Between Interpretive and Compiled
> and
> Between Procedural and Declarative.
That first distinction is by and large no longer a valid one. There are
very few interpreted languages left; even Perl and Python byte-compile
first and then execute bytecode.
> So it's quick for testing code, but the code runs slowly. If you want
> to program a First Person Shooter game in 3D, you would not use Basic,
> or Lisp. You'd want to use a compiled language that produces optimized,
> small and fast executables.
Lisp is a compiled language. Lisp can also be an interpreted language.
So can C. Commercial Lisp development is generally compiled, however,
just like you would compile C. The speed advantages are nowhere near this
clearcut.
> I'm saying is not exactly accurate, since, nowadays, a lot of
> interpretive languages have compilers available for them. But you'll
> always get best performance from languages which are natively compiled.
Once a compiler is available, there's really no useful distinction to be
made between "native" and not, only in how good the compiler is.
--
Russ Allbery (···@stanford.edu) <http://www.eyrie.org/~eagle/>
On Sun, 15 Sep 2002 19:39:02 -0400, chuck starchaser
<················@email.com> wrote:
>>real-world programming? If it is the case that , for example LISP is
>>better for learning, while C++ is better for real programming, would
>>the extra effor of learning C++ be justified if I do start with LISP?
>>On the other hand, would LISP's superiority for learning programming
>>be significant enough?
>
>
>Lisp is powerful but uses too many parenthesis.. ;-) ) ) ) )
Very true. Why don't they reintroduce Logo in primary schools?
A very nice language specially designed for learning, by
children, where you can draw some amazing graphics by
controlling a pen-equipped turtle.
To learn basic programming today, I'd recommend JavaScript!
Except that there's no easy way to produce graphics... Perhaps
the "dot" package could serve for that. I don't know.
>No, seriously. There's 2 big distinctions in languages:
>
>Between Interpretive and Compiled
>and
>Between Procedural and Declarative.
Another and perhaps more useful distinction:
General language.
Small, dedicated language.
>The first distinction relates to the difference between, for example,
>Basic and C. In Basic, you type the program, then you RUN it,
>immediately. So it's quick for testing code, but the code runs slowly.
Let me add to that. With interpretation some representation of the
program (could be the original text, could be a machine translated
form) is "run" by a program, the
interpreter,
instead of some representation of the program being run directly
by the machine.
This doesn't mean that an interpreted language cannot rely on
compilation (machine translation between different forms). We
call a language a compiled language when it's designed primarily
for compilation and not for direct interpretation.
The advantage of direct interpretation of program text is primarily
that it allows
Treating data as program code, and vice versa.
E.g., in Lisp and JavaScript you can let the program "eval" an
expression typed in by the user, as if it were part of the program.
Without this powerful but dangerous capability there's no real
difference.
>...
>A few years ago I fell in love with Eiffel, (a procedural, compiled,
>object-oriented to the core language). I still miss the clarity of its
>keywords:
>
>once
>deferred
>implies
>is
>precondition
>postcondition
>variant
>invariant
>real
>integer
>
>But it has no "unsigned char", which means that if I want to create a
>type to express an RGBA color, it would take a whopping 16 bytes.
>And it has no function overloading
I'm not sure you're right here, but I think you're simply using the
wrong name for the concept you're thinking of.
>meaning that initializers that
>take different kinds of arguments, must all be named differently, for
>example;
That's a feature. One quickly gets tired of inventing ways to
circumvent the corresponding limitation of C++. E.g., think of
creating a new complex number: you can supply x and y, or r and
angle; two equivalent ways that both involve two numbers, so
that some way to distinguish between them (other than argument
number/type) is required.
> and would not support the "visitor" pattern.
It does. The visitor pattern doesn't rely on anonymous
constructors.
Cheers,
- Alf
chuck starchaser <················@email.com> writes:
> No, seriously. There's 2 big distinctions in languages:
>
> Between Interpretive and Compiled
> and
> Between Procedural and Declarative.
Being Interpretive or Compiled is not a property of languages, but of
implementations. There are interpreters for C and native-code
compilers for (parts of) Python programs around. Objective Caml comes
with an interpreter, a bytecode compiler and a native-code compiler
out of the box.
> But then again, there's INTERCALC and QUANTUM INTERCALC; search for
> them. That may be the way of the future... ;-)
Scince someone mentioned Assembler as a way to learn how the basics of
a computer work, perhaps Brainf**k and Unlambda might be of interest,
to go down to the basics of computability... ;-)
Regards
Henrik
On 16 Sep 2002, Henrik Motakef wrote:
>Scince someone mentioned Assembler as a way to learn how the basics of
>a computer work, perhaps Brainf**k and Unlambda might be of interest,
>to go down to the basics of computability... ;-)
What about Befunge? ;)
Befunge teaches you stack-based programming, and the true horrors of
writing spaghetti code...
--
Jeff "japhy" Pinyan RPI Acacia Brother #734 2002 Acacia Senior Dean
"And I vos head of Gestapo for ten | Michael Palin (as Heinrich Bimmler)
years. Ah! Five years! Nein! No! | in: The North Minehead Bye-Election
Oh. Was NOT head of Gestapo AT ALL!" | (Monty Python's Flying Circus)
Jeff 'japhy' Pinyan <······@rpi.edu> writes:
> On 16 Sep 2002, Henrik Motakef wrote:
>
> >Scince someone mentioned Assembler as a way to learn how the basics of
> >a computer work, perhaps Brainf**k and Unlambda might be of interest,
> >to go down to the basics of computability... ;-)
>
> What about Befunge? ;)
>
> Befunge teaches you stack-based programming, and the true horrors of
> writing spaghetti code...
How about Spaghetti ?
http://99-bottles-of-beer.ls-la.net/s.html#Spaghetti
:-)
frank
--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frankDOTschmittAT4scDOTcom
·············@yahoo.com (Scott) writes:
> Is it true that some languages are good for learning, while
> others are better for real-wolrd programming?
it is true and false depending on the learner and how they relate
to the world. do you think these glyphs floating in front of your
face are "real"?
thi
From: Jon Bell
Subject: Re: becoming a better programmer
Date:
Message-ID: <H2HwEB.F0r@presby.edu>
In article <····························@posting.google.com>,
Scott <·············@yahoo.com> wrote:
>
>Do you think it is better to learn several languages at the same time
>or to be more selective?
Unless you're already really comfortable with programming in general, and
already know a couple of languages well, I sugggest you try to learn only
one language at a time. Less chance for confusion and linguistic
interference.
--
Jon Bell <·········@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
Scott wrote:
>
> Thank you very much for your suggestion!
>
> Do you think it is better to learn several languages at the same time
> or to be more selective?
You have to keep in mind that computer science is a relatively young
field, at least in comparison to other sciences. So there are still no
general rules that have come up as of yet. Mostly you have to figure out
for yourself what works and what doesn't work.
My guess is that it's better to concentrate on one language at a time,
but your mileage may vary.
> I would certainly like to know more languages rather than fewer, but I
> thought that learning a new language is always a considerable effort.
>
> Is it true that some languages are good for learning, while others
> are better for real-wolrd programming?
This depends on how you define "real world". ;)
> If a certain language expresses programming paradigms better than
> others, wouldn't it be a better choice for both learning and
> real-world programming? If it is the case that , for example LISP is
> better for learning, while C++ is better for real programming, would
> the extra effor of learning C++ be justified if I do start with LISP?
> On the other hand, would LISP's superiority for learning programming
> be significant enough?
Programming languages that are pure in the sense that they support a
single programming paradigm are interesting because they show you how
far you can go in a single direction. However, there are studies that
show that good programmers can easily switch in their minds between
different programming paradigms and that this the main reasons why they
are good. So in the long run it's probably better to choose a language
that supports different paradigms. However, such language have to make
some compromises and are therefore harder to learn. I think that "pure"
programming languages are somewhat easier to learn in the beginning.
Don't worry though. If you are willing to invest in learning several
languages/paradigms you will, at some stage, have a very easy time to
learn new ones. Don't let anyone tell you what _the_ best language or
_the_ best tool is - if you stay open-minded you will have developed
your own criteria and your own judgements, and that's the best thing
that can happen to you!
Pascal
In article <·····················@sccrnsc02>, ··········@notahost.org
says...
>
> > So, one of my friends tells me that I should learn C++, because "it's
> > the best". But, seriously, he doesn't know anything but C++, so I'm
> > not too sure if he is qualified to give this type of advice...
> > Another friend tells me "define what you mean by 'better programmer'".
> > So, that guy wasn't too helpful either. So I thought about this A LOT,
> > and I'm wonderingif I could ask for advice on the internet.
> >
>
> Read this book:
>
> Code Complete
> http://www.construx.com/stevemcc/cc.htm
I wouldn't recommend that book. It's typically geared towards procedural
programming and somewhat outdated.
If you want to be a better programmer, start coding and start looking
at other people's code.
I think Java is a very good choice for a language,
and I've worked with many a language, including Basic, assembly, Pascal,
C, C++, VHDL, AWK, Perl, Forth, Lisp, Haskell and others.
C++ is fine *IF* you can decide which language features to use, else
it's a nightmare, especially if you have to work with code from other
people who use all kind of different paradigms inside one code base.
(Ask your average C++ programmer to explain the use of the following
keywords: 'export' 'explicit' 'typename')
I mainly work with C because I have to -- it's simple (primitive), you
know where the pitfalls are, but not very powerful -- but I really
prefer Java.
It's clean, versatile and has excellent *standard* (very important)
libraries.
Paul
jvm wrote:
> > Code Complete
> > http://www.construx.com/stevemcc/cc.htm
>
> I wouldn't recommend that book. It's typically geared towards procedural
> programming and somewhat outdated.
I'd have to strongly disagree with you there.
The main thing I've found about it is that it has good solid information and
research running back from many decades ago. It's just as pertinent as say
'The Mythical Man-Month'.
Code reviews aren't just for procedural. Nor is knowing prerequisites,
modularity, design styles, variable naming, code layout, self-documenting
code, quality, types of testing, need for more than one type of testing,
etc...
There is a little there that is more procedural, but then that applies to
Java quite well, and so is not really outdated. But then the sources cited
are worth it alone. I don't know how many times I was able to push some
better practices into a company I was working at by pointing out the hard
numbers on testing efficiency (and that there was no real difference between
formal and informal code reviews).
Now, if you were talking about "Writing Solid Code" (which I purchased back
at the same time), then I'd say that your statements were spot-on in regards
to it.
--
Jon A. Cruz
What's this? It's almost as though the fates were tempting me to...
Bad fates. Baaad... Naughty fates...
From: Tramm Hudson
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <amfgmt$jq5$1@iruka.swcp.com>
Jon A. Cruz <·······@geocities.com> wrote:
> Now, if you were talking about "Writing Solid Code" (which I purchased back
> at the same time), then I'd say that your statements were spot-on in regards
> to it.
The subtitle for "Writing Solid Code" is:
Microsoft's Techniques for Developing Bug-Free C Programs
While the book is actually fairly good for procedural programming,
I'm really not sure what to make of the claim that Microsoft produces
bug free programs in any language.
Trammell
--
-----|----- ······@swcp.com H 240-476-1373
*>=====[]L\ ······@rotomotion.com W 240-453-3317
' -'-`- http://www.swcp.com/~hudson/ KC5RNF
From: Dale King
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3d8b84dd@news.tce.com>
"Tramm Hudson" <······@swcp.com> wrote in message
·················@iruka.swcp.com...
> Jon A. Cruz <·······@geocities.com> wrote:
> > Now, if you were talking about "Writing Solid Code" (which I purchased
back
> > at the same time), then I'd say that your statements were spot-on in
regards
> > to it.
I disagree. While "Writing Solid Code" is not in the same league as "Code
Complete", it's advice is certainly not out of date and is well worth
reading, although not a must have.
> The subtitle for "Writing Solid Code" is:
>
> Microsoft's Techniques for Developing Bug-Free C Programs
>
> While the book is actually fairly good for procedural programming,
> I'm really not sure what to make of the claim that Microsoft produces
> bug free programs in any language.
But the book is primarily a lot of examples of bad programming practices.
Micro$oft is certainly the foremost authority on bad programming.
--
Dale King
From: Jon A. Cruz
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3D8D70F4.5C671E88@joncruz.org>
Dale King wrote:
> I disagree. While "Writing Solid Code" is not in the same league as "Code
> Complete", it's advice is certainly not out of date and is well worth
> reading, although not a must have.
Actually....
When I read "Writing Solid Code" a 486 was a good developer machine, and
Windows 3.1 was still the only game in town. At that time, many of the
procedures in the book would not even work on a Windows box. IIRC, it had to
deal with the writing having been a mac developer, and not knowing the subtle
problems of 386 segment offsets, etc. And especially not with all the nice
fun MS Windows memory handles, etc.
Amusingly enough, years later when Windows 95 finally took over, some of the
recomended practices would work again under Win32.
The main difference struck me as "Code Complete" being a solid attempt to
craft a lasting textbook on the subject, while "Writing Solid Code" was a
collection of personal experience and musings. Sometimes the "I do this
'cause it works for me" hits good stuff, but sometimes it doesn't.
--
Jon A. Cruz
What's this? It's almost as though the fates were tempting me to...
Bad fates. Baaad... Naughty fates...
From: Dale King
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3d8f9830$5@news.tce.com>
"Jon A. Cruz" <···@joncruz.org> wrote in message
······················@joncruz.org...
> Dale King wrote:
>
> > I disagree. While "Writing Solid Code" is not in the same league as
"Code
> > Complete", it's advice is certainly not out of date and is well worth
> > reading, although not a must have.
>
> Actually....
>
> When I read "Writing Solid Code" a 486 was a good developer machine, and
> Windows 3.1 was still the only game in town. At that time, many of the
> procedures in the book would not even work on a Windows box. IIRC, it had
to
> deal with the writing having been a mac developer, and not knowing the
subtle
> problems of 386 segment offsets, etc. And especially not with all the nice
> fun MS Windows memory handles, etc.
>
> Amusingly enough, years later when Windows 95 finally took over, some of
the
> recomended practices would work again under Win32.
>
> The main difference struck me as "Code Complete" being a solid attempt to
> craft a lasting textbook on the subject, while "Writing Solid Code" was a
> collection of personal experience and musings. Sometimes the "I do this
> 'cause it works for me" hits good stuff, but sometimes it doesn't.
As I see it, most of the advice is still valid. As you may remember he sums
up each section with a brief tip statement. If you look at a list of those
tips you would agree that most apply.
Here are a few of these statements:
Always ask, "Can this variable or expression over- or underflow?"
Avoid risky language idioms.
Don't abuse your programming language.
Write code for the "average" programmer. (My favorite)
There are no free features.
The examples are all C based, so is not as applicable to Java. So while it
is not a must have book, like Code Complete, it certainly is not harmful to
read. There is good advice in there.
--
Dale King
jvm <···@fiberia.is.no.more> wrote in message news:<··························@pixs.htc.nl.philips.com>...
> [Java is] clean, versatile and has excellent *standard* (very important)
> libraries.
Clean? Let's see, adding two floating point number class objects, to produce a sum:
Java:
new Float(a.floatValue() + b.floatValue())
C++:
a + b; // given suitable Float class with operator +
Lisp:
(+ a b) ;; numbers are class objects
From: Joe Marshall
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <8z1w75g7.fsf@ccs.neu.edu>
···@ashi.footprints.net (Kaz Kylheku) writes:
> Clean? Let's see, adding two floating point number class objects, to produce a sum:
>
> Java:
>
> new Float(a.floatValue() + b.floatValue())
>
> C++:
>
> a + b; // given suitable Float class with operator +
>
> Lisp:
>
> (+ a b) ;; numbers are class objects
You let them off easy! Let's try something more complicated like
adding two polynomials.
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> jvm <···@fiberia.is.no.more> wrote in message news:<··························@pixs.htc.nl.philips.com>...
> > [Java is] clean, versatile and has excellent *standard* (very important)
> > libraries.
>
> Clean? Let's see, adding two floating point number class objects, to produce a sum:
>
> Java:
>
> new Float(a.floatValue() + b.floatValue())
>
> C++:
>
> a + b; // given suitable Float class with operator +
>
> Lisp:
>
> (+ a b) ;; numbers are class objects
First, can't you do this in Java:
a + b // a & b are primitive floats
Second...what's you point?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
···@ashi.footprints.net (Kaz Kylheku) wrote in
·································@posting.google.com:
> jvm <···@fiberia.is.no.more> wrote in message
> news:<··························@pixs.htc.nl.philips.com>...
>> [Java is] clean, versatile and has excellent *standard* (very
>> important) libraries.
>
> Clean? Let's see, adding two floating point number class objects, to
> produce a sum:
>
> Java:
>
> new Float(a.floatValue() + b.floatValue())
Yes, THANK YOU for pointing this out. I thought I was the only one who saw
that the emperor has no clothes.
I know C++, somewhat. I know Perl very very well. Every now and then I
start to think maybe I should learn Java. I fiddle around with it for a
day or so, or I read twenty pages of a book, and I immediately quit in
disgust and say "Why would I do all that?? It's SO much easier in C, C++,
or (especially) Perl!"
- --
Eric
print scalar reverse sort qw p ekca lre reh
ts uJ p, $/.r, map $_.$", qw e p h tona e;
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPYvPmWPeouIeTNHoEQIqrgCcDtLszNEP1Mh7kZ/oFkGM/O4bZ3MAn2Wn
Bip5JXFm6gv7rrUsyNcMsHuP
=6Mo+
-----END PGP SIGNATURE-----
"Eric J. Roode" <·············@comcast.net> writes:
> ···@ashi.footprints.net (Kaz Kylheku) wrote in
> ·································@posting.google.com:
>
> > jvm <···@fiberia.is.no.more> wrote in message
> > news:<··························@pixs.htc.nl.philips.com>...
> >> [Java is] clean, versatile and has excellent *standard* (very
> >> important) libraries.
> >
> > Clean? Let's see, adding two floating point number class objects, to
> > produce a sum:
> >
> > Java:
> >
> > new Float(a.floatValue() + b.floatValue())
>
> Yes, THANK YOU for pointing this out. I thought I was the only one who saw
> that the emperor has no clothes.
>
> I know C++, somewhat. I know Perl very very well. Every now and then I
> start to think maybe I should learn Java. I fiddle around with it for a
> day or so, or I read twenty pages of a book, and I immediately quit in
> disgust and say "Why would I do all that?? It's SO much easier in C, C++,
> or (especially) Perl!"
They are even easier in Common Lisp (and as fast as C/C++ as well).
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> jvm <···@fiberia.is.no.more> wrote in message news:<··························@pixs.htc.nl.philips.com>...
> > [Java is] clean, versatile and has excellent *standard* (very important)
> > libraries.
>
> Clean? Let's see, adding two floating point number class objects, to produce a sum:
>
> Java:
>
> new Float(a.floatValue() + b.floatValue())
>
> C++:
>
> a + b; // given suitable Float class with operator +
>
> Lisp:
>
> (+ a b) ;; numbers are class objects
Java:
a.plus(b) // given suitable MyFloat class with method "plus"
From: Kaz Kylheku
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <ami74b$rfm$1@luna.vcn.bc.ca>
In article <····························@posting.google.com>, Larry A Barowski
wrote:
> ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
>> jvm <···@fiberia.is.no.more> wrote in message news:<··························@pixs.htc.nl.philips.com>...
>> > [Java is] clean, versatile and has excellent *standard* (very important)
>> > libraries.
>>
>> Clean? Let's see, adding two floating point number class objects, to produce a sum:
>>
>> Java:
>>
>> new Float(a.floatValue() + b.floatValue())
>>
>> C++:
>>
>> a + b; // given suitable Float class with operator +
>>
>> Lisp:
>>
>> (+ a b) ;; numbers are class objects
>
> Java:
>
> a.plus(b) // given suitable MyFloat class with method "plus"
So why is there a Float class in this clean language, if you have to write
MyFloat? Why can't you just add the method to the Float class?
What if N programmers on the same project write their own variant of MyFloat?
N x N conversions, here we go.
Also, although you might give a nice short name like ``plus'' to the method for
adding MyFloats, you will need to make up new ones:
a.plus(b1); // MyFloat + MyFloat
a.plusFloat(b2); // MyFloat + Float
a.plusInteger(b3); // MyFloat + Integer
a.plusint(b4); // MyFloat + int
Suffer in your programming hell, if you must, but don't lie to others and call
it clean!
> Also, although you might give a nice short name like ``plus'' to the method for
> adding MyFloats, you will need to make up new ones:
>
> a.plus(b1); // MyFloat + MyFloat
> a.plusFloat(b2); // MyFloat + Float
> a.plusInteger(b3); // MyFloat + Integer
> a.plusint(b4); // MyFloat + int
>
> Suffer in your programming hell, if you must, but don't lie to others and call
> it clean!
You didn't study Java too long if you thought that was the case.
a.plus(Integer i)
a.plus(MyFloat f)
a.plus(Float f)
a.plus(int i)
are perfectly acceptable together, and, in my opinion, perfectly
clean. (I'm sure I won't be the only respondent to make this point.)
Jared
From: Kaz Kylheku
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <amiv9q$a4v$1@luna.vcn.bc.ca>
In article <····························@posting.google.com>, Jared MacDonald
wrote:
>> Also, although you might give a nice short name like ``plus'' to the method for
>> adding MyFloats, you will need to make up new ones:
>>
>> a.plus(b1); // MyFloat + MyFloat
>> a.plusFloat(b2); // MyFloat + Float
>> a.plusInteger(b3); // MyFloat + Integer
>> a.plusint(b4); // MyFloat + int
>>
>> Suffer in your programming hell, if you must, but don't lie to others and call
>> it clean!
>
> You didn't study Java too long if you thought that was the case.
>
> a.plus(Integer i)
> a.plus(MyFloat f)
> a.plus(Float f)
> a.plus(int i)
What does it matter? If i is an Object that happens to be a Float,
will a.plus(i) call a.plus(Float f)?
How about making it commute? If you can write a.plus(b), where a is a MyFloat,
and b is an int, then b.plus(a) also should work, and produce the same result.
From: Benjamin Goldberg
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3D8D479E.959FD442@earthlink.net>
Kaz Kylheku wrote:
[snip]
> > a.plus(Integer i)
> > a.plus(MyFloat f)
> > a.plus(Float f)
> > a.plus(int i)
>
> What does it matter? If i is an Object that happens to be a Float,
> will a.plus(i) call a.plus(Float f)?
No, but a.plus((Float)i) will.
> How about making it commute? If you can write a.plus(b), where a is a
> MyFloat, and b is an int, then b.plus(a) also should work, and produce
> the same result.
It doesn't in C++. If you have a as an instance of a class, and b as an
int, and you have "only" defined a MyFloat::operator+(int), then if you
write "b+a", it's a syntax error.
Better yet, consider a class of Points in a field defined by a
particular Elliptical Curve (eg, for ECC cryptography) -- it would make
sense to multiply a Point by an Integer, but it would not make the
slightest bit of sense to multiply an Integer by a Point.
--
Announcement in the Zoo:
"Please don't scare the ostriches! Cement floor!"
From: Kaz Kylheku
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <aml8i0$oat$1@luna.vcn.bc.ca>
In article <·················@earthlink.net>, Benjamin Goldberg wrote:
> Kaz Kylheku wrote:
> [snip]
>> > a.plus(Integer i)
>> > a.plus(MyFloat f)
>> > a.plus(Float f)
>> > a.plus(int i)
>>
>> What does it matter? If i is an Object that happens to be a Float,
>> will a.plus(i) call a.plus(Float f)?
>
> No, but a.plus((Float)i) will.
That statically assumes that i is a Float; what if it is sometimes
a Float and sometimes something else, determined at run time?
>> How about making it commute? If you can write a.plus(b), where a is a
>> MyFloat, and b is an int, then b.plus(a) also should work, and produce
>> the same result.
>
> It doesn't in C++.
I don't care; I consider C++ to be a braindamaged pile of crap. ``C++ does it
that way'' is an insufficient excuse for language design compromises.
> If you have a as an instance of a class, and b as an
> int, and you have "only" defined a MyFloat::operator+(int), then if you
> write "b+a", it's a syntax error.
Correct; moreover, the function called is determined dynamically only
for the leftmost parameter (i.e. the object); it's static for everything
else.
> Better yet, consider a class of Points in a field defined by a
> particular Elliptical Curve (eg, for ECC cryptography) -- it would make
> sense to multiply a Point by an Integer, but it would not make the
> slightest bit of sense to multiply an Integer by a Point.
For that reason, the programmer should be able to define the appropriate
methods to make the operations commute, or not. I'm not saying that the
compiler should try it one way or the other automatically; that would
probably be a bad idea, unless it could be defeated. E.g. common lisp:
(defpackage :my-matrix-package
(:use :common-lisp)
(:shadow :+ :*))
(in-package :my-matrix-package)
(defclass matrix () ())
(defgeneric * (left right))
(defmethod * ((left matrix) (right integer))
(format t "matrix * integer operation called~%"))
(defmethod * ((left integer) (right matrix))
(format t "integer * matrix operation called~%"))
(defvar mat (make-instance 'matrix))
(* mat 3)
matrix * integer operation called
(* 3 mat)
integer * matrix operation called
Writing a new method that takes an integer as the leftmost parameter presents
no problem at all. Moreover there is no stupid integer class versus integer
``basic type''. An integer is both a type and a class.
In some cases it could be nice to have the methods generated both ways
for automatic commutativity. No problem, how about a simple macro:
(defmacro define-commutative-method (name (left right) &body forms)
`(progn (defmethod ,name (,left ,right)
,@forms)
(defmethod ,name (,right ,left)
,@forms)))
This is clean. Clean means that the language gets the hell out of the way so
that I can do what I want with a minimum effort. Clean doesn't mean that the
language is simplified for the implementor, so that the programmer has to pile
workaround upon workaround to get it to do the right thing.
From: Marshall Spight
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <bw8j9.28513$gA4.2962@sccrnsc02>
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message ·················@luna.vcn.bc.ca...
>
> What does it matter? If i is an Object that happens to be a Float,
> will a.plus(i) call a.plus(Float f)?
(I'm assuming what you mean is, i is a variable of declared type
Object, holding a value that is a reference to a Float.)
No, and you wouldn't want it to. That is, and should be, a compile-time error.
Marshall
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message ·················@luna.vcn.bc.ca...
>
> What if N programmers on the same project write their own variant of MyFloat?
Then it's time for the tech lead to KICK SOME ASS!
Marshall
Kaz Kylheku <···@ashi.footprints.net> wrote in message news:<············@luna.vcn.bc.ca>...
> In article <····························@posting.google.com>, Larry A Barowski
> wrote:
> > ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> >> jvm <···@fiberia.is.no.more> wrote in message news:<··························@pixs.htc.nl.philips.com>...
> >> > [Java is] clean, versatile and has excellent *standard* (very important)
> >> > libraries.
> >>
> >> Clean? Let's see, adding two floating point number class objects, to produce a sum:
> >>
> >> Java:
> >>
> >> new Float(a.floatValue() + b.floatValue())
> >>
> >> C++:
> >>
> >> a + b; // given suitable Float class with operator +
> >>
> >> Lisp:
> >>
> >> (+ a b) ;; numbers are class objects
> >
> > Java:
> >
> > a.plus(b) // given suitable MyFloat class with method "plus"
>
> So why is there a Float class in this clean language, if you have to write
> MyFloat? Why can't you just add the method to the Float class?
>
Not needed very often. The Float wrapper is most often used
only as a container. How often do you use arithmetic on float
wrappers in C++?
> What if N programmers on the same project write their own variant of MyFloat?
> N x N conversions, here we go.
>
> Also, although you might give a nice short name like ``plus'' to the method for
> adding MyFloats, you will need to make up new ones:
>
> a.plus(b1); // MyFloat + MyFloat
> a.plusFloat(b2); // MyFloat + Float
> a.plusInteger(b3); // MyFloat + Integer
> a.plusint(b4); // MyFloat + int
>
Not necessary as explained in other responses. Since you didn't
know that, I assume your opinion of Java is based on prejudice
rather than experience.
> Suffer in your programming hell, if you must, but don't lie to others and call
> it clean!
I'm not sure what you mean by clean. Many experienced programmers
consider operator overloading unclean, especially those who work with
other-people's-code. "+" is much more ambiguous than "DotProduct".
If you write and maintain a few 100 kloc of both C++ and Java, as I
have (real world code that people are using), and don't find that
development time and maintenance time for Java are much lower, I would
be quite surprised.
-Larry Barowski
········@eng.auburn.edu (Larry A Barowski) wrote in message news:<····························@posting.google.com>...
> Kaz Kylheku <···@ashi.footprints.net> wrote in message news:<············@luna.vcn.bc.ca>...
> > In article <····························@posting.google.com>, Larry A Barowski
> > wrote:
> > > ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> > >> jvm <···@fiberia.is.no.more> wrote in message news:<··························@pixs.htc.nl.philips.com>...
> > >> > [Java is] clean, versatile and has excellent *standard* (very important)
> > >> > libraries.
> > >>
> > >> Clean? Let's see, adding two floating point number class objects, to produce a sum:
> > >>
> > >> Java:
> > >>
> > >> new Float(a.floatValue() + b.floatValue())
> > >>
> > >> C++:
> > >>
> > >> a + b; // given suitable Float class with operator +
> > >>
> > >> Lisp:
> > >>
> > >> (+ a b) ;; numbers are class objects
> > >
> > > Java:
> > >
> > > a.plus(b) // given suitable MyFloat class with method "plus"
> >
> > So why is there a Float class in this clean language, if you have to write
> > MyFloat? Why can't you just add the method to the Float class?
> >
>
> Not needed very often. The Float wrapper is most often used
> only as a container. How often do you use arithmetic on float
> wrappers in C++?
>
I think you are missing Mr. Kylheku's point, so I will elaborate: Why
does there exist such a thing as float wrappers? Why can't I just
apply the method + to two numbers and have it result in the *right*
answer?
C++ is just as guilty as Java.
Common Lisp, on the other hand, treats all numbers as objects. There
is no need for pesky float-wrappers. Common Lisp also has
multi-methods, so there's no need to define nonsense such as a.plus(b)
when you can simply do (plus a b). Multi-methods dynamically dispatch
on the classes of their arguments, and can easily be supplemented by
writing additional methods.
C++ and Java both conflate code modules with data classes, and this
results in some very awkward code when the method in question does not
fit in with that paradigm. Encapsulation never enters into this
particular question, for example, but it is forced upon you anyway by
C++ and Java. Common Lisp separates the encapsulation mechanism from
the object-system because sometimes it's not appropriate to have them
combined.
Not to mention, with a proper numeric tower you do not get such
nonsense as 14 / 4 evaluating to 3. 3*4 is 12, not 14. The correct
result for 14 / 4 is 7/2. / is not an operation from integers to
integer. It is an operation from numbers to number.
(As for efficiency, the oft-cited reason for Java having primitive
types, any reasonably decent Common Lisp compiler can reduce number
objects and operations to machine equivalents when it can prove that
this can safely be done. Therefore there is no excuse to have
"primitive types" in Java. Premature optimization on the part of the
language design!)
>
> > What if N programmers on the same project write their own variant of MyFloat?
> > N x N conversions, here we go.
> >
> > Also, although you might give a nice short name like ``plus'' to the method for
> > adding MyFloats, you will need to make up new ones:
> >
> > a.plus(b1); // MyFloat + MyFloat
> > a.plusFloat(b2); // MyFloat + Float
> > a.plusInteger(b3); // MyFloat + Integer
> > a.plusint(b4); // MyFloat + int
> >
>
> Not necessary as explained in other responses. Since you didn't
> know that, I assume your opinion of Java is based on prejudice
> rather than experience.
Yes he is wrong about the names (which would be required in an SML
style language). But that is it.
See my point about multi-methods above.
>
> > Suffer in your programming hell, if you must, but don't lie to others and call
> > it clean!
>
> I'm not sure what you mean by clean. Many experienced programmers
> consider operator overloading unclean, especially those who work with
> other-people's-code. "+" is much more ambiguous than "DotProduct".
Certainly! Operator overloading is very unclean when the overloaded
semantics are different from the original semantics. Cross-product is
a better example, since it is not commutative. Operators, all-in-all,
are not very clean in themselves; they are not first-class functions
(except in SML).
>
> If you write and maintain a few 100 kloc of both C++ and Java, as I
> have (real world code that people are using), and don't find that
> development time and maintenance time for Java are much lower, I would
> be quite surprised.
I don't even want to find out---life is too short. I will take your
word for it.
From: Bulent Murtezaoglu
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <87r8flkgnv.fsf@acm.org>
>>>>> "MD" == Matthew Danish <·······@andrew.cmu.edu> writes:
This posting is accurate, but I would like to point something out and
maybe get myself corrected.
[...]
MD> Common Lisp, on the other hand, treats all numbers as objects.
MD> There is no need for pesky float-wrappers. Common Lisp also
MD> has multi-methods, so there's no need to define nonsense such
MD> as a.plus(b) when you can simply do (plus a b). Multi-methods
MD> dynamically dispatch on the classes of their arguments, and
MD> can easily be supplemented by writing additional methods.
True, but
MD> (As for efficiency, the oft-cited reason for Java having
MD> primitive types, any reasonably decent Common Lisp compiler
MD> can reduce number objects and operations to machine
MD> equivalents when it can prove that this can safely be done. [...]
once you use generic functions for your arithmetic (the multi-method
reference above), _AFAIK_ a compliant implementation cannot perform this
optimization. I see no fundamental reason why CLOS cannot be
extended (with things like 'sealing' and such) to do this, but it can't
do it out of the box. Please correct me on this if I am wrong.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> wrote in message news:<··············@acm.org>...
> >>>>> "MD" == Matthew Danish <·······@andrew.cmu.edu> writes:
>
> This posting is accurate, but I would like to point something out and
> maybe get myself corrected.
>
> [...]
> MD> Common Lisp, on the other hand, treats all numbers as objects.
> MD> There is no need for pesky float-wrappers. Common Lisp also
> MD> has multi-methods, so there's no need to define nonsense such
> MD> as a.plus(b) when you can simply do (plus a b). Multi-methods
> MD> dynamically dispatch on the classes of their arguments, and
> MD> can easily be supplemented by writing additional methods.
>
> True, but
>
> MD> (As for efficiency, the oft-cited reason for Java having
> MD> primitive types, any reasonably decent Common Lisp compiler
> MD> can reduce number objects and operations to machine
> MD> equivalents when it can prove that this can safely be done. [...]
>
> once you use generic functions for your arithmetic (the multi-method
> reference above), _AFAIK_ a compliant implementation cannot perform this
> optimization. I see no fundamental reason why CLOS cannot be
> extended (with things like 'sealing' and such) to do this, but it can't
> do it out of the box. Please correct me on this if I am wrong.
>
This isn't an issue with CLOS so much as it is an issue with
full-calls in general. The point of a full-call is that it can be
made from anywhere, and the compiler doesn't know in advance what the
arguments will be (you probably know this, but elaborating for
others). That is where the type-inferring ability of compilers such
as Python (shared by CMUCL, SBCL, and Scieneer CL) and Allegro's
compiler come into play. In closed situations, or where there are
declarations, the types may be decidable; in which case a more
efficient entry-point can be used, while retaining the full-call
entry-point as well. Combine this with open-coding and you can
eliminate the call-overhead too.
Unfortunately, the last time I checked, Python and CLOS aren't very
well integrated, so I don't think this behavior will extend into
methods as it does with functions in those environments. As for
Allegro's compiler, and others, I do not know.
From: Tim Bradshaw
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <ey3k7ld59fg.fsf@cley.com>
* Matthew Danish wrote:
> This isn't an issue with CLOS so much as it is an issue with
> full-calls in general.
It is an issue with CLOS. CLOS specifies that you can redefine
methods on a GF pretty freely. In an unadorned CLOS, the compiler can
simply never statically know what types are allowed at all, or even
what the effective method is for a GF. It has to do a full call, and
be willing to actually compute the effective method at the time of
that call. Obviously clever caching tricks mean that this doesn't
actually cost very much in practice, but it is very hard to see how
you could make it cheaper than a full ordinary function call (one way
to make it possibly cheaper would be the heroic trick of having the
compiler note every call site, and on any change to the GF to be
willing to recompile all calls).
*But* there is absolutely nothing preventing an implementation adding
sealing declarations which would allow the compiler, for instance, to
know that the GF+methods that it knows are all the ones that exist,
and to take advantage of that knowledge the same way it can for, say,
+.
--tim
Sorry for the second reply, but a further correction:
I was assuming in my previous post that we were talking about the
built-in number classes. In the case of a normal user-defined class,
something like sealing would be necessary if open-coding were to take
place (to ensure that the choice of methods is indeed static). Also I
forgot to consider method-combination which ensures that no
open-coding can take place (unless one is to take an
inline-declaration as waiver of all redefinition-rights).
You are correct about multi-methods, but since the arithmetic
functions are built-in and not subject to redefinition they can be
optimized well. And all the necessary "methods" are already defined
on them for numerical operations.
From: Bulent Murtezaoglu
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <87elblk2gk.fsf@acm.org>
>>>>> "MD" == Matthew Danish <·······@andrew.cmu.edu> writes:
MD> Sorry for the second reply, but a further correction: I was
MD> assuming in my previous post that we were talking about the
MD> built-in number classes.
Yeah, I assumed so.
MD> In the case of a normal user-defined
MD> class, something like sealing would be necessary if
MD> open-coding were to take place (to ensure that the choice of
MD> methods is indeed static).
Yup. Doesn't seem horribly hard, and might, under some cicumstances, be
doable with a compiler-macro even without sealing. Something roughly like
Inspect funcall,find applicable method, recover the function itself and
then fall back on the built-in compiler optimizations. This does break
CLOS but it breaks it in much the same way as inlining breaks redefinition
via defun (as you point out below). Anyhow that is just my hunch,
and I am pretty ignorant on these things.
MD> Also I forgot to consider
MD> method-combination which ensures that no open-coding can take
MD> place (unless one is to take an inline-declaration as waiver
MD> of all redefinition-rights). [...]
That seems like an excellent idea actually. Maybe something along the
lines of CMUCL's maybe-inline that causes the compiler to save enough
information for a variaty of optimizations during compilation without
comitting to inline the defun outright.
Follow-up's redirected to c.l.lisp
cheers,
BM
"Matthew Danish" <·······@andrew.cmu.edu> wrote in message
·································@posting.google.com...
>
> (As for efficiency, the oft-cited reason for Java having primitive
> types, any reasonably decent Common Lisp compiler can reduce number
> objects and operations to machine equivalents when it can prove that
> this can safely be done. Therefore there is no excuse to have
> "primitive types" in Java. Premature optimization on the part of the
> language design!)
There is every excuse for this choice in a language originally targeted at
set top boxes and other environments where a JIT may be a luxury. Even where
a JIT is available there remain types of calculations where it is not
possible to safely deduce that machine types would suffice. So these
calculations would suffer a performance penalty where Java does not. In
those cases where numerical performance is crucial, you then require the
programmer to understand which forms of calculation are reducable by the
compiler to an efficient form and how to recast the calculation in such a
form (if it is even possible).
In short it is not yet possible to eliminate primitive types without
imposing some costs.
Mark Thornton
From: Kaz Kylheku
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <amlbl1$pci$1@luna.vcn.bc.ca>
In article <··············@ID-139894.news.dfncis.de>, Mark Thornton wrote:
>
> "Matthew Danish" <·······@andrew.cmu.edu> wrote in message
> ·································@posting.google.com...
>>
>> (As for efficiency, the oft-cited reason for Java having primitive
>> types, any reasonably decent Common Lisp compiler can reduce number
>> objects and operations to machine equivalents when it can prove that
>> this can safely be done. Therefore there is no excuse to have
>> "primitive types" in Java. Premature optimization on the part of the
>> language design!)
>
> There is every excuse for this choice in a language originally targeted at
> set top boxes and other environments where a JIT may be a luxury. Even where
> a JIT is available there remain types of calculations where it is not
> possible to safely deduce that machine types would suffice.
In those situations, the programmer could be provided with an optional
declaration mechanism. Common Lisp has a standard way to declare, over specific
regions of code, how much the programmer cares about size, safety and speed.
And standard ways to indicate that some value can be assumed to have a certain
type.
> So these
> calculations would suffer a performance penalty where Java does not. In
The biggest performance penalty in software is lost programmer productivity due
to wrestling with poor abstractions, and poor abstraction-defining tools.
> those cases where numerical performance is crucial, you then require the
> programmer to understand which forms of calculation are reducable by the
> compiler to an efficient form and how to recast the calculation in such a
> form (if it is even possible).
Why is it okay to require the programmer to wrestle with a stupid static
typesystem in the entire program, but not okay to require the the programmer to
learn how to optimize a few hotspots?
Heck, you can even use a different language for the hotspots. If you want
maximum, uncompromising performance, drop down to the target-specific
machine language level.
> In short it is not yet possible to eliminate primitive types without
> imposing some costs.
It's not yet possible to eliminate assembly language without imposing some
performance costs either.
From: Tim Bradshaw
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <ey3lm5tixz3.fsf@cley.com>
* Mark Thornton wrote:
> There is every excuse for this choice in a language originally targeted at
> set top boxes and other environments where a JIT may be a luxury. Even where
> a JIT is available there remain types of calculations where it is not
> possible to safely deduce that machine types would suffice. So these
> calculations would suffer a performance penalty where Java does not. In
> those cases where numerical performance is crucial, you then require the
> programmer to understand which forms of calculation are reducable by the
> compiler to an efficient form and how to recast the calculation in such a
> form (if it is even possible).
This is a spurious argument. If it's not possible for the compiler to
safely deduce that machine types can be used then it knows this (by
definition), and there is nothing at all preventing it telling you.
At least one major CL implementation can warn copiously about just
this kind of failure:
(defun foo (x y)
(declare (optimize speed) (type fixnum x y))
(* x y))
foo
* (compile *)
Compiling lambda (x y):
In: lambda (x y)
(* x y)
Note: Unable to recode as shift and add due to type uncertainty:
The first argument is a fixnum, not a (unsigned-byte 32).
The second argument is a fixnum, not a (unsigned-byte 32).
The result is a (integer -288230375614840832 288230376151711744), not a (unsigned-byte
32).
Note: Forced to do generic-* (cost 50).
Unable to do inline fixnum arithmetic (cost 2) because:
The result is a (integer -288230375614840832 288230376151711744), not a fixnum.
Unable to do inline (signed-byte 32) arithmetic (cost 3) because:
The result is a (integer -288230375614840832 288230376151711744), not a (signed-byte
32).
etc.
Compiling Top-Level Form:
Compilation unit finished.
2 notes
foo
t
nil
*
This kind of thing has been available in Lisp systems for at least 10
years, and probably closer to 20.
--tim
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * Mark Thornton wrote:
>
> > There is every excuse for this choice in a language originally targeted
at
> > set top boxes and other environments where a JIT may be a luxury. Even
where
> > a JIT is available there remain types of calculations where it is not
> > possible to safely deduce that machine types would suffice. So these
> > calculations would suffer a performance penalty where Java does not. In
> > those cases where numerical performance is crucial, you then require the
> > programmer to understand which forms of calculation are reducable by the
> > compiler to an efficient form and how to recast the calculation in such
a
> > form (if it is even possible).
>
> This is a spurious argument. If it's not possible for the compiler to
> safely deduce that machine types can be used then it knows this (by
> definition), and there is nothing at all preventing it telling you.
>
> At least one major CL implementation can warn copiously about just
> this kind of failure:
Fair enough the compiler can warn you. However it appears still the case
that it will not always be easy or even possible to recast your calculation
in a form that is computed efficiently.
Mark Thornton
From: Tim Bradshaw
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <ey3ofap59su.fsf@cley.com>
* Mark Thornton wrote:
> Fair enough the compiler can warn you. However it appears still the case
> that it will not always be easy or even possible to recast your calculation
> in a form that is computed efficiently.
Well, if it can be done efficiently with native types then, well, it
can be done. If it can't then it can't and the availability of native
types won't help you.
I think the answer on this kind of thing is really clear. It's
possible although not implementationally trivial to integrate native
and non-native numeric types such that `everything is an object' and
at the same time numerical calculations on suitably small values of
good types have efficiency very close to that of a `nothing is an
object' system (like C, or Java's native types). Common Lisp
implementations do this pretty well in general, and do it with a tiny
fraction of the implementation effort that has gone into, say Java
implementations (because there are a tiny fraction of the people
implementing CL as implementing Java). If Java had bitten this bullet
then it could have done it too, but it chose not to, thus imposing
permanent pain on its users for the benefit of implementors. That
kind of tradeoff is something I, as a user, find entirely
unacceptable.
--tim
Mark Thornton wrote:
> "Matthew Danish" <·······@andrew.cmu.edu> wrote in message
> ·································@posting.google.com...
>
>>(As for efficiency, the oft-cited reason for Java having primitive
>>types, any reasonably decent Common Lisp compiler can reduce number
>>objects and operations to machine equivalents when it can prove that
>>this can safely be done. Therefore there is no excuse to have
>>"primitive types" in Java. Premature optimization on the part of the
>>language design!)
>
> There is every excuse for this choice in a language originally targeted at
> set top boxes and other environments where a JIT may be a luxury. Even where
> a JIT is available there remain types of calculations where it is not
> possible to safely deduce that machine types would suffice. So these
> calculations would suffer a performance penalty where Java does not.
Sorry, I don't understand this point. My perception is as follows: When
you use a certain numerical type in a language like Java like, say, a
32-bit integer, and your tests show that this type is not capable of
holding all values that may occur, then you basically have two choices.
One is to switch the involved variables to, say, 64-bit integers by
default; the other is to manually check for overflows and insert the
necessary type casts. The former generally looses the efficiency you are
asking for; the latter is tedious and error-prone (it gets even worse
when you have to switch to something like BigInteger).
For example in Common Lisp (and I think in Smalltalk as well), numbers
take the minimum size they need by default and the runtime system takes
care of doing the necessary overflow checks and casts to larger types
automatically. So this is both efficient and safe (for example, you
cannot forget to include checks at any place where they are necessary),
and this may even reduce the number of tests. So by default, Common Lisp
does for you what you would have to program yourself anyway in Java.
(And if you are 100% sure that a variable will ever hold a number with a
maximum number of bits known in advance, you can even declare this and
the compiler can do the optimiziations that result from this declaration.)
So I cannot see any advantage in having distinct primitive types. What
am I missing?
Pascal
Pascal Costanza wrote:
>So I cannot see any advantage in having distinct primitive types. What
>am I missing?
I think it's a direct inheritance from C.
--
Bart.
I do agree with you in the respect that operator overloading is a
painful omission from the Java language. But your example is a bit
unfair towards Java for two reasons:
a + b in C++
is not the equivalent of
new Float(a.floatValue() + b.floatValue())
The correct translation would be:
a.add(b)
Your Java code is quite a strange version of what could be Float c = a
+ b in C++ (provided there were a Float class). The sensible Java
translation would be Float c = a.add(b) which is not terribly hard to
read.
And then we all know that you can produce fairly cryptic code with C++
as well. Any idea what this means for example:
pObj->*n = 22;
or this:
int Dog::*age
Nevertheless I do agree with you that some of Java's "simplifications"
do in fact make things more complicated and unsafe. Every Java program
contains a miriad of type casts of the form:
ItemType item = (ItemType)iterator.next();
or
ItemType item = (ItemType)map.get(key);
That's tedious and above all it produces incredible amounts of
ClassCastExceptions at runtime. Something that would never happen in
C++ because that's what templates are for. Templates (or generics as
they call it in the Java community) is THE most wanted new feature and
it will be added in the next Java version (sometime in 2003).
Regards,
Alexander
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> jvm <···@fiberia.is.no.more> wrote in message news:<··························@pixs.htc.nl.philips.com>...
> > [Java is] clean, versatile and has excellent *standard* (very important)
> > libraries.
>
> Clean? Let's see, adding two floating point number class objects, to produce a sum:
>
> Java:
>
> new Float(a.floatValue() + b.floatValue())
>
> C++:
>
> a + b; // given suitable Float class with operator +
>
> Lisp:
>
> (+ a b) ;; numbers are class object
From: Kaz Kylheku
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <ami74f$rfm$2@luna.vcn.bc.ca>
In article <····························@posting.google.com>, Alexander
Jerusalem wrote:
> I do agree with you in the respect that operator overloading is a
> painful omission from the Java language. But your example is a bit
> unfair towards Java for two reasons:
>
> a + b in C++
> is not the equivalent of
> new Float(a.floatValue() + b.floatValue())
> The correct translation would be:
> a.add(b)
Does the Float class include a method for every arithmetic operation
that one could use over floats, so that you never have to manually ``unbox''
the float value from the Float object?
> And then we all know that you can produce fairly cryptic code with C++
> as well. Any idea what this means for example:
> pObj->*n = 22;
>
> or this:
> int Dog::*age
Of course I do; I use pointers-to-member relatively frequently, when I'm paid
to to code in one of the world's most idiotic programming languages.
The syntax is perverse; in particular, the ->* operator has the wrong
precedence, so that obj->*func(arg) means obj->*(func(arg)),
rather than the intended (obj->*func)(arg).
However, the functionality of a pointer-to-member is important an useful.
In Common Lisp, we can retain the symbol which selects a class slot, and then
use it to dynamically select that slot of a given object instance. Pointers to
member functions aren't necessary because generic functions are functions; you
can indirect upon them in the same way:
(defgeneric foo (arg))
(defmethod foo ((arg string))
(reverse arg))
(defmethod foo ((arg number))
(* 2 arg))
(mapcar #'foo '(1 2.0 "asdf"))
==> (2 4.0 "fdsa") ;; numbers got doubled, strings reversed.
The expression #'foo gives you a pointer to a generic-function object,
which you can apply over types for which foo has methods.
> Nevertheless I do agree with you that some of Java's "simplifications"
> do in fact make things more complicated and unsafe. Every Java program
> contains a miriad of type casts of the form:
>
> ItemType item = (ItemType)iterator.next();
> or
> ItemType item = (ItemType)map.get(key);
>
> That's tedious and above all it produces incredible amounts of
> ClassCastExceptions at runtime. Something that would never happen in
> C++ because that's what templates are for. Templates (or generics as
> they call it in the Java community) is THE most wanted new feature and
> it will be added in the next Java version (sometime in 2003).
Actually, for iterating over sequences, I don't want to deal with an iterator
object at all. All I care about is having some symbol freshly bound to each
successive element, and a body of code that is evaluated with that symbol in
lexical scope. Iterators expose the mechanism, and thus severely weaken the
abstraction, if not destroy it completely.
For example, I make much use of a construct that I invented for myself called
FOR-EACH-FILE-INFO that iterates over filesystem trees. Here is an example use:
;;; Count disk usage in blocks, taking care to not count
;;; hard linked files twice.
(let ((inode-hash (make-hash-table))
(disk-usage 0)
(some-path "/usr/local"))
(for-each-file-info (fi some-path)
(unless (gethash (inode fi) inode-hash)
(setf (gethash (inode fi) inode-hash) fi)
(incf disk-usage (blocks fi))))
(format t "Usage for ~a is ~a blocks.~%" some-path disk-usage))
Or how about an iteration example using only standard features:
(let ((list '(("Joe" 23 "Mechanic")
("Amy" 41 "Executive")
("Bob" 31 "Programmer"))))
(loop for (name age occupation)
in list
do (format t "name: ~a, age: ~a, occupation ~a~%"
name age occupation)))
Output:
name: Joe, age: 23, occupation Mechanic
name: Amy, age: 41, occupation Executive
name: Bob, age: 31, occupation Programmer
With loathing do I anticipate the next time I will be forced to write
``iter.next()'', or sugared equivalent, in some pathetic excuse for a
programming language.
Kaz Kylheku <···@ashi.footprints.net> wrote in message news:<············@luna.vcn.bc.ca>...
> In article <····························@posting.google.com>, Alexander
> Jerusalem wrote:
> > I do agree with you in the respect that operator overloading is a
> > painful omission from the Java language. But your example is a bit
> > unfair towards Java for two reasons:
> >
> > a + b in C++
> > is not the equivalent of
> > new Float(a.floatValue() + b.floatValue())
> > The correct translation would be:
> > a.add(b)
>
> Does the Float class include a method for every arithmetic operation
> that one could use over floats, so that you never have to manually ``unbox''
> the float value from the Float object?
No, actually that was my mistake. I worked so much with the BigDecimal
class recently which does have all the mathematical operations and is
also a subclass of Number, so that I infered that this was the case
for Float as well. So you were completely right in your criticism. Of
course it wouldn't be a big task to subclass the Number wrapper
classes to add some mathematical operations. But you're right it's not
in the Float class itself, which is a shame.
>
> > And then we all know that you can produce fairly cryptic code with C++
> > as well. Any idea what this means for example:
> > pObj->*n = 22;
> >
> > or this:
> > int Dog::*age
>
> Of course I do; I use pointers-to-member relatively frequently, when I'm paid
> to to code in one of the world's most idiotic programming languages.
> The syntax is perverse; in particular, the ->* operator has the wrong
> precedence, so that obj->*func(arg) means obj->*(func(arg)),
> rather than the intended (obj->*func)(arg).
>
> However, the functionality of a pointer-to-member is important an useful.
Agreed. It's cryptic but powerful, like many things in C++.
>
> In Common Lisp, we can retain the symbol which selects a class slot, and then
> use it to dynamically select that slot of a given object instance. Pointers to
> member functions aren't necessary because generic functions are functions; you
> can indirect upon them in the same way:
>
> (defgeneric foo (arg))
>
> (defmethod foo ((arg string))
> (reverse arg))
>
> (defmethod foo ((arg number))
> (* 2 arg))
>
> (mapcar #'foo '(1 2.0 "asdf"))
>
> ==> (2 4.0 "fdsa") ;; numbers got doubled, strings reversed.
>
> The expression #'foo gives you a pointer to a generic-function object,
> which you can apply over types for which foo has methods.
That's great. I'd like to learn much more about Common Lisp. The real
problem here is that as a contractor they won't let you use Lisp in
commercial projects very often because none of the customers staff
knows it. I have the same problem with Python by the way.
Regards,
Alexander
·····@blueyonder.co.uk (Alexander Jerusalem) writes:
> > In Common Lisp, we can retain the symbol which selects a class slot, and then
> > use it to dynamically select that slot of a given object instance. Pointers to
> > member functions aren't necessary because generic functions are functions; you
> > can indirect upon them in the same way:
> >
> > (defgeneric foo (arg))
> >
> > (defmethod foo ((arg string))
> > (reverse arg))
> >
> > (defmethod foo ((arg number))
> > (* 2 arg))
> >
> > (mapcar #'foo '(1 2.0 "asdf"))
> >
> > ==> (2 4.0 "fdsa") ;; numbers got doubled, strings reversed.
> >
> > The expression #'foo gives you a pointer to a generic-function object,
> > which you can apply over types for which foo has methods.
>
> That's great. I'd like to learn much more about Common Lisp.
That is good!
> The real problem here is that as a contractor they won't let you use
> Lisp in commercial projects very often because none of the customers
> staff knows it. I have the same problem with Python by the way.
You should have less problems with Common Lisp, once you point out
that (unlike Python) you can compile Common Lisp code to extremely
efficient native assembly.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
·····@blueyonder.co.uk (Alexander Jerusalem) wrote in message news:<···························@posting.google.com>...
[...]
> Of
> course it wouldn't be a big task to subclass the Number wrapper
> classes to add some mathematical operations.
Except that they (Float, Integer, etc.) are final...
In Common Lisp, on the other hand, it wouldn't be a big task
at all (if it were needed, that is, since values of the primitive
numeric types in Common Lisp are already objects, with some
subtypes such as FIXNUM and SHORT-FLOAT typically having special
efficient `unboxed' representations). It wouldn't even require
subclassing, merely defining more methods for the respective
generic functions.
---Vassil.
Alexander Jerusalem wrote:
>
> Nevertheless I do agree with you that some of Java's "simplifications"
> do in fact make things more complicated and unsafe. Every Java program
> contains a miriad of type casts of the form:
>
> ItemType item = (ItemType)iterator.next();
> or
> ItemType item = (ItemType)map.get(key);
>
> That's tedious and above all it produces incredible amounts of
> ClassCastExceptions at runtime. Something that would never happen in
> C++ because that's what templates are for. Templates (or generics as
> they call it in the Java community) is THE most wanted new feature and
> it will be added in the next Java version (sometime in 2003).
Generics is not just a different name for templates, but generics and
templates are two different concepts that share some similarities.
Templates in C++ allow you to use type variables when you declare your
superclasses. This is forbidden in the generics extension for Java.
Therefore, templates are Turing-complete, generics are not. That's an
important distinction.
In order to get this back on topic again: I have stated that it's not
necessarily a good idea to use a hyped language for learning, and I
would definitely include Java and Perl in the list of hyped languages.
Here is why:
* Hyped languages are generally used for a limited set of concerns. Java
has been developed explicitly for embedded devices and for the web. Perl
has been developed for certain kinds of scripting tasks. Learning such
languages usually means that the examples you use are narrowed down to
these "popular" domains. It's likely that you loose your view on the
more general concepts that determine certain language design choices. (I
don't say that you will definitely run into such traps, I only say that
it is more likely.)
* There are several languages out there that haven't been trimmed to
certain "popular" tasks. Such languages are more likely to teach you
general principles of languages. Understanding these general principles
make you a better programmer.
So for example, if you have understood the concepts of closures,
higher-order functions, object identity, static vs. dynamic typing, and
so on, and so forth, by having seen them in very different languages,
you will definitely have an easy time to recognize the same concepts in
any new language that will come up in the future for the next hype. No
one can guarantee you that Java, Perl or similar languages are still
alive in, say, five or ten years. But those concepts will definitely endure.
So for example, learning Common Lisp might buy you much more, because it
includes a wealth of ideas and concepts that steadily change your view
of the world. This will increase your flexibility in solving concrete
problems, whether you use Common Lisp in practice or not.
Pascal
Also sprach Pascal Costanza:
> In order to get this back on topic again: I have stated that it's not
> necessarily a good idea to use a hyped language for learning, and I
> would definitely include Java and Perl in the list of hyped languages.
> Here is why:
>
> * Hyped languages are generally used for a limited set of concerns. Java
> has been developed explicitly for embedded devices and for the web. Perl
> has been developed for certain kinds of scripting tasks. Learning such
> languages usually means that the examples you use are narrowed down to
> these "popular" domains. It's likely that you loose your view on the
> more general concepts that determine certain language design choices. (I
> don't say that you will definitely run into such traps, I only say that
> it is more likely.)
Well, Perl was indeed created with some domains in mind...15 years ago.
Ever since Perl5 a quite complete set of OO-techniques have been added.
Perl6 will have even more of this and supersede virtually any language
that currently is a close rival.
As for Java, Java nowadays is certainly rather used as a language for
big projects and general programming. When programming Java, it feels
anything but designed for embedded devices.
> * There are several languages out there that haven't been trimmed to
> certain "popular" tasks. Such languages are more likely to teach you
> general principles of languages. Understanding these general principles
> make you a better programmer.
So, in other words: A language must be unpopular and clumsy in order to
teach good principles? Sure, in this concern Lisp is definitely the best
teacher.
> So for example, if you have understood the concepts of closures,
> higher-order functions, object identity, static vs. dynamic typing, and
> so on, and so forth, by having seen them in very different languages,
> you will definitely have an easy time to recognize the same concepts in
> any new language that will come up in the future for the next hype. No
> one can guarantee you that Java, Perl or similar languages are still
> alive in, say, five or ten years. But those concepts will definitely endure.
All of this is already there in Perl, except perhaps the static vs.
dynamic typing thing since Perl5 is strictly dynamic. Perl6 will have
more means of statically typing variables. But I really don't understand
why one shouldn't be able to learn the concept of closures and
higher-order functions in Perl: In Perl each function is actually a
closure.
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
Tassilo v. Parseval wrote:
> Also sprach Pascal Costanza:
>>In order to get this back on topic again: I have stated that it's not
>>necessarily a good idea to use a hyped language for learning, and I
>>would definitely include Java and Perl in the list of hyped languages.
>>Here is why:
>>
>>* Hyped languages are generally used for a limited set of concerns. Java
>>has been developed explicitly for embedded devices and for the web. Perl
>>has been developed for certain kinds of scripting tasks. Learning such
>>languages usually means that the examples you use are narrowed down to
>>these "popular" domains.
[...]
> Well, Perl was indeed created with some domains in mind...15 years ago.
> Ever since Perl5 a quite complete set of OO-techniques have been added.
> Perl6 will have even more of this and supersede virtually any language
> that currently is a close rival.
I find such statements very strange. Why didn't Perl have these features
in the first place, why were they added only later in its history? In
fact, the concepts have been known long before. Why didn't people use a
language that had all these features in the first place? Why do they
wait for Perl to include them? Obviously, they are needed, otherwise
Perl would _not_ include them.
My perception is that scripting languages like Perl all start to be
simplified languages that are boild down to the bare necessary features
that are perceived to be needed for a specific task. However, it always
turns out that you need a full-blown language sooner or later, no matter
what task you try to accomplish. So I am convinced it's always better to
start with "the real thing" right away.
> As for Java, Java nowadays is certainly rather used as a language for
> big projects and general programming. When programming Java, it feels
> anything but designed for embedded devices.
Yes, but its designers had embedded devices and web applications in mind
when they designed it. And web applications were among the reasons why
people have adopted it so fast. What conclusions you can draw from the
fact that it is now mainly used for totally different purposes is left
as an exercise for the reader. ;-)
>>* There are several languages out there that haven't been trimmed to
>>certain "popular" tasks. Such languages are more likely to teach you
>>general principles of languages. Understanding these general principles
>>make you a better programmer.
>
> So, in other words: A language must be unpopular and clumsy in order to
> teach good principles? Sure, in this concern Lisp is definitely the best
> teacher.
I didn't say "clumsy". I think you are intentionally bending my argument.
To rephrase your rhetorics: A language must be trendy and clumsy in
order to teach good principles? ;)
My statement is: In order to learn good principles you have to study the
principles in the first place, not the languages! However, these
principles are not available as entities in their own right, but are
always concretized in languages, so you can't do away with looking at
concrete languages (this wouldn't make sense anyway). But by learning a
variety of languages you will learn and recognize what the essentially
parts of those principles are and what only superficial coincidences of
concrete instances in a specific language are.
By learning a "hyped" language the danger is considerably high to get
stuck by coincidences of the language, or worse, by coincidences of its
popular domain(s). Only by looking at a wide variety of languages and
domains, including unpopular ones, you will train your mind to think in
flexible and unusual ways. The unpopular domain of today might be the
popular domain of tomorrow!
Here is a simple exercise to illustrate what I am thinking about:
1. When you have closures and recursion, it is not strictly necessary to
include explicit loop constructs in a programming language.
2. Java's inner classes are in fact a restricted variant of closures.
3. To prove statement 1, implement a for loop in Java without using any
explicit control structures (like for, while, etc.), but only with
anonymous inner classes and recursion.
This is possible, and you learn several facts about closures by doing
this on your own.
(Do the same exercise in any other language that has a better support
for closures, and you have learned something about the clumsiness of
Java. ;-)
>>So for example, if you have understood the concepts of closures,
>>higher-order functions, object identity, static vs. dynamic typing, and
>>so on, and so forth, by having seen them in very different languages,
>>you will definitely have an easy time to recognize the same concepts in
>>any new language that will come up in the future for the next hype. No
>>one can guarantee you that Java, Perl or similar languages are still
>>alive in, say, five or ten years. But those concepts will definitely endure.
>
>
> All of this is already there in Perl, except perhaps the static vs.
> dynamic typing thing since Perl5 is strictly dynamic. Perl6 will have
> more means of statically typing variables. But I really don't understand
> why one shouldn't be able to learn the concept of closures and
> higher-order functions in Perl: In Perl each function is actually a
> closure.
It doesn't matter in the context of my argument whether Perl has these
features or not. (But to note this again: I don't see the point when
language designers try to include as much features as possible.
Questions that are equally important include: Are these features well
integrated? Do they follow some orthogonality principle? Is it easy for
programmers to comprehend these features? Are they proven in practice? ...)
Pascal
"Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
>
> I find such statements very strange. Why didn't Perl have these features
> in the first place, why were they added only later in its history?
Why don't you stick with Lisp, v. 1.0? You know, the one just before
they put "eval" in?
That's a rhetorical question, of course. You use the latest Common Lisp
because it's the best one so far. Likewise for the Perl people using the
latest Perl.
> > As for Java, Java nowadays is certainly rather used as a language for
> > big projects and general programming. When programming Java, it feels
> > anything but designed for embedded devices.
>
> Yes, but its designers had embedded devices and web applications in mind
> when they designed it.
How does this matter in any least way? It doesn't.
> My statement is: In order to learn good principles you have to study the
> principles in the first place, not the languages! However, these
> principles are not available as entities in their own right, but are
> always concretized in languages, so you can't do away with looking at
> concrete languages (this wouldn't make sense anyway).
Why not? Why can't you have a textbook in language principles?
They did math before they had Mathematica, after all.
> 2. Java's inner classes are in fact a restricted variant of closures.
Closures encapsulate state and behavior. Classes encapsulate state
and behavior. You don't need both.
Marshall
Marshall Spight wrote:
> That's a rhetorical question, of course. You use the latest Common Lisp
> because it's the best one so far. Likewise for the Perl people using the
> latest Perl.
Ah, but they don't. I know of at least three medium sized (international
3000+ user) systems that have -- because of compatability problems with
upgrading -- stuck with perl 5.0005. The testing nightmare of upgrading
and breaking things in new and interesting ways was deemed to expensive.
However, since there is an ANSI standard for common lisp upgrading using
the latest *conforming* compiler is much cheaper and safer.
:)w
From: Kaz Kylheku
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <amieh2$32s$1@luna.vcn.bc.ca>
In article <·······················@rwcrnsc52.ops.asp.att.net>, Marshall
Spight wrote:
> "Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
>> My statement is: In order to learn good principles you have to study the
>> principles in the first place, not the languages! However, these
>> principles are not available as entities in their own right, but are
>> always concretized in languages, so you can't do away with looking at
>> concrete languages (this wouldn't make sense anyway).
>
> Why not? Why can't you have a textbook in language principles?
> They did math before they had Mathematica, after all.
However, mathematics is not a framework for describing Mathematica.
>> 2. Java's inner classes are in fact a restricted variant of closures.
>
> Closures encapsulate state and behavior. Classes encapsulate state
> and behavior. You don't need both.
That's the kind of conclusion you might come up with if you understand classes
and closures from a textbook description. The reality of how these entities
factor into actual software development is quite different.
If you took either closures or classes out of Common Lisp, you would severely
cripple the language.
Firstly, whether classes encapsulate state and behavior depends on the object
system. In the Lisp object system, classes don't have behavior, only state.
(If we temporarily close our eyes to things like slot initforms). A textbook
which asserts that classes encapsulate state and behavior is biased toward
Simula-67-like languages with single dispatch. Behavior comes from generic
functions, which serve as abstract interfaces to methods.
Secondly, closures express something different from classes. Though there are
some superficial similarities between the class objects of a single-dispatch
object system and closures, this does not imply that the expressive power of
one makes that of the other superfluous.
And even if two programming language entities are provably equivalent, that
doesn't mean that it's easy to substitute one for the other in a given software
development task. They may have different expressive powers that make them
uniquely suitable to given situations.
Marshall Spight wrote:
> "Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
>
>>I find such statements very strange. Why didn't Perl have these features
>>in the first place, why were they added only later in its history?
>
> Why don't you stick with Lisp, v. 1.0? You know, the one just before
> they put "eval" in?
>
> That's a rhetorical question, of course. You use the latest Common Lisp
> because it's the best one so far. Likewise for the Perl people using the
> latest Perl.
Yes, but Lisp 1.0 was developed at a time (in the 50's or 60's) when
many of the concepts that are included in Common Lisp were not known or
poorly understood. So you can't blame John McCarthy for not having
included object orientation because the concept didn't exist as such.
You can't say that in the case of Perl.
>>My statement is: In order to learn good principles you have to study the
>>principles in the first place, not the languages! However, these
>>principles are not available as entities in their own right, but are
>>always concretized in languages, so you can't do away with looking at
>>concrete languages (this wouldn't make sense anyway).
>
> Why not? Why can't you have a textbook in language principles?
> They did math before they had Mathematica, after all.
These textbooks exist, but the good ones always include concrete
examples. For mathematics, you also always use some kind of concrete
notation.
>>2. Java's inner classes are in fact a restricted variant of closures.
>
>
> Closures encapsulate state and behavior. Classes encapsulate state
> and behavior. You don't need both.
You're proving my point: Why can you make this statement? Because you
understand these two concepts!
I think it's a mistake to tell other people that they shouldn't look at
closures because they won't need it. I am convinced that it's far better
to empower them so that they can make up their own mind. Their mileage
may vary!
Pascal
From: Marshall Spight
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <Uh6j9.26966$gA4.2883@sccrnsc02>
"Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
> Marshall Spight wrote:
> > "Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
> >
> >>I find such statements very strange. Why didn't Perl have these features
> >>in the first place, why were they added only later in its history?
> >
> > Why don't you stick with Lisp, v. 1.0? You know, the one just before
> > they put "eval" in?
> >
> > That's a rhetorical question, of course. You use the latest Common Lisp
> > because it's the best one so far. Likewise for the Perl people using the
> > latest Perl.
>
> Yes, but Lisp 1.0 was developed at a time (in the 50's or 60's) when
> many of the concepts that are included in Common Lisp were not known or
> poorly understood. So you can't blame John McCarthy for not having
> included object orientation because the concept didn't exist as such.
> You can't say that in the case of Perl.
Well, uh, you have a point there.
> >>2. Java's inner classes are in fact a restricted variant of closures.
> >
> > Closures encapsulate state and behavior. Classes encapsulate state
> > and behavior. You don't need both.
>
> You're proving my point: Why can you make this statement? Because you
> understand these two concepts!
Well, uh, you have a point there too.
Marshall
Also sprach Pascal Costanza:
> Tassilo v. Parseval wrote:
>> Well, Perl was indeed created with some domains in mind...15 years ago.
>> Ever since Perl5 a quite complete set of OO-techniques have been added.
>> Perl6 will have even more of this and supersede virtually any language
>> that currently is a close rival.
>
> I find such statements very strange. Why didn't Perl have these features
> in the first place, why were they added only later in its history? In
> fact, the concepts have been known long before. Why didn't people use a
> language that had all these features in the first place? Why do they
> wait for Perl to include them? Obviously, they are needed, otherwise
> Perl would _not_ include them.
Yes, they are needed...and good they are there, after all.
Perl had an odd history: Larry Wall did it to circumvent a special
limitation in awk. But during the years he decided to pich some of the
best features of other languages and include them in Perl. It's not as
consistent as Lisp, granted, but then again no human is consistent. I
even think that consistency sometimes scares us off.
> My perception is that scripting languages like Perl all start to be
> simplified languages that are boild down to the bare necessary features
> that are perceived to be needed for a specific task. However, it always
> turns out that you need a full-blown language sooner or later, no matter
> what task you try to accomplish. So I am convinced it's always better to
> start with "the real thing" right away.
But then you might create a dogmatic monster that is interesting from a
technical standpoint but not so much in practical use. I don't think
Lisp is one, but some might say it's already on the edge.
>> So, in other words: A language must be unpopular and clumsy in order to
>> teach good principles? Sure, in this concern Lisp is definitely the best
>> teacher.
>
> I didn't say "clumsy". I think you are intentionally bending my argument.
Was just too tempting. ;-)
> To rephrase your rhetorics: A language must be trendy and clumsy in
> order to teach good principles? ;)
>
> My statement is: In order to learn good principles you have to study the
> principles in the first place, not the languages!
But this is not satisfactory from a pedagogical standpoint. It's easier
to learn when there is some fun and perhaps even usefulness in the
matter.
> However, these principles are not available as entities in their own
> right, but are always concretized in languages, so you can't do away
> with looking at concrete languages (this wouldn't make sense anyway).
> But by learning a variety of languages you will learn and recognize
> what the essentially parts of those principles are and what only
> superficial coincidences of concrete instances in a specific language
> are.
So, there you are right. The tenor of that is: Learn more than one
language.
> By learning a "hyped" language the danger is considerably high to get
> stuck by coincidences of the language, or worse, by coincidences of its
> popular domain(s). Only by looking at a wide variety of languages and
> domains, including unpopular ones, you will train your mind to think in
> flexible and unusual ways. The unpopular domain of today might be the
> popular domain of tomorrow!
The term 'hyped' was certainly not framed by me (was it you in the first
place?). I still think it is misplaced in thsi discussion. Either a
language is useful or not. It's not Java's fault (Java as concept) that
Sun is pushing it in questionable ways. As for Perl, there is not even
anyone with a lot of money pushing it.
> Here is a simple exercise to illustrate what I am thinking about:
>
> 1. When you have closures and recursion, it is not strictly necessary to
> include explicit loop constructs in a programming language.
>
> 2. Java's inner classes are in fact a restricted variant of closures.
Questionable. Inner classes (or also anonymous classes) are more the
'closures' for data-structures and not so much for algorithms. They are
useful for creating small classes on the fly (but the interface needs to
be defined already which is an arbitrary limitation in my eyes).
> 3. To prove statement 1, implement a for loop in Java without using any
> explicit control structures (like for, while, etc.), but only with
> anonymous inner classes and recursion.
Ok, can do it in Perl (this should also give you an idea whether
closures are well integrated into Perl):
($sub = sub { print $_[0] || return;
$sub->($_[0] - 1) } )->(10);
This counts from 10 to 1.
But no one would do it this way. For simple count loops, an explicit
while or for is probably more natural. But in other situations it is
useful.
> This is possible, and you learn several facts about closures by doing
> this on your own.
>
> (Do the same exercise in any other language that has a better support
> for closures, and you have learned something about the clumsiness of
> Java. ;-)
Sure, Java's out here. This feature of passing code around is something
Java is seriously lacking.
>> All of this is already there in Perl, except perhaps the static vs.
>> dynamic typing thing since Perl5 is strictly dynamic. Perl6 will have
>> more means of statically typing variables. But I really don't understand
>> why one shouldn't be able to learn the concept of closures and
>> higher-order functions in Perl: In Perl each function is actually a
>> closure.
>
> It doesn't matter in the context of my argument whether Perl has these
> features or not. (But to note this again: I don't see the point when
> language designers try to include as much features as possible.
> Questions that are equally important include: Are these features well
> integrated? Do they follow some orthogonality principle? Is it easy for
> programmers to comprehend these features? Are they proven in practice? ...)
They are not as tightly integrated as they are in functional languages
such as ML or Lisp. But they are definitely proven in practice. The
basic concept is extremely easy:
my $sub_ref = sub {
# code of anonymous function follows here
};
$sub_ref->(@arguments); # called through the reference
They are some Perl functions that use it. Here the famous Schwartzian
transform:
@sorted = map { $_->[0] }
sort { $a->[1] cmp $b->[1]
||
$a->[2] <=> $b->[2] }
map { [ $_, split ] } @to_be_sorted;
Three times it is a snippet of code being the first argument to a
Perl-builtin. Also, it shows Perl's ability to work with lists in a
quite pleasant and lazy way.
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
Tassilo v. Parseval wrote:
> Also sprach Pascal Costanza:
>
>
>>Tassilo v. Parseval wrote:
>
>
>>My perception is that scripting languages like Perl all start to be
>>simplified languages that are boild down to the bare necessary features
>>that are perceived to be needed for a specific task. However, it always
>>turns out that you need a full-blown language sooner or later, no matter
>>what task you try to accomplish. So I am convinced it's always better to
>>start with "the real thing" right away.
>
>
> But then you might create a dogmatic monster that is interesting from a
> technical standpoint but not so much in practical use. I don't think
> Lisp is one, but some might say it's already on the edge.
Yes, human creativity is always faced with the possibility to fail. But
does this mean you shouldn't try? ;)
>>>So, in other words: A language must be unpopular and clumsy in order to
>>>teach good principles? Sure, in this concern Lisp is definitely the best
>>>teacher.
>>
>>I didn't say "clumsy". I think you are intentionally bending my argument.
>
>
> Was just too tempting. ;-)
:)
>>To rephrase your rhetorics: A language must be trendy and clumsy in
>>order to teach good principles? ;)
>>
>>My statement is: In order to learn good principles you have to study the
>>principles in the first place, not the languages!
>
> But this is not satisfactory from a pedagogical standpoint. It's easier
> to learn when there is some fun and perhaps even usefulness in the
> matter.
Agreed. (I have started to learn Common Lisp some months ago - and I can
tell you, this is really fun! ;-)
> So, there you are right. The tenor of that is: Learn more than one
> language.
Exactly - this is the essential idea I am trying to get across. And you
can definitely learn interesting things from languages that try to push
certain features to the extreme like, say, Scheme (-> continuations),
Haskell (-> lazy evaluation), Smalltalk (-> object orientation), Lisp ->
(data & code are the same), and so forth.
> The term 'hyped' was certainly not framed by me (was it you in the first
> place?).
Yes, I have used the term "hype", but I don't insist to do so. ;)
> I still think it is misplaced in thsi discussion. Either a
> language is useful or not. It's not Java's fault (Java as concept) that
> Sun is pushing it in questionable ways. As for Perl, there is not even
> anyone with a lot of money pushing it.
I disagree - programming languages always reflect the values and belief
systems of their designers. That's why there's always these flame wars
on them - languages are strongly entangled with social aspects. If they
were neutral (like, say, mathematical notation), we wouldn't have those
flame wars.
>>Here is a simple exercise to illustrate what I am thinking about:
>>
>>1. When you have closures and recursion, it is not strictly necessary to
>>include explicit loop constructs in a programming language.
>>
>>2. Java's inner classes are in fact a restricted variant of closures.
>
> Questionable. Inner classes (or also anonymous classes) are more the
> 'closures' for data-structures and not so much for algorithms. They are
> useful for creating small classes on the fly (but the interface needs to
> be defined already which is an arbitrary limitation in my eyes).
I am referring to the fact that inner classes close over the final
variables of their lexical scope.
>>3. To prove statement 1, implement a for loop in Java without using any
>>explicit control structures (like for, while, etc.), but only with
>>anonymous inner classes and recursion.
>
> Ok, can do it in Perl (this should also give you an idea whether
> closures are well integrated into Perl):
>
> ($sub = sub { print $_[0] || return;
> $sub->($_[0] - 1) } )->(10);
>
> This counts from 10 to 1.
>
> But no one would do it this way. For simple count loops, an explicit
> while or for is probably more natural. But in other situations it is
> useful.
...and how did you gain this knowledge? (nudge, nudge ;)
> Sure, Java's out here. This feature of passing code around is something
> Java is seriously lacking.
...and this is an example for a deliberate choice of Java's designers.
Heck, Guy Steele co-designed Java, and he was one of those who
discovered the similarity of closures and objecs!
Pascal
From: Erik Naggum
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3241641639682709@naggum.no>
* Pascal Costanza
| I disagree - programming languages always reflect the values and belief
| systems of their designers. That's why there's always these flame wars on them
| - languages are strongly entangled with social aspects. If they were neutral
| (like, say, mathematical notation), we wouldn't have those flame wars.
As if there were no flamewars over mathematic notation! Just look at the
history of the notation for derivation. Genii at war is no less pretty.
Note that only people who care, care enough to fight.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Pascal Costanza wrote:
>Why didn't Perl have these features
>in the first place, why were they added only later in its history?
Because things grow. There was no Genesis, "Pooff! And there was
programming." Instead, you get used to a certain way of doing things,
and these form an inspiration: wouldn't it be neat.... That's the way
technology evolves, and grows. Programming languages are not different
in that regard.
--
Bart.
From: Erik Naggum
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3241641923700143@naggum.no>
* Bart Lateur
| Because things grow. There was no Genesis, "Pooff! And there was
| programming." Instead, you get used to a certain way of doing things, and
| these form an inspiration: wouldn't it be neat.... That's the way technology
| evolves, and grows. Programming languages are not different in that regard.
But why does every creation have to start at Day 1? The whole point with
this learning from the experience of others thing is to pick up where the
other guy went to take his rest after version 6 to behold his creation and
see that it is good.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On Sat, 21 Sep 2002 13:20:25 -0300, Pascal Costanza wrote:
>
> It doesn't matter in the context of my argument whether Perl has these
> features or not. (But to note this again: I don't see the point when
> language designers try to include as much features as possible.
> Questions that are equally important include: Are these features well
> integrated? Do they follow some orthogonality principle? Is it easy for
> programmers to comprehend these features? Are they proven in practice?
> ...)
>
> Pascal
Perl is an incredible scripting programming language, it allows for real
short programs.
For instance, here's a 163 lines implementation for the
Lambda function, with which to add 1+1 (yielding 2 as the answer). The
Lambda function, by the way, is an useless feature which receives a lot
of hype. Almost any CS student will confirm that.
http://perl.plover.com/lambda/
Cheers,
Henry
--
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
s> Perl is an incredible scripting programming language, it allows for real
s> short programs.
and real long ones too. the myth that perl is only for small programs is
just a myth.
s> For instance, here's a 163 lines implementation for the
s> Lambda function, with which to add 1+1 (yielding 2 as the answer). The
s> Lambda function, by the way, is an useless feature which receives a lot
s> of hype. Almost any CS student will confirm that.
s> http://perl.plover.com/lambda/
you don't get what he did. i won't bother to explain the joke either.
and if you don't understand the importance of lambda calculus, try
reading godel, escher, bach a few more times.
uri
--
Uri Guttman ------ ···@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
synthespian wrote:
> Perl is an incredible scripting programming language, it allows for real
> short programs.
> For instance, here's a 163 lines implementation for the
> Lambda function, with which to add 1+1 (yielding 2 as the answer). The
> Lambda function, by the way, is an useless feature which receives a lot
> of hype. Almost any CS student will confirm that.
>
>
> http://perl.plover.com/lambda/
So?
Pascal
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> I find such statements very strange. Why didn't Perl have these features
> in the first place, why were they added only later in its history? In
> fact, the concepts have been known long before. Why didn't people use a
> language that had all these features in the first place?
Because they couldn't get their work done.
> Why do they wait for Perl to include them? Obviously, they are needed, otherwise Perl would _not_ include them.
We didn't wait. We used Perl to solve problems Perl was good for solving,
and as we did we thought "this would be easier if we had better language
support".
[Please don't misinterpret my use of "we" to mean that I had any part in
implementing Perl. By "we" I meant the community of Perl users and developers.]
>
> My perception is that scripting languages like Perl all start to be
> simplified languages that are boild down to the bare necessary features
> that are perceived to be needed for a specific task. However, it always
> turns out that you need a full-blown language sooner or later, no matter
> what task you try to accomplish. So I am convinced it's always better to
> start with "the real thing" right away.
I can't think of a single successful language that hasn't changed
extensively since it's introduction.
> Here is a simple exercise to illustrate what I am thinking about:
>
> 1. When you have closures and recursion, it is not strictly necessary to
> include explicit loop constructs in a programming language.
So what? The vast majority of programmers find iteration easier
to understand. Sure, we can compute anything using recursive functions.
We could also compute anything with a Turing machine. But the weight
of 50 years of computing shows that most people are more comfortable
with imperative programming.
> It doesn't matter in the context of my argument whether Perl has these
> features or not. (But to note this again: I don't see the point when
> language designers try to include as much features as possible.
> Questions that are equally important include: Are these features well
> integrated? Do they follow some orthogonality principle? Is it easy for
> programmers to comprehend these features? Are they proven in practice? ...)
Those questions are not equally important. The last two are the only
two of any importance for programmers trying to deliver useful systems.
Kevin Cline wrote:
> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
>>My perception is that scripting languages like Perl all start to be
>>simplified languages that are boild down to the bare necessary features
>>that are perceived to be needed for a specific task. However, it always
>>turns out that you need a full-blown language sooner or later, no matter
>>what task you try to accomplish. So I am convinced it's always better to
>>start with "the real thing" right away.
>
> I can't think of a single successful language that hasn't changed
> extensively since it's introduction.
So?
>>Here is a simple exercise to illustrate what I am thinking about:
>>
>>1. When you have closures and recursion, it is not strictly necessary to
>>include explicit loop constructs in a programming language.
>
> So what? The vast majority of programmers find iteration easier
> to understand. Sure, we can compute anything using recursive functions.
> We could also compute anything with a Turing machine. But the weight
> of 50 years of computing shows that most people are more comfortable
> with imperative programming.
You're citing me out of context. I don't propose to remove iteration
constructs from any language, I totally agree that they are very useful.
However, you will get a much better understanding of how programming
languages work when you try to implement such constructs on your own on
top of pure recursion. That's all.
Please remember two things: (1) We're talking about how to become a
better programmer, not about how to become an average programmer. (2)
There is a reason why you are able to choose one language over others.
Don't try to convince other people that your choice is the right one,
but try to enable them to make a choice of their own.
>>It doesn't matter in the context of my argument whether Perl has these
>>features or not. (But to note this again: I don't see the point when
>>language designers try to include as much features as possible.
>>Questions that are equally important include: Are these features well
>>integrated? Do they follow some orthogonality principle? Is it easy for
>>programmers to comprehend these features? Are they proven in practice? ...)
>
> Those questions are not equally important. The last two are the only
> two of any importance for programmers trying to deliver useful systems.
It's arguable that good integration and orthogonality lead to
comprehensibility and maintainability.
Pascal
Kevin Cline wrote:
> So what? The vast majority of programmers find iteration easier
> to understand. Sure, we can compute anything using recursive functions.
> We could also compute anything with a Turing machine. But the weight
> of 50 years of computing shows that most people are more comfortable
> with imperative programming.
Those who are only comfortable with imperative programming
should find something else to do with their lives. They
are not good programmers, because there are some easily
solvable problems they will struggle with.
Imperative programming is fine for some problems
but it's clearly suboptimal for others. For those problems
it's suboptimal for, other techniques -- recursion, higher
order functions, non-strictness, search, pattern matching,
object orientation, etc. -- might be called for and these are all
part of a good programmer's repertoire. Designers of general
purpose languages should ideally include /all/ of these, in
order to give programmers /the choice/ of which to use,
instead of restricting the feature set to prevent weak
programmers from shooting themselves in the foot.
And enough of this "all languages are equivalent" nonsense.
Is Java 1.0 as good as Java 1.2? Is Perl 4 as good as
Perl 6? Is Lisp 1.5 as good as Common Lisp? Of course not.
And now, some Lisp. Here's factorial, three different
ways:
(defun fac (n)
(if (zerop n)
1
(* n (fac (1- n)))))
(defun fac (n)
(do ((i n (1- i))
(result 1 (* i result)))
((= i 1) result)))
(defun fac (n)
(collect-sum (scan-range :from 1 :upto n)))
I'll leave you to sort those solutions by elegance.
My point is not about Lisp /per se/, it's about the
benefits of supporting multiple ways of solving problems.
(NB I have not tested the third solution, only proven it.)
> > It doesn't matter in the context of my argument whether Perl has these
> > features or not. (But to note this again: I don't see the point when
> > language designers try to include as much features as possible.
> > Questions that are equally important include: Are these features well
> > integrated? Do they follow some orthogonality principle? Is it easy for
> > programmers to comprehend these features? Are they proven in practice? ...)
>
> Those questions are not equally important. The last two are the only
> two of any importance for programmers trying to deliver useful systems.
I disagree strongly that features should necessarily be easily
comprehended. The test should be: Does knowing the feature make
the problem easier to solve? If yes, then it's a good feature
for that problem.
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
[ Newsgroups trimmed ]
··········@mailandnews.com (Software Scavenger) writes:
> Donald Fisk <················@enterprise.net> wrote in message news:<·················@enterprise.net>...
> > (defun fac (n)
> > (if (zerop n)
> > 1
> > (* n (fac (1- n)))))
> >
> > (defun fac (n)
> > (do ((i n (1- i))
> > (result 1 (* i result)))
> > ((= i 1) result)))
> >
> > (defun fac (n)
> > (collect-sum (scan-range :from 1 :upto n)))
>
> (defun fac (n)
> (apply '* (iota n)))
Hmm. I don't know about elegance, but I will note in passing that only
the first definition of fac is in fac correct... all of the others
will fail on (FAC 0).
I haven't tested the SCAN version either, but it looks to me that it's
computing triangular numbers, not factorials.
Cheers,
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
>
> [ Newsgroups trimmed ]
>
> ··········@mailandnews.com (Software Scavenger) writes:
> > Donald Fisk <················@enterprise.net> wrote in message news:<·················@enterprise.net>...
> > > (defun fac (n)
> > > (if (zerop n)
> > > 1
> > > (* n (fac (1- n)))))
> > >
> > > (defun fac (n)
> > > (do ((i n (1- i))
> > > (result 1 (* i result)))
> > > ((= i 1) result)))
> > >
> > > (defun fac (n)
> > > (collect-sum (scan-range :from 1 :upto n)))
> >
> > (defun fac (n)
> > (apply '* (iota n)))
>
> Hmm. I don't know about elegance, but I will note in passing that only
> the first definition of fac is in fac correct... all of the others
> will fail on (FAC 0).
I should have been more careful before I posted:
(defun fac (n)
(do ((i n (1- i))
(result 1 (* i result)))
((or (= i 1) (= i 0)) result)))
> I haven't tested the SCAN version either, but it looks to me that it's
> computing triangular numbers, not factorials.
Yes. Maybe I shouldn't post when I'm tired. collect-product
does what I want (but it might still need a test for n=0 before
calling it).
I think you have to define iota before you use it.
> Christophe
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
To this
> (defun fac (n)
> (apply '* (iota n)))
from cubicle584, I add
(defun fac(n)
(apply '*
(maplist (lambda(ones)(apply '+ ones))
(fill (make-list n) 1))))
;-)
Alan Crowe
From: Tim Bradshaw
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <ey3d6qrquhj.fsf@cley.com>
* Alan S Crowe wrote:
> To this
>> (defun fac (n)
>> (apply '* (iota n)))
> from cubicle584, I add
> (defun fac(n)
> (apply '*
> (maplist (lambda(ones)(apply '+ ones))
> (fill (make-list n) 1))))
Both of these solutions have exciting defects: they apply a function
to a potentially very large number of arguments, which will not work.
This is what REDUCE is for.
--tim
From: Lieven Marchand
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <861y79wdqb.fsf@just.fgov.be>
Donald Fisk <················@enterprise.net> writes:
> (defun fac (n)
> (collect-sum (scan-range :from 1 :upto n)))
> (NB I have not tested the third solution, only proven it.)
I'd suggest collect-product, or for maximum obfuscation
(exp (collect-sum (scan-range :from 1 :upto n)))
--
Never argue with a fool in public. People might not see the difference.
Tassilo v. Parseval:
[...]
>As for Java, Java nowadays is certainly rather used as a language for
>big projects and general programming. When programming Java, it feels
>anything but designed for embedded devices.
Because it's a high-level language? I'd say that if the embedded
devices these days can deal with what Java programmers throw at them,
why not? There seem to be some nifty development tools and JVMs out
there for embedded devices. Once you go back to less abstract
languages like C you get the usual advantages and disadvantages. Not
necessarily a bad thing, but also not automatically better.
[...]
fup2 comp.lang.java.advocacy
But feel free to ignore, you're probably not reading that group and
neither am I (yet).
Regards,
Marco
--
Please reply in the newsgroup, not by email!
Java programming tips: http://jiu.sourceforge.net/javatips.html
Other Java pages: http://www.geocities.com/marcoschmidt.geo/java.html
"Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
>
> Generics is not just a different name for templates, but generics and
> templates are two different concepts that share some similarities.
Correct.
> Therefore, templates are Turing-complete, generics are not.
A language is said to be "Turing complete" if it can calculate all
the things that a Turing machine can. This has nothing to do with
generics or templates, neither of which is in the least required for,
or even related to, Turing completeness.
> Java has been developed explicitly for embedded devices and for the web.
Java is a general purpose programming language. There is nothing in the
language or the core API that in any way suggests embedded use.
> No one can guarantee you that Java, Perl or similar languages are still
> alive in, say, five or ten years. But those concepts will definitely endure.
I will personally guarantee that Java and Perl will both be alive in ten years.
Hell, even Fortran will still be alive in ten years.
I just went to dice.com, an excellent classified site for programming jobs.
I gave it a few different queries:
"java programmer" got 400+ results
"c++ programmer" got 300+ results
"perl programmer" got 200+ results
"lisp programmer" got exactly zero results
> So for example, learning Common Lisp might buy you much more, because it
> includes a wealth of ideas and concepts that steadily change your view
> of the world. This will increase your flexibility in solving concrete
> problems, whether you use Common Lisp in practice or not.
I agree. Lisp is an important language, despite the fact that it has
relatively little commercial impact. It seems to me that this point can
be made effectively without bashing Java or Perl.
Marshall
From: Kaz Kylheku
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <amib03$13a$1@luna.vcn.bc.ca>
In article <·······················@rwcrnsc52.ops.asp.att.net>, Marshall
Spight wrote:
> Java is a general purpose programming language. There is nothing in the
> language or the core API that in any way suggests embedded use.
Java is the predominant systems programming language on the
Java oper^H^H^H^Hplatform.
>> No one can guarantee you that Java, Perl or similar languages are still
>> alive in, say, five or ten years. But those concepts will definitely endure.
>
> I will personally guarantee that Java and Perl will both be alive in ten years.
> Hell, even Fortran will still be alive in ten years.
>
> I just went to dice.com, an excellent classified site for programming jobs.
> I gave it a few different queries:
>
> "java programmer" got 400+ results
> "c++ programmer" got 300+ results
> "perl programmer" got 200+ results
> "lisp programmer" got exactly zero results
Right; so if you want to learn programming just for the sake of job security,
it's useful to know Java, C++ and Perl. No question about it! Every senior CS
undergrad knows that he or she must know at least two out of these three
to land a job soon after graduation day.
But consider that there are people looking for Lisp jobs. Some of those C++,
Java or Perl programmers would rather be programming in Lisp; they have settled
for these jobs just to pay their bills, and have to compete for attention
against a horde of job-security-motivated mediocrites.
One day, you may be your own boss, and you will have to decide what tools to
use for a project. You might need a few others to complete your team. From
that point of view, matters will probably look a little different. You will
probably not care what programming language provides the most job security,
because you will not want to work with people who are in it for job security.
If you have an ounce of intelligence, you will use the programming language
with the greatest technical qualifications, and work with the most capable
programmers. Rather than, say, the most replaceable programmers.
> I agree. Lisp is an important language, despite the fact that it has
> relatively little commercial impact. It seems to me that this point can
> be made effectively without bashing Java or Perl.
Sometimes effectiveness claims a little collateral damage. ;)
From: Duane Rettig
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <4elbnjika.fsf@beta.franz.com>
"Marshall Spight" <·······@dnai.com> writes:
> "Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
> >
> > No one can guarantee you that Java, Perl or similar languages are still
> > alive in, say, five or ten years. But those concepts will definitely endure.
>
> I will personally guarantee that Java and Perl will both be alive in ten years.
> Hell, even Fortran will still be alive in ten years.
I tend to agree with you. Languages that have legacy code tend
not to die.
> I just went to dice.com, an excellent classified site for programming jobs.
> I gave it a few different queries:
>
> "java programmer" got 400+ results
> "c++ programmer" got 300+ results
> "perl programmer" got 200+ results
> "lisp programmer" got exactly zero results
I'm assuming you look at these results and think "Well, Lisp must
have no job activity", or "Lisp must have no market". I know
better, because my company makes its bread and butter from Common
Lisp exclusively, so when I look at these numbers I think "What are
the java, c++, and perl shops doing wrong that they can't keep their
programmers?", or else "Why does it take so many java, c++, or perl
programmers to do the same jobs that just a couple of good Lisp
programmers can do?"
> > So for example, learning Common Lisp might buy you much more, because it
> > includes a wealth of ideas and concepts that steadily change your view
> > of the world. This will increase your flexibility in solving concrete
> > problems, whether you use Common Lisp in practice or not.
>
> I agree. Lisp is an important language, despite the fact that it has
> relatively little commercial impact. It seems to me that this point can
> be made effectively without bashing Java or Perl.
It's interesting that you use Lisp bashing yourself (i.e., by using the
unsubstantiated phrase "relatively little commercial impact") to make
your own point.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes [in part]:
> ... "Why does it take so many java, c++, or perl
> programmers to do the same jobs that just a couple of good Lisp
> programmers can do?"
my experience with all the above languages is that given good enough
programmers, the numbers are about even in development time.
oz
---
bang go the blobs. -- ponder stibbons
From: Duane Rettig
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <4elbm20c8.fsf@beta.franz.com>
ozan s yigit <··@blue.cs.yorku.ca> writes:
> Duane Rettig <·····@franz.com> writes [in part]:
>
> > ... "Why does it take so many java, c++, or perl
> > programmers to do the same jobs that just a couple of good Lisp
> > programmers can do?"
>
> my experience with all the above languages is that given good enough
> programmers, the numbers are about even in development time.
I won't argue experiences here. You have your experiences, and I have
mine. Trying to discuss testimonials plunges this discussion deeper
into the depths of a religious argument than it has been already.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Trying to discuss testimonials plunges this discussion deeper
> into the depths of a religious argument than it has been already.
kent pitman once pointed out the usefulness of testimonials, such as
yours and mine. i have not offered it for argument, just for the record.
it is getting tedious to keep hearing about what average programmers can
and cannot do given a half-decent language. evidently most cannot program
their way out of a paper computer. i'm sure there is something to be said
for such programmers no longer working with lisp and the results
appearent to a lisp vendor would reflect that.
oz
--
a nought, an ought, a knot, a not easily perceived distinction. -- t. duff
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> "Marshall Spight" <·······@dnai.com> writes:
>
> > "Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
> > >
> > I just went to dice.com, an excellent classified site for programming jobs.
> > I gave it a few different queries:
> >
> > "java programmer" got 400+ results
> > "c++ programmer" got 300+ results
> > "perl programmer" got 200+ results
> > "lisp programmer" got exactly zero results
>
> I'm assuming you look at these results and think "Well, Lisp must
> have no job activity", or "Lisp must have no market".
No. I know there are commercial projects going on that use Lisp. But
they are outnumbered by projects being done is C++ or Java.
Does this say anything about the relative merits of these three languages?
No. It is a statement about their popularity.
> So when I look at these numbers I think "What are
> the java, c++, and perl shops doing wrong that they can't keep their
> programmers?", or else "Why does it take so many java, c++, or perl
> programmers to do the same jobs that just a couple of good Lisp
> programmers can do?"
Nothing about those numbers gives any information about any correlation
between language choice and keeping programmers. Nothing about that
information says anything about the relative productivity of programmers
based on language choice. It was a list of job openings, nothing more.
I brought it up to refute the suggestion that Java or Perl are going away soon,
which I believe it did quite effectively.
> > I agree. Lisp is an important language, despite the fact that it has
> > relatively little commercial impact. It seems to me that this point can
> > be made effectively without bashing Java or Perl.
>
> It's interesting that you use Lisp bashing yourself (i.e., by using the
> unsubstantiated phrase "relatively little commercial impact") to make
> your own point.
I think the numbers I provided earlier in the post substantiated my claim
of "relatively little commercial impact" quite nicely and succinctly. I
do not consider this Lisp bashing in the least. Just as I believe that Java
and Perl's being popular does not make them good, I likewise believe
that Lisp's being unpopular does not make it bad. I believe popularity
and goodness to be independent. I also believe, and have provided some
documentation supporting, that Lisp has relatively little commercial
impact. I would be happy to have access to further documentation of
Lisp's relative commercial impact; perhaps you can supply some?
Marshall
From: Duane Rettig
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <4it0y20lx.fsf@beta.franz.com>
"Marshall Spight" <·······@dnai.com> writes:
> "Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> > "Marshall Spight" <·······@dnai.com> writes:
> >
> > > "Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
> > > >
> > > I just went to dice.com, an excellent classified site for programming jobs.
> > > I gave it a few different queries:
> > >
> > > "java programmer" got 400+ results
> > > "c++ programmer" got 300+ results
> > > "perl programmer" got 200+ results
> > > "lisp programmer" got exactly zero results
> >
> > I'm assuming you look at these results and think "Well, Lisp must
> > have no job activity", or "Lisp must have no market".
>
> No. I know there are commercial projects going on that use Lisp. But
> they are outnumbered by projects being done is C++ or Java.
> Does this say anything about the relative merits of these three languages?
> No. It is a statement about their popularity.
Correct, and you should have said what you had meant in that article
(you make no mention of popularity in that article, but you do mention
commercial impact - perhaps you just forgot to mention it?)
I can deal with popularity, or the lack of it. As a nerd in grammar
and high schools, I was never popular, but that wasn't important to
me most of the time, and I learned at those times when it seemed
important to me to stay true to myself and to ignore the issue of
popularity. As I grew up it became clear to me that popularity had
nothing to do with success, even though it seemed to define success
at the time. Just ask the dot-com-ers who lost their shirts how
important the popularity of the dot-com industry was to them.
> > So when I look at these numbers I think "What are
> > the java, c++, and perl shops doing wrong that they can't keep their
> > programmers?", or else "Why does it take so many java, c++, or perl
> > programmers to do the same jobs that just a couple of good Lisp
> > programmers can do?"
>
> Nothing about those numbers gives any information about any correlation
> between language choice and keeping programmers. Nothing about that
> information says anything about the relative productivity of programmers
> based on language choice. It was a list of job openings, nothing more.
Precisely. Without any background about those statistics, they say
absolutely nothing at all.
> I brought it up to refute the suggestion that Java or Perl are going away soon,
> which I believe it did quite effectively.
You ended a paragraph demonstrating that these numbers say nothing by
implying that these numbers say something about longevity. They do
not. Your belief (that you demonstrated your first point effectively)
is unfounded.
> > > I agree. Lisp is an important language, despite the fact that it has
> > > relatively little commercial impact. It seems to me that this point can
> > > be made effectively without bashing Java or Perl.
> >
> > It's interesting that you use Lisp bashing yourself (i.e., by using the
> > unsubstantiated phrase "relatively little commercial impact") to make
> > your own point.
>
> I think the numbers I provided earlier in the post substantiated my claim
> of "relatively little commercial impact" quite nicely and succinctly. I
> do not consider this Lisp bashing in the least.
Of course not. The lisp bashing was that you jumped incorrectly from a
set of numbers to a conclusion about the commercial impact of a
language.
> Just as I believe that Java
> and Perl's being popular does not make them good, I likewise believe
> that Lisp's being unpopular does not make it bad. I believe popularity
> and goodness to be independent.
I agree completely here.
> I also believe, and have provided some
> documentation supporting, that Lisp has relatively little commercial
> impact.
I disagree here.
> I would be happy to have access to further documentation of
> Lisp's relative commercial impact; perhaps you can supply some?
No more than I supply every time I post (hint: see below, and then
search visually for the cue: "Success")
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> "Marshall Spight" <·······@dnai.com> writes:
>
> > Nothing about those numbers gives any information about any correlation
> > between language choice and keeping programmers. Nothing about that
> > information says anything about the relative productivity of programmers
> > based on language choice. It was a list of job openings, nothing more.
>
> Precisely. Without any background about those statistics, they say
> absolutely nothing at all.
They say one thing: they reflect how many jobs are available requiring
the given programming language. That's a long way from "nothing."
Perhaps you are somehow affronted by the low numbers for Lisp. Perhaps
you can supply me a web site I could go to that would show lots of Lisp
job-wanted listings? More data points are better than fewer. If you have
actual statistics we could use, that would be good. Just saying the statistics
I have don't count isn't constructive.
Getting hard numbers for these kinds of things is difficult. Ideally, one
would poll each professional computer programmer in the country and
ask them what language(s) they are working with currently. Since that
would be prohibitive, we necessarily have to use less comprehensive
techniques. I like checking job-wanted listings, because I believe it's
the most revelant factor for determining what's important now. Certainly
COBOL is underrepresented in some way; there are lots of installed
COBOL applications that are not reflected in upcoming jobs. But I
don't care about that; I care more about where things are going than
where they are coming from.
> > I brought it up to refute the suggestion that Java or Perl are going away soon,
> > which I believe it did quite effectively.
>
> You ended a paragraph demonstrating that these numbers say nothing by
> implying that these numbers say something about longevity. They do
> not. Your belief (that you demonstrated your first point effectively)
> is unfounded.
Well, it didn't convince *you* anyway. But to me, those numbers need
little or no interpretation.
Let me see if I understand your contention: you are saying that the
current number of job postings for a given programming language
say *nothing* about its expected longevity. The programming language
in the #1 spot could disappear in short order.
Has this ever happened, do you think? I kinda don't think it has.
> > > > I agree. Lisp is an important language, despite the fact that it has
> > > > relatively little commercial impact. It seems to me that this point can
> > > > be made effectively without bashing Java or Perl.
> > >
> > > It's interesting that you use Lisp bashing yourself (i.e., by using the
> > > unsubstantiated phrase "relatively little commercial impact") to make
> > > your own point.
> >
> > I think the numbers I provided earlier in the post substantiated my claim
> > of "relatively little commercial impact" quite nicely and succinctly. I
> > do not consider this Lisp bashing in the least.
>
> Of course not. The lisp bashing was that you jumped incorrectly from a
> set of numbers to a conclusion about the commercial impact of a
> language.
There are *very* few Lisp jobs available compared to the number of C++,
Java, or Perl programming jobs available. I consider the number of jobs
available to be closely tied to the commercial impact of a language.
So, how would YOU estimate the commercial success of one language
relative to another? Note that to do that, you have to come up with something
that gives numbers for at least two different languages.
> > I also believe, and have provided some
> > documentation supporting, that Lisp has relatively little commercial
> > impact.
>
> I disagree here.
>
> > I would be happy to have access to further documentation of
> > Lisp's relative commercial impact; perhaps you can supply some?
>
> No more than I supply every time I post (hint: see below, and then
> search visually for the cue: "Success")
So you have had some success; that's great. I applaud you. I am happy
every time I hear about someone in my industry (software) making a
good living doing what they love.
But those weren't *relative* numbers. I specifically said "documentation
of Lisp's relative commercial impact."
Marshall
From: Duane Rettig
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <4adma1j4h.fsf@beta.franz.com>
"Marshall Spight" <·······@dnai.com> writes:
> "Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> > "Marshall Spight" <·······@dnai.com> writes:
> >
> > > Nothing about those numbers gives any information about any correlation
> > > between language choice and keeping programmers. Nothing about that
> > > information says anything about the relative productivity of programmers
> > > based on language choice. It was a list of job openings, nothing more.
> >
> > Precisely. Without any background about those statistics, they say
> > absolutely nothing at all.
>
> They say one thing: they reflect how many jobs are available requiring
> the given programming language. That's a long way from "nothing."
The report I looked at had a disclaimer that said that the data reflects
public information posted by dice.com customers and users. It is thus
self-selecting and not statistically accurate. But even if it were
accurate, what those numbers represent are going to be whatever
you decide they mean.
> Perhaps you are somehow affronted by the low numbers for Lisp.
Not at all. Low numbers for Lisp are a given. Some people absolutely
hate Lisp, and have never forgiven it of its involvement in the AI hype
(and subsequent crash) in the late 80's. A lot of money was involved,
and the wounds still run deep in the hearts of some managers.
> Perhaps
> you can supply me a web site I could go to that would show lots of Lisp
> job-wanted listings? More data points are better than fewer. If you have
> actual statistics we could use, that would be good. Just saying the statistics
> I have don't count isn't constructive.
If you really care, then Google is your friend. If you don't really
care, but are just trying to prove a point, then sorry, but you're on
your own.
> Getting hard numbers for these kinds of things is difficult. Ideally, one
> would poll each professional computer programmer in the country and
> ask them what language(s) they are working with currently. Since that
> would be prohibitive, we necessarily have to use less comprehensive
> techniques. I like checking job-wanted listings, because I believe it's
> the most revelant factor for determining what's important now. Certainly
> COBOL is underrepresented in some way; there are lots of installed
> COBOL applications that are not reflected in upcoming jobs. But I
> don't care about that; I care more about where things are going than
> where they are coming from.
Ah, yes, let's look where it's easier. I'm reminded of a story of a
man happening upon a drunk underneath a streetlight, obviously searching
for something. The man asked the drunk what he was looking for and the
drunks said "My wallet - I dropped it a block and a half back that way".
Confused, the man asked "Then why are you looking for it here?", to which
the drunk replied "There's more light here".
> > > I brought it up to refute the suggestion that Java or Perl are going away soon,
> > > which I believe it did quite effectively.
> >
> > You ended a paragraph demonstrating that these numbers say nothing by
> > implying that these numbers say something about longevity. They do
> > not. Your belief (that you demonstrated your first point effectively)
> > is unfounded.
>
> Well, it didn't convince *you* anyway. But to me, those numbers need
> little or no interpretation.
I won't try to convince you otherwise, because you've obviously made
up your mind.
> Let me see if I understand your contention: you are saying that the
> current number of job postings for a given programming language
> say *nothing* about its expected longevity. The programming language
> in the #1 spot could disappear in short order.
>
> Has this ever happened, do you think? I kinda don't think it has.
Maybe you are confusing me with someone else. In a previous article
on this thread, you said:
| > I will personally guarantee that Java and Perl will both be alive in ten years.
| > Hell, even Fortran will still be alive in ten years.
And I replied:
| I tend to agree with you. Languages that have legacy code tend
| not to die.
Why are you bringing this back up? What do languages' popularity or
comercial success have to do with their longevity?
> So, how would YOU estimate the commercial success of one language
> relative to another? Note that to do that, you have to come up with something
> that gives numbers for at least two different languages.
I wouldn't. See below.
> > > I would be happy to have access to further documentation of
> > > Lisp's relative commercial impact; perhaps you can supply some?
> >
> > No more than I supply every time I post (hint: see below, and then
> > search visually for the cue: "Success")
>
> So you have had some success; that's great. I applaud you. I am happy
> every time I hear about someone in my industry (software) making a
> good living doing what they love.
It doesn't look like you really went to where I pointed you to (or perhaps
you didn't really read it), so I'll make it explicit for you: Go to
http://www.franz.com/success/ and read, not about our successes, but
the successes of some of our _customers_.
> But those weren't *relative* numbers. I specifically said "documentation
> of Lisp's relative commercial impact."
Let's look at what you really said:
| I agree. Lisp is an important language, despite the fact that it has
| relatively little commercial impact. It seems to me that this point can
| be made effectively without bashing Java or Perl.
Now, perhaps you really could have meant commercial success "relative to
other languages", but you certainly didn't say that; indeed you _precluded_
the comparison with Java or Perl, which were two of the languages in
the survey you quoted.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Marshall Spight
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <fdsj9.37669$gA4.5659@sccrnsc02>
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> "Marshall Spight" <·······@dnai.com> writes:
>
> The report I looked at had a disclaimer that said that the data reflects
> public information posted by dice.com customers and users. It is thus
> self-selecting and not statistically accurate. But even if it were
> accurate, what those numbers represent are going to be whatever
> you decide they mean.
Is your contention then "nothing can be said about the relative number
of jobs available for Java, Lisp, etc?" I agree that the exact number
cannot easily be found, but I assert that rough estimates can
be made effectively.
> Not at all. Low numbers for Lisp are a given.
Well okay then.
> > Perhaps
> > you can supply me a web site I could go to that would show lots of Lisp
> > job-wanted listings? More data points are better than fewer. If you have
> > actual statistics we could use, that would be good. Just saying the statistics
> > I have don't count isn't constructive.
>
> If you really care, then Google is your friend. If you don't really
> care, but are just trying to prove a point, then sorry, but you're on
> your own.
As far as trying to estimate the actual relative number, of course I'm
on my own, because no one besides me has supplied any numbers
or suggested any methodology for finding any numbers.
Although you mention Google; maybe that's meant to imply a methodology.
Google hits for "java jobs": about 1,270,000
Google hits for "lisp jobs": about 55,200
Looks like Lisp has *relatively* *fewer* jobs available.
> Ah, yes, let's look where it's easier. I'm reminded of a story of a
> man happening upon a drunk underneath a streetlight, obviously searching
> for something.
Again you bash my methodology but supply nothing of your own.
> I won't try to convince you otherwise, because you've obviously made
> up your mind.
I've invited you to provide further data but you've declined. I've looked at
what evidence is available and drawn a conclusion. Sue me.
If presented with contradictory data, I reserve the right to alter my initial
conclusion.
> Why are you bringing this back up? What do languages' popularity or
> comercial success have to do with their longevity?
Commercial success and longevity are closely correlated. But maybe
longevity is a canard. Does any 3GL language, no matter how bad, ever die?
Cobol and BASIC are alive and kicking.
> > So, how would YOU estimate the commercial success of one language
> > relative to another? Note that to do that, you have to come up with something
> > that gives numbers for at least two different languages.
>
> I wouldn't. See below.
Well then why are you taking such exception to my attempts at doing so?
It seems perverse.
> > But those weren't *relative* numbers. I specifically said "documentation
> > of Lisp's relative commercial impact."
>
> Let's look at what you really said:
>
> | I agree. Lisp is an important language, despite the fact that it has
> | relatively little commercial impact. It seems to me that this point can
> | be made effectively without bashing Java or Perl.
>
> Now, perhaps you really could have meant commercial success "relative to
> other languages", but you certainly didn't say that; indeed you _precluded_
> the comparison with Java or Perl, which were two of the languages in
> the survey you quoted.
Well of *course* I meant relative to other languages! That's why I used the
word "relatively!" The only thing I was trying to preclude was bashing, not
comparing numbers.
Let me try my statement again, and see if it works better for you the new way:
"Lisp is an important language, despite the fact that it has little commercial
impact relative to other languages, such as Java and Perl."
I'm guessing you won't like this one any better.
Marshall
From: Duane Rettig
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <4fzw1yyjb.fsf@beta.franz.com>
"Marshall Spight" <·······@dnai.com> writes:
> "Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> > "Marshall Spight" <·······@dnai.com> writes:
> >
> > The report I looked at had a disclaimer that said that the data reflects
> > public information posted by dice.com customers and users. It is thus
> > self-selecting and not statistically accurate. But even if it were
> > accurate, what those numbers represent are going to be whatever
> > you decide they mean.
>
> Is your contention then "nothing can be said about the relative number
> of jobs available for Java, Lisp, etc?" I agree that the exact number
> cannot easily be found, but I assert that rough estimates can
> be made effectively.
Not for Lisp. Already answered here:
> > Not at all. Low numbers for Lisp are a given.
>
> Well okay then.
Glad we agree.
> > > Perhaps
> > > you can supply me a web site I could go to that would show lots of Lisp
> > > job-wanted listings? More data points are better than fewer. If you have
> > > actual statistics we could use, that would be good. Just saying the statistics
> > > I have don't count isn't constructive.
> >
> > If you really care, then Google is your friend. If you don't really
> > care, but are just trying to prove a point, then sorry, but you're on
> > your own.
>
> As far as trying to estimate the actual relative number, of course I'm
> on my own, because no one besides me has supplied any numbers
> or suggested any methodology for finding any numbers.
Why do you want a number? I'll give you a number: .175 (how's that for
a number)? It means as much as those other numbers you published. Why
do you think that any other numbers would be more meaningful?
> Although you mention Google; maybe that's meant to imply a methodology.
>
> Google hits for "java jobs": about 1,270,000
> Google hits for "lisp jobs": about 55,200
>
> Looks like Lisp has *relatively* *fewer* jobs available.
Very good, you're finally doing your homework. 55,200 is just a number,
just as useless without analysis as any other number, but it's also a
long way from zero. That may also mean nothing to you, but it certainly
leads me to suspect that your "excellent" dice.com is something less than
that.
> > Ah, yes, let's look where it's easier. I'm reminded of a story of a
> > man happening upon a drunk underneath a streetlight, obviously searching
> > for something.
>
> Again you bash my methodology but supply nothing of your own.
Now you're talking in circles. Just above, you took my sugestion as
an implication of a methodology. Even if it hadn't been such, how
can you take that as "nothing"?
> > I won't try to convince you otherwise, because you've obviously made
> > up your mind.
>
> I've invited you to provide further data but you've declined. I've looked at
> what evidence is available and drawn a conclusion. Sue me.
My, my, aren't we getting testy here? Why would I care enough about your
conclusions to sue you? I only care just barely enough about your
conclusions to correct you, and even that desire is getting pretty
thin.
> > Why are you bringing this back up? What do languages' popularity or
> > comercial success have to do with their longevity?
>
> Commercial success and longevity are closely correlated. But maybe
> longevity is a canard. Does any 3GL language, no matter how bad, ever die?
> Cobol and BASIC are alive and kicking.
There you go again, arguing in circles. First, you argue against my
rhetorical, and then you shoot your own argument down? Perhaps I should
just stay out of this argument and let you argue with yourself. Tell me
who wins. :-)
> > > So, how would YOU estimate the commercial success of one language
> > > relative to another? Note that to do that, you have to come up with something
> > > that gives numbers for at least two different languages.
> >
> > I wouldn't. See below.
>
> Well then why are you taking such exception to my attempts at doing so?
> It seems perverse.
Call me perverse, then. I'm still wondering why you want such numbers,
as if there has to be one winner, and all the rest are losers.
> > > But those weren't *relative* numbers. I specifically said "documentation
> > > of Lisp's relative commercial impact."
> >
> > Let's look at what you really said:
> >
> > | I agree. Lisp is an important language, despite the fact that it has
> > | relatively little commercial impact. It seems to me that this point can
> > | be made effectively without bashing Java or Perl.
> >
> > Now, perhaps you really could have meant commercial success "relative to
> > other languages", but you certainly didn't say that; indeed you _precluded_
> > the comparison with Java or Perl, which were two of the languages in
> > the survey you quoted.
>
> Well of *course* I meant relative to other languages! That's why I used the
> word "relatively!" The only thing I was trying to preclude was bashing, not
> comparing numbers.
Take A and B (let's say they're something other than languages). Now, try
posting to newsgroups consisting of A advocates and B advocates, and try to
rate A and B relative to each other, on any scale at all, without being
accused of bashing one or the other. You won't succeed. It can't be done.
You may have _intended_ the meaning of your statement to be clear and obvious,
but you didn't succeed. I suppose that you _could_ have meant "Go ahead
and bash C++, but leave Java and Perl out of it", but your own numbers
themselves didn't leave Java and Perl out of it.
But let's reset now; I will take you at your word that you really want
to do comparisons of Lisp relative to Perl and Java:
> Let me try my statement again, and see if it works better for you the new way:
>
> "Lisp is an important language, despite the fact that it has little commercial
> impact relative to other languages, such as Java and Perl."
>
> I'm guessing you won't like this one any better.
You're pretty bad at guessing. Once you clarify the restriction on
relative numbers, I agree, of course. Java and Perl are of course
more popular than Lisp, and I agreed with this several threads ago.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> "Marshall Spight" <·······@dnai.com> writes:
>
> But let's reset now; I will take you at your word that you really want
> to do comparisons of Lisp relative to Perl and Java:
>
> > Let me try my statement again, and see if it works better for you the new way:
> >
> > "Lisp is an important language, despite the fact that it has little commercial
> > impact relative to other languages, such as Java and Perl."
> >
> > I'm guessing you won't like this one any better.
>
> You're pretty bad at guessing. Once you clarify the restriction on
> relative numbers, I agree, of course. Java and Perl are of course
> more popular than Lisp, and I agreed with this several threads ago.
I'm pleased we were able to reach consensus. Good luck with Franz!
As a Berkeley grad, I wish you and it well.
Hey, one of those articles you have under "Lisp in the News" was written
by a guy whose office is just up the hall from mine.
Marshall
[Followup posted to comp.lang.lisp only]
On Sun, 22 Sep 2002 23:18:35 GMT, "Marshall Spight" <·······@dnai.com>
wrote:
> As far as trying to estimate the actual relative number, of course I'm
> on my own, because no one besides me has supplied any numbers
> or suggested any methodology for finding any numbers.
Here is a starting point:
- collect a large number (say the archives of the past 2-3 years) of
messages posted to comp.lang.lisp and all other major Lisp-related
mailing lists
- select the messages posted by employees of Lisp vendors and companies
using Lisp; other sources on companies using Lisp are the proceedings of
conferences/events and the testimonials/success stories pages at vendor
sites (note that it may take some familiarity with the Lisp community to
know whether someone works for a vendor or a company using Lisp)
- mail all of the above and ask whether they have any job openings
- and, of course, be sure to select the posts about job openings.
In short: Lispers don't rely much on Dice.com and similar services for
looking for jobs.
> Google hits for "java jobs": about 1,270,000
> Google hits for "lisp jobs": about 55,200
Can you estimate the amount of noise? Your Java query may also return
genuine but expired jobs openings (perhaps from dot-coms no longer in
business), documents discussing job openings in Java--the island--or
Indonesia, news items telling how great the market was/is/will be for Java
jobs, etc.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Marshall Spight wrote:
> Has this ever happened, do you think? I kinda don't think it has.
It happened after the AI winter. Lisp and Prolog disappeared, as "popular
languages", in less than three years. Same thing for Pascal in its
teaching and industrial niches. If you think that this can't happen with
Perl, Python, Java, etc., you're denying historical evidence for it
happening. I can see Java and Python's popularity being decimated by C#
(which is arguably a better language withthe backing of a major software
force). As for Perl, it may take a bit longer, and I see no clear
contenders as of yet, but if Perl has the longevity of Lisp and we are
still "programming" in Perl fifty years from now, I will be very surprised
(Statistically speaking, I'll probably be very dead, so I won't have much
reaction one way or another :-).
In the long run, our popularity is (as we are) but dust; Our true
friendships endure. It is the same with languages. Get over it.
faa
From: Hartmann Schaffer
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3d8d6fd4@news.sentex.net>
In article <······················@sccrnsc03>,
"Marshall Spight" <·······@dnai.com> writes:
> ...
> I brought it up to refute the suggestion that Java or Perl are going
> away soon,
> which I believe it did quite effectively.
in the 1970s and early 1980s practically everybody was looking for
pascal programmers. afaik, pascal has pretty much gone away now (at
least it seems to be restricted to niche markets)
> ...
hs
--
don't use malice as an explanation when stupidity suffices
Marshall Spight wrote:
> "Pascal Costanza" <········@web.de> wrote in message ·················@newsreader2.netcologne.de...
[...]
>>Therefore, templates are Turing-complete, generics are not.
>
>
> A language is said to be "Turing complete" if it can calculate all
> the things that a Turing machine can. This has nothing to do with
> generics or templates, neither of which is in the least required for,
> or even related to, Turing completeness.
No, I mean what I say. Templates are Turing-complete because they allow
you to write programs that are executed at compile-time. This is used in
Generative Programming to generate classes that are tailored towards
specific needs. The standard template library is an example that uses
this power of templates.
(Templates are Turing-complete because of the following facts: They
allow you to let a class extend a variation of itself, so you get
recursion; they also allow you to define terminating conditions (default
variants of such classes). So in effect you kind write functional
programs with templates that operate on your source code.)
>>Java has been developed explicitly for embedded devices and for the web.
>
>
> Java is a general purpose programming language. There is nothing in the
> language or the core API that in any way suggests embedded use.
These two statements are not contradictory. It has been designed with
concrete applications in mind, but can also be used for others. Read
about the history of Java, there are some papers about it available on
the net.
>>No one can guarantee you that Java, Perl or similar languages are still
>>alive in, say, five or ten years. But those concepts will definitely endure.
>
> I will personally guarantee that Java and Perl will both be alive in ten years.
> Hell, even Fortran will still be alive in ten years.
Bet accepted. ;)
> I agree. Lisp is an important language, despite the fact that it has
> relatively little commercial impact. It seems to me that this point can
> be made effectively without bashing Java or Perl.
I didn't bash Java and Perl. I think they have their merits - I mean,
they are obviously successfully used in their respective domains.
But this thread is about how to become a better programmer, and not how
to use a particular language most effectively.
Here is an analogy: If you want to learn about similarities and
distinctions of natural languages you should take a closer look at
several of them, not just one (say, English). If you want to be _really_
good at this you will definitely want to take a wide variety of
languages into account, including uncommen ("unpopular") languages. It's
probably better to focus on "untrendy" languages because it makes it
simpler to look at general principles (say, Latin). This doesn't mean
that I am bashing English... ;)
Some philosophers even think that it's not possible to develop certain
ideas when you only know a limited range of natural languages. I don't
know if this is true, but I would certainly agree with this with regard
to programming languages.
Pascal
On Sat, 21 Sep 2002 16:51:05 GMT, "Marshall Spight" <·······@dnai.com>
wrote:
>> Therefore, templates are Turing-complete, generics are not.
>
>A language is said to be "Turing complete" if it can calculate all
>the things that a Turing machine can. This has nothing to do with
>generics or templates, neither of which is in the least required for,
>or even related to, Turing completeness.
Talk about stupid, not even understanding what the differences between
Java generics and C++ templates ( not to mention Eiffel generics ).
The fact that C++ templates are Turing complete means that things like
Aspect Oriented Programing can be implemented using templates. Whereas
someone has to hack into the compiler to add aspects to Java.
Even that is not done completely. AspectJ only supports execution flow
aspects not data flow aspects ( of the applications that use aspects
the data flow aspects are much more interesting ).
>
>> No one can guarantee you that Java, Perl or similar languages are still
>> alive in, say, five or ten years. But those concepts will definitely endure.
>
>I will personally guarantee that Java and Perl will both be alive in ten years.
>Hell, even Fortran will still be alive in ten years.
>
>I just went to dice.com, an excellent classified site for programming jobs.
>I gave it a few different queries:
>
>"java programmer" got 400+ results
>"c++ programmer" got 300+ results
>"perl programmer" got 200+ results
>"lisp programmer" got exactly zero results
>
Aside from the question of whether dice is even a good barometer
of the job market, this says very little analysis of the qualtiy or
endurance of the job market.
Examining the jobs closer one is likely to see something like:
Jobs that require a person to work 80hrs/week because management is
cheap and only wants to hire half a staff.
java programmer 350+ jobs
C++ programmer 150+ jobs
perl programmer 190+ jobs
lisp programmer 0.
The companies engaging in such practices are discovering the hard
way ( bankrupcy ) that approached like this do not work. That is the
reason for the recent job implosion.
As for the validity of dice to judge the job market.
A while ago an employer of mine, who ran a small startup, put an ad on
Dice. Loooking for the words that he used in the ad I could not find
his company, sdespite going about ten layers down.
The only way I could find his company was by searching for the company
name.
What was ahead of him. Recruiters. Often times posting the same
nonexistent job multiple times.
The fact is that dice and other online job hunting services are scams
run by recruiters to: 1) Acquire resumes from unsuspecting programmers
so they can pad their resume count; 2) Crowd out small recruiters, and
companies to force people to use their services.
So I hardly think dice is a good barometer of the job market.
"Thaddeus L Olczyk" <······@interaccess.com> wrote in message ·······································@4ax.com...
>
> The fact that C++ templates are Turing complete means that things like
> Aspect Oriented Programing can be implemented using templates. Whereas
> someone has to hack into the compiler to add aspects to Java.
Yes, I misunderstood Pascal to be talking about the entire language, and
not just the feature of templates by themselves; he made that clear in a
later post.
> >I just went to dice.com, an excellent classified site for programming jobs.
> >I gave it a few different queries:
> ...
>
> Aside from the question of whether dice is even a good barometer
> of the job market, this says very little analysis of the qualtiy or
> endurance of the job market.
>
> Examining the jobs closer one is likely to see something like:
> ...
I consider my flawed, actual numbers preferable to your idealized
made-up ones. Sorry, I'm just perverse that way.
If you have any non-made-up numbers, however flawed, I'd be interested
to hear them. (How come no one ever takes me up on that?)
Marshall
[Followup posted to comp.lang.lisp only]
On Sat, 21 Sep 2002 16:51:05 GMT, "Marshall Spight" <·······@dnai.com>
wrote:
> I just went to dice.com, an excellent classified site for programming jobs.
> I gave it a few different queries:
>
> "java programmer" got 400+ results
> "c++ programmer" got 300+ results
> "perl programmer" got 200+ results
> "lisp programmer" got exactly zero results
How many hits did you get for "president united states"?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> Alexander Jerusalem wrote:
> >
> > Nevertheless I do agree with you that some of Java's "simplifications"
> > do in fact make things more complicated and unsafe. Every Java program
> > contains a miriad of type casts of the form:
> >
> > ItemType item = (ItemType)iterator.next();
> > or
> > ItemType item = (ItemType)map.get(key);
> >
> > That's tedious and above all it produces incredible amounts of
> > ClassCastExceptions at runtime. Something that would never happen in
> > C++ because that's what templates are for. Templates (or generics as
> > they call it in the Java community) is THE most wanted new feature and
> > it will be added in the next Java version (sometime in 2003).
>
> Generics is not just a different name for templates, but generics and
> templates are two different concepts that share some similarities.
I didn't say they were the same. My point was that the type casting
problem in the code snippet above would be solved with generics and
that the same problem doesn't occur in C++ because it has templates.
> In order to get this back on topic again: I have stated that it's not
> necessarily a good idea to use a hyped language for learning, and I
> would definitely include Java and Perl in the list of hyped languages.
I remember the times when C++ was a much hyped language. Nevertheless
I think C++ has a lot of interesting concepts. Hyped or not doesn't
seem to be a very good categorization for programming languages.
> Here is why:
>
> * Hyped languages are generally used for a limited set of concerns. Java
> has been developed explicitly for embedded devices and for the web. Perl
> has been developed for certain kinds of scripting tasks. Learning such
> languages usually means that the examples you use are narrowed down to
> these "popular" domains. It's likely that you loose your view on the
> more general concepts that determine certain language design choices. (I
> don't say that you will definitely run into such traps, I only say that
> it is more likely.)
Then the distinction should probably be general purpose vs. special
purpose languages. But the purpose of a language is determined to a
large degree by the set of available libraries. I for one have never
used any embedded systems libraries in Java. And you would be hard
pressed to find a language that is used in more different areas than
Java. Also, don't forget that Lisp was made for a very special
purpose: Processing lists :-) No, seriously: It was made for highly
dynamic AI programming tasks. That may seem more general purpose today
but in the 50ies it was definitely not. I think special purpose
languages can bring up features that become general purpose over time
because they are just convincing.
> So for example, if you have understood the concepts of closures,
> higher-order functions, object identity, static vs. dynamic typing, and
> so on, and so forth, by having seen them in very different languages,
> you will definitely have an easy time to recognize the same concepts in
> any new language that will come up in the future for the next hype. No
> one can guarantee you that Java, Perl or similar languages are still
> alive in, say, five or ten years. But those concepts will definitely endure.
>
> So for example, learning Common Lisp might buy you much more, because it
> includes a wealth of ideas and concepts that steadily change your view
> of the world. This will increase your flexibility in solving concrete
> problems, whether you use Common Lisp in practice or not.
I completely agree with you there. It makes perfect sense to acquire a
thorough understanding of all the concepts that computer science has
developed over the decades. You can always later go back and use Java
or even VB for commercial reasons but you shouldn't use them out of a
lack of knowledge. And it should hurt to have to use them (And it does
:-/
Regards,
Alexander
Alexander Jerusalem wrote:
> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
>
>>Alexander Jerusalem wrote:
>> >
>>
[...]
>>>Templates (or generics as
>>>they call it in the Java community) is THE most wanted new feature and
>>>it will be added in the next Java version (sometime in 2003).
>>
>>Generics is not just a different name for templates, but generics and
>>templates are two different concepts that share some similarities.
>
> I didn't say they were the same. My point was that the type casting
> problem in the code snippet above would be solved with generics and
> that the same problem doesn't occur in C++ because it has templates.
Then I have misunderstood your statement. It can be understood as if
(full) templates would be added to Java, but it's only a stripped-down
version (without Turing-completeness) that will. I hope this is what you
meant.
>>In order to get this back on topic again: I have stated that it's not
>>necessarily a good idea to use a hyped language for learning, and I
>>would definitely include Java and Perl in the list of hyped languages.
>
> I remember the times when C++ was a much hyped language. Nevertheless
> I think C++ has a lot of interesting concepts. Hyped or not doesn't
> seem to be a very good categorization for programming languages.
Well, but the focus of C++ has changed over the last few years. In the
beginning it was advertised as an object-oriented language, and now a
much wider range is claimed by C++.
(My personal feeling is that you can shoot yourself in the foot in C++
more easily than in other languages, so it's not very well-suited for
beginners. But I don't have enough evidence or experience in C++ to
prove this, so this is just a guess. Especially, I find the lack of
automatic garbage collection, at least as a default, very strange...)
>>Here is why:
>>
>>* Hyped languages are generally used for a limited set of concerns. Java
>>has been developed explicitly for embedded devices and for the web. Perl
>>has been developed for certain kinds of scripting tasks. Learning such
>>languages usually means that the examples you use are narrowed down to
>>these "popular" domains. It's likely that you loose your view on the
>>more general concepts that determine certain language design choices. (I
>>don't say that you will definitely run into such traps, I only say that
>>it is more likely.)
>
> Then the distinction should probably be general purpose vs. special
> purpose languages. But the purpose of a language is determined to a
> large degree by the set of available libraries. I for one have never
> used any embedded systems libraries in Java. And you would be hard
> pressed to find a language that is used in more different areas than
> Java.
I think you're still missing my point. (But of course, this is probably
my problem. ;) To be more concrete with the example of Java: In the
beginning, most of those "Java in 21 miliseconds" books concentrated
mainly on showing you how to program applets and how to embed them in
HTML. Nowadays, this still happens, and this is amended by introductions
to using the Swing API, because of those superficial quick "rewards".
It's very hard to find any book about Java that teaches _principles of
programming_ instead of perceived "hot topics" like how to fiddle with
XML processing.
It's more likely that these things happen with "hyped" languages than
with "unpopular" ones. For example, when you look for books on
programming that use Scheme as their expository language, you will find
such classics like "Structure and Interpretation of Computer Programs",
"How to Design Programs" or "The Little Schemer" that will teach you
more fundamentals and substantial lessons than 1000 books on Java.
Furthermore, the stuff you learn in the latter books empower you to make
better use of _any language_. So it's more likely that you become a
better programmer with Scheme than with Java.
It's just a matter of statistical probability that you will pick a good
book about an "unpopular" language rather than a good book on a "hot"
language. That's all I want to say.
> Also, don't forget that Lisp was made for a very special
> purpose: Processing lists :-) No, seriously: It was made for highly
> dynamic AI programming tasks. That may seem more general purpose today
> but in the 50ies it was definitely not. I think special purpose
> languages can bring up features that become general purpose over time
> because they are just convincing.
I completely agree. It's just not correct to still label Lisp as an AI
language nowadays, because many of the things that were considered to be
AI many years ago are now just standard and conventional techniques.
There exist many successful applications of AI nowadays - they're just
not called AI anymore.
[...]
> I completely agree with you there. It makes perfect sense to acquire a
> thorough understanding of all the concepts that computer science has
> developed over the decades. You can always later go back and use Java
> or even VB for commercial reasons but you shouldn't use them out of a
> lack of knowledge. And it should hurt to have to use them (And it does
> :-/
Yes, exactly!
Pascal
From: Dale King
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3d8f9830$6@news.tce.com>
Hey, comp.lang.java.advocacy is just down the hall.
"Pascal Costanza" <········@web.de> wrote in message
·················@newsreader2.netcologne.de...
> Alexander Jerusalem wrote:
> >
> > Nevertheless I do agree with you that some of Java's "simplifications"
> > do in fact make things more complicated and unsafe. Every Java program
> > contains a miriad of type casts of the form:
> >
> > ItemType item = (ItemType)iterator.next();
> > or
> > ItemType item = (ItemType)map.get(key);
> >
> > That's tedious and above all it produces incredible amounts of
> > ClassCastExceptions at runtime. Something that would never happen in
> > C++ because that's what templates are for. Templates (or generics as
> > they call it in the Java community) is THE most wanted new feature and
> > it will be added in the next Java version (sometime in 2003).
>
> Generics is not just a different name for templates, but generics and
> templates are two different concepts that share some similarities.
>
> Templates in C++ allow you to use type variables when you declare your
> superclasses. This is forbidden in the generics extension for Java.
> Therefore, templates are Turing-complete, generics are not. That's an
> important distinction.
>
> In order to get this back on topic again: I have stated that it's not
> necessarily a good idea to use a hyped language for learning, and I
> would definitely include Java and Perl in the list of hyped languages.
> Here is why:
>
> * Hyped languages are generally used for a limited set of concerns. Java
> has been developed explicitly for embedded devices and for the web. Perl
> has been developed for certain kinds of scripting tasks. Learning such
> languages usually means that the examples you use are narrowed down to
> these "popular" domains. It's likely that you loose your view on the
> more general concepts that determine certain language design choices. (I
> don't say that you will definitely run into such traps, I only say that
> it is more likely.)
>
> * There are several languages out there that haven't been trimmed to
> certain "popular" tasks. Such languages are more likely to teach you
> general principles of languages. Understanding these general principles
> make you a better programmer.
>
> So for example, if you have understood the concepts of closures,
> higher-order functions, object identity, static vs. dynamic typing, and
> so on, and so forth, by having seen them in very different languages,
> you will definitely have an easy time to recognize the same concepts in
> any new language that will come up in the future for the next hype. No
> one can guarantee you that Java, Perl or similar languages are still
> alive in, say, five or ten years. But those concepts will definitely
endure.
>
> So for example, learning Common Lisp might buy you much more, because it
> includes a wealth of ideas and concepts that steadily change your view
> of the world. This will increase your flexibility in solving concrete
> problems, whether you use Common Lisp in practice or not.
--
Dale King
From: Benjamin Goldberg
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3D8FD11D.C72F0CB8@earthlink.net>
Pascal Costanza wrote:
[snip]
> In order to get this back on topic again: I have stated that it's not
> necessarily a good idea to use a hyped language for learning, and I
> would definitely include Java and Perl in the list of hyped languages.
> Here is why:
>
> * Hyped languages are generally used for a limited set of concerns.
> Java has been developed explicitly for embedded devices and for the
> web. Perl has been developed for certain kinds of scripting tasks.
Eeh, define "scripting" ... do you mean CGI scripting?
Perl has been used in a *wide* variety of tasks, including full-scale
applications. Indeed, many of the regulars of comp.lang.perl.misc have
been using perl for years, and haven't once written a CGI script.
Furthermore, who says that CGI needs to be a script? After all, it's
just a data passing protocol... *any* kind of program, including a C,
C++, java, lisp, (etc, etc) program can be written to understand the CGI
protocol.
The hype of Perl is not "scripting", per se (although it is technically
an interpreted language), the hypes of perl are:
1/ it's powerful text processing capabilities (both it's builtin regex
engine, and external modules).
2/ The *HUGE* set of free modules available (for free!) from CPAN, the
"Comprehensive Perl Archive Network" to help you perform specific tasks.
3/ The long shallow learning curve. You only need a small subset of
perl's functionality to begin programming with it, and you can quickly
and easily learn such a subset, and start programming right away. If
you're serious about learning and using perl, you can go on to learn
other features of the language as you run into the need for them.
4/ Buzword compliancy -- closures, dynamic typing, higher-order
functions, database connections (ODBC, mySQL, etc),
CPAN is perhaps one of the most important things about Perl -- it helps
you avoid reinventing the wheel.
No other programming language has any such thing, with oodles of useful
libraries collected in one *central* location.
(TeX (whose CTAN inspired CPAN) isn't really a programming language.)
> Learning such languages usually means that the examples you use are
> narrowed down to these "popular" domains. It's likely that you loose
> your view on the more general concepts that determine certain language
> design choices. (I don't say that you will definitely run into such
> traps, I only say that it is more likely.)
>
> * There are several languages out there that haven't been trimmed to
> certain "popular" tasks. Such languages are more likely to teach you
> general principles of languages. Understanding these general
> principles make you a better programmer.
Perl is a general purpose language -- about the only thing it doesn't do
well is number crunching... and you can plug in modules which will do
that for you.
> So for example, if you have understood the concepts of closures,
> higher-order functions, object identity, static vs. dynamic typing,
> and so on, and so forth, by having seen them in very different
> languages, you will definitely have an easy time to recognize the same
> concepts in any new language that will come up in the future for the
> next hype. No one can guarantee you that Java, Perl or similar
> languages are still alive in, say, five or ten years. But those
> concepts will definitely endure.
I would be quite surprised if Perl were to die in 10 years. Perhaps
perl5 will be dead by then (with perl6 in it's place), there will almost
certainly be something which looks and feels like Perl still around.
And Lisp, Java, C, C++, will also still be around. Well, maybe not
Java... depending on whether M$ manages to kill it with it's .NET
framework.
> So for example, learning Common Lisp might buy you much more, because
> it includes a wealth of ideas and concepts that steadily change your
> view of the world. This will increase your flexibility in solving
> concrete problems, whether you use Common Lisp in practice or not.
Kinda like the advantage that learning Latin gives you for for dealing
with other languages.
--
Announcement in the Zoo:
"Please don't scare the ostriches! Cement floor!"
From: Pascal Costanza
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3D903340.3090109@web.de>
Benjamin Goldberg wrote:
> Pascal Costanza wrote:
> [snip]
>
>>In order to get this back on topic again: I have stated that it's not
>>necessarily a good idea to use a hyped language for learning, and I
>>would definitely include Java and Perl in the list of hyped languages.
>>Here is why:
>>
>>* Hyped languages are generally used for a limited set of concerns.
>>Java has been developed explicitly for embedded devices and for the
>>web. Perl has been developed for certain kinds of scripting tasks.
>
>
> Eeh, define "scripting" ... do you mean CGI scripting?
No.
> The hype of Perl is not "scripting", per se (although it is technically
> an interpreted language), the hypes of perl are:
[...]
I have no intentions to question Perl's merits. Please read my (and
other people's) other posts in this thread - I don't want to repeat myself.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
jvm wrote:
> I think Java is a very good choice for a language,
> and I've worked with many a language, including Basic, assembly, Pascal,
> C, C++, VHDL, AWK, Perl, Forth, Lisp, Haskell and others.
None of those are dynamically typed OO language. The closest are Perl, Lisp
and Haskell. Dynamism vs. staticism is the fundamental distinction among OO
languages, and learning to use a dynamic language, such as Smalltalk, Ruby
or Python, will increase your ability to advocate linguistic issues.
--
Phlip
http://flea.sourceforge.net
-- MCCD - Microsoft Certified Co-Dependent --
Phlip <·········@yahoo.com> writes:
>
> None of those are dynamically typed OO language. The closest are Perl, Lisp
> and Haskell. Dynamism vs. staticism is the fundamental distinction among OO
> languages, and learning to use a dynamic language, such as Smalltalk, Ruby
> or Python, will increase your ability to advocate linguistic issues.
>
In view of CLOS, in what way would you say that Common Lisp is not a
dynamically typed OO language (or at least that it easily permits,
though does not force, one to program in that style)?
Howard Ding
"Howard Ding" wrote:
> Phlip writes:
> > None of those are dynamically typed OO language. The closest are Perl,
Lisp
> > and Haskell. Dynamism vs. staticism is the fundamental distinction among
OO
> > languages, and learning to use a dynamic language, such as Smalltalk, Ruby
> > or Python, will increase your ability to advocate linguistic issues.
>
> In view of CLOS, in what way would you say that Common Lisp is not a
> dynamically typed OO language (or at least that it easily permits,
> though does not force, one to program in that style)?
jvm threw out a long list of languages and language-like systems. He did not
seem aware of the distinctions between OO and non-OO languages, or of static
and dynamic typing.
Anyone who would declaim "Use Java!" ought to be made aware of these
distinctions.
--
Phlip
http://clublet.com/c/c/why?ZenoBuddhism
-- The first few lines of code must "hook" the
computer, and make it "care" about the program --
"Phlip" <·········@my-deja.com> writes:
> "Howard Ding" wrote:
>> Phlip writes:
>
>>> None of those are dynamically typed OO language. The closest are Perl,
> Lisp
>>> and Haskell. Dynamism vs. staticism is the fundamental distinction among
> OO
>>> languages, and learning to use a dynamic language, such as Smalltalk, Ruby
>>> or Python, will increase your ability to advocate linguistic issues.
>>
>> In view of CLOS, in what way would you say that Common Lisp is not a
>> dynamically typed OO language (or at least that it easily permits,
>> though does not force, one to program in that style)?
>
> jvm threw out a long list of languages and language-like systems. He did not
> seem aware of the distinctions between OO and non-OO languages, or of static
> and dynamic typing.
>
> Anyone who would declaim "Use Java!" ought to be made aware of these
> distinctions.
>
Indeed. However, your response implies that Lisp is not a dynamically
typed OO language, when in fact it is (or to be more precise, Common
Lisp is dynamically typed and is OO in the sense that it supports OO
progamming, though not in the sense that it forces it).
--
Howard Ding
<·····@prairieinet.net>
http://math.sunysb.edu/~hading http://thunder.prohosting.com/~hading
"Howard Ding" wrote:
> Indeed. However, your response implies that Lisp is not a dynamically
> typed OO language, when in fact it is (or to be more precise, Common
> Lisp is dynamically typed and is OO in the sense that it supports OO
> progamming, though not in the sense that it forces it).
Lisp is the greatest language that has ever existed or ever will exist.
My response implied I suspected the depth of the earlier poster's
understanding, but tried to remain ambiguous myself to avoid vacant language
advocacy.
Best laid plans of mice...
--
Phlip
http://www.greencheese.org/MakeItSo
"I love deadlines. I love the whooshing sound they make as they fly
by." -- Douglas Adams
Phlip wrote:
> "Howard Ding" wrote:
>
>> Indeed. However, your response implies that Lisp is not a dynamically
>> typed OO language, when in fact it is (or to be more precise, Common
>> Lisp is dynamically typed and is OO in the sense that it supports OO
>> progamming, though not in the sense that it forces it).
>
> Lisp is the greatest language that has ever existed or ever will exist.
>
You must be one of those rare genii who know all dead, extant and future
computer languages.
With deepest admiration and appreciation,
Oleg
Oleg wrote:
> Phlip wrote:
>
>
>>"Howard Ding" wrote:
>>
>>
>>>Indeed. However, your response implies that Lisp is not a dynamically
>>>typed OO language, when in fact it is (or to be more precise, Common
>>>Lisp is dynamically typed and is OO in the sense that it supports OO
>>>progamming, though not in the sense that it forces it).
>>
>>Lisp is the greatest language that has ever existed or ever will exist.
>>
>
>
> You must be one of those rare genii who know all dead, extant and future
> computer languages.
>
Well, why do you think Lisp has been dead for so many years? If it
hadn't reached a global maximum in programming language space so long
ago, all the Brilliant Lisp Geniuses would have kept improving it. But I
guess they all got bored with their perfection and left to work on
quantum chromodynamics or something. This is as good as it gets, so take
it or leave it.
;)
Joe
Joseph Dale wrote:
> Oleg wrote:
>> Phlip wrote:
>>
>>
>>>"Howard Ding" wrote:
>>>
>>>
>>>>Indeed. However, your response implies that Lisp is not a dynamically
>>>>typed OO language, when in fact it is (or to be more precise, Common
>>>>Lisp is dynamically typed and is OO in the sense that it supports OO
>>>>progamming, though not in the sense that it forces it).
>>>
>>>Lisp is the greatest language that has ever existed or ever will exist.
>>>
>>
>>
>> You must be one of those rare genii who know all dead, extant and future
>> computer languages.
>>
>
> Well, why do you think Lisp has been dead for so many years? If it
> hadn't reached a global maximum in programming language space so long
> ago, all the Brilliant Lisp Geniuses would have kept improving it. But I
> guess they all got bored with their perfection and left to work on
> quantum chromodynamics or something.
FORTRAN and COBOL have not evolved any more than Lisp has. And I have never
met any of their users who were simple enough to deduce from this fact that
either language "is the greatest language that has ever existed or ever
will exist". I wonder if "Brilliant Lisp Genius" is an oxymoron.
Oleg
"Oleg" <············@myrealbox.com> wrote in message
·················@newsmaster.cc.columbia.edu...
> Joseph Dale wrote:
> > Oleg wrote:
> >> Phlip wrote:
> >>>Lisp is the greatest language that has ever existed or ever will exist.
> >>>
> >> You must be one of those rare genii who know all dead, extant and
future
> >> computer languages.
> >>
> > Well, why do you think Lisp has been dead for so many years? If it
> > hadn't reached a global maximum in programming language space so long
> > ago, all the Brilliant Lisp Geniuses would have kept improving it. But I
> > guess they all got bored with their perfection and left to work on
> > quantum chromodynamics or something.
>
> FORTRAN and COBOL have not evolved any more than Lisp has.
The latest ISO COBOL Standard was approved this week.
> And I have never
> met any of their users who were simple enough to deduce from this fact
that
> either language "is the greatest language that has ever existed or ever
> will exist". I wonder if "Brilliant Lisp Genius" is an oxymoron.
COBOL is the greatest language ever :) Look at the control it gives you over
defining variables:
01 WS-FIELDS.
05 WS-DATE.
10 WS-CCYY PIC 9(4). <- unsigned 4-digit number
10 WS-MM PIC 99. <- unsigned 2-digit number
10 WS-DD PIC 99.
05 WS-DESCR PIC X(40). <- 40 character string
05 WS-TOTAL PIC S9(13)V99 PACKED-DECIMAL. <- signed 13 integer
and 2 decimal places
And how logical are the keywords:
MOVE 5387.78 TO WS-TOTAL
ADD +1 TO WS-COUNT
PERFORM <some-section>
VARYING WS-COUNT FROM 1 BY 1
UNTIL WS-COUNT > 100
See, COBOL is self-commenting. :)
--
David
A. Top posters.
Q. What is the most annoying thing on Usenet?
Oleg <············@myrealbox.com> writes:
> >> You must be one of those rare genii who know all dead, extant and future
> >> computer languages.
> >>
> >
> > Well, why do you think Lisp has been dead for so many years? If it
> > hadn't reached a global maximum in programming language space so long
> > ago, all the Brilliant Lisp Geniuses would have kept improving it. But I
> > guess they all got bored with their perfection and left to work on
> > quantum chromodynamics or something.
>
> FORTRAN and COBOL have not evolved any more than Lisp has. And I have never
> met any of their users who were simple enough to deduce from this fact that
> either language "is the greatest language that has ever existed or ever
> will exist". I wonder if "Brilliant Lisp Genius" is an oxymoron.
Dear Oleg,
this is just a reminder:
the kind people on comp.lang.lisp are still wainting the OCaml
implementation of the Visitor's Pattern.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Duane Rettig
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <4y99vkabu.fsf@beta.franz.com>
Joseph Dale <·········@sbcglobal.net> writes:
> Oleg wrote:
> > Phlip wrote:
> >
>
> >>"Howard Ding" wrote:
> >>
> >>
> >>>Indeed. However, your response implies that Lisp is not a dynamically
> >>>typed OO language, when in fact it is (or to be more precise, Common
> >>>Lisp is dynamically typed and is OO in the sense that it supports OO
> >>>progamming, though not in the sense that it forces it).
> >>
> >>Lisp is the greatest language that has ever existed or ever will exist.
> >>
> > You must be one of those rare genii who know all dead, extant and
> > future computer languages.
>
> >
>
>
> Well, why do you think Lisp has been dead for so many years?
Amazing! I haven't actually seen such a strong "Lisp is dead" rant
for many years, let alone so many implications in this thread to that
effect since 1994, when many people actually did think that Lisp was
dead. Thanks for the laugh.
> If it
> hadn't reached a global maximum in programming language space so long
> ago, all the Brilliant Lisp Geniuses would have kept improving it. But
> I guess they all got bored with their perfection and left to work on
> quantum chromodynamics or something. This is as good as it gets, so
> take it or leave it.
We're still here, and Lisp still improves, but the AI hype and crash of
the late '80s taught us to be more quiet about it.
> ;)
:-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Dale King
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3d8f9830$3@news.tce.com>
"Duane Rettig" <·····@franz.com> wrote in message
··················@beta.franz.com...
> Joseph Dale <·········@sbcglobal.net> writes:
>
> > Oleg wrote:
> > > Phlip wrote:
> > >
> >
> > >>"Howard Ding" wrote:
> > >>
> > >>
> > >>>Indeed. However, your response implies that Lisp is not a
dynamically
> > >>>typed OO language, when in fact it is (or to be more precise, Common
> > >>>Lisp is dynamically typed and is OO in the sense that it supports OO
> > >>>progamming, though not in the sense that it forces it).
> > >>
> > >>Lisp is the greatest language that has ever existed or ever will
exist.
> > >>
> > > You must be one of those rare genii who know all dead, extant and
> > > future computer languages.
> >
> > >
> >
> >
> > Well, why do you think Lisp has been dead for so many years?
>
> Amazing! I haven't actually seen such a strong "Lisp is dead" rant
> for many years, let alone so many implications in this thread to that
> effect since 1994, when many people actually did think that Lisp was
> dead. Thanks for the laugh.
>
> > If it
> > hadn't reached a global maximum in programming language space so long
> > ago, all the Brilliant Lisp Geniuses would have kept improving it. But
> > I guess they all got bored with their perfection and left to work on
> > quantum chromodynamics or something. This is as good as it gets, so
> > take it or leave it.
>
> We're still here, and Lisp still improves, but the AI hype and crash of
> the late '80s taught us to be more quiet about it.
I no of no language that achieved widespread use (so not counting various
toy languages) that one can call dead (depending on your definition of
dead). Any language you can mention is still being used somewhere. In a past
thread someone mentioned Simula as a dead language, but come to find out
there is a Simula conference every year and its attendance grows every year.
--
Dale King
Joseph Dale <·········@sbcglobal.net> wrote in message news:<·····················@newssvr21.news.prodigy.com>...
> Well, why do you think Lisp has been dead for so many years? If it
> hadn't reached a global maximum in programming language space so long
> ago, all the Brilliant Lisp Geniuses would have kept improving it. But I
> guess they all got bored with their perfection and left to work on
What does it mean to improve a programming language? Once it has all
the features of Common Lisp, it can be improved by adding libraries,
fixing bugs, adding more optimizing to the compilers, and especially
by improving the hardware it runs on. Common Lisp is an extremely
powerful programming language to vastly improve the productivity of
the best programmers. As hardware advances, becoming exponentially
more powerful at lower cost, the importance of software productivity
increases with it. Thus Common Lisp is advancing as a "dark horse"
and may eventually reach a new critical mass where it will suddenly
leave all other programming languages in the dust. That may be a big
part of the reason why some Common Lisp fans seem to worship the
ground its bugs crawl on. The Common Lisp vendors continue to improve
their compilers and release new versions, not like zombies worshipping
a dead god, but more like highway construction workers adding new
lanes to an old highway.
People are so used to seeing improvements in hardware that the "newer
is better" theory has been proven to them overwhelmingly by ubiquitous
examples but without solid logic to tell them where the theory applies
and where it doesn't. Improving a programming language is not so much
like improving a word processor as improving the alphabet and grammar
of the language being processed. It's one place where the "newer is
better" theory simply doesn't hold.
Joseph Dale wrote:
> Well, why do you think Lisp has been dead for so many years?
This has to be one of the greatest non sequiters I have read in a long,
long time. Thank you. Are you related to Jim?
;)
In article <·····················@newssvr21.news.prodigy.com>, jdale1729
@sbcglobal.net says...
> Oleg wrote:
> > Phlip wrote:
> >
> >
> >>"Howard Ding" wrote:
> >>
> >>
> >>>Indeed. However, your response implies that Lisp is not a dynamically
> >>>typed OO language, when in fact it is (or to be more precise, Common
> >>>Lisp is dynamically typed and is OO in the sense that it supports OO
> >>>progamming, though not in the sense that it forces it).
> >>
> >>Lisp is the greatest language that has ever existed or ever will exist.
> >>
> >
> >
> > You must be one of those rare genii who know all dead, extant and future
> > computer languages.
> >
>
> Well, why do you think Lisp has been dead for so many years? If it
> hadn't reached a global maximum in programming language space so long
> ago, all the Brilliant Lisp Geniuses would have kept improving it. But I
> guess they all got bored with their perfection and left to work on
> quantum chromodynamics or something. This is as good as it gets, so take
> it or leave it.
>
> ;)
>
>
> Joe
>
>
Yep, kinda like Macs and Emacs. <grin> (ducking and running)
KAC
"Phlip" <·········@my-deja.com> writes:
> "Howard Ding" wrote:
> > Phlip writes:
>
> > > None of those are dynamically typed OO language. The closest are Perl,
> Lisp
> > > and Haskell. Dynamism vs. staticism is the fundamental distinction among
> OO
> > > languages, and learning to use a dynamic language, such as Smalltalk, Ruby
> > > or Python, will increase your ability to advocate linguistic issues.
> >
> > In view of CLOS, in what way would you say that Common Lisp is not a
> > dynamically typed OO language (or at least that it easily permits,
> > though does not force, one to program in that style)?
>
> jvm threw out a long list of languages and language-like systems. He did not
> seem aware of the distinctions between OO and non-OO languages, or of static
> and dynamic typing.
>
> Anyone who would declaim "Use Java!" ought to be made aware of these
> distinctions.
And what you said indicates that you simply *do not* know about the
nature of some of the languages you carelessly mention.
Not knowing Common Lisp and saying that "learning to use a dynamic
language, such as Smalltalk, Ruby or Python, will increase your
ability to advocate linguistic issues." does indicate that you have to
do quite a bit of learning (especially historically-wise) in the
field.
Cheers
PS. Feel free to send followups to /dev/null.
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Phlip <·········@yahoo.com> writes:
> jvm wrote:
>
> > I think Java is a very good choice for a language,
> > and I've worked with many a language, including Basic, assembly, Pascal,
> > C, C++, VHDL, AWK, Perl, Forth, Lisp, Haskell and others.
>
> None of those are dynamically typed OO language. The closest are Perl, Lisp
> and Haskell. Dynamism vs. staticism is the fundamental distinction among OO
> languages, and learning to use a dynamic language, such as Smalltalk, Ruby
> or Python, will increase your ability to advocate linguistic issues.
Also your knowledge of other languages will improve the information
you are spreading. From what you say above, one can infer that Lisp
is not a "dynamically typed OO language".
This is false.
You should learn about (Common) Lisp before making these sort of
statements. Especially if you then make the case for things like Ruby
and Python, without a reference to Greenspun's Tenth Rule of
Programming.
Cheers
PS. Fell free to send followps to /dev/null. :)
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
On Fri, 20 Sep 2002 16:01:24 +0200, jvm
<···@fiberia.is.no.more> wrote:
>In article <·····················@sccrnsc02>, ··········@notahost.org
>says...
>>
>> > So, one of my friends tells me that I should learn C++, because "it's
>> > the best". But, seriously, he doesn't know anything but C++, so I'm
>> > not too sure if he is qualified to give this type of advice...
>> > Another friend tells me "define what you mean by 'better programmer'".
>> > So, that guy wasn't too helpful either. So I thought about this A LOT,
>> > and I'm wonderingif I could ask for advice on the internet.
>> Read this book:
>> Code Complete
>> http://www.construx.com/stevemcc/cc.htm
>
>I wouldn't recommend that book. It's typically geared towards
>procedural programming and somewhat outdated.
I disagree. If that is what you think, you completely
misunderstood the book's central message.
Code Complete is an excellent book. Its examples
are often procedural, but that is probably because
that is way simpler than to make an object oriented
example that shows exactly the same thing.
The book is about programming in general and not
geared towards any language or type of language.
--
Regards, Helgi Briem
helgi AT decode DOT is
A: Top posting
Q: What is the most irritating thing on Usenet?
- "Gordon" on apihna
In article <··················@news.cis.dfn.de>, ·····@decode.is says...
> On Fri, 20 Sep 2002 16:01:24 +0200, jvm
> <···@fiberia.is.no.more> wrote:
>
> >In article <·····················@sccrnsc02>, ··········@notahost.org
> >says...
> >>
> >> > So, one of my friends tells me that I should learn C++, because "it's
> >> > the best". But, seriously, he doesn't know anything but C++, so I'm
> >> > not too sure if he is qualified to give this type of advice...
> >> > Another friend tells me "define what you mean by 'better programmer'".
> >> > So, that guy wasn't too helpful either. So I thought about this A LOT,
> >> > and I'm wonderingif I could ask for advice on the internet.
>
> >> Read this book:
>
> >> Code Complete
> >> http://www.construx.com/stevemcc/cc.htm
> >
> >I wouldn't recommend that book. It's typically geared towards
> >procedural programming and somewhat outdated.
>
> I disagree. If that is what you think, you completely
> misunderstood the book's central message.
I understand the central message, thank you, but I already picked
the message up from other sources.
> Code Complete is an excellent book. Its examples
> are often procedural, but that is probably because
> that is way simpler than to make an object oriented
> example that shows exactly the same thing.
No, when reading it for the second time, I found that many problems
which were described as problems, actually are easily solved with OO
concepts.
> The book is about programming in general and not
> geared towards any language or type of language.
It's geared towards procedural programming.
It could have been a much better book had it either kept itself
to pure software process issues, or to inform the reader about
the object and pattern paradigms.
Now this person was asking advice how to be a better programmer,
and I think going the Java road will be very apropriate for him.
Code complete would focus a lot of his attention to procedural
language problems.
From: Dale King
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3d8f9830$4@news.tce.com>
"jvm" <···@fiberia.is.no.more> wrote in message
······························@pixs.htc.nl.philips.com...
> In article <··················@news.cis.dfn.de>, ·····@decode.is says...
> > On Fri, 20 Sep 2002 16:01:24 +0200, jvm
> > <···@fiberia.is.no.more> wrote:
> >
> > >In article <·····················@sccrnsc02>, ··········@notahost.org
> > >says...
> > >>
> > >> > So, one of my friends tells me that I should learn C++, because
"it's
> > >> > the best". But, seriously, he doesn't know anything but C++, so I'm
> > >> > not too sure if he is qualified to give this type of advice...
> > >> > Another friend tells me "define what you mean by 'better
programmer'".
> > >> > So, that guy wasn't too helpful either. So I thought about this A
LOT,
> > >> > and I'm wonderingif I could ask for advice on the internet.
> >
> > >> Read this book:
> >
> > >> Code Complete
> > >> http://www.construx.com/stevemcc/cc.htm
> > >
> > >I wouldn't recommend that book. It's typically geared towards
> > >procedural programming and somewhat outdated.
> >
> > I disagree. If that is what you think, you completely
> > misunderstood the book's central message.
>
> I understand the central message, thank you, but I already picked
> the message up from other sources.
Good for you. Then you are well-read. Most programmers are not.
> > Code Complete is an excellent book. Its examples
> > are often procedural, but that is probably because
> > that is way simpler than to make an object oriented
> > example that shows exactly the same thing.
>
> No, when reading it for the second time, I found that many problems
> which were described as problems, actually are easily solved with OO
> concepts.
>
> > The book is about programming in general and not
> > geared towards any language or type of language.
>
> It's geared towards procedural programming.
No, it is about any type of programming. He doesn't limit himself to just
OO, because not everyone is programming OO (and even less were in 1993 when
it come out).
Let's look over the 33 chapters and see if we can find a focus on procedural
programming. You can see the table of contents at
www.construx.com/stevemcc/cc.html.
- the first 3 chapters are high-level philosophical discussions of the
development process and show no code either way.
- chapter 4 and 5 are a discussion of building a routine (function or
method). OO has methods and everything covered here is applicable to OO. He
even talks about cohesion and coupling.
- chapter 6 is about modularity and information hiding, which are one of the
strengths of OO, but achievable in any language.
- chapter 7 is a high-level design chapter discussing structured design and
OO design, including how to do OO design.
- chapters 8 - 12 are about data. Last time I checked we had data in OO
programming and still have to worry about data types, names, scope,
persistence, etc.
- chapters 13 - 17 are about contol statements. Last time I checked we still
had straight-line code, conditionals, loops, etc.
- chapters 18 - 22 talks about things like program layout, self-documenting
code, programming tools, program size, and managing construction. All apply
to OO programming as well.
- chapters 23 - 26 are about software quality. Last time I checked we wanted
god quality from OO software as well. It talks about different techniques,
code reviews, unit testing, and debugging.
- chapters 27 - 30 talk about integration, code tuning, and software
evolution, all of which apply to OO software as well.
- the remaining three chapters are about software craftsmanship which are
more about the programmer than the program
I find no evidence to back up your claim that it is about procedural
programming. It is simply about programming.
> It could have been a much better book had it either kept itself
> to pure software process issues, or to inform the reader about
> the object and pattern paradigms.
It does talk about OO (see section 7.3 for instance). It just doesn't limit
itself to OO, because the subjects talked about apply to OO or procedural
programming.
As far as design patterns, Code Complete predates the GOF book that
introduced design patterns.
> Now this person was asking advice how to be a better programmer,
> and I think going the Java road will be very apropriate for him.
I agree with that much.
> Code complete would focus a lot of his attention to procedural
> language problems.
No, it would talk about issues that are important in any type of
programming.
--
Dale King
In article <··········@news.tce.com>, ·····@TCE.com says...
> "jvm" <···@fiberia.is.no.more> wrote in message
> ······························@pixs.htc.nl.philips.com...
> > In article <··················@news.cis.dfn.de>, ·····@decode.is says...
> > > On Fri, 20 Sep 2002 16:01:24 +0200, jvm
> > > <···@fiberia.is.no.more> wrote:
> > >
> > > >In article <·····················@sccrnsc02>, ··········@notahost.org
> > > >says...
> > It's geared towards procedural programming.
>
> No, it is about any type of programming. He doesn't limit himself to just
> OO, because not everyone is programming OO (and even less were in 1993 when
> it come out).
<snip>
> I find no evidence to back up your claim that it is about procedural
> programming. It is simply about programming.
I don't say it's about procedural programming, but that it's steers one
in the direction of procedural programming.
He talks about procedures and datatypes which is the typical way
problems are solved with procedural programming languages.
When thinking along object oriented lines, you approach a problem
totally differently. You start at a higher level of abstraction,
procedures (methods) and abstract data types don't come into the picture
until much later. I agree that at that moment you can learn from Code
Complete.
> > It could have been a much better book had it either kept itself
> > to pure software process issues, or to inform the reader about
> > the object and pattern paradigms.
>
> It does talk about OO (see section 7.3 for instance). It just doesn't limit
> itself to OO, because the subjects talked about apply to OO or procedural
> programming.
> As far as design patterns, Code Complete predates the GOF book that
> introduced design patterns.
Exactly, and that why I think there are better books now.
If someone is new to programming I therefore wouldn't advice them to
pick up Code Complete, but choose something else, especially because I
think that starting from a procedural language mindset makes object-
oriented programming actually more difficult (I've been there).
The Design Patterns book however made a big impact on my thinking on
object-oriented design, I would classify it as probably the most
important book I read about designing programs.
> > Now this person was asking advice how to be a better programmer,
> > and I think going the Java road will be very apropriate for him.
>
> I agree with that much.
>
> > Code complete would focus a lot of his attention to procedural
> > language problems.
>
> No, it would talk about issues that are important in any type of
> programming.
But they are rather 'low level' issues; I mean all the talk about
abstract data types is a bit too much given that you have e.g. good
container classes in Java.
In my experience, once you have your high-level software architecture
'right', the methods and detailed types more or less 'flow' from it.
(I understand that that's ofcourse related to experience, but
nevertheless.)
In the end, it doesn't hurt to read Code Complete, although it could be
much more terse, but it isn't my number 1 recommendation to this person.
Paul
From: Dale King
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3d9333f7@news.tce.com>
"jvm" <···@fiberia.is.no.more> wrote in message
·······························@pixs.htc.nl.philips.com...
> In article <··········@news.tce.com>, ·····@TCE.com says...
> > "jvm" <···@fiberia.is.no.more> wrote in message
> > ······························@pixs.htc.nl.philips.com...
> > > In article <··················@news.cis.dfn.de>, ·····@decode.is
says...
> > > > On Fri, 20 Sep 2002 16:01:24 +0200, jvm
> > > > <···@fiberia.is.no.more> wrote:
> > > >
> > > > >In article <·····················@sccrnsc02>,
··········@notahost.org
> > > > >says...
>
> > > It's geared towards procedural programming.
> >
> > No, it is about any type of programming. He doesn't limit himself to
just
> > OO, because not everyone is programming OO (and even less were in 1993
when
> > it come out).
>
> <snip>
>
> > I find no evidence to back up your claim that it is about procedural
> > programming. It is simply about programming.
>
> I don't say it's about procedural programming, but that it's steers one
> in the direction of procedural programming.
> He talks about procedures and datatypes which is the typical way
> problems are solved with procedural programming languages.
And one encounters the same things down at the lower levels of OO
programming.
> When thinking along object oriented lines, you approach a problem
> totally differently. You start at a higher level of abstraction,
> procedures (methods) and abstract data types don't come into the picture
> until much later. I agree that at that moment you can learn from Code
> Complete.
But inside an object much of it is still very procedural. You have methods
which are not that different from functions in procedural. Certainly they
have a higher level abstraction, but underneath it is very similar.
> > > It could have been a much better book had it either kept itself
> > > to pure software process issues, or to inform the reader about
> > > the object and pattern paradigms.
> >
> > It does talk about OO (see section 7.3 for instance). It just doesn't
limit
> > itself to OO, because the subjects talked about apply to OO or
procedural
> > programming.
>
> > As far as design patterns, Code Complete predates the GOF book that
> > introduced design patterns.
>
> Exactly, and that why I think there are better books now.
I wouldn't say they are better. They add to what it is in Code Complete,
making the picture more "complete", but I don't see how any of the
information in Code Complete does not apply anymore. You just need to
augment it with additional information.
> If someone is new to programming I therefore wouldn't advice them to
> pick up Code Complete, but choose something else, especially because I
> think that starting from a procedural language mindset makes object-
> oriented programming actually more difficult (I've been there).
It certainly isn't the book I would recommend to read first, either. But I
definitely recommend reading it at some point.
Even the author says "The techniques described in this book fill the void
after introductory and advanced programming texts."
> The Design Patterns book however made a big impact on my thinking on
> object-oriented design, I would classify it as probably the most
> important book I read about designing programs.
Agreed. That is about design. Code complete is more about details of coding.
See page 3 where he shows the classical waterfall model. Code complete is
about the detailed design, coding and debugging, and unit testing portions.
Design patterns is about the architectural design portion, which is not in
the scope of Code Complete. On page 4 he shows the waterfall model with the
bubbles in proportion to their coverage in Code Complete. Coding and
Debugging is the primary focus.
> > > Now this person was asking advice how to be a better programmer,
> > > and I think going the Java road will be very apropriate for him.
> >
> > I agree with that much.
> >
> > > Code complete would focus a lot of his attention to procedural
> > > language problems.
> >
> > No, it would talk about issues that are important in any type of
> > programming.
>
> But they are rather 'low level' issues; I mean all the talk about
> abstract data types is a bit too much given that you have e.g. good
> container classes in Java.
You still have low level issues in Java. And while the implementation of
ADT's is different the concepts are meaningful.
> In my experience, once you have your high-level software architecture
> 'right', the methods and detailed types more or less 'flow' from it.
> (I understand that that's ofcourse related to experience, but
> nevertheless.)
And Code Complete helps with getting the detailed types right.
> In the end, it doesn't hurt to read Code Complete, although it could be
> much more terse, but it isn't my number 1 recommendation to this person.
It wasn't me doing the recommending (although I do recommend it). I was just
correcting the misinformation.
--
Dale King
From: Benjamin Goldberg
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3D934FCE.9881B347@earthlink.net>
Dale King wrote:
> jvm wrote:
> > helgi wrote:
[snip]
> > > The book is about programming in general and not
> > > geared towards any language or type of language.
> >
> > It's geared towards procedural programming.
>
> No, it is about any type of programming.
You need to discern the differences between imperative vs functional vs
logical programming.
What kinds of control statements exist in logical programming?
Are closures mentioned anywhere in the book?
Amongs the types of control statements listed, are "map" or "currying",
or some variant of those, mentioned?
--
Announcement in the Zoo:
"Please don't scare the ostriches! Cement floor!"
From: Dale King
Subject: Re: Use Java! Was: becoming a better programmer
Date:
Message-ID: <3d9472a7@news.tce.com>
"Benjamin Goldberg" <·······@earthlink.net> wrote in message
······················@earthlink.net...
> Dale King wrote:
> > jvm wrote:
> > > helgi wrote:
> [snip]
> > > > The book is about programming in general and not
> > > > geared towards any language or type of language.
> > >
> > > It's geared towards procedural programming.
> >
> > No, it is about any type of programming.
>
> You need to discern the differences between imperative vs functional vs
> logical programming.
We've already acknowledged that it does not really deal with functional and
logic programming as I have already stated.
--
Dale King
jvm wrote:
...
i *cannot* follow this discussion.
picking some samples brings some thoughts into my mind.
i'd like to share them.
(i'm not sure if the facts on which my thoughts are based are correct )
Steele.
one of the designers of Scheme, a Lisp dialect.
author of Common Lisp The Language (I and II)
has done many things for Common Lisp, the 'merger' of the lisp-dialects.
Lisp.
many people find lisp very-much very-good
steele.
since 1994 @sun
sun.
makes java.
don't know his influence on java.
if steele.influence-one-java-design is very-high
then java-design is very-good
at least very-high possibility that
this should be true for those people who think that Scheme is a
very-good language-design.
i don't know.
i'm a lisp novice.
and i'm udereducated.
-
loosers will loose.
winners will win.
care.
loosers will win.
winners will loose.
-
have you eaten?
Scott wrote:
> Hello!
>
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
>
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
>
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
> not too sure if he is qualified to give this type of advice...
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either. So I thought about this A LOT,
> and I'm wonderingif I could ask for advice on the internet.
>
I believe that a programming language is just a tool -- like the paint brush is
in the hand of the artist, or the guitar in the hand of the master. I think you
should find out why you want to be a programmer -- what do you want to make? I
learnt using Pascal, because that was the language we used in computer science,
learnt C++ to design an object orientated multimedia program (which is now
becoming embedded), and now program also in VB (there is plenty of money there)
and Java. The language is only the tool -- being a good engineer is about
recognising the best tool for the job and using that -- the real power is in
your logic in the algorithms you design or implement. C++ is my favourite
language because I have the full power of accessing the underlying machine that
I am programming for. It is a bit easier from when I started now that there is
a standard library, but you have a flexibility and power with C++ that you don't
get with other languages (my opinion -- maybe biased?). Once you get C++
happening Java is a snack. Additionally, you can get a C++ compiler for free
(GNU) to do some experimenting.
Make projects for yourself -- i.e. problems -- that you can write code to solve
them. You learn the language this way (it is a bit like children playing --
they are actually building their muscles and learning coordination while having fun)
Good luck
--
Angelo Fraietta
PO Box 859
Hamilton NSW 2303
Home Page
http://www.users.bigpond.com/angelo_f/
There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)
·············@yahoo.com (Scott) writes:
> as if a language is windows-only. What I do care about is learning
> something new.
learn verilog or vhdl.
design hardware.
thi
Thien-Thi Nguyen wrote:
> learn verilog or vhdl.
> design hardware.
Betcher ass.
A lot if the really good programmers I know have come out of hardware
design. It teaches modularity and functional thinking and an attempt at
minimizing or, at least, centralizing state (makes it too hard to test
otherwise).
Plus, nothing smokes out fuzziness of thought quicker than a piece of
hardware that won't run. You can run though millions of test cycles during
the time that a simulation would still be starting up, Of course, it is a
bit expensive if you take it all the way to silicon :-).
faa
Since this is a Perl group, I'll assume you're interested in Perl.
If you're interested in Internet/web programming (versus, say,
embedded controller programming), you should probably
learn Perl and Java, along with HTML, XML, CGI, and
HTTP.
For Perl, you could read through www.perlmonks.com.
It's free, and newbie-friendly.
--
If you get any important email, mHook will push it to your cell phone.
Peace of mind, at http://www.mhook.com/
"Scott" <·············@yahoo.com> wrote in message
·································@posting.google.com...
> Hello!
>
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
>
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
>
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
> not too sure if he is qualified to give this type of advice...
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either. So I thought about this A LOT,
> and I'm wonderingif I could ask for advice on the internet.
>
> Thanks in advance for your time...
avecfrites <··········@yahoo.com> scribbled the following
on comp.lang.java.programmer:
> Since this is a Perl group, I'll assume you're interested in Perl.
> If you're interested in Internet/web programming (versus, say,
> embedded controller programming), you should probably
> learn Perl and Java, along with HTML, XML, CGI, and
> HTTP.
"This is a Perl group"? Take a look where this was cross-posted to:
comp.lang.c++
comp.lang.lisp
comp.lang.java.programmer
comp.lang.perl.misc
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"C++. C++ run. Run, ++, run."
- JIPsoft
Joona I Palaste wrote:
> avecfrites <··········@yahoo.com> scribbled the following
> on comp.lang.java.programmer:
>
>>Since this is a Perl group, I'll assume you're interested in Perl.
>>If you're interested in Internet/web programming (versus, say,
>>embedded controller programming), you should probably
>>learn Perl and Java, along with HTML, XML, CGI, and
>>HTTP.
>>
>
> "This is a Perl group"? Take a look where this was cross-posted to:
> comp.lang.c++
> comp.lang.lisp
> comp.lang.java.programmer
> comp.lang.perl.misc
Can you say "flamewar"?
--
Thomas Stegen
Scott <·············@yahoo.com> wrote:
> So, one of my friends tells me that I should learn C++, because "it's the
> best". But, seriously, he doesn't know anything but C++, so I'm not too
> sure if he is qualified to give this type of advice... Another friend
> tells me "define what you mean by 'better programmer'". So, that guy
> wasn't too helpful either. So I thought about this A LOT, and I'm
> wonderingif I could ask for advice on the internet.
Figure out what you'd have to the most fun programming right now, then
just sit down and hit that huge wall of "what now"-problems and start
tearing it down.
/t
--
# Per scientiam ad libertatem! // Through knowledge towards freedom! #
# Genom kunskap mot frihet! =*= (c) 1999-2002 ····@svanstrom.com =*= #
perl -e'print$_{$_} for sort%_=`lynx -source svanstrom.com/t`'
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
·············@yahoo.com (Scott) wrote in
·································@posting.google.com:
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which.
...
>
> Thanks in advance for your time...
In my opinion, you should learn MANY languages. You won't necessarily
use then, and don't learn them all at once (that's confusing), but
knowing how different languages approach similar problems, and knowing
the strengths and weaknesses of various languages, is an excellent way to
become a better programmer.
I would especially encourage you to learn an assembly language at some
point. You may never use it (you will probably never use it), but
knowing how the computer operates at its lowest level is extremely
useful, and will give you an edge over programmers who don't know that.
Aside from knowing several languages, the next best thing you can do is
to learn various algorithms and techniques, and how they're done in
various languages. Take a course on data structures and/or algorithms.
It may be confusing and abstract, but you'll be surprised years down the
road how much you use the information.
Also, along the way, it would behoove you to develop your own programming
style -- how you lay a program out, how you use variables, how you name
them, how you organize things to minimize your effort and the number of
bugs that you introduce. You will acquire your own style over time,
especially as you review your programs after they're written and as you
read code that others have written.
Good luck! :-)
- --
Eric
print scalar reverse sort qw p ekca lre reh
ts uJ p, $/.r, map $_.$", qw e p h tona e;
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPYR1mmPeouIeTNHoEQKkqgCgiuH5BbwPp+s046kQIrYIcnau1sIAoJW6
NfOa+xCh4DCgRwjQA2OFfp8D
=byAQ
-----END PGP SIGNATURE-----
Eric J. Roode wrote:
...
> I would especially encourage you to learn an assembly language at some
> point. You may never use it (you will probably never use it), but
> knowing how the computer operates at its lowest level is extremely
> useful, and will give you an edge over programmers who don't know that.
While the model presented by an assembly language is a useful level to
know, it is way above "how the computer operates at its lowest level".
It is just a symbolic representation of the lowest level that is
directly available to the programmer.
> Also, along the way, it would behoove you to develop your own programming
> style -- how you lay a program out, how you use variables, how you name
> them, how you organize things to minimize your effort and the number of
> bugs that you introduce. You will acquire your own style over time,
> especially as you review your programs after they're written and as you
> read code that others have written.
Don't get too wedded to any one style. Flexibility in styles is just as
valuable as flexibility in choice of language.
A style that works well in one language may not work so well in another.
For example, languages have different rules about where variable
declarations can be placed.
Also, large projects often have a required style for all code in the
project.
Patricia
Eric J. Roode wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ·············@yahoo.com (Scott) wrote in
> ·································@posting.google.com:
>
>
>>HOwever, I realized that I want to be better at this stuff and learn
>>more about programming. It's fascinating. I talked to some of my
>>friedns and told them that I want to be a better programmer. I'm
>>thinking of learning a new programming language, but I do not know
>>which.
>
> ...
>
>>Thanks in advance for your time...
>
>
> In my opinion, you should learn MANY languages. You won't necessarily
> use then, and don't learn them all at once (that's confusing), but
> knowing how different languages approach similar problems, and knowing
> the strengths and weaknesses of various languages, is an excellent way to
> become a better programmer.
I totally agree and want to add that you should make sure to not only
learn different languages but also languages from different programming
paradigms. Different problems need different approaches, and to know
different approaches means to be able to solve more problems adequately.
Here are some suggestions:
* functional programming: Scheme, ML, Haskell
* imperative programming: Pascal, Modula-2, C
* object-oriented programming: Java, Smalltalk, Ruby, gbeta
* logic programming: Prolog
Some other languages allow to you to mix various paradigms: C++, Common
Lisp, Objective CAML, Python, Leda
Also make sure in the long run that you get to know both dynamically
typed (for example Scheme, Lisp, Smalltalk) and statically typed
languages (for example Haskell, gbeta, CAML, Java).
(I have definitely forgotten some, and the categorization is surely not
exhaustive.)
It will take you a while to become a really good programmer but it's
worth it. There's no general recommendation which language to start
with, just go with your gut feelings. There is no single "best"
language, all have their different tradeoffs and resolve different sets
of forces. And don't believe in hype: current trendy languages are not
necessarily good languages to start with with regard to the learning
perspective. (However, it might be good for economical reasons to
include them in the long run. ;)
All the best,
Pascal
On Sun, 15 Sep 2002 09:27:49 -0300, Pascal Costanza wrote:
(karate chop here)
> I totally agree and want to add that you should make sure to not only
> learn different languages but also languages from different programming
> paradigms. Different problems need different approaches, and to know
> different approaches means to be able to solve more problems adequately.
>
> Here are some suggestions:
>
> * functional programming: Scheme, ML, Haskell * imperative programming:
> Pascal, Modula-2, C * object-oriented programming: Java, Smalltalk,
> Ruby, gbeta * logic programming: Prolog
>
> Some other languages allow to you to mix various paradigms: C++, Common
> Lisp, Objective CAML, Python, Leda
>
> Also make sure in the long run that you get to know both dynamically
> typed (for example Scheme, Lisp, Smalltalk) and statically typed
> languages (for example Haskell, gbeta, CAML, Java).
>
> (I have definitely forgotten some, and the categorization is surely not
> exhaustive.)
>
>
What about Eiffel's "design by contract" approach?
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
I have been prgramming 30+ years and agree with this! I'd like to
add Forth to the language list here. Haven't used it for years, but
it taught me how to factor an application/system/program to the
proper pieces!!! I am sure that my coding style for every programming
language I have learned since then is influenced by what I learned
in programming Forth!
Also, there is a long out of print book called "Thinking Forth" that
would be an all time computer science classid if it had been written
about C (same time period). If you can get past the Forth examples,
it will teach you a lot about system design!!!
Norm
Pascal Costanza <········@web.de> wrote in message news:<················@web.de>...
> Eric J. Roode wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > ·············@yahoo.com (Scott) wrote in
> > ·································@posting.google.com:
> >
> >
> >>HOwever, I realized that I want to be better at this stuff and learn
> >>more about programming. It's fascinating. I talked to some of my
> >>friedns and told them that I want to be a better programmer. I'm
> >>thinking of learning a new programming language, but I do not know
> >>which.
> >
> > ...
> >
> >>Thanks in advance for your time...
> >
> >
> > In my opinion, you should learn MANY languages. You won't necessarily
> > use then, and don't learn them all at once (that's confusing), but
> > knowing how different languages approach similar problems, and knowing
> > the strengths and weaknesses of various languages, is an excellent way to
> > become a better programmer.
>
> I totally agree and want to add that you should make sure to not only
> learn different languages but also languages from different programming
> paradigms. Different problems need different approaches, and to know
> different approaches means to be able to solve more problems adequately.
>
> Here are some suggestions:
>
> * functional programming: Scheme, ML, Haskell
> * imperative programming: Pascal, Modula-2, C
> * object-oriented programming: Java, Smalltalk, Ruby, gbeta
> * logic programming: Prolog
>
> Some other languages allow to you to mix various paradigms: C++, Common
> Lisp, Objective CAML, Python, Leda
>
> Also make sure in the long run that you get to know both dynamically
> typed (for example Scheme, Lisp, Smalltalk) and statically typed
> languages (for example Haskell, gbeta, CAML, Java).
>
> (I have definitely forgotten some, and the categorization is surely not
> exhaustive.)
>
> It will take you a while to become a really good programmer but it's
> worth it. There's no general recommendation which language to start
> with, just go with your gut feelings. There is no single "best"
> language, all have their different tradeoffs and resolve different sets
> of forces. And don't believe in hype: current trendy languages are not
> necessarily good languages to start with with regard to the learning
> perspective. (However, it might be good for economical reasons to
> include them in the long run. ;)
>
> All the best,
> Pascal
On Sun, 15 Sep 2002 08:56:19 -0300, Eric J. Roode wrote:
> n my opinion, you should learn MANY languages.
Many different approcahes? Functional, pure OOP, strong typed, weak
typed, scripting, etc
> I would especially encourage you to learn an assembly language at some
> point. You may never use it (you will probably never use it), but
> knowing how the computer operates at its lowest level is extremely
> useful, and will give you an edge over programmers who don't know that.
>
>
Is HLA (High Level Assembly) adequate? It's asembly, but it's got a
C-like syntax.
Regs
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
·············@yahoo.com (Scott) wrote in message news:<····························@posting.google.com>...
> Hello!
>
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
>
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
>
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
> not too sure if he is qualified to give this type of advice...
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either. So I thought about this A LOT,
> and I'm wonderingif I could ask for advice on the internet.
>
> Thanks in advance for your time...
Hi Scott
I have been programming for over 27 years now, and during that time I
have mastered well over a dozen languages that most folks probably
never even heard of.
Please do not pay attention to those who are saying that it really
does not matter what tool you use as long as <bla bla bla>. What tool
you use affects your thinking in very drastic ways that you may not
even realize.
As much as I would like to give a specific computer language
recommendation, it is hard:
As someone correctly mentioned you should certainly stay from hype
languages like Java, Perl, etc. They may make you more employable in
the short term, but in the long term they will make a crappy
programmer out of your, and there's no going back: bad habbits die
hard.
Many people expected a lot from Lisp, and given your background in
Scheme, Lisp would seem like a reasonable next step. The industry
realized over the years that while Lisp makes a fine language for
certain niche small to medium size projects, it has two serious
drawbacks: firstly, maintainability issues arise, because Lisp
programmers can never understand each other's code, and secondly, Lisp
teaches you bad programming style, as your code is usually a mess of
if's, conds, and so on. That is why it almost lost its relevance by
now. I can not say that I'm glad, because a lof of my own expertise is
wasted. Oh well, that's life.
I was one of the early adopters when C++ came out (C with classes),
and I'm still very fond of it. I think the standardization committee
and Bjarnee have done a wonderful job. C++, of course has its own
drawbacks, the most important of which being that you must not be a
half-wit if you want to learn to use it correctly. If you lack in the
brains department, you can still make a decent living as a programmer
coding in shite like Java or VB.
So it all depends on your own mental abilities and on your dedication
Good luck!
Alec wrote:
>
> As someone correctly mentioned you should certainly stay from hype
> languages like Java, Perl, etc.
Excuse me, I don't want to start a flame war but, under what definition
of hype are you using to define Perl?
John
--
use Perl;
program
fulfillment
"John W. Krahn" <······@acm.org> wrote in message news:<·················@acm.org>...
> Alec wrote:
> >
> > As someone correctly mentioned you should certainly stay from hype
> > languages like Java, Perl, etc.
>
> Excuse me, I don't want to start a flame war but, under what definition
> of hype are you using to define Perl?
>
>
> John
When I say "hype" languages, I am not merely referring to languages
that are popular, but those that are at the same time mediocre or bad.
For them, popularity comes from aggressive marketing, etc. In case of
Java, it was Sun's desire to take a bite of Microsoft's market, and in
case of Perl, it was a bunch of things, not the least of which was
OReilly of course. If it were up to them, they would be feeding us new
revolutionary "tech" every month.
Alec wrote:
>
> "John W. Krahn" <······@acm.org> wrote in message news:<·················@acm.org>...
> > Alec wrote:
> > >
> > > As someone correctly mentioned you should certainly stay from hype
> > > languages like Java, Perl, etc.
> >
> > Excuse me, I don't want to start a flame war but, under what definition
> > of hype are you using to define Perl?
> >
> >
> > John
>
> When I say "hype" languages, I am not merely referring to languages
> that are popular, but those that are at the same time mediocre or bad.
> For them, popularity comes from aggressive marketing, etc. In case of
> Java, it was Sun's desire to take a bite of Microsoft's market, and in
> case of Perl, it was a bunch of things, not the least of which was
> OReilly of course. If it were up to them, they would be feeding us new
> revolutionary "tech" every month.
You might want to read "Java's Cover" on www.paulgraham.com, which
states the reasons why its author has avoided Java.
An interesting point not mentioned by Paul Graham but which adds
weight to his argument, is that Java was originally designed to
run in embedded devices, then in web browsers, and now on servers.
I don't know of any widespread use of devices with embedded Java,
most people browse the web with Java switched off (to be fair,
there are some interesting applets out there, but they are few and
far between), and you can write server software in any language
so there's no reason to use Java. I was expecting until very
recently that it would gradually become extinct over the next five
years, but it seems to have an even worse fate in store -- as a
replacement for Cobol. So there's still money to be made out
of it, but a career in accountancy seems the more interesting
option.
Perl I don't know enough about to decide whether it has merits,
but its designer seems to think a complex syntax is a good thing
for a language (as a Lisper I couldn't disagree more), and I've
been warned off it by people who do know it well, but have now
switched to Python.
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Donald Fisk <················@enterprise.net> writes:
> You might want to read "Java's Cover" on www.paulgraham.com, which
> states the reasons why its author has avoided Java.
> An interesting point not mentioned by Paul Graham but which adds
> weight to his argument, is that Java was originally designed to
> run in embedded devices, then in web browsers, and now on servers.
> I don't know of any widespread use of devices with embedded Java,
> most people browse the web with Java switched off (to be fair,
> there are some interesting applets out there, but they are few and
> far between), and you can write server software in any language
> so there's no reason to use Java. I was expecting until very
> recently that it would gradually become extinct over the next five
> years, but it seems to have an even worse fate in store -- as a
> replacement for Cobol. So there's still money to be made out
> of it, but a career in accountancy seems the more interesting
> option.
You're absolutely wrong that most people browse the web with Java
turned off. All indications I've seen from server logs indicate that
the vast majority of web users use IE with Javascript and Java on.
Common sense would confirm that: because IE (the #1 browser) and
Netscape (a distant second) both ship with JS and Java on, of *course*
most users have them on -- how many people would (know to) / (know how to)
/ (want to) turn them off? I'm sure *you* have Java off, and probably
most people you know (or have discussed this with) do too. I know I
do, and I only turn it on when I need to and am willing to trust the
site. Many people I know do the same thing. But I'm not typical, and
the people I've asked about this aren't either.
And I'm actually kind of glad. I can assume that all the people who
use a site *can* use Java, which means I can use it to deliver small
applications. This is a godsend for me, because I use Solaris, Linux,
and Mac OS X -- which isn't very useful if I want to develop an
application for J. Random Webuser. I suppose I could do it in Lisp or
Smalltalk, but then I need the user to install the runtime support.
Sure, the JVMs in the browsers stink, but they're already there, and
don't require me to hunt down a Windows box to develop on.
And while it's true that I can generally use whatever language I want
on a server, I sometimes use Java because it can be easier to use the
same language on both the front and back ends. When I don't get any
particular benefit from that homogeneity, I don't hesitate to write
the backend in Lisp, but there can be a definate benefit to using Java
on the server -- entirely because all web browsers have JVMs built in.
> Perl I don't know enough about to decide whether it has merits,
> but its designer seems to think a complex syntax is a good thing
> for a language (as a Lisper I couldn't disagree more), and I've
> been warned off it by people who do know it well, but have now
> switched to Python.
Why do you use Python instead of Lisp? I don't particularly like
Perl, but I can live with it, and I use it when it's practical -- and
it's often practical because it's a widely-accepted Unix
scripting/small-app language. I wouldn't consider Python, because
it's not reasonable to assume that it's on a typical Unix server, or
that another developer knows it. With those benefits gone, I'll
choose Lisp 6.5 days of the week (the other 12 hours, I'll use
Smalltalk ;)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d8a6e88@news.tce.com>
"Thomas F. Burdick" <···@hurricane.OCF.Berkeley.EDU> wrote in message
····················@hurricane.OCF.Berkeley.EDU...
> Donald Fisk <················@enterprise.net> writes:
>
> > You might want to read "Java's Cover" on www.paulgraham.com, which
> > states the reasons why its author has avoided Java.
> > An interesting point not mentioned by Paul Graham but which adds
> > weight to his argument, is that Java was originally designed to
> > run in embedded devices, then in web browsers, and now on servers.
> > I don't know of any widespread use of devices with embedded Java,
> > most people browse the web with Java switched off (to be fair,
> > there are some interesting applets out there, but they are few and
> > far between), and you can write server software in any language
> > so there's no reason to use Java. I was expecting until very
> > recently that it would gradually become extinct over the next five
> > years, but it seems to have an even worse fate in store -- as a
> > replacement for Cobol. So there's still money to be made out
> > of it, but a career in accountancy seems the more interesting
> > option.
>
> You're absolutely wrong that most people browse the web with Java
> turned off. All indications I've seen from server logs indicate that
> the vast majority of web users use IE with Javascript and Java on.
> Common sense would confirm that: because IE (the #1 browser) and
> Netscape (a distant second) both ship with JS and Java on, of *course*
> most users have them on -- how many people would (know to) / (know how to)
> / (want to) turn them off? I'm sure *you* have Java off, and probably
> most people you know (or have discussed this with) do too. I know I
> do, and I only turn it on when I need to and am willing to trust the
> site. Many people I know do the same thing. But I'm not typical, and
> the people I've asked about this aren't either.
And he is also wrong about widespread use of Java in embedded systems. Java
is widely used in cell phones.
--
Dale King
Dale King wrote:
> And he is also wrong about widespread use of Java in embedded systems. Java
> is widely used in cell phones.
Any particular reason why? What does Java offer for cellphone
applications that C or C++ doesn't?
> Dale King
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d8b9037@news.tce.com>
"Donald Fisk" <················@enterprise.net> wrote in message
······················@enterprise.net...
> Dale King wrote:
>
> > And he is also wrong about widespread use of Java in embedded systems.
Java
> > is widely used in cell phones.
>
> Any particular reason why? What does Java offer for cellphone
> applications that C or C++ doesn't?
Primarily write once, run anywhere (WORA). One can write a J2ME application
for the cell-phone market and it can run on different phones, from different
manufacturers, running on different processors, running different operating
systems, without recompiling. Contrast this to the PDA market where programs
are different for Palm vs. PocketPC and even within the Windows CE O/S you
have different executables for different processors (MIPS vs. SHA-1).
Java code is also usually a bit more compact than equivalent object code,
which is also a concern for the bandwidth limited nature of cell phones.
--
Dale King
"Dale King" <·····@TCE.com> writes:
> "Donald Fisk" <················@enterprise.net> wrote in message
> ······················@enterprise.net...
> > Dale King wrote:
> >
> > > And he is also wrong about widespread use of Java in embedded systems.
> Java
> > > is widely used in cell phones.
> >
> > Any particular reason why? What does Java offer for cellphone
> > applications that C or C++ doesn't?
>
>
> Primarily write once, run anywhere (WORA). One can write a J2ME application
> for the cell-phone market and it can run on different phones, from different
> manufacturers, running on different processors, running different operating
> systems, without recompiling. Contrast this to the PDA market where programs
> are different for Palm vs. PocketPC and even within the Windows CE O/S you
> have different executables for different processors (MIPS vs. SHA-1).
Write once, run anywhere is a proven failure in other
areas. Is there any reason to think that the situation will be
different on mobile equipment?
> Java code is also usually a bit more compact than equivalent object code,
> which is also a concern for the bandwidth limited nature of cell phones.
I'm not so sure that Java code is more compact than ARM
"thumb" code, which is commonly found in mobile phones. Further, Java
code is likely to be slower than native code in the absence of JIT
technology, and JIT technology requires large amounts of RAM, which is
typically a scarce resource in a mobile phone. If the Java
alternative is slower, it stands to reason that the processor must be
clocked faster for a given performance point, which means greater
power consumption - another no-no in a mobile phone.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
* Raymond Wiker
| Write once, run anywhere is a proven failure in other areas.
All software written to a standard specification is portable to conforming
translators and execution environments. Has this been a failure more often
than not? Have most American or International standards failed? I believe
otherwise. What we have is a number of reasons that things have failed that
are fairly unrelated to the specification. I have a hunch you were satisfied
with observations that supported a simple conclusion rather than looking
carefully at more reasons things failed.
| Is there any reason to think that the situation will be different on mobile
| equipment?
Is there any reason to believe the situation will be the /same/ as the long
list of failures you think are important enough to overshadow this project?
And how long is that list, anyway?
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Raymond Wiker <·············@fast.no> wrote:
> "Dale King" <·····@TCE.com> writes:
>
>> "Donald Fisk" <················@enterprise.net> wrote in message
>> ······················@enterprise.net...
>> > Dale King wrote:
>> >
>> > > And he is also wrong about widespread use of Java in embedded systems.
>> Java
>> > > is widely used in cell phones.
>> >
>> > Any particular reason why? What does Java offer for cellphone
>> > applications that C or C++ doesn't?
>>
>> Primarily write once, run anywhere (WORA). One can write a J2ME
>> application for the cell-phone market and it can run on different
>> phones, from different manufacturers, running on different
>> processors, running different operating systems, without
>> recompiling. Contrast this to the PDA market where programs are
>> different for Palm vs. PocketPC and even within the Windows CE O/S
>> you have different executables for different processors (MIPS
>> vs. SHA-1).
>
> Write once, run anywhere is a proven failure in other areas. Is
> there any reason to think that the situation will be different on
> mobile equipment?
Mobile equipment is smaller in terms of size, but more importantly, in
terms of overall features. There has not been as much incentive to
add in /great gobs/ of local functionality as has been the case with
Windows, OS/2, MacOS, and such.
The platform is is small enough that there's not the incentive to add
vast amounts of "bloatware."
>> Java code is also usually a bit more compact than equivalent object
>> code, which is also a concern for the bandwidth limited nature of
>> cell phones.
> I'm not so sure that Java code is more compact than ARM "thumb"
> code, which is commonly found in mobile phones. Further, Java code
> is likely to be slower than native code in the absence of JIT
> technology, and JIT technology requires large amounts of RAM, which
> is typically a scarce resource in a mobile phone. If the Java
> alternative is slower, it stands to reason that the processor must
> be clocked faster for a given performance point, which means greater
> power consumption - another no-no in a mobile phone.
There's certainly not the incentive to do stupid things that bloat up
the code as happens when you've got 1024x768 pixels to play with.
There's little value in adding the bloat of 'theme engines' or special
"prettified widgets sets."
In the absence of "great gobs of memory," developers /can't/ fritter
memory away on frivolous glitter, and and in the absence of that
"frittering away of memory," and in the absence of needing to populate
a SVGA screen with "full color" images, they don't /need/ great gobs
of memory or CPU power.
I'm skeptical that ARM "thumb code" /won't/ be a fair bit bigger than
bytecode; historically, bytecode is quite a lot smaller than native
code, /which is a win for them,/ JIT or not.
J2ME appears to be be a viable platform for deploying code on multiple
cell phones. It's possible that deploying native code could be
marginally more efficient, but that then opens the balls of worms of
"what APIs?" back up, and throws away reason to be interested in
interoperability.
J2ME belongs to Sun, who has little reason to care about any one phone
manufacturer over the others, which means that while it may be a
"poor" lowest common denominator for the reasons you suggest, that may
still be a better LCD than they'd have if Nokia and Erikkson and
Motorola and such were all trying to pull the old "Sun NeWS/NeXTstep"
thing of trying to dominate the industry with APIs that favor one of
those vendors.
Java is pretty bad; the alternatives may /overall/ be worse, despite
there being some merits of improved code efficiency.
--
(concatenate 'string "chris" ·@cbbrowne.com")
http://cbbrowne.com/info/multiplexor.html
Chad has brought us a brilliant new twist: "Nobody has ever been a bad
parent by buying Microsoft."
-- David Steinberg <········@interchange.ubc.ca>
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d8f2980@news.tce.com>
"Raymond Wiker" <·············@fast.no> wrote in message
···················@raw.grenland.fast.no...
> "Dale King" <·····@TCE.com> writes:
>
> > "Donald Fisk" <················@enterprise.net> wrote in message
> > ······················@enterprise.net...
> > > Dale King wrote:
> > >
> > > > And he is also wrong about widespread use of Java in embedded
systems.
> > Java
> > > > is widely used in cell phones.
> > >
> > > Any particular reason why? What does Java offer for cellphone
> > > applications that C or C++ doesn't?
> >
> >
> > Primarily write once, run anywhere (WORA). One can write a J2ME
application
> > for the cell-phone market and it can run on different phones, from
different
> > manufacturers, running on different processors, running different
operating
> > systems, without recompiling. Contrast this to the PDA market where
programs
> > are different for Palm vs. PocketPC and even within the Windows CE O/S
you
> > have different executables for different processors (MIPS vs. SHA-1).
>
> Write once, run anywhere is a proven failure in other
> areas. Is there any reason to think that the situation will be
> different on mobile equipment?
Is there any reason to think I was making a statement about the success of
WORA? I wasn't, but I will now in response.
Where has WORA been a proven failure? It certainly hasn't been in the case
of Java. On the contrary it has been a great success. You can certainly
write an application in Java that will run on Windoze, Linux, Macintosh,
OS/390, and Solaris using the same compiled code for all. That is what
WORA is all about. I did not say that achieving that is always automatic.
Sometimes it takes work. Sometimes you have to debug on the different
platforms and sometimes you have to compensate for incompatibilities in
VM's. But it is possible and has been done countless times, primarily in
business settings where you are more likely to see heterogeneous platforms.
None of those things constitute failure of WORA. You often face the same
things just trying to write for Windoze and facing incompatibilities from
the different versions of Windoze. Yet we don't call Windoze programming a
failure.
And there are many reasons why it should be (and currently is) very
successful in the J2ME space. For one thing, you are dealing with a much
smaller set of API's. The fast majority of incompatibilities occur in
relationship to UI components, like AWT. You don't have as much of that to
worry about as you have a different and simpler UI.
Also you are not trying to run Java on some long established platform that
was not designed with Java in mind. The platform is new and can be designed
with Java in mind.
Also currently the monopolist is not competing in that space using illegal
practices as it has done in the desktop space. You have companies that are
not threatened by Java in that space.
> > Java code is also usually a bit more compact than equivalent object
code,
> > which is also a concern for the bandwidth limited nature of cell phones.
>
> I'm not so sure that Java code is more compact than ARM
> "thumb" code, which is commonly found in mobile phones.
I imagine that it is still slightly more compact. It probably consumes more
resources on the actual machine, but download wise is small. The scope of
the standard API's make a difference here to. Java has an extensive set of
core API's that lessen the size of the user code. That of course can be done
in other languages as well, but to date really has not been done as much as
with Java.
> Further, Java
> code is likely to be slower than native code in the absence of JIT
> technology,
Agreed, but speed is not a huge factor in this space. Consider the limited
size of the display. The applications are interactive and spend most of
their time waiting on the user.
> and JIT technology requires large amounts of RAM, which is
> typically a scarce resource in a mobile phone.
No argument there. That is why they use a reduced JVM like the KVM or CVM.
> If the Java
> alternative is slower, it stands to reason that the processor must be
> clocked faster for a given performance point, which means greater
> power consumption - another no-no in a mobile phone.
But the performance point is considerably lower in this case. How much
processing are you going to do with only a 4-line text display for example?
--
Dale King
"Dale King" <·····@TCE.com> wrote in message news:<········@news.tce.com>...
> That is what
> WORA is all about. I did not say that achieving that is always automatic.
> Sometimes it takes work. Sometimes you have to debug on the different
> platforms and sometimes you have to compensate for incompatibilities in
> VM's.
Which is why WODE is a more truthful acronym for Java:
Write Once Debug Everywhere
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d909e04@news.tce.com>
"Raffael Cavallaro" <·······@mediaone.net> wrote in message
·································@posting.google.com...
> "Dale King" <·····@TCE.com> wrote in message
news:<········@news.tce.com>...
> > That is what
> > WORA is all about. I did not say that achieving that is always
automatic.
> > Sometimes it takes work. Sometimes you have to debug on the different
> > platforms and sometimes you have to compensate for incompatibilities in
> > VM's.
>
> Which is why WODE is a more truthful acronym for Java:
>
> Write Once Debug Everywhere
No it is write once, occasionally debug multiple places. That is still light
years ahead of rewrite everywhere, recompile everywhere, debug everywhere.
--
Dale King
Dale King wrote:
>
>"Raffael Cavallaro" <·······@mediaone.net> wrote in message
>·································@posting.google.com...
>> "Dale King" <·····@TCE.com> wrote in message
>news:<········@news.tce.com>...
>> > That is what
>> > WORA is all about. I did not say that achieving that is always
>automatic.
>> > Sometimes it takes work. Sometimes you have to debug on the different
>> > platforms and sometimes you have to compensate for incompatibilities in
>> > VM's.
>>
>> Which is why WODE is a more truthful acronym for Java:
>>
>> Write Once Debug Everywhere
>
>No it is write once, occasionally debug multiple places. That is still light
>years ahead of rewrite everywhere, recompile everywhere, debug everywhere.
But it is not ahead of write once, run anywhere, which you already have with perl.
Raffael Cavallaro <················@mac.com> wrote in
····························@rwcrnsc51.ops.asp.att.net:
> Dale King wrote:
>
>>
>>"Raffael Cavallaro" <·······@mediaone.net> wrote in message
>>·································@posting.google.com...
>>> "Dale King" <·····@TCE.com> wrote in message
>>news:<········@news.tce.com>...
>>> > That is what
>>> > WORA is all about. I did not say that achieving that is always
>>automatic.
>>> > Sometimes it takes work. Sometimes you have to debug on the
>>> > different platforms and sometimes you have to compensate for
>>> > incompatibilities in VM's.
>>>
>>> Which is why WODE is a more truthful acronym for Java:
>>>
>>> Write Once Debug Everywhere
>>
>>No it is write once, occasionally debug multiple places. That is still
>>light years ahead of rewrite everywhere, recompile everywhere, debug
>>everywhere.
>
> But it is not ahead of write once, run anywhere, which you already
> have with perl.
>
>
Well this is not completely true. My ex boss was playing with some perl
code, 6509 disasembler, that was orignaly written for unix and it was not
working. The problem was that perl by default on windows opens all files
as text. Once we edited the source and declaired the file handle binary
all worked well. But it took a sourcecode edit to a working program to
make it work here(win32).
marc
On Sat, 28 Sep 2002 06:24:41 GMT, Marc Spitzer
<········@optonline.net> wrote:
> Well this is not completely true. My ex boss was playing with some
> perl code, 6509 disasembler, that was orignaly written for unix and
> it was not working. The problem was that perl by default on windows
> opens all files as text.
That's the default regardless of platform. It so happens that there
is no difference on UNIX and MacOS but there is on VMS and Windows.
> Once we edited the source and declaired the file handle binary all
> worked well. But it took a sourcecode edit to a working program to
> make it work here(win32). ^^^^^^^^^^^^^^^
That isn't the same as correct. :-)
So the original program was wrong. It treated the file as binary, but
never set binmode() on the file. The Perl FAQ points you to this
function ("How do I handle binary data correctly?") and the manual
page for binmode() explains that it should be used whenever the file
is treated as binary data regardless of platform. The _correct_
program executes correctly on all platforms. :-)
--
Garry Williams
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3bs6i1fcf.fsf@cley.com>
* Raffael Cavallaro wrote:
> But it is not ahead of write once, run anywhere, which you already have with perl.
Cool, can I run perl in my phone? It has Java.
--tim
Raffael Cavallaro <················@mac.com> writes:
> But it is not ahead of write once, run anywhere, which you already have with perl.
Written much perl which uses signals, have you?
[OK, maybe a bit unfair, but only a bit.]
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d987569@news.tce.com>
"Raffael Cavallaro" <················@mac.com> wrote in message
····························@rwcrnsc51.ops.asp.att.net...
> Dale King wrote:
>
> >
> >"Raffael Cavallaro" <·······@mediaone.net> wrote in message
> >·································@posting.google.com...
> >> "Dale King" <·····@TCE.com> wrote in message
> >news:<········@news.tce.com>...
> >> > That is what
> >> > WORA is all about. I did not say that achieving that is always
> >automatic.
> >> > Sometimes it takes work. Sometimes you have to debug on the different
> >> > platforms and sometimes you have to compensate for incompatibilities
in
> >> > VM's.
> >>
> >> Which is why WODE is a more truthful acronym for Java:
> >>
> >> Write Once Debug Everywhere
> >
> >No it is write once, occasionally debug multiple places. That is still
light
> >years ahead of rewrite everywhere, recompile everywhere, debug
everywhere.
>
> But it is not ahead of write once, run anywhere, which you already have
with perl.
I'm getting awfully tired of putting of people sticking words into my mouth.
I never even mentioned perl in this thread. I actually thought of mentioning
perl as another successful case of WORA, but since I am not a perl expert I
didn't want to go out on a limb.
--
Dale King
On Sun, 22 Sep 2002 21:33:36 -0500,
Dale King <·····@TCE.com> wrote:
>
> Where has WORA been a proven failure?
Try one out of a dozen (German) homebanking java applets,
which usually work on windows, but fail at different
stages when used on linux or Macintosh with different browsers.
When the environment has support for platform specific
features, programmers will use them, and the promise
of WORA is a thing of the past.
s.
"Dale King" <·····@TCE.com> writes:
> "Raymond Wiker" <·············@fast.no> wrote in message
> ···················@raw.grenland.fast.no...
> >
> > Write once, run anywhere is a proven failure in other
> > areas. Is there any reason to think that the situation will be
> > different on mobile equipment?
>
> Is there any reason to think I was making a statement about the success of
> WORA? I wasn't, but I will now in response.
>
> Where has WORA been a proven failure? It certainly hasn't been in the case
> of Java. On the contrary it has been a great success. You can certainly
> write an application in Java that will run on Windoze, Linux, Macintosh,
> OS/390, and Solaris using the same compiled code for all. That is what
> WORA is all about. I did not say that achieving that is always automatic.
> Sometimes it takes work. Sometimes you have to debug on the different
> platforms and sometimes you have to compensate for incompatibilities in
> VM's. But it is possible and has been done countless times, primarily in
> business settings where you are more likely to see heterogeneous platforms.
This is exactly why I would consider WORA a failure, or at
least a concept that has not lived up to its hype. If you have to
debug on several platforms and code for platform differences, you're
really in much the same situation as you are with other languages -
the main difference is that you have a single binary, and the porting
effort is hopefully smaller. There are several other languages (or
implementations thereof) that provide platform-independent byte-code
formats, and source distribution may even be an option in some cases.
> None of those things constitute failure of WORA. You often face the same
> things just trying to write for Windoze and facing incompatibilities from
> the different versions of Windoze. Yet we don't call Windoze programming a
> failure.
Well, *I* consider Windows programming a failure, and that's
even without considering different versions :-) I did Windows
programming (Visual Studio/C++) for two years, and I'd rather give up
programming and becoming a goat farmer on the west coast of Norway before
doing that again.
> And there are many reasons why it should be (and currently is) very
> successful in the J2ME space. For one thing, you are dealing with a much
> smaller set of API's. The fast majority of incompatibilities occur in
> relationship to UI components, like AWT. You don't have as much of that to
> worry about as you have a different and simpler UI.
But in that case, you're that much likely to require
functionality outside the common platform, no?
> Also you are not trying to run Java on some long established platform that
> was not designed with Java in mind. The platform is new and can be designed
> with Java in mind.
>
> Also currently the monopolist is not competing in that space using illegal
> practices as it has done in the desktop space. You have companies that are
> not threatened by Java in that space.
Hum. The monopolist is very interested in becoming a
monopolist in the mobile arena, too.
> > > Java code is also usually a bit more compact than equivalent object
> code,
> > > which is also a concern for the bandwidth limited nature of cell phones.
> >
> > I'm not so sure that Java code is more compact than ARM
> > "thumb" code, which is commonly found in mobile phones.
>
> I imagine that it is still slightly more compact. It probably consumes more
> resources on the actual machine, but download wise is small. The scope of
> the standard API's make a difference here to. Java has an extensive set of
> core API's that lessen the size of the user code. That of course can be done
> in other languages as well, but to date really has not been done as much as
> with Java.
I'm not all that worried about download size (but maybe I
should be :-). On the other hand, it makes economical sense to
minimize the memory requirements of the platform, especially since
we're talking about very high volumes of devices.
> > Further, Java
> > code is likely to be slower than native code in the absence of JIT
> > technology,
>
> Agreed, but speed is not a huge factor in this space. Consider the limited
> size of the display. The applications are interactive and spend most of
> their time waiting on the user.
>
> > and JIT technology requires large amounts of RAM, which is
> > typically a scarce resource in a mobile phone.
>
> No argument there. That is why they use a reduced JVM like the KVM or CVM.
>
> > If the Java
> > alternative is slower, it stands to reason that the processor must be
> > clocked faster for a given performance point, which means greater
> > power consumption - another no-no in a mobile phone.
>
> But the performance point is considerably lower in this case. How much
> processing are you going to do with only a 4-line text display for example?
Well, if the Java code is only to be used to put text on a
4-line display, then it may not be an issue. On the other hand, I
think that most(?) mobile telephones use a single processor for
controlling the hardware as well as running "applications", so you
should keep this issue in mind.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
In article <········@news.tce.com>, ·····@TCE.com says...
> "Raymond Wiker" <·············@fast.no> wrote in message
> ···················@raw.grenland.fast.no...
> > "Dale King" <·····@TCE.com> writes:
> >
> > > "Donald Fisk" <················@enterprise.net> wrote in message
> > > ······················@enterprise.net...
> > > > Dale King wrote:
> > > >
> > > > > And he is also wrong about widespread use of Java in embedded
> systems.
> > > Java
> > > > > is widely used in cell phones.
> > > >
> > > > Any particular reason why? What does Java offer for cellphone
> > > > applications that C or C++ doesn't?
> > >
> > >
> > > Primarily write once, run anywhere (WORA). One can write a J2ME
> application
> > > for the cell-phone market and it can run on different phones, from
> different
> > > manufacturers, running on different processors, running different
> operating
> > > systems, without recompiling. Contrast this to the PDA market where
> programs
> > > are different for Palm vs. PocketPC and even within the Windows CE O/S
> you
> > > have different executables for different processors (MIPS vs. SHA-1).
> >
> > Write once, run anywhere is a proven failure in other
> > areas. Is there any reason to think that the situation will be
> > different on mobile equipment?
>
> Is there any reason to think I was making a statement about the success of
> WORA? I wasn't, but I will now in response.
>
> Where has WORA been a proven failure? It certainly hasn't been in the case
> of Java. On the contrary it has been a great success. You can certainly
> write an application in Java that will run on Windoze, Linux, Macintosh,
I stopped reading here -------------------------^^^^^^
KAC
--
Kenny A. Chaffin
http://www.kacweb.com
Custom Programming and Design
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d909eaa@news.tce.com>
"Kenny Chaffin" <·····@kacweb.com> wrote in message
·······························@news.dimensional.com...
> In article <········@news.tce.com>, ·····@TCE.com says...
> > "Raymond Wiker" <·············@fast.no> wrote in message
> > ···················@raw.grenland.fast.no...
> > > "Dale King" <·····@TCE.com> writes:
> >
> > Where has WORA been a proven failure? It certainly hasn't been in the
case
> > of Java. On the contrary it has been a great success. You can certainly
> > write an application in Java that will run on Windoze, Linux, Macintosh,
>
> I stopped reading here -------------------------^^^^^^
What, we can't poke a little fun at Windoze? Is it so sacrosanct that it is
a heresy to joke about the name?
I always spell it that way. I also always say Micro$oft.
--
Dale King
Dale King wrote:
> What, we can't poke a little fun at Windoze? Is it so sacrosanct that it
> is a heresy to joke about the name?
>
> I always spell it that way. I also always say Micro$oft.
It has been misspelled so many times that spelling it correctly is now
considered witty.
Oleg
Dale King <·····@tce.com> scribbled the following
on comp.lang.java.programmer:
> What, we can't poke a little fun at Windoze? Is it so sacrosanct that it is
> a heresy to joke about the name?
> I always spell it that way. I also always say Micro$oft.
How does one actually SAY "Micro$oft"?
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen
Joona I Palaste <·······@cc.helsinki.fi> writes:
> Dale King <·····@tce.com> scribbled the following
> on comp.lang.java.programmer:
> > What, we can't poke a little fun at Windoze? Is it so sacrosanct that it is
> > a heresy to joke about the name?
>
> > I always spell it that way. I also always say Micro$oft.
>
> How does one actually SAY "Micro$oft"?
Monopoly.
Peace,
Petr
From: Aleksandr Skobelev
Subject: Re: becoming a better programmer
Date:
Message-ID: <m3elbi4k74.fsf@list.ru>
Joona I Palaste <·······@cc.helsinki.fi> writes:
> How does one actually SAY "Micro$oft"?
MegaSucks
"Dale King" <·····@TCE.com> wrote:
> Primarily write once, run anywhere (WORA).
That's the theory. In practice, it's usually more like WODA (Write
Once, Debug Everywhere).
Roy Smith wrote ...
> "Dale King" <·····@TCE.com> wrote:
> > Primarily write once, run anywhere (WORA).
>
> That's the theory. In practice, it's usually more like WODA (Write
> Once, Debug Everywhere).
I agree that the above comment sounded kinda neat the first time I heard
it... but that doesn't make it accurate. At the place I work, we've been
developing a web application on Windows, and deploying on various UNIX
flavors, for some time. During the approximately two-year span where
this has been the case, we haven't had *one* bug relating to the fact
that all our development and testing has been done on Windows, and all
our production deployment has happened on UNIX. Not one problem with
this.
Imagine that in C, C++, Perl, BASIC, Pascal, or any of dozens of other
languages that are portable "if you do everything right."
Chris Smith
"Chris Smith" <·······@twu.net> wrote in message ·······························@news.altopia.com...
> Roy Smith wrote ...
> > "Dale King" <·····@TCE.com> wrote:
> > > Primarily write once, run anywhere (WORA).
> >
> > That's the theory. In practice, it's usually more like WODA (Write
> > Once, Debug Everywhere).
>
> I agree that the above comment sounded kinda neat the first time I heard
> it... but that doesn't make it accurate. At the place I work, we've been
> developing a web application on Windows, and deploying on various UNIX
> flavors, for some time. During the approximately two-year span where
> this has been the case, we haven't had *one* bug relating to the fact
> that all our development and testing has been done on Windows, and all
> our production deployment has happened on UNIX. Not one problem with
> this.
>
> Imagine that in C, C++, Perl, BASIC, Pascal, or any of dozens of other
> languages that are portable "if you do everything right."
I'll second that. I've been developing Java code for about six years, and much
of that time has been spent developing on Windows and deploying on Unix.
I can recall one "bug" in that time that didn't show up on Windows, but did
on Solaris. I had this one dialog that had been laid out in absolute pixel
units instead of using a layout manager. (Hey, I was still new to Java.) The
height of text labels worked for Windows, but it was too short for Solaris,
so the text got clipped.
Rewrote it with a layout manager and all was well.
I can't really recall any other portability issues since then... Pretty well makes
your jaw drop the first time you take a program that's tens or hundreds of KLOC,
copy the *compiled form* from one platform to another completely different
one and run it and it just works, GUI, network, and all.
Marshall
Dale King wrote:
>
> "Donald Fisk" <················@enterprise.net> wrote in message
> ······················@enterprise.net...
> > Dale King wrote:
> >
> > > And he is also wrong about widespread use of Java in embedded systems.
> Java
> > > is widely used in cell phones.
> >
> > Any particular reason why? What does Java offer for cellphone
> > applications that C or C++ doesn't?
>
> Primarily write once, run anywhere (WORA).
This is not a unique characteristic of Java. As I've
pointed out, I was working on a similar interpreter for
COBOL back in 1982. It also means you need to write a
separate interpreter for each platform. You might as
well write a separate compiler for each platform, and
use a standardized language, such as Ansi C or Ansi
Common Lisp.
WORA is a myth anyway -- I wrote a Java program on Windows
95, and had to rewrite large parts of it to get it to run
on Linux. Later, I had trouble with threads (on Linux).
Initially I blamed myself, but I fould out that another
application, with significant similarities to mine (a PDP-1
Emulator for running Spacewar) runs on Windows NT but not
on Linux. My Java program seems to run better on Windows
too.
> Dale King
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d8f9830$1@news.tce.com>
"Donald Fisk" <················@enterprise.net> wrote in message
······················@enterprise.net...
> Dale King wrote:
> >
> > "Donald Fisk" <················@enterprise.net> wrote in message
> > ······················@enterprise.net...
> > > Dale King wrote:
> > >
> > > > And he is also wrong about widespread use of Java in embedded
systems.
> > Java
> > > > is widely used in cell phones.
> > >
> > > Any particular reason why? What does Java offer for cellphone
> > > applications that C or C++ doesn't?
> >
> > Primarily write once, run anywhere (WORA).
>
> This is not a unique characteristic of Java.
Nor did I say it was.
> As I've
> pointed out, I was working on a similar interpreter for
> COBOL back in 1982. It also means you need to write a
> separate interpreter for each platform. You might as
> well write a separate compiler for each platform, and
> use a standardized language, such as Ansi C or Ansi
> Common Lisp.
One certainly could do it in another language, but such a thing doesn't
generally exist, which is why Java is chosen.
> WORA is a myth anyway -- I wrote a Java program on Windows
> 95, and had to rewrite large parts of it to get it to run
> on Linux.
Since you got it to run on Linux, that proves that WORA is not a myth. All
you have shown is that it takes work sometimes.
> Later, I had trouble with threads (on Linux).
> Initially I blamed myself, but I fould out that another
> application, with significant similarities to mine (a PDP-1
> Emulator for running Spacewar) runs on Windows NT but not
> on Linux. My Java program seems to run better on Windows
> too.
Which once again does not disprove WORA.
--
Dale King
From: Ron Natalie
Subject: Re: becoming a better programmer
Date:
Message-ID: <0vMj9.8847$lk.6805@fe05>
> > WORA is a myth anyway -- I wrote a Java program on Windows
> > 95, and had to rewrite large parts of it to get it to run
> > on Linux.
>
> Since you got it to run on Linux, that proves that WORA is not a myth. All
> you have shown is that it takes work sometimes.
Huh? By that reasoning C++ fits your definition of WORA. Hell, I don't even
need a C++ compiler because with a little work I could rewrite it in C.
Dale King wrote:
>
> "Donald Fisk" <················@enterprise.net> wrote in message
> ······················@enterprise.net...
> > WORA is a myth anyway -- I wrote a Java program on Windows
> > 95, and had to rewrite large parts of it to get it to run
> > on Linux.
>
> Since you got it to run on Linux, that proves that WORA is not a myth. All
> you have shown is that it takes work sometimes.
I wrote parts of it twice, once for Windows '95 and
again for Linux. The Linux version ran on Windows,
which was lucky.
My understanding of WORA, before you were so kind to
point this out, was that ALL 100% Java programs are
supposed to run in the same way on all platforms that
support Java. How naive of me.
The problem I have with this is that the behaviour
differences between platforms, and how to go about
fixing the incompatibility, is undocumented. Nor was
there any way of looking at my code and saying "the
version refactored on Linux is correct, and the Windows
version is wrong". Both versions compiled, and both
accurately what I wanted my program to do. Only one
worked on Linux.
With C I don't have that problem. I know that if
I stick to ANSI C it's either portable or I can blame
the compiler writer, and if I use platform dependent
extensions I know I need to make changes when porting,
and the changes I need to make are documented.
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
"Donald Fisk" <················@enterprise.net> wrote in message
······················@enterprise.net...
> Dale King wrote:
> >
>
> My understanding of WORA, before you were so kind to
> point this out, was that ALL 100% Java programs are
> supposed to run in the same way on all platforms that
> support Java. How naive of me.
>
> The problem I have with this is that the behaviour
> differences between platforms, and how to go about
> fixing the incompatibility, is undocumented.
The documentation is improving. Incompatibilities are slowly either being
eliminated or documented.
> With C I don't have that problem. I know that if
> I stick to ANSI C it's either portable or I can blame
> the compiler writer, and if I use platform dependent
> extensions I know I need to make changes when porting,
> and the changes I need to make are documented.
How much can you do before you need to use something platform specific? It
seems to me that you can do a lot more in Java without running into this
problem. Of course it helps if you are aware of differences in file systems
and the like. You also have to be very careful with threads --- Java has
been careful not to over specify thread behaviour. This leads some to assume
that just because something always works on their single processor Windows
box, that it will also work on a dual processor or on Linux.
Mark Thornton
Mark Thornton wrote:
> How much can you do before you need to use something platform specific? It
> seems to me that you can do a lot more in Java without running into this
> problem. Of course it helps if you are aware of differences in file systems
> and the like.
Most of the code was portable. The code that wasn't
involved dragging something with the mouse from one window to
another. While I'd expect the implementation of graphics to
differ markedly between systems, I'd also expect the interface
to be the same wherever possible, and any unavoidable
differences to be documented. This was not the case. I
had to replace an elegant algorithm with an inelegant one
before it worked on Linux.
As for differences in file systems, perhaps these can be
mitigated with a mechanism similar to Common Lisp's logical
pathnames.
> You also have to be very careful with threads --- Java has
> been careful not to over specify thread behaviour. This leads some to assume
> that just because something always works on their single processor Windows
> box, that it will also work on a dual processor or on Linux.
Java threads don't appear to work properly on Linux.
I was told by my lo cal Java wizard that this was a
Linux problem rather than a Java problem. Again, I'd
expect any differences to be documented as long as they
exist, and an alternative implementation of Java threads
on Linux to be implemented.
> Mark Thornton
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
From: Aleksandr Skobelev
Subject: Re: becoming a better programmer
Date:
Message-ID: <m38z1q4jio.fsf@list.ru>
Donald Fisk <················@enterprise.net> writes:
>
> Java threads don't appear to work properly on Linux.
> I was told by my lo cal Java wizard that this was a
> Linux problem rather than a Java problem.
Could you elaborate on details concerning this `Linux problem' with
threads in Java? The only problem I know is problem with mixing signals
and threads. But, I think, it must not be a problem in Java, because
there is not a notion of signals. Am I wrong?
Aleksandr Skobelev wrote:
> Could you elaborate on details concerning this `Linux problem' with
> threads in Java? The only problem I know is problem with mixing signals
> and threads. But, I think, it must not be a problem in Java, because
> there is not a notion of signals. Am I wrong?
Well....
I do know that they show up in ps as separate processes, so that confuses
a lot of people. :-)
--
Jon A. Cruz
What's this? It's almost as though the fates were tempting me to...
Bad fates. Baaad... Naughty fates...
Aleksandr Skobelev wrote:
> Donald Fisk <················@enterprise.net> writes:
>
>>
>> Java threads don't appear to work properly on Linux.
>> I was told by my lo cal Java wizard that this was a
>> Linux problem rather than a Java problem.
>
> Could you elaborate on details concerning this `Linux
> problem' with threads in Java? The only problem I know is
> problem with mixing signals and threads. But, I think, it
> must not be a problem in Java, because there is not a
> notion of signals. Am I wrong?
There has been some work lately to improve the threading
mechanism in Linux. According to this the latest kernel
handles threads very well.
http://developers.slashdot.org/article.pl?sid=02/09/21/2024247&mode=nested&tid=106
--
Jens Axel S�gaard
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d909fa3@news.tce.com>
"Donald Fisk" <················@enterprise.net> wrote in message
······················@enterprise.net...
> Dale King wrote:
> >
> > "Donald Fisk" <················@enterprise.net> wrote in message
> > ······················@enterprise.net...
>
> > > WORA is a myth anyway -- I wrote a Java program on Windows
> > > 95, and had to rewrite large parts of it to get it to run
> > > on Linux.
> >
> > Since you got it to run on Linux, that proves that WORA is not a myth.
All
> > you have shown is that it takes work sometimes.
>
> I wrote parts of it twice, once for Windows '95 and
> again for Linux. The Linux version ran on Windows,
> which was lucky.
>
> My understanding of WORA, before you were so kind to
> point this out, was that ALL 100% Java programs are
> supposed to run in the same way on all platforms that
> support Java. How naive of me.
To the level that the behavior is specifed that is true, although you still
have to compensate for differences among platforms.
> With C I don't have that problem. I know that if
> I stick to ANSI C it's either portable or I can blame
> the compiler writer, and if I use platform dependent
> extensions I know I need to make changes when porting,
> and the changes I need to make are documented.
If you stick to the same level of functionality you get with just ANSI C you
will not have any problems with Java either. There is very little of any
significance that can be done in pure ANSI C.
--
Dale King
>>>>> "DF" == Donald Fisk <················@enterprise.net> writes:
DF> With C I don't have that problem. I know that if I stick to
DF> ANSI C it's either portable or I can blame the compiler
DF> writer, and if I use platform dependent extensions I know I
DF> need to make changes when porting, and the changes I need to
DF> make are documented.
Well, in Java you can do the same thing -- if you stick to standard
Java, it's either portable, or you can blame the JVM author.
I think the principal difference is that the standard Java libraries
are much bigger than the standard C libraries, and certain companies
don't see any advantage in adhering to the standard in the first place
-- which means that other companies' attempts at sticking to the
standard are undermined.
Charlton
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d90ccf6@news.tce.com>
"Charlton Wilbur" <·······@mithril.chromatico.net> wrote in message
···················@mithril.chromatico.net...
> >>>>> "DF" == Donald Fisk <················@enterprise.net> writes:
>
> DF> With C I don't have that problem. I know that if I stick to
> DF> ANSI C it's either portable or I can blame the compiler
> DF> writer, and if I use platform dependent extensions I know I
> DF> need to make changes when porting, and the changes I need to
> DF> make are documented.
>
> Well, in Java you can do the same thing -- if you stick to standard
> Java, it's either portable, or you can blame the JVM author.
>
> I think the principal difference is that the standard Java libraries
> are much bigger than the standard C libraries, and certain companies
> don't see any advantage in adhering to the standard in the first place
> -- which means that other companies' attempts at sticking to the
> standard are undermined.
There are also areas that are underspecified like threading. Java specifies
very little about threading except that threads are supported. An JVM does
not have to support pre-emptive threads and does not even have to honor
thread priorities. So there is room for incompatibilities.
--
Dale King
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3n0qcjrhg.fsf@cley.com>
* Donald Fisk wrote:
> Any particular reason why? What does Java offer for cellphone
> applications that C or C++ doesn't?
I should think having a standard library is a big part (the Nokia
phones at least use J2ME), and safety: if the downloaded app crashes
it doesn't chase a wild pointer and take the phone with it, possibly
smashing lots of non-volatile data like stored numbers in the
process. Of course you could get safety for C/C++ either by using HW
protection (possibly unlikely in the kind of OS that phones run) or by
running them in a virtual machine too (which kind of defeats the
point).
--tim
From: Christopher C. Stacy
Subject: Re: becoming a better programmer
Date:
Message-ID: <ulm5wiav5.fsf@dtpq.com>
>>>>> On 20 Sep 2002 22:11:55 +0100, Tim Bradshaw ("Tim") writes:
Tim> * Donald Fisk wrote:
>> Any particular reason why? What does Java offer for cellphone
>> applications that C or C++ doesn't?
Tim> I should think having a standard library is a big part (the Nokia
Tim> phones at least use J2ME), and safety: if the downloaded app crashes
Tim> it doesn't chase a wild pointer and take the phone with it, possibly
Tim> smashing lots of non-volatile data like stored numbers in the
Tim> process. Of course you could get safety for C/C++ either by using HW
Tim> protection (possibly unlikely in the kind of OS that phones run) or by
Tim> running them in a virtual machine too (which kind of defeats the
Tim> point).
My Kyocera phone (which still says Qualcomm on it, as well) crashes
from time to time. It's hard to reproduce, but happens due to some
interaction between the power-off sequence and the charging sequence.
The phone will either totally lock up, requiring the removal of all
power supply; or sometimes it gives me a programmer's error message
(that a user should never see) involving the word "stack" and some hex
numbers. Been a while since it happened, so I forget the exact wording.
Dunno what language it's programmed in.
Donald Fisk <················@enterprise.net> writes:
> Any particular reason why? What does Java offer for cellphone
> applications that C or C++ doesn't?
In the phones I've programmed Java offers mainly ease of use. The
Symbian OS for example has a C++ API which is quite complex and has a
large learning curve. Anyone who knows Java can pretty much code an
application immediately though.
The problems with Java (on Symbian) is its large memory usage. On the
Nokia 9210 a Personal Java application will take up most of the memory
of the phone leaving little for the user to run other applications.
A C++ application tends to run in smaller memory or at least have its
memory requirements 'tunable'. I use Forth which also has a small
memory footprint. I'd be interested in how a Common Lisp would fit in
since I'd much prefer using that on a phone.
J2ME changes things a little since it tends to have a small memory
footprint too. In return there is not a great deal you can do with it
using 'standard' J2ME without venturing into vendor specific
API's. Then you're stuck again being limited to a small set of phones.
Chris.
--
http://www.double.co.nz
"Thomas F. Burdick" wrote:
>
> Donald Fisk <················@enterprise.net> writes:
>
> > You might want to read "Java's Cover" on www.paulgraham.com, which
> > states the reasons why its author has avoided Java.
> > An interesting point not mentioned by Paul Graham but which adds
> > weight to his argument, is that Java was originally designed to
> > run in embedded devices, then in web browsers, and now on servers.
> > I don't know of any widespread use of devices with embedded Java,
> > most people browse the web with Java switched off (to be fair,
> > there are some interesting applets out there, but they are few and
> > far between), and you can write server software in any language
> > so there's no reason to use Java. I was expecting until very
> > recently that it would gradually become extinct over the next five
> > years, but it seems to have an even worse fate in store -- as a
> > replacement for Cobol. So there's still money to be made out
> > of it, but a career in accountancy seems the more interesting
> > option.
>
> You're absolutely wrong that most people browse the web with Java
> turned off.
OK, I stand corrected. But I wonder whether, if Java turned off were
the default, how many would choose to switch Java on.
> And while it's true that I can generally use whatever language I want
> on a server, I sometimes use Java because it can be easier to use the
> same language on both the front and back ends. When I don't get any
> particular benefit from that homogeneity, I don't hesitate to write
> the backend in Lisp, but there can be a definate benefit to using Java
> on the server -- entirely because all web browsers have JVMs built in.
I'm puzzled about why that should make a difference.
> Why do you use Python instead of Lisp? I don't particularly like
> Perl, but I can live with it, and I use it when it's practical -- and
> it's often practical because it's a widely-accepted Unix
> scripting/small-app language. I wouldn't consider Python, because
> it's not reasonable to assume that it's on a typical Unix server, or
> that another developer knows it. With those benefits gone, I'll
> choose Lisp 6.5 days of the week (the other 12 hours, I'll use
> Smalltalk ;)
I don't use Python. I do almost all my programming in C
and Lisp. It's been recommended to me as an alternative
to Perl, in case I needed that.
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
On Thu, 19 Sep 2002 19:57:12 +0100, ················@enterprise.net
said:
>
[snip]
>
> most people browse the web with Java switched off
Seems like 350 million people would disagree:
http://www.thecounter.com/stats/2002/August/java.php
87% have java enabled with 11% unknown whether it's enabled or disabled.
On Sep 20, Brian Palmer inscribed on the eternal scroll:
> On Thu, 19 Sep 2002 19:57:12 +0100, ················@enterprise.net
> said:
> >
> > most people browse the web with Java switched off
>
> Seems like 350 million people would disagree:
>
> http://www.thecounter.com/stats/2002/August/java.php
>
> 87% have java enabled
One could still make a comfortable living, even if one's only
customers were selected from the discerning ~ 40-45Million who didn't.
"Donald Fisk" <················@enterprise.net> wrote in message ······················@enterprise.net...
> Alec wrote:
> >
> > "John W. Krahn" <······@acm.org> wrote in message news:<·················@acm.org>...
> > > Alec wrote:
> > > >
> > > > As someone correctly mentioned you should certainly stay from hype
> > > > languages like Java, Perl, etc.
> > >
> > > Excuse me, I don't want to start a flame war but, under what definition
> > > of hype are you using to define Perl?
> >
> > When I say "hype" languages, I am not merely referring to languages
> > that are popular, but those that are at the same time mediocre or bad.
> > For them, popularity comes from aggressive marketing, etc. In case of
> > Java, it was Sun's desire to take a bite of Microsoft's market
The idea that Sun's wanting to gain market share from Microsoft makes
Java technically flawed does not follow logically.
> You might want to read "Java's Cover" on www.paulgraham.com, which
> states the reasons why its author has avoided Java.
Indeed. I found this part of his analysis particularly telling: "I've never written
a Java program, never more than glanced over reference books about it, but
I have a hunch that it won't be a very successful language." The fact that,
measured by the height and steepness of its adoption curve, Java is the
most successful programming language in the history of computation
makes even more ironic what would otherwise be an uninformed opinion
piece by an elitist who admittedly never even wrote anything in the language
in question.
> An interesting point not mentioned by Paul Graham but which adds
> weight to his argument, is that Java was originally designed to
> run in embedded devices, then in web browsers, and now on servers.
By that line of thought, we should consider C as useless because it
was designed to run on the PDP-11. I shudder to think what that
kind of thinking would lead us to say about Lisp. But I again consider
that this does not follow logically.
> I don't know of any widespread use of devices with embedded Java,
> most people browse the web with Java switched off
Well, wrong and wrong, as others have pointed out.
> (to be fair,
> there are some interesting applets out there, but they are few and
> far between),
Applets represent approximately 0% of what is interesting about Java.
It is true that back in 1996, people talked about Java applets a lot, but
they really didn't go anywhere. I've been working as a professional
Java programmer for ~6 years now, and no one's ever asked me to
write an applet.
> and you can write server software in any language
> so there's no reason to use Java.
Except for the fact that it makes a great language for writing server
code in.
> I was expecting until very
> recently that it would gradually become extinct over the next five
> years, but it seems to have an even worse fate in store -- as a
> replacement for Cobol.
I too predicted Java's swift demise, until I started working with it a lot.
> So there's still money to be made out
> of it, but a career in accountancy seems the more interesting
> option.
It's a free country.
> RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
> drugs,
> sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
> LSD.
With all respect due Lisp (which is a lot,) I went to Berkeley back when,
and it was all C and Fortran. And again with respect to Lisp, but it has
a *terrible* name. Imagine naming a language after a speech impediment!
> Java evokes a vision of a stereotypical nerd, with no life or social
> skills.
"Java" evokes visions of coffee.
Marshall
* Marshall Spight
| And again with respect to Lisp, but it has a *terrible* name. Imagine
| naming a language after a speech impediment!
It may not be as good as naming it after an island or a coffee brand, but
seriously, if you would react negatively to (Common) Lisp because of its
name, or if you have heard about others who have rejected it before looking
at it because of its name, or have ignored it because it did not look like a
programming language, I would be very interested to hear about actual cases.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
>
> * Marshall Spight
> | And again with respect to Lisp, but it has a *terrible* name. Imagine
> | naming a language after a speech impediment!
>
> It may not be as good as naming it after an island or a coffee brand, but
> seriously, if you would react negatively to (Common) Lisp because of its
> name, or if you have heard about others who have rejected it before looking
> at it because of its name, or have ignored it because it did not look like a
> programming language, I would be very interested to hear about actual cases.
There's a small village near Lier in Belgium called Lisp.
It has its own football team. You could claim, somewhat
facetiously, that it's named after that.
> Erik Naggum, Oslo, Norway
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Donald Fisk <················@enterprise.net> writes:
> There's a small village near Lier in Belgium called Lisp.
> It has its own football team. You could claim, somewhat
> facetiously, that it's named after that.
Actually, Lisp is the name of the football stadium, not of a
village. And the city it lies in is Lierse, not Lier.
--
Hai koe, zei de stier,
Kom mee met mij in de wei,
Dan zijn we tweezaam.
Lieven Marchand <···@wyrd.be>
Lieven Marchand wrote:
>
> Donald Fisk <················@enterprise.net> writes:
>
> > There's a small village near Lier in Belgium called Lisp.
> > It has its own football team. You could claim, somewhat
> > facetiously, that it's named after that.
>
> Actually, Lisp is the name of the football stadium, not of a
> village. And the city it lies in is Lierse, not Lier.
On the map I have in front of me (published by Michelin),
there's a town called Lier/Lierre about 15 km south east of
Antwerpen/Anvers. Due north of this, is a village called
Lisp. For all I know it's, a copyright trap but a Flemish
]friend told me about it he used the word "neighbourhood"
rather than village).
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Donald Fisk <················@enterprise.net> scribbled the following
on comp.lang.java.programmer:
> Erik Naggum wrote:
>> * Marshall Spight
>> | And again with respect to Lisp, but it has a *terrible* name. Imagine
>> | naming a language after a speech impediment!
>>
>> It may not be as good as naming it after an island or a coffee brand, but
>> seriously, if you would react negatively to (Common) Lisp because of its
>> name, or if you have heard about others who have rejected it before looking
>> at it because of its name, or have ignored it because it did not look like a
>> programming language, I would be very interested to hear about actual cases.
> There's a small village near Lier in Belgium called Lisp.
> It has its own football team. You could claim, somewhat
> facetiously, that it's named after that.
Big deal! There's a whole *island* called Java! It has its own coffee
brand! You could claim, somewhat facetiously, that Java has been named
after that.
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"To know me IS to love me."
- JIPsoft
"Joona I Palaste" <·······@cc.helsinki.fi> az al�bbiakat �rta a k�vetkez�
h�r�zenetben: ············@oravannahka.helsinki.fi...
> Donald Fisk <················@enterprise.net> scribbled the following
> on comp.lang.java.programmer:
> > Erik Naggum wrote:
> >> * Marshall Spight
> >> | And again with respect to Lisp, but it has a *terrible* name.
Imagine
> >> | naming a language after a speech impediment!
> >>
> >> It may not be as good as naming it after an island or a coffee brand,
but
> >> seriously, if you would react negatively to (Common) Lisp because of
its
> >> name, or if you have heard about others who have rejected it before
looking
> >> at it because of its name, or have ignored it because it did not look
like a
> >> programming language, I would be very interested to hear about actual
cases.
>
> > There's a small village near Lier in Belgium called Lisp.
> > It has its own football team. You could claim, somewhat
> > facetiously, that it's named after that.
>
> Big deal! There's a whole *island* called Java! It has its own coffee
> brand! You could claim, somewhat facetiously, that Java has been named
> after that.
Could you take your off-topic garbage out of clc++? I have already ignored
the thread, then you start a new one. Worship Java in the nearest church
which allows it...
--�
WW aka Attila
ICQ#: 26070936
Marshall Spight wrote:
>
> "Donald Fisk" <················@enterprise.net> wrote in message ······················@enterprise.net...
> > Alec wrote:
> > >
> > > "John W. Krahn" <······@acm.org> wrote in message news:<·················@acm.org>...
> > > > Alec wrote:
> > > > >
> > > > > As someone correctly mentioned you should certainly stay from hype
> > > > > languages like Java, Perl, etc.
> > > >
> > > > Excuse me, I don't want to start a flame war but, under what definition
> > > > of hype are you using to define Perl?
> > >
> > > When I say "hype" languages, I am not merely referring to languages
> > > that are popular, but those that are at the same time mediocre or bad.
> > > For them, popularity comes from aggressive marketing, etc. In case of
> > > Java, it was Sun's desire to take a bite of Microsoft's market
>
> The idea that Sun's wanting to gain market share from Microsoft makes
> Java technically flawed does not follow logically.
>
> > You might want to read "Java's Cover" on www.paulgraham.com, which
> > states the reasons why its author has avoided Java.
>
> Indeed. I found this part of his analysis particularly telling: "I've never written
> a Java program, never more than glanced over reference books about it, but
> I have a hunch that it won't be a very successful language." The fact that,
> measured by the height and steepness of its adoption curve, Java is the
> most successful programming language in the history of computation
> makes even more ironic what would otherwise be an uninformed opinion
> piece by an elitist who admittedly never even wrote anything in the language
> in question.
I'm unclear what you mean by success. I presume you mean
"numbers of people who are told they have to write their code
in Java". The other successful language measured by that
criterion is Cobol.
> > An interesting point not mentioned by Paul Graham but which adds
> > weight to his argument, is that Java was originally designed to
> > run in embedded devices, then in web browsers, and now on servers.
>
> By that line of thought, we should consider C as useless because it
> was designed to run on the PDP-11.
PDP-7. Close enough though. C suceeded on it, and Unix is the
proof. Had Java been as widely used on embedded devices as its
developers hoped, and then expanded into some other area, your
point would seem less pedantic. But its use in mobile phones
postdates its other uses -- certainly in the summer of 1998, well
after Java was released, there was only ONE embedded device with
Java (source: one of the presenters at an international conference
I attended, in a workshop devoted to Java).
> I shudder to think what that
> kind of thinking would lead us to say about Lisp. But I again consider
> that this does not follow logically.
It's one of only two languages you can write AI programs in (unless
you want to prove Philip Greenspun correct for the Nth time),
and it's been used in other areas: to write text editors, operating
systems, computer games, web sites, etc. It's not hugely popular
but then good things seldom are.
> > I don't know of any widespread use of devices with embedded Java,
> > most people browse the web with Java switched off
>
> Well, wrong and wrong, as others have pointed out.
OK, so I was wrong. (though it took several years before it
was used in GSMs).
> > (to be fair,
> > there are some interesting applets out there, but they are few and
> > far between),
>
> Applets represent approximately 0% of what is interesting about Java.
They're Java's only significant innovation. Everything else
about Java is derivative of other languages, mostly Smalltalk and
C/C++, with a piece here and there from Lisp (garbage collection,
bignums, catch and throw).
> It is true that back in 1996, people talked about Java applets a lot, but
> they really didn't go anywhere. I've been working as a professional
> Java programmer for ~6 years now, and no one's ever asked me to
> write an applet.
>
> > and you can write server software in any language
> > so there's no reason to use Java.
>
> Except for the fact that it makes a great language for writing server
> code in.
Java Server Pages? Putting HTML and Java in the same file
is an obvious case of bad design. You have to make a cognitive
switch every time the code changes from one to the other, indenting
the code correctly becomes a nightmare, etc.
> > I was expecting until very
> > recently that it would gradually become extinct over the next five
> > years, but it seems to have an even worse fate in store -- as a
> > replacement for Cobol.
>
> I too predicted Java's swift demise, until I started working with it a lot.
I think its demise will be slow, like Cobol's. I think that the
hype surrounding it has done serious damage, possibly irreparable,
to the software industry. And I think that its popularity, and
popularity in general, has nothing to do with quality.
> > So there's still money to be made out
> > of it, but a career in accountancy seems the more interesting
> > option.
>
> It's a free country.
I suppose it's a matter of taste. Applications programming
doesn't do much for me. I much prefer systems programming,
writing algorithms, that sort of thing.
> > Java evokes a vision of a stereotypical nerd, with no life or social
> > skills.
>
> "Java" evokes visions of coffee.
Which in turn evokes visions of agressive yuppies, a point made
in later in the exchange. My .sigs are mostly there to offend
people who are easily offended, and occasionally to amuse.
> Marshall
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Also sprach Donald Fisk:
> Marshall Spight wrote:
>> I shudder to think what that
>> kind of thinking would lead us to say about Lisp. But I again consider
>> that this does not follow logically.
>
> It's one of only two languages you can write AI programs in (unless
> you want to prove Philip Greenspun correct for the Nth time),
> and it's been used in other areas: to write text editors, operating
> systems, computer games, web sites, etc. It's not hugely popular
> but then good things seldom are.
What an odd statement!
The term 'artificial intelligence' has been a misunderstanding on from
the very beginning. Intelligence is the ability to draw certain
conclusions based on...incidents, to put it just very generally. As long
as these 'incidents' can be foreseen and restricted to a number of cases
that can be dealt with, all is fine. As far as that is concerned, we are
back in the domain of ordinary programming which consists of setting up
some data (in a computer-readable format) and have some algorithms (in a
computer-understandable and executable format) work on them. Obviously,
this can be done in any Turing-complete language. Just for the fact that
Lisp has some nifty techniques to work with lists and basically create
self-modifying programs (since those are lists, too) doesn't
automatically make it one of two languages exclusive in the fields of
'AI' (I suppose the other one you were thinking of was Prolog, as
conventionally mentioned in this context).
It is unfortunate, though, that actual intelligence is largely based on
feelings and nuances in reasoning that is unique to human beings. Is
Lisp any better in that than Java, C, Perl, Erlang or whatever? A
rhetorical question of course: Neither of those is even theoretically
applicable when it comes to that.
[ pointless advocacy snipped ]
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3it10jrc5.fsf@cley.com>
* Donald Fisk wrote:
> They're Java's only significant innovation. Everything else
> about Java is derivative of other languages, mostly Smalltalk and
> C/C++, with a piece here and there from Lisp (garbage collection,
> bignums, catch and throw).
Well, so what? Is innovation more important than being a standard,
and some good? What was innovative about Common Lisp?
--tim
Tim Bradshaw wrote:
>
> * Donald Fisk wrote:
>
> > They're Java's only significant innovation. Everything else
> > about Java is derivative of other languages, mostly Smalltalk and
> > C/C++, with a piece here and there from Lisp (garbage collection,
> > bignums, catch and throw).
>
> Well, so what? Is innovation more important than being a standard,
> and some good? What was innovative about Common Lisp?
So, why aren't you programming in Portable Standard Lisp?
It depends what you want. Common Lisp was an amalgam of
various dialects -- Maclisp, Interlisp, Scheme, etc.
Standardization is important for interoperability -- if
you buy a Lisp system for running your existing Common Lisp
code on, you'll be annoyed if it isn't compliant with the
standard, just as you'll be annoyed if your plug doesn't
fit, your coin is rejected by the vending machine.
But if you want to develop a /better/ Lisp for any reason,
you'll have to break the standard -- because better implies
different. Alternatively you could be patient and wait
years for your proposal to be adopted by a committee.
Without change, there can be no progress, and no ability to
adapt to changes in the future.
(I note that it's going to other newsgroups, but the
most of the above arguments apply, mutatis mutandis, to C++,
Java and Perl.)
> --tim
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3ptv6j28l.fsf@cley.com>
* Donald Fisk wrote:
> So, why aren't you programming in Portable Standard Lisp?
Well, I used to.
> It depends what you want. Common Lisp was an amalgam of
> various dialects -- Maclisp, Interlisp, Scheme, etc.
> Standardization is important for interoperability -- if
> you buy a Lisp system for running your existing Common Lisp
> code on, you'll be annoyed if it isn't compliant with the
> standard, just as you'll be annoyed if your plug doesn't
> fit, your coin is rejected by the vending machine.
yes, and maybe that's what CL and Java are aiming at. It doesn't have
to be innovative to be useful, and it annoys me that people from the
Lisp community will hark on at Java for not being innovative while CL
is not really any more so - almost anything that's in CL started
somewhere else, the same way almost anything that's in Java started
somewhere else. Does this make either language worthless? Not in my
opinion.
--tim
From: Dale King
Subject: Re: becoming a better programmer
Date:
Message-ID: <3d8f9830$2@news.tce.com>
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * Donald Fisk wrote:
>
> > They're Java's only significant innovation. Everything else
> > about Java is derivative of other languages, mostly Smalltalk and
> > C/C++, with a piece here and there from Lisp (garbage collection,
> > bignums, catch and throw).
I thought that was the definition of innovation as promoted by Micro$oft.
--
Dale King
On Fri, 20 Sep 2002 19:34:13 +0100, Donald Fisk <················@enterprise.net>
wrote:
>They're Java's only significant innovation. Everything else
>about Java is derivative of other languages, mostly Smalltalk and
>C/C++, with a piece here and there from Lisp (garbage collection,
>bignums, catch and throw).
This kind of inheritance is true of any language, or even any idea.
But considering the most direct inheritance I think it would be more
fruitful to consider Java as early Eiffel with C-inspired syntax,
less consistency, and the idea of running on a virtual machine (Eiffel
instead was intended to be compiled down to C). The match is near
100%. The match to Smalltalk, C/C++, Lisp etc., is at best construed.
Uhm, perhaps I can learn something here: is it the case that Lisp
introduced the throw-and-catch style of exception handling, e.g. before
Ada? Must point out that the question implies nothing, esp. not that
Lisp has or doesn't have that style of exception handling.
Cheers,
- Alf
···············@yahoo.no.invalid (Alf P. Steinbach) writes:
> Uhm, perhaps I can learn something here: is it the case that Lisp
> introduced the throw-and-catch style of exception handling, e.g. before
> Ada?
afaik, maclisp had throw/catch in the early seventies, when ADA was
still in planning.
--
(espen)
Espen Vestre wrote:
> afaik, maclisp had throw/catch in the early seventies, when ADA was
> still in planning.
T
> (espen)
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
After takin a swig o' grog, ···············@yahoo.no.invalid (Alf P. Steinbach) belched out...:
> On Fri, 20 Sep 2002 19:34:13 +0100, Donald Fisk <················@enterprise.net>
> wrote:
>>They're Java's only significant innovation. Everything else
>>about Java is derivative of other languages, mostly Smalltalk and
>>C/C++, with a piece here and there from Lisp (garbage collection,
>>bignums, catch and throw).
>
> This kind of inheritance is true of any language, or even any idea.
>
> But considering the most direct inheritance I think it would be more
> fruitful to consider Java as early Eiffel with C-inspired syntax,
> less consistency, and the idea of running on a virtual machine
> (Eiffel instead was intended to be compiled down to C). The match
> is near 100%. The match to Smalltalk, C/C++, Lisp etc., is at best
> construed.
Interesting thought.
I'd agree that any link to Smalltalk is, at best, construed.
But we /know/ that Gosling and Steele were familiar with Lisp and with
C, so it is reasonable to expect a design with awareness of those
languages. Do we know that they were highly familiar with Eiffel?
> Uhm, perhaps I can learn something here: is it the case that Lisp
> introduced the throw-and-catch style of exception handling, e.g. before
> Ada? Must point out that the question implies nothing, esp. not that
> Lisp has or doesn't have that style of exception handling.
I indeed believe so. I first saw it in Forth, where those that
introduced it to Forth attributed it as having come from Common Lisp.
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/sgml.html
"I owe the government $3400 in taxes. So I sent them two hammers and
a toilet seat." -- Michael McShane
Donald Fisk <················@enterprise.net> writes:
> Marshall Spight wrote:
> > By that line of thought, we should consider C as useless because
> > it was designed to run on the PDP-11.
> PDP-7.
According to
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
, C started out on the PDP-11. C evolved from the PDP-11
implementation of B, and B in turn was first implemented on the PDP-7.
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
Alec wrote ...
> As someone correctly mentioned you should certainly stay from hype
> languages like Java, Perl, etc. They may make you more employable in
> the short term, but in the long term they will make a crappy
> programmer out of your, and there's no going back: bad habbits die
> hard.
I missed the step in your logic where you demonstrated that if a language
is getting media or popular attention, then it must produce bad habits
for programmers. I find that's far from the case. There are far more
niche languages that encourage poor style and practice. Programmers are
not, on the whole, stupid people. Many times if a language is popular,
it's because a lot of people over a long period of time found it to be a
useful solution to real problems that they have had.
I agree with the more general suggestion to avoid forming bad habits.
Chris Smith
"Alec" <········@ziplip.com> wrote in message
·································@posting.google.com...
> ·············@yahoo.com (Scott) wrote in message
news:<····························@posting.google.com>...
> Many people expected a lot from Lisp, and given your background in
> Scheme, Lisp would seem like a reasonable next step. The industry
> realized over the years that while Lisp makes a fine language for
> certain niche small to medium size projects, it has two serious
> drawbacks: firstly, maintainability issues arise, because Lisp
> programmers can never understand each other's code, and secondly, Lisp
> teaches you bad programming style, as your code is usually a mess of
> if's, conds, and so on. That is why it almost lost its relevance by
> now. I can not say that I'm glad, because a lof of my own expertise is
> wasted. Oh well, that's life.
Many people expect a lot out of C++, and given your background in Scheme, C++
would be seem like a reasonable next step. The industry realized over the
decade that while C++ makes a fine language for certain small to medium size
projects, it has two serious drawbacks: firstly, maintainalbility issues arise,
because C++ programmers can never understand each other's code and class
heiacrchies, and secondly, C++ teaches and encourages one and only one bad
programming style, as your code is usually a mess of if's, for's, function
calls, include files, overloaded operators and so on. That is why it it losing
its relevance. I can say that I'm glad, because I have not wasted a lot of my
expertise on it. Thank God that's life.
>
> I was one of the early adopters when C++ came out (C with classes),
> and I'm still very fond of it. I think the standardization committee
> and Bjarnee have done a wonderful job. C++, of course has its own
> drawbacks, the most important of which being that you must not be a
> half-wit if you want to learn to use it correctly. If you lack in the
> brains department, you can still make a decent living as a programmer
> coding in shite like Java or VB.
>
> So it all depends on your own mental abilities and on your dedication
>
> Good luck!
"Wade Humeniuk" <····@nospam.nowhere> wrote in message news:<·····················@news1.telusplanet.net>...
> "Alec" <········@ziplip.com> wrote in message
> ·································@posting.google.com...
> > ·············@yahoo.com (Scott) wrote in message
> news:<····························@posting.google.com>...
> > Many people expected a lot from Lisp, and given your background in
> > Scheme, Lisp would seem like a reasonable next step. The industry
> > realized over the years that while Lisp makes a fine language for
> > certain niche small to medium size projects, it has two serious
> > drawbacks: firstly, maintainability issues arise, because Lisp
> > programmers can never understand each other's code, and secondly, Lisp
> > teaches you bad programming style, as your code is usually a mess of
> > if's, conds, and so on. That is why it almost lost its relevance by
> > now. I can not say that I'm glad, because a lof of my own expertise is
> > wasted. Oh well, that's life.
>
> Many people expect a lot out of C++, and given your background in Scheme, C++
> would be seem like a reasonable next step. The industry realized over the
> decade that while C++ makes a fine language for certain small to medium size
> projects, it has two serious drawbacks: firstly, maintainalbility issues arise,
> because C++ programmers can never understand each other's code and class
> heiacrchies, and secondly, C++ teaches and encourages one and only one bad
> programming style, as your code is usually a mess of if's, for's, function
> calls, include files, overloaded operators and so on. That is why it it losing
> its relevance. I can say that I'm glad, because I have not wasted a lot of my
> expertise on it. Thank God that's life.
Wade, thanks for attempting to be funny and for sharing with us your
dilettante opinion, of course. Since, as you mentioned yourself, you
have not spent a lot of time on C++, what makes you think you are even
remotely capable of judging it: what exactly have you "learned" about
it? I suspect you are simply repeating whatever FUD you have heard or
read. Do not let slashcrap and similar sources do your thinking for
you.
> >
> > I was one of the early adopters when C++ came out (C with classes),
> > and I'm still very fond of it. I think the standardization committee
> > and Bjarnee have done a wonderful job. C++, of course has its own
> > drawbacks, the most important of which being that you must not be a
> > half-wit if you want to learn to use it correctly. If you lack in the
> > brains department, you can still make a decent living as a programmer
> > coding in shite like Java or VB.
> >
> > So it all depends on your own mental abilities and on your dedication
> >
> > Good luck!
"Alec" <········@ziplip.com> wrote in message
·································@posting.google.com...
> "Wade Humeniuk" <····@nospam.nowhere> wrote in message
news:<·····················@news1.telusplanet.net>...
> Wade, thanks for attempting to be funny and for sharing with us your
> dilettante opinion, of course. Since, as you mentioned yourself, you
> have not spent a lot of time on C++, what makes you think you are even
> remotely capable of judging it: what exactly have you "learned" about
> it? I suspect you are simply repeating whatever FUD you have heard or
> read. Do not let slashcrap and similar sources do your thinking for
> you.
I have 5 years experience with C++. Using one of the very first beta compilers
from DEC. I think the years were from 1993-1998. I do not consider this a lot
of time ( I have been programming since 1977). The largest programming project
I have worked on involved 85 people with the C++ team consisting of 5
programmers (it was experimental at the time).
Mostly what I learned from the language is that programmers using C++ attempt to
force the understanding of the world into the OO paradigm. They also attempt to
use all the OO features of the C++ language (inheritence, multiple inheritence,
overloading) and this just slows down the whole development effort. It also
results in tons of useless code that basically does nothing. All the code that
really implements functionality is bound into a few key functions. Also I have
found that programming teams spend in inordinate amount of time "talking" about
the design and not enough "doing" the work. Its like people feel they are
actually accomplishing something, but one does not truly understand the problem
until one writes the code. In some ways getting the coding (a truly technical
specification) done will facilitate getting the design done.
Here is an article I basically agree with:
http://www.paulgraham.com/noop.html
As with most languages like C/C++/Pascal/Compile-Link-Test-Languages great
amounts of test scafolding (unit testing and intergration testing) programs have
to be written, which in a substantive testing environment, exceeds the actual
code written. For larger and larger projects this can be the kiss of death
since the test code is always more complex than the actual tested code. Much of
the time people also resort to scripting languages to do the testing as the
underlying language is not expressive enough.
I have mostly given them all up to develop in Common Lisp where multiple
programming styles are supported, test code is integrated with the development
environment (the test script language is also in CL) and all in all I am many
times more productive. Unit testing is a snap in CL and integration testing is
in some ways is an expanded form of unit testing.
Wade
"Wade Humeniuk" <····@nospam.nowhere> writes:
> the design and not enough "doing" the work. Its like people feel they are
> actually accomplishing something, but one does not truly understand the problem
> until one writes the code. In some ways getting the coding (a truly technical
> specification) done will facilitate getting the design done.
I reply to this only a a foil to any who would take your statement as
reason to sneer at those who talk with other programmers on their
team, but it is vitally important to not go the other way here, and
not communicate with one another and attempt to let the code do that
work. A balance is needed. Sitting down and talking thru the problem
with others is very helpful in my experience.
--
Sincerely,
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"Craig Brozefsky" <·····@red-bean.com> wrote in message
···················@piracy.red-bean.com...
> "Wade Humeniuk" <····@nospam.nowhere> writes:
>
> > the design and not enough "doing" the work. Its like people feel they are
> > actually accomplishing something, but one does not truly understand the
problem
> > until one writes the code. In some ways getting the coding (a truly
technical
> > specification) done will facilitate getting the design done.
>
> I reply to this only a a foil to any who would take your statement as
> reason to sneer at those who talk with other programmers on their
> team, but it is vitally important to not go the other way here, and
> not communicate with one another and attempt to let the code do that
> work. A balance is needed. Sitting down and talking thru the problem
> with others is very helpful in my experience.
Yes I agree, much of he work getting a software team to work together is to use
a common vocabulary. This vocabulary is what I think OO proponents are aiming
for but the popular methodology of Spec->Design->Code->Integrate that goes along
with it precribes the vocabulary too soon.
Wade
········@ziplip.com (Alec) writes:
> ·············@yahoo.com (Scott) wrote:
>
> Many people expected a lot from Lisp, and given your background in
> Scheme, Lisp would seem like a reasonable next step. The industry
> realized over the years that while Lisp makes a fine language for
> certain niche small to medium size projects, it has two serious
> drawbacks: firstly, maintainability issues arise, because Lisp
> programmers can never understand each other's code, and secondly, Lisp
> teaches you bad programming style, as your code is usually a mess of
> if's, conds, and so on. That is why it almost lost its relevance by
> now. I can not say that I'm glad, because a lof of my own expertise is
> wasted. Oh well, that's life.
>
Could you please be more specific about the maintainability issues and
bad programming style? Perhaps you could give a few examples?
Regards,
Richard
--
Richard Krushelnitskiy "I know not with what weapons World War III will
rkrush (at) gmx.net be fought, but World War IV will be fought with
http://rkrush.cjb.net sticks and stones." -- Albert Einstein
> As someone correctly mentioned you should certainly stay from hype
> languages like Java, Perl, etc. They may make you more employable in
> the short term, but in the long term they will make a crappy
> programmer out of your, and there's no going back: bad habbits die
> hard.
Can you please explain yourself a bit here. Just because Java and Perl
are popular, how will using them make you a bad programmer? Clearly,
this a false statement to begin with - you can be good or bad in any
language. I would just like to know how you arrived at this
conclusion, because it is fasinating how you can damn an entire
language for inflicting bad habits.
Ryan
Alec wrote:
> Many people expected a lot from Lisp, and given your background in
> Scheme, Lisp would seem like a reasonable next step.
People expected a lot from Lisp because of hype associated with
the commercialization of AI in the 1980s.
> The industry
> realized over the years that while Lisp makes a fine language for
> certain niche small to medium size projects, it has two serious
> drawbacks: firstly, maintainability issues arise, because Lisp
> programmers can never understand each other's code, and secondly, Lisp
> teaches you bad programming style, as your code is usually a mess of
> if's, conds, and so on. That is why it almost lost its relevance by
> now. I can not say that I'm glad, because a lof of my own expertise is
> wasted. Oh well, that's life.
This is not my experience. The only trouble I have understanding
other people's Common Lisp is if they're implementing an extremely
complex algorithm. But that's because of the algorithm, not because
of the language, and such algorithms would not even be attempted in
lesser languages.
Also, the Lisp programmers I have known care more about avoiding side
effects, and use global variables less, because they're familiar with
the functional programming style which effectively forbids them.
As for the mess of ifs and conds, could you explain this? All
programming languages have conditional statements or expressions.
At least Lisp forces you to use a decent editor that keeps track
of their nesting.
There is a bogus maintainability issue -- there aren't that many
Lisp programmers, and suits worry if one leaves. But there are even
fewer Lisp jobs, and in any case, people had to learn Java and C#
in the not too distant past, so why shouldn't they be expected
to learn Lisp?
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Donald Fisk wrote in message <·················@enterprise.net>...
>
>As for the mess of ifs and conds, could you explain this? All
>programming languages have conditional statements or expressions.
Perhaps you mean "all procedural programming languages". There are variants
of Prolog that do not have conditional statements or expressions.
Tom.
Tom Beer wrote:
> Donald Fisk wrote in message <·················@enterprise.net>...
>>
>> As for the mess of ifs and conds, could you explain this? All
>> programming languages have conditional statements or expressions.
>
> Perhaps you mean "all procedural programming languages". There are
> variants of Prolog that do not have conditional statements or
> expressions.
I think Donald meant "All programming languages have conditions or other
means of control flow control"
As you mentioned neither statements nor expressions are really necessary
(functional languages don't have statements, assemblers don't necessarily
have expressions)
jue
"Jürgen Exner" wrote:
>
> Tom Beer wrote:
> > Donald Fisk wrote in message <·················@enterprise.net>...
> >>
> >> As for the mess of ifs and conds, could you explain this? All
> >> programming languages have conditional statements or expressions.
> >
> > Perhaps you mean "all procedural programming languages". There are
> > variants of Prolog that do not have conditional statements or
> > expressions.
>
> I think Donald meant "All programming languages have conditions or other
> means of control flow control"
All the ones I'm aware of. But I never set out to make such a
general point -- merely that Lisp's baggage of conditional
expressions is no bigger than C++'s baggage of conditional
statements and expressions.
Prolog was introduced by someone else. But arguing that it lacks
conditionals when every top level expression is one, is on a par
with arguing that Snobol4 lacks a goto.
> jue
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Hello!
J�rgen Exner <········@hotmail.com> wrote:
>[...]
>I think Donald meant "All programming languages have conditions or other
>means of control flow control"
>As you mentioned neither statements nor expressions are really necessary
>(functional languages don't have statements, assemblers don't necessarily
>have expressions)
And, in fact, in purely functional or dataflow languages, there is
no such thing like "control flow" which you can control. But, in some
way, there should usually be conditions like (in an approximately
mathematical way of expression):
ite(c,t,f) = t, when c is true
f, otherwise
Kind regards,
Hannah.
In article <············@merki.connect.com.au>,
"Tom Beer" <········@btfinancialgroup.spamfilter.com> wrote:
> Donald Fisk wrote in message <·················@enterprise.net>...
> >
> >As for the mess of ifs and conds, could you explain this? All
> >programming languages have conditional statements or expressions.
>
> Perhaps you mean "all procedural programming languages". There are variants
> of Prolog that do not have conditional statements or expressions.
!!!!
*Every* Prolog clause is a great big short-circuit nested if statement.
With backtracking (which make it series of nested loops).
-- Bruce
Bruce Hoult wrote:
>
> In article <············@merki.connect.com.au>,
> "Tom Beer" <········@btfinancialgroup.spamfilter.com> wrote:
>
> > Donald Fisk wrote in message <·················@enterprise.net>...
> > >
> > >As for the mess of ifs and conds, could you explain this? All
> > >programming languages have conditional statements or expressions.
> >
> > Perhaps you mean "all procedural programming languages". There are variants
> > of Prolog that do not have conditional statements or expressions.
>
> !!!!
I think you mean :-
If a language lacks Horn clauses (syntactically indicated
by :- (pronounced "if") in the standard Edinburgh syntax),
I would argue that it isn't a variant of Prolog.
Maybe there are languages /related to/ Prolog without Horn
clauses. I don't know them. I was replying to a C++
advocate who said that Lisp was a mess of ifs and conds.
C++ has these too, so it's a case of the pot calling the
kettle black.
> -- Bruce
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Bruce Hoult wrote in message ...
>In article <············@merki.connect.com.au>,
> "Tom Beer" <········@btfinancialgroup.spamfilter.com> wrote:
>
>> Donald Fisk wrote in message <·················@enterprise.net>...
>> >
>> >As for the mess of ifs and conds, could you explain this? All
>> >programming languages have conditional statements or expressions.
>>
>> Perhaps you mean "all procedural programming languages". There are
variants
>> of Prolog that do not have conditional statements or expressions.
>
>!!!!
>
>*Every* Prolog clause is a great big short-circuit nested if statement.
>With backtracking (which make it series of nested loops).
Hmmm. Are you speaking formally? I don't know enough about languages to know
if this is true in the formal sense.
Even though you can understand a Prolog clause as an if statement, it has
always seemed to me to be something quite different.
Tom.
--
**If at first you don't succeed - destroy any evidence that you tried!**
"Scott" <·············@yahoo.com> wrote in message
·································@posting.google.com...
> Hello!
>
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
>
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
>
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
> not too sure if he is qualified to give this type of advice...
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either. So I thought about this A LOT,
> and I'm wonderingif I could ask for advice on the internet.
>
> Thanks in advance for your time...
Hi Scott,
Well you got a lot of good advice up there, but they kinda skipped around
the issue a bit so I'll try and fill in the gaps:
I asked about a particular language to learn and although what eveyone said
above was great advice you DO still need to pick one or two to play with:
I started learning programing about 3 year ago and though i might not be a
shit hot as a lot of the guys here, I have the added advnatage of a. still
being a learner, and b. remembering what those very very first steps were
like.
So without further adue I'm going to suggest:
Language 1:
- Java - In my opinion it is definately one of, if not the best language for
a beginner who wants to learn modern programming eg Object Oreiented.
Java takes an awful lot from C++, which is also a very impressive language,
but it is also more complicated than java.
Java is deliberately very powerful but does a great job of hiding the
complexities of C++ and does a good job of watching out for you as you
learn. It will also take you 85% there if you want to go that final mile
and take on the mother language C++
The following books in conjunction with the internet (java is very well
supported on the net!) will get you to a more than competent level:
1. Thinking in Java by Bruce Eckel - Somehow manages to cover just about the
entire language - bells and whistel en all, all in one book!. Very good at
explaining the complex stuff like it were simple as pie!
2. Java for student by bell and parr(I think) - It is the other room!
Language 2
Depends on what sort of stuff you'd like to do with your programming. If you
want to look into cgi stuff and making dynamic web pages choose perl
Perl is ok (in my opinion) I dont think its the nicest language to learn
first off. I'm glad I came from a partial java background first.
If you want another language where you can make GUIs rapidly then I'd choose
VB - its a nice and straight forward language that is good for quick and
dirty programs but then you would use C++ java for harder work
The best advice though would be to listen to what everyone in this thread
says and follow up on conflicting suggestions - look into both sides of any
disagreements
Take care and enjoy
Simon
On Sun, 15 Sep 2002 13:03:10 +0100, Simon Harvey wrote:
> Language 2
>
> Depends on what sort of stuff you'd like to do with your programming. If
> you want to look into cgi stuff and making dynamic web pages choose perl
> Perl is ok (in my opinion) I dont think its the nicest language to learn
> first off. I'm glad I came from a partial java background first.
Please don't promote the fallacy that Perl is a CGI-only language. Perl
is a general purpose language and CGI programming is only one area where
it is particularly popular.
I've been programming in Perl for seven years, and well under half of
that work has been CGI programming.
Dave...
--
Shoot some of those missiles, think of us as fatherless scum
It won't be forgotten 'cause we'll never say anything nice again
Will we?
> Please don't promote the fallacy that Perl is a CGI-only language. Perl
> is a general purpose language and CGI programming is only one area where
> it is particularly popular.
A good point to raise Dave. I didnt (mean to) imply that perl was only for
cgi prgramming - just that if that was what he would like to do, then perl
is the obvious choice. He could indeed use C++ for cgi - it's obviously not
just for cgi either. I was just trying to imagine why he might like to
program and give him suggestions for a couple of scenarios
A good point you have! - Yoda
Simon
Perl is certainly not a good language to learn as a beginner. Most Perl
code you will find is obfuscated, as Perl syntax promotes obfuscation.
(After learning another language then taking a look at Perl, this will be
self-evident.) Only a very disciplined Perl programmer would be able to
escape the self-obfuscating nature of Perl.
Perl is the ultimate shorthand. You can express quite a bit in only a few
lines of Perl... quite powerful.. but those few lines will look like a
monkey was bashing at the keyboard unless you are a Perl expert.
Perl has it's place, but learn something easier first.
It sounds like I am bashing Perl, and I admit I find it to be a ridiculous
language, but I will certainly admit that if you can stomach it, there are
many things that can be done in a few lines of Perl that would take many
more lines of code in other languages. Some people really like that.
Scott
"Dave Cross" <····@dave.org.uk> wrote in message
········································@dave.org.uk...
<snip>
> Please don't promote the fallacy that Perl is a CGI-only language. Perl
> is a general purpose language...
<snip>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.386 / Virus Database: 218 - Release Date: 2002-09-09
On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
> Perl is certainly not a good language to learn as a beginner. Most Perl
> code you will find is obfuscated, as Perl syntax promotes obfuscation.
This is nonsense. Please present some evidence to back up your claims.
Dave...
--
It was long ago and it was far away
And it was so much better that it is today
In article <····································@dave.org.uk>,
····@dave.org.uk says...
> On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
>
> > Perl is certainly not a good language to learn as a beginner. Most Perl
> > code you will find is obfuscated, as Perl syntax promotes obfuscation.
>
> This is nonsense. Please present some evidence to back up your claims.
>
> Dave...
>
>
check out the obfuscated perl contest....
KAC
--
Kenny A. Chaffin
KAC Website Design - http://www.kacweb.com
Custom/Contract Programming, Graphics, Design
Poetry Page: http://www.kacweb.com/poems/
Also sprach Kenny Chaffin:
> In article <····································@dave.org.uk>,
> ····@dave.org.uk says...
>> On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
>>
>> > Perl is certainly not a good language to learn as a beginner. Most Perl
>> > code you will find is obfuscated, as Perl syntax promotes obfuscation.
>>
>> This is nonsense. Please present some evidence to back up your claims.
> check out the obfuscated perl contest....
Eh? Just because a thing like the OPC is feasible in a language doesn't
mean it is its only way of writing code. I suggest you go to
http://search.cpan.org/, pick up a random module and view the
corresponding source.
And if you think that Perl promotes obfuscation, why not come up with a
piece of real obfuscated Perl code? You'll realize that it's not that
easy to do it 'properly', that's why an OPC and also Perl Golf can
exist.
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
On Sep 16, Kenny Chaffin inscribed on the eternal scroll:
> ····@dave.org.uk says...
> > On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
> >
> > > Perl is certainly not a good language to learn as a beginner.
petitio principii
> > > Most Perl
> > > code you will find is obfuscated, as Perl syntax promotes obfuscation.
> >
> > This is nonsense. Please present some evidence to back up your claims.
>
> check out the obfuscated perl contest....
Why? If "most Perl code" was obfuscated, there would be no point in
holding a contest. The exception proves the rule.
Perl is certainly _capable_ of being used to write well-structured and
transparent code. As far as learning a language is concerned, surely
that is the key, rather than bandying dubious statistics about its
users, many of whom - present company excepted, of course - appear to
me to be writing FORTRAN in Perl4 -- but then, "physicists write
FORTRAN in any language" (attribution not known, but heard quoted at
CERN many years ago).
cheers
* "Alan J. Flavell" <·······@mail.cern.ch>
| Why? If "most Perl code" was obfuscated, there would be no point in
| holding a contest. The exception proves the rule.
Since you bring this age-old expression up, perhaps you should know what it
really means to those few who know what it really means. From The Concise
Oxford Dictionary of Proverbs, Oxford University Press 1998, Oxford
Reference Online, 16 SEPT 2002 (they make me say all this, sorry)
The very fact of an exception proves there must be a rule? (Brewer); now
frequently misunderstood and used to justify inconsistency. Cf. L. exceptio
probat regulam in casibus non exceptis, the exception confirms the rule in
cases not excepted.
This URL is also a required part of the reference, but it appears not to
work unless you are a subscriber. Oh, well, for the IP lawyers, then:
<http://www.oxfordreference.com/views/ENTRY.html?subview=Main&entry=t90.000645>
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On Mon, 16 Sep 2002 11:58:14 +0100, Kenny Chaffin wrote:
> In article <····································@dave.org.uk>,
> ····@dave.org.uk says...
>> On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
>>
>> > Perl is certainly not a good language to learn as a beginner. Most
>> > Perl code you will find is obfuscated, as Perl syntax promotes
>> > obfuscation.
>>
>> This is nonsense. Please present some evidence to back up your claims.
>>
> check out the obfuscated perl contest....
I am well aware of the obfuscated perl contest, It has no relevance to
this discussion. Just because it's possible to write obfuscated code in a
language, that's not the same as saying that the syntax promotes
obfuscation.
Dave...
--
And crawling on the planet's face, some insects called the human race
Lost in time, and lost in space. And meaning.
Re: Does Perl's syntax promote obfuscation?
(The meaning of 'obfuscation' really needs to be defined. I agree that
intentional obfuscation has very little to do with it. I'd also like to
point out that Perl has eliminated several sources of obfuscation over
the years, e.g. by adding a module mechanism.)
It can be argued that a working syntax for a programming language cannot
promote true obfuscation -- if it did, it would be hard or impossible to
write a processor for it.
But surely we mean that an obfuscated program is worded in a way that
makes it hard for a (human) reader to grasp the meaning of the code.
Some syntaxes (e.g. C++, Cobol, Java) require the programmer to write
extensive and detailed instructions which are hard to take in: this can
be said to promote obfuscation. In this case, potential obfuscation can
be measured in LOC, and can be controlled by coding practice.
Some languages (Prolog, ML, etc) lock their syntax inside some formalism
that may not be very readable to everyone (though crystal clear to those
who are familiar with it). Consider this ML fragment:
fun first (a,b) = a
This is self-explanatory or incomprehensible depending on your
background (and when the interpreter responds "val ('a, 'b) first = fn :
'a * 'b -> 'a" you might well wonder if this is some kind of error
message). In this case, obfuscation is totally subjective, and can be
eliminated with training.
What about Perl, then? I find there are mainly two traits of Perl's
syntax that 'promote obfuscation':
1. Switching back and forth between detailed and abstract. This makes
the 'pace' of Perl code uneven and hard to read. This is harder to
measure than the relatively predictable and uniform code bloat of other
languages, and cannot be controlled by coding practices.
2. TMTOWTDI. The syntax is constructed to be flexible and to allow
the programmer to indulge in personal idioms. While this is good for
the original coder, there are potential maintenance problems, and
training is only of limited help here.
So, *does* Perl's syntax promote obfuscation? Yes, I think it does. Do
I therefore stick pins into wax dolls of Wall, Schwartz, and
Christiansen? No. The same traits that promote obfuscation also make
Perl extremely useful and enjoyable to program in.
On Mon, 16 Sep 2002 04:58:14 -0600, ·····@kacweb.com said...
>
> check out the obfuscated perl contest....
Should that be done before, or after, one checks out the obfuscated C
code contest?
Dave Cross <····@dave.org.uk> writes:
> On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
>
> > Perl is certainly not a good language to learn as a beginner. Most Perl
> > code you will find is obfuscated, as Perl syntax promotes obfuscation.
>
> This is nonsense. Please present some evidence to back up your claims.
Which claim, that Perl syntax promotes obfuscation? What more evidence
do you want than the perl man pages?
p.s. I'm a reasonably fluent perl programmer, before you flame on.
I didn't really think it need an example since it is so self-evident. Show
me any Perl function and tell me what it does (so I dont' have to waste time
"decoding" Perl. And I can show you a Java function that will do the same.
Give both programs to someone that does not know Perl or Java and see which
one they can figure out first. My bet is on Java.
As I stated in my first message - that doesn't mean that Perl doesn't have
it's place and I don't mean to imply that Perl is not more efficient for
various tasks. It is *my opinion* however that Perl (or perhaps it is
common Perl coding practice) tends to produce obfuscated code.
As an example I give a significant application written in Perl: Bugzilla.
Here's a small trivial function that demonstrates the rediculous result of
Perl syntax:
# Perl function to trim white space form both ends of a string
sub trim {
($_) = (@_);
s/^\s+//g;
s/\s+$//g;
return $_;
}
Now of course that function is built-in to the Java runtime libraries, so
using the built-int function would not be fair. But consider this simple
approximation - NOT using regular expression, which are also available in
Java...
public String trim( String s ) {
int startPos = -1;
for(int i = 0; i < s.length(); i++) {
if( !Character.isWhitespace( s.charAt(i) ) ) {
startPos = i;
break;
}
}
int endPos = -1;
for(int i = s.length()-1; i >=startPos; i--) {
if( !Character.isWhitespace( s.charAt(i) ) ) {
endPos = i;
break;
}
}
if( startPos == -1 )
return "";
else
return s.substring(startPos,endPos+1);
}
It isn't the most efficient code - it's just what I came up with on the
spot. Yes it is much wordier, Perl can be compact that's for sure. But I
think a beginner taking a look at the code has a MUCH better chance of
understanding the Java version, that was my point.
What is it about Perl syntax that promote obfuscation? Simple things like
"$_" or ·@_" when symbols with proper names could be used instead. Even
in my example I arbitrarily picked a single letter name for my parameter
('s') - but it is still much clearer.
Scott
"Dave Cross" <····@dave.org.uk> wrote in message
·········································@dave.org.uk...
> On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
>
> > Perl is certainly not a good language to learn as a beginner. Most Perl
> > code you will find is obfuscated, as Perl syntax promotes obfuscation.
>
> This is nonsense. Please present some evidence to back up your claims.
>
> Dave...
>
> --
> It was long ago and it was far away
> And it was so much better that it is today
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.389 / Virus Database: 220 - Release Date: 2002-09-16
>>>>> "SP" == Scott Palmer <············@sympatico.ca> writes:
SP> Here's a small trivial function that demonstrates the rediculous result of
SP> Perl syntax:
SP> # Perl function to trim white space form both ends of a string
SP> sub trim {
SP> ($_) = (@_);
SP> s/^\s+//g;
SP> s/\s+$//g;
SP> return $_;
SP> }
i didn't want to get into this thread but that is abyssmal perl code.
it shows your lack of perl skills rather than any issue with perl.
the saying goes that you can program badly in nay language. in over 28
years of coding i have seen too much bad code in too many languages to
refute that.
sub trim {
my ($text) = @_ ;
# first off, get rid of the useless parens and use a named variable. no
# one who knows perl assigns a sub arg to $_. and the way you did it
# would clobber any use of $_ in the call stack.
# now use the bind operator to trim leading white space.
$text =~ s/^\s+//;
# no need for the useless /g modifier. that can only match once so don't
# add extraneous and confusing options
# oh, that is too hard to understand. so use the /x modifier and COMMENT it
$text =~ s{ # we are going to trim leading spaces
^ # start at the beginning of the string
\s+ # match any white space
}
{}x ; # and replace it with nothing thereby
# stripping leading white space.
$text =~ s/\s+$//; # i won't expand this one.
# by the way, regexes are really a minilanguage which are used in almost
# every popular language today. and most try to emulate or steal perl's
# regex features. so using them in perl and your silly character loop in
# java is comparing apples to pc's.
return $text ; # duh, return the original, stripped text.
}
was that so hard? easy to understand, concise but well explained and a
hell of a lot shorter and probably much faster than the java code.
SP> It isn't the most efficient code - it's just what I came up with
SP> on the spot. Yes it is much wordier, Perl can be compact that's
SP> for sure. But I think a beginner taking a look at the code has a
SP> MUCH better chance of understanding the Java version, that was my
SP> point.
not really. if someone is using perl and doesn't understand regexes
(especially simple ones like that) they shouldn't be coding perl or any
language. they are well documented with a tutorial and a quick reference
as well as a full reference that all come with perl. and the excellent
book mastering regular expressions can help too. the second edition just
came out and it covers regexes in many languages and programs as well as
their differences.
SP> What is it about Perl syntax that promote obfuscation? Simple
SP> things like "$_" or ·@_" when symbols with proper names could be
SP> used instead. Even in my example I arbitrarily picked a single
SP> letter name for my parameter ('s') - but it is still much clearer.
and you did't use the named variables. i eschew the use of $_ and
encourage that practice. and @_ is always used at the beginning of subs
so it is not obscure due to its common use and obvious place. for
fearful types like yourself there is even an English module which
provides named aliases for all of perl's special variables. but since
all of those are fully explained in the perlvar document (which comes
with perl, of course) no one seems to mind using @_. in fact use of
English is frowned upon as very few people use it and it can be more
confusing than using the well known special variables.
and way before the obsfucated perl contests there were obsfucated c
contests. and c++ can be more confusing than c to many. you can write
obsfucated code in any language (but befunge :-).
so your argument holds no water. you can write crappy java and crappy
perl. i happen to write very good perl. i also write (and have written
tons of) very good c. and very good PL/I and very good pdp-11
assembler. does that make those languages better than java? no, it is
the skill of the coder that matters, not the language. i choose perl
since it maps well to my brain. i know lisp (if you went to mit or use
emacs you know lisp) and i hate it. it doesn't map to my brain. i WANT
syntax to help me. if i didn't i would just code in postscript. ever see
a lisp regular expression? i want multiple quoting mechanisms. because
lisp only has plain strings it becomes backwhack city to get anything
useful done. try counting \ chars all day long for your amusement. i
want dynamic late binding of method calls. i use that massively in my
networking toolkit called stem (see .sig). that could never be written
in java since it doesn't support such things. stem can load modules and
send messages to them without any predefined knowledge anywhere of the
methods. not simple to do in almost any language. trivial in perl.
so stop this stupid language war thread already. i can rip any language
apart in seconds. when you have used so many and seen the features come
and go, it becomes a trivial exercise and not worth the effort. even
perl has major flaws in my eyes. perl6 will be much better in many
ways. it will have a complete grammar and parsing system builtin which
will make text processing easier and more understandable than current
regexes. you should be scared as it will dominate the world when
released. :)
you like a language because it LIKES YOU. you find it easier to express
your thoughts in it. remember the number one rule of coding:
code is for people, not computers.
and people like different things. otherwise we would all be coding in
fortran.
uri
--
Uri Guttman ------ ···@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Uri Guttman <···@stemsystems.com> writes:
> i know lisp (if you went to mit or use emacs you know lisp) and i
> hate it. it doesn't map to my brain. i WANT syntax to help me. if i
> didn't i would just code in postscript. ever see a lisp regular
> expression? i want multiple quoting mechanisms. because lisp only
> has plain strings it becomes backwhack city to get anything useful
> done. try counting \ chars all day long for your amusement.
Tsk, right after chiding someone for criticizing Perl based on lousy
Perl skills, you turn around and do the same to Lisp. It sounds like
you know an old Lisp dialect (emacs lisp is essentially a time-warp),
and not very well. Lisp has very simple syntax, and this is extremely
useful for one reason: it lets the programmer easily define syntax for
the problem at hand. Yes, if you were trying to do regexps in Lisp
using strings, it will be backwhack city -- but why on earth would you
do that?!? This gets back to the syntax issue. I hardly use regexps
in my Lisp, but back when I used them more often, my code would not
look like this:
(let ((re "^\\(\\w+\\)\\|\\(***\\)"))
;; yuck!
(use-regular-expression re))
It would look like this:
(let ((re (regexp :begin (or (>=1 :whitespace)
"***"))))
;; ahhh ... once you're used to prefix notation, this is
;; nice and easy to read.
(use-regular-expression re))
Like you said earlier in your article, regular expressions are a
little embedded language.
> i want dynamic late binding of method calls. i use that massively in
> my networking toolkit called stem (see .sig). that could never be
> written in java since it doesn't support such things. stem can load
> modules and send messages to them without any predefined knowledge
> anywhere of the methods. not simple to do in almost any
> language. trivial in perl.
Sounds like you want a modern Lisp dialect ;)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
[snip]
> I hardly use regexps in my Lisp, but back when I used them more often,
> my code would not look like this:
>
> (let ((re "^\\(\\w+\\)\\|\\(***\\)"))
> ;; yuck!
> (use-regular-expression re))
>
> It would look like this:
>
> (let ((re (regexp :begin (or (>=1 :whitespace)
> "***"))))
> ;; ahhh ... once you're used to prefix notation, this is
> ;; nice and easy to read.
> (use-regular-expression re))
Knowing what I do of regexps, and of lisp, I would expect something more
like:
(regexp (or (non-capturing-group
:begin-of-line (literal "(") (>=1 :word-chars)
(literal ")")
)
(literal "(***)")
))
or it would be:
(regexp (or (non-capturing-group
:begin-of-line (capturing-group (>=1 :word-chars))
)
(capturing-group (literal "***"))
))
... depending on the meaning of "\\(" and "\\)" in your favorite way of
interpreting string representations of regular expressions. Note that
in perl, and many other languages, \w means word-chars, and \s means
whitespace chars.
> Like you said earlier in your article, regular expressions are a
> little embedded language.
And a very useful and powerful one, too! :)
In fact, perl REs can be used for solving NP-complete problems...
see: http://perl.plover.com/NPC/
--
Announcement in the Zoo:
"Please don't scare the ostriches! Cement floor!"
"Uri Guttman" <···@stemsystems.com> wrote in message
···················@mail.sysarch.com...
> SP> # Perl function to trim white space form both ends of a string
> SP> sub trim {
> SP> ($_) = (@_);
> SP> s/^\s+//g;
> SP> s/\s+$//g;
> SP> return $_;
> SP> }
>
> i didn't want to get into this thread but that is abyssmal perl code.
> it shows your lack of perl skills rather than any issue with perl.
Ah, but it isn't MY code.. I took it from Bugzilla.. I find it is a typical
example of Perl code.
> the saying goes that you can program badly in nay language. in over 28
> years of coding i have seen too much bad code in too many languages to
> refute that.
I agree. My point was referring to "typical" code in whatever language you
choose.
> sub trim {
>
> my ($text) = @_ ;
>
> # first off, get rid of the useless parens and use a named variable. no
> # one who knows perl assigns a sub arg to $_. and the way you did it
> # would clobber any use of $_ in the call stack.
I have rarely seen Perl code that uses a named parameter. And I already
find the first 2 lines of your example to be ridiculous syntax. It's not
confusing if you know Perl, but compared to the Java equivalent, which does
so much more to show what is happening... Java code would declare a return
type, Java code would show the function arguments, their types, the order
they are expected in, how many there are... compare that to "sub trim"
where all the information you get is the name of the method. It is these
simple details that would help a beginner.
> # now use the bind operator to trim leading white space.
>
> $text =~ s/^\s+//;
>
> # no need for the useless /g modifier. that can only match once so don't
> # add extraneous and confusing options
Useless modifier? - nice to have those around in a language.. no, something
like that couldn't possible contribute to obfuscation... sigh.. you are only
proving my point...
I won't get into the concept that regular expressions alone can be quite
scary looking for a beginner (remember we are talking about beginners here).
> # oh, that is too hard to understand. so use the /x modifier and COMMENT
it
>
> $text =~ s{ # we are going to trim leading spaces
> ^ # start at the beginning of the string
> \s+ # match any white space
> }
> {}x ; # and replace it with nothing thereby
> # stripping leading white space.
Typical Perl code that you will find in the real world is not commented so
extensively. You have done a good job of leading a beginner through this
code, but from my own personal experience I can say that is not what they
will find when they look at most code.
Anyway.. here you are explaining regular expressions more than Perl. I
could have used regular expression in my Java example as well.. and if I did
it would still be more intuitive to most.
> $text =~ s/\s+$//; # i won't expand this one.
>
> # by the way, regexes are really a minilanguage which are used in almost
> # every popular language today. and most try to emulate or steal perl's
> # regex features. so using them in perl and your silly character loop in
> # java is comparing apples to pc's.
>
> return $text ; # duh, return the original, stripped text.
> }
>
> was that so hard? easy to understand, concise but well explained and a
> hell of a lot shorter and probably much faster than the java code.
<snip>
> so stop this stupid language war thread already. i can rip any language
It wasn't a language war.. (although it seems to have turned into that).
It was advice to a beginner. Start with a language with a more intuitive
syntax - that's all.
> you like a language because it LIKES YOU. you find it easier to express
> your thoughts in it. remember the number one rule of coding:
>
> code is for people, not computers.
That is exactly my argument against using Perl for a beginner. I believe it
is less likely to "like you". It's not just my own personal view, but from
talking with all of my colleagues.. everyone of them laughed when I showed
them Bugzilla code.
> and people like different things. otherwise we would all be coding in
> fortran.
I agree.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.389 / Virus Database: 220 - Release Date: 2002-09-17
Also sprach Scott Palmer:
> "Uri Guttman" <···@stemsystems.com> wrote in message
> ···················@mail.sysarch.com...
>> # now use the bind operator to trim leading white space.
>>
>> $text =~ s/^\s+//;
>>
>> # no need for the useless /g modifier. that can only match once so don't
>> # add extraneous and confusing options
>
> Useless modifier? - nice to have those around in a language.. no, something
> like that couldn't possible contribute to obfuscation... sigh.. you are only
> proving my point...
And you have obviously no idea of Perl regexes. Uri's point was that the
modifier was useles in this context. But see:
my @matches = "abcdefghi" =~ /(..?)/g;
print ·@matches";
__END__
ab cd ef gh i
If you omit the g-modifier here (stands for matching globally), you just
get 'ab' in the first element of the array.
By the way: Lisp equivalent of the above code? I am not implying that it
is ugly in Lisp...I just would like to see how a Lisper would extract
group of two characters from a string and collect those in a list.
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
Tassilo v. Parseval wrote:
> my @matches = "abcdefghi" =~ /(..?)/g;
> print ·@matches";
> __END__
> ab cd ef gh i
>
> By the way: Lisp equivalent of the above code? I am not implying that
> it is ugly in Lisp...I just would like to see how a Lisper would
> extract group of two characters from a string and collect those in a
> list.
(defun return-pairs (string)
"Return a list of the characters in string grouped into pairs.
How funky."
(let ((string-length (length string)))
(loop as i from 0 below string-length by 2
collect (subseq string i (when (< i (- string-length 2)) (+ i 2))))))
(return-pairs "abcdefghi")
F'up2 cll.
--
Wolfgang Mederle
$BONMOT
Hi Wolfgang Mederle,
> Tassilo v. Parseval wrote:
>
>> my @matches = "abcdefghi" =~ /(..?)/g;
>> print ·@matches";
>> __END__
>> ab cd ef gh i
>>
>> By the way: Lisp equivalent of the above code? I am not implying that
>> it is ugly in Lisp...I just would like to see how a Lisper would
>> extract group of two characters from a string and collect those in a
>> list.
>
> (defun return-pairs (string)
> "Return a list of the characters in string grouped into pairs.
> How funky."
> (let ((string-length (length string)))
> (loop as i from 0 below string-length by 2
> collect (subseq string i (when (< i (- string-length 2)) (+ i 2))))))
>
> (return-pairs "abcdefghi")
>
> F'up2 cll.
Here's an example using recursion:
(defun return-pairs (seq)
(if (> (length seq) 1) (cons (subseq seq 0 2) (return-pairs (subseq seq 2)))
(if (= (length seq) 1) (list seq))))
(return-pairs "abcdefghi")
("ab" "cd" "ef" "gh" "i")
Tassilo should also note that these functions have wider application
because they operate on sequences (and lists are sequences):
(return-pairs '(this is a short list of symbols))
((THIS IS) (A SHORT) (LIST OF) (SYMBOLS))
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> writes:
> Hi Wolfgang Mederle,
>
> > Tassilo v. Parseval wrote:
> >
> >> my @matches = "abcdefghi" =~ /(..?)/g;
> >> print ·@matches";
> >> __END__
> >> ab cd ef gh i
> >>
> >> By the way: Lisp equivalent of the above code? I am not implying that
> >> it is ugly in Lisp...I just would like to see how a Lisper would
> >> extract group of two characters from a string and collect those in a
> >> list.
> >
> > (defun return-pairs (string)
> > "Return a list of the characters in string grouped into pairs.
> > How funky."
> > (let ((string-length (length string)))
> > (loop as i from 0 below string-length by 2
> > collect (subseq string i (when (< i (- string-length 2)) (+ i 2))))))
> >
> > (return-pairs "abcdefghi")
> >
> > F'up2 cll.
>
> Here's an example using recursion:
>
> (defun return-pairs (seq)
> (if (> (length seq) 1) (cons (subseq seq 0 2) (return-pairs (subseq seq 2)))
> (if (= (length seq) 1) (list seq))))
>
> (return-pairs "abcdefghi")
> ("ab" "cd" "ef" "gh" "i")
>
> Tassilo should also note that these functions have wider application
> because they operate on sequences (and lists are sequences):
>
> (return-pairs '(this is a short list of symbols))
> ((THIS IS) (A SHORT) (LIST OF) (SYMBOLS))
... and vectors.
* (return-pairs (vector 1 2 3 4 5 6 7))
(#(1 2) #(3 4) #(5 6) #(7))
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
"Uri Guttman" <···@stemsystems.com> wrote in message ···················@mail.sysarch.com...
>
> by the way, regexes are really a minilanguage which are used in almost
> every popular language today. and most try to emulate or steal perl's
> regex features.
Note that Perl "stole" (not a good word choice, IMO) much of its
regex and substitution syntax from earlier Unix tools. This is not
a bad thing, of course.
> if someone is using perl and doesn't understand regexes
> (especially simple ones like that) they shouldn't be coding perl or any
> language.
That's a bit extreme, don't you think? (Not to mention a bit confused;
I'm not sure what it means to say that "if someone is using perl ...
they shouldn't be coding [in] any language.") I guess what you mean
is that training in the use of regular expressions should be a prerequisite
for writing computer programs. But regular expressions are not applicable
to every domain, so that seems to narrow to me.
> no, it is the skill of the coder that matters, not the language.
I'd agree that the skill of the coder is the most important factor, but
it's not *everything.* It's not like the choice of language is irrelevant.
Marshall
>>>>> "MS" == Marshall Spight <·······@dnai.com> writes:
MS> "Uri Guttman" <···@stemsystems.com> wrote in message
>> if someone is using perl and doesn't understand regexes (especially
>> simple ones like that) they shouldn't be coding perl or any
>> language.
MS> That's a bit extreme, don't you think? (Not to mention a bit
MS> confused; I'm not sure what it means to say that "if someone is
MS> using perl ... they shouldn't be coding [in] any language.") I
MS> guess what you mean is that training in the use of regular
MS> expressions should be a prerequisite for writing computer
MS> programs. But regular expressions are not applicable to every
MS> domain, so that seems to narrow to me.
you misinterpreted what i said (or i didn't say it well). perl's two
primary features are hashes and regexes. you aren't programming in perl
if you don't use those regularly. so someone who can't figure that out
and study those two features in depth, isn't going to be too good a
programmer in general, hence the comment about they shouldn't be coding
in any language.
>> no, it is the skill of the coder that matters, not the language.
MS> I'd agree that the skill of the coder is the most important
MS> factor, but it's not *everything.* It's not like the choice of
MS> language is irrelevant.
it is not nearly as important as the skill of the coder. as i said i
have seen great and crappy code in every language i have worked around
or read. so that implies the language is independent of the coding
skill. you pick a language because you like it. it is that simple. you
can't absolutely state any language is superior to all others as you
can't compare them in any meaningful way. it all falls down to
subjective opinions which end up in silly language wars like this
thread.
uri
--
Uri Guttman ------ ···@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
"Uri Guttman" <···@stemsystems.com> wrote in message ···················@mail.sysarch.com...
> >>>>> "MS" == Marshall Spight <·······@dnai.com> writes:
>
> you misinterpreted what i said (or i didn't say it well). perl's two
> primary features are hashes and regexes. you aren't programming in perl
> if you don't use those regularly. so someone who can't figure that out
> and study those two features in depth, isn't going to be too good a
> programmer in general, hence the comment about they shouldn't be coding
> in any language.
Ah, I understand now.
> >> no, it is the skill of the coder that matters, not the language.
>
> MS> I'd agree that the skill of the coder is the most important
> MS> factor, but it's not *everything.* It's not like the choice of
> MS> language is irrelevant.
>
> it is not nearly as important as the skill of the coder. as i said i
> have seen great and crappy code in every language i have worked around
> or read. so that implies the language is independent of the coding
> skill. you pick a language because you like it. it is that simple.
I pretty much agree.
> you
> can't absolutely state any language is superior to all others as you
> can't compare them in any meaningful way. it all falls down to
> subjective opinions which end up in silly language wars like this
> thread.
I don't agree that programming languages can't be compared in any
meaningful way. If there is a problem, it's that there are *too many*
meaningful ways to compare programming languages, and no
clear way to choose among them.
That doesn't mean one language is as good as any other. There
are significant differences. I hope no one will contradict me when
I say that the dialect of BASIC that I learned as a youngster was
a *bad* language by modern standards.
Marshall
On Sat, 21 Sep 2002 04:30:34 GMT, Uri Guttman <···@stemsystems.com>
wrote:
[...]
> the saying goes that you can program badly in nay language. in over 28
> years of coding i have seen too much bad code in too many languages to
> refute that.
>
> sub trim {
>
> my ($text) = @_ ;
>
> # first off, get rid of the useless parens and use a named variable. no
> # one who knows perl assigns a sub arg to $_. and the way you did it
> # would clobber any use of $_ in the call stack.
It may be a thing of personal prefrence but I would do.
my $text = shift;
Is there anybenifit in doing
my ($text) = @_ ;
In the example you have given?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
"Scott Palmer" <············@sympatico.ca> wrote in message news:<·······················@news20.bellglobal.com>...
> # Perl function to trim white space form both ends of a string
When you find yourself writing such functions, you should stop and
think. Converting a string of text into a representation more easily
processed by a computer program is called parsing. Parsing is a
heavily researched and developed area of computer science.
Reinventing the wheel is one of the biggest sources of bugs and
inefficiencies in computer programs. What you should stop and think
about is why you're not simply invoking a canonical parsing function
to process your text. Such thinking is a major component of software
quality.
··········@mailandnews.com (Software Scavenger) writes:
> "Scott Palmer" <············@sympatico.ca> wrote in message news:<·······················@news20.bellglobal.com>...
>
>> # Perl function to trim white space form both ends of a string
>
> When you find yourself writing such functions, you should stop and
> think. Converting a string of text into a representation more easily
> processed by a computer program is called parsing.
and since most of the parsed strings in real life of a programmer
happen, in fact, to be the output of other programs, parsing them
instead of fixing those other programs (to output some structured
representation, like sexps) is called stupidity. but it's such a
widespread form of stupidity that most people never notice.
--
Incrementally extended heuristic algorithms tend inexorably toward the
incomprehensible.
What a ridiculous statement. Why on Earth would you assume the programmer
has the ability to change everyone else's program????
Scott
"Michael Livshin" <······@cmm.kakpryg.net> wrote in message
···················@cmm.kakpryg.net.cmm...
> ··········@mailandnews.com (Software Scavenger) writes:
>
<snip>
>
> and since most of the parsed strings in real life of a programmer
> happen, in fact, to be the output of other programs, parsing them
> instead of fixing those other programs (to output some structured
> representation, like sexps) is called stupidity. but it's such a
> widespread form of stupidity that most people never notice.
.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.391 / Virus Database: 222 - Release Date: 2002-09-19
"Scott Palmer" <············@sympatico.ca> writes:
> What a ridiculous statement. Why on Earth would you assume the programmer
> has the ability to change everyone else's program????
in my experience (I should have qualified my original statement so,
sorry), most programs whose output is to be parsed are, indeed,
developed in-house. YMMV.
--
Hit the philistines three times over the head with the Elisp reference manual.
-- Michael A. Petonic
Michael Livshin <······@cmm.kakpryg.net> wrote:
> Software Scavenger <··········@mailandnews.com> wrote:
> > When you find yourself writing such functions, you should stop and
> > think. Converting a string of text into a representation more easily
> > processed by a computer program is called parsing.
> and since most of the parsed strings in real life of a programmer
> happen, in fact, to be the output of other programs, parsing them
> instead of fixing those other programs (to output some structured
> representation, like sexps) is called stupidity.
No, it's called being a small customer of a closed source vendor.
Not everyone gets to deal with only software that they are able to
modify (or have modified) without having to reimplement it from scratch.
If the closed source code is otherwise correct and efficient, do I spend
an hour or two writing a parser every so often, or do I spend days,
weeks, or possibly years rewriting and debugging important libraries,
applications, or OSs?
hmm... tough choice.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
i think ALL of you need to take a look at:
http://99-bottles-of-beer.ls-la.net/0-9.html
and look at all the different versions of the "song"
99-beer bottles on a wall.
it's written in a lot lot lot of languages, most i have never even thought
of being heard of...heh
anyways.
code in whatever feels good and right to 'you' and thats all im gonna say
about this rather sad 'language-war' with its 'i can code that line much
better than you can'.
enjoy yourself...
and may the source be with you at all times...
-the:groovester-
"malte" <··············@gmx.net> wrote in message
····················@news.t-online.com...
> i think ALL of you need to take a look at:
> http://99-bottles-of-beer.ls-la.net/0-9.html
> and look at all the different versions of the "song"
> 99-beer bottles on a wall.
> it's written in a lot lot lot of languages, most i have never even thought
> of being heard of...heh
This page misses an excellent Lisp version with a hilarious twist to it
posted here by Kent Pitman a while ago (and you don't need to know lisp to
get a kick out of it!)
http://groups.google.com/groups?selm=sfwd75gm5np.fsf%40world.std.com
I still get a kick out of that :)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> wrote in message ················@otis.netspace.net.au...
> This page misses an excellent Lisp version with a hilarious twist to it
> posted here by Kent Pitman a while ago (and you don't need to know lisp to
> get a kick out of it!)
>
> http://groups.google.com/groups?selm=sfwd75gm5np.fsf%40world.std.com
>
> I still get a kick out of that :)
Actually it is there under C for Common Lisp
http://99-bottles-of-beer.ls-la.net/c.html#Common-Lisp-(format-string)
Wade
> Actually it is there under C for Common Lisp
>
> http://99-bottles-of-beer.ls-la.net/c.html#Common-Lisp-(format-string)
Lisp is particularly appropriate for this particular application
because of the bottoms-up programming style [1] that it encourages. I
was very pleased to see the Lisp community rise to the occasion.
[1]The concept of bottoms-up programming was first formally described
in a public forum by the author during an AI Seminar end-of-semester
party held at Stanford University in 1989. :-)
--
Fred Gilham ······@csl.sri.com
Ah, the 20th century, when the flight from reason crash-landed into
the slaughterhouse. --- James Ostrowski
Coby Beck wrote:
> This page misses an excellent Lisp version with a hilarious twist to it
> posted here by Kent Pitman a while ago (and you don't need to know lisp to
> get a kick out of it!)
>
> http://groups.google.com/groups?selm=sfwd75gm5np.fsf%40world.std.com
yes, it is awesome!!!!!! =)
thanks for the post!
-the:groovester-
Coby Beck wrote:
> This page misses an excellent Lisp version with a hilarious twist to it
> posted here by Kent Pitman a while ago (and you don't need to know lisp to
> get a kick out of it!)
>
> http://groups.google.com/groups?selm=sfwd75gm5np.fsf%40world.std.com
>
> I still get a kick out of that :)
A n escalation of this is the C program that gets an approximation of
pi by computing its own area:
/*
* Program to compute an approximation of pi
* by Brian Westley, 1988
* (requires pcc macro concatenation; try gcc -traditional-cpp)
*/
#define _ -F<00||--F-OO--;
int F=00,OO=00;
main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_
_-_-_-_
}
In article <····························@posting.google.com>,
··········@mailandnews.com (Software Scavenger) wrote:
> "Scott Palmer" <············@sympatico.ca> wrote in message
> news:<·······················@news20.bellglobal.com>...
>
> > # Perl function to trim white space form both ends of a string
>
> When you find yourself writing such functions, you should stop and
> think. Converting a string of text into a representation more easily
> processed by a computer program is called parsing. Parsing is a
> heavily researched and developed area of computer science.
> Reinventing the wheel is one of the biggest sources of bugs and
> inefficiencies in computer programs. What you should stop and think
> about is why you're not simply invoking a canonical parsing function
> to process your text. Such thinking is a major component of software
> quality.
You are indeed correct. Computer Science has come up with a number of
formal types of languages, along with suitable algorithms for parsing
each of them. One such formal means of describing a language is the
"regular expression", which can be recognised by a type of parser known
as a non-deterministic finite state automaton (NFA), which can itself be
implemented via interpretation with backtracking, or by constructing a
deterministic finite state automaton, either explicitly or implicitly.
Such an implementation happens to be built into Perl, and it is ideally
suited to a number of tasks, including this one. (It's less than
ideally suited to a number of tasks for which some people actually use
it, but that is another matter)
The main problem I have with the original Perl subroutine ...
sub trim {
($_) = (@_);
s/^\s+//g;
s/\s+$//g;
return $_;
}
... is that it is too wordy and inefficient. The person who wrote it
doesn't seem to know either regular expressions, Perl's implementation
of them, or Perl itself very well.
It suffices to do the entire pattern recognition with a single regular
expression and a temporary variable is not needed.
sub trim {
shift =~ /^\s*(.*?)\s*$/
}
-- Bruce
Also sprach Bruce Hoult:
> In article <····························@posting.google.com>,
> ··········@mailandnews.com (Software Scavenger) wrote:
> The main problem I have with the original Perl subroutine ...
>
> sub trim {
> ($_) = (@_);
> s/^\s+//g;
> s/\s+$//g;
> return $_;
> }
>
> ... is that it is too wordy and inefficient. The person who wrote it
> doesn't seem to know either regular expressions, Perl's implementation
> of them, or Perl itself very well.
>
> It suffices to do the entire pattern recognition with a single regular
> expression and a temporary variable is not needed.
>
> sub trim {
> shift =~ /^\s*(.*?)\s*$/
> }
But this is not at all the same:
$var = trim (" string ");
print $var;
__END__
1
Oups. You forgot about list versus scalar context. Also, capturing
parens slow the thing down.
For the given task, I suspect the following is most efficient:
sub trim {
$_[0] =~ s/^\s+//;
$_[0] =~ s/\s+$//;
}
This trims in-place. Also, making two regexes is more efficient in this
particular case.
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
In article <············@nets3.rz.RWTH-Aachen.DE>,
"Tassilo v. Parseval" <················@post.rwth-aachen.de> wrote:
> > sub trim {
> > shift =~ /^\s*(.*?)\s*$/
> > }
>
> But this is not at all the same:
>
> $var = trim (" string ");
> print $var;
> __END__
> 1
>
> Oups. You forgot about list versus scalar context. Also, capturing
> parens slow the thing down.
arrg. You're right. I tested it with 'print trim(" foo ")', which
is list context.
sub trim {
shift =~ /^\s*(.*?)\s*$/;
$1
}
-- Bruce
All these silly arguments about "you obviously don't know Perl regexs,
etc..." are proving my point. A beginner would NOT know these things and
they are easier to get wrong (a Perl programmer just demonstrated that)
because they are more unnatural to people. Regexs are powerful and great to
have... but for a beginner, that doesn't know any structured programming, to
start out with Perl syntax is absurd. They are going to have to learn
enough new operators - it is best to minimize the complexity.
Having different variables with essentially the same name.. e.g. @var $var
or in this example the confusion between list and scalar context is exactly
the sort of thing that is more likely to happen in Perl than other
languages. These are issues that don't come up in many other languages,
thus making them easier to learn. Don't dump all this on a beginner, that's
my point. Arguably I would say don't dump all this on anyone... but
obviously some people like it.
Scott
"Bruce Hoult" <·····@hoult.org> wrote in message
································@copper.ipg.tsnz.net...
> In article <············@nets3.rz.RWTH-Aachen.DE>,
> "Tassilo v. Parseval" <················@post.rwth-aachen.de> wrote:
>
> > > sub trim {
> > > shift =~ /^\s*(.*?)\s*$/
> > > }
> >
> > But this is not at all the same:
> >
> > $var = trim (" string ");
> > print $var;
> > __END__
> > 1
> >
> > Oups. You forgot about list versus scalar context. Also, capturing
> > parens slow the thing down.
>
> arrg. You're right. I tested it with 'print trim(" foo ")', which
> is list context.
>
> sub trim {
> shift =~ /^\s*(.*?)\s*$/;
> $1
> }
>
> -- Bruce
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.391 / Virus Database: 222 - Release Date: 2002-09-19
"Scott Palmer" <············@sympatico.ca> wrote in message news:<····················@news20.bellglobal.com>...
> Perl is certainly not a good language to learn as a beginner. Most Perl
> code you will find is obfuscated, as Perl syntax promotes obfuscation.
> (After learning another language then taking a look at Perl, this will be
> self-evident.) Only a very disciplined Perl programmer would be able to
> escape the self-obfuscating nature of Perl.
Only very discpilined programmers are able to write clear code in any
language. Perl is no better or worse than the others.
> Perl is the ultimate shorthand. You can express quite a bit in only a few
> lines of Perl... quite powerful.. but those few lines will look like a
> monkey was bashing at the keyboard unless you are a Perl expert.
So become an expert. I would rather analyze a few lines of Perl than
wade through 100 lines of some other language.
> Perl has it's place, but learn something easier first.
Perl is easy to learn because it is interpreted, and fun to learn
because
the CPAN makes it easy to write useful programs immediately. Example:
I need to automatically FTP some files periodically. This would have
been a day or more of work in C++. With Perl, I just downloaded
Net::FTP,
played with it in the debugger for a couple of minutes, and soon I had
a finished, working script.
The Perl syntax seems 'ridiculous' to someone with experience in only
a couple of other languages. To a beginning programmer, the Perl
syntax
isn't any weirder than the syntax of C++, FORTRAN, or Ada. And it's a
whole lot easier to get started with Perl.
> It sounds like I am bashing Perl, and I admit I find it to be a ridiculous
········@hotmail.com (Kevin Cline) wrote in message news:<····························@posting.google.com>...
> So become an expert. I would rather analyze a few lines of Perl than
> wade through 100 lines of some other language.
On the subject of a few lines of Perl, I'm curious to know what my
Common Lisp "do-combinations" macro would look like if you implemented
the same functionality in Perl. Using it in Common Lisp I can write
something like:
(do-combinations (a b) '(1 2 3)
(print (list a b)))
and the output will be:
(1 2)
(1 3)
(2 3)
It provides completely general combinations iteration, e.g.
(do-combinations (a b c d e) (iota 52)
(deal-poker-hand a b c d e))
etc.
Anyway, I'm just wondering what the equivalent functionality would
look like in Perl.
[posted & mailed]
On 16 Sep 2002, Software Scavenger wrote:
>On the subject of a few lines of Perl, I'm curious to know what my
>Common Lisp "do-combinations" macro would look like if you implemented
>the same functionality in Perl. Using it in Common Lisp I can write
>something like:
>
>(do-combinations (a b) '(1 2 3)
> (print (list a b)))
>
>and the output will be:
>(1 2)
>(1 3)
>(2 3)
This is how I would write it (and it looks mildly Lisp-ish); it might not
be the most efficient way, but I like it:
sub combinations (&·@) {
my ($code, $size) = (shift, shift);
do_cmb($code, $size, [@_], []);
}
sub do_cmb {
my ($c, $s, $set, $idx) = @_;
if (@$idx == $s) { return $c->(@$set[@$idx]) }
else {
for my $i ((@$idx ? $idx->[-1] + 1 : 0) .. $#$set) {
push @$idx, $i; &do_cmb; pop @$idx;
}
}
}
If you want a detailed explanation, I can offer one. The function is used
like so:
combinations { print "(@_)\n" } 2, (1..5);
and the output would be:
(1 2)
(1 3)
(1 4)
(1 5)
(2 3)
(2 4)
(2 5)
(3 4)
(3 5)
(4 5)
--
Jeff "japhy" Pinyan RPI Acacia Brother #734 2002 Acacia Senior Dean
"And I vos head of Gestapo for ten | Michael Palin (as Heinrich Bimmler)
years. Ah! Five years! Nein! No! | in: The North Minehead Bye-Election
Oh. Was NOT head of Gestapo AT ALL!" | (Monty Python's Flying Circus)
Jeff 'japhy' Pinyan <······@rpi.edu> wrote in message news:<·········································@vcmr-104.server.rpi.edu>...
> This is how I would write it (and it looks mildly Lisp-ish); it might not
> be the most efficient way, but I like it:
Yes, it's an elegant algorithm. I'm basically comparing how people
accomplish the same functionality in different languages, using
whatever algorithm seems appropriate for the language. The versions
for languages such as Scheme, OCaml, etc. are in comp.lang.lisp in
discussions about macros etc.
My CL version is a macro which builds nested loops, so there is no
need for it to call any functions at run time, recursive or not. I'm
curious to know if Perl has macros, or if it makes sense for a Perl
program to rewrite Perl code in some situations.
I also wonder if that "print" block of code in your Perl code is a
closure. If outside of the call to combinations, you were to define a
number of local variables, and in the block, you were to add code
which used those, would it work, even though it would be executed by
combinations rather than in line?
i.e.
combinations { print "(@_)\n" } 2, (1..5);
^ block of code ^
(add other code inside the same block, and use variables defined
outside)
I also wonder why the 2 has a comma after it, when the other arguments
to combinations don't.
[posted & mailed]
On 18 Sep 2002, Software Scavenger wrote:
>Jeff 'japhy' Pinyan <······@rpi.edu> wrote in message news:<·········································@vcmr-104.server.rpi.edu>...
>
>> This is how I would write it (and it looks mildly Lisp-ish); it might not
>> be the most efficient way, but I like it:
>
>My CL version is a macro which builds nested loops, so there is no
>need for it to call any functions at run time, recursive or not. I'm
>curious to know if Perl has macros, or if it makes sense for a Perl
>program to rewrite Perl code in some situations.
Perl does have eval(), which allows you to (compile and) execute Perl code
at run-time. You can construct a SPECIFIC chunk of code (such as a
function) with values hard-coded, instead of a function which relies on
several variables. But you can also...
>I also wonder if that "print" block of code in your Perl code is a
>closure. If outside of the call to combinations, you were to define a
>number of local variables, and in the block, you were to add code
>which used those, would it work, even though it would be executed by
>combinations rather than in line?
... use closures.
>i.e.
> combinations { print "(@_)\n" } 2, (1..5);
> ^ block of code ^
> (add other code inside the same block, and use variables defined
>outside)
Yeah, it can be a closure. In this case, the @_ is not interpolated until
the code block is executed, because each execution of the code block sets
@_ to a list of (in this case, 2) values.
sub gt_maker {
my ($n) = @_;
return sub { $_[0] > $n };
}
my $five = gt_maker(5);
if ($five->(8)) { print "8 > 5\n" }
>I also wonder why the 2 has a comma after it, when the other arguments
>to combinations don't.
That's a by-product of Perl's weird syntax rules regarding the '&'
prototype the function has.
sub foo (&@) { (definition) }
foo { code } 1, 2, 3, 4, 5;
is how the code has to be written when using the "code block as the first
argument". Built-in functions that can do that look the same:
@big = grep { $_ > 10_000 } @numbers;
@half = map { $_/2 } @numbers;
@ordered = sort { $a <=> $b } @big, @half;
--
Jeff "japhy" Pinyan RPI Acacia Brother #734 2002 Acacia Senior Dean
"And I vos head of Gestapo for ten | Michael Palin (as Heinrich Bimmler)
years. Ah! Five years! Nein! No! | in: The North Minehead Bye-Election
Oh. Was NOT head of Gestapo AT ALL!" | (Monty Python's Flying Circus)
In article <····························@posting.google.com>,
··········@mailandnews.com (Software Scavenger) wrote:
> My CL version is a macro which builds nested loops, so there is no
> need for it to call any functions at run time, recursive or not. I'm
> curious to know if Perl has macros, or if it makes sense for a Perl
> program to rewrite Perl code in some situations.
Perl doesn't have macros, but it does make sense sometimes for a Perl
program to create Perl code and pass it to eval().
> I also wonder if that "print" block of code in your Perl code is a
> closure.
Yes, Perl functions are closures (if they refer to free variables). If
you put the appropriate magic character as the declaration of a sub
argument then you can pass a function body in using just { } around it,
as you saw there.
> If outside of the call to combinations, you were to define a
> number of local variables, and in the block, you were to add code
> which used those, would it work, even though it would be executed by
> combinations rather than in line?
Yes. In fact, since you can walk the entire tree of namespaces and
fudge about with the "globs" (like CL symbols, except that they have
more than just a value and a function slot), you can actually do just
about *anything* you like, although perhaps not quite with the syntax
you'd like.
-- Bruce
On 9/15/02 5:43 PM, Scott Palmer wrote:
>
> Perl is certainly not a good language to learn as a beginner.
On the contrary, Perl is unique (in my experience) as a language that
lets you be productive while learning only a small subset of the
language. I find it terribly frustrating to have to learn (almost) an
entire language before I can do anything useful in it.
> Most Perl code you will find is obfuscated, as Perl syntax promotes
> obfuscation.
Perl syntax promotes expressiveness (which looks a lot like obfuscation
until you're well versed in the language. ;) )
> Only a very disciplined Perl programmer would be able to
> escape the self-obfuscating nature of Perl.
It's difficult not to take advantage of that /expressiveness/, once
you're aware of it's power.
> Perl is the ultimate shorthand. You can express quite a bit in only a few
> lines of Perl... quite powerful.. but those few lines will look like a
> monkey was bashing at the keyboard unless you are a Perl expert.
Sometimes yes, sometimes no.
Perl is non-orthogonal by design. That flexibility in the syntax often
allows you to write things that are both shorter *and* clearer. IMHO,
the hardest code to read is where the programmer was going through
contortions trying to get around the limitations of a langauge;
something that's rarely necessary in Perl.
-mjc
"Michael Carman" <········@mchsi.com> wrote in message
················@onews.collins.rockwell.com...
>
> Perl syntax promotes expressiveness (which looks a lot like obfuscation
> until you're well versed in the language. ;) )
This supports my point that for a beginner it isn't a good choice.
Scott
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.389 / Virus Database: 220 - Release Date: 2002-09-16
On Sun, 15 Sep 2002 18:43:25 -0400, "Scott Palmer"
<············@sympatico.ca> wrote:
>Perl is certainly not a good language to learn as a beginner.
Yes it is. It is a very easy language for beginners to
learn. You can accomplish a lot of useful tasks knowing
only a few functions. It has the best and least
obfuscated documentation system (perldoc) I have seen
in a programming language, by far the best system
for sharing reusable code (CPAN) and many other
features.
>Most Perl code you will find is obfuscated, as Perl syntax
>promotes obfuscation.
No it doesn't. A bad programmer can write obfuscated
code in any language. Good Perl code is as clear as
anything in existence.
--
Regards, Helgi Briem
helgi AT decode DOT is
A: Top posting
Q: What is the most irritating thing on Usenet?
- "Gordon" on apihna
Based on what Perl code I have seen, I would classify your message as the
ramblings of a lunatic.
:-) Ok I was trying to be funny.. but seriously I can't help but strongly
disagree. However I admit to only seeing one Perl project (Bugzilla) in any
detail as I detested what I saw so much that I simply didn't care to look at
anything more.
Like I said before, "some people like it"... I just can't understand why!
Scott
"Helgi Briem" <·····@decode.is> wrote in message
·······················@news.cis.dfn.de...
> On Sun, 15 Sep 2002 18:43:25 -0400, "Scott Palmer"
> <············@sympatico.ca> wrote:
>
> >Perl is certainly not a good language to learn as a beginner.
>
> Yes it is. It is a very easy language for beginners to
> learn. You can accomplish a lot of useful tasks knowing
> only a few functions. It has the best and least
> obfuscated documentation system (perldoc) I have seen
> in a programming language, by far the best system
> for sharing reusable code (CPAN) and many other
> features.
>
> >Most Perl code you will find is obfuscated, as Perl syntax
> >promotes obfuscation.
>
> No it doesn't. A bad programmer can write obfuscated
> code in any language. Good Perl code is as clear as
> anything in existence.
>
> --
> Regards, Helgi Briem
> helgi AT decode DOT is
>
> A: Top posting
> Q: What is the most irritating thing on Usenet?
> - "Gordon" on apihna
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.389 / Virus Database: 220 - Release Date: 2002-09-16
On Sun, 15 Sep 2002 09:03:10 -0300, Simon Harvey wrote:
> Hi Scott,
>
> Well you got a lot of good advice up there, but they kinda skipped
> around the issue a bit so I'll try and fill in the gaps:
>
> I asked about a particular language to learn and although what eveyone
> said above was great advice you DO still need to pick one or two to play
> with:
>
>
Do you have a particular goal, or need? Maybe you just need to deploy
small scripts to do "little dirty jobs".
People like Perl for that - but that's because they hadn't come in contact
with Python, or perhaps Ruby.
Maybe you want to develop for the web. Consider Java, because of all the
bells and whistles.And it's a good general programming language, too.
Or, you want a language for operating system design: it would have
to be C/C++, because there's a huge legacy of code.
IM very, very HO, in my newbie experience (not a CS student, a medical
student with interest in bioinformatics/statistics/computer
algebra/medical informatics), Common Lisp will blow your mind. If you
study data structures in C (say, from Tannenbaum's book), for instance,
half of the time is all about what to do with the f*****g pointers. With
lisp, you can focus on the _problem_ and not so much on details that you
have to move out of your way to get the solution right.
However, be warned: it's not easy to make sense of the information that's
out there,
and it's so different, chances are you won't be able to ask some guy at
your local LUG to give you a hand on your problem. And lispers don't make
it easy for newbies, too: there aren't very many of the HOWTOs and stuff
to get you started. Apparently, they gather all their info from just
reading the code, which you don't know how to do yet And the specs:-)) We
_will_ get there, us newbies! :-) If you thought open source programming
was hard, finding out some things in lisp is cryptic or just a huge
learning curve, a huge amount of reading. And some things are just weird
:-)) Like "ring buffers" for string substitution. Turns out, you learn
what a ring buffer is, even though deep in your heart you know that there
would be an eeasier way in some scripting language. But, perhaps you end
up wanting to go and read Knuth, and that already indicates you're a
better programmer than the opens ource kid who just throws some code up on
the wall and see if it sticks...
So, for me, there's no question. When I first set out to learn an
"industrial" language (not a scripting language like Python, which BTW is
great) I did a lot of reading on the net and lurked at newsgroups. I came
to realize that there's a very good rationale for using Common Lisp, if
you just _listen_ to what the guys here at c.l.l. have to say (they're
pretty knowledgeable on other computer languages, too). And then good and
read some more. Also, you start to think deeper about programming in
general because there are a lot of things in lisp that aren't even on the
radar screen on other programming languages.
Cheers
Henry
_______________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
·············@yahoo.com (Scott) wrote:
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
>
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
>
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
> not too sure if he is qualified to give this type of advice...
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either. So I thought about this A LOT,
> and I'm wonderingif I could ask for advice on the internet.
>
> Thanks in advance for your time..
How about another book suggestion:
"The Pragmatic Programmer" by A. Hunt and D. Thomas.
As far as what language to learn: Is there something that you want to do
that Scheme can't do? If so, then find out what language *does* do what
you want and learn it.
If you want to switch languages because you don't like Scheme, then
identify what you don't like about it and find a language that doesn't
do it.
Otherwise, you might as well stick with Scheme until you know more.
Hi!
I recommend starting with C, not because its the king of languages or
because I love it etc... just because most of todays languages use C syntax
and concepts. if you know C well learning many other languages like Java,
PHP, ... would be much easier.
Then move on to C++ and learn the concepts of object oriented programming...
my recommended source is Bruce Eckel's "thinking in C++" which is available
as PDF:
http://www.mindview.net is his url.
I also recommend not moving to C++ before learning C well, in other words
don't move to Object Oriented Programming before you feel you are good at
Structural Programming, I know many people here may object but this is my
opinion.
after this I recommend 3 steps, which are a little boring but I think
without knowing them one can't name himself a programmer:
1- Learn how a compiler works and whats acctually happening in CPU, Ram,
etc... when your program is running. learn some assembly programming just to
become familliar with it and try to write some simple assembly programs.
2- Learn general programming concepts and algorithms.
3- Learn some methodologies and analysis and design strategies.
let me add that me too learned programming just because I loved programming
and no other reason. I'm also a self-taught programmer, as I remember the
only language I learned with a teacher was C when I was 12 :)
Arash Dejkam
http://portfolio.dejkam.com
"Scott" <·············@yahoo.com> wrote in message
·································@posting.google.com...
> Hello!
>
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
>
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
>
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
> not too sure if he is qualified to give this type of advice...
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either. So I thought about this A LOT,
> and I'm wonderingif I could ask for advice on the internet.
>
> Thanks in advance for your time...
--
**If at first you don't succeed - destroy any evidence that you tried!**
"Arash Dejkam" <······@softhome.net> wrote in message
···················@ID-97842.news.dfncis.de...
> Hi!
>
> I recommend starting with C, not because its the king of languages or
> because I love it etc... just because most of todays languages use C
syntax
> and concepts. if you know C well learning many other languages like Java,
> PHP, ... would be much easier.
> Then move on to C++ and learn the concepts of object oriented
programming...
> my recommended source is Bruce Eckel's "thinking in C++" which is
available
> as PDF:
> http://www.mindview.net is his url.
> I also recommend not moving to C++ before learning C well, in other words
> don't move to Object Oriented Programming before you feel you are good at
> Structural Programming, I know many people here may object but this is my
> opinion.
> after this I recommend 3 steps, which are a little boring but I think
> without knowing them one can't name himself a programmer:
> 1- Learn how a compiler works and whats acctually happening in CPU, Ram,
> etc... when your program is running. learn some assembly programming just
to
> become familliar with it and try to write some simple assembly programs.
> 2- Learn general programming concepts and algorithms.
> 3- Learn some methodologies and analysis and design strategies.
>
> let me add that me too learned programming just because I loved
programming
> and no other reason. I'm also a self-taught programmer, as I remember the
> only language I learned with a teacher was C when I was 12 :)
>
> Arash Dejkam
> http://portfolio.dejkam.com
>
I'm not convinced - as you say, C++ is the king of all languages and it is a
great language at that, but I dont think someone just starting programming
should be needlessly exposed to the really advanced parts of the subject
unecessarily. Java would let him build experience and confidence as it would
keep a lot of the more triky elements at bay whilst he concentrate on
fundementals
Simon
"Simon Harvey" <········@homtaild.com> wrote in message
··························@wards...
>
>
> --
> **If at first you don't succeed - destroy any evidence that you tried!**
> "Arash Dejkam" <······@softhome.net> wrote in message
> ···················@ID-97842.news.dfncis.de...
> > Hi!
> >
> > I recommend starting with C, not because its the king of languages or
> > because I love it etc... just because most of todays languages use C
> syntax
> > and concepts. if you know C well learning many other languages like
Java,
> > PHP, ... would be much easier.
> > Then move on to C++ and learn the concepts of object oriented
> programming...
> > my recommended source is Bruce Eckel's "thinking in C++" which is
> available
> > as PDF:
> > http://www.mindview.net is his url.
> > I also recommend not moving to C++ before learning C well, in other
words
> > don't move to Object Oriented Programming before you feel you are good
at
> > Structural Programming, I know many people here may object but this is
my
> > opinion.
> > after this I recommend 3 steps, which are a little boring but I think
> > without knowing them one can't name himself a programmer:
> > 1- Learn how a compiler works and whats acctually happening in CPU, Ram,
> > etc... when your program is running. learn some assembly programming
just
> to
> > become familliar with it and try to write some simple assembly programs.
> > 2- Learn general programming concepts and algorithms.
> > 3- Learn some methodologies and analysis and design strategies.
> >
> > let me add that me too learned programming just because I loved
> programming
> > and no other reason. I'm also a self-taught programmer, as I remember
the
> > only language I learned with a teacher was C when I was 12 :)
> >
> > Arash Dejkam
> > http://portfolio.dejkam.com
> >
>
>
> I'm not convinced - as you say, C++ is the king of all languages and it is
a
> great language at that, but I dont think someone just starting programming
> should be needlessly exposed to the really advanced parts of the subject
> unecessarily. Java would let him build experience and confidence as it
would
> keep a lot of the more triky elements at bay whilst he concentrate on
> fundementals
>
> Simon
>
Dear Simon,
First of all I didn't say C++ is the king of languages or anything like
that, read my text carefully. I even currently like Java more than C++
myself.
secondly I'm not rigid about my opinion, maybe I'm a little biased or my
opinion is becuase when I learned C and C++ there was no Java :)
Why I recommend starting with C is to feel the underlying events happening
in a computer when a program is running and to know how stupid a computer is
!
I think if one start with Java may assume that computer is a very
intelligent thing that even understands some humanly concepts like Objects,
Classes, Inheritance,etc...
anyway, I have never been a programming teacher so I may not be good person
to talk about this.
this is my own opinion extracted from my own learning experiences.
Arash
> "I recommend starting with C, not because its the king of languages"
Apologies - I took this as the expression of an opinion. The language you
used is ambiguous, not that it matters. I still happen to disagree with you
though:
>I think if one start with Java may assume that computer is a very
>intelligent thing that even understands some humanly concepts like Objects,
>Classes, Inheritance,etc...
I think if you are thinking about programming computers, you are probably
quite aware that it isn't really smart at all! - in fact just a number
cruncher!
>this is my own opinion extracted from my own learning experiences
Mine Also
Simon Harvey wrote:
>>"I recommend starting with C, not because its the king of languages"
>
> Apologies - I took this as the expression of an opinion. The language you
> used is ambiguous, not that it matters. I still happen to disagree with you
> though:
I don't think his language is ambiguous.
I think you 'exraction process' is 'ambiguous'.
Could you please show me, how you extract the essence "C++ its the king
of all languages" out of the above text?
If you fail, try it again with the following, more complete text, which
i've copied for your convenience:
>> Hi!
>>
>> I recommend starting with C, not because its the king of languages or
>> because I love it etc... just because most of todays languages use C syntax
>> and concepts. if you know C well learning many other languages like Java,
>> PHP, ... would be much easier.
>> Then move on to C++ and learn the concepts of object oriented programming...
I'm very curious.
>>I think if one start with Java may assume that computer is a very
>>intelligent thing that even understands some humanly concepts like Objects,
>>Classes, Inheritance,etc...
>
> I think if you are thinking about programming computers, you are probably
> quite aware that it isn't really smart at all! - in fact just a number
> cruncher!
as you said: probably.
probably no.
probably yes.
If the OP is aware of the non-smartness, he will reject the suggestion.
If the OP is not aware of the non-smartness, he will take the suggestion
into account.
>
>>this is my own opinion extracted from my own learning experiences
>
> Mine Also
The process of extraction.
Precision.
According to ilias <·······@pontos.net>:
> Simon Harvey wrote:
> >>"I recommend starting with C, not because its the king of languages"
> >
> > Apologies - I took this as the expression of an opinion. The language you
> > used is ambiguous, not that it matters. I still happen to disagree with you
> > though:
>
> I don't think his language is ambiguous.
>
> I think you 'exraction process' is 'ambiguous'.
>
> Could you please show me, how you extract the essence "C++ its the king
> of all languages" out of the above text?
Easy: "s/I recommend starting with C, not because it/C++ i/"
Slightly more, but still not entirely, serious:
"I'll stay home, not because it rains, but because I'm tired" means, "It
is, in fact, raining, but that is not the reason I stay home, but...".
Similarly, the sentence above translates to "C++ is the king of languages,
but that's not the reason I recommend it, but...".
> If you fail, try it again with the following, more complete text, which
> i've copied for your convenience:
No need. The author of the sentence (I have lost attributions) slipped
and implied something he didin't mean to say. That was pointed out. No
one has claimed that he actually thinks C (or C++) is the king of
languages.
[rest snipped]
Anno
Anno Siegel <········@lublin.zrz.tu-berlin.de> scribbled the following
on comp.lang.java.programmer:
> According to ilias <·······@pontos.net>:
>> Simon Harvey wrote:
>> >>"I recommend starting with C, not because its the king of languages"
>> >
>> > Apologies - I took this as the expression of an opinion. The language you
>> > used is ambiguous, not that it matters. I still happen to disagree with you
>> > though:
>>
>> I don't think his language is ambiguous.
>>
>> I think you 'exraction process' is 'ambiguous'.
>>
>> Could you please show me, how you extract the essence "C++ its the king
>> of all languages" out of the above text?
> Easy: "s/I recommend starting with C, not because it/C++ i/"
> Slightly more, but still not entirely, serious:
> "I'll stay home, not because it rains, but because I'm tired" means, "It
> is, in fact, raining, but that is not the reason I stay home, but...".
> Similarly, the sentence above translates to "C++ is the king of languages,
> but that's not the reason I recommend it, but...".
And how does it magically change C into C++?
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Insanity is to be shared."
- Tailgunner
Also sprach Joona I Palaste:
> Anno Siegel <········@lublin.zrz.tu-berlin.de> scribbled the following
> on comp.lang.java.programmer:
>> Easy: "s/I recommend starting with C, not because it/C++ i/"
[...]
> And how does it magically change C into C++?
Well, should be obvious:
($_ = <<EOM) =~ s/I recommend starting with C, not because it/C++ i/;
I recommend starting with C, not because its the king of languages
EOM
print;
__END__
C++ is the king of languages
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
Tassilo v. Parseval <················@post.rwth-aachen.de> scribbled the following
on comp.lang.java.programmer:
> Also sprach Joona I Palaste:
>> Anno Siegel <········@lublin.zrz.tu-berlin.de> scribbled the following
>> on comp.lang.java.programmer:
>>> Easy: "s/I recommend starting with C, not because it/C++ i/"
> [...]
>> And how does it magically change C into C++?
> Well, should be obvious:
> ($_ = <<EOM) =~ s/I recommend starting with C, not because it/C++ i/;
> I recommend starting with C, not because its the king of languages
> EOM
> print;
> __END__
> C++ is the king of languages
I did not mean the ed (sed?) command above, I meant how the previous
poster can infer "C++ is the king of languages" from "I recommend
starting with C, not because it's the king of languages".
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Shh! The maestro is decomposing!"
- Gary Larson
According to Joona I Palaste <·······@cc.helsinki.fi>:
> Anno Siegel <········@lublin.zrz.tu-berlin.de> scribbled the following
> on comp.lang.java.programmer:
> > According to ilias <·······@pontos.net>:
> >> Simon Harvey wrote:
> >> >>"I recommend starting with C, not because its the king of languages"
> >> >
> >> > Apologies - I took this as the expression of an opinion. The language you
> >> > used is ambiguous, not that it matters. I still happen to disagree with you
> >> > though:
> >>
> >> I don't think his language is ambiguous.
> >>
> >> I think you 'exraction process' is 'ambiguous'.
> >>
> >> Could you please show me, how you extract the essence "C++ its the king
> >> of all languages" out of the above text?
>
> > Easy: "s/I recommend starting with C, not because it/C++ i/"
>
> > Slightly more, but still not entirely, serious:
>
> > "I'll stay home, not because it rains, but because I'm tired" means, "It
> > is, in fact, raining, but that is not the reason I stay home, but...".
> > Similarly, the sentence above translates to "C++ is the king of languages,
> > but that's not the reason I recommend it, but...".
>
> And how does it magically change C into C++?
It doesn't. I ignored the C/C++ mixup, considering it a typo, except
in the facetios regex, where ignoring it would have spoiled the effect.
The structure of the sentence, and the conclusions that can be drawn,
don't change whether the OP actually meant C or C++.
Anno
>Could you please show me, how you extract the essence "C++ its the king
>of all languages" out of the above text?
"I recommend starting with C, not because its the king of languages"
- If you cant see why the words
"not because its the King of all languages"
might be read as an expression of opinion, then I don't know how to prove to
you that it does. Perhaps another example:
"I think you should like the band Metallica, not because they are talented,
articlate, witty, funky, passionate and did I say talented? You should like
them becuase they like brussell sprouts!" - In my opinion you could be
forgiven if you surmise that there is a *good chance* that I believe
Metallica to be talented, articlate, witty......
Do you get my point?
Anyway, I cant believe I'm actually discussing the finer points of English
language. I didnt even like English at school!!
Take Care mate
Simon
--
**If at first you don't succeed - destroy any evidence that you tried!**
Simon Harvey wrote:
>>Could you please show me, how you extract the essence "C++ its the king
>>of all languages" out of the above text?
>
> "I recommend starting with C, not because its the king of languages"
>
> - If you cant see why the words
>
> "not because its the King of all languages"
even if:
he referenced C. Not C++.
C != C++
> might be read as an expression of opinion, then I don't know how to prove to
> you that it does. Perhaps another example:
>
> "I think you should like the band Metallica, not because they are talented,
i like them.
especially
"Nothing else Matters"
Arash Dejkam wrote:
> Hi!
>
> I recommend starting with C, not because its the king of languages or
> because I love it etc... just because most of todays languages use C syntax
> and concepts. if you know C well learning many other languages like Java,
> PHP, ... would be much easier.
> Then move on to C++ and learn the concepts of object oriented programming...
> my recommended source is Bruce Eckel's "thinking in C++" which is available
> as PDF:
> http://www.mindview.net is his url.
> I also recommend not moving to C++ before learning C well, in other words
> don't move to Object Oriented Programming before you feel you are good at
> Structural Programming, I know many people here may object but this is my
> opinion.
I object. I would, in fact, say that what you are saying here
has very little basis in reality. And isn't OO structural programming...
In any event, both OO and procedural programming are under the
imperative paradigm and are very similar to eachother. An OO language
just offers a few more builtin abstractions to play with.
Learning C++ on the basis of the C you allready know is more often than
not a very bad idea. (most properly written C programs invoke undefined
behaviour when compiled as a C++ program)
The book you are recommending is good though.
> after this I recommend 3 steps, which are a little boring but I think
> without knowing them one can't name himself a programmer:
> 1- Learn how a compiler works and whats acctually happening in CPU, Ram,
> etc... when your program is running. learn some assembly programming just to
> become familliar with it and try to write some simple assembly programs.
Not boring.
> 2- Learn general programming concepts and algorithms.
Not boring.
> 3- Learn some methodologies and analysis and design strategies.
Maybe a bit boring to learn, but not boring to know.
Remember this. It can make boring stuff interesting if you
manage to put yourself in the right mindset.
--
Thomas Stegen
"Thomas Stegen" <·······@cis.strath.ac.uk> wrote in message
·····················@cis.strath.ac.uk...
> Arash Dejkam wrote:
> > Hi!
> >
> > I recommend starting with C, not because its the king of languages or
> > because I love it etc... just because most of todays languages use C
syntax
> > and concepts. if you know C well learning many other languages like
Java,
> > PHP, ... would be much easier.
> > Then move on to C++ and learn the concepts of object oriented
programming...
> > my recommended source is Bruce Eckel's "thinking in C++" which is
available
> > as PDF:
> > http://www.mindview.net is his url.
> > I also recommend not moving to C++ before learning C well, in other
words
> > don't move to Object Oriented Programming before you feel you are good
at
> > Structural Programming, I know many people here may object but this is
my
> > opinion.
>
> I object. I would, in fact, say that what you are saying here
> has very little basis in reality. And isn't OO structural programming...
> In any event, both OO and procedural programming are under the
> imperative paradigm and are very similar to eachother. An OO language
> just offers a few more builtin abstractions to play with.
>
excuse me, I meant "procedural programming", I used "structural" word
mistakenly.
>
> Learning C++ on the basis of the C you allready know is more often than
> not a very bad idea. (most properly written C programs invoke undefined
> behaviour when compiled as a C++ program)
>
> The book you are recommending is good though.
>
> > after this I recommend 3 steps, which are a little boring but I think
> > without knowing them one can't name himself a programmer:
> > 1- Learn how a compiler works and whats acctually happening in CPU, Ram,
> > etc... when your program is running. learn some assembly programming
just to
> > become familliar with it and try to write some simple assembly programs.
>
> Not boring.
>
> > 2- Learn general programming concepts and algorithms.
>
> Not boring.
>
> > 3- Learn some methodologies and analysis and design strategies.
>
> Maybe a bit boring to learn, but not boring to know.
>
> Remember this. It can make boring stuff interesting if you
> manage to put yourself in the right mindset.
>
>
> --
> Thomas Stegen
>
I didn't say these three steps were boring for ME, I loved them when I was
learning them.
I meant it MAY be boring for scott who asked the question.
Arash
"Scott" <·············@yahoo.com> wrote in message
·································@posting.google.com...
> I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
As a reductionist, I recommend PDP-11 assembly language. It's elegant, easy
to pick up, and once you understand the fundamentals of how computers work
you will have a better idea of what all other languages are actually doing.
After that: Smalltalk.
--
**If at first you don't succeed - destroy any evidence that you tried!**
"A Bag Of Memes" <·@b.c> wrote in message
······························@twister.austin.rr.com...
>
> "Scott" <·············@yahoo.com> wrote in message
> ·································@posting.google.com...
> > I'm
> > thinking of learning a new programming language, but I do not know
> > which. Basically, I do not particularly care about the details, such
> > as if a language is windows-only. What I do care about is learning
> > something new.
>
> As a reductionist, I recommend PDP-11 assembly language. It's elegant,
easy
> to pick up, and once you understand the fundamentals of how computers work
> you will have a better idea of what all other languages are actually
doing.
>
> After that: Smalltalk.
>
>
>
Holy s$t - you cant be serious right? Where did you pick up form the OP that
he wanted to learn assembly language!
I really love learning computing and all sorts of programming language but I
dram the line at assembly. I'm grateful that some people like it though!!
Kind regards
Simon
In comp.lang.lisp, Simon Harvey <········@homtaild.com> writes:
> Holy s$t - you cant be serious right? Where did you pick up form the OP
> that he wanted to learn assembly language! I really love learning
> computing and all sorts of programming language but I dram the line at
> assembly. I'm grateful that some people like it though!!
I think it's a useful learning exercise for someone planning to do a lot
of programming to learn an assembly language at some point and write some
simple routines in it. I'm not saying that you should use it for anything
significant, but it's valuable to know how the processor actually executes
one's code in the end (even if you can and should ignore that knowledge
most of the time).
There are still occasional applications that can be helped by having a
touch of assembly language in a critical point, or cases where one needs
to examine the assembly language output of the compiler to figure out why
it's mis-optimizing something critical, if you do low-level programming.
It can also drill into your head some low-level concepts like how the
processor stack works and what a pointer *really* is.
And even if you're planning on living the rest of your life in a
high-level programming language that strongly discourages ever thinking
about such things, it can at least give you new-found appreciation for
just how much work that programming language is saving you. :)
I've found it useful in the same way that I found useful the experience of
implementing a file system when I took a class in operating systems. I
likely won't ever work on a file system again, but I now really
*understand* (for example) what an inode is, which has helped me a lot in
understanding, troubleshooting, and drawing conclusions about file systems
and file system behavior in areas even unrelated to programming.
--
Russ Allbery (···@stanford.edu) <http://www.eyrie.org/~eagle/>
On Sep 15, Russ Allbery inscribed on the eternal scroll:
> I think it's a useful learning exercise for someone planning to do a lot
> of programming to learn an assembly language at some point and write some
> simple routines in it.
I don't want to make a big thing out of this, but...
I've been involved, at various times, with the lowest levels of
programming, i.e writing microcode below the normal assembler level,
as well as writing assembler code per se. On the whole, I would be
inclined to say that those experiences make me a worse programmer of a
high level language, since I find myself worrying quite
inappropriately about bit-level optimisation when I _ought_ to be
worrying about proper selection of algorithms and such.
Back in the Fortran-IV era and later, it was usually the case that,
for the most part, the compiler could produce better assembler code
than any of those around me who claimed to be writing their routines
in assembler for "efficiency". Just occasionally, one could get
better results by having the compiler print-out its assembler code
listing and then hand-optimising that. But only occasionally, and the
returns were rather small. On a number of occasions, taking out
instructions actually made the program slower (due to execution
pipelining and/or memory bank access interleaving being disrupted),
and it was by no means a rarity for an expert to make a program faster
by inserting NOP instructions at strategic places. But the later
optimizing compilers _knew_ how to do that anyway, and experts of that
calibre had more important things to do than save a tiny fraction of
the overall execution time of an individual piece of software.
> I'm not saying that you should use it for anything
> significant, but it's valuable to know how the processor actually executes
> one's code in the end (even if you can and should ignore that knowledge
> most of the time).
I think we're saying the same thing, but with somewhat different
emphasis...
cheers
·······@mail.cern.ch (Alan J. Flavell) wrote on 15.09.02 in <·······································@lxplus071.cern.ch>:
> I've been involved, at various times, with the lowest levels of
> programming, i.e writing microcode below the normal assembler level,
> as well as writing assembler code per se. On the whole, I would be
> inclined to say that those experiences make me a worse programmer of a
> high level language, since I find myself worrying quite
> inappropriately about bit-level optimisation when I _ought_ to be
> worrying about proper selection of algorithms and such.
Doesn't seem to work that way for me. I've searched for better algorithms
in practically every level of language, from assembly up to at least SQL
("how do I convince this SQL engine to do this without creating and
scanning a full join?") - I don't remember if I did enough Prolog to do
the same there.
> by inserting NOP instructions at strategic places. But the later
> optimizing compilers _knew_ how to do that anyway, and experts of that
> calibre had more important things to do than save a tiny fraction of
> the overall execution time of an individual piece of software.
Which is why the general optimization rule is, *first* you *measure* where
the program spends the most time, *then* you optimize *that point* - or
(often better) you change your algorithm so you don't need to do that
particular bit so often.
Because it isn't particularly rare that the hot spots are in a completely
different place than you had assumed.
I think there's a tale about some early (Fortran?) compiler which, it
turned out, spent most of its time fairly ineffectively reading the source
code. Not analyzing it, or compiling it, just plain reading it. Speeding
up that compiler turned out to be fairly easy, *once the problem was*
*recognized*.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (···@stanford.edu)
···@stanford.edu (Russ Allbery) wrote on 15.09.02 in <··············@windlord.stanford.edu>:
> In comp.lang.lisp, Simon Harvey <········@homtaild.com> writes:
>
> > Holy s$t - you cant be serious right? Where did you pick up form the OP
> > that he wanted to learn assembly language! I really love learning
> > computing and all sorts of programming language but I dram the line at
> > assembly. I'm grateful that some people like it though!!
>
> I think it's a useful learning exercise for someone planning to do a lot
> of programming to learn an assembly language at some point and write some
> simple routines in it. I'm not saying that you should use it for anything
> significant, but it's valuable to know how the processor actually executes
> one's code in the end (even if you can and should ignore that knowledge
> most of the time).
Personally, I believe that every good programmer needs to know at least
one assembly language, *and* needs to have looked what sort of (assembly
or machine) language at least one compiler actually generates from the
high-level source code.
More than once I've seen people who didn't understand why their program
was extremely slow, which would have been quite obvious for anyone
understanding the above. (Such as, no, copying a string is not as fast as
copying an integer.)
Doesn't mean you need to actually use assembler daily for anything, but
that knowing these things makes for better understanding what you do when
uusing a high-level language.
In the same vein, when using a declarative language, it can help having
seen what sort of imperative code is used to implement such a language.
Or in general, when using a compiled or interpreted language, having seen
source for a compiler or interpreter.
(Or, if you want, when driving a car, understanding at least some of the
stuff an auto mechanic does.)
> I've found it useful in the same way that I found useful the experience of
> implementing a file system when I took a class in operating systems. I
> likely won't ever work on a file system again, but I now really
> *understand* (for example) what an inode is, which has helped me a lot in
> understanding, troubleshooting, and drawing conclusions about file systems
> and file system behavior in areas even unrelated to programming.
Another great example.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (···@stanford.edu)
"Simon Harvey" <········@homtaild.com> wrote in message
··························@stones...
>
> Holy s$t - you cant be serious right?
Yes I can.
> Where did you pick up form the OP that
> he wanted to learn assembly language!
I didn't. He was asking how to become a better programmer. My experience
has been that programmers who know assembly have an advantage over those who
do not.
Quoth "Simon Harvey" <········@homtaild.com>:
> Holy s$t - you cant be serious right? Where did you pick up form the OP that
> he wanted to learn assembly language!
> I really love learning computing and all sorts of programming language but I
> dram the line at assembly. I'm grateful that some people like it though!!
People keep writing new Virtual Machines for /various/ languages, so
having some knowledge about this is something that any competent
programmer should have.
(Recent VMs: Everyone knows of JVMs, but recent new instances include
NET and the Perl 6 "Parrot" VM.)
If you have /some/ clue about dealing with bytecode, you have a good
understanding of how to attack /lots/ of related sorts of problems.
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/bytecode.html
Sleep is a poor subsititute for caffeine. -Pat Dughi
"Simon Harvey" <········@homtaild.com> wrote in message
··························@stones...
>
>
> --
> **If at first you don't succeed - destroy any evidence that you tried!**
> "A Bag Of Memes" <·@b.c> wrote in message
> ······························@twister.austin.rr.com...
> >
> > "Scott" <·············@yahoo.com> wrote in message
> > ·································@posting.google.com...
> > > I'm
> > > thinking of learning a new programming language, but I do not know
> > > which. Basically, I do not particularly care about the details, such
> > > as if a language is windows-only. What I do care about is learning
> > > something new.
> >
> > As a reductionist, I recommend PDP-11 assembly language. It's elegant,
> easy
> > to pick up, and once you understand the fundamentals of how computers
work
> > you will have a better idea of what all other languages are actually
> doing.
> >
> > After that: Smalltalk.
> >
> >
> >
>
>
> Holy s$t - you cant be serious right? Where did you pick up form the OP
that
> he wanted to learn assembly language!
> I really love learning computing and all sorts of programming language but
I
> dram the line at assembly. I'm grateful that some people like it though!!
>
> Kind regards
> Simon
>
>
You know why I learned assembly ??? because when I used to write C++
programs without knowing assembly and the program had a bug and the computer
was showing me a bunch of assembly code for debugging but I didn't know
anything about it, I thought what is this language that this stupid computer
understands and I don't. so I felt disrespect and learned it :)
just joking.
Assembly (actually machine code) is the only language that computer
understands directly, so knowing this is essential.
I don't mean every programmer must learn assembly (human readable version of
machine code), but knowing it opens a new view to the programmer. I think
learning it is a revolution in the live of a programmer! at least it was for
me :)
Arash
All the above comments are very fair points. I think he should maybe come
back to it though once he has his feet planted in a decent high level
language
·············@yahoo.com (Scott) wrote in message news:<····························@posting.google.com>...
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
I've used C++ since the 1980's, and I prefer other languages, such as
Smalltalk and Common Lisp. My personal preference is Common Lisp, but
it takes a long time for most programmers to learn it fluently. What
I like about it is that I can program much faster in it than in other
languages. In the future, as computer hardware gets cheaper and more
powerful, the value of being able to write sophisticated programs fast
will increase more and more. Learning to program is a lifelong
effort, and you never quite reach a plateau where you can consider
most of your learning behind you. Considering how much of an
investment of my time that is, I can't see wasting it anymore on
anything less powerful than Common Lisp. I'm still looking for
something even better, but have not found it yet. Meanwhile, the more
I use it, the better I get at it, and the bigger my personal software
library in it grows, so I can do more and more work with less and less
effort.
On the other hand, what's best for a novice? I think it depends on
your personality and talent more than anything else. Do you need
something that will keep you constantly motivated, or are you
self-motivated to learn more faster regardless of immediate feedback?
Nobody but you can really know the answers to such questions. You
have to know yourself, and seek out something that fits you like a
glove. Other people's advice is based on their own experience in the
context of their own talents and motivations. And for those who need
constant positive feedback, there are different kinds of feedback,
fitting different personalities different ways. For example, do you
need to build a GUI and see it work while you add your program's
features while learning how to use your programming language? Or do
you prefer to use a workspace paradigm where you can test small
snippets of code easily and see the results of those immediately
without putting them in the context of a larger program? And what
about money? Some people can only learn on the job, because their
personality won't let them spend time doing something they aren't
getting paid for. And some just need the constant feeling that the
work they're doing will soon result in more money for them, such as
when they're working towards an advanced degree and are getting good
grades constantly, and knowing they will be able to get a good job as
a result. This is the kind of stuff you have to know about yourself,
as well as a lot of other aspects, such as how well you learn at
different levels of abstraction, etc.
··········@mailandnews.com (Software Scavenger) wrote in message news:<····························@posting.google.com>...
> ·············@yahoo.com (Scott) wrote in message news:<····························@posting.google.com>...
>
> > So, one of my friends tells me that I should learn C++, because "it's
> > the best". But, seriously, he doesn't know anything but C++, so I'm
>
> I've used C++ since the 1980's, and I prefer other languages, such as
> Smalltalk and Common Lisp. My personal preference is Common Lisp, but
> it takes a long time for most programmers to learn it fluently. What
> I like about it is that I can program much faster in it than in other
Greetings, Scavenger.
With all due respect to another veteran, I have to disagree with you
regarding Lisp. While you're not blatantly recommending it to newbies,
you are being very suggestive in your tone. Time is money, and time
spent learning Lisp could be better spent more productively elsewhere.
And this is coming from someone who has worked with Lisp 2 through
Common Lisp for years in several teams and solo. Besides, he already
knows some Scheme, which diminishes the educational value of Lisp for
him even further. In any event, what was the largest Lisp team that
you have ever worked in? What is the largest Lisp team that you have
ever heard of that actually managed to deploy their product
successfully? Orbitz is more of an exception than a rule. Most large
team efforts in Lisp were failures, and that's a fact. IIRC the
notorious "Mythical Man-Month" might have even mentioned this curious
fact, although I may be confusing it with another book.
> On the other hand, what's best for a novice? I think it depends on
> your personality and talent more than anything else. Do you need
> something that will keep you constantly motivated, or are you
> self-motivated to learn more faster regardless of immediate feedback?
> Nobody but you can really know the answers to such questions. You
> have to know yourself, and seek out something that fits you like a
> glove. Other people's advice is based on their own experience in the
> context of their own talents and motivations. And for those who need
> constant positive feedback, there are different kinds of feedback,
> fitting different personalities different ways. For example, do you
> need to build a GUI and see it work while you add your program's
> features while learning how to use your programming language? Or do
> you prefer to use a workspace paradigm where you can test small
> snippets of code easily and see the results of those immediately
> without putting them in the context of a larger program? And what
> about money? Some people can only learn on the job, because their
> personality won't let them spend time doing something they aren't
> getting paid for. And some just need the constant feeling that the
> work they're doing will soon result in more money for them, such as
> when they're working towards an advanced degree and are getting good
> grades constantly, and knowing they will be able to get a good job as
> a result. This is the kind of stuff you have to know about yourself,
> as well as a lot of other aspects, such as how well you learn at
> different levels of abstraction, etc.
From: Tim Bradshaw
Subject: Re: becoming a better programmer
Date:
Message-ID: <ey3ofayxpdn.fsf@cley.com>
* alec2001 wrote:
> Most large team efforts in Lisp were failures, and that's a
> fact. IIRC the notorious "Mythical Man-Month" might have even
> mentioned this curious fact, although I may be confusing it with
> another book.
Most large-team software efforts are failures, full stop.
The book you are referring to is probably `software runaways' by
someone-or-other which is a collection of papers describing various
software project catastrophes. It has a chapter the failure of
a project at MCC and blaming it on Lisp. This is, essentially,
bullshit - there ware a lot of other problems which caused this
disaster. I suspect that many of its other papers are also bullshit
although I haven't checked up on them.
Here's a description from someone who was there (you can probably find
this by searching on google groups, although I have it in a file with
no reference, sorry).
A dozen years later, that BS paper still gets my blood boiling!
Lisp was NOT MCC's problem. Incompetent management was! The
director of the CAD group kept overriding the system architect and
made technical decisions about which he knew nothing. His constant
interference completely underminded any chance of it being a
success. As a result of his interference, each group leader went
and did their own thing, giving no consideration to the overall
goals. As an example of how disfunctional management became, I and
another engineer attended a meeting with the director and the
system architect to discuss design size problems, namely that TI
and LMI lisp machines didn't have enough address space to handle
the size of problems that MCC wanted. (Not without doing software
"overlays".) Half way thru the meeting, the director was sitting
in one corner staring out the window and the system architect was
sitting in the opposite corner staring out that window. The
director just didn't want to hear about any problems with the TIs
and LMIs. Or anything else! It become clear to me at that moment
that MCC was doomed to failure because of the internal politics
and incompetence of management.
ALthough I didn't always agree with the decisions of the system
architect (more often than not, I disagreed!), I knew that for a
large system to have any hope of success, one person had to be
responsible for the global design. Due to the director at MCC
CAD, there was no ONE person responsible for the system
design. Well, that's not quite true. The system architect WAS
responsible for the design. He just had no authority to carry it
out.
I know of no real evidence that large Lisp systems have worse problems
than large systems in any other languages. Since Lisp is a left-field
choice it's a fairly obvious candidate for blame when large software
projects screw up - better to blame the language than the
mismanagement if you want to keep your job, and, like buying IBM,
no-one ever gets sacked for choosing C++ or Java.
--tim
········@ziplip.com (Alec) wrote in message news:<···························@posting.google.com>...
> And this is coming from someone who has worked with Lisp 2 through
> Common Lisp for years in several teams and solo. Besides, he already
I've noticed from some of your postings that you seem to have
something personal against Common Lisp. Did something happen to you
which made you hate it, or maybe hate someone who was using it?
I'm not claiming it's a panacea and all programmers should start using
it. Just that I personally find it the most productive language for
the way I work, after so many years of experience with so many other
programming languages. The issues most people complain about, when
they say they don't like Common Lisp, seem like nitpicking to me.
What matters to me is how fast and how well I can program. At the end
of the day, I want to see high quality production software which
people can use and be happy with.
I had an argument like this with someone who gave a lot of reasons to
hate Common Lisp, but all of those reasons seemed silly to me.
Finally I asked him to post some of his Common Lisp code, as an
example of what he was referring to, and he didn't have any. Before I
spend any time arguing the merits of Common Lisp with you, could you
please tell me upfront whether you have any actual Common Lisp code
which we could discuss?
"Ian Lazarus" <······@nowhere.net> wrote in message
> Why try to reinvent the wheel? If you want to learn computer science, read
> the textbooks which form a computer science cirriculum.
this is true in the case of fight between Betamax and VHS, but not in this
case!
Assembly does not belong to the history, every program running on any
computer is still converted to Assembly (Machine Code) before running. and
probably will be converted in future as long as computer technology is based
on 0-1.
Arash
"Arash Dejkam" <······@softhome.net> wrote:
> Assembly does not belong to the history, every program running on any
> computer is still converted to Assembly (Machine Code) before running. and
> probably will be converted in future as long as computer technology is based
> on 0-1.
Well, that may be true, but by the same logic, every programmer should
learn about microcode, and digital circuit design, and semiconductor
physics. Where does it end? The idea is to build abstractions which
eliminate the need to know what's going on at the deeper levels.
In some ways, knowing about machine architecture can be a detriment. I
remember when I first learned C on a pdp-11, I knew the machine
architecture inside and out, and my C code showed it! At the time, I
thought I was being clever and efficient, when in reality I'm sure I was
just writing unportable code.
Then I moved to the Vax and 68k-based Suns, where I was vaguely aware of
how the instruction set worked. Eventually I moved to machines
(PowerPC, Sparc, Alpha) where I honestly have no clue what the
architecture, let alone the assembly language, looks like. It's just
not important.
"Roy Smith" <···@panix.com> wrote in message
······························@reader1.panix.com...
> "Arash Dejkam" <······@softhome.net> wrote:
> > Assembly does not belong to the history, every program running on any
> > computer is still converted to Assembly (Machine Code) before running.
and
> > probably will be converted in future as long as computer technology is
based
> > on 0-1.
>
> Well, that may be true, but by the same logic, every programmer should
> learn about microcode, and digital circuit design, and semiconductor
> physics. Where does it end?
>
> The idea is to build abstractions which
> eliminate the need to know what's going on at the deeper levels.
>
I'm not against abstraction, how can one be against it. but I think we
cannot have "pure abstraction", thats possible only if we program for a
"pure abstract machine" with infinite resources. but such machine does not
exist! our resources (ram,speed,...) are finite. so we should be concerned
about it! this is why I think a programmer must be FAMILIAR with Assembly,
machine code even digital circuits as you mentioned. also I don't mean
knowing about these is necessary for writing a good and efficient program
but knowing them is an ADVANTAGE for the programmer.
Also I have a personal feeling. after I have learned assembly and about Cpu,
ram... and how they work, even when I'm programming in a High Level language
like java in the background of my mind I see the assembly code, cpu
instructions,... needed for each line which may not be accurate but somehow
gives me clue about how to write a better program. this have had practical
increase in quality of my programs, I can't justify what I'm saying because
its just a personal feeling. maybe it just gives me more self-confidence!, I
don't know, but it is good, I don't want to go back to the time when I
didn't know assembly :)
Arash
> Then I moved to the Vax and 68k-based Suns, where I was vaguely
> aware of how the instruction set worked. Eventually I moved to
> machines (PowerPC, Sparc, Alpha) where I honestly have no clue what
> the architecture, let alone the assembly language, looks like. It's
> just not important.
Actually I think it's important to be able to move up and down the
ladder of abstraction. Implement your ideas as abstractly as possible
but not more so. :-)
You should be able to take on lower-level concerns as necessary.
Perhaps you find your program running more slowly than you expect.
You should be able to look at a disassembly and see what it's doing in
case the problem is that you've tickled some inefficiency in your
compiler.
And there's nothing like a good assembly language hack....like the
time I patched a terminal driver on a Honeywell DPS-6 so some guys
could do print-screens on dumb terminals they were using to replace a
batch of unreliable microcomputers. I walked down to talk to them and
saw them using the dumb terminals. I said, `Notice any difference?'
`Uh, no, not really.' I went away happy.
--
Fred Gilham ······@csl.sri.com
Behold, how good and pleasant it is when brothers dwell in unity. It
is like the precious oil upon the head, running down upon the beard,
upon the beard of Aaron, running down on the collar of his robes. It
is like the dew of Hermon, which falls on the mountains of Zion. For
there the LORD has commanded the blessing, life for evermore. -Ps 133
On Sep 16, Arash Dejkam inscribed on the eternal scroll:
> every program running on any computer is still converted to
> Assembly (Machine Code) before running.
Really? I suppose that's a question of definition.
We were already playing with an interpreted "bytecode"[1] in the
1960's (Zebra Simple Code, in my case - a language which itself had an
interesting history ;-).
Virtual machines have been "old hat" for quite some time now. It's
just another way of implementing layers of abstraction, after all.
Zebra "Normal code" was more fun though (programmed with a "railway
sidings" diagram, and in effect what we'd now probably call a
microcode).
Why do I get this strange feeling that each new wave of newbies has to
reinvent the past? Oh well.
[1] as it would be known nowadays.
> Virtual machines have been "old hat" for quite some time now. It's
> just another way of implementing layers of abstraction, after all.
> ....
> Why do I get this strange feeling that each new wave of newbies has
> to reinvent the past? Oh well.
Yea, you can often recognize us old farts by the fact that we
sometimes `accidently' refer to Java byte code as `P-code'.
--
Fred Gilham ······@csl.sri.com || "If I thought there was anything at
all in your arguments, I should have to be not only a theist, but an
Episcopalian to boot," he said, after one interchange, reckoning that
since Episcopalianism was, in his book, that than which nothing could
be worse, this was an effective reductio ad absurdum. - J. R. Lucas
In article <··············@snapdragon.csl.sri.com>,
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
> > Virtual machines have been "old hat" for quite some time now. It's
> > just another way of implementing layers of abstraction, after all.
> > ....
> > Why do I get this strange feeling that each new wave of newbies has
> > to reinvent the past? Oh well.
>
> Yea, you can often recognize us old farts by the fact that we
> sometimes `accidently' refer to Java byte code as `P-code'.
You mis-spelled "O-code".
-- Bruce
Bruce Hoult wrote:
>
> In article <··············@snapdragon.csl.sri.com>,
> Fred Gilham <······@snapdragon.csl.sri.com> wrote:
>
> > > Virtual machines have been "old hat" for quite some time now. It's
> > > just another way of implementing layers of abstraction, after all.
> > > ....
> > > Why do I get this strange feeling that each new wave of newbies has
> > > to reinvent the past? Oh well.
> >
> > Yea, you can often recognize us old farts by the fact that we
> > sometimes `accidently' refer to Java byte code as `P-code'.
>
> You mis-spelled "O-code".
S-code, please! That's what it was called on Burroughs
small and medium systems. I worked on the S-code interpreters
for Cobol, MPL (Burroughs' answer to BCPL) and Ada back in
1982-1983. It was done because the B90 and B900 had an
instruction set that was almost impossible to compile down
to, and because the B1900 was designed with running S-code
in mind (and ran like a tortoise on valium as a result).
> -- Bruce
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Scott wrote:
> Hello!
>
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
>
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
>
> So, one of my friends tells me that I should learn C++, because "it's
> the best". But, seriously, he doesn't know anything but C++, so I'm
> not too sure if he is qualified to give this type of advice...
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either. So I thought about this A LOT,
> and I'm wonderingif I could ask for advice on the internet.
Since I see that this topic gets cold-flame, and linguistics and
philosophy I guess I add my wisdom here. I believe I have the best ever
possible advice ;-)
The best way to become a better programmer is to write many good programs.
Really! This was not meant to be a joke.
WW
White Wolf wrote:
> Scott wrote:
>
>> Hello!
>>
>> I need your advice! Last summer I took an introductory programming
>> course and learned a little bit of Scheme, even tho I didn't like it
>> too much...
>>
> Since I see that this topic gets cold-flame, and linguistics and
> philosophy I guess I add my wisdom here. I believe I have the best ever
> possible advice ;-)
>
> The best way to become a better programmer is to write many good programs.
>
> Really! This was not meant to be a joke.
>
> WW
>
Good advice. Try to get work in a team environment and try not to get
emotionally involved with your code. This will enable you to look critically at
your code rather than just feeding your ego.
--
Angelo Fraietta
PO Box 859
Hamilton NSW 2303
Home Page
http://www.users.bigpond.com/angelo_f/
There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)
Scott wrote:
> I need your advice!
Stop trying to be a better programmer. First start concentrating on being a
mediocre programmer. When you're through with that, you can graduate to
being a good programmer. Maybe at that point you'll be able to skip being
better and go directly to excellent. It all may take a few years, though.
I'd get started soon.
The fact that you can ask your question with a straight face means you still
have a long way to go. At this point, no particular language will make you
a better programmer.
Bottom line, there is no "royal road" to programming. If there was one, it
certainly would not be ensconced within any particular language. Just
start programming, reading programs as you go, learning new languages as
they come up. Come back in a few years and let us know how it's going.
faa
"Scott" <·············@yahoo.com> wrote in message
·································@posting.google.com...
> Hello!
>
> I need your advice! Last summer I took an introductory programming
> course and learned a little bit of Scheme, even tho I didn't like it
> too much...
>
> HOwever, I realized that I want to be better at this stuff and learn
> more about programming. It's fascinating. I talked to some of my
> friedns and told them that I want to be a better programmer. I'm
> thinking of learning a new programming language, but I do not know
> which. Basically, I do not particularly care about the details, such
> as if a language is windows-only. What I do care about is learning
> something new.
To learn you have to start where you are at. You already know some Scheme, so
what I would suggest is to program some non-trivial application in Scheme. My
first suggestion is to write a web-server (as the www is all the rage these
days). Give yourself a deadline, say 30 days, and get at it. If you have any
problems just ask for help in these forums (or just comp.lang.scheme). Post
your code for critical review (put a copyright on it).
The RFC for the HTTP protocol is at
http://www.w3.org/Protocols/rfc2068/rfc2068
After this brief excursion you will better understand what is needed in a
programing language and then you can pick your next application and programming
language. Repeat the procedure, continue until happy.
See you in 30 days.....
Wade (comp.lang.lisp)
On Mon, 16 Sep 2002 02:47:47 GMT, "Wade Humeniuk"
<····@nospam.nowhere> wrote:
>
>"Scott" <·············@yahoo.com> wrote in message
>·································@posting.google.com...
>> Hello!
>>
>> I need your advice! Last summer I took an introductory programming
>> course and learned a little bit of Scheme, even tho I didn't like it
>> too much...
>>
>> HOwever, I realized that I want to be better at this stuff and learn
>> more about programming. It's fascinating. I talked to some of my
>> friedns and told them that I want to be a better programmer. I'm
>> thinking of learning a new programming language, but I do not know
>> which. Basically, I do not particularly care about the details, such
>> as if a language is windows-only. What I do care about is learning
>> something new.
>
>To learn you have to start where you are at. You already know some Scheme, so
>what I would suggest is to program some non-trivial application in Scheme. My
>first suggestion is to write a web-server (as the www is all the rage these
>days). Give yourself a deadline, say 30 days, and get at it. If you have any
>problems just ask for help in these forums (or just comp.lang.scheme). Post
>your code for critical review (put a copyright on it).
>
>The RFC for the HTTP protocol is at
>
>http://www.w3.org/Protocols/rfc2068/rfc2068
>
>After this brief excursion you will better understand what is needed in a
>programing language and then you can pick your next application and programming
>language. Repeat the procedure, continue until happy.
>
>See you in 30 days.....
>
A server is too complex and vague a task.
The vagueness comes from what functionality you want to add.
Do you support CGI and virtual servers for example?
The complexity comes from serveral fronts, mainly
the complexity of HTTP itself ( which is not that complex, but
more complex than for one junior programmer ).
Instead go to:
http://icfpcontest.cse.ogi.edu/
there you will find 5 problems doable by one programmer that are
extremely well defined and should be doable by one person in 30 days.
Thome and Hunt ( aka the pragmatic programmers ) advocate a practice
called loty ( language of the year ) where a person learns a new
language each year. Recently I've begun to advocate starting your loty
on Labor day, and using the exam as your "final exam" of the last
years loty, and using the exam as a problem to probe next years loty.
"Thaddeus L Olczyk" <······@interaccess.com> wrote in message
·······································@4ax.com...
> A server is too complex and vague a task.
> The vagueness comes from what functionality you want to add.
> Do you support CGI and virtual servers for example?
> The complexity comes from serveral fronts, mainly
> the complexity of HTTP itself ( which is not that complex, but
> more complex than for one junior programmer ).
Yes it is vague, but it is real life. This task has real-world programming
issues stamped all over it.
It has a deadline and a specification.
Choices will have to made about the programming language implementation,
trade-offs of what can be implemented in the alloted time. The programmer will
have to learn about HTTP, sockets, data structures, files, parsers,...., the
list goes on. Even if he only gets a very simple server done (no general URI
parsers) that only serves files I would consider that a success. He will also
hit the issue of testing and how to do that. Part of the conclusion is to see
how well the programming language enables the programmer to be productive within
the timeline.
Wade
On Mon, 16 Sep 2002 14:36:45 GMT, "Wade Humeniuk"
<····@nospam.nowhere> wrote:
>
>Yes it is vague, but it is real life. This task has real-world programming
>issues stamped all over it.
>
>It has a deadline and a specification.
This is *much much much more* true of ICFP.
In fact a web server does not have a specification ( otherwise it
would not be vague ).
Put in simpler words if someone wanted to hire me and
handed me a sheet of paper saying:
Project: Write a web server.
Deadline: 30 days.
I would say "hand me a lot more pages describing what you want"
before I even consider taking the jobs. Even if handed (IIRC) RCF2616
I would not take the job. ( RCF2616 is a description of a protocol,
*not* a specification. )
OTOh there are many who do use the ICFP as a specification because it
is a specification. Yes it's for teams of people, it's meant to be
worked on full-time and it's not for someone learning a new language,
but those limitations are overcome by extending the deadline to thirty
days.
* ·············@yahoo.com (Scott)
| Another friend tells me "define what you mean by 'better programmer'".
You have received much advice, most of which I find useful given a prior
understanding of what it means to be a programmer, but it occurs to me that
this is far from as obvious as one might think. What kinds of things would
you like the computer to do for you? What kinds of things are you already
good enough at that you can teach a computer to do it? Do you have extensive
experience with hardware so you want to control devices and do things like
play music or movies and such? Are you adept at human-computer interaction so
you want to write software that embodies your psychological insight to write
software that makes a human being more efficient at some task? Have you
succeeded in teaching children or adults anything and would like to write
computer-aided teaching software? Do you enjoy graphic arts and typography
and would like to use the computer to automate the production of, say, flyers
and posters? Are you interested in photography and would like to write
software for digital image processing? Is optical recognition and artificial
vision on your list of interests? The list of questions obviously goes on and
on, extending into every field of human endeavors.
In my view, to be a programmer is to be sufficiently well versed in some non-
computer-related field that you can see how the computer can aid practioners
of that field accomplish their goals. Many programmers never progress beyond
the point of aiding their own use of the computer and never do anything "real"
-- the number of software packages that help people read mail and news and
waste enormous amount of time in front of the computer are legion, but they
tend to make people spend /more/ time on these tasks than they would or should
have done compared to actually productive tasks.
Take spam, for instance. Varying amounts of effort by an enormous number of
people have been poured into getting rid of this problem, including many
pretty clever filtering tricks. However, the opportunity arises for machine
recognition of meaning in electronic texts such that computers can analyze and
classify them according to, say, Dewey's or Universal decimal classification.
If this problem was solved, such things as the Semantic Web and search engines
that produced topic maps would provide vastly different perspectives on the
enormous emount of web pages out there. Spam detection would fall out of this
work simply by being classified in areas most people have no interest, and if
you should be interested in some of the things that are advertised by this
means, you would be able to locate it. Imagine a world in which you could ask
your computer to retrieve news articles and web pages according to a semantic
classification instead of having to try out different search words. Imagine
that this classification would not need a human to classify the documents but
where machines would "understand" them. What would you need to know as a
programmer before you could successfully implement something like this?
Clearly, being a good programmer, you would need to know many algorithms in
addition to understanding the nature of classification better than most of the
people who do it by hand, perhaps instead writing a system that finds patterns
in what has already been classified instead of actually understanding things.
Often, a the solution to a problem is very different from the solutions that
come to mind immediately. High intelligence and good creativity is needed
atop a vast mass of knowledge from many fields is necessary to solve the many
remaining interesting problems.
However, if all it means to be a programmer is to be able to code up something
from a specification and a design provided by others, "all" you need is a good
command of the tools you use and the language grammar and idioms to express
the ideas that somebody else have dreamt up. This part of programming is not
the most interesting in my view, but many people who hire programmers want
them to think as little as possible and be as faithful as possible to designs
made by others. To be a "better" programmer in this regard is very different
from a better programmer who can solve unsolved problems.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On Mon, 16 Sep 2002 04:49:08 -0300, Erik Naggum wrote:
>
> Take spam, for instance. Varying amounts of effort by an enormous
> number of people have been poured into getting rid of this problem,
> including many pretty clever filtering tricks. However, the
> opportunity arises for machine recognition of meaning in electronic
> texts such that computers can analyze and classify them according to,
> say, Dewey's or Universal decimal classification. If this problem was
> solved, such things as the Semantic Web and search engines that
> produced topic maps would provide vastly different perspectives on the
> enormous emount of web pages out there. Spam detection would fall out
> of this work simply by being classified in areas most people have no
> interest, and if you should be interested in some of the things that
> are advertised by this means, you would be able to locate it. Imagine
> a world in which you could ask your computer to retrieve news articles
> and web pages according to a semantic classification instead of having
> to try out different search words. Imagine that this classification
> would not need a human to classify the documents but where machines
> would "understand" them. What would you need to know as a programmer
> before you could successfully implement something like this? Clearly,
> being a good programmer, you would need to know many algorithms in
> addition to understanding the nature of classification better than
> most of the people who do it by hand, perhaps instead writing a system
> that finds patterns in what has already been classified instead of
> actually understanding things.
>
>
Dear Mr. Naggum --
I don't understand your point of view, in the light of the fact that a
couple of weeks ago you said that SGML and XML were "braindead."
That really kept me wondering for days...I kept thinking "well, how
would you view, then, a thing like the Semantic Web from a Lisp
perspective?" I thought it would be, perhaps, something like the LispWeb
server, which seemed a very "intelligent" proposal (if I may make a pun
with the A.I. feature.)
Now, you're a "senior" member of this community, and I respect what you
write and have often learned a lot from you posts and interesting views
of issues posted here. That said...
Would you care to expand on your views regarding the Semantic Web, XML
being "hopeless", SGML being "braindead" and all that in what regards a
Lisp approach to those important questions? That is, how would *you* go
about it, if I may ask?
All these things matter a lot to me, being from the medical community,
and quite aware of the importance that being able to integrate the data
that continues to grow at exponential rate in the field (genome, for
instance, the barrier that tradional statistics methods are up against in
a large medical database, etc...)
Thank you
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
* synthespian
| I don't understand your point of view, in the light of the fact that a
| couple of weeks ago you said that SGML and XML were "braindead."
Well, let me put it this way: The XML crowd believes that if you only add
enough markup, everything humankind has ever dreamt of will suddenly emerge
from the chaos. I believe that this is a very serious misunderstanding of
both chaos and emergent properties and that more markup will, in fact,
prevent them from emerging. XML-style markup effectively prohibits the
multiple perspectives on the same information that makes it usable for
multiple purposes. In this sense, the more you employ XML to achieve your
goals, the more irrelevant the result will become.
| That really kept me wondering for days...I kept thinking "well, how would
| you view, then, a thing like the Semantic Web from a Lisp perspective?"
Note that the Semantic Web so far is being realized with tons and tons of
markup that fail miserably in being the flexible declarative language to
describe semantics in web pages that we need. I consider the efforts by the
people who work on this without any understanding of how people have dealt
with semantic classification of information prior to the Internet to be a
colossal waste of effort. They will, in all likelihood, reinvent everything
badly, being more interested in concocting useless syntactic monsters than
the information infrastructure that is necessary to realize their ideas.
| Would you care to expand on your views regarding the Semantic Web, XML being
| "hopeless", SGML being "braindead" and all that in what regards a Lisp
| approach to those important questions? That is, how would *you* go about
| it, if I may ask?
This is a very broad question. I think the Semantic Web will be realized
when the analytical capacity of software has progressed to the point where
people are actively encouraged to help the computer by communicating their
intent and our human-computer-human communication changes out language and
our communication skills. For instance, when it becomes rewarding for the
user to make the steps of his argument clear to the computer so the computer
can help him communicate with other computers that might more effectively
argue his point with the originating human who will listen more to his
computer than to other people, the user will benefit from communicating in a
way that removes much of the ambiguity of our current language. This will
not happen if the amount of work necessary to communicate with the computer
is as immensely complicated as the current XML-based Semantic Web.
| All these things matter a lot to me, being from the medical community, and
| quite aware of the importance that being able to integrate the data that
| continues to grow at exponential rate in the field (genome, for instance,
| the barrier that tradional statistics methods are up against in a large
| medical database, etc...)
I envision a future where people are sufficiently encouraged by computers to
learn the skills of rhetoric, argumentation, and logic to actually achieve
what education cannot achieve when there is no clear benefit to learning
either of these skills. I also believe that something like Dewey's or the
Universal decimal classification system needs to be taught as the optimal
means of searching for information with computers. (The actual numbers is
not the point -- the hierarchical structuring of human knowledge that is
embodied in the coding into numbers is an unparallelled achievement. The
silly re-invention of "ontologies" in the Semantic Web context is pathetic
in comparison.) All of this actually means that philosophy, epistemology,
the nature of concepts, etc, will have to become fundamental in people's
approach to information. Today, we are hampered by many false starts in
these areas and much muddled thinking and expression thereof. I believe
that over time, probably many decades, perhaps even centuries, we will get
rid of many of the historical accidents in our language and communication
and will consider the new accident of using computers a more fundamental
property than it is today. When you cannot get anything /done/ being sloppy
and incoherent, people will just adapt. The school that says that computers
should adapt to people is wrong for many reasons, the most important of
which is the misguided notion that what people do today is better than whet
they will do tomorrow under new technological influences, that yesterday's
(or yestercentury's) technology that shaped our language and thinking, is
better than our current or future technology, is keeping us all back.
I am, obviously, not advocating that we go into some "logical" language or
that we "speak mathematics" (frequent hysterical rejections of improvements
in human communication usually take this form by mathofobes), but that we
consider the benefits that befall us when adapting our natural language to
the requirements that follow from wanting to get the most out of exchanges
with our communication peers. When our peers become computers, as the
Semantic Web clearly foresee, people should, indeed must, change to make
themselves better understood and the exchange more fruitful for all parties.
If the Sapir-Whorf hypothesis holds, we must change our language in order to
become more "rational" vis-a-vis the computer. This could become a "class
distinction" in the future, where the educated communicate mostly with their
computers and the illiterate mostly with people. It is at times like this
that my desire to see immortality in our lifetime just gets more intense.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Frank A. Adrian
Subject: Knowledge classification systems (Was: Re: becoming a better programmer)
Date:
Message-ID: <7Byh9.1652$M91.112606@news.uswest.net>
Erik Naggum wrote:
> I also believe that something like Dewey's or the
> Universal decimal classification system needs to be taught as the
> optimal
> means of searching for information with computers. (The actual numbers
> is not the point -- the hierarchical structuring of human knowledge that
> is embodied in the coding into numbers is an unparallelled achievement.
You've mentioned the Dewey Decimal System. I assume from the above that you
believe that other classifications would also be OK (Prytz, Library of
Congress, etc.) as long as the classification was universal and
hierarchical or do you also prefer numberical, as opposed to
alphanumerical? I also find the ideas of a universal classification system
useful, but I have some things that bother me about the use of these
systems when searching for materials.
First, hierarchical classifications are fine for finding books within a
given subject, but give no indication as to level. A book on introductory
geometry might be next to an advanced book like Hilbert's "Foundations of
Geometry". Although you might be able to find books on a topic, will you
be able to sort and find books at a given level on a topic easily? Second,
I wonder about stability of item location within the classification system.
I remember finding a 1960's technical report on SNOBOL from Bell Labs back
in 1972 and thinking that this was already "historical material". If I
found it today, I'm pretty sure it would be better classified under history
of computing and not programming. In subclassifications dealing with
rapidly changing topics, I could see this becoming an issue.
I guess I'm wondering if any single ontological system really works that
well, or if a linearization of a multi-dimensional or networked system
might be better. In any case, I am, of course, thankful for what we
currently have!
Finally, just a note of curiosity. While looking for information on library
classification systems, I noticed that Finland uses a Dewey derivative
called YKL. Does Norway also have its own derivative for its libraries or
does it follow Dewey's system?
faa
From: Erik Naggum
Subject: Re: Knowledge classification systems (Was: Re: becoming a better programmer)
Date:
Message-ID: <3241258769257668@naggum.no>
* Frank A. Adrian
| You've mentioned the Dewey Decimal System. I assume from the above that you
| believe that other classifications would also be OK (Prytz, Library of
| Congress, etc.) as long as the classification was universal and hierarchical
| or do you also prefer numberical, as opposed to alphanumerical?
I cannot find any useful information on Prytz, and I have not been able to
figure out the Library of Congress system. I am comfortable with Dewey's
and the Universal decimal classification system, probably because I remember
numbers accurately without effort, while alphanumeric strings are lossy.
Others I have talked to about this over the years see higher error rates in
alphanumeric, including an unexpectedly interesting conversation with the
designer of postal codes in Norway (which introduced them in 1968) and an
equally unexpectedly entertaining conversation with the designer of the
Norwegian social security number (introduced in 1964) -- I fear that such
people are seldom recognized for their achievements. So I actually favor a
system that is as simple as possible, possibly using coded representation of
extraneous features. Dewey reserves 0 in subclasses and codes such things a
geography, special subcategorization, etc, with 0 followed by additional
digits. Thus the total number is a simple string of digits. UDC uses a
more complex syntax which I personally find harder to remember.
| I also find the ideas of a universal classification system useful, but I
| have some things that bother me about the use of these systems when
| searching for materials.
|
| First, hierarchical classifications are fine for finding books within a
| given subject, but give no indication as to level.
There are codes available for this in most of the existing systems.
| Second, I wonder about stability of item location within the classification
| system.
This has become a more significant issue. If you look for the Library of
Congress Cataloging-in-Publication Data of most U.S. imprints, you will find
the Dewey code after the LC classification (a.k.a. call number) and year and
before the LCCN (control number).
Book Ed Year Dewew CIP LOC
Common Lisp the Language 1984 001.64'24 (dc19)
2nd 1990 005.13'3 (dc20)
Winston & Horn: Lisp 2nd 1984 001.64'24 (dc19)
3rd 1989 005.13'3 (dc19)
James Gleick: Chaos 1988 003--dc19
Structure and Interpretation 1985 001.64'24 (dc19)
of Computer Programs 2nd 1996 005.13'3--dc20
Introduction to Algorithms 1989 005.1--dc20
2nd 2001 005.1--dc21
The addition of the DDC edition in the Dewey code started with DDC 19, but
was recommended with DDC 20 and mandatory with DDC 21. DDC 22 is due out
next year. We see that programming languages moved from DDC 19 to DDC 20,
with at least one book published before DDC 20. (I included the last two
items just to show that things also do not move. :)
| I remember finding a 1960's technical report on SNOBOL from Bell Labs back
| in 1972 and thinking that this was already "historical material".
But while the material itself is historical, the subject matter is not. The
crucial difference between here is in the intent of the publication.
| If I found it today, I'm pretty sure it would be better classified under
| history of computing and not programming.
That would require an arbitrary decision as to "currentness" of the
material, which is explicitly excluded from consideration in classification.
| In subclassifications dealing with rapidly changing topics, I could see this
| becoming an issue.
Strictly speaking, topics do not change, but new subclasses are frequently
added and guidance on classification is published by the OCLC. E.g., I was
happy to find "Semantic Web" classififed there as 025.04 for me when I did
not find an obvious classification for it. The world-wide agreement on the
application of and changes to the Dewey classification is a fascinating
thing it itself.
| I guess I'm wondering if any single ontological system really works that
| well, or if a linearization of a multi-dimensional or networked system might
| be better. In any case, I am, of course, thankful for what we currently
| have!
Many are surprised to find that DDC and UDC are multidimensional.
| Finally, just a note of curiosity. While looking for information on library
| classification systems, I noticed that Finland uses a Dewey derivative
| called YKL. Does Norway also have its own derivative for its libraries or
| does it follow Dewey's system?
Just this week, the Norwegian Library Association published its 5th edition,
a translation and adaptation of the 21st edition of DDC (i.e., including a
number of pre-built numbers for typical Norwegian uses and downplaying
classes that are more fine-grained in the U.S., particulary the 800 class
(literature)). We have been lagging behind the U.S. development and only
now prepare to reclassify public administration (350-354), education (370)
and life sciences (560-590) according to DDC 21. The Oslo public library
system (Deichmanske), being as it was the first library in Norway to adapt
and apply Dewey's classification in 1898, have been a leading force in the
application of Dewey in the Nordic countries and have resisted the
temptation to make the kind of renegade changes that plagued many other
Norwegian public libraries a few decades ago.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> Many are surprised to find that DDC and UDC are multidimensional.
Does this mean that a given Dewey classification encodes multiple attributes?
That's interesting, but not quite as good as independent features. Please
correct me if I'm wrong, but I assume that the Dewey system (and the others
you've mentioned) are designed for physical objects like books, where each item
belongs in exactly one place.
With online systems, it would seem much better to label each data item with
a whole set of applicable features, and then basically navigate through the
hierarchy by doing searches and building virtual indexes. In such a scheme,
a given object might appear at numerous "leafs" in the classification tree,
rather than only one.
Do Dewey systems already allow for this somehow? Or do you think the idea that
an item might not have a unique classification is misguided?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org ···@geddis.org
I don't think God put me on this planet to judge others. I think he put me on
this planet to gather specimens and take them back to my home planet.
-- Deep Thoughts, by Jack Handey
* Don Geddis
| Does this mean that a given Dewey classification encodes multiple attributes?
Yes. Geography and audience are particularly well-utilized examples. E.g.,
a book about Indiana high-school women's basketball would be classified
under sports, basketball, pre-college, in Indiana, for women. A book about
cats for children would be classified under cats, intended for children.
| Please correct me if I'm wrong, but I assume that the Dewey system (and the
| others you've mentioned) are designed for physical objects like books, where
| each item belongs in exactly one place.
Yes, the books would be in one place, but you would obviously have multiple
index cards for them if they were cross-classified. It is useful to find
related items grouped in the bookshelves, but this is a consequence of the
nature of bookshelves, not of the classification.
| With online systems, it would seem much better to label each data item with
| a whole set of applicable features, and then basically navigate through the
| hierarchy by doing searches and building virtual indexes. In such a scheme,
| a given object might appear at numerous "leafs" in the classification tree,
| rather than only one.
This is already the case. I have several books that are cross-classified.
| Do Dewey systems already allow for this somehow? Or do you think the idea
| that an item might not have a unique classification is misguided?
I think you have assumed that a classified item has only one classification.
This is false. It must have one, and the better it is, the more useful that
one is, but if a book covers some more than subject, there is nothing to
stop it from getting several classifications. (Unless, of course, it is a
"general collection", where the classifiers basically give up on it with the
assumption that people would not look for it under any specific area.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> a book about Indiana high-school women's basketball would be classified
> under sports, basketball, pre-college, in Indiana, for women.
>
> Yes, the books would be in one place, but you would obviously have multiple
> index cards for them if they were cross-classified.
Thanks for pointing out the "cross-classification", which indeed was my main
concern.
> It is useful to find
> related items grouped in the bookshelves, but this is a consequence of the
> nature of bookshelves, not of the classification.
I believe you were suggesting that (something like) the Dewey system be used
for online materials as well, so I was wondering how this works in practice
for non-physical items.
I would imagine that "cross-classification" is relatively rare. Even for your
example, is "for women" a section underneath the sports/basketball hierarchy?
How natural would it be to allow me to look at an index of all "for women"
books, whether they fall under sports or not?
The alternative I was thinking of (which may actually be compatible with
a Dewey system) is just a long list of feature/value pairs, perhaps where the
features and/or values may be hierarchical. So then your book example might be
Category sports
Category basketball
Level pre-college
Geography Indiana
For women
Pages 138
Published 1975
Edition 3
etc.
I would like a user to be able to query for
all books
with less than 200 pages
that are intended for women
in an area of the United States
and then to be shown a custom index that includes your sample book. Note how
Indiana automatically matches "part of the United States", which probably means
that "Category sports" doesn't need to be explicit, since it is implied by
"category basketball".
This scenario seems to me the way online material should be indexed, with very
flexible metadata. It isn't obvious to me that existing classifications like
the Dewey Decimal System are intended for this kind of application. You were
recommending them, though, so I assume you think much (all?) of the value
transfers directly to the new application?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org ···@geddis.org
* Don Geddis
| I believe you were suggesting that (something like) the Dewey system be used
| for online materials as well, so I was wondering how this works in practice
| for non-physical items.
My vision, if that is what it is, is that you would navigate the Dewey space
more or less visually and locate things according as you believe they would
be classified. Multiple classifications would never be a problem online.
| I would imagine that "cross-classification" is relatively rare.
Yes, but not because of the clasisfication, but because most publishers try
to limit the scope of their published material. It is considered bad from
to publish a book about programming languages and spend half of it on the
psychological aspects of temporal reasoning.
| Even for your example, is "for women" a section underneath the
| sports/basketball hierarchy?
No, it is a secondary table of "tags". You can search for these tags in
almost all electronic library systems. E.g., there are geographical codes
that make it possible to search for anything that is published about some
small place, if it has been suitably classified.
| How natural would it be to allow me to look at an index of all "for women"
| books, whether they fall under sports or not?
How natural? On a scale from 0 through 9, probably around 7. :)
| It isn't obvious to me that existing classifications like the Dewey Decimal
| System are intended for this kind of application.
I believe something very much like Dewey would be an essential part of a
better web, but I sense somehow that you think I want to get rid of all
other approaches and classifications. Why is this? I have not given you
any conscious indication of such a desire, which is in fact contrary to what
I would want to see.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On 16 Sep 2002 10:59:07 +0000, Erik Naggum <····@naggum.no> wrote:
> This is a very broad question. I think the Semantic Web will be realized
> when the analytical capacity of software has progressed to the point where
> people are actively encouraged to help the computer by communicating their
> intent and our human-computer-human communication changes out language and
> our communication skills. For instance, when it becomes rewarding for the
Suppose the <H1>, <H2>,... <H6> HTML tags had been used for what they were
intended. It would have been trivial for search engines to generate useful
outlines of indexed documents.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
* Paolo Amoroso
| Suppose the <H1>, <H2>,... <H6> HTML tags had been used for what they were
| intended. It would have been trivial for search engines to generate useful
| outlines of indexed documents.
If the CSS had been available from the start, things could have developed
that way. It is, however, far better design not to use explicit levels but
rather nesting constructs. The fact that these headings do not nest but
sort of "float" in the overall body may have been a good idea to some people
at some time, but it is generally only a recipe for abuse, which is also the
development we have seen.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> * Paolo Amoroso
> | Suppose the <H1>, <H2>,... <H6> HTML tags had been used for what they were
> | intended. It would have been trivial for search engines to generate useful
> | outlines of indexed documents.
>
> If the CSS had been available from the start, things could have developed
> that way. It is, however, far better design not to use explicit levels but
> rather nesting constructs. The fact that these headings do not nest but
> sort of "float" in the overall body may have been a good idea to some people
> at some time, but it is generally only a recipe for abuse, which is also the
> development we have seen.
For the record, XHTML 2 will finally have nested sections, and
generally seems to make it from a lousy to a tolerable *ML
application. Maybe there's hope, but I still think getting rid of HTML
altogether is more promising than fixing it.
* Henrik Motakef
| For the record, XHTML 2 will finally have nested sections, and generally
| seems to make it from a lousy to a tolerable *ML application. Maybe there's
| hope, but I still think getting rid of HTML altogether is more promising
| than fixing it.
I quite agree, but the cost of the transition will be considerable. The only
good things about the Web are that web pages are rewritten and applications
scrapped at an alarming rate even in our current recession and that there is
apparently no resistance to any kind of design in the community as long as
they can get their desired visual results. Such a pragmatic focus may be a
good foundation for making the necessary changes relatively quickly.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On Mon, 16 Sep 2002 07:59:07 -0300, Erik Naggum wrote:
> I envision a future where people are sufficiently encouraged by
> computers to learn the skills of rhetoric, argumentation, and logic to
> actually achieve what education cannot achieve when there is no clear
> benefit to learning either of these skills. I also believe that
> something like Dewey's or the Universal decimal classification system
> needs to be taught as the optimal means of searching for information
> with computers. (The actual numbers is not the point -- the
> hierarchical structuring of human knowledge that is embodied in the
> coding into numbers is an unparallelled achievement. The silly
> re-invention of "ontologies" in the Semantic Web context is pathetic
> in comparison.) All of this actually means that philosophy,
> epistemology, the nature of concepts, etc, will have to become
> fundamental in people's approach to information. Today, we are
> hampered by many false starts in these areas and much muddled thinking
> and expression thereof.
There's one thing that I definitely think is a basic flaw with
ontologies, at least the way they're set up (I may have a very limited
understanding on the topic, however): the ontology is defined by the
"definer".
For example, the person who defines the ontology has motives
for indexing something in the ontology. Why does he/she do it? What are the
"economics" or "psychology" behind it? This is relevant, as anyone who
works with narketing will tell you.
Another thing is the very meaning
of a word.How then, does he/she understand the meaning of the word?
Words change meaning over time, a fact any linguist will tell you...And,
if that wasn't enough, they mean different things to different people. I'm
not talking about you defining that <zp> means <zip code>, but the very
concept of zip code (ok, my example isn't so good. But let me give you a
*real* example: a sociologist here in Brazil set out to discover what
percentage of the population understood the correct meaning of the
concepts of "right" and "left" in politics...A total disaster...An amazing
amount had no clue, and actually exchanged meaning. Now imagine a
candidate for the the congress asking for votes...you get the picture...)
So, at some point, words cease to mean what they initially meant. This,
from the point of view of a database of ontologies introduces quite a lot of noise.
So maybe you end up eventually with inference rules that are really
bogus.When you have the emergence of new meanings as in language you need
software that a software that is intelligent enough to sort out the new
meanings, perhaps even in a temporal way which, AFAIK is totally out
of the design of the ontologies as they are being proposed for the
Semantic Web. You end up with a huge amount of entropy.
Henry
--
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
"synthespian" <···········@debian-rs.org> wrote in message
·········································@debian-rs.org...
> On Mon, 16 Sep 2002 07:59:07 -0300, Erik Naggum wrote:
>
>
> > I envision a future where people are sufficiently encouraged by
> > computers to learn the skills of rhetoric, argumentation, and logic to
> > actually achieve what education cannot achieve when there is no clear
> > benefit to learning either of these skills. I also believe that
> > something like Dewey's or the Universal decimal classification system
> > needs to be taught as the optimal means of searching for information
> > with computers. (The actual numbers is not the point -- the
> > hierarchical structuring of human knowledge that is embodied in the
> > coding into numbers is an unparallelled achievement. The silly
> > re-invention of "ontologies" in the Semantic Web context is pathetic
> > in comparison.) All of this actually means that philosophy,
> > epistemology, the nature of concepts, etc, will have to become
> > fundamental in people's approach to information. Today, we are
> > hampered by many false starts in these areas and much muddled thinking
> > and expression thereof.
>
> There's one thing that I definitely think is a basic flaw with
> ontologies, at least the way they're set up (I may have a very limited
> understanding on the topic, however): the ontology is defined by the
> "definer".
> For example, the person who defines the ontology has motives
> for indexing something in the ontology. Why does he/she do it? What are
the
> "economics" or "psychology" behind it? This is relevant, as anyone who
> works with narketing will tell you.
> Another thing is the very meaning
> of a word.How then, does he/she understand the meaning of the word?
I'm in agreement with Erik that most of the people working on the semantic
web have a fairly pathetic notion of "ontologies", at least from the point
of view of someone who thinks they need to be more than just a database
schema. The one point you make that I do agree with you on is that
ontologies do need to have some mechanism for representing temporal
relations, but probably not for the reasons you have cited.
However you seem to be somewhat confused by what an ontology (or more
accurately an ontograph to coin a word - ontology is "the study of being"
and we're really talking about a "representation of being"; so where I use
the word "ontology" in what follows, I mean "ontograph") is intended to
capture, and to be fair, the blame can probably rest on those who have
mistaken the concept for "data dictionary" and promulgated the usage of the
term as equivalent to a dictionary. Natural langauge words have more than
one sense, or meaning. The sense is the semantics of the word on an
occasion, but you may use other pragmatic information to decide which sense
is meant (or if indeed, the expression is intended metaphorically, etc.).
Words, however, are not "defined" in an ontograph, only symbols are. I
cannot define the english word "right" to mean "conservative", I can only
define some symbol, say XYZZY to mean what we usually mean by conservative
(to the extent the representational power of the ontograph allows me to do
this), and then say that there is some sense of the word "right" that is
XYZZY, as there is some sense of the word "conservative". Typically lexicons
are used to map word tokens to their possible senses (concepts); this is not
the job of the ontograph. (That I happen to choose the symbol RIGHT instead
of XYZZY still has nothing to do with the use of the english word "right" on
any particular occasion, although as a matter of good practice, generally
one should choose symbols in one's ontograph that are at least somewhat
intuitive to the user(s). But since any entry will by necessity only capture
some particular sense (and perhaps even concepts that are not natural senses
of any particular word at all, but some other concept either a priori or a
posteriori, or even ad hoc).
Now that this ontograph is (in part) a dictionary of symbols (as opposed to
a dictionary of words) is part of the answer to your confusion . The other
part of an ontograph which is missed by many in the semantic web community
who come from a database background, is that the ontograph also must contain
all of the relationships between these concepts, in a way that corresponds
to that part of "existance" that is to be described. Symbol grounding, or
how we get from a particular symbol to some entity in the world (the problem
of mapping intension to extension) is not directly addressed by ontography,
but the ease by which such mechanisms can be created is one way to rate the
effectiveness of a particular representation (when such a mechanism is
needed, e.g. for reasoning systems attached to robots or other "embodied
agents". (Of course the ontograph itself consists of type or class
information and relationships, not of individuals. For information about
individuals, we consult a world model. For instance, we might have the
concept of "person" in the ontograph, but "George Bush Jr." would be in the
world model. Similarly, a particular description of language used by people
on an occasion (your concern with the change of preferred word senses over
time) would be part of the world model. That words can change their sense
might be represented in the ontograph, but not any particular mapping.
Literally the ontology is a representation of existance. Of necessity, that
representation will have errors of various sorts, and this is something that
has been a problem in the field of Knowledge Representation from the start;
the real question is if your application will care about those errors, what
kinds of inferences your representation encourages (makes easy), and how
well that matches the problem(s) at hand. The concepts represented in an
ontograph do not change over time, though a lexicon that is meant to
correspond to the language usage of a particular time and place may well do
so. Think of it this way: the length denoted by a meter will never change,
it is eternal. However, the meaning of the word "meter" may change, and come
to denote a different length. Or as some old saw once said, "I don't know
what langauge they'll be using for AI in the next century, but I do know it
will be called 'Lisp'."
If you want a nice short introduction to KR, may I recommend (best of the
papers available online that I've seen, I'd welcome better citations from
other practitioners): Randall Davis, Howard Shrobe, and Peter Szolowits
"What is a Knowledge Representation?", AI Magazine 14:1 17--33, 1993.
http://citeseer.nj.nec.com/davis93what.html
> Words change meaning over time, a fact any linguist will tell you...And,
> if that wasn't enough, they mean different things to different people. I'm
> not talking about you defining that <zp> means <zip code>, but the very
> concept of zip code (ok, my example isn't so good. But let me give you a
> *real* example: a sociologist here in Brazil set out to discover what
> percentage of the population understood the correct meaning of the
> concepts of "right" and "left" in politics...A total disaster...An amazing
> amount had no clue, and actually exchanged meaning. Now imagine a
> candidate for the the congress asking for votes...you get the picture...)
> So, at some point, words cease to mean what they initially meant. This,
> from the point of view of a database of ontologies introduces quite a lot
of noise.
> So maybe you end up eventually with inference rules that are really
> bogus.When you have the emergence of new meanings as in language you need
> software that a software that is intelligent enough to sort out the new
> meanings, perhaps even in a temporal way which, AFAIK is totally out
> of the design of the ontologies as they are being proposed for the
> Semantic Web. You end up with a huge amount of entropy.
>
>
>
> Henry
>
>
>
> --
>
>
> _________________________________________________________________
> Micro$oft-Free Human 100% Debian GNU/Linux
> KMFMS "Bring the genome to the people!
> www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
On Wed, 18 Sep 2002 14:59:22 -0300, Brad Miller wrote:
> "synthespian" <···········@debian-rs.org> wrote in message
>
> I'm in agreement with Erik that most of the people working on the
> semantic web have a fairly pathetic notion of "ontologies", at least
> from the point of view of someone who thinks they need to be more than
> just a database schema. The one point you make that I do agree with you
> on is that ontologies do need to have some mechanism for representing
> temporal relations, but probably not for the reasons you have cited.
>
> However you seem to be somewhat confused by what an ontology
> If you want a nice short introduction to KR, may I recommend (best of
> the papers available online that I've seen, I'd welcome better citations
> from other practitioners): Randall Davis, Howard Shrobe, and Peter
> Szolowits "What is a Knowledge Representation?", AI Magazine 14:1
> 17--33, 1993.
(snip)
> http://citeseer.nj.nec.com/davis93what.html
>
Thank you for your newbie-friendly approach and for the explanations and
URL. :-) Nowdays, the web isn't only populated by experts. Some regret
that. Others understand that this is just how life is, and that newbies
will not remain in that condition, and that one day, they might make
substantial contributions. "The world goes around and comes around", is
that the correct English saying?
I wish there were more people like that at c.l.l. I remember the days
when Kent Pitmann used to help newbies (and everyone else) here...Now he
just quit posting at c.l.l. Sad...
Best regards,
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
* synthespian <···········@debian-rs.org>
| I wish there were more people like that at c.l.l. I remember the days when
| Kent Pitmann used to help newbies (and everyone else) here...Now he just
| quit posting at c.l.l. Sad...
While lamenting any development is anyone's prerogative, have you given any
consideration to what you can do make newbies less arrogant?
| Nowdays, the web isn't only populated by experts. Some regret that.
What has changed is more than its composition and it is not restricted to
the Net. The amount of knowledge that a person needs to acquire from the
grand total in society before he can make a useful contribution to advance
it is at serious odds with the massive glorification of youth. As marketing
found itself unable to expand without encroaching upon our childhood, the
intense drive to capture the minds of the youngest among us has tended to
make people believe that 30 years of experience can be replaced by the young
looks of rank novices. This is made worse by the management schools that
make it possible for people who have yet to grow enough facial hair to need
to shave daily not only to show off their insufficient beard growth as "hip"
but to fill "leadership" positions where they feel threatened by anyone
significantly older than themselves and where the inability to /lead/ is
replaced by their simple skills at /managing/.
I believe it takes all kinds to make a working world, but what I find among
the modern novices is that they do not feel the same way about the experts --
they want an expert-free world where their ignorance is not painful, where
their inexperience is not used against them, where they get all the jokes,
where nobody uses literary references that elude them, where every one of
their ideas is accepted by their peers as just as novel as they think it is,
where they can make mistakes without being corrected by people who do know
better, where they can reap all the benefits early in life instead of having
to work for 40 years first. It is not that getting everything early in life
is bad, it is more that you get so disillusioned when you have got everything
and you still have to live 50 years with bleak prospects since you helped
establish and encouraged the cultue that eschewes people of your age. It is
not that it is bad to find new programming languages cooler than older ones,
it is more that you find that being good at what you do is punished and you
keep reverting to a novice when the next new language comes around. It is
not that is bad to make a relative ton of money when you are fresh out of
highschool, it is more that the relative ton is much bigger when you are 40
and you find yourself losing the competition with the youngsters who still
live with their parents and have no obligations or mortgages or children or
pension saving plans.
| Others understand that this is just how life is, and that newbies will not
| remain in that condition, and that one day, they might make substantial
| contributions.
Some actually understand that you cannot just kill people when grow old.
The effort spent at the new must continue to be rewarding to the old. When
it is not, the new teach the new, and you get a virtual absence of vertical
communication, leading to lack of continuity and horizontal bands that move
through the population over time, each self-sufficient and unwilling to help
other age groups. Ignorance of the past becomes a virtue and experience a
liability in societies that form like this. In some movie (I believe it was
�The Straight Story�), some old guy is asked by a younger: "What is the worst
part of growing old?" and answers "Remember when you were young." The
problem with glorifying youth is that they do not have the knowledge to make
an informed choice. So, too, with the ignorant-friendly Net -- of course the
ignorants think it's great, what else can they compare with -- of course many
experts think it sucks, they actually have something to compare it with.
People who want to learn are, however, always welcome. People who respect
knowledge, know what it costs to acquire it. People who do not know its
costs will generally not respect it, either. It is sometimes illuminating to
take a child to a library with more than a million books. Some feel humbled
and overwhelmed by what they could not possibly deal with that day, but some
understand right there that they will never run out of exciting books to read.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> wrote in message news:<················@naggum.no>...
> they want an expert-free world where their ignorance is not painful, where
In the past people had to get along better. Old and young,
experienced and novice, had to work together well. But now we have
the internet, where everyone can be their own boss, and age is not
even noticed. Instead of giving advice to young people, we should
write programs to give them advice, and sell those programs to them.
Instead of working by the hour for a young boss who finds our
experience annoying, we should work for ourselves, and set up shop on
the internet to sell our products.
Let the arrogant novices sink their own ship. It's the only way they
can learn to swim. But if someone does like to give them advice, we
should not complain. Arrogant novices ignore good advice, and nothing
is gained by complaining to those who give it. Advice givers get
their own rewards, often from the advice itself, as it may be putting
words to ideas which were vague to them until they gave them the form
of advice.
synthespian <···········@debian-rs.org> writes:
> But let me give you a *real* example: a sociologist here in Brazil
> set out to discover what percentage of the population understood the
> correct meaning of the concepts of "right" and "left" in
> politics...A total disaster...An amazing amount had no clue, and
> actually exchanged meaning. Now imagine a candidate for the the
> congress asking for votes...you get the picture...)
What I find even more amazing is that this ``sociologist'' apparently
thinks that it is so entirely clear what right and left means, that
there is much of a difference between them and he knows what it is and
everybody else should, too. For another viewpoint see, for instance,
``The Road to Serfdom'' by F. A. Hayek.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
On Wed, 18 Sep 2002 08:43:06 -0300, Nils Goesche wrote:
> synthespian <···········@debian-rs.org> writes:
>
>> But let me give you a *real* example: a sociologist here in Brazil set
>> out to discover what percentage of the population understood the
>> correct meaning of the concepts of "right" and "left" in politics...A
>> total disaster...An amazing amount had no clue, and actually exchanged
>> meaning. Now imagine a candidate for the the congress asking for
>> votes...you get the picture...)
>
> What I find even more amazing is that this ``sociologist'' apparently
> thinks that it is so entirely clear what right and left means, that
> there is much of a difference between them and he knows what it is and
> everybody else should, too. For another viewpoint see, for instance,
> ``The Road to Serfdom'' by F. A. Hayek.
>
> Regards,
Norberto Bobbio's "Destra e Sinistra", too. I agree, partially. It
probably has to do with all the years that sociologist has spent at the
Sorbonne.
However, you can see a right wing agenda on U.S. very clearly now...
Please don't claim they're sitting left at the political spectrum. The
concept still holds. Jimmy Carter, the U.S. former president that just
about everybody loves thinks so too. Anyways, this is too
off-topic...there's alt.politics for that.. :-)
Regs
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
* synthespian
| There's one thing that I definitely think is a basic flaw with ontologies,
| at least the way they're set up (I may have a very limited understanding on
| the topic, however): the ontology is defined by the "definer".
That is, it is a flaw in the system that it is designed by humans for humans.
This is an age-old philosophical problem which I personally consider totally
nuts. We /are/ humans. This is /not/ a flaw. We take what we have and deal
with it. Wishful thinking and dreaming about changing the human condition
may be fun, but it is not productive.
| For example, the person who defines the ontology has motives for indexing
| something in the ontology. Why does he/she do it? What are the "economics"
| or "psychology" behind it? This is relevant, as anyone who works with
| narketing will tell you.
So you have at least discovered that all human knowledge is contextual.
This is a good step up from the desire that human knowledge should be
acontextual or absolute, a desire which has frustrated people for ages when
they do not think things through. Coupled with a "magical" weltanschauung
where things become what we think about them, there can only be chaos. But
there is a different fundamental outlook on this: The world out there is the
same for all people, and no matter which contorted approach you take to
grasp it, you will, eventually, end up with the same knowledge as everybody
else. The real question is whether there you can find ways to approach this
whole knowledge thing that would result in fewer blind alleys and false
starts, and there is. This is what philosophy is all about, or at least the
branch of it called epistemology -- or the study of how we know what we
know. I know of no serious effort to study epistemology that has ended up
with the same kind of "magical" weltanschauung that people who have not
studied it, but have sort of adopted the pre-scientific model of religions,
tend to hold.
| Another thing is the very meaning of a word. How then, does he/she
| understand the meaning of the word? Words change meaning over time, a fact
| any linguist will tell you...And, if that wasn't enough, they mean different
| things to different people. I'm not talking about you defining that <zp>
| means <zip code>, but the very concept of zip code (ok, my example isn't so
| good. But let me give you a *real* example: a sociologist here in Brazil
| set out to discover what percentage of the population understood the correct
| meaning of the concepts of "right" and "left" in politics...A total
| disaster...An amazing amount had no clue, and actually exchanged meaning.
| Now imagine a candidate for the the congress asking for votes...you get the
| picture...)
No, on the contrary: I think you show a massive lack of insight into these
issues, and thus react with fear, uncertainty, and doubt about issues that
are not only taken well care of by professionals who know their business,
but never actually arise in practice when the system is used by skilled
users. And believe me, if you are observant and wish to understand, instead
of approaching a system with preconceived notions that how you have done
things up until now is flawless and perfect and anything that deviates from
it is bunk, it takes very little time to understand Dewey or the Universal
decimal classification well enough to predict where you will find things.
For the fine-grained classification of new works, however, it takes serious
investment in studying it and discussing with other classifiers. This is,
after all, social engineering. I think most of the problems you allude to
actually come from the desire to see a system usable in a vacuum by one
person with no prior exposure to the system. I believe that novices should
be willing to learn something rather than be willing to judge something they
do not know. I realize that I am in the minority in this modern world where
many people think that not knowing something is superior to knowing it, at
least morally, and that the only people you cannot ask if you want to know
something are experts in the field. This anti-rational, anti-intellectual,
anti-knowledge stance is not usually conscious, however, and most people
will deny that they have such attitudes, but still act on them and feel much
"safer" if they ask some fellow ignorant than if they ask an expert. It has
puzzled me greatly for as far back as I can remember. None of the experts I
have asked have been able to give a good answer. [Pause for effect...] The
people who tend to feel this way, however, are usually unable to argue for
it, because as soon as they start to think, they move into the rational world
where their attitudes are very different from their default non-thinking ones.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On Wed, 18 Sep 2002 11:29:27 -0300, Erik Naggum wrote:
>he | picture...)
>
> No, on the contrary: I think you show a massive lack of insight into
> these issues, and thus react with fear, uncertainty, and doubt about
> issues that are not only taken well care of by professionals who know
> their business, but never actually arise in practice when the system
> is used by skilled users. And believe me, if you are observant and
> wish to understand, instead of approaching a system with preconceived
> notions that how you have done things up until now is flawless and
> perfect and anything that deviates from it is bunk, it takes very
> little time to understand Dewey or the Universal decimal
> classification well enough to predict where you will find things. For
> the fine-grained classification of new works, however, it takes
> serious investment in studying it and discussing with other
> classifiers. This is, after all, social engineering. I think most of
> the problems you allude to actually come from the desire to see a
> system usable in a vacuum by one person with no prior exposure to the
> system. I believe that novices should be willing to learn something
> rather than be willing to judge something they do not know.
>
>
To be more specific, I was concerned with how ontologies keep track of
the changes in the word's meaning. Is there, for instance, a way to track
a date a definition was set? Is there an etymology or a framework that
enables one?
And I wasn't *judging*, I worked with the information I had, which was perhaps, very little, but was
from Tim Berners-Lee and the article he wrote about it recently. I
am not an expert on ontologies, it's not my focus...
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
* synthespian <···········@debian-rs.org>
| To be more specific, I was concerned with how ontologies keep track of the
| changes in the word's meaning. Is there, for instance, a way to track a
| date a definition was set? Is there an etymology or a framework that
| enables one?
Ontologies are intended to capture concepts and their relationships. Words
are merely names for concepts, so this is a little beside the point, but I
think I understand what you might be getting at. I have no idea, however.
| And I wasn't *judging*, I worked with the information I had, which was
| perhaps, very little, but was from Tim Berners-Lee and the article he wrote
| about it recently. I am not an expert on ontologies, it's not my focus...
Well, I have been massively unimpressed with TBL's work and papers. Having
just reviewed a book on the Semantic Web that I asked the publisher not to
publish, and having read several other books on the Semantic Web in that
process, I can safely say that the Semantic Web is not rocket science. It
is, however, massively overcomplex, the typical result of insufficiently
intelligent people in action. One of the reasons I have returned to study
Dewey and work with the Online Computer Library Center, our National Library
and the Deichmanske Library in Oslo to see if it is possible to automate or
at least let the machine assist classification of Internet resources like
Usenet news articles is precisely that I think reinventing the wheel in this
area is nuts. If nothing else, letting these experienced people think about
the problem should save me a lot of time and should help them think about
future directions for their systems. So far, the response has been amazingly
positive.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On Mon, 16 Sep 2002 05:28:33 -0300, synthespian <···········@debian-rs.org>
wrote:
> All these things matter a lot to me, being from the medical community,
> and quite aware of the importance that being able to integrate the data
> that continues to grow at exponential rate in the field (genome, for
> instance, the barrier that tradional statistics methods are up against in
> a large medical database, etc...)
I suggest that you have a look at all the books by Edward Tufte you can
afford. Lots of food for thought.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
On Tue, 17 Sep 2002 10:03:18 -0300, Paolo Amoroso wrote:
> On Mon, 16 Sep 2002 05:28:33 -0300, synthespian
> <···········@debian-rs.org> wrote:
>
>> All these things matter a lot to me, being from the medical community,
>> and quite aware of the importance that being able to integrate the data
>> that continues to grow at exponential rate in the field (genome, for
>> instance, the barrier that tradional statistics methods are up against
>> in a large medical database, etc...)
>
> I suggest that you have a look at all the books by Edward Tufte you can
> afford. Lots of food for thought.
>
>
> Paolo
Thanks, will do.
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
Erik Naggum <····@naggum.no> writes:
> * ·············@yahoo.com (Scott)
> | Another friend tells me "define what you mean by 'better programmer'".
[ ... ]
> However, if all it means to be a programmer is to be able to code up something
> from a specification and a design provided by others, "all" you need is a good
> command of the tools you use and the language grammar and idioms to express
> the ideas that somebody else have dreamt up. This part of programming is not
> the most interesting in my view, but many people who hire programmers want
> them to think as little as possible and be as faithful as possible to designs
> made by others. To be a "better" programmer in this regard is very different
> from a better programmer who can solve unsolved problems.
Another way to look at what makes a better programmer is by looking at
the endpoints, i.e. the best and worst possibilities. To me, the closest
I can come to the endpoints are these:
- Most elemental programmer: I don't consider a person who learns to
use a word-processor (or any other shrink-wrapped app, for that matter)
a programmer. However, if that app has a preferences option, and the
user is using it to customize the app for their own usages, well that
becomes programming. Some may argue that this is not really programming,
because it is so common, but then where else would we draw the line?
- The Ultimate Programmer: I saw an original Star Trek episode, when it
first came out, and as I recall (but it may be fuzzy) Kirk and Spock
break into an ancient computer room, and find a computer not built
by any Federation life forms. Spock had never seen the computer, but
proceeds to discover what it is (I think it was an archive library of
some sort) and then to access the data, so that their adventure could
go on. Being fairly new to programming at the time, and having seen
several completely different languages, operating systems, and even
I/O devices, I scoffed at this episode at first; I didn't think it was
possible to encounter a completely foreign computer and figure out how
to access it, let alone work it. But now that I am more experienced,
I believe (without proof) that it is possible, although I still admire
the scientific and programming expertise of Spock to be able to figure
it out so quickly.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Scott <·············@yahoo.com> wrote:
[wants to be a better programmer, asks friends for advice.]
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either.
Here is where, if this were a zen story, your friend is supposed to
smack you in the head with a stick, and you become enlightened.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
Scott wrote:
> Another friend tells me "define what you mean by 'better programmer'".
> So, that guy wasn't too helpful either.
Only because you did not follow his advice. :)
kenny
clinisys
Scott wrote:
> Thanks in advance for your time...
One word: Java
I've decided recently this is a great beginner's language.
You'll learn about Object-Orientation and structured programming.
You'll learn a lot that is useful in C and C++.
It has graphics, so you'll get instant gratification.
It's not too hard to learn.
It's free.
--
|_ CJSonnack <·····@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
Also sprach Programmer Dude:
> Scott wrote:
>
>> Thanks in advance for your time...
>
> One word: Java
>
> I've decided recently this is a great beginner's language.
> You'll learn about Object-Orientation and structured programming.
You'll learn about one form of Object-Orientation, namely the Java way.
This is by no means the only way. In a sense, it is even quite limited
with some arbitrary limitations that sooner or later start to become a
nuisance (of course only to those knowing the OO of other languages).
> You'll learn a lot that is useful in C and C++.
What, except for the similar syntax? Especially between C and Java I see
no similarity at all. One obvious example: Where the process model is
quite essential in C (at least for systems supporting it such as
unices), Java is rather going for threads which is a whole different
way of thinking.
> It has graphics, so you'll get instant gratification.
Java has graphics? You must be referring to Java's Swing toolkit. I very
much doubt that a beginner to programming will get instant gratification
from that.
> It's not too hard to learn.
Debatable. While the language core itself appears to be rather simple it
is not enough to be productive. You need to know a good deal about the
huge API that comes with it. I don't think this is very
beginner-friendly.
> It's free.
So are most other languages.
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
Programmer Dude <·········@mmm.com> writes:
> One word: Java
>
> I've decided recently this is a great beginner's language.
> You'll learn about Object-Orientation and structured programming.
> You'll learn a lot that is useful in C and C++.
> It has graphics, so you'll get instant gratification.
> It's not too hard to learn.
> It's free.
Best of all, it leaves a lot of room to improve yourself by learning
better languages after you are done with it. Yay Java!
Programmer Dude <·········@mmm.com> writes:
> One word: Java
>
> I've decided recently this is a great beginner's language.
introducing java at a beginners level may make the beginners course
a course in library-shopping instead of real programming...
--
(espen)
On Thu, 19 Sep 2002 06:36:10 GMT, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
>Programmer Dude <·········@mmm.com> writes:
>
>> One word: Java
>>
>> I've decided recently this is a great beginner's language.
>
>introducing java at a beginners level may make the beginners course
>a course in library-shopping instead of real programming...
"Real programmers type octal into the debugger at the command line", eh?
Java the language is simple but limited. Java plus a library or two is capable
of expressing a wide range of solutions. For esoteric applications, there are
esoteric libraries. As is the case with C++.
Al Balmer
Balmer Consulting
Alan Balmer <········@att.net> writes:
> >introducing java at a beginners level may make the beginners course
> >a course in library-shopping instead of real programming...
>
> "Real programmers type octal into the debugger at the command line", eh?
I wasn't thinking of "real programming" in that sense, but in the sense
of implementing algorithms.
--
(espen)
Alan Balmer wrote:
> "Real programmers type octal into the debugger at the command line",
> eh?
"Real programmers "cp /dev/audio a.out" and whistle into the mike." (Randal
L. Schwartz)
jue
"J�rgen Exner" <········@hotmail.com> scribbled the following
on comp.lang.java.programmer:
> Alan Balmer wrote:
>> "Real programmers type octal into the debugger at the command line",
>> eh?
> "Real programmers "cp /dev/audio a.out" and whistle into the mike." (Randal
> L. Schwartz)
Real programmers read their e-mail by whistling 300 baud into the
modem line.
--
/-- Joona Palaste (·······@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio
Also sprach Joona I Palaste:
> "J�rgen Exner" <········@hotmail.com> scribbled the following
> on comp.lang.java.programmer:
>> Alan Balmer wrote:
>>> "Real programmers type octal into the debugger at the command line",
>>> eh?
>
>> "Real programmers "cp /dev/audio a.out" and whistle into the mike." (Randal
>> L. Schwartz)
>
> Real programmers read their e-mail by whistling 300 baud into the
> modem line.
Nah, that's how they send them.
Tassilo
--
$_=q!",}])(tsuJ[·@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
Joona I Palaste <·······@cc.helsinki.fi> writes:
> "J�rgen Exner" <········@hotmail.com> scribbled the following
> on comp.lang.java.programmer:
> > Alan Balmer wrote:
> >> "Real programmers type octal into the debugger at the command line",
> >> eh?
>
> > "Real programmers "cp /dev/audio a.out" and whistle into the mike." (Randal
> > L. Schwartz)
>
> Real programmers read their e-mail by whistling 300 baud into the
> modem line.
Bah, only those who are too slow to keep up with 1200 baud...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'