LINUX.ORG.RU
ФорумTalks

Зачем придумывают всё новые языки-велосипеды?

 , ,


0

1

Зачем кому-то понадобился раст, когда есть адекватные и всем знакомые кресты? Зачем нужен элексир, когда есть шарпик, который знает каждая мартышка? Зачем изобретают го, вместо развития сишечки? Зачем нужна нода, когда есть питон, и зачем нужен питон, когда есть руби?

Даже не сам факт того, что изобретаются всё новые и новые языки, удручает. Пусть изобретают люди, коль нечем заняться. Но зачем это всё тянут в продакшон?

Профессия размывается, за всем нереально уследить. Раньше, с некоторой натяжкой, всё было более-менее понятно: пэхэпэшник пишет бэк под веб, на джаваскрипте ваяют фронт, на делфи пилят формы, сишники — лоулэвл, крестовики — молодцы вообще ребята. А сейчас одно и то же можно сделать сотней разных способов. И вроде бы это хорошо, но вот глядишь на вакансии и там: требуется знания языка X123 (от 5 лет), опыт работы с фреймворком Y456, и ещё тулзы Z789, Z798 и Z897.

Да чёрт возьми, а если я знаю X321 и Z888? Мы вам перезвоним. А потом такие, ко-ко-ко, на рынке дефицит нормальных девелоперов, а юные вайтишники опыть наклепали говна и сорвали дедлайн трижды.

Наболело.


Ответ на: комментарий от next_time

если выпустить в продакшен сырое говно, то на рынке сформируется понимание, что такой продукт не нужен

Нет, если есть круг заинтересованных участников. О настоящем проде в этот момент речь не идет, скорее обкатка функционала.

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

это уже 50%+ готового продукта, поздняк будет на другой язык переходить

Видел как один проект переписали с с++ на scala, затем scala на java, потом добавили куски на питоне и в прод он вышел уже на котлине. Пол страны пользуются, полет нормальный.

и какой же профит с переписывания альфа версии на другой язык?

На альфа версии нужны скорость разработки и скорость внесения изменений, а в проде приоритеты другие: простота сопровождения, возможность соответствовать sla, соответствие _всем_ требованиям безопасности и исходя из этого пилится архитектура соответствующая всему вышеописанному, которой приклад в свою очередь должен соответствовать. Лично на моей практике почти в 100% случаев прототип и прод разрабатывают разные команды с разными компетенциями.

phoen ★★
()
Последнее исправление: phoen (всего исправлений: 1)
Ответ на: комментарий от phoen

Видел как один проект переписали с с++ на scala, затем scala на java, потом добавили куски на питоне и в прод он вышел уже на котлине.
полет нормальный.

Нет, полёт хреновый

Пол страны пользуются

и кто же эти полстраны? я вот не пользуюсь такой дичью

Лично на моей практике почти в 100% случаев прототип и прод разрабатывают разные команды с разными компетенциями.

у меня ровно противоположная практика

скорость внесения изменений

она для всех языков одинакова

На альфа версии нужны скорость разработки

определяется используемыми фраемворками, а не языком, причём с питона + пирамид переходить на рельсы или жабу или наоборот очень тяжело

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

next_time ★★★★★
()
Ответ на: комментарий от phoen

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

Результат: репутация нашего продукта упала до нуля. Первоначальный клиент отказался от дальнейшего сотрудничества, включая ТП, и перешёл на продукт конкурентов.

Самое забавное, что написать один и тот же продукт до одинакового состояния на питоне и плюсах заняло почти одинаковое время: примерно 8 месяцев.

next_time ★★★★★
()
Ответ на: комментарий от phoen

Часто правильнее взять условную java, быстро сделать проект и начать получать деньги

Обычно так пишут люди, которые кроме Java/instrument_name больше ничего не знают. Потому что есть валом инструментов, в которых можно сделать проект намного быстрее, и начать получать деньги. Собсна, что и делают PHP-макаки.

byko3y ★★★★
()
Ответ на: комментарий от iZEN

Появляется языки уровня описания предметной области (DSL), которые лаконично описывает проблематику и решение в конкретной области знаний.

Wrong, e.g. Python, Lisp.

byko3y ★★★★
()
Ответ на: комментарий от phoen

В энтерпрайзном мире уже давно и прочно осела java, она позволяет быстро и, при некотором умении, качественно реализовать почти все что угодно (не low level).

Клевые истории, весели еще. Не подскажешь, почему в 2019 жава практически нигде, кроме числодробильных серверов для бизнеса, не используется? Я понимаю, что это довольно денежный и востребованный сектор, но все же ограниченный по сути.

byko3y ★★★★
()
Ответ на: комментарий от phoen

Но сейчас уже и Java слишком сложная.

Во первых нет, во вторых всё ещё крайне востребованная в отличии от.

Представь себе Cobol - востребован. Никто в здравом уме не будет на нем писать новые приложения, но его поддерживают. От Java тоже уже начинают отказываться в пользу более продвинутых JVM-based языков, но работы для жабомакак еще долго не убавится.

byko3y ★★★★
()
Ответ на: комментарий от vertexua

Затем что в ноде с нуля всех заставили все либы писать асинхронными, а в руби и python сложно так адаптировать экосистему.

Нет, дело в том, что в JS каждые 5 лет 98% либ отправляется на помойку, и их заменяют новыми либами.

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

byko3y ★★★★
()
Ответ на: комментарий от monk

Потому что в лиспе map принимает первым аргументом функцию, а остальными n коллекций. И типы аргументов этой функции должны соответствовать типам этих коллекций

Ну на конечном кол-ве аргументов в хаскеле такой map описывается. Я сомневаюсь, что где-то есть острая необходимость иметь map с бесконечным числом аргументов. Мне самому интересно, можно ли на каррировании сделать именно бесконечный map со статической типизацией в хаскеле.

byko3y ★★★★
()
Ответ на: комментарий от vertexua

У лисперов «можно написать» - универсальная защита. Но написано ли? Куда не посмотришь в лисп коде Python-style динамическая говнятина. Ждёт часа чтобы упасть в продакшне от потерянного уровня вложения или типа.
Это меня и наводит на мысль что это все язык одного программиста, раз типизация не нужна на практике и юнит-тесты спасут отца русской демократии.

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

byko3y ★★★★
()
Ответ на: комментарий от next_time

в)Создание алгоритмической базы приклада.
это уже 50%+ готового продукта, поздняк будет на другой язык переходить

Это 5-10-20% готового продукта, если конечный продукт будет писаться на каком-то Java/C++/C, а прототип - на питоне.

byko3y ★★★★
()
Ответ на: комментарий от next_time

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

Если прототип дотачивается, то это не прототип. Прототип строго уничтожается. Вывод: конкуренты смогли воспользоваться вашим прототипом, а ваша фирма - нет. И как бы при чем тут ненужность прототипов?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Я сомневаюсь, что где-то есть острая необходимость иметь map с бесконечным числом аргументов

То есть лучше писать zip3, zip4, ..., map2, map3, ... fold2, fold3, ..., lift2, lift3, ..., curry2, curry3, ... с почти идентичными реализациями?

С бесконечным может и не надо, но с разным количеством аргументов надо.

Кстати, аналогичная проблема с вытаскиванием из кортежа. fst работает только с кортежом из двух элементов. А гетерогенный список (HList) вроде и есть, а вроде и нет (hMap, hFold и прочее на нём имеют такие сигнатуры, что использование весьма затруднительно).

В результате, половину времени думаешь не над алгоритмом задачи, а над тем, в прокрустово ложе каких хаскелевских типов её уложить.

monk ★★★★★
()
Ответ на: комментарий от byko3y

Это правда. Типичная ситуация у лисперов - когда есть три реализации одного и того же функционала, и ни одна из трех не работает безупречно.

Вот поэтому я рад, что у Racket есть стандартная библиотека, которая закрывает все основные потребности (многопоточность, FFI, GUI, сеть, ...).

monk ★★★★★
()
Ответ на: комментарий от byko3y

Прототип строго уничтожается.

мы так и сделали, но поздно

вывод: конкуренты смогли воспользоваться вашим прототипом

нет, не смогли - они его в глаза не видели

И как бы при чем тут ненужность прототипов

при том, что начальство всю дорогу «кормило»: да рано переходить на плюсы/жабу, смотрите, сколько по времени разработка даже на питоне занимает, представьте сколько по времени займёт разработка на плюсах - а потом оказалось, что на плюсах вышло быстрее, на жабе тоже думаю быстрее было бы

next_time ★★★★★
()
Ответ на: комментарий от byko3y

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

next_time ★★★★★
()
Ответ на: комментарий от monk

Cobol - востребован. Никто в здравом уме не будет на нем писать новые приложения

Ознакомься: https://habr.com/ru/company/wirex/blog/431558/

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

byko3y ★★★★
()
Ответ на: комментарий от monk

И разве мы довольны окружением, в котором работаем?

ага )

Windows уязвим, Visual Studio работает слишком медленно, из Vim’а невозможно выйти.

поэтому, я и не пользуюсь всем этим

next_time ★★★★★
()
Ответ на: комментарий от byko3y

Кобол имеет слабые выразительные средства, когда нужно сделать чуть больше, чем «прочитать строку из файла».

js даже таких выразительных ср-в не имеет, но на нём все пишут

next_time ★★★★★
()
Ответ на: комментарий от next_time

Ознакомься: https://habr.com/ru/company/wirex/blog/431558/

Статья похожа скорее на стеб какой-то.>

а что там, по-вашему, не так написано? «Долой синтаксис» - очевидно, современные популярные языки имеют синтаксис и прекрасно гуглятся. Разве что программист из племени мумба-юмба, не знакомый с символами «+», "-", "(", ")", может пожаловаться на неясность языка с синтаксисом, но остальные прекрасно его понимают.

Долой встроенные типы

Это то, что не дает JS быть использованым для крупного проекта. В ES6 типы, как раз, добавили. Правда, сохранить совместимость и сделать хорошую систему типов все равно не получится, потому в ближайшее время крупных проектов на JS не будет, по прежнему.

Долой практику метаязыков

Единственный оправданный тезис. Дело в том, что метаязык создает новый язык, новый язык нужно учить, а индусы не обучаемы.

byko3y ★★★★
()
Ответ на: комментарий от next_time

js даже таких выразительных ср-в не имеет, но на нём все пишут

Да, не имеет. Потому его догоняет питон, хотя JS распространился намного шире при помощи браузеров. У питона есть выразительные средства, потому это более приятная альтернатива для большого проекта. Не то, чтобы на питоне приятно писать и поддерживать большой проект - это просто возможно. В случае с JS можно ловить неожиданные ошибки в неожиданных местах, и вы ничего с этим не сделаете - кто-то поменял прототип фундаментального типа, кто-то вызывает функцию не с тем this, кто-то засунул функцию не в то пространство имен (что сделать просто из-за убогости онных), а проблемы с преобразованиями типов в структурах-аргументах - это вообще сказка. По крайней это я узнал из моего скромного опыта с vue.js. Проект, с которым я работаю, содержит 30 тыс строк - постепенно подходим к той границе, где программисты начинают забывать функции и структуры, которые они помнили все наизусть.

Но, все же, нужно заметить, что какой-нибудь захудалый проектик на JS по функционалу таки будет пожирнее многих COBOL-проектов. Почему? Потому что большая часть функционала реализована в самом браузере. Почему умер jQuery, Ajax, Axios? Потому что их функции перешли в сами браузеры, точнее, самые удачные приемы из этих библиотек. Просто, реализация этих функций в C++ в браузере намного стройнее, быстрее, поддерживаемие, чем реализация на самом JS. Таким образом разрабы браузеров разгрузили JS, снова переведя его в ту простоту, где он хорошо работает.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Да, не имеет. Потому его догоняет питон, хотя JS распространился намного шире при помощи браузеров.

Кто кого догоняет неясно, так как Node.js появился тогда, когда питон уже вытеснил перл и стал стандартом де-факто, для бэкендов веб-приложений.

Но, все же, нужно заметить, что какой-нибудь захудалый проектик на JS по функционалу таки будет пожирнее многих COBOL-проектов.

Смеёшься? Всё, что было проще, чем самый тяжёлый проект на JS, давно уже переписали на Java.

Почему? Потому что большая часть функционала реализована в самом браузере.

Браузер даёт только отрисовку, а не алгоритмы. К тому же, если речь про питон/кобол/js, то это серверная часть, где вместо браузера NodeJS и особой разницы в доступных библиотеках у языков нет.

Просто, реализация этих функций в C++ в браузере намного стройнее, быстрее, поддерживаемие, чем реализация на самом JS.

Только пишется дольше. И отлаживать сложнее. Основной критерий — быстрее. Разработчики браузеров встроили функции из распространённых библиотек, чтобы их браузер быстрее выполнял приложения на JS.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Кто кого догоняет неясно, так как Node.js появился тогда, когда питон уже вытеснил перл и стал стандартом де-факто, для бэкендов веб-приложений.

А я вообще не упоминал бэкэнды. JS всегда был языком фронтенда, пока что он в основном им и остается. Но по общей популярности JS давно уделывал питон.

Всё, что было проще, чем самый тяжёлый проект на JS, давно уже переписали на Java.

Ты сейчас о чем? Особенно в свете того, что я пишу в этом сообщении.

Браузер даёт только отрисовку, а не алгоритмы. К тому же, если речь про питон/кобол/js, то это серверная часть, где вместо браузера NodeJS и особой разницы в доступных библиотеках у языков нет.

Кроме чисто визуальных продвинутых операции с DOM, из jQuery перетек request в движки JS, а также появились новые типы данных, вроде типизированных массивов, а также worker потоки. Нода - это, все-таки, кусок браузера, от которого отпилена часть интерфейсов и присобачены новые. Хотя, тот же spidermonkey почему-то не спешат отпиливать от браузера.

Просто, реализация этих функций в C++ в браузере намного стройнее, быстрее, поддерживаемие, чем реализация на самом JS.

Только пишется дольше. И отлаживать сложнее. Основной критерий — быстрее. Разработчики браузеров встроили функции из распространённых библиотек, чтобы их браузер быстрее выполнял приложения на JS.

Я не помню, чтобы разрабов фронтендов когда-то смущала низкая производительность сайта. Они будут делать его настолько тормозным, насколько можно для приемлимой работы с сайтом, хотя можно было бы сделать его намного быстрее. Вот что более серьезно - так это когда сайт перестает работать на некоторых функциях и/или браузерах, потому что какая-то библиотека новее, какая-то старее, интерфейсы/типы разлезлись, реализации в браузерах отличаются - и привет.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Ты сейчас о чем? Особенно в свете того, что я пишу в этом сообщении.

О том, что COBOL-проекты — это системы управления корпорациями. На 2013 год COBOL поддерживает 90% бизнес-систем, используемых корпорациями из списка Fortune 500 и используется в 85% всех ежедневных финансовых (бизнес) транзакций. А JS — сайтики. Сравнивать функциональность отрисовки даже фейсбука или гуглопочты и функциональностью системы управления корпорацией даже не смешно.

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

Именно. Поэтому разработчики браузеров начали пиарить свои изделия производительностью сайтов. https://www.businessinsider.com/google-chrome-vs-firefox-speed-performance-co...

monk ★★★★★
()
Ответ на: комментарий от monk

На 2013 год COBOL поддерживает 90% бизнес-систем, используемых корпорациями из списка Fortune 500 и используется в 85% всех ежедневных финансовых (бизнес) транзакций.

Нужно понимать, что какой-то сайтик среднего уровня на JS по сложности (именно сложности) соответствует написанной на COBOL части той самой бизнес-системе корпорации из списка Fortune 500. Прокатывает это потому, что для кобола наделали на более динамичных языках обвязку, благодаря чему проверенные бабули могут продолжать писать ответственный софт. Это не преувеличение - там в прямом смысле бабушки сидят пишут софт. Но они свои, они проверенные, а для крупных корпораций вопросы рисков стоят прежде всего.

Именно. Поэтому разработчики браузеров начали пиарить свои изделия производительностью сайтов. https://www.businessinsider.com/google-chrome-vs-firefox-speed-performance-co...

Я хотел написать о том, что грамотное проектирование сайта переплевывает весь выхлоп от оптимизации браузера. Грубо говоря, можно сказать, что все усилия создателей браузеров направлены на то, чтобы сайты могли писать всё более умственно отсталые люди. Это обеспечивается и производительностью, и стандартизацией, в том числе введением тех же типизированных массивов и слияний объектов в ES6, или встроенная функция request(), которая так-то дает плюс-минус ничего в плане производительности, но зато дает более ясный интерфейс вместо множества нестандартных в лице jQuery, axios, etc.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Нужно понимать, что какой-то сайтик среднего уровня на JS по сложности (именно сложности) соответствует написанной на COBOL части той самой бизнес-системе корпорации из списка Fortune 500

В чём измеряем сложность? Количество строк, количество точек принятия решений, количество типов (структур данных)? По всем этим параметрам программы на COBOL'е намного сложнее. Даже 1С: Бухгалтерия (которая примерно соответствует учётной части бизнес системы и не содержит планирования, бюджетирования, согласования, логистики, документооборота и производства) — это 3,5 миллиона строк кода (без комментариев), 200 тысяч процедур и 65 тысяч функций, порядка 1000 таблиц СУБД. Хочешь сказать, много сайтиков среднего уровня большей сложности?

Грубо говоря, можно сказать, что все усилия создателей браузеров направлены на то, чтобы сайты могли писать всё более умственно отсталые люди.

Так я и не спорю. Переход COBOL → Java преследует ту же цель. Но вот вопрос: качество языка программирования определяется «чтобы программы могли писать всё более умственно отсталые люди»? Или всё-таки, чтобы нормальные люди могли писать более качественные программы (или на худой конец, программы такого же качества с большей скоростью)?

monk ★★★★★
()
Ответ на: комментарий от monk

Количество строк, количество точек принятия решений, количество типов (структур данных)

Пардон, был слишком краток. По сложности выполняемых программой действий. Операции кобола очень примитивны, потому элементарный ассоциативный массив, работа с которым в JS пишется за пять минут, будет писаться пять часов в коболе. То есть, программист может сделать меньше - это плюс и минус языка одновременно: пока он будет писать программу, он сам поймет, что написал. И наоборот, алгоритмически сложные действия, описываемые парой символов, опасны из-за того, что программист делает слишком много за слишком мало времени. С появлением react/vue.js страницы начали выполнять чудовищно сложные действия, при этом праграммист почти ничего не пишет - просто дергает за ручки.

1С: Бухгалтерия (которая примерно соответствует учётной части бизнес системы и не содержит планирования, бюджетирования, согласования, логистики, документооборота и производства) — это 3,5 миллиона строк кода (без комментариев)

Я подчеркнул, что именно код на COBOL, исключая его обвязку. Обвязка там жирная, это правда, и я писал почему - потому что на самом коболе ее писать будет неподъемно. Потому какое-нибудь окошко с табличкой на коболе можно сделать, но само окошко написано на крестах или жаве, а кобол только скармливает окошку данные и настройки отображения.

1C - хорошая аналогия, но какая часть коммерсов эксплуатирует систему 1С, содержащую хотя бы 100 тыс написанных строк, помимо стандартной поставки.

Грубо говоря, можно сказать, что все усилия создателей браузеров направлены на то, чтобы сайты могли писать всё более умственно отсталые люди.

Так я и не спорю. Переход COBOL → Java преследует ту же цель.

Кобол очень прост, потому я не вижу здесь преследование той же цели. Прееход Кобол -> Жава происходит потому, кобол уже не может полноценно использовать возможности железа.

Просто, реализация этих функций в C++ в браузере намного стройнее, быстрее, поддерживаемие, чем реализация на самом JS.

Только пишется дольше. И отлаживать сложнее. Основной критерий — быстрее. Разработчики браузеров встроили функции из распространённых библиотек, чтобы их браузер быстрее выполнял приложения на JS.

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

Именно. Поэтому разработчики браузеров начали пиарить свои изделия производительностью сайтов

Я хотел написать о том, что грамотное проектирование сайта переплевывает весь выхлоп от оптимизации браузера. Грубо говоря, можно сказать, что все усилия создателей браузеров направлены на то, чтобы сайты могли писать всё более умственно отсталые люди.

Но вот вопрос: качество языка программирования определяется «чтобы программы могли писать всё более умственно отсталые люди»? Или всё-таки, чтобы нормальные люди могли писать более качественные программы (или на худой конец, программы такого же качества с большей скоростью)?

Как я понимаю, контекст тот же - Javascript. В JS никогда не было проблем с производительностью - они надуманные. Сайты делают хуже, сайты тормозят - разрабы браузеров делают быстрее движки, чтобы сайты быстрее тормозили. JS был слеплен за 10 дней, и всю историю под JS пытаются подставить разные костыли - вот тебе ES6, вот тебе новые стандартные механизмы. Может быть реализация этих функций на крестах и быстрее, но почему же тогда не ускоряют простой старый JS? Потому что фактора два, стандартизация и производительность, и, по сути, они все служат одной цели - говностроению.

А теперь скажи мне: почему никого вообще не парит вопрос безопасности просмотра интернета? Что мои пароли не утекут через уязвимости, что я не словлю трояна, который бесшумно встанет на мой комп, что каждое мое посещение не будет отслеживаться гуглем. Это разве не один из критериев «качества языка программирования»?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Операции кобола очень примитивны, потому элементарный ассоциативный массив, работа с которым в JS пишется за пять минут, будет писаться пять часов в коболе.

А зачем его писать в коболе, если это структура хранения данных? Он будет в DL/1, DB2 или любом другом хранилище данных. И даже если сильно приспичит, бинарный поиск и вычисление хэша есть, сделать на них ассоциативный массив несложно (не 5 часов).

С другой стороны, сколько будешь писать на JS реализацию кобольного типа PIC 9(15)v9(4) для расчёта ФСС с точностью до сотой доли копейки или PIC 9(30)v9(60) для расчёта чего-то с наименьшей потерей точности.

monk ★★★★★
()
Ответ на: комментарий от byko3y

Операции кобола очень примитивны

Функции и библиотеки в коболе тоже есть. Поэтому одной операцией вполне может быть «рассчитать движения транспорта по заданной таблице потребления подразделений».

monk ★★★★★
()
Ответ на: комментарий от byko3y

Я подчеркнул, что именно код на COBOL, исключая его обвязку.

На мейнфреймах вся обвязка тоже на Коболе. Или ты про операционную систему?

Потому какое-нибудь окошко с табличкой на коболе можно сделать, но само окошко написано на крестах или жаве, а кобол только скармливает окошку данные и настройки отображения.

У JS то же самое. И вообще у любого языка, на котором не написана используемая ОС, то же самое.

monk ★★★★★
()
Ответ на: комментарий от byko3y

1C - хорошая аналогия, но какая часть коммерсов эксплуатирует систему 1С, содержащую хотя бы 100 тыс написанных строк, помимо стандартной поставки.

Э-э-э... А какая часть пользователей сайта использует его версию, содержащую хотя бы 100 тысяч строк, помимо написанных разработчиком?

В случае, когда у коммерса есть отдел программирования, то почти все. Потому что отдел программирования пишет в среднем не менее 100 строк в день и за 4-5 лет получается уже более 100 тысяч строк.

monk ★★★★★
()
Ответ на: комментарий от byko3y

Кобол очень прост, потому я не вижу здесь преследование той же цели. Прееход Кобол -> Жава происходит потому, кобол уже не может полноценно использовать возможности железа.

Посмеялся... Кобол намного сложнее Java, иначе за его знание не платили бы в разы больше, чем за знание Java.

И скорость выполнения программ на Кобол сравнима с C, а не с Java: http://opencobol.add1tocobol.com/gnucobol/#what-about-gnucobol-in-high-perfor...

monk ★★★★★
()
Ответ на: комментарий от byko3y

В JS никогда не было проблем с производительностью - они надуманные.

Смотря с чем сравнивать. С Java вровень, c С/С++ — JS в 3 раза медленнее.

Может быть реализация этих функций на крестах и быстрее, но почему же тогда не ускоряют простой старый JS? Потому что фактора два, стандартизация и производительность, и, по сути, они все служат одной цели - говностроению.

Ничего не понял. Простой старый JS тоже радикально ускорили. Можешь взять любой старый код и замерить на Netscape 3.5 и современном Chrome. Вообще скорость JS сейчас близка к теоретически максимальной. Для большей скорости из языка надо выкидывать сборщик мусора и динамическую типизацию.

А теперь скажи мне: почему никого вообще не парит вопрос безопасности просмотра интернета?

Как это не парит? Браузер запускает код с сайта в контролируемом окружении (sandbox).

Что мои пароли не утекут через уязвимости

Это разработчики браузеров очень тщательно отслеживают. JS не имеет доступа к памяти и к другим окнам браузера.

что я не словлю трояна, который бесшумно встанет на мой комп

JS из браузера не имеет доступа к диску. Так что разве что сам запустишь.

что каждое мое посещение не будет отслеживаться гуглем

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

Это разве не один из критериев «качества языка программирования»?

Нет конечно. Эти параметры никак не зависят от характеристик JS и даже (в части посещений и троянов) от его наличия.

monk ★★★★★
()
Ответ на: комментарий от byko3y

«Долой синтаксис» - очевидно, современные популярные языки имеют синтаксис и прекрасно гуглятся.

rust, хаскель, C# - нет, в хаскеле и вовсе разрешено свои операторы создавать

Это то, что не дает JS быть использованым для крупного проекта.

JS тут не причём. автор говорит о повсеместной замене строго типизированными числами слаботипизированных в прикладном коде

в плюсах это можно написать так:

template<int min, int max>
class Num
{
int actual_value;
...
};

next_time ★★★★★
()
Ответ на: комментарий от monk

Но вот вопрос: качество языка программирования определяется «чтобы программы могли писать всё более умственно отсталые люди»? Или всё-таки, чтобы нормальные люди могли писать более качественные программы (или на худой конец, программы такого же качества с большей скоростью)?

Качество языка определяется минимизацией стоимости разработки на нём продукта соответствующего ТЗ, т.е. времязатратами на получение продукта с требуемыми свойствами.

В перспективе, идеальный язык - это сильный AI, способный за час написать ПО лучшего качества, чем аналогичное, написанное толпой «нормальных людей» за год. Из чего можно сделать вывод, что да, в пределе качество языка определяется «чтобы программы могли писать всё более умственно отсталые люди».

next_time ★★★★★
()
Ответ на: комментарий от next_time

В перспективе, идеальный язык - это сильный AI, способный за час написать ПО лучшего качества, чем аналогичное, написанное толпой «нормальных людей» за год.

Тогда этот AI должен быть не только сильным, но и читающим мысли. Или он напишет, ПО лучшего качества, которое нужно ему, а не людям.

monk ★★★★★
()
Ответ на: комментарий от monk

Тогда этот AI должен быть не только сильным, но и читающим мысли.

вы когда программы пишете, тоже мысли читаете?

Или он напишет, ПО лучшего качества, которое нужно ему, а не людям.

современные технологии таргетированной рекламы уже позволяют с разумной точностью предсказывать потребности людей, в будущем они ещё более разовьются

next_time ★★★★★
()
Ответ на: комментарий от byko3y

Не подскажешь, почему в 2019 жава практически нигде, кроме числодробильных серверов для бизнеса, не используется?

Странно, в моём мире она используется на каждом андроид смартфоне. А в вашем как, коммунизм наступил?

next_time ★★★★★
()
Ответ на: комментарий от monk

А зачем его писать в коболе, если это структура хранения данных? Он будет в DL/1, DB2 или любом другом хранилище данных

Если так неаккуратно говорить, то можно плавно прийти к более общему вопросу, вроде «зачем писать в коболе?» - и он будет справедлив.

С другой стороны, сколько будешь писать на JS реализацию кобольного типа PIC 9(15)v9(4) для расчёта ФСС с точностью до сотой доли копейки или PIC 9(30)v9(60) для расчёта чего-то с наименьшей потерей точности.

https://www.npmjs.com/package/js-big-decimal - просто это никому не нужно в JS.

byko3y ★★★★
()
Ответ на: комментарий от monk

Функции и библиотеки в коболе тоже есть. Поэтому одной операцией вполне может быть «рассчитать движения транспорта по заданной таблице потребления подразделений».

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

byko3y ★★★★
()
Ответ на: комментарий от monk

На мейнфреймах вся обвязка тоже на Коболе. Или ты про операционную систему?

То самое «DB2 или любое другое хранилище данных», ровно как и другие либы писаны не на коболе. Я приводил пример GUI, с которым кобол без сторонней помощи решительно не умеет работать.

У JS то же самое. И вообще у любого языка, на котором не написана используемая ОС, то же самое.

Да. Но у кобола возможности внутри самого языка меркнут перед возможностями вне языка. JS вполне себе способен лепить на чистом листе очень гибкий интерфейс, вплоть до того же unreal engine, запущенного в браузере.

byko3y ★★★★
()
Ответ на: комментарий от monk

А какая часть пользователей сайта использует его версию, содержащую хотя бы 100 тысяч строк, помимо написанных разработчиком?

Сейчас сайты кошмарно тяжелые стали. Тот проект, с которым я сейчас работаю, содержит 30 тыс строк написанные макаками на месте, но при загрузке титульной страницы оно уже грузит 500 Кб жабоскрипта в непожатом виде, а как пару страничек открыл, да еще и с WYSIWYG редактором - привет, 5 Мб жабоскрипта. И это как бы только сам высокоуровневый язык логики, который отдает команды браузеру. А есть еще стили, JSON-конфигурации.

В случае, когда у коммерса есть отдел программирования, то почти все. Потому что отдел программирования пишет в среднем не менее 100 строк в день и за 4-5 лет получается уже более 100 тысяч строк.

Я сомневаюсь, что много коммерсов выкладывают 5 лямов рублей на создание свой системы на 1С. Я знаю один крупный завод, который по состоянию на 2010 год выложил 500 тыс долларов на свой софт. Но это огромный завод, который в длину, от одного края к другому, проходится пешком за час. Таких предприятий в СНГ можно по пальцам пересчитать. То, что готов выложить средний коммерс - это 10-20 тыс $. А мелкие - и того меньше.

byko3y ★★★★
()
Ответ на: комментарий от monk

Посмеялся... Кобол намного сложнее Java, иначе за его знание не платили бы в разы больше, чем за знание Java.

За работу в плавильном цехе много платят, но знания тут не при чем. Просто работа в плавильном цехе тяжелее, чем в офисе. Примерно такая ситуация, например, с COM, которым много человек владеет, но никто не хочет на нем писать. Собсна, с 1С тоже много людей бежит - приходится компенсировать через ЗП.

И скорость выполнения программ на Кобол сравнима с C, а не с Java

Да, потому что уровень абстракций кобола сравним с асм-ом, уроень абстракций и выразительная способность даже Си находится значительно выше кобола.

byko3y ★★★★
()
Ответ на: комментарий от monk

Смотря с чем сравнивать. С Java вровень, c С/С++ — JS в 3 раза медленнее.

JS не рисует страницу, JS не грузит данные и не разбирает JSON, JS отвечает только за логику - потому его производительности хватает с большим запасом. Вот когда ты делаешь на JS виртуальную машину и запускаешь на нем Unreal Engine - тогда да, по производительности в разы проигрывает аналогичной реализации на C++. Но это уже бред, для веба всё это не нужно, и простая динамическая страница может очень много и очень быстро, даже на старом браузере.

byko3y ★★★★
()
Ответ на: комментарий от monk

Что мои пароли не утекут через уязвимости

Это разработчики браузеров очень тщательно отслеживают. JS не имеет доступа к памяти и к другим окнам браузера.

что я не словлю трояна, который бесшумно встанет на мой комп

JS из браузера не имеет доступа к диску. Так что разве что сам запустишь.

В идеале. А как насчет уязвимостей и произвольного выполнения кода? Причем, не только по отношению к наглухо огороженному процессу JS. Чрезмерная оптимизация приводит к повышению возможностей для уязвимостей - это неизбежно, и это случилось с браузерами. Также, например, это случилось с теми же процессорами (Spectre/Meltdown).

byko3y ★★★★
()
Ответ на: комментарий от next_time

вы когда программы пишете, тоже мысли читаете?

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

Нет, если сильный AI может реализовать задачу типа «Напиши интересную книгу», или классическое «Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова... Пользователь может играть лесными эльфами, охраной дворца и злодеем....», тогда конечно. Но я сомневаюсь, что это возможно без человеческого личного опыта. То есть AI-андроид должен прожить лет 20-30 в человеческом обществе так, чтобы все думали, что он человек. Тогда у него будет достаточно информации.

monk ★★★★★
()
Ответ на: комментарий от next_time

«Долой синтаксис» - очевидно, современные популярные языки имеют синтаксис и прекрасно гуглятся.

rust, хаскель, C# - нет, в хаскеле и вовсе разрешено свои операторы создавать

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

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.