I don't know about veggie oil, but I'd consider it a great improvement if we could get our fuel from plants (probably genetically modified) that we grew in the US, Europe, China, India...basically anyplace other than the Middle East.
Burning such fuel would, of course, put CO2 into the atmosphere, but only the the CO2 that had been pulled out of the atmosphere to grow the plant to begin with.
But the best part would be making the Middle East less "strategic".
For newbies to Lisp, the parentheses don't vanish because of some mystical enlightenment. They vanish primarily because you've written your code according to a standard that specifies how it is to be indented. You parenthesize correctly when writing then simply ignore the parens when reading and look at the indentation level.
Of course I'm doing some handwaving here about the writing it correctly part. Until you memorize the major idioms, you'll often experience starting something with a single paren when it really needs to start with two, for example, and you'll get weird behavior that ends up driving you to randomly adding and removing parens until it seems to work. Admittedly that's a bit of a hurdle at first, but after some experience, that part gets easy. (Like glancing at for (int x=0; x10; x++) and reading "do it ten times" without having to think about it. A lot of people forget how much thinking a newbie has to do to parse such an expression the first few times.)
The real problem with Lisp isn't the parens. Once you get over the initial hurdle, you just look at the indentation. The problem is that dev platforms these days are so much more than just a language. The basic concepts underlying a Lispy language are almost timeless. The whole rest of the dev system, though, has a shelf life of about a decade or less, after which time the way it is made available, the libraries, the editors you have to use, the string model, the constraints it's optimized for, the compromises it has made, its interaction with other technologies, etc., are all out of touch with current realities. Such is Lisp today.
(Paul Graham once seemed like the guy who could rejuvenate Lisp, but each year that passes makes that less likely. Speaking of out of touch with current realities.... Even Microsoft's secret projects are more open.)
It's not really correct to state that AJAX is good for Internet or database (meaning network information) access apps. A better model is that AJAX is good for apps that DON'T require X, Y, or Z, for appropriate values of X,Y,Z.
Plain old executable client side apps written in C can access network information as well as any AJAX app. But they can also do anything else your client OS allows an app to do. You can have a full-featured, fully interactive user interface, local data storage, high performance, inter-app communication, etc., in addition to your network info access if you write your app in C (or some traditional equivalent.)
The only advantage an AJAX app has over a traditional app is in installation, which can be considered an almost instantaneous, just-in-time network install. ("Cross platform" is not an advantage since writing different code for different browsers, which we still have to do, is just like IFDEF'ing your C code for different OSes.)
I say installation is the only AJAX advantage, but it is a HUGE advantage, so much so that most app developers would love to have it. Well, they can have it with AJAX, but only only if their apps DON'T require X, Y, or Z.
What I'd like to hear from an AJAX expert is a list of what you CAN'T do well or *reliably* with an AJAX app--based on experience, not guesses. It seems that all of the successful AJAX apps I've seen have had UIs that were so simple that they were just marginally more than a static HTML page.
you will never get a country that thinks its a good idea to ahve its tax software open to all to see
Actually I think the government SHOULD provide open source tax software for some purposes. As a taxpayer, you should be able to download free tax preparation software from the government that comes with a guarantee: if you use it and answer each question it asks honestly, then the amount that it says you owe is the amount you DO owe. You wouldn't have to be personally responsible for keeping up with all changes in tax laws. The government would have to do it. The government would have no recourse to accuse you of underpayment other than accusing you of not honestly answering the questions.
The actual algorithms (source code) for calculating what you owe would be open for all to view. If those algorithms didn't match the legislation, you would have people pointing it out quickly. If the legislation was ambiguous in some way, the problems the government would have implementing it in source code would be taken back to the legislators with a requirement for disambiguation. People could submit changes to the app, but only the government would have the ability to commit changes.
You seem to be using unix and windows 3.1 as examples of "good" usability. I find that laughable.
I now think you have critical reading issues along with critical thinking problems. When I referred to Win3.1 and Unix using the right button to do a different random thing in every app, unlike the consistent context menu only usage that began with Win95, intelligent readers would have understood that "random", inconsistent usage was a *criticism* of Win3.1 and Unix. But not you.
For the record, those UIs were case studies in poor design.
Get back to me when you've tried a bunch of different interfaces...
"Tried a bunch of interfaces"? Let's start with the Mac. Going by your list, I started building commercial Mac apps before you even became a Mac user. I also *ran* a Mac tech support department. I was never more than arm's reach from my Inside Macintosh. I studied HCI with Terry Winograd at Stanford and have been involved with SIGCHI since the '80s. I was a cofounder of the International Mac Users Group at Stanford in the '80s as well as being a regular (and occasional presenter) at BMUG.
As if that weren't enough to absolutely pickle me in Apple UI theory, I spent a lot of time in the Claris usability lab.
But if bigger picture is what you want, though, I've written apps (not just "used" them) for mainframes, minis, Windows, *nix, DOS, Apple II, Mac, Palm, many of them commercial, commercial Web apps (I built an ecommerce site ten years ago), and code that I wrote is currently running on hundreds of millions of mobile phones in Asia. I've had to design UIs for command line, for mouse, and for "device button" interfaces.
Context menus are "power user" features which are not necessary and they do not add to usability....You are so bloody windows centric that you cannot see the big picture.
Yeah, right. So bloody Windows centric.
I know from years of experience in HCI that the context menu is not just a power user feature. It is widely used by vast numbers of ordinary users (at least an order of magnitude more people than all Mac users combined) as a way to explore the affordances of an app and to get relevant functionality to come to them when and where needed rather than forcing them to go hunting for it.
Those aren't old memories. [stroking my imaginary gray beard...] I forget how young Slashdotters tend to be.
I fondly remember using the ARPANet as a young defense contractor before they let all you riff-raff in and renamed it the "Internet". In those days, it wasn't all about porn, science fiction, and demanding rights to download hip hop for free. It was about particle physics, science fiction, and demanding the right to use MACSYMA for free. Well, okay, there was ASCII porn.
No, YOU just don't get it. Maybe you would if you reread what I'm responding to.
There is nothing wrong with offering a context menus as an alternative as long as you provide easy access to those functions from the main menu.
Exactly. Not only is there nothing wrong with it, it is a great plus for usability.
You seem to believe that someone here is proposing forcing users to use context menus as the only way to access functionality. Nobody is suggesting that. We're saying ALLOW users to access functionality via context menus, because it's a great way to work. Right clicking a "thing" and being immediately presented with a list of relevant operations that can be performed on that thing is a more direct approach than (left) clicking to select and then wondering which menus to go search in for functionality that may or may not be available.
The whole idea of the menu, as opposed to typing a command on a command line, was to inform users on a just in time basis of their options without requiring that they memorize lots of arcane details.
The context menu (not a right button that has whatever random functionality the app designer wants as in Win3.1 or Unix, but a right button that does just one consistent thing: "show me what I can to to this thing I'm clicking") is an improvement over basic menus. It doesn't tell you what you can do in general (or it shouldn't, as you stated). It tells you what you can do now to the thing you are clicking now.
There are plenty of context menus through out OS X and OS X apps. What you will notice is that all functionality in those context menus are also readily available through other means.
You really don't get it. Nobody is proposing designing apps so that context menus are the only way to access functionality. What we are complaining about is that there are NOT "plenty of context menus". Not even close. They are only "enough" to Mac users who don't use them.
On Windows, app designers assume two button mice and assume that legions of users will explore their app by right clicking various things to discover what can be done with them.
In contrast, on the Mac, app designers assume that most users will only be using the crippled Mac mouse, so they don't put much effort into creating useful context menus. A Windows user who is used to more direct access to functionality will want to explore the features of a Mac app by right clicking lots of things to see what can be done and waving his mouse cursor over things to see what tooltips pop up, and will discover that the UI is pretty uninformative compared to what he is used to (and this is a HUGE reversal from the state of the world in the early Mac vs. DOS or even Mac vs. Win3.1 days). Instead, he'll discover what Mac users assume everyone has to do--he'll have to dig around in the main menus to try to get a sense of the app, based on what's there and what's grayed out.
It took years for the Mac to adopt tooltips, presumably because Microsoft thought of them first and Apple has its pride. As a result, tooltips are usually less used on the Mac. In contrast, MS will gladly rip off (ahem, adopt) ANY idea that is popular with users. And the Mac clings to its crippled mouse, with the consequence that another great way for an app to show its users what to do--context menus--is at about the stage where Win95 was.
Back in the day, Mac apps (I miss you, Claris!!) ruled when it came to UI. But Apple needs to get used to the idea that great UI ideas come from everyone these days and that the market today is not the same as it was a generation ago.
Look at any study with "new" computer users and you will see that most of them have a lot of trouble adjusting to a "right click".
Now look at any study of what percentage of computer users these days are "new" users. Hint: 1984 was more than 20 years ago and there have been some MAJOR changes in computer user demographics since then. In the US, the average computer user is NOT still using his first computer, and his first computer more likely than not, had a two button mouse.
Granted, in markets such as India or China, most users are now new users, but Macs are nowhere to be found in those markets, and Macs are still using that canard about new users to justify their design in their major markets where only a small fraction of users are new to using a computer mouse.
Have you ever worked in technical support?
I don't know about him, but I used to *run* a tech support department. I whiled away many hours trying to teach old ladies how to double click a single-button Mac mouse...
do us all a favour and work as a web developer for a few years before you touch any desktop applications....And exactly where is the double click in a Web interface? It turned out that the best way to get an old lady to double click a Mac mouse was to get her to click (to select), go to the File menu, and choose "Open". That's for Mac tech support (and I've done plenty.) For Windows tech support, having them click the right mouse button, then choose "Open" (or some other option) was at least as easy.
That's just for the newbies, though. Over time, the percentage of our users who had to be walked through the process of double clicking declined (we kept stats on all issues that resulted in calls, thereby costing us money). It never disappeared, but crippling the interface for the average user to accommodate newbies makes less sense now than ever, and if you must do it, and your theory about Web usablility being the way to do all app usability, then when is the Mac going to eliminate double clicking?
I thought not. And now that a huge percentage of the population has spent years using computers with twin mouse buttons, having Macs crippled in this way just makes them annoying to use. (Again, as the other poster said, getting an external 2-button mouse isn't very useful when the OS & most apps are context menu deficient.)
I can't stand the Mac's crippled "maximize" behavior. I miss having a real maximize whenever I use a Mac. (I own Macs, Wintels, & Linuxen.) If I tell it I want full screen, I mean it. I don't mean, please waste twenty pixels or so around every edge. I want to see more of my work, not a bunch of strips of inert desktop. I always end up having to manually slide and stretch and slide some more and stretch some more...to get it FULL SCREEN. The Mac fights you every step of the way.
If you grab a Safari browser window on a Mac and manually force it to cover the whole screen, you get more of the Web page's contents displayed on screen than when using the Mac's crippled maximize. Of course, that's exactly what I want.
I don't oppose the idea of a "minimal window that still shows everything" operation for windows with very limited contents. But that's a "shrinkwrap" button, not a maximize button. If it were available, I'd use it sometimes. If the little button in the upper left has to be a shrinkwrap, then it should have a different icon, and maybe a doubleclick anywhere on the title bar should be the real maximize.
Come back to me when you've graduated and have >10 years under your belt.
Maybe he doesn't have that kind of experience, but I have more than twice that, and I think you have all the earmarks of a 15 yr old Slashdot troll, with the bragging, profanity, "hahaha" in place of argument, "I make X dollars/year" blather, posting as AC, etc.
Normally I wouldn't waste time on an adolescent troll, but I want to make sure something is clear. I was one of the architects involved in the creation of Dreamweaver, and it we designed it to be used by programmers, not just Web designers. Among other things, it was designed to be used just as BitTrollent is describing: as a code generator for GUI elements. Typically, you'll lay out a page, or some page element such as a form, graphically in the GUI view. Then you'll switch to the embedded code editor and tweak it. Then you can either use the code editor to embed inline code in a language like PHP, or "code behind" (as in ASP.Net, using VS as he described to write the C#), or do what I've done on occasion and copy the generated HTML into your source in some other language (e.g. a "HERE document" in Perl or a C++ header file, perhaps after running it thru a preprocessor to turn tokens into method calls or whatever).
A troll who can't understand that real programmers who create GUI apps sometimes start with a GUI layout and code generation tool--or even with a simple drawing program--doesn't really understand the process. If he really has ten years of experience himself, it must have been pretty narrow experience to be so unfamiliar with such a common form of development.
3. touchpad on the side of a laptop... 4. how about an integrated mouse in a laptop?...
Just get an IBM ThinkPad or Dell with a TrackPoint ("eraserhead") in the middle of the keyboard and three mouse buttons right under your thumbs (right below the space bar), then learn how to use it.
It works so well, I can't stand using a keyboard and standard mouse anymore. Command line bigots are always claiming that GUIs are bad because you have to move your hands back and forth between the keys and the mouse, but it's not the GUIs that are bad. It's the input device. I felt the same way until I got a machine that made mouse action just another quick keyboard function from the home keys.
You ask for a touchpad on the side of the laptop, presumably so you can take you hand (hands?) off the keyboard, scratch, scratch, scratch, at it, poke a button way off somewhere to click the "mouse", find your way back to the keys and get resituated for a half dozen keystrokes, move your hands away again to go scratch, scratch, scratch, etc....
My left thumb sits on the "left mouse button" at all times. Moving my index finger from the "J" key to the "mouse" (the eraserhead) is less motion than moving it to the "B" key. The eraserhead is set to the fastest motion with the lightest touch. Yes, that took a while to learn, and it pays off every day. Tiny, quick finger movements put the mouse pointer anywhere on screen and my fingers never leave the home keys.
And with a slight movement of my wrist, my right thumb slides off the spacebar and onto the "middle mouse button" while my index finger lands on the eraserhead. From there, tiny motions of my index finger scroll the window containing the mouse cursor and scrolls in two dimensions (i.e., vert, horiz, or diagonally).
Unfortunately, no such input option is available for a Mac laptop, and if you install Linux on a ThinkPad, you lose most of the TrackPoint functionality and reestablishing it is only partly successful after a great deal of research and fiddling.
The TrackPoint, like the command line itself, seems to be one of those innovations that are for people who use their computers a LOT and are willing to learn to use something that is initially more difficult for the increased payoff. It's not that such innovations are never created. It's that they tend to fade into obscurity, missed only by a few passionate cranks(CLI on a client device, TrackPoint, Lisp, great outliner programs,...)
Don't invent the field of cartography from scratch. Study it before you leave.
I don't know what "mapping" means in your case. Are you trying to show where each village is or are you trying to create street maps of the major towns? In any case, find out what maps already exist, then go get yourself the best satellite photos you can find, and when you get there, prepare to rent small aircraft for some aerial photography. Trying to map West Africa on foot from scratch with a pocket GPS device would be a fool's errand.
And be VERY CAREFUL. People who make maps are often considered spies by people who carry guns. You'd better be very sure you know what you are doing and have the necessary permission from whoever (official or unofficial) controls the guns in the region you are mapping.
The dereanged idea that it has to have meaning, relevance, etc., or it is worthless is ruining schools
While I imagine that you are probably supporting the (pretty good) idea that instilling a certain amount of discipline in students is good because of their limited vision of what is relevant, I still have to object to your statement.
Relevance is fundamental to attention, and attention is fundamental to learning. With so much more to learn and so little time, relevance is more important than ever as both a filter for curriculum developers and an incentive for students.
Others are suggesting answers to your scanning needs, and your mother may have already done this, but just in case:
The most important thing you can do with a pile of data is turn it into useful information. I know that's what you're trying to do. In the case of genealogical data, the most important is not just an electronic version of paper sources, but something built from those sources: an electronic family tree with facts (birth date/place, death date/place/cause, graduations, marriage date/place, immigration, military service, etc.) attached to each person and SOURCES attached to each fact, and all of it exported to GEDCOM format.
For each source, good software will let you include transcripts (not scans but transcribed excerpts that aren't too big) along with the bibliographic reference that tells others where they could find the information for themselves.
I probably have as much of this sort of data as you have, but most of it has been "processed" by extraction. That leaves the rest as backup that I seldom need to refer to. Since 99% of the information (by VALUE, not by bits) has been extracted into a very useful form, the rest is referred to so rarely that paper is just fine (as long as there is another copy stored elsewhere).
I'm not saying that having electronic copies of all of the original paper sources wouldn't be better. It would, but mostly for ease of backup. It's just that the most valuable thing to do (in my opinion) is the extraction and assembly of a really rich information structure (family tree, facts, sources, transcriptions of sections of sources) in a standard interchange format (GEDCOM).
After doing so, the additional value in having electronic, searchable copies of the original documents gets much smaller, so if I were you I'd make sure the information extraction project was done first before embarking on the scan/OCR/indexing project. After you do the former, you may decide that the latter isn't worth the effort.
Well, according to Walter, we still have a bit of a wait before it will be "1.0-worthy", but when it is it will be a HUGE improvement over working in C or C++ for those of us who (at least occasionally) need the benefits of C/C++ but are sick of gotcha-oriented programming.
Maybe this forum would gain a better prespective by educating themselves about Islam...and listen to what the majority moderates have to say on the situation.
Okay, fine. Since we're constantly told that there are more than a BILLION muslims, and you seem to want us to believe that the "majority moderates" (the majority of more than a billion is more than half a billion) oppose Bin Ladin, let's see what happens next.
We've seen how many people in the Muslim world will protest over reports of the desecration of a copy of the Koran, so let's see whether they are more or less outraged by Al Qaeda's intentional mass murder of civilians in the name of Islam and Allah.
If the "no murder of civilians in our name" protests look like they represent more than half a billion people, we've definitiely learned something, as you suggest.
However, if the "no murder of civilians in our name" protests don't come close to the scale of the "no desecration of our sacred book" protests, I think we'll see for ourselves (yet again) the real values and priorities of the majority of the Muslim world without need of instruction from you.
Pretty worthless consultant. I have ten years of experience with Java, having used it since it was an alpha version, and I wasn't alone in those days.
And most skilled developers with long experience do NOT have CS degrees, as most skilled artists don't have art degrees. Those of us from a physics background tend to bring more math skills to a job than those with CS degrees. Those with degrees in other domains are also frequently more valuable that CS degree holders, since most development tasks are more about the problem to be solved than about the computers.
There are certainly tasks where the computer is the domain--compiler writing or algorithmically challenging problems, for example--but the CS degree is just another domain specialty. Software is used for everything these days: medicine, art, music, genealogy, archaeology, astronomy, etc. It is ridiculous to assume that software development is exclusively a problem in the CS domain.
What I need from Apple is a Mac laptop with a built-in TrackPoint (eraserhead) with three buttons under the space bar, just like the IBM ThinkPads and Dell laptops have.
Using a laptop with one of these, after you get used to it, is so sweet that I don't have any desire to get an external mouse. It's so much nicer to leave your hands on the keys, especially when you really are holding it in your lap (at the airport, on the sofa, etc.)
I'd rather use a Mac, but it has to be a laptop, and until Apple makes a laptop with a TrackPoint, or allows a licensee to make one, I'll stay with my ThinkPad.
Do you mean you "scroll", as in what you do with scroll bars, or are you referring to moving the mouse pointer as scrolling?
On the ThinkPad, if you put your index finger on the eraser head and push a little, it moves the mouse pointer. If you drop your thumb onto the middle mouse button (right under the space bar) and then push the eraser head, the mouse pointer doesn't move. Instead, the contents of the window under the mouse pointer move. IOW, the window scrolls as if you were dragging a scrollbar.
If everyone used this input device, we could remove the scrollbars from windows because they'd be obsolete. All I have to do is shoot the mouse pointer somewhere into the window (anywhere inside) with a shot from my index finger, then drop my thumb and the next shot from my index finger scrolls the window contents--diagonally if I like--without moving the mouse pointer away from wherever I'm working in the middle of the window. So the mouse never leaves its work area and my hands never leave the keyboard.
In contrast, any system (e.g. Mac laptop) that makes me take my hand off the keyboard, go down to a trackpad and scratch at it until I get the mouse pointer properly positioned over a scrollbar, then scratch some more to scroll, then scratch some more to get my mouse pointer back to where it was so that I can continue working, is intolerable. And the normal response of the Mac lover, "buy an external mouse," isn't a solution.
That's too bad, because there is a lot to love about Macs.
And regarding the sensitivity of the eraserhead, if you use your computer a lot, you should turn it up to maximum, to where it flies around the screen with a light touch, and then practice until your touch gets light, quick, and accurate. It doesn't take long, even for someone with somewhat poorer than average manual dexterity like me. Of course, if you don't have the hardware, you're out of luck, and Mac laptops never have the hardware....
she now has a Mac with a trackpad input that uses a pen. She still complains about the lack of buttons. She has to keep putting the pen down and switching to the keyboard to type a command, then picking the pen up.
That's why I can't switch to a Mac. On my ThinkPad, I have three mouse buttons built in right under the space bar on the keyboard, and the "eraser head" mouse smack in the middle of the keyboard.
After using this setup, I can't stand using a "real" mouse or "keyboard only" or the crippled 1 button plus trackpad design of every Mac laptop. If they made Mac laptops with this input device, I'd switch.
This 3-button plus eraser head setup lets you use the mouse without ever moving your fingers off the keyboard, almost as if it were another key. And when you want to scroll, no more scroll bars. You just drop your thumb on the middle button and nudge the eraser head and the page the mouse pointer is hovering over scrolls in whatever direction you push, including diagonally.
As long as I'm using my ThinkPad, I never have to use a scrollbar and most text navigation shortcuts are irrelevant. I have the eraserhead set to maximum speed and sensitivity and I can jump around text like a hummingbird in any app without memorizing different key chords or shortcut sequences for every app. And since my hands never leave the keyboard, those few keyboard shortcuts that ARE still useful are always available to me.
But if I switch to a Mac, all of that goes out the Window. The Mac, with its "superior user interface" requires me to go off hunting around for scroll bars again every time I want to slide a window. Yes OF COURSE keyboard only is better than that, but there's an even better way than keyboard only--but only on certain PC laptops, not on any Mac.
Yes, I took calculus in a US high school, and that's how we did it, too, including the two-sided formula sheet.
I'd like to see a bit more emphasis placed on the type of mental math that was common among scientists and engineers in the mid-20th century. The ability to do quick "back of the envelope" calculations (rough estimates) using nothing more than your head and perhaps some scrap paper is one of the major differences between serious engineers then and now. They tended to be much better at it than we are because they had to be.
In most ways, we're much better off with cheap, ubiquitous machines to do our number crunching, but a lot of errors are made in "critical thinking" today that wouldn't have been made by engineers 50 years ago who tended to double check numerical claims in their heads by reflex.
Thus Windows developers have more trouble crossing over to Unix, than Unix developers have crossing to Windows.
This part is true, but your analysis is simplistic. The same type of people who love programming as kids and go for Linux today tended to do their personal projects on DOS/Windows a generation ago for reasons of affordability.
Many of them are very sophisticated developers today on a platform that has offered extensive professional opportunities and are every bit the equal of *nix developers.
While it is easier for Unix types to switch to Windows than the reverse, this is because the incompatibilities between Unix flavors encourage the use of "least common denominator" portable approaches that discourage ever getting too deep into any one platform. The Windows developer with years of deep Windows experience will be almost lost on Unix, where few of his tools exist, while the Unix developer with his bag of shallow, portable tools will be able to use many of his favorites on Windows. (Shallow in this sense means abstracting away any special features of the underlying OS.)
However, the Unix guy will be doing things like using ANSI C with std C libraries instead of VC++ with native Win32 APIs and libs, using "printf debugging" instead of the powerful VC debugging facilities, or even using something like Perl, which is optimized for Unix by design.
This kind of development is extremely superficial compared to what an experienced Windows developer is capable of.
I'm not trying to insult *nix developers. This is my approach, too, when I write software for the Mac these days. I said goodbye to "Inside Macintosh" a decade ago and switched to Perl, then Java, and now Python.
We often hear this "it's easier for Unix developers to use Windows than vice versa" argument used as if it were evidence of the superiority of *nix developers. While the "easier" statement is true, in my experience, it doesn't mean what a lot of *nix develpers think it means. It doesn't mean they're any better than Windows developers.
In fact, I don't see how someone who is a Perl developer (I am from time to time) has any grounds for dissing VB developers (which I've never been). I've done a lot of professional Windows work in VC++, but I've met some VB developers whose Windows knowledge put me to shame. I've been slowly backing away from Windows and doing more and more with *nix in the last few years, but *nixers who assume they are superior to VB developers are usually misinformed.
You have to be careful with the term "prove" here. In the normal scientific sense, Einstein and subsequent experimenters HAVE proven that time is not absolute. It's not that it "seems" to be non-absolute. It IS non-absolute.
If two atomic clocks are synchronized and not moved, or moved the same way, they stay in sync (to within a predictable error.) If one of them is then moved at a high speed and the two are brought back together, they are no longer in sync. Absolute time would require they stay in sync no matter how they moved (as long as they weren't damaged, of course).
Countless variations of this experiment, with all sorts of devices yield identical results. The extent of loss of synchrony is the same, regardless of the items being tested. The time is demonstrably, predictably a function of motion. Thus, absolute time has been disproven.
Einstein's theory explains the phenomenon so well that it is (so far) ENTIRELY predictable.
This doesn't mean, of course, that we couldn't discover some more complex version of relativity at some point in the future, but in a scientific sense, we've proven that time is not absolute, and it is not reasonable to claim, "no one knows crap about how nothing really works." The route dependency of time is VERY well understood and not at all mysterious. Just because it is counter to the intuitions we develop from daily life doesn't mean that we don't understand it. We can understand it and still be amazed by it.
Slashdot Mirror
I don't know about veggie oil, but I'd consider it a great improvement if we could get our fuel from plants (probably genetically modified) that we grew in the US, Europe, China, India...basically anyplace other than the Middle East.
Burning such fuel would, of course, put CO2 into the atmosphere, but only the the CO2 that had been pulled out of the atmosphere to grow the plant to begin with.
But the best part would be making the Middle East less "strategic".
For newbies to Lisp, the parentheses don't vanish because of some mystical enlightenment. They vanish primarily because you've written your code according to a standard that specifies how it is to be indented. You parenthesize correctly when writing then simply ignore the parens when reading and look at the indentation level.
Of course I'm doing some handwaving here about the writing it correctly part. Until you memorize the major idioms, you'll often experience starting something with a single paren when it really needs to start with two, for example, and you'll get weird behavior that ends up driving you to randomly adding and removing parens until it seems to work. Admittedly that's a bit of a hurdle at first, but after some experience, that part gets easy. (Like glancing at for (int x=0; x10; x++) and reading "do it ten times" without having to think about it. A lot of people forget how much thinking a newbie has to do to parse such an expression the first few times.)
The real problem with Lisp isn't the parens. Once you get over the initial hurdle, you just look at the indentation. The problem is that dev platforms these days are so much more than just a language. The basic concepts underlying a Lispy language are almost timeless. The whole rest of the dev system, though, has a shelf life of about a decade or less, after which time the way it is made available, the libraries, the editors you have to use, the string model, the constraints it's optimized for, the compromises it has made, its interaction with other technologies, etc., are all out of touch with current realities. Such is Lisp today.
(Paul Graham once seemed like the guy who could rejuvenate Lisp, but each year that passes makes that less likely. Speaking of out of touch with current realities.... Even Microsoft's secret projects are more open.)
It's not really correct to state that AJAX is good for Internet or database (meaning network information) access apps. A better model is that AJAX is good for apps that DON'T require X, Y, or Z, for appropriate values of X,Y,Z.
Plain old executable client side apps written in C can access network information as well as any AJAX app. But they can also do anything else your client OS allows an app to do. You can have a full-featured, fully interactive user interface, local data storage, high performance, inter-app communication, etc., in addition to your network info access if you write your app in C (or some traditional equivalent.)
The only advantage an AJAX app has over a traditional app is in installation, which can be considered an almost instantaneous, just-in-time network install. ("Cross platform" is not an advantage since writing different code for different browsers, which we still have to do, is just like IFDEF'ing your C code for different OSes.)
I say installation is the only AJAX advantage, but it is a HUGE advantage, so much so that most app developers would love to have it. Well, they can have it with AJAX, but only only if their apps DON'T require X, Y, or Z.
What I'd like to hear from an AJAX expert is a list of what you CAN'T do well or *reliably* with an AJAX app--based on experience, not guesses. It seems that all of the successful AJAX apps I've seen have had UIs that were so simple that they were just marginally more than a static HTML page.
you will never get a country that thinks its a good idea to ahve its tax software open to all to see
Actually I think the government SHOULD provide open source tax software for some purposes. As a taxpayer, you should be able to download free tax preparation software from the government that comes with a guarantee: if you use it and answer each question it asks honestly, then the amount that it says you owe is the amount you DO owe. You wouldn't have to be personally responsible for keeping up with all changes in tax laws. The government would have to do it. The government would have no recourse to accuse you of underpayment other than accusing you of not honestly answering the questions.
The actual algorithms (source code) for calculating what you owe would be open for all to view. If those algorithms didn't match the legislation, you would have people pointing it out quickly. If the legislation was ambiguous in some way, the problems the government would have implementing it in source code would be taken back to the legislators with a requirement for disambiguation. People could submit changes to the app, but only the government would have the ability to commit changes.
You seem to be using unix and windows 3.1 as examples of "good" usability. I find that laughable.
I now think you have critical reading issues along with critical thinking problems. When I referred to Win3.1 and Unix using the right button to do a different random thing in every app, unlike the consistent context menu only usage that began with Win95, intelligent readers would have understood that "random", inconsistent usage was a *criticism* of Win3.1 and Unix. But not you.
For the record, those UIs were case studies in poor design.
Get back to me when you've tried a bunch of different interfaces...
"Tried a bunch of interfaces"? Let's start with the Mac. Going by your list, I started building commercial Mac apps before you even became a Mac user. I also *ran* a Mac tech support department. I was never more than arm's reach from my Inside Macintosh. I studied HCI with Terry Winograd at Stanford and have been involved with SIGCHI since the '80s. I was a cofounder of the International Mac Users Group at Stanford in the '80s as well as being a regular (and occasional presenter) at BMUG.
As if that weren't enough to absolutely pickle me in Apple UI theory, I spent a lot of time in the Claris usability lab.
But if bigger picture is what you want, though, I've written apps (not just "used" them) for mainframes, minis, Windows, *nix, DOS, Apple II, Mac, Palm, many of them commercial, commercial Web apps (I built an ecommerce site ten years ago), and code that I wrote is currently running on hundreds of millions of mobile phones in Asia. I've had to design UIs for command line, for mouse, and for "device button" interfaces.
Context menus are "power user" features which are not necessary and they do not add to usability....You are so bloody windows centric that you cannot see the big picture.
Yeah, right. So bloody Windows centric.
I know from years of experience in HCI that the context menu is not just a power user feature. It is widely used by vast numbers of ordinary users (at least an order of magnitude more people than all Mac users combined) as a way to explore the affordances of an app and to get relevant functionality to come to them when and where needed rather than forcing them to go hunting for it.
Those aren't old memories. [stroking my imaginary gray beard...] I forget how young Slashdotters tend to be.
I fondly remember using the ARPANet as a young defense contractor before they let all you riff-raff in and renamed it the "Internet". In those days, it wasn't all about porn, science fiction, and demanding rights to download hip hop for free. It was about particle physics, science fiction, and demanding the right to use MACSYMA for free. Well, okay, there was ASCII porn.
Ah, those were the days....
No, YOU just don't get it. Maybe you would if you reread what I'm responding to.
There is nothing wrong with offering a context menus as an alternative as long as you provide easy access to those functions from the main menu.
Exactly. Not only is there nothing wrong with it, it is a great plus for usability.
You seem to believe that someone here is proposing forcing users to use context menus as the only way to access functionality. Nobody is suggesting that. We're saying ALLOW users to access functionality via context menus, because it's a great way to work. Right clicking a "thing" and being immediately presented with a list of relevant operations that can be performed on that thing is a more direct approach than (left) clicking to select and then wondering which menus to go search in for functionality that may or may not be available.
The whole idea of the menu, as opposed to typing a command on a command line, was to inform users on a just in time basis of their options without requiring that they memorize lots of arcane details.
The context menu (not a right button that has whatever random functionality the app designer wants as in Win3.1 or Unix, but a right button that does just one consistent thing: "show me what I can to to this thing I'm clicking") is an improvement over basic menus. It doesn't tell you what you can do in general (or it shouldn't, as you stated). It tells you what you can do now to the thing you are clicking now.
There are plenty of context menus through out OS X and OS X apps. What you will notice is that all functionality in those context menus are also readily available through other means.
You really don't get it. Nobody is proposing designing apps so that context menus are the only way to access functionality. What we are complaining about is that there are NOT "plenty of context menus". Not even close. They are only "enough" to Mac users who don't use them.
On Windows, app designers assume two button mice and assume that legions of users will explore their app by right clicking various things to discover what can be done with them.
In contrast, on the Mac, app designers assume that most users will only be using the crippled Mac mouse, so they don't put much effort into creating useful context menus. A Windows user who is used to more direct access to functionality will want to explore the features of a Mac app by right clicking lots of things to see what can be done and waving his mouse cursor over things to see what tooltips pop up, and will discover that the UI is pretty uninformative compared to what he is used to (and this is a HUGE reversal from the state of the world in the early Mac vs. DOS or even Mac vs. Win3.1 days). Instead, he'll discover what Mac users assume everyone has to do--he'll have to dig around in the main menus to try to get a sense of the app, based on what's there and what's grayed out.
It took years for the Mac to adopt tooltips, presumably because Microsoft thought of them first and Apple has its pride. As a result, tooltips are usually less used on the Mac. In contrast, MS will gladly rip off (ahem, adopt) ANY idea that is popular with users. And the Mac clings to its crippled mouse, with the consequence that another great way for an app to show its users what to do--context menus--is at about the stage where Win95 was.
Back in the day, Mac apps (I miss you, Claris!!) ruled when it came to UI. But Apple needs to get used to the idea that great UI ideas come from everyone these days and that the market today is not the same as it was a generation ago.
Look at any study with "new" computer users and you will see that most of them have a lot of trouble adjusting to a "right click".
...And exactly where is the double click in a Web interface? It turned out that the best way to get an old lady to double click a Mac mouse was to get her to click (to select), go to the File menu, and choose "Open". That's for Mac tech support (and I've done plenty.) For Windows tech support, having them click the right mouse button, then choose "Open" (or some other option) was at least as easy.
Now look at any study of what percentage of computer users these days are "new" users. Hint: 1984 was more than 20 years ago and there have been some MAJOR changes in computer user demographics since then. In the US, the average computer user is NOT still using his first computer, and his first computer more likely than not, had a two button mouse.
Granted, in markets such as India or China, most users are now new users, but Macs are nowhere to be found in those markets, and Macs are still using that canard about new users to justify their design in their major markets where only a small fraction of users are new to using a computer mouse.
Have you ever worked in technical support?
I don't know about him, but I used to *run* a tech support department. I whiled away many hours trying to teach old ladies how to double click a single-button Mac mouse...
do us all a favour and work as a web developer for a few years before you touch any desktop applications.
That's just for the newbies, though. Over time, the percentage of our users who had to be walked through the process of double clicking declined (we kept stats on all issues that resulted in calls, thereby costing us money). It never disappeared, but crippling the interface for the average user to accommodate newbies makes less sense now than ever, and if you must do it, and your theory about Web usablility being the way to do all app usability, then when is the Mac going to eliminate double clicking?
I thought not. And now that a huge percentage of the population has spent years using computers with twin mouse buttons, having Macs crippled in this way just makes them annoying to use. (Again, as the other poster said, getting an external 2-button mouse isn't very useful when the OS & most apps are context menu deficient.)
I can't stand the Mac's crippled "maximize" behavior. I miss having a real maximize whenever I use a Mac. (I own Macs, Wintels, & Linuxen.) If I tell it I want full screen, I mean it. I don't mean, please waste twenty pixels or so around every edge. I want to see more of my work, not a bunch of strips of inert desktop. I always end up having to manually slide and stretch and slide some more and stretch some more...to get it FULL SCREEN. The Mac fights you every step of the way.
If you grab a Safari browser window on a Mac and manually force it to cover the whole screen, you get more of the Web page's contents displayed on screen than when using the Mac's crippled maximize. Of course, that's exactly what I want.
I don't oppose the idea of a "minimal window that still shows everything" operation for windows with very limited contents. But that's a "shrinkwrap" button, not a maximize button. If it were available, I'd use it sometimes. If the little button in the upper left has to be a shrinkwrap, then it should have a different icon, and maybe a doubleclick anywhere on the title bar should be the real maximize.
Come back to me when you've graduated and have >10 years under your belt.
Maybe he doesn't have that kind of experience, but I have more than twice that, and I think you have all the earmarks of a 15 yr old Slashdot troll, with the bragging, profanity, "hahaha" in place of argument, "I make X dollars/year" blather, posting as AC, etc.
Normally I wouldn't waste time on an adolescent troll, but I want to make sure something is clear. I was one of the architects involved in the creation of Dreamweaver, and it we designed it to be used by programmers, not just Web designers. Among other things, it was designed to be used just as BitTrollent is describing: as a code generator for GUI elements. Typically, you'll lay out a page, or some page element such as a form, graphically in the GUI view. Then you'll switch to the embedded code editor and tweak it. Then you can either use the code editor to embed inline code in a language like PHP, or "code behind" (as in ASP.Net, using VS as he described to write the C#), or do what I've done on occasion and copy the generated HTML into your source in some other language (e.g. a "HERE document" in Perl or a C++ header file, perhaps after running it thru a preprocessor to turn tokens into method calls or whatever).
A troll who can't understand that real programmers who create GUI apps sometimes start with a GUI layout and code generation tool--or even with a simple drawing program--doesn't really understand the process. If he really has ten years of experience himself, it must have been pretty narrow experience to be so unfamiliar with such a common form of development.
3. touchpad on the side of a laptop...
...)
4. how about an integrated mouse in a laptop?...
Just get an IBM ThinkPad or Dell with a TrackPoint ("eraserhead") in the middle of the keyboard and three mouse buttons right under your thumbs (right below the space bar), then learn how to use it.
It works so well, I can't stand using a keyboard and standard mouse anymore. Command line bigots are always claiming that GUIs are bad because you have to move your hands back and forth between the keys and the mouse, but it's not the GUIs that are bad. It's the input device. I felt the same way until I got a machine that made mouse action just another quick keyboard function from the home keys.
You ask for a touchpad on the side of the laptop, presumably so you can take you hand (hands?) off the keyboard, scratch, scratch, scratch, at it, poke a button way off somewhere to click the "mouse", find your way back to the keys and get resituated for a half dozen keystrokes, move your hands away again to go scratch, scratch, scratch, etc....
My left thumb sits on the "left mouse button" at all times. Moving my index finger from the "J" key to the "mouse" (the eraserhead) is less motion than moving it to the "B" key. The eraserhead is set to the fastest motion with the lightest touch. Yes, that took a while to learn, and it pays off every day. Tiny, quick finger movements put the mouse pointer anywhere on screen and my fingers never leave the home keys.
And with a slight movement of my wrist, my right thumb slides off the spacebar and onto the "middle mouse button" while my index finger lands on the eraserhead. From there, tiny motions of my index finger scroll the window containing the mouse cursor and scrolls in two dimensions (i.e., vert, horiz, or diagonally).
Unfortunately, no such input option is available for a Mac laptop, and if you install Linux on a ThinkPad, you lose most of the TrackPoint functionality and reestablishing it is only partly successful after a great deal of research and fiddling.
The TrackPoint, like the command line itself, seems to be one of those innovations that are for people who use their computers a LOT and are willing to learn to use something that is initially more difficult for the increased payoff. It's not that such innovations are never created. It's that they tend to fade into obscurity, missed only by a few passionate cranks(CLI on a client device, TrackPoint, Lisp, great outliner programs,
All wearing headphones, seeing different things, hearing different things, and not speaking?
If this sounds appealing to you...seek help.
Clearly, you don't have children.
Don't invent the field of cartography from scratch. Study it before you leave.
I don't know what "mapping" means in your case. Are you trying to show where each village is or are you trying to create street maps of the major towns? In any case, find out what maps already exist, then go get yourself the best satellite photos you can find, and when you get there, prepare to rent small aircraft for some aerial photography. Trying to map West Africa on foot from scratch with a pocket GPS device would be a fool's errand.
And be VERY CAREFUL. People who make maps are often considered spies by people who carry guns. You'd better be very sure you know what you are doing and have the necessary permission from whoever (official or unofficial) controls the guns in the region you are mapping.
The dereanged idea that it has to have meaning, relevance, etc., or it is worthless is ruining schools
While I imagine that you are probably supporting the (pretty good) idea that instilling a certain amount of discipline in students is good because of their limited vision of what is relevant, I still have to object to your statement.
Relevance is fundamental to attention, and attention is fundamental to learning. With so much more to learn and so little time, relevance is more important than ever as both a filter for curriculum developers and an incentive for students.
Others are suggesting answers to your scanning needs, and your mother may have already done this, but just in case:
The most important thing you can do with a pile of data is turn it into useful information. I know that's what you're trying to do. In the case of genealogical data, the most important is not just an electronic version of paper sources, but something built from those sources: an electronic family tree with facts (birth date/place, death date/place/cause, graduations, marriage date/place, immigration, military service, etc.) attached to each person and SOURCES attached to each fact, and all of it exported to GEDCOM format.
For each source, good software will let you include transcripts (not scans but transcribed excerpts that aren't too big) along with the bibliographic reference that tells others where they could find the information for themselves.
I probably have as much of this sort of data as you have, but most of it has been "processed" by extraction. That leaves the rest as backup that I seldom need to refer to. Since 99% of the information (by VALUE, not by bits) has been extracted into a very useful form, the rest is referred to so rarely that paper is just fine (as long as there is another copy stored elsewhere).
I'm not saying that having electronic copies of all of the original paper sources wouldn't be better. It would, but mostly for ease of backup. It's just that the most valuable thing to do (in my opinion) is the extraction and assembly of a really rich information structure (family tree, facts, sources, transcriptions of sections of sources) in a standard interchange format (GEDCOM).
After doing so, the additional value in having electronic, searchable copies of the original documents gets much smaller, so if I were you I'd make sure the information extraction project was done first before embarking on the scan/OCR/indexing project. After you do the former, you may decide that the latter isn't worth the effort.
They'll probably start by scoring all the first posts....
Well, according to Walter, we still have a bit of a wait before it will be "1.0-worthy", but when it is it will be a HUGE improvement over working in C or C++ for those of us who (at least occasionally) need the benefits of C/C++ but are sick of gotcha-oriented programming.
Maybe this forum would gain a better prespective by educating themselves about Islam ...and listen to what the majority moderates have to say on the situation.
Okay, fine. Since we're constantly told that there are more than a BILLION muslims, and you seem to want us to believe that the "majority moderates" (the majority of more than a billion is more than half a billion) oppose Bin Ladin, let's see what happens next.
We've seen how many people in the Muslim world will protest over reports of the desecration of a copy of the Koran, so let's see whether they are more or less outraged by Al Qaeda's intentional mass murder of civilians in the name of Islam and Allah.
If the "no murder of civilians in our name" protests look like they represent more than half a billion people, we've definitiely learned something, as you suggest.
However, if the "no murder of civilians in our name" protests don't come close to the scale of the "no desecration of our sacred book" protests, I think we'll see for ourselves (yet again) the real values and priorities of the majority of the Muslim world without need of instruction from you.
Pretty worthless consultant. I have ten years of experience with Java, having used it since it was an alpha version, and I wasn't alone in those days.
And most skilled developers with long experience do NOT have CS degrees, as most skilled artists don't have art degrees. Those of us from a physics background tend to bring more math skills to a job than those with CS degrees. Those with degrees in other domains are also frequently more valuable that CS degree holders, since most development tasks are more about the problem to be solved than about the computers.
There are certainly tasks where the computer is the domain--compiler writing or algorithmically challenging problems, for example--but the CS degree is just another domain specialty. Software is used for everything these days: medicine, art, music, genealogy, archaeology, astronomy, etc. It is ridiculous to assume that software development is exclusively a problem in the CS domain.
What I need from Apple is a Mac laptop with a built-in TrackPoint (eraserhead) with three buttons under the space bar, just like the IBM ThinkPads and Dell laptops have.
Using a laptop with one of these, after you get used to it, is so sweet that I don't have any desire to get an external mouse. It's so much nicer to leave your hands on the keys, especially when you really are holding it in your lap (at the airport, on the sofa, etc.)
I'd rather use a Mac, but it has to be a laptop, and until Apple makes a laptop with a TrackPoint, or allows a licensee to make one, I'll stay with my ThinkPad.
Do you mean you "scroll", as in what you do with scroll bars, or are you referring to moving the mouse pointer as scrolling?
On the ThinkPad, if you put your index finger on the eraser head and push a little, it moves the mouse pointer. If you drop your thumb onto the middle mouse button (right under the space bar) and then push the eraser head, the mouse pointer doesn't move. Instead, the contents of the window under the mouse pointer move. IOW, the window scrolls as if you were dragging a scrollbar.
If everyone used this input device, we could remove the scrollbars from windows because they'd be obsolete. All I have to do is shoot the mouse pointer somewhere into the window (anywhere inside) with a shot from my index finger, then drop my thumb and the next shot from my index finger scrolls the window contents--diagonally if I like--without moving the mouse pointer away from wherever I'm working in the middle of the window. So the mouse never leaves its work area and my hands never leave the keyboard.
In contrast, any system (e.g. Mac laptop) that makes me take my hand off the keyboard, go down to a trackpad and scratch at it until I get the mouse pointer properly positioned over a scrollbar, then scratch some more to scroll, then scratch some more to get my mouse pointer back to where it was so that I can continue working, is intolerable. And the normal response of the Mac lover, "buy an external mouse," isn't a solution.
That's too bad, because there is a lot to love about Macs.
And regarding the sensitivity of the eraserhead, if you use your computer a lot, you should turn it up to maximum, to where it flies around the screen with a light touch, and then practice until your touch gets light, quick, and accurate. It doesn't take long, even for someone with somewhat poorer than average manual dexterity like me. Of course, if you don't have the hardware, you're out of luck, and Mac laptops never have the hardware....
she now has a Mac with a trackpad input that uses a pen. She still complains about the lack of buttons. She has to keep putting the pen down and switching to the keyboard to type a command, then picking the pen up.
That's why I can't switch to a Mac. On my ThinkPad, I have three mouse buttons built in right under the space bar on the keyboard, and the "eraser head" mouse smack in the middle of the keyboard.
After using this setup, I can't stand using a "real" mouse or "keyboard only" or the crippled 1 button plus trackpad design of every Mac laptop. If they made Mac laptops with this input device, I'd switch.
This 3-button plus eraser head setup lets you use the mouse without ever moving your fingers off the keyboard, almost as if it were another key. And when you want to scroll, no more scroll bars. You just drop your thumb on the middle button and nudge the eraser head and the page the mouse pointer is hovering over scrolls in whatever direction you push, including diagonally.
As long as I'm using my ThinkPad, I never have to use a scrollbar and most text navigation shortcuts are irrelevant. I have the eraserhead set to maximum speed and sensitivity and I can jump around text like a hummingbird in any app without memorizing different key chords or shortcut sequences for every app. And since my hands never leave the keyboard, those few keyboard shortcuts that ARE still useful are always available to me.
But if I switch to a Mac, all of that goes out the Window. The Mac, with its "superior user interface" requires me to go off hunting around for scroll bars again every time I want to slide a window. Yes OF COURSE keyboard only is better than that, but there's an even better way than keyboard only--but only on certain PC laptops, not on any Mac.
Yes, I took calculus in a US high school, and that's how we did it, too, including the two-sided formula sheet.
I'd like to see a bit more emphasis placed on the type of mental math that was common among scientists and engineers in the mid-20th century. The ability to do quick "back of the envelope" calculations (rough estimates) using nothing more than your head and perhaps some scrap paper is one of the major differences between serious engineers then and now. They tended to be much better at it than we are because they had to be.
In most ways, we're much better off with cheap, ubiquitous machines to do our number crunching, but a lot of errors are made in "critical thinking" today that wouldn't have been made by engineers 50 years ago who tended to double check numerical claims in their heads by reflex.
Thus Windows developers have more trouble crossing over to Unix, than Unix developers have crossing to Windows.
This part is true, but your analysis is simplistic. The same type of people who love programming as kids and go for Linux today tended to do their personal projects on DOS/Windows a generation ago for reasons of affordability.
Many of them are very sophisticated developers today on a platform that has offered extensive professional opportunities and are every bit the equal of *nix developers.
While it is easier for Unix types to switch to Windows than the reverse, this is because the incompatibilities between Unix flavors encourage the use of "least common denominator" portable approaches that discourage ever getting too deep into any one platform. The Windows developer with years of deep Windows experience will be almost lost on Unix, where few of his tools exist, while the Unix developer with his bag of shallow, portable tools will be able to use many of his favorites on Windows. (Shallow in this sense means abstracting away any special features of the underlying OS.)
However, the Unix guy will be doing things like using ANSI C with std C libraries instead of VC++ with native Win32 APIs and libs, using "printf debugging" instead of the powerful VC debugging facilities, or even using something like Perl, which is optimized for Unix by design.
This kind of development is extremely superficial compared to what an experienced Windows developer is capable of.
I'm not trying to insult *nix developers. This is my approach, too, when I write software for the Mac these days. I said goodbye to "Inside Macintosh" a decade ago and switched to Perl, then Java, and now Python.
We often hear this "it's easier for Unix developers to use Windows than vice versa" argument used as if it were evidence of the superiority of *nix developers. While the "easier" statement is true, in my experience, it doesn't mean what a lot of *nix develpers think it means. It doesn't mean they're any better than Windows developers.
In fact, I don't see how someone who is a Perl developer (I am from time to time) has any grounds for dissing VB developers (which I've never been). I've done a lot of professional Windows work in VC++, but I've met some VB developers whose Windows knowledge put me to shame. I've been slowly backing away from Windows and doing more and more with *nix in the last few years, but *nixers who assume they are superior to VB developers are usually misinformed.
You have to be careful with the term "prove" here. In the normal scientific sense, Einstein and subsequent experimenters HAVE proven that time is not absolute. It's not that it "seems" to be non-absolute. It IS non-absolute.
If two atomic clocks are synchronized and not moved, or moved the same way, they stay in sync (to within a predictable error.) If one of them is then moved at a high speed and the two are brought back together, they are no longer in sync. Absolute time would require they stay in sync no matter how they moved (as long as they weren't damaged, of course).
Countless variations of this experiment, with all sorts of devices yield identical results. The extent of loss of synchrony is the same, regardless of the items being tested. The time is demonstrably, predictably a function of motion. Thus, absolute time has been disproven.
Einstein's theory explains the phenomenon so well that it is (so far) ENTIRELY predictable.
This doesn't mean, of course, that we couldn't discover some more complex version of relativity at some point in the future, but in a scientific sense, we've proven that time is not absolute, and it is not reasonable to claim, "no one knows crap about how nothing really works." The route dependency of time is VERY well understood and not at all mysterious. Just because it is counter to the intuitions we develop from daily life doesn't mean that we don't understand it. We can understand it and still be amazed by it.