Democrats lost a lot of representative seats in large part because "excess" gov't domestic snooping was big in the news at the time of elections. Now the administration is "not doing enough".
I looks like the country is now doing a flip-flop, just like I predicted, upon a big terror event.
Indeed. Lisp variants often rank high in Google searches, but are generally skipped for production applications.
"Hobby" languages can be fun to write in and talk about because you can play with powerful abstractions, but such is not always readable by average developers in the field, limiting their industry selection.
and risk bringing back killer bacteria we have no immunity for? We don't want to win the Galactic Darwin Award (although certain groups seem to be trying).
Plus, sending enough fuel to escape the Jupiter system's gravity is not going to be trivial.
Rather than a heavy multi-step risky crane landing system, why not spend the weight to juice up the in-orbit plume sniffer? If the moon pukes stuff toward the orbiter, then there is no need to land to sample it: sniff it while flying. Or, is there simply not enough material ejected to analyze well?
I should qualify that. I use MS-Paint for a large portion of many types of image fiddling, and then GIMP to add adjustments not available in Paint. I've picked up some Paint shortcuts and tricks over the years. One can make shadowed text with Paint, for example, even though it's not a "direct" feature. Sometimes I work on a higher res version, and then scale it down for web pages etc. so that edge artifacts don't show up.
Re: "to support and wade through even if you never change UI methods"
Change: "to support and wade through even if you never change UI frameworks or platforms"
Re: "For big projects, multiple viewing, searching, and grouping angles becomes more useful."
Change: "For big projects, multiple viewing, searching, and grouping angles becomes more valuable to help deal with the volume of (UI) code."
Re: "UI-related code doesn't necessarily have to "run" in the table, for compiled languages could have the IDE generate file-based code..."
Note that interpreted languages could optionally do an "eval()" function on code in tables. Or they can use the same technique mentioned for compiled languages, but it's an extra code preparation step. Or just store attributes in tables, not methods. But one may be able convert common method behavior into "action" attributes, such as opening a given screen in an "on-click" event.
A lot of GUI activity has reoccurring patterns that can be parameter-ized rather than rely on lots of explicit app code. That way more of the GUI activity is attributes instead of direct code, reducing the tricky issue of how to execute UI-related app code. I'd say at least 3/4 of GUI activity can be readily parameterized in such a way. It's just not the habit of GUI engine/API designers to think that way because they are writing for coders, not attribute "programmers".
(And added advantage of such a system is that it's less language-dependent. You do most GUI "coding" by setting attributes and action-lists having parameters, not using a specific app language.)
Regarding dynamic relational, generally each widget will have a fixed or common set of attributes, such as an ID, container ID/ref, title, default value, sequence or coordinates, widget type, etc., but also have a widget-type-specific set of attributes. Traditional RDMBS don't deal with these widget-specific attributes very well, and this may be why the idea hasn't really been tried. (Visual FoxPro did it to some extent, but mostly didn't expose it to the coder. OODBMS may use sub-classing for widget-specific stuff, but that creates other problems, especially if the differences are not clean "type" hierarchies.)
This partly demonstrates why "separation of content from presentation" is an overrated concept that often complicates designs by making unnecessary "busy work" layers.
How features are presented and grouped are largely interrelated to the function of the application itself. On different devices or gizmos one may design or group features entirely different. The UI is not just a "skin", it's an integral part of the overall product. It's what the users and customers see and largely what they judge you on, fair or not.
You can bend over backward to keep them separated, but then you create a bureaucratic bloated middle-man layer that you have to support and wade through even if you never change UI methods. It's expensive meteor insurance.
That being said, I'd like to see IDE's or similar that make it easy to change (virtual) groupings and filters of UI related code to fit the viewpoint of a given task.
I've kicked around the idea of a "table oriented GUI" where the code is stored, or at least managed, in a database. That way you can sort and group widget code by widget type, screen, title, change-date, property values, method names, etc. etc. -- all the powerful virtual grouping and filtering that database queries offer. For big projects, multiple viewing, searching, and grouping angles becomes more useful. It's what databases are for.
The traditional approach hard-wires one grouping aspect into linear code, making tasks not aligned to that grouping aspect more difficult.
Note the UI-related code doesn't necessarily have to "run" in the table, for compiled languages could have the IDE generate file-based code from the tables. The database would be a code management tool.
Some IDE's kind of do this, but they are essentially reinventing databases. Why reinvent something that already exists?
(One difficult part of this is that "dynamic relational" doesn't exist yet, and each widget kind has different attributes. Making a custom table for each widget gets unruly. Dynamic relational would allow columns to be dynamic. Name/value attribute-tables have to be used instead for traditional RDBMS.)
There are more journalism graduates per year than there are journalism jobs in the totality of the profession.
But journalists have skills that can be used in other areas, such as HR (interviews); research, such as marketing or competitive research; and business writing. Just because you don't get your target profession doesn't mean you can't use any of your major.
I've seen multiple studies showing that in the longer run a degree more than pays for itself on average, even liberal arts.
This seems like a contradiction to TFA. One possible theory to reconcile this is that it takes time to find or become ready for positions that use education.
The idea that you'll be doing more than just grunt work out of college is perhaps unrealistic. Employers want educated AND experienced employees. It takes a while to get sufficient experience.
Even if you start in grunt work, learn what you can around you, pick up tidbits, listen and learn in meetings, go out of your way to do extra, read the policy & procedure manuals, practice your people skills, understand how your little corner of the work-load affects the rest of the org. Clues are all over the place. Education doesn't end out of college.
Okay, I misunderstood your context. No hard feelings.
Note I didn't see where the article gave evidence that the listed projects were already successful. It seems more of a forecast, like a stock broker recommending what they feel will be growing stocks in the future.
And, some of them are kits and/or API's that others could use to build polished products with. That's probably the best hope.
And you are right that OSS doesn't necessarily mean "free" or "low cost". If you really want certain features or strong support, you will probably will have to pay for it. Otherwise, you are at the whims of other customers with money and/or other egos.
Paint.NET crashed my PC. I'm gun-shy to try it again.
However, I do agree that Gimp is overkill for a good many uses. I often use MS-Paint instead because it's less key/mouse-strokes. But Paint lacks gamma level, contrast, brightness, blur/sharp, save-quality-levels, and selected (cursor-controlled) blur/sharp/bright/darken. Add these, and Paint would satisfy 95% of my graphics needs. (I'm not a graphic artist, but do need to clean up and tweak photos and logos on occasion for web publish.)
I use to use Paint Shop Pro in the 90's. It was pretty good for simple stuff. Do they still have a free version?
Once you get into your 30's, you start to have family responsibilities and want to be paid what you're worth.
Your "worth" is less if you have a life. Corporations value de-facto slaves. It's why corporations like H1B's: they are stuck here, away from their regular home and family, with nothing else to do but work their asses off.
There's a reason corporations no longer value loyalty and shrank rewards for loyalty such as pensions and "experience" raises: they want you to leave after you get a family.
You also know that their buzz-word filled toy is a pile of crap, and they don't want to hear the truth: they like yes-men. Short-term-thinking PHB's want hit-and-run trophies.
Your best bet is often to go to work for companies that have already been burned by fads and cheesy outsourcers: they value wisdom.
All such opinions are subjective, until the point we can directly examine customer neurons in action, or at least have objective surveys. If my opinion is to be deleted because it's subjective, as you appear to request, then so should yours, and there would be no opinions nor objective info in existence either way. Nor does Slashdot preclude anecdotal and subjective evidence. It's not an academic research publication. Your complaint is baseless.
That being said, "corporate" software tends to have better UI's in my observation than most open-source projects and university projects.
I believe this is because a corporation MUST make the software somewhat usable or they die. In OSS and research projects, you have more room to fail, in terms of popularity of project.
Thus, corporate software generally ranges from C- to A in "usability", whereas the others can range from F to A. D's and F's are weeded out quickly in corporate land because the producers of such go bankrupt if they keep it up (or down).
Blender, Gimp, and Open Office Base (OOB) are examples of some OSS products which have/had horrid UI's, in my opinion.
Take OOB, for example. It took me forever to find the set-primary-key setting. I compared it to MS-Access, and although MS-Access's UI is messy, they gave at least 3 different ways to set (open) the primary-key setting tool. They probably did some user tests, and after learning users had a hard time finding the key setter, stuck it in multiple places. It's a messy work-around, but better than OOB's.
I don't believe universities are very good at delivering "finished" products. Those with their heads deep in the arcane theory and bits often forget or don't know how to think about how regular users interact with products. Good UI's and feature packaging is hard to get right.
But, creating new algorithms or code libraries for those outside with a better "product sense" is certainly something universities can and have done well.
I agree it may never be practical to send humans beyond Mars, but humans are not always practical.
For example, maybe one day a religious cult will save up for a multi-generational trek to nearby stars. After all, the Mormons once sold almost everything they had to trek to Utah to avoid (perceived) persecution and establish their idea of a better society.
You never know. The required resources for a Project Orion-style* ship(s) seem huge by today's standards, but in the future it may be within the reach of large private groups.
Microsoft plays too many games to "encourage" you to migrate. They may not outright pull the plug on legacy stuff, but they often make you jump through hoops to keep using older stuff. IBM seems to have gotten over trying that crap and realize if you run old stuff you are likely to keep buying IBM. MS sales is still caught in the upgrades=profits mode.
Okay, I was wrong about individual transistors. But I'm not sure those qualify as "integrated circuits". But let's not get into a terminology game, as space and military spending on IC technology was a big driver of IC R&D. I remember Intel stating that somewhere, but cannot currently find the source.
Making small circuits was more expensive than "medium" circuits at the time, like SLT, such that it was more economical for most commercial computers to use the "medium" circuits as they were cheaper and more plentiful than the smaller ones of the time, being the smaller ones were cutting edge with cutting edge problems to be worked out. Aerospace, on the other hand, paid a premium for reduced size. I imagine they had to throw away a lot of attempts to get one "good chip".
But hacking and radio jamming may limit what bot-jets can do in some cases. That's why multiple techniques and strategies are needed: one can defeat some of the plane types all of the time and all of the plane types some of the time, but not all of the plane types all of the time. (My apologies to Mr. Lincoln.)
And that approach may still be cheaper than the one-size-fits-all approach that the f35 tried and failed at.
Slashdot Mirror
Democrats lost a lot of representative seats in large part because "excess" gov't domestic snooping was big in the news at the time of elections. Now the administration is "not doing enough".
I looks like the country is now doing a flip-flop, just like I predicted, upon a big terror event.
Indeed. Lisp variants often rank high in Google searches, but are generally skipped for production applications.
"Hobby" languages can be fun to write in and talk about because you can play with powerful abstractions, but such is not always readable by average developers in the field, limiting their industry selection.
Such is called the "broken window" economic theory. It may generate employment, but not necessarily better living.
Paying MS to fix security problems is like paying chemical companies to clean up their own pollution.
and risk bringing back killer bacteria we have no immunity for? We don't want to win the Galactic Darwin Award (although certain groups seem to be trying).
Plus, sending enough fuel to escape the Jupiter system's gravity is not going to be trivial.
Rather than a heavy multi-step risky crane landing system, why not spend the weight to juice up the in-orbit plume sniffer? If the moon pukes stuff toward the orbiter, then there is no need to land to sample it: sniff it while flying. Or, is there simply not enough material ejected to analyze well?
I should qualify that. I use MS-Paint for a large portion of many types of image fiddling, and then GIMP to add adjustments not available in Paint. I've picked up some Paint shortcuts and tricks over the years. One can make shadowed text with Paint, for example, even though it's not a "direct" feature. Sometimes I work on a higher res version, and then scale it down for web pages etc. so that edge artifacts don't show up.
Clarifications and further details:
Re: "to support and wade through even if you never change UI methods"
Change: "to support and wade through even if you never change UI frameworks or platforms"
Re: "For big projects, multiple viewing, searching, and grouping angles becomes more useful."
Change: "For big projects, multiple viewing, searching, and grouping angles becomes more valuable to help deal with the volume of (UI) code."
Re: "UI-related code doesn't necessarily have to "run" in the table, for compiled languages could have the IDE generate file-based code..."
Note that interpreted languages could optionally do an "eval()" function on code in tables. Or they can use the same technique mentioned for compiled languages, but it's an extra code preparation step. Or just store attributes in tables, not methods. But one may be able convert common method behavior into "action" attributes, such as opening a given screen in an "on-click" event.
A lot of GUI activity has reoccurring patterns that can be parameter-ized rather than rely on lots of explicit app code. That way more of the GUI activity is attributes instead of direct code, reducing the tricky issue of how to execute UI-related app code. I'd say at least 3/4 of GUI activity can be readily parameterized in such a way. It's just not the habit of GUI engine/API designers to think that way because they are writing for coders, not attribute "programmers".
(And added advantage of such a system is that it's less language-dependent. You do most GUI "coding" by setting attributes and action-lists having parameters, not using a specific app language.)
Regarding dynamic relational, generally each widget will have a fixed or common set of attributes, such as an ID, container ID/ref, title, default value, sequence or coordinates, widget type, etc., but also have a widget-type-specific set of attributes. Traditional RDMBS don't deal with these widget-specific attributes very well, and this may be why the idea hasn't really been tried. (Visual FoxPro did it to some extent, but mostly didn't expose it to the coder. OODBMS may use sub-classing for widget-specific stuff, but that creates other problems, especially if the differences are not clean "type" hierarchies.)
This partly demonstrates why "separation of content from presentation" is an overrated concept that often complicates designs by making unnecessary "busy work" layers.
How features are presented and grouped are largely interrelated to the function of the application itself. On different devices or gizmos one may design or group features entirely different. The UI is not just a "skin", it's an integral part of the overall product. It's what the users and customers see and largely what they judge you on, fair or not.
You can bend over backward to keep them separated, but then you create a bureaucratic bloated middle-man layer that you have to support and wade through even if you never change UI methods. It's expensive meteor insurance.
That being said, I'd like to see IDE's or similar that make it easy to change (virtual) groupings and filters of UI related code to fit the viewpoint of a given task.
I've kicked around the idea of a "table oriented GUI" where the code is stored, or at least managed, in a database. That way you can sort and group widget code by widget type, screen, title, change-date, property values, method names, etc. etc. -- all the powerful virtual grouping and filtering that database queries offer. For big projects, multiple viewing, searching, and grouping angles becomes more useful. It's what databases are for.
The traditional approach hard-wires one grouping aspect into linear code, making tasks not aligned to that grouping aspect more difficult.
Note the UI-related code doesn't necessarily have to "run" in the table, for compiled languages could have the IDE generate file-based code from the tables. The database would be a code management tool.
Some IDE's kind of do this, but they are essentially reinventing databases. Why reinvent something that already exists?
(One difficult part of this is that "dynamic relational" doesn't exist yet, and each widget kind has different attributes. Making a custom table for each widget gets unruly. Dynamic relational would allow columns to be dynamic. Name/value attribute-tables have to be used instead for traditional RDBMS.)
But journalists have skills that can be used in other areas, such as HR (interviews); research, such as marketing or competitive research; and business writing. Just because you don't get your target profession doesn't mean you can't use any of your major.
A: Lobbyists
I've seen multiple studies showing that in the longer run a degree more than pays for itself on average, even liberal arts.
This seems like a contradiction to TFA. One possible theory to reconcile this is that it takes time to find or become ready for positions that use education.
The idea that you'll be doing more than just grunt work out of college is perhaps unrealistic. Employers want educated AND experienced employees. It takes a while to get sufficient experience.
Even if you start in grunt work, learn what you can around you, pick up tidbits, listen and learn in meetings, go out of your way to do extra, read the policy & procedure manuals, practice your people skills, understand how your little corner of the work-load affects the rest of the org. Clues are all over the place. Education doesn't end out of college.
Heavy "H" Heaping Hinders Helpful Headlines. Have Heart!
Okay, I misunderstood your context. No hard feelings.
Note I didn't see where the article gave evidence that the listed projects were already successful. It seems more of a forecast, like a stock broker recommending what they feel will be growing stocks in the future.
And, some of them are kits and/or API's that others could use to build polished products with. That's probably the best hope.
And you are right that OSS doesn't necessarily mean "free" or "low cost". If you really want certain features or strong support, you will probably will have to pay for it. Otherwise, you are at the whims of other customers with money and/or other egos.
Paint.NET crashed my PC. I'm gun-shy to try it again.
However, I do agree that Gimp is overkill for a good many uses. I often use MS-Paint instead because it's less key/mouse-strokes. But Paint lacks gamma level, contrast, brightness, blur/sharp, save-quality-levels, and selected (cursor-controlled) blur/sharp/bright/darken. Add these, and Paint would satisfy 95% of my graphics needs. (I'm not a graphic artist, but do need to clean up and tweak photos and logos on occasion for web publish.)
I use to use Paint Shop Pro in the 90's. It was pretty good for simple stuff. Do they still have a free version?
Its open-sorce grammer and spailing, whaddya expekt
Your "worth" is less if you have a life. Corporations value de-facto slaves. It's why corporations like H1B's: they are stuck here, away from their regular home and family, with nothing else to do but work their asses off.
There's a reason corporations no longer value loyalty and shrank rewards for loyalty such as pensions and "experience" raises: they want you to leave after you get a family.
You also know that their buzz-word filled toy is a pile of crap, and they don't want to hear the truth: they like yes-men. Short-term-thinking PHB's want hit-and-run trophies.
Your best bet is often to go to work for companies that have already been burned by fads and cheesy outsourcers: they value wisdom.
All such opinions are subjective, until the point we can directly examine customer neurons in action, or at least have objective surveys. If my opinion is to be deleted because it's subjective, as you appear to request, then so should yours, and there would be no opinions nor objective info in existence either way. Nor does Slashdot preclude anecdotal and subjective evidence. It's not an academic research publication. Your complaint is baseless.
That being said, "corporate" software tends to have better UI's in my observation than most open-source projects and university projects.
I believe this is because a corporation MUST make the software somewhat usable or they die. In OSS and research projects, you have more room to fail, in terms of popularity of project.
Thus, corporate software generally ranges from C- to A in "usability", whereas the others can range from F to A. D's and F's are weeded out quickly in corporate land because the producers of such go bankrupt if they keep it up (or down).
Blender, Gimp, and Open Office Base (OOB) are examples of some OSS products which have/had horrid UI's, in my opinion.
Take OOB, for example. It took me forever to find the set-primary-key setting. I compared it to MS-Access, and although MS-Access's UI is messy, they gave at least 3 different ways to set (open) the primary-key setting tool. They probably did some user tests, and after learning users had a hard time finding the key setter, stuck it in multiple places. It's a messy work-around, but better than OOB's.
I don't believe universities are very good at delivering "finished" products. Those with their heads deep in the arcane theory and bits often forget or don't know how to think about how regular users interact with products. Good UI's and feature packaging is hard to get right.
But, creating new algorithms or code libraries for those outside with a better "product sense" is certainly something universities can and have done well.
I agree it may never be practical to send humans beyond Mars, but humans are not always practical.
For example, maybe one day a religious cult will save up for a multi-generational trek to nearby stars. After all, the Mormons once sold almost everything they had to trek to Utah to avoid (perceived) persecution and establish their idea of a better society.
You never know. The required resources for a Project Orion-style* ship(s) seem huge by today's standards, but in the future it may be within the reach of large private groups.
* The original "Orion", not the capsule.
Microsoft plays too many games to "encourage" you to migrate. They may not outright pull the plug on legacy stuff, but they often make you jump through hoops to keep using older stuff. IBM seems to have gotten over trying that crap and realize if you run old stuff you are likely to keep buying IBM. MS sales is still caught in the upgrades=profits mode.
If you pay enough, you will "find" them. At least they exist. If you pick something obscure, even money may not be enough to bring them in.
Okay, I was wrong about individual transistors. But I'm not sure those qualify as "integrated circuits". But let's not get into a terminology game, as space and military spending on IC technology was a big driver of IC R&D. I remember Intel stating that somewhere, but cannot currently find the source.
Making small circuits was more expensive than "medium" circuits at the time, like SLT, such that it was more economical for most commercial computers to use the "medium" circuits as they were cheaper and more plentiful than the smaller ones of the time, being the smaller ones were cutting edge with cutting edge problems to be worked out. Aerospace, on the other hand, paid a premium for reduced size. I imagine they had to throw away a lot of attempts to get one "good chip".
But hacking and radio jamming may limit what bot-jets can do in some cases. That's why multiple techniques and strategies are needed: one can defeat some of the plane types all of the time and all of the plane types some of the time, but not all of the plane types all of the time. (My apologies to Mr. Lincoln.)
And that approach may still be cheaper than the one-size-fits-all approach that the f35 tried and failed at.
Then carry advanced decoys. If you don't have to design around stealth, then you have more room and power for such.