By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,361 Members | 1,683 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,361 IT Pros & Developers. It's quick & easy.

Looking for a language/framework

P: n/a
Way back when, I got a lot of training and experience in highly
structued software development. These days, I dabble with
web-development, but I may become more serious.

I consider php to be an abombination, the backward compatibility issues
alone are reason enough to make me hate it. Rail looks promising, but
it's difficult to find inexpensive hosting that supports rails.

I like python much better, but I'm not certain it's as well suited for
web developement. I'm not sure how th e apache module thing works. I am
using shared hosting, they provide python, but I'm not sure how limited
I'll be.

Ideally, I would like to be able to develop a database driven web-app,
in much the same manner as I could develop an ms-access app. As much as
I dislike msft, I have to admit, an ms-access app can be put together
quickly, without any steep learning curve.

I've been looking at python web frameworks, and I'm not sure what to
think. It seems like these frameworks would allow me to do a lot of
work, with a small amount of code, but the learning curve seems very
steep.

I wouldn't even mind the steep learning curves, so much, except, it
seems to me that anything developed with one framework, would not work
with another. So if I changed my mind about which framework, I'd have
to start all over again - re-learning everything, re-writing
everything. Of course, everybody says their framework is the best. But
how can I know for sure? I don't have time to try them all.

Mar 28 '06 #1
Share this Question
Share on Google+
23 Replies


P: n/a
walterbyrd <wa********@iname.com> wrote:
...
I consider php to be an abombination, the backward compatibility issues
alone are reason enough to make me hate it. Rail looks promising, but
it's difficult to find inexpensive hosting that supports rails.
What's your budget? DreamHost offers Rails hosting for $7.95 per month,
which definitely falls within what I would call "inexpensive", just for
example. I'm sure you can find others in similar price ranges.
I like python much better, but I'm not certain it's as well suited for
web developement. I'm not sure how th e apache module thing works. I am
using shared hosting, they provide python, but I'm not sure how limited
I'll be.
What Python server-side frameworks does your shared hosting service
support? Or do they only offer Python as a CGI language?
I wouldn't even mind the steep learning curves, so much, except, it
seems to me that anything developed with one framework, would not work
with another. So if I changed my mind about which framework, I'd have
to start all over again - re-learning everything, re-writing
everything. Of course, everybody says their framework is the best. But
how can I know for sure? I don't have time to try them all.


Nobody does, which is the main advantage of Rails -- it so dominates the
scene of web frameworks for Ruby, that nobody seriously wonders what
framework to pick for that language (there exist others, but their "mind
share" is close to zero). Python frameworks may interoperate at several
levels (e.g. through the WSGI middleware layer) but that's not the same
as having a single framework.

OTOH, different frameworks may cater for different audiences: at one
extreme, the webjockey who knows and loves the underlying technologies,
from HTTP to SQL, and only wants high productivity without (what he or
she perceives as) "cruft" on top and definitely without any conceptual
blockage impeding access to the underlying technologies when that access
is wanted; at the other extreme, somebody who doesn't even know the
difference between SQL and HTTP, doesn't want to learn anything hard,
and just wants to point and grunt and make three websites a day -- and,
of course, anything in-between.

For example, I've never seen an "object-relational mapping" (technical
term for cruft that tries to avoid people having to learn and use SQL)
which doesn't drive me into a murderous, foam-at-mouth rage in a very
short time -- I *WANT* my SQL, I *LOVE* SQL, it's *WAY* more powerful
and suitable for access to data than all those simulated "OO DB" people
lay on top of it (of course, that does depend on having a REAL
relational DB underneath, not, say, MySQL;-). Other people disagree
very, very deeply with my preferences (as proven by the existence of a
begazillion ORMs, including general-purpose ones as well as ones that
are part of web-application frameworks). How is a poor web framework to
make both groups happy (me on one side, all the rest of the world on the
other;-) without becoming ridiculously complex and ungainly?
Alex
Mar 28 '06 #2

P: n/a
walterbyrd wrote:
Way back when, I got a lot of training and experience in highly
structued software development. These days, I dabble with
web-development, but I may become more serious.

I consider php to be an abombination, the backward compatibility issues
alone are reason enough to make me hate it. Rail looks promising, but
it's difficult to find inexpensive hosting that supports rails.

I like python much better, but I'm not certain it's as well suited for
web developement.
It is. Much more than PHP.

The problem then is: which solution/framework. And there quite a few
Python web developpment solutions...
I'm not sure how th e apache module thing works.
It exposes most of the Apache API to Python, and provides hooks to take
control over request processing.
I am
using shared hosting, they provide python, but I'm not sure how limited
I'll be.
You can bet it'll be plain old cgi - possibly with an outdated Pyton
version.
Ideally, I would like to be able to develop a database driven web-app,
in much the same manner as I could develop an ms-access app. As much as
I dislike msft, I have to admit, an ms-access app can be put together
quickly, without any steep learning curve.

I've been looking at python web frameworks, and I'm not sure what to
think. It seems like these frameworks would allow me to do a lot of
work, with a small amount of code, but the learning curve seems very
steep.
Which frameworks have you looked at ?
I wouldn't even mind the steep learning curves, so much, except, it
seems to me that anything developed with one framework, would not work
with another.
heck, this is true of all frameworks ever (web or not, Python or not).
So if I changed my mind about which framework, I'd have
to start all over again - re-learning everything, re-writing
everything. Of course, everybody says their framework is the best. But
how can I know for sure?
Trying them ?
I don't have time to try them all.


Then only try the ones that *may* fit your needs !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Mar 28 '06 #3

P: n/a
> You can bet it'll be plain old cgi - possibly with an outdated Pyton version.

I think you are right. In practical terms, what does that mean? Will I
not be able to use modules? Will I not be able to use frameworks?
Which frameworks have you looked at ?


django, turbogears, cheetah, cherrypy, . . .

By "looked at" I mean I read up on them, a little. I have not tried any
of them.

Mar 28 '06 #4

P: n/a
As far as languages go, Python seems a far better choice than php or
perl based solutions. I haven't tried Ruby - so I can't comment.

The Zope framework for python has been remarkably productive for me
both with and wtihout plone(CMF modules and a look and feel on top of
Zope). The documentation is improving, but I can's say the situation
is good. In truth, Zope knowledge is zope specific (at least I haven't
found it useful) and it was a bit of a transition coming from a j2ee
background.

I didn't find the learning curve to be very steep, but the path is
covered in brambles - haha. Mostly due to the fast pace of
development.

btw, I am not a zope person or a plone, person - I have however used
both solutions to develop some pretty nifty sites faster than anything
else I have used. Even through the "gettting to know you phase" So
I'm a pretty big fan. That being said, Zope is it's own universe of
ideas, and a lot of them seem "odd". As far as hosting, I also know
where Zope/Plone hosting from 7.95 a month - although the host doesn't
list it on their ads, they do use and host it.

Mar 28 '06 #5

P: n/a
ak*********@gmail.com wrote:
As far as hosting, I also know
where Zope/Plone hosting from 7.95 a month - although the host doesn't
list it on their ads, they do use and host it.


Which host would this be? I'm currently exploring some options for getting
a Zope site hosted.

Thanks much.
--
Steve Juranich
Tucson, AZ
USA

Mar 28 '06 #6

P: n/a
walterbyrd <wa********@iname.com> wrote:
Ideally, I would like to be able to develop a database driven web-app,
in much the same manner as I could develop an ms-access app. As much as
I dislike msft, I have to admit, an ms-access app can be put together
quickly, without any steep learning curve.


Look at django then. It excels (IMHO) at this interfacing to an SQL
database. Its admin interface is all you'll ever need for trusted
data entry, and you won't have to write any code at all for it.

We're currently converting a twisty mass of perl code which we can't
maintain any more into a django site, and we've been monstrously
impressed!

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick
Mar 29 '06 #7

P: n/a
walterbyrd wrote:
You can bet it'll be plain old cgi - possibly with an outdated Pyton version.
I think you are right. In practical terms, what does that mean? Will I
not be able to use modules? Will I not be able to use frameworks?


It means that you will be limited to what can run with cgi and the
installed Python version. But instead of wondering, why don't you check
this out with your hosting company ? And if it appears that Python
support is too limited, you can also change for a more Python-friendly
host...
Which frameworks have you looked at ?
django, turbogears, cheetah, cherrypy, . . .


cheetah is a templating system, not a framework. Django needs
mod_python. Turbogears needs Cherrypy, which is itself a web server - so
it's not sure you'll be able to run it, depending on your hosting.

Anyway - I'm actually developping an app with Django, I have also played
with Turbogears (not stable and documented enough by now to be used in
production IMHO, but definitively very exciting) and Cherrypy, and I
certainly wouldn't qualify the learning curve for any of them as 'steep'.
By "looked at" I mean I read up on them, a little. I have not tried any
of them.


Maybe you should ?

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Mar 29 '06 #8

P: n/a
ocssolutions.com offers hosting solutions and will host Zope

Mar 29 '06 #9

P: n/a
Alex Martelli wrote:
I've never seen an "object-relational mapping" (technical
term for cruft that tries to avoid people having to learn and use SQL)
which doesn't drive me into a murderous, foam-at-mouth rage in a very
short time -- I WANT my SQL, I LOVE SQL, it's WAY more powerful
and suitable for access to data than all those simulated "OO DB" people
lay on top of it
How refreshing to discover I'm not the only person on earth who feels this
way.
(of course, that does depend on having a REAL
relational DB underneath, not, say, MySQL;-).


Well, you lost me there ... I prefer MySQL to the alternatives, but I still
feel validated :-)
Jeffrey
Mar 29 '06 #10

P: n/a
Jeffrey Froman <je*****@fro.man> wrote:
Alex Martelli wrote:
I've never seen an "object-relational mapping" (technical
term for cruft that tries to avoid people having to learn and use SQL)
which doesn't drive me into a murderous, foam-at-mouth rage in a very
short time -- I WANT my SQL, I LOVE SQL, it's WAY more powerful
and suitable for access to data than all those simulated "OO DB" people
lay on top of it


How refreshing to discover I'm not the only person on earth who feels this
way.


Hey, there's two of us, if this was Italy we could found a new political
party!-)

(of course, that does depend on having a REAL
relational DB underneath, not, say, MySQL;-).


Well, you lost me there ... I prefer MySQL to the alternatives, but I still
feel validated :-)


Lots of people I respect like MySQL, I just can't see _why_ (compared,
for example, to PostgreSQL). I guess our new party will have two rival
currents from the start (how nostalgically Italian!-)...
Alex
Mar 29 '06 #11

P: n/a
Steve Juranich wrote:
ak*********@gmail.com wrote:
As far as hosting, I also know
where Zope/Plone hosting from 7.95 a month - although the host doesn't
list it on their ads, they do use and host it.


Which host would this be? I'm currently exploring some options for getting
a Zope site hosted.


Virtual servers is getting cheaper and cheaper. That's obviously
a viable way to host Zope, if you don't mind being your own sysop.
Mar 30 '06 #12

P: n/a
Actually I recently went from a managed hosting to a virtual host via
XEN, it's been great value for the cost

Mar 30 '06 #13

P: n/a
I am presently looking at a commercial product called dbqwiksite. I
generates php code.

I know that sounds lame, but the demos were impressive.

If I could get the product to work like they show in the demos it would
be great.

It uses ODBC to connect to a mysql database; but I can't get it to work.

Mar 31 '06 #14

P: n/a
I am presently looking at a commercial product called dbqwiksite. I
generates php code.

I know that sounds lame, but the demos were impressive.

If I could get the product to work like they show in the demos it would
be great.

It uses ODBC to connect to a mysql database; but I can't get it to work.

Mar 31 '06 #15

P: n/a
> For example, I've never seen an "object-relational mapping" (technical
term for cruft that tries to avoid people having to learn and use SQL)
which doesn't drive me into a murderous, foam-at-mouth rage in a very
short time -- I *WANT* my SQL, I *LOVE* SQL, it's *WAY* more powerful
and suitable for access to data than all those simulated "OO DB" people
lay on top of it (of course, that does depend on having a REAL
relational DB underneath, not, say, MySQL;-). Other people disagree
very, very deeply with my preferences (as proven by the existence of a
begazillion ORMs, including general-purpose ones as well as ones that
are part of web-application frameworks).


I for one don't have any particular love for SQL. For most purposes I
don't want to be bothered with its details. However, I am disillusioned
with ORMs. With SQL and old school database management, I had tools
such as QBEs, ERD managers to visually manage much of the details (I
perform better with pictures than text) and even if others disagree, it
worked well for me. Now with ORMs, I am back to code again. Granted, it
appears cleaner most of the time but I want to be able to not see it at
all.

Java ORMs are begining to get a lot of these tools now. But I have been
cautious to dip my toes in these cold (verbose, XML infested) waters so
far.

Mar 31 '06 #16

P: n/a
Ravi Teja wrote:
... I've never seen an "object-relational mapping" (technical term for
cruft that tries to avoid people having to learn and use SQL) which
doesn't drive me into a murderous, foam-at-mouth rage in a very
short time -- I *WANT* my SQL, I *LOVE* SQL, it's *WAY* more powerful
and suitable for access to data than all those simulated "OO DB" people
lay on top of it....


I for one don't have any particular love for SQL. For most purposes I
don't want to be bothered with its details. However, I am disillusioned
with ORMs. With SQL and old school database management, I had tools
such as QBEs, ERD managers to visually manage much of the details (I
perform better with pictures than text) and even if others disagree, it
worked well for me. Now with ORMs, I am back to code again. Granted, it
appears cleaner most of the time but I want to be able to not see it at
all....


But what you overlook is SQL's strength:

SQL can be translated into _very_ efficient query plans w/o changing
the SQL. SQL's query optimizers (more properly, de-pessimizers) give
performance which can be tuned w/o touching the SQL. SQL, a language
which is truly ugly, not quite standardized, and otherwise quite clunky,
does manage to let you say more of what you want without specifying how
to get it. This separation of result spec from query plan is what makes
makes those optimizers work. The ORMs put objects on top of the DB, but
in a way that either (A) violates the object model in that everything
must be of the _same_ type in a table (good-bye duck-typing), or
(B) gives up on most any attempt to get optimized access -- the DB
becomes a persistent store, without the normal SQL feature of "our DB
admin can tune this up to fly like a peregrine in full stoop." A
query planner for well-insulated objects just doesn't have enough
information about what it can and cannot rewrite, so it doesn't know
how to estimate how much I/O one plan will cost as opposed to another.

--Scott David Daniels
sc***********@acm.org
Mar 31 '06 #17

P: n/a
Agreed. Mine was hardly a complete list.

Another bit I lost is keeping data operations close to the database. I
am more likely to use multiple languages/frameworks over the same
database than change databases for the same application. I actually
prefer functions and procedures within the DB (even if I have to use a
non-standard language extension) than implementing them in multiple
clients (No, I don't want to toss in middleware unless I have to).

Apr 1 '06 #18

P: n/a

But what you overlook is SQL's strength:

SQL can be translated into _very_ efficient query plans w/o changing
the SQL. SQL's query optimizers (more properly, de-pessimizers) give


Premature optimization is the root of all evil.

On the top level of an appliciation the goal is to only have problem or
domain specific code.
Middelware or ORM is a way to this goal because it encapsulates and
hides the technical details of persistence and helps for cleaner code.

--
Mit freundlichen Grüßen,
Ing. Gregor Horvath, Industrieberatung & Softwareentwicklung
http://www.gregor-horvath.com
Apr 1 '06 #19

P: n/a
Gregor Horvath wrote:
But what you overlook is SQL's strength:

SQL can be translated into _very_ efficient query plans w/o changing
the SQL. SQL's query optimizers (more properly, de-pessimizers) give


Premature optimization is the root of all evil.

On the top level of an appliciation the goal is to only have problem or
domain specific code.
Middelware or ORM is a way to this goal because it encapsulates and
hides the technical details of persistence and helps for cleaner code.

Using a relational DBMS is most definitely _not_ premature optimization.
A relational system provides a way to store data so that it is later
possible to go back into your DBMS setup and improve the performance
of your program _without_changing_the_program's_code_. The ORM
structure prevents this ability by abstracting away the meaningful
structure. The database structures built are as good a DB organization
as code generated by code generation programs: the meaning is obscured,
and the generated (structure / code) is hard to work with.

--Scott David Daniels
sc***********@acm.org
Apr 1 '06 #20

P: n/a
Scott David Daniels schrieb:
Using a relational DBMS is most definitely _not_ premature optimization.
A relational system provides a way to store data so that it is later
I did not mean that using a relational DBMS is premature optimization
but not using a ORM because of performance considerations is one .

If it turns out that the ORM is a performance problem you can always
tune it afterwards. (probably by the DBMS setup, indexes etc.)
structure. The database structures built are as good a DB organization
as code generated by code generation programs: the meaning is obscured,
and the generated (structure / code) is hard to work with.


Its just a layer and therefore the endresult is SQL much the same as the
one you would hand code. (and you still can use direct SQL if you like
with most of them)

In any way you have to bridge the logical gap between the relational and
the object data model in your programm.
So you will end up in building a layer between your persistence code and
your problem and domain specific application code, so what you are
actually doing is writing an ORM.

Not reinventing the wheel every time and using a existing one is IMHO a
better approach.

--
Mit freundlichen Grüßen,
Ing. Gregor Horvath, Industrieberatung & Softwareentwicklung
http://www.gregor-horvath.com
Apr 2 '06 #21

P: n/a
Gregor Horvath wrote:
Scott David Daniels schrieb:
Using a relational DBMS is most definitely _not_ premature optimization.
A relational system provides a way to store data so that it is later
I did not mean that using a relational DBMS is premature optimization
but not using a ORM because of performance considerations is one .


Whether or not to use an ORM might be a fairly big design decision, and
a part of the entire approach to your data handling. For some kinds of
data and some kinds of applications, it will drastically reduce your
flexibility in how you can conveniently deal with the data.

Object oriented design and programming, is often very helpful, but it's
not the only approach you can take to solving a problem in software, and
I'm not sure it's always the best approach...

Using an ORM means that you are making it much more difficult to use the
full expressiveness of SQL. On the other hand, using the full
expressiveness of SQL might make it much more difficult to use your data
in an object oriented way... You have to weigh the pros and cons
depending on the situation.

I'm sure different ORMs might be more or less limiting on SQL. I suspect
that this depends on how well the designer of the ORM knows SQL. I guess
the problem is that those who are best at SQL and most capable of
writing a non-limiting ORB are fairly good at working without an ORM, so
it's the guys who don't really understand and appreciate the strengths
of SQL that designs the ORMs... :)
If it turns out that the ORM is a performance problem you can always
tune it afterwards. (probably by the DBMS setup, indexes etc.)
To a large extent, use of ORMs and a proper OO design, means that you
move a lot of logic from the the DB and the SQL layer up to the Python
(or whatever language you use) layer, and there are efficient SQL
solutions you simply can't reach in that way.

As a simple example, the natural way to calculate the averages of an
attribute in a set of object in an OO system is to iterate over the
objects, get the value, add up a sum, count the objects as you iterate
and divide the sum with the count once you were done iterating. It's
very simple and straight forward, and often magnitudes slower than the
corresponding obvious SQL solution.
Its just a layer and therefore the endresult is SQL much the same as the
one you would hand code. (and you still can use direct SQL if you like
with most of them)
That's a joke, right? It might be much the same as *you* would have hand
coded, but perhaps very different from what *I* (and I suspect Scott)
would have coded.

With different approaches to your design, you solve problems in
completely different ways. Different languages lend themselves to
very different design approaches. The distinction between declarative
and imperative languages is pretty big, as is the more concrete ways
to actually work with data in Python and SQL.

SQL is a really stupid language in many ways. It's pretty useless
without a good partner, such as Python, and even considering its limited
perspective as a language for querying and manipulating relational
databases, I think it could have been designed so much better. I can't
see any intelligent reason not to provide the kind of abstractions that
function calls provide for instance. The amount of repetition in SQL
code in large database applications is appalling.

Still, there are applications where it's widely superior to any really
existing alternatives, and it goes far beyond manipulating or fetching
individual records in tables.
In any way you have to bridge the logical gap between the relational and
the object data model in your programm.
Certainly.
So you will end up in building a layer between your persistence code and
your problem and domain specific application code, so what you are
actually doing is writing an ORM.
Well, I wouldn't say it's an ORM unless it tries to be generic in some
way. In many cases, this mapping is fairly trivial. I once used
SQLObject for a whisky tasting database web app, and I think it made
life easier for me than raw SQL would have been, but that was a small
system where it was more important to make development fast than to make
the end product fast and robust.
Not reinventing the wheel every time and using a existing one is IMHO a
better approach.


Well, as usual... That depends... For each project you have to decide
how well different available alternatives fit your actual requirements.
If there's an ORM that fit yours, fine. No such external product would
be able to handle the applications I work with right now. The kind of
"conventional" use of SQL in ORMs simply won't work for our needs for
several reasons.

For us, and ORM simply can't solve the problem. For others, it's
overkill.

As I said, ORMs have their uses, but it seems to me that a reason for
many people to use ORMs is to avoid having to properly understand the
way relational databases work, and that means they will never use the
database really well. I'm pretty certain there are cases where it's
better with an ORM and a mediocre use of a database than no ORM and a
complete mess, but that's not the kind of applications or developers I
like to work with.
Apr 11 '06 #22

P: n/a
Magnus Lycka schrieb:
As I said, ORMs have their uses, but it seems to me that a reason for
many people to use ORMs is to avoid having to properly understand the
way relational databases work, and that means they will never use the


So is the reason for using Python for many people to avoid having to
properly understand the way a von Neumann architecture (or Assembler) works?

--
Mit freundlichen Grüßen,
Ing. Gregor Horvath, Industrieberatung & Softwareentwicklung
http://www.gregor-horvath.com
Apr 12 '06 #23

P: n/a
Alex Martelli wrote:
Jeffrey Froman <je*****@fro.man> wrote:
Alex Martelli wrote:
I've never seen an "object-relational mapping" (technical
term for cruft that tries to avoid people having to learn and use SQL)
which doesn't drive me into a murderous, foam-at-mouth rage in a very
short time -- I WANT my SQL, I LOVE SQL, it's WAY more powerful
and suitable for access to data than all those simulated "OO DB" people
lay on top of it

How refreshing to discover I'm not the only person on earth who feels this
way.


Hey, there's two of us, if this was Italy we could found a new political
party!-)


Me too - I rather prefer using SQL to ORMs, *but* my basic reason is
that I find it ridiculous for python ORMs to claim they lower sql/python
impedance while they lead away from the python construct that's the
obvious fit in the role of sql representative : I mean generator
expressions.

And OK, generator expressions aren't quite as powerful as SQL, but...
well, maybe they can yet be perfected.
Apr 12 '06 #24

This discussion thread is closed

Replies have been disabled for this discussion.