you start off with an incorrect understanding of the problem
Claiming you are better informed doesn't make it so.
For example, your statement implies that you view wealth as a bounded resource that "log jams" somewhere.
It *is* log-jamming at the top: I'm just the messenger. And in most economic models it is a bounded resource: factories etc. have a maximum capacity. Inflation usually starts to become a problem when we approach such. (Inflation has been sub-par for a while, I would note. Perhaps we need Helicopter Money.)
Technology etc. can indeed expand the maximum capacity, but not overnight.
So, government-mandated monopolies and barriers to entry (like copyrights, patents, regulations, etc.) created in response to big corporate lobbying make markets less efficient. How is that an indictment of free markets?
I agree some of these are overdone. The problem is that there's no consensus over which are underdone and which are overdone. Capitalists have shown many times they'll harm or poison babies for profit, and cannot be trusted in general to voluntarily not be jerks. Everybody has lovely theories on paper about which of these things are good or bad and how to tune them.
The gov't is kind of like an OS: it coordinates resources, enforces limits, and provides standards. I remember the early days of multi-processing PC's where applications could pretty much do what they want and bad apples ruined it for everybody. (Similar with browser pop-ups etc. these days.)
if it takes Trump's ego to get us to Mars, I am all for that.
But he may force sloppy shortcuts that contaminate a planet or two and/or kill astronauts by skipping physical safety to try to get there during his term(s) in office.
if the "framework" doesn't come with the standard library for your development language of choice, it's going to be a headache at some point in the future.
They indeed do change and/or go out of style quite often.
And if you're doing CRUD by itself, you're doing it wrong. Call a stored proc that
What I mean is applications that are data-centric, typically internally used by an org, as opposed say a shopping web app that is more presentation-centric.
Then you have fewer competitors left, which we need like a hole in the head.
Separate financial institutions and banks.. A bank is there to keep your money safe, not to invest it in random schemes
Good luck convincing the current swamp to do that.
It would be better for the government to only use laws to incentivize companies to hire more people.
Interesting idea, but it's hard to say if it would work. We may need to experiment with the economy, and that may mean failed experiments, which is a difficult political sell.
I'm skeptical of many of your numbers. Where did you get them?
You make it sound like the entire West switched to laissez-faire free market economics and massive cuts in welfare spending in 1980
I didn't specify a cause of wealth log-jamming at the top. Economists are still puzzled over the exact cause(s). Cheap foreign labor and automation are the top candidates.
It's becoming a winner-take-all system. Owners of the (foreign) factories and automation software and/or patents seem to get richer, while the rest stagnate. For example, why can't smaller competitors break into the smart-phone market? Because the biggies use their size and patent portfolio as weapons against smaller players, subsidizing threatened product lines with oligopoly cash-cow profits from others.
I've noticed MS products often stagnate until a competitor threatens them periodically. I've seen well-known bugs last a decade in MS-Access because they had no viable competitors during that time.
I don't buy this. A simple hello world in Java is much more complex and wordy than the same functionality in 50 year-old BASIC. And any language that relies on whitespace to modify the program flow cannot be described as readable.
The whitespace controversy illustrates that nobody agrees what a "good language" is. The ways our eyes, fingers, and brains work (or don't work) varies widely. I've learned after many heated debates that extrapolating how my own thought process works into others is a dead-end.
And many of the tools of the past were simpler. They combined database, business logic, and UI's into an integrated and coordinated package. Now we have layers and frameworks, which don't always get along and/or change independently, and require "translation code" between each layer, making more bloat and busy work. Yes, we gain flexibility in choices for the sub-parts, but lose compact and coordinated integration.
I don't know if this is a general trend, or merely a pendulum swing. Maybe a "killer tool" will come along using many of the integration lessons of the past and put a lot of "layer slingers" out of work. I see a lot of bloat in CRUD-oriented frameworks that could be factored out and away to the unemployment line if somebody just provides the right tool and/or standards. It won't be perfect, by neither is the current crap. It would just be more productive crap.
There are two methods of distributing wealth: voluntarily through markets, and using force through the government. The first one works, the second one doesn't.
Since about 1980, trickle-down has been failing more and more, in many countries. The "market" ain't working well for about 90%. GDP's grow, but most don't receive the benefits of that growth. Time for a Plan B.
I suspect your head has been filled with anti-government and anti-tax propaganda from the right and big corporations who bribe heavily to keep and grow their turf.
USA is full of really fat cats, and full of lots of rotting bridges, road, dams, and pipes. Something is out of kilter.
AI predictions should all be taken with a grain of salt.
However, my wife recently told me about a consumer product CAD software demo she saw at a trade show that would more or less eliminate her job, or at least greatly reduce the people employed in her specialty.
Using large databases of existing drawings of particular product types, along with AI, it would guess most of the design specifics based off rough sketches and operator selections of similar designs from the database, Google-image-search-like. It also automatically generates different sizes, such as shoe sizes. Humans then tune the result.
Her job is a well-paying position right now if you are good. Such software would still require design inspectors and tuners, but that's less labor intensive than direct from-scratch CAD. If half your profession's labor is made obsolete, your wages and career options will likely drop.
She gives her profession about 5 more viable years.
OOP and functional programming, and probably other paradigms/methodologies have something in common: there's a right place and way to use them and wrong places and ways. They are helpful in the right place, but can make Yuuuge messes in the wrong place.
The "art" of programming is often using the right tool for the job: hammers are not "bad", but don't use them to drive in screws. Always remember not to make things hard on future maintainers who may not know about or share your grand code design philosophies.
As much as I hate Microsoft as a company, having Google and Apple control everything is also problematic. Thus, it would indeed be nice if MS gave them decent competition.
5 years experience in a technology that has only existed for 14 months and cannot be taught in a classroom outside of business anyways. The requirements are way past ridiculous and border on the insane.
There's a "shortage" of good liars. I know a guy who was a fantastic BS-er that way. He had a network of fake references, for example. "Sure, he was doing Java for us in 1989. We used the first beta out. And he used Silverlight when it was still Bronzelight."
I felt too slimy to copy his techniques, but in a competitive world where a position receives hundreds of resumes, it's "survival of the fibbist", I hate to say.
Or, white men are conditioned to an environment of abrasive competition, and not to complain about such behavior.
In a more general sense, different cultures value different things in different proportions, and that is going create conflict. "X people don't do enough Y" and/or "X people do too much Z".
Our egos make our own culture the center of the universe, and we try to shape the universe in our image. A recipe for conflict.
True, the muscle part could be seen as "protecting and caring". I'm rather large in general such that perhaps that part mostly took care of itself despite me NOT resembling a super-hero. A man small or slight in stature may need muscles or karate skills to make up that portion of the report card.
Women want to be able to walk down the street at night with their guy and feel safe. There are different ways to achieve that. Some men fake it well with pure attitude.
COBOL was ultimately designed by a committee, but Grace's early compilers had a lot of influence on the language design.
The military and other organizations found it difficult to build financial, logistics, and administrative software for multiple machines that each speak a different language, and thus formed a joint committee to create a common language. (Science and research institutions had FORTRAN for cross compatibility.)
Basically the COBOL committee grew sour with disagreement. As the deadline for the first specification approached, the committee fractured into a "git'er done" tribe, and a "do it right" tribe. The git-er-done tribe basically cloned Grace's language with some minor changes and additions because they knew they didn't have time to reinvent the wheel from scratch. Grace's language was road-tested.
As the deadline came up, the git-er-done group were the only tribe with something close to ready, and so that's the work the committee heads ultimately submitted. There were a lot of complaints about it, but the heads wanted to submit something rather than outright fail. (The story varies depending on who tells it.)
Later versions of COBOL borrowed ideas from other languages and report-writing tools, but the root still closely mirrored Grace's language. Therefore, it could be said that Grace Hopper's work had a large influence on COBOL.
As far as what orgs should do about existing COBOL apps, it's not realistic to rewrite it all from scratch, at least not all at once. That would be a long and expensive endeavor. It's probably cheaper to pay the higher wages for COBOL experts, but also gradually convert sub-systems as time goes on.
However, whatever you pick as the replacement language could face the same problem. There's no guarantee that Java, C#, Python, etc. will be common in the future. Rewriting COBOL into Java could simply be trading one dead language for another.
I know shops that replaced COBOL "green screen" apps with Java Applets. Now Java Applets are "legacy" also. (And a pain to keep updating Java for.)
Predicting the future in IT is a dead-man's game. At least the COBOL zombie has shown staying power. If you pick a different zombie, you are gambling even more than staying with the COBOL zombie.
If it ain't broke, don't fix it. If it's half-broke, fix it gradually.
There is indeed more social pressure on men to be the bread winners, similar to how women are pressured to look attractive. And thus we'd expect young men to work harder and longer to try to get the promotions. If you are pressured by society to do X, you are more likely to do X.
It may not be "fair", but that's society as-is. A quota system doesn't factor this in.
perhaps companies ARE mistreating women and minorities which WOULD make it the company's fault
The company can't force employees to like someone. If there are known incidents, they can perhaps do something, but most "mistreatment" is subtle and/or unrecorded. The organization cannot micromanage social encounters at that level.
In general, many people are tribal jerks. I've had white colleagues who told about mistreatment when they worked with a uniform non-white group, such as all Asian. The "minority" is often targeted. Sometimes it's driven by resentment of "white culture" discriminating against them in general. They channel that frustration into an individual who happens to be white.
I'm not sure how to fix this because it's probably fundamental to human nature. Mass nagging about "being good" only goes so far. If you over-nag, people often do the opposite as a protest to the nagging. (Is the word "nagging" sexist?)
forcing yourself into a pure functional style means that your code can run anywhere because it doesn't care about the context in which it runs.
Most planners focus on the current needs, not future needs. Whether that's rational (good business planning) is another matter. It's generally cheaper to hire and get future maintenance on procedural code. If and when machine performance issues override that, the planners may THEN care.
It depends on the project. If most of the processing for an app is happening on servers in cloud centers, then it's probably already parallelizing user sessions. Parallelizing at the app level thus won't really give you much more parallelism potential, especially if most of the data chomping is done on the database, which should already be using parallelism. Web servers and databases already take advantage of parallelism. It would thus be diminishing returns to parallelize the app level. If the code is looping on 10,000 items in app code itself, the coder is probably do something wrong.
The industry learned the hard way that OOP works well for some things but not others. For example, OOP has mostly failed in domain modeling (modeling real-world "nouns") but is pretty good at packaging API's for computing and networking services.
The industry may also learn the hard way where FP does well and where it chokes. Some understandably don't want to be the guinea pigs.
Claiming you are better informed doesn't make it so.
It *is* log-jamming at the top: I'm just the messenger. And in most economic models it is a bounded resource: factories etc. have a maximum capacity. Inflation usually starts to become a problem when we approach such. (Inflation has been sub-par for a while, I would note. Perhaps we need Helicopter Money.)
Technology etc. can indeed expand the maximum capacity, but not overnight.
I agree some of these are overdone. The problem is that there's no consensus over which are underdone and which are overdone. Capitalists have shown many times they'll harm or poison babies for profit, and cannot be trusted in general to voluntarily not be jerks. Everybody has lovely theories on paper about which of these things are good or bad and how to tune them.
The gov't is kind of like an OS: it coordinates resources, enforces limits, and provides standards. I remember the early days of multi-processing PC's where applications could pretty much do what they want and bad apples ruined it for everybody. (Similar with browser pop-ups etc. these days.)
But he may force sloppy shortcuts that contaminate a planet or two and/or kill astronauts by skipping physical safety to try to get there during his term(s) in office.
The Orange Guy: "It looks so simple when they do it in the movies."
They indeed do change and/or go out of style quite often.
What I mean is applications that are data-centric, typically internally used by an org, as opposed say a shopping web app that is more presentation-centric.
Then you have fewer competitors left, which we need like a hole in the head.
Good luck convincing the current swamp to do that.
Interesting idea, but it's hard to say if it would work. We may need to experiment with the economy, and that may mean failed experiments, which is a difficult political sell.
I'm skeptical of many of your numbers. Where did you get them?
I didn't specify a cause of wealth log-jamming at the top. Economists are still puzzled over the exact cause(s). Cheap foreign labor and automation are the top candidates.
It's becoming a winner-take-all system. Owners of the (foreign) factories and automation software and/or patents seem to get richer, while the rest stagnate. For example, why can't smaller competitors break into the smart-phone market? Because the biggies use their size and patent portfolio as weapons against smaller players, subsidizing threatened product lines with oligopoly cash-cow profits from others.
I've noticed MS products often stagnate until a competitor threatens them periodically. I've seen well-known bugs last a decade in MS-Access because they had no viable competitors during that time.
The whitespace controversy illustrates that nobody agrees what a "good language" is. The ways our eyes, fingers, and brains work (or don't work) varies widely. I've learned after many heated debates that extrapolating how my own thought process works into others is a dead-end.
And many of the tools of the past were simpler. They combined database, business logic, and UI's into an integrated and coordinated package. Now we have layers and frameworks, which don't always get along and/or change independently, and require "translation code" between each layer, making more bloat and busy work. Yes, we gain flexibility in choices for the sub-parts, but lose compact and coordinated integration.
I don't know if this is a general trend, or merely a pendulum swing. Maybe a "killer tool" will come along using many of the integration lessons of the past and put a lot of "layer slingers" out of work. I see a lot of bloat in CRUD-oriented frameworks that could be factored out and away to the unemployment line if somebody just provides the right tool and/or standards. It won't be perfect, by neither is the current crap. It would just be more productive crap.
My experimental TrumpBot grabs pussies. I wonder how the legal side of that will turn out.
Since about 1980, trickle-down has been failing more and more, in many countries. The "market" ain't working well for about 90%. GDP's grow, but most don't receive the benefits of that growth. Time for a Plan B.
I suspect your head has been filled with anti-government and anti-tax propaganda from the right and big corporations who bribe heavily to keep and grow their turf.
USA is full of really fat cats, and full of lots of rotting bridges, road, dams, and pipes. Something is out of kilter.
AI predictions should all be taken with a grain of salt.
However, my wife recently told me about a consumer product CAD software demo she saw at a trade show that would more or less eliminate her job, or at least greatly reduce the people employed in her specialty.
Using large databases of existing drawings of particular product types, along with AI, it would guess most of the design specifics based off rough sketches and operator selections of similar designs from the database, Google-image-search-like. It also automatically generates different sizes, such as shoe sizes. Humans then tune the result.
Her job is a well-paying position right now if you are good. Such software would still require design inspectors and tuners, but that's less labor intensive than direct from-scratch CAD. If half your profession's labor is made obsolete, your wages and career options will likely drop.
She gives her profession about 5 more viable years.
I have to disagree. It was interesting hearing from an actual DIY-ish publisher. Don't generalize your criticism into everybody, please.
TRS-80's, where I first learned programming. I built a cheap-ass & slow Space Invaders clone.
OOP and functional programming, and probably other paradigms/methodologies have something in common: there's a right place and way to use them and wrong places and ways. They are helpful in the right place, but can make Yuuuge messes in the wrong place.
The "art" of programming is often using the right tool for the job: hammers are not "bad", but don't use them to drive in screws. Always remember not to make things hard on future maintainers who may not know about or share your grand code design philosophies.
As much as I hate Microsoft as a company, having Google and Apple control everything is also problematic. Thus, it would indeed be nice if MS gave them decent competition.
You sure remember the Fox incarnation.
Good! I feel better.
There's a "shortage" of good liars. I know a guy who was a fantastic BS-er that way. He had a network of fake references, for example. "Sure, he was doing Java for us in 1989. We used the first beta out. And he used Silverlight when it was still Bronzelight."
I felt too slimy to copy his techniques, but in a competitive world where a position receives hundreds of resumes, it's "survival of the fibbist", I hate to say.
Heaven forbid if we ever got a president like that.
In a more general sense, different cultures value different things in different proportions, and that is going create conflict. "X people don't do enough Y" and/or "X people do too much Z".
Our egos make our own culture the center of the universe, and we try to shape the universe in our image. A recipe for conflict.
Most women I've known put money far above men's looks. If I had to use a point system, I'd assign it as such:
Earning power/potential: 60 pts.
Protecting and caring: 30 pts.
Looks/muscles: 10 pts.
True, the muscle part could be seen as "protecting and caring". I'm rather large in general such that perhaps that part mostly took care of itself despite me NOT resembling a super-hero. A man small or slight in stature may need muscles or karate skills to make up that portion of the report card.
Women want to be able to walk down the street at night with their guy and feel safe. There are different ways to achieve that. Some men fake it well with pure attitude.
COBOL was ultimately designed by a committee, but Grace's early compilers had a lot of influence on the language design.
The military and other organizations found it difficult to build financial, logistics, and administrative software for multiple machines that each speak a different language, and thus formed a joint committee to create a common language. (Science and research institutions had FORTRAN for cross compatibility.)
Basically the COBOL committee grew sour with disagreement. As the deadline for the first specification approached, the committee fractured into a "git'er done" tribe, and a "do it right" tribe. The git-er-done tribe basically cloned Grace's language with some minor changes and additions because they knew they didn't have time to reinvent the wheel from scratch. Grace's language was road-tested.
As the deadline came up, the git-er-done group were the only tribe with something close to ready, and so that's the work the committee heads ultimately submitted. There were a lot of complaints about it, but the heads wanted to submit something rather than outright fail. (The story varies depending on who tells it.)
Later versions of COBOL borrowed ideas from other languages and report-writing tools, but the root still closely mirrored Grace's language. Therefore, it could be said that Grace Hopper's work had a large influence on COBOL.
(It's somewhat similar to the "worse is better" story between Unix/C and a Lisp-based OS: http://dreamsongs.com/WorseIsB... )
- - - - - - -
As far as what orgs should do about existing COBOL apps, it's not realistic to rewrite it all from scratch, at least not all at once. That would be a long and expensive endeavor. It's probably cheaper to pay the higher wages for COBOL experts, but also gradually convert sub-systems as time goes on.
However, whatever you pick as the replacement language could face the same problem. There's no guarantee that Java, C#, Python, etc. will be common in the future. Rewriting COBOL into Java could simply be trading one dead language for another.
I know shops that replaced COBOL "green screen" apps with Java Applets. Now Java Applets are "legacy" also. (And a pain to keep updating Java for.)
Predicting the future in IT is a dead-man's game. At least the COBOL zombie has shown staying power. If you pick a different zombie, you are gambling even more than staying with the COBOL zombie.
If it ain't broke, don't fix it. If it's half-broke, fix it gradually.
There is indeed more social pressure on men to be the bread winners, similar to how women are pressured to look attractive. And thus we'd expect young men to work harder and longer to try to get the promotions. If you are pressured by society to do X, you are more likely to do X.
It may not be "fair", but that's society as-is. A quota system doesn't factor this in.
The company can't force employees to like someone. If there are known incidents, they can perhaps do something, but most "mistreatment" is subtle and/or unrecorded. The organization cannot micromanage social encounters at that level.
In general, many people are tribal jerks. I've had white colleagues who told about mistreatment when they worked with a uniform non-white group, such as all Asian. The "minority" is often targeted. Sometimes it's driven by resentment of "white culture" discriminating against them in general. They channel that frustration into an individual who happens to be white.
I'm not sure how to fix this because it's probably fundamental to human nature. Mass nagging about "being good" only goes so far. If you over-nag, people often do the opposite as a protest to the nagging. (Is the word "nagging" sexist?)
Most planners focus on the current needs, not future needs. Whether that's rational (good business planning) is another matter. It's generally cheaper to hire and get future maintenance on procedural code. If and when machine performance issues override that, the planners may THEN care.
It depends on the project. If most of the processing for an app is happening on servers in cloud centers, then it's probably already parallelizing user sessions. Parallelizing at the app level thus won't really give you much more parallelism potential, especially if most of the data chomping is done on the database, which should already be using parallelism. Web servers and databases already take advantage of parallelism. It would thus be diminishing returns to parallelize the app level. If the code is looping on 10,000 items in app code itself, the coder is probably do something wrong.
The industry learned the hard way that OOP works well for some things but not others. For example, OOP has mostly failed in domain modeling (modeling real-world "nouns") but is pretty good at packaging API's for computing and networking services.
The industry may also learn the hard way where FP does well and where it chokes. Some understandably don't want to be the guinea pigs.