Labview was also the first thing that came to my mind.
In my experience, apart from complex number-crunching (for which it does have a stripped down textual-code vi), I found it easier to work with than java. I think that is more related to my hatred of unnecessary state (which an OOP only model supports). In Labview, the easiest way to store state is to pass the output of the vi (function) into its input at the next time it is called.
I still don't enjoy using Labview, but I haven't felt like there was something I couldn't do in it (in terms of resulting program).
I agree that the de-emphasis of state and the stream-based programming model are wins for LabVIEW. (Though the real win is: It seems to support every piece of lab hardware by one means or another. This is a difficult feature to give up.) It's the mere mechanics of LabVIEW programming - the need to massage a layout of wires that were difficult to draw, read, print out, diff, or version-control - that used to drive me crazy.
Though the last time this came up on HN a National Instruments employee turned up to say that things have improved since last I used LabVIEW. Apparently they've lavished attention on the design problem of virtual-wire layout and tracking.
The new versions of Labview are pretty good about layout. The auto format command (^e I think) usually produces easy to read code.
Diff is still pretty bad though.
