Threads for rele

  1. 4

    My first reaction: this is brilliantly summarized. I admit I’m going to have to step back to offer critical feedback.

    1. 14

      Rich has been railing on types for the last few keynotes, but it looks to me like he’s only tried Haskell and Kotlin and that he hasn’t used them a whole lot, because some of his complaints look like complete strawmen if you have a good understanding and experience with a type system as sophisticated as Haskell’s, and others are better addressed in languages with different type systems than Haskell, such as TypeScript.

      I think he makes lots of good points, I’m just puzzled as to why he’s seemingly ignoring a lot of research in type theory while designing his own type system (clojure.spec), and if he’s not, why he thinks other models don’t work either.

      1. 15

        One nit: spec is a contract system, not a type system. The former is often used to patch up a lack of the latter, but it’s a distinct concept you can do very different things with.

        EDIT: to see how they can diverge, you’re probably better off looking at what Racket does than what Clojure does. Racket is the main “research language” for contracts and does some pretty fun stuff with them.

        1. 4

          It’s all fuzzy to me. They’re both formal specifications. They get overlapped in a lot of ways. Many types people are describing could be pre/post conditions and invariants in contract form for specific data or functions on them. Then, a contract system extended to handle all kinds of things past Boolean will use enough logic to be able to do what advanced type systems do.

          Past Pierce or someone formally defining it, I don’t know as a formal, methods non-expert that contract and type systems in general form are fundamentally that different since they’re used the same in a lot of ways. Interchangeably, it would appear, if each uses equally powerful and/or automated logics.

          1. 14

            It’s fuzzy but there are differences in practice. I’m going to assume we’re using non-FM-level type systems, so no refinement types or dependent types for full proofs, because once you get there all of our intuition about types and contracts breaks down. Also, I’m coming from a contract background, not a type background. So take everything I say about type systems with a grain of salt.

            In general, static types verify a program’s structure, while contracts verify its properties. Like, super roughly, static types are whether a program is sense or nonsense, while contracts are whether its correct or incorrect. Consider how we normally think of tail in Haskell vs, like, Dafny:

            tail :: [a] -> [a]
            method tail(s: seq<T>) returns (o: seq<T>)
            requires s.Len > 0
            ensures s[0] + o = s

            The tradeoff is that verifying structure automatically is a lot easier than verifying semantics. That’s why historically static typing has been compile-time while contracts have been runtime. Often advances in typechecking subsumed use cases for contracts. See, for example, how Eiffel used contracts to ensure “void-free programming” (no nulls), which is subsumed by optionals. However, there are still a lot of places where they don’t overlap, such as in loop invariants, separation logic, (possibly existential contracts?), arguably smart-fuzzing, etc.

            Another overlap is refinement types, but I’d argue that refinement types are “types that act like contracts” versus contracts being “runtime refinement types”, as most successful uses of refinement types came out of research in contracts (like SPARK) and/or are more ‘contracty’ in their formulations.

            1. 3

              Is there anything contacts do that dependent types cannot?

              1. 2

                Fundamentally? Not really, nor vice versa. Both let you say arbitrary things about a function.

                In practice contracts are more popular for industrial work because they so far seem to map better to imperative languages than dependent types do.

                1. 1

                  That makes sense, thanks! I’ve never heard of them. I mean I’ve probably seen people throw the concept around but I never took it for an actual thing

          2. 1

            I see the distinction when we talk about pure values, sum and product types. I wonder if the IO monad for example isn’t kind of more on the contract side of things. Sure it works as a type, type inference algorithms work with it, but the sife-effect thing makes it seem more like a pattern.

          3. 20

            I’m just puzzled as to why he’s seemingly ignoring a lot of research in type theory

            Isn’t that his thing? He’s made proud statements about his disinterest in theory. And it shows. His jubilation about transducers overlooked that they are just a less generic form of ad-hoc polymorphism, invented to abstract over operations on collections.

            1. 1

              wow, thanks for that, never really saw it that way but it totally makes sense. not a regular clojure user, but love lisp, and love the ML family of languages.

              1. 1

                So? Theory is useless without usable and easy implementation

                1. 1

                  So? Theory is useless without usable and easy implementation

                  No. Let me setup a thought experiment to show the flaw in this argument…

                  Let’s say this sequence of events happens over time:

                  1. Theory X is developed. Think of it as general theory
                  2. Theory Y, which builds on top of X, is developed. Think of it as being more specific.
                  3. An implementation of Y happens. Call it imp(Y).

                  By the logic quoted above:

                  • Theory Y is now useful because of imp(Y).
                  • Theory X is not useful because there is not yet any imp(X).

                  Such a scenario can happen when an implementer thinks something like “Theory X is quite general; I’m not sure I even can understand its terminology; I certainly don’t know how to apply it to my work.” However, once Theory Y comes along, it is easier for implementors to see the value, and, voila, you get enough interest to generate imp(Y).

                  However, Y could not have happened without X, so X must be valuable too. This leads to a contradiction: Theory X is both useful and useless.

                  The problem arises out of an overly narrow definition of “useful” (commenter above).

                  In truth, the word “useful” can mean many things in different contexts. One kind of use is implementation (i.e. a library). Another kind of use is to build additional thinking around it. Yes, I’ll say it – theory is useful. It may be common to bash on “theory”, but this is too often an unfair and misattributed attack.

              2. 7

                I don’t see anything of substance in this comment other than “Haskell has a great type system”.

                I just watched the talk. Rich took a lot of time to explain his thoughts carefully, and I’m convinced by many of his points. I’m not convinced by anything in this comment because there’s barely anything there. What are you referring to specifically?

                edit: See my perspective here:

                1. 3

                  That wasn’t my point at all. I agree with what Rich says about Maybes in this talk, but it’s obvious from his bad Haskell examples that he hasn’t spent enough time with the language to justify criticizing its type system so harshly.

                  Also, what he said about representing the idea of a car with information that might or might not be there in different parts of a program might be correct in Haskell’s type system, but in languages with structural subtyping (like TypeScript) or row polymorphism (like Ur/Web) you can easily have a function that takes a car record which may be missing some fields, fills some of them out and returns an object which has a bit more fields than the other one, like Rich described at some point in the talk.

                  I’m interested to see where he’s gonna end up with this, but I don’t think he’s doing himself any favors by ignoring existing research in the same fields he’s thinking about.

                  1. 7

                    But if you say that you need to go to TypeScript to express something, that doesn’t help me as a Haskell user. I don’t start writing a program in a language with one type system and then switch into a language with a different one.

                    Anyway, my point is not to have a debate on types. My point is that I would rather read or watch an opinion backed up by real-world experience.

                    I don’t like the phrase “ignoring existing research”. It sounds too much like “somebody told me this type system was good and I’m repeating it”. Just because someone published a paper on it, doesn’t mean it’s good. Plenty of researchers disagree on types, and admit that there are open problems.

                    There was just one here the other day!


                    I’ve found that the applicability of types is quite domain-specific. Rich Hickey is very clear about what domains he’s talking about. If someone makes general statements about type systems without qualifying what they’re talking about, then I won’t take them very seriously.

                2. 6

                  seemingly ignoring a lot of research in type theory

                  I’ve come to translate this utterance as “it’s not Haskell”. Are there languages that have been hurt by “ignoring type theory research”? Some (Go, for instance) have clearly benefited from it.

                  1. 13

                    I don’t think rich is nearly as ignorant of Haskell’s type system as everyone seems to think. You can understand this stuff and not find it valuable and it seems pretty clear to me that this is the case. He’s obviously a skilled programmer who’s perspective warrants real consideration, people who are enamored with type systems shouldnt be quick to write him off even if they disagree.

                    I don’t like dynamic languages fwiw.

                    1. 3

                      I dont think we can assume anything about what he knows. Even Haskellers here are always learning about its type system or new uses. He spends most of his time in a LISP. It’s safe to assume he knows more LISP benefits than Haskell benefits until we see otherwise in examples he gives.

                      Best thing tl do is probably come up with lot of examples to run by him at various times/places. See what says for/against them.

                      1. 10

                        I guess I would want hear what people think he’s ignorant of because he clearly knows the basics of the type system, sum types, typeclasses, etc. The clojure reducers docs mention requiring associative monoids. I would be extremely surprised if he didn’t know what monads were. I don’t know how far he has to go for people to believe he really doesn’t think it’s worthwhile. I heard edward kmett say he didn’t think dependent types were worth the overhead, saying that the power to weight ratio simply wasn’t there. I believe the same about haskell as a whole. I don’t think it’s insane to believe that about most type systems and I don’t think hickey’s position stems from ignorance.

                        1. 2

                          Good examples supporting he might know the stuff. Now, we just need more detail to further test the claims on each aspect of languge design.

                          1. 3

                            From the discussions I see, it’s pretty clear to me that Rich has a better understanding of static typing and its trade offs than most Haskell fans.

                    2. 11

                      I’d love to hear in a detailed fashion how Go has clearly benefited from “ignoring type theory research”.

                      1. 5

                        Rust dropped GC by following that research. Several languages had race freedom with theirs. A few had contracts or type systems with similar benefits. Go’s developers ignored that to do a simpler, Oberon-2- and C-like language.

                        There were two reasons. dmpk2k already said first, which Rob Pike said, that it was designed for anyone from any background to pick up easily right after Google hired them. Also, simplicity and consistency making it easy for them to immediately go to work on codebases they’ve never seen. This fits both Google’s needs and companies that want developers to be replaceable cogs.

                        The other is that the three developers had to agree on every feature. One came from C. One liked stuff like Oberon-2. I dont recall the other. Their consensus is unlikely to be an Ocaml, Haskell, Rust, Pony, and so on. It was something closer to what they liked and understood well.

                        If anything, I thought at the time they shouldve done something like Julia with a mix of productivity features, high C/Python integration, a usable subset people stick to, and macros for just when needed. Much better. I think a Noogler could probably handle a slighty-more-advanced language than Go. That team wanted otherwise…

                        1. 2

                          I have a hard time with a number of these statements:

                          “Rust dropped GC by following that research”? So did C++ also follow research to “drop GC”? What about “C”? I’ve been plenty of type system conversation related to Rust but nothing that I would attribute directly to “dropping GC”. That seems like a bit of a simplification.

                          Is there documentation that Go developers ignored type research? Has the Go team stated that? Or that they never cared? I’ve seen Rob Pike talk about wanting to appeal to C and C++ programmers but nothing about ignorning type research. I’d be interested in hearing about that being done and what they thought the benefits were.

                          It sounds like you are saying that the benefit is something familiar and approachable. Is that a benefit to the users of a language or to the language itself? Actually I guess that is more like, is the benefit that it made Go approachable and familiar to a broad swath of programmers and that allowed it to gain broad adoption?

                          If yes, is there anything other than anecdotes (which I would tend to believe) to support that assertion?

                          1. 10

                            “That seems like a bit of a simplification.”

                            It was. Topic is enormously complex. Gets worse when you consider I barely knew C++ before I lost my memory. I did learn about memory pools and reference counting from game developers who used C++. I know it keeps getting updated in ways that improve its safety. The folks that understand C++ and Rust keep arguing about how safe C++ is with hardly any argument over Rust since its safety model is baked thoroughly into the language rather than an option in a sea of options. You could say I’m talking about Rust’s ability to be as safe as a GC in most of an apps code without runtime checks on memory accesses.

                            “Is there documentation that Go developers ignored type research? Has the Go team stated that? Or that they never cared?”

                            Like with the Rich Hickey replies, this burden of proof is backwards asking us to prove a negative. If assessing what people knew or did, we should assume nothing until we see evidence in their actions and/or informed opinions that they did these things. Only then do we believe they did. I start by comparing what I’ve read of Go to Common LISP, ML’s, Haskell, Ada/SPARK, Racket/Ometa/Rascal on metaprogramming side, Rust, Julia, Nim, and so on. Go has almost nothing in it compared to these. Looks like a mix of C, Wirth’s stuff, CSP like old stuff in 1970’s-1980’s, and maybe some other things. Not much past the 1980’s. I wasn’t the first to notice either. Article gets point across despite its problems the author apologized for.

                            Now, that’s the hypothesis from observation of Go’s features vs other languages. Lets test it on intent first. What was the goal? Rob Pike tells us here with Moray Taylor having a nicer interpretation. The quote:

                            The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

                            It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.

                            So, they’re intentionally dumbing the language down as much as they can while making it practically useful. They’re doing this so smart people from many backgrounds can pick it up easily and go right to being productive for their new employer. It’s also gotta be C-like for the same reason.

                            Now, let’s look at its prior inspirations. In the FAQ, they tell you the ancestors: “Go is mostly in the C family (basic syntax), with significant input from the Pascal/Modula/Oberon family (declarations, packages), plus some ideas from languages inspired by Tony Hoare’s CSP, such as Newsqueak and Limbo (concurrency).” They then make an unsubstantiated claim, in that section at least, that it’s a new language across the board to make programming better and more fun. In reality, it seems really close to a C-like version of the Oberon-2 experience one developer (can’t recall) wanted to recreate with concurrency and tooling for aiding large projects. I covered the concurrency angle in other comment. You don’t see a lot of advanced or far out stuff here: decades old tech that’s behind current capabilities. LISP’ers, metaprogrammers and REBOL’s might say behind old tech, too. ;)

                            Now, let’s look at execution of these C, Wirth-like, and specific concurrency ideas into practice. I actually can’t find this part. I did stumble upon its in-depth history of design decisions. The thing I’m missing, if it was correct, is a reference to the claim that the three developers had to agree on each feature. If that’s true, it automatically would hold the language back from advanced stuff.

                            In summary, we have a language designed by people who mostly didn’t use cutting-edge work in type systems, employed nothing of the sort, looked like languages from the 1970’s-1980’s, considered them ancestors, is admittedly dumbed-down as much as possible so anyone from any background can use it, and maybe involved consensus from people who didn’t use cutting-edge stuff (or even much cutting-edge at 90’s onward). They actually appear to be detractors to a lot of that stuff if we consider the languages they pushed as reflecting their views on what people should use. Meanwhile, the languages I mentioned above used stuff from 1990’s-2000’s giving them capabilities Go doesn’t have. I think the evidence weighs strongly in favor of that being because designers didn’t look at it, were opposed to it for technical and/or industrial reasons, couldn’t reach a consensus, or some combo.

                            That’s what I think of Go’s history for now. People more knowledgeable feel free to throw any resources I might be missing. It just looks to be a highly-practical, learn/use-quickly, C/Oberon-like language made to improve onboarding and productivity of random developers coming into big companies like Google. Rob Pike even says that was the goal. Seems open and shut to me. I thank the developers of languages like Julia and Nim believing we were smart enough to learn a more modern language, even if we have to subset them for inexperienced people.

                        2. 4

                          It’s easy for non-LtU programmers to pick up, which happens to be the vast majority.

                          1. 3

                            Sorry, that isn’t detailed. Is there evidence that its easy for these programmers to pick up? What does “easy to pick up” mean? To get something to compile? To create error-free programs? “Clearly benefited” is a really loaded term that can mean pretty much anything to anyone. I’m looking for what the stated benefits are for Go. Is the benefit to go that it is “approachable” and “familiar”?

                            There seems to be an idea in your statement then that using any sort of type theory research will inherintly make something hard to pick up. I have a hard time accepting that. I would, without evidence, be willing to accept that many type system ideas (like a number of them in Pony) are hard to pick up, but the idea that you have to ignore type theory research to be easy to pick up is hard for me to accept.

                            Could I create a language that ignores type system theory but using a non-familiar syntax and not be easy to pick up?

                            1. 5

                              I already gave you the quote from Pike saying it was specifically designed for this. Far as the how, I think one of its designers explains it well in those slides. The Guiding Principles section puts simplicity above everything else. Next, a slide says Pascal was a minimalist language designed for teaching non-programmers to code. Oberon was similarly simple. Oberon-2 added methods on records (think simpler OOP). The designer shows Oberon-2 and Go code saying it’s C’s syntax with Oberon-2’s structure. I’ll add benefits like automatic, memory management.

                              Then, the design link said they chose CSP because (a) they understood it enough to implement and (b) it was the easiest thing to implement throughout the language. Like Go itself, it was the simplest option rather than the best along many attributes. There were lots of people who picked up SCOOP (super-easy but with overhead) with probably even more picking up Rust’s method grounded in affine types. Pony is itself doing clever stuff using advances in language. Go language would ignore those since (a) Go designers didn’t know them well from way back when and (b) would’ve been more work than their intent/budget could take.

                              They’re at least consistent about simplicity for easy implementation and learning. I’ll give them that.

                          2. 3

                            It seems to me that Go was clearly designed to have a well-known, well-understood set of primitives, and that design angle translated into not incorporating anything fundamentally new or adventurous (unlike Pony and it’s impressive use of object capabilities). It looked already old at birth, but it feels impressively smooth, in the beginning at least.

                            1. 3

                              I find it hard to believe that CSP and Goroutines were “well-understood set of primitives”. Given the lack of usage of CSP as a mainstream concurrency mechanism, I think that saying that Go incorporates nothing fundamentally new or adventurous is selling it short.

                              1. 5

                                CSP is one of oldest ways people modeled concurrency. I think it was built on Hoare’s monitor concept from years before which Per Brinch Hansen turned into Concurrent Pascal. Built Solo OS with mix of it and regular Pascal. It was also typical in high-assurance to use something like Z or VDM for specifying main system with concurrency done in CSP and/or some temporal logic. Then, SPIN became dominant way to analyze CSP-like stuff automatically with a lot of industrial use for a formal method. Lots of other tools and formalisms existed, though, under banner of process algebras.

                                Outside of verification, the introductory text that taught me about high-performance, parallel computing mentioned CSP as one of basic models of parallel programming. I was experimenting with it in maybe 2000-2001 based on what those HPC/supercomputing texts taught me. It also tied into Agent-Oriented Programming I was looking into then given they were also concurrent, sequential processes distributed across machines and networks. A quick DuckDuckGo shows a summary article on Wikipedia mentions it, too.

                                There were so many courses teaching and folks using it that experts in language design and/or concurrency should’ve noticed it a long time ago trying to improve on it for their languages. Many did, some doing better. Eiffel SCOOP, ML variants like Concurrent ML, Chapel, Clay with Wittie’s extensions, Rust, and Pony are examples. Then you have Go doing something CSP-like (circa 1970’s) in the 2000’s still getting race conditions and stuff. What did they learn? (shrugs) I don’t know…

                                1. 12


                                  I’m going to take the 3 different threads of conversation we have going and try to pull them all together in this one reply. I want to thank you for the time you put into each answer. So much of what appears on Reddit, HN, and elsewhere is throw away short things that often feel lazy or like communication wasn’t really the goal. For a long time, I have appreciated your contributions to because there is a thoughtfulness to them and an attempt to convey information and thinking that is often absent in this medium. Your replies earlier today are no exception.

                                  Language is funny.

                                  You have a very different interpretation of the words “well-understood primitives” than I do. Perhaps it has something to do with anchoring when I was writing my response. I would rephrase my statement this way (and I would still be imprecise):

                                  While CSP has been around for a long time, I don’t that prior to Go, that is was a well known or familiar concurrency model for most programmers. From that, I would say it isn’t “well-understood”. But I’m reading quite a bit, based on context into what “well-understood” means here. I’m taking it to me, “widely understood by a large body of programmers”.

                                  And I think that your response Nick, I think it actually makes me believe that more. The languages you mention aren’t ones that I would consider familiar or mainstream to most programmers.

                                  Language is fun like that. I could be anchoring myself again. I rarely ask questions on or comment. I decided to on this occasion because I was really curious about a number of things from an earlier statement:

                                  “Go has clearly benefited from “ignoring type theory research”.

                                  Some things that came to mind when I read that and I wondered “what does this mean?”

                                  “clearly benefited”

                                  Hmmm, what does benefit mean? Especially in reference to a language. My reading of benefit is that “doing X helped the language designers achieve one or more goals in a way that had acceptable tradeoffs”. However, it was far from clear to me, that is what people meant.

                                  “ignoring type theory research”

                                  ignoring is an interesting term. This could mean many things and I think it has profound implications for the statement. Does ignoring mean ignorance? Does it mean willfully not caring? Or does it mean considered but decided not to use?

                                  I’m familiar with some of the Rob Pike and Go early history comments that you referenced in the other threads. In particular related to the goal of Go being designed for:

                                  The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

                                  It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.

                                  I haven’t found anything though that shows there was a willful disregard of type theory. I wasn’t attempting to get you to prove a negative, more I’m curious. Has the Go team ever said something that would fall under the heading of “type system theory, bah we don’t need it”. Perhaps they have. And if they have, is there anything that shows a benefit from that.

                                  There’s so much that is loaded into those questions though. So, I’m going to make some statements that are possibly open to being misconstrued about what from your responses, I’m hearing.

                                  “Benefit” here means “helped make popular” because Go on its surface, presents a number of familiar concepts for the programmer to work with. There’s no individual primitive that feels novel or new to most programmers except perhaps the concurrency model. However, upon the first approach that concurrency model is fairly straightforward in what it asks the programmer to grasp when first encountering it. Given Go’s stated goals from the quote above. It allows the programmers to feel productive and “build good software”.

                                  Even as I’m writing that though, I start to take issue with a number of the assumptions that are built into the Pike quote. But that is fine. I think most of it comes down to for me what “good software” is and what “simple” is. And those are further loaded words that can radically change the meaning of a comment based on the reader.

                                  So let me try again:

                                  When people say “Go has clearly benefited from “ignoring type theory research” what they are saying is:

                                  Go’s level of popularity is based, in part, on it providing a set of ideas that should be mostly familiar to programmers who have some experience with the Algol family of languages such as C, C++, Python, Ruby etc. We can further refine that to say that from the Algol family of languages that we are really talking about ones that have type systems that make few if any guarantees (like C). That Go put this familiarity as its primary goal and because of that, is popular.

                                  Would you say that is a reasonable summation?

                                  When I asked:

                                  “Is there documentation that Go developers ignored type research? Has the Go team stated that? Or that they never cared?”

                                  I wasn’t asking you for to prove a negative. I was very curious if any such statements existed. I’ve never seen any. I’ve drawn a number of conclusions about Go based mostly on the Rob Pike quote you provided earlier. I was really looking for “has everyone else as well” or do they know things that I don’t know.

                                  It sounds like we are both mostly operating on the same set of information. That’s fine. We can draw conclusions from that. But I feel at least good in now saying that both you and I are inferring things based on what appears to be mostly shared set of knowledge here and not that I am ignorant of statements made by Go team members.

                                  I wasn’t looking for proof. I was looking for information that might help clear up my ignorance in the area. Related to my ignorance.

                                  1. 3

                                    I appreciate that you saw I was trying to put effort into it being productive and civil. Those posts took a while. I appreciate your introspective and kind reply, too. Now, let’s see where we’re at with this.

                                    Yeah, it looks like we were using words with a different meaning. I was focused on well-understood by PLT types that design languages and folks studying parallelism. Rob Pike at the least should be in both categories following that research. Most programmers don’t know about it. You’re right that Go could’ve been first time it went mainstream.

                                    You also made a good point that it’s probably overstating it to say they never considered. I have good evidence they avoided almost all of it. Other designers didn’t. Yet, they may have considered it (how much we don’t know), assessed it against their objectives, and decided against all of it. The simplest approach would be to just ask them in a non-confrontational way. The other possibility is to look at each’s work to see if it showed any indication they were considering or using such techniques in other work. If they were absent, saying they didn’t consider it in their next work would be reasonable. Another angle would be to look at, like with C’s developers, whether they had a personal preference for simpler or barely any typing consistently avoiding developments in type systems. Since that’s lots of work, I’ll leave it at “Unknown” for now.

                                    Regarding its popularity, I’ll start by saying I agree its simple design reusing existing concepts was a huge element of that. It was Wirth’s philosophy to do same thing for educating programmers. Go adopted that philosophy to modern situation. Smart move. I think you shouldn’t underestimate the fact that Google backed it, though.

                                    There were a lot of interesting languages over the decades with all kinds of good tradeoffs. The ones with major, corporate backing and/or on top of advantageous foundations/ecosystems (eg hardware or OS’s) usually became big in a lasting way. That included COBOL on mainframes, C on cheap hardware spreading with UNIX, Java getting there almost entirely through marketing given its technical failures, .NET/C# forced by Microsoft on its huge ecosystem, Apple pushing Swift, and some smaller ones. Notice the language design is all across the board here in complexity, often more complex than existing languages. The ecosystem drivers, esp marketing or dominant companies, are the consistent thread driving at least these languages’ mass adoption.

                                    Now, mighty Google claims they’re backing for their massive ecosystem a new language. It’s also designed by celebrity researchers/programmers, including one many in C community respect. It might also be a factor in whether developers get a six digit job. These are two, major pulls plus a minor one that each in isolation can draw in developers. Two, esp employment, will automatically make a large number of users if they think Google is serious. Both also have ripple effects where other companies will copy what big company is doing to not get left behind. Makes the pull larger.

                                    So, as I think of your question, I have that in the back of my mind. I mean, those effects pull so hard that Google’s language could be a total piece of garbage and still have 50,000-100,000 developers just going for a gold rush. I think that they simplified the design to make it super-easy to learn and maintain existing code just turbocharges that effect. Yes, I think the design and its designers could lead to significant community without Google. I’m just leaning toward it being a major employer with celebrity designers and fanfare causing most of it.

                                    And then those other languages start getting uptake despite advanced features or learning troubles (esp Rust). Shows they Go team could’ve done better on typing using such techniques if they wanted to and/or knew about those techniques. I said that’s unknown. Go might be the best they could do in their background, constraints, goals, or whatever. Good that at least four, different groups made languages to push programming further into the 90’s and 2000’s instead of just 70’s to early 80’s. There’s at least three creating languages closer to C generating a lot of excitement. C++ is also getting updates making it more like Ada. Non-mainstream languages like Ada/SPARK and Pony are still getting uptake even though smaller.

                                    If anything, the choices of systems-type languages is exploding right now with something for everyone. The decisions of Go’s language authors aren’t even worth worrying about since that time can be put into more appropriate tools. I’m still going to point out that Rob Pike quote to people to show they had very, very specific goals which made a language design that may or may not be ideal for a given task. It’s good for perspective. I don’t know designers’ studies, their tradeoffs, and (given alternatives) they barely matter past personal curiosity and PLT history. That also means I’ll remain too willfully ignorant about it to clear up anyone’s ignorance. At least till I see some submissions with them talking about it. :)

                                    1. 2

                                      Thanks for the time you put into this @nickpsecurity.

                                      1. 1

                                        Sure thing. I appreciate you patiently putting time into helping me be more accurate and fair describing Go designers’ work.

                                        1. 2

                                          And thank you, I have a different perspective on Go now than I did before. Or rather, I have a better understanding of other perspectives.

                        3. 4

                          I don’t have a good understanding of type systems. What is it that Rich misses about Haskells Maybe? Does changing the return type of a function from Maybe T to T not mean that you have to change code which uses the return value of that function?

                          1. 26

                            Does changing the return type of a function from Maybe T to T not mean that you have to change code which uses the return value of that function?

                            It does in a way, but I think people sometimes over-estimate the amount of changes that are required. It depends on whether or not really really care about the returned value. Let’s look at a couple of examples:

                            First, let’s look at an example. Let’s say that we had a function that was going to get the first element out of a list, so we start out with something like:

                            getFirstElem :: [a] -> a
                            getFirstElem = head

                            Now, we’ll write a couple of functions that make use of this function. Afterwards, I’ll change my getFirstElem function to return a Maybe a so you can see when, why, and how these specific functions need to change.

                            First, let’s imagine that I have some list of lists, and I’d like to just return a single list that has the first element; for example I might have something like ["foo","bar","baz"] and I want to get back "fbb". I can do this by calling map over my list of lists with my getFirstElem function:

                            getFirsts :: [[a]] -> [a]
                            getFirsts = map getFirstElem

                            Next, say we wanted to get an idea of how many elements we were removing from our list of lists. For example, in our case of ["foo","bar","baz"] -> "fbb", we’re going from a total of 9 elements down to 3, so we’ve eliminated 6 elements. We can write a function to help us figure out how many elements we’ve dropped pretty easily by looking at the sum of the lengths of the lists in the input lists, and the overall length of the output list.

                            countDropped :: [[a]] -> [b] -> Int
                            countDropped a b =
                              let a' = sum $ map length a
                                  b' = length b
                              in a' - b'

                            Finally, we probably want to print out our string, so we’ll use print:

                            printFirsts =
                              let l = ["foo","bar","baz"]
                                  r = getFirsts l
                                  d = countDropped l r
                              in print l >> print r >> print d

                            Later, if we decide that we want to change our program to look at ["foo","","bar","","baz"]. We’ll see our program crashes! Oh no! the problem is that head doesn’t work with an empty list, so we better go and update it. We’ll have it return a Maybe a so that we can capture the case where we actually got an empty list.

                            getFirstElem :: [a] -> Maybe a
                            getFirstElem = listToMaybe

                            Now we’ve changed our program so that the type system will explicitly tell us whether we tried to take the head of an empty list or not- and it won’t crash if we pass one in. So what refactoring do we have to do to our program?

                            Let’s walk back through our functions one-by-one. Our getFirsts function had the type [[a]] -> [a] and we’ll need to change that to [[a]] -> [Maybe a] now. What about the code?

                            If we look at the type of map we’ll see that it has the type: map :: (c -> d) -> [c] -> [d]. Since both [[a]] -> [a] and [[a]] -> [Maybe a] satisfy the constraint [a] -> [b], (in both cases, c ~ [a], in the first case, d ~ a and in the second d ~ Maybe a). In short, we had to fix our type signature, but nothing in our code has to change at all.

                            What about countDropped? Even though our types changed, we don’t have to change anything in countDropped at all! Why? Because countDropped is never looking at any values inside of the list- it only cares about the structure of the lists (in this case, how many elements they have).

                            Finally, we’ll need to update printFirsts. The type signature here doesn’t need to change, but we might want to change the way that we’re printing out our values. Technically we can print a Maybe value, but we’d end up with something like: [Maybe 'f',Nothing,Maybe 'b',Nothing,Maybe 'b'], which isn’t particularly readable. Let’s update it to replace Nothing values with spaces:

                            printFirsts :: IO ()
                            printFirsts =
                              let l = ["foo","","bar","","baz"]
                                  r = map (fromMaybe ' ') $ getFirsts' l
                                  d = countDropped l r
                              in print l >> print r >> print d

                            In short, from this example, you can see that we can refactor our code to change the type, and in most cases the only code that needs to change is code that cares about the value that we’ve changed. In an untyped language you’d expect to still have to change the code that cares about the values you’re passing around, so the only additional changes that we’ve had to do here was a very small update to the type signature (but not the implementation) of one function. In fact, if I’d let the type be inferred (or written a much more general function) I wouldn’t have had to even do that.

                            There’s an impression that the types in Haskell require you to do a lot of extra work when refactoring, but in practice the changes you are making aren’t materially more or different than the ones you’d make in an untyped language- it’s just that the compiler will tell you about the changes you need to make, so you don’t need to find them through unit tests or program crashes.

                            1. 3

                              countDropped should be changed. To what will depend on your specification but as a simple inspection, countDropped ["", "", "", ""] [None, None, None, None] will return -4, which isn’t likely to be what you want.

                              1. 4

                                That’s correct in a manner of speaking, since we’re essentially computing the difference between the number of characters in all of the substrings minutes the length of the printed items. Since [""] = [[]], but is printed " ", we print one extra character (the space) compared to the total length of the string, so a negative “dropped” value is sensible.

                                Of course the entire thing was a completely contrived example I came up with while I was sitting at work trying to get through my morning coffee, and really only served to show “sometimes we don’t need to change the types at all”, so I’m not terribly worried about the semantics of the specification. You’re welcome to propose any other more sensible alternative you’d like.

                                1. -3

                                  That’s correct in a manner of speaking, since …

                                  This is an impressive contortion, on par with corporate legalese, but your post-hoc justification is undermined by the fact that you didn’t know this was the behavior of your function until I pointed it out.

                                  Of course the entire thing was a completely contrived example …

                                  On this, we can agree. You created a function whose definition would still typecheck after the change, without addressing the changed behavior, nor refuting that in the general case, Maybe T is not a supertype of T.

                                  You’re welcome to propose any other more sensible alternative you’d like.

                                  Alternative to what, Maybe? The hour long talk linked here is pretty good. Nullable types are more advantageous, too, like C#’s int?. The point is that if you have a function and call it as f(0) when the function requires its first argument, but later, the requirement is “relaxed”, all the places where you wrote f(0) will still work and behave in exactly the same way.

                                  Getting back to the original question, which was (1) “what is it that Rich Hickey doesn’t understand about types?” and, (2) “does changing the return type from Maybe T to T cause calling code to break?”. The answer to (2) is yes. The answer to (1), given (2), is nothing.

                                  1. 10

                                    I was actually perfectly aware of the behavior, and I didn’t care because it was just a small toy example. I was just trying to show some examples of when and how you need to change code and/or type signatures, not write some amazing production quality code to drop some things from a list. No idea why you’re trying to be such an ass about it.

                                    1. 3

                                      She did not address question (1) at all. You are reading her response to question (2) as implying something about (1) that makes your response needlessly adverse.

                                2. 2

                                  This is a great example. To further reinforce your point, I feel like the one place Haskell really shows it’s strength in these refactors. It’s often a pain to figure out what the correct types should be parts of your programs, but when you know this and make a change, the Haskell compiler becomes this real guiding light when working through a re-factor.

                                3. 10

                                  He explicitly makes the point that “strengthening a promise”, that is from “I might give you a T” to “I’ll definitely give you a T” shouldn’t necessarily be a breaking change, but is in the absence of union types.

                                  1. 2

                                    Half baked thought here that I’m just airing to ask for an opinion on:

                                    Say as an alternative, the producer produces Either (forall a. a) T instead of Maybe T, and the consumer consumes Either x T. Then the producer’s author changes it to make a stronger promise by changing it to produce Either Void T instead.

                                    I think this does what I would want? This change hasn’t broken the consumer because x would match either alternative. The producer has strengthened the promise it makes because now it promises not to produce a Left constructor.

                                    1. 5

                                      When the problem is “I can’t change my mind after I had insufficient forethought”, requiring additional forethought is not a solution.

                                      1. 2

                                        So we’d need a way to automatically rewrite Maybe t to Either (forall a. a) t everywhere - after the fact. ;)

                                4. 2

                                  Likewise, I wonder what he thinks about Rust’s type system to ensure temporal safety without a GC. Is safe, no-GC operation in general or for performance-critical modules desirable for Clojure practitioners? Would they like a compile to native option that integrates that safe, optimized code with the rest of their app? And if not affine types, what’s his solution that doesn’t involve runtime checks that degrade performance?

                                  1. 7

                                    I’d argue that GC is a perfectly fine solution in vast majority of cases. The overhead from advanced GC systems like the one on the JVM is becoming incredibly small. So, the scenarios where you can’t afford GC are niche in my opinion. If you are in such a situation, then types do seem like a reasonable way to approach the problem.

                                    1. 3

                                      I have worked professionally in Clojure but I have never had to make a performance critical application with it. The high performance code I have written has been in C and CUDA. I have been learning Rust in my spare time.

                                      I argue that both Clojure and Rust both have thread safe memory abstractions, but Clojure’s solution has more (theoretical) overhead. This is because while Rust uses ownership and affine types, Clojure uses immutable data structures.

                                      In particular, get/insert/remove for a Rust HashMap is O(1) amortized while Clojure’s corresponding hash-map’s complexity is O(log_32(n)) for those operations.

                                      I haven’t made careful benchmarks to see how this scaling difference plays out in the real world, however.

                                      1. 4

                                        Having used clojure’s various “thread safe memory abstractions” I would say that the overhead is actual not theoretical.

                                  2. 2

                                    Disclaimer: I <3 types a lot, Purescript is lovely and whatnot

                                    I dunno, I kinda disagree about this. Even in the research languages, people are opting for nominal ADTs. Typescript is the exception, not the rule.

                                    His wants in this space almost require “everything is a dictionary/hashmap”, and I don’t think the research in type theory is tackling his complaints (the whole “place-oriented programming” stuff and positional argument difficulties ring extremely true). M…aybe row types, but row types are not easy to use compared to the transparent and simple Typescript model in my opinion.

                                    Row types help o solve issues generated in the ADT universe, but you still have the nominal typing problem which is his other thing.

                                    His last keynote was very agressive and I think people wrote it off because it felt almost ignorant, but I think this keynote is extremely on point once he gets beyond the maybe railing in the intro

                                  1. 1

                                    This is a great article about how to identify false prophets.

                                    There is however a rather pervasive religion that has been unreasonably effective at predicting the future; mathematics and assuming balance / eventual equilibrium / equality when equivalent.

                                    That last bit about the reproducible builds is exactly the kind of admission that leads down the path to finding the “one thing” that actually works, <I said something wrong; personally I believe “patience” may fit>.

                                    Whatever actually works is locally consistent and globally not so.

                                    1. 3

                                      There is however a rather pervasive religion that has been unreasonably effective at predicting the future; mathematics …

                                      I’m not sure if I agree.

                                      1. The scientific method, not mathematics per se, is designed to (iteratively) find causal mechanisms using a particular kind of experimental design (the controlled experiment).

                                      2. That said, there are “non-scientific” mathematical methods that don’t require controlled experiments and still have various degrees of usefulness (i.e. statistical correlation and sometimes predictive power)

                                      … and assuming balance / eventual equilibrium / equality when equivalent.

                                      What do you mean here?

                                      My experience: I was trained as an electrical engineer, which I summarize in this way. The field of engineering, built by understanding physics deeply, allows ‘working’ engineers to do their jobs without understanding the full complexity of the universe. Engineering is founded by identifing operating conditions that allow for good approximations. This allows for things like: approximating systems as being linear and/or assuming equilibrium.

                                      As a corollary, traditional engineers are skeptical of the term “software engineering”.

                                      1. 6

                                        As a corollary, traditional engineers are skeptical of the term “software engineering”.

                                        I found this series of posts by @hwayne a pretty convincing argument in the other direction. It changed my view, in fact; I used to be a bit uncomfortable with the term “software engineering” for the same reasons.

                                        1. 1

                                          What do you mean here?

                                          An example of what I mean would be in the context of newtonian physics, we assume two equivalent things (same shape + weight) to be literally equal in our model.

                                          Another example would be in economics where we assume eventual equilibrium (justified by arbitrage?).

                                          The scientific method is a method for testing how well mathematical models hold up against reality, often the assumptions made rely on some “naturality” that is justified by these eq* concepts.

                                      1. 1

                                        This is a neat way to do this, but I’m not personally a fan. I don’t want to keep the overhead of remembering what’s where, I’d rather have one big rc-file for my shell. I haven’t ever had a need to disable these things either. But things like this are why I love scripting with Bash, and I always learn something.

                                        1. 2

                                          I bet you’d like zsh scripting even more than bash. I read the zsh docs in detail and it offers dozens, if not more, of conveniences that improve my sanity.

                                          1. 1

                                            I’m sure you’re right, and I really want learn zsh scripting more thoroughly. It’s my shell, but I haven’t really taken the time to do more than its bash interop.

                                        1. 5

                                          One thing I’ve noticed in most non-OOP frameworks is that you have a lot of functions that just take in a data structure as their first argument. GTK does this and so does Elixir (and has a |> operator for calling multiple functions on some data). You essentially have a similar data mechanic, but the state is clearly separate. You can then create more functions that do not have side-effects.

                                          The big advantage of this is unit testing. There’s less to mock. You don’t have to get your object in the right state during a setup() call before running your tests. You can pass one state and check the return state. You can also greatly reduce the number of mocks you need.

                                          I still do a lot of OOP and non-OOP and I can see clear advantages and disadvantages to both. It’s all about tradeoffs. Testing is one thing non-OOP seems have some advantages in though.

                                          1. 3

                                            GTK is definitely built on an OOP framework (GObject)

                                            1. 4

                                              Yeah, GUIs are a slam dunk for OOP. The metaphor works outrageously well, and the data model actually does fit an inheritance structure for once.

                                              I’ll always remember my CS 102 class, where we were taught that Square naturally subclasses Rectangle. It still bothers me that I had to set width and height for Square.

                                              1. 8

                                                Are they a slam dunk? React (which is effectively a GUI framework) has basically abandoned oop in favor of functional prop-drilling, and it’s wildly successful.

                                                1. 8

                                                  The existence of another legitimate paradigm doesn’t invalidate the legitimacy of its predecessors.

                                                  1. 4

                                                    I think you and I have a different interpretation of what “slam dunk” means.

                                                    1. 2

                                                      To be clear, I’m mostly referring to the library implementation, not necessarily the paradigm used by application authors. A lot of what I’m talking about is part of the browser layer, namely the implementation and interface of HTML elements. For example, consider HTMLFormElement, which has the following ancestry:

                                                      1. EventTarget
                                                      2. Node
                                                      3. Element
                                                      4. HTMLElement
                                                      5. HTMLFormElement

                                                      Those superclasses contain tons of common behavior necessary to tie together the system. All of that stuff is just as necessary for HTMLInputElement or any other HTML GUI widget. For example all HTML elements support core events like onclick.

                                                      React isn’t responsible for doing any of that. It stands on the shoulders of a huge OOP GUI framework implemented by browsers. And React Native similarly stands on the shoulders of native toolkits, also OOP based.

                                                      1. 2

                                                        That react doesn’t reach further down into the underlying workings of the DOM is simply a matter of convenience, react is not served by rewriting how javascript works, nor is it served by rewriting how, say, android’s Java engine works, but that doesn’t mean one couldn’t continue the prop-drill-ification all the way down into deeper layers (and possibly improve ergonomics, at least). Sibling comment by doug-moen talks about how DOD/ECS system can be a better model for the lower-level stuff than an object-oriented system, in terms of performance.

                                                        I stand by my assertion that it’s not a “slam dunk” (for, at least what I understand to be a “slam dunk”), for the lower levels, too, not just for consumers of GUI systems.

                                                        1. 4

                                                          The GUI components of most games are built with OOP, DOD is used for managing game entities, interaction, and motion. And those game entities are a perfect example of OOP mismatch, where the entity ontology doesn’t match the required data model. Entities in a game have traits like “has velocity” and “affected by gravity” and “collides with player” that don’t have a strict hierarchy.

                                                          GUI components on the other hand have common behavior that’s extremely hierarchical. A Button may provide an “on pressed” interface by consuming the raw mouse down, mouse up, and keypress events from its Widget parent class. A layout container would instead forward mouse events to its child Widgets based on the coordinates of the event, and the sizes of its children. The children are polymorphic subclasses of Widget, and could be Buttons, Inputs, other layout containers, or anything else. Pretty much all GUI widgets specialize their parent’s behavior. React works at a higher level, composing and orchestrating core widgets to build specific things like dialog boxes or chat windows. It’s completely different.

                                                          but that doesn’t mean one couldn’t continue the prop-drill-ification all the way down into deeper layers (and possibly improve ergonomics, at least)

                                                          This would be a complete nightmare. OOP works for GUI libraries because events, geometry, layout, and a zillion other things are 100% common between all elements. Prop drilling massive amounts of literally identical fields would be nothing but boilerplate.

                                                          That kind of near-perfect code and data sharing is extremely rare. Most real world problems have some aspect that doesn’t model nicely with inheritance hierarchies, making OOP a poor fit. That’s what I mean when I say GUIs are a slam dunk for OOP: all the promises about code organization and deduplication hold true when using OOP to implement a GUI library.

                                                        2. 1

                                                          Wouldn’t it also be fair to say that inheritance trees are only one piece of the OOP pie?

                                                  2. 7

                                                    The reason OOP is important for GUIs is that the original GUI, Smalltalk, was written in the original OOP language, Smalltalk. Every GUI toolkit since then (until recently) has been based on OOP. So that’s just the way things are done (historically).

                                                    But consider that Data Oriented Design (cited by the author as the alternative to OOP) was invented by game programmers to get away from the performance problems and maintenance issues caused by OOP. Games have a lot in common with GUIs; they are both mouse- and keyboard- driven graphical user interfaces.

                                                    For insight on why OOP is bad for GUIs (performance, scalability, modifiability, testability), watch this:

                                                    1. 3

                                                      Thanks for this viewpoint. I’ve always had a pet theory that the relative decline of OO is due to the fact that classic, desktop UI (exemplified by programs like Photoshop and Visual Studio) is also in relative decline. But I must admit I know very little about the state of the art nowadays.

                                                    2. 2

                                                      Agreed. Basically the only time I use inheritance is when customising a view or control in UIKit.

                                                      1. 1

                                                        GUIs are a slam dunk for OOP

                                                        I can’t speak to GTK, but the various MVC-flavored UI frameworks I’ve tried over the years were hardly a slam dunk on a scale beyond roughly three to five screens. The idiomatic way of managing state in MVC is either a) synchronizing multiple local states, or b) sharing globally mutable state through services. Option A does not scale. Option B becomes a debugging problem unless your services use getters and setters for everything so you can set breakpoints to figure out what’s mutating what. Even when you’re working in an MVC codebase where everyone’s agreed to use thin controllers and thick services with lots of getters and setters, race conditions and other more garden-variety mutation conflicts abound. I’ve noticed that these are the kinds of footguns that are especially prevalent in OOP and are virtually non-existent in Elm and other decidedly non-OOP state management architectures inspired by it.

                                                    3. 3

                                                      Separate state:

                                                      I think we’re on to something. State is inherently dangerous, and so are implicit dependencies. Minimizing these is the name of the game for making predictable, testable and ultimately dependable software.

                                                      OOP is good at hiding things – an actually appropriate tool to enforce correct use of an object. But hiding the bad things – state and object references – does not solve the problem that they exist. On the contrary: The paradigm’s tendency to encourage them is a bad trait. Object references are better passed down the call hierarchy. Too many arguments is no real problem, and is trivially solvable if perceived to be, whereas too few is, even often.

                                                      Unit testing:

                                                      Absolutely. State is input, and unit testing a piece of logic necessitates controlling all its inputs. As soon as you apply OOP and make some of that private, it becomes untestable. And that is just half the reason; the other being the need to mock dependencies, as you also mentioned.

                                                      1. 2

                                                        State is bad in its own right

                                                        What does this mean? Can you explain it to someone who is maybe a bit behind the curve with regard to software paradigms? What if I need to track the state of something? Like if I am making a video game, say real time strategy. The entire program and it’s reason for existing is to track and manipulate the state of the game world and the locations of the units in it. If state is bad in its own right then there must be some way to implement a traditional RTS with no state. But if it has no state then it is not a traditional RTS…

                                                        I hope you understand my confusion.

                                                        1. 5

                                                          I wouldn’t say state is “bad in its own right”, but state is equivalent to a system changing in time (if it didn’t, there couldn’t be state!), and dynamic systems have a whole host of complications that static systems don’t. Systems are easier to reason about when there’s less dynamism, which means reducing state mutations to “essential” changes, which also means reducing state overall. That’s easily confused for “state is bad”.

                                                          I should probably write a blog post about this or something

                                                          1. 2

                                                            I was just inspecific. Let’s say dangerous.

                                                            Of course, state is not generally avoidable. Your state tracker is a good example of something with a well defined minimum amount of state. I did say it should be minimized, and I mean that.

                                                            As for why state is dangerous, it makes software behave differently for the same inputs (unless you count the state as input, which I argued it really is). Ask any FP person about impure functions…

                                                          2. 1

                                                            Object references are better passed down the call hierarchy.

                                                            Would you elaborate please? Perhaps with an example?

                                                          3. 2

                                                            There’s not much difference between i.e button_text(button, text) and button.text(text) other than where they’re declared. What matters more is that the values aren’t mutated, but returned anew. This is the whole Elixir |> operator and the “stream-like” foo().bar() one can do.

                                                            1. 2

                                                              I think this is the way to go in general, especially when modeling real world systems. When I did robotics work the idea of avoiding side effects was useless since the entire point of the program is to move things in the real world. It makes much more sense to have a small class Motor with some tiny functions like setSpeed etc., and pass those class instances to functions that do work with the physical motors. This way you don’t have to refactor Motor whenever you want a helper function to e.g. check if the motor is in reverse or not.

                                                              Note that Motor wouldn’t be a pure data structure, it would still be a class, but the idea is to treat Motor more like a dumb API that bridges hardware to software, and to write the actual business logic inside functions.

                                                            1. 1

                                                              Any informed guesses as to what the application is? Mysterious!

                                                              1. 7

                                                                A text editor is a central tool in my workflow; almost all my work goes through it. (Same for web browsers.) I would find it completely unreasonable to use a proprietary tool for such a core tool/need, especially given the rather good quality of open source alternatives. Evidently other people disagree, and it’s completely fine, but I am constantly surprised that there is a large enough pool to make “proprietary text editor” a sustainable business.

                                                                (Maybe there is a failure among contributors to open source editors to find the right way to commercialize them and make them feel “aww” to the audience that likes to pay for slick software.)

                                                                1. 15

                                                                  Whether a tool is proprietary or open source is an abstract property that’s totally unrelated to its user experience.

                                                                  1. 8

                                                                    that’s totally unrelated to its user experience.

                                                                    I would consider having the right to read, modify and share the changes I make to an editor a core part of the user experience. I’ve fixed bugs both for myself and for friends in the text editor I currently use, not having the right to do that would certainly sour my experience.

                                                                    1. 4

                                                                      I would consider having the right to read, modify and share the changes I make to an editor a core part of the user experience.

                                                                      That’s fine, but it’s a position that’s shared by statistically zero other people.

                                                                      1. 2

                                                                        That’s fine, but it’s a position that’s shared by statistically zero other people.

                                                                        If your population is the entirety of people who use software, I do not doubt that. If your population is constrained to people using text editors to write programs, I’d want a link to a study before believing you :).

                                                                        1. 1

                                                                          Ehh, fair :p

                                                                      2. 4

                                                                        I would consider having the right to read, modify and share the changes I make to an editor a core part of the user experience.

                                                                        I think that’s the key difference. I’ve literally never even looked at the source code for the vast majority of tools I use. They do what I need them to do, so I have no motivation to change them. I use (and pay for) JetBrains IDEs (which are proprietary) partly because I’ve never even encountered a meaningful (to me) bug or problem with any of them. That being said, FOSS editors provide competition that improves the quality of proprietary editors. So if that’s your cup of tea, then that’s great in my book!

                                                                      3. 2

                                                                        Saying this doesn’t make it true. In practice, some open tools have better user experiences; these are not always coincidental or unrelated to the development model.

                                                                        1. 12

                                                                          Open source GUI tools also can often have innate challenges with UX due to a “too many cooks” effect — there have been many articles written about this, with titles like “why open source usability tends to suck”. I can’t speak for all tools, but in my experience I’ve found proprietary ones to have much better UX than open source ones.

                                                                          (My background is working at Apple from 1991-2007. I’ve worked with gifted UI designers who were passionate about getting things right. It could be really painful as the engineer who had to make all those changes and hone details, but I think the results were worth it. Of course sometimes this goes wrong and features get dropped or too much time gets spent on questionable eye candy, but in general I think it’s the way to go for really good UX.)

                                                                          1. 3

                                                                            Yes, the “too many cooks” effect often happens. I see what you mean based on your experience.

                                                                            I’m speaking more generally, in the hopes of highlighting some design options software developers might be less aware of. To that end, I would like to make two distinctions:

                                                                            First, I want to point out that “user experience” takes many forms. In the case of a text editor, the “primary” experience is the person doing the text editing. But there are also others; e.g. the experience for the extension/plugin designer. It is often said that committees don’t design UIs well, but on the other hand, it can be very valuable to have a small army of people to listen to suggestions, triage them, document rough spots, and ease user pain.

                                                                            Second, I distinguish between (a) code licensing and availability (e.g. open source code) and (b) the governance model. My hypothesis is that the governance model is a larger driving factor when it comes to user experience.

                                                                            This would be an interesting area to study empirically. I personally would enjoy speaking with large numbers of open source contributors to see how they feel about their efforts and the results.

                                                                      4. 10

                                                                        For those who don’t intend to spend cycles on editing the tool itself and just want to get the best thing and use it, their personal definition of “best” will lead them from one tool to another over the years. For such a central piece of workflow, it can be easy to justify some investment of money and/or learning time every now and then.

                                                                        If I recall correctly, the first version of Sublime introduced the minimap UI feature we’ve since seen in Atom and VS Code. It was very fast for a graphical app, especially compared to its then competitor TextMate. Both TextMate and Sublime offered scripting in major languages of their day, Ruby and Python respectively.

                                                                        Sitting back and observing, you can see these editors maybe trying to do too much of the job themselves, repeating work they could have shared, not standing the test of time. But to a serial app-of-the-moment user, that’s just the way it goes.

                                                                        1. 2

                                                                          This here is why we can’t have nice things :(

                                                                          1. 1

                                                                            I’m not familiar with any good open source text editors which weren’t formerly commercial — could you name any that I’ve been missing?

                                                                            1. 2

                                                                              Some examples: emacs, vim, neovim, kakoune, vis, …

                                                                              1. 0

                                                                                That’s the reply I expected, and I leave the interpretation to the reader.

                                                                          1. 5

                                                                            I think clarity of communication is one of the most underrated skills as a developer. If the ratio of reading code to writing code is 10:1 then the ratio of talking about code to writing code must be 100:1

                                                                            So, barring overtime, a truly senior developer must average no more than 24 minutes a week coding? Possible, for some people who have the title “architect”, but I doubt it’s true of that many developers. I hope that if I ever reach that point, it’s because my title is manager/consultant/whatever else.

                                                                            1. 3

                                                                              I interpret these ratios as applying to time over the life of code, possibly including many people.

                                                                              Also, I am not aware of empirical studies that justify the stated ratios. I interpret them mostly as placeholders used to make a (useful) point.

                                                                              1. 2

                                                                                I definitely know multiple people for whom this is true.

                                                                                I hope to avoid such a fate myself but it absolutely happens.

                                                                                1. 2

                                                                                  The majority of my time is doing operational stuff nowadays, and I frequently read code but am not an “official” developer on any of the projects whose code I’m reading. The ratio of loc read / loc written is > 10 for me for many projects.

                                                                                1. 29

                                                                                  You shouldn’t be having visceral reactions to peoples’ coding mistakes anyway.

                                                                                  No. Emotions are part of how humans work. Of course, these emotions can lead to various kinds of communication, and in a team setting choosing kind and useful communication is important.

                                                                                  I would prefer the author say “Your code review need not contain raw emotional language.”

                                                                                  P.S. The word should is a minefield in writing.

                                                                                  1. 5

                                                                                    Agreed. And it’s not just mistakes — I remember (almost 20 years ago) being really steamed by a coworker’s commit that added a new feature by spicing a bunch of awful kludges into clean code I’d written. It felt like an insult, like sabotage. I went next door and started yelling at him. Not one of my finest moments.

                                                                                    1. 3

                                                                                      At least the awkward memory will keep you from doing the same in the future, and as long as he didn’t give up and go to law school there’s probably no long-term harm ;-)

                                                                                    2. 3

                                                                                      I would prefer the author say “Your code review need not contain raw emotional language.”

                                                                                      Outside of obvious emotive words, what makes a statement “raw emotional language”?

                                                                                      Whowhich particular group of people (amidst an international community of tech people, where emotional appraisal varies among cultures) – gets to objectively qualify it as so?

                                                                                      1. 2

                                                                                        Who … gets to objectively qualify it as [“raw emotional language”]?

                                                                                        You added “objective” to this question. I would not expect such judgments to be objective.

                                                                                        One possible rephrasing of the question is “Who gets to decide if there is raw emotional language?”. Still, that phrasing is limiting, because the question may imply:

                                                                                        1. there is (a) one person or group…
                                                                                        2. … making (b) “the decision”

                                                                                        However, there doesn’t have to be one person or group acting. Also, there doesn’t need to be one decision made. There is more flexibility than that.

                                                                                        Here is a better phrasing of a set of questions: “How would this suggestion (to avoid raw emotional language) play out? Would it be a guideline? Would it be enforced? If so, how?”. Rather than write at length, I’ll just say this becomes a decision for teams to figure out; i.e. managers, human resources, and employees.

                                                                                        1. 1

                                                                                          Your better phrasing still doesn’t address the question of what makes something (such as a statement in a code review) “raw emotional language”.

                                                                                          In a diverse team comprised of people from multiple backgrounds across the planet, many will have differing definitions given the cultural differences in emotional appraisals (especially of language), thus there is no globally uniform notion as “raw emotional language” (beyond emotive words) that everyone will sincerely agree upon … and so ultimately – if one were to enforce, be it as a guideline or a hard rule, this nebulous idea at all (aka. “play out”) – it would have to come down to whichever person/group (usually in authority) gets to choose what is/ what is not considered “raw emotional language” (at the expense of going against a subset of their employees).

                                                                                          1. 1

                                                                                            Overall, I think you are losing essential context here. Remember the context: my feedback is offered at a high level with regards to the original blog post. Please read it in this context. Nothing there is perfect, and there are no claims that enforcement should be harsh or rigid. The post does not suggest these guidelines have to be imposed.

                                                                                            In a diverse team comprised of people from multiple backgrounds across the planet, many will have differing definitions given the cultural differences in emotional appraisals (especially of language), thus there is no globally uniform notion as “raw emotional language” (beyond emotive words) that everyone will sincerely agree upon.

                                                                                            You’re making a false dichotomy here. There is likely to be significant common ground.

                                                                                            In areas where there may be differences of experience or opinion, having these kinds of discussion will be valuable. It is very useful for a team to be aware of how their language affects each other. It can help build common understanding and some shared norms.

                                                                                            Yes, even after these discussions, some areas of disagreement may remain – such is the nature of humanity. Having such differences is not a convincing justification for throwing out an imperfect goal altogether.

                                                                                            this nebulous idea at all (aka. “play out”) – it would have to come down to whichever person/group (usually in authority) gets to choose what is/ what is not considered “raw emotional language” (at the expense of going against a subset of their employees).

                                                                                            It sounds to me like you are asking for the impossible – a completely unambiguous definition, applicable across all regions on earth, where all employees sincerely agree at a particular time.* I think it would be helpful if you accept that this is not going to happen perfectly, and this is ok. However, it is still better to strive to not include raw emotional language in a code review. Some imperfections in figuring this out do not justify throwing out the goal of being calm and rational in a code review.

                                                                                            * Remember that people can adapt and change.

                                                                                            1. 1

                                                                                              I do understand that you are giving a high level and general view … however my comment is primarily in response to a very specific code review criterion proposed (be it prescribed as a guideline or imposed as a hard/ rigid rule), viz:

                                                                                              Your code review need not contain raw emotional language.

                                                                                              which you also repeat but in a different form as,

                                                                                              it is still better to strive to not include raw emotional language in a code review

                                                                                              Hence my as yet unanswered query of just what would constitute this “raw emotional language” (beyond emotive words).

                                                                                              Now if, as you say, there is likely to be “significant common ground” in regards to emotional appraisal of statements in code reviews among a diverse team comprised of people from multiple backgrounds across the planet – such as from the Americas, Europe, Africa, Asia, Russia, Australia, etc – then surely it would be straightforward to directly answer that as yet answered query?

                                                                                              It sounds to me like you are asking for the impossible – a completely unambiguous definition, applicable across all regions on earth, where all employees sincerely agree at a particular time.

                                                                                              Which is why I say that if one were to prescribe this as a guideline or impose it as hard rule – it would ultimately have to come down to whichever person/group (usually in authority*) gets to choose what is/ what is not considered “raw emotional language” (at the expense of going against the rest). However if it be as loose and time-varying in meaning as you say it is, then nobody nowhere at no point in time will have any idea of what “raw emotional language” is, thus making the whole guideline/ rule null and void to begin with.

                                                                                              * I use this word in its sociological meaning (and regardless of organizational hierarchies).

                                                                                              1. 1

                                                                                                However if it be as loose and time-varying in meaning as you say it is…

                                                                                                You are misrepresenting what I wrote.

                                                                                                … then nobody nowhere at no point in time will have any idea of what “raw emotional language” is, thus making the whole guideline/ rule null and void to begin with.


                                                                                                In general, you sound uncomfortable with any principle that isn’t perfectly clear and agreed to by all people in a team. Fair?

                                                                                                Also, it sounds like you want me to elaborate on what “raw emotional language” means for a diverse team of people across continents. My response is simple:

                                                                                                1. My argument does not hinge on my ability to do that in general (for some arbitrary team I’ve never interacted with).

                                                                                                2. Instead, I believe a (mostly) reasonable group of people can figure this out.

                                                                                                3. Some complexity and disagreement is to be expected when people are involved. This is ok. It is better to have a broadly useful guideline, even if imperfect. Its imperfection does not render it “null and void”. Rather, it means that humans have to figure things out.

                                                                                                It is important for teams to socialize some norms and figure out ways to encourage/enforce them.* Yes, all other things equal, clear norms are better than vague norms. That said, the presence of disagreement is not a sign that the norms are failing. Rather, it is a sign that people have different interests and are finding ways to work together.

                                                                                                * Yes, there is a spectrum. Some teams may prefer more norms, and some may prefer fewer. I’m not attempting to specify what is “correct” for every team.

                                                                                                1. 1

                                                                                                  It sounds to me like you are asking for the impossible – a completely unambiguous definition, applicable across all regions on earth, where all employees sincerely agree at a particular time (Remember that people can adapt and change)

                                                                                                  However if it be as loose and time-varying in meaning as you say it is…

                                                                                                  You are misrepresenting what I wrote.

                                                                                                  Your previous comment (quoted above) implies that the definition of “raw emotional language” is not unambiguous (hence “loose in meaning”), and that its meaning can change over time as people can adapt and change over time (hence time-varying).

                                                                                                  … then nobody nowhere at no point in time will have any idea of what “raw emotional language” is, thus making the whole guideline/ rule null and void to begin with.


                                                                                                  So on what basis would you say that a new member of the team, half way across the world, while doing their code review (and feeling good or neutral whilst doing so), appraise what they are about to write as “raw emotional language” or not?

                                                                                                  In general, you sound uncomfortable with any principle that isn’t perfectly clear and agreed to by all people in a team.

                                                                                                  Not any principle, but a principle that uses an invented phrase with no commonly agreed upon meaning.

                                                                                                  Now I understand the intent behind such a principle (to facilitate a friendly environment for all) - however without commonly agreed upon meaning, this sort of guideline is ripe for abuse, depending who holds the power in a team. I actually agree with you that “raw emotional language” cannot be precisely defined (it is mostly a subjective thing; varies between cultures; and has no strong association with the actual emotion expressed and spread as vibes), which is why I say that if one were to prescribe this as a guideline or impose it as hard rule – it would ultimately have to come down to whichever person/group (usually in authority) gets to choose, at whatever point in time, what is/ what is not considered “raw emotional language” (at the expense of going against the rest).

                                                                                                  There are far better ways to approach this issue than imposing introjective overhead on globally diverse team members.

                                                                                                  1. 1

                                                                                                    I’ll put aside the misrepresentation issue. I’ll just call it a misunderstanding.

                                                                                                    however without commonly agreed upon meaning, this sort of guideline is ripe for abuse

                                                                                                    No, in general, one should not assume an imperfect norm is ripe for abuse. This is cherry picking one possible outcome. Another possible outcome is that a somewhat flexible norm is more accommodating. Simply put, it depends.

                                                                                                    But, yes, a group should figure out what it’s norms are over time. This happens all the time.

                                                                                                    You see to have a rather pessimistic view of this kind of situation. You see to accentuate only the potential downsides.

                                                                                                    But, of course, groups figure out norms regularly. Often with overall success.

                                                                                                    Yes, some people in power abuse rules to their advantage. This is often a function of their power imbalance. In my view, ethically challenged people in power don’t ‘need’ a somewhat ambiguous norm to abuse their power. They can find any number of ways to do it.

                                                                                                    Some people are pessimistic about things and that’s fine. But please don’t mistake that pessimism for fact. Consider taking a broader view of pros and cons.

                                                                                                    There are far better ways to approach this issue…

                                                                                                    Please define the issue and the problem as you see it. Then please share some of the better ways you see.

                                                                                                    1. 1

                                                                                                      You see to have a rather pessimistic view of this kind of situation. You see to accentuate only the potential downsides.

                                                                                                      I’m actually quite optimistic about code review communication, and have no trouble with them. The downside is only when you deviate from what demonstrably works. I have not seen any demonstrable evidence that “having visceral reactions to peoples’ coding mistakes” for instance (which is what prompted this whole comment thread) is minimized collectively in a diverse team spanning the globe by institutionalizing vague behavioral guidelines such as not to use “raw emotional language”.

                                                                                                      Please define the issue and the problem as you see it.

                                                                                                      The issue is conflict (thus an absence of friendly ambiance), part of which is “having visceral reactions to peoples’ coding mistakes”.

                                                                                                      Then please share some of the better ways you see.

                                                                                                      If A is having a “visceral reaction” to B’s statement, and if it is not clear that B is feeling malicious (either peeved or angry) - then it is A’s responsibility to try to better understand what’s happening. Now I disagree with the post that A “shouldn’t be having” these reactions (inasmuch as affect is often an automatic response). A doesn’t have total control over their feeling patterns (nobody does), but what they can do is communicate with B as a fellow human being to clarify their intent/stance so that the chances of these “visceral reactions” are minimized. The submitted post also segues to it in another roadblock context: “After dozens of contrasting PR comments and proposed solutions, it should be clear that online communication has become unproductive for the issue at hand. Send a meeting hit to involved members to discuss the issue offline.

                                                                                                      Besides, one can adjust their “language” all day along, and yet malice (either peeved or angry) will seep through it anyway,[1] causing “visceral reactions” on their team members (this is what the sixties’ term “vibes” refers to). It is better to establish a culture of communication and understanding from the get go.

                                                                                                      [1]: For instance

                                                                                                      The leadership style in Elm is extremely aggressive and authoritarian.

                                                                                                      By that I do not mean impolite or rude. It is almost always very civil. But still ultimately aggressive and controlling. — Luke Plant

                                                                                                      Or, for another instance:

                                                                                                      … once enough people are piling on to complain or tell you what’s wrong with what you did, you’re going to feel attacked - even if every single comment is worded politely and respectfully. — SO


                                                                                                      If only I could have read this years ago, before I had the misfortune of working at NoRedInk. The team shows a bewildering mix of cargo-cult inclusiveness coupled with inability to consider that anyone could be different from them in any way that matters. I’ve never before or since met a group where a mentor would advise someone to “show more curiosity” by asking fewer questions!

                                                                                                      [I was] fired halfway through the period for “engaging in conflict” which I can only speculate referred to a bizarre conversation on company Slack about whether or not it made sense to add a cache. — former employee:

                                                                                                      1. 1

                                                                                                        Ok, now that you’ve shared what you think is a better alternative, I understand your POV better. From my POV, what you write in the second half of your comment makes sense.

                                                                                                        It still seems to me that you were not understanding what I was trying to get across. So, let me clarify something…

                                                                                                        I have not seen any demonstrable evidence that “having visceral reactions to peoples’ coding mistakes” for instance (which is what prompted this whole comment thread) is minimized collectively in a diverse team spanning the globe by institutionalizing vague behavioral guidelines such as not to use “raw emotional language”.

                                                                                                        Ah ha!… I may now see why this conversation has felt so murky (i.e. I could not figure out what was bothering you).

                                                                                                        Let’s clear this up – I didn’t say that “having visceral reactions to people’s coding mistakes” is minimized by having a guideline such as avoiding “raw emotional language”. (You seem to have made a connection between these ideas that I did not say or intend.)

                                                                                                        Instead, my argument goes like this (in context of a code review);

                                                                                                        1. Humans naturally sometime have visceral reactions

                                                                                                        2. This is ok – but take enough time to pause and reflect before writing a response.

                                                                                                        3. When you do respond, it is a good idea not to use raw emotional language.

                                                                                                        Hopefully this clears it up.

                                                                                                2. 1


                                                                                                  1. 2


                                                                                                    What is it exactly that you are asking here?

                                                                                      1. 26

                                                                                        Calling reviewers’ behavior “toxic behavior” seems pretty toxic itself. It immediately puts it in an us-vs-them hostile framing. If “toxic” is removed from the title, it would be less likely to rile people up. The “unhelpful” framing is better, but still violates the guideline against passing opinion off as fact. How about “Review behaviors I think are counterproductive”?

                                                                                        1. 7

                                                                                          I think “toxic” is a pretty reasonable descriptor in this context. Behaviors which are unhelpful, counterproductive, adversarial, and have a net negative effect on culture and trust are IMO bad enough to be classified as “toxic”, especially since they have a tendency to spread around unchecked.

                                                                                          1. 4

                                                                                            Real-world example of this in a general context (not just code reviews).

                                                                                            1. 3

                                                                                              Much like “problematic,” the word “toxic” seems to have become a signifier of a certain kind of holier-than-thou preaching, and, well…. problematic.

                                                                                              1. 1

                                                                                                Yes, the word “toxic” can be misused. It can be used to bash people over the head, overgeneralize, and proclaim one’s self-importance, none of which tend to be useful.

                                                                                                Still, I think there is a useful core to the word: calling attention to individual behaviors that might be narrowly defensible (e.g. technically correct) while also being harmful to a group.

                                                                                                1. 2

                                                                                                  I would agree it’s widely misused where “harmful” would do (but that typically requires being willing & able to enunciate the specific harm, whereas “toxic” tends - for whatever reason - to get a pass on that front).

                                                                                              2. 2

                                                                                                Fair enough. Whatever we choose – “toxic” or “unhelpful” – these words tend to imply a value judgment about what is important to a group.

                                                                                                It immediately puts it in an us-vs-them hostile framing.

                                                                                                Well said. It depends on it a value is shared between two people:

                                                                                                • On one hand, if two people share a value, pointing out a value misalignment may be useful. The other person might think “I value X, and I didn’t mean to take an action that compromised it.” and be willing to discuss and/or change behavior.

                                                                                                • On the other hand, if two people disagree on a value (or its relative importance), calling out another person for failing to live up to a value often starts a conversation on the wrong foot.*

                                                                                                * In my view, it takes a certain patience and skill to be insulted or judged by another person, and calmly understand the other person’s motivations without being bothered. There are great opportunities to turn a situation around. Hostile people often are surprised by people that engage without cowering or yelling back.

                                                                                              1. 2

                                                                                                The software world is full of gordon ramseys and ramsey is a mirco managing fraud.

                                                                                                1. 3

                                                                                                  I don’t follow the connection between your comment and the post. Would you please explain?

                                                                                                  1. 4

                                                                                                    Sure. Have you seen kitchen nightmares ? Toxic reviewers are like that.

                                                                                                1. 5

                                                                                                  If you notice someone being unhelpful during code reviews, consider letting them know (if you feel safe in your role/company doing so) and be direct.

                                                                                                  My experience : I’ve dealt this with, and it was difficult. The abrasive person had more seniority (based on time served at the organization, not based on experience).

                                                                                                  1. 28

                                                                                                    As someone who wants Rust to succeed and thus be well funded but at the same time Facebook to be gone from this planet I find myself in a minority expressing concern about this. I find it weird that there’s very little objection to this from either the community or the foundation. The general consensus is “it’s free money”, “they’re doing great with open-source”, “who else should pay for this?” but I rarely see people questioning where this money comes from. Not to mention the concern that they could always threaten to remove the funding if x, y or z doesn’t happen.

                                                                                                    1. 10

                                                                                                      Are there open source projects Facebook has become a part of that went downhill as a result of them? (I get your point, I was just curious if there was a bad track record of their interaction with the open source community…)

                                                                                                      1. 2

                                                                                                        Not that I know of.

                                                                                                      2. 10

                                                                                                        When the founding members are Google, Huawei, AWS, Microsoft, and Mozilla I don’t know if there’s much point complaining that Facebook is joining in.

                                                                                                        Personally, I think it’s probably one of the better ways for these companies to spend their money, and I don’t have any strong feelings about Rust one way or the other.

                                                                                                        1. 2

                                                                                                          I have about as much of a problem with Facebook as I do with every single other company on that list (including Mozilla itself). That is to say, they all do things I disapprove of, and there’s nothing particularly special about the things Facebook does that I disapprove of.

                                                                                                        2. 6

                                                                                                          First off, the funding is probably a rounding error in FB’s finances (and is almost certainly written off as charitable).

                                                                                                          Second, sneakily enforcing FB’s will through subtle arm-twisting of the Rust Foundation is incredibly inefficient. This is a company that can literally decide a country’s election, should it wish to do so.

                                                                                                          Third, Freedom Zero. As long as an organization follows the license and the code of conduct (if applicable) it can be as “evil” as it wants.

                                                                                                          Frankly, FB hate is probably a small minority voice. If you’d ask the stereotypical person on the street, they’d probably rate FB as a very trusted company/brand, at the level of (say) Sony.

                                                                                                          1. 5

                                                                                                            Third, Freedom Zero. As long as an organization follows the license and the code of conduct (if applicable) it can be as “evil” as it wants.

                                                                                                            Is this meant to be a convincing argument? Shouldn’t the last twenty years have put the myth of moral compartmentalization to rest?

                                                                                                            Aside from that, this is not actually responsive to the concern it’s ostensibly addressing. “Hey, it’s a free country, they can do whatever they want,” is not a reasonable or helpful reply to, “Facebook’s involvement makes me uncomfortable for many obvious reasons.”

                                                                                                            1. 2

                                                                                                              Is this meant to be a convincing argument? Shouldn’t the last twenty years have put the myth of moral compartmentalization to rest?

                                                                                                              It was the devil’s bargain the Rust project signed when they chose a license.

                                                                                                              1. 1

                                                                                                                I don’t think that picking a license that allows corporations to use, fork, contribute to etc your work requires you to put them on your foundation.

                                                                                                                Though, given the list of founders, I don’t think you can get much worse by adding FB. And I’m struggling to imagine how Facebook’s badness could influence Rust in a negative way; I don’t think they’re trying to pull some weird ‘sabotage Rust from the inside because ???’ move.

                                                                                                              2. 2

                                                                                                                Aside from that, this is not actually responsive to the concern it’s ostensibly addressing. “Hey, it’s a free country, they can do whatever they want,” is not a reasonable or helpful reply to, “Facebook’s involvement makes me uncomfortable for many obvious reasons.”

                                                                                                                I think is responsive, and the important point, to my eye, is that evil corporation X is benefiting from Rust already. Because it’s released under a license that upholds freedom zero.

                                                                                                                If there’s discomfort, I think it should come from the fact that this community project is helping to further the agenda of a corporation that you consider evil.

                                                                                                                The fact that they’re now participating in the funding of the project in addition to benefiting from its output doesn’t alter my level of discomfort. The bad thing is that they were already enjoying the benefits.

                                                                                                                When you release software under a license that lets it be used for any purpose, that discomfort is a sunk cost IMO. Contributions that benefit the entire community seem like they should offset that.

                                                                                                                I don’t see how compartmentalization comes into play here.

                                                                                                              3. 2

                                                                                                                Third, Freedom Zero. As long as an organization follows the license and the code of conduct (if applicable) it can be as “evil” as it wants.

                                                                                                                I don’t see the connection. From The Free Software Definition on Wikipedia…

                                                                                                                Finally, another freedom was added, to explicitly say that users should be able to run the program. The existing freedoms were already numbered one to three, but this freedom should come before the others, so it was added as “freedom zero”.

                                                                                                                How is the argument “As long as an organization follows the license and the code of conduct (if applicable) it can be as “evil” as it wants.” related to Freedom Zero?

                                                                                                                My take: it isn’t.

                                                                                                                I think the argument above is making a different claim. The argument above suggests as long as an organization is complying with legal requirements, no other considerations matter. This, of course, is not true. Particularly with the Rust Foundation, they are free to have additional criteria. It is also in their interest to do so.

                                                                                                                1. 1

                                                                                                                  I think I see where you’re coming from.

                                                                                                                  You’re not trying to prevent FB from using Rust or the tooling around it. You’d prefer the Rust Foundation to not accept funding from FB, under the assumption that the reputational hit from doing so would outweigh the monetary and other benefits deriving from FB’s support.

                                                                                                                  I agree, that has nothing to do with Freedom Zero.

                                                                                                                  1. 2

                                                                                                                    Not exactly. I distinguish between Rust’s open source license and the Rust community’s governance model. I have confidence that the Rust Foundation is setup in a way that reduces undue influence from contributing organizations. Putting aside its societal impacts, Facebook has many well-meaning individuals and does a lot of good engineering work. I think FB’s contributions and support will likely be a net positive.

                                                                                                                2. 2

                                                                                                                  Rust Foundation is a 501(c)(6) business interest group, not a charitable foundation. To the extent that FB can write off tax against its donations that would be as a business expense and not as a charitable donation.

                                                                                                                  (Almost every “we think Free Software Foundation sounds serious and we want to be taken seriously too” technology Foundation created in the USA after the FSF, most notably the Linux Foundation which is the legal home of many of the others, is a 501(c)(6) which is more a not-for-profit cartel than a charity. Notably 501(c)(6) are allowed to lobby in the interests of their corporate “donors” which 501(c)(3) may not do. If you want your public software to be managed in the public interest you have to look beyond corporate associations to groups like FSF, Conservancy, or SPI.)

                                                                                                                  1. 2

                                                                                                                    Thanks a lot for clearing that up. US non-profit law is confusing to outsiders.

                                                                                                                3. 1

                                                                                                                  You aren’t the only one who reacted that way. I have the same sentiments. Though given the other members….Rust could easily be in jeopardy of lost funding even without FB.

                                                                                                                1. 1

                                                                                                                  Nice, yet another reason not to use Rust!

                                                                                                                  1. 17

                                                                                                                    Be careful, they also use C (e.g. in zstd). Better not use C either!

                                                                                                                    1. 5

                                                                                                                      It is one thing to dislike Facebook having influence on the Rust Foundation. However, it is another thing to not use Rust because of this event. Would you care to unpack your reasoning? Does it have to do with moral principles? Predictions about where this leads?

                                                                                                                      Also, for the language(s) you prefer, to what degree are they “free” from the same concerns you have about Rust and/or Facebook’s involvement in Rust?

                                                                                                                      I admit that I’m prodding a bit here, because when people say “reasons” it is only fair to dig in and get, well, the reasoning as opposed to a one-liner.

                                                                                                                      1. 2

                                                                                                                        I don’t write Rust, but most it seems like most developers have had an overwhelmingly positive reaction to the emergence of Rust. I’m curious, what (other than Facebook’s involvement) makes you hesitant to get on board? What are some alternatives that you would consider instead?

                                                                                                                        1. 6

                                                                                                                          I’ve been told many, many times, “Why are you using Rust? You should use Rust!”, and it feels very much like the push for everything to be Java and OOP years ago. I actually like writing Rust and I’ve made a few things with it. I might have burned out of learning updates to it since I started writing it around 1.0 until around async/await getting stabilized.

                                                                                                                          Ada 2012 is a viable mature alternative, and is very close in feature set and many conceptual constructs to a Pascal version of a safer C++, with extra features for type safety and error detection. Going from C++ -> Ada is actually a two week process or so because there’s many similarities, despite the languages being in different families.

                                                                                                                          1. 12

                                                                                                                            With all due respect, I was around for the “everything Java” push (maybe you were too!) and the movement around Rust is much more “grassroots”. Java had the backing of a big “hot” corporation (yes kids, Sun was hot once!) and there were endless streams of books and tutorials and people cold calling companies and seminars and stuff. Not to mention tons of back-end development of standard libraries, etc.

                                                                                                                            Rust to me still feels like an enthusiast movement, but coupled with an actual, delivered product.

                                                                                                                            1. 2

                                                                                                                              My tone may not have come across well, I’m not trying to disparage Rust or be combative, I’m just giving my opinion. Rust usage would likely affect me at work, so I’ve been trying to predict it’s adoption by reading about Theory of Reasoned Action, the Technology Acceptance Model and similar concepts. At the time people were just trying to solve development problems, just like they’re trying to do now. I’m curious if Github and more widespread internet and computing resources existed back then, if there would have been more parallels, or if Smalltalk would have had more sticking power.

                                                                                                                            2. 2

                                                                                                                              I’ve been told many, many times, “Why are you using Rust? You should use Rust!”, and it feels very much like the push for everything to be Java and OOP years ago.

                                                                                                                              I take your point. There are (at least) two underlying aspects:

                                                                                                                              1. Distinguishing initial enthusiasm from longer-term suitability.

                                                                                                                              2. Distinguishing ‘disinterested’ (i.e. unbiased) recommendations from marketing-driven hype.

                                                                                                                              Another factor to consider: Around Java’s first public release in 1996, the main popular alternatives were C and C++. (Fair? I’m not a historical expert, so please add to this – i.e. let me know if others were considered both popular and situated similarly.) In contrast, compare 1996 to 2015, when Rust 1.0 was released. The diversity and language competition is much deeper now. My point is to say that Rust’s popularity is even more impressive given the choices available; e.g. C, C++, Java, Python, Go, Scala, C#, F#, Haskell …

                                                                                                                              1. 3

                                                                                                                                I think Delphi was a popular alternative back then while Smalltalk was close to where Rust is now in industrial mindshare.

                                                                                                                                1. 1

                                                                                                                                  A lot of this was told to me by a Smalltalk developer at the time. Smalltalk was somewhat already established. It wasn’t just Sun, but it was competing against IBM, a giant at the time, that made the independent Smalltalk tool developers feel like they had to merge together and resulted in many internal issues. With the smaller folks struggling, Smalltalk effectively died when IBM pivoted to Java. This is a bit oversimplified, there were other technical concerns involved.

                                                                                                                                  I think Facebook joining up, along with other big names is the equivalent of Sun and IBM with Java. In this way, I feel Rust vs Ada seems to parallel Java vs Smalltalk in some ways and I think Ada (and possibly C++) is in big trouble, if it wasn’t already. However, AdaCore is in full swing promotion and marketing mode right now, so things might get interesting over the next year.

                                                                                                                            3. 2

                                                                                                                              Be careful. We the are crustaceans.

                                                                                                                            1. 1

                                                                                                                              Can haz mind-map version grouped by topic and/or theme? K thnks bye.

                                                                                                                              1. 2
                                                                                                                                1. The article is about Google search. Perhaps the claim could be generalized, but the article doesn’t do so convincingly. Therefore, “Google” should be prominent in the title. A more apropos title would be: “Google search results rely on metadata more than some realize.”

                                                                                                                                2. Like many articles, this one is mired in the quagmire of the ambiguity of the “AI” term as well as different people’s expectations. I don’t see much point in feeding off this ambiguity or claiming that “AI was promised”. Promised by who?

                                                                                                                                3. There are many false dichotomies in the article. There is not a zero sum game between AI and metadata. They can and do work together. For example, having metadata features, content analysis, and graph analysis are all useful for AI. (As I say in (2), the term AI is debatable, but by many definitions, machine learning and optimization are included.)

                                                                                                                                1. 12

                                                                                                                                  Ah, the world where storing a string vs a Boolean has “negligible” overhead. Whereas my inner bean-counter immediately starts hopping up and down yelling about heap allocations and locality of reference, and even if you store the time stamp as a double that’s 8 bytes vs 1 and do you know the size of a cache line…?

                                                                                                                                  Not saying one world is truer or better, of course! I wasn’t the one stating a practice that’s “almost always” right. I’m just amused at how people think their domains are all there is (like the web-dev folks who can’t believe SQLite is more widely deployed than Postgres.)

                                                                                                                                  1. 7

                                                                                                                                    If you are working with those restraints then it’s pretty obvious that his won’t work for you, but I think it’s very obvious that this post wasn’t aimed at you.

                                                                                                                                    1. 4

                                                                                                                                      Yeah. “Web development” features in the very first sentence of the post, and I’m sure the blog author knows their audience. Comments like the one you replied to don’t elevate the discussion whatsoever. (cf. @dbove’s, which is germane and an interesting discussion point.)

                                                                                                                                      1. 2

                                                                                                                                        there are tons of other web development languages where people would cringe at:

                                                                                                                                        is_published = new Date();
                                                                                                                                        if (is_published)

                                                                                                                                        that’s… not how types should work, really (I know that in Python it could also be None, but in this case I find this a horrible combo of naming+type)

                                                                                                                                        1. 2

                                                                                                                                          Sure, say if published_at != nil or whatever the equivalent idiomatic truth test in your language of choice is.

                                                                                                                                          The article maybe spends too much time on the ergonomics in JavaScript with the large code block, drawing attention away from its whole point: that you’re better off storing a nullable timestamp than a boolean in most cases.

                                                                                                                                          How you then test that field is kind of secondary to the data modelling concern. (“And you can pretty this up with a helper function called isPublished() which checks the published_at attribute.”)

                                                                                                                                      2. 4

                                                                                                                                        Mea culpa — by the time I reached the end I must’ve forgotten the first sentence, “ In my 15+ years of web development…” 😫

                                                                                                                                      3. 2

                                                                                                                                        A string? Is that a typo?

                                                                                                                                        1. 3

                                                                                                                                          If you’re using sqlite3, it is. explains:

                                                                                                                                          2.2. Date and Time Datatype

                                                                                                                                          SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:

                                                                                                                                          • TEXT as ISO8601 strings (“YYYY-MM-DD HH:MM:SS.SSS”).
                                                                                                                                          • REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
                                                                                                                                          • INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.

                                                                                                                                          Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.

                                                                                                                                          And sure enough:

                                                                                                                                          > sqlite3 tmp.sqlite3
                                                                                                                                          SQLite version 3.32.3 2020-06-18 14:16:19
                                                                                                                                          Enter ".help" for usage hints.
                                                                                                                                          sqlite> create table asdf (id integer primary key, created_at timestamp);
                                                                                                                                          sqlite> insert into asdf (id, created_at) values (1, CURRENT_TIMESTAMP);
                                                                                                                                          sqlite> ^D
                                                                                                                                          > strings tmp.sqlite3
                                                                                                                                          SQLite format 3
                                                                                                                                          CREATE TABLE asdf (id integer primary key, created_at timestamp)
                                                                                                                                          32021-04-25 03:57:55
                                                                                                                                          > xxd tmp.sqlite3 | tail -2
                                                                                                                                          00001fe0: 0000 0000 0000 0000 1601 0300 3332 3032  ............3202
                                                                                                                                          00001ff0: 312d 3034 2d32 3520 3033 3a35 373a 3535  1-04-25 03:57:55
                                                                                                                                      1. 31

                                                                                                                                        If the author is here and open to changing the post title, Rust is for everyone, and good for professionals too! The title as is sounds like it may be exclusionary toward people who don’t identity as professionals, or feel intimidated by Rust, which is contrary to Rust’s core goal of opening up systems programming to everyone!

                                                                                                                                        1. 39

                                                                                                                                          I, the author, am here.

                                                                                                                                          I appreciate the constructive feedback and can see your point. Choosing titles is hard. I too was concerned about the exclusionary potential for the title. However, I thought I had it sufficiently mitigated by the introduction paragraphs. Apparently I could have done better.

                                                                                                                                          I’m not going to change the title of this post because I don’t want to deal with the hassle of rewriting URLs. However, I will try to consider your feedback for future posts I author.

                                                                                                                                          1. 6

                                                                                                                                            I appreciated the way you took the feedback. Just wanted to say thanks for listening and considering it.

                                                                                                                                            1. 3

                                                                                                                                              I’ve programmed in the following languages: C, C++ (only until C++11), C#, Erlang, Go, JavaScript, Java, Lua, Perl, PHP, Python, Ruby, Rust, shell, SQL, and Verilog.

                                                                                                                                              To me, Rust introduced a number of new concepts, like match for control flow, enums as algebraic types, the borrow checker, the Option and Result types/enums and more.

                                                                                                                                              How did you use Erlang without pattern matching?

                                                                                                                                              1. 2

                                                                                                                                                I think the order is alphabetical so its possible that author used Erlang after he learned Rust.

                                                                                                                                                Have a nice day!

                                                                                                                                                1. 1

                                                                                                                                                  Doesn’t add up, he says that Rust introduced pattern matching to him :-)

                                                                                                                                              2. 3

                                                                                                                                                My usual way of framing it is “Rust is an industrial programming language”. That leaves the door open for practitioners of all kinds. It’s more like a cars are (in general) a utility and not a plaything or research endeavor, but are open to enthusiasts and amateur practitioners as well.

                                                                                                                                                1. 2

                                                                                                                                                  Thanks! I liked the disclaimer, and think predicting how people will respond can be tough. Appreciate you putting in the time to write this, and agree that Rust can be used in professional / production environments successfully, and that it can feel like a breath of fresh air for many!

                                                                                                                                                2. 22

                                                                                                                                                  Or, alternately, when someone writes 13,000 words about how nice Rust is, how ergonomic and human-centric and welcoming and humane the language and tooling and community are, they can keep the title without someone telling them they’re maybe being exclusionary.

                                                                                                                                                  1. 16

                                                                                                                                                    It’s constructive criticism. If you post something on the public web, it’s fair game to criticize it- especially if done in a polite manner.

                                                                                                                                                    1. 23

                                                                                                                                                      It’s criticism, but just because it’s delivered politely does not mean it is constructive. There is a cost to spending the effort to write a thirteen thousand word love letter to a language, just to have someone nipping at your ankles about how the first four words might exclude someone. Objectively speaking, this is a blogger that Rust would benefit from sticking around – but what is the signal they’ve received here?

                                                                                                                                                      1. 11

                                                                                                                                                        Agree 💯.

                                                                                                                                                        Recently a friend submitted his static site generator which is optimised for math heavy sites on HN.

                                                                                                                                                        He made the fatal mistake of calling it “beautiful” in the description and the amount of hangups that people had. It was done in a mostly polite manner, but the amount of time and energy wasted in discussing just the first sentence with barely any technical discussion of the internals, was a form of pathological bikeshedding that I was surprised to see. It was just that “nipping at his ankles” as you’ve described, which can take its toll.

                                                                                                                                                        Vowed to never take that site seriously again.

                                                                                                                                                        1. 1

                                                                                                                                                          It was done in a mostly polite manner, but the amount of time and energy wasted in discussing just the first sentence with barely any technical discussion of the internals, was a form of pathological bikeshedding that I was surprised to see. It was just that “nipping at his ankles” as you’ve described, which can take its toll.

                                                                                                                                                          Agreed. Yet here we are- arguing about arguing. I need a life… xD

                                                                                                                                                          1. 1

                                                                                                                                                            Right, in my experience, HN often attracts uninteresting, unhelpful, or even mean-spirited commentary. Sometimes I am surprised by the opposite, though. In any case, understanding the dynamic really helps. A lot of commentary, seems to me, are upset at some level in some way and take it out in their commentary.

                                                                                                                                                          2. 3

                                                                                                                                                            The author thanked them and described the feedback as constructive. So if they feel like they’ve taken something away from it, who are we to decide otherwise? My own hopefully constructive feedback here is that this subthread strikes me as projecting conflict into an interaction between two parties who themselves seem to have had a positive experience with it.

                                                                                                                                                            1. 2

                                                                                                                                                              Yeah, I get where you’re coming from and I don’t really disagree.

                                                                                                                                                              But I also think that the person who offered the criticism is just trying to help the author get more views.

                                                                                                                                                              It’s fair to suggest that we all should consider our criticisms carefully, though. Because you’re right- if the criticism isn’t that important, we may just be disincentivizing someone from future contributions.

                                                                                                                                                              I also wonder if you’re maybe reading a little too hard into the choice of the word “exclude” used by the criticizer, though… I think that term has a little bit of extra charge and connotation in today’s social environment and I don’t believe the criticizer meant it in that way. I think they simply meant that a person who isn’t writing enterprise software might pass over the article because they believe they aren’t the target audience. I agree with that conclusion as well, because I do write enterprisey software and I thought the article was going to be about that specific point of view- I thought I would see arguments about productivity and developer costs and cross-platform support and other less-sexy stuff. But, it was really- as you said, just a love letter to everything about Rust.

                                                                                                                                                          3. 8

                                                                                                                                                            I felt this lead-in made it a friendly suggestion and not harsh:

                                                                                                                                                            If the author is here and open to changing the post title

                                                                                                                                                            1. 4

                                                                                                                                                              FWIW first third of those thousands of words is irellevant chitchat. The First actual claim on why is rust good is rust makes me giddy. I’m not sure “giddy” describes profesionals. It’s not no, but for me definitely not a yes either - giddy is just…giddy. Then all the technical points, borrow checkers, race conditions and whatnot - none of that tells me why is it a thing for professionals.

                                                                                                                                                              What I mean is, I don’t know if rust is for pros or not, I just think that the title is a bit click-baity, and “rust is good for everyone, even pros” like alilleybrinker suggested would work much better.

                                                                                                                                                              1. 7

                                                                                                                                                                The First actual claim on why is rust good is rust makes me giddy. I’m not sure “giddy” describes profesionals.

                                                                                                                                                                There’s a layer of extra irony here in that the word “amateur” comes from a root meaning “love”; in other words, amateurs are people who do something because they love it. So taken literally, this is very unprofessional!

                                                                                                                                                            2. 18

                                                                                                                                                              It seems relevant to note that the author does address this in the post itself:

                                                                                                                                                              The statement Rust is for Professionals does not imply any logical variant thereof. e.g. I am not implying Rust is not for non-professionals. Rather, the subject/thesis merely defines the audience I want to speak to: people who spend a lot of time authoring, maintaining, and supporting software and are invested in its longer-term outcomes.

                                                                                                                                                              1. 10

                                                                                                                                                                Yes, except the title doesn’t have a disclaimer, and will be taken in the way they say they don’t want. Rather than leaving it ambiguous, they could change the title to remove the ambiguity.

                                                                                                                                                                1. 28

                                                                                                                                                                  This side-steps the issue “people don’t read past the title” - which is the real problem. It’s bad, and unrealistic, to expect every person who writes on the internet to tailor each individual sub-part of an article (including the title) to an audience that is refusing to read the (whole) article itself before making judgements or assumptions. That’s purely the fault of the audience, not the writer, and changing the article title is merely addressing the symptoms, instead of the root problem, which will allow it to just become worse.

                                                                                                                                                                  We have an expression “judging a book by its cover” specifically for this scenario, and in addition to that, any reasonably-thoughtful reader is aware that, once a sufficient amount of context has been stripped away, any statement loses its meaning - which logically implies that full context must be absorbed before the reader has any chance of understanding the author’s intended meaning.

                                                                                                                                                                  People should not have to write hyper-defensively on the internet, or anywhere, because civil discussion collapses when your audience isn’t acting honestly.

                                                                                                                                                                  Reading the title and judging before reading the content itself is not acting honestly.

                                                                                                                                                                  1. 4

                                                                                                                                                                    Thank you for writing this. I’m sick of how much culture is warped by toxic social media sites.

                                                                                                                                                                  2. 7

                                                                                                                                                                    Agreed. It’s a poor choice for a title, even with a disclaimer. In fact, that he knew he needed a disclaimer should have been a big clue that it wasn’t a good title.

                                                                                                                                                                    A better title would be: “Professional devs should love Rust”, or “Rust isn’t just for enthusiasts and hipsters”

                                                                                                                                                                    1. 0

                                                                                                                                                                      I don’t disagree.

                                                                                                                                                                  3. 18

                                                                                                                                                                    Responses like this make me hesitant to try Rust, because they make me feel that I’d have to tiptoe around every word I put into a chat room, issue tracker, or mailing list.

                                                                                                                                                                    1. 10

                                                                                                                                                                      I’m not sure this is a Rust issue as much as a general issue of recent years. Be delicate and excessively sensitive about everything because everyone’s an egg shell. It’s contrary to anti-fragility which I would suggest is a far better approach; and the opposite approach. “Rust is for professionals” would have had me targeting Rust so that I could level up, not scare me away. Show me a challenge,

                                                                                                                                                                    2. 5

                                                                                                                                                                      I used rust for three years outside of work, but I’m afraid I stopped last year because I find it too big for a hobbyist. If I used it all day every day - no problem. It’s a great language, but I agree with the title.

                                                                                                                                                                      1. 2

                                                                                                                                                                        This was my first thought, as well, before even reading the article. Obviously I should read before judging, but the author may want to consider that the title could turn away potential readers.

                                                                                                                                                                        I made the same mistake in my own My staff engineering reading list. There was no reason for me to needlessly exclude people earlier in their careers from my list.

                                                                                                                                                                        And it’s good feedback that the author of this piece may not want to unintentionally exclude people from their article.

                                                                                                                                                                      1. 2

                                                                                                                                                                        I once used Hammerspoon but later realized that I can do anything in Hammerspoon with Keyboard Maestro so I stopped using it.

                                                                                                                                                                        1. 1

                                                                                                                                                                          How does your recommendation handle window management? (I looked at a few pages, but didn’t find much.)

                                                                                                                                                                          1. 1

                                                                                                                                                                            I use BetterTouchTool for window management. But KM has actions to move windows too.

                                                                                                                                                                          2. 0

                                                                                                                                                                            Do you have any incentives or connections that might influence your recommendation?

                                                                                                                                                                            1. 1

                                                                                                                                                                              Not sure what you mean. I love KM because its a tool where I can easily make custom macros with as many actions as I want and bind it to a key directly with Karabiner.

                                                                                                                                                                              1. -1

                                                                                                                                                                                I’m asking if you have any financial incentives to recommend Keyboard Maestro.

                                                                                                                                                                                1. 2

                                                                                                                                                                                  Why are accusing him of shilling?

                                                                                                                                                                                  1. 0

                                                                                                                                                                                    I’m not accusing, just asking.

                                                                                                                                                                                  2. 1

                                                                                                                                                                                    What a profoundly odd line of questioning.

                                                                                                                                                                                    1. 2

                                                                                                                                                                                      In some other contexts, some would call this line of questioning “in bad faith”

                                                                                                                                                                            1. 2

                                                                                                                                                                              I found this in a back issue of Communications of the ACM. I shared it because, frankly, I could see myself in part of the story. I see some limitations of the article: (a) I suspect the tone may grate on some people – including myself; (b) the label of “hazardous enthusiasm” seems problematic and perhaps conflates too many other issues; and (c) as would be expected, it shares just one viewpoint around a particular kind of contributor.

                                                                                                                                                                              In any case, I think it might be a useful starting point for discussion, even though it leaves out some pretty big facets of the issues involved.

                                                                                                                                                                              1. 2

                                                                                                                                                                                I’ve definitely run into a few devs of this type — not in the open-source world, but at work.

                                                                                                                                                                                This company (no longer my current employer) was started by a CEO who could “write a bit of code”. He hired a couple more devs to get things over the wall into production, and the company was quietly successful for the next 5 or 6 years, then it started getting big fast, had an IPO, acquired a bunch of companies, started up a bunch of new products, etc. — but the main revenue source was still the codebase that the CEO had started on day one, which was getting pretty scary and fragile. It was ugly, but it worked. There was a Big Rewrite project, but it didn’t succeed until after I was gone.

                                                                                                                                                                                Anyway for several years I was pretty much in charge of the care and feeding of that app, and I was pretty decent at it, managed to keep it running in the face of way more traffic, and even add new features. Management, of course, always wanted me to have more devs, so that they could have more new features. So we hired, and some were dull, and some were bright, as it goes. But I learned that being bright wasn’t enough — some of the brightest ones just could not engage with the code on its own terms. It was too different from anything they’d dealt with. If you tasked them with adding a checkbox to a form to control a new user preference which had to be honored in a certain place, they would come back with a plan to refactor this, rewrite that, and extract such-and-such into a new service written in Clojure. Noble, and sometimes with good ideas behind it, but not practical. If you asked them to stick to getting the job done, their brains would lock up. We would send them off to another team working on a greenfield project with a sexy tech stack, and start looking for a replacement.