MATLAB fits a specific market, whereas Delphi is very general and open ended. Their great benefit is RAD (Rapid Application Development) of GUI applications in relatively less time.
I always want my variable names to be as long and descriptive as possible. We're no longer in the teletype era and our monitors are huge. With autocomplete there is no reason to keep variable names short
Thats the only acceptable way to write code, but it doesn't mean that names can't be too expressive, for example I wouldn't accept nameing like this:
> RandomizeArrayPositionUsingFisherYatesShuffle
Since the algorithm detail is something I don't want to think about when I use it and something that the implementer should be able to change without changing the contract.
Having Getters for each member variable always seems fine and reasonable. It's when you have getters that do "magic" that I feel a little.. unsure. Like if it's taking a member and returning it in a different unit that seems kosher... But there is a fuzzy line where at some point the Getter is doing too much work to genuinely be a getter. It gives a false impression for the internal structure of the program. But conveying the const'ness is important as you describe (or semi-constness if you have caching)
I'm of the somewhat unpopular opinion that "getters for everything!" is a philosophy that sounds good on paper, but results in writing a lot of getter and setter functions and feeling safe, while ignoring these sorts of traps cropping up everywhere.
Member variables are easy to reason about; they behave exactly like the type they are, and in the case of built in types, have extremely consistent behavior. Getters / setters are a black box of mystery; I like to reserve that pattern for when there's going to be extra work to retrieve some value, so my call site knows it needs to tip-toe around possible failures. While I can see the value in using getters/setters for everything in something like an API or framework, I don't see the value in trying to use them all the time, "just in case."
I haven't really seen this done but couldn't Google pour money in to developing very high quality GPL'd libraries for say.. C++ or Python - becoming the defacto standard libraries. If other's want to use them in their closed source projects they'd have to pay licenses to Google, however internally they can use them in their closed source code since they own the rights to it.
The trick would be get that critical mass where competing libraries aren't used as much. Google definitely seems to have the talent and workforce to do it
Anything that makes it easier to develop native software (which 'won't-suddenly-disappear' software has to be) is in direct conflict with Google's strategic interests (Chrome, ChromeOS) and their bottom line.
MATLAB has cashed in and they don't have a free version. Octave isn't eating their lunch.
And it's not like the C/C++ guys made a ton of cashmoney - so "just make it free" isn't generally a viable business model