1. 5

    Great write-up, I had no idea the REPL of lisp/smalltalk was so powerful. I need to get around to learning clojure.

    I think the elixir* REPL fits the bill for the most part - if I start up one iex instance and connect to it from another node I can define modules/functions and they show up everywhere. And for hot-fixing in production one can connect to a running erlang/elixir node and fix modules/functions on the REPL live, and as long as the node doesn’t get restarted the fix will be there.

    * erlang doesn’t quite fit the bill since one can’t define modules/functions on the REPL, you have to compile them from the REPL.

    1. 3

      Does Clojure actually have these breakloops though? I think I’ve seen some libraries that allow doing parts of it (restarts), but isn’t the default a stacktrace and “back to the prompt”?

      1. 1

        Well, prompt being the Clojure repl, but you’re correct that the breakloop isn’t implemented, as far as I got in the language. You can must implement the new function and re-execute, so you lose all of the context previous to the break. I think with all of the customizability of what happens when a stack trace happens, it’s possibly possible.

        I THINK the expected use with Clojure is to try to keep functions so small and side effect free that they are easy to iterate on in a vacuum. Smalltalk and CL have not doubled down on functional and software transactional memory like Clojure has. That makes this a little more nuanced than “has/doesn’t have a feature”.

        1. 1

          You’re correct. Interactivity and REPL affordances are areas where Clojure–otherwise an advancement over earlier Lisps–really suffers compared to, for instance, Common Lisp. You don’t have restarts, there is a lot you can’t do from the REPL, and it’s easy to get a REPL into a broken state that can’t be fixed without either a full process restart or using something like Stuart Sierra’s Component to force a full reload of your project (unless you know a ton about both the JVM and the internals of the Clojure compiler). You also can’t take a snapshot of a running image and start it back up later, as you can with other Lisps (and I believe Smalltalk). (This can be useful for creating significant applications that start up very quickly; not coincidentally, Clojure apps start up notoriously slowly.)

      1. 3

        If you notice one difference, it would probably be that commands that act on the symbol at point (e.g. cider-doc) will no longer prompt you to confirm the symbol. The old default was a mistake and I wanted to adjust this for this grand release.

        Best news I’ve heard all day! It’ll be nice to remove the override of this setting from my Emacs config.

        1. 4

          At least we have a single connector now…

          1. 18

            Arguably having one connector that is not actually interoperable is worse than having multiple connectors whose lack of interoperability is apparent at a glance.

            1. 5

              Yep, not knowing if the cable you want will work is like having USB-C Heisenberg edition. Its arguably worse because of the lack of knowing.

              1. 4

                It works for me with everything. A variety of phones, laptops, Nindendos Switch, chargers, batteries and cables. Maybe sometimes I’m not getting optimal charging speed, but it’s always better than the situation was before.

                I don’t have a MacBook though. I hear they have more issues than anything else.

                1. 3

                  Good for you. But the article shows your experience isn’t shared by everyone. Not knowing if a USB-C cable and charger will charge your device unless you try it is mildly infuriating.

            1. 4

              I use fish and have been happy with it. I don’t use any of the plugins for it, mostly because it’s good enough out of the box for the simple shell stuff I do.

              On occasion I have used bass to work with bash scripts that were required by projects I had to work on. It runs bash scripts and exports environment changes back to your fish session.

              1. 3

                Damn, I’ve been wanting something like bass for years, thank you!

              1. 6

                I switched away from Fish (after using it for several years) because I couldn’t get used to it’s non-POSIX syntax…

                1. 13

                  That’s the reason I picked it; for day to day usage, it’s a lot less warty, and if I need a bunch of POSIXy stuff, I can just exec bash.

                  1. 1

                    You are correct in that exec bash is a useful way to run POSIXy stuff. Unfortunately (to my knowledge), shell functions, aliases, etc. must be translated into fish. I depend on being able to source POSIX shell scripts in order to bring my functions and aliases to remote servers and containers.

                    1. 2

                      From my experience, 90% of shell functions and aliases can (and should) be rewritten as standalone scripts. Unless you indeed modify the current shell’s environment or even the argument handling (like noglob in zsh), there is no reason to hoard functions.

                      1. 1

                        Funny; I did just that mere hours before you posted your comment. Took three commits to my dotfile repo (1, 2, 3).

                        There is one other benefit to using shell functions and aliases: it’s easy to view them all at once by running functions && alias; the result can be written to a file, giving you a single file with all your custom commands.

                      2. 1

                        That’s a different use case, yeah. For me, I have two computers I ever interact with, so.

                        1. 1

                          Yeah, that’s unfortunately why I have to use bash at work even though I use fish everywhere else. Sad; fish is way nicer for shell scripting.

                      3. 5

                        I switched away from Fish, despite much preferring its obviously better syntax and other UI improvements, because I still had to work with old bash and posix shell scripts day-to-day anyway.

                        1. 4

                          I’m just writing scripts for zsh or a non-shell language when I want to do more than one thing.

                          fish has made 99% of my interactions at a shell prompt ‘just work’ with practically zero config, learning curve, or slowness.

                          1. 4

                            For the folks in this thread who found Fish was not compatible with their POSIX scripts: do you have a lot of functions that modify your shell’s state/environment, then? For me that’s limited to a few scripts related to virtualenv, changing directories, and setting the prompt. The other 95% does just fine as standalone scripts with #!/bin/sh as the hashbang.

                            To avoid misunderstanding, I’m not really asking “why do/don’t you use X”. It is me wanting to see all the things folks do with their shell that could not be done as a script, so please Share All The Things That Come Under That Heading And That You Feel LIke Sharing :D

                            1. 3

                              The biggest offenders are the version-switchers for various languages–virtualenv, chruby/rvm/rbenv, nvm, etc. For some of these things, there are fish equivalents, but it remains a point of friction.

                              The other annoyance with fish is that any time I have any problem with a shared script at work that works for everybody else, everyone assumes fish is the problem (which is rarely-to-never the case).

                              But it’s still a great shell and I continue to use it.

                          1. 4

                            The decision to not try to entirely abstract the host away as some other languages do (Java for example, with respect to operating systems) has not in any way hindered the ability of different Clojure implementations to share code between them.

                            This seems … patently false? For several years there was no way to conditionally execute code based on which runtime it was running under.

                            1. 10

                              Yeah, there is a lot of hand-waving in this piece. All implementations of Clojure other than the first-party JVM implementation are distinctly second-class citizens. The latest version of Clojure does not work with Graal–you have to use an older version and many of the most common Clojure libraries are not compatible. Clojurescript works OK in the browser, but most Clojurescript tooling was not designed with Node.js in mind. Code reuse between Clojure and Clojurescript kind of works unless your code needs to do any IO, at which point your Clojurescript becomes a nest of callbacks (and you don’t have access to the async/await stuff that makes async IO tolerable in Javascript).

                              I like Clojure and have been using it professionally since 2014, but its strength is definitely in the core language concepts, not the implementation–and certainly not in having multiple compatible implementations, where it lags behind many, many other languages.

                              1. 1

                                FWIW the Graal issue is being worked on at the moment, slated for release in 1.11.

                              2. 4

                                I’m sure in those earlier years it was more of a struggle, but I’m speaking from the perspective of someone who started using Clojure in 2017. To me it’s been smooth sailing with .cljc files from the very beginning.

                              1. 10

                                The maker of the Iowa Caucus app was given $60,000 and 2 months. They had four engineers. $60k doesn’t cover salary and benefits for four engineers for two months, especially on top of any business expenses. Money cannot be traded for time. There is little or no outside help.

                                This is the important bit. “Cheap, fast, good: pick two.” If the caucus wanted a better app, they’d have needed to invest a lot more time and money.

                                1. 4

                                  I don’t think so: Even if you assume 10% bench time, that’s still a mean $81k salary which is above market rates (avg. software engineer salary in Des Moines is $75k). That still leaves revenue for a $80k salesperson with a $80k OTE and the company makes money.

                                  It is more than possible two months time isn’t enough to build a $360k mobile app for some people, but I certainly could’ve done it, and I probably would have for $360k.

                                  My guess: Either the persons who made the RFP didn’t anticipate their real requirements (uptime/availability, accuracy, etc), or The Maker really doesn’t know how to make software. Without looking at the RFP I wouldn’t venture to say, and my own experience doing government projects could have me believe either equally.

                                  1. 1

                                    Did you read that number right? It’s 60k not 600k.

                                    1. 4

                                      $60k for 2 months work is $30k/pcm. If I do 6 projects of that size a year that’s $360k/pa revenue. If I discount that by 10% (for running my business; my salesperson, overage, etc), that’s still $324k/pa I could budget for four people, or an average salary of $81k.

                                      I could certainly do this project in two months, and then do six more just like it in a year. That means if I went and did the RFP myself I could make $360k/pa doing projects like this.

                                      I’ve also done events though, so I know that even if the RFP says there’s going to be wifi available, it’s going to be shit. Someone who hasn’t might trust the RFP and the project will fail: Whose fault is that? It seems a bit unfair to blame the developer who writes to a spec where the spec is just ambitious/wrong, but it also seems a bit unfair to blame the RFP writer since they might have never done event software before either. I suppose I could blame the DNC for hiring idiots in the first place, but that’s a bit higher up the food chain than what we’re talking about: We have no idea what they’re paying their PM…

                                    2. 1

                                      None of the engineers at Shadow was based in Des Moines. They seem to have been based in Seattle, Denver, and NYC. $81k is not above market rates in those cities.

                                      1. 1

                                        Do you have a link for that?

                                        I searched their jobs page and saw offers for “remote” which is usually a sign they pay midwest rates.

                                        I haven’t seen any news articles saying where the developers actually were.

                                        1. 1

                                          I was going by the developers associated with them on Linkedin.

                                  1. 2

                                    I used Google Reader and when it shut down, I exported my subscription list (in a standard format), imported that list into several other competitors until I found one I liked (Feedbin), and continued reading essentially without interruption. Isn’t that how interoperable standards are supposed to work? I would be thrilled if any newer social media stuff were as interoperable as RSS.

                                    1. 3

                                      In retrospect it’s kind of amazing how quickly we moved from an Internet with no “like” counts (the golden age of blogging) to an Internet where it’s very difficult to find any community where “like” counts or upvotes are not a core part of the system. Even indie sites like Lobste.rs or Metafilter that eschew a lot of the apparatus of the modern Internet incorporate this very quantitative approach to community and social interaction.

                                      1. 2

                                        Yes. The quieter, less-evaluative Internet was hijacked by one of addictive narcissism.

                                        1. 2

                                          After writing my earlier comment I realized that there is one type of online community I participate in that is completely free of likes/voting/ranking/quantitative anything: mailing lists.

                                          It’s probably not a coincidence that I love mailing lists, while people whose Internet experience started even a few years later than mine did seem to really, really hate them. I wonder if there is a real generational (or internet-generational) divide here, or if I’m just an outlier.

                                          1. 2

                                            It’s probably not a coincidence that I love mailing lists, while people whose Internet experience started even a few years later than mine did seem to really, really hate them. I wonder if there is a real generational (or internet- generational) divide here, or if I’m just an outlier.

                                            As a guy who first acquired an ISP in 1993, I can honestly say that I generally dislike mailing lists (like most people, I guess). I always think of them as a poor-man’s usenet, I would much rather just hop on tin(1) and read the latest posts in my subscribed groups.

                                            Having said that, I am a member of some mailing lists that I genuinely enjoy. Though they are the exception, not the rule…

                                          2. 1

                                            It would be interesting to see an implementation of an upvote button that didn’t display the count to the users. You still get the “community” aspect of it, without the narcissistic side.

                                            1. 1

                                              HN does this.

                                              1. 2

                                                Right! For the comments. They still show the points for each story, which I think makes sense (or does it…?)

                                            2. 1

                                              Back then we had guestbooks and hit counters to provide the tingle of popularity that is oh so addictive.

                                              I remember when I first added commenting to my blog and getting ten or so meaningfull comments within the first week of publishing a new post was a thrill to see; those were different to likes though, because they were actual meaningful interactions that often spawned discussion.

                                            1. 5

                                              I feel lucky to work in the Clojure ecosystem where edn is ubiquitous. It behaves predictably and supports the features I need.

                                              In a previous job I found myself sometimes hand-editing YAML CloudFormation templates. What a nightmare that was.

                                              1. 25

                                                With respect to email, don’t forget that pull requests were once intimidating too - as anyone who frequently works with onboarding new developers to its workflow can attest. To help make onboarding users with email easier, I wrote this tutorial:

                                                https://git-send-email.io

                                                I also wrote a rebase guide which applies to both workflows for making your changes more consistent and easier to review:

                                                https://git-rebase.io

                                                1. 26

                                                  https://git-send-email.io

                                                  That nicely outlines how to send patches, but I think people have far more difficulty receiving patches via email. Not everyone uses mutt, aerc, or runs a patchwork instance. Many mail clients, that people are otherwise generally fairly happy using, are just super not great at handling emailed patches. Emailed patches also generally don’t show a CI status that you can view ahead of time (I have heard of some, but I don’t ever remember seeing it firsthand in the wild).

                                                  It’s great that it (an email patch workflow) works well with your workflows and tooling, but for some people it just… doesn’t work as well.

                                                  1. 4

                                                    I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion. And testing your patches against SourceHut CI is pretty easy, before or after it’s sent.

                                                    1. 26

                                                      I think one issue is that for most of us, sending and receiving patches is a very small part of what we do with email, so choosing a mail client on that basis doesn’t make sense.

                                                      1. 1

                                                        But we aren’t forced to use only one mail client. I use several depending on context / the task at hand.

                                                        1. 1

                                                          I am curious about your multiclient workflow. Do you use multiple addresses, or use filters and one shared address? Or just all the mail in all of them?

                                                          1. 4

                                                            Whether you use local maildir or imap, mail stores are designed for concurrent access. How many people check email on their phone and not their phone?

                                                            1. 1

                                                              Sure, but my question was specifically about their workflow with it.

                                                            2. 2

                                                              As it happens I do use multiple accounts for multiple “hats”, but that’s slightly orthogonal to multiple clients, which I use even for a single account. My daily driver is mutt; I use thunderbird for rare occasions when I need to see rendered html properly or perform a search (still haven’t got mairix or not much etc set up) and I often use ios mail app but mostly read only.

                                                              At work we use Gmail. I do check that from ios mail app too. I recently started configuring mutt to read my work mail too but it’s a work in progress so I still regularly open the Gmail website.

                                                        2. 23

                                                          I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion.

                                                          To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.
                                                          Well…maybe.. I do find it unlikely that is going to convince very many people who weren’t already riding them, or weren’t already inclined to do so. Even if it is amazing.

                                                          Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find that oddly humorous.

                                                          Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                                                          1. 7

                                                            To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.

                                                            I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                                                            Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find the humorous.

                                                            Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                                                            Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                                                            That’s why Sourcehut can do it for you.

                                                            1. 9

                                                              I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                                                              A bit of an “Ipse dixit”, but I’ll take it at face value anyway. To be clear, my comment was in response to your statement:

                                                              I mean, those people who don’t have such a mail client are missing out.

                                                              Which is what I made the comparison against. You have now pulled in other concerns in your response, and attributed them to the comment I made. I find that a bit uncharitable. I guess at this point we can just agree to disagree.

                                                              Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                                                              That’s odd. I looked through the last 2 months of their mutt-dev mailing list, and saw no mailed patches, but several gitlab PRs. Maybe I saw the wrong mailing list? Maybe I didn’t go back far enough? Overlooked it?
                                                              It doesn’t really matter, and I’ll take your word for it that they predominantly use emailed patches.

                                                              1. 2

                                                                The last 2 months have only seen one patch on Gitlab:

                                                                https://gitlab.com/muttmua/mutt/merge_requests?scope=all&utf8=%E2%9C%93&state=merged

                                                                After reviewing it myself I have to correct myself, I reckon that Gitlab and the mailing lists are at about an even pace these days.

                                                                1. 2

                                                                  Do note: that was merged PRs. There were a couple of more (not many though!) in All which is what I looked at.

                                                          2. 5

                                                            Not everyone is productive using such mail client. Personally, I just plainly cannot remember more than a few shortcuts, which is already a massive roadblock for effectively using CLI tools as for most of them rely on shortcuts to increase productivity, they also do not provide me with options of what I can do, and I cannot for my life remember what can I do for all the possible contexts, cause of course options on what you can do are dependent on the context which you are currently in. Some people just aren’t productive using CLI tools, and saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                                                            1. 3

                                                              saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                                                              This is absurd. If a mechanic decides that he “is not a ratchet person” and will only ever use open-end wrenches, then I will question his professionalism just as I would question a software developer that “is not a CLI person” and will not learn to use a CLI mail client.

                                                              He doesn’t need to use the CLI mail client for his day-to-day email, but he should be capable of learning how to use it to handle the occasional emailed patches.

                                                              1. 5

                                                                Or this person will work with whatever, when paid for (professionals are paid for their work by definition!), but will only work with tools he/she finds enjoyable when doing charity. Thus FLOSS projects forcing inconvenient, last century methods with arrogant communication are missing contribution.

                                                                I thing the FLOSS community should focus on this kind of openness more, instead of CoCs.

                                                                1. 3

                                                                  Good point. For work I’ll use whatever tools get the job done, no matter how gruesome. But for FOSS contributions, I agree that if the tool is difficult or simply frustrating to use, then it may as well not exist.

                                                                2. 1

                                                                  Wrong assumption. Difference between using GUI and CLI clients is not like between open-end and ratcheted wrenches. Using those wrenches is basically the same. Meanwhile the experience between using CLI and GUI mail client is a lot bigger. I’d compare it to using automatic and manual wood planes. You can work with higher precision and similar speed with manual hand plane, but most carpenters would choose automatic hand plane, as it “just works” and doesn’t require that much skill and learning to do.

                                                                  And why should you care what kind of wrench does your car mechanic uses, if he does the job well? This isn’t a problem not using better tools, but a problem of tool abilities. The tools that an average developer uses does not represent the tools that are created for that workflow. And that is a problem.

                                                                  1. 2

                                                                    I’ll entertain the analogy to a wood plane, though I’m unfamiliar with the devices. You say it yourself: the manual wood plane is useful in certain circumstances but requires skill. So does the CLI mail client. Use the automatic wood plane where it fits, but at least learn the skill to use the manual wood plane where the higher precision is necessary.

                                                                    A developer that refuses to acquire a skill is simply not professional.

                                                                    1. 1

                                                                      It’s not like it requires much skill. It is the basically the same skill. The difference is, you need to move the manual wood plane along the plank 10 times, while with automatic you only need to move it once and the motor does its job. Some people just don’t have the patience and/or physical stamina to use manual wood plane. Manual hand plane is in fact more configurable, and can be used in more specialized scenarios. So enthusiasts use hand planes. Your average carpenter does not.

                                                                      1. 2

                                                                        The analogy was not mine.

                                                                3. 0

                                                                  Consider acme?

                                                                  1. 2

                                                                    I am unable to find such email client. And the point is, for a workflow to be usable by a wide range of people, it should require as little new tools that do the same as the ones they use. And in case of email clients, most people probably like their current email client, and they do not want to change it. So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                                                    1. 4

                                                                      acme is a text editor which can be easily coaxed into being a mail client.

                                                                      Consider as well that you needn’t discard your daily mail client in order to adopt another. What difference does it make if some technology is backed by email or by some other protocol? Just because you already have an HTTP client (e.g. your web browser) doesn’t mean another isn’t useful (e.g. curl).

                                                                      1. 7

                                                                        Acme does not seem like general user friendly. My colleagues all use JetBrains IDE’s and use Thunderbird as their mail client. And acme would be a downgrade for their experience. I might use it, but they wouldn’t. If I cannot offer them a good GUI email interface, there is no way they would switch to email-based workflow.

                                                                        1. 0

                                                                          I was recommending acme particularly for you, given the following:

                                                                          I just plainly cannot remember more than a few shortcuts

                                                                          If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software. A bicycle is easier to use than a car but it’s not going to get you to the other end of town in time for the movie.

                                                                          1. 14

                                                                            If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software.

                                                                            Don’t you think peace within a team is more important than any particular software or workflow? Or, to put it another way, the feelings of people are more important than any workflow, so if a large group of people reject a workflow, it’s better to conclude that the workflow is wrong for those people than to say that those people are wrong.

                                                                            1. 7

                                                                              My colleagues wouldn’t join me because the workflow is bad, but because there is no tooling suitable for them and the workflow. If tooling for a specific workflow just isn’t comfortable for me, I’m just not going to use it.

                                                                        2. 2

                                                                          So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                                                          What happened to using the right tool for the job?

                                                                          1. 1

                                                                            The question here is not about “the right tool for the job” but about the usability of those tools for the wider audience. Currently I do not see the majority of the developers switching to email-based workflow purely because of the usability of tools. “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                                                            1. 3

                                                                              “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                                                              Good to know that we were all rockstars for decades without realizing it!

                                                                              This is probably just an age thing but I don’t know any professional programmers who aren’t comfortable with CLIs.

                                                                              1. 3

                                                                                There is CLI, and there is CLI application. Git is used through CLI. Vim is a CLI application. Surely you know at least one professional programmer that isn’t comfortable with Vim and alike.

                                                                    2. 3

                                                                      I am not particularly experienced at using git with email. One problem I have had in the past is when I want to pull in a patchset from a mailinglist archive, where either I am not subscribed to the mailinglist, or wasn’t subscribed at the time when the patches were sent. Can these mail clients help me with this problem? (By contrast, I find it very easy to add a branch / PR as a remote and pull or cherry-pick commits that way)

                                                                      1. 3

                                                                        lists.sr.ht, the sourcehut web archive for mailing lists, has a little copy+paste command line thing you can use to import any patch (or patchset) into your local git repo. Here’s an example:

                                                                        https://lists.sr.ht/~sircmpwn/aerc/patches/7471

                                                                        On the right, expand the “how do I use this” box and a short command is given there.

                                                                        Integration directly with your mail client would require more development but isn’t necessarily out of the question.

                                                                        1. 3

                                                                          That’s good to see, but presumably doesn’t help for non-sourcehut mailinglists?

                                                                          1. 3

                                                                            No, I’m afraid that there are fewer good solutions for non-sourcehut mailing lists. Patchworks has a similar feature, if the list in question has that set up. You could also ask someone else for a copy of the mail. I don’t think this damns the idea, it just shows that we need better software to support the idea - which is what sourcehut tries to be.

                                                                  2. 2

                                                                    I am still trying to find some time to check out Sourcehut. My only concern is how to configure it to run CI builds on mailing list patches as I couldn’t find it anywhere in the docs.

                                                                    1. 1

                                                                      This hasn’t been implemented yet, but it will be soon.

                                                                      1. 1

                                                                        Great. If that happens I will think about migrating some of my personal projects to the Sourcehut as it seems pretty as a pretty nice solution.

                                                                  1. 1

                                                                    As another programmer without a degree I really like seeing this documented. Thank you!

                                                                    1. 4

                                                                      I’m sorry this happened (and is happening) to you. It’s clear that you did the right thing here.

                                                                      1. 1

                                                                        If you’re interested in this kind of thing you should check out Clara, a Rete-algorithm-based forward-chaining rules engine written in Clojure (so you get that nice S-expression syntax). Anecdotally, it seems like rules engines are having a bit of a resurgence as the healthcare software industry heats up. In my experience Clara is a pretty good fit for capturing the kinds of really baroque business (or clinical) logic that is often required in the healthcare space.

                                                                        1. 2

                                                                          The author of this post is famous but doesn’t get how things work. This is his argument…

                                                                          Tl/DR:

                                                                          • companies go public later, doing more later stage funding rounds.
                                                                          • founders have more control nowadays since VCs started to realize that founders outperform external CEOs
                                                                          • being a founder is less risky (not clear why this would be the case, yes, funding rounds went up, but so did the early expenses of starting a company)
                                                                          • founders have more upside than employees (he pulls a number from thin air, 30-50 times)

                                                                          There is so much in this post that I don’t agree with that it’s hard to know where to start. First of all, founders having more control is a good thing for employees. Founder stock is very close to the deal employees are getting. At the very least it’s better aligned with employees than investor stock. (down round protection is almost always built-in to investor stock). Also the founders work with the employees on a day to day basis. Making them on average less likely to screw over the employees. (seriously does anyone believe that the VCs care more about you than the founders? have a look at what happened to Travis)

                                                                          The opportunity cost of being a founder has only gone up. The reason is that nowadays you can get crazy high engineering or management salaries at big tech companies.

                                                                          I can only speak from my own experience. Maybe we’re particularly generous, but the difference between top employees and founders is not that big over here.

                                                                          The main thing I don’t agree with is the general sentiment of the post. Supply and demand for engineering talent have been more and more in favor of engineers over the last 10 years. Salaries are going up, perks are going up, work life balance is becoming more chill. I have a friend who joined 4 startups and sold his stock 4 times. He can pay his house in cash these days. No other industry has these amazing jobs.

                                                                          The one thing that does really need to change is taxation on stock options. That system is obviously a bit broken at the moment.

                                                                          What I think is really going on here is that Steve Blank is low on traffic for his blog and decided to write some hipster sounding controversial blogpost.

                                                                          1. 10

                                                                            I have to disagree with you on a number of your points.

                                                                            First of all, founders having more control is a good thing for employees.

                                                                            This is highly situation dependent–if the founder has experience and values their employees, it’s a great thing. If a founder is young and doesn’t understand the career trajectory of engineers (or other people trying to raise a family), this can be bad. If the founder, as a purely random example, comes from a privileged background and tries to treat their employees like pieces of factory machinery, it’s terrible.

                                                                            Founder stock is very close to the deal employees are getting. At the very least it’s better aligned with employees than investor stock.

                                                                            Founder stock grants are quite often orders of magnitude larger than that for their employees, they have inside information about how the financing and fundraising is going, they have direct control over those aspects in ways their employees do not, and that’s before you even get into the options, voting stock, and other differences Blank touches on.

                                                                            I’ve seen a CTO (who is legally liable for the company’s behavior as an executive!) be grudgingly given less than a point share in the business, because of stingy founders! Us poor grunts who build the products have no hope in such cases.

                                                                            Also the founders work with the employees on a day to day basis.

                                                                            The company I was just let go from had a founder that talked to me a total of like 5 times in the last year and a half, the final time gaslighting me about who had me fired. The previous health IT company I was at, the tech cofounder kept their day job and seagull managed the rest of us, and the biz cofounder/CEO usually was holed up in their office and popped out to ask for asinine product tweaks and failed to make sales and raise investment.

                                                                            This is a highly-variable thing.

                                                                            Making them on average less likely to screw over the employees.

                                                                            VCs are there to make money, if it means sharing with employees they’ll do that. Founders are there, in my observation, to boost their own egos–and even if you write most of their product, their own arrogance will prevent them from ever giving you similar compensation, because you once took a paycheck from them and somehow that makes you not as worthy…even if the paycheck was backed by other people’s money. If it’s backed by their money, God help you.

                                                                            The opportunity cost of being a founder has only gone up. The reason is that nowadays you can get crazy high engineering or management salaries at big tech companies.

                                                                            That applies double for early employees, right? At least founders get to network with the investing class and can put “I founded ” on their resume and go on podcasts and shit–early employees are usually hired because they’re more qualified than the founders (by definition…if they weren’t, they probably wouldn’t be hired) and they are paid very much below market rates.

                                                                            Maybe we’re particularly generous, but the difference between top employees and founders is not that big over here.

                                                                            Are you one of the founders? Can you throw out some numbers?

                                                                            I have a friend who joined 4 startups and sold his stock 4 times.

                                                                            I’ve worked at least four startups (two as senior FTE, one as cofounder, others as contracted engineering talent), and only now might have stock from one of them. Last one the founder got really weird when I talked about exercising my options to see our finances. Good for your friend, but equity is basically a joke on par with exposure now.

                                                                            No other industry has these amazing jobs.

                                                                            You might be surprised at the perks and job security offered by other white-collar fields. Engineering, once you have a PE, is relaxed as hell by all accounts. If these jobs are so great, why do we mostly only see dumb young men signing up for them?

                                                                            ~

                                                                            Like, I get it–in magical little pockets of reality that still mirror the 90s, being a startup early engineer is great. For most of us, though, we’re getting shafted compared to the value we add.

                                                                            1. 1

                                                                              Sorry to hear that, doesn’t sound like a great environment. As an engineer you can be quite picky where you work. I’ve made this mistake in the past as well, staying too long somewhere were the culture/environment isn’t right. Did you find a good opportunity eventually?

                                                                            2. 1

                                                                              I don’t think the post said or could credibly say it’s a bad time for engineers, but it did raise some things that seem both true and relevant to one’s analysis of options. Just that you might be waiting a long time before you can sell is a pretty big deal. A naïve analysis of options value probably doesn’t factor in dilution – you might think “it’s 0.x% equity” based on what it is at the time, forgetting that if there are more rounds, that will change. This post only touches on it, but the whole short exercise window if you quit thing is relevant too.

                                                                              The world is, in general, quite unfairly kind to engineers in 2019. But you should still understand upsides and downsides of options when you’re evaluating them.

                                                                              1. 1

                                                                                I have a friend who joined 4 startups and sold his stock 4 times.

                                                                                When did this happen? His whole argument is that options used to be a good deal, but no longer are. Examples from ten years ago don’t disprove that thesis, which is in accord with my experience. Yes, it’s a good time to be an engineer, but only because salaries are high. None of the equity I’ve notionally had at several startups has ever been worth even enough to buy a coffee in actual exchange value.

                                                                                Maybe we’re particularly generous, but the difference between top employees and founders is not that big over here.

                                                                                OK, I’ll bite. What’s the ratio of a founder’s equity to the equity of an April 2019 new hire at your shop?

                                                                              1. 1

                                                                                The #NoEstimates response to these business needs is typically of the form, “Estimates are inaccurate and therefore not useful for these purposes” rather than, “The business doesn’t need estimates for these purposes.”

                                                                                That argument really just says that businesses are currently operating on much worse quality information than they should be, and probably making poorer decisions as a result, because the software staff are not providing very good estimates. If software staff provided more accurate estimates, the business would make better decisions in each of these areas, which would make the business stronger.

                                                                                If magical fairies dropped bundles of gold doubloons from the sky onto the conference room table, that would also make the business stronger. It does not follow that this means relying on fairy gold is a sound practice.

                                                                                Like every #yesestimates argument, this one boils down to: we really need to be able to estimate reliably, therefore it must be possible. That’s not how causation works.

                                                                                1. 39

                                                                                  I’m really burning out on “simplicity” posts. I get it, simplicity is good. But that doesn’t actually inform me as a developer. Why do things become complex? What kinds of simplicity are there? How do we detect simplicity? How do we know when we shouldn’t simplify? None of these posts ever answer that.

                                                                                  It’s like if I stood on stage and said “Be good! Don’t be evil! Being evil is bad!” Sure, everybody agrees with that, but does it actually help people make moral choices?

                                                                                  (Also the analogy is dumb. Yes, we should totally base our engineering practice on a movie! A movie where the engineers are wrong because of magic.)

                                                                                  1. 11

                                                                                    Why do things become complex? What kinds of simplicity are there? How do we detect simplicity? How do we know when we shouldn’t simplify? None of these posts ever answer that.

                                                                                    Because your questions are difficult and answers are dependent on a lot of factors.

                                                                                    I’ll tell you what I do to detect simplicity, maybe you’ll find it useful. Let’s start with a real-life example.

                                                                                    I needed tokens for authorization, I reviewed existing formats, JWTs look conservative and Macaroons look powerful.

                                                                                    What do I do? I dissect the formats. For JWTs I read the RFCs and implemented software to create them and verify them (each in 2 languages) for various options (key algorithms).

                                                                                    For Macaroons I read the whitepaper, then implemented verifier based on the whitepaper, reviewed existing implementations, found out differences between the whitepaper and de-facto code with explanations. While comparing my implementation I found out some security issues with existing code. Additionally I implemented the rest of the stack (de/serialization, UI for manipulation of Macaroons). After two months I knew precisely where does complexity lie in Macaroons and of course there are the only spots all blogposts don’t mention (spoilers: cycles in third party caveats, no standards for encoded caveats…)!

                                                                                    Then I looked at my JWT proof-of-concept code - it uses base64(url) and JSON, primitives that basically all programming environments have built-in. After limiting the algorithms used the entire verifier takes just a couple of lines of code! It’s vastly simpler than the Macaroon one.

                                                                                    What’s the moral here? That you need a lot of time to see for yourself what is simple and what is complex. Now every time I see a post recommending Macaroons I can already see the author didn’t use them in practice (compare that with the Tess Rinearson post linked at the end of that article).

                                                                                    That’s only the example, I routinely implement various protocols and re-implement software (ActivityPub, Mailing Lists, roughtime client) and each time I discover what’s simple or what’s complex in each one of them.

                                                                                    (By the way your book is excellent!)

                                                                                    1. 9

                                                                                      I get it, simplicity is good.

                                                                                      Alas, not everybody gets it. The best that these kinds of exhortations can do (all that they aim to do, as far as I can tell) is to persuade people to modify their own set of values. This doesn’t immediately result in better code… but I think it’s a necessary precondition. The only developers who will even ask the good questions you suggest (let alone look for good answers) are the developers who hold simplicity as a value.

                                                                                      (The analogy is pretty dumb though, and not especially motivating.)

                                                                                      1. 10

                                                                                        I’ve never met a developer who does not claim to hold simplicity as a value. But as a concept it is so subjective that this is meaningless. It’s extremely common for two developers arguing for opposing approaches each to claim that their approach is the simpler one.

                                                                                        1. 7

                                                                                          I get the value of exhortations. I think more examples would be better. Pairs of solutions where the simple one meets requirements with a number of better attributes. Developers often prefer to see the difference and benefits instead of being told.

                                                                                        2. 6

                                                                                          Exactly. This is one of those things you can’t explain in a book. When to compose, when to decompose. When to extract methods, when to inline methods. When to add a layer of abstraction, when to remove one. When is it too flexible, when is it too simplistic?

                                                                                          No amount of rules of thumb is going to answer those question. I only know of one way to learn it: practice. Which takes effort and most importantly, time. Rendering this kind of posts mostly useless.

                                                                                          1. 3

                                                                                            P.S. They do feel good to write though, so people will keep writing them, and there’s nothing wrong with it either.

                                                                                          2. 5

                                                                                            I agree that anecdotes like this can get old, but I’ve been meaning to actually write a similar post to this… on something I’ve been calling the “too many buttons” syndrome. This issue pops up a ton in large pieces of software (Though I’m specifically thinking of projects like JRA and Confluence) where there’s an option for everything.

                                                                                            Not everyone gets that simplicity is good because it can be harder to sell. “If a user wants it, we should do it” is something I’ve heard just a few too many times without bothering to look at the use case or if it could be done better. Sometimes it’s worth stepping back and looking at the complexity something will add to the project (in both code and testing… especially when it comes to options and how they interact with each other) rather than just adding all the little features.

                                                                                            1. 5

                                                                                              In my experience a lot of commercial companies that develop under tight deadlines produce a lot of suboptimal and dreadful code. Often it takes more time, to produce less code simply because the more time you spend on a difficult problem, the better you understand it. I think the reason that most a lot of software is bloated and complex is because it’s “good enough” which is optimal from an economic point of view.

                                                                                              The other day there was a discussion here on Lobsters about all the required pieces needed to run a Mastodon instance and the popular solution of abstracting all that away in a Docker container. There are alternative implementations that depend on a smaller number of components alleviating the need for dumping everything in a container (of course the question is, do these alternatives offer the same functionality).

                                                                                              How do we detect simplicity?

                                                                                              For me personally simplicity has to do with readability, maintainability and elegance of code or infrastructure. If someones solution involves three steps, and someone else can do it in two steps (with comparable cognitive load per step), I would say it’s more simple.

                                                                                              How do we know when we shouldn’t simplify?

                                                                                              If that would cut some features you cannot miss.

                                                                                              1. 5

                                                                                                You are so right. After years of experience, I only start to clarify my idea of “simplicity”. There are different kind of simplicity most of them are not totally compatible. And in my opinion some need to be preferred to other, but there is no clear rule. To make a choice between different complexity I still use a lot of intuition and I debate a lot, and I am still unsure my choice are the best.

                                                                                                • only using basic feature of a language (do not use advanced programming language feature) is certainly the most important aspect in simplicity. It will make your code easy to read by more people.
                                                                                                • don’t use too much intermediate functions, and if possible don’t disperse those function in many different files before really feel you are copy/pasting too much. My rule of thumb is, 2 or 3 times duplications is totally fine and superior to centralisation of code. It start to be really clear that code factorisation is good when you start repeating yourself more than 6 to 10 times
                                                                                                • only really use advanced feature of the language after having tried not to use it for some time and really lack the ability of that advanced feature. Some examples of what I call advanced feature of a language are; class heritage, protocols in Clojure, writing your own typeclasses in Haskell, meta programming (macros in LISP), etc…
                                                                                                • prefer stateless functions to objects/service with internal states
                                                                                                • prefer pure functions (side effect free) other procedures (functions with side effects)
                                                                                                • give a lot of preference to composable solutions ; composable in the algebraic meaning. For example, I do my best not to use LISP macros, because most of the time macros break composability. The same could be said when you start to deal with type-level programming in Haskell, or when you are doing meta-programming in ruby/python.

                                                                                                For now, all those rules are still quite artisanal. I don’t have any really hard metrics or strong rules. Everything I just said is “preferable” but I’m pretty sure we can find exception to most of those rules.

                                                                                                1. 5

                                                                                                  Amen, +1, etc. “Simplicity” often just means that a concept fits cleanly in the maker’s head at a particular point in time. How many times have I returned to a project I thought was simple only to find I had burdened it with spooky magic because I didn’t benefit from critical distance at the time? When was the last time I deemed another person’s work “too complex” because I couldn’t understand it in one sitting and wasn’t aware of the constraints they were operating under? Answers: too often and too recently.

                                                                                                  1. 3

                                                                                                    What kinds of simplicity are there?

                                                                                                    This is a good question (as are the others). Borrowing from Holmes, I’d say there’s a continuum from naive simplicity, to complexity, to simplicity on the other side of complexity (which is what is truly interesting)

                                                                                                    For example, “naively simple” code would only cover a small subset (say, the happy path) of a business problem. Complex code would handle all, or most, of the business complexity but in a messy, complicated way. “Other side” simplicity refines that complex code into something that can handle the business complexity without itself becoming overly complicated.

                                                                                                    1. 2

                                                                                                      What happens to simplicity? We trade it for a other things of course. For example, you can have simple regular expressions, but most people prefer less simple and more powerful implementation like Perls.

                                                                                                      Simplicity is often a tradeoff versus easyness, performance, flexibility, reusability, useability, etc. So simplicity is good, but those other things are also good.

                                                                                                      1. 1

                                                                                                        Most people seem to agree that simplicity is best. However, when it comes down to simplicity for the user versus the developer, I have seen disagreement. Each trade off is going to be situation and implementation dependent, but at my job I’ve been pushing for a simpler developer environment.

                                                                                                        In my office, there is a tendency to create exceptions to rules because it makes things simpler for the user. Since the environment has more exceptional circumstances, it tends to have more errors when people forget the undocumented exception case. In my opinion, this causes an uneven experience for the user despite being “simpler.”

                                                                                                        My experience is coming from a medium sized, non-tech company. I work in the IT department so we are a cost center. There is an emphasis on white glove treatment of the revenue producing portions of the company. YMMV

                                                                                                      1. 4

                                                                                                        Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers.

                                                                                                        Haha, what a load of crap, just admit you don’t like java. We should be honest about these things.

                                                                                                        1. 34

                                                                                                          Please don’t dismiss people by telling them you know their own opinions better than they do or that they’re lying. There’s much better ways to disagree with their decision here.

                                                                                                          1. 8

                                                                                                            It’s a case study for promoting Rust…I wouldn’t judge it the same as dismissing somebody’s own blog post or whatever, say.

                                                                                                            1. 3

                                                                                                              It’s dismissing people’s experience. The medium is irrelevant.

                                                                                                              1. 21

                                                                                                                Sometimes people’s experiences are not representative of reality, and sometimes people lie about their experiences, and sometimes people rewrite their experiences without realizing it, and sometimes people have experiences so limited that their ability to usefully generalize and advise others is called into question.

                                                                                                                Just because it’s somebody’s claimed experience doesn’t magically make it somehow unable to be questioned.

                                                                                                                And so we’re on the same page…we’re not talking about somebody relating a background of trauma or something: we’re talking about a company (npm) engineering team deciding to redo the same task three times using 1 hour (Node), 2 days (Go), and a week (Rust) and then the RESF using that to shill Rust (glossing over a doubling in the complexity of the npm’s language ecosystem and stack.

                                                                                                                If they’d provided real performance numbers, maybe shown how the Rust version vastly outperformed the Node version, then this might be a better article. As it is, anybody with experience reading press releases (rightly) will wonder if the “experiences” are worth learning from.

                                                                                                                1. 3

                                                                                                                  What exact claim do you find insufficiently backed up? They literally just documented the (their!) process of rewriting a chunk of JS in a different language, and how it went (for them). To get back to the original “page”: The “claim” ac was attacking was an opinion, a non-falsifiable statement at worst (as I think the conclusion is).

                                                                                                                  1. 17

                                                                                                                    There are no numerical metrics or benchmarks in the article. The service in question was “projected to become a CPU-bound task”, but it’s unclear if that’s a real issue without seeing their math. Other quotes like “the legacy JavaScript implementation of this service in Node.js was in need of a rewrite in any case” hint that this might be a strictly unnecessary rewrite.

                                                                                                                    Have you not experienced engineers selling a rewrite or new technology because they’re bored and not because it’s necessary?

                                                                                                                    1. -5

                                                                                                                      Ugh. Nobody is selling you anything here.

                                                                                                                      1. 13

                                                                                                                        “Rust Case Study:” “Copyright © 2019 The Rust Project Developers” “https://www.rust-lang.org

                                                                                                                        It’s on there specifically to convince people to adopt Rust. Which is fine: they’re promoting their work and how others benefit from it on their project page. (shrugs) It doesn’t bother me as much as friendlysock since I got at least two things out of it:

                                                                                                                        (a) Javascript developers were able to adopt it. That’s good to know in long term since I’m for minimizing Javascript use in general. Rust apps will also be more secure and maybe predictable. The typical predictions so far were that it would win over only C and C++ types, not Javascript and Go. This is a data point against that expectation for Javascript in an unlikely place.

                                                                                                                        (b) The Rust apps caused less problems, possibly due to what I just said. Then again, it could be anything since we have no data. Might not even be Rust. Heck, the Go rewrite might have taught them some lesson they reused when making the Rust version. We don’t know.

                                                                                                                        Now, far as a scientific evaluation, there’s nothing more to go on as friendlysock says. They didn’t even give us numbers. We’d also be interested in what was easy, difficult, and so on at a language level for the work they were doing. What they told us was what everyone writes, including Rust project’s marketing pages. It objectively introduces no new information on a technical level that we can evaluate or build on.

                                                                                                                        1. 2

                                                                                                                          We’d also be interested in what was easy, difficult, and so on at a language level for the work they were doing.

                                                                                                                          The did mention that the Rust implementation was more difficult, though.

                                                                                                                          “Therewriteof the authorization service using Node.js tookabout an hour. … The Go rewritetook two days. … The rewrite of the service in Rust did take longer than both the JavaScript version and the Go version: about a week to get up to speed in the language and implement the program. Rust felt like a more difficult programming language to grapple with.”

                                                                                                                          1. 2

                                                                                                                            Almost all things on Rust mention a learning curve with borrow-checker (or language), cargo being great, and a great community. Mentioning that downside is echoing common claims more than anything extra critical at this point. It’s part of the refrain.

                                                                                                                            You mentioning this did bring another data point I overlooked: they felt up to speed in Rust in about a week. So, Javascript developers both found the language useful and picked it up in a week. Or at least did for that one type of service well enough to falsely think they understood it in general. See how we’re still lacking objective data? We have a nice anecdote, though, which justifies trying to train a crowd of JS developers on Rust on similar or different projects to see what happens.

                                                                                                                            1. 1

                                                                                                                              See how we’re still lacking objective data?

                                                                                                                              That’s not a surprise to me, since I believe that the programming language field is at least a century away from having the capability of gaining objective data on anything non-trivial. We’re like surgeons ridiculing the guy who washes his hands before operating.

                                                                                                                              I guess that guy is Rust.

                                                                                                                              1. 3

                                                                                                                                It’s a frequent complaint we have. We’d love to have more data to compare us to.

                                                                                                                        2. 6

                                                                                                                          Nobody is selling you anything

                                                                                                                          Companies don’t just publish information randomly. A white paper is a standard marketing device (https://en.wikipedia.org/wiki/White_paper#In_business-to-business_marketing).

                                                                                                                          In this case they’re selling:

                                                                                                                          1. NPM as a rigorous engineering culture (recruiting), and
                                                                                                                          2. JavaScript-Rust ecosystem cohesion (technology)
                                                                                                                          1. 3

                                                                                                                            Exactly, we use whitepapers in precisely this fashion. They are basically executive tl;drs and as such gloss over details.

                                                                                                              2. 2

                                                                                                                Did you really need use Sysop hat to say that?

                                                                                                                1. 3

                                                                                                                  hatters gonna hat.

                                                                                                                2. 0

                                                                                                                  Perhaps the ‘haha’ didn’t convey my tone right. I meant it as a jab/joke, the type of thing you would say to make fun of your friend…

                                                                                                                  ‘cmmmoooon, my friend… just admit it, you don’t like java … nenornenornenor … lets go play tag’

                                                                                                                  1. 0

                                                                                                                    Also, I didn’t say lying… I think I was more implying a level of self delusion.

                                                                                                                  2. 19

                                                                                                                    Those are valid complaints. Deploying a Java service requires deploying at minimum 2 things that must be kept in sync. A JVM and a Java jar.

                                                                                                                    Because they are separate they bring a number of deployment and operations issues for the life of the service. Rust being a single binary removes those issues entirely.

                                                                                                                    There are resolutions for all those in Java too but they all require more effort than Rust does.

                                                                                                                    1. 12

                                                                                                                      Of all the other things you have to do to run or build service - that seems like a drop in the bucket of things to care about to me.

                                                                                                                      How many backwards incompatible changes are the JVM’s making these days anyway?

                                                                                                                      1. 14

                                                                                                                        Quite a few, actually.

                                                                                                                        I am no JVM expert but in my experience as a Clojure application developer it’s quite common for new Java releases to break Clojure and/or widely-used Clojure libraries. It’s happened several times in the last year. At work, we are currently on an older Java release for this reason. Right now, the latest Java has a serious performance regression for some fairly-common Clojure use cases and folks are being advised not to upgrade.

                                                                                                                        1. 2

                                                                                                                          that does sound pretty lame.

                                                                                                                        2. 3

                                                                                                                          It’s not so much the JVM’s backward incompatibilities as the JAR’s that are dependent on the latest and greatest JVM, except that one old JAR that only works on some old ancient version.

                                                                                                                          So you end up running multiple JVM’s across various machines, to make various JAR’s happy. Suddenly you start day dreaming of rust or go built binaries…

                                                                                                                          But generally I agree, JVM nightmares aren’t that miserable compared to 5,000 external service dependencies you may have to operate just to make X work.

                                                                                                                        3. 3

                                                                                                                          Shouldn’t that be easily automated, either provision the server with a pre-installed JVM (using ansible? etc.) or use Docker and put the JVM in there as is common?

                                                                                                                          1. 1

                                                                                                                            The most future proof method is to use a Docker container.

                                                                                                                          2. 4

                                                                                                                            They’re already doing the exact same thing with Node and the JS code that it runs.

                                                                                                                            1. 5

                                                                                                                              Sure, but that’s no reason to go through the same pain a second time. I put up with many things in the Python packaging world because I already know and use Python, but I am not willing to invest time in learning an ecosystem that exhibits issues anywhere close to that.

                                                                                                                            2. 2

                                                                                                                              But deploying any service is already tracking versions of databases, the state of your app, the code + compatibility with the OS. I don’t think avoiding java solves dependency or state management.

                                                                                                                            3. 8

                                                                                                                              While I think you phrased this strongly, I’m also puzzled by the quote. The legacy application being replaced is a node app. Running a node app requires a VM and standard library just as running a JVM app does. What is the overhead that makes a JVM app unacceptable while a node app is ok? Perhaps it’s language/tooling familiarity? In my experience, all those three-letter J** acronyms can get fairly confusing.

                                                                                                                              As an aside, I found the following quote refreshingly honest -

                                                                                                                              “I wouldn’t trust myself to write a C++ HTTP application and expose it to the web”

                                                                                                                              1. 7

                                                                                                                                Maybe you haven’t read the full article? it literally says

                                                                                                                                Given the criteria that the programming language chosen should be:

                                                                                                                                ● Memory safe

                                                                                                                                ● Compile to a standalone and easily deployable binary

                                                                                                                                ● Consistently outperform JavaScript

                                                                                                                                of which Java doesn’t fulfill at least one.

                                                                                                                                1. 1

                                                                                                                                  @ac’s comment doesn’t indicate that he missed that part of the article. He is challenging the premise of the second bullet point. The statement about Java that he quoted was the implicit justification for that bullet point.

                                                                                                                                  1. 1

                                                                                                                                    I don’t agree, I think the bullet point was the justification for the statement about Java and not the other way around. At least logically this makes more sense. You do have a point though about the order in the document:)

                                                                                                                                  2. 1

                                                                                                                                    Pretty sure graal vm java does all of those.

                                                                                                                                    1. 3

                                                                                                                                      It’s also commercially licensed by Oracle.

                                                                                                                                      1. 1

                                                                                                                                        from http://www.graalvm.org/downloads/

                                                                                                                                        License

                                                                                                                                        All open-source

                                                                                                                                        Free for production use

                                                                                                                                        1. 2

                                                                                                                                          The community edition. Enterprise edition:

                                                                                                                                          • Free for evaluation and other non-production uses
                                                                                                                                          • Improved performance and smaller footprint
                                                                                                                                          • Sandboxing capabilities for native code
                                                                                                                                          1. 1

                                                                                                                                            Twitter runs on the community edition for all production services and have impressive numbers. Search for talks by Chris Thalinger on YouTube to learn more.

                                                                                                                                            1. 1

                                                                                                                                              Yep, it’s still not “it’s free”, but “it has free variant”. Oracle is no stranger to changing the licensing, as they have recently shown with the mainline oracle JVM.

                                                                                                                                              Not wanting to deal with oracle stuff at all is a reasonable stance.

                                                                                                                                      2. 1

                                                                                                                                        Fair enough, though in this same vein you could argue that C++ is a safe programming language, if you avoid the “thorns”;)

                                                                                                                                    2. 4

                                                                                                                                      It’s a real issue. I stumbled across this “warp” project that makes standalone app bundles for the Buck build system and Buckaroo package manager, which are written in Java.

                                                                                                                                      https://github.com/dgiagio/warp

                                                                                                                                      If it weren’t an issue, then they wouldn’t have done this weird dance. I also took care to make a Python app bundle for Oil for related reasons.

                                                                                                                                      1. 2

                                                                                                                                        I found warp the same way you did :)

                                                                                                                                        but buckaroo is now written in F#

                                                                                                                                        1. 3

                                                                                                                                          We still use Warp, even though Buckaroo is now AOT-compiled F#. The reason is that we have dynamic libraries but still want users to be able to wget the tool for quick installs.

                                                                                                                                      2. 4

                                                                                                                                        It’s a legitimate concern. Having the ability to deploy a single binary easily from CI or the like can greatly reduce ops headaches (Python is a bit of a mess to deploy because it’s hard to do this).

                                                                                                                                      1. 5

                                                                                                                                        There are so many assumptions here I wouldn’t trust this any more than just asking during the interview. And from what I’ve seen, work/life balance depends as much on the employee as it does the employer.

                                                                                                                                        And fwiw, working on personal projects or doing any non-work open source development using your work GitHub account sounds like a terrible idea.

                                                                                                                                        1. 3

                                                                                                                                          I have never worked with anyone who had separate work and personal Github accounts. How would such separation benefit me as an employee?

                                                                                                                                          1. 4

                                                                                                                                            Odd. I’ve never met anybody who didn’t keep their work accounts separate.

                                                                                                                                            The way I see it, it’s just like any other work account. I wouldn’t use my work email for personal correspondence, or a work chat for personal chatting so why use my work GitHub account for personal projects?

                                                                                                                                            Not to mention all the questions it could raise about who actually owns the work the account creates. And what happens when you leave the job? And who knows what kind of snooping employers can do to the accounts they control.

                                                                                                                                            In general I like to keep a very strict separation between work and the rest of my life.

                                                                                                                                        1. 10

                                                                                                                                          In a burndown chart, I want to be able to run simulations as well. “What happens to this project if X work falls behind. What happens if Bob gets sick?”

                                                                                                                                          Is anything in software development predictable enough to make this kind of analysis useful?

                                                                                                                                          1. 8

                                                                                                                                            No, this is basically a management wish-fulfillment fantasy.

                                                                                                                                            Seeing that we thought something would take 8 hours of work but we spent 24 is incredibly valuable. We can revisit our assumptions we made when estimating see where we got it wrong. Then, we can try and account for it next time. Yes, estimating is hard but its also a skill you can get better at if you work at it and have support for proper tools.

                                                                                                                                            Likewise, I have heard this asserted by every manager I’ve ever worked with and for. No evidence has ever been presented, nor have estimates actually improved over time. (The usual anti-pattern is: estimates get worse over time because every time an estimate turns out to be low, a fix is proposed–“what if we do all-team estimates? what if we update estimates more frequently?”–which inevitably means spending more time on estimates, which means spending less time on development, which means we get slower and slower.)

                                                                                                                                            1. 7

                                                                                                                                              I personally used to be quite bad at estimating. I’ve worked at it, I’ve gotten much better about estimating. There are things you can do to get much better at it. None of the things you’ve mentioned are ones I think would help. I plan on writing a post about the things I’ve learned and taught others that have helped make estimates more accurate.

                                                                                                                                              1. 3

                                                                                                                                                That would make great reading.

                                                                                                                                                Are there any existing accounts of effective software schedule estimation you’d recommend?

                                                                                                                                                1. 1

                                                                                                                                                  Two things I would recommend (and will be primary topics of said blog post).

                                                                                                                                                  Estimates slipping is usually about not accurately accounting for risk. Waltzing with Bears is a great book on dealing with risk management. The ideas in it might be overkill for many folks but the process of thinking about how you should account for risk and establishing your own practices is invaluable. The book is great even if you only use it as “that seems overblown, what if I…”.

                                                                                                                                                  The second is to record your estimates and why you made them. What did you know at the time that you made your estimate. Then, when your estimate is wrong, examine why. What didn’t you account for? When I first started doing this, I realized that most of my estimates were wrong because I didn’t bother to explore the problem enough and that I was being tripped up by not accounting for known knowns. Eventually I got better at that and started getting tripped up by known unknowns (that’s risk). I’ve since adopted some techniques for fleshing our risks when I am estimating and then front loading working on risks. If you think something might take a week or it might take a month, work on that first. Dig in to understand the problem so you can better estimate it. Maybe the problem is way harder than you imagine and you shouldn’t be doing the project at all. This isn’t a new concept but its one that is rarely used. In agile methodologies, its usually called a “spike”.

                                                                                                                                                  I’ve worked on projects that spanned over the course of months and we spent a couple weeks on estimation and planning. A big part of that time digging in, understanding the problem better, discussing it and coming up with what we needed to explore more to really understand the project so we could course correct as we went along.

                                                                                                                                                  1. 1

                                                                                                                                                    Ooh, a DeMarco book! Will definitely check it out. Thanks!

                                                                                                                                                2. 1

                                                                                                                                                  Please do write this, I need to improve in this area.

                                                                                                                                                3. 1

                                                                                                                                                  The wish-fulfilment does not exist in a vacuum.

                                                                                                                                                  Your customers might not be happy with your team constantly running late. Your pre-revenue startup might have a hard time raising investment. Whatever. There are external reasons for why a professional developer must be reliable in his or her estimates to actually get things out the door.

                                                                                                                                                  I’ve been changing my opinion on this back and forth. Especially in a pïss-poor startup, where the the biz guys wanted us to skip unit testing to achieve results faster, refusing to estimate was a fuck you. The code base got convoluted, but also dealing with how they represented things was frustrating.

                                                                                                                                                  I feel that in those cases the problem runs deeper in how geeks are supposed to be managed. Hell, it could be that estimation starts eating up time because the managers drove the geeks into protesting, which is - of course - as unprofessional as delivering late. Still you need to sort out your org for smooth ops before taking care of estimates.

                                                                                                                                                  Yet this isn’t car repair for old vehicles, where you find more and more problems as you go along, making estimates tough without thorough diagnostics, but the customer is happy with the substitute car you gave out in the meantime.

                                                                                                                                                  1. 0

                                                                                                                                                    The fact that customers want something, or that it is necessary to the business’s success, do not cause it to become possible. I’m not disputing the desirability of accurate estimates. I’m disputing the idea that they are possible. I have not seen any team or technique generate such estimates reliably, over time, in various circumstances. (Of course, like any gambler with a “system,” sometimes people making estimates get lucky and they turn out to be right by coincidence.) I have heard many managers claim to have a system for reliable estimates which worked in some previous job; none was able to replicate that success on the teams I observed directly.

                                                                                                                                                    (It’s not just software, either. Many people point to the building trades as an example of successful estimation and scheduling. In my experience maintaining and restoring an old house and the experiences of friends and acquaintances who’ve undertaken more ambitious restorations, this is more wishful thinking. It’s common for estimates by restoration contractors on larger jobs to be off by months or years, and vast amounts of money. If so mature an industry can’t manage reliable scheduling, what hope is there for us?)

                                                                                                                                                    Yet this isn’t car repair for old vehicles, where you find more and more problems as you go along, making estimates tough without thorough diagnostics, but the customer is happy with the substitute car you gave out in the meantime.

                                                                                                                                                    I’d argue that is exactly what much software development is like (except there is no substitute for the customer).

                                                                                                                                                    1. 1

                                                                                                                                                      Maybe I’d like to be more optimistic about learning to estimate better ;) But for sure @SeanTAllen touched on a lot of pertinent points. Is it Alice or Bob who gets the task? How well is the problem space, the code, known? And so on.

                                                                                                                                                      It’s hard as balls, and you’re not wrong with your gambler analogy, but not all systems for getting things right occasionally are equally unlikely to succeed. Renovators also learn what to look out for and how long those issues tend to take, as well as the interactions. Probabilities are usually ok by customers if that’s all you got.

                                                                                                                                                      In my car analogy, the point kinda was that we’re screwed because we can’t give out substitutes. We can deliver temporary hacks, although nothing is as permanent as a temporary hack.

                                                                                                                                                4. 1

                                                                                                                                                  A lot of activities in software development try to improve predictability. For example: following style guidelines, continuous integration, unit testing, etc. All of these have a cost and slow developers down. The upside of course is to reduce bugs which will slow you down much more later. Or maybe not. The risk is generally too high, so we generally prefer the predictability of a slow incremental process.

                                                                                                                                                  I have a feeling that Demings thought about that when he talked about “variation”, but I need to read more from the father of Lean and grandfather of Agile to understand that. Currently, I believe that I don’t assign quite the correct meaning to the words I read from him.