Andrew po-jung Ho wrote:
> Hi Thomas,
> I am most interested in your critique of interpreted languages in general.
>Considering that many web-sites rely on various scripting languages, what general
>weaknesses and vulnerabilities are you referring to? Since I am not a software
>engineer, are there references that I can read to learn about these obvious issues?
>I would rather be embarassed than be ignorant. Please help me.
Let's consider the architecture of a web-capable information system. THe following
elements are required:
- database/persistence
- business logic
- GUI front end
The business logic does all the computing work according to the semantic model it was
based on, typically an OOPL implementation of an OO model in UML or similar. Such a
model is the result of an ongoing requirements, analysis and design effort, and is the
repository for thinking about the semantics of the domain and the system.
The back-end does mainly high volume but fairly mindless data transformations
according to a fairly low level ER model, or else an object model (in the case of
object databases). The front end does data transformation to get data onto the screen,
and some more intelligent validation to take data in. Both front and back-ends may of
course have some very sophisticated processing in them to
achieve their ends, but neither are implemented at the level of the business model -
they work with technical concepts like "rows" and "input fields" rather than business
or domain concepts.
THere are many systems which only have a backend, a front end and nothing in between.
The problem with these systems is that the underlying business rules and object model
are implied in the GUI code and (typically) relational schema of the database; there
is no explicit place you can go to see the design model of the system. Consequently,
the whole process of maintenance and enhancement
must be done purely at the implementation level (maybe with a bit of help from ER
modelling tools) - there is very little possibility for any intellectual understanding
and modification of the system at a design level. As a result, such systems soon stop
being able to deal with changing requirements.
Now, in an information-rich domain like clinical medicine, where the numbers of
concepts are measured in the 100,000s, much of it highly structured, the need to be
able to reason about how such information is processed is paramount to a successful
system. It's a hard problem, there's no doubt about that. But in the long run, decent
business logic is what is needed (sorry about using the
word "business", but it's a standard in the oo literature; some people talk about
"domain" models, but they're not quite the same thing; anyway, it's nothing to do with
finance).
> >But for GUIs, add-ons, converters, maybe even the new Python (OO?) database, why
>not?
>
> But why? If interpreted languages are so unsafe, how can they be trusted to manage
>a "database"?
You won't find any major database server running purely as an interpreter - the
servers of Oracle, Sybase, probably every OO database are nearly all hand-coded C,
C++, and more recently Java. Some Smalltalk systems may be an exception here (but the
interpreter in that case is like the JVM - very low-level and not too inefficient). As
far as I know Postgres uses a server written in C. SQL
is often interpreted, but the job of an SQL interpreter is to translate an SQL
statement into a call in the database server C API.
All the "interpreted" stuff in Zope will be Python code running over the database
server, doing data transformation on database query results.
Now.... the question of suitability of Python for the GEHR kernel hinges on questions
like:
- performance
- solid type system
- decent OO modelling semantics (e.g. design by contract, genericity, MI, feature
redefinition, etc).
Python is not likely to come up to the mark required by certain classes of systems,
including GEHR. There is nothing wrong with Python (I am considering using it
actually), but it won't do the job in some cases.
> The reason why this issue is so critical for me is that OIO runs on Zope which runs
>on Python. If this is a terrible mistake, I like to know sooner rather than later.
>(Tim may have similar concerns since FreePM also runs on Zope.)
>
> There has been quite a bit of discussion over the issue of collaboration between
>projects. I feel that the first step is to air these differences in understanding.
>If nothing else, I know I will learn something. However, if you care to, it is
>possible that you can convince me to move OIO to Eiffel and merge it with GEHR.
Point 1: I am not sure you are doing anything wrong. I am certainly not criticising
your work. I have an idea that it can be integrated with a GEHR server, and OIO would
keep most of its current form (but I am currently working on pure supposition so
far!). You would probably find that some of the more difficult logic could simply be
passed off to the server, making OIO a bit simpler.
Overall, the addition of GEHR to OIO is really adding business logic server (or
middleware component, if you prefer) to OIO. THis might be more of an intellectual
leap than a technical one to deal with.
By the way, despite some of my comments, I have the greatest respect for people who,
with whatever experience, actually get down and do something active. I think we can
achieve something together; there is just a learning process required, and with that,
patience on both sides.
- thomas beale
