7 ms·

What's worked in Computer Science (2015)

118 points by wheresvic1 9y ago

zellyn 9y ago
I'd love to see an updated version of this. After reading the stories from the Rust/Servo/Stylo developers, it feels like Rust might just be pushing both "fancy type systems" and "parallelism" to the left. Also, if you count GPU programming under "parallelism" then it's gotta be a huge YES.
- bryanlarsen 9y ago
  He mentions Rust in the garbage collection category, so it's interesting that it's not mentioned in the fancy type category. Maybe he considers higher kinded types a requirement to be fancy, which is still just an RFC in Rust.
- fhood 9y ago
  I agree on parallelism. I came to the conclusion that the author must not be including GPU programming in his assessment which does seem odd given how important it has been in recent years.
- hyperpape 9y ago
  He agrees that both of these points are reasonable in 2017 https://twitter.com/danluu/status/935878538623901696 https://twitter.com/danluu/status/935878538623901696 (though I guess you know that, since you're the one who asked him...)
  - zellyn 9y ago
    :-) Yes, I thought of twitter after posting here.
- jimbokun 9y ago
  I think Swift has a lot of developers adopting fancy (or fancier) type systems and functional programming concepts, even if they don't realized that's what they are doing. If you leave off immutability, Javascript, C++, and even Java 8 have introduced first class functions as mainstream programming concepts.
pyrale 9y ago
It appears that the author uses adoption as his main metric of what works. It's also quite hilarious that the author lists fancy type systems as a definite No, but formal methods as a maybe.
raiflip 9y ago
I'm confused as to why he doesn't put functional programming as a yes. He writes "Functional languages are still quite niche, but functional programming ideas are now mainstream, at least for the HN/reddit/twitter crowd." While purely Functional languages are definitely not mainstream, as he puts functional programming ideas are pretty mainstream. At the same time major OO languages like java have incorporated functional programming ideas, so arguably even Java is not purely Object Oriented anymore. It seems to me by his criteria that would also put OO as a no too. If he comes from OO languages I think this is a bias because it is easy to take OO for granted and put strict requirements on foreign Functional Programming before accepting it as successful. However it seems to me the only criteria that should be needed to call either paradigm successful is if their ideas are are mainstream, which is true for both languages. Basically if Function Programming ideas have gained currency then it should be regarded as successful.
- bryanlarsen 9y ago
  You can't get much more mainstream than Javascript, and it's fairly functional.
  - zaarn 9y ago
    JS is multi-paradigm, it's functional but it's also 3 other things that muddy the water a bit. Especially considering most programming languages have those neat helper methods or stdlib implementations that basically bring functional programming without changing the language much.
    - jackhack 9y ago
      JS may be capable of a pure functional programming style, but from 20 years of observing it's use (and misuse), functional JS is an exceptionally rare occurrence; an edge case.
  - maze-le 9y ago
    Javascript may have some functional concepts (mainly, functions as first order objects) but the programming style of most common javascript projects is not functional. This is with the notable exception of event-driven frameworks and precompiled languages like purescript.
geophile 9y ago
Functional programming and GC are slowly moving up. Looking forward to the (pure) Lisp resurgence of the 2020s.
- Sammi 9y ago
  Lisp languages aren't really growing. The most hyped lisp style language is Clojure and even it isn't growing. Here's a Google trends comparison of Clojure, Clojurescript, List, Racket, and Scheme: https://trends.google.com/trends/explore?date=2007-01-01%202017-11-29&q=clojure,clojurescript,%2Fm%2F04kyw,%2Fm%2F0974fb,%2Fm%2F06zrb https://trends.google.com/trends/explore?date=2007-01-01%202... Things aren't looking so hot for ML style languages like F#, Ocaml, and Haskell either: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F03j_q,f%23,%2Fm%2F09wmx https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... The only functional programming language that is showing any real growth is Scala, but that is also modest compared to the ones that are already much bigger or growing much faster: https://stackoverflow.blog/2017/09/06/incredible-growth-python/ https://stackoverflow.blog/2017/09/06/incredible-growth-pyth... Where functional programming is growing is in existing large OO languages. All of them now have lambdas. Most have mature immutable and composable data structure libraries. And other functional style syntaxes like pattern matching are being introduced in many of them.
  - yogthos 9y ago
    These trends aren't really all that meaningful in practice.
  - mrkgnao 9y ago
    Why was there such a spike in Haskell searches in August 2015? https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F03j_q,f%23,%2Fm%2F09wmx https://trends.google.com/trends/explore?date=today%205-y&q=...
  - charlysl 9y ago
    "other functional style syntaxes like pattern matching are being introduced in many of them" The Interpreter and its dual the Visitor GOF pattern have made what amounts to pattern matching possible in OO languages for a few decades now [1]. The whole point of these patterns is to write recursive functions following recursive data types, which is one of the main use cases for pattern matching (ok, more generally these are used to break data structures apart). In particular, if you look at an example of the Visitor pattern, you will see that it has exactly the same structure as a recursive function that separates cases in a FP language [2] Here is a detailed explanation of how to do it [3]; it is the "little language" technique (which I suspect is the reason why it is called the Interpreter). [1] https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions/ https://eli.thegreenplace.net/2016/the-expression-problem-an... [2] http://blog.higher-order.com/blog/2009/08/21/structural-pattern-matching-in-java/ http://blog.higher-order.com/blog/2009/08/21/structural-patt... [3] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec15.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu...
theandrewbailey 9y ago
I don't understand what is meant by "capabilities". My understanding of what capabilities are is so abstract, that asking if they worked is not something that could possibly be asked. I might have missed something, or this guy is an architecture astronaut (both?).
- naasking 9y ago
  He's talking about capability security. Look up the Joe-E programming language for a capability secure subset of Java if you want an idea of what sort of properties such a language must have.
- pjc50 9y ago
  https://linux.die.net/man/7/capabilities https://linux.die.net/man/7/capabilities In some ways the Android/iOS permissions system is a form of "capabilities". Granularity is a problem: too granular and they're tedious, not granular enough and you end up leaking your contacts to your torch app.
  - chubot 9y ago
    Linux capabilities aren't capabilities in the sense of capability-based security! They don't follow that security model. It's just an unfortunate pun. Capability-based security wasn't mainstream at the time they were invented. It arguably isn't now either. You can argue that Android/iOS are capability-based, but the model is pretty watered down. Capability-based security for end users (rather than sys admins) is an unsolved problem as far as I can tell. See this page: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security A capability (known in some systems as a key) is a communicable, unforgeable token of authority. Linux capabilities don't meet this definition. They're just permissions. The sibling comment is also correct: https://news.ycombinator.com/item?id=15807241 https://news.ycombinator.com/item?id=15807241
- DonbunEf7 9y ago
  Hi, here are some modern resources. First, what's the problem? http://www.cap-lore.com/CapTheory/ConfusedDeputy.html http://www.cap-lore.com/CapTheory/ConfusedDeputy.html What are capabilities? http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ Is there someplace with a massive pile of links? https://github.com/dckc/awesome-ocap https://github.com/dckc/awesome-ocap Yes, capabilities are abstract and simple. Don't worry if you don't get it at first.
kyberias 9y ago
What are the new Nos in 2017?
lph 9y ago
RISC: "If this was a Maybe in 1999 it’s certainly a No now." My cell phone begs to differ.
- mastax 9y ago
  The Acorn Risc Machine is pretty CISCy nowadays.
  - tmccrmck 9y ago
    I tend to agree. Group loads and stores isn't very RISCy to me. But then again, you could make the case that any x86 machine is RISC under the covers.
zackmorris 9y ago
I learned to program sometime around 1988 or 89 when I was 12 and have been doing it for 28 years. I saw several of these rise and fall, and conventions have changed greatly even though most of us are still using C-style languages. The highest leverage I've found comes from spreadsheets and relational databases because they require little or no code to accomplish so much. So I think that declarative or 4th generation programming languages deserve an honorable mention in the "yes" category. The lowest leverage has been on the object-oriented side, especially with C++. Java is the least abstract language I've used in recent memory, due to its obsession with staying as far from functional programming as it can (closures were accomplished with anonymous objects until version 8!). There is simply no way to infer where a value was set without tracing the entire code, which slows development time by a factor of 10 to 100 over more functional techniques that use methods to derive state instead of values. So I think the "No" category needs a mention of highly imperative code and its tendency to become spaghetti. The single most damaging practice I encounter daily is the breaking of convention and the loss of programming context that we've built up in our minds over the years. So while most functional programming languages are conceptually brilliant, they stray so far from mainstream languages like Javascript that I think they complicate syntax unnecessarily. Heavy-handed patterns also urge us to segregate code into parts when the logic doesn't require it, which I often find unintuitive. Mobile development especially, with its obsession with delegation, event broadcasting, observers and nondeterministic behavior of partially uninitialized views (especially recycler view and UITableView) feels like always having to remember 10 or 20 digits when we can only comfortably manage 7. Types for the sake of types will likely expand code size and complexity by an order of magnitude when a simple compiler would have accomplished nearly as much. I have low confidence that any of these will survive the next tech bubble. I view parallelism and AI as a great uncharted sector of computer science that was stifled by Microsoft, Apple, Intel and NVIDIA. Had FPGAs or open source graphics cards taken off after the 90s, we would have a very different view of things like the Actor model (Erlang, Go, etc). So shared threads are a huge "no", but the private address spaces/streams/message passing and copy-on-write model of UNIX is a huge "yes" and we'll likely see these techniques adopted at the language level in the next decade. It would also be nice to have the numerical computing techniques from MATLAB so we can operate on matrices instead of primitives and saturate the hardware with less effort. Under these tools and conventions, AI loses much of its mystery because you realize you can always brute force a solution and evolve more elegant ones later to find a better local optimum.
bogomipz 9y ago
The author states: >" DEC started a project to do dynamic translation from x86 to Alpha; at the time the project started, the projected performance of x86 basically running in emulation on Alpha was substantially better than native x86 on Intel chips." I'm really curious how an Alpha emulating x86 could be faster than the native x86? Can someone shed some light on how this would be possible
- draven 9y ago
  And a bit further in the article: "By the time DEC finished their dynamic translation efforts, x86 in translation was barely faster than native x86 in floating point code, and substantially slower in integer code." So perhaps they were overly optimistic.

118 points by wheresvic1 9y ago

I'd love to see an updated version of this. After reading the stories from the Rust/Servo/Stylo developers, it feels like Rust might just be pushing both "fancy type systems" and "parallelism" to the left. Also, if you count GPU programming under "parallelism" then it's gotta be a huge YES.

bryanlarsen 9y ago
He mentions Rust in the garbage collection category, so it's interesting that it's not mentioned in the fancy type category. Maybe he considers higher kinded types a requirement to be fancy, which is still just an RFC in Rust.
fhood 9y ago
I agree on parallelism. I came to the conclusion that the author must not be including GPU programming in his assessment which does seem odd given how important it has been in recent years.
hyperpape 9y ago
He agrees that both of these points are reasonable in 2017 https://twitter.com/danluu/status/935878538623901696 https://twitter.com/danluu/status/935878538623901696 (though I guess you know that, since you're the one who asked him...)
- zellyn 9y ago
  :-) Yes, I thought of twitter after posting here.
jimbokun 9y ago
I think Swift has a lot of developers adopting fancy (or fancier) type systems and functional programming concepts, even if they don't realized that's what they are doing. If you leave off immutability, Javascript, C++, and even Java 8 have introduced first class functions as mainstream programming concepts.

pyrale 9y ago

It appears that the author uses adoption as his main metric of what works. It's also quite hilarious that the author lists fancy type systems as a definite No, but formal methods as a maybe.

raiflip 9y ago

I'm confused as to why he doesn't put functional programming as a yes. He writes "Functional languages are still quite niche, but functional programming ideas are now mainstream, at least for the HN/reddit/twitter crowd." While purely Functional languages are definitely not mainstream, as he puts functional programming ideas are pretty mainstream. At the same time major OO languages like java have incorporated functional programming ideas, so arguably even Java is not purely Object Oriented anymore. It seems to me by his criteria that would also put OO as a no too. If he comes from OO languages I think this is a bias because it is easy to take OO for granted and put strict requirements on foreign Functional Programming before accepting it as successful. However it seems to me the only criteria that should be needed to call either paradigm successful is if their ideas are are mainstream, which is true for both languages. Basically if Function Programming ideas have gained currency then it should be regarded as successful.

bryanlarsen 9y ago
You can't get much more mainstream than Javascript, and it's fairly functional.
- zaarn 9y ago
  JS is multi-paradigm, it's functional but it's also 3 other things that muddy the water a bit. Especially considering most programming languages have those neat helper methods or stdlib implementations that basically bring functional programming without changing the language much.
  - jackhack 9y ago
    JS may be capable of a pure functional programming style, but from 20 years of observing it's use (and misuse), functional JS is an exceptionally rare occurrence; an edge case.
- maze-le 9y ago
  Javascript may have some functional concepts (mainly, functions as first order objects) but the programming style of most common javascript projects is not functional. This is with the notable exception of event-driven frameworks and precompiled languages like purescript.

geophile 9y ago

Functional programming and GC are slowly moving up. Looking forward to the (pure) Lisp resurgence of the 2020s.

Sammi 9y ago
Lisp languages aren't really growing. The most hyped lisp style language is Clojure and even it isn't growing. Here's a Google trends comparison of Clojure, Clojurescript, List, Racket, and Scheme: https://trends.google.com/trends/explore?date=2007-01-01%202017-11-29&q=clojure,clojurescript,%2Fm%2F04kyw,%2Fm%2F0974fb,%2Fm%2F06zrb https://trends.google.com/trends/explore?date=2007-01-01%202... Things aren't looking so hot for ML style languages like F#, Ocaml, and Haskell either: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F03j_q,f%23,%2Fm%2F09wmx https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... The only functional programming language that is showing any real growth is Scala, but that is also modest compared to the ones that are already much bigger or growing much faster: https://stackoverflow.blog/2017/09/06/incredible-growth-python/ https://stackoverflow.blog/2017/09/06/incredible-growth-pyth... Where functional programming is growing is in existing large OO languages. All of them now have lambdas. Most have mature immutable and composable data structure libraries. And other functional style syntaxes like pattern matching are being introduced in many of them.
- yogthos 9y ago
  These trends aren't really all that meaningful in practice.
- mrkgnao 9y ago
  Why was there such a spike in Haskell searches in August 2015? https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F03j_q,f%23,%2Fm%2F09wmx https://trends.google.com/trends/explore?date=today%205-y&q=...
- charlysl 9y ago
  "other functional style syntaxes like pattern matching are being introduced in many of them" The Interpreter and its dual the Visitor GOF pattern have made what amounts to pattern matching possible in OO languages for a few decades now [1]. The whole point of these patterns is to write recursive functions following recursive data types, which is one of the main use cases for pattern matching (ok, more generally these are used to break data structures apart). In particular, if you look at an example of the Visitor pattern, you will see that it has exactly the same structure as a recursive function that separates cases in a FP language [2] Here is a detailed explanation of how to do it [3]; it is the "little language" technique (which I suspect is the reason why it is called the Interpreter). [1] https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions/ https://eli.thegreenplace.net/2016/the-expression-problem-an... [2] http://blog.higher-order.com/blog/2009/08/21/structural-pattern-matching-in-java/ http://blog.higher-order.com/blog/2009/08/21/structural-patt... [3] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec15.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu...

theandrewbailey 9y ago

I don't understand what is meant by "capabilities". My understanding of what capabilities are is so abstract, that asking if they worked is not something that could possibly be asked. I might have missed something, or this guy is an architecture astronaut (both?).

naasking 9y ago
He's talking about capability security. Look up the Joe-E programming language for a capability secure subset of Java if you want an idea of what sort of properties such a language must have.
pjc50 9y ago
https://linux.die.net/man/7/capabilities https://linux.die.net/man/7/capabilities In some ways the Android/iOS permissions system is a form of "capabilities". Granularity is a problem: too granular and they're tedious, not granular enough and you end up leaking your contacts to your torch app.
- chubot 9y ago
  Linux capabilities aren't capabilities in the sense of capability-based security! They don't follow that security model. It's just an unfortunate pun. Capability-based security wasn't mainstream at the time they were invented. It arguably isn't now either. You can argue that Android/iOS are capability-based, but the model is pretty watered down. Capability-based security for end users (rather than sys admins) is an unsolved problem as far as I can tell. See this page: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security A capability (known in some systems as a key) is a communicable, unforgeable token of authority. Linux capabilities don't meet this definition. They're just permissions. The sibling comment is also correct: https://news.ycombinator.com/item?id=15807241 https://news.ycombinator.com/item?id=15807241
DonbunEf7 9y ago
Hi, here are some modern resources. First, what's the problem? http://www.cap-lore.com/CapTheory/ConfusedDeputy.html http://www.cap-lore.com/CapTheory/ConfusedDeputy.html What are capabilities? http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ Is there someplace with a massive pile of links? https://github.com/dckc/awesome-ocap https://github.com/dckc/awesome-ocap Yes, capabilities are abstract and simple. Don't worry if you don't get it at first.

kyberias 9y ago

What are the new Nos in 2017?

lph 9y ago

RISC: "If this was a Maybe in 1999 it’s certainly a No now." My cell phone begs to differ.

mastax 9y ago
The Acorn Risc Machine is pretty CISCy nowadays.
- tmccrmck 9y ago
  I tend to agree. Group loads and stores isn't very RISCy to me. But then again, you could make the case that any x86 machine is RISC under the covers.

zackmorris 9y ago

I learned to program sometime around 1988 or 89 when I was 12 and have been doing it for 28 years. I saw several of these rise and fall, and conventions have changed greatly even though most of us are still using C-style languages. The highest leverage I've found comes from spreadsheets and relational databases because they require little or no code to accomplish so much. So I think that declarative or 4th generation programming languages deserve an honorable mention in the "yes" category. The lowest leverage has been on the object-oriented side, especially with C++. Java is the least abstract language I've used in recent memory, due to its obsession with staying as far from functional programming as it can (closures were accomplished with anonymous objects until version 8!). There is simply no way to infer where a value was set without tracing the entire code, which slows development time by a factor of 10 to 100 over more functional techniques that use methods to derive state instead of values. So I think the "No" category needs a mention of highly imperative code and its tendency to become spaghetti. The single most damaging practice I encounter daily is the breaking of convention and the loss of programming context that we've built up in our minds over the years. So while most functional programming languages are conceptually brilliant, they stray so far from mainstream languages like Javascript that I think they complicate syntax unnecessarily. Heavy-handed patterns also urge us to segregate code into parts when the logic doesn't require it, which I often find unintuitive. Mobile development especially, with its obsession with delegation, event broadcasting, observers and nondeterministic behavior of partially uninitialized views (especially recycler view and UITableView) feels like always having to remember 10 or 20 digits when we can only comfortably manage 7. Types for the sake of types will likely expand code size and complexity by an order of magnitude when a simple compiler would have accomplished nearly as much. I have low confidence that any of these will survive the next tech bubble. I view parallelism and AI as a great uncharted sector of computer science that was stifled by Microsoft, Apple, Intel and NVIDIA. Had FPGAs or open source graphics cards taken off after the 90s, we would have a very different view of things like the Actor model (Erlang, Go, etc). So shared threads are a huge "no", but the private address spaces/streams/message passing and copy-on-write model of UNIX is a huge "yes" and we'll likely see these techniques adopted at the language level in the next decade. It would also be nice to have the numerical computing techniques from MATLAB so we can operate on matrices instead of primitives and saturate the hardware with less effort. Under these tools and conventions, AI loses much of its mystery because you realize you can always brute force a solution and evolve more elegant ones later to find a better local optimum.

bogomipz 9y ago

The author states: >" DEC started a project to do dynamic translation from x86 to Alpha; at the time the project started, the projected performance of x86 basically running in emulation on Alpha was substantially better than native x86 on Intel chips." I'm really curious how an Alpha emulating x86 could be faster than the native x86? Can someone shed some light on how this would be possible

draven 9y ago
And a bit further in the article: "By the time DEC finished their dynamic translation efforts, x86 in translation was barely faster than native x86 in floating point code, and substantially slower in integer code." So perhaps they were overly optimistic.