> Does that mean that the admin will have to manage dob of every student when creating accounts ?
That already happens to some extent although the mechanism by which this happens might depend on the school district, etc. The `dateOfBirth` LDAP attribute is probably the most obvious method (which admittedly should probably not be used due to the ease in accessing this info in the default configuration) but there are others.
In secondary school when my account was set up we were told that our initial password (that we had to change on first logon) was our DOB
Programs (this is true for most mainstream operating systems) can become network facing without realizing it. I've sometimes found a bunch of Windows programs sometimes tends to assume that I/O completes "instantly" (even if async I/O has been common on Windows for a very long time) and don't have a good UX for cancelling long running I/O operations
I'm not surprised; you need a lot more servers and even so, there are a lot of places where something low ping times is difficult. While there is a lot of room for latency to go down, 1 lightmillisecond is ~300 km (~186 mi). This means that if a computer is 150 km away, 1 ms is the minimum ping allowed by physics, if I am talking directly to it.
By that yardstick, we've actually done very well in a lot of cases. :)
Others in this subthread discussed the comparison of the complexity of different ways of achieving flight itself, but I think there is an interesting discussion in that... well... we do add senses we don't technically need to achieve stable flight (but are very useful for safe flight and have reduced the incidence of aviation incidents and accidents dramatically).
Whether it be altimeters based on radio[1] or air pressure[2], avoidance and surveillance systems that use radio waves to avoid collisions with other aircraft[3][4], airborne weather radars[5], sensors that measure angle of attack (AoA), GNSS location, attitude, etc, many aircraft (even unpowered gliders!) have some combination of special sensing systems that aren't strictly necessary to take off, fly to a destination, and land, even if some are required for what many would consider safe flight in some scenarios.
Many of these systems have redundancies built in in some form or another and many of these systems are even built into unmanned aerial systems (UASes) big and small.
> And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
Python doesn't use semver and never claimed to do so, but it's probably worth treating "x.y" releases as major versions in their own right (so like 2.7 -> 3.0 is a major version and so 3.10 -> 3.11). If you do that, the versioning makes a bit more sense
I think part of that thinking though is that if you do basic stuff like use a standard database engine or don't go too off the beaten path if that's what you need, it tends to be that you get the ultimately needed scale for basically free.
This is a lot of times what I see the "don't build for huge scale" to be. It's not necessarily "be proud of O(n^2) algorithms". Rather it's more "use Postgres instead of some hyperscale sharded database when you only have 10 million users" because the alternative tends to miss the forest (and oftentimes the scale, ironically) for the trees
Yes, but also I've found that using a decently scalable engine is insufficient for a good outcome without the scaled data.
The best software I've written always had > 10 GB of existing data to work with from day one. So for example the "customers" table didn't have one sample entry, it had one million real entries. The "products" table had a real history of product recalls, renames, category changes over time, special one-off products for big customers, etc...
That's how you find out the reality of the business instead of some idealised textbook scenario.
Things like: Oh, actually, 99% of our product SKUs are one-off specials, but 99% of the user interactivity and sales volume is with the generic off-the-shelf 1% of them, so the UI has to cater for this and database table needs a "tag" on these so that they can be filtered. Then, it turns out the filtering 10 million products down to 100K has non-trivial performance issues when paging through the list. Or even worse, 50% of the products are secret because their mere existence or their name is "insider info" that we don't want our own staff to see. Did I say "staff"? I meant subcontractors, partners, and resellers, all with their own access rules and column-level data masking that needs to be consistent across dozens of tables. Okay, let's start going down the rabbithole of column naming conventions and metadata...
You can't predict that stuff in a vacuum, no human has the foresight needed to "ask the right questions" to figure this all out through workshops or whatever. The ground-truth reality is the best thing, especially up-front during the early phases of development.
A lot of the above is actually easy to implement as a software developer, but hard to change half-way-through a project.
> What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all.
This isn't really correct and many programming language standards (including that of C and C++) don't support this view. Many language standards define a notion of conformance. Strictly conforming programs aren't allowed to invoke behaviors that which are undefined[1].
Conforming programs do not have this requirement and basically any non-trivial C and C++ programs are written to this rather than the notion of "strictly conforming".
Most non-trivial programs are not strictly conforming (including some C compilers themselves), generally because restricting the set of targets to something smaller than "any possible C implementation" is useful.
It is perfectly legal (and very desirable in cases where the standards fall short of usefulness) for a C compiler to define undefined behavior. What you compiled is still a C program, just one that isn't portable across the entire potential set of implementations.
[1]: Or unspecified or implementation-defined, for that matter, but this part tends to get left out of discussions.
The C++ ISO document describes conforming implementations of their language, ie compilers and similar tools - that conformance isn't a property of your program at all.
So far as I can tell there is no mention of the program conformance you're describing.
There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation. In theory you could have an implementation that gives semantics to UB like Fil-C or CCured do. No mainstream implementation does that for memory unsafety due to the performance overhead, and conforming implementations are required to document those extensions. I don't think there's a sane argument for an implementation to intentionally choose the behavior in the example I provided and Clang certainly doesn't, so it's non-conformant regardless.
> No mainstream implementation does that for memory unsafety due to the performance overhead
It depends on what is considered memory safety here (especially when some of them are arguably unforced errors in the standards), but many implementations do in fact have options for this ("no delete null pointer checks" for example is an example of one such option, for example, which is used extensively by the Linux kernel for example).
The performance impact tends to be much more negligible outside of, sometimes contrived, benchmarks, especially when compared to algorithmic efficiencies or the like.
> There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation.
Perhaps it "basically" says that, but it certainly doesn't appear to literally say any such thing, so you're going to need to specify where you believe you saw this so that I can have any idea what it actually says.
A conforming program is one that is acceptable to a conforming implementation.
That definition goes all the way back to C89. The C++ standard drops it for the term "well-formed program", but adds enough clarifications in 1.4 to mean essentially the same thing.
Ah, no. Most C++ programs that compile are not well-formed programs. This functions as an escape hatch for Rice's Theorem. You see, C++ even more so than C has semantic requirements - but Rice says all non-trivial semantic requiremnts are Undecidable. So, if you want what C++ says it wants it appears that compilers would be entirely impossible and that's awkward. To "fix" that C++ says it's fine if the compiler will compile your program even though it is not well-formed, the program doesn't have any meaning of course, only well-formed programs have meaning, but it did compile, so as a programmer you're happy...
C++ has a recurring phrase in its standard document "Ill-formed No Diagnostic Required" or IFNDR which carries this intent. The compiler can't tell you made a mistake, but you didn't actually write a valid C++ program so -shrug-
Because there's no way to tell for sure without exhaustive human examination we don't know for sure how many C++ programs aren't actually well-formed but experts who've thought about it tend to think the answer for large C++ software projects is all or most of them.
The problem is fundamentally the fact that it is a visual based system.
It is generally faster to communicate orally and process communication aurally than by text message when the message is short enough and requires immediate attention. This is also why urgent alarms (such as those provided by the Gound Proximity Warning System (GPWS) or Traffic Collision Avoidance System[1] (TCAS) have such a component). Some stall prevention systems are even partially tactile based (making a pretty unmistakable shaking feeling (it is loud as well)).
It is incredibly slow to type and then process that visual information. In addition, it's also just much more reliable.
For time critical situations, it's not a viable option.
[1]: Yes, TCAS has a visual component and many alarms do too, but the RAs are auditory and give specific, to the point, instructions on what to do ("climb", "descend").
That already happens to some extent although the mechanism by which this happens might depend on the school district, etc. The `dateOfBirth` LDAP attribute is probably the most obvious method (which admittedly should probably not be used due to the ease in accessing this info in the default configuration) but there are others.
In secondary school when my account was set up we were told that our initial password (that we had to change on first logon) was our DOB
reply