Threads for fouric

  1. 24

    Am I the only one being completely tired of these rants/language flamewars? Just use whatever works for you, who cares

    1. 11

      You’re welcome to use whatever language you like, but others (e.g. me) do want to see debates on programming language design, and watch the field advance.

      1. 6

        Do debates in blogs and internets comments meaningfully advance language design compared to, say, researchers and engineers exploring and experimenting and holding conferences and publishing their findings? I think @thiht was talking about the former.

        1. 2

          I’m idling in at least four IRC channels on Libera Chat right now with researchers who regularly publish. Two of those channels are dedicated to programming language theory, design, and implementation. One of these channels is regularly filled with the sort of aggressive discussion that folks are tired of reading. I don’t know whether the flamewars help advance the state of the art, but they seem to be common among some research communities.

          1. 5

            Do you find that the researchers, who publish, are partaking in the aggressive discussions? I used to hang out in a couple Plan 9/9front-related channels, and something interesting I noticed is that among the small percentage of people there who made regular contributions (by which I mean code) to 9front, they participated in aggressive, flamey discussion less often than those that didn’t make contributions, and the one who seemed to contribute the most to 9front was also one of the most level-headed people there.

            1. 2

              It’s been a while since I’ve been in academia (I was focusing on the intersection of PLT and networking), and when I was there none of the researchers bothered with this sort of quotidian language politics. Most of them were focused around the languages/concepts/papers they were working with and many of them didn’t actually use their languages/ideas in real-world situations (nor should they, the job of a researcher is to research not to engineer.) There was plenty of drama in academia but not about who was using which programming language. It had more to do with grant applications and conference politics. I remember only encountering this sort of angryposting about programming languages in online non-academic discussions on PLT.

              Now this may have changed. I haven’t been in academia in about a decade now. The lines between “researcher” and “practitioner” may have even become more porous. But I found academics much more focused on the task at hand than the culture around programming languages among non-academics. To some extent academics can’t be too critical because the creator of an academic language may be a reviewer for an academic’s paper submission at a conference.

              1. 2

                I’d say that about half of the aggressive folks have published programming languages or PLT/PLD research. I know what you’re saying — the empty cans rattle the most.

        2. 8

          You are definitely not the only one. The hide button is our friend.

          1. 2

            So I was initially keen on Go when it first came out. But have since switched to Rust for a number of different reasons, correctness and elegance among them.

            But I don’t ever say “you shouldn’t use X” (where ‘X’ is Go, Java, etc.). I think it is best to promote neat projects in my favorite language. Or spending a little time to write more introductory material to make it easier for people interested to get started in Rust.

            1. 2

              I would go further, filtering for rant, meta and law makes Lobsters much better.

              rant is basically the community saying an article is just flamebait, but short of outright removing it. You can choose to remove it.

            2. 5

              I think this debate is still meaningful because we cannot always decide what we use.

              If there are technical or institutional barriers, you can ignore $LANG, such as if you’re writing Android apps, where you will use a JVM language (either Kotlin or Java) but if you are writing backend services, outside forces may compel you to adopt Go, despite its shortcomings detailed in this post (and others by the author).

              Every post of this kind helps those who find themselves facing a future where they must write Go to articulate their misgivings.

            1. 40

              I tried out this language while it was in early development, writing some of the standard library (hash::crc* and unix::tty::*) to test the language. I wrote about this experience, in a somewhat haphazard way. (Note, that blog post is outdated and not all my opinions are the same. I’ll be trying to take a second look at Hare in the coming days.)

              In general, I feel like Hare just ends up being a Zig without comptime, or a Go without interfaces, generics, GC, or runtime. I really hate to say this about a project where they authors have put in such a huge amount of effort over the past year or so, but I just don’t see its niche – the lack of generics mean I’d always use Zig or Rust instead of Hare or C. It really looks like Drew looked at Zig, said “too bloated”, and set out to create his own version.

              Another thing I find strange: why are you choosing to not support Windows and macOS? Especially since, you know, one of C’s good points is that there’s a compiler for every platform and architecture combination on earth?

              That said, this language is still in its infancy, so maybe as time goes and the language finds more users we’ll see more use-cases for Hare.

              In any case: good luck, Drew! Cheers!

              1. 10

                why are you choosing to not support Windows and macOS?

                DdV’s answer on HN:

                We don’t want to help non-FOSS OSes.

                (Paraphrasing a lot, obvs.)

                My personal 2c:

                Some of the nastier weirdnesses in Go are because Go supports Windows and Windows is profoundly un-xNix-like. Supporting Windows distorted Go severely.

                1. 13

                  Some of the nastier weirdnesses in Go are because Go supports Windows and Windows is profoundly un-xNix-like. Supporting Windows distorted Go severely.

                  I think that’s the consequence of not planning for Windows support in the first place. Rust’s standard library was built without the assumption of an underlying Unix-like system, and it provides good abstractions as a result.

                  1. 5

                    Amos talks about that here: Go’s file APIs assume a Unix filesystem. Windows support was kludged in later.

                  2. 5

                    Windows and Mac/iOS don’t need help from new languages; it’s rather the other way around. Getting people to try a new language is pretty hard, let alone getting them to build real software in it. If the language deliberately won’t let them target three of the most widely used operating systems, I’d say it’s shooting itself in the foot, if not in the head.

                    (There are other seemingly perverse decisions too. 80-character lines and 8-character indentation? Manual allocation with no cleanup beyond a general-purpose “defer” statement? I must not be the target audience for this language, is the nicest response I have.)

                    1. 2

                      Just for clarity, it’s not my argument. I was just trying to précis DdV’s.

                      I am not sure I agree, but then again…

                      I am not sure that I see the need for yet another C-replacement. Weren’t Limbo, D, Go, & Rust all attempts at this?

                      But that aside: there are a lot of OSes out there that are profoundly un-Unix-like. Windows is actually quite close, compared to, say, Oberon or classic MacOS or Z/OS or OpenVMS or Netware or OS/2 or iTron or OpenGenera or [cont’d p94].

                      There is a lot of diversity out there that gets ignored if it doesn’t have millions of users.

                      Confining oneself to just OSes in the same immediate family seems reasonable and prudent to me.

                  3. 10

                    My understanding is that the lack of generics and comptime is exactly the differentiating factor here – the project aims at simplicity, and generics/compile time evaluations are enormous cost centers in terms of complexity.

                    1. 20

                      You could say that generics and macros are complex, relative to the functionality they offer.

                      But I would put comptime in a different category – it’s reducing complexity by providing a single, more powerful mechanism. Without something like comptime, IMO static languages lose significant productivity / power compared to a dynamic language.

                      You might be thinking about things from the tooling perspective, in which case both features are complex (and probably comptime even more because it’s creating impossible/undecidable problems). But in terms of the language I’d say that there is a big difference between the two.

                      I think a language like Hare will end up pushing that complexity out to the tooling. I guess it’s like Go where they have go generate and relatively verbose code.

                      1. 3

                        Yup, agree that zig-style seamless comptime might be a great user-facing complexity reducer.

                        1. 16

                          I’m not being Zig-specific when I say that, by definition, comptime cannot introduce user-facing complexity. Unlike other attributes, comptime only exists during a specific phase of compiler execution; it’s not present during runtime. Like a static type declaration, comptime creates a second program executed by the compiler, and this second program does inform the first program’s runtime, but it is handled entirely by the compiler. Unlike a static type declaration, the user uses exactly the same expression language for comptime and runtime.

                          If we think of metaprogramming as inherent complexity, rather than incidental complexity, then an optimizing compiler already performs compile-time execution of input programs. What comptime offers is not additional complexity, but additional control over complexity which is already present.

                          To put all of this in a non-Zig context, languages like Python allow for arbitrary code execution during module loading, including compile-time metaprogramming. Some folks argue that this introduces complexity. But the complexity of the Python runtime is there regardless of whether modules get an extra code-execution phase; the extra phase provides expressive power for users, not new complexity.

                          1. 8

                            Yeah, but I feel like this isn’t what people usually mean when they say some feature “increases complexity.”

                            I think they mean something like: Now I must know more to navigate this world. There will be, on average, a wider array of common usage patterns that I will have to understand. You can say that the complexity was already there anyway, but if, in practice, is was usually hidden, and now it’s not, doesn’t that matter?

                            then an optimizing compiler already performs compile-time execution of input programs.

                            As a concrete example, I don’t have to know about a new keyword or what it means when the optimizing compiler does its thing.

                            1. 2

                              A case can be made that this definition of complexity is a “good thing” to improve code quality / “matters”:

                              Similar arguments can be used for undefined behavior (UB) as it changes how you navigate a language’s world. But for many programmers, it can be usually hidden by code seemingly working in practice (i.e. not hitting race conditions, not hitting unreachable paths for common input, updating compilers, etc.). I’d argue that this still matters (enough to introduce tooling like UBSan, ASan, and TSan at least).

                              The UB is already there, both for correct and incorrect programs. Providing tools to interact with it (i.e. __builtin_unreachable -> comptime) as well as explicit ways to do what you want correctly (i.e. __builtin_add_overflow -> comptime specific lang constructs interacted with using normal code e.g. for vs inline for) would still be described as “increases complexity” under this model which is unfortunate.

                              1. 1

                                The UB is already there, both for correct and incorrect programs.

                                Unless one is purposefully using a specific compiler (or set thereof), that actually defines the behaviour the standard didn’t, then the program is incorrect. That it just happens to generate correct object code with this particular version of that particular compiler on those particular platforms is just dumb luck.

                                Thus, I’d argue that tools like MSan, ASan, and UBSan don’t introduce any complexity at all. The just revealed the complexity of UB that was already there, and they do so reliably enough that they actually relieve me of some of the mental burden I previously had to shoulder.

                            2. 5

                              languages like Python allow for arbitrary code execution during module loading, including compile-time metaprogramming.

                              Python doesn’t allow compile-time metaprogramming for any reasonable definition of the word. Everything happens and is introspectable at runtime, which allows you to do similar things, but it’s not compile-time metaprogramming.

                              One way to see this is that sys.argv is always available when executing Python code. (Python “compiles” byte code, but that’s an implementation detail unrelated to the semantics of the language.)

                              On the other hand, Zig and RPython are staged. There is one stage that does not have access to argv (compile time), and another one that does (runtime).

                              Related to the comment about RPython I linked here:

                              http://www.oilshell.org/blog/2021/04/build-ci-comments.html

                              https://old.reddit.com/r/ProgrammingLanguages/comments/mlflqb/is_this_already_a_thing_interpreter_and_compiler/gtmbno8/

                              1. 4

                                Yours is a rather unconventional definition of complexity.

                                1. 5

                                  I am following the classic paper, “Out of the Tar Pit”, which in turn follows Brooks. In “Abstractive Power”, Shutt distinguishes complexity from expressiveness and abstractedness while relating all three.

                                  We could always simply go back to computational complexity, but that doesn’t capture the usage in this thread. Edit for clarity: Computational complexity is a property of problems and algorithms, not a property of languages nor programming systems.

                                  1. 3

                                    Good faith question: I just skimmed the first ~10 pages of “Out of the Tar Pit” again, but was unable to find the definition that you allude to, which would exclude things like the comptime keyword from the meaning of “complexity”. Can you point me to it or otherwise clarify?

                                    1. 4

                                      Sure. I’m being explicit for posterity, but I’m not trying to be rude in my reply. First, the relevant parts of the paper; then, the relevance to comptime.

                                      On p1, complexity is defined as the tendency of “large systems [to be] hard to understand”. Unpacking their em-dash and subjecting “large” to the heap paradox, we might imagine that complexity is the amount of information (bits) required to describe a system in full detail, with larger systems requiring more information. (I don’t really know what “understanding” is, so I’m not quite happy with “hard to understand” as a concrete definition.) Maybe we should call this “Brooks complexity”.

                                      On p6, state is a cause of complexity. But comptime does not introduce state compared to an equivalent non-staged approach. On p8, control-flow is a cause of complexity. But comptime does not introduce new control-flow constructs. One could argue that comptime requires extra attention to order of evaluation, but again, an equivalent program would have the same order of evaluation at runtime.

                                      On p10, “sheer code volume” is a cause of complexity, and on this point, I fully admit that I was in error; comptime is a long symbol, adding size to source code. In this particular sense, comptime adds Brooks complexity.

                                      Finally, on a tangent to the top-level article, p12 explains that “power corrupts”:

                                      [I]n the absence of language-enforced guarantees (…) mistakes (and abuses) will happen. This is the reason that garbage collection is good — the power of manual memory management is removed. … The bottom line is that the more powerful a language (i.e. the more that is possible within the language), the harder it is to understand systems constructed in it.

                                      comptime and similar metaprogramming tools don’t make anything newly possible. It’s an annotation to the compiler to emit specialized code for the same computational result. As such, they arguably don’t add Brooks complexity. I think that this argument also works for inline, but not for @compileError.

                          2. 18

                            My understanding is that the lack of generics and comptime is exactly the differentiating factor here – the project aims at simplicity, and generics/compile time evaluations are enormous cost centers in terms of complexity.

                            Yeah, I can see that. But under what conditions would I care how small, big, or icecream-covered the compiler is? Building/bootstrapping for a new platform is a one-time thing, but writing code in the language isn’t. I want the language to make it as easy as possible on me when I’m using it, and omitting features that were around since the 1990’s isn’t helping.

                            1. 8

                              Depends on your values! I personally see how, eg, generics entice users to write overly complicated code which I then have to deal with as a consumer of libraries. I am not sure that not having generics solves this problem, but I am fairly certain that the problem exists, and that some kind of solution would be helpful!

                              1. 3

                                In some situations, emitted code size matters a lot (and with generics, that can quickly grow out of hand without you realizing it).

                                1. 13

                                  In some situations

                                  I see what you mean, but I think in those situations it’s not too hard to, you know, refrain from use generics. I see no reason to force all language users to not use that feature. Unless Hare is specifically aiming for that niche, which I don’t think it is.

                                  1. 4

                                    There are very few languages that let you switch between monomorphisation and dynamic dispatch as a compile-time flag, right? So if you have dependencies, you’ve already had the choice forced on you.

                                    1. 6

                                      If you don’t like how a library is implemented, then don’t use it.

                                      1. 2

                                        Ah, the illusion of choice.

                              2. 10

                                Where is the dividing line? What makes functions “not complex” but generics, which are literally functions evaluated at compile time, “complex”?

                                1. 14

                                  I don’t know where the line is, but I am pretty sure that this is past that :D

                                  https://github.com/diesel-rs/diesel/blob/master/diesel_cli/src/infer_schema_internals/information_schema.rs#L146-L210

                                  1. 17

                                    Sure, that’s complicated. However:

                                    1. that’s the inside of the inside of a library modeling a very complex domain. Complexity needs to live somewhere, and I am not convinced that complexity that is abstracted away and provides value is a bad thing, as much of the “let’s go back to simpler times” discourse seems to imply. I rather someone takes the time to solve something once, than me having to solve it every time, even if with simpler code.

                                    2. Is this just complex, or is it actually doing more than the equivalent in other languages? Rust allows for expressing constraints that are not easily (or at all) expressable in other languages, and static types allow for expressing more constraints than dynamic types in general.

                                    In sum, I’d reject a pull request with this type of code in an application, but don’t mind it at all in a library.

                                    1. 4

                                      that’s the inside of the inside of a library modeling a very complex domain. Complexity needs to live somewhere,

                                      I find that’s rarely the case. It’s often possible to tweak the approach to a problem a little bit, in a way that allows you to simply omit huge swaths of complexity.

                                      1. 3

                                        Possible, yes. Often? Not convinced. Practical? I am willing to bet some money that no.

                                        1. 7

                                          I’ve done it repeatedly, as well as seeing others do it. Occasionally, though admittedly rarely, reducing the size of the codebase by an order of magnitude while increasing the number of features.

                                          There’s a huge amount of code in most systems that’s dedicated to solving optional problems. Usually the unnecessary problems are imposed at the system design level, and changing the way the parts interface internally allows simple reuse of appropriate large-scale building blocks and subsystems, reduces the number of building blocks needed, and drops entire sections of translation and negotiation glue between layers.

                                          Complexity rarely needs to be somewhere – and where it does need to be, it’s in often in the ad-hoc, problem-specific data structures that simplify the domain. A good data structure can act as a laplace transform for the entire problem space of a program, even if it takes a few thousand lines to implement. It lets you take the problem, transform it to a space where the problem is easy to solve, and put it back directly.

                                    2. 7

                                      You can write complex code in any language, with any language feature. The fact that someone has written complex code in Rust with its macros has no bearing on the feature itself.

                                      1. 2

                                        It’s the Rust culture that encourages things like this, not the fact that Rust has parametric polymorphism.

                                        1. 14

                                          I am not entirely convinced – to me, it seems there’s a high correlation between languages with parametric polymorphism and languages with culture for high-to-understand abstractions (Rust, C++, Scala, Haskell). Even in Java, parts that touch generics tend to require some mind-bending (producer extends consumer super).

                                          I am curious how Go’s generic would turn out to be in practice!

                                          1. 8

                                            Obligatory reference for this: F# Designer Don Syme on the downsides of type-level programming

                                            I don’t want F# to be the kind of language where the most empowered person in the discord chat is the category theorist.

                                            It’s a good example of the culture and the language design being related.

                                            https://lobste.rs/s/pkmzlu/fsharp_designer_on_downsides_type_level

                                            https://old.reddit.com/r/ProgrammingLanguages/comments/placo6/don_syme_explains_the_downsides_of_type_classes/

                                            which I linked here: http://www.oilshell.org/blog/2022/03/backlog-arch.html

                                  2. 3

                                    In general, I feel like Hare just ends up being a Zig without comptime, or a Go without interfaces, generics, GC, or runtime. … I’d always use Zig or Rust instead of Hare or C.

                                    What if you were on a platform unsupported by LLVM?

                                    When I was trying out Plan 9, lack of LLVM support really hurt; a lot of good CLI tools these days are being written in Rust.

                                    1. 15

                                      Zig has rudimentary plan9 support, including a linker and native codegen (without LLVM). We’ll need more plan9 maintainers to step up if this is to become a robust target, but the groundwork has been laid.

                                      Additionally, Zig has a C backend for those targets that only ship a proprietary C compiler fork and do not publish ISA details.

                                      Finally, Zig has the ambitions to become the project that is forked and used as the proprietary compiler for esoteric systems. Although of course we would prefer for businesses to make their ISAs open source and publicly documented instead. Nevertheless, Zig’s MIT license does allow this use case.

                                      1. 2

                                        I’ll be damned! That’s super impressive. I’ll look into Zig some more next time I’m on Plan 9.

                                      2. 5

                                        I think that implies that your platform is essentially dead ( I would like to program my Amiga in Rust or Swift or Zig, too) or so off-mainstream (MVS comes to mind) that those tools wouldn’t serve any purpose anyway because they’re too alien).

                                        1. 5

                                          Amiga in Rust or Swift or Zig, too)

                                          Good news: LLVM does support 68k, in part to many communities like the Amiga community. LLVM doesn’t like to include stuff unless there’s a sufficient maintainer base, so…

                                          MVS comes to mind

                                          Bad news: LLVM does support S/390. No idea if it’s just Linux or includes MVS.

                                          1. 1

                                            Good news: LLVM does support 68k Unfortunately, that doesn’t by itself mean that compilers (apart from clang) get ported, or that the platform gets added as part of a target triple. For instance, Plan 9 runs on platforms with LLVM support, yet isn’t supported by LLVM.

                                            Bad news: LLVM does support S/390. I should have written VMS instead.

                                            1. 1
                                          2. 2

                                            I won’t disagree with describing Plan 9 as off-mainstream ;) But I’d still like a console-based Signal client for that OS, and the best (only?) one I’ve found is written in Rust.

                                        1. 4

                                          I did some experimentation with Android, and I found out that even if you don’t install a custom ROM you can still increase the level of privacy.

                                          The best way to get more privacy is to quit the social networks who feed on your data.

                                          My rules of making my phone more secure and private:

                                          • Never use a closed source browser;
                                          • Never use a browser controlled by an organisation who profits from your data;
                                          • Use add blockers, and a VPN.
                                          • Use Tor Browser or Orbot, or a browser with good protection against trackers.
                                          • Clear everything everytime you close the browser;
                                          • Don’t use apps if you can use the website. Just add it to home as a shortcut. Some sites will behave exactly as an app.
                                          • Don’t install apps from the Playstore if you can find alternatives on Fdroid;
                                          • Avoid saving stuff on ☁️;
                                          • Logoff from waze, never use Maps;
                                          • Install PCAPdroid to check what apps are calling home when they shouldn’t;
                                          • Don’t use Google if you are logged in the browser with a Gmail account. In any case prefer other search engines. Use more than one search engine if possible: peekier, duckduckgo, ecosia, mojeek, brave, marginalia, etc. The results are not that bad, sometimes are better because you don’t have all the commercial junk pushed first.
                                          • Instead of Reddit, use teddit;
                                          • Use an invidious instance instead of directly using the YouTube app;
                                          • Install deedum and look on the Gemini content, it will remind you of the old internet if you are nostalgic about it;
                                          1. 2

                                            Install deedum and look on the Gemini content, it will remind you of the old internet if you are nostalgic about it;

                                            What effect does this have on security or privacy?

                                            1. 1

                                              Looking at my comment now, I must admit that the last point doesn’t make a lot of sense in that context. So it has 0 effects for security and privacy.

                                            2. 1

                                              Don’t use apps if you can use the website.

                                              I find the exact opposite to be better both from a privacy focus and a reliability focus. Typically there is not as much ad junk in apps, there are far less beacons, and many apps (at least the ones I use) allow you to cache stuff locally so your activity is harder to track (because no network activity). Just my 2¢.

                                              1. 2

                                                From my perspective, the jury is out on this one. Websites tend to be well-inspected and there’s plugins that analyse which trackers are used. Common trackers are very known and you can do the inspection yourself even with simple methods. Apps - not so much.

                                                1. 2

                                                  I was in the same boat until I realized that some apps are making constant requests home, even if I don’t use them.

                                              1. 4

                                                Zig will automatically generate both an async and sync function body from the same source-level definition? That’s incredibly awesome, obviously the correct language design decision, and something that I’ve been upset at other languages (Python, Rust) for getting incorrect for a long time.

                                                (why “obviously correct”? because forcing you to rewrite the same function twice, with the only difference being the presence of the “async” keyword, in order to use it in both an async and sync context, is literally forcing the programmer to do repetitive, automatable work that can and should be done by a computer, which is an automation machine, for no benefit to the human)

                                                Maybe Zig is worth trying to learn to fit into my slot for “non-managed-memory systems-programming language” - currently occupied by C, because Rust was too difficult for me to fit my mind around in the small amount of time that I previously had to try to learn it.

                                                1. 1

                                                  It generates only one function “version” of async/sync, depending on whether the function does anything “async” or not (i.e. uses @frame(), does suspend, does await (which implicitly suspends), calls an async function normally (which implicitly awaits)).

                                                  When you’re switching between an async and synchronous version, changing only the keywords may mean you’re probably not taking advantage of either correctly. For example, spawning a bunch of async tasks and joining their results is fine and efficient; Doing the same with threads naively isn’t such a good idea even if it’s a one-to-one mapping. There’s actual, situational benefit in being explicit about what tools you’re using under what async/sync context.

                                                1. 4

                                                  Oh, so you’re the author of Vale. I had no idea that you were making it to build a game (engine to build a game) - what an incredible yak-shave. Vale has some very neat ideas, and seems to improve on Rust in some ways (e.g. better ergonomics around lifetimes) - props to you!

                                                  1. 1

                                                    Thank you for the kind words!

                                                  1. 1

                                                    I like the wifi QR code generator at https://qifi.org/ - useful for when guests come over and you want to conveniently give them wifi access.

                                                    1. 3

                                                      The counter-argument by Artemis goes like this: the availability of GNU-Free distros increases user agency because it gives Libre Enthusiast Strawpersons the ability to choose a GNU-Free distro that fits their needs better.

                                                      There are two problems here: one, the argument about whether the existence of GNU-Free distros increases user agency globally is different than the one in Xe’s post about how said distros decrease agency locally, for a user using the system - they’re separate levels of argument, and can both be true at the same time. (that is, I don’t think that the “response” post actually responds to the arguments in the original)

                                                      Two, the claim “In this case, a distribution that allows proprietary software actually decreases their agency.” is made, but there’s no supporting evidence - where is the decrease in agency?

                                                      There’s “I know that no matter what I do on my system, I’m not going to accidentally turn on the non-free repos.” but that’s not an increase in agency - it’s no-change at best, and still a decrease at worst. Those are safety rails - and safety is perpetually in tension with agency and freedom.

                                                      There’s “my distribution maintainers are designing with this in mind, so they’ll be more likely to actively look for free alternatives to proprietary software that other distributions might handwave on account of already providing a non-free option” but the existence or absence of software is an ecosystem problem, not a freedom problem (at least not in the sense of “what technical limitations does the system impose on me” (like preventing kernel blobs) that is the topic of discussion).

                                                      That is - the counter-post doesn’t name any kind of freedom or agency that is reduced by using a non-GNU-free distro, and half of their argument rests on that.

                                                      1. 7

                                                        Wow, thanks, I’m cured. My wifi card magically stopped existing and now everything is happy unicorns farting out rainbows that spawn free puppies and everything is saved forever.

                                                        Again, that doesn’t help me with the situation that my wifi card doesn’t work and I as a user want it to even though making it work will require proprietary firmware.

                                                        Okay, then buy a different wi-fi card. Stop trying to use something designed to be incompatible with your proprietary hardware and then getting mad about it not being supported.

                                                        1. 13

                                                          Okay, then buy a different wi-fi card.

                                                          Are you offering to pay for it? Aren’t we all supposed to be out there installing Linux for our friends and relatives to save them from… well, something? Most of those people already have computers that require compromises.

                                                          1. 9

                                                            Then install a distro that does that? GNU Guix is one of literally dozens of active and we’ll maintained distros for people to choose from. Guix System is for people who choose to be uncompromising in their free software stance (with exceptions of course). Would they like for more people to be uncompromising? Yes. Until that day comes is anyone forced to use guix as a Linux distro? No, not at all.

                                                            1. 6

                                                              Their argument is that self-advertised “libre” distributions not only reduce both user agency and total value to the user (including materially important things like security), but also they’re advertised as increasing user agency, when they don’t. Neither of those problems are solved if you, personally, don’t use Guix, because it’ll still sucker in some people who believe the marketing. The problem isn’t just that Guix doesn’t do the thing, it’s that it’s marketed as doing the thing.

                                                              So, amend the marketing, or change Guix to actually respect user freedom - just don’t keep lying.

                                                              1. 4

                                                                Or just use #nonguix

                                                                1. 2

                                                                  Well, that’s what I do.

                                                                  1. 1

                                                                    The whole point of this article is to show that while guix claims to be absolutely dedicated to increasing user agency they deliberately remove the ability for a user to use their computer as they want.

                                                                    Obviously people can use other distros but that isn’t the point. The point is that guix is explicitly doing the opposite of what they claim to be doing.

                                                                    1. 4

                                                                      #nonguix is the guix equivalent of Debian’s non-free repo, not a different distro

                                                                  2. 1

                                                                    I agree, that’s a reasonable stance. That’s actually why I use a Mac, because I got sick of using software that wasn’t designed to work with my hardware :-)

                                                                    1. 3

                                                                      One of the advantages MacOS has is it’s not a mongrel of an OS and most apps follow it’s HIG. So I definitely can relate there.

                                                                      1. 1

                                                                        Alas electron apps are increasingly ruining that. So many now necessary apps that can’t do basic things like find correctly.

                                                                2. 9

                                                                  Okay, then buy a different wi-fi card.

                                                                  This is a really user-hostile response. What if I’m a lifelong Windows user who now wants to try Linux? What if I’m low-income and don’t want to spend the money on purchasing a libre wifi card, or the time to do research on it? What if I’m a gamer who wants my software to be more free than it is, but isn’t a free-software zealot? What if I want wifi 6 and don’t want to spend hours looking for a card with free drivers, or days writing my own?

                                                                  Stop trying to use something designed to be incompatible with your proprietary hardware and then getting mad about it not being supported.

                                                                  You misunderstand their arguments. They’re not complaining about the existence of a distro that doesn’t allow them to install proprietary software; they’re complaining that it’s marketed as increasing user freedom, when it clearly does not, and that the community actively invests effort in making it harder to learn about things that would provide value to the user.

                                                                  1. 5

                                                                    I don’t think it is hostile, no. It’s not hostile to tell someone “the thing you have isn’t compatible with what we’re doing”, it’s a statement of fact. If you’re low-income, that’s unfortunate and you’ll have to stick to using not-guix until your hardware is compatible. If you’re not a “free software zealot”, go ahead and use something else or install the nonfree guix repos. If you want wifi 6, you’ll have to use something compatible with wifi 6. It’s not their goal to be compatible with every possible use case.

                                                                    Guix is not marketed as increasing user freedom. That’s silly. It’s marketed as respecting your freedoms.

                                                                    Liberating. Guix is an advanced distribution of the GNU operating system developed by the GNU Project—which respects the freedom of computer users.

                                                                    It’s not the Guix project’s job to tell you about all the wonderful software that goes against their core values. That’s antithetical to the mission of replacing proprietary software with libre software.

                                                                1. 5

                                                                  Agency is not the same thing as control. Free Software is not just about positive empowerment, but also removing proprietary control.

                                                                  If their goal is really to liberate users and make it easy for them to have control over what their computer is doing, they should make it trivial to escape hatch into a less “pure” setup without having to install third party repositories that you just have to know about or sidestepping the upstream update process to install your own system software.

                                                                  Rephrasing: if their goal is user liberation, then they should make it easy for users to add proprietary controls to their environment. But this is a clear contradiction, since proprietary control is a limitation on user agency.

                                                                  My wifi card magically stopped existing and now everything is happy unicorns farting out rainbows that spawn free puppies and everything is saved forever. [The defective-by-design argument] doesn’t help me with the situation that my wifi card doesn’t work and I as a user want it to even though making it work will require proprietary firmware.

                                                                  It doesn’t require proprietary firmware. It requires a driver. The driver could be authored by anybody with time, patience, a piece of hardware, and the programming manual. Being angry at the Free Software community for not producing the programming manual is misdirection; it wasn’t their obligation.

                                                                  Ubuntu gives the user more agency about how they want to use their computer than fully libre GNU/Linux distros ever can.

                                                                  And distros based on ports trees, from Gentoo to NixOS, are even more empowering, since they lower the discussed adoption barriers even further.

                                                                  1. 5

                                                                    Agency is not the same thing as control. Free Software is not just about positive empowerment, but also removing proprietary control.

                                                                    That’s a euphemistic way to say “there’s also an intentional reduction in user freedom/agency/control along a specific axis”.

                                                                    Rephrasing: if their goal is user liberation, then they should make it easy for users to add proprietary controls to their environment. But this is a clear contradiction, since proprietary control is a limitation on user agency.

                                                                    There is no contradiction. “Making it easy for a user to add proprietary controls to their environment” increases user liberation, period - the claim that this translates to a limitation on user agency is a fallacy. There may be a self-imposed limitation on user agency if the user then decides to exercise this right to add a proprietary control, but that’s a choice the user has - therefore, a freedom, or an agency, if you will, and certainly not one the user is forced into.

                                                                    It doesn’t require proprietary firmware. It requires a driver.

                                                                    How is this relevant to the article? Is the argument materially changed by s/firmware/driver/?

                                                                    The driver could be authored by anybody with time, patience, a piece of hardware, and the programming manual. Being angry at the Free Software community for not producing the programming manual is misdirection; it wasn’t their obligation.

                                                                    This is a misdirection itself - the anger is directed at the community for intentionally making it difficult or impossible to install proprietary software or coordinate doing so - if you read just a few sentences up, you’ll see “talk about that in the main #guix channel and you get told to not talk about it”. This actively requires more work on the side of the #guix channel users than not saying anything at all.

                                                                    Nobody is asking for open-source programmers to do anything for free here - the issues are (1) FSF’s misleading use of terms like “freedom” when they actively restrict user freedom by making it difficult to install various kinds of proprietary software and (2) some parts of the community that buy into the FSF’s ideology doing similar things.

                                                                    1. 4

                                                                      “Making it easy for a user to add proprietary controls to their environment” increases user liberation, period

                                                                      This isn’t the dunk you think it is. From the perspective of a free software purist the user is less liberated from the grasp of proprietary software when they are encouraged to and supported in their use of proprietary software.

                                                                      1. 1

                                                                        I wasn’t trying to be coy or euphemistic. Suppose we have two different ports trees of Free Software. Despite neither tree’s contents adding controls to its users, the different capabilities available to users of the two different trees reflect a difference in agency: the users are free to install different packages.

                                                                        Hardware does not require proprietary firmware, in general. Certainly, the typical WiFi chipset does not. Rather, proprietary firmware is one possible way of configuring the hardware. My favorite vendor to use as an illustration is nVidia, whose GPUs can either be driven with proprietary firmware over an nVidia-only interface, or with reverse-engineered firmware over common interfaces.

                                                                    1. 1

                                                                      What is meant by a “well-written book”?

                                                                      If you mean “beautiful and well-written in a strict prose sense” - then SICP is a well-written book, and I don’t

                                                                      If you mean “appropriate to the domain; in this specific case, because the domain is education: teaches the student efficiently and easily” then I can see SICP as not being particularly well-written; it is, as you and others have stated, very dense, and I can easily imagine (or maybe even recommend) other books that are easier and faster to learn from.

                                                                      Other commentators: the author writes “The core goal of a book recommendation is for the reader to get enjoyment or education from it.” and that’s absolutely true; SICP is an enjoyable book, but I’m not convinced that it is a particularly good book for getting education from. Education is the process of helping other learn stuff, which necessarily means that that stuff has to be made accessible, and SICP doesn’t do the best job at this.

                                                                      I say this as someone who adores Lisp, and has spent the past few months carrying SICP around in my backpack.

                                                                      1. 1

                                                                        *work*: My mentor handed me a PyQt application that needs additional functionality added - it’s been a very…. interesting… experience…

                                                                        *personal*: Almost have my handmade PIM able to capture the ~40k-item knowledge base that I have fragmented into various parts of my hard drive - and after I have the live data, it’ll be much more motivating to work on the functionality.

                                                                        1. 4

                                                                          Really great approach! The whole post showcases quite pragmatic approach to the problem they had and how they optimized it for. My favorite sentence is at the end:

                                                                          The library works for our target platforms, and we don’t wish to take on extra complexity that is of no benefit to us.

                                                                          Truly pragmatic approach: it works for us, if you want, fork and modify to oblivion, we give you a starting point. Wish more software is handled like this and doesn’t include all but kitchen sink.

                                                                          1. 0

                                                                            More and more people are fortunately adopting the suckless philosophy.

                                                                            1. 15

                                                                              Unfortunately, the suckless philosophy leads to software that doesn’t do what software is meant to do - alleviate human work by making the machine do it instead. The suckless philosophy of “simplicity” translates to “simplistic software that doesn’t do what you would need it to do, so either you waste time re-implementing features that other people have already written (or would have written), or you do the task by hand instead”.

                                                                              If, when required to choose exactly one of “change the software to reduce user effort” and “make the code prettier”, you consistently choose the latter, you’re probably not a software engineer - you’re an artist, making beautiful code art, for viewing purposes only. You definitely aren’t writing programs for other people to use, whether you think you are or not.

                                                                              This philosophy (and the results) are why I switched away from dmenu to rofi - because rofi provided effort-saving features that were valuable to me out-of-the-box, while dmenu did not. (I used dmenu for probably a year - but it only took me a few minutes with rofi to realize its value and switch) rofi is more valuable as a tool, as a effort-saving device, than dmenu is, or ever will be.

                                                                              In other words - the suckless philosophy, when followed, actively makes computers less useful as tools (because, among other things, computers are communication and collaboration devices, and the suckless philosophy excludes large collaborative projects that meet the needs of many users). This is fine if your purpose is to make art, or to only fulfill your own needs - just make sure that you clearly state to other potential users that your software is not meant for them to make use of.

                                                                              Also note that the most-used (and useful) tools follow exactly the opposite of the suckless philosophy - Firefox, Chromium, Windows, Libreoffice, Emacs, VSCode, Syncthing, qmk, fish, gcc, llvm, rustc/cargo, Blender, Krita, GIMP, Audacity, OBS, VLC, KiCad, JetBrains stuff, and more - not just the ones that are easy to use, but also ones that are hard to use (Emacs, VSCode, Audacity, Blender, JetBrains) but meet everyone’s needs, and are extensible by themselves (as opposed to requiring integration with other simple CLI programs).

                                                                              There’s a reason for this - these programs are more useful to more people than anything suckless-like (or built using the Unix philosophy, which shares many of the same weaknesses). So, if you’re writing software exclusively for yourself, suckless is great - but if you’re writing software for other people (either as an open-source project, or as a commercial tool), it sucks.

                                                                              To top it off, people writing open-source software using the suckless philosophy aren’t contributing to non-suckless projects that are useful to other people - so the rest of the open-source community loses out, too.

                                                                              1. 2

                                                                                It’s fine to disagree with “the suckless philosophy”, but do please try to be nice to people gifting their work as FLOSS.

                                                                                1. 11

                                                                                  The tone is not dissimilar from the language on the page it is replying to: https://suckless.org/philosophy/

                                                                                  Many (open source) hackers are proud if they achieve large amounts of code, because they believe the more lines of code they’ve written, the more progress they have made. The more progress they have made, the more skilled they are. This is simply a delusion.

                                                                                  Most hackers actually don’t care much about code quality. Thus, if they get something working which seems to solve a problem, they stick with it. If this kind of software development is applied to the same source code throughout its entire life-cycle, we’re left with large amounts of code, a totally screwed code structure, and a flawed system design. This is because of a lack of conceptual clarity and integrity in the development process.

                                                                                  1. 1

                                                                                    I wasn’t actually trying to copy the style of that page, but I guess that I kind of did anyway.

                                                                                    @JoachimSchipper (does this work on Lobsters?) My reply wasn’t meant to be unkind to the developer. I’m frustrated, in the same sense that you might be frustrated with a fellow computer scientist who thought that requiring all functions to have a number of lines of code that was divisible by three would improve performance, an idea which is both obviously wrong, and very harmful if spread.

                                                                                    …but I wasn’t trying to impart any ill will, malice, or personal attack toward FRIGN, just give my arguments for why the suckless philosophy is counter-productive.

                                                                                2. 1

                                                                                  Some people insist on understanding how their tool works.

                                                                                  I have a few friends like that - they are profoundly bothered by functionality they don’t understand and go to lengths to avoid using anything they deem too complex to learn.

                                                                                  The rest of open source isn’t ‘losing out’ when they work elsewhere - they weren’t going to contribute to a ‘complex’ project anyways, because that’s not what they enjoy doing.

                                                                                  1. -4

                                                                                    Nice rant

                                                                                    1. 5

                                                                                      You throw advertising for suckless in the room as the true way, link to your website with the tone described here and then complain about responses ? That doesn’t reflect well on the project.

                                                                                      1. 0

                                                                                        What are you talking about? There is no one single true way, as it heavily depends on what your goals are (as always). If your goals align with the suckless philosophy, it is useful to apply it, however, if your goals differ, feel free to do whatever you want.

                                                                                        I don’t feel like replying exhaustively to posts that are ad hominem, which is why I only (justifiably) marked it as a rant. We can discuss suckless.org’s projects in another context, but here it’s only about the suckless philosophy of simplicity and minimalism. I am actually surprised that people even argue for more software complexity, and SLOC as a measure of achievement is problematic. In no way does the suckless philosophy exclude you from submitting to other projects, and it has nothing to do with pretty code. You can do pretty complex things with well-structured and readable code.

                                                                                        1. 4

                                                                                          While you may find it insulting, I don’t think the comment is ad hominem at all. It’s not saying that the suckless philosophy is defective because of who created/adopts/argues for it. That would be an attack ad hominem. The comment is saying the suckless philosophy is defective because software that adheres to it is less useful than other software, some of which was then listed in the comment.

                                                                                          While it’s (obviously) perfectly fine to feel insulted by a comment that says your philosophy produces less-than-useful software, that does not make the comment either a rant or an ad hominem attack.

                                                                                          It’s a valid criticism to say that over-simplifying software creates more human work, and a valid observation that software which creates more human work doesn’t do what software is meant to do. And you dismissed that valid criticism with “Nice rant.” If you don’t feel like responding exhaustively, no one can blame you. But I view “nice rant” as a less-than-constructive contribution to the conversation, and it appears that other participants do as well.

                                                                                          1. 2

                                                                                            My post was neither a rant, nor ad-hominem. You should be a bit more thoughtful before applying those labels to posts.

                                                                                            It’s clearly not an ad-hominem because nowhere in my post did I attack your character or background, or use personal insults. My post exclusively addressed issues with the suckless philosophy, which is not a person, and is definitely not you.

                                                                                            It’s also (more controversially) probably not a rant, because it relies on some actual empirical evidence (the list of extremely popular programs that do the opposite of the suckless philosophy, and the lack of popularity among programs that adhere to it), is well-structured, is broken up into several points that you can refute or accept, had parts of it re-written several times to be more logical and avoid the appearance of attacks on your person, and takes care to define terminology and context and not just say things like “suckless is bad” - for instance, the sentence “So, if you’re writing software exclusively for yourself, suckless is great - but if you’re writing software for other people (either as an open-source project, or as a commercial tool), it sucks” specifically describes the purpose for which the philosophy is suboptimal.

                                                                                            It also had at least three orders of magnitude more effort put into it than your two-word dismissal.

                                                                                        2. 4

                                                                                          Rather than labeling it a rant, wouldn’t it be more persuasive to address some of the points raised? Can you offer a counterpoint to the points raised in the first or last paragraphs?

                                                                                          1. 2

                                                                                            It is definitely a rant, as the points adressed are usually based on the question which norms you apply. Is your goal to serve as many people as possible, or is your goal to provide tools that are easy to combine for those willing to learn how to?

                                                                                            In an ideal world computer users would, when we consider the time they spend with them, strive to understand the computer as a tool to be learnt. However, it becomes more and more prevalent that people don’t want to and expect to be supported along the way for everything non-trivial. We all know many cases where OSS developers have quit over this, because the time-demand of responding to half-assed PRs and feature-requests is too high.

                                                                                            @fouric’s post went a bit ad-hominem regarding “software engineers” vs. “artists”, but I smiled about it as my post probably hit a nerve somewhere. I would never call myself a “software engineer”.

                                                                                            Hundreds of thousands of people are using suckless software, knowingly or unknowingly. Calling us “artists” makes it sound like we were an esolang-community. We aren’t. We are hackers striving for simplicity.

                                                                                            I could also go into the security tangent, but that should already be obvious.

                                                                                            1. 1

                                                                                              It is definitely a rant, as the points adressed are usually based on the question which norms you apply.

                                                                                              …norms which I addressed - I was very clear to describe what purposes the suckless philosophy is bad at fulfilling. That is - my comment explicitly describes the “norms” it is concerned with, so by your own logic, it is not a rant - and certainly contains more discussion than any of your further replies, who do nothing to refute any of its points.

                                                                                              @fouric’s post went a bit ad-hominem regarding “software engineers” vs. “artists”

                                                                                              Nor is there any ad-hominem contained in the comment, and certainly nothing around my differentiation between “software engineers” and “artists” - nowhere did I make any personal attack on your “character or motivations”, or “appeal to the emotions rather than to logic or reason”, as a quick online search reveals for the phrase “ad-hominem”.

                                                                                              I smiled about it as my post probably hit a nerve somewhere.

                                                                                              If you want to refute any of the points I made, you’re welcome to do it. However, if you just want to try to arouse anger and smile when you do so, I’ll ask you to stop responding to my posts, especially with a two-word dismissal that doesn’t address any of my arguments.

                                                                                              I would never call myself a “software engineer”

                                                                                              …then it should be even more clear that my post was not a personal attack or ad-hominem against you. “You keep using that word…”

                                                                                      2. 4

                                                                                        How does the suckless philosophy interact with feature flags?

                                                                                        1. 2

                                                                                          Suckless would say you should only have features you use, and instead of feature flags you have optionally-applied patches

                                                                                    1. 3

                                                                                      Start by implementing a graph based algorithm.

                                                                                      My favorite personal projects are all intrinsically graph-based. Is Rust a poor fit for me?

                                                                                      1. 3

                                                                                        Use something like petgraph you will be fine. Or if you’re implementing it by hand, store the nodes in an arena/vec and instead of pointers use indicies.

                                                                                        It’s a bit of a bigger step for newcomers, because you’re learning both “rust” and “how to deal with graphs in rust without fighting the borrow checker” at the same time, instead of one and then the other.

                                                                                        1. 1

                                                                                          The takeaway message here isn’t “graphs are impossible, or even particularly hard to do in Rust (once you know Rust)”.

                                                                                          It’s that Rust makes you think very explicitly about the hardest part of graph programming (provably avoiding dangling pointers in all cases, in all codepaths), and that trying to work at this level of explicitness in a language you haven’t actually learned yet is an easy way to self-sabotage the learning process.

                                                                                          Learn Rust. Learn lifetimes and ownership and how those things interrelate to allow for correct memory management, and how Rust deals with the heap and runtime ways of enforcing ownership rules, etc. Learn about strategies like arena allocation for when you want children to be able to point at their parents without owning their memory. Then build your fun graph projects.

                                                                                          Just don’t try to walk and chew bubblegum at the same time when you’re not even crawling yet.

                                                                                          1. 1

                                                                                            Same for me and I still manage to write them. Simply be sure to understand that you’ll have to suffer more than other people learning Rust if you start here. The best working approach is the arena+index one but it needs you to be very cautious (test units help, of course) as it means you’re going around the protection given by the ownership model.

                                                                                          1. 24

                                                                                            No JavaScript means no in-browser simulations or interactive examples, which makes the teacher in me sad :(

                                                                                            EDIT from the linked rant, emphasis mine:

                                                                                            I know, I know - this website itself uses a little, teeny-tiny amount of CSS. I am indeed a hypocrite - but did I ever claim that I practice what I preach? At least this personal website is JavaScript-free… (apart from a handful of CodePen examples embedded in some of the tutorials).

                                                                                            Exactly!

                                                                                            1. 11

                                                                                              Nah, you’d just use Java applets or Flash movies, like in the “good old days” when JS wasn’t as powerful as it is today.

                                                                                              1. 9

                                                                                                This is a really good point. Some of the most incredible blogs have lots of JavaScript-based demo’s and examples. For example: https://ciechanow.ski/

                                                                                                1. 3

                                                                                                  Yeah, people who advocate getting rid of JavaScript don’t seem to be serious about education, because anyone who is knows that interactivity is far better than (pure) static content for teaching almost anything to almost anyone.

                                                                                                  1. 2

                                                                                                    It’d be a good first step to only allow Javascript from the same domain, ban third party scripts.

                                                                                                1. 5

                                                                                                  This article quotes the main thrust of the article it’s responding to, but it doesn’t address it. I’ll quote it again because it’s so damned important.

                                                                                                  Then, they return to real life.

                                                                                                  The point that the original author was making is so critical that it’s likely to go entirely unnoticed by any subsequent conversation. Because it’s not about whether the web is better (nicer or less nice, more boring or more interesting, more powerful or less powerful) with all the advanced doohickeys at our disposal. It’s not even, primarily, about accessibility. The vision it’s proposing is of a web that is less nice, and more boring, so that we don’t live there. We live here, instead, where our bodies and our people are. And even if our people are only accessible via the web, the web itself is as thin a layer as possible over their words (or their video, or audio…). The less designed it is, the less of it there is to get stuck into. And ultimately, we want it not to exist at all. We want it to be so thin and transparent that it melts away.

                                                                                                  1. 7

                                                                                                    The vision it’s proposing is of a web that is less nice, and more boring, so that we don’t live there.

                                                                                                    That’s not a vision that I like, personally. When I was young and all I had was books, I used to devour my local library. While I certainly would dumpster dive and try to play around with discarded computers since my family didn’t have money for much, I spent the vast majority of my intellectual time in the world of books. I wasn’t really an exception either, I knew many other kids my age, and honestly many adults at the time, who also spent their free time with their noses glued to books. Some of these books were high-brow, but many of them were just pulp mystery, science fiction, romance, or thrillers. Generations of my family have loved reading books and reading newspapers. The internet then was just the next step to this consumption and sharing of information, not all of it intellectual or even useful. I may have spent a little more time in the books than was good for me at that age, but almost nobody proposed having books be some place where we “don’t live there” or that books should be “as thin a layer as possible over their content” or “the less designed it is, the less of it there is to get stuck into”.

                                                                                                    I’m of the opinion that individuals should be able to make their lives revolve around whatever it is they want it to revolve around. Whether that’s code, prose, art, or whatever, it doesn’t matter. Usual caveats about harming others and such apply. I also largely agree with @fouric here. You’re trying to propose a technical solution to what is essentially a social problem.

                                                                                                    1. 6

                                                                                                      The vision it’s proposing is of a web that is less nice, and more boring, so that we don’t live there.

                                                                                                      This is exactly the wrong way to solve this problem.

                                                                                                      The problem is both content that is designed to be addicting (which can certainly survive even in a world without stylesheets) and users that have been habituated towards addicting habits and lost the discipline to decide what to do with their own time.

                                                                                                      These are both social problems, not technical ones, and need social(-adjacent) solutions, not technical ones.

                                                                                                      Crippling the web, which is an incredibly useful and valuable tool, to try (and fail) to fix a social problem (which is independent of the technology) is an incredibly bad idea, somewhat analogous to getting rid of GPUs because of the number of people addicted to video games.

                                                                                                      Not to mention that it’s far easier (and more probable) to change the content and consumers than it is to get Google and Mozilla and Apple to all remove rich media features that virtually every one of their users will be extremely unhappy about.

                                                                                                    1. 6
                                                                                                      1. Helping evade sanctions may get people (+on this thread) in trouble. See the North Korea Bitcoin talk case. Also, don’t put your friends in Europe at risk and use something like Github Pages or Netlify to host your site maybe?
                                                                                                      2. Whatever jurisdiction you choose, make sure to obey their laws. See the recent Protonmail case.
                                                                                                      3. Some countries are not fans of OFAC sanctions. A Chinese or Russian domain registrar may tell you if your place of residence is a big deal for them or not. Though using their tlds may not be that classy for your blog.
                                                                                                      4. Don’t evade sanctions (see #1).
                                                                                                      1. 10
                                                                                                        1. I don’t think hosting some website breaks sanctions, and if it does, I don’t care about what them as these sanctions are inhumane.

                                                                                                        2. Nope. If the law is inhumane, I won’t follow.

                                                                                                        3. China and Russia are no different than Iran and USA so it’s a no.

                                                                                                        4. I will actually, with everything I can. I don’t care if some Americans think all people of a nationality should live under sanctions and face various troubles and difficulties just because they can’t figure their shit. It’s racist kind of.

                                                                                                        1. -1

                                                                                                          What makes these sanctions “inhumane”? They were a response to specific actions by the Iranian government - shouldn’t you be asking them? Moreover, what prevents you from renouncing your citizenship and moving to another country?

                                                                                                          1. 1

                                                                                                            What the fuck? First, sanctions target people, not governments. Governments should be responsible, not people. Sanctions are inhumane because it targets innocent people, it fucks everything for innocent people. 40 years of sanctions and it’s only people who suffer from them. Second, you can’t expect people to simply move away from where they always lived and are living. It’s easy for you to say, not for people who live under an authoritative regime, not for people who are sanctioned and their economy is fucked. Not for people who every other government ignore them.

                                                                                                            1. 1

                                                                                                              What the fuck?

                                                                                                              Please don’t display such unprofessional and un-intellectual behavior here - this site is meant for intellectual discussion of technical topics, which you’ve already disrupted with your barely-on-topic post.

                                                                                                              First, sanctions target people, not governments.

                                                                                                              This is false - the Iran sanctions target the nation of Iran. You stop being an Iranian, the sanctions stop applying to you - so, by definition, they don’t target people.

                                                                                                              Sanctions are inhumane because it targets innocent people, it fucks everything for innocent people.

                                                                                                              No country owes your country any kind of trade deal - nations have the absolute right to refuse to do business with any other nation for any reason. Doing trade with another country is a privilege, not a right. It’s your government that’s responsible for taking care of you, not the United States - and, in this case, it was also the actions of your government that caused the US to sanction you, as they don’t just go around randomly refusing to do business with countries by rolling dice.

                                                                                                              Second, you can’t expect people to simply move away from where they always lived and are living. It’s easy for you to say, not for people who live under an authoritative regime, not for people who are sanctioned and their economy is fucked.

                                                                                                              If you’re prevented from leaving your country, then that’s your government that is taking advantage of you, not anyone else’s government, all of which have the absolute right to refuse trade deals with your government.

                                                                                                              Sanctions are a tool that governments use to shape the behavior of others, and are generally a rather humane alternative to war - and I don’t hear you calling for the US to invade Iran to replace your government. Those are your two options - sanctions and war, because it’s insane to just continue to do trade with an authoritarian government with no repercussions.

                                                                                                              I know that you have a hard life - but that’s not the fault of the US government, that’s exclusively the fault of the Iranian government. Direct your anger there, where it belongs.

                                                                                                              1. 2

                                                                                                                It’s sad to see such uncritical acceptance of the worst parts of US foreign policy being espoused on this site.

                                                                                                                1. 1

                                                                                                                  Please don’t display such unprofessional and un-intellectual behavior here

                                                                                                                  I apologize for that.

                                                                                                                  This is false - the Iran sanctions target the nation of Iran. You stop being an Iranian, the sanctions stop applying to you - so, by definition, they don’t target people.

                                                                                                                  You just repeated what I said and then claimed they don’t target people. Did you read what you wrote?

                                                                                                                  No country owes your country any kind of trade deal - nations have the absolute right to refuse to do business with any other nation for any reason. Doing trade with another country is a privilege, not a right. It’s your government that’s responsible for taking care of you, not the United States - and, in this case, it was also the actions of your government that caused the US to sanction you, as they don’t just go around randomly refusing to do business with countries by rolling dice.

                                                                                                                  You’re talking about something completely different. What a government does should not put people in this situation. Iranian government is authoritative and not democratic. Sanctioning all Iranian people for what that regime does is inhumane.

                                                                                                                  What you say about other governments wanting to trade is false because many countries want to trade but they can’t because U.S. forces them with its power. Now you can say it’s Iranian government’s fault, and I agree, but people are innocent and sanctioning all people of a nation is inhumane.

                                                                                                                  If you’re prevented from leaving your country, then that’s your government that is taking advantage of you, not anyone else’s government, all of which have the absolute right to refuse trade deals with your government.

                                                                                                                  This is completely irrelevant. Doesn’t matter whose fault it is, U.S., Iran, or any other government, I don’t care what a government thinks about me, I care for people. What Iranian regime does is what any other authoritative regime does, sacrificing people for its own benefits. That is however not a reason for any other government to impose inhumane rules and laws on innocent people.

                                                                                                                  I know that you have a hard life - but that’s not the fault of the US government, that’s exclusively the fault of the Iranian government. Direct your anger there, where it belongs.

                                                                                                                  It is partly U.S.’ fault though. U.S. is not innocent in this. You don’t want to accept it? Fine with me. I’m not responsible for what you believe. I don’t accept what Iranian government does, but that doesn’t mean U.S. is innocent country who is forced to impose sanctions on all people. U.S. is no different than Iran when it comes to human rights, the only difference is that Iranian regime kills its own people more obvious than U.S.

                                                                                                          2. 5

                                                                                                            Don’t evade sanctions (see #1).

                                                                                                            These “sanctions” are only between some countries (like the USA) and Iran. There is a lot of other countries that have actually good relations with Iran, and they aren’t “evading sanctions”: USA doesn’t rule the world.

                                                                                                            1. 3

                                                                                                              I was curious about this so I looked it up. This article seems to indicate that this sort of discussion or advice wouldn’t be an issue at all. Also this law seems to say directly providing web hosting or domain name registration wouldn’t be an issue for blogging, etc.

                                                                                                              I’m not a lawyer, this is not legal advice, etc. I’m guessing these kinds of laws are usually enforced based on politics more than the laws themselves, but who knows.

                                                                                                            1. 5

                                                                                                              I like this idea, and I think that this is part of what (interactive) provides in Emacs Lisp - the demarcation of a function as a user method.

                                                                                                              1. 4

                                                                                                                This article doesn’t make the same old “complex software is bad” fallacy, but it does make a related one: that large APIs intrinsically make a library difficult to use. This is rubbish - almost every library I’ve seen has bad documentation, including the simple ones - with the difference being that when a library is simple, bad documentation is much less noticeable, because if you can fit the whole API reference in a few pages, you tend not to notice the poor organizational structure or adherence to [https://documentation.divio.com/](the correct documentation format).

                                                                                                                Similarly, the number of functions is an API has very little to do with its difficulty of use - that’s a function of (1) how well the documentation allows you to filter and find the functions that you need (2) the actual number of concepts that the library exposes and (3) the difficulty of using the functions you actually care about. Let’s take the Docker documentation (which is very slightly less bad than most docs) as an example - when the developers add a new CLI command, it has no effect on how difficult it is for me to continue to use Docker. I don’t even notice that I can now run “docker ai-singularity”, let alone does it make it any harder for me to use the rest of the tool.

                                                                                                                1. 4

                                                                                                                  Large APIs aren’t necessarily more difficult to use, that’s true. But it’s also true that, all else equal, a smaller API is better than a larger one.

                                                                                                                  when the developers add a new CLI command, it has no effect on how difficult it is for me to continue to use Docker. I don’t even notice that I can now run “docker ai-singularity”, let alone does it make it any harder for me to use the rest of the tool.

                                                                                                                  I don’t think that’s true. Every expansion of the surface area of a thing necessarily increases the cognitive burden of understanding it. You can just stick to your little corner, of course, but that’s sidestepping the point.

                                                                                                                  1. 1

                                                                                                                    all else equal, a smaller API is better than a larger one

                                                                                                                    Absolutely. Unfortunately, all else is never equal, because the feature-set of the tool/library/framework affects API size. You can make the argument that you should try to get the same number of features with a smaller API, but that’s a matter of actual design, not merely reducing the API size, and especially not in the way that the author is suggesting (by removing useful features).

                                                                                                                    I don’t think that’s true. Every expansion of the surface area of a thing necessarily increases the cognitive burden of understanding it.

                                                                                                                    Your use of “understanding” is different than mine. You’re using it to mean “complete understanding of the entire tool”, which is not very valuable. There’s no reason for you to need to understand every feature of a tool that you’re using, unless it was designed that way - which is extremely poor design, and avoidable in almost every situation.

                                                                                                                    Examples: Linux, Docker, Firefox, Emacs, tmux, vim, gcc, llvm, Chrome, Microsoft Word, Windows, PowerShell…almost every single software tool that has any non-trivial number of users is designed such that you don’t need to understand every one of its features in order to use it effectively - and as a matter of fact almost every computer user, including the most competent ones, doesn’t completely understand all of the features of their tools.

                                                                                                                    So, your statement is trivially true, and effectively useless.

                                                                                                                    You can just stick to your little corner, of course, but that’s sidestepping the point.

                                                                                                                    If that’s the point, then the point is wrong. Good design means not needing to care about features that you’re not using. Making the API smaller in order to make it simpler means that it has bad design.

                                                                                                                    1. 1

                                                                                                                      You can make the argument that you should try to get the same number of features with a smaller API, but that’s a matter of actual design, not merely reducing the API size,

                                                                                                                      That’s right. Similar to good writing, well-designed APIs are as small as they can possibly be (but no smaller).

                                                                                                                      and especially not in the way that the author is suggesting (by removing useful features).

                                                                                                                      The author is not suggesting that useful features should be removed, and the package being discussed does not remove useful features.

                                                                                                                      almost every single software tool that has any non-trivial number of users is designed such that you don’t need to understand every one of its features in order to use it effectively … Good design means not needing to care about features that you’re not using.

                                                                                                                      I agree that good design makes it possible to use something effectively without fully understanding all of its features, but “features you’re not using” are value-negative, not neutral or positive.

                                                                                                                      1. 1

                                                                                                                        The author is not suggesting that useful features should be removed, and the package being discussed does not remove useful features.

                                                                                                                        If your issue is with the word “removed” - the author is pushing the idea that useful features should not be included in the first place - which is not an interesting or relevant distinction.

                                                                                                                        If your issue is with the word “useful” - colors and prompts are both useful features that the library is specifically excluding, so yes, the features being discussed are useful.

                                                                                                                        “features you’re not using” are value-negative, not neutral or positive.

                                                                                                                        I agree, but the meaning of “you” is important. The author is writing a library for others to use, and I can guarantee you that people who write CLI’s with Go are going to want to use some of the features that are being specifically excluded, such as color and prompting.

                                                                                                                        More generally, if you’re writing a thing for yourself, then good design is cutting out all of the features that you’re not going to use - but if you’re writing a thing for other people to use (which the author of the article/library is), then good design is putting in features that those other people are going to use.

                                                                                                                        This relates back to the topic of APIs: a smaller API is only better if it supports its users equally well - which the topical Go library did not, given that it elided valuable functionality in order to shrink its API footprint. Note that it’s possible to have valid reasons to remove functionality - most notably, because the users don’t use that functionality any more - but the author explicitly mentioned wanting to make the interface smaller, which is not a valid reason (only a side-effect).

                                                                                                                        1. 1

                                                                                                                          I can guarantee you that people who write CLI’s with Go are going to want to use some of the features that are being specifically excluded, such as color and prompting.

                                                                                                                          Is it important that all of the features that are conceivably useful for something be included in a single package?

                                                                                                                          1. 1

                                                                                                                            That’s misrepresentating my argument. I specifically mentioned two features, color support and CLI prompts, that are going to be used by many people building CLIs in Go.

                                                                                                                            The mentioned packages for those features have over 4k stars on GitHub each (significantly higher than ffcli, which as of the time of this writing has less than 900). To suggest that those are merely “conceivably useful” and not actually used by a significant number of people is disingenuous.

                                                                                                                            Nor did I say that libraries shouldn’t have limited scope - again, my point is that limiting API size is not a good reason for limiting scope by itself. Limiting scope is useful for maintainers - but it shouldn’t be portrayed as being good for users, because it rarely (if ever) is.

                                                                                                                            1. 1

                                                                                                                              Limiting scope is useful for maintainers - but it shouldn’t be portrayed as being good for users, because it rarely (if ever) is.

                                                                                                                              I don’t agree; it depends on what you’re trying to optimize for. Personally, as a user, I always prefer packages with well-defined and non-leaky abstractions, with totally orthogonal features, which are easy to understand totally, rather than easy to use. This almost always corresponds to a smaller API and more limited scope. I build packages in the same way.

                                                                                                                              1. 1

                                                                                                                                All forms of “optimizing for your users” take the form of “total utility for them”. This almost always corresponds to a feature-set that covers their needs, and because users are very diverse, so are their needs, and so the necessary feature-set is large.

                                                                                                                                I can also assure you that you’re an edge-case - I’ve heard hundreds of complaints in person (and thousands online) about software from dozens (and thousands, respectively) of users, and the number of complaints about missing features vastly outweighed complaints that “these two features aren’t orthogonal” or “this abstraction was too leaky”.

                                                                                                                                More generally, the number complaints that I hear about missing features is orders of magnitude greater than the number of complaints about “too many features” or not being able to understand the tool - and I’ve never heard anyone say “I don’t like this tool because I can’t understand it completely” until you stated that opinion - you, sir, are an outlier among users, and your preferences are not consistent with the majority of them.

                                                                                                                                Moreover, your preference has a negative correlation with utility. You’re welcome to have it, but for my own good (as well as that of the ecosystem), I’m going to actively discourage others from adopting it as well. A tool which is easy to understand totally is feature-limited (and utility-limited) by definition, whereas you can build a feature-rich tool that is easy to use, provides value, is easy to understand in part, and gives you all the features that you need to accomplish your desired task.

                                                                                                                                1. 1

                                                                                                                                  (more features always better)

                                                                                                                                  I understand this perspective, and why it’s popular. But it’s a local optima that produces a bad global result. Best way I can express it is via the commandline. The “UNIX philosophy” describes a constellation of well-scoped, more-or-less single-purpose tools, composed together to solve higher-order problems. It is strictly superior in every meaningful metric to the all-in-one approach exemplified by — I don’t know — maybe Docker, arguably git, probably jq, etc.

                                                                                                                                  Of course you ask Joe Public which they like better between the coreutils and jq and they’ll say jq. But letting that kind of user dictate the direction of your project is myopic. The question “what don’t you like about X” is scoped to a single tool, or component. You will of course never receive the answer that it’s doing too much. That response speaks at the scope of the entire system, the problem domain — it’s about the design of a larger thing.

                                                                                                                                  A similar story plays out in the evolution of programming languages. Everyone always wants to add features, because features have value. But that’s a truism: a feature necessarily has value. That’s not what’s important. The important consideration is the effect that feature has on the system, the language as a whole, the ways it interacts with every other feature and property of the language, combinatorially, that it touches. Languages start good and get bad over time because the original designers tend to have this (essential! important!) systems perspective in their minds as they build the thing, but almost nobody who comes later can say the same.

                                                                                                                                  The Design of Design by Fred Brooks is a great book on this topic. The most influential book I’ve read professionally.

                                                                                                                                  I can also assure you that you’re an edge-case - I’ve heard hundreds of complaints in person (and thousands online) about software from dozens (and thousands, respectively) of users, and the number of complaints about missing features vastly outweighed complaints that “these two features aren’t orthogonal” or “this abstraction was too leaky”.

                                                                                                                                  Heh, I bet! Well, here’s one now: jq sucks. It sucks that it does all of its work in a single execution of a process, via its own unique query language, provided in a single opaque string by the user. It would be a far better tool if each invocation performed a single transformation, if its query language were far less powerful, and if it worked on text streams like ~every other tool. The resulting and substantial loss of expressive capability would be a huge step backwards at the component level, but an enormous improvement at the system level.

                                                                                                                                  1. 3

                                                                                                                                    (more features always better)

                                                                                                                                    I never said that, nor is that my position - I believe that the right number of features is what your users need (I specifically said “so the necessary feature-set is large” - not infinite, nor ever-expanding). This means a large number of features, not every conceivable number of them - but certainly not an artificial restriction in order to obtain some amount of “beauty”.

                                                                                                                                    But it’s a local optima that produces a bad global result. Best way I can express it is via the commandline. The “UNIX philosophy” describes a constellation of well-scoped, more-or-less single-purpose tools, composed together to solve higher-order problems. It is strictly superior in every meaningful metric to the all-in-one approach exemplified by — I don’t know — maybe Docker, arguably git, probably jq, etc.

                                                                                                                                    This is backwards. The UNIX philosophy is the one that yields a local optima producing a bad global result, precisely because the constellation of single-purpose tools results in much greater complexity from the composition and integration of those tools. Said another way - as you decrease the complexity of your individual tools (whether they be functions or programs), the complexity of the individual modules decreases linearly, but the complexity of the whole system increases superlinearly, because the complexity of “plumbing” those modules together increases as the square of the number of modules.

                                                                                                                                    This has a lot of evidence behind it. For all of the elegance of the UNIX philosophy, you never see any functional large system built with UNIX shell scripts and command-line tools, or entirely out of tiny functions <10 lines each, because such systems are (1) fragile and (2) difficult to understand and architect due to extremely high levels of indirection. Linux won over Minix partially because of the complexity of the microkernel approach, which boils down to the UNIX philosophy. All of the tools that you named are incredibly popular, because they actually deliver concrete value to their users. You want to know of some other massive, integrated, feature-expanding tools that are very popular and extremely useful to users? The Linux kernel itself, Firefox, Blender, Emacs, vim, Visual Studio Code, Python, gcc, LLVM, LibreOffice, Krita, GIMP, Audacity, Anki, Singularity, Terraform, C++, Common Lisp (kind-of - it’s only popular among Lisp users, but notably it’s more popular than Scheme, with the main design difference being that Common Lisp throws everything and the kitchen sink in, whereas Scheme is a pretty “jewel” language).

                                                                                                                                    All of these things allow users to get things done more easily than if they had to assemble their own system out of primitive UNIX CLI components - furthermore, a pre-assembled system made out of those components, with the same levels of features, would be massively more complex from a source-code perspective, as well as far less performant.

                                                                                                                                    It is strictly superior in every meaningful metric to the all-in-one approach exemplified by

                                                                                                                                    If this were true, then most, if not all, popular tools would be compositions of simple UNIX CLI tools, because they would be easier to understand (lower code complexity), more featureful, and higher-performance. They’re not, which further invalidates that theory, in addition to the theoretical arguments I presented above.

                                                                                                                                    That is to say - whole-system complexity is increased by reducing the size of the modules your system is composed of. If you don’t agree with that, then I would like to ask you why Linux CLI enthusiasts haven’t re-written any of the above tools that I’ve named from their current language into UNIX CLI tools, and then had their solutions overtake the originals due to their superiority - or why none of those above tools were composed of UNIX CLI tools in the first place (with the possible exception of git, which might be currently being re-written from shell scripts into C? but which you already explicitly condemned as being “all-in-one”) - or why few, if any, useful programs today are composed of a large number of small functions/objects.

                                                                                                                                    Now, am I arguing against orthogonal design? Absolutely not - I think that designs should be made orthogonal in order to provide value to the user. A tool with a slightly smaller number of features, with significantly more orthogonality built in, will be more useful to users than one with a few more features but much less orthogonality. What I’m arguing against is the UNIX philosophy, that takes this to an extreme, to the detriment of users and to whole-system complexity.

                                                                                                                1. 33

                                                                                                                  Can we please stop normalizing spyware? I’m going to repost my comment from last time this bullshit was on this lobste.rs:

                                                                                                                  This site is claiming to offer a “standard for opting out of telemetry”, but that is something we we already have: Unless I actively opt into telemetry, I have opted out. If I run your software and it reports on my behavior to you without my explicit consent, your software is spyware.

                                                                                                                  1. 4

                                                                                                                    A shame I can’t upvote this more than once. This madness needs to stop.

                                                                                                                    1. 2

                                                                                                                      I disagree. Telemetry, which is a feature which does not collect personally-identifiable information (or attempt to fingerprint) by definition, is not spyware.

                                                                                                                      Moreover, I disagree that “actively opt[ing] into telemetry” is needed for software to report (again, by definition) non-PII usage information about itself, for the benefit of the software developers, and by extension the rest of the community. This biases the data and makes it much less useful, and because telemetry is non-PII by definition, there’s no harm to the user.

                                                                                                                      Now, that’s on a philosophical level. On a practical level, telemetry from trustworthy actors (Mozilla, and open-source projects more generally) is usually trustworthy, while “telemetry” from non-trustworthy sources (e.g. Microsoft, Google) is often not merely telemetry and collects fingerprinting and/or PII information (which, again, is not “telemetry” to begin with) - and so, the only safe action to take is just to turn off every switch that you have.

                                                                                                                      This “console do not track” proposal doesn’t work for either the good or bad actors. It fails for the good actors because, while I don’t want ads (which a good actor wouldn’t include in the first place), I do want telemetry and crash reporting, and most people want automatic updates. It fails for the bad actors because they won’t respect this switch anyway.