I successfully retrained myself for AI. What you’re proposing is possible, but it was extremely difficult and required a sustained and disciplined effort over a period of years. It was like trying to do a whole graduate degree through self-imposed study.
In brief, here’s my story. I graduated with a PhD in linguistics in 2001. I was also a competent programmer on the side. As a grad student, my studies were focused on pure linguistics, but I kept picking up odd jobs which fell in the overlap between computers and human language.I was aiming for a tenure-track job as a professor. After I graduated, though, it became clear that this was not where things were headed for me. Something like 4 out of 5 new PhD who try to get tenure-track jobs don’t get them. I found myself stuck in an adjunct professor position on a ramen-noodle salary. So, I took a hard look at what else I could do.
The obvious move was to get into Natural Language Processing, which is the branch of AI concerning human language. This would build on what I already knew about computers and about human language. I did eventually succeed at this, but it took years of effort. I did all of the following:
I taught a basic undergrad course in NLP. This was one of my last teaching assignments before I moved to industry, and it was a good way to force myself to learn some of the basics thoroughly. I spent a whole summer prepping for the course. I collected syllabi of other NLP courses to figure out what to cover. I ended up covering n-grams, Hidden Markov Models, had the students build a statistical spell checker, etc.
I took three evening math courses (one per semester) through a university extension school to fill some long-standing math weaknesses. The most important math course was linear algebra, which is absolutely essential for AI. If you haven’t already had a stats course, you’ll need that too.
I went to professional conferences in NLP, and listened to as many talks as I could. In the beginning, a lot of the talks were over my head, but I wrote down every term I didn’t know, and looked it up later (e.g. “What is ‘stochastic gradient descent’?). Gradually, the talks became more comprehensible.
Read, read, read. I had multiple textbooks on NLP and on machine learning. I was always studying them. I printed out academic articles. I printed out Wikipedia articles on various topics in math, machine learning, AI, and NLP.
I went to MeetUps on AI, machine learning, and NLP. Fortunately, I was living in a city where there were lots of these.
Sometimes I had to get creative with the solutions. At one point, I needed to learn how to use something called Conditional Random Fields. I asked around, found a grad student who was specializing in CRFs, and paid him $120 to answer my questions for a few hours on a Saturday and to show me how to use Mallet, a package which supports CRFs.
I seriously considered going back to school. It would have been a luxury to have someone teach me all this stuff rather than teach it to myself. Since I already had a Ph.D., though, it didn’t make sense to get another degree. I looked around, but there just wasn’t any program that seemed like a fit for someone in my situation.
I can now finally consider myself to be an NLP professional. I’m working in that field, and I regularly do stuff with machine learning and other AI techniques. My current job is in the area of machine translation (e.g. French to English, or whatever language pairs the company needs).
The long effort has paid off, because I’m in demand. It was an awful lot of work to get here, though.
Management knows more than I do about how to manage a business. I know more than they do about how to build technology.
Management is paying for the use of my brain. Good managers will give serious consideration to what their hired brains are telling them.
Of course, in any real-world situation, plenty of poor decisions come down, even if your management is pretty good. So when that happens, you have a few options:
1) You can follow orders, even though you know it's a bad judgment call; or 2) You can try to convince management differently (which sometimes works); or 3) You can do something rogue to mitigate the effects of bad decisions.
Anyone in a technical industry is regularly engaged in this balancing act.
I'd note that there is rarely a very clear dividing line between doing something rogue versus exercising judgment within the range of your own authority. There have been plenty of times when I've undertaken efforts which were neither authorized nor prohibited. I've never gotten in trouble for this. Of course some efforts get silently ignored, but others get adopted and praised.
At my last job, I spent three days coding up a solution which would save us days of work on every client-facing project. I had been thinking about the problem for a long time and saw a simple and elegant solution. It was ready to go, including testing and documentation. When I demoed it, folks were impressed.
Unfortunately, management had the idea that the way to contain costs was to have the Product division develop these kinds of tools. My division was supposed to focus on deploying Product’s solutions to clients, not build solutions ourselves. Management could see the value in my solution; they just didn’t like the fact that it had come from me, not from Product.
So I was told to write up a spec for the solution I had already implemented, and give it to Product to reimplement. I did that, but Product was notoriously slow and ineffective. They had way too many masters to serve, and they weren’t immersed in our day-to-day work to understand our needs.
Two and a half years later, the solution was still not rolled out. I was still trying to get Product to fix the fatal bugs in their crappy implementation. I had escalated it multiple times.
I ended up quitting that job in disgust. The case I just described was a symptom of a large and serious organizational problem; I kept running up against it. In my resignation letter, I did the math to show management how many hundreds of hours we would have saved by now if we had adopted my solution when I wrote it. I sent that letter around to a bunch of senior managers. There was a belated plea for me to stay, but I already had another job lined up.
I do think I know more about technology than management does. Management knows more than I do about how to run a business. Neither one of us has the entire picture. We have to inform each other as well as we can, so that our business decisions reflect good judgment across all of our areas of expertise.
Sometimes we have to explain things to each other, and sometimes those explanations need to go into depth. Some of my best moments in business have been when someone went to the whiteboard and effectively taught a little class.
There is a reason why management is asking for it.
The reason might be one of these two:
1. Management knows what they're talking about: there's some valid business reason why the information needs to be in the requested form; and the tech guy just isn't aware of that reason.
2. Management thinks they know what they want, but their request reflects an incomplete understanding as to what technical solutions are possible, and which one would really best serve the business.
I encounter both situations regularly. Sometimes I investigate and find out that management really does have good reasons. Sometimes I conclude that I'm dealing with case #2 above. It's not that I think management is stupid; it's just that their expertise is in a different area from mine. I often try to educate, depending on how important I think the issue is. Fairly often, my effort succeeds: managers generally want to do right for the business; they understand that the tech guy knows things and is worth listening to; and sometimes they agree that my proposal is better.
However, of course the effort doesn't always succeed. Unless you're writing software on your own without having to please clients or management (e.g. as a hobby, or in an academic setting), it's just a part of life as a paid tech guy that you sometimes have to implement decisions which were made without the benefit of as much tech expertise as you have yourself.
The article says that they're using a genetic algorithm. I'm no expert at AI, but my understanding is that an ordinary expert system doesn't use a genetic algorithm; an expert system just involves percolating propositions through a bunch of human-specified if/then statements.
I'd hazard a guess that the system described here is using the human-specified rules as part of the fitness function for the genetic algorithm. That's one way a system could use human-specified rules, but I think it's different from how an ordinary expert system uses them.
If you can call this an "expert system", then at a minimum, it looks like it's pushing the boundaries of the definition of "expert system".
True, but the null hypothesis is that men and women are equally capable at CS, however you measure that. Likewise with whites and blacks. Unless there's data to indicate otherwise, I'm assuming that knowing somebody's race or sex doesn't tell you anything about how likely they are to be good at CS.
The numbers might give the impression that Google and Yahoo are unfairly discriminating against blacks and women. To determine whether that's the case, I think you need to know two things:
--Among Google and Yahoo employees, what percentage are black? What percentage are women? --Among CS graduates, what percentage are black? What percentage are women?
(I'm simplifying here by assuming that every hire at Google and Yahoo is a CS graduate.)
If the two sets of numbers differ significantly, then it could indicate discriminatory hiring practices. If the numbers are the same, then it would seem to indicate that Google and Yahoo are evenhandedly hiring from the pool of available candidates, and that the cause of the inequality is further upstream.
I don't think anyone claims that open-source software won't ever have security issues. The claim is that the open-source model tends to find and correct the flaws more effectively than the closed-source model, and that the soundness of the resulting product tends to be better on average.
One case does not disprove that. The key words there are "tends" and "on average".
There have been various alternative calendars proposed, and some of them have the property that there's a special day in the yearly calendar which doesn't count as part of the regular seven-day-per-week cycle (such as the "month zero" proposed here).
A significant objection is that some religions require that every seventh day be kept as a holy day. If the calendar contains a day which isn't part of the regular week, then there are sometimes more than seven days between one weekly holy day and the next.
It's not a consideration for me personally. However, I'm sure that this feature would lead to significant resistance to the adoption of such a calendar.
Part of the proposal here is to reduce the U.S. to two time zones. The Eastern time zone would be on the same time as what's now Central Standard Time.
I'm in Boston, MA. Under the proposed change, sunset in December would come at 3:11 p.m. Um, no, thanks.
I dropped out of high school in 1983. I was being heavily harassed for being openly gay. I could take it no longer.
I took my GED and passed it easily on the first try. Then I worked my ass off, largely financed my own education, and eventually got a PhD from one of the Ivy League universities. Now I have a successful career.
If the option of the GED hadn't been there for me, I would have been at a dead end.
In the 1990s, I wanted to get into developing GUI apps for Linux. The single biggest reason why I gave up on it was that the Linux GUI effort fractured into KDE and Gnome camps.
At the time, I figured that one of the two would win out over the other. There was no telling which might win, and I was reluctant to back what might be the losing horse. This was a serious demotivator. Of course, 15 years later, we've ended up with the worst of both worlds: many Linux installations take up the disk space for both, and we've got two unharmonized APIs continuing to fight for a following.
With MacOS, there is no question what API you should use. Apple offers a very clear path. For that reason, I feel more confident developing for that platform.
Sorry, but this is bull. Your statement that "voice recognition is at its limits phonetically" is just wrong. I work in the voice recognition industry, and in the past five years, I've seen the recognition error rate markedly and measurably go down, and this trend is continuing.
There are actually two kinds of models involved in voice recognition:
1) the acoustic model (which has to do with looking at a sequence of time slices of the acoustic signal and working out what sequence of phonemes could most likely have given rise to it). You say that voice recognition is at its limits phonetically, but these models are actually getting better over time with larger sets of training data, and the improved models measurably result in a lowered word error rate.
2) the language model (which has to do with specifying which words exist, and in what order they are most likely to occur). These language models can be very simple, as in the case of a yes/no question in a phone-based app (your model might accept "yes" and "yes ma'am", but not any arbitrary English utterance); or they can be very large, as in the case of a general-purpose dictation application.
In conjunction with the recognizer, what these two models give you is a raw string of recognized words. What sort of processing you do on that string is a separate question. There are obviously all sorts of things you can do with the string. The parsing and processing techniques are getting more sophisticated, and are getting integrated with other systems in interesting ways. This is largely a separate question from the accuracy of the string itself, which is the output of the recognizer (I say "largely" because your application might activate a different language model based on the current context, which does affect recognition accuracy).
Suppose there was a large apartment building, and child pornography was found in one apartment. Should the government have the right to indefinitely hold the belongings of the residents of all of the other apartments in the building?
In the very unlikely event that a kind-hearted, mentally disabled person could become dictator, that person would not be dictator for very long. The first concern of an individual who is in power is to stay in power, because he or she is continually in competition with others who want power.
If a leader stays in power for a while without doing ruthless things, it just means that that leader had the good fortune of not being presented with situations where ruthlessness was required. I doubt that this happens very often.
How does the size of the user base of Dancer compare to that of Catalyst? How do the growth curves compare? Are these things known?
Having a larger support community is one factor I need to consider, partly because it's easier to get help when I need it, and partly because a more widely-used framework is likely to continue to be supported over time. The inherent technical superiority is, of course, another factor to consider.
What do you guys think of Catalyst these days? Does Catalyst still have enough support behind it to make it worth my while to sit down and really learn Catalyst?
This is assuming that I already know Perl well, and that I'm also not interested in switching to another language at the present time.
I've still got the old Apple ][ wire-bound manuals. Yeah, I know, it's extremely unlikely that I'll ever again go poking into the assembly code of Apple DOS, but I've just never been able to consign those manuals to the trash bin.
I've also still got the manuals for the TRS-80 Color Computer. I can still flip them open and immediately remember writing programs using those exact BASIC commands.
You missed the joke. CinthIA = CIA. The woman whose voice is used for one of the numbers stations is known as Cynthia because of the station's supposed connection to the CIA.
This is precisely my point: the free software community should have thrown away one of the two APIs ten years ago.
Choice is not always a good thing. Would you be better off if you had a "choice" of different voltages and socket types for your various household appliances? Is it important to be able to choose a hair dryer which runs on 60vDC and a toaster which runs on 150vAC? Oh, sure, you could have all kinds of voltage adapters for "interoperability", but there's no need for any adapters if everything runs on the same current.
The functional differences between Gnome and KDE are trivial; they are minor variations on the same window/widget paradigm found on MacOS and Windows. If there are individual differences in taste, they would be better handled as user preference settings within a single environment.
I think the free software community has really shot itself in the foot by continuing this division between Gnome and KDE.
Around ten years ago, I was interested in building some GUI apps for Linux, but there was no clear path as to which of the two GUI APIs I should learn. I found the lack of a clear path to be enough of a discouragement that I ended up losing interest. I doubt that I'm the only one who has felt that way about it.
Paying your taxes is one of your basic duties as a citizen. Other than jury duty, taxes are the only compulsory duty expected of U.S. citizens (we don't even have compulsory military service, much less any form of conscripted labor). In case you need to have this spelled out, taxes are what make it possible for us to have roads, public schools, a police department, an army and a navy, and so on.
Of course, there's plenty of room for debate about how much we should be taxed, and how the money can most wisely be spent. Liberals have a particular view on this question.
Don't confuse this question with the question of "freedom". You may not agree with the liberal view on taxation and government spending, but you're just plain mistaken if you think that liberals oppose freedom of speech, freedom of religion, freedom of association, and so on. Liberals strongly support those freedoms. There is nothing in the liberal view on taxation and government budgeting which contradicts those freedoms.
To answer your question about age grading, you have to look at a population at more than one point in time. In cases where this has been done (e.g. speakers of central American Spanish), what we find is that young adults have the highest percentage of the incoming feature (higher than both children and older adults). As those same young adults get older, their use of the incoming feature does decline some, but not down to the levels of the previous generation. The 40-year-olds today have a higher percentage of the incoming variant than the 40-year-olds twenty years ago.
Variants in speech can serve as social markers which you use to identify yourself as a member of a group. As a guess, I imagine that the slight decline in use of the incoming variant as you get older has less to do with "learning standard English better", and more to do with it not being quite as important to sound cool as you get older. As a 40-year-old, you probably still wear clothes which identify you as a member of a certain group, but you probably don't dress in quite as trendy a way as you did when you were 20.
Actually, it appears that AAVE is a product of the Great Northern Migration of African-Americans in the early 20th century. Prior to that time, there was little to no distinction between the dialects of southern whites and southern blacks.
The pieces of evidence for this claim include:
Phonograph recordings made in the 1930's of former slaves
Diaries and letters written by semi-literate slaves and former slaves in the 19th century. Since the writers were semi-literate, the spelling is a better indication of the pronunciation than standard spelling would be.
Something which linguists call "age grading". If you take speakers of AAVE today and compare younger speakers with older speakers, the younger speakers actually have a higher percentage occurrence of the distinctive features of AAVE. This suggests that AAVE is becoming increasingly distinct from standard American English over time.
There are other pieces of evidence as well, but those are some of the important ones.
I seriously considered going back to school. It would have been a luxury to have someone teach me all this stuff rather than teach it to myself. Since I already had a Ph.D., though, it didn’t make sense to get another degree. I looked around, but there just wasn’t any program that seemed like a fit for someone in my situation. I can now finally consider myself to be an NLP professional. I’m working in that field, and I regularly do stuff with machine learning and other AI techniques. My current job is in the area of machine translation (e.g. French to English, or whatever language pairs the company needs). The long effort has paid off, because I’m in demand. It was an awful lot of work to get here, though.
Management knows more than I do about how to manage a business. I know more than they do about how to build technology.
Management is paying for the use of my brain. Good managers will give serious consideration to what their hired brains are telling them.
Of course, in any real-world situation, plenty of poor decisions come down, even if your management is pretty good. So when that happens, you have a few options:
1) You can follow orders, even though you know it's a bad judgment call; or
2) You can try to convince management differently (which sometimes works); or
3) You can do something rogue to mitigate the effects of bad decisions.
Anyone in a technical industry is regularly engaged in this balancing act.
I'd note that there is rarely a very clear dividing line between doing something rogue versus exercising judgment within the range of your own authority. There have been plenty of times when I've undertaken efforts which were neither authorized nor prohibited. I've never gotten in trouble for this. Of course some efforts get silently ignored, but others get adopted and praised.
At my last job, I spent three days coding up a solution which would save us days of work on every client-facing project. I had been thinking about the problem for a long time and saw a simple and elegant solution. It was ready to go, including testing and documentation. When I demoed it, folks were impressed.
Unfortunately, management had the idea that the way to contain costs was to have the Product division develop these kinds of tools. My division was supposed to focus on deploying Product’s solutions to clients, not build solutions ourselves. Management could see the value in my solution; they just didn’t like the fact that it had come from me, not from Product.
So I was told to write up a spec for the solution I had already implemented, and give it to Product to reimplement. I did that, but Product was notoriously slow and ineffective. They had way too many masters to serve, and they weren’t immersed in our day-to-day work to understand our needs.
Two and a half years later, the solution was still not rolled out. I was still trying to get Product to fix the fatal bugs in their crappy implementation. I had escalated it multiple times.
I ended up quitting that job in disgust. The case I just described was a symptom of a large and serious organizational problem; I kept running up against it. In my resignation letter, I did the math to show management how many hundreds of hours we would have saved by now if we had adopted my solution when I wrote it. I sent that letter around to a bunch of senior managers. There was a belated plea for me to stay, but I already had another job lined up.
I do think I know more about technology than management does. Management knows more than I do about how to run a business. Neither one of us has the entire picture. We have to inform each other as well as we can, so that our business decisions reflect good judgment across all of our areas of expertise.
Sometimes we have to explain things to each other, and sometimes those explanations need to go into depth. Some of my best moments in business have been when someone went to the whiteboard and effectively taught a little class.
There is a reason why management is asking for it.
The reason might be one of these two:
1. Management knows what they're talking about: there's some valid business reason why the information needs to be in the requested form; and the tech guy just isn't aware of that reason.
2. Management thinks they know what they want, but their request reflects an incomplete understanding as to what technical solutions are possible, and which one would really best serve the business.
I encounter both situations regularly. Sometimes I investigate and find out that management really does have good reasons. Sometimes I conclude that I'm dealing with case #2 above. It's not that I think management is stupid; it's just that their expertise is in a different area from mine. I often try to educate, depending on how important I think the issue is. Fairly often, my effort succeeds: managers generally want to do right for the business; they understand that the tech guy knows things and is worth listening to; and sometimes they agree that my proposal is better.
However, of course the effort doesn't always succeed. Unless you're writing software on your own without having to please clients or management (e.g. as a hobby, or in an academic setting), it's just a part of life as a paid tech guy that you sometimes have to implement decisions which were made without the benefit of as much tech expertise as you have yourself.
The article says that they're using a genetic algorithm. I'm no expert at AI, but my understanding is that an ordinary expert system doesn't use a genetic algorithm; an expert system just involves percolating propositions through a bunch of human-specified if/then statements.
I'd hazard a guess that the system described here is using the human-specified rules as part of the fitness function for the genetic algorithm. That's one way a system could use human-specified rules, but I think it's different from how an ordinary expert system uses them.
If you can call this an "expert system", then at a minimum, it looks like it's pushing the boundaries of the definition of "expert system".
True, but the null hypothesis is that men and women are equally capable at CS, however you measure that. Likewise with whites and blacks. Unless there's data to indicate otherwise, I'm assuming that knowing somebody's race or sex doesn't tell you anything about how likely they are to be good at CS.
The numbers might give the impression that Google and Yahoo are unfairly discriminating against blacks and women. To determine whether that's the case, I think you need to know two things:
--Among Google and Yahoo employees, what percentage are black? What percentage are women?
--Among CS graduates, what percentage are black? What percentage are women?
(I'm simplifying here by assuming that every hire at Google and Yahoo is a CS graduate.)
If the two sets of numbers differ significantly, then it could indicate discriminatory hiring practices. If the numbers are the same, then it would seem to indicate that Google and Yahoo are evenhandedly hiring from the pool of available candidates, and that the cause of the inequality is further upstream.
I don't think anyone claims that open-source software won't ever have security issues. The claim is that the open-source model tends to find and correct the flaws more effectively than the closed-source model, and that the soundness of the resulting product tends to be better on average.
One case does not disprove that. The key words there are "tends" and "on average".
There have been various alternative calendars proposed, and some of them have the property that there's a special day in the yearly calendar which doesn't count as part of the regular seven-day-per-week cycle (such as the "month zero" proposed here).
A significant objection is that some religions require that every seventh day be kept as a holy day. If the calendar contains a day which isn't part of the regular week, then there are sometimes more than seven days between one weekly holy day and the next.
It's not a consideration for me personally. However, I'm sure that this feature would lead to significant resistance to the adoption of such a calendar.
Part of the proposal here is to reduce the U.S. to two time zones. The Eastern time zone would be on the same time as what's now Central Standard Time.
I'm in Boston, MA. Under the proposed change, sunset in December would come at 3:11 p.m. Um, no, thanks.
I dropped out of high school in 1983. I was being heavily harassed for being openly gay. I could take it no longer.
I took my GED and passed it easily on the first try. Then I worked my ass off, largely financed my own education, and eventually got a PhD from one of the Ivy League universities. Now I have a successful career.
If the option of the GED hadn't been there for me, I would have been at a dead end.
In the 1990s, I wanted to get into developing GUI apps for Linux. The single biggest reason why I gave up on it was that the Linux GUI effort fractured into KDE and Gnome camps.
At the time, I figured that one of the two would win out over the other. There was no telling which might win, and I was reluctant to back what might be the losing horse. This was a serious demotivator. Of course, 15 years later, we've ended up with the worst of both worlds: many Linux installations take up the disk space for both, and we've got two unharmonized APIs continuing to fight for a following.
With MacOS, there is no question what API you should use. Apple offers a very clear path. For that reason, I feel more confident developing for that platform.
Sorry, but this is bull. Your statement that "voice recognition is at its limits phonetically" is just wrong. I work in the voice recognition industry, and in the past five years, I've seen the recognition error rate markedly and measurably go down, and this trend is continuing.
There are actually two kinds of models involved in voice recognition:
1) the acoustic model (which has to do with looking at a sequence of time slices of the acoustic signal and working out what sequence of phonemes could most likely have given rise to it). You say that voice recognition is at its limits phonetically, but these models are actually getting better over time with larger sets of training data, and the improved models measurably result in a lowered word error rate.
2) the language model (which has to do with specifying which words exist, and in what order they are most likely to occur). These language models can be very simple, as in the case of a yes/no question in a phone-based app (your model might accept "yes" and "yes ma'am", but not any arbitrary English utterance); or they can be very large, as in the case of a general-purpose dictation application.
In conjunction with the recognizer, what these two models give you is a raw string of recognized words. What sort of processing you do on that string is a separate question. There are obviously all sorts of things you can do with the string. The parsing and processing techniques are getting more sophisticated, and are getting integrated with other systems in interesting ways. This is largely a separate question from the accuracy of the string itself, which is the output of the recognizer (I say "largely" because your application might activate a different language model based on the current context, which does affect recognition accuracy).
Suppose there was a large apartment building, and child pornography was found in one apartment. Should the government have the right to indefinitely hold the belongings of the residents of all of the other apartments in the building?
In the very unlikely event that a kind-hearted, mentally disabled person could become dictator, that person would not be dictator for very long. The first concern of an individual who is in power is to stay in power, because he or she is continually in competition with others who want power.
If a leader stays in power for a while without doing ruthless things, it just means that that leader had the good fortune of not being presented with situations where ruthlessness was required. I doubt that this happens very often.
How does the size of the user base of Dancer compare to that of Catalyst? How do the growth curves compare? Are these things known?
Having a larger support community is one factor I need to consider, partly because it's easier to get help when I need it, and partly because a more widely-used framework is likely to continue to be supported over time. The inherent technical superiority is, of course, another factor to consider.
What do you guys think of Catalyst these days? Does Catalyst still have enough support behind it to make it worth my while to sit down and really learn Catalyst?
This is assuming that I already know Perl well, and that I'm also not interested in switching to another language at the present time.
I've still got the old Apple ][ wire-bound manuals. Yeah, I know, it's extremely unlikely that I'll ever again go poking into the assembly code of Apple DOS, but I've just never been able to consign those manuals to the trash bin.
I've also still got the manuals for the TRS-80 Color Computer. I can still flip them open and immediately remember writing programs using those exact BASIC commands.
You missed the joke. CinthIA = CIA. The woman whose voice is used for one of the numbers stations is known as Cynthia because of the station's supposed connection to the CIA.
This is precisely my point: the free software community should have thrown away one of the two APIs ten years ago.
Choice is not always a good thing. Would you be better off if you had a "choice" of different voltages and socket types for your various household appliances? Is it important to be able to choose a hair dryer which runs on 60vDC and a toaster which runs on 150vAC? Oh, sure, you could have all kinds of voltage adapters for "interoperability", but there's no need for any adapters if everything runs on the same current.
The functional differences between Gnome and KDE are trivial; they are minor variations on the same window/widget paradigm found on MacOS and Windows. If there are individual differences in taste, they would be better handled as user preference settings within a single environment.
I think the free software community has really shot itself in the foot by continuing this division between Gnome and KDE.
Around ten years ago, I was interested in building some GUI apps for Linux, but there was no clear path as to which of the two GUI APIs I should learn. I found the lack of a clear path to be enough of a discouragement that I ended up losing interest. I doubt that I'm the only one who has felt that way about it.
Paying your taxes is one of your basic duties as a citizen. Other than jury duty, taxes are the only compulsory duty expected of U.S. citizens (we don't even have compulsory military service, much less any form of conscripted labor). In case you need to have this spelled out, taxes are what make it possible for us to have roads, public schools, a police department, an army and a navy, and so on.
Of course, there's plenty of room for debate about how much we should be taxed, and how the money can most wisely be spent. Liberals have a particular view on this question.
Don't confuse this question with the question of "freedom". You may not agree with the liberal view on taxation and government spending, but you're just plain mistaken if you think that liberals oppose freedom of speech, freedom of religion, freedom of association, and so on. Liberals strongly support those freedoms. There is nothing in the liberal view on taxation and government budgeting which contradicts those freedoms.
To answer your question about age grading, you have to look at a population at more than one point in time. In cases where this has been done (e.g. speakers of central American Spanish), what we find is that young adults have the highest percentage of the incoming feature (higher than both children and older adults). As those same young adults get older, their use of the incoming feature does decline some, but not down to the levels of the previous generation. The 40-year-olds today have a higher percentage of the incoming variant than the 40-year-olds twenty years ago.
Variants in speech can serve as social markers which you use to identify yourself as a member of a group. As a guess, I imagine that the slight decline in use of the incoming variant as you get older has less to do with "learning standard English better", and more to do with it not being quite as important to sound cool as you get older. As a 40-year-old, you probably still wear clothes which identify you as a member of a certain group, but you probably don't dress in quite as trendy a way as you did when you were 20.
Actually, it appears that AAVE is a product of the Great Northern Migration of African-Americans in the early 20th century. Prior to that time, there was little to no distinction between the dialects of southern whites and southern blacks.
The pieces of evidence for this claim include:
Something which linguists call "age grading". If you take speakers of AAVE today and compare younger speakers with older speakers, the younger speakers actually have a higher percentage occurrence of the distinctive features of AAVE. This suggests that AAVE is becoming increasingly distinct from standard American English over time.
There are other pieces of evidence as well, but those are some of the important ones.