Re:Scala: sharp and gets things cut
by jaxytee on Monday October 07, 2013 @12:05PM
(#6509140)
Scala transcends the static vs dynamic typing debate via it's duck typing. Because of it's implementation of implicits, you get static type checking along with the flexibility of a language like JavaScript or Python. IMO This puts Scala head and shoulders above the rest of the programming world in terms of language design.
[ Parent
| on HN ]
Re:Scala: sharp and gets things cut
by anonymoushn on Monday October 07, 2013 @12:12PM
(#6509192)
Scala lets you spend lots of time typing incomprehensible type signatures and gives you less type safety than ML-family languages in exchange. Truly it is the pinnacle of PL design!
Yeah, I hate those incomprehensible type signatures. Just give me an Object and I'll match with the type I need.
Re:Scala: sharp and gets things cut
by anonymoushn on Monday October 07, 2013 @08:51PM
(#6512295)
I certainly hope you don't give me an Object. That would mean I still haven't escaped the JVM! Just give me HM and I can write type safe code without typing types.
I have a better idea! Let's just use strings for everything!
Re:Scala: sharp and gets things cut
by virtualwhys on Monday October 07, 2013 @04:50PM
(#6511166)
thanks for the chuckle
> Scala transcends the static vs dynamic typing debate via it's duck typing.
Hardly anyone uses duck typing in Scala (you probably mean structural typing, by the way). There are plenty of articles explaining why structural typing is a bad idea, here is one:
That article explains duck typing badly. In duck typing, you actually test if it quacks like a duck. His example doesn't, and just blindly assumes it can quack.
Re:Scala: sharp and gets things cut
by anonymoushn on Monday October 07, 2013 @03:28PM
(#6510580)
Is this really a worthwhile distinction? Using the first example from the Wikipedia article on duck typing, I have a choice between exploding when given invalid values:
def calculate(a,b,c):
return (a+b)*c
or failing silently when given invalid values, which will often cause some other piece of code to explode, or at the worst cause some misbehavior that is difficult to detect: def calculate(a,b,c):
try:
a=a+b
except:
pass
try:
a=a*c
except:
pass
return a
or def calculate(a,b,c):
try:
return (a+b)*c
except:
return None
I would prefer to just not be in the situation of choosing what to do with invalid values in the first place.