Kotlin Is Better(steve-yegge.blogspot.com) |
Kotlin Is Better(steve-yegge.blogspot.com) |
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...
Don't feel bad, Sergey Brin also thought he was annoying at one point in time.
Personally I think it's cool that he's well known enough to annoy Sergey Brin but that's just me.
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.
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 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.
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.".
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 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.
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.
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.
.NET Core is awesome, but don't forget that it's not the first time .NET has been available to Linux developers.
Also known as "blogging."
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.
Embarcadero is just milking companies that need Delphi for legacy code.
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.
var somestuff = from x in someList
where x.Id > 7
select x.Name var somestuff = from x in someList
where x.Id > 7
select x.Name;
var somestuffList = somestuff.ToList();
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.
Inevitably, this is what CSS work devolves to, though.[0]
[0] Pixel twiddling
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.
This was an explicit decision to make functional programming more palatable to mainstream developers.
Have you read the paper from Erik Meijer?
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).
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).
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.
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.
fun String.shout() = this + "!!!"
fun shout(s: String) = s + "!!!"
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.
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.
Example: I have a layout-algorithm for a grid that takes sections:
interface Section {
val title: String
fun something()
}
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()
}
...
}
}So the difference would be in Kotlin
object StringUtilClass() {
fun shout(s: String) = s + "!!!""
}
import StringUtilClass.*
StringUtilClass.shout("I'm mad")
fun String.shout() = this + "!!!"
import StringExtensions.*
"I'm mad".shout()
import StringUtilClass.*
shout("I'm mad")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.
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.
> Patently false.
It's a mathematical fact.
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.
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.
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. :) ):
Smalltalk authors seeing static typing as major potential problem when started years ago does not make it actual problem today.
> 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.
1. Modify your codebase to use microservices
2. Modify your IDE habits to be more REPL friendly
3. Modify your team coding habits even if it makes it hard for one person to work on the other person's codebase.
>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.
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"
It can.
> 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.
Very specifically was: "(and yes, that includes Smalltalk IDE's)"
Kotlin is much more pagmatic (not only) in this regard, what is no surprise coming from a tool vendor.
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.
Back then, most of the team was using Eclipse, which was awful! IntelliJ's support was better, even then... but still sluggish.
What framework or library are you using to write said services?
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.
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.