C++ requires that all overloaded versions exist at compile time; Haskell allows them to exist at runtime. For example, in Haskell you can make a datatype like
data Foo a = Blah a | Bar (Foo [a])
and you'll have no trouble making a function "showFoo :: Show a => Foo a -> String" using straightforward programming. If you try to do that in C++ you'll get infinite template recursion.
Also, C++ templates don't restrict you to match the right type signatures, the way Haskell typeclasses do.
But other than that, they are pretty much the same kind of thing and are used in the same way.
You've mixed together a lot of stuff here. your Foo data type is recursive. I can achieve something similar in C++ without infinite template recursion, but I have to use pointers to do it. (Your Haskell has pointers too, they're just hidden from you.) Also there is nothing 'runtime' about the example you've got here. I can do the same thing with a tagged-union type in C/C++ and a switch statement, which is what your Haskell compiles down to. Maybe you were thinking of existential types? http://en.wikibooks.org/wiki/Haskell/Existentially_quantifie... . That's something C++ can't do.
---------
Edit: nm I see what you did there with the Foo a = ... | Blah (Foo [a]). That would probably break C++.
The problem is that you throw this in your module, and then someone else defines another Array#to_sentence (say in some Natural Language module you require) and all of a sudden you've got hell on earth.
You're actually taking the quote out of context. Getting a C in an art class is different from getting a C in macroeconomics. "Everything" doesn't refer to, say, athletic ability, I'm sure. There's some limitation to the set of abilities involved, centered around mental abilities, and art skills might be outside that limit, in the quotee's mind.
I mean, it's really easy to imagine a "good student" branching out, taking an art class, and getting a C, but it's hard to imagine a "good student" branching out, trying macroeconomics, and struggling.
I certainly can imagine a curious student taking macroeconomics and get so utterly bored and annoyed that he gets a C. In my case the course was "Entrepreneurship" and while the course itself was (mostly) interesting and inspiring, the test at the end was stupid and I recieved a C (well, something equivalent in Germany).
Now i'm thinking whether look for a job is the right way or whether I should rather look for a cofounder.
However, it's also easy to imagine someone taking a class and discovering he simply wasn't interested in it (or thought it was complete bull), only finishing the class to get the credit. It is silly to judge people by an occasional C amidst A's.
In C# 3, the verbosity level is much less than in C# 2, where it's slightly less than C# 1.
I don't see where Ruby syntax is particularly more concise than C# 3's.
Well, let me clarify "particularly". I don't find myself feeling like I'm suffering under C#'s syntax, relative to Haskell's. It has about the same amount of syntactic overhead: writing types for method parameters, and when defining data structures. Occasionally I have to explicitly write a type parameter to a function.
Of course, "UpTo" requires first extending int, which is trivial:
public static class IntExtensions {
public static List<int> UpTo(this int start, int end) {
var range = new List<int>();
for(int i = start; i < end; i++) {
range.Add(i);
}
return range;
}
}
This is a fairly uninteresting example, however. Something more interesting would be, for instance, the use of structural types to implement type-checked duck typing.
Scala example:
// Declare a structural type for any class implementing close()
type Closable = {def close(): Any}
// Executes the provided function with the given
// closable generator, creating a new instance which
// will then be closed on completion. The provided
// function's value will be returned.
def withClosable[T, C <: Closable] (c: => C) (f: (C) => T) = {
val closable = c
try {
f(closable)
} finally {
closable.close
}
}
// Example usage
def usage = {
val updated = withClosable(db.openConnection) { conn =>
conn.update("INSERT INTO example VALUES (...")
}
System.out.println("Rows updated: " + updated)
}
This could be compared with Python's new 'with' syntax.
> Requiring a degree in CS, SE, or EE (I don't see the point of requiring a degree if it's not directly related to the field) does exactly this.
But it doesn't. There are plenty of people with CS or SE degrees that lack a minimal level of understanding. Even with a terribly lenient definition of minimal.
I'm talking about people who get through 4 years of a decent CS program and would vehemently insist that "array" is an exact synonym for "linked list".
I'd say that the benefit of a CS degree is weaker -- just that it brings forced exposure to important topics, so if you have two people who are smart, the one with a CS degree is going to be more well-rounded. The thing is, you usually don't get to decide between two smart people when hiring. And the CS degrees that are around don't seem to reduce the risk of bugmaking.
Having had a lab partner who in Senior year EE couldn't do even the most basic things, I sympathize with you. But you need to consider what that person knows "as a whole." I've found that if you take the time to talk to graduates who were poor students that they do have a basic understanding of the subject matter, but there are gaps. The gaps tend to be most noticeable when they're really simple things, which I think is the point you're making.
Contrast that with someone who has say, a History degree who happens to be a good programmer. That person's expertise tends to be in one narrowly defined area and when taken outside that range he does badly. I'd rather hire someone who had promise to be reasonably good at anything I threw at him than amazing in one aspect and weak at most everything else.
I don't know where you work, but the people who make it through both our HR screen and the technical phone screen and end up in front of me are generally pretty bright. We normally weed people out for teamwork/communication skills rather than technical ability.
Next time you turn down someone with a History degree that has become a coding expert in a narrowly defined area, please send them to me so we can collaborate on something that rocks in another narrowly defined area.
You're misinterpreting reality with that quote, because labor that produces inherently more valuable goods is inherently more valuable labor than labor which does not. Part of the wealth that goes into the peanuts and book is the extremely valuable labor of finding out who needs what resources.
