Состоялся релиз Ruby 3.3.0, динамического объектно-ориентированного языка программирования, отличающегося высокой эффективностью разработки программ и вобравшего в себя лучшие черты Perl, Java, Python, Smalltalk, Eiffel, Ada и Lisp. Код проекта распространяется под лицензиями BSD ("2-clause BSDL") и "Ruby", которая ссылается на последний вариант лицензии GPL и полностью совместима с GPLv3...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60347
>планировщик потоков "M:N", позволяющий для сокращения накладных расходов на создание и управление потокамиНа каком числе потоков об этом стоит начинать задумываться? Вот, например, в моём коде живёт под 1000 потоков, но они достаточно самостоятельные и выделяются динамически. Отладка может быть _весьма_ увлекательной и замеры производительности тоже своеобразные, в остальном, не наблюдаю особых проблем. Правда, у меня питон и асинхронные либы (и асинхронные обёртки над сишными либами), сложно сказать, столько тут уходит интерпретатору.
На любом количестве потоков где есть взаимодействие потоков. Те практически любой многопоточный код с мьютексами.Когда у тебя потоки независимы у тебя и так параллелизм есть. Вопрос как его достичь (максимизировать) когда есть общая память.
> в моём коде живёт под 1000 потоковGIL не беспокоит ?
Не особо, всё ещё терпимо. Значительную часть времени они ждут, а когда им хочется одновременно поработать, упирается не в процессор. В первую очередь, пришлось отказаться от сомнительных библиотек вроде requests, из моего опыта, она упиралась в гил уже на ~2 потоках и процессы резко оказывались быстрее (но тут сопутствующие расходы добавлялись) -- помогла замена на pycurl. А сейчас есть aiohttp вполне неплохого уровня (особенно после pycurl). В общем, вопрос задач и выбора компонентов, чем меньше pure-python, тем лучше.
Может я не очень вас понимаю, но почему Python? Новость-то про Ruby вроде как?
> чем меньше pure-python, тем лучше.тогда зачем это все ?
А в чём суть софтины? Не секрет же, не?
Питон окончательно вытеснил руби отвсюду
Так и есть. Зачем его поддерживают до сих пор, неясно. Как и всякие лазарусы/fpc и прочую мертвечину.
Ну да, ну да - пошли мы нафиг сказали гитхаб с гитляпом и всякие redmine'ы. И твиторы-шопифи-айрбнб-с-твичами - тоже пошли.
Скорее всего, они существуют, потому что у их разрабов маки. Редхат по той же причине пропихивал. Но, в любом случае, всё это осталось в 2008, сейчас готовые продукты просто всё ещё дороже переписать чем сопровождать, вон кобол до сих пор не извели до конца (и ты его видишь куда чаще, чем думаешь).
Неееее... это perl существует по тому, что "у их разработчиков был unix" - и вот он примерно "мёртв". А ruby вполне себе жив - de-facto безальтернативные отраслевые решения на нем вполне себе в стадии активного развития а не в фазе поддержки.
Примеры безальтернативных решений можно?
github\gitlab для индустрии de-facto безальтернативны, нет?
Чего вы все периодически докапываетесь до perl-а!?
Он что, вам жить мешает или кушать не дает!?
Если лично я не использую perl, это не значит что он мертв!
Или если мы с тобой, по жизни, никогда не встретимся, это же на значит что один из нас сдох.
Помню в молодости на коленке и срочно под НГ рассчитал на нем премию на несколько тысяч человек, и после этого остались лишь приятные воспоминания о нем.
> Чего вы все периодически докапываетесь до perl-а!?
> Он что, вам жить мешает или кушать не дает!?
> Если лично я не использую perl, это не значит что он мертв!
> Или если мы с тобой, по жизни, никогда не встретимся, это же
> на значит что один из нас сдох.
> Помню в молодости на коленке и срочно под НГ рассчитал на нем
> премию на несколько тысяч человек, и после этого остались лишь приятные
> воспоминания о нем.Таки и я на нем - в молодости. Хороший был язык (нет) - жаль (тоже нет), что помер.
Это просто требует поддержки. Новые проекты уже мало кто пишет, как и на php.
Эээээм... и его ТОЖЕ python "отовсюду вытеснил"?!
Ну нет, товарищи на вордпрессе фигачат проекты как из пулемета.
> Ну нет, товарищи на вордпрессе фигачат проекты как из пулемета.Танк секретный - за пределами палаты №6 могут и не знать...
Палаты там обширные больные уже лет 10 из них не выходят света белого не видят. Не знают что в мире делается.
что там фигачить, если уже всё готово, поменял обои под очередного заказчика и всё
Не знаю больные же люди кто знает чего там фигачат может они собственные плаги поддерживают может психодизайн. К ним близко лучше не подходить.
не думаю что питон кого-то вытеснил, просто руби сдох
> Питон окончательно вытеснил руби отвсюдуПоправлю
"Несмотря на то, что Python самый тормозной язык и сильно отапливает нашу Планету, он окончательно вытеснил руби и другие менее затратные языки программирования отовсюду. Наступила эра Идиократии. Алилуя"
ПС. надеемся на mojo. Быть может, он что-то исправит в этом недоразумении - Python
Когда ruby ещё рассмативался как конкурент питона, стандартная реализация rudy неприлично проигрывала в производительности CPython-у. И питон при этом даже не был самым быстрым ЯП по сравнению с другими конкурентами вроде перла и php. Со временем у питона появились различного рода ускорители вроде JIT-ов, компиляторов и Cython-ов, но от ЯП такого класса требуются вменяемые ТТХ только в режиме работы интерпретатора.
Не только лишь все выбирают архитектуру приложений, многим приходится донашивать то что осталось. Плюс клиент не всегда доверяет экспертизе заказчика, он слышал что сейчас модно и что используют в "крутых" проектах и ЯЪ хочу так же на рельсах. Так что все эти споры кто быстрее интересны только как досужие разговоры на кухне, а на практике приходится апгрейдить перловый движок рельсовыми вкраплениями, а впереди ещё ужас того что в очередной раз захочет клиент.
Внимание, а теперь правильный ответ.
Сравнение производительности Ruby c Python:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...Вывод: В большинстве тестов Ruby рвет Python как тузик грелку с достаточно большым разрывом, в тех немногочисленных тестах, где Python оказывался быстрее наблюдалось совсем небольшое отставание Ruby.
Я таки вам скажу даже больше Python вчистую по производительности сливает даже древним интерпретируемым VBA и VBScript, не говоря уже о компилируемом VB (не путать с современным VB.Net, которому впрочем Python тоже сливает с разгромным счетом)
Python - это пример того, как никчемная технология завоевала широкое признание. Да, к сожаление, в нашем мире так бывает.
Здесь все сравнения кривые, но даже по ним CPython как раз получается лучше оптимизированным и сбалансированным...В первом fannkuch-redux сравиниваются однопоточнрые версии с распараллеливанием. В однопоточном Python против Ruby 15 минут против 24, т.е. Ruby просел радикально. С раскидыванием по процессам и потокам получается обратная картина - примерно 280 сек против 180.
Однако в варианте Ruby потоки и кастомная реализация раскидывания заданий против стандартной реализации на процессах в Python. Фактически во вторых тестах сравнили только код распараллеливания, а не сами языки с интерпретаторами. Просадка на 10 минут в однопотоке гораздо хуже просадки 100 сек из-за обвязок раскидывания по процессам.
Итого... Ruby везде запускаеться --yjit, хотя питон только интерпретаор. Тем не менее даже так Ruby на некоторых тестах, как выше, умудряется ощутимо сливать. Также нужно обратить внимание на память, в Ruby реализациях обычно раза в два потребление больше и в некоторых тестах разница ещё выше.Основной сценарий использования ЯП из этой ниши это однопоточные приложения. Чтобы правильно сравнивать, базово нужно тестировать в однопотоке и без JIT. Тесты с JIT нужно показывать отдельно, также отдельно нужно показывать результаты распараллеливания на точно такой же нагрузке чтобы оценить эффективность обвязок и потоков. Дополнительно нужно тестировать время холостого запуска, этого вообще нет, хотя на практике одна из важных характеристик (например, скрипт нужно запустить 10к раз). В тестах всё навалено в кучу и просто так не разобрать что и с чем сравнивается.
У Руби и питона почти не было областей пересечения. Разве что средства развёртывания и пр. В веб-разработке питон в любом случае не имеет никакой значимой доли и перспектив роста.
Ну вообще-то Django достаточно популярный фреймворк, Flask популярен тоже для небольших поделок, сейxас еще и FastApi. Для сайтов типа Google или Amazon конечно не подойдет, а вот для средне-мелких сайтов, Enterpris-а, оболочек для продуктов ML самое то.
Доля питона в веб разработке - какие-то единицы процентов. Ну нет у него шансов против JS/TS. Да и библиотеки ML (которые на прод-сервисы ориентированы) сейчас под JS/TS тоже по-умолчанию делают.
Ты проспал, жс на бэкенде это была дичь для "экономных" и ожидаемо не работает, вроде сегодня уже никто не ведётся.
> Ну нет у него шансов против JS/TS.Подходит только для "фронтенд" серверов для сбора данных и выплевывания в браузер. Для серьезных бэкнедов почти не используется. Ну либо просвети нас.
"Серьёзный бакенд" - это либо Java, либо C#, либо Julia, либо Rust. Ну и уж совсем серьёзный - C++... Но никак не скриптовое.
> "Серьёзный бакенд" - это либо Java, либо C#, либо Julia, либо Rust.
> Ну и уж совсем серьёзный - C++... Но никак не скриптовое.Осталось ввести понятие "серьезный".
Предложение: если бэкенд считает свои "миллиарды" - то он "серъезный".Если сунуться в "кровавый энтерпрайз, что не любит оверпрайс" - питона на бэке будет много. Он тут везде.
Да, медленный. Но быстрый в разработке. Плюс датасатанисты не учат TS/C++/JAVA - оно им не нада. С этими ребятами невозможно договориться, чуть-что - заявление на стол.
Ну, тут два измерения - первое это highload, у них своя атмосфера - второе это "сложная бизнесуха", и вот там - ява, шарп, пайтон, гошка.
'Серьёзный' бэкэнд это пока что только с++, чуть менее серьёзнее Java, C# и Go. Julia не ЯП общего назначения и не для бэкендов вообще. Rust ещё не взлетел в этой категории, в лучшем случае взлетает в системщине. Тем не менее питон почти всегда рядом в 'серьёзном' бэкенде в виде обслуживающих бэкенды сервисах, в виде UDF-ок и промежуточных прослоек. Нужно понимать, что не любую логику можно и нужно уносить с питона на дургие ЯП.
techempower говорит что ты немного не в теме, либо 'Серьёзный' именно что в кавычках
techempower не персона чтобы что-то говорить. Предлагаешь мне самому додумать что у тебя там в советской голове?
> Для сайтов типа Google или Amazon конечно не подойдетЛол
> вобравшего в себя лучшие черты Perl, Java, Python, Smalltalk, Eiffel, Ada и Lisp.Из этого списка только Python и Java является хоть чем-нибудь стоящим
Остальное - либо академические игрушки, либо просто легаси, которое-то и называть в слух уже не прилично.
Разработчики критически важных систем на ADA сейчас поперхнулись чаем. Опеннет берет новые высоты пробитого дна!
а что пишут на ада? вот на лиспе - искусственные нителекты.
Прошивки для видеокарт (на спарк, если точнее). Вообще я так смотрю весьма актуальный язык, куда больше перспектив на сегодня, чем у того же раста.
Чтоооо? Покажи пример такой прошивки
> Чтоооо? Покажи пример такой прошивкиТут спроси исходники https://www.nvidia.com/
Или тебе на фото показать, где она?
А так, первая же ссылка в интернете ведёт куда-то сюда, можешь там ещё поспрашивать https://www.adacore.com/nvidia
Что, целая 1 прошивка, мистер "слышал звон, да не знаю где он"?Время Ada безвозвратно ушло, в связи с тем, что это во-первых, действительно язык Ада - то есть министерства обороны США, во-вторых - большинство компиляторов языка Ada были платными и плохого качества. Да и сейчас, инструменты для производительной работы с Ada (не компилятор) тоже платные.
И Rust обеспечивает такую же, и даже лучше защиту от "дурака" намного лучше, чем это сделано в Ada и без снижения производительности, как это происходит в Ada.
Ada, как и Cobol - на свалку истории, там им самое место.
Там не одна прошивка, хотя я и сказал только про это. Код как минимум используется в чипах видеокарт и чипах машинного зрения и, судя по презентациям, уже 5 лет все очень довольны. А GNAT вполне себе актуальный компилятор и как раз используется для разработки и верификации кода на SPARK, ты пишешь какие-то несуразицы неразумные. Про Rust, пожалуй, можно оставить без комментариев.
Сейчас полно свободных компиляторов для Ада. Ада спроектирован как язык для сверхнадежных систем. А Раст обеспечивает только защиту от ошибок с управлением памяти, которые составляют лишь малую часть всех возможных багов. Поэтому когда Раст отправится на свалку, Ада вполне будет жить и процветать.
> мистер "слышал звон, да не знаю где он"?
> намного лучше, чем это сделано в Ada и без снижения производительности, как это происходит в Ada.Ясно, понятно... Опеннетная экспертиза как она есть. Ты сообщи об этом ребятам из Nvidia, а то они, дурачки, не знают:
> “Looking at the assembly generated from SPARK, it was almost identical to that from the C code,” he said. “I did not see any performance difference at all. We proved all of our properties, so we didn’t need to enable runtime checks.”
https://www.adacore.com/uploads/techPapers/222559-adacore-nv...
Молодец, в интернете искать можешь.Странно, что ты не нашел сравнение производительности Ada vs Rust, из которого видно, как Rust рвет Ada как тузик грелку:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
В авиация: автопилот, системы управления, сигнализации так далее.
Почти все военные системы США на Ада, ПО для управления реакторами.
Фукусима тоже? Если да, то ну ее Ada в Ад.
> Разработчики критически важных систем на ADA сейчас поперхнулись чаемприведи мне пример хоть одной критически важной системы на ADA
Из того, что я знаю — авиция. Бортовые компьютеры для boeing,F, eurofighter и других самолётов.
спасибо!
А еще в космических кораблях программа управления писалась на Ada пока ракета Ariane 5 не взорвалась (https://habr.com/ru/companies/pvs-studio/articles/306748/)
>покаТ.е., ты утверждаешь, что перестали писать на Ада, но продолжили писать на Фортран и Си? На самом деле, конечно, продолжили писать на Ада, да и факап собственно был никак не связан с языком.
Тыкай свою мамку, а здесь веди себя уважительно. Ошибка была программистская. Такую ошибку можно было сделать на любом языке. Поэтому вопрос - а зачем тогда использовать яpык Ada, который декларирует, что на этом языке нельзя сделать ошибки и если программа скомпилировалась, то там нет ошибок? Программисты на это и понадеялись и не перепроверили при переходе с Ariane 4 на Ariane 5. То есть смысла использовать Ada особо нет. И если почитать американские форумы - той страны, где действительно писали на Ada достаточно много, в не как у нас в СНГ "слышали звон", то американцы пишут, что переходят на Rust и С++ с Ada и сильно этому радуются. Да и GNAT тоже не шибко развивается, скорее стагнирует.
Что за бред сивой кобылы я только что прочитал? Даже комментировать нечего. И мало ли что и кто там пишет в интернетах, код на расте не то что не верифицируется (между прочим, это не про отсутствие ошибок, это про соответствие сгенерированного написанному), а даже не имеет стабильных интерфейсов.
Продолжайте заниматься и дальше самовнушением "Ada - современный язык, с новыми возможностями. Pragma - ни разу не говно мамонта, а неоцененный брульянт и т.д.". Только с голодухи случайно не умрите.
При чём тут самовнушение?>Программисты на это и понадеялись и не перепроверили
В статье прямо указано, что в целях экономии скопировали код, построенный на логических допущениях, из совершенно другой системы, и написанный под иные условия, но, кроме того, отключили все проверки, чтобы уложиться в лимиты, и не предприняли шагов, чтобы не вырубаться при ловле исключения. Но, виноват тут, конечно же, устаревший ЯП. Который с тех пор активно дорабатывали, учтя в том числе подобные случаи, но что толку, правда? Куда надёжнее взять новенький ЯП, не отвечающим никаким стандартам и не имеющий спецификаций, а, ещё лучше, написанный вчерашним веб-программистом.
Ты сначала верхними полушариями думать научись, а не нижними. Все уже наелись твоего дерьмового Раста и отказываются от него в пользу чего угодно, это прекрасно по снизившему количеству вакансий видно. В большинстве случаев нужен не программист на Расте, а на C++, но опционально со знанием Раста. Без знания С++ ты будешь только на мусорках рытся.
А зачем тогда использовать любой другой или вообще какой либо язык, если человек всё равно может ошыбиться?
>пока ракета Ariane 5 не взорваласьХороший пример ошибки, от которой и Раст бы не спас.
http://archive.adaic.com/projects/successes.html
Миллионы мух... Опеннетчиков не могут ошибаться в том, какой язык самый лучший!
Критически важные системы на чём только не пишут. Ада ничего особого для их написания не предоставляет (как защитное программирование например), и была статья почему она используется в боинге, найти увы сейчас не могу, но всё как всегда прозаично - кому-то было выгодно пропихнуть своё решение.
>была статья почему она используется в боинге, найти увы сейчас не могу, но всё как всегда прозаично - кому-то было выгодно пропихнуть своё решение.Ну что ты несешь, а? ADA -- заказ министерства обороны США. MIL-STD-1815/Ada 83 В боинге она использовалась потому что. В случае F-35 до сих пор отказ от нее расхлебывают.
> Java, Python... Остальное - либо академические игрушки,Это Python - чистая академическая игрушка. Как не использовали его в проде, так и не будут. Сейчас просто вектор замены питона изменился. Вместо полного переписывания на Java или доделывания библиотек к питону на C, тупо начали массово использовать Rust.
Я бы на вашем месте, прежде чем утверждать что Питон не используется в проде, сначала хотя бы сделал базовый ресёрч, например
https://hh.ru/search/vacancy?hhtmFrom=main&hhtmFromLabel=vac...
https://hh.ru/search/vacancy?hhtmFrom=main&hhtmFromLabel=vac...или анонимусу с Опеннета виднее, чем людям с деньгами, кто готов платить зп питон-разработчикам ?
Как можно было вобрать лучшие черты из того, где их совсем нет?
Есть такое выражение лучшие из худших. Вполне рабочее.
% ruby -v
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin22]для кого эти новые ветки делают если системный древнючий 2.6
Ловите проприетарщика с маком, не осилевшего brew install ruby!
смешно
сам брю работает на этой 2.6 версии
а это единственное приложение у меня которому нужен руби
Правильнее вопрос для кого делают системы с древнючим софтом.
> Правильнее вопрос для кого делают системы с древнючим софтом.очевидно для тех кто на коплюхторах работает
например програмулькирует на _современных_ и *востребованых* языках
Начинал кодить с Ruby когда-то, приятный язычок... Но Питхон его таки придушил конкретно, это факт...
все язычки которые не могут нормально в винду обречены барахтатся в проруби.
Что такое винда? Какая-то приставка?
То есть все кроме Сишарпа? Однако...
>То есть все кроме Сишарпа?отчего же?
тот же питон имеет хорошую поддержку винды, легко ставится.
Javа тоже легко ставиться.
Впрочем как и многие другие ЯП.
Да не так, чтобы много у них пересечений по функциональным направлениям на самом деле. Падение популярности RoR связано не с тем, что django или там flask "выдавили" (Ха. Ха. Ха.), а скорее с ростом популярности микросервисного подхода и отказом от "тяжеловесных" больших фреймворков.
Мне интересно, Ruby без Ruby on Rails вообще жизнеспособен / нужен?
Из недавнего чем я пользовался - asciidoctor на нем написан. А так$ apt-cache rdepends ruby | tail +3 | grep -v -E ruby-.* | wc -l
230
> 230Ну и там, конечно, много всего "полезного"
$ apt show lolcat
Package: lolcat
Version: 42.0.99-1
Depends: ruby | ruby-interpreter, ruby-trollop (>= 1.16.2), ruby-paint (>= 0.8.3)
Homepage: https://github.com/busyloop/lolcat
Ruby-Versions: all
Description: colorful `cat`
lolcat concatenates files like the UNIX `cat` program, but colors it for the
lulz in a rainbow animation. Terminals with 256 colors and animations are
supported.
> https://github.com/busyloop/lolcat5.7K звезд - все что нужно знать про гитхаб
brew, vagrant, puppet, chef, portupgrade - вполне себе пользовался в разное время, почему нет? Местами альтернатив все еще нет, местами - удобно, местами просто по инерции все еще используется.
Неплохой язык для веба, все еще довольно популярен. По распространенности примерно равен Расту, оба специализированные нишевые языки, только для разных областей. Чем-то похожи между собой своим непростым синтаксисом.
Ruby - это язык с самым прозрачным синтаксисом. Просто он со сдвигом в функциональное программирование, хотя и мягким сдвигом. Rust, в сущности, повторяет некоторые рубийные концепты типа рубийных же модулей и перечислители. Но Rust сейчас активно приобретает популярность из-за питона. Ниша production-ready ML - это будущее для Rust.
> Ниша production-ready ML - это будущее для Rust.Поподробнее что ты под этим подразумеваешь?
Раст может только для ml ops подойдёт, а пока весь код топовых фреймворков на которых все пишут - это с++ и python. Рядом Julia и R шевелятся.
https://github.com/huggingface/candle
Нечего там рассказывать, язык ML это Python, точка, нравится это кому-то или нет.
> язык ML это Python, точкаЕсть только один нюанс. Ни один алгоритм ML на питоне не реализован и никогда не будет реализован. А один из любимых инструментов питонистов - SWIG исключительно из-за непригодности питона к подобным задачам.
Правильнее выразиться, "язык для закидывания данных в С/C++ библиотеку-числодробилку через биндинги"
На pure python CPU-bound задачи не делают. В голом виде он только для веб-сервисов пригоден, т.к. там I/O-bound и даже тормозной Питон на асинхронных веб-либах держит достойный RPS, ибо задачка бэка, чаще всего, по пришедшему JSON в API на 3 if-ах собрать SQL, заслать в БД и вернуть ответ как есть. А учитывая, что пластмассовый мир победил, докер оказался сильней, в случае тормозов можно запустить в кубере N сервисов на Питоне и воткнуть перед ними балансировщик.
А какой смысл тащить питон в прод? Если в компании и так есть C++ разработчики, то зачем городить химеру?
> отличающегося высокой эффективностью разработки программА в плане высокой эффективности исполнения этих программ он отличается? Если да, то в какую сторону?
Всё зависит от ниши. Для задач ML - очевидно нет. Там есть Julia, которая на него очень похожа. В веб-задачах сейчас соизмерим с JS. Для задач скриптов администрирования - там всё замечательно. Во всяких Chef, Puppet проблем со скоростью нет. В тестировании - там тоже производительность не главное. Главное - читаемость текста.
> Там есть Julia, которая на него очень похожа.Чем же джулия похожа на руби?
open("1.txt", "w") do f
write(f, "some text")
endкак думаете, на каком это языке написано?
> open("1.txt", "w") do f
> write(f, "some text")
> end
> как думаете, на каком это языке написано?Даже если на джулии, то говорить после этого о сходстве языков некорректно. С таким же успехом (с немного измененным синтакисом) можно приплести и питон и лисп и что угодно еще.
> Даже если на джулии, то говорить после этого о сходстве языков некорректно.Если копируются базовые синтаксические конструкции, специфичные для конкретного языка, то ещё как корректно. А говорить можете что угодно, только специфичные примеры не сможете подобрать.
>> Даже если на джулии, то говорить после этого о сходстве языков некорректно.
> Если копируются базовые синтаксические конструкции, специфичные для конкретного языка,
> то ещё как корректно. А говорить можете что угодно, только специфичные
> примеры не сможете подобрать.with open(fname) as f:
...open(fname, (f) => { ... })
(with-open-file (fname)
(...))
И что это? И какое оно отношение к Руби или другому языку имеет?
Для Руби блок do..end - один из основополагающих принципов передачи анонимных методов. Как и для Джулии.
> И что это? И какое оно отношение к Руби или другому языку
> имеет?
> Для Руби блок do..end - один из основополагающих принципов передачи анонимных методов.
> Как и для Джулии.Другие языки с той же концепцией: сделать что-то с открытым файлом и закрыть его.
Вот скажи мне какая разница до конкретного синтаксиса? Будет ли там блок или анонимная функция?
> от скажи мне какая разница до конкретного синтаксиса?А чего тогда вообще рассуждать о разных языках, если, как выясняется, нет никакого дела до их синтаксиса и семантики?... Тогда считаем, что все языки одинаковые, раз различия синтаксиса не имеют значения. Так получается?.... Все используем C, и дело с концом.
> Все используем C, и дело с концом.На С ты такой код не напишешь: там функции не объекты первого типа в отличие от приведённых питона, жс и лиспа
#define lambda(lambda$_ret, lambda$_args, lambda$_body)\
({\
lambda$_ret lambda$__anon$ lambda$_args\
lambda$_body\
&lambda$__anon$;\
})printf("%f\n", lambda(float,(float x),{ return 2*x; }));
printf("%f\n", lambda(float,(float x),{ return x/3.0; }));
Ты же понимаешь, что это булшит по сравнению с приведенными примерами. Особенно доставляет приседания с именами вида lambda$_ из-за отсутствия гигиены.
Ты совсем начал в сторону уходить. Ответь мне лучше на поставелнный вопрос: в чем принципиальное отличие твоего кода от приведенного кода на питоне/js/лиспе?
Отличие в том, что блок do..end, определяющий анонимный метод, является основным способом написания кода на Ruby и Julia. Без них никак не обойтись. И именно конструкция do..end была у Ruby в Julia позаимствована, что делает код на Julia, похожим именно на Ruby-кода, а не на JS или питон-код (только вот не надо про [()->i for i in x]). А вот для Python (у которого никих do..end нет) - лямбды - это нашлёпка, без которой он много лет обходился. Как, в общем-то, и JS.Именно о сходстве Julia с Ruby была речь, а не о происхождении лямбд, функций, функторов и прочего.
> Отличие в том, что блок do..end, определяющий анонимный метод, является основным способом
> написания кода на Ruby и Julia. Без них никак не обойтись.
> И именно конструкция do..end была у Ruby в Julia позаимствована, что
> делает код на Julia, похожим именно на Ruby-кода, а не на
> JS или питон-код (только вот не надо про [()->i for i
> in x]). А вот для Python (у которого никих do..end нет)
> - лямбды - это нашлёпка, без которой он много лет обходился.
> Как, в общем-то, и JS.В js и лиспе лямбды были изначально.
> Именно о сходстве Julia с Ruby была речь, а не о происхождении
> лямбд, функций, функторов и прочего.Ну вот цитата из https://juliahep.github.io/JuliaHEP-2023/julia-intro-anonymo...
> More throughly speaking, the do-block syntax makes an anonymous function using the body (between do and end), taking variable names immediately after the do as parameters, and passes this function as the first argument of map(). Note, this works on any function (that expects first argument to be callable), not just map().
> Many functions in the Julia standard library have alternate forms which take a function as their first argument to allow this kind of style. Generally, such functions also perform clean-up after the do-block has completed, making this a lot like with blocks in Python.
> For example, there is a version of open which enables a very familiar form to Python programmers:То есть это просто сахар. Тоже самое можно делать через лямбды.
> Ну вот цитата из https://juliahep.github.io/JuliaHEP-2023/julia-intro-anonymo...Ну вот в чём смысл пытаться убедить, что Ruby-конструкция в Julia, без которой в куче методов нормально код писать нельзя, не является Ruby-конструкцией?.... В каком году появился блок with в питоне? У Руби do..end был от рождения. У Julia - аналогично. Я на C код лямбды с подстановкой адреса функции приводил. В теории, так писать тоже можно. Тем не менее, если "map" в Julia c многострочными функциями преобразования лепить в лямбду, за это так же оторвут руки, как и за ту самую лямбду в C.
>> Ну вот цитата из https://juliahep.github.io/JuliaHEP-2023/julia-intro-anonymo...
> Ну вот в чём смысл пытаться убедить, что Ruby-конструкция в Julia, без
> которой в куче методов нормально код писать нельзя, не является Ruby-конструкцией?....Что значит "нормально код писать нельзя", если это просто сахар?
> В каком году появился блок with в питоне? У Руби do..end
> был от рождения. У Julia - аналогично.Какая разница когда он появился? Lisp появился задолго до питона и руби.
> Я на C код лямбды с подстановкой адреса функции приводил. В теории, так писать тоже можно.
Ты не можешь провести аналогии? Зачем ты прицепился к руби из-за одной концепции? Я тебе привел примеры (к тому же подтвержденные докой), что это просто сахар для анонимных функций и что подобоный код (чтобы сделать что-то до и после) есть в других языках. Но ты уперся и утверждаешь, что лямбды есть в С на уровне языка, приводя в пример макроподстановку, но факт в том, что их нет.
Ты изначально утверждал https://www.opennet.me/openforum/vsluhforumID3/132416.html#80
> Там есть Julia, которая на него очень похожа.
Из-за одной конструкции, которая как выясняется из доки просто сахар и есть в других языках, язык не может быть *ОЧЕНЬ* похож на руби. Я бы сказал, что он совсем не похож. Достаточно открыть рядом два листинга нетривиального кода и сравнить. Но раз ты стоишь на своем, то приведи тогда весь список, что там похожего.
> Тем не менее, если "map" в Julia c многострочными функциями
> преобразования лепить в лямбду, за это так же оторвут руки, как
> и за ту самую лямбду в C.Вот как бы простой поиск https://github.com/search?q=repo%3AJuliaLang%2Fjul... дает кучу контрпримеров.
> Что значит "нормально код писать нельзя", если это просто сахар?Ты когда-нибудь код писал? Как можно называть "сахаром", основную синтаксическую конструкцию? Это тебе не аннотации Java, какие-нибудь, которыми можно обсыпать основной код.
> Вот как бы простой поиск https://github.com/search?q=repo%3AJuliaLang%2Fjul...
> дает кучу контрпримеров.И что? Много среди них многострочников без do..end?
В общем, сядь лучше, да напиши код на Ruby и на Julia, а не читай абстрактные листинги... Или, хотя бы, на Rosetta Code примеры смотри.
>> Что значит "нормально код писать нельзя", если это просто сахар?
> Ты когда-нибудь код писал? Как можно называть "сахаром", основную синтаксическую конструкцию?Давай опеределим, что такое сахар https://en.wikipedia.org/wiki/Syntactic_sugar
> In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express.
В случае Julia я могу использовать многострочную анонимную функцию, что никак не повлияет на поведение программы. Они даже сами пишут, что это просто удобство https://docs.julialang.org/en/v1/manual/functions/#Do-Block-...
> Julia provides a reserved word do for rewriting this code more clearly
Более того далее они пишут
> For example, there is a version of open that runs code ensuring that the opened file is eventually closed:
То есть по факту мы имеем лямбду (ну или блок как сахар), которая будет вызвана и далее файл будет всегда закрыт. И что мы тут видим? Да это же конструкция из лиспа, которую я тебе привел
(with-open-file (fname)
(...))> Это тебе не аннотации Java, какие-нибудь, которыми можно обсыпать основной код.
Не уходи в сторону. Мы не рассматриваем этот язык.
> В общем, сядь лучше, да напиши код на Ruby и на Julia, а не читай абстрактные листинги... Или, хотя бы, на Rosetta Code примеры смотри.
Ну ты приведи пример ссылкой.
Вы правы, насчет Lisp. Julia - это и есть Lisp, поверх которого нацепили синтаксис в форме процедурного программирования. У Julia есть 2 cli - одна с процедурным синтаксисом Julia (запуск $ julia), другая с Lisp синтаксисом (запуск $ julia --lisp).
В общем, учёные в очередной раз хотели сделать хороший ЯП, но снова получился убогий франкенштейн
Пишут, что у них там в команде Julia начались ругачки. Одни обвиняют других в том, что что-то изначально было сделано не так и сейчас переделывать это уже невозможно. А другие типа, - все возможно, язык развивается. Но судя по темпаи развития, исправления багов, внесения фич последняя версия Julia 1.9 как-то значительно медленнее развивается, чем ее предыдущие. Но это субъективно, имхо.
> Пишут, что у них там в команде Julia начались ругачки.А ссылки есть?
> Главное - читаемость текстаНет. Это далеко не главное. Программист, для которого главеое - это читаемость текста, это не программист, а кодомокако.
"Крылья, ноги... Главное - хвост!"
Решение о выборе технологического стека принимает не "программист", а "владелец продукта" - и основной критерий там "общая стоимость владения" с его производными. А что там "главное" очередному "венцу творения с нижней ветки" никому не интересно.
"Владелец продукта" имеет иллюзию, что он принимает решение о выборе технологического стека, соглашаясь с той лапшой, которую ему навешал на уши подрядчик.
> "Владелец продукта" имеет иллюзию, что он принимает решение о выборе технологического стека,
> соглашаясь с той лапшой, которую ему навешал на уши подрядчик.Лапша, навешанная программисту сначала преподом в институте, потом тимлидом конечно же имеет другой вкус :). Детерминизм т.н. "свободного осознанного выбора" штука интересная, но обсуждать мы её наверно не будем, да?
Тимлиду незачем вешать лапшу своему подчинённому, он приказать может. Ну, и да - обсуждать тут нечего.
Программист, который пренебрегает читаемостью кода – это не программист.
Какой-то странный хайп был вокруг Ruby с его Rails. Так и не понял в чём его киллер-фича, когда был уже Django даже, про Perl/PHP молчу.
Да, хайп сильный был. Одни railscasts чего стоили. Ну типа Фреймворк супер простой, тяп ляп готово, кода по минимуму, магия внутри, скафолдинг. Что не говори, а он повлиял на многие фреймворки. Но сейчас зачем все это - хз. В эпоху микросервисов.
Django Initial release: 21 July 2005
Ruby on Rails Initial release: August 2004
Лол, Django был создан как порт Рельсов на питоне, после того как о Рельсах начали писать. Авторам очень понравилось реализация Рельсов и они хотели перенести их в питон мир
А хотя бы поискать в инете не судьба?https://ru.wikipedia.org/wiki/Django
https://ru.wikipedia.org/wiki/Ruby_on_RailsDjango первая версия вышла 21 июля 2005.
Ruby_on_Rails первая версия вышла - 13 декабря 2005
Django вышел на полгода раньше ROR.
Тебя в гугле забанили что-ли? Вон тебе еще сверху написали, что Initial release у рельсов был в августе 2004, и в вики это тоже отражено https://en.wikipedia.org/wiki/Ruby_on_RailsDHH (автор) выделил фреймворк из кода своего проекта, представил его в блог постах, и начался хайп. Она в то время уже была пригодна для прода (и уже давно использовалась в проде в 37 signals), хотя и версия была наверное меньше первой, зачем ты сравниваешь когда вышли версии 1.0 - это вообще загадка.
Решил замериться члеником? Давай моя дата для Djano - Осень 2003 года:Django was created in the autumn of 2003, when the web programmers at the Lawrence Journal-World newspaper, Adrian Holovaty and Simon Willison, began using Python to build applications. Jacob Kaplan-Moss was hired early in Django's development shortly before Simon Willison's internship ended.[16] It was released publicly under a BSD license in July 2005. The framework was named after guitarist Django Reinhardt.[17] Adrian Holovaty is a Romani jazz guitar player and a big fan of Django Reinhardt.[citation needed]
Рельсы появились как отдельный фреймворк (доступный для всех) за год до появления Джанги, а до этого еще обкатывались в проектах компании DHH
> Лол, Django был создан как порт Рельсов на питоне, после того как
> о Рельсах начали писать. Авторам очень понравилось реализация Рельсов и они
> хотели перенести их в питон мирПроблема в твоём враньё в том, что у джанги совсем другие идеи.
Без рельсов Django бы и не появился
> Без рельсов Django бы и не появилсяЗадание на дом тебе - проверить дату релизов.
Уууух, нажористо :). Когда рельсы набирали популярность - python был 2й версии (Строки, кодировки - мммм!) с перспективами перехода к третьей, полноценных MVC-фреймворков на нем не то, чтобы разбежаться было. Perl'а почитай уже не было, PHP был - но на тот момент "лучше-б не было" ))).
Имхо в современной разработке монструозные фрейсворки аля рельсов не нунжны. Рано или поздно начинаешь упираться в ограничения фреймворка и тогда лучше иметь что-то минимальное. Поэтому микрофреймворки или либы типа того же фласка, старлета или аиоххтп гораздо лучше подходят на эту роль. К тому же REST, который продвигали рельсы далеко не везде подходит.
Разработки висящей в вакууме не существует.
Ни современной, ни древней.
Разработка решает конкретные задачи.
Поэтому не стоит так сурово обобщать, ведь не все фреймворки навязывают использовать все их возможности одновременно.
Что факт, так это то, что объективный недостаток всего, что написано на Ruby - недостаточное быстродействие для создания ПО которое должно заниматься массовым обслуживанием.
> Разработки висящей в вакууме не существует.
> Ни современной, ни древней.Существует стек технологий. Он, ествтенно, зависит от времени. Согласись, что ты бы не хотел сопровождать проект на python 1.0 или под С++ 98.
Если сейчас много облачных решений, то и код ты будешь деплоить соответсвующим образом. Например, собирать docker образы, а не deb или rpm пакеты.
> Разработка решает конкретные задачи.
> Поэтому не стоит так сурово обобщать, ведь не все фреймворки навязывают использовать
> все их возможности одновременно.Не использовать ты можешь, но тогда зачем он тебе нужен? Если ты используешь от джанги только шаблоны, то это явно глупость, когда можно взять отдельно шаблонизатор.
Большой фреймворк - это всегда больше кода, а значит и больше возможности чему-то сломаться, дольше релизные циклы фреймворка, а отсюда медленнее фиксы багов. Все микрофреймворки и либы имеют законченный вид и кода там не так много.
> Что факт, так это то, что объективный недостаток всего, что написано на
> Ruby - недостаточное быстродействие для создания ПО которое должно заниматься массовым
> обслуживанием.Помню как во времена пиара рельсов был лозунг "что программист стоит дороже железа". Они прям форсили эту тему. Оказалось, что опять обманывали.
> Согласись, что ты бы не хотел сопровождать проект на python 1.0 или под С++ 98.Речь шла о жёстком разделении решения задачи либо только на фреймворках, либо только на компонентах.
О неподдерживаемых языках речи не было
> Если сейчас много облачных решений, то и код ты будешь деплоить соответствующим
> образом. Например, собирать docker образы, а не deb или rpm пакеты.Правильно. Для каждой задачи свои подходы. О чём и речь.
> Не использовать ты можешь, но тогда зачем он тебе нужен? Если ты
> используешь от джанги только шаблоны, то это явно глупость, когда можно
> взять отдельно шаблонизатор.Верно.
Если нужны только шаблоны, и дальше тоже будут нужны только шаблоны - то и надо брать только шаблоны.
А если фреймворк толковый, то он и позволит взять только шаблоны, а потом, при надобности, без чрезмерных страданий вставить остальное.> Все микрофреймворки и либы имеют законченный вид и кода там не так много.
Как и возможностей.
Которые, в случае если решаемая задача была описана неверно, придётся наращивать на ходу.
А это не очень здоровое занятие, на ходу достраивать что-то большое из очень простых кирпичиков.
К тому же практика такова, что это всё приходится делать не прерывая обслуживания.
Все эти элементарные кирпичики - они же не от хорошей жизни.
А от переезда в большую распределённую среду.Тут есть проблема о которой очень мало говорят - как размещать в голове хотя бы приблизительную картину того, что происходит в этой самой среде на самом деле. Из маленьких этих кирпичиков.
Ну, типа "статус","и так всё понятно" и прочее "мы из другого теста".
А по факту поймать одного-единственного человека, который понимал бы как работает конкретное решение хотя бы на слой вниз - практически нереально.> Помню как во времена пиара рельсов был лозунг "что программист стоит дороже
> железа". Они прям форсили эту тему. Оказалось, что опять обманывали.Рельсы - частный случай.
Этим многие занимались.
Да, вообщем-то, тогда и не очень обманывали.
Но вернулись старые добрые времена и это опять не так - и железо снова имеет значение.
>> Согласись, что ты бы не хотел сопровождать проект на python 1.0 или под С++ 98.
> Речь шла о жёстком разделении решения задачи либо только на фреймворках, либо
> только на компонентах.
> О неподдерживаемых языках речи не былоНу вот ты вилять начал. Ты писал какой-то бред про разработку в вакууме. А когда тебя ткнули в конкретные примеры, сразу заднюю дал.
>> Если сейчас много облачных решений, то и код ты будешь деплоить соответствующим
>> образом. Например, собирать docker образы, а не deb или rpm пакеты.
> Правильно. Для каждой задачи свои подходы. О чём и речь.Подходы со временем развиваются. Монструозные фреймворки прменяются реже. К чему вообще ты занимаешься словоблудием? Это же твои слова https://www.opennet.me/openforum/vsluhforumID3/132416.html#103
> Ни современной, ни древней.
Опять заднюю даешь.
>> Не использовать ты можешь, но тогда зачем он тебе нужен? Если ты
>> используешь от джанги только шаблоны, то это явно глупость, когда можно
>> взять отдельно шаблонизатор.
> Верно.
> Если нужны только шаблоны, и дальше тоже будут нужны только шаблоны -
> то и надо брать только шаблоны.
> А если фреймворк толковый, то он и позволит взять только шаблоны, а
> потом, при надобности, без чрезмерных страданий вставить остальное.
> без чрезмерных страданийТы однако оптимист.
>> Все микрофреймворки и либы имеют законченный вид и кода там не так много.
> Как и возможностей.
> Которые, в случае если решаемая задача была описана неверно, придётся наращивать на
> ходу.
> А это не очень здоровое занятие, на ходу достраивать что-то большое из
> очень простых кирпичиков.А какие возможности тебе нужны? Веб приложение - это запрос-ответ по факту. HTTP - это просто одна из форм API.
> К тому же практика такова, что это всё приходится делать не прерывая
> обслуживания.
> Все эти элементарные кирпичики - они же не от хорошей жизни.
> А от переезда в большую распределённую среду.Что за бред ты пишешь? В какую распределенную среду? Какое непрерывное обслуживание? Кто тебе мешает добавить код, не ломая старое АПИ? Это не зависит от фреймоврка, а зависит от человека в первую очередь.
> Тут есть проблема о которой очень мало говорят - как размещать в
> голове хотя бы приблизительную картину того, что происходит в этой самой
> среде на самом деле. Из маленьких этих кирпичиков.
> Ну, типа "статус","и так всё понятно" и прочее "мы из другого теста".
> А по факту поймать одного-единственного человека, который понимал бы как работает конкретное
> решение хотя бы на слой вниз - практически нереально.Как все запущено. Вот что проще: прочитать и разобраться в коде рельсов или какой-нибудь синатры?
>> Помню как во времена пиара рельсов был лозунг "что программист стоит дороже
>> железа". Они прям форсили эту тему. Оказалось, что опять обманывали.
> Рельсы - частный случай.
> Этим многие занимались.
> Да, вообщем-то, тогда и не очень обманывали.Кто этим еще занимался. Ссылки в студию.
> Но вернулись старые добрые времена
Какие еще времена? Слушай, пиши ясно.
Смотря что ты делаешь же. Корпоративный RAD более, чем востребованен, при том, что highload'а там не будет примерно "никогда" и вероятность "упереться" в ограничения фреймворка тоже нифига не 100%, а вот перспектива колхозить лисапет-из-палка-и-веревка здесь-и-сейчас - вот она.
> Смотря что ты делаешь же. Корпоративный RAD более, чем востребованен, при том,
> что highload'а там не будет примерно "никогда" и вероятность "упереться" в
> ограничения фреймворка тоже нифига не 100%, а вот перспектива колхозить лисапет-из-палка-и-веревка
> здесь-и-сейчас - вот она.Эмм. Что им нужно для приложения? Роутинг, БД, шаблоны. Это есть вообще везде! В любом решении. Просто в одном случае ты будешь искать час как добавить 1 строчку, чтобы магия заработала, а в другом просто напишешь рабочий код.
>> Смотря что ты делаешь же. Корпоративный RAD более, чем востребованен, при том,
>> что highload'а там не будет примерно "никогда" и вероятность "упереться" в
>> ограничения фреймворка тоже нифига не 100%, а вот перспектива колхозить лисапет-из-палка-и-веревка
>> здесь-и-сейчас - вот она.
> Эмм. Что им нужно для приложения? Роутинг, БД, шаблоны. Это есть вообще
> везде! В любом решении. Просто в одном случае ты будешь искать
> час как добавить 1 строчку, чтобы магия заработала, а в другом
> просто напишешь рабочий код.... который кому-то надо будет потом поддерживать - читать, разбираться, править. А "магическая строчка" примерно у всех одна (Ну, пока версия фреймворка не бампнулась). А "что им нужно" - достаточно смешной вопрос на самом деле. Я бы сказал "вменяемые дефолты из коробки" и минимизация написания кода.
Есть два автомобиля: один напичкан электроникой по самое небалуй, при этом все друг на друга завязано, второй все по минимуму. Вроде оба едут, но это до первой поломки. И вот в поломке ты поймёшь реальную цену.
> Есть два автомобиля: один напичкан электроникой по самое небалуй, при этом все
> друг на друга завязано, второй все по минимуму. Вроде оба едут,
> но это до первой поломки. И вот в поломке ты поймёшь
> реальную цену.Ну, примерно так, да. Только у одного есть примерно все - от коммерческого саппорта до сети дилерских центров, а второй Вася в гараже делал - вот к нему и иди спрашивать, как колесо меняется. И это еще повезет, если колеса одинаковые, круглые и чётным числом - а то ить, возможны варианты.
>> Есть два автомобиля: один напичкан электроникой по самое небалуй, при этом все
>> друг на друга завязано, второй все по минимуму. Вроде оба едут,
>> но это до первой поломки. И вот в поломке ты поймёшь
>> реальную цену.
> Ну, примерно так, да. Только у одного есть примерно все - от
> коммерческого саппорта до сети дилерских центров, а второй Вася в гараже
> делал - вот к нему и иди спрашивать, как колесо меняется.
> И это еще повезет, если колеса одинаковые, круглые и чётным числом
> - а то ить, возможны варианты.Если ты готов платить саппорту и брать навязываемые услуги сети дилерских центров, то вопросов нет. Только ты должен кушать ответы в духе "быстрее она уже не поедет", "так у нас не принято", "надо добавить больше денег" и т.п.
А вот если хочешь быстрее, то идешь тогда как раз к Васям...
> Если ты готов платить саппорту и брать навязываемые услуги сети дилерских центров,
> то вопросов нет. Только ты должен кушать ответы в духе "быстрее
> она уже не поедет", "так у нас не принято", "надо добавить
> больше денег" и т.п.
> А вот если хочешь быстрее, то идешь тогда как раз к Васям...Ну да. Примерно так. Если тебе в гонках участвовать или там руду тысячами тонн возить - скорее всего нужен будет кастом и\или кто-то, ОЧЕНЬ хорошо умеющий готовить коробку (Кастом лучше-и-дешевле окажется скорее всего), а если тебе "пиццу по городу развозить" в формате "мы вчера заказов уже набрали, давай-программировай!" - "толстый" фреймворк скорее всего удобней. Говорю же - своя ниша у них есть.
Есть ли шанс у Ruby вновь стать достаточно популярным?
Имеет смысл учить сабж?
Какой ЯП лучше учить, чтобы больше всего вакансий и выше всего ЗП?
Ada и Cobol
Очень смешно. Нет.
круче фортрана ничего не придумали
В области параллельного обсчета больших математических моделей, таки Да - нет ничего лучше совремменного Fortran нет. Только С может с ним сравниться здесь, да и то с большой натяжкой. Но на С больше шансов выстрелить себе в ногу, да и не для ученых-предметников он.
Эээээ... Рыночек же - чем больше предложений, тем ниже стоимость)
Нет.
Рыночек - чем больше восстребованность и отдачас от программы или софта, тем больше зарплата. К этому надо еще приложить отличные знания Computer Science и алгоритмов, так как без них никуда. Ну и бизнес-область, в которой работаешь надо хорошо знать. Про отличное знание ЯП или инструмента на котором работаешь я и не говорю.
>Рыночек - чем больше восстребованность и отдачас от программы или софта, тем больше зарплата.Да вот вообще не связано. Стоимость формирует баланс спроса и предложения, а сколько бизнес зарабатывает на конкретной инсталляции "один эсс иееерыпи" - миллион или миллиард на зп программиста этой самой 1с влияет почти никак.
Еще как связано. Возьммем, например Илью Суцкевера - руководителя по научным исследованиям OpenAI и его зарплату в OpenAI и до его приходу в OpenAI или после его ухода из OpenAI. Думаю, что она будет отличаться в разы, а может и в на порядок.
> Еще как связано. Возьммем, например Илью Суцкевера - руководителя по научным исследованиям
> OpenAI и его зарплату в OpenAI и до его приходу в
> OpenAI или после его ухода из OpenAI. Думаю, что она будет
> отличаться в разы, а может и в на порядок.Он руководитель. У руководителей она всегда больше обычных погромистов
Программист это такой же линейный персонал, пролетариат, как и любой другой офисный планктон. То что программисты не избранные можно понять по массовым увольнениям. Начальники отделов, руководители организаций и уж тем более основатели всегда будут получать в разы больше. Программисты научились программировать, но такой простой мысли понять не могут.
Просто люди хотят разного. Руководители меньше пишут код, больше работают с людьми, им нужно сильно больше софтскилов. Ответственности тоже больше, отсюда больше загруженность.А кому интересны технические задачи и вообще они аутитсы.
Суцкевер это топ-менеджер, нашел с кем сравнивать, ты еще с Джопсом сравни. Его достижения в основном организационные, хоть он и позиционирует себя как технаря.
> Еще как связано. Возьммем, например Илью Суцкевера - руководителя по научным исследованиям
> OpenAI и его зарплату в OpenAI и до его приходу в
> OpenAI или после его ухода из OpenAI. Думаю, что она будет
> отличаться в разы, а может и в на порядок.Это вы к тому, что openai - убыточная компания? Вот перейдет товарищ в прибыльную - зарплата и вырастет? :)
> убыточная компанияВ США таких очень много, тот же убер, например.
В Ruby нет ничего хорошего, ради чего стоило бы его трогать. Для большой ЗП нужно прокачивать технический кругозор, уметь проектировать код, сервисы, стурктуры данных и алгоритмы, ЯП здесь просто один из инструментов. Ценный специалист знает несолько ЯП. Больше вакансий и выше ЗП вещи не совместимые: дорогих специалистов всегда нужно меньше линейных и дешёвых. Если искать середину, то скорее всего это будет Java как основной ЯП. Если хочется забраться на самые топовые вакансии с забористыми задачами, то это с++ и реже Java, Go, C# и другие ЯП из этой категории.
> Больше вакансий и выше ЗП вещи не совместимыеТо есть можно начинать учить Delphi с его VCL, WPF, Windows forms, FoxPro?
Если думаешь, что из условного { больше вакансий } ⋂ { выше ЗП } = {0} следует, что ∀ z ∉ { больше вакансий } ⇒ z ∈ { выше ЗП }, то, очевидно, думаешь неверно. Т.е. { меньше вакансий } ⋂ { меньше ЗП } != {0}. Иначе не совсем понятно что хочешь.
Когда-то вокруг Ruby был такой же хайп, как сейчас вокруг Rust. А сейчас Ruby сохранился только на легаси и в своей небольшой нише.
Делайте выводы.
Ruby не дал ничего нового и полезного и даже напротив - вобрал из других языков много неудобного хлама. Rust же даёт новые уникальные фичи, потому rust находится в более выгодных условиях. И его уже потихоньку в ядро загоняют. Т.е. вполне может взлететь.
> И его уже потихоньку в ядро загоняют. Т.е. вполне может взлететь.Если ты в шкаф новые вещи запихиваешь так чтобы дверца еле закрылась, то он от этого не взлетит.
Руст на хайпе только потому, что его пиарят корпорации и потому, что он продвигает античеловеческую лгбт\сжв повесточку, выгодную глобалистам (сатанистам).
> его пиарят корпорации и потому, что он продвигает античеловеческую лгбт\сжв повесточкуПитон же именно так и вытащили. И ничего, все довольны
Не, питон чисто народный язык. Арасаки бы не одобрили бардака с пакетированием и перехода с 2 на 3.
Если бы его Гугл, а потом и Микрософт не тащили, то никуда бы он не взлетел. Он и сейчас при парном сравнении технологий, нигде лучшим/удобным/производительным/надёжным не является.
Корпорации это не ССЗБ чтобы назло тебе пользоваться для себя неудобными инструментами. Так только совки поступают. Бизнесу нужно повышать эффективность труда, потому постоянно в поисках лучшего. Не все, разумеется, одинаково хорошо занимаются оптимизациями. Если что-то взлетает надолго благодаря корпорациям, то это только из-за изначально удачного решения и корпорации всего лишь выступают успорителем популяризации.Питон, кстати, к тому моменту уже обошёл всех конкурентов и был взлетевшим. На начальных этапах подскачил благодаря Zope (~2000), далее приглянулся учёным и инженерам в виде scipy (2001) и потом numpy. Его тащили мелкая вебня, системщики и админы, потом уже учёные, DS-ы и ML-щики.
> Корпорации это не ССЗБ чтобы назло тебе пользоваться для себя неудобными инструментами. Так только совки поступают. Бизнесу нужно повышать эффективность труда, потому постоянно в поисках лучшего.Ага–ага. Корпорацыи это такие сверхсущества никогда не ошыбающиеся а барыги святые люди.
Специально для особенно умных написал 'не все'. Слышал когда-нибудь о естественном отборе? В условиях конкуренции в долгосрочной перспективе выживают только эффективные.
Нынешний пайтон далеко отошел от изначальной идеи, которую закладывал Гвидо ван Россум.
Питон взлетел примерно по трём причинам: консистентная фичастая стандартная либа из коробки (против php, perl, js), уход от неявных переменных (perl, ruby) в сторну явных конструкций и типы (против perl, js). Взлетел по объективным причинам и потому многие им довольны по сравнению с альтернативамм.Взлетал в дистрибутивах как замена perl и в наколеночной вебне, в 'корпоративных' задачах взлетал плохо. Ему долго пытались прикручивать всякие корутины и JIT-ы, но всё было бесполезно. Собственно питон и сейчас в основном остаётся как инфраструктурный скриптовый ЯП для разработки вспомогательных приложений и обвязок.
> Взлетал в дистрибутивах как замена perlНо Perl почему-то до сих пор идёт к большинству пакетов как неотъемлемая зависимость. Подучить бы вам матчасть, товарисч.
Аноним, ну нужно же иногда включать мозг. Во-первых, к большинству пакетов не идёт как прямая зависимость:{ find /usr/portage/ -name "*.ebuild" | wc -l) } -> 30121
{ equery d -a perl | grep -Ev '^(virtual/perl|dev-perl/)' | wc -l } -> 1603
{ equery d -a python | grep -Ev '^(dev-python/)' | wc -l } -> 2939Грубая оценка по зависимостям по пакет-версия на примере Gentoo репозитория. Итого, python и perl суммарно нужны менее 15-20 % пакетам. И питон всё равно уже вышел вперёд.
Во-вторых, 'в дистрибутивах' это означает инструментарий для дистрибутивов, а не пакеты. Пакеты разрабатываются не разработчиками дистрибутивов. Здесь речь прежде всего о штуках вроде yum и portage. Новые инструменты сейчас пишут на perl разве что потерявшиеся во времени бедолаги. Так-то perl ещё долдго будет отсвечивать потому что некому переписывать всё легаси и практичнгее просто его не трогать и подохдать когда сгинет само.
> продвигает античеловеческую лгбт\сжв повесточку, выгодную глобалистам (сатанистам).Зачем она им? Это же приведет к уменьшению населения.
>Ruby не дал ничего нового и полезногоСтиль кодирования у него на хорошем уровне. Кое-кому (мне в том числе) дали крепкого пинка под зад, показали, как писать лучше.
А с технической точки зрения — выглядит, как будто ничего нового...
В ruby унесли много плохого из perl, например, неявные переменные. В начальных версиях у функций не было именнованных аргументов, нужно было доставать как в perl через shift. Также в ЯП встречаются логические косяки прямо в базовой функциональности. Склеивание строк выглядит как [ 'a', 'b' ].join(''), а должно быть ''.join([ 'a', 'b' ]). Оформление блоков по типу begin...end в 21-ом веке у ЯП общего назначения тоже дикость. Ruby проигал как раз из-за плохого 'стиля кодирования' и из-за менее фичастой стандартной библиотеки.
Ох уж эти эксперты. Они и в JS и в Perl и в Ruby шарят... 👏🤣
> Склеивание строк выглядит как [ 'a', 'b' ].join(''), а должно быть ''.join([ 'a', 'b' ])Почему?
p.s. в расте также
Потому что в ЯП вроде Python и Ruby списки не типизированы, т.е. самого общего назначения. А метод join() строго заточен под строки. Во-первых, зачем код работы с форматированием вклеен в контейнер о бщего назначения? Он должен быть в соответствующей библиотеке форматирования. Во-вторых, что делать если нужно сделать join для нестандартных строк или других объектов? Конкретно в ruby метод join() особо омерзителен...['1', '2', '3'].join(' ') -> "1 2 3" # норм
[1, 2, 3].join(5) -> ошибка # хочет String вместо 5
[1, '2', '3'].join(' ') -> "1 2 3" # какого хрена?
[1, [ '2', '3' ]].join(' ') -> "1 2 3" # это уже просто пцТакже сюда забралась мерзость из перла в виде скрытых неявных переменных
$,='~'; ['1', '2', '3'].join(' ') -> "1~ ~2~ ~3"
В 'правильной' библиотеки мухи и котлеты должны быть отдельно, например, на некотором условном языке
Join_Fn(array, sep) # Отдельная функция
Join(sep)(array) # Функтор Join(...) с явными настройками далее форматирует
join = Join(sep); join(array) # .. массив через оператор вызова ()
Str_Ops(sep).Join(array) # Аналогично, только уже модуль Str_Ops с набором функийЗдесь под array могут прятаться массивы, итераторы, генераторы и слайсы, а не только списки. Т.е. такой подход ещё и обладает большей универсальностью .. потому что мухи отдельно и котлеты отдельно. Теперь посмотрим как сделано в Python
' '.join(['1', '2', '3']) -> '1 2 3' # норм
' '.join([1, '2', '3']) -> ошибка типа # нормЗдесь используется вариация метода Str_Ops(sep).Join(array) выше (тут ' ' = str(' ')). И в данном случае это только склейка строк, а не форматирование. И должно быть только так. Также здесь в качестве аргумента array может быть что угодно похожее на итератор.
В rust метод join() это прокся к трейту std::slice::Join, т.е. фактически сахар для вызова форматирования по типу отдельной функции Join_Fn(array, sep). И в rust массивы типизированные из-за чего отсутствует неявное форматирование и метод можно расширять для других типов. Но с логической и практичкской точек зрения такой подход всё равно плохой. С практической, например, сложнее кастомизировать join т.к. придётся придумывать как прокидывать дополнительные настройки через скахар в конечную функцию. Потому в rust есть другие методы сделать join
Итого, Ruby с точки зрения логичности, прозрачности и безопасности кода просто хлам.
> Здесь под array могут прятаться массивы, итераторы, генераторы и слайсы, а не только списки.Ну по идее можно сделать этот метод у каждого из этих сущностей (ну или у базовой, от которой они наследуют)?
Тут просто это очень похоже на вопрос почему в питоне len() - это функция, а не метод, хотя у коллекций есть метод __len__(), который будет вызван len(). Ответ, насколько я понял, что Гвидо считает, что так математичнее https://stackoverflow.com/a/237312
> Оформление блоков по типу begin...end в 21-ом веке у ЯП общего назначения тоже дикость.А скобочки типа лучше? И почему именно в 21 веке? От тебя пахнет смузипрограммированнием и JavaScript.
>> Оформление блоков по типу begin...end в 21-ом веке у ЯП общего назначения тоже дикость.
> А скобочки типа лучше?Кхм. Отступы, конечно.
к 21 веку инженеры успели наплодить много разных ЯП с разными подходами и синтаксисами, и успели вдоволь с ними насношаться. Cейчас уже хорошо видно какие подходы удачные и какие нет. Неудобство BEGIN...END было уже понятно давно, это один из самых древних методов структурирования кода.Отступы тоже плохи. Нет возможности писать однострочники, из-за этого в ЯП вроде питона приходится придумывать отдельные конструкции для однострочников, которых всё равно мало. Также есть вечная проблема SPACE vs TABS и чему равен TAB. В коде не всегда видно что стоит - SPACE или TAB, из-за чего текст может оказаться невалидным и непонятно где для глаза.
И таки да, из самых удобных остаются только односимвольные парные скобки типа () <> {}, какие плюсы: нужно меньше набирать текста, оформление блоков не отвлекает на себя много внимания в текстах программ, симметричные из-за чего графически понятно где находится содержимое.
> к 21 веку инженеры успели наплодить много разных ЯП с разными подходами
> и синтаксисами, и успели вдоволь с ними насношаться. Cейчас уже хорошо
> видно какие подходы удачные и какие нет. Неудобство BEGIN...END было уже
> понятно давно, это один из самых древних методов структурирования кода.Ну просто end для конца блока норма читается.
> Отступы тоже плохи. Нет возможности писать однострочники, из-за этого в ЯП вроде
> питона приходится придумывать отдельные конструкции для однострочников, которых всё равно
> мало. Также есть вечная проблема SPACE vs TABS и чему равен
> TAB. В коде не всегда видно что стоит - SPACE или
> TAB, из-за чего текст может оказаться невалидным и непонятно где для
> глаза.Решается форматерами кода. Сейчас все новые языки поставляются с форматерами.
> И таки да, из самых удобных остаются только односимвольные парные скобки типа
> () <> {}, какие плюсы: нужно меньше набирать текста, оформление блоков
> не отвлекает на себя много внимания в текстах программ, симметричные из-за
> чего графически понятно где находится содержимое.Отступы, все равно будут для читаемости. К тому же опять могут возникуть вопросы где ставить { скобку: есть K&R, всегда на той же строке и GNU стили.
Function FFOff()
For i = 0 To 10
If i = 2 Then
…
End If
Next
End Function
Хороший был язык и фреймворк, самые теплые и приятные воспоминания. Слез где-то в 2017 и перешел на JavaScript, который ненавижу.
Сам по себе JS норм язык, он чем-то мне Lua напомнил - такой же везде впихиваемый и минималистичный по синтаксису. Но он должен быть, как и Lua, держаться в узкой нише. Пришёл nodejs и сказал "Теперь ВСЁ пишем на JS!".
JS слишком сложный. Все эти ивент лупы, промисы, коллбэки, прототипы. Плюс столько синтаксического сахара, что можно заработать диабет. Но без JS сегодня в вэбе - никуда.
От JS тут только прототипы, синтаксического сахара в JS нет. Остальное это паттерны проектирования и именно такие есть практически по всех ЯП куда не захотели засовывать корутины, или лёгковестные процессы. Т.е. практичесеки в большинстве ЯП. Сложность JS заключается совершенно в другом: в логике неявного приведения типов т.к. в JS нет типов вообще. И мб прототипы недостаточно посахарены
Из твоего комментария могу сказать одно - с JS ты не знаком от слова совсем.
> Из твоего комментария могу сказать одно - с JS ты не знаком
> от слова совсем.Вообще-то он правильно говорит. Евент луп - это не часть языка, промисы - это просто абстракция от будущего значения (до появления промисов в стандарте они были реализованы через библиотеки), колбэк - это просто анонимная функция.
Ну, давай покажи где есть JavaScript без event loop, без функцый обратного вызова (которые могут быть не только анонимными), без асинхронности почти везде, без ООП через протипы. Почти всё из этого я впервые увидел в JavaScript.
> Ну, давай покажи где есть JavaScript без event loop,Ты путаешь. Я тебе сказал, что event loop не является частью стандарта ECMAScript. В реализациях он есть, потому что без него не реализовать setTimeout или промисы.
Вот, например, реализация, где циклы событий можно создавать вручную из js https://github.com/just-js/just
> без функцый обратного вызова (которые могут быть не только анонимными)
Вот тут я не понимаю о чем речь. Можно подробнее?
> без асинхронности почти везде,
Ну из известного мне - https://github.com/just-js/just
> без ООП через протипы.
Классы в js - это надстройка над прототипами. Никто работу с прототипами не отрывал. Ты можешь создать класс с помощью class, и потом проверить у него свойство __proto__
> Почти всё из этого я впервые увидел в JavaScript.
Это лишь говорит, о том, что нужно чаще вокруг смотреть. Прототипы, напрмер, есть в lua. Цикл событий (правда создаваемый программно в python), async/await много где есть, генераторы есть в python.
> Вот тут я не понимаю о чем речь. Можно подробнее?Это я передаче функцый в другие функцыи и вложение всего и вся в кучу функцый которые потом вызываются.
> Это лишь говорит, о том, что нужно чаще вокруг смотреть.
В бурситете было понемногу Delphi, Java, C++, PHP, C#. Всё поверхностно, но когда я пытался зарабатывать денюжку сайтописательством и учил JavaScript, то тот же C# и тамошние делегаты вспоминал с теплотой потому что это именно в "прекрасном" JavaScript встретил наслоения вложеных функцый передающих друг друг данные, this и постоянной меняющийся контекст исполнения, фунцые в роли класов, игрища с прототипом, имитацыя модулей и ещё какая–то ебани…ка. А всё это не есть частью стандарта ECMAScript и вот есть такие и такие библиотечки сферические кони в вакууме и попытки сделать из коровы ездовую кобылу надев ей седло. JavaScript это клеймо.
>потому что это именно в "прекрасном" JavaScript встретил наслоения вложеных функцый передающих друг друг данныеПочитай sicp
Ты про чистый JS?
Нормальные люди ни на какой Node.js и JavaScript не ведутся.
Действительно, ведь нормальные сидят на msdos! Вот в сберкассе тётеньку видел с dos программой!
> Действительно, ведь нормальные сидят на msdos! Вот в сберкассе тётеньку видел с
> dos программой!Что плохого в программах под DOS?