Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 152
А мне вот непонятно, с каких это пор Lisp или Haskell являются эзотерическими языками.
видимо это в ИХ интернетах так повелось…
Видимо, они даже не слышали о BrainFuck, Ook!, Whitespace и им подобных…
Да есть такое дело — коммьюнити Хаскелла тяготеет к пропаганде божественной сущности функциональной парадигмы в первозданном виде.
Но вот, скажем, Лисп — так себе раритет, довольно регулярно до сих пор используется; хотя, конечно, и не мейнстрим.
Но вот, скажем, Лисп — так себе раритет, довольно регулярно до сих пор используется; хотя, конечно, и не мейнстрим.
Я так понимаю, автор считает нужным везде использовать универсальные плюсы, а все что не плюсы — эзотерика. А как насчет того, что профессиональный программист должен выбирать подходящий инструмент под задачу? Кто будет оплачивать лишние человеко-часы на программирование на плюсах, если задача оптимально решается на Lisp'e?
ну на самом деле можем обратится к тому же Грейхему: «В январе 2003 Yahoo выпустила новую версию редактора, написанную на С++ и Perl.» Это случилось уже после того как Грейхем с Моррисом продали свой стартап.
я не буду спорить, что под каждую задачу нужно выбирать оптимальный инструмент, но сравните количество программистов на плюсах и на лиспе? брутфорсом завалить можно :)
я не буду спорить, что под каждую задачу нужно выбирать оптимальный инструмент, но сравните количество программистов на плюсах и на лиспе? брутфорсом завалить можно :)
Можно, при неограниченном количестве средств. Но затраты-то надо соразмерять…
я думаю автор ведет речь именно о производстве, где гениальность и красота решения должны быть принесены в жертву простоте поддержки, развития и взаимозаменяемости сотрудников
конвейер…
конвейер…
Незаменимых — нет. Да, конечно, есть языки, которые создавали специально для упрощения программирования(например, SQL), но взаимозаменяемость сама по себе мифична. Нельзя приравнивать программистов по языку. Один разработчик БД будет стоить $120 000 в месяц, а другой $10 000 — насколько они взаимозаменимы?
Может с тех пор, как AutoCAD стал понимать С++? :))
Эдвардс не осилил скобочки Лиспа? Ну так пусть и дальше кодит на каком-нить там с++.
Если кто-такой Пол Грейхем, я прекрасно знаю, то что за некий Джонатан Эдвардс и кто он такой что бы делать такие громки заявления, совершенно непонятно. Алсо, если верить страничке About его блога, то он разрабатывает какой то язык программирования, видимо под нормальным языком он понимает именно его +) Остается ему только посочувствовать.
меньшая известность автора исключает вероятность того, что его суждение верно?
Вопрос лишь в том, зачем тогда он создает свой язык? Все, мол, эзотерики, а он один сам себе герой? То он ругает «избранность», то тут же говорит о «великих», как-то двояко звучит…
По моему, всё однозначно: гении нужны — они изобретают новое, но в массовом производстве сидят неприметные среднестатистические трудяги. Они не могут с помощью молотка, какой-то матери и вдохновения делать шедевр, им нужно справляться только набором инструментов.
Помнится видел на одном форуме описание замечательного способа написать компилятор С за день, максимум, два. Последовательность, если не изменяет память, была примерно такая: на асме пишется форт, на форте пишется лисп, на лиспе пишется сильно упрощенный С, на сильно упрощенном С пишется обычный С. На все, по утверждению автора, уходит пара дней. Ответ на вопрос: «А нахрена это надо?» очень прост- разработка под процессоры, для которых нет компиляторов нормальных языков. То, что форт на макроасме можно написать за вечер- подтверждаю. Сильно подозреваю, что остальное возможно примерно в те же сроки.
Это к вопросу о выборе языка под конкретные задачи.
Это к вопросу о выборе языка под конкретные задачи.
Это видимо очень скромный человек. Так просто и незатейливо говорит: «Есть суперпрограммисты… Я знаю, я когда тоже был таким» :)
Слишком часто звучит приставка «супер», по глазам хлещет. А на самом деле люди просто делают то, что умеют и как умеют и на Haskell, и на Lisp, и на C++, и даже на VBA…
Я считаю вы не совсем правы, я давно заметил, как правило чем круче програмер писал код тем он проще и понятнее. Хотя конечно если читающий код програмер, сильно хуже писавшего, то может и не понять… Конечно я видел и хороших програмеров которые любят «сложные» решения. Но даже в этом случае понять их «сложные» решения на много проще, чем быдло код.
А я считаю для себя комплиметном когда передав другому код, программист не матюкается на то, что я там наваял. А спокойно может продолжить разработку не выкидывая сделанное.
Обычно — это код «плохого программиста».
Данный код может быть: избыточным, неэффективным (в крайней степени), быть очень запутанным и сложным в поддержке/изменении. В данном коде могут сильно извращаться конструкции языка (использование динамических свойств там где не нужно, страницы кода в геттерах и сеттерах, «паблик Морозов» и т.д.).
Если вы возьмете чужой проект, все переменные прогоните обфускатором, удалите комментарии, а затем посмотрите в получившийся код и постараетесь его понять, тогда вы ощутите, что значит читать «быдлокод», но обычно быдлокод всеравно хуже, потому что в нем встречаются различные запутывания, которых не будет в «хорошем коде» даже после обфускатора.
Данный код может быть: избыточным, неэффективным (в крайней степени), быть очень запутанным и сложным в поддержке/изменении. В данном коде могут сильно извращаться конструкции языка (использование динамических свойств там где не нужно, страницы кода в геттерах и сеттерах, «паблик Морозов» и т.д.).
Если вы возьмете чужой проект, все переменные прогоните обфускатором, удалите комментарии, а затем посмотрите в получившийся код и постараетесь его понять, тогда вы ощутите, что значит читать «быдлокод», но обычно быдлокод всеравно хуже, потому что в нем встречаются различные запутывания, которых не будет в «хорошем коде» даже после обфускатора.
Посмотрю как вы будете реализовывать транзакционную память не на чистом функциональном языке.
очень даже здравая мысль
ИМХО заумность функциональных языков сильно преувеличена. Вон народ уже вовсю пишет лямбдами и LINQ-ой на дотнете и ничего, голова ни у кого не трескается. Скорее даже наоборот скоро все алгоритмы на циклах писать разучатся.
Замуны не сами языки, а идеи, которые за ними стоят.
Что-то написать на хаскелле можно и без знания теории категорий.
Что-то написать на хаскелле можно и без знания теории категорий.
Я вот не знаю теорию категорий. Не очень уверен что она сильно нужна для понимания Хаскеля.
Функциональные языки в действительности элементарны, хаскель же настолько наворочен — лучше считать, что это алгебраический язык, а не функциональный goo.gl/pxCb
Хаскель не очень-то и наворочен. Если не брать расширения, то он вообще скорее простой, чем сложный. Все трудности в изучении Хаскеля не от его навороченности, а от того что он очень сильно отличается от всего привычного.
Одно слово: монады
Монады понять не сложнее чем указатели или ООП. Просто со всем этим мы познакомились в детстве, а сейчас, владея кучей понятий, получаем проблемы при освоении ещё одного абстрактного, не выражающегося через уже известные.
«our biggest mistake in designing Haskell was using the scary term „monad“ rather than „warm fuzzy thing“ (Simon P.J.)
больше шума и слухов о сложности, страшных баек о теории категорий, чем реальной сложности.
больше шума и слухов о сложности, страшных баек о теории категорий, чем реальной сложности.
Ага, лучшая цитата за всю историю программирования, имхо :)
На самом деле никто никогда ни в одном туториале так и не смог внятно объяснить, что такое монады, и с чем их едят (вернее, такая ситуация была еще совсем недавно, как сейчас — хз)
На самом деле никто никогда ни в одном туториале так и не смог внятно объяснить, что такое монады, и с чем их едят (вернее, такая ситуация была еще совсем недавно, как сейчас — хз)
да туториалов ведь просто туева хуча. и какой будет понятен конкретному человеку — вопрос выбора.
а проблемы в объяснении в основном имхо такие: во-первых многие пытаются объяснить всё и сразу — а это для первоначального понимания нафиг не надо, во-вторых миф о сложности уже сложился и авторы пытаются его развеять, чтобы не спугнуть робкого читателя, вместо того, чтобы объяснять просто и по сути.
а проблемы в объяснении в основном имхо такие: во-первых многие пытаются объяснить всё и сразу — а это для первоначального понимания нафиг не надо, во-вторых миф о сложности уже сложился и авторы пытаются его развеять, чтобы не спугнуть робкого читателя, вместо того, чтобы объяснять просто и по сути.
Всё правильно Джонатан написал. Статья автора просто опровергает мнение Грехема. Причём, опровергнуть это мнение Грехема (на счёт элитарных ЯП) так же легко, как ковырнуть в носу. Хотя бы потому, что мнение Грехема — это как раз-таки мнение суперпрограммиста-супердрочера, которое тешит самолюбие таких же суперпрограммистов-супердрочеров. А относительно объективную оценку этому мнению даётся как минимум в древней книге «Peopleware» Листера и ДеМарко:
раз:
Семь ложных надежд руководителя проекта по разработке программного обеспечения
…
5. Смена языка даст гигантские преимущества.
Ответ: Выбор языка имеет значение, потому что он влияет на способ решения проблемы, но опять же, язык оказывает влияние лишь на этапе реализации. Благодаря преувеличениям, некоторые из новых языков попадают в разряд лаетрила. Не исключено, что новое приложение лучше написать, например на PowerBuilder™, а не на COBOL, но даже до появления PowerBuilder существовали способы лучшие, чем COBOL: специализированные инструменты, упрощаюшие запросы и обновления. Если последние несколько десятилетий вы не проспали у голубого телеэкрана, то смена языка не сильно вам поможет. Она может повысить производительность процентов на пять (вряд ли с этим стоит считаться), но не более того.
два:
Что не влияет на производительность
Исследуя результаты состязаний, мы обнаружили, что следующие факторы слабо влияли на производительность или не влияли вовсе:
Язык: Разработчики, использовавшие старые языки, такие как COBOL или Fortran, выполняли задание не хуже тех, кто писал на Pascal и С. Внутри каждой языковой группы распределение производительности было таким же, как в целом по выборке. Единственным исключением из этого наблюдения стал язык ассемблера: участники, писавшие на ассемблере, сильно отстали от всех остальных языковых групп. (Впрочем, люди, пишущие на ассемблере, привыкли к такому положению вещей.)
раз:
Семь ложных надежд руководителя проекта по разработке программного обеспечения
…
5. Смена языка даст гигантские преимущества.
Ответ: Выбор языка имеет значение, потому что он влияет на способ решения проблемы, но опять же, язык оказывает влияние лишь на этапе реализации. Благодаря преувеличениям, некоторые из новых языков попадают в разряд лаетрила. Не исключено, что новое приложение лучше написать, например на PowerBuilder™, а не на COBOL, но даже до появления PowerBuilder существовали способы лучшие, чем COBOL: специализированные инструменты, упрощаюшие запросы и обновления. Если последние несколько десятилетий вы не проспали у голубого телеэкрана, то смена языка не сильно вам поможет. Она может повысить производительность процентов на пять (вряд ли с этим стоит считаться), но не более того.
два:
Что не влияет на производительность
Исследуя результаты состязаний, мы обнаружили, что следующие факторы слабо влияли на производительность или не влияли вовсе:
Язык: Разработчики, использовавшие старые языки, такие как COBOL или Fortran, выполняли задание не хуже тех, кто писал на Pascal и С. Внутри каждой языковой группы распределение производительности было таким же, как в целом по выборке. Единственным исключением из этого наблюдения стал язык ассемблера: участники, писавшие на ассемблере, сильно отстали от всех остальных языковых групп. (Впрочем, люди, пишущие на ассемблере, привыкли к такому положению вещей.)
Берем команду .net-чиков, активно работающих на .net 3.5 и пересаживаем всех на VBA. Или даже просто держим народ с 2005-го года на первом дотнете. И наблюдаем как народ, начиная с самых толковых, сначала начинает сильно больше материться, а потом и вовсе расползается по другим конторам.
Я писал и на C#1.0, и на 3.0. По количеству ошибок и скорости разработки разница очень приличная, явно больше пяти процентов. А это даже не разные языки.
Я писал и на C#1.0, и на 3.0. По количеству ошибок и скорости разработки разница очень приличная, явно больше пяти процентов. А это даже не разные языки.
Совершенно согласен с вами. Я очень доволен Linq и лямбда выражениями, которые реально ускоряют разработку и намного упрощают понимание кода.
> Я писал и на C#1.0, и на 3.0.
> По количеству ошибок и скорости разработки разница очень приличная, явно больше пяти процентов. А это даже не разные языки.
Вы свою кривую обучения учесть не забыли?
> По количеству ошибок и скорости разработки разница очень приличная, явно больше пяти процентов. А это даже не разные языки.
Вы свою кривую обучения учесть не забыли?
Не забыл, действительно есть заметный прирост. Не в разы, конечно, но сильно ощутимый. Ты же не думаешь что дженерики и лямбды в C# просто для пиара добавили?
Я достаточно плохо знаю C#1 и C#3, чтобы думать для чего добавили лямбды в C# (например, тот же LINQ я воспринимаю как декларативный язык — кальку с SQL. Однако его по каким-то причинам считают частично функциональным языком)
Но тем не менее я точно знаю, что кривая обучения как раз может давать эффект прироста скорости кодинга в разы.
А, учитывая особенности человеческого восприятия, существенная часть этого эффекта переносится на счет новых фич и возможностей в языках.
Но тем не менее я точно знаю, что кривая обучения как раз может давать эффект прироста скорости кодинга в разы.
А, учитывая особенности человеческого восприятия, существенная часть этого эффекта переносится на счет новых фич и возможностей в языках.
SQL не определяет способ выполнения запроса, поэтому его можно смело называть декларативным. Но вряд ли функциональным — нет first class functions, например.
Linq to Collections четко определяет порядок вычислений. И использует чисто функциональные примочки — функции высокого порядка, например. Linq To SQL же использует несколько другую фичу — expression trees, которые потом транслируются в SQL-запросы. Так что в C# есть элементы и декларативные, и функциональные.
Насчет кривой обучения — да, опыт дает очень много. Но не нужно преуменьшать роль инструмента. На прошлом проекте приходилось писать и на C#3.0, и на C#1.0 в разных местах. При чем пришлось в одном месте алгоритм переписывать с C#3.0 на 1.0. Разница очень заметна.
Linq to Collections четко определяет порядок вычислений. И использует чисто функциональные примочки — функции высокого порядка, например. Linq To SQL же использует несколько другую фичу — expression trees, которые потом транслируются в SQL-запросы. Так что в C# есть элементы и декларативные, и функциональные.
Насчет кривой обучения — да, опыт дает очень много. Но не нужно преуменьшать роль инструмента. На прошлом проекте приходилось писать и на C#3.0, и на C#1.0 в разных местах. При чем пришлось в одном месте алгоритм переписывать с C#3.0 на 1.0. Разница очень заметна.
Как сказал Doug Hoyte, функциональный язык — это язык, состоящий из функций. SQL, как и питон и лисп и C# и ещё многие — не функционален, потому что его «функции» — на самом деле процедуры, изменяющие и читающие глобальное состояние.
Изменять общее состояние можно и в Хаскеле. Получается он тоже не функциональный?
В C# никто не запрещает делать функции чистыми. Хотя C# и нельзя назвать функциональным языком, многое оттуда в нем есть.
В C# никто не запрещает делать функции чистыми. Хотя C# и нельзя назвать функциональным языком, многое оттуда в нем есть.
Покажите мне на Хаскеле процедуру.
main :: IO ()
Ну, или посложнее:
Выведет:
1
2
3
import Data.IORef
proc var = do c <- readIORef var
writeIORef var (c + 1)
readIORef var >>= (putStrLn . show)
main = do var <- newIORef 0
proc var
proc var
proc varВыведет:
1
2
3
это сильно строгое определение, под него только чисто-функциональные языки попадают (собственно на практике только 1 язык). никто ж не говорит что OCaml или SML не функциональные? но тем не менее там «процедуры» в классическом смысле — оперируют глобальным состоянием
Прости, что я цитатами сыпать буду, но ведь надо же куда-то девать знания, почерпнутые из книг?
«Правила разработки программного обеспечения» от Джима Маккарти и Мишель Маккарти
«Интересно, что аналитики, пресса и клиенты — все наперебой — говорили нам, что рынок нуждался в шаблонах и средствах обработки исключений, и советовали включить их в наш продукт.» Дале: «Зайдите в отдел разработчиков и спросите: Кто из вас не способен выучить С++? Никто не будет поднимать руки или вскакивать на ноги и кричать Я! Я не могу его выучить» Он очень сложный! Нет. Все будут говорить: Мы шаблонов и обработки искоючений (ирония)". Маккарти в этой главе говорит о том, что на самом деле людям нужны были визарды. Кодогенерилки. У того же Листера и ДеМарко в их Peopleware производительность разработчиков с новыми средствами, не важно на каких платформах и языках, растёт на процент в год (или около того). Считайте, что VS 2005 дала вам 1-2% и VS 2008 те же 1-2%
«Правила разработки программного обеспечения» от Джима Маккарти и Мишель Маккарти
«Интересно, что аналитики, пресса и клиенты — все наперебой — говорили нам, что рынок нуждался в шаблонах и средствах обработки исключений, и советовали включить их в наш продукт.» Дале: «Зайдите в отдел разработчиков и спросите: Кто из вас не способен выучить С++? Никто не будет поднимать руки или вскакивать на ноги и кричать Я! Я не могу его выучить» Он очень сложный! Нет. Все будут говорить: Мы шаблонов и обработки искоючений (ирония)". Маккарти в этой главе говорит о том, что на самом деле людям нужны были визарды. Кодогенерилки. У того же Листера и ДеМарко в их Peopleware производительность разработчиков с новыми средствами, не важно на каких платформах и языках, растёт на процент в год (или около того). Считайте, что VS 2005 дала вам 1-2% и VS 2008 те же 1-2%
Мой опыт говорит мне другое. Либо разработчики просто лучше владели первым шарпом, либо вы не измеряли производительность и утверждение «явно больше 5%» вовсе не утверждение, а пук в лужу. Хотя бы потому, что на кодинг всегда уходит гораздо меньше времени, чем на всё остальное в проекте. Так, например, в нашей фирме был крупный проект для Credit Suisse, где мы были привязаны к первому дотнету. Через месяц все даже и не вспоминали о «фишках 3-го шарпа». И производительность не страдала вообще: аналитики компании не брали в рассчёт версию дотнета и по срокам всё было в точности так же, как если бы мы писали на третьем шарпе.
Кроме того, из ваших слов косвенно следует, что разработчики на Яве теперь, по сравнению с ребятами из дотнет, пишут значительно медленнее. Смело могу вас заверить, что это не так.
Кроме того, из ваших слов косвенно следует, что разработчики на Яве теперь, по сравнению с ребятами из дотнет, пишут значительно медленнее. Смело могу вас заверить, что это не так.
Непонятно как это измерять
Сорри, запостил случайно, не закончив мысль.
Я говорил по собственным ощущениям, очевидно что как-то измерить это проблематично.
Ощущения от того, что алгоритмы средней сложности, часто встречаемые в бизнес-приложениях, на LINQ пишутся раза в 2 быстрее, в 2-3 раза компактнее по коду, менее подвержены ошибкам и, особенно, ляпам, а также в разы проще модифицируются.
Плюс лямбды позволяют делать всякие интересные легковесные архитектурные решения без оверхеда.
Я не могу сказать сколько это приносит в итоге процентов, но недооценивать их я бы не стал.
А что аналитики угадали сроки — это, конечно, хорошо, но в сроках масштаб погрешности гораздо больше 5%.
Я говорил по собственным ощущениям, очевидно что как-то измерить это проблематично.
Ощущения от того, что алгоритмы средней сложности, часто встречаемые в бизнес-приложениях, на LINQ пишутся раза в 2 быстрее, в 2-3 раза компактнее по коду, менее подвержены ошибкам и, особенно, ляпам, а также в разы проще модифицируются.
Плюс лямбды позволяют делать всякие интересные легковесные архитектурные решения без оверхеда.
Я не могу сказать сколько это приносит в итоге процентов, но недооценивать их я бы не стал.
А что аналитики угадали сроки — это, конечно, хорошо, но в сроках масштаб погрешности гораздо больше 5%.
Супер язык — бред собачий!
Проблема, которая отличает профи от обычных разрабов — умение выбирать инструментарий. Вы ведь не будете писать драйвера на python«е или лиспе?! 80% программистов до конца своей жизни всё делают на популярных языках (С, Ява и т.д.) не предавая значения тому, что для конкретных задач уже есть решения и более удобные (расчитанные на эту область проблем) языки.
Вот и следствие — ФГМ, мифическое мнение о неких „арийцах“-профи (на самом деле это люди которые просто освоили больше, чем пяток однотипных языков и умеют писать код сами, а не юзать лишь фреймворки и либы) и вера в „чудо“ язык (»вот я его выучу и стану таким крутым-крутым!").
Проблема, которая отличает профи от обычных разрабов — умение выбирать инструментарий. Вы ведь не будете писать драйвера на python«е или лиспе?! 80% программистов до конца своей жизни всё делают на популярных языках (С, Ява и т.д.) не предавая значения тому, что для конкретных задач уже есть решения и более удобные (расчитанные на эту область проблем) языки.
Вот и следствие — ФГМ, мифическое мнение о неких „арийцах“-профи (на самом деле это люди которые просто освоили больше, чем пяток однотипных языков и умеют писать код сами, а не юзать лишь фреймворки и либы) и вера в „чудо“ язык (»вот я его выучу и стану таким крутым-крутым!").
Грэм. Пол Грэм.
Это еще мал людей прониклись Прологом :)
Хотя....
Хотя....
Вы слишком мало знаете о lisp'e
Только вчера на девклубе наткнулся на подобное мнение о лиспе и ООП.
Сейчас в Java кругах модно говорить об АОП. Забавно однако, что в объектную систему Common Lisp'а «АОП» было встроено изначально.
Сейчас в Java кругах модно говорить об АОП. Забавно однако, что в объектную систему Common Lisp'а «АОП» было встроено изначально.
Используют, почему нет?
Первое, что приходит в голову это лисп в маткаде и автокаде.
Первое, что приходит в голову это лисп в маткаде и автокаде.
Не интерпретатор, а аналитическая решалка, хотя там и жуткая смесь с прологом.
Реализаций лиспа тьма, на любых языках и на лиспе тоже и на хаскелле есть. Писать все приложение на лиспе не всегда оправдано — специалисты более дорогие.
Вот здесь один дядька рассказывает как.
Реализаций лиспа тьма, на любых языках и на лиспе тоже и на хаскелле есть. Писать все приложение на лиспе не всегда оправдано — специалисты более дорогие.
Вот здесь один дядька рассказывает как.
> почему, если есть надстройка ООП под Лисп
ООП под Лисп — не надстройка, а часть стандарта, присутствующая везде, а не как в, например, C++.
* (class-of 123)
#<BUILT-IN-CLASS FIXNUM>
* (sb-mop::class-direct-superclasses (class-of 123))
(#<BUILT-IN-CLASS INTEGER>)
> то этот язык не используют в промышленном программировании?
Вы считаете, что для промышленного программирования необходимо и достаточно ООП?
ООП под Лисп — не надстройка, а часть стандарта, присутствующая везде, а не как в, например, C++.
* (class-of 123)
#<BUILT-IN-CLASS FIXNUM>
* (sb-mop::class-direct-superclasses (class-of 123))
(#<BUILT-IN-CLASS INTEGER>)
> то этот язык не используют в промышленном программировании?
Вы считаете, что для промышленного программирования необходимо и достаточно ООП?
Если очень хочется взглянуть на промышленный код на Common Lisp'е — милости просим — качаете с торрентов пакет Symbolics Open Genera 2.0 — это ОС лисп-машины, прилагается оконная система, гипертекстовая документация, поддержка TCP/IP, лиспо-шелл, эмакс, графический редактор, почта, игры, лиспопролог, компиляторы паскаля и С — и всё это целиком и полностью написано на лиспе. Исходники прилагаются.
Запускается и работает на 64-битной Ubuntu.
Запускается и работает на 64-битной Ubuntu.
В современных лиспах ООП — не надстройка, а основа основ. Например, в случае Clojure — это родное Java'вское ООП:
> (class 123)
java.lang.Integer
> (class «asdf»)
java.lang.String
> (class +)
clojure.core$_PLUS___3868
> (instance? java.lang.Object +)
true
> (instance? clojure.lang.IFn +)
true
Ведь ничто не мешает использовать UML в таком случае?
> (class 123)
java.lang.Integer
> (class «asdf»)
java.lang.String
> (class +)
clojure.core$_PLUS___3868
> (instance? java.lang.Object +)
true
> (instance? clojure.lang.IFn +)
true
Ведь ничто не мешает использовать UML в таком случае?
Зачем огроные исходные тексты, когда можно взять какой-нибудь Erlang и поиметь профит в гораздо более сжатые сроки и меньший объем более понятного кода?
Это все очень похоже на вечную дискуссию про режиссеров.
Есть например, Спилберг, который без лишнего шума и пыли собирает раз за разом хорошие кассы.
И есть, скажем, Вачовски, у которых выпендреж через край, а результатов за последние 10 лет — никаких.
Есть например, Спилберг, который без лишнего шума и пыли собирает раз за разом хорошие кассы.
И есть, скажем, Вачовски, у которых выпендреж через край, а результатов за последние 10 лет — никаких.
Нет никаких суперязыков. Просто для *некоторых* задач *некоторые* Лиспы и Хаскели в разы удобнее мейнстримных языков, использующихся в решении мейнстримных задач.
быть может вы ещё и пример сходу назовёте или холивара боитесь? ;)
Кодогенерация, символические вычисления?
я, например, до сих пор не уверен в том, что Хаскелль или Лисп так уж удобны для кодогенерации.
для простейшего случая «обойти деревцо в глубину выплевывая код» разве что.
для простейшего случая «обойти деревцо в глубину выплевывая код» разве что.
В лиспе кодогенерация и вообще любая работа с собственным кодом, такая как символьные вычисления, вытекают из самой структуры языка. Я не знаю, что может быть еще удобнее.
во-первых, я под генерацией кода понимаю широкий класс задач, а не только генерацию «кода на лиспе».
во-вторых, никто не доказал, что генерировать лисп скриптом на питоне скажем неудобно.
во-вторых, никто не доказал, что генерировать лисп скриптом на питоне скажем неудобно.
вероятно, вам следует попробовать и то и то и сделать свой вывод о удобстве :)
для меня удобнее оказался лисп.
для меня удобнее оказался лисп.
> во-вторых, никто не доказал, что генерировать лисп скриптом на питоне скажем неудобно.
Преимущество XSLT перед скриптом на питоне для преобразования хитров*******х XML документов из одной схемы в другую тоже надо доказывать?
Преимущество XSLT перед скриптом на питоне для преобразования хитров*******х XML документов из одной схемы в другую тоже надо доказывать?
Боюсь ранить мнение присутствующих и получить обильную пачку минусов, но скажу. Допустим, если бы у нас была инфраструктура (библиотеки, фреймворки, и т.п.) аналогичная Java'вской, то Common Lisp был бы удобнее, чем Java\C++ для *всех* задач, с редчайшими исключениями.
Если для Common Lisp'а остается лишь гадать «если бы да кабы», то для Clojure осталось лишь запастись попкорном.
Я еще понимаю: хаскель — эзотерический язык, но в лиспе эзотеричности не больше чем в HTML или XML.
Я еще понимаю: хаскель — эзотерический язык, но в лиспе эзотеричности не больше чем в HTML или XML.
Ага. Если бы были живы Lisp-машины, то все было бы по-другому.
Пример редчайшего исключения — численные вычисления и boxing/unboxing.
Это при том, что мне нравится CL. Его практическая применимость довольно сильно ограничена.
Пример редчайшего исключения — численные вычисления и boxing/unboxing.
Это при том, что мне нравится CL. Его практическая применимость довольно сильно ограничена.
Еще пример — где в cl хеш-таблица с возможность своего hash/equal? Не в реализациях по факту, а в спеках? Заново писать?
Где универсальное сравнение? Да, несложно определить свой generic custom-equal, но это будет та же фигня, что и ситуация со строками в C++, где у очень многих библиотек есть свой класс для строки.
Где универсальное сравнение? Да, несложно определить свой generic custom-equal, но это будет та же фигня, что и ситуация со строками в C++, где у очень многих библиотек есть свой класс для строки.
Я не пишу на Common Lisp ибо он фактически умер 20 лет назад.
В качестве лисп-машины меня более чем устраивает JVM.
В качестве лисп-машины меня более чем устраивает JVM.
Описывать численные алгоритмы на Хаскеле удобно, например.
А Лисп, как уже сказали ниже, подходит для всего ;)
А Лисп, как уже сказали ниже, подходит для всего ;)
>> Описывать численные алгоритмы на Хаскеле удобно, например.
а потом сумеете легко предсказать сложно получившегося алгоритма по времени и памяти?
численные алгоритмы они многие о матрицах и их элементах… и всех Фортран до сих пор, наверное, на этом деле побеждает по количеству строчек написанного кода. Товарищи вот в Sisal тужатся создать панацею, но все никак не могут допилить, чтобы производительность нормальная была (= пытаются научить компилятор просекать, где можно иммутабельность выкидывать и без копировать изменять массивы прямо на месте). Иными словами, писать императивные по своей сути алгоритмы на ленивых чистых языках — это плевать против ветра и ждать, что умный компилятор защитит вас своим зонтиком. Компиляторы конечно становятся умней (вон Parallel Haskell двигается к светлому будущему, кажется), но это не избавляет вас от задачи расставлять ему везде подказки (а вот здесь мы хотим форсировать thunk. а вот здесь мы будем использовать грязный мутабельный массивчик). Так зачем же эта головная боль?
а потом сумеете легко предсказать сложно получившегося алгоритма по времени и памяти?
численные алгоритмы они многие о матрицах и их элементах… и всех Фортран до сих пор, наверное, на этом деле побеждает по количеству строчек написанного кода. Товарищи вот в Sisal тужатся создать панацею, но все никак не могут допилить, чтобы производительность нормальная была (= пытаются научить компилятор просекать, где можно иммутабельность выкидывать и без копировать изменять массивы прямо на месте). Иными словами, писать императивные по своей сути алгоритмы на ленивых чистых языках — это плевать против ветра и ждать, что умный компилятор защитит вас своим зонтиком. Компиляторы конечно становятся умней (вон Parallel Haskell двигается к светлому будущему, кажется), но это не избавляет вас от задачи расставлять ему везде подказки (а вот здесь мы хотим форсировать thunk. а вот здесь мы будем использовать грязный мутабельный массивчик). Так зачем же эта головная боль?
Да, да, да. Тоже было на работе один раз — вызывает начальство меня и еще одного программера, описывает задачу и спрашивает за сколько можно сделать? Я прикинул в голове время кодинга, вышло недели 3 и говорю «месяц, на С++» (перестраховался). Коллега мой на меня так посмотрел с презрением: «С++? Месяц? Да я за 3 дня на %какая_то_хрень_даже_не_запомнил% сделаю! Легко!». Начальство с упреком таким на меня посмотрело, мол, хотел месяц балду пинать, а тут люди за 3 дня сделают и отдали ему. Стоит ли говорить, что через месяц задача при готовности 15% была передана мне с формулировкой «выкинуть все сделанное на хрен и написать с нуля на С++». Вложился в 3 недели.
Что говорит о том, что ваш «оппонент» был банально некомпетентен. При чём тут языки?
Статья не только о языках, она еще о страдающих манией величия программистах, желающих писать что им интересно и на чем им интересно при этом не унижаясь такими мелочами, как доделка, отладка и внедрение проекта. Или не дай Бог, использования языков мейнстрима и классических способов разработки.
Это не Лисп крутой, это Грем — крутой.
Есть такой анекдот-история:
«Пришел как-то в гости фотограф, принес с собой пару своих работ, показал, все восхищались. А хозяйка дома сказала: „О! У Вас, наверное, очень хороший фотоаппарат!“. Фотограф промолчал, а когда уходил, сказал: „У Вас был прекрасный стол, все было очень вкусно. У Вас, наверное, очень хорошие кастрюли!“.
Есть такой анекдот-история:
«Пришел как-то в гости фотограф, принес с собой пару своих работ, показал, все восхищались. А хозяйка дома сказала: „О! У Вас, наверное, очень хороший фотоаппарат!“. Фотограф промолчал, а когда уходил, сказал: „У Вас был прекрасный стол, все было очень вкусно. У Вас, наверное, очень хорошие кастрюли!“.
А я не о статье. Я о вашем комментарии.
Что касается статьи — то в ней есть рациональное зерно, конечно.
Проблема же не стоит так, как вы показали в своём комментарии. Проблема же не в том, что «говорил что сделает на супер-крутом языке за 3 дня, а не сделал». Она состоит в том, что для редких языков мало подходящих специалистов, а значит код действительно трудно поддерживать. «Маргинальность» также сказывается и наколичестве готовых решений, и на литературе, во всёй «практичесткой» области.
С другой стороны — то, что не было показано в статье — в таких «редких» языках обкатываются новые и интересные решния, которые со временем попадают в мейстрим.
Иногда случается и такое, что меняются «правила» — и свойства определённых языков становятся действительно нужными, а не только на «о, прикольно». Хороший пример — ерланг.
И всё это невозможно без тех самых «суперпрограммистов-елитаристов». Они тратят своё время на нежизнеспособные вещи, а плодом из труда становятся новые идеи.
This is evolution, baby
Что касается статьи — то в ней есть рациональное зерно, конечно.
Проблема же не стоит так, как вы показали в своём комментарии. Проблема же не в том, что «говорил что сделает на супер-крутом языке за 3 дня, а не сделал». Она состоит в том, что для редких языков мало подходящих специалистов, а значит код действительно трудно поддерживать. «Маргинальность» также сказывается и наколичестве готовых решений, и на литературе, во всёй «практичесткой» области.
С другой стороны — то, что не было показано в статье — в таких «редких» языках обкатываются новые и интересные решния, которые со временем попадают в мейстрим.
Иногда случается и такое, что меняются «правила» — и свойства определённых языков становятся действительно нужными, а не только на «о, прикольно». Хороший пример — ерланг.
И всё это невозможно без тех самых «суперпрограммистов-елитаристов». Они тратят своё время на нежизнеспособные вещи, а плодом из труда становятся новые идеи.
This is evolution, baby
А мне кажется что проблема именно в «говорил что сделает на супер-крутом языке за 3 дня, а не сделал». Не сделал ведь не потому, что дурак там или лентяй. А потому, что язык в первом приближении показался супер-крутым (ну, знаете, там типа: «Вау! Замыкания! Бесконечные списки! Функторы! Лямбда! Круть!») а когда дошло до дела, то оказалось, что каждую бздюльку от логгера до сортировки, от сокетов до форм приходится делать вручную, писать кучу кода в неотлаженной IDE-шке, дебаггера под это дело вообще нету и как это запустить на чужой машине не ясно.
Т.е., Вы, конечно, правы что правильные фичи переходят из редких языков в мейнстрим и не надо сразу вот так брать и критиковать всякие ерланги, и хорошо, что где-то есть спецы по редким технологиям. Но зачем это все мне, программисту-практику, каждый день пишущему код, который должен работать (опять-таки каждый день)? Работа-работой, а хобби всякие и научные изыскания (типа изучения ерланга) — это другое. И нечего их смешивать
Т.е., Вы, конечно, правы что правильные фичи переходят из редких языков в мейнстрим и не надо сразу вот так брать и критиковать всякие ерланги, и хорошо, что где-то есть спецы по редким технологиям. Но зачем это все мне, программисту-практику, каждый день пишущему код, который должен работать (опять-таки каждый день)? Работа-работой, а хобби всякие и научные изыскания (типа изучения ерланга) — это другое. И нечего их смешивать
Опять же — вы описали некомпетентность. «Первое приближение» — это ещё не «знать язык». Может знаток бы назвал другую цифру. При чём тут сам инструмент?
Вам это не нужно? Превосходно — не занимайтесь. Зачем же критиковать тех, кто интересуется? Они дают вам больше работы? Так это же хорошо, значит вы ценнее как специалист. В чём же тогда проблема?
И использовать «специальные» языки на практике очень даже нужно — осознавая конечно все возможные трудности, как то кто будет поддерживать, слабые и сильные стороны самого языка, библиотек, окружения и т.п.. При правильной оценке задачи всё будет отлично. Тот же ерланг очень активно используется на практике без особых проблем. А питон так стал одним из «прикладных» языков — именно потому что его активно использовали, хоть он и был «молодым».
Вам это не нужно? Превосходно — не занимайтесь. Зачем же критиковать тех, кто интересуется? Они дают вам больше работы? Так это же хорошо, значит вы ценнее как специалист. В чём же тогда проблема?
И использовать «специальные» языки на практике очень даже нужно — осознавая конечно все возможные трудности, как то кто будет поддерживать, слабые и сильные стороны самого языка, библиотек, окружения и т.п.. При правильной оценке задачи всё будет отлично. Тот же ерланг очень активно используется на практике без особых проблем. А питон так стал одним из «прикладных» языков — именно потому что его активно использовали, хоть он и был «молодым».
Может быть, это конечно только мне кажется, но статья выглядит как невероятно резкое проявление личного мнения? Которое, причем, претендует на некоторую общность, что, честно сказать, вызывает некоторое сомнение.
Не могу не процитировать Сассмана по этому поводу:
«Решая задачу, попробуйте выразить ее на там языке[в той терминологии], на котором она бы решалась легко».
Так вот, выбор языка(не обязательно языка программирования) во многом определяет способ мышления(он определяет примитивы\выразимость\структуры данных, стандарные модели\паттерны\алгоритмы\библиотеки, личный опыт связанный с языком, синтаксический сахар, сообщество, etc), а тут уже сидит человеческий фактор! А значит и восприятие ЯП во многом зависит от человека, а следовательно, утверждения про супер-языки и их степень применимости во многом субъективны. Что в свою очередь, позволяет усомниться в общности, на которую претендует автор в своей статье.
Не могу не процитировать Сассмана по этому поводу:
«Решая задачу, попробуйте выразить ее на там языке[в той терминологии], на котором она бы решалась легко».
Так вот, выбор языка(не обязательно языка программирования) во многом определяет способ мышления(он определяет примитивы\выразимость\структуры данных, стандарные модели\паттерны\алгоритмы\библиотеки, личный опыт связанный с языком, синтаксический сахар, сообщество, etc), а тут уже сидит человеческий фактор! А значит и восприятие ЯП во многом зависит от человека, а следовательно, утверждения про супер-языки и их степень применимости во многом субъективны. Что в свою очередь, позволяет усомниться в общности, на которую претендует автор в своей статье.
мне понравилось выражение "… они ещё и супердрочеры. Я знаю, я был одним из них."))))
Откровенно)
Откровенно)
Миф?
лучшие языки пока не были прагматичны.
Формулы провалов:
провал на базе спецификаций языка — Prolog, CL, Scheme, Java, C#
слабость на базе имплементаций — Python, R
провал на базе продвижения в массы, как то стандартизация библиотек, позиционирование, поддержка и проч — Haskel, Scheme, Clean
провалы в стратегии:
Prolog — «будем декларативны до конца!»
Common Lisp? — раздули спеку — монстр хуже С++
Haskel, Clean — «мы — язык университетский!»
Scheme — «остаться самой компактной спекой, или таки раздуться? о, боже, за десятилетия мы таки раздулись, раздуемся же до конца!»
Python — «we don't need multiprocessing, we don't need multithreading! we are cool enough»
C#, Java — Enterprise сказала надо, мы всегда ответим: «есть!»
…
лучшие языки пока не были прагматичны.
Формулы провалов:
провал на базе спецификаций языка — Prolog, CL, Scheme, Java, C#
слабость на базе имплементаций — Python, R
провал на базе продвижения в массы, как то стандартизация библиотек, позиционирование, поддержка и проч — Haskel, Scheme, Clean
провалы в стратегии:
Prolog — «будем декларативны до конца!»
Common Lisp? — раздули спеку — монстр хуже С++
Haskel, Clean — «мы — язык университетский!»
Scheme — «остаться самой компактной спекой, или таки раздуться? о, боже, за десятилетия мы таки раздулись, раздуемся же до конца!»
Python — «we don't need multiprocessing, we don't need multithreading! we are cool enough»
C#, Java — Enterprise сказала надо, мы всегда ответим: «есть!»
…
поддерживаю, но Haskell пишется с двумя ll.
В течении 6-ти месяцев после того как начал заниматься Хаскелл думал точно также «Не быть ему в мейнстриме, сложно.»
Но как только поосвоился, теперь на основной работе тянет писать именно на нем, код получается выразительный, самого кода очень мало, но правда есть свои тонкости.
В течении 6-ти месяцев после того как начал заниматься Хаскелл думал точно также «Не быть ему в мейнстриме, сложно.»
Но как только поосвоился, теперь на основной работе тянет писать именно на нем, код получается выразительный, самого кода очень мало, но правда есть свои тонкости.
Oberon, вот, не «раздулся». А толку?
Поменьше эмоций и побольше смысла.
1. Каждый инструмент имеет свой круг задач.
2. Владение некоторыми инструментами формируют определенное мышление.
1. Каждый инструмент имеет свой круг задач.
2. Владение некоторыми инструментами формируют определенное мышление.
The Rise of ``Worse is Better'' by Peter Gabriel, 1989 год.
Еще один познал дзен.
Еще один познал дзен.
Хммм… Я вот уже десять лет как на LabVIEW программирую, и ничё, волосы на ладошках пока не выросли.
Я в свое время прочитал грэмовский «On Lisp». Быть может потом он понаписал маркетингового бреда, но в «On Lisp» он демонстрировал проектирование «снизу вверх» и то, как эта парадигма замечательно реализуется с помощью средств метапрограммирования лиспа. Описываемый им подход вполне универсален и может быть использован в любом другом языке, естественно, с некоторыми коррективами.
«Умники», описываемые автором статьи, встречаются везде. Они необязательно пишут на функциональном Хаскеле или какой-то другой немейнстримовой экзотике. Они вполне могут писать и на C++, щедрой рукой раскидывая по всему проекту притянутые за уши паттерны проектирования. И результат будет такой же: «умнику» станет неинтересно и он уйдет дальше нести свет в массы, а нанятый на его место опытный разработчик с N-летним стажем придет в ужас от увиденного и либо будет поддерживать, либо сможет популярно объяснить, почему этот код неподдерживаем и опишет выгоды от рефакторинга и оценит, сколько этот процесс может занять времени.
Я хочу сказать, что интеллектуальный элитизм развивается не от хеллоуворлдов на Лиспе или Хаскелле, он лишь может в них выражаться. И называть такое явление правильнее будет манией величия, потому как особым интеллектом в таких случаях не пахнет.
«Умники», описываемые автором статьи, встречаются везде. Они необязательно пишут на функциональном Хаскеле или какой-то другой немейнстримовой экзотике. Они вполне могут писать и на C++, щедрой рукой раскидывая по всему проекту притянутые за уши паттерны проектирования. И результат будет такой же: «умнику» станет неинтересно и он уйдет дальше нести свет в массы, а нанятый на его место опытный разработчик с N-летним стажем придет в ужас от увиденного и либо будет поддерживать, либо сможет популярно объяснить, почему этот код неподдерживаем и опишет выгоды от рефакторинга и оценит, сколько этот процесс может занять времени.
Я хочу сказать, что интеллектуальный элитизм развивается не от хеллоуворлдов на Лиспе или Хаскелле, он лишь может в них выражаться. И называть такое явление правильнее будет манией величия, потому как особым интеллектом в таких случаях не пахнет.
«Тьфу пропасть! — говорит она,- и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них».
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.
К несчастью, то ж бывает у людей:
Как ни полезна вещь,- цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них».
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.
К несчастью, то ж бывает у людей:
Как ни полезна вещь,- цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.
>Не важно, какой язык использует великий программист, он всё равно будет на порядки более продуктивен, чем посредственный программист, на чём бы тот не писал.
Посмотрим как великий программист посоревнуется попытавшись написать веб сайт на чем нибудь экзотическом, по сравнения с каким php или python.
Посмотрим как великий программист посоревнуется попытавшись написать веб сайт на чем нибудь экзотическом, по сравнения с каким php или python.
Пока одни исследуют шаблоны программирования, предлагают архитектуру систем, концепции интеграции, изучают различные методики командной работы над проектом, разрабатывают фреймворки и библиотеки, etc… другие посвящают себя вопросу «как написать еще короче».
А третьи уверены, что единственно верный и прогрессивный способ лечить зубы — это засунуть бор-машину вместе с дентистом в рот пациенту. И призывают всех к этому.
А третьи уверены, что единственно верный и прогрессивный способ лечить зубы — это засунуть бор-машину вместе с дентистом в рот пациенту. И призывают всех к этому.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миф о супер языке