👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

не читал, но осуждаю =)

не читал, но осуждаю =)

Почитайте таки оригинал. ИМХО, полезнее чем выяснение того в какую бы еще Ж засунуть офисы лидеров рынка.

А я вот сколько не смотрю на ФП, оно мне все кажется тривиальным синтаксическим сахаром, вокруг очевидных идей, только все суперпереусложнено товарищами которые на голом месте притягивают теорию категорий и прочие апликативные функторы.

Программист в день выдает 200 строк качественного кода.

На С это будет ,например, 15 кейсов и 20 циклов, на каком нибудь хаскелле это же будет всего 20 строк, благодаря map/reduce и паттерн матчингу. Логично, что у него остается время на 180 других строк и еще время подумать над предметной областью.

Вообще-то тот же Haskell был создан комитетом, а не гиком у себя в подвале, людей, с различными учеными степенями и наличие ТК и АФ оправдано их идеями. В то время как школьник писавший Php об этом и не слышал и не знал об этих вещах и проблематике. Это не значит, что Php или другой язык хуже, просто у вас нет таких проблем, где наличие функциональных фишек оправдано, а у кого-то они есть...

А если сравнивать хаскель с ассемблером то можно получить еще более поразительные результаты!
Хотя разница в 10 раз высосана из пальца: shootout.alioth.debian.org/...g=gcc&lang2=ghc

Вообще-то тот же Haskell был создан комитетом, а не гиком у себя в подвале, людей, с различными учеными степенями и наличие ТК и АФ оправдано их идеями.
А си создан школотой, ага?

Си — 2мя людьми, по сути пионерами, когда СS как наука зарождалась и порядок знаний в этой области был меньше.

А если сравнивать хаскель с ассемблером то

речь-то о высокоуровневых языках.

Хотя разница в 10 раз высосана из пальца

речь о производительности программиста, а не производительности системы. Эти тесты синтетические, есть разные способы оптимизации кода хаскеля, когда он генерится в шустрый си

речь о производительности программиста, а не производительности системы. Эти тесты синтетические, есть разные способы оптимизации кода хаскеля, когда он генерится в шустрый си.

Там есть строчка которая оценивает количество символов программы, и оказывается что у хаскеля и си приблизительно паритет, ни о каких 10-раз разницы речи не идет

Зависит от кода, я ,например, работал с ПО для телекома на С/С++, низкоуровневым и там попадаются такие полотнища с кейсами и внутренними ифами на сотни строк, которые паттерн матчингом ужимаются в 4-5 раз.

Я б так не говорил, если б реально не работал с хаскеллем, есть места где он может быть многословнее, но я редко с таким сталкивался...

Всем хаскель хорош только он дико трудный для понимания, и весьма непрактичный во многих случаях. Даже суровые функциональные парни рекомендуют юзать Standard ML/Ocaml так как они проще и практичнее. ну а сейчас, с появлением Скала и F# так вообще вопрос отпадает.

Ну вот я тебе привел кучу примеров что не ужимается.

LISP — до речі старіший Сі. Просто на момент написання Сі по суті єдиним способом писати швидкі програми був Ассемблер. Сі вийшов як макроасемблер, дуже близький до заліза, і при тому на вищому рівні абстракції, що дозволяло портування на інші процесорні архітектури. Якщо подивитися домінуючі тоді процесори з CISC набором інструкцій, то Сі транслюється ледь не 1 в 1 в асемблер.

LISP — до речі старіший Сі.

То что тогда было лиспом и сейчас это две огромные разницы, в отличие от си

Вообще-то тот же Haskell был создан комитетом, а не гиком у себя в подвале,
Вот не уверен что это такой уж и плюс.
Ц — это было решение __реальной инженерной__ задачи, а не абстрактной, теоретической. Может поэтому он и выстрелил, а вот, например, Паскаль не очень. Да че там Паскаль: Смоллток, Лисп.

P.S. Я не утверждаю что это была основная и самая весомая причина.

а вот, например, Паскаль не очень

Неправда ваша, Паскаль осознанно создавался, как язык для обучения программированию. И в этой роли он выстрелил. Среди моих однолеток я (начинавший с Си) — исключение, большая часть обучалась именно на Паскале (а теперь плюются при его упоминании).

Паскаль осознанно создавался, как язык для обучения программированию.

en.wikipedia.org/...mming_language

Initially, Pascal was largely, but not exclusively, intended to teach students structured programming.[4]

Паскаль как раз создавался как язык для «демонстрации концепции» структурного программирования. Суть одна — «язык из академической среды».

Паскаль как раз создавался как язык для «демонстрации концепции» структурного программирования. Суть одна — «язык из академической среды».

Опаньки, перепутал. Но согласитесь, он же был дико популярным (как Дельфи).

Но согласитесь, он же был дико популярным (как Дельфи).

Кстати, хороший пример :)

Делфи то решал инженерную (наболевшую) задачу — деланье УИ + РАД.

колись чілавєки думали, що земля кругла — це гєтто) в фп зовсім інший підхід, а перевчатись завжди складно. проте в фп є свої переваги, які його з «гетто» скоро витягнуть, детальніше тут — www.youtube.com/...h?v=rI8tNMsozo0

Не вытянут к сожалению... Я уже не первый год программирую, ничего не поменялось. У нас на одном ну очень крутом проекте только 2 — 3 человека на 5 команд знали классно ФП и продвигали его. Проблема с ФП даже не в том, что он сам по себе сложный, а в том что сложно формулировать задачи средствами ФП. настолько сложно что мозг просто загибается, ну смотря кому. Конечно я понимаю, что надо ФП внедрять, надо и все, но вот на скалу меня пока не хватает:)

сложно формулировать задачи средствами ФП
как-то очень странно. Задачи — они в предметной области. ФП как реализация не должно влиять на задачу.

Я имею в виду реализацию самих алгоритмов. Например, одно и тоже можно написать императивно, гибридно или чисто функционально. Или там какие — нибудь функциональные структуры данных применить.

Прочитал, не поленился:) теперь выскажу свое мнение. С автором я согласен наполовину только. Собственно в той части где он говорит о полезности ФП. да, функциональное программирование более чем полезно, он позволяет максимально абстрагировать, упростить и сделать неглючным алгоритм. Но с другой стороны, это такой напряг мозга, что просто ужас. У кого ум быстрый и могучий, тому вперед, прямая дорога в ФП, кто чуть поскромнее способностями, как я допустим, будут его применять по мере того как получается. Я сам видел простой пример классический — две программы с одним алгоритмом, на хаскеле и на Питоне. Программы одинакового размера. В программе на питоне я разобрался за 10 минут, в программе на Хаскеле я за 1 день не разобрался:) При этом практически не зная питона.
Автор категорически не прав насчет ява-шопов. Зайду издалека, говорят, что хорошему мастеру надо быть одновременно и творцом, и ремесленником. Да, джава это язык ремесленников, но это хороший язык, который позволяет быстро и качественно писать софт за который платят деньги. Суть — то коммерческой разработки в том, чтобы написать в срок то, что будет работать так как надо. Все остальное можно смело относить к научным исследованиям в Computer science. Да, результаты полученные в этих Computer science позволяют двигать программирование вперед, потому я лично одобряю ФП, стараюсь применять в меру своего разумения. Но к сожалению жизнь показала, что подход основанный на хардкорном ФП мейнстримом не стал и никогда не станет. Скорее люди перейдут на ДСЛи. Чистый ФП — это язык гиков и технология гиков, любителей вывернуть себе мозг. К тому же писание программ на классном императивном языке с поддержкой ФП, например на Руби, может доставить не меньшее удовольствие.
Резюмируя, я считаю, что:
1) ФП желательно внедрять, желательно но постепенно, в меру понимания и удобства, например начиная с Google Guava. Потом кто осилит мягко перейдет на скалу при необходимости.
2) Программисты пишущие на Джава в ява-шопах полноценны и не стоит оглядываться на гиков с восхищением. Я работаю, мой софт работает, ставится и приносит профит.
3) Языки типа Ocaml, Standard ML, haskell — язки гиковские, мейнстримом не стали и не станут никогда. Это языки для хобби и научных исследований.

Всем хорошего дня!

Я лично — за разумную мультипарадигменность. А поборники «чистого ООП» и «чистого ФП» мне иногда напоминают религиозно озабченных сектантов.

>2) Программисты пишущие на Джава в ява-шопах полноценны и не стоит оглядываться на гиков с восхищением. Я работаю, мой софт работает, ставится и приносит профит.

Согласен. Школота, пишущая на похапе на фриланс.сру полноценна и не стоит оглядываться на гиков с восхищением. Я работаю, мой софт работает, ставится и приносит профит.

Собственно да, так и есть:) Конечно качество кода у школоты ниже чем у гиков, но по идее код приносит деньги — приносит, а значит будут находиться желающие его делать и за него платить. Увы, программирование — это не религия и не идеология. Кстати, я собственно за функциональное программирование.

Согласен, что не идеология и не религия, именно поэтому синиоры в лидерах рынках получают копейки, ибо ремесленники и не более, ибо религией и идеологией должно быть саморазвитие и стрмеление к максимально качественному выполнению задач.

Не согласен, получают они потому столько, что за их работы платит рынок. Невыгодно просто джава — синьору платить столько — то, так как тогда будет невыгодно аутсорсить. Ножницы Маршалла — есть такой закон рыночной экономики. Можно написать идеальную программу на хаскеле но за нее точно не заплатят в этой ситуации.

Все вполне выгодно. Другое дело, что отдавать что-то годное тем, кто делают тяп-ляп никто не будет. А рынок может платить намного больше, только дял этого надо быть специалистом и работать не покладая рук, при этом не сидя в лидерах рынка.

Есть еще один закон, «скорость-цена-качество». ЗНаете такой? Так вот, многие работодатели вполне платят за качество, посему и получают хаскелисты много, а фомрошлепы из лидеров рынка мало.

В целом согласен, только вот реальных вакансий на хаскеле всего 20 — 30 по миру.:) В Украине я только 1 место где на нем пишут и то я не уверен что там хаскель это реально лучший выбор.

а можно уточнить где именно в Украине?

В Епаме для какого — то крутого проекта банковского.

Я не знаю деталей. Знаю что там реально очень умные ребята задействованы, дают высокий уровень качества и т.д. насколько там нужен хаскель — не знаю, им наверное виднее, полагаюсь на их знания и опыт.

Эммм... А вы в курсе того, что здесь обусждаецца? Или дял вас круг функциональных языков или таковых, где можно писать в функциональной парадигме, ограничен хаскелем?

Да, мы в курсе вполне. Я знаю что функциональный подход — это именно подход а не язык, стараюсь его применять и в джаве по возможности. Хаскелем не ограничен, но хаскель — это чисто функциональный язык, потому говорим трушное ФП — подразумеваем хаскель. или как минимум окамл.

потому говорим трушное ФП — подразумеваем хаскель. или как минимум окамл.

Тьху! Долбаные хипстеры!

ФП — это Lisp!!! :)

Ну уж нет, когда говорим о ФП, то подразумеваем парадигму и языки, котоыре позволяют в ней писать. Скалу, в т.ч., с разными F# и т.п.

Иначе, если уж тогда привязывацца таким образом, как сделали вы, то ни о С++, ни о яве, ни о с#нельзя говорить в контексте объектной парадигмы (языки — то не всем принципам ооп подчиняюцца), а пользовать тогда уже руби, смолтолк , оберон(ничего не знаю, но из зала подсказывали уже) и обжектив-с в обсуждениях ООП, котоыре объектные как раз в том смысле, которое в это понятие вкладывал создатель термина ООП.

да, руби более объектно-ориентирован чем джава, именно так. Джава это императивный язык просто с хорошей поддержкой объектно-ориентированного подхода, а руби — чисто ООП — язык. Точно также скала — это чисто ООП-язык с хорошей поддержкой ФП — подхода, а хаскель — чистый ФП — язк. Таким образом даже мега — функциональный язык Ocaml (наследник ML) не является чисто функциональным языком, так как там присутствуют императивные конструкции, ну да не буду запариваться, в целом я с вами согласен:)

аким образом даже мега — функциональный язык Ocaml (наследник ML) не является чисто функциональным языком

Ну да, буква О обозначает objective

ні, вони мають вчинити суїцид тому що трімм не одобряє їх діяльність.
мабуть трімм то й сам коли був школотою вже написав свій гугл на ерланг і какав нутеллою і пісяв молоком. Без образ.

Т.е. в вашей голове даже и мысли не проскочило, что они должны постоянно расти и учицца, а не сидеть на одном (я говорю об областях знаний ,а не о работодателе) и том же, выполняя рутинную работу некачественно?

Они никому и ничего не должны, кроме государства в виде налогов. Все остальное, включая желание учиться и совершенствоваться — исключительно добрая воля и лежит вне сферы понятий должны — не должны.

Нет. Они, как специалисты, обязаны выпонлять свою работу хорошо. Им деньги за это платят. А чтобы выполнять ее хорошо надо учицца и самосовершенствовацца. Иначе, так и выходит, что есть куча копеечных обезьянок без царя в голове упершихся в смешной стеклянный потолок в сфере, где до него еще ползти и ползти при хи уровне оплаиы, котоыре орут, что фундаментальные знания по CS менее важны, чем API социалочки.

Нету здесь понятия обязаны, они обязаны только согласно условиям контракта поставить на достаточном уровне качества. Все остальное — это чисто мораль и внутренний настрой. Учиться конечно нужно для того чтобы поднять уровень качества я совершенно с вами согласен, просто я бы хотел сказать что сам процесс труда и продажи его результатов весьма прозаичен, тут нету морали или кодекса разработчика.

да, фундаментальные знания важны, я не буду спорить с очевидными вещами, но им достаточно апи социалочки для их задач. А вот если они орут что хотят больше — тут да. ваш комментарий тут тогда как раз кстати.

Извините, вы все правильно написали, однако не увидели моего месседжа:

>Учиться конечно нужно для того чтобы поднять уровень качества я совершенно с вами согласен, просто я бы хотел сказать что сам процесс труда и продажи его результатов весьма прозаичен, тут нету морали или кодекса разработчика.

Тут нет морали и кодекса разработчика, поэтому, чтобы не получать несчастные 2-4к, как 23-летние синиоры уа рынка, специалист обязан расти и развивацца постоянно.

Я пока не знаю ни одного спеца, который бы не орал, что хочет больше, не?

Вот теперь поддерживаю полностью:)

А я это изначально и писал.

1) ФП желательно внедрять, желательно но постепенно, в меру понимания и удобства, например начиная с Google Guava.

Excessive use of Guava’s functional programming idioms can lead to verbose, confusing, unreadable, and inefficient code. These are by far the most easily (and most commonly) abused parts of Guava, and when you go to preposterous lengths to make your code “a one-liner,” the Guava team weeps.

code.google.com/...tionalExplained

Подписаться на комментарии