- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
new language "Kotlin" from jetbrains
Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:
http://confluence.jetbrains.net/display/Kotlin/Welcome
The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:
http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala. I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile. The scenery up here on mile two, it's nice, you
should come give it a look.
P.S. First mile is long.
Re: new language "Kotlin" from jetbrains
Kotlin, so what?
Let's face it, Scala is provocative, perhaps more-so than most other languages on the JVM. Many folks are going to react to Scala, some of them are going to go off and design a new language as a result. This simply is going to happen. There really is nothing that can be done about that, certainly Kotlin will not be the last language developed in response to Scala. From a competitive stand-point many valid points have been raised on this list and in other forums. We are at a strange cross-roads in the development of Scala: it is garnering enough attention to motivate the designers/stewards (Martin et al./Typesafe) to dial-up the "stability" knob at the same time that the language is sowing the seeds of its own competition. For me, I side with the view that Scala needs to remain agile and responsive to up-start threats at the expense of "stability", however, perhaps the exact right choice to sustain Scala's adoption is to become more "stable". I don't know what the best choice is.
RE: the sub-thread on Scala as "complex" - I think that a number of valid points have been made in this regard. For me the word "complex" doesn't quite capture the issue. I think that Scala is both a rich and deep language. Sufficiently so that it is possible to express solutions to problems in Scala in ways that can appear extremely foreign to programmers familiar with most popular languages (I view this as a strength of Scala, not something to be seriously worried about). That said, it is also a straight-forward exercise to propagate common idioms found in other languages, particularly Java. Further, I think the "complexity" story is not entirely contained in the language itself, it is a combination of the language and its "social ecosystem". People coming to Scala are not simply going to go to scala-lang.org as the be-all and end-all of information on the language and the "best-practices" on how to apply the facilities of it. There are numerous blog-posts, papers, mailing-list posts, and stack-overflow articles covering a wide-range of approaches and techniques for applying Scala to problems in some very non-obvious ways. By "non-obvious" I'm referring to approaches that seemingly do not follow from the prior experience of the average programmer. It's no secret that perhaps the most glaring example of this "alien technology" is the Scalaz library[1], but it certainly isn't limited to it. (As further example take a look at all the blog posts covering various type-level programming tricks.) The knee-jerk reaction to all this is probably going to be describing Scala as "complex" because the seeming "mastery" of Scala requires I learn about things I may never have even heard the names of before taking on Scala. The reality is that this situation is a tribute to Scala richness: you can take Scala pretty damned far in just about any direction you choose.
RE: Claims that Scala FP support is "standard fare" - While this claim is substantially true, the story isn't really finished, especially when it comes to type inference. It's common knowledge to folks on the various Scala mailing lists that the Scala type inferencer is rather sophisticated but still a work in progress. The fact that articles like this one (and the fantastic discussion it produced): http://pchiusano.blogspot.com/2011/05/making-most-of-scalas-extremely-limited.html exist at all adds to the perceived "complexity" of the language: not only do I have to learn Scala's type-system, but I'm likely going to have to become fluent in where the type infrencer seems to break down (perhaps for very good reasons, but honestly look at the discussion following the article from Martin, Daniel, and Paul and realize that almost all of it is gobbledygook to the uninitiated). This includes eventually confronting the need to learn apparent arcana like "type-lambdas". This stuff is only easy after it was hard. Some will bet that the payoff isn't worth the effort.
RE: Macros - yeah, I want them in Scala. More attractive than writing compiler plugins.
RE: Buying JetBrains - yes, it was said in jest with the hopes that folks would get a chuckle out of such an audacious statement.
RE: "Programming is hard" - No it's not, oh wait ... yeah, it is.
That's enough pablum for now. Need sleep.
--
Jim Powers
[1] It will be interesting to see if Scalaz can be implemented as succinctly (or at all) using Kotlin as it can be in Scala. If it can perhaps there are lessons to be learned for Scala.
Re: new language "Kotlin" from jetbrains
From a quick look at the site, it looks like the language specification isn't set in
stone, yet... Like Ceylon, there is no (publicly available) compiler yet.
I believe they missed an opportunity to distinguish more from Scala/Java/other
concurrents, to support metaprogramming, via type-safe and scope-safe macros.
I found the idea made elegantly in Nemerle (I don't know enough Lisp to comment on it, but
I believe it is the same idea).
I like the idea because it allows easy extension of syntax (even if Scala do a decent job
with partial functions and its nice syntax) and code generation.
Somehow, if such macro facility was in Scala, it would void the need for code generated by
external tools (as I suppose Tuple, among others, it done) and for compiler plugins
(which need extra installation just to compile some source, if I understood correctly).
Such macro system would also allow to have type-safe string interpolation, for example: a
literal string with placeholders can be parsed at compile time and checked against
parameters, and efficiently transformed to string-concatenation code.
Perhaps I am not aware of some drawbacks of such macro system, as I don't see the idea
adopted (from my limited knowledge) in new JVM languages (Gosu, Ceylon, Mirah, Kotlin,
etc.). Well, I suppose Clojure has it, at least...
Re: Re: new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 5:27 AM, Philippe Lhoste wrote:
> From a quick look at the site, it looks like the language specification
> isn't set in stone, yet... Like Ceylon, there is no (publicly available)
> compiler yet.
>
> I believe they missed an opportunity to distinguish more from
> Scala/Java/other concurrents, to support metaprogramming, via type-safe and
> scope-safe macros.
> I found the idea made elegantly in Nemerle (I don't know enough Lisp to
> comment on it, but I believe it is the same idea).
a) A problem with making "less complex" a selling point for your
language is that it makes it difficult to improve your design by
incorporating good ideas, no matter how good they are.
b) When your priority is integration of your language with an IDE,
macros are probably the last feature you would be willing to consider.
c) Borrowing Nemerle's macros wouldn't distinguish it from "other
concurrents" since Nemerle is one.
I actually think that this proliferation of Scala look-almost-alikes
is a good thing, largely because it increases the visibility of Scala
and highlights its excellence ... imitation is the sincerest form of
flattery, as they say. And I think these languages that miss the point
of Scala's "complex" features will suffer for it and will further
illustrate the point. And it may also work the other way around ...
these languages may serve as proving grounds for ideas that may later
make their way into Scala.
Re: new language "Kotlin" from jetbrains
On 22/07/2011 23:17, Jim Balter wrote:
> a) A problem with making "less complex" a selling point for your
> language is that it makes it difficult to improve your design by
> incorporating good ideas, no matter how good they are.
Indeed, and since "complex" features are not built/integrated in the
design from the start, it is even complexer! See Java generics...
> b) When your priority is integration of your language with an IDE,
> macros are probably the last feature you would be willing to consider.
Not sure about this one, but I won't argue, as I have experience in IDE
design...
> c) Borrowing Nemerle's macros wouldn't distinguish it from "other
> concurrents" since Nemerle is one.
It isn't a direct concurrent, at least, as it is a .NET language, not a
JVM one.
Re: Re: new language "Kotlin" from jetbrains
That would be fantastic. Maybe Scala 3?
It's not that hard to write code generators in Scala, but a depressing fraction of my code is now the output of code generators.
--Rex
Re: new language "Kotlin" from jetbrains
I also wonder whether there are plans to introduce metaprogramming
facilities in Scala. Would be lovely to receive comments from Scala
dev team regarding that.
However, we must keep in mind that Scala already provides experimental
support for a certain flavor of metaprogramming. To some extent,
metaprogramming can be implemented by language virtualization via
lightweight modular staging (http://infoscience.epfl.ch/record/150347/
files/gpce63-rompf.pdf). Personally to me, this approach seems simpler
to implement and use than traditional macros.
Language virtualization is an active area of research (check out
https://github.com/stanford-ppl/delite for more information). Though,
at the moment, there are certain language constructs that cannot be
virtualized. Currently unsupported constructs include all definition
constructs (though, Delite team plans to virtualize datastructures
somehow), pattern matching (Adriaan hinted that this is also a work in
progress) and, maybe, some other stuff that I forgot (e.g. there are
certain problem with casts).
Re: Re: new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 8:26 AM, Rex Kerr wrote:
> On Fri, Jul 22, 2011 at 8:27 AM, Philippe Lhoste wrote:
>>
>> I believe they missed an opportunity to distinguish more from
>> Scala/Java/other concurrents, to support metaprogramming, via type-safe and
>> scope-safe macros.
>> I found the idea made elegantly in Nemerle (I don't know enough Lisp to
>> comment on it, but I believe it is the same idea).
>
> That would be fantastic. Maybe Scala 3?
>
> It's not that hard to write code generators in Scala, but a depressing
> fraction of my code is now the output of code generators.
+100 - being able to abstract over names and arity would cut
essentially all the remaining boilerplate from my code.
Re: Re: new language "Kotlin" from jetbrains
http://infoscience.epfl.ch/record/150347/files/gpce63-rompf.pdf
2011/7/22 Kris Nuttycombe <kris [dot] nuttycombe [at] gmail [dot] com>
Re: Re: new language "Kotlin" from jetbrains
> +100 - being able to abstract over names and arity would cut
> essentially all the remaining boilerplate from my code.
Something that I find very interesting and which I don't fully understand yet is: when are macros necessary in a dynamically typed language? It seems like the use case you mention above is a case of "not necessary", at least when you are in a dynamically typed language. A case when a macro facility seems to be necessary is when you actually want to examine and use the syntactical nature of your argument expressions, like transforming 'addVC (v.right <= w.left)' into 'addVisualConstraint (v, "right", w, "left", "LessThanOrEqual")'.
- Steven
Re: Re: new language "Kotlin" from jetbrains
The need doesn't go away just because it's a dynamically typed language, but it's usually referred to as "monkey patching". Rightfully so, in my opinion.
I'm of two minds about statically typed macros. They can be tremendously useful and they can lead to very elegant DSL's and constructs, but the potential to come across code that you're having a hard time parsing even though you know the language it's written in is very high.
Groovy has made some interesting steps in this direction by offering hooks that seem to be halfway between compiler plug-ins and full blown macros.
-- Cédric
Re: Re: new language "Kotlin" from jetbrains
On 22.07.2011, at 17:07, Cédric Beust ♔ wrote:
Monkey Patching doesn't seem to be the same as coding macros. Rather, monkey patching seems to be what you do in certain situations if you DON'T have a good macro system.
Thx for the pointer, I am going to check this out.
- Steven
Re: Re: new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 4:48 PM, Kris Nuttycombe <kris [dot] nuttycombe [at] gmail [dot] com> wrote:
+101
--
Viktor Klang
Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts
Twitter: @viktorklang
Re: Re: new language "Kotlin" from jetbrains
+<positive infinity>
-- Jim Powers
Re: new language "Kotlin" from jetbrains
By the way, to those wanting String templates, there has been a plugin
providing that for Scala for a while now. I'm not sure if it works
with 2.9.0, but, anyway,
http://jrudolph.github.com/scala-enhanced-strings/Overview.scala.html
On Tue, Jul 19, 2011 at 20:29, Paul Phillips wrote:
> Maybe I'm the last guy to hear about things (it happens enough) but
> there's this language here which looks like a more credible effort to be
> a better/simpler scala than most:
>
> http://confluence.jetbrains.net/display/Kotlin/Welcome
>
> The "What Kotlin has that Scala has not" list does read like a list of
> things I would not mind having:
>
> http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
>
> It makes me sad to see another whole implementation's worth of effort
> being poured into something new -- come on guys, you won't be enough
> better than scala. I know everyone wants their own baby, but just
> imagine what we might accomplish if we didn't all keep re-running the
> same opening mile. The scenery up here on mile two, it's nice, you
> should come give it a look.
>
> P.S. First mile is long.
>
Re: new language "Kotlin" from jetbrains
Don't worry about "Kotlin", embrace "Babel-17" (http://www.babel-17.com) instead :-) It also has rudimentary tool support, and its newest incarnation v0.3.1 even has support for lenses!
By the way, a small tip how to get a MASSIVE boost for Scala: provide a Scala to Javascript compiler.
- Steven Obua
On 20.07.2011, at 01:29, Paul Phillips wrote:
> Maybe I'm the last guy to hear about things (it happens enough) but
> there's this language here which looks like a more credible effort to be
> a better/simpler scala than most:
>
> http://confluence.jetbrains.net/display/Kotlin/Welcome
>
> The "What Kotlin has that Scala has not" list does read like a list of
> things I would not mind having:
>
> http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
>
> It makes me sad to see another whole implementation's worth of effort
> being poured into something new -- come on guys, you won't be enough
> better than scala. I know everyone wants their own baby, but just
> imagine what we might accomplish if we didn't all keep re-running the
> same opening mile. The scenery up here on mile two, it's nice, you
> should come give it a look.
>
> P.S. First mile is long.
Re: new language "Kotlin" from jetbrains
On 21/07/2011 00:31, Steven Obua wrote:
> [...]
> By the way, a small tip how to get a MASSIVE boost for Scala: provide a Scala to Javascript compiler.
My little finer says that that wish may become reality in a not so far
future...
Re: new language "Kotlin" from jetbrains
On 21.07.2011, at 10:21, Francois wrote:
Now that you say that I looked up this one the net:http://www.j2js.com/scala-demo/index.html
Is there already any (in)official action going on to make Javascript a standard target for Scala? That would be HUGE.
- Steven
Re: new language "Kotlin" from jetbrains
On Thu, Jul 21, 2011 at 1:51 PM, Francois <fanf42 [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
Just to be clear : I'm in no way involved with Scala compiler development, nor any kind of Scala to javascript compiler. It's just that I infered ideas from things read on the big internet (and of course, every thing published on Internet is REAL), that's it.
Re: new language "Kotlin" from jetbrains
So yes, there seem to be plans for a Scala to Javascript compiler. :-) But one year is a long time.
- Steven
On 21.07.2011, at 10:33, Francois wrote:
Re: new language "Kotlin" from jetbrains
http://dl.dropbox.com/u/12870350/scalagwt/Showcase.html#CwMenuBar
On Thu, Jul 21, 2011 at 15:23, Steven Obua <steven [dot] obua [at] googlemail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.
The key ones to my eye are
(1) Extension functions. Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.
(2) NotNull support
(3) Delegation/proxying (without a plugin).
I'm pretty sure I wouldn't miss everything else, although inline string interpretation would be nice without having to go through XML.
Some of the design choices seem downright perplexing if one wants something simpler than Scala. Having to remember 30 rules to know which method corresponds to which operator? Extension functions extending anything anywhere? Pattern matching syntax even more complicated than Scala's?
--Rex
Re: new language "Kotlin" from jetbrains
Well, it's only my personnal interpretation, but I think that in the first mile, Paul also take into account the "adoption" factor.
Scala is now known and used in application deployed for several years, it has started to be an option for new projects... How much time and effort before Kotlin (or any other new Scala-alike language) reaching that state ?
I, too, share Paul (or Tony and others) sadness on that. On the other hand, being on a "every cloud has a silver line" mood, I will say that all these languages (and COT ;) are a good matrix for Scala 3.0.
Re: new language "Kotlin" from jetbrains
Considering that Scala's mindshare is still minuscule (even smaller than Groovy), I think the space between Java and a more modern language is still largely up for grabs. Also, Kotlin is going in one direction than no other language (Groovy, Fantom, Gosu, Ceylon, Scala) has covered adequately yet: top notch IDE support.
This could mean nothing or it could be the difference between obscurity and mainstream.
We'll see.
-- Cédric
Re: new language "Kotlin" from jetbrains
Top notch *IntelliJ* support, at least for some time. OK, every body but me seems to think it's the best IDE around, but it's not the only one, and not the one with the biggest user base (ok, perhaps it's a leadership minded user base, but again that put some delay on the broad adoption).
So, as you said, we'll see. We are living interesting time.
Re: new language "Kotlin" from jetbrains
-- Cédric
On Wed, Jul 20, 2011 at 10:44 AM, Francois <fanf42 [at] gmail [dot] com> wrote:
Good point. I'm an Eclipse user myself, so Kotlin's IDEA support does little for me. However, the fact that the language is being designed from the ground up in lockstep with the IDE is, hopefully, a guarantee that it will be extremely toolable (e.g. offering a lot of hooks into the compiler's internals). I'm hopeful that Eclipse support will happen quickly (maybe it's already even underway).
-- Cédric
Re: new language "Kotlin" from jetbrains
Yet I realized that I no longer refactor as much as I used to in my early programming days. I take more time to think about the high-level outline of the program and basically just copy it from my mind into IDE, enriching it with code details along the way. I used to just start coding right after I got *some* idea about it, which would inevitably require multiple refactoring passes later on. As to the IntelliJ's flattened menu structure and numerous keyboard shortcuts, some people find it appealing, but I personally do not. I guess it is a matter of taste.
So, at a risk of sounding snobbish, I would assert that IntelliJ is mostly a premium IDE for beginner programmers. Yes, some people start with it and stay with it long past their "coming of age" phase, yet I would argue that NetBeans was more productive for more experienced guys like me, and Eclipse is just an overall best-rounded platform that accommodates the widest range of programming styles. Just my personal opinion, based on first-hand experience.
Now, we need to realize that Eclipse started as a Java rewrite of IBM's venerable VisualAge for C++, the most advanced IDE at the time, significant chunks of which were written in Prolog, which helped codify the insane complexity of C++ and thus enabled the killer VisualAge feature - semantic referential search.
IBM did not stop at donating his crown jewel to the Java ecosystem, it kept supporting it for years on end with the effort on order of fifty man-years per year. The apparent target was of course Microsoft's Visual Studio, yet Eclipse also effectively killed off multiple commercial Java IDE hopefuls, and presently is squeezing IntelliJ really hard.
I personally do not believe that Kotlin is primarily a reaction to Scala's complexity. I think it is an answer to the huge competitive threat that the Scala/Eclipse/Typesafe presents to Java/IntelliJ/JetBrains. Martin and Typesafe team have to be mentally and operationally prepared for former friends becoming competitors and even enemies now that the lines in the Scala game of domination are drawn much more clearly.
Once the situation is looked at from that angle, the executive opinions regarding the best course of action are bound to shift. For instance, instead of keeping polishing Scala the language, perhaps more attention is going to be paid to expanding Scala the platform - for instance, taking the LLVM one-man project and boosting it into an effort capable to quickly deliver "native" iOS Scala.
Or maybe to drastically accelerating the work on Scala translation onto parallel hardware code. The opportunity is there as the remainder of the enormous fiscal stimulus money is still slushing in VC coffers. Yet it could be gone in a blink of an eye with all those new sovereign defaults springing to public attention every week. The stimulus money given to the financiers may in effect be "called back" to save the governments. While not too late, please boost the Typesafe's valuation, quickly and shamelessly, and raise enough money (~$50,000,000) to expand the Scala platform beyond the threshold of self-sustainabilty.
2011/7/20 Cédric Beust ♔ <cedric [at] beust [dot] com>
Re: new language "Kotlin" from jetbrains
Hey all,
> So, at a risk of sounding snobbish, I would assert that IntelliJ is mostly a
> premium IDE for beginner programmers. Yes, some people start with it and
> stay with it long past their "coming of age" phase, yet I would argue that
> NetBeans was more productive for more experienced guys like me, and Eclipse
> is just an overall best-rounded platform that accommodates the widest range
> of programming styles. Just my personal opinion, based on first-hand
> experience.
>
That does, unfortunately, sound snobbish. I use IntelliJ as my primary
IDE, having previously used both Netbeans and Eclipse. I think you are
trying to make a general rule out of your personal opinion. Netbeans
may work for your style, IntelliJ works for others. We are not
beginners, we merely have a different programming style.
> IBM did not stop at donating his crown jewel to the Java ecosystem, it kept
> supporting it for years on end with the effort on order of fifty man-years
> per year. The apparent target was of course Microsoft's Visual Studio, yet
> Eclipse also effectively killed off multiple commercial Java IDE hopefuls,
> and presently is squeezing IntelliJ really hard.
>
Actually, judging by the fact that they have just released a bunch of
new IDEs for dynamic languages, they have a whole range of .Net
products, and have just brought out a competitor to XCode for
objective-c programming on the Mac, I would say they are doing pretty
well...
> I personally do not believe that Kotlin is primarily a reaction to Scala's
> complexity. I think it is an answer to the huge competitive threat that the
> Scala/Eclipse/Typesafe presents to Java/IntelliJ/JetBrains. Martin and
> Typesafe team have to be mentally and operationally prepared for former
> friends becoming competitors and even enemies now that the lines in the
> Scala game of domination are drawn much more clearly.
>
Really? I just think they are diversifying.
Re: Re: new language "Kotlin" from jetbrains
Apologies for not being clear enough. I thought I said exactly the opposite - that this is my personal opinion. I said it to counteract the notion that somehow IntelliJ is "the best" or "most advanced" IDE period. I think I also stated that it is not just the beginners that use it, yet it is especially attractive to those beginners who like to refactor a lot. I would extend that attractiveness to those "bright, devoted professionals" who have to refactor lots of code written by relative beginners. Maybe you are one of those professionals ;-) I think we are in agreement here.
Maybe so. I don't think it is a good business strategy though. Here we disagree. For a business, it is extremely important to focus, that is, to decide what not to do. Decision to have a finger in every pie is fraught with many fingers being cut off by other players, each focusing on having the whole specific pie.
Re: Re: new language "Kotlin" from jetbrains
I think it's a good move by JetBrains, for a couple of reasons:
- No matter how good you are (and IDEA is a great IDE), it's hard to compete with free products, especially when these free products are as good as you are. It's a testament to the quality of the JetBrains team that they manage to stay in business despite this fierce competition. For this reason, the only way you can keep selling licenses is with differentiation. Creating your own language so you can build a specific IDE on top of it is definitely a reasonable response to this problem.
- Should Kotlin be successful, this could be another opportunity for JetBrains to create a new suite of tools on top of the language.
So the decision to create a new language, no matter how techy it sounds, is actually a sound business decision for an IDE company. I wish them the best of luck, even though I'm an Eclipse person myself.-- Cédric
RE: Re: new language "Kotlin" from jetbrains
Chris
From: cedric [at] beust [dot] com
Date: Thu, 21 Jul 2011 11:08:36 -0700
Subject: Re: [scala-debate] Re: new language "Kotlin" from jetbrains
To: hello [dot] sergei [at] gmail [dot] com
CC: andrew [dot] webb [at] gmail [dot] com; scala-debate [at] googlegroups [dot] com
On Thu, Jul 21, 2011 at 10:43 AM, Sergei <hello [dot] sergei [at] gmail [dot] com> wrote:
I think it's a good move by JetBrains, for a couple of reasons:
- No matter how good you are (and IDEA is a great IDE), it's hard to compete with free products, especially when these free products are as good as you are. It's a testament to the quality of the JetBrains team that they manage to stay in business despite this fierce competition. For this reason, the only way you can keep selling licenses is with differentiation. Creating your own language so you can build a specific IDE on top of it is definitely a reasonable response to this problem.
- Should Kotlin be successful, this could be another opportunity for JetBrains to create a new suite of tools on top of the language.
So the decision to create a new language, no matter how techy it sounds, is actually a sound business decision for an IDE company. I wish them the best of luck, even though I'm an Eclipse person myself.-- Cédric
Re: Re: new language "Kotlin" from jetbrains
Strangely I read this as:
Think TypeSafe can get access to the financial resources necessary to make this happen? Then the efforts/resources being put into Kotlin can simply be moved over to Scala. And we get Intelli/S Notion really really fast ;-).
--
Jim Powers
Re: Re: new language "Kotlin" from jetbrains
On Thu, Jul 21, 2011 at 2:33 PM, Jim Powers <jim [at] casapowers [dot] com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
Re: Re: new language "Kotlin" from jetbrains
Also Kotlin language seems to be pretty well designed. And somebody had finally courage to remove stuff which was kind of obsolete and often misused (octal strings, bitwise operators, 'l' letter used to denote Long..)
And I am happy that Scala will finally get some serious competition.
Jan
On Fri, Jul 22, 2011 at 12:17 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:
Re: Re: new language "Kotlin" from jetbrains
As far as I know the goal for Typesafe for the next 24 months is to increase Scala adoption as much as possible and this can be (and should be) achieved by different means.
Work on Kotlin has started long before formation of Typesafe...
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com
On Thu, Jul 21, 2011 at 4:53 PM, Jan Kotek <kjan80 [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
On 22/07/2011 01:53, Jan Kotek wrote:
> Also Kotlin language seems to be pretty well designed. And somebody had finally courage to
> remove stuff which was kind of obsolete and often misused (octal strings, bitwise
> operators, 'l' letter used to denote Long..)
Octal strings? You mean octal numeric literal, perhaps? I fully agree they are a thing of
the past, I wonder why they survived from C to other C-like languages like Java.
I don't see bitwise operators as obsolete, though. I use them almost daily...
Re: Re: new language "Kotlin" from jetbrains
bitwise operators are obsolete? I hope you are not seriouse on this.
-Stefan
2011/7/22 Jan Kotek :
> I think 10M injection into Typesafe may be actually trigger for Kotlin. It
> showed that 'next gen java' market is serious and can attract money.
> Also Kotlin language seems to be pretty well designed. And somebody had
> finally courage to remove stuff which was kind of obsolete and often misused
> (octal strings, bitwise operators, 'l' letter used to denote Long..)
> And I am happy that Scala will finally get some serious competition.
> Jan
>
> On Fri, Jul 22, 2011 at 12:17 AM, Meredith Gregory
> wrote:
>>
>> +1
>>
>> On Thu, Jul 21, 2011 at 2:33 PM, Jim Powers wrote:
>>>
>>> 2011/7/21 Cédric Beust ♔
>>>>
>>>> I think it's a good move by JetBrains, for a couple of reasons:
>>>
>>> Strangely I read this as:
>>>
>>> I think it's a good move to buy JetBrains, for a couple of reasons:
>>>
>>> Think TypeSafe can get access to the financial resources necessary to
>>> make this happen? Then the efforts/resources being put into Kotlin can
>>> simply be moved over to Scala. And we get Intelli/S Notion really really
>>> fast ;-).
>>>
>>> --
>>> Jim Powers
>>
>>
>>
>> --
>> L.G. Meredith
>> Managing Partner
>> Biosimilarity LLC
>> 7329 39th Ave SW
>> Seattle, WA 98136
>>
>> +1 206.650.3740
>>
>> http://biosimilarity.blogspot.com
>
>
Re: Re: new language "Kotlin" from jetbrains
http://confluence.jetbrains.net/display/Kotlin/Basic+types
"As of bitwise operations, there're no special characters for them,
but just named functions that can be called in infix form"
On Fri, Jul 22, 2011 at 12:45 AM, Stefan Langer
wrote:
> bitwise operators are obsolete? I hope you are not seriouse on this.
>
> -Stefan
>
> 2011/7/22 Jan Kotek :
>> I think 10M injection into Typesafe may be actually trigger for Kotlin. It
>> showed that 'next gen java' market is serious and can attract money.
>> Also Kotlin language seems to be pretty well designed. And somebody had
>> finally courage to remove stuff which was kind of obsolete and often misused
>> (octal strings, bitwise operators, 'l' letter used to denote Long..)
>> And I am happy that Scala will finally get some serious competition.
>> Jan
>>
>> On Fri, Jul 22, 2011 at 12:17 AM, Meredith Gregory
>> wrote:
>>>
>>> +1
>>>
>>> On Thu, Jul 21, 2011 at 2:33 PM, Jim Powers wrote:
>>>>
>>>> 2011/7/21 Cédric Beust ♔
>>>>>
>>>>> I think it's a good move by JetBrains, for a couple of reasons:
>>>>
>>>> Strangely I read this as:
>>>>
>>>> I think it's a good move to buy JetBrains, for a couple of reasons:
>>>>
>>>> Think TypeSafe can get access to the financial resources necessary to
>>>> make this happen? Then the efforts/resources being put into Kotlin can
>>>> simply be moved over to Scala. And we get Intelli/S Notion really really
>>>> fast ;-).
>>>>
>>>> --
>>>> Jim Powers
>>>
>>>
>>>
>>> --
>>> L.G. Meredith
>>> Managing Partner
>>> Biosimilarity LLC
>>> 7329 39th Ave SW
>>> Seattle, WA 98136
>>>
>>> +1 206.650.3740
>>>
>>> http://biosimilarity.blogspot.com
>>
>>
>
Re: Re: new language "Kotlin" from jetbrains
FYI, it's $3M.
-- Cédric
Re: Re: new language "Kotlin" from jetbrains
Not going to happen :)
I've talked extensively to Scala plugin team from JetBrains at Scalathon and they are pretty close to have all major issues resolved. Once their type aware highlighting is ironed out (for which GridGain is being used as a good test bed) - we'll have pretty much all we need (and can ask for in IDEA) for Scala...
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com
On Thu, Jul 21, 2011 at 2:33 PM, Jim Powers <jim [at] casapowers [dot] com> wrote:
Re: Re: new language "Kotlin" from jetbrains
Hello,
I think I have read most of the thread skimming some longer posts and
I must say we have diverted from the path of seeing what Kotlin does
good and how we can encoporate this into Scala to what is better to
which IDE do we use and what is better.
In the long run only time will tell weather Kotlin will succeed or not
but I wouldn't bet my job on it. If it is the next dominant language I
will be sure to adapt and learn as it shouldn't be a problem once you
have understood the fundamental principles. Experience and some
statistics show that the actual language used doesn't have so much to
do with successful projects in the enterprise sector. It's more about
people and the social aspects but that is a different story.
Then again I'm not a tooling freak I like working with Eclipse but I
also use Emacs, Vim etc...
I like Scala and that is the reason why I use it. I like Ruby but
somehow I'm more into Scala lately.
I code Java because that is the way I make a living.
In the long run I hope that the language I like will be a language I
can make a living off. If not, so be it.
Summarized I do not care whether Kotlin is more or less complex then
Scala and I think this is an open ended debate that doesn't bare any
fruits. On the contrary the discussion how we can incorporate what is
good in Kotlin into Scala in a Scalaishway is a discussion which will
profit everybody.
Stop being afraid and adapt or you will be left behind cause the next
big thing is lurking around the corner.
-
Stefan
P.S.: Kotlin is a very weird name for me as a German. Reminds me
somehow of Quell Kot
Re: new language "Kotlin" from jetbrains
On 21/07/2011 12:32, Stefan Langer wrote:
> P.S.: Kotlin is a very weird name for me as a German. Reminds me
> somehow of Quell Kot
I guess it comes from http://en.wikipedia.org/wiki/Kotlin_Island
Which might be related to the East European origin of JetBrains...
Re: Re: new language "Kotlin" from jetbrains
> In the long run I hope that the language I like will be a language I
> can make a living off. If not, so be it.
>
That's a very pragmatic and probably also very smart view of things. But none I could ever subscribe to :-)
- Steven
Re: Re: new language "Kotlin" from jetbrains
2011/7/21 Steven Obua :
>> In the long run I hope that the language I like will be a language I
>> can make a living off. If not, so be it.
>>
>
> That's a very pragmatic and probably also very smart view of things. But none I could ever subscribe to :-)
It's not like I want to but having family makes you pragmatic cause
the little ones want to eat and play and go have fun.
: )
Re: Re: new language "Kotlin" from jetbrains
On 21.07.2011, at 12:40, Stefan Langer wrote:
> 2011/7/21 Steven Obua :
>>> In the long run I hope that the language I like will be a language I
>>> can make a living off. If not, so be it.
>>>
>>
>> That's a very pragmatic and probably also very smart view of things. But none I could ever subscribe to :-)
> It's not like I want to but having family makes you pragmatic cause
> the little ones want to eat and play and go have fun.
> : )
I totally understand that, it depends on your personal priorities and life choices so far. I think I can rephrase your statement so that it becomes true for me:
In the long run I hope that choosing the work I do in the way I do will make enough money for a family and little ones. If not, so be it.
- Steven
Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.
Cheers
-- Martin
Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 12:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
Really? C# offers extension methods that don't apply to interfaces either. I find I need extension methods much more often than I need to add an extension to an existing interface.
Not long ago, Brian Goetz posted a proposal to implement this functionality in Java (draft here, PDF) which was very clever but went largely unnoticed, because the need just doesn't appear to be there, in my experience.
-- Cédric
Re: new language "Kotlin" from jetbrains
2011/7/20 Cédric Beust ♔ <cedric [at] beust [dot] com>
Hi Cedric,
Yes, that might be. But in more evolved designs you do need to implement new interfaces, and extension methods fail there. With implicits you get both functionalities for the price of one language feature.
I know about defender methods. They are an interesting design, but I really would wish they just added traits instead. The delta between defender methods and traits is very small, but infuriatingly it can't be bridged.
The fact that people do not ask for defender methods might be because the need only manifests itself in larger designs. And of course, these only come up once you have worked with the feature for a while.
Cheers
-- Martin
Re: new language "Kotlin" from jetbrains
I wonder. Is this really true in the face of type classes? It seems to me that the approach of type classes scales almost better than subclassing.
I know you think this is a question of optimization. But there are semantics to consider.
a) Wrapping an object creates a new object, with identiy, hashing, monitoring and all that. Do we really want to rely on optimzation to remove theese semantics?
b) Doesn't wrapping interfere with type inference and typing in general? Most of the time you _dont_ want to change the type of the wrapped object. To return X or RichX...
BR,
John
Re: new language "Kotlin" from jetbrains
+1
I would just be happy if the compiler had sugar for easier typeclass creation/definition and under the covers it still used implicits. With the T : M syntax, if we also had a way to make methoda on M[T] that take a T as their first parameter appear to be methods on T without boilerplate, then most uses of implicit views are unecessary for me.
Another implicit view use case i would miss is acting as a "lens" between two types that represent the same thing from different libraries.
So... implicits are more general, but I would love some optimisations for common use cases.
On Jul 20, 2011 10:07 AM, "John Nilsson" <john [at] milsson [dot] nu> wrote:> On Wed, Jul 20, 2011 at 9:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch>wrote:
>
>> Extension functions are shortsighted because they only make a class get new
>> methods but do not let it implement new interfaces. In any mature framework,
>> the primary reason for a method to exist is to implement some interface.
>> Extension functions don't scale up to that usage.
>>
>
> I wonder. Is this really true in the face of type classes? It seems to me
> that the approach of type classes scales almost better than subclassing.
>
> I know you think this is a question of optimization. But there are semantics
> to consider.
>
> a) Wrapping an object creates a new object, with identiy, hashing,
> monitoring and all that. Do we really want to rely on optimzation to remove
> theese semantics?
>
> b) Doesn't wrapping interfere with type inference and typing in general?
> Most of the time you _dont_ want to change the type of the wrapped object.
> To return X or RichX...
>
> BR,
> John