Какой язык использовали для написания самых первых программ для самых первых компьютеров с хранимой программой?
Двоичный машинный язык, конечно.
Почему?
Очевидно потому, что не было символьного ассемблера. Первые программы необходимо было писать двоичным кодом.
Насколько легче писать программы на ассемблере, чем на двоичном машинном языке?
Намного легче.
Можно цифру? Во сколько раз легче?
Ну, блин, ассемблер делает всю тяжелейшую «рутинную» работу для вас. Т.е. он рассчитывает все физические адреса. Он составляет все физические машинные команды. Он обеспечивает невозможность выдачи физически нереализуемых команд, например, адресацию за пределы адресного пространства. И затем он создаёт легко загружаемый двоичный вывод.
Экономия объёмов работы огромная.
Насколько? Можно цифру?
OK. Если бы я должен был написать простую программу, как, например, печать квадратов первых 25-ти целых чисел, в ассемблере на старой машине типа PDP-8, то мне потребовалось бы приблизительно два часа. Если бы я должен был написать ту же программу на двоичном машинном языке, это заняло бы вдвое больше времени.
Я говорю вдвое, потому что я сначала написал бы программу в символьном синтаксисе на бумаге, а затем ассемблировал бы машинный язык вручную на бумаге. После чего я должен был бы ввести этот двоичный код в компьютер также вручную. И вся эта дополнительная работа потребовала от меня примерно столько же времени, что написать программу в первом случае. Возможно, больше.
Хорошо, достаточно. Таким образом, использование символьного ассемблера снижает объём работ в два раза?
На самом деле, думаю, намного больше. Возведение целых чисел в квадрат является довольно простой программой. Чем больше программа, тем труднее её вручную ассемблировать и загружать. Полагаю, на деле выигрыш в трудоёмкости зависит от размера программы. Для больших программ экономия времени значительная.
Пожалуйста, поясните.
Хорошо, предположим надо изменить одну строку в программе на символьном ассемблере. Это займёт у меня 20 минут на старом PDP-8 с перфолентой. Но при ручном ассемблировании я должен затем пересчитать все адреса и реассемблировать все машинные команды вручную. В зависимости от размера исходной програмы уйдут часы. Последующий ручной ввод потребует не меньше времени.
Я мог бы сэкономить время, сегментируя программу на модули, загружаемые на фиксированные адреса, имеющие свободные интервалы между ними. Можно сэкономить ещё немного времени, написав небольшую программку, которая поможет загружать большую программу. Однако такая «рутинная» нагрузка будет, всё же, очень, очень высокой.
Хорошо. Но, всё же, можно цифру? В среднем, насколько использование ассемблера облегчает работу по сравнению с написанием программы в двоичном коде?
Ладно. Полагаю, можно сказать, примерно в 10 раз.
Иными словами, символьный ассемблер позволяет одному программисту выполнять работу десяти программистов, работающих в двоичном коде?
Да, это, вероятно, близко к правде.
Если символьный ассемблер уменьшил трудоёмкость примерно в 10 раз, то насколько это сделал Фортран?
Очень прилично. Если мы говорим о 50-х, то Фортран тогда был простым. Иначе говоря, он был несколько больше, чем символьный ассемблер для символьной компоновки, — не уверен, понимаете ли вы, что я имею в виду.
Значит ли это, что он уменьшил трудоёмкость ещё в десять раз?
Что вы, конечно, нет! «Рутинная» нагрузка у символьного ассемблера не была такой высокой. Я бы сказал, что Фортран уменьшил трудоёмкость сравнительно немного. Возможно, примерно на 30%.
Иначе говоря, 10 программистов на Фортране могут заменить 13 программистов на ассемблере?
Если вы желаете рассматривать процесс с такой позиции, то да, похоже на то.
Продолжаем — насколько помогает сберечь время такой язык как С по сравнению с Фортраном?
Ну, С затрачивает немного меньше времени на «рутинную» работу, чем Фортран. В старом Фортране нужно было помнить такие вещи, как номера строк и порядок общих операторов. Было также невероятное количество операторов перехода по всему тексту. Язык С намного более комфортный для программирования, чем Фортран 1. Я бы сказал, что он уменьшил трудоёмкость примерно на 20%.
Хорошо. То есть 10 программистов на С могут заменить 12 программистов на Фортране?
Ну, это, конечно, только предположение, но я бы сказал, обоснованное предположение.
Хорошо. Теперь: насколько С++ уменьшил трудоёмкость по отношению к C?
Послушайте, давайте остановимся. Мы сейчас не вспоминаем о намного большем воздействии.
Разве? Что именно?
Среда разработки. Это значит, что в 50-х годах мы использовали перфокарты и бумажные ленты. Компиляция простой программы занимала, как минимум, полчаса. И то, если вы могли получить доступ к машине. Но в конце 80-х, когда С++ стал популярным, программисты хранили свои программы на дисках, а компиляция простой программы продолжалась уже всего две-три минуты.
Это — снижение трудоёмкости? Или просто уменьшение времени ожидания?
А. Так вот оно что. Вопрос ясен. Да, тогда машину приходилось ждать долго.
Просьба: когда вы даёте ваши оценки трудоёмкости, исключайте, пожалуйста, время ожидания. Мне интересна экономия времени, связанная только с самим языком.
Понятно, понимаю. Итак, вы спрашивали о C++. Вообще-то, честно, я не думаю, что C++ как-то значительно снизил трудоёмкость. Конечно, что-то было, но, полагаю, не более 5%. Это значит, что рутинная нагрузка в С просто была небольшой, и поэтому сравнительная экономия времени при работе в С++ не могла быть значительной.
Если использовать 5%, то это значит, что 100 программистов на С++ могут заменить 105 программистов на С. Это, действительно, так?
В общем, да. Но только для небольших и средних по размеру программ. Для больших программ C++ даёт некоторые дополнительные преимущества.
Какие?
Это довольно сложно объяснить. Но суть в том, что объектно-ориентированные характеристики C++, в частности, полиморфизм, позволили разделять большие программы на независимо разрабатываемые и развёртываемые модули. И это — для очень больших программ — значительно уменьшает рутинную нагрузку.
Можно цифру?
Хорошо, вы, похоже, и дальше собираетесь выкручивать мне руки… Учитывая количество действительно больших программ, которые создавались в 80-е и 90-е годы, я скажу, что, в целом, C++ уменьшил трудоёмкость, возможно, на 7%.
Это не прозвучало особо уверенно.
Да. Но давайте использовать это значение. 7%.
Хорошо. Итак, 100 программистов на C++ могут заменить 107 программистов на C?
Похоже, так я и сказал. Давайте использовать это значение.
Сколько времени сберегает Java по сравнению с C++?
Трудно сказать. Какое-то время сберегает. Java — более простой язык. У него есть автоматическое управление освобождением динамической памяти («сборка мусора»). У него нет файлов заголовков. Он работает на виртуальной машине. У него есть много достоинств. И немного недостатков.
Как насчёт цифры?
У меня ощущение, что мы буксуем… Но поскольку вы так прессуете меня, то сказал бы, что при прочих равных условиях (чего никогда не бывает) можно, работая с Java, получить снижение трудоёмкости на 5% по сравнению с С++.
Итак, 100 программистов на Java могут заменить 105 программистов на C++?
Да! Впрочем, нет. Это не так. Разброс слишком большой. Если выбрать случайным образом 100 программистов на Java и сравнить их с так же выбранными 105 программистами на C++, то я не решился бы спрогнозировать результат. Чтобы получить реальный выигрыш, требуется намного больше программистов.
Насколько больше?
Как минимум, на два порядка.
Иначе говоря, 10 000 случайным образом выбранных программистов на Java могут заменить 10 500 так же выбранных программистов на C++?
Пожалуй, так.
Очень хорошо. Насколько такой язык, как Ruby, снижает трудоёмкость по сравнению с Java?
Ну, уважаемый! (вздыхает). О чём вы? Смотрите, Ruby, действительно, прекрасный язык. Он одновременно простой и сложный, элегантный и причудливый. Он намного медленнее Java, но компьютеры сейчас такие дешёвые, что …
Извините, но я спрашиваю не об этом.
Вы правы. Я знаю. Итак, главное направление, на котором трудоёмкость у Ruby меньше по сравнению с таким языком, как Java, — это Types (Типы). В Java необходимо создавать формальную структуру типов и поддерживать её согласованность. В Ruby можно играть с типами довольно быстро и свободно.
Звучит как прирост производительности труда.
В общем, нет. Оказывается, возможность играть быстро и свободно со структурой типа ведёт к появлению класса ошибок времени исполнения, которые отсутствуют при программировании на Java. Поэтому программисты на Ruby имеют более высокую нагрузку по тестированию и отладке программ.
Иными словами, эти эффекты уравновешиваются?
Это зависит от того, кого вы спрашиваете.
Я спрашиваю вас.
Ладно. Я бы сказал, что эффекты не уравновешивают друг друга. Трудоёмкость при работе с Ruby ниже, чем с Java.
Насколько? 20%?
Люди привыкли думать так. Действительно, в 90-е многие думали, что программисты на Smalltalk работают во много раз производительнее, чем на C++.
Вы запутываете меня. К чему вспоминать те языки?
Да потому, что C++ довольно близок к Java, а Smalltalk — к Ruby.
Ясно. Таким образом, Ruby снижает трудоёмкость в несколько раз по сравнению с Java?
Нет, скорее всего, не так. Если оглядываться на 90-е, то проблема со временем ожидания была ещё довольно выраженной. Длительность компиляции для типичной программы на C++ составляла несколько минут. Длительность компиляции для программы на Smalltalk была практически нулевой.
Нуль?
Практически, да. Проблема в том, что при использовании таких языков как Java и C++ необходимо выполнять много действий по согласованию всех типов. При использовании Smaltalk и Ruby такой проблемы нет. Поэтому в 90-е для них требовалось время от минут до миллисекунд.
Ясно. Но поскольку всё это — только время ожидания, то мы можем не рассматривать его.
Не совсем так. Видите ли, если время компиляции практически нулевое, то это порождает другие стиль и дисциплину программирования. Можно работать с очень коротким циклом — секунды вместо минут. Это даёт чрезвычайно быструю обратную связь. При большой длительности компиляции быстрая обратная связь невозможна.
Быстрая обратная связь снижает трудоёмкость?
Да, в определённой степени. Когда ваши циклы чрезвычайно короткие, то «рутинная» нагрузка в каждом цикла очень мала. Ваша занятость, вызываемая необходимостью отслеживания, снижается. Удлинение циклов увеличивает «рутинную» нагрузку, причём нелинейно.
Нелинейно?
Да, «рутинная» нагрузка растёт непропорционально длительности цикла. Она может расти как, например, O(N^2). Я не знаю. Но я совершенно уверен, что зависимость нелинейная.
Замечательно! Значит, Ruby является лидером!
Нет. И в этом-то суть. Благодаря совершенствованию нашего аппаратного обеспечения в последние двадцать лет длительность компиляции для Java стала практически нулевой. Время цикла у программиста на Java стало не больше (или должно быть не больше), чем у программиста на Ruby.
Уточните, пожалуйста.
Я говорю, что программисты, использующие дисциплину короткого цикла, увидят лишь небольшое различие в трудоёмкости (или, вообще, не увидят его), работая с Java и Ruby. Имеющееся различие будет настолько малым, что его трудно будет измерить.
Неизмеряемое различие?
Я полагаю, чтобы получить статистически достоверный результат по этому различию нужно будет провести эксперименты с тысячами программистов.
Но вы раньше сказали, что Ruby снижает трудоёмкость по сравнению с Java.
Я думаю, что так оно и есть, но только если время цикла большое. Если цикл редактирование/компиляция/тестирование держать очень коротким, то эффект будет пренебрежимо малым.
Нуль?
Конечно, нет, — более вероятно около 5%. Но разброс будет гигантским.
Таким образом, 10 500 программистов, работающих в коротком цикле на Java, выполняют ту же работу, что 10 000 программистов в коротком цикле на Ruby?
Если добавить ещё один порядок для размера выборки, то я бы рискнул согласиться.
Существуют ли языки, превосходящие Ruby?
Можно получить ещё 5%, используя язык типа Clojure, поскольку он, с одной стороны, довольно простой, и, с другой стороны, функциональный.
Вы даёте лишь 5% функциональному языку?
Нет, я говорю, что дисциплина короткого цикла практически стирает различия по производительности в современных языках.
Если вы работаете с короткими циклами, то едва ли имеет значение, какой современный язык вы используете.
То есть: Swift? Dart? Go?
Не имеет значения.
Scala? F#?
Не имеет значения.
Иными словами, мы достигли вершины. Никакой будущий язык не будет лучше того, что мы имеем теперь.
Не совсем так. Я говорю лишь, что мы идём по пути снижающейся эффективности. Ни один будущий язык не даст выигрыш в 10 раз, как это было у ассемблера по отношению к двоичному коду. Ни один будущий язык не даст снижение трудоёмкости на 50% или 20% или даже 10% в сравнении с имеющимися языками. Дисциплина короткого цикла свела различия к практической неизмеримости.
Тогда почему же появляются всё новые языки?
Это поиск Святого Грааля.
А, так это всего лишь вопрос уровня любимого цвета.
Примечание переводчика: Заголовок поста и его тематика являются отсылкой к фрагменту фильма «Монти Пайтон и Священный Грааль», в котором рыцари Круглого стола отвечают на
Комментарии (115)
numitus2
26.08.2016 15:23+10Какой-то поток сознания. Программы написанные на С занимают раз в 10 меньше строк чем на ассемблере и во сколько же проще читаются, и к тому же во сколько же раз проще поддерживаются. К тому же я бы посмотрел на создание сайта на C++.
RPG18
26.08.2016 15:58+1К тому же я бы посмотрел на создание сайта на C++.
Пожалуйста Диалог выбора файлов на Wt.
А я бы посмотрел бы на создание сайта на Python/Ruby/PHP без фреймворокв/CMS и фреймворков/библиотек JavaScript и без надстроек над CSS. К чему это? Со времен выхода "Мифического человека-месяца" самый дешевый и быстрый способ разработки: купить готовое, а не писать своё. Сейчас для быстрой скорости разработки во главе угла стоят фреймворки, библиотеки и другие готовые компоненты, а сам язык уходит на второй план.
G-M-A-X
26.08.2016 23:37+1>А я бы посмотрел бы на создание сайта на Python/Ruby/PHP без фреймворокв/CMS и фреймворков/библиотек JavaScript и без надстроек над CSS.
Лехко.
Это модники тянут разный мусор из фреймворков PHP/JS и надстроек над CSS.
А потом не знают как сделать элементарные вещи.
Да и скорость разработки на этом мусоре на самом деле не увеличивается, а цена растет.
>купить готовое, а не писать своё
Зачем покупать? Можно загнать в стойло соцсетей.
Многие вещи лучше купить, но есть много специфичных.
azsx
26.08.2016 16:12К тому же я бы посмотрел на создание сайта на C++.
На самом деле сайты делают. Проекты выдерживают огромные нагрузки и имеют очевидный недостаток, свободных программистов, которые реально умеют дорабатывать программы на С++ и ищут работу, тем более в веб отрасли — крайне мало. Может даже вернее сказать — их совсем нет.
http://cppcms.com/wikipp/ru/page/mainnumitus2
26.08.2016 16:31+2Я не говорю что это невозможно, просто это в разы труднее чем на питоне или php
OnYourLips
26.08.2016 18:56+2Труднее — некорректное слово.
Это дольше. Гораздо дольше из-за отсутствия нужных инструментов.
Это менее надёжно. Больше вероятности сделать ошибку. Гораздо менее надёжно из-за того, что придётся делать велосипеды и изобретать инструменты, ошибки могут быть ещё и в них.
Это гораздо дороже. Потому что дольше.
Проблема надёжности может быть частична решена увеличением времени на проверку инструментов и самой системы.
Это может не решить задачу, потому что условия задачи могут иметь сроки её реализации, в которые невозможно уложиться. В итоге многие задачи на C++ просто нельзя решить, а на Java или PHP они прекрасно решаются.
Заметьте, сколько раз я упомянул сроки. Практически все проблемы в сроках.azsx
26.08.2016 19:20+1Удивительная вещь. Написать игру (в том числе и сетевую) на С++, если игра критична к скорости обработки запросов от пользователей — это логично. Есть инструменты и способы тестирование ошибок.
А написать ядро сайта на С++ — это дороже и ошибок будет море. При чем ссылку я дал, cms на С++ есть, одна. Но то ли дело java, которую юзают почти на всех гос сайтах. Ошибки, конечно, бывают, но на С++ их было бы непременно больше. Сарказм, если что…numitus2
26.08.2016 20:39+2Несколько непонятно что значит сарказм. Вы сомневаетесь что писать сайт на С++ нерационально?
kekekeks
26.08.2016 21:04+2А почему бы и не написать? Статическая типизация есть, нормальные плюсовые шаблоны для управления памятью в стандартную библиотеку ещё в C++11 вошли. Если человек не пришедший по объявлению птушник, а действительно умеет программировать, то проблем у него не возникнет. Производительность и прожорливость до памяти при этом будет меньше в разы. Так что если стоит задача сделать что-то, что обрабатывает миллионы запросов и развёрнуто на 10+ серверах, то использование C++ будет экономически оправданным решением.
DrPass
26.08.2016 21:31> Так что если стоит задача сделать что-то, что обрабатывает миллионы запросов и развёрнуто на 10+ серверах,
> то использование C++ будет экономически оправданным решением.
Если речь идёт всё-таки о сайте, то скорее всего нет. Просто по той причине, что сам по себе инструментарий для хостинга подобных систем уже есть, и писать ещё один такой же (и годами отлаживать по-новой уже все пройденные грабли) точно нерационально. А если решать частную задачу по генерации HTML с помощью CGI-приложения на C++, то… зачем? Другие инструменты может быть и не быстрее сделают генерацию, но уж точно сделают быстрее сопровождение и развитие сайта.kekekeks
26.08.2016 22:03Ну так есть же готовые фреймворки для плюсов. CPPSP тот же слабо отличим от классического аспнета.
DrPass
27.08.2016 11:09Да всё равно, тут же главный вопрос как раз «зачем?» Вот смотрите, приведенный вами CPPSP обновлялся два с половиной года назад. В ИТ это достаточный срок, чтобы предположить, что автор потерял к проекту интерес, и развития можно не ждать. Скачиваний у него немного, поэтому рассчитывать на проверку/отладку со стороны комьюнити тоже не приходится. Т.е. это такой себе кот в мешке, который непонятно какие грабли в себе несёт. Это уже заведомо хуже популярных инструментов, которые используются десятками, сотнями тысяч разработчиков.
kekekeks
27.08.2016 11:13Ну вон товарищ выше привёл регулярно обновляющийся фреймворк с возможностью коммерческой поддержки. Вы поймите, не все клепают сайты-визитки и моднявые SPA-приложения с посещаемостью < 100K человек в сутки. С ростом нагрузки стоимость работы программиста становится дешевле стоимости работы железа.
DrPass
27.08.2016 20:42> С ростом нагрузки стоимость работы программиста становится дешевле стоимости работы железа.
А ещё с ростом нагрузки стоимость ошибок программиста и недостатков платформы становится намного выше. В качестве академических проектов — почему бы и нет, но я все равно склоняюсь к тому, что в коммерческом продакшене массовая платформа будет всяко лучше и надёжнее экзотической. Ну вот найдёте вы разработчика, который POCO изучил и использует, и он уговорит вас делать проект на POCO. Даже если и всё взлетит и заработает, но через год он уедет в США или еще куда-нибудь, и где вы будете искать второго такого же?
struvv
29.08.2016 09:48-2А как быть с undefined behavior? Именно он является ключевой причиной почему сайты не пишут на c++. Сайт это не компьютерная игра, он не может работать 6 часов со всё растущими тормозами с последующим крашем или просто крашем на ровном месте.
Тем более java показывает прекрасную производительность из-за JIT, а память нынче очень дешёвая(Даже если весь код работает упираясь в CPU, то производительность кода на java очень близка к коду на Си, а с новым сборщиком мусора это верно даже при небольших объёмах памяти или наоборот — ворочании огромных объёмов данных)
Если бы в c++ убрали UB, так чтобы он не просел в 2 раза по производительности, то писали бы именно на нём, а так пишут на том, что похоже на c++, но с минимумом UBkekekeks
29.08.2016 11:30+2Вот честно, ни разу в своей практике не напарывался на проблемы из-за UB. Оно обычно проявляется либо из-за нежелания читать стандарт языка, на котором пишешь, либо от от желания показать, что ты умнее компилятора.
Если так боитесь UB, возьмите свежий GCC и компилируйте с -Werror. У них там прямо из оптимизатора предупреждения выдаются о применении оптимизаций из-за UB.struvv
29.08.2016 20:50+2Речь тем не менее идет о коммерческом применении для разработки backend в рамках данной дискуссии.
Предположим есть типичный проект в 2-5кк строк. Прекращение доступа к ресурсу стоит к примеру 1000$ в 10 минут. Возникает вопрос, все ли готовы взять на себя ответственность и отказаться от защиты, которую предоставляет компилятор java ради некоторого увеличения скорости и уменьшения потребления памяти, за которую вообще платит компания или лучше риски уменьшить.
Обычно начиная с определённого уровня у разработчиков есть право выбирать архитектуру, экосистему итд. И вот для backend как-то стрёмно брать c++, так как у нас свободный рынок труда и разработчик, нанёсший ущерб тыщ в 50 баксов просто уволится и пойдёт работать в другую компанию. Как-то стрёмно, хоть ты гениев собирай, у них может быть банально плохое самочувствие, низкая сосредоточенность, а потом в случае чего они свободны и это право, которое гарантируется трудовым кодексом.
Я вот не верю в то, что человек ни разу не ошибётся и не создаст баг. И если баг в java это исключение, то баг в C/C++ это достаточно часто SIG***. Если кто-то возьмёт полную финансовую ответственность за такие ошибки, то тогда вопросов нет, можно брать хоть ассемблер. При должном тестировании можно пилить хоть на ассемблере, мне самому гораздо больше нравятся именно низкоуровневые языки, но увы есть такая штука, как бюджет…
А пока как-то не видно финансового профита, который даёт C++ перед java в случае если речь идёт о backend.
Когда мы говорим о распознавании документов, балансировщиках, быстрых хранилищах, заточенных под конкретные задачи, то мы берём C++, потому что в таких случаях он выгоден.
Я не говорю, что java лучше c++. Это два инструмента, которые без проблем могут работать вместе.
Это был лишь ответ на вопрос почему сейчас при разработке backend web ресурсов часто предпочитают java. Если в C++ были бы хорошие модули, возможность запретить UB(кидать исключение) иXandrmoro
29.08.2016 22:43А какую защиту предоставляет компилятор java, извините?
kekekeks
29.08.2016 23:23+1Видимо, имеется ввиду, что там сложнее при ошибке вместе с ногой отстрелить себе жизненно важные органы (словить heap corruption, например). Но при желании всё равно можно, да.
struvv
30.08.2016 08:09+1Речь шла о защите компилятора и защите, которую предоставляет VM(Предыдущее сообщение внезапно отправилось не будучи до конца изготовленным.)
- В Java используется подход — по умолчанию мы пишем безопасно, но используя Unsafe можем делать опасные вещи.
- В C/C++ по умолчанию мы лишены безопасности, но используя знания стандарта можем писать безопасно. Но при этом мы получаем какие-то преимущества.
Относительно детализации этой разница можно целую статью написать. Но самая ключевая часть — java даёт гораздо менее дырявые и менее протекающие из всех щелей абстракции, чем c++. О том, что такое дырявые абстракции можно прочитать тут. Я это отношу к определению «защита компилятора», хотя это не совсем так, но к сожалению в данный момент какого-либо более подходящего определения у меня нет в наличии.
В качестве хорошей абстракции можно представить систему запуска автомобиля, который заводится одной и той же кнопкой старта в любую погоду, хоть в минус 50. В качестве плохой абстракции можно представить систему двигателя запуска шахи — у неё внутреннее устройство этой системы полностью нарушает принцип инкапсуляции и пользователю нужно знать кучу его особенностей, чтобы правильно им пользоваться.
В итоге различия(никак не связанные с наличием GC) приводят к тому, что для определённых задач гораздо выгоднее использовать первый подход и в рамках этих задач java очень трудно заменить на c++ без удорожания разработки в несколько раз
qw1
30.08.2016 12:30Быстро найти баг и исправить его очень помогают хорошие стектрейсы, которые не делает c++ (в Release он много инлайнит и выкидывает фреймы стека при любом подходящем случае).
acmnu
29.08.2016 11:31+4> Тем более java показывает прекрасную производительность из-за JIT, а память нынче очень дешёвая
Как человек уже миллион лет работающий с продуктами на java, могу сказать, что проблема этой платформы для админов совсем не в памяти. Да действительно память дешевая, хотя и не настолько как это кажется разработчикам (бытовая память в вашем компьюетере иной раз на порядок дешевле, чем ECC в дорогом сервере).
Самая главная технологическая беда это GC. Как не крути ребус, какой алгоритм не выбирай, но на временном диапазоне в год и количестве инсталяции 100+, рано или поздно нарвешься на тормоза. И разумеется это произойдет в самый важный момент (отчетный период в банке или у провайдера, например), когда нагрузка велика.
Отягощают эту проблему манера писать у современных ява прогреров: зная что есть GC, они абсолютно безолаберно относятся к созданию сущностей. Христоматийный «хеллоу ворлд» из десятка класов хоть и гротеск, но хорошо отображает реальность. Практический на любое действие создают тысячи объектов в куче, которые уже через секунду-две не нужны.
Просто представте себе прием платяжей у провайдера с миллионной абонентской базой. Обработка платежа длится 30-40 ms, но за это время успевает создаться 30-50 объектов, которые почти тут же становятся не нужны. А рядом трудится написанный на C RADIOUS сервер, который глобально делает нечто очень похожее, но умудряется переиспользовать выделенные участки памяти и работать годами без сбоя без просадки производительности. Во многом эта ситуация завязана на излишне общие фреймворке, но все таки основа беды в культуре написания ПО.struvv
29.08.2016 21:51+2GC это то, что хорошо видно на инструментах мониторинга при тормозах, но это не сама причина тормозов, так же как и те же вакуумы в версионных RDBMS. Обычно можно поработать с параметрами VM, например последний сборщик мусора G1GC показывает себя прекрасно, плюс почти всегда тормоза возникают где-то в недрах БД, а не на сервере, где крутится java, но всякое бывает, надо детально изучать каждый конкретный случай, не важно на каком языке там всё сделано.
Относительно менеджмента памяти есть устойчивый миф, что разработчики java не умеют управлять ресурсами. На самом деле управление ресурсами на c++ проще и гораздо более продумано, чем в java. В java только память управляется автоматически, а вот все остальные ресурсы — нет. Если бы в c++ был бы добавлен такой же GC, то всё равно то что сейчас пилят на java пилили бы дальше на ней же, т.к. причины почему её выбирают совсем не в GC. Даже если его убрать, всё равно ничего не поменяется.
Другой проблема, что разработчики могли написать ересь, но так можно сделать на любой языке. В java это вызовет тормоза или там NPE, который устраняется за 5 минут. А вот в том же альтернативном биллинге на языках, которые имеют UB и таких же разработчиков будет краш биллинга и замечательные N часов в режиме нонстоп и состоянии лёгкого аффекта, состоящие из попыток найти почему оно вообще валится в продакшне под нагрузкой. Не, слишком нервно это всё.
я ни разу не спорю, что на Си можно сделать быстрее. Но скажем так — C/С++ это полностью спортивный автомобиль, с снятым каркасом для облегчения. Он может показывать отличные результаты в руках умелого водителя. Но на нём легко убить себя и не только себя и это часто коммерчески не выгодно.
Скорость и память это лишь небольшая часть профита. Далеко не всегда он перевешивает остальное виды профита. А когда такое происходит — есть замечательные проверенные временем экосистемы, позволяющие писать максимально быстрый код.
Для меня как java, так и c++ не более чем два разных инструмента для разных целей. Но использовать c++ для бэкэнда -на мой взгляд слишком рисковано для прибыли компании.
Если бы c++ имел возможность работы в enterprise режиме c максимально полным запретом UB, невозможностью выпадания в SIG*** и аналог maven, то использовался бы именно c++. Сейчас есть только D с похожими свойствами-
с синтаксисом c++, менеджером модулей, без сборщика мусора, без UB, поэтому в определённых задачах нет выхода, но в нём очень слабо теплится жизнь. Поэтому в ряде задач остаётся только java.
И её выбор делают не из-за такого различия с C++, как наличие GC, а из-за тех причин, о которых я написал — почти нет UB, хороший менеджер пакетов, крайне низкий шанс словить краш всей VM, т.е. низкие риски получить полный отказ системы, обслуживающей кучу народа.acmnu
30.08.2016 11:43> GC это то, что хорошо видно на инструментах мониторинга при тормозах, но это не сама причина тормозов, так же как и те же вакуумы в версионных RDBMS.
Ну это очевидно, я собственно и не говорил, что сама по себе платформа плохая. Речь о том, что GC в сочетании со средним программистом это неприятно.
Про C/C++ все верно: сегфолтов там будет на порядок больше, чем NPE в java. Но тут, понимаешь, работает отрицательный отбор: средние прогеры на С не выживают именно из-за того, что их поделия сыпятся, а средние прогеры на Java могут делать вид, что они спецы очень долго.
Я очень хорошо понимаю, что отдебажить С++ упавший в продакшене крайне сложно. Но обычно в таком случае у меня был бородатый гуру, ну или просто толковый студент, который умудрялся найти ошибку относительно шустро. А вот когда система неожиданно упиралась в FullGC или просто работала заметно медленнее с вероятностью в 95% у меня был индусоподобный гражданин, который вообще не знает как Java машина устроена, которому я, с моими чисто админскими знаниями об этой штуке, буду долго объяснять что случилось.
Поэтому чисто статестически для меня GC это худшее что есть в Java. И где-то рядом с этим ад называемый deployment.
Scf
30.08.2016 12:02Не уверен, что приложения на С удобнее деплоить, чем джавовые. Там же своих приколов хватает с версиями библиотек, "немного другим ядром" ОС и все такое.
acmnu
30.08.2016 12:21Там все более менее линейно: либо статическая линковка, тогда вообще нет проблем, либо динамика, но админы с ней очень хорошо знакомы и понимают как это работает. Да и стандарт в ентерпрайзе нынче один: RHEL и его клоны.
А в java, во-первых, может быть много деплоеров с разной логикой и нюансами. Например spring. Особенно забавно смотреть на случай одновременного использования спринга и штатного для аппликейшен сервера загрузщика. Или вообще свой деплоеер. Редко, но бывает.
Во-вторых, может быть много чисто физически разных форматов: jar, war, spring или что-нибудь кастомное, которые как-то сочетаются с первым пунктом. Бывает сложно разобраться а в какой же последовательности это все загружается. Совсем недавно я был вынужден использоваться deployment.xml в котором было написано, что для все файлов начинающихся с superproject, сначала надо загрузить spring, потом jar, потом war, но немного с другим именем :)
В-третьих, java девелоперы имеют очень плохую тенденцию тянуть много сторонних библиотек, которые не совместимы сами с собой. Например Axis умудряется изменить api в минорных версиях, что требует доработки своего кода, а иногда вам нужно два аксиса разных версий, которые притянулись как зависимости, но вы не всегда этого можете добиться (в частности на такой каке как jboss или как она там сейчас называется) и тогда вообще беда.Scf
30.08.2016 13:07Application server-а — да, согласен, геморрой еще тот. К счастью, современные приложения пишут stand-alone — т.е. shell-скрипт запуска + папочка lib с джарниками. Либо деплоят образы Docker — с ними вообще минимум проблем.
struvv
30.08.2016 20:35+1К сожалению компания никак не может надеяться на наличие бородатого гуру. И на отбор тоже не стоит рассчитывать, это слишком опасно. Вдруг этот гуру заболеет или ещё что и как раз в этот день всё решит рухнуть. В большинстве систем лучше пусть будут тормоза, чем вообще отказ.
Насчёт GC — ну не знаю. Раньше с ним действительно были проблемы, особенно сильно давно, а сейчас GC и JIT отлично работают, особенно новый G1GC. Тем более как правило тормоза с GC решаются конфигурированием JVM, это как раз делают админы. Потом есть наблюдения за поведением VM, профилирование и устранение проблемы. Для этого только кнопку начала/окончания надо нажать и скинуть результаты профайлинга разработчикам(на самом деле система может быть так нагружена, что её сложно профилировать, но и это решается)
К слову GC сейчас справляется без проблем с цифрами поболее чем порождение 1 000 000 объектов в сек, а не 1500-1700. Насчёт этого вообще не надо парится в современной java, я проверял, даже с jvm с 8Мб! памяти(впритык по потреблению за одну итерацию) просадка производительности всего в 2 раза по сравнению с 1гб RAM если приложение в цикле берёт и спавнит массивы объектов. Больше никаких резких уменьшений скорости работы из-за загрузки GC. Это в G1GC(дефолтный в java9, но можно использовать уже сейчас, включается флагом), а GC, который MarkAndSweep на таком сразу вешается
Да и вообще в последние пару лет я не вижу с этим проблем. JVM хорошо развивалась и развивается, и сейчас она сильно лучше, чем была раньше, поэтому и возникают холивары — обычно сравнивают старую java с старым c++, современная java достигла такого уровня, при котором можно на самом деле почти никогда не встречать проблем с производительностью.
В любом случае конкуренция между экосистемами делает лучше как C++, так и java, поэтому хорошим признаком является то, что есть такая штука, как вспыхивающие споры по поводу джавы и плюсов. Иначе мог быть какой нибудь один язык, намертво погрязший в Стандарте, и программирование бы скатилось в
— Ибо сказано на странице 4976 в разделе — о использовании запятой после последнего элемента при инициализации в многомерном массиве, используемом в упрощённой записи…
webkumo
29.08.2016 12:15Посмотрел я на сайт этой «cms»… шедевральный бенчмарк: http://cppcms.com/wikipp/en/page/benchmarks_all… просто за гранью добра и зла…
PS за сам сайт тоже убивать надо — какого фига использовать такой маленький шрифт, да ещё ограничиваться узкой колонкой — не понятно…
PPS в общем хорошо заниматься, тем что умеешь, а вот что не умеешь — может лучше не трогать?
JediPhilosopher
26.08.2016 16:57+1Мы в универе и на ассемблере сайт писали, хех. Ну как, в основном на С++ через CGI (делали сервис обработки ачивментов для нашего сервере Counter-Strike, странички можно было смотреть во внутриигровом браузере, это было еще до выхода Source и нативной поддержки ачивок в большинстве игр), но поскольку параллельно у нас шел курс ассемблера, то мы какие-то полезные куски кода выдирали прямо из курсовика.
Ничего сложного в общем, хотя конечно велосипедить побольше приходилось, да с утечками памяти бороться.
Так что теперь я честно могу свысока поглядывать на всяких там пхпшников и любителей прочих языков и гордо заявлять, что настоящие отцы пишут веб на ассемблере.
kekekeks
26.08.2016 20:52К тому же я бы посмотрел на создание сайта на C++.
Вот очень злая в плане производительности штука, предоставляющая примерно тот же инструментарий, что ASP.NET WebForms, а по бенчмаркам производительности рвёт вообще практически все существующие решения.
tangro
26.08.2016 22:58+1К тому же я бы посмотрел на создание сайта на C++
Ну, сходите посмотрите на Facebook или Google. В формировании того, что вы увидите на этих сайтах, задействована огромная куча кода на С++.
maaGames
26.08.2016 15:30+5> Иными словами, символьный ассемблер позволяет одному программисту выполнять работу десяти программистов, работающих в двоичном коде?
Десять программистов не сделают работу в десять раз быстрее, чем один программист, даже если говорить об одном и том же языке. Примерно на трети текста стало не интересно, я не настолько зануда.
ploop
26.08.2016 15:32+4Девять женщин не смогут родить ребёнка за месяц.
maaGames
26.08.2016 15:37+4Во! У вас ещё лучше пример нашёлся. Когда столь серьёзная логическая ошибка в самом начале обсуждения, то все последующие выводы основаны на ложной информации. Собственно, потому и стало не интересно читать.
Varfalomey
26.08.2016 16:49+1Думаю тут имеется ввиду, что 1 программист ASM сделает 10 задач за то же время, что 10 программистов двоичного кода каждый свою
saboteur_kiev
27.08.2016 04:51Тут дело не в выводах, а в каком-то маникальном и идиотском упорстве спрашивающего, который не ответы слушает, а хочет узнать число, хотя ему несколько раз поясняют, что число разное для разных ситуаций.
В реальности, я бы такого вопрошающего, послал бы после 3-4 вопроса, но видимо программист попался терпеливый.
grossws
27.08.2016 05:20но видимо программист попался терпеливый
вы имели ввиду воображаемого друга Дядюшки Боба?
Shifty_Fox
26.08.2016 16:51+4В статье, участник, задающий вопросы, сводил все не к срокам, а трудозатратам на произвольное X программистов. То есть, 9 женщин родят 9 детей за 9 месяцев, а одна женщина — нет. В одном проекте 9 программистов не напишут одну программу за месяц, но напишут 9 независимых программ за 9 месяцев.
Scf
26.08.2016 16:19Да даже если не оперировать толпами программистов. Один программист на сях напишет программу, которую силами любого кол-ва программистов в машинном коде написать невозможно.
bolk
27.08.2016 15:57А что им помешает?
wing_pin
29.08.2016 09:47+1Для каждого языка программирования есть порог сложности разрабатываемой на нем программы, после которого становится практически невозможно добавлять новые фичи и поддерживать этот проект. Я бы предположил, исходя из своего опыта, что этот предел подчиняется нормальному распределению, где по оси y находится сложность проекта, а по оси x располагается мощность языка в толковании Пола Грэма.
bolk
29.08.2016 19:17Всё-таки если у нас есть любое количество, то не соглашусь, да, это будет дорого, долго, стоимость изменений будет очень высокой, но это возможно.
pengyou
26.08.2016 16:01+1Видимо, важнее, не то, сколь сильно влияет язык на процесс разработки, а то, сколь сильно языки могут влиять на головы программистов, на стиль их решений, на общий подход к проблемам, а дальше, видимо, на весь мыслительный процесс (и вне работы тоже). А значит, тут мы наблюдаем борьбу мемов по Докинзу, только среди формальных систем.
Плюс в теме много факторов не-технического характера, особенно в бизнесе, которые влияют на языки и на их отбор (отрицательный, к сожалению). Так что в разговоре с самим собой автор героически себе поддался, рассмотрев только вершину айсберга. И кто его знает, может, это из-за самоуверенности, которая вызвана знанием какого-нибудь очень крутого ЯП для очень умных очень профессионалов.
Так что, разница есть, она огромна, и война за Грааль тут вполне оправдана. А то ваших детушек заставят писать на js так безальтернативно, что без добрых корпораций с v8 наперевес детушки уже не смогут вообще ничего. А как им смочь, откуда взяться пониманию? То-то же. Борьба мемов приводит к отбору генов, а если кто-то говорит иначе — не слушайте, он просто защищает свои мемы.
Cheater
26.08.2016 16:23+13Спрашивающий — какой-то придурок, упорно требующий количественные показатели там, где их быть не может по определению. Отвечающий вроде бы сначала сделал слабую попытку это объяснить, но затем видимо заразился идиотизмом и стал на эти вопросы отвечать конкретными цифрами, причём в какой-то момент уже стал открыто брать их с потолка. Феерически бесполезный диалог.
amarao
26.08.2016 16:26+5На машинном коде не возможно разработать современное веб-приложение. Не «сложно», а «невозможно». Потому что в какой-то момент server-side заканчивается и начинается браузер, который ожидает JS.
Если переводить это в язык машинного кода, то нужно будет написать полностью server-side приложение (включая СУБД, дисковую подсистему, скедулер процессов, сетевой стек, tcp), но это только цветочки.
А дальше надо будет написать БРАЗУЕРЫ под все платформы и операционные среды. Firefox под x86_32, x86_64, armv4, armv5, armv6, armpf, spark, ppc, chrome туда же, chromium туда же, IE под подмножество виндов, мобильные платформы, lynx в комадной строке…
Я бы сказал, что мой estimate для такой работы — за пределами сроков существования человечества.
Если кто-то скажет, что это всё можно упростить — да, можно. Но не забудьте, что ваше приложение должно правильно поддерживать hidpi монитор на моём фаблете, lowdpi экран на 2560х1440, а так же толерантно относиться к разным размерам глифов на разных компьютерах.
Ах, да, ещё надо поддерживать терминалы Брайля для слепых (браузеры-то такие есть). То есть если мы не хотим писать код для всех мыслимых ОС и мыслимых архитектур, надо писать JS.
То есть задача «написать программу на ассембере» большне не выполнима — надо использовать соглашения браузеров по использованию JS.
То же касается SQL. Если мы хотим избежать SQL — нам надо написать нашу версию реляционной БД.
Хотим избежать языках ahci — написать поддержку всех мыслимых и немыслимых железячных платформ.
Современная экосистема всё дальше уходит от машинного кода, потому что всё чаще система — write once, use many. Ещё не до конца, но всё более и более. Слои абстракций, каждый из которых всё менее машинный код и всё более — комфортная среда для разработки. Отказ от этой среды — предложение пойти и написать самому.grossws
27.08.2016 01:57Вполне логично, слоёв абстракции *просто стало существенно больше. Даже появление и чуть позже массовое использование микропрограмм в 50-60х годах уже сильно увеличило производительность работы программистов, предоставив ISA.
В современном мире системный-то программист не полезет ниже уровня ISA (даже если бы у него был бы доступ), равно и прикладной в большинстве случаев не полезет на уровень ассемблера и ОС.
Ciiol
27.08.2016 20:37Ну отчего же сразу «невозможно»? При должной упоротости можно сделать транслятор с машинных кодов в js. Хотя это, конечно, все равно оторвано от реальности.
Fedcomp
28.08.2016 11:36Сайт может работать без какого либо JS, аргумент непонятен.
qw1
28.08.2016 12:42Если есть функциональные требования, такие как сделать аналог «моих аудиозаписей» из вконтакта, без js их не выполнить.
amarao
28.08.2016 14:55Сделайте, пожалуйста, «без какого-либо JS» сайт, на котором на карте можно просматривать трек для хайкинга с зумом, индикатором высоты и фильтром для POI вдоль трека.
Это вам не хипстерские котики, это deadly serious приложение. И оно на JS.
youlose
26.08.2016 16:50-4Сравнение Java с Ruby в принципе неадекватное, почему только компилирование учли? Почему не учли что на Java на на порядок больше кода писать, а чем больше кода тем больше багов, которые тоже нужно покрывать тестами и/или дебажить?
А если код не только писать, но и изменять, тут у строгой типизации вообще веселье начинается. Не стало хватать разрядности в каком-то месте? Извольте изменить 100500 других мест которые с этим местом связаны. Изменился формат входных данных? Начинай плодить абстракции и/или опять танцы с изменением типов повсюду начинаются.
А инструменты? Подключить модуль через какой-нибудь maven, это целое приключение с xml конфигами, а на Ruby «gem install» и допольнительный код скачался и работает.
А если учесть что у некоторых языков какие-то конкретные решения более проработаны, чем у других, то сравнить вообще ничего не получится. Как сравнить простоту построения отказоустойчивых распределённых сервисов на Erlang и ту же Java? Я думаю там тоже разница в количестве кода(багов и.т.п.) будет на порядок.webkumo
26.08.2016 17:22+2> Сравнение Java с Ruby в принципе неадекватное, почему только компилирование учли? Почему не учли что на Java на на порядок больше кода писать, а чем больше кода тем больше багов, которые тоже нужно покрывать тестами и/или дебажить?
А если код не только писать, но и изменять, тут у строгой типизации вообще веселье начинается. Не стало хватать разрядности в каком-то месте? Извольте изменить 100500 других мест которые с этим местом связаны. Изменился формат входных данных? Начинай плодить абстракции и/или опять танцы с изменением типов повсюду начинаются.
Автору до вас куда как далеко. Поклонники perl и конкурсов типа 1k рукоплещут! Да и я, почему-то, всегда думал, что тестами покрывают осмысленные куски кода… На javadoc тесты писать будете? Строгая типизация как раз спасает от лишних багов. В общем если вы что-то не умеете, не стоит это заранее хаять.
> А инструменты? Подключить модуль через какой-нибудь maven, это целое приключение с xml конфигами, а на Ruby «gem install» и допольнительный код скачался и работает.
Модуль в мавен подключается к конкретному проекту… это позволяет неплохо рулить зависимостями. В современной IDE это задача укладывается в 3-10 секунд. Что конкретно делает ваш gem install?
В общем или вы потеряли тег сарказм или просто не разбирается в java…youlose
26.08.2016 18:51Да и я, почему-то, всегда думал, что тестами покрывают осмысленные куски кода…
Я и не писал обратного. А на баги вы тесты не пишете?
В общем если вы что-то не умеете, не стоит это заранее хаять.
Зачем переходить на личности, если вы можете рассказать как этого избежать, например?
Про maven я посмотрю завтра.
И да в Java я очень слабо разбираюсь (просто наблюдал за мучениями коллег), но внятно разбираюсь в C++ и сейчас чуть-чуть пописываю на Golang. Давайте разберёмся вместе, что же я неправильно написал выше.webkumo
26.08.2016 19:52> Я и не писал обратного. А на баги вы тесты не пишете?
Зависит от проекта (в некоторых время на тесты не выделяется, к сожалению), но в любом случае тестами покрывается логика/алгоритм/контракт/как угодно ещё назовите — суть в том, что от «многословности» java здесь нет проблем, она не вынуждает писать дополнительные тесты на пустом месте.
Так и не нашёл перехода на личности (а вот мою гипотезу вы подтвердили… ). Ну что же, вы писали о проблемах — напишите примеры, которые покажут эти проблемы, а я постараюсь объяснить, насколько они реалистичны и как в Java можно жить не имея таких проблем.
PS мавен — это не то, что требуется делать каждый день, но зависимости туда добавляются легко. Пляски с бубном начинаются только если вы хотите изменить билд-процесс.youlose
27.08.2016 09:11«суть в том, что от «многословности» java здесь нет проблем, она не вынуждает писать дополнительные тесты на пустом месте.»
«Многословность» — это больше циклов, ветвлений, необходимость реализовывать какие-то лишние простейшие алгоритмы на пустом месте (в том же Ruby очень богатая std библиотека, среди остальных подобных языков с динамической типизацией, там можно графы топологически отсортировать из коробки TSort ) и.т.п. Всё это было бы неплохо тестами покрыть. И эти тесты сложнее чем подать nil вместо некоторых аргументов, чтобы потом в коде привести их к нужному виду и часто больше никаких дополнительных тестов не надо.
«напишите примеры, которые покажут эти проблемы, а я постараюсь объяснить, насколько они реалистичны и как в Java можно жить не имея таких проблем.»
С примерами мне надо подумать, попробую позже что-то выдать, вам я предлагаю тоже дать пример где мне придётся 100500 лишних тестов написать на Ruby для какой-то задачи (ну или где строгая типизация ускоряет написание кода, а слабая замедляет и мы сравним подходы, ибо мне и самому очень интересно).
«PS мавен — это не то, что требуется делать каждый день»
Я с этим согласен, но это создаёт жуткие неудобства новичкам и там они тратят огромное количество времени и нервов (я это видел на примере 2х джунов).
«Что конкретно делает ваш gem install?»
Он загружает и делает доступным глобально модуль из центрального репозитория rubygems. Это используется когда надо быстро что-то сделать или проверить. К maven ближе будет рубёвый bundler, который ставит модули глобально, но позволяет использовать конкретные версии модулей для конкретных проектов.webkumo
29.08.2016 13:34+1> это больше циклов, ветвлений, необходимость реализовывать какие-то лишние простейшие алгоритмы на пустом месте
примеры «больше циклов ветвлений» в студию. Насчёт топологической сортировки и каких-то других «простейших алгоритмов» не уверен, но даже если это не включено в jdk, то с высокой вероятностью это можно найти в какой-нибудь библиотеке. Не вижу проблемы.
> вам я предлагаю тоже дать пример где мне придётся 100500 лишних тестов написать на Ruby для какой-то задачи (ну или где строгая типизация ускоряет написание кода, а слабая замедляет и мы сравним подходы, ибо мне и самому очень интересно).
Хм… видимо меня память подводит? Не могу найти, где я говорил, что в Ruby придётся писать лишние тесты. А строгая типизация не ускоряет (в самом банальном смысле) написание кода, всего лишь предотвращает проблемы, которые могут возникнуть либо при автоконвертации типов (с этим в java тоже возможны небольшие косяки, но их спектр — меньше), либо при получении неизвестного типа (при желании — в Java на это тоже можно нарваться, но для этого придётся сильно постараться… впрочем можно просто использовать java<1.5). Для проверки же, что в нужном месте нужный тип приходит… интеграционные же тесты придётся применять, вместо unit?! Сомнительное удовольствие… так что больше тестов писать не придётся — придётся в рантайме получать бомбу…
> Я с этим согласен, но это создаёт жуткие неудобства новичкам и там они тратят огромное количество времени и нервов (я это видел на примере 2х джунов).
Джунов на глобальные изменения помника ставить не стоит. Просто не стоит. Простой помник ещё можно доверить джуну… но лучше всё-таки подождать, пока он будет на грани мидла (а то и готовым мидлом) и дать 2-3 дня на глубокое осмысление мавена. В дальнейшем проблем быть уже не должно. Проблемы же возникают из-за непонимания и «с бору по сосенке» собранного опыта.
> Он загружает и делает доступным глобально модуль из центрального репозитория rubygems. Это используется когда надо быстро что-то сделать или проверить. К maven ближе будет рубёвый bundler, который ставит модули глобально, но позволяет использовать конкретные версии модулей для конкретных проектов.
Так зачем же вы сравнили геминсталл с мавеном, раз это настолько разные вещи? И я рад, искренне рад, что в Java нет глобальных модулей и библиотеки нужные «глобально» нужно ставить руками… Меньше шансов на косяки, больше вероятность найти проблему, если всё-таки случилась беда. Впрочем ожидаемая фича «модульности» может привезти эти самые глобальные модули в мир Java, только они же сделают мир Java готовым к такой беде… Впрочем никакого отношения к системе сборки это не имеет.
Xandrmoro
26.08.2016 17:25+5> А если код не только писать, но и изменять, тут у строгой типизации вообще веселье начинается.
А уж какое веселье у динамической, когда у тебя ломается что-то, и интерпретатор тебе даже не может рассказать, что у него и когда сломалось. Ну нет у него этой информации.
Зато недопрограммисту мозг включать не пришлось.youlose
26.08.2016 18:39-5Я вам рекомендую всё же углубиться в какой либо язык с нестрогой типизацией, такие проблемы крайне редки, особенно если стараться писать в функциональном стиле и соблюдать принцип SRP. Ну а в командах где с одним и тем же кодом работают большое количество программистов надо пытаться добиться полного покрытия тестами. Лично я с подобным давно не сталкивался. И в таком случае скорее всего будет runtime error, которую исправить в разы быстрее и проще чем на Java. А ещё есть шанс что при неверных входящих данных программа на языке с нестрогой типизацией отработает нормально (или ошибочно но продолжит работу), а вот со строгой типизацией скорее всего придётся изучать страшный segfault.
Ну и ваш снобизм не оправдан, недопрограммисты есть во всех сообществах(и для всех технологий) и думаю что в количественном соотношении цифры сопоставимы (хотя в более трендовых языках и технологиях их больше всех).
lair
26.08.2016 18:53+7ошибочно но продолжит работу
Я всегда считал, что это самый великий ужас программиста.
Впрочем, если уж совсем честно, "продолжит работу" vs "сегфолт" — это не от типизации зависит, а от того, как сделана обработка ошибок.
youlose
26.08.2016 21:05-2Я с вами согласен, и я не сказал что так надо, но так бывает в чужих проектах и диву даёшься что какой-то говнокод работает годами принимая на вход что попало и не ломаясь.
А про обработку ошибок всё то же самое и языков с слабой типизацией подходит.lair
26.08.2016 21:06А про обработку ошибок всё то же самое и языков с слабой типизацией подходит.
Вот я и говорю: фраза "при неверных входящих данных программа на языке с нестрогой типизацией отработает нормально (или ошибочно но продолжит работу), а вот со строгой типизацией скорее всего придётся изучать страшный segfault" некорректна.
youlose
27.08.2016 08:38-1При раздолбайском подходе к обработке ошибок вполне корректна, а если учесть что большинство проектов в вебе (не уверен где брать статистику по энтерпрайз разработке, но там где я с ней встречался говнокода и раздолбайства тоже было достаточно) написано именно с таким подходом (больше половины сайтов написаны на WP, например), то можно сказать что моё утверждение чаще корректно, чем нет.
lair
27.08.2016 13:29При раздолбайском подходе к обработке ошибок вполне корректна
Почему бы? Как обработка ошибок зависит от типизации языка?
(а в вебе все известные мне фреймворки, написанные на статически-типизированных языках не устраивают никакого сегфолта — который вообще не связан с типизацией, кстати, а связан с управлением памятью — а просто убивают обработку реквеста, а приложение продолжает работать)
Xandrmoro
26.08.2016 19:33+4Я по долгу работы, как разработчик полного цикла, несколько лет писал на жс и пхп. Поначалу тоже считал, что строгая типизация только мешает, а рантайм ошибки правятся быстрее ошибок компиляции. В какой-то момент углубления стало достаточно, чтобы понять, что продолжение работы на неверных данных — худшее, что может случиться с приложением, а низкий порог вхождения естественным образом ведёт к отсутствию архитектуры, размыванию ответственностей и прочим нехорошим вещам.
Ушёл три года назад в микрософтовский стек. Первый месяц было тяжеловато, потом постиг красоту жёстко структурированного кода и на лапшу, которой пользовался раньше, смотреть тошно — начиная от множества ошибок, которые в том же шарпе сделать невозможно, и как раз тем вот «надо изменить в тысяче мест», заканчивая тем, что и инструменты с таким подходом делаются и работают абы как. Да, можно и на том же жсе писать с соблюдением солида и прочих канонов — тогда разработка будет ничуть не быстрее, чем на статических технологиях, но их плюсов не будет и в помине.
А недопрограммистов в таком полу-энтерпрайзе, кстати, значительно меньше. Не выживают, знаете ли.G-M-A-X
27.08.2016 00:00В большинстве случаев со слабой динамической типизацией нету проблем.
Приводите параметры к общему типу вручную, если хотите.
PHP как бы позволяет указать параметры какого типа принимает функция.Xandrmoro
27.08.2016 00:27+2Но зачем вставлять квадратное в круглое, если можно взять нормальный ЯП?
Fedcomp
28.08.2016 11:48Потому что на динамическом разрабатывать/дебажить быстрее?
Xandrmoro
28.08.2016 17:18Разрабатывать — возможно (и то не во всех ситуациях), дебажить и поддерживать — точно нет.
G-M-A-X
28.08.2016 18:58-2А в статических языках есть типа такое:
call_user_func_array($dynamyc_function_name, $arParams); (PHP)
?
То есть на момент компиляции не известно имя функции, а только во время исполнения.DrPass
28.08.2016 20:06+1Реализации этого механизма различны, но в общем случае есть практически везде. Другое дело, что это синтаксический сахар, который бессмысленно рассматривать оторванным от контекста, где это полезно использовать.
qw1
28.08.2016 20:21Как правило, имя функции известно на момент компиляции.
Но вместо того, чтобы хранить имена функций в строках (array(1 => 'doNewDoc', 2 => 'doEditDoc')), лучше хранить их так, чтобы утилиты рефакторинга при переименовании функции смогли всё корректно сделать
var d = new Dictionary<int,Action> { { 1, () => doNewDoc() }, { 2, () => doEditDoc() } };
Xandrmoro
29.08.2016 12:27Например, на шарпе:
typeof(ClassWithFunctions).GetMethod(dynamicFunctionName).Invoke(null, arParameters); // для статических методов typeof(calleeObject).GetMethod(dynamicFunctionName).Invoke(calleeObject, arParameters); // для методов объекта
Собственно, роутинг в ASP.NET примерно так и работает.
Это вопрос не строгости типизации, а объёма хранимых метаданных. В языках вроде шарпа и джавы достаточно метаданных «из коробки», в каких-нибудь плюсах надо самостоятельно аннотировать, но в целом, как уже сказали, это можно сделать практически везде.
Да, кстати — а каким образом это ускоряет разработку?G-M-A-X
30.08.2016 12:17-1>Это вопрос не строгости типизации, а объёма хранимых метаданных.
Это вопрос динамичности — статичности.
В PHP метаданные хранить не нужно.
Есть Reflection* классы, которые возвращают нужную информацию.
Но я ими не пользуюсь :) И хз как они влияют на скорость.
А если хранить метаданные, то это дублирование кода. :)lair
30.08.2016 12:22+2Это вопрос динамичности — статичности.
Серьезно? И как же?
В PHP метаданные хранить не нужно. Есть Reflection* классы, которые возвращают нужную информацию.
… и откуда они ее берут?
А если хранить метаданные, то это дублирование кода.
Нет. Как вам показали выше на примерах из того же C#, никакого дублирования кода нет.
Alex_ME
26.08.2016 21:25+1Строго-типизированный код чуть более громоздкий, но куда более надежный, потому что многие ошибки находятся на этапе компиляции.
В универе писал курсач на Ruby — как же я научался с разными ошибками, когда я думал, что там один тип, а там другой. Отлаживать это без IDE было очень увлекательно.
G-M-A-X
27.08.2016 00:09+1На этапе компиляции отловим ошибки статически строго типизированного языка.
Язык может быть динамически строго типизированным (Ruby как раз такой, судя по ссылке ниже).
Эта компиляция должна еще быть. Может это интерпретируемый язык.
Ликбез по типизации:
https://habrahabr.ru/post/161205/Alex_ME
27.08.2016 00:14Да, вы правы.
В своем комментарии я имел в виду "статически строго типизированный компилируемый язык". Да, Ruby как раз кидал ошибки при попытке неверных преобразований.
grossws
27.08.2016 02:01на Ruby «gem install» и допольнительный код скачался и работает
Откройте для себя gem hell и его решение в виде bundler'а. Вообще за system-wide
gem installбьют канделябром. Больно и долго.
Как сравнить простоту построения отказоустойчивых распределённых сервисов на Erlang и ту же Java? Я думаю там тоже разница в количестве кода(багов и.т.п.) будет на порядок.
Достаточно вспомнить, что существуют библиотеки (и OTP по сути тоже является библиотекой). Взять akka и вперёд, воевать с использованием акторов. Паттерны обеспечения отказоусточивости в erlang и scala+akka будут отличаться не принципиальным образом.
youlose
27.08.2016 09:29-1«Откройте для себя gem hell и его решение в виде bundler'а. Вообще за system-wide gem install бьют канделябром. Больно и долго.»
Я это написал для примера, на самом деле во ВСЕХ своих проектах я использую bundler, но если надо написать на коленке что-то прямо сейчас или проверить функциональность какого либо gem'а, я делаю «gem install ...».
Про распределённые системы я всё же про императивную Java говорил и про количества кода и действий которые надо предпринять чтобы одну и ту же задачу решить.
Fen1kz
26.08.2016 16:50Очень жизненный диалог! Не про языки, конечно (тут логические ошибки и вообще хрень). А про то, как не надо отвечать менеджеру/начальнику которые решимости заменить 1 программиста на С++ на 5 фронтендщиков
olegchir
26.08.2016 18:13Измерять языки иселючительно метрикой механического упрощения работы — это как-то недавльновидно, что ли
Еще есть красота, культура, вот это всё
pengyou
26.08.2016 19:03-1Если двоичный машинный язык это нативный язык машин, и в целом, маш.коды (то есть слова) определяются архитектурой, не будет ли верным предположение о том, что язык для общения человека и машины должен учитывать не только архитектуру машины, но и архитектуру человека.
Кажется, не было ещё такого ЯП или парадигмы, в разработке которой участвовали психологи, нейрофизиологи, в общем те, кто шарит в архитектуре человека.
А то вот от скобочек фигурных (с самого их появления) многих людей тошнит. Функциональный стиль заходит в голову не всем.
Бизнесу это пофиг, архитекторам языков тоже пофиг («не нравится — не используй мой прекрасный язык с тройными скобочками»). Есть ли те, кому не всё равно?DrPass
26.08.2016 21:42+1> не будет ли верным предположение о том, что язык для общения человека и машины должен учитывать
> не только архитектуру машины, но и архитектуру человека.
Именно для этого вы имеете счастье созерцать всякие if, for, while и скобочки, вместо колоночек из 10001111011. Человеческое мышление по своей сути императивно, и подобные языки как раз идеально укладываются в стандартную архитектуру человека. Если вам не нравятся конкретно скобочки, возьмите себе язык с beginами и endами.
qrck13
26.08.2016 19:07+2Не знаю как на счет перехода с C++ на Java, но когда я на новом рабочем месте перешел с C++ на C#, который до этого вообще не знал (дали пару недель на освоение), то я почуствовал что ту-же самую работу на C# я могу делать как минимум в разы быстрее, чем на C++. Привыкнув к инструментам C# порой чуствуешь себя без рук, когда нужно вернуться в «старый добрый C++»… Не говоря уже о том, что разработка на C++ — это часто хотьба по минному полю, то тут то там что-то упадет (даже с использованием умных указателей и всех современных фишек такое случается), в то время как на C# я свой перый проект пару недель кодил вообще не запуская и не пытаясь собрать, потом нажал F5 — и оно практически сразу заработало!
Впрочем тут заслуга не только языка, но и среды. VS + ReSharper — творят чудеса в плане эффективной разработки. Но суть в том, что C++ сложнее поддается «решарпингу», и хотя он сейчас поддерживается решарпером, все равно не так эффективная помощь от ReSharper-а.qw1
28.08.2016 12:38Как по мне, высокая производительность программиста на C# объясняется тем, что у программиста меньше способов что-то сделать. Например, чтобы включить один объект в другой, можно просто объявить его полем объекта, можно объявить указатель, инициализируя его в конструкторе. Можно объявить умный указатель и т.д. То же самое с параметрами: как лучше на x86 передать параметр типа int64_t: как значение, или как константную ссылку? Ссылка займёт одно место в регистрах папаметров, а значение — два, ссылку можно также передать дальше в одном регистре, а значение опять займёт два. Обдумывание всех этих мелочей отнимает много времени при кодинге на с++.
qrck13
28.08.2016 12:55Очень вряд-ли. Опытный программист на любом языке имеет свои привычки как сделать то или иное, и об этом не думает. Не говоря уже о том, что на C# тоже много чего можно сделать 1000 и 1 способом. Те-же свойства (properties) можно обьявить тысячей способов.
qw1
28.08.2016 13:32Мне даже интересно стало, что это за 1000 способов.
Либо свойство без логики, и тогда это
string Name {get;set;},
либо с логикой и это
string Name {get { ...код... } set { ...код... } }qrck13
28.08.2016 13:431000 и 1 это конечно гипербола, но способов больше чем 2:
сначало было примерно так:
private string _field = ...;
public string Name { get { return _field; } set { _field = value; } }
потом стало можно сделать так:
public string Name { get; set; }
потом стало можно сделать так:
public string Name { get; set; } = ''Initial value'';
или например так, если это read-only property:
public string Name => ''Initial value'';
Еще из примеров того, что можно сделать кучей способов — много способов создать делегат.
Правда в случае с C# не возникает каких-либо проблем в том плане, что использовать, т.к. обычно речь идет о новом vs старом синтаксисе. Впрочем в том-же C++ тоже давно сложились стандартные практики в плане того как сделать ту или иную вещь, так что о таких мелочах на C++ — не приходится задумываться при разработке.
Время больше тратиться на отлавливание багов трудно-уловимых и на «парсинг» ошибок компилятора. Т.к. если C# скажет прямо — «у вас на строке такой-то какой-то бред», то сообщения о синтаксических ошибках, выдаваемые любым C++ компилятором, часто занимают экрана 3-4 чистым текстом на каждую ошибку, и порой их приходится долго «причесывать», пока не доберешся до сути сообщения
qw1
28.08.2016 13:44Если речь о
string Name => value;, то это синтаксический сахар и не влияет на производительность.
То есть, как короче, так и пишем, никаких размышлений о выборе варианта.
public string Name { get; set; } = «Initial value»;
И тут никаких размышлений — сахар, переносим инициализацию ближе к объявлению. Несомненно, это стоит сделать.
Другое дело c++ с его вечным вопросом — эти локальные данные разместить на стеке или в динамической памяти…
fogone
28.08.2016 13:10+1Очень странный диалог. Спрашивающий похож на тупого и наглого менеджера, который хочет поставить галочку в журнале напротив срока, а на остальное ему насрать. Отвечающий выглядит более компетентным, но отвечая на подобные вопросы цифрами очевидно взятыми с потолка очень сильно теряет в доверии к его словам. В итоге вся статья — это перевод разговора непонятно кого с непонятно кем в совершенно неприемлемом тоне и в совершенно дикой аргументацией (отсутствием оной) в ответах. Хотя, надо признать, что мысль о том, что современные языки плюс-минус равны в возможностях своей продуктивности — она кажется интуитивно верной, но давать вот такие процентные оценки по меньшей мере глупо, глупее только требовать их назвать.
Pilat
28.08.2016 14:05В статье куча оценок — «два часа», «в два раза», «5%» — но нет никаких обоснований этих оценок, что снижает их ценность до нуля. И так понятно, что на ассемблере писать проще чем в кодах, но зачем вытягивать конкретные цифры? Какое-то упражнение в риторике.
ploop
Вот интересно, даст ли экскаватор прирост в скорости разработки песочного домика? А детский совок в скорости разработки траншеи?
Я думал, давно ясно, что язык — инструмент, и для каждой задачи нужно выбирать наиболее эффективный.
DrPass
> Я думал, давно ясно, что язык — инструмент, и для каждой задачи нужно выбирать наиболее эффективный.
Так непонятно ведь, как выбрать наиболее эффективный. Вопрос, что выбирать под специализированные условия, особо не стоит, под STM32 вы скорее всего возьмете С, а под NAV вы будете писать на C/AL.
Вопрос становится острым в более общем случае, ведь многие из них конкурируют друг с другом в одной и той же области применения, да ещё каждый обильно сдобрен десятком конкурирующих фреймворков. Особенно это видно в вебе.
ploop
Допустим, языки, заточенные под веб появились после того, как появился веб, хотя и консольный калькулятор на них тоже можно написать, не так ли? :)
Однако, различия есть всегда. И всегда найдётся более подходящий. Факторы могут быть разные, начиная от опыта работы с ними конкретных исполнителей, заканчивая набором фреймворков.
DrPass
> И если задача возникает очень часто, то под ней делают специальный инструмент.
… или два специальных инструмента. Или десять.
> Однако, различия есть всегда
Есть, конечно. Но вот недавний жизненный пример из другой области: жена примеряет два платья, одно с широкими бретельками и светло-синее, другое чуть темнее и с узкими бретельками. Я прекрасно вижу, что они различны, но они решают одну и ту же задачу, цена у них схожая, и… что мне отвечать на вопрос жены: «Женя, какое из них _лучше_»?
А с инструментами разработки ведь то же самое. Даже двадцать лет назад можно было до изнеможения холиворить по поводу C++ vs Turbo Pascal при разработке практически любого десктопного приложения. А сейчас стало всё намного… разнообразней :)
Например, если хочу заказать веб-чего-нибудь, то мне какого разработчика искать, React JS или Angular? Или пусть по-старинке ручками на Bootstrap + jQuery?
ivann
Фреймворки дают задаче ещё одну степень свободы. Можно начинать дискутировать не только на тему JavaScript или Java, а на более сложную: JavaScript+Angular vs Java/Vaadin. Ваш выбор усложнился в разы.
Я думаю, что можно отойти назад и посмотреть не на производительность программистов, а на шанс успеха проекта. Сможем-ли мы найти нужного разработчика, столкнемся-ли мы с неожиданными проблемами? Большее удобство от фреймворка/языка может обернуться невозможностью расширения или критической проблемой, на фикс которой уйдут месяцы. А менее удобный, но проверенный рецепт позволит решить задачу быстрее.
Можно взять пример фирму PayPal, разработчики которой в 2013 году очень хвалили Node.JS, что технология позволила им ускорить время ответа сервера с 300 до 200 мс, что у них выросла производительность людей в два раза. https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ Сейчас в блоге посты про squbs (Scala). Логично предположить, что если бы Node.JS давал обещанную скорость реализации проекта, он был бы у них везде. Чисто по экономическим соображениям. Но они продолжают искать и пробовать новые инструменты и возвращаются к старым. Видно, что не так все радужно с Node.JS. Ускоряя что-то, теряешь в других местах.
Тут недавно был шутливый, но отчасти правдивый пост про Docker. С ним тоже возникает вопрос удешевляет-ли он на самом деле разработку и поддержку ПО. Статья хоть и была шутливая, но проблема в ней — реальная. Докер не всегда делает проекты успешнее и дешевле. О том сколько проблем он с собой приносит есть неплохой доклад Андрея Турецкого с Highload++: https://www.youtube.com/watch?v=UgUuF_qZmWc
ploop
Ну пусть будут несколько языков, заточенных под одну задачу, т.е. аналоги (как красный молоток и синий молоток). То есть выбирать по каким-то другим соображениям. Однако, по мере развития технологий, полюбому появятся новые задачи, требующие другого подхода, и понадобится уже новый инструмент. А в статье — типа всё, приплыли, остались на уровне «C++ vs Turbo Pascal».
Нет, не приплыли. Всё течёт, всё меняется, начиная от растущей работы с «большими данными», заканчивая грядущим ИИ…
FForth
Для STM32 (и для других контроллеров) есть ещё и варианты Форт языка, но они обычно вне рассмотрения.
grossws
Плюс традиционно C++, который не упомянули выше. Да и rust сейчас стремится, на cortex-m вполне себе работает.