LINUX.ORG.RU
ФорумTalks

Какие отрицательные моменты вы видите в функциональном подходе к программированию ?


0

0

В настоящее время на ЛОРе наблюдается некоторая истерия по поводу ФП. Идея охватила революционно настроенные массы. Образовались даже "около ФП-шные" лозунги (самый забавный имхо "чем меньше синтаксиса, тем проще")

Безусловно во многом данный подход к программированию интересен, необычен, привлекает высокая степень матиематической проработки, выразительность языков ФП для решения некоторых задач. Однако, хотелось бы провести некоторое критическое осмысление ФП, услышать не рекламмные слоганы, а взешенные pro and contra от сторонников и противников ФП.


То же самое было и 2 года назад, и год назад, ничего нового или революционного. Давайте еще раз потрясем человечество своей (без)грамотностью.

Shaman007 ★★★★★
()
Ответ на: комментарий от Shaman007

В чем ты видишь ?

> (без)грамотность

ukez
() автор топика
Ответ на: комментарий от Shaman007

Шоман, последнее время ты потрясаешь своими сарказмами. И ещё, не надо требовать от людей слишком многого, не всем дано быть такими правильными как ты.

theSoul ★★★
()
Ответ на: комментарий от Shaman007

Это касается всех топиков. Кажется, у тебя кризис взаимоотношений с окружающим миром (-;

theSoul ★★★
()

>В настоящее время на ЛОРе наблюдается некоторая истерия по поводу ФП.

Да? Не замечал :)

>Идея охватила революционно настроенные массы.

Ну здорово. Больше людей про ФП будут знать.

>Образовались даже "около ФП-шные" лозунги (самый забавный имхо "чем меньше синтаксиса, тем проще")

Автора в студию!

WFrag ★★★★
()

> а взешенные pro and contra

pro et contra. Это тебе латынь, а не инглиш.

anonymous
()
Ответ на: комментарий от WFrag

> > Образовались даже "около ФП-шные" лозунги (самый забавный имхо "чем меньше синтаксиса, тем проще")

> Автора в студию!

Landin??

dilmah ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

> за обещание убрать лямбду к едрене фене в третьей версии.

Он чё совсем ох#$л?? Монжно ссылку на это обещание?

CrazyPit ★★★
()
Ответ на: комментарий от Shaman007

> Убедили, не напишу ни слова в этот топик.

Не пиши лучше ни в какой, самому легче будет

anonymous
()

Contra:

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

- больший footprint рантайма. Это не обязательно, конечно, но этого очень трудно избежать. Однако, всё равно, такого оверхеда на рантайм, как у Java, нет ни у одной реализации.

- более пологая learning curve. Для того, чтоб научиться программировать в функциональном стиле требуется бОльший интеллект и бОльшая начальная математическая подготовка. Однако, и результаты будут гораздо более эффективными, чем для низкоуровневых языков.

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

vsl
()
Ответ на: комментарий от vsl

- более пологая learning curve. Для того, чтоб научиться программировать в функциональном стиле требуется бОльший интеллект и бОльшая начальная математическая подготовка. Однако, и результаты будут гораздо более эффективными, чем для низкоуровневых языков.

Вот толька какая досада, учится не у кого и литературы доступной

нет.

Эксперты в области lisp - математики, по большей части, и нужен очень и

очень нехилый задел по математике, чтобы понять чего они там делают :))

Sun-ch
()
Ответ на: комментарий от Sun-ch

Весьма спорное утверждение.
По большей части мои знакомые физики-ядерщики не испытывали затруднений
по крайней мере до определенного уровня, который и прикладному математику порой не часто годится
И потом, чтобы быть математиком, надо реально работать в математике
а не в программировании, иначе ты как бы уже и не совсем математик

У меня нет никаких проблем в чтении книг по математике или новым областям и диссертациям своих сокурсников, однако назвать себя метематиком после 8 лет только программирования мне как-то совестно
С ходу в карьер рвануть не смогу.
Вот помочь программой на основе матаппарата - это да
:-))

--Antey

anonymous
()
Ответ на: комментарий от Sun-ch

Литературы - до попы. Даже на русском языке кой чего встречается (e.g. SICP, Филд&Харрисон). Математики нужно - всего ничего, немножко дискретки: логика, теория множеств, теория графов.

vsl
()
Ответ на: комментарий от anonymous

>физики-ядерщики не испытывали затруднений

Ну они ведь не ПТУ заканчивали правда?

У каждого за плечами университетский курс математики, как минумум +

общая научная культура.

Sun-ch
()
Ответ на: комментарий от Sun-ch

P.S. И Лисп - это не ФП. Лисп - императивный метаязык с элементами функционального программирования. Чистое ФП - Clean, Haskell, Joy...

vsl
()
Ответ на: комментарий от vsl

> Однако, мало чисто функциональных языков, все, имеющие серьёзное индустриальное применение - комбинированные, сочетающие возможности и функционального, и императивного, и мета-программирования.

Клея маловато чтобы бегать туда-сюда от железа и обратно.

Пока не будет языка который имеет семантические слои вплоть до железа
ситуация с С/C++ - сохранится

Иначе всегда будут желающие еще больше ускорить программу а вместе с ускорением придет и плата за проезд - API будет доступен только подмножеству языков совместимых с реализацией

--Antey

anonymous
()
Ответ на: комментарий от vsl

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

--Antey

anonymous
()
Ответ на: комментарий от anonymous

Как я уже объяснял, такие задачи должны решаться созданием собственных компиляторов DSL-ей, заточенных под платформу... Не должно быть универсальных низкоуровневых языков.

vsl
()
Ответ на: комментарий от Sun-ch

:-))
До поступления в университет успел поработать токарем-револьверщиком около 2 лет - так там выпускники ПТУ занимались программированием станков с ЧПУ (конец 80x) - эдакая смесь декларативного и императивного программирования, однако думаю они этого не знали :-))

Пусть каждый будет хорошим спецом в _своей_ области.
Если сможет набрать больше - честь ему и хвала, если нет - получит то, что решил получить. Захочет - научится и применит.

--Antey

anonymous
()
Ответ на: комментарий от vsl

vsl, ты еще раз подумай

Такая схема правильна, но неоправдано дорога для start-up компаний и даже среднего бизнеса.
К примеру, выпускается 8 видов устройств, общий объем продаж - порядка 25 устройств в год позволяет фирме из 15 человек продолжать развиваться, но не быстро.
Бюджет не тигровый, но и не пожируешь, все работники дают большую отдачу и нанять крутого - не значит получить адекватную отдачу.
И еще каждые 3 месяца - новая opportunity и новые клиенты с абсолютно новыми требованиями на пару-тройку, ну, десяток устройств.
А упустить их сейчас - значит нет денег завтра ни на развитие, ни на зарплату, вот почему на разработку собственного решения под HW просто денег нет.
Это сплошь и рядом!

Ты там еще не почувствовал что-ли? :-))
Приглянись, чем твои директора занимаются - да те самые opportunities ищут, чтобы time-frame и отдача побольше,

--Antey

anonymous
()
Ответ на: комментарий от anonymous

Это заблуждение, что так - дорого. Потому как таргетом может быть и не ассемблер, а, допустим Си или Форт - то, для чего уже есть компилятор.

При наличии минимального опыта такие язычки пишутся за сутки без напряга. Тем более, есть есть богатый опыт с Фортом, то этот подход должен быть простым и естественным - всё же, Форт - неплохой метаязык.

То есть - этот подход при любом раскладе выгоднее - он и дешевле, и быстрее, чем тупое кодирование на чём-то низкоуровневом.

Сейчас вот, задалбавшись с http://wix.sf.net/ пишу к нему препроцессор на Лиспе. ;)

vsl
()
Ответ на: комментарий от vsl

> Это заблуждение, что так - дорого.

Правильнее "Это заблуждение, что так - должно быть дорого."
Согласен - при правильном подходе с 0 - не должно.

Однако в реалии получаем вот что:
Толковый электроншик не умеет Форт, хотя может читать С. Все пакеты, на которые завязана [наша] электроника и ее разработка - это либо FPGA (т.е. нейросеть, либо С и потом FPGA).
Слезть с одноко пакета для электроники на другой дороже чем заменить всю команду разработчкиков и всю команду программистов.

Найти программеров с опытом Форта, Лиспа и С++ - гхм! непросто, уговорить их на определенный уровень зарплаты - еще сложнее, а кто делать работу то будет?

Манагеры стремятся принимать решение с оправданным риском, ближе к минимальному (если он вменяем, В малом бизнесе риск и так велик).

И проект должен быть поддерживаемым (maintainable) во всех отношениях.
И уложится в рамки по времени, и деньгам
И еще масштабируемым на несколько устройств под управлением одного компа, несколько пользователей, несколько компов, и пошло поехало...

Ты говоришь правильные вещи (просто бальзам на душу), но не говоришь, КАК их добиться

При использовании специализированных языков основная проблема - сихронизация API и RT-информации и наличие команды, которая может потом этот зоопарк поддерживать.

И получается, что манагер возьмет на себя крайний риск если пойдет по предложенному тобой пути. Причем в случае неудачи смерть ждет не только его, но и всю малую компанию, вытянуть следующий R&D проект она будет уже не в состоянии.
Правда на другом конце линейки очень большой приз.

Результат мы видим каждый день - С/C++ требуются, а Forth+Lisp не очень ( у нас в городе, так вообще никак )

Я уже ходил наверх с предложением вовлекать студентов старшекурсников в R&D, но это по-хорошему - запрещенный прием. Как на картошку посылать.


anonymous
()
Ответ на: комментарий от vsl

> Ну так обучение этому подходу - тоже дешевое и быстрое. Жаль, что манагеры этого не знают...

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

--Antey

ЗЫ только что имел митинг с нашим электроншиком (толковым в своем деле)
реалии опять полностью подтвердились: он умеет читать С, но не знает, что такое стек (хотя идею ухватил быстро), при этом FPGA/CPLD схемы разрабатывает в течение дня, окупился навреное уже раз пять за approbation period - вот она реальность, млин!

anonymous
()
Ответ на: комментарий от anonymous

Дык об что я говорю? Не надо рассчитывать, что придут уже обученные. Обучать надо на месте. Быстро. Дёшево. Был бы хотя бы один для затравки, который может обучить...

vsl
()
Ответ на: комментарий от vsl

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

И когда же этот потенциал раскроется? На платформе AMD 64 или Cell придется ждать? Или после, в эпоху транспьютеров?

anonymous
()
Ответ на: комментарий от anonymous

Да уже сейчас они лучше оптимизируются. Это не от железа зависит.

vsl
()
Ответ на: комментарий от anonymous

> Я уже ходил наверх с предложением вовлекать студентов старшекурсников в R&D, но это по-хорошему - запрещенный прием. Как на картошку посылать.

Это почему же запрещённый??? Если по специальности.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

Потому что низы не смогут, а верхи не захотят:

у нас не лаборатория или кафедра, а компания,
и она с его помощью деньги не только на сегодня заработает,
но и на завтра, однако на его постоянное место - не хватит

как и не сможет внятно описать другому работатодателю,
что же он у нее делал ибо это IP
(а потому кстати он еще и NDA подпишет, что не позволит ему уйти к конкурентам)

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

Взаимоотношения будут неравноправные и заманивать молодого - это предлагать ему сыграть в лохотрон.

Он же тоже когда-нибудь поймет, и тогда конфликт

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

anonymous
()
Ответ на: комментарий от anonymous

Если R&D открыт - другой разговор, но в фармакологии, например, закрыт и правила очень жесткие

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.