civility

> Once you add preemptive multitasking and memory protection, you're simply going to end up with a normal modern operating system kernel again.

You're missing the point. There is no single file operating system for desktop users (maybe VxWorks or some other embedded OS falls into that category, but those aren't really for desktops). Modern operating systems sprawl all over the disk. Memory protection and multitasking are not large features, and CS undergrads all over the world routinely implement them in less a semester.

> It's possible to run linux from a few megabytes of ram.

A few megs of ram and a directory in /etc filled with startup stuff and config files. Clearly you don't appreciate it, but there was something really nice about being in the root directory and seeing only command.com and config.sys. The entire rest of the machine was yours to setup however you liked. The things most people hated about DOS really had more to do with the 16 bit address space and segmented architecture.

I always wondered what the world would be like if Microsoft had just made a 32 bit DOS instead of going down the WinNT/95 route. Most of the headache in config.sys and friends was because you were working around the 16 bit address space. However, there was something really nice about owning your entire machine and only needing command.com for the "operating system". Compare this to full operating systems which consume gigabytes of disk and memory.

This hypothetical 32 bit DOS could've had memory protection and multitasking too. Obviously device drivers would add complexity, but it doesn't need to be as complex as it's become.

This just defers the optimization process by one step. It's hard to improve something without measuring it first, but either you know where your inner loop is or the profiler tells you. Now you've still got to improve that bottleneck somehow and take into account all those complicating factors.

I've seen very unexpected results doing this. In one case, I put the inner loop in a separate function to enable swapping implementations and make it simpler to time. Surprisingly, the overall program ran faster without any other changes. Just pulling the inner loop into a function of its own sped things up.

My best guess was that the compiler was willing to put more effort into optimization on the smaller function. This contradicts common wisdom about function call overhead, and it also shows another level of complexity in the problem: Some compiler optimizations are exponential in their cost, so they punt if you put too much of your code in one block or function.

Also note that I wasn't able to prove this is what happened. It's just my best guess based on what I was able to see and infer.

Yes, and it's also complicated by the translation to micro-ops with out of order dispatch and instruction retirement. I remember seeing one statement saying this is now a complicated enough system that the number of cycles it takes to execute a block of code is literally chaotic in the sense that small changes to initial conditions cause large changes in the number of cycles to complete. A butterfly effect, possibly triggered by whatever the kernel chose to do a millisecond before your code runs.

Throw in changing clock rates based on the temperature of the CPU. If your code efficiently uses the ALUs / cores in the processor, it can get hot and slow itself down.

There is a nice diagram on this page:

    http://www1.lsbu.ac.uk/water/water_phase_diagram.html

I see your point, but the syntax inside of fstrings forms an entirely new sub-language (DSL). I can look at old python and know exactly how the .format() calls parse with positional and named keyword arguments, but looking at the fstrings I need to be familiar with all of the new magic.

I've heard similar complaints about the loop macro in Common Lisp, and this feels a bit like shell or Tcl strings which could mean anything (arguments to sed/awk or paths to widgets/urls). However, I guess people are familiar with regular expressions as a completely foreign nested language (DSL), so this isn't much different than that.

I'm not sure how much the rules vary, but in our case there were 18 candidate jurors and both sides were allowed to dismiss 3 without cause or justification. Additionally, if either side could argue there was a cause, additional jurors could be dismissed (requiring new jurors to be summoned), but that didn't happen. The plaintiffs removed the 3 with any college at all.

> Luckily, lay people are qualified to make those judgments. Whenever I have seen an actual jury at work, I have consistently been impressed by the degree to which folks can absorb the information presented at trial.

Having been through a jury trial for patent infringement, I saw nothing of the sort. My company was defending, and the plaintiffs dismissed every juror who had anything more than a high school degree. They were incapable of understanding any nuance in the engineering or math, and so they sided for the home team (the plaintiffs managed to get jurisdiction in their home town).

If you like, call it sour grapes because my company was on the losing side, but I think the majority of jurors are completely unequipped to understand basic science, mathematics, engineering, software, medicine, or technology.

> You cant lower costs in the US without having a more aggressive regulatory body which 50% of political bodies strongly oppose alongside lobbying efforts

Here is the fundamental problem from my point of view. Compare human medical costs to veterinary costs. Yes, people expect a slightly higher standard for themselves than they do their animals, but you can get a major knee surgery for your dog for a small fraction of what they charge for humans. The process is performed in a sterile environment by professionals in either case. We're smarter than animals on average, but our bodies and medical needs aren't vastly different.

The problem is price gouging because the providers and insurance companies know we have no real ability to shop around. They conspire with each other to publish false rates when the true costs are much lower after you agree to them.

You could maybe solve this with regulation on prices (a socialist approach), but you could also solve it by mandating they advertise true prices and re-enable competition (a capitalist approach). Either way could fix this, and the problem is corruption (lobbying) not party ideology.

> How many files are you talking about?

The numbers won't seem significant by today's standards. In the one case (stored by date), maybe 150 thousand files, each a few megabytes.

> you can copy a single 10 GB file to another drive faster than 1 million files totaling 1 GB

True, but I'll bet you can create (or read) a thousand files with a thousand records each faster than you can insert (or select) a million records into (or from) a SQLite table.

> The other option above was [...] millions of small files stored on the filesystem

I don't have any direct comparisons of SQLite to this approach, but other projects I've worked on did have a simple directory tree organizing medium size chunks of data by date over 20+ years. We had one "DB" where everything was stored by the degree of latitude and longitude it fell into, and another where things were stored by date. Both were gigabytes in size at a time when that was considered a large data set, and it was very fast to open only what you needed.

Depending on the problem, this can be a very good solution. It was trivially accessible from any programming language (including ones that didn't exist when the DB was started), and it was trivial to migrate to new operating systems (some of this started out on VMS).

I like SQLite quite a bit, but it's not always the best solution to storing tabular/relational data.

I don't work for that company any more, and I couldn't have legally showed the code even if I did.

It's not an index thing though. Try inserting 10 million rows into a simple table. No foreign constraints or anything. Some of our "documents" had 300 million rows. Handle the primary key however you want (let the DB do it, or generate your own). Use whatever SQLite API calls you want (precompiled statements, whatever). In a case like this, adding other indexes can only slow it down.

There are a few options to disable integrity and other safety constraints. They help speed things up a little, but it's all painfully slow in comparison to a writing simple CSV file.

The same is true on reading. You can parse an entire CSV file more quickly than "SELECT *" from the table.

I've tried several time to use SQLite as a document file format. It performs worse than CSV and JSON. It performs much worse than just an array of binary records. The devil is in the details, and assuming each file is not a single row/record, I wouldn't be surprised if 10+ million files in a structured directory tree performs better too.

You should benchmark SQLite before recommending it like this (for future reference). I think it's a very elegant library, and I admire the development philosophy that went into it. However, every time I've tried to use it for something that needs to be fast it ended up being a painful mistake.

Heh, I think stable sorts are great. However, you don't always need one, and you do pay a little bit for it.

> Do you have any evidence for this?

Of course I can't comment on all judges, but in my few interactions with them, the court sides with the police. Call it an anecdote if you want, but "citation needed" comments wear thin.

> But why does that affects your decision to lock your phone? Are you worried police are going to illegally compel a fingerprint from you and then put something on your phone?

I worry about every interaction with a police officer. They are the single biggest threat I ever run into.

> A single night of 4 hours sleep, followed by a year of normal nights sleep will lead to a me that is indistinguishable from the me that slept 8 hours that same night. [...] I'm all for sleeping properly, but lets not suggest that it is the end of the world any time someone doesn't get their standard n hours

I think of it kind of like burning yourself on a flame. Yes, a second degree burn will heal, and in a year you won't notice it, but if you do it over and over, or really burn yourself, you'll scar or kill nerves and never fully recover.

You do actual damage to your brain when you don't sleep enough, and it will effect your memory and cognition permanently if you do it too much.

Also no mention of introsort (C++ std::sort), where it uses insertion sort for small arrays, detects if it's fallen too far towards O(n^2) of quicksort, and punts to heapsort when it needs to.

> When you're pulled over for a traffic stop, a search requires probable cause.

That's the theory. In practice police can get away with pretty much anything, and if you make it to the point where a judge is listening to you, he/she won't be sympathetic.

You've seen the videos where the idiot cop didn't realize his camera was on and filmed himself placing drugs? This didn't just happen once.

> I think this view disrespects history a little.

I love C, but I'm hard pressed to think of any language other than assembly which is more willing to get out your way if you so much as nudge in an undisciplined direction. C certainly does not impose much discipline on programmers, but it allows them to bring some if they walk the line.

> Okay the language still has goto, hopefully we can agree to not make a big deal out of that.

> It's obviously easy to blow all sorts of holes in C's type system

Yes, I'm willing to politely ignore evidence which refutes your point. I mean you were kind enough to make my case for me. :-)

> I'd ask you to try teaching C to a room full of compsci students who have been raised on something like Python.

Dynamic vs static typing seems orthogonal to what we're talking about here, but maybe I'd have to think about that more. Python just waits to catch your type errors until runtime. Comparing that to JavaScript in a browser which silently ignores your errors (or happily performs crazy type conversions), Python seems disciplined in comparison.

FP is different things to different people. For me, it's pure functions and a preference for purely functional data scructures (Okasaki style).

Also to me, FP has an emphasis on avoiding mutating state. The second example on the React front page shows how to mutate state, and then they just build from there. I don't use React, but looking at those examples, it all looks very OO to me.

In this context, C and JavaScript would not be considered functional. They have functions, but that's not what most people mean by "functional". While it's possible to restrict yourself to a functional subset in both of them, they would typically fall into the "imperative" category.

Imperative programming languages (like C and JavaScript) don't generally impose any discipline on the users.

Motion in Vi is based on treating the home row of the keyboard as arrow keys. H, J, K, and L are left, down, up, and right. They aren't mnemonics, and so scrambling them around (Dvorak) is just doubly confusing.

Funny you ask. While you were writing, I posted about a friend of mine who did that in a sibling message.

I have a friend who used to use Vi(m) with his Dvorak keyboard at home, and Emacs with his qwerty keyboard at work. He considered it an exercise for keeping his brain sharp. I don't think he still does it, but maybe.

Vim on Dvorak is insane, imho.

I doubt this works. Stock and property prices would rise as more cash becomes available, so only people who keep their funds uninvested would lose value. It would also be easy enough to invest in a foreign currency.

It seems like rapid inflation would really only hurt the poor and middle class.

Compilers don't have to be slow to generate good code (at least not as slow as Rust). If you prefer them slow, you're just choosing to be ineffective like some idiotic martyr. Suffering for it's own sake is just stupid.

It's very weird you have the presentation of an impudent 20 year old but you share an irrational preference for Fortran, which is something I'm only used to seeing in people who are past their mid 50s.

"Move along"? You're very full of yourself, and I think that explains why you aren't as smart as you think you are.

That's not a discussion or dialog. Sharing what you know is only half the motive. Seeing the responses and learning something new is the other half.

When you already know what the response is likely to be (because most people are pandering for karma), it's just as pointless.

You really think it's just me? Take care.

> Benchmarks are meaningless.

Random anecdotes are meaningless. I've looked at plenty of generated code, and I've written plenty of SIMD assembly too. If you can't measure it, you can't compare it or improve it. There's nothing to discuss.