C# with visual studio is, I think, the most productive environment I've come across in programming. It's ergonomically sound, straightforward, and the IDE protects me from all sorts of relevant errors. Steve mentioned Intellij is a bit slower than he'd hope typing sometimes. I totally agree with that. I think Visual Studio doesn't quite suffer from that (though I haven't worked on huge projects, and that may well affect it). My main problems with IDEs are twofold: for non-static languages like Python, they're just not very good. Sometimes they do exactly what you need, and 70% of the time they're just totally useless (which is a knock on the programming languages more than the IDEs). The zippiness on reaction to my typing is another huge deal. If it's anything other than instantaneous, then I notice my editor in a negative light. When you pair a tremendous IDE with a good language though, the productivity loss of typing becomes pretty much negligible, and the gains for all the other reasons start to become apparent.
Changing one parameter or type on a class or function to refactor, and then just following the chain of compiler errors, reaching the end, and seeing that everything just works exactly how you want it to was a big eye opener to me.
Definitely going to give kotlin a go some time as well.
Yup, "following the chain of compiler errors" mostly makes refactoring straightforward. Dynamic typing is fine when the codebase is small enough to keep it all in your head so you know what the impact of a change is. Once you've got enough code or you're not completely familiar with it, the cycle of changing the code, running it, diagnosing errors, changing the code some more while hoping you caught everything etc. becomes tedious and impractical. Simple renaming a field in JavaScript, Python or PHP is a nightmare if you want to guarantee nothing broke so I can't relate to how people don't appreciate strong typing. You're basically badly doing the job of the compiler manually by trying out all code paths yourself looking for errors.
I definitely agree that dynamic typing doesn't scale as well as static typing, though.
I made the mistake of trying to build a system in Powershell because the ability to remote into windows boxes was core to it. That was a mistake I didn't see coming.
* No automatic incremental compilation. It turns out, this feature is specific to Eclipse alone. In my current job I'm forced to use Intellij and cannot figure out for the life of me why people think Intellij is better. Automatic incremental compilation is a game changer and only Eclipse has it.
* Limited Code analysis and search. For instance checkout this SO: http://stackoverflow.com/questions/282377/visual-studio-how-.... This kind of symbolic analysis and code search feels essential to me in an IDE, and stock Visual studio just didn't seem to have it beyond the basics.
* Weak refactoring and code generation support. ReSharper might bridge the gap a little here, but stock Visual Studio felt way behind.
* Weak ecosystem for plugins and tool integration. With Java IDEs I have excellent integration with unit test frameworks, code coverage tools, checkstyle, my command-line build tool, etc. I remember it taking a fair bit of effort just to be able to run NUnit tests in Visual Studio. Why NUnit? Well, our software needed to build on Linux with Mono so we needed to use a cross-platform unit testing framework instead of the one built into visual studio.
As a side note, I think the plugins ecosystem is another area where Eclipse has an edge over Intellij. For instance, when I tried Intellij's code coverage tool I eventually gave up on it because it had a critical bug I couldn't diagnose that resulted in incorrect code coverage being displayed.
...and in Maven since 1.1.2: https://blog.jetbrains.com/kotlin/2017/04/kotlin-1-1-2-is-ou...
There's always been codegen support with snippets, although I never found too much need for it, personally.
The tools ecosystem is pretty weak though. I always found TestDriven.NET to be the best test runner, although Resharper's is OK if slow. I actually like NUnit a lot better than JUnit, but YMMV.
I thought that but PyCharm scores way better than 70%. I even trust it to do automatic refactors. Sometimes...
> The zippiness on reaction to my typing is another huge deal. If it's anything other than instantaneous, then I notice my editor in a negative light.
Maybe I grew up on IDE's but I type stuff in full only if autocomplete fails me. Maybe I have an appalling memory. Or maybe I'm really slow at typing. Or maybe my variable and method names are too short.
> I even trust it to do automatic refactors. Sometimes.
Function extract refactors and the like are definitely within the realm of possibility. Once you want to refactor code across many files it becomes a lot harder in dynamically typed code, for sure.
I guess for a long time I sort of had this view of "ooh I have this awesome expressive language that won't get in my way and I can just power through it all". Don't get me wrong, I totally love python as a language. But I think languages like C# have started to make typing feel like it's more out of your way with type inference, etc.
I mean, this is the sort of code you can write in C# these days (to take a super trivial example):
var somestuff = someList.Where(x => x.Id > 7)
.Select(x => x.Name)
One of my hobby projects is in C, and I prefer using an editor to an IDE. Because of an accident of history, public methods tend to be named like `P_PlayerCommandRead`, where `P` means (generally) "physics", and `Player` and `Command` are essentially nested namespaces. I specifically name things this way so that I can type them quickly without spending a lot of brain cycles on figuring out the scopes.
I'm not saying code bases built with IDEs don't have consistent naming, or that code bases built without IDEs have hellish homegrown naming. But it's kind of a "how you grew up" thing, and it latches onto a lot of underlying feelings you have about coding in general.
I cringe when I have to deal with one big legacy product of ours that still hasn't been converted from a Eclipse project to IntelliJ; it's an order of magnitude more painful to work with.
See, that makes a lot of sense on the surface... And I find it playing out across a lot of the modern IDEs like PyCharm...
But I don't think it actually has to be that way.
DrRacket blew most of what I knew out of the water. It could refactor for me, trace functions and calls to definitions through multiple libraries, which included argument arities. I could write code in the REPL and push it back up into the editor, or vice versa.
Not to mention that toying with another language is not such a complicated endeavor once you're 5-10 languages in. The great thing about C# and Kotlin is they've been good at adopting features from other languages that are already good and familiar, so picking them up is generally super easy.
Yup. Because they can't.
Without type annotations, IDE's are pretty much incapable of offering automated refactorings without human supervision (and yes, that includes Smalltalk IDE's).
They can give you some primitive auto completion and navigation, but that's pretty much it.
Actually they can.
> incapable of offering automated refactorings without human supervision
> (and yes, that includes Smalltalk IDE's)
Patently false. Everyone repeat after me: automated refactoring was invented on Smalltalk with the Refactoring Browser. Again. Automated refactoring was invented on Smalltalk with the Refactoring Browser.
The lack of static type information was considered a major potential problem by the authors when they started the project. They later reported how they were surprised when it turned out it wasn't.
So please stop spreading misinformation.
'This is absolutely the greatest piece of programming software to come out since the original Smalltalk browser. It completely changes the way you think about programming. All those niggling little "well, I should change this name but..." thoughts go away, because you just change the name because there is always a single menu item to just change the name. When I started using it, I spent about two hours refactoring at my old pace. I would do a refactoring, then just kind of stare off into space for the five minutes it would have taken me to do the refactoring by hand, then do another, stare into space again. After a while, I caught myself and realized that I had to learn to think BiggerRefactoringThoughts, and think them faster. Now I use probably half and half refactoring and entering new code, all at the same speed (I should instrument to measure this). -- KentBeck'
http://wiki.c2.com/?RefactoringBrowser
Presumably Kotlin doesn't wrap the entire Android API with some kind of better API, but most Android API calls would be direct Kotlin->Java calls, so how does Kotlin solve the nasty API issue?
Really, this seems to be another Java critique by Steve. He's also written critiques against typed languages in general, including Scala.
Android's API issues are language independent I think. Compare the design of Guava vs Android, you can make well designed and easy to use Java APIs, it just takes thoughtfulness.
The improvement to findViewById was met with tepid applause today because its hardly used anymore due to there being a lot of better options. Kotlin's Android Extensions for the most part has completely eliminated one of big use cases I had for the data binding library, which was refactoring a view where an id and/or the type of view changes and also not needing to constantly have the xml open to directly compare which ID I need to use. I assume its also true for people using a tool like Butterknife. The autocomplete in the IDE could use a little help but its still great.
Anko makes the awfulness of dealing with SQLite on Android almost bearable, although I've only briefly experimented with it. Creating views in code also seems like it is a much more pleasant experience with Anko, although I also have only briefly experimented with it. My day job had me creating fairly complicated views where a preview was absolutely needed, but a lot of apps don't have that complicated a view hierarchy and would probably benefit.
This is just off the top of my head without even looking through the codebase or at my experiments.
Edit: Forgot to mention being able to write an async task like
async() {
val thing = ...
uiThread {
method(thing)
}
}
See my comment here: https://news.ycombinator.com/item?id=14365317
Kotlin manages to help you route around just about all of Android's Red Lights, and turns the experience into something that on the whole I now find superior to iOS development.
I haven't done any android and don't know kotlin either, so maybe someone here who does can expand on this.
> I was first in line to throw the Android book at the wall and give up last summer, but now with Kotlin I'm finding Android programming is, dare I say it -- enjoyable? I think this suggests that Android's "bad" APIs weren't all that bad to begin with, but rather that Java has been masking Android's neat functionality with a bunch of Java-y cruft.
One key obstacle for me to get over is that some of the stuff one learns by attempting to learn through Google's documentation and copying their examples is pretty horrible in a non-toy app. IIRC I had to learn this the hard way by making an app and finding it getting geometrically harder in complexity when adding features one by one with image downloading async tied to activities and message passing from service to activity tied to message number/activity number.
> but now with Kotlin I'm finding Android programming is, dare I say it -- enjoyable? I think this suggests that Android's "bad" APIs weren't all that bad to begin with, but rather that Java has been masking Android's neat functionality with a bunch of Java-y cruft.
The compiler was built with callbacks to provide code completion; it runs in process, as a DLL, as part of the IDE.
No accident that Hejlsberg also design C#, and innovated further with TypeScript's language server. He wrote the original Turbo Pascal (IDE + Compiler in the same executable) in assembler, so he's been building IDE + language combos all his life.
Mandatory: https://www.youtube.com/watch?v=8pTEmbeENF4
And even that is an incredibly bloated technology compared to delphi.
Web development...
It's not a co-incidence that I moved to TypeScript recently and am absolutely loving it, it feels like JS but engineered.
Second, I tried Kotlin and liked it a lot, but found it so much like Swift that my brain kept thinking it was Swift, so I ended up making mistakes and getting frustrated. That would probably go away with experience though.
We could fault the design for stacking all those views but that's another issue.
Those two statements are in no way mutually exclusive.
(That said, Swift is infinitely better than writing Android Java code, in my limited experience)
There was a talk about it on this IO https://www.youtube.com/watch?v=FrteWKKVyzI.
http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.ht...
And in the comments section he got lit up because he was unfamiliar with Haskell/Scala/OCaml type languages...
and here he is 9 years late to the party touting a baby version of these statically typed FP languages. I actually laughed out loud reading this blog post.
No dog in the fight personally as I don't use any of that stuff. Maybe I am missing some deep technical blunder but on the face of it seems a bit silly to cite the guys decade old work against his current; then be surprised they aren't fluidly consistent..
> and here he is 9 years late to the party
Put another way, is it a language that makes living in the Java environment less painful, and thus only of value to people who continue to need to live in the Java world?
Why would someone who has never programmed in the Java ecosystem use Kotlin?
I'm surely ignorant and prejudiced but when I read this I thought "Hey why not try Kotlin?", then I thought of Java and images came up in my head of thousands and thousands of files being installed, and the vast, lumbering Java engine cranking slowly and chugging and masses of XML configuration up the wazoo for everything and I shuddered and thought "I'll stick with JavaScript, where the pain of configuration is merely excruciating, as opposed to the pain of Java configuration which is similar to bowing before throne of the Java king of ninth level of hell awaiting punishment for a lifetime of sin.".
But if you choose to stay with the JVM, you get:
- the JVM - multithreaded, highly tuned and high performance JIT VM, well documented and continuously being improved
- mature tools
- libraries from the Java ecosystem - for pretty much anything you can think of
- coroutines (with Kotlin 1.1) for async support.
XML configuration is being phased out slowly (I guess you are talking about Spring here), in the last ~10 years annotations have become much more popular. You still have to support those legacy apps though.
This made me laugh: "then I thought of Java and images came up in my head of thousands and thousands of files being installed" - well, don't check your node_modules directory then, or you might be in for a surprise :)
Java (GWT) has been compiling to JS years before Kotlin was even a twinkle in JetBrain's eye.
I can't think of a language that doesn't compile to JS.
Even in plain Java though, your description of "the vast, lumbering Java engine cranking slowly and chugging and masses of XML configuration up the wazoo for everything" is largely only applicable in Enterprise software. Modern Java shops tend to eschew all those things and have for quite some time.
IDE support is bad, that's a good criticism but a good chunk of us don't use IDEs, and instead write it like a dynamic language. Live inside the REPL, copy paste back and fourth.
As for 'subsets' everyone uses, I find this advantageous. Our team strongly encourages a pure functional style, but we realize not everyone is going to start out that way, and it doesn't get in the way of shipping software.
https://groups.google.com/d/msg/clojure/JiK-WLFT65M/spBka_gs...
https://news.ycombinator.com/item?id=2466731
With replies directly from Rich Hickey regarding Steve Yegge's "yes language".
Steve is certainly no stranger to Clojure.
Edit: also of interest in the discussion, Clojure is now #50 on TIOBE's top 50 list of languages. Notably OCAML didn't break #50 (or Common Lisp). I don't put much value in those lists personally but it does have economic value.
Anyways, I broadly agree with his take that it adds all of the cool toys you could ever want to Java without the difficulty and mental overhead of learning Clojure or Scala. Strong compatibility with the existing Java ecosystem seems like a plus, but I've never dug into it deep enough to notice that.
I did find myself really wanting to know what he figured out to make Android UI programming non-awful though. I've messed with it some, and I don't see how adding in Kotlin would make it much nicer. Maybe he loved Kotlin so much that he was able to forget about the Android UI API.
* Runs everywhere js/asm
* MIxed bag of tooling, but generally you can find something amazing and you won't have to venture to sourceforge or similar to submit a patch
* Doesn't suffer from the coljure/scala "We can totally use other JVM libraries but we only really do that If we have no other option"
* Absolutely beautiful generics and spot on inference
```
function pluck<T>(key: keyof T, from: T[]) {
return from.map(item => item[key]);
}
```
* Incredible flexibility
* sketch in js then annotate
* decide on strict nulls
* decide on implicit types
* various approaches to composition
* One of the few cross-platfrom languages that feel pretty much identical on all the platforms
[edit] Formatting
In my book, Java is a fine language, and has been since Java SE 6 was released back in 2006. It keeps getting better, too. "Glacial" pace or not.
Whenever any kind of discussion about Java comes up, people start ranting about XML configuration or annotations. These are not language problems. These are developer problems. If you don't like XML or annotations, then don't use them. Problem solved. Very few Java features require the use of either.
I rarely run into issues with the Java language, syntax or productivity wise. I've run into a couple of Sun/Oracle/IBM bugs in my 17 years of Java development. I've greatly appreciated productivity-increasing features like try-with-resources and Streams, but the lack of those features have never held me back as a developer.
Given the sheer amount of Java code out there, I would say it deserves a little more praise and a little less negativity.
I wonder how well the like/dislike of Java correlates with like/dislike of object-oriented programming. I've always loved object oriented programming but there seems to be many programmers who feel the opposite, and for them Java would be going against the grain.
What I want, as a devoted Java partisan, is a Java (Oak) experiment do-over. More more and less less. A fantasy hypothetical effort I call Encore™.
What are the sources of programming errors? Engineer them away.
What causes the most boilerplate? Engineer those away.
I've got a laundry list that I've collected over the years. Maybe I'll scrub it for publication.
--
One specific, novel feature of Kotlin that is better, and should be swiped for every other OO language, is its automatic generation of the canonical object methods (toString, equals, etc).
Data classes are dumb though.
The writing is as good and hilarious as in the old good times when he used to write way more often. Lots of fun for the morning.
For aspiring blog-writers, it's also a good study how to write blogs to keep readers engaged. I only know 2 people writing in that style, him and Joel Spolsky, but it's highly effective.
Ugh. I left Android development right around Honeycomb - where Fragments were supposed to be the cool way to manage your app and you'd get screen orientation and device screen configuration all for almost free. In practice I found Fragments far more confusing to use than the already complex Activity lifecycle. To hear that 3 years later that everyone may think Fragments were a bad idea doesn't leave me feeling good.
I dovt know about other people but I certainly end up cargo culting every time I want to use the fragments API.
Part of that was because every time I'd seen some (relatively) small shop invent a language or platform in the past, it sort of sucked. But JetBrains are a rather different animal. They've done a great job of getting the right kind of people on board, with the right background and experience, to do language design well. They also have a talent for making long-term plays and consistently investing in them; they're patient about achieving long-term success (examples: IntelliJ, TeamCity, even YouTrack), which isn't so common. I probably shouldn't be surprised to see the same happening with Kotlin - they've been plugging away at it for about 6 years, I think. Great work.
[1] https://steve-yegge.blogspot.com/2016/11/the-monkey-and-appl...
Why is this so, if Java is not inherently slow?
Sure JetBrains are some of the smartest developers around and yet their IDE is still slow.
I can't help but feel that Java is slow and problems with performance in something like IntelliJ do nothing to dispel that feeling.
Java is objectively not slow. Unless slightly slower than C/C++ is what you call "slow"
Don't get me wrong I'm a huge fan of Scala and highly expressive language but on the other hand there is something to be said for simple consistent and not that expressive languages. It pains me to say it but less choices and not more.
That is I want Kotlin, or Scala, or Java to be a little more like Go (and I'm not a fan of Go). The development consistency with Go with gofmt and other build tools as well as having fairly good default concurrency (Java as a myriad of concurrency practices: eg. streams, actors, rx) help ramp up time.
The ramp up time for all JVM languages is pretty awful compared to C# or Go. There are so many tools and libraries and different way people do things. I love the choices but it really hurts bringing on new talent.
Luckily Kotlin is backed by a tools provider so perhaps extreme consistency will happen but when I look at the Spring 5.0 examples (also on the HN right now) I get nervous and think oh this is becoming Scala academic DSL confusion all over.
. advocated Javascript on the server-side
. tried to get goog to support Ruby
. is active in Lisp, enough to get it mentioned in wikipedia twice
And now is enough of an expert in Java and Koltin to instruct us on which is "better". That's a lot of languages to be an expert in! It's almost unbelievable.
If someone who's been working in Java for years and then has done a significant Koltin project (100k plus SLOC) that's in production and they told me "Koltin is ?" I would listen to them. Otherwise I might be tempted to believe someone's writing another clickbait article.
Regardless, looking to his wiki history, it seems he's, charitably, outspoken. Not someone i'd look to for a sober technical analysis.
Maybe the founders of Jetbrains are Russian. Not sure.
edit: aha Kotlin is in fact developed in Russia. From Russia with love!
Visual Studio Code is pretty nice with TypeScript. I've enjoyed having the autocomplete for my little Phaser game.
Anyway as any hype like scala and co. Java works very well, has small issues and no issue which really hurts me.
"Whereas Kotlin is made by world-class IDE vendors, so right from the start it has the best tooling support ever."
And then...
IntelliJ doesn't like it when you type fast. Its completions can't keep up and you wind up with half-identifiers everywhere.
So sounds like the tool support really isn't great.
My only issue is with his comment on swift. Which also sucks. Objective-C is wonderful and delightful. I'm sad to see it losing favor.
Oh well, off to try Kotlin. Maybe I'll finally make an android app... no.
The standard library[0] functions `apply` and `run` are really nice with builders.
When I converted Red Moon[1] from Java to Kotlin (no functionality changes), the code base shrunk by around 1/6.
[0]: http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan... [1]: https://github.com/raatmarien/red-moon
if they begin to build first class hooks for tensorflow in kotlin (as they might already have, considering Tensorflow Lite on android), i think it could replace python as the first language for data scientists.
I consider Steve Yegge to be one of the smartest writers I've ever read on the subject of programming. You might disagree, but I would recommend looking for his previous writing (which I'm not sure is still available). You may find he has a better understanding of your toolset than you presume.
Or possibly not. I personally miss his rants.
This made me hate Java before I knew enough to know why. It's joyful writing. I'd love to run it past a non-coder just to see if it's enjoyable in and of itself. I suspect it would be to someone with an ounce of patience.
You're new to this HN thing? Steve Yegge is kind well known around this here parts...
Also you seem to be responding to the (meant as joke) title, not TFA.
No, not really.
> Steve Yegge is kind well known around this here parts...
Well, I haven't noticed.
> Also you seem to be responding to the (meant as joke) title, not TFA.
Actually, to TFA as well. His arguments are trivial generics without much substance. Such articles irritate me greatly.
Also, I don't believe Steve Yegge is dumb...