Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Появляется все больше языков программирования совершенно непохожих, на традиционные языки вроде C++, Java, PHP. Эти языки построены по иным принципам: Haskell или F#, например, пропагандируют функциональный подход к программированию, и, соответственно, требуют более математического мышления, Erlang с нестандартным подходом к многопоточности/многопроцессовости.
Эти нововведения безусловно хорошо и позволяют легко решать какой-то определённый круг задач, но достаточно ли этого для ведения промышленной разработки? До сих пор не сталкивался с использованием того-же Хаскеля за рамками студенческих проектов. Сотни раз слышал, что подобные языки никогда не смогут использовать большинство программистов — они предполагают тяжёлую умственную работу и определённый склад ума.
Неужели новые подходы так и останутся лишь своеобразной головоломкой, доступной лишь немногим и ненужной в массах, станут своеобразной игрой в бисер?
Эти нововведения безусловно хорошо и позволяют легко решать какой-то определённый круг задач, но достаточно ли этого для ведения промышленной разработки? До сих пор не сталкивался с использованием того-же Хаскеля за рамками студенческих проектов. Сотни раз слышал, что подобные языки никогда не смогут использовать большинство программистов — они предполагают тяжёлую умственную работу и определённый склад ума.
Неужели новые подходы так и останутся лишь своеобразной головоломкой, доступной лишь немногим и ненужной в массах, станут своеобразной игрой в бисер?
Я бы не сказал, что появляются — Lisp(1958), Haskell(1990), Erlang(1987) давно уже существуют. Правильнее будет сказать — становятся известными широкому кругу программистов.
> они предполагают тяжёлую умственную работу
Это как понимать? А написание на «традиционных» языках не предполагает тяжёлую умственную работу?
Это как понимать? А написание на «традиционных» языках не предполагает тяжёлую умственную работу?
Вообще-то нет, тяжелой работы точно не предполагается. Либо, если и предполагается, то лишь небольшая часть, больше связанная с проектированием, нежели кодированием.
Или вы глубоко задумываетесь над каждой строчкой кода? ;)
Лично у меня процесс итеративного кодирования занимает больше руки, нежели говову, потому как понятно что надо делать, как надо делать и остается лишь сделать, написав несколько строчек.
И, как мне кажется, у более развитых программистов процесс вбивания кода еще более вытеснен из умственного пространства.
А если время, которое тратится на обдумывание, в 10 раз меньше времени потраченого на написание, то модно ли назвать это тяжелой умственной работой?
Или вы глубоко задумываетесь над каждой строчкой кода? ;)
Лично у меня процесс итеративного кодирования занимает больше руки, нежели говову, потому как понятно что надо делать, как надо делать и остается лишь сделать, написав несколько строчек.
И, как мне кажется, у более развитых программистов процесс вбивания кода еще более вытеснен из умственного пространства.
А если время, которое тратится на обдумывание, в 10 раз меньше времени потраченого на написание, то модно ли назвать это тяжелой умственной работой?
Спорно. Но я даже не про это. Чем «умственно тяжелее» программирование на Хаскеле или Ерланге? За исключением первоначальных трудностей восприятия другого синтаксиса и других концепций? Эти трудности сойдут на нет по мере освоения языка. Какие еще останутся?
Проблема в другом. Когда программируешь какую-то математическую хрень на Хаскеле, или, еще лучше, на LPL, то записанный код практически полностью соответстует математическим выкладкам.
В результате размера кода уменьшается в 5-7 раз. А это значит, что процесс осмысления занимает практически столько-же времени, сколько и процесс написания.
А поначалу и намного больше. Именно из-за таких чудовищных уменьшений работа становится «умственно тяжелее».
В результате размера кода уменьшается в 5-7 раз. А это значит, что процесс осмысления занимает практически столько-же времени, сколько и процесс написания.
А поначалу и намного больше. Именно из-за таких чудовищных уменьшений работа становится «умственно тяжелее».
> достаточно ли этого для ведения промышленной разработки? До сих пор не
> сталкивался с использованием того-же Хаскеля за рамками студенческих
> проектов.
На вскидку — darcs, maxima (clisp).
И как раз в промышленной/финансовой отрасли — в разработке специализированного
ПО — функциональные языки и используются — будь то численные методы,
криптография, статистический анализ, системы управления и формальной
валидации.
Кстати, большым плюсом ФЯ-ов является сравнительная легкость формальной
аргументации (доказательств корректности), что нередко используются, к
примеру, в авиастроении и разработке микросхем.
> Сотни раз слышал, что подобные языки никогда не смогут использовать
> большинство программистов — они предполагают тяжёлую умственную работу и
> определённый склад ума.
У нас в университете все начинали с lisp'а и ML. Ни у кого особых трудностей
не возникало, многие впоследствии выбирали ФЯ-ки для своих проектов.
> сталкивался с использованием того-же Хаскеля за рамками студенческих
> проектов.
На вскидку — darcs, maxima (clisp).
И как раз в промышленной/финансовой отрасли — в разработке специализированного
ПО — функциональные языки и используются — будь то численные методы,
криптография, статистический анализ, системы управления и формальной
валидации.
Кстати, большым плюсом ФЯ-ов является сравнительная легкость формальной
аргументации (доказательств корректности), что нередко используются, к
примеру, в авиастроении и разработке микросхем.
> Сотни раз слышал, что подобные языки никогда не смогут использовать
> большинство программистов — они предполагают тяжёлую умственную работу и
> определённый склад ума.
У нас в университете все начинали с lisp'а и ML. Ни у кого особых трудностей
не возникало, многие впоследствии выбирали ФЯ-ки для своих проектов.
На вскидку — darcs, maxima (clisp).
CLISP — это не чисто функциональный язык. Он и императивный также. А darcs написан с использованием Си. Так что… Желание услышать о коммерческом проекте, который написан при помощи одной только функциональной парадигмы не удовлетворено пока.
И как раз в промышленной/финансовой отрасли — в разработке специализированного
ПО — функциональные языки и используются — будь то численные методы,
криптография, статистический анализ, системы управления и формальной
валидации.
Ух… Не знаю про формальные доказательства корректности, но в криптографии и численных методах функциональная парадигма неэффективна. Многие криптографические алгоритмы требуют состояний и оперирования с потоками данных на битовом уровне. Для численных методов важна возможость оперировать большими объёмами данных с нетривиальной структурой, вроде, разреженных матриц. ФЯ такие возможности обеспечивают с натяжкой.
Кстати, большым плюсом ФЯ-ов является сравнительная легкость формальной
аргументации (доказательств корректности), что нередко используются, к
примеру, в авиастроении и разработке микросхем.
Единственное, что проще для ФЯ в этих доказательствах, так это то, что вычисление функций происходит без side-эффектов. Проблема только в том, что side-эффекты нужны для работы с реальным миром. Для их обеспечения приходится конструировать сложные механизмы, которые доказательства явно не упрощают. Или вы написали автоматических доказательствах?
В авиастроении разве не любят больше Ada? Всё же там управляющие системы должны быть системами реального времени, а у чисто функциональных языков и с этим натяжка.
У нас в университете все начинали с lisp'а и ML. Ни у кого особых трудностей
не возникало, многие впоследствии выбирали ФЯ-ки для своих проектов.
Потому что это не чисто функциональные языки.
CLISP — это не чисто функциональный язык. Он и императивный также. А darcs написан с использованием Си. Так что… Желание услышать о коммерческом проекте, который написан при помощи одной только функциональной парадигмы не удовлетворено пока.
И как раз в промышленной/финансовой отрасли — в разработке специализированного
ПО — функциональные языки и используются — будь то численные методы,
криптография, статистический анализ, системы управления и формальной
валидации.
Ух… Не знаю про формальные доказательства корректности, но в криптографии и численных методах функциональная парадигма неэффективна. Многие криптографические алгоритмы требуют состояний и оперирования с потоками данных на битовом уровне. Для численных методов важна возможость оперировать большими объёмами данных с нетривиальной структурой, вроде, разреженных матриц. ФЯ такие возможности обеспечивают с натяжкой.
Кстати, большым плюсом ФЯ-ов является сравнительная легкость формальной
аргументации (доказательств корректности), что нередко используются, к
примеру, в авиастроении и разработке микросхем.
Единственное, что проще для ФЯ в этих доказательствах, так это то, что вычисление функций происходит без side-эффектов. Проблема только в том, что side-эффекты нужны для работы с реальным миром. Для их обеспечения приходится конструировать сложные механизмы, которые доказательства явно не упрощают. Или вы написали автоматических доказательствах?
В авиастроении разве не любят больше Ada? Всё же там управляющие системы должны быть системами реального времени, а у чисто функциональных языков и с этим натяжка.
У нас в университете все начинали с lisp'а и ML. Ни у кого особых трудностей
не возникало, многие впоследствии выбирали ФЯ-ки для своих проектов.
Потому что это не чисто функциональные языки.
Зачем разрабатывать на таких языках?
Проект после разработки еще и поддерживать кто-то должен.
Уволится часть команды и что делать? Где новых людей искать?
Проект после разработки еще и поддерживать кто-то должен.
Уволится часть команды и что делать? Где новых людей искать?
Если опрос покажет, что достаточное количество людей способно обращаться с подобными языками, то поиск новых людей не должен стать такой уж большой проблемой.
А, соответственно, если задача хорошо попадает под «область действия» экзотического языка, то подобный подход позволит сэкономить массу времени и людских ресурсов и будет оправданным.
А, соответственно, если задача хорошо попадает под «область действия» экзотического языка, то подобный подход позволит сэкономить массу времени и людских ресурсов и будет оправданным.
Ну вот поэтому эти языки и распространенны только в университетах(lisp/haskell) & телекомах(erlang). Для всех остальных задач вполне хватает мейнстримовых языков.
Опрос это вообще ни о чем. Выборка слишком маленькая и специфичная.
Посмотрите резюме, вакансии где-нибудь на hh.ru и увидите реальную распространенность. И сразу станет понятно что на таких языках проект можно делать только для врагов, чтобы они потом с ним всю жизнь мучались.
Посмотрите резюме, вакансии где-нибудь на hh.ru и увидите реальную распространенность. И сразу станет понятно что на таких языках проект можно делать только для врагов, чтобы они потом с ним всю жизнь мучались.
Если вопрос был о функциональных языках — то практика показывает, что они не особо предназначены для коммерческой разработки.
Так что я соглашусь с известной цитатой: «Functional programming is like describing your problem to a mathematician. Imperative programming is like giving instructions to an idiot.» Даже Scala, которая по сути является гибридом функциональной и ОО моделей, сложна для понимания обычным Joe-the-developer. Говоря о мейнстриме: Java/C#/C++/Python/Ruby/PHP/JavaScript — все эти языки двигаются в ОО-направлении, хоть и заимствовуют некоторые функции из функциональных языков. И что самое интересное — пик уже практически настал, взгляните на JavaScript 2, он отчасти стирает границу между динамическими и статическими языками, о чём я недавно писал в своём блоге на Хабре. Нарощения в плане возможностей сходят на нет.
Если нас и ждёт какой-либо новый этап, то скорее это будет DSLs/LOP, но никак не новые general purpose languages.
Так что я соглашусь с известной цитатой: «Functional programming is like describing your problem to a mathematician. Imperative programming is like giving instructions to an idiot.» Даже Scala, которая по сути является гибридом функциональной и ОО моделей, сложна для понимания обычным Joe-the-developer. Говоря о мейнстриме: Java/C#/C++/Python/Ruby/PHP/JavaScript — все эти языки двигаются в ОО-направлении, хоть и заимствовуют некоторые функции из функциональных языков. И что самое интересное — пик уже практически настал, взгляните на JavaScript 2, он отчасти стирает границу между динамическими и статическими языками, о чём я недавно писал в своём блоге на Хабре. Нарощения в плане возможностей сходят на нет.
Если нас и ждёт какой-либо новый этап, то скорее это будет DSLs/LOP, но никак не новые general purpose languages.
Эти языки не экзотичные, а необычные. Экзотичный brainfuck ;)
А что значит «способны»?! Нет, не способен, т. к. не знаю их, но после изучения оных буду способен. По-моему, вопрос некорректен.
Haskell, Булычёв.
А OCaml как же?
А OCaml как же?
Ну, на этом чуде действительно созданы какие-то проекты:
А вот сказать, что он сейчас претендует на что-то новое побоюсь. В тот-же C# вставили небольшие куски функциональности, что делает его примерно аналогичным.
Хотя я с OCaml почти не знаком, могу ошибаться.
На языке OCaml, в частности написан рендеринг формул Википедии, использующих тег, а также популярный файлообменный клиент MLDonkey.
А вот сказать, что он сейчас претендует на что-то новое побоюсь. В тот-же C# вставили небольшие куски функциональности, что делает его примерно аналогичным.
Хотя я с OCaml почти не знаком, могу ошибаться.
Просто я с OCaml чуть-чуть общался. Хотя GUI на подобных языках писать — дело не самое благодарное.
Пауль, писать гуй дело вообще не благородное.
К тому-же, если на выходе из языка можно получить dll, ну или аналог для *nix систем, то почему-бы и нет?
Ведь гуй можно делать на чем-то специально для этого предназначеном ( например WPF ), а из него вызывать уже написанные на правильном языке функции.
К тому-же, если на выходе из языка можно получить dll, ну или аналог для *nix систем, то почему-бы и нет?
Ведь гуй можно делать на чем-то специально для этого предназначеном ( например WPF ), а из него вызывать уже написанные на правильном языке функции.
OCaml вполне себе традиционный язык. Начинался с функционального, но теперь в нём весь набор императивных возможностей присутсвует. Так что, писать на нём не сложнее, чем на C#
Очень хорошие языки, только нет времени ими заниматься + только один раз видел вакансию на erlang (на хабре)
я, конечно, использую groovy/grails, но он ни разу не экзотичный.
А erlang и уж тем более haskell нужны в оочень узких областях.
А erlang и уж тем более haskell нужны в оочень узких областях.
Секрет успешной разработки на этих языках прост: надо сесть, расслабиться и попробовать to get the job done. IMHO, в реальности, процентов 60 кода не требуют никакой особой императивности. Они даже написаны так, что один в один переносятся в функциональный язык. Другое дело, оставшиеся 40. Зачастую выходит геморрой. Чего-то из реальной жизни функциональные языки не схватывают… как и математика, вполне возможно.
Erlang это не экзотический язык
это язык промышленного уровня
это язык промышленного уровня
есть такая известная статья Джоела Спольски в том числе про пользу функциональных языков — «Опасности обучения на Java»: b23.ru/88f
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Способны ли Вы вести разработку на экзотических языках типа Haskell или Erlang?