> > These graphical or visual programming languages you denigrate really do >> help scientists, engineers, and other "domain experts" who aren't, and >> don't want to become, "programmers" implement an idea for which there is >> not, and will never be until the idea is proven sound, a budget for "hiring >> real programmers". >> > In principle, yes, they are useful and enabling. In practice, however, they have been underwhelming, and I can think of several reasons:
- fragmentation: they usually are designed for some domain-specific programming (e.g. LabView for data acquisition, GNUradio for signal processing, Simulink for control systems, SGI AVS/Explorer for data flow/processing, etc). This, however, means that their audience is limited to that particular domain. - closeness: most of graphical programming systems are commercial and closely held by their owners - lack of scaling: easy tasks are very easy, but as the program size grows, they become unmanageable. It's difficult to determine whether two visualized data flow graphs are equivalent: the program representation and semantics are mixed up. My favorite dis of graphical programming: - Finally, we can have spaghetti code that looks like spaghetti! Someday, someone will probably come up with visual system that's general, open source and amenable to maintaining in git---but that day hasn't arrived yet. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGyRF185jpBpgf%2BugqTRsfd5S6QdV9oHXc_W55%2Bs%3D5Ygw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
