If there's no release date and price what is the purpose.
The purpose is science, so we know how things work and what we can do. Technology you can personally leverage comes later. ALWAYS. You think the transistors on the ICs, and the ICs themselves, sprung into being in the first microprocessor systems? No, they were lab critters and no more than that, well prior to the 4004 and successors. Crude, hacky looking things of no direct use to anyone. But now look at them.
I agree it's tantalizing to see and hear about such tech and not be able to use it, but this is the process, and there is no alternative that's obvious to me, nor apparently, anyone else.
Call me when a supercap has anything like the energy density - by any measure of cubic or weight - as a battery. Till then, they have only niche uses.
The thing is, there are many applications where space and weight aren't an issue, but lifetime and power sourcing are. For instance, I have lots of room -- going ten X on the space involved isn't a problem for me in any way, but it'd be awesome to have a reliable, high-power capable storage system to replace the batteries I'm using now, which (a) aren't going to last very long and (b) are severely limited by comparison in terms of the maximum current that can be drawn from them.
The real problem is just an engineering one: we need some standard systems to give us usable energy in standard ranges (12vdc and/or 120/240vac) from ultracap stacks. There's nothing hard about that, it's a market and demand issue, no more. Given the demand, designing the hardware is a doddle.
And of course it's worth noting that UC size is going down while power is going up. Most likely, at some point they will cross the battery line, and that's the time to buy stock in whatever UC company pulls it off.
Plus, instead of poisoning the environment with a dead battery, you can will your UCs to your kids.:)
The problem with skeuomorphism is that the familiarity is often misleading or at best limiting
"often" is not "always", and that destroys the argument against skeuomorphism without even requiring you to prove your assertion of "often." Sorry, but it's BS and it's been BS all along. Familiarity can be a great thing, a significant assist into the how and why of something. Radio dials. The play, pause, rewind, record, FF, and dub interface of tape machines. The phase display of a radio-teletype scope. The hands and dial of a clock. The zoom, focus and objective controls of a microscope. The doors and windows of a home in the context of an alarm system. And so on, for a *really* long time. Even switches, buttons, knobs, meters and indicators fall into this cleanly.
The answer to "when is skeuomorphism not appropriate" is "when it isn't, otherwise, it is." It's not "never."
For example a skeuomorphic address book would look like an actual book, but not really work like one. You can fold the corners of real pages down to act as bookmarks, then turn the book sideways to find them.
Both of those could easily be software features. Pfft.
You can't search a real book by entering search terms, so there has to be a non-skeuomorphic text entry box with a magnifying glass, a symbol that represents searching even though it is rarely used for that purpose.
A magnifying glass represents looking closer for details otherwise not visible, something it is always used for and a very nice symbol for searching. "Find a specific word in all these words"... now with a magnifying glass, "find a detail in all these details."
It's just a mess.
No. It's not a mess. Your objections, full of holes and very weak, remind me of an interior decorator holding his hands to his cheeks while complaining that the coffee pot doesn't match the drapes. You have shown you are not qualified to judge these things; users can manage just fine. Also, it's REALLY annoying to have all this time spent on an absolute non functional set of changes when actual UI fails persist like lack of nested folders, inability for one app to work with another apps files, etc. The former is a flat out stupidity, the latter a UI design error putting security over functionality at the user's deep expense. THAT is a mess. Flat objects instead of the UI we already knew? That was just dysfunctional and stupid. Also, the new UI is ugly. Which I suppose we should have seen coming, given the bewilderment that led to the whole design change.
Optimally designed? They went from a machine that could run eight monitors to one that can, as near as we can tell from the marketing materials, do three; one where all your hardware was safe in a strong case to one that's going to require desk-turds all over the place; one where the basic system is barely functional due to minimal storage on board, as compared to the previous incarnation which could carry multiple terabytes in various formats.
I waited a LONG time for a new Mac Pro, and now it looks like the previous generation was by far the best. Near as I can tell, the engineers were drunk when they came up with this weird new design. The idea of scattering more hardware all over my desk is a complete non-starter for several reasons, and the machine can't even do what the previous generation could. Pffft.
I'm not saying Apple's alone in this (that was someone else), I'm just pointing out how Objective C can relate to lock-in.
Certainly using any OS's unique APIs can bind you tightly to that specific OS.
However, there are also lots of APIs that are the same, or so similar that dealing with them generally doesn't lock you to anything. The standard C library, for instance, contains lots of useful stuff, most of which works as designed on all major platforms (Windows, OSX, linux), and you can often leverage that without any significant lock-in with the exercise of a little care. Some things -- like fork() -- you need to know where and how the differences affect you, but mostly there's a uniform set of tools.
In my case, I've found it absolutely worth my while to avoid vendor specific APIs as much as possible, and write my own stuff. Not only because then I can move it around (which I do... I write for multiple OS's, often within the context of a single project), but because unlike an OS vendor, when I find a bug, I fix it instead of sitting on it for months or years. So I have lots of graphics stuff, list handing code, memory allocation code, threading code, etc. that I use.
For instance, one recent project was a library that contained a suite of live, non-destructive image processing code for DSLRs. It was designed to leverage multiple cores and give the user control over various aspects of that. I leveraged POSIX threads instead of the OSX API for threading; works great, and runs on multiple platforms, which it would not have if I had stuck with the OSX Objective C API.
Then there's QT, which provides a uniform (if somewhat busted) API that hides the OS underneath, and gives you a pretty good degree of platform independence in doing so. Sadly, QT is just as prone to leaving serious bugs in versions and blundering forward without fixing them (ever) as are the major OS vendors. So again, building your own code instead of using the provided APIs can save you.
It's a matter of time on the one hand, and of craftsmanship on the other.
Well, to be fair, Objective C is one thing, however Apple's related APIs are quite something else, and do represent potential vendor lock-in, particularly if you are careless about using them.
Hardly even trying. Last reboot was probably a result of an upgrade from Apple. System crashes are so rare I can't even recall one. App crashes, yeah, sometimes, perhaps once every couple months or so. Depends on the app.
Any "computer art professor" that teaches which style is "superior", as opposed to "how to do" any style you are tasked to implement, isn't worth the time spent with them.
The issue of replicating physical interfaces is not, and never will be, cut and dry. Some physical interfaces are highly refined and functional, and abandoning them leads to problems (look at a modern audio system as compared to, for instance, a late 1970's Marantz. Now try to turn up the midrange, or route one recording input to a recording output, assuming your modern hardware even has them.)
There are some excellent UI design guidelines out there. Like, don't constantly show and hide interface elements, it fouls up muscle memory. But "bury everything in menus" is a total newbie suck move, and "remove all familiarity" (which is what the rabid anti sku folk are saying, really) is also a suck move.
I wrote my own in Python; uses PostgreSQL to hold the data, gives me unlimited stylesheet and substitution capabilities, generates HTML or whatever I want directly. Table of contents, indexes in various formats, footnotes, endnotes (references), chaptering and sub-sectioning, local and global variables, image handling and conversions, etc. Works a charm. And since I wrote it, I can add to it, fix it, etc.
When I want to typeset something crazy, I do it in an image manipulation system and then shovel the image in; that's about the only thing I've run into that would require more work than I'm willing to put in.
The most difficult thing *always* turns out to be programming to some API that the manufacturer says does X, but either really does Y, or simply crashes -- and then finding out that they're not going to fix it, except or unless in some later version of the OS, thereby doing all the current, stable customers out of whatever it was I was trying to accomplish. I mostly program for OSX these days, so my examples are all Apple-centric.
1) I was writing a POS application for a Chinese restaurant owned by friends. I had an old mini core 2 running 10.6.8 I wasn't using, and I wanted to make the app around this unit. So I spent a couple of days writing it, using UTF-8 for the Chinese parts, and everything was going swimmingly. I ordered some receipt printers (one for the counter, one for the kitchen to print orders, and one for the to-go/delivery table.) English? No problem. Everything worked. Put characters -- I mean actual Chinese -- in the file to be printed via CUPS, and the print process would crash. The problem? CPU-specific bug in a CUPS filter (Apple owns CUPS now.) They have no intention of fixing it in 10.6.8. They told me, "Upgrade the mini to Lion." So I ordered Lion on a stick and stuffed it in there, and the Lion installer informed me "CPU not supported. Core 2 duo or above required." So the fix is in, but I can't run the fix. So I ended up buying a new mini. Yeah, that "fixed" it. At a cost of $600. Thanks a whole f'ing lot, Apple.
2) Qt 4.x: Full of bugs. Fixes? Sure. In 5.x. But 5.x is full of new problems. I'll spare you the details, other than to point out that if they'd just bloody fix the stuff they claimed as working in the first place, rather than constantly surf forward and expect you to follow them, I'd a darn sight happier.
I feel that if the manufacturer says "here's an OS, and here are the features it offers you (API list, UI operations, etc.), then they are obligated (because I have invested time and/or money based on what they claimed) to make it happen. I accept that first out the door, there may be things that are not working right. What I don't accept as "ok" is this attitude that it's ok to leave it that way. You get a straight up bug report you can verify (print high UTF-8 characters crashes your printer filters) by Ada, you should fix the thing YESTERDAY. It's more important than your new OS, because it's about the reliability and honor and ethics of what you do. You don't fix it -- Apple -- and you go from respected vendor to the opposite (both lose respect and that much less likely to vend anything to me.)
Same thing goes for apps. You sell a paint program that is supposed to draw rects and circles, but won't draw circles, you bloody well need to FIX it so it DOES, and make sure that fix is available to every poor bastard who bought your paint program WITHOUT requiring them to change anything else.
It's NOT acceptable to say "You must upgrade to the next OS" or "That's fixed in the latest version, but that only runs on a 4 core CPU so you're screwed" When you say stuff like that, some people, somewhere, are getting red faced, ramping up blood pressure, and contemplating ways to deliver a clutch of rabid wolverines to your development team in a box marked "live strippers, schedule party immediately."
Related to that, I've learned to stay well clear of other people's frameworks and libraries. If I wrote it, I can almost certainly fix it. There's nothing more disheartening than writing in about a bug and hearing back that it's been upon some list, while your stuff remains broken, etc. Might as well have written it yourself anyway. Assuming you have time, of course.
Everybody's in such a damn rush to move forward, they're unwilling to see to it that current efforts are made to represent fine craftsmanship instead of a harried dash to ship at any cost in reliability and honor.
I've got a lot of older software because my reaction to "you gotta upgrade to get that fix" is "you're not getting more of my money until what you sold me in the first place works as you told me it would." I can't always stick to that rule, but I assure you, I try.
Well, gee, fella, we've only been at it for fifty(ish) years. Don't you think you're jumping the gun a little?
As opposed to the evolutionary process we think led to humans, which has run just a bit longer and has just a bit (I hope your sarcasm sensitivity didn't come from the shallow end of the gene pool) more complexity?
Nothing like moving the goalposts... to the next galaxy.
Personally, I think that expecting us to replicate human level complexity with the goal of intelligently making humans or human like things ought to at *least* wait until we understand our bodies and our minds. The human ability to write code is not sourced from the same principles as that of an evolutionary process. Even so, I'd like to see you outwit one.
you either misunderstand the science or the religion, because they are not in conflict.
Wishful thinking. When Galileo's presentation was found to be at odds with religion by the ultimate arbiter of such things (the then-Pope), they certainly were in conflict. The "apology" took centuries to come around, far too late to help Galileo. It wasn't a misunderstanding. It was stubborn clinging to myth and nonsense with the added salt of the power to enforce the myth over the facts.
When religion gives us social rules, there may be, often is in fact, value to be had. When religion tries to tell us how the world came to be and why we are here, it falls flat on its face, each and every time. It's the purest form of conflict: The intentional and irresponsible promulgation of fictions in the face of repeatable, consensual facts to the contrary. The more we understand, the more visible this is.
Re:Anti-science? See, now you have proof!
on
How Science Goes Wrong
·
· Score: 4, Insightful
Yes, laudable in concept. But I'd like to point out that you can't fix stupid, and trying invites heartbreak and consists of a massive waste of time. Also, you can't fix faith -- it strikingly resembles stupid in form, effect, and depth of infestation. And it's worse in one way: Being stupid is not politically correct. Exhibiting faith is. Woe is us.
This story is exactly why so many people do not believe the myth of evolution.
If you're a tech type (and I assume you are at least somewhat, or else wtf are you doing here), you can *easily* write software that uses, and proves, evolution.
Generate two lists of sets of random characteristics. Breed pairs of list items by selecting randomly between the characteristics contained in the items for a full set: AB, BA, AB, BA, etc. Now you have a new item with a new combination of characteristics. Assign each characteristic a weight: ability to find food, resistance to disease, etc. Create an environment that requires certain weights for survival. Test items against environment. Some will survive: return them to the list. They get to "breed" again. The others die. Each pass through the lists will vary the population in both count and characteristics.
A pass is a generation. After each generation, graph the characteristics. Guess what? That graph will rise until the fitness of all the items reaches a peak.
What you've done is created a situation where fitness is tested against stress, and higher fitness results in more survival. Subsequent generations will be more and more fit until they're all fit enough to survive.
Now add some randomness. Kill a few off just at random. These are "accidents." Make a few of the weaker ones survive anyway. These are cripples taken care of by the community, or otherwise lucky. Run the thing again. Guess what? Fitness of the population will rise again.
This is evolution in a fishbowl, and it's a very useful programming mechanism for anything where you can assign a "gene" to an approach to a problem, and "fitness" to the result of applying that approach. That's the practical side. On the fun side, you can (and I have done) write a great game where you have critters that breed, live and die using this mechanism.
Create a 2d grid. The genes are instructions, things like: "turn left if nextcell contains rock" "move forward" "turn left", "eat (fitness up)", "turn towards food" "turn away from food" "turn away from other critter" "breed" "if critter in next cell skip next gene" "if rock in next cell skip next gene" "knock heads (one critter dies)", etc. Each critter gets a list of these, randomized. Every move costs them fitness; eating gains it back. Seed the environment randomly with food and rocks and critters. Then run them by executing their genes in order. They will initially perform very poorly -- randomly. But as you breed them and the generations pass and the genes update from the highest fitness critters, you'll end up with critters that seek out food and then go breed, never running into a rock or another critter. Add animations to taste, be sure to graph fitness for the whole population, it's fascinating.
You can add complexity by adding recessive genes, more types of actions, more stuff in the environment, etc. There's really no end to what you can do. As a fun exercise, try to create a high performing critter manually, then throw it into the mix. Then at the end, when the fitness has maxed out, take a look at the highest fitness critter and see not only how little it resembles your well thought out choices, but what bizarre strategies it's implemented to be better than what you worked out. It can be mind blowing.
evolution: not only a fact, one well within your reach to test, verify without a shade of doubt, and use to your own benefit.
Once you've seen this work in practice, assuming you've got a decent head on your shoulders, you will immediately be able to generalize the process to nature and generations of real critters, from moths to humans to whatever. Strategies and capabilities against stressors, survival of the fittest, it's just the way it works, and there is ZERO doubt about it among those who actually understand it. Anyone who denies evolution is either ignorant of the facts or deliberately snowing you for some reason. 100% guaranteed. There are no other possibilitie
Well understood frameworks also have widely disseminated and well understood (by the very people you would prefer didn't) vulnerabilities, not to mention unfixed bugs that persist because they're in the framework, not in your code.
There are a lot of very good reasons to write your own code. The presumption that your own code is poor code, or that it isn't worth the time, makes assumptions not in evidence about every programmer who has done so.
Sometimes frameworks/libraries/etc are the way to fly, especially if they're not exposed to the end user. But sometimes, rolling your own is precisely the right solution.
Observe the basics: sanitize all input; build a library *of your own* that does this for all manner of data types, then send ALL input through it. This prevents a very large number of vulnerabilities, and, you can fix it if you miss something. After a while, you'll have a very solid thing you can count on and extend as required. Watch out for bloatware. Any library or similar that weighs in at many megabytes when compiled, or tens of them, is almost certainly written like shit. Working AI code might be the one possible exception. Not that I've seen any such thing.
Lots more, of course, experienced programmers generally know these things anyway.
ok, ITER isn't a production reactor. So it's not hooked to the grid, right? Not that pulses of 500 mw would be able to be utilized reasonably.
So -- what do they do with all that energy? Is there a huge bank of water cooled resistors nearby they dump the output into? Or what? There has to be a load of some kind, doesn't there?
Resolving all of this is trivial compared to the TRILLIONS of dollars wasted on the congressional and judicial stupidity that is the patriot act, the wars, and all the side effects. You're not looking at the big picture.
What would your policy prescription be after 9/11 and the anthrax attacks?
1) Armor the cockpit bulkheads. 2) create separate door for pilot entry. 3) no connection to passenger space. 4) only communication from passenger space is a large red button marked "pressing this button requests pilots to land at nearest medical facility."
That's it. No need to screw US civil rights or plane travel or write a PATRIOT act or anything. The PROBLEM was terrorists -- organized criminals -- using aircraft as directed kinetic energy weapons. That problem could have been 100% solved by the above.
As it was, we spent a huge amount of money and lost a huge number of US soldiers, and hosed travel and stomped on our own civil rights. Monumentally stupid. We should have spent that money making our infrastructure better, highways safer, healthcare better, etc. Instead, we used it to support the military industrial complex at ZERO benefit to ourselves (excepting the fat cats who own said MIC.)
WRT anthrax attacks -- normal legal procedures were sufficient for them too, although perhaps some automatic gear to detect bio and chem agents in the post and package services would have been appropriate. We'll always have wackos. It's not worthwhile to turn our country into a caricature of the soviets at their worst because someone, somewhere, has lost their marbles. Freedom comes with risk. You eliminate the risk, you've eliminated freedom. That shouldn't be acceptable to anyone but the purest cowards.
Until you've programmed ASM for a micro controller, you really don't know what's going on under the hood, and you're almost certainly doomed to create bloated, slow-as-mud compared to what it *could* be, code.
Sit down with a 6809 system emulation and learn about stacks and heaps and PIC and addressing modes and registers and memory and IO and optimizing loops and etc. Then you've got a foundation. Then C and a linker AND a debugger, then something OO, then HTML, CSS, Python, PostgreSQL, follow the basic PostgreSQL with detailed DB stuff, make sure the math is there through at least algebra and geometry, explain 3D from acos() as pooltable reflection to the various lighting tech... this would be a good first year or possibly two.
You best learn to solve problems by... wait for it... solving problems.
Certainly. Then, and only then, will measurement of volume and rate acquire meaning. In the interim, statements like:
Even if it isn't a new development,
...and...
could be destabilising parts of the Antarctic ice shelf immediately around them and speeding up melting
...are no more than alarmist bullshit.
Now, next year (and years), when they measure those streams, if the aggregate volume is up, I'll nod in agreement when someone says "this could be a result of warming." Even more meaningful, if the trend continues upwards, we have an actual indicator. But right now we have the equivalent of "hey, here's a traffic signal" with absolutely no indication of if it's red, green, or broken.
Slashdot Mirror
The purpose is science, so we know how things work and what we can do. Technology you can personally leverage comes later. ALWAYS. You think the transistors on the ICs, and the ICs themselves, sprung into being in the first microprocessor systems? No, they were lab critters and no more than that, well prior to the 4004 and successors. Crude, hacky looking things of no direct use to anyone. But now look at them.
I agree it's tantalizing to see and hear about such tech and not be able to use it, but this is the process, and there is no alternative that's obvious to me, nor apparently, anyone else.
The thing is, there are many applications where space and weight aren't an issue, but lifetime and power sourcing are. For instance, I have lots of room -- going ten X on the space involved isn't a problem for me in any way, but it'd be awesome to have a reliable, high-power capable storage system to replace the batteries I'm using now, which (a) aren't going to last very long and (b) are severely limited by comparison in terms of the maximum current that can be drawn from them.
The real problem is just an engineering one: we need some standard systems to give us usable energy in standard ranges (12vdc and/or 120/240vac) from ultracap stacks. There's nothing hard about that, it's a market and demand issue, no more. Given the demand, designing the hardware is a doddle.
And of course it's worth noting that UC size is going down while power is going up. Most likely, at some point they will cross the battery line, and that's the time to buy stock in whatever UC company pulls it off.
Plus, instead of poisoning the environment with a dead battery, you can will your UCs to your kids. :)
"often" is not "always", and that destroys the argument against skeuomorphism without even requiring you to prove your assertion of "often." Sorry, but it's BS and it's been BS all along. Familiarity can be a great thing, a significant assist into the how and why of something. Radio dials. The play, pause, rewind, record, FF, and dub interface of tape machines. The phase display of a radio-teletype scope. The hands and dial of a clock. The zoom, focus and objective controls of a microscope. The doors and windows of a home in the context of an alarm system. And so on, for a *really* long time. Even switches, buttons, knobs, meters and indicators fall into this cleanly.
The answer to "when is skeuomorphism not appropriate" is "when it isn't, otherwise, it is." It's not "never."
Both of those could easily be software features. Pfft.
A magnifying glass represents looking closer for details otherwise not visible, something it is always used for and a very nice symbol for searching. "Find a specific word in all these words"... now with a magnifying glass, "find a detail in all these details."
No. It's not a mess. Your objections, full of holes and very weak, remind me of an interior decorator holding his hands to his cheeks while complaining that the coffee pot doesn't match the drapes. You have shown you are not qualified to judge these things; users can manage just fine. Also, it's REALLY annoying to have all this time spent on an absolute non functional set of changes when actual UI fails persist like lack of nested folders, inability for one app to work with another apps files, etc. The former is a flat out stupidity, the latter a UI design error putting security over functionality at the user's deep expense. THAT is a mess. Flat objects instead of the UI we already knew? That was just dysfunctional and stupid. Also, the new UI is ugly. Which I suppose we should have seen coming, given the bewilderment that led to the whole design change.
Good engineers see to it that more transistors == more performance, so...
Moore's law is, in the final analysis, about performance.
Optimally designed? They went from a machine that could run eight monitors to one that can, as near as we can tell from the marketing materials, do three; one where all your hardware was safe in a strong case to one that's going to require desk-turds all over the place; one where the basic system is barely functional due to minimal storage on board, as compared to the previous incarnation which could carry multiple terabytes in various formats.
I waited a LONG time for a new Mac Pro, and now it looks like the previous generation was by far the best. Near as I can tell, the engineers were drunk when they came up with this weird new design. The idea of scattering more hardware all over my desk is a complete non-starter for several reasons, and the machine can't even do what the previous generation could. Pffft.
I'm not saying Apple's alone in this (that was someone else), I'm just pointing out how Objective C can relate to lock-in.
Certainly using any OS's unique APIs can bind you tightly to that specific OS.
However, there are also lots of APIs that are the same, or so similar that dealing with them generally doesn't lock you to anything. The standard C library, for instance, contains lots of useful stuff, most of which works as designed on all major platforms (Windows, OSX, linux), and you can often leverage that without any significant lock-in with the exercise of a little care. Some things -- like fork() -- you need to know where and how the differences affect you, but mostly there's a uniform set of tools.
In my case, I've found it absolutely worth my while to avoid vendor specific APIs as much as possible, and write my own stuff. Not only because then I can move it around (which I do... I write for multiple OS's, often within the context of a single project), but because unlike an OS vendor, when I find a bug, I fix it instead of sitting on it for months or years. So I have lots of graphics stuff, list handing code, memory allocation code, threading code, etc. that I use.
For instance, one recent project was a library that contained a suite of live, non-destructive image processing code for DSLRs. It was designed to leverage multiple cores and give the user control over various aspects of that. I leveraged POSIX threads instead of the OSX API for threading; works great, and runs on multiple platforms, which it would not have if I had stuck with the OSX Objective C API.
Then there's QT, which provides a uniform (if somewhat busted) API that hides the OS underneath, and gives you a pretty good degree of platform independence in doing so. Sadly, QT is just as prone to leaving serious bugs in versions and blundering forward without fixing them (ever) as are the major OS vendors. So again, building your own code instead of using the provided APIs can save you.
It's a matter of time on the one hand, and of craftsmanship on the other.
Well, to be fair, Objective C is one thing, however Apple's related APIs are quite something else, and do represent potential vendor lock-in, particularly if you are careless about using them.
From my OSX shell, result of "uptime":
22:14 up 29 days, 18:22, 4 users, load averages: 0.15 0.15 0.10
Hardly even trying. Last reboot was probably a result of an upgrade from Apple. System crashes are so rare I can't even recall one. App crashes, yeah, sometimes, perhaps once every couple months or so. Depends on the app.
Any "computer art professor" that teaches which style is "superior", as opposed to "how to do" any style you are tasked to implement, isn't worth the time spent with them.
The issue of replicating physical interfaces is not, and never will be, cut and dry. Some physical interfaces are highly refined and functional, and abandoning them leads to problems (look at a modern audio system as compared to, for instance, a late 1970's Marantz. Now try to turn up the midrange, or route one recording input to a recording output, assuming your modern hardware even has them.)
There are some excellent UI design guidelines out there. Like, don't constantly show and hide interface elements, it fouls up muscle memory. But "bury everything in menus" is a total newbie suck move, and "remove all familiarity" (which is what the rabid anti sku folk are saying, really) is also a suck move.
Change and so forth in moderation, see?
I wrote my own in Python; uses PostgreSQL to hold the data, gives me unlimited stylesheet and substitution capabilities, generates HTML or whatever I want directly. Table of contents, indexes in various formats, footnotes, endnotes (references), chaptering and sub-sectioning, local and global variables, image handling and conversions, etc. Works a charm. And since I wrote it, I can add to it, fix it, etc.
Here's an example of an output document:
SdrDx Manual
When I want to typeset something crazy, I do it in an image manipulation system and then shovel the image in; that's about the only thing I've run into that would require more work than I'm willing to put in.
I think you meant "fizzle."
I'm not talking about backwards compatibility. Read again, then, if you like, respond to what I actually SAID.
The most difficult thing *always* turns out to be programming to some API that the manufacturer says does X, but either really does Y, or simply crashes -- and then finding out that they're not going to fix it, except or unless in some later version of the OS, thereby doing all the current, stable customers out of whatever it was I was trying to accomplish. I mostly program for OSX these days, so my examples are all Apple-centric.
1) I was writing a POS application for a Chinese restaurant owned by friends. I had an old mini core 2 running 10.6.8 I wasn't using, and I wanted to make the app around this unit. So I spent a couple of days writing it, using UTF-8 for the Chinese parts, and everything was going swimmingly. I ordered some receipt printers (one for the counter, one for the kitchen to print orders, and one for the to-go/delivery table.) English? No problem. Everything worked. Put characters -- I mean actual Chinese -- in the file to be printed via CUPS, and the print process would crash. The problem? CPU-specific bug in a CUPS filter (Apple owns CUPS now.) They have no intention of fixing it in 10.6.8. They told me, "Upgrade the mini to Lion." So I ordered Lion on a stick and stuffed it in there, and the Lion installer informed me "CPU not supported. Core 2 duo or above required." So the fix is in, but I can't run the fix. So I ended up buying a new mini. Yeah, that "fixed" it. At a cost of $600. Thanks a whole f'ing lot, Apple.
2) Qt 4.x: Full of bugs. Fixes? Sure. In 5.x. But 5.x is full of new problems. I'll spare you the details, other than to point out that if they'd just bloody fix the stuff they claimed as working in the first place, rather than constantly surf forward and expect you to follow them, I'd a darn sight happier.
I feel that if the manufacturer says "here's an OS, and here are the features it offers you (API list, UI operations, etc.), then they are obligated (because I have invested time and/or money based on what they claimed) to make it happen. I accept that first out the door, there may be things that are not working right. What I don't accept as "ok" is this attitude that it's ok to leave it that way. You get a straight up bug report you can verify (print high UTF-8 characters crashes your printer filters) by Ada, you should fix the thing YESTERDAY. It's more important than your new OS, because it's about the reliability and honor and ethics of what you do. You don't fix it -- Apple -- and you go from respected vendor to the opposite (both lose respect and that much less likely to vend anything to me.)
Same thing goes for apps. You sell a paint program that is supposed to draw rects and circles, but won't draw circles, you bloody well need to FIX it so it DOES, and make sure that fix is available to every poor bastard who bought your paint program WITHOUT requiring them to change anything else.
It's NOT acceptable to say "You must upgrade to the next OS" or "That's fixed in the latest version, but that only runs on a 4 core CPU so you're screwed" When you say stuff like that, some people, somewhere, are getting red faced, ramping up blood pressure, and contemplating ways to deliver a clutch of rabid wolverines to your development team in a box marked "live strippers, schedule party immediately."
Related to that, I've learned to stay well clear of other people's frameworks and libraries. If I wrote it, I can almost certainly fix it. There's nothing more disheartening than writing in about a bug and hearing back that it's been upon some list, while your stuff remains broken, etc. Might as well have written it yourself anyway. Assuming you have time, of course.
Everybody's in such a damn rush to move forward, they're unwilling to see to it that current efforts are made to represent fine craftsmanship instead of a harried dash to ship at any cost in reliability and honor.
I've got a lot of older software because my reaction to "you gotta upgrade to get that fix" is "you're not getting more of my money until what you sold me in the first place works as you told me it would." I can't always stick to that rule, but I assure you, I try.
Well, gee, fella, we've only been at it for fifty(ish) years. Don't you think you're jumping the gun a little?
As opposed to the evolutionary process we think led to humans, which has run just a bit longer and has just a bit (I hope your sarcasm sensitivity didn't come from the shallow end of the gene pool) more complexity?
Nothing like moving the goalposts... to the next galaxy.
Personally, I think that expecting us to replicate human level complexity with the goal of intelligently making humans or human like things ought to at *least* wait until we understand our bodies and our minds. The human ability to write code is not sourced from the same principles as that of an evolutionary process. Even so, I'd like to see you outwit one.
Wishful thinking. When Galileo's presentation was found to be at odds with religion by the ultimate arbiter of such things (the then-Pope), they certainly were in conflict. The "apology" took centuries to come around, far too late to help Galileo. It wasn't a misunderstanding. It was stubborn clinging to myth and nonsense with the added salt of the power to enforce the myth over the facts.
When religion gives us social rules, there may be, often is in fact, value to be had. When religion tries to tell us how the world came to be and why we are here, it falls flat on its face, each and every time. It's the purest form of conflict: The intentional and irresponsible promulgation of fictions in the face of repeatable, consensual facts to the contrary. The more we understand, the more visible this is.
Yes, laudable in concept. But I'd like to point out that you can't fix stupid, and trying invites heartbreak and consists of a massive waste of time. Also, you can't fix faith -- it strikingly resembles stupid in form, effect, and depth of infestation. And it's worse in one way: Being stupid is not politically correct. Exhibiting faith is. Woe is us.
If you're a tech type (and I assume you are at least somewhat, or else wtf are you doing here), you can *easily* write software that uses, and proves, evolution.
Generate two lists of sets of random characteristics. Breed pairs of list items by selecting randomly between the characteristics contained in the items for a full set: AB, BA, AB, BA, etc. Now you have a new item with a new combination of characteristics. Assign each characteristic a weight: ability to find food, resistance to disease, etc. Create an environment that requires certain weights for survival. Test items against environment. Some will survive: return them to the list. They get to "breed" again. The others die. Each pass through the lists will vary the population in both count and characteristics.
A pass is a generation. After each generation, graph the characteristics. Guess what? That graph will rise until the fitness of all the items reaches a peak.
What you've done is created a situation where fitness is tested against stress, and higher fitness results in more survival. Subsequent generations will be more and more fit until they're all fit enough to survive.
Now add some randomness. Kill a few off just at random. These are "accidents." Make a few of the weaker ones survive anyway. These are cripples taken care of by the community, or otherwise lucky. Run the thing again. Guess what? Fitness of the population will rise again.
This is evolution in a fishbowl, and it's a very useful programming mechanism for anything where you can assign a "gene" to an approach to a problem, and "fitness" to the result of applying that approach. That's the practical side. On the fun side, you can (and I have done) write a great game where you have critters that breed, live and die using this mechanism.
Create a 2d grid. The genes are instructions, things like: "turn left if nextcell contains rock" "move forward" "turn left", "eat (fitness up)", "turn towards food" "turn away from food" "turn away from other critter" "breed" "if critter in next cell skip next gene" "if rock in next cell skip next gene" "knock heads (one critter dies)", etc. Each critter gets a list of these, randomized. Every move costs them fitness; eating gains it back. Seed the environment randomly with food and rocks and critters. Then run them by executing their genes in order. They will initially perform very poorly -- randomly. But as you breed them and the generations pass and the genes update from the highest fitness critters, you'll end up with critters that seek out food and then go breed, never running into a rock or another critter. Add animations to taste, be sure to graph fitness for the whole population, it's fascinating.
You can add complexity by adding recessive genes, more types of actions, more stuff in the environment, etc. There's really no end to what you can do. As a fun exercise, try to create a high performing critter manually, then throw it into the mix. Then at the end, when the fitness has maxed out, take a look at the highest fitness critter and see not only how little it resembles your well thought out choices, but what bizarre strategies it's implemented to be better than what you worked out. It can be mind blowing.
evolution: not only a fact, one well within your reach to test, verify without a shade of doubt, and use to your own benefit.
Once you've seen this work in practice, assuming you've got a decent head on your shoulders, you will immediately be able to generalize the process to nature and generations of real critters, from moths to humans to whatever. Strategies and capabilities against stressors, survival of the fittest, it's just the way it works, and there is ZERO doubt about it among those who actually understand it. Anyone who denies evolution is either ignorant of the facts or deliberately snowing you for some reason. 100% guaranteed. There are no other possibilitie
I'm Jonnie cab!
Well understood frameworks also have widely disseminated and well understood (by the very people you would prefer didn't) vulnerabilities, not to mention unfixed bugs that persist because they're in the framework, not in your code.
There are a lot of very good reasons to write your own code. The presumption that your own code is poor code, or that it isn't worth the time, makes assumptions not in evidence about every programmer who has done so.
Sometimes frameworks/libraries/etc are the way to fly, especially if they're not exposed to the end user. But sometimes, rolling your own is precisely the right solution.
Observe the basics: sanitize all input; build a library *of your own* that does this for all manner of data types, then send ALL input through it. This prevents a very large number of vulnerabilities, and, you can fix it if you miss something. After a while, you'll have a very solid thing you can count on and extend as required. Watch out for bloatware. Any library or similar that weighs in at many megabytes when compiled, or tens of them, is almost certainly written like shit. Working AI code might be the one possible exception. Not that I've seen any such thing.
Lots more, of course, experienced programmers generally know these things anyway.
ok, ITER isn't a production reactor. So it's not hooked to the grid, right? Not that pulses of 500 mw would be able to be utilized reasonably.
So -- what do they do with all that energy? Is there a huge bank of water cooled resistors nearby they dump the output into? Or what? There has to be a load of some kind, doesn't there?
Any ITER experts know?
Resolving all of this is trivial compared to the TRILLIONS of dollars wasted on the congressional and judicial stupidity that is the patriot act, the wars, and all the side effects. You're not looking at the big picture.
1) Armor the cockpit bulkheads. 2) create separate door for pilot entry. 3) no connection to passenger space. 4) only communication from passenger space is a large red button marked "pressing this button requests pilots to land at nearest medical facility."
That's it. No need to screw US civil rights or plane travel or write a PATRIOT act or anything. The PROBLEM was terrorists -- organized criminals -- using aircraft as directed kinetic energy weapons. That problem could have been 100% solved by the above.
As it was, we spent a huge amount of money and lost a huge number of US soldiers, and hosed travel and stomped on our own civil rights. Monumentally stupid. We should have spent that money making our infrastructure better, highways safer, healthcare better, etc. Instead, we used it to support the military industrial complex at ZERO benefit to ourselves (excepting the fat cats who own said MIC.)
WRT anthrax attacks -- normal legal procedures were sufficient for them too, although perhaps some automatic gear to detect bio and chem agents in the post and package services would have been appropriate. We'll always have wackos. It's not worthwhile to turn our country into a caricature of the soviets at their worst because someone, somewhere, has lost their marbles. Freedom comes with risk. You eliminate the risk, you've eliminated freedom. That shouldn't be acceptable to anyone but the purest cowards.
Yes. Government(s). That's what we're saying.
Until you've programmed ASM for a micro controller, you really don't know what's going on under the hood, and you're almost certainly doomed to create bloated, slow-as-mud compared to what it *could* be, code.
Sit down with a 6809 system emulation and learn about stacks and heaps and PIC and addressing modes and registers and memory and IO and optimizing loops and etc. Then you've got a foundation. Then C and a linker AND a debugger, then something OO, then HTML, CSS, Python, PostgreSQL, follow the basic PostgreSQL with detailed DB stuff, make sure the math is there through at least algebra and geometry, explain 3D from acos() as pooltable reflection to the various lighting tech... this would be a good first year or possibly two.
You best learn to solve problems by... wait for it... solving problems.
Certainly. Then, and only then, will measurement of volume and rate acquire meaning. In the interim, statements like:
Now, next year (and years), when they measure those streams, if the aggregate volume is up, I'll nod in agreement when someone says "this could be a result of warming." Even more meaningful, if the trend continues upwards, we have an actual indicator. But right now we have the equivalent of "hey, here's a traffic signal" with absolutely no indication of if it's red, green, or broken.