9 ms·

> one of the places where computer science has gone backward, preferring more clunky systems and less elegant paradigms I respectfully disagree. Smalltalk has

> one of the places where computer science has gone backward, preferring more clunky systems and less elegant paradigms I respectfully disagree. Smalltalk has had its time. OOP has had plenty of investment and exploration, but it's fundamentally non-compositional and is a poor fit for modern hardware. Other paradigms, for example statically typed functional languages, are just as expressive (the expressive parts of Smalltalk were functional features anyway) and have much more to offer in terms of building reliable software that does not crash and is secure. Programming is hard, there is no silver bullet, but computer science is moving forward.

abecedarius 5y ago
As long as we're trading opinions: the OO vogue of 1990-2010ish and the anti-OO reaction since then were both too much a matter of fashion. OO and FP are both powerful ideas, neither dominates the other, sometimes you can combine them, and you don't have to declare allegiance to either.
- willtim 5y ago
  The attraction of "functional programming" to academics and many others, is that the paradigm is underpinned by established and well studied mathematical logics. For example, the lambda calculus or more recently linear logic. You can view this as "fashion" if you like, but by making programming more formalized and less adhoc, it's probably better recognised as progress.
  - pyuser583 5y ago
    Those advantages aren’t merely theoretical … implicitly gained knowledge is extremely powerful in FP.
  - bmitc 5y ago
    I’m not sure that stronger type systems always means an improvement to writing programs. They simply move the needle on the scale of where the difficulty lies in writing programs. Untyped languages make it very easy to write programs while the stronger the type system, the harder it gets to write the program in the first place. I think balance is in order and this is one reason why we haven’t seen fancy type systems become mainstream except for niche domains. If I’m writing a program in F#, I have a balance between a type system constraining me but a language that allows me, the programmer, to do what I want to do for the most part. The stronger and fancier type systems means I now have to somehow teach the type system things that I already now how to do and are safe. Fancy type systems simply try to say that you should write down a specification of your program. But in the real world, this is an enormously difficult if not impossible task. It makes the programming process and program rigid and brittle and not robust, which is not necessarily properties of software you want. There’s a reason why certain language ecosystems like Erlang/Elixir say errors, unexpected input, and more pathological events will happen (i.e., they can’t be reasoned out of the system) and so you need a way to explicitly deal with them. This is also a big theme in the recent book Software Design for Flexibility in terms of expanding programs, getting them to handle things they couldn’t before. While fancy type systems are neat, like those in Idris, I think the most useful idea is to have mixed type systems and programming paradigms in a program, which seems to be relatively unexplored right now.
    - willtim 5y ago
      Any statically typed language allows one to use dynamic types when it is necessary. I don't see the problem. If you need a map of string keys to variants, this can be done. At least one can still put some static constraints on the types when necessary.
lalalandland 5y ago
OP said IDE, not object oriented programming. Most Smalltalk dialects have very nice programming environments that makes it much easier to be productive.
- rbanffy 5y ago
  And even Smalltalk/80 was light years ahead of pretty much any IDE that came much later. It is a whole OS with integrated development and debugging tools.
sicromoft 5y ago
Why are we downvoting someone who is respectfully disagreeing?
- deleted 5y ago
  [deleted]
mpweiher 5y ago
1. If OO is a poor fit for modern hardware, FP is much, much worse. 2. Actually OO is highly compositional. 3. The few actual studies that have been done disagree on static FP being more expressive (or safer). In fact, if you look at something like Mozart/Oz, they make the case that FP is less expressive. 4. Agree there is no silver bullet. On the other hand, the gentleman who wrote "No Silver Bullet" actually also wrote that he viewed OO as one of the closest shots we have at a silver bullet. And 10 years later wrote that this turned out to be correct.
- grumpyprole 5y ago
  1. FP is easier to optimise and is data-centric, which is much more useful for parallel processing. For example, game engines like Unity have been forced to move away from OOP and towards more data-centric architectures. 2. OO often features pervasive mutable state, which is hidden but not encapsulated. Side-effecting computations fundamentally do not compose. In the worst case, one ends up with a combinatorial explosion of the state space, good for simulations, but no so good for building systems one can easily reason about. This is what functional programming sets out to solve. OO does encourage modules, which is a good thing and can help with composition. But modules are not unique to OO. 3. Static typing is (obviously) safer than dynamic types. Smalltalk got most of its expressiveness from closures. 4. OO is clearly not a silver bullet. US academics need to invest more time in exploring functional programming (and actually teach it to their undergrads!).
  - mpweiher 5y ago
    You are making a lot of unsubstantiated claims. 1. Unity did not move to FP. FP might be "easier" to optimise, but it starts off from such a disadvantage that the relative ease usually can't make up for it. (The same is true for Swift, by the way: they also make great claims for how much it optimises, and those claims are largely true, but its base performance is so horrible that those heroic optimisations leave it slower than the language it replaces) The claimed advantages of FP for parallel processing are still vastly outweighed by the imposed overhead. I remember a talk by SPJ where he also made vast claims for the advantages of FP for parallel processing. At the end of the talk, he had to admit that the FP version needed 6 cores to become equivalent to a single core with C. He also claimed that some technique was "only possible with FP", but an audience member informed him that this very technique had been standard in HPC FORTRAN for quite some time. So these unsubstantiated claims have to be taken with a HUGE grain of salt. For high-performance, you still turn to tuned, mechanically sympathetic low-level code, not to FP. FP is about as mechanically antipathetic as possible. 2. Hand-waving. Have you heard of "object composition"? While you might believe that OO doesn't compose, for theoretical reasons, the fact is that it does, in practice. If your theory predicts something that turns out to be wrong, it is time to update the theory, rather than complain about the world. Also this "reason about" canard gets bandied abound a lot, but it is mostly just that: a canard. It refers to a very specific type of mechanical reasoning that is rarely done when actually trying to understand real code. FP code tends to be very hard for humans to understand. 3. It might be "obvious" to you, but: "It ain't the things that you don't know that kill you. It's the things you know that just ain't so". Every study purporting to show increased safety for statically typed languages compared to dynamic languages has been shown to be incorrect, sometimes comically so. What has been shown is a documentation effect. The idea that Smalltalk got most of its expressiveness from closures is laughable. What is true is that you absolutely do not need FP to reap the benefits of higher order code such as blocks. 4. Straw man. Nobody claimed that OO is a silver bullet. But once again, the very person who coined the phrase and wrote the paper "No Silver Bullets" said that he viewed OO as the closest thing to such a silver bullet. And 10 years later, he said that his belief had been shown to be correct.

abecedarius 5y ago

As long as we're trading opinions: the OO vogue of 1990-2010ish and the anti-OO reaction since then were both too much a matter of fashion. OO and FP are both powerful ideas, neither dominates the other, sometimes you can combine them, and you don't have to declare allegiance to either.

willtim 5y ago
The attraction of "functional programming" to academics and many others, is that the paradigm is underpinned by established and well studied mathematical logics. For example, the lambda calculus or more recently linear logic. You can view this as "fashion" if you like, but by making programming more formalized and less adhoc, it's probably better recognised as progress.
- pyuser583 5y ago
  Those advantages aren’t merely theoretical … implicitly gained knowledge is extremely powerful in FP.
- bmitc 5y ago
  I’m not sure that stronger type systems always means an improvement to writing programs. They simply move the needle on the scale of where the difficulty lies in writing programs. Untyped languages make it very easy to write programs while the stronger the type system, the harder it gets to write the program in the first place. I think balance is in order and this is one reason why we haven’t seen fancy type systems become mainstream except for niche domains. If I’m writing a program in F#, I have a balance between a type system constraining me but a language that allows me, the programmer, to do what I want to do for the most part. The stronger and fancier type systems means I now have to somehow teach the type system things that I already now how to do and are safe. Fancy type systems simply try to say that you should write down a specification of your program. But in the real world, this is an enormously difficult if not impossible task. It makes the programming process and program rigid and brittle and not robust, which is not necessarily properties of software you want. There’s a reason why certain language ecosystems like Erlang/Elixir say errors, unexpected input, and more pathological events will happen (i.e., they can’t be reasoned out of the system) and so you need a way to explicitly deal with them. This is also a big theme in the recent book Software Design for Flexibility in terms of expanding programs, getting them to handle things they couldn’t before. While fancy type systems are neat, like those in Idris, I think the most useful idea is to have mixed type systems and programming paradigms in a program, which seems to be relatively unexplored right now.
  - willtim 5y ago
    Any statically typed language allows one to use dynamic types when it is necessary. I don't see the problem. If you need a map of string keys to variants, this can be done. At least one can still put some static constraints on the types when necessary.

lalalandland 5y ago

OP said IDE, not object oriented programming. Most Smalltalk dialects have very nice programming environments that makes it much easier to be productive.

rbanffy 5y ago
And even Smalltalk/80 was light years ahead of pretty much any IDE that came much later. It is a whole OS with integrated development and debugging tools.

sicromoft 5y ago

Why are we downvoting someone who is respectfully disagreeing?

deleted 5y ago
[deleted]

mpweiher 5y ago

1. If OO is a poor fit for modern hardware, FP is much, much worse. 2. Actually OO is highly compositional. 3. The few actual studies that have been done disagree on static FP being more expressive (or safer). In fact, if you look at something like Mozart/Oz, they make the case that FP is less expressive. 4. Agree there is no silver bullet. On the other hand, the gentleman who wrote "No Silver Bullet" actually also wrote that he viewed OO as one of the closest shots we have at a silver bullet. And 10 years later wrote that this turned out to be correct.

grumpyprole 5y ago
1. FP is easier to optimise and is data-centric, which is much more useful for parallel processing. For example, game engines like Unity have been forced to move away from OOP and towards more data-centric architectures. 2. OO often features pervasive mutable state, which is hidden but not encapsulated. Side-effecting computations fundamentally do not compose. In the worst case, one ends up with a combinatorial explosion of the state space, good for simulations, but no so good for building systems one can easily reason about. This is what functional programming sets out to solve. OO does encourage modules, which is a good thing and can help with composition. But modules are not unique to OO. 3. Static typing is (obviously) safer than dynamic types. Smalltalk got most of its expressiveness from closures. 4. OO is clearly not a silver bullet. US academics need to invest more time in exploring functional programming (and actually teach it to their undergrads!).
- mpweiher 5y ago
  You are making a lot of unsubstantiated claims. 1. Unity did not move to FP. FP might be "easier" to optimise, but it starts off from such a disadvantage that the relative ease usually can't make up for it. (The same is true for Swift, by the way: they also make great claims for how much it optimises, and those claims are largely true, but its base performance is so horrible that those heroic optimisations leave it slower than the language it replaces) The claimed advantages of FP for parallel processing are still vastly outweighed by the imposed overhead. I remember a talk by SPJ where he also made vast claims for the advantages of FP for parallel processing. At the end of the talk, he had to admit that the FP version needed 6 cores to become equivalent to a single core with C. He also claimed that some technique was "only possible with FP", but an audience member informed him that this very technique had been standard in HPC FORTRAN for quite some time. So these unsubstantiated claims have to be taken with a HUGE grain of salt. For high-performance, you still turn to tuned, mechanically sympathetic low-level code, not to FP. FP is about as mechanically antipathetic as possible. 2. Hand-waving. Have you heard of "object composition"? While you might believe that OO doesn't compose, for theoretical reasons, the fact is that it does, in practice. If your theory predicts something that turns out to be wrong, it is time to update the theory, rather than complain about the world. Also this "reason about" canard gets bandied abound a lot, but it is mostly just that: a canard. It refers to a very specific type of mechanical reasoning that is rarely done when actually trying to understand real code. FP code tends to be very hard for humans to understand. 3. It might be "obvious" to you, but: "It ain't the things that you don't know that kill you. It's the things you know that just ain't so". Every study purporting to show increased safety for statically typed languages compared to dynamic languages has been shown to be incorrect, sometimes comically so. What has been shown is a documentation effect. The idea that Smalltalk got most of its expressiveness from closures is laughable. What is true is that you absolutely do not need FP to reap the benefits of higher order code such as blocks. 4. Straw man. Nobody claimed that OO is a silver bullet. But once again, the very person who coined the phrase and wrote the paper "No Silver Bullets" said that he viewed OO as the closest thing to such a silver bullet. And 10 years later, he said that his belief had been shown to be correct.