Interesting article by Joel Spolsky: The Perils of JavaSchools
Casey Hawthorne
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
--
Regards,
Casey
Gerry Quinn
caseyhHA...@istar.ca says...
> Interesting article by Joel Spolsky: The Perils of JavaSchools
>
> http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
Decades ago, Dijkstra sneered at students who had dared to learn Basic,
and consequently lapped up his pearls of wisdom with less appreciation
than he expected. Now, it appears, the target is Java.
It's ironic to see the somewhat trivial concepts of pointers and
recursion feted as challenging, purely on the basis that certain
programmers are unfamiliar with their use. [And surely Java supports
recursion as well as any language?]
Then comes the extolling of functional languages such as Lisp, which
have more advocates than useful programs written in them. It expands
the brain and makes you a better person, or so we're told. I've heard
colonic irrigation does the same.
- Gerry Quinn
Chris Dollin
> It's ironic to see the somewhat trivial concepts of pointers and
> recursion feted as challenging, purely on the basis that certain
> programmers are unfamiliar with their use. [And surely Java supports
> recursion as well as any language?]
No, it doesn't - TRO isn't mandated (nor TCO), and can't be easily added
because of the <adjective> way security checks rely on call traces, as
far as I understand. Compare Scheme.
--
Chris "believes seventeen improbable things before coffee" Dollin
Seventeen, forty-two - what else is there?
wooks
Gerry Quinn wrote:
> In article <qokqr1los71vcv7oe...@4ax.com>,
> caseyhHA...@istar.ca says...
> > Interesting article by Joel Spolsky: The Perils of JavaSchools
> >
> > http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
>
> Decades ago, Dijkstra sneered at students who had dared to learn Basic,
> and consequently lapped up his pearls of wisdom with less appreciation
> than he expected. Now, it appears, the target is Java.
>
> It's ironic to see the somewhat trivial concepts of pointers and
> recursion feted as challenging, purely on the basis that certain
> programmers are unfamiliar with their use. [And surely Java supports
> recursion as well as any language?]
>
Misses the point.
Most Java(any imperative language) programmers will instinctively opt
for an iterative solution and will only use recursion when they are
forced to.
Iterative solutions don't scale well to increasingly complex data
structures. In those situations your imperative programmer takes a lot
longer to produce buggier, less concise solutions, because they are not
practised in recursive techniques.
> Then comes the extolling of functional languages such as Lisp, which
> have more advocates than useful programs written in them. It expands
> the brain and makes you a better person, or so we're told. I've heard
> colonic irrigation does the same.
>
Misses the point again.
The ability to think recursively is an important skill for a programmer
and indeed problem solvers at large.
Functional languages force you to acquire that skill because thats the
only way of getting things done.
Once you have that skill it transfers to understanding algorithms, and
to programming competently in languages that do have "useful programs
written in them" like XSLT which alot of imperative programmers make a
complete mess off..
MSCHAEF.COM
Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
...
>It's ironic to see the somewhat trivial concepts of pointers and
>recursion feted as challenging, purely on the basis that certain
>programmers are unfamiliar with their use. [And surely Java supports
>recursion as well as any language?]
The Java specification doesn't require JVM's to implement tail call
elimination, which can restrict its use severely. [1] Related, the MS CLR
has performance issues with its implemetation of tail calls too, although
Microsoft appears to be working on it. [2]
For non-tail recursion, you're probably right.
>Then comes the extolling of functional languages such as Lisp,
<pedant>
Lisp isn't functional, although it does have good support for
functional styles of programming.
</pedant>
>which have more advocates than useful programs written in them.
Lisp has many more detractors than advocates, even as mainstream
programming practice is rushing to embrace its techniques.
-Mike
1] http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf
2] http://blogs.msdn.com/shrib/archive/2005/01/25/360370.aspx
MSCHAEF.COM
Chris Dollin <ke...@hpl.hp.com> wrote:
...
>No, it doesn't - TRO isn't mandated (nor TCO), and can't be easily added
>because of the <adjective> way security checks rely on call traces, as
>far as I understand.
This paper describes a way to accomplish security checking in the
presence of tail call optimizations:
http://www.ccs.neu.edu/scheme/pubs/cf-toplas04.pdf
It also points out that the MS CLR already has tail call elimination, that
works in the absence of a transition from untrusted to trusted code. My
hunch is that in most cases, the uses of tail call optimization that
depend on the optimization don't make such a security transition.
-Mike
--
http://www.mschaef.com
Phlip
> It's ironic to see the somewhat trivial concepts of pointers and
> recursion feted as challenging, purely on the basis that certain
> programmers are unfamiliar with their use. [And surely Java supports
> recursion as well as any language?]
Joel's point is real programmers comprehend pointers, so pointers make a
good test to identify real programmers.
Not to defend Java, but comprehending virtual methods makes as good a
test...
> Then comes the extolling of functional languages such as Lisp, which
> have more advocates than useful programs written in them.
;-)
--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Arthur J. O'Dwyer
On Fri, 6 Jan 2006, Phlip wrote:
>
> Gerry Quinn wrote:
>> It's ironic to see the somewhat trivial concepts of pointers and
>> recursion feted as challenging, purely on the basis that certain
>> programmers are unfamiliar with their use. [And surely Java supports
>> recursion as well as any language?]
>
> Joel's point is real programmers comprehend pointers, so pointers make a
> good test to identify real programmers.
Yes.
> Not to defend Java, but comprehending virtual methods makes as good a
> test...
I would agree, but another of Joel's points was that OOP "learning"
usually means learning /jargon/, not actual programming skills. I think
"virtual method" is a good example of that observation. AIUI, a virtual
method is essentially a way to let derived objects have different
behaviors, but gussied up with a jargon name. Joel offers "the
difference between polymorphism and overloading" as another example
of an OO "skill" that amounts to a vocabulary lesson.
Another point I don't think Joel explicitly made, but: How on earth
does an interviewer test "comprehension" of virtual methods? Just asking
"What does a virtual method do?" doesn't work; that's the vocabulary-
lesson model again.
OTOH, it's easy to see whether a college grad understands pointers;
just give him a C library function to implement.
(FWIW, I've seen C knowledge tested with the vocabulary model, too;
Nvidia asks "what does 'volatile' mean?" when talking with prospective
coders.)
Gerry wrote:
>> Then comes the extolling of functional languages such as Lisp, which
>> have more advocates than useful programs written in them.
Yes, Paul Graham made that point in the article linked from Joel's,
http://www.paulgraham.com/avg.html
He points out that when hackers /stop/ extolling Lisp and /start/ coding
in it, they make lots of money. :)
-Arthur
Phlip
> I would agree, but another of Joel's points was that OOP "learning"
> usually means learning /jargon/, not actual programming skills. I think
> "virtual method" is a good example of that observation. AIUI, a virtual
> method is essentially a way to let derived objects have different
> behaviors, but gussied up with a jargon name. Joel offers "the
> difference between polymorphism and overloading" as another example
> of an OO "skill" that amounts to a vocabulary lesson.
Oh, my - you're right. Pointers are a hardware abstraction surfaced as a
variable. Virtual methods, contrarily, are a hardware abstraction (often a
jump table) camoflaged as messages and methods. So with pointers there's
less camoflage to discuss.
I ain't volunteering to interview programmers...
> Another point I don't think Joel explicitly made, but: How on earth
> does an interviewer test "comprehension" of virtual methods? Just asking
> "What does a virtual method do?" doesn't work; that's the vocabulary-
> lesson model again.
Uh, I have placed myself above other interviewees by demonstrating more than
a vague awareness what virtual methods _are_... ;-)
> (FWIW, I've seen C knowledge tested with the vocabulary model, too;
> Nvidia asks "what does 'volatile' mean?" when talking with prospective
> coders.)
It means the compiler won't optimize the variable because things outside the
compiler's understanding might change it.
There! I qualify to work for NVidia!! (And to think that there are
applicants who wouldn't realize a maker of video graphics display hardware
might not live and breath changing volatile memory between screen
refreshes...;)
Gerry Quinn
woo...@hotmail.com says...
> Gerry Quinn wrote:
> > It's ironic to see the somewhat trivial concepts of pointers and
> > recursion feted as challenging, purely on the basis that certain
> > programmers are unfamiliar with their use. [And surely Java supports
> > recursion as well as any language?]
> Misses the point.
> Most Java(any imperative language) programmers will instinctively opt
> for an iterative solution and will only use recursion when they are
> forced to.
If that's the point, it's not a very good one. A language that allows
you to pick appropriate solutions is better than one that forces you
into unsuitable ones.
(Actually I would expect many beginning programmers will be over-
excited by the concept of recursion, and will use it in inappropriate
circumstances.)
> Iterative solutions don't scale well to increasingly complex data
> structures. In those situations your imperative programmer takes a lot
> longer to produce buggier, less concise solutions, because they are not
> practised in recursive techniques.
Then the solution is to practice the techniques, but there's no need to
abandon Java in favour of a toy language that is limited to them and no
other.
> > Then comes the extolling of functional languages such as Lisp, which
> > have more advocates than useful programs written in them. It expands
> > the brain and makes you a better person, or so we're told. I've heard
> > colonic irrigation does the same.
> Misses the point again.
> The ability to think recursively is an important skill for a programmer
> and indeed problem solvers at large.
Yes, it's very useful. And you can learn it from Java, or Basic for
that matter.
- Gerry Quinn
Gerry Quinn
msc...@eris.io.com says...
> Lisp has many more detractors than advocates, even as mainstream
> programming practice is rushing to embrace its techniques.
> 1] http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf
That's definitely the first time I've seen the phrase "even as" used in
reference to a 1977 paper that talks about the evils of GOTO!
> 2] http://blogs.msdn.com/shrib/archive/2005/01/25/360370.aspx
Something about optimisation of tail-call recursion.
- Gerry Quinn
Gerry Quinn
@unix46.andrew.cmu.edu>, a...@nospam.andrew.cmu.edu says...
> Gerry wrote:
> >> Then comes the extolling of functional languages such as Lisp, which
> >> have more advocates than useful programs written in them.
>
> Yes, Paul Graham made that point in the article linked from Joel's,
> http://www.paulgraham.com/avg.html
> He points out that when hackers /stop/ extolling Lisp and /start/ coding
> in it, they make lots of money. :)
Yup, I've read that article, on account of how it refers to one of the
ten or so significant projects that were built in Lisp.
(IIRC, after he was bought out the new owners re-wrote it in Java.)
- Gerry Quinn
CTips
> In article <Pine.LNX.4.60-041.0601061432230.4811
> @unix46.andrew.cmu.edu>, a...@nospam.andrew.cmu.edu says...
>
>>Gerry wrote:
>>
>>>>Then comes the extolling of functional languages such as Lisp, which
>>>>have more advocates than useful programs written in them.
>>
>> Yes, Paul Graham made that point in the article linked from Joel's,
>>http://www.paulgraham.com/avg.html
>>He points out that when hackers /stop/ extolling Lisp and /start/ coding
>>in it, they make lots of money. :)
>
>
> Yup, I've read that article, on account of how it refers to one of the
> ten or so significant projects that were built in Lisp.
*significant*? Are you talking about the viaweb editor? Its only 25000
lines of code!
[See http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
"The Viaweb editor, which eventually grew
to be about 25,000 lines of code, grew incrementally from this
program."
]
The mind boggles at the concept of calling a 25-kloc program significant
(OTOH, someone paid BIG $$$ for it, so perhaps by that metric its
significant.)
> (IIRC, after he was bought out the new owners re-wrote it in Java.)
Perl + C++ actually
MSCHAEF.COM
Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
..
>(IIRC, after he was bought out the new owners re-wrote it in Java.)
Yes, viaweb was eventually rewritten in C++. More recently (the last few
months) Reddit was rewritten in Python, due to some sort of threading
related stability issue in the Lisp they used.
-Mike
--
http://www.mschaef.com
MSCHAEF.COM
Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
>In article <N-idnWdhwoU5HiPe...@io.com>,
>msc...@eris.io.com says...
>> In article <MPG.1e28627a5...@news1.eircom.net>,
>> Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
>
>> Lisp has many more detractors than advocates, even as mainstream
>> programming practice is rushing to embrace its techniques.
>
>> 1] http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf
>
>That's definitely the first time I've seen the phrase "even as" used in
>reference to a 1977 paper that talks about the evils of GOTO!
Those were foot notes.... :-) See the references further up in the mail.
The reason I mentioned the paper is that it gives a good summary of how
closures and tail calls can work together to efficiently implement
looping. The paper is not so much an argument about the evils of goto as
it is a description of how anonymous closures and efficient tail calls can
provide a structured form of goto without any loss of efficiency.
Without that kind of excellent support for tail call optimization, these
techniques don't work as well, which places more restrictions on the
control flow constructs you can use.
Which brings me to my second footnote:
>> 2] http://blogs.msdn.com/shrib/archive/2005/01/25/360370.aspx
>
>Something about optimisation of tail-call recursion.
Yes, it's about the implementation of tail call optimzation in .Net. It
turns out to be implemented in a way that's significantly less than the
ideal Steele describes in the first few sections of his paper.
-Mike
--
http://www.mschaef.com
Gerry Quinn
says...
> The mind boggles at the concept of calling a 25-kloc program significant
> (OTOH, someone paid BIG $$$ for it, so perhaps by that metric its
> significant.)
That's the metric that counts.
- Gerry Quinn
wooks
Gerry Quinn wrote:
> In article <1136550849.1...@z14g2000cwz.googlegroups.com>,
> woo...@hotmail.com says...
> > Gerry Quinn wrote:
>
> > > It's ironic to see the somewhat trivial concepts of pointers and
> > > recursion feted as challenging, purely on the basis that certain
> > > programmers are unfamiliar with their use. [And surely Java supports
> > > recursion as well as any language?]
>
> > Misses the point.
>
> > Most Java(any imperative language) programmers will instinctively opt
> > for an iterative solution and will only use recursion when they are
> > forced to.
>
> If that's the point, it's not a very good one. A language that allows
> you to pick appropriate solutions is better than one that forces you
> into unsuitable ones.
>
The problem is with your conception of "appropriate" and unsuitable.
Lists (or some derivative thereof so that includes arrays, stacks,
queues) are just about the most common and useful data structure in
computer science. How can you possibly class a recursive solution to
processing a list as unsuitable and inappropriate. It actually is the
best and most natural fit for the processing lists like structures for
the simple reason that a list is in fact a recursively defined data
structure.
There is nothing suitable or appropriate about stating
y = y + 1
because it quite obviously isn't true. It makes no mathematical sense
nor would it make sense to the man in the street. It's just the
perverted way in which many programmers go about effecting iteration.
Just because thats the way they easily understand whats going on
doesn't mean there's anything suitable or appropriate about it.
The fact is the mental model humans adopt to doing iterative things is
a recursive one.
Whether it's a 2 year old toddler, middle aged man or 90 year old
woman, if you put them at the bottom of the steps and ask them to climb
to the top they do they
start by counting the number of steps,
climb a step,
then say steps climbed = steps climbed + 1,
then compare steps climbed to the total number of steps.
or do they
climb(steps)
if no more steps stop
go up the first step
climb (rest of steps).
Same thing with a lecturer marking papers or a clerk processing
invoices. Only programmers approach these iterative tasks by counting
the total and keeping a running total as you process each one.
> (Actually I would expect many beginning programmers will be over-
> excited by the concept of recursion, and will use it in inappropriate
> circumstances.)
>
> > Iterative solutions don't scale well to increasingly complex data
> > structures. In those situations your imperative programmer takes a lot
> > longer to produce buggier, less concise solutions, because they are not
> > practised in recursive techniques.
>
> Then the solution is to practice the techniques, but there's no need to
> abandon Java in favour of a toy language that is limited to them and no
> other.
>
You are confusing popularity with capability and power!! Just because
Java gives you 3 different ways of writing loops in addition to
recursion do you think that makes it more powerful. Lets not even talk
about things like higher order functions that Java doesn't even
support.
The main reasons why imperative programming languages are in more
widespread use have nothing to do with them being better suited for
"real work", or being "serious languages". It's because they are
accessible to the mathematically unsophisticated which is a
description that probably applies to the majority of people employed
as programmers today.
The whole point Spolsky is making is that teaching people in Java means
that the odds are they won't practice these techniques in the first
place.
> > > Then comes the extolling of functional languages such as Lisp, which
> > > have more advocates than useful programs written in them. It expands
> > > the brain and makes you a better person, or so we're told. I've heard
> > > colonic irrigation does the same.
>
> > Misses the point again.
> > The ability to think recursively is an important skill for a programmer
> > and indeed problem solvers at large.
>
> Yes, it's very useful. And you can learn it from Java, or Basic for
> that matter.
>
> - Gerry Quinn
>
But the fact is your average Java programmer can't parse an abritarily
nested regular expression and can't grok XSLT because they ain't used
to thinking recursively. Why. Because they work in languages that lets
them work around having to.
wooks
again.
Gerry Quinn wrote:
> In article <1136550849.1...@z14g2000cwz.googlegroups.com>,
> woo...@hotmail.com says...
> > Gerry Quinn wrote:
>
> > > It's ironic to see the somewhat trivial concepts of pointers and
> > > recursion feted as challenging, purely on the basis that certain
> > > programmers are unfamiliar with their use. [And surely Java supports
> > > recursion as well as any language?]
>
> > Misses the point.
>
> > Most Java(any imperative language) programmers will instinctively opt
> > for an iterative solution and will only use recursion when they are
> > forced to.
>
> If that's the point, it's not a very good one.
It's an excellent one.
> A language that allows
> you to pick appropriate solutions is better than one that forces you
> into unsuitable ones.
>
Lists are recursively defined structures. Therefore recursion is the
most suitable and appropriate solution for problems that involve lists
and structures that derive from lists (arrays, stacks etc). The
languages you are referring to are the ones that allow you to pick
unsuitable and inappropriate solutions that depend on hacks like y=y+1
(it's obviously not true, makes no sense to a lay person and is a
mathematical abomination). Like I said these iterative solutions don't
scale with increasingly complex data structure. Ask an average Java
programmer to parse an arbitrarily nested regular expression and watch
him lose the plot.
> (Actually I would expect many beginning programmers will be over-
> excited by the concept of recursion, and will use it in inappropriate
> circumstances.)
>
Then you better define inappropriate because recursion is the
appropriate technique for any recursively defined data structure. If
your solution accurately models the data structure then it will scale
elegantly as the data structure gets more complicated. Methinks you are
thinking premature optimisation.
Put a child at the bottom of stairs and ask him to climb them. Give a
lecturer a pile of papers to mark. Give a clerk a stack of invoices to
process.The solution to all these problems is naturally recursive
Base case - no mor steps, invoices, papers to mark. Stop
Mark 1st paper/Climb first step/Process first invoice.
Recurse with the rest of papers/steps/invoices.
The only people who think that the appropriate and suitable way to
approach this task by counting the number of steps, invoices, papers,
processing one, incrementing a counter and then comparing that counter
to a total are computer programmers implementing dumbed down hacks.
> > Iterative solutions don't scale well to increasingly complex data
> > structures. In those situations your imperative programmer takes a lot
> > longer to produce buggier, less concise solutions, because they are not
> > practised in recursive techniques.
>
> Then the solution is to practice the techniques, but there's no need to
> abandon Java in favour of a toy language that is limited to them and no
> other.
>
To me a toy language is one that doesn't support higher order
functions.
You are confusing popularity with capability and power!! Just because
Java gives you 3 different ways of writing loops in addition to
recursion do you think that makes it more powerful. The main reasons
why imperative programming languages are in more widespread use have
nothing to do with them being better suited for "real work", or being
"serious languages". It's because they are accessible to the
mathematically unsophisticated which is a description that probably
applies to the majority of people employed as programmers today which
goes back to the dumbing down point that Spolsky is making.
> > > Then comes the extolling of functional languages such as Lisp, which
> > > have more advocates than useful programs written in them. It expands
> > > the brain and makes you a better person, or so we're told. I've heard
> > > colonic irrigation does the same.
>
> > Misses the point again.
> > The ability to think recursively is an important skill for a programmer
> > and indeed problem solvers at large.
>
> Yes, it's very useful. And you can learn it from Java, or Basic for
> that matter.
>
The whole point Spolsky is making is that teaching people in Java means
that the odds are they won't practice these techniques in the first
place because Java offers them solutions that enable them to work
around having to think recursively. For simple problems they can get
away with it. It breaks down when the have to parse an arbitrarily
nested formula or regular expression. There is no guarantee that a Java
programmer possesses this mental capability (and the odds are that they
don't), OTOH you are guaranteed it with a Lisp/Haskell/Scheme/ML
programmer.
wooks
again.
Gerry Quinn wrote:
> In article <1136550849.1...@z14g2000cwz.googlegroups.com>,
> woo...@hotmail.com says...
> > Gerry Quinn wrote:
>
> > > It's ironic to see the somewhat trivial concepts of pointers and
> > > recursion feted as challenging, purely on the basis that certain
> > > programmers are unfamiliar with their use. [And surely Java supports
> > > recursion as well as any language?]
>
> > Misses the point.
>
> > Most Java(any imperative language) programmers will instinctively opt
> > for an iterative solution and will only use recursion when they are
> > forced to.
>
> If that's the point, it's not a very good one.
It's an excellent one.
> A language that allows
> you to pick appropriate solutions is better than one that forces you
> into unsuitable ones.
>
Lists are recursively defined structures. Therefore recursion is the
most suitable and appropriate solution for problems that involve lists
and structures that derive from lists (arrays, stacks etc). The
languages you are referring to are the ones that allow you to pick
unsuitable and inappropriate solutions that depend on hacks like y=y+1
(it's obviously not true, makes no sense to a lay person and is a
mathematical abomination). Like I said these iterative solutions don't
scale with increasingly complex data structure. Ask an average Java
programmer to parse an arbitrarily nested regular expression and watch
him lose the plot.
> (Actually I would expect many beginning programmers will be over-
> excited by the concept of recursion, and will use it in inappropriate
> circumstances.)
>
Then you better define inappropriate because recursion is the
appropriate technique for any recursively defined data structure. If
your solution accurately models the data structure then it will scale
elegantly as the data structure gets more complicated. Methinks you are
thinking premature optimisation.
Put a child at the bottom of stairs and ask him to climb them. Give a
lecturer a pile of papers to mark. Give a clerk a stack of invoices to
process.The solution to all these problems is naturally recursive
Base case - no mor steps, invoices, papers to mark. Stop
Mark 1st paper/Climb first step/Process first invoice.
Recurse with the rest of papers/steps/invoices.
The only people who think that the appropriate and suitable way to
approach this task by counting the number of steps, invoices, papers,
processing one, incrementing a counter and then comparing that counter
to a total are computer programmers implementing dumbed down hacks.
> > Iterative solutions don't scale well to increasingly complex data
> > structures. In those situations your imperative programmer takes a lot
> > longer to produce buggier, less concise solutions, because they are not
> > practised in recursive techniques.
>
> Then the solution is to practice the techniques, but there's no need to
> abandon Java in favour of a toy language that is limited to them and no
> other.
>
To me a toy language is one that doesn't support higher order
functions.
You are confusing popularity with capability and power!! Just because
Java gives you 3 different ways of writing loops in addition to
recursion do you think that makes it more powerful. The main reasons
why imperative programming languages are in more widespread use have
nothing to do with them being better suited for "real work", or being
"serious languages". It's because they are accessible to the
mathematically unsophisticated which is a description that probably
applies to the majority of people employed as programmers today which
goes back to the dumbing down point that Spolsky is making.
> > > Then comes the extolling of functional languages such as Lisp, which
> > > have more advocates than useful programs written in them. It expands
> > > the brain and makes you a better person, or so we're told. I've heard
> > > colonic irrigation does the same.
>
> > Misses the point again.
> > The ability to think recursively is an important skill for a programmer
> > and indeed problem solvers at large.
>
> Yes, it's very useful. And you can learn it from Java, or Basic for
> that matter.
>
The whole point Spolsky is making is that teaching people in Java means
wooks
again.
Gerry Quinn wrote:
> In article <1136550849.1...@z14g2000cwz.googlegroups.com>,
> woo...@hotmail.com says...
> > Gerry Quinn wrote:
>
> > > It's ironic to see the somewhat trivial concepts of pointers and
> > > recursion feted as challenging, purely on the basis that certain
> > > programmers are unfamiliar with their use. [And surely Java supports
> > > recursion as well as any language?]
>
> > Misses the point.
>
> > Most Java(any imperative language) programmers will instinctively opt
> > for an iterative solution and will only use recursion when they are
> > forced to.
>
> If that's the point, it's not a very good one.
It's an excellent one.
> A language that allows
> you to pick appropriate solutions is better than one that forces you
> into unsuitable ones.
>
Lists are recursively defined structures. Therefore recursion is the
most suitable and appropriate solution for problems that involve lists
and structures that derive from lists (arrays, stacks etc). The
languages you are referring to are the ones that allow you to pick
unsuitable and inappropriate solutions that depend on hacks like y=y+1
(it's obviously not true, makes no sense to a lay person and is a
mathematical abomination). Like I said these iterative solutions don't
scale with increasingly complex data structure. Ask an average Java
programmer to parse an arbitrarily nested regular expression and watch
him lose the plot.
> (Actually I would expect many beginning programmers will be over-
> excited by the concept of recursion, and will use it in inappropriate
> circumstances.)
>
Then you better define inappropriate because recursion is the
appropriate technique for any recursively defined data structure. If
your solution accurately models the data structure then it will scale
elegantly as the data structure gets more complicated. Methinks you are
thinking premature optimisation.
Put a child at the bottom of stairs and ask him to climb them. Give a
lecturer a pile of papers to mark. Give a clerk a stack of invoices to
process.The solution to all these problems is naturally recursive
Base case - no mor steps, invoices, papers to mark. Stop
Mark 1st paper/Climb first step/Process first invoice.
Recurse with the rest of papers/steps/invoices.
The only people who think that the appropriate and suitable way to
approach this task by counting the number of steps, invoices, papers,
processing one, incrementing a counter and then comparing that counter
to a total are computer programmers implementing dumbed down hacks.
> > Iterative solutions don't scale well to increasingly complex data
> > structures. In those situations your imperative programmer takes a lot
> > longer to produce buggier, less concise solutions, because they are not
> > practised in recursive techniques.
>
> Then the solution is to practice the techniques, but there's no need to
> abandon Java in favour of a toy language that is limited to them and no
> other.
>
To me a toy language is one that doesn't support higher order
functions.
You are confusing popularity with capability and power!! Just because
Java gives you 3 different ways of writing loops in addition to
recursion do you think that makes it more powerful. The main reasons
why imperative programming languages are in more widespread use have
nothing to do with them being better suited for "real work", or being
"serious languages". It's because they are accessible to the
mathematically unsophisticated which is a description that probably
applies to the majority of people employed as programmers today which
goes back to the dumbing down point that Spolsky is making.
> > > Then comes the extolling of functional languages such as Lisp, which
> > > have more advocates than useful programs written in them. It expands
> > > the brain and makes you a better person, or so we're told. I've heard
> > > colonic irrigation does the same.
>
> > Misses the point again.
> > The ability to think recursively is an important skill for a programmer
> > and indeed problem solvers at large.
>
> Yes, it's very useful. And you can learn it from Java, or Basic for
> that matter.
>
The whole point Spolsky is making is that teaching people in Java means
Willem
) Base case - no mor steps, invoices, papers to mark. Stop
)
) Mark 1st paper/Climb first step/Process first invoice.
) Recurse with the rest of papers/steps/invoices.
Looks like iteration to me.
Repeat until the stack of papers is empty:
Mark paper and remove it from the stack
end
) The only people who think that the appropriate and suitable way to
) approach this task by counting the number of steps, invoices, papers,
) processing one, incrementing a counter and then comparing that counter
) to a total are computer programmers implementing dumbed down hacks.
So, the only form of iteration is when you count the steps ?
Does that mean that for (p = list; *p != NULL; p = p->next)
is not iteration ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
wooks
Willem wrote:
> wooks wrote:
> ) Base case - no mor steps, invoices, papers to mark. Stop
> )
> ) Mark 1st paper/Climb first step/Process first invoice.
> ) Recurse with the rest of papers/steps/invoices.
>
> Looks like iteration to me.
>
> Repeat until the stack of papers is empty:
> Mark paper and remove it from the stack
> end
>
do you also climb a step and remove it?
> ) The only people who think that the appropriate and suitable way to
> ) approach this task by counting the number of steps, invoices, papers,
> ) processing one, incrementing a counter and then comparing that counter
> ) to a total are computer programmers implementing dumbed down hacks.
>
> So, the only form of iteration is when you count the steps ?
> Does that mean that for (p = list; *p != NULL; p = p->next)
> is not iteration ?
>
p=p->next is the same order of hack as p=p+1.
Willem
) do you also climb a step and remove it?
Are you intentionally being stupid ?
) p=p->next is the same order of hack as p=p+1.
If your pet peeve is that the assignment operator looks unnatural,
then just say so. A variable that changes its value is completely
natural to a computer.
Gerry Quinn
> Gerry Quinn wrote:
> > > Most Java(any imperative language) programmers will instinctively opt
> > > for an iterative solution and will only use recursion when they are
> > > forced to.
> > If that's the point, it's not a very good one. A language that allows
> > you to pick appropriate solutions is better than one that forces you
> > into unsuitable ones.
> The problem is with your conception of "appropriate" and unsuitable.
>
> Lists (or some derivative thereof so that includes arrays, stacks,
> queues) are just about the most common and useful data structure in
> computer science. How can you possibly class a recursive solution to
> processing a list as unsuitable and inappropriate. It actually is the
> best and most natural fit for the processing lists like structures for
> the simple reason that a list is in fact a recursively defined data
> structure.
Complete nonsense. A list is a data structure, and different means can
be used to define it. Recursion is useful in mathematical definitions,
but programming is not math. But even if there is no better way than
recursion to define an ordered set, that does not imply (as you imply
above) that recursion is in every possibly situation the best way to
process it. Many languages are suitable for the implementation of both
recursive and iterative methods.
> There is nothing suitable or appropriate about stating
>
> y = y + 1
>
> because it quite obviously isn't true. It makes no mathematical sense
> nor would it make sense to the man in the street. It's just the
> perverted way in which many programmers go about effecting iteration.
> Just because thats the way they easily understand whats going on
> doesn't mean there's anything suitable or appropriate about it.
Actually it is an example of recursion. A function (+1) is called
repeatedly to modify y.
Iteration usually looks like:
for( int i = 0; i < maxVal; i++ ) {}
..or
for ( iterator i = begin(); i != end(); i++ ) {}
The above succintly indicate that all elements of a set are to be
processed, and the sequence in which this will occur. The first
includes a counter, which is often very useful.
> The fact is the mental model humans adopt to doing iterative things is
> a recursive one.
>
> Whether it's a 2 year old toddler, middle aged man or 90 year old
> woman, if you put them at the bottom of the steps and ask them to climb
> to the top they do they
>
> start by counting the number of steps,
> climb a step,
> then say steps climbed = steps climbed + 1,
> then compare steps climbed to the total number of steps.
>
> or do they
>
> climb(steps)
> if no more steps stop
> go up the first step
> climb (rest of steps).
Once they have learned to walk and count, they do what is best in a
given situation. But I would say that they normally do:
go to bottom of stairs
if ( at top ) stop
climb next step
repeat
This corresponds best to my second example of iteration.
> > Then the solution is to practice the techniques, but there's no need to
> > abandon Java in favour of a toy language that is limited to them and no
> > other.
> You are confusing popularity with capability and power!! Just because
> Java gives you 3 different ways of writing loops in addition to
> recursion do you think that makes it more powerful.
Yes. And it's nothing to do with popularity.
> Lets not even talk
> about things like higher order functions that Java doesn't even
> support.
If functional languages were so great, people would use them. That is
the 'popularity' argument, and it is quite a valid one.
> The main reasons why imperative programming languages are in more
> widespread use have nothing to do with them being better suited for
> "real work", or being "serious languages". It's because they are
> accessible to the mathematically unsophisticated which is a
> description that probably applies to the majority of people employed
> as programmers today.
In other words, they are suited to real work by real people. And
frankly, if a language is easier to use for ordinary folks, it is
probably easier to use for everyone.
> The whole point Spolsky is making is that teaching people in Java means
> that the odds are they won't practice these techniques in the first
> place.
And it's the same half-baked point that has been made for millennia,
when those who consider themselves as members of an intellectual elite
get worried that their inferiors are achieving much the same things as
they can, without having bothered with the elaborate membership
initiations. "They must be stopped", they wail. "How can the sacred
work be left in the hands of ignorami?".
> > > Misses the point again.
> > > The ability to think recursively is an important skill for a programmer
> > > and indeed problem solvers at large.
> >
> > Yes, it's very useful. And you can learn it from Java, or Basic for
> > that matter.
> But the fact is your average Java programmer can't parse an abritarily
> nested regular expression and can't grok XSLT because they ain't used
> to thinking recursively. Why. Because they work in languages that lets
> them work around having to.
When they need to learn it, they will. Hopefully employers will choose
to hire staff capable of doing or learning to do what they need,
whether that includes the above things or not.
Though if their teachers haven't taught them the basics, I would blame
them rather than the language.
- Gerry Quinn
Chuck F.
>
... snip ...
>
> There is nothing suitable or appropriate about stating
>
> y = y + 1
>
> because it quite obviously isn't true. It makes no mathematical
> sense nor would it make sense to the man in the street. It's
> just the perverted way in which many programmers go about
> effecting iteration. Just because thats the way they easily
> understand whats going on doesn't mean there's anything suitable
> or appropriate about it.
You are assuming a specific meaning for '=', which is contrary to
that of the language in question. Better programming languages
avoid the confusion by using something like ':=' for assignment.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
wooks
Gerry Quinn wrote:
> In article <1136648171.2...@g14g2000cwa.googlegroups.com>,
> woo...@hotmail.com says...
> > Gerry Quinn wrote:
>
> > > > Most Java(any imperative language) programmers will instinctively opt
> > > > for an iterative solution and will only use recursion when they are
> > > > forced to.
>
> > > If that's the point, it's not a very good one. A language that allows
> > > you to pick appropriate solutions is better than one that forces you
> > > into unsuitable ones.
>
> > The problem is with your conception of "appropriate" and unsuitable.
> >
> > Lists (or some derivative thereof so that includes arrays, stacks,
> > queues) are just about the most common and useful data structure in
> > computer science. How can you possibly class a recursive solution to
> > processing a list as unsuitable and inappropriate. It actually is the
> > best and most natural fit for the processing lists like structures for
> > the simple reason that a list is in fact a recursively defined data
> > structure.
>
> Complete nonsense.
>A list is a data structure, and different means can
> be used to define it.
The floor is yours. Give us your definition.
> Recursion is useful in mathematical definitions,
> but programming is not math. But even if there is no better way than
> recursion to define an ordered set, that does not imply (as you imply
> above) that recursion is in every possibly situation the best way to
> process it.
Of course a variety of hacks are at your disposal especially if you are
programming in something like Java.
> Many languages are suitable for the implementation of both
> recursive and iterative methods.
>
> > There is nothing suitable or appropriate about stating
> >
> > y = y + 1
> >
> > because it quite obviously isn't true. It makes no mathematical sense
> > nor would it make sense to the man in the street. It's just the
> > perverted way in which many programmers go about effecting iteration.
> > Just because thats the way they easily understand whats going on
> > doesn't mean there's anything suitable or appropriate about it.
>
> Actually it is an example of recursion. A function (+1) is called
> repeatedly to modify y.
>
no it's not.
> Iteration usually looks like:
> for( int i = 0; i < maxVal; i++ ) {}
>
> ..or
>
> for ( iterator i = begin(); i != end(); i++ ) {}
>
Right now tell me the difference between i++ and i=i+1?
BTW none of these techniques are available in XSLT. What then?
> The above succintly indicate that all elements of a set are to be
> processed, and the sequence in which this will occur. The first
> includes a counter, which is often very useful.
>
But it isn't so succint when some of the elements of the sets are sets
themselves. And supposing this nesting could be n levels deep. What
then?
> > The fact is the mental model humans adopt to doing iterative things is
> > a recursive one.
> >
> > Whether it's a 2 year old toddler, middle aged man or 90 year old
> > woman, if you put them at the bottom of the steps and ask them to climb
> > to the top they do they
> >
> > start by counting the number of steps,
> > climb a step,
> > then say steps climbed = steps climbed + 1,
> > then compare steps climbed to the total number of steps.
> >
> > or do they
> >
> > climb(steps)
> > if no more steps stop
> > go up the first step
> > climb (rest of steps).
>
> Once they have learned to walk and count, they do what is best in a
> given situation. But I would say that they normally do:
>
> go to bottom of stairs
> if ( at top ) stop
> climb next step
> repeat
>
> This corresponds best to my second example of iteration.
>
Whats the difference between your "repeat" and my clim(rest of steps).
> > > Then the solution is to practice the techniques, but there's no need to
> > > abandon Java in favour of a toy language that is limited to them and no
> > > other.
>
> > You are confusing popularity with capability and power!! Just because
> > Java gives you 3 different ways of writing loops in addition to
> > recursion do you think that makes it more powerful.
>
> Yes. And it's nothing to do with popularity.
>
> > Lets not even talk
> > about things like higher order functions that Java doesn't even
> > support.
>
> If functional languages were so great, people would use them. That is
> the 'popularity' argument, and it is quite a valid one.
>
It's got alot to do with the same reasons why there isn't a
Lisp/Scheme/Haskell/ML for Dummies/Idiots etc. They require a fair
degree of mathematical sophistication.
Nevertheless here is an opportunity to better inform yourself.
http://portal.acm.org/citation.cfm?id=286387
> > The main reasons why imperative programming languages are in more
> > widespread use have nothing to do with them being better suited for
> > "real work", or being "serious languages". It's because they are
> > accessible to the mathematically unsophisticated which is a
> > description that probably applies to the majority of people employed
> > as programmers today.
>
> In other words, they are suited to real work by real people. And
> frankly, if a language is easier to use for ordinary folks, it is
> probably easier to use for everyone.
>
Can you drop the "real" nonsense.
There are alot of ordinary folk writing crappy buggy software that
keeps crashing.
The ordinary "real" arguments are fine if you are solving a genuinely
simple problem.
Ordinary "real" folk didn't create the language that enables you to
come here and say what you are saying today. Check out the role that
Guy Steele had in inventing Java. Steele was an MIT student and one of
the inventors of Scheme.
> > The whole point Spolsky is making is that teaching people in Java means
> > that the odds are they won't practice these techniques in the first
> > place.
>
> And it's the same half-baked point that has been made for millennia,
> when those who consider themselves as members of an intellectual elite
> get worried that their inferiors are achieving much the same things as
> they can, without having bothered with the elaborate membership
> initiations. "They must be stopped", they wail. "How can the sacred
> work be left in the hands of ignorami?".
>
What has that got to do with whether Java programmers are well
practised in recursion.
> > > > Misses the point again.
> > > > The ability to think recursively is an important skill for a programmer
> > > > and indeed problem solvers at large.
> > >
> > > Yes, it's very useful. And you can learn it from Java, or Basic for
> > > that matter.
>
> > But the fact is your average Java programmer can't parse an abritarily
> > nested regular expression and can't grok XSLT because they ain't used
> > to thinking recursively. Why. Because they work in languages that lets
> > them work around having to.
>
> When they need to learn it, they will.
What you really mean is that they'll continue with their buggy
iterative hacks.
How can you know when it is appropriate to apply a technique that you
haven't even learnt.
> Hopefully employers will choose
> to hire staff capable of doing or learning to do what they need,
> whether that includes the above things or not.
>
Thats why Spolsky wants to hire people that can write Scheme/Lisp,
because he can be assured they have the necessary capabilities.
wooks
Willem wrote:
> wooks wrote:
> ) do you also climb a step and remove it?
>
> Are you intentionally being stupid ?
>
No but you obviously are.
> ) p=p->next is the same order of hack as p=p+1.
>
> If your pet peeve is that the assignment operator looks unnatural,
> then just say so. A variable that changes its value is completely
> natural to a computer.
>
There are languages in common use that don't let you do that. XSLT for
one.
Henceforth if you want to address me, learn some manners and try to
understand the underlying point being made. What you are raising are
largely irrelevant side issues.
Jonathan Bartlett
> recursion feted as challenging, purely on the basis that certain
> programmers are unfamiliar with their use. [And surely Java supports
> recursion as well as any language?]
(a) no, Java doesn't support recursion as well as any language, as it
does not do tail-call elimination.
(b) as Spolsky said, the issue is not whether or not a programmer has or
has not learned those things, but whether or not the programmer is
_capable_ of learning those things. I've known many programmers who
truly have difficulty learning such subjects, and it affects nearly
everything they do, even when they don't have to deal with it directly
(especially pointers).
In fact, I wrote a book introducing programming using assembly language
to help establish a more concrete basis for thinking about programming.
I think sometimes the problem is that most current languages are
fairly abstract, while pointers are very concrete. The mixing confuses
people. Teaching them assembly language gives them a full taste for the
concrete-ness of programming as an enterprise, and then later when they
learn the more abstract ideas, they will understand the underlying
mechanisms. You can get my book here:
http://www.cafeshops.com/bartlettpublish.8640017
> Then comes the extolling of functional languages such as Lisp, which
> have more advocates than useful programs written in them. It expands
> the brain and makes you a better person, or so we're told. I've heard
> colonic irrigation does the same.
The point of Scheme, for instance, is not necessarily useful programs,
but to teach concepts. While there are professional Scheme platforms,
the best use of Scheme is teaching concepts, which wind up helping
programmers really understand what they are doing.
In fact, my next book is going to be on just this subject.
Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
Jonathan Bartlett
> when those who consider themselves as members of an intellectual elite
> get worried that their inferiors are achieving much the same things as
> they can, without having bothered with the elaborate membership
> initiations. "They must be stopped", they wail. "How can the sacred
> work be left in the hands of ignorami?".
I think the problem isn't that people are looking for an intellectual
elite (though some might), it's that they are looking for people who
have an understanding of the whole picture. While a given feature may
be useful for 90% of programming projects, how will you know when you
have hit the 10% that you need another tool for, unless you know about
such tools and where they are used?
If you don't understand how program proofs work, how will you even know
that you need to prove something?
If you don't understand how the underlying machine works, how will you
be able to do anything but be at the mercy of tech support when
something unexpected happens?
If you don't understand tail recursion, how will you know that you need
it, or, having it, know that it changes the question of whether or not
to use a recursive procedure?
The problem is that training someone for the basics is not enough. In
order to be truly successful, you need to know about the advanced stuff,
too, even if it is only to know when a solution requires someone else to
help.
>>>>Misses the point again.
>>>>The ability to think recursively is an important skill for a programmer
>>>>and indeed problem solvers at large.
>>>
>>>Yes, it's very useful. And you can learn it from Java, or Basic for
>>>that matter.
>
>>But the fact is your average Java programmer can't parse an abritarily
>>nested regular expression and can't grok XSLT because they ain't used
>>to thinking recursively. Why. Because they work in languages that lets
>>them work around having to.
>
> When they need to learn it, they will. Hopefully employers will choose
> to hire staff capable of doing or learning to do what they need,
> whether that includes the above things or not.
Which is exactly why Java is a bad language to use for teaching. It
_doesn't_ teach them the skills they need to handle new situations.
> Though if their teachers haven't taught them the basics, I would blame
> them rather than the language.
Except that Java doesn't have the expressibility to do so.
Jonathan Bartlett
> wooks wrote:
> ) do you also climb a step and remove it?
>
> Are you intentionally being stupid ?
>
> ) p=p->next is the same order of hack as p=p+1.
>
> If your pet peeve is that the assignment operator looks unnatural,
> then just say so. A variable that changes its value is completely
> natural to a computer.
It's natural to a computer, but that doesn't make it good design. See:
http://www-128.ibm.com/developerworks/linux/library/l-recurs.html
Basically, redefining the value of a variable is one of the most common
sources of bugs, at least in my estimation.
Willem
) It's natural to a computer, but that doesn't make it good design. See:
)
) http://www-128.ibm.com/developerworks/linux/library/l-recurs.html
)
) Basically, redefining the value of a variable is one of the most common
) sources of bugs, at least in my estimation.
There is a difference between changing the value and redefining it,
so I can't be sure what you mean by this.
But given that changing the value of a variable is one of the most common
occurrences in a program, it's no wonder that it is also the most common
source of bugs.
Chris Dams
"wooks" <woo...@hotmail.com> writes:
>BTW none of these techniques are available in XSLT. What then?
XSLT is a very limited language. How would one write and subsequently use
a random number generator in XSLT?
Best,
Chris
wooks
The reason that I keep using XSLT as an example is because it is a
functional or at least functional like language that is widely used in
what Gerry would call the "real world" and there is a fairly good
chance of a Java programmer being exposed to it.
Richard Harter
>Lists are recursively defined structures. Therefore recursion is the
>most suitable and appropriate solution for problems that involve lists
>and structures that derive from lists (arrays, stacks etc).
As a side note this is a faulty argument. One may use a recursive
definition to define a list, but it isn't obligatory. You can define
it as an ordered set, as the image of a function on the integers, and
in sundry other ways. (Pedant's observation - recursion cannot be
avoided in the definition game; you need it to get the integers.)
Regardless of whether we define lists recursively it doesn't at all
follow that recursion is "the most suitable and appropriate solution
for problems that involve lists and structures that derive from lists
(arrays, stacks etc)".
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
The eternal revolution has its needs - its slogans to be chanted,
its demonstrations to be held, its children to eat.
Michael Wojcik
In article <HaBvf.5024$fO5...@newssvr33.news.prodigy.com>, "Phlip" <phli...@yahoo.com> writes:
> Arthur J. O'Dwyer wrote:
>
> > (FWIW, I've seen C knowledge tested with the vocabulary model, too;
> > Nvidia asks "what does 'volatile' mean?" when talking with prospective
> > coders.)
>
> It means the compiler won't optimize the variable because things outside the
> compiler's understanding might change it.
But, of course, it doesn't, in the context Arthur named ("C know-
ledge"). In C, all "volatile" means is that "each access to a
volatile-qualified variable must be performed in accordance with the
semantics of the abstract machine", but since the C standard makes
"access" an implementation-defined activity in this context,
"volatile" doesn't mean anything at all, strictly speaking.
In practice, typical implementations do disable various optimizations
when operating on volatile-qualified objects, but that's a QOI issue,
not anything governed by the standard.
This has real consequences, such as the proliferation of patterns
that are not thread-safe even with liberal sprinklings of "volatile"
on various common implementations - double-checked locking being the
canonical example.
Perhaps it's not such a bad question after all.
--
Michael Wojcik michael...@microfocus.com
Against all odds, over a noisy telephone line, tapped by the tax authorities
and the secret police, Alice will happily attempt, with someone she doesn't
trust, whom she can't hear clearly, and who is probably someone else, to
fiddle her tax return and to organise a coup d'etat, while at the same time
minimising the cost of the phone call. -- John Gordon
Randy Howard
(in article <dpuj3...@news2.newsguy.com>):
> In practice, typical implementations do disable various optimizations
> when operating on volatile-qualified objects, but that's a QOI issue,
> not anything governed by the standard.
>
> This has real consequences, such as the proliferation of patterns
> that are not thread-safe even with liberal sprinklings of "volatile"
> on various common implementations - double-checked locking being the
> canonical example.
>
> Perhaps it's not such a bad question after all.
Anytime you see "volatile" and "thread-safe" in the same
paragraph, warning flares should go off. If you are writing
threaded code, and think that volatile helps at all in that
regard, you are probably going down the wrong path.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
How 'bout them Horns?
Walter Bright
"wooks" <woo...@hotmail.com> wrote in message
news:1136648171.2...@g14g2000cwa.googlegroups.com...
> The fact is the mental model humans adopt to doing iterative things is
> a recursive one.
... and ...
> But the fact is your average Java programmer can't parse an abritarily
> nested regular expression and can't grok XSLT because they ain't used
> to thinking recursively. Why. Because they work in languages that lets
> them work around having to.
You seem to be arguing that recursive algorithms are both innately natural
and something unnatural that one tries to avoid. Sounds contradictory.
joh...@eskimo.com
> ) sources of bugs, at least in my estimation.
>
> There is a difference between changing the value and redefining it,
> so I can't be sure what you mean by this.
>
> But given that changing the value of a variable is one of the most common
> occurrences in a program, it's no wonder that it is also the most common
> source of bugs.
The reason that it is the source of bugs is that it leaves your
variables in a transitory state, and when you go back and update your
program it is not always clear when your variables are self-consistent
or in a transitory state.
If you never modify existing variables, you never have this problem.
Variable modification can be eliminated for the most part by replacing
looping constructs with either higher-order functions (like foreach) or
tail-recursive constructs. If you need an intermediate calculation, it
is better to create a new variable than to re-use an existing one.
Doing these things will aid you in keeping variables self-consistent
while in complex loops. And, if you are in a language that supports
tail-call elimination, it should not add any extra overhead.
wooks
Richard Harter wrote:
> On 8 Jan 2006 03:06:06 -0800, "wooks" <woo...@hotmail.com> wrote:
>
>
> >Lists are recursively defined structures. Therefore recursion is the
> >most suitable and appropriate solution for problems that involve lists
> >and structures that derive from lists (arrays, stacks etc).
>
> As a side note this is a faulty argument. One may use a recursive
> definition to define a list, but it isn't obligatory.
but I didn't say it was obligatory.
> You can define
> it as an ordered set, as the image of a function on the integers, and
> in sundry other ways. (Pedant's observation - recursion cannot be
> avoided in the definition game; you need it to get the integers.)
>
Yes you can. My questions would be
why would you want to - if you have a simple and natural ready made
definition.
> Regardless of whether we define lists recursively it doesn't at all
> follow that recursion is "the most suitable and appropriate solution
> for problems that involve lists and structures that derive from lists
> (arrays, stacks etc)".
>
It does follow..
Sure you can define it other ways -
could be an optimisation (premature?).
could be that the person doesn't understand recursion.
There's always a price to pay.
If you can hand on heart say that you have figured out all the
implications of straying from the natural definition (what classes of
problem am I making more difficult/impossible to solve; how scalable is
this definition), then fine.
The fact is most people don't figure this stuff this is an industry
prone to premature optimisations and the questions I have posed
usually don't get considered until late in the game .... usually too
late.
wooks
I am definitely not saying the latter, there must have been either a
miscommunication or a misunderstanding from one of us.
Willem
)> You can define
)> it as an ordered set, as the image of a function on the integers, and
)> in sundry other ways. (Pedant's observation - recursion cannot be
)> avoided in the definition game; you need it to get the integers.)
)>
)
) Yes you can. My questions would be
)
) why would you want to - if you have a simple and natural ready made
) definition.
Because the recursive definition is not simple, and natural ready made.
It only seems that way to you. To other people, another definition is
much more simple, and natural ready made.
' A linked list is a set of items where each item contains a pointer
to the next item. '
See ? Simple. Natural. No recursion.
wooks
Willem wrote:
> wooks wrote:
> )> You can define
> )> it as an ordered set, as the image of a function on the integers, and
> )> in sundry other ways. (Pedant's observation - recursion cannot be
> )> avoided in the definition game; you need it to get the integers.)
> )>
> )
> ) Yes you can. My questions would be
> )
> ) why would you want to - if you have a simple and natural ready made
> ) definition.
>
> Because the recursive definition is not simple, and natural ready made.
> It only seems that way to you. To other people, another definition is
> much more simple, and natural ready made.
>
> ' A linked list is a set of items where each item contains a pointer
> to the next item. '
>
> See ? Simple. Natural. No recursion.
1. you haven't defined what a pointer is.
2. You need 2 entities to define 1 thing.
3. what if there is no next item to point to.
4. what can be "pointed to" - another linked list or another item.
5. if I can't point to another linked list how do I implement nested
structures.
6. if I can point to another linked list then how do I differentiate
between a pointer to a list and a pointer to another item.
Willem
)> It only seems that way to you. To other people, another definition is
)> much more simple, and natural ready made.
)>
)> ' A linked list is a set of items where each item contains a pointer
)> to the next item. '
)>
)> See ? Simple. Natural. No recursion.
wooks wrote:
) 1. you haven't defined what a pointer is.
I don't need to, people already know what it is.
Only mathematicians rigidly define everything.
) 2. You need 2 entities to define 1 thing.
So what ? They're entities thet most people already understand.
Remember, we are talking about *natural* definitions here.
Or does 'natural' have some weird other meaning in mathematics ?
) 3. what if there is no next item to point to.
There are different solutions for this. For example, you could point back
to the first item.
) 4. what can be "pointed to" - another linked list or another item.
Another item. Odd question, it sais so right there in my definition.
) 5. if I can't point to another linked list how do I implement nested
) structures.
You mean a linked list inside a linked list ? Each item in a linked list
has a data field that can contain anything you want, including another
linked list.
) 6. if I can point to another linked list then how do I differentiate
) between a pointer to a list and a pointer to another item.
See above.
wooks
Willem wrote:
> )> Because the recursive definition is not simple, and natural ready made.
> )> It only seems that way to you. To other people, another definition is
> )> much more simple, and natural ready made.
> )>
> )> ' A linked list is a set of items where each item contains a pointer
> )> to the next item. '
> )>
> )> See ? Simple. Natural. No recursion.
>
> wooks wrote:
>
> ) 1. you haven't defined what a pointer is.
>
> I don't need to, people already know what it is.
> Only mathematicians rigidly define everything.
>
there are no pointers in Java. Lack of understanding about pointers
constitutes the other half of the point that Spolsky's was making.
only hackers toss out sloppy definitions.
> ) 2. You need 2 entities to define 1 thing.
>
> So what ? They're entities thet most people already understand.
no they are not - see Spolsky.
> Remember, we are talking about *natural* definitions here.
what is natural about using 2 entities to define 1 thing
> Or does 'natural' have some weird other meaning in mathematics ?
>
no but it seems to have a weird meaning to you.
> ) 3. what if there is no next item to point to.
>
> There are different solutions for this. For example, you could point back
> to the first item.
>
if there are different solutions then its not simple. What is natural
about pointing back to yourself - its simply a manifestation of an
unnatural implementation.
> ) 4. what can be "pointed to" - another linked list or another item.
>
> Another item. Odd question, it sais so right there in my definition.
>
not odd if you are thinking beyond a simple linear list and fwiw your
definition is not clear on the point.
> ) 5. if I can't point to another linked list how do I implement nested
> ) structures.
>
> You mean a linked list inside a linked list ? Each item in a linked list
> has a data field that can contain anything you want, including another
> linked list.
>
your definition doesn't say anything about data fields. in that case
you had better define item.
> ) 6. if I can point to another linked list then how do I differentiate
> ) between a pointer to a list and a pointer to another item.
>
> See above.
>
above says it can contain anything you want. it doesn't say how to
differentiate.
Willem
)> ) 1. you haven't defined what a pointer is.
)>
)> I don't need to, people already know what it is.
)> Only mathematicians rigidly define everything.
)>
)
) there are no pointers in Java. Lack of understanding about pointers
) constitutes the other half of the point that Spolsky's was making.
)
) only hackers toss out sloppy definitions.
Everybody but mathematicians toss out sloppy definitions.
If I want to explain to a layman what a linked list is, I'm not going
to go with tuples and a recursive definition.
)> ) 2. You need 2 entities to define 1 thing.
)>
)> So what ? They're entities thet most people already understand.
)
) no they are not - see Spolsky.
What people don't understand is how pointers work in computer languages.
)> Remember, we are talking about *natural* definitions here.
)
) what is natural about using 2 entities to define 1 thing
What is unnatural about it ?
I could also have said 'a linked list is a list of item where each item
links to the next.'
)> Or does 'natural' have some weird other meaning in mathematics ?
)
) no but it seems to have a weird meaning to you.
To me it has to do with the way an average human would think.
Average humans don't think recursively, as far as I know.
At best, they think hierarchically.
)> ) 3. what if there is no next item to point to.
)>
)> There are different solutions for this. For example, you could point back
)> to the first item.
)>
)
) if there are different solutions then its not simple. What is natural
) about pointing back to yourself - its simply a manifestation of an
) unnatural implementation.
It is irrelevant to the understanding of how a linked list works.
How you implement ending the last item is an implementation detail.
)> ) 5. if I can't point to another linked list how do I implement nested
)> ) structures.
)>
)> You mean a linked list inside a linked list ? Each item in a linked list
)> has a data field that can contain anything you want, including another
)> linked list.
)
) your definition doesn't say anything about data fields. in that case
) you had better define item.
Defining what an item is is irrelevant to understanding what a linked
list is. It could be several different things, for that matter.
If you want to make nested structures, then ask about nested structures.
Steve O'Hara-Smith
"wooks" <woo...@hotmail.com> wrote:
True but the Java programmers I've known who got exposed to XSLT
ran screaming to the extensions that let you embed Java code in it.
I think XSLT is the single most hideous and inconvenient programming
language invented far more than perl it deserves the label "write only".
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
Steve O'Hara-Smith
joh...@eskimo.com wrote:
> The reason that it is the source of bugs is that it leaves your
> variables in a transitory state, and when you go back and update your
> program it is not always clear when your variables are self-consistent
> or in a transitory state.
>
> If you never modify existing variables, you never have this problem.
Of course if you can't modify it the name variable is hardly
justified.
Gerry Quinn
> Gerry Quinn wrote:
> >A list is a data structure, and different means can
> > be used to define it.
>
> The floor is yours. Give us your definition.
An ordered set of data objects.
> > Actually it is an example of recursion. A function (+1) is called
> > repeatedly to modify y.
> no it's not.
A function (+1) taking y as a parameter is called repeatedly, leading
to successive modifications of y. Sounds like recursion to me.
> > Iteration usually looks like:
> > for( int i = 0; i < maxVal; i++ ) {}
> >
> > ..or
> >
> > for ( iterator i = begin(); i != end(); i++ ) {}
> >
> Right now tell me the difference between i++ and i=i+1?
None. You can use +1 in iterative contexts too.
> BTW none of these techniques are available in XSLT. What then?
I don't know as I've never used it. It seems like a very limited
special purpose language - maybe they are not needed.
> > The above succintly indicate that all elements of a set are to be
> > processed, and the sequence in which this will occur. The first
> > includes a counter, which is often very useful.
> But it isn't so succint when some of the elements of the sets are sets
> themselves. And supposing this nesting could be n levels deep. What
> then?
There are well known iterative mechanisms for fixed small n. Or you
can use recursion if that is more appropriate. I've nothing *against*
recursion as a technique - it has many uses.
> > > climb(steps)
> > > if no more steps stop
> > > go up the first step
> > > climb (rest of steps).
> >
> > Once they have learned to walk and count, they do what is best in a
> > given situation. But I would say that they normally do:
> >
> > go to bottom of stairs
> > if ( at top ) stop
> > climb next step
> > repeat
> >
> > This corresponds best to my second example of iteration.
> >
> Whats the difference between your "repeat" and my clim(rest of steps).
The former is iterative, the latter is recursive.
for ( iterator i = begin(); i != end(); i++ )
> > go to bottom of stairs // i = begin()
> > if ( at top ) stop // if i = end() exit
> > climb next step // i++
> > repeat // loop
> > > climb( steps ) // function declaration
> > > if no more steps stop // if at-top stop, else
> > > go up the first step // go up a step
> > > climb (rest of steps). // call this function recursively
> > If functional languages were so great, people would use them. That is
> > the 'popularity' argument, and it is quite a valid one.
> It's got alot to do with the same reasons why there isn't a
> Lisp/Scheme/Haskell/ML for Dummies/Idiots etc. They require a fair
> degree of mathematical sophistication.
So does special relativity, and there is one for that.
> Nevertheless here is an opportunity to better inform yourself.
>
> http://portal.acm.org/citation.cfm?id=286387
They want money.
> > > The main reasons why imperative programming languages are in more
> > > widespread use have nothing to do with them being better suited for
> > > "real work", or being "serious languages". It's because they are
> > > accessible to the mathematically unsophisticated which is a
> > > description that probably applies to the majority of people employed
> > > as programmers today.
> >
> > In other words, they are suited to real work by real people. And
> > frankly, if a language is easier to use for ordinary folks, it is
> > probably easier to use for everyone.
> >
> Can you drop the "real" nonsense.
You used it first.
> There are alot of ordinary folk writing crappy buggy software that
> keeps crashing.
> The ordinary "real" arguments are fine if you are solving a genuinely
> simple problem.
> Ordinary "real" folk didn't create the language that enables you to
> come here and say what you are saying today. Check out the role that
> Guy Steele had in inventing Java. Steele was an MIT student and one of
> the inventors of Scheme.
I am not wild about Java, but I recognise its popularity. According to
Wikipedia, Steele joined the Java team after the language had been
designed. But what matter?
> > > The whole point Spolsky is making is that teaching people in Java means
> > > that the odds are they won't practice these techniques in the first
> > > place.
> >
> > And it's the same half-baked point that has been made for millennia,
> > when those who consider themselves as members of an intellectual elite
> > get worried that their inferiors are achieving much the same things as
> > they can, without having bothered with the elaborate membership
> > initiations. "They must be stopped", they wail. "How can the sacred
> > work be left in the hands of ignorami?".
>
> What has that got to do with whether Java programmers are well
> practised in recursion.
It has to do with the fact that there's no reason they can't learn
about recursion through Java. In fact, if they don't, they are being
incompetently taught.
> > > But the fact is your average Java programmer can't parse an abritarily
> > > nested regular expression and can't grok XSLT because they ain't used
> > > to thinking recursively. Why. Because they work in languages that lets
> > > them work around having to.
> >
> > When they need to learn it, they will.
>
> What you really mean is that they'll continue with their buggy
> iterative hacks.
> How can you know when it is appropriate to apply a technique that you
> haven't even learnt.
Knowing that is one of the things you are supposed to learn in college.
But to be honest, any teenage Basic hacker learns about recursion. I
can't imagine that Java students don't, and if they don't it's the
fault of their teachers and/or their own lack of interest in their
subject, not the language.
> > Hopefully employers will choose
> > to hire staff capable of doing or learning to do what they need,
> > whether that includes the above things or not.
> >
> Thats why Spolsky wants to hire people that can write Scheme/Lisp,
> because he can be assured they have the necessary capabilities.
Cool - if all employers come to feel the same I assume they will become
as popular as Java.
- Gerry Quinn
Gerry Quinn
says...
> > And it's the same half-baked point that has been made for millennia,
> > when those who consider themselves as members of an intellectual elite
> > get worried that their inferiors are achieving much the same things as
> > they can, without having bothered with the elaborate membership
> > initiations. "They must be stopped", they wail. "How can the sacred
> > work be left in the hands of ignorami?".
>
> I think the problem isn't that people are looking for an intellectual
> elite (though some might), it's that they are looking for people who
> have an understanding of the whole picture. While a given feature may
> be useful for 90% of programming projects, how will you know when you
> have hit the 10% that you need another tool for, unless you know about
> such tools and where they are used?
As I said in another post, that's exactly what you are supposed to
learn in college. It's far more important than what language you are
familiar with.
> If you don't understand how program proofs work, how will you even know
> that you need to prove something?
The question of whether proofs are needed seems unrelated to the
question of how they work.
> If you don't understand how the underlying machine works, how will you
> be able to do anything but be at the mercy of tech support when
> something unexpected happens?
Certainly there's no harm understanding things, be they about the
hardware, or about the Java virtual machine.
> If you don't understand tail recursion, how will you know that you need
> it, or, having it, know that it changes the question of whether or not
> to use a recursive procedure?
That's a bit like the 'proof' question. What you need to know is what
it delivers in terms of time and space efficiency. Then if for some
problem you wanted to use recursion rather than iteration, you could
evaluate whether that was feasible.
> > When they need to learn it, they will. Hopefully employers will choose
> > to hire staff capable of doing or learning to do what they need,
> > whether that includes the above things or not.
>
> Which is exactly why Java is a bad language to use for teaching. It
> _doesn't_ teach them the skills they need to handle new situations.
Why not? Certainly there's no difficulty using recursion functions in
Java.
> > Though if their teachers haven't taught them the basics, I would blame
> > them rather than the language.
>
> Except that Java doesn't have the expressibility to do so.
There are some things that Java doesn't do, and some things that Lisp
doesn't do. If you learn either one and nothing else, you will have a
very limited understanding.
Ironically, the original argument was that by not supporting iteration
- in other words because of their limited expressiveness - certain
languages make programmers better. Yet by not supporting pointers,
Java is supposed to make them worse. And its support of recursion
doesn't count, for some reason. Poor old Java just doesn't seem able
to win.
- Gerry Quinn
Chris Dollin
> On 9 Jan 2006 22:33:49 -0800
> joh...@eskimo.com wrote:
>
>> The reason that it is the source of bugs is that it leaves your
>> variables in a transitory state, and when you go back and update your
>> program it is not always clear when your variables are self-consistent
>> or in a transitory state.
>>
>> If you never modify existing variables, you never have this problem.
>
> Of course if you can't modify it the name variable is hardly
> justified.
It is, however, traditional, and predates (ttbomk) computers. I think
you're confusing "variable" with "mutable state"; "variable" need
not mean "can be changed" but can mean "is not bound to a specific
value".
--
Chris "believes seventeen improbable things before coffee" Dollin
Seventeen, forty-two - what else is there?
wooks
Willem wrote:
> wooks wrote:
> )> ) 1. you haven't defined what a pointer is.
> )>
> )> I don't need to, people already know what it is.
> )> Only mathematicians rigidly define everything.
> )>
> )
> ) there are no pointers in Java. Lack of understanding about pointers
> ) constitutes the other half of the point that Spolsky's was making.
> )
> ) only hackers toss out sloppy definitions.
>
> Everybody but mathematicians toss out sloppy definitions.
> If I want to explain to a layman what a linked list is, I'm not going
> to go with tuples and a recursive definition.
>
A list of items is either empty (the empty list).
Or the concatenation of an item and a list.
There that didn't hurt.
I've not met a layman yet who needs to know what a linked list is.
> )> ) 2. You need 2 entities to define 1 thing.
> )>
> )> So what ? They're entities thet most people already understand.
> )
> ) no they are not - see Spolsky.
>
> What people don't understand is how pointers work in computer languages.
>
Nor do they understand what to do when there is no next item to point
to.
> )> Remember, we are talking about *natural* definitions here.
> )
> ) what is natural about using 2 entities to define 1 thing
>
> What is unnatural about it ?
>
because in the real world the item (whatever it is) does not consist of
2 entities, neither does it contain a pointer. Those are things you
have introduced to support your hack.
> I could also have said 'a linked list is a list of item where each item
> links to the next.'
>
but loads of lists in the real world don't link. You have a pile of
invoices that you are processing. If you take out one of the invoices
you don't have to worry about updating the links. But in your
representation you do.
Thats another complication that you have introduced to support your
hacks.
> )> Or does 'natural' have some weird other meaning in mathematics ?
> )
> ) no but it seems to have a weird meaning to you.
>
> To me it has to do with the way an average human would think.
average humans do not associate pointers with list.
> Average humans don't think recursively, as far as I know.
yes they do. they climb steps recursively, they mark papers
recursively. they read books recursively.
You don't really know what recursively means do you.
> At best, they think hierarchically.
>
> )> ) 3. what if there is no next item to point to.
> )>
> )> There are different solutions for this. For example, you could point back
> )> to the first item.
> )>
> )
> ) if there are different solutions then its not simple. What is natural
> ) about pointing back to yourself - its simply a manifestation of an
> ) unnatural implementation.
>
> It is irrelevant to the understanding of how a linked list works.
> How you implement ending the last item is an implementation detail.
>
1. your definition introduces complications that are not present in the
real world.
2. when I ask you to explain things the answers I get are ... there are
a number of ways to do this or it's irrelevant.
3. You have not demonstrated how this structure can scale to accurately
model anything more complicated than a linear list.
> )> ) 5. if I can't point to another linked list how do I implement nested
> )> ) structures.
> )>
> )> You mean a linked list inside a linked list ? Each item in a linked list
> )> has a data field that can contain anything you want, including another
> )> linked list.
> )
> ) your definition doesn't say anything about data fields. in that case
> ) you had better define item.
>
> Defining what an item is is irrelevant to understanding what a linked
> list is. It could be several different things, for that matter.
>
You probably won't believe this but my response to the previous
subpoint was written before I read this. Strangely prophetic.
> If you want to make nested structures, then ask about nested structures.
Why should I when I have given you a definition of a list that already
supports nested structures. It's your problem if you don't want to
accept it.
wooks
Steve O'Hara-Smith wrote:
> On 9 Jan 2006 22:33:49 -0800
> joh...@eskimo.com wrote:
>
> > The reason that it is the source of bugs is that it leaves your
> > variables in a transitory state, and when you go back and update your
> > program it is not always clear when your variables are self-consistent
> > or in a transitory state.
> >
> > If you never modify existing variables, you never have this problem.
>
> Of course if you can't modify it the name variable is hardly
> justified.
>
Do you remember x==(-b+/-sqrt(b^2-4ac))/(2a).
It's the solution to a quadratic equation. It has variables a, b and c.
Once you assign values to a,b and c, do they change?.
wooks
Gerry Quinn wrote:
> In article <1136821381.8...@g14g2000cwa.googlegroups.com>,
> woo...@hotmail.com says...
> > Gerry Quinn wrote:
>
> > >A list is a data structure, and different means can
> > > be used to define it.
> >
> > The floor is yours. Give us your definition.
>
> An ordered set of data objects.
>
but lots of lists are not ordered. why does your definition require
them to be ordered.
> > > Actually it is an example of recursion. A function (+1) is called
> > > repeatedly to modify y.
>
> > no it's not.
>
> A function (+1) taking y as a parameter is called repeatedly, leading
> to successive modifications of y. Sounds like recursion to me.
>
wheres your base case?
> > > Iteration usually looks like:
> > > for( int i = 0; i < maxVal; i++ ) {}
> > >
> > > ..or
> > >
> > > for ( iterator i = begin(); i != end(); i++ ) {}
> > >
> > Right now tell me the difference between i++ and i=i+1?
>
> None. You can use +1 in iterative contexts too.
>
> > BTW none of these techniques are available in XSLT. What then?
>
> I don't know as I've never used it. It seems like a very limited
> special purpose language - maybe they are not needed.
>
Interesting solution. Anything that a Java programmer can't understand
is defined out of existence or classed as limited.
Unfortunately it's not the reality.
Now I've made clear in an earlier post why I keep citing XSLT as an
example.
Go to www.jobserve.co.uk and type Java XSLT in your search. I got 4883
jobs.
> > > The above succintly indicate that all elements of a set are to be
> > > processed, and the sequence in which this will occur. The first
> > > includes a counter, which is often very useful.
>
> > But it isn't so succint when some of the elements of the sets are sets
> > themselves. And supposing this nesting could be n levels deep. What
> > then?
>
> There are well known iterative mechanisms for fixed small n. Or you
> can use recursion if that is more appropriate. I've nothing *against*
> recursion as a technique - it has many uses.
>
In other words your solution doesn't scale.
> > > > climb(steps)
> > > > if no more steps stop
> > > > go up the first step
> > > > climb (rest of steps).
> > >
> > > Once they have learned to walk and count, they do what is best in a
> > > given situation. But I would say that they normally do:
> > >
> > > go to bottom of stairs
> > > if ( at top ) stop
> > > climb next step
> > > repeat
> > >
> > > This corresponds best to my second example of iteration.
> > >
> > Whats the difference between your "repeat" and my clim(rest of steps).
>
> The former is iterative, the latter is recursive.
>
I beg to differ. Your example is recursive the thing you are repeating
is the climb steps routine.
> for ( iterator i = begin(); i != end(); i++ )
>
> > > go to bottom of stairs // i = begin()
> > > if ( at top ) stop // if i = end() exit
> > > climb next step // i++
> > > repeat // loop
>
> > > > climb( steps ) // function declaration
> > > > if no more steps stop // if at-top stop, else
> > > > go up the first step // go up a step
> > > > climb (rest of steps). // call this function recursively
>
> > > If functional languages were so great, people would use them. That is
> > > the 'popularity' argument, and it is quite a valid one.
>
>
> > It's got alot to do with the same reasons why there isn't a
> > Lisp/Scheme/Haskell/ML for Dummies/Idiots etc. They require a fair
> > degree of mathematical sophistication.
>
> So does special relativity, and there is one for that.
>
> > Nevertheless here is an opportunity to better inform yourself.
> >
> > http://portal.acm.org/citation.cfm?id=286387
>
> They want money.
>
I'll summarise 2 reasons... the ones that I think are more prevalent.
1. Functional languages do not have the extensive general purpose
libraries.
2. They require a degree of mathematical sophistication which your
average Joe doesn't have.
They are not toy languages and they are certainly more powerful and
more expressive than Java.
> > > > The main reasons why imperative programming languages are in more
> > > > widespread use have nothing to do with them being better suited for
> > > > "real work", or being "serious languages". It's because they are
> > > > accessible to the mathematically unsophisticated which is a
> > > > description that probably applies to the majority of people employed
> > > > as programmers today.
> > >
> > > In other words, they are suited to real work by real people. And
> > > frankly, if a language is easier to use for ordinary folks, it is
> > > probably easier to use for everyone.
> > >
> > Can you drop the "real" nonsense.
>
> You used it first.
>
na na na na na ... jeez.
> > There are alot of ordinary folk writing crappy buggy software that
> > keeps crashing.
> > The ordinary "real" arguments are fine if you are solving a genuinely
> > simple problem.
> > Ordinary "real" folk didn't create the language that enables you to
> > come here and say what you are saying today. Check out the role that
> > Guy Steele had in inventing Java. Steele was an MIT student and one of
> > the inventors of Scheme.
>
> I am not wild about Java, but I recognise its popularity. According to
> Wikipedia, Steele joined the Java team after the language had been
> designed. But what matter?
>
If you are determined to take nothing from what I said it's a matter
for you.
> > > > The whole point Spolsky is making is that teaching people in Java means
> > > > that the odds are they won't practice these techniques in the first
> > > > place.
> > >
> > > And it's the same half-baked point that has been made for millennia,
> > > when those who consider themselves as members of an intellectual elite
> > > get worried that their inferiors are achieving much the same things as
> > > they can, without having bothered with the elaborate membership
> > > initiations. "They must be stopped", they wail. "How can the sacred
> > > work be left in the hands of ignorami?".
> >
> > What has that got to do with whether Java programmers are well
> > practised in recursion.
>
> It has to do with the fact that there's no reason they can't learn
> about recursion through Java. In fact, if they don't, they are being
> incompetently taught.
>
I've just given you the reasons that they don't learn it and one of the
manifestations. You've chosen to ignore them and continue to repeat the
same mantra. Not interested in arguing for the sake of it - it's a
waste of time.
> > > > But the fact is your average Java programmer can't parse an abritarily
> > > > nested regular expression and can't grok XSLT because they ain't used
> > > > to thinking recursively. Why. Because they work in languages that lets
> > > > them work around having to.
> > >
> > > When they need to learn it, they will.
> >
> > What you really mean is that they'll continue with their buggy
> > iterative hacks.
> > How can you know when it is appropriate to apply a technique that you
> > haven't even learnt.
>
> Knowing that is one of the things you are supposed to learn in college.
>
> But to be honest, any teenage Basic hacker learns about recursion. I
> can't imagine that Java students don't, and if they don't it's the
> fault of their teachers and/or their own lack of interest in their
> subject, not the language.
>
Sigh.
> > > Hopefully employers will choose
> > > to hire staff capable of doing or learning to do what they need,
> > > whether that includes the above things or not.
> > >
> > Thats why Spolsky wants to hire people that can write Scheme/Lisp,
> > because he can be assured they have the necessary capabilities.
>
> Cool - if all employers come to feel the same I assume they will become
> as popular as Java.
>
Once upon a time the same thing was said of COBOL......
Jonathan Bartlett
> doesn't do. If you learn either one and nothing else, you will have a
> very limited understanding.
That is precisely the idea under question here. Noone is saying that
people shouldn't learn Java. But there are many schools, even
well-respected schools, that are teaching Java AND NOTHING ELSE.
> Ironically, the original argument was that by not supporting iteration
> - in other words because of their limited expressiveness - certain
> languages make programmers better. Yet by not supporting pointers,
> Java is supposed to make them worse. And its support of recursion
> doesn't count, for some reason. Poor old Java just doesn't seem able
> to win.
Again, it is the restriction to Java-only that is the problem. But as
to recursion, Java does not do proper tail recursion.
I personally think that the best approach is to teach assembly language,
Scheme, and then some standard language, so you get to learn programming
from a variety of perspectives -- from the machine up, from the concept
down, and from the toolset out.
Steve O'Hara-Smith
Chris Dollin <ke...@hpl.hp.com> wrote:
> Steve O'Hara-Smith wrote:
>
> > Of course if you can't modify it the name variable is hardly
> > justified.
>
> It is, however, traditional, and predates (ttbomk) computers. I think
> you're confusing "variable" with "mutable state"; "variable" need
> not mean "can be changed" but can mean "is not bound to a specific
> value".
We use different dictionaries - I can't find one with your
meaning of variable, all of mine have it as "likely to change" or
"A quantity capable of assuming any of a set of values". I tend to
use the word "constant" for things that cannot change.
Antoon Pardon
I change them or assign new values to them when I start solving the next
equation.
--
Antoon Pardon
Chris Dollin
> On Tue, 10 Jan 2006 13:28:05 +0000
> Chris Dollin <ke...@hpl.hp.com> wrote:
>
>> Steve O'Hara-Smith wrote:
>>
>> > Of course if you can't modify it the name variable is hardly
>> > justified.
>>
>> It is, however, traditional, and predates (ttbomk) computers. I think
>> you're confusing "variable" with "mutable state"; "variable" need
>> not mean "can be changed" but can mean "is not bound to a specific
>> value".
>
> We use different dictionaries - I can't find one with your
> meaning of variable, all of mine have it as "likely to change" or
> "A quantity capable of assuming any of a set of values".
That latter meaning pretty much the same as "is not bound to a
specific value", which is what I said.
In a purely functional language, some variables are immutable but
are not bound to a specific value; witness:
let inc x = x + 1
`x` is a variable, but it is not bound to a specific value, at least
not in this expression. Similarly in a list comprehension we can
write something like
[x + 1, x - 1 | x <- [16, 41]]
where again `x` is a variable and yet is immutable.
> I tend to use the word "constant" for things that cannot change.
Well, so do I. But I wouldn't use it for the x's above.
S'all to do with quantifier scope if you don't have mutable store.
Willem
) A list of items is either empty (the empty list).
) Or the concatenation of an item and a list.
)
) There that didn't hurt.
That's the definition of a list, not of a _linked_ list.
A list of items is an ordered collection of items. Sheesh.
)> )> Remember, we are talking about *natural* definitions here.
)> )
)> ) what is natural about using 2 entities to define 1 thing
)>
)> What is unnatural about it ?
)
) because in the real world the item (whatever it is) does not consist of
) 2 entities, neither does it contain a pointer. Those are things you
) have introduced to support your hack.
In the real world, there are no *linked* lists. I need two entities
to make it a *linked* list.
)> To me it has to do with the way an average human would think.
)
) average humans do not associate pointers with list.
Average humans that know about linked lists *do* associate pointers
with *linked* lists. Average humans would also equate normal lists
more naturally with arrays.
)> Average humans don't think recursively, as far as I know.
)
) yes they do. they climb steps recursively, they mark papers
) recursively. they read books recursively.
They climb steps iteratively, they mark papers iteratively,
and they read books iteratively. A human usually repeats the
same action until he is done. repeating the same action until
you are done is called iteration.
) You don't really know what recursively means do you.
If you are going down to such a basic level of what recursion means,
then you have lost the meaning it has in a programming context.
Yes, you can call 'repeat an action until you are done' recursion. But
to claim it is a more natural way to program 'repeating an action' than
to use the repeat idiom given by the programming language is nonsense.
) 1. your definition introduces complications that are not present in the
) real world.
That's because it is the definition of a *linked* list.
In the real world, linked lists are few and far between.
) 2. when I ask you to explain things the answers I get are ... there are
) a number of ways to do this or it's irrelevant.
That's because there are indeed a number of ways to do them and/or they
are indeed irrelevant.
Willem
) Gerry Quinn wrote:
)> An ordered set of data objects.
)
) but lots of lists are not ordered. why does your definition require
) them to be ordered.
Can you give an example of a list that is not ordered, then ?
Your recursive definition also implies an ordering.
Steve O'Hara-Smith
"wooks" <woo...@hotmail.com> wrote:
> Steve O'Hara-Smith wrote:
> > On 9 Jan 2006 22:33:49 -0800
> > Of course if you can't modify it the name variable is hardly
> > justified.
> >
>
> Do you remember x==(-b+/-sqrt(b^2-4ac))/(2a).
Well with = not == - I don't recall it being a comparison :)
> It's the solution to a quadratic equation. It has variables a, b and c.
> Once you assign values to a,b and c, do they change?.
Sure they change - every time the quadratic I want the roots
of changes.
Richard Harter
>
>Richard Harter wrote:
>> On 8 Jan 2006 03:06:06 -0800, "wooks" <woo...@hotmail.com> wrote:
>>
>>
>> >Lists are recursively defined structures. Therefore recursion is the
>> >most suitable and appropriate solution for problems that involve lists
>> >and structures that derive from lists (arrays, stacks etc).
>>
>> As a side note this is a faulty argument. One may use a recursive
>> definition to define a list, but it isn't obligatory.
>
>but I didn't say it was obligatory.
This raises Clinton's question, that depends on what "is" is, or in
this case, what "are" is. You say lists *are* recursively definted
structures. If you merely mean that lists can be thought of as
recursively defined structures, then, yes, then you aren't saying that
it was obligatory. However I read your statement as an assertion that
the correct way to describe lists, the essence so to speak, is
recursively. If you mean something like "A natural way to treat lists
is to view them as recursively defined structures and let your
methodology follow the recursive structure." then no one would argue
with you.
>
>> You can define
>> it as an ordered set, as the image of a function on the integers, and
>> in sundry other ways. (Pedant's observation - recursion cannot be
>> avoided in the definition game; you need it to get the integers.)
>>
>
>Yes you can. My questions would be
>
> why would you want to - if you have a simple and natural ready made
>definition.
Because there are other definitions that may be equally simple and
natural that have their own merits. The wise programmer is not
content to know only one methodology and one solution.
>
>
>> Regardless of whether we define lists recursively it doesn't at all
>> follow that recursion is "the most suitable and appropriate solution
>> for problems that involve lists and structures that derive from lists
>> (arrays, stacks etc)".
>>
>
>It does follow..
This is a mere naked assertion (one doesn't prove things by shouting
loudly and puffing one's chest out.) For it to follow you actually
have to show that it follows.
>
>Sure you can define it other ways -
>
>could be an optimisation (premature?).
>could be that the person doesn't understand recursion.
Or it might be none of these. It might be that a different definition
provides a cleaner approach.
In any event, you are missing the point - it doesn't follow
automatically that recursion is the right solution just because one is
defining lists recursively. Modelling a definition in a solution is a
natural sort of thing to do; it isn't necessarily the most suitable
solution.
>
>There's always a price to pay.
No matter what you do, there always is a price to pay?
>If you can hand on heart say that you have figured out all the
>implications of straying from the natural definition (what classes of
>problem am I making more difficult/impossible to solve; how scalable is
>this definition), then fine.
Oh dear. Here we go again with "the natural definition". Have you
asked the same question about your "natural definition"? Have you
considered that there might not be any approach that is a universal
silver bullet?
>The fact is most people don't figure this stuff this is an industry
>prone to premature optimisations and the questions I have posed
>usually don't get considered until late in the game .... usually too
>late.
I agree that all too often that people don't consider the consequences
of their choices until too late. I hold that they should consider the
consequences rather than swallowing snake oil.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
The eternal revolution has its needs - its slogans to be chanted,
its demonstrations to be held, its children to eat.
blm...@myrealbox.com
Phlip <phli...@yahoo.com> wrote:
>Gerry Quinn wrote:
>
>> It's ironic to see the somewhat trivial concepts of pointers and
>> recursion feted as challenging, purely on the basis that certain
>> programmers are unfamiliar with their use. [And surely Java supports
>> recursion as well as any language?]
>
>Joel's point is real programmers comprehend pointers, so pointers make a
>good test to identify real programmers.
>
>Not to defend Java, but comprehending virtual methods makes as good a
>test...
Further, one of the examples he gives in the main article of using
pointers (linked-list manipulation) could perfectly well be written
in Java. It could be that some programs that use Java as a teaching
language don't teach this sort of thing, because it's not often needed
in practice given Java's extensive library of collection classes.
But some do, and it seems to me that this is a pretty good test of
whether one understands pointers. Or does the ability to do arithmetic
on pointers, which AFAIK Java lacks, add something essential?
(I also am not defending the practice of teaching only Java. IMO,
a CS program that teaches only one language, whatever it is, has
missed an important point. But Java seems to me to be a reasonable
language for teaching some things one would want to teach.)
[ snip ]
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
blm...@myrealbox.com
Jonathan Bartlett <joh...@eskimo.com> wrote:
[ snip ]
>In fact, I wrote a book introducing programming using assembly language
>to help establish a more concrete basis for thinking about programming.
> I think sometimes the problem is that most current languages are
>fairly abstract, while pointers are very concrete. The mixing confuses
>people. Teaching them assembly language gives them a full taste for the
>concrete-ness of programming as an enterprise, and then later when they
>learn the more abstract ideas, they will understand the underlying
>mechanisms. You can get my book here:
>
>http://www.cafeshops.com/bartlettpublish.8640017
Ah yes, the book mentioned in your signature:
>Learn to program using Linux assembly language
>http://www.cafeshops.com/bartlettpublish.8640017
I've been curious about what you mean by "Linux assembly language",
and the Web page you reference doesn't make it clearer to me.
I'd have said that "assembly language" is specific to a processor
architecture (examples that come to mind for me are x86, MIPS,
and IBM 370) rather than to an operating system. ?
(Anyone else bothered by this terminology, or am I either nitpicking
or missing the point?)
Richard Harter
>
>Gerry Quinn wrote:
>> In article <1136821381.8...@g14g2000cwa.googlegroups.com>,
>> woo...@hotmail.com says...
>> > Gerry Quinn wrote:
>>
>> > >A list is a data structure, and different means can
>> > > be used to define it.
>> >
>> > The floor is yours. Give us your definition.
>>
>> An ordered set of data objects.
>>
>
>but lots of lists are not ordered. why does your definition require
>them to be ordered.
Cheese. Lists are ordered; order is a fundamental property of lists.
Where do you get this stuff?
Arthur J. O'Dwyer
On Tue, 10 Jan 2006, Willem wrote:
>
[Willem wrote:]
>>> Because the recursive definition is not simple, and natural ready
>>> definition is much more simple, and natural ready made.
>>>
>>> ' A linked list is a set of items where each item contains a pointer
>>>
>>> See ? Simple. Natural. No recursion.
>
> wooks wrote:
> > 1. you haven't defined what a pointer is.
>
> I don't need to, people already know what it is.
> Only mathematicians rigidly define everything.
In fact, most mathematicians don't even try to define everything, and
those who do, fail. Even set theory starts out with axioms (the empty
set, rules for creation of new sets). At some level, you really /do/
have to pick some concepts that "people already know."
Willem picks pointers and structures (records, objects); Wooks picks...
um, lists, I guess. At least, his definition of "list" contains the
word "list" in it. ;) [1]
[1] - No, there's nothing wrong with recursive definitions, but they
don't tell you /how/ to do things. That's the main obstacle to FP from
my point of view, which I think of as more a "Real Programmer" viewpoint
than a "JavaSchools" viewpoint: Knowing that a list can be represented
as (an item plus another list) doesn't tell you how to implement it on
a modern Von Neumann machine. Knowing that a list can be /implemented/
as (a set of items connected by pointers) is much more useful to a
programmer who uses imperative languages --- e.g., anyone who works on
compilers for the higher-level languages Wooks prefers. :)
> ) 3. what if there is no next item to point to.
>
> There are different solutions for this. For example, you could point back
> to the first item.
Pedantry: Typically, you'd "point to nothing" (using a value such as
"nil" or C's "NULL"), or in rare cases point to yourself or point to a
global object designated for the purpose. Pointing back to the first item
sounds like a bad idea, unless you're specifically trying to make a
circularly linked list.
(I see how it would work, except for ugly hackishness when you go to
remove the first item in the list and end up having to update the "next"
pointer of the last item, too!)
-Arthur,
babbling
Willem
)> to the first item.
Arthur wrote:
) Pedantry: Typically, you'd "point to nothing" (using a value such as
) "nil" or C's "NULL"), or in rare cases point to yourself or point to a
) global object designated for the purpose. Pointing back to the first item
) sounds like a bad idea, unless you're specifically trying to make a
) circularly linked list.
I wanted to point out a non-obvious solution. :-)
) (I see how it would work, except for ugly hackishness when you go to
) remove the first item in the list and end up having to update the "next"
) pointer of the last item, too!)
And maybe I was trolling a bit for people to point out how broken it is.
It is broken by the way, I spent several days tracing a bug in someones
code who was using circular linked lists for some obscure reason.
Arthur J. O'Dwyer
On Tue, 10 Jan 2006, Gerry Quinn wrote:
>
> joh...@eskimo.com says...
[Gerry Quinn, IIRC, wrote:]
>>> And it's the same half-baked point that has been made for millennia,
>>> when those who consider themselves as members of an intellectual elite
>>> get worried that their inferiors are achieving much the same things as
>>> they can, without having bothered with the elaborate membership
>>> initiations. "They must be stopped", they wail. "How can the sacred
>>> work be left in the hands of ignorami?".
Not at all. That is, I think you've hit the nail on the head with
respect to the elite's attitude, but somehow you've come to the bizarre
conclusion that "inferior" programmers are indeed achieving "much the
same things" as the good, smart programmers. Would you disagree that
most of the software produced today is extremely poor in quality?
I can't blame Spolsky for making a connection between
A) many college graduates don't display knowledge of basic software
concepts
and
B) the software produced by many college graduates is low-quality
He's saying --- and I agree --- that if you teach students to think
about software in the right way, it will make it easier for them to
write better software later in life.[1]
>> If you don't understand tail recursion, how will you know that you need
>> it, or, having it, know that it changes the question of whether or not
>> to use a recursive procedure?
>
> That's a bit like the 'proof' question. What you need to know is what
> it delivers in terms of time and space efficiency. Then if for some
> problem you wanted to use recursion rather than iteration, you could
> evaluate whether that was feasible.
Here I agree with Gerry. The whole "tail recursion" thing is a complete
and utter red herring in the JavaSchools debate. I didn't know Java had
partial support for TRE, and I still don't care. I don't even care that
Lisp supports TRE. That's an implementation detail, and it doesn't affect
the way students /think/ about programming.
What matters is that Lisp (Scheme, ML) teaches students to use
recursion, because they have to. Java does NOT teach students to use
recursion, because they don't have to. See below.
>>> When they need to learn it, they will. Hopefully employers will choose
>>> to hire staff capable of doing or learning to do what they need,
>>> whether that includes the above things or not.
(Silly. Spolsky's point is that if an interviewer is faced with a
JavaSchool grad, he won't be able to judge the interviewee's capability,
precisely because the interviewee won't be able to demonstrate any grasp
of the concepts it take capability to understand. If Alice understands
pointers and recursion, she'll be able to understand anything, and get
hired. If Bob doesn't understand P&R, he may yet be able to understand
anything, but he won't be able to demonstrate that capacity, and he won't
get hired.)
>> Which is exactly why Java is a bad language to use for teaching. It
>> _doesn't_ teach them the skills they need to handle new situations.
>
> Why not? Certainly there's no difficulty using recursion functions in
> Java.
Certainly. Which means that any highly motivated student will go far.
Duh. We already knew that. Spolsky's trying to make sure that (A) the
completely unmotivated students /don't/ go far, but switch out of a
major that's not their cup of tea; and more importantly, (B) the
somewhat motivated slackers who compose the vast majority of [U.S.]
college students /do/ go far, by being forced to learn pointers and
recursion and thereby expand their horizons beyond Visual Basic.
This is a point you (Gerry) have been stubbornly ignoring through
this whole thread --- students are lazy. If they can write Visual Basic
code in Java, they will. This is how so many students come to the
200-level courses, even at CMU, unable to write 'atoi'.
Lisp, Scheme, and ML make it impossible to cruise through the curriculum
in Visual Basic mode. They force the students to learn, which is all
that most students need.
[In re: another red herring]
> Ironically, the original argument was that by not supporting iteration
> - in other words because of their limited expressiveness - certain
> languages make programmers better.
Right. That's correct. See above.
> Yet by not supporting pointers, Java is supposed to make them worse.
I have two comments on the above sentence, which I realize don't take
into account the thread of the debate up to this point: (A) Java /does/
have pointers, it just hides the *s; and (B) the reason that Java is
not a replacement for Lisp/Scheme/ML in universities has nothing to do
with pointers. (Lisp/Scheme/ML don't have pointers, either![2])
> And its support of recursion doesn't count, for some reason.
Right --- because /supporting/ recursion is a far cry from /encouraging/
recursion. The average student will never learn to fish by being put
out on a lake that /supports/ fishing; they need firm guidance. (And
no, you can't entirely blame the teachers. A lot of teachers are bad,
but it's better that a bad teacher teach Lisp than a bad teacher teach
Java, and there appears to be a shortage of good teachers at the moment.)
-Arthur
[1] - Also consider that Spolsky, as one of the "elite," isn't necessarily
thinking of future application-software drones. His argument applies even
more forcefully to future visionaries --- the ones who are going to make
your life easier with totally original paradigms, whether it be a new
language, a new operating system, a new compression or network protocol,
or a new kind of computer altogether.
[2] - Okay, ML at least supports pointers, but they're ugly as sin and
come with severe limitations --- no pointing to objects "on the stack",
for example. I bet Lisp has an even uglier pointer syntax; I wouldn't be
surprised if Scheme didn't have pointers at all, and I would be surprised
if either language allowed pointing to stack objects.
Point is, in Java the teacher does pointers on day 3 --- you need
pointers and "new" in order to deal with any object more complicated
than String. In a functional language, pointers are a hackish afterthought
that will likely never be mentioned in class. You'll get enough pointers
in 15-113 and 213. :)
wooks
Willem wrote:
> wooks wrote:
> ) A list of items is either empty (the empty list).
> ) Or the concatenation of an item and a list.
> )
> ) There that didn't hurt.
>
> That's the definition of a list, not of a _linked_ list.
>
Of course it was.
> A list of items is an ordered collection of items. Sheesh.
>
See the definition I gave above which scales unlike yours which
doesn't. Sheesh.
> )> )> Remember, we are talking about *natural* definitions here.
> )> )
> )> ) what is natural about using 2 entities to define 1 thing
> )>
> )> What is unnatural about it ?
> )
> ) because in the real world the item (whatever it is) does not consist of
> ) 2 entities, neither does it contain a pointer. Those are things you
> ) have introduced to support your hack.
>
> In the real world, there are no *linked* lists. I need two entities
> to make it a *linked* list.
>
that makes them even more unnatural.
> )> To me it has to do with the way an average human would think.
> )
> ) average humans do not associate pointers with list.
>
> Average humans that know about linked lists *do* associate pointers
> with *linked* lists. Average humans would also equate normal lists
> more naturally with arrays.
>
Average humans work to their limitations some of them self imposed.
What are you trying to say aim low?
> )> Average humans don't think recursively, as far as I know.
> )
> ) yes they do. they climb steps recursively, they mark papers
> ) recursively. they read books recursively.
>
> They climb steps iteratively, they mark papers iteratively,
> and they read books iteratively. A human usually repeats the
> same action until he is done. repeating the same action until
> you are done is called iteration.
>
What exactly do you understand by recursion.
> ) You don't really know what recursively means do you.
>
> If you are going down to such a basic level of what recursion means,
> then you have lost the meaning it has in a programming context.
>
giving things unnatural meaning in a "programming context" is called
hacking.
> Yes, you can call 'repeat an action until you are done' recursion. But
> to claim it is a more natural way to program 'repeating an action' than
> to use the repeat idiom given by the programming language is nonsense.
>
What are the essential characteristics of a recursive algorithm,
because the more you contribute to this thread the more it seems that
you don't know.
> ) 1. your definition introduces complications that are not present in the
> ) real world.
>
> That's because it is the definition of a *linked* list.
> In the real world, linked lists are few and far between.
>
I agree. they only exist in the minds of programmers who hack.
> ) 2. when I ask you to explain things the answers I get are ... there are
> ) a number of ways to do this or it's irrelevant.
>
> That's because there are indeed a number of ways to do them and/or they
> are indeed irrelevant.
>
and as far as answers go that is 100% soundbite 0% substance.
Richard Harter
<a...@nospam.andrew.cmu.edu> wrote:
> Here I agree with Gerry. The whole "tail recursion" thing is a complete
>and utter red herring in the JavaSchools debate. I didn't know Java had
>partial support for TRE, and I still don't care. I don't even care that
>Lisp supports TRE. That's an implementation detail, and it doesn't affect
>the way students /think/ about programming.
Here I will disagree even though there is much in what you say. The
catch is that if you adopt a style in which every thing is recursive
software becomes grossly inefficient unless (a) you have tail
recursion optimization, and (b) you program in such a way as to
exploit tail recursion. In imperative languages this generally isn't
an issue because explicit iteration is used rather than tail
recursion. In consequence the lack of TRO isn't important.
wooks
Willem wrote:
> wooks wrote:
> ) Gerry Quinn wrote:
> )> An ordered set of data objects.
> )
> ) but lots of lists are not ordered. why does your definition require
> ) them to be ordered.
>
> Can you give an example of a list that is not ordered, then ?
>
> Your recursive definition also implies an ordering.
>
my recursive definition does not preclude an unordered list.
wooks
Richard Harter wrote:
> On 10 Jan 2006 00:17:04 -0800, "wooks" <woo...@hotmail.com> wrote:
>
> >
> >Richard Harter wrote:
> >> On 8 Jan 2006 03:06:06 -0800, "wooks" <woo...@hotmail.com> wrote:
> >>
> >>
> >> >Lists are recursively defined structures. Therefore recursion is the
> >> >most suitable and appropriate solution for problems that involve lists
> >> >and structures that derive from lists (arrays, stacks etc).
> >>
> >> As a side note this is a faulty argument. One may use a recursive
> >> definition to define a list, but it isn't obligatory.
> >
> >but I didn't say it was obligatory.
>
> This raises Clinton's question, that depends on what "is" is, or in
> this case, what "are" is. You say lists *are* recursively definted
> structures. If you merely mean that lists can be thought of as
> recursively defined structures, then, yes, then you aren't saying that
> it was obligatory. However I read your statement as an assertion that
> the correct way to describe lists, the essence so to speak, is
> recursively. If you mean something like "A natural way to treat lists
> is to view them as recursively defined structures and let your
> methodology follow the recursive structure." then no one would argue
> with you.
>
You read my statement correctly and made my point more lucidly than I
did or could. thanks.
> >
> >> You can define
> >> it as an ordered set, as the image of a function on the integers, and
> >> in sundry other ways. (Pedant's observation - recursion cannot be
> >> avoided in the definition game; you need it to get the integers.)
> >>
> >
> >Yes you can. My questions would be
> >
> > why would you want to - if you have a simple and natural ready made
> >definition.
>
> Because there are other definitions that may be equally simple and
> natural that have their own merits.
and as scalable.... I'd like to see one.
> The wise programmer is not
> content to know only one methodology and one solution.
>
Wise programmers get their data structures right and apply them
appropriately to the problem. Wise programmers know that there is a
price to pay for not doing that - there may be a performance gain which
is what is often what is sought but u don't get it for nothing. You
usually have to pay in one or more of 4 currencies scalability,
flexibility, extensibility, complexity
> >
> >
> >> Regardless of whether we define lists recursively it doesn't at all
> >> follow that recursion is "the most suitable and appropriate solution
> >> for problems that involve lists and structures that derive from lists
> >> (arrays, stacks etc)".
> >>
> >
> >It does follow..
>
> This is a mere naked assertion (one doesn't prove things by shouting
> loudly and puffing one's chest out.) For it to follow you actually
> have to show that it follows.
>
The only definition I have seen here that scales to arbitrarily nested
list data structures is the one i gave. Thats good enough for me.
> >
> >Sure you can define it other ways -
> >
> >could be an optimisation (premature?).
> >could be that the person doesn't understand recursion.
>
> Or it might be none of these. It might be that a different definition
> provides a cleaner approach.
>
Prove it.
> In any event, you are missing the point - it doesn't follow
> automatically that recursion is the right solution just because one is
> defining lists recursively. Modelling a definition in a solution is a
> natural sort of thing to do; it isn't necessarily the most suitable
> solution.
like I said there always a price to pay .... often it is not
immediately apparent what that price will be.
> >
> >There's always a price to pay.
>
> No matter what you do, there always is a price to pay?
>
if you choose the most natural data structures then the price you pay
later to enhance the system is much much cheaper.
> >If you can hand on heart say that you have figured out all the
> >implications of straying from the natural definition (what classes of
> >problem am I making more difficult/impossible to solve; how scalable is
> >this definition), then fine.
>
> Oh dear. Here we go again with "the natural definition". Have you
> asked the same question about your "natural definition"?
yes.
> Have you
> considered that there might not be any approach that is a universal
> silver bullet?
>
get your data structure right and you will be in good shape for
whatever comes.
> >The fact is most people don't figure this stuff this is an industry
> >prone to premature optimisations and the questions I have posed
> >usually don't get considered until late in the game .... usually too
> >late.
>
> I agree that all too often that people don't consider the consequences
> of their choices until too late. I hold that they should consider the
> consequences rather than swallowing snake oil.
>
I don't do snake oil.
Richard Harter
Fascinating. Perhaps you will share this definition with us, since it
seems to be quite unlike definitions of "list" ordinarily used in
computer science.
Richard Harter
>
>Richard Harter wrote:
>> On 10 Jan 2006 00:17:04 -0800, "wooks" <woo...@hotmail.com> wrote:
>>
[snip]
>> Because there are other definitions that may be equally simple and
>> natural that have their own merits.
>
>and as scalable.... I'd like to see one.
Actually, the ordered set definition is equally scalable, which is not
surprising since it covers the same ground. Be that as it may lists
(with recursive expansions into sublists) are limited in the kinds of
data structures that they scale into in the sense of natural scaling.
[snip]
>> I agree that all too often that people don't consider the consequences
>> of their choices until too late. I hold that they should consider the
>> consequences rather than swallowing snake oil.
>>
>
>I don't do snake oil.
Oh, but you do. You make broad claims and justify them with
handwaving.
wooks
Richard Harter wrote:
> On 10 Jan 2006 11:03:03 -0800, "wooks" <woo...@hotmail.com> wrote:
>
> >
> >Willem wrote:
> >> wooks wrote:
> >> ) Gerry Quinn wrote:
> >> )> An ordered set of data objects.
> >> )
> >> ) but lots of lists are not ordered. why does your definition require
> >> ) them to be ordered.
> >>
> >> Can you give an example of a list that is not ordered, then ?
> >>
> >> Your recursive definition also implies an ordering.
> >>
> >
> >my recursive definition does not preclude an unordered list.
> >
>
> Fascinating. Perhaps you will share this definition with us, since it
> seems to be quite unlike definitions of "list" ordinarily used in
> computer science.
>
Well it's not "my" definition (if I said the definition I posted then
it would have precluded the sarcasm but oh well) it's the standard
recursive definition and I've already posted it.
wooks
Richard Harter wrote:
> On 10 Jan 2006 11:18:24 -0800, "wooks" <woo...@hotmail.com> wrote:
>
> >
> >Richard Harter wrote:
> >> On 10 Jan 2006 00:17:04 -0800, "wooks" <woo...@hotmail.com> wrote:
> >>
> [snip]
>
> >> Because there are other definitions that may be equally simple and
> >> natural that have their own merits.
> >
> >and as scalable.... I'd like to see one.
>
> Actually, the ordered set definition is equally scalable, which is not
> surprising since it covers the same ground. Be that as it may lists
> (with recursive expansions into sublists) are limited in the kinds of
> data structures that they scale into in the sense of natural scaling.
>
> [snip]
> >> I agree that all too often that people don't consider the consequences
> >> of their choices until too late. I hold that they should consider the
> >> consequences rather than swallowing snake oil.
> >>
> >
> >I don't do snake oil.
>
> Oh, but you do. You make broad claims and justify them with
> handwaving.
>
Not my job to educate you. Pick up a copy of the Little Schemer or Eric
Roberts Thinking Recursively and figure it out for yourself.
Willem
) Well it's not "my" definition (if I said the definition I posted then
) it would have precluded the sarcasm but oh well) it's the standard
) recursive definition and I've already posted it.
The definition you posted implies an ordering.
Jonathan Bartlett
The system calls used in the examples are Linux-specific. It is more
technically correct to say "x86 assembly language programming in a Linux
environment" but that suffers from being (a) more verbose and (b) it
doesn't make a lot of sense to the target audience of the book --
newbies who have no idea that assembly language is tied to the computer
architecture.
Basically, I think I'm justified in using the term "Linux assembly
language" on several counts:
(1): Using Linux-specific system calls (necessary to do _anything_)
(2): Using the Linux calling convention
(3): Using gas syntax rather than AT&T
(4): Completely ignoring 16-bit considerations, or indeed any memory
model except the one employed by Linux user-level applications
Jon
----
Michael Wojcik
In article <0001HW.BFE83D21...@news.verizon.net>, Randy Howard <randy...@FOOverizonBAR.net> writes:
> Michael Wojcik wrote
> (in article <dpuj3...@news2.newsguy.com>):
>
> > In practice, typical implementations do disable various optimizations
> > when operating on volatile-qualified objects, but that's a QOI issue,
> > not anything governed by the standard.
> >
> > This has real consequences, such as the proliferation of patterns
> > that are not thread-safe even with liberal sprinklings of "volatile"
> > on various common implementations - double-checked locking being the
> > canonical example.
>
> Anytime you see "volatile" and "thread-safe" in the same
> paragraph, warning flares should go off. If you are writing
> threaded code, and think that volatile helps at all in that
> regard, you are probably going down the wrong path.
Agreed, but that was basically my point: that there are widespread
misconceptions about what "volatile" means (in C, at least), which
is why the question is interesting.
--
Michael Wojcik michael...@microfocus.com
It does basically make you look fat and naked - but you see all this stuff.
-- Susan Hallowell, TSA Security Lab Director, on "backscatter" scanners
Michael Wojcik
In article <20060110140355....@eircom.net>, Steve O'Hara-Smith <ste...@eircom.net> writes:
> On Tue, 10 Jan 2006 13:28:05 +0000
> Chris Dollin <ke...@hpl.hp.com> wrote:
> > Steve O'Hara-Smith wrote:
> >
> > > Of course if you can't modify it the name variable is hardly
> > > justified.
> >
> > It is, however, traditional, and predates (ttbomk) computers. I think
> > you're confusing "variable" with "mutable state"; "variable" need
> > not mean "can be changed" but can mean "is not bound to a specific
> > value".
>
> We use different dictionaries - I can't find one with your
> meaning of variable, all of mine have it as "likely to change" or
> "A quantity capable of assuming any of a set of values".
The latter is equivalent to Chris' definition for these purposes;
it doesn't say anything about ever assuming more than one member of
the set. It's also a suitable definition of "variable" in the
sense johnnyb used, which started this subthread: "If you never
modify existing variables" they still may be "quantit[ies] capable
of assuming any of a set of values" - once.
A variable is an entity that does not have an inherent value. It
may refer to an unspecified, unknown, or known quantity; but it is
not a representation of any single quantity. That's the difference
between a variable and a constant.
--
Michael Wojcik michael...@microfocus.com
Art is our chief means of breaking bread with the dead ... but the social
and political history of Europe would be exactly the same if Dante and
Shakespeare and Mozart had never lived. -- W. H. Auden
wooks
Willem wrote:
> wooks wrote:
> ) Well it's not "my" definition (if I said the definition I posted then
> ) it would have precluded the sarcasm but oh well) it's the standard
> ) recursive definition and I've already posted it.
>
> The definition you posted implies an ordering.
>
A list is either empty (the empty list) or
Richard Harter
Just so. And as Willem observed, that definition implies an ordering.
Think about it.
Richard Harter
Chortle. Did it ever occur to you that some of the people you are
patronizing were acquainted with Scheme and recursion before you were
born? ("Before you were born" is a guess, but given your naivete and
your ill placed dogmatic assurance it is a fair guess that you are
rather young.)
Willem
) wooks wrote:
)>Oh well here goes again.
)>
)>A list is either empty (the empty list) or
)>the concatenation of an item and a list.
)
) Just so. And as Willem observed, that definition implies an ordering.
) Think about it.
In the meantime, here is a non-recursive definition of a list that matches
the recursive one as closely as possible:
A list is a concatenation of items.
I wonder what wooks will find wrong with that one.
Oh, by the way, just to pick a nit: The recursive definition needs
two entities (the empty list, and an item) to define one thing.
wooks
Willem wrote:
> Richard wrote:
> ) wooks wrote:
> )>Oh well here goes again.
> )>
> )>A list is either empty (the empty list) or
> )>the concatenation of an item and a list.
> )
> ) Just so. And as Willem observed, that definition implies an ordering.
> ) Think about it.
>
> In the meantime, here is a non-recursive definition of a list that matches
> the recursive one as closely as possible:
>
> A list is a concatenation of items.
>
> I wonder what wooks will find wrong with that one.
>
Why should I waste my time on your trolling. Go ahead and try and apply
it as a data structure and let us know how you get on.
>
> Oh, by the way, just to pick a nit: The recursive definition needs
> two entities (the empty list, and an item) to define one thing.
>
a list is not an atomic structure so it is perfectly natural to use
more than one entity to define it.
wooks
I'm not interested in a pissing contest and I haven't patronized
anybody.
I was trained on an ICL 1904 in COBOL and was brought up with punched
cards, file allocation utilities and mag tape. I have been baptised in
MVS JCL and learnt how to write CLISTS, REXX on one hand and to deal
with TPMS and 4GL's like ADS/Online and FOCUS. My first database was
IDMS and my professional programming career spans 4 continents
including both sides of the atlantic.
I was taught Jackson Structured Programming in my 2nd programming job
so I was fortunate to learn the importance of data structures early in
my career. Even back then there were dinosaurs who didn't start with
JSP and refused to learn anything from it.
What I have learnt I learnt the hard way. Although it's not where or
how I learnt, I haven't told you anything that a first termer at MIT
couldn't tell you. I'm not peddling anything and you don't have to buy
it.
AFAIC this thread just goes to prove how Spolksy is.
Thank You.
Willem
) Why should I waste my time on your trolling. Go ahead and try and apply
) it as a data structure and let us know how you get on.
I did, many years ago. It works quite nicely, thanks.
)> Oh, by the way, just to pick a nit: The recursive definition needs
)> two entities (the empty list, and an item) to define one thing.
)
) a list is not an atomic structure so it is perfectly natural to use
) more than one entity to define it.
Then why did you criticise me on exactly that same point ?
wooks
Willem wrote:
> wooks wrote:
> ) Why should I waste my time on your trolling. Go ahead and try and apply
> ) it as a data structure and let us know how you get on.
>
> I did, many years ago. It works quite nicely, thanks.
>
> )> Oh, by the way, just to pick a nit: The recursive definition needs
> )> two entities (the empty list, and an item) to define one thing.
> )
> ) a list is not an atomic structure so it is perfectly natural to use
> ) more than one entity to define it.
>
> Then why did you criticise me on exactly that same point ?
>
because you were using 2 entities to define the items of a list -
red
blue
yellow
the items above are all atomic.
Willem
) because you were using 2 entities to define the items of a list -
I was using one entity to define the item (more precisely, I was simply
naming it), and the other to define the structure of the list.
blm...@myrealbox.com
Jonathan Bartlett <joh...@eskimo.com> wrote:
>> I've been curious about what you mean by "Linux assembly language",
>
>The system calls used in the examples are Linux-specific. It is more
>technically correct to say "x86 assembly language programming in a Linux
>environment" but that suffers from being (a) more verbose and (b) it
>doesn't make a lot of sense to the target audience of the book --
>newbies who have no idea that assembly language is tied to the computer
>architecture.
>
>Basically, I think I'm justified in using the term "Linux assembly
>language" on several counts:
>
>(1): Using Linux-specific system calls (necessary to do _anything_)
>(2): Using the Linux calling convention
>(3): Using gas syntax rather than AT&T
>(4): Completely ignoring 16-bit considerations, or indeed any memory
>model except the one employed by Linux user-level applications
>
Fair enough -- that's more or less what I might have guessed
about what you're doing.
As for whether you should be more verbose but technically correct:
My two cents' worth is that by talking about "Linux assembly
language" you make it appear that *you* don't know that assembly
language is tied to the computer architecture, and that there's
more than one of those, and that by being a little more specific
you might even enlighten some of those newbies .... But I may,
as I said before, be nitpicking.
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
Gerry Quinn
says...
> > There are some things that Java doesn't do, and some things that Lisp
> > doesn't do. If you learn either one and nothing else, you will have a
> > very limited understanding.
>
> That is precisely the idea under question here. Noone is saying that
> people shouldn't learn Java. But there are many schools, even
> well-respected schools, that are teaching Java AND NOTHING ELSE.
Oh, they are probably teaching lots of abstract theory, on the basis
that actual programming is as unimportant to computer science as
writing good novels is to literary criticism. But I'm not sure this
mindset is entirely different from the one that encourages the use of
exotic, awkward, or unpopular languages.
(Of course students worth their salt will be picking up a few languages
in their spare time, so may not be harmed.)
> > Ironically, the original argument was that by not supporting iteration
> > - in other words because of their limited expressiveness - certain
> > languages make programmers better. Yet by not supporting pointers,
> > Java is supposed to make them worse. And its support of recursion
> > doesn't count, for some reason. Poor old Java just doesn't seem able
> > to win.
>
> Again, it is the restriction to Java-only that is the problem. But as
> to recursion, Java does not do proper tail recursion.
Tail recursion isn't really relevant to understanding the uses of
recursion, though. It just makes it practical in some cases where it
wouldn't otherwise be.
> I personally think that the best approach is to teach assembly language,
> Scheme, and then some standard language, so you get to learn programming
> from a variety of perspectives -- from the machine up, from the concept
> down, and from the toolset out.
If anything is to be skimped, it is NOT the standard languages such as
Java. Start with them, and if a bit of exposure to the other stuff is
considered desirable, by all means include it.
- Gerry Quinn
Gerry Quinn
woo...@hotmail.com says...
> Gerry Quinn wrote:
> > An ordered set of data objects.
> but lots of lists are not ordered. why does your definition require
> them to be ordered.
An unordered list is best called a set.
> > > BTW none of these techniques are available in XSLT. What then?
> > I don't know as I've never used it. It seems like a very limited
> > special purpose language - maybe they are not needed.
> Interesting solution. Anything that a Java programmer can't understand
> is defined out of existence or classed as limited.
I looked it up, and a limited special purpose language is exactly what
it seems to me. I assume competent programmers can understand it when
they have to, although I should imagine that few choose voluntarily to
interest themselves in it.
> Unfortunately it's not the reality.
>
> Now I've made clear in an earlier post why I keep citing XSLT as an
> example.
>
> Go to www.jobserve.co.uk and type Java XSLT in your search. I got 4883
> jobs.
Arguing from popularity now, are we? How about 'Scheme XSLT'?
> > > > The above succintly indicate that all elements of a set are to be
> > > > processed, and the sequence in which this will occur. The first
> > > > includes a counter, which is often very useful.
> >
> > > But it isn't so succint when some of the elements of the sets are sets
> > > themselves. And supposing this nesting could be n levels deep. What
> > > then?
> >
> > There are well known iterative mechanisms for fixed small n. Or you
> > can use recursion if that is more appropriate. I've nothing *against*
> > recursion as a technique - it has many uses.
>
> In other words your solution doesn't scale.
Scale to what? There's no point is 'scaling' for its own sake where no
scaling will be required. If you are writing a chess game, you will
use a 2D array or equivalent for the board, even as you use recursion
or equivalent for analysis.
Perhaps if functional languages became popular, people would observe
that 'premature scaling is the root of all evil'. Like over-
optimisation in the more conventional languages, over-abstraction may
be a temptation in these.
> > > > > climb(steps)
> > > > > if no more steps stop
> > > > > go up the first step
> > > > > climb (rest of steps).
> > > >
> > > > Once they have learned to walk and count, they do what is best in a
> > > > given situation. But I would say that they normally do:
> > > >
> > > > go to bottom of stairs
> > > > if ( at top ) stop
> > > > climb next step
> > > > repeat
> > > >
> > > > This corresponds best to my second example of iteration.
> > > >
> > > Whats the difference between your "repeat" and my clim(rest of steps).
> >
> > The former is iterative, the latter is recursive.
> >
> I beg to differ. Your example is recursive the thing you are repeating
> is the climb steps routine.
No, there is no 'climb steps' routine in my example. A single step is
climbed at a time, and 'climb step' does not call itself. Whereas your
climb(steps) function does call itself recursively.
> I'll summarise 2 reasons... the ones that I think are more prevalent.
>
> 1. Functional languages do not have the extensive general purpose
> libraries.
> 2. They require a degree of mathematical sophistication which your
> average Joe doesn't have.
>
> They are not toy languages and they are certainly more powerful and
> more expressive than Java.
They are toys if they aren't useful. And clearly the average Joe
doesn't find them either more powerful or more expressive.
I don't doubt they express some things better. It's just that in most
cases, these things are evidently not the things that programmers are
most interested in expressing.
- Gerry Quinn
wooks
Gerry Quinn wrote:
> In article <1136902346....@g43g2000cwa.googlegroups.com>,
> woo...@hotmail.com says...
> > Gerry Quinn wrote:
>
> > > An ordered set of data objects.
>
> > but lots of lists are not ordered. why does your definition require
> > them to be ordered.
>
> An unordered list is best called a set.
>
not my fault that I was given a contradictory definition.
> > > > BTW none of these techniques are available in XSLT. What then?
>
> > > I don't know as I've never used it. It seems like a very limited
> > > special purpose language - maybe they are not needed.
>
> > Interesting solution. Anything that a Java programmer can't understand
> > is defined out of existence or classed as limited.
>
> I looked it up, and a limited special purpose language is exactly what
> it seems to me. I assume competent programmers can understand it when
> they have to, although I should imagine that few choose voluntarily to
> interest themselves in it.
>
I've noticed from communicating with you that u tend to assume alot.
> > Unfortunately it's not the reality.
> >
> > Now I've made clear in an earlier post why I keep citing XSLT as an
> > example.
> >
> > Go to www.jobserve.co.uk and type Java XSLT in your search. I got 4883
> > jobs.
>
> Arguing from popularity now, are we? How about 'Scheme XSLT'?
>
Now you're just being awkward. You learn scheme not to get a job but
because it teaches you to think and abstract, which is another point
that Spolsky made. I haven't seen much evidence of an ability to
abstract from the replies i have been getting from you.
> > > > > The above succintly indicate that all elements of a set are to be
> > > > > processed, and the sequence in which this will occur. The first
> > > > > includes a counter, which is often very useful.
> > >
> > > > But it isn't so succint when some of the elements of the sets are sets
> > > > themselves. And supposing this nesting could be n levels deep. What
> > > > then?
> > >
> > > There are well known iterative mechanisms for fixed small n. Or you
> > > can use recursion if that is more appropriate. I've nothing *against*
> > > recursion as a technique - it has many uses.
> >
> > In other words your solution doesn't scale.
>
> Scale to what? There's no point is 'scaling' for its own sake where no
> scaling will be required.
scale to more complex data structures. another word for it is
extensibility. If you don't appreciate what it is or means and why it
is desirable then it's a matter for you.
> If you are writing a chess game, you will
> use a 2D array or equivalent for the board, even as you use recursion
> or equivalent for analysis.
>
Bad example because the rules of chess, the pieces and the dimensions
of the board are static. Unlike most business systems.
> Perhaps if functional languages became popular, people would observe
> that 'premature scaling is the root of all evil'. Like over-
> optimisation in the more conventional languages, over-abstraction may
> be a temptation in these.
>
Over abstraction. Richard Gabriels had something to say about this in
Pattern of Software . You can download a copy of the whole book from
his website and it won't cost you a bean.. A greater peril in my view
is the inability to abstract whether at all or sufficiently.
> > > > > > climb(steps)
> > > > > > if no more steps stop
> > > > > > go up the first step
> > > > > > climb (rest of steps).
> > > > >
> > > > > Once they have learned to walk and count, they do what is best in a
> > > > > given situation. But I would say that they normally do:
> > > > >
> > > > > go to bottom of stairs
> > > > > if ( at top ) stop
> > > > > climb next step
> > > > > repeat
> > > > >
> > > > > This corresponds best to my second example of iteration.
> > > > >
> > > > Whats the difference between your "repeat" and my clim(rest of steps).
> > >
> > > The former is iterative, the latter is recursive.
> > >
> > I beg to differ. Your example is recursive the thing you are repeating
> > is the climb steps routine.
>
> No, there is no 'climb steps' routine in my example. A single step is
> climbed at a time, and 'climb step' does not call itself. Whereas your
> climb(steps) function does call itself recursively.
>
You are repeating the same thing. You just haven't put it in a routine.
If you could only just abstract a bit better then you'll see what i
mean.
> > I'll summarise 2 reasons... the ones that I think are more prevalent.
> >
> > 1. Functional languages do not have the extensive general purpose
> > libraries.
> > 2. They require a degree of mathematical sophistication which your
> > average Joe doesn't have.
> >
> > They are not toy languages and they are certainly more powerful and
> > more expressive than Java.
>
> They are toys if they aren't useful. And clearly the average Joe
> doesn't find them either more powerful or more expressive.
>
Spolsky point is that he doesn't want to hire average Joe's and
universities shouldn't be gearing their degree courses to produce
average Joe's.
> I don't doubt they express some things better.
> It's just that in most
> cases, these things are evidently not the things that programmers are
> most interested in expressing.
>
Sticking to the hacks you know guarantees you remain an average Joe
for your entire career. If you truly did speak for "programmers" as you
purport to then that would be quite depressing.
wooks
Willem wrote:
> wooks wrote:
> ) because you were using 2 entities to define the items of a list -
>
> I was using one entity to define the item (more precisely, I was simply
> naming it), and the other to define the structure of the list.
>
Willem. I don't care anymore.
wooks
Gerry Quinn wrote:
> In article <43c3c9ed$1...@news.tulsaconnect.com>, joh...@eskimo.com
> says...
> > > There are some things that Java doesn't do, and some things that Lisp
> > > doesn't do. If you learn either one and nothing else, you will have a
> > > very limited understanding.
> >
> > That is precisely the idea under question here. Noone is saying that
> > people shouldn't learn Java. But there are many schools, even
> > well-respected schools, that are teaching Java AND NOTHING ELSE.
>
> Oh, they are probably teaching lots of abstract theory, on the basis
> that actual programming is as unimportant to computer science as
> writing good novels is to literary criticism.
Why not check any of the thousands of CS curriculums online before
tossing out that statement.
> But I'm not sure this
> mindset is entirely different from the one that encourages the use of
> exotic, awkward, or unpopular languages.
>
The exotic, awkward unpopular languages happen to be better at teaching
skills like thinking and abstracting.
> (Of course students worth their salt will be picking up a few languages
> in their spare time, so may not be harmed.)
>
> > > Ironically, the original argument was that by not supporting iteration
> > > - in other words because of their limited expressiveness - certain
> > > languages make programmers better. Yet by not supporting pointers,
> > > Java is supposed to make them worse. And its support of recursion
> > > doesn't count, for some reason. Poor old Java just doesn't seem able
> > > to win.
> >
> > Again, it is the restriction to Java-only that is the problem. But as
> > to recursion, Java does not do proper tail recursion.
>
> Tail recursion isn't really relevant to understanding the uses of
> recursion, though. It just makes it practical in some cases where it
> wouldn't otherwise be.
>
> > I personally think that the best approach is to teach assembly language,
> > Scheme, and then some standard language, so you get to learn programming
> > from a variety of perspectives -- from the machine up, from the concept
> > down, and from the toolset out.
>
> If anything is to be skimped, it is NOT the standard languages such as
> Java. Start with them, and if a bit of exposure to the other stuff is
> considered desirable, by all means include it.
>
So in the 70's and 80's you'd have had universities teaching Cobol.
Willem
) Willem. I don't care anymore.
I thought you never actually cared in the first place, what with the way
you were picking apart and hammering down every argument made against your
points, as if they were a bastion under attack.
Martin Eisenberg
> In article <43c4...@news.tulsaconnect.com>,
> Jonathan Bartlett <joh...@eskimo.com> wrote:
>>The system calls used in the examples are Linux-specific. It is
>>more technically correct to say "x86 assembly language
>>programming in a Linux environment" but that suffers from being
>>(a) more verbose and (b) it doesn't make a lot of sense to the
>>target audience of the book -- newbies who have no idea that
>>assembly language is tied to the computer architecture.
> As for whether you should be more verbose but technically
> correct: My two cents' worth is that by talking about "Linux
> assembly language" you make it appear that *you* don't know that
> assembly language is tied to the computer architecture, and that
> there's more than one of those, and that by being a little more
> specific you might even enlighten some of those newbies ....
I agree, and I think the cure need be no more verbose than "assembly
language on Linux".
Martin
--
Quidquid latine scriptum sit, altum viditur.
wooks
Steve O'Hara-Smith wrote:
> On 9 Jan 2006 08:49:10 -0800
> "wooks" <woo...@hotmail.com> wrote:
>
> >
> > Chris Dams wrote:
> > > Dear wooks,
> > >
> > > "wooks" <woo...@hotmail.com> writes:
> > >
> > > >BTW none of these techniques are available in XSLT. What then?
> > >
> > > a random number generator in XSLT?
> > >
> > > Best,
> > > Chris
> >
> > The reason that I keep using XSLT as an example is because it is a
> > functional or at least functional like language that is widely used in
> > what Gerry would call the "real world" and there is a fairly good
> > chance of a Java programmer being exposed to it.
>
> True but the Java programmers I've known who got exposed to XSLT
> ran screaming to the extensions that let you embed Java code in it.
>
Not really an option for those running it on an MS platform from VB+-
.Net, C#/++ though is it. Besides in saying that you merely buttress
Spolsky's concern about Java programmers or people taught in Java
being one trick ponies.
> I think XSLT is the single most hideous and inconvenient programming
> language invented far more than perl it deserves the label "write only".
>
Imperative programmers always say things like that about functional
languages.
XSLT written in accordance with the declarative paradigm is very
succinct and quite elegant. It starts to look hideous and inconvenient
when you try to use it like an imperative language which it is not.
I've had first hand experience rewriting XSLT created by people who
misused the language in this way and hideous and inconvenient and a few
other adjectives would accurately describe the state of the code when
it was handed to me.
wooks
Gerry Quinn wrote:
> In article <1136902346....@g43g2000cwa.googlegroups.com>,
> woo...@hotmail.com says...
> > Gerry Quinn wrote:
>
> > > An ordered set of data objects.
>
> > but lots of lists are not ordered. why does your definition require
> > them to be ordered.
>
> An unordered list is best called a set.
>
If it makes no odd whether my list is ordered (3, 1, 2) or (2,1,3). I
can abstract away ordering from my definition. If on the other hand I
am processing a telephone directory then the order of the items becomes
relevant, perhaps even to the extent where I would include in a
definition (maybe call it sorted list).
If OTOH the argument is there is an ordering inherent in the way the
list is stored (regardless of whether it is relevant to processing),
why stop there. Why not include in your definition the fact that the
items are internally represented in binary.
So ATEOTD it comes down to abstraction.
wooks
Steve O'Hara-Smith wrote:
> On 10 Jan 2006 05:51:58 -0800> > > On 9 Jan 2006 22:33:49 -0800
>
> > > Of course if you can't modify it the name variable is hardly
> > > justified.
> > >
> >
>
> Well with = not == - I don't recall it being a comparison :)
>
> > It's the solution to a quadratic equation. It has variables a, b and c.
> > Once you assign values to a,b and c, do they change?.
>
> Sure they change - every time the quadratic I want the roots
> of changes.
>
Absolutely but then you would be doing a new invocation of your
quadratic subroutine.
But while you are evaluating quadratic(a, b, c)..in your subroutine.
the values of a b and c are immutable.
This is how variables work in mathematics and it's how they work in
functional programming languages.
Steve O'Hara-Smith
"wooks" <woo...@hotmail.com> wrote:
> Steve O'Hara-Smith wrote:
> > On 9 Jan 2006 08:49:10 -0800
> > True but the Java programmers I've known who got exposed to XSLT
> > ran screaming to the extensions that let you embed Java code in it.
> >
> Not really an option for those running it on an MS platform from VB+-
> .Net, C#/++ though is it. Besides in saying that you merely buttress
> Spolsky's concern about Java programmers or people taught in Java
> being one trick ponies.
It's an observation, not something I consider desirable - when I
learned the art having a wide variety of languages of different types
under the belt was considered to be required.
> > I think XSLT is the single most hideous and inconvenient programming
> > language invented far more than perl it deserves the label "write only".
> >
> Imperative programmers always say things like that about functional
> languages.
I've seen elegance and readability and maintainability in
functional languages - but not in XSLT. Perhaps I have only seen bad
XSLT - my main exposure was adjusting Norman Walsh's XSLT for Docbook
to XSL-FO conversions. By the time I got it to do what was wanted of
it I had come to the conclusion that it would have been easier to
start from scratch - but even that looked like a large and tricky job.
I also used XSLT for some conversions of much simpler XMLs
and found it reasonably convenient. It just seemed that when the
job got complex the XSLT got vile.
> XSLT written in accordance with the declarative paradigm is very
> succinct and quite elegant.
Even for large and complex transformations ?
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/