It's long (36 hours, broken up into ~45min lectures), but very engaging and accessible. He goes through the entire history of Western music from Pythagoras through the 20th century. He covers everything from (very basic) music theory to how trends in society and technology influenced the music that was produced in each period.
After listening to the whole thing, it gave me a much more fully formed mental model of how different eras, composers, and styles relate to each other.
And from there it's become much easier to dig in and appreciate different areas of the repertoire, rather than idly trying to absorb disparate pieces that would come up on radio/streaming.
I think this is the last thing people need. Do you really expect me to listen to 36 hours of lectures before I am able to appreciate art music? Listen to the music! Then, if you hear something that clicks with you, and you want to learn more about it, do. You don't have to understand the history, theory, and technology of music to appreciate it.
An interest in learning about the music follows a love for the music.
I don’t think the parent was suggesting that you need to listen to 36 hours of lectures before listening to classical music. Just that for people who have any interest this could further enhance your appreciation. Seems like a reasonable suggestion to me.
I'm not a fan of classical music's cultural self understanding myself - although I do like a lot of classical music. So I do understand where you're coming from.
However, we can't entirely divorce music from its context. If you only listen to music you like without ever asking what it is, who made it, and what they were trying to do with it, you're going to miss out on a lot of things you easily could have liked.
We shouldn't treat music as if it was just sound waves for producing feelings. I think music is communication, people trying to say things, things that maybe aren't so easy to fully say in words. And as with any communication, context matters, and language matters. Understanding non-verbal messages from hundreds of years ago is worth a little effort, I think.
I think we're in agreement on this. It's true that the best classical music has great depths to be plumbed, and some of it requires an understanding of the techniques and intentions of the composers, but there's still plenty that can be taken in by an uneducated listener. My point was that until that uneducated listener gets a bit hooked on it, telling them that they can't possibly appreciate it until they've engaged in serious study is going to sound like off-putting elitist claptrap, and put them off completely. (Which was probably not what you were saying, but it was about my turn to fail at nuance in online conversations.)
I wish I could tolerate him. The content is great, but I find his constant tone of “oh how enlightened and civilized we are because we listen to the right music” thing beyond irritating.
That makes me think of the "light music" which was popular in the 20th century, especially in the US. It was very much music for and by the upper classes, but supposed to be tongue in cheek and charming, not to take itself too seriously. The patrons of orchestral music increasingly weren't too keen on the "serious" classical music of the time which had the conservatories' stamp of approval (because, well, have you heard it?)
Leroy Anderson was part of that tradition. I'd say so were comedians like Victor Borge and Anna Russell.
I LOVE that audiobook/course. I enjoyed it way more than I thought I would.
For anyone on the fence, the narrator/instructor is funny and makes you want to listen to more of it. They walk you through history of music and play songs explaining how the song came about. As an adult that loves music, it’s easy to enjoy it because it’s a very informal format but you learn interesting things the whole time.
I enjoyed it, it goes into quite a bit of music theory and many different musical styles, with a lot of listening exercises.
As a sibling comment said, of course you don't need this to enjoy music, but I did feel like it deepened the experience in some way (and maybe made it a more analytical experience simultaneously - which may or may not be what you want).
I'm listening to this now and love it. The best part is that he puts clips of various types of music throughout (European) history, so you get to listen to them all and compare.
You're going to get a lot of snark from people saying things like "don't", or "learn python instead".
This epitomizes "a little knowledge is a dangerous thing".
Bash has many cringeworthy aspects, but we have to deal with the world as it is, not the world as we would like it to be, and the reality is that bash is the default shell on 99.9% of unix boxes you encounter — even if you use an alt shell on your machine.
Coworkers machine? Bash. Default AWS AMI? Bash. init script to bootstrap $DAEMON? Bash. ssh to a server at your workplace? Bash. Random O'Reilly Linux tutorial? Assumes bash.
My advice?
Take some time.
Sit down.
and read "man bash"
cover-to-cover.
at least once.
A lot of the illogical things in bash make a lot more sense once you understand its parsing/expansion rules. And once you understand what is in the language vs an external terminal program in your PATH.
Since that sounds unappealing (and I scoffed at that very advice for many years), I've also found the wooledge bash guide to be very helpful.
Bash is unbeatable as a functional concept for chaining command-line tools together. Once you start getting functions or even a lot of if/while constructs, it's usually time to switch to Python/Perl.
I wrote a guide to the shell (posted elsewhere here). I concur with this statement wholeheartedly. Bash as a command language is exceptional, as a scripting language it is sub-par at best. I've been using Ruby a lot lately in command line scripting, little things like
$ ls /*.orig | ruby -e 'while f = gets do ... end'
It's not quite as easy as the shell tools for little things, but I feel like the crossover point where the lack of programming constructs begins to outweigh the initial ease of Bash scripting is about ten lines of Bash. Which is not to say that it's not useful -- I do think that Bash is something that every developer should know -- but that you really need to have Bash and another command line scripting language in your toolbox, and know when to use each.
I used to think of it in terms of "number of lines" but then I found a task that worked quite well in a longer bash script (creating a .deb file). In fact, it worked better than if it were a python script, because all the commands were right there.
Now my metric is, "if it needs a function, or even a complex while loop，switch to perl/ruby"
I think that what I would tell new people would be "more than ten lines, OR using more than two variables, OR any flow control constructs". Bash can make even simple conditional statements difficult, and while my rule is absurdly restrictive, Bash can still be amazingly useful within those bounds. Probably mine is the lower bound for "anything less complex than this is fine to write in Bash" and yours is "anything more complex than this should definitely not be written in Bash", with the middle ground being "have a good reason why Bash is the best tool for the job".
I'm not sure if you'll see this 2 days later, but I've been trying to make heads or tails of your example and I think there’s a mistake in there somewhere.
Maybe I'm hopelessly lost, but, for one, the inverse of
Your code stops compiling with a pretty unhelpful error message. Y'know, like Segmentation Fault 11, and a stack trace into the swift compiler sourcecode if you're lucky.
XCode doesn't always crash (though it does, frequently), but syntax highlighting goes away at the first hint of an issue.
1000 times this. I've been really enthusiastic about the idea of a modern, compiled, type safe, systems language, backed by a major tech juggernaut.
But the compiler crashes and sourcekit instability are just breathtaking (even in 3.0+). I'm surprised I haven't seen this get more attention.
I'd (somewhat) expected something like this for the first few releases, but two years in I'm starting to think the team bit off more than they can chew with the type system.
SourceKit is unbelievable! When using Xcode for most of the time (as in >50%) it causes very high CPU load and it's not uncommon for it to use >3GB of RAM.
SourceKit issues fall into two categories. The source causes the compiler itself to crash (due to one of those compiler defects mentioned elsewhere in the thread), or some issue with the build configuration.
The latter category is especially nasty, and SourceKit won't inform you of this, except perhaps to crash. Oh, and that dumb bar in Xcode.
You can compile all the Swift source in your target successfully but have SourceKit choke on your build configuration. Accidentally introduce a duplicate set of headers in HEADER_SEARCH_PATHS? Degraded performance, and at worse, the compiler crashes everytime you edit text and SourceKit invokes the compiler. In cases like this the SOURCEKIT_LOGGING environment variable is your friend. Have fun combing through those logs to tease out what build option you set is causing your issue.
I spent the better part of two days sifting through SourceKit logs to figure out why a project's autocomplete wouldn't work. Yet, I wouldn't want to go back to writing Objective-C primarily. Because Swift as a language rocks.
Very little maintenance after the initial assembly and planting, and I've had pretty great results so far.
I've heard about aquaponics before, but never dug into it. I'd be interested in hearing about its advantages over a (presumably less involved) traditional container setup like mine.
Hey Josh, the advantages are similar as compared to a garden, except the containers solve some of the problems (such as optimal watering). Probably the biggest advantage is you get fish as part of your harvest.
I feel like it’s going to be hard for a company like Spotify to compete on price. Their margins are already thin from what I hear, and they don’t have a hugely profitable hardware business to subsidize their service.
But at this point Apple has gone to great lengths to control the entire toolchain from the OS to the compiler to the chips that run the instructions the compiler produces.
It’d seem odd if they didn’t go with something home-grown as their language of choice.
But it would be better for a lot of developers who don't want to spend a lot of time learning ObjC just for iPhones. It might also have been a safer choice for Apple since they now are in a bit of a danger if iPhone and iPad sales goes down. Then the number of developer learning their languages might fall fast and then the app ecosystem might start to fall too.
Available on audible:
https://www.audible.com/pd/How-to-Listen-to-and-Understand-G...
It's long (36 hours, broken up into ~45min lectures), but very engaging and accessible. He goes through the entire history of Western music from Pythagoras through the 20th century. He covers everything from (very basic) music theory to how trends in society and technology influenced the music that was produced in each period.
After listening to the whole thing, it gave me a much more fully formed mental model of how different eras, composers, and styles relate to each other.
And from there it's become much easier to dig in and appreciate different areas of the repertoire, rather than idly trying to absorb disparate pieces that would come up on radio/streaming.