Что является высшим приоритетом в программировании?
Фрэймворки? Производительность?
На мой взгляд важнейшим являются простота ЯП и возможность посредством ЯП сохранять код
максимально простым и однозначным.
И здесь я вижу пока лишь два кандидата.
Почему lisp? потому что это первый(только подумайте) ЯП со сборщиком мусора. Только одно это убрало огромное кол-во сложности.
Второе это выражение программы в виде близком к АСТ. однозначность любой конструкции позволяет однозначно записывать любые конструкции.
Почему rust? Утверждают что компилятор раста не позволяет выполнить неправильные операции с памятью. нереально круто.
Еще в обоих ЯП мы может отделить структуры данных от методом их обработки. Это существенно упрощает код.
Ну и 3-е это конечно возможности мета-программирования. только они могут довести принцип DRY до совершенства.
еще одно приемушество перед другими ЯП что раст что лисп базируются на выражениях в противоположность инструкциям.
И пока хейтеры кричат: скобочки, каша и т.п. кто-то создает чистый код на этих ЯП.
остается лишь нерешенным вопрос: static || dynamic.
Здравствуйте, varenikAA, Вы писали:
AA>Что является высшим приоритетом в программировании? AA>Фрэймворки? Производительность? AA>На мой взгляд важнейшим являются простота ЯП и возможность посредством ЯП сохранять код AA>максимально простым и однозначным. AA>И здесь я вижу пока лишь два кандидата.
C и LUA
изучил, как там работает interop / native API или как называется та технология, которая реализует вызовы из lisp в rust и обратно ?
ТС это не нужно и неинтересно, он восхищается красотой которую видит в этих языках. К их практическому применению это не имеет никакого отношения.
Здравствуйте, varenikAA, Вы писали:
AA>Что является высшим приоритетом в программировании? AA>И здесь я вижу пока лишь два кандидата.
Неужели тухлее темы не было?? Прибежать с двумя аутсайдерами и сотрясать как идолом. Провокации — их если пишешь, в них должен быть ... интеллект какой-то что ли! А эти вбросы оставь первокурсникам. Или ты уже на втором?
Здравствуйте, varenikAA, Вы писали:
AA>Таких ЯП как си и луа вагон, а лисп и раст уникальны даже по отношению друг к другу. AA>раст кстати имеет отдельные черты оберона в части полиморфизма.
Уникальны sql, erlang, forth, prolog, brainfuck... а раст и lisp как раз совершенно обычные языки.
Просто lua собирается C компилятором, а C есть почти везде при желании можно самому поменять.
Синтаксис простой в изучении и очень гибкий.
Ни Lisp, ни Rust не являются простыми ЯП. Простой ЯП это виртовский Паскаль, например.
Теперь по поводу сложности ЯП. Суть в том, что реальность сложная. Да, порой программисты её переусложняют ещё больше, но даже если ты не привносишь ни толики дополнительной сложности, то реальность остаётся сложной. Простые задачи решать обычно не нужно. И сложность задачи неизменно выливается в сложность решения. Это можно назвать законом сохранения сложности. Нельзя решить сложную задачу просто. Если это кто-то делает, значит где-то подвох, где-то эту сложность спрятали.
К примеру есть задача менеджмента памяти. В постановке задачи часто нет ограничений на размер входных данных. Это вызывает необходимость выделять память разного размера и освобождать её. От этой сложности не уйти. Но её можно спрятать за сборщиком мусора. Таким образом сложность задачи перешла в сложность реализации рантайма.
Чаще всего и очевидней всего сложность прячется в библиотеках. Например есть сложный формат XML, но для программиста вся сложность в том, чтобы выучить, как правильно пользоваться каноничной библиотекой для работы с XML, а про всё остальное уже подумали разработчики библиотеки.
Но если всё писать на виртовском Паскале, окажется, что сама структура кода получается довольно сложной и упростить её никак не получится. Отсюда и берётся нужда в сложных ЯП. Когда сложность структуры кода переносится в сложную семантику ЯП и в результате получается простой код, который решает сложную проблему. А структурная сложность спрятана в компиляторе и рантайме, которые обеспечивают выполнение сложной задачи простым по виду кодом.
Это всё звучит довольно заумно. Поэтому попробую привести пример. К примеру есть понятие полиморфизма в ООП. Это когда у нас есть интерфейс с виртуальными методами и несколько реализаций. Во многих кодовых базах на языке C этот паттерн реализован, например в Linux kernel, Gtk. Там он реализован "просто" — есть таблица с указателями на функции, есть указатель на эту таблицу в объекте (ну или сразу указатели на функции в объекте). Понятное дело, что в C это требует множества служебного кода. Частично это можно спрятать за макросами, но очень частично. А в C++ этот паттерн встроен в язык и позволяет решать эту задачу кодом, который выглядит просто и изящно. А всю работу по этим таблицам функций и непрямым вызовам выполняет компилятор. Ещё один пример — мультиметоды. Если там нужны полиморфные функции, реализация которых зависит не от одного объекта, как в классическом ООП, а от двух и более объектов, в ООП предлагается применять паттерн визитор. Довольно много писанины. С мультиметодами всё выходит очень просто и понятно, хотя внутри будет, вероятно, примерно то же — таблица с указателями на таблицы и тд.
Но в любом случае сложность языка требует понимания этого языка. Выигрыш тут в том, что сложность языка достаточно выучить один раз, а использовать его можно в тысячах программ. Но, тем не менее, практика показывает, что бесконтрольное усложнение языка приводит к тому, что люди перестают его осиливать. Поэтому нужна золотая середина.
Собственно современные ЯП и пытаются найти эту золотую середину и проводят её в разных местах. Поэтому сложные ЯП нужны, но не слишком переусложнённые.
изучил, как там работает interop / native API или как называется та технология, которая реализует вызовы из lisp в rust и обратно ?
времени не хватает. читаю практичный лисп на лиспер.ру
Здравствуйте, varenikAA, Вы писали:
AA>Что является высшим приоритетом в программировании? AA>Фрэймворки? Производительность?
Каждый в своем пузыре сидит и, соответственно, имеет свои приоритеты. "Высшего" нет, все относительно.
Для кого-то приоритет "решение проблем заказчика максимально быстро и качественно за минимальные деньги" (см. выше), для кого-то "минимизировать количество багов любой ценой" (авиакосмическая отрасль), для кого-то "иметь принципиальную возможность выразить на языке нужные концепции" (что-нибудь с высокой сложностью/абстрактностью предметной области, математические движки условно), для кого-то "возможность быстрого создания интересной программы", для кого-то просто фан от программирования. И так далее.
Здравствуйте, Kolesiki, Вы писали:
K>Неужели тухлее темы не было?? Прибежать с двумя аутсайдерами и сотрясать как идолом. Провокации — их если пишешь, в них должен быть ... интеллект какой-то что ли! А эти вбросы оставь первокурсникам. Или ты уже на втором?
Еще не выбрал куда поступать. Тема нормальная.
Здравствуйте, varenikAA, Вы писали:
AA>с первым согласен полностью, но только вот гибкость у него такая себе(низкоуровневая, требует думать как машина).
И как думает машина?
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, varenikAA, Вы писали:
AA>>с первым согласен полностью, но только вот гибкость у него такая себе(низкоуровневая, требует думать как машина). _>И как думает машина?
укзатели, кругом указатели и ассемблерные вставки.
Здравствуйте, varenikAA, Вы писали:
AA>Что является высшим приоритетом в программировании? AA>Фрэймворки? Производительность? AA>На мой взгляд важнейшим являются простота ЯП и возможность посредством ЯП сохранять код
Экосистема.
Rust очень сложный язык, кстати. Не концептуально, это было бы простительно, а своими синтаксическими прибабахами.
Здравствуйте, kov_serg, Вы писали:
AA>>Таких ЯП как си и луа вагон, а лисп и раст уникальны даже по отношению друг к другу. AA>>раст кстати имеет отдельные черты оберона в части полиморфизма. _>Уникальны sql, erlang, forth, prolog, brainfuck... а раст и lisp как раз совершенно обычные языки.
Нет, я не согласен. Лисп — он такой первый. Чуть ли даже не раньше Фортрана появился (или чуть позже его, тут я могу напутать).
Здравствуйте, Kolesiki, Вы писали:
K>Неужели тухлее темы не было?? Прибежать с двумя аутсайдерами и сотрясать как идолом. Провокации — их если пишешь, в них должен быть ... интеллект какой-то что ли! А эти вбросы оставь первокурсникам. Или ты уже на втором?
Здравствуйте, varenikAA, Вы писали:
AA>Что является высшим приоритетом в программировании? AA>Фрэймворки? Производительность?
Умение абстрагироваться от конкретных языков программирования, фреймворков и библиотек. Способность спроектировать и реализовать красивую, простую и понятную систему. Грубо говоря, умение работать на мета уровне.
AA>На мой взгляд важнейшим являются простота ЯП и возможность посредством ЯП сохранять код AA>максимально простым и однозначным.
Можно писать максимально просто и однозначно даже на самом ужасном языке программирования. А можно писать максимально ужасно на самом простом и красивом языке.
B> Можно писать максимально просто и однозначно даже на самом ужасном языке программирования. А можно писать максимально ужасно на самом простом и красивом языке.
А можно прийти устраиваться на работу и провалить собеседование из-за незнания деталей технологии.
Здравствуйте, Эйнсток Файр, Вы писали:
B>> Можно писать максимально просто и однозначно даже на самом ужасном языке программирования. А можно писать максимально ужасно на самом простом и красивом языке. ЭФ>А можно прийти устраиваться на работу и провалить собеседование из-за незнания деталей технологии.
Можно, но как это связано с тем, что я написал выше?
Здравствуйте, varenikAA, Вы писали:
AA>https://www.tiobe.com/tiobe-index/
AA>rust уже скоро в первую лигу перейдет. лисп повыше упомянутого луа.
И будет тягаться с visual basic
B>>> Можно писать максимально просто и однозначно даже на самом ужасном языке программирования. А можно писать максимально ужасно на самом простом и красивом языке. ЭФ>>А можно прийти устраиваться на работу и провалить собеседование из-за незнания деталей технологии.
B> как это связано с тем, что я написал выше?
Обычно те, кто "готов писать на любом языке" деталей каждого языка не знают.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Решение проблем заказчика максимально быстро и качественно за минимальные деньги.
Дай определение качественно.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Обычно те, кто "готов писать на любом языке" деталей каждого языка не знают.
Это правда, но это не значит, что они пишут говнокод. За то на прошлой работе был парень, который знал все тонкости и нюансы C++ в мельчайших деталях. Но писал такой наркоманский код, что потом хотелось все переписать к чертям собачьим.
Здравствуйте, varenikAA, Вы писали: AA>Что является высшим приоритетом в программировании?
быстро и эффективно выполнять задачи, к сожалению это не означает "получать удовольствие",
мой основной язык abap/4 и он очень эффективен, позволяет сконцентрироваться на самой задаче,
но язык примитивен даже сейчас, чрезмерно длинные инструкции и устаревшие конструкции,
некоторые до сих пор пишут операторы заглавными как на COBOL 66,
и многие компании требуют именно такое оформление кода, у меня от этого до сих пор немного подгорает,
складывается ощущение, что люди не писали на других языках
lisp прекрасен, на нём можно довольно быстро писать, т.к. есть nil и можно писать сверху вниз,
сразу проектировать в коде для экономии времени,
haskell сложнее, но на нём можно написать любое алгоритмическое извращение, repl утилиты легко писать,
python классный язык, легко писать и довольно быстро, но он медленнее выполняется и не годится если нужна скорость,
на rust я не писал, но лысый из яндекса и другие знающие говорят, что этот язык сильно недооценен,
и еще почему-то все кто пробовал Гошку очень хвалят его (go)
vsb>Теперь по поводу сложности ЯП. Суть в том, что реальность сложная. Да, порой программисты её переусложняют ещё больше, но даже если ты не привносишь ни толики дополнительной сложности, то реальность остаётся сложной. Простые задачи решать обычно не нужно. И сложность задачи неизменно выливается в сложность решения. Это можно назвать законом сохранения сложности. Нельзя решить сложную задачу просто. Если это кто-то делает, значит где-то подвох, где-то эту сложность спрятали.
Именно. Хорошая иллюстрация к этим словам — примитивнейшая (с виду) "задача телеграфиста", сформулированная Науром.
"Telegram Problem", originally described by Peter Naur, is to write a program which accepts lines of text and generates output lines containing as many words as possible, where the number of characters in each line does not exceed a certain length. The words may not be split and we assume no word is longer than the size of the output lines. This is analogous to the word-wrapping problem in text editors.
Подвох в том, что её эффективное решение (без использования блокирующих операций ввода-вывода, без аллокаций памяти в процессе работы, на буферах фиксированного размера) невозможно выразить красиво и элегантно ни в императивной, ни в функциональной парадигме. Потому что имеем в явном виде несколько конечных автоматов, связанных по данным, два из которых асинхронны. И сокрытие сути в библиотеках/фреймворках не спасает ситуацию, а только усугубляет.
vsb>К примеру есть задача менеджмента памяти. В постановке задачи часто нет ограничений на размер входных данных. Это вызывает необходимость выделять память разного размера и освобождать её. От этой сложности не уйти. Но её можно спрятать за сборщиком мусора. Таким образом сложность задачи перешла в сложность реализации рантайма.
Это называется "заметание проблемы под ковёр" вместо её решения. Правильное решение — это не просто выделять память, а пользоваться аллокаторами, аренами, слябами, преаллоцированными буферами и т.д.
vsb>Но если всё писать на виртовском Паскале, окажется, что сама структура кода получается довольно сложной и упростить её никак не получится. Отсюда и берётся нужда в сложных ЯП. Когда сложность структуры кода переносится в сложную семантику ЯП и в результате получается простой код, который решает сложную проблему. А структурная сложность спрятана в компиляторе и рантайме, которые обеспечивают выполнение сложной задачи простым по виду кодом.
Да. А ещё, принимая во внимание, что лучший код — это ненаписанный код, я все больше прихожу к выводу, что полноценное метапрограммирование на этапе компиляции жизненно необходимо. По этому поводу мне нравится ещё одно высказывание: "язык, который не позволяет мыслить в терминах AST, приносит больше вреда, чем пользы". И очень жаль, что два языка, где эта концепция доведена до совершенства, не допилены по уровню качества до должного уровня, и на боевых задачах их использовать боязно. Я про Nemerle и Nim. А шаблонизатор C++, который развивался стихийно ("discovered, not engineered"), хоть на нём и можно выразить всё то же самое, трогать просто эстетически противно
vsb>Там он реализован "просто" — есть таблица с указателями на функции, есть указатель на эту таблицу в объекте
Бгг, указатель на таблицу указателей Хорошее решение для процессоров 20-го века, и лютый мрак на современных платформах. Кеш-трешинг гарантирован. Поэтому виртуальными функциями предпочитают не злоупотреблять на серьёзных нагрузках.
vsb>Но в любом случае сложность языка требует понимания этого языка. Выигрыш тут в том, что сложность языка достаточно выучить один раз, а использовать его можно в тысячах программ. Но, тем не менее, практика показывает, что бесконтрольное усложнение языка приводит к тому, что люди перестают его осиливать. Поэтому нужна золотая середина.
Есть такое. Можно вспомнить Аду. Я был крайне удивлён, что GNAT не просто жив, но и активнейшим образом развивается, и его современная версия Ada/Spark позволяет делать настолько мощные трюки со статическим доказательством корректности кода во время компиляции, что Rust отдыхает. Но. Так как Ada это сборище всех концепций и парадигм, огромная коллекция всего на свете, то осилить её на должном уровне зашибёшься. Ещё и синтаксис вырвиглазный.
Здравствуйте, varenikAA, Вы писали:
AA>>>Очевидно, что все языки разные. НС>>Ну ты прям КО. AA>Ну, не знаю, от профессионалов матерых слышу часто ЯП не важен.
Здравствуйте, Poopy Joe, Вы писали:
НС>>Решение проблем заказчика максимально быстро и качественно за минимальные деньги. PJ>Дай определение качественно.
Здравствуйте, trop, Вы писали:
T>lisp прекрасен, на нём можно довольно быстро писать, т.к. есть nil и можно писать сверху вниз, T>сразу проектировать в коде для экономии времени,
На Лиспе и правда можно быстро прототипы писать, но за счет динамической типизации лучше потом все это переписывать на чем-то типизированном.
T>haskell сложнее, но на нём можно написать любое алгоритмическое извращение, repl утилиты легко писать,
Не знаю, может я его не умею готовить, но алгоритмические вещи у меня на Хаскеле получались со скрипом, возможно у меня закостенелое императивное мышление.
T>python классный язык, легко писать и довольно быстро, но он медленнее выполняется и не годится если нужна скорость,
Дополню, и не годится для больших проектов, опять же, за счет динамической типизации.
T>на rust я не писал, но лысый из яндекса и другие знающие говорят, что этот язык сильно недооценен, T>и еще почему-то все кто пробовал Гошку очень хвалят его (go)
Пока я был в Яндексе, все очень любили Раст, и недолюбливали Го, но при этом именно Го сделали одним из разрешенных языков.
Здравствуйте, blacktea, Вы писали:
B>Пока я был в Яндексе, все очень любили Раст, и недолюбливали Го, но при этом именно Го сделали одним из разрешенных языков.
смотришь на go и не видишь никаких приемушеств. ну быстро накидали библиотек для всяких нужно. это конечно говорит в пользу языка.
но это также говорит что он спонсируется гуглом.
Все же раст, как врочем и ди(если не оглядываться на сборщкик мусора) предоставляют наиболее мощный компилятор в купе с иммутабельностью.
Если обратить внимание на сообщения компляторов то видно что он действительно очень умный. он подсказывает.
разница между растом и ди лишь в том что раст основан на выражениях, а ди императивный (ближе к классике).
в принципе стоило бы наверно сравнить плюшки и мишки этих двух статически компилируемых ЯП.
например, в ди участник реализовал мультиметоды, в раст эта проблема как я понял решена трейтами.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, blacktea, Вы писали:
B>>Пока я был в Яндексе, все очень любили Раст, и недолюбливали Го, но при этом именно Го сделали одним из разрешенных языков.
AA>смотришь на go и не видишь никаких приемушеств. ну быстро накидали библиотек для всяких нужно. это конечно говорит в пользу языка. AA>но это также говорит что он спонсируется гуглом. AA>Все же раст, как врочем и ди(если не оглядываться на сборщкик мусора) предоставляют наиболее мощный компилятор в купе с иммутабельностью. AA>Если обратить внимание на сообщения компляторов то видно что он действительно очень умный. он подсказывает. AA>разница между растом и ди лишь в том что раст основан на выражениях, а ди императивный (ближе к классике). AA>в принципе стоило бы наверно сравнить плюшки и мишки этих двух статически компилируемых ЯП. AA>например, в ди участник реализовал мультиметоды, в раст эта проблема как я понял решена трейтами.
Здравствуйте, varenikAA, Вы писали:
AA>Почему rust? Утверждают что компилятор раста не позволяет выполнить неправильные операции с памятью. нереально круто.
Злые языки утверждают, что если C++ не позволяет завести динамический массив, то раст- связный список. Представляешь, какой профит- найти цикл в списке не спросят.
Здравствуйте, Poopy Joe, Вы писали:
НС>>Решение проблем заказчика максимально быстро и качественно за минимальные деньги. PJ>Дай определение качественно.
Ка́чество програ́ммного обеспечения
— способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014)[1].
— весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94)[2][3];
— степень, в которой система, компонент или процесс удовлетворяют потребностям или ожиданиям заказчика или пользователя (IEEE Std 610.12-1990)
Для отдельных модулей (т.е. с т.з. конкретного разработчика) — степень соответствия модуля функциональным и нефункциональным требованиям.
И да, исходно должно быть не "проблем заказчика", а "задач заказчика".
Проблемы, наоборот, часто возникают по мере внедрения готовых решений, т.к. "саботаж неизбежен" (С).
И это не шутка, еще ни одно заметное (в кол-ве затрагиваемых людей) внедрение автоматизации очередной операции производства/учёта/управления и т.д. не обходилось без противодействия на местах. ))
Да что далеко ходить — даже у айтишников при вводе в обиход очередной системы контроля версий или системы сборки проектов противодействия неизбежны.
Здравствуйте, Artem Korneev, Вы писали:
AK>Здравствуйте, varenikAA, Вы писали:
AA>> Почему rust? [..] AA>> создает чистый код на этих ЯП.
AK>И где бы посмотреть на примеры хорошего чистого кода на Rust?..
Учебные фрагменты на 10..20 строк это несерьёзно.
В продакшн-коде у вас не будет этих "expect()", там придётся ставить реальную обработку ошибок и/или преобразования из одних типов ошибок в другие. А ветвления кода будут вызывать не println!(), а реальные методы, со своими аргументами и своими результатами выполнения и кодами ошибок. И код очень быстро станет куда менее красивым.
AA>а в вашем понимании что означает чистый?
Слово "чистый" упомянули вы, я хотел посмотреть на то, что представляет из себя чистый код на Rust с вашей точки зрения.
Сам я второй год работаю с Rust и у меня немало времени уходит как раз на то, чтоб сделать код "чище". В моём понимании это легко читаемый код с минимумом ненужных деталей. Rust как раз заставляет выставлять наружу очень уж много тех самых деталей, загромождая код. Бороться с этим трудно.
Из недавних попыток — я воспользовался макросами. Получилось неплохо, основной код бизнес-логики значительно упростился. Но при этом синтаксис самих макросов в Rust'е тоже не то чтоб легко читаемый.
тех самых деталей, загромождая код. Бороться с этим трудно.
что ж, возможно. этой мой взгляд со стороны. сам я дальше учебного примера не заходил. чистый код в моем понимании это http://blog.cleancoder.com/
AK>Из недавних попыток — я воспользовался макросами. Получилось неплохо, основной код бизнес-логики значительно упростился. Но при этом синтаксис самих макросов в Rust'е тоже не то чтоб легко читаемый.
По сравнению с другими ЯП с макросами или по сравнению с обычным кодом? макросы это же расширение компилятора, вряд ли они могут бы простыми.
Здравствуйте, varenikAA, Вы писали:
AA>что ж, возможно. этой мой взгляд со стороны. сам я дальше учебного примера не заходил.
Ясно. Я думал, примеры есть.
На C++/C#/Java я могу писать легко читаемый код. Обычно разделяю для этого код на разные уровни, чтоб в бизнес-логике не было низкоуровневых деталей, чтоб бизнес-логика отражала предметную область как можно лучше. С Rust'ом мне пока сложно в этом плане.
Из того, что мне видится примерами хорошего кода на Rust, могу упомянуть опенсорсные проекты типа этого:
Там тоже мелькает синтаксический мусор, но в целом получается довольно читабельно. Стараюсь держаться похожего стиля, но активно разбавляю макросами.
AA>По сравнению с другими ЯП с макросами или по сравнению с обычным кодом? макросы это же расширение компилятора, вряд ли они могут бы простыми.
Здравствуйте, varenikAA, Вы писали:
AA>Почему lisp? потому что это первый(только подумайте) ЯП со сборщиком мусора. Только одно это убрало огромное кол-во сложности.
Занудствую: первым языком с GC был Algol-68.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, varenikAA, Вы писали:
AA>>Почему lisp? потому что это первый(только подумайте) ЯП со сборщиком мусора. Только одно это убрало огромное кол-во сложности. C>Занудствую: первым языком с GC был Algol-68.
Здравствуйте, varenikAA, Вы писали:
AA>Что является высшим приоритетом в программировании?
Отсутствие ошибок.
AA>На мой взгляд важнейшим являются простота ЯП и возможность посредством ЯП сохранять код AA>максимально простым и однозначным.
Ну нет. Простой и однозначный код ведёт к нехватке ресурсов.
AA>И здесь я вижу пока лишь два кандидата. AA>Почему lisp? потому что это первый(только подумайте) ЯП со сборщиком мусора. Только одно это убрало огромное кол-во сложности.
Разве это не убило lisp?
AA>Почему rust? Утверждают что компилятор раста не позволяет выполнить неправильные операции с памятью. нереально круто.
Это как? Что будет, если памяти не хватит для поступивших данных?
Здравствуйте, B0FEE664, Вы писали:
AA>>Почему rust? Утверждают что компилятор раста не позволяет выполнить неправильные операции с памятью. нереально круто. BFE>Это как? Что будет, если памяти не хватит для поступивших данных?
Здравствуйте, B0FEE664, Вы писали:
BFE>А чем этот код отличается от C++?
В первую очередь отсутствием операторов, отcутствием void
ну т.е. большей функциональностью. компоуз и т.п.
явное приведение типов. много чего. простой и понятный карго.
Здравствуйте, B0FEE664, Вы писали:
BFE>Отсутствие ошибок.
Знаете способ как доказать что в коде нет ошибок?
Главное это полезность. Куча софта который страшно глючил по началу, но что называется "выстрелил". тот же firefox.
Он до сих падает, но он банально удобен.
BFE>Ну нет. Простой и однозначный код ведёт к нехватке ресурсов.
Это как?
BFE>Разве это не убило lisp?
Лисп сейчас очень активно развивается, достаточно окунуться в его среду, чтобы это понять.
а аналогов сигнального протокола я до сих пор не встречал.
BFE>Это как? Что будет, если памяти не хватит для поступивших данных?
Не практикую, но думаю у раста случится паника
Здравствуйте, vaa, Вы писали:
BFE>>Отсутствие ошибок. vaa>Знаете способ как доказать что в коде нет ошибок?
нет, такого способа вообще не существует.
vaa>Главное это полезность. Куча софта который страшно глючил по началу, но что называется "выстрелил". тот же firefox. vaa>Он до сих падает, но он банально удобен.
Всё, что связано с web-ом вообще никогда нормально не работало. Я не знаю ни одной нормально работающей программы связанной с web-ом. Всё программирование в этой области — бардак и содомия. А уж говорить, что это главное... Извините, не согласен.
BFE>>Ну нет. Простой и однозначный код ведёт к нехватке ресурсов. vaa>Это как?
Обычно расходуется либо слишком много памяти, либо слишком много энергии.
BFE>>Разве это не убило lisp? vaa>Лисп сейчас очень активно развивается, достаточно окунуться в его среду, чтобы это понять.
В академической среде?
vaa>а аналогов сигнального протокола я до сих пор не встречал.
Если я правильно понял, то в некоторых библиотеках С++ используется похожая технология.
BFE>>Это как? Что будет, если памяти не хватит для поступивших данных? vaa>Не практикую, но думаю у раста случится паника
паника — это правильная операция с памятью?
Здравствуйте, vaa, Вы писали:
BFE>>А чем этот код отличается от C++? vaa>В первую очередь отсутствием операторов, отcутствием void vaa>ну т.е. большей функциональностью. компоуз и т.п. vaa>явное приведение типов. много чего. простой и понятный карго.
Но ведь это зависит исключительно от стиля написания кода. Если хочешь писать на С++ как на Rust, то что мешает?
Здравствуйте, B0FEE664, Вы писали:
BFE>В академической среде?
в телеге довольно много только русскоговорящих любителей лиспа. не могу сказать что лисп академический. это скорее оберон.
BFE>паника — это правильная операция с памятью?
ну это не проблема раста, это от программиста зависит кончится память или нет.
плюсы что сделают?
Здравствуйте, B0FEE664, Вы писали:
BFE> Но ведь это зависит исключительно от стиля написания кода. Если хочешь писать на С++ как на Rust, то что мешает?
Ничего не мешает. Более того, тот стиль, что навязывает компилятор Rust, является в точности тем же стилем, что считается правилами хорошего тона в современном C++. Т.е. вся разница между этими двумя языками в том, что в C++ ты так пишешь на самодисциплине, а в Rust компилятор тебе по другому просто не даёт (ну точнее и в Rust можно написать код в худших традициях C, типа void* и т.п., но для этого придётся использовать unsafe блок).
Здравствуйте, B0FEE664, Вы писали:
BFE>Нет, не мешает. На С++ можно писать в функциональном стиле, если есть желание.
Мешает повышенная сложность плюсов.
Как ни крути, а семантика раста на много порядков проще.
Здравствуйте, DarkEld3r, Вы писали:
DE>И чем же кложа лучше других лиспов? Комон лисперы так вообще смотрят на неё как на говно.
я тут общался в телеге с кложуристами русскоговорящими насчет спеки, да кложа переоценена сильно,
единственное достижение кложи это синтаксис для хэшмапов {:name "alice" :age 12}
все остальное сильно слабее. так спеки это как библиотека валидации, но прикол в том, после валидации данные уходят дальше и могут быть как угодно преобразованы.
в отличии от коммон лиспа где можно испльзовать CLOS.
как всегда часть не может быть лучше целого.
Вообщем я забил на кложу, да и лиспов думаю в емаске хватит пока для поддержания мозговой активности.
Здравствуйте, vaa, Вы писали:
vaa>я тут общался в телеге с кложуристами русскоговорящими насчет спеки, да кложа переоценена сильно,
Мне кажется, что ты слишком легко поддаёшься влиянию "авторитетов". Лисперы любят рассказывать байки про гибкость, мощность и прочий дебаг спутников в космосе. Да, язык интересный и с налётом "илитности", но надо понимать, что многие его фичи отсутствуют в более современных языках не потому, что лисп настолько опередил время, а потому что они, зачастую, неоднозначные. Скажем, хвалёная разработка в образе подталкивает к манкипатчингу. В общем, я бы рекомендовал не слушать разнообразных гуру и не метаться от плюсов к расту и от лиспа к хаскелю, в зависимости от того чей голос будет сегодня громче. А взять и освоить тот же лисп, попробовать на нём что-нибудь написать и сделать уже свои выводы.
Я сам когда-то давно наслушался этих романтических баек, но когда язык как следует пощупал, пришёл к выводу, что мне в целом динамика не особо нравится не важно Common Lisp ли это или Racket. Пощупать всякую экзотику бывает полезно, но надо именно ознакомиться с предметом, а не бегать по форумам и выбирать "самый мощный язык в мире".
Здравствуйте, kaa.python, Вы писали:
KP>Тем что из неё всё разнообразие мира JVM доступно, в первую очередь. Как бы не был прекрасен язык, без библиотек он бесполезен.
Это понятно, я усомнился именно в прекрасности кложуры самой по себе.
Здравствуйте, DarkEld3r, Вы писали:
DE>Я сам когда-то
По спирали приближаюсь к похожу мнению, однако большинству ЯП
все же не помешало бы больше гибкости в разработке.
Так 10 лет была отличная возможность типа GUI UML-редактора в VS для C#
прямо из редактора можно было создавать инстансы и у них вызывать методы.
Что-то типа https://www.bluej.org/
Ну и REPL это же просто такая удобная штука. Куда без нее.
Или макросы, без них метапрограммивание весьма убого. и к тому же не работает, как я убедился на DispatchProxy т.е. цепочные вызовы не обрабатываются прокси.
Здравствуйте, varenikAA, Вы писали:
AA>На мой взгляд важнейшим являются простота ЯП и возможность посредством ЯП сохранять код
Доводилось мне участвовать в разработке двух разных проектов на Clojure и Haskell. Я даже не знаю, каким словом описать ту неразбериху, которая творилась в коде. У нас же все функции без побочных эффектов, да? — Ага, поэтому контекст загружался через вызовы каких-то левых функций, которые модифицировали глобальное состояние. Я думаю, что даже схемы попила госденег в РФ не такие запутанные, как функциональный код в кровавом энтерпрайзе. Кстати, в проекте на Clojure был ещё один вариант передачи контекста — он хранился в JSON-like структуре. Это просто бомба! Вместо строго типизированной иерархии объектов мы получаем какую-то кашу, которая, стоит, чуть тронуть (убрать или изменить поле), взрывается зигзиллионом ошибок. Поэтому поступали просто — не убирали старые поля, а добавляли sum2, newSum и так далее. Вот это чистый код, я понимаю!
P.S. Конкретно на Haskell можно писать красивый, более безопасный, не всегда быстрый, строго типизированный код, просто мало кто это умеет.
Здравствуйте, cppguard, Вы писали:
C> Поэтому поступали просто — не убирали старые поля, а добавляли sum2, newSum и так далее. Вот это чистый код, я понимаю!
Ну что ж, прекрасный пример из опыта. я тут пару дней назад разбирался со спекой в кложе и потролил маленько русское комунити.
там подобный подход единственно возможный видимо. т.к. хешмапа это по сути обычный словарь в который можно положить все что угодно. это позволяет быстро и наглядно закодить решение.
но спека конечно позволяет валидировать данные только на входе. в этом тупость конечно.
C>P.S. Конкретно на Haskell можно писать красивый, более безопасный, не всегда быстрый, строго типизированный код, просто мало кто это умеет.
в том то и дело, что умение гибко применять возможности языка приходит не сразу и не ко всем. 90% программистов они как религиозные фанатики, уверовавшие в истинного единого ООП/ФП/СтатТип/Динамику(подставить нужное).
Но когда понимаешь что это лишь кирпичи, а дом ты можешь построить любой, то и продукт выходит совсем иначе.
поэтому ЯП общего назначения поддерживающие все возможные методы (common lisp) лучше узкоспециализированных (clojure).
lisp это и сигналы(круче исключений в разы) и гибкий ООП и обобщенные методы(тут Ричи правильно заметил, что дженерики в языках типа c# это трэш, когда логика умножается на кол-во параметров типа)
и много другое.
Как заметил один лиспер справедливо "если бы круглые скобки были моей единственной проблемой!"
на лиспе писал только для фаната но он мне понравился больше кложи, свобода полнейшая, удобная отладка.
и самое главное простой очень синтаксис. все единообразно.
вчера посмотрел сколько операторов в F# чуть не упал.
