You're a computer scientist who has never attempted to tile their own roof.
I'm a computer scientist and I've tiled roofs, and I think the vast majority of roofing jobs are quite susceptible to automation with existing technology.
For many of them it's still economically infeasible, but they'll start by automating the low-hanging fruit, of course. Simple roof lines on single-story buildings, where they're just doing an additional layer with no tear-off. And probably starting with metal panel rather than shingles (of whatever material) or more-exotic roofs like hand-crimped standing seam.
Assembling a metal-panel roof on the ground on-site and then lifting it onto the building with a crane is amenable to automation, and you only need decent conditions for the placement stage. Final fastening can be done with a crane attachment, essentially a big screwgun - it doesn't have to be little robots walking or rolling around on the roof. That is very much within the capabilities of existing robotics.
And some of us like our metal roofs (relatively) loud. For my wife, the sound of rain on the roof is one of the main selling points.
Fire resistance is another - this house is in a semi-arid area - and we wouldn't get that from a plastic (or conventional composite shingle, or membrane, or wooden) roof. Cement-shingle would be a viable option, but we prefer the look and sound of the metal panel.
I'd also hate to see how quickly a plastic roof would degrade at 7600 feet above sea level; UV is intense here. And a cement-based roof would have to be sealed very well because of the daily freeze-thaw cycles we have much of the year; the climate is hell on exposed concrete, as the quick cycling causes the surface to spall and gradually ablate.
OK, I'll admit that's an interesting thought. It's certainly true that there's no technical barrier to producing fairly readable machine-generated code, though whether I'd use machine learning to do it is something I'd have to think about. Producing a design that's comprehensible to a human reader, and meaningful comments, would be harder. But this would be an interesting area of research.
The main difficulty in transforming legacy COBOL is probably the control-flow graph, given COBOL's accommodation of overlapping code paths and the wild abandon with which that has traditionally been used by developers. When we compile traditional procedural COBOL to inherently-structured targets like CLR IL, we often end up creating very large methods because the only alternative would be lots of tiny methods and a huge amount of state, in order to preserve COBOL semantics. And it's hard to make huge methods, or huge C functions, easy for human readers to understand.
But, as I say, machine translation to readable code would definitely be an interesting area to investigate.
Plenty of people who do have English as their first language can't spell "tongue". It's one of those common English words with a spelling that, for historical reasons, is bizarre even by the lax standards of English.
Anyway, in this case there's something to be said for "tong in cheek".
There was no argumentum ad hominem (or "homenim" - I know, looking things up is hard) in my post. Perhaps you should learn what that phrase means.
Nor did I claim there were closures in Java. Of course there are, but I said nothing on the subject. (And I have never confused Java with Javascript. I've been using both languages since shortly after they were thrust on an undeserving world. I've never been under the impression they were in any way related, aside from being distant members of the C syntactic family.)
And, incidentally, the alot is better than you at everything. Because you're an idiot. I don't claim that says anything about the facticity or quality of your arguments, of course; that would be argumentum ad hominem. Your arguments fail on their own merits.
This impressively bad idea has been tried many times.
The results were always impressively bad.
Really, it's hard to see how anyone with a passable knowledge of both languages would think that a source translation of COBOL (legacy or modern) to C (pick any rev of the standard you like) would produce source that is easier to maintain.
And I say that as someone who does more work in C than any other language (though I also professionally write code in COBOL, C++, Java, C#, Javascript, occasionally PL/I, and many scripting languages; and I've used dozens more over the years). Well-written C can be very readable and maintainable. Machine-generated C rarely is. Machine-generated C that is attempting to exactly replicate the behavior of a non-trivial program written in a very different language is doomed.
Fortunately, there is absolutely no advantage to doing this sort of source translation, so it doesn't matter that it's a terrible idea.
COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages.
You know, I work for a COBOL company (the COBOL company, arguably), and I don't find this argument persuasive. While readability is important,[1] I'm not aware of any methodologically sound studies showing COBOL is inherently more readable than other mainstream programming languages.
In my experience, any correlation between a programming language and readability has more to do with the predominating culture around that language than anything else. C, for example, suffers from a culture of terseness, with meaningless identifiers and expressions compressed far more than necessary. It's possible to write good, readable C; but relatively few C developers do so.
Vast amounts of COBOL source code - probably the majority - is not particularly readable. The individual statements may be clear, and COBOL culture encourages relatively useful identifiers; but prior to COBOL85 the language lacked sufficient structuring mechanisms, and consequently COBOL programs are often nightmares to untangle. (This is true even for the compiler; you wouldn't believe what our compilers go through to figure out where they can use efficient control flow when dealing with bad old source that has overlapping perform ranges and liberal gotos.)
Similarly, refactoring has not traditionally been part of COBOL programming culture, so you have huge source bases full of dead code, because no one's willing to remove or rework anything.
Again, you can write very good COBOL code. Even with procedural COBOL85, you can use ANSI scope terminators such as end-if and write well-structured programs. With really modern COBOL you can write very clear and tidy OO programs with all the usual high-level expressive features. And more people are doing that - we get questions about it on our community forums and enhancement requests and that sort of thing. But that vast corpus of lousy old code is not going to magically get better.
What does justify continuing to invest in COBOL is that rip-and-replace has proven to be hugely expensive and risky, and it's relatively easy to extend existing COBOL applications by integrating them with modern COBOL and/or other languages. If you want, you can have your developers do piecewise modernization as they maintain components, or you can just wrap those legacy components in modern interfaces.
Whoever wrote this article unfortunately appears to subscribe to some bizarre employer-centric view that programmers and CS grads are not allowed to learn programming languages on-the-job.
Indeed. If there's economic incentive to learn COBOL, people will learn COBOL. The "skills shortage" is one of those things the market actually can fix on its own.
[1] Maintenance costs are a large component of total software costs, and reading code is a large component of maintenance. It's also critical for improving reliability and security.
Assuming you mean "lambda expressions" (it's not a fucking acronym), and by that you mean "closures", then yes, via anonymous delegates (in managed COBOL).
Does COBOL have Autoboxing?
Yes, in managed COBOL for CLR. Actually, I think it autoboxes for JVM, too.
Does COBOL have Generics?
Managed COBOL has generic types and methods, yes.
Does COBOL have a vast population of developers?
It's certainly much larger than the snake-oil merchants like the one quoted in this article would have you believe. I'll omit the religious war over the value of popularity; I'm sure we're all tired of it.
Does COBOL have AOP?
Depends on the execution environment and flavor of AOP. Could be better.
Shall I continue?
I wouldn't, if I were you. Too much competition in the ignorance parade today.
Unicode? No. Variable sized data fields! no.. Threads? No. Useful libraries? No. Integration with other components? No.
Wrong on every point.
Maybe you should learn something about a subject before you make an utter fool of yourself.
Of course, you're still doing better than BeauHD, who published this obvious piece of marketing rubbish along with nonsense like claiming Grace Hopper invented COBOL. If only he had access to some sort of global repository of information to fact-check this shit...
That could be one ship-wrecked (is "raft-wrecked" a word?) storm-tossed East Asian who arrived with a fish hook and is starting to re-build his tool kit.
Not my field by any means, but that sounds plausible to me. Harvesting marrow from the large (and thus unlikely to be cracked by predators) bones of carrion is a good choice for someone stranded on their own - a good food source at very little risk, obtained because stone tools give humans an advantage in extracting it.
Archaeologists have found plenty of marrow extraction sites; it's not like this was a rare practice.
And anyone who's knapped flint tools (I've done a few) knows that you generally end up making several before you get just the ones you want, even if you're experienced. Stone stock often has faults that are invisible to the naked eye which can spoil a piece at any point during working, and sometimes you just don't get the shape you're after even if it doesn't break (particularly with percussion knapping). So at a stone-working site you'll often find a bunch of discarded pieces.
That doesn't mean it wasn't a thriving community either, of course. It could have faded away ten thousand years later and not left much for us to stumble across. Look at Cahokia - in 1100 it likely had a larger population than London (did then), but if they hadn't built the mounds we might not know it was ever there.
FWIW, he wasn't even the first European to discover America
Basque fishermen did a brisk business in Grand Banks cod throughout the Medieval period. Salt cod was a European staple, and it came from the North American coast. It's highly unlikely they were unaware of the landmass near their fishing grounds, probably in the general area of Newfoundland.[1]
The European merchant class had been well aware of the existence of the Americas for centuries before 1492. They were just trying to keep it a secret from the aristocracy and the Church. Columbus / Colón / Colombo was a small-time trader with ambitions and a collection of grossly erroneous ideas who Dunning-Kruger'd his way into spilling the beans.
Well, the curriculum for CS programs has changed, of course; very few degree programs remain static. (For one thing, at least with accredited US universities, the dean and provost are not likely to look kindly upon a program that isn't revising its curriculum every few years.) And CS is highly vulnerable to changes driven by enthusiasm (i.e. fads), because the field moves quickly. Also, both accreditation organizations and professional ones such as the ACM are always pushing curricular changes. The ACM recently completely overhauled their recommended curriculum, for example.
But many CS programs have never been particularly keen on programming. When Bjarne Stroustrup was Chair of CS at Texas A&M he wrote an essay complaining about the hostility to programming in many of his faculty.[1] That was relatively recent (this century), but other people have been making similar observations at least since the '80s.
There are a number of reasons for it, most particularly that programming and computer science are two very different things. Also, CS departments with strong graduate programs (which will be the ones at Research I and Research II universities in the US, or similar institutions elsewhere) naturally gravitate toward research; faculty have a strong research component to their job allocations, and grad students doing research are generally more fun to work with than undergrads muddling through relatively simple projects.[2] At that sort of department, unless you have a critical mass of faculty who are interested in writing code, your undergrads will tend to receive more training on the theoretical side than the practical, and coding in particular is likely to be given short shrift.
[1] Quite rightly, in my opinion. While there's no reason for a computer scientist to like programming, or do much of it, outright hostility just shows a limited worldview. It's like a physicist deriding engineering. Not a good mental habit.
[2] And most undergrad projects will be simple, because of scheduling: they typically have to be completed in a single term (quarter/semester/whatever), and undergrads have a lot of demands on their time.
Good story, but I think that stories like yours are the exception rather than the norm.
Probably true, but I also think they're not all that rare. Over the years I've worked with dozens of professional programmers who didn't hold CS degrees. For several years in the late 80s / early 90s I worked for a startup with ten or so other developers, and there were only a couple other CS grad in the bunch. Other degrees include mathematics, architecture, business, physics; one guy had dropped out of college, but he was knowledgeable and wrote nice clean code that was reliable and maintainable.
And the product was system-level, not application - a middleware system with multiprotocol communications, an application engine, service resolution, etc. Not the sort of thing you could copy out of some source snippet you found with archie.
These days CS and cognate degrees are more common, so more developers have them, but I believe relatively few developers do much applied CS, and even fewer think about the theoretical side. While I'm glad to have my CS degree (and I do CS), and while I think there's a place for it in software development, most programming has really very little connection to CS.
In the 1970s we had Math, Engineering, and Physics. There was no such thing as a CS degree.
While CS degree programs, and degrees, were much rarer in the 1970s, this is simply wrong. The first CS departments in the US were founded in the 1960s, and the first degrees, as far as I know, were granted in the mid-1960s.
Those were graduate degrees, but undergrad CS degree programs followed in the early 1970s.
All intentionalist ("in the meaning of the day") arguments are shit. They're the refuge of lazy thinkers.
The "founders" were not gods or paragons of wisdom and virtue, and naive intentionalism is a bogus interpretive strategy. (I'm not particularly persuaded by sophisticated intentionalism either, but that's between me and Walter Benn Michaels.)
I'm sure there's a reason that it doesn't count as a founding document in some lines of thinking.
You mean the ones that prefer accuracy, perhaps?
The Declaration of Independence may be a "founding document" (a subjective term that has no legal consequences), but it is not part of US federal law. I realize not everyone is familiar with the complexities of the US federal government, but this one is pretty easy to check.
Also, of course, the passage you quoted says nothing about healthcare being an inalienable right, or a right of any sort.
Personally, I am in favor of US healthcare reform. I'd be fine with a single-payer system (and I have pretty good healthcare under the current mess). But I don't think arguments from the authority of the Declaration of Independence offer any support for that position, because that document has no authority (aside from sentiment), and because founder-intentionalist arguments, while a staple of American jurisprudence, are rarely enlightening or productive.
Fresh out of college, I figured I was smart and impressive enough to find a way to retire by 50.
Interesting. Fresh out of college, I wanted to never retire.
I'm nearing 50 now, and I still don't.
Work fewer hours at my job? Sure, some day, though I could do that now if I wanted to. But I've never liked the thought of giving up work, either in my profession or all the things I do avocationally. And even if I don't need the money (my wife and I have healthy retirement savings and other assets, and the sorts of jobs where we can find ad hoc income when we feel the urge), I can always find a use for it: charity, helping out family, seeing more of the world, trying out another hobby.
There are plenty of things I like to do that aren't very productive, but labor is hugely important to my sense of self and my happiness. I like to make things, and I like getting compensated for some of it.
Of course, many people don't feel that way, and that's fine. Plenty of folks put in their time being productive and then want some time off at the end of it. I have no beef with that. Some people seem to think that the only sane stance is to want to retire as soon as possible.
What, just because existing voice-activated consumer devices have terrible security, and existing IP-connected security cameras have terrible security, you think that a product combining the two will have terrible security?
Of course on top of that we have the fact that the economic incentives are all for it to have terrible security (in the name of "usability" and "convenience").
But I have to appreciate how Amazon is pitching its terrible security - particularly the lack of privacy - as a feature. Nicely played.
... for Amazon's Echo Crap, which goes in the toilet bowl, analyzes your elimination procedures and products, and offers helpful advice on health, diet, and lifestyle. Thanks to the built-in waterproof camera it will also perform motion-efficiency analysis on your wiping activities.
And should you suddenly decide you want to buy something while you're lightening your load, or feel that your Facebook friends want to know about your excretory success, it features Amazon's patented Intrusive Voice Activated Spying with Immediate Impulse Satisfaction.
Slashdot Mirror
Assuming the B stands for billions I'm sure many would like to know how far our galactic empire stretches.
ShanghaiBill didn't say human speakers. Perhaps you were unaware that mice speak English, as shown in documentaries such as Cinderella.
You're a computer scientist who has never attempted to tile their own roof.
I'm a computer scientist and I've tiled roofs, and I think the vast majority of roofing jobs are quite susceptible to automation with existing technology.
For many of them it's still economically infeasible, but they'll start by automating the low-hanging fruit, of course. Simple roof lines on single-story buildings, where they're just doing an additional layer with no tear-off. And probably starting with metal panel rather than shingles (of whatever material) or more-exotic roofs like hand-crimped standing seam.
Assembling a metal-panel roof on the ground on-site and then lifting it onto the building with a crane is amenable to automation, and you only need decent conditions for the placement stage. Final fastening can be done with a crane attachment, essentially a big screwgun - it doesn't have to be little robots walking or rolling around on the roof. That is very much within the capabilities of existing robotics.
And some of us like our metal roofs (relatively) loud. For my wife, the sound of rain on the roof is one of the main selling points.
Fire resistance is another - this house is in a semi-arid area - and we wouldn't get that from a plastic (or conventional composite shingle, or membrane, or wooden) roof. Cement-shingle would be a viable option, but we prefer the look and sound of the metal panel.
I'd also hate to see how quickly a plastic roof would degrade at 7600 feet above sea level; UV is intense here. And a cement-based roof would have to be sealed very well because of the daily freeze-thaw cycles we have much of the year; the climate is hell on exposed concrete, as the quick cycling causes the surface to spall and gradually ablate.
OK, I'll admit that's an interesting thought. It's certainly true that there's no technical barrier to producing fairly readable machine-generated code, though whether I'd use machine learning to do it is something I'd have to think about. Producing a design that's comprehensible to a human reader, and meaningful comments, would be harder. But this would be an interesting area of research.
The main difficulty in transforming legacy COBOL is probably the control-flow graph, given COBOL's accommodation of overlapping code paths and the wild abandon with which that has traditionally been used by developers. When we compile traditional procedural COBOL to inherently-structured targets like CLR IL, we often end up creating very large methods because the only alternative would be lots of tiny methods and a huge amount of state, in order to preserve COBOL semantics. And it's hard to make huge methods, or huge C functions, easy for human readers to understand.
But, as I say, machine translation to readable code would definitely be an interesting area to investigate.
Plenty of people who do have English as their first language can't spell "tongue". It's one of those common English words with a spelling that, for historical reasons, is bizarre even by the lax standards of English.
Anyway, in this case there's something to be said for "tong in cheek".
There was no argumentum ad hominem (or "homenim" - I know, looking things up is hard) in my post. Perhaps you should learn what that phrase means.
Nor did I claim there were closures in Java. Of course there are, but I said nothing on the subject. (And I have never confused Java with Javascript. I've been using both languages since shortly after they were thrust on an undeserving world. I've never been under the impression they were in any way related, aside from being distant members of the C syntactic family.)
And, incidentally, the alot is better than you at everything. Because you're an idiot. I don't claim that says anything about the facticity or quality of your arguments, of course; that would be argumentum ad hominem. Your arguments fail on their own merits.
This impressively bad idea has been tried many times.
The results were always impressively bad.
Really, it's hard to see how anyone with a passable knowledge of both languages would think that a source translation of COBOL (legacy or modern) to C (pick any rev of the standard you like) would produce source that is easier to maintain.
And I say that as someone who does more work in C than any other language (though I also professionally write code in COBOL, C++, Java, C#, Javascript, occasionally PL/I, and many scripting languages; and I've used dozens more over the years). Well-written C can be very readable and maintainable. Machine-generated C rarely is. Machine-generated C that is attempting to exactly replicate the behavior of a non-trivial program written in a very different language is doomed.
Fortunately, there is absolutely no advantage to doing this sort of source translation, so it doesn't matter that it's a terrible idea.
even trivial things are awkward to do in Cobol
Translation: I know nothing about what's happened with the COBOL language since 1985.
COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages.
You know, I work for a COBOL company (the COBOL company, arguably), and I don't find this argument persuasive. While readability is important,[1] I'm not aware of any methodologically sound studies showing COBOL is inherently more readable than other mainstream programming languages.
In my experience, any correlation between a programming language and readability has more to do with the predominating culture around that language than anything else. C, for example, suffers from a culture of terseness, with meaningless identifiers and expressions compressed far more than necessary. It's possible to write good, readable C; but relatively few C developers do so.
Vast amounts of COBOL source code - probably the majority - is not particularly readable. The individual statements may be clear, and COBOL culture encourages relatively useful identifiers; but prior to COBOL85 the language lacked sufficient structuring mechanisms, and consequently COBOL programs are often nightmares to untangle. (This is true even for the compiler; you wouldn't believe what our compilers go through to figure out where they can use efficient control flow when dealing with bad old source that has overlapping perform ranges and liberal gotos.)
Similarly, refactoring has not traditionally been part of COBOL programming culture, so you have huge source bases full of dead code, because no one's willing to remove or rework anything.
Again, you can write very good COBOL code. Even with procedural COBOL85, you can use ANSI scope terminators such as end-if and write well-structured programs. With really modern COBOL you can write very clear and tidy OO programs with all the usual high-level expressive features. And more people are doing that - we get questions about it on our community forums and enhancement requests and that sort of thing. But that vast corpus of lousy old code is not going to magically get better.
What does justify continuing to invest in COBOL is that rip-and-replace has proven to be hugely expensive and risky, and it's relatively easy to extend existing COBOL applications by integrating them with modern COBOL and/or other languages. If you want, you can have your developers do piecewise modernization as they maintain components, or you can just wrap those legacy components in modern interfaces.
Whoever wrote this article unfortunately appears to subscribe to some bizarre employer-centric view that programmers and CS grads are not allowed to learn programming languages on-the-job.
Indeed. If there's economic incentive to learn COBOL, people will learn COBOL. The "skills shortage" is one of those things the market actually can fix on its own.
[1] Maintenance costs are a large component of total software costs, and reading code is a large component of maintenance. It's also critical for improving reliability and security.
Does COBOL have for each loops?
Yes, in managed COBOL (JVM or CLR).
Does COBOL have LAMBDA expressions?
Assuming you mean "lambda expressions" (it's not a fucking acronym), and by that you mean "closures", then yes, via anonymous delegates (in managed COBOL).
Does COBOL have Autoboxing?
Yes, in managed COBOL for CLR. Actually, I think it autoboxes for JVM, too.
Does COBOL have Generics?
Managed COBOL has generic types and methods, yes.
Does COBOL have a vast population of developers?
It's certainly much larger than the snake-oil merchants like the one quoted in this article would have you believe. I'll omit the religious war over the value of popularity; I'm sure we're all tired of it.
Does COBOL have AOP?
Depends on the execution environment and flavor of AOP. Could be better.
Shall I continue?
I wouldn't, if I were you. Too much competition in the ignorance parade today.
Unicode? No. Variable sized data fields! no.. Threads? No. Useful libraries? No. Integration with other components? No.
Wrong on every point.
Maybe you should learn something about a subject before you make an utter fool of yourself.
Of course, you're still doing better than BeauHD, who published this obvious piece of marketing rubbish along with nonsense like claiming Grace Hopper invented COBOL. If only he had access to some sort of global repository of information to fact-check this shit...
That could be one ship-wrecked (is "raft-wrecked" a word?) storm-tossed East Asian who arrived with a fish hook and is starting to re-build his tool kit.
Not my field by any means, but that sounds plausible to me. Harvesting marrow from the large (and thus unlikely to be cracked by predators) bones of carrion is a good choice for someone stranded on their own - a good food source at very little risk, obtained because stone tools give humans an advantage in extracting it.
Archaeologists have found plenty of marrow extraction sites; it's not like this was a rare practice.
And anyone who's knapped flint tools (I've done a few) knows that you generally end up making several before you get just the ones you want, even if you're experienced. Stone stock often has faults that are invisible to the naked eye which can spoil a piece at any point during working, and sometimes you just don't get the shape you're after even if it doesn't break (particularly with percussion knapping). So at a stone-working site you'll often find a bunch of discarded pieces.
That doesn't mean it wasn't a thriving community either, of course. It could have faded away ten thousand years later and not left much for us to stumble across. Look at Cahokia - in 1100 it likely had a larger population than London (did then), but if they hadn't built the mounds we might not know it was ever there.
FWIW, he wasn't even the first European to discover America
Basque fishermen did a brisk business in Grand Banks cod throughout the Medieval period. Salt cod was a European staple, and it came from the North American coast. It's highly unlikely they were unaware of the landmass near their fishing grounds, probably in the general area of Newfoundland.[1]
The European merchant class had been well aware of the existence of the Americas for centuries before 1492. They were just trying to keep it a secret from the aristocracy and the Church. Columbus / Colón / Colombo was a small-time trader with ambitions and a collection of grossly erroneous ideas who Dunning-Kruger'd his way into spilling the beans.
[1] Which should really be known as Refoundland.
What has changed in the curriculum?
Well, the curriculum for CS programs has changed, of course; very few degree programs remain static. (For one thing, at least with accredited US universities, the dean and provost are not likely to look kindly upon a program that isn't revising its curriculum every few years.) And CS is highly vulnerable to changes driven by enthusiasm (i.e. fads), because the field moves quickly. Also, both accreditation organizations and professional ones such as the ACM are always pushing curricular changes. The ACM recently completely overhauled their recommended curriculum, for example.
But many CS programs have never been particularly keen on programming. When Bjarne Stroustrup was Chair of CS at Texas A&M he wrote an essay complaining about the hostility to programming in many of his faculty.[1] That was relatively recent (this century), but other people have been making similar observations at least since the '80s.
There are a number of reasons for it, most particularly that programming and computer science are two very different things. Also, CS departments with strong graduate programs (which will be the ones at Research I and Research II universities in the US, or similar institutions elsewhere) naturally gravitate toward research; faculty have a strong research component to their job allocations, and grad students doing research are generally more fun to work with than undergrads muddling through relatively simple projects.[2] At that sort of department, unless you have a critical mass of faculty who are interested in writing code, your undergrads will tend to receive more training on the theoretical side than the practical, and coding in particular is likely to be given short shrift.
[1] Quite rightly, in my opinion. While there's no reason for a computer scientist to like programming, or do much of it, outright hostility just shows a limited worldview. It's like a physicist deriding engineering. Not a good mental habit.
[2] And most undergrad projects will be simple, because of scheduling: they typically have to be completed in a single term (quarter/semester/whatever), and undergrads have a lot of demands on their time.
Good story, but I think that stories like yours are the exception rather than the norm.
Probably true, but I also think they're not all that rare. Over the years I've worked with dozens of professional programmers who didn't hold CS degrees. For several years in the late 80s / early 90s I worked for a startup with ten or so other developers, and there were only a couple other CS grad in the bunch. Other degrees include mathematics, architecture, business, physics; one guy had dropped out of college, but he was knowledgeable and wrote nice clean code that was reliable and maintainable.
And the product was system-level, not application - a middleware system with multiprotocol communications, an application engine, service resolution, etc. Not the sort of thing you could copy out of some source snippet you found with archie.
These days CS and cognate degrees are more common, so more developers have them, but I believe relatively few developers do much applied CS, and even fewer think about the theoretical side. While I'm glad to have my CS degree (and I do CS), and while I think there's a place for it in software development, most programming has really very little connection to CS.
In the 1970s we had Math, Engineering, and Physics. There was no such thing as a CS degree.
While CS degree programs, and degrees, were much rarer in the 1970s, this is simply wrong. The first CS departments in the US were founded in the 1960s, and the first degrees, as far as I know, were granted in the mid-1960s.
Those were graduate degrees, but undergrad CS degree programs followed in the early 1970s.
OK, I admit that made me laugh.
It's all in the delivery.
the fact that the founders didn't start building hospitals means that they never meant it that way
Oh, that's just adorable. Go on, give us another one.
Basically your argument is shit.
All intentionalist ("in the meaning of the day") arguments are shit. They're the refuge of lazy thinkers.
The "founders" were not gods or paragons of wisdom and virtue, and naive intentionalism is a bogus interpretive strategy. (I'm not particularly persuaded by sophisticated intentionalism either, but that's between me and Walter Benn Michaels.)
I'm sure there's a reason that it doesn't count as a founding document in some lines of thinking.
You mean the ones that prefer accuracy, perhaps?
The Declaration of Independence may be a "founding document" (a subjective term that has no legal consequences), but it is not part of US federal law. I realize not everyone is familiar with the complexities of the US federal government, but this one is pretty easy to check.
Also, of course, the passage you quoted says nothing about healthcare being an inalienable right, or a right of any sort.
Personally, I am in favor of US healthcare reform. I'd be fine with a single-payer system (and I have pretty good healthcare under the current mess). But I don't think arguments from the authority of the Declaration of Independence offer any support for that position, because that document has no authority (aside from sentiment), and because founder-intentionalist arguments, while a staple of American jurisprudence, are rarely enlightening or productive.
That's pretty inefficient. Why make your own bespoke children when so many are already available on the mass market?
Fresh out of college, I figured I was smart and impressive enough to find a way to retire by 50.
Interesting. Fresh out of college, I wanted to never retire.
I'm nearing 50 now, and I still don't.
Work fewer hours at my job? Sure, some day, though I could do that now if I wanted to. But I've never liked the thought of giving up work, either in my profession or all the things I do avocationally. And even if I don't need the money (my wife and I have healthy retirement savings and other assets, and the sorts of jobs where we can find ad hoc income when we feel the urge), I can always find a use for it: charity, helping out family, seeing more of the world, trying out another hobby.
There are plenty of things I like to do that aren't very productive, but labor is hugely important to my sense of self and my happiness. I like to make things, and I like getting compensated for some of it.
Of course, many people don't feel that way, and that's fine. Plenty of folks put in their time being productive and then want some time off at the end of it. I have no beef with that. Some people seem to think that the only sane stance is to want to retire as soon as possible.
I'm running out of armchairs to sit in while I solve all the world's problems!
Oh, shit. Have we hit Peak Armchair already? Can Maker Culture build us out of this mess?
What, just because existing voice-activated consumer devices have terrible security, and existing IP-connected security cameras have terrible security, you think that a product combining the two will have terrible security?
Of course on top of that we have the fact that the economic incentives are all for it to have terrible security (in the name of "usability" and "convenience").
But I have to appreciate how Amazon is pitching its terrible security - particularly the lack of privacy - as a feature. Nicely played.
... for Amazon's Echo Crap, which goes in the toilet bowl, analyzes your elimination procedures and products, and offers helpful advice on health, diet, and lifestyle. Thanks to the built-in waterproof camera it will also perform motion-efficiency analysis on your wiping activities.
And should you suddenly decide you want to buy something while you're lightening your load, or feel that your Facebook friends want to know about your excretory success, it features Amazon's patented Intrusive Voice Activated Spying with Immediate Impulse Satisfaction.