6 ms·
To people who say Scala has too many features, which ones would you remove? (Please don't say + to concatenate strings, because everyone knows its terrible, it
by octo_t 13y ago
To people who say Scala has too many features, which ones would you remove?
(Please don't say + to concatenate strings, because everyone knows its terrible, its there for Java compatibility)
- lmm 13y agoI'd remove structural types. I don't see them being actually used in scala libraries, and I think "traditional" types provide a better replacement for most (all?) use cases.
- octo_t 13y agoDing ding! (That's the answer I'd give if someone asked me this question)
- octo_t 13y agoSo as i understand it the 'use case' is for coercing 3rd party types into your own type hierarchy. Suppose you had: trait Foo { def bar(): Int } and 3rd party library had final class FooBar extends java.lang.Object { public int bar() { /** **/ } } you could simply define your methods to take in a: type BarAble = { def bar():Int } But obviously if the library class is not final, you can simply do: type ThirdPartyFoo = FooBar with Foo ThirdPartyFoo <: Foo
- trailfox 13y agoRemoving structural typing wouldn't be an improvement to my mind. It's the sort of thing you use maybe once a year, but when you do it's extremely useful to have around. It's a bit like saying that removing the ternary conditional operator in Java would make a big difference to developers' lives.
- lmm 13y agoI think the kind of features you use maybe once a year are a bad thing to have in programming languages - ease of reading is more important than ease of writing.
- trailfox 13y agoI should also point out that it's a feature which I don't believe detracts from readability. It's pretty clear from looking at code which uses ST what it does. There are examples in this thread. It's a feature that you will use directly maybe once a year when adding it to a library, but I then use that library (and indirectly that feature) virtually every day. YMMV but we've found it very useful.
- deleted 13y ago[deleted]
- strictfp 13y agoRemove Java backwards compatibility.
- CmonDev 13y agoEasy - drop the JVM branch and continue the CLR branch. This way you could gain better performance as well.
- trailfox 13y agoBetter performance? What are you basing that on?
- CmonDev 13y agoVM-level support of generics, value types and tail call optimization. My knowledge could be outdated though. http://stackoverflow.com/a/267496/486561 http://stackoverflow.com/a/267496/486561 http://stackoverflow.com/a/480362/486561 http://stackoverflow.com/a/480362/486561
- MichaelGG 13y agoTail calls are actually rather un-optimized in .NET. F# avoids them as much as possible. F# used to emit tail calls any time it could, but it hurt performance. IIRC, tail calls were also ignored in many areas prior to v4 (and they still have some limitations IIRC). The JVM could implement tailcalls via analysis; the tail prefix isn't truly needed. But Xamarin's porting of Java to C# to run Android on Mono without the JVM did show a rather large perf increase. I'd assume that's mostly generics eliminating boxing.
- kvb 13y agoWhat do you mean by "The JVM could implement tailcalls via analysis"? Offhand, I can't see a way for this to be practically viable, but I may just be lacking imagination.
- weak 13y agoIf you asked me 6 months ago I would say the features that confused me the most: - Covariance / Contravariance - Implicit Parameters - Implicit Conversions - and also mentioned here, Structural typing. However now that i've spent time with the language, seen these in action and used them myself I see the reason why they exist and embrace them. I can see why this would be a common complaint against Scala and can be a barrier for a lot, but I think the language is worth investing time in learning, at least for me.
- pkolaczk 13y agoCovariance / Contravariance - Noooooooo! I admit - this might be hard to grasp at first, but in reality it is very simple concept that simplifies a lot of code. It is enough to get variance right once for a class, instead of fighting with ? in Java everywhere. BTW: Kotlin has copied it and noone complains it is too complex :D As of implicit parameters / implicit objects - ok, but what do you suggest as a replacement so that map/filter/reduce preserve types correctly? Or how do you do type-classes then?
- CmonDev 13y agoAgreed, Covariance / Contravariance was a fantastic feature to borrow from C#! It just should have been implemented to be friendlier to people new to language.
- firepoet 13y agoIs that where he borrowed it from? I've seen mention of the language feature showing up in Eiffel, Sather, and so on. http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) http://en.wikipedia.org/wiki/Covariance_and_contravariance_(...
- pkolaczk 13y agoEhm... No. If any, C# borrowed it from Scala. C# got them in version 4.0, which was first half of 2010. Scala had them since I remember (from day 1?) - for sure they were in Scala 2.6, which was released in 2006.
- RivieraKid 13y agoHave a look at Ceylon, my first impression was that compared to Scala, there's much more focus on readability, regularity and productivity. Ceylon is one of the 2 languages (the other isbJulia) that I find almost perfect.
- kasey_junk 13y agoIt's not so much about what I would remove, it's more about gaining guidance/acceptance/standardization around the "right" way to do various things. When creating a library should my functionality exist explicitly on the types? As extension methods on an implicit? As type classes? When should I use infix/prefix notation? When should I use . syntax vs no .? What does _ mean in this particular line of code? Is an allocation happening for this lambda or not? Why are map/flatmap/filter magical? Why are for comprehensions part of the language for those but not for type classes? All of these kinds of questions are really hard to answer and I've been programming Scala in production for years. Other complaints I have are about the mess that is the collections library, the push for actors when they are generally a bad solution, an emphasis on algebraic types without providing Union types, and all the opportunity costs represented in sbt (which is finally passable but no better) and Scala IDE. Don't get me wrong, if you are targeting the JVM & want strong typing (I do), Scala is the best language for the job, but even for someone who uses it every day and is pretty expert there are some confusing corners & no 2 developers seem to write code the same way, so there is a price to be paid for that.
- scotth 13y agoWow, I have never heard anyone talk about actors that way, but have often thought it myself. What makes you say this?
- kasey_junk 13y agoI have 3 major complaints about actors (specifically Scala/Akka actors, but most of the models I've encountered have similar problems). 1) In general, I think that going parallel should be an architectural decision. On current commodity architectures it doesn't buy people as much as they think it does, and can in many cases over complicate code. Actors hide this complexity, but don't actually remove it. People think actors give them free license to add tons of threads when they shouldn't. 2) Actor code tends to mix business logic with threading logic, precisely what we should be trying to avoid. 3) The actor model subtly conflates publisher/consumer models which tend to decompose and perform better in parallel situations. Normally, for calculation style parallelism I prefer future/promises and for event style parallelism I prefer single writer/multiple consumer based shared memory.
- Pxtl 13y agoPython, C#, all the Java-derived languages... basically every C-ish syntax language except for C/C++ itself use + to concatenate strings. And it's an intuitive concept too - adding two strings is concatentation. That makes sense. The problem isn't + string-concat, it's silently casting numerics into strings. "foo" + 6 + 6 Should be a compiler-error.
- krapp 13y ago"foo" + 6 + 6 >Should be a compiler-error. Why? "foo" is already a string, getting "foo66" from that makes perfect sense to me. 6 + "foo" though would be crazy.