7 ms·

It is fascinating to watch how both the java and javascript communities deal with the very different shortcomings of their respective programming languages. It

• pron 11y ago
  It is fascinating to watch how people underestimate the cost of switching a programming language[1], and overestimate the benefits of a new one. It is also horrifying. [1]: Switching to another language on the same platform (JVM/JS) lowers the cost considerably, but it is still high.
  • istvan__ 11y ago
    True, how about starting with the right language? :) I only write Clojure for both JVM and JS. Works like a charm. The only problem is when you need to work in a team and nobody does anything else but Java and JS.
    • pron 11y ago
      My rule of thumb is, if you need to switch a primary production language more than once a decade[1], then you're picking them wrong. Personally, I've been using Java for over a decade, and a few years ago I added Clojure to the mix and expect it to serve me for over a decade, as well. I like them both and believe they both qualify as good picks. I'm also adding Kotlin now, too, mostly because its switching cost and added risk are practically zero. [1]: for reasons other than targeting a new platform
      • kcorbitt 11y ago
        Seconding Kotlin coming from Java. It takes maybe 2 days to learn everything in the language if you already know Java, and it fixes pretty much all the warts that bother me about Java (the big ones for me are immutable references, first-class/higher-order functions, and unnullable-by-default references. Type inference and string interpolations are handy as well). It also has a small enough runtime/stdlib (unlike Scala or Clojure, which I've also tried) to make it practical to use in environments where startup time matters, specifically Android.
        • fnordsensei 11y ago
          When it comes to startup times and Clojure, I'm keeping my eyes on Skummet: http://clojure-android.info/skummet/ http://clojure-android.info/skummet/
      • pbh101 11y ago
        Just want to say I found this comment informative, on-topic, and its tone respectful and appropriate, so I'm disappointed it has been downvoted :(
      • fnordsensei 11y ago
        Speaking of which, Estonia recently implemented a "no legacy" directive [1], under which all government systems will be rewritten from scratch at least every thirteen years. They are taking the stance that a good implementation will last around a decade, not less, but also not much more. [1]: http://www.ozy.com/rising-stars/taavi-kotka-is-putting-the-e-in-estonia/32101 http://www.ozy.com/rising-stars/taavi-kotka-is-putting-the-e...
        • pron 11y ago
          Sounds about right.
      • istvan__ 11y ago
        Absolutely, I need to learn about Kotlik, it almost looks like Scala at the first glance. I agree with you about languages and targeting 10+ years with it. Stability is worth more than anything to me, out of the box performance also important (this tend to be great for older languages) not to mention the std library quality. For these reasons Java is an excellent choice. Clojure came to me as a total surprise, since I haven't studied CS and because I was surrounded with Perl/Java engineers for a long time I haven't heard about Lisp till 2011. It changed my approach to software engineering a lot. It is absolutely eye opening, mind blowing and all that jazz.
    • zzalpha 11y ago
      ROFL. "Right" language. There is no such thing. There's only technical tradeoffs and personal preferences. Everything else is simply faith and dogma. But, I'm sure someday we'll all discover your one true God... Err... Programming language, like the lispers and smalltalkers, the rubyists and the haskellers, the C++ fanatics and the C faithful...
      • istvan__ 11y ago
        There is such a thing but the scope is usually limited to a problem, a project, a department or a company. A good example would be OCaml and Jane Street for the latter.
        • zzalpha 11y ago
          Right. So for the exact same problem domain, one company might use Java and another might use Haskell, purely because of history, the candidates they can find, and any number of other possible concerns. None of this has anything to do with objective technical superiority of one solution or another, assuming you could make that case definitively. And if one could make that case, technical superiority is only one input into a much more complicated decision-making process. Again: there is no one true language. There never was and there never will be. Our entire industry, hell, all industries, operate based on tradeoffs, whether those be business, technical, political, or other. Why would programming language selection be any different?
    • frugalmail 11y ago
      Lol right, I'd take all the shortcomings of a statically and strongly types language like Java in my problem domain over a dynamically typed language like Clojure any day. But since you're probably still in school or in your first startup you wouldn't understand.
      • icebraining 11y ago
        Let's avoid personal attacks, please.
      • dkersten 11y ago
        I've programmed professionally in C, C++, Java, PHP, Python, Javascript and Clojure. I've been out of school for a number of years, have worked for a few companies and cofounded two startups. I still choose Clojure when I can.
    • wlievens 11y ago
      In ten years some other language will get the right language, and the things you're talking about will be for dinosaurs. Don't fall for that trap. What matters is that you build solid software that delivers value.
      • istvan__ 11y ago
        Well I might have given you the impression that I am a Clojure zealot. This is not true at all. I program in Ruby, Python, Java, Erlang, Go and OCaml on the top of Clojure. The only reason I prefer the later it because I can use the same minimal syntax to target 2 VMs and that is a huge win. It is also fun to show people the power of Lisp time to time, but that is it. If my manager or team asks me to write code in a random language I am going to learn it and do it, but for personal projects I tend to use Clojure. This is all.
• banthar 11y ago
  This is just what programmers do. They all have irresistible urge to write their own meta language on top of what they are using. C programmers do that with pre-processor. C++ programmers do that with templates and pre-processor. Java programmers do that with annotations.
  • pron 11y ago
    And then you have Lisp, that said, "fuck it, let's keep just the meta-language!" :)
    • 616c 11y ago
      Not sure if you mean that positively, but considering your Java work, if meant positively, that is a huge compliment!
      • pron 11y ago
        Oh, it certainly wasn't negative. I was doing Scheme long before I did Java, and I'm doing quite a bit of Clojure now, so I'm certainly a long-time Lisp fan.
        • wlievens 11y ago
          I learned Scheme before I learned Java. Knowledge of lisp family languages makes me a far better Java programmer.
        • 616c 11y ago
          As mentioned previously, I finished up some preliminary Java coursework. This was around the time our quasar and pulsar work took off in popularity. I see you as a hero and hope for a 1/1000 of your productivity when I peak. Glad to see you were a Schemer too.
    • agumonkey 11y ago
      The thing is, will there be a time where people will stop dealing with a concrete specific language to stay at the `lisp` level, or will this keep going on forever ?
• cscurmudgeon 11y ago
  Fascinating. A programmer gives automation/abstraction to other domains, but yet uses tools which rob him(her) of that in their own work. Amazing that we had tools to solve most of these problems decades ago.
  • lemevi 11y ago
    How does anything here rob the programmer of automation and abstraction? This adds something, it doesn't detract. It's an annotation you can use where you want. Your observation is specious.
    • pbh101 11y ago
      The GP is referring to Java as the tool that robs the programmer of [various dimensions of] abstraction.
    • cscurmudgeon 11y ago
      This is like a robber who takes your entire house and lets you stay under the porch only when it rains. Will you be grateful to them for giving you shelter?
      • kedean 11y ago
        Not really, no. If we're doing analogies, it's like you bought a house with no porch, and sometimes you accidentally get locked out and are stuck in the rain. These guys came along and built you a porch to put next to your house for when it does rain.
        • cscurmudgeon 11y ago
          It is 2015, there are house with porches since 1950 that you could have bought at the same rate. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
          • eropple 11y ago
• ExpiredLink 11y ago
  What "shortcomings"? What's "horrifying"? What real-wold use-cases does this "Immutables" library solve?
  • saryant 11y ago
    Immutable values can be safely shared across concurrent contexts.
    • banthar 11y ago
      You can create immutable classes "by hand". Just make all fields final and either primitive or reference to immutable type. This framework just makes it a little bit shorter to type as it automatically generates some boilerplate code.
      • TheLoneWolfling 11y ago
        And you can also simulate any Turing-complete language using any other Turing-complete language. That doesn't mean it's practical to do so :)
        • danieldk 11y ago
          As someone who programmed Java a couple of years, because work: it is quite doable, since there are now good collection libraries that provide mutable collections (e.g. Google Guava). Of course, you cannot get the same guarantees that e.g. Haskell provides. Moreover, unless you return concrete types, that Map<> being returned by a method could be mutable or immutable (it's your guess ;), or hopefully in the documentation).
          • TheLoneWolfling 11y ago
            The problem is, as you say, it is quite doable, as long as you have internal access to all of the code. There's no way to ensure that, for example, a function actually returns an immutable map, or actually doesn't modify a map passed to it. (And no, Collections.immutableMap doesn't.) (And then there are problems with the JVM bytecode as well - do you know you can pass 2 into a function expecting a boolean? And sometimes it'll get treated as true and sometimes as false? The JVM is "wonderful" like that.)
• unclebucknasty 11y ago
  Mutability isn't a shortcoming. It's a feature.
  • hyperpape 11y ago
    It's arguably a good feature, but I've come to the opinion that it's a bad default.
    • unclebucknasty 11y ago
      As with any feature, it must be used properly. But, from an OOP perspective, modelling state changes is natural and desirable. So mutability seems a sensible default. It's only the recognition of issues that can arise from state changes that has us wanting to lop off the entire feature. A rather strange and drastic "solution" in my view.
  • nmrm2 11y ago
    Immutability isn't a shortcoming. It's a feature. :-)
    • unclebucknasty 11y ago
      Hold on to that thought. I'll check back in with you in, say, 5 years. By then, we should have all endured enough unnecessary pain to lurch back in the other direction. :)
      • fnordsensei 11y ago
        We're well into the era where scarce computing resources no longer limits us the way they used to. We're over some kind of hump with regards to that. Since computing power is more abundant, the limiting factor we're currently running into has to do with the cognitive overhead incurred by our current tools, since tools always lag behind somewhat. Our current tools are primarily built to be efficient with machine resources, but are not necessarily built to make efficient use of cognitive resources. As cognitive resources become the bottleneck, it's sensible to invest in tools that decrease cognitive burden. So we're seeing an upswing in popularity with methods and techniques aimed at limiting the amount of unnecessary, incidental complexity generated. "Easier to use" is nice, but "less complex" is imperative right now. Immutability is one of those techniques that can be leveraged to limit growth of complexity.
• hyperpape 11y ago
  This requires some explanation. What limitations are people working around here? If you mean immutability, it's doesn't make sense to single out Java, since immutability was not significantly valued by any mainstream language until the 2000s (of course Haskell and various MLs existed before, but I'm talking about popular mindshare).
  • danieldk 11y ago
    Exactly. Object oriented languages of this generation even embraced mutability. The idea was that by having encapsulated/hidden data, methods could validate data and make sure that objects are always in an inconsistent state, hence making mutability safe. (Of course, the same can be achieved in C with opaque pointers.) It was only until concurrency/parallelization/multi-core became more important that immutability-by-default gained much traction. Nowadays, Java feels like the victim of the OO hype: mutable by default, static methods being the only escape hatch from OO, only predefined value types (yes, I know, Java 9). People always say that Go is like pre-generics Java, but it at least doesn't make two of the aforementioned mistakes.
    • catnaroek 11y ago
      > make sure that objects are always in a consistent state This only works for invariants that constrain the state of a single object. Realistically, invariants that constrain the state of multiple objects are a necessity, and no amount of in-object validation will help you enforce those.