5 ms·

Back in university (1974), I took a course in AI. The prof wanted us to write a brute-force solution to solve the 8-queens problem -- any language! I wrote the

Back in university (1974), I took a course in AI. The prof wanted us to write a brute-force solution to solve the 8-queens problem -- any language! I wrote the solution in APL in about an hour and it only had 3 lines of code. The rest of the class spent days on their terminals and keypunches trying to solve it. Most solutions took hundreds of lines of code. I got a D from my professor. I questioned why and was told that it was unreadable, and that the solution was inefficient. This annoyed me because he didn't know APL, and I figured that since I solved the problem in one hour, while the rest took days, it was very efficient. I protested the result with the department head (who liked APL) and ended up getting an A+. As you can imagine, all the rest of my assignments, written in a variety of languages, were graded by that AI prof with significant prejudice. I passed nonetheless. I loved APL and ended up working for one of the major APL providers as my first job out of school.

coopreme 5y ago
Great story, it’s stories like these that make me still hold onto my undergrad work (as bad as it is). Maybe one c#, Visual Basic, asp, php, t-sql and other esoteric projects will be looked at as relics of the past.
S4M 5y ago
> I got a D from my professor. I questioned why and was told that it was unreadable, and that the solution was inefficient. That is such a bad faith argument, how can a brute force solution be efficient or inefficient?
- jiggawatts 5y ago
  Constant factors, heuristics, memory usage, etc... There was a discussion on array programming languages here recently where someone proudly showed off a K language solution to a simple problem, stating that the K solution was efficient because it could solve it in 1.2 microseconds. I used Rust to solve it in 5.5 nanoseconds, which is nearly 200x faster. Both used "brute force" with no cleverness, but there's "bad" brute force and "good" brute force. I've had a similar experience at university while using Haskell. It's a very elegant lazy pure functional language, but it's glacially slow. The natural, low-friction path is very inefficient. The efficient path is unidiomatic and verbose. I hear people making similar observations about F# also. It's fast to program in, but if you also need performance then it is no better than more mainstream languages -- in fact worse in some ways because you're "going against the grain".
  - whb07 5y ago
    Compared to Rust/C/C++? Sure! But Haskell vs most others, it’s faster and compiles down to a binary executable. F# runs on .NET and is comparable to Haskell but not AOT.
    - jiggawatts 5y ago
      This is magical thinking. Compilation doesn't magically eliminate Haskell treating all lists as linked lists. It's an inherent aspect of the language.
      - lmm 5y ago
        Calling Haskell "glacially slow" is grossly misleading when there are languages like Python and Ruby in common use.
        whb07 5y ago
        Exactly! Where is the nuance here plus he’s not exactly mentioning what he’s comparing it to.
        mumblemumble 5y ago
        I think that the nuance here was perfectly obvious, if not explicit, to everyone who wasn't busy burying it under a pile of whataboutism. I would also say that I wouldn't be at all surprised if idiomatic Python is actually quite a bit faster than idiomatic Haskell in some interesting use cases. Which does not at all mean that the opposite is true. There are always interesting cases that make good fodder for "what about" comments, but getting carried away with them doesn't really make for particularly edifying discussion. Just mentally append "in my experience" to everyone's comments and move on.
        lmm 5y ago
        > I would also say that I wouldn't be at all surprised if idiomatic Python is actually quite a bit faster than idiomatic Haskell in some interesting use cases. Which does not at all mean that the opposite is true. I'd be utterly amazed. Haskell is orders of magnitude faster than Python for "typical" code (having to do a hash lookup for every method invocation ends up being really costly). It's not a slow language by any reasonable definition. And the fact that you're suggesting it is suggests that the nuances are not at all obvious. (Not trying to hate on Python - performance is a lot less important than most people think it is - just trying to put Haskell's performance characteristics in a familiar context)
travisjungroth 5y ago
> I questioned why and was told that it was unreadable, [...] this annoyed me because he didn't know APL. I often tell people that Spanish is unreadable if you don't know Spanish. This also applies to language features! It's only fair to call things "unreadable" if you have the full context to understand but still find it hard.

coopreme 5y ago

Great story, it’s stories like these that make me still hold onto my undergrad work (as bad as it is). Maybe one c#, Visual Basic, asp, php, t-sql and other esoteric projects will be looked at as relics of the past.

S4M 5y ago

> I got a D from my professor. I questioned why and was told that it was unreadable, and that the solution was inefficient. That is such a bad faith argument, how can a brute force solution be efficient or inefficient?

jiggawatts 5y ago
Constant factors, heuristics, memory usage, etc... There was a discussion on array programming languages here recently where someone proudly showed off a K language solution to a simple problem, stating that the K solution was efficient because it could solve it in 1.2 microseconds. I used Rust to solve it in 5.5 nanoseconds, which is nearly 200x faster. Both used "brute force" with no cleverness, but there's "bad" brute force and "good" brute force. I've had a similar experience at university while using Haskell. It's a very elegant lazy pure functional language, but it's glacially slow. The natural, low-friction path is very inefficient. The efficient path is unidiomatic and verbose. I hear people making similar observations about F# also. It's fast to program in, but if you also need performance then it is no better than more mainstream languages -- in fact worse in some ways because you're "going against the grain".
- whb07 5y ago
  Compared to Rust/C/C++? Sure! But Haskell vs most others, it’s faster and compiles down to a binary executable. F# runs on .NET and is comparable to Haskell but not AOT.
  - jiggawatts 5y ago
    This is magical thinking. Compilation doesn't magically eliminate Haskell treating all lists as linked lists. It's an inherent aspect of the language.
    - lmm 5y ago
      Calling Haskell "glacially slow" is grossly misleading when there are languages like Python and Ruby in common use.
      - whb07 5y ago
        Exactly! Where is the nuance here plus he’s not exactly mentioning what he’s comparing it to.
        mumblemumble 5y ago
        I think that the nuance here was perfectly obvious, if not explicit, to everyone who wasn't busy burying it under a pile of whataboutism. I would also say that I wouldn't be at all surprised if idiomatic Python is actually quite a bit faster than idiomatic Haskell in some interesting use cases. Which does not at all mean that the opposite is true. There are always interesting cases that make good fodder for "what about" comments, but getting carried away with them doesn't really make for particularly edifying discussion. Just mentally append "in my experience" to everyone's comments and move on.
        lmm 5y ago
        > I would also say that I wouldn't be at all surprised if idiomatic Python is actually quite a bit faster than idiomatic Haskell in some interesting use cases. Which does not at all mean that the opposite is true. I'd be utterly amazed. Haskell is orders of magnitude faster than Python for "typical" code (having to do a hash lookup for every method invocation ends up being really costly). It's not a slow language by any reasonable definition. And the fact that you're suggesting it is suggests that the nuances are not at all obvious. (Not trying to hate on Python - performance is a lot less important than most people think it is - just trying to put Haskell's performance characteristics in a familiar context)

travisjungroth 5y ago

> I questioned why and was told that it was unreadable, [...] this annoyed me because he didn't know APL. I often tell people that Spanish is unreadable if you don't know Spanish. This also applies to language features! It's only fair to call things "unreadable" if you have the full context to understand but still find it hard.