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.

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. :-)

As someone who is unfamiliar with clojure -- is there any particular reason a function which doesn't actually work with sets allows non-sets to be passed to it in the first place? Or this a deficiency in the type-checking? I mean, truly, this kind of thing seems like a solved problem...

Speaking of the truth: Sterling lost his basketball team because of private recordings of him being a racist, not hearsay. Then he proceeded to dig a deeper hole publicly. That is: a lapel-camera would not have exonerated him.

Here's some advice, since you think you can take it. When striving to correct others: (a) Make sure you're actually correct (b) make sure you're doing it to reach a common goal, rather than to uplift yourself and (c) understand that a defensive reaction is not a weakness, it's an entirely normal human reaction, and try to empathize with the person as you deliver the hard news.

A lot of people think that others don't want to hear the truth, but it's not that. Most people want to know what's going on. What most people don't want to endure is the embarrassment of being wrong in front of someone -- which is an entirely different thing.

People get corrected on stuff all the time and take it in stride. It's when there is a blow to their ego or you're actually wrong that they get upset. So, you need to either make it clear it's not about them in particular (it usually isn't, hence the "common goal"), and even if it is, you need to make sure they know it's about making them better, not tearing them down. And, you have to be willing to consider counter-arguments -- that is, not pretend you are the sole arbiter of truth.

Bluntly stating an uncomfortable truth (or opinion!) with no quarter is not what people who seek the truth do, it is what people who want to be in control do.

"subsubsubsublemma" kind of cracked me up. He seems very dedicated to not numbering the nested schema in this proof. :-)

This is going to sound a little misguided, but bear with me. If you want to see what you're missing: Take a look at the IDEs of the moment. Try something like eclipse on java code or maybe devstudio in the windows world.

In general, vi/emacs are missing support for editing above the level of text (eg. refactoring) and support for UI above the level of a text terminal. I know add-ons exist for both editors that do some of these things, and of course, you can run both in a graphical terminal with custom fonts, etc -- but if one is being honest, it's not very well integrated in either of the old standbys.

I'm a vim user, but not really an advocate. I'm just used to it, I like the way it works (mostly) out of the box[1], and I think it's text editing facilities match the way I edit better. It's a great generic text editor -- as is emacs (for some others, not me). But all they do is understand text...

I had to do some Java development recently. So I tried eclipse (with a vim keymap plugin). Now, eclipse kind of sucks in many ways, but one thing it definitely has is the ability to refactor code. Something like variable rename over multiple files that would have me concocting a sed-ish script for vi, or doing query-search-replace, next,next,next,skip,next in emacs was literally two keystrokes and bang, done. Forget about actually moving language constructs from one file to another or to another package, etc. And the UI for it was very clear: inplace modification, and popping up a warning about where the refactoring would break, if it would.

And then we have modern UI. Eclipse isn't even very pretty (or modern) by modern standards, but it still highlights properties of code (warnings, unused variables, etc) by actually drawing symbols or boxes on the screen rather than attempting to wrangle indications into the world of VT220 terminals. Among other things...

One could put this all making up for deficiencies in Java, I suppose. Except, again, if one is honest, one realizes that this kind of thing is highly useful no matter what language you're developing in...

Neither Vim or Emacs has very good support for any of this at all. There are examples of add-ons that do it kinda-sorta, but they aren't very good. Emacs is better than vim at this, of course[2], but it's still not very common for language support to get to this level. It's not a standard thing, and it should be. Such is history, and the pragmatics are writing a substantial piece of software inside another piece of software in a crappy language :-). Emacs still crappier (and slower) than eclipse at just highlighting syntax (and barely does the highlighting of semantics).

Emacs & vim have real issues as code editors because they are stuck in the past -- and not the recent past either. Vi was never meant to be anything but a text editor, for good or ill. And Emacs... well emacs lives in it's own little world reminiscent of a half-baked lisp machine crossed with a VT220 terminal. And while the capability is there somewhat to do the above, there is a lot of historical baggage and historical code to overcome.

So, is eclipse my editor of choice now? :-) :-P Well, no (except for java code). :-) It's a shitty editor, it's slow to start, it crashes or gets into a funky state too often, and it's really a Java-editor, not a generic text/code/anything editor (although it tries to be, and fails). But I think eclipse and tools like it show clearly "what is missing" in an old-school editor like vim/emacs, or indeed any new editor which uses either of these as a model.

[1] I also think key-chording, which emacs uses (and others influenced by emacs use) is actively physically harmful.

[2] A better scripting language helps. I'm sure emacs is somewhat passable at refactoring lisp code. :-)

One would like to think licensing is about ensuring quality, but if one actually takes a look at the reality, one realizes that licensing is about restricting the field and paying to play, and almost never about ensuring quality.

Even professional licenses are like this, unless you are a complete idiot it's not the knowledge that's the problem (e.g. passing the exam, if there is one), it's paying for the requirements (e.g. the degree and/or the continuing license fee) or fitting the requirements (e.g. being a foreign worker).

I wasn't really referring to wasm vs JS (which is easy to outperform), but reaching equivalent speed to native, which is the ultimate goal, I'd hope. Otherwise you're just throwing performance away...

But, I was a little quick on the trigger. It's not obvious, but after drilling through the design docs for a half hour.. I found a tentative discussion of how SIMD might be added later (based on some kind extension mechanism).

The issue with this is that if you care about speed, you need to be using SIMD -- and wasm doesn't seem to want to support it -- stating a "minimum viable" standard from the year 2000.

You aren't in a position to demand anything.

And, admit it -- you didn't look that hard. In fact, your research was so weak, that you failed to point out additional Cato-published opinions re:lead -- literally in the top google search results for the appropriate terms. Failing to do research when being critical is not anyone else's problem but your own.

If you want to apply your skepticism correctly, the point is to test your own beliefs, not ask everyone else to test theirs. Not just reading from the sources that make you comfortable or attacking easy marks, but reading sources you disagree with, with a generous attitude and thinking about the hard questions related to those.

A lot of the time, you'll find you are correct! And then when someone says something you know is incorrect, you'll actually have something to say, rather than asking them to say it for you. Otherwise, one should not be happy with following a fixed ideology, and you should be happy when people point out flaws -- as no one is happy with a clock that is correct only half the time.

If only there were a technology which was screen and font size agnostic that could display text interspersed with diagrams in various ways including alternative layouts.

One difference, in the 18th century, they cared about the format.

Now if only ebook publishers (a) hired proofreaders (b) could figure out how to properly render diagrams, specialized fonts and pictures such that reading an ebook containing such was anything other than a disappointment.

I thought the "sloppy" era would be over by now as the technology and acceptance increased, but for whatever reason, ebooks still are given lesser priority than printed matter when it comes to editing and layout (and still are kind of a ripoff compared to the printed edition because of that).

I appreciate the work here, and I'll remember this when I need it, but C++ is long past gross.

Enough already, the committee needs to be less prideful and just add complete macros/metaprogramming to the language already in C++14 and let apparently smart programmers who can disentangle variadic type templates to stop wasting brainpower and valuable time doing that and just write the compile-time transformations they want to have happen.