I'm a retired 72. I've been programming in C, C++, Fortran, ASM etc. etc. for over 40 years, and used just about every OS/GUI going.
But, but, but I really cannot get along with mobile phones! Whenever I pick one up I swipe or press the wrong thing. Just answering a call usually goes horribly wrong! And I have literal nightmares about it. So I am pretty much stuck with my VOIP landline, but am worrying things like my bank will stop supporting the tech.
Luckily, I guess I've done my three-score-years-and-ten, so I don't probably need to retrain. But I can completely understand non-techie oldies having problems.
I have Windows 11 on my Asus laptop - I've never seen an ad (except on some web pages my adblocker doesn't catch) - where are all these Win 11 users seeing all these ads?
Well, I dunno. On my lock screen I get local weather, local events and such, which I don't mind and are not really adverts. I never see anything else. Nothing in start menu or taskbar.
This is Windows 11 home. I wonder if people complaining about ads have some 3rd party adware installed, or are just parroting what they have heard about the evils of Microsoft?
By having knowledge baked into it about its properties (which it can validly do because the behaviour of the float_abs operation is specified by the language; it's not calling an arbitrary external function). The blog post sketches out one approach to this: as the optimizer is working on a tree of expressions, it has attached to the nodes extra information about the values in it (e.g. "this is a constant X" or "this value is definitely in the range A..B"); then as it simplifies the tree, it can say "abs of a value that's already definitely not negative is a no-op, don't do anything", in the same way it can say "multiplying X by 1 is a no-op".
The actual bug-fix linked to in the footnote does it in a slightly different way: it says "as I'm walking through optimizing my tree of expressions, if I see 'abs(abs(X))' then simplify the tree to just 'abs(X)'".
I'd agree with 1-based indexing problems, but not 0-based, which seems very natural. And if you have -2-based, I'd argue that perhaps you don't want an array.
I think it's down to personal preferences/how you think. I haven't actually used any languages that didn't have 0 based indexing, but I remember it being very painful and super unintuitive to learn, it just didn't make sense at all (still doesn't, but it's not a problem for me anymore). I always thought 1 based would make a lot more sense and be way easier to learn.
None, in my experience. 1-based is far, far likely to introduce errors, as you have to keep adjusting the index to the algorithm and/or what is actually going on underneath.
> as you have to keep adjusting the index to the algorithm and/or what is actually going on underneath.
Yeah, that's mixing both of them. Wouldn't it work as well if they all used 1-based indexing or 0-based indexing? Sounds like the issue was that algorithms/stuff underneath wasn't 1-based.
I would say it is sensible. Given that an array index is an unsigned integer, what are you going to do with an index of zero?
Perhaps I've been influenced by writing a lot of code in assembler, way back when, but zero-based has always seemed completely natural to me, to the extent that I find it very hard to understand algorithms expressed in non-zero based code.
An array index can be signed with no problem. If you're worried about the address calculations, well, the address of an array doesn't have to be the address to its initial element, does it? It can be the address of the element with index 0 (even if an array does not have such an index at all):
arr: array[-2..10] of integer;
pointer(@arr) == pointer(@arr[0])
Or you can use descriptors (dope vectors), but that involves quite an overhead. The books on compilers from the 70s (e.g. Gries's "Compiler construction for digital computers") have rather extensive discussions on both approaches.
Yes, I'm familiar with Pascal indexes, but I don't find them very natural for the kind of programs I write. I want functions/classes to do any sort of translation.
> The books on compilers from the 70s (e.g. Gries's "Compiler construction for digital computers")
Yellow cover, I think? My then GF bought it for Xmas at about 1984 or so. Not the best book on the topic, IMHO.
I think encountering C arrays and pointers rewrote my brain so that 0 based indexing made more sense even though up to that point (~40 years ago) I'd only used languages that used 1 based indexing (Basic and Pascal).
0 based is much simpler for any mathematical calculation done with the indexes. only reasons I can think where you need to handle it is when getting the last index from the length of the array or when interacting with the user. With 1-based you'll need to subtract or add 1 all over the place when doing almost anything
Ah, ed. Back in the mid 80s, I had to teach a course on Unix & its tools - if I remember correctly it was called "Unix - a modern OS". One of those tools was of course ed. We couldn't use vi because the termcap/terminfo settings were screwed up for the physical serial terminals we had - I eventually fixed this & felt very pleased with myself, as those terminal config files are a b*tch.
Still, teaching bash, C and the usual suspects along with ed was very strenuous for the students, and for me - we only ran the course once.
In retail banking I'm sure that this could be true. Working in investment banking, I never saw a single COBOL application, or had to have my C++/Java/$MODERNLANGUAGE code interact with one.
Corp bank here, everyone has rumours about COBOL systems but no one I've ever spoke to has seen, interacted or has any other evidence these really exist anymore either.
But I asked for a bank statement from my old savings account a few years old and it took two weeks to print out, printed in monospace dot matrix.
Or the betting company that I was a customer that suspends betting everyday 6:30am for an hour for daily maintainance. Ironically, they would accept bets for football matches played at the time, but the system was shut down.
You haven’t seen or heard them because they are abstracted away by APIs, circuit breakers and proxies. Almost ALL banks, credit card companies, travel systems and other high throughput transaction systems run on mainframe that is written in COBOL.
I think the issue here is that people working in fintech don't seem to come across these systems much, if at all - if you know one specifically, please tell us.
It's still there at the accounting/backend level. Automated Financial Systems Level 3 and it's replacement Vision are commercial loan systems.
LVL3 is pure cobol. It has been recently deprecated but there are many banks who own the code and are still self hosting it, along with it's IBM green screen support.
Vision is a java front end in front of an updated cobol backend. When your reputation is based on your reliability and long term code stability, at what point do you risk making the conversion, versus training new developers to work on your system.
No, we are not afraid of our own systems. The idea that there is some fabled computer system which everyone is too scared to touch doesn’t exist (I work in payment processing). There are levels of controls way outside these systems which provide these safety nets (e.g settlement / reconciliation controls).
If the cobol is still there, it’s not due to risk. If anything, the cobol is a much higher operational risk than replacing it.
Analogously, GDSes like SABRE still ran on mainframes until very recently (c. 2023) [0]. SABRE was written in some combination of assembly and some kind of in-house dialect of PL/I, if I recall.
I worked briefly at a company that wrote applications that interacted with bank mainframes. Think end point bank teller systems and in branch customer/account management. They definitely do exist - every major bank has a mainframe written in (usually) cobol.
But it's very abstracted, part of our main product offering WAS abstracting it. On top of our ready to use applications, we offered APIs for higher-level data retrieval and manipulation. Under the hood, that orchestrates mainframe calls.
But even then that there could be more level of abstractions. Not every bank used screen-level mainframe access. Some used off the shelf mainframe abstractors like JxChange (yes, there's a market for this).
Fintech would be even more abstracted, I imagine. At that point you can only interact with the mainframe a few levels up, but it's still there. Out of sight.
> Working in investment banking, I never saw a single COBOL application
What was the back office settlement or wire transfer system written in? There is a good chance that some part of them was written in COBOL. And while Bloomberg terminals are a vendor product, for a bloody long time, many of their screens had some COBOL.
Also, lots of quantitative software at i-banks use LINPACK or BLAS, which use FORTRAN.
Well, I had a very badly specified project to write a library for our back office systems to do Swift payments from our C++ applications, via COM. There was no obvious COBOL involved, on either side, but it has to be said that the whole use case for the library was very murky. And it never worked, due to the lack of spec, not the languages.
First hand knowledge:
ERGO and MunichRE both have a lot of cobol still doing the core business. You will most likely never run into the system because they just run batch jobs - sometimes configured via a “nice” web UI… you configure your job, submit and the next morning you have your report… that’s why you never actually see COBOL.
Surely an abacus is a simple form of digital computer? The position/state of the beads is not continuous, ignoring the necessary changes of position/state.
But, but, but I really cannot get along with mobile phones! Whenever I pick one up I swipe or press the wrong thing. Just answering a call usually goes horribly wrong! And I have literal nightmares about it. So I am pretty much stuck with my VOIP landline, but am worrying things like my bank will stop supporting the tech.
Luckily, I guess I've done my three-score-years-and-ten, so I don't probably need to retrain. But I can completely understand non-techie oldies having problems.