1.  

      So presumably future Firefoxes might support this distributed Web natively by maintaining a big-ish local list of gateways?

      (I mention Firefox specifically due to its non-profit nature, as this entire idea should sound like anathema to any commercial entity.)

      1.  

        I think making each browser installation a first-class IPFS node is the right way to do that.

        Assuming Worse-Is-Better, then, sure, throw a list of gateways in there. It needs some logic though.. What happens when you click a link?

        On that blog, if you view it through Gateway A and click a link, the link points to some other resource on Gateway A. That’s how the author wrote the links; they are relative URLs. None of these Gateways touch the content, AFAIK.

        But, also on that blog are some regular http(s) links that point to gateways…

        I guess I am thinking out loud here. These gateways are themselves ordinary websites and making Firefox IPFS-aware will require some work.

    1. 3

      Incidentally, I’m looking at https://www.lambda.cd/ right now, which seems to be in the same ballpark as Drone, but probably with even less assumptions about what build steps do.

      1. 3

        Using Clojure for the build script is neat, I like it, but like many others, LambdaCD fails short on some of my key requirements:

        • Builds should be isolated, preferably running in a container.
        • It should support triggering builds on pull requests, too.

        LambdaCD doesn’t appear to do either out of the box. A quick look suggests that one can build both on top of it, but I’d rather not, when there are other options which do what I need out of the box. Still, there are some good ideas there, will be keeping an eye on it. Thanks for mentioning it!

        1. 2

          It does the triggering thing, although right now it’s a separate plugin (which they apparently want to ship with the main library at some point): https://github.com/flosell/lambdacd-git#using-web--or-post-commit-hooks-instead-of-polling

          Can you explain more about isolation? My simplistic view on it was that one could simply shell out to docker build ., and generally rely on docker itself to manage images. Am I missing some gotcha here?

          1. 3

            Yeah, that notification thing looks good enough for implementing pull requests, though the pipeline will need to be set up in every case to support that scenario, since the pipeline is responsible for pulling the source too. Thus, it must be ready to pull it from a branch, or a different ref, or tag, or whatever. Having to implement this for every single repo is not something I’d like to do. Yes, I could implement a function to do that, and remember to use it in every pipeline, but… this is something I’d expect the CI system to do for me.

            Looking further into LambdaCD, this part of the HOWTOs suggest that while pipelines are code, they are not in the same repository as the code to build. This means that when I add a new project, I need to touch two repos now. If I have a project with more than one branch, and I want to run different pipelines in the branches, this makes that much more complicated. For example, I have a master and debian/master branch: on master I do the normal CI stuff, on debian/master, I test the packaging only, or perhaps in addition; or I’m implementing a new feature, which requires a new dependency, so I want that branch to have that dependency installed too - both of these would be cumbersome. If, like in the case of Drone, or Travis, if the pipeline is part of the source repo, neither of these is a problem: I simply adjust .drone.yml / .travis.yml, and let the system deal with it.

            Additionally, if someone else implements a feature, and submits a pull request, I want them to be able to modify the pipeline, to add new dependencies, or whatever is needed for the feature. But I do not want to give them access to all of my pipelines, let alone my host system. I don’t think this can be achieved with LambdaCD’s architecture.

            Can you explain more about isolation? My simplistic view on it was that one could simply shell out to docker build ., and generally rely on docker itself to manage images. Am I missing some gotcha here?

            It’s not that easy. First, I don’t want to run docker build .. I don’t need to build a new image for every project I have. I want each of my stages to execute in a container, by default, with no other option. I do not want the pipeline to have access to the host system under normal conditions. To better highlight what goes on under the hood, lets look at an example. See this Drone control file for example, which on one hand is reasonably simple, but it achieves quite a few things.

            The dco and signature-check stages execute in parallel, in two different containers, using two different images (with the sources mounted as a volume). The latter only on tag events. Under the hood, this pulls down the image if it’s not available locally yet, runs them in docker with the sources mounted, and fails the build if any of them fail.

            The bootstrap and tls-certificate stages run parallel again, using the same image, but two containers. This way if I change anything outside of the shared source directory, that won’t cause a conflict. This allows me to install a different set of packages in parallel, and not have a conflict.

            The stable-build and unstable-build stages also run parallel, and so on.

            There’s also a riemann service running in the background, which is used for some of the test cases.

            Shelling out to docker is easy, indeed. Orchestrating all of the above - far from it. It could be implemented in LambdaCD too, with wrapper functions/macros/whatever, but this is something I don’t want to deal with, something which Drone does for me out of the box, and it’s awesome.

            1.  

              Thank you very much for such a detailed response! I’ll give it a thorough thinking because you seem to approach the problem from a completely different side from mine, so may be I need to rethink everything.

              For example, instead of having every project define its own pipeline I’d rather have a single pipeline defined in my CD system which would work for all projects. So it will have logic along the lines “if it’s the master branch deploy to production, if it’s a PR, just run tests”. For it to work, all project will have to follow conventions on how they get built, how they get tested.

              This is something I implemented successfully in the past with Jenkins, but now I’m looking for something more palatable.

              1.  

                So it will have logic along the lines “if it’s the master branch deploy to production, if it’s a PR, just run tests”.

                Yeah, that makes sense, and might be easier with a global pipeline. Perfectly doable with pipelines defined in the projects themselves too, even if that’s a bit more verbose:

                pipeline:
                  tests:
                    image: some/image
                    commands:
                      - make tests
                
                  deploy_production:
                    image: some/image
                    commands:
                      - deploy
                    when:
                      event: [push, tag]
                      branch: master
                

                With Drone, this will run tests for everything, PRs, pushing to any branch, tagging. The deploy_production stage will only be run for the master branch, and only on push and tag (this excludes PRs, pushes to any other branch, or tags that aren’t on master). Granted, with a single pipeline, this can be abstracted away, which is nicer. But per-project, in-source pipelines grant me the flexibility to change the pipeline along with the rest of the project. When adding new dependencies, or new testing steps, this is incredibly convenient, in my experience.

                Mind you, there’s no solution that fits all use cases. If you mostly have uniform projects, a global pipeline has many benefits over per-project ones. For a company with well controlled, possibly internal repos, likewise. My case is neither of those: I have a bunch of random projects, each with their own nuances, there’s very little in common. For me, a per-project pipeline is more useful.

                1.  

                  If you mostly have uniform projects, a global pipeline has many benefits over per-project ones. For a company with well controlled, possibly internal repos, likewise. My case is neither of those: I have a bunch of random projects, each with their own nuances, there’s very little in common.

                  This sums it up nicely!

      1. 10

        Were I a Windows user if I had had any doubts about switching browsers before, that right there would clench it for me. It’s like a clingy ex.

        1. 9

          For the average user this might have some pretty devastating effects. Firefox is in decline despite being technically incredible because they don’t have a powerful platform to leverage.

          It seems plausible that in the future essentially every windows user will use Edge, every Apple user uses Safari and every Android user uses Chrome. Chrome is pretty much the only browser people manually install and thats because it’s constantly pushed on users on all google pages as well as IE being horrible.

          1. 9

            It’s actually not that bad, as long as all of them agree on a common standard. And now they have to, because otherwise too much of the Web will look broken to too many users. Anything is better than a monoculture, even if it means that Mozilla who’s been pushing for this diversification all these years doesn’t get to claim winning numbers in terms of users. It doesn’t matter. Firefox’s role is to be a constant threat/challenge that keeps other browser developers honest. In a world where we already have 3 major browsers competing besides Firefox, this role just isn’t emphasized.

            And as The Beast, who once saved the world, Firefox will recede to its lair and keep vigil in case any new sons of Mammon arise from the ashes!

            1. 1

              They aren’t though. Apple regularly invents proprietary web standards when they need them and only switches to open standards when another org makes them.

            2. 1

              Do you mean that Firefox’s market share numbers are declining?

          1. 10

            I appreciate both the desire to have a formal spec which implementations can be compared against, and the desire to capture things as they really are. A spec no-one follows is worse than useless; someone will write an implementation against it, then wonder why everything else seems to do things incompatibly.

            Unfortunately, it’s very difficult to formally capture what’s arisen from a process of ad hoc implementations. I experienced this working on CommonMark; its spec is incredibly long, and isn’t even a grammar; it’s more like what WHATWG put together for the URI, for the same reasons.

            1. 6

              Bear in mind that the URL syntax did have RFCs, so it didn’t purely arise from a process of ad hoc implementations. I’m not 100% sure the RFC did actually capture what browsers were already doing, but it certainly helped in focusing the existing implementations towards a common agreement. WHATWG’s spec is a step back from that, IMO.

              1. 7

                Thing is, simply having an RFC is not enough for it to be followed. Here’s the obligatory classic link: https://web.archive.org/web/20110904005422/http://diveintomark.org/archives/2004/08/16/specs

                1. 1

                  haha, that’s a great one! I did’t know it yet. Thanks for pointing it out

                2. 5

                  WHATWG’s spec is a step back from that, IMO.

                  Agreed. It’s a pity, and now that this is done, it’d be very difficult to try to converge again on a spec in the future.

              1. 15

                This started out as a total rant about the current state of the web, insecurity and the lack of proper rigidity in specifications. I decided not to post it while I was all riled up. The next day I rewrote it in its current form. It’s still a bit one-sided as I’m still having trouble understanding their reasoning. I vainly hope they’ll either give me a more coherent explanation why they dropped the formal grammar, or actually fix it.

                1. 15

                  The formal grammar doesn’t reflect reality. The browsers started diverging from it years ago, as did the server authors. Sad, but true of many many similar specifications. The WHATWG spec a descriptive spec, not a prescriptive one: it was very carefully reverse engineered from real behaviours.

                  1. 8

                    You can model that, too. Specs trying to model C with undefined behavior or protocol operation with failure modes just add the extra stuff in there somewhere. Preferably outside of the clean, core, expected functioning. You still get the benefits of a formal spec. You just have to cover more ground in it. Also, good to do spec-based test generation run against all those clients, servers, or whatever to test the spec itself for accuracy.

                    1. 1

                      … that’s exactly what these modern bizarro algorithmic descriptions of parsers are—rigorous descriptions of real behaviors that have been standardized. “Just add the extra stuff” and this is what you get.

                      It sounds like by a “formal spec” you mean a “more declarative and less algorithmic” spec, which definitely seems worthwhile. But be clear about what you want and how it’s different from what people have been forced to do by necessity in order to keep the web running.

                      1. 1

                        By formal spec, I mean formal specification: a precise, mathematical/logical statement of the standard. A combo of English and formal spec (esp executable) with both remove ambiguities, highlight complexities, and aid correct implementation.

                        Certain formal languages also support automatic, test generation from specs. That becomes a validation suite for implementations. A formal spec also allows for verified implementations, whether partly or fully.

                        1. 2

                          I am exceedingly familiar with what a formal specification is. I am pretty sure you are confused about the difference between rigor and a declarative style—the two are entirely orthogonal. It is possible to specify something in an algorithmic style and to be entirely unambiguous, highlight complexities, aid correct implementation, and support automatic test generation, moreover, this has been done and is done extremely often—industry doesn’t use (or get to use) parser generators all the time.

                          1. 1

                            Ok, good you know it. It’s totally possible Im confused on rigor. Ive seen it used in a few different ways. How do you define it?

                            1. 2

                              Sorry for the delay, renting a car :(

                              I would define rigor as using mathematics where possible and extremely precise prose when necessary to removing ambiguity, like you pointed out. Concretely, rigor is easier to achieve when the language you are writing in is well defined.

                              If you written using mathematical notation you get the advantage of centuries of development in precision—you don’t have to redefine what a cross product or set minus or continuity are, for example, which would be very painful to do in prose.

                              Specs try to achieve the same thing by using formalized and often stilted language and relying on explicit references to other specs. Because mathematicians have had a much longer time to make their formalisms more elegant (and to discover where definitions were ambiguous—IIRC Cauchy messed up his definition of convergence and no one spotted the error for a decade!) specs are often a lot clunkier.

                              For an example of clunkiness, look at the Page Visibility API. It’s an incredibly simple API, but even then the spec is kind of painful to read. Sorry I can’t link to the specific section, my phone won’t let me. https://www.w3.org/TR/page-visibility/#visibility-states-and-the-visibilitystate-enum

                              Separately, for an example of formal methods that looks more algorithmic than you might normally expect, see NetKAT, which is a pretty recent language for programming switches. https://www.cs.cornell.edu/~jnfoster/papers/frenetic-netkat.pdf

                              Certainly web spec authors have a long way to go until they can commonly use formalisms that are as nice as NetKATs. But they still have rigor, just within the clunky restrictions imposed by having to write in prose.

                  2. 5

                    I have to parse sip: and tel: URLs (RFC-3261 and RFC-3966) for work. I started with the formal grammar specified in the RFCs (and use LPeg for the parsing) and even then, it took several iterations with the code to get it working against real-world data (coming from the freaking Monopolistic Phone Company of all places!). I swear the RFCs were written by people who never saw a phone number in their life. Or were wildly optimistic. Or both. I don’t know.

                    1. 8

                      I may hazard a guess… I watched the inception of WHATWG and used to follow their progress over several years, so I have a general feeling of what they’re trying to do in the world.

                      WHATWG was born as an anti-thesis to W3C’s effort to enforce a strict XHTML on the Web. XHTML appealed to developers, both of Web content and of user agents, because, honestly, who doesn’t want a more formal, simpler specification? The problem was that the world “in large” is not rigid and poorly lends itself to formal specifications. WHATWG realized that and attempted to simply describe the Web in all its ugliness, complete with reverse engineered error handling of non-cooperative browsers. They succeeded.

                      So I could imagine the reasoning for dropping the formal specification is due to admitting the fact that it can’t be done in a fashion compatible with the world. Sure, developers would prefer to have ABNF for URLs, but users prefer browsers where all URLs work. Sorry :-(

                      1. 3

                        This is my understanding too, but you still need to nail down some sort of “minimally acceptable” syntax for URLs to prevent further divergence and to guide new implementations.

                    1. 9

                      Minor nitpick in an otherwise excellent article.

                      I think in every Software Engineers life comes a time when he needs to decide if he wants to pursue a career in engineering or switch to management.

                      I would encourage using they instead of “he”. Small change but makes quite a lot of difference.

                      1. 8

                        By the way… Given that the author’s name is Slavic, this is most likely comes from our languages’ coordination of pronouns with the grammatical gender of the preceding word. In Russian/Ukrainian/Belorussian the word “engineer” is of male gender grammatically, so it’s inevitably followed by “he”.

                        1. 3

                          Interesting. I didn’t know that. Thanks!

                        2. 8

                          Hey, sure! Thanks for the heads up

                          1. 1

                            in my experience, it is at least an upwards move in terms of pay (not to equivocate that with worth).

                          1. 23

                            I don’t think that direction is “up” ;)

                            1. 6

                              agreed. it’s at best sideways, but in reality, it’s downward for a time. nobody will necessarily respect your opinion as management in an org just because you’ve been promoted.

                              1. 2

                                The article actually does distinguish between “moving up” and “switching from engineering to management”. It’s the title of the link here on lobste.rs that’s misleading.

                                1. 2

                                  Perhaps, this is a personal opinion of mine. I consider both moving to a Software Architect position or Management position as going up.

                                1. 1

                                  The technology in upcoming Firefox versions looks increasingly great.

                                  I would switch back in a heart beat if it wasn’t for the lack of vertical tabs. But it seems like Chrome is working on them, so Firefox might add them too.

                                  1. 5

                                    There are several add-ons for vertical tabs in Firefox, including Tab Center Redux and Tree Style Tab.

                                    1. 2

                                      Yes, I left Firefox after more than 15 years of usage after seeing these abominations. If these are the best option Mozilla allows, I’ll look elsewhere for a browser.

                                      1. 1

                                        Which browser have you found that has vertical tabs done better?

                                        1. 1

                                          I’m pretty happy with Vivaldi (it’s one of the first questions they ask on first startup – where the tabs should be placed). Here is how it looks: https://i.imgur.com/DzoJ8d9.png

                                        2. 1

                                          Haha, well, to each their own… I happily use Tree Style Tab everyday myself. I am not sure how to browse the web without it anymore… (All of these add-ons have been (re)implemented to use WebExtension APIs that isolate the browser and add-ons from each other in the last year or so… perhaps they are quite different from the last time you checked them, depending on when that was.)

                                          1. 1

                                            Yeah, I used Tree Style Tabs, too. Since Mozilla broke the old APIs without replacement, all the reimplemented extensions are an utter disappointment.

                                            I looked at different extensions right now, and I love how all extension authors carefully crop their screenshots to hide the fact that they can’t get rid of

                                            • the horizontal tab bar
                                            • the sidebar header

                                            thanks to Mozilla’s “mom knows best!” approach, which makes their extensions rather pointless.

                                            I’m so glad Mozilla isn’t in charge of an IDE/editor, because otherwise we all could start preparing to develop without syntax highlighting, because “Mozilla UX team decided it’s unnecessary”.

                                      2. 1

                                        Every time I see something like this quoted as a reason to switch browsers I’m amazed how deep control-freakery is rooted in all of us :-)

                                        1. 1

                                          Stuff like mass-market browsers are designed for the lowest common denominator of user behavior.

                                          It shouldn’t be surprising that more and more people fall outside Mozilla’s supported use cases, as Mozilla keeps pushing “our way or the highway” on how their users have to use their browser.

                                        2. 1

                                          I have been using tree tabs which works wonderfully. Even better than what I had before the web extensions migration.

                                          1. 1

                                            Just tried it, it’s rather embarrassing due to missing APIs Mozilla removed without replacement. It is pretty much the state when I left Firefox, no improvements visible.

                                        1. 3

                                          I still hope to revive mine: http://softwaremaniacs.org/blog/en/

                                          1. 4

                                            The choice of Cyrillic “counterparts” is pretty hilarious :-) For example the old Russian letter “ѵ” which we tried to get rid of since about 3 centuries ago and succeeded in that after 2 centuries since then :-)

                                            1. 24

                                              As I read this I thought about my experiences with Diaspora and Mastodon. Pages like this one or this one (click “Get Started”, I couldn’t do a deep link because JavaScript) are, IMHO, a big part of the reason these services don’t take off. How can an average user be expected to choose from a basically random list of nodes? How can I, a reasonably “technical” person, even be expected to do so?

                                              So then why not host my own node? First, I don’t have time and most people I know don’t either. If I was 15 again I totally would because I had nothing better to do. I also don’t want to play tech support for a good chunk of my social network, and providing a service to someone has a tendency to make them view you as the tech support.

                                              Second, if I do that I’m now in charge of security for my data. As terrible as Twitter and Facebook are, they’re probably still a lot better at securing my data than I am (at the very least they probably patch their systems more often than I would). Even worse, if some non-technical person decides to bite the bullet and create a node for his/her friends, how secure do you think that’s going to be?

                                              Further, what are the odds that I, or whoever is maintaining the node, basically gets bored of it one day and kills the whole thing? Pretty damn high (maybe I and all my friends are assholes, though, so whatever).

                                              Anyway, this post really spoke to me because I’ve been trying to escape Evil companies for awhile now and “federated” just doesn’t seem to be the answer. I now believe that centralized is here to stay, but that we should start looking at the organizations that control the data instead of the technology. For example, if Facebook were an open non-profit with a charter that legally prevented certain kinds of data “sharing” and “harvesting” maybe I wouldn’t have any problem with it.

                                              1. 18

                                                How can an average user be expected to choose from a basically random list of nodes?

                                                How did they choose their email provider? Not be carefully weighing the technical options, surely. They chose whatever their friends or parents used, because with working federation it doesn’t matter.

                                                what are the odds that I, or whoever is maintaining the node, basically gets bored of it one day and kills the whole thing?

                                                Same as what happened with many early email providers: when they died, people switched to different ones and told their friends their new addresses.

                                                Really, all this argument of “what if federation isn’t a holy grail” is pointless because we all already use a federated system — email — and we know for a fact that it works for humans, despite all its flaws.

                                                1. 8

                                                  How did they choose their email provider? Not be carefully weighing the technical options, surely. They chose whatever their friends or parents used, because with working federation it doesn’t matter.

                                                  In contrast to mastodon instances - which are very alike - email providers have differentiated on the interface and guarantees they provide and market that. People react to that.

                                                  1. 2

                                                    In contrast to mastodon instances

                                                    While this was largely true in the beginning, many Fediverse nodes now do market themselves based on default interface, additional features (e.g. running the GlitchSoc fork or something like it), or even using non-Mastodon software like Pleroma. I suspect this will only increase as additional implementations (Rustodon) and forks (#ForkTogether) take off and proliferate.

                                                  2. 8

                                                    How did they choose their email provider?

                                                    I think federated apps like Mastodon are fundamentally different than email providers. Most email providers are sustainable businesses, they earn money with adds or paid plans or whatever and have their own emails servers and clients with specific features. Self-hosted email servers are a minority. Please tell if I wrong, but I don’t think one can easily earn money with a Mastodon instance.

                                                    However I agree that both are federated.

                                                    1. 1

                                                      i don’t know if any nodes do this but you could charge for mastodon hosting

                                                    2. 6

                                                      You’re certainly not wrong, though I would argue that email, particularly as it was 20+ years ago when it went “mainstream”, is much simpler (for instance, it doesn’t require any long-term persistence or complicated access control) and therefore easier to federate successfully (in a way that humans can handle) than social networking.

                                                      1. 1

                                                        AP style social network federation also doesn’t require long-term persistence or complicated access control.

                                                        1. 1

                                                          email is social networking. are there particular social networking features you had in mind?

                                                          1. 3

                                                            Yeah, I listed them in my comment… “long-term persistence or complicated access control”. Admittedly I didn’t go into much detail. Email is a very simple social network, there isn’t much “meat” to it, particularly as it existed when it became popular.

                                                            1. 1

                                                              email has very long term persistence, much longer than something like facebook because it’s much easier to make backups of your emails than to make backups of your facebook interactions.

                                                              i guess i don’t know what you mean by “complicated access control.”

                                                              1. 1

                                                                Email is basically fire and forget. You download it to your computer and then you’ve got it forever (modern email does more, but also includes more of the privacy / data issues that come with other social networks). But most users can’t easily give other people on-demand access to their emails, which is the case with Facebook, Twitter, etc. Email is really meant for private communication (possibly with a large group, but still private), Facebook and company are for private, semi-private, and even public communication, and they require a user to be able to easily retroactively grant or retract permissions. Email doesn’t handle these other use-cases (this isn’t a fault of email, it doesn’t try to).

                                                            2. 2

                                                              The ability for interested parties to interact without reply all. I can post a picture of a beautiful burrito, and people can comment or ignore at their leisure, and then reply to each other. I guess there’s some preposterous email solution where I mail out a link to an ad hoc mailing list with every update and various parties subscribe, but… meh.

                                                              1. 2

                                                                something that handles a feature like that need not be email per se, but it could have a very similar design, or be built on top of email. something like what you suggested wouldn’t seem preposterous if the clients were set up to facilitate that kind of use.

                                                          2. 3

                                                            In the case of Mastodon, which instance you pick does matter. Users can make posts that are only visible to others in the same instance. If you pick the “wrong” home instance, you’ll have to make another account in another instance to see the instance-private posts there. If you’re a new Mastodon user, you might not know that one instance is good for artists and another good for musicians, etc. In any case, this is as easily solvable problem by adding descriptions and user-provided reviews to each instance.

                                                          3. 2

                                                            These ‘which instance to join’ sites are completely useless, I wish they wouldn’t exist at all.

                                                            1. 1

                                                              Second, if I do that I’m now in charge of security for my data. As terrible as Twitter and Facebook are, they’re probably still a lot better at securing my data than I am

                                                              Setting a price tag on your datas doesn’t secure them. There are enough scams and hoaxes on Facebook to share your information with other companies that I have to disagree with you. And since those social networks are collecing more data than necessary, it is easier to lose data.

                                                              1. 2

                                                                Facebook and Twitter also present single valuable targets and are thus more likely to be targeted. A hundred mastodon instances may be individually less secure due to the operators having fewer resources or less experience, but compromising a single server won’t get you as much.

                                                                1. 2

                                                                  That’s a good point, although Wordpress vulnerabilities are still a big deal even though there are tons of small servers. The server might not be a monolith, but if the software is then it’s only slightly more work to attack N instances.

                                                                  1. 1

                                                                    True, although it depends whether the vulnerabilities are in the application being served or in the web server or OS serving it.

                                                            1. 2

                                                              Here’s me feeling pangs of guilt for not ever finishing my draft of “Why OpenID has failed”… As well as loads of other incredibly insightful and impactful posts I could’ve blogged.

                                                              1. -1

                                                                As one insignificant user of this language, please stop adding these tiny edge case syntax variations and do something about performance. But I am one small insignificant user …

                                                                1. 56

                                                                  This is exactly the attitude that leads to maintainers’ burn outs.

                                                                  Do realize this:

                                                                  • Adding syntax variations is not done at the expense of performance, different volunteers are working on what’s more interesting to them.
                                                                  • Python is not a product, and you’re not a paying customer, you don’t get to say “do this instead of that” because none of the volunteer maintainers owes you to produce a language for you. Just walking by and telling people what to do with their project is at the very least impolite.
                                                                  • If you want something to happen in an open source project, volunteer to do it.

                                                                  (None of this is aimed at you personally, I don’t know who you are. I’m dissecting an attitude that you’ve voiced, it’s just all too common.)

                                                                  1. 23

                                                                    Python is not a product, and you’re not a paying customer, you don’t get to say “do this instead of that” because none of the volunteer maintainers owes you to produce a language for you. Just walking by and telling people what to do with their project is at the very least impolite.

                                                                    I agree with the general direction of your post, but Python is a product and it is marketed to people, through the foundation and advocacy. It’s not a commercial product (though, given the widespread industry usage, you could argue it somewhat is). It’s reasonable of users to form expectations.

                                                                    Where it goes wrong is when individual users claim that this also means that they need to be consulted or their consultation will steer the project to the better. http://www.ftrain.com/wwic.html has an interesting investigation of that.

                                                                    1. 2

                                                                      Where it goes wrong is when users claim that this also means that they need to be consulted or their consultation will steer the project to the better.

                                                                      Wait, who is the product being built for, if not the user? You can say I am not a significant user, so my opinion is not important, as opposed to say Google which drove Python development for a while before they focused on other things, but as a collective, users’ opinions should matter. Otherwise, it’s just a hobby.

                                                                      1. 5

                                                                        Sorry, I clarified the post: “individual users”. There must be a consultation process and some way of participation. RFCs or PEPs provide that.

                                                                        Yet, what we regularly see is people claiming how the product would be a better place if we listened to them (that, one person we never met). Or, alternatively, people that just don’t want to accept a loss in a long-running debate.

                                                                        I don’t know if that helps clarifying, it’s a topic for huge articles.

                                                                        1. 3

                                                                          I often find what people end up focusing on - like this PEP - is bike shedding. It’s what folks can have an opinion on after not enough sleep and a zillion other things to do and not enough in depth knowledge. Heck I could have an opinion on it. As opposed to hard problems like performance where I would not know where to start, much less contribute any code, but which would actually help me and, I suspect, many other folks, who are with some sighing, migrating their code to Julia, or, like me, gnashing their teeth at the ugliness of Cython.

                                                                          1. 4

                                                                            Yeah, it’s that kind of thing. I take a harsh, but well-structured opinion any time and those people are extremely important. What annoys me is people following a tweet-sized mantra to the end, very much showing along the path that they have not looked at what is all involved or who would benefit or not knowing when to let go off a debate.

                                                                    2. 17

                                                                      Adding syntax variations is not done at the expense of performance, different volunteers are working on what’s more interesting to them.

                                                                      Regrettably, a lot of languages and ecosystems suffer greatly from the incoherence that this sort of permissive attitude creates.

                                                                      Software is just as much about what gets left out as what gets put in, and just because Jane Smith and John Doe have a pet feature they are excited about doesn’t mean they should automatically be embraced when there are more important things on fire.

                                                                      1. 8

                                                                        the incoherence that this sort of permissive attitude creates

                                                                        The Haskell community would’ve just thrown PEP 572 behind {-# LANGUAGE Colonoscopy #-} and been done with it.

                                                                        Sure, this doesn’t get us out of jail free with regard to incoherence, but it kicks down the problem from the language to the projects that choose to opt-in.

                                                                        1. 2

                                                                          I find it hard to see this as a good thing. For me, it mostly highlights why Haskell is a one-implementation language… er, 2 ^ 227 languages, if ghc --supported-extensions | wc -l is to be taken literally. Of course, some of those extensions are much more popular than others, but it really slows down someone trying to learn “real world” Haskell by reading library code.

                                                                          1. 2

                                                                            Of course, some of those extensions are much more popular than others

                                                                            Yeah, this is a pretty interesting question! I threw some plots together that might help explore it, but it’s not super conclusive. As with most things here, I think a lot of this boils down to personal preference. Have a look:

                                                                            https://gist.github.com/atondwal/ee869b951b5cf9b6653f7deda0b7dbd8

                                                                        2. 4

                                                                          Yes. Exactly this. One of the things I value about Python is its syntactic clarity. It is the most decidedly un-clever programming language I’ve yet to encounter.

                                                                          It is that way at the expense of performance, syntactic compactness, and probably some powerful features that could make me levitate and fly through the air unaided if I learned them, but I build infrastructure and day in, day out, Python gets me there secure in the knowledge that I can pick up anyone’s code and at the VERY LEAST understand what the language is doing 99% of the time.

                                                                        3. 4

                                                                          I find that “people working on what interests them” as opposed to taking a systematic survey of what use cases are most needed and prioritizing those is a hard problem in software projects, and I find it curious that people think this is not a problem to be solved for open source projects that are not single writer/single user hobby projects.

                                                                          Python is interesting because it forms core infrastructure for many companies, so presumably they would be working on issues related to real use cases. Projects like numpy and Cython are examples of how people see an important need (performance) and go outside the official language to get something done.

                                                                          “If you want something to happen in an open source project, volunteer to do it.” is also one of those hostile attitudes that I find curious. In a company with a paid product of course that attitude won’t fly, but I suspect that if an open source project had that attitude as a default, it would gradually lose users to a more responsive one.

                                                                          As an example, I want to use this response from a library author as an example of a positive response that I value. This is a library I use often for a hobby. I raised an issue and the author put it in the backlog after understanding the use case. They may not get to it immediately. They may not get to it ever based on prioritization, but they listened and put it on the list.

                                                                          Oddly enough, I see this kind of decent behavior more in the smaller projects (where I would not expect it) than in the larger ones. I think the larger ones with multiple vendors contributing turn into a “pay to play” situation. I don’t know if this is the ideal of open source, but it is an understandable outcome. I do wish the hostility would decrease though.

                                                                          1. 12

                                                                            Performance has never been a priority for Python and this probably won’t change, because as you said, there are alternatives if you want Python’s syntax with performance. Also its interoperability with C is okeish and that means that the small niche of Python’s users that use it for performance critical operations that are not already supported by Numpy, Numba and so on, will always be free to go that extra mile to optimize their code without much trouble compared to stuff like JNI.

                                                                            If you want raw performance, stick to C/C++ or Rust.

                                                                            1. 3

                                                                              I also observe the same tendency of smaller projects being more responsive, but I think the issue is scale, not “pay to play”. Big projects get so much more issue reports but their “customer services” are not proportionally large, so I think big projects actually have less resource per issue.

                                                                            2. 0

                                                                              He did say “please”.

                                                                            3. 7

                                                                              please stop adding these tiny edge case syntax variations and do something about performance.

                                                                              There’s a better forum, and approach, to raise this point.

                                                                              1. 2

                                                                                I guess you are saying my grass roots campaign to displace “Should Python have :=” with “gradual typing leading to improved performance” as a higher priority in the Python world is failing here. I guess you are right :)

                                                                              2. 1

                                                                                Have you tried Pypy? Have you tried running your code through Cython?

                                                                                Have you read any of the zillion and one articles on improving your Python’s performance?

                                                                                If the answer to any of these is “no” then IMO you lose the right to kvetch about Python’s performance.

                                                                                And if Python really isn’t performant enough for you, why not use a language that’s closer to the metal like Rust or Go or C/C++?

                                                                                1. 6

                                                                                  Yes to all of the above. But not understanding where all the personal hostility is coming from. Apparently having the opinion that “Should := be part of Python” is much less important than “Let’s put our energies towards getting rid of the GIL and creating a kickass implementation that rivals C++” raises hackles. I am amused, entertained but still puzzled at all the energy.

                                                                                  1. 5

                                                                                    There was annoyance in my tone, and that’s because I’m a Python fan, and listening to people kvetch endlessly about how Python should be something it isn’t gets Ooooold when you’ve been listening to it for year upon year.

                                                                                    I’d argue that in order to achieve perf that rivals C++ Python would need to become something it’s not. I’d argue that if you need C++ perf you should use C++ or better Rust. Python operates at a very high level of abstraction which incurs some performance penalties. Full stop.

                                                                                    1. 5

                                                                                      This is an interesting, and puzzling, attitude.

                                                                                      One of the fun things about Cython was watching how the C++ code generated approaches “bare metal” as you add more and more type hints. Not clear at all to me why Python can not become something like Typed Racket, or LISP with types (I forget what that is called) that elegantly sheds dynamism and gets closer to the metal the more type information it gets.

                                                                                      Haskell is a high level language that compiles down to very efficient code (barring laziness and thunks and so on).

                                                                                      Yes, I find this defense of the slowness of Python (not just you but by all commentators here) and the articulation that I, as one simple, humble user, should just shut up and go away kind of interesting.

                                                                                      I suspect that it is a biased sample, based on who visits this post after seeing the words “Guido van Rossum”

                                                                                      1. 8

                                                                                        My hypothesis is that people who want performance are minority among Python users. I contributed to both PyPy and Pyston. Most Python users don’t seem interested about either.

                                                                                        1. 3

                                                                                          For me that has been the most insightful comment here. I guess the vast majority of users employ it as glue code for fast components, or many other things that don’t need performance. Thanks for working on pypy. Pyston I never checked out.

                                                                                        2. 5

                                                                                          Not clear at all to me why Python can not become something like Typed Racket, or LISP with types (I forget what that is called) that elegantly sheds dynamism and gets closer to the metal the more type information it gets.

                                                                                          Isn’t that what mypy is attempting to do? I’ve not been following Python for years now, so really have no horse in this race. However, I will say that the number of people, and domains represented in the Python community is staggering. Evolving the language, while keeping everyone happy enough to continue investing in it is a pretty amazing endeavor.

                                                                                          I’ll also point out that Python has a process for suggesting improvements, and many of the core contributors are approachable. You might be better off expressing your (valid as far as I can see) concerns with them, but you might also approach this (if you care deeply about it) by taking on some of the work to improve performance yourself. There’s no better way to convince people that an idea is good, or valid than to show them results.

                                                                                          1. 4

                                                                                            Not really. Mypy’s goal is to promote type safety as a way to increase program correctness and reduce complexity in large systems.

                                                                                            It doesn’t benefit performance at all near as I can tell, at least not in its current incarnation.

                                                                                            Cython DOES in fact do this, but the types you hint with there are C types.

                                                                                            1. 2

                                                                                              Ah, I thought maybe MyPy actually could do some transformation of the code, based on it’s understanding, but it appears to describe itself as a “linter on steroids,” implying that it only looks at your code in a separate phase before you run it.

                                                                                              Typed Racket has some ability to optimize code, but it’s not nearly as sophisticated as other statically typed languages.

                                                                                            2. 3

                                                                                              Be aware that even Typed Racket still has performance and usability issues in certain use cases. The larger your codebase, the large the chance you will run into them. The ultimate viability of gradual typing is still an open question.

                                                                                            3. 3

                                                                                              In no way did I imply that you should “shut up and go away”.

                                                                                              What I want is for people who make comments about Python’s speed to be aware of the alternatives, understand the trade-offs, and generally be mindful of what they’re asking for.

                                                                                              I may have made some false assumptions in your case, and for that I apologize. I should have known that this community generally attracts people who have more going on than is the norm (and the norm is unthinking end users posting WHY MY CODE SO SLOW?

                                                                                              1. 2

                                                                                                Hey, no problem! I’m just amused at the whole tone of this set of threads set by the original response (not yours) to my comment, lecturing me on a variety of things. I had no idea that (and can’t fathom why) my brief comment regarding prioritization decisions of a project would be taken so personally and raise so much bile. What I’m saying is also not so controversial - big public projects have a tendency to veer into big arguments over little details while huge gaps in use cases remain. I saw this particular PEP argument as a hilarious illustration of this phenomenon in how Python is being run.

                                                                                                1. 3

                                                                                                  Thinking about this a little more - sometimes, when languages ‘evolve’ I feel like they forget themselves. What makes this language compelling for vast numbers of programmers? What’s the appeal?

                                                                                                  In Python’s case, there are several, but two for sure are a super shallow learning curve, and its tendency towards ‘un-clever’ syntax.

                                                                                                  I worry that by morphong into something else that’s more to your liking for performance reasons, those first two tenets will get lost in the shuffle, and Python will lose its appeal for the vast majority of us who are just fine with Python’s speed as is.

                                                                                                  1. 1

                                                                                                    Yes, though we must also remember that as users of Python, invested in it as a user interface for our code ideas, we are resistant to any change. Languages may lose themselves, but changes are sometimes hugely for the better. And it can be hard to predict.

                                                                                                    In Python’s 2.x period, what we now consider key features of the language, like list comprehensions and generator expressions and generators, were “evolved” over a base language that lacked those features altogether, and conservatives in the community were doubtful they’d get much use or have much positive impact on code. Likewise for the class/type system “unification” before that. Python has had a remarkable evolutionary approach over its long 3-decade life, and will continue to do so even post-GvR. That may be his true legacy.

                                                                                        3. 1

                                                                                          Heh. I think this is an example of the Lobste.rs rating system working as it should :) I posted an immoderate comment borne of an emotional response to a perfectly reasonable reply, and end up with a +1: +4 -2 troll, -1 incorrrect :)

                                                                                      1. 31

                                                                                        Software correctness is not a developer decision, it’s largely a business decision guided by cost management. I mean depending on where you work and what you work on the software may be so stable that when you try to point out a problem the business will simply point out that the software is correct because it’s always correct and that you’re probably just not understanding why it is correct. Apps are buggy mostly when the costs of failure to the business are low or not felt by management.

                                                                                        1. 5

                                                                                          Came here to say exactly this.

                                                                                          There is no barrier to entry or minimum bar for consideration in software.

                                                                                          So you end up with thousands of businesses saying variations of “our budget is $1000 and we want you to make a software that …”.

                                                                                          Then of course you are going to see lots of failure in the resulting software.

                                                                                          The choice often ends up being “spend 10,000x and make it super robust” or “live with bugs”.

                                                                                          No business chooses the first option when you can say “oops sorry that was a bug we just fixed it. thank you! :)”.

                                                                                          This pattern persists even as the cost of developing software comes down. Meaning if you reduce the cost of producing flawless software to $X the market will choose a much more buggy version that costs a fraction of $X because the cost of living with those bugs is still much lower than the cost of choosing a flawless one.

                                                                                          1. 15

                                                                                            I recently moved to financial software development, and it seems everybody has real life experience of losing huge sums of money to a bug, and everybody, including management and trading, is willing to try practice to reduce bugs. So I became more convinced that it is the cost of bugs that matters.

                                                                                            1. 1

                                                                                              While this is true, don’t you think this is sort of… pathetic? Pretty harsh, I couldn’t come up with a better word on the spot. What I mean is, this is basically “those damn suits made us do it”.

                                                                                              1. 1

                                                                                                Not really.

                                                                                                Would you like your mobile phone screen to be made bullet proof and have it cost $150M?

                                                                                                Would you like an atomic bedside alarm clock for $500k?

                                                                                                A light bulb that is guaranteed to not fail for 200 years for $1,000?

                                                                                                It’s a real trade-off and there’s a line to be drawn about how good/robust/reliable/correct/secure you want something to be.

                                                                                                Most people/businesses can live with software with bugs and the cost of aiming for no bugs goes up real fast.

                                                                                                Taking serious steps towards improving software quality is very time consuming and expensive so even those basic first steps wont be taken unless it’s for something critical such as aircraft or rocket code.

                                                                                                For non-critical software often there’s no huge difference between 0 bugs or 5 bugs or 20 bugs. So there isn’t a strong incentive to try so hard to reduce the bugs from their initial 100 to 10 (and to keep it there).

                                                                                                The case that compels us to eliminate bugs is where it is something to the effect of “no bugs or the rocket crashes”.

                                                                                                Also you have to consider velocity of change/iteration in that software. You can spend tons of resources and have your little web app audited and certified ast it is today but you have to think of something for your future changes and additions too.

                                                                                                As the technology improves the average software should become better in the same way that the average pair of shoes or the average watch or the average tshirt becomes better.

                                                                                                1. 1

                                                                                                  Would you like your mobile phone screen to be made bullet proof and have it cost $150M?

                                                                                                  Quite exaggerated, but I get your point. The thing is — yes, I personally would like to pay 2-3x for a phone if I can be SURE it won’t degrade software-wise. I’m not worried about hardware (as long as the battery is replaceable), but I know that in 2-3 major OS updates it will feel unnecessarily slow and clunky.

                                                                                                  Also you have to consider velocity of change/iteration in that software

                                                                                                  Oh, man, that’s whole other story… I can’t remember the last time I wanted software to update. And the only two reasons I do update usually are:

                                                                                                  1. It annoys me until I do;
                                                                                                  2. It will hopefully fix some bugs introduced due to this whole crazy update schedule in the first place.

                                                                                                  Most people/businesses can live with software with bugs and the cost of aiming for no bugs goes up real fast.

                                                                                                  Which brings us back to my original point: we got used to it and we don’t create any significant pressure.

                                                                                              2. 1

                                                                                                Businesses that allow buggy code to ship should probably be shamed into better behavior. They exist because the bar is low, and would cease to exist with a higher bar. Driving them out of business would be generally desirable.

                                                                                                A boycott would need to start or be organized by developers, since developers are the only people who know the difference between a circumstance where a high-quality solution is possible but difficult, a circumstance where a high-quality solution is trivial but rare for historical reasons, and a situation where all solutions are necessarily going to run up against real, mathematical restrictions.

                                                                                                (Also, most code in existence isn’t being developed in a capitalist-corporate context, and the most important code – code used by everybody – isn’t being developed in that context either. We can and should expect high quality from it, because there’s no point at which improving quality becomes “more than my job’s worth”.)

                                                                                              3. 3

                                                                                                it’s largely a business decision guided by cost management.

                                                                                                I don’t agree about the cost management reasoning. Rather it is a business decision that follows what customers actually want. And customers actually do prefer features over quality. No matter how much it hurts our pride in craftsmanship…

                                                                                                The reason we didn’t see it before software is that other fields simply don’t have this trade off as an option: buildings and cars can’t constantly grow new physical features.

                                                                                                1. 3

                                                                                                  Speed / Quality / Cost

                                                                                                  Pick two

                                                                                                  You can add on features to cars, and buildings, and the development process does sometimes go on and on forever. The difference is if your cow clicker game has a game breaking bug, typically nobody literally dies. There exists software where people do die if there are serious bugs and in those scenarios they either compromise in speed or cost.

                                                                                                  We’ve seen this before software in other fields, and they do have this trade off as an option, you just weren’t in charge of building it. The iron triangle predates software though I do agree scope creep is a bigger problem in software it is also present in other industries.

                                                                                                2. 4

                                                                                                  I agree. I suppose this is another thing that we should make clear to the general public.

                                                                                                  But the problem I’m mostly focusing on is the problem of huge accidental complexity. It’s not business or management who made us build seemingly infinite layers and abstractions.

                                                                                                  1. 12

                                                                                                    It’s not business or management who made us build seemingly infinite layers and abstractions.

                                                                                                    Oh it definitely was. The waterfall process, banking on IBM/COBOL/RPG, CORBA, endless piles of objects everywhere, big company apps using obfuscated formats/protocols, Java/.NET… these were middle managers and consultants forcing bullshit on developers. Those bandwagons are still going strong. Most developers stuck on them move slower as a result. The management solution is more bullshit that looked good in a PowerPoint or sounded convincing in a strip club with costs covered by a salesperson. The developers had hardly any say in it at all.

                                                                                                    With that status quo, we typically are forced to go with two options: build the new thing on top of or within their pile of bullshit; find new niches or application areas that let us clean slate stuff. Then, we have to sell them on these whether internally or externally. Doing that for stuff that’s quality-focused rather than feature/buzzword-focused is always an uphill battle. So, quality-focused software with simple UI’s aren’t the norm. Although developers and suppliers cause problems, vast majority of status quo is from demand side of consumers and businesses.

                                                                                                    1. 3

                                                                                                      It isn’t? Most managers I’ve met come and see me saying, we dont want to have to think about this, so build on top of this abstraction of it. They definitely do not want us wiping the slate clean and spending a lot of time rebuilding it anew, that would be bad for business.

                                                                                                  1. 4

                                                                                                    What does this do better than the canvas element? And why is it specifically part of CSS?

                                                                                                    1. 4

                                                                                                      The houdini project aims to let you polyfill (future) CSS features rather than waiting for them to be implemented everywhere.

                                                                                                      Once houdini support rolls out to all your target browsers, you won’t have to write a bunch of fallback CSS.

                                                                                                      1. 4

                                                                                                        This is what happens when excitement overrules sane design principles. People seem to have all but forgotten about why we tried to separate HTML, CSS and JS. Now it seems to converge on the idea of everything being a JS library and JS being a structure of the Web, instead of HTML.

                                                                                                        1. 1

                                                                                                          I don’t see it that way at all. The practical implication of the Houdini features (viewed in total, not just this piece of them), at least aspirationally, will be that it’s easier to factor custom design elements into their declarative parts and their procedural parts. There’s a lot of black-box complexity within CSS as it currently stands, and it makes sense to open that up so it can be extended and modified.

                                                                                                          1. 1

                                                                                                            But then you lose predictability. It’s one thing for a browser to optimize CSS knowing exactly how it works, but as soon as you have to accommodate arbitrary imperative code from outside all optimization bets are usually off.

                                                                                                            1. 2

                                                                                                              I take that point for sure, but it’s really a performance concern rather than a code health one, isn’t it? I defer to browser vendors as to whether Houdini will hurt performance unacceptably; I don’t feel qualified to have an opinion.

                                                                                                      1. 2

                                                                                                        I’m pretty much totally in support of this thesis. Simplicity is imperative.

                                                                                                        Interesting cultural note: the Hacker News crowd pretty much disagreed (https://news.ycombinator.com/item?id=17489934). Most of the commenters there thought that correctness should be first.

                                                                                                        1. 5

                                                                                                          My own revelation was understanding that correctness is not a state, but a process: you get to the correct code iteratively through fixing bugs. Simplicity, thus, should come first as it helps (or even required) getting there.

                                                                                                        1. 16

                                                                                                          Complicated software breaks. Simple software is more easily understood and far less prone to breaking: there are less moving pieces, less lines of code to keep in your head, and fewer edge cases.

                                                                                                          Sometimes code is complicated because the problem is complicated.

                                                                                                          And sometimes the simple solution is wrong, even for something as basic as averaging two numbers.

                                                                                                          1. 3

                                                                                                            But there’s a difference here: a code is simple when it doesn’t introduce (too much of) its own accidental complexity. The innate complexity of the field is out of the equation, can’t do anything about it. But the code must strive to express its intent as simple as possible. It’s not a contradictory goal.

                                                                                                            1. 3

                                                                                                              No, it’s not the problem that’s complicated, it’s the underlying platform on which they chose to develop. You wouldn’t have that bug in Common LISP, Ruby, or any environment with big nums.

                                                                                                                1. 1

                                                                                                                  Funny as he is, there were systems- and performance-oriented variants of LISP that either stayed low-level or produced C output that was low-level. They were really fast with many advantages of LISP-like languages. PreScheme was an early one. My current favorite, since they beat me to my idea of C-like Scheme, was ZL where authors did C/C++ in Scheme. With Scheme macros, one might pick the numeric representation that worked best from safest to fastest. Even change it over time if you had to start with speed on weak hardware but hardware got better.

                                                                                                                  These days, we even have type-safe and verified schemes for metaprogramming that might be mixed with such designs. So, you get clean-looking code that generates the messy, high-performance stuff maybe in verified or at least type-checked way. People are already doing similar things for SIMD. And you’re still using x86! And if you want, you can also use a VIA x86 CPU so you can say hardware itself was specified and verified in LISP-based ACL2. ;)

                                                                                                                  1. 1

                                                                                                                    What if you try to help the process along by immersing both objects in water?

                                                                                                                2. 3

                                                                                                                  I’m not sure this really rebuts the claim. Is complicated code that solves complicated problems immune from breaking?

                                                                                                                  Also, I don’t think he recommended stopping at simple and ignoring correct.

                                                                                                                  1. 3

                                                                                                                    Is complicated code that solves complicated problems immune from breaking?

                                                                                                                    It’s more that some problem cannot be solved with simple code, because you can’t capture the whole complexity of the problem without writing a lot of code to capture it.

                                                                                                                    Consider tax code. Accurately following tax law is going to be messy because tax law itself is messy.

                                                                                                                    1. 1

                                                                                                                      Definitely not. If you have simple but wrong, it’s no good by definition. You can “not have” fast, but essentially, you still need “fast enough”. If you can accomplish the task, and you can do so simply and correctly, but can’t work it quick enough for real-life workloads, then in those cases you might as well call it broken.

                                                                                                                      1. 1

                                                                                                                        I am put in mind of the quote:

                                                                                                                        You can make simple software with obviously no defects, or complicated software with no obvious defects.

                                                                                                                        I don’t even think “correct” software is required–for many lucrative things, you have a human being interpreting the results, and oftentimes incorrect or wrong output can still be of commercial value.

                                                                                                                        That’s why we have customer support folks. :)

                                                                                                                        1. 2

                                                                                                                          This is a misquote of C.A.R. Hoare:

                                                                                                                          I conclude there are two ways of constructing software design: one way is to make it so simple there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

                                                                                                                          Nothing wrong with a misquote btw, as it means you internalized the statement rather than regurgitating the words :).

                                                                                                                      2. 1

                                                                                                                        If I understand correctly (hah), his point is that if you aim for simplicity, it’s easier to ensure correctness.

                                                                                                                      1. 8

                                                                                                                        Given that most popular email clients these days are awful and can’t handle basic tasks like “sending email” properly

                                                                                                                        I agree with the sentiment in general, but once you’re in the position where everybody else does it wrong and you’re the last person on the planet that does it right, then maybe it’s time to acknowledge that the times have changed and that the old way has been replaced by the new way and that maybe it is you who is wrong and not everybody else.

                                                                                                                        And I’m saying this as a huge fan of plain-text only email, message threading and inline quotes using nested > to define the quote level.

                                                                                                                        It’s just that I acknowledge that I have become a fossil as the times have changed.

                                                                                                                        1. 3

                                                                                                                          once you’re in the position where everybody else does it wrong and you’re the last person on the planet that does it right

                                                                                                                          Thankfully we haven’t reached this position for email usage on technical projects. Operating systems, browsers, and databases still use developer mailing lists, and system programmers know how to format emails properly for the benefit of precise line-oriented tools.

                                                                                                                          I acknowledge that I have become a fossil as the times have changed

                                                                                                                          If the technology and processes you prefer have intrinsic merit, then why regretfully and silently abandon them? I’m not saying we should refuse to cooperate on interesting new projects simply because they use slightly worse development processes. But we should let people know about the existence of other tools and ways to collaborate, and explain the pros and cons.

                                                                                                                          1. 2

                                                                                                                            If the technology and processes you prefer have intrinsic merit, then why regretfully and silently abandon them?

                                                                                                                            Because when I didn’t, people were complaining about my quoting style, not understanding which part of the message was mine and which wasn’t and complaining that me stripping off all the useless bottom quote caused them to lose context.

                                                                                                                            This was a fight it didn’t feel worth fighting.

                                                                                                                            I can still use my old usenet quoting habits when talking to other old people on mailing lists (which is another technology on the way out it seems), but I wouldn’t say that the other platforms and quoting styles the majority of internet users use these days are wrong.

                                                                                                                            After all, if the maiority uses them, it might as well be the thing that finally helped the “other” people to get online to do their work, so it might very well be time for our “antiquated” ways to die off.

                                                                                                                          2. 1

                                                                                                                            I’d like to try to convince you that it’s _good* that plain text email is no longer the norm.

                                                                                                                            First, let’s dispense with a false dichotomy: I’m not a fan of HTML emails that are heavy on layout tables and (especially) images with no text equivalents. Given my passion for accessibility (see my profile), that should come as no surprise.

                                                                                                                            But HTML emails are good for one thing: providing hyperlinks without exposing URLs to people. As much as good web developers aim for elegant URLs, the fact remains that URLs are for machines, not people. A hyperlink with descriptive text, where the URL is available if and only if the reader really wants it, is more humane.

                                                                                                                            For longer emails, HTML is also good for conveying the structure of the text, e.g. headingsg and lists.

                                                                                                                            Granted, Markdown could accomplish the same things. But HTML email actually took off. Of course, you could hack together a system that would let you compose an email in Markdown and send it in both plain text and HTML. For folks like us that don’t prefer WYSIWYG editors, that might be the best of all worlds.

                                                                                                                            1. 2

                                                                                                                              But HTML emails are good for one thing: providing hyperlinks without exposing URLs to people.

                                                                                                                              That doesn’t come without a huge cost. People don’t realize that they need to know the underlying URL and don’t care to pay attention to it. That leads to people going places they didn’t expect or getting phished and the like.

                                                                                                                              Those same people probably wouldn’t notice the difference between login.youremail.com and login.yourema.il.com either, though. So I’m not saying the URL is the solution but at least, putting it in front of you, gives you a chance.

                                                                                                                              1. 2

                                                                                                                                As much as good web developers aim for elegant URLs, the fact remains that URLs are for machines, not people.

                                                                                                                                I’m not sure about this… at least the whole point of DNS is to allow humans to understand URLs. Unreadable URLs seem to be a relatively recent development in the war against users.

                                                                                                                                1. 2

                                                                                                                                  Not only do I completely agree with you but you are also absolutely right about that.

                                                                                                                                  Excerpt from section 4.5 of the RFC3986 - Uniform Resource Identifier (URI): Generic Syntax:

                                                                                                                                  Such references are primarily intended for human interpretation
                                                                                                                                  rather than for machines, with the assumption that context-based
                                                                                                                                  heuristics are sufficient to complete the URI [...]
                                                                                                                                  

                                                                                                                                  BTW, the above URL is a perfect example of how one should look like.

                                                                                                                                2. 1

                                                                                                                                  Personally, I hate HTML in email - I don’t think it belongs there. Mainly, for the very reasons you had just mentioned.

                                                                                                                                  Let’s take phishing, for example - and spear phishing in particular. At an institution where I work, people - especially those at the top - are being targeted. And it’s no longer click here-type of emails - institutional HTML layouts are being used to a great effect to collect people’s personal data (passwords, mainly). With the whole abstraction people cannot distinguish whether an email, or even a particular link, is genuine.

                                                                                                                                  When it comes it the structure itself, all of that can be achieved with plain text email - the conventions used predate Markdown, BTW, and are just as readable as they were several decades ago.

                                                                                                                                  1. 1

                                                                                                                                    are these conventions well-defined? is there some document which describes conventions for stuff like delimiting sections of plain text emails?

                                                                                                                                    1. 1

                                                                                                                                      are these conventions well-defined? is there some page which describes conventions for stuff like delimiting sections of plain text emails?

                                                                                                                                  2. 1

                                                                                                                                    It’s just that I acknowledge that I have become a fossil as the times have changed.

                                                                                                                                    Well, there are just too many of us fossils to acknowledge this just yet.

                                                                                                                                  1. 1

                                                                                                                                    Thank you.

                                                                                                                                    1. 15

                                                                                                                                      Rust on the 7th place with 1 million LOC is actually pretty cool for Firefox! Didn’t think it has taken over that much already.