Kotlin Is Better
161–170 of 229 posts
Re: Kotlin Is Better
#162Yet Another Java Rant. 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.…
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.
Re: Kotlin Is Better
#163Having all parameters to be read-only is a deal breaker for me.
Re: Kotlin Is Better
#164Earlier quoted context omitted.
I worked on a commercial project that used Scala. Never again. Compiles were slow, IDE support was terrible, everyone had their own subset they used. I'm sure it's improved since 2010.
I work on a large Scala team. We use microservices so my regular compile times are somewhere between 4s and 20s. I rarely have to do a full rebuild. 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 pur…
What framework or library are you using to write said services?
Re: Kotlin Is Better
#165Earlier quoted context omitted.
I mean guys been blogging for ages and it's been like a decade so maybe his position changed or he is contradicting himself. 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..
It's not that there's anything wrong with someone changing their mind. I certainly thought FP was useless ten years ago, java was the best and generally had some bad ideas about software engineering. However, the difference is I had the sense to not blog about things I only had cursory knowledge of while attempting to sound like the ultimate authority on the matter...
Also known as "blogging."
Re: Kotlin Is Better
#166A few people have said that IntelliJ is slow. 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.
Re: Kotlin Is Better
#167I've started to come around on a similar thought recently, after a few years avoiding static typing in python. I've been toying with C# specifically. 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 somet…
I developed at a Windows-centric shop for several years using C# and Visual Studio, and I can personally attest, at least in 2013, that stock Visual Studio is pretty far behind Java IDEs in its capabilities. At the time everyone I talked to recommended I get my manager to get me a copy of ReSharper, but it wasn't in our team's budget. At least in 2013, here's where I remember C# IDE support was lacking: * No automati…
...and in Maven since 1.1.2: https://blog.jetbrains.com/kotlin/2017/04/kotlin-1-1-2-is-ou...
Re: Kotlin Is Better
#168Is there reason to choose Kotlin if you don't already live in the Java world? 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?", t…
You can compile Kotlin to Javascript, as a start. You get the benefits and drawbacks of static typing and object-oriented (or rather "class-oriented", if we call Javascript object-oriented) programming support. 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 ec…
Re: Kotlin Is Better
#169Other language built around IDE support: Delphi. 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.
Oh Delphi.. every time I fight with CSS and think about how easy making GUI apps used to be almost 20(sic!) years ago, I feel like something went wrong. Mandatory: https://www.youtube.com/watch?v=8pTEmbeENF4
Re: Kotlin Is Better
#170Earlier quoted context omitted.
Automatic refactoring in dynamic languages are nowhere need to those in java. Just rename method - with static typing you know it was changed correctly everywhere, full stop. Implementation of refactoring code is easy. With javascript, you just don't know what can potentially come in as argument of function, so you don't know whether object function call can or can not be renamed. Smalltalk authors seeing static typi…
Please: re-read the comment and preferably the links as well. Once again: automatic refactoring tools were invented on Smalltalk. > Smalltalk authors seeing static typing as major potential problem Authors saw lack of static typing as a major potential problem. It just wasn't. Again: reading helps. A lot.
Even then you still need manual supervision in that it may work in 99% of the cases, but for a particular method it is more difficult to automate (because it's meaning is more overloaded).
And of course just because the authors foresaw problems and decided that it was fine doesn't mean someone used to refactoring in static type system can't have more stringent norms.