Comments 84
Все читают, но не комментят.
Мне страшно.
Чувствовал тоже самое, когда опубликовывал первый свой первый пост.
(добавлено) То же самое чувствуется у обычных сисадминов в бюджетных организациях, когда они видят что их заслуги приписывают вышестоящим организациям.
Что касается сравнений, то тут есть конкретные метрики и наблюдения. Сразу после выпуска этой статьи мы разговаривали с одной весьма умной и начитанной девушкой, и она взахлеб поведала о фактах жизни Стива Джобса, недавно вычитанных из понятно какой книжки. С другой стороны, про Ритчи она практически ничего не знала. Знала про Си и Си++, а про Ритчи — нет. Как так?
Попробуй у себя провести этот эксперимент с разработчиками, которые вообще не писали на Си и Си++, например, на новичках-фронтендерах. Какие будут результаты? Как их можно интерпретировать?
распечатать стандарт Си-99 на принтере и читать на бумагеПомню, в начале 90-х отец притащил с работы польский клон 9-игольчатого Роботрона, купил переплетный станок с резаком и прессом, и стал делать книги по библиотекам С++ и тд тп. Получались очень увесистые фолианты, весом и форматом как тома БСЭ.
Язык Си на самом-то деле наколенная поделка по факту, почитайте историю его создания и скачайте исходники ранних версий его компилятора. И, как мне кажется, очень многие широко известные уязвимости, о которых мы много раз слышали (Heartbleed, например), проистекают именно из недостатков этого языка. Я говорю про то, как реализованы там массивы (границы не проверяются), приведение типов, строки и строковые функции, работа с памятью (принудительно вручную), сколько там в стандарте тонких мест, позволяющих плодить трудно отлавливаемые и исправляемые баги, и т.п., и если вам кажется, что так, как там, делать нормально и допустимо (особенно в наше время), то в этом и заключаются основные негативные последствия повсеместного распространения этого языка. Почитайте CVE и статьи авторов PVS Studio, и в полной мере насладитесь масштабом катастрофы :)
А вот Apple часто была ледоколом революции, и достаточно сильно повлияла на индустрию, вспомним хотя бы WebKit с clang/llvm. Но вы почему-то помните только iPhone (который сам по себе и весьма неплох, да).
большинство названных вами вещей не считались недостатками
А можно пруф, что отсутствие проверки границ массивов, возможность использования неинициализированных указателей и неопределённое поведение в C когда-то не считались недостатками языка программирования? В конце-концов проверку границ можно было бы включать/отключать флагом компилятора, а использование неинициализированных переменных и указателей вообще проверяется на этапе компиляции. К тому же я что-то не встречал неопределённого поведения в описании, к примеру, FORTRAN — хотя он такой же быстрый (а то и быстрее), как C. А цель эмуляции строк и массивов в C через указатели для высокоуровневого языка вообще за гранью понимания.
Может вы дадите пруф на то, что авторы Си с самого начала его создания считали, что отстуствие проверок это недостаток, но он компенсируется эффективностью, например?
Однако присваивание ему заструги в появлении Photoshop/FLStudio/MacOS полный бред, все эти три штуки появились благодаря языку Pascal/Delphi (а если серьезно, то язык был использован, тот, что был более удобен для конкретной задачи, не один, так другой).
Уж не смог удержаться от этого комментария. Это всё-таки не паблик ВК, где и появилась эта картинка, скорее всего, а технический ресурс.
Серьёзно? С такими ляпами? Хипстота.
Картинку приложу сюда на всякий случай, а то ещё потрут :)
Я часто пересматриваю вот эту презентацию.
«This is a day I’ve been looking forward to for two-and-a-half years.
Every once in a while, a revolutionary product comes along that changes everything. And Apple has been – well, first of all, one’s very fortunate if you get to work on just one of these in your career.
Apple’s been very fortunate. It’s been able to introduce a few of these into the world.»
И дальше по тексту. Очень рекомендую к просмотру.
Сам Ритчи был одним из авторов Юникса, вовсе не очевидно, что юникс бы написали вообще. Вы это хотели услышать?
Свяжите дважды два: я не собираюсь отвечать на ваши наезды. В приличном обществе не общаются наездами, а с террористами не ведут переговоров. Токсичность — это плохо. Это последний ваш комментарий, на который я отвечаю.
И что? Ну взлетела бы другая ОС, Торвальдс написал бы её клона на Simula. А Photoshop на винде работал бы точно так же.
По существу моего комментария вы так и не ответили, зато написали немного бессвязного текста. Извините, но такое ощущение, что вы отвечаете в комментариях под воздействием веществ.
Сегодня не все могут смотреть в завтрашний день…
Классика жи.
До C был создан FORTRAN с его скоростью и шикарными встроенными возможностями по обработке массивов данных, которые в C и его наследниках до сих пор так и не появились.
До C был создан PL/I и его семейство языков с безопасностью в плане ошибок адресации и переполнения буфера, на котором пишут операционные системы и софт для мейнфреймов IBM.
До C был создан Pascal, на котором, как уже упоминали выше, были написаны первые версии того же Photoshop и на котором писался софт для Mac OS…
На их фоне распространённость C, с его стандартом с кучей undefined behaviours, бедными возможностями по работе с массивами и типами данных, но богатыми возможностями по отстрелу ног и написанию программ из закорючек, выглядит парадоксом.
Про FORTRAN vs C. Если ты запускаешь свой код на железе напрямую, без операционной системы в качестве прослойки (или если это какая-то встроенная система), то нужно управлять железом напрямую. А для этого нужен доступ к настоящим адресам памяти. Си предоставляет эту возможность посредством поинтеров. Насколько понимаю, в FORTRAN существует концепция поинтеров, но они не эквивалентны поинтерам в Си. Фортрановские поинтеры нельзя использовать для прямого управления железом, что могло быть огромной проблемой в эпоху, когда на макбуки еще не ставили 64 гигабайта оперативной памяти, которые позволяют из любого языка вызывать любой, не включая мозг. Фортран наверняка использовали вместе с Си и даже ассемблером. И тут сразу возникает вопрос — нафига козе баян, зачем использовать три языка, если можно обойтись одним?
И тут сразу возникает вопрос — нафига козе баян, зачем использовать три языка, если можно обойтись одним?
Зачем мне три разных инструмента, если я всё-равно гвозди микроскопом забиваю?
Fortran разрабатывался учёными для учёных, и он приобрел наибольшую популярность именно в сфере научных расчетов. До сих пор существует огромное количество научного ПО, написанного на Fortran, так же как и разработчики, которые продолжают на нем писать.
C создавался программистами для программистов, с весьма утилитарной целью — обеспечить переносимость Unix. Недаром, C называют ассемблером виртуальной машины Unix.
Отсюда вытекают особенности этих языков, так же как и области применения. Это разные инструменты.
Это очень хороший вопрос, и тут я на вашей стороне :-) Сейчас я разобраюсь с GraalVM и пытаюсь популяризовать её в широких народных массах. Одна из основных частей технологии — это так называемый Polyglot Runtime, позволяющий быстро и без оверхеда пистать приложение сразу на куче языков, выбирая нужный под задачу.
Но в попытке объяснить это людям встречаюсь с очень большими затруднениями. На практике донести эту аргументацию бизнесовым чувакам очень, очень сложно.
У разных областей применения разный процент распространенности. Например, опердени для коммерсов пишет половина мира, а спутники запускают три с половиной счастливчика. Очевидно же, что платформа общего назначения (что операционная система, что платформа для программирования), созданная для широких народных масс, должна ориентироваться на самые частые кейсы использования.
Использование сразу нескольких языков добавляет несколько дополнительных уровней сложности. Например, массовое обучение специалистов по этим языкам. Или удобство тулинга. Или скорость интеропа.
Попробуйте объяснить бизнесмену, почему он должен обучать свои десять тысяч разработчиков не одному языку (Java или JS), а сразу двум (Java+JS). В конечном итоге все упирается во время, деньги, скорость вывода продуктов на рынок, и так далее. Обучение и зарплаты сотрудников — это очень большие расходы. Коммуникация между разработчиками — это очень большие расходы (есть формальное объяснение в "мифическом человеко-месяце"), а несколько языков (и несколько связанных с ними программных платформ) увеличивают сложность коммуникации.
Да, писать задачу на языке, удобном для этой задачи — это очень приятно для программиста. Далеко не всегда очевидно, что это действительно будет экономить деньги. Например, сейчас многие пишут веб-фронтенды на Java хотя камон, Java вообще никак для браузера в его текущем виде не подходит. Многие пишут бэкенды на JS, хотя JS для хайлоадной системы это кошмар и ад. Но пробиться сквозь простую логику, что раз у нас уже есть 2 тысячи JS разработчиков, нафига нам покупать еще тысячу джавистов или упаси бог C++-ников, если можно просто перекинуть JS разрабов на бэкенд — очень сложно эту логику пепреплюнуть.
Если у вас есть хороший ответ на этот вопрос — пожалуйста, расскажите. Скопипащу, сохраню, запомню наизусть, буду использовать в повседневной деятельности.
Джава не подходит для браузеров? Оно работает? Работает. Специалисты есть? Есть. Бизнес потребность закрыл? Закрыл. Скорость? Мы тут не спутники запускаем.
JS для хайлоада? Его у нас нет. Позаботиться о будущем? Ну так давайте сразу представительства ООО «Рога и Копыта» по всему миру откроем, документацию ко всему напишем и лолакизуем всё хотя бы языков на 50, только платить за это будете из зарплаты.
Если вдруг компания вырастет до неподъёмного технического долга — то это будет полной ошибкой и некомпетентностью управленцев в области управления риска.
А на Ваш вопрос ответ, поэтому, может звучать так:
Выбор нормального инструментария, покрытие тестами, хорошая инфраструктура — это не совсем про прибыль и расходы. Это про амортизацию и накапливающийся износ. Как завод не хочет остаться внезапно без станков, так и компании должно быть страшно остаться с умершим сервером и невозможностью масштабирования. Если бизнес хочет оказаться в такой ситуации или планирует прожить меньше, чем износ достигнет критической отметки — пожалуйста.
(Всплыла забавная аналогия про российский аджайл и проектную работы: это как купить станок, поубивать его, и продать «новый, почти не использованный, не битый» дальше)
Попробуйте объяснить бизнесмену, почему он должен обучать свои десять тысяч разработчиков не одному языку (Java или JS), а сразу двум (Java+JS)
Дубовый пример — «Ты на ночные гонки поедешь на Ferrari, а картошку с дачи повезешь на Dodge Ram.» Так, мне кажется, любой поймет.
JS для хайлоадной системы это кошмар и ад
Ваши бы слова да богу в уши :)
Поинтеры не используют для управления железом, они для адресации. Мб вы перепутали с портами?
Указатели в фортране — тот же адрес. Проблема в массивах, они там с дескриптором.
Так же есть проблема с преобразованием типов (нельзя перекинуть float в Int напрямую, подправить пару битов и вернуть в float).
Тут можно почитать про отличия фортрана от С:
openmp.ru/2017/04/05/%d0%be%d1%81%d0%be%d0%b1%d0%b5%d0%bd%d0%bd%d0%be%d1%81%d1%82%d0%b8-%d1%8f%d0%b7%d1%8b%d0%ba%d0%b0-%d1%84%d0%be%d1%80%d1%82%d1%80%d0%b0%d0%bd-%d0%b2%d0%b7%d0%b3%d0%bb%d1%8f%d0%b4-%d1%81%d0%be-%d1%81
Кстати от использования ассемблера в ядре UNIX никуда не ушёл. В принципе прямой доступ к памяти можно встроить в любой язык путём добавления соответствующей функции.
Все другие ОС были написаны полностью на асме. Железо менялось часто, а переписывать всю ОС на новый ассемблер было делом долгим и дорогим.
А ещё строки, Строки, СТРОКИ. Уж сколько в мире уязвимостей(я думаю больше половины), тупо из-за отсутствия строк в СИ.
Я люблю СИ за то, что он является кросплатфоременным ассемблером, и работает везде, но если бы на его месте был Паскаль, мир бы был чуточку лучше. Но к сожалению создатели UNIX выбрали, и сделали популярным именно СИ.
И тут сразу возникает вопрос — нафига козе баян, зачем использовать три языка, если можно обойтись одним?
Вот вы — любите использовать Java, если вообще программируете практически, а не только конференции устраиваете, так зачем вы его используете? Там же внутри все на C++! Обойдитесь одним языком, и используйте C++.
Ой, C++ использует C, тогда и плюсы вам не подходят. Пишите на C. И никаких вам ненужных классов и строк.
Я не только люблю использовать Java, но и постоянно пишу про неё на Хабр :-) В общем-то, это основная и практически единственная тема, про которую я пишу на Хабр.
Например, сейчас я дико увлечен проектом по переписыванию рантайма Java с C++ на Java. Сейчас про это речь идет в проекте GraalVM, но целиком это называется Project Metropolis и поддерживается основными архитекторами Java-рантайма. Так что да, безусловно, я бы хотел увидеть написанным на джаве вообще всё, и работаю в этом направлении.
Но мы не одни такие. Например, еще есть JavaScript, и сейчас бэкенды серверных приложений стало нормально писать на JS, и переводить на JS софт, который ранее был написан на Java и С/C++.
Это совершенно нормально — не связываться с излишней сложностью, когда с ней можно не связыватья. Введение дополнительного языка — это сложность. Использование Си позволяет избавиться от неё. В чем проблема?
Так что да, безусловно, я бы хотел увидеть написанным на джаве вообще всё, и работаю в этом направлении.
…
Это совершенно нормально — не связываться с излишней сложностью, когда с ней можно не связыватья. Введение дополнительного языка — это сложность. Использование Си позволяет избавиться от неё. В чем проблема?
Забавно.
Еще не так давно мир и двигался в этом направлении — некая централизация во всем:
- Появились IDE вместо отдельных тестового редактора, компилятора и линковщика, и нам рассказывали, как это круто — делать все в одной IDE, причем в основном мышкой.
- Один язык. Если очень упрощенно, конкурировали за эту роль C++ и Delphi/Object Pascal.
- Затем — единая платформа/VM. Здесь будет уже ближе к действительности, если сказать, что конкурентами здесь были Java и .NET.
- С другого ракурса — единые интегрированые системы управления жизненным циклом приложений. Вначале Borland ALM, потом Microsoft ALM (и TFS — лишь часть ее).
И вдруг что-то случилось.
Началось это примерно с бума планшетов (кстати, где они сейчас), и мифического закаты "эры ПК/буков" (вроде ужались до своей естественной ниши, а так живее всех живых).
Затем перекинулось почему-то на средства разработки.
Вновь стали отдельные компиляторы, редакторы, из IDE вынесена отдельно в невсегда работоспособные утилиты куча тулинга (а ведь до сих вроде нет такого же удобного мерджа, если не ошибаюсь, с семантическим анализом (?), как это было в TFS), и все это склеивалось на честном слове.
Снова разные языки (а уж какой вдораздел произошел между беком и фронтом, не описать).
И вновь разработка стала, как в 80-х — начале 90-х. Ну, почти.
И вдруг маятник качнулся в обратную сторону.
Тут и Web Assembly (можем писать на фронте на бек языках), а уж какой вклад в (ре)интеграцию внесли IDEA и Kotlin (разом под JVM, JS, Native)…
Ну и понятно, Node с JS/TS на бек-енде.
Т.е., все вновь стало стремиться к интеграции, и вновь появились конкурирующие экосистемы, предлагающие себя в качестве единой платформы.
Понятно, что это такой маятник развития.
Удивляет же реакция сообщества, как каждый раз подхватывается вот эта волна хайпа и забывается хорошее, что было сделано до, хотя можно было использовать много из старых наработок в новом качестве.
Пошел мятник назад — и история повторятся. И каждый раз забывается, что вот еще несколько лет назад на волне хайпа ратовали за противоположное.
Это совершенно нормально — не связываться с излишней сложностью, когда с ней можно не связыватья. Введение дополнительного языка — это сложность. Использование Си позволяет избавиться от неё. В чем проблема?
Мне кажется, или тут взаимоисключающие утверждения?
Каламбур: возмущаются, что Стив Джобс распиаренная рекламная личность, за которым не видно человека создавшего Си, но Си тоже распиаренный ЯП за которым не видно более безопасных и удобных в использовании для прикладного программирования языков
программ из закорючекэмм обычная программа, просто все названия переменных и функция состоят из одного символа и записаны в одну строку. Ну вот ни разу не программа на Perl.
Не совсем по теме: поправьте меня, если я неправ, но "первая версия Photoshop" для Windows — это не что иное, как Aldus PhotoStyler (по-моему, PageMaker прошёл примерно тот же путь). Просто довелось немало поработать как раз в PhotoStyler, и долго искал "более свежую версию — для Windows 95"… а потом понял, что компьютерная графика — не совсем моё.
И даже когда в 2014-м был громко представлен Swift, в бытовых обсуждениях этой новости не фигурировало имя Криса Латтнера, а было лишь размытое «Apple»
По ту сторону плотины лежало большое, чистое, прохладное озеро.
Дойдя до центра плотины, мистер Томсон внезапно остановился, широко расставив ноги по обе стороны белой черты.
— Теперь, — сказал он, — я стою одной ногой в Аризоне, а другой — в Неваде Боулдер-дам, расположенный на стыке четырех штатов — Аризоны, Невады, Юты и Калифорнии, — дает пустыне не только электричество, но и воду. Кроме электростанции, здесь будет еще центр оросительной системы Всеамериканского канала.
— Скажите, — спросили мы Томсона, — кто автор проекта Боулдер-дам?
К нашему удивлению, он не ответил на этот вопрос. Он мог лишь сообщить названия акционерных обществ, которые по заказу правительства выполняли эту работу.
— Вероятно, — сказал Томсон, улыбаясь, — если какого-нибудь строителя спросить, кто здесь монтирует турбины, он не сможет назвать мое имя. Он скажет просто, что монтаж ведет «Дженерал Электрик Компани». Инженеры у нас, в Америке, не пользуются известностью. У нас известны только фирмы.
— Позвольте, мистер Томсон, но это большая несправедливость. Мы знаем, кто построил собор Петра в Риме, хотя он был построен несколько веков тому назад. Авторы Боулдер-дам, где соединены замечательная техника и удивительное строительное искусство, имеют право на известность.
— Нет, — сказал мистер Томсон, — я не вижу в этом несправедливости.
Лично я, например, не ищу известности. Я вполне удовлетворен тем, что мою фамилию знают двести специалистов в мире. Кроме того, состояние современной техники таково, что действительно не всегда можно определить автора того или иного технического произведения. Эпоха Эдисона кончилась. Пора отдельных великих изобретений прошла. Сейчас есть общий технический прогресс. Кто строит Боулдер-дам? Шесть известных фирм. И это все.
— Но вот в СССР есть инженеры и рабочие, которые пользуются большой популярностью. Газеты о них пишут, журналы печатают их портреты.
— Вы просто увлечены строительством. Оно играет у вас сейчас слишком большую роль. А потом вы позабудете о нем и перестанете прославлять инженеров и рабочих.
Мы долго еще говорили о славе, вернее — о праве на славу. Нам кажется, мы не убедили друг друга ни в чем. Позиция Томсона была нам ясна: капитализм отказал ему в славе, — вернее, присвоил его славу, и этот гордый человек не желает о ней даже слышать. Он отдает своим хозяевам знания и получает за это жалованье. Ему кажется, что они квиты.
Стоя на вершине одного из самых прекрасных сооружений нашего века, о котором доподлинно известно лишь то, что оно неизвестно кем построено, мы говорили о славе в Соединенных Штатах.
Слава в этой стране начинается вместе с паблисити. Паблисити же делают человеку только тогда, когда это кому-то выгодно.
Кто пользуется в Америке действительно большой, всенародной славой?
Люди, которые делают деньги, или люди, при помощи которых делает деньги кто-то другой. Исключений из этого правила нет. Деньги! Всенародную славу имеет чемпион бокса или чемпион футбола, потому что матч с их участием собирает миллион долларов. Славу имеет кинозвезда, потому что ее слава нужна предпринимателю. Он может лишить ее этой всенародной славы в ту минуту, когда этого ему захочется. Славу имеют бандиты, потому что это выгодно газетам и потому что с именами бандитов связаны цифры с большим количеством нулей.
А кому может понадобиться делать славу Томсону или Джексону, Вильсону или Адамсу, если эти люди всего только строят какие-то машины, электростанции, мосты и оросительные системы! Их хозяевам даже невыгодно делать им славу. Знаменитому человеку придется платить больше жалованья.
— Нет, серьезно, сэры, — сказал нам мистер Адамс, — неужели вы думаете, что Форд знаменит в Америке потому, что он создал дешевый автомобиль? О, но!
Было бы глупо так думать! Просто по всей стране бегают автомобили с его фамилией на радиаторе. В вашей стране знаменит совсем другой Форд. У вас знаменит Форд-механик, у нас — Форд-удачливый купец.
Нет, пожалуй, милейший мистер Томсон прав, отмахиваясь от американской славы. Слава в Америке — это товар. И как всякий товар в Америке, она приносит прибыль не тому, кто ее произвел, а тому, кто ею торгует.
Там минимум человек 10 больше знают больше про историю и развитие языка. Но рассказывать вы зовёте лицо с лучшей историе продаж. Неплохое продолжение истории про Ритчи.
— То есть сначала вы это вдвоём делали? В четыре руки, в две головы?
— Ну, это слишком нескромно. Участвовали другие люди, конечно. Всякие идеи обрабатывались и апробировались в коридоре. Очень много ребят (тот же Дима Жемеров, тот же Илья Рыженков, Володя Решетников, который сейчас в Microsoft), высказывали массу идей, комментировали. Или Рома Елизаров — он пришёл к нам, потому что я позвал: «Ром, я буду в JetBrains рассказывать, как мы будем делать язык программирования, приходи».
— Какой это был год?
— 2011-й. Может, 2012-й. Рома пришёл, послушал, сказал: «Чуваки, всё классно… Но Nullability». И мы такие: «Ну это трудно: дженерики, interoperability с Java»… Он: «Nullability, чуваки». И появилось Nullability.
— Это очень интересно, потому что Рома Елизаров зимой тоже был в «Без слайдов», и тогда он ещё был сотрудником компании Devexperts, а теперь он сотрудник компании JetBrains и внезапно он делает Kotlin Native, о котором мы ещё поговорим. То есть он ещё тогда, на том этапе, был человеком, который существенно повлиял на язык?
— Да, именно Рома предложил конкретно Nullability. И это сейчас, наверное, одна из самых главных фич в Котлине — это понятная вещь, удобно объяснять пользователю. Но Рома дал идею, а нам пришлось действительно сильно пыхтеть для того, чтобы сделать её реализацию в языке удобной.
Рефле́ксия (от позднелат. reflexio «обращение назад») — это обращение внимания субъекта на самого себя и на своё сознание, в частности, на продукты собственной активности, а также какое-либо их переосмысление.
Что вы там лепите, ******* безграмотные?
Каким образом языки программирования и их происхождение могут быть продуктом активности массового сознания?
Вообще-то вы и сами прекрасно поняли, что хотел сказать автор. А если нет, то это повод задуматься. Рефлексия, как вы ранее упомянули это обращение назад. Т.е. в данном случае это означает, что человек не занимается возвратом сознания и анализом, что вполне приемлимо и никакой ошибки я тут не нашёл.
P.S. Безусловно, есть более подходящее слово, так и вертится на языке, но никак не могу вспомнить.
Не было бы Джобса — ничего страшного, были бы другие смартфоны.
А культ личности — это плохо.
Я заметил интересную классификацию: некоторые языки известны по именам, некоторые — по компаниям.
В качестве примеров, есть языки, авторов которых «все знают»: C от Кена Томпсона и Денниса Ритчи, C++ от Бьярна Страуструпа, Python от Гвидо ван Россума, Ruby от Юкихиро Matz Мацумото, Scala от Мартина Одерски, Pascal от Никлауса Вирта. С другой стороны «корпоративные» языки: Sun Java, Microsoft C#, Mozilla JavaScript и Rust, Apple Objective-C и Swift, JetBrains Kotlin. Причём известно, что C делался в AT&T, Гвидо наверное где-то тоже работал, фольклор сохраняет предание о JS, написанном за 2 недели каким-то парнем, да и Kotlin пилят конкретные люди, но почему-то на слуху оказываются в одних случаях люди, в других — компании.
Интересно, почему так? Или это только в моём инфополе такое разделение?
Что думаете о конференции Codemotion?
Неужели Котлин начинает набирать обороты и можно будет его начинать использовать вместо мерзкой Джавы?
Был один хороший язык на JVM, но мир не смог его осилить и понять как на нем писать. А возвращаться со Скалы на Джаву было очень больно. Теперь я все ещё жду, что появится нормальная замена для нее, но пока не будет популярности, боюсь что будет очень сложно ставить деньги на очередного кандидата.
На мой взгляд сейчас гораздо актуальнее новые нативные языки типа Go, Swift, Rust. Java нужна в-основном для допиливания давно написанного энтерпрайза, поэтому другие языки для JVM уже не взлетят — никто не будет переписывать софт на Scala или Kotlin. В мобильной разработке под один Android писать не выгодно, так что там рулят кроссплатформенные средства разработки, соответственно Kotlin как замена Java там тоже пролетает.
На мой взгляд сейчас гораздо актуальнее новые нативные языки типа Go, Swift, Rust. Java нужна в-основном для допиливания давно написанного энтерпрайза, поэтому другие языки для JVM уже не взлетят — никто не будет переписывать софт
А можно поподробней?
- Какую сферу применения вы видите для Rust?
Если позиционировать его как замену C++, то насколько знаю, C++ тоже используется в легаси кода — в финансовых приложениях, где важна скорость (поэтому C++, а не Java).
Какие есть еще области применения? Язык действительно очень интересный — системный и со всеми современными плюшками, хотелось бы его видеть в реальной работе. - Swift? Но если Swift, то почему вы не ставите на Kotlin? Для мобильной разработки он требуется в том же объеме, что и Swift (а когда выйдет Fuсhsia OS, писать/переписывыать приложения нужно будет еще больше).
Потенциально Rust — замена C++ и C. Хотя, на мой взгляд, зря они скопировали закорючечный синтаксис C++. Я его привёл больше для полноты примера и потому, что он использует инновационную модель управления памятью.
если Swift, то почему вы не ставите на Kotlin
Потому как Swift нативный и не использует сборщик мусора, что в реальных задачах ставит его на один уровень с C++ по скорости. Прикручивание языка, изначально предназначенного для VM, к нативу, обычно не работает.
Кстати Swift уже поддерживается в Fuchsia, соответственно выбор языка для написания легкопортируемого мобильного приложения в будущем очевиден.
Прикручивание языка, изначально предназначенного для VM, к нативу, обычно не работает.
Со Скалой такое что-то не взлетело.
Потенциально Rust — замена C++ и C.
Тогда здесь уместен ваш же аргумент против Java в части переписывания на Kotlin:
На C/C++ тоже практически все написано, и вряд ли все это будет переписываться на Rust.
Про Rust давно говорят (как говорили раньше про D), но где рабочие проекты, а если точнее, реальные вакансии?
В отличие от той же JVM, код на C очень сильно привязан к системе и железу.
При серьёзных изменениях, например, переходе с 32 бит на 64 бита или с x86 на ARM, при смене парадигм (асинхронность вместо многопоточность) проще код переписать, чем исправить.
Если писать на C/C++ правильно, то код не устареет, его достаточно будет пересобрать.
В этом плане JVM/.NET не сильно дальше от железа, чем Си:
вспомните истории, когда импорты системных функций делались с помощью Int32-, а не IntPtr-указателей, и как все посыпалось при переходе на x64-версии, особенно 8.1/10.
А все потому, что код был написан неправильно, и нужно было править именно исходники.
Также, вы не задумываись над таким вопросом?:
типы int (Integer, Int32), long (Long, Int64) в Java и .NET определены жестко:
32 и 64 бит.
При этом везде в коде, включая базовую библиотеку, используются именно 32-битные целые.
И все работает нормально только потому, что в x64 архитектуре 32-битное целое такое же "нативное", как и 64-битное.
И даже вследствие особенностей архитектуры более нативное: если не ошибаюсь, операции с 32-битными числами атомарные, а 64 — нет.
И что будет, когда появится действительно 64-битная архитектура? И тем более 128-битная? Где 32-битное целое будет эмулироваться, как сейчас это происходит с 8 и 16 бит.
Если писать на C/C++ правильно, то код не устареет, его достаточно будет пересобрать.
Что значит "правильно"? И как писать правильно в случае, когда ни один из базовых типов данных не имеет определённого размера? Спасибо, что хоть char сейчас официально — 8 бит.
И да, сразу напомните, когда в C завезли тип ptrdiff_t, до появления которого все массово использовали int?
Также, вы не задумываись над таким вопросом?: типы int (Integer, Int32), long (Long, Int64) в Java и .NET определены жестко: 32 и 64 бит. При этом везде в коде, включая базовую библиотеку, используются именно 32-битные целые.
Нет, это просто абстрагирование от уровня железа. В том же C++ в стандартной библиотеке сплошь и рядом используются size_t и ptrdiff_t.
Подход C++ позволяет использовать 64-битные индексы в массивах, но ценой геморроя с типами и расточительством памяти на хранение 64-битных индексов.
Подход C# и Java же ограничивает массивы 2 гигабайтами памяти. Но на практике в прикладных необходимость в настолько огромных массивах данных отсутствует.
И все работает нормально только потому, что в x64 архитектуре 32-битное целое такое же "нативное", как и 64-битное.
Вы путаете причину и следствие. Не Java/.NET используют 32-битную арифметику, потому что такова архитектура, а архитектура была разработана таким образом, потому что есть потребность в использовании 32-битной арифметики.
И даже вследствие особенностей архитектуры более нативное: если не ошибаюсь, операции с 32-битными числами атомарные, а 64 — нет.
Ошибаетесь. Арифметические операции с 64-битными числами на x64 атомарны. На x86 — нет, не атомарны, но даже там есть инструкция CMPXCHG8B, атомарно работающая с 64-битными данными.
Где 32-битное целое будет эмулироваться, как сейчас это происходит с 8 и 16 бит.
Ничего не эмулируется. В системе команд x64 работа с байтами и словами нативна.
Сколько тут неверных предположений.
1. Int128 ;) Как индекс это бессмысленно, т.к. Int64 это 17000Пб адресного пространства. Нам еще не скоро предстоит увидеть столько памяти даже в одном супере, не говоря уже об одной машине.
2. Смысл сохранения Int32 как базы в том что при переезде на int64 все целочисленные массивы автоматически увеличатся вдвое. А это иногда упс, очень больно.
3. «Подход C# и Java же ограничивает массивы 2 гигабайтами памяти. Но на практике в прикладных необходимость в настолько огромных массивах данных отсутствует.»
Знаете, я бы на вашем месте высказывая такие штуки немного притормозил и подумал. Потом еще немного подумал… Потому как вы совсем не правы, говоря за всех. Физика твердого тела, моделирование потоков жидкости и газа, работа с геномом, базы данных… Это первое что вспомнилось на вскидку, все они хотят большие целочисленные массивы.
Потому как вы совсем не правы, говоря за всех. Физика твердого тела, моделирование потоков жидкости и газа, работа с геномом
А вам не кажется, что для подобных вычислительных задач использование C# и Java вместо нативных ЯП типа C/C++/Fortran — не лучший выбор?
Сейчас вообще стало довольно модно в таких прикладных вещах основную архитектуру писать на, скажем, питоне, и только в вычислительно сложных местах спускаться в библиотеку на C/C++.
Например тот же TensorFlow. Но скажу от себя — отладка ошибок в библиотеке это отдельное действо, больше похожее на сплошную боль :)
Неужели Котлин начинает набирать обороты
Да ничего он не начинает, пиарят его здорово — это да. Маркетинг голый. Вдумайтесь, зачем он на самом деле нужен, и вы найдете ответ на свой вопрос.
del
взлёт языка Kotlin.
Пока я вижу только хайп вокруг этого языка.
Сейчас разработка под Android активно переходит на Kotlin, сопровождается это бурными восторгами
Насколько активно, есть сухие цифры? И про бурные восторги тоже интересно.
Незамеченное IT