I haven't worked with Android or Java that much, but I tried out Kotlin a few months ago, and my impression was that it takes Java from several steps behind C# to several steps ahead as far as being a high-quality, efficient strongly-typed language. I also liked how simple it seemed to be to get it going on Android.
The only downside is that it seems to be immature and not very widely adopted yet, but at least it has a strong backer in Jetbrains.
I would like to hear what people with more experience in the Java world think of it versus other alternate JVM languages.
It feels to me like a better Java, but still very limited compared to Scala. It stays very much in Java's paradigm.
So while Scala doesn't have to fear Java's evolutions, Kotlin seems to be risking obsolescence when Java gets good enough - and it's already happening with Java 8. Just look at the article: they talk about Kotlin as a good language for people stuck with Java 6.
Java functions are still not first class. The headline feature of Java 8 was lambda function, which arguably isn't first class either (they are implemented as instances of object subtype, so essentially still is object nonetheless)
First class functions mean you can define functions outside of classes. Java 8 does not have any such feature.
Kotlin has quite a lot of hidden treasures in it, typically at the intersection points of several features. People who think of it as a better Java, or something Java can easily catch up with, should take a closer look.
Technically first class functions means functions can be treated like objects and passed around like any object (for example, python).
That said, I agree with you that Java does not have first class functions. They have something tacked on that is nowhere as elegant and lacks full support.
On the other hand, not every language that lets you define functions outside of classes lets you treat them like objects. C for example is generally not considered a language with true first class functions because it doesn't allow passing nested ones without additional support within the chosen complier.
Alright, in that case Kotlin has that other sense of first class functions as well. You can get a function typed object that supports the invoke operator, amongst other things.
Kotlin can inline lambdas (sometimes), which matters a lot on Android. For example there is no over head to writing your code so that it uses map and a lambda to writing a native loop.
In addition, because the code is inlined it can use the actual type of generic arguments. Not sure when that is useful.
Arguably they got the 20% of features that provide 90% of the value. It depends on whether you're looking at Scala from the perspective of "a better Java" or "Haskell for the JVM".
Not sure I get your point. I would both prefer a language which either had 20% of the futures and 20% of the cost, or 100% of the futures and 100% of the cost.
In Kotlin you get stuff like extension methods, which bear almost all the costs of implicit values, but don't support most use-cases you would use implicit classes for.
Extension methods vs implicits is one of those things that people seem to really like about Kotlin, on the balance of comments I've read. For instance because they are more predictable, higher performance, implicits are apparently a leading source of Scala compiler slowness, because to fix the issues with implicits you end up needing what Scala calls value types (but which have so many restrictions, they're more like type aliases than actual value types), etc.
- Implicit resolution can be slow, because you can make the compiler do arbitrary work for you. This is completely unrelated to implicit classes themselves.
- Scala had the option to either not ship value types at all, or support only a limited subset of things that can be made work well under the current restrictions. If Scala didn't ship value types, the JVM would have probably never gotten them. You can thank Scala developers later for dragging Java people into the 1990ies.
- Extension methods looks totally cool on paper, but are pretty much useless for writing maintainable, readable code, which also does something useful:
Dev: "Ok, I want to be able to use String as if it
was a collection of chars."
Kotlin: "Sure, just implement all the collection methods
one-by-one."
Dev: "But, but ... all implementations I need are
already implemented in that trait over there?"
Kotlin: "Bad luck, I guess. You could of course just
delegate all your methods to that trait."
Dev: "But then I would need to create a real instance
of that trait first which implements the missing
abstract method ... that's more boilerplate than
just copy-and-pasting the code?"
Kotlin: "Yeah, you have to decide whether to write a
short implementation on your own or pay the
price for sharing common pieces of code."
Dev: "... <much later> ... ok, I now implemented all
all the methods of the collection interface of
my own ... I guess ... the compiler will warn me
if I forgot to implement a method from that
interface or messed up a signature, right?"
Kotlin: "No."
Dev: "I just tried passing my String to a method
expecting a collection ... it doesn't even
compile?"
Kotlin: "Just because you went to all the trouble to make
String act like a collection doesn't mean it's
supported as soon as abstraction enters the
picture."
Dev: "So I can write cute things like myString.map(...)
but as soon as map(...) is moved to a method,
I have to overload that method to accept both
Strings and collections?"
Kotlin: "You could also just write a
StringCollectionWrapper and wrap every String
in that when you need it."
Dev: "I guess the compiler will figure out when I need
to wrap it?"
Kotlin: "No, you have wrap it manually every single time."
Dev: "So extension methods are basically just syntax
for writing static methods in a nicer way?"
Kotlin: "Can you please stop asking questions while I
waste your time?"
"foo".asSequence() works fine. I understood your long hypothetical conversation: you want to avoid an intermediary method that returns a collection of chars. I just fail to see why anyone would care about this.
No, I don't think you understood it. There is a large qualitative gap between what you propose, and what Scala does:
In Scala, it is an _one_ time effort to make String act "like" collections, while the only solution Kotlin provides means doing the work manually _n_ times: At every call site of the string in question.
That file contains the definitions of asList and asSequence, for example. If you're saying "but look at the other methods", that's not very convincing to me either because honestly I don't think having a fold method directly on String is very useful - if they scrapped a lot of those extension methods I'd be totally OK with that.
At any rate, you never addressed the core point I raised. Saying "implicit resolution isn't related to implicit classes" doesn't seem very convincing. If solving that issue was so easy then why is the use of implicits so frequently identified as a performance issue for tools?
The key point is that Android will never be on par with the latest version of Java. Scala has a lot of great features but its size and the learning curve is bigger than Kotlin. It's easier to start right now to develop with Kotlin instead Scala.
No, that was the first argument – android will soon be 3 versions behind Java, it already is using Java 6 compiled for Java 5 bytecode. The distance is getting worse with every day.
It also supports a couple of Java 7 features... but... I totally agree with your point here.
This far past the Oracle lawsuit and the increasing divergence between "real Java" and "Android Java", it is actually kind of bizarre Google hasn't really presented any kind of useful guidance on what they plan to do moving forward (unless their plan is actually to just keep limping along with a gimped Java implementation indefinately).
It is hard not to look at things like Swift and wish Google would make a similar push to update the "offical" Android language. Technically speaking, Kotlin is a great alternative, but without the sort of official blessing Swift has coming from Apple, for most developers it will be politically very difficult to get by the inertia that appears when suggesting you use a "non-standard" language, regardless of how interoperable it is technically.
Outside of really lean startups you might as well be asking to write your app in brainfuck if it isn't going to be in Java.
> It feels to me like a better Java, but still very limited compared to Scala. It stays very much in Java's paradigm.
You've basically summarized Kotlin's design goals. Java was designed to be a simple language for widespread use, hiding an extremely powerful runtime beneath it. The very first paragraph describing its design reads[1]:
Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea.
So: 1/ not PhD thesis material, 2/ familiar, 3/ adopt tried-and-true solutions.
Scala's design is the exact opposite of each and every one of these goals, but Kotlin tries very much to follow them. As such, they are very different languages (even though they share many features) because they are guided by opposite philosophies, and are therefore meant for completely different audiences. Kotlin aims to be exactly what Java would have been if it had been designed today; Scala aims to be something completely different.
I'm a Scala developer and personally I believe that such claims are unwarranted, mostly coming from beginners with a superficial understanding of the language. Not only is Scala not a kitchen sink, but it actually cuts down on Java features that were a bad idea.
This misunderstanding mostly happens because some people start learning Scala in the hope of finding a better Java. But Scala is not a Java++, but something else entirely, being the kind of language that makes sense outside the boundaries of the JVM.
As a piece of advice, if you aren't interested in trolling, you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. That way, in case you have a point, then other people or even Scala's or Kotlin's language designers can learn from your feedback. And if you don't have a point, then you might get some useful piece of advice.
On Kotlin - I don't like that it doesn't diverge enough. This is because when picking a non-mainstream language, you lose the advantages of mainstream languages, like easily available documentation, copy/paste-able samples, big developers pool, etc, etc... so the advantages of the non-mainstream language would better be worth it to balance the disadvantages ;-)
C++'s goal was to introduce a newly popular paradigm (oop) on top of an existing rich ecosystem (c). Scala's goal was to introduce a newly popular paradigm (fp) on top of an existing rich ecosystem (java). They both suffer from poor tooling, long compile times, and feature bloat with several predominant styles of writing it.
Yeah, both are programming languages. Objective-C was also built on top of C, with the same original purpose as C++, yet you couldn't find two other mainstream languages that differ so much.
I can't really answer to your argument because it is superficial and there isn't anything in there to answer to. Whenever I ask folks what makes Scala complex or bloated, or what the conflicting "styles of writing it" are there, they always shy away. Because it's easier to be handwavy than it is to construct a good argument.
Unfortunately handwavy arguments are subject to marketing and social forces. This is how people end up worshiping Python's spirit and included batteries, which must be some of the biggest lies in our industry, since I can name more non-orthogonal and half-baked features in Python than in Scala, plus several clusterfucks in its standard library and ecosystem, starting from the build management tools, the async-I/O libraries and the web libraries, all of them screaming anything else but "there is only one way to do it". But that's just the herd mentality in action.
On Objective-C: yes, it's quite different from C++; that's because it took a very different approach to integrating object oriented programming into C, and because it had a much more traditional (at the time) model of what object oriented programming was. Essentially, Objective-C adds a completely new language for object oriented code, one which has a very good zero-overhead C FFI and one which happens to be source compatible with C. C++ really tries to make one cohesive language, so that you don't have that dichotomy (although it doesn't always succeed when it comes to templates).
Yes, Scala isn't exactly the C++ formula applied to java and functional programming; it doesn't, for example, strive for source compatability (C++ has to because of header files, it likely wouldn't otherwise).
Whenever I ask folks what makes Scala complex or bloated, or what the conflicting "styles of writing it" are there, they always shy away.
I don't think there's a good way to identify concrete examples for "bloatedness" because it's kind of a fundamentally handwavy concept. It's a feeling that you get while learning and using the language. One that people don't get with C, or Go, or Haskell or Scheme, but tend to get with Scala and C++ and Common Lisp, to name examples.
Complexity is easier to point to though. The interaction of inheritance and generics, the mutability semantics, the fact that it's not clear from the call site when arguments get evaluated (with defered evaluation and macros), anything that can result from an abuse of implicits, mutability semantics.
The various styles of writing Scala? Well there's the people who wanted to write Haskell but settled for Scala because it's what their bosses gave them, who write it with a lot of immutability and use the type system to a great extent. There's the people who wanted to write java but write Scala because their bosses make them, who write java in Scala because that's a totally viable way to do it. And there's a lot of people in the middle.
Addressing your python point: I agree that the "there's only one way to do it" mantra is kind of wrong in pythonland, but there are a lot of conventions in that community that people adhere to that make it true in a way. This comes with a lot of dogma unfortunately. Other languages have fewer "non-orthogonal and half-baked" features. Go, for all its issues, doesn't have many of those because it seems its designers are content to just not have the features at all rather than have them be imperfect. C doesn't either, really, nor Haskell.
Regarding C++ having poor tooling: care to elaborate a little? Just one or two specific examples.
I know the grammar is really difficult to parse and that has hindered static analyzers in the past, for example, but what else are you talking about? Also, how good or bad is clang's static analyzer compared to those of other languages?
> you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable.
Sure, I could name things that I don't like but they will be by definition non falsifiable as well, so I don't really see the point of what you're asking.
Overall, I just find the surface area of Scala way, way too big. I felt the same way about C++ compared to C in the 90s, hence my comparison. I've used Scala for five years and over that period of time, I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools.
I'm still stuck with Scala at work but I'm really hoping Kotlin takes off because using it on my personal projects has been a breath of fresh air compared to Scala. It's like getting 90% of the power of Scala with 5% of the cognitive load.
Here's the reason for why I asked. You're saying that:
> I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools
Well, Scala 2.11 hasn't added any features, being a release meant for stabilizing, modularizing and optimizing the compiler and the library, fixing many non-withstanding issues. So zero new features.
Scala 2.10, released Jan/04-2013 (2 and a half years ago, OK?), was the release that added some features which included Value Classes / Implicit Classes (they are linked, for providing extension methods, as a refinement of implicit conversions), String interpolation (any sane language has it, plus Scala can now deprecate the conversion to String that was imported from Java), plus macros as experimental. Besides macros, everything else is minor and macros are meant for library authors as a neater way of building compiler plugins.
Scala 2.9, released May/12-2011, only includes changes to the standard library and not the language.
Scala 2.8, released Jul/14-2010 (5 years ago), introduced named and default arguments, package objects, changes to implicits, type constructor inference and a completely redesigned collections library. This release was so big for its users that it should have been called Scala 3. Before Scala 2.8 the language wasn't suitable for usage and Scala 2.11 is pretty much the same language as Scala 2.8.
So I'm really wondering what "feature after feature" you're referring to. Really, take other programming languages that aren't Java and compare the features added in the last 5 years to Scala's history. You'll have a surprise ;-)
Also IntelliJ IDEA is pretty awesome for Scala, I've been using it for the last 3 years. It's worse than IntelliJ IDEA for Java, but it is better than Eclipse for Java or Visual Studio for C#. There's also Scala IDE (built on top of Eclipse) and Ensime (a pretty capable Emacs / Atom / SublimeText plugin). Other platforms can only dream of such support, including Kotlin, or C# for that matter. I'm not joking.
> Sure, I could name things that I don't like
So why don't you name those things that you don't like?
Personally I'm not having discussions about Scala with the purpose of winning arguments, but rather with the purpose of clearing misunderstandings and this goes both ways.
The "_" character is a placeholder for things that can be named, but for which you don't care about that name. And because you don't care about the name, it can function as a wildcard (i.e. any). To me all use-cases of the underscore make perfect sense and I can't remember a single instance in which I was confused by its meaning.
Type lambdas are arcane, but as @lmm points out, this is more about the absence of a feature. Basically in Scala type lambdas do not have first class support and so they are based on Scala's abstract types.
As to why they don't have first class support? Well, because people complain about too many features ;-) But it's worth pointing out that the TypeLevel folks have plans to introduce first-class support in their fork and thus propose an improvement. And also, because of the work that happened in Dotty, Scala the language is heading towards a DOT calculus foundation, along with a unification of higher kinded types with abstract types, which should iron out the edge cases.
The curry syntax seems silly if you come from SML, Ocaml, Haskell or languages from the ML family in general. In such languages all functions have exactly one argument. But Scala is not an ML language and so it doesn't do currying by default. It's annoying sometimes, but as with all design choices there are disadvantages and benefits.
The type lambda syntax is arcane, but that's not a feature - indeed if anything it's the absence of a feature (would you favour explicit support for type lambdas, like the plugin does?). If you're complaining about the syntax of curried functions then again that's not a complaint about a feature; likewise _.
I'm not saying they aren't issues, but none of the things you mention is about Scala having "too many features".
It's not a language-level feature. It's a pattern that makes use of several features - type members, structural types, member selection. (You can often write these things more readably by splitting them onto two lines, putting the type alias in one place and the use of it in another, avoiding the need for the structural type and member selection). It's like the visitor pattern in a language that doesn't have pattern matching, or an explicit Y combinator in a language that doesn't have recursion.
Some newer languages have this kind of functionality (in Haskell it's a GHC extension, I think).
Scala's surface area isn't especially large though? Here's a list of Scala language-specific features I use & have to keep in my head on a daily basis:
- Case classes + sealed hierarchies (algebraic types, in other words)
- Implicit parameters
- Collections library
- Traits
- Function types, currying, partial application
- for-yield
- Pattern matching
None of those concepts on their own are especially complicated. In fact, I find Scala to have a bunch of orthogonal features that are easy to understand on their own and that compose in a variety of useful ways.
> Scala's surface area isn't especially large though?
You'll find plenty of disagreement with that feeling everywhere you ask...
The fact that you choose to use a small subset of all these features is irrelevant: eventually, you have to hold all the language in your head because you will work with other people and other organizations that have different standards than you do.
Which is why it's so important for a language to learn how to say "no" to new features, something I feel Scala has been unable to do.
What other features could someone even reasonably use though? I say this because what I listed above isn't some small subset of Scala. It's actually the majority of the language.
Hmm I'll try to think of some features that we don't use at work that would add additional semantic overhead:
- Inheritance? I mean okay but nobody I work with makes heavy use of this anyways and if I were working in a Scala shop where inheritance was used heavily it would be like working in a different language. So I suppose I'll give you that although I don't see how that makes the language hard to learn or work with.
- Mutable collections + references (vars)? Once again nobody I work with uses these outside of local mutability when they fail to be able to leverage immutable abstractions that do the same thing. If I worked in a Scala shop where mutability was used without care, it would be like working in a different language entirely true.
- while loops? I don't know what else I'm grasping for straws here.
If anything, the additional 'complicated' things we use in Scala aren't language features but rather libraries, mostly scalaz/shapeless.
> If anything, the additional 'complicated' things we use in Scala aren't language features but rather libraries
One thing with Scala is that various features of the language allow libraries to reshape the "feel" of the language, because a number of things that would be fixed in the language in many other languages can be modified by libraries in Scala.
Consider that whilst Kotlin does not support things like function currying and partial application out of the box, they can both be added by a library (funktionale). Kotlin has a focus on DSLs defined in libraries and has a few language features that are intended to make them work better, in this sense, Kotlin and Scala are similar.
Right, but by comparison Scala goes further than Kotlin on this. Consider the case of operators, for instance: Kotlin, like many languages, lets you redefined a predefined set of operators for new types with predefined precedence, Scala lets you create entirely new operators.
To some, this is a strength for Scala -- to others, it is a weakness.
Also IDE support in Scala is pretty much fine. Have you used it lately? IntelliJ is able to handle my code fine in almost all cases, and I make heavy use of scalaz and occasionally what Scala has for dependent types. The only problems I ever run into are IntelliJ sometimes telling me I don't use an import for a typeclass instance that I am definitely using.
I love Scala but the Intellij support is lacking in that it can't always find the right import to auto-import and I have to manually add it myself. I think it comes down to the fact that it takes the compiler a lot of cpu cycles to figure out what's actually in scope with implicits, etc. I soldier through it, but it can be annoying when I have to go hunting around for the import.
IntelliJ IDEA's auto-import works fine for normal imports. But it cannot guess what implicits you need imported in scope any more than the compiler can.
The only implicit (I can think of) from the standard library that needs to be explicitly imported is ExecutionContext.Implicits.global. It's a form of dependency injection meant for working with Future and the error message tells you exactly what to do, but it can't be automatically imported because the thread-pool used is a pretty big deal and you should pause for a second to think about it. Other than that, the implicits you need are probably your own doing, because common libraries usually have a design where you get everything needed with sensible defaults.
In other words, if it's painful to import, then you should probably rethink it. This is actually a very good rule for Java as well. People too often rely on IDEs to do the boring parts, not noticing the stench until it is too late.
As said on http://www.scala-lang.org/api/2.11.7/index.html#scala.concur... the default global should not be imported all over the place. It's better to declare functions with an implicit ExecutionContext and try to declare your execution contexts in a few well-known places.
The (web) app I'm working on uses several ExecutionContexts (database access has a specific one for example.)
I'm not really sure how to interpret that. To you, what's the negative aspect of a feature? If features are things to avoid, what's the benefit of Kotlin over something with less features, like Java 6?
Feature is not a good thing per se. A presence of feature is a cost the makers and the users pay to be able to do something efficiently.
Good design has the smallest number of features making the greatest amount of things efficiently possible. Scheme and Forth are brilliant designs by this metric, Haskell, Python, and Go good ones, while C++ and Scala, well, not so much, frankly. BTW, Odersky himself admits it.
Have to step in here :-). In fact I bet that Scala has fewer features than Kotlin. In retrospect I now think Scala could have had fewer features, and hope we can get to a state where we can remove some of the redundant ones. But that's because (1) hindsight is always easy and (2) I am at heart a minimalist. Almost all programming languages have too many features to my taste.
But Scala design is exactly that. In fact I'd bet that Kotlin has more features than Scala does, because it often has about five separate features to cover the use cases that Scala does with one feature like implicits.
If the cost is less than the benefit, aren't we overall in a better place? Can't some people value the gain in efficiency, or whatever else the feature provides more than the cost? This sounds suspiciously subjective, regardless of how many people assert that many features is a bad thing, or that it's a metric of "good design" and then list a few languages categorized fairly arbitrarily, IMO.
It's perfectly fine to have an opinion, but it shouldn't be stated as fact without any substantiation (as in the GP) or with evidence consisting entirely of subjective elements unless those elements are further explored and explained in less subjective term (using "good language design" as evidence does not count as less subjective).
> BTW, Odersky himself admits it.
Was I supposed to know who that was referencing prior to googling? I'm not sticking up for Scala, I'm interested in exploring the concept of too many features as a negative in language design.
> If the cost is less than the benefit, aren't we overall in a better place? Can't some people value the gain in efficiency, or whatever else the feature provides more than the cost?
If you work alone, you're right. Problems start when working in a team. The average lifetime of a codebase is about a decade, in which time it is read and touched by many hands, and falls under several management administrations. We know that languages that are too feature-rich can prove troublesome under these conditions.
> sounds suspiciously subjective
Of course its's subjective -- like many things that have to do with the choice of languages -- but unlike many other debates, we actually have some very good data on this: C++. For a few years, C++ was considered a blessing. Expressive, sophisticated, powerful. But after a few years, as codebases started to mature, the industry as a whole discovered that maintaining C++ codebases is a nightmare. Every team had its own style and its own subset of features it chose to use. Some features (like operator overloading and esp. cast and assignment operators) while useful, ended up making long-lasting, large-project collaboration extremely costly. Java's design was very much a reaction to C++, eliminating features right and left, and declaring from the get-go that it aims to be less expressive and more verbose. It worked. The question now is whether any new "rich" language would share C++'s troubles or not, and that is indeed subjective (so far). But at least we know that sometimes a combination of too many features can be really bad, especially when working in large teams.
BTW, today C++ is quite effective because it's become a (relative) niche language (even according to its creator). Niche languages are used by specialized teams that are good at enforcing discipline, and/or tend to be smaller.
I suspect there are several interpretations of "feature" being used in these discussions, and without someone being a bit more explicit in what they mean, I doubt much useful progress will be made.
I also think that complex languages may be harder for teams with high turnover or a lower average skill set within that language (and as such the average allowed complexity per expression may play a role in this). I went into some depth on this in a cousin thread[1], but my conclusion may not be quite the same as yours. Part (well, most actually) of my original question on this topic was to ask for clarification, because I thought the assertion was inherently ambiguous.
That said, if you have actual numbers or studies to bolster your statements about C++ I would love to see them. What you assert is a common refrain here, but I'm truly not sure how much of it is confirmation bias and squeaky wheel. There are plenty of C++ supporters as well as detractors, but I'm not sure how to sort through the noise here to get an accurate assessment of the landscape. Interestingly, my relative distance from C++ may actually help here since my own experiences may not sway me as much, but that might be entirely overshadowed by C++'s similarities and differences to other languages that I like or dislike in some aspect that I am more familiar with.
In the end, since it's not as simple as "less features us better, more features is worse" (otherwise we would all be writing assembly), I suspect there are a few other important axes of comparison that actually describe the situation better, and language features is a useful abstraction but only over a very short range of values, outside of which it becomes increasingly useless as a metric for how hard or easy it is to manage a codebase.
> BTW, today C++ is quite effective because it's become a (relative) niche language (even according to its creator). Niche languages are used by specialized teams that are good at enforcing discipline, and/or tend to be smaller.
Is it? I know there have been other systems eating into the market share for C++ for a while, but my impression has always been that it's still extremely popular in certain segments where there hasn't been much new competition for a while. E.g. high performance computation, cutting edge/AAA games, etc.
> if you have actual numbers or studies to bolster your statements about C++ I would love to see them.
Note that most real-world case studies were done in the late '90s-early '00s so they are not that easy to find. A quick Google search, however, came up with this[1].
> There are plenty of C++ supporters as well as detractors
It's not about C++ supporters and detractors today. It is an undisputed fact is that the industry as a whole abandoned C++ (except for its relevant niches) and practically no one has looked back.
> In the end, since it's not as simple as "less features us better, more features is worse"
I'm not saying it is simple. I am saying that we have one experiment with conclusive results. Perhaps there are other variables, but given the strength of the results, the burden of proof -- IMO -- lies with those who claim that their super-feature-rich language will not meet the same fate.
> it's still extremely popular in certain segments
It is, and those are its niches. They form a largeish share of the market, but not anywhere as large as the segments that used C++ in the 90s or the segments that use, say, Java today. It is most certainly no longer a general-purpose cross-market industry-wide language.
> the burden of proof -- IMO -- lies with those who claim that their super-feature-rich language will not meet the same fate.
All you are doing is reducing the discussion to something so hand-wavey that it can't be argued anymore. I'm interested in how much is too much and what type of features increase tihs load. I assert that some features don't increase errors, but in fact decrease them (e.g. Java's automatic memory management), and if that's true, than the statement "more features is worse than less features" is trivially proven false. Is it really that hard to move the argument beyond the simplistic point of view that "features" are the problem?
Automatic memory management is what's known as an extra-linguistic feature. Those usually reduce complexity (JITs do the same, as they allow very efficient compilation while introducing different dispatch kinds -- static vs. virtual -- with different performance). I was talking about language-level abstractions. For example overloading, operator overloading, having both subtyping and explicit sum-types, etc..
It is handwavy because designing languages is an art, but usually providing too many ways to achieve the same thing or allowing code that hides its operation (or appears to violate the "normal" language semantics while looking innocuous) is, in general, bad (for large teams), as it hinders readability. Of course, things need to be balanced, and you have to consider what kind of projects the language is for, what would be the "average" code size, etc..
> I was talking about language-level abstractions.
And I've been trying to get people to at least define what they are talking about in every single comment I made. Kudos to you for doing so. :)
> Automatic memory management is what's known as an extra-linguistic feature.
While that makes your position easier to support (but it's not what the original comment stated, which is why I asked for clarification from them), I'm not sure I buy it entirely. I need an explanation why a language with more language level abstractions is worse than one with less, given that you can enforce the restriction of some abstractions. Why is artificially limiting yourself the better solution than enforcing restraint, which leaves the possibility to work outside those constraints when the conditions are correct?
Because what C++ has taught us that it's impossible to enforce restraint in a serious project[1], because the people enforcing the discipline change. The discipline enforced by you is different from that enforced by the team-lead to follow you, and by then the codebase lacks any discipline. That was exactly C++'s lesson, which is why people are weary of languages that say, "all you need is a bit of discipline".
[1]: This is less true of C++ today, when it's mostly a specialist language used by specialist teams working in fields that have always required a lot of restraint. They know how to do restraints (well, at least better than the industry at large).
> Because what C++ has taught us that it's impossible to enforce restraint in a serious project[1], because the people enforcing the discipline change.
So? the language's themselves change over the time frame you are looking at. You seem to be arguing that having the language enforce it is better than policy, but name one language that's seen any serious use that hasn't seen change to add new features over the last then years, of the exact sort you are saying cause problems. So we're supposed to entrust this to a third party that really doesn't care about our specific needs. The Java standards committee doesn't know who you are. And if they do, you are not a representative case of the vast majority of Java programmers. I would rather control my future, so I choose freedom with restraint.
I'm really not buying your C++ is niche argument. C++ is one of the top 3-5 languages in the world in every metric. Java is more popular, but not being the most popular has nothing to do with being niche. C++ is still in massive use in almost every industry. That is not niche. Using C++ as your go-to example and basing your argument on having lost so much market share as to be a niche language isn't really moving the discussion along. Shops switched to Java from many languages, not just C++, and for many reasons, not just because C++ features caused problems. That argument is far too simplistic and ignores far too many things for me to give it much credence.
> I'm really not buying your C++ is niche argument. C++ is one of the top 3-5 languages in the world in every metric.
If you see how Bjarne Stroustrup[1] describes C++ today, you'll probably agree that it's a niche language (he sees it that way today).
> That argument is far too simplistic and ignores far too many things for me to give it much credence.
Of course. But ignore it at your peril. If you want to use a language that is similar to C++ in many respects (many of the same respects that the industry complained about), you should at least acknowledge the risk and try to be damn sure that this is what you want or be sure that this wasn't a contributing factor to C++'s fall from dominance.
> I know there have been other systems eating into the market share for C++ for a while, but my impression has always been that it's still extremely popular in certain segments where there hasn't been much new competition for a while.
"Extremely popular in certain segments" is typical of "niche languages" -- those segments are its niche(s).
Yes, but "eating into the market share" doesn't necessarily mean it isn't still a heavy contender. I think we can agree that while Internet Explorer has been losing market share for quite a long while, you can't classify it as niche. In that respect, my original statement regarding it dominating some industries and your reply don't really affect the answer to the question of whether or not it's a relatively niche language. The blame is mostly mine though since you were responding to something I put forth that wasn't really relevant.
> Fine, but C++'s "niche" is larger than all but maybe four other language's total market share. So the word "niche" doesn't really fit very well...
If the niche is well-defined, the size doesn't really matter in many respects, because its effectively a completely different market, and it doesn't matter whether that markets large or small in terms of what goes on outside that market.
> In the end, since it's not as simple as "less features us better, more features is worse" (otherwise we would all be writing assembly)...
Arguably, assembly is the most feature-full language - everything is possible. But those features are very expensive, which is why it's only used where there is no alternative.
Well, in that respect, every turing complete language is at feature parity, but I think the meaning of "feature" here for most people (I still think there's a few specific differences in people's interpretations) is "language construct making hard, complex to program construct or methodology more easily expressed through language level support."
That is, both C and Perl can implement Hash data objects, but C requires a library or implementation, and Perl makes it a core data type of the language.
No, assembly is more than turing complete. On many CPUs, you get instructions like "enter supervisor mode" or "flush the data caches" or "change the interrupt mask", which aren't part of the definition of a turing machine. (I know, floating-point multiplication isn't, either, but you're going to have to be able to do at least some kinds of arithmetic to implement a turing machine, whereas supervisor mode is completely outside the spec.)
And C, Java, Perl, etc, also don't have anything like "enter supervisor mode". But if the CPU supports it, assembly will let you do it.
Again, that depends entirely on how you define "feature". If the feature in question is "easy use of hashes as a built in data type" assembly doesn't have it. Yes, you can implement hashes in assembly, the the feature as outlined is not something you can ascribe to assembly. Additionally, assembly has a few features that are not replicated in most languages (but not all, some languages allow inlining assembly). So they are often just partially overlapping sets.
The reason Scala has so many features is that it chooses to be 100% compatible with Java, which means it needs to be a superset of Java. Benefit greater than cost? Many would say that.
> The reason Scala has so many features is that it chooses to be 100% compatible with Java,
Not sure what you mean, the ABI compatibility doesn't require any feature to work. Does Scala support higher kinded types to be compatible with Java? This does not make sense to me.
Scala is stack-compatible with Java. You can call any Java function from Scala and vice versa. Additionally, for ease of migration, any valid Java class is a valid Scala class. The Scala standard library includes the Java standard library copy-pasted in.
For the sentence "Scala is compatible with Java", there is almost no interpretation of "compatible" that would make the sentence untrue.
It's not readily apparent to me how a feature necessitates that a guarantee can no longer be kept. In fact, one feature of a language might be an additional guarantee about some aspect of it's function (e.g. Rust and it's memory ownership feature).
Cars and airplanes are things, not features. The ability to drive on roads and the ability fly don't necessarily entail the downsides of a car or of an airplane.
I'm honestly wondering what the reasoning is behind the dislike of too many features, and how people justify the "right" amount of features. I can think of at least one argument against too many features, and that's managing what features a team should use in production, but there are solutions to that and I think that's a weak argument for the original assertion, which was entirely unsubstantiated.
I haven't used C++ or Java in over a decade, and I've never used Scala, so I don't have a horse in this race, but vague assertions deserve substantiation.
For me, language design is a balance between being expressive and being readable. Coders love the ability to concisely express nuance and therefore gravitate towards expressive languages, but there's a hidden cost that most underestimate. And that cost is paid by all the readers of the code that do not share the same style and context of the author. Note that this includes the original author when they're revisiting code they haven't touched in months. Most modern languages can be seen to be somewhere on that continuum between expressive and readable.
Languages like Go fall completely on the side of readable. I found that in my first few hours of Go, I could easily read through all the code that I found online and found it incredibly easy to reason about. But, as you'll hear time and again in critiques of the language, there's a lot of boilerplate that makes things explicit and many programmers dislike the lack of expressiveness.
Which brings me to Scala. Scala is on the entirely opposite end of the spectrum. When I first dove into Scala, I was constantly having to look up language constructs to understand the code that I was reading. And, worse yet, there was often no keyword or other indicator to tell me which feature was being used. In short, it was a nightmare to learn to read. But I'm sure the author loved it. S/he could express what s/he wanted from the computer in a few short lines that were entirely comprehensible to h[er|im].
My own personal view is that it's a right tool for the job situation. I think Go is a great language for large teams with high turnover. The fact that you could onboard a new Go developer and s/he would be able to read everything in your codebase and start contributing on day 1 is a huge plus. But if you've got a small, cohesive team that can agree on the subset of Scala features and overall patterns to use when developing, Scala could be a good choice since it would allow the team to move very quickly. There's a cost to both and it's important to consider when choosing a language. The main difference is that people too often evaluate the cost of a language based on their experience writing it rather than reading it.
I understand and agree with your point, but have always cast it in a slightly different light. I think some languages having longer or steeper learning curves than others, but when used effectively this can allow the language to be more expressive and efficient in developer time for both writing and reading. It's analogous to the communication in a field between an expert and novice, or between two experts. The experts can rely on their shared experience to succinctly explain a concept, which the novice requires detailed explanations for. This makes communication between experts highly efficient, but requires a lot of investment to get to that level of expertise.
I find programming languages follow the same rules, but often you are communicating with yourself (sometimes time shifted by minutes, hours or days). If you are an expert in a language that allows complex concepts to be defined concisely, you can use those idiomatic constructs to express your intent and another expert may easily grasp that intent, but a novice may find that much harder to comprehend. Conversely, a language that does not allow complex concepts to be expressed concisely will be easier for a novice to understand, but there is an inherent loss in efficiency for experts in that language that must resort to continuously defining complex concepts with the simpler concepts the language supports (boilerplate, in this case).
Neither type of language is inherently better than the other (as much as people like to assume so), they are just trade-offs that have different benefits and drawbacks based on the people or teams that use them. A team with low turnover and high experience could benefit greatly from the long-term use of a language that supports higher level concepts succinctly, while a a team with lower expertise or high turnover might find that extends the learning period of new hires. It's fairly easy to point out languages that have chosen one path over the other, such as Java and Haskell. I think an interesting case is Perl, which supports both, and I think that's a large source of the idea that Perl code is unreadable. It's made to be easy enough to understand in many cases at first glance, while also supporting a lot of higher level concepts. This can cause people that use it to experience very different levels of complexity in close proximity, which can be jarring for the novice, and sometimes the competent user as well.
Java will never get good enough - for one it will always have checked exceptions and undesirable casting syntax, not to mention no native getters/setters.
As somebody working all day with java in Android's context, Kotlin seems to pretty much address all my gripes with Java (again, java for Android, so no java 8 or 9 here).
The only issue is that the Android framework code is still written in java, so it might not be that useful for the parts of an app that are deeply embedded in the android framework.
I really hope that the google people take notice of Kotlin and decide to adopt it.
Judging from the public commits in AOSP, java 8 & 9 seems to be the current official focus, but there is no way to know what is going on under wraps.
> The only issue is that the Android framework code is still written in java, so it might not be that useful for the parts of an app that are deeply embedded in the android framework.
Kotlin promises 100% interoperability with Java, and Android appears to be a particular area of focus (Android Studio is based on Jetbrain's product, and Jetbrains makes Kotlin).
it is indeed. Kotlin has gained some popularity among Android devs and is focusing on it.
Still, it is hard to use all of Kotlin's features when you have to dialog with a java framework.
So eg for UI code, you might end up with quasi-java code.
I would still love to see Kotlin pushed as the platform's language or alternatively a Rust inspired language.
Another big challenge of such a move would be the back compatibility story.
Check out Anko. It's a good demo of how to use Kotlin's features to extend native Java frameworks. For instance you can define the UI using a Kotlin DSL rather than XML.
yeah, I have checked that out.
As much as I dislike xml, I don't think I want to place my layouts in my code though.
From what I have seen, Anko's answer to how to handle buckets is 'just do it by code'. I need to see how it works for very complex layouts.
I have written several very complex UIs that I don't think would be expressed easily with Anko.
Again, I should really have a try, it seems to bring some niceties that I would have to write custom ViewGroup code to do with the base framework.
However my argument had more to do with the Android's API surface area than the UI in particular.
How much does having to deal with a pure java API for something like Chromecast (again, insert any android API instead) hampers Kotlin code style ?
Now that I know that, Kotlin looks pretty cool! It proposes solutions to a lot of the most painful problems in Java.
I'm not sure the solutions are always correct, though. When I hear "null safety", I think "pattern matching on a Maybe sum type to statically ensure non-nullness", but what the talk says Kotlin actually provides is pressuring you into writing a bunch of your code in the Maybe monad, thus spreading nullness far and wide. The talk example is "println(a?.length())".
Maybe that's the best pragmatic solution in Kotlin, or maybe the talk oversimplifies what Kotlin actually gives you, but it kind of seems like the wrong direction to go in to me (most of the time!)
I think the point isn't the Maybe stuff - Int? - but the non-nullable reference types. In conventional Java, every reference type is always nullable, so there's no way to strictly differentiate between things that couldn't possibly be null, and so don't need checking, and things that have a valid reason for being null, and should be checked and handled properly.
Kotlin allows non-nullable reference types, so you can declare a method as taking a non-nullable reference to an object. Now within that method, you know that reference is never null, and don't need to check it. When you call it, you have to either check for null beforehand, or pass something that is already guaranteed not to be null.
It's kind of like it builds a wall between things that could be null, and things that can't be, instead of having theoretical potential nulls all over your code. When you think about it, it seems like a pretty natural thing for a strongly-typed language to do.
I agree that non-nullable reference types are a big advantage. (People who haven't programmed in Java might underestimate how big a problem null pointers are in Java.)
> Adding to your Kotlin to your project is pretty easy as now you can just have it mixed in with Java classes. You’ll need to add the gradle plugin to your build script, apply the Kotlin Android plugin, add your source directories, and include the standard library.
Between Kotlin, Ceylon [1] and Xtend [2], all recent JVM languages that aspire to be an improved Java, which one would you bet to come out on top in the long run?
My answer to this question used to be Scala. It has orders of magnitude more traction (and is a much better language) than any of the options you mention.
The fact that it hasn't "happened yet" is a bit worrisome though. To the point that I honestly think the answer at this point is Java. It will never be awesome but it will get a bit better every year.
I believe a lot of the lack of adoption has to do with how hard it tends to be setting up the environment for Scala dev on Android. Whereas, Kotlin aims to make it as easy as possible by working hand in hand with Android Studio/IntelliJ.
Isn't it fairly easy to slim down the runtime at build time to only the methods you're using? I was under the impression that this was possible, though I've never actually done it so what do I know....
i'm loving sbt, but still on projects above > 100 dependencies it gets really really slow to download it, while with gradle (even i dislike it) it is way way faster.
This is probably SBT's greatest weakness and Gradle's biggest strength, relatively. I've never run in to this personally, probably because I'm use Nexus[1] as a repository cache. My understanding is that the underlying problem is a limitation of the dependency resolution library they use, Ivy[2]. Gradle used to use this but at some point wrote their own dependency resolution library. There are some improvements in recent versions of SBT but you have do a little configuration. See here[3] for more details.
I also thought of introducing Nexus, but since we are only 3 Devlopers (yet, we searching though) it didn't too much sense. I also I hoped for Nexus 3 (but since I'm waiting over half a year now, we might introduce Nexus 2).
Oh and we also using the Cache, when working on newer sbt projects.
This type of general conclusion isn't, by itself, particularly useful in discussion; a lot more useful would be presenting a summary of the specific facts and experiences that lead you to this conclusion.
sbt isn't very good for copy&paste build masters, which was pretty much all of us who had to setup Ant and Maven projects. It demands a certain amount of investment in learning its core concepts, but OMIGOD it's sooooo good once you know what you're doing. I've extracted so much common setup to hierarchies of plugins that I can setup our company's most common usecases for new projects in 3 or so lines of code.
Probably Scala (although I hope Kotlin makes some inroads too), but I don't think it will ever displace Java in a significant way. Scala, outliers aside, is well loved by it's users [1], but not everyone wants to spend the time to learn it. Java remains popular because it's the nobody got fired for picking it default, not because it's technically superior to Kotlin, Celon etc. The Java language has become one of the poorest choices on the JVM and is showing its age when compared to the alternatives. We ditched Java for Scala for most work. It's fantastic to work with once you've learned it, but it's not a path for everyone who doesn't have the inclination to spend the time learning.
IMO, as with every "who will win out" scenario, it usually depends on how well word gets out, who's backing and just basic "do I like this". That being said, I really like Kotlin and the fact that it can be used easily with Android Studio and IntelliJ means I'll be watching it closely (more closely than all the rest).
Personally, even though I like all 3 languages (ceylon, kotlin and scala - no experience with xtend) I came to appreciate the vision behind ceylon lately: the language is really well designed, with very few compromises.
A lot of people overlook ceylon because the language is just not promoted too well currently: even though the documentation is comprehensive, it's not focused on the features the programmers are interested about. And they need more target platforms, but they are already working on that.
if ceylon had better android support (codegen and tooling) i would start learning it immediately. kotlin seems like it's gotten that right; if it builds up enough momentum that there's a good third party ecosystem of android libraries i can see it doing very well in the future. it's design is not quite as nice as ceylon's, and it doesn't do as much as scala, but it's a very pleasant language to use and jetbrains has some really good tooling for it.
True, kotlin has the huge advantage that google switched to Intellij, and the team knew how to take advantage of this opportunity really well. It also helps that JetBrains is a much smaller company and with that, more focused on their core products.
As opposed to that, I assume it is much harder for the ceylon team to get the entire company to support them. For example, even though vert.x 2.0 had support for ceylon, it's not clear for me if that is also the case for vert.x 3.0, and even if it is, ceylon still isn't featured as a main language on their landing page.
But they are working on an Intellij plugin, which I think will be available in ceylon 1.2. And that is the first step towards Android support.
Last I checked, Xtend generates Java, so it's kind of a non starter.
A year ago, I would have put Kotlin and Ceylon on the same level in potential but Kotlin seems to have gained some momentum this past year. On the other hand, I barely hear about Ceylon, even though it's now approaching 1.1.
The big issue with Scala on Android is the size of the Scala runtime, which is around 5 MB. Kotlin's is about 900 KB if I recall correctly. I like to see it as a "mini" Scala for Android. Just like Scala, it's a pleasant language to write in.
Yes, you pretty much have to use proguard when programming in Scala on Android.
The other problem I had using Scala on Android is that the very nature of the Android SDK forces you to work in a way that is very Java-ish. There are some libraries that try to provide a nice Scala layer on the top of the Android SDK, but it never covers everything so you always end-up writing ugly Javaish Scala code.
How come one can use other modern jvm languages on Android, but not newer Java? E.g., if you can make Android support Kotlin, why cannot Java8 be introduced the same way?
Kotlin compiles to jvm 1.6 bytecode, so even though it is a different language it runs the same as Java 6 on the devices.
Supporting Java 8 requires updating the vm & OS, which is difficult to do in the Android ecosystem. It may happen in the future but backwards compatability will be tough since the phone manufacturers lag so badly on platform upgrades. I'm not even getting into the Oracle v Google spat that may slow down adoption of a newer version of Java.
For that reason Kotlin is a lot more viable today than Java 8. Maybe someday Java 8 will make it to Android, but that day is definitely not today. Even after it is released in the newest devices, it probably won't be widespread for 18+ months.
edit: no one should downvote the parent question it is a legit technical ask without an obvious answer.
It might be a stupid ask, but: What would it take for Android to start support for a different dev language (being able to write an app in js or Swift for example)? Also, is it never the case that when a new language is released (Java 8 for example) there is usually a strong emphasis on backwards compatibility (compiling into all or a few previous versions' bytecodes)?
You can get Java 6 bytecode from a Java 8 compiler but it will fail to compile if you used Java 8 features:
$ jdk-1.8-64/bin/javac -target 1.6 -source 1.6 LambdaTest.java
warning: [options] bootstrap class path not set in conjunction with -source 1.6
LambdaTest.java:16: error: lambda expressions are not supported in -source 1.6
Runnable r2 = () -> System.out.println("Hello world two!");
^
(use -source 8 or higher to enable lambda expressions)
1 error
1 warning
Out of curiosity, why would the Android ART VM care about what language version, or language for that matter, was used to create the DEX byte code? As long as the DEX byte code generator is able to convert the original byte code to DEX byte code isn't that all that really matters?
Yes, but the issue with Java 8 is that it requires new bytecode commands (mostly related to handling lambdas and method references) and is thus not compatible with older JVMs.
There is a project that patches Java 8 bytecode and replaces all lambda invocations and method references with anonymous class instantiations. It's called RetroLambda and lets Android devs use Java 8 lambdas in their code. It does open a whole new pit of issues though.
Nobody has made Android support Kotlin. Kotlin compiles to Java 6 bytecode. If someone made a Java 8 source or bytecode to Java 6 bytecode compiler, including support for the changes in the standard library, that would also work, but nobody has done that, so it doesn't.
I'm not sure how much success Android developers are having with this, but Retrolambda combined with streamsupport (java.util.stream) and ThreeTen (java.time) makes Java 8 on Android possible:
To produce an Android app the Android build system converts Java byte code to Dalvik/ART byte code, and currently that conversion process only support converting Java 7 and lower. If you wrote the new code needed to support Java 8 byte code to Dalvik/ART byte code then you can get Java 8 support, but Google has no plans to do that at the moment as it would take quite a bit of effort.
These JVM based languages are able to support the latest and greatest features however because they end up compiling down to Java 7 byte code, which can in turn be converted to Dalvik/ART byte code.
If you mean the "getting worse" part, I believe the implication is that Google's lack of control over either Java the language, or the Android device ecosystem upgrades, means the future would likely see increasing fragmentation/divergence in important core language features across Android devices, causing much developer pain.
If one assumes e.g. in comparison Apple will in 2 years have 95% of devices capable of running Swift 3 apps vs. 15% of Android devices capable of Java 8, much less 9/10 ... it could be quite a competitive disadvantage for Android, as well as argument for adopting a forward-looking JVM language dedicated to compiling to 1.6 bytecode if you plan to do Android development.
Kotlin is my favorite JVM language by far, it's like Scala-lite. It has great tools thanks to IntelliJ. It's great how easily you can substitute Kotlin for Java in most projects, doing so with Dropwizard was quite easy: https://github.com/doomspork/kotlin-dropwizard
I really didn't understand why they didn't started to work at scala and make it better?!
Like modularize it more so they can have a subset working on Java and make the compiler faster / better / more tooling support.
That would've been better with yet another JVM language.
The community is splitting and splitting and still most people think in the same niche, but they always use their different syntax.
I mean kotlin does a lot of things like scala but still tries to be his own language and doesn't use as much fp as scala does.
it also uses 'it' instead of '_' not sure why they came to 'it' also the data classes so much work around stuff, thats just aweful.
Hopefully Java will get more functional so that we don't get a too fragmented community.
P.S.: Yes everything has it's place i just dislike whats happening in the it, so that everybody wants to do his own thing instead of working together.
Kotlin brings few very clear improvements to Java, while Scala is a completely different language. There is no single "make it better" that would work for both.
> Hopefully Java will get more functional so that we don't get a too fragmented community.
Java did so much harm to programming community, it basically destroyed reputation of strong static typing as something considered "fun". Maybe it's time to move on, to split into better, more modern, elegant and expressive languages.
As we have seen in most milestones, Kotlin is gradually moving closer and closer to Scala, because even they realize that "a slightly better Java" won't cut it in the mid-/long-term.
I wouldn't call it "slightly better". It is much, much better. There aren't that much changes to your programming habits or architecture, but improvements which Kotlin brings are huge.
Absence of nulls, type-inference, top-level functions. All this would make a huge difference, not "slight" one.
I see it the other way around: Scala demonstrated that a C++-like beast with too many features is not what the community wants since Scala failed to gain any sizeable mind share.
Kotlin is an attempt at taking the other road: building an incremental language over Java. We'll see in a couple of years if that experiment is a success.
I just wish there was an officially supported way to get set up with a kotlin-first Android project from the command line. So far the best documentation I've seen is:
Which a) requires one use the IDE. Maybe not surprising from a company that sells IDEs, but it's not my dream environment. b) Even then, one is asked to manually "replace java kode with kotlin" (with help of a wizard). Couldn't we just get a script/function that'll set up a project targeting the desired Android API level?
It'd be nice if kotlin provided a script/command-line utility that basically allowed the equivalent of:
android create project -a Main -p hello \
-k com.example.app
-t android-15 -g -v 1.3.1
cd hello/
# Note that even android sdk is broken,
# one needs to manually change:
#
# runProguard false
#
# to
#
# minifyEnabled false
#
# in build.gradle
gradle build
# Start emulator (android avd...)
# possibly (re)start adb server
#
adb install ./build/outputs/apk/hello-debug.apk
I'm still figuring out the Android/java command-line/build workflow, but I suppose one should be able to drop the kotlin.jar somewhere, and add something to build.gradle. I've yet to find any documentation how how to do that (official or otherwise).
Am I really the only one that wants a predictable, scriptable environment in which I can both initiate development from scaffolding supported by upstream, and have a reasonable grasp over the entire build process?
I mean, we all want to automate this for Continous Integration, right?
Thank you for the reminder, I'd looked at that, and forgot while figuring out why the "android sdk" skeleton didn't work (see note above about manually patching the build-file).
At least now I should be able to get a proper java skeleton, fix the build, add support for kotlin. Only missing piece would be a supported "pure" kotlin Android project/skeleton generator.
At some point I also looked at the Android example at the bottom of that page: https://github.com/JetBrains/kotlin-examples/tree/master/gra... -- that is also IDE centric, and hasn't been touched in a while. Which doesn't leave me very confident that it's been tested with Android 5.1 and/or 6 alpha.
I suppose I'll just have to push out a "howistart"-article if/when I figure out a process that is both easy and repeatable, and hope someone will help with filing bugs as it inevitably drifts towards being outdated as the android landscape changes :-)
Does JetBrains have any way to make money off of Kotlin? Most people use the free version of IDEA nowadays. Do they have consulting services for Kotlin? Seems especially strange since they seem to be admitting it will be irrelevant once Java 8/9 get on to Android.
I'm no longer holding out hope that Java 8/9 will ever get to Android.
I think it's more likely that we'll see Go, Dart, JavaScript, or even Swift become a first-class development option on Android.
Swift would be especially nice. How fantastic it would be to be able to use the same language to target the two most popular mobile platforms? Of course Swift is also probably the least likely since Google is still smarting from the Oracle/Java debacle. The last thing they need is another decade-long copyright infringement fight with the richest company in the world...
It is very surprising though, I would have expected Google to explore other options due to the hard back compatibility story and with Oracle ready to push this legal battle as far as possible.
As far as Swift on Android ? From a developer point of view, there would probably be far worse choices (one could argue that Kotlin would be a better choice, if only because of Java 6 as a target) but yeah even without considering the legal aspect, I doubt that Google would be ready to use a language managed by its direct competitor.
This. Google is in a very ugly place with Oracle right now. Being able to jump ship might save them, but I'm not sure if Kotlin avoids all the legal troubles here.
I do believe that Google will continue to lose as the history of the East Texas juries for IP is almost always gifting the patent/copyright holder. I wish our system had some kind of venue randomizer. Its clear that this district is a moneymaker for IP holders.
> Google could have avoided all of this if they hadn't try to screw Sun.
Or, conversely, if they'd bought Sun instead of letting Oracle do so, stripped interesting IP (particularly, Java), and sold the rest back off (see, e.g., what they did with Motorola Mobility.)
I don't quite follow your argument (or if we're disagreeing). However, if they are allegedly infringing on version 6 of Java, how would follow-up infringements of versions 7 and 8 not be foolhardy? They are better off staying on Java 6 and eventually leaving Java altogether or only updating Java versions upon prevailing in Court (which might take a long while, appeals considered)
Hmm, inventing a whole new language doesn't seem like the best way to increase your quality. There are already a lot of outstanding languages nowadays.
Where has JetBrains claimed that Kotlin is going to become irrelevant once Java 8/9 get on Android? Kotlin was and is a multi-purpose language targeting not only Android but other applications and platforms such as server-side, web or even client-side.
I'm not a Java guy but I remember checking the language a few months ago and really enjoying it. I wouldn't mind if Java dies and people adopt languages like Kotlin and Scala instead. Of course, Java will never die, because of BUSSINESS APPS!
What is with languages that swap args and type? It looks cooler? It says, "Hey look at me, I'm not like those languages your dad used, tee hee!". If I want a simple and clear to understand script language on the JVM I'd choose Groovy, in fact, Grails is a pure joy to develop with I've come to find out.
Kotlin has almost exactly the same declaration syntax as Pascal, which would seem to me to be the platonic ideal of "language your dad used". Postfix type annotations go way back. They permit somewhat less ambiguous syntax for things like function types (see C's infamous function pointer declarations) and play more nicely with type inference (it makes more sense to drop the ': int' in 'a: int' than the 'int' in 'int a').
It's certainly not a radical or nonconformist choice to make while designing a language. It might seem unusual to people whose experience is with C-style declarations, but it really is just replacing one well-known syntax with another, equivalent well-known syntax.
That was a bit harsh, but oh the irony that C syntax is now considered "normal". Yuck.
I admire the bravery of Guido the Python guy for giving C layout orthodoxy the finger when he designed his language. But of course Python doesn't have variables with explicit types to worry about where to put them :-)
The type of 'filter' and 'map' should tell you whether they are eager or lazy. If they return something iterable and uncountable except by consuming, then they're probably lazy. If they return something array or collection-like, they're probably eager.
I had a quick scan of the Kotlin repo, and I think it depends on the type that you start out with. The sequence stuff is lazy; the map stuff is eager.
Looking at the docs on Iterable, map and filter return List<T>, not another Iterable. I imagine this isn't a concern when you've got small data sets, but I wouldn't feel safe using this when performance is a concern.
I haven't played with Kotlin in a while but if you want collection operations to be lazy you have to explicitly convert it to a sequence. So your example would be something like:
ints.asSequence().filter { it > 0 }.map { it * it }
and then you can convert it to a concrete collection type with toList, toHashSet, toArrayList etc.
Why would they advertise chaining together sequence operations like this as being LINQ-like (or like Clojure and other functional languages) when it's eager by default? What is gained by making these eager by default?
It just seems like a poor choice to me. That's a shame, because I feel like it's otherwise a pretty well-designed language.
Plenty of functional languages do not have lazy sequences by default. Haskell does because the entire language is lazy by default, and Clojure does as a conscious design decision (one that is not shared by its Lisp, Smalltalk, Ruby, and ML influences). There are plenty of hardcore functional programmers who will argue that strict by default and lazy by choice is the preferable option.
The reason Kotlin sequence operations aren't lazy by default is probably because Java collections aren't, and Kotlin code is going to spend a lot of time dealing with Java collections. And, frankly, it's always a tradeoff to implement lazy collections in a strict language -- people using them need to become intimately aware of exactly which operations are lazy and which are eager.
Did you know Groovy was booted off the Codehaus hosting service and its 3 developers retrenched by Pivotal,Inc last January? And Groovy's backup plan to join Apache via its incubator is a hoax, just providing a cover story for a non-technical person to run the show in the background. Virtually all the links at Groovy's page at Apache redirect to "groovy-lang.org", which is privately registered to Registrant Name "Guillaume Laforge" and blank Registrant Organisation. This individual controlling this domain and holding passwords to other non-Apache infrastructure for Groovy is a non-technical person pretending otherwise. Looking at today's emails on the Groovy dev list, we see Cedric Champeau giving two examples of "non code committing" committers, but this Laforge would be a far better example as he doesn't have even one single email in the entire 6-month history of the notifications or commits lists for Groovy at Apache. Until "Apache Software Foundation" is listed as the Organisation, the incubation process isn't real. Even better would be if the technical people who actually built and tested Groovy took over. The only real reason they haven't tried is they know a worse predator lurks over at the Grails ecosystem ready to pounce if Laforge is toppled.
Groovy's always been good from the very beginning for quick and dirty Java class manipulation, such as test scripts. It found use in Grails when they added a MOP to simulate Rails's ActiveRecord, but Grails is declining quickly -- people aren't starting new projects with it or upgrading to Grails 3.x. Gradle provides it as a configuration language but its typical use is for 30-line build scripts using the declarative DSL only, not the actual language. Gradleware no longer mentions Groovy in any of their promotional blog posts and announcements about Gradle -- it's like they're embarrassed of it -- so I suspect there's changes coming soon in that area.
OK, Groovy wasn't explicitly booted off. But I'm wondering why Codehaus closed down when 5 years ago they were saying Groovy was their most popular project in terms of page accesses and downloads. Weren't the Groovy project team reciprocating the benefits by helping with Codehaus's maintenance?
You created an anonymous HN user specifically to attack someone's motives instead of discussing the issue of people using the Apache Software Foundation as a cover to hide their effective ownership of some open source software built at other people's time and expense. That's been a common theme from the very people I mentioned.
How come noone mentioned Xamarin? Coming from a C# background it's definitely the choice; even coming from a non-Java and non-C# background seems a better choice nowadays.
after seeing the information about Kotlin, I think 'coffeeScript' which is more convenient, concise, easy to read than javascript. time is only one problem, it is immature
can Kotlin support 'Spring framework ?, if can, it is more attract for Java developer
The only downside is that it seems to be immature and not very widely adopted yet, but at least it has a strong backer in Jetbrains.
I would like to hear what people with more experience in the Java world think of it versus other alternate JVM languages.