a_lieb
The stats on the CIRR site across schools did always seem a little... odd to me, with differences in outcomes too big to believe at times. Sounds like I would have found the same thing if I looked at any individual school over time, as the rules and practices changed.
I think you're talking about either the Council on Integrity in Results Reporting (CIRR) [1], or Course Report [2] (both still up). CIRR is a body run by the code school industry itself to monitor its own results; Course Report has over 50k reviews by students as well as articles with tips about how to pick a code school, "top x code schools for y" lists, etc.
CIRR seems to be reasonably rigorous and honest. Their reports are easily available on the site. I've poked around in their reports, and there's a huge range of results, from less than 50% employment at 6 months to 80%+. There seems to be little to no correlation between the reputation of a given school and the actual outcomes (some of the most reputable schools had employment rates of 50%-60% at 6 months).
A big trend I noticed was that the schools with the highest employment rates were relatively low-profile schools teaching unsexy technologies that are low in SV buzz but nonetheless have high demand, like Java and C#.
If you're the head of a successful OSS project and you believe it's helping your career in the way of industry notoriety, good demo work to show potential employers, etc.—then give a cut to cover the project's expenses, or even hire folks for freelance work.
There might be stretches when you're not going to make any extra money from the project; say you've reached the point where the project isn't a top line-item in your resume and is probably not responsible for your next salary bump. You can still honor what you've gotten from the project by voluntarily investing back a portion of the money. It has a "benefit corporation" flavor.
If this sounds like too much generosity to expect of people, consider people like Thibault. He's very, very deep into the "generous" side, in that pretty clearly he could work on the project _far_ less and still get a dream job. What I'm describing is a way to make an overall profit and still feel like you're giving back to the world by nurturing the project you've built.
Obviously, this is an overwhelmingly common thing in practice already, whether it's someone who made an OSS project to get a good job and then continued to work in their spare time to maintain it, or language BDFLs who maintain the project on a volunteer basis, but as a result of founding the language they have amazing and well-paying day jobs. But so far I've never seen it described as an actual business model, where you can feel great about helping to keep up your project, but still come out ahead overall.
There have been many attempts at a chromatic music notation, but nothing has caught on so far [1].
Things are a little better with solfege -- there is "chromatic fixed do" solfege, where every note has its own name, rather than only having a name for the "white notes," which leaves you to mentally calculate the sharps and flats.
It's a minority thing--maybe 5-10% in Europe? Even regular fixed "do" is rare in English-speaking countries, so I would assume the chromatic fixed "do" is almost unheard of in the US, Britain, etc.
At any rate, there're are at least seeds of hope for a chromatic fixed-do solfege to catch on more. I use it for my own learning.
It turns out that when you make a language like that, you end up something where your code looks and feels like a list of commands (much like a shell script) but is also capable of doing "real" programming stuff where needed without much pain.
The test suite for SQLite is (still!) written in Tcl, I think partly for this reason. You probably wouldn't want to write a test suite in bash, but you don't quite get that feeling of "it's just a list of commands."
Nice easter egg from the source code:
<!-- <audio autoplay="autoplay" controls="controls"><source src="topgun.mid" type="audio/mpeg"></audio> -->That said, in the Princeton lecture notes, he does seem to start a given topic on fundamental/"why" questions and then build out, more than any other intro music material that I've seen. A far as I can tell, his own theories are in there, but more as a framework to help explain things, rather than demanding you think that way.
For example, in the first pages, he describes a bunch of well-known fundamentals in music theory/psychoacoustics, but in a very "Tymoszco-esque" way. He lays out five principles common to a huge range of music styles: some combinations of notes are considered more pleasant than others, you don't want to have melodies that jump around too much, etc. (These all go for the Western musical tradition, but also many others.)
Then he says that our scales are essentially "solutions" to how you can chop up the octave into steps and meet all of the five requirements. It turns out there are a relatively small number of ways to do that, we've found just about all of them, and those are pretty much exactly the list of scales that we're using. But then he quickly builds it out to common scales that you can play on a keyboard written out in normal notation, and goes from there.
This is extremely satisfying to my hacker brain, like picking a handful of criteria and doing a search to find all the possible lists of numbers that meet those criteria.
I wouldn't be surprised at all if you can explain music theory from fundamentals just as well using traditional Neo-Riemannian theory, or even something totally different. I just haven't ran into any intro-level materials like that.
(Also: it could even be that his list of requirements isn't really true, but it's hard to see which ones you would want to deny for Western music.)
He teaches a set of 2 comprehensive introductory music theory classes at Princeton, and he makes the lecture notes public: https://dmitri.mycpanel.princeton.edu/teaching.html. These are a really underrated resource and have now grown to be as complete as a full intro theory textbook.
There is a serious lack of stuff that teaches music theory from the ground up (how a lot of us hackers like to learn). So much of the confusion around music theory just comes from most theorists using using old, incredibly crufty "data structures" to describe music, when the actual material isn't so hard. Tymoczko is one of the few researchers pushing back on that. He is best known for his higher-level, mathy research (he wrote the first music theory article ever published in Science), but those lecture notes are a great way to get started for anyone who gets frustrated with learning theory the traditional way—which is pretty much everyone.
What "exists" means depends on the language; it can be as loose as checking if the variable has ever been set (PHP), but generally has nothing to do with truthiness/falsiness status.
(1 :+ 2)
(+ 1 2)
(1 2 3 4 5 :+)
This doesn't solve the "too many parens" problem, because you still have parens, but it does solve the "prefix math looks weird" problem. It's quite a bit simpler than what Dylan does, in that there's no special concept of "binary operators" and it's obvious at a glance how everything converts to sexps.
There are some trends coming together in recent research that suggest that the most sustainable way to lose weight not to follow any specific regime, but to find a set of food restrictions that you can live with but which still lower your overall "food reward" to a level that you can sustain without giving up. (See this book review at Slate Star Codex [1] for more on these ideas.) It's like a much more fine-tuned and personalized version of the fad diets that don't have calorie-counting but add some restriction so that you don't want to eat as much, like the Atkins Diet or the grapefruit diet.
It turns out what works for me is to limit myself to 3-4 specific meal categories a day, only changing something up every few months. Currently it's Grape Nuts Flakes and milk in the morning, a homemade turkey and roast beef sandwich (or even 2) for lunch, and homemade burritos or Barilla Plus pasta for dinner. No beverages except water. No sides, except there are a couple of low-reward foods that I'm allowed to eat all day (currently Spring Mix and steam-in-bag veggies).
Crucially, these are actually some of my favorite foods–and some are pretty high-calorie–but if they are the only things that I am allowed to eat every day, my food reward starts to drift down and I want fewer calories.
I don't put any limits on anything, so I'm never physically hungry and my willpower isn't being drained every day by trying to limit myself. I let myself eat pretty much whatever when I go out socially, but otherwise absolutely no cheating.
We'll see how it works out in the long run, but overall I'm just as happy as before. Any boredom from the diet itself is mostly cancelled out by the benefits mentioned in the article (saving money, not needing to think about making your meals, etc.) Not to mention the whole "losing weight" part!
[1] https://slatestarcodex.com/2017/04/25/book-review-the-hungry...
A few other smaller subcultures have gotten a foothold on Mastodon; it's far from a ghost town. Another upshot is that unlike anything else you listed, it's decentralized and federated, so your instance could never be taken down.
Tegmark's theory is an expanded version of Tononi's Integrated Information Theory, which has gotten a lot of interest in mainstream cognitive science. IIT also stays well within the laws of physics.
Non-materialist philosophers of mind tend to like these theories since they make consciousness correspond with fairly low-level processes, and that looks a lot more plausible than consciousness being something that only pops up in animal brains for some mystical reason. But neither IIT nor Tegmark's approach actually require any kind of escaping from the laws of physics. In fact Tononi sounds to me mostly like a materialist, although he's pretty slippery about it. Not as sure about Tegmark.
Also, important to note that almost no one believes in vitalism (the idea that life itself requires special extra-physical "secret sauce" to exist) anymore. It is only consciousness that is up for debate in mainstream philosophy.
JavaScript is already jam packed with subtleties and gotchas that make it hard to learn, including situations where two things have the same name or the name doesn't quite match the underlying concept: C-style "for" vs. "for ... in" vs. "for ... of," object vs. Object, Object.prototype vs. "the prototype of the object," etc. We don't need another one of those.
I'd actually like this if it used another word than "case." "choose ... when", maybe? Kinda awkward, but I bet someone could think of something better. "case" has the nice feature that it's already a reserved word, but it's not valid syntax to have a variable name right next to an open brace, so the parsers could figure it out.