Thank you for your remarks. I looked at your FreeTUIT and must admit that if (I repeat: if) I understand it well, then it is not codeless technics: the code is more compact than Perl's but still is.
I know such a technics true codeless GUI/web programming: it is (was?) Magic-eDeveloper. I spend many years with the true codeless language - no a line!. In those years it used btrieve database and was really unbeatable. The tool was (and AFAIK is) pure table/graphical language. All the logic is build from fundamental objects/operations. What you must write are expressions only. Now however ( I checked version 10th) it has few serious drawbacks so I resigned to work with it. But the drawbacks does not connected with the main idea. The main technical problems was wrong sql solutions and wrong web solutions. Maybe they repair problems recently? I do not know - my knowledge is from 2007. All the stuff with the MVC is just talking. Always programmers try to make a job easier. So they cut work into slices. However the slices in web/php or web/perl (templates) are not very good solutions: levels are still too joined. That the true reason of such number of tamplates on market. My idea is not to through out code but give proper code to properl people: for database programmer: sql (Codd), for document template creator: (la)TeX (Knuth), for enterprice database application: logic language (me :) ). I have already said that I am database/gui/web programmer so my words should be taken limited only to the subject. Thanks for your remarks again! wb. Dnia środa 02 grudnia 2009 o 19:06:52 Eric Wilhelm napisał(a): > # from Waldemar Biernacki > # on Monday 30 November 2009 08:23: > > >My idea is to build specific very-high-level language in which all > > application logic is written. This language should be reading by GUI > > and WEB engines giving similar application. It is interesting that in > > web area we have many such templates (although their code programming > > level is too low in my opinion - including catalyst) but on a GUI > > side they are very few (it should be written in wxperl in your case). > > That sort of touches on what I'm doing with FreeTUIT, though the > high-level language is all about widget layout and event connection. > Some backend logic doesn't contain any Wx code, but when you get into > responding to user events you need rather specific code interacting > with the view (e.g. wxWidgets vs javascript+cgi.) > > Note that FreeTUIT is intended mostly as a desktop GUI framework, but > I've been asked about whether it could do web apps and have been > thinking about how that might be possible. > > There's a big gap between the two paradigms though because in a GUI app > you're not designing around network latency. I'm having a hard time > thinking of how those differences could be abstracted without crippling > the API in both use cases. > > There's also a very limited widget-set in web applications as compared > to desktops. For instance, webapps would frequently use a submit form > for appending/editing tabular data where a guiapp would trivially allow > inline edits in the table. Similarly, the webapp would page the data > where the guiapp would easily have a scrollable widget that's lazily > populated. > > In "traditional" (i.e. without javascript) webapps, you're basically > working in an "everything is a wizard" paradigm of stepping through > prompts and a rather sequential interaction -- pretty simple concepts > to map between a desktop and webapp. With ajax involved, you get to > juggle the widgets right in front of the user, which makes for a more > mediated experience. The trouble with automagically handling this > widget-juggling code in both webapp/desktop paradigms is not only the > javascript/wx API difference, but also that the code seems to naturally > factor into differently shaped components in terms of dealing with > what's in front of the user and recalculating/rendering data from the > backend. > > Amusingly, there's a thread about "Qt on rails" happening over on the > kde bindings list. > > Also amusingly, if "MVC" was a valid abstraction, this problem would > have been trivially solved long ago. :-D > > --Eric >
