Re: kylix: rad!
Hi all, brian moseley wrote: have you folks seen kylix? http://www.borland.com/kylix/ And have you seen KDevelop ? http://www.kdevelop.org and also http://dot.kde.org/992083107/ http://dot.kde.org/986594487/ So there is already a basic Perl support in KDevelop 3 (codename Gideon)... Regards, -- Christian
Re: kylix: rad!
On Sun, 13 Jan 2002, Daniel Aldham wrote: Slashdot and Freshmeat ran a story on the weekend about the Borland/Kylix license. Pretty draconian stuff. that's where i heard of it.
Re: kylix: rad!
GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. consider struts, a popular java mvc framework. it defines simple interfaces for things like actions and forms. does struts (and mvc in general) work for non trivial websites? Struts is a framework, not a GUI builder. I'm all for frameworks, and we have stuff on CPAN that duplicates all the significant parts of Struts. a struts-oriented rad tool could easily scan WEB-INF dirs to find action and form classes and represent them in the gui. the main purpose of the tool would be to assemble and configure those classes in order to generate a struts-config.xml file. it could also incorporate ide functionality. Such a tool does exist for Struts, but all it does is generate/edit the config file. Too me, this doesn't seem very labor-saving (typing in a Swing app vs. typing in my text editor), but it might generate more interest among certain groups. Adding some mod_perl oriented stuff to whatever the leading Apache GUI is these days could be a good start. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. I'm not sure I want to try and draw in users who can't program at all. why do you think this tool would appeal to people who can't program at all? Because your post made it sound like you were talking about drag-and-drop wizard-driven GUI builders with pre-written components (which is what Kylix is trying to be, if I understand it correctly). There is a need for tools to generate instant database editing apps, and some projects to build those tools exist now. Beyond that, I think most users know enough Perl to write actual code in a good editor. There are already commercial Perl IDEs (aimed at CGI mostly) that have some code generation support and a set of pre-built components. Maybe looking at those would help to gauge developer demand for this kind of thing. - Perrin
Re: kylix: rad!
On Sat, 12 Jan 2002, Perrin Harkins wrote: Well, does this product actually have any users to compete for? unknown. i figure a large established software company isn't going to spend time developing a product for a market that doesn't exist, but you never know. GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. consider struts, a popular java mvc framework. it defines simple interfaces for things like actions and forms. does struts (and mvc in general) work for non trivial websites? a struts-oriented rad tool could easily scan WEB-INF dirs to find action and form classes and represent them in the gui. the main purpose of the tool would be to assemble and configure those classes in order to generate a struts-config.xml file. it could also incorporate ide functionality. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. I'm not sure I want to try and draw in users who can't program at all. why do you think this tool would appeal to people who can't program at all? consider the popularity of java and c++ ides. do you think it's possible that people who use those languages might switch to perl if tools like this existed to generate webapps in perl? many of us on this list have well-developed preferences for editing and debugging our code, configuring and testing our applications that are based on executing shell commands in a terminal. don't you think there are lots of well developed advocacy reasons for offering an alternative paradigm? said another way, just cos *you* don't use gui development tools to develop modperl apps doesn't mean there aren't heaps of people out there who'd love to do just that.
Re: kylix: rad!
-- brian moseley [EMAIL PROTECTED] many of us on this list have well-developed preferences for editing and debugging our code, configuring and testing our applications that are based on executing shell commands in a terminal. don't you think there are lots of well developed advocacy reasons for offering an alternative paradigm? Good example would be W32 developers who want to migrate and simply don't know their way around *NIX yet. Even if they've taken the time to learn how the HTTP/HTML/etc end of things function, working on NT doesn't give them very good reflexes for dealing with *NIX. This does seem like a good way to show people that gaining add'l control with mod_perl doesn't have to be painful. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: kylix: rad!
On Sat, 12 Jan 2002, Perrin Harkins wrote: Well, does this product actually have any users to compete for? GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. Agree. I'm not sure I want to try and draw in users who can't program at all. Tangential thought: we may not want to draw individual non-programmers but we undoubtably do work with non-programmers - artists and HTML writers. I think a GUI system that made it easier for these non-programmers to interface with our creations would have some utility. I've got a half-baked module sitting in my workspace, HTML::Template::Explorer, that was an attempt to do something along these lines for HTML::Template. I didn't get very far before I realized I didn't have a strong enough design to be coding... -sam
Re: kylix: rad!
On Sun, 13 Jan 2002, brian moseley wrote: altho kylix was discussed in the first post of the thread, my actual reply to you stood on its own as a condemnation of a general cliquish attitude. Oh, consider me properly chastened then. BTW - kylix is actually the subject of this thread, supposedly. I didn't think addressing it directly was too out of bounds! And Kylix *is* aimed at non-programmers, or at least it was when it was Delphi. but microsoft visual studio blah blah .net blah blah is quite popular, isn't it? Have you used MS visual studio? There isn't much visual about it. In my experience it's pretty much on par with the various C/C++ IDE's around for Linux already. All of which are pretty close to useless, IMO. People use MS Visual Studio because they have to. Same reason they'll use .NET. If there's anything Borland has proved it's that providing a better development environment than Microsoft doesn't get you more developers. Kylix is, as I understand it, something much closer to original Delphi aim of programming without coding. I'm not saying it wouldn't be neat if you could do Kylix for Perl. I'm just saying I don't think it would be a fantastic success. So, yeah, I'm agreeing with Perrin, but I don't think that makes me some kind of horrible elitist. -sam
Re: kylix: rad!
At 06:16 AM 1/14/2002, brian moseley wrote: On Sun, 13 Jan 2002, Sam Tregar wrote: On Sat, 12 Jan 2002, Perrin Harkins wrote: Well, does this product actually have any users to compete for? GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. Agree. you know, i think it's this attitude, or a more insidious version of it, that keeps mod_perl from being as ubiquitous as php. it's like having to pledge the frat before you can get the hot chicks. i, for one, would like to see more people getting interested in making it easy for people who don't practice black magic to take advantage of mod_perl. OK, I learned mod_perl, now where are my hot chicks! :) I think a UI tool would help a bit, but it wouldn't necessarily solve the hard part of mod_perl which is the lack of Interpreter cleanup between invocations. PHP and ASP clear their variables at the start so it seems harder for applications to overwrite each other and cause weird subtle bugs. I guess there is PerlRun (but it's not true cleanup) or PerlRestart, but that's really slow To some degree, the nature of mod_perl feels like it makes it harder. A UI would help though especially if it had a debugger that learned when attached to a given httpd process what variables were being preserved and reused over and over again... so you could trace those things down. A point to note... even though we give out free Perl and Java applications, we feel that even our own config files are large and therefore daunting for beginners so we have been doing RD to come up with a web interface to create config files for MVC based web apps. A UI is not what we want because we'd like people to go through the wizard and then be able to download a pre-packaged app. I Think making things easier is always a noble effort but it's not always clear until you try, what is truly easier. 1 size doesn't usually fit all. Many peple like IDEs, many people hate them... Later, Gunther
Re: kylix: rad!
On Mon, 14 Jan 2002, Gunther Birznieks wrote: OK, I learned mod_perl, now where are my hot chicks! :) no, no, you have to pledge the frat! I think a UI tool would help a bit, but it wouldn't necessarily solve the hard part of mod_perl which is the lack of Interpreter cleanup between invocations. PHP and ASP clear their variables at the start so it seems harder for applications to overwrite each other and cause weird subtle bugs. To some degree, the nature of mod_perl feels like it makes it harder. true, altho it can be said that persistent state is part of the nature of server programming, and whether you use a tool to generate an app or code it all by hand, you have to learn to exist according to that nature. you can certainly write php code that scopes its variables properly, uses disk- and shmem-based configuration and persistence mechanisms rather than global variables, etc. but you don't have to, cos php bends over backwards to make the world a very forgiving place. i think that best practices should be enforced by the environment. i don't think it's inconsistent to create tools that make a developer's job easier (enabling him to speed up the implementation lifecycle) and that also enforce best practices. A point to note... even though we give out free Perl and Java applications, we feel that even our own config files are large and therefore daunting for beginners so we have been doing RD to come up with a web interface to create config files for MVC based web apps. A UI is not what we want because we'd like people to go through the wizard and then be able to download a pre-packaged app. web and desktop uis are all guis, right? hell, emacs jde is an ide/gui. it shouldn't be a huge technical challenge to design an application that can have multiple types of gui layered onto it. i built my last little project exactly that way - with a web interface and a command line interface. mvc helped immensely with that. I Think making things easier is always a noble effort but it's not always clear until you try, what is truly easier. 1 size doesn't usually fit all. Many peple like IDEs, many people hate them... yah. i don't really feel very comfortable in them myself. i wasn't suggesting that i was going to build this tool myself; i just thought i'd share the idea. because given the number of gui tools that exist, and the testimony of users, it's clear that at last some people find those tools useful. subject line aside, the idea/opinion that really got me in this thread was mod_perl is not for less/non experienced programmers. that may be the reality today, but it doesn't have to be by nature. it's like we were talking about on #modperl yesterday. somebody wondered why php applications tend to sport prettier/cleaner/better ui's than perl applications. i think it's cos the php community is more design oriented, specifically because the environment is so conducive to less experienced programmers getting stuff done. if you were a designer sitting down to do your first application, which would you choose - php or perl+mason/tt/whatever? you can go to php.net and see a comprehensive searchable manual of all core apis. you don't have to install anything to be able to send an email or connect to a database. you don't have to look at many web sites - just one (maybe two, if you consult phpbuilder for tips and tricks). you can store data in a web session with 2 function calls. you can reasonably make a dynamic page within 30 seconds of your admin telling you that php is installed in the web server. contrast that with what's available for mod_perl, mason, tt, etc. all well documented, but at a lower level technically. you have to ask your admin to install DBI and MIME-tools (or figure out how to install them into your home dir). you have to figure out how to cause registry scripts or mason pages to be executed (and you have to install mason). you have to write wrapper code to rig up a session framework (and you have to install session modules). etc. the bar is higher for mod_perl and friends. you have to read and understand many more concepts in order to make a hello world web page. you can't be a 9th level designer/1st level coder.
Re: kylix: rad!
On Sun, 13 Jan 2002, brian moseley wrote: Kylix is, as I understand it, something much closer to original Delphi aim of programming without coding. I'm not saying it wouldn't be neat if you could do Kylix for Perl. I'm just saying I don't think it would be a fantastic success. So, yeah, I'm agreeing with Perrin, but I don't think that makes me some kind of horrible elitist. Slashdot and Freshmeat ran a story on the weekend about the Borland/Kylix license. Pretty draconian stuff. http://freshmeat.net/articles/view/369/ -- Danny Aldham Providing Certified Internetworking Solutions to Business www.postino.com E-Mail, Web Servers, Web Databases, SQL PHP Perl
kylix: rad!
have you folks seen kylix? http://www.borland.com/kylix/ check out this white paper that describes how to create cgis and modules for apache: http://www.borland.com/kylix/papers/apache_development.pdf kylix looks pretty much like ye olde application framework, just like what many of us have built in the past, plus a gui that allows boneheads to drag and drop application components and right click to configure the application's properties, resulting in an immediately deployable cgi or dso (rad, or rapid application development). competition with this product (which has some really freaking license clauses which you can read about on freshmeat) seems pretty easy: 1) create a suite of standard web components (such as emailform); 2) build a gui to let you easily assemble and configure those components (and your custom components) into an application; and 3) provide a compiler tool that creates the cgi executable or module dso given the inputs from #2. the kylix netclx layer, defining actions (which are dispatched according to the value of the path info) and page producers (which generate html forms), is your standard mvc design. no real innovation there, we have several to choose from on cpan and in our own cvs repositories. one question is: what frameworks and components to use (task #1). you could limit the tool to one framework, say mason, or you could support an abstraction layer (libservlet comes to mind :) which would allow you to select mason or tt or axkit as you prefer. anybody interested?
