
Kotlin Is Better - praxxis
http://steve-yegge.blogspot.com/2017/05/why-kotlin-is-better-than-whatever-dumb.html
======
bpicolo
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.

~~~
sreque
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-...](http://stackoverflow.com/questions/282377/visual-studio-how-do-i-show-all-classes-inherited-from-a-base-class). 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.

~~~
ptx
Kotlin has incremental compilation since 1.0.2 last year, both in IntelliJ and
Gradle: [https://blog.jetbrains.com/kotlin/2016/05/kotlin-1-0-2-is-
he...](https://blog.jetbrains.com/kotlin/2016/05/kotlin-1-0-2-is-here/)

...and in Maven since 1.1.2:
[https://blog.jetbrains.com/kotlin/2017/04/kotlin-1-1-2-is-
ou...](https://blog.jetbrains.com/kotlin/2017/04/kotlin-1-1-2-is-out/)

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

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

~~~
andybak
And this paragraph:

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

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

------
barrkel
Other language built around IDE support: Delphi.

The compiler was built with callbacks to provide code completion; it runs in
process, as a DLL, as part of the IDE.

No accident that Hejlsberg also design C#, and innovated further with
TypeScript's language server. He wrote the original Turbo Pascal (IDE +
Compiler in the same executable) in assembler, so he's been building IDE +
language combos all his life.

~~~
comboy
Oh Delphi.. every time I fight with CSS and think about how easy making GUI
apps used to be almost 20(sic!) years ago, I feel like something went wrong.

Mandatory:
[https://www.youtube.com/watch?v=8pTEmbeENF4](https://www.youtube.com/watch?v=8pTEmbeENF4)

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

~~~
bitL
Yes, if you set anchors on each component you wanted to be resizable (more
specifically, all four sides could have had an independent anchor).

~~~
flukus
Same with winforms. I'm not sure if it was added at some point or always
there, if it was always there I wish I knew about it a lot sooner.

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

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

~~~
sidlls
It's a pretty terrible design to couple activity state to the physical
orientation of the device.

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

~~~
sidlls
No, I understand the Android Activity lifecycle quite well. I think it has
severe flaws from a design perspective.

~~~
AstralStorm
Not from design, no. Design is pretty sound.

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.

------
runT1ME
Does anyone remember when he wrote this?

[http://steve-yegge.blogspot.com/2008/06/rhinos-and-
tigers.ht...](http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html)

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.

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

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

~~~
emodendroket
> blog about things I only had cursory knowledge of

Also known as "blogging."

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

~~~
haspok
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 :)

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

------
pje
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")

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

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

~~~
thr0waway1239
You might have actually convinced people to not consider Scala. You are
saying, Scala is great, except for these small things:

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.

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

~~~
mateuszf
Because there are other languages, which also provide the benefits, but
without these downsides.

~~~
whateveracct
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 :)

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

------
BJanecke
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
    
    
       ```
        function pluck<T>(key: keyof T, from: T[]) {
           return from.map(item => item[key]);
         }
       ```
    

* First class functions

* Incredible flexibility
    
    
       * sketch in js then annotate  
    
       * decide on strict nulls
    
       * decide on implicit types
    
       * various approaches to composition 
    

* Amazing IDE support(VSCode)(This technically falls under tooling ;))

* One of the few cross-platfrom languages that feel pretty much identical on all the platforms

[edit] Formatting

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

------
Tharkun
Yet Another Java Rant.

In my book, Java is a fine language, and has been since Java SE 6 was released
back in 2006. It keeps getting better, too. "Glacial" pace or not.

Whenever any kind of discussion about Java comes up, people start ranting
about XML configuration or annotations. These are not language problems. These
are developer problems. If you don't like XML or annotations, then don't use
them. Problem solved. 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.

~~~
specialist
Kotlin (Ceylon, C#, Nice, Boo, Groovy, etc) isn't better. Just different.

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.

[https://kotlinlang.org/docs/reference/data-
classes.html](https://kotlinlang.org/docs/reference/data-classes.html)

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

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

~~~
lokedhs
It's not so much that fragments is a bad idea as a concept. It's that its
implementation is a textbook example of bad API design.

I dovt know about other people but I certainly end up cargo culting every time
I want to use the fragments API.

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

------
charlieflowers
The biggest news is: Yegge is blogging again! Glad to see it!

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

[1] [https://steve-yegge.blogspot.com/2016/11/the-monkey-and-
appl...](https://steve-yegge.blogspot.com/2016/11/the-monkey-and-apple.html)

------
andrewstuart
A few people have said that IntelliJ is slow.

Why is this so, if Java is not inherently slow?

Sure JetBrains are some of the smartest developers around and yet their IDE is
still slow.

I can't help but feel that Java is slow and problems with performance in
something like IntelliJ do nothing to dispel that feeling.

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

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

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

------
RandyRanderson
So this guy has [0]:

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

[0]
[https://en.wikipedia.org/wiki/Steve_Yegge](https://en.wikipedia.org/wiki/Steve_Yegge)

------
codecamper
Just wanted to point out that Kotlin is not from Russia. It's from Prague,
Czech Republic. Almost the furthest west you can go and still be Slavic.

Maybe the founders of Jetbrains are Russian. Not sure.

edit: aha Kotlin is in fact developed in Russia. From Russia with love!

------
askvictor
Fwiw, jetbrains originates in Prague not Russia; although the kotlin dev team
is based in Russia.

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

~~~
manojlds
Scala?

~~~
iLemming
Arguably Kotlin was actually created to address some deficiencies of Scala.

------
zengid
>How many languages can you name that were built with IDE support from the
ground up?

Visual Studio Code is pretty nice with TypeScript. I've enjoyed having the
autocomplete for my little Phaser game.

------
sigi45
Awesome article! Not one practical comparison between java and Kotlin.

Anyway as any hype like scala and co. Java works very well, has small issues
and no issue which really hurts me.

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

------
ensiferum
How exactly does kotlin fix the bad Android apis? You'd imagine that you still
have to deal with the apis.

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

------
chrisallick
Great article. Slamming android and talking about Russian software. Click bait
to boot? Sold.

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.

~~~
saimiam
Hello fellow Obj-C fan. I tried to teach myself Swift much like I taught
myself Obj-C. It didn't feel right.

~~~
JustSomeNobody
Funny how that is. Some language just click with certain developers.

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

~~~
smichel17
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...](http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-
library/) [1]: [https://github.com/raatmarien/red-
moon](https://github.com/raatmarien/red-moon)

------
i386
Kotlin wouldn't be happening if Java was shipping things developers actually
cared about.

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

~~~
norswap
It's been changed. Lol at that.

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

------
rev_null
Better than Java seems like a pretty low bar.

~~~
MarkMc
Curious: what language would be a high bar?

~~~
rev_null
Rust, Haskell, Lisp, Smalltalk. There are a lot of languages out there that
are already better than Java.

------
gigatexal
Makes bold claims, but shows no code.

------
anjanb
Anyone knows how it performs versus, say, Clojure for server-side development
?

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

------
awinter-py
intellij is soooo sloooow

------
r3m3mb3rm3
Having all parameters to be read-only is a deal breaker for me.

~~~
andrewstuart
There's got to be a good reason why though?

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

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

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

------
gankgu
golang is better.

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

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

Or possibly not. I personally miss his rants.

~~~
andybak
[http://steve-yegge.blogspot.co.uk/2006/03/execution-in-
kingd...](http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingdom-of-
nouns.html)

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.

