Live data from Hacker News

How Class-based Programming Sucks (2011)

loup-vaillant.fr

121–130 of 147 posts

Re: How Class-based Programming Sucks (2011)

#121
post #93

Earlier quoted context omitted.

PL designer here with extensive experience writing compilers in C#, Java, and Scala. Pattern matching is nice but OO will get you most of the way and filling the matching gap is simple. The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching. There are so many OO solutions to this problem it's not funny; I think I had a small argument with Wad…

I couldn't help but notice this phrase: [X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple. reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

I live ok without pattern matching and I build compilers/runtimes for a living; is that blub conceit?

I also have no problem with the expression problem. C# has partial classes anyways, which work even if type checking is non-modular. Of course, I would like it if C# support some form of pattern matching, but not enough to switch over to F# (whose pattern matching isn't as rich as Scala's, anyways).

Re: How Class-based Programming Sucks (2011)

#122

Earlier quoted context omitted.

FRP is great until you need to be interactive or switch over collections, then it becomes quite ugly. It can work for small games, like the ones in Courtney's dissertation. But over that? Not until a complete physics engine can be joined with a FRP library.

FRP can exist happily alongside imperative methods of updating state. This approach is explored in FrTime for Racket. http://cs.brown.edu/~sk/Publications/Papers/Published/ck-frt...

FrTime is not really pure FRP as envisioned by Elliot or Hudak. But then I prefer these impure FRP systems and have designed/implemented one myself called SuperGlue [1] as part of my dissertation.

[1] http://research.microsoft.com/apps/pubs/default.aspx?id=1793...

Re: How Class-based Programming Sucks (2011)

#123
post #93

Earlier quoted context omitted.

PL designer here with extensive experience writing compilers in C#, Java, and Scala. Pattern matching is nice but OO will get you most of the way and filling the matching gap is simple. The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching. There are so many OO solutions to this problem it's not funny; I think I had a small argument with Wad…

I couldn't help but notice this phrase: [X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple. reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

>reads a lot like the Blub conceit

Perhaps. But then again the "Blub conceit" is nothing that exists in real life as a proven fact of computer science.

It's just an argument expressed in an essay. Not some kind of formal logical error.

Re: How Class-based Programming Sucks (2011)

#124
post #93

Earlier quoted context omitted.

I couldn't help but notice this phrase: [X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple. reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

What is the blub conceit? Google searched it and got nothing.

A "my language is more expressive than yours" version of the Sapir–Whorf hypothesis.

Re: How Class-based Programming Sucks (2011)

#125
post #53
post #2

The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, per…

> cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms. It absolutely reduces cognitive overload. Having "containers" of functionality that allow me to easily know at a glance what I'm working with is invaluable. I'm not knocking functional programming, since I haven't built a few projects in a purely functional language yet, but trying to do some things with the functio…

In fp, those containers are known as modules.

Re: How Class-based Programming Sucks (2011)

#126
post #93

Earlier quoted context omitted.

I couldn't help but notice this phrase: [X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple. reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

I live ok without pattern matching and I build compilers/runtimes for a living; is that blub conceit? I also have no problem with the expression problem. C# has partial classes anyways, which work even if type checking is non-modular. Of course, I would like it if C# support some form of pattern matching, but not enough to switch over to F# (whose pattern matching isn't as rich as Scala's, anyways).

> I live ok without pattern matching and I build compilers/runtimes for a living; is that blub conceit?

No, I would have quoted it the first time if it was. But if you want to repeat that again you will certainly sound conceited.

Re: How Class-based Programming Sucks (2011)

#127
post #93

Earlier quoted context omitted.

I couldn't help but notice this phrase: [X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple. reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

> reads a lot like the Blub conceit Perhaps. But then again the "Blub conceit" is nothing that exists in real life as a proven fact of computer science. It's just an argument expressed in an essay. Not some kind of formal logical error.

What's your point?

Re: How Class-based Programming Sucks (2011)

#128

Earlier quoted context omitted.

I live ok without pattern matching and I build compilers/runtimes for a living; is that blub conceit? I also have no problem with the expression problem. C# has partial classes anyways, which work even if type checking is non-modular. Of course, I would like it if C# support some form of pattern matching, but not enough to switch over to F# (whose pattern matching isn't as rich as Scala's, anyways).

> I live ok without pattern matching and I build compilers/runtimes for a living; is that blub conceit? No, I would have quoted it the first time if it was. But if you want to repeat that again you will certainly sound conceited.

OK, I have no idea what point you are trying to make then. Please forgive my ignorance on your social conventions.

Re: How Class-based Programming Sucks (2011)

#129

Earlier quoted context omitted.

> I live ok without pattern matching and I build compilers/runtimes for a living; is that blub conceit? No, I would have quoted it the first time if it was. But if you want to repeat that again you will certainly sound conceited.

OK, I have no idea what point you are trying to make then. Please forgive my ignorance on your social conventions.

The point was simply that what you wrote is how a very bad argument starts. I took care to point out I wasn't accusing you of that but you have reacted defensively anyway.

It's my fault for trying to engage an HN-er in a form of discourse other than debate.

Re: How Class-based Programming Sucks (2011)

#130

Earlier quoted context omitted.

FRP can exist happily alongside imperative methods of updating state. This approach is explored in FrTime for Racket. http://cs.brown.edu/~sk/Publications/Papers/Published/ck-frt...

FrTime is not really pure FRP as envisioned by Elliot or Hudak. But then I prefer these impure FRP systems and have designed/implemented one myself called SuperGlue [1] as part of my dissertation. [1] http://research.microsoft.com/apps/pubs/default.aspx?id=1793...

I guess I prefer the impure systems then, too. :)
Post reply on HN