1,002 karma · joined July 1, 2015
This has always been the case for mathematicians. People that just learn how to do computations are called engineers.
Algorithms encoded as a program end up as an abstract syntax tree in the compiler. Algorithm -> Data structure. The compiler then turns that ast into some other representation (e.g. machine instructions, JavaScript) which is again the algorithm. Data structure -> algorithm. Bijection identified.
sazerac = do
add ice
add ryeWhisky
add bitters
add absinthe
shake
strainInto glass
add lemonGarnish
main = serve $ makeCocktail sazeracFirst of all, is this a solo project or is a group of people going to be working on it? If it's a solo project, then you are far less constrained. If it was a small proof of concept or otherwise throwaway project, I'd probably use it as an opportunity to try a new language. If it's a real deliverable and doesn't involve hard real time performance, I'd choose Haskell because it's a language with which I'm proficient and I enjoy using.
If this project is going to be developed and maintained by more than just myself, then the story changes. With an existing group of developers, you have to play to their strengths and get buy-in, so use either a language they already know, something similar, or something they've shown an interest to learn. If you don't yet have developers, consider the difficulty of hiring for certain technologies. There are also performance and correctness requirements to consider.
If you happen to be an enterprise decision maker (which is unlikely since this is a community for intelligent critical-thinkers) then the only correct choice is Java. No one gets fired for choosing Java. There's a framework for everything. There are plenty of cheap developers. It's popular, so it must be good.
This article raises some valid points, though. One that resonates most with me is that git exposes its entire model. I really wish there was a git-lite that just had the few basic commands that junior developers can grok and not fuck up so I wouldn't have to waste my time explaining the same stuff for the umpteenth time.
Ok, enough sarcasm. What is really interesting about this is that the old saying "history is written by the winner" may have to be changed to "history is auctioned off to the highest bidder".
You might also be interested in:
https://hackage.haskell.org/package/djinn
Djinn writes the code for you. Cut out the middle-man. (Don't show your boss.)
Interestingly, my father did his best to instill this lesson with his persistently defeatist and pessimistic outlook on everything.
I now (in my 30s) make more than both of my parents combined.
The good old days! I've been a desktop Linux user for going on a decade. Yes, it used to be a mess. Something only someone with technical acumen, enormous amounts of free time, and an endless supply of patience would subject themselves to. It's amazing how much has changed. Maybe I was lucky. I transitioned from 'student with plenty of time to mess around with my computer' into 'adult who actually needs to get work done' at around the time that Linux desktops were becoming mature. I've been using Ubuntu for the last two years and rarely have problems. Granted, I'm not a typical computer user. I don't need everything dumbed down and made pretty. I need a stable and reliable system that I have complete control over. It doesn't hurt that any software I need is an 'apt-get install' away as well.
So thank you Linux, and thanks to all the developers that contribute to the ecosystem.
> of how much value is a rigorous type system?
It saves a lot of time on those tests you won't have to write and maintain just to ensure that you're getting your types correct. Strong static types are also good documentation. Some type systems (e.g. Haskell) can even explicitly indicate whether a procedure is pure or has effects. Static types also enable dispatch that can be resolved at compile-time, resulting in more efficient execution. And the list goes on.
Of course, advocates of languages without static types have heard and dismissed all these arguments before. I guess it's really just a matter of taste.
This is not going to change.
I love Haskell, and I appreciate the effort many are making to evangelize the language, but I am experienced (ie. cynical) enough to believe that it's never going to become truly mainstream.
This is exactly why it's a good idea to try your own implementations. You get intimately familiar with the problem. You understand the trade-offs, corner cases, api design, etc. far better that way. And there might be a slight chance that you come up with a better solution.
I've heard that Feynman had a motta something like "If I can't build it, I can't claim to understand it."
Also, I like the idea of apprenticeships. At some point our academic culture seems to have shifted from liberal education to some kind of quasi-vocational preparation. This is probably in response to the death of apprenticeships when we started requiring a bachelor's degree for entry level professional jobs.