Posts by MarkMLl

Britain has no idea how close it came to ATMs flooding the streets with free money thanks to some crap code, 1970s style

Re: Not the only Burroughs ATM story

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.

There are already Chinese components in your pocket – so why fret about 5G gear?

Re: Standards?

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

One-time Brexit Secretary David Davis demands Mike Lynch's extradition to US be halted

Re: There's no imbalance in the treaty

More to the point, my recollection is that one Boris Johnson argued passionately against the "unequal treaties" we have with the USA during the very brief time allowed in Parliament to debate the 2003 agreement.

MarkMLl

In the red corner, Big Red, and in the blue corner... the rest of the tech industry

A header file might be more than just an API description

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

Re: Protocols. not APIs

... and a protocol is defined by the specification in one or more RFCs, without which it would be opaque. A header file is to a binary library as an RFC is to a binary protocol.

MarkMLl

Clutching at its Perl 6, developer community ponders language name with less baggage

Re: Why exactly is Perl any worse than Python?

> 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.

Re: Why exactly is Perl any worse than Python?

> 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.

Re: Why exactly is Perl any worse than Python?

> 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.

Re: Why exactly is Perl any worse than Python?

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.

Beware the developer with time on his hands and dreams of Disney

Re: Printers were another prime target

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.

Re: File under "abuse of resources"

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.

Delphi RAD tool (remember that?) gets support for Linux desktop apps – again

Re: "It is the security aspect that would worry me though."

"...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.

Re: "many developers such as myself who are not writing off-the-shelf apps "

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.

Re: A good indication of the market ...

Doesn't seem to stop corporates buying Oracle products, which AIUI are regularly presented to senior management over the heads of their technical staff.