4 ms·

What I dont like about scala is its "syntaxtic flexibility". Or how I would call it, non consistent syntax. Too much features: Scala has everything, it seems l

by TeeWEE 13y ago

What I dont like about scala is its "syntaxtic flexibility". Or how I would call it, non consistent syntax. Too much features: Scala has everything, it seems like the language designers coudn't make a choice about what is best. "Whoo this is cool, lets add it". One word: implicits, arrgh Also the fact that is built on top of java... When you design a good language, you should try to do it right, and leave all other out. However this is a design choice of Scala. And I think this choice makes the language a short term language, just as a stepping stone for java programmers to better languages. - end of rant -

yareally 13y ago
Why don't you like implicits? Even the more conservative language C# has them. It beats the heck out of having to do the following in Java: BigInteger x = new BigInteger(someBigNumString); BigInteger sum = x.add(new BigInteger("1000"); When you can do this in Scala (or similar in C#): BigInt x = BigInt(someBigNumString) BigInt sum = x + 1000 If you're going to say it can be abused, lots of things can be abused in any language. I prefer sanity in this case for implicits over risk of abuse. Having to use something like BigInteger in Java without implicits just makes my head hurt trying to read and write code using it.
- pivo 13y ago
  I've done exactly one project in Scala, so I'm by no means a Scala expert. My objection to the implicit conversions is mostly when they're used with DSLs. Our project used several libraries that each implemented their own DSLs that of course made use of implicit conversions. There were two things struck me as questionable about the extensive DSL support in Scala. First, Scala source files that used one library's DSL ended up looking like they were written in a different language than Scala source files using another library's DSL. That, to me at least, makes it harder to read the source quickly and understand whats going on. This wasn't a horrible problem, but I found it somewhat burdensome to reorient myself when switching between DSLs, so I feel like it's an overall negative feature of the language. Sort of the opposite of the benefit that more consistant looking languages like Python and Go provide. It also means, at least for me, that and IDE is necessary in order to understand what's going on in source files using certain DSLs. I'm an Emacs user and this is the first time I've felt like I really should have been using an IDE, which was irritating. My second objection was that because of ambiguities between implicit conversions in different DSLs, source files that used more than one DSL had to fall back on explicit conversions and therefore not really use the DSLs. That made some source files using a given library look very different from other source files using the same library, since one was written using the DSL and the other wasn't. This is really my major objection to the language. In many other ways I really enjoyed Scala and wish I could use it more. Yet I wish DSLs and implicit conversions were used much more sparingly in Scala libraries.
happy_dino 13y ago
Could you expand on what exactly you feel is syntactically inconsistent? Considering features: Well, it certainly depends where you come from. If you come from Scheme, Scala is huge. But if you come from Java or C# or F# or ..., Scala is refreshingly small, consistent and self-contained. Regarding implicits: Most languages have implicits, they are just hard-coded into the language and will be there forever. In Scala, you can just de-import the ones you dislike and if enough people dislike those, they might even get deprecated and removed. Implicits seem to be really the feature all people except actual Scala users love hating, especially exactly those kinds of implicits which aren't even widely used anyway. Implicit conversions make up maybe 10% of all usages of “implicit ” and require a feature import.
- TeeWEE 13y ago
  Syntax: If there are 3 ways to do the same thing, you remove 1 to have a more consistent syntax. See the point in the article of the author. Features: Compared to Java, scala has a lot more features. It has functional programming for example, but its not done right, due to it's java bases. For example, try currying, you need extra syntax to curry functions. Implicits: They might have a place, but see my comment above this one.
  - happy_dino 13y ago
    Syntax: The author in the article is complaining about 18 different ways to define a function. Of those 18, the ones which use postfix operators create a feature warning already and will stop being accepted without the appropriate flag in the future. If you eliminate the ones which use additional but pointless curly braces (Really, what's the point? Why not add 5 curly braces instead of 1?), you are pretty much left with either a named variation (n =>) and an anonymous variation (_). That seems pretty reasonable. Features: Compared to Java, Scala also removes a lot of stuff. Having read both language specs, I say Scala comes out as a winner, because the actual features it has are actually working and don't consist of tons of pointless cruft like in Java or C#. Implicits: Really, implicits seem to be a big deal for those people not using Scala. For actual users of Scala, they are not. I have never touched a codebase where implicit conversions posed such an issue as it is claimed in blogs. In practice, implicit conversions are pretty rare and mostly used for Java compatibility. The good thing is that you can get rid of the ones you don't like in Scala, which you cannot do in pretty much all other languages (where they are built into the language itself).
eli_gottlieb 13y ago
Too much features: Scala has everything, it seems like the language designers coudn't make a choice about what is best. "Whoo this is cool, lets add it". One word: implicits, arrgh You mean implicit conversions, right? Because implicit parameters are the single best thing since sliced bread.
- TeeWEE 13y ago
  Yes, thanks for correcting me. Implicits parameters are not so bad, but still i'd rather love code to be explicit.
  - eli_gottlieb 13y ago
    Bah, if they were explicit, they wouldn't be nearly as useful for parametric polymorphism.
tomp 13y ago
Personally, I think implicits are one of the most useful, influential and practical features for extensibility and code reuse. They allow flexibility and extensibility without too much typing, while keeping things clean and safe (type-checked). Imagine, for example, math. Sometimes, I want 1/3 to be exact (i.e. a rational), so that 1/3 * 3 == 1, other times I want 1/3 be a float (eg. when doing numeric algebra). In a language with implicits, I could simply import the correct math object that provides the correct implementation of /, and use it in the whole module. Furthermore, if this math implementation is passed as an implicit parameter, every other library/function I use (even in another module) automatically uses the implementation of / that I want. This could be used in many other situations as well, such as memory management, where we could have an implicit policy (allocate on stack, heap, reference-counting, GC, ...), "opening" of classes (import a class and an implicit extension of it), and many other. In a way, this is similar to what Haskell type-classes do, except that it can actually be controlled by the programmer.
- TeeWEE 13y ago
  Implicit Conversion is indeed powerfull. But so is the goto statement. My experience with implicit conversion is: "Lets read this code, Ah i think it does X. Let's run it, wait what is happening, ow my why is this implicits here?" You could argue that you should use them with care, but i'd argue not to include them in the language. You'll go c++ all the way. Implicits are very powerfull for creating DSL's in Scala. And indeed scala is a good language for doing DSL's. But for me understanding what was happening by reading code was difficult. And i think code should be easy to understand.
  - tomp 13y ago
    The difference between goto and implicits is that the former are completely statically safe - typechecked and declared, and an IDE can at any point of the program tell you what's being passed implicitly. They are a bit like local (i.e. funcion-scope only) goto, which isn't that bad (and sometimes necessary, e.g. `break <label>`).

by TeeWEE 13y ago

yareally 13y ago

Why don't you like implicits? Even the more conservative language C# has them. It beats the heck out of having to do the following in Java: BigInteger x = new BigInteger(someBigNumString); BigInteger sum = x.add(new BigInteger("1000"); When you can do this in Scala (or similar in C#): BigInt x = BigInt(someBigNumString) BigInt sum = x + 1000 If you're going to say it can be abused, lots of things can be abused in any language. I prefer sanity in this case for implicits over risk of abuse. Having to use something like BigInteger in Java without implicits just makes my head hurt trying to read and write code using it.

pivo 13y ago
I've done exactly one project in Scala, so I'm by no means a Scala expert. My objection to the implicit conversions is mostly when they're used with DSLs. Our project used several libraries that each implemented their own DSLs that of course made use of implicit conversions. There were two things struck me as questionable about the extensive DSL support in Scala. First, Scala source files that used one library's DSL ended up looking like they were written in a different language than Scala source files using another library's DSL. That, to me at least, makes it harder to read the source quickly and understand whats going on. This wasn't a horrible problem, but I found it somewhat burdensome to reorient myself when switching between DSLs, so I feel like it's an overall negative feature of the language. Sort of the opposite of the benefit that more consistant looking languages like Python and Go provide. It also means, at least for me, that and IDE is necessary in order to understand what's going on in source files using certain DSLs. I'm an Emacs user and this is the first time I've felt like I really should have been using an IDE, which was irritating. My second objection was that because of ambiguities between implicit conversions in different DSLs, source files that used more than one DSL had to fall back on explicit conversions and therefore not really use the DSLs. That made some source files using a given library look very different from other source files using the same library, since one was written using the DSL and the other wasn't. This is really my major objection to the language. In many other ways I really enjoyed Scala and wish I could use it more. Yet I wish DSLs and implicit conversions were used much more sparingly in Scala libraries.

happy_dino 13y ago

Could you expand on what exactly you feel is syntactically inconsistent? Considering features: Well, it certainly depends where you come from. If you come from Scheme, Scala is huge. But if you come from Java or C# or F# or ..., Scala is refreshingly small, consistent and self-contained. Regarding implicits: Most languages have implicits, they are just hard-coded into the language and will be there forever. In Scala, you can just de-import the ones you dislike and if enough people dislike those, they might even get deprecated and removed. Implicits seem to be really the feature all people except actual Scala users love hating, especially exactly those kinds of implicits which aren't even widely used anyway. Implicit conversions make up maybe 10% of all usages of “implicit ” and require a feature import.

TeeWEE 13y ago
Syntax: If there are 3 ways to do the same thing, you remove 1 to have a more consistent syntax. See the point in the article of the author. Features: Compared to Java, scala has a lot more features. It has functional programming for example, but its not done right, due to it's java bases. For example, try currying, you need extra syntax to curry functions. Implicits: They might have a place, but see my comment above this one.
- happy_dino 13y ago
  Syntax: The author in the article is complaining about 18 different ways to define a function. Of those 18, the ones which use postfix operators create a feature warning already and will stop being accepted without the appropriate flag in the future. If you eliminate the ones which use additional but pointless curly braces (Really, what's the point? Why not add 5 curly braces instead of 1?), you are pretty much left with either a named variation (n =>) and an anonymous variation (_). That seems pretty reasonable. Features: Compared to Java, Scala also removes a lot of stuff. Having read both language specs, I say Scala comes out as a winner, because the actual features it has are actually working and don't consist of tons of pointless cruft like in Java or C#. Implicits: Really, implicits seem to be a big deal for those people not using Scala. For actual users of Scala, they are not. I have never touched a codebase where implicit conversions posed such an issue as it is claimed in blogs. In practice, implicit conversions are pretty rare and mostly used for Java compatibility. The good thing is that you can get rid of the ones you don't like in Scala, which you cannot do in pretty much all other languages (where they are built into the language itself).

eli_gottlieb 13y ago

Too much features: Scala has everything, it seems like the language designers coudn't make a choice about what is best. "Whoo this is cool, lets add it". One word: implicits, arrgh You mean implicit conversions, right? Because implicit parameters are the single best thing since sliced bread.

TeeWEE 13y ago
Yes, thanks for correcting me. Implicits parameters are not so bad, but still i'd rather love code to be explicit.
- eli_gottlieb 13y ago
  Bah, if they were explicit, they wouldn't be nearly as useful for parametric polymorphism.

tomp 13y ago

Personally, I think implicits are one of the most useful, influential and practical features for extensibility and code reuse. They allow flexibility and extensibility without too much typing, while keeping things clean and safe (type-checked). Imagine, for example, math. Sometimes, I want 1/3 to be exact (i.e. a rational), so that 1/3 * 3 == 1, other times I want 1/3 be a float (eg. when doing numeric algebra). In a language with implicits, I could simply import the correct math object that provides the correct implementation of /, and use it in the whole module. Furthermore, if this math implementation is passed as an implicit parameter, every other library/function I use (even in another module) automatically uses the implementation of / that I want. This could be used in many other situations as well, such as memory management, where we could have an implicit policy (allocate on stack, heap, reference-counting, GC, ...), "opening" of classes (import a class and an implicit extension of it), and many other. In a way, this is similar to what Haskell type-classes do, except that it can actually be controlled by the programmer.

TeeWEE 13y ago
Implicit Conversion is indeed powerfull. But so is the goto statement. My experience with implicit conversion is: "Lets read this code, Ah i think it does X. Let's run it, wait what is happening, ow my why is this implicits here?" You could argue that you should use them with care, but i'd argue not to include them in the language. You'll go c++ all the way. Implicits are very powerfull for creating DSL's in Scala. And indeed scala is a good language for doing DSL's. But for me understanding what was happening by reading code was difficult. And i think code should be easy to understand.
- tomp 13y ago
  The difference between goto and implicits is that the former are completely statically safe - typechecked and declared, and an IDE can at any point of the program tell you what's being passed implicitly. They are a bit like local (i.e. funcion-scope only) goto, which isn't that bad (and sometimes necessary, e.g. `break <label>`).