Why Scala not groovy or Clojure?
Aseem Bansal
Oliver Ruebenacker
"I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." -- James Strachan, inventor of Groovy
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Rex Kerr
Alan Burlison
> But in exchange, you mostly get to use the best paradigm for your
> task, and because it's strongly typed the compiler will do a lot of
> work for you to help you ensure your program is not broken in obvious
> ways.
paean of praise for Scala:
http://bellringers.net/pipermail/ringing-theory_bellringers.net/2012-July/010619.html
For those of you who don't know a Helixoid-based extent from a hole in
the ground, the subject area is English Change Ringing, which despite
being 300+ years old and involving the contents of dusty church bell
towers, is mathematically-based (it's an application of group theory)
and Scala is a good fit as a result.
https://en.wikipedia.org/wiki/Change_ringing
Eat your heart out Haskell ;-)
--
Alan Burlison
--
Eric Kolotyluk
After playing around with Java FX Script for a while I was astonished that the team at Sun Microsystems invented 'yet another language' that had many of the features of Scala, but was far less well developed than Scala. I, and others, complained about this openly, and now Java FX Script has expired, while Scala FX is a better replacement.
Years before when I learned Groovy, my sense was that it was a better Java, and I really enjoyed it. After that I tried to learn Scala, and hurt myself so badly, it took over a year to take another try at it. Since then, I find that Scala is like a better Groovy, and a much better Java in many ways, but...
At the same time, Scala is very similar to my experiences with C++ where C++ was supposed to be a better C. When Java first came out, I immediately abandoned C++ as being a waist of time, realizing that Java was a much better C than C++ could ever be. After 20 years of using Java I am still convinced that Java is astonishingly better than C++, but almost glacial in its evolution.
My ultimate hope is some new language will come along that replaces Scala the way Java replaced C++. The most valuable thing about C++ was that it was full of lessons on how not to design a language. Similarly, Scala has many good lessons on how not to design a language. My sense of Scala is that it is the 'Kitchen Sink' language that James Gosling once talked about. My other sense is that Martin Odersky was quite brilliant in the original intent of Scala, far better than Bjarne Stroustrup was at C++, but there have been so many other cooks in that kitchen since then that Scala is now a very disturbing 'kitchen sink' indeed.
While I personally enjoy writing code in Scala, I thoroughly hate reading most other people's Scala code. While I love many of the APIs in Scala, I thoroughly hate most of the others. Scala takes me to the extremes of my emotions like no other programming language I have ever used. The main problem I see with the Scala community these days is most people are too focused on adding new and 'clever' features, and too few are focused on actually cleaning up the mess.
I have seen advances in Computing Science through Scala like no other language before it, but there really needs to be a new language to replace it. Scala is a really awesome playground for ideas and innovation, but I have recently concluded that it is too dangerous and unwieldy for practical software engineering solutions.
I really look forward to the next new language to replace Scala. If anyone has any recommendations, please let me know.
- Eric
Alan Burlison
> I really look forward to the next new language to replace Scala. If
> anyone has any recommendations, please let me know.
--
Alan Burlison
--
martin odersky
"Scala.next" effort, we can clean up some of the more contentious
points of Scala. If you have some specific input what you think we
should address, I'd like to read it!
- Martin
EPFL
Rex Kerr
Raoul Duke
> to the fact that mutability is hard to reason about. Mutability is hard to
> reason about because there are too many things to keep in mind.
humans. So they need to be less complicated. That is, until the day
when the complicated solutions to things can be wrapped up into a
language / library and then stupid humans can use them w/out having to
worry about ever needing to look inside them to debug. But the
external behaviour still has to be something simple we can reason
through in our stupid human ways. (Until we leverage ourselves up into
using automated tools to do more reasoning/checking for us.) That is
e.g. what hardware designers do for us all when they make some
out-of-order supporting monster.
There are other language paradigms out there delving into other
possibilities. Maybe they can even be written up as libraries for
Scala to some degree.
* FRP (e.g. Elm)
* RDP
* linear types (e.g. ATS)
* STM (e.g. Haskell, Clojure)
* Sean McDirmid's stuff :-)
* etc.
Eric Kolotyluk
I will think more about specific input, but for now here is my general sense.
From an Architecture Astronaut perspective, the challenges mere mortals face in using Scala reminds me very much of "The Inmates Are Running The Asylum" by Alan Cooper. Largely the design and implementation of Scala and the accompanying ecosystem has been intended by Scala experts for Scala experts, and this pattern has tended to recurse upon itself like microphone feedback at a concert, producing some horrible noise at times.
This was also much of the failing of C++ where Bjarne Stroustrup et al just seemed to feed off of ever more innovative and clever design tricks without regard for real world programmers. The real genius that James Gosling and crew brought to Java was simplifying things enormously, while adding to Java the important things missing from C, well aware of the dangers of C++. In part their goal was to bring programming to the masses, the way Steve Jobs brought personal computers to the masses. While Steve Jobs democratized computers, James Gosling democratized programming. This is really the heart of what Alan Cooper is getting at:
Software engineers try very hard to make their software easy to use. They believe that their products are as easy to use as isIn essence, some of the people driving the evolution of Scala are building what they want, without clear evidence of what the end users actually need.
technically possible. As engineers, their belief is in technology. They see power and flexibility, richness of features and functionality in their software. What they don’t see is how difficult their software is to use for people who use it on a daily basis. As such, it is hard for them to see clearly the nature of the problems plaguing the software industry. The result is what Cooper calls “Dancing Bearware”. If one saw a dancing bear on the street, we would be amazed not because the bear dances well, but that the bear dances at all. Cooper likens this to software today in that people will overlook interaction problems because the software performs its function, albeit problematically and inefficiently.
-- Tim Renczes
When I was at Kodak I did a lot of User Interface Design and Implementation in Java/Swing. I think I was above average at it, but eventually I discovered other people (outside our team) who were recognizably much better than I. The point was, even though I tried to provide a lot of design leadership for our particular product, it was a lot like herding cats. Too often, other developers (like cooks in the kitchen) invented their own patterns, beaming with pride over their innovations, regardless of established principles, norms and conventions. Generally, developers designed and implemented what they liked rather than what our customers needed. I myself fell prey to this indulgence from time to time.
We did some usability testing before finalizing a few important designs. I myself conducted some tests. They were very time consuming to set up and run, but they did reveal some bad patterns in our design attempts. There in lies the problem. It is way more fun and less expensive to just write code than to go to all the trouble to understand user's actual needs.
The mathematical basis for Scala is remarkably beautiful at times, but most humans cannot appreciate the beauty of mathematics, especially at the higher levels, let alone use it. What Scala is lacking is the psychological basis for normal human cognition, rather than the cognition of a small group of computing science savants.
After learning BASIC, FOCAL, FORTRAN, PL/1, APL, etc., when I finally learned Pascal I was in shock. While Pascal did not have all the bells and whistles of other languages, it was so much easier to write good code, and understand other people's code. When I finally had to start using C in production, I felt it was a huge step backwards from Pascal. Much of the success of Pascal was because Niklaus Wirth intended it to promote good programming practices, where Dennis Ritchie was more intent on other issues than good programming practices.
It is fair to say that many of the Scala design features do promote good programming practices, most notably functional programming. However, my sense is that many other features of not only the Scala language, but the Scala ecosystem are more intended to satisfy the hacking desire of some people more intent on just having fun, without the sense of what normal software developers really need. My recent excursions into Reactive Streams has been a nightmare of WTF experiences.
My experience when I am writing Scala code is that I am constantly referring to reference materials. The language, features, and concepts are so much bigger than Java, I simply do not have enough RAM in my old brain to write code without constant paging. When I read some other people's Scala code, or worse their APIs, then my cognitive paging system starts thrashing, resulting in WTF paralysis, and my verbal synthesis framework executes the 'halt and catch fire' instruction.
I think what is needed is a new language, Scala-like perhaps, but designed more from a software engineering and human psychology perspective. There should be psychological and engineering, or ergonomics testing of critical ideas and concepts. By all means, all that has been learned from Scala should be considered, but the goal should be to consider the 'normal' end user (software developer) first.
Advances in programming language design are like a pendulum that swings between radically innovative to the pragmatically safe, and back. Scala has become a little too radical for practical use.
Cheers, Eric
Simon Ochsenreither
In the beginning, Scala shipped with traits, uniform access to values/methods, (companion) objects, and the claim that a language can have good support for both OO and FP.
All of this could have been considered experimental, eccentric or exotic, but if we look at the new crop of languages as well as many old ones, they are all picking these things up.
While I have many disagreements with Martin, he has been an excellent steward of the language, and always keeps the practical application in mind, not only the academic purity.
Although much of the work now, and in the immediate future looks researchy and academic, but has an profound impact on practical engineering:
Take the work on TASTY as an example: Scala is one of the few languages and the only one on the JVM which invests a lot of thought into making compatibility and cross-compilation feasible. No other language has this even on their radar right now!
Take the work on macros and scala.meta: People are pushing the boundaries pretty hard in Scala to make these things practical, whereas many earlier attempts in other languages fell short of having a worthwhile impact.
Take the work on dotty: I didn't believe that the fusion of compiler phases was possible in practice, and people pulled it off. This is a huge advance in compiler design outside of compilers for toy languages.
Take the work on the SBT server: Lots of fancy flow charts and indirections, but in the end it will allow people to have multiple clients like IDEs, build tools, manual input via the SBT console working concurrently without getting into each others way.
I think in ten years people will say that all of this was obvious, but it took some determined Scala people to work hard to bring these new advances into a shape usable by developers.
Of course there are issues:
I think JavaDoc/ScalaDoc style documentation is a lot less useful in Scala than in other languages. This is a problem.
The rapid development causes a lot of churn, because people figure out new ways to make their libraries safer/faster/easier to use.
Standardization can only help so much, because ossification of APIs shipped in the standard library is a huge issue if you apply the standards most Scala developers have.
There is a mismatch in expectations; many people look for a slightly nicer Java, and while Scala certainly provides this, it has so many more improvements that it can cause irritation, because most Scala people think that we can do much better and need to do much better than just having a slightly nicer Java.
If you had issues with Reactive Streams, I think the people working on it would be happy to hear the experience you had with it!
martin odersky
of it match my experience and others don't.
I believe the fundamental issue we are grappling with is abstraction.
In terms of features, core Scala is actually not that big a language.
Core Scala means: excluding things that are experimental or require a
special language import. And Dotty will further shrink the footprint.
If you do think that there are features we could do without, I'd like
to hear about them.
But Scala is a language with powerful abstraction and composition
capabilities. And these are used a lot, and undoubtedly they are also
sometimes overused.
Abstraction is a tricky business because it gives us the power to
create new things and often one person might not like the things
another person creates. So, it seems to me the only way to avoid the
misuses you refer to is to remove abstraction capabilities from the
language. Turn it into a pre-generics Java, so to speak. But that is
difficult, because almost everyone craves abstraction capabilities;
witness that pre-generics Java which did not have much of it, where
people resorted to horrible XML-based frameworks to get the
abstraction capabilities they needed. So, people abstract anyway, the
only question is whether they do it in the language or outside.
Maybe a possible path would be to have a language with only modest
abstraction capabilities but lots of features. That way, users would
not bother to write their own abstractions because there already was a
well-supported feature that did the same thing. That's sort of like
C#: In terms of feature count it is much larger than Scala, but its
users seem to complain a lot less about complexity; it seems they are
quite happy with the plethora of features they are given.
But it won't be me designing such a language, because trading
abstraction capabilities for basic features is exactly the opposite of
my design philosophy. My design philosophy is more like free speech.
We protect it even if it is abused. In fact free speech would be a
fiction if there were no abuses. In the same way, abstraction
capabilities would be a fiction if there was no over-abstraction. I
completely agree this approach comes with challenges. It is our
responsibility as good engineers to realize that abstractions have
benefits as well as costs, and to collectively develop designs where
the benefits exceed the costs.
Best,
- Martin
EPFL
Viktor Klang
Yep, Simon's right, that RS feedback would be really useful, let me know if you have any additional questions too.
--
Cheers,
√
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
Rich Oliver
Abstraction is a tricky business because it gives us the power to
create new things and often one person might not like the things
another person creates. So, it seems to me the only way to avoid the
misuses you refer to is to remove abstraction capabilities from the
language. Turn it into a pre-generics Java, so to speak. But that is
difficult, because almost everyone craves abstraction capabilities;
witness that pre-generics Java which did not have much of it, where
people resorted to horrible XML-based frameworks to get the
abstraction capabilities they needed. So, people abstract anyway, the
only question is whether they do it in the language or outside.
I'm reminded of the spoof interview with Bjarne Stroustrup where he says that he created C++ to create work for programmers. I think part of the popularity of Java is that people to get to create monstrous quasi languages on top called frameworks. If someone really created the perfect general purpose programming language, it would rather spoil all the other would be language designers fun.
Maybe a possible path would be to have a language with only modest
abstraction capabilities but lots of features. That way, users would
not bother to write their own abstractions because there already was a
well-supported feature that did the same thing. That's sort of like
C#: In terms of feature count it is much larger than Scala, but its
users seem to complain a lot less about complexity; it seems they are
quite happy with the plethora of features they are given.
But it won't be me designing such a language, because trading
abstraction capabilities for basic features is exactly the opposite of
my design philosophy. My design philosophy is more like free speech.
We protect it even if it is abused. In fact free speech would be a
fiction if there were no abuses. In the same way, abstraction
capabilities would be a fiction if there was no over-abstraction. I
completely agree this approach comes with challenges. It is our
responsibility as good engineers to realize that abstractions have
benefits as well as costs, and to collectively develop designs where
the benefits exceed the costs.
Best,
- Martin
I could be wrong but my sense is that Spark is the long awaited Scala killer App. I see Scala is up to 24 on Tiobe. If I'm right then love it or hate it Scala is about to arrive.
Eric Kolotyluk
I would agree that abstraction can be a fundamental problem at times. Not everyone handles abstraction with equal skill and ease. There is much we could do to make it easier for more people to deal with the abstraction better.
For example, it made sense in Scala to replace the for-loop with the for-comprehension, but it is very much harder for some of us to keep our heads wrapped around the for-comprehension. The for-comprehension is an abstraction of map and flatmap. There is a lot more going on behind the scenes that a for-loop. While I can write code with correct for-comprehensions, it still takes me significantly more mental effort that writing a for-loop in Java.
The problem with abstraction is that, often too much of the actual mechanism is being hidden by elegant looking code, that it becomes harder to reason about the code. For example, one of my pet peeves is using for-comprehensions to deal with future values. Not only are the map and flatmap mechanisms hidden, but all of the concurrent mechanisms are too. It becomes hard to wrap your head around it without significant practice, and if your are new to the concept, well then you have no practice at all. For example, it is really easy for a novice to accidentally try to assign the expressions generating the future values within the for-comprehension itself. You 'just have to know' to assign the expressions to future vals before the for-comprehension because there is nothing in the code to show any problem, the Scala compiler will too happily do what you say and not what you want.
In particular, what I find too often challenging in reading Scala code and APIs is these 'you just have to know' moments. This is especially true when dealing with futures, promises, and other reactive mind puzzles.
There are various ways you could go. You could create a language that is more 'feature rich' to reduce the abstraction, but I am not advocating that.
- You could improve the training materials, but this requires scarce resources.
- Sadly the Scaladoc is generally of little help in
understanding important APIs, and I do not sense any urgency
in the community to produce better Scaladoc.
- While the first Coursera course I took was excellent, the second Coursera course was especially frustrating because Erik Meijer is simply not as good at explaining things as Martin and Roland are. I am sure Erik is a wonderful person, but he is not great at explaining things.
- When I went to other web sites to trying to understand reactive streams, the explanations were just as atrocious.
- In the course I actually had to experiment with some code to
understand what was really going on in Assignment 4. I
published my example in the discussion group. Several other
students thanked me because it really helped them understand
what was mechanically going on. Basically I solved the problem
of poorly explained abstraction by creating an example to
clearly demonstrate the concrete mechanics. This is something
that Erik or someone else should have done before the course.
I wish I could find someone to pay me to write Scala training
materials.
- You could build more diagnostic intelligence into Scalac to perform better static analysis. For example:
- Warning, you have written a for-comprehension with expressions producing Future values that should probably be computed prior to the for-comprehension. For example (followed by a clear example what to do).
- You could even change scalac to do the right thing in the
first place, but I am not enough of a compiler expert to know
how hard that would be to do, and the other dangers it would
create.
Basically I am not asking anyone to abandon their design
philosophy around using abstraction, but only to think more about
the problems that are created and finding solutions to those
problems too. Think more like Alan Cooper did.
I will leave you with this. When the automobile was invented, few
really cared about the problems it created. Millions of people
have died in automobile accidents, and now our entire planet is in
peril because of climate change. Many of the automobile's problems
were finally addressed when Ralph Nader came on the scene, and
many more have not been addressed. Computing Science and Software
Engineering have not seen their Ralph Nader yet, and we continue
to forge ahead without really appreciating the unintended
consequences of our actions.
Cheers, Eric
P.S. Implicit really should be removed from the language. It
causes more problems than it solves by creating even more of those
'you just have to know' moments. I really hate reading examples
people write because you generally cannot copy and paste them to
get a working example as they almost never declare the hidden
implicits the example depends on. It is generally impossible to
convince everyone to actually test their code examples before
publishing them. IMHO, implicit was one of the worse features
added to Scala, and I hope it gets removed from Dotty.
Eric Kolotyluk
On Thursday, 5 November 2015 08:02:47 UTC, martin wrote:
Abstraction is a tricky business because it gives us the power to
create new things and often one person might not like the things
another person creates. So, it seems to me the only way to avoid the
misuses you refer to is to remove abstraction capabilities from the
language. Turn it into a pre-generics Java, so to speak. But that is
difficult, because almost everyone craves abstraction capabilities;
witness that pre-generics Java which did not have much of it, where
people resorted to horrible XML-based frameworks to get the
abstraction capabilities they needed. So, people abstract anyway, the
only question is whether they do it in the language or outside.
I'm reminded of the spoof interview with Bjarne Stroustrup where he says that he created C++ to create work for programmers. I think part of the popularity of Java is that people to get to create monstrous quasi languages on top called frameworks. If someone really created the perfect general purpose programming language, it would rather spoil all the other would be language designers fun.
Maybe a possible path would be to have a language with only modest
abstraction capabilities but lots of features. That way, users would
not bother to write their own abstractions because there already was a
well-supported feature that did the same thing. That's sort of like
C#: In terms of feature count it is much larger than Scala, but its
users seem to complain a lot less about complexity; it seems they are
quite happy with the plethora of features they are given.
C# is part of the .Net Visual Studio eco system, so it has a huge budget, which really helps for documentation and testing. It shouldn't be surprising that C# can keep its user base happy. Its inevitable that the bar for Scala is going to be a lot higher. Early adopters are inevitably far more self opinionated. However I do think Scala has made some wrong choices notably in the collections library, which has created extra complexity. But I see no reason to apologise for this. Things can only be learnt through experimentation. But not just experimentation, there needs to be a certain pig headedness. An approach might seem like a mistake, but requires someone to keep banging at it before it finally gets to to be really usable. Sometimes a break though happens because someone keeps pushing their intuition long after everyone else had written it off.
What I find interesting is that even though Microsoft has all the experience of Java to learn from, they still botched a lot of things in C#/.NET because Microsoft has a very different philosophy than Sun did. Some things in C# were better than Java, but overall I still find Java a more productive development environment.
Scala suffers from the fact it does not have entities like Oracle or Microsoft funding it.
Eric Kolotyluk
I agree we have learned many useful things in the laboratory that is Scala, but sooner or later it would be nice if these things were repackaged in a form that is practical and not only experimental.
My main problem with reactive streams is that they are poorly explained. People are too focused on building, and not putting enough effort into explaining things that well. As I said in another post: During the Scala Reactive course, I was able to build example code that demonstrated the mechanisms much better than the course materials. It's not that it's hard to explain reactive streams, it just not a priority. Someone really needs to pay for some good tech writers to build better training materials, and to challenge the designers to create better designs.
Cheers, Eric
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
Simon Ochsenreither
I agree we have learned many useful things in the laboratory that is Scala, but sooner or later it would be nice if these things were repackaged in a form that is practical and not only experimental.
How would that look like? Sadly what I see is that most languages just adopt either whatever Scala did or something worse (usually 10 years after Scala shipped it).
Do you have an example where an experimental feature in Scala shipped in a more practical form somewhere else?
Naftoli Gugenheim
On Thu, Nov 5, 2015, 6:25 PM Eric Kolotyluk <eric.ko...@gmail.com> wrote:
It would be odd if all our experiences matched Martin, and it is serendipitous that some do :-)
I would agree that abstraction can be a fundamental problem at times. Not everyone handles abstraction with equal skill and ease. There is much we could do to make it easier for more people to deal with the abstraction better.
For example, it made sense in Scala to replace the for-loop with the for-comprehension, but it is very much harder for some of us to keep our heads wrapped around the for-comprehension. The for-comprehension is an abstraction of map and flatmap. There is a lot more going on behind the scenes that a for-loop. While I can write code with correct for-comprehensions, it still takes me significantly more mental effort that writing a for-loop in Java.
The problem with abstraction is that, often too much of the actual mechanism is being hidden by elegant looking code, that it becomes harder to reason about the code. For example, one of my pet peeves is using for-comprehensions to deal with future values. Not only are the map and flatmap mechanisms hidden, but all of the concurrent mechanisms are too. It becomes hard to wrap your head around it without significant practice, and if your are new to the concept, well then you have no practice at all. For example, it is really easy for a novice to accidentally try to assign the expressions generating the future values within the for-comprehension itself. You 'just have to know' to assign the expressions to future vals before the for-comprehension because there is nothing in the code to show any problem, the Scala compiler will too happily do what you say and not what you want.
While it is indeed a common mistake, and documentation should be improved, I don't agree that it's a "you just have to know." If the value produced by previous future is in scope, that's proof that it has completed.
I think part of the reason people don't think of that, it's they're trying to use something without a clear understanding of it. Which is fine, but let's recognize that.
In particular, what I find too often challenging in reading Scala code and APIs is these 'you just have to know' moments. This is especially true when dealing with futures, promises, and other reactive mind puzzles.
There are various ways you could go. You could create a language that is more 'feature rich' to reduce the abstraction, but I am not advocating that.
You could improve the training materials, but this requires scarce resources.Sadly the Scaladoc is generally of little help in understanding important APIs, and I do not sense any urgency in the community to produce better Scaladoc.
While the first Coursera course I took was excellent, the second Coursera course was especially frustrating because Erik Meijer is simply not as good at explaining things as Martin and Roland are. I am sure Erik is a wonderful person, but he is not great at explaining things.When I went to other web sites to trying to understand reactive streams, the explanations were just as atrocious.In the course I actually had to experiment with some code to understand what was really going on in Assignment 4. I published my example in the discussion group. Several other students thanked me because it really helped them understand what was mechanically going on. Basically I solved the problem of poorly explained abstraction by creating an example to clearly demonstrate the concrete mechanics. This is something that Erik or someone else should have done before the course. I wish I could find someone to pay me to write Scala training materials.
You could build more diagnostic intelligence into Scalac to perform better static analysis. For example:Warning, you have written a for-comprehension with expressions producing Future values that should probably be computed prior to the for-comprehension. For example (followed by a clear example what to do). You could even change scalac to do the right thing in the first place, but I am not enough of a compiler expert to know how hard that would be to do, and the other dangers it would create.
There's no way to know that. Very often you specifically *want* it to run subsequently.
Basically I am not asking anyone to abandon their design philosophy around using abstraction, but only to think more about the problems that are created and finding solutions to those problems too. Think more like Alan Cooper did.
I will leave you with this. When the automobile was invented, few really cared about the problems it created. Millions of people have died in automobile accidents, and now our entire planet is in peril because of climate change. Many of the automobile's problems were finally addressed when Ralph Nader came on the scene, and many more have not been addressed. Computing Science and Software Engineering have not seen their Ralph Nader yet, and we continue to forge ahead without really appreciating the unintended consequences of our actions.
Cheers, Eric
P.S. Implicit really should be removed from the language. It causes more problems than it solves
How many problems does it solve?
by creating even more of those 'you just have to know' moments. I really hate reading examples people write because you generally cannot copy and paste them to get a working example as they almost never declare the hidden implicits the example depends on. It is generally impossible to convince everyone to actually test their code examples before publishing them. IMHO, implicit was one of the worse features added to Scala, and I hope it gets removed from Dotty.
On 2015-11-05 12:02 AM, martin odersky wrote:
Thanks for your input, Eric. It's interesting to me because some parts of it match my experience and others don't. I believe the fundamental issue we are grappling with is abstraction. In terms of features, core Scala is actually not that big a language. Core Scala means: excluding things that are experimental or require a special language import. And Dotty will further shrink the footprint. If you do think that there are features we could do without, I'd like to hear about them. But Scala is a language with powerful abstraction and composition capabilities. And these are used a lot, and undoubtedly they are also sometimes overused. Abstraction is a tricky business because it gives us the power to create new things and often one person might not like the things another person creates. So, it seems to me the only way to avoid the misuses you refer to is to remove abstraction capabilities from the language. Turn it into a pre-generics Java, so to speak. But that is difficult, because almost everyone craves abstraction capabilities; witness that pre-generics Java which did not have much of it, where people resorted to horrible XML-based frameworks to get the abstraction capabilities they needed. So, people abstract anyway, the only question is whether they do it in the language or outside. Maybe a possible path would be to have a language with only modest abstraction capabilities but lots of features. That way, users would not bother to write their own abstractions because there already was a well-supported feature that did the same thing. That's sort of like C#: In terms of feature count it is much larger than Scala, but its users seem to complain a lot less about complexity; it seems they are quite happy with the plethora of features they are given. But it won't be me designing such a language, because trading abstraction capabilities for basic features is exactly the opposite of my design philosophy. My design philosophy is more like free speech. We protect it even if it is abused. In fact free speech would be a fiction if there were no abuses. In the same way, abstraction capabilities would be a fiction if there was no over-abstraction. I completely agree this approach comes with challenges. It is our responsibility as good engineers to realize that abstractions have benefits as well as costs, and to collectively develop designs where the benefits exceed the costs. Best, - Martin On Thu, Nov 5, 2015 at 6:50 AM, Eric Kolotyluk <eric.ko...@gmail.com> wrote:
On 2015-11-04 1:32 PM, martin odersky wrote: On Wed, Nov 4, 2015 at 9:02 PM, Eric Kolotyluk <eric.ko...@gmail.com> wrote: Interesting claim by James Strachan. Very honest and sensible. After playing around with Java FX Script for a while I was astonished that the team at Sun Microsystems invented 'yet another language' that had many of the features of Scala, but was far less well developed than Scala. I, and others, complained about this openly, and now Java FX Script has expired, while Scala FX is a better replacement. Years before when I learned Groovy, my sense was that it was a better Java, and I really enjoyed it. After that I tried to learn Scala, and hurt myself so badly, it took over a year to take another try at it. Since then, I find that Scala is like a better Groovy, and a much better Java in many ways, but... At the same time, Scala is very similar to my experiences with C++ where C++ was supposed to be a better C. When Java first came out, I immediately abandoned C++ as being a waist of time, realizing that Java was a much better C than C++ could ever be. After 20 years of using Java I am still convinced that Java is astonishingly better than C++, but almost glacial in its evolution. My ultimate hope is some new language will come along that replaces Scala the way Java replaced C++. The most valuable thing about C++ was that it was full of lessons on how not to design a language. Similarly, Scala has many good lessons on how not to design a language. My sense of Scala is that it is the 'Kitchen Sink' language that James Gosling once talked about. My other sense is that Martin Odersky was quite brilliant in the original intent of Scala, far better than Bjarne Stroustrup was at C++, but there have been so many other cooks in that kitchen since then that Scala is now a very disturbing 'kitchen sink' indeed. While I personally enjoy writing code in Scala, I thoroughly hate reading most other people's Scala code. While I love many of the APIs in Scala, I thoroughly hate most of the others. Scala takes me to the extremes of my emotions like no other programming language I have ever used. The main problem I see with the Scala community these days is most people are too focused on adding new and 'clever' features, and too few are focused on actually cleaning up the mess. I have seen advances in Computing Science through Scala like no other language before it, but there really needs to be a new language to replace it. Scala is a really awesome playground for ideas and innovation, but I have recently concluded that it is too dangerous and unwieldy for practical software engineering solutions. I really look forward to the next new language to replace Scala. If anyone has any recommendations, please let me know. Thanks for the frank assessment, Eric! I do hope that with Dotty, the "Scala.next" effort, we can clean up some of the more contentious points of Scala. If you have some specific input what you think we should address, I'd like to read it! - Martin I tried following Dotty, but it is hard to see how to get started as everything is still very raw (uncooked). In particular, what is the difference between a Dotty program and a Scala one? Is there a Dotty primmer? I will think more about specific input, but for now here is my general sense. From an Architecture Astronaut perspective, the challenges mere mortals face in using Scala reminds me very much of "The Inmates Are Running The Asylum" by Alan Cooper. Largely the design and implementation of Scala and the accompanying ecosystem has been intended by Scala experts for Scala experts, and this pattern has tended to recurse upon itself like microphone feedback at a concert, producing some horrible noise at times. This was also much of the failing of C++ where Bjarne Stroustrup et al just seemed to feed off of ever more innovative and clever design tricks without regard for real world programmers. The real genius that James Gosling and crew brought to Java was simplifying things enormously, while adding to Java the important things missing from C, well aware of the dangers of C++. In part their goal was to bring programming to the masses, the way Steve Jobs brought personal computers to the masses. While Steve Jobs democratized computers, James Gosling democratized programming. This is really the heart of what Alan Cooper is getting at: Software engineers try very hard to make their software easy to use. They believe that their products are as easy to use as is technically possible. As engineers, their belief is in technology. They see power and flexibility, richness of features and functionality in their software. What they don’t see is how difficult their software is to use for people who use it on a daily basis. As such, it is hard for them to see clearly the nature of the problems plaguing the software industry. The result is what Cooper calls “Dancing Bearware”. If one saw a dancing bear on the street, we would be amazed not because the bear dances well, but that the bear dances at all. Cooper likens this to software today in that people will overlook interaction problems because the software performs its function, albeit problematically and inefficiently. -- Tim Renczes In essence, some of the people driving the evolution of Scala are building what they want, without clear evidence of what the end users actually need. When I was at Kodak I did a lot of User Interface Design and Implementation in Java/Swing. I think I was above average at it, but eventually I discovered other people (outside our team) who were recognizably much better than I. The point was, even though I tried to provide a lot of design leadership for our particular product, it was a lot like herding cats. Too often, other developers (like cooks in the kitchen) invented their own patterns, beaming with pride over their innovations, regardless of established principles, norms and conventions. Generally, developers designed and implemented what they liked rather than what our customers needed. I myself fell prey to this indulgence from time to time. We did some usability testing before finalizing a few important designs. I myself conducted some tests. They were very time consuming to set up and run, but they did reveal some bad patterns in our design attempts. There in lies the problem. It is way more fun and less expensive to just write code than to go to all the trouble to understand user's actual needs. The mathematical basis for Scala is remarkably beautiful at times, but most humans cannot appreciate the beauty of mathematics, especially at the higher levels, let alone use it. What Scala is lacking is the psychological basis for normal human cognition, rather than the cognition of a small group of computing science savants. After learning BASIC, FOCAL, FORTRAN, PL/1, APL, etc., when I finally learned Pascal I was in shock. While Pascal did not have all the bells and whistles of other languages, it was so much easier to write good code, and understand other people's code. When I finally had to start using C in production, I felt it was a huge step backwards from Pascal. Much of the success of Pascal was because Niklaus Wirth intended it to promote good programming practices, where Dennis Ritchie was more intent on other issues than good programming practices. It is fair to say that many of the Scala design features do promote good programming practices, most notably functional programming. However, my sense is that many other features of not only the Scala language, but the Scala ecosystem are more intended to satisfy the hacking desire of some people more intent on just having fun, without the sense of what normal software developers really need. My recent excursions into Reactive Streams has been a nightmare of WTF experiences. My experience when I am writing Scala code is that I am constantly referring to reference materials. The language, features, and concepts are so much bigger than Java, I simply do not have enough RAM in my old brain to write code without constant paging. When I read some other people's Scala code, or worse their APIs, then my cognitive paging system starts thrashing, resulting in WTF paralysis, and my verbal synthesis framework executes the 'halt and catch fire' instruction. I think what is needed is a new language, Scala-like perhaps, but designed more from a software engineering and human psychology perspective. There should be psychological and engineering, or ergonomics testing of critical ideas and concepts. By all means, all that has been learned from Scala should be considered, but the goal should be to consider the 'normal' end user (software developer) first. Advances in programming language design are like a pendulum that swings between radically innovative to the pragmatically safe, and back. Scala has become a little too radical for practical use. Cheers, Eric - Eric On 2015-11-04 6:50 AM, Oliver Ruebenacker wrote: Hello, "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." -- James Strachan, inventor of Groovy Clojure? Sure, if you like Lisp. Best, Oliver On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal <asmba...@gmail.com> wrote: Can someone give any inputs on https://www.reddit.com/r/scala/comments/3rhu5n/why_scala_not_groovy_or_clojure/ Asked a similar question from Clojure community https://www.reddit.com/r/Clojure/comments/3rcjus/new_clojurians_ask_anything/cwmue2n -- You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsub...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Oliver Ruebenacker Senior Software Engineer, Diabetes Portal, Broad Institute -- You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsub...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsub...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsub...@googlegroups.com.
Alan Burlison
> P.S. Implicit really should be removed from the language. It causes more
> problems than it solves by creating even more of those 'you just have to
> know' moments. I really hate reading examples people write because you
> generally cannot copy and paste them to get a working example as they
> almost never declare the hidden implicits the example depends on. It is
> generally impossible to convince everyone to actually test their code
> examples before publishing them. IMHO, implicit was one of the worse
> features added to Scala, and I hope it gets removed from Dotty.
(appropriate) use of implicits. Yes they can be abused, but that's the
same as any other language feature.
--
Alan Burlison
--
Rüdiger Klaehn
> P.S. Implicit really should be removed from the language. It causes more
> problems than it solves by creating even more of those 'you just have to
> know' moments. I really hate reading examples people write because you
> generally cannot copy and paste them to get a working example as they almost
> never declare the hidden implicits the example depends on. It is generally
> impossible to convince everyone to actually test their code examples before
> publishing them. IMHO, implicit was one of the worse features added to
> Scala, and I hope it gets removed from Dotty.
>
More than half of the libraries that make up the scala ecosystem would
not even be possible without some kind of implicits mechanism. Just
from the top of my head: spire, algebird, shapeless, scalaz, cats.
Many of the commercially successful scala products such as spark build
on those libraries.
Oliver Ruebenacker
Haddock
Couldn't you just replace every use of an implicit with an explicit?Best, Oliver
-- Haddock
Roland Kuhn
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Haddock
Couldn't you just replace every use of an implicit with an explicit?Yes, of course, but that would defeat the point: we want the compiler to figure out the value for us, meaning the compiler runs a computation on our behalf.There seems to be growing consensus that implicit conversions are a bad idea (hence they are guarded by a language feature import now), but implicit arguments are vital for concise DSLs as well as type-level computations and implicit classes (a.k.a. extension methods) greatly improve the ability to separate data from behavior.With these points in mind I must say that I am quite puzzled by Eric’s statement, the only possible interpretation is that he means dotty shall be completely different from Scala, not a successor (because it would explore a different region of the design space).
No, he means not to have implicitsin the same way they are rejected in Kotlin and also no other language has them for a good reason (scalability of build times).
-- Haddock
Rich Oliver
There seems to be growing consensus that implicit conversions are a bad idea (hence they are guarded by a language feature import now),
Its Any2StringAdd that produces despair me in. I mean why bother? Why not just use Javascript?
Rex Kerr
package die.die.die
package object Any2StringAdd {
implicit class any2stringadd[A](a: A) {}
}
import die.die.die.Any2StringAdd._
object ItsGone {
val fails = Option("Hi") + "there"
}
$ scalac ItsGone.scala
ItsGone.scala:4: error: value + is not a member of Option[String]
val fails = Option("Hi") + "there"
^
one error found
--
Kevin Wright
Rich Oliver
implicit class any2stringadd[A](a: A) {}
Rüdiger Klaehn
> On Friday, 6 November 2015 14:02:34 UTC, rkuhn wrote:
>>
>>
>> There seems to be growing consensus that implicit conversions are a bad
>> idea (hence they are guarded by a language feature import now),
>>
> I can't see what's wrong with implicit conversions as long as they are used
> for conversion to specific types. For example I use them to convert Strings
> to HTML content. It is irritating that sensible valid uses require a
> compiler flag, while Any2StringAdd the one implicit conversion we really
> want to get rid of, we can't. Why can't we have a compiler flag to switch
> Any2StringAdd off?
>
If you have an implicit conversion from String to HTMLContent in
scope, every single String in your program will suddenly have all the
methods of HTMLContent (except if they have the same name as a method
on string). This is very rarely what you want. Having a single
extension method "x".asHtmlContent is very much preferable. This is
one of the reasons why usage JavaConversions is discouraged in favour
of JavaConverters.
Implicit conversions are much more dangerous than implicits as
evidence (the approach that enables all those powerful libraries like
shapeless, spire etc.)
Simon Ochsenreither
No, he means not to have implicits in the same way they are rejected in Kotlin and also no other language has them for a good reason (scalability of build times).
I think that really depends on which implicits you are thinking of:
- Many languages have implicit conversions, including many popular ones like Java and C#.
- Scala has implicit classes, which have largely the same drawbacks as extension methods, but many advantages, making them superior to extension methods in every way.
- Implicit parameters are in Scala, Adga, Idris, and in an upcoming version of OCaml.
Rex Kerr
No, he means not to have implicits in the same way they are rejected in Kotlin and also no other language has them for a good reason (scalability of build times).
I think that really depends on which implicits you are thinking of:
- Many languages have implicit conversions, including many popular ones like Java and C#.
- Scala has implicit classes, which have largely the same drawbacks as extension methods, but many advantages, making them superior to extension methods in every way.
Alan Burlison
> - Many languages have implicit conversions, including many popular ones
> like Java and C#.
Even C has implicit conversions, and calls them exactly that. You just
don't get to say what they are.
--
Alan Burlison
--
Henry Story
On 4 Nov 2015, at 14:29, Aseem Bansal <asmba...@gmail.com> wrote:
Can someone give any inputs on https://www.reddit.com/r/scala/comments/3rhu5n/why_scala_not_groovy_or_clojure/Asked a similar question from Clojure community
Eric Kolotyluk
I am still waiting for an answer to Oliver's question.
I believe that implicit was a useful experiment in an experimental language such as Scala. The point of experiments is that you sometimes have to admit it was a bad idea and move on. Can anyone provide me with a list of bad features that were removed from Scala?
Part of why Scala is suffering from the 'too many cooks in the kitchen' problem is that some of the extra cooks may also suffer from 'shiny object syndrome' and will fight passionately to keep their particular shiny new Scala feature in the language, no matter what. But hey, that is fine as long as you accept that Scala is a kitchen sink language where we can continue to experiment and learn.
One of the strengths of Java is that it is guided by a philosophy that: if you make a mistake in new language features, you cannot take them back. This is necessary for a production language such as Java. On the other hand, because Scala is not a production language, but a research language, it is perfectly OK to make such mistakes.
We truly need both conservative and progressive thought in programming language design. Software Engineers need to have stable, well tested tools in order to build robust, maintainable solutions to real world problems. However, these tools need to evolve from Computing Scientists who take delight in thinking out of the box, challenging old ideas, exploring and experimenting with new perspectives.
Part of the success of Scala is that Martin Odersky is not Gordon Ramsay. He is a great designer and teacher, who encourages and promotes new ideas and experimentation. On the other hand, if you are trying to get the meals out for the evening in a five star restaurant, you sort of needs someone like Gordon Ramsay to exert control over the other cooks. Like it or not, Java, C#, and even C++ and Javascript are those five star restaurants. I am simply looking forward to the next five star language to emerge.
Cheers, Eric
Rex Kerr
Eric Kolotyluk
As far as library changes, the deprecation processes started in Java, is
a good way to remove bad API features, but it cannot work for actual
language features.
Cheers, Eric
Eric Kolotyluk
--
I would say that Function Types being implemented in Java 8 is a god example of an experimental feature being shipped in a more practical form somewhere else.
It is easy to poke holes at that statement so I will go on to explain.
My premise is that Scala is still an experimental language, therefore even Function Types are an experimental feature, even though they are a core feature of Scala. The landmark success of Scala was to prove that functional and object oriented features could coexist competently. The fact that Java has incorporated it validates that success. Then again, compared to C#, Java was late to the game, but better late than never.
Also, C# implemented Function Types in a manner very recognizable to Scala, so it is fair to say, two leading languages have benefited from importing Scala features.
Similarly, Java is reducing boilerplate based on Scala. Similarly, the design of the Scala collections classes has greatly influenced the evolution of the Java collections classes, most notably around.
I would agree, that from your perspective "what I see is that most languages just adopt either whatever Scala did..." but this really is features repackaged in a more practical form.
In the long run, I would like to see a new language, that takes the good things in Scala (and some other languages), but intentionally leaves out the problematic features the same way that Java left out the worst features of C++ and other languages.
Sadly, I am not a brilliant composer like Martin Ordersky and others, but I am a pretty good DJ.
Cheers, Eric
Naftoli Gugenheim
Thanks. You are correct in what I mean Haddock.
I am still waiting for an answer to Oliver's question.
I believe that implicit was a useful experiment in an experimental language such as Scala. The point of experiments is that you sometimes have to admit it was a bad idea
and move on.
Can anyone provide me with a list of bad features that were removed from Scala?
Part of why Scala is suffering from the 'too many cooks in the kitchen' problem is that some of the extra cooks may also suffer from 'shiny object syndrome' and will fight passionately to keep their particular shiny new Scala feature in the language, no matter what. But hey, that is fine as long as you accept that Scala is a kitchen sink language where we can continue to experiment and learn.
One of the strengths of Java is that it is guided by a philosophy that: if you make a mistake in new language features, you cannot take them back. This is necessary for a production language such as Java. On the other hand, because
Scala is not a production language, but a research language,
it is perfectly OK to make such mistakes.
We truly need both conservative and progressive thought in programming language design. Software Engineers need to have stable, well tested tools in order to build robust, maintainable solutions to real world problems. However, these tools need to evolve from Computing Scientists who take delight in thinking out of the box, challenging old ideas, exploring and experimenting with new perspectives.
Part of the success of Scala is that Martin Odersky is not Gordon Ramsay. He is a great designer and teacher, who encourages and promotes new ideas and experimentation. On the other hand, if you are trying to get the meals out for the evening in a five star restaurant, you sort of needs someone like Gordon Ramsay to exert control over the other cooks. Like it or not, Java, C#, and even C++ and Javascript are those five star restaurants. I am simply looking forward to the next five star language to emerge.
Cheers, Eric
On 2015-11-06 6:27 AM, Haddock wrote:
Couldn't you just replace every use of an implicit with an explicit?
Yes, of course, but that would defeat the point: we want the compiler to figure out the value for us, meaning the compiler runs a computation on our behalf.
There seems to be growing consensus that implicit conversions are a bad idea (hence they are guarded by a language feature import now), but implicit arguments are vital for concise DSLs as well as type-level computations and implicit classes (a.k.a. extension methods) greatly improve the ability to separate data from behavior.
With these points in mind I must say that I am quite puzzled by Eric’s statement, the only possible interpretation is that he means dotty shall be completely different from Scala, not a successor (because it would explore a different region of the design space).
No, he means not to have implicitsin the same way they are rejected in Kotlin and also no other language has them for a good reason (scalability of build times).
-- Haddock
martin odersky
contribution of Scala to programming languages. Implicit conversions
are more contentious and I am glad they have to be explicitly enabled
by a language import. I do think they are over-used in most cases, but
at least you get a warning:
<console>:11: warning: implicit conversion method foo should be enabled
by making the implicit value scala.language.implicitConversions visible.
This can be achieved by adding the import clause 'import
scala.language.implicitConversions'
or by setting the compiler option -language:implicitConversions.
See the Scala docs for value scala.language.implicitConversions for a discussion
why the feature should be explicitly enabled.
And then if I look up the link you get:
Why control it? Implicit conversions are known to cause many pitfalls
if over-used. And there is a tendency to over-use them because they
look very powerful and their effects seem to be easy to understand.
Also, in most situations using implicit parameters leads to a better
design than implicit conversions.
What more can one say?
- Martin
Martin Odersky
EPFL
Naftoli Gugenheim
On 2015-11-05 5:38 PM, Simon Ochsenreither wrote:
--
I agree we have learned many useful things in the laboratory that is Scala, but sooner or later it would be nice if these things were repackaged in a form that is practical and not only experimental.
How would that look like? Sadly what I see is that most languages just adopt either whatever Scala did or something worse (usually 10 years after Scala shipped it).
Do you have an example where an experimental feature in Scala shipped in a more practical form somewhere else?
I would say that Function Types being implemented in Java 8 is a god example of an experimental feature being shipped in a more practical form somewhere else.
It is easy to poke holes at that statement so I will go on to explain.
My premise is that Scala is still an experimental language,
therefore even Function Types are an experimental feature,
even though they are a core feature of Scala. The landmark success of Scala was to prove that functional and object oriented features could coexist competently. The fact that Java has incorporated it validates that success.
Then again, compared to C#, Java was late to the game, but better late than never.
Also, C# implemented Function Types in a manner very recognizable to Scala, so it is fair to say, two leading languages have benefited from importing Scala features.
Similarly, Java is reducing boilerplate based on Scala. Similarly, the design of the Scala collections classes has greatly influenced the evolution of the Java collections classes, most notably around.
I would agree, that from your perspective "what I see is that most languages just adopt either whatever Scala did..." but this really is features repackaged in a more practical form.
In the long run, I would like to see a new language, that takes the good things in Scala (and some other languages), but intentionally leaves out the problematic features
the same way that Java left out the worst features of C++ and other languages.
Sadly, I am not a brilliant composer like Martin Ordersky and others, but I am a pretty good DJ.
Cheers, Eric
Rex Kerr
I would say that Function Types being implemented in Java 8 is a god example of an experimental feature being shipped in a more practical form somewhere else.
Rex Kerr
Rich Oliver
On Fri, Nov 6, 2015 at 4:13 PM, Rich Oliver <rzi...@gmail.com> wrote:
> On Friday, 6 November 2015 14:02:34 UTC, rkuhn wrote:
The problem with implicit conversions is that they are so powerful.
If you have an implicit conversion from String to HTMLContent in
scope, every single String in your program will suddenly have all the
methods of HTMLContent (except if they have the same name as a method
on string).
trait IndentCon extends IndentCommon
{ override def multiLine: Boolean = false }
trait JustTextCon extends IndentCon { def str: String; override def out(indent: Int) = str }
None of which are likely to cause problems being called out of context. I have a number of traits which allow me to format progammatically produced nested code. I can use the same method implementations to format (indent) code whether I'm producing HTML, Javscript, CSS, C or indeed Scala. Yes I could no doubt use the type class methodology, but it would create unnecessary boilerplate for no gain.
But if any2stringadd is removed and the Scala Compiler stops infering such types as: Any AnyRef, AnyVal, Seq[Any] etc, than I can happily live with a compiler flag for implicit conversions.
Eric Kolotyluk
If you cannot accept the premise that "Scala is still and experimental language" then anything thereafter is pointless. You are not arguing with the points in the discussion, you are only arguing with the premise. It is sufficient to say, "I don't agree with your premise" and say nothing else.
I plan to say nothing else on this sub-thread as don't like to engage trolls.
Cheers, Eric
Rich Oliver
Naftoli Gugenheim
I already said "It is easy to poke holes at that statement."
If you cannot accept the premise that "Scala is still and experimental language" then anything thereafter is pointless. You are not arguing with the points in the discussion, you are only arguing with the premise. It is sufficient to say, "I don't agree with your premise" and say nothing else.
I plan to say nothing else on this sub-thread as don't like to engage trolls.
Cheers, Eric
On 2015-11-06 12:11 PM, Rex Kerr wrote:
Correction: there _should_ be 100-odd different function types. There are _actually_ "only" 43, which means there are a less crazy number of things to remember. (But gives you point 3.)--Rex
On Fri, Nov 6, 2015 at 12:08 PM, Rex Kerr <ich...@gmail.com> wrote:
On Fri, Nov 6, 2015 at 11:45 AM, Eric Kolotyluk <eric.ko...@gmail.com> wrote:
I would say that Function Types being implemented in Java 8 is a god example of an experimental feature being shipped in a more practical form somewhere else.
Seriously?! It feels like a way _less_ practical form to me, weirdly tacked-on and rather clunky instead of just being a seamless part of the language.
First, there are 100-odd _different_ function types. You need to use the correct one, which if you're writing a lambda inline is easy because the compiler fills it in for you, but if you already have one and need a different one, you have to write another lambda. And if you have to write your function signature, you need to remember what's a Predicate and what's a UnaryOperator and so on, not just state what types you need.
Secondly, there is very little inheritance relationship between the different types. But method names are sometimes reused (accept) and sometimes not (applyDouble) with little rhyme or reason apparent.
Thirdly, there are weird holes in what's available. Want an ObjDoubleConsumer? Great! Want a DoubleObjConsumer? No go!
I'm glad Java picked it up--it's better than nothing. But it is a long way from as nice as in Scala.
--Rex
Eric Kolotyluk
Scala that look great, and have valid uses, but invariably thing get
over used or abused to the detriment of others.
My particular pet peeve is with implicit values. This too often gets
manifest when I am trying to learn something by reading a code snippet
someone has posted. When I try to copy and past the example into the
REPL, a Worksheet, or an App, it fails miserably because the snippet
does not contain the essential declarations of the implicit vals.
Implicit vals makes it easier to publish bad code examples.
Basically I am saying, there is a definite lack of seat belts in Scala.
If you want a car that can go 200 km/hr, then seat belts and even air
bags are not sufficient, if you hit a wall you will still die at 200k.
If you want really powerful features in the language, what are you going
to do to protect others from the detrimental effects?
I personally find implicit one of the most confusing aspects of Scala,
and it generally causes me more pain than most other features. We don't
have to agree on why they are in the language, I am only asking for
people to acknowledge the problems and propose solutions.
Cheers, Eric
Rex Kerr
I already said "It is easy to poke holes at that statement."
If you cannot accept the premise that "Scala is still and experimental language" then anything thereafter is pointless.
You are not arguing with the points in the discussion, you are only arguing with the premise. It is sufficient to say, "I don't agree with your premise" and say nothing else.
Russel Winder
>
[…]
> HLists
> are all implemented via implicits - and you’d have to rip all three
> out of
> my cold dead hands
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Eric Kolotyluk
But my point is, when people have that kind of passion about keeping
features in the language, can they even begin to appreciate the harm
such features may cause others?
Cheers, Eric
Simon Ochsenreither
One of the main strength of Scala is that is sometimes tries multiple approaches and uses the knowledge gained to settle on the best approach. That's experience which just isn't available in languages which treat language features as a popularity contest.
Two examples:
- In many languages upper bounds ("extends") are extensively used. But if you look at e. g. Java, most of these bounds are used the restate variance over and over. Scala has a much easier and simpler approach with declaration site variance, which is why you will never see madness like
static <T,K,U> Collector<T,?,Map<K,U>>toMap(Function<? super T,? extends K> keyMapper, Function<? super T,? extends U> valueMapper). Suddenly, upper bounds have a much smaller, and more focused use-case, and we "discovered" context bounds as a better, more flexible solution which we use over upper bounds.
We wouldn't arrived at this huge advancement of how we write code without actually going out and trying it.
Most languages only have upper (and lower) bounds, don't provide their users with a better abstraction, and as "the limits of my language are the limits of my world" developers can not even look further. Extension methods are a well-liked feature in some languages. But if you compare it to implicit classes which subsume extension methods, you will see that the feature thatextension methods provide is pretty much the least interesting aspect of what makes implicit classes useful. Extension methods allow none of the use-cases I would implicit classes for.
Things Scala doesn't have:
- Static types and members
- Complicated property syntax/features
- Special operators/indexers
- Raw types & wildcards
- Extension methods
- Weird generic syntax placement rules (after the class name, before the method return type, after the method when invoking, instance.<Foo>bar() when calling methods on instances, ...)
- Aarray/collection initializers
- Special language operators like .class, instanceOf, casts, sizeof, ...
- Confusing function types (java.util.function in Java, Action/Func in C#)
- Primitive vs. wrapper types
- Non-exchangeable fields/methods (leading to the well-known getter-/setter hell)
- Unsound covariance of arrays
- Special, hard-coded syntax for initializing, accessing and updating arrays
- Horrible interactions between arrays and collections
- Mandatory use-site Generics
- New language features cannot be used on older runtimes
- Static members of classes can be called from subclasses
- Cryptic !, ?, :?, ?? null syntax helpers
- Post- and prefix increment/decrement operators
- Procedure syntax (being removed)
- View bounds (being removed)
- Obscure octal literals
- Confusing double literal syntax
- Hard-coded/built-in numeric widening rules, and string concatenation syntax
Haoyi Li
Simon Ochsenreither
> Static typesScala has no static types???
"static" as in keyword-static. :-)
Simon Schäfer
On 11/06/2015 09:53 PM, Eric Kolotyluk wrote:
> We don't have to agree on why they are in the language, I am only
> asking for people to acknowledge the problems and propose solutions.
upon them. You said "Implicit really should be removed from the
language", "My main problem with reactive streams is that they are
poorly explained", "But hey, that is fine as long as you accept that
exploring and experimenting with new perspectives."
tries to make Scala a better ecosystem and thankless against everyone
who invest their time to help you on the mailing lists with your
questions. These were not your first posts of this kind on this mailing
list, you continue to show this insulting behavior and I have to ask you
to stop. It is not helpful in any way to solve any problems.
I have been involved in improving Scalas tooling infrastructure for some
years now and I can assure you that - in contrast to whatever you seem
to believe - nearly everyone I met acknowledges the problems you are
talking about. I for my part are actively working on resolving them.
Just because you don't see all the work that is done publicly does not
mean it does not exist.
You are free to ask for contributions and discussions but these
subliminal assumptions you are making here are a completely
inappropriate tone on this mailing list. I'm not willing to show any
sympathy when I have to expect to get insults in return.
Simon
Eric Kolotyluk
You may all celebrate my absence from this time forward.
- Eric
