Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

PHP

Name: Anonymous 2013-07-09 13:31

Since most of the /g/tards are presumably gone by now. I want to hear your PHP conspiracy theories again, /prog/. They're a bit intriguing.

Name: Anonymous 2013-07-09 17:31

PHP > Python

Name: Anonymous 2013-07-09 18:01

Python > PHP

Name: Anonymous 2013-07-09 19:30

>>2
Are you insane

Name: Anonymous 2013-07-09 20:01

Most of the pitfalls of PHP are easily nullified by using a good framework.

Name: Anonymous 2013-07-10 2:00

What are those pitfalls? And how do frameworks help to get around them?

Name: Anonymous 2013-07-10 2:06

Name: Anonymous 2013-07-10 3:26

The Zend thing is run by a Jew.

Name: Anonymous 2013-07-10 4:25

>>6
Take for example the argument made in the "fractal of bad design" blog post where it talks about SQL sanitation and why using mysql_real_escape_string() is unsafe and poor design. This is an argument made against an archaic part of PHP, you don't even need to use a framework for SQL sanitizing. There's a class called "PDO" that's a part of the standard library that allows you to bind variables to a SQL string, escaping them in the process. But a framework makes it even easier. Take Laravel as an example, running DB::table('touhous')->where('name', 'LIKE', 'Genjii')->first(); produces select * from `touhous` where `name` like 'Genjii' limit 1, all variables escaped, no possibility of SQL injection.

In fact most of the arguments in that article are made against archaic use of PHP. It's like the writer thinks PHP hasn't progressed since 2000.

Name: Anonymous 2013-07-10 4:29


(sql "touhous"
  (where "name" (like "Genji")
  (limit 1))

Name: shit shit shit 2013-07-10 4:31


(sql "touhous"
  (where "name" (like "Genji"))
  (limit 1))

Name: Anonymous 2013-07-10 5:10

>>9
I can see you're trying to allure the Nikita to liking PHP by using touhous but PHP is still not LISP and thus is still a disgusting lovecraftian chimera of algol/undefined shit + COBOL + javashit.

Meanwhile  >>10/>>11 has the obvious Right Idea.

Name: Anonymous 2013-07-10 9:03

>>9
Not if you escape the input variables by assigning them as functions. With that, you have more than one way to mess with the system, whether you escape or not PDO's ``sanitizing'' functions. Like global_variable = Off will save you if dynamic scope is enabled.

Name: Anonymous 2013-07-10 18:29

Perl is what you get when Larry Wall designs a language.
PHP is what you get when Larry Wall's shit designs a language.

Name: Anonymous 2013-07-10 18:35

PHP is defective by design. There is simply no apology for PHP flaws:
1. Inconsistent lexical scope, where assignment acts as declaration and all variables have function scope, serving as major source of PHP bugs and impeding functional programming, because in PHP anonymous functions require awfully verbose constructions, like `function($y) use ($x) {`. Compared to Scheme/Racket, which uses `let` for everything, PHP's global scope is completely separate entity and requires explicit use of `global` keyword to access variables. PHP has no package system, so global namespace becomes unmanageably cluttered. Moreover, referencing nonexistent variable isn't even an error, so any typo produces untraceable bug. Finally, PHP allows non-string variable names: $a=array();$$a='broken'; print ${array()};
2. Inconsistent standard library: for example, shuffle(123) would return false, instead of logging error and halting execution, before more damage is done; same for accessing array beyond bounds, which is even worser than C/C++, where such access at least produces segmentation fault. Despite null also being valid JSON object, json_decode returns null on error, welcoming bugs if user forgets json_last_error. Functions sizeof, count `print` and `echo` duplicate functionality, while `print` for some reason always returns 1. Moreover, PHP arrays are implemented as hash tables, so there is no way to get their real size or iterate by indices at all. PHP standard library basically indulges hard to trace bugs, exploits and backdoors, because almost any PHP feature is fragile and poses security danger. Inconsistent function naming: underscores (isset vs is_null), abbreviations (call_user_func vs create_function), uncertain parameter order (in_array($needle, $haystack) vs strpos($haystack, $needle)), redundant aliases (disk_free_space vs diskfreespace, strcmp vs ==), misleading names (addslashes and stripslashes, which deal with backslashes). PHP's one unique operator is @ (actually borrowed from DOS), which silences errors.
3. Broken and non-portable type system: PHP stores integers in a platform-dependent format, usually 64-bit or 32-bit signed integer, equivalent to the C-language long type. Even worse: big integers are represented as floating point numbers, so 9999999999999999999==10000000000000000000. Confusing automatic type coercion, where FALSE=="", FALSE==0, array()==FALSE, array()!=0, "1e3"=="1000", "0x10"=="16" "a"+"d"==0, 123=="123broken", "4.2"=="4.20", "6"==" 6", "x"==0", NULL<-1, NULL==0. Be prepared to a lot of instant bugs, like if(strpos($h,$n)) {...}, because 0 gets converted to FALSE, behind your back. Due to broken `<` sorting is nondeterministic.
4. Inconsistent garbage collection, performed only when you tell PHP to do it or passing specific junctions. In some cases memory lost until program halts, which unnoticeable with small one shot page generation scripts, but poses a major handicap for general purpose programming using PHP, when code must run for days.
5. Discrepancy between literals and variables, growing from variables being objects themselves: given $a="foo", var_dump($a instanceof stdClass) works, but var_dump("foo" instanceof stdClass) produces error; same with array literals: $a[0] works, but array(1,2,3)[0] fails. Array assignment always involves deep copying, which is confusing and bad for performance. Function may be called via variable, containing function name, leading to badly designed and insecure code, welcoming exploits, especially when function name comes from use input.
6. Fugly syntax: every PHP variable requires `$` prefix, which looks even scarier when combined with `&`, required to pass objects by reference, so be prepared for quirky perl-ugly code, like &$o[i++] and !--$$i. The syntax has 1375 conflicts and 6 unused terminals, reflecting that implementors had no understanding of LALR(1) parser generators or robust language design in general, because with that many conflicts, the chances are slime that the parser is actually doing 100% of what was intended: for example "a".2 produces an error, but "a"."2", "a" . 2 and 1 . 2 parse as string concatenation, while 1.2 and .2 parse as numbers, worser 0x0+2==4, but 0x0+ 2==2 so meaning of operator depends on spaces around it.  Usual `{` and `}` braces can be interchanged with `:` and `endif;`, which is aggravated by the fact that PHP syntax treats { and ${ as separate tokens (T_CURLY_OPEN and T_DOLLAR_OPEN_CURLY_BRACES), making PHP syntax bigger and even less regular: PHP has around 70 keywords, including echo, eval and exit, which in well designed languages implemented as functions. Appending to an array is done with $foo[] = $bar.
7. No multithreading support possible, because PHP is full of global and implicit state. mbstring uses a global character set. func_get_arg and friends look like regular functions, but operate on the currently-executing function. Error handling have global defaults. register_tick_function sets a global function to run every tick.
8. When faced with criticism, all PHP apologists spit generic arguments, starting with banal ad-hominem, which speak for themselves: "all languages are turing complete", "languages are just tools", "no language is perfect", "good developers can write good code in any language", "PHP was never intended to solve problem X", "PHP isn't the problem, bad programmers are", "products X was built using PHP, so PHP is good enough", "there are two kinds of languages: the ones complained about and the ones nobody uses", "PHP is free, hosting is available, PHP programmers are cheap", "clients don't care what language is used", "PHP has great community, we are like family", "if you do X then problem Y would be less noticeable", and a myriad of variations. The best examples of PHP apologetics, like https://news.ycombinator.com/item?id=4177516 , contain gems in the lines of "Sometimes you don't care if a function succeeds" - in other words, PHP community doesn't care if their code succeeds.
9. PHP is Jewish language, developed by Israeli company with unclear agenda. It is entirely possible that PHP is just a trojan horse and real goal was to produce exploit-happy environment, which Israeli intelligence agencies could leverage to advance interests of Israel. Being originally a collection of CGI scripts designed for building a 'personal home page', PHP indulges messy, unmaintainable code: spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.

Name: Anonymous 2013-07-10 18:35

Very good article!... I agree, PHP may have its downfalls, but all can be resolved with good coding practices, and future releases.  -- Thomas Borzecki, professional Jew

Name: Anonymous 2013-07-10 20:04

Calling me retarded is an affront to the mentally challenged. My worldview is warped beyond reason. I have no education nor have I ever had stable employment. I spend most my time shitting up an anonymous textboard and blaming others for my miserable failure of a life.  -- Nikita Sadkov, professional Antisemite

Name: Anonymous 2013-07-10 20:14

>>17
Shalom, Hymie!

Name: Anonymous 2013-07-10 20:27

>>18
Do you sometimes regret fucking up your life so badly, Sadkike?

Name: Anonymous 2013-07-10 21:48

>>19
Shalom, Hymie!

Don't change these.
Name: Email:
Entire Thread Thread List