Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Covariance and Contravariance: a fresh look at an old issue [pdf]

irif.univ-paris-diderot.fr

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Covariance and Contravariance: a fresh look at an old issue [pdf]

#21

Post by btilly »

kbenson wrote: post #19
btilly wrote: post #14

Earlier quoted context omitted.

Most programmers shy away from Haskell and OCaml. :-P Seriously, the average programmer trying to learn Haskell starts with wanting to print "Hello, world", eventually winds up at a tutorial about monads, then retires with their head spinning. Haskell remains on the, "I should learn that some day" bucket list and remains unlearned. This is not to say that you don't have plenty who don't learn them. But now we have an…

Unfortunately, I think this speaks more towards the failing humans have towards assessing risk in complex systems. The cheaper to learn (considering time and effort required) languages that provide less safeguards routinely get far more new users over time. These languages can be useful in their ease of use (hey, I'm a Perl programmer, so I can't knock them entirely), but they have a far wider share of the market tha…

ahem

PHP

Re: Covariance and Contravariance: a fresh look at an old issue [pdf]

#22

Post by catnaroek »

shiro wrote: post #16
catnaroek wrote: post #15

Earlier quoted context omitted.

Why should you be able to do that?

Right, if you take type-safety first, you shouldn't be able to. But a list of abstract fruits has very limited usage without the ability to accessing concrete fruit instance. The adoption of downcasting in some OO languages came out from such needs, given that they lacked generic and/or algebraic types. And with that regard, I thought your solution didn't address the original covariance/contravariance problem (that i…

> I thought your solution didn't address

FWIW, I didn't propose the original Scala snippet, so it isn't really “my” solution.

> the original covariance/contravariance problem

The problem is precisely preventing what you're trying to do, because it's unsafe.

Re: Covariance and Contravariance: a fresh look at an old issue [pdf]

#23

Post by kbenson »

btilly wrote: post #21
kbenson wrote: post #19

Earlier quoted context omitted.

Unfortunately, I think this speaks more towards the failing humans have towards assessing risk in complex systems. The cheaper to learn (considering time and effort required) languages that provide less safeguards routinely get far more new users over time. These languages can be useful in their ease of use (hey, I'm a Perl programmer, so I can't knock them entirely), but they have a far wider share of the market tha…

ahem PHP

Indeed.[1]

There's definitely a trade-off between on-boarding new programmers and teaching good software engineering practices. I think that programming language mind-share is so overvalued at this point that to some degree we are shooting ourselves in the foot. There's some point at which the number of new users you can get based on how easy your language is to learn and the average quality of the software produced in that language are at an equilibrium[2], and I think we've seen a few languages which have blown straight past that equilibrium.

1: As I suspect most Perl programmers feel when they've had to spend time writing PHP, the event can be infuriating. Here's a language that purported to take a lot of ideas from Perl, and all you can conclude is they took all the wrong things.

2: Obviously affected by other language traits as well. I think Python keeps a higher average of quality than you would think likely though strict dogmatism, so that works well for them, even if it doesn't attract me.

Re: Covariance and Contravariance: a fresh look at an old issue [pdf]

#24

Post by shiro »

catnaroek wrote: post #22
shiro wrote: post #16

Earlier quoted context omitted.

Right, if you take type-safety first, you shouldn't be able to. But a list of abstract fruits has very limited usage without the ability to accessing concrete fruit instance. The adoption of downcasting in some OO languages came out from such needs, given that they lacked generic and/or algebraic types. And with that regard, I thought your solution didn't address the original covariance/contravariance problem (that i…

> I thought your solution didn't address FWIW, I didn't propose the original Scala snippet, so it isn't really “my” solution. > the original covariance/contravariance problem The problem is precisely preventing what you're trying to do, because it's unsafe.

Ah, ok, I mixed up you with continuational.

For this context, what I'm saying is that if you don't need to extract an apple from a list of fruits, then you can do it safely with inheritance, so whether using inheritance or delegation is irrelevant. Isn't it?

Re: Covariance and Contravariance: a fresh look at an old issue [pdf]

#25

Post by catnaroek »

shiro wrote: post #24
catnaroek wrote: post #22

Earlier quoted context omitted.

> I thought your solution didn't address FWIW, I didn't propose the original Scala snippet, so it isn't really “my” solution. > the original covariance/contravariance problem The problem is precisely preventing what you're trying to do, because it's unsafe.

Ah, ok, I mixed up you with continuational. For this context, what I'm saying is that if you don't need to extract an apple from a list of fruits, then you can do it safely with inheritance, so whether using inheritance or delegation is irrelevant. Isn't it?

If you want to extract an apple from a list of fruits, you need runtime type information (so that you can test whether a particular fruit object happens to be an apple), which has nothing to do with whether your language has inheritance or not. Using runtime type information is a symptom of bad design, though, since it lessens the extent to which you can reason about programs (as pieces of text) by just looking at their types.

Re: Covariance and Contravariance: a fresh look at an old issue [pdf]

#26

Post by vorg »

btilly wrote: post #14
catnaroek wrote: post #12

Earlier quoted context omitted.

> Unfortunately for the author, there is a chicken and egg problem here. Few programmers understand the sophisticated type system required for the reasoning solution, or can understand the weird errors that the type system can give you to say why it won't let you do something stupid. So developers shy away from languages that provide such types. Therefore there is little demand for languages that provide it. Somehow…

Most programmers shy away from Haskell and OCaml. :-P Seriously, the average programmer trying to learn Haskell starts with wanting to print "Hello, world", eventually winds up at a tutorial about monads, then retires with their head spinning. Haskell remains on the, "I should learn that some day" bucket list and remains unlearned. This is not to say that you don't have plenty who don't learn them. But now we have an…

> The sum of popularities for these three would tie with Groovy at #18

You said "highly flawed TIOBE index". Look at http://www.tiobe.com/tiobe_index?page=Groovy and notice the sudden jump from 0.33% in Nov 2015 to 1.2% a month later. I would say grossly unbelievable, even massively fabricated. I suspect Groovy's backers pulled off this trick by having "Gradle DSL" added to their Groovy keyword list, but with the announcement that Gradle are adding Kotlin to their supported DSL languages, Groovy's top 20 listing won't last.

Re: Covariance and Contravariance: a fresh look at an old issue [pdf]

#27

Post by shiro »

catnaroek wrote: post #25
shiro wrote: post #24

Earlier quoted context omitted.

Ah, ok, I mixed up you with continuational. For this context, what I'm saying is that if you don't need to extract an apple from a list of fruits, then you can do it safely with inheritance, so whether using inheritance or delegation is irrelevant. Isn't it?

If you want to extract an apple from a list of fruits, you need runtime type information (so that you can test whether a particular fruit object happens to be an apple), which has nothing to do with whether your language has inheritance or not. Using runtime type information is a symptom of bad design, though, since it lessens the extent to which you can reason about programs (as pieces of text) by just looking at th…

I agree with you all. All I say is that suggesting delegation in place of inheritance to address contravariance issue seems off the mark.
Post reply on HN