Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30102 > unrolled thread

Alternative languages on the JVM: what's a meaningful strategy?

Back to article view | Back to comp.lang.java.programmer

Contents

  Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-16 05:27 -0700
    Re: Alternative languages on the JVM: what's a meaningful strategy? Robert Klemme <shortcutter@googlemail.com> - 2014-10-16 21:15 +0200
    Re: Alternative languages on the JVM: what's a meaningful strategy? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-16 16:28 -0400
    Re: Alternative languages on the JVM: what's a meaningful strategy? Arne Vajhøj <arne@vajhoej.dk> - 2014-10-16 19:13 -0400
    Re: Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-17 06:34 -0700
      Re: Alternative languages on the JVM: what's a meaningful strategy? Arne Vajhøj <arne@vajhoej.dk> - 2014-10-18 22:42 -0400
        Re: Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-19 11:00 -0700
    Re: Alternative languages on the JVM: what's a meaningful strategy? Roedy Green <see_website@mindprod.com.invalid> - 2014-10-19 11:03 -0700
    Re: Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-21 05:48 -0700
      Re: Alternative languages on the JVM: what's a meaningful strategy? ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-22 06:34 +0000
    Re: Alternative languages on the JVM: what's a meaningful strategy? Silvio <silvio@internet.com> - 2014-10-21 15:10 +0200
      Re: Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-21 07:09 -0700
        Re: Alternative languages on the JVM: what's a meaningful strategy? Silvio <silvio@internet.com> - 2014-10-21 16:26 +0200
          Re: Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-21 08:03 -0700
      Re: Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-22 07:22 -0700
        Re: Alternative languages on the JVM: what's a meaningful strategy? Silvio <silvio@internet.com> - 2014-10-22 17:14 +0200
          Re: Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-23 08:53 -0700
            Re: Alternative languages on the JVM: what's a meaningful strategy? Silvio <silvio@internet.com> - 2014-10-24 00:37 +0200
    Re: Alternative languages on the JVM: what's a meaningful strategy? Saxo <jeti789@web.de> - 2014-10-24 02:52 -0700

#30102 — Alternative languages on the JVM: what's a meaningful strategy?

Hi dudes,

some while ago I felt annoyed with Java lacking various things like extension methods and traits that other competing languages have for a long time (e.g., C#). So I started to have a look at other JVM languages such as Groovy, Scala, Fantom, and now Kotlin. 

I disliked Scala for various reason. It seems to have a problem with code readibility (mostly caused by implicits). Code readabilitiy is for me an absolute top priority in software development. Then build times were a problem. Now it seems to be o.k., but still just acceptable.

So I had a look at Kotlin, which I really like. Code readibility is excellent here and so are built time and other things. Basically, Kotlin would be it for me. But then again it made me think: Java will always dominate on the JVM with, say, 95% or something. What you do with Kotlin will be for sparetime fun & leisure. It will almost never be for work. 

All right, then I pick a language that is radically different which brings me back to Scala. Actually, this is starting to drive me nuts. Really ... What is your take on the matter? I mean not in a subjective way, but in an objective way. To make a good decision you kind of have to predict the future, but you can still try to be objective with this.

Any opinions aprreciated.
Cheers, Saxo

[toc] | [next] | [standalone]

#30108

On 16.10.2014 14:27, Saxo wrote:

> All right, then I pick a language that is radically different which
> brings me back to Scala. Actually, this is starting to drive me nuts.
> Really ... What is your take on the matter? I mean not in a
> subjective way, but in an objective way.

First of all: there are no objective decisions.  What is good depends on 
your goals and how you weight them.

> To make a good decision you kind of have to predict the future, but
> you can still try to be objective with this.

Anything that involves predicting the future is shaky at best.  I think 
best you can do is to define your priorities and evaluate languages 
against them.  On top of that you can try to estimate which language is 
going to increase or decrease it's coverage of your goals in the next N 
years.

But the most important thing is: find out what you want, what is your 
goal.  You seem to be pretty undecided and the situation will not 
improve as long as you do not know where you are headed to.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#30109

On 10/16/2014 8:27 AM, Saxo wrote:
> [...]
> I disliked Scala for various reason. It seems to have a problem with code readibility (mostly caused by implicits). Code readabilitiy is for me an absolute top priority in software development. Then build times were a problem. Now it seems to be o.k., but still just acceptable.

     In addition to Robert Klemme's points, consider that readability
is a function not only of the language (and the writer's style), but
also of the reading audience.  If you find a language that you can read
with ease and perhaps even with delight but that is inscrutable to
99.44% of other programmers, "effective readability" suffers.

     Cretan Linear A (<http://en.wikipedia.org/wiki/Linear_A>) may be
the most readable, expressive, and beautiful language ever invented,
but nobody knows for sure.

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#30111

On 10/16/2014 8:27 AM, Saxo wrote:
> some while ago I felt annoyed with Java lacking various things like
> extension methods and traits that other competing languages have for
> a long time (e.g., C#). So I started to have a look at other JVM
> languages such as Groovy, Scala, Fantom, and now Kotlin.

Java 8 default methods will cover a good part of your need for
extension methods.

A good AOP framework will cover a good part of your need for
traits. I like AspectJ. It is not that easy, but it is quite
powerful.

> I disliked Scala for various reason. It seems to have a problem with
> code readibility (mostly caused by implicits). Code readabilitiy is
> for me an absolute top priority in software development. Then build
> times were a problem. Now it seems to be o.k., but still just
> acceptable.
>
> So I had a look at Kotlin, which I really like. Code readibility is
> excellent here and so are built time and other things. Basically,
> Kotlin would be it for me. But then again it made me think: Java will
> always dominate on the JVM with, say, 95% or something. What you do
> with Kotlin will be for sparetime fun & leisure. It will almost never
> be for work.
>
> All right, then I pick a language that is radically different which
> brings me back to Scala. Actually, this is starting to drive me nuts.
> Really ... What is your take on the matter? I mean not in a
> subjective way, but in an objective way. To make a good decision you
> kind of have to predict the future, but you can still try to be
> objective with this.

Scala is a very complex language.

Whether you like it or not is a personal preference. You need
to make up your own mind.

But professionally Scala is relevant because it is actually
used out there.

A search on dice.com finds:

Java - 17863
Scala - 432
Groovy - 431
Clojure - 87
Kotlin - 0
Fantom - 0

Did you try Groovy?

Even though Java is clearly the dominant language, then knowing another
language is certainly a good thing.

Arne

[toc] | [prev] | [next] | [standalone]

#30118

>Anything that involves predicting the future is shaky at best.  I think
>best you can do is to define your priorities and evaluate languages
>against them.  On top of that you can try to estimate which language is
>going to increase or decrease it's coverage of your goals in the next N
>years. 

Not long after I started this thread I found this article:
http://romansky.me/2012/11/14/making-the-case-for-kotlin/ I think the author got it exactly right. Scala turned out overly complicated. It is not just loaded with many features. Some decisions made it more complicated than necessary. I believe Kotlin will collect many of the people that had a look at Scala, but then turned away from it, because too complicated.

>But the most important thing is: find out what you want, what is your
>goal.  You seem to be pretty undecided and the situation will not
>improve as long as you do not know where you are headed to. 

Yeah, this has something to it. My "heart" says Kotlin is really well made and has some coherence and simplicity I think is important in language design. What makes me think is that Ceylon turned 1.0 for almost a year ago and it has not created any interest at all. Hope this won't happen with Kotlin.

>A search on dice.com finds:

>Java - 17863
>Scala - 432
>Groovy - 431
>Clojure - 87
>Kotlin - 0
>Fantom - 0 

Scala is now over 10 years old. Those 423 for Scala took over 10 years! This is what makes me think. Otherwise I would just go with Kotlin.

Well I did that Scala Functional course at Coursera and paid for the certificate. Think that is enough as what Scala is concerned. Maybe I start with Kotlin now. This is the language I think was done well. And it is geared towards the enterprise where Scala is more of a research language that the creators try to tell to companies.

Well, well. Will let some days pass by till my mind has "become calm" so that I can think undisturbed about it. 

Thanks for the helpful replies.
Cheers, Saxo

[toc] | [prev] | [next] | [standalone]

#30129

On 10/17/2014 9:34 AM, Saxo wrote:
>> A search on dice.com finds:
>
>> Java - 17863
>> Scala - 432
>> Groovy - 431
>> Clojure - 87
>> Kotlin - 0
>> Fantom - 0
>
> Scala is now over 10 years old. Those 423 for Scala took over 10 years! This is what makes me think. Otherwise I would just go with Kotlin.

Kotlin has spend 3 years reaching 0.

But if it is not CV driving this then you can ignore these numbers.

Arne

[toc] | [prev] | [next] | [standalone]

#30130

> > Scala is now over 10 years old. Those 423 for Scala took over 10 years! This is what makes me think. Otherwise I would just go with Kotlin.
> 
> Kotlin has spend 3 years reaching 0.
> 
> But if it is not CV driving this then you can ignore these numbers.

Problem is that some things in Scala are really screwed up. If build times don't scare people away, then it will be the code that can be hard to read.

The Kotlin guys really spent time thinking about how to do things. Kotlin is really Java done right + Scala done right. I think I just do Kotlin without falling prey to some illusion that any language on the JVM other than Java will ever really matter. Kotlin is OO really done well and it fits really well to my OO knowledge build in many years doing Smalltalk. 

Question is more what to develop with it. Here you can fall prey to the next illusion that anything you do will be noticed and make a difference for job applications. Maybe just play with it and write some blog articles that show good understanding and see what happens during the next 1-2 years when Kotlin become 1.0.

So long, Saxo

[toc] | [prev] | [next] | [standalone]

#30131

On Thu, 16 Oct 2014 05:27:52 -0700 (PDT), Saxo <jeti789@web.de> wrote,
quoted or indirectly quoted someone who said :

>. W=
>hat is your take on the matter? 

If you create a large body of code you need to maintain indefinitely
into the future, the biggie is will the langugage continue to be
supported and maintained. That tends to make you put up with a lot of
imperfection.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Software gets slower faster than hardware gets faster.
~ Niklaus Wirth (born: 1934-02-15 age: 80) Wirth’s Law

[toc] | [prev] | [next] | [standalone]

#30144

Well, Jetbrains has a very good plugin for Kotlin for their own IDE IntelliJ. They have uploaded a basic eclipse plugin to Gihub. But it is clear that their own IDE will always be the most polished one. 

So this looks like Kotlin might become a proprietary language like earlier Delphi from Borland. Scala is so screwed up, it makes me sick to look at that language. Simply too many bad decisions. If they only had had more patience and tried out things (effect on compilation speed?) before they were made official. I'm very sure Niklaus Wirth would have been more cautious ...

[toc] | [prev] | [next] | [standalone]

#30151

In article 6fad51bf-bfcd-4dea-839b-b1397b5cb50d@googlegroups.com, Saxo
said...

> Well, Jetbrains has a very good plugin for Kotlin for their own IDE
> IntelliJ. They have uploaded a basic eclipse plugin to Gihub. But it is
> clear that their own IDE will always be the most polished one.
> 
> So this looks like Kotlin might become a proprietary language like
> earlier Delphi from Borland. Scala is so screwed up, it makes me sick to
> look at that language. Simply too many bad decisions.

Well, then, I guess that only leaves ... what was that other language? 
Clojure? Assuming that that is non-proprietary and sure to remain that 
way.

[toc] | [prev] | [next] | [standalone]

#30145

On 10/16/2014 02:27 PM, Saxo wrote:
> Hi dudes,
>
> some while ago I felt annoyed with Java lacking various things like extension methods and traits that other competing languages have for a long time (e.g., C#). So I started to have a look at other JVM languages such as Groovy, Scala, Fantom, and now Kotlin.
>
> I disliked Scala for various reason. It seems to have a problem with code readibility (mostly caused by implicits). Code readabilitiy is for me an absolute top priority in software development. Then build times were a problem. Now it seems to be o.k., but still just acceptable.
>
> So I had a look at Kotlin, which I really like. Code readibility is excellent here and so are built time and other things. Basically, Kotlin would be it for me. But then again it made me think: Java will always dominate on the JVM with, say, 95% or something. What you do with Kotlin will be for sparetime fun & leisure. It will almost never be for work.
>
> All right, then I pick a language that is radically different which brings me back to Scala. Actually, this is starting to drive me nuts. Really ... What is your take on the matter? I mean not in a subjective way, but in an objective way. To make a good decision you kind of have to predict the future, but you can still try to be objective with this.
>
> Any opinions aprreciated.
> Cheers, Saxo
>

Scala implicits effectively increases code readability unless someone 
starts using it outside the standard library and does so badly.

Implicit parameters can be a very valuable way of simplifying library 
usage code and getting rid of endlessly passing along context-like 
parameters, in the end making code much easier to read as well.

Implicit conversions are something completely different. I have vetoed 
any attempt to use them in application code inside my company.

For the non-lay Scala code is probably at least 2 times easier and 
faster to proof-read. Code readability is mostly about signal/noise 
ratio which is extremely much better in Scala code than in Java code.

For a good Scala programmer the code is also much easier to understand 
because of the higher abstraction level but that does require mastering 
the language. Lacking that even a small fragment of Scala code can be 
well neigh incomprehensible.

Code readability is a function of the way code was written, the language 
it is written in and the person who is doing the reading. Of these three 
the language is the least influential factor.

Silvio

[toc] | [prev] | [next] | [standalone]

#30146

> Implicit conversions are something completely different. I have vetoed  
> any attempt to use them in application code inside my company.

The point is that when you need to add a method, say to class String, you would use an implicit conversion for that (pimp my library pattern). Because this StringUtils stuff with static methods is really ugly ...

[toc] | [prev] | [next] | [standalone]

#30147

On 10/21/2014 04:09 PM, Saxo wrote:
>
>> Implicit conversions are something completely different. I have vetoed
>> any attempt to use them in application code inside my company.
>
> The point is that when you need to add a method, say to class String, you would use an implicit conversion for that (pimp my library pattern). Because this StringUtils stuff with static methods is really ugly ...
>

I do not think adding methods to String is a wise thing. Therefore I do 
not like the pimp my library pattern. Such constructs are highly 
overrated and I hate zoomed in discussions about what is nicer or uglier 
about a certain syntactical construct.

It is the overall structure (and architecture) of a software system that 
defines its quality. Scala allows me to create constructs that are hard 
to implement succinctly and in an extensible way with languages like 
Java that lack more important stuff like traits, co/contra-variance, 
pattern matching and case classes, standard library with 
immutable/persistent containers, higher kinded types etc.

Silvio

[toc] | [prev] | [next] | [standalone]

#30148

Am Dienstag, 21. Oktober 2014 16:26:27 UTC+2 schrieb Silvio:

> It is the overall structure (and architecture) of a software system that 
> defines its quality. Scala allows me to create constructs that are hard 
> to implement succinctly and in an extensible way with languages like 
> Java that lack more important stuff like traits, co/contra-variance, 
> pattern matching and case classes, standard library with 
> immutable/persistent containers, higher kinded types etc.

Extension methods are really useful as they preserve "proper" OO-style message passing. They exist in Smalltalk, Objective-C, C# and also Kotlin for a reason. Neverhteless, I understand the point you are making. Scala appears to me more like a "research language". There is no negative pun intended here. Good thing such a language exists! But for company internal development some Java done right language with nice additional features as with Kotlin is what many people are looking for. 

As a matter of fact I should learn both, Scala and Kotlin. Scala for "applied language research" and Kotlin for application development as some "Java done right" and "Scala light" language. But both languages are just too much ... ;-).

[toc] | [prev] | [next] | [standalone]

#30157

> Implicit conversions are something completely different. I have vetoed 
> any attempt to use them in application code inside my company.

I think the Scala people should add delegates to Scala as they exist in Kotlin:
http://kotlinlang.org/docs/reference/delegation.html

This would take the preasure out of Scala's implicit conversions and they can keep face. They just implemented a cool new feature...

[toc] | [prev] | [next] | [standalone]

#30159

Totally agree that delegation is a very powerful and useful feature. I 
have advocated for it in both Java and Scala development forums (to no 
avail, of course) and would very much welcome such an addition to Scala. 
It enables interface oriented no-inheritance OOP.

However, I fail to understand how it would be an alternative for 
implicit conversions...

On 10/22/2014 04:22 PM, Saxo wrote:
>
>> Implicit conversions are something completely different. I have vetoed
>> any attempt to use them in application code inside my company.
>
> I think the Scala people should add delegates to Scala as they exist in Kotlin:
> http://kotlinlang.org/docs/reference/delegation.html
>
> This would take the preasure out of Scala's implicit conversions and they can keep face. They just implemented a cool new feature...
>

[toc] | [prev] | [next] | [standalone]

#30166

> However, I fail to understand how it would be an alternative for 
> implicit conversions...

Delegation can be seen as some kind of explicit conversion. What is physically happening is something else, but it appears kind of as an explicit conversion that is not transparent.

In this pseudo-code the conversion is explicit (explicitly saying new RichString("foo")), but it is transparent as class String is untouched:

class RichString {

    implicit def foo(): String = whatever

}

val str = new RichString("foo")

This is pseudo-code Groovy-style where things are also not transparent, because base class String is changed:

class String {

    @Delegate
    RichtString str = new RichString()
    
}

What I mean is that in cases where conversion can be explicit or not need to be transparent you could use delegation to get the work done and get around implicit conversion which keeps the compiler much more busy and thus reduce build times.

Maybe I'm also just wrong and don't understand implicit conversion in Scala well enough. I don't know ...

Cheers, Saxo

[toc] | [prev] | [next] | [standalone]

#30168

On 10/23/2014 05:53 PM, Saxo wrote:
>> However, I fail to understand how it would be an alternative for
>> implicit conversions...
>
> Delegation can be seen as some kind of explicit conversion. What is physically happening is something else, but it appears kind of as an explicit conversion that is not transparent.
>
> In this pseudo-code the conversion is explicit (explicitly saying new RichString("foo")), but it is transparent as class String is untouched:
>
> class RichString {
>
>      implicit def foo(): String = whatever
>
> }
>
> val str = new RichString("foo")
>
> This is pseudo-code Groovy-style where things are also not transparent, because base class String is changed:
>
> class String {
>
>      @Delegate
>      RichtString str = new RichString()
>
> }
>
> What I mean is that in cases where conversion can be explicit or not need to be transparent you could use delegation to get the work done and get around implicit conversion which keeps the compiler much more busy and thus reduce build times.
>
> Maybe I'm also just wrong and don't understand implicit conversion in Scala well enough. I don't know ...
>
> Cheers, Saxo
>

What I dislike about implicit conversions is that they are used to 
attach behaviour to existing classes from the outside by having the 
compiler insert wrappers automatically. Like this Scala example:

implicit class HalveString(str : String)
{
    def firstHalve = str.substring(0,str.length / 2)
    def secondHalve = str.substring(str.length / 2)
}

which when in scope makes

    "abcd".firstHalve == "ab"

because the compiler replaces that with

    (new HalveString("abcd")).firstHalve == "ab"

which I think is complete bullocks. The meaning of an operation on an 
object is not only defined by the definition of its class but also by 
the implicit conversions that are in scope.
The way it has been used in the standard library is not bad and makes 
for a cleaner library but that is where it ought to stop.

I admit to having used it here and there to make some painfully bulky 
code (yes, although less common we now and then have that with Scala as 
well) a bit less painful. But then I always keep the implicit wrapper 
local to a surrounding class.

But I think we agree that delegation works exactly the other way around: 
it makes adding behaviour to a class easier by delegating to an object 
of a class that already had the desired behaviour but does so by 
explicitly making the behaviour part of said class.

Cheers,

Silvio

[toc] | [prev] | [next] | [standalone]

#30170

I think I found the criteria that really matters (at least to me): Scala is a true community project. Whatever someone contributes will be to the benefit of the community. I like Kotlin in many ways more. But everything you do will in the end be to the benefit of the company behind Kotlin. What I do in my sparetime should be for the community. Kotlin will have good build times, which Scala might never have. But I don't think any language can rival Java on the JVM anyway. That would be foolish to believe. It is only about having some spare time leisure to free me from the limitations of Java and discover new things. So the decision is for Scala. Man, that was really hard now. But I think this was it. Thanks for all the replies.

Regards, Saxo

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web