I'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 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.
> 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.
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.
> We tend to use tests for just this case. You change anything you want, then see which tests break, and fix all the places.
Why not tests + static typing? Getting tests to point out breakages is attempting to do job the compiler can do for you but not as well. If you renamed a field in some places but not others for example, you'd have to rely on good enough code coverage to catch this plus deciphering a failing test is nowhere near as easy as a compiler error that pinpoints the exact line causing the problem. Tests take time to write and static typing is giving you many tests for free. You also miss out on automatic refactoring tools and autocomplete.
Wait, you don't enforce 100% coverage? (Sorry, couldn't resist ;))
I actually mostly agree, static typing is a huge boon for productivity, and certainly allows for less experienced (both new programmers, and new to the project) developers to become productive on a new codebase faster.
However, I think dynamic typing forces a certain familiarity with the codebase that can prove really useful. Yes, it slows learning down, yes it rules the lower end of the spectrum of developers out, but there are still benefits to this required familiarity.
Obviously, when codebases reach a certain size, this falls over. And even before they do, the drawbacks may be more than the benefits, but it's still something to consider.
My personal opinion right now is that these benefits don't exceed the drawbacks, that static languages are better, however I tend to flip flop back and forth on this every other month (or project).
> However, I think dynamic typing forces a certain familiarity with the codebase that can prove really useful. Yes, it slows learning down, yes it rules the lower end of the spectrum of developers out, but there are still benefits to this required familiarity.
Useful in what way? I don't see how static typing is going to make you less familiar with a codebase. Good use of types provides a certain amount of documentation for free as well.
I know this was a joke, but 100% coverage only means you've covered every code path, not that you've tested every case. Static types allow you to prove the absence of certain classes of errors. Of course, you still need tests for all of the classes of errors that your type system doesn't cover.
My intuition would stay that static typing would rule the lowest end of the spectrum of developers out, and that dynamic typing would allow that lower end to get started coding much more quickly, until reaching the scale at which the false economy becomes apparent.
But if you're writing tests (and writing documentation that documents the expected return type of methods, etc.) you're doing an error-prone replacement of work the compiler can be doing for you.
While I've always preferred static over dynamic, Powershell is what finally got me to actively disliking dynamic languages. Not strongly disliking, but enough that I'll put up with a bit of pain in order to use a static language over a dynamic language.
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.
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 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.
A lot of this has been at least partially addressed since VS2015. There is built-in code search (ie, "find me any language construct with these letters in it"), there's support for basic refactorings (rename, extract method, extract interface, etc). I got used to all the built-in stuff before someone talked my into Resharper, and found most of the built-in stuff is actually better these days. Faster, anyway.
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.
> Sometimes they do exactly what you need, and 70% of the time they're just totally useless.
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 think I'm pretty sensitive to even a minor typing delay. That's not necessarily true for everybody, but it irks me.
> 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):
Typing in this case is 100% out of your way, but you get all the benefits regardless, and you get all those sort of nice functional-style list operations you expect in other languages.
Except when you have to wrap it in parentheses and tack a .ToList() onto the end of it, or use something outside the subset that the query syntax supports, it starts looking considerably more ugly than chaining the functions together.
The obvious answer is don't wrap a good query in parentheses, use a second line:
var somestuff = from x in someList
where x.Id > 7
select x.Name;
var somestuffList = somestuff.ToList();
For what it is worth, I personally consider ToList() harmful. I've done a lot of LINQ performance work and the first place I start is with a project-wide search for ToList and start to delete and/or replace calls to ToList to things more appropriate. List is more often than not the wrong data structure for a query result and I've seen too many people use ToList as a debugging crutch without understanding its performance impact.
They're different ways of programming -- it's where you spend your brain power. You can see codebases that weren't built in IDEs: they generally don't have strong naming conventions in their classes/structures/functions.
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.
More recently I've come to the conclusion that most of naming must be influenced by "how you grew up". As someone who has mostly touched the Java and Python ecosystems while learning to program, I frequently run into names that seem "weird" to me, because they replace often-used technical words (from those ecosystems) through more obscure synonyms.
C++ also often had that (replacing 'map' through 'transform' and so on) - but since it's a standard, at least it is usually more consistent in its own internal logic. Same goes e.g. for LINQ, which was influenced by SQL instead of LISP-like collection transformation functions.
It's pretty obvious that this was a conscious decision. And it makes a lot of sense too, if you think of Microsoft's target audience.
But still - if you're used to the functional "default" naming schema (which mostly comes from math, anyway), it's nontheless something that can be a bit irritating (especially since there's also the "inline SQL syntax" you could use alternatively).
It definitely is. I started with C++, and at some point I found my way to Common Lisp. At first I was surprised at how many weird names the latter has... and then I got used to them, started to like them, and now I shake my head when I see new languages inventing new names for things that had a perfectly good Lisp name already, probably because they didn't know the concept had already existed for 50+ years...
I think part of that is that PyCharm is a JetBrains product. Those guys are the preeminent IDE makers out there at this point. Even Visual Studio is playing catchup to the stuff that they've been offering for years with ReSharper, and Rider is making a compelling case at becoming the best C# editor out there.
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.
> 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)
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.
I just disable automatic autocomplete in IDEA and use ctrl+space explicitly when I need it. You still have all the smart functionality of the IDE, but you also get zippy typing.
If you know C# you don't really need Kotlin. You can write windows, windows universal, web, linux console, Android and iOS apps, all native, and all in C#.
I don't think that's necessarily true. Dotnet is still just getting started on Linux, meanwhile the Java ecosystem is insanely mature on Linux. Fwiw, I have been writing dotnetcore lately, and enjoying it, but it definitely doesn't match the java ecosystem in terms of library maturity. Because of Google/Netflix/etc, Java on Linux is a really interesting beast
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.
The Mono runtime is quite mature and capable on Linux as the Java ecosystem. Many very good GTK/Gnome apps have been written in C# over the years (Banshee, F-Spot, etc).
.NET Core is awesome, but don't forget that it's not the first time .NET has been available to Linux developers.
> for non-static languages like Python, they're just not very good
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.
> 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'
Here's the thing: guided, interactive refactoring is not the same as automatic refactoring. If I can hit a button to inline all usages of a method (as in IntelliJ), that's not the same as using a tool that can point out candidate locations for inlining what might be the method.
Furthermore, the reason Smalltalk pulled all this off is because it is/was metadata-heavy. Every object could be interrogated about its shape and capabilities (in the form of asking about its "slots"), even though there were no static type annotations. It's sorta like the runtime-typing stuff done by Dialyzer in the Erlang/Elixir world nowadays, and the tooling and code all ran together in the same runtime/VM instance.
Clearly this is not the case for Python, Ruby, or Javascript, where the tooling runs in a separate process from the code, and there's very little metadata that tooling can query without just up and executing the whole program. In fact, this particular lack of metadata is why PEP-484 exists (https://www.python.org/dev/peps/pep-0484/) adding "type annotations" that are really just runtime metadata hints.
So no, a language without static typing or metadata is not as tooling-friendly as a language with such requisite available analyzable information, and certain categories of refactoring cannot confidently be done automatically.
Smalltalk was not as "loose" as Javascript or Python, not by a long ways. The level of metaprogramming it was capable of was only enabled by the level of metadata it made available to its hybrid, in-process runtime/design-time tooling.
> Clearly this is not the case for Python, Ruby, or Javascript,
Javascript objects are inspectable and modifiable in exactly the same way as Smalltalk objects are. All browsers support this today.
This inspection capability has nothing to do with static/dynamic typing.
> So no, a language without static typing or metadata is not as tooling-friendly as a language with such requisite available analyzable information, and certain categories of refactoring cannot confidently be done automatically.
Yes, they are. You can do anything with IDEA/Eclipse + Java that you could do in Smalltalk + IDE.
Without type annotations, refactorings are never safe and need supervision from a human.
Did you notice that the "Refactoring Browser" calls itself just that, not "Automatic"?
Because it can't provide that guarantee. Even renaming a function is dangerous and can break a program when you don't have type annotations.
I have a lot of respect for Smalltalk and the pioneering work it accomplished, but the refactoring browser was just a powerful string replacement engine, nothing more. Which is not a knock on the engineers and scientists who invented it: it simply, mathematically, could not do more than that.
> Without type annotations, refactorings are never safe
There is a difference between "I can prove this is safe" and
"this is safe". You guys need to start figuring out the difference between theory and practice.
Please. With all due respect towards Smalltalk and all the pioneering work it did, stop it with the Refactoring Browser as a shining example for automated refactoring.
No, it really can't, not with the correctness guarantees of a statically typed language.
If you are required to run tests to do refactoring, you're simply not on the same level.
The last paragraphs in this link for an example (Ironic title, I know. :) ):
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 typing as major potential problem when started years ago does not make it actual problem today.
This may depend a lot on coding style and uniformity of coding conventions, something likely to be the case on the Smalltalk system (as it was designed by a small and focussed team) and less likely to be the case on a system using many different libraries, some of which might have names conflicting with names you use.
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.
Yours is first and foremost a theoretical argument. The authors of the Refactoring Browser and I understand these theoretical concerns (about not having static type safety). However, there is theory and there is practice. The two are not identical, and practice trumps theory (see also: science). And in practice, that theoretical concern appears to not have been an issue.
You also argue with hypotheticals (may...depend, likely be the case etc.). Why is that so? Is it because you can't accept that reality doesn't conform to your theory?
Once again: the argument was "you can't". That is as patently false as can be, in reality is it not just "you most definitely can", but "this system is extremely well suited for building this type of tool and in fact the whole category was invented on that system".
And your theoretical concerns notwithstanding, people who have actually used the system consider it best-of-breed.
A scientific approach adapts theory to observation. Theology adapts observation to theory.
> You also argue with hypotheticals (may...depend, likely be the case etc.). Why is that so?
Partly because my experience with Smalltalk has always been that my experience is less positive than what others claim to encounter (this is not just about refactoring, where at least once I wanted to rename a method, but this method name was also used in a different context where it shouldn't be renamed, typing would have made this irrelevant; but also about things like Monticello where I got far more conflicts and things that didn't work out of the box than I consider reasonable or knew how to handle). This may have been the way I got introduced to the platform, but it colors my skepticism about the generality of the observations.
Well, he/she isn't saying anything about smalltalk, but talking about python. Are you sure these two pose the same problems when it comes to automated refactoring? Apart from just lack of static typing, these languages could be miles apart when it comes to how dynamic they are and what problems this poses to automated refactoring. For example, the fact that attribute access in python can be delegated to a function that will receive the attribute name as an argument and decide whether that object has this attribute or not and what it is, or the fact that you can dynamically generate a new class whose attribute names and implementation come from outside as function arguments. How would you deal with automating the renaming of such an attribute when it is defined and used across wildly varying circumstances. I have no idea if smalltalk can do this, or even if my examples are good examples of showcasing the automated refactoring problem, but just raising a point.
> if my examples are good examples of showcasing the automated refactoring problem
They're not.
More to the point: Smalltalk is as dynamic a language as practically possible and was like that for two decades before Python existed. The `__getattr__` from Python, `method_missing` from Ruby, and `__index` from Lua are all inspired by Smalltalk's `doesNotUnderstand`. The concepts of metaclasses and first-class message sends was invented in Smalltalk. The idea of inspecting code using a GUI instead of flat text files also originates with Smalltalk. Refactoring, as noted by GP, also came out of Smalltalk-land. Smalltalk gives you all that without any static typing in sight.
How? Smalltalk is special. Normally, you have your code: a static blueprint of what's going to happen; and a program: part of computer memory which your code gets loaded into and gets executed. This is true for both statically and dynamically typed languages: the familiar type something -> hit "Run" -> see if it worked cycle works equally well in Java and in Python.
Smalltalk is not like this. With Smalltalk, all you have is a program. It's always running. You hand it the code and it patches itself dynamically in memory. The classes are live objects you can query. Metaclasses are, too, objects you can query. They implement methods for refactoring. It's easy, because there's no need for any parsing, statical analysis of any kind: you just iterate over all the classes in your system and ask them one by one: "do you call such-and-such method?" And the classes inspect themselves and say: "why, yes, I call it when handling such-and-such messages, here's the list".
Really, Smalltalk is special. It's not unique: Forth and Common Lisp come to mind, Self, Lua and Io too. But it's special and very few modern languages come close to its capabilities.
I often use WebStorm (Intellij variant), and I am continually annoyed by its inability to keep up with my typing. I do like the IDE, but I do wish it was more responsive. It often feels like a heavyweight, taking long to do any operation, especially starting up.
I've never seen anything that tried to do intellisense in JavaScript that wasn't slower than molasses. The quickest way for me to get Visual Studio to crash is to open two or three small .js files, watch the memory usage skyrocket, and the editor speed grind to a halt.
The only problem with Steve's rant is that he starts out describing his experience with APIs, but then it turns into an issue of better languages.
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.
Extension functions as mentioned are extremely useful. There's just some functionality you need on different types of Android classes (especially views, activites, and fragments) very often but it really isn't worth it to subclass it since not all views or activites need all of the functionality.
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
What's the advantage of extension functions compared to plain functions?
fun String.shout() = this + "!!!"
fun shout(s: String) = s + "!!!"
Looks pretty much the same to me. Extension functions use static dispatch so what's the point of using member syntax?
Also, extension functions can be overwritten by a member function with the same signature. That seems quite fragile to me considering the class and the extension function very likely have different authors.
That said, I don't know Kotlin very well. So perhaps you can set me straigt on any misconceptions I may have.
Besides what Larrikin said, discoverability. Discoverability is the killer feature of languages designed for IDE support that you just won't understand if you haven't seen it. It's a big reason of why Kotlin beats Scala in practice, IMO (1).
I code Elixir a lot these days and spend a lot of time looking at hexdocs.pm and occasional library source code. With Kotlin or C#, this is seldomly necessary, because the IDE's autocomplete tells you everything you can do with this object. It doesn't guess, it knows. If it's in the list, you can do it, if it's not, you can't.
Now, if I have a string object called "str", and I write "str.", I want to see a list of everything I can do with it. But a MyStringUtils.shout() is never in that list, because it does not come after the dot.
With extension functions, this becomes possible with userland extensions to existing classes and interfaces. All you need is a single import on top, and good IDEs (eg. visual studio) can also auto-import that one if you use a function from it once.
(1) Last I tried, Scala was too slow to compile to provide 100% perfect autocomplete within a few milliseconds. IntelliJ did some Python-esque guesswork to mitigate that, but that effectively reduces the feature to "save me some keystrokes", i.e. not very useful. Maybe this has been fixed since.
I used extensions with multiple receivers for adding context inside data-structures.
Example: I have a layout-algorithm for a grid that takes sections:
interface Section {
val title: String
fun something()
}
Then I have the grid-algorithm. Inside I store expanded/collapsed state for each section. When I use a member-extension with both receivers I can write that pretty conveniently:
class GridLayout(sections: List<Section>) {
/* the state */
val expandedSections = mutableSetOf<Section>()
/* the extensions I need in this context */
val Section.isExpanded get() = this@Section in expandedSections
fun Section.expand() = expandedSections += this@Section
fun compute() {
...
if (!section1.isExpanded) {
section2.expand()
}
...
}
}
I use extension functions on classes I don't own to add functionality I think the class should have had or would be extremely useful for my project if a certain type of class had the functionality. Your example would require a static utility class in Java or an object in Kotlin to use every where, the extension functions can just be inside of a kotlin file.
So the difference would be in Kotlin
object StringUtilClass() {
fun shout(s: String) = s + "!!!""
}
import StringUtilClass.*
StringUtilClass.shout("I'm mad")
vs
fun String.shout() = this + "!!!"
import StringExtensions.*
"I'm mad".shout()
Kotlin doesn't always add brand new functionality, it also strives to make it faster to read and write code.
I was asking myself the same question, then he wrote:
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.
I don't think it's Java fault per se, just the API design. Java8 streams, RxJava, BufferKnife injection, Guava, etc are pretty nice to use, especially in combination with Java8. There's no async/await, but if you use ReactiveX, you don't really need it.
Kotlin looks very nice, I'm just pointing out that if the Android View/Fragment lifecycle design is an issue, language design isn't the cause or solution, and most likely, you will need a middleware/facade to mitigate it.
I don't know Kotlin but I have done both IOS and Android programming and they both have their plusses and minuses compared to each other. I am not a superstar programmer like Yegge, learned IOS first and Android seemed really weird coming from that background but I eventually grokked it and converted existing IOS app to Android, and next few apps we did I wrote it for Android first.
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.
I think Steve is unjustly being harsh on the Android API, probably because he's not very experience with it, and I suspect that he'll be hard pressed to produce an example of an API that's completely ugly with Java but is somehow good with a Kotlin wrapper.
> 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.
I agree. The Activity and Fragment lifecycles that create such a pain are based on architecture decisions, not language. Kotlin can't overcome the fundamental fact that activities are stateless, and all the knock-on effects this creates.
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.
So did Delphi handle dynamically resizing and positioning layouts? My impression is all the old highly productive gui languages (Delphi, Visual Basic, ...) used absolute positioning. Personally I'd rather have a more complex gui framework (css, swing, wpf) that handles positioning than to be forever cursed tweaking pixel width, height, x, y values.
It has anchor layout, flow layout, table layout, etc... I have typically found it easier to do the layout I wanted in delphi than CSS. The only annoying thing is that the visual designer has no undo, which you really miss when doing exploratory designs.
CSS 2 really is terrible. There's a few things in CSS 3 that make it passable, but overall I consider it a failed layout system which needs more workarounds than it provides solutions.
I had to do maintenance on an old winforms app recently, it's insane how simple it is to develop with, how quickly it starts up and how quickly it show users the data they want. I signed myself up as the project maintainer.
And even that is an incredibly bloated technology compared to delphi.
I've been writing web apps for 20ish years, and also still can't see productivity catching up to what we were doing with Delphi and other desktop uis 25 years earlier... not even with react and all these other webpack/babel heavy things.
Haven't looked at Delphi since last century, but it seems it's still alive, and can produce iOS and Android (and all the desktops) programs. No idea how well though...
It's rubbish. Worst IDE I've ever worked with, sometimes I consider just using Notepad. No day without crashes, random errors, intelliSense not working, debugger suddenly not showing variable values, code navigation not working...
Embarcadero is just milking companies that need Delphi for legacy code.
Two thoughts. First, I also thought Android programming was horrible at first, but have since come to see it as no worse on average than iOS programming. The only really sucky thing about it IMO is the lack of ability to pass an object to another activity without serializing it (or maybe there is one I don't know about.) But since everything is done with fragments now that's moot anyway.
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.
It's hard to pass objects like that because it's a terrible idea. If you can't serialize the object then your state isn't stored and you'll possibly lose that object on a screen rotation and activity restart.
No, you don't understand. The state is serialized and stored. You might navigate away or pop into a windowed state. These things might rebuild your activity and the idea is your state should be serializable. The idea is every activity can be restarted outside of your control and your state should be fully storable.
It has implementation issues - you get to use a crusty ContentProvider or manually serialize everything into also crusty Bundle. Then you have that separate SharedPreferences thing. Or you can do it on your own, typically more cleanly, with an object database.
Instead it would be often fine if it just took a Java Serializable and ran with it, just call you back so that you can read all the state and redo whatever you need to redo.
Likewise IPC with Intents is pretty crusty as is with Binder, though bit less with the latter.
You can always handle the orientation change manually if you want to. But if you don't want to bother, restarting the Activity seems like a reasonable default.
The passing of things from activity to activity does feel vaguely boilerplatey, on the other hand I have to review my colleagues' IOS code from time to time and there's always an issue with a view loading data, then loading a view on top of that with another different set of data, and so on, until the app runs out of memory that I'll have to fix by making it work like the Android app by serializing all the data when the views disappear.
We could fault the design for stacking all those views but that's another issue.
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.
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...
Well, is he? He was talking about JavaScript on the server side even before Node.js existed, and now we see that it took off as one of the most popular platforms, surpassing Ruby on Rails.
Netscape Enterprise Server was shipping server-side JS in the 90s. I used LiveScript in a project (it could also call into JVM classes). NES was nasty to setup and configure and there were oodles of limitations, but Node.js didn't invent the idea of server side JS, it just made it practical.
Well, here he says that kotlin is better than java, not that statycal typing is better, so it's not an argument in favor of one of those "all frog legs and calf brains and truffled snails" languages;)
Is 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?", 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.".
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 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 :)
And Kotlin is targeting LLVM too. It's too early to tell how that will work out considering that much of Kotlin is dependent upon Java libraries, but it's promising.
For certain classes of problems the JVM just cannot be beat. Its a phenomenal bit of tech that laps the competition, especially with regard to large data sets, concurrency support, and instrumentation. Unfortunately, Java the language is fairly painful to work in (less so every release but still). Kotlin makes that particular problem less of an issue.
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.
Erlang is probably the closest competitor to the JVM and is a fine VM in its own right (especially for classes of concurrency problems that can operate independently).
But if you are dealing with a big interconnected data set that also needs to be concurrently accessed the Erlang memory model doesn't work as well as the JVM one.
For the kind of concurrency model that Erlang is offering it is great, but the JVM offers more variety, so that you can craft your concurrency to your problem instead of being shoe horned into 1 model.
I'd add that the commercial offerings for the JVM (and alternative JVMs like Zing) make the ecosystem more rich than the Erlang one as well.
Finally, I'd say that Erlang suffers from a similar problem to Java, that is, the VM is without peer for certain classes of problem but the ergonomics of the language make people choose other solutions. I think that is a shame as I'd like to see more solutions built on top of BEAM.
I should note, I've not programmed on BEAM for production purposes, only for small projects, but the reason for that is largely those that I mention above.
The "ew gross weird" reaction to Scala and Clojure is tremendously disappointing (especially coming from someone whose thesis is basically "give this new language a chance")
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 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.
I work with some larger Scala codebases too and the compile times are not that bad either. Maybe 30 seconds is more common for the large ones. Certainly not worse than C++, only a bit slower than Java.
>2. Modify your IDE habits to be more REPL friendly
Plenty of people use IDEs, I just think if that's what your main sticking point when picking a language, go with C#. It has the best IDE of any language.
>3. Modify your team coding habits even if it makes it hard for one person to work on the other person's codebase.
Nope, not a problem. I can work on any code base in the company. It's spooky how fast we can jump into others teams projects and contribute, and a lot of that is due to the power of the language.
Also, re: 1...you don't have to use microservices. You just need non-monolithic compilation units. This just means breaking up your application into library code that doesn't need re-compilation.
GF mentioned microservices because they end up forcing this by design, but nowhere does it say "you must use microservices or else get horrible compile times"
But the thing is if you modify your habits, it's so much more efficient than most other languages. It's reasonable to have to learn knew coding style when paradigm-shifting languages. Why isn't it reasonable for there to be other new behaviors as well?
Hah no there aren't. I work in Haskell (one of the few languages that is as or more efficient as Scala) and these things still arise with it. And they're not a problem because you do them and you end up programming better than in a language without these things :)
Scala IDE support is bad? What IDE are you using?
I find IDE support in IDEA almost on par with that of Java. It is very fast, has accurate error highlighting, very good smart autocomplete, understands advanced Scala features, supports most refactoring I care of, but most importantly works reliably.
I've used IntelliJ for Scala some time and did encounter way more IDE bugs than in Java. I think JetBrains did a good job, but Scala is not engineered towards tool support. That is one big flaw of the language.
Kotlin is much more pagmatic (not only) in this regard, what is no surprise coming from a tool vendor.
I also encountered way more IDE bugs in Scala than in Java. Actually during the full last year of development of a real-world commercial Scala project I encountered 0 bugs in Java and 2 bugs in Scala.
What about more objective measures?
Scala plugin issue tracker: 11667 issues.
Kotlin plugin issue tracker: 17664 issues.
And this difference is despite Scala being longer on the market and being more popular than Kotlin.
It looks like Scala IDE support is actually better than that of Kotlin.
How on earth is this an objective measure for plugin quality? There's so much you can interpret into these numbers that they are borderline meaningless.
It is objective measure - it may not be a perfect metric, but definitely objective. If there are more issues relative to the number of programmers this means there are either more bugs, users have more questions, and/or just more feature requests (which means - the plugin is lacking features). Also both plugins share the exactly same bug tracker and the same issue filing process, so you can't argue it is easier to report errors for one over another.
Scalaz, Http4 for web stuff, Netty/scalaz-stream otherwise. We really don't need "frameworks" to be insanely productive in Scala, just a few tried and true libraries. This also really helps when jumping into new projects, there's never "magic" beyond just the features the language provides.
Agreed as far as it goes. But can one person really understand a 2 million line codebase? Can a team large enough to use a 2 million line codebase stay in close enough communication that they all know what each other are doing? IME to stay sane on a codebase that large you need separated components with strict separation between interface and implementation and independent versioning of each, at which point you might as well make that split at the module/VCS level and take advantage of what your tools can do for you.
I think it has changed for good. There are also initiatives to simplify Scala (e.g: dotty), and initiatives to go native (e.g: Scala native via LLVM). I think Scala has some good potential.
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.
I'm glad to hear Steve Yegge's take on Kotlin. I've played with it some and thought it was quite interesting, and I wouldn't mind doing a project in it sometime. Although I don't use Java much, I'm more into Rails for personal projects, and I'm not about to switch any of them to JVM just to play with Kotlin.
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.
Kotlin is really nice and I am very happy to have more than one great/fun/productive language however I feel like mentioning typescript might be worthwhile (yes I know it's "just" a superset of JS and you have a personal gripe with whatever you think JS is but hear me out).
* 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
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've also been coding Java professionally for 17 years and like you I feel Java is a great little language. What makes the biggest difference in productivity is the simplicity of the algorithm and associated object oriented design, and I've never really felt that Java was hindering me in achieving that simplicity.
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).
Why do you think data classes are dumb? The only thing I think they're missing is an automatic method to serialize to JSON or other text format, eg, so they can be easily stored in an android preference.
Side note: Even if you're not interested in Kotlin, or don't know Steve Yegge, give a read to this blog post.
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.
>And Android has some pretty big red-light APIs. Fragments, for example, are a well-known Flagship Bad API in Android.
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.
Interesting - I thought it was just me. I couldn't comprehend the way they are supposed to work until I spent lots of time figuring it out. And then I had a year off Adndroid and when I came back I couldn't make sense of my own code... awful interface. I have no idea why they didn't replace it with some better concept.
It's impressive to see Kotlin finally getting some traction. The first time I heard of it was years ago: I was doing a piece of competitor analysis at Red Gate and I clearly remember reading about it and having a distinctly "whatever" reaction.
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.
As soon as I saw "blah blah blah (steve-yegge.blogspot.com)", I came looking for this comment. I hope he keeps it up. Also, apparently he actually "came back" back in November[1]. That post is even sort of related.
Because IntelliJ does a lot of work. Similarly, Visual Studio is not usually slow but sometimes it will mysteriously become so slow as to become unusable, or at least that was true a few years ago when I spent a lot of time in it.
Visual Studio is a hosting environment for Resharper. And Resharper makes it awfully slow. IntelliJ compared to VS (even without Resharper) is like Emacs compared to IntelliJ.
IntelliJ is written in Swing, which 10 years ago was certainly slower than an alternative UI framework like SWT. Not sure if there is a noticeable difference nowadays.
With IntelliJ using Swing as a major vendor and showing its potential, is there a chance for getting a new developer community behind Swing/geom2d? Or is IntelliJ in the progress of migrating away to something else?
Asking because I'm having an old (but useful) Java2D diagramming app lying around that I'd maybe like to lift, but the lack of a future perspective for java2d and Swing always held me back on working on it. I don't even know if java.awt.geom can handle HiDPI these days. Would be a pity to loose it, since java 2d certainly is a useful programming model for these kind of apps; what's missing is commitment (by Oracle or other party) to it.
What makes me nervous about Kotlin is it could become Scala (or even Groovy) again.
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.
. 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.
It seems to mostly be compared to Java. Sure, if you don't like functional languages or dynamic languages (Jython, Groovy, JRuby) then I guess it's the best high profile JVM language.
You can and should build your domain language on whatever base language you happen to like/use. This is where most failures happen on big projects. If you treat your solution as a script or glue code, and your complexity needs to scale, you will quickly reach a stalling point.
A good, well thought structure & design is required,there is no language available (yet) that will replace that.
the title has been made politically correct - the actual title is "Why Kotlin Is Better Than Whatever Dumb Language You're Using". I wonder if that was intentional editorial oversight.
i wonder what server side platform are they using ? there's been a lot of buzz around vertx+kotlin or Reactor ... and with android support, it is a very compelling stack to have for android focused startups.
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.
Good question. I would also be interested in seeing some concurrency related benchmarks. Clojure excels on that field due to immutable data-structures. There's simply no point of talking about concurrency without immutability.
Honestly, I can't think of anything that is not bullshit. Having to declare a new variable for each parameter that you need to manipulate makes the code a lot messier.
It's a trade-off. Yes, the code is messier for the 20% of functions where the input is manipulated. For the remaining 80% it makes it slightly easier to analyse the behaviour of the function.
I understand that. But I think it's better to let the programmer decide whether their parameters are mutable or not. Then you don't have to compromise.
Why my programming languages are smarter than whatever dumb writer that
knows nothing about my toolset and my needs is at hand with his trivial
cliches.
> whatever dumb writer that knows nothing about my toolset
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.
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.
He writes entertainingly (and clearly has a talent for the written word) but I'm not convinced he's got any genuine insight into programming. Put another way: he seems to be just as convincing when he's wrong as he is when he's right.
>Actually, to TFA as well. His arguments are trivial generics without much substance. Such articles irritate me greatly.
Well, it is a personal blog post and this post in particular is meant to convey personal preference (as evident by the whole semi-autobiography about his game app). The title was probably jokingly chosen to be generic on purpose (the post alludes to that in the fist paragraph).
Ah, see, a Yegge blog post isn't an article, it's an essential touchstone of the computer geek experience. You don't get persuaded by his arguments, but instead… delighted, filled with whimsy, and joy?
sarcasm off, his posts also fall south of my reading:substance ratio
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.