71–80 of 233 posts
Earlier quoted context omitted.
Lots. See https://en.wikipedia.org/wiki/Java_applet and https://en.wikipedia.org/wiki/Java_Web_Start for links.
You forgot Jini, https://en.wikipedia.org/wiki/Jini Also Oberon was another system that also allowed for something like Java applets, called Juice. http://www.modulaware.com/mdlt69.htm
I'm JVM guy and really wish this platform has something like F# - "minimalistic" functional language (not like Scala) with static, powerful type system (not like Clojure).
Earlier quoted context omitted.
They can, it is their problem if they keep ignoring the existing AOT compilers, and there are quite a few.
Are there any without an expensive license?
ExcelsiorJET has a free license for non-commercial uses.
https://www.excelsiorjet.com/#free
RoboVM's fork is another possibility
If the language designers keep their heads, Kotlin will slowly eat away at Java. Java itself is never going away: it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. Xtend never was alive, and it's clear Ceylon has lost at this point, even though it is arguably better designed than Kotlin. However, they made some bad syntactic decisions (not shedding enough of the Java verbosity,…
Kotlin can never replace Java as long as the JVM is relevant. This is like trying to replace C on UNIX, C# on .NET, Erlang on BEAM, or JavaScript on the browser.
I also never said Kotlin will replace Java, but that it will gradually grow to the detriment of Java, which is still here to stay.
I wonder why Kotlin beat Scala in this virtual programming language traction game. I don't write code for the JVM anymore, but Kotlin occupies the same space as Scala. Was it compilation speed? Corporate support?
The article shows google search traffic for Kotlin which temporarily spiked above Scala in the wake of the Android announcement and then dropped back down to less than half the Scala traffic, below Groovy in fact. I'm not sure that it's much of an indicator of anything.
Also of interest:
Earlier quoted context omitted.
> I wonder why Kotlin beat Scala in this virtual programming language traction game. I don't write code for the JVM anymore, but Kotlin occupies the same space as Scala. If you look at the graph in the post, it didn't; Scala is substantially more popular. Kotlin is just at a different point in the hype cycle.
That's incorrect. Scala had 13 years to achieve something while Kotlin is only around for a few years. If you extrapolate the current trends you will see that Kotlin will surpass Scala __very__ soon.
Earlier quoted context omitted.
Scala is much more complex language. Kotlin is more complex, than Java, but its complexity is just enough to cover major Java pain points. Scala brings its own huge library with features that I don't need. Billions of abstract collections, but all I need is HashMap and ArrayList. They generalize over builders, so `filter` can return some fancy underlying class, but all I need for filter is to return ArrayList or lazy…
>"Kotlin is more complex, than Java, but its complexity is just enough to cover major Java pain points." Would you mind elaborating on what those Java pain points are that Kotlin smoothes over? Also are people deploying Kotlin on the server side or do you see that being a thing in the future? For some reason I have this(perhaps incorrect) association Kotlin only in the context of Android. But maybe that's incorrect?
1. Explicit semantics for nullable variables. It helps to convey information whether this function can accept or return null and compiler checks that your code won't throw NullPointerException. It's not ideal when you're dealing with Java code, but it works.
2. Explicit and convenient semantics for mutable and immutable variables. You can use `final` in Java for variables or parameters, but few people do that, because code becomes quite verbose. With Kotlin you are using `val` or `var`, so code doesn't become more verbose.
3. Almost everything is an expression. Helps to write concise code sometimes and makes a language more consistent.
4. Compiler changes type of variable when developer checks for this type. So you don't have to write nonsense like `if (a instanceof String) f((String) a)`, instead you write `if (a is String) f(a)`.
5. Better replacement for `switch` statement. Kotlin's `when` statement has more features. Not a proper pattern-matching, though.
6. Default values for function parameters. With Java you have to write lot of function overloads with slightly different set of parameters and delegate it to a single function. With Kotlin you're writing one function with optional parameters.
7. Named arguments. Sometimes it leads to much more readable code.
8. Generic parameters can be covariant or contravariant. Basically you can assign `List` to variable of type `List`. It helps sometimes.
9. Operator overloading. `a + b` instead of `a.plus(b)`; `m["x"]` instead of `m.get("x")`. Code looks much more natural, when used appropriately.
10. Singletons. Kotlin doesn't have static classes, instead it has `object`s, which are implementation of singleton pattern. They can implement interfaces, for example.
11. Proper properties. getter/setters generated automatically, property access looks like field access, but with all perks the methods have.
12. No need for artificial utility classes, which are not really a classes, but just a bunch of static methods. You can either use plain functions at top-level or enhance existing classes with utility methods. `str.isBlank()` instead of `StringUtils.isBlank(str)`, for example.
Generally Kotlin is much less verbose than Java, but it's concise enough and doesn't try to be implicit or magical.
> Also are people deploying Kotlin on the server side or do you see that being a thing in the future? For some reason I have this(perhaps incorrect) association Kotlin only in the context of Android. But maybe that's incorrect?
According to Kotlin developers their user base was roughly 50% : 50% between server side and Android. I used Kotlin for small server side projects, it works almost flawlessly with standard Java frameworks like Spring or Hibernate.
Earlier quoted context omitted.
> I wonder why Kotlin beat Scala in this virtual programming language traction game. I don't write code for the JVM anymore, but Kotlin occupies the same space as Scala. If you look at the graph in the post, it didn't; Scala is substantially more popular. Kotlin is just at a different point in the hype cycle.
That's incorrect. Scala had 13 years to achieve something while Kotlin is only around for a few years. If you extrapolate the current trends you will see that Kotlin will surpass Scala __very__ soon.
(There's plenty I don't like about Scala qua Scala, but I don't see it ever being displaced by a language that lacks HKT. Kotlin has some good aspects to its design, but the anti-intellectual hostility to good formalisms and refusal to learn anything from Scala's mistakes rubs me the wrong way)
If the language designers keep their heads, Kotlin will slowly eat away at Java. Java itself is never going away: it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. Xtend never was alive, and it's clear Ceylon has lost at this point, even though it is arguably better designed than Kotlin. However, they made some bad syntactic decisions (not shedding enough of the Java verbosity,…
>Scala's big trump card is the Java library ecosystem. Much of which is awkward to operate with because of Scala's own collection library. One of the main reasons Kotlin is so much easier to use.
> I started developing in Java, late 2001. At that time, Java was really cool. As someone who was there in 2001, I just have to say: Java was never cool, and especially not at that time. It was bloated and ugly and slow, the GC was terrible, applets were simply the worst, the UI toolkits available looked horrible on every single platform. There were no decent IDEs or editors and the language was if possible even more…
Java was cool when I started using it "in anger" in 1995. It was going to be a totally new way of delivering software on the fly over the network (that's why all the package names look like reverse domain names). I moved to Python when Java gave up on the dream and became the new COBOL after the dotcom crash.