[BlackGriffen]

Is anyone here familiar with a program called Lab Bench? It allows you to build virtual instruments that simulate real ones. You literally connect the virtual bits together graphically, and build instrumentation. Why can't we program this way? You'd probably have to still code the basic "functional units" by hand. I know that flow charts are a big help in planning a program, but why can't the shapes in a flow chart represent functions, objects, small programs, and/or variables? Has this been tried before? The reason I ask the guys from Omni to read this is because I imagine that OmniGraffle would be part way there already...

BlackGriffen

[skeedog98]

Is that anything like LabView?

[Millennium]

What you're talking about sounds very similar to a CASE (Computer Aided Software Engineering) tool. The idea behind programs like these is to work out a complete design for the program, and it will spit out most of the grunt-work parts of the code for you.

These things never really caught on, for a variety of reasons. One, they're actually much more complex than one might originally think. You spend almost as much time drawing -perhaps more- than you would have spent coding. Two, these programs bring the phrase "absurdly expensive" to a whole new level, generally costing thousands of dollars per license and requiring funky network-based schemes to ensure you're not running multiple copies at once.

I don't know if any CASE tools exist for OSX. A few used to exist for OS9, but I think they died out a long time ago.

[absmiths]

This won't happen anytime in the near future (if ever). It has been a pipe dream ever since VB 1.0 and before (probably way back to SmallTalk). This is one reason that many managers think that their IT staff is so expendable - "GEE, look at how easily we can drag-and-drop and create applications!" Technology like this is always late to market and by the time you can utilize it it is too primitive for what the market demands.

Many studies have been done and the end result of all of this GUI appbuilder nonsense is that more time is wasted using the tool (VB, JBuilder, Forte, VisualAge, etc) then coding by hand (not without an IDE, just without the visual tools that they try to provide).

When you get to the level at which LabView operates, an app tool like that would be seriously heinous to work with. OTOH, LabView is excellent for what it is, because it has a very specific problem domain and it handles it well. An application builder, however, has to be able to do everything and even though Microsoft would have you believe that any idiot can write a program, the reality is somewhat different.

[sadie]

I agree, it's a flawed idea. At any level, a system which takes control of programming away from the programmer is dangerous.

Interface Builder for Cocoa (and Carbon now) appears to be an exception - a visual builder that works. But the fact is, it only works because it isn't at all invasive. It doesn't try to force how you build your applications, it simply provides a simpler way of writing the data format for a window.

Nanny tools restrict programming freedom.

[absmiths]

Originally posted by sadie:
<STRONG>Interface Builder for Cocoa (and Carbon now) appears to be an exception - a visual builder that works.</STRONG>

I would be interested in finding out how to do what it does myself. I haven't seen any docs yet on how it does it. I can create text fields, windows, buttons, etc, but how does the layout work? What about all the connections/etc? What about dynamic menus?

I kinda see PB/IB sorta like CW PowerPlant - a handy place to start - especially for rapid prototyping.

IB also has the added advantage that it is by default Aqua compliant.

[Rickster]

Well, OmniGraffle may address your needs in the future, if only unintentionally. Greg's been adding extensive AppleScript support for 2.0, and one of the test cases he came up with is a logic gate diagram that actually works.

[Chaaaosss]

Originally posted by absmiths:
<STRONG>

I would be interested in finding out how to do what it does myself. I haven't seen any docs yet on how it does it. I can create text fields, windows, buttons, etc, but how does the layout work? What about all the connections/etc? What about dynamic menus?

I kinda see PB/IB sorta like CW PowerPlant - a handy place to start - especially for rapid prototyping.

IB also has the added advantage that it is by default Aqua compliant.</STRONG>

Well, to be brief (but not really as I found out later... the thoughts kept coming), I equate Interface Builder most to Adobe GoLive. You get this blank window and all these widgets in this other floating window. Whatever you need you drag over to your blank window. So let's say you drag an editable text box and a button over to the blank window. Both the text box and the blank window are instantiations of base classes from the AppKit side of Cocoa. So while they look like harmless pretty buttons and text boxes, they're really just a layer of beauty that are hardcoded underneath through the frameworks. You use actions to allow the text box or the button to have a function beyond just sitting there and looking pretty. For example, you click the button and get its properties, and you add an action. Once you click the "Make files" or whatever to instantiate your document or your class, the header and implementation files are added to the project you launched from IB, and you can edit within the parentheses IB made for the button (tell the button what to do when it's clicked, etc.). Obviously this whole "tutorial" is heinous and wouldn't get you very far in the real world but hopefully it gives you a general idea of how it works. You drag widgets over. You give them properties. IB creates header files and implementation files for you based on what properties (or actions or outlets) you gave the widgets. You then edit the code (like you do in the Source tab of GoLive) in Project Builder to suit your needs.

As many have said in this forum below, IB's function and my rambling above are effortlessly explained in Aaron Hilegass' (sp?) book -- Cocoa Programming for Mac OS X. His book is incredible.

[kamprath]

Originally posted by Millennium:
<STRONG>What you're talking about sounds very similar to a CASE (Computer Aided Software Engineering) tool. The idea behind programs like these is to work out a complete design for the program, and it will spit out most of the grunt-work parts of the code for you.

These things never really caught on, for a variety of reasons. One, they're actually much more complex than one might originally think. You spend almost as much time drawing -perhaps more- than you would have spent coding. Two, these programs bring the phrase "absurdly expensive" to a whole new level, generally costing thousands of dollars per license and requiring funky network-based schemes to ensure you're not running multiple copies at once.

I don't know if any CASE tools exist for OSX. A few used to exist for OS9, but I think they died out a long time ago.</STRONG>

Effectively used CASE tools allows you to do something you can't manage well via source code alone - design software architecture, especially in OO-software projects. True, in simple projects, the benifit/work ratio is pretty low, but the true benifit of CASE tools show their heads in extremely large and complex software and system design. It allows you to break coding work up into portions where a single programmer doesn't need the CASE tool to get the (assigned) work done .

Furthermore, CASE methodologies such as UML allow you to do OO-design RIGHT. Just because you made a class object does [I]not[/I} mean you have experienced the benifits of OO-design (I've seen so much "bad" code that claims to be OO because it is in C++ or Java), and it is extremely hard to visualize what is going one in a complex OO project by looking at headers. UML/CASE allows you to first concentrate on developing the good OO-design (each object has appropriate, consistent, and coherent interfaces), the emit boilerplate code to then concentrate on developing good implementation (actual coding).

As with anything design/implementation is an iterative process, but it is not a "chicken vs egg" process - you must design before you can implement - even if you are only doing it in your head. CASE tools are made to make the design phase effective, especially for large efforts.

BTW, UML use is very much alive today, but there are no tools for OSX. Rational Rose has a tool for Linux, maybe they can be persuaded into porting it to at least an X-windows application that runs on Darwin.

Michael

[ 01-17-2002: Message edited by: kamprath ]