[ubuntu-za] Database Problems

[Lee Sharp]

Jonathan Hitchcock wrote:
> Hi,
> 
> I figure it's about time I take some of the strain off poor Raoul.
> 
> On Mon, Jan 25, 2010 at 5:43 PM, Lee Sharp <leesharp at hal-pc.org> wrote:
>> Bah...  Real men use perl! :)
> 
> If you're going for obfuscated and outdated, why be so half-hearted
> and stop at perl?  Don't you mean assembly?  Punchcards?

Actually, I still use quite a bit of perl.  It is both stable, and fast. 
  Faster than php, and much faster than ruby.  Python can beat it in 
some things, but not many.  Of course, C and assembly are both faster 
than perl. :) Horses for courses.

>> However, you shooting down php because it is easy, seems silly as the
>> person in question is a beginner.
> 
> The problem is not that it is 'easy', the problem is that it lets you
> do anything without much difficulty.  These may sound like the same
> thing, and they may sound like good things, but consider what would
> happen if we were talking about cars.  A car that let anybody get in
> and scream off down the road at 180km/h just by pressing a button
> would be a dangerous, dangerous thing.

I miss my BMW. :)

> Python is actually an incredibly easy language, too, but in order to
> redefine the core functions, a programmer would have to access some
> internals - this is a very good thing, because most people would never
> want to redefine them, and we don't want beginners doing it by
> mistake.  It's not hard to do, but you have to know what you're doing
> - just like driving a car.
> 
> A final point on the "easy" thing - you don't want to be able to do
> everything as a beginner - you want to ease into it slowly, building
> up your knowledge and abilities, otherwise you are just flooded and
> start doing things you probably shouldn't.

Good points.  However, php is included in the lamp stack, and the others 
have to be installed.  Not a major problem, but not trivial. (As the 
pgSQL thread is proving)

>> And Security being a major concern for an internal system is also a bit overboard.
> 
> It's not just security.  That is just one example of the way in which
> PHP encourages bad practices.  Take "register_globals", for example -
> I know this is now off by default, but it is an instance of the sloppy
> way which PHP encourages its users to think.  When it is turned on, it
> creates a whole bunch of variables in the global namespace with values
> assigned by outside users.  This is the most ridiculous,
> unpredictable, insecure feature you could think of, but a lot of PHP
> programmers complained bitterly when it was turned off, because it was
> "much harder" to write code, and so on.  If you allow users to start
> thinking like that, they will never develop a proper sense of how
> things should be done.

I agree that it never should have been there.  But removing it broke 
things.  Taking something away will always be more painfull than not 
giving it to them in the first place.

>>  After all, ruby won't fix leaving the database open to "world" which is what most beginners do
>> when they need to access it from the system next door.
> 
> That is more of a sysadminny sort of fault, and is obviously going to
> be a problem no matter what language you use, so it is pointless
> talking about it.  Since we are comparing languages, you need to talk
> about problems that arise directly from writing bad code, and you will
> find that PHP leaves a lot more doors open than other languages.

I snipped the example for brevity. (And the fact that many will still 
not get it..)  It is a good point, but you are still only secure as your 
weakest like.  That may be php, but it also may be the "sysadminy 
things."  I still think php is a good compromise language for a quick 
internal app.  Not so good for an outward facing website.

			Lee