Part of the problem is that the default Java GUI framework is a bit awkward, and partly that applets don't solve the middle-ground between web-page and CRUD gui's.
Applets and Flash showed hints of what a better standard could be like from a developer perspective, but are sort of a walled garden away from the rest of the web, and tangled up in proprietary interests.
A good standard that fits well into both worlds would probably have to look like or extend HTML with common desktop-like GUI idioms already built in.
Partly true, but the out-of-the-box widgets and feature set generally covered many more of the common GUI idioms than out-of-the-box HTML/CSS/DOM/JS. Those desktop kits generally handled about 85% of what you needed without requiring add-ons or additional big libraries, but with HTML/CSS/DOM/JS it's more like 30%. You gotta include a lot of stuff just to get GUI basics. Those common GUI idioms should be built into HTML (or equiv) in my opinion so that we get most of them declaratively. Combo boxes, sub-window resizing, most drag-and-drop, form field validation by reg-ex and/or types, partial/incremental-page "in-place" refreshes etc. should be commodity attributes and features by now. It's not like I'm asking for flying cars.
Perhaps the standard can focus on just IT (or diff standards per industry) instead of try to fit all industries. That way it doesn't have to try to cast a wide net.
Government has IT talent, although not in the IRS' desktop support division.
To be fair, long-term archiving is not the job of desktop computers. A true archive system costs money, i.e. tax money. There was a push around the time at issue to shrink gov't cost. Now they are bitching about not having sufficient equipment. You cannot have it both ways.
According to Wikipedia, only roughly 3k people a year go to jail over tax evasion in the US. It could make getting a legitimate job difficult, but instances of physical restraint are small relative to the total population.
The hardest part is trying to get a web browser to act like a desktop GUI, which is what customers want. We have to glue together a jillion frameworks and libraries, creating a big fat-client Frankenstein with versioning snakes ready to bite your tush. Great job security, perhaps, but also an Excedrin magnet. What use is lining your pockets if you die too early to spend it?
It's time for a new browser standard that is desktop-GUI-like friendly. The HTML/DOM stack is not up to the job.
Dynamic languages (JavaScript) are fine as glue languages and small event handling, but to try to make them into or use them for a full-fledged virtual OS or GUI engines is pushing dynamic languages beyond their comfort zone. Static typing is better for base platform tools/libraries. You don't write operating systems in dynamic languages.
Somebody please stab and kill the HTML/DOM stack so we can move on to a better GUI fit.
They never actually live up to the hype...I remember when the salespeople were touting dBase II and how programming would be completely changed. Right.
For custom biz app programming, dBASE and clones did live up to most of the hype in my opinion. I was able to crank out small-to-medium CRUD apps pretty damned quick compared to using Pascal or MS-BASIC or C (of the day), and users were quite happy.
True, you were limited on UI conventions, and if you didn't follow certain code conventions, dBASE's loosy-goosy scoping rules would byte you in the ass. But the tight integration between the language and the data simplified a lot of CRUD idioms. And its command-line prototyping was magical.
dBASE got a bad reputation when people started trying to scale its source code size, UI, and market (packaged/box apps) beyond its original niche. If you use a Toyota Corella to haul big trailers, it will indeed fail. Use the right tool for the job and know its limits rather than force things.
I was programming circles around everybody else with dBASE for smaller apps, even against MS-Access (and more reliable). It did well what it did well. Good Times; I miss it.
Ada actually has some nice properties, but its sheer number of features makes it difficult to learn and find developers for.
Committees do tend to catch feature-itus because they try to make everybody on the committee happy. It's difficult to get good pruning of features from committees. They are pretty good at generating ideas, but NOT good at weighing trade-offs by saying "no" to the right things.
No, you are only coerced to choose among multiple private vendors. That's mostly different. And you can still skip buying, but you will have a skipper's fee.
Whether that plan is "good for society" or not is probably another topic. I'm just bothered by your particular comparison.
I've seen big private organizations with a lot of slack also. Big, complex organizations are just difficult to manage, period. Look at all of Microsoft's and Sony's screw-ups, for example.
The one key difference though is that in the private sector one must meet sales expectations. If your teem doesn't produce sales, it's dismantled and people often fired. It's not always fair, but it is a constant pressure that puts a limit on goofing off.
The patent office doesn't really have the equivalent. Number of patents processed is not a very effective metric because one can slack on quality in exchange for quantity, and quality is difficult to measure because it requires a lot of specialists, who are hard to find and expensive. (Layers of auditors are not cheap, tax-wise.)
However, I do notice that the private sector "wastes" a lot of resources on manipulative marketing rather than making a better mousetrap: they've found it's often cheaper to trick the customer into buying an inferior mousetrap rather than just making a good trap. (The exception may be cars, which have a lot of consumer attention from both the public and consumer organizations.)
Thus, both public and private have plenty of BS and waste, it's just a different form of BS. The public sector generally does work harder, but often harder at manipulating buyers.
Let me rework that to reflect it more accurately: Patent US 9063520 A: The U.S. Patent and Trademark Office A method and system for under-performing approv...zzzz zz ZZzz...ZZZZZ...
a "significant" number of examiners did not work for long periods, then rushed to get their reviews done at the end of each quarter.
Where does this deadline cycle NOT happen?
Managers and/or auditors could spend more time monitoring employees, but then you have to pay the monitors and hire more managers, and also monitor the monitors to make sure they are monitoring correctly, creating a recursive bloat in inspection time.
Further, the monitors and monitor of monitors would have to be experts to know if employees are really spending quality time. If you just count time staring at the screen, typing, or reading research, you can't know if it's relevant to the task unless you are an expert in that specialty also. Industry-specific auditors are going to be pretty expensive.
Plus, recruiting is harder and/or more expensive if potential specialty employees find out their ass is always under Big Brother's watch.
Brick-laying is relatively easy to monitor. Intellectual tasks, not so much.
Sometimes it's just cheaper to accept some slack than add bureaucracy layers to prevent all slack.
(It's similar to weeding out welfare cheats: Republicans want to heavily monitor welfare recipients, but the cost of monitoring and related lawsuits could be more than the welfare cheating, making taxes even higher, which Republicans can't stand...or at least act like they can't stand.)
Managers should be able to give bonus pay and/or penalties for productivity. However, in practice this often results in favoritism as managers judge based on friendship or kissing up rather than raw merit. Humans are just that way, in general.
running them off of cliffs...Was this used for a similar purpose?
Only if there is a way to get to the bottom of the cave and carry out the prey, such as a side entrance. But I have heard about traps that use a similar technique: dig a hole at a narrow passage, cover it with hide, sticks, and dirt, and wait for a sucker to step on it and fall in. Dinner!
Native Americans are always said to have lived in peace with one another. If that were true, how come Europeans met with warriors
They didn't live in peace, all humans fight and they are no different. The difference is that there usually wasn't genocide: if there was a clear victory, the losing tribe merged with the winning one (at least the women and children).
If a predator such as a mountain lion falls in and survives, he may actually have an easy life if new food falls in every few weeks. Even if the lion breaks its legs and can only hobble, bigger prey may be in worse condition, and thus readily munch-able, especially if the prey is vegetarian because they'd grow too weak to fight back being there's not much to live on down there.
And the lion may get really lucky if another lion of the opposite sex falls in. They can limp around together and munch fallen buffalo and have a family.
I doubt the frequency of falls is actually that high, but if the opening was at a highly-trafficked spot, such as near a watering hole or narrow passage through hills, it could be productive.
Slashdot Mirror
Part of the problem is that the default Java GUI framework is a bit awkward, and partly that applets don't solve the middle-ground between web-page and CRUD gui's.
Applets and Flash showed hints of what a better standard could be like from a developer perspective, but are sort of a walled garden away from the rest of the web, and tangled up in proprietary interests.
A good standard that fits well into both worlds would probably have to look like or extend HTML with common desktop-like GUI idioms already built in.
Partly true, but the out-of-the-box widgets and feature set generally covered many more of the common GUI idioms than out-of-the-box HTML/CSS/DOM/JS. Those desktop kits generally handled about 85% of what you needed without requiring add-ons or additional big libraries, but with HTML/CSS/DOM/JS it's more like 30%. You gotta include a lot of stuff just to get GUI basics. Those common GUI idioms should be built into HTML (or equiv) in my opinion so that we get most of them declaratively. Combo boxes, sub-window resizing, most drag-and-drop, form field validation by reg-ex and/or types, partial/incremental-page "in-place" refreshes etc. should be commodity attributes and features by now. It's not like I'm asking for flying cars.
Perhaps the standard can focus on just IT (or diff standards per industry) instead of try to fit all industries. That way it doesn't have to try to cast a wide net.
I have a binder full of Mitt jokes.
To be fair, long-term archiving is not the job of desktop computers. A true archive system costs money, i.e. tax money. There was a push around the time at issue to shrink gov't cost. Now they are bitching about not having sufficient equipment. You cannot have it both ways.
Why it's ColdFusion...done wrong!
According to Wikipedia, only roughly 3k people a year go to jail over tax evasion in the US. It could make getting a legitimate job difficult, but instances of physical restraint are small relative to the total population.
It's called "Artificial Sloth Scaled". Makes a catchy acronym.
JavaScript is the new COBOL already? Damn, I'm gettin' old. (At least COBOL works :-)
The hardest part is trying to get a web browser to act like a desktop GUI, which is what customers want. We have to glue together a jillion frameworks and libraries, creating a big fat-client Frankenstein with versioning snakes ready to bite your tush. Great job security, perhaps, but also an Excedrin magnet. What use is lining your pockets if you die too early to spend it?
It's time for a new browser standard that is desktop-GUI-like friendly. The HTML/DOM stack is not up to the job.
Dynamic languages (JavaScript) are fine as glue languages and small event handling, but to try to make them into or use them for a full-fledged virtual OS or GUI engines is pushing dynamic languages beyond their comfort zone. Static typing is better for base platform tools/libraries. You don't write operating systems in dynamic languages.
Somebody please stab and kill the HTML/DOM stack so we can move on to a better GUI fit.
For custom biz app programming, dBASE and clones did live up to most of the hype in my opinion. I was able to crank out small-to-medium CRUD apps pretty damned quick compared to using Pascal or MS-BASIC or C (of the day), and users were quite happy.
True, you were limited on UI conventions, and if you didn't follow certain code conventions, dBASE's loosy-goosy scoping rules would byte you in the ass. But the tight integration between the language and the data simplified a lot of CRUD idioms. And its command-line prototyping was magical.
dBASE got a bad reputation when people started trying to scale its source code size, UI, and market (packaged/box apps) beyond its original niche. If you use a Toyota Corella to haul big trailers, it will indeed fail. Use the right tool for the job and know its limits rather than force things.
I was programming circles around everybody else with dBASE for smaller apps, even against MS-Access (and more reliable). It did well what it did well. Good Times; I miss it.
Where is the official rule that "programming languages" have to be Turing Complete?
They are to a good hacker.
Ada actually has some nice properties, but its sheer number of features makes it difficult to learn and find developers for.
Committees do tend to catch feature-itus because they try to make everybody on the committee happy. It's difficult to get good pruning of features from committees. They are pretty good at generating ideas, but NOT good at weighing trade-offs by saying "no" to the right things.
Can't, I just patented Artificial Sloth.
Worse, they pretend the whole time, but blame the other party at the end of 3 months regardless of (non) findings.
"Why did it take them so long to discover the harddrive was recycled? That looks suspicious, very very suspicious. More investigations, charrrrge!"
Hey, if they invent practical flying cars or star travel, they deserve some good ol' goof-off time.
If I can arrive at the Risa Galactic Hilton within 15 years, I'll personally buy them a 2k-Naps-for-Free card.
No, you are only coerced to choose among multiple private vendors. That's mostly different. And you can still skip buying, but you will have a skipper's fee.
Whether that plan is "good for society" or not is probably another topic. I'm just bothered by your particular comparison.
I've seen big private organizations with a lot of slack also. Big, complex organizations are just difficult to manage, period. Look at all of Microsoft's and Sony's screw-ups, for example.
The one key difference though is that in the private sector one must meet sales expectations. If your teem doesn't produce sales, it's dismantled and people often fired. It's not always fair, but it is a constant pressure that puts a limit on goofing off.
The patent office doesn't really have the equivalent. Number of patents processed is not a very effective metric because one can slack on quality in exchange for quantity, and quality is difficult to measure because it requires a lot of specialists, who are hard to find and expensive. (Layers of auditors are not cheap, tax-wise.)
However, I do notice that the private sector "wastes" a lot of resources on manipulative marketing rather than making a better mousetrap: they've found it's often cheaper to trick the customer into buying an inferior mousetrap rather than just making a good trap. (The exception may be cars, which have a lot of consumer attention from both the public and consumer organizations.)
Thus, both public and private have plenty of BS and waste, it's just a different form of BS. The public sector generally does work harder, but often harder at manipulating buyers.
Let me rework that to reflect it more accurately:
Patent US 9063520 A: The U.S. Patent and Trademark Office
A method and system for under-performing approv...zzzz zz ZZzz...ZZZZZ...
But goofing off is relative.
Where does this deadline cycle NOT happen?
Managers and/or auditors could spend more time monitoring employees, but then you have to pay the monitors and hire more managers, and also monitor the monitors to make sure they are monitoring correctly, creating a recursive bloat in inspection time.
Further, the monitors and monitor of monitors would have to be experts to know if employees are really spending quality time. If you just count time staring at the screen, typing, or reading research, you can't know if it's relevant to the task unless you are an expert in that specialty also. Industry-specific auditors are going to be pretty expensive.
Plus, recruiting is harder and/or more expensive if potential specialty employees find out their ass is always under Big Brother's watch.
Brick-laying is relatively easy to monitor. Intellectual tasks, not so much.
Sometimes it's just cheaper to accept some slack than add bureaucracy layers to prevent all slack.
(It's similar to weeding out welfare cheats: Republicans want to heavily monitor welfare recipients, but the cost of monitoring and related lawsuits could be more than the welfare cheating, making taxes even higher, which Republicans can't stand...or at least act like they can't stand.)
Managers should be able to give bonus pay and/or penalties for productivity. However, in practice this often results in favoritism as managers judge based on friendship or kissing up rather than raw merit. Humans are just that way, in general.
In short, no easy fix.
I bet in a few years, a new theory called "Dark Bang" will replace it.
Only if there is a way to get to the bottom of the cave and carry out the prey, such as a side entrance. But I have heard about traps that use a similar technique: dig a hole at a narrow passage, cover it with hide, sticks, and dirt, and wait for a sucker to step on it and fall in. Dinner!
They didn't live in peace, all humans fight and they are no different. The difference is that there usually wasn't genocide: if there was a clear victory, the losing tribe merged with the winning one (at least the women and children).
Those are all the same thing :-)
If a predator such as a mountain lion falls in and survives, he may actually have an easy life if new food falls in every few weeks. Even if the lion breaks its legs and can only hobble, bigger prey may be in worse condition, and thus readily munch-able, especially if the prey is vegetarian because they'd grow too weak to fight back being there's not much to live on down there.
And the lion may get really lucky if another lion of the opposite sex falls in. They can limp around together and munch fallen buffalo and have a family.
I doubt the frequency of falls is actually that high, but if the opening was at a highly-trafficked spot, such as near a watering hole or narrow passage through hills, it could be productive.