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