"Robert Clipsham" <robert@octarineparrot.com> wrote in message news:huembk$2660$1@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.

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:

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.

So to write good reliable code in PHP:

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.

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).

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.

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!!!

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.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hu9fic$24ic$1@digitalmars.com...
>D is an extremely powerful language,

Like OxyClean! (?)

>  but when I read complaints and sighs about other languages, few seem
> to know that these problems are solved with D.

So will this snakeoil solve my rheumatoid arthritis?

> Essentially, we have a marketing problem.

Go (go pun intended) figure?.

>
> One great way to address it

Whoa, you presented a "hypothesis", and are now "embarking off on it" and soliciting others to do the same and take it for granted that your "hypothesis" (or whatever it was) is good. It's one thing to throw good money after bad. It's quite another to draw other people into your losing game.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hu9fic$24ic$1@digitalmars.com...
>D is an extremely powerful language, but when I read complaints and sighs about other languages, few seem to know that these problems are solved with D. Essentially, we have a marketing problem.
>
> One great way to address it is by writing articles about various aspects of D and how they solve problems, like http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/ which was well received on reddit.
>
> Anyone have good ideas on topics for D articles? And anyone want to stand up and write an article?
>
> They don't have to be comprehensive articles (though of course those are better), even blog entries will do.

I think you have and have had good intent (that is not necessarily a reality, just a hope, I don't trust anyone or believe anything). I don't diss you. If I had a compiler to build, I'd send out an RFP to you, maybe. If I had a "task" to fill that required a "language builder", I wouldn't call on you, knowing what I know about you and this place. I know you're old, so I won't task you with riddles, so I'll give that answer: "building a language", is not a task on a project manager's schedule.

You have kids (I hope!). I think you should put D in maintenance mode (like C and C++ are).

I think Walter has been doing a great job with D. I do not like all the choices he has made (I am more radical when it is about breaking old habits from C) but, overall, D is an admirable and well-balanced language. And dmd a quite nice compiler. I hope it will be on 64-bits asap.

I admire and use Walter's work.

eles

== Quote from ArnoldSSchwartz (asschwann@usenet.com)'s article
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hu9fic$24ic$1@digitalmars.com...
> >D is an extremely powerful language, but when I read complaints and sighs about other languages, few seem to know that these problems
are
> >solved with D. Essentially, we have a marketing problem.
> >
> > One great way to address it is by writing articles about various aspects of D and how they solve problems, like http://www.reddit.com/r/programming/comments/cb14j/
compiletime_function_execution_in_d/
> > which was well received on reddit.
> >
> > Anyone have good ideas on topics for D articles? And anyone want
to
> > stand up and write an article?
> >
> > They don't have to be comprehensive articles (though of course
those
> > are better), even blog entries will do.
> I think you have and have had good intent (that is not necessarily a reality, just a hope, I don't trust anyone or believe anything). I
don't
> diss you. If I had a compiler to build, I'd send out an RFP to you, maybe. If I had a "task" to fill that required a "language
builder", I
> wouldn't call on you, knowing what I know about you and this place.
I
> know you're old, so I won't task you with riddles, so I'll give that
> answer: "building a language", is not a task on a project manager's
> schedule.
> You have kids (I hope!). I think you should put D in maintenance
mode
> (like C and C++ are).

On 06/06/10 03:02, Nick Sabalausky wrote:
> "Robert Clipsham"<robert@octarineparrot.com>  wrote in message
> news:huembk$2660$1@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

Am 04.06.2010 01:58, schrieb Walter Bright:
> D is an extremely powerful language, but when I read complaints and sighs about
> other languages, few seem to know that these problems are solved with D.
> Essentially, we have a marketing problem.
>
> One great way to address it is by writing articles about various aspects of D
> and how they solve problems, like
> http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/
>    which was well received on reddit.
>
> Anyone have good ideas on topics for D articles? And anyone want to stand up and
> write an article?
>
> They don't have to be comprehensive articles (though of course those are
> better), even blog entries will do.

what about writing an "connect" example of D featureset usage in an C, or C++ and the way back - something that shows Ds interoperability - with some compiler (like intel/microsoft and borland) related tools, example what is needed to bring the different object-formats together

dennis luehring wrote:
>  with some compiler (like intel/microsoft and borland) related tools, example what is needed to bring the different object-formats together

I experienced a runtime access violation on Windows when interoperating with the DLL created with the MSVC, which attempted to callback DMD executable. Mingw32 GCC is doing well, however cannot interoparate with XPCOM. Unless I'm doing something wrong, crosscompiler interoperability is a problem for me, however such issue have other languages.

If there's a reference on how to face this kind of problems, I would be glad to have it, like other people which supposed to work with the D.


-- 
Alex Makhotin,
the founder of BITPROX,
http://bitprox.com

ArnoldSSchwartz wrote,

[nothing of value]

You just made me feel much less guilty that PHP's syntax turned me off back in my java days.

"Robert Clipsham" <robert@octarineparrot.com> wrote in message news:hufr5k$vnd$1@digitalmars.com...
> On 06/06/10 03:02, Nick Sabalausky wrote:
>
>> 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
>

Heh heh. "good reliable code in PHP" *is* a contradiction of terms, after all ;)

>
> 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.
>

As much as I prefer to write Haxe (and then compile it down to PHP), one of the [many] things that bugs me about Haxe is that it doesn't appear to do any of those checks automatically. Big missed opportunity there.

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

I've been positively salivating at the idea of combining D, FastCGI and a D-ified rails-like framework. Haven't gotten around to it though. Fortunately, I did recently find out that the hosts I'm currently using allow custom-made CGI. Unfortunately, I can't use FastCGI on them, although I've been getting so fed up with PHP lately (both the PHP language and the PHP platform - Haxe only sheilds you from [parts of] the language, not the platform), that I think I can live perfectly happily without FastCGI.