If you're interested in trying out BCPL on your own machine the inventor of the language, Martin Richards, maintains a working environment/compiler[0]. I've gotten it up and running on both Ubuntu and OS X. The readme is structured in a way that makes it kinda hard to follow so I wrote down some instructions[1] for my future self after I figured it out.
C was my first programming language and several years ago I became acquainted with ALGOL 68. I'd never seen BCPL before a few months ago. It's rather interesting how, from the perspective of someone born well after its creation, it is very clearly the link between the ALGOL family and C. I'm sure that's rather obvious to programmers who were around in the mid to late 60's but for me personally it was a lot like discovering a missing link.
The image below shows the Hello World program with multiple fonts and centering applied. Since the compiler ignores any formatting, the program runs as before."
Good question! I'd also add the questions Why are we still programming with the semantics of 80-column punched cards? Why are programs even structured as sequential lines?
The lines within a method need to be ordered, but beyond that, code should just float to where it's convenient and be hypertext-y. And worrying about whitespace and fitting code on a fixed-length line is pointless.
I don't have the answers to how programs should be written, but the current system just seems wrong, locked into decisions made decades ago. It seems like programming is stuck at a local maximum.
There's been articles posted to HN that have attempted to explain why textual source code has become the norm, but from what I remember it comes down to simplicity (and with it, efficiency of storage and processing) and portability. It's the same reason why files as plain sequences of arbitrary bytes won over structured/more "rich" formats, and the "everything is a file/stream of bytes" model of Unix dominated; all the complexity involved in handling things like embedded formatting instructions, resource forks and other nuances is a huge obstacle to widespread implementation and interoperability. The phrase I remember reading in reference to this is "text is universal", and I agree completely.
One would naturally wonder how Alto/Mesa managed to have all these features, and the answer is simple: it is effectively a closed proprietary ecosystem, developed by one company with plenty of engineering effort, and with little consideration for interchange with other systems. It also had far more processing power than personal computers of the time.
I don't have the answers to how programs should be written, but the current system just seems wrong, locked into decisions made decades ago. It seems like programming is stuck at a local maximum.
Never underestimate the importance of simplicity and a low "barrier to entry" --- in fact, I'd consider the lack of success of much larger, "fancier", more complex systems like the Alto as a strong evidence that, regardless of how fancy, featureful, and radical your system is, unless it has a low barrier to entry and interoperates with existing ones, it will not endure the test of time.
I suspect that part of the reason is that Microsoft Word's internal representation is such a mess. Making a compiler read .doc files would be a major effort. So writing code in Word never caught on.
There are various programming environments where source code is not structured as big sequential files, but as sets of individual methods, Smalltalk with roots on Alto being one of them (other such environments are various "4GL database systems").
While ST80 has standard textual source code format, it's not something you want to write by hand but essentially an semi-convenient serialization format (with slightly hackish implementation).
> Why are programs even structured as sequential lines?
Same reasons books are structured as sequential lines: easier to read for humans.
And the reason why source code is still heavily text based and why introducing more WYSIWIG to it would be disastrous is that all the peripheral tooling would become a nightmare (diffs, code reviews, source control, etc...).
This is what drove me away from GNU/Linux back into the worlds of Mac OS X and Windows, as the developer communities view of the world isn't Vi/Emacs + CLI.
Working on .NET, Android or Mac OS X/iOS is a much closer experience to working with Alto and Star environments, or even ETHZ Oberon derivatives.
When Emacs started supporting variable-width fonts well, I tried coding with them for a while. It works fine. I went back to monospace not because I'd been more productive, individually, with it, but because I needed to see my code the way others would see it.
I don't like programming with proportional fonts as much because they tend to be narrower than monospaced fonts. To get the same on-screen indentation, I end up using more spaces, and it's easier to have an off-by-one different in indentation, which is troublesome if I'm using Python, and which really bothers me if I'm using C++.
Aside from that, I like having nicely-aligned tables in my code, and it's sometimes useful to align conditional statements across lines. Monospaced fonts just fit into my workflow a little bit better.
It seems backwards that on the Alto you could style your code with a WYSIWYG editor but 40 years later putting a <b> tag in your Javadoc is about all you can do to code.
There are lots of things you could do on the Alto and on the Star that one cannot still do today.
For example being able to do systems programming on memory safe languages, Mesa and Cedar, using a live coding environment, with embedded objects and a rich REPL, which even did suggestions for typos.
Those systems were impressive for their time indeed, but let's not lose sight of our options today; if you want to do systems programming in a memory safe language you can use Rust, and if you want a live coding environment, with embedded objects and a rich REPL, you can use Racket.
He said AND not OR for those features. There might be modern stuff with the AND but they usually ignore something. I had luck in distant past making type-safe 3GL's in a LISP that extracted to C/C++ with checks on. Really kludgy, though. Still haven't seen one do such things as cleanly as the old systems with high efficiency as well.
This reminds me of some of the tricks Apple used to pull with the resource and data forks on the classic Mac OS.
Like, a file could have plain text in the data fork and formatting instructions in the resource fork, so an application that can only handle plain text can just read the data fork, and something that knows how to deal with rich text can read the resource fork and apply the formatting.
While the old Mac OS had its problems, it was full of brilliant strokes of design genius like this, and I'm still kinda saddened that these little tricks are almost entirely gone.
You could in fact do exactly the kind of formatting in the article on an old mac for exactly this reason. The formatting data was stuffed into the resource fork which the compiler was free to ignore but could be used by the editor.
Interesting sidenote, Windows has supported resource forks since the days of NT, but the only time I ever saw them used was when virus writers were trying to hide their payload. Even Mac files brought over to Windows tended to have their resource forks stripped out and stuffed into some cryptically named directory. Ultimately, the resource forks on Windows were such a forgotten feature that they couldn't safely be used, because you never knew when a user might try to compress a file with an oblivious compression tool or send it via some old DOS program and strip out the resource fork by accident. They are the kind of clever feature that only works if everybody agrees to honor them, and become a total nightmare otherwise.
How did it handle the contents of the data fork getting out of sync with the contents of the resource fork? Or was the plain text "view" of the data read-only?
Not even joking, take a look at TempleOS and HolyC... Terry Davis has made some wonderful features that allow for formatting code files and embedding a variety of rich content (like images or videos).
TemplosOS and especially HolyC and the editor are one of the few instances of something done wonderfully right, but for the wrong intentions, rather than the other way round.
His embedded models for example in the editor are stunning.
If by 'outside world' you mean legacy systems, then ok, that's valid, but there's not really any reason that idea couldn't be portable across systems, as long as they support common encodings. I fail to see how a ring-0 memory model factors in at all.
I seem to recall reading that the Bravo editor stored the text and the formatting separately. So having the compiler read the text and ignore the formatting maybe not so mind-blowing after all.
No, not sarcastic at all. It never occurred to me that we could have a simple rich-text rendering for code. For example, render code in html, and strip all tags before passing through to the compiler. Why don't we do this?!
Syntax highlighting is nothing like that. It's one-size-fits-all. All types/keywords/whatever get the same color. It doesn't support font changes.
If I was to hack this into say Neovim, I'd leave color alone and focus on just wysiwyg markup for font size/style. Imagine being able to bold the key call inside a function that does all the important work.
Didn't mean to sound personal - I was just involuntarily baiting the editor war discussion ;).
> What happens when you quit and restart?
I'd lose the changes because I applied them only to the runtime configuration. It'd be a few seconds more of work to save them permanently to my configuration though.
In general, Emacs implements syntax highlighting by applying various "faces" to the highlighted parts. Those faces are highly customizable - including font foundry/family, various sizes, slant, as well as various decorations, foreground & background colors, etc. It has no problem rendering multiple fonts simultaneously (which is actually pretty useful if you're dealing with Unicode characters - your typical programmer's font won't have glyphs for many Unicode characters, so you can set "fallback fonts" for those).
To de-bait the editor war trap, I think Eclipse can also pull that off, but I've left the only instance I have at work so I can't confirm it now :).
---
EDIT: Crap, I think I misunderstood you.
Did you mean "annotating" code with temporary style changes, especially in a semantic way? If so, I don't know of any editor that would support it out-of-the-box. In Emacs, you could probably hack your way around this with temporary font-locking (aka. adding an on-the-spot syntax highlighting for a particular symbol, and applying all the face-configuration-magic I described earlier), which I sometimes do when digging through log-files or grep results - there's a family of functions like "highlight-line-matching-regexp" or "highlight-symbol-at-point" with which you can quickly assign such highlights (and then there's a command that will write out all highlights in the format that you can save as a file-comment so that Emacs will reapply them the next time you open that file). But this is a hacky solution, IMO.
This also brings me to my observation that there's literally zero tools out there for reading code. Something I'd love to change, and I keep gathering ideas, but I sadly lack time ATM to make even a proof-of-concept.
I have no doubt that you can apply various decorations to text, but that is also the part relatively less interesting to me. I'm more interested to see in what format you would save emacs's runtime configuration that would allow it to embiggen just one '&rest' in a file. Can you show an example of what this elisp would look like? Markup seems the most natural approach to me, to avoid issues with files getting renamed, etc.
I don't know how to do that exactly. In Emacs per se, you could probably abuse bookmarking facility - there are some built-in ways for Emacs to remember a particular place or region in a file that are somewhat resistant to changes in other parts of the file; AFAIR they involve a combination of storing the line number and the pattern describing the marked text / its surroundings. Or something like that. I've been playing with some Emacs libraries for annotating parts of file that would store those annotations in a separate place, but they were all rather crude. It's definitely an area that needs a lot of work.
Markup seems to be the most robust approach, but sadly, it isn't supported by pretty much any tool in use.
Ah, just saw your edit. I'm not sure what you mean by 'temporary', but there's two axes here:
a) Is the formatting saved across restarts?
b) Is the formatting customized for tiny parts of a file?
What I'm looking for is 'temporary' for b) but 'permanent' for a).
> This also brings me to my observation that there's literally zero tools out there for _reading_ code. Something I'd love to change, and I keep gathering ideas, but I sadly lack time ATM to make even a proof-of-concept.
That is very close to my heart, though my theory is that reading code only becomes easier when the very representation of software projects undergoes a sea change: http://akkartik.name/about. I'd love to hear your thoughts!
Re a) and b), I replied below your comment about your Vim plugin.
> That is very close to my heart, though my theory is that reading code only becomes easier when the very representation of software projects undergoes a sea change: http://akkartik.name/about. I'd love to hear your thoughts!
I read the page you linked (though I didn't browse the other parts it links to - I'll have to leave that for later). Quite a lot of interesting ideas you have there. I've added the Mu project to check out later.
It seems we have similar general goals in mind, but different ideas of making it happen. You seem to be focusing on how to change the programming practice to facilitate understanding of large codebases. I am thinking more along the lines of tools that would help one explore and get the picture of existing codebases in current languages.
So far, I've briefly explored areas like:
- software for generating diagrams of the code
- software for generating runtime diagrams
- time travelling debuggers
- printing out code on paper (per edw519's advice) and annotating it
- annotating code in PDF readers and word processors
I think what resonates with me most in the text you linked is "Deemphasize abstractions in favor of traces". I actually went into the first three bullet points of mine because I had to refactor some code that I couldn't figure out the exact flow of. What I wanted was exactly the "trace" of execution I could inspect. Unfortunately, the time travelling debuggers I tested are too heavy for the task, and don't present the trace itself in any way, they just allow you to navigate it.
A dream tool I'd love to have would be a "read-only" IDE for code, that would let me quickly move around the project with semantic commands ("jump to definition", etc.) and annotate stuff. I want to take notes, highlight stuff in colors, even draw on the code. Kind of a combination of a good IDE and annotation facilities of a PDF reader.
I have a lot of thoughts on the subject; I guess I should publish them somewhere at some point :).
"A dream tool I'd love to have would be a "read-only" IDE for code, that would let me quickly move around the project with semantic commands ("jump to definition", etc.) and annotate stuff. I want to take notes, highlight stuff in colors, even draw on the code. Kind of a combination of a good IDE and annotation facilities of a PDF reader."
Yeah, I spent a few years thinking about a "wikipedia for code" which is almost exactly what you describe. But I eventually gave up on it for 2 reasons:
a) I started learning about the benefits of tests, and I noticed that this idea doesn't really have a good answer to how to make use of tests for reading.
b) I started noticing that in large teams and over time a good tool contains within it the seeds of its own demise. It's a little like creating roads to relieve traffic: for a while things are good, but then people start buying more cars (at least in the US), and eventually traffic is as bad as it used to be. In software, for example, high-level languages make it easier to declare function arguments (compared to say Basic's GOSUB), but now programmers start creating functions with 20 arguments, and that is as bad if not worse than GOSUB. Inheritance makes some kinds of control flow easier but also causes new kinds of spaghetti code. And so on and on..
These are the reasons why I stopped thinking in terms of just a tool. A tool helps existing habits, but loses control of new habits created around the tool. Changing practice, on the other hand, would affect both sides of the feedback loop. Instead of a vicious cycle of new abstractions (language features or tools) that hide details from the user and cause users to abuse them, I'd like to trigger a virtuous cycle where using a tool gradually makes you more likely to understand its internals. Lisp macros have that property: after using them for a few months I was surprised to find when I built a lisp interpreter how easy implementing macroexpansion was. It was as if macros were a (benign) virus that planted themselves in my brain as I used them. I'd like to create more such viruses :) It's a slower approach to changing things than creating a tool, it's true. But I think there's a lot more upside in the long run.
As an example of persistent-but-customized, check out this plugin of mine (in an inferior editor, sadly ;) which lets me highlight specific words in a random but persistent color: https://www.reddit.com/r/programming/comments/1w76um/coding_.... When I'm reading a strange codebase, finding a couple of key variables to colorize immediately causes the data flow of a function to "pop out" to my eyes.
I still have that experimental buffer opened, so I used the features for highlighting I described to highlight words "let", "buffer" and "create" with highlight-symbol-at-point, and the lines containing word "foo" with highlight-line-matching-regexp:
The last four lines were generated by calling M-x hi-lock-write-interactive-patterns. If you save them in the file, Emacs can reload and reapply those highlights in the future.
I use it mostly when browsing log files, though the feature is useful for code too. Since I'm addicted to traditional syntax highlighting, I prefer the background change when highlighting code.
Yeah, I think what you showed is exactly what my plugin was going for. To get more fine-grained than that we'd need a smarter editor that understands markup. Fun conversation! I just shot you an email.
Okay, I was going off an old comment from Animats where he said "The Bravo file representation was plain text, followed by a control-Z as an EOF, followed by the formatting information. The compiler just stopped at the control-Z."
^Z in DOS was a holdover from its roots as a CP/M clone. CP/M in turn cribbed it from certain DEC OSes, because that's what Gary Kildall used while making CP/M. So ^Z is a case of convergent evolution.
Isn't the Mesa compiler for the Alto available? If you have that, there's no need to write in in the British Cruddy Programming Language. BCPL was written as a tool for bootstrapping compilers. It's one notch above a structured assembler. The only type that BCPL supports is the 16-bit word.
Mesa and Smalltalk for the Alto are around [1], so I hope to get them running at some point. The files need to be copied into a disk image that the simulator can read, so I may need to write an Alto file system emulator.
Lisp for the Alto, on the other hand, seems to be entirely gone - I asked around and nobody seems to have a copy. From what I hear, it never worked very well because there wasn't enough memory.
C was my first programming language and several years ago I became acquainted with ALGOL 68. I'd never seen BCPL before a few months ago. It's rather interesting how, from the perspective of someone born well after its creation, it is very clearly the link between the ALGOL family and C. I'm sure that's rather obvious to programmers who were around in the mid to late 60's but for me personally it was a lot like discovering a missing link.
[0]: http://www.cl.cam.ac.uk/~mr10/BCPL.html
[1]: https://gist.github.com/seaneshbaugh/e09abd748ccc07c5463f253...