1. 35
  1. 6

    Interesting that the author references Wirth, specifically Oberon, in the context of the article. Oberon is at once a language and the whole system that runs that language. It comes from a line of thinking about computing environments holistically, and having a given environment itself be as simple and powerful as possible. The problem with any particular “programming language” today – including Go – is that no matter how simple it is or what nice design features it contains, it will always be hamstrung by the environment du jour upon which it runs. In our case (let’s face it) that’s the world of Unix and its descendants.

    1. 7

      Interesting observation, however, it is also interesting that the people who made Go have a lot of experience with “building universes”, specifically Unix itself and Plan 9. While Go definitely had to conform to Unix’s auspices, it still kind of feels like its own separate universe in a way that’s difficult to convey. A programming language is not an operating system, but for someone who used Plan 9 the connection is immediately obvious, and this has to do with the kinds of abstractions it provides, and not with the implementation.

      1. 2

        True, true. Plus Go was designed for use in the real world, not necessarily a “better” world. I still think some of the abstractions languages like Go use come about by the limitations of the most common environments in which they have to operate, however. This leads to novel and good ideas, to be sure (channels, for example). I have indeed read elsewhere that Go is a kind of effort to bring Plan 9-ness to the current Unixy world. Oh, the things we could do if we were not encumbered by software requirements and backward compatibility…

        A programming language is not an operating system

        Very true in the popular sense, and also (to my mind) regrettable.

      2. 5

        Rob Pike very obviously loves Wirth’s work.

        Acme and Help are earlier Pike projects that are attempts to get the Oberon system feel on top of Unix. You might enjoy playing around with those if you haven’t already.

        Go itself is pretty much Oberon-2 with Alef-style coroutines (Oberon-2 wasn’t directly from Wirth, he kept going with plain Oberon, but the influences are obviously there).

        There’s also the BlackBox Component Builder, which is unrelated to Go but is an Oberon-system-style operating-system-in-an-app built around Component Pascal, a derivative of Oberon-2. AFAIK it’s Windows-only, sadly.

        1. 2

          Nitpick, acme was designed for Plan 9, not unix. It was ported to unix only later. I use acme on unix, and I miss Plan 9 dearly.

          1. 1

            True. My bad. Help was Unix, though (right? I think so), which is where my mind was in I wrote that.

            1. 2

              Still Plan 9, might have been one of the first “true” Plan 9 programs (in the sense that it wasn’t a port from unix and it based based on filesystems).

              Btw, another interesting family of editors is the one in Plan B/Octopus by Francisco J. Ballesteros: https://lsub.org. I swear there were a few videos available, but I can’t find them anymore.

              1. 1

                Well damn I brain-farted hard then. My bad.

                And yeah, I remember seeing videos on Plan B as well. Then again, I think we’ve just established my memory isn’t working today.

      3. 4

        Was two weeks really a common turnaround time for compiling and executing a FORTRAN program at an institution in the 70’s? Sounds like the result of a long queue ahead of you. I would have imagined overnight turnaround if there were no big jobs being done.

        1. 3

          Between this and the recent Software Crisis 2.0 thread, I’m starting to think the “software crisis” framing is counter-productive. Its metric of choice is “percentage of projects that fail”, but the very notion of “project” feels burdensome to me in the 21st century. It’s been hard to find good definitions, but in these discourses the term seems to have the following properties:

          • Fixed start and end time
          • Externally defined requirements

          Neither has been true of the well run tech organizations I’ve been in, where programmers are above all maintaining the factory that does the work while we sleep, and where we have a strong say in what to build.

          Which isn’t to say there’s no crisis. These days the part of the elephant I start with is the need for intermediation and delegation. Why is there a divide between the person in need of automation and the “programmer” creating said automation, and how can we help people help themselves. A lot of what ails software seems due to misaligned incentives, and I think the problem gets much more tractable if you fix the incentives first.

          1. 3

            Why is there a divide between the person in need of automation and the “programmer” creating said automation,

            Because “real programmers” don’t like being put out of business by users just using Excel, Access, and FrontPage.

            1. 4

              Having done a few rescue projects for those who have outgrown their homegrown solution - I’m confident that there’s more paid work in giving them enough rope to get into trouble.

              It turns out that using those (great) tools doesn’t free you from caring about change management, testing, communicating with others who might contribute, etc - and people who have developed those skills are usually able (and prefer) to use higher-level abstractions.

              1. 2

                My favourite (and last!) .NET gig was to help a company build a .NET development capability in-house, so they could evolve their software solution built in VBA and Excel.

                Far from getting themselves in trouble, they’d used that VBA + Excel solution to grow their business profitably to the order of 100 staff internationally. They weren’t in trouble, but they had hit the practical limits of their solution in terms of additional functionality (especially Web), and scale.

                Most of their VBA code had been written by one of the company co-founders, who was himself an expert in their vertical, but not at all a programmer by trade.

                I’m fairly certain that they’d never have been able to bootstrap their business in the way they did by starting with a ‘bells and whistles’ software development team, or with software that didn’t happen to already be running on all their machines.

            2. 3

              Why is there a divide between the person in need of automation and the “programmer” creating said automation, and how can we help people help themselves.

              Because automation is fucking hard and it helps to have someone experienced fix it before you make a mess of it. It will stay hard. Forever. Not because of tooling, not because of developer productivity, but simply because the world is hard.

              Of course it is good to let people help themselves if that is possible. But this will always require some investment from those people. We all have limited amount of time and energy, so for a lot of problems and situations, getting an automation expert is simply the best option.

              1. 1

                Totally agreed! Automation is fucking hard, as you so eloquently put it. This is why I said “more tractable” and not “solved”.

                Our choice is between making a mess of it ourselves… or giving it to someone else who will also make a mess of it as well, either by accidentally creating security holes or by giving us software that we make vulnerable by failing to patch on time or by pivoting to a new market/strategy and causing us grief by increasingly user-hostile actions.

                It’s not clear to me that one is better than the other, outside of say cryptographic libraries. Even if you think you’re ahead right now, your exposure is still high over the long term. Particularly when you take epidemiological effects into account. In our connected world, other people’s irresponsibility with software has a great capacity to hurt us.

                A third way is to stop using so much software. That’s my preferred approach to the crisis. Software has eaten the world way too fast. You don’t have to let it eat you. Which isn’t to say you have to quit cold-turkey. There is value in being eaten slower than the next person.

                For people who have limited time and some money to spend, a fourth way is:

                • Create personal relationships with programmers. If everyone did this, it would result in a higher programmer/user ratio, which moves the needle in the right direction. It would also prevent power law effects which cause the greatest user abuse from the Googles of the world. Relationships work best when they’re between approximate equals.
                • Weight the antifragility of new and bespoke stacks against the “efficiency” of getting pwned, ransomed and data-breached at the same time as everyone else.
                1. 2

                  A third way is to stop using so much software. That’s my preferred approach to the crisis. Software has eaten the world way too fast. You don’t have to let it eat you. Which isn’t to say you have to quit cold-turkey. There is value in being eaten slower than the next person.

                  I agree with this. It is my preferred option too. If I have to explain it to others, I refer to it as digital minimalism or digital frugality. In my mind, I draw comparisons with vegetarians/vegans, who also constrain their options because they think they and/or the world will be better off that way.

                  But, as slow my personal transition may go, I feel the gap getting wider and wider. I feel like a vegetarian in the 70s. People sort of understand what you are talking about on a rational level, but it is already way too far from their personal experience to relate. It would cause them a disproportionate amount of discomfort to start moving in the same direction for the benefit they perceive it will give. Society is not yet able to handle those minimal people, so even the simplest things are very hard.

                  Somewhere on my todo list is the item of starting a blog to show and explain how this minimalism works for me and how it might work for others. I first have to finish my todo app though.

              2. 2

                Why is there a divide between the person in need of automation and the “programmer” creating said automation

                Because that’s where a lot of money is extracted.

                Say you’re Apple or Google, and your users have a problem.

                Which gets you more money? Those users solving their own problem with a general purpose programming environment targeted at laypeople[1], or those users buying a single purpose app to solve it and paying you a cut?

                [1] I still think the combination of VBA + Excel is the greatest example of this that we’ve yet produced.

                1. 1

                  You’re absolutely right. It was a rhetorical question, hence the absence of the question mark.

                  The only way to keep one set of entities from doing what’s in their interest is for their opponents to push back. There’s a growing sense of just how much people have given up by letting a tiny slice of society write all the software for all of society. But I think this needs to bubble up a lot more before it will constrain Google or Apple’s behavior. In the form of more people taking an interest in hyperlocal, situated software. Which is hard to do, because the software we use to build software isn’t really intended for that use case. Because the software we use to build software was written by commercial entities for commercial “requirements”, all the way back to the dawn of computing.

              3. 2

                Go is so far away from Smalltalk. And … wow … our community has even forgot the Pascal vs. C wars.

                1. 3

                  our community has even forgot the Pascal vs. C wars.

                  We really need comp sci students to be taught the ‘modern’ history of the industry.

                  1. 2

                    Go is so far away from Smalltalk

                    Yeah a friend even commented that he mentions the superiority of interactive programming (Smalltalk, Interlisp) at the beginning and then ends up at Go. Not the most interactive contemporary choice.