1. 25

    A quick, rough timeline:

    • 2005: git is released, and Junio Hemano becomes the core maintainer
    • 2008: the first thread about staging on the linked article, and, GitHub is formed
    • 2021: 13 years later, this is still a thing

    There’s something about “we can’t change this, what about all the people using this” in the early days, becoming an issue for far far longer and for far many more people, that feels like a failure mode.

    1. 31

      I’m reminded of the anecdote about make: Its original author used tab characters for indentation in Makefiles without much thought. Later when they decided to add make to UNIX, they wanted to change the syntax to something more robust. But they were afraid of breaking the ten or so Makefiles in existence so they stuck with the problematic tab syntax that continues to plague us today.

      1. 11

        Your comment reminds me of the origin of C’s confusing operator precedence rules:

        Eric Lippert’s blog post “Hundred year mistakes”

        There were several hundred kilobytes of existing C source code in the world at the time. SEVERAL HUNDRED KB. What if you made this change to the compiler and failed to update one of the & to &&, and made an existing program wrong via a precedence error? That’s a potentially disastrous breaking change. …

        So Ritchie maintained backwards compatibility forever and made the precedence order &&, &, ==, effectively adding a little bomb to C that goes off every time someone treats & as though it parses like +, in order to maintain backwards compatibility with a version of C that only a handful of people ever used.

        But wait, it gets worse.

        1. 18

          I think this article includes a logical fallacy. It assumes that whatever you’re doing will be successful, and because it is successful, it will grow over time. Since it will grow over time, the best time for breaking changes is ASAP.

          What this logic ignores is that any tool that embraces breaking changes constantly will not be successful, and will not grow over time. It is specifically because C code doesn’t need continual reworking that C has become lingua franca, and because of that success, we can comment on mistakes made 40+ years ago.

          1. 6

            Sure, but this error propagated all the way into Javascript.

            I’m not saying C should have changed it. (Though it should.) But people should definitely not have blindly copied it afterwards.

        2. 3

          I’m curious why you think it is problematic? Just don’t like significant whitespace? But make also has significant newlines…

          1. 3

            For me it’s because most editors I’ve used (thinking Vim and VSCode) share their tab configs across file types by default.

            So if I have soft tabs enabled, suddenly Make is complaining about syntax errors and the file looks identical to if it was correct. Not very beginner friendly.

            1. 4

              IIRC Vim automatically will set hardtabs in Makefiles for you. So it shouldn’t be a problem, at least there (as long as you have filetype plugin on).

              1. 2

                I always make sure to have my editor show me if there are spaces at the front of a line. Having leading spaces look the same as r trb is a terrible UX default most unfortunately have

            2. 2

              Thanks, I hate it

              1. 1

                What was the problem with tab syntax?

            1. 4

              I’d like to write something book-like someday, and I’d idly mused about doing print on demand. This has convinced me that I actually don’t want to do that.

              This print work is fascinating and valuable and hard, and I don’t want to do it. I want to git push book readers_brain.

              1. 19

                Author here. You can definitely do a print edition of a book much easier than I did. I specifically chose to:

                • Hand illustrate everything.
                • Use a two-column design with lots of asides.
                • Include every single line of code in the book along with contextual location information so that readers can build up a complete program.

                If your technical book doesn’t do all that, it’s a lot easier. A lot of CS books are done in LaTeX where the process is mostly automated. It is still a decent amount of work to edit, find a copyeditor, index, design a cover, etc. If you don’t have any graphic design background, you’ll end up with a more beautiful book if you go with a conventional publisher.

                1. 7

                  The asides in the margins remind me of Tufte’s books. Did you take any influence from them?

                  I think I remember reading something about how he also made sure that every diagram and the text that referred to it appears on the same page? And it involves a ton of labor. Not sure if that is true but I think so.

                  I’m very impressed by the craftsmanship! :)

                  1. 5

                    Oh, yes, I have been a Tufte fanboy for many years. :)

                  2. 4

                    Thanks for the reply! All of that work definitely comes across, I wish my CS textbooks looked as good as the pictures you featured.

                    Side thing: I’m totally bookmarking your tile_pages script. That kind of non-text document-modification-verification tool seems super useful.

                  3. 6

                    I used a professional publisher, but did all of the typesetting of my books myself using LaTeX. The only difficult part was making the copyright page correspond to the publisher’s template. I wrote in a semantic markup language that happened to be valid LaTeX syntax, so for the ePub editions, I wrote a small program that parsed this into a DOM-like structure and emitted semantic HTML. I would probably just use something like PanDoc and Sile if I did this again. I did all of the diagrams with OmniGraffle (sadly, my favourite drawing program is an older version of OmniGraffle that doesn’t run on modern macOS - Omni Group went full hipster and turned their beautifully clean NeXT-inspired UIs that were a joy to use into things that looked great while posing with a MacBook in a coffee shop and are a pain to use).

                    I spent a while tinkering with the typeset output because I’m a typography geek, but it wasn’t really required. I used URW Grotesk for the titles and the standard LaTeX fonts for pretty much everything else.

                    Getting a good copyeditor is probably the hardest part if you’re self publishing. I worked with some fantastic ones and some mediocre ones, even with a professional publisher in the mix.

                    640 pages over 15 months is a very nice sedate rate, it averages to less than 1.5 pages per day. That’s a nice sustainable pace.

                    1. 6

                      I’m writing a book about publishing for technical people and the interior formatting has almost been the doom of the project because I wanted an index in the print edition. As munificent says, there are much easier ways to do it depending on your particular priorities.

                      My chapter about interior formatting has a recommendation specifically geared toward technical people: AsciiDoc. The format provides a good deal of power, and the tooling is pretty good — but a lot depends on what you want your end product to look like. Crafting Interpreters is a beautiful work and there’s no easy way to get that kind of format without the work (other than hiring that work out, either to a traditional publisher or independently).

                      Leanpub also does a good job of giving you tooling to target ebook and print.

                      1. 2

                        I’m probably going to use leanpub, primarily because I have no idea what I’d want a book too look like. I just want it to be readable.

                        Ironic that a book about publishing has troubles in the designing/publishing pipeline!

                        1. 4

                          I just want it to be readable.

                          You can try pandoc. I use it to convert GitHub style markdown to pdf/epub. The default conversion by pandoc is good enough, but I spent some time customizing it. There are templates made by others that you can use too. That said, I haven’t done print versions, only ebooks.

                          I wrote a blog post about my set up (includes other resources at the end too): https://learnbyexample.github.io/customizing-pandoc/

                          1. 3

                            Part of the value of the book is that I’m blazing the trail somewhat.

                            There are actually a number of fine choices for people who don’t care about having an index, and there’s even a program that will add an index to your PDF file. So it’s not terrible in general. I’ve published 4 novels and that experience was quite pleasant!

                      1. 3

                        Aside from a couple of IEEE pecadillos, almost all of these are from implicit conversions. The reason JS has so many implicit conversions was because the initial design of the language had no way to report runtime errors. In the absence of that, every operation on every possible kinds of operands had to produce some kind of value and now here we are.

                        If there a lesson here for other language designers, it’s that you need to have a coherent strategy for handling type errors from day one or you will end up regretting it. That can be static types, exceptions, or something else, but you have to think about it and do something or you’ll end up having to fill every single cell of your implicit conversion table with increasingly arbitrary values and your users will hate you forever.

                        1. 9

                          Use the right tool for the right job.

                          1. 30

                            Really not a fan of this quote. How do you know what the right tool is? How do you know what the right job is? “Use the right tool for the right job” is like saying “write good code, not bad code.” It doesn’t inform us.

                            1. 17

                              The phase is best used among the already informed when making a decision about what is available. To the uninformed I would simply say “do not be dogmatic.”

                              1. 6

                                I agree that this quote can be frustrating and has the property that its wisdom is most visible in hindsight.

                                But the way I interpret this is not to mean “You should know the right tool”, it’s to draw attention to the fact that the right tool is context sensitive. “The right job” part of the quote is critical. It’s saying that a blanket answer doesn’t work because the solution depends on at least one parameter. Seek out those parameters and then the solution becomes more obvious.

                                1. 4

                                  How do you know what the right tool is? How do you know what the right job is?

                                  You know what the right tool is by getting good at lots of different tools, thinking about them a lot, reading what people have written, and talking with people about what they have experienced. You know what the right job is basically via the same method.

                                  As c12 has pointed out, when you rely too much on other people’s experiences, or those experiences are not varied enough, you can fall into the trap of dogma. If you rely too much on your own experiences, without considering the wisdom of others, you can fall into the trap of egotism.

                                  I like this quote a lot because it’s what broke me of my antipattern of looking for the Perfect Programming Language. The smartest person I knew was doing a game jam and writing the game in C, and I asked why they would use something so backwards instead of Haskell or OCaml or Lisp or anything else. Their response was that C was a good tool for what they were trying to do.

                                  1. 2

                                    Could not agree more. In addition to your questions: Should you choose the perfect-fit tool that you’ve never used before or the fits-ok tool that you’re an expert in? What about the perfect tool that you’re an expert in but no one else on the team has used before? And if we’re just talking about language paradigms in a code base, how do you prioritize problem-paradigm fit versus consistency?

                                1. 13

                                  Very impressive. But is it just me, or is guys buying a lot of clothes? 15 pair of shoes over the course of three years? That sounds like a lot.

                                  I did a quick count and I have used 8 shoes over the course of three years.

                                  1. 7

                                    Not judging but this guy has more white sneakers than I have shoes, and more belts than I have pants.

                                    1. 6

                                      If you’re the sort of person who would track every item of clothing you wear, every day, for three years, you probably already like fashion!

                                      1. 5

                                        If he’s an avid runner it could be running shoes.

                                        1. 6

                                          In the article, he says sportswear is excluded.

                                          1. 2

                                            This. I know I can go through three pairs about every thousand miles, where I’m averaging about 1.5k-mi every year.

                                            1. 2

                                              Looking at the pictures in the post, it doesn’t look like very many running shoes.

                                              1. 2

                                                I did a quick inventory:

                                                • Dress shoes that I only use indoors at work (12 years old), looks like new. But they go to the shop every couple of years.
                                                • Winter boots (~10 years)
                                                • Winter boots (~3 years)
                                                • Chelsea boots (~6 years)
                                                • Sneakers (~ 3 years old)
                                                • Sneakers (~ 2 years old)
                                                • Running shoes (~ 5 years)
                                                • Indoor training shoes (~6 years old)
                                                • Dress shoes (~7 years old)

                                                Then I have a couple of shoes that I have not used for years.

                                                Hmm.

                                              2. 3

                                                His GitHubIO page is actually really interesting in this regard: https://hoverfalt.github.io/shoes.html

                                                1. 2

                                                  The author probably lives here in Finland (Reaktor is a mostly-Finnish company). You need shoes for temperatures from -25 to +25 degrees Celsius, for snowy/slushy/wet/dry conditions. If you do sports year round or like variety, that quickly adds up.

                                                  EDIT: on a closer look, yeah, I have less than half the amount of clothes of the author.

                                                  1. 3

                                                    Yes. I live in the middle of Sweden. So have more or less the same climate. Very seldom -25, but still.

                                                  2. 1

                                                    It’s a lot of clothes, but it makes more sense if you look at it as a hobby.

                                                  1. 2

                                                    I like most of this except the rule against early returns. Consider the suggested alternative:

                                                    if (input less than waterleve) {
                                                        turn motor on
                                                    } else {
                                                        turn motor off
                                                    }
                                                    

                                                    When reading this code, you ask yourself “when can the motor be turned off”? To answer that, you need to reason about the control flow that can enable that statement to be reached. You have to look up at the if condition. When that condition is true, the then block is run. Then you negate the condition in your head and understand that the else can only be reached when the condition is false. That’s exactly the same mental processing you do for an early return.

                                                    In particular, consider a more complex example using early returns:

                                                    if (file does not exist) return file not found error;
                                                    
                                                    if (file is empty) return file empty error;
                                                    
                                                    if (file cannot be read) return read error;
                                                    
                                                    read file;
                                                    

                                                    The author argues that this is better written as:

                                                    if (file does not exist) {
                                                      return file not found error
                                                    } else if (file is empty) {
                                                      return file empty error
                                                    } else if (file cannot be read) {
                                                      return read error;
                                                    } else {
                                                      read file;
                                                    }
                                                    

                                                    But, again, ask yourself, “When does the file get read?” The answer to that is “When the file exists, and it’s not empty, and it can be read.” Even though there are technically no “early returns”, the chain of else if clauses still means that you have to maintain all of those if conditions in your head when reasoning about the control flow. The underlying control flow is the same, as is the cognitive load.

                                                    Also, for what it’s worth, I think Dijstra’s “Goto Considered Harmful” letter to be a weak, poorly-argued claim and Dijkstra’s own “guarded control flow” language is just as bad as goto according to his own logic.

                                                    1. 1

                                                      We have to remember all those conditions in both cases, but the second one makes it much more easier for us to to identify what they are and to separate them from the rest of our code.

                                                      1. 1

                                                        the second one makes it much more easier for us to to identify what they are

                                                        Do you have evidence to support that claim?

                                                        1. 1

                                                          Well, in the first case, they (the conditions) may be scattered all over the function, while in the second one they are all contained in this one if-else clause. Consider an example where the read file; operation is 100 lines of code long - if an early return is permitted, then you would have to read all those 100 lines in order to ensure that they don’t contain a return statement, while if it’s not, then all of those would be in one big else block, and you would know they do not contain extra conditions.

                                                    1. 1

                                                      Short history of the if statement? Was McCarthy exagerating when he claimed to invent it in 1960?

                                                      https://en.wikipedia.org/wiki/McCarthy_Formalism#McCarthy's_notion_of_conditional_expression

                                                      1. 2

                                                        Fortran (well, FORTRAN at the time, I guess) had conditional code execution. So it could jump from one place to another based on some Boolean expression. This was a mechanistic, imperative thing.

                                                        McCarthy invented the conditional expression. It was a way in mathematics of defining recursive functions that didn’t have an infinite regress. It also just happened to turn out that you could take McCarthy’s math and make a computer implement it. It’s not clear to me how much innovation McCarthy’s conditional expression really is. It seems conceptually quite similar to piecewise functions, which I’m guessing are much older.

                                                        1. 1

                                                          The if statement existed in FORTRAN, I think, but the blocks were a later idea. The first language that had blocks was ALGOL 60. And yes, McCarthny was involved.

                                                          http://www-formal.stanford.edu/jmc/recursive.pdf (see footnote 2).

                                                          https://craftofcoding.wordpress.com/2017/04/29/the-evolution-of-if-i-from-fortran-i-to-algol-60/

                                                        1. 1

                                                          It was an audacious goal, especially for a language released in 1995.

                                                          Is it just the baggage that’s implied? Or that newer things are necessarily better/faster?

                                                          1. 25

                                                            Maybe the implication is that the language has already been incrementally improving for 25 years, so a 3x speed-up at this point in its development would be quite remarkable.

                                                            1. 4

                                                              The last time I looked at Ruby, it was significantly slower than Squeak, which at the time was a fairly faithful reimplementation of a Blue Book Smalltalk-80 bytecode interpreter and what I’d consider to be minimal baseline performance for a new dynamic language implementation that learned anything from prior work. I believe Squeak has since added JITs and other more modern features but at the time it was focused aggressively on being easy to understand and hack on at the expense of performance. Being slower than Smalltalk when your language is Smalltalk minus several of the bits of Smalltalk that are hardest to implement efficiently was pretty depressing.

                                                              There was definitely a lot of room for improvement.

                                                              1. 3

                                                                I think it’s worth pointing out that Ruby is a much larger language with a huge core library. Surface area matters a lot when it comes to optimizing language performance. A typical Ruby application will touch a lot of language features, so if any part is left unoptimized, that loss may easily dwarf the gains made in other areas. You have to optimize the whole enchilada, and that can be cost-prohibitive for teams without deep pockets.

                                                                I can’t find the links now, but I recall one of the people on PyPy saying Python is harder to optimize than JS just because Python’s core lib surface area is so large. Mike Pall said something similar about why LuaJIT was feasible as a mainly single-person project: the language and libs are tiny.

                                                            2. 1

                                                              Maybe they are saying older things are faster because they were designed for slower computers, making it hard improve on performance?

                                                            1. 9

                                                              Very interesting read. I wonder how much the bad times with async the author met, are caused by the 2000’s style of async that is based on callback hell. Modern async (as implemented in, say, rust) emphasizes writing async functions in a direct style (with “async”/“await” keywords and compiler support to turn these into state machines, not callbacks) that should be as readable as their purely sequential counterpart. The dispatch might also be different, using a work-stealing scheduler backed by a pool of threads, instead of many single-threaded queues of events.

                                                              1. 14

                                                                I don’t think it fundamentally changes things. async/await is more syntax than anything, and will not prevent ordering bugs because of concurrent executions. It also doesn’t change the fact that async code is contagious, when something deep down your stack suddenly becomes async, you have to mark every caller as async as well. Also, I have some doubts about the argument that “with a good enough scheduler, everything can be made async”. I do think it’s still worth carefully considering whether a function should be async. There is probably a good balance to find, and a lot of measurements to do.

                                                                1. 4

                                                                  Async/await is more than syntax. It enables stackless coroutines, which make more efficient use of threads.

                                                                  Part of the problem with dispatch_async is that it’s quite expensive, since it requires creating a heap-allocated block. The first time I tried using it instead of locks to make a class thread-safe, I (fortunately) did some comparative profiling and backed out that change in a hurry.

                                                                  Contagion is real, but I think it’s less of an issue when there’s much less runtime and syntactic overhead to making a function async.

                                                                  1. 7

                                                                    it requires creating a heap-allocated block

                                                                    So does async/await in most implementations I’ve seen. You still have local variables. If you’re going to have stackless coroutines, those variables need to exist somewhere in memory, right? That somewhere is on the heap.

                                                                    1. 4

                                                                      Afaik in rust you only allocate on the heap once for a full “task” (comprising many futures, which are translated by the compiler into an enum representing the state of a state machine). So you don’t have one allocation per future + one allocation per callback on that future. https://aturon.github.io/blog/2016/08/11/futures/ and following posts explain it much better than I can hope to do myself.

                                                                      1. 3

                                                                        Dammit, you’re right. I’d overlooked that. (But c-cube’s reply implies this can be optimized a lot, which is good.)

                                                                        1. 4

                                                                          In most cases, the optimizations still don’t make up for the high costs associated with distributing work to executor threads, handling communication around scheduling, and stitching results back together. This is well illustrated with the Universal Scalability Law. async is a very sharp tool that only has a couple use cases where the performance actually is improved in Rust, but the downsides are always severe in terms of additional bug classes related to accidental blocking, additional compiler errors due to requiring anything in-scope to be Send if it survives across a suspension point, additional compilation time as large trees of async-specific dependencies are pulled in, etc.. etc… etc… it really eats into the amount of energy that engineers have left to actually be productive, and as a result the async Rust sub-ecosystem suffers from significant performance and quality issues that simply can’t compete with non-async implementations that are not hampered by these costs during their development.

                                                                          Like many things in computing, it’s not popular because it’s good, it retains users because of the social connections people form while compensating for its badness. As humans, we avoid acquiring information that could cause us to lose contact with a social group which manifests as async users either never comparing performance to threads or acting like they hadn’t seen any information at all when their tests show them that async makes things worse.

                                                                      2. 3

                                                                        Contagion is real, but I think it’s less of an issue when there’s much less runtime and syntactic overhead to making a function async.

                                                                        Isn’t the async-contagion cost the issue of “two versions of everthing”? (What colour is my function)

                                                                        Isn’t this the big idea of golang?

                                                                        There is no async contagion. But you get the benefits.

                                                                        Coroutines are managed by passing first class objects around (channels), which are lexically scoped so you know which routine is yielding to which.

                                                                        OS-level blocking is managed by the runtime so you pretend to write straight-through code but if you call read() then things are managed so that you don’t block anything else.

                                                                        1. 5

                                                                          Goroutines require custom stack management, which has a high cost in complexity — it took the team many years and two entirely different implementations to fix performance problems. The custom stacks also create interoperability problems with other languages, since the stacks have unusual behaviors like growing on demand and relocating(!). It also creates problems calling out into other-language code that can block, since you don’t want to block the goroutine scheduler.

                                                                          Also, all those stacks increase memory usage. Zillions of goroutines doing a task are potentially carrying around a zillion deep stacks.

                                                                          Channels are a nice feature but they’re really awkward to use for coroutine / actor implementations; I’ve tried. You have to write a lot of boilerplate to serialize and deserialize the messages, and it ends up being pretty expensive.

                                                                          1. 2

                                                                            Do you know of any good articles about how the Go project solved these issues, and what they were, exactly?

                                                                            1. 2

                                                                              Something’s here: https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub

                                                                              via: https://github.com/golang/go/wiki/DesignDocuments (Contiguous Stacks)

                                                                              for newer design docs, see also: https://github.com/golang/proposal

                                                                              Personally I’m not tracking the proposals since long ago, so I don’t have any idea if more happened since the doc I linked first above, which was around Go 1.3…

                                                                              1. 1

                                                                                Thanks for the links! Definitely worth a read

                                                                            2. 1

                                                                              Also, all those stacks increase memory usage. Zillions of goroutines doing a task are potentially carrying around a zillion deep stacks.

                                                                              I thought this was again a selling pt of golang. goroutines are generally cheap?

                                                                              https://tpaschalis.github.io/goroutines-size/

                                                                              On a mid-end laptop, I’m able to launch 50 million goroutines.

                                                                              It may be possible to arrange things so that an app has many deep stacks, but it’s not a case I’ve heard people coming across in practice.

                                                                              Channels are a nice feature but they’re really awkward to use for coroutine / actor implementations; I’ve tried. You have to write a lot of boilerplate to serialize and deserialize the messages, and it ends up being pretty expensive.

                                                                              I agree channels are cumbersome. I think this is likely to be due to the lack of higher level helpers, which I hope/expect will be addressed once go2 lands generics.

                                                                              Having routines to handle fan-out, actor idiom etc genericised on “chan T” should help a lot with channel ergonomics I think.

                                                                              It also creates problems calling out into other-language code that can block, since you don’t want to block the goroutine scheduler.

                                                                              That’s an argument for all languages, including golang. If you block a thread in another language, the golang scheduler can’t help you. But that kind of proves the point - in golang, that’s a real win?

                                                                            3. 2

                                                                              Java’s Project Loom is another try at providing concurrency and parallelism without dividing the world in two. Time will tell if it succeeds!

                                                                      1. 3

                                                                        Definitely:

                                                                        • Continue working through the last editing pass of “Crafting Interpreters” before I typeset it. It’s moving along fairly quickly, though it’s still a lot of text to grind through. Should have written a shorter book!

                                                                        • Writing postcards for “Reclaim Our Vote” to encourage people who might have been disenfranchised to be able to vote.

                                                                        Aspirationally:

                                                                        • Enjoying the hopefully smoke-free cool air after last week’s utterly miserable hot/muggy/smoky weather.

                                                                        • If I find the time, assembling the Electrosmith 3340 VCO DIY kit I got last week.

                                                                        • Maybe noodling on the FM synth for a fantasy console I started tinkering on again.

                                                                        • Watching TV with the wife. Currently Sampson Boat Co’s YouTube series rebuilding Tally-Ho (amazing and very good for my mental health) and “Lovecraft Country” (good but sometimes a little heavy and too relevant given 2020 context).

                                                                        • Playing Super Smash Bros with the kids. The day my oldest can consistently beat me is the day she graduates to full tween-hood and loses all respect for me. So far that day has yet to arrive.

                                                                        Mostly, just trying to survive the dumpster fire that is USA 2020 with some level of sanity intact.

                                                                        1. 2

                                                                          Excellent. Crush the children. Let them know just what kind of man their father is.

                                                                          On a lighter note, when will they announce the next damn DLC character?!

                                                                          1. 1

                                                                            Oh, no. I didn’t even realize there was DLC for Super Smash Bros.

                                                                            1. 1

                                                                              Did I misunderstand and you are playing the n64 original? Or are you playing ultimate? If the later, they are actually on their second DLC. :)

                                                                              Actually if you were playing the n64 version people are working on putting new characters in it:

                                                                              http://n64vault.com/ssb-characters:smash-remix

                                                                              They apparently released Bowser recently:

                                                                              https://youtu.be/CvXZ6d9aUUg

                                                                              1. 2

                                                                                I’m playing Ultimate on the Switch. I just try to not pay attention to stuff like DLC.

                                                                        1. 6

                                                                          My goal is to write something that isn’t tied to technology. These days I write a lot but it’s mostly about coding. At university, I wrote and published fiction, essays, and poems. I miss it.

                                                                          Otherwise:

                                                                          • Catching up with internet friends
                                                                          • Working on a mini-golf game in Unity (personal)
                                                                          • Building things for the web (work)
                                                                          • Perhaps a little code golf too
                                                                          1. 2

                                                                            One of my goals as well. I would love to do some novel-length hard sci-fi.

                                                                            While I’ve done a ton of writing, novels seem like another thing entirely. For some reason, writing a sci-fi novel seems orders of magnitude harder than writing the equivalent code.

                                                                            1. 2

                                                                              I don’t about orders, but I do think a novel is about an order of magnitude harder than equivalent amount of code.

                                                                              With well-factored code, the goal is to minimize coupling between different sections, so the effort to create a codebase is ideally roughly linear in the size of the codebase. The greater the connections there are between disparate parts of the codebase, the more you get bit by Metcalfe’s law. With heavy coupling, the amount of code you have to touch grows with the square of the size of the codebase.

                                                                              A novel, by design, is very heavily coupled. Readers delight when there are no loose ends, when subplots weave together and reinforce main plots, and when there are no plot holes. That implies to me that the effort to write a novel is likely quadratic in the size of the text.

                                                                              If that’s too overwhelming, start with short stories. An anthology of those is easier than an equal-length novel. :)

                                                                              1. 1

                                                                                I would pick a good short-story over a bad novel any day. Maybe you can write something like Ray Bradbury’s The Martian Chronicles, ie. a collection of related short stories.

                                                                            1. 18

                                                                              I think it’s worth pointing out that Wren is made by the creator of crafting interpreters. Perhaps that’s a little bit of an argument to authority, but the author clearly knows a lot about creating languages.

                                                                              1. 4

                                                                                I’ve followed the second part (bytecode VM implementation) of this book in C++ and I can say that it’s been one of my favorite project-style book walkthroughs in a while so far! Good combination of learning low level things and also learning parsing stuff at the same time, in a very pragmatic way. I think the information is also very relevant to current-day systems, since they are often usually running such a VM somewhere or the other.

                                                                                edit (and maybe tangential): Godbolt link for what I’ve done so far: https://godbolt.org/z/5GbhnK I followed till control structures then did the nan-tagging bit and added ‘indirect threaded’ dispatch, it actually comes out to be competitive for arithmetic-loop benchmarks with other real (JIT-off) VMs (included times for benchmarks vs. Lua{,JIT}, v8, …). I’ve been interested in building out a VM that doesn’t (or rarely/differently) does GC (eg. if it’s just for a per-frame rule in an ECS-y game, it does some logic and calls system functions to save out data–so mgmt of layout and lifetimes of longer-term data is in the ECS in the native lang, or described elsehow (scene editor tool / ….)) and has easy interop with C struct type memory. SPIR-V is an interesting format in this space too (it’s cool that you literally define types upfront with eg. OpTypeVoid and OpTypeStruct then can do eg. OpAccessChain…).

                                                                                1. 3

                                                                                  Nystrom is also one of the main guys behind Dart (and a good twitter follow to boot).

                                                                                  1. 24

                                                                                    I wouldn’t describe myself as one of the “main guys”. I was not one of the original language designers and only joined the language team as a full member much later. I’m just higher profile because I wrote more stuff down and use Reddit and Twitter more. :)

                                                                                    1. 1

                                                                                      Is there a chance of the printed book being under a Christmas tree in 2020? ;-)

                                                                                      1. 2

                                                                                        I would love that to be the case, but it seems unlikely. I’m making steady progress on the last editing pass and the typesetting, but it’s a big project and 2020 is not exactly playing nice with anyone’s goals.

                                                                                  2. 2

                                                                                    I loved the second part, and it enabled me to write a small VM + “compiler” in rust for a proof language I’m working on, in a few thousands lines (although it uses fixed size instructions, à la lua, rather than pure stack instructions). I found the book very interesting and well written, kudos u/munificent !

                                                                                  1. 13

                                                                                    It has become difficult for me to avoid the suspicion that this class of complaint is another way of saying that semver often doesn’t work very well in practice.

                                                                                    1. 18

                                                                                      I think it does work well in practice, for packages that practice it. I think a lot of people still have this “only want to increment the major version for big stuff” mindset as opposed to “major version just denotes breaking changes and it’s okay if we’re releasing version 105.2”.

                                                                                      1. 4

                                                                                        And for packages which can practice it. Many packages can’t change anything without altering previous behavior. It’s hard to think “people might depend on this bug, so it’s a breaking change.”

                                                                                        1. 2

                                                                                          I was thinking about this recently too… normally you would think of adding a new function as being a minor change - not breaking compatibility but not just an internal fix either..

                                                                                          But, on the other hand, if you add a new function, it might conflict with an existing name in some third party library the user also imports and then boom they have a name conflict they must resolve.

                                                                                          So you could fairly argue that all changes are potentially breaking changes…

                                                                                          1. 5

                                                                                            Isn’t this why namespaces are a thing?

                                                                                            1. 3

                                                                                              Not in languages like C, which still does have libraries.

                                                                                              1. 2

                                                                                                They’re a thing but there are frequently ways to have this problem anyway

                                                                                                E.g.

                                                                                                 from dependency import *
                                                                                                

                                                                                                in python. “Don’t do that” is fair to say, but if somebody downstream already has they have to deal with fixing the ambiguity.

                                                                                                You can have subtler versions of this for example in C++ ADL can bite you:

                                                                                                int foo(tpnamespace::Type v) { ... }
                                                                                                

                                                                                                if your dependency later adds a function named foo in their namespace the meaning of

                                                                                                foo(...)
                                                                                                

                                                                                                in your program may change.

                                                                                                A world where every identifier is fully qualified to avoid running into this after an upgrade starts to look similar to a world with no namespaces at all.

                                                                                                1. 1

                                                                                                  This is precisely it, you can import all and get conflicts. In the D language I use, you can do it with decent confidence too: the compiler automatically detects it and offers ways to very easily specify it (you can just be like alias foo = mything.foo; to give it priority in this scope, among other things).

                                                                                                  But nevertheless, if the conflict happens in a dependency of a dependency because one of its dependencies added something… it can be a pain. Some unrelated change caused a name conflict compile error that is halting your build.

                                                                                                  (of course personally I say the real wtf is using dependencies with dependencies on dependencies. but meh)

                                                                                          2. 3

                                                                                            I think a lot of people still have this “only want to increment the major version for big stuff”…

                                                                                            This has been my experience as well. Forcing a major increment for breaking changes has a secondary benefit in that it encourages developers to think hard about whether they actually need to break an API, or can judiciously deprecate to provide a smooth path forward.

                                                                                          3. 11

                                                                                            I would like to point out that you’re far less likely to come across a blog post that says “I’ve been using SemVer for the past several years and it’s been working very well in practice”. SemVer is probably one of those things that, when it works, you get to not think about it much and carry on with whatever it was you were actually trying to do.

                                                                                            1. 4

                                                                                              This class of complaint is part of how the system works in practice.

                                                                                              Semver is basically a way of managing expectations between API producers and consumers. Complaining when API produces don’t follow the stated guidelines is part of the feedback loop to maintain consensus about what changes are allowed.

                                                                                              1. 2

                                                                                                Exactly. The only other thing I would add is something about scale in terms of the number of independent people working on independent projects that can be combined together in any one of a number of ways. Or in other words, a lack of centralization.

                                                                                                If the scale problem didn’t exist, then I absolutely would not want to deal with semver. But to some extent, the problems with semver are the problems with communication itself.

                                                                                            1. 4

                                                                                              Lately, I’ve been feeling more and more that one of the fundamental choices around what you sink your time into is where it falls on any of these mostly equivalent continua:

                                                                                              • Type 1 fun <-> type 2 fun
                                                                                              • Process <-> product
                                                                                              • Journey <-> destination

                                                                                              Basically, do you experience the reward during the doing, or after in the having-done. Relaxing in a warm bath is purely the former. There is no great sense or reward or pride after you take a bath. You extracted all the joy you are going to get out of it while you were in the tub. Conversely, cleaning out your garage is almost all latter. It’s dirty, hot, there are spiders. It’s not fun. But it feels amazing to gaze upon your neat, organized garage afterwards.

                                                                                              The author argues that we can (or perhaps should) prefer work that is the latter. Where the job ain’t fun but what you get out of it makes it worth it. This is a fine moral stance, but I think it’s important to understand what your own motivations are before you pick a point on the spectrum.

                                                                                              Personally, I’m happiest somewhere in the middle. I get bored and feel like I’m wasting my time if my work doesn’t affect anyone else in a positive way. But I’m miserable if I don’t feel like I used my brain in an enjoyable way during the day.

                                                                                              1. 11

                                                                                                So if you want to discuss fundamental differences you can pretty much only point out that dict values are accessible by keys, which could be of any immutable type, while list values are indexed with integers. That’s it :-)

                                                                                                You can’t insert arbitrary keys into a list. You have to “insert” (append) in key order. That seems like a pretty fundamental difference to me!

                                                                                                1. 5

                                                                                                  Yes, and in particular, if you insert an element into the middle of a list, all of the “keys” of the subsequent elements spontaneously change. Not very map-like!

                                                                                                1. 11

                                                                                                  It’s a good read, and it’s good to hear that (some) developers are focussing on improving this.

                                                                                                  Slow compile times are one of my major pain points with GHC/Haskell, and I’ve been confused in the past by how little most Haskellers see this as a problem. There seems to be a strong self-reinforcing effect here, where a slow compiler means you lose people who care about compilation speed.

                                                                                                  1. 17

                                                                                                    There seems to be a strong self-reinforcing effect here

                                                                                                    This is a really common failure mode I see in software product evolution. If you do “design by addressing complaints” then you may satisfy existing users, but fail to fix fundamental things that cause people to not show up at all. It’s form of survivorship bias where you end up putting armor on the fuselage instead of on the engines where you should.

                                                                                                    It takes real effort to get information out of the users you don’t have because they have less incentive to bother communicating with you, but it’s vital if you want to grow a userbase.

                                                                                                    1. 0

                                                                                                      An interesting but exhausting read; when the author writes

                                                                                                      Too many tired metaphors in this section. Sorry about that.

                                                                                                      he’s absolutely right. I wonder why the author kept all this stuff if he realized it’s an issue. It’s also not just the metaphors – something feels really off about the writing style, but I can’t pin-point it.

                                                                                                      I experienced the self-reinforcing effect not with compile-times, but with documentation/beginner friendliness in Scala; this effect definitely exists.

                                                                                                      (Languages with bad documentation largely attract people who don’t care about good documentation, so documentation never improves.)

                                                                                                    1. 4

                                                                                                      I’m tinkering on a virtual console. Sort of like PICO-8, but more 16 bit and with something more akin to an IDE. It has a custom language designed entirely around this use case. It’ll probably fizzle out before it goes anywhere, but it has been ludicrously fun implementing my own little code editor from the pixels up.

                                                                                                      1. 8

                                                                                                        If you haven’t come across it, I also highly recommend Bob Nystrom’s book Crafting Interpreters, available for free. It has two parts: first he goes over building a tree-walking interpreter in Java then he goes over building a bytecode compiler & VM in C.

                                                                                                        This second part is still a work-in-progress but he’s kept a strong pace, last chapter was released about a week ago.

                                                                                                        Thank you for the great write up. I’m on a similar learning path and I really enjoyed it and got me excited to write my own compiler as well!

                                                                                                        1. 6

                                                                                                          I’m hoping to get the chapters done by the end of 2019. If you’re impatient, all of the code for the entire book is already done. (In fact, I wrote all of the code and carefully split it into chapters before I wrote the first sentence of prose.)

                                                                                                          You can see it all here: https://github.com/munificent/craftinginterpreters/tree/master/c

                                                                                                          1. 2

                                                                                                            Thanks! I had briefly noticed Crafting Interpreters before, but I’m glad to hear it’s worth a second look.

                                                                                                            Thanks for the kind words, and I hope you will continue on your journey!

                                                                                                          1. 37

                                                                                                            I’m no longer excited by the technology for it’s own sake. I couldn’t give a shit how many serverless functions your bespoke kubernetes cluster manages, or how simple your webpack configuration is.

                                                                                                            I find work that matches my ethics; at the moment I’m lucky enough to support radiopaedia.org. We get regular letters from around the world detailing cases where the site has helped save a patient or markedly improve their health, which is always a morale boost.

                                                                                                            What is there that’s genuinely interesting and exciting in the world of software, and what was your way of engaging your interest and excitement?

                                                                                                            Software systems get used to plan large-scale infrastructure projects, keep track of clean drinking water, food production & distribution, and healthcare. Being aware of the positive outcomes my work generates has become key to enjoying it.

                                                                                                            1. 24

                                                                                                              Some (mostly unfiltered) thoughts on this:

                                                                                                              This all sounds very familiar. In fact, I resigned a few weeks ago with no new job lined up as I felt my entire job was just useless. Everything gets rewritten every year or so anyway, so why bother?

                                                                                                              I was rewriting some of the same code I rewrote when I started. When I joined a lot of stuff was objectively bad; for example a lot of the email handling code was so bad a lot of emails simply didn’t get delivered, or incoming emails wouldn’t get accepted (it was written by someone who didn’t understand email). So my refactors served a clear purpose: “don’t drop emails”, “make sure emails are RFC-compliant”, etc. I then refactored things to add some features (“more details logs”, “ability to re-send delivery failures”, etc.) Again, refactors to enable a concrete goal.

                                                                                                              Later on, we did some refactoring to make stuff compile faster; it was taking upwards of 30 seconds for even simple changes, and it was pretty annoying. This involved rewriting quite a bit of our API, and that took maybe 2 months in total. I’m not sure if it was worth it in hindsight, but at least it had a clear concrete goal (“make it compile faster”), which was measurably achieved. It did make working with the code more pleasant, as waiting 30 seconds for a simple type is no fun at all (fast compile speeds are supposed to be a feature of Go!)

                                                                                                              But now, I see people rewrite stuff because “it’s more elegant, “it had better layers”, or “this is the best way to do it according to {person,methodology,religion,…}”, which are all really just rephrasing of “I prefer it this way”. This doesn’t mean the new way is bad per se, sometimes I think it’s probably a better approach too, but … the “old” way is working, and often has been working for quite a while. Why rewrite it? “I prefer it this way” is not a concrete goal. What is gained with the rewrite? Often this isn’t clear, and at the same time there’s still the increased workload. Even if you’re not involved in the rewrite directly, you’ll still have to learn the new API and/or way of doing things.

                                                                                                              This is a product to solve concrete problems for our customers. The code to achieve that isn’t some sort of art project.

                                                                                                              Yet, many people seem to treat code as an art project. Now, I treat some of my personal projects as “art projects” – and I learned a lot from doing that – but when building software in a team of people that’s just not workable, every time someone new joins the “art project” needs a re-evaluation because it doesn’t fit their sense of aesthetics.

                                                                                                              Software is easy to change. This is great in some ways, but it’s also easy to fall in to the trap of constant change. If you build, say, a bridge of building you can’t just change it at a whim, even if it has serious problems such as lack of daylight or airflow (far too many office buildings suffer from this), so people accept that the world is imperfect, suck it up, an deal with it the best they can. But in software it’s tempting to say “no, I can make the world a better place! I just need to rewrite [..]!” Sometimes that is the correct approach, but often times it’s not. Especially not if you’re in a team. It’s very hard to actually prove something is “better” in the world of software, so the endless battles/bikesheds start.

                                                                                                              This isn’t just a software dev problem, it’s also a management problem in the company. But I don’t see that changing, so I just quit.

                                                                                                              If it was just this company I’d find a different job, but it’s a pattern I’ve seen in many places in my 10-year career. This is not a new observation, either: CADT, Magpie developer, etc. are all phrasings of this problem.

                                                                                                              I don’t know what I’ll do next; maybe I’ll just go jwz and open a bar or something. I really like building software products, but am thoroughly fed up with the industry. Everything feels like a battle, and I’m too tired of it. It might be worth it if I felt the end-result is worth it, but it’s just regular B2B software. Not the worst in the world, but nothing special either. There are a whole bunch of competing products that do an equally good job (if not better).

                                                                                                              1. 12

                                                                                                                If it was just this company I’d find a different job, but it’s a pattern I’ve seen in many places in my 10-year career. This is not a new observation, either: CADT, Magpie developer, etc. are all phrasings of this problem.

                                                                                                                Every time I’ve seen this happen, it’s at a organisation that has money far in excess of its costs (unfortunately, this happens pretty often in b2b software).

                                                                                                                This enables middle management to start empire-building / hiring for projects of dubious value. You can fight it in the early stages by having a suitably aware CEO (eg 37signals / basecamp) but as you get to larger organisations, most roles fit this description.

                                                                                                                Once you have more developers than you need to solve the problem, you start stepping on each others toes and spending all your time communicating; before you know it, there are four teams building microservices (to reduce the communication overhead) to solve a problem that only needed one team of 3-5.

                                                                                                                You can avoid this by finding a place that either lacks excess money, or has somewhere to sink it. Basecamp sink it into high engineering salaries and dividends to owners; radiopaedia can only afford me part-time, but can hire me for more hours if they get more money.

                                                                                                                1. 5

                                                                                                                  There is a saying that if everybody are morons, you are the moron. (For clarity, I don’t believe you are a moron, you seem bright).

                                                                                                                  Could something similar be said of battles? If everything feels like a battle, does it come from within?

                                                                                                                  1. 4

                                                                                                                    Okay, some more mostly unfiltered thoughts (I guess Lobsters is my weblog now?)

                                                                                                                    That’s not unreasonable, and I’ve been thinking about that for quite a while during the last few months (even before I resigned). There is an easy solution to it: shrug, don’t care about anything that happens outside of the narrow scope of the job I was hired for, do my boring job for a few hours, and collect the paycheck.

                                                                                                                    But that’s not really how I work. In many companies there’s a lot of stuff “between the cracks”, stuff where there’s no person/team who has a clear responsibility, but really should get done. I tend to do a fair amount of work “in between the cracks” as that’s often pretty valuable for the business. Example: I wrote standard scripts for our Travis integration, because that’ll save everyone a lot of time so they won’t have to ad-hoc the .travis.yaml files with random copy/pasting. I spent a day on it two years ago and while hardly perfect, it’s been working pretty well since then. Yet I’ve had to deal with a ton of bikeshedding and headaches about it. Some of the feedback has been reasonable and constructive (great), but there’s also a lot of “change for the sake of it”, and some downright toxic stuff (like the guy that just overwrite it all several times with his own version without prior discussion, often getting a few key things wrong).

                                                                                                                    Perhaps the worst part if that all the bikeshedding and toxic idiocy made me shoot down a more reasonable proposal that someone made a few months ago. The PR did have a bunch of issues and needed quite a lot of work, but fundamentally it was a good effort as it attempted to address various real concerns (and was’t a “I don’t like the way it’s done” type of rewrite). The entire thing was eventually amicably resolved, but being in the state where I growl at things because I’m tired of bikesheds and toxicity being flung at me is not a place I want to be at.

                                                                                                                    To be clear, the problem isn’t “everybody”, it’s just that there are a few people who have very strong visions on the One True Way™ how to do things and will push that vision with little sense to pragmatism. A lot of people think that’s somehow normal, so these people can do what they want (some of these people are also very toxic).

                                                                                                                    As I briefly mentioned, this is just as much of a management fail as anything. Ideally, management should have nipped a lot of this nonsense in the bud and fired a lot bunch of these people (some of the more toxic ones have).

                                                                                                                    Some examples: I wrote our internal Go framework; this wasn’t a “invent a framework from scratch” effort, but more “codify common practices our existing projects already use, while making sensible ROI improvements”. The end results is pretty decent, if I say so myself. Yet, no one uses it, as it doesn’t fit the One True Way™ for any of the teams. The result is that we now have 6+ “frameworks”, all based in varying degrees on the original. There is loads of duplicated effort here. I tried very hard to accommodate people’s concerns, but there was a lot of “I don’t like it”-ism and people just went of in their own direction anyway 🤷

                                                                                                                    I don’t even have strong opinions. I just care about 6 teams not duplicating all effort to produce a Go API. Not unreasonable, right? But now we’ve got all that duplicated effort. Worse, some of these efforts are just … not very good. We’ve had two unreleased apps that already had to undergo a massive rewrite before release because the re-invented stuff sucked too much, but is being ignored “because I don’t like it”. I get that new apps sometimes need to take risks and experiment, and that some of these risks don’t work out, but this isn’t rocket science, this is basic CRUD APIs. We already invented all of that 2 years ago.

                                                                                                                    I’ve been working on a weblog post about all of this for a while, but I find it hard to articulate my feelings accurately, because when described like above it doesn’t necessarily sound like a huge deal. “So no one uses your framework, deal with it!” In part, it’s a “death by a thousand cuts” affair, this is just one example. There have been a lot of pushes to rewrite/redo existing systems without a clearly stated goal. Seeing a lot of your work being rewritten all the time has a certain psychological effect. Why bother if everything will be rewritten next year, anyway? There was also a good HN comment on that last week.

                                                                                                                    I’m also one of the few that actually takes the effort to push back on all of this. A lot of people seem to shrug in apathy, or they just don’t do anything because they don’t want to spend the effort to get involved. Turns out that actually caring about making a good business, and not just doing the job you were hired for, can burn you down. I’m “just” a developer, I don’t really have more authority than anyone else. In hindsight, I should have either pushed for more authority, or tried harder to get those in authority aboard. Being remote while ~75% of the company is in an office probably doesn’t help either, especially not after I moved to New Zealand which put me in a massively different timezone (main office is in Ireland).

                                                                                                                    Part of this is just growing pains from small startup to company with >250 people. When I joined stuff worked pretty well without any direction, as a lot of people were very pragmatic and dedicated. Now that’s we’ve increased the amount of staff by a lot, things are more tricky. I guess I could work to change the culture, but after 3 years I feel burned out and to be honest, our products aren’t all that great and not really sure if it’s worth is trouble.

                                                                                                                    1. 2

                                                                                                                      What you’re describing here sounds like a bad mismatch between the level at which you care and the level of authority you hold. Plus probably. the proportion of payoff you stand to receive if you do succeed.

                                                                                                                      Put another way: if you’re high up enough in the organisation that you could fix it, it might be your responsibility. If you’re not senior enough to e.g. be able to order people to knock bad behavior off, then by definition it is not your responsibility.

                                                                                                                      Please don’t get emotionally invested in a company of which you are not a large-stake shareholder. It is IME a recipe for getting burned out hard.

                                                                                                                      1. 3

                                                                                                                        I suppose you’re not wrong, but on the other hand apathy and not caring is also quite toxic, IMHO.

                                                                                                                        1. 2

                                                                                                                          Sure, don’t start casually keying peoples’ cars on the way in or whatever. Care about your work. Don’t try to fix things that are your boss’s (boss’s) job, though.

                                                                                                                2. 26

                                                                                                                  I’m no longer excited by the technology for it’s own sake. I couldn’t give a shit how many serverless functions your bespoke kubernetes cluster manages, or how simple your webpack configuration is.

                                                                                                                  Here’s why this is so correct: being excited by technology is a surefire way to be disappointed in life.

                                                                                                                  1. 20

                                                                                                                    This kind of sentiment confuses me, especially given the context of this community. If working at a job that matches your ethics is what does it for you, then that’s amazing! We need more people like that around to make the world a better place.

                                                                                                                    But disparaging people for being excited about technology is odd, to say the least. There’s something intrinsically satisfying, at least to some people, about learning new things, understanding the context in which that thing is (or is not) useful, and why it is (or is not) more useful than the old way of doing things. Do you think a mathematician being excited about mathematics for its own sake is a surefire way to be disappointed in life?

                                                                                                                    Treating your software like a craft and always striving to be better is a great way to enjoy what you do. A carpenter isn’t diminished by making tables for whoever happens to want to buy them, they can enjoy their work intrinsically as they masters their craft and take satisfaction in a job well done. Obviously this can be complicated by the reality of working with other people who may not treat it the same way, but… that’s how people work, and that problem exists in any field or career.

                                                                                                                    1. 20

                                                                                                                      But disparaging people for being excited about technology is odd, to say the least.

                                                                                                                      If you get excited about technology, it’s much more meaningful to get excited about how a technology could help people, not about the technology on its own, which most of the time is going to be deployed to sell more ads or perform more effective surveillance.

                                                                                                                      1. 7

                                                                                                                        it’s much more meaningful to get excited about how a technology could help people, not about the technology on its own

                                                                                                                        There is a certain irony to this comment coming from someone with the username “technomancy” whose description links to their blog about their custom-made personal keyboards. :)

                                                                                                                        One way to help people is to not criticize their internal motivations simply because they don’t align with yours. If someone gets home at the end of the day and feels great for no other reason than that they got to write a bunch of code and they love how writing code makes them feel, more power to them.

                                                                                                                        It might be more meaningful to also help other people with your tech, but that has its downsides. When you hang your satisfaction on someone else’s joy, you give others control over your own happiness. You sacrifice the freedom to feel good about something you did just because they happened to not like it.

                                                                                                                        Each of us is free to find our joy however we like.

                                                                                                                        1. 8

                                                                                                                          coming from someone with the username “technomancy” whose description links to their blog about their custom-made personal keyboards. :)

                                                                                                                          On the contrary, the reason I have continued to make custom keyboards after all these years is precisely that; it helps people. The keyboards allow my customers to avoid RSI and learn some useful DIY skills. I wouldn’t still be doing it otherwise.

                                                                                                                          If you look at my comment in context, I’m replying to a post that is explaining why the original poster no longer feels motivation to work in software. If you don’t feel like they do right now, that’s great, but the odds are very good that at some point in your life you will if you’re working in the technology industry.

                                                                                                                        2. 4

                                                                                                                          Genuinely wondering how you feel about this:

                                                                                                                          If you get excited about mathematics, it’s much more meaningful to get excited about how mathematics could help people, not about mathematics on its own, which most of the time is going to be used to sell more ads or perform more effective surveillance.

                                                                                                                          1. 5

                                                                                                                            which most of the time is going to be used to sell more ads or perform more effective surveillance.

                                                                                                                            This isn’t actually true for mathematicians as far as I know? I mean, if you’re a statistician working for an ad company, then sure; it seems to hold up fine, but as far as I know most mathematicians aren’t.

                                                                                                                            1. 1

                                                                                                                              The “most of the time” probably isn’t (I personally think definitely isn’t, but no data no certainty), but if you’re a mathematician working on something just because it interests you, there is a chance still that someone might find a use for it in ways that you didn’t think about, including ads and surveillance. What I was wondering about phrased directly is basically, whether these two questions have different answers for you:

                                                                                                                              Q1: Is it meaningful for a mathematician to work on some mathematical structure that interests them, without any foresight of a meaningful use of their work?

                                                                                                                              Q2: Is it meaningful for a programmer to work a on a technology that interests them, without any foresight of a meaningful use of their work?

                                                                                                                              where meaningful is relative to you personally.

                                                                                                                            2. 2

                                                                                                                              Mathematics is discovered. Technology is built.

                                                                                                                              When you discover new mathematics, nobody owns the math.

                                                                                                                              When you build technology for an employer, somebody else owns the technology.

                                                                                                                              That means:

                                                                                                                              • Your work can be destroyed by someone else without you getting a say (eg the project discontinued by management)
                                                                                                                              • Your work can be redirected to only be used in ways you disapprove of.
                                                                                                                              1. 1

                                                                                                                                Mathematics is discovered. Technology is built.

                                                                                                                                This statement is in my opinion too general to have any useful meaning or validity.

                                                                                                                                I however find your distinction between discovery and invention (building) interesting, so I’d like to ask you a question. Consider a new real world programming language L. It would probably be very easy to argue that L was invented. Assume now that a user of L stumbles upon a quirk in the way L handles closures for example. Is this quirk an invention or a discovery?

                                                                                                                                1. 1

                                                                                                                                  The quirk is in an implementation; it was invented by the language creator and discovered by the user.

                                                                                                                                  1. 1

                                                                                                                                    What about the behavior of numbers? why isn’t that an implementation detail? if numbers are too natural for you then what about the behavior of sequences of numbers? doesn’t that seem a bit closer to an implementation detail?

                                                                                                                                    1. 1

                                                                                                                                      Whether numbers are an implementation detail is a question for theology 😀. Human understanding of them is a discovery.

                                                                                                                                      1. 1

                                                                                                                                        Whether numbers are an implementation detail is a question for theology

                                                                                                                                        Hehe, I was actually heading in the direction that numbers are defined by humans and not by any divine entity and thus the way they behave is maybe just an implementation detail of how we defined them;)

                                                                                                                          2. 8

                                                                                                                            But disparaging people for being excited about technology is odd, to say the least.

                                                                                                                            My intent was not to disparage and I find that reading to be very odd. All I’m saying is that if you focus on technology as your source of excitement in life you are setting yourself up for disappointment. This does not mean you are a lesser person for liking it.

                                                                                                                            Treating your software like a craft and always striving to be better is a great way to enjoy what you do.

                                                                                                                            I take great pleasure in writing software, making keyboards and other such things. I truly enjoy it and I always want to improve. But that is not technology. Technology is just a vehicle for that kind of growth. The technology itself may be interesting and I may like it, but I certainly don’t like it just because it’s technology.

                                                                                                                            According to the life expectancy measures, I have one foot in the grave (that is, I’m past the halfway point). I grew up in the personal computer revolution and was an adult when the Internet took off. I’ve heard a lot of promises of what technology will do and how it will change things. Only one thing has ever been consistent: it does change things (corollary: we’re terrible at predicting the future). It does this for both good and bad, and rarely in the ways you hope. I used to look for the new thing all the time. I don’t anymore and I’m happier for it.

                                                                                                                            The joy I get from technology is understanding it and using it so that I can do things or better yet, how it gets used to help people. I don’t get excited about AI/deep learning, for example, I get excited about the thought of learning how it works and maybe using it to help me with my extensive collection of papers. At the same time, I think the adtech world is nothing short of a blight on humanity and have zero respect for it. As such, I would never work in it, regardless of what AI techniques they use. Being excited about AI for the sake of technology, in this case, would cause me great inner conflict and thus, disappointment. To avoid these situations, I no longer seek happiness in technology.

                                                                                                                            This is one of those topics that is hard to put your finger on and honestly, I don’t think I’ve quite captured it here. I apologize for that. At the same time, I can’t deny that a lot of my friends, just like me, used to be thrilled about new technological innovations, saying things like “Wow! That’s awesome!” or “It’s just like in the movies!”. Now we say, “Maybe a Earth-level EMP pulse isn’t such a bad idea.”

                                                                                                                            1. 2

                                                                                                                              My intent was not to disparage and I find that reading to be very odd. All I’m saying is that if you focus on technology as your source of excitement in life you are setting yourself up for disappointment.

                                                                                                                              Not if they die tomorrow. Sorry for the strong statement, but I just wanted to provide at least one counter example.

                                                                                                                              People are different, maybe as programmers we need to resist the urge to generalize more than other humans.

                                                                                                                              1. 2

                                                                                                                                I wasn’t generalizing so much as playing the odds. (And yes, there are plenty of counter examples. But it’s also not a cut and dried kind of argument, which is kind of the point.)

                                                                                                                                1. 2

                                                                                                                                  Fair enough, I personally share your sentiment. Thanks for your explanations, you’ve certainly put it in a way better than I could’ve.

                                                                                                                              2. 1

                                                                                                                                This is one of those topics that is hard to put your finger on and honestly, I don’t think I’ve quite captured it here. I apologize for that. At the same time, I can’t deny that a lot of my friends, just like me, used to be thrilled about new technological innovations, saying things like “Wow! That’s awesome!” or “It’s just like in the movies!”. Now we say, “Maybe a Earth-level EMP pulse isn’t such a bad idea.”

                                                                                                                                I’d like to point out that this is the same tendency, expressing itself in opposite ways. If we had an Earth-Level EMP Pulse, people would die. A lot of people. Technologists have a hubris that says “We can do it better, just watch us” that leads to magpie development, technological innovation, and a wish to burn it all down.

                                                                                                                                1. 2

                                                                                                                                  It’s a hyperbolic statement.

                                                                                                                              3. 10

                                                                                                                                There is almost nothing new and shiny that’s genuinely interesting, in my opinion. I derive excitement from learning about new concepts and such that I haven’t previously known about–there’s plenty of that. I do not derive excitement from whatever the current hype is. Elixir? Serverless? Those just feel dull to me. They seem like a cycle: “This is the next great thing! It’s SIMPLE! And FANTASTIC!” and then those folks write software systems that, like most other software systems, suck. Everything is simple in the beginning, and everything is legacy after five years. I think that’s what Geoff was getting at.

                                                                                                                                1. 4

                                                                                                                                  I think you are describing the toxicity of the hype cycle and the shallow excitement it inspires. The target of the hype, being it yet another software framework, a music genre, or a food, is not relevant.

                                                                                                                                  Trends are almost parasitic: they chase after new idea, feed on the novelty aspect and then leave it behind.

                                                                                                                                  1. 1

                                                                                                                                    I share that, mostly. There’s one problem with this approach I’ve experienced, which is that it focuses on getting fundamentals right (good!) but disregards the importance of getting the superficial details right too.

                                                                                                                                    The reason for e.g. Go being popular is that they got so many little details right, not because it contains new concepts.

                                                                                                                              4. 6

                                                                                                                                I find work that matches my ethics

                                                                                                                                That’s a good suggestion. I think this is why I have been trying to skirt the Free Software world, because I believe strongly in the four freedoms. When I’ve gone for “open source” jobs that aren’t really open source, I’ve always been disappointed (in one, the open source was kept very much at arms’ reach to avoid “accidentally” opening the core IP; in another, I took on the role of defining our open source strategy, getting the internal lawyers and other stakeholders on board, getting buy-in from the engineers…who then didn’t open source anything).

                                                                                                                                1. 6

                                                                                                                                  Being aware of the positive outcomes my work generates has become key to enjoying it.

                                                                                                                                  This is helpful for me, thanks.

                                                                                                                                  1. 8

                                                                                                                                    Honestly, it’s hard for me to imagine any other reliable way to enjoy work, other than enjoying the company of your co-workers.

                                                                                                                                    You might get some fleeting enjoyment out of solving a particularly tricky logic puzzle at work, but in a healthy workplace there tend to be few opportunities to apply cleverness; people applying a lot of cleverness to their code on a regular basis is a sign of an unhealthy workplace.

                                                                                                                                    1. 5

                                                                                                                                      I get quite a bit of enjoyment from just solving the problems at hand in the most appropriate way. This is way more reliable for me than enjoying the company of coworkers! People come and go, have a bunch of opinions and habits, but GNU Emacs never lets me down.

                                                                                                                                      1. 12

                                                                                                                                        speaking of Emacs, I think there’s definitely something to be said for dotfiles hacking as a kind of “release valve” that allows you to express your cleverness in a way that doesn’t result in unmaintainable code for your teammates!

                                                                                                                                        1. 1

                                                                                                                                          I like that idea a lot actually.

                                                                                                                                      2. 4

                                                                                                                                        I live in the central US and I’ve met a lot of developers around here who are happy to grind away at an insurance company because it lets them provide their family with a level of comfort other jobs wouldn’t allow. The work itself doesn’t seem to give them a wholesome feeling, but being able to provide for their families does.

                                                                                                                                        This feels related, but somewhat different from your point about the work itself being directly beneficial to society.

                                                                                                                                  1. 3

                                                                                                                                    I’m blowing through The Rust Programming Language, and really enjoying it. I haven’t tried to write any Rust code yet, but I probably will at some point. Either way, it’s always fun wrapping my head around a new language.