1.  

    By the author of Chicken Scheme, right? Looks really interesting. Anyone here have any example code written in it I can look at? Curious to see some real code.

    1.  

      Some libraries and example programs can be found here: https://gitlab.com/b2495/flenglibs, but note that this is all relatively new and has undergone very little testing.

      1.  

        I was confused looking at the repo full of Haskell files until I realized .ghc isn’t the Haskell file extension and these files contain FLENG code. Just curious, why .ghc instead of .fl(eng)?

        1.  

          So the manual says:

          If the source file name has an .fl or .fleng extension, then the “fleng” driver assumes it contains FLENG code. In all other cases the file is considered to be an FGHC or Strand source file.

          and:

          Additionally a front end for “Flat Guarded Horn Clauses” (FGHC)[2] and “Strand”[5] is provided, which are slightly higher level and more convenient languages.

          I haven’t taken a deeper look, but I assume FLENG is too minimal for general programming.

          1.  

            Huh, ok. Thanks.

        2.  

          Interesting. It looks quite a bit like simple Haskell code, i.e. pure functional. Is that a reasonable intuition? I’ve never really understood how logic programming can be used for normal application development.

          1.  

            Indeed, logic programming is purely functional (if you disregard assertions to a database in Prolog or non-standard extensions like global variables). Concurrent logic languages usually have a somewhat simpler control flow than Prolog, though - most dialects have no backtracking, e.g. are what is called “committed choice” languages.

            But there is no reason why logic languages should be less capable of application development than other functional languages, it just depends on the libraries. The only obstacle is IMHO a sparse implementation landscape, lack of easy to use “glue” to use foreign code effectively and the effort needed to learn a paradigm that differs strongly from mainstream languages.

            1.  

              Wouldn’t Prolog et al more commonly (and correctly) be described as relational, rather than functional? (Because a predicate can map an element in its domain to many elements in the co-domain, hence generalizing functions.) In any case, the point about purity is the important one and I think the great similarities between functional and logic programming languages are not often appreciated, maybe because of the differences in syntax or the fact that most logic programming languages are dynamically typed (in contrast to most pure functional languages).

      1. 12

        Today I was being polite and held the door for someone, but they looked like they wouldn’t be paying me for doing that, so I slammed the door at them and broke their fucking face. I can’t believe anybody is endorsing this behavior.

        1. 6

          Exactly. There are two very different scenarios:

          I hold the door open for you but my hand slips and it shuts on you and you get hurt. This is the kind of scenario where the disclaimer of warranty in most open source licenses covers: you made a best-effort attempt to do the nice thing, you failed, and someone got hurt.

          I hold the door open for you and then slam it in your face as you get here. This is actively malicious behaviour that causes actual harm. In the metaphor, this would likely be covered by something like actual bodily harm. In the scenario in the article, this is likely covered by computer misuse laws. No disclaimer of warranty protects you.

          1. 3

            Can you un-publish a library on npm, and what happens if you do? If so, a third scenario would appear:

            I stop opening the door for you and you run into it because you expected me to open it.

            1. 1

              Un-publish in NPM has rules. If the door is not used that much (or just built in yesterday), you can leave it closed as you want.

              1. 1

                It is in fact what happened back in 2016 with the infamous left-pad incident.

          1. 57

            The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on ’colors and ‘faker’.

            I wonder if the person who wrote this actually knows what “bricked” means.

            But beyond the problem of not understanding the difference between “bricked” and “broke”, this action did not break any builds that were set up responsibly; only builds which tell the system “just give me whatever version you feel like regardless of whether it works” which like … yeah, of course things are going to break if you do that! No one should be surprised.

            Edit: for those who are not native English speakers, “bricked” refers to a change (usually in firmware on an embedded device) which not only causes the device to be non-functional, but also breaks whatever update mechanisms you would use to get it back into a good state. It means the device is completely destroyed and must be replaced since it cannot be used as anything but a brick.

            GitHub has reportedly suspended the developer’s account

            Hopefully this serves as a wakeup call for people about what a tremendously bad idea it is to have all your code hosted by a single company. Better late than never.

            1. 24

              There have been plenty of wakeup calls for people using Github, and I doubt one additional one will change the minds of very many people (which doesn’t make it any less of a good idea for people to make their code hosting infrastructure independent from Github). The developer was absolutely trolling (in the best sense of the word) and a lot of people have made it cleared that they’re very eager for Github to deplatform trolls.

              I don’t blame him certainly; he’s entitled to do whatever he wants with the free software he releases, including trolling by releasing deliberately broken commits in order to express his displeasure at companies using his software without compensating him in the way he would like.

              The right solution here is for any users of these packages to do exactly what the developer suggested and fork them without the broken commits. If npm (or cargo, or any other programming language ecosystem package manager) makes it difficult for downstream clients to perform that fork, this is an argument for changing npm in order to make that easier. Build additional functionality into npm to make it easier to switch away from broken or otherwise-unwanted specific versions of a package anywhere in your project’s dependency tree, without having to coordinate this with other package maintainers.

              1. 31

                The developer was absolutely trolling (in the best sense of the word)

                To the extent there is any good trolling, it consists of saying tongue-in-cheek things to trigger people with overly rigid ideas. Breaking stuff belonging to people who trusted you is not good in any way.

                I don’t blame him certainly; he’s entitled to do whatever he wants with the free software he releases, including trolling by releasing deliberately broken commits in order

                And GitHub was free to dump his account for his egregious bad citizenship. I’m glad they did, because this kind of behavior undermines the kind of collaborative trust that makes open source work.

                to express his displeasure at companies using his software without compensating him in the way he would like.

                Take it from me: the way to get companies to compensate you “in six figures” for your code is to release your code commercially, not open source. Or to be employed by said companies. Working on free software and then whining that companies use it for free is dumbshittery of an advanced level.

                1. 31

                  No I think the greater fool is the one who can’t tolerate changes like this in free software.

                  1. 1

                    It’s not foolish to trust, initially. What’s foolish is to keep trusting after you’ve been screwed. (That’s the lesson of the Prisoner’s Dilemma.)

                    A likely lesson companies will draw from this is that free software is a risk, and that if you do use it, stick to big-name reputable projects that aren’t built on a house of cards of tiny libraries by unknown people. That’s rather bad news for ecosystems like node or RubyGems or whatever.

                  2. 12

                    Working on free software and then whining that companies use it for free is dumbshittery of an advanced level.

                    Thankyou. This is the point everybody seems to be missing.

                    1. 49

                      The author of these libraries stopped whining and took action.

                      1. 3

                        Worked out a treat, too.

                        1. 5

                          I mean, it did. Hopefully companies will start moving to software stacks where people are paid for their effort and time.

                          1. 6

                            He also set fire to the building making bombs at home, maybe he’s not a great model.

                            1. 2

                              Not if you’re being responsible and pinning your deps though?

                              Even if that weren’t true though, the maintainer doesn’t have any obligation to companies using their software. If the company used the software without acquiring a support contract, then that’s just a risk of business that the company should have understood. If they didn’t, that’s their fault, not the maintainer’s - companies successfully do this kind of risk/reward calculus all the time in other areas, successfully.

                              1. 1

                                I know there are news reports of a person with the same name being taken into custody in 2020 where components that could be used for making bombs were found, but as far as I know, no property damage occurred then. Have there been later reports?

                              2. 3

                                Yeah, like proprietary or in-house software. Great result for open source.

                                Really, if I were a suit at a company and learned that my product was DoS’d by source code we got from some random QAnon nutjob – that this rando had the ability to push malware into his Git repo and we’d automatically download and run it – I’d be asking hard questions about why my company uses free code it just picked up off the sidewalk, instead of paying a summer intern a few hundred bucks to write an equivalent library to printf ANSI escape sequences or whatever.

                                That’s inflammatory language, not exactly my viewpoint but I’m channeling the kind of thing I’d expect a high-up suit to say.

                      2. 4

                        There have been plenty of wakeup calls for people using Github, and I doubt one additional one will change the minds of very many people

                        Each new incident is another feather. For some, it’s the last one to break the camel’s back.

                        1. 4

                          in order to express his displeasure at companies using his software without compensating him in the way he would like.

                          This sense of entitlement is amusing. This people totally miss the point of free software. They make something that many people find useful and use (Very much thanks to the nature of being released with a free license, mind you), then they feel in their right to some sort of material/monetary compensatiom.

                          This is not miss universe contest. It’s not too hard to understand that had this project been non free, it would have probably not gotten anywhere. This is the negative side of GitHub. GitHub has been an enormously valuable resource for free software. Unfortunately, when it grows so big, it will inevitably also attract this kind of people that only like the free aspect of free software when it benefits them directly.

                          1. 28

                            This people totally miss the point of free software.

                            An uncanny number of companies (and people employed by said companies) also totally miss the point of free software. They show up in bug trackers all entitled like the license they praise in all their “empowering the community” slides doesn’t say THE SOFTWARE IS PROVIDED “AS IS” in all fscking caps. If you made a list of all the companies to whom the description “companies that only like the free aspect of free software when it benefits them directly” doesn’t apply, you could apply a moderately efficient compression algorithm and it would fit in a boot sector.

                            I don’t want to defend what the author did – as someone else put it here, it’s dumbshittery of an advanced level. But if entitlement were to earn you an iron “I’m an asshole” pin, we’d have to mine so much iron ore on account of the software industry that we’d trigger a second Iron Age.

                            This isn’t only on the author, it’s what happens when corporate entitlement meets open source entitlement. All the entitled parties in this drama got exactly what they deserved IMHO.

                            Now, one might argue that what this person did affected not just all those entitled product managers who had some tough explaining to do to their suit-wearing bros, but also a bunch of good FOSS “citizens”, too. That’s absolutely right, but while this may have been unprofessional, the burden of embarrassment should be equally shared by the people who took a bunch of code developed by an independent, unpaid developer, in their spare time – in other words, a hobby project – without any warranty, and then baked it in their super professional codebases without any contingency plan for “what if all that stuff written in all caps happens?”. This happened to be intentional but a re-enactment of this drama is just one half-drunk evening hacking session away.

                            It’s not like they haven’t been warned – when a new dependency is proposed, that part is literally the first one that’s read, and it’s reviewed by a legal team whose payment figures are eye-watering. You can’t build a product based only on the good parts of FOSS. Exploiting FOSS software only when it benefits yourself may also be assholery of an advanced level, but hoping that playing your part shields you from all the bad parts of FOSS is naivety of an advanced level, and commercial software development tends to punish that.

                            1. 4

                              They show up in bug trackers all entitled like the license they praise in all their “empowering the community” slides doesn’t say THE SOFTWARE IS PROVIDED “AS IS” in all fscking caps

                              Slides about F/OSS don’t say that because expensive proprietary software has exactly the same disclaimer. You may have an SLA that requires bugs to be fixed within a certain timeframe, but outside of very specialised markets you’ll be very hard pressed to find any software that comes with any kind of liability for damage caused by bugs.

                              1. 1

                                Well… I meant the license, not the slides :-P. Indeed, commercial licenses say pretty much the same thing. However, at least in my experience, the presence of that disclaimer is not quite as obvious with commercial software – barring, erm, certain niches.

                                Your average commercial license doesn’t require proprietary vendors to issue refunds, provide urgent bugfixes or stick by their announced deadlines for fixes and veatures. But the practical constraints of staying in business are pretty good at compelling them to do some of these things.

                                I’ve worked both with and without SLAs so I don’t want to sing praises to commercial vendors – some of them fail miserably, and I’ve seen countless open source projects that fix security issues in less time than it takes even competent large vendors to call a meeting to decide a release schedule for the fix. But expecting the same kind of commitment and approachability from Random J. Hacker is just not a very good idea. Discounting pathological arseholes and know-it-alls, there are perfectly human and understandable reasons why the baseline of what you get is just not the same when you’re getting it from a development team with a day job, a bus factor of 1, and who may have had a bad day and has no job description that says “be nice to customers even if you had a bad day or else”.

                                The universe npm has spawned is particularly susceptible to this. It’s a universe where adding a PNG to JPG conversion function pulls fourty dependencies, two of which are different and slightly incompatible libraries which handle emojis just in case someone decided to be cute with file names, and they’re going to get pulled even if the first thing your application does is throw non-alphanumeric characters out of any string, because they’re nth order dependencies with no config overrides. There’s a good chance that no matter what your app does, 10% of your dependencies are one-person resume-padding efforts that turned out to be unexpectedly useful and are now being half-heartedly maintained largely because you never know when you’ll have to show someone you’re a JavaScript ninja guru in this economy. These packages may well have the same “no warranty” sticker that large commercial vendors put on theirs, but the practical consequences of having that sticker on the box often differ a lot.

                                Edit: to be clear, I’m not trying to say “proprietary – good and reliable, F/OSS – slow and clunky”, we all know a lot of exceptions to both. What I meant to point out is that the typical norms of business-to-business relations just don’t uniformly apply to independent F/OSS devs, which makes the “no warranty” part of the license feel more… intense, I guess.

                            2. 12

                              The entitlement sentiment goes both ways. Companies that expect free code and get upset if the maintainer breaks backward compatibility. Since when is that an obligation to behave responsibly?

                              When open source started, there wasn’t that much money involved and things were very much in the academic spirit of sharing knowledge. That created a trove of wealth that companies are just happy to plunder now.

                            3. 1

                              releasing deliberately broken commits in order to express his displeasure at companies using his software without compensating him in the way he would like.

                              Was that honestly the intent? Because in that case: what hubris! These libraries were existing libraries translated to JS. He didn’t do any of the hard work.

                            4. 8

                              There is further variation on the “bricked” term, at least in the Android hacker’s community. You might hear things like “soft bricked” which refers to a device that has the normal installation / update method not working, but could be recovered through additional tools, or perhaps using JTAG to reprogram the bootloader.

                              There is also “hard bricked” which indicates something completely irreversible, such as changing the fuse programming so that it won’t boot from eMMC anymore. Or deleting necessary keys from the secure storage.

                              1. 3

                                this action did not break any builds that were set up responsibly; only builds which tell the system “just give me whatever version you feel like regardless of whether it works” which like … yeah, of course things are going to break if you do that! No one should be surprised.

                                OK, so, what’s a build set up responsibly?

                                I’m not sure what the expectations are for packages on NPM, but the changes in that colors library were published with an increment only to the patch version. When trusting the developers (and if you don’t, why would you use their library?), not setting in stone the patch version in your dependencies doesn’t seem like a bad idea.

                                1. 26

                                  When trusting the developers (and if you don’t, why would you use their library?), not setting in stone the patch version in your dependencies doesn’t seem like a bad idea.

                                  No, it is a bad idea. Even if the developer isn’t actively malicious, they might’ve broken something in a minor update. You shouldn’t ever blindly update a dependency without testing afterwards.

                                  1. 26

                                    Commit package-lock.json like all of the documentation tells you to, and don’t auto-update dependencies without running CI.

                                    1. 3

                                      And use npm shrinkwrap if you’re distributing apps and not libraries, so the lockfile makes it into the registry package.

                                    2. 18

                                      Do you really think that a random developer, however well intentioned, is really capable of evaluating whether or not any given change they make will have any behavior-observable impact on downstream projects they’re not even aware of, let alone have seen the source for and have any idea how it consumes their project?

                                      I catch observable breakage coming from “patch” revisions easily a half dozen times a year or more. All of it accidental “oh we didn’t think about that use-case, we don’t consume it like that” type stuff. It’s truly impossible to avoid for anything but the absolute tiniest of API surface areas.

                                      The only sane thing to do is to use whatever your tooling’s equivalent of a lock file is to strictly maintain the precise versions used for production deploys, and only commit changes to that lock file after a full re-run of the test suite against the new library version, patch or not (and running your eyeballs over a diff against the previous version of its code would be wise, as well).

                                      It’s wild to me that anyone would just let their CI slip version updates into a deploy willynilly.

                                      1. 11

                                        This neatly shows why Semver is a broken religion: you can’t just rely on a version number to consider changes to be non-broken. A new version is a new version and must be tested without any assumptions.

                                        To clarify, I’m not against specifying dependencies to automatically update to new versions per se, as long as there’s a CI step to build and test the whole thing before it goes it production, to give you a chance to pin the broken dependency to a last-known-good version.

                                        1. 7

                                          Semver doesn’t guarantee anything though and doesn’t promise anything. It’s more of an indicator of what to expect. Sure, you should test new versions without any assumptions, but that doesn’t say anything about semver. What that versioning scheme allows you to do though is put minor/revision updates straight into ci and an automatic PR, while blocking major ones until manual action.

                                        2. 6

                                          The general form of the solution is this:

                                          1. Download whatever source code you are using into a secure versioned repository that you control.

                                          2. Test every version that you consider using for function before you commit to it in production/deployment/distribution.

                                          3. Build your system from specific versions, not from ‘last update’.

                                          4. Keep up to date on change logs, security lists, bug trackers, and whatever else is relevant.

                                          5. Know what your back-out procedure is.

                                          These steps apply to all upstream sources: language modules, libraries, OS packages… dependency management is crucial.

                                          1. 3

                                            Amazon does this. Almost no-one else does this, but that’s a choice with benefits (saving the set up effort mostly) and consequences (all of this here)

                                          2. 6

                                            When trusting the developers (and if you don’t, why would you use their library?)

                                            If you trust the developers, why not give them root on your laptop? After all, you’re using their library so you must trust them, right?

                                            1. 7

                                              There’s levels to trust.

                                              I can believe you’rea good person by reading your public posts online, but I’m not letting you babysit my kids.

                                          3. 2

                                            Why wouldn’t this behavior be banned by any company?

                                            1. 2

                                              How do they ban them, they’re not paying them? Unless you mean the people who did not pin the dependencies?

                                              1. 4

                                                I think it is bannable on any platform, because it is malicious behavior - that means he intentionally caused harm to people. It’s not about an exchange of money, it’s about intentional malice.

                                              2. 1

                                                Because it’s his code and even the license says “no guarantees” ?

                                                1. 2

                                                  The behavior was intentionally malicious. It’s not about violating a contract or guarantee. For example, if he just decided that he was being taken advantage of and removed the code, I don’t think that would require a ban. But he didn’t do that - he added an infinite loop to purposefully waste people’s time. That is intentional harm, that’s not just providing a library of poor quality with no guarantee.

                                                  Beyond that, if that loop went unnoticed on a build server and costed the company money, I think he should be legally responsible for those damages.

                                            1. 2

                                              Thanks! Interestingly it is not the same as the Oral History of Adele Goldberg interview I knew about.

                                              1. 8

                                                As much as I love 2000 (great mouthfeel, last time Microsoft felt like they were firing on all cylinders), all these guides feel like the schizophrenic ramblings of teenagers with too much free time. I know things and this just feels like Pepe Silvia-esque cargo culting.

                                                And even if I did somehow follow all this, I still wouldn’t really have a working browser nor tools I’d need like Zoom. I still love to mess with Windows 2000, but it’s just not a daily driver anymore. Let it go.

                                                1. 4

                                                  I tend to agree but I can absolutely see a use case of keeping a VM with just that one version of Office (you like, or own, or whatever) installed, if that is what you want to use and installing it locally or WINE is not a solution.

                                                  Also this isn’t as far-fetched as you’d think, I’ve had this one version of Office 2000 still installed on my parents’ computers until at least 2010-2015ish, and I personally hate the newer versions, whereas that one was kinda ok.

                                                  1. 3

                                                    Yeah, I absolutely use VMs extensively - they’re the best option for running fickle old software. I just don’t do this wacky kernel patching for newer API thing that requires slipstreaming or whatever.

                                                    1. 2

                                                      Slipstreaming has been kinda common back then even when it was current (I think I did it for XP and 7 myself, not sure about 2000) and I don’t find the task or time investment overly much for this kind of undertaking.

                                                      1. 2

                                                        I think there’s two different things here:

                                                        • The guide is suggesting slipstreaming updates, presumably because they can’t get Windows 2000 to talk to Windows Update anymore (TLS version, SHA256 signing, etc.)
                                                        • Actual kernel patching in this guide happens by installing something later, and isn’t using slipstreaming. Back then there’s no driver signing/patchguard requirements, so kernel mode is freely manipulable without needing magic tricks.

                                                        As much as I love the Windows 2000 UI, XP is more practical in a VM today. It still has DOS support, runs apps quite a few years newer (without kernel patching), has an extra 9 years of updates if you include POSready, and things like Windows Update can be made to work.

                                                    2. 1

                                                      I almost always install my own Dutch copy of office 2003 in Wine, just because that’s the version of office in most productive in and grew up with.

                                                    3. 4

                                                      What happened to having fun? :-)

                                                      I wouldn’t do it either, yet I am the kind of lobster who likes to play with other old OSes where I can’t get a working browser, let alone Zoom.

                                                      Still I suggested the removal of the historical tag, since Windows 2000 does “happen to be old”.

                                                      1. 3

                                                        I like having fun, but these guides are for people deluded into thinking they can use it as a daily driver.

                                                        1. 4

                                                          I didn’t read it as a recommendation to do that, or any kind of zealotry to try to persuade people to follow that - simply instructions. That said, there’s no need for ad hominems, even if they would advise to do this as a daily driver. The very headline “Retrocomputing” plus “So, you want to use Windows 2000 in 2021?” could be read as “..at all”.

                                                        2. 2

                                                          ReactOS also runs old Windows software quite well, and it’s free software that is getting improved (even if slowly). I find that project much more fun to play with and participate in than performing necromantic rituals with old proprietary OSes.

                                                      1. 11

                                                        The three persons having flagged as “already posted” may like to know that bkhl’s post was in fact the first one, a few minutes before raymii posted the other link.

                                                        You should probably unflag, as this is not very welcoming, especially when the other one is at +9 :-)

                                                        1. 37

                                                          A company “bought” Audacity and added spyware. The same company also did it to MuseScore.

                                                          You know, it really was and still is a stretch to describe basic, opt-in telemetry as spyware just because they made the unfortunate decision to use Google Analytics as a backend.

                                                          1. 18

                                                            Also, from what I heard they are doing decent work, actually paying maintainers to work on the software. You know, the exact thing that OP is complaining about not happening.

                                                            1. 5

                                                              please explain how Google Analytics isn’t spyware? it is software that monitors user behavior and reports it to a 3rd party, all typically without user consent.

                                                              1. 19

                                                                Audacity/GA would be spyware if it was monitoring usage of other things the user was doing on their computer. Using the term to describe the app recording usage of itself is hyperbole.

                                                                1. 5

                                                                  If my business was audio engineering, having a tool that started reported on my usage of it would be problematic. I would immediately start looking for alternatives. Why should I have to look through the code to find out exactly what it’s logging? File names? My use of licensed plugins? The inference that the lead singer needs pitch correction on every single track, or that we brought in a pro “backup” singer who is actually 85% of the lead on the final mix?

                                                                  When I am editing my family’s amateur instrumental work, I think I can reasonably feel equally peeved at having my sound editor report back to base.

                                                                  Calling it spyware is not necessarily hyperbole.

                                                                  1. 5

                                                                    Fortunately the scenario you described doesn’t exist since the telemetry is opt-in.

                                                                2. 18

                                                                  all typically without user consent

                                                                  Except here it is opt-in, as pekkavaa said.

                                                                  1. 2

                                                                    thanks, i missed that.

                                                                    I was curious what kind of consent was involved, and honestly it’s better than I expected. Based on the issue linked in the OP it seems Audacity now displays a dialog asking users to help “improve audacity” by allowing them to collect “anonymous” usage data. They don’t seem to mention that it also reports this to Google.

                                                                  2. 8

                                                                    Counting how many people clicked the big red button and bought products, or how many users have a 4K monitor, or how fast the page loads technically involves monitoring.. but it’s not really the same as what you would typically imagine when you hear the word “spying” is it?

                                                                    It’s rather silly to equate performance metrics, usability studies and marketing analytics to a secret agent carefully reading all your messages.

                                                                1. 1

                                                                  The previous blog post Einar references at the start of this lightning talk.

                                                                  1. 12

                                                                    Java lived up to the hype,

                                                                    Oof… What?

                                                                    I love rust and I don’t think it is hyped, really. But why go and defend Java? Just hurts the argument IMO.

                                                                    1. 39

                                                                      While not every Java prophesy came true as foretold, I think it was very successful overall.

                                                                      Android runs on Java, and it’s the most popular consumer OS in the world. So billions of devices really do use Java. It is write once, and run on a bunch of devices with vastly different hardware, and even Chromebooks and Windows 11. For over a decade it was probably the only sensible option for high-performance servers.

                                                                      Keep in mind that Java hype happened when there weren’t many other options. There was no golang, Rust, or Swift. The fancier JVM languages haven’t been created yet. There was no “modern” C++. C# was a clone from an evil empire. JavaScript was an interpreted toy confined to a slow buggy environment. Lua was obscure and LuaJIT didn’t exist yet. You had C, Python in its infancy (and as slow as ever), Perl, and some more obscure languages that wouldn’t easily run on consumer machines.

                                                                      Java looked really good in that company. And today despite much bigger choice of languages available, Java is still one of the most popular ones.

                                                                      1. 1

                                                                        The book “modern C++” was published in 1992. Unfortunately I can’t actually find a reference to that book online. As I recall it had a purple cover.

                                                                        1. 4

                                                                          I think of https://github.com/isocpp/CppCoreGuidelines when I hear “modern C++”.

                                                                          1. 2

                                                                            I thought the “modern C++” phrase originated with Alexandrescu’s book, Modern C++ Design, published in 2001.

                                                                        2. 17

                                                                          “There are only two kinds of languages: the ones people complain about and the ones nobody uses”

                                                                          Java is probably the most critical programming language in the enterprise space, the backbone of the majority of mobile devices (Android), and was used to create the best-selling video game of all time (Minecraft). Its time is waning, but it lived up the hype.

                                                                          1. 2

                                                                            I don’t think these things are related. Surez Java is entrenched and sure it’s very popular in some verticals, but it hasn’t managed to become popular for the things C was popular for (mostly) and the run everywhere thing sort of fell flat as x86 crushed everyone. I’m not sure I would say it close to “lived up to the hype” but maybe it depends on one’s memories kof the hype.

                                                                            1. 16

                                                                              Looking back now, I’d say it did. Normalizing managed code and garbage collection alone would qualify, but add robust, cross platform concurrency primitives and stable, cross platform GUI, classloaders and all the stuff about OSGi… I resent it for killing off Smalltalk’s niche, but it moved a much larger piece of software development in a good direction.

                                                                              1. 9

                                                                                You’re looking at niches that C has kept, rather than all the uses that C lost to Java. C used to be the default for most applications, not only low-level and performance-critical ones.

                                                                                On mobile, where “Wintel” didn’t have a stronghold, J2ME has crushed, and delivered some portability across devices with vastly different (and crappy) hardware.

                                                                                1. 8

                                                                                  “Become popular for the things C was popular for” is kind of an impossible standard to hold any language to. Back in the day when Java was new, C was popular for everything. I know I personally wrote or worked on multiple backend business-logic-heavy services in C that would have been much better fits for Java had it existed in mature form at the time.

                                                                                  Even at the height of Java’s early hype, I can’t remember anyone credibly suggesting it would replace C outright.

                                                                                  Write once, run everywhere is still valuable. My team develops on MacOS, Windows, and Linux, and we deploy to a mix of x86 servers and on-premises low-power ARM devices (think Raspberry Pi). The same JVM bytecode (Kotlin, not Java, in our case) works identically enough in all those environments that we haven’t felt any urge to push people toward a single OS for dev environments. We have far more headaches with OS incompatibilities in our Python code than in our Kotlin code, though admittedly we’re not doing the same stuff in both languages.

                                                                                  1. 7

                                                                                    This seems slightly ahistorical — before C’s niche was God of the Gaps-ed into “tiny performant chunks of operating systems where zero copy memory twiddling is critical” it was everywhere. Like, people were writing web applications in C. People were doing things with C (and the godforsaken C-with-objects style of C++) that nobody today would go near in an unmanaged language. It was Java that showed the way. And I am no fan of Java-the-language.

                                                                                    1. 4

                                                                                      Which is itself funny because everything good about Java was available elsewhere. The difference was the giant education campaign and campaign to embed the vm everywhere.

                                                                                      1. 2

                                                                                        Oh, I know.

                                                                                    2. 2

                                                                                      Now we have AWS Graviton, I found Java people do have easier time.

                                                                                  2. 3

                                                                                    I think that nobody can deny that Java had been widely successful.

                                                                                    If it lived up to the hype, then we first have to define what the hype was. If I remember correctly, our was first hyped for applets. Java’s successes have been elsewhere.

                                                                                  1. 2

                                                                                    I am a bit out of the loop, does this mean that GDC has finally become part of GCC? If so, congrats to Iain Buclaw who has been working on this since years and years! Glad it has finally paid off.

                                                                                    I was quite impressed with D when I read the D book but I fear that now with Rust it is too late for broad adoption since they seem to serve similar niches.

                                                                                    1. 3

                                                                                      Does this mean that GDC has finally become part of GCC?

                                                                                      Yes, support for the D programming language has been added to GCC, and got released with GCC 9 in 2019.

                                                                                      1. 1

                                                                                        I looked at D almost 20 years ago but the fact that the only reliable compiler was the Digital Mars D compiler and it had limited platform support put me off. Now, D has GCC and LLVM front ends that are actively maintained (is the Digital Mars implementation still going?). Rust still has a single implementation (though others are in progress), so D has some advantages here.

                                                                                        Looking at the Wikipedia page, I think the biggest problem with D is that it is now quite a dated language. It solves problems that I had with C++98 and is very much an object-oriented language. Languages like Rust and modern C++ are very much compromises picking the bits of object orientation, functional programming, and generic metaprogramming that work and letting you adapt them for the problem at hand.

                                                                                        1. 2

                                                                                          very much compromises picking the bits of object orientation, functional programming, and generic metaprogramming that work and letting you adapt them for the problem at hand

                                                                                          Honestly that describes D too. In any case, I wouldn’t say that D is “very much” an OO language. It has OO (Java 5 style) in the language, true, but you don’t have to use it if it doesn’t solve your problem.

                                                                                          I mean, for example D had ranges before they were cool :)

                                                                                          1. 2

                                                                                            There are 2 capabilities that, in my view showed, that D can advance with time:

                                                                                            a ) Sub-setting the language to have narrower capabilities, in exchange for wider cross-language integration/interfacing opportunities:

                                                                                            https://dlang.org/spec/betterc.html

                                                                                            b ) Compile time programming: eg

                                                                                            https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time

                                                                                            Certainly, plugging gaps in C++ as a product-roadmap, hindered language formalisms and its runtime. But having the language now to be part of GCC, while still maintaining separate backends – is a big deal, and perhaps could put D closer to the top of the list for some larger projects.

                                                                                            I also think specifically full-featured compile-time programming, could be a way to integrate a language with a new breed of formal verification tools (although this is just a thought at this point).

                                                                                        1. 21

                                                                                          This is good stuff. We’ve been working (lightly) with sourcehut for this and it’s in my eyes one of the big steps forward.

                                                                                          IRC might be an old protocol, but the number one issue is purely one of client UX. Better on ramps and clients to get people to the communities where people are is the number one issue. I really strongly believe that this is improvements like this one will keep IRC competitive with proprietary systems like discord and slack.

                                                                                          1. 7

                                                                                            Of course it’s a good thing to have alternatives, but as it is a paid service I still think it’s spam.

                                                                                            1. 29

                                                                                              I’m perfectly happy with paid up services that run entirely and exclusively on Free software. This ends up being a well tested and supported stack that anyone can run themselves, or have sr.ht host it for them.

                                                                                              What matters to me is that there’s a variety of free software tools to compete with proprietary stuff, and this is such an example.

                                                                                              1. 8

                                                                                                Yes, I’m sure we all agree on that. :)

                                                                                                But compared to articles about IRCv3, modern-irc, or the internal workings of the service, this announcement is not exactly on-topic.

                                                                                              2. 7

                                                                                                It’s only a paid service if you use the sr.ht instance, sourcehut itself, including the stack that runs chats.sr.ht is entirely open source. You can host it yourself if you want.

                                                                                                1. 3

                                                                                                  Yes, and still not the 2 application reps were linked but this.

                                                                                                2. 1

                                                                                                  would it be spam if it were a nominally free proprietary service which you pay for in data and attention?

                                                                                                  1. 3

                                                                                                    rephrasing the title as “company/org X is offering irc bouncers” still would make it “news as in product announcment” for me, so still offtopic, just because many of us use IRC… Same as announcing a new free mail provider. The fact that it is paid is just another category of offtopic.

                                                                                                    Had someone posted “Hey here’s an alternative to thelounge and irccloud” and “btw, sr.ht made this and offers this” would’ve been a good comment.

                                                                                                    Just from the point of a normal user, I’m not mad at sr.ht or anything.

                                                                                              1. 15

                                                                                                there should be one and only one programming language for everything. That language is Nim.

                                                                                                This attitude makes me inclined to avoid Nim. I want to use a language that’s honest about its limitations. If you believe that a general-purpose language can beat a specialized one at any task that’s extremely naive and reflects very poor judgement.

                                                                                                Many of the other points just feel like stating the obvious. Using the word “zen” to refer to these ideas feels very disrespectful of Buddhists.

                                                                                                1. 14

                                                                                                  I’m assuming that statement was tongue-in-cheek. But Nim does have a really broad range of uses, since it can compile to C or JS, has an interpreter for a large subset of itself, and has a very extensible syntax.

                                                                                                  The term “the Zen of ____” has become a trope since the 1960s — try googling it — and has nothing to do with Zen Buddhism. You might as well say an article called “The Ten Commandments of functional programming” is disrespectful to Christians/Jews/Muslims.

                                                                                                  1. 8

                                                                                                    Respectfully, old tropes can still be - and in fact are probably more likely to be - racist or appropriative, and should be reevaluated occasionally.

                                                                                                  2. 10

                                                                                                    Using the word “zen” to refer to these ideas feels very disrespectful of Buddhists.

                                                                                                    I’ve studied Zen Buddhism a bit and my understanding is that they’re generally far from the snowflakes you picture them here to be. It could be said that you’re probably being more disrespectful of them by saying that.

                                                                                                    1. 2

                                                                                                      “Snowflakes”? Can you explain? I’ve only ever heard it used by ultra-conservatives as an (unintentionally ironic) insult so I’m confused by the usage here, thanks

                                                                                                      1. 3

                                                                                                        Perhaps a cultural difference. It’s used where I live without too much political baggage. It refers to a person who gets offended without a reason. Zen Buddhists typically are not like that although there are individual differences obviously.

                                                                                                        I think it’s a pretty clear metaphor though, I’m confused what you’re confused about.

                                                                                                    2. 4

                                                                                                      Using the word “zen” to refer to these ideas feels very disrespectful of Buddhists.

                                                                                                      I’m not a Buddhist, but from what I have read about Chan Buddhist monks (from which Zen is descended) they were a pretty iconoclastic bunch. I imagine that some might have more of an issue with expounding a series of formalisms than with the appropriation of a term. My understanding is that they believed that enlightenment came from a sudden moment of clarity, not necessarily sustained study, and they tried to induce that moment of insight through koans as well as suddenly shouting or striking a pupil.

                                                                                                      Whats more, there are some great koans about not letting things get to you. I like this one in particular:

                                                                                                      Tanzan and Ekido were once traveling together down a muddy road. A heavy rain was still falling.

                                                                                                      Coming around a bend, they met a lovely girl in a silk kimono and sash, unable to cross the intersection.

                                                                                                      “Come on, girl” said Tanzan at once. Lifting her in his arms, he carried her over the mud.

                                                                                                      Ekido did not speak again until that night when they reached a lodging temple. Then he no longer could restrain himself. “We monks don’t go near females,” he told Tanzan, “especially not young and lovely ones. It is dangerous. Why did you do that?”

                                                                                                      “I left the girl there,” said Tanzan. “Are you still carrying her?”

                                                                                                      1. 3

                                                                                                        I am a (largely) Zen Buddhist, and we’re used to the word being used for chocolate bars and shampoos and the like. ‘The Zen of Nim’ just makes me assume it’s a riff on Python; no problem.

                                                                                                        Ironically, I’m more at pains to point out that what you posted above is not a koan; it’s a fun story, or parable, but it would never be used as a part of meditation practice and is of a considerably different flavor than actual koans.

                                                                                                        1. 1

                                                                                                          Fair enough. I picked it up from Ashida Kim’s site so it isn’t my original description.

                                                                                                          ** Edit **

                                                                                                          I’m actually going to back this up. The wikipedia page for koans says they are “a story, dialogue, question, or statement which is used in Zen practice to provoke the “great doubt” and to practice or test a student’s progress in Zen.” This isn’t the classic sound of one hand clapping or does a dog have a Buddha nature, but it does present a paradox: it is not the act touching a woman that is inimical to the monk’s path, but it’s the how the woman disturbs and occupies their thoughts.

                                                                                                          1. 2

                                                                                                            I mean, you can believe what you like, but koans are a specific corpus which have a specific function in Zen training. It’s not a structural characterization; there is a specific body of texts that are used as koans, and that story ain’t in it.

                                                                                                            1. 1

                                                                                                              I’m open to changing my mind about it. I just don’t feel like I’ve got a good reason to yet. There is one website the calls it a koan, a person that says it isn’t, and a definition that indicates that it could be. Rather than focusing on why this specifically isn’t a koan, what should I be looking at for koans? You say that there is a specific body of texts, what are they called?

                                                                                                      2. 4

                                                                                                        I suspect they’re copying the Zen of Python. However your point is a good one, probably best to avoid the use of Zen at all in a programming context.

                                                                                                        1. 11

                                                                                                          I suspect they’re copying the Zen of Python.

                                                                                                          Copying bad design is not good design.

                                                                                                          But, of course, I kid.

                                                                                                          1. 4

                                                                                                            You kid and it’s actually funny! Even funnier if you know Python and the Zen of Python!

                                                                                                            Truly a rarity in the tech sphere. If I could upvote this 20 times I would :)

                                                                                                          2. 4

                                                                                                            The computer science literature is full of “Bibles”. Do you find them equally disrespectful?

                                                                                                            1. 3

                                                                                                              I don’t actually find the usage of “Zen” disrespectful because I’m not a Zen buddhist.

                                                                                                              I don’t have a problem with any of this, however I try to be respectful of things others find to be deeply important even if I cannot understand them.

                                                                                                              1. 2

                                                                                                                Yes, I guess I should have asked technomancy directly. Sorry for that :-)

                                                                                                                But what I meant is that, like many other words, “Zen” is now used in everyday language, without its religious meaning. That might be sad, but I don’t think we should see any disrespect in that.

                                                                                                              2. 3

                                                                                                                I wouldn’t find this disrespectful if it were a list of aphorisms which seemed paradoxical or contained some subtle wisdom. These just don’t hit that mark. It feels like invoking the word “zen” is only done to make it sound more clever than it is.

                                                                                                          1. 6

                                                                                                            So merkle-trees are a data structure used by cryptocurrency, but the data structure is used in other contexts as well. I suppose it’s possible there will be crypto currencies that don’t rely on such trees.

                                                                                                            Perhaps add the suffix for cryptography and add a separate cryptocurrency tag?

                                                                                                            1. 23

                                                                                                              my understanding is that the merkle-trees tag is a sort of implicit “this content isn’t welcome here” for cryptocurrency-related articles that don’t immediately focus on the technology involved.

                                                                                                              1. 3

                                                                                                                What’s the point of having this coded language? What is somebody posts something that is actually about Merkle trees? Should it then not use the tag?

                                                                                                                1. 2

                                                                                                                  Technical discussions around Merkle trees are on topic.

                                                                                                                  Cryptocurrencies outside that are not.

                                                                                                                  That’s the reason for the tag denomination change.

                                                                                                                  1. 1

                                                                                                                    in my experience most cryptocurrency articles are literal spam or written by scammers. the only ones that aren’t discuss the technology or design separate from the tokenomics/economics of the currency involved. I don’t know why the topic isn’t banned outright, you’d have to ask the admins here about that.

                                                                                                                    incidentally, I wonder what the most filtered tags are. Merkle-trees is probably up there.

                                                                                                                    1. 1

                                                                                                                      I think that what janus meant is that Merkle trees are used in a wide variety of domains totally unrelated to cryptocurrencies.

                                                                                                                      1. 1

                                                                                                                        And those areas are on topic, as there is a tag for them…

                                                                                                                  2. 1

                                                                                                                    Ah, that makes perfect sense.

                                                                                                                1. 4

                                                                                                                  This should be merged to this story.

                                                                                                                  1. 1

                                                                                                                    This is about Spec2, the user interface framework of Pharo.

                                                                                                                    PS: sorry about the Medium link!

                                                                                                                    1. 7

                                                                                                                      The book The UNIX Programming Environment by Kernighan and Pike is also a great read on much the same topic. It’s expensive to buy new but I found a cheap second-hand copy.

                                                                                                                      The thing is, I find the argument really compelling… but it doesn’t seem to have caught on. Some people really like this style of computing - see the Plan 9 holdouts, for example - but UNIX moved away from it pretty quickly once it left Bell Labs (hence this paper, which uses BSD and SysV changes as examples). GNU is definitely not UNIX, and Windows never was.

                                                                                                                      It seems like the UNIX style appeals strongly to a few people, but has no mass appeal. Maybe it appeals strongly to developers whose main focus is building software systems, but less to end users - and hence less to developers whose main focus is building software for those end users? Contrast Kernighan and Pike’s paper with Jamie Zawinski’s Unity of Interface, which he described as, “An argument for why kitchen-sink user interfaces (such as web browsers, and emacs) are a good idea.”

                                                                                                                      1. 11

                                                                                                                        Modularity is great if it comes with composability. UNIX originally justified its existence with a typesetting system and the UNIX kind of modularity where you consume a text file and produce a text file was great for that. The only stage that wasn’t plain text was the set of printer control commands that were sent to the printer device (over a stream interface, which looked like a text stream if you squinted a bit). It doesn’t actually work for anything non-trivial.

                                                                                                                        Here’s a toy example: Consider ls -Slh. In a UNIX purist world, -l is the only one of these that you actually need in ls and actually you don’t need that because if -l is the default you can get the non-verbose output with ls -l | cut -f 9 -w and you can make that a shell alias if you use it often enough. You don’t need -S because sort can sort things, so you can do ls -l | sort -k5. Except that now you’ve gone away from the UNIX spirit a bit because now both sort and cut have the functionality to split a line of text into fields. Okay, now that you’ve done that how do you add the -h bit as a separate command? You can do it with some awk that splits the input and rewrites that one column, but now you’ve added an entire new Turing-complete language interpreter to the mix. You could, in fact, just do ls | awk and implement the whole sort part in awk as well. If you do this, you’ll discover that awk scripts compose a lot better than UNIX pipelines because they have functions that can take structured values.

                                                                                                                        Many years ago, I sent a small patch to OpenBSD’s du to add the -d option, which I use with around 90% of du invocations (du -h -d1 is my most common du invocation). The patch was rejected because you can implement the -d equivalent with -c and a moderately complex find command. And that’s fine in isolation, but it doesn’t then compose with the other du flags.

                                                                                                                        The UNIX-Haters Handbook explained the problem very well: We’ve implemented some great abstractions in computing for building reusable components: they’re functions that consume and produce rich data types. Composing systems implemented in terms of these primitives works great. Witness the huge number of C/C++ libraries, Python packages, and so on in the world. In contrast, plumbing together streams of text works well for trivial examples, can be forced to work for slightly more complex examples, and quickly becomes completely impossible for more complex ones.

                                                                                                                        Even some of the most successful kitchen-sink UIs have been successful because they support composition. Word and Photoshop, for example, each have rich ecosystems of extensions and plugins that add extra features and owe their success in a large part to these features. You can build image-processing pipelines in UNIX with ImageMagick and friends but adding an interactive step in the middle (e.g. point at the bit you want to extract) is painful, whereas writing a Photoshop workflow that is triggered from a selection is much easier. Successful editors, such as vim, emacs, and VS Code, are popular because of their extensions far more than their core functionality: even today, NeoVim and Vim are popular, yet nvi has only a few die-hard users.

                                                                                                                        1. 5

                                                                                                                          Yeah I agree the sort -k5 thing is annoying. Several alternative shells solve that to some extent, like PowerShell, nushell, and maybe Elvish (?). They have structured data, and you can sort by a column by naming it, not by coming up with a sort invocation that re-parses it every time (and sort is weirder than I thought.)

                                                                                                                          However I want a Bourne shell to have it, and that’s Oil, although it’s not done yet. I think what PowerShell etc. do has a deficiency in that it creates problems of composition. It doesn’t follow what what I’m calling the Perlis-Thompson principle (blog posts forthcoming).

                                                                                                                          So Oil will support an interchange format for tables, not have an in-memory representation of tables: https://github.com/oilshell/oil/wiki/TSV2-Proposal (not implemented)

                                                                                                                          I also think the shell / awk split is annoying, and Shell, Awk, and Make Should Be Combined.

                                                                                                                          1. 1

                                                                                                                            Unfortunately, it’s not really something that you can solve in a shell because the problem is the set of communication primitives that it builds on. PowerShell is incredibly badly named, because it’s not really a shell (a tool whose primary purpose is invoking external programs), it’s a REPL. It has the converse problem: there’s no isolation between things in PowerShell.

                                                                                                                            Something like D-BUS would be a reasonably solid building block. If the shell managed a private D-BUS namespace for the current session then you could write composed commands that run a bunch of programs with RPC endpoints in both directions and some policy for controlling how they go together. You could then have commands that exposed rich objects to each other.

                                                                                                                            ’d be quite curious to know what a shell based around the idea of exporting D-BUS objects would look like, where if you wrote foo | bar then it would invoke both with D-BUS handles in well-known locations for each, rather than file descriptors for stdin / stdout. For example, a shell might provide a /shell/pipeline/{uuid} namespace and set an environment variable with that UUID and another with the position in the pipeline for each process so that foo would expose something in /shell/pipeline/3c660423-ee16-11eb-b8cf-00155d687d03/1 and look for something exposed as /shell/pipeline/3c660423-ee16-11eb-b8cf-00155d687d03/2, expose the /0 and /3 things for input from and output to the terminal (and these could be a richer set of interfaces than a PTY, but might also provide the file descriptor to the PTY or file directly if desired). Each shell session might run its own D-BUS bus or hook into an existing one and the shell might also define builtins for defining objects from scripts or hooking in things from other places in a D-BUS system.

                                                                                                                            1. 2

                                                                                                                              (very late reply, something reminded me of this comment recently)

                                                                                                                              I don’t see why you need DBus or anything similar to solve the sort -k5 problem? I think you just need something like TSV over pipes, and then a sort-by tool that takes a column name to sort by. An enhancement would be to attach types to column names, so you don’t have to choose whether to do sort (lexicographic) or sort -n (numeric) – that would be in the data rather than the code.

                                                                                                                              There are already people who use CSV/TSV, XML/HTML, and JSON over pipes. And entire shell-based toolkits and languages around them, like jq, csvkit, etc.

                                                                                                                              Projects listed at the end of this page: https://github.com/oilshell/oil/wiki/Structured-Data-in-Oil

                                                                                                                              So I think there is a lot of room to improve the shell without changing anything about the kernel. Sure you don’t have metadata for byte streams, but these tools should be strict about parse errors, and it’s very easy to tell a TSV vs. HTML vs. JSON document apart. I think better parse errors would go a long way, and that can be done in user space.

                                                                                                                          2. 4

                                                                                                                            Interestingly enough, OpenBSD added the -d option to du some years ago: https://cvsweb.openbsd.org/src/usr.bin/du/du.c?rev=1.26&content-type=text/x-cvsweb-markup

                                                                                                                            And the reason is to be compatible with other BSDs and Linux and so we’re back to the original topic ;)

                                                                                                                            1. 5

                                                                                                                              I think I submitted my patch to add -d in 2004 or 2005, so it took OpenBSD over a decade to actually add the feature. I was running a locally patched du for the entire time I was using OpenBSD. That interaction put me off contributing to OpenBSD - the reaction of ‘this feature is a waste of time, you can achieve the same thing with this complicated find expression’ and the hostility with which the message was delivered made me decide not to bother with writing any other code that would require that I interacted with the same people.

                                                                                                                              1. 3

                                                                                                                                Sorry to hear that. In general I find it is extremely difficult to reject patches gracefully, even when you are trying to. It’s one of those things where text loses nuance that would do the job in real life, and so you have to be extra enthusiastic about it. I usually try to start on a positive statement ‘cause that’s what people will see first, something like “I love this, thanks for submitting it. But, there’s no way I can accept this because…”. If it’s a (smallish) bug fix rather than a feature addition I often try to accept it anyway, even if it kinda sucks, and then clean it up myself.

                                                                                                                                I’m all for technical rigor, but if a project wants to attract contributions, it’s nice to have a reputation for being easy to work with. And it’s better for everyone if people are encouraged to submit patches without them fearing a nasty rejection. You never know when someone sending a patch is a 13 year old self-taught hacker with more enthusiasm than sense, just starting to play with getting involved in the world outside their own head.

                                                                                                                                1. 2

                                                                                                                                  Interesting, found the original mailing list response where the “rejection” was given: https://marc.info/?l=openbsd-tech&m=115649277726459&w=2

                                                                                                                                  How frustrating to receive that response, “it is not being added as it is not part of POSIX”, since -d got added some years later, with the commit message explicitly acknowledging its omission from POSIX standards at the time. :\

                                                                                                                                  On the upside, looks like you had the right intentions all along so I send some kudos your way for trying :)

                                                                                                                                  1. 3

                                                                                                                                    How frustrating to receive that response, “it is not being added as it is not part of POSIX”, since -d got added some years later, with the commit message explicitly acknowledging its omission from POSIX standards at the time. :\

                                                                                                                                    To be fair, eight years is a long time and the project might have changed its mind about POSIX.

                                                                                                                                    I started this comment by writing that I was not sure the reasoning was inconsistent. David’s patch was rejected in part due to portability concerns. And schwarze’s commit message does mention compatibility with other BSDs and GNU as justification.

                                                                                                                                    But on the other hand, support for -d appeared in NetBSD around the same time as David’s patch and in FreeBSD even before that. Soooo… you’re probably right :-)

                                                                                                                                    1. 2

                                                                                                                                      haha, yeah I mean, it’s fair to stick to POSIX, but I guess in David’s case it was a matter of the person reviewing the submission being more stringent about that than the person/people who adopted the change later.

                                                                                                                                      Out of curiosity I checked the FreeBSD du.c commit history and found that the -d option was added in Oct 1996! Glad they kept the full commit history upon each transition to a new versioning technology (since I’ve definitely encountered projects where that history was lost). Ah well, anyway, that’s more than I expected to learn about the history of du this week! haha :)

                                                                                                                            2. 5

                                                                                                                              To me, the closest thing to the Unix philosophy today is the Go standard library. It has lots of functions with simple APIs that take io.Readers or io.Writers and lets you compose them into whatever particular tool you need. I guess this makes sense, since it’s from Rob Pike.

                                                                                                                              The thing about the Unix philosophy is it’s not just about “small” tools that do one thing. It’s about finding the right abstraction that covers a wider range of cases by being simpler. Power comes from having fewer features.

                                                                                                                              For example, file systems before Unix were more complicated and featureful. We see today that for example, iOS makes files complicated in an old school mainframe like way where some data is in the Photos library, some is locked in a particular app, some needs iTunes to be extracted, and some is actually in the Files app. This might be the right choice in terms of creating a lot of small seemingly simple interfaces instead of one actually simple interface that can do everything, but it makes it much harder to extend things in ways not envisioned by the software developers.

                                                                                                                              1. 3

                                                                                                                                To me, the closest thing to the Unix philosophy today is the Go standard library. It has lots of functions with simple APIs that take io.Readers or io.Writers and lets you compose them into whatever particular tool you need. I guess this makes sense, since it’s from Rob Pike.

                                                                                                                                Yeah, he mentioned this in “Less is Exponentially More”:

                                                                                                                                Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!):

                                                                                                                                We should have some ways of coupling programs like garden hose–screw in another segment when it becomes necessary to massage data in another way. This is the way of IO also.

                                                                                                                                That is the way of Go also. Go takes that idea and pushes it very far. It is a language of composition and coupling.

                                                                                                                                It’s fun to think of Go programs like that. Like a website could be a bunch of http handler functions slotted into a mux, and an HTML template parser is wired up to the handers’ response witers. It’s nice to think like that in terms of packages too. My favorite packages are those that I can think of as a “part” that I can hook up to other parts.

                                                                                                                                The thing about the Unix philosophy is it’s not just about “small” tools that do one thing. It’s about finding the right abstraction that covers a wider range of cases by being simpler. Power comes from having fewer features.

                                                                                                                                Definitely. I think the “do one thing…” etc sayings kind of miss the point. And io.Writers and io.Readers are definitely that kind of abstaction. They have one method and can therefore easily cover a wide range of types. I think Go’s interfaces work that way in general too, since they grow more specific and “narrow” with more methods and the number of types that implement them shrinks.

                                                                                                                            1. 1

                                                                                                                              I like the exploration of the assumptions, but that seems a long way away from “F# is the best…”

                                                                                                                              For the sake of discussion, let’s just grant the whole “functional is better” bias underlying them. Looking 1-by-1:

                                                                                                                              1. Tooling: Doesn’t F# limit you to visual studio on windows and the associated build tools? Unless “writing software for Windows” is the main objective, I find working in Visual Studio to be miserable. And “writing software for Windows” is something I do at the end after all the growth and learning and concept proving that might lead me to try a new language or new set of libraries. That’s the kind of job listing-style qualifier that OP said would make assumption #2 not apply… to then require it for assumption #1 puts the argument in a rough place.

                                                                                                                              2. Accommodating a wide range of styles is an interesting point, but it does hamper learning in some ways too. If it weren’t for the damned borrow checker in Rust making some bad habits unworkable, I don’t think the improvement occurs. Over-accommodation can lead you to stall out; how does F# prevent that?

                                                                                                                              3. I’d need some persuasion to see why F# isn’t dragging up the rear behind Kotlin, Rust and Clojure here, and the article offers none.

                                                                                                                              Maybe it’s just incomplete and needs a follow-up, as others have suggested.

                                                                                                                              1. 4

                                                                                                                                Doesn’t F# limit you to visual studio on windows and the associated build tools?

                                                                                                                                No it doesn’t.

                                                                                                                                .NET Core runs well on other platforms these days. And the open-source F# tooling has very good support for Visual Studio Code, but there is a LSP server so other editors (vim, emacs, …) should be supported as well (I haven’t tried that recently though).

                                                                                                                                1. 1

                                                                                                                                  Yep. The only lack of support I’ve bumped into is that dotnet doesn’t have an implementation for ppc64le yet. issue #13277

                                                                                                                                  1. 1

                                                                                                                                    Nice. I didn’t know the dev tooling had made it off windows yet. (I was aware it could be built and run, in some measure, but my impression from the last time I messed with it for C# was that most of the stuff people used in the software they wrote for distribution was still very much tied to windows.)

                                                                                                                                1. 3

                                                                                                                                  Great. Fantastic. Wonderful. Imagine me jumping up and down, clapping my hands together, reading this blog post because I’ve always wanted to do exactly what Hillel is doing: finding if the metaphors are even real.

                                                                                                                                  I think the real impact of “is it real engineering or not” is the stuff that other engineers get “for free”. I know digital gives some stuff for free but consider that we don’t really have atoms. This causes many problems.

                                                                                                                                  1. Software is too abstract, you can barely describe what the thing is - name all the things curl does (be exact)
                                                                                                                                  2. You can’t describe done - is grep done?
                                                                                                                                  3. We can’t compare or contrast software - everything is opinions, man :)

                                                                                                                                  Great post.

                                                                                                                                  1. 3

                                                                                                                                    You can’t describe done - is grep done?

                                                                                                                                    How can you describe if an aircraft, a car or even a power drill is done?

                                                                                                                                    I would argue the situation is exactly the same with software: to declare it “done”, you need to have some kind of pre-established specification of what is enough to call it a day and ship it.

                                                                                                                                    1. 1

                                                                                                                                      Fair. I guess a car isn’t done either and I wouldn’t easily be able to find its spec nor grep’s spec.

                                                                                                                                      My point is that software is too abstract. The specs for software are abstract and hard to experience compared to some of physical objects’ traits. The specs for physical products have freebies like atoms which is sort of nice for experience/feedback/demostration but also testing and measuring. I feel like software doesn’t have iron / steel / plastic which has mostly dependable properties. Or maybe software does have dependable properties (math, memory, types, immutability) but we’re not using those enough?

                                                                                                                                      It would be interesting to compare demonstrations of a physical vending machine and a completely software vending machine (like something you have to drive with a mouse). See which is harder to explain based on time. If it’s harder to explain then it’s harder to experience and then it’s harder to test so it’s less dependable.

                                                                                                                                      I think theatlantic article linked in the OP says this all better than I can.

                                                                                                                                      “Computing is fundamentally invisible,” Gerard Berry said in his talk. “When your tires are flat, you look at your tires, they are flat. When your software is broken, you look at your software, you see nothing.”

                                                                                                                                      1. 3

                                                                                                                                        Industrial engineering also mostly works with abstract concepts. Much of it is optimizing schedules, workflows, processes, etc.

                                                                                                                                        1. 1

                                                                                                                                          This is a good point. The whole article series is a good point! :) I think I need to change my chunking and opinion about this topic. You posted a story three months ago, interviewed 17 people, were surprised. There’s a journey you started a while back and I’m catching up. I was in The Atlantic article zone, you were surprised (I believe) and now I’m turning my ship?

                                                                                                                                          I still like rapid feedback and visual cortex stuff when possible. Maybe the machine is abstract but we don’t have to work that way if we try. Systems can be observed. Algorithms can be animated. Schedules can be post-it notes. Console commands can be reactive TUIs. StoryboardJS kind of blew my mind today, it’s just increasing visual feedback.