Fog Creek Software
Discussion Board




What should programmers learn first

The automatic vs manual debate that developed in the religous debate thread earlier contains a few assertions that all programmers should learn C first.  It all got a bit messy, so I decided to take it back to the top.

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=77677

Personally I disagree.  I think C should be avoided at all costs and all programmers should be taught set theory before being allowed near a development environment.

What do you think is the fundamental knowledge that all programmers should have?

Ged Byrne
Wednesday, October 15, 2003

I think that programmers should have knowledge of indirection, as the more I learn, the more I think that it's *the* fundamental idea in computing.

John Topley (www.johntopley.com)
Wednesday, October 15, 2003

I think programmers should be taught to continually learn and be open minded about what they need to know.

Len Holgate
Wednesday, October 15, 2003

Actually you're right. I think they should be taught that being able to find out things for yourself is more important than knowing everything.

John Topley (www.johntopley.com)
Wednesday, October 15, 2003

Why on earth do you think programmers need to know Set Theory? I've don't think I've ever used it while programming.

Mr Jack
Wednesday, October 15, 2003

The principles of Relational Databases and Object Oriented Design are based on Set Theory.

At university we did a course on Set Theory in the first semester, and grumbled all the way.  Years later I am beginning to understand why we were wrong.

Ged Byrne
Wednesday, October 15, 2003

I studied maths, not computing, at university. We did A LOT of set theory, I found it fascinating but I really don't see the relevance to computing. You may well be able to apply set theory to OOD, but I fail to see any actual need to do so. I'm not so familiar with relational databases so I will refrain from comment there.

What do you see as the benefit you gain from knowing set theory when attempting Object Orientated Design?

Mr Jack
Wednesday, October 15, 2003

Well I'd say C first, and then set theory. If you learn set theory first you will not understand why you are learning it, and therefore, assume that it must be a waste of time.

Fernanda Stickpot
Wednesday, October 15, 2003

Old basic, Logo, or Python without the OO constructs. Then go to assemly, and only then consider a modern high level language with all the shiny things.

I would have suggested assembly first, except that it isn't practical for the uninitiated, whereas old Basic, Logo and Python are.

You always need to know at least one layer below what you work with, in order see through the "leaky abstractions" that are always there; And people tend to abstract new things in term of all things.

Yes, I have heard someone describe a C function call as "a method call, except that it doesn't have an object", and he later said that's how he envisions it.

Some people can break away from misconceptions, and some won't. For the benefit of the latter, it's important to do things in the "right" abstraction order as much as realistically possible.

Ori Berger
Wednesday, October 15, 2003

"in terms of all things" -> "in terms of old things they know".

Ori Berger
Wednesday, October 15, 2003

Logic. Particularly propositional logic.


Wednesday, October 15, 2003

For me the most useful things were assembly language, on the one hand, and cognitive linguistics on the other. Everything else has fallen somewhere in between.

The Real PC
Wednesday, October 15, 2003

When you've developed a variety of pieces of software on different platforms and using different tools, the differences start to pale into insignificance compared to developing talents at writing high-quality software first-time round and being able to use debugging/tracing/analysis tools to identify problems.

For example, Java, C++ and VB programmers usually despise each other, but :

  Area = 16
  Height = 0
  Width = Area / Height

is the same problem in any language/environment/O/S. There's a divide by zero - which can cause an error/exception or be quietly ignored.  The program still won't work though.

So, learn how to write and fix programs in any language/environment.

James Wilkinson
Wednesday, October 15, 2003

If somebody asked me what to do to become a programmer, I would tell them to spend a year going through SICP.  Then I would tell them to spend a year learning whatever commercial environment the wanted to work in.


Wednesday, October 15, 2003

<Offtopic>
Any good books to recommend on Set Theory and Databases?

Wanna learn, wanna learn...
</Offtopic>

Karel
Wednesday, October 15, 2003

Jeffery D Ullman's "Principles of Database and Knowledge Base systems" will tell you a lot about databases, from the theoretical (set, relation, and others) and practical points of view.

Ori Berger
Wednesday, October 15, 2003

Mr Jack,

Then I am probablay using the wrong term.

My main point is that software design should be about modeling, not moving around bytes.

Langauges like C are all about manipulating bytes, and this is where the problems come from.

Take characters for example.  C encourages the programmer to see characters as bytes.  When manipultaing strings, they are just manipulating bytes.  This all leads to the nightmare we now have with all these leaky abstractions and conflicting standards.

Ged Byrne
Wednesday, October 15, 2003

Now that I can agree with. In modern programming languages, I find the most significant difference between good and bad programmers is whether they solve the problem or the code.

Mr Jack
Wednesday, October 15, 2003

There are enough essential differences between set theory and object orientation theory that it is a bad idea to study the former as an introduction to the latter.

Many students assume that sub-classing (OO) maps to subsetting (set theory), which is provably false. It takes many months to stamp this out.

Karel Thönissen
Wednesday, October 15, 2003

There are two things a programmer should learn:

1. How to play chess, and play it well. It's good for distraction and relaxation. The problem solving aspects are also good practice.

2. How to get to the nearest beer serving establishment, and what they have on tap. While my computer's CPU is air cooled, mine is definitely liquid cooled.

Clay Dowling
Wednesday, October 15, 2003

> the most significant difference between good and bad programmers is whether they solve the problem or the code.

This is a good statement of the problem. I think one failure of current education and hiring policies is to accept facility with a programming language as evidence of ability to design and develop software, when it isn't.

So in my view the most important thing to learn is how to think.

JM
Wednesday, October 15, 2003

I don't know what the programmer should learn first, but under no circumstances should the beginning programmer be allowed to learn first either Java or C++. They are both horrible languages for the starting programmer.

Java is bad because it doesn't make pointers/references obvious, so there is a tendancy to not learn the difference between pass by value and reference. This happens a lot and is a huge handicap.

C++ is just too damned big. I think there's enough gotchas in it that unless you have them read all of Stroustroup and Meyer's books, they will be outright dangerous programmers.

I don't see a reason to really avoid anything else in particular, though it would probably be best to keep it a practical language.

Mike Swieton
Wednesday, October 15, 2003

Note: any language that doesn't make pass by reference clear to the programmer should be avoided. Java is just the one they teach here, so it came to mind first.

Mike Swieton
Wednesday, October 15, 2003

For theory, programmers should learn not just set theory, but various aspects of discrete mathematics.

For a first hands-on language, a NON-drag-and-drop version of BASIC which includes POKE and PEEK should give a good introduction to programming logic and concepts of memory locations, without the shock value of C or Assembly.

T. Norman
Wednesday, October 15, 2003

I don't get payed for each time I mention OOSC/2. But really, I'd start with a very basic introduction of procedural languages, and then put all the emphasys in Object Oriented Software Development, using the Eiffel language as the most suitable option (*way* more suitable than C++, Java or C#).

There's always time later to learn those inferior languages <g> and to dive into advanced topics.

Even if you later write production code in the "real" world, in C++ or .NET, you'll do better if a correct OO method is in your mind.

A bad start must not be crucial, anyway. Most of us started badly, and here we are.

Daniel Daranas
Wednesday, October 15, 2003

Why are you all presuming that a "programmer" is a useful concept.

Surely there are so many differences in what "programmers" do, that it is pointless talking about a general introduction.

Stephen Jones
Wednesday, October 15, 2003

There are a class of programmers that will never
know the deeper concepts because they don't
really need to and they don't really care. I can drive
yet do not have a firm grasp of the mechanical details.
So all the lower level details that geeks love can
be bypassed.

Progammers need to learn how to make their
environment do what they want to do. Not sure
what this means exactly.

son of parnas
Wednesday, October 15, 2003

"A bad start must not be crucial, anyway. Most of us started badly, and here we are."

Most programmers started badly.  But most programmers are also crappy.  And when you talk to them, some of them implicitly reveal that their crappiness is due to fundamental concepts that are missing because of gaps in their early programming experiences that were never filled in.

T. Norman
Wednesday, October 15, 2003

"I can drive yet do not have a firm grasp of the mechanical details."

Taxi drivers don't need to know the mechanical details, but mechanics do.  As programmers we are the mechanics of computers, at least where the software is concerned.

T. Norman
Wednesday, October 15, 2003

My programming 101 course (at university) was taught by by one of the leading lights of proving programs correct and we used a blackboard language converting into pascal.

At the time OO languages weren't around (actually we did do smalltalk but that was much later on, C++ was just available at that time)

Personally I think I'd suggest that programmers start with C-like language but running in a CPU sandbox ala Java.

I think it should have:
char= 9 bits
int = 18 bits
long=36 bits
ptr=32 bits

along with a pile of obscure alignment rules for data and ptr addresses should be gray coded when converted to and from longs:

i.e.
char *my_ptr;
int i;

my_ptr=(char *) 3L;
for (i=0;i<5;i++) printf ("%p,",my_ptr++);
printf ("\n");

would produce:

3,2,6,7,5

It should dump core on access to unallocated memory, have proper readonly access for static strings (via a segmented memory model) and the debugger should be assembler mixed with C statements (ala symdeb for those who remember it on MSDOS)

This is mainly to remind folks that a C char ain't always 8 bits and that pointers aren't always interchangeable with longs.

It certainly wouldn't be C as most folks would know it but I think you could write an ANSI conforming compiler.
I'd like to throw in a scheme where strings are 6 bit packed for I/O but by then you start to diverge too much from the "normal" C library.

The other alternative would be the little 4 bit processor language that toshiba had that was kinda like C but that causes too many horrors over stack frames.

Peter Ibbotson
Wednesday, October 15, 2003

Programmers should learn a nice structured and abstract language at the very beginning so they can learn design.

Smalltalk, Scheme, or even Python would make a good language for this.

At some point along the way, they need to learn assembley language.  But not first, because I think that it's easier to teach the nitty-gritty details of assembley to somebody who's already learned structure than the other way around.

I think that using a language without automatic memory management is very important because it teaches good habits that are still useful when you have your memory garbage-collected.

I don't see learning C a necessety anymore.  I do see learning C++ a necessity, but I also do 95% of my coding in C++ so I'm biased.  The big one is that almost all of the important programming languages in the "real world" right now have C-like syntax, so you really should know at least one language in the tree, but C isn't necessary.

Flamebait Sr.
Wednesday, October 15, 2003

I would tell a beginning programmer today to get an MBA and learn how to manage off shore software projects.

Unless the beginning programmer lives in India.

Jim Rankin
Wednesday, October 15, 2003

"The big one is that almost all of the important programming languages in the "real world" right now have C-like syntax, so you really should know at least one language in the tree, but C isn't necessary."

A lot of modern programming languages were probably written in C, too.  Also, if you're writing drivers, kernel modules, etc., C is probably indispensable.

Jim Rankin
Wednesday, October 15, 2003

They should learn to avoid programming forums - so that they actually get some work done!

Nick
Wednesday, October 15, 2003

how to use google, and say "I charge one hundred seventy five dollars per hour" with a straight face.

rz
Wednesday, October 15, 2003

Daniel,

I'm about a quarter of the way through OOSC/2 and it really is an eye opener for me.

It was during the chapter on ADTs that I suddenly realised just how important that almost forgotten course on set theory really was.

When I think of all the time I've spent trying to understand just what a class is, and how it should be used...

Then again, if I hadn't been through that stuggle, I probably wouldn't have appreciated OOSC/2.

Ged Byrne
Wednesday, October 15, 2003

I think programmers should first learn a language that
will be easy, fun, and have quick development time. Something like Perl/Python/Ruby would be perfect. I disagree with Joel that C should be the first language, because it is very hard and requires a lot of understanding of how the machine level operates, as well as basics, that are best acquired from other languagages.

I do think everyone should learn C eventually, though. Actually, the more languages one learn, the better.

Shlomi Fish
Wednesday, October 15, 2003

Humility

braggart
Wednesday, October 15, 2003

Ged,

A quarter of OOSC/2 is roughly where design by contract is - enjoy! :-)

I'm now at chapter 30 and I'm already applying the ideas I learned in previous chapters to my production code. I was even joking to my workmates "This code I wrote is correct, though I'm not sure about the style since I haven't yet got to chapter 26".

Saying these things might seem counter intuitive to some in our "highly competitive" software world - "what?! you haven't even *finished* reading OOSC/2?". The policy seems to be to pretend you know everything. Hint: You don't know everything. Noone does. I'm learning and I'm eager to learn more every day. I'd love to know Ruby or to read the "Design Patterns" book soon. The worst thing a programmer can do is pretend they've seen it all. But if someone ignores the fundamental OO concepts, I really don't care how much years of SQL experience they have or even how many languages they know - they'll be bad at all of them.

Someone said programmers are sloppy as a consequence of a never corrected bad beginning. Well, reading OOSC/2 I found out there's always time for a change and as you say, having previous bad experiences makes the enlightenment even better. This, however, shouldn't keep us apart of the fundamental objective of teaching the right things from the start.

By the way, see chapter 29 - "Teaching the method" :-)

Daniel Daranas
Wednesday, October 15, 2003

1) basic
2) assembly
3) C
4) C# or Java

but, more important is learn to learn and to never stop learning.

Augusto
Wednesday, October 15, 2003

First thing to teach a programmer? Yourdon loops & Structured programming... language? anything that allows for yourdon loops and structured programming.

Myself, I was taught these using Pascal in my first year, then C & C++ in 2nd a 3rd.

After 3 years of study at a tech colledge I went to uni and the first thing they tried to teach kids straight out of high school was OOP using Smalltalk... I couldn't believe it...
OOP before basic programming structure... just crazy.

As for language? Language means nothing. I can take any language you give me and be up and running in a couple of weeks. I can do that because I know the basics...

Jack of all
Thursday, October 16, 2003

Depends on the age, interests, background, and goals of the programmer.

12 year old kids?

University freshmen?

ITT freshman?

All these might give different answers.

The set theory thing though seems just plain weird. Didn't we study set theory in third grade? Unions? Intersections? Null set? Seems arithmetic would be a better thing to have down if we're going back that far.

Dennis Atkins
Thursday, October 16, 2003

Ged,

>> What do you think is the fundamental knowledge that all programmers should have? <<

Interesting question. For me, every developer should learn how and why software systems fail.

Mark

Mark Pearce
Thursday, October 16, 2003

*  Recent Topics

*  Fog Creek Home