Programming is not as much fun/more fun than it used to be.

[Tony Morris]

Java and C# ... No need to worry about memory management

I assume you haven't been bitten by the consequences of believing this
common fallacy yet ?

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Mike Kent]

If you're not careful here, you could re-invent APL ...

 

[Andy Fish]

I definitely like the idea of storing all the resources in an XML file.

Unfortunately I don't do much GUI programming nowadays and it is all either
java swing or native win32 (vb6). I just wish MS had gone this way with .net
winforms though

 

[Cristiano Sadun]

*We*, OTOH, from time to time hire CS students to write code.
And then I get to fix it. As a result, I believe that average
CS graduate is completely unaware of all those modern programming
techniques you've described.

I'd say that holds for most engineering fields. Experience is part of the
game, and by definition you dont get much of that at school.

The main issue with CS schools, at least in my experience, is another: they
often fail to create the right mentality - where precision, forward-
thinking, decision making and assessing the consequences of small scale
decisions to the big picture - all founded on mathematical language and
methods - is considered essential by the fresh graduate.

And the industry (read: the businesses) doesnt help much there either.

"<language of your choice> in 21 days" simply isn't the way of engineering
- software of whatever else.

 

[Scott Ellsworth]

I'd say that holds for most engineering fields. Experience is part of the
game, and by definition you dont get much of that at school.

Of course, exactly _what_ many schools teach is a problem as well. The
chair of a CS department I know said recently that they teach Java in
the intro CS course for non CS majors, and Scheme, Rexx, ML, and
eventually C++ in the track for CS majors. Thus, a CS student will come
out with markedly less marketable skills and experience than a student
who takes the class for non majors.

C++ is quite popular, and a good choice, but I would really like to have
my graduates very familiar with more than just one popular OO language.
Having done C++ for 7 years helped me understand what Java did right and
wrong, and doing Java for 6 years has given me a lot of perspective on
C++.

Personally, I would probably teach Java, C++, Perl, and Python to my CS
majors, as I see these used as common tools for sysadmins and developers
all over the place. I hate Perl, but it is a very good language to
understand some of.

The main issue with CS schools, at least in my experience, is another: they
often fail to create the right mentality - where precision, forward-
thinking, decision making and assessing the consequences of small scale
decisions to the big picture - all founded on mathematical language and
methods - is considered essential by the fresh graduate.

That, I chalk up to experience most of the time. Once they know when to
compromise, and when to stick to their guns, that outlook can be really
handy.

And the industry (read: the businesses) doesnt help much there either.

"<language of your choice> in 21 days" simply isn't the way of engineering
- software of whatever else.

Agreed, but businesses do sometimes learn that they are getting what
they are paying for with this kind of approach.

Scott

 

[Cristiano Sadun]

Of course, exactly _what_ many schools teach is a problem as well.
The chair of a CS department I know said recently that they teach Java
in the intro CS course for non CS majors, and Scheme, Rexx, ML, and
eventually C++ in the track for CS majors. Thus, a CS student will
come out with markedly less marketable skills and experience than a
student who takes the class for non majors.

Interesting - and not dissimilar to what used to happen in some CS
faculties when I was a student - people knowing everything about ring
theory but unable to put a diskette into a pc.

Still, both theoretical and practical experience are essential: unless we
start planning 10-years courses (and extremes excluded), a bias towards
theory is acceptable to me - after all, in the world outside the school
there are far less opportunities to delve into theoretical details than
to gain pragmatic experience.

C++ is quite popular, and a good choice, but I would really like to
have my graduates very familiar with more than just one popular OO
language. Having done C++ for 7 years helped me understand what Java
did right and wrong, and doing Java for 6 years has given me a lot of
perspective on C++.

It certainly does that effect.

Personally, I would probably teach Java, C++, Perl, and Python to my
CS majors, as I see these used as common tools for sysadmins and
developers all over the place. I hate Perl, but it is a very good
language to understand some of.

Still, I ain't sure that a language-centric approach is entirely a
solution. Languages are tools, and knowing *one* language (and its ever-
growing libraries, if it's one that's alive is an effort requiring
years of problem-solving application. Trying to cram many into what's at
most a 5-years degree might just end up with students having a
superficial experience with any of them, which hasn't much value.

I understand what u mean: but, personally, I've some experience with C++
and Java and I never felt the _need_ of using phyton or perl unless
required by external factors. Not because they aren't good, or because
they aren't *better* than Java and C++ at certain things: they certainly
are; but the cost of keeping fluent in them (and to gain and keep the
kind of immediate solution-seeing I have with C++ and Java) is - to me -
too high to justfy the advantage. When I did have to do some perl or
phyton, it was a breeze - even if I could never claim to be an expert in
them.

I learned very early that paradigm choice and complexity-based reasoning
(both computational and design), plus attention to development of s/e
ideas where very helpful in making me an effective programmer first, and
a reasonably good designer after. That, simply because just *knowing*
that a problem exists (and someone else has encountered it) expands the
way you can think proactively.

That kind of approach ('interest') is what I would like to see encouraged
in schools: the idea that the wealth of experience (or just discovery of
problems) that is documented in literature *is* useful, and not just for
passing the exam.

 

[Robert Klemme]

news:[email protected]:

Interesting - and not dissimilar to what used to happen in some CS
faculties when I was a student - people knowing everything about ring
theory but unable to put a diskette into a pc.

And some post docs (from the theroteical CS dept) even displayed a certain
pride in this. *shudder*

Still, both theoretical and practical experience are essential: unless we
start planning 10-years courses (and extremes excluded), a bias towards
theory is acceptable to me - after all, in the world outside the school
there are far less opportunities to delve into theoretical details than
to gain pragmatic experience.
Definitely!

I understand what u mean: but, personally, I've some experience with C++
and Java and I never felt the _need_ of using phyton or perl unless
required by external factors. Not because they aren't good, or because
they aren't *better* than Java and C++ at certain things: they certainly
are; but the cost of keeping fluent in them (and to gain and keep the
kind of immediate solution-seeing I have with C++ and Java) is - to me -
too high to justfy the advantage.

Fortunately I was able to drop C++ and Perl for Ruby. Great and simple,
which makes it easy to stay fluent.

That kind of approach ('interest') is what I would like to see encouraged
in schools: the idea that the wealth of experience (or just discovery of
problems) that is documented in literature *is* useful, and not just for
passing the exam.

Yep. Although I'd expect students to bring that interes with them when
they enter university...

robert

 

[Dale King]

Of course, exactly _what_ many schools teach is a problem as well. The
chair of a CS department I know said recently that they teach Java in
the intro CS course for non CS majors, and Scheme, Rexx, ML, and
eventually C++ in the track for CS majors. Thus, a CS student will come
out with markedly less marketable skills and experience than a student
who takes the class for non majors.

I just listened to an interesting interview with Steve McConnell where he
talked about the differences between a CS degree and what is currently
gaining ground is a Software Engineering degree.

You can listen to it or read the transcript here:

http://www.itconversations.com/shows/detail82.html

 

[Scott Ellsworth]

[big snip]

Personally, I would probably teach Java, C++, Perl, and Python to my
CS majors, as I see these used as common tools for sysadmins and
developers all over the place. I hate Perl, but it is a very good
language to understand some of.

Still, I ain't sure that a language-centric approach is entirely a
solution. Languages are tools, and knowing *one* language (and its ever-
growing libraries, if it's one that's alive is an effort requiring
years of problem-solving application. Trying to cram many into what's at
most a 5-years degree might just end up with students having a
superficial experience with any of them, which hasn't much value.

I was a bit unclear - A CS major at my alma mater takes 5 courses a
semester, for a total of roughly 30 courses after declaring a major and
finished the freshman core. Of those, 20 are in major, and of those,
only two are really "teach them languages" courses. The other 18 are
the usual things like database theory, parallel processing, operating
systems, OO theory, and the like. The program is not as language
centric as I made it out to be.

My complaint was more that they did not give the graduates a grounding
in several popular OO languages, which would make it hard for them to
judge for themselves how to feel about .NET/C#, or Objective C.

I had no problem being fluent in both Pascal and C Back In The Day,
while those a generation before me usually walked out with two or three
different assembly languages, and so I suspect that current students can
be familiar with more than one tool. I would not want to see them
spread too thin, but a small handful of languages can work for you.

Scott

 

[Roedy Green]

Still, both theoretical and practical experience are essential: unless we
start planning 10-years courses (and extremes excluded), a bias towards
theory is acceptable to me - after all, in the world outside the school
there are far less opportunities to delve into theoretical details than
to gain pragmatic experience.

theory goes stale more slowly than practical knowledge.

 

[Paul Hsieh]

1. Programming is more fun than it used to be.

Java and C# (and doubtless others) are everything a programming
language/environment should always have been. No need to worry about memory
management, IDEs with auto-completion, and massive built in libraries of
data structures and support functions.

Good riddance to all of the follwing: Managing strings in and memory
allocation in C;

I would ask that you look at the Better String Library for C and C++:

http://bstring.sf.net/

[...] porting C apps across unixes or to windows (all those
nested #ifdefs);

The cygwin port of gcc provides a substantial amount of the UNIX
interface for Windows. I think that writing applications that are
portable between Windows and UNIX/Linux is not as difficult as you
might think, so long as you develop with this in mind.

[...] 16 bit windows programming (near and far, large compact
small, and a memory manager that would allocate you a block of memory but
might move it afterwards);

Yeah, but this is long gone ...

[...] trying to call windows APIs from VB; dll hell;

Ok, but *anyone* who ever wrote a program subject to these problems
has always been short sighted.

socket programming; [...] unix interrupt handlers.

Or semaphores, or gotos ... . I'll grant this point.

[...] languages without exception handling (having to check the return code
of every function);

Again, see the Better String Library for useful standards for error
return code handling (in particular, BstrLib lets you ignore return
codes without leading to fatal problems.)

 

[Cristiano Sadun]

I just listened to an interesting interview with Steve McConnell where he
talked about the differences between a CS degree and what is currently
gaining ground is a Software Engineering degree.

Thanks. The bit about distinction of science and engineering is quite on
target - at least in Europe. My curriculum in CS had quite little to do
with programming and software engineering, and a lot with theoretical
computer science and research-oriented learning.

Now things are changing: there's much more practical stuff in a "CS" course
today - s/e and practical programming are more central (and in Italy they
introduceed a 3-years diploma as an alternative to the 5-years full
course).

 

[Phillip Lord]

Cristiano> "Dale King" <kingd[at]tmicha[dot]net> wrote in
Cristiano>

Cristiano> Thanks. The bit about distinction of science and
Cristiano> engineering is quite on target - at least in Europe. My
Cristiano> curriculum in CS had quite little to do with programming
Cristiano> and software engineering, and a lot with theoretical
Cristiano> computer science and research-oriented learning.

Cristiano> Now things are changing: there's much more practical
Cristiano> stuff in a "CS" course today - s/e and practical
Cristiano> programming are more central

I'm not sure, though, that a university is necessarily a good place to
teach software engineering. The name "engineering" is inaccurate. At
the moment, its far too much of an art. Its something that you need to
learn to some extent by doing, and it's very hard to teach abstracted
from this.

If we really need more programmers (which I think is an open
question), then to me shoving more people through university, to get
more degrees, seems like a poor way to do things.

Phil

 

[Gerry Quinn]

writes:

Cristiano> Now things are changing: there's much more practical
Cristiano> stuff in a "CS" course today - s/e and practical
Cristiano> programming are more central

I'm not sure, though, that a university is necessarily a good place to
teach software engineering. The name "engineering" is inaccurate. At
the moment, its far too much of an art. Its something that you need to
learn to some extent by doing, and it's very hard to teach abstracted
from this.

Programming is a craft, not an art. Engineering is precisely the
formalised study of a craft, and no form of engineering can be
properly taught abstracted from doing.

- Gerry Quinn

 

[Cristiano Sadun]

I'm not sure, though, that a university is necessarily a good place to
teach software engineering. The name "engineering" is inaccurate. At
the moment, its far too much of an art. Its something that you need to
learn to some extent by doing, and it's very hard to teach abstracted
from this.

I wrote a bit on my definition of "engineering" some time ago in

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&frame=right&th=
10e66ae551b47e4a&seekm=Xns94B67AFD56047cristianosadunhotmai%
40195.131.52.135#link6

From that idea, it descends I don't think programming is more of an art
than, say, car engine-building. Of course, doing formula1 engines
efficiently and within budget limits _requires_ a special talent; but
designing day-to-day car engines is very similar to designing day-to-day
software. Or so it should be.

If we really need more programmers (which I think is an open
question), then to me shoving more people through university, to get
more degrees, seems like a poor way to do things.

For going to the university, "getting a degree" is actually quite besides
the point. Knwledege (also of difficulties and their reasons) - and
especially attitude - are what u get from there that you don't from
elsewhere.

A bit of meddling in an enviornment more used to forward thinking as
opposed to one subject to dateline pressure is in my opinion useful.

 

[Andrew Thompson]

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&frame=right&th=
10e66ae551b47e4a&seekm=Xns94B67AFD56047cristianosadunhotmai%
40195.131.52.135#link6

From that idea, it descends I don't think programming is more of an art
than, say, car engine-building.

...whereas shortening Google URL's is a black art.
<http://google.com/groups?th=10e66ae551b47e4a#link6>

Note the '<' '>' around the URL should
preserve a long one, to test the theory..
<http://groups.google.com/[email protected]#link6>

HTH

 

[Chris Sonnack]

Programming is a craft, not an art. Engineering is precisely the
formalised study of a craft, and no form of engineering can be
properly taught abstracted from doing.

What do you consider Architecture (which I consider the closest
analog to Programming)?

I think that--particularly with regard to UIs--there are some very
definite creative aspects to programming.

 

[Nick Landsberg]

Gerry Quinn wrote:




What do you consider Architecture (which I consider the closest
analog to Programming)?

Well, for starters, the term "architect" literally means
"chief technician."

This may lead to another interesting discussion as to
what is "architecture" in the domain of software.
(And, no doubt, Phlip will re-post his humorous
denigration of software architects, but I expect that.

I have my own opinions, and others will have theirs.

For starters, let me paraphrase Christopher Alexander
from "The Timeless Way of Building" as he talks about
architectural elements and relationships between
elements.

[Much Condensed]

" ... a large part of the "structure" of a building
or a town consists of patterns of relationships...

at first, it seems that these patterns of relationships
are separate from the elements ...

.... [but] the elements
themselves are patterns of relationships."

He goes on (and on, and on), to give examples
regarding a church. Saying that, for example,
if the aisle were not aligned in a particular way
it would no longer be an aisle, or if the pews
were facing away from the altar it wouldn't really
be a church, would it?

Bt extension, I would claim that "software architecture"
should be concerned with the relationships of the
elements which comprise a program (or a system
of cooperating programs, or a system of cooperating
systems) rather than the elements themselves.

Comments and discussion welcome.

I think that--particularly with regard to UIs--there are some very
definite creative aspects to programming.

You got me on that one, Chris. Just like the maidservant
who says "I don't do windows", I don't do UI's unless
forced to. It's my blind spot, freely admitted,
but I don't have to worry about it much since almost all
of my work is on what is now called "server side software."
(This doesn't mean I don't have to find a creative
solution to a problem now and then which does not
involve a UI, but I consider that aspect of it
not so much as creative as finding the right algorithm
to do the job.)

 

[Joe Wright]

..whereas shortening Google URL's is a black art.
<http://google.com/groups?th=10e66ae551b47e4a#link6>

Note the '<' '>' around the URL should
preserve a long one, to test the theory..
<http://groups.google.com/[email protected]#link6>

HTH

Thanks for the '<' '>' note. I didn't know that.

 

[Andrew Thompson]

...
Thanks for the '<' '>' note. I didn't know that.

Comes in very handy.

[ Please teach others. ;-) ]