Linked lists

[Lew]

I started
talking mergesort and quicksort to him too, but his eyes glazed over, and
I quit that effort.

I might add - the gentleman in question has a CS degree...

Half of all college graduates were in the bottom 50% of their class.

Just because some students are incompetent doesn't mean that the subject has
no value, nor that good students of that subject don't benefit from having
studied it.

 

[Arne Vajhøj]

Computer scientists
are people who spend too much time doing maths and not enough time
writing code, and their opinions are not to be trusted.

I assume that is a joke.

Software development is more about thinking about how the
code should be than typing in the code.

Math is a foundation for practically all programming even though
it for some type of coding is a bit implicit.

Arne

 

[Arne Vajhøj]

Nonetheless, i do believe that there's a strong strain of aesthetics
within CS that has a very different idea of what's beautiful and good
and worthwhile to the idea that prevails in the fields and mines of the
software industry (and to which i'm implicitly attaching a sort of halo
of empirical validness). The kind of thinking that leads to this sort of
thing:

http://lambda-the-ultimate.org/node/3210

Which is pretty much guaranteed never to actually be any use to anyone.

Functional programming may not take over the world tomorrow, but
there are some people using it.

Furthermore, i think this highly abstracted, mathematicised strain of
thinking has been dominant in CS for much of its history, and has led to
a lot of smart people putting all their efforts into things which from a
distance seem pretty pointless.

That is not specific for computer science. There is a lead time
between theoretical research at universities and practical applications.

Albert Einsteins work was not particular useful when published
before WW I.

The result of this is that people who are heading for a career writing
code get an education which doesn't actually help them do that. This is
purely anecdotal, but i've often heard people in industry say that they
don't consider a CS degree any kind of preparation of a job writing code
(my currrent bosses say, only semi-jokingly, that they won't hire
computer scientists - we currently have people with degrees in maths,
software engineering, electronic engineering, architecture and
biochemistry). Indeed, i know of a university department that made its
reputation by specifically *not* being a CS department - it was part of
the electrical engineering faculty, and gave its students a much more
craft-oriented education.

Any academic education should not focus on writing code in language X
but on principles.

I don't think CS in general are less capable of that than EE or whatever.

I guess it all comes down to whether you think Alan Turing or Tom
Kilburn is the real father (or midwife, perhaps) of the computer. Alan
Turing wrote some brilliant papers about the idea of computability, but
it was Tom Kilburn who actually made the first program run.

Turings work still has importance today. Kilburns work has
only historic interest today as far as I can tell.

BTW, http://en.wikipedia.org/wiki/Tom_Kilburn#Administration says:

"Kilburn was instrumental in forming the Department of Computer Science
in 1964, becoming the first head of the department,"



Arne

 

[Arne Vajhøj]

This is called a

http://en.wikipedia.org/wiki/Defence_mechanism

. When one learns of people with a higher level of education
than one's own level of education, one's

http://en.wikipedia.org/wiki/Self-esteem

is threatened.

There are also people with degrees in something else than CS.

I think a less advanced psychological explanation of:
http://en.wikipedia.org/wiki/Not_Invented_Here
is more correct.

Arne

 

[Arne Vajhøj]

One of the best managers I had the fortune to work for was a really
bright guy (1st from Oxford in Maths), top class system designer and also
a very good manager with exactly the right ability to delegate to the
appropriate person.

His approach to hiring was unique: he always said he didn't care what a
new graduate knew or had studied: that was irrelevant. What he wanted to
hire was brain power and the ability to think, learn and solve problems.

There are some truth to that.

The way of thinking and some of the theoretical foundation
in natural sciences, electric engineering etc. are
close to CS.

Arne

 

[Arne Vajhøj]

In the sixties I met a few chemists who had become programmers. Maybe
chemists and programmers have similar mindsets.

Physics, chemistry, statistics etc..

Arne

 

[Arne Vajhøj]

I absolutely agree with the first sentence here. I wish the rest of the
quote was true more often than it really is. In practise, the "highest
ranks of understanding" of data structures and algorithms (and everything
else that one would expect a CS degree to give you an education on) seems
to be missing for a large percentage of programmers (the majority)
regardless of whether they have a CS degree or not.

When I started programming as a career I recognized eventually that my
background in data structures and algorithms was deficient. After all,
you don't learn that in physics or engineering. So I went out and bought,
and studied, texts like Sedgewick's "Algorithms in C". Having done that
(and I'm still doing it), it's been disconcerting over the years to find
out that I know more about CS basics than many recent CS graduates do.
Makes me wonder what the hell they get taught.

Not all universities are good, not all students are bright, not
all students are hardworking.

The Gaussian normal distribution applies.

Arne

 

[Martin Gregorie]

There are some truth to that.

The way of thinking and some of the theoretical foundation in natural
sciences, electric engineering etc. are close to CS.

He had far more hits than misses despite hiring from other disciplines
than maths and sciences - I remember a historian who turned out very
well. He also managed to find excellent PS/unit administrators and sales
johnnies. It probably helped that he was no slouch at these roles.

 

[Martin Gregorie]

In the sixties I met a few chemists who had become programmers. Maybe
chemists and programmers have similar mindsets.

By and large it seems to have been a successful cross-over, possibly
because to be a good chemist you need a fairly wide range of both
theoretical and practical skills. Mind you, in the late 60s there was a
world-wide oversupply of chemistry graduates, which fortunately coincided
with a shortage of programmers and analysts as the market for 3rd
generation mainframes (IBM System/360, ICL 1900, etc) expanded.

 

[Tom Anderson]

I assume that is a joke.
Somewhat.

Software development is more about thinking about how the code should be
than typing in the code.

But it's thinking you only learn to do by doing.

I'm reminded of the friend of mine who did a PhD on a new way of
representing programs in compilers; he spent three years coming up with it
and proving it was right, and after he submitted his thesis, he mentioned
that it was a shame that he'd never got round to actually implementing it.
I don't mean to belittle his work at all (from what i undestood of it, it
was very clever), but the fact is that he has no real idea if it's a good
basis for a compiler, because he hasn't tried it.

Math is a foundation for practically all programming even though it for
some type of coding is a bit implicit.

I can't remember any time i've applied non-trivial mathematics to coding.
By non-trivial, i mean beyond things like working out if an expression for
an index variable is guaranteed to be in bounds etc. I've never proven
something correct, or calculated an asymptotic running time. I know there
are people who need to do that in their work, but i think that's very
unusual.

OTOH, the kind of disciplined, logical thinking you use in maths is vital
for writing computer programs, but that kind of thinking isn't unique to
maths - it's the standard mindset across the sciences, and i imagine
engineering too.

tom

 

[Arved Sandstrom]

Half of all college graduates were in the bottom 50% of their class.

Just because some students are incompetent doesn't mean that the subject
has no value, nor that good students of that subject don't benefit from
having studied it.

Never said any different. If I didn't think that data structures and
algorithms had value I wouldn't have studied those subjects myself.

My main point is, I haven't seen in my career that a CS degree has much
relevance to professional programming. And it's clearly possible for a CS
graduate to possess little knowledge of those subjects which _would_
help. More to the point, if the skills of a programmer with a CS degree
are broadly the same as those of a programmer with a non-CS degree, all
other things being equal, whatever the computer science curriculum is
intended for it's not professional software development. And that
observation has been my experience.

AHS

 

[Martin Gregorie]

There are also people with degrees in something else than CS.

I think a less advanced psychological explanation of:
http://en.wikipedia.org/wiki/Not_Invented_Here
is more correct.

That's a good point. I think the general University switch from Unix to
Windows for teaching CS subjects was a disaster from the point of view of
teaching component re-use. Unix and derivatives are excellent for that
thanks to their extensive use of concepts such as single function utility
programs, pipelines and shell scripting.

You simply cant do this sort of reuse nearly as easily in a Windows
environment due to the over-simplistic shell. On top of that the emphasis
on giant multi-function programs and everything-gotta-be-GUI is a major
disincentive for component re-use outside of function libraries. I think
this all amounts to a breeding ground for the 'not made here' syndrome.

Is design for re-use taught anywhere these days?

IME it is difficult to do and should be a staple of all types of course
whether they are part of a CS degree or just language-specific. It is
something I work at continuously. Reuse requires careful thought about
designing the API before starting to cut code. As a simple example

int copyFile(InputStream in, OutputStream out)

is considerably more useful than

int copyFile(File inName, File outName)

The latter approach merely gets you a file copy procedure for whatever
file type is instantiated inside the method, while the first can be used
for copying different types of streams from a variety of sources as well
as concatenating them.

 

[blueparty]

Tom Anderson wrote:
...
...

In that case, I had better stop writing articles here, in case my
untrustworthy opinions lead anyone astray.

I'm a computer science Ph.D. candidate with a bachelor's degree in
mathematics and a master's degree in CS. By any reasonable
classification I'm a computer scientist, and I have spent a significant
portion of my time thinking about mathematics.

When pressed by deadlines, choose the solution that is easiest to
implement even if it is not optimal. CS people would, most likely,
advise against such solution.

Later, when you have more time, consult CS people and replace the solution.

Your application will probably have couple of revisions during its lifetime.

B

 

[Arne Vajhøj]

When pressed by deadlines, choose the solution that is easiest to
implement even if it is not optimal. CS people would, most likely,
advise against such solution.

I don't see that.

The CS people would have a good understanding of why it
was not optimal.

But spending 5 years studying CS does not make people not
understand what a deadline is.

Arne

 

[Arne Vajhøj]

I think the general University switch from Unix to
Windows for teaching CS subjects was a disaster from the point of view of
teaching component re-use. Unix and derivatives are excellent for that
thanks to their extensive use of concepts such as single function utility
programs, pipelines and shell scripting.

You simply cant do this sort of reuse nearly as easily in a Windows
environment due to the over-simplistic shell.

CMD, VBS or PowerShell ?

CMD is not the only option available on Windows.

Actually CMD in later Windows versions is rater powerful, but
the syntax makes assembler look structured and readable.

Is design for re-use taught anywhere these days?

I would expect the concepts being teached as part of general
programming concepts (OOP, CBD etc.).

Obviously practical experience is required on top of the theoretical
foundation to be truly successful.

IME it is difficult to do and should be a staple of all types of course
whether they are part of a CS degree or just language-specific. It is
something I work at continuously. Reuse requires careful thought about
designing the API before starting to cut code. As a simple example

int copyFile(InputStream in, OutputStream out)

is considerably more useful than

int copyFile(File inName, File outName)

The latter approach merely gets you a file copy procedure for whatever
file type is instantiated inside the method, while the first can be used
for copying different types of streams from a variety of sources as well
as concatenating them.

That type of stuff is probably best learned by experience.

Arne

 

[Arne Vajhøj]

But it's thinking you only learn to do by doing.

Experience is definitely a big plus.

But so is a theoretical background.

I'm reminded of the friend of mine who did a PhD on a new way of
representing programs in compilers; he spent three years coming up with
it and proving it was right, and after he submitted his thesis, he
mentioned that it was a shame that he'd never got round to actually
implementing it. I don't mean to belittle his work at all (from what i
undestood of it, it was very clever), but the fact is that he has no
real idea if it's a good basis for a compiler, because he hasn't tried it.

If it is good, then it will eventually show up in compilers.

Universities are supposed to do basic research not create products.

I can't remember any time i've applied non-trivial mathematics to
coding. By non-trivial, i mean beyond things like working out if an
expression for an index variable is guaranteed to be in bounds etc. I've
never proven something correct, or calculated an asymptotic running
time. I know there are people who need to do that in their work, but i
think that's very unusual.

But you do not decide whether to use ArrayList, LinkedList or HashMap
by throwing a dice.

You utilize that someone has analyzed their big O characteristics.

And you do not make your database structures randomly either.

You utilize that someone has invented relational algebra.

You may not be using Math directly, but you are standing
on the shoulders of a lot of mathematicians.

OTOH, the kind of disciplined, logical thinking you use in maths is
vital for writing computer programs, but that kind of thinking isn't
unique to maths - it's the standard mindset across the sciences, and i
imagine engineering too.

There are many years of experience that shows that other sciences
than math and CS is a good background for software development.

Arne

 

[Lew]

Never said any different. If I didn't think that data structures and
algorithms had value I wouldn't have studied those subjects myself.

My main point is, I haven't seen in my career that a CS degree has much
relevance to professional programming. And it's clearly possible for a CS
graduate to possess little knowledge of those subjects which _would_
help. More to the point, if the skills of a programmer with a CS degree
are broadly the same as those of a programmer with a non-CS degree, all
other things being equal, whatever the computer science curriculum is
intended for it's not professional software development. And that
observation has been my experience.

I don't disagree with your points, either. My issue isn't about CS degrees
anyway. I'm pointing up the value of computer science, not a computer science
degree.

There is a difference between having a Ph.D. in physics and being a physicist.
There is a value to the science of physics beyond that of being a
physicist. So with computer science.

 

[Lew]

Also it should be noted that some universities had great success in
teaching programming using languages like
Scheme or other functional stuff...
The reason behind this is that you just can't hack in Functional
languages... you have to plan ahead.. desing you program..

In Java you can just hack away smaller programs and get to what you want
while you hack. Functional languages enforce planning.

Another argument for using such languages like Scheme or OCaml in
academia for teaching is that all students are then on the same
level... In a Java course 50% has already learned some drops and all are
on a different level.

Also what I see is that even if those languages are mostly academic
use.. if you look at programming competitions.. more and more of these
are won by people doing functional programming.

<http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html>

 

[Lew]

When pressed by deadlines, choose the solution that is easiest to
implement even if it is not optimal. CS people would, most likely,
advise against such solution.

Later, when you have more time, consult CS people and replace the solution.

Your application will probably have couple of revisions during its lifetime.

A great theoretical approach that rarely, if ever, works in workaday
programming. I have been promised many times the opportunity to refactor
software, then been forbidden to do so based on variants of, "If it ain't
broke, don't fix it."

I have learned that I must do it right the first time, because management
rarely permits, and then not willingly, the opportunity to improve it.

I have also learned that it's no slower, and usually faster, to create an
optimal solution up front.

Agile shops are sort of an exception to this, but I have not had the privilege
of working in those environments.

In my career, when I have refactored I've had to do it surreptitiously, and
put up with getting in trouble for it. The only exception was a team that was
ignored by management for six months, and therefore was able to redesign the
architecture on its own. The result was a 200-fold (not 200%, 200-fold)
increase in productivity for adding features to the product, and a change from
unreliable results to completely reliable results.

Incidentally, this is in line with the theory of software project management,
as described in several books I've read on the subject. The strangest thing
about this to me is that both the theory of software development and of
software project management supports behaviors that managers I've worked with
will not usually trust. Theories like keep an effective team together even
during periods of inactivity, or the tenets of agile programming. Despite the
anti-academic prejudice expressed at times in this thread, the theories are
actually more pragmatically useful than many of the practices of less
theoretically-inclined practitioners.

 

[Arne Vajhøj]

A great theoretical approach that rarely, if ever, works in workaday
programming. I have been promised many times the opportunity to
refactor software, then been forbidden to do so based on variants of,
"If it ain't broke, don't fix it."

I have learned that I must do it right the first time, because
management rarely permits, and then not willingly, the opportunity to
improve it.

So very true.

But that does not change deadlines.

I have also learned that it's no slower, and usually faster, to create
an optimal solution up front.

Not always.

And especially not if it is enhancements to existing code.

Arne