- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: new language "Kotlin" from jetbrains
On Tue, Jul 19, 2011 at 7:37 PM, Jim Balter <Jim [at] balter [dot] name> wrote:
Agreed. I use this all the time in Fantom and it's really nice. The only downside is that question marks soon become overwhelming in code that is relies a lot on null. I guess it's one more incentive to drop the practice.
-- Cédric
NotNullable is the default ... you have to append '?' to a type to
make it Nullable. That seems to me a step forward from both Java and
Scala, where all reference types are always Nullable ...
Agreed. I use this all the time in Fantom and it's really nice. The only downside is that question marks soon become overwhelming in code that is relies a lot on null. I guess it's one more incentive to drop the practice.
-- Cédric
Re: Re: new language "Kotlin" from jetbrains
On Tue, Jul 26, 2011 at 1:24 PM, Channing wrote:
> Maybe they should just write a scala compiler plugin that prevents you
> using all the complex things in scala ;)
as much as that is tongue-in-cheek, i'd like to use it as an
opportunity to publicly disagree strongly with the meme in programming
language design subcultures that complexity can be hidden in /
abstracted away to one part of the language, leaving Joe New
Programmer safe and comfy. to that i say, "bullshit" because i've been
through that with java generics, and scala types, and &c.
sincerely. :-)
Re: new language "Kotlin" from jetbrains
just my 2c
Michael
Sent from my iPad
On 24.07.2011, at 14:02, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
2011/7/24 Michael Stal <michael [dot] stal [at] gmail [dot] com>
Probably because it's being developed by JetBrains, which guarantees that it will have top notch support from at least one major IDE right out of the gate. No other JVM language has had such support so far.
-- Cédric
RE: new language "Kotlin" from jetbrains
I wonder how the F# people feel about the possibility of Scala on .NET. J
Peter
From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Michael Stal
Sent: Sunday, July 24, 2011 09:02
To: Josh Suereth
Cc: √iktor Ҡlang; scala-debate
Subject: Re: [scala-debate] new language "Kotlin" from jetbrains
The only real competitor would be F# if available on JVM if you ask me
Re: new language "Kotlin" from jetbrains
Sent from my iPad
On 24.07.2011, at 16:28, "Peter C. Chapin" <PChapin [at] vtc [dot] vsc [dot] edu> wrote:
Re: new language "Kotlin" from jetbrains
On 24/07/2011 17:05, Michael Stal wrote:
> However both Martin and Don are excellent language developers. And Don
> Syme has high respect for Scala
And Martin Ordersky has high respect for Scala, IIRC.
F# is an interesting language, but its syntax might be different enough
not to be a direct concurrent, perhaps.
Re: new language "Kotlin" from jetbrains
Am 24.07.2011 15:02, schrieb Michael Stal:
Re: new language "Kotlin" from jetbrains
On 24/07/2011 15:23, HamsterofDeath wrote:
> i don't see a problem with 100 languages being developed (ide/tool
> support being another problem) as they are very similar to each other.
What is funny, is there has been always a lot of languages coming out
every year, and most of them are just ignored by the vast majority of
programmers... Not much debate, at least.
Now, the JVM ecosystem has less languages built on it, so they got more
audience because lot of programmers live on this ecosystem, and perhaps
look around, tired of the old syntax of Java.
That, and the fact most of these languages are done by big names in
programming language design, or big (or at least well known) companies.
Re: Re: new language "Kotlin" from jetbrains
Hi,
>> i don't see a problem with 100 languages being developed (ide/tool
>> support being another problem) as they are very similar to each other.
>
> What is funny, is there has been always a lot of languages coming out
> every year, and most of them are just ignored by the vast majority of
> programmers... Not much debate, at least.
I guess the main difference is that they basically get much of their
audience by bashing Scala (and we are sadly participating here ...)
While the overall level of intellectual dishonesty is troubling, I think
it is a step into the right direction:
People don't have to explain anymore "Why Java is not enough anymore"
but can start with trying to differentiate themselves from Scala (and fail).
Bye
RE: new language "Kotlin" from jetbrains
Quote
The problems posed by concurrency are vastly overstated these days. First because the complexities are often neatly abstracted behind frameworks and technologies that have been honed for more than a decade (web and application servers mostly, but also individual libraries) and second because ever since Java 5, developers who actually have to deal with complex threading problems have had some very powerful and well designed tools to address them (j.c.util is the most obvious one, JCIP is also a very important part of this picture).
… if you actually meant that, you would be kidding me. A web server helps deal with your concurrent issues how exactly? Application servers, all they do in this respect is provide basically an actor framework (MDB) and transactional extensions for synchronous calls (EJB) with the underlying thread and resource pools.
Concurrency is hard. It has been abstracted for the past 5 decades or more, in numerous dedicated languages, environments, libraries and it’s still hard! If it wasn’t, we wouldn’t be talking about it. And when you go distributed, it’s that much harder. If it wasn’t we wouldn’t be talking about it!
In my experience, most java developers screw up badly whenever approaching concurrency but luckily, they don’t have to, most of the time. So you’d be right to observe that most of the time they don’t have issues with concurrency J
I’m glad to see that so many folks in this thread are having an easy time with concurrency, but then 80% of us think are better drivers than average! I wonder how many actually use concurrency constructs on a monthly or weekly basis to justify said skill.
Having said that, concurrency has nothing to do with scala. Are you talking about the “actor library” or the “parallel collection library”? Scala doesn’t even have a concurrency primitive like “synchronized” I think it’s a method..
Just saying…
From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Cédric Beust ?
Sent: July-22-11 1:01 PM
To: Ðavîd Låndïs
Cc: Maxime Lévesque; Meredith Gregory; Sébastien Bocq; martin odersky; Ben Hutchison; Josh Suereth; John Nilsson; Rex Kerr; scala-debate
Subject: Re: [scala-debate] new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 9:49 AM, Ðavîd Låndïs <dlandis [at] gmail [dot] com> wrote:
As an "enterprise" Java developer myself I have to agree with Maxime
here. I appreciate Greg's perspective of course, but it simply is not
true in my experience in the financial sector over the past 5+ years
that the "vast majority" of developers are struggling with concurrency
issues. I would say the vast majority are not in fact.
Another +1 from me as well. The problems posed by concurrency are vastly overstated these days. First because the complexities are often neatly abstracted behind frameworks and technologies that have been honed for more than a decade (web and application servers mostly, but also individual libraries) and second because ever since Java 5, developers who actually have to deal with complex threading problems have had some very powerful and well designed tools to address them (j.c.util is the most obvious one, JCIP is also a very important part of this picture).
I also find it odd when so many people are saying that the multicore era is upon us and we need to start dealing with the "new" problem of massive parallelism.
We've been dealing with this ever since Java shipped 1.0 with the java.lang.Thread class in it. Switching from multi processors to multi cores adds no problem that JVM developers haven't already been exposed to for the better part of a decade.
It's nice to see new directions such as actors or ForkJoin being explored, but there's nothing really revolutionary happening there.
--
Cédric
Re: new language "Kotlin" from jetbrains
By running all the servlets and queries in a thread pool that's completely hidden from you. When was last time you were writing a servlet and you had to worry about spawning threads to run them all in parallel?
Nobody is saying concurrency is easy, just that it's a non-issue for a lot of developers.
I don't have an easy time with concurrency. Never have, probably never will. It's always difficult to write correct multithreaded code, especially if you are writing a framework (meaning: you're exposing these facilities to others). The point is that *I* am going through these pains so that users of my framework won't have to. For example, I make it possible for them to test the thread safety of their code without having to even spawn a single thread, with features such as:
@Test(threadPoolSize = 10, invocationCount = 10000)public void test() { ... }
-- Cédric
RE: new language "Kotlin" from jetbrains
Sorry – I didn’t consider this as real help
listen (port, servlets) {
request => new Thread {
def run { servlets.foreach {_.matchAndProcess(request)} }
}
Add a thread pool in 10 more lines of code. Actually you don’t need one, just spawn new threads with an upper limit – it’s cleaner that way.
In my view, what the web server does is authorization, authentication, all the HTTP stuff, SSL, mapping, forwarding etc. concurrency is the last thing and close to nothing really. Just a thread pool.
Dealing with concurrency in the *implementation of the servlet* – that’s where the trouble lies. If the world was synchronous and instantaneous, we wouldn’t have this issue J
Sorry for forking the discussion. Fork over…
Cheers,
Razie
From: cbeust [at] gmail [dot] com [mailto:cbeust [at] gmail [dot] com] On Behalf Of Cédric Beust ?
Sent: July-22-11 2:12 PM
To: Razvan Cojocaru
Cc: Ðavîd Låndïs; Maxime Lévesque; Meredith Gregory; Sébastien Bocq; martin odersky; Ben Hutchison; Josh Suereth; John Nilsson; Rex Kerr; scala-debate
Subject: Re: [scala-debate] new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 11:03 AM, Razvan Cojocaru <pub [at] razie [dot] com> wrote:
Quote
The problems posed by concurrency are vastly overstated these days. First because the complexities are often neatly abstracted behind frameworks and technologies that have been honed for more than a decade (web and application servers mostly, but also individual libraries) and second because ever since Java 5, developers who actually have to deal with complex threading problems have had some very powerful and well designed tools to address them (j.c.util is the most obvious one, JCIP is also a very important part of this picture).
… if you actually meant that, you would be kidding me. A web server helps deal with your concurrent issues how exactly?
By running all the servlets and queries in a thread pool that's completely hidden from you. When was last time you were writing a servlet and you had to worry about spawning threads to run them all in parallel?
Nobody is saying concurrency is easy, just that it's a non-issue for a lot of developers.
I don't have an easy time with concurrency. Never have, probably never will. It's always difficult to write correct multithreaded code, especially if you are writing a framework (meaning: you're exposing these facilities to others). The point is that *I* am going through these pains so that users of my framework won't have to. For example, I make it possible for them to test the thread safety of their code without having to even spawn a single thread, with features such as:
@Test(threadPoolSize = 10, invocationCount = 10000)
public void test() { ... }
--
Cédric
Re: new language "Kotlin" from jetbrains
Concurrency is most of the time hidden and well insulated these days. Devs that need to deal with it accumulated enough proficiency by now - as well as JDK tools/frameworks matured dramatically over the last few years.
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com
On Fri, Jul 22, 2011 at 11:12 AM, Cédric Beust ♔ <cedric [at] beust [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
True if and only if you are working on something that is structurally similar to a web application. That's probably the single most common use case, sure -- but most interesting and complex problems aren't structured like that.
Looking at it a different way: I think that the majority of *programmers* today don't need to worry about concurrency much, because most of them are working on a very small category of problems. But the majority of distinctly-different programming *problems* do involve concurrency rather deeply.
I don't buy it. I am very good at concurrent programming -- the vast majority of the projects I've worked on in the past dozen years, both client- and server-side, have required serious multi-threading -- and I still find it difficult drudge-work. Most frameworks are by no stretch of the imagination good enough for the general case, just for a few specific ones. (The frameworks that *are* really powerful are the ones we're talking about here, like Actors...)
Re: new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 11:51 AM, Justin du coeur wrote:
> 2011/7/22 Nikita Ivanov
>>
>> Concurrency is most of the time hidden and well insulated these days.
>
> True if and only if you are working on something that is structurally
> similar to a web application. That's probably the single most common use
> case, sure -- but most interesting and complex problems aren't structured
> like that.
> Looking at it a different way: I think that the majority of *programmers*
> today don't need to worry about concurrency much, because most of them are
> working on a very small category of problems. But the majority of
> distinctly-different programming *problems* do involve concurrency rather
> deeply.
The original claim being disputed here is "At the practical level,
this is what the vast majority of developers are facing in their day
jobs, now" and it appears that you dispute it too.
Re: new language "Kotlin" from jetbrains
I would like to add my experience of what the average dev faces in the
financial world I inhabit from time to time, and where I think scala
fits in as a superior choice of language over Java/Kotlin/etc.
1. Concurrency / parallelism is not understood at all, but actually
doesn't matter, because...
2. Apps rely on frameworks (hibernate etc) and coarse transactions to
keep data out of trouble - kind of. When apps mysteriously misbehave,
an army of support people leap into action (because banks can afford
it) and fix/hack/slash until all is 'apparently' well.
3. Scaling and performance is not an issue except in some rare cases
such as high frequency trading or pricing. Most apps only need to deal
with a few thousand users at most if they are user facing. Back end
systems also rarely deal with much when compared with systems
operating at the internet scale. A database, a few queues and a few
processes is usually about it. Performance can be a problem simply
because people do stupid things.
4. Devs just follow the Java patterns as decreed by framework writers
and architects - its the law - and it usually works sufficiently well
for people to get their bonuses.
5. Now the problem. The biggest, most expense, ugliest, bug-ridden,
cut and paste mess is almost always in modelling the domain. Financial
models of weird structured products is a nightmare. Across a single
stack, from front to back office, the same domain is modelled in each
system in multiple different ways and almost always in deeply
unsatisfying ways.
Java is simply not up to the job of modelling these domains.
Furthermore, I believe that any language that is not statically typed
and supports higher order abstractions, mixins, etc. will not be up to
the job.
The point is that the average Java dev has absolutely no idea how a
type system like scala's together with FP can help them. Words like
monad, monoids and endofunctors make them run a mile.
Show these people how scala can model these nasty domains, explicitly,
and you might get the dev's attention and that of senior IT management
who lament the cost of building, maintaining and rewriting these
systems every 3-5 years.
But right now, a language like kotlin will be much more attractive to
them because it makes doing what they do now slightly easier.
RE: Re: new language "Kotlin" from jetbrains
> Subject: [scala-debate] Re: new language "Kotlin" from jetbrains
> From: channingwalton [at] mac [dot] com
> 5. Now the problem. Financial models of weird structured products is a nightmare. Across a single
> stack, from front to back office, the same domain is modelled in each
> system in multiple different ways and almost always in deeply unsatisfying ways.
+1
>
> I believe that any language that is not statically typed and supports higher order abstractions, > mixins, etc. will not be up to the job.
The authors of Kapital, which is the exotics system at JPMorgan (who basically invented exotics) and which is written in *Smalltalk* (yes, Smalltalk), would likely havethe opposite opinion on this.
Re: RE: Re: new language "Kotlin" from jetbrains
On Monday, July 25, 2011 4:22:06 AM UTC-7, Chris Marshall wrote:
Smalltalk has had very good tool support, going back 30 and more years. Very good programmers plus good tools plus a well-designed language can do wonders.
I would prioritize my choices for any project in that order...
1. Have good people2. Have good tools3. Have a good language
Sometimes you have to swap #2 and #3, and that works out well as long as you have #1.
Re: Re: new language "Kotlin" from jetbrains
On 25 Jul 2011, at 12:22, Chris Marshall wrote:
> >
> > I believe that any language that is not statically typed and supports higher order abstractions,
> > mixins, etc. will not be up to the job.
>
> The authors of Kapital, which is the exotics system at JPMorgan (who basically invented exotics) and which is written in *Smalltalk* (yes, Smalltalk), would likely have
> the opposite opinion on this.
Quite so. I know some of those guys and I'd forgotten about it.
Re: Re: new language "Kotlin" from jetbrains
On 23/07/2011 23:07, Channing wrote:
> [...]
> 5. Now the problem. The biggest, most expense, ugliest, bug-ridden,
> cut and paste mess is almost always in modelling the domain. Financial
> models of weird structured products is a nightmare. Across a single
> stack, from front to back office, the same domain is modelled in each
> system in multiple different ways and almost always in deeply
> unsatisfying ways.
>
> Java is simply not up to the job of modelling these domains.
> Furthermore, I believe that any language that is not statically typed
> and supports higher order abstractions, mixins, etc. will not be up to
> the job.
>
> The point is that the average Java dev has absolutely no idea how a
> type system like scala's together with FP can help them. Words like
> monad, monoids and endofunctors make them run a mile.
>
> Show these people how scala can model these nasty domains, explicitly,
> and you might get the dev's attention and that of senior IT management
> who lament the cost of building, maintaining and rewriting these
> systems every 3-5 years.
Now, that's intersting, and a sufficiently uncommon advantage of Scala
to be noticed. Well, Debasish has a blong full of such examples[1], but
nonetheless it's worth noticing.
> But right now, a language like kotlin will be much more attractive to
> them because it makes doing what they do now slightly easier.
That's intersting too. And what make Kotlin suitable for that, and not
Scala ? The too-much different syntax ?
[1]
http://debasishg.blogspot.com/2011/06/composing-heterogeneous-dsls-in-sc...
for example.
Re: new language "Kotlin" from jetbrains
On Jul 24, 7:20 am, Francois wrote:
> On 23/07/2011 23:07, Channing wrote:
> > But right now, a language like kotlin will be much more attractive to
> > them because it makes doing what they do now slightly easier.
>
> That's intersting too. And what make Kotlin suitable for that, and not
> Scala ? The too-much different syntax ?
Its not something that Kotlin is more suitable, it isn't. Kotlin is
just not scary for the average dev. I have had a few people come to me
saying they are 'scared' that scala is too difficult for them because
of all the FUD they see and hear.
Yes I am aware of Debasish's most excellent blogs. I am going to spend
more time studying them I think.
Re: Re: new language "Kotlin" from jetbrains
On Sun, Jul 24, 2011 at 3:00 PM, Channing <channingwalton [at] mac [dot] com> wrote:
I've had similar experiences with developers being introduced to Scala. There is some apprehension w.r.t. things like implicits. Some education of how to use implicits and how to structure your own implicits typically address this concern.
--
Jim Powers
Re: new language "Kotlin" from jetbrains
On 21/07/11 14:57, Ben Hutchison wrote:
> On Thu, Jul 21, 2011 at 2:31 AM, martin odersky wrote:
>> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth
>> wrote:
>>> I never said scala was complex :)
>> If you are in the majority, it's a silent one, then :-)
> IMO... this whole "complexity" issue risks becoming a major distraction.
>
> I don't find Scala too complex. I came from Java, found parts of Scala
> confusing or foreign at first, then got over it.
>
> Scala should continue to focus on "making programming easier", above
> "being popular" if need be. Making programming easier for easy
> problems, but also and especially for hard problems, since any old
> programming language can solve easy problems.
>
> Scala got to its current, enviable position by a sincere, sustained
> focus on tackling challenges using the best known methods and
> technology (plus an awful lot of hard work). Regardless of whether
> that technology was widely known or popular at the time of
> introduction.
>
> Problems will keep arising, things that emerge as difficult or awkward
> to express in Scala; in type classes, variance, type inference, effect
> tracking or elsewhere. We should not be ashamed to be the leader, to
> go into battle with these problems and formulate solutions, even when
> others yet deny they even exist.
>
> -Ben
Scala is not complex. Programming is hard.
Anti-intellectual disguises are self-deceiving distractions from the
fact. Giggle about it -- this "complex" issue is being taken way too
seriously.
Re: new language "Kotlin" from jetbrains
2011/7/21 Tony Morris <tonymorris [at] gmail [dot] com>
Scala is not complex. The problems it addresses are complex.
--
Sébastien
Re: new language "Kotlin" from jetbrains
Yes, sometimes, but certainly not always. Take a look at the US tax code.
--Russ P.
--
http://RussP.us