Threads for dennisl
-
The results here will just be nonsense if they aren’t segmented based on ‘programming sector’. People writing firmware for a Boeing aircraft in Ada vs a consumer web startup in Ruby aren’t going to have comparable opinions about software. Probably one of the biggest fallacies around giving advice in our profession is that ‘everyone is working on software like you are working on’.
-
-
-
Largely agreed, but I’m not sure how to design a study that deals with that adequately. It would be great to not have to make assumptions about what programming sectors exist. Most programmers have not worked in every sector and it’s easy to forget about those we haven’t got personal experience with, and it would be nice to use a survey to check our intuition against the reality.
Maybe a free-form field like “how would you describe the type of programming you do, in terms of the technical constraints and the business model?” Then cluster based on distance from the other answers, then try to summarize this field to label each cluster?
I’m not a data scientist, and shouldn’t really pretend to be. :)
-
-
Managed memory via garbage collection: I chose “Convenient as long as the GC pauses aren’t too long.”, but my real preferred memory management system is automated reference counting; the question seemed to be a pure axis of GC <-> manual.
-
I think people that get into Ruby via Rails are naturally prone to over-caching in the exact way that is outlined here. In Rails, it’s almost 100% safe to use this type of caching in a controller method because each request makes a new instance of the controller processing it. It’s also incredibly useful to cache results of I/O operations (think isloggedin? or current_user type results) to improve code quality in the meat of the methods. But back to my point, when you step outside of Rails into the vanilla Ruby world, it’s all too easy to use that in places where it doesn’t apply.
-
s/memoization/mutability/ig
-
-
-
I upvoted the article just so people could see this comment. It really helps illuminate how people project their issues onto the layer they’re working with instead of looking into root causes.
-
-
-
Interesting. Why not just use C when you’re doing things like adding padding in structs? Surely at some point you’ll be fighting and reverse-engineering the Go compiler more than if you were to just factor out that section of code into a native binding.
-
The Scala folks seem to think creating a new language that is halfway between Java and Scala isn’t a great idea.
-
Well, of course they are. They’ve invested a lot of time into Scala; if Kotlin takes off, their situation arguably becomes worse.
Here’s the thing, though: I actually think that Kotlin really hits a sweet spot for many teams. Scala really is its own thing, in a lot of ways. Yes, it compiles to JVM bytecode, and yes, you can work with Java libraries, but code you write in Scala still feels (at least in my experience) a bit cut-off from the Java side of things. Calling Scala from Java is a bit involved, Scala almost always uses its own build system (sbt), Scala has tons of syntax and concepts that are absent from Java, etc. This means it’s relatively expensive for Java teams to adopt: there’s a real need to train everyone before they can sanely use the language, and even more if you really want them to properly leverage everything Scala has to offer.
Kotlin, by contrast, is really just trying to be to Java what Swift is to Objective-C: a slightly better Java that fixes a lot of the major problems of the language, but doesn’t try anything radically new. I understand why that’s frustrating if you’re into Scala, but for Java shops, it’s brilliant: Java/Kotlin interop is really easy in both directions, Kotlin reuses the same build infrastructure as Java, and so on; Kotlin just brings a few key things to the table (null safety by default, immutability by default, a better streams library, and better immutability), and otherwise leaves things be. This means that gradually adopting Kotlin is a reasonable idea, and that the time required to train a team is dramatically lower.
For example, on my team, I was able to spool everyone up on Kotlin in really just a day, and we had Kotlin code running in production barely a week later. Based on teams at my company who’ve tried Scala in the past, this is concrete evidence that Kotlin is much easier to introduce into a legacy code base.
I understand why a Scala user would find all of this really frustrating. They’re looking at a language that, from their standpoint, is demonstrably “worse” because it does a lot less than Scala. But I genuinely believe that this “weakness” can be a strong benefit, and I think that writing off Kotlin because it’s between Scala and Java is not only a mistake, but erroneously looks at its biggest strength as a weakness.
-
I think some of the annoyance comes from the feeling that it is trying to sell a compromise which isn’t very useful.
It’s like Java claims “vaccination causes autism” and Scala says “no, there is scientific evidence that vaccination doesn’t cause autism” … then Kotlin comes in and suggests “hey, can’t we compromise? let’s just say vaccination causes some autism”!
In my opinion, the whole a-slightly-better-Java-is-all-we-need movement lives in some kind of a filter bubble–it only appeals to Java developers; everyone else will just assume those people are crazy and move on.
So we have a language which lives somewhere between Java 8 and C# 3 in terms of expressiveness. Given that the .NET team decided that they basically want to include everything Scala does for C# 7, I’m skeptic that their bet works out in the long-term: They have a very limited appeal, they haven’t managed to release a stable version, the language is still very volatile, they added an considerable amount of cruft to the language in the latest milestone, the compiler is quite unstable, the ecosystem is very small, there is nothing that you couldn’t write in Java and they lack any kind of “killer library”.
I apologize if I sounded too negative, but I think they will have a lot of trouble convincing people that the “slightly better Java” is called “Kotlin”, and not “Java 9”.
-
I want to ignore .NET, since we’re narrowly focused on JVM languages right now, and the JVM, for better or for worse, simply imposes a different set of trade-offs than the CLR. (Although having an F# v. Scala v. Haskell discussion would be really fun if you ditch that requirement.)
You went with a pretty intense claim with the vaccination thing. Can you give an example or two of what you have in mind there? I’m guessing you have several concrete language features where there’s something that Java and Kotlin make a horrible/ever-so-slightly-less-than-horrble decision on, and Scala avoids. Or some cruft you think they added in recent milestones? Or an example of where the compiler’s really unstable? Any of that might enable us to have a bit more of a concrete discussion here; at the moment, I’ve just got metaphors.
From my end, we’ve been having great luck using Kotlin in production to make money, and with very minimal track-the-language churn compared to my old Scala project. When we moved from Scala 2.8 to 2.10 (IIRC; might’ve been 2.9), we had a bunch of Scala library API changes, plus we had to rebuild all our JARs due to the lack of binary backcompat, plus there was some language syntax change that bit us. Conversely, the Kotlin upgrader has cleanly handled companion objects and lambda alterations for us, which are the only two breaks that have happened since we began using it in February. We’ve had no binary backcompat issues that I’m aware of, and internally publish a Kotlin library designed to be consumed from Java. Thus, the backcompat story, in my personal experience, has been better so far.
-
-
The compromise is stupidly useful for Android devs actually. We need tooling integration to be able to write code effectively because of the nature of mobile programming. Kotlin provides that officially; JetBrains makes the only up-to-date Android IDE and also makes Kotlin. It’s a huge leap forward. Maybe you’ve changed your mind in the huge amount of time between when you wrote this comment and now, but if not, their appeal is certainly working. Kotlin is Android’s Swift. We’re writing all our new code in it despite it still being in beta for the past few months.
Scala is neither useful nor desired for a majority of programming applications. It brings considerable code maintenance overhead to developers with non-functional backgrounds (most of them). In that respect, is not better than Java, it is only more powerful. Be careful when conflating the two.
EDIT: I’m also pretty curious as to how I stumbled upon this thread. I just had it open on my browser with no recollection of getting here.
-
-
-
-
Last time I checked, the overhead was around 100kb (for a simple “Hello World”). I think every random third-party library is larger than that.
Kotlin doesn’t have “practically zero overhead” either, but considering that no one uses the language, there are just less people fact-checking the claims of Kotlin devs.
-
-
The response to the inheritance question stuck out to me. I haven’t been around lobsters for long at all so it’s very telling of the “programmer demographic” here. The fact that 1/3 of people answered “by now we should all know that was a bad idea” indicates a huge reddit-like zeitgeist awareness (or trend following) to me. (Personally I still think that in certain situations, inheritance is an incredibly useful model for hierarchical structures, e.g. mobile UI work, and I can’t fathom why someone would say otherwise–CMV please.) At the very least it shows that we’re not just a bunch of students or professionals working in Swing government contracting. Fantastic amount of discussion as well.