4 ms·

We did a similar assignment at University many years ago. I think it was the same assignment, one per day for two weeks. Each time in a different language. The

We did a similar assignment at University many years ago. I think it was the same assignment, one per day for two weeks. Each time in a different language. 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".

deleted 4y ago
[deleted]
aebtebeten 4y ago
> how little it matters which language obligatory reference to Landin "The next 700 programming languages" (1966) https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf
ModernMech 4y ago
Curious which languages you used. If they were C, C++, Java, and Python then I could see how they could blur together if you squint. Different syntax, similar semantics. 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.
- dfinninger 4y ago
  Sure, but in university that can be a useful exercise, whatever the language. There are many commonalities in just about every language. Learning your first language is hard, you’re second is freeing. At least personally I’ve found that the more languages I study, the easier it gets to pick up a new one, specifically because of the commonalities. Sure, Haskell and Ruby are really different, but when you try to pick up Elixir you’ve got a lot of common ground.
  - goatlover 4y ago
    Languages like APL, Forth and Prolog are different enough that this wouldn't apply until you learn another array, stack, or logic-based language. And with languages like Smalltalk or Lisp, learning how to use the environment will be just as challenging.
- nerdponx 4y ago
  APL might be an outlier here. For the rest, I think the difference lies more in the standard libraries of those languages than the languages themselves. Yes, differences in core language design start to matter when you are considering performance, or structuring larger applications, but for simpler scripts, you're mostly dealing with the standard library. 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.
  - OkayPhysicist 4y ago
    Erlang doesn't have loops. You've got filter, map, reduce, and recursion. It's safe to say for most programs that your Erlang solution is going to look rather different than your ALGOL family one. 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.
    - nerdponx 4y ago
      > You've got filter, map, reduce, and recursion. 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.
spikej 4y ago
We did the same but the idea was to do it in different paradigms: iterative, OO, functional, etc. And the code was very different
- deleted 4y ago
  [deleted]
galangalalgol 4y ago
Even for a one day task it seems language choice could make it much easier or harder depending on the nature of the task. Text formatting and parsing, vector/tensor math, parallelism, network io, all those things vary drastically in difficulty depending on the language chosen. Then, if there are any performance constraints on the problem that is another clear discriminator.
bmitc 4y ago
> The goal was to see how similar code is, and how little it matters which language you pick. 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.
- WJW 4y ago
  You can write good software in almost* any language though. Encoding of domain and/or clear coding style is mostly orthogonal to language syntax. The OPs exercise is exactly to show that language choice is not all that important, since you can write good software in bad languages and you can write bad software even in the best languages. * Excluding some deliberately opaque languages like brainfuck and malbolge.
  - OkayPhysicist 4y ago
    I would describe programming languages less as encoding problem domain, and more of encoding/enabling solution domains. For example, if you're in Java the language steers towards defining objects that have methods that express your solution, where as in Haskell you'd be more inclined to your solution in terms of a composition of functions. At a lower level, your Java program is more likely to use loops and iteration whereas your Haskell program is more likely to use a recursive solution. Anyone who's tried hammering a Java-shaped solution into an Haskell-shaped language will eventually see the folly.
- ketralnis 4y ago
  I think you read a comment that they didn’t write. But to take your argument there is still value there. Learning that the goal is to get the nail into the wood and give you a tour of some ways to do that provides different value to practising your memorised best practise of 3/8” 95% iron alloy hammer swings at 20 degree arcs 1.2 times per inch of nail bed. Maybe that’s valuable too but you need to know both. 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.
kfir 4y ago
You can get a taste here and decide if you want to go deeper or not - https://github.com/mattmight/advent-of-code-2022/tree/main/day-2 https://github.com/mattmight/advent-of-code-2022/tree/main/d...
rr808 4y ago
Most languages have completely different idioms though. Sure you can write functions, loops, if statements the same in dozens of different language syntaxes, but that doesn't prove anything. I've seen loads of codebases written completely backwardly, eg when a C++ programmer writes their first Python app or a Java developer writes Javascript - they're just writing the same style in a different language, not writing idiomatical correct code as a Python or JS developer would.
- TrueSlacker0 4y ago
  ... and it's amazing how it works perfectly fine for a basic 1 day program as the og author needs. No need to make it "idiomatically correct"
rqtwteye 4y ago
"The goal was to see how similar code is, and how little it matters which language you pick." 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.
- TrueSlacker0 4y ago
  While I mostly agree, A program this "basic" is not going to go far enough to learn anything that pushes any language far enough to learn it's limits.
  - rqtwteye 4y ago
    Which means it's an almost useless exercise.

deleted 4y ago

[deleted]

aebtebeten 4y ago

> how little it matters which language obligatory reference to Landin "The next 700 programming languages" (1966) https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf

ModernMech 4y ago

Curious which languages you used. If they were C, C++, Java, and Python then I could see how they could blur together if you squint. Different syntax, similar semantics. 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.

dfinninger 4y ago
Sure, but in university that can be a useful exercise, whatever the language. There are many commonalities in just about every language. Learning your first language is hard, you’re second is freeing. At least personally I’ve found that the more languages I study, the easier it gets to pick up a new one, specifically because of the commonalities. Sure, Haskell and Ruby are really different, but when you try to pick up Elixir you’ve got a lot of common ground.
- goatlover 4y ago
  Languages like APL, Forth and Prolog are different enough that this wouldn't apply until you learn another array, stack, or logic-based language. And with languages like Smalltalk or Lisp, learning how to use the environment will be just as challenging.
nerdponx 4y ago
APL might be an outlier here. For the rest, I think the difference lies more in the standard libraries of those languages than the languages themselves. Yes, differences in core language design start to matter when you are considering performance, or structuring larger applications, but for simpler scripts, you're mostly dealing with the standard library. 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.
- OkayPhysicist 4y ago
  Erlang doesn't have loops. You've got filter, map, reduce, and recursion. It's safe to say for most programs that your Erlang solution is going to look rather different than your ALGOL family one. 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.
  - nerdponx 4y ago
    > You've got filter, map, reduce, and recursion. 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.

spikej 4y ago

We did the same but the idea was to do it in different paradigms: iterative, OO, functional, etc. And the code was very different

deleted 4y ago
[deleted]

galangalalgol 4y ago

Even for a one day task it seems language choice could make it much easier or harder depending on the nature of the task. Text formatting and parsing, vector/tensor math, parallelism, network io, all those things vary drastically in difficulty depending on the language chosen. Then, if there are any performance constraints on the problem that is another clear discriminator.

bmitc 4y ago

> The goal was to see how similar code is, and how little it matters which language you pick. 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.

WJW 4y ago
You can write good software in almost* any language though. Encoding of domain and/or clear coding style is mostly orthogonal to language syntax. The OPs exercise is exactly to show that language choice is not all that important, since you can write good software in bad languages and you can write bad software even in the best languages. * Excluding some deliberately opaque languages like brainfuck and malbolge.
- OkayPhysicist 4y ago
  I would describe programming languages less as encoding problem domain, and more of encoding/enabling solution domains. For example, if you're in Java the language steers towards defining objects that have methods that express your solution, where as in Haskell you'd be more inclined to your solution in terms of a composition of functions. At a lower level, your Java program is more likely to use loops and iteration whereas your Haskell program is more likely to use a recursive solution. Anyone who's tried hammering a Java-shaped solution into an Haskell-shaped language will eventually see the folly.
ketralnis 4y ago
I think you read a comment that they didn’t write. But to take your argument there is still value there. Learning that the goal is to get the nail into the wood and give you a tour of some ways to do that provides different value to practising your memorised best practise of 3/8” 95% iron alloy hammer swings at 20 degree arcs 1.2 times per inch of nail bed. Maybe that’s valuable too but you need to know both. 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.

kfir 4y ago

You can get a taste here and decide if you want to go deeper or not - https://github.com/mattmight/advent-of-code-2022/tree/main/day-2 https://github.com/mattmight/advent-of-code-2022/tree/main/d...

rr808 4y ago

Most languages have completely different idioms though. Sure you can write functions, loops, if statements the same in dozens of different language syntaxes, but that doesn't prove anything. I've seen loads of codebases written completely backwardly, eg when a C++ programmer writes their first Python app or a Java developer writes Javascript - they're just writing the same style in a different language, not writing idiomatical correct code as a Python or JS developer would.

TrueSlacker0 4y ago
... and it's amazing how it works perfectly fine for a basic 1 day program as the og author needs. No need to make it "idiomatically correct"

rqtwteye 4y ago

"The goal was to see how similar code is, and how little it matters which language you pick." 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.

TrueSlacker0 4y ago
While I mostly agree, A program this "basic" is not going to go far enough to learn anything that pushes any language far enough to learn it's limits.
- rqtwteye 4y ago
  Which means it's an almost useless exercise.