So true, tale as old as time. Someone “raises doubts” based on partial knowledge of the subject, they go back and forth with someone, and then finally someone comes in with conversation-killing “what is consciousness anyways” type comment
The underscore prefix is more about communication. It's not a bad convention as it makes you feel a bit dirty when you are using them outside a class, but, do what you want, we are consenting adults.
Whenever I say "I'm no longer attached to all that private stuff", people always reply, "wait until you work on a large code base". I work on a million line+ code base. Whatever.
This argument aside, I'm not a total philistine. RAII is awesome but C++ is full to the boot with crusty stuff to keep the compatibility. I always feel there is a language better than anything trying to come out.
Python will literally mangle the names of double underscore members by prefixing them with the class name, to make it harder to access from the outside, so it is not just about communication.
These days I'm for minimalism, most of my structs are aggregates of public members, but sometimes you really want to make sure to maintain the invariant that your array pointer and your size field are in sync.
Using double underscore is advised against, and the name mangling is largely considered a mis-feature these days. Most style guides will tell you to use a single underscore to mark something as not for public consumption.
Of course neither double nor single underscore will stop anyone who wants to touch your privates badly enough. Which is big part of the python philosophy: You're not stopped from doing inadvisable things. Instead there's a strong culture around writing "pythonic" code, which largely avoids these pitfalls.
Also in microservices land you could have the service doing its business logic but needing to support a server for metrics and/or debugging. Just piling on, this is good to study :)
I also left engineering for law. Money was a factor when I applied, but also I did not like being pigeon holed in my engineering career. I do patent litigation, so I get to see discovery on the whole system as opposed to portions of it for a variety of technologies (i.e., network security, semiconductors, mechanical devices). I only had about 2 years of engineering experience (working in defense industry), but found the career boring and the pay low (~60k starting vs $160k starting in big law (which is now $205k starting)). Granted, I do think if I went to silicon valley when I graduated, I may have found a better position at a start-up environment. After 10 years of patent litigation, I do find it boring, but at least I am paid well comparatively to my SV engineering friends.
I tried making the original Macintosh OS in Godot and my takeaway was it was really enjoyable to make UIs in a game engine. It would be interesting to see some “avant-garde” movement of making not only games but native apps using game engines.
I was fairly young when these games came out but could someone confirm with me that the first collage of game screenshots are mirrored backwards? They say [bottom to top, left] but it looks like they have it flipped. Like Wolfenstein 3D (left), Hovertank (right) and Quake (left), Doom (right).
Top: Return to Castle Wolfenstein (2001)
Second row, from left: Quake II (1997), Doom (1993)
Third row: Wolfenstein 3D (1992), Hovertank 3D (1991)
Bottom: Dangerous Dave In the Haunted Mansion (1991)
Very much this. It doesnt bode well for the credibility of an article posted on IEEE no less, when random 30 something person can spot 2 errors in 5 seconds after loading the page.
- Bad image order instructions
- Quake should be Quake II
- Hovertank should be Hovertank 3D
- Commander Keen should be Dangerous Dave In the Haunted Mansion
Looks right to me. Right to left, bottom to top is what I read their description as being. One thing wrong is that isn't Quake, but Quake 2 which was released in 1997
They do mention that order, kind of. I guess the problem is that right to left, top to bottom is a fairly maniacal order to put things in without a good reason.
The point he is trying to get at is that in an OO language you take it for granted that all methods can call all other methods. However without such trickery as described in the article this is not true in the simple language with only functions.
It depends from what perspective you come at it, though.
The article makes the case that the "simpler language" is the one where a function can only call another function if it has been declared before. Then, the ability to call any function regardless of declaration would be seen as an addition to that.
But couldn't one make an equally valid case that the "simpler language" is the one where function declaration order is not significant, that unordered is "simpler" than ordered? Then, the availability of a "F was declared before G" relation would be seen as the addition.
After all, the only reason we intuitively feel there is an order to function declarations is because the computer program's representation in source code is linear text. But I'd argue that the more fundamental representation of a computer program is that of a graph. Or at least equally fundamental :) It's just that in practice, computer memory is linear, and so any representation of a graph structure will have an implicit order that we need to tell the computer to ignore. But mathematically this ordering is just a side-effect of computer memory, irrelevant just like whether '1' bits weigh more than '0' bits or not.
That paragraph confused me too, but then I realised what he meant, felt the same as you, but still couldn't think of anything on the spot that would work other than:
set(value) {
count = 0
while count != value {
increment()
}
}
