Язык программирования для Backend

Здравствуйте.
Халивар неизбежен, однако, мне следует задать этот вопрос.
Что сейчас лучше использовать для Backend?
Конкретнее:
1) Из того, что востребовано;
2) Из того, с чем будет проще разработка крупных проектов, включая разработку API;
3) Не JS.
Прошу конкретизировать вашу позицию.
Всем спасибо!

0

Сообщение от Curry rust близок к тому.

Rust далёк от Хаскелла.

Сообщение от Curry А выдумывать новые языки - этим я давно переболел.

Кто ж говорит о новых? Улучши существующий.

Сообщение от Curry Кол-во языков сокращать пора.

Зачем? PL-Nazi?

Сообщение от Curry …

Rust не взлетел по многим причинам:
– все эти заморочки с памятью, которые многим нафиг не нужны (а кому нужны — пишут на C/C++)
– соответствующие им элементы грамматики (оверюз всяких знаков пунктуации для обозначения разной семантики владения и т.п.)
– ломающие обратную совместимость изменения при девелопменте (для сравнения: одной из политик при разработке Go было минимум breaking changes, что позволило быстро выкатить 1.0 в использование и параллельно развивать; C# и .NET же MS сильно и активно меняла в процессе, потому он долго не мог выстрелить, так что см.ниже).

Но у него, похоже, ещё есть шанс хотя бы занять какую-то нишу — поклонники, вроде, медленно, но прибывают.

Сообщение от Curry Не нужно вставлять не к месту высказывания известных людей только потому что вы их услышали.

Оно ещё как к месту. И там был вопрос.

Добавлено через 53 секунды

Сообщение от Fulcrum_013 Типа человек который постоянно пишет на плюсах по вашему может не разбираться в недостатках ФП?

Запросто. Вот ты не разбираешься не только в недостатках ФП, но и в ФП вообще.

0

Сообщение от korvin_ но и в ФП вообще.

ФП по современным временам - один большой недостаток.

Добавлено через 11 минут

Сообщение от korvin_ для сравнения: одной из политик при разработке Go было минимум breaking changes, что позволило быстро выкатить 1.0 в использование и параллельно развивать; C# и .NET же MS сильно и активно меняла в процессе, потому он долго не мог выстрелить, так что см.ниже

Причины абсолютно другие. Шарп вышел гораздо раньше. Т.е. такого дефицита разрабов и ниши для горе-кодеров экспоненциально создаваемых срамо-агилом еще не было, а резерв пополнения неквалифицированных разрабов знакомый с явой со школы еще только-только зарождался. Go же делался уже под существующий низкоквалифицированный контингент, которому для примитивных задач, на него возлагаемых, что то кроме самой простой процедурщины вообще противопоказано. Именно поэтому он и "взлетел" сразу - путем внедрения в административно-приказном порядке в гугле.
Профи же владеющий плюсами никогда добровольно на ни на шарп, ни на го, ни на раст не перейдет. Ни тем более на ФП-анахронизмы.

0

Сообщение от Fulcrum_013 ФП по современным временам - один большой недостаток.

Я же писал: твоё мнение никого не интересует. Продолжай пофапывать на билдер.

Добавлено через 1 минуту

Сообщение от Fulcrum_013 Причины абсолютно другие. Шарп вышел гораздо раньше. Т.е. такого дефицита разрабов и ниши для горе-кодеров экспоненциально создаваемых срамо-агилом еще не было, а резерв пополнения неквалифицированных разрабов знакомый с явой со школы еще только-только зарождался. Go же делался уже под существующий низкоквалифицированный контингент, которому для примитивных задач, на него возлагаемых, что то кроме самой простой процедурщины вообще противопоказано. Именно поэтому он и "взлетел" сразу - путем внедрения в административно-приказном порядке в гугле. Профи же владеющий плюсами никогда добровольно на ни на шарп, ни на го, ни на раст не перейдет. Ни тем более на ФП-анахронизмы.

Очередное ко-ко-ко от неуча.

0

Сообщение от korvin_ Я же писал: твоё мнение никого не интересует.

Ну можете забивать на кэптайна Очевидность сколько угодно и продолжать ловить грабли. У математики мнениев не бывает. Бывают факты. А факт того что ФП - тюринговская трясина давно доказан. Т.е. ни для чего большего чем параметризовать к примеру функцию поиска функцией сравнения аргументов ФП будет значительно уступать императивному.

0

Сообщение от Fulcrum_013 У математики мнениев не бывает. Бывают факты. А факт того что ФП - тюринговская трясина давно доказан

Посколку "тьюринговая трясина" - не строгий математический термин, то доказать в математическом смысле, что какой-то языке ею является - невозможно. Ну или приведите определение и доказательство, может я чего то не знаю.

0

Сообщение от Fulcrum_013 Оно у них тоже не разу не с нулевой стоимостью а с заголовком под капотом каждого указателя.

Владение и заимствование в rust -- это время компиляции.

Сообщение от Fulcrum_013 Напомню - механизм шаблонов - чистый функциональный язык.

Напомню, шаблоны -- нечто именуемое как полиморфизм. Это техника, а не функциональный язык.

Сообщение от Fulcrum_013 А факт того что ФП - тюринговская трясина давно доказан.

А тот факт что Тьюринг полнота и лямбда исчисление -- по сути одно и то же, не? Не слышали про такое? Я вам скажу что означает ваша цитата примерно так: Ставим задачу. Двое претендентов задачу решают. Один для этого изобрел Тьюринг машину, а другой -- лямбда исчисление. И тут появляетесь вы и громогласно заявляете что только Тьюринг машина решает задачу и согласно Тьюринг машине лямбда исчисление как метод несостоятельно. Не заметив при этом слона, у которого на лбу написано что это разные математически выверенные подходы к решению одной задачи. Или другой пример: Докажем теорему Пифгора двумя разными методами -- алгебраически и вероятностью. Вы опять станете настаивать что доказательство вероятностью несостоятельно потому что уже все доказано алгебраически?

0

Сообщение от zeroalef Вот видите? По мне так это ад и израиль. Никакой мыслительной работы, прожигание времени впустую.

Так я об этом же и говорю. Никакой мыслительной деятельности, только имитация и сотрясание воздуха на конференциях и написание бесконечных статей о темах, которые яйца выеденного не стоят. Главное ведь, чтобы заказчики не поняли, что все, чем занимаются их подчиненные за весьма немалые суммы - это монотонная работа, которую с успехом можно автоматизировать и оставить вместо армии веб-макак одну на всю контору, которая сможет кнопки в автоматизированной интеллектуальной системе проектирования нажимать. Собственно, уход от профессий, не требующих никакой мыслительной деятельности и их автоматизацию мы сейчас наблюдаем во всех сферах нашего общества. Дойдет эта волна и до программистов в ближайшие годы.

0

Сообщение от Катафалк Собственно, уход от профессий, не требующих никакой мыслительной деятельности и их автоматизацию мы сейчас наблюдаем во всех сферах нашего общества.

Это мы наблюдали лет 90-30 назад, когда станкизаменяли рабочих. Сегодня, на ряду с развитием станков мы наблюдаем главным образом не автоматизацию, а полную замену человеческого разума машинным. Но я говорил не об этом, не пытайтесь увести диспут в демагогию. Я говорил о том, что автоматизация веба -- крайне сложная задача в силу 'несовершенства' самого веба.

0

Сообщение от zeroalef Я говорил о том, что автоматизация веба -- крайне сложная задача в силу 'несовершенства' самого веба.

Ну так в стандартизации тоже нет ничего невозможного. В любой области в начале ее развития наблюдается хаос из различных стандартов, технологий, но потом все более-менее стабилизируется. Что касается сложности, то сложность тут не качественная, а количественная, вызванная как раз отсутствием единого стандарта в том числе. Но все это вполне поддается автоматизации, например уже есть проекты по построению ui прямо по его картинке. Пока еще все это несовершенно и для практического применения не пригодно, но прогресс на месте не стоит.

Сообщение от zeroalef Сегодня, на ряду с развитием станков мы наблюдаем главным образом не автоматизацию, а полную замену человеческого разума машинным. Но я говорил не об этом

А я именно об этом. С развитием интеллектуальных средств разработки низкоквалифицированный труд формошлепов будет с успехом заменен этими самыми средствами.

0

Сообщение от zeroalef А тот факт что Тьюринг полнота и лямбда исчисление -- по сути одно и то же, не?

Ну вот тьюринговская трясина - это и есть Тьюринг-полный язык но с исключительно низкой продуктивностью. А так в общем то все языки программирования Тюринг-полные. По большому счету полнота по Тюрингу - критерий отделения языков программирования от языков описания данных. И необходимы для этой полноты по Тюрингу всего то возможность условного перехода назад (т.е. ветвление и циклы).

Добавлено через 2 минуты

Сообщение от zeroalef Это техника, а не функциональный язык.

Это тюринг-полный функциональный язык.

Сообщение от zeroalef Напомню, шаблоны -- нечто именуемое как полиморфизм.

А полиморфизм это нечто абсолютно другое. А именно взаимозаменяемость типов данных. Учите матчасть.

0

Сообщение от Fulcrum_013 Ну вот тьюринговская трясина - это и есть Тьюринг-полный язык но с исключительно низкой продуктивностью.

Так как насчет привести математическое доказательство того, что функциональные языки - тьюринговая трясина? Которое, как вы утверждали, существует. Но перед этим, разумеется, привести математическое определение тьюринговой трясины.

0

Сообщение от Катафалк Так как насчет привести математическое доказательство того, что функциональные языки - тьюринговая трясина?

В кратце - после ликвидации всех недостатков ФП, продиктованных техническими возможностями первых ЭВМ, (неизменяемость данных,рекурсия вместо циклов и т.д. и т.п.) и несоответствия модели вычислений вычислителю ( программа физически не может выполняться без изменения среды как минимум потому что время выполнения функции ненулевое) получаем процедурное программирование. Ну и дальше по нарастающей.

0

Сообщение от Fulcrum_013 В кратце

Ну то есть никакого математического доказательства у вас нет. И даже определения нет. Что и требовалось доказать, собственно. Лучше бы просто сознались, что взболтнули не подумав.

0

Сообщение от Катафалк Ну то есть никакого математического доказательства у вас нет. И даже определения нет. Что и требовалось доказать, собственно. Лучше бы просто сознались, что взболтнули не подумав.

Тьюринговская трясина — языки программирования, которые Тьюринг-полны, но обладают крайне примитивными синтаксисом и семантикой. Это как раз про ФП. К примеру только ограничение количества параметров функции одной ведет к увеличению размеров кода в десятки раз.

0

Сообщение от Fulcrum_013 Тьюринговская трясина — языки программирования, которые Тьюринг-полны, но обладают крайне примитивными синтаксисом и семантикой.

Все еще не видно математики. Выражения вроде "крайне примитивный" и прочие оценочные суждения математикой не являются.

0

Сообщение от Катафалк Выражения вроде "крайне примитивный" и прочие оценочные суждения математикой не являются

Да что вы. В конечном итоге все сравнение приходит в ту или иную циферь. Ну разве что кое что в булевские типы по наличию возможностей. По которым у ФП сплошные фалсе.

0

Сообщение от Fulcrum_013 В конечном итоге все сравнение приходит в ту или иную циферь.

Так у вас то и цифири даже нет.

0

Сообщение от korvin_ Rust далёк от Хаскелла.

В rust взято очень много от Haskell. Встроенной лени нет, но трейты - это классы типов, даже улучшенные, что естественно, язык более молодой, учли опыт разработок и на Haskell тоже. Из Haskell GC не выдернуть, не сделав вместо него другой язык, но если посмотреть как в rust реализуются функциональные конструкции, можно сделать вывод что ФП не обязано сочетаться с GC.

Сообщение от korvin_ Зачем? PL-Nazi?

У вас нет определения кто это, по этому не знаю, подходит ли это ко мне. Но существующий зоопарк языков - определённо перебор. В том же бекенде из названия темы применяются php,hodejs,java(kotlin,Scala),C#(F#,VB), питон, перл, ruby, go ...
И для каждого продублировали в библиотеках миллионы строк кода делающих то же самое. Эффект вавилонской башни, что тут хорошего?

Сообщение от korvin_ Оно ещё как к месту.

Поясните. Определённо, я не высказывал идеи стать премьером.

Сообщение от Fulcrum_013 Тьюринг-полный язык но с исключительно низкой продуктивностью.

Тогда это подъязык шаблонов в С++, т.к. Тьюринговую полноту он реализует со страшным скрипом.
https://stackoverflow.com/ques... g-complete
На практике его так не используют, т.к. это специализированный язык которому эта полнота не требуется.

Сообщение от Fulcrum_013 рекурсия вместо циклов

Хвостовая рекурсия заменяется циклом. Это частный случай оптимизации называемой tail-call elimination.
В некоторых языках она обязательна. С++ к ним не относится, по этому даже хвостовая рекурсия в нём грозит stack overflow.

Сообщение от Fulcrum_013 программа физически не может выполняться без изменения среды как минимум потому что время выполнения функции ненулевое

Для реализации чистой функции требуется только что бы один и тот же набор аргументов давал всегда одинаковый результат и без побочек (вывод куда то,изменение глобальных переменных). Время исполнение и нагрев процессора при этом не оговариваются.
Чистые функции можно писать и на С++. Мало того, хороший стиль, это выделять чистые функции (расчёт) из всего алгоритма, а не смешивать расчёт с I/O.

Сообщение от Fulcrum_013 Это как раз про ФП. К примеру только ограничение количества параметров функции одной ведет к увеличению размеров кода в десятки раз.

Не устаёте демонстрировать своё незнание,того о чём пишите. Услышали звон ...
Если бы вы посмотрели на код на каком то из функциональных языков (вы не будете смотреть, это я так, как риторический приём), то увидели бы функции из нескольких аргументов. А если бы вникли, то поняли бы что и состояние у этих программ есть.

0

Сообщение от Катафалк Так у вас то и цифири даже нет.

Достатчоно булов. Итак ФП не умеет в принципе: изменять данные, работать с состояниями, как следствие не может и диалоговый режим обработки и событийное управление. При прикостыливании же всего этого нечистыми способами ведет к гигантским проблемам с актуализацией данных. Отсюда и его исключительная непродуктивность и неэффективность.

0

Сообщение от Curry Время исполнение и нагрев процессора при этом не оговариваются.

Ну вот как раз это и есть несоответсвием модели вычислений вычислителю.

Добавлено через 1 минуту

Сообщение от Curry Хвостовая рекурсия заменяется циклом.

Вопрос не в том чем она заменяется а в том что код только с рекурсией гораздо более громоздкий и запутанный чем с циклами особенно при наличии ветвления в теле цикла.

Добавлено через 5 минут

Сообщение от Curry На практике его так не используют, т.к. это специализированный язык которому эта полнота не требуется.

На практике именно это и используют постоянно. те же тупли и т.п. по другому не получить. Его разница только в том что он не расчеты в привычном виде производит производит а код генерит. Т.е. вместо функций - шаблоны, вместо параметров - их аргументы. Результат работы - инстанционированные шаблоны. Тогда все становится на свои места. И вот тут введение только одного императивного элемента - if constexpr уже позволило сократить код в десятки раз и значительно повысить читабельность. что будет если все на императивные средства перевести?

Добавлено через 1 час 6 минут

Сообщение от Curry Для реализации чистой функции требуется только что бы один и тот же набор аргументов давал всегда одинаковый результат и без побочек (вывод куда то,изменение глобальных переменных).

Т.е. не должно быть никаких состояний изменяемых во времени.

Сообщение от Curry Чистые функции можно писать и на С++. Мало того, хороший стиль, это выделять чистые функции (расчёт) из всего алгоритма, а не смешивать расчёт с I/O.

Вопрос не в том где и че можно. Вопрос в том что только чистых функций в принципе недостаточно. Именно в следствие их невозможности работы с состояниями. А соответсвенно чистые функциональные языки - сапоги в смятку. А при использовании нечистых довесков возникает проблема с актуализацией данных посчитанных одной частью программы для использования в другой. Вот это и есть тот недостаток ФП который делает его абсолютно непригодным к практической разработке чего либо за исключением пакетных утилит, не взаимодействующих с внешними хранилищами данных, эпоха которых закончилась к 60-ым.
А второй момент именно в том что и смысла в чистоте функций тоже ноль. Хотя бы потому что они или заменяемы константами или, если это невозможно, то необходимость постоянной проверки вычислялась ли функция или нет для данного набора аргументов, сводит всю кажущуюся потенциальную эффективность ленивых вычислений в минус.

Добавлено через 3 часа 29 минут

Сообщение от Curry Если бы вы посмотрели на код на каком то из функциональных языков (вы не будете смотреть, это я так, как риторический приём), то увидели бы функции из нескольких аргументов. А если бы вникли, то поняли бы что и состояние у этих программ есть.

Там еще много чего есть коме автоматического кррирования и декаррирования. К примеру всякие нечистые монады и т.д. Что как раз и подтверждает утверждение о том что процедурное программирование - естественное развитие функционального на цифровые вычислители и память с многократной записью. И без такого развития тюринг-полноты явно недостаточно (что в общем то следует из определения тюринг-полноты которая никак не касается вопросов организации доступа к данным). А прикостыливание нечистых оставаясь в рамках ФП - костыли, которые только резко усложняют тривиальные для процедурного программирования задачи и не более того.

0