Marketing of D - article topic ideas?

[Robert Clipsham]

On 06/06/10 03:02, Nick Sabalausky wrote:
> "Robert Clipsham"<robert at octarineparrot.com>  wrote in message
> news:huembk$2660$1 at digitalmars.com...
>>
>> Being the only two languages I'd call myself fluent in, I'd definitely
>> call D easier to maintain than PHP... I guess this is easily debatable
>> though.
>>
>
> Easily debatable? Not without an existing brain injury ;)
>
> I've used a lot of different languages. PHP's maintainability is one of the
> worst I've ever seen. The whole design of it *begs* for bugs.

Or worse, security issues - heck, the examples on php.net are so easy 
for someone new to the language to use to introduce a large number of 
security issues with it's unbelievable. It doesn't take much to find a 
number of SQL injections in the code most PHP devs write - it's so easy 
to do! If only there were a language that made safe operations easy to 
do and harder more bug prone things harder to do :3

> Hell, PHP is the only (*cough*) modern (*cough*) language I can think of
> where bugs can actually be introduced without any programmer involvement and
> without even touching a single line of code. The sysadmin just needs to
> change any one of certain PHP server settings (or move the code to another
> server that isn't configured exactly the same), and suddenly random parts of
> the code are silently broken and the programmer is screwed.
>
> An old example is magic quotes - your code will magically (and silently)
> break if the setting is changed without adjusting the code to compensate.
> Yea, I know they're deprecated in PHP5 and removed in PHP6, but it's just
> one off-the-top-of-my-head example of a bigger theme:

My favourite is register_globals - not only does it introduce bugs, it 
allows for remote code execution! Gotta love that ;)

> It's standard practice by PHP's creators to toss in language-changing server
> settings, and without even having predictable defaults (the *defaults* can
> be configured. Seriously, WTF?). These settings often either can't be
> adjusted in the code itself (ex: magic quotes) or can only *sometimes* be
> adjusted in the code depending on how the server settings are configured (I
> think some session-management stuff falls into this category...and speaking
> of PHP's session-management...well, better *not* to speak of it). So not
> only does stuff change from one PHP version to another, but even within a
> *single exact* version of PHP you *still* have 2^^n number of what are
> essentially different languages, and no realistic way to work around it.

Fortunately you can detect what's disabled/how it's configured etc in 
the script, it means you have to write 1000LoC of checks etc before 
every php app you write if you want it to be supported by a selection of 
hosts. Refusing anything less than PHP 5.2 helps here, there's still 
loads of checks you've gotta do though. I generally find the best way to 
avoid bugs due to different configs/PHP versions is to use 
error_reporting( E_ALL | E_STRICT | E_DEPRECATED ); at the start of all 
my code, even that has to check the PHP version though thanks to 
E_DEPRECATED... and there'll still be some bugs that manage to slip 
through :3

> So to write good reliable code in PHP:

I was gonna make a witty remark here, I found it turning into a rant so 
I removed it though :3

> First, you have to have a deep understanding of every fucking setting
> offered by every version of PHP that you use. Of course, many of the
> important gotchas are completely undocumented and you have to go by hearsay
> and anecdotal advice. So good luck with that.

This is completely true. Using some kind of PHP framework usually solves 
this problem for you as they do all the checks etc generally, it's still 
not perfect though, and the developer still has to be aware of what the 
framework actually checks for.

> Then you have to identify which of those settings might cause problems
> depending on how they're set and make sure to set them properly at the start
> of every single page (not always easy when your "package" system is one step
> away from the C preprocessor).

If you can set them properly that is :3 Gotta hate safe mode/the ability 
of clueless admins to disable functions which don't pose any security 
vulnerability to the server but they're adamant they do.

> Then, for the ones you can't change (because of either your sysadmin or PHP
> itself), you have to find the common "safe" subset and not venture beyond it
> (Ex: goodbye '<%%>' and'<??>', it's'<?php ?>' or nothing). When there
> isn't a safe common subset you can rely on (ex: magic quotes) you have to
> detect the active setting (if possible) and adapt. Of course, even doing
> that isn't always possible.

trigger_error( "Your setup sucks, damned if I'm writing code that 
supports it :3", E_USER_ERROR );

I love not having to write commercial code where supporting idiots is 
mandatory, I'd rather not spend 90% of my time making sure my code works 
on different setups :3

> Then when the server's PHP is upgraded, you have to check everything all
> over again (or just pray). Oh, and did I mention sometimes the OS and
> OS-configuration abstractions leek? Needless to say, writing good reliable
> code in PHP is realistically impossible (frankly, I don't even bother to try
> anymore). And if you want to make a re-usable library...hah! Ha ha ha!! Ah
> ha ha ha ha ha!!!

Fat chance of that if they've got register_globals enabled or 
magic_quotes etc. You'll be lucky if they upgrade in a few years :3 
This said, there are people who are *that* stupid.

> So, PHP maintainability? Welcome to hell. PHP is evilness itself, given form
> as a programming language. Given a choice, I would seriously consider
> writing classic-ASP in VBScript on a WinME workstation running Microsoft Bob
> with an IDE that included Clippy if the only alternative was to do a big
> project in hand-written PHP.

I guess I'm lucky here, all the PHP I ever have to write now is 
supported by a framework/CMS that some guy who knows what he's doing 
made, I've yet to have any issues with it anywhere it's been run 
fortunately. I'd put money on this not being the case for most people 
though.

I would be curious as to how well D/FastCGI works, guess I'll have to 
have a play at some point.

Robert