ghettoimp

> Biphasic and triphasic are actually pretty normal, historically.

Is there evidence of this? I'm not doubting - I think I've seen this suggested before. I just don't know how people figured this out?

I of course agree completely that a journalist should be open minded, aware of their own bias, conduct thorough research, interview knowledgeable people, and all of that. At the end of this process they are ideally quite an expert in whatever they are writing about.

But I'm not sure I see why journalists should try to be strictly objective. A journalist is in a unique position to identify the BS, provide analysis and context, and help the reader understand what to make of the competing narratives.

I really enjoyed, and highly recommend, a recent podcast on this subject: http://www.sceneonradio.org/s4-e11-more-truth/

That is a pretty wild Wikipedia page.

I thing "government intervention" is too nuanced and expansive of a concept to meaningfully debate as if it were one thing.

It would include at least:

Police-state policies. Examples: laws against voluntary drug use, policies like stop-and-frisk, our incarceration rate, restrictions on contraception, etc., seem particularly in your face. Historically, the military draft. I'd oppose these.

Basic public-safety policies. Examples: Laws like speed limits, or driving while intoxicated, or some limits on gun ownership (e.g., folks with a history of violence shouldn't have machine guns). These will always annoy some people, but I'd support most of this.

Environmental and business regulations. These really make some folks mad. But I'm strongly in favor of clean air and water, solvent banks, safe working conditions, etc., and think regulations here are really important.

Social policies. Many people were/are violently opposed to school integration, affirmative action, gay marriage, etc. But I think we have a moral imperative to view and treat { blacks, women, gays, jews, ... } as real people, and history has shown that we won't do this on our own.

I certainly can see some cases where there are overlap between these. Example: government needed an army to enforce school integration. But, mostly mostly these are orthogonal, and lumping these into one "big government" bucket just makes it a muddy issue.

I could be wrong.

I might be one of these people?

I want a government that trusts us and respects our rights (e.g., non police state) and that helps to provide for the poor and vulnerable (e.g., healthcare).

I don't see any conflict between these goals. Our medicare providers are not flying drones and kneeling on necks.

This is completely fair and is absolutely a very real thing for many people. But only about 19% of the US population lives in rural areas, for some definition [1] of rural.

Unlike rural areas, cities are dense enough that we could certainly choose to build them in a different way, so that we are not all completely dependent on our cars to go anywhere. For a lot of folks, I think it's definitely a discussion worth having.

[1] https://www.census.gov/newsroom/press-releases/2016/cb16-210...

The "all things are nails, always use hammers" mentality is almost explicitly what I am arguing against.

My mention of SQL was particularly deliberate. It's an especially successful high level declarative language with clear semantics. Implementations provide sophisticated execution engines for optimizing and efficiently running queries. It is quite a lovely separation of concerns that gives you great flexibility and good performance.

Obviously SQL would be a disastrous choice for, say, storing the pixel data in your video codec. Meanwhile, hand-coded C data structures and algorithms would be a disastrous choice for an inventory management system. Tradeoffs everywhere.

I strongly disagree with the idea that lower level is better.

Yes, lower-level languages allow for programs with good performance, small executables, and so forth. There are many domains where they are clearly the way to go.

But higher-level languages allow for better safety, tremendous productivity, portability, exploration, and flexibility.

If you keep your data in an SQL database and you can easily query and update it in any number of ways that you didn't initially realize you wanted. If you instead keep it in hand-crafted C structs, you can probably provide awesome performance. for whatever you originally thought you needed. Once your needs go outside of that box, you'll have to spend significant development effort.

The correct choice depends almost entirely on the domain.

> Where is the anger when people try to set speed records on boats?

These do not seem to be remotely comparable.

Wikipedia has a list [1] of several people that died in water speed record attempts. This list does has several names on it. This pales in comparison with the 36,000 people [2] died in auto-collisions in just the US in 2018.

Driving 100mph+ on public roads is completely reckless. If you fuck it up, someone's going to die.

[1] https://en.wikipedia.org/wiki/List_of_fatal_accidents_in_mot...

[2] https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in...

So... yeah.

I log into FB about once a day and see some pictures of friends who live far away and their children. Sometimes people post funny things. A couple of friends occasionally post interesting or thought provoking articles. My experience as a user is almost entirely positive.

Meanwhile at some level I know it can and is being used in abusive and bad ways. Cyber-bullying, sure. The ever-present outrage machine, pitting the God-loving Americans against the God-hating ones, certainly thrives there. And I once read something or other about enabling horrible hate crimes in Myanmar. And the company itself seems to be a scandal factory, bent on a kind of dystopian mission of collecting data on everyone.

I do struggle a bit with how much to blame the company versus, well, the people who are misusing it. I think a constant lesson of this whole internet thing has been: you can develop the most utterly amazing tools ever, but at least some of your users will take them and use them to be absolute shits.

I think you're slightly confused about the kind of racism being discussed.

You rightly point out that there has been tremendous exploitation of (for instance) Africa by Europe, and that a lot of this exploitation has been justified by racism.

But separately from that, consider the question: why were Europeans able to do this to Africans in the first place?

If you asked question back in the Nazi regime, you'd probably get answers like, "Europeans are somehow inherently racially superior to Africans, and this superiority allowed them to become dominant."

Guns, Germs, and Steel lays out a different and detailed explanation. The author is quite aware of this history of racist explanations. He provides a competing theory, backed by considerable research and evidence. I found it quite good, but also very dry. :)

This is probably just a matter of how one defines "family".

On one level there's my "real", immediate family (my spouse, my children). On another level there's my "real" extended family (parents, other blood relatives). On yet another level there's my "adopted" family (close friends, their children, etc.)

It's pretty easy to see certain coworkers moving into the adopted family category.

I'm no doctor. I just tried to research the COVID death rate and I found a lot of conflicting and nuanced information. My impression is that if you want to make claims around this, you should cite sources. Unfortunately the best articles I found on this were somewhat dated. I don't think I can offer either correction or rebuttal.

I think we can agree that there is a significant cost to having folks not work. As I read it, TFA is mainly pointing out the significant conflict of interest here. Big business owners have big incentives to get production back on track, but face little risk from the disease. Workers need money, but will also be the ones who will face the risks.

I am very skeptical. This state-machine approach seems much more like an implementation than a specification. Having a reference implementation could certainly be a good thing, but this doesn't even look like something one could run and test against.

The declarative form of Comment, above, is wonderfully concise and clear when compared to these several lines of imperative, update-this/goto-there style alternative. You can see in your head what it should match without mentally simulating these specific instructions against some imagined parser state.

There certainly can be a host of terrible issues with BNF-style grammars. When they're just used as a notation to write down a bunch of rules, with no regard to actually implementing these rules, the result can be a sprawling and terribly ambiguous mess. For instance, this[1] is an abject disaster, chock full of ambiguity and senseless distinctions.

But if one is prepared to take the effort to really write a machine-readable grammar like this[2], the result is a straightforward, high-level, concise spec that can be compiled into an implementation to boot. What's not to like?

[1] http://sven.xtreme-eda.com/ [2] https://docs.python.org/3/reference/grammar.html

"Cheating" implies something sinister. Far more likely, they just missed it.

Modern CPUs are at the very edge of what humans can design and build. Hundreds of verification engineers try to make sure they work. Not one of them will have a whole picture of the entire machine in their head, or really understand all of its requirements. The very best, hardest working, most diligent and dedicated teams will still ship a CPU with bugs. Perfection is simply not possible in this domain.

Wait, really? My understanding was that, whereas VW intentionally cheated to fool regulators, Intel (and others) got blind-sided by a creative attack against a fundamental, well-established technique for gaining performance. These seem like very different problems.

Note: I haven't followed the "saga" closely so maybe there is more to it that I'm not aware of.

> Now I'm thinking that the situation in the US is even worse than that; not only are corporations trying to discredit the government, but the government is working hard to discredit itself as well.

Of course it is.

Powerful and motivated interests have long been working to overturn basically every social program and every protection for labor, discrimination, environment, voting, etc. The goal is to "starve the beast," privatize everything to work toward a government that only runs the military and police, and to make sure it stays that way once it gets there.

Insidiously, they can win support by pushing the government to be more wasteful, more corrupt, less effective, more intrusive, more bumbling, and more frustrating to work with. The moment of victory is when they convince you that government fundamentally is a bad idea that cannot work well, all those taxes you are paying are just going to be squandered, and we'd be better off getting rid of the whole thing.

They have been at work for decades through groups like the Heritage Foundation, CATO institute, etc., to push this into the mainstream. They reached new heights of legitimacy with FOX news & co., and have made great progress with the Trump presidency so far.

Huh. Slack's MacOS UI is the first thing I thought of when reading this article. No titlebar with standard icons. Bizarre mechanisms for popping up dialogs. It could be a poster-child for inconsistency with every "normal" mac app.

Backward compatibility is a laudable goal and is not to be broken lightly. But sometimes, things are so fundamentally broken that we would be far better off with a clean break.

Interoperability is quite possibly a good argument for coming up with some reasonable restrictions on filenames. Today you could easily (case sensitive names, special characters, etc.) create a ZIP file or similar that cannot be successfully extracted on this platform or that.

In an excellent article, David A. Wheeler [1] lays out a compelling case against the status quo. TL;DR: bad filenames are too hard to handle correctly. Programs, standards, and operating systems already assume there are no bad filenames. Your programs will fail in numerous ways when they encounter bad filenames. Some of these failures are security problems.

He concludes: "In sum: It’d be far better if filenames were more limited so that they would be safer and easier to use. This would eliminate a whole class of errors and vulnerabilities in programs that “look correct” but subtly fail when unusual filenames are created (possibly by attackers)." He goes on to consider many ideas towards getting to this goal.

[1] https://dwheeler.com/essays/fixing-unix-linux-filenames.html

You're absolutely right. Unfortunately the broken-ness of the interview process is not limited to the interview itself.

I've interviewed around 40-50 folks for $role at $wildly_successful_megacorp.

My qualifications: zero training, zero oversight.

I'm getting a lot better and more consistent. But I have still left a lot of interviews thinking how poorly I have done, and needing to reflect on how things could have gone differently.

It's very easy to think of interviewing folks as a chore or merely a favor to $other_manager. For something so vital to the long term health of the company, it's really appalling how little effort is put into it.

Works beautifully in Common Lisp. Of course, it is not mainstream.

? (< 0 1 2)

T

? (< 0 -1 2)

NIL

Hard to say.

At start of year, situation normal, the economy we had was unsustainable. We were collectively waging war on our environment and winning. Folks mostly had jobs, which was good, but income inequality was nuts and lots of jobs didn't pay a living wage. Housing costs, healthcare and college were out of control.

In short, the world could really use a correction. The pollution reduction from this shutdown has been dramatic and wonderful.

This will hit the economy very hard. The rich will be livid and will push hard to return to business as usual. The rest of us will suffer terribly. Maybe so terribly, and in such numbers, that we have to address it. Maybe we'll come out the other end with something more sustainable for everyone.

(Probably not.)

One of my most successful development experiences came from starting not with code, but with a keynote/powerpoint slide deck. It made me think through exactly what it was I was trying to achieve, what it would involve, and how it would work. When I realized something or other didn't work well, changing approaches only required editing a few high-level diagrams. Computer diagrams can be cumbersome compared to pen and paper, but have the great advantage of being easy to change once you've spent the time to draw them. Implementing the final solution was much easier when I could look back on how it was supposed to work. And at the end, I already had slides ready to explain everything...

This seems like a really nice chart. I haven't seen the data "normalized" to start date like this before.

Hrmn. This makes it sound like you can only implement a systematically racist system if you are overtly/intentionally trying to be racist.

I suspect in many cases, folks who implement racist systems simply do not care whether their system is racist or not. They want to optimize/automate whatever it is that they are about, and if the result is unfair, well, that's just someone else's problem.

This rings so, so true.

At my very large company, in my particular department, any one trouble ticket may bounce between

(1) a Java ticketing app (2) a web/email ticketing system (3) a Jira issue, or (4) a Gitlab issue, or (5) a company-wide issue tracker

Other groups (e.g., customer service) have their own, completely separate systems besides the above.

Some development tasks are tracked with an issue tracker. Others are planned out in Confluence or Jira, per the whims of each team. We have literally 5 different chat "solutions," with various factions preferring each. Every day it seems someone brings online yet another script that sends out helpful emails. My count is around 16k since Jan 1.

The result of all of this is a sprawling, utterly insane flood of useless noise that everyone ignores.

Definitely.

At a very large company, I was involved in hiring something like programmers for a particular niche department. Over years we developed a good set of battle-tested questions, and had a clear process for evaluating candidates.

But all of this feedback was just an input for management and HR. Regardless of how much we liked a candidate, only HR was trusted to communicate and negotiate with them.

We later found out that candidates were routinely ghosted if the company had chosen not to hire them. We raised a stink about this, but ain't nobody got time to fight that fight.

Anyway, the TLDR: especially with big organizations, never attribute to malice what can be explained by incompetence.

Yes exactly. TCL is somehow even more weakly typed than conventional dynamically typed languages. For instance, in Python, len(3) is an error, but in TCL, llength 3 is 1.

Not to be mean about it or anything, but I really dislike TCL.

Granted, you could do much worse. Unlike shell scripts you at least have access to sensible data structures like lists, dictionaries, and so on. And unlike shell scripts or Makefiles, you can actually handle spaces in your data, so that's at least not horrible.

But when everything is a string, there is no type safety anywhere. So many things that should just be compile errors blow up on you at run-time instead. God help you if you're using code that other people are updating and silently changing.

The syntax is also pretty annoying at times. For instance, you can use unbalanced {} characters within comments, but not if those comments are within a proc. You can nicely write long lists over many lines with {...}, but you can't put comments in those.

Anyway, haters gonna hate. I hope other folks like it more than I do.

All of hardware is tradeoffs.

A huge L1 would be slower to access. You might end up slowing down all memory accesses by a cycle (or more) just for accessing the large cache. You also have to find some place to put the thing in your floorplan, and route everything else around it. This may result in timing challenges in other parts of the chip, which might require additional delay to resolve.

A huge L1 would take up more space. This would increase area, reduce yield, and increase cost. Since in a multi-core chip each core has its own L1, you will have to pay this cost multiple times. Also, L2 caches are typically inclusive, so you would potentially need a much larger L2 to be able to accommodate all the extra information in these L1s.

These tradeoffs have to be studied with simulated experiments to make the right call. For programs with huge working set, maybe the added latency pays for itself because you have have fewer cache misses. For programs with good locality, maybe you end up losing performance. Maybe you save power by reducing misses, or maybe you waste more power because the cache is using more power. Maybe it's an insignificant area increase, or maybe it completely blows up your budget.