F-0X

array.includes(x) is really a function includes(array, x), and this is O(n,1).

> And it hit me that it's actually O(n), because we've got an array and have to iterate over every element to see if the element matches char.

No, it's actually O(1). n refers to the _input_, which is always a single character. The iteration over an array (fixed at 5 elements) means a maximum of 5 comparisons. O(isVowel) = 5.

> And the old "I have suffered therefore the others have to suffer".

Actually, its an extremely important point. Tools which optimise for the professional are better than those which do so for the noob. Whenever you can achieve both, do so, but never side with the beginner otherwise. People should learn their tools, and they shouldn't be beginners for long, so making things "friendly" at the cost of rewarding expertise is poor design.

> You can ease the cognitive load by making certain programming structures first-class citizens in the language.

Which, in every s-expression based language I'm aware of, can be achieved using macros.

The major examples are parts of the stdlib which offer higher-level pipelines (some answers here indicate the need for such things to be very flexible in their return values to allow this, but this is not a priori obvious - Java manages similar functionality with just the Stream<T> class after all).

In this (and the sibling pages in algorithm) nearly every entry is listed as either "template" or "auto" relhttps://dlang.org/phobos/std_algorithm_iteration.html

One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking at what the compiler complains about.

And that's a huge shame. Because in general I really liked using D.

My personal anecdatal arguement against "Hard to parse for humans" is... I actually really like generics residing within <>. It's actually harder for me to read generics denoted otherwise (D uses parentheses)

As for the last paragraph, I'd implore language implementors to continue using < > lest we get that awfully ambigous nonsense.

Within my first year of professional development, I encountered several fixed-width files I needed to read and write. I suppose exposure depends a lot on the specific industry.

> I had to parse 9million lines.

Awk would chew through that no problem.

> Some of which contain "quoted records", others, same column, are unquoted.

In which case, there is the FPAT variable which can be used to define what a field is. FPAT="\"[^\"]\"|[^,]", which means "stuff between quotes, or things that are not commas", would probably have worked for you. (EDIT: Looks like formatting has gotten hold of my FPAT and I don't know how to stop it... hopefully it is still clear where asterisks should be)

> Some contain comma's, in the fields, most don't. CSV is like that: more like a guideline than actual sense.

Well, I would say that's absolutely false. You can't just put the delimiter wherever you fancy and call it a well-formed file. Quoting exists for the unfortunate cases your data includes the delimiting character (ideally the author would have the sense to use a more suitable character, like a tab).

This is just a retort to prevent your post from dissuading readers from awk, which is a fantastic tool. If you actually sit for half and hour and learn it rather than google to cobble together code that works, it is wonderful. I also don't think it is valid to base your judgement of a tool on what was apparently garbage data.

Just want to throw D into the ring as a candidate here. It's a smashing language. I think it satisfies the very compromise you are seeking from your evaluations of other languages.

I think I am going to side with VW on this. I have always been skeptical of fully autonomous vehicles, and I do not believe they will _ever_ exist on the roads that currently stand. Driving safely in all conditions without aid from a human is simply too complex a task for code that can be audited and verified. If some AI model that's been trained on a billion years of driving experience shows promise, but it is some incomprehensible black box of weights, I won't be getting in that car.

Autonomous vehicles will only ever truly exist upon infrastructure literally designed to aid them, greatly simplifying how they need to interact with the environment, thus making the problem tractable with code we can prove works. I really think it will take more than putting markings on existing roads. It is going to take new roads full stop, probably with various wireless checkpoints built into them.

I think C has better syntax than Rust, by miles. Rust's syntax is the bastard child of C++ and OCaml and is more than the sum of its parts. Rust code having fewer bugs has absolutely nothing to do with its syntax.

> disk space is mostly free these days.

This is the only "argument" ever presented, and I don't think it is any good. I care about file sizes. I want to get the most out of my hardware. Not needing to buy another drive is always going to be cheaper for me and every other user.

Here's one maybe-reason and one definitely-reason VSCode cannot replace vim for me:

1) Logs are often compressed. Can VSCode open .gz files? Vim behaves pleasingly unixy: 'zcat logs.gz | vim -' opens the file pretty quickly in vim. No fuss with explicit de/recompression. This also ties in to the usual "but ssh" argument, since of course you're likely to be getting logs on remote machines.

2) Bash pipelines are usually an iterative affair. It has some tricks in place to mitigate the issues of very long commands. C-x C-e will open vim to allow you to enter a command, and fc will open vim with the previously executed command already there (short for fix command).

Lastly, vim has an expansive collections of extensions. So much so that if vim is ever "not enough", then neither is VSCode, and I should just use a full IDE.

I don't think it does. People share information and learn from each other. Hence, it is important to be responsible when providing information. We frequently see disclaimers on HN, Reddit, etc. like "IANAL", so as to put forward a point of view while warning it shouldn't be taken too seriously as actionable advice. It's the sensible thing to do.

Anybody spreading anti-vaccination propaganda has been convinced of it themselves.

Is it?

If A says to B, "don't vaccinate your kids", B complies, and then B's child dies of a disease it could have been vaccinated against, you would not say A had any culpability?

Would be a big improvement on Rust.

Money is not as wierd as anyone might guess. I work on a financial application, and money is almost always just a BigDecimal with the scale set to 2 (and stored in a database as a bigint type or equivalent). When its not, its just a higher scale (for say, compound daily interest on small amounts for a significant period of time).

AlphaZero does not "smash" Stockfish. In official games they draw 90+% of the time, and stockfish won a non-negligible number of games. AZ is still the "winner" but honestly it didnt seem like a massive leap forward to me.

Though I do still agree in thinking there is likely a deeper theory yet uncovered.

> the rare ability to identify a musical note like F# just by hearing it, can be a massive benefit to a musician

It can also be a curse. I've known a number of people with perfect pitch. Those who were pianists typically insisted on playing only electric pianos, because a typical mechanical piano that's not in a performance hall is probably not tuned until "regular" listeners can tell it is out, but it could be out enough to make it unplayable to a performer with perfect pitch.

Another thing I noticed which I thought was surprising - they weren't notably better composers despite their "better understanding" of pitch.

> No, emojis are incredibly expressive and enrich all forms of writing.

I certainly find many (almost all?) highly ambiguous, which is the total opposite of expressive in my opinion.

I'm aware I will sound "old man shouts at cloud" to some, but if you need emojis to express yourself, you are lacking language skills.

Interesting analogy, but it's a little off.

The main reason modules are interesting is not as a generalisation of vector spaces, but because they are helpful in studying rings. Kernels of ring homomorphisms are ideals, which in general are not subrings, but they are modules - and of course every ring is a module over itself. So to study a ring R it pays off to instead study R-modules, since working with them is... you guessed it! Simpler.

Great articles for when you want to know how it works but want the code to play hard to get.

Rust macros can do worse things than C macros can. They can execute arbitrary code at compile time.

> It takes effort to not use electron.

Why do you believe this? I don't think it is quite that ubiquitous.

>Elon Musk will be this generations' Edison.

I hope you mean this in the literal sense, in that they are both people who have taken the scientific contributions of others for their own businesses, and somehow get the credit for work they never did.

>Like, if I type a math formula or "what's the population of Alberta", the Google result is just the number, not a link to the result.

I prefer to use WolframAlpha for such things.

>So... Yes, these are both (special cases of) magmas, but the general term used for them is "algebra" or "algebraic structure". Don't you agree?

Algebraic stucture, sure, but _algebra_, absolutely not.

An algebra is a module with a compatible multiplication which has an identity element. If I had a magma and you asked about my "algebra" I would be very confused about where you were seeing all the extra structure.

The proof prover proves the proof, but who shall prove the proof prover?

Considering that Windows 95 powered many people's first exposure to computers, they clearly had to put a lot of thought into user experience. And they did a fantastic job.

I definitely believe almost everything since has been "innovation" for the sake of "progress", regardless of whether it was really better or not. Usually novel but worse.