Comments 119
Вот интересно, даст ли экскаватор прирост в скорости разработки песочного домика? А детский совок в скорости разработки траншеи?
Я думал, давно ясно, что язык — инструмент, и для каждой задачи нужно выбирать наиболее эффективный.
Я думал, давно ясно, что язык — инструмент, и для каждой задачи нужно выбирать наиболее эффективный.
> Я думал, давно ясно, что язык — инструмент, и для каждой задачи нужно выбирать наиболее эффективный.
Так непонятно ведь, как выбрать наиболее эффективный. Вопрос, что выбирать под специализированные условия, особо не стоит, под STM32 вы скорее всего возьмете С, а под NAV вы будете писать на C/AL.
Вопрос становится острым в более общем случае, ведь многие из них конкурируют друг с другом в одной и той же области применения, да ещё каждый обильно сдобрен десятком конкурирующих фреймворков. Особенно это видно в вебе.
Так непонятно ведь, как выбрать наиболее эффективный. Вопрос, что выбирать под специализированные условия, особо не стоит, под STM32 вы скорее всего возьмете С, а под NAV вы будете писать на C/AL.
Вопрос становится острым в более общем случае, ведь многие из них конкурируют друг с другом в одной и той же области применения, да ещё каждый обильно сдобрен десятком конкурирующих фреймворков. Особенно это видно в вебе.
Так непонятно ведь, как выбрать наиболее эффективныйВот есть задача. Её решают имеющимися средствами, и она решается, просто/нет не важно. И если задача возникает очень часто, то под ней делают специальный инструмент.
Допустим, языки, заточенные под веб появились после того, как появился веб, хотя и консольный калькулятор на них тоже можно написать, не так ли? :)
Вопрос становится острым в более общем случае, ведь многие из них конкурируют друг с другом в одной и той же области примененияОднако, различия есть всегда. И всегда найдётся более подходящий. Факторы могут быть разные, начиная от опыта работы с ними конкретных исполнителей, заканчивая набором фреймворков.
> И если задача возникает очень часто, то под ней делают специальный инструмент.
… или два специальных инструмента. Или десять.
> Однако, различия есть всегда
Есть, конечно. Но вот недавний жизненный пример из другой области: жена примеряет два платья, одно с широкими бретельками и светло-синее, другое чуть темнее и с узкими бретельками. Я прекрасно вижу, что они различны, но они решают одну и ту же задачу, цена у них схожая, и… что мне отвечать на вопрос жены: «Женя, какое из них _лучше_»?
А с инструментами разработки ведь то же самое. Даже двадцать лет назад можно было до изнеможения холиворить по поводу C++ vs Turbo Pascal при разработке практически любого десктопного приложения. А сейчас стало всё намного… разнообразней :)
Например, если хочу заказать веб-чего-нибудь, то мне какого разработчика искать, React JS или Angular? Или пусть по-старинке ручками на Bootstrap + jQuery?
… или два специальных инструмента. Или десять.
> Однако, различия есть всегда
Есть, конечно. Но вот недавний жизненный пример из другой области: жена примеряет два платья, одно с широкими бретельками и светло-синее, другое чуть темнее и с узкими бретельками. Я прекрасно вижу, что они различны, но они решают одну и ту же задачу, цена у них схожая, и… что мне отвечать на вопрос жены: «Женя, какое из них _лучше_»?
А с инструментами разработки ведь то же самое. Даже двадцать лет назад можно было до изнеможения холиворить по поводу C++ vs Turbo Pascal при разработке практически любого десктопного приложения. А сейчас стало всё намного… разнообразней :)
Например, если хочу заказать веб-чего-нибудь, то мне какого разработчика искать, React JS или Angular? Или пусть по-старинке ручками на Bootstrap + jQuery?
Фреймворки дают задаче ещё одну степень свободы. Можно начинать дискутировать не только на тему 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
Я прекрасно вижу, что они различны, но они решают одну и ту же задачу, цена у них схожая, и… что мне отвечать на вопрос жены: «Женя, какое из них _лучше_»?Аналогично, я в этом случае рандомно тыкаю на любое (правда с женщинами сложнее, последует вопрос "… а почему это не нравится?") :)
Ну пусть будут несколько языков, заточенных под одну задачу, т.е. аналоги (как красный молоток и синий молоток). То есть выбирать по каким-то другим соображениям. Однако, по мере развития технологий, полюбому появятся новые задачи, требующие другого подхода, и понадобится уже новый инструмент. А в статье — типа всё, приплыли, остались на уровне «C++ vs Turbo Pascal».
Нет, не приплыли. Всё течёт, всё меняется, начиная от растущей работы с «большими данными», заканчивая грядущим ИИ…
Для STM32 (и для других контроллеров) есть ещё и варианты Форт языка, но они обычно вне рассмотрения.
UFO just landed and posted this here
К тому же я бы посмотрел на создание сайта на C++.
Пожалуйста Диалог выбора файлов на Wt.
А я бы посмотрел бы на создание сайта на Python/Ruby/PHP без фреймворокв/CMS и фреймворков/библиотек JavaScript и без надстроек над CSS. К чему это? Со времен выхода "Мифического человека-месяца" самый дешевый и быстрый способ разработки: купить готовое, а не писать своё. Сейчас для быстрой скорости разработки во главе угла стоят фреймворки, библиотеки и другие готовые компоненты, а сам язык уходит на второй план.
>А я бы посмотрел бы на создание сайта на Python/Ruby/PHP без фреймворокв/CMS и фреймворков/библиотек JavaScript и без надстроек над CSS.
Лехко.
Это модники тянут разный мусор из фреймворков PHP/JS и надстроек над CSS.
А потом не знают как сделать элементарные вещи.
Да и скорость разработки на этом мусоре на самом деле не увеличивается, а цена растет.
>купить готовое, а не писать своё
Зачем покупать? Можно загнать в стойло соцсетей.
Многие вещи лучше купить, но есть много специфичных.
Лехко.
Это модники тянут разный мусор из фреймворков PHP/JS и надстроек над CSS.
А потом не знают как сделать элементарные вещи.
Да и скорость разработки на этом мусоре на самом деле не увеличивается, а цена растет.
>купить готовое, а не писать своё
Зачем покупать? Можно загнать в стойло соцсетей.
Многие вещи лучше купить, но есть много специфичных.
К тому же я бы посмотрел на создание сайта на C++.
На самом деле сайты делают. Проекты выдерживают огромные нагрузки и имеют очевидный недостаток, свободных программистов, которые реально умеют дорабатывать программы на С++ и ищут работу, тем более в веб отрасли — крайне мало. Может даже вернее сказать — их совсем нет.
http://cppcms.com/wikipp/ru/page/main
UFO just landed and posted this here
Исходя из контекста статьи, Вам стоит написать на сколько больше надо программистов на С++ по сравнению с pyton программистами.
UFO just landed and posted this here
Удивительная вещь. Написать игру (в том числе и сетевую) на С++, если игра критична к скорости обработки запросов от пользователей — это логично. Есть инструменты и способы тестирование ошибок.
А написать ядро сайта на С++ — это дороже и ошибок будет море. При чем ссылку я дал, cms на С++ есть, одна. Но то ли дело java, которую юзают почти на всех гос сайтах. Ошибки, конечно, бывают, но на С++ их было бы непременно больше. Сарказм, если что…
А написать ядро сайта на С++ — это дороже и ошибок будет море. При чем ссылку я дал, cms на С++ есть, одна. Но то ли дело java, которую юзают почти на всех гос сайтах. Ошибки, конечно, бывают, но на С++ их было бы непременно больше. Сарказм, если что…
UFO just landed and posted this here
А почему бы и не написать? Статическая типизация есть, нормальные плюсовые шаблоны для управления памятью в стандартную библиотеку ещё в C++11 вошли. Если человек не пришедший по объявлению птушник, а действительно умеет программировать, то проблем у него не возникнет. Производительность и прожорливость до памяти при этом будет меньше в разы. Так что если стоит задача сделать что-то, что обрабатывает миллионы запросов и развёрнуто на 10+ серверах, то использование C++ будет экономически оправданным решением.
> Так что если стоит задача сделать что-то, что обрабатывает миллионы запросов и развёрнуто на 10+ серверах,
> то использование C++ будет экономически оправданным решением.
Если речь идёт всё-таки о сайте, то скорее всего нет. Просто по той причине, что сам по себе инструментарий для хостинга подобных систем уже есть, и писать ещё один такой же (и годами отлаживать по-новой уже все пройденные грабли) точно нерационально. А если решать частную задачу по генерации HTML с помощью CGI-приложения на C++, то… зачем? Другие инструменты может быть и не быстрее сделают генерацию, но уж точно сделают быстрее сопровождение и развитие сайта.
> то использование C++ будет экономически оправданным решением.
Если речь идёт всё-таки о сайте, то скорее всего нет. Просто по той причине, что сам по себе инструментарий для хостинга подобных систем уже есть, и писать ещё один такой же (и годами отлаживать по-новой уже все пройденные грабли) точно нерационально. А если решать частную задачу по генерации HTML с помощью CGI-приложения на C++, то… зачем? Другие инструменты может быть и не быстрее сделают генерацию, но уж точно сделают быстрее сопровождение и развитие сайта.
Ну так есть же готовые фреймворки для плюсов. CPPSP тот же слабо отличим от классического аспнета.
Или POCO, охватывающая значительный диапазон абстракций. Если говорить про сеть — от тонкой прослойки над bsd sockets, через reactor и до HTTPServer, который предоставляет servlet-like API.
Да всё равно, тут же главный вопрос как раз «зачем?» Вот смотрите, приведенный вами CPPSP обновлялся два с половиной года назад. В ИТ это достаточный срок, чтобы предположить, что автор потерял к проекту интерес, и развития можно не ждать. Скачиваний у него немного, поэтому рассчитывать на проверку/отладку со стороны комьюнити тоже не приходится. Т.е. это такой себе кот в мешке, который непонятно какие грабли в себе несёт. Это уже заведомо хуже популярных инструментов, которые используются десятками, сотнями тысяч разработчиков.
Ну вон товарищ выше привёл регулярно обновляющийся фреймворк с возможностью коммерческой поддержки. Вы поймите, не все клепают сайты-визитки и моднявые SPA-приложения с посещаемостью < 100K человек в сутки. С ростом нагрузки стоимость работы программиста становится дешевле стоимости работы железа.
> С ростом нагрузки стоимость работы программиста становится дешевле стоимости работы железа.
А ещё с ростом нагрузки стоимость ошибок программиста и недостатков платформы становится намного выше. В качестве академических проектов — почему бы и нет, но я все равно склоняюсь к тому, что в коммерческом продакшене массовая платформа будет всяко лучше и надёжнее экзотической. Ну вот найдёте вы разработчика, который POCO изучил и использует, и он уговорит вас делать проект на POCO. Даже если и всё взлетит и заработает, но через год он уедет в США или еще куда-нибудь, и где вы будете искать второго такого же?
А ещё с ростом нагрузки стоимость ошибок программиста и недостатков платформы становится намного выше. В качестве академических проектов — почему бы и нет, но я все равно склоняюсь к тому, что в коммерческом продакшене массовая платформа будет всяко лучше и надёжнее экзотической. Ну вот найдёте вы разработчика, который POCO изучил и использует, и он уговорит вас делать проект на POCO. Даже если и всё взлетит и заработает, но через год он уедет в США или еще куда-нибудь, и где вы будете искать второго такого же?
UFO just landed and posted this here
Вот честно, ни разу в своей практике не напарывался на проблемы из-за UB. Оно обычно проявляется либо из-за нежелания читать стандарт языка, на котором пишешь, либо от от желания показать, что ты умнее компилятора.
Если так боитесь UB, возьмите свежий GCC и компилируйте с -Werror. У них там прямо из оптимизатора предупреждения выдаются о применении оптимизаций из-за UB.
Если так боитесь UB, возьмите свежий GCC и компилируйте с -Werror. У них там прямо из оптимизатора предупреждения выдаются о применении оптимизаций из-за UB.
UFO just landed and posted this here
А какую защиту предоставляет компилятор java, извините?
Видимо, имеется ввиду, что там сложнее при ошибке вместе с ногой отстрелить себе жизненно важные органы (словить heap corruption, например). Но при желании всё равно можно, да.
UFO just landed and posted this here
Быстро найти баг и исправить его очень помогают хорошие стектрейсы, которые не делает c++ (в Release он много инлайнит и выкидывает фреймы стека при любом подходящем случае).
> Тем более java показывает прекрасную производительность из-за JIT, а память нынче очень дешёвая
Как человек уже миллион лет работающий с продуктами на java, могу сказать, что проблема этой платформы для админов совсем не в памяти. Да действительно память дешевая, хотя и не настолько как это кажется разработчикам (бытовая память в вашем компьюетере иной раз на порядок дешевле, чем ECC в дорогом сервере).
Самая главная технологическая беда это GC. Как не крути ребус, какой алгоритм не выбирай, но на временном диапазоне в год и количестве инсталяции 100+, рано или поздно нарвешься на тормоза. И разумеется это произойдет в самый важный момент (отчетный период в банке или у провайдера, например), когда нагрузка велика.
Отягощают эту проблему манера писать у современных ява прогреров: зная что есть GC, они абсолютно безолаберно относятся к созданию сущностей. Христоматийный «хеллоу ворлд» из десятка класов хоть и гротеск, но хорошо отображает реальность. Практический на любое действие создают тысячи объектов в куче, которые уже через секунду-две не нужны.
Просто представте себе прием платяжей у провайдера с миллионной абонентской базой. Обработка платежа длится 30-40 ms, но за это время успевает создаться 30-50 объектов, которые почти тут же становятся не нужны. А рядом трудится написанный на C RADIOUS сервер, который глобально делает нечто очень похожее, но умудряется переиспользовать выделенные участки памяти и работать годами без сбоя без просадки производительности. Во многом эта ситуация завязана на излишне общие фреймворке, но все таки основа беды в культуре написания ПО.
Как человек уже миллион лет работающий с продуктами на java, могу сказать, что проблема этой платформы для админов совсем не в памяти. Да действительно память дешевая, хотя и не настолько как это кажется разработчикам (бытовая память в вашем компьюетере иной раз на порядок дешевле, чем ECC в дорогом сервере).
Самая главная технологическая беда это GC. Как не крути ребус, какой алгоритм не выбирай, но на временном диапазоне в год и количестве инсталяции 100+, рано или поздно нарвешься на тормоза. И разумеется это произойдет в самый важный момент (отчетный период в банке или у провайдера, например), когда нагрузка велика.
Отягощают эту проблему манера писать у современных ява прогреров: зная что есть GC, они абсолютно безолаберно относятся к созданию сущностей. Христоматийный «хеллоу ворлд» из десятка класов хоть и гротеск, но хорошо отображает реальность. Практический на любое действие создают тысячи объектов в куче, которые уже через секунду-две не нужны.
Просто представте себе прием платяжей у провайдера с миллионной абонентской базой. Обработка платежа длится 30-40 ms, но за это время успевает создаться 30-50 объектов, которые почти тут же становятся не нужны. А рядом трудится написанный на C RADIOUS сервер, который глобально делает нечто очень похожее, но умудряется переиспользовать выделенные участки памяти и работать годами без сбоя без просадки производительности. Во многом эта ситуация завязана на излишне общие фреймворке, но все таки основа беды в культуре написания ПО.
UFO just landed and posted this here
> GC это то, что хорошо видно на инструментах мониторинга при тормозах, но это не сама причина тормозов, так же как и те же вакуумы в версионных RDBMS.
Ну это очевидно, я собственно и не говорил, что сама по себе платформа плохая. Речь о том, что GC в сочетании со средним программистом это неприятно.
Про C/C++ все верно: сегфолтов там будет на порядок больше, чем NPE в java. Но тут, понимаешь, работает отрицательный отбор: средние прогеры на С не выживают именно из-за того, что их поделия сыпятся, а средние прогеры на Java могут делать вид, что они спецы очень долго.
Я очень хорошо понимаю, что отдебажить С++ упавший в продакшене крайне сложно. Но обычно в таком случае у меня был бородатый гуру, ну или просто толковый студент, который умудрялся найти ошибку относительно шустро. А вот когда система неожиданно упиралась в FullGC или просто работала заметно медленнее с вероятностью в 95% у меня был индусоподобный гражданин, который вообще не знает как Java машина устроена, которому я, с моими чисто админскими знаниями об этой штуке, буду долго объяснять что случилось.
Поэтому чисто статестически для меня GC это худшее что есть в Java. И где-то рядом с этим ад называемый deployment.
Ну это очевидно, я собственно и не говорил, что сама по себе платформа плохая. Речь о том, что GC в сочетании со средним программистом это неприятно.
Про C/C++ все верно: сегфолтов там будет на порядок больше, чем NPE в java. Но тут, понимаешь, работает отрицательный отбор: средние прогеры на С не выживают именно из-за того, что их поделия сыпятся, а средние прогеры на Java могут делать вид, что они спецы очень долго.
Я очень хорошо понимаю, что отдебажить С++ упавший в продакшене крайне сложно. Но обычно в таком случае у меня был бородатый гуру, ну или просто толковый студент, который умудрялся найти ошибку относительно шустро. А вот когда система неожиданно упиралась в FullGC или просто работала заметно медленнее с вероятностью в 95% у меня был индусоподобный гражданин, который вообще не знает как Java машина устроена, которому я, с моими чисто админскими знаниями об этой штуке, буду долго объяснять что случилось.
Поэтому чисто статестически для меня GC это худшее что есть в Java. И где-то рядом с этим ад называемый deployment.
Не уверен, что приложения на С удобнее деплоить, чем джавовые. Там же своих приколов хватает с версиями библиотек, "немного другим ядром" ОС и все такое.
Там все более менее линейно: либо статическая линковка, тогда вообще нет проблем, либо динамика, но админы с ней очень хорошо знакомы и понимают как это работает. Да и стандарт в ентерпрайзе нынче один: RHEL и его клоны.
А в java, во-первых, может быть много деплоеров с разной логикой и нюансами. Например spring. Особенно забавно смотреть на случай одновременного использования спринга и штатного для аппликейшен сервера загрузщика. Или вообще свой деплоеер. Редко, но бывает.
Во-вторых, может быть много чисто физически разных форматов: jar, war, spring или что-нибудь кастомное, которые как-то сочетаются с первым пунктом. Бывает сложно разобраться а в какой же последовательности это все загружается. Совсем недавно я был вынужден использоваться deployment.xml в котором было написано, что для все файлов начинающихся с superproject, сначала надо загрузить spring, потом jar, потом war, но немного с другим именем :)
В-третьих, java девелоперы имеют очень плохую тенденцию тянуть много сторонних библиотек, которые не совместимы сами с собой. Например Axis умудряется изменить api в минорных версиях, что требует доработки своего кода, а иногда вам нужно два аксиса разных версий, которые притянулись как зависимости, но вы не всегда этого можете добиться (в частности на такой каке как jboss или как она там сейчас называется) и тогда вообще беда.
А в java, во-первых, может быть много деплоеров с разной логикой и нюансами. Например spring. Особенно забавно смотреть на случай одновременного использования спринга и штатного для аппликейшен сервера загрузщика. Или вообще свой деплоеер. Редко, но бывает.
Во-вторых, может быть много чисто физически разных форматов: jar, war, spring или что-нибудь кастомное, которые как-то сочетаются с первым пунктом. Бывает сложно разобраться а в какой же последовательности это все загружается. Совсем недавно я был вынужден использоваться deployment.xml в котором было написано, что для все файлов начинающихся с superproject, сначала надо загрузить spring, потом jar, потом war, но немного с другим именем :)
В-третьих, java девелоперы имеют очень плохую тенденцию тянуть много сторонних библиотек, которые не совместимы сами с собой. Например Axis умудряется изменить api в минорных версиях, что требует доработки своего кода, а иногда вам нужно два аксиса разных версий, которые притянулись как зависимости, но вы не всегда этого можете добиться (в частности на такой каке как jboss или как она там сейчас называется) и тогда вообще беда.
UFO just landed and posted this here
Посмотрел я на сайт этой «cms»… шедевральный бенчмарк: http://cppcms.com/wikipp/en/page/benchmarks_all… просто за гранью добра и зла…
PS за сам сайт тоже убивать надо — какого фига использовать такой маленький шрифт, да ещё ограничиваться узкой колонкой — не понятно…
PPS в общем хорошо заниматься, тем что умеешь, а вот что не умеешь — может лучше не трогать?
PS за сам сайт тоже убивать надо — какого фига использовать такой маленький шрифт, да ещё ограничиваться узкой колонкой — не понятно…
PPS в общем хорошо заниматься, тем что умеешь, а вот что не умеешь — может лучше не трогать?
Вконтакте использует С и PHP.
Мы в универе и на ассемблере сайт писали, хех. Ну как, в основном на С++ через CGI (делали сервис обработки ачивментов для нашего сервере Counter-Strike, странички можно было смотреть во внутриигровом браузере, это было еще до выхода Source и нативной поддержки ачивок в большинстве игр), но поскольку параллельно у нас шел курс ассемблера, то мы какие-то полезные куски кода выдирали прямо из курсовика.
Ничего сложного в общем, хотя конечно велосипедить побольше приходилось, да с утечками памяти бороться.
Так что теперь я честно могу свысока поглядывать на всяких там пхпшников и любителей прочих языков и гордо заявлять, что настоящие отцы пишут веб на ассемблере.
Ничего сложного в общем, хотя конечно велосипедить побольше приходилось, да с утечками памяти бороться.
Так что теперь я честно могу свысока поглядывать на всяких там пхпшников и любителей прочих языков и гордо заявлять, что настоящие отцы пишут веб на ассемблере.
К тому же я бы посмотрел на создание сайта на C++.Вот очень злая в плане производительности штука, предоставляющая примерно тот же инструментарий, что ASP.NET WebForms, а по бенчмаркам производительности рвёт вообще практически все существующие решения.
К тому же я бы посмотрел на создание сайта на C++
Ну, сходите посмотрите на Facebook или Google. В формировании того, что вы увидите на этих сайтах, задействована огромная куча кода на С++.
> Иными словами, символьный ассемблер позволяет одному программисту выполнять работу десяти программистов, работающих в двоичном коде?
Десять программистов не сделают работу в десять раз быстрее, чем один программист, даже если говорить об одном и том же языке. Примерно на трети текста стало не интересно, я не настолько зануда.
Десять программистов не сделают работу в десять раз быстрее, чем один программист, даже если говорить об одном и том же языке. Примерно на трети текста стало не интересно, я не настолько зануда.
Девять женщин не смогут родить ребёнка за месяц.
Во! У вас ещё лучше пример нашёлся. Когда столь серьёзная логическая ошибка в самом начале обсуждения, то все последующие выводы основаны на ложной информации. Собственно, потому и стало не интересно читать.
Думаю тут имеется ввиду, что 1 программист ASM сделает 10 задач за то же время, что 10 программистов двоичного кода каждый свою
Тут дело не в выводах, а в каком-то маникальном и идиотском упорстве спрашивающего, который не ответы слушает, а хочет узнать число, хотя ему несколько раз поясняют, что число разное для разных ситуаций.
В реальности, я бы такого вопрошающего, послал бы после 3-4 вопроса, но видимо программист попался терпеливый.
В реальности, я бы такого вопрошающего, послал бы после 3-4 вопроса, но видимо программист попался терпеливый.
В статье, участник, задающий вопросы, сводил все не к срокам, а трудозатратам на произвольное X программистов. То есть, 9 женщин родят 9 детей за 9 месяцев, а одна женщина — нет. В одном проекте 9 программистов не напишут одну программу за месяц, но напишут 9 независимых программ за 9 месяцев.
Да даже если не оперировать толпами программистов. Один программист на сях напишет программу, которую силами любого кол-ва программистов в машинном коде написать невозможно.
А что им помешает?
Для каждого языка программирования есть порог сложности разрабатываемой на нем программы, после которого становится практически невозможно добавлять новые фичи и поддерживать этот проект. Я бы предположил, исходя из своего опыта, что этот предел подчиняется нормальному распределению, где по оси y находится сложность проекта, а по оси x располагается мощность языка в толковании Пола Грэма.
Видимо, важнее, не то, сколь сильно влияет язык на процесс разработки, а то, сколь сильно языки могут влиять на головы программистов, на стиль их решений, на общий подход к проблемам, а дальше, видимо, на весь мыслительный процесс (и вне работы тоже). А значит, тут мы наблюдаем борьбу мемов по Докинзу, только среди формальных систем.
Плюс в теме много факторов не-технического характера, особенно в бизнесе, которые влияют на языки и на их отбор (отрицательный, к сожалению). Так что в разговоре с самим собой автор героически себе поддался, рассмотрев только вершину айсберга. И кто его знает, может, это из-за самоуверенности, которая вызвана знанием какого-нибудь очень крутого ЯП для очень умных очень профессионалов.
Так что, разница есть, она огромна, и война за Грааль тут вполне оправдана. А то ваших детушек заставят писать на js так безальтернативно, что без добрых корпораций с v8 наперевес детушки уже не смогут вообще ничего. А как им смочь, откуда взяться пониманию? То-то же. Борьба мемов приводит к отбору генов, а если кто-то говорит иначе — не слушайте, он просто защищает свои мемы.
Плюс в теме много факторов не-технического характера, особенно в бизнесе, которые влияют на языки и на их отбор (отрицательный, к сожалению). Так что в разговоре с самим собой автор героически себе поддался, рассмотрев только вершину айсберга. И кто его знает, может, это из-за самоуверенности, которая вызвана знанием какого-нибудь очень крутого ЯП для очень умных очень профессионалов.
Так что, разница есть, она огромна, и война за Грааль тут вполне оправдана. А то ваших детушек заставят писать на js так безальтернативно, что без добрых корпораций с v8 наперевес детушки уже не смогут вообще ничего. А как им смочь, откуда взяться пониманию? То-то же. Борьба мемов приводит к отбору генов, а если кто-то говорит иначе — не слушайте, он просто защищает свои мемы.
Спрашивающий — какой-то придурок, упорно требующий количественные показатели там, где их быть не может по определению. Отвечающий вроде бы сначала сделал слабую попытку это объяснить, но затем видимо заразился идиотизмом и стал на эти вопросы отвечать конкретными цифрами, причём в какой-то момент уже стал открыто брать их с потолка. Феерически бесполезный диалог.
На машинном коде не возможно разработать современное веб-приложение. Не «сложно», а «невозможно». Потому что в какой-то момент 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. Ещё не до конца, но всё более и более. Слои абстракций, каждый из которых всё менее машинный код и всё более — комфортная среда для разработки. Отказ от этой среды — предложение пойти и написать самому.
Если переводить это в язык машинного кода, то нужно будет написать полностью 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. Ещё не до конца, но всё более и более. Слои абстракций, каждый из которых всё менее машинный код и всё более — комфортная среда для разработки. Отказ от этой среды — предложение пойти и написать самому.
Вполне логично, слоёв абстракции *просто стало существенно больше. Даже появление и чуть позже массовое использование микропрограмм в 50-60х годах уже сильно увеличило производительность работы программистов, предоставив ISA.
В современном мире системный-то программист не полезет ниже уровня ISA (даже если бы у него был бы доступ), равно и прикладной в большинстве случаев не полезет на уровень ассемблера и ОС.
Ну отчего же сразу «невозможно»? При должной упоротости можно сделать транслятор с машинных кодов в js. Хотя это, конечно, все равно оторвано от реальности.
Сайт может работать без какого либо JS, аргумент непонятен.
Если есть функциональные требования, такие как сделать аналог «моих аудиозаписей» из вконтакта, без js их не выполнить.
Сделайте, пожалуйста, «без какого-либо JS» сайт, на котором на карте можно просматривать трек для хайкинга с зумом, индикатором высоты и фильтром для POI вдоль трека.
Это вам не хипстерские котики, это deadly serious приложение. И оно на JS.
Это вам не хипстерские котики, это deadly serious приложение. И оно на JS.
Мне сейчас вспомнился очень ёмкий язык APL, и мне очень жаль что в C++ (не знаю как в C#) нет столь же ёмких конструкций для работы с матрицами и массивами.
Сравнение Java с Ruby в принципе неадекватное, почему только компилирование учли? Почему не учли что на Java на на порядок больше кода писать, а чем больше кода тем больше багов, которые тоже нужно покрывать тестами и/или дебажить?
А если код не только писать, но и изменять, тут у строгой типизации вообще веселье начинается. Не стало хватать разрядности в каком-то месте? Извольте изменить 100500 других мест которые с этим местом связаны. Изменился формат входных данных? Начинай плодить абстракции и/или опять танцы с изменением типов повсюду начинаются.
А инструменты? Подключить модуль через какой-нибудь maven, это целое приключение с xml конфигами, а на Ruby «gem install» и допольнительный код скачался и работает.
А если учесть что у некоторых языков какие-то конкретные решения более проработаны, чем у других, то сравнить вообще ничего не получится. Как сравнить простоту построения отказоустойчивых распределённых сервисов на Erlang и ту же Java? Я думаю там тоже разница в количестве кода(багов и.т.п.) будет на порядок.
А если код не только писать, но и изменять, тут у строгой типизации вообще веселье начинается. Не стало хватать разрядности в каком-то месте? Извольте изменить 100500 других мест которые с этим местом связаны. Изменился формат входных данных? Начинай плодить абстракции и/или опять танцы с изменением типов повсюду начинаются.
А инструменты? Подключить модуль через какой-нибудь maven, это целое приключение с xml конфигами, а на Ruby «gem install» и допольнительный код скачался и работает.
А если учесть что у некоторых языков какие-то конкретные решения более проработаны, чем у других, то сравнить вообще ничего не получится. Как сравнить простоту построения отказоустойчивых распределённых сервисов на Erlang и ту же Java? Я думаю там тоже разница в количестве кода(багов и.т.п.) будет на порядок.
> Сравнение Java с Ruby в принципе неадекватное, почему только компилирование учли? Почему не учли что на Java на на порядок больше кода писать, а чем больше кода тем больше багов, которые тоже нужно покрывать тестами и/или дебажить?
А если код не только писать, но и изменять, тут у строгой типизации вообще веселье начинается. Не стало хватать разрядности в каком-то месте? Извольте изменить 100500 других мест которые с этим местом связаны. Изменился формат входных данных? Начинай плодить абстракции и/или опять танцы с изменением типов повсюду начинаются.
Автору до вас куда как далеко. Поклонники perl и конкурсов типа 1k рукоплещут! Да и я, почему-то, всегда думал, что тестами покрывают осмысленные куски кода… На javadoc тесты писать будете? Строгая типизация как раз спасает от лишних багов. В общем если вы что-то не умеете, не стоит это заранее хаять.
> А инструменты? Подключить модуль через какой-нибудь maven, это целое приключение с xml конфигами, а на Ruby «gem install» и допольнительный код скачался и работает.
Модуль в мавен подключается к конкретному проекту… это позволяет неплохо рулить зависимостями. В современной IDE это задача укладывается в 3-10 секунд. Что конкретно делает ваш gem install?
В общем или вы потеряли тег сарказм или просто не разбирается в java…
А если код не только писать, но и изменять, тут у строгой типизации вообще веселье начинается. Не стало хватать разрядности в каком-то месте? Извольте изменить 100500 других мест которые с этим местом связаны. Изменился формат входных данных? Начинай плодить абстракции и/или опять танцы с изменением типов повсюду начинаются.
Автору до вас куда как далеко. Поклонники perl и конкурсов типа 1k рукоплещут! Да и я, почему-то, всегда думал, что тестами покрывают осмысленные куски кода… На javadoc тесты писать будете? Строгая типизация как раз спасает от лишних багов. В общем если вы что-то не умеете, не стоит это заранее хаять.
> А инструменты? Подключить модуль через какой-нибудь maven, это целое приключение с xml конфигами, а на Ruby «gem install» и допольнительный код скачался и работает.
Модуль в мавен подключается к конкретному проекту… это позволяет неплохо рулить зависимостями. В современной IDE это задача укладывается в 3-10 секунд. Что конкретно делает ваш gem install?
В общем или вы потеряли тег сарказм или просто не разбирается в java…
Да и я, почему-то, всегда думал, что тестами покрывают осмысленные куски кода…
Я и не писал обратного. А на баги вы тесты не пишете?
В общем если вы что-то не умеете, не стоит это заранее хаять.
Зачем переходить на личности, если вы можете рассказать как этого избежать, например?
Про maven я посмотрю завтра.
И да в Java я очень слабо разбираюсь (просто наблюдал за мучениями коллег), но внятно разбираюсь в C++ и сейчас чуть-чуть пописываю на Golang. Давайте разберёмся вместе, что же я неправильно написал выше.
Я и не писал обратного. А на баги вы тесты не пишете?
В общем если вы что-то не умеете, не стоит это заранее хаять.
Зачем переходить на личности, если вы можете рассказать как этого избежать, например?
Про maven я посмотрю завтра.
И да в Java я очень слабо разбираюсь (просто наблюдал за мучениями коллег), но внятно разбираюсь в C++ и сейчас чуть-чуть пописываю на Golang. Давайте разберёмся вместе, что же я неправильно написал выше.
> Я и не писал обратного. А на баги вы тесты не пишете?
Зависит от проекта (в некоторых время на тесты не выделяется, к сожалению), но в любом случае тестами покрывается логика/алгоритм/контракт/как угодно ещё назовите — суть в том, что от «многословности» java здесь нет проблем, она не вынуждает писать дополнительные тесты на пустом месте.
Так и не нашёл перехода на личности (а вот мою гипотезу вы подтвердили… ). Ну что же, вы писали о проблемах — напишите примеры, которые покажут эти проблемы, а я постараюсь объяснить, насколько они реалистичны и как в Java можно жить не имея таких проблем.
PS мавен — это не то, что требуется делать каждый день, но зависимости туда добавляются легко. Пляски с бубном начинаются только если вы хотите изменить билд-процесс.
Зависит от проекта (в некоторых время на тесты не выделяется, к сожалению), но в любом случае тестами покрывается логика/алгоритм/контракт/как угодно ещё назовите — суть в том, что от «многословности» java здесь нет проблем, она не вынуждает писать дополнительные тесты на пустом месте.
Так и не нашёл перехода на личности (а вот мою гипотезу вы подтвердили… ). Ну что же, вы писали о проблемах — напишите примеры, которые покажут эти проблемы, а я постараюсь объяснить, насколько они реалистичны и как в Java можно жить не имея таких проблем.
PS мавен — это не то, что требуется делать каждый день, но зависимости туда добавляются легко. Пляски с бубном начинаются только если вы хотите изменить билд-процесс.
«суть в том, что от «многословности» java здесь нет проблем, она не вынуждает писать дополнительные тесты на пустом месте.»
«Многословность» — это больше циклов, ветвлений, необходимость реализовывать какие-то лишние простейшие алгоритмы на пустом месте (в том же Ruby очень богатая std библиотека, среди остальных подобных языков с динамической типизацией, там можно графы топологически отсортировать из коробки TSort ) и.т.п. Всё это было бы неплохо тестами покрыть. И эти тесты сложнее чем подать nil вместо некоторых аргументов, чтобы потом в коде привести их к нужному виду и часто больше никаких дополнительных тестов не надо.
«напишите примеры, которые покажут эти проблемы, а я постараюсь объяснить, насколько они реалистичны и как в Java можно жить не имея таких проблем.»
С примерами мне надо подумать, попробую позже что-то выдать, вам я предлагаю тоже дать пример где мне придётся 100500 лишних тестов написать на Ruby для какой-то задачи (ну или где строгая типизация ускоряет написание кода, а слабая замедляет и мы сравним подходы, ибо мне и самому очень интересно).
«PS мавен — это не то, что требуется делать каждый день»
Я с этим согласен, но это создаёт жуткие неудобства новичкам и там они тратят огромное количество времени и нервов (я это видел на примере 2х джунов).
«Что конкретно делает ваш gem install?»
Он загружает и делает доступным глобально модуль из центрального репозитория rubygems. Это используется когда надо быстро что-то сделать или проверить. К maven ближе будет рубёвый bundler, который ставит модули глобально, но позволяет использовать конкретные версии модулей для конкретных проектов.
«Многословность» — это больше циклов, ветвлений, необходимость реализовывать какие-то лишние простейшие алгоритмы на пустом месте (в том же Ruby очень богатая std библиотека, среди остальных подобных языков с динамической типизацией, там можно графы топологически отсортировать из коробки TSort ) и.т.п. Всё это было бы неплохо тестами покрыть. И эти тесты сложнее чем подать nil вместо некоторых аргументов, чтобы потом в коде привести их к нужному виду и часто больше никаких дополнительных тестов не надо.
«напишите примеры, которые покажут эти проблемы, а я постараюсь объяснить, насколько они реалистичны и как в Java можно жить не имея таких проблем.»
С примерами мне надо подумать, попробую позже что-то выдать, вам я предлагаю тоже дать пример где мне придётся 100500 лишних тестов написать на Ruby для какой-то задачи (ну или где строгая типизация ускоряет написание кода, а слабая замедляет и мы сравним подходы, ибо мне и самому очень интересно).
«PS мавен — это не то, что требуется делать каждый день»
Я с этим согласен, но это создаёт жуткие неудобства новичкам и там они тратят огромное количество времени и нервов (я это видел на примере 2х джунов).
«Что конкретно делает ваш gem install?»
Он загружает и делает доступным глобально модуль из центрального репозитория rubygems. Это используется когда надо быстро что-то сделать или проверить. К maven ближе будет рубёвый bundler, который ставит модули глобально, но позволяет использовать конкретные версии модулей для конкретных проектов.
> это больше циклов, ветвлений, необходимость реализовывать какие-то лишние простейшие алгоритмы на пустом месте
примеры «больше циклов ветвлений» в студию. Насчёт топологической сортировки и каких-то других «простейших алгоритмов» не уверен, но даже если это не включено в jdk, то с высокой вероятностью это можно найти в какой-нибудь библиотеке. Не вижу проблемы.
> вам я предлагаю тоже дать пример где мне придётся 100500 лишних тестов написать на Ruby для какой-то задачи (ну или где строгая типизация ускоряет написание кода, а слабая замедляет и мы сравним подходы, ибо мне и самому очень интересно).
Хм… видимо меня память подводит? Не могу найти, где я говорил, что в Ruby придётся писать лишние тесты. А строгая типизация не ускоряет (в самом банальном смысле) написание кода, всего лишь предотвращает проблемы, которые могут возникнуть либо при автоконвертации типов (с этим в java тоже возможны небольшие косяки, но их спектр — меньше), либо при получении неизвестного типа (при желании — в Java на это тоже можно нарваться, но для этого придётся сильно постараться… впрочем можно просто использовать java<1.5). Для проверки же, что в нужном месте нужный тип приходит… интеграционные же тесты придётся применять, вместо unit?! Сомнительное удовольствие… так что больше тестов писать не придётся — придётся в рантайме получать бомбу…
> Я с этим согласен, но это создаёт жуткие неудобства новичкам и там они тратят огромное количество времени и нервов (я это видел на примере 2х джунов).
Джунов на глобальные изменения помника ставить не стоит. Просто не стоит. Простой помник ещё можно доверить джуну… но лучше всё-таки подождать, пока он будет на грани мидла (а то и готовым мидлом) и дать 2-3 дня на глубокое осмысление мавена. В дальнейшем проблем быть уже не должно. Проблемы же возникают из-за непонимания и «с бору по сосенке» собранного опыта.
> Он загружает и делает доступным глобально модуль из центрального репозитория rubygems. Это используется когда надо быстро что-то сделать или проверить. К maven ближе будет рубёвый bundler, который ставит модули глобально, но позволяет использовать конкретные версии модулей для конкретных проектов.
Так зачем же вы сравнили геминсталл с мавеном, раз это настолько разные вещи? И я рад, искренне рад, что в Java нет глобальных модулей и библиотеки нужные «глобально» нужно ставить руками… Меньше шансов на косяки, больше вероятность найти проблему, если всё-таки случилась беда. Впрочем ожидаемая фича «модульности» может привезти эти самые глобальные модули в мир Java, только они же сделают мир Java готовым к такой беде… Впрочем никакого отношения к системе сборки это не имеет.
примеры «больше циклов ветвлений» в студию. Насчёт топологической сортировки и каких-то других «простейших алгоритмов» не уверен, но даже если это не включено в jdk, то с высокой вероятностью это можно найти в какой-нибудь библиотеке. Не вижу проблемы.
> вам я предлагаю тоже дать пример где мне придётся 100500 лишних тестов написать на Ruby для какой-то задачи (ну или где строгая типизация ускоряет написание кода, а слабая замедляет и мы сравним подходы, ибо мне и самому очень интересно).
Хм… видимо меня память подводит? Не могу найти, где я говорил, что в Ruby придётся писать лишние тесты. А строгая типизация не ускоряет (в самом банальном смысле) написание кода, всего лишь предотвращает проблемы, которые могут возникнуть либо при автоконвертации типов (с этим в java тоже возможны небольшие косяки, но их спектр — меньше), либо при получении неизвестного типа (при желании — в Java на это тоже можно нарваться, но для этого придётся сильно постараться… впрочем можно просто использовать java<1.5). Для проверки же, что в нужном месте нужный тип приходит… интеграционные же тесты придётся применять, вместо unit?! Сомнительное удовольствие… так что больше тестов писать не придётся — придётся в рантайме получать бомбу…
> Я с этим согласен, но это создаёт жуткие неудобства новичкам и там они тратят огромное количество времени и нервов (я это видел на примере 2х джунов).
Джунов на глобальные изменения помника ставить не стоит. Просто не стоит. Простой помник ещё можно доверить джуну… но лучше всё-таки подождать, пока он будет на грани мидла (а то и готовым мидлом) и дать 2-3 дня на глубокое осмысление мавена. В дальнейшем проблем быть уже не должно. Проблемы же возникают из-за непонимания и «с бору по сосенке» собранного опыта.
> Он загружает и делает доступным глобально модуль из центрального репозитория rubygems. Это используется когда надо быстро что-то сделать или проверить. К maven ближе будет рубёвый bundler, который ставит модули глобально, но позволяет использовать конкретные версии модулей для конкретных проектов.
Так зачем же вы сравнили геминсталл с мавеном, раз это настолько разные вещи? И я рад, искренне рад, что в Java нет глобальных модулей и библиотеки нужные «глобально» нужно ставить руками… Меньше шансов на косяки, больше вероятность найти проблему, если всё-таки случилась беда. Впрочем ожидаемая фича «модульности» может привезти эти самые глобальные модули в мир Java, только они же сделают мир Java готовым к такой беде… Впрочем никакого отношения к системе сборки это не имеет.
> А если код не только писать, но и изменять, тут у строгой типизации вообще веселье начинается.
А уж какое веселье у динамической, когда у тебя ломается что-то, и интерпретатор тебе даже не может рассказать, что у него и когда сломалось. Ну нет у него этой информации.
Зато недопрограммисту мозг включать не пришлось.
А уж какое веселье у динамической, когда у тебя ломается что-то, и интерпретатор тебе даже не может рассказать, что у него и когда сломалось. Ну нет у него этой информации.
Зато недопрограммисту мозг включать не пришлось.
Я вам рекомендую всё же углубиться в какой либо язык с нестрогой типизацией, такие проблемы крайне редки, особенно если стараться писать в функциональном стиле и соблюдать принцип SRP. Ну а в командах где с одним и тем же кодом работают большое количество программистов надо пытаться добиться полного покрытия тестами. Лично я с подобным давно не сталкивался. И в таком случае скорее всего будет runtime error, которую исправить в разы быстрее и проще чем на Java. А ещё есть шанс что при неверных входящих данных программа на языке с нестрогой типизацией отработает нормально (или ошибочно но продолжит работу), а вот со строгой типизацией скорее всего придётся изучать страшный segfault.
Ну и ваш снобизм не оправдан, недопрограммисты есть во всех сообществах(и для всех технологий) и думаю что в количественном соотношении цифры сопоставимы (хотя в более трендовых языках и технологиях их больше всех).
Ну и ваш снобизм не оправдан, недопрограммисты есть во всех сообществах(и для всех технологий) и думаю что в количественном соотношении цифры сопоставимы (хотя в более трендовых языках и технологиях их больше всех).
ошибочно но продолжит работу
Я всегда считал, что это самый великий ужас программиста.
Впрочем, если уж совсем честно, "продолжит работу" vs "сегфолт" — это не от типизации зависит, а от того, как сделана обработка ошибок.
Я с вами согласен, и я не сказал что так надо, но так бывает в чужих проектах и диву даёшься что какой-то говнокод работает годами принимая на вход что попало и не ломаясь.
А про обработку ошибок всё то же самое и языков с слабой типизацией подходит.
А про обработку ошибок всё то же самое и языков с слабой типизацией подходит.
А про обработку ошибок всё то же самое и языков с слабой типизацией подходит.
Вот я и говорю: фраза "при неверных входящих данных программа на языке с нестрогой типизацией отработает нормально (или ошибочно но продолжит работу), а вот со строгой типизацией скорее всего придётся изучать страшный segfault" некорректна.
При раздолбайском подходе к обработке ошибок вполне корректна, а если учесть что большинство проектов в вебе (не уверен где брать статистику по энтерпрайз разработке, но там где я с ней встречался говнокода и раздолбайства тоже было достаточно) написано именно с таким подходом (больше половины сайтов написаны на WP, например), то можно сказать что моё утверждение чаще корректно, чем нет.
При раздолбайском подходе к обработке ошибок вполне корректна
Почему бы? Как обработка ошибок зависит от типизации языка?
(а в вебе все известные мне фреймворки, написанные на статически-типизированных языках не устраивают никакого сегфолта — который вообще не связан с типизацией, кстати, а связан с управлением памятью — а просто убивают обработку реквеста, а приложение продолжает работать)
ошибочно но продолжит работу
Я всегда считал, что это самый великий ужас программиста.
Точно!
Мне сразу PHP вспомнился, который до победного будет делать любую ерунду, но скрипт не упадет! :)
Я по долгу работы, как разработчик полного цикла, несколько лет писал на жс и пхп. Поначалу тоже считал, что строгая типизация только мешает, а рантайм ошибки правятся быстрее ошибок компиляции. В какой-то момент углубления стало достаточно, чтобы понять, что продолжение работы на неверных данных — худшее, что может случиться с приложением, а низкий порог вхождения естественным образом ведёт к отсутствию архитектуры, размыванию ответственностей и прочим нехорошим вещам.
Ушёл три года назад в микрософтовский стек. Первый месяц было тяжеловато, потом постиг красоту жёстко структурированного кода и на лапшу, которой пользовался раньше, смотреть тошно — начиная от множества ошибок, которые в том же шарпе сделать невозможно, и как раз тем вот «надо изменить в тысяче мест», заканчивая тем, что и инструменты с таким подходом делаются и работают абы как. Да, можно и на том же жсе писать с соблюдением солида и прочих канонов — тогда разработка будет ничуть не быстрее, чем на статических технологиях, но их плюсов не будет и в помине.
А недопрограммистов в таком полу-энтерпрайзе, кстати, значительно меньше. Не выживают, знаете ли.
Ушёл три года назад в микрософтовский стек. Первый месяц было тяжеловато, потом постиг красоту жёстко структурированного кода и на лапшу, которой пользовался раньше, смотреть тошно — начиная от множества ошибок, которые в том же шарпе сделать невозможно, и как раз тем вот «надо изменить в тысяче мест», заканчивая тем, что и инструменты с таким подходом делаются и работают абы как. Да, можно и на том же жсе писать с соблюдением солида и прочих канонов — тогда разработка будет ничуть не быстрее, чем на статических технологиях, но их плюсов не будет и в помине.
А недопрограммистов в таком полу-энтерпрайзе, кстати, значительно меньше. Не выживают, знаете ли.
В большинстве случаев со слабой динамической типизацией нету проблем.
Приводите параметры к общему типу вручную, если хотите.
PHP как бы позволяет указать параметры какого типа принимает функция.
Приводите параметры к общему типу вручную, если хотите.
PHP как бы позволяет указать параметры какого типа принимает функция.
Но зачем вставлять квадратное в круглое, если можно взять нормальный ЯП?
Потому что на динамическом разрабатывать/дебажить быстрее?
На основе каких исследований вы делаете такой вывод?
Разрабатывать — возможно (и то не во всех ситуациях), дебажить и поддерживать — точно нет.
А в статических языках есть типа такое:
call_user_func_array($dynamyc_function_name, $arParams); (PHP)
?
То есть на момент компиляции не известно имя функции, а только во время исполнения.
call_user_func_array($dynamyc_function_name, $arParams); (PHP)
?
То есть на момент компиляции не известно имя функции, а только во время исполнения.
Реализации этого механизма различны, но в общем случае есть практически везде. Другое дело, что это синтаксический сахар, который бессмысленно рассматривать оторванным от контекста, где это полезно использовать.
Как правило, имя функции известно на момент компиляции.
Но вместо того, чтобы хранить имена функций в строках (
Но вместо того, чтобы хранить имена функций в строках (
array(1 => 'doNewDoc', 2 => 'doEditDoc')), лучше хранить их так, чтобы утилиты рефакторинга при переименовании функции смогли всё корректно сделатьvar d = new Dictionary<int,Action> { { 1, () => doNewDoc() }, { 2, () => doEditDoc() } };Например, на шарпе:
Собственно, роутинг в ASP.NET примерно так и работает.
Это вопрос не строгости типизации, а объёма хранимых метаданных. В языках вроде шарпа и джавы достаточно метаданных «из коробки», в каких-нибудь плюсах надо самостоятельно аннотировать, но в целом, как уже сказали, это можно сделать практически везде.
Да, кстати — а каким образом это ускоряет разработку?
typeof(ClassWithFunctions).GetMethod(dynamicFunctionName).Invoke(null, arParameters); // для статических методов
typeof(calleeObject).GetMethod(dynamicFunctionName).Invoke(calleeObject, arParameters); // для методов объекта
Собственно, роутинг в ASP.NET примерно так и работает.
Это вопрос не строгости типизации, а объёма хранимых метаданных. В языках вроде шарпа и джавы достаточно метаданных «из коробки», в каких-нибудь плюсах надо самостоятельно аннотировать, но в целом, как уже сказали, это можно сделать практически везде.
Да, кстати — а каким образом это ускоряет разработку?
typeof(calleeObject)Все-таки, calleeObject.GetType().
>Это вопрос не строгости типизации, а объёма хранимых метаданных.
Это вопрос динамичности — статичности.
В PHP метаданные хранить не нужно.
Есть Reflection* классы, которые возвращают нужную информацию.
Но я ими не пользуюсь :) И хз как они влияют на скорость.
А если хранить метаданные, то это дублирование кода. :)
Это вопрос динамичности — статичности.
В PHP метаданные хранить не нужно.
Есть Reflection* классы, которые возвращают нужную информацию.
Но я ими не пользуюсь :) И хз как они влияют на скорость.
А если хранить метаданные, то это дублирование кода. :)
Это вопрос динамичности — статичности.
Серьезно? И как же?
В PHP метаданные хранить не нужно. Есть Reflection* классы, которые возвращают нужную информацию.
… и откуда они ее берут?
А если хранить метаданные, то это дублирование кода.
Нет. Как вам показали выше на примерах из того же C#, никакого дублирования кода нет.
Строго-типизированный код чуть более громоздкий, но куда более надежный, потому что многие ошибки находятся на этапе компиляции.
В универе писал курсач на Ruby — как же я научался с разными ошибками, когда я думал, что там один тип, а там другой. Отлаживать это без IDE было очень увлекательно.
на Ruby «gem install» и допольнительный код скачался и работает
Откройте для себя gem hell и его решение в виде bundler'а. Вообще за system-wide gem install бьют канделябром. Больно и долго.
Как сравнить простоту построения отказоустойчивых распределённых сервисов на Erlang и ту же Java? Я думаю там тоже разница в количестве кода(багов и.т.п.) будет на порядок.
Достаточно вспомнить, что существуют библиотеки (и OTP по сути тоже является библиотекой). Взять akka и вперёд, воевать с использованием акторов. Паттерны обеспечения отказоусточивости в erlang и scala+akka будут отличаться не принципиальным образом.
«Откройте для себя gem hell и его решение в виде bundler'а. Вообще за system-wide gem install бьют канделябром. Больно и долго.»
Я это написал для примера, на самом деле во ВСЕХ своих проектах я использую bundler, но если надо написать на коленке что-то прямо сейчас или проверить функциональность какого либо gem'а, я делаю «gem install ...».
Про распределённые системы я всё же про императивную Java говорил и про количества кода и действий которые надо предпринять чтобы одну и ту же задачу решить.
Я это написал для примера, на самом деле во ВСЕХ своих проектах я использую bundler, но если надо написать на коленке что-то прямо сейчас или проверить функциональность какого либо gem'а, я делаю «gem install ...».
Про распределённые системы я всё же про императивную Java говорил и про количества кода и действий которые надо предпринять чтобы одну и ту же задачу решить.
Очень жизненный диалог! Не про языки, конечно (тут логические ошибки и вообще хрень). А про то, как не надо отвечать менеджеру/начальнику которые решимости заменить 1 программиста на С++ на 5 фронтендщиков
UFO just landed and posted this here
Измерять языки иселючительно метрикой механического упрощения работы — это как-то недавльновидно, что ли
Еще есть красота, культура, вот это всё
Еще есть красота, культура, вот это всё
Если двоичный машинный язык это нативный язык машин, и в целом, маш.коды (то есть слова) определяются архитектурой, не будет ли верным предположение о том, что язык для общения человека и машины должен учитывать не только архитектуру машины, но и архитектуру человека.
Кажется, не было ещё такого ЯП или парадигмы, в разработке которой участвовали психологи, нейрофизиологи, в общем те, кто шарит в архитектуре человека.
А то вот от скобочек фигурных (с самого их появления) многих людей тошнит. Функциональный стиль заходит в голову не всем.
Бизнесу это пофиг, архитекторам языков тоже пофиг («не нравится — не используй мой прекрасный язык с тройными скобочками»). Есть ли те, кому не всё равно?
Кажется, не было ещё такого ЯП или парадигмы, в разработке которой участвовали психологи, нейрофизиологи, в общем те, кто шарит в архитектуре человека.
А то вот от скобочек фигурных (с самого их появления) многих людей тошнит. Функциональный стиль заходит в голову не всем.
Бизнесу это пофиг, архитекторам языков тоже пофиг («не нравится — не используй мой прекрасный язык с тройными скобочками»). Есть ли те, кому не всё равно?
> не будет ли верным предположение о том, что язык для общения человека и машины должен учитывать
> не только архитектуру машины, но и архитектуру человека.
Именно для этого вы имеете счастье созерцать всякие if, for, while и скобочки, вместо колоночек из 10001111011. Человеческое мышление по своей сути императивно, и подобные языки как раз идеально укладываются в стандартную архитектуру человека. Если вам не нравятся конкретно скобочки, возьмите себе язык с beginами и endами.
> не только архитектуру машины, но и архитектуру человека.
Именно для этого вы имеете счастье созерцать всякие if, for, while и скобочки, вместо колоночек из 10001111011. Человеческое мышление по своей сути императивно, и подобные языки как раз идеально укладываются в стандартную архитектуру человека. Если вам не нравятся конкретно скобочки, возьмите себе язык с beginами и endами.
Не знаю как на счет перехода с C++ на Java, но когда я на новом рабочем месте перешел с C++ на C#, который до этого вообще не знал (дали пару недель на освоение), то я почуствовал что ту-же самую работу на C# я могу делать как минимум в разы быстрее, чем на C++. Привыкнув к инструментам C# порой чуствуешь себя без рук, когда нужно вернуться в «старый добрый C++»… Не говоря уже о том, что разработка на C++ — это часто хотьба по минному полю, то тут то там что-то упадет (даже с использованием умных указателей и всех современных фишек такое случается), в то время как на C# я свой перый проект пару недель кодил вообще не запуская и не пытаясь собрать, потом нажал F5 — и оно практически сразу заработало!
Впрочем тут заслуга не только языка, но и среды. VS + ReSharper — творят чудеса в плане эффективной разработки. Но суть в том, что C++ сложнее поддается «решарпингу», и хотя он сейчас поддерживается решарпером, все равно не так эффективная помощь от ReSharper-а.
Впрочем тут заслуга не только языка, но и среды. VS + ReSharper — творят чудеса в плане эффективной разработки. Но суть в том, что C++ сложнее поддается «решарпингу», и хотя он сейчас поддерживается решарпером, все равно не так эффективная помощь от ReSharper-а.
Как по мне, высокая производительность программиста на C# объясняется тем, что у программиста меньше способов что-то сделать. Например, чтобы включить один объект в другой, можно просто объявить его полем объекта, можно объявить указатель, инициализируя его в конструкторе. Можно объявить умный указатель и т.д. То же самое с параметрами: как лучше на x86 передать параметр типа int64_t: как значение, или как константную ссылку? Ссылка займёт одно место в регистрах папаметров, а значение — два, ссылку можно также передать дальше в одном регистре, а значение опять займёт два. Обдумывание всех этих мелочей отнимает много времени при кодинге на с++.
Очень вряд-ли. Опытный программист на любом языке имеет свои привычки как сделать то или иное, и об этом не думает. Не говоря уже о том, что на C# тоже много чего можно сделать 1000 и 1 способом. Те-же свойства (properties) можно обьявить тысячей способов.
Мне даже интересно стало, что это за 1000 способов.
Либо свойство без логики, и тогда это
либо с логикой и это
Либо свойство без логики, и тогда это
string Name {get;set;},либо с логикой и это
string Name {get { ...код... } set { ...код... } }1000 и 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 чистым текстом на каждую ошибку, и порой их приходится долго «причесывать», пока не доберешся до сути сообщения
сначало было примерно так:
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 чистым текстом на каждую ошибку, и порой их приходится долго «причесывать», пока не доберешся до сути сообщения
Если речь о
То есть, как короче, так и пишем, никаких размышлений о выборе варианта.
И тут никаких размышлений — сахар, переносим инициализацию ближе к объявлению. Несомненно, это стоит сделать.
Другое дело c++ с его вечным вопросом — эти локальные данные разместить на стеке или в динамической памяти…
string Name => value;, то это синтаксический сахар и не влияет на производительность.То есть, как короче, так и пишем, никаких размышлений о выборе варианта.
public string Name { get; set; } = «Initial value»;
И тут никаких размышлений — сахар, переносим инициализацию ближе к объявлению. Несомненно, это стоит сделать.
Другое дело c++ с его вечным вопросом — эти локальные данные разместить на стеке или в динамической памяти…
Очень странный диалог. Спрашивающий похож на тупого и наглого менеджера, который хочет поставить галочку в журнале напротив срока, а на остальное ему насрать. Отвечающий выглядит более компетентным, но отвечая на подобные вопросы цифрами очевидно взятыми с потолка очень сильно теряет в доверии к его словам. В итоге вся статья — это перевод разговора непонятно кого с непонятно кем в совершенно неприемлемом тоне и в совершенно дикой аргументацией (отсутствием оной) в ответах. Хотя, надо признать, что мысль о том, что современные языки плюс-минус равны в возможностях своей продуктивности — она кажется интуитивно верной, но давать вот такие процентные оценки по меньшей мере глупо, глупее только требовать их назвать.
В статье куча оценок — «два часа», «в два раза», «5%» — но нет никаких обоснований этих оценок, что снижает их ценность до нуля. И так понятно, что на ассемблере писать проще чем в кодах, но зачем вытягивать конкретные цифры? Какое-то упражнение в риторике.
Когда-то шутили, мол, скоро будем программировать мышкой. Потом шутка стала несколько ближе к реальности, когда появился Flash 5. И программист стал немного художником и аниматором или наоборот.
Interactive: The Top Programming Languages 2018
spectrum.ieee.org/static/interactive-the-top-programming-languages-2018
spectrum.ieee.org/static/interactive-the-top-programming-languages-2018
В описанном диалоге неявно делается очень смелое и совершенное неверное допущение, что все оцениваемые программисты идентичны по своему опыту и возможностям разработки, после чего на неверном исходном тезисе строится все остальное сравнение. В реальности же программисты, во-первых, неравны, во-вторых, их постоянно не хватает, в-третьих, это означает, что имеется огромное количество мало / среднеквалифицированных программистов. При этом бизнесу нужны проекты, которые рассчитаны на высокую квалификацию, а такого количества программистов с нужной квалификацией просто нет. Соответственно, что? Соответственно, создаются инструменты, которые позволяют программистам принимать участие в проектах «не по опыту» Строгая типизация, сборщики мусора, константные объекты по умолчанию и т.д. — это все как раз дает такую возможность, т.к. у программиста уменьшается количество вариантов, где он может накосячить, а если уж накосячил, то легче найти, где именно.
Sign up to leave a comment.
Синий. Нет! Жёлтый! — или — Дают ли новые языки программирования прирост скорости разработки