One would assume that, but in practice, the predominant style is not one of many short procedures. Instead it feels that there's a preference to just inline the code unless the resulting procedure will have more than one caller.
Control structures are deeply nested and this goes on for 64 (very dense) lines. The low line count but is an artifact of how Oberon is conventionally formatted. When reformatted to mimic the conventions of languages like C, Java or Python it works out to more than 120 lines.
When I program in Oberon (recreationally) I tend to follow this style even though I would extract the same code into a separate method were I writing in Java.
For extra fun consider the German-Speaking word where CSV files are actually Semicolon-Separated but everyone still calls them CSV and looks at you like you drooled on yourself when you point out that “;” is not a “,”.
This appears to be because we use “,” as decimal separator and were too dense to learn how to use " properly in CSV.
When I wrote "teletype" I wasn't referring to what teletypes had become by the time by the time Unix was developed. Think further back than that. This is why I mentioned 5-bit codes:
This coding scheme is so constrained (32 possible 5-bit values) that it uses the codes FIGURES (01000) and LETTERS (10000) to toggle back and forth between two alternate sets of meanings for the remaining 30 possible codes. Still not enough space for lower case or ASCII's plethora of control codes (just NUL and DEL).
The early days of manual typewriters, paper tape, teletypes and vacuum tube systems, which already followed this practice predate US-ASCII, so I don't think the particular numeric values assigned by US-ASCII can have any explanatory power in answering this question.
Me, I blame the Romans ;-)
The Latin alphabet was initially only what we call the "upper case". What became the lower case came (a millennium?) later, first as an alternate style of handwriting and then as an addition to the alphabet along with rules about when which form of each letter should be used.
Given the need to economize as in 5-bit teletype codes it's not surprising the chosen convention was to print (or later display) those codes as upper case as that is, historically speaking, the default.
Still, I like to wonder if anyone every thought to build a teletype that printed in lowercase just to screw with people. :-D
I've always suspected that 'Reader' and 'Writer' were names borrowed from Oberon since that's one of the influences that contributed to early Go design:
Enumerations and subranges (in style of Modula-2 and Pascal) are missing from Oberon, but Records are present subject to type extension in the style of structs in Go.
In Oberon(-1), we used (pointers to) procedures in record fields as methods when programming in an object-oriented style.
Oberon-2 added methods which dispatch dynamically based on type of receiver. These were "type bound procedures". You'll find this idea echoed in Go as well.
I was shocked by how spammy Amazon.com's search results seemed compared to what I'm accustomed to from Amazon.de. I'm not a regular user of Amazon.com but have had occasion to do so since I'm visiting family in the US. Amazon.de is the "local" Amazon where I live.
Is this an affect of differing laws in the EU versus the USA? Differences in leadership of Amazon.com versus Amazon.de? Differences in perceived market expectations? Perhaps the average American consumer is expected to be more tolerant of this kind of thing? (I wonder because I compare the robo-call-infested hellscape that we've made of our telephone system compared to the rarity of such abuse where I live in Europe and wonder if we, in the US, are just more prone to behave in a way that produces tragedies of the commons.)
"Permanently suspended" is neither accurate nor helpful. That an account can't leave that state is precisely what "permanently" means. Since an appeal is possible, "Indefinitely suspended" would be accurate.
The article's proposed mapping of tags and especially comments to links strikes me as unavoidably clunky in a world where one-way links are the only kind available.
Maybe I'd find this golden hammer argument more convincing in the context of a hypertext system where bi-directional links [1] were common and well supported.
> In school you do “experiments” and if the answer doesn’t match what is in the book you are marked down.
This is unsurprising and probably obvious. The purpose of the exercise is learning how to do experiments reliably so that at some later point when doing experiments to test a hypothesis you can have some confidence that the results you produce are actual data and not just noise.
When doing science class "experiments" of this sort perhaps it would illuminate things to students better by going up one level: the hypothesis under test is "student can perform experiment reliably". The putative subject of the "experiment" isn't the actual subject in inquiry: you are. On the other hand maybe this would just confuse students. (I've observed wildly varying capacity for abstraction and meta-cognition among the people I work with as a software developer so I suppose this is something that varies among individuals generally.)
Back in the day™ Think’s Pascal used bold, italics and underlining to do syntax highlighting because the Mac’s screen was black-and-white. It would be a compromise: you can’t encode as much information into the text’s appearance without access to color, but it could be sufficient depending on your requirements.
My $JOB is maintaining such a desktop CRUD app that's been in use for the past 20 years. It uses a Swing (via a proprietary higher-level framework) for its GUI. Over the years it's accreted a few dozen services (also in Java) in its orbit, but the central GUI app and its data-base still remain and continue to be extended as new requirements arise.
iCab was a favorite of mine before the switch from Classic Mac OS to Mac OS X. I made heavy use of its ability to save offline copies of open web pages (with all embedded resources).
http://www.icab.de
This will already sort equal file names together. If I wanted
to combine that with file sizes, I'd probably do some kind of
decorate | sort | undecorate
dance on each line produced by find. Where decorate would add the start of each line the things you want to sort by and undecorate would remove them again.
For example, search for "PROCEDURE Scan" here: https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Texts...
Control structures are deeply nested and this goes on for 64 (very dense) lines. The low line count but is an artifact of how Oberon is conventionally formatted. When reformatted to mimic the conventions of languages like C, Java or Python it works out to more than 120 lines.
When I program in Oberon (recreationally) I tend to follow this style even though I would extract the same code into a separate method were I writing in Java.