This is an interesting point, but I wish the delivery wasn't so snarky. There probably are a number of issue of specialization that I wonder about now; is building bridges in an earthquake zone a solved problem at this point, or does it require additional focus that could justify some of the time and money cost. Similarly, desert ground can move a surprisingly large amount through heat and rain cycles; are similar challenges faced in places like Arizona and Texas for more ground-based infrastructure?
I’ve noticed a recurring theme on iOS where interactions intended for an app get trapped by the OS (especially multi-window interactions on iPad). The OS is less and less a foundation to support what you actually want, and more the product itself. If the actual content of the phones matters less than the fact that iOS itself is “the latest” then this makes perfect sense and is in line with the general momentum over the past several years.
Fully agree with your sentiment, and it was kinda sad to see the demo going there.
"And this is how easy I can replace this custom component with a new glass component...".
The whole thing is just wild.
There was plenty of UX enhancements which looked solid, but just for them to be paired with a design choice of N=1 elements is... well let's see if it pays off I guess?
The government shapes diets both through guidance (food pyramid, “plates”, etc) and regulation. For example, a major criticism revolves around farm bill payouts that incentivize corn production, leading to cheap fructose that finds its way into everything.
As a completely incidental observation (and maybe related to the article from a few days ago considering the importance of language skills compared to math skills for software development), I'm interested in what people choose to capitalize when developing languages. With c, lowercase seems to be the default, signifying variables or function calls. Adding inheritance in c++ leads to Proper Nouns like classes being capitalized, while their instances are often lowercase. This communicates a subtle "feel" for the language, meta information about what's being accomplished.
Capitalizing method calls (`rl.InitWindow()`) seems to place the importance on the Method being called, but at first glance (ASP, or Go off the top of my head) it muddies the waters. If this isn't clear, consider that capitalizing ALL code would reduce clarity as all letter shapes are now essentially the same (a box).
I spend most of my time in c, c++, ruby, and javascript, but maybe I should try to do a personal project in Go (or Odin) for this reason alone.
I believe most of this is language designers picking their personal preference and then that percolating down through history.
The original UNIX folks really love lowercase. Executables are lowercase, most file names are lowercase, file extensions are, etc. That extends to C where DMR and Ken Thompson chose lowercase names for keywords, built-in types, and standard library functions. If I remember right, Thompson uses all lowercase in most of his communications too, so I suspect it comes from him. Or maybe it was a flex because the PDP-11 could do lowercase when some other early computers didn't support it at all?
The early Pascal compilers from Niklaus Wirth and friends appear to be all caps, probably because that's all the machines supported. The language itself generally isn't case sensitive. (I say "generally" because there are many flavors of Pascal.)
When Anders Hejlsberg created Turbo Pascal (which is also case-insensitve), he introduced a convention of lowercase for keywords what we now call PascalCase for function and type names and (judging by the Wikipedia article) a mixture of PascalCase and camelCase for variables.
Perhaps because Straustrup built on C but is a Dane like Hejlsberg, he picked a mix for C++: camelCase function and variable names with PascalCase type names.
These conventions then flowed down through time. Java was heavily inspired by C++ and takes the same convention. C# is another Hejlsberg creation and follows his preferences. JavaScript follows Java. (It must annoy Hejlsberg to no end that his third baby TypeScript breaks with his own convention.)
In this case, I believe the capitalization is a hold-over from raylib's c library, Odin doesn't appear to put any preference?
In Go it has a specific meaning: starting an identifier with a capital causes it to be exported for use in other packages. Identifiers with a starting lowercase char are package private.
Apologies if this is explaining what you already know...
Odin itself does not care what naming conventions you use. Use whatever you prefer.
For Odin native libraries, we usually for the convention of `snake_case` for variables and procedures and `Ada_Case` for types. However for anything that is third-party/foreign, we try to keep to the same convention as the original library to make it easier to people reference the original documentation, as well as not have any of the problems that certain naming conventions cannot be translated to another. So the raylib code uses the original raylib naming conventions because of the reasons I described.
Sticking to an library style is a way to go. It's so much friction to use python library wrappers which try to hammer original style into a snake_case.
Nim has solved this in a very practical way, which works great - case insensitive except 1st letter, and underscore insensitive. So hello_world and helloWorld and hello___wOrlD are the same identifier, though HelloWorld and hello_world are not.
Many people complain that this is horrible, but not people who have actually tried it. It works very well, lets you bridge over differences in C++ library conventions, Unix C conventions and Microsoft conventions in a project that interfaces all of them, without getting users upset. (There’s more to it - consistency for some identifier can be enforced, there’s a smart source reformatted, and more)
snake_case is just more readable overall. PascalCase and/or camelCase are okay in moderation and add a kind of emphasis, which is why e.g. Rust uses PascalCase for types (other than core built-in ones) and enum case constructors. SCREAMING_SNAKE_CASE is ok for even rarer things that should stand out - C/C++ uses it for preprocessor macros, Rust for program constants and global variables. Ada_Case is rare and mostly shows up in languages with case-insensitive identifiers, like Ada itself.
The FAA says that I can't fly closer than 500 ft to a shed in the desert, but a Blackhawk is fine to be within 75 ft of a part 121 airliner in a bravo.
Yeah but the Blackhawk requested visual separation. It shouldn't have, it couldn't tell the difference between the CRJ and any number of lights around it. Anyway, at that point the request was granted and you see how it ended.
I recall the tower establishing that they could maintain visual separation, not a request being made from the helicopter. My point is that if everything had gone perfectly, as little as 75 ft of separation would be provided. This is unacceptable in this context for reasons should have been clear ahead of time, but very unfortunately are made clearer in hindsight.
Let's refresh recollections. TFA: "Shortly after the Black Hawk passed over Washington’s most famous array of cherry trees, an air traffic controller at nearby Ronald Reagan National Airport alerted the crew to a regional passenger jet in its vicinity. The crew acknowledged seeing traffic nearby. One of the pilots then asked for permission to employ a practice called “visual separation.” [...] "Visual separation approved,” the controller replied."
This doesn't really address my point, but the ambiguity arises from the fact that there are often implicit understandings tunneled through standard phraseology that may or may not be intended. We don't know exactly what the Blackhawk crew said. Clearly tower thought they'd be staying clear of the CRJ, but the Blackhawk crew (to some degree) thought they'd be staying clear of some other lights in the area.
Regardless, 91.119 applies (harshly, and unambiguously, in some cases) to significantly safer operations than 75 ft visual separation from passenger aircraft in bravo airspace. That is absurd. Failure was built into the design from the beginning.
What is your point, that 75' isn't enough separation? Of course it's not enough. But you know as well as I do that visual separation is normal, encouraged even. We know pretty clearly what the Blackhawk crew said. They said they had the traffic in sight and requested visual separation from the reported traffic, not from some passive lights on the ground.
Yes indeed, failure was built in to the airspace design.
They could be huge in this, but sadly they'll continue to ruin it because (IMHO) they are rotten at the core. I can't tell you how many times I've seen a question posted on a relevant topic, switched tabs to consult the manual to verify my memory, and then gone back only to see Facebook do its ADHD reload and bury the question.
Once people get sufficiently frustrated and the ad revenue declines below the cost of running the servers, we will immediately lose all of the information shared there. None of it will be archived like the old forums. It's a genuinely sad situation.
> and then gone back only to see Facebook do its ADHD reload and bury the question
Does anyone know why facebook does this? It's the most infuriating thing, like it's assuming the poor user doesn't know how to "refresh" a page so it does it for them, because clearly they got stuck on an old crusty piece of content.
Agreed. It's a matter of degree, and I wonder what reaching the eventual limit (if there is one) looks like.
reply