3 ms·

Not a great example because actually you can't override simple assignment but that aside, I was disputing that Scala had more features. It doesn't. I've ackno

Not a great example because actually you can't override simple assignment but that aside, I was disputing that Scala had more features. It doesn't. I've acknowledged that the features it does have are more powerful and could be abused. The fact that operators are methods and can be overridden simplifies things - you no longer need to know and remember operators. They are always methods on the type you are looking at. This is what I mean by more regular and fewer surprises, the footprint is smaller. So you can use this simpler, more powerful feature to create DSLs. They are compile checked and are "real Scala". The tools autoamtically help you. Of course, DSLs exist in Java but they often involve tools like JTB and JavaCC, extra compilation steps, no compiler assistance for users - I could go on. Which is more complex? Anyway, I agree you could abuse the more powerful language features to write hard to comprehend code. However if you take a look at Scala code in the wild, you will see that these concerns so far have been largely theoretical and of course you can also write incomprehensible junk in Java or any other language should you wish. I'd encourage people to try the Coursera Scala course which is running again soon, and see for yourself.

xjru 14y ago
It doesn't matter which operator you choose as an example. It's the same with a == b. And I don't agree that it's a theoretical problem that only arises with bad code. It's simply a downside that we have to be aware of when we use DSLs, even well designed ones. For some purposes bland code is just better than smart code. But I do agree that a Scala based DSL is hugely superior compared to any byte code manipulation based Java framework that obscures lanaguage semantics beyond recognition. It's also way easier to reason about Scala code than about Python/Ruby style meta programming.
- happy_dino 14y ago
  It's funny that you keep picking blatantly wrong examples. scala> def ==(a: Any) = false <console>:7: error: overriding method == in class Any of type (x$1: Any)Boolean; method == cannot override final member def ==(a: Any) = false ^ Maybe you should actually use the language for a few minutes before commenting? :-)
  - xjru 14y ago
    Maybe you shouldn't try so hard to deliberately misunderstand what I'm saying. Your nitpicking doesn't change the fact that you can redefine what == does in your own classes. I hope you do realise that my point isn't even specifically about Scala, but about syntactical abstraction in general.

xjru 14y ago

It doesn't matter which operator you choose as an example. It's the same with a == b. And I don't agree that it's a theoretical problem that only arises with bad code. It's simply a downside that we have to be aware of when we use DSLs, even well designed ones. For some purposes bland code is just better than smart code. But I do agree that a Scala based DSL is hugely superior compared to any byte code manipulation based Java framework that obscures lanaguage semantics beyond recognition. It's also way easier to reason about Scala code than about Python/Ruby style meta programming.

happy_dino 14y ago
It's funny that you keep picking blatantly wrong examples. scala> def ==(a: Any) = false <console>:7: error: overriding method == in class Any of type (x$1: Any)Boolean; method == cannot override final member def ==(a: Any) = false ^ Maybe you should actually use the language for a few minutes before commenting? :-)
- xjru 14y ago
  Maybe you shouldn't try so hard to deliberately misunderstand what I'm saying. Your nitpicking doesn't change the fact that you can redefine what == does in your own classes. I hope you do realise that my point isn't even specifically about Scala, but about syntactical abstraction in general.