1. 12

    This is an advertisement for their git commit-based metrics service, which is about as awful as one can get.

    I get these emails constantly as I have an admin account on our enterprise Pluralsight account, and I manage a developer team, and honestly this idea of “let’s use commit metrics to judge your developers” is not something I think anyone would welcome. Let me share a recent email they sent:

    Hey Adam,

    You can’t lead to what you can’t measure, and every day Engineers create troves of data that are currently unused.

    Sales, marketing, and finance use data daily to refine their processes.

    However, your engineering team’s git history is an untapped goldmine of data that can help you manage your teams and communicate with external stakeholders. There’s almost limitless data in your Git history waiting to be used.

    Ready to advocate for your team with concrete metrics?

    I have some availability this week to connect, when works for you?

    Thanks,

    1. 5

      This reads like a horoscope. And within it are really questionable assertions. “A developer in the zone produces evenly spaced, similarly sized pull requests”. Do people actually believe this?

      1. 2

        If the opposite means giving devs an hour between each meeting to complete their work, being in the zone is a wonderful thing.

      2. 3

        Well, I do think there is valuable data in the git history but not to judge developers. For example, the files with the most commits or the most authors are hot spots and a refactoring should be considered.

        1. 1

          this idea of “let’s use commit metrics to judge your developers” is not something I think anyone would welcome

          Maybe welcomed by the ones doing the judging; the ones being judged, not so much. :)

          1. 1

            I flirted with Codermetrics[1] after reading the O’Reilly book back in the day. I think it could genuinely be useful as a tool for self-improvement. Inevitably, though, it would be turned into a performance management tool and thence gamed or otherwise take on a life of its own.

            [1] https://codermetrics.org/

          1. 2

            Nice write up. I think this kinda thing is easy to overlook until it smacks you in the face.

            I came to a similar conclusion after running beam irl. If the whole point of the runtime is fault tolerance, it actually becomes a lot more complicated to figure out system health, since you need multiple vantage points. It seems so obvious in hindsight…oops.

            1. 1

              I would read the heck out of a blog post titled “Load Balancers Are Distributed Systems And We’d Better Start Treating Them That Way”.

            1. 4

              The atomic pi looks interesting. https://dlidirect.com/products/atomic-pi

              I thinks it’s fairly new, not sure if it works well or is a PITA, but it looks to check those boxes.

              1. 22

                This came up again in the context of the recent Dyn DDoS and comes up regularly in discussion of the Internet of Things and its general total lack of software or security.

                Link? I’m wondering why people think this. Do you mean people are arguing it would have made taking over the IoT devices impossible in the first place, or that a static type system would somehow make handling a DDoS possible? In any case, I think any reasonable person would see through these statements pretty quickly. You can find someone who has said just about anything.

                As static typing becomes more elaborate the scope of the bugs it can prevent becomes wider, but it comes with an additional cost: Build times.

                Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.

                My general experience of the correctness software written in fancy statically typed languages is not overwhelmingly positive compared to that of software written in dynamic languages. If anything it trends slightly negative. This suggests that for the scale of many projects the costs and benefits are close enough that this actually matters.

                Having written and inherited code in a dynamically typed language, I can say the big win, in my experience, is refactoring. IME, a lot of people (on both sides) talk about producing code the first time. IME, that is pretty easy no matter what language one is it. Coming back to code 6 months or 6 years later is a much different story.

                1. 14

                  Coming back to code 6 months or 6 years later is a much different story.

                  Oh gosh this so much.

                  I’ve inherited various chunks of under-documented under-tested code over time. Type-y assistance where present has made all the difference in these situations!

                  1. 11

                    Maintaining nearly 80KLOC of OCaml over three years, I was able to use repeated edit-compile-error-scratch-head sessions as a means to re-acquaint myself with the system. But this is such a low bar; we need better. Maintaining more than 1MLOC of Smalltalk over the past twelve years, I found leaning on a type system–even OCaml’s–to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.

                    1. 4

                      I’ve heard that refactoring smalltalk is a great experience. I don’t hear the same about erlang. Is this just a matter of the smalltalk folks focusing more on tooling? They’re such similar languages in a lot of ways, I would think you could achieve similar things, but I don’t hear people talking about refactoring erlang systems with such reverence.

                      1. 4

                        I can’t do it justice in a few lines, and I don’t want to clutter the discussion here. I will say that’s not just about Smalltalk but the mindset that Smalltalk fostered and, in turn, fed back into the evolution of Smalltalk. Go back, at least, to the writings of Ward Cunningham, Kent Beck, Ralph Johnson, and Brian Foote. As for Smalltalk itself, tooling almost emerges spontaneously from it because–I think–of the attributes I noted in the last line of my previous reply.

                      2. 3

                        to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.

                        Do you mean that the code bases are uniform in this way or that any program written in Smalltalk will have this quality? One reason I like a good type system is because most code is not uniform and the type system let’s me take messes and make them clean, pretty safely. But a type system is no panacea, of course.

                        1. 5

                          You can write bad code in Smalltalk, as in any other language. One thing that sets Smalltalk apart is that it’s as much a system as it is a language. Further, it’s a system represented solely in terms of objects sending messages to other objects. Further still, it’s a running, fully reflective, live system with that entire object graph readily introspected and manipulated. So, in Smalltalk–as Alan Kay said–architecture (uniform recursive object system) dominates materials (code). In Smalltalk, even bad code is easily navigated, understood, and refactored.

                    2. 7

                      “Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.”

                      Build time is measured the same, no matter the language. One could say a longer build time is justified because of certain benefits, but it’s still a longer build time.

                      1. 4

                        I’m not sure what I said you’re disagreeing or correcting me on. I am saying Ocaml builds fast, but slower than Go, but you get a lot of typing out of that extra time.

                        1. 3

                          That seems reasonable. The original statement might be more clear to me if it said “close enough to Go given…”

                      2. 3

                        Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.

                        That’s a good example, thanks. I’ll add it in.

                      1. 4

                        Hmm, I rather like crashable stateless microservices.

                        1. 3

                          Also known as Erlang. Which is indeed a nice concept, but the problem arises when people have crashable stateless services without the important pieces of Erlang: supervision trees, sane message passing, process links.

                          Microservices as many folks implement them really are poorly specified, slow, buggy implementations of half of Erlang.

                          And even if you do have all those pieces, there are hard problems at the application level to think about.

                        1. 24

                          This makes me very very thankful that the Rust team places such an emphasis on good documentation. It is so easy to let documentation fall by the wayside, and once you have commercial training providers pop up, it’s a lot harder to get documentation efforts going (because now you have businesses with a vested interest in the documentation remaining bad). Good documentation doesn’t just happen. It takes serious work and real buy-in from stakeholders, where they actually believe it is important to invest the time, money, and energy to do it right.

                          1. 22

                            It has certainly been a pleasure to have the support of the rest of the organization (both Mozilla and non-Mozilla) here. They’ve always said “we need good docs, and that means paying someone for them,” and it certainly would go much, much slower if I had some other job.

                            1. 4

                              Thanks for all the work! Your dedication really shows.

                              Nothing advances language growth like good documentation (perhaps a fabulous, welcoming community, but Rust also has that).

                            2. 3

                              This has been my observation as well. As soon as you get a for-profit-company who makes their money by selling “professional services” running a project, the documentation always falls by the wayside. Typesafe (or, Lightbend, as they prefer to be called now) is no exception here - and why should they be? Their business model depends on them pumping out ShinyNewThings as fast as possible and then selling consulting services. It really shows in the Scala ecosystem, so many Lightbend projects with flashy webpages touting their Reactive Big Data Synergy, and then the UX for them is terrible.

                              Meanwhile, the not for profit communities behind Rust, Clojure, Python, Elixir, etc put much more emphasis on delivering a smaller set of composable building blocks with thorough documentation.

                              I know the author of the post in the google-groups thread says he/she doesn’t believe this is the case, but I’ve yet to see an exception here, it absolutely is not specific to scala.

                              1. 1

                                i think that’s the best explanation - not so much having a vested interest in bad documentation so they can sell training, but that features will always have a higher return on investment than documentation will, so that’s where time and energy gets focused.

                              2. 5

                                It also helps that Rust’s design is a lot cleaner than Scala’s. While both Rust and Scala are larger languages than most, in Rust, every language feature has a clear unique purpose, and it would be very hard to achieve all of Rust’s design goals with a smaller language. On the other hand, Scala is full of features that were thrown in just because they initially seemed like a good idea.

                                1. 2

                                  Scala is full of features that were thrown in just because they initially seemed like a good idea

                                  Could you mention a few?

                                  1. 4

                                    Subclasses, traits and implicits: They all serve overlapping purposes (variations on ad-hoc polymorphism), which suggests they should be merged into a single feature. (Please don’t bring Java compatibility as an excuse.)

                                    Case classes make it easier to manipulate value objects by value, but their physical object identities are still there, waiting to be accidentally used. Instead, Scala could and should have provided actual value types. (Again, please don’t use Java compatibility as an excuse.)

                                    Extractors are inelegant: They hard-code support for a very specific use case into the core language, and they make pattern matching exhaustiveness checking unnecessarily difficult. If you actually want to enhance the expressive power of pattern matching, Haskell’s pattern guards are a superior solution.

                                    1. 7

                                      Though I think we could link some of these features together, Java compatibility is a major design goal of Scala. Ignoring the reason for features to exist makes it easy to call them not good.

                                      I also think that Scala follows a very C++-style design philosophy. Throwing in a huge amount of features gives people flexibility so long as they know what they’re doing.

                                      As to whether this is a good idea… depends on who you ask ;)

                                      1. 3

                                        Subclasses, traits and implicits: They all serve overlapping purposes (variations on ad-hoc polymorphism), which suggests they should be merged into a single feature.

                                        Classes and traits offer a clean distinction between classes that have initialization and classes that don’t. Having used a language without it, this distinction is essential to having practical multiple inheritance; I wish other languages would adopt it.

                                        Implicits alone couldn’t offer the same functionality as inheritance. I hope there’s a better design “out there” - something that offers the functionality of both - but I’ve never seen it.

                                        Case classes make it easier to manipulate value objects by value, but their physical object identities are still there, waiting to be accidentally used.

                                        Where? What’s the difference? I mean sure you could call System.identityHashCode on a case class and get unpleasant behaviour, but you wouldn’t do that by accident.

                                        1. 2

                                          Classes and traits offer a clean distinction between classes that have initialization and classes that don’t.

                                          Why do you need this distinction in the first place? In OCaml, heck, in C++, a class without initialization is just… a class without initialization. Going even further, in Eiffel, all effective classes have creation procedures, it’s just that some classes have empty ones.

                                          Having used a language without it, this distinction is essential to having practical multiple inheritance

                                          You’re conflating issues here. The linked article describes the unfortunate consequences of Python’s superclass linearization strategy for modularity: embedding one class hierarchy into another breaks the chain of superclass methods reached by repeatedly calling super. But this isn’t specifically related to initialization: it causes problems for normal (non-constructor) method calls as well.

                                          Implicits alone couldn’t offer the same functionality as inheritance. I hope there’s a better design “out there” - something that offers the functionality of both - but I’ve never seen it.

                                          A good starting point would be dissecting inheritance into multiple features, each of which does one thing and does it well.

                                          Where? What’s the difference?

                                          You can call eq on Options and Lists. How does this make sense?

                                          1. 2

                                            The linked article describes the unfortunate consequences of Python’s superclass linearization strategy for modularity: embedding one class hierarchy into another breaks the chain of superclass methods reached by repeatedly calling super. But this isn’t specifically related to initialization: it causes problems for normal (non-constructor) method calls as well.

                                            In theory yes. In practice __init__ is where the problem happens, 99.9% of the time. Many languages feel these problems are severe enough to ban multiple inheritance outright; I find the Scala approach strikes the best balance (a class may inherit from multiple classes, but from at most one class that requires initialization), and the class/trait distinction is the simple way to implement that.

                                            A good starting point would be dissecting inheritance into multiple features, each of which does one thing and does it well.

                                            A starting point isn’t enough - Scala is a production language, not a research language. Choosing a mature approach over a supposedly better but unproven one is not bad design.

                                            You can call eq on Options and Lists. How does this make sense?

                                            It makes exactly as much sense as calling eq ever does.

                                            1. 1

                                              It isn’t often that I say C++ makes sense, but, in this particular regard, it does: when an object of a base class is being constructed, no object of the derived class exists yet, so virtual member function calls inside a base class constructor are resolved to the implementation provided by the base class: http://ideone.com/Ytr6xm . Even if you use virtual inheritance: http://ideone.com/zvUbI5 .

                                              On the other hand, Java and Scala take the position that, even inside base class constructors, method calls must resolve to the implementation provided by the derived class: http://ideone.com/zv7iOq , http://ideone.com/uw1F43 . This is awkward precisely because it creates the initialization issues you mention - you could be calling a method of a class whose initialization logic hasn’t yet run.

                                              To summarize: In C++, the constructor is what creates an object in the first place. In Java and Scala, the constructor is what runs immediately after the object has been created. The latter is an inferior design, because there exists a point in time, between object creation and initialization, in which the object is in a bogus state.

                                              1. 1

                                                when an object of a base class is being constructed, no object of the derived class exists yet, so virtual member function calls inside a base class constructor are resolved to the implementation provided by the base class: http://ideone.com/Ytr6xm . Even if you use virtual inheritance: http://ideone.com/zvUbI5 .

                                                This is very confusing behaviour too. There’s no perfect answer here (except perhaps the checker framework with @Raw); I don’t think I’d call one approach inferior to the other.

                                                1. 1

                                                  An object is a collection of methods that operate on a hidden data structure. There are two important things about a data structure: its invariants and the asymptotic complexity of its operations. Leaving the latter aside, the role of an object constructor is to establish the object’s internal invariants, which all other methods must preserve. Viewed under this light, the behavior of virtual member function calls inside constructors in C++ is the Right Thing ™.

                                        2. 1

                                          Subclasses, traits and implicits

                                          I think lmm gave a good answer already. On top of that, I think that making up the requirement of merging typelclasses with dynamic dispatch is kind of a tall order given that Haskell itself can’t even manage to get type classes working in isolation.

                                          Scala could and should have provided actual value types

                                          Scala does provide value types. They are completely orthogonal to case classes.

                                          If you actually want to enhance the expressive power of pattern matching, Haskell’s pattern guards are a superior solution.

                                          This looks like the for-comprehensions Scala had since day one.

                                          1. 2

                                            merging typeclasses with dynamic dispatch is kind of a tall order given that Haskell itself can’t even manage to get type classes working in isolation.

                                            I have no idea what you mean by “get type classes working in isolation”, but I’m pretty sure that, if you create an existential package where the existentially quantified type variable has a type class constraint, the methods of said type class are dynamically dispatched.

                                            Scala does provide value types. They are completely orthogonal to case classes.

                                            Okay, then the question is - why aren’t Option, List, etc. value types, when they clearly only make sense when used as value types?

                                            This looks like the for-comprehensions Scala had since day one.

                                            Pattern guards have nothing to do with monads. All a pattern guard does is produce values that can be used in the right-hand side of a pattern matching arm:

                                            insert x (t:u:ts) | Just v <- node x t u = v : ts
                                            insert x xs                              = leaf x : xs
                                            

                                            If node x t u evaluates to Nothing, then insert x (t:u:ts) evaluates to leaf x : t : u : ts.

                                    2. 1

                                      (because now you have businesses with a vested interest in the documentation remaining bad)

                                      I’ve seen this sentiment a bunch, is it really that common of a thing, or are people just getting angry at documentation and rationalizing it as EvilCompany trying to sell services?

                                      E.g. I work at Elastic, and from time to time people complain about our documentation. And sometimes they claim it’s bad on purpose, because we want folks to buy services (these allegations almost always correlate with rageful tweets who ignore active attempts at help, fwiw).

                                      I can 100% say that’s not the case for us… it’s just a part of the documentation that’s bad, or old and poorly worded. Our docs are in our github repo, we wrote a book and OSS’d it, and we have several full time technical writers on staff (which are distinct from our education/consulting teams). We recently added checks that run code snippets in the docs, and fail the build if you break them. Etc etc.

                                      So I wonder if this sentiment is really justified, or if perhaps software just often has crappy documentation in places, entirely unrelated to offering services? Writing good documentation is hard, and good presentation of those docs often spans multiple departments (engineering for technical accuracy, marketing/web for proper integration into the site, infra if it requires special features like online REPL, etc).

                                      I dunno, having been on the sharp end of the documentation stick, I can appreciate it isn’t as simple as “your docs suck because you make money on services”. I think people underestimate the work that goes into good documentation. And how quickly good docs turn bad due to bitrot.

                                      Note: I know nothing about Scala, so it may really be the case :)

                                      1. 2

                                        So I wonder if this sentiment is really justified, or if perhaps software just often has crappy documentation in places, entirely unrelated to offering services?

                                        I think it’s entirely likely that there’s no actual human from the business who looks at the docs situation and says “well, better not improve those; that would go against the best interests for the company”. That doesn’t mean there aren’t emergent factors at play which subtly incentivize other things over documentation which wouldn’t be there if the revenue was structured a different way. You don’t need ill intentions in order for this sentiment to be justified.

                                    1. 32

                                      I agree with DHH’s statement that programmer happiness is all that matters. However, I haven’t met a Rails programmer that was happy writing Rails in, probably years. Everyone writing Rails constantly complains about how nothing works like expected, all apps become unmainable nightmares etc etc.

                                      If programmer happiness matters to the Rails team, what’s being done to increase it?

                                      1. 22

                                        I’ve said it before, but I wish the Rails team would invest more resources into maintaining an LTS branch. It’s easier to create happiness when a developer can just learn the tool once and get back to work without having to constantly learn the new version, spend time migrating code to it, fix broken tests, deal with incompatible plugins, etc. Unfortunately I think a lot of newer developers equate a stable project with a dead one, and they constantly want new shiny things.

                                        I’m a happy Rails developer because most of the projects I work on are stuck on old versions like 2.3 and 4. I never have to think about upgrading Rails unless it’s for the occasional security update, so I can just focus on writing my application. If I thought about what it would take to pull all of these things up to whatever the current version is, it would make me unhappy.

                                        Things like PHP succeeded because the language/interpreter moved very slowly (although this was bad for security, because certain things needed to change quicker) so developers could write code that still worked years down the road. This is kind of why I am apprehensive about learning Swift for iOS projects once it was open sourced - I think there are too many cooks in the kitchen trying to form the language around what they want, and it’s going to be a moving target for a long time.

                                        1. 6

                                          IMO, it all depends on scale. Once the experiential barrier is overcome, Ruby provides short-term programmer happiness with its object-oriented/procedural orientation and eclectic grammar (deriving from Perl and Smalltalk), while Haskell provides long-term programmer happiness with its extremely versatile type system and pure functional-ness. Each has a clean syntax, but the underlying paradigms make for radically different programmer experiences. Ruby is great for churning out code that’s fun and natural to write without jumping through functional hoops, while for more sophisticated tasks it may perl in comparison with Haskell’s strong maintainability and reasonableness. That’s just one example, but you might see how what makes me happy may not make you happy, and vice versa.

                                          Nevertheless, I wouldn’t call this a failure of Rails to make programmers happy per se; maintainability is a whole other problem that operates on an entirely different scale.

                                          1. 3

                                            A big part of this is because frameworks try to cram all of programming into a tiny color-by-number box and call it good. Eventually what you’re doing doesn’t fit so well, but you’re already stuck there, so you just hack atop it.

                                            Rails has enabled lots of projects to get bigger than they would have without it, but it doesn’t fix the fact that you need to know architecture eventually.

                                            1. 3

                                              I’ve worked professionally for the past 5+ years on 7 or 8 projects that used Rails in various capacities. For me personally, Rails is awesome when you aren’t stuck using all of it. If you’re using the routing/controllers, sticking your business logic in a service layer and leaving everything else out, it’s a joy. While there is some small level of efficiency you gain from all the automagical stuff, my opinion these days is that the opacity hurts more than it helps.

                                              Not to mention the… trendiness? Fad-culture? I’m not sure what the right way to label it is, but if you’re stuck trying to decide whether it’s fashionable this year to use helpers vs decorators (or was it presenters?), and wondering whether _changed? methods are deprecated this month, Rails can be quite a nuisance. Did “rake db:test:prepare” get undeprecated? Oh, lovely, I suppose we can use that again. Need to build an administrative backend for your own people? I guess it’s cool now to use ActiveAdmin, a deus ex machina gem that somehow attempts to what, simplify writing CRUD apps? I thought that’s what Rails was for.

                                              </rant>

                                              On a somewhat more serious note, I have worked on a very large Rails project where the performance of the application was perhaps the single biggest problem we had - largely ActiveRecord generating complex and inefficient queries which ended up being tediously re-written by hand. This wasn’t a Twitter-scale application, either. The Ruby language wasn’t at fault, but pieces of Rails certainly were.

                                              1. 1

                                                While it may or may not be impossible to remedy the programmer happiness problem within Ruby/Rails, I think we’re missing something if we only look within that community. Jose Valim created a language and community that is making people really happy. Elixir was heavily influenced by Ruby, and (at the moment) it nails the programmer happiness point - so to say “Ruby/Rails makes people sad” is a little bleaker than reality, it certainly fostered some good ideas that made their way into other microcosms. I’m sure there are other examples, but the point is that all software ends up becoming unwieldy and unpleasant, but the nice aspects generally make their way into other projects.

                                                1. 1

                                                  Rails dev here at Shopify. Still loving it!

                                                  We’ve still never had a complete rewrite but have been really good about keeping tabs on tech debt and making sure we’re running as close to edge as possible.

                                                1. 1

                                                  Building a streaming ESRI shapefile parser for geospatial data in elixir. The experience using geotools on the jvm for geospatial stuff was appalling, so I’m hoping to eventually replace a bunch of garbage at work with this.

                                                  1. 1

                                                    GM chief product cybersecurity officer Jeff Massimilla hints to WIRED that performing the cellular update on five-year-old OnStar computers required some sort of clever hack, though he refused to share details. “We provided a software update over the air that allowed us to remediate the vulnerability,” Massimilla writes in an email. “We were able to find a way to deliver over-the-air updates on a system that was not necessarily designed to do so.”

                                                    Reminds me of a scene from The Martian by Andy Weir.

                                                    1. 1

                                                      IIRC this is sort of how the Chrysler hack worked, the researchers were able to write their own version of the firmware and load it onto the car’s computer. I’m assuming the GM vulnerability was probably similar in nature, and then GM used the vulnerability to fix the vulnerability. Good thing they left that door open :)

                                                    1. 22

                                                      Why can’t I learn Haskell the way I learned $BOZOLANG? Because $BOZOLANG is just like every other language you’ve already learned. Hash-mappy/stringy/numby/mutatey whatevers

                                                      This is nonsense - Clojure, OCaml, Elixir etc can evidently be learned via web-apps without being “stringy/numby/mutatey whatevers”.

                                                      Shame that most Haskell evangelists can’t be as honest as Simon Peyton Jones: the trade off for Haskell’s benefits is making things that are easy in other languages obscure and difficult (the ‘hair shirt’). Whether those trade offs are worth it is contextual and, probably, personal.

                                                      1. 4

                                                        Clojure, OCaml, Elixir

                                                        Stronger point with OCaml than Elixir or Clojure, but you’d have to read very uncharitably to think I was talking about ML users. (Why would I be? ML users have and use a proper type system.)

                                                        I was a Clojure user before Haskell. You’re still structuring your data in Clojure most often in terms of a Map, the semantics and general patterns involved aren’t much different from Python or Ruby. I was speaking to what’s most common in industry. Most programmers I’ve known are jumping between Ruby/Python/JS/Clojure or languages like them.

                                                        1. 10

                                                          I think you’re taking an overly reductionist line of thinking. Distilling languages down to “haskell’s type system” and “not haskell’s type system” will lead one to your philosophy, but misses out on a bunch of cool differentiating factors among languages. Erlang is great because of the concurrency model, Elixir builds on that with metaprogramming, Clojure inherits a lot of the nice qualities from the JVM, Scala brings an assload of complexity and pain to the act of writing code, python is as simple as dirt, rust has a reasonable type system and a great deal of control over your memory, etc, etc. Taking a binary approach to language classification is an over simplification and will constrain your thinking, which is objectively a Bad Thing.

                                                          Also, as an aside, cut the crap with the smug tone, referring to languages your don’t like as $BOZOLANG isn’t constructive.

                                                          1. 4

                                                            I didn’t write the post because I wanted to talk about other languages. I wrote it because I wanted to explain why were taking a particular approach to teaching Haskell and why it requires taking learning the basics seriously (because it’s different).

                                                            Haskell being different isn’t a value judgment, it’s an observation about the foundations of the language contra almost all others (pure lambda calculus vs. augmented lambda calculus or fully imperative semantics).

                                                            If you’re secure in your choice of tools a single line like:

                                                            Hash-mappy/stringy/numby/mutatey whatevers.

                                                            shouldn’t create an entire sub-branch in a comment thread. That line also was not a value judgment, but a comment upon how easy it is for people to learn Ruby/Python/JS/etc. when they already know one of the other languages in that list.

                                                            It doesn’t matter that Clojure inherits whatever from the JVM or Elixir adds metaprogramming and better syntax to Erlang. These are orthogonal to my point. I’ve used these languages (Clojure particularly) and am comfortable with them, I’m talking about the core semantics of the programming languages and how what they have in common is frequently ignored by programmers when reasoning about what it’s like to learn a programming language. When you learn Haskell, to understand it properly, you will need to be able to reason in terms of lambda calculus. It’s not difficult, but most people haven’t needed to learn this because very few programming languages have a pure lambda calculus as their core semantics.

                                                            It’s about what’s different at the core. That’s all. You’re getting distracted by details irrelevant to the pedagogical issues because like most programmers, you’re taking for granted this collectively shared, fuzzy notion of “how programming works” that is mostly portable with minor modifications across most languages. Most programmers will never confront or understand what they’ve been taking for granted unless they use something outside that paradigm or they teach somebody that’s never programmed before.

                                                            I should’ve made this clear in my initial reply but I let the OP’s “getting away from the point of the whole article” distract me.

                                                            To understand a programming language, you have to learn the semantics of the programming language.

                                                            1. 9

                                                              I am not sure where I side in this argument, or if it is even necessary to take sides, but I think you are incorrect in assuming that people were offended by

                                                              Hash-mappy/stringy/numby/mutatey whatevers.

                                                              The part I found somewhat snarky and flippant was the use of the description $BOZOLANG for that group of languages, implying that they are useless.

                                                              Not to mention that Haskellers tend to be somewhat arrogant about what they believe the “perfect” programming language is, so I already had to consciously overcome some prejudice before I could even start reading the article (and maybe I am showing that I still have some prejudice, in which case, I apologize).

                                                              1. 4

                                                                Haskell isn’t perfect, there’s tons I’d like to add/change/remove. (Fair chunk of Prelude, for example; the upcoming Dependent Haskell stuff is exciting but not perfect/ideal)

                                                                I don’t even really want programmers-in-general to be convinced it’s a good language to use. I made the point recently on Quora that learning Haskell will not necessarily make you a better programmer in $DAYJOB. The article is about pedagogy, not language choice.

                                                                I’ll edit the post so people stop getting distracted.

                                                                1. 4

                                                                  Pre-emptive apologies if this is off-topic, but the thread seems mostly to be about this now.

                                                                  I see blog posts (and tweets, and reddit threads, etc) all the time about how Haskell has $THISIMPERFECTION therefore Haskell is completely worthless, and frequent posts (and tweets, etc) about how people who write Haskell are terrible people (usually not phrased as terrible – arrogant, pedantic, condescending, smug…pick a nasty adjective). You just did it yourself, though softening it with “tend to be.”

                                                                  Honest question: do you find snarking about Haskell and Haskellers to be more acceptable than snarking about other languages?

                                                                  I am new to Haskell, but honestly so far I haven’t met a single Haskeller who thinks Haskell is perfect – not even Kmett. And I see a bunch of Haskellers I know feeling that they must periodically assert that they know it isn’t perfect in order to avoid being labeled as arrogant, smug, etc. Do users of Golang or Ruby feel the need to frequently publicly assert their belief that their own language isn’t perfect?

                                                                  Again, I’m new, both to Haskell and to programming (Haskell is my first language; I was a linguist in my younger, more idealistic years), so these are sincere questions. This is in no way meant to posit a specific argument or take sides.

                                                                  1. 7

                                                                    I am not flyingfisch, but I will answer from my perspective. 20+ years in industry, 10+ with Haskell, only one shipped professional project in Haskell, later abandoned and rewritten in C++.

                                                                    do you find snarking about Haskell and Haskellers to be more acceptable than snarking about other languages?

                                                                    No. All languages gets snarked about – and in most cases there is a kernel of truth under it.

                                                                    And I see a bunch of Haskellers I know feeling that they must periodically assert that they know it isn’t perfect in order to avoid being labeled as arrogant, smug, etc.

                                                                    This is because of fairly well earned reputation of Haskellers (mostly around the edges, not core people) being arrogant, pedantic, condescending and smug. When I gave talks on Haskell I did the same thing (I even had line, “Don’t worry, I am not one of ‘them’, lets have some fun”) – because I know the horrible reputation I am up against from the start of a talk. The Haskell core community is full of great people, but as you get out just a little toward the edges you meet the people that use Haskell as an arrogance set piece more than a programming language. They love being able to claim superiority and constantly throw it in others faces. Phrases like “Not smart enough to use Haskell, go use one of your ‘popular’ languages” and far worse / less useful things. This was doubly easy because in most cases they were completely abstracted from having to ship actual code in Haskell, so it gave criticism no purchase… they could claim whatever nonsense they wanted without evidence or reality intruding.

                                                                    Do users of Golang or Ruby feel the need to frequently publicly assert their belief that their own language isn’t perfect?

                                                                    No, because these languages both strive to be fairly inclusive, adopted by corporations and straightforward. Because they are constantly used on real production projects, their faults are laid bare and talked about constantly. Beyond that, the “You are too dumb to ever understand Ruby|Go” just doesn’t fly – they spend 5 minutes reading and have a basic app working – an hour later they have a basic Web App working. Also, both languages are populist and strive to grow in terms of users, something that Haskell has really only gotten on board with in the last few years… and is still have a lot of trouble with, let alone corporate adoption.

                                                                    Again, I’m new, both to Haskell and to programming (Haskell is my first language; I was a linguist in my younger, more idealistic years), so these are sincere questions. This is in no way meant to posit a specific argument or take sides.

                                                                    The bottom line is, if you want to promote Haskell or teach it… you have to be aware of the public perception of it. Beyond that, I think you have to go out of your way to avoid being arrogant, condescending, smug and asserting things without evidence like “This isn’t hypothetical – I’ve seen a lot of people give up on Haskell because this is how they tried to learn the language.” which you could simplify to “Trust Me” or “Because I Say So” – people burned by the Haskell community in the past will see that as dripping with arrogance.

                                                                    This is unfair, you didn’t make Haskell have this reputation and were not even aware of it. However, you still have to deal with it. Enough people have been treated poorly by Haskellers (again, along the edges, not core people) and talked down to by them (mostly as a form of lame bullying) to view anyone who claims to come with good tidings from that camp with trepidation.

                                                                    I think you just have to be aware that a lot of times, the people who might be reading your material have already been burned, they don’t come from a clean slate like you did.

                                                                    1. 4

                                                                      Thanks for writing this, you put my thoughts into words quite nicely. I said “tend to be”, because that’s been my experience, though I realize that YMMV.

                                                                      I did not mean to be snarky in my comment, I was just making an honest observation about the experiences I have had with the Haskell community on their IRC channel and forums.

                                                                      That said, I sincerely enjoy using the language, and I hope it continues to grow. And FTR, I have also met great Haskell community members, but for some reason the negative ones are the ones who are the first to pounce on beginners. Of course, that’s just been my experience, there may be some bias involved.

                                                                2. 11

                                                                  I think I’ve finally realized why I find most of your writing so distasteful. I mean, I’ve always found your writing rather condescending (you knew that from our previous interactions), but here is a microcosm of the image you’re projecting in a single comment:

                                                                  If you’re secure in your choice

                                                                  but a comment upon how easy it is for people to learn Ruby/Python/JS/etc. when they already know one

                                                                  what they have in common is frequently ignored by programmers

                                                                  you will need to be able to reason in terms of lambda calculus

                                                                  but most people haven’t needed to learn

                                                                  You’re getting distracted

                                                                  like most programmers, you’re taking for granted

                                                                  Most programmers will never confront or understand

                                                                  what they’ve been taking for granted

                                                                  unless they use something outside that paradigm or they teach somebody that’s never programmed before.

                                                                  you have to learn the semantics

                                                                  Your writing is littered with authoritative prescriptions, but you are not a recognized authority on pedagogy. You write as if there’s one way to interpret or learn something, and I find that extremely off-putting.

                                                                  1. 6

                                                                    Hi. I’m his coauthor, both of the book and that blog post. I am, in fact, a trained teacher. I have taught in universities, in technical colleges, in public schools in Japan, and in private schools.

                                                                    Most of the sentence fragments you’ve picked out are not “authoritative prescriptions” at all; some of them aren’t even prescriptions, and a couple of them are seemingly quite uncontroversial (Haskell is based on a pure typed lambda calculus; if you eventually want to understand how Haskell works to any depth, you really do have to learn to reason in terms of lambda calculus. Perhaps you do not if you do not want to understand how it works under the hood). It’s fine that you don’t like the tone; other people have enjoyed it. And it’s fine if you personally can’t see through the tone to the content, but à chacun son goût.

                                                                    Neither of us believes there is only way to learn anything. The book has one set of goals and priorities. His guide has another. Other Haskell books try other strategies. The world is generally a better place for having diversity, is it not?

                                                                    1. 11

                                                                      I don’t really see much to disagree with in what you’ve said. My issue is with bitemyapp’s tone in comments here. I see it as condescending and presumptive.

                                                                    2. 1

                                                                      You write as if there’s one way to interpret or learn something

                                                                      I’ve mentioned at least two just in this thread, with different prerequisites and ideal circumstances. I even went into detail on the second one.

                                                                      If your point is that you don’t need to learn the semantics of a programming language to understand the programming language, you are making a very controversial point indeed.

                                                                      1. 14

                                                                        Honest question [for bitemyapp] – do you feel the criticisms leveled at you by burntsushi have merit? I honestly agree with ‘em wholeheartedly and have consistently found your comments and tone hard to stomach and extremely off-putting. The thing is – I always thought this was what you intended.

                                                                        I thought your goal was to be acidic and irritating while popping on every thread that mentions Haskell (or, half the time, doesn’t) to plug your book and be obnoxious so you don’t get ignored. I respected it as a business / marketing play and I think it worked fairly well for you as it was the only reason I poked at your blog and book – because I found you so contemptible.

                                                                        If it has been you goal, let me compliment you on your effectiveness and skill at it, you are amazing. If it isn’t your goal, you might invest 6 minutes in this video by Sally Kohn (a TED talk): https://youtu.be/NCJTV5KaJJc and consider how much of your message is carried in tone, and more importantly how little of it will get through if your tone is abrasive to the reader.

                                                                        1. 7

                                                                          If your point is that you don’t need to learn the semantics of a programming language

                                                                          No, that is not my point. Whether you’re correct or not is irrelevant (for example, I happen to agree with some of your points). My point is that your writing is unapproachable to me because of the number of assumptions littered at every turn about the knowledge and behavior of others. My evidence is the quotation in my previous comment. (The signpost is “you need” or “you did.”)

                                                                          1. 1

                                                                            I’m speaking from observation and experience teaching people Haskell. My coauthor is the real expert, but has never objected in my memory to anything I’ve said about pedagogy.

                                                                            I’m not going to litter my writing with weasel words just to avoid giving you an excuse to complain. There are exceptions to the rule, that’s not material to my point and they’re uncommon and not densely concentrated in individual learners in my experience.

                                                                            1. 11

                                                                              I’m not going to litter my writing with weasel words

                                                                              It’s quite possible to refrain from speaking from authority without using weasel words.

                                                                              There are exceptions to the rule, that’s not material to my point and they’re uncommon and not densely concentrated in individual learners in my experience.

                                                                              Again, you’re generalizing your experience instead of quantifying it.

                                                              1. 2

                                                                Plug+Cowboy in Elixir. Phoenix+Cowboy if I’m doing something bigger.

                                                                Python+Flask+Gunicorn+Nginx used to be my go-to. I find Elixir to be much more pleasant though.

                                                                1. 2

                                                                  At work its your old go to for myself. I’m not a huge fan of the python for this stuff to be honest.

                                                                  1. 1

                                                                    I’m not a huge fan of the python for this stuff to be honest.

                                                                    why?

                                                                    1. 1

                                                                      Python 2.6, that and I’m not a huge fan of dynamic languages in general. They’re fine but start to annoy me with runtime exceptions.

                                                                1. 23

                                                                  Just reading this makes me see red–like, blinding rage.

                                                                  Our build time at work was over 30 minutes. 30. Goddamn. Minutes.

                                                                  After griping for a while, I finally said “Fuck it, I’m going to solve this problem this week, leave me the hell alone.”

                                                                  Got it down to 13. Then 11. Finally, below 3 minutes. Still not doing anything clever like incremental linking or whatever–just removing unused includes, refactoring things into support libraries so we don’t keep recompiling the same damned things, etc. etc.

                                                                  This on an aging Core2 Duo with 4gb ram and spinny disks. Because we don’t believe in spending money on our developer’s tools.

                                                                  The answer I’ve gotten for like four months is “It’ll happen it’ll happen”…it’s like, fuck you I just saved the cost of three new machines in developer time spent goofing off–even told the suits this. Suits were amused at my list of numbers and charts showing saved money, and were like “dawww it thinks its an MBA…silly developer”.

                                                                  I can’t even properly express my unhappiness about this.

                                                                  EDIT: The thing that really pisses me off? The fixes were easy enough that the CTO should’ve done them a long time ago–it’s just a sign that a) his machine is so much better than ours that he doesn’t care and b) he doesn’t do enough coding to feel our pain. That, though, is a whole ‘nother story.

                                                                  1. 12

                                                                    Sounds like a ship to jump off of…

                                                                    1. 5

                                                                      …but if I leave nobody will look out for my team. :(

                                                                      EDIT: More seriously, it’s rough, because there’s good with the bad, right? The people are nice (even if they make decisions I disagree with sometimes), the problem is actually important (potentially fixing a lot of healthcare, no really, at like the fundamental new tools level), and I get to be pretty flexible in terms of commute and scheduling.

                                                                      They really do seem to kinda want to help, but they aren’t prioritizing on things like mentioned above, and it isn’t clear what the cashflow/runway situation is in. And the clients aren’t doing us any favors by being super slow hospitals.

                                                                      1. 10

                                                                        Admirable feeling, but you really need to look out for yourself. No sense prolonging the process if the writing is already on the wall.

                                                                        1. 5

                                                                          I’ve seen that situation before. You can’t fix the culture above you, and from the description of your meeting it sounds like respect has entirely broken down. As important as the project is: do you want to put that organization and culture in charge of the solution?

                                                                          If you can’t take your team with you, write glowing letters of recommendation to help individuals leave when you go. But you have to go, for your sanity.

                                                                      2. 8

                                                                        Perhaps this is why your handle is “angersock”.

                                                                        1. 7

                                                                          Would you say that that pain was “bold and unrelenting”? Or, more “caustic and burning”?

                                                                          Joking aside, it’s astonishing to me that, in an industry where our tooling is by it’s very nature entirely plastic, we put up with garbage fires like sbt; in fact, not only do we tolerate it, we get so beaten down that we celebrate the lousiness of tools, treating our scars as a mark of character, instead of stupidity.

                                                                        1. 8

                                                                          I’ve never worked anywhere with a reasonable build strategy. I jumped ship from the last place in part because I didn’t feel I could ever be productive, and a large part of that was the build process. It took about 2 hours to build and run unit and integration tests.

                                                                          Then I ended up somewhere where compilation takes ~10 minutes. Unit tests take 2 hours. Integration tests take all night. So now I’ve accepted that this is the norm, and that I will never be even 5% as productive as I am working on my own projects or working for a company under 10 or so people.

                                                                          Basically what I’m getting at is that you can’t examine pain threshold in a vacuum. It’s not a one dimensional vector where you can say “ok, this process has too much friction, fuck it”. There are external factors that play into a decision to alleviate that pain. The reason why I am not actively working on making the process better is because there’s a ton of momentum behind the current way of doing stuff, and organizational challenges in trying to change strategy such that I could work 24/7 for the next year and would not be able to put a dent in it. And the reason why I’m working at the place I’m at is in part because I’m not confident that anywhere else I would go would have a sane workflow either, as I’ve already gotten bitten by this once by jumping ship.

                                                                          Eventually this sort of debt catches up to any company and progress grinds to a halt.

                                                                          1. 5

                                                                            I wonder why you didn’t use the interview with the new company to make sure they do it better. I mean, isn’t the hole point of an interview to get information from the other side to be able to judge whether it is a good fit for both sides?

                                                                          1. 6

                                                                            A lot of these look like properties of elixir.

                                                                            The exception would be the lack of the common serialization and HTTP libraries included in the stdlib, which I wish would be added, as they would make writing little scripts without needing to pull in dependencies a lot easier. But within an actual project, the dependency management is so good this is a none issue.

                                                                            1. 6

                                                                              Is “JavaScript is a toy language” the new “writing scripts isn’t real programming”?

                                                                              1. 8

                                                                                Just because a language isn’t good at everything doesn’t mean it’s a toy language. If that were true, every language would be a toy and nobody would be doing “real programming”.

                                                                                The comic just calls out the shoe-horning of javascript into environments that it’s not really well suited for. It’s not an attack on the language, but instead calling out humans that are doing silly things. Javascript is great for some things, and not so great for others.

                                                                                1. 5

                                                                                  A better comparison would be “x86 is a toy”. We have these monstrous 64 bit machines that still boot up in 16 bit real mode with archaic instruction sets. Much like the cascading tech pile that is emscripten, asm, etc.

                                                                                  The criticisms here are more thorough, however. Callback hell seems like a valid weakness to point out.

                                                                                  1. 5

                                                                                    In that it’s infelictious, but largely true?

                                                                                    1. 4

                                                                                      Yes, that’s precisely what this is. It’s all about back-end developers trying to feel superior to front-end. Of course, JS isn’t only front-end now, because of node.js and related infrastructure… This is fairly subjective, but to me, the subtext of javascript-on-the-server was always that self-proclaimed server developers are often unwilling to treat web developers as equals, which makes it difficult to do meaningful collaboration, and most interesting sites require both types of work. You can see how that would be frustrating.

                                                                                      There really are not very many conceptual differences between the two, just language proficiency, so JS backends were fundamentally a move to ignore the people trying to be exclusionary and hope they went away.

                                                                                      And no, it’s not always easy for everyone to change career direction to use another language, precisely because of this, um, “typecasting” and rhetoric about how JS supposedly attracts less competent programmers. And I don’t actually agree that JS was ever bad enough to justify wanting to leave, anyway. This was always purely about claiming prestige and trying to hang onto it by putting down everyone else.

                                                                                      Given that history, it feels like making fun of the JS ecosystem is somewhat unsporting. It’s programmers who feel superior saying “well, you’re not inferior anymore but look at how silly it was of you to work so hard to get to that point!”

                                                                                      Although JS is certainly doing well as a technology today, so I could see a case that it’s the new incumbent. But then I’d like to see criticism of what it could be doing differently today, not of how it got here. Much of what the comic derides are (source) distribution and toolchain issues, which are no worse in JS than in Ruby, PHP, Java, or C++. All contemporary languages have absolutely horrible stories for distribution. Actually, that’s a big problem. :)

                                                                                      1. 3

                                                                                        I actually use JavaScript (well, CoffeeScript) voluntarily both on the server and client side because I think it’s the best available choice for my mix of components. I disagree with your assessment, and I think this picture is in fact a very good criticism of JavaScript and related tools. The problem is that people are thoughtlessly building a huge rickety tower of tools on a questionable foundation. This creates enormous complexity and churn, and makes it very hard to produce good software that doesn’t constantly require rewriting various parts as things break and become obsolete.

                                                                                        I don’t know what the solution is, and the root of the problem probably lies deeper - in the web platform, its evolution, and everything around it, rather than just JavaScript. However, it’s definitely frustrating regardless of whether I look at the server or client side development, and I believe this sort of criticism is worthwhile because it might just inspire somebody to think “Hang on, there is a better way of doing things”.

                                                                                        I agree with your last paragraph though; I can’t think of any language I’m familiar with which doesn’t have many issues of its own (C++, Ruby, C#, Python, Haskell - I can immediately think of problems with each), so it would be wrong to single out JavaScript as the only offender.

                                                                                        1. 2

                                                                                          The problem is that people are thoughtlessly building a huge rickety tower of tools on a questionable foundation.

                                                                                          A thousand times yes.

                                                                                          I don’t mind Javascript-the-language too much, though there are some design choices which in retrospect look like mistakes. For years, and long before anybody used the phrase “full-stack developer,” I enjoyed chances to do front-end work and prided myself on my willingness and ability to see my work through end-to-end and handle both the client and the server components. I was always the guy defending Javascript to my fellow back-end developers.

                                                                                          But Javascript’s limited standard library, lack of higher-level code organization facilities, and protean nature have always led to these all-encompassing frameworks where you have to buy into a whole cosmology, and at some point I just lost the patience to deal with the world of frameworks layered upon frameworks, where it takes half a dozen language-specific build tools and package managers to run even the simplest modern webapp, and where front-end build times (for an interpreted language!) exceed server-side build times. Maybe I’m just getting old, but I’m glad that these days I mostly get to leave the front-end to the front-end people (and it’s certainly not because I think that work is easier or of lesser value than the work that I do).

                                                                                        2. 3

                                                                                          Given that history, it feels like making fun of the JS ecosystem is somewhat unsporting. It’s programmers who feel superior saying “well, you’re not inferior anymore but look at how silly it was of you to work so hard to get to that point!”

                                                                                          I can’t speak for anyone else, but for my part in poking fun at the JS ecosystem, my complaint is along the lines of @jfb, in that the community has been considerably ahistoric. This is a complaint I sling at any place apporpriate, it just so happens that the JS community is the visible offender these days. The JS community has produced a huge amount of low-quality software completely ignorant of what has come before them and they are proud of it. I find it very frustrating to be in an industry where one of the biggest growth components is unintersted in self-improvement. That is a problem and one of the biggest contributors to my desire to become a farmer someday. It is by no means a new complaint but I don’t think it is getting any better.

                                                                                          1. 3

                                                                                            It’s all about back-end developers trying to feel superior to front-end.

                                                                                            So you chalk it up any criticism of javascript to people just needing to feel superior to someone else, and you think javascript is actually the one true language that should be used everywhere? That seems more than a bit reactionary and on the far other end of the spectrum.

                                                                                            I think some languages are just bad (not a fan of php either, fwiw). It is unfortunate that javascript is the only language available for browsers, and web developers have little to no choice of which language to use. There is no possibility of natural selection to weed out really terrible languages. So you end up with people creating X-to-JS compilers to escape javascript, and the web just ends up with more layers of complexity. With people trying to push the web into apps (mobile and desktop), I think this will only get worse. The Birth and Death of JavaScript is terrifyingly insightful.

                                                                                            1. 1

                                                                                              I don’t believe I said either of those things, nor do I believe them. I admit I’m a bit bewildered by such an emotional response; I try pretty hard to take personal attacks out of things like this when I write them, and I don’t think I did a worse than usual job this time. I realize it’s a sensitive subject.

                                                                                              I am absolutely a fan of any effort to explore more languages than we currently are, and to explore using languages for things they haven’t traditionally been used for. Compilers which target JavaScript are such an exploration. Escaping JS is not a wrong description of the goal, but understand that the cost of adding a new language to all browsers, and dealing with security and API-design and feature support for it, is immense. That has far more to do with the nature of the web, and JS’s good fortune to have gotten that position, which with current technology can really only be occupied by one language (or virtual machine) at a time. It has nothing to do with compiler authors disliking JS. If I prefer to study Buddhist writings in the original Pali, does that mean I dislike English?

                                                                                              1. 4

                                                                                                I don’t believe I said either of those things, nor do I believe them. I admit I’m a bit bewildered by such an emotional response; I try pretty hard to take personal attacks out of things like this when I write them, and I don’t think I did a worse than usual job this time. I realize it’s a sensitive subject.

                                                                                                eh? I just read what you wrote, which seemed fairly accusatory to me. Picking out a few things:

                                                                                                It’s all about back-end developers trying to feel superior to front-end…

                                                                                                self-proclaimed server developers are often unwilling to treat web developers as equals, which makes it difficult to do meaningful collaboration…

                                                                                                This was always purely about claiming prestige and trying to hang onto it by putting down everyone else.

                                                                                                It’s programmers who feel superior saying “well, you’re not inferior anymore but look at how silly it was of you to work so hard to get to that point!”

                                                                                                I don’t think what I wrote was “such an emotional response” by any means, it was certainly written more as bewildered bogglement than “such an emotion response”. The web clearly needs a <boggle> tag (would fit right in with <blink>).

                                                                                                If I prefer to study Buddhist writings in the original Pali, does that mean I dislike English?

                                                                                                Not sure what point you are trying to make here.

                                                                                                In summary: I wasn’t intending to come across as “emotional”.

                                                                                                1. 2

                                                                                                  Well, we seem to be talking past each other intent-wise; I was similarly confused by your response, and perhaps emotion wasn’t the reason.

                                                                                                  So you chalk it up any criticism of javascript to people just needing to feel superior to someone else,

                                                                                                  No, but this one.

                                                                                                  and you think javascript is actually the one true language that should be used everywhere?

                                                                                                  I’m at a loss for what I said that sounded anything like this.

                                                                                          2. 1

                                                                                            It’s been around. It kind of reminds me of immigration in the US. At one point, Italian Americans were considered weird and foreign. Now, Latinos draw the fire, but in 2035, they’ll be entrenched, must like YavaScript.

                                                                                            1. 1

                                                                                              No, because some of the people who said “writing scripts isn’t real programming” did actually program, a little.

                                                                                            1. 2

                                                                                              Pretty cool, although I’m not sure how the digital money scenario plays out. It seems like there needs to be a way to prevent double-spending, but I don’t see it. As I understand it, the same agent can sign two messages with the same sha1(sha1(key)).

                                                                                              1. 2

                                                                                                Maybe I’m not understanding the article, but wouldn’t enforcing that the key be immutable and enforcing that the signed key == the key used to locate it in the DHT prevent this?

                                                                                                Again, maybe I’m not understanding it.

                                                                                                1. 2

                                                                                                  Okay - so relying on some mechanism in some DHT to prevent double writes? My knowledge is admittedly limited on the subject - I’m really only acquainted with kademlia, which I’m pretty sure wouldn’t be very good at this.

                                                                                                  (I think kademlia nodes need a means of verifying that particular values are associated with particular keys. This is straightforward with bittorrent since everything is content-addressed. It’s straightforward with cryptographic signing too but I don’t know of a mechanism in a kademlia network that could prevent a keyholder from signing conflicting statements - like “sha1(sha1(key)): pay account A” and “sha1(sha1(key)): pay account B”.)

                                                                                                  I haven’t spent much time exploring the DHT zoo, and I wish I were more acquainted with the options available. Do you happen to know of a DHT that’s not content addressable but which preserves immutability? If that’s the case then I could start to understand the digital money scenario.

                                                                                                  1. 2

                                                                                                    I think you’re right about this.

                                                                                                    I was also thinking that there’s no good way to resolve conflicts with a system like this when a network partition is resolved. You could potentially resolve conflicts by breaking immutability, but it’s not possible to resolve conflicts while maintaining immutability in a p2p system like kademlia.

                                                                                                    Unless I’m missing something, but I just don’t see it.

                                                                                              1. 7

                                                                                                The author seems to think the grass is always greener. On the other side of the coin you have Java and Scala, which given a strong type system, have a vast array of tools with bundles of features that always seem impede more than help. Indeed, the nature of those languages allows you to make tools that on the label say they will make you a latte, but then proceed to take 20 minutes to compile your hello world program. This is speaking from experience; I can make my own latte, your job is to compile my program. Maybe this is a Java thing, but I’m reasonably certain C++ also uploads your entire program to skynet at 9600 baud each time you want to compile.

                                                                                                Writing a lot of python and javascript in my past life, I often found myself thinking the same thing as the author. “Gee, it would be nice if I didn’t have to run the test suite every time I make a change only to see that undefined is not a function”. Yes, that would be nice, and strong tools built on a language that allows you to make reasonable assumptions about the code and data might help you do that. But reality is a harsh mistress, and time has proven again and again that those tools will never exist because they will get exceedingly complex before they will become useful.

                                                                                                Or perhaps this is the inherently human element of software devolving into a cesspit as more people hop on the gravy train. Maybe this is why haskell has an elegant type system and tooling that doesn’t make my want to curl up into the fetal position and cry. But the fact that ruby is exceedingly dynamic actually spared it from the horrors that would have been introduced had it been possible to write more elaborate tooling for it.

                                                                                                tl;dr i wrote this entire post while my scala microservice was compiling

                                                                                                1. 5

                                                                                                  This is such a marvelously optimistic document:

                                                                                                  Even as the clock ticks, better and better computer support for the creative spirit is evolving. Help is on the way.

                                                                                                  One of my friends presented this paper, actually, as part of a monthly reading club we have, and what was just so amazing is just the sheer cultural difference it has compared with the New Jersey school. The audience during the presentations (enjoying beer and ribs) was smiling the whole time at how hippy and awesome the Smalltalk ideas were…it was just so weird and cool.

                                                                                                  I hadn’t seen the future like that since I ran into Prolog–unfortunately, it seems that the future is more Mad Max (Javascript).

                                                                                                  1. 2

                                                                                                    Smalltalk was ahead of its time, but the ideas and ideals live on in other languages. Erlang has technical features that are analogous to Smalltalk, but is missing some pieces imo.

                                                                                                    The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone.

                                                                                                    The mechanisms of human thought and communication have been engineered for millions of years, and we should respect them as being of sound design

                                                                                                    Elixir, from a strictly human standpoint, encapsulates Smalltalk’s main goal really nicely and in an accessible way, all while being built on Erlang which makes it inherit a lot of the conceptual tech bits that make Smalltalk so cool.

                                                                                                    The future doesn’t have to be Mad Max. And I think the excitement around more elegant languages (very recently, and I may be living in a bubble) is evidence of that.

                                                                                                    1. 1

                                                                                                      As much as I love Elixir, I don’t think we want to oversell it too much–after all, look what happened with Smalltalk!

                                                                                                      Specifically, I don’t think that it has the same emphasis on programmer ergonomics that drove a lot of that document, and it isn’t quite as possessive of the operating environment as Smalltalk seemed to want to be.

                                                                                                      It’s still really cool though! :D

                                                                                                  1. 1

                                                                                                    work: new job floundering and flailing. First job I’ve started with a stack I’m not familiar with, plenty of stress that I didn’t anticipate.

                                                                                                    otherwise: finishing up this little DOM utility in elixir after abandoning it for a while. haven’t written an html/xml parser from scratch before so it was kinda fun.

                                                                                                    1. 42

                                                                                                      Excuse the strong language, but I can’t stand snobbish, deceitful drivel like this. The article attempts to make the explicit point that programming is not a craft (because, apparently, the author thinks they have a monopoly on what it means for something to be a craft). But its subtext is far more sinister: it not-so-subtly weds the idea of craftsmanship to negative qualities like “big ego”:

                                                                                                      So here’s my concern with the idea of Software Craftsmanship. It’s at risk of letting programmers’ egos run riot. And when that happens… well, the last time they went really nuts we got Web Services, before that J2EE. They convinced the British government that they wanted an uber-database to store Everything Ever About Everyone. You see where I’m going?

                                                                                                      Um. What?

                                                                                                      Blatantly irrelevant analogies:

                                                                                                      Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.)

                                                                                                      Programming isn’t plumbing and plumbing isn’t programming. What one does has no bearing on the other.

                                                                                                      Well it seems to me the most succesful programmers I’ve encountered don’t craft software

                                                                                                      Which is clearly supposed to read as, “Successful programmers don’t craft software.” I’m not putting words in the author’s mouth. The entire point of the article is to seemingly generalize their own opinions to programming as a whole.

                                                                                                      More deceit:

                                                                                                      Do I need to demonstrate any kind of skill? No. Any specific credentials? No. Any kind of experience working in the field? Nope (and as the Pragmatic Programmers are happy to remind you, ten years experience is very different from one year repeated ten times). In fact, all I have to do to associate myself with Software Craftsmanship movement is to fill in my name on the website. Woohoo!

                                                                                                      As if acknowledging craftsmanship necessarily implies throwing out every other indicator. Really? The subtext with this nonsense is that people that see programming as a craft will produce lower quality code. The author even bemoans the loss of good programmers to the craft:

                                                                                                      Software practitioners – especially, ironically, the good ones – often lose sight of this. They fall in love with the software itself and start thinking of themselves as craftsmen of software.

                                                                                                      Unbelievably, despite the fact that programming isn’t a “proper” profession (the author’s words), the author has still somehow managed to identify good programmers from bad programmers. I know I’ve certainly never needed to see someone else’s certificate, nor have I ever needed the approval of some “Software Craftsmanship Council” to tell if a programmer was a real craftsmen or not.

                                                                                                      I’ll never forget my programming languages course. On the first day, the professor went around the room and asked us to name some properties of programs. You had the usual suspects: “correct,” “fast”, “functional”, “object oriented”, “size” and so on. I was the only one who said “beauty.”

                                                                                                      Donald Knuth has my back:

                                                                                                      We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better. Therefore we can be glad that people who lecture at computer conferences speak of the state of the Art.

                                                                                                      You can try to impose as many pre-conceived judgments on me as you want (“losing sight of the utility of software” or my giant “ego”), but I’m never going to stop seeing programming as a craft. I always have and I always will.

                                                                                                      1. 7

                                                                                                        Fantastic quote by Donald Knuth!

                                                                                                        A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better.

                                                                                                        To me, this is the biggest thing that separates a software engineering from many other engineering professions.

                                                                                                        1. 3
                                                                                                        2. 5

                                                                                                          Thanks for this. The article bothered me, but I didn’t feel able to explain why. As a “hook”, the author refers repeatedly to a disconnect between engineers and users, and, actually, that’s true - there are several such disconnects and they deserve individual attention. I suspect most readers will agree with that part. You correctly point out that the real thesis here doesn’t follow from it, and I agree with all your points.

                                                                                                          I guess I’d not go so far as to call this “deceit”; I believe the author is sincere. Most people who have conflated different things like this are unaware they’ve done so. I’ll give you “snobbish” though. :)

                                                                                                          You have me very curious - how did the professor and other students respond to “beauty”?

                                                                                                          1. 4

                                                                                                            As a “hook”, the author refers repeatedly to a disconnect between engineers and users, and, actually, that’s true - there are several such disconnects and they deserve individual attention. I suspect most readers will agree with that part.

                                                                                                            Definitely agreed.

                                                                                                            I guess I’d not go so far as to call this “deceit”; I believe the author is sincere. Most people who have conflated different things like this are unaware they’ve done so.

                                                                                                            Also agreed. I could have been more charitable. Just got a bit riled up!

                                                                                                            You have me very curious - how did the professor and other students respond to “beauty”?

                                                                                                            My professor paused and smiled, then moved on to the next student. It was one of those “first day of classes, let’s get the juices flowing” kind of thing. But that moment has stuck with me.

                                                                                                            We actually became very good friends. I went on to TA that course a couple times, and it is one of the most enriching experiences I’ve ever had!

                                                                                                            1. 1

                                                                                                              Neat. :)

                                                                                                          2. 2

                                                                                                            Well,

                                                                                                            I like the idea of programming as craft but I liked that the article raised a number of issues involved with the craft conception - despite the unfortunate “slick consultant” tone.

                                                                                                            The challenge is to engage in software craftsmanship in a fashion that makes a customer care about that craftsmanship.

                                                                                                            The example of the plumber seems good. The average person understands that not everyone who can stop a leak does so with equal skill. The immateriality of software makes that understanding harder. How can it be communicated to people effectively?

                                                                                                            1. 2

                                                                                                              Programming isn’t plumbing and plumbing isn’t programming. What one does has no bearing on the other.

                                                                                                              While you’re right, I think his analogy here is apt, but it also misses the point. A good plumber would see a bad plumber’s jumble of pipes and think “That’s a fucking mess”, just like good/bad programmers do with code. And why do we think it’s a mess? The reason a jumble of pipes or a pile of spaghetti code is scary is because we’ve been trained to recognize these patterns and associate them with a broken plumbing system or broken software.

                                                                                                              There’s a reason why highly skilled programmers think simple, elegant code is something to work towards, and that reason is because more often than not, it works.

                                                                                                              Either way, I absolutely agree with you. And this article has some serious gaping holes.

                                                                                                              1. 1

                                                                                                                Totally fair point! Agreed. :-)