Les Reddits Thread #0

http://www.reddit.com/r/programming/comments/rp9ha/bad_orm_is_infinitely_worse_than_bad_sql/

ORM are shit in terms of power and expressiveness compared to SQL. Why would you use a shitty object system instead of a relational calculus?

Lessons taken.
1. The more ORM the more upboats.
2. ORM actually borne out of MySQL's flaws and not much else.

>>2
In one word? Morons.

All of the talk about the top 1% of companies' NoSQL applications exists to allow idiots to conceal their incompetence. Unless you have an insanely huge dataset you have no reason not to use a RDMS. NoSQL is a technical compromise, not a design solution.

I've had to use applications where the DB access layer could only do a SELECT * FROM only_one_table WHERE (some_expr). The developers even went to the effort of creating their own mini-query language that codified this limitation and congratulated themselves for their cleverness in "abstracting the database". If you can't JOIN, what is the fucking point of even using a database.

>>4
Relational Algebra is hard. I cant believe PHP people somehow master MySQL, because relational database requires careful planning and designing types in advance, like in this retarded Haskell with its typeclasses (which are tuples too!).

Just replace all databases with simple map/reduce pattern.

Moreover, relation databases are global variables, leaking abstraction, and you cant have database as first class object.

see http://en.wikipedia.org/wiki/Leaky_abstraction

SQL is everything that is wrong with modern IT. It is worse than goto.

>>5
& filter.

Most programmers don’t find databases interesting or fun, so they dismiss databases as “legacy” technology that doesn’t know when it’s time to die. RDBMSs are approximately as old as the C language, and younger than Lisp and Forth, which are trendy again. RDBMSs are still around for two big reasons: There is no serious competing data management technology, and a huge amount of data is committed to RDBMSs. If there was an alternative technology that solved the problems RDBMSs solve so well and offered additional advantages database-based applications would be slowly migrating. Instead we have MySQL and SQLite, low-end open source implementations of 35-year-old technology.

Because most of what programmers do has no theoretical basis or system of proof, programmers back away from anything that looks like hard math. Failure to understand and appreciate relational theory has launched countless bad databases (and thousands of witless articles condemning SQL). The idea that there is a right way to design a normalized database–and that the wrong ways are provably wrong–is alien to most programmers. Database management doesn’t come down to a matter of opinion like OOP class hierarchies or coding style.

Most professional programmers know how it feels to see an amateur, unfamiliar with Knuth or any programming book containing equations, implement their own sort routine. That’s how people who understand relational theory feel when they see a badly-designed database. Relational theory and RDBMSs are old and well-established now, so it’s hard not to think a lot of programmers are willfully ignorant.

>>8
Forth is trendy...?

>>10
http://factorcode.org/

>>5
My mothers vagina is hard. Creating load balancing Daemons that manage DDNS and creating a network protocols is harder then Myshitkuel. Everything requires careful planning and designing types in advance; even your HTTP shit POST to your mirror Cloudflare server.

Your paragraph is non sequitur.

And you can use PosgreSQL for a  simple map/reduce pattern, if the syntax is too hard, make a layer for it like in >>4. Still waiting to see your struct!

I hope you are not using Lua's table/array type:
[m]Error: Out of Memory on table a[] **568 line 440[/m[

>>12
For example, you can just fwrite dirty pages every few minutes or so. It will give you free persistence, based on malloc.

>>13
and you can have char* pointers inside you database too!

>>5
Building any large system that works is hard. Map/reduce isn't a solution; it's a dodge.

>>6
Moreover, object oriented data structures are extensively denormalized, duplicating information, and you cant make objects model every possible relation.

http://en.wikipedia.org/wiki/Database_normalization

Object orientation is everything that is wrong with modern IT. It is worse than COBOL.

>>9
The idea that there is a right way to design a normalized database–and that the wrong ways are provably wrong–is alien to most programmers.
Alien to most programmers lacking a university education, anyway. The root of the problem, I think, is that most users just don't care whether their software actually works as designed or not, so there's no economic incentive for programmers to produce good software.

>>13
sorry, what happens when:
Segmentation fault. Could not allocate 256bytes to file silly_non_ACID.txt

Do you also have a hash table to check its validity, and repair it, huh?

Actually for your silliness, I rather use good old Berkeley_DB. Nice and easy key=value ACID pairs.

>>14
I love you. Want a job? We have free beer fridays!

>>15
Watch out, we have a bad ass over here. seriously