Two Turntables and a Microphone (2006)(goodfuzzysounds.com)
goodfuzzysounds.com
Two Turntables and a Microphone (2006)
https://goodfuzzysounds.com/ma/docs/funnyversion.htm
47 comments
> I wonder if "The Orchestra that draws no salary" was as controversial at the time as "Artisans won't complain about work-life balance" is today.
Yes, it was. Here's the view from Local 802, American Federation of Musicians. Nowhere else in this mechanical age does the workman create the machine which destroys him, but that’s what happens to the musician when he plays for a recording. The iceman didn’t create the refrigerator. The coachman didn’t build the automobile. But the musician plays his music into a recorder and a short time later the radio station manager comes around and says, “Sorry, Joe, we’ve got all your stuff on records, so we don’t need you anymore.” And Joe’s out of a job.[1]
This finally came to a head in an 800-day strike. The outcome was that performers started getting royalties from recordings. An unexpected side effect was the end of the big band era and the rise of the pop star.
[1] https://www.local802afm.org/allegro/articles/the-silence-was...
Yes, it was. Here's the view from Local 802, American Federation of Musicians. Nowhere else in this mechanical age does the workman create the machine which destroys him, but that’s what happens to the musician when he plays for a recording. The iceman didn’t create the refrigerator. The coachman didn’t build the automobile. But the musician plays his music into a recorder and a short time later the radio station manager comes around and says, “Sorry, Joe, we’ve got all your stuff on records, so we don’t need you anymore.” And Joe’s out of a job.[1]
This finally came to a head in an 800-day strike. The outcome was that performers started getting royalties from recordings. An unexpected side effect was the end of the big band era and the rise of the pop star.
[1] https://www.local802afm.org/allegro/articles/the-silence-was...
> An unexpected side effect was the end of the big band era
An unexpected side effect was to contribute to the shift away from big bands dominating the musical scene, during/after a world war and changing tastes in music and music-making. In other words, the strike hastened a trend.
And keep in mind that the troops themselves had access to the newest jazz recordings, as mentioned earlier in the same article you're citing:
"As the strike progressed, limited recordings (called Victory Discs, or V-Discs) could be made solely for servicemen, as long as they weren’t distributed commercially."
IIRC, some of those V-Discs featured early bebop performers. Like bop, big band in general had already been getting faster-- often not even dance-able-- and more dissonant-- to the point of becoming avant-garde. By the end of the decade, in 1949, you already had Miles Davis' Boplicity and Israel, and those trends were never going to sustain a popular music industry, especially with the advent of television (where, according to the article you cited, Petrillo negotiated again for musicians' royalties).
In any case, Petrillo apparently had balls of steel. Everyone on HN should read that article, if only to get an idea of the work it would take to get remunerated fairly when a cluster of GPUs can be trained to do all your future work.
An unexpected side effect was to contribute to the shift away from big bands dominating the musical scene, during/after a world war and changing tastes in music and music-making. In other words, the strike hastened a trend.
And keep in mind that the troops themselves had access to the newest jazz recordings, as mentioned earlier in the same article you're citing:
"As the strike progressed, limited recordings (called Victory Discs, or V-Discs) could be made solely for servicemen, as long as they weren’t distributed commercially."
IIRC, some of those V-Discs featured early bebop performers. Like bop, big band in general had already been getting faster-- often not even dance-able-- and more dissonant-- to the point of becoming avant-garde. By the end of the decade, in 1949, you already had Miles Davis' Boplicity and Israel, and those trends were never going to sustain a popular music industry, especially with the advent of television (where, according to the article you cited, Petrillo negotiated again for musicians' royalties).
In any case, Petrillo apparently had balls of steel. Everyone on HN should read that article, if only to get an idea of the work it would take to get remunerated fairly when a cluster of GPUs can be trained to do all your future work.
The entire set of V-Disks was preserved by the Library of Congress, and the Internet Archive has them all on line.[1] As publications of the U.S. Government, they are not copyrighted.
Many are military-oriented. "Officer of the Day March", "It's a Long Way to Tipperary". Some big names, mixed in with the military bands, often with messages to the troops. Some good jazz. It's specialty content for the troops.
[1] https://archive.org/details/V-discs1-991943-1944/
Many are military-oriented. "Officer of the Day March", "It's a Long Way to Tipperary". Some big names, mixed in with the military bands, often with messages to the troops. Some good jazz. It's specialty content for the troops.
[1] https://archive.org/details/V-discs1-991943-1944/
Thanks a lot for digging this up, the outcome of introducing royalties is very interesting.
> I wonder if "The Orchestra that draws no salary" was as controversial at the time as "Artisans won't complain about work-life balance" is today.
I'm not sure about controversy, but I do think they will look similarly silly in retrospect.
Early vendors of new technology tend to over-promise and under-deliver. They sort of have to, as they are creating a new market. People need to be moved in order to be convinced they need it.
The technology (if there is real merit to it) usually evolves over time based on who pays for it, which helps separate the actual uses from imagined ones.
I do not think today's AI will replace everything, it's unclear where it will be used and where it wont. Just keep doing what you are doing. The salesmen are just doing their thing.
As for whether musicians specifically will be impacted, sure, some will. Good musicians, the ones who channel and share their feelings with listeners will always (well, until AI has something resembling real emotion) have work. Today's AI does not have emotion, and I expect people will know the difference. I'm sure the music industry will go wild trying, but people will always create music for themselves, and real emotion will resonate far further than 'art' created via a prompt.
I'm not sure about controversy, but I do think they will look similarly silly in retrospect.
Early vendors of new technology tend to over-promise and under-deliver. They sort of have to, as they are creating a new market. People need to be moved in order to be convinced they need it.
The technology (if there is real merit to it) usually evolves over time based on who pays for it, which helps separate the actual uses from imagined ones.
I do not think today's AI will replace everything, it's unclear where it will be used and where it wont. Just keep doing what you are doing. The salesmen are just doing their thing.
As for whether musicians specifically will be impacted, sure, some will. Good musicians, the ones who channel and share their feelings with listeners will always (well, until AI has something resembling real emotion) have work. Today's AI does not have emotion, and I expect people will know the difference. I'm sure the music industry will go wild trying, but people will always create music for themselves, and real emotion will resonate far further than 'art' created via a prompt.
> I wonder if "The Orchestra that draws no salary" was as controversial at the time as "Artisans won't complain about work-life balance" is today.
Ex-Orchestra player here.
I don't think so. A musician who's not playing in an orchestra pit in a play/performance can always play in a concert or in future times in a recording orchestra, or have a solo career. Using the same skill set they have, and even earning more in the process.
Employees replaced by AI find that their whole skill set captured by the said AI, and they're now irrelevant without a new set of skills. Getting a new skillset requires time, money and effort, and sometimes substantial background. What we're going through is much more damaging. The former one was transformative, not destructive.
Ex-Orchestra player here.
I don't think so. A musician who's not playing in an orchestra pit in a play/performance can always play in a concert or in future times in a recording orchestra, or have a solo career. Using the same skill set they have, and even earning more in the process.
Employees replaced by AI find that their whole skill set captured by the said AI, and they're now irrelevant without a new set of skills. Getting a new skillset requires time, money and effort, and sometimes substantial background. What we're going through is much more damaging. The former one was transformative, not destructive.
I agree with respect to that old advertisement, but GenAI + acoustic physical modeling (SWAM) are likely poised to disrupt music more than you'd think.
You can 100% believe that the moment a composer/company/etc. can sketch out the cello/viola/whatever line of a song as pure midi and have an AI that can render it in a realistic articulable fashion (think some kind of futuristic band in a box coupled with physical modeling of the instrument)... a TON OF GIG/SESSION musicians will unfortunately lose their jobs.
It also wouldn't surprise me with the advent of MPE (Seaboard, Linnstrument, Osmose) that we start to see more instrumental approximations that are considered good enough for many lines of work.
Obviously though live performances will always have their place.
https://youtu.be/11Qprwtzl6s?si=qKlWX35zeOHIkiSS
You can 100% believe that the moment a composer/company/etc. can sketch out the cello/viola/whatever line of a song as pure midi and have an AI that can render it in a realistic articulable fashion (think some kind of futuristic band in a box coupled with physical modeling of the instrument)... a TON OF GIG/SESSION musicians will unfortunately lose their jobs.
It also wouldn't surprise me with the advent of MPE (Seaboard, Linnstrument, Osmose) that we start to see more instrumental approximations that are considered good enough for many lines of work.
Obviously though live performances will always have their place.
https://youtu.be/11Qprwtzl6s?si=qKlWX35zeOHIkiSS
The comment I have written taken both examples during their eras of the respective advertisements.
So it was what records did to orchestra players vs. what AI did to programmers. Good sound fonts, a good sound cards (DACs) and MIDI was already good enough to render complex orchestrations at impeccable quality since 00s. We're just seeing it trickle down to ordinary attic musicians' budget limits.
I like Venus Theory's channel and videos for that reason. He shows what can be done with bog standard software of today, but it was already possible yesterday.
So it was what records did to orchestra players vs. what AI did to programmers. Good sound fonts, a good sound cards (DACs) and MIDI was already good enough to render complex orchestrations at impeccable quality since 00s. We're just seeing it trickle down to ordinary attic musicians' budget limits.
I like Venus Theory's channel and videos for that reason. He shows what can be done with bog standard software of today, but it was already possible yesterday.
I'm not sure if I'm dumb or something, but I don't see the difference in your examples.
First: Musician used to play orchestra, but now automation might replace them. Musician can take their skills elsewhere as they still posses them
Second: Software developer (for example) used to write CRUD apps, but now automation might replace them. Developer can take their skills elsewhere as they still posses them.
I don't see how in the second example, somehow the skills as "destroyed" while in the first example, they're used somewhere else instead of destroyed.
First: Musician used to play orchestra, but now automation might replace them. Musician can take their skills elsewhere as they still posses them
Second: Software developer (for example) used to write CRUD apps, but now automation might replace them. Developer can take their skills elsewhere as they still posses them.
I don't see how in the second example, somehow the skills as "destroyed" while in the first example, they're used somewhere else instead of destroyed.
If automation takes your job, there are now less overall positions and more people competing for them (you and everyone else who got laid off) so its not like you can "just" take your skills elsewhere, there may be nowhere else to go.
How is that different from the hypothetical Cello player? Once enough automatized cello players exists, how could they go anywhere else?
Thats exactly the point I was trying to make.
This is assuming we're at some sort of job ceiling and no new jobs will ever be created.
A cello player is a cello player everywhere. They can use the same instrument, same reflexes, and what they used to play in a different environment.
Consider a developer versed in CRUD apps obsoleted by a code generator AI and, they need to pivot to something different. e.g.: UI, simulation, games or system. That pivot will require different languages, different mindset, different knowledge (simulation and games needs different sets of deep math, UI needs new tools and paradigms, system requires a different knowledge stack from hardware to lower levels of OS, etc.).
They need to learn, get experience, go through hoops, etc. A musician can play in an orchestra pit in 2PM and play with a symphony at 8PM. They just need a little rest and a meal in between (had friends doing exactly that).
If said musician is forced to change their instrument. e.g. from cello to tuba, or cello to timpani, the effect will be the same as software developer's. Some things would carry over, but others needs to be replaced completely.
Consider a developer versed in CRUD apps obsoleted by a code generator AI and, they need to pivot to something different. e.g.: UI, simulation, games or system. That pivot will require different languages, different mindset, different knowledge (simulation and games needs different sets of deep math, UI needs new tools and paradigms, system requires a different knowledge stack from hardware to lower levels of OS, etc.).
They need to learn, get experience, go through hoops, etc. A musician can play in an orchestra pit in 2PM and play with a symphony at 8PM. They just need a little rest and a meal in between (had friends doing exactly that).
If said musician is forced to change their instrument. e.g. from cello to tuba, or cello to timpani, the effect will be the same as software developer's. Some things would carry over, but others needs to be replaced completely.
I feel like you're ignoring the amount of training that an expert musician does to learn a specific piece of music and maintain their proficiency in it. For the most part, they don't go to professional gigs and play something novel.
Traditional musicians have a whole live or real-time performance aspect as do athletes, dancers, etc. I think the amount of time they spend preparing for this can be similar to the time we spend working on one programming task. Bigger problems take more preparation. The difference is we don't have to then do a live performance after we've figured out how to program it. We just accumulate a recorded artifact and ship it, rather than doing a live recital after we've figured out all the difficult bits.
So it's difficult to draw parallels. Programmers have more in common with writers, painters, and sculptors who all work on a tangible artifact that is delivered after the fact and which acts as an accumulator of time-shifted work product. Some crafts, like glass blowing, are more like live music in that you develop a skill but then have to make a real-time performance each time you produce the artifact.
Traditional musicians have a whole live or real-time performance aspect as do athletes, dancers, etc. I think the amount of time they spend preparing for this can be similar to the time we spend working on one programming task. Bigger problems take more preparation. The difference is we don't have to then do a live performance after we've figured out how to program it. We just accumulate a recorded artifact and ship it, rather than doing a live recital after we've figured out all the difficult bits.
So it's difficult to draw parallels. Programmers have more in common with writers, painters, and sculptors who all work on a tangible artifact that is delivered after the fact and which acts as an accumulator of time-shifted work product. Some crafts, like glass blowing, are more like live music in that you develop a skill but then have to make a real-time performance each time you produce the artifact.
Actually no. When you're learning a piece from scratch, you start with 60bpm or slower and slowly polish your performance and reach to the normal speed of the piece. If you're going to perform with an orchestra, you also rehearse a lot. We started 14 weeks before the actual concert date (used to play double bass in a symphony).
Learning the instrument is akin to learning the programming language. Music theory is the same thing as programming languages / intro to computation courses. You pass through them once and revisit as needed. Not everyday.
However, when you finish a piece, 95% of the skill required to play it again is permanent. You just rehearse it a couple of times and, viola. The performance is there.
The constant exercise part is very on par with what programmers do every day. You either code (work) or playfight/practice (hobby projects). Also, composers and genres have similar structures in their pieces, so when you get used to them, you can just fly through them, even if you play for the first time.
There are a couple of comments which say that we're talking about senior programmers here. Senior musicians can play what they see in the first pass, or just improvise/remix what they hear for the first time (see [0]).
So, in most cases, the partitions in front of the musicians are cheat sheets. I remember just looking at the section and playing half (sometimes most) of it without even looking to it.
The live/improvised performance is akin to "hacking" in programming. I had my mentor who taught me playing double bass had to improvise a bridge section of a piece because he forgot that specific part. He said that since he knows the motifs, he bridged the part on the fly, in a solo performance in conservatory, and he got a pass because how he handled it. This is how we hack something together when we're in a rough spot and dig our way out of it by knowing what we're doing, but improvising and trusting the process.
So, I draw these conclusions from 10+ years of live concerts and 15+ years of professional sysadmin/programming/research work.
[0]: https://www.youtube.com/watch?v=3pYHCGYJbw0
Learning the instrument is akin to learning the programming language. Music theory is the same thing as programming languages / intro to computation courses. You pass through them once and revisit as needed. Not everyday.
However, when you finish a piece, 95% of the skill required to play it again is permanent. You just rehearse it a couple of times and, viola. The performance is there.
The constant exercise part is very on par with what programmers do every day. You either code (work) or playfight/practice (hobby projects). Also, composers and genres have similar structures in their pieces, so when you get used to them, you can just fly through them, even if you play for the first time.
There are a couple of comments which say that we're talking about senior programmers here. Senior musicians can play what they see in the first pass, or just improvise/remix what they hear for the first time (see [0]).
So, in most cases, the partitions in front of the musicians are cheat sheets. I remember just looking at the section and playing half (sometimes most) of it without even looking to it.
The live/improvised performance is akin to "hacking" in programming. I had my mentor who taught me playing double bass had to improvise a bridge section of a piece because he forgot that specific part. He said that since he knows the motifs, he bridged the part on the fly, in a solo performance in conservatory, and he got a pass because how he handled it. This is how we hack something together when we're in a rough spot and dig our way out of it by knowing what we're doing, but improvising and trusting the process.
So, I draw these conclusions from 10+ years of live concerts and 15+ years of professional sysadmin/programming/research work.
[0]: https://www.youtube.com/watch?v=3pYHCGYJbw0
Thanks for the perspective. I'm not a musician but have some among my friends and family where I've observed their general approach over decades.
I think your point about similarities among some composers or genres is akin to the point about similarities in a genre of programming. You can easily produce your Nth version of CRUD app, audio or video filter, standard statistical analysis, etc. But changing to a different genre can require significant practice and learning. I think musicians face this just like programmers, without having to change instruments.
I think that musicians must do a lot more regular work, like athletes, to retain or recover their physical form. But, I don't really believe there are "programmer's hands" that can get clumsy after mere months of downtime. After all, even if our typing slows down, it isn't really a gating factor in being able to produce complex products. It might even be a benefit, when it biases one towards more compact solutions rather than churning out baroque monstrosities!
I think your point about similarities among some composers or genres is akin to the point about similarities in a genre of programming. You can easily produce your Nth version of CRUD app, audio or video filter, standard statistical analysis, etc. But changing to a different genre can require significant practice and learning. I think musicians face this just like programmers, without having to change instruments.
I think that musicians must do a lot more regular work, like athletes, to retain or recover their physical form. But, I don't really believe there are "programmer's hands" that can get clumsy after mere months of downtime. After all, even if our typing slows down, it isn't really a gating factor in being able to produce complex products. It might even be a benefit, when it biases one towards more compact solutions rather than churning out baroque monstrosities!
> You just rehearse it a couple of times and, viola.
Been scratching my head for a few minutes, and I still can't decide whether this was autocorrect at work or a musician's joke.
Opting for the latter, and thanks for the laughs :)
Been scratching my head for a few minutes, and I still can't decide whether this was autocorrect at work or a musician's joke.
Opting for the latter, and thanks for the laughs :)
> Traditional musicians have a whole live or real-time performance aspect as do athletes, dancers, etc. I think the amount of time they spend preparing for this can be similar to the time we spend working on one programming task.
Using the word “one” here is a very subtle, disingenuous way of trying to make your point, it’s almost clever.
Using the word “one” here is a very subtle, disingenuous way of trying to make your point, it’s almost clever.
An insightful comment! Had never drawn those parallels before -- great call.
> A cello player is a cello player everywhere. They can use the same instrument, same reflexes, and what they used to play in a different environment.
But programming is exactly the same. A programmer knows how to program, and they can program all sorts of different things, with different languages, without having learn how to program from scratch each time. Most programming languages/projects are more similar to the rest, than different.
> A musician can play in an orchestra pit in 2PM and play with a symphony at 8PM.
In your developer example, it would be more fitting to compare it to that they could build CRUD apps, or desktop applications, and it wouldn't be that much different. Plenty of programmers work in multiple "fields" at the same time, just like a Cello player might.
But programming is exactly the same. A programmer knows how to program, and they can program all sorts of different things, with different languages, without having learn how to program from scratch each time. Most programming languages/projects are more similar to the rest, than different.
> A musician can play in an orchestra pit in 2PM and play with a symphony at 8PM.
In your developer example, it would be more fitting to compare it to that they could build CRUD apps, or desktop applications, and it wouldn't be that much different. Plenty of programmers work in multiple "fields" at the same time, just like a Cello player might.
> But programming is exactly the same. A programmer knows how to program
That approach works much better for more experienced senior devs. It takes time to go from knowing a particular language for a particular type of software to recognizing the universal patterns and picking up new languages and types of software project quickly.
I've been in it for around 15 years and feel pretty comfortable picking up a new language and jumping around between stack, frontend/back end/db, and languages. That takes time though and I still have plenty I could learn. 5 or 10 years ago I may have felt confident in that bit I'm not so sure I'd have been able competitive if the industry all went into the job market post-LLM layoffs (hypothetical?).
That approach works much better for more experienced senior devs. It takes time to go from knowing a particular language for a particular type of software to recognizing the universal patterns and picking up new languages and types of software project quickly.
I've been in it for around 15 years and feel pretty comfortable picking up a new language and jumping around between stack, frontend/back end/db, and languages. That takes time though and I still have plenty I could learn. 5 or 10 years ago I may have felt confident in that bit I'm not so sure I'd have been able competitive if the industry all went into the job market post-LLM layoffs (hypothetical?).
> That approach works much better for more experienced senior devs.
I don't think we're talking about junior developers here since the counter-example is a Cello player in orchestras and symphonies, those have to be considered "senior" as well no?
> I've been in it for around 15 years and feel pretty comfortable picking up a new language and jumping around between stack, frontend/back end/db, and languages.
Yeah, but that's comparing it to a musician switching instrument, instead of just a musician switching the place they play. The comparison then would be that a desktop app programmer does a todo app, or they do a calendar app. Both involving still the same instrument/area of programming, but different environments of sorts.
I don't think we're talking about junior developers here since the counter-example is a Cello player in orchestras and symphonies, those have to be considered "senior" as well no?
> I've been in it for around 15 years and feel pretty comfortable picking up a new language and jumping around between stack, frontend/back end/db, and languages.
Yeah, but that's comparing it to a musician switching instrument, instead of just a musician switching the place they play. The comparison then would be that a desktop app programmer does a todo app, or they do a calendar app. Both involving still the same instrument/area of programming, but different environments of sorts.
I do agree with your points here, but they don't align with the original quote I was responding to.
> But programming is exactly the same. A programmer knows how to program.
This would be akin to saying a cello player knows how to orchestra, and changing instruments wouldn't be a problem.
Software development in the frontend, backend, database, etc are very different skills especially when at a non-junior level. Expecting someone to jump between them without much to any training is like expecting a cellist to jump over to the violin.
> But programming is exactly the same. A programmer knows how to program.
This would be akin to saying a cello player knows how to orchestra, and changing instruments wouldn't be a problem.
Software development in the frontend, backend, database, etc are very different skills especially when at a non-junior level. Expecting someone to jump between them without much to any training is like expecting a cellist to jump over to the violin.
> But programming is exactly the same.
Respectfully, no. You're right about picking up programming languages, but missing the nuance about developing different genres of software.
I develop utilities, material simulation systems (think finite element, boundary element, etc.), and used to develop an AI system (a multi-agent collectively intelligent system, an autonomous marketplace).
The knowledge required in each one of these is vastly different. First one requires OS knowledge and is generally I/O bound, so you try write good code, talk sensibly with the OS, but you don't need to optimize beyond the obvious pain points.
Writing simulations is completely different. I do care about the language, how it behaves, how I can extract every bit of performance from the CPU, while implementing numerical differential equations which needs to be exact, accurate and precise, while not compromising the performance of the codebase. I benchmark memory and CPU separately and as a whole, while not deviating from ground truth values. Otherwise things go very bad.
AI system was latency sensitive. I needed to make it fast while not bogging down the system as a whole, it needed to scale while being intelligent about what to do, and be flexible enough. This required strategies, self-tuning, etc. It was no neural net, so it was a completely different beast.
System programming is similar. Latency sensitive, talking correctly with the OS, and not bogging the system down while doing useful work.
Learning programming languages is easy. Implementing differential equations with demoscene levels of optimization while being exact and accurate is not.
Heck, even the usage patterns for the same programming language is different between different genres of software.
Respectfully, no. You're right about picking up programming languages, but missing the nuance about developing different genres of software.
I develop utilities, material simulation systems (think finite element, boundary element, etc.), and used to develop an AI system (a multi-agent collectively intelligent system, an autonomous marketplace).
The knowledge required in each one of these is vastly different. First one requires OS knowledge and is generally I/O bound, so you try write good code, talk sensibly with the OS, but you don't need to optimize beyond the obvious pain points.
Writing simulations is completely different. I do care about the language, how it behaves, how I can extract every bit of performance from the CPU, while implementing numerical differential equations which needs to be exact, accurate and precise, while not compromising the performance of the codebase. I benchmark memory and CPU separately and as a whole, while not deviating from ground truth values. Otherwise things go very bad.
AI system was latency sensitive. I needed to make it fast while not bogging down the system as a whole, it needed to scale while being intelligent about what to do, and be flexible enough. This required strategies, self-tuning, etc. It was no neural net, so it was a completely different beast.
System programming is similar. Latency sensitive, talking correctly with the OS, and not bogging the system down while doing useful work.
Learning programming languages is easy. Implementing differential equations with demoscene levels of optimization while being exact and accurate is not.
Heck, even the usage patterns for the same programming language is different between different genres of software.
I feel like you're mixing the domain which you are programming in, versus "programming" as a concept, while I'm focusing purely on programming.
I do understand that different domains require different skills, that much is evident in itself. But then we're moving on from just discussing programming to also discussing programming domains, which detracts a bit from the core discussion.
I do understand that different domains require different skills, that much is evident in itself. But then we're moving on from just discussing programming to also discussing programming domains, which detracts a bit from the core discussion.
My first comment already had domains in "pivoting" parts, so I didn't change the scope from comment to comment.
So domains is at the core of the discussion since the beginning, as the programming itself. At least that's how I formed my comment, and that's my intention while writing that comment.
So domains is at the core of the discussion since the beginning, as the programming itself. At least that's how I formed my comment, and that's my intention while writing that comment.
But if you're talking about domains in the programmer's example, you'd have to do the same for the cello player's example.
So in that case it would be that the cello player could seamlessly (without training) change between genres for example, which clearly isn't true.
So in that case it would be that the cello player could seamlessly (without training) change between genres for example, which clearly isn't true.
Changing genres are easy. Some of my orchestra mates were multi-genre (jazz/classic for example). I used to play metal and classic back in the day.
What’s hard is changing instruments, which I have given as an example in one of my comments. Yes I did go thorough that one, too.
What’s hard is changing instruments, which I have given as an example in one of my comments. Yes I did go thorough that one, too.
AI will replace programming languages, as optimizating compilers replaced Assembly programmers.
Anyone that thinks code generation will stay as is, is fooling themselves.
Anyone that thinks code generation will stay as is, is fooling themselves.
I don't see the point. If/when that happens, programmers start doing the thing that comes next. The thread was about skills, ASM skills aren't irrelevant for doing C, C skills aren't irrelevant for doing Python and so on.
One-trick ponies aren't good programmers in the first place.
One-trick ponies aren't good programmers in the first place.
Many things that come next isn't programming as we know it.
Already today, see SaaS products for content management, CMS and no-code frontend.
There is zero programming, what one ends up doing is configuring SaaS products to connect among themselves, plug data sources, have AI algorithms process marketing data, export a generated UI into Vercel/Nelify and that is about it for 90% of customers.
Already today, see SaaS products for content management, CMS and no-code frontend.
There is zero programming, what one ends up doing is configuring SaaS products to connect among themselves, plug data sources, have AI algorithms process marketing data, export a generated UI into Vercel/Nelify and that is about it for 90% of customers.
Well yea, of course you can say that on an open ended timeline.
Well, some apparently still think code generation won't go away, like those Assembly devs when Fortran was new.
Even if we consider a similar timeline, it means we have about 50 years to enjoy programming as we know it.
Even if we consider a similar timeline, it means we have about 50 years to enjoy programming as we know it.
> Consider a developer versed in CRUD apps obsoleted by a code generator AI and, they need to pivot to something different. e.g.: UI, simulation, games or system. That pivot will require different languages, different mindset, different knowledge (simulation and games needs different sets of deep math, UI needs new tools and paradigms, system requires a different knowledge stack from hardware to lower levels of OS, etc.).
This is nothing new, though. There used to be very lucrative job titles like "webmaster" or "web developer" whose daily work consisted of creating bespoke, static websites created with raw HTML and CSS. Whenever a customer wanted their website updated, even if just textual content updates, they got to bill a few hundred bucks to copy and paste the text into their site and upload the updated files onto whatever shared web hosting they were using.
Tools were invented: first WYSIWYG editors like Microsoft Frontpage, then content management systems so users could update their own websites, then full-on SaaS website designers like Wix, and now the current state of, well maybe your business doesn't even really need a website because you can just make a Facebook page instead.
When I was going to university in 2005, I was heavily warned by (cough) "experts" that due to this, plus the imminent wave of outsourcing of "IT" to low-cost developers in India and Bangladesh, that learning web-based software development was a dead-end career path, and US software developer salaries would cap out at $75k unless you got into management... yeah.
So, yes, you'll need to pivot as you always have in the industry. Any potential threat from AI isn't anything new. And it's not nearly as impactful as switching from playing cello to piano.
This is nothing new, though. There used to be very lucrative job titles like "webmaster" or "web developer" whose daily work consisted of creating bespoke, static websites created with raw HTML and CSS. Whenever a customer wanted their website updated, even if just textual content updates, they got to bill a few hundred bucks to copy and paste the text into their site and upload the updated files onto whatever shared web hosting they were using.
Tools were invented: first WYSIWYG editors like Microsoft Frontpage, then content management systems so users could update their own websites, then full-on SaaS website designers like Wix, and now the current state of, well maybe your business doesn't even really need a website because you can just make a Facebook page instead.
When I was going to university in 2005, I was heavily warned by (cough) "experts" that due to this, plus the imminent wave of outsourcing of "IT" to low-cost developers in India and Bangladesh, that learning web-based software development was a dead-end career path, and US software developer salaries would cap out at $75k unless you got into management... yeah.
So, yes, you'll need to pivot as you always have in the industry. Any potential threat from AI isn't anything new. And it's not nearly as impactful as switching from playing cello to piano.
I can recommend a silent film with real live music to everyone. I've been to a few at the Midnight Sun film Festival.
It can be really good.
It can be really good.
I've read that there was familiar controversy over player-piano rolls in the early 1900s/late 1800s. They'd be created in the eastern US and then be duplicated out west, potentially putting pianists out of a job.
Yes. That's why the copyright license to record a composition is called a "mechanical license".[1]
[1] https://en.wikipedia.org/wiki/Mechanical_license
[1] https://en.wikipedia.org/wiki/Mechanical_license
[deleted]
[deleted]
23B1(1)
I wonder if "The Orchestra that draws no salary" was as controversial at the time as "Artisans won't complain about work-life balance" is today.