Posts by MarkMLl 24 posts • joined 29 Jun 2019
I don't know who advises the ACM grandees on this sort of thing, but the charitable assumption is that he was working from home and the wrong side of the paywall that protects the ACM archives from plebs like us.
Everybody agrees that Aho (, Sethi) and Ullman wrote and maintained a comprehensive book describing compiler writing. But crediting them with major contributions to the field?
What about Irons (recursive ascent), Grau and Waychoff (recursive descent), Knuth (who famously wrote a mainframe ALGOL compiler over his Summer vacation), and Wirth (an undeniable "doer" and influential on just about every major language)? What about Schorre (compiler-compilers) and Richards in the UK (BCPL?) What about Hoare and Dijkstra, who laid much groundwork even if not significant compiler authors in their own right? Hell, what about Alan Kay (Smalltalk)?
Crediting Aho and Ullman as substantial contributors of original work is vastly wide of the mark, and smacks of the current tendency to lionise "media personalities" and to listen to those who make the most noise.
Thanks for the more recent photos which I think just about wrap this up. I'd comment that Google Maps shows a cluster of (maintenance?) buildings in the area from which that the original Twitter photo was almost certainly taken, so presumably somebody got out quickly to take a photo or there might have been a camera set up taking timelapse shots.
Finally, I think we could all do with remembering the island and people of Puerto Rico, which is much more than just a convenient foundation for the USA's astronomical facilities.
That's been "photoshopped". If you look carefully the cables have completely vanished, and the towers in the "after" shot have fewer tiers than in the "before" one.
Genuine photo at https://astronomy.stackexchange.com/q/38585/7982
Which just goes to show that one shouldn't take stuff on Twitter at face value.
The problem with ALGOL-68 was that when Wirth's ALGOL-W was rejected he threw his toys out of the pram and resigned from the committee. If he'd stayed but voted against the proposed standard than it's likely that a majority of the committee would have followed his lead... it was basically Wirth+Hoare vs van Wijngaarden and a number of his students whom he'd coopted.
And what exactly McCarthy was doing there is unclear, since he'd already abandoned ALGOL for Lisp.
MarkMLl
There was something odd with the magstripe on those early dispensers: Burroughs used some sort of "pepperpot encoding" which I suspect relied more on obscurity than cryptographic rigour.
The TC500 was an interesting brute. A mechanical golfball driven by steel tapes (to circumvent IBMs patent which used steel wires), and a small disc for main memory to circumvent GOK how many patents on using a drum (in particular, I suspect, the LGP-30 which was a similar serial-logic machine).
And software was typically loaded into it using paper tape made out of recycled bog roll. Which was also used for diagnostic software, which more often than not would tear or jam with a customer breathing down your neck.
The bottom line is that we should be asking ourselves: if we can't make it, should we be using it?
International telecoms and cross-manufacturer operability were long ensured by CCITT standards, and I'm pretty sure that they weren't beholden to FRAND agreements. If some technique is so obtuse that somebody can claim that it's protectable by patent then it's probably not the sort of thing that we want in an international standard, even if it would appear to be desirable to keep the teenagers happy.
And while 99% of 5G will probably be teenage chatter and porn, it's the 1% which is business and emergency services that really matters.
MarkMLl
MarkMLl
I'm entirely OK with the idea that a header file is a factual description of a library (etc.) which is otherwise opaque. The function names are a statement of fact, the types- in conjunction with documented compiler behaviour- are a statement of fact, and the order and type of parameters are a statement of fact. The names of function parameters are not necessarily a statement of fact, but can be changed without altering the API.
What I'm rather less OK with is when a header file contains macros, which are themselves functional and as such are not a simple statement of fact. In my opinion complex macros have no place in published header files, since they blur the distinction between the purely factual definition and the implementation detail.
MarkMLl
> For decades now we've had people needing to program as part of their day job and they simply don't have the education or aptitude to be able to use something like C correctly. But that doesn't mean that they can't write perfectly reasonable code in something else that internally relies on C.
It also doesn't mean that their preference for Python or Javascript should carry as much weight as the opinion of somebody who through long experience and study knows what he's doing.
> What do the inexperienced programmers code in to become experienced programmers?
Anything that's available, but not on live projects.
That might be the reason that so many large projects these days run into enormous problems: industry and government isn't prepared to support an infrastructure of dummy runs and experiments most of which are expected to fail, so instead of cutting their teeth on- for example- a moderate-sized program which is one of many running on a bank's mainframe novice programmers are expected to be effective members of a team writing a comprehensive integrated system: and if their collective inexperience breaks it there's no fallback position.
> Yes. But for the practical purposes of this discussion (?), the vast majority of Perl use cases is pattern matching and substitution.
I'd suggest that that's unfair, and I'd point out that most of the substantial corpus of add-ons in CPAN can't be invoked directly from a search which implies that most developers recognise that Perl- once it had started to move away from its AWK heritage- was something more general.
It certainly has exemplary pattern-handling capabilities for something spawned in the 1990s. So exemplary in fact that most languages developed since are at least as comprehensive in that area.
> > Python's major problem is the significance of tabs and indentation [ ... ]
> That. We tried this once with Make. Everyone hated, and still hates, it. But no, Python had to do it again, because once is not enough. And it has nothing to do with helping code readability.
Actually, we tried it with FORTRAN which required that ordinary statements started in col 7. And in ALGOL and COBOL which might have been more relaxed about start column but in most early implementations still reserved a chunk of each input record for a line number.
"Some [preferred] the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause." -- Rob Pike https://talks.golang.org/2012/splash.article
And finally, for another 2d worth, I'd add that Dijkstra's comment about "coding bums" AIUI echoed John McCarthy's words and sentiment which were originally inspired by a certain type of student who obsessed about shaving an instruction or so off a sequence of operations in the same way that a downhill "ski bum" obsessed about shaving a second off his run.
I'm quite sure that you can write impenetrable code in any language, and would suggest that if a language comes along that prevents you from turning a hard-to-understand algorithm into a difficult-to-follow instruction sequence that there's probably some severe downsides to it. But while I'd certainly agree that some of the things in Perl give sloppy workers much more rope than they deserve, I think that the real problem is managerial: most fields of applied science /require/ adequate documentation and review, and the complexity and pervasiveness of computer software makes that requirement even more important.
Ultimately, saying "this code works even though nobody really understands it" is neither an excuse to allow the situation to continue, nor adequate justification to rip it out and redo from scratch. And selecting Python or Javascript for the sole reason that they're popular with inexperienced users is asking for trouble.
AWK is fundamentally different, in that it was designed to match patterns and insert replacements rather than to perform sequential operations with its own robust flow control. Virtually every "shop" had something like that which it used to do things like systematic modification of source files before they were compiled/assembled: I used something called Stage2 (W.M.Waite) for that sort of job.
And irrespective of whether it really was the first, by the time Perl reached v4 it offered a vast improvement when compared with the alternatives. /Much/ more significant than that offered by Python when compared with Perl etc.
Perl's major problem, leaving aside the perennial tendency of twits to advertise their superiority by writing impenetrable one-liners, was the sigil prefixes. Python's major problem is the significance of tabs and indentation, which can make it virtually unusable as a component of some larger system which emits code fragments. Quite frankly, the World deserves something better.
132 little electromagnet assemblies, each delivering enough impulse to a hammer to bang the paper and ribbon onto the right character of the rotating drum and then get out of the way /fast/. Printing long sequences of the same character in the same column was particularly cruel- particularly when you allow that Burroughs at that time wasn't exactly renowned for its R&D expenditure and the printer electronics was basically 1960s technology.
Even worse was the "comb" of magnets interleaved with the hammers. This was inherently fragile and was inclined towards "rapid unscheduled disassembly": I'm sure I've got a few bits in a gash box since in their day they were quite usefully strong.
Don't get me going on Burroughs's power supplies, which typically had lots of transistors in parallel which were inclined to "unzip" releasing things into the atmosphere that today would be considered Very Bad News Indeed.
The Burroughs TD830 (certainly the "J" variant) was based on a 6800 and similarly allowed a binary to be loaded: somebody used the ISO2047 (?) character set- the one with lightning bolts etc.- for a game of Space Invaders.
Allowing that this was decades before code-signing, encryption on the leased line back to the mainframe and so on the security implications are horrendous.
"...easier to debug": that is of course an interesting point, since neither Delphi nor Lazarus/FPC are entirely happy when debugging an app split out into DLLs on account of the large amount of memory management (strings passed as parameters etc.) behind the scenes.
I think it's worth commenting that early versions of Turbo Pascal- you remember, with the "treat this like a book" licence- not only installed on multiple operating systems (CP/M-80, CP/M-86, MS-DOS) but could also be customised for different keyboard and screen types. Now that is obviously far removed from the pixel-perfect positioning and prettification that is de rigeur in current desktop application programs, but the unavoidable conclusion is that somebody took their eye off the ball and screwed up badly.
And my understanding is that the person at the helm when Borland decided that it was better off concentrating on large corporates and didn't need goodwill from small users later resurfaced handling developer relations for IBM's OS/2.
Pascal is a bit of a pariah as far as languages go, but I tend to justify its use- where suitable- by pointing out that as implemented in Delphi (and in Lazarus, with the Free Pascal Compiler as its code generator) it is basically the final expression of what were known in the 80s and 90s as "4GLs"- in fact one might even call it the last one.
Lazarus does have the advantage that it is distributed as source and can fairly easily be rebuilt if an up-to-date binary for a particular platform is unavailable, which is particularly useful with CPUs which have multiple subarchitectures such as ARM. It also gives it a fair chance of "just working" on a platform which the core developers can't easily test, for example in the past I've relied on the fact that FPC can generate SPARC code and Lazarus supports Solaris (for x86-64) to build it without too much of a problem for Solaris on SPARC.
While FPC's support for multiple CPUs and OSes is superb, the one unfortunate thing is that Lazarus can't support alternative languages. Having something as mature and flexible as the Lazarus IDE working with a decent C++ backend would be an unbeatable combination.
MarkMLl
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2021
