Kotlin vs. Java - <AUTHOR> https://www.kotlinvsjava.com <comment><USER2> The I/O example is moot since Java 11 where Java got [https://docs.oracle.com/en/java/javase/13/docs/api/java.base...](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/nio/file/Files.html#readString\(java.nio.file.Path\)), so we can do `Files.readString(Paths.get(doc.txt))`.

Java 14 is getting an experimental preview of Records ([https://openjdk.java.net/jeps/359](https://openjdk.java.net/jeps/359)) which takes care of much (but not all) of ceremony around "data classes".

And Java 13 got a preview of text blocks, [https://openjdk.java.net/jeps/355](https://openjdk.java.net/jeps/355).

Things are coming. That said, I hardly believe those minor syntax improvements are what is so "good" about Kotlin. It has some better defaults (non-null by default, final classes by default), and is a more modern language. Java will stay with us for many years to come, though.

<comment><USER3> I wonder if Java's speeding up of new language features over the past several years, after many years of a stagnant feature set, is a direct result of pressure from the likes of kotlin.

<comment><USER4> It is mostly C# that is keeping Java on their toes. Java competes with C# than any other language in this world. In the enterprise space, it is either Java or C#. If you check most of their improvements, they were done ion C# first, then they follow.

<comment><USER3> kotlin copied a lot from C# first.

<comment><USER5> Now that is a good strategy. Copy directly from a language that is moving at a very fast pace and competing directly with the language you want to replace.

<comment><USER6> Kotlin will never replace Java, unless you are speaking about Android Java.

<comment><USER7> Of course it won't ever replace it but it has the potential to overtake it.

<comment><USER6> Maybe when I see the first JVM written in Kotlin I will consider that scenario.

Even considering ART as the KVM, isn't a safe deal, as it is written in a mix of Android Java and C++.

And currently its potential is very tiny when measuring all JVM guest languages against Java, using any recent language report.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Frankly, I find Kotlin syntax a lot more meaningful as it contains much less boilerplate code than Java. And the same time, though, I believe Kotlin can only be truly appreciated if you are coming in from experience with Java.

The thing I found hard at times with Kotlin is that it allows/relies on Java classes/frameworks but almost all of those classes/frameworks have their documentation (and only resources) written in Java so you have to have that additional mental step of translation between the two languages.

If you are not competent with basic Java, you may struggle to utilize those Java classes in Kotlin effectively.

Finally, when it comes to hiring people/finding job for Kotlin development, outside of Android jobs, there are very few positions requiring Kotlin which in terms means that there are very few non-mobile developers working with Kotlin as compared to Java. Now this may not be that much of a concern to us Developers, but for Management and leadership, it can raise a big concern towards adopting a language which from perspective of labor market comes across as a niche.

Having said all this though, I have no doubt at least in Android development, Kotlin will replace Java as programming language of choice but I don't think it will find traction beyond mobile (to displace / challenge Java).

<comment><USER9> I think I can confirm your sentiment. As far as I can tell, which, however, is not much as pertains to the JVM, apart from polyglot projects, Kotlin is a rarity.

I'm rather unfamiliar with Kotlin as a language. Is Kotlin for Android rather idiosyncratic as is Android Java? In other words, is there a superset of language features in Kotlin that goes beyond Android and is more expressive than modern Java?

<comment><USER10> It's actually not that rare, in my experience. Job adverts can be quite misleading in this case. Kotlin jobs are usually advertised as Java jobs. For a couple of reasons:

Firstly, quite a few large shops have started to use it, but usually due to grassroots bottoms-up activity of the sort that takes a while to percolate through to recruiting departments in distant departments where changing a job req is a heavy process.

Secondly, there's really not much incentive to try and change job reqs like that because it would be extremely hard to advertise via job reqs _We use Kotlin but you don 't have to know it to apply_. To a non-technical recruiter or HR department this looks like a useless statement and will frequently get "fixed" to what you "really meant", something like "Java experience is required, Kotlin highly desirable" which might just put off candidates who don't know what Kotlin is or how easy it is to learn. You're just restricting your pool of candidates for no reason in a highly competitive market.

Much better to advertise the usage of Kotlin in places where developers looking for new opportunities might notice and leave the job reqs alone, and let Java devs get up to speed in the first few days. For example:

[https://medium.com/ing-blog/introducing-kotlin-at-ing-a- long...](https://medium.com/ing-blog/introducing-kotlin-at-ing-a-long-but- rewarding-story-1bfcd3dc8da0)

 _Edit:_ To answer your later question, yes, Kotlin goes beyond Java in a lot of ways other than nicer syntax. For instance it has a different (better) generics model, it has far more type inference, it has sealed (sum) types, it has language-integrated coroutines, it has compiler plugins that automate, amongst other things, serialization, it has delegated properties and interfaces, it has type aliases, it has extension functions etc.

I suppose a lot of these can be considered "just" better syntax than Java (except for coroutines and generics), but, at the heart of most programming languages is making patterns that are possible in other languages much easier.

</comment></comment></comment><comment><USER11> Why don't the nullability examples use Java's Optional?

This code:

      if (nullableVariable != null) {
          boolean success = nullableVariable.someMethodCall()
          if (success) {
              return success
          } else {
              return fallbackIfNullMethodCall()
          }
      } else {
          return fallbackIfNullMethodCall()
      }

Could also be written something like this:

      result = Optional.ofNullable(nullableVariable)
                       .map(NullableType::someMethodCall)
                       .orElse(fallbackIfNullMethodCall());

Sure, it's no Elvis operator, but it's a lot more readable than the "standard" if/else structure of traditional Java. If we're comparing Java and Kotlin, we should at least give Java a fair chance. I dislike the verbosity of the Optional wrapper, but it's a lot better than if/else checking.

<comment><USER12> Even the simple if/else approach can be done more cleanly (i.e. without repeating the fallback call):

      boolean success = false;
      if (nullableVariable != null) {
          success = nullableVariable.someMethodCall();
      }
      if (success) {
          return success;
      } else {
          return fallbackIfNullMethodCall();
      }

<comment><USER13> Even that seems way too much. The original would be much easier as:

      if (nullableVariable != null) {
          boolean success = nullableVariable.someMethodCall()
          if (success) {
              return success;
          }
      }
      return fallbackIfNullMethodCall();

And even that can be more concise if you prefer:

      if (nullableVariable != null && nullableVariable.someMethodCall()) {
          return true;
      }
      return fallbackIfNullMethodCall();

</comment></comment></comment><comment><USER14> This doesn't really showcase many of the best advantages of Kotlin. They should add some with data classes, JavaBeans, multiple assignment, lambdas, map/reduce/fold, extension methods, etc. I've found that Kotlin code is usually 3-4x more concise than Java, and most of the benefit is in your data structure definitions (i.e. changing 100 lines of boilerplate to a 4-line data class, or destructuring a Pair/Triple where you would otherwise have been tempted to create a new class and 2-3 lines of assignments) rather than in individual statements.

<comment><USER15> Kotlin (which I don't know) looks a lot like Scala (which I do), at least superficially. Wonder if you've had any experience with Scala to compare the two?

<comment><USER16> I did Scala first, then recently took over a codebase with both. I think the people who did Scala were not good and they made a total mess, however, their Kotlin miscroservice was actually quite nice and was the best code in the project. So I reluctantly have concluded Kotlin is a better level of expressivity. Scala is full of footguns... I love it ... but it's hard to write well.

One example was they were using enumerations and got boxed in. They had to add unit tests to ensure they enumerated all the options. Why does Scala have that feature? It's full of bad features you should avoid.

<comment><USER17> I have the same experience. Once you do more with Scala than "better Java" it is easy to create a mess full of "try to be clever" code you will regret a year later.

It is really hard to become a good Scala programmer, but it is not hard to become a good Kotlin programmer. All the little things that make Scala theoretically better are not worth the learning effort. In Kotlin you get 80 % for 20 % of the effort.

Scala is separated in subcultures. Some developers use it as "Haskell for the JVM" and other as a "better Java", or something between. That makes hiring and picking up existing projects hard.

Tooling is another weakness of Scala. Scala IDE (Eclipse) is more or less dead. IntelliJ with the Scala plug-in is ok, but the Kotlin support is much better.

</comment></comment></comment></comment><comment><USER18> I have been extensively programming in Kotlin in the last 2 years coming from a 10 years Java experience. Even Java advanced a lot from from version 8, still it is very far behind in reaching the pure joy of programing in Kotlin, especially in functional style. Immutability with 'val', data classes, functions as first class citizens, destructuring, if/when expressions, just to name a few of the features than enables this.

Also, the great 100% interoperability with Java makes possible to migrate part of your codebase to Kotlin and using tons of already proven and great libraries in the Java ecosystem. On top of the Kotlin standard library includes many improvements of the existing Java classes from collections to String, and all of this using extension functions, one very usefull and powerful feature.

I can keep going on and on, but to conclude Kotlin is not just Java with improved syntax, but completely new modern programming language incorporating or "borrowing" some of the best features from Scala, C# and other popular programming languages. So in my opinion it is a great language which has a lot more funtional features than Java, but still pragmatic and easier to learn than Scala.

<comment><USER6> There is no 100% interoperability with Java.

Try to call co-routines from Java, use SAM types with default methods from Kotlin, just for starters.

<comment><USER18> I was mostly referring to the Kotlin calling side of Java code and libraries, and yes you're technically right that would mean only 100% compatibility with existing Java code and not interoperability. But, when moving forward to using exclusively Kotlin and not building libraries that will be Java compatible that is totally ok.

<comment><USER6> Kotlin is not moving forward on the JVM given that the platform is written in Java, and Kotlin happens to be a guest language, now with JetBrains trying to build a Kotlin platform.

</comment></comment></comment></comment><comment><USER19> At it's base Kotlin is a nicer java. But it's much more. Simply looking at the syntax comparison is only half of the story. The focus at the recent conference was multi platform and concurrency.

They are making concurrency a first class citizen. With items like Go channels, Observable etc. This is baked into the language. There are a number of new frameworks utilizing these patterns. Resulting in less code, and more performance. At the cost of sometimes more difficult debugging.

The bigger item to me is multi platform. I'm working on a micro orm. That reflects your schema automatically generating types for NodeJs, Native, and JVM(Graal/JDK). It can then be run on any of those platforms. An example is libpq for postgres allows streaming and observing rows on update. This is not in the DB libraries that I've seen yet. I can have an actor run natively on LLVM, talk back via grpc/rsocket/tcp/etc. To a JVM/JS service. All while adhering to the same interface / method description.

Besides that. There are scripts for kubernetes, react/angular/vue, etc. Dukat is coming to automatically convert ts.d files to kotlin description files. For me I can have one language, one IDE, for every part of my product. From deployment, back end, data handling, front end, and mobile.

<comment><USER20> I don't see how concurrency isn't a first class citizen in Java, especially compared to kotlin/native's concurrency package which is barely a package.

<comment><USER21> Thread based concurrency where everything is blocking inside the thread is the first class citizen. If you want to move to a non blocking world, then you will suffer.

Moving between Channel and Flow sucks. No async/await keywords like Python, C#, Rust so you have callback hell. try-with-resources doesn't work with async callbacks (i.e. thenApply, thenCompose, etc.).

Also, JAX-WS standard doesn't currently support Channel or Publisher<ByteBuffer> for body types.

<comment><USER22> Java is getting green threads/fibers by means of project Loom. Arguably much more straightforward to use compared to async/await.

<comment><USER23> So when is this Project Loom set to arrive?

<comment><USER21> Literally "when it's done". This is the answer given in talks by the developers working on it.

But you have to understand that many many libraries are on Java 1.8 because that's what Android supports. Even when Loom arrives, many libraries won't use it but will rather continue to use threads.

<comment><USER10> But that's the nice thing about Loom. The direction they're heading in is upgrading the existing Java threading APIs. Maybe not "new Thread() {}" but if you use ForkJoinPool, executors, etc then it should mostly all just work. That means it won't fork the ecosystem in the same way Kotlin coroutines do (coloured functions in new languages). And even better it won't fork the ecosystem across Android either. If you use constructs that don't automatically Loomify, you can just tweak them so they still work fine on Android but get the benefits of Loom too.

BTW parts of Loom already shipped.

On the other hand, outside of certain core libraries this won't matter much. You don't do a whole lot of scalable blocking IO on phones.

<comment><USER21> >Maybe not "new Thread() {}" but if you use ForkJoinPool, executors, etc then it should mostly all just work.

Ah that's a nice way to do it. But then what happens to Channels? Are they cast aside so we go back to InputStream which blocks the fiber?

> You don't do a whole lot of scalable blocking IO on phones.

No but you can save a lot of memory, a lot of context switches, and CPU depending on the scenario.

<comment><USER10> I'm not sure but yeah, in theory you don't need more than Input/OutputStreams if you can block at will.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Whenever I see an article comparing a market leader with an underdog, I always know that the article will be biased against the market leader. It is human nature to root for the underdog. What was the reason for not starting with variables II? I suspect the author wanted to manipulate our minds right there. It is obvious that Java version is the better of the two but they decided to start with a variable with final. Ternary operator for Kotlin doesn't look like ternary to me. It is just an inline if\else.

<comment><USER24> Why is variables II better in Java? Its almost the same with advantage on Kotlin side with type inference. Also ternary operator isnt needed in Kotlin since if/else itself can return value, so its just example to show so people dont try to look for it in Kotlin. Overall its not even an article, its just a showcase of differences in syntax and idioms in both languages, i cant fathom how could you be manipulated with that.

<comment><USER5> Clear and concise to someone new to programming. Also less typing. Comparison of an a market leader to a new entrant is designed to make you switch from market leader to new entrant in the market.

</comment></comment></comment><comment><USER25> Comparing to

>>> public static void main(final String[] args) { System.out.println("Hello world!") }

Is just a glamour shot. How many times does one actually have to type public static void main? Once per application, by definition.

<comment><USER26> Isn't final optional?

<comment><USER27> Yes. And there are cases where omitting it is specifically useful.

</comment></comment></comment><comment><USER28> Kotlin is much nicer than Java, that's for sure. It strives to be compatible both ways (calling Java from Kotlin and vice versa), which I think has helped with its adoption. It also means that it cannot have very wild features that can't be mapped nicely to the world of Java, which I think has its downsides.

My main gripe with Kotlin is some of its design choices for syntax. I really really really don't like its syntax for lambdas, specifically. A code block in curly braces could be both a lambda with an implicit argument, or a list of statements. You have to inspect the context to see which one it is, or rely on intelliJ to make the former type slightly bolder. That is so bad for comprehension, and I think the only reason it was done like that was to allow for some cute hacks where control flow constructs such as map, fold etc. could be implemented using lambdas and still look like regular imperative code.

Another thing is that you can create lambdas with an implicit binder that you can refer to as "it" inside the body. It may save you one or two keystrokes, but it also encourages the programmer to be lazy about naming things. Combined with the fact that curly braces are overloaded, whenever I see "it" in code, my eyes scan frantically for the first opening curly brace, and I then have to determine whether it is a lambda with an explicit binder (then it isn't my binder, and I have to continue searching), a statement block (then it also isn't my binder), or a lambda with an implicit binder. Don't get me started on nested lambdas with implicit "it" binders that shadow each other.

<comment><USER10> Well, they see it more as a core language feature than a cute hack. Kotlin 1.0 was big into DSLs as a competitive advantage, though I don't think it got adopted in the way they hoped and I don't see much talk about it anymore. But the idea was you can make libraries where you can write code like this:

        val page = html {
            head { title = "Title" }
            body {
               etc
            }
        }

It looks like it's a part of the language and naturally integrates with features like code folding, but it's actually all just functions and objects anyone can create.

DSLs _have_ taken off in one area: UI construction. There's TornadoFX for JavaFX, SwiftUI on Apple and JetPack Compose for Android. I've tried both new and old approaches extensively and to be honest I'm not sure this is actually better than using a proper GUI builder, but for small fragments of UI it's pretty neat. Sort of like what JSX does in React but more principled and type safe.

<comment><USER28> I don't see why you can't create DSLs with an equally compact syntax which doesn't overload the curly braces. Yes, it would look different, but it would be more readable. Curly brace lambdas give a first impression of readability, but they really are not when you consider how they affect the binding structure.

</comment></comment></comment><comment><USER29> Not to defend Java, but some examples seem just unfair:

        if (nullableVariable != null) {
            boolean success = nullableVariable.someMethodCall()
            if (success) {
                return success
            } else {
                return fallbackIfNullMethodCall()
            }
        } else {
            return fallbackIfNullMethodCall()
        }

        // Wouldn't that work just as well ?
        if (nullableVariable != null) {
          return nullableVariable.someMethodCall() || fallbackIfNullMethodCall();
        }
        return fallbackIfNullMethodCall();

Ok, that is still more cluter than the kotlin elvis operator, but more fair, isn't it?

<comment><USER30> Would this work?

      return Optional.ofNullable(nullableVariable).map(v -> v.someMethodCall()).orElse(false) ? true : fallbackIfNullMethodCall();

<comment><USER31> Why not replace the tenary operator at the end with the method call in the or else block?

return Optional.ofNullable(nullableVariable) .map(v::someMethodCall) .orElse(fallbackIfNullMethodCall);

That also looks much easier to understand, at least to me.

</comment></comment></comment><comment><USER32> the biggest wins w Kotlin, imo, are the sensible defaults - variables are non- nullable & collections are immutable by default. These eliminate entire classes of runtime exceptions and bugs (respectively).

</comment><comment><USER33> I don't know if I like the "Elvis Operator" \- I feel its one too many conditions on a single line.

And the ternary operator is just odd when there is a more terse "standard" approach to it.

<comment><USER34> It feels like a common sentiment that concise code == good code

<comment><AUTHOR> To be more precise, I would say that expressive code == good code

<comment><USER35> As long as expressive doesn't mean too terse and somewhat readable to most...lest you commit perl's sins.

<comment><USER34> Yeah. This was the point I was halfheartedly making -- concise code for the sake of concise code is a dogma that needs to go away.

</comment></comment></comment></comment></comment><comment><USER36> There are very few of these examples that don't just make me feel exhausted compared to the Clojure version, but I realise it's a different set of priorities entirely.

</comment><comment><USER37> I love the idea and look/feel of Kotlin. I work to learn and use it on my own.

In the workplace, however, the problem for me are the fearful developers who think it is too difficult to maintain a multi-project code base that contains more than one language. I want to continually grow and improve and branch out, sadly I find many I work with who would rather just skate by on what they know (in this case, Java, which I helped to mentor).

I haven't yet found a way to convince them. I feel the only way I'll be able to use Kotlin within the workplace is by changing jobs.

Java is still a great language, and the new release model is helpful to get some of the more modern language features found in other languages sooner in the Java ecosystem. And while JEP is a fine governance model for feature development, I still find myself wanting more, sooner, than what it produces.

I welcome any thoughts or suggestions on how to convince others of the usefulness of introducing Kotlin into the workflow. The idea I attempted was that I would begin a new project with Kotlin that, to start, only I maintained — to make it easier for others to begin to absorb the language, at their own pace. It was futile and they simply don't want to try.

<comment><USER38> I don't know why but your assumption that others are skating by with what they know rubbed me the wrong way (maybe because I have been on other side of this). There are likely many other valid reasons here - project deadlines (sometimes it is not the right time to pick a new language), consistency of code (having a mix of languages is going to raise hell in code reviews with opinions on some code that could be done better in one language vs other), hiring (does your hiring/onboarding get more complex?), writing idiomatic code (learning a new programming language is easy but writing good code is hard), extreme swing in brevity (people abusing new languages to write concise code using obscure language features, which makes it hard for someone new to jump in).

I am sorry I don't have any suggestions to fix your problem but I just wanted to provide a bit of perspective. Maybe try thinking from your peers perspective to see what benefits adopting this new language would give and be prepared to answer why Kotlin among a whole class of JVM languages - Scala, Kotlin, Groovy, Clojure.

<comment><USER37> It's a very small company and I'm the lead developer. I know exactly what is being worked on and what timelines are involved. The replies I got when I suggested all of this was something akin to "Why now and not before? Why this project and not the others?" Even though the majority of what we work on was originally developed prior to Kotlin going 1.0 and I had already laid out my reasoning. It felt like excuses due to simply not wanting to learn and maintain something new simply because they didn't see any benefit, even though I also explained the benefits in my original suggestion.

Thanks for your thoughts, though, I'll take them into account.

</comment></comment></comment><comment><USER39> OK, but where are the advantages? The page has just a different syntactic sugar resembling Pascal/Scala; sine JVM nihil Kotlin anyway. Sometimes Kotlin's "advantages" there have more boilerplate than Java...

<comment><USER40> That's actually what I like about Kotlin the most -- it's just syntactic sugar over Java, I wouldn't call it a new language.

E.g. if you want to parse a CSV or JSON, you would google "how to parse it in Java", not "... in Kotlin". That's different, from e.g. Scala, where everything should be Scala-way (of course you could use Java libs in Scala, but it was always second-class I feel).

<comment><USER41> Once you learn the Scala way of e.g. parsing JSON or defining any custom parser or working with collections/optionals you don't want to look back. I had to move back to coding in pure Java for a while after coding Scala many years, and really it feels Java is making things far too overcomplicated in many places.

<comment><USER39> Scala is overcomplicated. Java's goal was to get rid of C++ complexity, Scala sneaked it back in.

<comment><USER41> It is only because you are _familiar_ with Java. Scala is much different language so it looks unfamiliar to you. But familiarity is not objective simplicity. Java has many more gotchas and irregularities than Scala, and you just got used to it, so you don't see it. Primitive types vs boxed types, static state, default methods (poor man's traits), unsound array types, etc to name a few.

Also it is funny to see how Kotlin or Swift are marketed as simple languages when they managed to literally copy 90%+ of Scala features and make some actually even more complex (eg nullability).

If you say "overcomplicated" it suggests you have a simpler solution for the same problem in mind. So, what exactly would you simplify in Scala? Which unnecessary features would you remove? It is easy to throw an "X is overcomplicated" statement but much harder to point to concrete things that could be done differently. Sure, some stuff could be easily removed, but not without making the language less expressive.

<comment><USER39> Look, Java was born when C++/CORBA dominated investment banking and everybody was having headaches with those. Java was like "manna from heaven" that made everything orders of magnitude simpler. It still didn't get everything right, like too much boilerplate, but simplicity of approach was there. Then Scala arrived, and obfuscated everything. It didn't retain simplicity of either Java or Haskell, instead went full-blown C++ "many styles" way. As a consequence, either all of your team is on the same level in the same areas in Scala, or you are going to have "fun" in production. In Java the syntax was quite trivial, in Scala one has to fight with DSLs of different frameworks and unintended consequences of various higher-order structures originally designed to be "simple".

</comment></comment></comment></comment></comment></comment><comment><USER42> I learned that Kotlin has a native compiler:

[https://github.com/JetBrains/kotlin- native](https://github.com/JetBrains/kotlin-native)

does this mean end user can run without JRE? Does Java proper have something similar?

<comment><USER43> Java had a native gcc front end way back in the 90's. No one used it and they eventually dropped it. This isn't really a killer feature for the problem areas targetted by Java developers.

Android ART is, effectively, a native compiler for a Java-targetted (but not JVM) bytecode too.

<comment><USER20> I think one of the main use cases of graal native will be for container's with smaller memory footprint (where GO traditionally shines) or where startup time needs to be fast.

</comment></comment></comment><comment><USER44> It pisses me off a bit to not see Scala mentioned anywhere. Scala has everything Kotlin has, and a lot more.

<comment><USER45> Which could be considered a reason to use Kotlin instead. Scala is a more powerful footgun. You pay for the power in overengineered code, slow compile times, and worse compatibility with other JVM languages.

<comment><USER41> Scala compatibility with JVM is the same as Kotlin's. It is implemented the same way in both languages - they compile to JVM bytecode and as long as you keep away from non-Java features, interoperability is good both ways. If you start using stuff not directly supported by Java like default arguments or multiple inheritance of traits, then calling Scala/Kotlin code from Java is similarly bad experience. Scala has also a few more non-Java features e.g. macros or implicits, so I get how you could end up with this impression. Just don't use these features of you need to call your code from Java.

As for compile times, Scala with Bloop is the fastest of JVM languages I ever saw. We switched to compile Java with Bloop because it is orders of magnitude faster than Maven/Gradle. Bloop works for Java and Scala, but not Kotlin. So Kotlin, having really nothing comparable at the moment, is currently the slowest to compile from these three languages.

<comment><USER46> Something doesn't add up. First you say (emphasis mine):

> Scala compatibility with JVM is the SAME as Kotlin's.

Then you follow up with:

> Scala has also a few more non-Java features

These are contradictory claims. OP had a very good point about Scala being a more powerful footgun. Unfortunately, consciously avoiding features is not a matter of "just", and rarely works out in practicality.

<comment><USER41> No they aren't contradictory. What is the compatibility of a feature that even doesn't exist in Kotlin? How can be the lack of way to call a Scala macro from Java a disadvantage, when Kotlin doesn't allow you to call a macro from neither Java nor Kotlin, because this feature doesn't exist? Scala is strictly superior in this case.

And you need to avoid some features only in code that gets called _from_ Java, not the whole codebase. Calling it this direction is very rare and not really a problem. Most codebases call Java from Scala and this is easy and fully supported.

<comment><USER47> 100 intercompatiblity is a feature.

<comment><USER41> But Kotlin doesn't have 100% interoperability! There are features in Kotlin which don't map nicely to Java features. For example you can't call methods with default arguments from Java without resorting to unreadable hacks relying on a way defaults are implemented (same is true for Scala).

</comment></comment></comment></comment></comment></comment></comment><comment><USER48> I tried Kotlin for some time and went back to Java.

Kotlin is nice, and on some days preferrable, but the fact of the matter is, it's really not that much more legible or succinct than Java in the long run.

Look at Androind BTE docs [1] - the K vs. J examples side by side, there really isn't that much difference.

In the end, I feel K is just a 'different flavour' of Java, and often I feel that the makers of K are just throwing a bunch of ideas together, without necessarily having a philosophy.

Given a choice between a 'world of J or K' \- to me, it's kind of a toss up - but in reality - J is the incumbent. You have to know J and deal with J at every step, all sorts of libraries are in J etc. etc. - so in reality, the offer of Kotlin is really not Kotlin, it's always Kotlin+Java - meaning two languages and paradigms to support.

If this were 1996 and we had to pick between DVD and BlueRay, it would be a difference decision, but in the end, it's not really 'either or', it's J or J+K.

In the end, J is not that much more hard to write and the differences are negligible except for some specific things ... so I've switch back to J and don't miss K.

[1] [https://developer.android.com/guide/topics/connectivity/blue...](https://developer.android.com/guide/topics/connectivity/bluetooth#kotlin)

</comment><comment><USER49> I wonder whether Project Loom will create a split in the Kotlin ecosystem between coroutine-based concurrency and Loom lightweight thread-based concurrency.

Java will have a similar problem with CompletableFuture and third-party projects like Reactor used in Spring WebFlux.

However, Kotlin baking in language syntax for a competing concurrency model will exacerbate the split.

With Java already having type inference, concise lambdas, and with upcoming records that can already be faked in current versions via Lombok, the value proposition of Kotlin seems questionable outside of Android with its held-back version of Java.

Clojure is another story entirely, offering a very different and compelling way of thinking about computing on the JVM. By contrast, my developing view is that Kotlin is different enough to require learning something new yet not different enough from modern vanilla java to offer substantial advantages.

</comment><comment><USER50> I think one feature of Kotlin that is underestimated is extension functions. Combine them with autocompletion and you've got a great developer experience. Finding the method you need no longer requires a Google, and optimisation pays off massively in terms of productivity by tightening the development loop.

<comment><USER51> Extension functions are dispatched statically which can be surprising if you can't tell what is an extension and what isn't

</comment></comment><comment><USER52> I like Kotlin (as a half-way house in a Java codebase to something purer like Scala) but I'm worried about being locked in in future, and that becoming a liability in a codebase 20 years from now.

Does anyone have experience of emergency automatic conversion back to Java?

(Edit: Never used Kotlin but I like the look of it)

<comment><USER10> There's no direct conversion back. IntelliJ has a decompiler that produces reasonable-ish Java code based on the debug symbols, so you get things like local variable names and obviously method/class names back, but, it's a decompiler, so no code comments. And Kotlin constructs frequently require synthetic Java variables to be created that were implicit in the Kotlin, so you have to clean up the result quite a bit.

However note that Kotlin and Java code can co-exist very closely in the same codebase. In the same way you can incrementally port a Java codebase to Kotlin, so too can you incrementally port Kotlin to Java. There's just no automatic tool for it like there is Java->Kotlin.

<comment><USER52> Thanks for that. I think I'd misread something then and thought that it could work both ways.

</comment></comment></comment><comment><USER53> All of this stuff will eventually wind up in Java, and when it does, Kotlin is going to feel an awful lot like Coffeescript. The Kotlin proponents of today are going to feel a bit silly.

I predict there's going to be a lot of effort wasted porting old Kotlin code to Java 20 or some such.

Willing to place a longbet on it.

<comment><USER54> But all of this stuff simply can't end up in Java, because of backwards compatibility. For example, kotlin object references are non null by default. That is not something Java can easily bolt on. I think there should be many such features.

</comment></comment><comment><USER55> Raw, multi-line strings are coming in JDK 13 thanks to [https://openjdk.java.net/jeps/326](https://openjdk.java.net/jeps/326)

<comment><USER56> Java 13 was released 2 months ago.

<comment><USER55> I am _so_ outdated. (Our company uses an internal licensed version of the JDK and we don't have JDK 13 yet)

</comment></comment></comment><comment><USER57> So choosing Kotlin over Java boils down to some syntactical differences? Nah. The syntax differences between Kotlin and Java are not even that huge. It's not like choosing between Elixir and Erlang, or between JavaScript and ReasonML.

The main differences between Kotlin and Java are:

* Kotlin forces null checks.

* Kotlin arrays are invariant.

* Kotlin does not have checked exceptions.

* Kotlin has first class functions.

* Kotlin sealed classes don't really have an analog in Java, AFAIK.

I don't find data classes to be a big deal. The best thing about them is you get `copy()` for free.

</comment><comment><USER58> Why don't the Java examples use var?

<comment><AUTHOR> They will. I am in the process of updating Java code snippets to Java 11.

<comment><USER20> Probably should do 13 since it's the current release.

<comment><AUTHOR> Sure, but you have take into account that Android devs are limited to Java 6, most enterprise devs (based on my experience) are still on Java 8 and some are still on Java 5 or below.

<comment><USER20> Yeah this is nonsense and isn't an argument against the language. Embedded devs aren't allowed to use Rust, does that mean we shouldn't compare C++ 20 to Rust? Does that mean Rust is a bad language? If these said devs are limited to Java 6/7/8 does their company have the inertia to use a brand new programming language (Kotlin) that their devs don't know? Does this mean Kotlin is bad because they're not using it?

This is a bad argument.

<comment><AUTHOR> My goal is to compare Kotlin with the current version of Java along with any Java libs that are commonly used (such as Lombok). I have mentioned the fact that some teams are still on older versions of Java just to highlight that not every developer can access the features of the latest Java release.

<comment><USER20> Unless it's Android, if they can't access the latest features of Java they more than likely can't access the latest features of Kotlin either.

<comment><AUTHOR> That's not always the case, since Kotlin can generate Java 6 compatible bytecode.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER59> These examples don't show the true power of Kotlin, for example pattern matching is super powerful and helps to put a much more solid and readable logic in your applications.

Still a lot of Kotlin I see from my Android colleagues suffers from all the CONSTANT_STRING_TYPED magic and onion architected* stuff either inherited from the libraries and API's or ingrained into their programming habits.

* many layers, and every time you peel off another layer you feel more like crying

</comment><comment><USER60> A lot of this could be misleading, a programming language can have excellent syntax to do something small and yet might turn out to be a horrifying if you are going through a complex system.

Having worked with Kotlin I do love the language though. There are some features like extensions which I hate. But in general I love the syntax though I do not find any significant advantage of using it over java.

</comment><comment><USER61> Very nice catalog of comparisons. IMO it could also use a section on "Generics," Kotlin's declaration-site variance is a nice improvement over Java wildcards.

[https://kotlinlang.org/docs/reference/generics.html](https://kotlinlang.org/docs/reference/generics.html)

</comment><comment><USER62> To those who've done a lot of Kotlin, does it actually alter your programs' design and structure? Your approach to problem solving? Does it open new doors in how you choose to think about and attack a problem? In a nutshell, do you think your programs are better because you chose Kotlin over Java and why?

<comment><USER63> I've converted a lot of Java backend code to Kotlin. You usually start out with the intellij converter. I tend to go class by class. That leaves you with something that nearly compiles but not quite. After addressing that, you typically end up with some needlessly nullable types, lots of mutable types, some misguided generics and a few other java-isms that are easily fixed. So, far you've not really changed the structure of the code, you're merely improving it and making it more safe to use. I usually get the process above over in a few minutes for a single class; it's not hard and I would argue the resulting code is already massively better than what you started with.

After that, there are probably a few places where idiomatic use of Kotlin library and extension functions can improve things. I tend to that as I stumble on opportunities to do so. This stuff is great for getting rid of boiler plate. E.g. Kotlin's internal DSL language features can replace a lot of ugly builder pattern code. Also having constructors with default arguments removes the need for having builders or having multiple constructors. Same for functions.

Converting streams to sequences and restructuring statements with nested returns to return the result of a complex expression helps to. Using when instead of if makes things nicer. Etc. Lots of stuff to use.

My programs are definitely shorter in Kotlin and safer (e.g. nullability). Shorter is correlated with lower maintenance cost in literature on software engineering. Some things that Java is ok with are compile errors in Kotlin. So, safer is better in my book as well.

</comment></comment><comment><USER64> I like a succinct way to define immutable variables. That's what I do by default in Swift

       let str = "foo"
       let age = 10

Kotlin does this with val, which is great.

How do Scala and Kotlin compare?

Next time I'm back on the JVM, I'd like to one of these two, perhaps both if they interoperate.

</comment><comment><USER65> Out of topic, talking about language defaults, I wish C++ defaulted to const reference instead of value. True that it would lead to some pitfalls such as having to explicitly copy values during initialization, but it would make things much less verbose.

</comment><comment><USER66> Kotlin is like a virus. Once you use it in a non trivial project, it infects you and takes over your body and mind. Every time I look at Java code in my Android apps, a part of my body hurts. Luckily there exists a Java to Kotlin converter.

<comment><USER67> It reminds me of moving from VB.Net to C# years ago!

</comment></comment><comment><USER68> Kotline looses me at _val_ vs. _var_

So much focus on readability otherwise, what happened there?

<comment><USER69> value vs variable. As someone that works on both Kotlin and Java daily, what is issue? 95% of the time I'm using val.

<comment><USER70> They also look completely different in the IDE

<comment><USER59> They should because it's very easy to miss when skimming over the code otherwise.

</comment></comment></comment></comment><comment><USER71> See also: [https://rosetta.alhur.es/compare/Kotlin/Java/#](https://rosetta.alhur.es/compare/Kotlin/Java/#)

</comment><comment><USER72> Kotlin is people impatient with the glacial evolution of Oracle Java.

</comment><comment><USER73> Kotlin really shines when it comes to async programming. This is some code I wrote using Vert.x with Kotlin extensions :

        router.get("/api/article/:id").coroutineHandler { ctx ->
            val news = newsRepository.get(ctx.pathParam("id")) // no need for await
                 ?: return ctx.respondText(404, "Not Found") // can still use basic code constructs
            ctx.respondJson(200, jsonObjectOf("news" to news)) // actually an extension method i wrote
        }

</comment><comment><USER74> Though I do find Java's String concatenation cleaner than Kotlin's (refer: Strings II comparison/example, the 2nd last)

</comment><comment><USER75> The Null II example and the Elvis operator look like special cases of monadic bind/functorial map.

</comment><comment><USER76> This seems great.

For someone who already knows Kotlin.

</comment><comment><USER44> For fun, I'm going to rewrite all of the examples in Scala:

1) Main

def main() = println("Hello")

2) Variables:

val y = 1

3) Options (nulls are discouraged):

val name: Option[String] = None

4) Null 2:

//If bob is not null, get his age, or get a default age

val age = bob.map(_.age).getOrElse(0)

5) Elvis operator

Kotlin:

val result = nullableVariable?.someMethodCall() ?: fallbackIfNullMethodCall()

Scala:

val result = option.map(_.someCall()).getOrElse(defaultValue)

6) String interpolation in scala seems to be exactly the same as kotlin:

val name = "John"

val lastName = "Smith"

val text = "My name is: $name $lastName"

val otherText = "My name is: ${name.substring(2)}"

In addition, you can also have:

val longString = s"""

|This is line 1

|This is line 2, my name is $name

""".stripMargin

7) This shows the same multi-line strings as above, but its unclear if you can have variables in multi-line strings like I showed above in Scala

8) Ternary operator:

val text = if (x > 5) "x > 5" else "x <= 5"

Some bonus stuff which scala has:

9) Case classes:

case class Person(name: String, age: Int)

10) Pattern matching

person match {

      case Person("bob", 13) =>

          println("Matched bob with age 13")

      case Person("sally", _) =>

         println("Matched sally, age unknown")

      case Person(name,age) =>

        println(s"Matched unknown person with name $name and age $age")

       case x:_>

          println(s"Matched unknown item: $x")

}

10) Equality which actually makes sense, i.e

val foo = "foo"

val bar = "foo"

foo == bar //true in scala, no need to foo.equals(bar)

val bob = Person("bob", 13)

val other = Person("bob", 13)

bob == other //true, based on values

val list = Seq(bob)

list.contains(other) //true, based on values

11) .par collections / way better higher order functions

val list = Seq(string1, string2,...)

//Do a parallelized search on list to find all strings <= 3 chars in length:

val shortStrings = list.par.filter(_.length <= 3).seq

12) Try:

val riskyOp = Try( doSomethingRisky() )

riskyOp match {

       case Success(result) =>

            println(s"Op succeeded with result $result")

       case Failure(e) =>

            e.printStackTrace

}

Disclaimer: I wrote all these in the HN textbox, please excuse any typos

<comment><USER9> Could you please also provide Scala versions for the other code snippets on that site? Just what you can come up with from the top of your head?

I'm genuinely interested, having spent the last few years with Haskell and having recently rediscovered and being incredibly awed by the JVM and its ecosystem, and pondering on whether I should refresh what I'd known of Java or just outright embrace Scala.

<comment><USER44> You should definitely go for Scala if you're coming from Erlang. You'll find it much more Erlang-like.

I don't have the time to convert their whole site right now, sorry, but you'll find the same pattern holds - Scala does everything more elegantly and concisely. Feel free to look up a Scala tutorial.

<comment><USER9> Great, thanks! Do you think Martin's textbook on Scala is recent enough relative to the present state of Scala as a language? I also see Scala 3.0 is in talks, nice.

<comment><USER44> I found that to be a bit dry personally, I personally just looked up Scala tutorials online and followed them

</comment></comment></comment></comment></comment><comment><USER77> what i want to see is kotlin vs scala

</comment><comment><USER78> I love programming languages that are case sensitive. So easy for each programmer to have their own programming style on naming variables and then errors galore, which in the end will result in hiring an outside senior to clean-up the mess - that's me of course, and all for heavy money.

Somebody please invent another case sensitive programming language, we don't have enough of them already.

<comment><USER79> Aren't they all case sensitive since FORTRAN and BASIC?

<comment><USER80> Pascal, R, Lisp, Ada, SQL are case-insensitive.

<comment><USER81> And COBOL, don't forget COBOL! ;-)</comment></comment></comment></comment>


Netflix and FreeBSD: Using Open Source to Deliver Streaming Video [pdf] - <AUTHOR> https://fosdem.org/2019/schedule/event/netflix_freebsd/attachments/slides/3103/export/events/attachments/netflix_freebsd/slides/3103/FOSDEM_2019_Netflix_and_FreeBSD.pdf <comment><AUTHOR> _> Using FreeBSD and commodity parts, we achieve 90 Gb/s serving TLS-encrypted connections with ~55% CPU on a 16-core 2.6-GHz CPU._

(highlight from slide #7)</comment>


Ask HN: How do you become social media influencer? - <AUTHOR> <comment><USER2> You approach any system with thoughts of how to cheat/game it in your favor.

If you look at any large social media platform's most prominent users you will find common patterns. On Reddit you'll find a sort of roving cabal of interconnected people who control the largest subs. On Instagram you'll find paid follower counts and paid engagements from third world social media sweatshops to be the norm. On twitter you'll find gangs of journos amplifying each other similar to the Reddit moderator scenario.</comment>


Fedora Project Officially Turns 9 Today - <AUTHOR> http://www.thepowerbase.com/2012/09/fedora-project-officially-turns-9-today/

<comment><USER2> I know its not the most popular distro, but I still think fedora is a bright spot in Linux desktop innovation. A lot of the great changes that have been incorporated into other distributions have originated in Fedora. Keep up the good work.</comment>


Interview Street (YC S11) streamlines the search for great programmers - <AUTHOR> http://techcrunch.com/2011/08/06/yc-funded-interview-street-streamlines-the-search-for-great-programmers/ <comment><USER2> A computer program automatically torturing applicants with endless puzzle tests is not a way to find talented qualified people with experience delivering working results that delight the user. It's a good way to find people that have a lot of free time to play games because they are unemployed.

In the years following my first job out of school (decades ago) I can't recall any work that I have gotten by going to these sites, or dealing with monkey tests. Work comes because of my reputation and experience which speaks for itself. At conferences people give me their card and tell me to call them if I am looking to 'move up', which generally means "pay more than the last guy". Any time one contract or job ends, I look through these cards. Most of the time I get several phone calls from people I have met of the sort: "Hey Bugsy, I heard rumors of ABC Corp having layoffs. You looking to get out? We have a position..."

It's bad enough when the interviewer wastes more than 10 minutes of time with puzzles. Having it be automated so it can waste hours and hours without any human feedback is extremely offensive. Whoever designed this system knows nothing about acquiring talent.

The note in the article that in the future the site is going to be augmented with "real world tests" that force the user to design entire sites or otherwise labor for free borders on criminal since they are forcing you to do real work and you're not getting paid for it, in violation of state and federal labor laws.

If you haven't already seen examples of someone's work before you contact them, maybe you shouldn't be hiring them. Or maybe you need recruiters who know what they are doing.

Again, I have no doubt that desperate people who are unemployed because of their incompetence or lack of skill will not have any problem devoting the hours needed to google answers, or to hire third parties to help them complete these tests. I am sure complementary businesses will now open up that sell test answers to desperate applicants for a fee.

<comment><USER3> Not every developer has a brand. This service appears to target companies hiring developers that don't. Fortunately that is 99.99% of the market.

<comment><USER2> You may have misunderstood my comment. It's not about having a brand. It's about having a professional reputation. Professionals who are of the "excellent" caliber that this service purports to represent usually develop a professional reputation naturally without even trying.

This happens even if one is fairly isolated doing "heads down coding" for much of the year. There are times when you meet with clients in meetings, or talk to customers, and talk to competitors at industry conferences, standards meetings and the like.

People who are competent recognize other people who are also competent just by talking to them. People either know what you are talking about and can respond intelligently, or they don't. When people don't know what you are talking about, you downgrade the conversation and talk about gardening, the weather, sports. This is just normal everyday human interaction. It's strange reading some of the replies here, it sounds like some of the people on this discussion board don't know about how that is done. They seem to not have face to face interactions with other people in their field.

In the cases where you connect with someone who is likewise competent, you both remember the encounter. You trade business cards. And if you have an opening at your job for the sort of work the person does, when the position is mentioned, you pull out his card and say "What about this guy? I met him at the XYZ conference. He invented the ABC protocol that is used in GHI devices, just like the thing we are looking to get into."

Connections made don't have to be with management. Typically it is another engineer, a peer relationship. If you know what you are doing, then you get recommended when there is an opening. That is how most jobs at good companies get filled. It's not "nepotism" as someone below claims (apparently he is lacking a dictionary.) I have never worked for a relative. If I do in the future, they will have tried to hired me not because I am related, but because I am the best. And should that happen I would turn them down since I wouldn't want to mix up family relationships with work, that can be a disaster. In any case, if you are good, even the most reclusive and introverted developer/designer/inventor is going to have some people he talks to. And if he is good some of those people are going to talk to others about his work. If that is not happening for someone, the likely reason is they are not all that great. There is no shame in being incompetent nowadays, but the article under discussion is about hiring "excellent" people, not incompetent ones, so it is relevant for the specific topic at hand.

<comment><USER4> I strongly, _strongly_ agree with everything you're saying and second it wholeheartedly, but I want to add that there is a class of people in our field that can talk brilliantly about what they've worked on, who have resumes with key roles on shipping products on them, and who will absolutely flatline if called upon to code. There is a logic to some level of programming quiz. You really want to verify that the person you're hiring is capable of sitting down, focusing on a problem, and turning out some reasonable facsimile of good code.

That said: this site clearly doesn't look like the right way to do it.

Here's our hiring process (we're hiring!):

<http://www.matasano.com/careers/>

I think we're extraordinarily careful to be respectful of people's time. We've learned through difficult experience to put practical problems in front of candidates, but to avoid Aspie-type alpha-geekery in those problems, and to be appreciative of the time people give us to go through those problems.

Running the puzzle gauntlet doesn't sound respectful to me. There are great programmers who get off on solving puzzles and this process may not weed them out, but there are _lots_ of other great devs who will walk if they see something like this. Caveat emptor.

<comment><USER5> There's also the opposite.. there are a huge number of programmers who are great at what they do, but asked to be social, come off as awkward and incompetent. Unfortunately it is these talented individuals who often get passed over because they aren't good at "networking", as the grandparent suggests should simply come "naturally." Unfortunately he doesn't seem to understand that something that comes naturally for some--talking to other people--is difficult and hellish for others. And it doesn't mean they wouldn't be a good choice for the job. The world is heavily biased towards people who know how to "network," and maybe this company is trying to expose individuals who don't, but happen to be really good problem solvers.

<comment><USER2> > he doesn't seem to understand that something that comes naturally for some

I think that is an excuse. Speaking as the person you are claiming doesn't understand, I am highly introverted and awkward. I hate interacting with people in public, it is exhausting. I throw up after having to do public speaking. Yet, I do talk enthusiastically about my work and the field with other people, and I have learned over the years, as introverts do, to be sociable, just as I have learned over the years how to write compilers, design microchips, do web design, etc. (Little of which was covered in depth at all in the university classes I took at a pretty good engineering school.)

</comment></comment></comment></comment></comment></comment><comment><USER6> I get frustrated because I am pretty horrible (in my mind) at these kind of math puzzles ("Given N numbers , [N<=10^5] we need to count the total pairs of numbers that have a difference of K. [K>0 and K<1e9]..."). My frustration is compounded when I know that I won't really need to write this kind of Project Euler-style programs in 90% of jobs.

Your company is a web app, I can write web apps; why am I solving problem sets from undergrad Discrete Math to demonstrate competence? Why not have the tasks be like "Use AJAX to pull down a users last 10 tweets and display them on a web page"?

Maybe it's because the only samples are generic and not submitted by the companies, but I was hoping for a bit more relevance to the intended job duties than yet-another-interview-puzzle.

<comment><USER7> Hi Swanson, totally agree to your comment. We're going live in a week's time where hackers can solve real-world problems. Mind dropping an e-mail to firstname.lastname@example.com ? Would get back to you once it's live.

<comment><USER6> Thanks, I didn't actually read the TC post all the way though (I just went to your site directly) so I missed the part where you addressed this in the article. Glad to see you understand my perspective.

<comment><USER7> Yes, thanks swanson

</comment></comment></comment></comment><comment><USER8> Maybe it's just me, but when I look for great programmers, their ability to solve coding challenges is really the least of my problems.

In my experience, the ability to leverage those skills into delivering mature, stable, maintainable and generally high quality software is considerably rarer than the skill to solve puzzles. And don't even get me started on non- technical skills, like being able to organize and plan the work, communicate with non-technical people etcetera.

Basically, I don't see this kind of testing covering more than 5% of the screening effort.

<comment><USER9> You're not the only one. The more experience I get developing software with other people, the more I value stuff that isn't really captured by coding interviews:

      * do you thoroughly document your code without nagging?
      * do you value simplicity over cleverness?
      * do you think communication is a chore?
      * do you enjoy human interaction?
      * do you have empathy?
      * are you creative?
      * do you have good taste?

Googrosoft-style interviews are great for selecting people with raw intelligence, a competitive streak and some level of arrogance. They're not quite as hot at selecting reasonably smart people who are personable, creative and tasteful. And that's a _huge_ portion of the job when you're writing software in a group. Very little day-to-day software work requires raw brilliance, but _nearly all of it_ requires communication, empathy, creativity and taste.

<comment><USER10> And how do you test for all of these things that you listed during an interview? I've been in charge of technical interviews for a large corporation for a year and a half, and there have been many truly shitty developers who couldn't solve even simple programming problems, but they knew how to bullshit, and they would totally ace your questions.

<comment><USER9> _"I've been in charge of technical interviews for a large corporation for a year and a half, and there have been many truly shitty developers who couldn't solve even simple programming problems, but they knew how to bullshit, and they would totally ace your questions."_

Well, first, it's not like I _just ask someone_ if they enjoy documenting code, and expect them not to lie. That would be stupid. It's much easier to just ask coding questions than to figure out if someone is creative. That's why the problem is hard.

Second, how do you focus on the other important factors, and still manage to test for coding ability? You ask coding questions -- you just don't devote the entire interview process to them.

</comment></comment></comment></comment><comment><USER11> The guy in the live chat said they look negatively on large numbers of submits. I think this is a poor idea for two reasons.

1) This will simply encourage people to develop offsite and submit when they have working code. On their site they allow recruiters to see what applicants are typing in real time, and pushing people off site will render this function useless.

2) In interpreted languages like python my work flow usually is incremental change and test, so very high numbers of submissions will not be unlikely. I don't think that kind of programming should be discouraged.

There should be a Test button as well as a Submit button. The employee understood my concerns, so hopefully they get that worked out soon.

Another criticism: The problem desctriptions seemed poorly worded to me.

It is a good looking site either way. I'll be keeping my eye on it.

<comment><USER12> That's really interesting. If there is criteria beyond the solution you produce, they should really list that clearly on the site. If I don't know that and I'm applying, I might be only half-focusing while doing other things and take a long time and maybe not come up with the perfect solution right away.

I think this kind of extra testing could be detrimental because it's going to stress people out. Give a hacker a fun challenge and set him to work, he'll probably do it better and faster than if you set him in an empty room with a big timer and people scowling at him.

</comment></comment><comment><USER13> "Programmers should not be puzzle-minded… We would be much better served by clean, systematic minds, with a sense of elegance." - Edsger W. Dijkstra

([http://portal.acm.org/ft_gateway.cfm?id=1787249&type=htm](http://portal.acm.org/ft_gateway.cfm?id=1787249&type=htm))

</comment><comment><USER14> I'm not sure that this effectively replaces any part of the traditional process (resume--phone interview(s)--onsite interview(s)). I guess it comes closest to replacing the phone screen, but my understanding is that the goal of the phone screen is to establish "can this person actually write code" which I don't really think this does given how easy it would likely be to cheat--either by finding a solution online or by getting someone else to do it for you.

<comment><USER15> This helps for campus placements where you can't Realky get others to code for you.

</comment></comment><comment><USER16> I have so much open source to demonstrate my ability, I promise you I'll never use this site or complete any code exercise for an interview. If you don't want to look at my github profile, fine, I don't want to work at your company

I also happen to hire and if the candidate does not have an open source project I give them a meaningful challenge (add value to the community) and tell them to create a github acct and share a link to the repo. At least by the end of the process they have something to walk away with

<comment><USER17> You are insulted by the idea of programming puzzles in an interview situation. That's fair enough by me. But then you go on to say this:

> I also happen to hire and if the candidate does not have an open source > project I give them a meaningful challenge (add value to the community) and > tell them to create a github acct and share a link to the repo. At least by > the end of the process they have something to walk away with

Could you be any more silly and condescending? Right back at you: Unless your nickname is a literal and accurate description of your programming abilities, I will take a bet of dollars to donuts that every programmer in my office has more raw coding acumen than you. But guess what? None of them has a GitHub account and that is unlikely to change. Neither do most of the other top-tier programmers I know. One of my coworkers has put out numerous public domain libraries (<http://nothings.org>), most of them developed on RAD's dime, but he'd probably be appalled to be considered a member of your "community".

I actually have an old, effectively defunct GitHub account that I continue paying $8/month for because I like what those guys are doing. The problem isn't GitHub. GitHub is great. The problem is you, and people like you.

Don't be a GitHub Douche.

<comment><USER16> First off, I don't understand where your rage is coming from. My point is that if you contribute to open source then your coding ability is clearly demonstrated in those projects. I'd rather spend my mental powers on coding something that others could use afterwards then a stupid code challenge that will just be rm -rf after the interviewer reviews it.

 _None of them has a GitHub account and that is unlikely to change_

I'm surprised your so proud that your team will never have a free account on the largest repository of open source. Regardless if you contribute, why wouldn't you take advantage of FOSS instead of re-creating the wheel.

 _I will take a bet of dollars to donuts that every programmer in my office has more raw coding acumen than you_

Thats a rather baseless statement. What would you know about my ability to code or not to code. On the other hand, your team's apparent anti-open-source position (based on above comment) seems to indicate they are not as awesome as you describe.

 _The problem is you, and people like you_

You mean people that are passionate enough about programming to voluntarily write code on evenings and weekend and share it for the broader _community_ of developers for the sole purpose of being proud of something you create and sharing it so others can benefit? I'd be happy if there were more problems like me

 _dont be a github douce_

Honestly I don't care if you use github, bitbucket, codeplex, or your blog

<comment><USER17> You think I'm enraged? I'm sitting here chuckling and shaking my head in bemusement at you.

> I'm surprised your so proud that your team will never have a free account on > the largest repository of open source.

I'm not proud of it. When I say it's unlikely to change, I'm making a considered prediction. Don't confuse 'is' and ought'.

> Thats a rather baseless statement. What would you know about my ability to > code or not to code.

It's not baseless. It's Bayesian statistics. They are enough sigmas above the mean that I feel comfortable making that bet. If you were to reveal your identity and it turned out you were, say, Guido van Rossom, I might lose the bet and have to update my prior.

> You mean people that are passionate enough about programming to voluntarily > write code on evenings and weekend and share it for the broader community of > developers

Nah, I mean people who assume anyone who isn't exactly like them must be a second-rate human being or at least a second-rate member of their profession. This is the same personality flaw that turns enthusiastic, inveterate puzzle solvers into the kind of puzzle-mad interviewers you seem to hate with a vengeance. Isn't it nice to find out you have something in common?

</comment></comment></comment></comment><comment><USER18> This is a perfect example of cargo cult thinking. Just because you're a tech start-up doesn't automatically put you on the same level with Google and Microsoft. Both of those companies have products which require a team of developers with understanding of computational complexities of algorithms, data structures and etc (think of Windows, Visual Studio IDE, Google Chrome/OS, Bing/Google search engines). I'm yet to find out how this applies to your featured list of companies such as Disqus, DropBox or Weebly and i am more than 100% sure that it doesn't.

<comment><USER19> Working at Dropbox would almost certainly require "advanced knowledge of computational complexities of algorithms, data structures and etc".

<comment><USER18> I hope you didn't mean scalability when you wrote that.

</comment></comment></comment><comment><USER20> In case people didn't know this, this is based all out of India. And we have Yuvi Panda (HN:yuvipanda), one of the younger hackers around here, joining them. Can't wait to see how they do.

<comment><USER7> We just moved to valley :)

<comment><USER20> Nice. We should meet up :)

Also, another tidbit for folks here - Yuvi is following the startup lifestyle by taking a break from college and joining this startup. Which is a big, big deal in India. I'm very impressed

<comment><USER21> It's a big decision for anyone to make, in my opinion.

</comment></comment></comment></comment><comment><USER22> I submitted the same Java code 3 times. Compiled ok only on the third time since I poked around a bit and found I have to call my class "Solution" in order to pass compilation! The guy in the live chat said he'll change my # of submissions to 1 instead of 3, since the challenge didn't say that the class be called "Solution". Hasn't done so yet. My score is 52.5 when it should really be 57.5. Hopefully they fix that. Am on to my next challenge.

<comment><USER23> Done now!

</comment></comment><comment><USER24> Interesting, but as a (potential) candidate I wouldn't be very happy if each company had its own coding challenge, since it would make getting a job much more time consuming than it already is.

</comment><comment><USER25> I looked at the demo site.

I _know_ there are domains which call for Project Euler solutions.

Really. I do.

But I only run into "CS" problems about once a month right now. The rest of it is code cranking, talking with people, and working on deadlines.

I'm not saying that this is drek in the stream. It's not. It's just... not even close to a demonstration of what I can do for the company I work for.

Yes, I could work out these solutions. But (these days) I'd rather work on writing software rather than developing one-off algorithms.

(And of _course_ this sort of thing tempts me to submit in Haskell or Lisp, because hey, more mathematical notation. And you probably don't want to read >>= or ))))), do you? ;-) )

I'd rather share my open-source code (it's on github and bitbucket!), talk about my prior projects, and present my ability to work with other human beings to get the task at hand done.

Yet- all that said - Best of luck, Interview Street. Anything that helps people connect with jobs they are suited for is a good thing in my book.

</comment><comment><USER26> The only thing a site like this can "streamline" is the weeding out of the truly incompetent people, pretending to be programmers. But I'd argue that it's not a very hard task anyway. So, while solving the challenges will be fun for the applicants, it doesn't seem like the service would be of much help to the companies.

<comment><USER27> Weeding out the truly incompetent people may not be hard but it's time consuming nonetheless. A phone screening may take anywhere from 30 to 60 minutes of the interviewer's time, regardless of the interviewee's competence. Multiply this with the number of candidate a company has to wade through for a single opening and it gets significant real soon.

They're probably not the new LinkedIn but I think they're into something.

</comment></comment><comment><USER28> Competitor Codility (funded by Seedcamp) who launched a couple of years ago was discussed quite extensively at the time:

<http://news.ycombinator.com/item?id=1039140>

<comment><USER29> I had great fun doing the codility tests. Their site is great, allowing you to do the tests in the language of your choice.

<comment><USER30> Neither of these sites allows you to do the tests in the language of your choice =/

<comment><USER31> From their demo test:

 _Your test consists of 1 programming problem to be solved in Java, C++, C#, C, Javascript, Pascal, Perl, PHP, Python, Ruby or VB.NET,_

<comment><USER30> That's correct. On both of these sites, I may use C, C++, C#, Java, Python, PHP, Ruby, or Perl. On Interviewstreet I may also use Haskell. On Codility I may also use Javascript, Pascal, or VB.NET. "The language of your choice" would probably include Algol-68, Lua, more than zero Lisps, D, and Brainfuck.

<comment><USER32> and on Coderloop you can also use Fortran, Erlang, Objective-C, Lua, Javascript, Scala, OCaml, Clojure and Common-Lisp :)

<http://www.coderloop.com/home/guidelines>

</comment></comment></comment></comment></comment></comment><comment><USER33> A feature suggestion from me: \- Allow the recruiter to decide what he's looking for in the code. e.g. Complexity / Efficiency / Clean maintainable code / OO Principles, etc.

The biggest problem I have with job interview style 'coding puzzles' - is that the code that is optimum to solving the solution is actually not code I would want to write day to day and wouldn't be code I would want to work with day to day.

The reason is because in my line of work, we are working with good clean, maintainable code, using good OO principles. This includes naming of variables, naming of functions and accounting for extendibility and maintainability from the ground up.

However, most of these coding puzzles, will be looking for people to write the 'simplest' / 'most elegant' solution to the problem, often leaning towards efficiency or using the least number of lines / characters.

For example, the variables will be 'x', 'y', 'a', 'b', everything will be manipulated through integer 'index' and complex reg exp's may often feature as short cuts to longer code.

\- Now there's nothing wrong with the solution this produces. However, overall coding style I prefer is maintainable and easily readable. Variable names have meaning, we work with concrete objects and each piece of complexity is broken into separate functions / classes.

Neither solution is wrong, but the approach to either is completely different and for a interviewee it's often hard to know which path I should be treading when writing the sample code.

On the one hand, the interviewer may think I lack any forethought of maintainability / readability, if I just hack together something quickly using single character variables.

On the other hand, the interviewer may think I'm adding too much bloat / taking too long by using full naming and creating my objects to handle what I want to achieve.

</comment><comment><USER34> How is this different from Codility?

</comment><comment><USER35> Nuts. On challenge #1 my code passed 14/15 of their test cases, and failed on the final one. Only, I don't get sufficient feedback to determine where the bug is.

Ok - I only spent 15 minutes on this, and I'm not particularly interested in finding a job with any of the companies that are listed. Still annoying though.

</comment><comment><USER36> Another potentially good idea trying to solve an open problem with lots of room for improvement...

...ruined by the ever-spreading concept that everything should be solved using web apps. I mean, heaven forbid that they actually have a physical center with employees testing people.

<comment><USER37> Who the hell would go to that? The internet exists, therefore use it to make "physical testing centers for hackers" totally irrelevant.

<comment><USER36> By this logic, companies should never interview in person.

</comment></comment></comment><comment><USER38> I love the idea, running into a bug though. I'm getting a "Compilation Error" message on my submission, but it compiles fine locally, and clicking "Compile Message" to see the error just brings up a blank window. (Username: andrewbadr, using Chrome 13 on OSX)

<comment><USER7> Checking it up right away.

</comment></comment><comment><USER39> What kind of companies require this kind of service to screen the engineers? Maybe when hiring via odesk? Hiring remotely for short coding gigs?

I'm genuinely interested since I'm not sure if startups or big corporations will use something like this.

</comment><comment><USER40> For the sake of comparison, there is a site with a similar aim that was mentioned here earlier. <http://www.codeeval.com/>

<comment><USER41> Also, there is <http://www.coderloop.com/>

</comment></comment><comment><USER31> Looks cool, maybe i'll go solve a few of these.

 _Please log in with google._

Never mind.

</comment><comment><USER42> There's also an interesting tool that's open source in case you don't want to pay for Interview Street called WebCat used by some universities to run automated test cases. Not all software can be automatically tested (and in the case of WebCat, I think there are only plugins for C++ and Java at the moment).

<http://web-cat.cs.vt.edu/>

</comment><comment><USER43> I hope the system recognizes C and C++ as two different languages. That would be one hipster feature.

<comment><USER23> Of course it does !

</comment></comment><comment><USER44> If I may add my 2 cents - the design interface of this site is all over the place ... honestly it's such an eyesore seeing they can't even make the footer stick to the bottom of the page. Then there is the Terms of Service page -- such an embarrassment!

</comment><comment><USER45> The unemployed should be spending every minute trying to learn programming.

I'm surprised we haven't seen any sort of public awareness campaign geared towards learning computer science. Only recently is it starting to be "cool" and equivalent to lawyers/doctors.

</comment><comment><USER12> This looks really cool! A bit of design/copy feedback, none of it terribly urgent of course. Using Chrome 13 on OS X.

\- Copy problem on the main challenges page: "Solve challenging programming questions and land -on- your dream job."

\- On the challenges page "Solve This" buttons, the text is too high within the button, isn't centered.

\- "Are you a great company for hackers?" box on the challenges page has weird stray space at the bottom of the box. Either vertically center the contents of the box or cut off the bottom.

\- Typing error in the FAQ: "No worries, the remaining invites automatically get-s- added for the next month." Sort of awkward anyway, maybe "automatically roll over to the next month" is better?

\- On my laptop, the live chat tab covers up the "All Rights Reserved" line, which doesn't matter but is a little visually annoying.

\- The check marks and X's on the pricing page aren't aligned correctly with the row labels. They're aligned by the bottom of the text to the bottom of the icon, but the icons are bigger so it looks off. You should align the center of the text to the center of the icon.

\- "Buy Now" buttons on the pricing page aren't centered correctly within the columns

\- This is a small one, but maybe "Recruit" and "Challenges" don't match very well as the two halves of your site. They aren't the same part of speech and don't perfectly convey the two areas. Maybe something like "Get Hired" vs. "Recruit" would more clearly convey the split?

\- The "About" page could do with being re-worked in a lot of ways. The spacing is pretty messed up (for example, YC branding has tons of space above, none below), and the paragraph format makes no sense for the information you're conveying. If you want to include companies you've worked for, why not make them a list. Overall, this page doesn't seem to serve any effective purpose beyond being a placeholder for some eventual page. There are also a ton of copy errors:

"At Interviewstreet[ _Isn't the 'S' capitalized in your brand?_ ], we are looking to change the way the recruitment industry works. We are a team of five hardcore hackers and our Hall of Fame reads as[ _This is really unclear and awkward language. A Hall of Fame is usually comprised of people, not their accomplishments. If you want to keep it, change "reads as" to "includes," but it might be better to say something like "with experience at companies like"_ ] MediaWiki, GNOME, Firefox, Libreoffice and Hadoop hackers, multiple Google Summer of Code participants, ex-Yahoo!, ex-Amazon and ex-IBM . Having worked in top Silicon Valley firms, we understand what hackers look for in their perfect job and[ _New sentence here?_ ] with InterviewStreet, we hope to match programmers with the best jobs out there[ _Needs punctuation_ ]"

and

"We are always online - just hit an e-mail[ _"hit an e-mail" is a strange phrase; maybe it's lingo I don't know or something but I've never heard it. What's the advantage over "send?"_ ] to email@example.com (or) call us at 512-800-3815,[ _New sentence?_ ] we will get back to you! save[ _Capitalize_ ] the precious time of your employees[ _Maybe "Save your employees' precious time" is better, but I'm not sure what you even mean by this, or why it's here._ ] :-) Hiring is fun from now on!"

\- "Contact Us" page is also a little weird. If I'm in "Challenges" and click on the link in the footer, it takes me to the "Recruit" tab for some reason. The spacing is strange: there's a ton of vertical space in between "Recruit" and "Contact Us," but the fields and field labels and submit button are all jammed together. My eye loses track of which field labels apply to which fields unless I start at the top and move down.

<comment><USER7> Wow! Thanks a ton :) Fixing all of them. Please check up the site in 20-30 mins, everything would be up

<comment><USER46> Button text is still broken for Windows Chrome 13.0.782.107

</comment></comment></comment><comment><USER47> I thought that this was a cool service, but then I opened the Pricing page and I went "Holy Shit"!

</comment><comment><USER48> What's there to stop blogs with problem solutions or how-to's from popping up?

<comment><USER49> Very little. However, if companies are making their own problems and the same set aren't used for every job posting, it would be harder to make a general how-to for every problem on the site. It also would probably not be that hard to determine which problems have publicly available solutions, or if the solution an applicant uses is publicly available - for that matter, if I were an employee of this company I might advocate for creating fake solution websites (with flawed solutions), so that applicants who were simply copying code could be easily detected.

</comment></comment><comment><USER50> Support for solving programming challenges in Bash? Killer feature!

</comment><comment><USER51> Any ideas about how the scoring mechanism works on the site?

</comment><comment><USER52> Might want to tell your co-founder that pictures of hot chicks on his blog might not give the most professional impression:

<http://sp2hari.com/>

<comment><USER53> Disagree.

 _Oh, and, by the way, if you think that it's unprofessional to be funny, then I'm sorry, but you just don't have a sense of humor. (Don't deny it. People without senses of humors always deny it. You can't fool me.) And if you work in a company where people will respect you less because your specs are breezy, funny, and enjoyable to read, then go find another company to work for, because life is just too damn short to spend your daylight hours in such a stern and miserable place._

<http://www.joelonsoftware.com/articles/fog0000000033.html>

</comment></comment><comment><USER54> What? No Lisp option?

<comment><USER55> The question would be, which LISP? We have too many to choose from :)

Clojure, however, is coming soon.

<comment><USER54> > which LISP?

Arc. Obviously. :-)

</comment></comment></comment><comment><USER56> Have you ever met an elite programmer who was not an alpha male or alpha female. I would simply test for signs of dominance.

Edit: downvoted. Two possibilities spring to mind:

1) Downvoted by a feeble mind not capable of constructing an intelligent retort.

2) Downvoted by a relatively strong, yet ultimately scarce mind that wants to prevent access to the truth.

</comment><comment><USER57> The writing for the statements of the three problems has some severe errors at the level of eighth grade English and Algebra I. No one very good at solving those problems should spend their time on problems so poorly written.

E.g., for the first, really serious, substantive error, in the first problem, the largest possible size or absolute value of each of the "N numbers" was not specified. Without any such specification, it is not possible to write solid code to solve the problem.

The problems look like rotten bait on rusty hooks. I'm not biting.

The third problem does have some cute contact with convexity that can be exploited to give a relatively fast algorithm.

Will I write out the code? I will not! The problems suggest that writing the code is the main challenge, that if I could write the code then I would, and if I don't write the code then I can't and am shown to be unable and should be embarrassed. This suggestion is nonsense and an incompetent insult, and I'm not falling for that insult.

My work in computing and computer science has passed reviews with competence far, far, FAR above that of what the problems show for Interview Street. Net, Interview Street is promising that its really bad house painters are the ones to pick someone to paint the ceiling of the Sistine Chapel which is insulting nonsense.

Besides, more important than the code would be the documentation that explained why the code is correct, but the problems are not seeking such explanations. So, the problems are a bad example of how to work in computing and a 'bummer'.

Today I'm writing code to get a use of Windows Communications Foundation (WCF) working for the asynchronous 'remote procedure call' communications I need for the server farm for the Web site for my project.

Yes, the third problem has some math, but my startup has at its core much more math, much more advanced, powerful, and valuable, and some nicely original. Besides, I have all such math for my startup in code ready for production so that at this point I just need to get code using WCF to connect together the asynchronous parts of my server farm and write a few more, simple Web pages to have code ready to go live. That is, WCF will so help me go live assuming, still open to question, that WCF is the 'right stuff' for my project; else I'll just write a TCP/IP sockets application. So, I have no time for puzzles with convexity with no business connection.

Besides, who at Interview Street would actually understand the convexity exploitation? From the writing of the math in the questions, likely no one would! That is, people who write math as badly as in the problem statements have little chance of understanding the convexity math of the third problem. That is, the writing of the math indicates solidly that the writers know far too little math to understand the role of convexity in the third problem.

Instead, it looks like Interview Street got the third problem from a textbook on, maybe, facility location and, then, made a mess of copying over the problem.

So, the third problem is in facility location: Maybe I should call up one of my old facility location profs, J. Cohon, now President at CMU, or just get out my class notes! Or, with convexity, maybe I should get out my old notes on optimization. Besides, what employer would appreciate the role of convexity? Likely none.

So, writing the code is a fool's errand. Life is awash in fools' errands to be avoided.

No, to solve the third problem well, the main issue is actually not writing the code but exploiting the convexity; that I have noted this is likely a better 'solution' than most of what will be submitted.

Indeed, any good solution will have to address the math of the convexity carefully and otherwise be just a lot of gibberish with no reason to believe in its value. Net, the third problem is not in computer science but in applied math; once again, computing, out'a gas, is looking to applied math for 'content' and is making a mess.

My background is in applied math, especially for business problems. Given the math, the computing is routine! The coding ain't the main challenge, guys!

Interview Street is illustrating a serious, fundamental problem with current computing: It doesn't know the difference between applied math and software. In particular, a good solution should not be in C, etc. but in TeX and is not 'code' but theorems and proof. Sorry 'bout that!

<comment><USER58> Dude, you need to get off your high horse. What you are saying might be true, but you offered no better way of sorting through 1000 candidates. Besides, making applicants solve problems does _not_ imply that writing code is the _main_ skill, it only implies that it is a _required_ skill. (Given all your math talk I wouldn't expect you to make that fallacy.) If the object is to sort out scores of unqualified applicants, then any simple criterion that weeds out a significant fraction is useful. Unless you can make a convincing argument that the tests will _decrease_ the fraction of qualified applicants, your post just smacks of arrogance and entitlement.

<comment><USER57> You are jumping to misunderstand:

I didn't say that your "making applicants solve problems" was bad, just that the problems, especially the third, in this thread are bad.

"Unless you can make a convincing argument that the tests will decrease the fraction of qualified applicants, your post just smacks of arrogance and entitlement."

I believe that others on this thread have made such an argument. Again, I'm considering just the three problems on just this thread.

For how to sort through "1000 candidates", I do have an improvement: Don't use the test of this thread!

So, that takes us back to what we had last week.

You want to move forward from there? For that, I'm lost; I don't see the severe problem. I've been in computing for a long time and have interviewed and been interviewed, done projects and supervised projects. Once I had made some progress in my career, I never thought that recruiting or interviewing was very difficult.

Here is a way to improve the situation: Return to the early days of Java, when it first came out. Then the job ads were awash in requests for persons with "two years of Java experience". So, why not just call up Gosling since he was the only one who was qualified! That example is from a very general pattern: Pick some highly specific, improbable combination of 'skills' and demand that an employee have all those 'skills'. Nonsense. So, the first step forward is to quit recruiting for specific 'skills'. Just STOP it. Don't do it anymore. Drop it. Give it up.

Next, mostly what recruit for is general technical talent. A BS, MS, or more in math, physics, or computer science (in that order!) from a good university should do fine. If there is more evidence that the person is 'bright', then fine.

Next, recruit for some basic computer 'skills'. We're talking declare and allocate variables, assignment statements, if-then-else, do-while, and call- return. How difficult is that?

Next, recruit for interest in the work.

Next, recruit for general presentation of self.

Then, hired, expect that the person will get 'trained' on the job. The person will need a few months to become useful to the organization. The training can be self-taught, mentoring, routine supervising, some video materials, some presentations within the group, some training programs, maybe even with tests and grades, etc.

I've seen plenty of just routinely well qualified people dive into a new computer with a new operating system with new hardware devices with new programming languages, etc. and do just fine. E.g., when I was Chair of a college computing committee, I led an effort to get some new computing for the college. When it arrived, the existing staff jumped right in. One project was an application to contact, track, send mail, and get responses back from alumni. The guys just did it! Soon the college was sending boxes of mail daily to alumni. The software project quickly, uh, 'paid for itself'! Soon the university took over the project, rewrote it from just the high level description, and rolled it out to all the colleges on campus. Likely it again 'paid for itself'!

Where's the really big problem?

The main guy who did the alumni system? He worked for the college, but he didn't have a college degree and had had no courses in computer science. Not a problem.

I'm in the Mid Hudson Valley and hope to hire. I will be able to pick from people from community colleges, four year colleges, various development labs, and, of course, maybe Yorktown Heights. I don't see a problem.

If you see a problem, make sure you are not looking in a mirror.</comment></comment></comment>


OpenBSD pledge(2) "execpromises" - <AUTHOR> https://marc.info/?l=openbsd-cvs&m=151304116010721&w=2 <comment><AUTHOR> pledge(2): [https://man.openbsd.org/pledge](https://man.openbsd.org/pledge)

"pledge()'s 2nd argument becomes char *execpromises, which becomes the pledge for a new execve image immediately upon start."

This will be eventually be used to improve fork+exec daemons, permitting a much safer interlock between parent and child.

Previous mailing list discussions: [https://marc.info/?l=openbsd- tech&m=151302727506669&w=2](https://marc.info/?l=openbsd- tech&m=151302727506669&w=2)

[https://marc.info/?l=openbsd- tech&m=151268831628549&w=2](https://marc.info/?l=openbsd- tech&m=151268831628549&w=2)</comment>


Ask HN: what hackerly things can we do to reduce gun violence? - <AUTHOR>

<comment><USER2> Write the President, your two Senators, and your Representative, telling them what you want them to do. The simplest way to find their contact page: Google "contact <person's name>". That's what I did, and here's my message (if you want to crib from it):

\-- begin -- I _strongly_ support you doing whatever you feel best about to increase Americans' safety against gun violence. I would be in favor of:

* limiting access to guns (especially assault weapons)

* increasing access to mental health care

* increasing gun owners' legal liability for actions performed using guns registered to them

Thank you so much for your leadership and work on this.

Respectfully, <your name here

\-- end --

<comment><AUTHOR> I support your doing this, and of course it's meaningful to tell elected representatives what we think.

But, on average, not enough people do this, and not enough elected representatives actually change their positions based on sparse feedback.

By hackerly, I meant: how can we change and/or game the system to create change AND/OR what are some creative solutions to the problem.</comment></comment>


The Space Shuttle and the Horse's Rear End - <AUTHOR> http://www.astrodigital.org/space/stshorse.html <comment><USER2> And now for something completely different: [https://en.wikipedia.org/wiki/List_of_track_gauges](https://en.wikipedia.org/wiki/List_of_track_gauges)

In other words, that's very similar to "1920x1080 is the natural screen size because it's most frequent." 1435 mm gauge becoming prevalent is not given by its inherent superiority, just a ex-post-facto observation.

</comment><comment><USER3> On the other hand, actual facts: [http://www.snopes.com/history/american/gauge.asp](http://www.snopes.com/history/american/gauge.asp)</comment>


Infographic - How to Increase Your E-Commerce App's Sales - <AUTHOR> http://www.pinterest.com/pin/526780487635499355/

<comment><USER2> A while back we were looking at issues surrounding mobile users, our site was built primarily in the late 90s and had lots of caveats and had organically grown beyond anything imagined.

we decided that, instead of an app- we'd rather go with a responsive design, so, we did.

Before: [https://web.archive.org/web/20110315032541/http://www.firebo...](https://web.archive.org/web/20110315032541/http://www.firebox.com/) after: [http://www.firebox.com](http://www.firebox.com)

I can't publish exact numbers, but our turn-over this year as a result (hopefully directly) is much higher- this coincides with our email newsletters that, when used, would open in a standard browser. (we send many emails, most emails appear to be opened on mobile devices)

I think responsive design is far superior to native apps in ecommerce; if only we could scale down the images to make smartphones not need to download 1.5mb of assets for every page :P

</comment><comment><AUTHOR> You have a point but you are still missing the bigger picture. I'll point out certain arguments that may help you understand my reasoning:

1\. if you offer an existing web service for users logins and account management, a native mobile app is probably going to be a much better investment, as it will provide tremendous performance benefits over using the mobile web.

2\. If personal data is being collected, it can often be done so more securely in a native app than on a responsive site.

3\. You are going to be missing out on the hardware features of the platform like accelerometer on an iPhone.

4\. Always a better network connection.

I hope you understand my point of view by now and very frankly in the near future native apps are going to dominate the market even more rapidly.</comment>