Ext-JS is known to have a long learning curve, has cryptic or missing error messages (blank areas instead of messages), and is sluggish to load because of its fat libraries.
Middle-man layers create more busy work and more layers to change when requirements change. They are often a favorite for consultants who want to gold-plate the application/system to run up their charges.
But you do know that OO models are mapped trivially directly to relational models and vice versa?
Trivially? I don't think so. OO-RDB mappers are often considered a royal PITA. I suspect some will say "but they are doing it wrong". Again it's yet another case of OO domain modelling being hard to get right and hard to know if you are doing it right.
I have not seen any. Some mistake corrections for malice without giving a solid case that it's malice.
I will agree that "messaging" data is fairly common in science to exaggerate the intended conclusion because conclusion-free papers don't get much attention, but that works both ways. There's no reason why the vast majority of such fudging should be in the pro-change direction instead of the anti-change direction.
A tenured professor in a private university close to retirement has no financial incentive to fudge toward a pro-change conclusion: he/she already has their money and will be exiting from the work-force soon to enjoy their guaranteed retirement money.
If the bias claimers could show that those closer to retirement and/or have tenure are less likely to produce pro-change conclusions in the climate studies, then the bias-claimers would have a case. I haven't seen such. If funding source affects research results, then there should be a statistical relationship to be found. Go find it!
I wouldn't quite put it that way. Often a life-time of experience builds up "notions" of patterns. We don't remember every detail, but we do grow aggregate impressions similar to how artificial neural nets are trained over time even though the nets don't remember each specific training case.
For example, I've experienced the slime-ballery of big companies like Microsoft, the cable/telecoms (AT&T, Comcast), banks, etc. I've even worked for some to see the slime-ballery from the inside also.
All these experiences have built up a big distrust of big companies such that I take almost everything they say with a big grain of salt, including that massive deregulation is the magic to sparking the economy. (Further, the details of their dereg plans usually allow them to grow even bigger and buy up or sue away all their competition.)
I've also experienced the sluggishness of the public sector first hand. It is slow, but in general is not madly driven to rip you off. A monster who wants to nap does less damage than one who wants to eat you.
It's also true individuals don't remember every event equally and/or different events make stronger impressions than others. Our gray-matter neural nets respond differently to different stimuli. Emotion may indeed play a part in that as we respond emotionally differently to a given event.
Some may perceive being ripped off by a big co as a learning experience for the consumer instead of act of malice by the big co. The big co. is giving the consumer an education. The Trump-U "graduate" now can recognize spin because they have heavy personal experience of it. The "graduate" came away wiser; isn't that what education is about?
Every known politician is a spinner. Trump's and Cruz's politifact.com score is much worse than H's, by the way.
I don't believe it's possible for an honest politician to survive long, in large part because most voters are low-information voters.
By the way, why is it expected H to know that a given fact sent to her in a given email was classified? I have not heard a clear argument for "she should have known". In one case there was a "C." that indicates likely classified info (although the classified info itself was not in the body, just the marker), but what about the others? I'm not saying she's "off the hook", I just want to see a strong argument for "should have known." Comey's a known drama-king based on the iPhone back-door incident.
A keeper-of-classified-info-database clerk should be watching that, not the head honcho. The CEO's time is too valuable.
Republicans won't listen to science, you think Facebook posts are going to make a difference?
That's not quite a fair assessment of their stance. In general they believe that the profit motive applies to scientists as well as business-persons such that scientists will bias their results to get more money just like any salesperson would. You could argue they are projecting their own greed into scientists, but they can claim that human nature is human nature, and most humans are naturally greedy (which is the basis of capitalism's feedback mechanism).
You can argue specific climate facts, but they can always find a scientist (or a shill acting like a scientist) to poke holes in such facts.
It's true that the Earth is a complex system with lots of "moving parts" such that its climate is the aggregate result of jillions of factors.
You could point out that in most models, more CO2 warms the earth, and we know the CO2 increase is largely man-made due to the isotope signature.
But they may reply that not all models show CO2 warming the Earth and/or the temperature readings are rigged by those "greedy scientists" I mentioned above such that there is no excessive warming beyond the normal natural ebb and flow.
How does one prove scientists didn't rig temperature readings? There were no cameras following them 24/7. Ultimately it relies on trust, and if they believe scientists don't deserve our trust, there's not much one can do.
Unfortunately we may have to wait until their tushies bake off or their houses are under the sea until they get a clue. Reality is merely poking them right now, but they'll only notice it when it kicks them in the nuts/cunt.
Specifically, so-called "web" interface programming using client-side Javascript on the DOM.
Amen! Productivity (work-related) application programming (CRUD) using HTML/DOM/JS is a f8cking nightmare.
Part of the problem is that each browser brand/version combo can potentially render things differently such that you have to test on say 30+ combo's of browsers and devices to cover all bases, AND future versions may STILL break it after all those 30+ tests. My hair is turning Bernie Sanders shades over that crazy shit (and falling out like his). It makes the DLL-hell of the 90's feel better in comparison. Now we have render-hell.
Possible solutions include bringing back WYSIWYG and/or vector coordinates, OR doing the "auto-flow" rendering on the server and making the browser be a dumb coordinate-based vector plotter. That way you are dealing with only one renderer instead of 30+.
Another idea is to put X Window engines on browsers, but I'm skeptical of the input box response. Input boxes should (optionally) buffer on the client.
Other ideas welcomed.
Sure, you if you put a lot of bloated margins around everything you can make stuff "shift proof" in the web stack; but it looks ugly, wastes space, and is often not what the customers want.
Views only help on the output side, not the input side. If you split domain nouns up into bunches of little tables, then you often have to manage the updating of bunches of little tables. The input screens and/or update ordering may not match the table divisions. Even if they start out that way, they may grow apart over time.
I have to agree that over-normalizing tables creates difficult-to-use and slow systems in general. There are exceptions, but they are probably dumb luck rather than from genius high-level-normalization experts. And you don't know up-front which of these box of chocolates you are getting under high normalization: genius-split tables, dumb-luck-good tables, or PITA tables. I usually encounter the PITA ones.
I don't see how that necessarily improves things, but another problem with domain-modeling in OOP is that nobody agrees on how to do it "right". There are no solidly-proven set of unambiguous rules to partition domain objects. If you have them, write them down so I can verify they are unambiguous. In other words, OOP domain-modelling is too easy to get wrong because it's too hard to know if you are "doing it right".
If 98% of human resources processing is on "employees", then adding an extra "person" layer into it doesn't help. Maybe if HR tracks and processes contractors also (which they may not, per org), it might help, but perhaps it would be easier for contractors and employees to be independent objects/classes if they are usually treated differently: a top level just gets in the way because it may not contribute much of actual use.
Over-normalizing relational tables can create similar problems: too many joins and keys to keep track of without helping much. And it slows processing down.
It's hard to say without studying the domain and intended use of the software. Having a generic model of the world would have too much indirection (levels/layers/components) to be practical for IT.
Relational generally doesn't require one to hard-wire domain verbs to a given set of domain nouns. Operations are often multi-noun anyhow such that tying them to a single noun is often arbitrary (forced) in OO. The real world is better modeled as virtual coming together of nouns for a particular purpose at a time, rather than trying to make universal declarations about which verbs go with which nouns.
The business world is situational, and our software models should reflect that. Noun X working with Noun Y on Tuesday shouldn't have to care about Noun X working with Noun Z on Friday. Many-to-many relationships tend to get really ugly to manage in OOP such that one ends up turning the OOP app into an (ugly) database to track and manage it all. Might as well start with the database instead and stop trying to make an OO mirror for it: that's double work.
It turns out OOP can be a pretty good tool for name-space management in many cases, but it has stunk at domain modelling. Domain modelling is how OO was "sold" to us for roughly the last 2 decades, and this was a fat mistake that turned many prematurely gray.
An example of domain modelling would be a human resources app that models employees, managers, offices, etc. as objects. This mostly flopped.
But OOP works fairly well for making API's to network and system services (and arguably GUI's, but that's another subject).
We are more likely to be roughly in the middle of the universe's time-period, or at least in the middle of its population of intelligent existence-ponderers.
We can thus statistically surmise that intelligent life is NOT likely to proliferate. I wouldn't Vegas-bet that we are "simply early". Math says otherwise. Expansion is wishful thinking.
However, there are some interesting caveats. In the future intelligent life may be more Borg-like or bot-based such that there are a smaller quantity of "individuals" pondering their existence. Borg/bot units don't ponder such unless explicitly assigned such a task because it's not efficient for individuals to re-invent pondering done by others. Intelligent life may proliferate, just NOT as individuals, as we know them.
This "solves" Copernican principle by reducing the quantity of future ponders without having to also assume general intelligent life reduction.
We also know it's difficult to transport intelligent life-forms to other planets compared to bots. We have bots past Pluto, but humans have only gone to the moon. Colonization is quicker and more efficient with automatons.
Further, isolated colonies of biological beings would be vulnerable to aggressive competing space bots because biological beings are more fragile (or at least harder to replace). After a nasty space war, bots may be almost all that's left. Protecting a large quantity of biological beings may be considered secondary to mere survival as a civilization under the hard realities of war.
It might be a little depressing, but better bot than dead.
The "last mile" should be a public utility, like land-lines used to be. The carrier (ISP) should then be relatively easily switchable per what individual customers want in order to finally give us real competition, instead of 2 actual (crappy) choices plus a 3rd fake choice that most places have now
It's not economically efficient (i.e. redundant) for each vendor to lay wires all the way to each house. Centralize the final wiring, but make the up-stream part easily toggle-able between vendors so that many vendors can enter the market without investing an arm and a leg. They'd only have to run (or rent) wiring to the switching stations/nodes, NOT to each house.
That's how Vulcan's would do it. Ferengi-like humans got us our current oligopoly mess. Only the airline industry has worse customer satisfaction ratings than the big telecoms. Comcast et al. are just shy of crying babies, lost luggage, no leg room, and long airport waits.
Yip, they really need to automate the slapping of PHB's if they want smoother software development.
Granted, PHB's are job security. CRUD and GUI idioms have been around long enough that they could largely be encoded into data dictionaries which could control about 90% or more of the rendering of typical applications.
But UI fads, stupid "standards", Microsoft's forced obsolescence, ego-based customization, customers/managers who don't want to bother to think things through, and other shit muck it up, causing us to reinvent the wheel gazillion different ways. You eventually realize how illogical humans are, but also realize their lack of logic is what gets you your paycheck.
Most of the cost of a working software product is maintenance, not original code creation. Something that automatically generates code better produce grokkable code, or else maintenance will be even more expensive.
It's hard to replace sunlight as an energy source. Volcanism is either going to be in limited spots, or causing mass damage. Any chemical metabolism couldn't last particularly long as it will eventually get "used up".
Good lasting energy typically comes from long-to-medium-wavelength radiation and/or temperature differentials.
If Donald Trump had any influence over my car at least it would have to be honest with me. That's better than I can get from any mechanic.
"You are about to be in a yuuuuuge smashup. It'll be really terrific; we really do the best smashups; beautiful multicolored sparks, smoke, and all you'd want in one."
The Copernican principle says we are more likely to be roughly average in space and time. This would imply that something in the future limits life. For example, it could be horrible terrorist weapons like self-reproducing nanobots that eat multi-cellular life.
Slashdot Mirror
Ext-JS is known to have a long learning curve, has cryptic or missing error messages (blank areas instead of messages), and is sluggish to load because of its fat libraries.
Middle-man layers create more busy work and more layers to change when requirements change. They are often a favorite for consultants who want to gold-plate the application/system to run up their charges.
Trivially? I don't think so. OO-RDB mappers are often considered a royal PITA. I suspect some will say "but they are doing it wrong". Again it's yet another case of OO domain modelling being hard to get right and hard to know if you are doing it right.
I have not seen any. Some mistake corrections for malice without giving a solid case that it's malice.
I will agree that "messaging" data is fairly common in science to exaggerate the intended conclusion because conclusion-free papers don't get much attention, but that works both ways. There's no reason why the vast majority of such fudging should be in the pro-change direction instead of the anti-change direction.
A tenured professor in a private university close to retirement has no financial incentive to fudge toward a pro-change conclusion: he/she already has their money and will be exiting from the work-force soon to enjoy their guaranteed retirement money.
If the bias claimers could show that those closer to retirement and/or have tenure are less likely to produce pro-change conclusions in the climate studies, then the bias-claimers would have a case. I haven't seen such. If funding source affects research results, then there should be a statistical relationship to be found. Go find it!
I wouldn't quite put it that way. Often a life-time of experience builds up "notions" of patterns. We don't remember every detail, but we do grow aggregate impressions similar to how artificial neural nets are trained over time even though the nets don't remember each specific training case.
For example, I've experienced the slime-ballery of big companies like Microsoft, the cable/telecoms (AT&T, Comcast), banks, etc. I've even worked for some to see the slime-ballery from the inside also.
All these experiences have built up a big distrust of big companies such that I take almost everything they say with a big grain of salt, including that massive deregulation is the magic to sparking the economy. (Further, the details of their dereg plans usually allow them to grow even bigger and buy up or sue away all their competition.)
I've also experienced the sluggishness of the public sector first hand. It is slow, but in general is not madly driven to rip you off. A monster who wants to nap does less damage than one who wants to eat you.
It's also true individuals don't remember every event equally and/or different events make stronger impressions than others. Our gray-matter neural nets respond differently to different stimuli. Emotion may indeed play a part in that as we respond emotionally differently to a given event.
Some may perceive being ripped off by a big co as a learning experience for the consumer instead of act of malice by the big co. The big co. is giving the consumer an education. The Trump-U "graduate" now can recognize spin because they have heavy personal experience of it. The "graduate" came away wiser; isn't that what education is about?
Every known politician is a spinner. Trump's and Cruz's politifact.com score is much worse than H's, by the way.
I don't believe it's possible for an honest politician to survive long, in large part because most voters are low-information voters.
By the way, why is it expected H to know that a given fact sent to her in a given email was classified? I have not heard a clear argument for "she should have known". In one case there was a "C." that indicates likely classified info (although the classified info itself was not in the body, just the marker), but what about the others? I'm not saying she's "off the hook", I just want to see a strong argument for "should have known." Comey's a known drama-king based on the iPhone back-door incident.
A keeper-of-classified-info-database clerk should be watching that, not the head honcho. The CEO's time is too valuable.
That's not quite a fair assessment of their stance. In general they believe that the profit motive applies to scientists as well as business-persons such that scientists will bias their results to get more money just like any salesperson would. You could argue they are projecting their own greed into scientists, but they can claim that human nature is human nature, and most humans are naturally greedy (which is the basis of capitalism's feedback mechanism).
You can argue specific climate facts, but they can always find a scientist (or a shill acting like a scientist) to poke holes in such facts.
It's true that the Earth is a complex system with lots of "moving parts" such that its climate is the aggregate result of jillions of factors.
You could point out that in most models, more CO2 warms the earth, and we know the CO2 increase is largely man-made due to the isotope signature.
But they may reply that not all models show CO2 warming the Earth and/or the temperature readings are rigged by those "greedy scientists" I mentioned above such that there is no excessive warming beyond the normal natural ebb and flow.
How does one prove scientists didn't rig temperature readings? There were no cameras following them 24/7. Ultimately it relies on trust, and if they believe scientists don't deserve our trust, there's not much one can do.
Unfortunately we may have to wait until their tushies bake off or their houses are under the sea until they get a clue. Reality is merely poking them right now, but they'll only notice it when it kicks them in the nuts/cunt.
Amen! Productivity (work-related) application programming (CRUD) using HTML/DOM/JS is a f8cking nightmare.
Part of the problem is that each browser brand/version combo can potentially render things differently such that you have to test on say 30+ combo's of browsers and devices to cover all bases, AND future versions may STILL break it after all those 30+ tests. My hair is turning Bernie Sanders shades over that crazy shit (and falling out like his). It makes the DLL-hell of the 90's feel better in comparison. Now we have render-hell.
Possible solutions include bringing back WYSIWYG and/or vector coordinates, OR doing the "auto-flow" rendering on the server and making the browser be a dumb coordinate-based vector plotter. That way you are dealing with only one renderer instead of 30+.
Another idea is to put X Window engines on browsers, but I'm skeptical of the input box response. Input boxes should (optionally) buffer on the client.
Other ideas welcomed.
Sure, you if you put a lot of bloated margins around everything you can make stuff "shift proof" in the web stack; but it looks ugly, wastes space, and is often not what the customers want.
Views only help on the output side, not the input side. If you split domain nouns up into bunches of little tables, then you often have to manage the updating of bunches of little tables. The input screens and/or update ordering may not match the table divisions. Even if they start out that way, they may grow apart over time.
I have to agree that over-normalizing tables creates difficult-to-use and slow systems in general. There are exceptions, but they are probably dumb luck rather than from genius high-level-normalization experts. And you don't know up-front which of these box of chocolates you are getting under high normalization: genius-split tables, dumb-luck-good tables, or PITA tables. I usually encounter the PITA ones.
I don't see how that necessarily improves things, but another problem with domain-modeling in OOP is that nobody agrees on how to do it "right". There are no solidly-proven set of unambiguous rules to partition domain objects. If you have them, write them down so I can verify they are unambiguous. In other words, OOP domain-modelling is too easy to get wrong because it's too hard to know if you are "doing it right".
If 98% of human resources processing is on "employees", then adding an extra "person" layer into it doesn't help. Maybe if HR tracks and processes contractors also (which they may not, per org), it might help, but perhaps it would be easier for contractors and employees to be independent objects/classes if they are usually treated differently: a top level just gets in the way because it may not contribute much of actual use.
Over-normalizing relational tables can create similar problems: too many joins and keys to keep track of without helping much. And it slows processing down.
It's hard to say without studying the domain and intended use of the software. Having a generic model of the world would have too much indirection (levels/layers/components) to be practical for IT.
Relational generally doesn't require one to hard-wire domain verbs to a given set of domain nouns. Operations are often multi-noun anyhow such that tying them to a single noun is often arbitrary (forced) in OO. The real world is better modeled as virtual coming together of nouns for a particular purpose at a time, rather than trying to make universal declarations about which verbs go with which nouns.
The business world is situational, and our software models should reflect that. Noun X working with Noun Y on Tuesday shouldn't have to care about Noun X working with Noun Z on Friday. Many-to-many relationships tend to get really ugly to manage in OOP such that one ends up turning the OOP app into an (ugly) database to track and manage it all. Might as well start with the database instead and stop trying to make an OO mirror for it: that's double work.
It turns out OOP can be a pretty good tool for name-space management in many cases, but it has stunk at domain modelling. Domain modelling is how OO was "sold" to us for roughly the last 2 decades, and this was a fat mistake that turned many prematurely gray.
An example of domain modelling would be a human resources app that models employees, managers, offices, etc. as objects. This mostly flopped.
But OOP works fairly well for making API's to network and system services (and arguably GUI's, but that's another subject).
We were doing it wrong.
Well, statistically, we kind of do.
We are more likely to be roughly in the middle of the universe's time-period, or at least in the middle of its population of intelligent existence-ponderers.
We can thus statistically surmise that intelligent life is NOT likely to proliferate. I wouldn't Vegas-bet that we are "simply early". Math says otherwise. Expansion is wishful thinking.
However, there are some interesting caveats. In the future intelligent life may be more Borg-like or bot-based such that there are a smaller quantity of "individuals" pondering their existence. Borg/bot units don't ponder such unless explicitly assigned such a task because it's not efficient for individuals to re-invent pondering done by others. Intelligent life may proliferate, just NOT as individuals, as we know them.
This "solves" Copernican principle by reducing the quantity of future ponders without having to also assume general intelligent life reduction.
We also know it's difficult to transport intelligent life-forms to other planets compared to bots. We have bots past Pluto, but humans have only gone to the moon. Colonization is quicker and more efficient with automatons.
Further, isolated colonies of biological beings would be vulnerable to aggressive competing space bots because biological beings are more fragile (or at least harder to replace). After a nasty space war, bots may be almost all that's left. Protecting a large quantity of biological beings may be considered secondary to mere survival as a civilization under the hard realities of war.
It might be a little depressing, but better bot than dead.
The "last mile" should be a public utility, like land-lines used to be. The carrier (ISP) should then be relatively easily switchable per what individual customers want in order to finally give us real competition, instead of 2 actual (crappy) choices plus a 3rd fake choice that most places have now
It's not economically efficient (i.e. redundant) for each vendor to lay wires all the way to each house. Centralize the final wiring, but make the up-stream part easily toggle-able between vendors so that many vendors can enter the market without investing an arm and a leg. They'd only have to run (or rent) wiring to the switching stations/nodes, NOT to each house.
That's how Vulcan's would do it. Ferengi-like humans got us our current oligopoly mess. Only the airline industry has worse customer satisfaction ratings than the big telecoms. Comcast et al. are just shy of crying babies, lost luggage, no leg room, and long airport waits.
Us Proxima Centaurians gave Earth email technology in order to confound her into submission.
I'm sure if we saw RNC's emails, "fun stuff" would happen to GOP also.
Good managers use the appropriate technique per employee. Unfortunately, good managers are hard to come by.
Yip, they really need to automate the slapping of PHB's if they want smoother software development.
Granted, PHB's are job security. CRUD and GUI idioms have been around long enough that they could largely be encoded into data dictionaries which could control about 90% or more of the rendering of typical applications.
But UI fads, stupid "standards", Microsoft's forced obsolescence, ego-based customization, customers/managers who don't want to bother to think things through, and other shit muck it up, causing us to reinvent the wheel gazillion different ways. You eventually realize how illogical humans are, but also realize their lack of logic is what gets you your paycheck.
Stay stupid, humans, I need the money.
Most of the cost of a working software product is maintenance, not original code creation. Something that automatically generates code better produce grokkable code, or else maintenance will be even more expensive.
They already sent a Mr. Trump to clear out the humans.
It's hard to replace sunlight as an energy source. Volcanism is either going to be in limited spots, or causing mass damage. Any chemical metabolism couldn't last particularly long as it will eventually get "used up".
Good lasting energy typically comes from long-to-medium-wavelength radiation and/or temperature differentials.
"You are about to be in a yuuuuuge smashup. It'll be really terrific; we really do the best smashups; beautiful multicolored sparks, smoke, and all you'd want in one."
We don't know how long it will last. Estimates vary widely. If expansion is accelerating, we could be in the mid-point now.
I'm a cockroach, you insensitive clod!
The current standing theory is the accelerating expansion of the universe will make matter unstable around very roughly 30 billion years from now.
The Copernican principle says we are more likely to be roughly average in space and time. This would imply that something in the future limits life. For example, it could be horrible terrorist weapons like self-reproducing nanobots that eat multi-cellular life.