zhxshen

If you look at recent layoff numbers, their coastal brethren will be joining them soon. It's America! One man copes with food, another with money, another with sex. You are all degenerate!

Not just readability; trade-offs in every conceivable dimension: time efficiency, memory efficiency, developer efficiency, readability, maintainability, correctness, etc, etc...

Adopting the features he values is not free. A toll would be paid along a different axis.

I'd approximate my use as an 80%-20% split, in the terminal's favor. I don't use a terminal browser, because I am not a sadist, but outside of that, it is all text in glorious monospace. But as atemerev stated, I am also an independent consultant, so I am under no compulsion to have a Slack or Teams tab open at all times for "massa" to give me my pickin' orders.

The combinatorics of full-text search are astronomical. A dashed-off comparison like this is pure noise. There are so many knobs to twiddle, and a nudge to any one of them can yield remarkably different results.

HN is written in Arc, which is a lisp derivative that runs on top of Racket, which has the same runtime inspectability as almost every other lisp, and for PG's public relations board, it was a good choice.

Rusher is full of s** though. It isn't really a case of, "this one was ahead of it's time, this one's behind". It is a case of trade-offs. I can dash off all kinds of cool stuff in Racket or Clojure, in record time w/ minimal lines of code. Good luck getting someone else to understand it though, and good luck getting me to understand it after a year away from it. With a larger code base, built-in compile-time type enforcements are huge--and as an afterthought, with macros, on an opt-in basis does not count. Aaron Swartz had Reddit re-written from lisp to python for similar reasons--not strict types, obviously, but having more syntax than parentheses is a big win when new hires are trying to understand the system.

Same story with APL: brilliant as a desk calculator on steroids, clumsy for nearly everything else. Or C, the indispensable bit-twiddling language; only a sadist would want to write an application in it, but it's still pretty darn indispensable for the tight spots where performance matters (drivers, AAA video games, AI maths, crypto, etc). I'd say that all the way up until the late 80s, all of the spots were "tight spots."

It's like the Bret Victor cult--a demo of a game-maker program that used javascript as its intermediate representation. It had been done hundreds of times before with different IRs, and the model is entirely appropriate for making 2D video games. Raise the dimensionality, or change the problem, and the model breaks down, but he conveniently ignored that, because it is more fun to get up on the podium and play programming prophet than to do the work of making a language that actually has legs.

It's like three steps--four if you count the verification.

https://go.dev/doc/install

Oi, you gotta loicense for that guv'nah?

https://preview.redd.it/mmksakh888t21.jpg?auto=webp&s=f4dc90...

daniel-cussen's excellent comment on this story:

https://news.ycombinator.com/item?id=32999671

Best comment I've ever read on this awful site.

Under present circumstances, I believe the Germans have much bigger fish to fry, and possibly no fuel to fry them with.

peak hackernews: the best answer is at the bottom

All of these have been around for a long time, but just like well-maintained software, 7 years worth of incremental improvements add up:

https://en.wikipedia.org/wiki/Superscalar_processor

https://en.wikipedia.org/wiki/Pipeline_(computing)

https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...

https://en.wikipedia.org/wiki/Branch_predictor

https://en.wikipedia.org/wiki/Speculative_execution

https://en.wikipedia.org/wiki/Multi-core_processor

Since RAM (slow) and/or cache access is involved in nearly every step--which becomes increasingly complicated when trying to preserve cache coherency across multiple cores--improvements in the next two are a big deal:

https://en.wikipedia.org/wiki/Memory_management_unit

https://en.wikipedia.org/wiki/Cache_hierarchy

Executive summary: Work smarter, not harder, & the ultimate measure of performance, is performance (which may sound stupid, but it's in the textbook, because it's true!).

I would also add that more cores aren't necessarily better. The utility depends upon the nature of the task & how memory-hungry it is. If the task is inescapably sequential, it doesn't really matter how many cores are on the die. Same story with parallelizable tasks that pound RAM: at any given time, one core is hogging the memory bus, and the rest are waiting their turn. They may take turns, but at any point in time, it's essentially single-core performance.

The place where multi-core really shines is when you have a highly parallelizable task, where each thread grinds really hard over a smallish data set that fits comfortably in the core's cache. In that case, you can definitely max out all cores. Though from what I see in the wild, that is a rare case.

A lot of the industry is really just gaming benchmarks at this point, which are, for the most part, bullshit. I think Apple will remain in very good shape on this front, if only because of their customers (i.e. normies instead of gamers; people who haven't fallen completely into the quantity cult). They will complain when it stops feeling fast (the only measure...), instead of taking it as a challenge & wasting their lives on overclocked water-cooling bullshit.

This puts me in the mood for a Diet Shasta.

Didn't tell him to write one from scratch. Just suggested boning-up on the lingo: grammars, tokens, lexing, parsing, etc. An understanding of the first 2-3 chapters would be more than sufficient.

Getting a firm grasp on such things made every language I deal with "click". Knowing how the sausage is made--if only at the kindergarten field-trip level--brings all of the trade-offs language designers have to make into relief. With this knowledge, you'll know where the sharp corners are to begin with--the ones that were unavoidable due to the limitations of the medium. This is much better than beating one's head against the wall over a syntax error while being pissed at the language for not being a miracle.

There are plugins for vim/emacs/vscode to aggressively lint/highlight various errors as you type and/or save.

Since two of the languages you've mentioned are compiled, they should be giving you specific line/column/error information on syntax errors. If it's taking you a day to de-cipher explicit error reports from the compiler, it's probably time to better familiarize yourself with compiler lingo (most people recommend "the dragon book").

Here's Ralph (Baric) giving us market tips for the next pandemic (discusses coronaviruses earlier in the video):

https://youtu.be/UuERPvBFfco?t=1944

Bush made the agency, & now budgets must be justified. With a lull in terrorism, they'll either have to fund new terrorisms (i.e. CIA funds making their way to ISIS[0]), or define it downward (like dropping the N-word in call of duty).

[0] https://en.wikipedia.org/wiki/Timber_Sycamore

Dzhanibekov effect / tennis racket theorem. The flippening is nigh!

https://www.youtube.com/watch?v=1x5UiwEEvpQ

I use aerc, which is similar to this, but written in Go. Most of these TUI mail clients have a configurable filter option for different MIME types. I've found that this program does a great job as an HTML to text filter:

https://github.com/jaytaylor/html2text

I think the classic approach is to use something like lynx or w3m with networking disabled, but I wasn't impressed with the output.

I am not a lawyer, but if this puts the screws to social media, it is a beautiful thing.

> because the spec is a little complicated

Patching over the old work--hopefully without breaking anything--always is. I'm just stating that much of the hostility toward C++ comes from the fact that we have so many superior options to choose from now--options which profited from the lessons C++ learned the hard way, and incorporated them into v1 instead of patching them in as options at v23.

And this is not to strikeforce anyone with a "Rewrite it in Rust!", but to suggest that C++ is maybe not the best choice for new work in 2022.

The text-include compilation model is broken, larger projects pay dearly for this, and thanks to C++'s very long history & very long feature list, there is a veritable Babel of feature subsets & compiler opts to choose from. Adding new dialects and features is not an improvement here.

This is beautifully typeset.

We had a guy from toptal for a while. He was okay, but nothing extraordinary. The odd thing is that nearly everyone they sent our way was of Eastern European extraction, with a demeanor & grooming more military than nerd, which I found most peculiar.

"The Unix Programming Environment" by Kernighan & Pike

> the frictions (e.g legal fees, time, access) prevent small everyday externalities from being reasonably addressable

Small infractions by small operators, perhaps so. Small infractions by big operators, hell no. Thanks to class action, civil suits are perpetual hearburn & lost sleep for them. There's always a batch of aggressive trial lawyers ready to take the case on contingency, and even if the original plaintiff's damages are very small, it still adds up to big money when you include payouts to the rest of the class, & of course, punitive damages--which can exceed the damages by orders of magnitude.

> It also would rely on a judiciary that can't be bought

Buying off judges and juries is a costlier & dangerously more sensitive task than promising a comfy board position to an agency head over drinks and a meal at a restaurant in DC.

> It hasn't failed.

The microplastics in our bloodstreams and the glyphosate in our cheerios say otherwise.