Не мисля че “какво” е толкова по-важно от “как”…

А пък аз казах, че ако някой смята така, или има още да учи (в твоя случай) или трябва въобще да си сменя професията (в случаите на много останали хора). Изписах сума ти неща и частично тоя пост, специално да ти го покажа от още една гледна точка.

Ще направя последен опит да го обясня по различен начин. След това отказвам да говорим с теб на тая тема по коментари и продължаваме на бира . Не си ползвал map и select, не можеш да се изказваш колко добре работят. Преди четири години и аз не ги бях ползвал, бях заклет C++-аджия и въобще не признавах нещо, което има garbage collector или не прави .exe. После обаче видях Java, след което Lisp и Ruby. Пробвах тяхните подходи и те ми помогнаха да видя, че мога да върша нещата много по-бързо и по-качествено със средствата, които дотогава бях отричал.

Така че, разбери какво е map и select и пиши известно време с тях. Примерно четири-пет дена. Докато ги зацепиш и свикнеш да мислиш с тях естествено. След това се върни към средите без select/map и дай да си говорим тогава. Защото, казах ти го вече - извървял съм тоя път и няма никаква сила, която ще ми позволи да те убедя, че грешиш. Можеш само да пробваш сам и да видим докъде ще стигнеш. Може да стигнеш до други изводи, а може да стигнеш и до същите.

И само обърни какво елегантно противоречие направи. Статията на raganwald, която цитира в предния пост, казва точно това - “какво е по-важно от как” и че разликата от “как” до “какво” се нарича accidental complexity.

@dzver:

Не, не, никак даже. Свежда се до това какво намираме за сложно, какво намираме за разбираемо и какво намираме добра идея. И от какво се ръководим като вземаме тези решения. И по-скоро, първия пост опираше до “какво е по-важно от как и ако не го схващате - лошо”, а втория - “като не разбирате нещо, това не го прави сложно или нечетимо. и не може да правите такива заключения”.

Иначе, да, map-а и select-а са добра идея, където имаш предвид map и select. И да, хубаво е да ползваш sort, вместо да си пишеш собствен, освен в ситуациите, в които не ти е много важно бързодействието.

@Стойчо:

Силно ти благодаря за този коментар. Блестящ е! По три причини. Първо, страхотно илюстрира тезата на този материал. Второ, страхотно илюстрира тезата на предния пост. Трето, понеже ясно си личи че не си прочел за какво иде реч, официално се квалифицираш като първия трол на моя малък, скромен блог. Честито!

Нечетимият код се подържа по-трудно и предполага по-голяма вероятност за грешки. Грешките водят най-често до загуба … на време(и много вероятно пари)

“Ползвайте select и map, по дяволите, и sort, никой на днешно време не пише алгоритми за сортиране на масив, нали?”

Правилно ли разбрах?

Обаче да се търси най-абстрактното налично в момента “КАКВО” също не винаги е добър подход. Понякога са достатъчни (и даже препоръчителни) по-конвенционални средства.

Това е безумно вярно и напълно подкрепя тезата ми. Просто въпроса е къде чертаеш линията на тези “по-конвенционални” средства. Аз включвам map и select в тях. А ти?