The funny part, and perhaps the part that really damns the critics, is that (IF..GOTO,) GOTOs and line numbers are useful baseline concepts because they have a direct correspondence to what a computer actually does. People who went from BASIC to assembly language did not experience much cognitive dissonance compared to your average JS programmer. And decades later, computers still work roughly this way under the covers complete with (tests,) jumps and memory addresses. :-)
My first exposure to the innards, from a software perspective, of a computer was a 6809 based system. The first assembly language I learned and the first “real” operating system with multitasking (Microware’s OS-9). I suppose it made an impression— I stuck with Motorola CPUs on my personal computers up to the 68040. :-)
It feels like WWCYO is still a good question, abstractly, to ask though even in cases where you don't think there's a good contrary argument, or don't have the knowledge, or it feels more value based.
For example, if I apply your example question to my beliefs, I don't necessarily come up with any specific answer, because I'm not super well versed in philosophy. It highlights that my belief that I exist might be on shaky ground, or it just might not be testable at all, but I'm open to being convinced otherwise.
And so that's the more abstract answer, which is : if I saw an argument that seemed rational to me, I might be convinced that I don't actually exist, but I'm sticking with what I believe for now. That's all you need -- WWCYO doesn't mean that there is a valid contrary argument, but that you're open to hearing one and changing your views. If the belief is more about experience, of course, you can get more specific about your null hypothesis.
I didn't want to put down the effort of the OP, because even they admit it's an interesting experiment, not something they recommend that anyone use, and I do think it's an interesting experiment. But I have exactly this feeling in general.
I like the idea of Rust, but I feel it has, unfortunately, been taken over by the seductive idea that abstraction is the purpose of a programming language (e.g the C++ crowd, among others). I can say from long experience, that while it probably won't impede its popularity, this isn't real progress in programming language design. These abstractions just create their own problems to solve on top of solving the original problem you wanted to solve by writing a program in the first place.
Inevitably, that means that you end up having to limit yourself to some particular "idiom" or subset of the language in production, so that you can get anything constructive done without the code being inscrutable or unmaintainable or just overblown for the task that's being performed.
I knew it was over when they started debating adding more and more meta-language type system features, and then added async/await -- which is the very definition of creating a problem to solve a problem.
So, as much as I appreciate Rust, I am looking forward a newer systems language with more discipline in its design and direction.
Go isn't perfect, but it definitely trends to the right flavor of simplicity and design discipline.
Most of the article is devoted to complications related to handling arrays that are inline at the tail of existing structs that usually are layout and size sensitive. Hence the related two restrictions that the count variable keep the same name and location in the struct, and there is no explicit array head pointer (just the implicit location at which the array starts at the end of the struct).
The reasoning most likely being that a bunch of annotations to structs, and perhaps some changes to calls to kmalloc() would be less destructive and much simpler than breaking the kernel ABI and altering the base size of any struct that used that idiom while also having to change every for loop or whatnot in the kernel that uses an explicit counter member name.
This is, of course, an argument against a strawman. I wish the author had not mentioned certain folks by name, because the analysis is interesting on its own, and makes some good points about apparent simplicity. However, by mentioning a specific person, and then restating that person's opinion poorly, it does a disservice to the material, and basically it just devolves the whole thing.
My understanding of Jon Blow's argument is not that he is against certain classes of "safe" languages, or even formal verification. It is that software, self-evidently, does not work well -- or at least not as well as it should. And a big reason for that is indeed layers of unnecessary complexity that allow people to pretend they are being thoughtful, but serve no useful purpose in the end. The meta-reason being that there is a distinct lack of care in the industry -- that the kind of meticulousness one would associate with something like formal verification (or more visibly, UI design and performance) isn't present in most software. It is, in fact, this kind of care and dedication that he is arguing for.
His language is an attempt to express that. That said, I'm not so sure it will be successful at it. I have some reservations that are sort of similar to the authors of this piece -- but I do appreciate how it makes an attempt, and I think is successful in certain parts, that I hope others borrow from (and I think some already have).
Yea, I think a lot of programmers confuse the map for the territory. It's not only the data, but the program itself.
Almost no one actually cares how a particular program was written or how it understands it's input and output -- we care that it works with some level of quality. How one gets that result is irrelevant in the end. It could be written directly in twisty assembly code. Do not care[1]
Parts of these paradigms have useful tools for building working programs, but a great majority of the contents of these paradigms are simply about organization. This shows up most clearly in OO, and of course, functions are a way to organize code. This isn't a bad thing -- certainly helpful for humans working on a code base -- but it isn't actually relevant to the task the program itself performs or how fast or well it performs it.
So, of course, the input and output of a program aren't really conformant to any paradigm, because the paradigms are about organizing programs, not about performing a particular task.
[1] (it might even be more reliable, in some cases, because you would be forced to be careful and pay attention and all those little details you want to ignore are right there in your face (see: async) :-))
The elephant in the room is that Apple must already know this is happening. It's not like they need a viral blog article or a user flag uprising to tell them this -- It's been obvious to most technologically saavy users who own iphones -- and it must be 10x as obvious to someone who works at Apple on the actual App Store . They're just choosing to do nothing about it because it's advantageous to them. Period. But what else is new when large sums of money are involved...
That is not a new "Amiga", that's just a nostalgic upgrade to an old Amiga computer.
A new "Amiga" would be something completely different than the old Amiga (which has long been surpassed by PCs with high-end graphics cards) or the current software/hardware model of a PC (which could be improved in many ways if you decided not to be a slave to current hardware and software standards).
I'm not sure what that means, really, because creating something new and useful is a hard (but not impossible) task. It really does take commitment in these days of software that is POSIX everywhere and (graphics) hardware that is sometimes interesting and high performance, but very buggy and effectively, probably intentionally, undocumented.
The main trick behind Watson is to take the various systems (parsers, search, et al.) and hacks (constraints imposed by the rules of jeopardy) needed by a jeopardy playing bot and put them all together.
So, in some sense, you could say UIMA is what Watson did -- because it allowed a lot of flexibility for researchers to combine their efforts. Ranking and filtering becomes of ultimate importance in a system like that because at some point you have to make a decision. However, it is terribly reliant on the other modules at least getting somewhere in the ballpark -- and the ranking is also not, by itself, anything impressive.
So, it's an interesting case of how far you can get by just setting a single goal and slamming everything together -- but as it turns out, for every new domain you wish to apply something like that to, that magic ballpark is hard to reach without a significant amount of engineering & research effort to come up with new systems/hacks combined with a lot of relevant data. In other words, just like any other adhoc AIish system with a particular goal. Change the goal, change the system.
So, of course Watson was oversold, it was a PR and Sales effort from the beginning. Sort of like AlphaGo or DeepBlue -- you might be able to find one or two interesting ideas in the bowels of such a system -- but the system itself is not a generic one.
I get what you are saying, but my impression was that she wasn't dismissing unknown knowledge as intrinsically trivia, just the use of it in a certain context. When you use knowledge as a status marker, it becomes trivia -- because it isn't related to the application of such knowledge.
In the case laid out in the OP, it is a little subtle, but it's really about status games, not the knowledge itself. Otherwise he wouldn't need to make someone feel like shit for not knowing (or remembering) the term.
For example, I will readily admit I had to look it up because I don't use the term often -- I remembered learning it, and vaguely that it was related to the diagonal/determinant, but that was about it. That doesn't make it trivia, but it doesn't make me an idiot either.
So, it's not trivia if one needs to use it, but that's not how the protagonist in the essay used it. You can imagine how differently things would have gone if he kept his judgement to himself, had sharing information as the real goal, and simply explained what the trace was in the context of the conversation without the putdown. It wouldn't be trivia in that context, because it would be relevant to a useful conversation -- not a status cudgel.
I don't think this is correct. I'm not sure there are many people that would argue that C++11 doesn't have lexical closures just because its closures need to take into account the semantics of C++ itself. Anyone who says that, doesn't really understand how C++ is used, frankly.
You said it yourself, if you specify generic close by value, you will get the behavior you want. If you know your closure won't outlive the stuff it closes over, you can capture by ref. If you need some other behavior, you use smart pointers and capture by value or mix and match based on what you're capturing.
Just because C++ doesn't automatically figure it out for you isn't an argument against it having closures, any more than not a having bignum or rational built in means it can't do arithmetic.
My stock response to libertarians: "I'm glad that things have worked out great for you". Before you propose dismantling an existing arrangement that seems to be working just fine, you first have to tell us why the existing arrangement is faulty in a real practical sense. If you can not do that, then leave it the hell alone. We have enough ideologues fucking with things already.
If you have an IQ of 89 or below in a first world country, you might be able to barely complete high school, but are not going to become a math professor.
IQ (g) is normally distributed.
The only hope here is that there is some extrinsic element, similar to nutrition, but as yet undiscovered, that will improve human IQ for those on the left-hand side of the curve in a real way. Otherwise, no, not everyone can contribute in the same way.
Uh, why would residents report dissatisfaction when it would hurt their opportunities down the road? Would you have? I don't think so. I don't think you are being skeptical enough about these "studies".
Honestly, as weird as cygwin can be, I question the judgement of relying on Linux's chief competitor to keep a mock linux kernel interface as well supported as the OS they really care about. Are you really sure that environment will be working in Windows 11... windows 12? etc?
This just seems like a really bad idea compared to simply running a VM and sharing a filesystem using networking or other means... It's not like a modern machine, even a shitty netbook nowadays, can't handle a virtualbox instance, or localhost networking.
The key to rational thought is not just logic and reasoning, because both rely on axioms and information. You need to make sure you're getting the correct data and proceeding from sound foundations. Thats where the skepticism comes in -- double and triple check your sources.
I'm going to be straight here -- what are your sources?
I mean try not to take this too defensively, but you pegged Reagan as a political outsider when arguing for trump. You think an investigation is the same as a conviction. You think that political correctness is the substantive issue difference between HRC and Trump. None of these things are true. In fact, they are so obviously not true that I have to wonder about your rationality.
> it was hard to map the Rust concepts with what actually runs when it is compiled.
This. The primary reason to choose rust is performance -- that is, you want more advanced abstraction/safety capabilities than C++, and you want that with the same or better performance. And performance implies CPU cost and memory usage/layout control. There really isn't any point otherwise.
Therefore, going into at least a little bit of detail on the idioms and performance impact of those idioms is important. Rust is a supposed to be a systems programming language to replace C, do not pretend it's as abstract as ML in the documentation.
What throws me for a loop when learning Rust isn't high level details like the borrow checker or sum types, it's what is happening with cpu & memory[1]. When things are copied, when they aren't, how much do the std derives cost, matching cost, sum type storage cost, etc. Because while the semantics are similar to C++, they are not the same. And you don't have to go nuts specifying it (compilers will differ), but at least give a general understanding/hint of what to do and what to avoid.
To be fair, the doc does have this scattered about, but it doesn't feel a priority (There are many things I've had to search the web for or ask on #rust, or just look at disassembly for).
[1] To take an extremely simple example, RVA is something Rust supposedly does much more consistently than C++, thus returning a new struct by value to be placed wherever is idiomatic. However this isn't called out very clearly (the last time I checked) in the doc, and to a C programmer, it feels very wrong. Stuff like this is extremely important, otherwise we'd just ignore performance and use a JVM based language with the same (or better) abstraction features and a faster compiler. :-)