4 ms·

"OOP ... contains a simple metaphor and simple device for turning totally bad code into slightly less bad code, for allowing completely unrelated stuff to relat

"OOP ... contains a simple metaphor and simple device for turning totally bad code into slightly less bad code, for allowing completely unrelated stuff to relate together in a half-assed way." haha, nice. i don't think it's quite that cynical, hybrid OOP/FP languages like Scala seem to have a better industry record than pure functional languages, at least for the internet companies we hear all about. OO isn't inherently bad, and FP isn't inherently good, but knowing how to think in FP will certainly make us better engineers, and the "functional in the small, object-oriented in the large" seems to be gaining acceptance in elite circles.

thesz 15y ago
Just for record. Type system for OOP was developed during some 25 years: http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%20Simula%20User%20%28ECOOP%20Prize%29.pdf http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... Lambda calculus was introduced in 1936 and in 1948 it was given simple type system (along Fortran one, which, in turn, was introduced in 1958, ten years later). Year after Simula-67 was introduced, logician Hindley presented a polymorphic type system with type inference for lambda-calculus, which was later rediscovered by Milner and incorporated into ML in 1978. Simula-67 didn't have proper parametric polymorphism. I know no such examples before ML. Functional programming is based on logic and could be a basis for logic on its own. Consider Type Theory by Per Martin-Loef. Or even simpler extension of polymorphic type system fo lambda calculus: Haskell's type classes, where type represents theorem, and function text serves as a proof. OOP, on other hand, does not represent some simple kind of logic. I emphasize simple, because Luca Cardelli finally found some logic out there. So I think that OOP is inherently less useful that FP.
- dustingetz 15y ago
  thank you for posting this, fascinating perspective
  - thesz 15y ago
    I really think that history of computing is full of fantastic discoveries, atlants and their country, historical twists, etc. When I finally come to create my own map of some small island of history of computing, namely "type systems", I was thrilled, no less. The superheroes are among us, I think. ;)
- joe_the_user 15y ago
  All sorts of interesting stuff and then... ... OOP is inherently less useful that FP ... Is it that hard to see different uses for different languages? Original BASIC was neither OO nor FP and came after both. Still it satisfied a particular need. C++ is the worse programming language in the world, except for all the others - in the domain it is used in.
  - thesz 15y ago
    >Is it that hard to see different uses for different languages? Okey. How about language that could encompass all of them? The thing about such language is that it have to be functional one, at the core. Be it Lisp, or Haskell, or Agda2. Let's look at Haskell. It has OO: http://homepages.cwi.nl/~ralf/OOHaskell/ http://homepages.cwi.nl/~ralf/OOHaskell/ Everything in mainstream OOP languages and then some, all in Haskell type system. It has BASIC: http://hackage.haskell.org/package/BASIC http://hackage.haskell.org/package/BASIC I embedded to Haskell a MIPS assembler, a language to describe CPU cores, and some other things. I am not an expert in Lisp, but an avid reader of HN should know that it pretty good in encompassing languages. As for C++, it's domain shrinks every year.
    - joe_the_user 15y ago
      Uh certainly, FP language are certainly the most powerful and flexible languages, aside from maybe logic languages, far beyond OO. FP language definitely encompass more, you are correct there. I just think it's important to not to confuse power and flexible with usefulness. Rigidity and limits have their uses. As far as c++ goes, it's market share shrinks every year yet since the market grows and c++'s share began huge, c++ gains more users and more market position every years than the total users of functional programming languages. That may change in the future. FP will have to show its usefulness and not only its power and flexibility for this to happen.
    - cageface 15y ago
      As for C++, it's domain shrinks every year. Mobile seems to be generating a resurgence of interest in C++. Squeezing every last bit of performance out of tightly constrained CPU and RAM matters again.
- barrkel 15y ago
  Unfortunately, I don't think type theory has a whole lot to do with programming or software engineering. The most practical languages (as measured by popularity, which seems to be the best way to do it over a period of decades) do not have sound type systems, nor even particularly interesting ones theoretically.
  - thesz 15y ago
    You should reconsider your stance. Types allow requirements changes to be propagated through all program. State-of-the-art type systems even allow accounting of effects, like prevent deadlocks by ensuring a specific order of locking: http://www.cs.st-andrews.ac.uk/~eb/writings/fi-cbc.pdf http://www.cs.st-andrews.ac.uk/~eb/writings/fi-cbc.pdf This is just another tool in a toolbox. You can use it. Or you can throw it away as "no one seem to use it".
    - barrkel 15y ago
      I never said "no one seems to use it". What I specifically said was that I don't think type theory has a lot to do with programming: i.e., that the majority of work put into type theory in academic contexts does not, on balance, do much to improve the state of programmers writing software, or the quality of our software engineering. "Types allow requirements changes to be propagated through all program" - what does this even mean, and why is it a justification for powerful types? I designed a system once that let you describe the program at a high level, using a DSL. I've outlined it several times on this site here (here's one link: http://news.ycombinator.com/item?id=2192322 http://news.ycombinator.com/item?id=2192322). Now that system allowed requirements changes to be propagated throughout the whole program, because the level of description of the program was dense enough that it could just about be considered detailed requirements (i.e. it was powerful - see below). It worked because it was focused on a reasonably precise niche. It did enough checks during the compilation process that you could be fairly sure that if it didn't find any errors, it would work without bugs (i.e. it was good - again, below). But the level of type system it had was no more advanced than Pascal - and I mean early Pascal, no objects etc. If you can get the same effects without a very abstract and powerful type system, isn't that better, because it reduces the overall expressiveness of the language - i.e. reducing the solution space that needs to be searched? Form can be liberating. Preventing deadlocks by ensuring a specific order of locking. Fantastic; good work. How many people are using it? Which large shipping systems are using it? What was the prior rate of deadlocks for similar systems at that level of complexity, how long did those deadlocks take to be fixed, and how much time and money was saved by using this new technique? Because frankly, deadlocks are trivial to debug; the relevant threads are stopped, and after you attach a debugger the stack traces tell you exactly which locks were taken and in which order. Debugging races is a wee bit harder. I have TAPL by Pierce right here on my bookshelf. Here's a typical sentence which illustrates my problem: "Perhaps the best illustration of the power of recursive types is the fact that we can embed the whole untyped lambda-calculus - in a well-typed way - into a statically typed language with recursive types." (pp 273). It seems to me to take for granted that a statically typed language is good[1], and that a good measure of power for a statically typed language is how expressive it is (i.e. what shapes of programs it can express, not e.g. how syntactically light it can be in doing so). And this is probably right and good, for type systems. But I have a different perspective of "good" and "power" in a programming language (as distinct from a type system). A good language is one whose target audience finds it easy to express their intent in such a way that the computer can understand. A powerful language is one in which complicated effects can be expressed with succinctness. And this is the core of it: type theorists spend entirely too much time on theoretical benefits, and far too little time on whether these benefits are worthwhile. Perhaps that's not their job, you say: and I agree to you to the extent that you also agree, then, that much of their work is irrelevant because of that. [1] I happen to like statically typed programming languages, but I understand why some people don't. I wrote an extended reply on this topic to Paul Biggar some time ago, again on this site: http://news.ycombinator.com/item?id=1110653 http://news.ycombinator.com/item?id=1110653

thesz 15y ago

Just for record. Type system for OOP was developed during some 25 years: http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%20Simula%20User%20%28ECOOP%20Prize%29.pdf http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... Lambda calculus was introduced in 1936 and in 1948 it was given simple type system (along Fortran one, which, in turn, was introduced in 1958, ten years later). Year after Simula-67 was introduced, logician Hindley presented a polymorphic type system with type inference for lambda-calculus, which was later rediscovered by Milner and incorporated into ML in 1978. Simula-67 didn't have proper parametric polymorphism. I know no such examples before ML. Functional programming is based on logic and could be a basis for logic on its own. Consider Type Theory by Per Martin-Loef. Or even simpler extension of polymorphic type system fo lambda calculus: Haskell's type classes, where type represents theorem, and function text serves as a proof. OOP, on other hand, does not represent some simple kind of logic. I emphasize simple, because Luca Cardelli finally found some logic out there. So I think that OOP is inherently less useful that FP.

dustingetz 15y ago
thank you for posting this, fascinating perspective
- thesz 15y ago
  I really think that history of computing is full of fantastic discoveries, atlants and their country, historical twists, etc. When I finally come to create my own map of some small island of history of computing, namely "type systems", I was thrilled, no less. The superheroes are among us, I think. ;)
joe_the_user 15y ago
All sorts of interesting stuff and then... ... OOP is inherently less useful that FP ... Is it that hard to see different uses for different languages? Original BASIC was neither OO nor FP and came after both. Still it satisfied a particular need. C++ is the worse programming language in the world, except for all the others - in the domain it is used in.
- thesz 15y ago
  >Is it that hard to see different uses for different languages? Okey. How about language that could encompass all of them? The thing about such language is that it have to be functional one, at the core. Be it Lisp, or Haskell, or Agda2. Let's look at Haskell. It has OO: http://homepages.cwi.nl/~ralf/OOHaskell/ http://homepages.cwi.nl/~ralf/OOHaskell/ Everything in mainstream OOP languages and then some, all in Haskell type system. It has BASIC: http://hackage.haskell.org/package/BASIC http://hackage.haskell.org/package/BASIC I embedded to Haskell a MIPS assembler, a language to describe CPU cores, and some other things. I am not an expert in Lisp, but an avid reader of HN should know that it pretty good in encompassing languages. As for C++, it's domain shrinks every year.
  - joe_the_user 15y ago
    Uh certainly, FP language are certainly the most powerful and flexible languages, aside from maybe logic languages, far beyond OO. FP language definitely encompass more, you are correct there. I just think it's important to not to confuse power and flexible with usefulness. Rigidity and limits have their uses. As far as c++ goes, it's market share shrinks every year yet since the market grows and c++'s share began huge, c++ gains more users and more market position every years than the total users of functional programming languages. That may change in the future. FP will have to show its usefulness and not only its power and flexibility for this to happen.
  - cageface 15y ago
    As for C++, it's domain shrinks every year. Mobile seems to be generating a resurgence of interest in C++. Squeezing every last bit of performance out of tightly constrained CPU and RAM matters again.
barrkel 15y ago
Unfortunately, I don't think type theory has a whole lot to do with programming or software engineering. The most practical languages (as measured by popularity, which seems to be the best way to do it over a period of decades) do not have sound type systems, nor even particularly interesting ones theoretically.
- thesz 15y ago
  You should reconsider your stance. Types allow requirements changes to be propagated through all program. State-of-the-art type systems even allow accounting of effects, like prevent deadlocks by ensuring a specific order of locking: http://www.cs.st-andrews.ac.uk/~eb/writings/fi-cbc.pdf http://www.cs.st-andrews.ac.uk/~eb/writings/fi-cbc.pdf This is just another tool in a toolbox. You can use it. Or you can throw it away as "no one seem to use it".
  - barrkel 15y ago
    I never said "no one seems to use it". What I specifically said was that I don't think type theory has a lot to do with programming: i.e., that the majority of work put into type theory in academic contexts does not, on balance, do much to improve the state of programmers writing software, or the quality of our software engineering. "Types allow requirements changes to be propagated through all program" - what does this even mean, and why is it a justification for powerful types? I designed a system once that let you describe the program at a high level, using a DSL. I've outlined it several times on this site here (here's one link: http://news.ycombinator.com/item?id=2192322 http://news.ycombinator.com/item?id=2192322). Now that system allowed requirements changes to be propagated throughout the whole program, because the level of description of the program was dense enough that it could just about be considered detailed requirements (i.e. it was powerful - see below). It worked because it was focused on a reasonably precise niche. It did enough checks during the compilation process that you could be fairly sure that if it didn't find any errors, it would work without bugs (i.e. it was good - again, below). But the level of type system it had was no more advanced than Pascal - and I mean early Pascal, no objects etc. If you can get the same effects without a very abstract and powerful type system, isn't that better, because it reduces the overall expressiveness of the language - i.e. reducing the solution space that needs to be searched? Form can be liberating. Preventing deadlocks by ensuring a specific order of locking. Fantastic; good work. How many people are using it? Which large shipping systems are using it? What was the prior rate of deadlocks for similar systems at that level of complexity, how long did those deadlocks take to be fixed, and how much time and money was saved by using this new technique? Because frankly, deadlocks are trivial to debug; the relevant threads are stopped, and after you attach a debugger the stack traces tell you exactly which locks were taken and in which order. Debugging races is a wee bit harder. I have TAPL by Pierce right here on my bookshelf. Here's a typical sentence which illustrates my problem: "Perhaps the best illustration of the power of recursive types is the fact that we can embed the whole untyped lambda-calculus - in a well-typed way - into a statically typed language with recursive types." (pp 273). It seems to me to take for granted that a statically typed language is good[1], and that a good measure of power for a statically typed language is how expressive it is (i.e. what shapes of programs it can express, not e.g. how syntactically light it can be in doing so). And this is probably right and good, for type systems. But I have a different perspective of "good" and "power" in a programming language (as distinct from a type system). A good language is one whose target audience finds it easy to express their intent in such a way that the computer can understand. A powerful language is one in which complicated effects can be expressed with succinctness. And this is the core of it: type theorists spend entirely too much time on theoretical benefits, and far too little time on whether these benefits are worthwhile. Perhaps that's not their job, you say: and I agree to you to the extent that you also agree, then, that much of their work is irrelevant because of that. [1] I happen to like statically typed programming languages, but I understand why some people don't. I wrote an extended reply on this topic to Paul Biggar some time ago, again on this site: http://news.ycombinator.com/item?id=1110653 http://news.ycombinator.com/item?id=1110653