Software Engineering Is a Dead-End Career, Says Bloomberg - Slashdot
http://developers.slashdot.org/story/12/04/23/1928202/software-engineering-is-a-dead-end-career-says-bloomberg

FLEGMA: no, taky to moc nechápu, ale co s tím jako mám dělat? :-)

REDGUY: no, jak fixnout problém s databázi mi poradil i Google, a jinak v tomhle klubu žádné reálné problémy myslím nemám... spíš je to takové útočiště ve smyslu "o kolik jednodušší by bylo vyvíjet všechno co opravdu potřebuju sám v céčku, než být nucen do kooperace v rámci soukolí soudobého IT businessu"

FLEGMA: Jo, jasne, presne to je duvod proc jsem mu napr. za posledni dva dny jednak presne rekl, jak fixnout problem s databazi, jednak podrobne ukazal jak mysql meni query strategii v zavislosti na datech. Hazet sipky do jeho fotky a resit jeho problemy, tak se projevuje anti-chaos.

(Jestli ti pipa detektor sarkasmu, tak funguje skvele. Prosim, zamysli se nad rozdilem mezi obsahem a formou.)

XCHAOS: wtf? Jak to myslis, "prochazejici vsechny kombinace"? Proc si to myslis?

REDGUY: to je docela působivé, akorát nevím, o jakou jde optimalizaci, když evidentně jde o dotaz procházející všechny kombinace - bez ohledu na počet záznamů v jednotlivých tabulkách se mi to jeví tak nějak že složitost je pokaždé stejná :-) nicméně jako důkaz, že MySQL dělá pokaždé něco jiného to pochopitelně dostačuje.

akorát, že jsem asi jediný moderátor klubu na NYXu, která se nechává od přispěvatelů beztrestně urážet. no ale snad časem i NYXáci dospějí/dozrají... kdo ví.

ALMAD: Protoze mi to prijde jako naprosto zbytecny. Pokud se vejdu do pameti, tak mi relace mezi datama prijde mnohem jednodussi vytvorit v normalnich datovejch strukturach a rovnou tak s nima pracovat, nez mapovat data na tabulky, pak psat sql prikazy a pak doufat, ze to SQL engine vymysli dobre. Proste vyjadrovaci schopnost high-level jazyku je mnohem vyssi, nez SQL, u kteryho jsem omezenej tim ze musi byt relativne snadno mapovatelny na nejaky v podstate jednorozmerny tabulky.

Jasne, muzeme se bavit o nejakem datovem/query metajazyce kterej by za me generoval C/C++/Perl. Ale je hloupost stavet ho na SQL.

REDGUY: Tak jako proc ne.

Jak vidis na xChaosove prikladu, SQL optimalizatory jsou chytrejsi, nez interprety a kompilatory (sql dotaz trva 0.00, php parsing 0.5, QED), takze proc je nevyuzit na preklad SQL -> pametove struktury?

XCHAOS: teď teda nezbývá počkat, než mi nějaká SQL databáze ukáže různé DESCRIBE pro různé obsahy tabulek - a jako obvykle, obecni idiot radsi tlacha o vecech kterejm nerozumi, pripade "ceka" az az se mu neco "ukaze", misto toho aby si neco nastudoval nebo vyzkousel. A pritom je to tak snadne.

Nu co, v Uzbekistanu dnes slavi Den Kdy Kazdy Pravy Uzbek Musi Byt Hodny Na Vesnickeho Idiota, proc se nepripojit k oslavam, i kdyz nejsem uzbek, ze?

mysql> describe users;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(8)      | YES  | MUL | NULL    |       |
| name  | varchar(20) | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql> describe posts;
+---------+--------------+------+-----+---------+-------+
| Field   | Type         | Null | Key | Default | Extra |
+---------+--------------+------+-----+---------+-------+
| user_id | int(8)       | YES  |     | NULL    |       |
| text    | varchar(255) | YES  |     | NULL    |       |
+---------+--------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql> show index from users;
+-------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name     | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| users |          1 | idx_users_id |            1 | id          | A         |        NULL |     NULL | NULL   | YES  | BTREE      |         |               |
+-------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
1 row in set (0.00 sec)


# Ruzne vysledky describe pro ruzne obsahy tabulek:

# hodne radku v posts i users

mysql> describe select users.id, posts.text from users, posts where posts.user_id = users.id;
+----+-------------+-------+------+---------------+--------------+---------+---------------------+------+--------------------------+
| id | select_type | table | type | possible_keys | key          | key_len | ref                 | rows | Extra                    |
+----+-------------+-------+------+---------------+--------------+---------+---------------------+------+--------------------------+
|  1 | SIMPLE      | posts | ALL  | NULL          | NULL         | NULL    | NULL                | 4096 |                          |
|  1 | SIMPLE      | users | ref  | idx_users_id  | idx_users_id | 5       | rtest.posts.user_id |   11 | Using where; Using index |
+----+-------------+-------+------+---------------+--------------+---------+---------------------+------+--------------------------+
2 rows in set (0.00 sec)


# Hodne radku v posts, jeden radek v users

mysql> describe select users.id, posts.text from users, posts where posts.user_id = users.id;
+----+-------------+-------+--------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type   | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------+--------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | users | system | idx_users_id  | NULL | NULL    | NULL |    1 |             |
|  1 | SIMPLE      | posts | ALL    | NULL          | NULL | NULL    | NULL | 4096 | Using where |
+----+-------------+-------+--------+---------------+------+---------+------+------+-------------+
2 rows in set (0.00 sec)

# jeden radek v posts i users;

mysql> describe select users.id, posts.text from users, posts where posts.user_id = users.id;
+----+-------------+-------+--------+---------------+------+---------+------+------+-------+
| id | select_type | table | type   | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+-------+--------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | users | system | idx_users_id  | NULL | NULL    | NULL |    1 |       |
|  1 | SIMPLE      | posts | system | NULL          | NULL | NULL    | NULL |    1 |       |
+----+-------------+-------+--------+---------------+------+---------+------+------+-------+
2 rows in set (0.00 sec)


# posts i users prazdne

mysql> describe select users.id, posts.text from users, posts where posts.user_id = users.id;
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                                               |
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
|  1 | SIMPLE      | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | Impossible WHERE noticed after reading const tables |
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
1 row in set (0.00 sec)


# hodne radku v posts, nekolik v users

mysql> describe select users.id, posts.text from users, posts where posts.user_id = users.id;
+----+-------------+-------+-------+---------------+--------------+---------+------+-------+---------------------------------------------+
| id | select_type | table | type  | possible_keys | key          | key_len | ref  | rows  | Extra                                       |
+----+-------------+-------+-------+---------------+--------------+---------+------+-------+---------------------------------------------+
|  1 | SIMPLE      | posts | ALL   | NULL          | NULL         | NULL    | NULL | 14496 |                                             |
|  1 | SIMPLE      | users | index | idx_users_id  | idx_users_id | 5       | NULL |     8 | Using where; Using index; Using join buffer |
+----+-------------+-------+-------+---------------+--------------+---------+------+-------+---------------------------------------------+
2 rows in set (0.00 sec)


# hodne radku v posts, dva v users

mysql> describe select users.id, posts.text from users, posts where posts.user_id = users.id;
+----+-------------+-------+-------+---------------+--------------+---------+------+-------+--------------------------------+
| id | select_type | table | type  | possible_keys | key          | key_len | ref  | rows  | Extra                          |
+----+-------------+-------+-------+---------------+--------------+---------+------+-------+--------------------------------+
|  1 | SIMPLE      | users | index | idx_users_id  | idx_users_id | 5       | NULL |     2 | Using index                    |
|  1 | SIMPLE      | posts | ALL   | NULL          | NULL         | NULL    | NULL | 14496 | Using where; Using join buffer |
+----+-------------+-------+-------+---------------+--------------+---------+------+-------+--------------------------------+
2 rows in set (0.00 sec)

XCHAOS: "... errr, protože v PHP omáčka okolo trvá 0.5 sekundy?" [citation needed]

XCHAOS: já se ale nechtěl omezovat na datové struktury SQL - šlo mi vysloveně o to, že bych napsal jednořádkový SQL dotaz, který by mi pre-compiler rozexpandoval třeba na 10 řádků volání knihovních C funkcí - coze? To myslis vazne? Takze ty misto toho abys proste rucne napsal kod kterej bude pouzivat struktury, objekty, hashe, linked listy, stromy a janevim co jeste bude psat SQL ktery o nicem z toho nema ani paru a budes doufat ze optimizer to nejak zazracne vymysli? HAHAHAHAHAHAHA. Cim dal tim lepsi.

XCHAOS: což jsem u svých projektů elegantně chtěl řešit použitím makro-wrapperů, - HAHAHAHAHAHA. No nic.

norma POSIX se právě snažila striktně definovat i kompatibilitu hlavičkových souborů k běžným knihovním funkcím jo, a "bezne knihovni funkce" jsou plne a naprosto dostacujici pro real-world projekty.

Jen tak pro legraci, jak dobre by dneska fungoval tvuj slavnej prometheus kdybys ho napsal v roce 1994? (a nez napises nejakou pitomost, zamysli se nad tim, jak vypadaly linuxove firewally v roce 1994).

XCHAOS: jasně, že bych mohl trochu optimalizovat i v PHP... ale člověk tam instinktivně píše co nejsrozumitelněji... a navíc ani není jasné, která feature jazyka tam zdržuje kolik a tak...

kthx, neat: :D anyways:

Ad 1) No, v SQL taky clovek pise normalnizovane a pekne a srozumitelne a instinktivne. A pak potka vykonovou realitu. Nejak nevidim duvod, proc by to v php melo bejt stejny.

Ad 2) Neni jasne? Protoze...errr...protoze to neznas a nemeris?

A vytvarim 3): Z bodu 1) mi teda vyplyva, ze nejvetsi ficura prepisu do C je ta, ze v C clovek instinktivne nepise co nejsrozumitelneji, ale co nejvykonneji.

REDGUY: ... což jsem u svých projektů elegantně chtěl řešit použitím makro-wrapperů, které by pomohly obcházet případné dílčí nekompatibility knihoven či platforem ... :-) (což je nápad, který se výrazně osvědčil např. u javascriptové knihovny JQuery ...)

jinak máš pravdu částečně - norma POSIX se právě snažila striktně definovat i kompatibilitu hlavičkových souborů k běžným knihovním funkcím, a v řadě přídů se toto opravdu už 10 a více let nezměnilo.

REDGUY: já se ale nechtěl omezovat na datové struktury SQL - šlo mi vysloveně o to, že bych napsal jednořádkový SQL dotaz, který by mi pre-compiler rozexpandoval třeba na 10 řádků volání knihovních C funkcí... možná je to celé blbost, ale rozhodně mi místo toho nepodsouvej vlastní hloupé nápady, které nějak automaticky předpokládáš i u mě :-)

ALMAD: ... errr, protože v PHP omáčka okolo trvá 0.5 sekundy? přesto, že není jediný důvod, proč by měla?

třeba proto, že v PHP se na sloupce ve výsledku odkazuji pomocí $vysledek['klic'] - zatímco libmysqlclient mě trochu spartánštěji vede k použití číselných indexů do pole reprezentujícícho jeden řádek z výsledku dotazu? jasně, že bych mohl trochu optimalizovat i v PHP... ale člověk tam instinktivně píše co nejsrozumitelněji... a navíc ani není jasné, která feature jazyka tam zdržuje kolik a tak...

BTW můj typický jednoduchý dotaz do tabulky trvá 0.00 sekund(...)
to beru jako finální argument, proč chci bastlit webové aplikace v Céčku místo v PHP(....)

Cely svet je plny jednoduchych dotazu co trvaji 0.00 sekund (ano, nejspis proto ze se index vejde do pameti a na jednom nodu), takze chceme bastlit v Ccku, protoze...err...to dava smysl.


XCHAOS: Mel bych takovy dotaz...kdyz si delas tu predstavu...jakej ze tam byl vlastne engine?

Me ponekud desi ze tu hazes "nenavidim externi enginy, mam rozbitou tabulku a haze mi to chybu" hlasky a pri tom ani nenapises, co za engine v mysql si pouzil.

Jakoze vzhledem k tomu, ze mysql engines jsou od sebe tak daleko, ze jsou to de facto separatni databaze (maj jiny vlastnosti, jiny zpusoby optimalizace, jiny modely zamykani, ...), tak to je podobna kravina, jako kdyby na zaklade toho ze mu pro nejakej pripad maly appky zralo vic parsovani na frontendu nez pristup k datum a vubec neresil nejaky skalovani (tj. jak moc muze pridavat dalsi fe vs. db stroje) vyvozoval, ze ma cenu to psat v rychlejsim fe jazyce, co bude radove pomalejsi na vyvoj.

Oh wait.

XCHAOS: ale já právě počítal s tím, že by se v takovýchto tabulkách pak místo číselných primárních klíčů používaly přímo pointery - nejde jen o pouzivani pointeru. Jde o to, ze pokud mas primej pristup do pameti, muzes pouzivat mnohem sirsi skalu datovej struktur nez nabizi SQL a tudiz je pitomost se na nej omezovat.

XCHAOS: Výrazným rysem samotného jazyka C je zpětná kompatibilita - Hello, Captain Obvious. Coz je bohuzel tvrzeni v podstate o nicem. Jednak proto, ze podobne zpetne kompatibilnich je i spousta dalsich jazyku, druhak proto ze samotna kompatibilita jazyka je ti uplne na houby, kdyz se ti knihovny meni pod rukama a tu a tam se dokonce zmeni i format executable.

ale upřímně: nevím, jak to tam je se zpětnou kompatibilitou reálně - my vime 8))

Pokud vím, tak javové aplikace ani nebyly přenositelné mezi mobilními telefony a webovými browsery) - coz je podobne pitome tvrzeni, jak rikat ze Cckove programy nejsou prenositelne mezi Arduinem a Linuxem. Viz vyse, problem neni v jazyce, ale v knihovnach a v tom ma C problem jako vsichni ostatni.

REDGUY: ...ale já právě počítal s tím, že by se v takovýchto tabulkách pak místo číselných primárních klíčů používaly přímo pointery... přesto by ale kód vznikl kompilací "human readable" SQL dotazu. akorát by např. to id v takovéto tabulce pochopitelně byl vždy přímo pointer, a relace by byly přímo do paměti.

REDGUY: to je samozřejmě zajímavá teorie... teď teda nezbývá počkat, než mi nějaká SQL databáze ukáže různé DESCRIBE pro různé obsahy tabulek. zatím mě vždy přišlo, že na to má vliv jen struktura dotazu a struktura klíčů u tabulek.

DAVIDOWITCH: připouštím, že nemám představu, jak uvnitř vypadá databáze... ale na základě chyb, které mi hází MySQL, si postupně nějakou dělám :-)