Messages - pao [ switch to compact view ]

Pages: prev1 [2]
I've found Apple's ports of their Mac programs to Windows to always be a bit short of their Mac counterparts.

To be clear, Lightroom is an Adobe, not Apple, product.  However, Adobe did originally develop the program on Mac, clearly as a response to Apple's Aperture product, with Windows development starting only recently.  That said, I expect future Lightroom for Windows betas will be quicker as Adobe gets the Windows version more up to speed with the Mac version.

Adobe released the first beta of Lightroom for Windows (confusingly labeled Beta 3 because it's the third Mac release) a couple of days ago, which is free for the time being.  The Mac version has been available for some time now.  I haven't tried using the metadata features, but they are supported, and if I understand correctly will be written to XMP/DNG, IPTC, and the like when possible, like in Bridge.  The beta version is slow, but usable on my machine (1 GB RAM, Athlon64 3000+).  It supports most image formats, including any RAW format supported by Adobe Camera RAW, though RAW conversion is noticeably slower than in standard ACR.

Lightroom's beta versions are/will be free.  No word on the cost of the final product.

i do think though that matlab suffers from the thing that most powerful tools suffer from after many years of evolution towards more powerful scripting, which is that the underlying language is not quite up to par with a full clean well designed oop language. ... in other words, i predict that in 10 years i suspect that programs will not have their own little languages.
in 10 years when you buy a tool like matlab, microsoft office, firefox, whatever - they will all use a standardized interface for scripting.

The underlying language of MATLAB is C*, and advanced users could write really advanced stuff as a C library instead, but this doesn't seem to come up much.

I don't think we'll see a generalization of scripting languages--for example, MATLAB is syntactically refined to be an excellent language for programming numerical algorithms, down to details like myvector(end) (shortcut for last element) and myvector(1:2) = [] (shortcut to remove first two elements from the vector).

Similarly, Perl is the greatest thing in the world for messing around with text files and strings, and its syntax, particularly with the simple use of regexes, seems geared to that.

I think the best example of a general-purpose scripting language that interfaces with many applications is AppleScript, which I'm not very familiar with, but sounds closest to mouser's prediction.  VBA is similar, though limited mostly to Microsoft apps.  But I don't see these replacing, just augmenting, existing scripting interfaces.  If nothing else, the group of people who might be called "non-dedicated programmers" for whom programming is only a part of what they do will have a resistance to the changes that would lead to the loss of their favorite niche language.

Okay, I'm just rambling now.  My original point was that the OP (not mouser, the blog poster) seems to either dismiss or ignore graphical programming environments, notably LabView, as failed attempts.  While LabView (in particular) has not seen broad acceptance by programmers, this probably has more to do with typecasting--in the acting sense--not as a general purpose language, but as a data acquisition language, no doubt because (1) that was its original purpose, and (2) National Instruments uses LabView primarily as a way to sell DAQ cards.  Thus, programmers, even those with access to LabView, often don't consider it for other tasks which it is perhaps just as well suited for.  It's a shame because it's an extremely rapid application development environment.  If only it weren't so expensive...

* The IDEs of MATLAB 6 and above are written in Java, and the language has access to the JRE, though I'm not exactly sure how to do this, as it too has never come up.

When I worked at the Georgia Tech Research Institute as a co-op a few years back, most of my programming was done in LabView, a highly successful graphical dataflow programming environment which tends to be used for real-time data capture and processing, but which is in truth far more flexible.  Similarly, the Aerospace Controls Lab class has 100% of the programming work done in a combination of MATLAB, a conventional procedural language with a focus on numerical (particularly vector) work; and SIMULINK, a graphical dataflow language used by engineers, among others, to simulate physical processes and control systems.

This is anecdotal, but I've seen people who haven't written a large-scale program in their lives (myself included) "writing" large programs with reusable components in LabView with almost no problems whatsoever.  People who never really got the hang of MATLAB (after taking a class on it!) get SIMULINK figured out in a week and a half.  It seems unfair to call these languages a "failure."  Perhaps they won't make everyone a programmer--I think the proprietary and expensive nature of these tools is a factor--but they are clearly easier to learn by engineering students than conventional programming languages.  I'm interested in the IBM graphical language project mouser mentions above.

But there's a large difference even between text-based, non-functional languages.  I learned BASIC (my first language), Pascal, and MATLAB almost instantly.  Perl I can handle with the O'Reilly pocket guide.  I never got the hang of C and C++ is complicated as all get-out, but I'm starting to get it.  But a few years back I was helping people with their CS homework in Java despite never having learned it.

On a different note, I think the remark about excessively nested structures is a valid one.  Forth had even worse luck than the Lisp-y languages, except among owners of HP graphing calculators, and Forth has no parentheses.  Back when I carried an HP 49G as my primary calculator, I'd pore for many minutes over the program flow of even a simple RPL program which I would readily understand in BASIC, C, MATLAB, Perl, etc.  (I've since switched to a 32SII, which I have no idea how to program.)

Pages: prev1 [2]
Go to full version