ezy

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.

"Watson" was a Jeopardy playing bot.

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.

See: Agile

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.