Someone who sees that PHP is TRWTF
-
Epic troll is epic.
Hi to all of you,
first I want to apologize for may bad English,
.. . .
I write because I feel that that the way how you see your own product PHP
is totally wrong. I do not mean with it that the construction of the
language is wrong.Your basic aproach is wrong.
PHP is a server side programming language. That means that the most work
what PHP have to do is to be the boss of the data servers and handle the
data.Create database or tables or records, edit, delete and read and write
them.And where is your fantastic programming language so incredible lousy that
me, I am since 35 years a database programmer, just shake my head???Exact in this operations!!!
I know that it is for free and I can not tell you how much I value your
work on it, but all of you, WAKE UP!!!!You sent the handling of records from modern handling via recordsets back
to computer stone age. It is a torture to use PHP without tools (and they
are lousy too) for database operations.I can give you a example:
It is in PHP a lot of work to just read the next record in a table.
With ADO is it just nextrecord().
The PHP way is a insult to the modern world of programming.
Maybe you should consider to write internal functions for the record
handling which do take all the sql waste of time away from the programmer
and create just short command words that the developer can use them.This would be a "small step for you but a huge leap for mankind!".
And you would finally win the race in the language battle.
I am sorry that I write it so harsh, but PHP is for me the definition of
server data handling and exact there you fail in a big way.All the programmers around the world reinvent every time the wheel new?
Have this really to be?
In my opinion should exist commands like:
recordnew(table)
recordread(id, table)
recordwrite(id, table)
recorddelete(id, table)
recordprev(currentrecord, table)
recordnext(currentrecord, table)This is the minimum what I expect from a program language in the year 2015.
This should include already the ajax handling and all the other actions
that are needed to get or view or write the data.It should also be included table locking and record locking, if needed.
And special commands for reading multiple records for paginations.
And also for a easy way to edit a record in this paginations set (page,
count) and write this back to the MySQL database or whatever database is
used... . .
You are so focused to make PHP better and better that you just forgot to
upgrade the basic commands.A programmer in the year 2015 should not need to fetch records and do this
with program code line by line. This was in the year 1982 the case
.. . .It reminds me on hotels which always renovate the lobby but never the rooms
for the guests... . .
I am sorry to be so critical, but this was cooking me since long time.
I am database programmer for international police organizations.
Please keep my name confident.
>
> Frank Liebl, GER
> KTTL - Royal Thai Police
> Federal Police, Headquarters
> Bangkok 10330, Phatumwan
> T H A I L A N D
> Phone: +66 90 243 7837
> Email: frankybkk@gmail.com
> Line: scoobeedo
> Facebook: scoobeedo cool
> Web: www.scoobeedo.com
>
-
God dammit why did he have to be a Microsoft programmer?
-
The poster critiques PHP's awful database handling and then holds up ADO as the Right Thing?
-
> It is in PHP a lot of work to just read the next record in a table.
I know I like to give PHP shit, but it's not like
$row = $statement->fetch()is exactly hard.They know that PHP actually standardized the way to do DB calls like 10 years ago, right? Right?
-
And where is your fantastic programming language so incredible lousy thatme, I am since 35 years a database programmer, just shake my head???
I agree with this sentiment entirely.
-
The poster critiques PHP's awful database handling and then holds up ADO as the Right Thing?
What's wrong with ADO?
Them's fighting words.
-
What's wrong with ADO?
Generally speaking, if you are explicitly iterating through a recordset, you're doing it wrong.
Admittedly, Java is just as bad about, but Java is shit.
-
I write because I feel that that the way how you see your own product PHPis totally wrong.
Wrong forum, methinks.
-
Generally speaking, if you are explicitly iterating through a recordset, you're doing it wrong.
So what you do use instead? Linq-To-SQL? So instead of explicitly iterating through a recordset, you implicitly do it BECAUSE THAT IS WAY DIFFERENT MAN!
-
Maybe he uses... shudder Entity Framework.
I have no idea if Entity Framework is bad, I'm just going with it.
-
I'm 90% sure Entity Framework uses ADO.
-
I don't know much about LINQ, TBH.
So instead of explicitly iterating through a recordset, you implicitly do it BECAUSE THAT IS WAY DIFFERENT MAN!
Actually, yes, it rather is, for a number of reasons.
First off, it's a lot easier to reason about, and hence design and debug, the more declarative version. If you are passing a filter or manipulator to the recordset or the connector, rather than having to explicitly fetch and manipulate the individual records, then yes, the change in the level of abstraction is significant.
Second, there are fewer chances for bugs, if only because you can't screw up the iteration conditionals. And don't tell me that no one is that incompetent, because I've seen it far too many times, even in professional code.
Third, chances are the operation can - and in many cases probably should - be done by the database engine in the first place, not in the middleware. The RDBMS ought to be able to optimize a lot of the work out when given the right queries. Even if it must be done in the middleware, explicit iteration takes away a chance for the connector to optimize parts of the work via filtering or folding. I know that in most cases neither of these things are done, but that doesn't mean they can't be done, and often they ought to be possible if the RBDMS engine and the connector were designed better.
-
YOU DID NOT ANSWER THE QUESTION ABOUT WHAT YOU USE INSTEAD.<dogshit>
-
No, I didn't, because unfortunately, the way I would like to do things isn't generally available right now. There's no good reason for this - it would be trivial to do in several different languages - but for some reason it isn't.
I guess that I am just saying that as bad as PHP is, the rest of the world isn't much better.
That, and ADO et. al. are often used as a crude substitute for more complex SQL queries by coders who really don't know SQL. Not that SQL is all that great - it is deeply worrying to me that we have yet to come up with a decent implementation of relational calculus to replace it yet - but it is a lot more declarative than any of the things used instead of it.
-
Setting aside the issue whether PHP is a good technology in general, the rant is of course wrong.
There are various libraries which offer the API that he wants, for example this first search result
-
Admittedly, Java is just as bad about, but Java is shit.
Actually, yes, it rather is, for a number of reasons.
First off, it's a lot easier to reason about, and hence design and debug, the more declarative version. If you are passing a filter or manipulator to the recordset or the connector, rather than having to explicitly fetch and manipulate the individual records, then yes, the change in the level of abstraction is significant.
Second, there are fewer chances for bugs, if only because you can't screw up the iteration conditionals. And don't tell me that no one is that incompetent, because I've seen it far too many times, even in professional code.
Third, chances are the operation can - and in many cases probably should - be done by the database engine in the first place, not in the middleware. The RDBMS ought to be able to optimize a lot of the work out when given the right queries. Even if it must be done in the middleware, explicit iteration takes away a chance for the connector to optimize parts of the work via filtering or folding. I know that in most cases neither of these things are done, but that doesn't mean they can't be done, and often they ought to be possible if the RBDMS engine and the connector were designed better.
OK, so you're railing on ADO here.
However... you lost me by mentioning Java. Last I checked, both JDBC and JPA involves manually writing SQL / "JPL" SELECT queries1 to fetch data. JPL is in quotes because it's mostly SQL except it substitutes a common binding syntax for prepared queries and a few other niceties that make dealing with
Oracledatabases that do things differently less of a pain in the butt.1unless you're using the JPA Criteria Query API
-
Because I still see a lot of Java code that does a trivial query and then combs through the data to filter out records that should have been filtered out in the query instead.
-
Because I still see a lot of Java code that does a trivial query and then combs through the data to filter out records that should have been filtered out in the query instead.
Ah, so you're blaming the language for the stupid things people do with it.
-
No, I didn't, because unfortunately, the way I would like to do things isn't generally available right now. There's no good reason for this - it would be trivial to do in several different languages - but for some reason it isn't.
So it's awful but nothing better exists.
Awesome.
I guess that I am just saying that as bad as PHP is, the rest of the world isn't much better.
PHP uses PDO, which is basically an exact port of ADO.
That, and ADO et. al. are often used as a crude substitute for more complex SQL queries by coders who really don't know SQL.
?
Unless you're using ADO indirectly via. something like EntityFramework, you kind of have to know SQL to use ADO to do virtually anything useful.
-
Unless you're using ADO indirectly via. something like EntityFramework, you kind of have to know SQL to use ADO to do virtually anything useful.
Yeah.. and complex things should be done directly in sql anyway. I've had terrible 'luck' with EF and performance.
-
I've done both EF and Linq-To-SQL and wasn't impressed with either. They save a tiny bit of typing, but only if you don't do anything more sophisticated than simple CRUD operations.
The good news about EF is you can teach it about stored procedures, then execute those are if they were just functions.
-
-
You just go to that database-first design view that lays out all your shit, find the sprocs in the database objects in the left, then drag-and-drop the sproc onto the design view.
Now your DataContext contains a function that's basically a translation of the sproc.
That said, I seem to recall it failing on complex sprocs that have multiple queries in them, and it'll certainly fail if your sproc doesn't return the same columns for every possible input. (It's kind of a WTF that SQL even allows that.)
-
-
http://news.php.net/php.internals/88937
Epic troll is epic.
... SNIP ...
To be fair, the guy's probably been driven crazy by having to work with PHP. So no surprise there, really.
-
Because I still see a lot of Java code that does a trivial query and then combs through the data to filter out records that should have been filtered out in the query instead.
So what I'm hearing here is that your earlier post could be condensed to
Generally speaking,
if you are explicitly iterating through a recordset,you're doing it wrong.Because if you've got decorative (Swype doesn't know that word, I cba to fix it) stuff to do, you should be doing it in the Db, which means the only thing left to do with the data is to iterate it.
-
So, the guy is mixing up a programming language with a framework written in that language (AJAX request handling and pagination in the core? yeah, right).
Yawn.
3/10, would not decrypt bad grammar again.
-
PDOStatement implements
Traversableso you can justforeachthe whole result set. Can't get much easier than that.In my own code I usually make a "select" object directly
Traversableso you can just create a select, execute and iterate through the results in one line. This pattern is based on extending the oldZend_Select.foreach ($db->select()->from('foo')->where('bar') as $row) { ... }TRWTF is that everything is a string when it comes to databases and PHP.
-
Because I still see a lot of Java code that does a trivial query and then combs through the data to filter out records that should have been filtered out in the query instead.
To be honest you're probably dealing with someone who doesn't know a thing about sql except for SELECT * FROM *.I don't know much about SQL so it usually becomes a trade off between debugging SQL or debugging Java. Guess which one I prefer. Luckily for the sanity of my colleagues I'm not allowed near the DB.
-
TRWTF is that everything is a string when it comes to databases and PHP.
I'm pretty sure
ints andfloats come through OK when dealing with Postgres at least, do they not? Or did I mix it up with setting parameters forINSERTs andUPDATEs? I admit I haven't touched that part of code in a while now, my memory might be wonky...
Filed under: TRWTF is
dynamicduck typing
-
I have no idea if Entity Framework is bad, I'm just going with it.
I like Entity Framework but I've only done very simple things with it. The code-first approach just worked and the syntax is simple and easy to use. Performance was absolutely fine for what I was doing too. I'd use it again without a second thought.
-
However... you lost me by mentioning Java. Last I checked, both JDBC and JPA involves manually writing SQL / "JPL" SELECT queries1 to fetch data. JPL is in quotes because it's mostly SQL except it substitutes a common binding syntax for prepared queries and a few other niceties that make dealing with Oracledatabases that do things differently less of a pain in the butt.
1unless you're using the JPA Criteria Query API
Indeed. As a Hibernate guy, I switch between SQL and HQL (which returns the ORM's view of the data, which is super handy, but which is somewhat more limited than SQL).
-
People need to read all the way to the end. The punchline is probably the most epically epic part of the whole thing.
-
I agree the confidentiality thing was brillant, but it had all this pointless drivel before it.
-
Linq-To-SQL?
Have some vomit.
My entire PHP career was about running a query and getting an array as a response. I don't know if there's a better way or not. I don't even know if nextrecord would have many applications when you've got Array.prototype.forEach in ES.
-
I'm trapped in a raw JDBC world at the moment, but when not, I try to use Hibernate's JPA interface Just In Case we decide to move to something else.
Which is probably why it bugs me that the Maven copy of the JPA 2.x spec is in the EclipseLink namespace (and the 1.x section will tell you the newer version is there). as opposed to the
javax.persistencenamespace it should be in. Luckily, the Java code is still in the correct namespace since that would horribly break things otherwise.Incidentally, to enforce the JPA thing, Hibernate is a runtime dependency as opposed to a compile time dependency and even then, only on the web application... the actual data project isn't even aware Hibernate is there.
-
a trade off between debugging SQL or debugging Java. Guess which one I prefer.
Why not
bothneither?
:nope_meme.flv:
-
They save a tiny bit of typing, but only if you don't do anything more sophisticated than simple CRUD operations.
And even with those, it mostly excels at the "R" part, and other things can get... nasty. Especially if the data objects you want in your application are different than the table structures - you either screw around with the mapping (which only really gets you so far), or you convert between entities and business objects, which then screws you over in all the ways you can spell "detached entities".
And don't even get me started on FK relationships...
-
@ScholRLEA said:
The poster critiques PHP's awful database handling and then holds up ADO as the Right Thing?
What's wrong with ADO?
Them's fighting words.
Ignore them. They're making much ADO about nothing.
-
Hibernate is a runtime dependency
If you're not using a compliant JEE container like JBoss, in which case having your own version of Hibernate + the AS JPA package & version is a fun (read: mind fucking) exercise for the reader.
