gooseyard
Despite those needs though, I eventually looked into the p-b-s builder and found that I couldn't make a serious argument against continuing to maintain our builder and all of the random crap that's needed to manage all the dependencies and using p-b-s. It solves all the same problems and after having switched to it a couple of years ago, my initial concerns about possibly needing to get changes upstreamed never became an issue as your folks pretty much always run into and fix stuff before I do and have been both really pragmatic and helpful in any of the discussions surrounding issues. I keep hoping for an opportunity to contribute something back since the project has really saved me a great deal of toil over the past year or two since adopting it.
I really like the model of treating the interpreter as just another runtime dependency, and after working in the Erlang universe for a few years I keep thinking there are some interesting opportunities for tooling related to bundling stripped-down versions of the runtime stuff along with an application rather than some of the more exotic approaches. Stuff like rebar/erlang.mk might be a nice pattern to study.
Anyhow if Indygreg is reading this, huge thanks and nice work, and I really appreciate all the work you (Charlie) and the astral folks have put in, it's been a real bright spot at work for a while.
It's interesting since I saw another comment near yours that raised the question of robustness of the lab-grown design, which I thought was kind of the most fascinating part of the damninteresting article was the revelation that the evolved programs were inseparable from the single physical FPGA used in the training. Since this RFIC training model employs a simulator, do you suppose that the quirks of the physical hardware on which the simulator runs are sufficiently isolated from the training such that a pair of designs would behave similarly when the simulator was run on distinct hardware? And I guess the even more obvious question is whether a design evolved on a simulator would have any hope of behaving as expected in physical hardware?
My hunch about the latter is no, although it still seems like an interesting study, and I often find myself thinking that really understanding what was going on with the FPGAs might be a prerequisite for really understanding how to master reinforcement learning.
Anyway I'm glad you posted this and if you have any other favorites related to this domain send them my way!
I've been doing this for coming up on thirty years now, mostly at one large company, and I spent a significant number of hours every week fielding questions from people who are newer at it who are having trouble with one thing or another. Often I can tell immediately from the question that the root of the problem is that their world model (Naur would call it their Theory) is incomplete or distorted in some way that makes it difficult for them to reason about fixing the problem. Often they will complain that documentation is inadequate or missing, or that we don't do it the way everyone else does, or whatever, and there's almost always some truth to that.
The challenge then is to find a way to represent your own theory of whatever the thing is into some kind of symbolic representation, usually some combination of text and diagrams which, shown to a person of reasonable experience and intelligence, would conjure up a mental model in the reader which is similar to your own. In other words you want to install your theory into the mind of another person.
A theory of the type Naur describes can't be transplanted directly, but I think my job as a senior developer is to draw upon my experience, whether it was in the lecture hall or on the job, to figure out a way of reproducing those theories. That's one of the reasons why communication skills are so critical, but its not just that; a person also needs to experience this process of receiving a theory of operation from another person many times over to develop instincts about how to do it effectively. Then we have to refine those intuitions into repeatable processes, whether its writing documents, holding classes, etc.
This has become the most rewarding part of my work, and a large part of why I'm not eager to retire yet as long as I feel I'm performing this function in a meaningful way. I still have a great deal to learn about it, but I think that Naur's conception of what is actually going on here makes it a lot more clear the role that senior engineers can play in the long term function of software companies if its something they enjoy doing.
In the end, I am generally using the search engine to find examples because I am too lazy to look at the source for the library I'm using, but if the choice is between an LLM that fabricates stuff some percentage of the time and just reading the fucking code like I've been doing for decades, I'd rather just take my chances with the search engine. If I'm unable to understand the code I'm reading enough to make it work, it's a good signal that maybe I shouldn't be using it at all since ultimately I'm going to be on the hook to straighten things out if stuff goes sideways.
Ultimately that's what this is all about- writing code is a big part of my career but the thing that has kept me employed is being able to figure out what to do when some code that I assembled (through some combination of experimentation, documentation, or duplication) is not behaving the way I had hoped. If I don't understand my own code chances are I'll have zero intuition about why it's not working correctly, and so the idea of introducing a bunch of random shit thrown together by some service which may or may not be able to explain it to me would be a disservice to my employers who trust me on the basis of my history of being careful.
I also just enjoy figuring shit out on my own.
She mentioned that even if you could find one of the machines that was working, keeping it running required routine maintenance and that they were down to essentially one guy who was nearing the age of retirement who had the skill and parts to keep one running. So they were in a race against time to figure out which masters to convert.
The problem gets even more thorny for sessions that were recorded using software like ProTools, which has been around in some form or another for almost 40 years, has gone through countless revisions of project file formats, and has a complicated relationship with specialty audio hardware and software plugins.
It seems like there's a general awareness of the problem now and good studios are taking some measures to archive sessions in ways that allow them to be imported in the future, but in the meantime there are two decade's worth of recordings at risk, even if their media hasn't been lost or corrupted. I guess if nothing else its a cool opportunity for people who like to hack on systems of this type though.
since it's convenient to use the headphone out on the uv1 for the headset, i do use a limiter plugin in Rogue Amoeba Soundsource to compress the output from the conferencing software we use, it's nice being able to do that per-application since i listen to music through the headset a lot and don't want to have to take the limiter in and out.
analog headsets are so much less annoying and flexible, huge fan
I am by no means a prolific or genius songwriter, nobody would know any of my music, and I don't believe that any of it is particularly impressive. However I've always found the fact that it happened spontaneously way to be a source of wonder, and as I've aged as a musician its delightful to see the endless stream of new songs and that it doesn't seem to matter whether you're a prodigy when it comes to writing songs that impact listeners. It seems to be a fundamental aspect of the human experience.
The analogy I've tried to use in teaching is that learning to play jazz is like being a comedian; when your skills are at their peak you're going to be inventing jokes regularly, but in the decades before you get there, you're going to be delivering other people's jokes putting a little of your own spin on them. The delivery matters a lot, and like good jazz playing it's pretty much impossible to write a book called "How to be Funny" that wouldn't just be an academic analysis rather than an instructional guide.
I struggled with jazz for the reasons I've alluded to above, and it wasn't until I started studying with a teacher who just had me memorize hundreds of standards that I got my playing together. We definitely talked about the technical bits of what was happening in the tunes, but those were really just interesting observations; repeatedly playing them in a group setting after woodshedding them at home between lessons, then taking a lot of solos was really what made it happen.
It really makes me happy to see up-and-coming killer players like Patrick Bartley espousing this same approach. Yeah it means you're going to spend thousands of hours memorizing tunes, but if that's not fun then playing jazz isn't going to be fun either.
My background is in jazz, and often I encounter beginner students who have learned enough about the pedagogical aspects of music to know about a thing called theory and that there is virtue in knowing it, but they also mistakenly believe that an knowledge of theory is sort of the fountain from which ideas flow, which is not the case. For example to learn to compose and improvise in the jazz idiom, the way I learned it, the way essentially all the people I play with learned it, and how I teach my own students to do it is to internalize a great deal of music in your chosen style by players whose style resonates most with you. Memorizing changes, transcribing recorded parts on whatever instrument you enjoy playing, and so on. After doing this for a while you will start to develop a vocabulary of musical phrases which will occur to you spontaneously as a reaction to some kind of prompt, for example in jazz there are common sequences of chords that occur frequently in compositions, and by absorbing thousands of melodic phrases that occur over those changes you will have an innate idea of what you like to hear over them without having to think analytically about the relationships between tones and scales. You can certainly apply knowledge of theory to expand on your ideas in an analytical way, but the intuitive part needs to be developed first.
Many beginners balk at this idea because they like the idea of having purely new ideas, and you can certainly do music however you want, but I think ultimately most composers/performers want audiences to hear their work and there is a tacit relationship between the two; the audiences have an opinion about what sounds good and if your compositions don't sound like the genre of music they enjoy, neither of you are likely to be happy. I like to use the analogy of stand-up comedy; your jokes may crack you up but people don't want to watch somebody else laughing, so you have to meet them partway.
So having said all this, I think step one is to develop some opinions about what you think sounds good. Make a list of your favorite recordings and your favorite performances on those recordings and learn to reproduce them somehow. If you don't play an instrument, figure out how to sequence the changes, or noodle out a melody on the piano (if you don't play any instruments the piano is the smart choice, since it's like knowing how to type if you're a musician). The act of making these reproductions will tune your ear to hear chord qualities that might not be apparent to you until you try to recreate them, and relationships between notes in a melody and the supporting changes that you missed when just listening.
During that process, take time to just play. Undirected noodling on an instrument is the way you develop an intuition about where the notes you like live in relation to each other, and bumping around the space of notes on an instrument is a great way to learn.
At some point during those play sessions, you'll have an idea that'll get stuck in your head. Capture those ideas, save them, and then when you have a few you like, its time to start working on the composition process, either by notating/sequencing them with software instruments, or making a recording of mixed live/sequenced performance. I generally use Garage Band for making demos that I give to people I perform tunes with, some of my friends love Ableton Live, and the friends I know who do arranging for a living typically use something like Sibelius to produce scores.
I think that after you've made a few compositions of your own, if you decide you want to continue, its not a bad idea to take an introductory course on harmony to help develop your ear so that you can identify sounds that you like, but I think its best to do that after you have started to develop an intuitive sense of what sounds good, since that's the skill thats going to determine whether you make something that is interesting and not built from a formula.
Good Luck!
The bulk of the people I've described had very little interaction with the world outside the area where they lived, and the only way they were likely to interact with someone from the facts-first community was via a letter to the editor of some magazine (which might not be published), or if an outsider came to visit, in which case politeness might avoid a confrontation.
Social media introduced these two groups to each other, each group thinks the other is comprised of fools and neither is shy about saying so, and here we are. In my own family, I have yet to see a case in which a member of the tribal knowledge community was moved by an argument from a member of the facts-first community; their belief structure seems to ossify at around pubescence and compromising on it in any way would risk a loss of status in that community.
I take some comfort in believing that we have not been plopped into a post-truth reality, but rather that providing the internet to rural tribal communities was rather like switching on a light and discovering what things had been hiding before our eyes in the dark. I think its also a generational issue because the difference between my old relatives and their offspring my childrens' age is nearly as stark as the difference between the facts-first and tribal-knowledge communities on the whole. While it sucks that this post-truth era will be with us for a while I'm hopeful that the same internet access that led to this schism will also allow at least some of the kids who grew up like I did to be skeptical about tribal knowledge from a younger age. However you might also argue that now the segment of the entire population who are susceptible to misinformation will be poisoned in the same way I was.
Anyhow thanks for your comment; reading it made me stop to think about something that had been bothering me a great deal lately and it was helpful writing this response.
As it happened both parties arrived way late, and the deal went down. I'm still a little salty about it after all this time.
For example, I have studied a lot of classical repertoire in order to get my technique together to improve my jazz playing, and while I appreciate those compositions, I don't really listen to them for pleasure. My opinion about their value as works of art is not based on whether I enjoy them or not. I don't enjoy many types of food but I recognize that they have enormous value to people who do enjoy them. We like what we like, and we shouldn't judge styles on the basis of whether we like them or not.
If you listen to a record like Kind of Blue and it doesn't do anything for you, don't sweat it. You wouldn't be a better person for liking it, and no true lover of jazz would judge you on the basis of whether you like that record or not. If you're genuinely curious, listen to other jazz records from the era, maybe you'll like those. If you don't, no big whoop. There's a lot of music to love. Listen to what you like.
Something I found that I like about the approach is that sometimes while working on a change, some unrelated code will catch my eye that I want to fix but not as part of my next commit. Being free to make the edit, knowing that I'll see it again later when staging changes, is nice because I would often otherwise forget to go back and revisit the thing I saw. The git add -p sessions then wind up being an opportunity to decide what changes go into each commit, etc. I do burn myself occasionally by having an unrelated edit that is in a hunk that can't be split- I suspect there are tweaks to diff I could make to help with that but have yet to overcome my apathy wrt research.
What totally confused me at the time though were program listings in assembly (I couldn't figure out how you were meant to type those in) and especially the discussions of OS-9. I didn't know what it was, and even in some cases where I found a Radio Shack with the Tandy OS-9 distro, it was like 100$ and didn't have any games as near as I could tell, so I couldn't figure out why you would pay so much for it. Also I lived in a rural location where even the nearest 6809-oriented BBS would have meant expensive toll calls, so I missed the opportunity to learn that way.
Anyway skip forward, I started to college in 1993, immediately found Usenet, then Linux, and spent the next 30 years or so steeped in that world. Every so often I would go back and do a little reading on the 6809 world, but because I had never really understood most of what was going on, I didn't have a great deal of nostalgia.
Finally though, a few weeks ago I came across a link (maybe here?) to a release of the VCC emulator, and although I had played with a couple of 6809 emulators before, I hadn't really gone down the rathole of finding the MultiPak roms, or hard disk controller paks, etc. I found a couple of hard drive images, one from the NitrOS9 Ease of Use project, and another random NitrOS9 image packed with old software. What was particularly fascinating to me was the NitrOS9 source itself- since my introduction to Unix was in the 486-MMU-having-era, to see what people were able to do with a 6809 and an assembler was just a joy to read and understand.
I feel like probably everything that has ever needed doing on a 6809 has probably been done, and I've done enough 8 bit assembly stuff in school that I don't have a powerful urge to go back and make something myself, but boy what a feeling of having come full circle when I cd'd into the NitrOS9 source directory and found a makefile of all things! I feel so fortunate to have been able to live through a time of such explosive growth and change, and hope to get the chance to do a little OS-9 hacking when I retire some day :)