You have no explanation for why it wasn't at least manslaughter. I applied Occam's Razor.
You cannot accuse a jury of being biased for a specific motivation based on Occam's Razor. You were not on the jury and were not privy to the discussion. You have no specific details to suggest the jury "did it wrong". They too should be considered innocent until proven guilty.
If you use Occam's Razor to form an internal personal guess, that's fine, but you implied it was definitive conclusion. Don't open your trap unless you have reasonably solid evidence, NOT personal guesses using very indirect means. This is Slashdot; we expect more logic and details, not stream of conscientiousness chatter. If we wanted the latter, we'd tune into the President.
And to me, Occam's Razor says there are too many alternative possibilities to select a specific one as a solid or most-likely guess. In other words, Occam's Razor produces no answer in this case because there's too many possibilities and insufficient information to select among them for a top guess(es).
It's indeed true that "important" and "paid well" are not necessarily the same. Those who make smart or wise observations may not be paid so well and that could be a problem.
For example, solving "how" to make automated military tanks may skip over the question of "why" because those solving "how" are paid too well to bother.
Borland Delphi....It's really a shame nobody has pushed this direction. It worked really, really well.
If someone just finds a way to make Delphi/Lazarus easy to deploy (install & upgrade) on desktops, it might catch on in corporations. Desktop deployment headaches are mainly what made Web-based applications catch on. Solve the deployment problem and we can get away from the spaghetti web stacks, and UI's become simpler to make again. MUISA!
Some say Microsoft has greatly improved Windows WPF application deployment, making it automatically detect upgrades, prompting users; and optionally automatically upgrading without a prompt if the developers choose. The pendulum often swings, so maybe desktop apps are back.
Well maybe, but they are usually less critical. If your ad doesn't display right on 2% of browsers, that's not a big loss. If your app doesn't work on 2% of browsers, then you flood your help desk.
Add a growing internet, with many users of your page. Now you need to know how to make a scalable system, and how to design a proper database.
You should let a DBA or at least somebody with solid training and experience in databases design the schemas and indexes.
But there's also a reverse problem in "scaling" when shops adopt technologies meant for scaling that they don't need. You are making a podunk application, but your ego wants to be Netflix or Amazon, so you use CouchDB and microservices. The result is far more code than it would be with regular components.
another problem is it's not clear how "easier" is being scored. You have to show what it's being compared to, and have some objective and agreed upon metric for scoring "easier". "Author X likes notation Y" doesn't necessarily translate to benefits beyond Author X.
Stop assuming you can get it right on the first try and experiment. Draft up some plans and sample languages or API's/XML and let people comment. Come up with about a dozen sample applications, such as college class and grades tracking, hotel reservations, etc. to see how they do under each test stack.
Yes, it takes time and resources, but that's different than "can't be done". And I've mentioned a tool or two that appears to be on the right track. Let's understand why they do what they do well and build on that.
The gun handler claimed it was an accident. Just because you don't like the Jury's decision does not make the reason related to amnesty. Did you dissect the jurors' neurons or something?
Sorry, but it just doesn't seem relevant to the kind of applications I see day to day. The author seems to specialize in building graphic design and publishing tools of the kind Adobe specialize in. It's a fine niche, but it ain't mine.
If good tools were so easy to make they would already exist.
They do: VB, Delphi/Lazarus, PowerBuilder, Oracle Forms, Paradox, Clarion, and a few others.
The problem was deployment, and NOT programming productivity. Nobody ever said, "Our GUI/CRUD tools make programming too tedious, let's go Web!" Deployment issues are what "sold" the web: reduction of client-side installs and updates. But, we should revisit the assumptions behind all this.
As I mentioned elsewhere, Oracle Forms used to have a thin client that was relatively easy to install and distribute, but they mucked that up when they converted it to Java: a really fat client.
The mantra of the Web was that in order to get easy or no deployment you had to live with a more complicated and layered development environment. You either hired 25 more deployment specialists (desktop support) or 10 more programmers, and the second looked cheaper to most bosses and owners. (It's why we've had a dev boom/bubble.)
Implied is a fundamental trade-off between simple development and simple deployment. The theory is that one MUST make this trade-off; that it's hard-wired into the Universe.
But I'm not convinced it's a Law of Nature. Nobody's produced something akin to Amdahl's Law for an inherent dev-vs-deployment tradeoff.
Pre-Java Oracle Forms seemed to just about get it right (with some fixable qualms). I believe if the client's and server's responsibilities are partitioned well to avoid a bloated client standard, we can have the best of both, or at least a better mix than the current web mess. A work-world-oriented "GUI browser" standard.
I don't see much concrete and relevant there. The educational drawing gizmo is interesting, but doesn't represent the typical business apps I see day to day.
I'd say it depends on what you are trying to do. As a general purpose programming language, VB indeed did suck. But as a platform for internal CRUD applications (data entry and search forms), it simplified a lot of common tasks. Users loved tabbed forms.
Delphi was more flexible in terms of customizing the architecture and distribution. For data-centric applications with a similar drag-and-drop programming feel, there was also PowerBuilder.
A language or tool probably cannot be optimized for all usages. Same with the web browser: it's pretty good for e-brochures, but weak at productivity and data-centric applications.
It's not the 80s anymore. Useful systems are complex, have many layers, and tend to grow new layers over time.
I have to disagree. The necessary CRUD, GUI, and relational idioms to do the job of typical business applications are mostly the same as the 80's. The web and silly fads came in and mucked it up, turning bicycle science into rocket science by pounding a square peg into a round hole.
Nobody seems interested in exploring and developing new standards to make CRUD and productivity applications easier again. The arcane fidgety nature of the state of the art is too much job security: simplification may trigger an IT bust.
For example, the Oracle Forms developers at our shop can crank out applications at about 1/7 the pace of the "web" oriented developers. The result is not aesthetic, but they work and get the job done. (Oracle is a jerk in other ways, but Forms just works.)
But our shop has to migrate away from Oracle Forms because Oracle stopped making a Forms client and converted it to Java. Java doesn't get along with our security infrastructure. Flash and Java made the same mistake of making their client into do-all behemoth, which resulted in security holes. If they or the industry had focused on making just a "GUI browser" (hopefully with an open standard), we could toss HTML browsers for productivity applications. HTML browsers are better for e-brochures, and not eCRUD.
So, if you want to fix it, learn from past products that work, and produce a stateful "GUI Browser" standard. Let's go back to coordinate based clients instead of client-size auto-flow placement. The server side can resize for the client size as needed. That way we have one placement engine instead of the 50+ placement engines we have now (browser brands & versions). Client-side layout sucks big productivity donkey dicks. (This is not the same as proposing only WYSIWYG as some critics have claimed, because the server can still do auto-flow if desired.)
Put on the client just enough to get the client job done, shifting the rest to the server, but otherwise learn from the failure Java applets and Flash and don't make the client into a do-everything monstrosity. (Resisting Emacs jokes.)
GOP is not "divided" on the issue: they've had at least 2 chances for reform and border guard increases, and flaked both times. They only give it lip service because GOP voters want to hear it, but flake because their biz funders DONT want it. Legalized bribery works.
(You are spinning the Kate Steinle story. It's more nuanced.)
The Democrats have become the party of illegal immigration.
Both parties have neglected the issue, but for different reasons. Democrats tend to ignore it because illegals are more likely to give birth to future Democrat voters.
And GOP has ignored it because business likes the cheap labor illegals bring, and business funds GOP campaigns.
If Democrats were really serious about immigration, they'd work with Trump and bring a sane immigration policy that put American interests first.
Sorry, but the Orange Guy is doing it wrong. Rather than obsessing on a wall, focus on hiring more border guards, and auditing business hiring practices. He seems reluctant to do the second because he's a "pro business" politician, and doesn't want Mar-a-Lago etc. audited.
Democrats once offered a bill to hire more border guards, but GOP turned it down, in part over alleged debt concerns.
Okay, I agree, and I should have made that clear. But it doesn't change my point that there are, or at least can be, other issues besides the base language itself that override base language benefits. Use the right tool for the job at hand.
Should be irrelevant with a good deployment and test strategy.
True, but sometimes it's hard to get "good" people to do it and/or do it right.
There are plenty of relevant Python libraries and tutorials.
For web-based application, I just found more for PHP and they seemed a bit more mature. Maybe in the future Python will catch up, but it has a ways to go.
There are plenty of Python templating libraries.
True, but you have to add the library and different people are familiar with different libraries (or none). Anyone who knows PHP knows its default templating engine.
They are not show-stopper issues, I agree, but on average PHP just makes web-ing easier.
I generally agree, but with an "it depends" closely bound to Conway's Law. If the designers are a separate group from the application coders, then templating is quite handy. If coders do everything and will likely continue to, then direct templating has less overall benefits.
Python is popular as a language itself, but often other factors should be considered. For example, we were looking at PHP versus Python as a possible alternative to Microsoft dotnet. These factors seem to override language-only issues in PHP's favor:
1. Easier web deployment on test, staging, and production because it's built for the web.
2. More web-oriented functions, libraries, and related tutorials/forums.
3. Built-in HTML-embed templating language. This is important if designers are separate from app coders and/or you want modular UI parts.
Most of the work should be gluing together libraries and function calls such that the language itself shouldn't really matter: we are not solving dark energy math, we mostly are marshaling data back and forth and gluing it to the UI and API's. Mundane perhaps, but it's our job to do mundane efficiently.
If you can show that a given language outright gets in the way of building and gluing libraries & templates, then I'd like to hear about it. Usually it's a matter of trade-offs: each language does different things better.
The environment and libraries override PHP's weakness as a language. (I do wish PHP would add named parameters, though.)
There were no slumps in those years you mentioned that affected all the STEM professions simultaneously.
There does seem to be a correlation. For example, the "Glasnost" aerospace slump of the early 1990's did affect IT jobs to some degree, by my observation. (Although there was a general econ slump also that makes it difficult to really know.) There is enough cross-over such that a big slump in one STEM area does seem to push on others. Some aerospace engineers have IT experience and vice versa.
But you are right that my account is an over-simplification. I fully admit it. Thorough writing is often criticized (or ignored) for being long-winded such that people often oversimplify their description of the world for brevity. It's hard to make everyone happy, but the average person prefers short over full accuracy.
This issue does not significantly affect my main point that past or current patterns of demand are not sufficient to predict future patterns. The IT/coding "boom" of the last 15 or so years could be a long-term trend or a short term trend and we cannot really tell, only guess. Many career-related articles imply that "the future is STEM". That's not a reliable prediction.
Slashdot Mirror
It's in the fake comics. It was put there to throw off slashdot googlers.
You cannot accuse a jury of being biased for a specific motivation based on Occam's Razor. You were not on the jury and were not privy to the discussion. You have no specific details to suggest the jury "did it wrong". They too should be considered innocent until proven guilty.
If you use Occam's Razor to form an internal personal guess, that's fine, but you implied it was definitive conclusion. Don't open your trap unless you have reasonably solid evidence, NOT personal guesses using very indirect means. This is Slashdot; we expect more logic and details, not stream of conscientiousness chatter. If we wanted the latter, we'd tune into the President.
And to me, Occam's Razor says there are too many alternative possibilities to select a specific one as a solid or most-likely guess. In other words, Occam's Razor produces no answer in this case because there's too many possibilities and insufficient information to select among them for a top guess(es).
Man up and admit you made a mistake.
It's indeed true that "important" and "paid well" are not necessarily the same. Those who make smart or wise observations may not be paid so well and that could be a problem.
For example, solving "how" to make automated military tanks may skip over the question of "why" because those solving "how" are paid too well to bother.
So, you have NO real evidence, you are just guessing out of your FoxHole. I wasted my time debating you.
If someone just finds a way to make Delphi/Lazarus easy to deploy (install & upgrade) on desktops, it might catch on in corporations. Desktop deployment headaches are mainly what made Web-based applications catch on. Solve the deployment problem and we can get away from the spaghetti web stacks, and UI's become simpler to make again. MUISA!
Some say Microsoft has greatly improved Windows WPF application deployment, making it automatically detect upgrades, prompting users; and optionally automatically upgrading without a prompt if the developers choose. The pendulum often swings, so maybe desktop apps are back.
Well maybe, but they are usually less critical. If your ad doesn't display right on 2% of browsers, that's not a big loss. If your app doesn't work on 2% of browsers, then you flood your help desk.
You should let a DBA or at least somebody with solid training and experience in databases design the schemas and indexes.
But there's also a reverse problem in "scaling" when shops adopt technologies meant for scaling that they don't need. You are making a podunk application, but your ego wants to be Netflix or Amazon, so you use CouchDB and microservices. The result is far more code than it would be with regular components.
another problem is it's not clear how "easier" is being scored. You have to show what it's being compared to, and have some objective and agreed upon metric for scoring "easier". "Author X likes notation Y" doesn't necessarily translate to benefits beyond Author X.
Stop assuming you can get it right on the first try and experiment. Draft up some plans and sample languages or API's/XML and let people comment. Come up with about a dozen sample applications, such as college class and grades tracking, hotel reservations, etc. to see how they do under each test stack.
Yes, it takes time and resources, but that's different than "can't be done". And I've mentioned a tool or two that appears to be on the right track. Let's understand why they do what they do well and build on that.
The gun handler claimed it was an accident. Just because you don't like the Jury's decision does not make the reason related to amnesty. Did you dissect the jurors' neurons or something?
Sorry, but it just doesn't seem relevant to the kind of applications I see day to day. The author seems to specialize in building graphic design and publishing tools of the kind Adobe specialize in. It's a fine niche, but it ain't mine.
They do: VB, Delphi/Lazarus, PowerBuilder, Oracle Forms, Paradox, Clarion, and a few others.
The problem was deployment, and NOT programming productivity. Nobody ever said, "Our GUI/CRUD tools make programming too tedious, let's go Web!" Deployment issues are what "sold" the web: reduction of client-side installs and updates. But, we should revisit the assumptions behind all this.
As I mentioned elsewhere, Oracle Forms used to have a thin client that was relatively easy to install and distribute, but they mucked that up when they converted it to Java: a really fat client.
The mantra of the Web was that in order to get easy or no deployment you had to live with a more complicated and layered development environment. You either hired 25 more deployment specialists (desktop support) or 10 more programmers, and the second looked cheaper to most bosses and owners. (It's why we've had a dev boom/bubble.)
Implied is a fundamental trade-off between simple development and simple deployment. The theory is that one MUST make this trade-off; that it's hard-wired into the Universe.
But I'm not convinced it's a Law of Nature. Nobody's produced something akin to Amdahl's Law for an inherent dev-vs-deployment tradeoff.
Pre-Java Oracle Forms seemed to just about get it right (with some fixable qualms). I believe if the client's and server's responsibilities are partitioned well to avoid a bloated client standard, we can have the best of both, or at least a better mix than the current web mess. A work-world-oriented "GUI browser" standard.
I don't see much concrete and relevant there. The educational drawing gizmo is interesting, but doesn't represent the typical business apps I see day to day.
I'd say it depends on what you are trying to do. As a general purpose programming language, VB indeed did suck. But as a platform for internal CRUD applications (data entry and search forms), it simplified a lot of common tasks. Users loved tabbed forms.
Delphi was more flexible in terms of customizing the architecture and distribution. For data-centric applications with a similar drag-and-drop programming feel, there was also PowerBuilder.
A language or tool probably cannot be optimized for all usages. Same with the web browser: it's pretty good for e-brochures, but weak at productivity and data-centric applications.
I have to disagree. The necessary CRUD, GUI, and relational idioms to do the job of typical business applications are mostly the same as the 80's. The web and silly fads came in and mucked it up, turning bicycle science into rocket science by pounding a square peg into a round hole.
Nobody seems interested in exploring and developing new standards to make CRUD and productivity applications easier again. The arcane fidgety nature of the state of the art is too much job security: simplification may trigger an IT bust.
For example, the Oracle Forms developers at our shop can crank out applications at about 1/7 the pace of the "web" oriented developers. The result is not aesthetic, but they work and get the job done. (Oracle is a jerk in other ways, but Forms just works.)
But our shop has to migrate away from Oracle Forms because Oracle stopped making a Forms client and converted it to Java. Java doesn't get along with our security infrastructure. Flash and Java made the same mistake of making their client into do-all behemoth, which resulted in security holes. If they or the industry had focused on making just a "GUI browser" (hopefully with an open standard), we could toss HTML browsers for productivity applications. HTML browsers are better for e-brochures, and not eCRUD.
So, if you want to fix it, learn from past products that work, and produce a stateful "GUI Browser" standard. Let's go back to coordinate based clients instead of client-size auto-flow placement. The server side can resize for the client size as needed. That way we have one placement engine instead of the 50+ placement engines we have now (browser brands & versions). Client-side layout sucks big productivity donkey dicks. (This is not the same as proposing only WYSIWYG as some critics have claimed, because the server can still do auto-flow if desired.)
Put on the client just enough to get the client job done, shifting the rest to the server, but otherwise learn from the failure Java applets and Flash and don't make the client into a do-everything monstrosity. (Resisting Emacs jokes.)
GOP is not "divided" on the issue: they've had at least 2 chances for reform and border guard increases, and flaked both times. They only give it lip service because GOP voters want to hear it, but flake because their biz funders DONT want it. Legalized bribery works.
(You are spinning the Kate Steinle story. It's more nuanced.)
Doctor: "Bob, you are not getting enough sleep. I'm giving you a prescription for Comcast."
Both parties have neglected the issue, but for different reasons. Democrats tend to ignore it because illegals are more likely to give birth to future Democrat voters.
And GOP has ignored it because business likes the cheap labor illegals bring, and business funds GOP campaigns.
Sorry, but the Orange Guy is doing it wrong. Rather than obsessing on a wall, focus on hiring more border guards, and auditing business hiring practices. He seems reluctant to do the second because he's a "pro business" politician, and doesn't want Mar-a-Lago etc. audited.
Democrats once offered a bill to hire more border guards, but GOP turned it down, in part over alleged debt concerns.
Okay, I agree, and I should have made that clear. But it doesn't change my point that there are, or at least can be, other issues besides the base language itself that override base language benefits. Use the right tool for the job at hand.
True, but sometimes it's hard to get "good" people to do it and/or do it right.
For web-based application, I just found more for PHP and they seemed a bit more mature. Maybe in the future Python will catch up, but it has a ways to go.
True, but you have to add the library and different people are familiar with different libraries (or none). Anyone who knows PHP knows its default templating engine.
They are not show-stopper issues, I agree, but on average PHP just makes web-ing easier.
I generally agree, but with an "it depends" closely bound to Conway's Law. If the designers are a separate group from the application coders, then templating is quite handy. If coders do everything and will likely continue to, then direct templating has less overall benefits.
Everybody wants a cut. Governments just happen to have to the power to get it.
Python is popular as a language itself, but often other factors should be considered. For example, we were looking at PHP versus Python as a possible alternative to Microsoft dotnet. These factors seem to override language-only issues in PHP's favor:
1. Easier web deployment on test, staging, and production because it's built for the web.
2. More web-oriented functions, libraries, and related tutorials/forums.
3. Built-in HTML-embed templating language. This is important if designers are separate from app coders and/or you want modular UI parts.
Most of the work should be gluing together libraries and function calls such that the language itself shouldn't really matter: we are not solving dark energy math, we mostly are marshaling data back and forth and gluing it to the UI and API's. Mundane perhaps, but it's our job to do mundane efficiently.
If you can show that a given language outright gets in the way of building and gluing libraries & templates, then I'd like to hear about it. Usually it's a matter of trade-offs: each language does different things better.
The environment and libraries override PHP's weakness as a language. (I do wish PHP would add named parameters, though.)
There does seem to be a correlation. For example, the "Glasnost" aerospace slump of the early 1990's did affect IT jobs to some degree, by my observation. (Although there was a general econ slump also that makes it difficult to really know.) There is enough cross-over such that a big slump in one STEM area does seem to push on others. Some aerospace engineers have IT experience and vice versa.
But you are right that my account is an over-simplification. I fully admit it. Thorough writing is often criticized (or ignored) for being long-winded such that people often oversimplify their description of the world for brevity. It's hard to make everyone happy, but the average person prefers short over full accuracy.
This issue does not significantly affect my main point that past or current patterns of demand are not sufficient to predict future patterns. The IT/coding "boom" of the last 15 or so years could be a long-term trend or a short term trend and we cannot really tell, only guess. Many career-related articles imply that "the future is STEM". That's not a reliable prediction.
MAGA = Moscow Agent Governing America