Comments 85
И что? Любой язык требует "нешуточного такого runtime". Это называется абстракция, ага.
[... ладно, кроме ассемблера на каком-нибудь PIC-micro.]
[... ладно, кроме ассемблера на каком-нибудь PIC-micro.]
UFO just landed and posted this here
Почему? Это язык общего назначения. Функциональный. На нём можно решить любую алгоритмическую задачу. Язык высокоуровневый. И на нём действительно можно писать кратко. Меня только удивляют утверждения, что это делается только при помощи haskell.
То есть, на Bash, ведь тоже можно писать кратко. Однако, когда любителям haskell показываеш небольшие скрипты они начинают говорить о 'создании программ средствами языка'. Это удивляет несколько.
Честно говоря, не понял сути поста.
С каких пор высокий уровень абстракции является отрицательной чертой?
В наши дни разве что китайский калькулятор не имеет этой самой экосистемы.
Разве при написании того же самого веб-приложения на другом языке вы не будете утверждать, что написали его на этом языке, разве вас как разработчика веб-приложения интересует, на чём написан Apache и уж тем более ядро Linux? В общем, я идеи не уловил совершенно...
Кстати, что за "неявные правила"?
А лично мне Haskell просто интересно изучать (не так быстро, как хотелось бы), потому что язык к этому располагает :)
С каких пор высокий уровень абстракции является отрицательной чертой?
В наши дни разве что китайский калькулятор не имеет этой самой экосистемы.
Разве при написании того же самого веб-приложения на другом языке вы не будете утверждать, что написали его на этом языке, разве вас как разработчика веб-приложения интересует, на чём написан Apache и уж тем более ядро Linux? В общем, я идеи не уловил совершенно...
Кстати, что за "неявные правила"?
А лично мне Haskell просто интересно изучать (не так быстро, как хотелось бы), потому что язык к этому располагает :)
Не просто разминка для мозгов, а способ посмотреть на программирование с другого угла, расширить кругозор и просто получить удовольствие.
Программистов на С также можно обвинить в том что их программы компилируются в машинный код ;)
Программистов на С также можно обвинить в том что их программы компилируются в машинный код ;)
Фактически любой язык требует рантайма, несёт в комплекте библиотеки, сборщики мусора-построители деревьев, работает поверх операционной системы, биндится к другим системам/средам/тулкитам.
Но даже при всём этом, ЯВУ (наподобие Haskell и других) позволяют писать код проще, компактнее и лаконичнее, чем низкоуровневые языки типа С++.
Но даже при всём этом, ЯВУ (наподобие Haskell и других) позволяют писать код проще, компактнее и лаконичнее, чем низкоуровневые языки типа С++.
Эх дожил, уже С++ с его множественным наследованием, шаблонами, стл и бустом называют языком низкого уровня.
Знаете, что с чем у меня ассоциируются перечисляемые и столь любимые "плюсовыми гурами" "высокоуровневые фичи" плюсов и прочего обьектно-ориентированного масс-продукта?
Несколько увиденных мною как-то статей на общую тему - ООП на ассемблере.
Люди всерьёз попытались реализовать на ассемблере то, как они поняли ООП. Доступ к полям объекта "через точечку", инкапсуляция внутреннего представления.
А вызывать "методы" объекта - всё равно путём по-завхозному тщательного складывания аргументов в регистры, рассчитывая их размер в битиках.
"Как бы ООП" - появилось. Для галочки. Заметно удобнее, чтобы уровень абстракции повысился - не стало.
Так же и с ООП как таковым, и с С++ в частности (жабошарпы не дальше ушли - ладно там хоть сборка мусора появилась и некоторая типатипозащищенность, но это ещё слишком мало). Язык, построенный "вокруг ООПа" - это настолько же маразматично непониманием глубинной сущности ЯВУ и переоценкой значимости ООПа как концепции, как и языки, построенные "вокруг машины Тьюринга", или "вокруг постфиксной нотации" - смешно, наглядно, но при отсутствии других положительных черт само по себе никакой пользы не несёт. "ООП? Постфиксная нотация? Ага, прикольно. А что, действительно сильно помогает?"
"Аааабьектно-ааариентированное" программирование с многомудрыми "множественными наследованиями", дизайн-паттерны и плюсовые шаблончики - это костыль на костыле, попытка приблизиться к тому, что в других языках даётся примитивами, компактно и лаконично, без многостраничного путанья в шаблонах и приведения одних абстрактных типов к другим, о чём в других языках просто не задумываются как о чём-то, имеющем ценность большую, чем у оператора сравнения. "Мыкол, бачишь, як эти москали наши клозури кличут? - Як? - "Шаблооон проектииирования Команда" - От уроды."
И Хаскель, надо отметить, далеко не есть "абсолютный идеал высокоуровневого языка". Бывает и получше. Язык, который неспособен модифицировать написанную на нём же программу, возможности архитектуры Фон Неймана, можно считать, и не использует.
Несколько увиденных мною как-то статей на общую тему - ООП на ассемблере.
Люди всерьёз попытались реализовать на ассемблере то, как они поняли ООП. Доступ к полям объекта "через точечку", инкапсуляция внутреннего представления.
А вызывать "методы" объекта - всё равно путём по-завхозному тщательного складывания аргументов в регистры, рассчитывая их размер в битиках.
"Как бы ООП" - появилось. Для галочки. Заметно удобнее, чтобы уровень абстракции повысился - не стало.
Так же и с ООП как таковым, и с С++ в частности (жабошарпы не дальше ушли - ладно там хоть сборка мусора появилась и некоторая типатипозащищенность, но это ещё слишком мало). Язык, построенный "вокруг ООПа" - это настолько же маразматично непониманием глубинной сущности ЯВУ и переоценкой значимости ООПа как концепции, как и языки, построенные "вокруг машины Тьюринга", или "вокруг постфиксной нотации" - смешно, наглядно, но при отсутствии других положительных черт само по себе никакой пользы не несёт. "ООП? Постфиксная нотация? Ага, прикольно. А что, действительно сильно помогает?"
"Аааабьектно-ааариентированное" программирование с многомудрыми "множественными наследованиями", дизайн-паттерны и плюсовые шаблончики - это костыль на костыле, попытка приблизиться к тому, что в других языках даётся примитивами, компактно и лаконично, без многостраничного путанья в шаблонах и приведения одних абстрактных типов к другим, о чём в других языках просто не задумываются как о чём-то, имеющем ценность большую, чем у оператора сравнения. "Мыкол, бачишь, як эти москали наши клозури кличут? - Як? - "Шаблооон проектииирования Команда" - От уроды."
И Хаскель, надо отметить, далеко не есть "абсолютный идеал высокоуровневого языка". Бывает и получше. Язык, который неспособен модифицировать написанную на нём же программу, возможности архитектуры Фон Неймана, можно считать, и не использует.
Так то оно так, только помню я, что и паскаль назывался языком высокого уровня, в котором такими абстракциями и не пахнет.
А насчет костылей, а какой еще существует путь сохранения приемлемой производительности(та причина, почему с++ еще на плаву) при использовании каких то абстракций?
П.С. Насколько я помню, в реализациях ООП на асме, аргументы обычно передавались через стэк.
А насчет костылей, а какой еще существует путь сохранения приемлемой производительности(та причина, почему с++ еще на плаву) при использовании каких то абстракций?
П.С. Насколько я помню, в реализациях ООП на асме, аргументы обычно передавались через стэк.
> Так то оно так, только помню я, что и паскаль назывался языком высокого уровня, в котором такими абстракциями и не пахнет.
Когда-то ГАЗ-2410 тоже считался хорошей современной машиной. Только неумолимый прогресс сдвинул рамки и уровни качества.
> А насчет костылей, а какой еще существует путь сохранения приемлемой производительности(та причина, почему с++ еще на плаву) при использовании каких то абстракций?
На плаву он из-за инертности людской массы, и только.
Производительность во всём цивилизованном мире принято увеличивать в первую очередь высокоуровневыми оптимизациями (ну, говоря упрощённо - квиксорт на жабе всё равно быстрее пузырька на ассемблере), чему (высокоуровневому мышлению) С++ особо не способствует. Впрочем, жабошарпы не сильно лучше. Хаскели-окамлы получше, конечно, хотя и они не являются идеалами ЯВУ.
А ещё в то время как для одних стоит вопрос "сохранения приемлемой производительности на старых ресурсах", для других стоит вопрос "полномерного освоения новых ресурсов". Задачу "эффективно компилироваться в код i386" плюсы ещё как-то решают, а вот "обеспечить удобное и эффективное использование SIMD-архитектуры и параллельных вычислений" - ну вообще ни в зуб ногой. И не смогут. Им нечем. Костыли типа OpenMP - не в счёт, ибо полумеры.
> Насколько я помню, в реализациях ООП на асме, аргументы обычно передавались через стэк.
О да, для повышения удобства высокоуровневого программирования на ассемблере существенно важно, передаются аргументы в функцию через стек или через регистры.
Когда-то ГАЗ-2410 тоже считался хорошей современной машиной. Только неумолимый прогресс сдвинул рамки и уровни качества.
> А насчет костылей, а какой еще существует путь сохранения приемлемой производительности(та причина, почему с++ еще на плаву) при использовании каких то абстракций?
На плаву он из-за инертности людской массы, и только.
Производительность во всём цивилизованном мире принято увеличивать в первую очередь высокоуровневыми оптимизациями (ну, говоря упрощённо - квиксорт на жабе всё равно быстрее пузырька на ассемблере), чему (высокоуровневому мышлению) С++ особо не способствует. Впрочем, жабошарпы не сильно лучше. Хаскели-окамлы получше, конечно, хотя и они не являются идеалами ЯВУ.
А ещё в то время как для одних стоит вопрос "сохранения приемлемой производительности на старых ресурсах", для других стоит вопрос "полномерного освоения новых ресурсов". Задачу "эффективно компилироваться в код i386" плюсы ещё как-то решают, а вот "обеспечить удобное и эффективное использование SIMD-архитектуры и параллельных вычислений" - ну вообще ни в зуб ногой. И не смогут. Им нечем. Костыли типа OpenMP - не в счёт, ибо полумеры.
> Насколько я помню, в реализациях ООП на асме, аргументы обычно передавались через стэк.
О да, для повышения удобства высокоуровневого программирования на ассемблере существенно важно, передаются аргументы в функцию через стек или через регистры.
>Когда-то ГАЗ-2410 тоже считался хорошей современной машиной. Только неумолимый прогресс сдвинул рамки и уровни качества.
Я ведь не ошибусь, если скажу, что как Газ-2410 был когда-то седаном(или чем-то еще) так он и остался им?
>На плаву он из-за инертности людской массы, и только.
Производительность во всём цивилизованном мире принято увеличивать в первую очередь высокоуровневыми оптимизациями (ну, говоря упрощённо - квиксорт на жабе всё равно быстрее пузырька на ассемблере), чему (высокоуровневому мышлению) С++ особо не способствует. Впрочем, жабошарпы не сильно лучше. Хаскели-окамлы получше, конечно, хотя и они не являются идеалами ЯВУ.
А ещё в то время как для одних стоит вопрос "сохранения приемлемой производительности на старых ресурсах", для других стоит вопрос "полномерного освоения новых ресурсов". Задачу "эффективно компилироваться в код i386" плюсы ещё как-то решают, а вот "обеспечить удобное и эффективное использование SIMD-архитектуры и параллельных вычислений" - ну вообще ни в зуб ногой. И не смогут. Им нечем. Костыли типа OpenMP - не в счёт, ибо полумеры.
Высокоуровневые оптимизации - это конечно очень круто, но тот же алгоритм разбора лексем в интерпретаторе известен очень давно и высокоуровнево там ничего не переделаешь. Высокоуровневое мышление в первую очередь идет на базе абстракции, а на каком языке реализовать абстракцию - это уже совсем другой вопрос.
Насчет освоения новых ресурсов, а фреймворк для использования параллельных вычислений вы будете писать на ОКамле? Да, и почему интерпретаторы "языков высокого уровня" базируются на костылях с++?(Кстати еще на си была библиотека process.h с помощью которой довольно легко реализуется многопоточность)
>О да, для повышения удобства высокоуровневого программирования на ассемблере существенно важно, передаются аргументы в функцию через стек или через регистры.
Это не удобство высокоуровнего программирования, это элементарно - правильное использование ассемблера. Да и вообще ассемблеры предназначены для низкого уровня, так что про асм - оффтопик.
Я ведь не ошибусь, если скажу, что как Газ-2410 был когда-то седаном(или чем-то еще) так он и остался им?
>На плаву он из-за инертности людской массы, и только.
Производительность во всём цивилизованном мире принято увеличивать в первую очередь высокоуровневыми оптимизациями (ну, говоря упрощённо - квиксорт на жабе всё равно быстрее пузырька на ассемблере), чему (высокоуровневому мышлению) С++ особо не способствует. Впрочем, жабошарпы не сильно лучше. Хаскели-окамлы получше, конечно, хотя и они не являются идеалами ЯВУ.
А ещё в то время как для одних стоит вопрос "сохранения приемлемой производительности на старых ресурсах", для других стоит вопрос "полномерного освоения новых ресурсов". Задачу "эффективно компилироваться в код i386" плюсы ещё как-то решают, а вот "обеспечить удобное и эффективное использование SIMD-архитектуры и параллельных вычислений" - ну вообще ни в зуб ногой. И не смогут. Им нечем. Костыли типа OpenMP - не в счёт, ибо полумеры.
Высокоуровневые оптимизации - это конечно очень круто, но тот же алгоритм разбора лексем в интерпретаторе известен очень давно и высокоуровнево там ничего не переделаешь. Высокоуровневое мышление в первую очередь идет на базе абстракции, а на каком языке реализовать абстракцию - это уже совсем другой вопрос.
Насчет освоения новых ресурсов, а фреймворк для использования параллельных вычислений вы будете писать на ОКамле? Да, и почему интерпретаторы "языков высокого уровня" базируются на костылях с++?(Кстати еще на си была библиотека process.h с помощью которой довольно легко реализуется многопоточность)
>О да, для повышения удобства высокоуровневого программирования на ассемблере существенно важно, передаются аргументы в функцию через стек или через регистры.
Это не удобство высокоуровнего программирования, это элементарно - правильное использование ассемблера. Да и вообще ассемблеры предназначены для низкого уровня, так что про асм - оффтопик.
> Я ведь не ошибусь, если скажу, что как Газ-2410 был когда-то седаном(или чем-то еще) так он и остался им?
Остался. Зато мир вокруг него изменился.
> а на каком языке реализовать абстракцию - это уже совсем другой вопрос
Тот самый вопрос. На каком языке её будет проще и понятнее всего записать, без синтаксического мусора.
> а фреймворк для использования параллельных вычислений вы будете писать на ОКамле?
Фреймворк? Параллельные вычисления, бывает, и сам язык предоставить может. Взгляните, например, на APL.
> Кстати еще на си была библиотека process.h с помощью которой довольно легко реализуется многопоточность
Даю подсказку - а ещё в Си был malloc. А потом появилась Джава.
> Это не удобство высокоуровнего программирования, это элементарно - правильное использование ассемблера.
Задача ООП - в повышении уровня абстракции. Вводим ООП в ассемблер, вроде как повышаем уровень абстракции... а опа, в него аргументы надо передавать в регистрах. Или в стеке. В нужном порядке. Или в нужных регистрах. Побайтно-вордно-двордно. "Вот на такой фигне и прокалываются" :)
> так что про асм - оффтопик.
Асм хорош тем, что его наглядно можно сравнивать с жабоплюсами, чтобы в параллель сравнить жабоплюсы с хаскелями-окамлами :)
Остался. Зато мир вокруг него изменился.
> а на каком языке реализовать абстракцию - это уже совсем другой вопрос
Тот самый вопрос. На каком языке её будет проще и понятнее всего записать, без синтаксического мусора.
> а фреймворк для использования параллельных вычислений вы будете писать на ОКамле?
Фреймворк? Параллельные вычисления, бывает, и сам язык предоставить может. Взгляните, например, на APL.
> Кстати еще на си была библиотека process.h с помощью которой довольно легко реализуется многопоточность
Даю подсказку - а ещё в Си был malloc. А потом появилась Джава.
> Это не удобство высокоуровнего программирования, это элементарно - правильное использование ассемблера.
Задача ООП - в повышении уровня абстракции. Вводим ООП в ассемблер, вроде как повышаем уровень абстракции... а опа, в него аргументы надо передавать в регистрах. Или в стеке. В нужном порядке. Или в нужных регистрах. Побайтно-вордно-двордно. "Вот на такой фигне и прокалываются" :)
> так что про асм - оффтопик.
Асм хорош тем, что его наглядно можно сравнивать с жабоплюсами, чтобы в параллель сравнить жабоплюсы с хаскелями-окамлами :)
>Фреймворк? Параллельные вычисления, бывает, и сам язык предоставить может. Взгляните, например, на APL.
Фреймворк, компилятор, в сущности то эти параллельные вычисления должны чем-то транслироватся.
>Даю подсказку - а ещё в Си был malloc. А потом появилась Джава.
Которую невозоможно использовать в приложениях интенсивно использующих память.
>Задача ООП - в повышении уровня абстракции. Вводим ООП в ассемблер, вроде как повышаем уровень абстракции... а опа, в него аргументы надо передавать в регистрах. Или в стеке. В нужном порядке. Или в нужных регистрах. Побайтно-вордно-двордно. "Вот на такой фигне и прокалываются" :)
Если повышать уровень абстракции у асма, то выйдет тот же си.
Фреймворк, компилятор, в сущности то эти параллельные вычисления должны чем-то транслироватся.
>Даю подсказку - а ещё в Си был malloc. А потом появилась Джава.
Которую невозоможно использовать в приложениях интенсивно использующих память.
>Задача ООП - в повышении уровня абстракции. Вводим ООП в ассемблер, вроде как повышаем уровень абстракции... а опа, в него аргументы надо передавать в регистрах. Или в стеке. В нужном порядке. Или в нужных регистрах. Побайтно-вордно-двордно. "Вот на такой фигне и прокалываются" :)
Если повышать уровень абстракции у асма, то выйдет тот же си.
Удобное использование SIMD в императивных языках обеспечивается. Собственно, для векторных процессоров проще всего программировать на FORTRAN. OpenMP - это костыль, конечно, и параллельная обработка lambda-графов - это true. Однако, функции без побочных эффектов требуют в два раза больше памяти, например, при умножении матриц. А для HPC это критично.
Вам бы в академию наук! Что интересно, о каких же языках ведется речь, где так просто делаются замыкания, а?
Уважаемый, если вы хотели начинать холивар - начните его отдельным топиком, если же хотели здесь вылить ваш гнев на С/С++ - пишите уж конкретикой, а не абстрактными фразами.
А вообще, ключевая фраза "как они поняли ООП". А откуда вы знаете, что вы правильно поняли ООП и уверены ли вы в том, что вы имеете судить о правильности реализации ООП в том или ином языке? Что-то я вас не припоминаю в создателях парадигмы ООП и ОО-языков.
Вторя вам, "Миколо, а що це за нова мова? -Та хтось знову вчить С/С++ та написав щось для початку, почекай, воно само помре.".
По большому счету, среды для всех языков (ну или для подавляющего большинства) пишутся на С/С++, и почему то в вопросе выбора основы для нового языка никто не выбирает между явой и прологом, а молча берут С и пишут компиляторы.
Именно потому, что специалисты просто пишут, а демагоги - демагогируют.
Уважаемый, если вы хотели начинать холивар - начните его отдельным топиком, если же хотели здесь вылить ваш гнев на С/С++ - пишите уж конкретикой, а не абстрактными фразами.
А вообще, ключевая фраза "как они поняли ООП". А откуда вы знаете, что вы правильно поняли ООП и уверены ли вы в том, что вы имеете судить о правильности реализации ООП в том или ином языке? Что-то я вас не припоминаю в создателях парадигмы ООП и ОО-языков.
Вторя вам, "Миколо, а що це за нова мова? -Та хтось знову вчить С/С++ та написав щось для початку, почекай, воно само помре.".
По большому счету, среды для всех языков (ну или для подавляющего большинства) пишутся на С/С++, и почему то в вопросе выбора основы для нового языка никто не выбирает между явой и прологом, а молча берут С и пишут компиляторы.
Именно потому, что специалисты просто пишут, а демагоги - демагогируют.
> Что интересно, о каких же языках ведется речь, где так просто делаются замыкания, а?
Википедию вам в помощь.
> пишите уж конкретикой, а не абстрактными фразами.
Вы сможете в формате коммента к посту дать объяснение, чем BMW M5 лучше, чем ВАЗ-2110? Боюсь, перечислять все детали будет долго и занудно; более эффективно будет дать общее представление и ощущение.
> и уверены ли вы в том, что вы имеете судить о правильности реализации ООП в том или ином языке
(Хихикнув) Правильность реализации ООП в ассемблере?
Да я даже вопроса такого не ставлю. Меня мало волнует, будет там ООП или не будет. Меня интересует удобство, а не ООП.
> По большому счету, среды для всех языков (ну или для подавляющего большинства) пишутся на С/С++, и почему то в вопросе выбора основы для нового языка никто не выбирает между явой и прологом, а молча берут С и пишут компиляторы.
Ага-ага, без Lex-ов с Yacc-ами, конечно.
Почему-то, кстати, возможностей С/С++/Java/C#/прочей современной модной муры не хватает, чтобы без костылей типа Lex-а с Yacc-ом написать полноценную основу языка. А возможностей того же Haskell - вполне хватает. Не наводит ни на какие мысли, нет?
> Именно потому, что специалисты просто пишут, а демагоги - демагогируют.
Вам английские слово "evangelist" знакомо?
Ну, да ладно. Конкретика, значит? Всем считающим C++/Java/C# за "высокоуровневые языки программирования" будет очень полезно ознакомиться с ICFPC. И попробовать порешать что-нибудь оттуда (пусть даже не на время, сравнивать по эффективности C++ с Haskell-ом каким даже смешно - просто порешать). Будет очень забавно посмотреть, как Boost-ы с STL-ами в этом им помогут :)
Википедию вам в помощь.
> пишите уж конкретикой, а не абстрактными фразами.
Вы сможете в формате коммента к посту дать объяснение, чем BMW M5 лучше, чем ВАЗ-2110? Боюсь, перечислять все детали будет долго и занудно; более эффективно будет дать общее представление и ощущение.
> и уверены ли вы в том, что вы имеете судить о правильности реализации ООП в том или ином языке
(Хихикнув) Правильность реализации ООП в ассемблере?
Да я даже вопроса такого не ставлю. Меня мало волнует, будет там ООП или не будет. Меня интересует удобство, а не ООП.
> По большому счету, среды для всех языков (ну или для подавляющего большинства) пишутся на С/С++, и почему то в вопросе выбора основы для нового языка никто не выбирает между явой и прологом, а молча берут С и пишут компиляторы.
Ага-ага, без Lex-ов с Yacc-ами, конечно.
Почему-то, кстати, возможностей С/С++/Java/C#/прочей современной модной муры не хватает, чтобы без костылей типа Lex-а с Yacc-ом написать полноценную основу языка. А возможностей того же Haskell - вполне хватает. Не наводит ни на какие мысли, нет?
> Именно потому, что специалисты просто пишут, а демагоги - демагогируют.
Вам английские слово "evangelist" знакомо?
Ну, да ладно. Конкретика, значит? Всем считающим C++/Java/C# за "высокоуровневые языки программирования" будет очень полезно ознакомиться с ICFPC. И попробовать порешать что-нибудь оттуда (пусть даже не на время, сравнивать по эффективности C++ с Haskell-ом каким даже смешно - просто порешать). Будет очень забавно посмотреть, как Boost-ы с STL-ами в этом им помогут :)
Lex и Yacc - не костыли. Просто это Unix-way. Использование не одного большого приложения, а комбинации маленьких. Можно конечно встроить Лекс и Як прямо в компилятор, это не сложно, но толку?
Можно, кстати, и встроить. Только не в компилятор, а в язык.
А ещё лучше - сделать язык таким, чтобы в него каждый мог встроить тот же Лекс с Яком, если приспичит. Вот это - задачка для ЯВУ, не так многими ЯВУ и решенная. Lisp way.
Второй вариант - сделать так, чтобы язык мог использоваться для этих задач и без лекса с яком, достаточным набором встроенных примитивов. Бонусом получаем возможность использовать эти примитивы не только в задачах написания DSL, но и в любых других. Haskell way.
А Unix-way... для языка, позиционирующегося как "универсальный", откровенно слаб. Универсальный же язык, нет? - так почему не самим им пользуемся, а внешними средствами его код генерируем?
А ещё лучше - сделать язык таким, чтобы в него каждый мог встроить тот же Лекс с Яком, если приспичит. Вот это - задачка для ЯВУ, не так многими ЯВУ и решенная. Lisp way.
Второй вариант - сделать так, чтобы язык мог использоваться для этих задач и без лекса с яком, достаточным набором встроенных примитивов. Бонусом получаем возможность использовать эти примитивы не только в задачах написания DSL, но и в любых других. Haskell way.
А Unix-way... для языка, позиционирующегося как "универсальный", откровенно слаб. Универсальный же язык, нет? - так почему не самим им пользуемся, а внешними средствами его код генерируем?
А зачем раздувать язык? Если мы можем использовать уже написанные приложения. Если что, эти приложения можно элементарно вызывать из своей программы, и получать результаты в неё же. Есть же тысяча задач, решение каждой же будешь встраивать в язык.
> А зачем раздувать язык
Чтобы сдвинуть баланс в сторону компактности и элегантности записи алгоритмов. Точно так же, как реюзаемый во многих местах программы код мы выносим в библиотеку, имеет смысл реюзаемые во многих программах-библиотеках-задачах концепции выносить в язык. Когда-то в язык выносили string-и - а теперь выносят closure-ы, iterator-ы и decorator-ы, уровень подрос.
Из этого, кстати, замечаем, что языки всегда будут "дышать", изменяться, "лучшего языка" никогда не будет (ну, по понятным причинам - кроме Lisp-а %) ) - ибо будут меняться актуальные задачи.
Чтобы сдвинуть баланс в сторону компактности и элегантности записи алгоритмов. Точно так же, как реюзаемый во многих местах программы код мы выносим в библиотеку, имеет смысл реюзаемые во многих программах-библиотеках-задачах концепции выносить в язык. Когда-то в язык выносили string-и - а теперь выносят closure-ы, iterator-ы и decorator-ы, уровень подрос.
Из этого, кстати, замечаем, что языки всегда будут "дышать", изменяться, "лучшего языка" никогда не будет (ну, по понятным причинам - кроме Lisp-а %) ) - ибо будут меняться актуальные задачи.
А что такое внешнее средство? Yacc написан на Си. Это внешнее по отношению к языку средство? Другая программа, библиотека? Так тогда для чистоты эксперимента IO надо написать на самом Haskell, и компилятор нужен не в СИ, а прямо в ассемблерный код. И сам этот компилятор должен заниматься низкоуровневой оптимизацией, а не складывать всё на Си.
Насчет ICFPC, а вы попробуйте написать простой веб-сервер на Хаскелле, который не будет самым узким местом по производительности.
Ну зачем же на Хаскелле :) Ограничивать себя одним языком программирования - удел code monkeys. Веб-сервер мы будем писать на Эрланге :)
имхо, резюмируя небольшое пикетирование, следует принять как факт "каждый язык для своей цели". Пусть на С пишут системные вещи, на яве/нет кроссплатформы, на лиспе разбирают лингвистику и т.д.
Вообще-то стартом холиварчика явилась фраза, что с++ язык низкого уровня ^_^
П.С. Я с детства люблю холивары.
П.С. Я с детства люблю холивары.
Даже для уровня системных вещей, на должность "штатного макроассемблера", С/С++ недостаточно подходят (не говоря уж про высокий уровень). В них откровенно не хватает более строгой типизации.
это в С/С++ то нет типизации???
Если вы ошибочно намекаете на пресловутую void*, то смею утверждать, что на уровне ассемблера вообще нет типов как таковых, кроме чисел. А уж ява прям и блещет везде Object-ами
Если вы ошибочно намекаете на пресловутую void*, то смею утверждать, что на уровне ассемблера вообще нет типов как таковых, кроме чисел. А уж ява прям и блещет везде Object-ами
По сравнению, например, с Паскалем - можно считать, что нет :)
я уже как-то подзабыл совсем паскаль, не могли бы вы просветить этот вопрос? мне действительно интересно, где в паскале такая жестокая типизация.
В необходимости приводить типы даже для совместимых, но по-разному произошедших типов. В наличии set-ов и enum-ов, защищённых от неправильных значений (и не мешающихся с integer-ами), и способных быть использованными в циклах.
Впрочем, он тоже не идеал для низкого уровня - в нём зачем-то в примитивы выделены integer и boolean, которые великолепно - гораздо лучше - моделируются на базе set-а.
Впрочем, он тоже не идеал для низкого уровня - в нём зачем-то в примитивы выделены integer и boolean, которые великолепно - гораздо лучше - моделируются на базе set-а.
а по моему приведение всего к интежеру как раз и есть "для низкого уровеня", максимально приближенно к процессору ;-)
что же до сетов и энумов, то set это совсем не то, что set . А значение enum-ов вами слишком преувеличено. Это не более, чем числовые константы.
что же до сетов и энумов, то set это совсем не то, что set . А значение enum-ов вами слишком преувеличено. Это не более, чем числовые константы.
поправка: "...то set<int> ... set<char>.."
Под set-ом я имел в виду паскалевый set: "var set1: set of 1..10;", напрямую связанный с enum-ом. Да, кстати, вроде как в Паскале enum с set-ом есть, но аргументами цикла их использовать нельзя (что лишает их основного преимущества). Жаль. Спутал с каким-то другим паскалеподобным языком.
> А значение enum-ов вами слишком преувеличено. Это не более, чем числовые константы.
Ага. Только при этом типозащищённые. В правильный enum (sunday, monday, tuesday) впихнуть значение "3" нельзя, хоть оно туда и влезет. Правильный enum (sunday, monday, tuesday) нельзя передать туда, где аргументом должен быть enum (male, female, not_decided), и тем более туда, где аргументом должен быть байт. Вот это и есть нормальная типизация. А не так, как с Си, благодаря которому в Линуксе, например, у функции ioctl аргумент command имеет тип int.
> А значение enum-ов вами слишком преувеличено. Это не более, чем числовые константы.
Ага. Только при этом типозащищённые. В правильный enum (sunday, monday, tuesday) впихнуть значение "3" нельзя, хоть оно туда и влезет. Правильный enum (sunday, monday, tuesday) нельзя передать туда, где аргументом должен быть enum (male, female, not_decided), и тем более туда, где аргументом должен быть байт. Вот это и есть нормальная типизация. А не так, как с Си, благодаря которому в Линуксе, например, у функции ioctl аргумент command имеет тип int.
излишняя ограниченность - это зло. Калека-программист, который всецело полагается на типо- и прочие защищенности не должен лезть в С/С++. int вполне хороший тип для понятия "команда", нужно точно знать, что за команду ты отдаешь, прежде чем командовать :)
Хотя это демагогия. Имхо, намного удобнее инт, чем энум непонятный. К тому же инт-энум намного быстрее работает, чем полноценный тип-объект.
Хотя это демагогия. Имхо, намного удобнее инт, чем энум непонятный. К тому же инт-энум намного быстрее работает, чем полноценный тип-объект.
1. Возможностей haskell'я не хватает, чтобы сделать полноценную основу языка - попробуйте из haskell jscript сделать. Приходится идти по той же самой дороге: генератор парсера, дописывание парсера под построение нужного дерева, генератор кода, который, кстати, пишется весьма нетривиально - алгоритмы на графах для haskell сложно, даже с монадами.
2. Уже второй раз решаю задачи из ICFP PC на bash + куча утилит, написанных на Си (просто ли реализовать алгоритм поиска MGU на Haskell?) + сам Си. И ничего, решается. А когда я смотрю решения тех же задач на Haskell, меня пробивает дрожь, ибо уровень абстракций просто офигенный. То есть, я смотрю на программы, вижу кучу идентификаторов и почти никакой конкретики. Как так можно писать и думать? Не представляю просто. И, ведь, главное, объём-то кода нисколько не меньше, чем в моих решениях.
Объясните, в чём я не прав?
2. Уже второй раз решаю задачи из ICFP PC на bash + куча утилит, написанных на Си (просто ли реализовать алгоритм поиска MGU на Haskell?) + сам Си. И ничего, решается. А когда я смотрю решения тех же задач на Haskell, меня пробивает дрожь, ибо уровень абстракций просто офигенный. То есть, я смотрю на программы, вижу кучу идентификаторов и почти никакой конкретики. Как так можно писать и думать? Не представляю просто. И, ведь, главное, объём-то кода нисколько не меньше, чем в моих решениях.
Объясните, в чём я не прав?
жжоте, батенька, напалмом! С++ - низкий уровень, это одна из последних первоапрельских шуток, видать.
Не видали вы, наверное, высокого уровня. Кому и кобыла невеста, а Чёрная Волга - представительский класс автомобиля.
На сколько я помню, языками низкого уровня считались только ассемблеры, а все остальные языки были языками высого уровня. А все эти языки с динамической типизацией, модификацией классов на ходу обычно назывались языками сверхвысокого уровня.
Воо, низкий - высокий - сверхвысокий. Не пора ли уже сдвинуть планку вверх, всё равно на ассемблере сейчас уже почти никто не пишет :) ? А сложность задач уже существенно выросла.
Это на ассемблере то никто не пишет? А платформенно зависимые вещи? А программы для простеньких микропроцессоров встраиваемых?
Вооо, еле вспомнили пару областей (хотя сейчас уже даже в часах наручных, похоже, ARM с портированным на него Линуксом). А ведь раньше на асме софт писали. Всерьёз софт писали, с начала и до конца. Жизнь изменилась :)
Почему еле то, как писали эти вещи на асме, так и будут писать. Кстати линух портируют если что то же переписывая часть его ядра на асме под конкретную архетиктуру(ну и перекомпилируя остальную часть)
Эти - да. Пока кросс-компиляторы нормальные не сделают.
А вот нортонкомандир целый или игру какую на ассемблере уже никто не напишет. Всерьёз, ага.
> Кстати линух портируют если что то же переписывая часть его ядра на асме под конкретную архетиктуру(ну и перекомпилируя остальную часть)
Очень маленькую, и из года в год - всё меньшую. А когда-то оси на ассемблере писали целиком...
А вот нортонкомандир целый или игру какую на ассемблере уже никто не напишет. Всерьёз, ага.
> Кстати линух портируют если что то же переписывая часть его ядра на асме под конкретную архетиктуру(ну и перекомпилируя остальную часть)
Очень маленькую, и из года в год - всё меньшую. А когда-то оси на ассемблере писали целиком...
Ну. Это от корявости архитектуры x86. Для некоторых архитектур in/out совсем не нужен. И на ассемблере, как на отдельном языке для них ничего не пишется. Так, вставляется пара-тройка инструкций при помощи встроенного ассемблера GCC. Но этот ассемблер нельзя рассамтривать, как самостоятельный язык, imho. Всё же это часть C, со своими заморочками.
А gcc компилирует на архетиктуру этой платформы по божьему велению?)
Нет. :) Но, ведь, в генераторе генераторов кода (sic), которым пользуются в gcc, тоже нет кода на ассемблере :) Там есть абстрактное описание инструкций.
Вы уж извините, но куда нам за вами поспесть, за вашим "высоким" уровнем. Судя по вашим словам так этот "высокий" каждый год все выше и все на словах да на словах, в недрах болтологии ;)
Кто высоко поднимается, тот низко падает. И довольно скоро закончится время "мнений специалистов" и здравый разум возобладает над болтологией.
Кто высоко поднимается, тот низко падает. И довольно скоро закончится время "мнений специалистов" и здравый разум возобладает над болтологией.
> Судя по вашим словам так этот "высокий" каждый год все выше и все на словах да на словах, в недрах болтологии ;)
Хе-хе. Как когда-то сказал Paul Graham, все языки программирования находятся где-то на отрезке между Fortran-ом и Lisp-ом. Первый - "абсолютно удобен для компьютера, абсолютно неудобен для программиста". Второй - наоборот. Фишки из второго в современные языки тягают уже много лет; то на С++ натянут, то на Джаву, то на Шарп какой, то на Питон-Руби. Чем мощнее компьютеры становятся - тем больше "удобных для программиста, неудобных для компьютера" фишек выдёргивают.
Глядишь, выдернут последнюю фишку - и получится у них второй Lisp.
Так что... высокий уровень, пожалуй, вполне ограничен. Одним язычком программирования, которому в этом году 50 лет исполняется, а более молодые его потомки так его возможностей достигнуть и не могут :)
Хе-хе. Как когда-то сказал Paul Graham, все языки программирования находятся где-то на отрезке между Fortran-ом и Lisp-ом. Первый - "абсолютно удобен для компьютера, абсолютно неудобен для программиста". Второй - наоборот. Фишки из второго в современные языки тягают уже много лет; то на С++ натянут, то на Джаву, то на Шарп какой, то на Питон-Руби. Чем мощнее компьютеры становятся - тем больше "удобных для программиста, неудобных для компьютера" фишек выдёргивают.
Глядишь, выдернут последнюю фишку - и получится у них второй Lisp.
Так что... высокий уровень, пожалуй, вполне ограничен. Одним язычком программирования, которому в этом году 50 лет исполняется, а более молодые его потомки так его возможностей достигнуть и не могут :)
хаскел, имхо, хорошая разминка для мозгов :)
> "Эх. Проблема в том, что мы живём в век дезинформации, мнений авторитетов и сверхспециализации."
главное, что бы умные люди оставались при своем мнении и поменьше слушали деланых "авторитетов".
> "Эх. Проблема в том, что мы живём в век дезинформации, мнений авторитетов и сверхспециализации."
главное, что бы умные люди оставались при своем мнении и поменьше слушали деланых "авторитетов".
Так таки авторитеты бывают и правы. Проблема в том, что эти авторитеты не желают вступать в открытые обсуждения.
Вообще говоря, я тут почитал небольшой спор повыше. Там несколько раз упомянался Haskell, что к теме разговора относится. Как я понимаю, основные pro за этот язык:
1. Его семантика позволяет 'встроить' в язык нечто, например, parser, естественно при помощи библиотеки для генерации парсера (вроде как? кстати, интересно было бы посмотреть на таковую для Haskell). Но опять же непонятно, чем это отличается от решения на Си, когда его семантика позволяет написать не тот же генератор парсеров, а потом при помощи него сгенерировать нужный... Хм. В чём принципиальное отличие?
2. Haskell - высокоуровневый и это круто. Ну, высокоуровневость очевидна. Но... Так ли уж она нужна - вот в чём вопрос. Да, вполне возможно, одна строчка на haskell заменяет 10 строчек на Си. НО, вот вам contra к этой ситуации: я не могу тонко настроить поведений этой абстракции, а в 10 строчках я абсолютно свободен. И большие абстракции воспринимать гораздо сложнее. Сможет ли человек въехать в интегралы и правильно начать их использовать имея представление только об их свойствах (а это, собственно, и есть абстрагирование).
Поэтому какая-то непонятка и выходит. Получается, что берутся какие-то довольно абстрактные ценности и утверждается, что раз язык этими ценностями обладает, то он хороший. Действительно победа искусства абстрагирования. Кстати, в обсуждениях активно раскручиваемых языков, вроде Java и C++, так же часто принимается эта техника: мол язык хороший, потому что в нём можно сделать вот это (далее идёт три строчки оперирования шаблонами и множественным наследованием), но непонятно, с какой целью.
При этом нормальных экспертных оценок нет. А, может, нет и нормальных экспертов.
Вообще говоря, я тут почитал небольшой спор повыше. Там несколько раз упомянался Haskell, что к теме разговора относится. Как я понимаю, основные pro за этот язык:
1. Его семантика позволяет 'встроить' в язык нечто, например, parser, естественно при помощи библиотеки для генерации парсера (вроде как? кстати, интересно было бы посмотреть на таковую для Haskell). Но опять же непонятно, чем это отличается от решения на Си, когда его семантика позволяет написать не тот же генератор парсеров, а потом при помощи него сгенерировать нужный... Хм. В чём принципиальное отличие?
2. Haskell - высокоуровневый и это круто. Ну, высокоуровневость очевидна. Но... Так ли уж она нужна - вот в чём вопрос. Да, вполне возможно, одна строчка на haskell заменяет 10 строчек на Си. НО, вот вам contra к этой ситуации: я не могу тонко настроить поведений этой абстракции, а в 10 строчках я абсолютно свободен. И большие абстракции воспринимать гораздо сложнее. Сможет ли человек въехать в интегралы и правильно начать их использовать имея представление только об их свойствах (а это, собственно, и есть абстрагирование).
Поэтому какая-то непонятка и выходит. Получается, что берутся какие-то довольно абстрактные ценности и утверждается, что раз язык этими ценностями обладает, то он хороший. Действительно победа искусства абстрагирования. Кстати, в обсуждениях активно раскручиваемых языков, вроде Java и C++, так же часто принимается эта техника: мол язык хороший, потому что в нём можно сделать вот это (далее идёт три строчки оперирования шаблонами и множественным наследованием), но непонятно, с какой целью.
При этом нормальных экспертных оценок нет. А, может, нет и нормальных экспертов.
есть одно небольшое заблуждение, которое будем вам contra. Языки сравнивать принципиально нельзя. Смешными выглядят потуги сравнивать десятки языков на типичных задачах, где каждый язык вырывается там, где он наиболее адекватен.
<имхо>
суть в том, что новые языки стараются приобрести черты человеческого мышления категориями и общими понятиями, а не разложением на атомарные операции. Отсюда и масштабное абстрагирование. Хорошо это или плохо - время покажет. Опять же смотря для какой задачи. В этом и суть - найдет ли хаскел свою нишу или же так и останется разминкой для мозгов.
</имхо>
<имхо>
суть в том, что новые языки стараются приобрести черты человеческого мышления категориями и общими понятиями, а не разложением на атомарные операции. Отсюда и масштабное абстрагирование. Хорошо это или плохо - время покажет. Опять же смотря для какой задачи. В этом и суть - найдет ли хаскел свою нишу или же так и останется разминкой для мозгов.
</имхо>
Хм... Не. Imho, вы немного смещаете акцент. У нас же есть очень высокоуровневые императивные языки. Взять тот же MATLAB, ну, или JavaScript (тут, конечно, есть кусочки и от функциональных языков, но основа императивная). И возникает вопрос: человек мыслит более близко к функциональному стилю, или к императивному? Или есть и тот и другой тип мышления. В последнем случае, кстати, всё-равно остаётся вопрос: а какой тип мышления эффективнее в большинстве случаев. Ну, то есть, какой язык предпочтительно узнавать досконально, а какой использовать для разминки мозга.
Вобщем не понятно.
Вобщем не понятно.
>"Ну, то есть, какой язык предпочтительно узнавать досконально, а какой использовать для разминки мозга."
на данный момент все довольно просто. Опять же зная С/С++ вы легко овладеете большинством современных языков, так как подавляющая часть из них С-подобная (имеются ввиду используемые, а не богом забытые), даже паскаль в инкарнации делфи приобрел много черт С++.
Есть еще лисп, пролог, да хаскел тот же, которые либо узконишевые, либо как разминка :) Скажем так, мейнстримовые языки все С-подобные. И с этой точки зрения, если есть желание знать много языков, то стоит начинать с С/С++.
Но если есть желание поговорить с компом на человеческом языке, тогда С будет обузой, хотя это и возможно. Стоит для примера вспомнить MUDs с командной строкой, это как прообраз языка. Говорят пролог и ИИ неразлучны, сложно судить, я о прологе мало что знаю. Вполне возможно, что на таких нишевых языках и будет создано нечто человекоподобное. Но маловероятно. Скорей всего, опять таки возьмут С, сделают ЧелоЗык 0.0.1 и понесется ветка за веткой, релиз за релизом, срастется комьюнити, а там глядишь и родится что-нибудь. Все-таки спецы пролога-лиспа заняты своим делом ;-)
на данный момент все довольно просто. Опять же зная С/С++ вы легко овладеете большинством современных языков, так как подавляющая часть из них С-подобная (имеются ввиду используемые, а не богом забытые), даже паскаль в инкарнации делфи приобрел много черт С++.
Есть еще лисп, пролог, да хаскел тот же, которые либо узконишевые, либо как разминка :) Скажем так, мейнстримовые языки все С-подобные. И с этой точки зрения, если есть желание знать много языков, то стоит начинать с С/С++.
Но если есть желание поговорить с компом на человеческом языке, тогда С будет обузой, хотя это и возможно. Стоит для примера вспомнить MUDs с командной строкой, это как прообраз языка. Говорят пролог и ИИ неразлучны, сложно судить, я о прологе мало что знаю. Вполне возможно, что на таких нишевых языках и будет создано нечто человекоподобное. Но маловероятно. Скорей всего, опять таки возьмут С, сделают ЧелоЗык 0.0.1 и понесется ветка за веткой, релиз за релизом, срастется комьюнити, а там глядишь и родится что-нибудь. Все-таки спецы пролога-лиспа заняты своим делом ;-)
вот, кстати, интересная статейка с табличками.
Prolog на мой вкус - это интерфейс к алгоритму поиска наиболее общего унификатора (я уже упомянул это). Вероятно, ошибочно на него навешивать большее. Практика это доказывает. ИИ же не сводится к простому логическому алгоритму.
А насчёт Haskell - вот и не понятно. Нишевой это язык или нет? Переписывают же Linspire на нём. Чем это вызвано? Просто совершенно непонятно, какие выгоды даёт программирование на Haskell. Лично я вижу, что только осознание собственной крутости программисту. Та же пресловутая жёсткая система типов - с одной стороны хорошо, а с другой, чтобы выделить часть структуры приходится писать обёртку из функций. Как-то это выглядит странновато. Но вполне вероятно, что такое восприятие происходящего - профессиональный деффект программистов на си. И в Haskell действительно что-то есть. Вот только эксперты от Haskell не желают объяснять, что именно.
Тем более. Что до productivity, так объём кода на Haskell при решении типовых задач (я опять ссылаюсь на shootout.alioth.debian.org) не намного меньше, чем объём кода решений на Си. В чём выгода-то?
А насчёт Haskell - вот и не понятно. Нишевой это язык или нет? Переписывают же Linspire на нём. Чем это вызвано? Просто совершенно непонятно, какие выгоды даёт программирование на Haskell. Лично я вижу, что только осознание собственной крутости программисту. Та же пресловутая жёсткая система типов - с одной стороны хорошо, а с другой, чтобы выделить часть структуры приходится писать обёртку из функций. Как-то это выглядит странновато. Но вполне вероятно, что такое восприятие происходящего - профессиональный деффект программистов на си. И в Haskell действительно что-то есть. Вот только эксперты от Haskell не желают объяснять, что именно.
Тем более. Что до productivity, так объём кода на Haskell при решении типовых задач (я опять ссылаюсь на shootout.alioth.debian.org) не намного меньше, чем объём кода решений на Си. В чём выгода-то?
мне вот видится только одна причина, пока. Те, кто страстно желает програмимровать, но не может освоиться с идиомами С/ява/..., тот берет хаскел и смотрит на мир перпендикулярно. Мне, как старому С-шнику хаскел не понятен. Не сам синтаксис, а именно цель его. А кому-т может не понятен С/..., а вот хаскел прийдется по душе.
Крайне маловероятная ситуация. Все известные мне люди интересующиеся или всерьёз занимающиеся «нетрадиционными» языками, в первую очередь функциональными, хорошо знакомы с Си, Java и иже с ними. Чаще всего, используют их в работе. То есть первично именно желание перевернуть своё представление о программировании.
Как C может быть непонятен? Да и в Haskell нет никакой загадки, там всего пара базовых конструкций. Но... Когда программы увеличиваются, то они превращаются в кашу из идентификаторов. Хм...
А. Вот, вероятно, в чём проблема с восприятием Haskell - слишком много промежуточных абстракций. То есть, пока программки небольшие, то всё просто. А когда они увеличиваются, то, чтобы добраться до сути, приходится проходить много уровней до реальный операций.
Хм... Как-то не знаю.
А. Вот, вероятно, в чём проблема с восприятием Haskell - слишком много промежуточных абстракций. То есть, пока программки небольшие, то всё просто. А когда они увеличиваются, то, чтобы добраться до сути, приходится проходить много уровней до реальный операций.
Хм... Как-то не знаю.
имел неосторожность заниматься преподаванием С/С++ и вот в чем заключается непонятность :) Первая же ситуация - это массивы-указатели-строки. По сути - это одно и то же, но вот как новичку это объяснить? :) Приходится выдумывать множество образов с ящичками и стопочками, что бы за одно занятие уместить хотя бы общее понятие.
Не "крутость", а мозг, мозг прежде всего разворачивается в интересную сторону. Это главная выгода на мой взгляд. Смотришь на многие вещи шире, и неважно на чем программировать.
Haskell вообще говоря был в первую очередь экспериментальным языком, он содержит очень много интересных решений, очень мало неприятных хаков и то, что при этом на нем можно отлично писать реальные приложения это же замечательно!
Конкретные задачи, для решения которых (имхо) разумно выбрать хаскель: на нем очень удобно и приятно писать парсеры, компиляторы, на базе хаскеля можно легко и непринужденно делать приятные embedded dsl. Смотрите примеры из этой области, если хотите увидеть реальные мощные преимущества, а лучше сами попробуйте ;)
Haskell вообще говоря был в первую очередь экспериментальным языком, он содержит очень много интересных решений, очень мало неприятных хаков и то, что при этом на нем можно отлично писать реальные приложения это же замечательно!
Конкретные задачи, для решения которых (имхо) разумно выбрать хаскель: на нем очень удобно и приятно писать парсеры, компиляторы, на базе хаскеля можно легко и непринужденно делать приятные embedded dsl. Смотрите примеры из этой области, если хотите увидеть реальные мощные преимущества, а лучше сами попробуйте ;)
у меня нет реальных данных на руках, но смею усомниться в скорости парсеров/компиляторов н хаскеле. Если у кого-то есть какие-либо сравнения скорости работы хакела и С в области компиляторов/парсеров, с удовольствием посмотрел бы.
Уже даже средние проекты на С/С++ компилятся довольно долго, а крупные собираются больше часа (а то и нескольких). Даже если такие вещи приятно писать, то пользоваться ими будет крайне неприятно именно из-за скорости.
Уже даже средние проекты на С/С++ компилятся довольно долго, а крупные собираются больше часа (а то и нескольких). Даже если такие вещи приятно писать, то пользоваться ими будет крайне неприятно именно из-за скорости.
Haskell скорее всего будет несколько медленнее, да, но далеко не всегда это критично.
А C++ это очень специфичный пример, один из самых сложных языков в плане написания компилятора к нему, и при этом у него практически отсутствует поддержка модулей/библиотек в результате этого, чтобы скомпилировать один .cpp файл компилятору приходится обрабатывать десятки и сотни тысяч строк хедеров.
А C++ это очень специфичный пример, один из самых сложных языков в плане написания компилятора к нему, и при этом у него практически отсутствует поддержка модулей/библиотек в результате этого, чтобы скомпилировать один .cpp файл компилятору приходится обрабатывать десятки и сотни тысяч строк хедеров.
Хм. Не факт. Насчёт мозга. Вы вот можете конкретно идентифицировать в чём этот разворот?
Хаков же полно, на мой взгляд. Чем монады не хак? В том же C, по моим представлениям, все хаки связанны не с попытками добиться от самого Си каких-то действий, а с хаками именно системы. Монады же, а далее и спектры всякие - это чисто языковые хаки. Типа: простыми средствами добиться не можем, поэтому изобретаем обёртки.
БррРрр. Я пробовал писать парсер, для простенькой грамматики для выражений. У меня не получилось сделать нормальную обработку ошибок, и восстановление состояния этого парсера после ошибки.
Сейчас я, конечно, понимаю, как это делается через Maybe и через прочие... Но назвать это простым язык не поворачивается. Или я чего-то определённо не понимаю.
Приемущество же в том, что строки представляются списками и по ним ходить удобно. Это мои ощущения. Но, может быть, у вас есть пример готового парсера какого-нибудь, на который можно посмотреть?
Хаков же полно, на мой взгляд. Чем монады не хак? В том же C, по моим представлениям, все хаки связанны не с попытками добиться от самого Си каких-то действий, а с хаками именно системы. Монады же, а далее и спектры всякие - это чисто языковые хаки. Типа: простыми средствами добиться не можем, поэтому изобретаем обёртки.
БррРрр. Я пробовал писать парсер, для простенькой грамматики для выражений. У меня не получилось сделать нормальную обработку ошибок, и восстановление состояния этого парсера после ошибки.
Сейчас я, конечно, понимаю, как это делается через Maybe и через прочие... Но назвать это простым язык не поворачивается. Или я чего-то определённо не понимаю.
Приемущество же в том, что строки представляются списками и по ним ходить удобно. Это мои ощущения. Но, может быть, у вас есть пример готового парсера какого-нибудь, на который можно посмотреть?
Сдвиг мозга это субъективно конечно, зависит от бэкграунда. В хаскеле многие вещи просто сделаны "правильно", то есть стройно и красиво прежде всего это касается системы типов.
Монады не хак потому что они реализуются средствами языка и в системе типов ничего специально под монады не докручивалось.
Насчет парсера своего ничего под рукой нету, но вот это например хороший пример. Но лучше поиграться преимущества в том, что это (опять же) красиво ложится на мощную систему типов, и в том как эти монадические парсеры легко, как кубики, с друг другом комбинируются.
Монады не хак потому что они реализуются средствами языка и в системе типов ничего специально под монады не докручивалось.
Насчет парсера своего ничего под рукой нету, но вот это например хороший пример. Но лучше поиграться преимущества в том, что это (опять же) красиво ложится на мощную систему типов, и в том как эти монадические парсеры легко, как кубики, с друг другом комбинируются.
Да, забыл с помощью тех же monadic parser, например в библиотеке Harpy реализован дизассемблер x86. И еще ассемблер в виде DSL (можно посмотреть вот тут).
Ну. Всё-таки хаком принято называть способ, которым добиваются от системы некоторого оригинального поведения, но в рамках этой системы. Поэтому монады - это классический хак.
Писать парсеры при помощи parsec - это удобно, конечно. Но это не написание вручную. А на том же Си парсер пишется вручную, при этом, довольно удобно и прямолинейно. Кода выходит больше, но он понятен от начала и до конца. Чего не скажешь о Haskell. Даже зная, как работает LL(1) парсер, понять, что происходит в программе на уровне абстракций, отличном от parsec - сложно.
Помогает ли в этом разобраться мощная система типов, или она только запутывает? - не понятно.
Писать парсеры при помощи parsec - это удобно, конечно. Но это не написание вручную. А на том же Си парсер пишется вручную, при этом, довольно удобно и прямолинейно. Кода выходит больше, но он понятен от начала и до конца. Чего не скажешь о Haskell. Даже зная, как работает LL(1) парсер, понять, что происходит в программе на уровне абстракций, отличном от parsec - сложно.
Помогает ли в этом разобраться мощная система типов, или она только запутывает? - не понятно.
Sign up to leave a comment.
Haskell