compiler-guy

Zhang, L., Liu, X., & Hu, Y. (2024). Degrees of return: Estimating internal rates of return for college majors using quantile regression. American Educational Research Journal. Prepublished March 12, 2024.

https://journals.sagepub.com/stoken/default+domain/W9MBX7ZGK...

"We estimate the internal rates of return (IRRs) for individuals with college degrees in 10 broad majors compared to high school graduates. Our analysis shows significant differences in the age-earnings trajectories and IRRs across college majors. Specifically, Computer Science and Engineering majors have the highest IRRs, exceeding 13%, whereas Humanities & Arts and Education majors have the lowest IRRs, around 5% for male and 8–9% for female college graduates. Furthermore, the quantile regression analyses show that IRR is generally higher at the high end of the earnings distribution. Finally, we observed a slight decrease in IRR during the study period, which is consistent with the flattening and even decline in college wage premiums following the 2008 Great Recession."

Deprecated or not, there are billions of lines of code out there that use it, and the odds of a random CS graduate encountering it are very, very high. So it makes sense to be familiar with it.

Code from that era predates the web, and a lot of open source style guides, and even most open source code itself.

So it came up in an era where folks were inventing their own style and the huge homogenizing influence of the gnu standards (and other open source projects) hadn't taken hold.

I like it. It feels like another language, and has its advantages. I really like to know of alternate ways of doing things, even if I don't adopt them myself.

One interesting thing about the EDG front end is that it can emulate all the others (and in various versions of the others) and what they support, and the errors they might detect.

It isn't perfect, but it is awfully good.

Another interesting thing is that in 1999ish, when SGI open-sourced the Irix compiler (known as sgicc) into open-64, the it used a terribly hacked version of gcc as a front end to generate its internal intermediate representation.

This was because sgicc, even back then, used EDG as a front end, and EDG wasn't open and couldn't be opened up at the time.

The combination worked OK, but was pretty hacky, and I wonder if open64 would have gotten more traction than it did if it had been able to use EDG, or perhaps some other front end actually designed as a front end instead of the hacky thing.

This is discussed in the article.

You did read where going too slow causes additional risk related to avalanches and rock slides, did you not?

It's a very sticky problem that doesn't lend itself to "Why don't you just...." solutions.

It's a highly specialized use-case where every little detail of the timing and hardware is important. So that, for example, games run exactly right.

For folks without this particular use case, other emulation solutions are probably better.

It’s a common idiom. And idioms are often weird. But that is exactly the point.

That’s not what the idiom “don’t do x for fun” is about.

The expression means that X is the best of unpalatable options to accomplish something else, where X is taken in a literal and narrow sense.

People don’t fly with babies for fun. They do it because visiting grandparents is fun, and driving isn’t a good option. Or, if it involves a trip across the ocean, the alternative would be sailing.

The VP also needs to know if the fix will require some sort of resource reallocation, or if the timeline is long so they can deal with the other stakeholders, or whatever. These are all forward looking things that the details influence but the details aren't what matter.

I agree with the 2023 decode there, but there is still a bit of a puzzle:

If someone knew to replace the battery just three years ago, I would expect they also would have enough knowledge to set the clock itself. Or at least explain what was going on. Maybe this person isn't connected with the building anymore. But I would expect the new owners would be able to contact the old owners for help on this instead of sending a generalized call for help.

Because that's the way courts work. This court only had jurisdiction over Germany. It is possible that other courts with broader jurisdiction would rule similarly, but someone has to bring the case.

It’s hard to imagine a company more all in on ai than Google. The pressure to use it is intense and they are throwing ai at basically every problem. If a proposal doesn’t have ai in the title somewhere it has no chance of funding.

I don’t really think it has made Google products better, but it is absolutely the expectation.

I do want (some, carefully curated as to certain usecases) AI. But I don't want to waste my diskspace for this AI.

Being short on disk space is a pretty good reason to not upgrade.

I would rather keep my personal picture library on my local disk (with backups, of course) than gigabytes and gigabytes of Apple models.

They were the ones who thought that 256Gb was a reasonable number. And it actually did work pretty well, until they wanted to fill it with models.

The linux kernel didn't even gain SMP until 1996. Solaris was running circles around it both before and after that point. Solaris was vastly more mature and stable.

Of course, after that, Solaris just kept running in very expensive circles while linux went on to make steady progress.

There are two commenting critics. So "multiple" is true, I suppose, but only quite weakly so. And there are more than 4x that many upvotes on the top-level comment. So I don't think it is as simple as "everyone is saying you are wrong."

You are arguing a point I didn’t make.

I certainly don't think anything like this actually happened. And the linked article doesn't really do so either. I do think it can be a useful illustration of what problem each technology solves.

In another thread you talk about how the internet really is a series of tubes. We all know that "tubes" can be a useful analogy for understanding certain things about circuits and things built upon them. But we also don't think that tubes are more than a very basic analogy. Tubes don't really do packet switching.

This is obviously not an attempt at anything remotely resembling documentary history. It’s more of a just so story explaining what problem each step solved.

Unless of course one thinks that smooth gray stones from a riverbed two miles away reflects some historically significant point in money’s evolution.

If everyone needs to give them roughly the same set of instructions to get good results, then those instructions should be built in.

Good defaults are expected in pretty much every other tool.

And “You just have to set it up carefully and properly” is pretty much saying that the defaults are never good enough.

A sibling comment talks about needing a lot of setup and context for agents to produce good code. That’s both true and bizarre.

If the compiler that I write produces lousy code, I get bugs that I fix until it doesn’t.

And that is the most annoying thing about this revolution. It’s obviously powerful and transformative and I use in my job all the time.

But many, perhaps even most, purveyors seem intent on blaming their users when they have issues, rather than fixing their own bugs.

General model improvement is going a long way here, but basic things like “ensure you use good style and programming practices” really shouldn’t be a thing users need to put in any .md file.

Not sure when it started, but the second chance pool has moderators putting stories that didn’t get much attention when they were submitted directly on the front page.

There may be some survivor bias here, but second-chance stories seem very front-page sticky to me. At least those I have recognized.

"Most groups look more homogeneous from the outside than the inside."

But that doesn't mean that they really are all that different in the end. It reminds me a of joke as told by Emo Philips that I think is quite apropos:

==-==-=

A man was walking across a bridge when he saw someone about to jump. He ran over and said, "Don't do it! There's so much to live for!"

"Like what?" the person asked.

"Well, are you religious?"

"Yes."

"Me too! Are you Christian or Jewish?"

"Christian."

"Me too! Protestant or Catholic?"

"Protestant."

"Me too! What denomination?"

"Baptist."

"Me too! Northern Baptist or Southern Baptist?"

"Northern Baptist."

"Me too! Northern Baptist Conservative or Northern Baptist Liberal?"

"Northern Baptist Conservative."

"Me too! Northern Baptist Conservative Covenant or Northern Baptist Conservative Council?"

"Northern Baptist Conservative Council."

"Me too! Northern Baptist Conservative Council of 1879, or Northern Baptist Conservative Council of 1912?"

"Northern Baptist Conservative Council of 1912."

The man stepped back, eyes narrowing, and yelled, "Die, heretic scum!" and pushed the other off the bridge.

It's a sales website with a not-terrible hook.

Also AI generated diagrams with strange labelling doesn't persuade me much.

This true, but you can write the two separately if you want.

The disadvantages of writing them together are listed in the various parent posts. But some code authors really like the convenience of having the two in the same file.

It’s easy to write instructions that have the agent check once every fifteen minutes, or even once an hour, in perpetuity, which never sleeps. And people do write such instructions. A human can’t do that by hand for very long.

The problem is that it is hard to distinguish your one off (which seems perfectly fine) from the tidal wave of bad actors.

That is the debate. And it is hotly contested.

The legal framework around all this is way too immature to make a definitive statement one way or the other. Anyone who says otherwise is speculating.

The only way to clarity will be legislation or court cases, because it really could go either way.

Not to mention that it solves none of the rate issues. If the scrapers are hitting your site 10,000 times a day, adding markdown isn’t going to change that at all.

I suspect most people would be ok with this if they could only do it at the rate and frequency you yourself can do it. The problem is largely one of scale.