OSDev.org

Dead on the mark. After many years of woe and pain, the guys at HR start to realize this, too. Back in 2000 (my first job application), anyone without a CS diploma was considered a "second-class programmer". Feh.

I agree with Solar about learning C++ early on -- it's a great way to learn about how the machine actually works, and how that relates to programming in a higher-level language. However, I think stopping there would be a mistake. A good introduction to programming should include a survey of other programming paradigms. If Lisp is too weird for beginners, maybe a hybrid OO-functional language like Scala would be more appropriate.

In ten or so years, however, I think teaching C++ will be like teaching people to speak Latin. Sooner or later we're going to stop programming computers like they're sequential Von-Neumann machines and move on to a more parallel programming model. Sequential CPU performance has hit the wall -- we'll have no choice. However, I'm sure that even with this change there will be some middle-of-the-road language that can express higher-level ideas while still allowing you to program to the bare metal, and that language will take on C++'s role as a fancy macro assembler.

Speaking as an experienced software developer with a CS degree, I agree that the quality of CS grads seems to have dropped in recent years since I graduated. I think this has a lot to do with the move from C++ to Java in the curriculum. It's no good to teach just the high-level or just the low-level. To really excel, you have to understand the entire stack, from digital logic (or transistors if you're really gung-ho) up to very high-level functional languages.

I don't think a CS degree is necessarily meant to keep you out of programming. IMO programming is just the most detailed form of design, but it's still design. As the level of abstraction in mainstream languages increases, people will need more theoretical background knowledge to use them effectively. CS gives you the vocabulary to understand and explain such concepts with fewer words:

• "closure" instead of "a function invocation and its environment wrapped together"
• "Lambda expression" instead of "the body of an anonymous function declared directly at the point of use"
• "O(n^2) time" instead of "as the number of items being processed increases, the time it takes to process them increases on the order of the square of the number of items"
• etc....

It's just like design patterns -- a common vocabulary for expressing complex ideas quickly.

BTW Solar, in C++ terms a "closure" would be the result of using something like boost::bind or std::bind1st/bind2nd.

Either the domain language does support something like that, and I would expect anyone on the project (CS degree or no) using the lingo of the domain language (i.e., functor instead of closure).

Or the domain language doesn't support it, and the knowledge that there is something like that in other languages doesn't really cut it.



Now there's something from the CS labs which I expect even a lowly code-monkey to know about.

I might as well list up part of what we get (= what I got) as first year students taking CS at university.

Period 1: Imperative Programming, i.e. Java.
Period 2: Systems architecture. Includes assembly, pointers and everything else I'd wish all programmers would be aware of. Make one class write Java with pointers which then suddenly starts looking a lot like C...
Period 3: Functional Programming; Haskell., data structures.

Considering that, I think this follows the ideas of everyone who posted:
- Start with a relatively easy language
- Learn pointers
- Get an idea of other paradigms
- Learn about all the basic goodnesses and badnesses you might encounter.
Which is apparently enough to get everybody write programs without much effort (which I know from practical experience).

I think that's enough proof-of-concept

Well, apparently we are here. And we're ranked ~40 in the list of best universities around the world. </shameless promotion>

The point is that the concept itself transcends language. "Verbs" exist in all human languages, for example, and knowing what "verbs" are allows you to learn the grammar of other languages more quickly.

To bring it back to C++, "functors" are the closest you can get to "closures" in C++, but they are not first-class features of the language.

Being able to draw comparisons between languages is of huge importance. For every type of problem, there is a way to express the solution in abstract terms that may fit well to some languages, but not to others. If you're trying to solve a problem that you could solve trivially in language A using feature X, but you're forced to use language B, your best bet is often figuring out how to emulate feature X in language B. This is how C++ came to have functors, boost::bind, boost::function, and Boost lambda (although Boost lambda is insane IMO).

What exactly distinguishes a first-class feature from any other feature? Being a part of the language, the standard library or the most common libraries?

Personally (athough I don't know a dictionary definition) I would say a first-class feature is one which is covered/implemented in the grammar of the language. Standard libraries would add second-class features, imho.

Example: regular expressions are available as part of libraries in C/C++.
They are available as first-class features in perl/Ruby:




<shameless retort>Mine's ranked 4th in the UK for Computer Science. How that compares over borders I have no idea.</shameless retort>

To those not that much into C++ and scratching their head on what we're talking about (e.g. because they came to this thread via a search function), a functor is a class with it's operator() being overloaded. Effectively, an object foo of such a class can store information (state), and be called like a function (foo()), thus executing its operator(). A function pointer can be made into a functor with a trivial wrapper call.

Functors - or closures, as C.K. tells us is the more general term - are used in the C++ standard library, especially in the <algorithm> part of the STL. If you know the C style qsort() call (which takes a function pointer for comparing two elements), you can picture where functors can be useful.

That's pretty much it, although a first-class feature is not just syntactic sugar -- it is also built in to the type system and language semantics. For example, calling a an overloaded operator() in C++ is just syntactic sugar -- semantically it is just a method call on an object. In contrast, in a language like Scala, when you take a closure, the result is actually a function that you can call. The equivalent in C++ would be if you could somehow magically get a function pointer returned to you from boost::bind().

If C++ had first-class support for closures and lambda expressions, instead of writing this:

you could write this instead:

Under the hood, everything would work the same as before, but it would be the compiler's responsibility instead of the libraries'. boost::bind(), boost::function(), Boost lambda, and just about everything in <functional> would disappear and code using the STL would be a lot more readable.