soc88

25 ms·

211.
by soc88 15y ago
No, not really. And it just broke backward compatibility, one thing all these Scala critics get so worked up about.
212.
by soc88 15y ago
Great and accurate summary.
213.
by soc88 15y ago
That's pretty interesting, because I had no trouble reading and understanding the sources of the compiler and writing simple patches for it ... and I'm not really a compiler guy and not a type theorist. The Scala compiler is in my opinion o
214.
by soc88 15y ago
Easy. The first one returns the collection type of the left collection, the second one the type of the right collection. Appending : to a method name makes makes the method right-associate. That's a very general rule, nothing to do with col
215.
by soc88 15y ago
The official style guide says the opposite: Avoid! Despite the degree to which Scala facilitates this area of API design, the definition of methods with symbolic names should not be undertaken lightly, particularly when th
216.
by soc88 15y ago
??? These are the same methods. It is common in languages with inheritance that classes implementing the same types have pretty much the same methods available ...
217.
by soc88 15y ago
Yes. Because Scala doesn't make up random rules about how you name your methods. If you name your method addAll or ++ is pretty much the same. The same rules apply to both. Both can be called the same way: coll1.addAll(coll2) c
218.
by soc88 15y ago
The ASF is missing the boat here. It is like ... the 21st century? And core people of the Apache are not only thinking “SVN should be enough for everyone” but also make it exceptionally hard for projects to use the rigth tool for their job.
219.
by soc88 15y ago
Scala doesn't permit operator overloading, it doesn't even have operators.
220.
by soc88 15y ago
Seeing that you still don't grok the basics discussed here, this is probably my last answer to you. You still fail to understand that the `map` (and other methods) are far more flexible in Scala, making them play well with sub-typing and in
221.
by soc88 15y ago
For instance you can implement a library providing Units of Measurements such that you can track the correct type through computations, e.g: val time: Time[Int] = 15 s val length: Length[Int] = 450 m val speed: Speed[Int] = ti
222.
by soc88 15y ago
http://hackerne.ws/item?id=3265598
223.
by soc88 15y ago
How about acting less aggressive? It certainly dosen't help you to get your point across. > Here's some Ruby code for you You just tried very hard to not understand the problem at hand, right? Because the equivalent Scala code looks lik
224.
by soc88 15y ago
Haskell has no subtyping as far as I know Haskell.
225.
by soc88 15y ago
Yes, yes and yes.
226.
by soc88 15y ago
The difference is that Scala also abstracts over the "container" not just the contents. If Scala only did what ML and Haskell do, the type signatures would be exactly that.
227.
by soc88 15y ago
I think the reason why Scala is often used for these niche applications is that: A) The language doesn't fall apart as soon as you try something not imagined by the original language creators. B) Pushing the boundaries actually returns usef
228.
by soc88 15y ago
I think the case is not that people knowing Scala are unable to see the problems of the language (e. g. scala.Enumeration). The thing is that people knowing the language can easily tell apart people who never seriously tried using the langu