Live data from Hacker News

Experiment: Unit testing isn't enough; You need static types, too

evanfarrer.blogspot.ca

271–276 of 276 posts

Re: Experiment: Unit testing isn't enough; You need static types, too

#271
post #246

Earlier quoted context omitted.

> "Right now I see no difference between the good and bad" You're building a new query string each time you create a Query object, and concatenating the string onto that. With that approach, each time you build a Query object you have a fresh opportunity to mess up. So you're right that there's no difference between your to cases. Let's drop my off-the-cuff example and look at how a real library, postgresql-simple, h…

Sure, and Rails offers a similar syntax: User.select('x').where('name like ?', username) But if your language allows literal string interpolation (as Ruby does), what prevents you from doing this: query conn ("select x from users where name like #{username}") How do type-safe languages prevent this?

Query isn't a String. String interpolation[^1] would de-sugar to something like this:

  query conn ("select x from users where name like " ++ username)
++ is a function that expects two Strings. The "select..." stuff isn't a String, quotation marks not withstanding. When we try to hand a Query to ++, the compiler screams bloody murder.

Longer explanation: I suspect the syntax is a bit confusing, since while I keep saying "select ..." is a Query, it looks an awful lot like a String. Here's what's going on. Haskell has a typeclass called IsString. Query is an instance of IsString, as is String.[^2]

Quoted text can represent any instance of IsString. So the compiler sees a function that expects a Query and an IsString of some sort, and through the magic of type inference, it decides that the IsString must be a Query.[^3] And when you try to use a function that concatenates Strings on that Query, it knows that Something's Not Right.

[1]: Haskell doesn't have string interpolation. But if it did, this is how it would work.

[2]: And other instances as well. postgresql-simple actually uses ByteStrings, not Strings, for performance.

[3]: I've fuzzed the evaluation order a bit, for simplicity. In practice the first error reported might be that you've passed 2 arguments to a function that expects 3.

Re: Experiment: Unit testing isn't enough; You need static types, too

#272

Earlier quoted context omitted.

I'm a programmer that in general prefers dynamic languages. Recently I've started writing production code in Scala for a couple of web services for which I really needed the performance and flexibility of the JVM. Scala does have problems. But NOT the language. I find the language to be extremely elegant and well designed. The problem lies with the community. I find Scala libraries to be an abomination of taste and c…

David Pollak has long been one of Scala's greatest champions but his grudging acceptance that Scala is hard, from a lot of experience in the field, is worth a read: http://blog.goodstuff.im/yes-virginia-scala-is-hard/

Yeah, but Scala is hard in the same way that Ruby is hard.

You can use a subset that's easier, however the usage of the more advanced language features need a level of understanding that's beyond the capabilities of many developers.

And this is in fact true of most mainstream languages. Java may be an easy language to learn, but Java isn't just a language, but a platform - and as soon as beginners start messing around with multi-threading (since multi-threading capabilities in Java are in your face), then all hell breaks loose ... from this point of view, Scala may in fact be easier to deal with than Java is for beginners.

And for instance I see people complaining about the method signatures exposed by the collections API. I can't read those signatures very well myself, however in the case of a dynamic language, such as Ruby, you'd have to look at the source-code to see what the method actually returns. So IMHO, even if those signatures are complicated, at least you've got signatures to look at.

Re: Experiment: Unit testing isn't enough; You need static types, too

#273

Earlier quoted context omitted.

David Pollak has long been one of Scala's greatest champions but his grudging acceptance that Scala is hard, from a lot of experience in the field, is worth a read: http://blog.goodstuff.im/yes-virginia-scala-is-hard/

Yeah, but Scala is hard in the same way that Ruby is hard. You can use a subset that's easier, however the usage of the more advanced language features need a level of understanding that's beyond the capabilities of many developers. And this is in fact true of most mainstream languages. Java may be an easy language to learn, but Java isn't just a language, but a platform - and as soon as beginners start messing aroun…

I really don't think so.

Scala requires a more disciplined mindset. David Pollak actually developed Lift in response to problems he had managing big Rails projects so I don't think he would be advancing this analysis if he didn't think Scala was harder than Python/Ruby.

Re: Experiment: Unit testing isn't enough; You need static types, too

#274

Earlier quoted context omitted.

I don't think page counts of specs or feature lists really tell you that much. I didn't find it that hard too get up to speed in Scala but it seems to scare away too many Java people. My main criticism is that it allows too much syntactic flexibility.

I'm a programmer that in general prefers dynamic languages. Recently I've started writing production code in Scala for a couple of web services for which I really needed the performance and flexibility of the JVM. Scala does have problems. But NOT the language. I find the language to be extremely elegant and well designed. The problem lies with the community. I find Scala libraries to be an abomination of taste and c…

Python culture/community is a greater thing than Python. If this culture could be cloned in other places...

Re: Experiment: Unit testing isn't enough; You need static types, too

#275

Earlier quoted context omitted.

A constraint is only possibly a cost - if it forces behavior you wouldn't have chosen otherwise.

True, but free usually means freedom from both cost and restraint, so the point doesn't change much. I should have said "constraint" rather than "cost". Though the original commenter did follow-up, clarifying that the common interpretation of "free" doesn't closely match the point he'd intended to make

Fair.

Re: Experiment: Unit testing isn't enough; You need static types, too

#276
post #251

Earlier quoted context omitted.

> can static typing reduce the number of bugs No one claims otherwise. However, that's true of Java's type system too. > Why can't anyone follow a simple line of reasoning without resorting to fallacies? I followed your simplistic line of reasoning just fine. It was wrong. Admit that and move on. Of course you can't, which is how you got there. The biggest obstacle to Haskell becoming more popular is its advocates. A…

>I followed your simplistic line of reasoning just fine. It was wrong. Admit that and move on. You are wrong, admit it and move on. Oh gee, does that not actually make a constructive argument? >The biggest obstacle to Haskell becoming more popular is its advocates. What does this have to do with anything? >And, it will never replace Java, C, Python, or even PHP It already has. You might be too foolish to take advanta…

> >And, it will never replace Java, C, Python, or even PHP

> It already has.

Oh really? Significantly fewer systems are being developed in those languages? How about some evidence?

What? You meant that a couple of applications have been written in Haskell instead of those applications? That's not "replace".

Which reminds me - if I find an application that was written in Haskell that is being replaced by an implementation written in some other language, would you claim that said other language is "replacing" Haskell? If not, don't make the mirror-argument.

Post reply on HN