At least they don't commit the inverse problem, where a single word is blindly assumed to be a search term just because it doesn't contain a dot or slash.

Chrome, Safari and IE all commit that UX sin, which is really annoying when you're trying to go to an internal LAN web server by name.

Chrome and IE let you hack around this by appending a slash (e.g. "myserver/") but Safari doesn't. You end up creating bookmarks purely to avoid having to type the FQDN or explicitly prepend "http://"

FORTRAN wasn't the language in 1964 that you think of as FORTRAN today.

Most people's concept of FORTRAN is FORTRAN 77 or its descendants, which was 13 years in the future from BASIC's introduction.

At the time of BASIC's introduction, FORTRAN IV was the current version.

FORTRAN wouldn't be ANSI-fied for another two years as FORTRAN 66, so every version had machine-specific features. Also, because FORTRAN's development was largely driven by IBM until FORTRAN 66, all the non-IBM versions were "nonstandard." Imagine if, today, every computer came with a C compiler and there were no ANSI or ISO standard to constrain its behavior. The last common reference would have been K&R '78.

Another fun feature of early FORTRAN was fixed column layout, common among languages invented in the punched card era. That is, you had to do things like start all statements in column 7 or later, because the first 6 columns had other meaning.

Early FORTRANs also had very primitive program structuring concepts, hardly raised from the level of assembly language.

Read through the Wikipedia article. You'll probably be shocked at how primitive FORTRAN was in the early 1960s.

Are you aware of even one substantial program that builds without changes under both Ocaml and F#? I'm not.

F# is a "port" of Ocaml in about the same sort of way as C# is a port of Java.

Familial resemblance, yes. Compatibility, definitely not. And as with C# and Java, the gap widens year by year.

IMHO, F# is a vast improvement on Ocaml.

F# and Ocaml are pretty different, actually. They share about as much familial resemblance as C# and Java, or C++ and Objective C:

- The default "light" syntax in F# does away with most of the semicolons and other noise required in Ocaml

- The OO facilities are entirely incompatible

- The standard libraries are almost entirely different; there's only a tiny bit of overlap

- The mere fact of F# being a .NET language has many practical effects on the language, down to strange implementation details like what it means to rotate an 8-bit integer right by 8. F# and Ocaml do not do the same thing! F# differs because it behaves like C#, whereas Ocaml behaves like C in this regard.

- Ocaml has separate operators for integer vs floating point arithmetic; F# overloads the traditional set, though like Ocaml, F# won't let you implicitly mix integer and FP arithmetic

I could go on, but suffice to say, knowing one only gives you a bit of a leg up on learning the other.

It typically takes about 60% of the number of code lines to accomplish something in F# as with C#.

Don't take it from me. Go to the MSDN library page for any given .NET API, scroll down to the Examples, and compare the F# and C# versions. (Not all pages have F# equivalents for the C# examples, but an impressive number do.)

It's no mystery why that is so. F# is highly expressive and doesn't require much boilerplate.

You can mix an F# library into a C# "solution" (urp), so the next time you need a new class or module in a .NET project, I challenge you to write it in F#. You might just get hooked. If not, learning an FP language changes how you think about software, in a good way, even if you never use a pure FP language again.

I also find that correct F# code is more obviously correct than equally correct C# code. It just seems to snap into focus at some point. This might be due to the mathematical rigor of pure FP, or it might just be another benefit of its expressive syntax.

Not much chance of that. F# just hit #12 on the Tiobe Index, up from #69 this time last year:

http://www.tiobe.com/index.php...

...and StackExchange.

The Express editions have a bunch of arbitrary limitations in them.

The two that bit me were:

1. You can't install plugins. I don't currently use any I can't live without, but several features in VS2013 -- e.g. NuGET, the thumbnail view replacing the scroll bar, better refactoring, visual indent level indication -- started out as plugins. Even if you take the view that eventually, all third-party plugin features eventually make it into the retail version, you're opting into being years behind the current state of the art.

2. The Express editions are artificially siloed into several versions, none of which has all of the features. If you need two features that are in different versions, at best you have to keep bouncing between the editions. If you need both features simultaneously, you're stuffed.

For me, the two features I needed simultaneously were the ability to create a mixed C# and F# program that ran on the desktop. To make a C# desktop app, you naturally need the desktop edition, but that edition doesn't include any F# support. For some demented reason, that's off in the Web edition, where it seems focused on ASP.NET development, not desktop development.

(And if you ask me why F#, well, this is Slashdot, isn't it? If I'd said Haskell instead, you'd just be nodding now. :) )

Take a look at Forks::Super. It's still a bit on the beta side, but useful enough for you to get real work done while you bang on the author to fix the remaining bugs. :)

I might have some sympathy with your position if I hadn't seen a technically savvy person like yourself bitten just a few months ago by the belief that RAID is a backup.

Did he get a virus? No.

Did he delete some file he had no other backup of? Nope, guess again.

Did a hard drive fail? No again. All four drives in the RAID-5 were A-OK.

What happened is a power outage in a thunderstorm. The RAID subsystem disappeared while the OS was writing something to the disk. When power came back, THE FILESYSTEM WAS GONE. Not corrupted, gone. MIA. Poof.

The RAID monitor saw all the disks, but the OS wouldn't even acknowledge that there was a mountable filesystem there any more. The victim had to resort to one of those data recovery programs that just scans the disk for file-like objects and saves them off one by one without metadata to an external hard drive.

He had no backup because he thought this 4-disk external RAID was expensive as-is. To back it up, he would have had to double his hardware costs. Now he's looking at the cost of recreating the home movies he had stored on that RAID and realizing that a thousand dollars or so for an offline backup RAID is actually cheap.

That is a lame-ass cop-out.

All it would take to figure some of these things out is some reverse engineering. Similar feats have been accomplished by the FLOSS community for less return many times.

I suspect what the GP ran into is a lack of support for layer styles, a feature Adobe added to Photoshop about a dozen years ago. No one's been able to figure this addition to PSD out in a dozen years? Really?

No: the truth is that everything you can do with Layer Styles, you can do by hand, so the Gimp culture's knee-jerk reaction is "Why bother?"

I'll tell you why: Layer Styles greatly speed up one's workflow. You can apply an effect with a few clicks, change it dynamically, save it, and keep editing it when you open the file again later. That's powerful stuff. But because it only amounts to smoothing out a workflow, and we all know how much the Gimp project cares about workflow issues, the feature never gets any attention.

Stone knives and bearskins, I tell you. That's all you really need!

Valid Photoshop license holder speaking here.

Yes, it's great that Gimp exists and that it's free in both senses of the word.

The problem is that Gimp keeps getting compared to Photoshop, as though it's any kind of contest.

If this were a racing event, the only way you'd get Gimp up against Photoshop is to do away with the class system. They call it an outlaw race, in automotive racing.

If you want to compare Gimp to something in the commercial world, compare it to Photoshop Elements, or Pixelmator.

...such as??

Seriously. I'd like a list of features in the stock version of Gimp that have no equivalent in Photoshop, please.

I'm only aware of one: the Lanczos resampling mode in the image resize dialog.

I happen to know that one only because it's emblematic of the Gimp usability problem. Its naming says it's a good idea to give a creative app a feature named after a mathematician with an unpronounceable name. (Yes, I know, LUNT-shosh. A fact maybe 1% of the 1% Gimp community knows.) Why not name it after its effect, or after its raison d'etre? For all I know, Photoshop does have Lanczos resampling, but they've named it something sensible.

The closest you see Adobe coming to this problem is Gaussian blur, and the past several releases of Photoshop have been moving away from it. One of the banner features of Photoshop CS6, the blur gallery, should do wonders for sweeping plain old Gaussian blurs into the dustpan of history.

So is that it? Is there anything else Gimp can point to and call its own?

I guess you could point to the scripting languages. Yes, Photoshop doesn't have a Scheme or Python interpreter. But it does have JavaScript, and you have a choice of VBScript on Windows and AppleScript on OS X. This doesn't count in my book. These two feature sets are comparable. I'm asking for features Gimp has that actually make some difference to an artist. Artists don't care what language their scripts are written in.

Simple: this bill takes these rights away for all 300+ million Americans. At a pen stroke. Poof, gone.

I don't know how you do your crime calculus on this issue, but it would have to be a pretty strange method for any conceivable level of murder to exceed this level of violation of our rights.

What is the murder equivalent of the loss of 3e8 rights?

If this passes and doesn't get repealed, double that cost in lost rights every 74 years, because the crime continues while new Americans are born.