The goal was to see how similar code is, and how little it matters which language you pick.
Obviously it's a constrained problem set (we didn't have to learn all the ins and outs of each language) but it really opened our eyes to the "commonness" of programming, and free'd us from the tyranny of "I program in x".
I think this thinking is a mistake. If you learn languages superficially, you will end up writing the same code just with slightly different syntax. It can take a long time to really understand a language and ecosystem and use its capabilities.
But if those languages are C, APL, Erlang, ML and Lisp then I would expect the lesson would be the design space of languages is much larger than the popular imperative languages would have you believe.
On the other hand, differences will start to show them selves after you spend a while noodling with your script, refactoring it a couple of times and deliberately seeking out opportunities to use language-specific features in the process. This expands the exercise to something more like "a language a week" instead of "a language of day", which is obviously a bit more of a time commitment. But if you want to get value out of a "polyglot" programming exercise like this, I think that's what you really need to do. Otherwise I think you learn lessons that are only correct at surface level.
And Java didn't, until relatively recently (oh god Java 8 was almost 10 years ago), have anonymous functions, which means that you'd be more inclined to express solutions in terms of vulgar loops rather than a map, filter, reduce type operation.
Which is to say, they'd definitely look different.
Right, and you can implement a recursive function in Haskell, OCaml, or Scheme that looks more or less identical in all 3 languages, and is only a recursion-transformation away from the for-loop version seen in Python, Ruby, Java, etc. So all the functional recursion-based implementations will look similar, and all the imperative loop-based implementations will look similar, and the two classes of implementations will also have a lot of overarching similarity.
The basic pattern of "obtain system state, do thing, set up next system state, proceed to next thing" is the same. The differences between languages (read: sets of tools that you are given for expressing algorithms) tend not to become apparent until you've spent a little while working with them.
I can't speak specifically to Erlang because I haven't used it, but from what I've seen the story should be the same.
For example: If you're in a language that primarily uses recursion as the primary iteration mechanism, if you have to iterate through every element of a tree you will just about never do a breadth-first search unless it is absolutely necessary. It's just a pain to express recursively compared to a depth-first traversal. In contrast, in an iterative language, a breadth first traversal is the same (somewhat obnoxious) complexity as any other traversal. But that's assuming both languages would be traversing a tree at all: trees are vastly more likely to be used at all in languages where recursion is the norm.
Like, sure, any iterative function of the form:
f(x) = {
state = h(x)
cond = true
while(cond) do
state = j(x,state)
cond = k(x,state)
end
post_work = l(state,x)
return post_work
}
f(x) = l(m(x,h(x)))
m(x,state) = state if k(x,state) else m(x,j(x,state))
Put another way: for(i=0;i<x;i++) loops are common in iterative codebases I've worked on, but it's exceedingly rare to see f(x,i) = blah return f(g(x),i++) in a functional codebase.
I think that’s a pretty bad result of the exercise. The point of software isn’t just to do a thing. Good software should properly encode a domain or idea and communicate that to others.
If one took the analogy of driving a nail into wood, there are many tools that can do the job, but only a couple that properly handle the job. Because the goal isn’t to just drive the nail, it’s to do it efficiently and ergonomically and in a way easily communicable.
* Excluding some deliberately opaque languages like brainfuck and malbolge.
Anyone who's tried hammering a Java-shaped solution into an Haskell-shaped language will eventually see the folly.
I interview a lot of programmers and I often get told that one of my questions is just impossible because it’s slightly awkward to express in Java. (It’s only Java folk incidentally, even though it’s roughly equally awkward to express in most of the long list of languages we let candidates use.) By analogy these are folk that would have to sit around waiting for their hammer delivery rather than just make do with a mallet for a few minutes.
I agree with your point though. I remember being asked a question and I blanked with how to model it in Java. Then I switched mid interview to python and it clicked for me.
obligatory reference to Landin "The next 700 programming languages" (1966)