10 ms·

What's Worked in Computer Science

135 points by cjbprime 11y ago

vezzy-fnord 11y ago
Author is slyly redefining "what's worked" to "what's widely used".
- chubot 11y ago
  What are some examples of things that "worked" but are not "widely used"? Erlang?
  - Jtsummers 11y ago
    Functional programming, even when not in, strictly speaking, functional programming languages (MLs, Haskell, lisps, Erlang), has worked. It's moving more and more into mainstream languages. Either as a sublanguage (Linq) or by piecemeal incorporation of its concepts (pattern matching, anonymous functions, TCO so recursion can be used penalty-free, etc.).
    - dikaiosune 11y ago
      I think the same could be said of the fancy type system segment (although I'm not entirely sure why those were disjoint -- they so frequently go hand in hand).
      - Jtsummers 11y ago
        Yes. Should've included that. The type theory that came from functional languages is moving into the mainstream languages, too.
    - pron 11y ago
      > Functional programming, even when not in, strictly speaking, functional programming languages (MLs, Haskell, lisps, Erlang), has worked How do you know? By "worked" the author means "has unambiguously turned out to be a good idea with very significant benefits". That some people really like something and are able to write good, working programs with it doesn't mean it's "worked" in the sense discussed. First, each of these languages is "functional" in a very different way, so much so that even their inclusion in the same category is tenuous. Second, none of these (except maybe Erlang) has been used extensively enough in large-scale projects to give us a definitive answer regarding the actual benefits. That functional concepts are finding their way into the mainstream is very true, but some of these have also been associated with OO for a very long time now (in fact, they've been a part of OO longer than three of the four FP languages you list have existed). Smalltalk, the most OO of OO languages, had anonymous functions from the beginning, and would tell you that anonymous functions are just as much OO as functional. TCO is not very mainstream, and as Guy Steele demonstrated, is just as relevant for OO as it is for functional. Also, adoption of some concepts doesn't mean FP as a paradigm has worked (the bigger problem is that FP doesn't even have a definition; it is continuously redefined to mean whatever it is people associate with languages that call themselves FP). In short, we're not sure quite yet, hence "maybe".
      - markatkinson 11y ago
        I agree with you that from the perspective of the article Functional Programming is still a "maybe" as it doesn't have the same sort of following or use in large-scale projects as OO, but I suppose it might be the perspective of the article that is incorrect. Whatsapp has demonstrated the power of FP with Erlang, and other programming languages like Elixir are starting to gain traction as they improve on the older Frameworks and make development more "comfortable". Whether they will get enough traction and garner enough of a following to become a "Yes" from this articles perspective is difficult to say but I am confident people will see the light of FP sooner than they think, and I feel like it won't be long till FP is the new cool kid on the block, I'm just not sure who will be responsible for leading that.
        pron 11y ago
        > Whatsapp has demonstrated the power of FP with Erlang Whatsapp demonstrated the power of actors and lightweight threads with Erlang. FP had little to do with that.
        markatkinson 11y ago
        Good point... I suppose that is also what Elixir is bringing to the party.
        discreteevent 11y ago
        "Is Erlang object oriented? Joe Armstrong: Smalltalk got a lot of the things right. So if your question is about what I think about object oriented programming, I sort of changed my mind over that. I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was part of the intention actually. I started wondering about what object oriented programming was and I thought Erlang wasn't object oriented, it was a functional programming language. Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". He said object oriented languages aren't object oriented. I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism. Alan Kay himself wrote this famous thing and said "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages". He wrote that and he said that the initial reaction to object oriented programming was to overemphasize the classes and methods and under emphasize the messages and if we talk much more about messages then it would be a lot nicer. The original Smalltalk was always talking about objects and you sent messages to them and they responded by sending messages back. But you don't really do that and you don't really have isolation which is one of the problems. Dan Ingalls said yesterday (I thought it was very nice) about messaging that once you got messaging, you don't have to care where the message came from. You don't really have to care, the runtime system has to organize the delivery of the message, we don't have to care about how it's processed. It sort of decouples the sender and the receiver in this kind of mutual way. That's why I love messaging. The 3 things that object oriented programming has it's messaging, which is possibly the most important thing. The next thing is isolation and that's what I talked about earlier, that my program shouldn't crash your program, if the 2 things are isolated, then any mistakes I make in my program will not crash your program. This is certainly not true with Java. You cannot take 2 Java applications, bung them in the JVM and one of them still halts the machine and the other one will halt as well. You can crash somebody else's application, so they are not isolated. The third thing you want is polymorphism. Polymorphism is especially regarding messaging, that's just there for the programmer's convenience. It's very nice to have for all objects or all processes or whatever you call them, to have a printMe method - "Go print yourself" and then they print themselves. That's because the programmers, if they all got different names, the programmer is never going to remember this, so it's a polymorphism. It just means "OK, all objects have a printMe method. All objects have a what's your size method or introspection method." Erlang has got all these things. It's got isolation, it's got polymorphism and it's got pure messaging. From that point of view, we might say it's the only object oriented language and perhaps I was a bit premature in saying that object oriented languages are about. You can try it and see it for yourself." http://www.infoq.com/interviews/johnson-armstrong-oop http://www.infoq.com/interviews/johnson-armstrong-oop
  - tikhonj 11y ago
    From this article's list: "fancy" type systems, functional programming, RISC (!). Formal methods, albeit in specific domains. Security? (I'm not even sure how we can say whether "security works" or not.) Erlang is a good specific example. Haskell and OCaml are others. (I've seen first hand just how incredibly well OCaml works at Jane Street, even if almost nobody else uses it.) SMT solvers are another cool example. They're used by certain kinds of researchers (including "applied" research like at security companies), but most people haven't even heard of them. At the same time, they let you do some absurd things surprisingly easily that seem intractable. Everything from exhaustively verifying algorithms and invariants to automatically detecting and debugging bugs on the fly to running code backwards. And they make a whole bunch of less absurd but still useful constraint-based problems virtually trivial. Lots of people would benefit from them—if they knew about them and cared. Another great example is the Nix package manager which does package manager magic, but hasn't caught on yet. This is partly a function of its limited ecosystem and documentation, but it does work and I know people using it in production. Hell, for some definition of "widely used", Emacs and VIM fall under this banner. They're somewhat more popular than functional programming and the like, but, in the grand scheme of things, they're a narrow niche among everyday programmers.
- pron 11y ago
  I think he's defining "worked" to be "clearly demonstrated to be significantly beneficial for a wide range of applications in numerous production uses in the industry". Seems reasonable.
peter303 11y ago
Software Engineering is a loaded question. It covers the range from formal planning bureaucracies to seat-of-pants extreme programming. Any software company that makes it into its second decade has probably hacked together something that works.
silverpikezero 11y ago
The claim about RISC being a No is bizarre. RISC has definitely won, for 2 big reasons: 1. Intel redesigned their x86 processors to execute using a RISC model internally. AMD is using the same idea. A processor architecture is defined by its execution model (not it's external encoding). 2. ARM is more ubiquitous than Intel, and ARM is a RISC architecture. In fact, ARM may be the dominant processor architecture in the next 10 years. RISC is resoundingly a Yes.
- thristian 11y ago
  The author addresses this: > It’s possible to nitpick RISC being a no by saying that modern processors translate x86 ops into RISC micro-ops internally, but if you listened to talk at the time, people thought that having a external RISC ISA would be so much lower overhead that RISC would win, which has clearly not happened. Moreover, modern chips also do micro-op fusion in order to fuse operations into decidedly un-RISC-y operations.
  - wodenokoto 11y ago
    The success criteria is not mentioned at all, so there is no clear way of settling this. yes the brand "risc" failed, but does that mean the idea behind risc presented by the computer science community failed? I'm no processor expert, but it sounds like to me the paradigm behind risc is both theoretical and practically sound and is a key component in most modern CPU's.
    - qznc 11y ago
      I would disagree. Intel adds more and more special instructions for niche uses (crypto,HPC,virtualization,etc) for the sake of efficiency. This becomes increasingly necessary for performance improvements, because frequency scaling hit its boundary for now and manycore is about to (see Dark Silicon).
  - varjag 11y ago
    One point of RISC was better production yield due to higher die regularity. By this criterion RISC clearly won, and this is also one of the driving factors to CISC-as-microcoded-RISC approach.
uint32 11y ago
This article discusses "today", yet it has no publication date. Well, it mentions "2015" in the conclusion, but that's it. This trend to publish without a date is ill-conceived.
andrewflnr 11y ago
Speaking as someone currently in the "enamored with capabilities" phase, I'd like to know more about how people get disillusioned with them and whether it can be prevented. Is it something we just need to keep trying until we get out right, or are they somehow fundamentally unworkable despite their elegance? Also, does the increasing importance of power consumption affect the RISC vs CISC issue? Naïvely I would expect that to work in favor of RISC.
- douche 11y ago
  What exactly are capabilities, in this context? It's not something I've been acquainted with. Wikipedia gave me a short article that appears to be about schemes for tagged memory, which I vaguely remember hearing about for a hot minute in one of my intro survey CS classes, and then never again.
  - mediumdeviation 11y ago
    Basically, http://www.eros-os.org/essays/capintro.html http://www.eros-os.org/essays/capintro.html and https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
    - douche 11y ago
      Thanks. That section of the original article kind of assumes you know what is being referred to, and I wasn't eager to go through the 80 page pdf that was linked. Trying to google Capabilities+Computer+Science turns up a lot of noise.
- bascule 11y ago
  I would put the author in the "doesn't know what he's talking about camp" in regard to capabilities. The same could probably be said regarding the claim that distributed computing works and that maybe we're ok at security now. All of these feel like fields in their infancy. Capabilities are among the few systems that can solve authorization decisions involving three or more principals. Ambient authority systems e.g. systems based on ACLs are inherently broken when dealing with 3 or more principals (see http://waterken.sourceforge.net/aclsdont/ http://waterken.sourceforge.net/aclsdont/): "The ACL model is unable to make correct access decisions for interactions involving more than two principals, since required information is not retained across message sends. Though this deficiency has long been documented in the published literature, it is not widely understood." If you're looking for a place this arises in practice, look no further than the same-origin policy in web browsers, and the complexity of three principal interactions where one principal is a user, another is a web site, and the third is a malicious web site. That's not to say we should abandon the same-origin policy, but we need authorization primitives that seamlessly span multiple principals. Projects like Capsicum are adding capabilities to OSes like Linux and FreeBSD. Cap'n Proto is demonstrating what's possible with a modern implementation of CapTP. I think the need for authorization-centric (as opposed to identity-centric) access control systems is becoming increasingly clear. Capabilities (particularly in the CapTP sense) are one realization of this idea but there are others.
chvid 11y ago
What a strange random list of things big and small loosely related to computers. So "bitmaps" work? "Software engineering" does not. Sure things change in this industry. But you really need a bit more focus to capture what is going on and what drives it.
- brudgers 11y ago
  In 1995, "Software Engineering" would usually have implied CASE tools and heavy weight UML. It's current "success" is largely based on a bit of redefinition toward testing and team interactions and common values. They are rather different notions.
  - chvid 11y ago
    Yes. Where are as bitmaps here probably refer to pixel-level raster graphics. Where as "software engineering" is an entire field of its own. If anything we are moving away from raster graphics to vector graphics, declarative approaches and display schemes that are adaptive to the device and its resolution.
robotresearcher 11y ago
Bad title. the list of topics is a very small fraction of the activity in computer science. The original Lampson title was fine. Why change it?
jwatte 11y ago
We write web services in Haskell every day and it's much, much easier to refactor, and runs much faster than, the PHP that came before it. This is at large scale for a mature tech company, too. We've also had good success with Erlang for messaging, although its standard libraries have annoying bugs. Based on this, I'd say: Functional programming: yes. Fancy type systems: maybe. The reason for "maybe" is that we use ByteString a little too happily and don't new type enough to prevent all bugs ahead of time... Then again, C++ templates are definitely fancy type systems, and we ship lots of important code on that every day, too!
- rifung 11y ago
  If you don't mind me asking, what company is this that uses Haskell everyday?
  - codygman 11y ago
    I have a video in my watch queue that shows Facebook is: https://youtu.be/sl2zo7tzrO8 https://youtu.be/sl2zo7tzrO8
  - pokoleo 11y ago
    He's talking about IMVU.
  - qznc 11y ago
    https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
- lmm 11y ago
  Yeah, I've been doing Scala professionally for 5+ years, and not just stringy types (free monads are everywhere once you start looking for them), so this was a weird thing to read.
- felixgallo 11y ago
  which annoying bugs in erlang's stdlib are you referring to?
tikhonj 11y ago
As usual, read this as "what's popular in Computer Science" more than "what's worked". Lots of things listed in the Maybe and No category (both the original table and in the article) do work but aren't super-popular and some things listed as "Yes" like bitmaps and subtypes are bad but ubiquitous. Apart from my usual spiel on how popularity is not particularly meaningful[1], this is also an example of a fascinating idea from poker: "results oriented thinking"[2]. It's a terrible name, but a crucial concept: you can do everything right and still fail or you can do things wrong and still succeed. In Poker it means you can bet correctly and still lose to the luck of the draw and vice-versa; you can't generalize from a single example or even a handful of examples. Of course, this is exactly what so many people in industry do. Results oriented thinking is endemic in practical software engineering. We even have our own name for it, or at least part of it: the IBM effect. "Nobody ever got fired for buying IBM."[3] If you do the same old thing and fail, well, things happen. If you try something new and fail, well that thing you tried has to be terrible! Never do it again! Of course, in reality, those "things that happen" still dominate, but that's not how people make decisions. Then it's all magnified through institutional memory and "common wisdom". It's also magnified because there's a certain kind of personality that values pragmatism above all else and categorically opposes anything new, idealistic or academic. (To be fair, pretty much the opposite of me :P.) The tricky thing is that they have a point... some of the time. But they'll use any sort of failure to rationalize their view, and because decision makers tend to be so results-oriented this sort of rationalization has an outsized influence. Putting this all together both this article and Butler Lampson's original argument tell us a lot more about the social dynamics of software engineering than they do about computer science. There are still interesting insights to be had, but certainly not the ones the article is arguing for. [1]: https://news.ycombinator.com/item?id=10567962 https://news.ycombinator.com/item?id=10567962 [2]: Unfortunately, I haven't found a single good description of "results oriented thinking" as the phrase is used here. This blog post is okay, but the first part plays dubious semantic games with words that you may as well ignore: http://randomdirections.com/why-being-results-oriented-is-actually-bad/ http://randomdirections.com/why-being-results-oriented-is-ac... [3]: Hilariously, this was the first Google result for the phrase: https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
- 11y ago
lambdalambda 11y ago
> "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've heard this several times, but would love to read more about it. Anyone know where to find more information?
- topkekz 11y ago
  https://en.wikipedia.org/wiki/FX!32 https://en.wikipedia.org/wiki/FX!32 (page 7) http://web.stanford.edu/class/cs343/resources/fx32.pdf http://web.stanford.edu/class/cs343/resources/fx32.pdf note that it was 500 MHz DEC Alpha vs 200 Mhz Pentium
toolslive 11y ago
What about Objects/Subtypes ?: a 'Yes' in 1999 but these days, we've learned the hard way that there are at least 2 contexts were objects don't quite work: - relational databases (objects & classes are organized in trees, and a tree is a sin in RDB land) - concurrency & parallelism so a No? (although some people keep on trying)
cm2187 11y ago
I am not sure I would categorize a type system as a maybe. Dynamically typed languages succeeded only because they are simple and popular with beginers (python, php, javascript) and hence are popular by number of programmers, or because they are the only way to be cross platform (javascript). But I am not convinced that dynamic languages "work". It is great for simple things but completely breaks on large projects.
vseloved 11y ago
First of all, this isn't so much about CS as about Computer Engineering. Next, as pointed out already, this selection is quite random and subjective
sklogic 11y ago
RPC has won indeed, in many different ways. Classic RISC made its way into the embedded, low power devices and clearly won, at least by the sheer numbers of chips produced. Formal methods settled strongly in the hardware design [1]. Distributed computing made a very strong comeback (map-reduce, clouds, all that). So, in general, it's very outdated. It was already outdated even in 1999. [1] https://www.cl.cam.ac.uk/~jrh13/slides/nasa-14apr10/slides.pdf https://www.cl.cam.ac.uk/~jrh13/slides/nasa-14apr10/slides.p...
guard-of-terra 11y ago
I won't say RPC won. We don't use Remote Procedure Calls much, we do Remote Endpoint Calls. Every endpoint still have to be considered, specified, secured, protected against DoS. None of that is automated - for example, endpoint specification systems famously didn't work. It's not that we fire random procedures on remote machines. We use protocols in the end, not procedures.
rbanffy 11y ago
> In retrospect, the reason RISC chips looked so good in the 80s was that you could fit a complete RISC microprocessor onto a single chip, which wasn’t true of x86 chips at the time. This is simply not true. In fact, the first RISC I saw, the 88000, would not fit on one chip.
Olshansky 11y ago
Dependency injection. - No one ever

135 points by cjbprime 11y ago

vezzy-fnord 11y ago

Author is slyly redefining "what's worked" to "what's widely used".

chubot 11y ago
What are some examples of things that "worked" but are not "widely used"? Erlang?
- Jtsummers 11y ago
  Functional programming, even when not in, strictly speaking, functional programming languages (MLs, Haskell, lisps, Erlang), has worked. It's moving more and more into mainstream languages. Either as a sublanguage (Linq) or by piecemeal incorporation of its concepts (pattern matching, anonymous functions, TCO so recursion can be used penalty-free, etc.).
  - dikaiosune 11y ago
    I think the same could be said of the fancy type system segment (although I'm not entirely sure why those were disjoint -- they so frequently go hand in hand).
    - Jtsummers 11y ago
      Yes. Should've included that. The type theory that came from functional languages is moving into the mainstream languages, too.
  - pron 11y ago
    > Functional programming, even when not in, strictly speaking, functional programming languages (MLs, Haskell, lisps, Erlang), has worked How do you know? By "worked" the author means "has unambiguously turned out to be a good idea with very significant benefits". That some people really like something and are able to write good, working programs with it doesn't mean it's "worked" in the sense discussed. First, each of these languages is "functional" in a very different way, so much so that even their inclusion in the same category is tenuous. Second, none of these (except maybe Erlang) has been used extensively enough in large-scale projects to give us a definitive answer regarding the actual benefits. That functional concepts are finding their way into the mainstream is very true, but some of these have also been associated with OO for a very long time now (in fact, they've been a part of OO longer than three of the four FP languages you list have existed). Smalltalk, the most OO of OO languages, had anonymous functions from the beginning, and would tell you that anonymous functions are just as much OO as functional. TCO is not very mainstream, and as Guy Steele demonstrated, is just as relevant for OO as it is for functional. Also, adoption of some concepts doesn't mean FP as a paradigm has worked (the bigger problem is that FP doesn't even have a definition; it is continuously redefined to mean whatever it is people associate with languages that call themselves FP). In short, we're not sure quite yet, hence "maybe".
    - markatkinson 11y ago
      I agree with you that from the perspective of the article Functional Programming is still a "maybe" as it doesn't have the same sort of following or use in large-scale projects as OO, but I suppose it might be the perspective of the article that is incorrect. Whatsapp has demonstrated the power of FP with Erlang, and other programming languages like Elixir are starting to gain traction as they improve on the older Frameworks and make development more "comfortable". Whether they will get enough traction and garner enough of a following to become a "Yes" from this articles perspective is difficult to say but I am confident people will see the light of FP sooner than they think, and I feel like it won't be long till FP is the new cool kid on the block, I'm just not sure who will be responsible for leading that.
      - pron 11y ago
        > Whatsapp has demonstrated the power of FP with Erlang Whatsapp demonstrated the power of actors and lightweight threads with Erlang. FP had little to do with that.
        markatkinson 11y ago
        Good point... I suppose that is also what Elixir is bringing to the party.
      - discreteevent 11y ago
        "Is Erlang object oriented? Joe Armstrong: Smalltalk got a lot of the things right. So if your question is about what I think about object oriented programming, I sort of changed my mind over that. I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was part of the intention actually. I started wondering about what object oriented programming was and I thought Erlang wasn't object oriented, it was a functional programming language. Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". He said object oriented languages aren't object oriented. I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism. Alan Kay himself wrote this famous thing and said "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages". He wrote that and he said that the initial reaction to object oriented programming was to overemphasize the classes and methods and under emphasize the messages and if we talk much more about messages then it would be a lot nicer. The original Smalltalk was always talking about objects and you sent messages to them and they responded by sending messages back. But you don't really do that and you don't really have isolation which is one of the problems. Dan Ingalls said yesterday (I thought it was very nice) about messaging that once you got messaging, you don't have to care where the message came from. You don't really have to care, the runtime system has to organize the delivery of the message, we don't have to care about how it's processed. It sort of decouples the sender and the receiver in this kind of mutual way. That's why I love messaging. The 3 things that object oriented programming has it's messaging, which is possibly the most important thing. The next thing is isolation and that's what I talked about earlier, that my program shouldn't crash your program, if the 2 things are isolated, then any mistakes I make in my program will not crash your program. This is certainly not true with Java. You cannot take 2 Java applications, bung them in the JVM and one of them still halts the machine and the other one will halt as well. You can crash somebody else's application, so they are not isolated. The third thing you want is polymorphism. Polymorphism is especially regarding messaging, that's just there for the programmer's convenience. It's very nice to have for all objects or all processes or whatever you call them, to have a printMe method - "Go print yourself" and then they print themselves. That's because the programmers, if they all got different names, the programmer is never going to remember this, so it's a polymorphism. It just means "OK, all objects have a printMe method. All objects have a what's your size method or introspection method." Erlang has got all these things. It's got isolation, it's got polymorphism and it's got pure messaging. From that point of view, we might say it's the only object oriented language and perhaps I was a bit premature in saying that object oriented languages are about. You can try it and see it for yourself." http://www.infoq.com/interviews/johnson-armstrong-oop http://www.infoq.com/interviews/johnson-armstrong-oop
- tikhonj 11y ago
  From this article's list: "fancy" type systems, functional programming, RISC (!). Formal methods, albeit in specific domains. Security? (I'm not even sure how we can say whether "security works" or not.) Erlang is a good specific example. Haskell and OCaml are others. (I've seen first hand just how incredibly well OCaml works at Jane Street, even if almost nobody else uses it.) SMT solvers are another cool example. They're used by certain kinds of researchers (including "applied" research like at security companies), but most people haven't even heard of them. At the same time, they let you do some absurd things surprisingly easily that seem intractable. Everything from exhaustively verifying algorithms and invariants to automatically detecting and debugging bugs on the fly to running code backwards. And they make a whole bunch of less absurd but still useful constraint-based problems virtually trivial. Lots of people would benefit from them—if they knew about them and cared. Another great example is the Nix package manager which does package manager magic, but hasn't caught on yet. This is partly a function of its limited ecosystem and documentation, but it does work and I know people using it in production. Hell, for some definition of "widely used", Emacs and VIM fall under this banner. They're somewhat more popular than functional programming and the like, but, in the grand scheme of things, they're a narrow niche among everyday programmers.
pron 11y ago
I think he's defining "worked" to be "clearly demonstrated to be significantly beneficial for a wide range of applications in numerous production uses in the industry". Seems reasonable.

peter303 11y ago

Software Engineering is a loaded question. It covers the range from formal planning bureaucracies to seat-of-pants extreme programming. Any software company that makes it into its second decade has probably hacked together something that works.

silverpikezero 11y ago

The claim about RISC being a No is bizarre. RISC has definitely won, for 2 big reasons: 1. Intel redesigned their x86 processors to execute using a RISC model internally. AMD is using the same idea. A processor architecture is defined by its execution model (not it's external encoding). 2. ARM is more ubiquitous than Intel, and ARM is a RISC architecture. In fact, ARM may be the dominant processor architecture in the next 10 years. RISC is resoundingly a Yes.

thristian 11y ago
The author addresses this: > It’s possible to nitpick RISC being a no by saying that modern processors translate x86 ops into RISC micro-ops internally, but if you listened to talk at the time, people thought that having a external RISC ISA would be so much lower overhead that RISC would win, which has clearly not happened. Moreover, modern chips also do micro-op fusion in order to fuse operations into decidedly un-RISC-y operations.
- wodenokoto 11y ago
  The success criteria is not mentioned at all, so there is no clear way of settling this. yes the brand "risc" failed, but does that mean the idea behind risc presented by the computer science community failed? I'm no processor expert, but it sounds like to me the paradigm behind risc is both theoretical and practically sound and is a key component in most modern CPU's.
  - qznc 11y ago
    I would disagree. Intel adds more and more special instructions for niche uses (crypto,HPC,virtualization,etc) for the sake of efficiency. This becomes increasingly necessary for performance improvements, because frequency scaling hit its boundary for now and manycore is about to (see Dark Silicon).
- varjag 11y ago
  One point of RISC was better production yield due to higher die regularity. By this criterion RISC clearly won, and this is also one of the driving factors to CISC-as-microcoded-RISC approach.

uint32 11y ago

This article discusses "today", yet it has no publication date. Well, it mentions "2015" in the conclusion, but that's it. This trend to publish without a date is ill-conceived.

andrewflnr 11y ago

Speaking as someone currently in the "enamored with capabilities" phase, I'd like to know more about how people get disillusioned with them and whether it can be prevented. Is it something we just need to keep trying until we get out right, or are they somehow fundamentally unworkable despite their elegance? Also, does the increasing importance of power consumption affect the RISC vs CISC issue? Naïvely I would expect that to work in favor of RISC.

douche 11y ago
What exactly are capabilities, in this context? It's not something I've been acquainted with. Wikipedia gave me a short article that appears to be about schemes for tagged memory, which I vaguely remember hearing about for a hot minute in one of my intro survey CS classes, and then never again.
- mediumdeviation 11y ago
  Basically, http://www.eros-os.org/essays/capintro.html http://www.eros-os.org/essays/capintro.html and https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
  - douche 11y ago
    Thanks. That section of the original article kind of assumes you know what is being referred to, and I wasn't eager to go through the 80 page pdf that was linked. Trying to google Capabilities+Computer+Science turns up a lot of noise.
bascule 11y ago
I would put the author in the "doesn't know what he's talking about camp" in regard to capabilities. The same could probably be said regarding the claim that distributed computing works and that maybe we're ok at security now. All of these feel like fields in their infancy. Capabilities are among the few systems that can solve authorization decisions involving three or more principals. Ambient authority systems e.g. systems based on ACLs are inherently broken when dealing with 3 or more principals (see http://waterken.sourceforge.net/aclsdont/ http://waterken.sourceforge.net/aclsdont/): "The ACL model is unable to make correct access decisions for interactions involving more than two principals, since required information is not retained across message sends. Though this deficiency has long been documented in the published literature, it is not widely understood." If you're looking for a place this arises in practice, look no further than the same-origin policy in web browsers, and the complexity of three principal interactions where one principal is a user, another is a web site, and the third is a malicious web site. That's not to say we should abandon the same-origin policy, but we need authorization primitives that seamlessly span multiple principals. Projects like Capsicum are adding capabilities to OSes like Linux and FreeBSD. Cap'n Proto is demonstrating what's possible with a modern implementation of CapTP. I think the need for authorization-centric (as opposed to identity-centric) access control systems is becoming increasingly clear. Capabilities (particularly in the CapTP sense) are one realization of this idea but there are others.

chvid 11y ago

What a strange random list of things big and small loosely related to computers. So "bitmaps" work? "Software engineering" does not. Sure things change in this industry. But you really need a bit more focus to capture what is going on and what drives it.

brudgers 11y ago
In 1995, "Software Engineering" would usually have implied CASE tools and heavy weight UML. It's current "success" is largely based on a bit of redefinition toward testing and team interactions and common values. They are rather different notions.
- chvid 11y ago
  Yes. Where are as bitmaps here probably refer to pixel-level raster graphics. Where as "software engineering" is an entire field of its own. If anything we are moving away from raster graphics to vector graphics, declarative approaches and display schemes that are adaptive to the device and its resolution.

robotresearcher 11y ago

Bad title. the list of topics is a very small fraction of the activity in computer science. The original Lampson title was fine. Why change it?

jwatte 11y ago

We write web services in Haskell every day and it's much, much easier to refactor, and runs much faster than, the PHP that came before it. This is at large scale for a mature tech company, too. We've also had good success with Erlang for messaging, although its standard libraries have annoying bugs. Based on this, I'd say: Functional programming: yes. Fancy type systems: maybe. The reason for "maybe" is that we use ByteString a little too happily and don't new type enough to prevent all bugs ahead of time... Then again, C++ templates are definitely fancy type systems, and we ship lots of important code on that every day, too!

rifung 11y ago
If you don't mind me asking, what company is this that uses Haskell everyday?
- codygman 11y ago
  I have a video in my watch queue that shows Facebook is: https://youtu.be/sl2zo7tzrO8 https://youtu.be/sl2zo7tzrO8
- pokoleo 11y ago
  He's talking about IMVU.
- qznc 11y ago
  https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
lmm 11y ago
Yeah, I've been doing Scala professionally for 5+ years, and not just stringy types (free monads are everywhere once you start looking for them), so this was a weird thing to read.
felixgallo 11y ago
which annoying bugs in erlang's stdlib are you referring to?

tikhonj 11y ago

As usual, read this as "what's popular in Computer Science" more than "what's worked". Lots of things listed in the Maybe and No category (both the original table and in the article) do work but aren't super-popular and some things listed as "Yes" like bitmaps and subtypes are bad but ubiquitous. Apart from my usual spiel on how popularity is not particularly meaningful[1], this is also an example of a fascinating idea from poker: "results oriented thinking"[2]. It's a terrible name, but a crucial concept: you can do everything right and still fail or you can do things wrong and still succeed. In Poker it means you can bet correctly and still lose to the luck of the draw and vice-versa; you can't generalize from a single example or even a handful of examples. Of course, this is exactly what so many people in industry do. Results oriented thinking is endemic in practical software engineering. We even have our own name for it, or at least part of it: the IBM effect. "Nobody ever got fired for buying IBM."[3] If you do the same old thing and fail, well, things happen. If you try something new and fail, well that thing you tried has to be terrible! Never do it again! Of course, in reality, those "things that happen" still dominate, but that's not how people make decisions. Then it's all magnified through institutional memory and "common wisdom". It's also magnified because there's a certain kind of personality that values pragmatism above all else and categorically opposes anything new, idealistic or academic. (To be fair, pretty much the opposite of me :P.) The tricky thing is that they have a point... some of the time. But they'll use any sort of failure to rationalize their view, and because decision makers tend to be so results-oriented this sort of rationalization has an outsized influence. Putting this all together both this article and Butler Lampson's original argument tell us a lot more about the social dynamics of software engineering than they do about computer science. There are still interesting insights to be had, but certainly not the ones the article is arguing for. [1]: https://news.ycombinator.com/item?id=10567962 https://news.ycombinator.com/item?id=10567962 [2]: Unfortunately, I haven't found a single good description of "results oriented thinking" as the phrase is used here. This blog post is okay, but the first part plays dubious semantic games with words that you may as well ignore: http://randomdirections.com/why-being-results-oriented-is-actually-bad/ http://randomdirections.com/why-being-results-oriented-is-ac... [3]: Hilariously, this was the first Google result for the phrase: https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

11y ago

lambdalambda 11y ago

> "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've heard this several times, but would love to read more about it. Anyone know where to find more information?

topkekz 11y ago
https://en.wikipedia.org/wiki/FX!32 https://en.wikipedia.org/wiki/FX!32 (page 7) http://web.stanford.edu/class/cs343/resources/fx32.pdf http://web.stanford.edu/class/cs343/resources/fx32.pdf note that it was 500 MHz DEC Alpha vs 200 Mhz Pentium

toolslive 11y ago

What about Objects/Subtypes ?: a 'Yes' in 1999 but these days, we've learned the hard way that there are at least 2 contexts were objects don't quite work: - relational databases (objects & classes are organized in trees, and a tree is a sin in RDB land) - concurrency & parallelism so a No? (although some people keep on trying)

cm2187 11y ago

I am not sure I would categorize a type system as a maybe. Dynamically typed languages succeeded only because they are simple and popular with beginers (python, php, javascript) and hence are popular by number of programmers, or because they are the only way to be cross platform (javascript). But I am not convinced that dynamic languages "work". It is great for simple things but completely breaks on large projects.

vseloved 11y ago

First of all, this isn't so much about CS as about Computer Engineering. Next, as pointed out already, this selection is quite random and subjective

sklogic 11y ago

RPC has won indeed, in many different ways. Classic RISC made its way into the embedded, low power devices and clearly won, at least by the sheer numbers of chips produced. Formal methods settled strongly in the hardware design [1]. Distributed computing made a very strong comeback (map-reduce, clouds, all that). So, in general, it's very outdated. It was already outdated even in 1999. [1] https://www.cl.cam.ac.uk/~jrh13/slides/nasa-14apr10/slides.pdf https://www.cl.cam.ac.uk/~jrh13/slides/nasa-14apr10/slides.p...

guard-of-terra 11y ago

I won't say RPC won. We don't use Remote Procedure Calls much, we do Remote Endpoint Calls. Every endpoint still have to be considered, specified, secured, protected against DoS. None of that is automated - for example, endpoint specification systems famously didn't work. It's not that we fire random procedures on remote machines. We use protocols in the end, not procedures.

rbanffy 11y ago

> In retrospect, the reason RISC chips looked so good in the 80s was that you could fit a complete RISC microprocessor onto a single chip, which wasn’t true of x86 chips at the time. This is simply not true. In fact, the first RISC I saw, the 88000, would not fit on one chip.

Olshansky 11y ago

Dependency injection. - No one ever