Complexity of Scala versus Kotlin/Ceylon
Eric Pederson
-- Eric
Brian Maso
The "simplicity" argument, though, definitely is a red herring. If you want simplicity, why not just use BASIC? Maybe there's a even a "visual" form of BASIC that would be even better, where you could program by just dragging and dropping items around?
I find well-designed Scala DSLs just so powerful, as are DSLs in other languages. But when you add typesafety? Oh my gosh -- I just don't want to go back to anything unexpressive or weakly typed. To me it just feels childish to do so -- like I'm playing with popguns where I was firing live ordinance before.
Brian Maso
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
br...@blumenfeld-maso.com
Naftoli Gugenheim
Tony Morris
On 22/07/11 13:39, Eric Pederson wrote:
One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler. They don't really back up these claims yet, but the general idea seems to be that they get their simplicity through a intentionally limited feature set. ( It remains to be seen if they will ultimately resist the temptation to get feature parity with Scala.)
My initial reaction to the simplicity argument was that it was FUD - your Scala code can be as simple or complex as you want -- that is part of Scala's nature being a "Scalable Language". However, a good point was made on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentId=40703726#comment-40703726):
"When you're coming to a project of legacy code (that hundreds different people written several years), you [can't] ignore all of scala's overcomplicated features. You'll have to understand all of them."
This is a pretty interesting argument that enterprise management types would find compelling. Being the sole Scala developer in my typically enterprise dev group I often reflect back on my code wondering if I made it too clever/concise/etc for whoever is going to have to maintain it.
What do we do about this? For Scala to go mainstream it has to address the "too complex" issue. One idea is to use profiles or levels to tell the compiler to reject certain language features. Conservative development shops could turn off "dangerous" stuff in regular app code.
Thoughts?
-- Eric
Rex Kerr
One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler. They don't really back up these claims yet, but the general idea seems to be that they get their simplicity through a intentionally limited feature set. (It remains to be seen if they will ultimately resist the temptation to get feature parity with Scala.)
I think they're fooling themselves. With very few exceptions, I think Scala is only as complex as necessary in order to allow programmers to solve difficult problems clearly and compactly.
If their selling point is that they can solve easy problems even more easily than in Scala, and that people wouldn't really dare to tackle a hard problem, so you don't have to worry about that either, that isn't much of a selling point to me.
Take parser combinators, for example. I've written a lot of little parsers in a lot of languages over the years, and they've always been a pain. Then along comes Scala--and poof! 90% of parsing jobs are now simple with a DSL from a library. Brilliant! If you make a language that doesn't comfortably support parser combinators, you've made it "simpler" by making parser construction much harder. Yay?
That said, there is a place for languages that make easy problems easy and hard problems terrifying: it keeps people who have less training from making as bad a mess of things. I don't think Scala needs to be that language.
"When you're coming to a project of legacy code (that hundreds different people written several years), you [can't] ignore all of scala's overcomplicated features. You'll have to understand all of them."
This is only true if either
(a) Your project required all those features or it would be an even more complicated code base, or
(b) Your coders didn't exercise discipline in their coding.
Sadly, (b) is all too common.
I think there is a place--a very large place, occupied by a large number of excellent programmers writing really interesting things--for people who can exercise some discipline in their coding. I don't think it reflects badly on Scala that people can use it to write unmaintainable code. It also doesn't reflect badly on other languages that they try to force you to write maintainable code. They are different, largely opposing use cases. Scala shouldn't adopt gratuitously confusing or dangerous features, but I think it's okay to sit in the "with power comes responsibility" corner.
What do we do about this? For Scala to go mainstream it has to address the "too complex" issue. One idea is to use profiles or levels to tell the compiler to reject certain language features. Conservative development shops could turn off "dangerous" stuff in regular app code.
The best libraries require a lot of "dangerous" stuff, and anyway, the "dangerous" stuff is there to make difficult problems more approachable. So this seems like a bad idea. If you run a conservative development shop, hire talented people or don't use Scala.
--Rex
Jim Balter
> One of the big claims that Kotlin and Ceylon are making is that Scala is too
> complex and that these other languages are simpler. They don't really back
> up these claims yet, but the general idea seems to be that they get their
> simplicity through a intentionally limited feature set. (It remains to be
> seen if they will ultimately resist the temptation to get feature parity
> with Scala.)
> My initial reaction to the simplicity argument was that it was FUD - your
> Scala code can be as simple or complex as you want -- that is part of
> Scala's nature being a "Scalable Language". However, a good point was made
> on the Kotlin wiki
> (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentId=40703726#comment-40703726):
> "When you're coming to a project of legacy code (that hundreds different
> people written several years), you [can't] ignore all of scala's
> overcomplicated features. You'll have to understand all of them."
> This is a pretty interesting argument
Well, it's interesting in that it begs the question by asserting that
Scala has "all" these "overcomplicated" features -- which, aside from
not being supported by a reasoned argument, is somewhat dishonest
considering how many of Scala's features Kotlin has adopted, sometimes
making them more complicated in the process. As for the point it tries
to make, language features are a red herring, because they are a small
fragment of the entire project ecology that must be understood, most
of which is far more obscure and undocumented than the language
features ... *especially* if powerful language features aren't
available.
> that enterprise management types would
> find compelling. Being the sole Scala developer in my typically enterprise
> dev group I often reflect back on my code wondering if I made it too
> clever/concise/etc for whoever is going to have to maintain it.
And what would prevent you form doing that in Kotlin code? This
illustrates the red herring.
> What do we do about this? For Scala to go mainstream it has to address the
> "too complex" issue.
It's largely a political issue, and must be addressed by pushing back
against misinformation and bad arguments, by educating people, by
getting more major adopter and testimonials, and by being somewhat
more "diplomatic" in certain areas.
> One idea is to use profiles or levels to tell the
> compiler to reject certain language features. Conservative development
> shops could turn off "dangerous" stuff in regular app code.
> Thoughts?
This idea has been discussed here at some length. I believe it's
fraught with problems, but you might want to hunt down the discussion
to get the full range of opinion.
-- Jim
Vlad Patryshev
But it's too late.
Scala sets much higher standards. Higher order generics. Implicits. (Almost) union types. :)
I believe Kotlin will stay a niche langauge, like Groovy and the likes.
(disclaimer: I know nothing about The Market)
Thanks,
-Vlad
Bernd Johannes
[Quote from Kotlin]
> "When you're coming to a project of legacy code (that hundreds different
> people written several years), you [can't] ignore all of scala's
> overcomplicated features. You'll have to understand all of them."
...
> What do we do about this? For Scala to go mainstream it has to address
> the "too complex" issue. One idea is to use profiles or levels to tell
> the compiler to reject certain language features. Conservative
> development shops could turn off "dangerous" stuff in regular app code.
I thought about compiler levels of allowed complexity as well (whatever
definition of complexity we want to apply).
But I dismissed it after quite some time. Because I came to the conclusion
that each feature of scala is part of a problem solving toolset. By removing
any feature of this toolset you might force devs into solving problems with
less appropriate tools creating even less obvious or less efficient solutions.
I would recommend
- a scalaish adaption of code metrics to be able to measure some code
properties (for the rough sketch and as warning signal)
- team code reviews to identify proplematic parts
- good documentation and education
- code styleguides, code conventions
Any feature can be misused (in any language). It's about establishing a code
culture and a diagnostic toolset to help create and maintain a sound codebase.
And we all now - a dev who doesn't care will create code problems no matter
what language he/she is using.
Just my 5 cents
Bernd
rklaehn
They make the argument that implicits are too complex, but I did not
see anything about their collections. If they manage to get the scala
collection behavior (all transformations keep the proper type when
possible) without implicits, then they will have a point. But if they
can't do it then obviously the language is lacking in features. Having
used the scala collections I am not willing to go back to a collection
library where you can not do transformations while preserving the
type.
Kotlin claims to have "reified generics". I am curious how they did
that. But there is not even a REPL yet that would allow you to play
with it. So I guess we will have to wait.
I hope that kotlin does not lead to jetbrains slowing the development
of the scala plugin for IDEA.
On Jul 22, 5:39 am, Eric Pederson <eric...@gmail.com> wrote:
> One of the big claims that Kotlin and Ceylon are making is that Scala is too
> complex and that these other languages are simpler. They don't really back
> up these claims yet, but the general idea seems to be that they get their
> simplicity through a intentionally limited feature set. (It remains to be
> seen if they will ultimately resist the temptation to get feature parity
> with Scala.)
>
> My initial reaction to the simplicity argument was that it was FUD - your
> Scala code can be as simple or complex as you want -- that is part of
> Scala's nature being a "Scalable Language". However, a good point was made
> ):
Tony Morris
> They make the argument that implicits are too complex
Naftoli Gugenheim
Rüdiger Klaehn
just that when having an implicit manifest.
But how will they interact with existing classes (e.g. from Java) that
don't have that field? You won't be able to distinguish a
java.util.List<Int> from a java.util.List<String> since the
information is simply not there, right?
There really should be a JVM wide standard about how to encode such
information. Otherwise we will end up with each language having its
own, incompatible way...
Jim Balter
> We had a discussion about this at work.
>
> They make the argument that implicits are too complex, but I did not
> see anything about their collections.
From http://confluence.jetbrains.net/display/Kotlin/FAQ?focusedCommentId=40703732#comment-40703732
Andrey Breslav: "There will be a collection library in Kotlin standard
library. The exact design is not fixed yet."
Xuefeng Wu
Francois
I really believe that this is a company "internal development standard"
problem, and there was the same with Java.
Implicit are no more magic than Java broken memory model, untyped
collection are variant array... or even Java Generics. I could say they
are complexe, because I just never understood them. Is that a reason to
ask Oracle to build compiler profile to forbid them ? No, better I try
to understand them and decide with my team which aspects of them we will
use in our soft, and why.
I don't know Kotlin (or Ceylon), but I'm pretty sure they will have
gotcha, and things tagged as "magic", and they will endure really alike
comments about complexity. Just because they are new, they bring new
ideas, people have to understand and get used to them.
--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com
Xuefeng Wu
Martin Grigorov
Nice explanation! :-)
Sébastien Bocq
Now being able to navigate and refactor large code bases efficiently is crucial in enterprise environments and this is today an area where Scala lacks behind. Of course, adressing compile time speed and IDE support issues caused by (higher-kinded) type inference and implicit resolution takes time because these are innovative features Scala brings on the table.
JetBrain could have collaborated with Scala folks to improve the presentation compiler. It could have invested in the design of new visualisation tools to provide the best commercial IDE support for Scala development. But no. Instead it drops the ball and "creates" a language that supports only the features that would have made Scala just a better Java.
I haven't seen a good explanation of what went wrong here. People drop bluntly a "Scala is too complex", but then it is fair to question their ability to innovate or support innovation.
--
Sébastien
Philippe Lhoste
and complexity...
On 22/07/2011 05:39, Eric Pederson wrote:
> "When you're coming to a project of legacy code (that hundreds different people written
> several years), you [can't] ignore all of scala's overcomplicated features. You'll have to
> understand all of them."
Not necessarily. The Scala compiler, and probably the collection library, are probably
using "overcomplicated features", yet they make (or try hard) a good job at hiding them.
That's a responsibility of a good library: make hard things possible, perhaps doing ugly
(but efficient) or complex things behind the functions we see.
Most of the maintainers of the large codebase will have to deal with this library and the
code using it, which hopefully can remain simple.
Only advanced users will have to dive into the library itself to maintain it.
See Martin's levels of Scala essay.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Daniel Dekany
that has much higher chance for mass adaptation than Scala has (but of
course, much more is needed for that than the language itself, so it
doesn't mean at all that Kotlin will go anywhere). Wouldn't you agree?
It addresses tasks that ordinal Java developers recognize on a direct
and catching way. Just look at Kotlin "properties", or its null-safety
(compared to Option-s). If you are someone who is smart with languages
then maybe you say that Scala is more flexible, more correct, etc.
Certainly, but I doubt that ordinary developers see that, want that,
or maybe even that they need that. Surely it's part psychological on
their side, because you also have to grasp a lot of API-s, frameworks,
tools, etc., and compared to that the difficulty of the language is
maybe not a big deal. OTOH maybe most programmers indeed aren't good
when it comes to languages (consider: PHP is a raging success; users
should be disgusted at seeing the language design and run away, but
they don't even notice anything), so they can just never truly grasp a
deeper language.
--
Best regards,
Daniel Dekany
Paulo Pinto
It seems that every time a new "simpler" language is presented, it
ends up
becoming a complex language over the time, sometimes even more complex
than the languages it was supposed to replace.
Sure Scala, C++, PL/I, Algol among others, are complex languages. But
we
live in a complex world.
Only complex languages can provide the right abstraction mechanisms to
handle
most architecture issues.
I think the desire for simple languages comes from this idea that
everyone should
be able to program. Or even better, simple languages make it easier to
replace
developers, forgetting that the language is only one piece of the
software
development puzzle.
The thing is, I don't expect in many jobs the people to know their job
without proper
education, so why should computing be any different?
--
Paulo
Nation, Carey
√iktor Ҡlang
Computing is different because you never see _Brain Surgery for Dummies_
--
Viktor Klang
Akka Tech Lead
Detering Dirk
post that and fire up discussion here.
Now it is done ;-)
> My initial reaction to the simplicity argument was that it was FUD -
> your Scala code can be as simple or complex as you want --
I think it is not so much about the code itsself but about the
possible features one has to learn.
Well and about the theories behind that features.
But I feel that we cannot avoid that stuff, if we want to
be future-compatible.
> that is part of Scala's nature being a "Scalable Language".
> However, a good point was made on the Kotlin wiki
> (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentI
> d=40703726#comment-40703726):
>
> "When you're coming to a project of legacy code (that hundreds
> different people written several years), you [can't] ignore all of
> scala's overcomplicated features. You'll have to understand all of
> them."
>
> This is a pretty interesting argument that enterprise management types
> would find compelling.
Only if they talk only to themselves and don't consult the dev
department.
I consider that argument a FUD a lot.
And I say that sitting between the chairs, being a non-academic
framework-developer.
I.e.: I have a hard time to grok some of the advanced features
of Scala on one hand, but are confronted with the rants from people
that keep programming Java the 1.4 style, when they look at my code.
The problem arises when management decides to put some developers who
have only coded new MyClass() and if/else so far into the fw department
to "speed things up".
The topics *are* complex, and Java does not help. So one has to learn
the complex (say: bloated) code of the solutions, deeply
understand Generics (user-site), be fit in design patterns
(structural solutions for lacking language features) a.s.o.
The problem is only shifted not solved.
Kotlin may have some interesting features one can think about, and may
perhaps even influence Scala here and there.
But the Complexity argument -in the way they (re-)produce it- I do not buy!
Once they will have a fancy collection library, will have copied the
actors framework, will have reproduced some other features of Scala
or Groovy, they will get the same rant from old-style Java developers
who are facing too many new concepts at once.
> What do we do about this? For Scala to go mainstream it has to
> address the "too complex" issue. One idea is to use profiles or levels
> to tell the compiler to reject certain language features. Conservative
> development shops could turn off "dangerous" stuff in regular app code.
Not the job of the compiler. There are two solutions already available:
a) Coding guides (organisational restriction)
b) Teaching (=> no restriction necessary, gain: better developers )
I promise, if a conservative shop will restrict the features technically
(by profiles), they will chop themselves a leg of or throw them obstacles
in the way to the future.
Another way to address the problem is: Talk about your (positive) experience
with Scala. Messages like that, in private or public, will much better do
against the FUD than any technical activism.
KR
Det
Cay Horstmann
<Dirk.D...@bitmarck.de> wrote:
> Another way to address the problem is: Talk about your (positive) experience
> with Scala. Messages like that, in private or public, will much better do
> against the FUD than any technical activism.
+1.
And another way: Keep publishing Scala code that people want to use.
Ruby didn't become popular because of its intrinsic beauty, but people
use it because it comes with Rails. (Oldtimers may remember that
people bought Apple IIs so they could run Visicalc, the first
spreadsheet.) Get those libraries and frameworks out there, and people
will use Scala because that's what they need to use them.
Cheers,
Cay
Vlad Patryshev
Thanks,
-Vlad
Paulo Pinto
The same people that complain about Scala's complexity, are the same
that
have issues dealing with advanced meta-programming concepts in dynamic
languages.
Those developer shops have to learn that people should learn how to
develop software
properly and apply proper abstraction concepts.
Having to work to an offshoring company I got to learn that many of
these complains come
from people that like offshoring friendly languages. Where you can
replace resources (what
a name for persons) at the whim of project status without having to
look for "experts".
--
Paulo
On 23 Jul., 00:38, Cay Horstmann <cay.horstm...@gmail.com> wrote:
> On Fri, Jul 22, 2011 at 8:39 AM, Detering Dirk
>
coach3pete
Most of the complexity I have found (in any language) is when I wasn't up to speed on the concept--not the language. Understand the concepts that Scala supports and the language flows well. So what's the top 10 list for those that struggle with Scala the language, but not the concepts?
Erik
Chad Salamon
However, I do see a way in which scala can make this significantly better - the ability to create scale the language to create domain specific language capabilities. When done well it can result in code that is vastly more readable and can reduce the learning curve. Think of Behavior Driven Development scripts using specs or ScalaTest as an example of this. I imagine that many business domains could benefit from customized language features.
A counter argument could be made that even though scala can be used in a way that improves readability and minimizes the learning curve, the possiblity is still there to venture out into the wild west and create code that will then be much harder to maintain. I find this true of any programming environment though. They all build up cruft and they all have the potential for unreadable code. I think a certain amount of developer discipline along with a well defined business processes (including code reviews and change control for example) are the only solution for this.
So in short, I think the flexibility of scala is a big selling point. It can result in greater complexity, but it doesn't have to.
Ken McDonald
Ken McDonald
I've met Scala newbies coming from Java, PHP, Groovy, and Ruby. They seem to appreciate Scala simplicity and its aptitude for application to a broader solution set. As announced in an earlier post, I'm putting together a ~6 person Scala team for a multi-year initiative. Skill to design libraries and frameworks takes longer, but a developer new to Scala can start writing acceptable code in a few days. So I'm fine with them learning Scala on-the-fly if necessary.Most of the complexity I have found (in any language) is when I wasn't up to speed on the concept--not the language. Understand the concepts that Scala supports and the language flows well. So what's the top 10 list for those that struggle with Scala the language, but not the concepts?
Erik
On Jul 23, 2011, at 11:53 AM, Paulo Pinto wrote:
> Agreed.
>
> The same people that complain about Scala's complexity, are the same
> that
> have issues dealing with advanced meta-programming concepts in dynamic
> languages.
>
Renghen Renghen
concepts like manifest, package object, delimited continuation, compiler plugin, linear types(capabilities), monads are important and but there is a need for tutorials (pragmatic one).
Some these features/concepts have deep computer science baggage that com with them(eg monads).
These are things that may make scala seem "complicated", but they are not. However, once you learn them, you can program in any language that have them, scala I believe promotes also the learning of concepts, another language that does that on the jvm is clojure.
Kotlin took a more pragmatic root meaning fewer features, more verbose,more java like IDE support and less computer science to absorbed. This may make it a good competitor. Also, it support for reified generics,exension methods, implicit nullable type ala c# has also decrease some of its complexity. But how would it fair on the long run when new features will be added, will it be as awful as java generics.
Kotlin is not proven yet, scala is.
scala new features did not break the language, only binary compatibility.
Also it is a community that really put a language to the test, scala is well poised on many levels to be a language of choice for the jvm/clr. It is just as mentioned earlier by Ken mcDonald some library makes scala unreadable, even disgusting, I personally avoid those.
One flaw that appears a lot in those libary :-
Operator as a method is great, it is like a good spice, but too much of it, makes you sick.
Overusing implicits.
I believe we will see other static languages and functional, and they will target scala as their primary target to say how great their language is and point out flaws in scala.
All in all, I believe it is a community that drives the language, example perl is awful, but for decades may be still now it was a great language for many.
That is my 2 cents on the matter.
Cay Horstmann
> Python is dead simply compared to Scala. If you want to get
> complex, you have to get into Python metaprogramming, which isn't intended
> for general use--while Scala's advanced features are. And even there,
> Python's metaprogramming is still simpler than the complex Scala stuff.
> Ken
Python metaprogramming may well be simple--I haven't looked at it. But
Ruby metaprogramming is not simple at all, and people still think Ruby
is simple.
When I bring this up with Ruby programmers, they tell me cheerfully
that they don't care. They never do any metaprogramming--that's left
to a few wizards. And in Java--how many people write generic methods
with wildcards?
Why would it be any different in Scala? There is no good reason for
Joe Programmer to write their own implicits, or their own
parameterized methods. That's why Martin talks about Scala levels. You
can be happy and productive at Martin's level A2. You use objects and
some functional idioms, exactly like a Python programmer would.
Cheers,
Cay
Ittay Dror
The main difference I think is when a programmer meets the complex
features of the language. With Ruby, a new programmer first encounters
the cool and easy features. Only later, if he wants to, he learns
metaprogramming. In Scala, these are in-your-face from the start (e.g.,
the scala tour). I think that the Scala documentation (not just
scaladoc, but the scala tour, examples etc.) should focus more on how to
program java-like, but with less lines of code, and leave the more
complex features "hidden", so only those already proficient with Scala
will find them.
Ittay
>
> Cheers,
>
> Cay
Detering Dirk
> I'd disagree about the comment that people who have problems with
> Scala's advanced features also have problems with advanced features in
This is IMHO an unfair statement, as in that comparision so far you compare
Scala's advanced(!) features with (standard) Python. But ...
> If you want to get complex, you have to get into Python metaprogramming,
> which isn't intended for general use--while Scala's advanced features are.
AFAIC there is
1.) a mismatch about when the 'advanced' features begin and the
'standard' level ends.
2.) a documented intention about the feature set, which does not
really back up your statement: http://www.scala-lang.org/node/8610
The differentiation between application programmer and
library designer alone is just contradicting your statement that
Scala's advanced features are intended for general use.
> And even there, Python's metaprogramming is still simpler than the
> complex Scala stuff.
of what exactly the problematic things are, this is a worthless debate.
And:
! ( dynamic languages == Python)
Python's metaprogramming may even be as simple in it's technique as
Scala's most often critized advanced features.
But it is as well confusing in an application when one is not trained
to think in meta-levels and it's correct application and is easily
scared by what's going on with the classes and objects at runtime:
Suddenly appearing methods (true reflection), changing scope ('delegate'
and other Builder stuff), or magic behaviour (missing method).
And e.g. delimited continuations exist in Ruby too, and are not
used or even understood by the ordinary programmer, and therefore
not needed by them. Same is true with Scala's delimited continuations.
It is not the language, it's the concept!
The people I would keep Scala's advanced features away from are the
same I would not put into framework development or codegenerator
maintenance with Java or even Python. They would shoot in the foot,
not only of themselves but also of their users.
"Scala is complex" _is_ FUD.
"Scala has very advanced features" is true.
"Scala provides concepts I had never before contact with" may be surely
true for many of us, but what the set of these concepts is depends on
the individual developer.
My 2ct
Det
Andreas Joseph Krogh
+1, especially "code maintenance is much more expensive than code
production". Seems people tend to forget or overlook this one. That's my
nr. 1 argument for using a type-safe language like Scala (and Lift
instead of reflection-based frameworks).
--
Andreas Joseph Krogh <and...@officenet.no>
Senior Software Developer / CTO
Public key: http://home.officenet.no/~andreak/public_key.asc
------------------------+---------------------------------------------+
OfficeNet AS | The most difficult thing in the world is to |
Rosenholmveien 25 | know how to do a thing and to watch |
1414 Troll�sen | somebody else doing it wrong, without |
NORWAY | comment. |
Org.nr: NO 981 479 076 | |
| |
Tlf: +47 24 15 38 90 | |
Fax: +47 24 15 38 91 | |
Mobile: +47 909 56 963 | |
------------------------+---------------------------------------------+
Randall R Schulz
> ...
>
> Praeus, this wasn't necessarily aimed at you, I just get annoyed with
> fads in CS (I've been around long enough to have seen a lot of them),
> and I think DSLs are mostly (not completely) another fad.
To be a fad, they'd have to be far younger than they are. That which is
today referred to as a DSL went by other names in the past and go back
at least 35 years.
> Cheers,
> Ken
Randall Schulz
Kris Nuttycombe
Yup. Why do you think there is that saying about every program of a
sufficient size containing an ad-hoc, poorly specified, buggy
implementation of half of Common Lisp? Giving an old concept a
3-letter acronym doesn't make it a new concept.
Kris
Ken McDonald
Giving an old concept a
3-letter acronym doesn't make it a new concept.Kris
Vlad Patryshev
Thanks,
-Vlad
Daniel Sobral
> 35... as I understand Forth was invented to make it easy to implement dsls,
> and it was something like 7 years earlier (and 42 is also a good round
> number).
Both Forth and Lisp -- the second oldest high level language, older
even than COBOL -- are programmed in by writing successive layers of
DSLs.
--
Daniel C. Sobral
I travel to the future all the time.
Saxo
One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler.
Well, for example, the Kotlin guys are saying that they didn't make the type system that strict as in Scala. Kotlin fixes the holes in Java's type system, but that's it. Anything more than that would only make the compiler become slow and they want Kotlin to compile as fast as Java. I think it's good that some guys at some university sat down to write a compiler that tries to get as much out of type safety as possible. But it might turn out in the end that the type safety in Kotlin/Ceylon/Fantom/whatever, which is better than the one in Java, is the right amount. We will see...
Kotlin does not on implement implicits on purpose. First that was an argument for me to choose Scala. But then I started to think that they have some point there. Even my "Programming Scala" book says to use implicits sparingly. I know I might get some furious answers now that I don't understand implicits. The thinking behind implicits that a language feature can solve design problems is what makes me think about Scala and the Scala people. That is really academical ...
Last and least, Eiffel, Oberon, Smalltalk have disappeared completey. And there was a time where Smalltalk was really big in banking and insurance companies being the only choice for serious OO besides C++. The only competitor to Java will still be .NET. The masses will not follow anyone whose technology is not based on their own CLR or VM including their own GC. Scala is good for learning. But don't bet your future on it.
-- Oliver
Dennis Haupt
i would prefer to say: one more languages that's better than java. good thing.
it gives you one more choice to pick from. i prefer scala though. not using implicits in scala would be like not using macros in clojure.
you need to understand them, but when you do, they are very powerful.
-------- Original-Nachricht --------
> Datum: Thu, 13 Dec 2012 06:27:01 -0800 (PST)
> Von: Saxo <jet...@web.de>
> An: scala...@googlegroups.com
> Betreff: [scala-user] Re: Complexity of Scala versus Kotlin/Ceylon
Saxo
instead of saying: scala vs kotlin
i would prefer to say: one more languages that's better than java. good thing.
I found this blog entry where explicits are explained:
http://www.drmaciver.com/2008/03/an-introduction-to-implicit-arguments/
Somewhere in the middle of the page this here is done:
scala> implicit val hello = "Hello world"
hello: java.lang.String = Hello world
scala> speakImplicitly
Hello world
As what that kind of use of implicit is concerned I agree with the Kotlin guys. But I don't know any Scala enough by far to tell whether that is misuse of implicits and doesn't scratch the real thing or not.
-- Oliver
Saxo
I found this blog entry where explicits are explained:
I wanted to say implicits of course. Sorry, time for the week-end to arrive ...
Rex Kerr
The thinking behind implicits that a language feature can solve design problems is [snip]
The thinking I have about implicits vs. design as a user is _I can solve other people's lousy designs_. When dealing with large projects with all sorts of dependencies and weird APIs, one can become mired in writing huge amounts of glue code and trying to shift mentally between lots of different ways of doing things. You can't realistically "fix your design problem", because your design problem is that you have a huge project re-using code made from many other designs.
If you use implicits to cover over your _own_ faulty design, that's a different matter. That's generally not such a good idea, just like you ought not use macros in C to fix your own bad choice of variable names, and you ought not use operators for every method in C++ or Scala.
Now, I agree that we do not yet know whether in practice people can embrace the incredible value of implicits without shooting themselves in the foot an unacceptable number of times. At this stage, I would attempt giving advice: "use them like this, it's awesome! Don't use it like that, it's going to bite you later on!", not giving up on it entirely.
The only competitor to Java will still be .NET.
Er, why are you comparing a language to a platform? If you are saying .NET not C# (and admitting VB and F# and whatever else), then presumably you recognize that one big barrier to entry is simply deployability. And Scala on JVM is no less deployable than F# on the CLR. There's no reason why there can't be more than one JVM language on the left-hand side of the competition with .NET. Of course, there has to be a compelling use-case, but Clojure and Scala (and perhaps Ceylon and Kotlin and others) will between them cover a lot of compelling cases with a good deal of overlap. Not all alternatives can be sustained, I don't think, but that doesn't mean that they'll all fail, either.
--Rex
Ittay Dror
caller. This serves to remove contextual burden from the caller.
I have two examples. First, consider the signature of the `map` method
on collections:
def map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom
<http://www.scala-lang.org/api/current/scala/collection/generic/CanBuildFrom.html>[Traversable
<http://www.scala-lang.org/api/current/scala/collection/Traversable.html>[A],
B, That]): That
What the designers of the scala collections wanted is for map to return
the most appropriate type of sequence. So if you map over a List[Int],
returning String in the function, then the result should be
List[String]. If you map over a Map[Int, String] and the function
returns (Int, Int), the result should be Map[Int, Int]. If however the
function returns String, the result cannot be Map, and should be
Iterable[String].
IMHO, this is a very powerful feature because: (A) most of the time you
want the same type to return (e.g., if you started with a Set, you want
a Set back, not a List), (B) you get something with is more specific,
hence has more methods you can use.
The way to do all this is with the CanBuildFrom instance that creates
the dependency between the object type, the function return type and the
result type.
In java, you'd need to explicitly ask the user of the library to create
this instance for you. Then they'd need to know the name of the class
implementing the interface for each use case (what is the class
implementing CanBuildFrom[Map[Int, String], String, ???])? Also, the
call site source code will not look pretty.
Another example is manifests. In java there are many cases when using
reflection where type erasure prevents me from knowing the type of
elements the target object uses. Adding an implicit argument of type
Manifest means the compiler automatically generates the right instance
for me. In Java I'd need to ask the developer to explicitly pass this,
which is error prone and doesn't refactor well (I may change the type,
but forget to change the class instance passed in the call)
Rex Kerr
Somewhere in the middle of the page this here is done:
scala> implicit val hello = "Hello world"
hello: java.lang.String = Hello world
scala> speakImplicitly
Hello world
As what that kind of use of implicit is concerned I agree with the Kotlin guys. But I don't know any Scala enough by far to tell whether that is misuse of implicits and doesn't scratch the real thing or not.
Er, criticizing an illustrative example like that makes about as much sense as criticizing "Hello World" for not printing out an error and usage message if you call it with the wrong command-line arguments (i.e. more than none).
Clarity in teaching often has different requirements than those of producing robust, maintainable code. Students should be alerted to this fact (if it's not sufficiently obvious on its own), but that does not mean that simple examples that illustrate a principle should be avoided as "bad practice".
--Rex
Kevin Wright
Saxo
Not all alternatives can be sustained, I don't think, but that doesn't mean that they'll all fail, either.
No, what I wanted to say was that Java will remain the dominant language on the JVM. For Scala or some other JVM language to "replace" Java many people will say "Well, have those guys written a VM with a GC like the Java people from Sun?".
Thanks for your comment about implicits. You can also do a lot of things you shouldn't with meta programming in Smalltalk or Groovy, etc. That doesn't mean it is bad to have meta programming.
Saxo
I have two examples. First, consider the signature of the `map` method
on collections:
def map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom
<http://www.scala-lang.org/api/current/scala/collection/generic/CanBuildFrom.html>[Traversable
<http://www.scala-lang.org/api/current/scala/collection/Traversable.html>[A],
B, That]): That
What the designers of the scala collections wanted is for map to return
the most appropriate type of sequence. So if you map over a List[Int],
returning String in the function, then the result should be
List[String]. If you map over a Map[Int, String] and the function
returns (Int, Int), the result should be Map[Int, Int]. If however the
function returns String, the result cannot be Map, and should be
Iterable[String].
Thanks Ittay, this is a very good example that makes me understand implicits in an instant. Really appreciate that one. Wished my "Programming Scala" book had an example like that. It covers implicits much too shortly.
Jon Steelman
Kevin Wright
Saxo
You also argue from the perspective that "dominant language" is a significant goal. Is it not enough to be mainstream enough that you can sustain an ecosystem, that people are confident your language won't be abandoned overnight, and that there's a thriving jobs market?
What I mean is that you shouldn't bet your future on Scala, because you somewhen might have to do again Java in your career.
Saxo
What the designers of the scala collections wanted is for map to return
the most appropriate type of sequence. So if you map over a List[Int],
returning String in the function, then the result should be
List[String]. If you map over a Map[Int, String] and the function
returns (Int, Int), the result should be Map[Int, Int]. If however the
function returns String, the result cannot be Map, and should be
Iterable[String].
Something else stroke my mind: You add a map method to the List class and one to the Map class and you get the same result. The generic solution through implicits is nice but not required to achieve the same result. My general suspicion is that the Scala language designers are not that much into OO. Nevertheless, I think I understand the point about implicits from what Rex has said in his post.
-- Oliver
Kevin Wright
You also argue from the perspective that "dominant language" is a significant goal. Is it not enough to be mainstream enough that you can sustain an ecosystem, that people are confident your language won't be abandoned overnight, and that there's a thriving jobs market?
What I mean is that you shouldn't bet your future on Scala, because you somewhen might have to do again Java in your career.
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com
Saxo
My experience so far is that Scala devs are amongst the best Java programmers currently on the planet.
Yah, Scala would be a good hide out place from all the Java boilerplate coders that think they are your boss, because they are so good. On the other hand the Scala people that tell you they are fantastic developers, because they develop in Scala, also made me think. But I should not look that much to the left and right, I guess.
I also think it's fair to say that the cat is now out of the bag. People have finally become fed up with Java's stagnation, and there's been an explosion of alternate languages as a result, it's *very* unlikely that we'll ever end up with just Java again.
True, good point.
Right now, my future is doing very well from having invested in Scala. Even if it doesn't "win", that will never have been a wasted investment.
I think I'm still suffering from my trauma from earlier when I was interested in Eiffel and Oberon and Smalltalk and I saw all those languages disappearing. Worse than that, nowadays almost nobody I talk to has heard of Eiffel or Oberon (as what Oberon is concerned I can somewhat understand that). Only few have heard of Smalltalk, because the Ruby and Groovy books mention that some ideas were taken from Smalltalk.
Oliver Ruebenacker
On Thu, Dec 13, 2012 at 11:16 AM, Saxo <jet...@web.de> wrote:
>> Right now, my future is doing very well from having invested in Scala.
>> Even if it doesn't "win", that will never have been a wasted investment.
>
>
> I think I'm still suffering from my trauma from earlier when I was
> interested in Eiffel and Oberon and Smalltalk and I saw all those languages
> disappearing. Worse than that, nowadays almost nobody I talk to has heard of
> Eiffel or Oberon (as what Oberon is concerned I can somewhat understand
> that). Only few have heard of Smalltalk, because the Ruby and Groovy books
> mention that some ideas were taken from Smalltalk.
read an article by Bertrand Meyer about implicit setters and getter
and I thought that was cool. Finally, I'm using a language that has
that, and it is Scala.
Take care
Oliver
--
IT Project Lead at PanGenX (http://www.pangenx.com)
"Stagnation and the search for truth are always opposites." - Nadezhda
Tolokonnikova
Dennis Haupt
-------- Original-Nachricht --------
> Datum: Thu, 13 Dec 2012 08:16:26 -0800 (PST)
> CC: Saxo <jet...@web.de>
> Betreff: Re: [scala-user] Re: Complexity of Scala versus Kotlin/Ceylon
>
>
> > My experience so far is that Scala devs are amongst the best Java
> > programmers currently on the planet.
> >
>
Ittay Dror
1. You will need to add a lot of methods. Each method that currently uses CanBuildFrom would need to be re-implemented. And any method that builds upon them would also need to be reimplemented. Now thing you want to create a new type of collection. How much boilerplate would you need to write? What happens when a new method is introduced in one of the base classes?
2. This doesn't solve the problem of Map[Int, String]#map returning Map[Int,Int] or Iterable[String] depending on the function the caller passes.
-- Oliver
Daniel Sobral
pagoda_5b
On Thursday, December 13, 2012 4:57:33 PM UTC+1, Saxo wrote:
What the designers of the scala collections wanted is for map to return
the most appropriate type of sequence. So if you map over a List[Int],
returning String in the function, then the result should be
List[String]. If you map over a Map[Int, String] and the function
returns (Int, Int), the result should be Map[Int, Int]. If however the
function returns String, the result cannot be Map, and should be
Iterable[String].
Something else stroke my mind: You add a map method to the List class and one to the Map class and you get the same result. The generic solution through implicits is nice but not required to achieve the same result. My general suspicion is that the Scala language designers are not that much into OO.
-- Oliver
Saxo
1. You will need to add a lot of methods. Each method that currently uses CanBuildFrom would need to be re-implemented. And any method that builds upon them would also need to be reimplemented. Now thing you want to create a new type of collection. How much boilerplate would you need to write? What happens when a new method is introduced in one of the base classes?
I can see that this will keep the compiler busy having to do all the work the developer doesn't have to do any more. Well, okay, that is what computers are for :-). I guess an incremental compiler would be beneficial here.
2. This doesn't solve the problem of Map[Int, String]#map returning Map[Int,Int] or Iterable[String] depending on the function the caller passes.
I see, I'm still thinking in Smalltalk sometimes where types aren't an issue.
-- Oliver
Saxo
will take some time to read this. For today it is time to go to bed ;-)
Geir Hedemark
Not all alternatives can be sustained, I don't think, but that doesn't mean that they'll all fail, either.No, what I wanted to say was that Java will remain the dominant language on the JVM. For Scala or some other JVM language to "replace" Java many people will say "Well, have those guys written a VM with a GC like the Java people from Sun?".
Geir Hedemark
You also argue from the perspective that "dominant language" is a significant goal. Is it not enough to be mainstream enough that you can sustain an ecosystem, that people are confident your language won't be abandoned overnight, and that there's a thriving jobs market?What I mean is that you shouldn't bet your future on Scala, because you somewhen might have to do again Java in your career.
Saxo
after writing my first Scala program (which was println("hello world") I just wrote my second one:
class A {
def foo() {
println("foo")
}
}
class B {
def bar() {
println("bar")
}
}
object Test
{
implicit def aToBWrapper(a: A) = {
println("before")
a.foo
println("after")
new B()
}
def main(args: Array[String])
{
val a = new A
a.bar
}
}
When run, it prints:
before
foo
after
bar
Man, that is coooool :-))).
Next thing I want is to make it print this:
before
foo
bar
after
Didn't get that accomplished, yet. When I do, I jump to the ceiling :-)
Eric Kolotyluk
Some Scala features and some Scala libraries are like naked blades.
Many Scala features and many Scala libraries are like plastic safety scissors.
Scala has something for everyone, you just need to know what you want, how much of an expert you are, and how much of an expert your audience is (when you are designing and/or explaining language features and libraries).
Thanks Kevin for the clarity :-)
Cheers, Eric
Oliver Ruebenacker
On Fri, Dec 14, 2012 at 2:20 PM, Eric Kolotyluk
<eric.ko...@gmail.com> wrote:
> OK, I really love this analogy.
>
> Some Scala features and some Scala libraries are like naked blades.
>
> Many Scala features and many Scala libraries are like plastic safety
> scissors.
>
> Scala has something for everyone, you just need to know what you want, how
> much of an expert you are, and how much of an expert your audience is (when
> you are designing and/or explaining language features and libraries).
>
> Thanks Kevin for the clarity :-)
Usually after some one got cut.
Take care
Oliver
Eric Kolotyluk
Cheers, Eric
Eric Kolotyluk
Are you saying Scala is sharp enough to accidentally cut your wrists?
Or deliberately cut your wrists if you try to fathom delimited continuations ;-)
;-)
Oliver Ruebenacker
On Fri, Dec 14, 2012 at 2:32 PM, Eric Kolotyluk
programming languages:
http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html
http://www.thealmightyguru.com/Humor/Docs/ShootYourselfInTheFoot.html
There's none yet about Scala, but the one about Haskell seems quite relevant:
"You spend several hours creating a new copy of the Universe which
is identical to the existing one except your foot has a hole in it.
You then hear that it can be done more elegantly with Dyadic Functile
Hyper-Arrows, but the very act of reading some of the included sample
code causes one of your metatarsals to explode. "
Simon Ochsenreither
Would it be fair to say the infinite set of solutions to a problem written in Scala is larger than the infinite set of solutions written in other languages such as Java. Maybe complexity is not the issue, but the scariness of facing larger infinities?
I'd say it this way:
Everything you can do in Java is easier in Scala, but there are a lot of things possible in Scala which you can't even do in Java in the first place.
Rex Kerr
Define a bunch of constants in an enum? Define arrays (especially with static initializers)? Cope with both generic and non-generic versions of the same interface? Write an ultra-fast loop?
Let's say almost everything.
--Rex
Erik Osheim
> Define a bunch of constants in an enum? Define arrays (especially with
> static initializers)? Cope with both generic and non-generic versions of
> the same interface? Write an ultra-fast loop?
one--I don't think Java has anything Scala lacks on this score (at
least in 2.10, or if you're willing to write "ugly" Scala code). In
fact you can sometimes do better than Java with @tailrec.
The one thing that occasionally saves you an instruction is the ability
to use your arguments as vars, but @inline @tailrec (at least in 2.10)
can get you the same bytecode I think.
Maybe there is something else I'm forgetting? I'm not trolling, just
interested in what example you'd give.
> Let's say *almost everything*.
Agreed.
-- Erik
Eric Kolotyluk
Eric Kolotyluk
LISP first appeared, it was not all that fast. Later, LISP optimizing
compilers became very good at generating amazingly fast code.
I suspect that some day some smart people will come along and do the
same for Scala. Like most software, it is best to make sure things work
correctly first, and them make them fast. Scala's biggest contribution
so far is to help programmers think correctly.
Cheers, Eric
Rex Kerr
int s = 0;
for (int x : a) s += x;
Scala attempt #1:
var i,s = 0
while (i<a.length) {
a(i) += s
i += 1 // Egad, talk about error-prone
}
Scala attempt #2:
// Easier? Really??
@tailrec def sum(a: Array[Int], i: Int, s: Int = 0) = if (i>=a.length) s else sum(a, i+1, s + a(i))
Scala attempt #3:
a.sum // Awesome! Oh, wait, ultra-fast?
Scala attempt #4:
var s = 0
for (x <- a) s += x
// So close, but...ultra-fast, always? *sigh*...
Scala attempt #5:
// Step 1: download spire
// Wait, that's already harder than in Java
So I stand by #4 for now.
--Rex
Rex Kerr
I tend not to worry too much about performance in Scala right now. When LISP first appeared, it was not all that fast. Later, LISP optimizing compilers became very good at generating amazingly fast code.
If you can, say, generate 4 GB of 4D (volume over time) image data per minute, and do so for many minutes, and want to analyze this data (which involves tracking and measuring objects embedded in the volume), LISP is precisely useless until after someone's created those very good optimizing compilers.
Likewise with Scala. (Or you write it the fast way.)
--Rex
Erik Osheim
> So I stand by #4 for now.
spot. I'm hopeful that something like Spire's cfor (also available in
Macrocosm) could get us nicer syntax once 2.10 is out and we all become
macro experts. :)
I guess I had forgotten the "more easily" bit of "anything Java
can do Scala can do more easily".
-- Erik
Simon Ochsenreither
Having to use a while-loop instead of a for-loop is actually an improvement in my opinion. Maybe it is just me, but I always found for-loops hard to read and understand, so I'm happy that they are gone for good in Scala.
Josh Suereth
Two points: that domain is quite specialized
And
If we improved performance on sum, when would you need to rewrite that code?
I understand your point, but 90% of code I write is at a much higher layer than that, and micro optimization can hurt total program throughput.
Rex Kerr
Two points: that domain is quite specialized
However, if you are
* Image processing
* Dealing with video
* Dealing with audio
* Dealing with vector graphics
* Parsing large files (text or binary)
* Doing anything with machine learning
* Calculating anything nontrivial
* Compressing/decompressing
* Writing collections libraries
* (I'm sure there are many more)
you will quickly find yourself limited by your loop speed if your loops are slow and you have to do anything low-level yourself.
And
If we improved performance on sum, when would you need to rewrite that code?
I understand your point, but 90% of code I write is at a much higher layer than that
and micro optimization can hurt total program throughput.
HamsterofDeath
the greatest strengh of scala is how fast and simple you can get things done. the overall speed is "average", compared to everything else out there. it nowhere near the bottom, but also far away from the top.
if you need number crunching, go use cuda or opencl. it's much, much better for that.
Oliver Ruebenacker
class Creature {
val range : Int = 10
val env : Array[Int] = new Array[Int](range)
}
class Ant extends Creature {
override val range = 2
}
val ant = new Ant
What is ant.env.length?
This one is from "Scala for the Impatient" by Cay S. Horstmann, page
92. Good book.
Quote: "When you override a val in a subclass and use the value in a
superclass constructor, the resulting behaviour is unintuitive."
Detering Dirk
Seems nobody has answered to that one, so I'll try:
[Hint: I condensed the code structure a bit]
> after writing my first Scala program (which was println("hello world") I just
> wrote my second one:
>
> class A {
> def foo() { println("foo") }
> }
>
> class B {
> def bar() { println("bar") }
> }
>
> object Test {
> implicit def aToBWrapper(a: A) = {
> println("before")
> a.foo
> println("after")
> new B()
> }
>
> def main(args: Array[String]) {
> val a = new A
> a.bar
> }
> }
>
> When run, it prints:
>
> before
> foo
> after
> bar
>
> Man, that is coooool :-))).
It is? After reading what you try next, I would like to ask:
What do you think your code does?
> Next thing I want is to make it print this:
>
> before
> foo
> bar
> after
First: Why would you want to do that? Or: What do you think you are trying to do?
> def main(args: Array[String]) {
> val a = new A
This created an instance of A and assignes it to a.
> a.bar
Here you are calling the non-existing method bar on a.
The compiler knows that B provides this method, and that a conversion from A to B is present in scope.
So what really happening is:
> aToBWrapper(a).bar
So if _first_ the conversion method is called, which prints "before" and "after" plus in the end returns the newly created B,
and _then_ the bar method is called on this new object, how should your "next thing" happen?
The conversion is already over.
The call to bar is what you explicitly wrote in your main method, so it is the last thing happening.
The implicit call comes _before_ the explicit call to bar, and therefore there comes nothing after that.
So the best solution would be to change your code to:
>......
> object Test {
> implicit def aToBWrapper(a: A) = {
> println("before")
> a.foo
> -----------cut
> new B()
> }
>
> def main(args: Array[String]) {
> val a = new A
> a.bar
> println("after") ------------------paste
> }
> }
... which may not be what you meant.
BTW: The code presents very untypical behavior for the conversion:
1.) The implicit method is named aToBWrapper, but B does not wrap A
2.) the conversion itself calls a method on the object to be converted.
That is very weird design.
May it be that you confuse the _method_ to be the "wrapper"?
Typically it is not.
So what is more in the line is:
class B(a:A) { // B objects are wrapper for A objects
def bar() {
println("before");
a.foo;
println("bar");
println("after")
}
}
implicit def aToBWrapper(a: A) = { println("conversion"); new B(a) } // ONLY converting !
So the call a.bar would result in:
conversion
before
foo
bar
after
What makes me wonder here is, that you claimed :
" My general suspicion is that the Scala language designers are not that much into OO".
So the fact that the wrapper is an object of a wrapper class wrapping an object of another class
should satisfy your strong desire for an object oriented design, and should also in Scala be
your first approach to a solution.
KR
Det
BITMARCK Software GmbH
Firmensitz: Paul-Klinger-Strasse 15, 45127 Essen
Geschaeftsfuehrer: Andreas Strausfeld
Registergericht: Amtsgericht Essen HRB 20680
***********************************************************************
Die Information in dieser E-Mail ist vertraulich und ist ausschliesslich
fuer den/die benannten Adressaten bestimmt. Ein Zugriff auf diese
E-Mail durch andere Personen als den/die benannten Adressaten ist
nicht gestattet. Sollten Sie nicht der benannte Adressat sein, loeschen
Sie bitte diese E-Mail.
Josh Suereth
Gonna have to disagree. Coming from a company where micro optimisation was the norm, you had to go through great lengths to make a design which seemed inefficient, but could drastically improve speed. E.g, the actors pattern would not fly because of constructing a closure for your critical handling code.
My point is that Scala should attempt to make higher order methods as fast as possible, on par with hand rolled loops when they look like hand rolled loops, the number of people having to get their hands dirty in loops should be low.
You're right it's not as fast as it could be now, but it's definitely something we're working on. It's good to see frameworks like Spire push the state of the art.
Saxo
Am Montag, 17. Dezember 2012 12:58:35 UTC+1 schrieb Detering Dirk:
It is? After reading what you try next, I would like to ask:
What do you think your code does?
Rex Kerr
Gonna have to disagree. Coming from a company where micro optimisation was the norm, you had to go through great lengths to make a design which seemed inefficient, but could drastically improve speed. E.g, the actors pattern would not fly because of constructing a closure for your critical handling code.
Maybe we have different definitions of micro-optimization.
With micro-optimization, I typically mean that either you can replace
f(x: X): Y
with
g(x: X): Y
that is identical from the outside but runs faster for the majority of actual use cases (and you measure the speed of f in order to find the bottlenecks and write g), or
trait T { ... }
can be replaced by
trait U { ... }
where T and U provide equivalent functionality as used in the intended code base (with room for sensible levels of extension), but U provides an API that allows better f -> g optimization. What makes these "micro" is that you look at them pretty much in isolation, which is only fair if they are near the leaves of any dependency tree you'd write. The question then is whether you're better off micro-optimizing or taking a more global view of the performance problems--but if you can get micro-optimization for free, you're basically always better off.
I don't mean a set of "micro-optimization patterns" that are followed without thinking. There, I agree: the good can be the enemy of the great, and sometimes you need the great. "I saved 10% runtime by skipping an object creation, but missed a 4x speedup because I can't parallelize easily enough to actually make it happen" is not an example of micro-optimization (as I define it) making your code slower, it's an example of following patterns without thinking making your code slower, and it happens in this case to be particularly ironic because the pattern was motivated by the desire for optimization.
(Another example would be using arrays instead of streams when the computation could be done lazily and on average one would skip 99% of the work--sure, arrays are 10x faster, but that's not the issue here. Mergesort doesn't work in-place on arrays very easily, but that doesn't mean one should use insertion sort because it's easy to implement in-place on an array.)
My point is that Scala should attempt to make higher order methods as fast as possible, on par with hand rolled loops when they look like hand rolled loops, the number of people having to get their hands dirty in loops should be low.
--Rex
Detering Dirk
How can that be, as B and A do not implement the same trait?
And the conversion exactly works _because_ they do not.
So the calling code treats a:A as if it were a B, so in principle it _expects_ a B,
otherwise it would not try to call .bar .
So there is no transparency on usage site.
And for being a proxy, B would have to delegate to A, exactly what I designed
in my last code example. This never comes with zero overhead.
Saxo
So the calling code treats a:A as if it were a B, so in principle it _expects_ a B,
otherwise it would not try to call .bar .
So there is no transparency on usage site.
Yes, there is. For instance you couldn't achieve the same thing with a C++ conversion operator, e.g.
class A {
operator B() const {return B(...);}
};
You would still have to add some kind of conversion code to class A. But in the Scala sample I provided class A and B are both completely untouched. All conversion code is in some unaffiliated third class Test. This is why I wrote:
Man, that is coooool :-))).