Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin Is Better

steve-yegge.blogspot.com

Post reply on HN
Print view View original

191–200 of 229 posts

Re: Kotlin Is Better

#191

Post by shawkinaw »

randomsearch wrote: post #86
shawkinaw wrote: post #5

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 li…

> I also thought Android programming was horrible at first, but have since come to see it as no worse on average than iOS programming Those two statements are in no way mutually exclusive. (That said, Swift is infinitely better than writing Android Java code, in my limited experience)

Heh, that's true. I should have also mentioned that I generally enjoy iOS programming :)

Re: Kotlin Is Better

#192

Post by breischl »

_ivvf wrote: post #147
bpicolo wrote: post #20

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 somet…

I developed at a Windows-centric shop for several years using C# and Visual Studio, and I can personally attest, at least in 2013, that stock Visual Studio is pretty far behind Java IDEs in its capabilities. At the time everyone I talked to recommended I get my manager to get me a copy of ReSharper, but it wasn't in our team's budget. At least in 2013, here's where I remember C# IDE support was lacking: * No automati…

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.

Re: Kotlin Is Better

#193

Post by smichel17 »

newsat13 wrote: post #133

I don't get it. How does Kotlin actually solve Android's fragment/activity issues?

It doesn't, but it eases a lot of frustration in other areas, which makes fragments slightly more bearable.

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

Re: Kotlin Is Better

#194

Post by WorldMaker »

douche wrote: post #137
Kipters wrote: post #103

Earlier quoted context omitted.

More often snippets like this can be even more straightforward: var somestuff = from x in someList where x.Id > 7 select x.Name

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.

Re: Kotlin Is Better

#195

Post by kiallmacinnes »

seanwilson wrote: post #179
Singletoned wrote: post #154

Earlier quoted context omitted.

We tend to use tests for just this case. You change anything you want, then see which tests break, and fix all the places. I definitely agree that dynamic typing doesn't scale as well as static typing, though.

> 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 tes…

> rely on good enough code coverage to catch this

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).

Re: Kotlin Is Better

#196

Post by WorldMaker »

bpicolo wrote: post #152
skrowl wrote: post #143

Earlier quoted context omitted.

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 su…

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.

Re: Kotlin Is Better

#197

Post by btschaegg »

pjmlp wrote: post #139
btschaegg wrote: post #112

Earlier quoted context omitted.

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 o…

> 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?

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).

Re: Kotlin Is Better

#198

Post by wtetzner »

kiallmacinnes wrote: post #195
seanwilson wrote: post #179

Earlier quoted context omitted.

> 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 tes…

> rely on good enough code coverage to catch this 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…

> Wait, you don't enforce 100% coverage? (Sorry, couldn't resist ;))

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.

Re: Kotlin Is Better

#199

Post by cel1ne »

fauigerzigerk wrote: post #172
cel1ne wrote: post #95

Earlier quoted context omitted.

If you got time, play around with extensions with multiple receivers, you can do pretty neat stuff with them. See my comment here: https://news.ycombinator.com/item?id=14365317

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…

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) {

        /* the state */
        val expandedSections = mutableSetOf()

        /* 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()
            }
            ...
        }

    }

Re: Kotlin Is Better

#200

Post by seanwilson »

kiallmacinnes wrote: post #195
seanwilson wrote: post #179

Earlier quoted context omitted.

> 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 tes…

> rely on good enough code coverage to catch this 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…

> 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.

Post reply on HN