Threads for mfeathers

    1. 3

      “You can’t read from files during unit tests: “;

      Please explain. I agree that if you have a doSomething(String data) function you should write a unit test and feed it a String of data, not a path to a file. But how would you unit-test your “read a file” function in the step before, assuming it’s not just a standard library call.

      1. 1

        That could be a test but it should not be mixed in with your unit tests. Unit tests should be purely computational. If you do this uniformly, you end up with a layer between computation and IO that most systems lack. It’s ‘separation of responsibilities’ and good for design.

        Some guy wrote about this a long time ago. https://www.artima.com/weblogs/viewpost.jsp?thread=126923

        1. 1

          Well, I know that school of thinking and I disagree. I can’t tell you why the filesystem is different than the database or the network, but it feels like it is somewhere between unit and system test, whereas I agree with the other points.

          I’m also not alone with this opinion or maybe it has been shaped by the people and teams I have worked with. Maybe it is because databases and network are kind of horrible to mock away and can be in any state of disrepair… but the filesystem can usually be persuaded to give you a file. Maybe it’s also moot fighting over the definition. I’ve just seen a lot of code bases that don’t even have anything but “unit tests” which turn out to be just that, plus file system access, but nothing with databases or networks.

    1. 19

      While I agree with the reasoning in the article and think the approach suggested makes sense, I also think it misses the wider picture and is only likely to result in small gains. The real issue with modern tech is not technical it is political, and there is not technical solution to this problem.

      The solution proposed here may get adopted and result in marginal gains if and only if some corporate executives decide it could make their company more profitable.

      The real issue with tech as I see it is the participation of for profit corporations. The goals of for profit corporations are not aligned with those of the human race in general, or individual humans in particular, unless those humans are shareholders. They put non-technical people in charge of development projects because those people have the capital everyone needs to get the job done. They prefer opaque proprietary protocols and interfaces because it enables them to entrap their users and gives them a chance to build monopolies. The create broken by design systems like DRM to protect profits. They turn a blind eye to bad behaviour like spam, clickbaiting, trolling and scamming whenever these are sources of profit for them. They hide their source from scrutiny which might otherwise discourage bad behaviour and discover security issues. They work programmers too hard for too long hours, while browbeating them and breaking their spirit until they no longer take pride in their work. Their focus is always short term. Worst of all, they discourage the population at large from understanding how their devices work, preferring instead to dumb all human interfaces down and make people dependant on ‘tech support’. Their interest is not in building a good base of software for enabling human beings to live full and happy lives with everyday technology, their goal is to siphon resources out of society and use it to grow out of control and ultimately take over everything. Like a malignant tumour.

      I know a lot of programmers don’t like talking about this aspect of things but I think it is important. It may seem off topic but if your read the three introductory paragraphs of the article again I think you will see that what I am talking about is probably a major factor in the problems the author is trying to solve.

      1. 24

        We see the same problems in open source projects, free software, and government tech. I bet if you peeked into Soviet software companies you’d see the same problems, too. Blaming capitalism is the lazy way out.

        1. 17

          This is too conflationary of a dismissal. Look again at the list of problems:

          • Non-technical leaders giving top-down orders
          • Building and publishing proprietary interfaces
          • Designing DRM
          • Giving reputation to bad actors as long as it is profitable
          • Building private code repositories and refusing to share knowledge
          • Forcing programmers to work long hours
          • Blocking right-to-repair and right-of-first-sale

          Your reply is that this also happens in the open-source world, which is a corporate bastardization of Free Software; and that it happened in the USSR, a time and place where a government pretended to be “communist” but still had shops, jobs, wages, and a wealthy upper class. Yes, I imagine that these capitalist and corporatist patterns are recurring in many contexts. No, it is wrong to lump them all together with Free Software.

          1. 17

            Looking at the list of problems:

            • Not in the article.
            • Not in the article.
            • Not in the article.
            • Not in the article.
            • Not in the article.
            • Arguable?
            • Not in the article.

            That’s why it’s the lazy way out. It doesn’t engage with the article at all. You just have to say “it’s capitalism’s fault” and watch the upvotes roll in.

            1. 12

              Just because anti-capitalist/corporate sentiment is popular doesn’t make it lazy or disingenuous. Putting the argument in a cultural/political context is a perfectly valid way of engaging with it. Pointing out that they come up with their own examples that are not in the article, as if that’s a bad thing, is a weird way to make a counterargument, given that the article is concerned with “ways we keep screwing up tech.” Giving corporations too much control over its direction seems like a pretty big way we’ve screwed up tech so far.

              1. 6

                Software development suffers during demand imbalance. In a market situation with fierce life or death competition, people work insane hours and abandon practice just to get things out the door. In markets where companies make money/survive no matter what they do, practice (and code) atrophy. No one cares. The latter case has effects that are remarkably similar among government projects, non-profits, and large institutions like banks and insurance companies with little competition.

                You can blame Capitalism, but the truth is people and projects need purpose and incentive; just not too much. There’s a sweet spot. It is like having a good exercise routine. Without it you atrophy; with too much, you destroy yourself.

                1. 2

                  I largely agree with that point. And I’d be naive to argue that capitalism alone is the cause of all problems in the tech industry, which is why I didn’t. At the same time, I think that capitalism, at least as it exists in the United States today, offers pretty bad incentives for teams and individuals most of the time. Professionals in the computing field have it better than most in that they have large monetary incentives. But above about $75K, as Kahneman and Deaton found, more income has little effect on one’s evaluation of own’s own life. Beyond that, you still have the problem that the interests of working people, including programmers, mostly don’t align with oligarchs’ interests. I’m not alone in the experience that even at a substantial salary, it’s pretty hard to feel incentivized to deliver value, ultimately, to those who own vastly more wealth. Not what I would call a sweet spot.

                  1. 5

                    It would probably be good for you to talk to programmers in Sweden (if you haven’t). Less capitalistic, much more socialist. A lot of big employers and relatively fewer startups. They have problems too. And that’s the thing. All systems have problems. It’s just a matter of tradeoffs. It’s nice that there’s enough diversity in the world to be able to see them.

              2. 8

                (You should know that I wrote and deleted about seven paragraphs while attempting to engage with the article seriously, including this one.)

                Let’s take the article’s concluding suggestion seriously; let’s have a top-ten list of ways that “the technology industry” is “screwing up creating tech”. I would put at number one, at the very top: The technology industry’s primary mode of software creation is providing services for profit, and this damages the entire ecosystem. What ten behaviors would you put above this one? The only two contenders I can think of are closely related: Building patent pools and using work-for-hire provisions to take copyrights from employees.

                It’s not capitalism’s fault that self-described “experts” are having trouble giving useful advice.

                1. 3

                  Is there an “industry” that doesn’t exist for profit?

                  I think needless churn, overcomplication, harmful treatment of developers, harmful treatment of users, and wasteful use of energy are all ways the industry screws up tech…but then again, so too does libre software!

                  And unlike industry, there isn’t even an evolutionary pressure you can hijack to keep it honest.

                  1. 3

                    Beavers do not terraform for profit. The bulk of free culture is not profit-driven either.

                    Note carefully that you substituted the original list of seven problems which are all created by profit-seeking behavior with your own list of five issues which are not. Yours are also relatively vague to the point of equivocation. I’ll give a couple examples to illustrate what I mean.

                    For example, where you say “harmful treatment of users”, I said “giving reputation to bad actors as long as it is profitable” and the original comment said “spam, clickbaiting, trolling and scamming”; and I do not know of examples in the FLOSS world which are comparable to for-profit spamming or other basic fraud, to say nothing of electoral interference or genocide, although I’m open to learning about atrocities committed in the furtherance of Free Software.

                    For another example, where you say “harmful treatment of developers”, I said “forcing programmers to work long hours” and they said “[for-profit corporations] work programmers too hard for too long hours, while browbeating them and breaking their spirit until they no longer take pride in their work”; you have removed the employer-employee relationship which was the direct cause of the harmful treatment. After all, without such a relationship, there is no force in the Free Software world which compels labor from people. I’ll admit that it’s possible to be yelled at by Linus, but the only time that happened to me was when I was part of a team that was performing a corporation-led restructuring of a kernel subsystem in order to appease a still-unknown client.

                    1. 5

                      You asked for a top-ten list, I gave five; don’t bait-and-switch.

                      Each of those examples I gave can and does happen under both a for-profit model and under a libre-hippy-doing-it-for-free model.

                2. 7

                  Not in the article.

                  “But once I started working with teams-of-teams, process, and changing large groups of people, things did not work the way I expected.” “I found myself repeating the same things over and over again and getting the same substandard results.” “ came to realize that these were honest efforts to get more traction.” “I got worse at learning new stuff” “tired of watching my friends repeating the same things over and over again, snatching at this or that new shiny in an effort to stay relevant”

                  It is fine that you disagree with my interpretation of how the article describes the problem. Maybe I completely misunderstood what the author was referring to. Perhaps you could enlighten me and provide the correct interpretation. I look forward to your response.

              3. 9

                Solely blaming capitalism certainly won’t address all problems with software development, but I do think there’s a case to be made that the profit motive is just as good a tool for producing pathological states as innovation. DRM is a prime example.

                1. 12

                  The original post had nothing to with DRM, putting nontechnical people in charge, hiding source code, working long hours, or dumbed down human interfaces. Dunkhan didn’t engage at all with the actual article, he just said it was all because of “for profit corporations” and listed unrelated claims.

                  You could argue that profit motive is a good tool for producing pathological states; he didn’t.

                2. 7

                  I mean, open source in the large is dominated by corporate interests, so this isn’t much of a gotcha. Just ignoring capitalism as a fundamental factor seems like the significantly lazier option.

                  1. 11

                    I never blamed capitalism. Adam Smith, and most respected capitalist economists that followed have all said that monopoly formation is to be avoided at all costs and if not correctly controlled will completely undermine any benefits of a capitalist system. If you go through the behaviour I called out, almost every example is either the result of, or an effort to achieve a monopoly. It would be more accurate to say I am defending capitalism against those corporations who are ruining it. If you want an -ism that I am blaming, I think the closest analogy to what they are doing is some kind of feudalism. Lets call it corporate neofeudalism.

                    The main tool we have for combating this behaviour also comes directly from the same canon of capitalist thinkers. Namely, antitrust laws. All we need to do is expand them, make them harsher, and then ruthlessly enforce them. There is no need for new and creative solutions to this problem, it is an old problem and has been solved already.

                    1. 4

                      IMO when somebody says “the problems with software are that it’s being done for profit” there’s no need to talk with them about software any more. They’re not interested in fixing software, and if that’s all you feel like talking about right here and right now there’s no useful outcome in engaging with them.

                      1. 1

                        No one said that.

                        If you want to put words in other people’s mouths and then dismiss their opinions based on those words go right ahead, but it does not reflect well on you. The fact that you see any attack on corporations as an attack on profit making of all kinds also concerns me a great deal. Did you take the Citizens United ruling so seriously that you really believe corporations are people, or are you just getting paid to defend their interests on the web?

                  1. 3

                    I think the best way to understand DI is: historically.

                    DI never occurred to people using C++ or Smalltalk, or even early Java. It only surfaced with the advent of Enterprise Java Beans (EJB) as a way to allow 1) separation between business logic and framework code in a “container” and, 2) testability independent of the framework. It was a way to facilitate the creation of POJOs (plain old Java classes) in the middle of framework hell.

                    It still can be useful, but it can be overused. I tend to favor just adding special purpose constructors for testing in an OO context if there isn’t already a DI framework in place.

                    1. 4

                      DI never occurred to people using C++ or Smalltalk, or even early Java.

                      oh, I really disagree. I’ve taught C++ classes in uni and saw students come up with the concept pretty much on their own.

                      1. 2

                        Agreed, many (most?) applications not using DI as an intentional “pattern” are going to implement some subset of it just to maintain separation of concerns. Using Spring is just acknowledging this upfront, knowing that you’ll have all the tools you need to let your modules consume each other.

                        1. 1

                          Prior to EJB?

                          1. 1

                            The students I’m talking about had been exposed to programming overall for less than two years, and certainly not to enterprise java beans, only C, LISP, a hint of C++ and raw Java, and algorithms

                      1. 1

                        That is what Unison is, essentially: https://www.unisonweb.org/

                        1. 7

                          I wonder whether we should give up nested folders and just move to tagging.

                          1. 6

                            I tried this for a while and it suffers the same problem as nested folders: you still have to tag/categorize everything.

                            1. 6

                              For things that have no better location, I use a system of weekly folder rotation which works out pretty well since everything current is there and you don’t need to check a lot in the older folders usually.

                              Everything that has a better location (e.g. because it’s part of a project) gets moved to that then.

                              1. 1

                                Yeah, it just seems like it is more flexible. Yes, tagging can be a pain and there is no notion of one categorization being a sub of another. That part is not easily discoverable. Those are two downsides.

                                1. 2

                                  I do think tagging is better, by the way. When I tried it, though, I found I was very inconsistent with what tags I was using so finding that “thing that was like some other thing” was not as great as was made out to be.

                              2. 3

                                A path is just a list of tags, especially if you have a super fast search engine like Everything.

                                I place my files in nested folders, but I don’t navigate them. I open Everything, type parts of the path, and it’s in the top 3 of “Date accessed” 99% of the time. Takes one second.

                              1. 5

                                It would be great to see Dropbox and Google Drive data on percentage of users who actually create subfolders. My guess is < 5%

                                1. 1

                                  Since struct and class are so similar, I choose to consider class to be the keyword in excess, simply because struct exists in C and not class, and that it is the process of the keyword class that brought them both so close.

                                  This is an interesting perspective on the history. I would consider struct to be the keyword worth removing, since that would change the default access qualifiers to be safer.

                                  1. 5

                                    I may be misremembering but I am reasonably sure that backwards compatibility with C was one of the early design goals of C++. Removing struct would quickly break compatibility. That is, presumably, why the default access qualifier is different from class‘s (and identical to C’s struct).

                                    1. 1

                                      It’s always irked me that this C compatibility was only one-way because of support for member functions (at least).

                                    2. 3

                                      Removing struct would create a lot more C code that is not C++, and making the default “safer” doesn’t improve things since, as noted, it’s standard practice to be explicit with access qualifiers.

                                      1. 4

                                        Yeah, I don’t think that can be understated. This would destroy one of the biggest reasons C++ was successful, and one of its main advantages to this day. It would even make most C headers not C++ compatible, which would be an absolute catastrophe. Even if the committee did something so egregious, no compiler could or would ever implement it (beyond perhaps a performative warning).

                                        I think the real mistake is that the keywords are redundant at all. We’ve ended up with this near-universal convention that struct is for bags of data (ideally POD or at least POD-ish) because that’s a genuinely useful and important distinction. Since C++ somehow ended up with the useless “class except public by default” definition, we all simply pretend that it has a useful (if slightly fuzzy) one.

                                        1. 1

                                          Because of its incremental design and the desire to make classes seem like builtin types, C++ has a Moiré pattern-like feel. A lot of constructs that are exceedingly close, yet different.

                                    1. 3

                                      I suggested the tag historical. Can someone second that?

                                      1. 2

                                        I’m glad the tag was added given it is a very old argument. Nonetheless, I read the article hoping that it would be something novel like repurposing the concept keyword.

                                      1. 15

                                        This uses a specific definition of fragility related to portability and availability of of environmental requirements. Which is interesting. I would be more interested though in an examination of the fragility of a codebase broken down by language.

                                        • How frequently will an upgrade of the interpreter/compiler/stdlib break you.
                                        • How quickly will the language ecosystem change enough to break you.
                                        1. 11

                                          Some of their assessment is pretty questionable too. For example, they object to C because it depends on libc, but that’s a part of the OS install (or bare-metal environment) - you might as well object to something depending on the kernel (and then you’re left with a much smaller list of ones that can run in a freestanding environment). To give a concrete example, Go doesn’t depend on libc and so every Go program broke a couple of years back because Apple changed the arguments to the gettimeofday system call. Everything calling it via the public interface in libSystem.dylib kept working because it was updated for the new system call ABI, everything calling it via the private syscall interface broke. XNU, Windows, and Solaris all provide public C APIs but not a public syscall interface and periodically move things from the kernel to userspace libraries or vice versa.

                                          Similarly, they object to clang and gcc because they depend on a package manager or installer to install (because apparently untaring a tarball is something you can’t do in their future world), but not to go, which depends on being able to connect to remote git repos to grab dependencies for pretty much everything and which also ships as multiple binaries and support files to provide a working toolchain.

                                          1. 2

                                            That would be interesting. I wonder how similar the lists would be.

                                            1. 1

                                              Really, it’s a modularity problem.

                                            1. 1

                                              It’s interesting to see this as a modularity failure.

                                              1. 1

                                                Bounced after the second time the page stole my focus away from the text. I barely got past reading the title.

                                                1. 3
                                                  1. 1

                                                    Indeed, there are a couple of annoying pop-ups - but the content was interesting IMNHO.

                                                  1. 4

                                                    Services are objects wanted to be.

                                                    1. 13

                                                      The article doesn’t seem to appreciate that fork is exit.

                                                      1. 11

                                                        Fork is exiting but bringing a copy with you.

                                                        Imagine leaving the store and walking into an identical store but now the walls are blue.

                                                        1. 6

                                                          Soon you find that the blue coat of paint cost a pretty penny; and that you now have to pay your new shop’s rent, as well as hiring staff to run & maintain it.

                                                          For a hobbyist it’s less of a risk; but for a business maintaining a fork of a significant piece of software can become an albatross around your neck, or can result in a significant business opportunity—or anything in between. Thus I’d caution against rash forking: evaluate carefully whether it’s worth it in your case.

                                                          1. 11

                                                            Then you always have an option to exit, same as before, with only moderate-to-low sunk cost.

                                                        2. 5

                                                          Not necessarily.

                                                          It’s also a way of formulating voice into a coherent and proven valid response.

                                                          A “Pull Request” is a “voice” asking the original developers to “to hear” a fully fleshed out and proven valid suggestion.

                                                          They may choose to take it as is where is, or tweak, or ask it to be reformulated, or reject.

                                                          Once rejected, the fork may choose to exit, or partially exit.

                                                          1. 3

                                                            Is Debian exiting Linux since they have their own fork of it? I don’t think so.

                                                            1. 2

                                                              There are many levels of exit so we can argue endlessly about what is and isn’t exit and all be right within a particular frame. A person leaves the living room of a house and goes to their own room where they have control within parameters. This is the same as the Exit, Voice, and Loyalty case of someone leaving an organization. Outside, they have control within parameters - usually set by the government they are under the jurisdiction of. For Debian, the control factor is their users and their choice to follow Linux. They can change their mind about all of those things without asking permission of the repo they forked from.

                                                              So, yes, it’s all a matter of how you frame exit. FWIW, it’s a big question in political science whether exit exists at all, but I think that it is obvious that it does as long as one isn’t binary about it. It exists in degrees and at particular levels.

                                                          1. 3

                                                            The biggest issue with a lot of software engineering research that I encounter is that it is unsurprising. It is information that practitioners can acquire talking to a wide range of other practitioners or via first-principles thinking.

                                                            The recurring pattern seems to be that organizations seeking better ways of working try things out and gain some advantage. Others hear about their success and attempt the same thing. The ones that don’t (laggards), often wait for confirmation from various source of practice authority (academia in this case) before trying something that appears risky to them.

                                                            Since the primary learning loop happens through market experimentation, this leaves research the task of putting a stamp of approval on what is often common knowledge in some pockets of practice, leading to wider adoption. Or, more rarely, showing that some common knowledge may not work in particular circumstances, and that is more of a negative agenda. Practice discovery (positive agenda) will always be easier in industry.

                                                            This makes academic software engineering research very hard and, maybe, demoralizing for those who do it. It’s relatively easy to show that some things don’t work in particular circumstances, but the range of circumstances is huge and every company / open source project has incentive to discover niche places where a particular method, tool or practice provides value.

                                                            1. 6

                                                              Why use C as a target at all? The code output is unreadable and useless. It’s also subject to interpretation by the various compilers.

                                                              LLVM IR seems a better idea.

                                                              1. 5

                                                                Worse, it invites edits that could invalidate the proofs.

                                                                1. 1

                                                                  It’s also subject to interpretation by the various compilers.

                                                                  This seems like a misconception. If your C output follows the C standard, it is not open for interpretation, if compilers don’t follow the standards, then it is a bug.

                                                                1. 13

                                                                  It seems like C++ is the only language where the advice has always been “don’t use the basic language features.” One could argue that the same is true of Javascript but for Javascript it is more like “here are things to be careful about with the basic features.”

                                                                  1. 2

                                                                    I like Ruby on this:

                                                                    “aaaabbbcca”.chars.slice_when {|c,n| c != n }.map {|s| [s[0], s.size] }

                                                                    1. 15

                                                                      Bitcoin makes a lot more sense when you see it as performance art.

                                                                      1. 29

                                                                        I think we are (slowly) fixing such problems in newer languages. The mindset changes from “if your program crashed you’re a bad programmer and you should feel bad” to “it’s the programming language’s fault that it hasn’t caught your bug”.

                                                                        For example, look at this fork wrapper:

                                                                        fn fork() -> Result<Fork, i32>
                                                                        

                                                                        You’ll get a warning if you ignore the return value, and a compile error if you try to use as a pid without handling the error somehow. Even if you want to handle the error by aborting the program, you still have to write that explicitly. And the Fork type is an enum Parent | Child(pid), so you have to match on it, and you can’t just run with let pid = fork().

                                                                        1. 6

                                                                          While I completely agree newer languages help here (specifically those with algebraic datatypes), it isn’t an end-all solution. In Rust, I’ve seen many people just bubble up errors like this with ? and it ends up acting like an exception (especially with libraries that automatically convert all errors into a universal type). This is 100x better than just failing with segfault, but it still doesn’t actually handle the problem.

                                                                          It really is just a cultural issue. So many developers believe solving the problem is just handling the happy path, when true engineering is when you handle both the happy path and the failure path. There is only so much a language can actually do here. If a developer believes “good” code looks only like the clean happy-path code then they are doomed to write terrible code.

                                                                          1. 12

                                                                            still doesn’t actually handle the problem

                                                                            Depending on the kind of program, just aborting is a perfectly valid way to handle an error, especially a “fork failed” kind of error — essentially the “your OS environment is kinda screwed up” condition.

                                                                            You definitely don’t want that in your spacecraft navigation controller (but that ideally shouldn’t have any dynamically-allocated resources at all), you would prefer to avoid it in a document editor with unsaved state (although users of those are conditioned to Ctrl-S early, Ctrl-S often), but who cares if a media player or system info monitor just gives up when your system is out of resources.

                                                                            The key problem with the old school C error handling is that a quick segfault in the right place is the good outcome. lldb -c program.core program, bt, “oh I see lol”. The far more insidious issue is that the program can go on as if nothing bad happened and start doing wildly incorrect things, and the article’s example of sending a signal to the -1 “pid” returned by the failed fork call is a perfect example.

                                                                            1. 2

                                                                              True, arguably for most applications simply failing with a relevant error message is appropriate. I think taking the article’s argument in general, and not specific to fork or segfaulting, properly handling errors is not something that is taught or even well regarded.

                                                                              1. 2

                                                                                This is the crux of the problem, IMO. That different applications need to handle errors differently AND that different kinds of errors within the same application need to be handled differently.

                                                                                That’s why, IMO, a general purpose language needs at least three failure mechanisms: one for “you used the API incorrectly or fed invalid data”, one for “something unexpected happened- let’s message the user and see what they want to do”, and one for “holy shit! There’s no way this will work any more. Just quit”.

                                                                                Rust is pretty damn close to right, IMO. My only complaint is that Rust (the std and some of the ecosystem) is still too eager to publish panicking APIs without at least offering a non-panicking version. In general, I rather have the non-panicking version than the panicking version because I can choose to panic on receiving the failure response. It’s harder to “unpanic” if you even realize that a panic might happen.

                                                                                Swift is kinda-sorta there. It has throws and it has Result. But it seems that nobody actually uses Result as a return value.

                                                                                Even in Java you were “supposed” to use checked exceptions for expected failure modes and unchecked for the cases where you need to just bubble all the way up or just crash.

                                                                                I’m super disappointed that Kotlin, for as ergonomic and awesome as the language is, reverted to just using unchecked exceptions for everything. That’s such a crappy way to do error handling/signalling.

                                                                            2. 3

                                                                              I want to add to your point. The kernel API matters too; the Linux fork syscall still takes a pid_t, which is a numeric type that indicates something like Parent | Child(u32 pid) | Error(u32 errno) when combined with C’s errno global error information. Programming language runtimes can only paper over the issue, as when this particular functionality is shaped like CreateProcess and doesn’t allow the fork/exec split.

                                                                              The very nature of fork is that parent processes are invited to confuse themselves as to who they are and with which privileges they are running. All a programming language can do in this situation is delay implementing the raw syscall at user level, and try to write enough tamed wrappers to keep up with demand.

                                                                              1. 4

                                                                                And this in turn is probably has a lot to do with the fact that the linux kernel is written in C (and thus suffers from C’s primitive type system), and POSIX dates back to a time when C and languages with similar type semantics to C were the only game in town when it came to writing an OS. If I was writing an OS from scatch today, I would do so in a language that did let me define the return type of the fork syscall with a sensible algebraic type. But that’s not C.

                                                                              2. 2

                                                                                It’s worth looking at how Erlang handles it too.

                                                                                1. 2

                                                                                  In case you’re referring to fork specifically: I don’t think there’s any way to reasonably use fork in the Erlang VM. Generally multi-threaded VM runtimes don’t give you any API for fork, and if you just use FFI to call it from your program, prepare for unforeseen consequences.

                                                                                  If this is about error handling in general: both exceptions and pattern matching, but of course dynamic pattern matching since it’s dynamically typed. i.e. there’s no Either type, just tuple conventions like {ok, <your result>} vs {error, <your error>} (where ok and error are atoms). And of course you can use try to turn exceptions into tuples to match, and match and throw to do the opposite.

                                                                                  1. 2

                                                                                    I wasn’t going specific on fork but, rather, what it enables. In Erlang you spawn processes. As far as I can tell, you are guaranteed to get a valid pid from spawn and there is a good story about what happens you use a pid for a destroyed process. It’s a case where a differently designed mechanism makes a class of errors impossible.

                                                                              1. 21

                                                                                This could be one of those hard cases that I talked about recently. This is mostly critiquing his programming, but then there’s notes about his business work that he’s now more famous for, and the business stuff is off-topic here. I’m not removing this because it’s mostly programming. Please help maintain the topicality of the site by not diving into his business and politics. (And reminder: anyone is welcome to help work through the above cases to figure out where to draw the line and how to express it. Those comments I just linked are my current thinking as I slowly work towards getting more of this more explicitly into /about.)

                                                                                1. 30

                                                                                  I enjoy bashing PG and startupcanistan as much as anyone, but this critique was heavy on “PG is an ossified hasbeen reactionary” and light on good critiques of Arc.

                                                                                  An article about why Arc has deficiencies and what we can learn from it is one thing; character attacks in the guise of technical critique are another.

                                                                                  I am as sure the real damages and harm PG has done are nontechnical as I am sure this is offtopic.

                                                                                  1. 24

                                                                                    More succinctly: we wouldn’t celebrate an article attacking Larry Wall or Richatd Stallman instead of Perl or Emacs.

                                                                                    0r at least, I would hope we wouldn’t.

                                                                                    1. 10

                                                                                      I don’t have as much faith in the ability of the lobsters commentariat (and moderation team) to fairly judge what content is too political to be on-topic as you do. I would say that merely using the word “reactionary” in a pejorative way makes this article far more political than, say, anything I’ve ever posted here about Urbit that was flagged as off topic or trolling.

                                                                                      1. 3

                                                                                        Just to note that the bar for discussing an article here shouldn’t be that it’s worthy of celebration. What’s being discussed is whether this is on-topic at all.

                                                                                        1. 9

                                                                                          Consider the case of an article about, I don’t know, old IBM punchcards. Perfectly good information. Additionally, the author goes into Holocaust ramblings. How much other stuff are you willing to put up with?

                                                                                          The exploit being used in this article is “mix nontechnical political content, e.g. character assasination, in with sufficient technical content, e.g. language design”.

                                                                                          The article itself could’ve been written purely as a critique of Arc, with a passing reference to its designer, but that clearly isn’t why it was written.

                                                                                          1. 8

                                                                                            This isn’t even close to character assassination. It gives due praise but delves into a serious critique of character or maybe more accurately of method and intent. That was the point of the article. The technical content isn’t an excuse for the political content, it’s an illustrative example. The fact that the article isn’t a good fit for Lobsters shouldn’t matter to the author one bit.

                                                                                            1. 9

                                                                                              It gives due praise but delves into a serious critique of character or maybe more accurately of method and intent. That was the point of the article. The technical content isn’t an excuse for the political content, it’s an illustrative example.

                                                                                              Thank you for making my point!

                                                                                              Lobsters isn’t a site for character critiques and other drama gussied up with supporting technical details.

                                                                                              1. 6

                                                                                                Well, in theory a lot of people take technical advice from his essays on programming languages, language design, etc. If someone believes that’s a bad idea, it is 100% fair game and technical content to make that argument. Not long ago there was a piece that critiqued taking technical advice from Bob Martin by pointing out problems with Clean Code, for example.

                                                                                        2. 1

                                                                                          More succinctly: (make-my-point)

                                                                                        3. 6

                                                                                          I disagree, it is fairly technical and on point with Arc.

                                                                                          Speaking as someone who actually wrote a program in Arc when it was released.

                                                                                        4. 24

                                                                                          Is this a reasonable summary of the article?

                                                                                          • PG’s writing has taken a reactionary turn
                                                                                          • Brevity in language design is a flawed and unrigorous notion. He’s using his intuition, which has not held up to reality
                                                                                          • This is evidence that he uses his intuition everywhere; his opinions about politics shouldn’t be taken seriously.

                                                                                          It’s a fair enough set of observations, although I’m not sure the argument is air tight. It’s also a very roundabout way of refuting political arguments… I’d rather just read a direct refutation of the politics (on a different site)

                                                                                          1. 16

                                                                                            Yes, the politics mentioned in the introduction felt out of place. The rest of the article was well-written and dispassionately argued, but I couldn’t help feeling the whole piece was motivated by political disagreements with Graham (epitomized by the coinbase tweet), and that diminished its impact for me.

                                                                                            1. 8

                                                                                              I don’t think it’s as clear as it could be, but I read the article as starting from the assumption that Graham’s recent political and social writing is poor, and then asking whether the earlier more technical writing is similarly flawed.

                                                                                              If the argument went the way you said, it would be pretty bad. This is why I think talking about logical fallacies is less valuable than many people think. It’s usually pretty easy to tell if a precisely stated argument is fallacious. What’s harder is reconstructing arguments in the wild and making them precise.

                                                                                              1. 13

                                                                                                Yeah, if you want PG criticism, just go straight for Dabblers and Blowhards. It’s funny and honest about what it’s doing.

                                                                                                https://idlewords.com/2005/04/dabblers_and_blowhards.htm

                                                                                                This article spends a lot of words saying something that could be said a lot more directly. I’m not really a fan of the faux somber/thoughtful tones.

                                                                                                (FWIW I think PG’s latest articles have huge holes, with an effect that’s possibly indistinguishable of that of willfully creating confusion. But it’s also good to apply the principle of charity, and avoid personal attacks.)

                                                                                              2. 5

                                                                                                You’ve removed an implication that libraries matter as much as the base language, some negative remarks on Paul Graham’s work as a language designer, and some positive remarks on Paul Graham’s overall effectiveness as a developer, technical writer, and marketer.

                                                                                                But yes, the article seems fairly well summarized by its “This is all to say that Paul Graham is an effective marketer and practitioner, but a profoundly unserious public intellectual (…)”.

                                                                                              3. 12

                                                                                                I’m not removing this because it’s mostly programming.

                                                                                                The programming that is mentioned is there to make a case against a person and extend it to a broader point about people. I would’ve made the call the other way.

                                                                                                1. 17

                                                                                                  There’s a lot of interesting insight here into how to do language design (and how not to do it). I’m glad it stayed up.

                                                                                                2. 8

                                                                                                  This is is a tricky one, yeah. It feels like there’s really three things going on in this article:

                                                                                                  • The writer is bashing Paul Graham
                                                                                                  • The writer is making it about Paul Graham’s political/social writings
                                                                                                  • The writer is supporting those by talking about Paul Graham’s history in the technology field

                                                                                                  When looked at that way, I’d lean slightly towards it being offtopic. If one wanted to write something about the design of Arc and the history and origin of design mistakes and the personality of the person that resulted in those mistakes, one could re-use the same arguments in this article and do so. I think one would come up with a very different article if so. So it’s not about the tech or the intersection of humanity and their artifacts, it’s about Paul Graham and their opinions.

                                                                                                  1. 6

                                                                                                    I’m glad this article about PG made it to lobsters, otherwise I wouldn’t have seen it. I’ve had a similar journey with PG’s writings as the author, going so far as to purchase Hackers and Painters when I was younger and thought programming made me special. I enjoyed learning a bit more about arc than I would have had this article been moderated off the site.

                                                                                                    1. 5

                                                                                                      Thanks for your hard work @pushcx! Moderation of topics is what makes lobsters great!

                                                                                                      1. 4

                                                                                                        My impression on this meta-topic of to what extent lobste.rs should have posts that touch to some extent on non-technical questions: We’ve arrived at a point where there’s a group of readers who will indiscriminately flag anything off-topic that falls into this category, and another group of readers who will indiscriminately upvote anything of this category that makes it through.

                                                                                                        I’d suggest that it might be better for the health of the community to be a bit more permissive in terms of what political/social/cultural tech-adjacent stories are allowed, and to rather aim to let those that don’t want to see those posts here filter them using the tagging system. (But I’m sure that’s been suggested before.)