1. 8

    On gradual refactoring:

    Gradual refactoring of a codebase, where each individual step is trivial but there’s just so many of them—and this is why big-bang rewrites often happen, because that’s just less terrible than trying to mop up a floor with a muddy mop.

    I wonder how many people are like me, but I adore slow gradual refactorings consisting of trivial steps that together form a completely unpredictable emergent results which make the code look completely different and from-another-universe better!

    Unfortunately this sort of work stops being useful pretty soon. Right after code turns from ugly to palatable, nobody wants to pay for it to become really good.

    1. 3

      I do this too. For every 2 PR’s related to an issue, I end up with another small refactor (1-10 lines) that I noticed along the way. It’s great because PR’s that small are often pretty trivial to write and test. It feels a bit like tidying up.

      1. 3

        Completely agreed. It’s the only way to actually keep tech debt at a minimum, without waiting for a “good time” to clean everything up.

    1. 1

      dont say “gems” - thats just confusing.

      1. 9

        Thanks for pointing it out. I thought it was a pretty common idiom, like in “hidden gems”.

        1. 5

          It’s okay, you can use it because Ruby is mostly dying off.

          Just don’t call them eggs!

          1. 3

            Eggs?? That’s so last century! You probably meant wheels :-)

            1. 1

              Yeah but:

              • hidden gem -> gem
              • easter egg -> egg
              • [what goes here?] -> wheels

              I’m wracking my brain for how you’d get wheels reasonably in the title!

              1. 2

                fortune wheel..

        2. 8

          Can you please tell us for how long you were confused? your comment comes across quite rude and nonconstructive (to me personally).

        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. 3

                                I’m not sure it’s inventing anything that doesn’t exist, or even new:

                                👤 => 人
                                📕 => 书
                                🏠 => 家

                                1. 1

                                  Chinese characters are basically old emoji. I use them as such in texts and it’s always great. (Still learning Chinese though, so sometimes I’m off…)

                                  Added benefit: you can write any word as a combination of “emoji”. Example: In Japanese, an emoji (絵文字) is a “picture writing letter” if you look at each individual kanji.

                                1. 3

                                  I wish every new language web site, instead of having a “hello world” example would state something like: “It’s like but with and without ”.

                                  1. 3

                                    They have a “detailed comparison”

                                    Why create V when there are already so many languages? Why not use Go, Rust, C++, Python etc?

                                    Detailed comparison of V and other languages.

                                    Clicking it though gives you “coming in March”

                                    1. 2

                                      I’ll post it today. In about 30 minutes.

                                      1. 4

                                        Did you ever post that detailed article about the C++ to V translator? If it handles legacy code, that could be your biggest achievement given how slow to compile and hard to analyze C++ is.

                                        1. 3

                                          In about 2 weeks. Not sure about all legacy. Boost for example was terrible, I gave up almost immediately for now. That’s why I’m working on Doom 3 right now, it’s written using much simpler C++.

                                          1. 3

                                            I’d be happiest to see the sqlite to v translation.

                                            Sqlite is probably one of the most used code bases on the planet.

                                            1. 2

                                              Yes, C is easy compared to C++. You’ll see it in 2 weeks.

                                        2. 2

                                          But it’s not March! :)

                                      2. 2

                                        What information do you think is missing from the landing page? I’ll add it.

                                        Right now I have 8 main features there, small FAQ, software built in V, and a link to the documentation that covers pretty much the entire language.

                                        1. 5

                                          Shapr said:

                                          “er, not available yet?

                                          I’d be more interested if I could read the source.”

                                          doug-moen said:

                                          “No GC, “safe”, and “fearless concurrency” (a feature of Rust) is a bold claim. How can this be done without the complexity of the Rust type system and borrow checker?”

                                          Descriptions on how the safety system works… esp combo of no GC, safe, and ultra-fast… along with the source to prove the description is true. Especially in a form with independent replication of claims being possible. You’re making some big claims that create excitement and skepticism. So, you should expect these reactions at a minimum. Ideally, many folks would love to test it out. If your description is true, it can already do amazing things worth an alpha release that warns of breaking changes maybe happening.

                                          1. 2

                                            It says right in the very middle of the page that it will be open sourced this summer. It’s absolutely not ready for a release right now.

                                            Fearless concurrency is achieved by making sure all variables used in different threads are locked. That’s not hard to implement.

                                            Implementing easier Rust-like memory management is very hard. Right now it’s very basic, and I manage lots of memory manually when developing Volt. I still need to figure out lots of things, but I’m 100% confident I can do this.

                                            1. 7

                                              Fearless concurrency is achieved by making sure all variables used in different threads are locked. That’s not hard to implement.

                                              Correctness in concurrency is not about locking single variables, but maintaining invariants between variables.

                                              ie. If there exists a relationship between a and b that must always hold for correct execution eg. f( a, b) must always be true, then the accesses to a and b must be locked both by the reader and mutator.

                                              Of course, as soon as you do this… you now open yourself up to deadlocks and priority inversions unless you’re careful….

                                              Of course, you can just Stop The World…. in which case you no longer have concurrency…

                                              1. 3

                                                Interesting.

                                                Could you please post a small example of this in Rust or any language you prefer?

                                                Thanks!

                                                1. 2

                                                  The thing to understand about schedulers is “unlock” whether it’s a mutex or whatever, means to the scheduler “reschedule now”. It may decide it doesn’t need to switch threads, but it will make the choice at that point.

                                                  Consider the classic bank account, the variable balance holds how much you have, and you’re not allowed to withdraw more than you have.

                                                  SImple.

                                                  if( balance >= withDrawalAmount) balance = balance - withDrawalAmount;

                                                  If you lock on each variable access it doesnt help you.

                                                  If you have two threads a race like this can still occur… Thread 1 Does if( balance >= withDrawalAmount) and then reschedules to Thread 2 which does if( balance >= withDrawalAmount)

                                                  The check succeeds for both Threads… Thread 2 continues and does… balance = balance - withDrawalAmount; ..taking all the money out of the account and reschedules back to thread 1 which does balance = balance - withDrawalAmount; rendering the account negative.

                                                  But every single variable access was locked!

                                                  You need to identify and lock across the whole transaction, not access to variables.

                                                  1. 1

                                                    OK I see, thanks.

                                                    In V you’d have to wrap the entire statement into lock{}:

                                                    lock { if balance >= withDrawalAmount { balance = balance - withDrawalAmount } }

                                                    But I understand your point. I don’t think Rust prevents you from making this locking error. It forces you to use locking, but you can still use it incorrectly like you described, right?

                                                    1. 2

                                                      Most “fearless concurrency” languages achieve this (more or less) by immutability.

                                                      The core problem in this example is we’re reading AND writing to balance from more than one thread.

                                                      If balance was immutable… no problem.

                                                      If balance was only accessible (for read and/or write) from one thread, also no problem.

                                                      Rust’s approach is basically that, the borrow checker forces only one thing to be holding at a time…. Which solves this simple class of race… but I bet a bad programmer could still do stupid in Rust by passing balance back and forth between threads with an exchange between the check and the update.

                                                      ie. Good language design can save you from simple threading issues. Nothing can save you when your code is insanely complexity and you have stupid humans writing it.

                                                      1. 2

                                                        Your V example has a gotcha…. what is it locking? ie. It will locking out all threads doing a lock even if they are not touching balance or withdrawal. ie. You won’t achieve good performance on highly parallelized tasks.

                                                        This is why things like pthreads have mutex’s that are associated with a particular resource.

                                          2. 1

                                            I wish it had both. I like examples.

                                            1. 2

                                              Hi,

                                              Developer here. There’s a large “Examples” link in the main menu :)

                                              1. 2

                                                The “hello world” ones in particular are by definition so simplistic that they hardly tell you anything about a language. A general shape of the syntax perhaps?

                                                1. 4

                                                  They give a brief overview of the language and they provide something small enough that you can type it in and get results to confirm your toolchain is properly installed.

                                                  Plus, and most importantly, tradition. :)

                                                  1. 2

                                                    Yes, I can buy the tradition argument for sure :-)

                                                  2. 1

                                                    Yes, I like it for the syntax. I think the syntax is very relevant, especially if your language doesn’t differ a lot from other languages in other ways.

                                              1. 8

                                                Half of me agrees, the other half disagrees. The half of me that disagrees thinks that I want everyone, including businesses, to use my work. That does mean I need to be open to providing at least some level of support. At the very least, I ought to communicate my schedules/plans so that “share holders” can confide in my work.

                                                But, this isn’t true for all projects I work on. I’m not going to provide the same level of support for libhijack as I will for HardenedBSD. So, the half of me that disagrees also recognizes the need for flexibility and appropriate “risk management.” After all, the amount of support a given project receives could be considered “risk.”

                                                1. 19

                                                  The difference here is between a project and a product. A project that is interested to be seen as a product should be making explicit steps for that: have a web site oriented to customers, exposed business contacts, appropriate wording in the documentation, etc. My gripe is about businesses treating all projects as products by feault.

                                                  After effecting a cultural shift about a decade ago that made businesses view OSS code seriously, we need to effect another one, by making everyone understand that dependability doesn’t come for free.

                                                  1. 1

                                                    Wholly agreed with you there. Great discussion. :)

                                                  2. 3

                                                    “The half of me that disagrees thinks that I want everyone, including businesses, to use my work. “

                                                    You’re not really disagreeing. Widespread adoption along with whatever that entails is part of your goals for HardenedBSD. Whereas, the author’s goals were different. Either way, other people freeloading off the work shouldn’t expect you to do anything past what your stated goals and preferences are. Even still, they shouldn’t expect it or criticize you much since it was purely a volunteer effort. If it matters, they can contribute something as well.

                                                    I just don’t think you’re really saying something different if we’re looking at making sure what maintainer wants and others’ needs align. You’re actively aligning the two to some degree with HardenedBSD. You’re also letting people know with your words, foundation, and so on. Others care less about adoption or putting work in. Won’t align with them. Changes how they should or might react.

                                                    1. 3

                                                      You’re not really disagreeing. Widespread adoption along with whatever that entails is part of your goals for HardenedBSD. Whereas, the author’s goals were different. Either way, other people freeloading off the work shouldn’t expect you to do anything past what your stated goals and preferences are. Even still, they shouldn’t expect it or criticize you much since it was purely a volunteer effort. If it matters, they can contribute something as well.

                                                      Fully agreed. I guess “disagree” wasn’t the right word to describe my thoughts. Sometimes I suck at choosing the right wording.

                                                  1. 18

                                                    A DSL is better than the alternative. Terribly shitty HIDDEN DSL’s embedded in yaml files … cough kubernetes cough.

                                                    1. 4

                                                      My biggest gripe as a programmer of the past ~2 years is pointing out exactly this to ops people and having been met with a blank stare not even understanding what the problem is. I guess there’s a sort of a watershed between people who sees configs as an asset vs. a liability.

                                                      1. 6

                                                        As a programmer turned ops person. This is also my biggest grip. YAML is awful as a language, it’s pretty lovely as a data format (easy to read, easy to format), but using it like Ansible or K8S does is just asking for trouble.

                                                        1. 3

                                                          Most ops people are convinced Turing completeness is evil but they have no problem putting loops in templetized YAML files.

                                                          I think it started with tools like puppet and ansible and their marketing. They needed to sell “not programming” as a hireable skill so they did. Now we’re stuck with weird DSLs that configure and manage enterprise software systems with no reasonable path out of the mess.

                                                          1. 3

                                                            I have been using https://github.com/dhall-lang/dhall-lang for configuration and like it. It has some programming capabilities, but is not turing complete. Though I think the same problem can happen of forcing a tool to do too much.

                                                            1. 1

                                                              Terminating and statically typed programmability seems like a valid tradeoff for a configuration language.

                                                      1. 2

                                                        https://highlightjs.org/ is pretty “spartan” with ~20 lines of JS and handwritten CSS, just look into view-source:. Of course, a big caveat is that it’s the site about a JavaScript library, so it won’t be as pretty with it disabled. But it works!

                                                        1. 1

                                                          syntax higlighting in javascript is one of those things that says “wtf” to me at all though, with rare exceptions. But it is static content, why not just render the semantic tags on the server - once - and have a stylesheet define the client look?

                                                          1. 1

                                                            I’m showcasing the library this way: the site is using it as it is intended to be used by others. If I were using node.js on the server, I’d probably do it there.

                                                        1. 2

                                                          I hope all of this gets fixed when the Microsoft facelift is out.

                                                          1. 2

                                                            Either you use the word “fixed” with a fair share of sarcasm, or… “you must be new here” :-)

                                                            1. 1

                                                              it was sarcasm :-)

                                                              1. 1

                                                                you got me then :-)

                                                          1. 10

                                                            I dunno. This looks like feature creep.

                                                            Want to start a conversation but no code has been written: Open an issue. You’re PR is going to fix a bug or add a feature. This starts as a issue that is discussed, voted upon and milestoned

                                                            Your PR is not ready for merging yet: Keep it in your branch/fork and keep working on it. It’s not ready for a PR. Have questions, ask it on the issue. Want a code review, request one on the issue. Or do a regular PR and request comments, because you can keep adding commits to the PR.

                                                            1. 10

                                                              Keep it in your branch/fork and keep working on it.

                                                              I suspect this doesn’t work for most people because you can’t (easily) see and comment on a diff between your branch and the base one without opening a PR. Which is exactly what they should have done instead of creating another redundant first-class entity in the already over-complicated UI.

                                                              1. 6

                                                                t’s not ready for a PR. Have questions, ask it on the issue. Want a code review, request one on the issue.

                                                                Send the patch to a mailing list and discuss it there inline within the comfort of your favorite mail client of choice.

                                                                1. 3

                                                                  Hard to deny that these days most people find a Web UI more comfortable than any of the (stagnating) mail clients. Minus the hassle of subscribing to a mailing list.

                                                                  I mean, I’m totally with you that all of that is just as easy, but most people seem to have a different perception.

                                                                  1. 4

                                                                    Minus the hassle of subscribing to a mailing list.

                                                                    This is a common misconception; there is no need to subscribe to the mailing list if it’s set up correctly. If you send your patch there, people will include you in the reply list regardless.

                                                                    I agree it’s distressing how much GMail’s near-monopoly has hurt the ecosystem and caused people to forget that better clients exist.

                                                                    1. 1

                                                                      In some cases, like work, you’re forced into GMail to avoid someone exfiltrating your IMAP synced mailbox via malware. So…

                                                                      1. 2

                                                                        Yeesh; hopefully work policies don’t prevent you from making OSS contributions with your personal mail account tho.

                                                                        1. 2

                                                                          In some cases, yes. For the types of stuff I’d do in my spare time, most likely not.

                                                                          But my guess is that this restrictive email thing will become more popular, not less, meaning that important projects, like those you get paid to work on during work hours, won’t be able to successfully support contributions that way.

                                                                          I dunno though. I could certainly be completely offbase here and we will see a resurgence of plain text email, and a new generation of mail tools. Fastmail is betting on JMAP, which uses JSON, so the barrier to entry might get much much lower in years to come…

                                                                  2. 1

                                                                    A mailing list you say? So I have to fight through all the spam, and everything else that comes with it? Should I set up a list for every single repo? Should I write my own automation for code review and assignment?

                                                                    I mean, on GitHub, I can clearly see who I requested code review from (and whether they reviewed it, and what their review is), who’s assigned to the PR/issue, what milestone it belongs to and so on. Can I do that with a mailing list? Yes, I could search, use labels, bookmarks, whathaveyou in my client of choice, but there’s no built-in thing that provides me with this information. One can build it on top of mailing lists, but then I’d use the API of that, and the mailing list would be reduced to transport only.

                                                                    As it happens, I can reply to GitHub notifications by email, from the comfort of my favourite mail client. And I get to enjoy the benefits of the API too. So no, a mailing list is not a substitute. For tiny things, or if you’ve established an email-based workflow already, it can work. For a lot of projects, it doesn’t.

                                                                    1. 2

                                                                      So I have to fight through all the spam, and everything else that comes with it?

                                                                      The last time spam got thru on any of my mailing lists was over a decade ago. (Basically never happened since I moved off Google.)

                                                                      Should I set up a list for every single repo?

                                                                      Another advantage of this setup is that you aren’t locked in to a 1:1 mapping between issue tracking and repos. You can easily set up a single mailing list to discuss patches for a group of related repositories under a single project, or a separate mailing list for a subset of development on a single large repository.

                                                                      1. 4

                                                                        The last time spam got thru on any of my mailing lists was over a decade ago. (Basically never happened since I moved off Google.)

                                                                        Lucky you. Plenty of my non-google addresses get quite a bit of spam, can’t imagine it being any different for mailing lists. The single list I run gets plenty of spam. Most are caught, but only because I spend non-negligible time making sure they are. I’d happily let go of this task.

                                                                        Another advantage of this setup is that you aren’t locked in to a 1:1 mapping between issue tracking and repos. You can easily set up a single mailing list to discuss patches for a group of related repositories under a single project, or a separate mailing list for a subset of development on a single large repository.

                                                                        I can do the same on GitHub with GitHub projects. I get e-mail notification, I can reply via e-mail, but I also have an API to access all of that information - and more - whenever I want, from wherever I may be, without having to carry my email archive around, or host my email on a server I can access on the go. I can also selectively subscribe to issues (via the API, so I don’t ever need to fire up a web browser), and get e-mail notifications. The API lets me query on labels, milestones, etc. Doing the same on a mailing list is very far from being trivial, or convenient, especially when I want to search backwards to times I weren’t subscribed yet.

                                                                        If you don’t need the labels, don’t use milestones and various other features GitHub provides, a mailing list might be a suitable alternative, and a convenient workflow. The moment you start to use these, a mailing list will stop being adequate. No, Subject: [project:subsystem bug#N]: blah is not a solution, and doesn’t work. Client-side labeling/filtering doesn’t either, because the point of labels & milestones is that they’re centralised. N+1 mailing lists for subsystems is a pain to maintain, and even bigger a pain to work with (been there, tried it, no thanks).

                                                                        In my experience, working with Magit & Forge is much more convenient than mailing patches and whatnot around.

                                                                  3. 5

                                                                    You say feature creep, I say the end of a long period of feature stagnation.

                                                                    Enough companies use Github as part of their development infrastructure – not just process – that it makes sense to have a programmatic way of flagging a PR as “not ready yet”. The rest of us will just type “[WIP]” less often. Is it that bothersome?

                                                                    1. 4

                                                                      Do you all not use a WIP label?

                                                                      1. 6

                                                                        I do, and include that same title. No one looks at labels, even if they are blinking and bright red.

                                                                        1. 2

                                                                          Reminds me of how many PRs we’ve merged that have a “Do Not Merge” label on them.

                                                                          1. 1

                                                                            We have a policy of only allowing PRs to be merged by a reviewer, never by the assignee. You may self assign as a reviewer but normally a PR will be created by one person and merged by another. If nobody has been assigned it sits until someone is.

                                                                      2. 2

                                                                        I’d prefer to open a PR to start a discussion, but I’ve worked with people who prefer to see PRs as ‘ready to go’ and get shirty when you open a PR that’s not merge-ready.

                                                                        Making it explicit is handy for dealing with people who aren’t interested in learning how to use patches-by-mail but you want a place to discuss work in progress.

                                                                      1. 3

                                                                        Missing Rust in the ML family?

                                                                        1. 2

                                                                          A much more interesting spin on this idea is to read it backwards: Open Source code should be funded from a public source. In my opinion something like a corporate tax is the only way to find it, otherwise there’s no incentive.

                                                                          1. 2

                                                                            The person holding the purse strings controls the product.

                                                                            I don’t want government setting software requirements for the rest of us.

                                                                          1. 17

                                                                            This is such an obvious thing to me, I have a hard time understanding how this can possibly not be the case already. Governments have a lot of spending power and they should use it wisely.

                                                                            1. 4

                                                                              It’s a very obvious thing for us, but unfortunately there’s a lot of people in the top of the hierarchy chain that has no idea what the hell open source is, because 1) never heard of it or 2) think it is some thing that only hobbyists do, therefore not for serious people.

                                                                              In my field (biology, public universities), until some years ago, talking about open sourcing your software would be met with a question “but aren’t you afraid that someone will steal your code?” There are still cases like that, of people that don’t provide their code for some analysis (like the case of one professor I knew that didn’t want to provide his R script that he used to determine why a certain area should be a conservation area), which is very weird to me. How is the third party going to know exactly how they came to that conclusion? ¯_(ツ)_/¯

                                                                              1. 4

                                                                                Ever heard of corruption? :-)

                                                                                1. 2

                                                                                  Big, proprietary vendors be spending big on politicians. Copyright and patent laws remained strongly in their favor. Product purchases by the government for a long time, too. That corruption probably goes a long way toward maintaining lock-in and monopolistic/oligopolistic practices. They also benefit from university, tech transfer for a decent chunk of research getting federal funding.

                                                                                  Then, the publishers make lots of money on selling articles. They don’t want them being open. So, they’re mostly fighting against that trend. I don’t know if they’re doing campaign contributions to back it up. I did read they demand copyright of most stuff submitted to those journals. So, they can resist under copyright law.

                                                                                  Plenty of incumbents with lots of reasons to like the current system.

                                                                              1. 11

                                                                                Why not just block all autoplay?

                                                                                I don’t get why so many news websites have this autoplaying video, which gets pinned when you scroll down 🤦; even without audio this seems like terrible UX design: who wants to be distracted by a bunch of moving images when reading text? I certainly don’t.

                                                                                Either I am a very special users or there are a lot of really bad web designers. I suspect it’s probably the latter. Autoplaying video is the <blink> and <marquee> of this decade.

                                                                                1. 10

                                                                                  Its because most “gifs” these days are actually just videos with no sound. This change is aiming to not break that which would cause websites to revert to the much less efficient actual gifs.

                                                                                  1. 1

                                                                                    I wouldn’t mind blocking actual animated gifs from animating without a click too.

                                                                                    1. 1

                                                                                      https://addons.mozilla.org/en-US/firefox/addon/toggleanigif/

                                                                                      (and I’m sure there’s a variant with a per-image enabling or something…)

                                                                                  2. 8

                                                                                    I strongly suspect that it is cargo-cult behaviour – someone somewhere heard that video coverts at 17x the rate of text and thus obviously it is the case that any video is therefore better than any other medium. Add in panic over shrinking ad rates, and you have the recipe for a self-destructive feedback loop.

                                                                                    Advertising is really a scourge.

                                                                                    1. 3

                                                                                      In many cases, it may have been a decision based on conversion metrics. Not cargo-culting, actual data-driven decision making.

                                                                                      Of course, data-driven decisions are only as good as the data. There is some dispute over the extent to which those metrics were real.

                                                                                      1. 7

                                                                                        I don’t even mind the autoplay video on the top of the page. I get that this can be useful.

                                                                                        What I don’t get in particular is the small video in the bottom-right corner that so many websites add. If I scroll down, then I’m clearly not interested i your fecking video, so why continue forcing it upon me? I simple stopped visiting websites that do this. It’s obnoxious beyond belief.

                                                                                        In fact, when utilized correct, autoplay doesn’t need to be bad, if it only start playing when the user focuses the tab/window and stops playing when people scroll past it.

                                                                                        It’s not very hard really.

                                                                                  1. 2

                                                                                    Despite commentators here generally touting the idea of having a cross-platform package manager, one can clearly see a theme in the comments:

                                                                                    • snap and flatpack fail to get traction across Linux
                                                                                    • nix is available on Mac but lacks adoption

                                                                                    Which is to say, it doesn’t look like most users actually want a cross-platform package manager.

                                                                                    Even more, users of various language ecosystems seem to be quite content with having another, language-specific package manager alongside the system one.

                                                                                    1. 15

                                                                                      As someone who was watching Django since its inception in 2005, and seeing Flask coming on the scene later, I’m surprised to see the same exact argument surfacing after so many years again. And it breaks my heart! Like,

                                                                                      I’d have spent twice as long ripping out the rest of Django’s bits

                                                                                      There’s no need to rip anything out. You just don’t use the bits you don’t need, simple as that. Django is just a Python library. Sure you won’t get any related integration (like supporting a novel auth scheme in the built-in admin) but that’s expected, and you don’t get that in Flask either.

                                                                                      But I always found that the bits you would want to use are usually much more thought out and polished in Django than in other frameworks. (Although I haven’t done any actual comparisons lately.)

                                                                                      1. 10

                                                                                        But I always found that the bits you would want to use are usually much more thought out and polished in Django than in other frameworks.

                                                                                        I love Flask, it’s one of my favourite web frameworks, but what you’re saying is true in a sense. See, Flask’s components are very pluggable and this makes it flexible. Flask has many modules, which I found to be unmaintained (hasn’t had updates for months/years, kinda scary). So because Flask is flexible you can just write everything yourself. Most of the time you don’t want to do that. That’s where Django shines, Django gets maintained so everything Django ships gets maintained. This is one of the strenghts Django has over Flask IMO, just because Flask gets maintained doesn’t mean that all the plugins get maintained, which is a huge weakness if you ask me. The cost of either forking and maintaining it yourself or rewriting everything from scratch are both ridiculously high. Maybe OP has the luxury of writing everything himself or forking and maintaining everything himself, but certainly not everyone can do that.

                                                                                        1. 7

                                                                                          I have seen a bunch of flask apps in my career that probably started as the simplest flask app. They all grew into chaotic collections of code, reimplementing a lot of functionality Django provides directly. Problem is that if you look at 10 flask apps they all do it subtly different.

                                                                                          So instead of setting up flask apps with the standard flask plugins and tinkering for a day or too about initializing then in the right order, you might just start with a Django project and use the parts you need.

                                                                                          If Django had a Single-App template I think many would not use flask, because Django’s multi app directory layout scares a lot of people off.

                                                                                          1. 2

                                                                                            That is exactly why I made mini-django project, I wanted a single file no install needed flask-like app that could grow as needed: https://github.com/readevalprint/mini-django/blob/master/pico_django.py

                                                                                      1. 3

                                                                                        John Gruber wouldn’t go so far out of his way to not subtly imply that this openness was somehow endemic to Mac only. But MS-DOS was exactly like that, and I’ll hazard a guess that most of the OSes of the 80s were like that.

                                                                                        1. 7

                                                                                          The Mac was in a somewhat unusual situation where the OS provided high-level APIs, and most applications used them because the actual hardware varied from machine to machine. Contrast this with MS-DOS, where the OS (or the BIOS) provided high-level APIs that people generally ignored because you could get better performance by bit-banging the VGA registers yourself.

                                                                                          1. 2

                                                                                            This is true for graphics, for which there was no powerful API. But for things like opening files and writing text to the output you still used common work horses like int 13h / int 21h.

                                                                                        1. 10

                                                                                          “small performance investigation”, with TOC alone taking a whole page :-)

                                                                                          1. 6

                                                                                            The original post rewriting in rust is of comparable length.

                                                                                            1. 3

                                                                                              The proper comparison might be the time it takes a Javascript programmer with no VM or assembly knowledge (just common heuristics) to do what he did vs Javascript programmers of similar skill to rewrite same code in Rust. I’d say the latter should also be people who already got past the fight-the-borrow-checker phase so those slowdowns don’t contaminate the measurements of the port.

                                                                                              1. 2

                                                                                                Indeed, performance shootouts between languages practically always forget to account for the developer :)

                                                                                                1. 2

                                                                                                  While we’re at it, might do an extra experiment to see how people modifying unfamiliar codebases in a time crunch improve their performance and safety together. That represents the rush it out the door mindset in many companies. Languages like Ada and Rust will be way ahead if proponents are correct.

                                                                                          1. 2

                                                                                            Oh just wait till you have to deal with other people’s code (i.e. libraries). That’s when the idea of only confining yourself to a nice subset of the language goes out the window :-)