This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: <modperl@apache.org>
From: brian moseley <bcm@maz.org>
Subject: kylix: rad!
Date: Sat, 12 Jan 2002 01:35:42 -0800 (PST)
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?
===
To: <modperl@apache.org>
From: brian moseley <bcm@maz.org>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 16:26:26 -0800 (PST)
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 R&D 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.
===
To: <modperl@apache.org>
From: brian moseley <bcm@maz.org>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 14:16:55 -0800 (PST)
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.
===
To: "brian moseley" <bcm@maz.org>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: kylix: rad!
Date: Mon, 14 Jan 2002 09:58:37 -0500
> > 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.
===
To: Perrin Harkins <perrin@elem.com>
From: Sam Tregar <sam@tregar.com>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 16:17:53 -0500 (EST)
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
===
To: <modperl@apache.org>
From: Gunther Birznieks <gunther@extropia.com>
Subject: Re: kylix: rad!
Date: Mon, 14 Jan 2002 07:50:59 +0800
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 R&D 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
===
To: sam@tregar.com (Sam Tregar)
From: Daniel Aldham <falstaff@lennon.postino.com>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 17:40:14 -0800 (PST)
>
> 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/
===
To: mod_perl list <modperl@apache.org>
From: Christian Couder <Christian.Couder@cetelem.fr>
Subject: Re: kylix: rad!
Date: Mon, 14 Jan 2002 09:15:36 +0100
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)...
===
To: lembark@wrkhors.com
From: Steven Lembark <lembark@wrkhors.com>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 14:32:44 -0600
brian moseley <bcm@maz.org> wrote:
> 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.
===
To: Perrin Harkins <perrin@elem.com>
From: brian moseley <bcm@maz.org>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 12:27:34 -0800 (PST)
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.
===
To: brian moseley <bcm@maz.org>
From: Sam Tregar <sam@tregar.com>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 17:56:49 -0500 (EST)
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.
===
To: <modperl@apache.org>
From: brian moseley <bcm@maz.org>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 14:46:03 -0800 (PST)
On Sun, 13 Jan 2002, Sam Tregar wrote:
> Ah, gimme a break. You want to convince me that
> non-programmers can find their way to the party with a
> fancy GUI? Go right ahead! I'll let you wear the
> moose-hat for a whole week if you succeed. However,
> that doesn't mean I'm going to stay quiet about just how
> unlikely I think it is!
you apparently didn't read my second-to-last message in this
thread, in which i explained that non-programmers are not
the subject of the original idea.
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.
> Kylix is not a new idea - it's an old, mostly
> unsuccessful one ported to Linux by an old and mostly
> unsuccessful company. If it had worked then we'd all be
> out of business and most commercial apps would be
> "written" by business majors with Delphi.
but microsoft visual studio blah blah .net blah blah is
quite popular, isn't it? and many commercial apps /are/
written with that toolset, aren't they?
once again: give people tools they are comfortable with, and
they are more likely to try alternative technologies and
perhaps find their way to the party.
maybe if i said "maybe activestate could make komodo
generate cgis and mod_perl modules", you'd find the idea
more interesting. cos you know, people actually write code
with komodo.
===
To: brian moseley <bcm@maz.org>
From: Sam Tregar <sam@tregar.com>
Subject: Re: kylix: rad!
Date: Sun, 13 Jan 2002 17:23:01 -0500 (EST)
On Sun, 13 Jan 2002, brian moseley wrote:
> On Sun, 13 Jan 2002, Sam Tregar wrote:
> >
> > 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.
Ah, gimme a break. You want to convince me that non-programmers can find
their way to the party with a fancy GUI? Go right ahead! I'll let you
wear the moose-hat for a whole week if you succeed. However, that doesn't
mean I'm going to stay quiet about just how unlikely I think it is!
Kylix is not a new idea - it's an old, mostly unsuccessful one ported to
Linux by an old and mostly unsuccessful company. If it had worked then
we'd all be out of business and most commercial apps would be "written" by
business majors with Delphi.
-sam
===