The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
You make it sound as if you will never, ever, accept any sort of critisism of your favorite programming language...
First: Any programming language can be (ab)used to write really obfuscated code. Some programmer subcultures tend to write unreadable code, whatever language is used, but if that is PHP, it leads other people to associate unreadable code with that language. Furthermore, if most subcultures (ab)use the language that way, the few programmers that use it properly might not be strong enough to save the reputation of the language.
Second: If you don't know/understand the "philosophy" of a language (or of whatever) - the rationale for the mechanisms offered, the inteded usage pattern - then it always looks messy. To the guy who understands the reasoning behind the design, and is trained in the same thought patterns as the programmer of the obfuscated code, the code is not at all obfuscated. Nine out of ten times claims of "obfuscation", "unreadable" or "messy" code (or coding style) really says "I am lacking the background to understand why it is done that way".
Surely, some philosophies are easier to grasp than others, and some rather elegant programming languages failed in the marketplace because its protagonists were mostly programmers rather than teachers (of the philosophy of the language). Some languages excel in clean and simple basic mechanisms but rely on the programmer to handle any sort of abstractions, which some programmers do better than others. (Everyone understands that we need higher basic abstractions than Turing machine marks, but many lisp programmers don't understand that we need higher basic abstractions than car and cdr.) And then, some languages offer mechanisms that is an open invitation to obfuscation. My favorite example is Fortran 'return k': A function can take (numeric) labels as arguments. 'return 4' means: Do not return to the statement following the function call, but to the label supplied as the 4th argument. More recent languages provide several comparable mechanisms, such as switch fallthrough and address-of-operators that might have null effect, but none as grave as 'return k'.
I have worked some, but not much, with PHP. It will never become my favorite language, but I would never agree than you can't write well structured, readable code in PHP. I don't think obfuscated code is a bigger problem with PHP than with, say, classical C.
First: Any programming language can be (ab)used to write really obfuscated code.
Some programmer subcultures tend to write unreadable code, whatever language is
used, but if that is PHP, it leads other people to associate unreadable code
with that language. Furthermore, if most subcultures (ab)use the language
that way, the few programmers that use it properly might not be strong enough to
save the reputation of the language.
And some just come that way out of the box. :p
I like this:
IX1 D IXDUP ;22*130
F DDUCRFE=0:0 S DDUCRFE=$O(^DD(DDUCFI,0,"IX",DDUCXREF,DDUCRFI,DDUCRFE)) Q:DDUCRFE'>0 D
. I $D(^DD(DDUCRFI,DDUCRFE,0))[0 D WFI W """IX"" Subscript: "_DDUCXREF_" " D WFE,WMS D:DDUCFIX IX2 Q
. I $D(^DD(DDUCRFI,DDUCRFE,1,0))=0,$D(^DD(DDUCRFI,DDUCRFE,1))=10 S:DDUCFIX ^DD(DDUCRFI,DDUCRFE,1,0)="^.1"
. S DDUCRFE1=0,DDUCRFEX="" F S DDUCRFE1=$O(^DD(DDUCRFI,DDUCRFE,1,DDUCRFE1)) Q:DDUCRFE1'>0 S DDUCRFEX=$G(^(DDUCRFE1,0)) I $P(DDUCRFEX,U,2)=DDUCXREF K DDUCRFEX Q
. I $D(DDUCRFEX) W !?5,"Cross-reference logic is missing for """,DDUCXREF,""" x-ref" D:DDUCFIX IX2 Q
K DDUCRFE1 Q
Well, when I say "like", I mean No, you will never ever ever get me to program with m-code.
Another day, another "mock the poster" post. This time with the added benefit of mocking PHP as well. While you're at it, my shirt's particularly loud today - perhaps you'd like to go for the tri-defecta.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington