Здравствуйте, 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)
Для отдельных модулей (т.е. с т.з. конкретного разработчика) — степень соответствия модуля функциональным и нефункциональным требованиям.
И да, исходно должно быть не "проблем заказчика", а "задач заказчика".
Проблемы, наоборот, часто возникают по мере внедрения готовых решений, т.к. "саботаж неизбежен" (С).
И это не шутка, еще ни одно заметное (в кол-ве затрагиваемых людей) внедрение автоматизации очередной операции производства/учёта/управления и т.д. не обходилось без противодействия на местах. ))
Да что далеко ходить — даже у айтишников при вводе в обиход очередной системы контроля версий или системы сборки проектов противодействия неизбежны.
