Пока, список моих потребностей, в части поддержки тех-же wsdl, xsd, xml, orm на уровне, на котором мне это требуется что бы решать быстро и легко практические задачи — и попытка прояснить а как же дела с этим в гоу — говорит что дела у гоу с этим «никак».
Как вы предлагаете мне приятно удивиться?
Вы говорите ледит на поверхности? на поверхности вон по wsdl например — лежит пакет goWsdl (спасибо камраду за ссылку). но из описания пакета, я понял, что в сравнении с тем, что умеет в этой части джава — goWsdl это дешевая студенческая поделка. Где генерация wsdl, где xsd 1.1, где сериализация и десериализация в код через аннотации?
Извините, не хочу я тратить время на изучение очередного изделия. Таких изделий каждый день -десятками плодится — на всех жизни не напасешься ознакамливаться. Надоело, если честно.
Если от идеологов нет ответов на конкретные вопросы — значит изучать уже никто не будет. И аргумент мол на поверхности, сразу найдете ответы — во первых не катит, потому что то что поверхности уже не впечатляет, а во вторых — это просто гнилой маркетинговый подход, согласитесь. Не буду я тратить время на изучение кота в мешке.
Особенно, плохо звучит такой ответ (начните изучать и будете приятно удивлены, вместо конкретного ответа) — если сравнить такой ответ с ситуацией, когда я спрашиваю у мастодонтов джавы «что есть в джаве для этого?» — мне говорят конкретный набор буков и я иду гуглить этот пакет или технологию.
парой пос ов пиже, я описал вполне конкретные вопросы и ситуации про вебсервисы, wsdl и soap. у вас есть что ответить? и да, ответ я много раз отвечал — тоже гнилой ответ. отвечали — дайте ссылку, сделайте фак и ссылайтесь на него. но не отсылайте в никуда)
К тому, что интерес к языку либо академический, либо практический.
Посмаковать синтаксический сахар на досуге — это прекрасно.
Но я описываю интерес практический. и я прошу оппоннта ответить на эти вопросы хотя бы самому себе.
Как язык поддерживает те или иные технологии, и что имено означает эта «поддержка».
В частности, к прмеру — была заявлена поддержка вебсервисов.
Я начинаю «разбираться» — описываю кейсы (рабочие ситуации) и проблемы с которыми мы столкнулись в жизни, с примерами «провала кейса» на «других модных языках».
Что бы узнать, как именно обстоят дела в части «поддержки всех этих букв» в сабжевом языке.
На самом деле, вероятный ответ я уже знаю, но мне важно, что бы оппонент осознал что, заявленная «поддержка буков» на ко оруб ор сослался — это филькина грамота, мало общего имеющая с потребностями в части «поддержки указанных буков»за пределами академической среды.
Хотя, остается шанс, что я не прав, и я буду приятно удивлен.
Увы, но такое впечатление, что очень многие идеологи новомодных языков и их последователи как правило мало подкованы в технической части и практике применения IT в жизни. Для них сложный код — это сложная курсовая. для них важнее запилит красивую модную фичу в язык, а не обеспечить 100% ьбратную совместимость. Их понимание того, что такое технология и как она применяется — толькь пара лежащих на поверхности случаев, причем о проверке валидности структур и об обработке ошибок и исключерий — они и не слышали, или даже хуже — сознательно выпилили это из языка.
Первое чему приходится учить стажера — это критический взгляд, и умение строить зашиту от дурака в своем коде/системе. Подавляющее число технологий на новомодных языках — не серьезны, и крайне плохо обрабатывают проблемные ситуации. Пример с руби сервером который падает на 5 потоках запросов — очень характерен для идеалистических выходцев из академической среды в розовых очках. Или для хипстоты.
Другая причина почему я это все говорю — надежда, что сегодняшний «свидетель гоу/руби/питона/хацкеля», погрущившись в детали технической части и сравнительный анализ возможностей языков — начнет изучать нечто более серьезное, и будет смотреть на вещи более критично. Для этого, имзо, достаточно просто ответить на вопросы которые я задаю. Только честно. Хотя бы самому себе )))
Адекватных инженеров очень мало.
Когда-то, мне перла для веб — вполне хватало. Для дипломной работы. Но потом был пхп, дельфи, си++, джава… Задали бы мне пяток таких вопросов в свое время…
а будущим авторам статей (самим авторам и переводчикам тоже) типа «про прекрасное гоу»: предлагаю: вместо заявлений, типа вот гоу такой хороший — описали бы ниши, и как ниже хорошо в одном посте сказали — кейсы применения описали с конкретными параметрами, и задачами, вместо того, что бы разводить «какой то рекламный буллшит».
гоу — как я сейчас понимаю нишевый язык. очень нишевый. с, судя по всему, очень особенной поддержкой, которую устраивает текущее состояние, при котором многих бесят некоторые недофичи языка (ссылаюсь на статью «50 оттенков гоу»).
Так вот и опишите эти ниши. Конкретно. С техническии деталями и подробностями.
Так вы завоюете больше последователей. Мне вот все равно на чем писать на проекте — надо было -мы на сишарпе «прокси» с интерфейсом на вебсервисах для доступа с андроида к доксвижену сделали. Хотя сам я джаву люблю — но надо — ращобрались и сделали.) есть на Qt проекты. Будем понимать нишу гоу — почему бы на гоу не продать пару проектов — но нужны конкретные примеры с тех подробностями. Я вот не буду разбираться в интимных откровениях и проблемах недо-языков за свой счет — мне бы сделать бизнес-задачу, что бы клиент был доволен))) А гоу пока не ложится ну никак супротив джавы, имхо. и не будет ложиться, пока будут дешевые переводные статьия с рекламным буллшитом, вместо сухих технических данных и статистики с плюсами и минусами. когда мы инструменты для проекта выбираем — надо профиль понимать, и риски минимизировать.
… а вместо этого — половина сторонников гоу, в комментариях выше и ниже только радостными воплями разрождаются про то, как им понравилось, и какой экстаз они испытали… да плевать на это. глубоко плевать, извините) Факты давайте.
а как именно «поддерживает»? вы эту «поддержку» с джавовским стеком сравнивали?
давайте по порядку: первое — кодогенератор по ссылке — это клиентская часть или серверная?
если серверная, то для какой серверной платформы или какого сервера приложений ?(такое понятие в гоу есть?)
я к чему — управление ресурсами в этом сервере есть? пул потоков, скажем? А то, знаете, видели мы тут недавеча «супер сервер». на руби писанный. Когда ему 5 потоков запросов в параллель пускаешь… он… падает. Понимаете, Карл,… падает!!! Не выдает 5хх-й код, не закрывает соединение с месседжем типа — превышены ресурсы, и продолжает работать, как это делает практически любой сервер приложений для всеми ненавидимой джавы… а просто падает.
Как в гоу решается вопрос управления русурсом подключений? Так же, как в руби на том сервере?)))
Ладно. Следующий вопрос: где генератор wsdl по коду? обратный, так сказать, генератор? я могу написать структуры, массивы, определить их обязательность или не очень, функции… а она мне — по моему коду — и wsdl, и опубликованный сервис на сервере и сразу подключайся-не-хочу… умеет? почему джава и сишарп (мать его))) — умеют, а гоу… для вебсервисов ориентированный, все поддерживающий — … умеет?
Теперь следующий вопрос: xml schema 1.1 — где? А то нам тут АТ-К прислали файлики как-то раз… так мы их едва открыли… кстати, не wsdl прислали, а xsd.
xds..., да, а что у нас с xsd? Что с валидацией xml, на соответствие xsd?
Что, с сериализацией/десериализацией xml? Есть в «красивом синтаксисе гоу» аналог джавовских аннотаций? Есть возможность просто «промаркировать» поля структуры xpath-ами — и отдать структуру в некую «фабрику», а на выходе — получить xml-заданной структуры? ну не охота мне руками раскладывать поля по элементам xml…
Что с ОРМ? Могу я в «аннотациях структур» гоу описать какое поле в какой таблице в какой колонке лежать? И что бы была просто фабрика, которой, подсовываешь струтуры, а она сама тебе и базу данных перестроит, и сохранение-восстановление сделает? и что бы мне — только одну строчку над каждым полем прямо в классе прописать. можно так в гоу? или только gowsdl пакет, который, судя по всему, упадет если ему на вход подать не корректную структуру?
и я ещё много могу рассказать чего у вас в вашем распрекрасном гоу нету, что есть в ненавидимой хопстотой «джаве-йе-йе».
…
просто я к чему? гоу, насколько я могу сейчас судить, находится на уровне технологичности джавы 1 или 2. аннотации, вон, и «рефлекшен» в какой джаве появиоись? в третьей кажется, поправьте? какой это год? начало 2000-х? вот и гоу сейчас — примерно на этом уровне готовности для «промышленной разработки». Играйтесь конечно, но прошу, давайте не портить пространство воплями типа «большой код», все умеет, вебсервисы… вы видели «большой код»? сколько читающих этот пост хотя бы знает о «монструозности» стека приложений «ibm websphere»? а «рейшионал»? вы пытались писать систему которая должна хранить ваши данные 75 лет после вашей смерти? Эта «простая задача» сейчас решается в пенсионке. На джаве и майфреймах ibm. Ну смешно же выглядят сказки про «большой код» на гоу, на фоне достаточно примитивного набора возможностей языка. Ну серьезно, народ)))) Не ведитесь.
Да, в нем есть, вероятно прикольные фичи типа горутин (так и не понял из статьи, что эта за фигня, кстати) — но это не делает картины на фоне провала по всем остальным фронтам. Не может сделать, извините.
В пхп вон тоже поддержка wsdl есть. и причем на уровне более серьезном, чем это единственное поделие «gowsdl»… только что с этого?..
а что именно под «вебсервисами» вы понимаете? для меня вебсервисы описываются в .wsdl, работаю я с ними с использованием soap, а http — это только один из транспортов, причем не самый идеальный.
Это вебсервисы, потому что это они описываются в спецификациях с соответствующими названиями.
Если открыть википедию, то там как раз о wsdl/soap/xml и говорится.
А что для вас «вебсервисы»? о каких именно вебсервисах вы говорите, о которых «все» (кто эти все?) знают? — можете обозначить назвария технологий, номера специфицаций и стандарты, которыми описываются ваши «вебсервисы»?
для каких именно «вебсервисов» предназначен этот язык?
Вот именно о задачах, которым соответствует описываемый язык — в статье нет ни слова. Не о чем делать аналитические заключения. Статья — реклама, рассчитанная на восторженного наивного, не отягощенного практикой новичка. Потому и "срач". Имхо.
Вы, вместо громогласных заявлений, ответили бы для начала хотя бы на часть вопросов.
Рубисты/питонисты говорили точно так. Но нет, подташнивает. А ещё, все знают об "успехах" рубистов на проекте в росреестре. Сданый вовремя проект, довольный заказчик, коммерческий успех компании подрядчика, безоблачные перспективы команды проекта… ага...
Следующие свои проекты, особенно после прочтения статьи "50 оттенков го", я буду писать на java. Как и последние несколько лет.
Простите, пропустил, с просонок ту часть, где говорится по синтаксис в части обратной совместимости.
Обратная совместимость не только стабильностью синтаксиса гарантируется. В джаве вон синтаксис меняется, но обратная 100% совсестимость остается. То, что гугль заморозил синтаксис, это может быть и хорошо, но что с базовыми библиотеками? Или будет как в си? (через 5 лет, на другой платформе, теоретически, собрать софтину можно, но вот половины библиотек уже нет или они просто не перенесены на эту платформу? да и разрядность уже поменялась, потому вылазят нулл-поинеры да сег-фолты?)
Что у языка с кроссплатформенностью?
И повторюсь: не увидел, даже после перепросмотра статьи производственных задач, которые решаеются языком у тех или иных вендоров! Или вы как «свидетели руби» — обосновывают выбор руби для сложного «иниерпрайз» проекта с ЖЦ длительностью лет 10 тем, что «там-то оно используется» — а когда выясняешь как именно используется — выясняется что там 5-и строчники-скриптики для тестирования оборудования на нем пишут?)))
Задам свой любимый вопрос: а что там с обратной совместимостью?
Код написанный на го, будет хотя бы собираться в новых версиях компилитора хотя бы через 3-5 лет? я молчу про такую «ынтерпрайзную роскошь», как «работать точно так же»…
Или будет как с руби? (гугль выпутит новую, улучшенную версию языка, не совместимую с предыдущей, и через 2 года снимет старую с поддержки, со словами, мол, " мы скорбим, что до сих пор ещё много проектов не смогли перейти на новую версию, из-за проблем с перерабокой исх. кода, но мы все-таки снимаем старую версию с поддержки. (читаем между строк: «Мы плевать хотели на ваши проблемы. Это ваши проблемы, трудоемкость и деньги. А мы будем дальше делать наш красивый язык, ибо нас волнует только красота нашего поделия.»)?
Ещё, во всей статье, так и не нашел позиционирования языка. Под какие задачи он заточен? Какой сдк и библиотеки под него есть?
Ещё вопрос, как разработчика с 20 годами стажа, которого, вопреки заявленному в статье тезису, никогда не сводили с ума новые языки, которого эта череда «новых откровений» банально достала: зачем нужен ваш язык, если всё, что нам надо, мы прекрасно делаем на уже существующих технологиях: java, javascript, с/с++? кто то еще вспомнит про си-диез (простите, не люблю я его — но и ладно..., живет и даже что ть полезное можно на на нем делать)… кто то вспомнит про питон ( скажу — «остыньте, уже не модно»), руби ( «и вы пойдете на свалку моды»), хацкель (подмигну -ну ты понял, посмтри на питон и руби)… Но чем го отличается от этого разношерстного безобразия? Это нишевый язык или общего назначения?
Да, вы проводите какие, весьма спорные, сравнения, очень пахнущие глубоким субъективизмом, картинки рисуете. Говорите про какую-то понятность… Но вот я так и не понял — это замена питону или башу в скриптах инициализации линукса?
Это скриптовый язык с возможностью компиляции и возможностью использовать .dll/.so? Или это легкое нечто которое позволяет набросать что то на коленке типа мини утилиты? Или это нечто для веб, компилируемое и мегашустрое в обработке мегатонн микро-запросов?.. Ведь нечто большое, мега-интерпрайзное этот язык, как сложилось впечатление, в силу отсутствия ооп -банально не потянет (в си же вон от структур и пакетов к ооп перещли?.. зачем, не понятно, наверное… но си, сегодня, остался, видимо, только при программировании микроконтроллеров...). Или го — это замены простому си, пригодному для програмирования микроконтроллеров?
Какие прикладные пакеты есть в го?(кодогенератор веб сервис-клиента из .wsdl-файла есть? Я могу тестовый скриптик типа как для junit набросать? А к базе данных могу подключиться? jdbc-драйвера он понимает? Нет? а odbc?) Какие средства для управления GUI есть? я могу его интегрировать с Qt? нет? а какие средства есть для воддержки веб-интерфейса? Поддержка вебсокетов есть?
Эти, и ещё полсотни других влпросов я могу задать, и не остановиться, потому, что есть еще много за этой полсотней…
Не должен я учить го. Не вижу я в этой статье, чем го отличается от мегасотен других «откровений». Извините.
Зачем мне писать что то серьезное на го, если никто не гарантирует, что завтра они не выкинут такой же финт как руби? или как питон не выпустят новую версию, на которой старый код не работает?
А если не серьезное — то что тогда писать? как этот язык поможет улучшить жизнь моему бизнес-заказчику? какие проблемы я могу на нем решать? плевать на синтаксис ( хотя, нет, не плевать — за отступы-табы-проблемы в питоне надо «бить в голову с ноги»)))))(шутка)) но как этот язык облегчит мне жизнь?
>>Насколько мне известно, для серьёзных бизнес-задач серьёзные конторы используют специализированные языки, вроде SAP ABAP
«Бизнес-задачи» бывают разные. «Бизнес-задачи» — это не только то, чем занимается «коммерция» и «бизнес».
Не путайте конкретные учетные задачи, на которые заточены компоненты SAP и задачи автоматизации бизнес-процессов.
Например АСУТП писать на SAP — это надо сильно удариться головой.
Не стоит писать систему реального времени контроля за грузоперевозками в масштабе страны на SAP. Можно, но в здравом уме это никто делать не будет. Потому там майнфреймы IBM, DB2, Java.
А вот бухгалтерию и зарплату под объемы РЖД — самое дело — SAP там лег как родной) (а на самом деле просто потому, что 1С не тянул эти объемы).
ABAP хорош только в контексте учетных механизмов SAP, а как сам язык, сужу по отзывам — не очень катит супротив даже 1С.
ABAP — конкурент 1С, а не Java/С++…
гм… «основной язык для описания бизнес-приложений», если это можно так назвать. ibm-ы традиционно выделяют отдельный процессор специально под задачи джавы. (я говорю про айбиэмовские майнфреймы, потому, что иные производители, куда-то исчезли)
в нашей стране я видел следующее: нашу с вами пенсию учитывают, грузовыми жд-перевозками по стране управляют, банковские платежи в цб обрабатывают.
ps: это такой тролинг, или вы серьезно не в курсе «области применения на майнфреймах»? давайте обсудим.
В современном мире это должно делаться автоматическим рефакторингом.
Эээ… а что вы имеете в виду под «автоматическим рефакторингом» в контексте языков с динамической типизацией? руби же, кажется, язык с динамической типизаицей?
Как уже было упомянуто, нет методов провести автоматический рефакторинг кода для языка с динамической типизацией — потому, что вы не можете узнать, что именно вам подсунут в значение переменной до момента рантайма и сработает у вас обращение к измененному методу или нет. Это не говоря о ситуации, когда у вас функция вызывается в нескольких местах, и вам подсовывают разные типы в один параметр.
Весь рефакторинг кода при динамической типизации — это смесь ручного труда и обработки баг-репортов после того как у вас не прошел очередной тест.
А когда у вас большой продукт — ручной рефакторинг с масштабным тестрованием — это ОЧЕНЬ серьезная проблема. Иногда даже проще написать продукт с нуля. На языках со статической типизацией. джаве/сиДиезе/паскале/сиПлюсПлюс — там, где автоматический рефакторинг возможен.
Если не развивается, то какая вам разница, что там поломали в версии Y? Пользуйтесь версией X
«Нельзя пользоваться версией X, потому что она снимается с поддержки» => никаких исправлений ошбок, заплаток для безопасности, никакой линии техподдержки и ответов производителя по вашим багам.
ну я же говорил, что меня надо поправить:
* не 1.8, а 1.8.7
* не 2.0 а «1.9.3, которую постепенно вытеснит ветка Ruby 2.0».
* не 2.5 года, а почти 5 лет.
так, что это не наезд, а констатация типовых проблем. это мы еще дотнет 3.5 и дотнет4 не обсуждали.
весь старый код, который я пробовал с новой версией интерпретатора, продолжал работать.
вам крупно повезло, имхо. а большой ли был проект, сколько человек и как долго писали, часто ли перерабатывали?
я же не говорю что проблемы будут гарантированно. вернее они будут почти гарантированно только при большом объеме кода, но на маленьких скриптах, это почти не заметно, и даже не факт что вы наступите на то, что поломали создатели языка.
Я не согласен с утверждением, что языки появляются потому, что к ЯП предъявляются требования. Далеко не всегда.
Возьмем историю C#. В следствии каких требований появился этот язык?
в следствии одного единственного, и не к языку, а вообще: майкрософту нужен был конкурент джаве. Не больше, ни меньше. Им плевать на ваши требования к языку. «Чисто бизнес, ничего личного». Они бы джаву использовали, но в своё время их за попытку создать несовместимую с эталонной реализацию языка джава — жестоко пои… наказали юристы Sun
Или — в следствии какого требования в Питоне невидимые символы стали использоваться не только как разделители? это не требование к языку, это спорное решение его создателя, попытка навесить на язык функции, ему не свойственные (кслову — неужели, кто то думает, что перейдя с питона на си, люди будут продолжать форматировать код отступами, если они не понимают зачем они это делали, а теперь можно не форматировать? смешно как то...)
Или вот в следствии каких требований к языку, в руби класс (имя класса? поправьте) можно подменить объектом и поломать создание объектов во всей программе? это не требование к языку обусловленное решаемыми задачами, это желание его автора, воплотить некие идеи о «некой идеальной ооп-шности в вакууме». или вот какие требования к языку обуславливают, что разные реализации руби не совместимы друг сдругом?
Вот не связаны качества многих новых языков с требованиями, возникшими из задач, которые надо решать. Это решения их создателей, мода, красивый ближик, философия… но не требования к ЯП.
Языки сегодня создаются как стартапы — не от потребности решить проблему, а от других причин. от бизнесово-коммерческой жилки до банального ЧСВ.
Сегодня среди живых, распространенных языков, я вижу только 3 которые «возникли от требований к языкам», или сформировались исходя из задач, которые они решают: c/c++, java, javascript. Ну ещё куча ассемблеров под разные процессоры или микроконтроллеры.
Сишарп похоже начинает воплощаться в нечто похожее на потребное, но как то слишком многь в него впихивают «модностей».
Для утилитарного рабочего языка нужно далеко не это.
Практически все откровения про новые языки — выглядят как некие «нечистые манипуляции над неокррепшими умами неосиляторов с/с++» (да простят меня адепты модных языков).
Потому что когда я слышу объяснения, что вот тут новый язык, и он такой милый/удобный/красивы/удобный язык, в нем «так много синтаксического сахара», или в котором реализован «самый правильный философичный ооп» или «это самый функциональный из функциональных» — я начинаю сильно подозревать, что люди, которым это нравится, не собираются повседневные задачи решать, а собираются играться с логическими задачами из академической среды.
Я тоже не против почитать про хацкель, под бутылочку пива, дома вечером, но ребята, не на работе же, и не тогда когда нам надо остатки на складах считать и xml-ки валидные прогружать гигатонами! не надо писать на хацкеле учетную систему, не надо на пхп делать модуль обработки веб-сервиса )
И знаете, мне это напоминает анекдот про байкеров и стрит-рейсеров.
"- Давайте что ли знакомиться? Мы же тоже на мотоциклах гоняем, только на спортивных.
— А что с вами знакомиться — вы каждый год новые."
Каждый год новые откровения про очередную серебрянную пулю, новые языки, новые восторженные юнцы, которые бездумно лезут на новый лад очередного моднявого подобия бездумно все переделать… блин ) Рассказывал знакомый бывший рубист — из 200 рубистов собеседование прошел 1. Алгоритмов не знают, паттернов разработки не знают, структрур и технологий не знают, думать не хотят… зато они знают руби, самый модный язык, для решения всех каких ни попади задач, с высокой зарплатой программистов. Вот эти толпы хомячков и составляют основную массу последователей, как создающих, так и пользующих тысячи новых языков. Прилетающих как мухи на мед. А вы говорите… требования к ЯП… хи).
Что делать с этим не знаю. Но уж точно не пытаться оправдывать появление десятков новых языков некими «требованиями к ЯП». имхо)
Но я бы, все таки, не ставил знак равно между вливанием бабла и успехом.
Понятно, что серьезная поддержка требует денег и не малых — я даже не представляю затраты на разработку новой спецификации Java в условиях обеспечения 100% обратной совместимости, или на разработку тестов джавамашины.
Но помимо просто денежных вливаний (которые кстати, еще надо понимать как и куда вливать — в рекламу и откаты лицам принимающим решения, или вот в спецификации и стандартизацию) — есть некая техническая составляющая, которая делает инструмент надежным, прогнозируемым которому ты начинаешь доверять. Иначе после окончания вливаний и движухи — технология быстро сойдет на нет.
Джаве это удалось.
Я сомневаюсь, что Нуралиев, принимая решения о начале работ над «1С Enterprise Tools», был под чьим то денежным вливанием, когда принимал решение о том, что это будет написано на Java под Eclipse.
Удалось получить признание Джаваскрипту. даже стандартизирован, развивается.
Си с Плюсами развиваются тоже без особого жесткого маркетинга.
Дотнетам — имхо, ещё не факт, что удалось подобное. Пока майкрософт сам пилит продукт, пока платит за шумиху вокруг языка — оно будет жить. Но вот я не вижу пока такого же сообщества какое сложилось вокруг джавы. имхо.
Мы вроде говорили о сильной/слабой, а не о статической/динамической типизациях.
Ах… Гм… Был спросонок, перепутал. Погуглил. Уточнил. Осознал :)
Крайне редко говорят про сильную и слабую типизацию.
Вы первый или второй. Обычно говорят про динамическую-vs-статическую типизацию.
Особой корелляции между сильной-слабой типизацией и проблемами с разработкой не отмечал.
Проблемы с динамической типизацией изложил — с ростом объема кода, проблемы в разработке на динамических языках прастут «очень не линейно». Проблемы со статической типизацией — относительно линейно. Это мои оценки и наблюдения.
И до тех пор, пока не будет исследований, показывающих, какая типизация действительно лучше с точки зрения, подчеркиваю, бизнеса/заказчика в различных контекстах применения, я всегда на подобные споры и попытки их разведения буду смотреть осуждающе.
Тогда у нас дед-лок))
Исследований нет, и наверное не будет, ибо некому за это заплатить. нет — исследований — будет постоянное осуждение. Будет осуждение — проблему скорее всего не решить. Но принимать-то архитектурные решения надо! И стажеров надо обучать! Как быть?
Хотя согласен, в том плане, что попытки разведения неконструктивных споров надо подавлять в зародыше.
С моей же точки зрения, если выбирать между «статикой и динамикой» в типизации при выборе языка разработки, то мой опыт говорит мне следующее: выгода зависит от объема разрабатываемого кода. ( и я сейчас буду говорить только выгодах проекта, вытекающих из минимизации трудозатрат и технических рисков. Если последствия неадекватных технических решений будут лежать на ком-то другом, или «бизнес» планирует «отскочить» до проявления проблем или «еще как-то» (вплоть до полного наплевательства на последствия, или полного одупления (непонимания лицами принимающими решения технических проблем) ) — то «бизнес», естественно, будет принимать решения совсем с других, не связаных с техническими аспектами, позиций )
и так:
* на коротком периоде, для небольших задач, одноразовых, скриптования поведения «жесткой части» — удобнее/выгоднее динамическая типизация. Низкий порог входа, быстрое прототипирование — позволят экономить бюджет. До тех пор, пока кривая проблем не начала расти (не сдвинулась с места), или не начался рефакторинг, или число модулей в вашей системе не выросло до двух.
Отсюда и область применения: скрипты инициализации, тестирование, небольшие хранимки в бд, сайты с линейной логикой работы, различные примитивные СМО и пр.
* на длинном периоде, при относительно большом коде, с рисками изменения бизнес-логики, для задач сложнее чем на одну неделю, для кода которые надо будет поддерживать — лучше сразу начать писать на языках со статической типизацией ( возможно с включением скриптов на динамических языках ). Потому что линейный рост числа проблем (а не галлопирующий экспонентой) в зависимости от объема кода — очень даже комфортен. Причем выбирать стоит те языки, у которых как можно меньше проблем с обратной совместимостью.
А корелляции между «сильной» и «слабой» типизацией я не заметил.
Я не могу запретить вам его осуждать, но рассуждения, особенно логически стройные, буду рад услышать.
я сам был таким))
Не очень понятен этот снисходительный тон.
Я принял вас за очередного молодого адепта «новомодных языков». Извиняюсь)
Как вы предлагаете мне приятно удивиться?
Вы говорите ледит на поверхности? на поверхности вон по wsdl например — лежит пакет goWsdl (спасибо камраду за ссылку). но из описания пакета, я понял, что в сравнении с тем, что умеет в этой части джава — goWsdl это дешевая студенческая поделка. Где генерация wsdl, где xsd 1.1, где сериализация и десериализация в код через аннотации?
Извините, не хочу я тратить время на изучение очередного изделия. Таких изделий каждый день -десятками плодится — на всех жизни не напасешься ознакамливаться. Надоело, если честно.
Если от идеологов нет ответов на конкретные вопросы — значит изучать уже никто не будет. И аргумент мол на поверхности, сразу найдете ответы — во первых не катит, потому что то что поверхности уже не впечатляет, а во вторых — это просто гнилой маркетинговый подход, согласитесь. Не буду я тратить время на изучение кота в мешке.
Особенно, плохо звучит такой ответ (начните изучать и будете приятно удивлены, вместо конкретного ответа) — если сравнить такой ответ с ситуацией, когда я спрашиваю у мастодонтов джавы «что есть в джаве для этого?» — мне говорят конкретный набор буков и я иду гуглить этот пакет или технологию.
парой пос ов пиже, я описал вполне конкретные вопросы и ситуации про вебсервисы, wsdl и soap. у вас есть что ответить? и да, ответ я много раз отвечал — тоже гнилой ответ. отвечали — дайте ссылку, сделайте фак и ссылайтесь на него. но не отсылайте в никуда)
Посмаковать синтаксический сахар на досуге — это прекрасно.
Но я описываю интерес практический. и я прошу оппоннта ответить на эти вопросы хотя бы самому себе.
Как язык поддерживает те или иные технологии, и что имено означает эта «поддержка».
В частности, к прмеру — была заявлена поддержка вебсервисов.
Я начинаю «разбираться» — описываю кейсы (рабочие ситуации) и проблемы с которыми мы столкнулись в жизни, с примерами «провала кейса» на «других модных языках».
Что бы узнать, как именно обстоят дела в части «поддержки всех этих букв» в сабжевом языке.
На самом деле, вероятный ответ я уже знаю, но мне важно, что бы оппонент осознал что, заявленная «поддержка буков» на ко оруб ор сослался — это филькина грамота, мало общего имеющая с потребностями в части «поддержки указанных буков»за пределами академической среды.
Хотя, остается шанс, что я не прав, и я буду приятно удивлен.
Увы, но такое впечатление, что очень многие идеологи новомодных языков и их последователи как правило мало подкованы в технической части и практике применения IT в жизни. Для них сложный код — это сложная курсовая. для них важнее запилит красивую модную фичу в язык, а не обеспечить 100% ьбратную совместимость. Их понимание того, что такое технология и как она применяется — толькь пара лежащих на поверхности случаев, причем о проверке валидности структур и об обработке ошибок и исключерий — они и не слышали, или даже хуже — сознательно выпилили это из языка.
Первое чему приходится учить стажера — это критический взгляд, и умение строить зашиту от дурака в своем коде/системе. Подавляющее число технологий на новомодных языках — не серьезны, и крайне плохо обрабатывают проблемные ситуации. Пример с руби сервером который падает на 5 потоках запросов — очень характерен для идеалистических выходцев из академической среды в розовых очках. Или для хипстоты.
Другая причина почему я это все говорю — надежда, что сегодняшний «свидетель гоу/руби/питона/хацкеля», погрущившись в детали технической части и сравнительный анализ возможностей языков — начнет изучать нечто более серьезное, и будет смотреть на вещи более критично. Для этого, имзо, достаточно просто ответить на вопросы которые я задаю. Только честно. Хотя бы самому себе )))
Адекватных инженеров очень мало.
Когда-то, мне перла для веб — вполне хватало. Для дипломной работы. Но потом был пхп, дельфи, си++, джава… Задали бы мне пяток таких вопросов в свое время…
гоу — как я сейчас понимаю нишевый язык. очень нишевый. с, судя по всему, очень особенной поддержкой, которую устраивает текущее состояние, при котором многих бесят некоторые недофичи языка (ссылаюсь на статью «50 оттенков гоу»).
Так вот и опишите эти ниши. Конкретно. С техническии деталями и подробностями.
Так вы завоюете больше последователей. Мне вот все равно на чем писать на проекте — надо было -мы на сишарпе «прокси» с интерфейсом на вебсервисах для доступа с андроида к доксвижену сделали. Хотя сам я джаву люблю — но надо — ращобрались и сделали.) есть на Qt проекты. Будем понимать нишу гоу — почему бы на гоу не продать пару проектов — но нужны конкретные примеры с тех подробностями. Я вот не буду разбираться в интимных откровениях и проблемах недо-языков за свой счет — мне бы сделать бизнес-задачу, что бы клиент был доволен))) А гоу пока не ложится ну никак супротив джавы, имхо. и не будет ложиться, пока будут дешевые переводные статьия с рекламным буллшитом, вместо сухих технических данных и статистики с плюсами и минусами. когда мы инструменты для проекта выбираем — надо профиль понимать, и риски минимизировать.
… а вместо этого — половина сторонников гоу, в комментариях выше и ниже только радостными воплями разрождаются про то, как им понравилось, и какой экстаз они испытали… да плевать на это. глубоко плевать, извините) Факты давайте.
а как именно «поддерживает»? вы эту «поддержку» с джавовским стеком сравнивали?
давайте по порядку: первое — кодогенератор по ссылке — это клиентская часть или серверная?
если серверная, то для какой серверной платформы или какого сервера приложений ?(такое понятие в гоу есть?)
я к чему — управление ресурсами в этом сервере есть? пул потоков, скажем? А то, знаете, видели мы тут недавеча «супер сервер». на руби писанный. Когда ему 5 потоков запросов в параллель пускаешь… он… падает. Понимаете, Карл,… падает!!! Не выдает 5хх-й код, не закрывает соединение с месседжем типа — превышены ресурсы, и продолжает работать, как это делает практически любой сервер приложений для всеми ненавидимой джавы… а просто падает.
Как в гоу решается вопрос управления русурсом подключений? Так же, как в руби на том сервере?)))
Ладно. Следующий вопрос: где генератор wsdl по коду? обратный, так сказать, генератор? я могу написать структуры, массивы, определить их обязательность или не очень, функции… а она мне — по моему коду — и wsdl, и опубликованный сервис на сервере и сразу подключайся-не-хочу… умеет? почему джава и сишарп (мать его))) — умеют, а гоу… для вебсервисов ориентированный, все поддерживающий — … умеет?
Теперь следующий вопрос: xml schema 1.1 — где? А то нам тут АТ-К прислали файлики как-то раз… так мы их едва открыли… кстати, не wsdl прислали, а xsd.
xds..., да, а что у нас с xsd? Что с валидацией xml, на соответствие xsd?
Что, с сериализацией/десериализацией xml? Есть в «красивом синтаксисе гоу» аналог джавовских аннотаций? Есть возможность просто «промаркировать» поля структуры xpath-ами — и отдать структуру в некую «фабрику», а на выходе — получить xml-заданной структуры? ну не охота мне руками раскладывать поля по элементам xml…
Что с ОРМ? Могу я в «аннотациях структур» гоу описать какое поле в какой таблице в какой колонке лежать? И что бы была просто фабрика, которой, подсовываешь струтуры, а она сама тебе и базу данных перестроит, и сохранение-восстановление сделает? и что бы мне — только одну строчку над каждым полем прямо в классе прописать. можно так в гоу? или только gowsdl пакет, который, судя по всему, упадет если ему на вход подать не корректную структуру?
и я ещё много могу рассказать чего у вас в вашем распрекрасном гоу нету, что есть в ненавидимой хопстотой «джаве-йе-йе».
…
просто я к чему? гоу, насколько я могу сейчас судить, находится на уровне технологичности джавы 1 или 2. аннотации, вон, и «рефлекшен» в какой джаве появиоись? в третьей кажется, поправьте? какой это год? начало 2000-х? вот и гоу сейчас — примерно на этом уровне готовности для «промышленной разработки». Играйтесь конечно, но прошу, давайте не портить пространство воплями типа «большой код», все умеет, вебсервисы… вы видели «большой код»? сколько читающих этот пост хотя бы знает о «монструозности» стека приложений «ibm websphere»? а «рейшионал»? вы пытались писать систему которая должна хранить ваши данные 75 лет после вашей смерти? Эта «простая задача» сейчас решается в пенсионке. На джаве и майфреймах ibm. Ну смешно же выглядят сказки про «большой код» на гоу, на фоне достаточно примитивного набора возможностей языка. Ну серьезно, народ)))) Не ведитесь.
Да, в нем есть, вероятно прикольные фичи типа горутин (так и не понял из статьи, что эта за фигня, кстати) — но это не делает картины на фоне провала по всем остальным фронтам. Не может сделать, извините.
В пхп вон тоже поддержка wsdl есть. и причем на уровне более серьезном, чем это единственное поделие «gowsdl»… только что с этого?..
Это вебсервисы, потому что это они описываются в спецификациях с соответствующими названиями.
Если открыть википедию, то там как раз о wsdl/soap/xml и говорится.
А что для вас «вебсервисы»? о каких именно вебсервисах вы говорите, о которых «все» (кто эти все?) знают? — можете обозначить назвария технологий, номера специфицаций и стандарты, которыми описываются ваши «вебсервисы»?
для каких именно «вебсервисов» предназначен этот язык?
Вот именно о задачах, которым соответствует описываемый язык — в статье нет ни слова. Не о чем делать аналитические заключения. Статья — реклама, рассчитанная на восторженного наивного, не отягощенного практикой новичка. Потому и "срач". Имхо.
Вы, вместо громогласных заявлений, ответили бы для начала хотя бы на часть вопросов.
Рубисты/питонисты говорили точно так. Но нет, подташнивает. А ещё, все знают об "успехах" рубистов на проекте в росреестре. Сданый вовремя проект, довольный заказчик, коммерческий успех компании подрядчика, безоблачные перспективы команды проекта… ага...
Следующие свои проекты, особенно после прочтения статьи "50 оттенков го", я буду писать на java. Как и последние несколько лет.
Спасибо за подборку!
Обратная совместимость не только стабильностью синтаксиса гарантируется. В джаве вон синтаксис меняется, но обратная 100% совсестимость остается. То, что гугль заморозил синтаксис, это может быть и хорошо, но что с базовыми библиотеками? Или будет как в си? (через 5 лет, на другой платформе, теоретически, собрать софтину можно, но вот половины библиотек уже нет или они просто не перенесены на эту платформу? да и разрядность уже поменялась, потому вылазят нулл-поинеры да сег-фолты?)
Что у языка с кроссплатформенностью?
И повторюсь: не увидел, даже после перепросмотра статьи производственных задач, которые решаеются языком у тех или иных вендоров! Или вы как «свидетели руби» — обосновывают выбор руби для сложного «иниерпрайз» проекта с ЖЦ длительностью лет 10 тем, что «там-то оно используется» — а когда выясняешь как именно используется — выясняется что там 5-и строчники-скриптики для тестирования оборудования на нем пишут?)))
Код написанный на го, будет хотя бы собираться в новых версиях компилитора хотя бы через 3-5 лет? я молчу про такую «ынтерпрайзную роскошь», как «работать точно так же»…
Или будет как с руби? (гугль выпутит новую, улучшенную версию языка, не совместимую с предыдущей, и через 2 года снимет старую с поддержки, со словами, мол, " мы скорбим, что до сих пор ещё много проектов не смогли перейти на новую версию, из-за проблем с перерабокой исх. кода, но мы все-таки снимаем старую версию с поддержки. (читаем между строк: «Мы плевать хотели на ваши проблемы. Это ваши проблемы, трудоемкость и деньги. А мы будем дальше делать наш красивый язык, ибо нас волнует только красота нашего поделия.»)?
Ещё, во всей статье, так и не нашел позиционирования языка. Под какие задачи он заточен? Какой сдк и библиотеки под него есть?
Ещё вопрос, как разработчика с 20 годами стажа, которого, вопреки заявленному в статье тезису, никогда не сводили с ума новые языки, которого эта череда «новых откровений» банально достала: зачем нужен ваш язык, если всё, что нам надо, мы прекрасно делаем на уже существующих технологиях: java, javascript, с/с++? кто то еще вспомнит про си-диез (простите, не люблю я его — но и ладно..., живет и даже что ть полезное можно на на нем делать)… кто то вспомнит про питон ( скажу — «остыньте, уже не модно»), руби ( «и вы пойдете на свалку моды»), хацкель (подмигну -ну ты понял, посмтри на питон и руби)… Но чем го отличается от этого разношерстного безобразия? Это нишевый язык или общего назначения?
Да, вы проводите какие, весьма спорные, сравнения, очень пахнущие глубоким субъективизмом, картинки рисуете. Говорите про какую-то понятность… Но вот я так и не понял — это замена питону или башу в скриптах инициализации линукса?
Это скриптовый язык с возможностью компиляции и возможностью использовать .dll/.so? Или это легкое нечто которое позволяет набросать что то на коленке типа мини утилиты? Или это нечто для веб, компилируемое и мегашустрое в обработке мегатонн микро-запросов?.. Ведь нечто большое, мега-интерпрайзное этот язык, как сложилось впечатление, в силу отсутствия ооп -банально не потянет (в си же вон от структур и пакетов к ооп перещли?.. зачем, не понятно, наверное… но си, сегодня, остался, видимо, только при программировании микроконтроллеров...). Или го — это замены простому си, пригодному для програмирования микроконтроллеров?
Какие прикладные пакеты есть в го?(кодогенератор веб сервис-клиента из .wsdl-файла есть? Я могу тестовый скриптик типа как для junit набросать? А к базе данных могу подключиться? jdbc-драйвера он понимает? Нет? а odbc?) Какие средства для управления GUI есть? я могу его интегрировать с Qt? нет? а какие средства есть для воддержки веб-интерфейса? Поддержка вебсокетов есть?
Эти, и ещё полсотни других влпросов я могу задать, и не остановиться, потому, что есть еще много за этой полсотней…
Не должен я учить го. Не вижу я в этой статье, чем го отличается от мегасотен других «откровений». Извините.
Зачем мне писать что то серьезное на го, если никто не гарантирует, что завтра они не выкинут такой же финт как руби? или как питон не выпустят новую версию, на которой старый код не работает?
А если не серьезное — то что тогда писать? как этот язык поможет улучшить жизнь моему бизнес-заказчику? какие проблемы я могу на нем решать? плевать на синтаксис ( хотя, нет, не плевать — за отступы-табы-проблемы в питоне надо «бить в голову с ноги»)))))(шутка)) но как этот язык облегчит мне жизнь?
«Бизнес-задачи» бывают разные. «Бизнес-задачи» — это не только то, чем занимается «коммерция» и «бизнес».
Не путайте конкретные учетные задачи, на которые заточены компоненты SAP и задачи автоматизации бизнес-процессов.
Например АСУТП писать на SAP — это надо сильно удариться головой.
Не стоит писать систему реального времени контроля за грузоперевозками в масштабе страны на SAP. Можно, но в здравом уме это никто делать не будет. Потому там майнфреймы IBM, DB2, Java.
А вот бухгалтерию и зарплату под объемы РЖД — самое дело — SAP там лег как родной) (а на самом деле просто потому, что 1С не тянул эти объемы).
ABAP хорош только в контексте учетных механизмов SAP, а как сам язык, сужу по отзывам — не очень катит супротив даже 1С.
ABAP — конкурент 1С, а не Java/С++…
Вы хотите сказать что ада применяется в медицине и авиа (в смысле «до сих пор»)?
Я не для спора, мне скорее интересна фактическая ситуация.
в нашей стране я видел следующее: нашу с вами пенсию учитывают, грузовыми жд-перевозками по стране управляют, банковские платежи в цб обрабатывают.
ps: это такой тролинг, или вы серьезно не в курсе «области применения на майнфреймах»? давайте обсудим.
Как уже было упомянуто, нет методов провести автоматический рефакторинг кода для языка с динамической типизацией — потому, что вы не можете узнать, что именно вам подсунут в значение переменной до момента рантайма и сработает у вас обращение к измененному методу или нет. Это не говоря о ситуации, когда у вас функция вызывается в нескольких местах, и вам подсовывают разные типы в один параметр.
Весь рефакторинг кода при динамической типизации — это смесь ручного труда и обработки баг-репортов после того как у вас не прошел очередной тест.
А когда у вас большой продукт — ручной рефакторинг с масштабным тестрованием — это ОЧЕНЬ серьезная проблема. Иногда даже проще написать продукт с нуля. На языках со статической типизацией. джаве/сиДиезе/паскале/сиПлюсПлюс — там, где автоматический рефакторинг возможен.
«Нельзя пользоваться версией X, потому что она снимается с поддержки» => никаких исправлений ошбок, заплаток для безопасности, никакой линии техподдержки и ответов производителя по вашим багам.
дизайн, скорректированный опытом реальной разработки сложных и «сверхбольших» систем на протяжении почти 20 лет. не? :)
ну я же говорил, что меня надо поправить:
* не 1.8, а 1.8.7
* не 2.0 а «1.9.3, которую постепенно вытеснит ветка Ruby 2.0».
* не 2.5 года, а почти 5 лет.
так, что это не наезд, а констатация типовых проблем. это мы еще дотнет 3.5 и дотнет4 не обсуждали.
вам крупно повезло, имхо. а большой ли был проект, сколько человек и как долго писали, часто ли перерабатывали?
я же не говорю что проблемы будут гарантированно. вернее они будут почти гарантированно только при большом объеме кода, но на маленьких скриптах, это почти не заметно, и даже не факт что вы наступите на то, что поломали создатели языка.
Возьмем историю C#. В следствии каких требований появился этот язык?
в следствии одного единственного, и не к языку, а вообще: майкрософту нужен был конкурент джаве. Не больше, ни меньше. Им плевать на ваши требования к языку. «Чисто бизнес, ничего личного». Они бы джаву использовали, но в своё время их за попытку создать несовместимую с эталонной реализацию языка джава — жестоко
пои…наказали юристы SunИли — в следствии какого требования в Питоне невидимые символы стали использоваться не только как разделители? это не требование к языку, это спорное решение его создателя, попытка навесить на язык функции, ему не свойственные (кслову — неужели, кто то думает, что перейдя с питона на си, люди будут продолжать форматировать код отступами, если они не понимают зачем они это делали, а теперь можно не форматировать? смешно как то...)
Или вот в следствии каких требований к языку, в руби класс (имя класса? поправьте) можно подменить объектом и поломать создание объектов во всей программе? это не требование к языку обусловленное решаемыми задачами, это желание его автора, воплотить некие идеи о «некой идеальной ооп-шности в вакууме». или вот какие требования к языку обуславливают, что разные реализации руби не совместимы друг сдругом?
Вот не связаны качества многих новых языков с требованиями, возникшими из задач, которые надо решать. Это решения их создателей, мода, красивый ближик, философия… но не требования к ЯП.
Языки сегодня создаются как стартапы — не от потребности решить проблему, а от других причин. от бизнесово-коммерческой жилки до банального ЧСВ.
Сегодня среди живых, распространенных языков, я вижу только 3 которые «возникли от требований к языкам», или сформировались исходя из задач, которые они решают: c/c++, java, javascript. Ну ещё куча ассемблеров под разные процессоры или микроконтроллеры.
Сишарп похоже начинает воплощаться в нечто похожее на потребное, но как то слишком многь в него впихивают «модностей».
Для утилитарного рабочего языка нужно далеко не это.
Практически все откровения про новые языки — выглядят как некие «нечистые манипуляции над неокррепшими умами неосиляторов с/с++» (да простят меня адепты модных языков).
Потому что когда я слышу объяснения, что вот тут новый язык, и он такой милый/удобный/красивы/удобный язык, в нем «так много синтаксического сахара», или в котором реализован «самый правильный философичный ооп» или «это самый функциональный из функциональных» — я начинаю сильно подозревать, что люди, которым это нравится, не собираются повседневные задачи решать, а собираются играться с логическими задачами из академической среды.
Я тоже не против почитать про хацкель, под бутылочку пива, дома вечером, но ребята, не на работе же, и не тогда когда нам надо остатки на складах считать и xml-ки валидные прогружать гигатонами! не надо писать на хацкеле учетную систему, не надо на пхп делать модуль обработки веб-сервиса )
И знаете, мне это напоминает анекдот про байкеров и стрит-рейсеров.
"- Давайте что ли знакомиться? Мы же тоже на мотоциклах гоняем, только на спортивных.
— А что с вами знакомиться — вы каждый год новые."
Каждый год новые откровения про очередную серебрянную пулю, новые языки, новые восторженные юнцы, которые бездумно лезут на новый лад очередного моднявого подобия бездумно все переделать… блин ) Рассказывал знакомый бывший рубист — из 200 рубистов собеседование прошел 1. Алгоритмов не знают, паттернов разработки не знают, структрур и технологий не знают, думать не хотят… зато они знают руби, самый модный язык, для решения всех каких ни попади задач, с высокой зарплатой программистов. Вот эти толпы хомячков и составляют основную массу последователей, как создающих, так и пользующих тысячи новых языков. Прилетающих как мухи на мед. А вы говорите… требования к ЯП… хи).
Что делать с этим не знаю. Но уж точно не пытаться оправдывать появление десятков новых языков некими «требованиями к ЯП». имхо)
Понятно, что серьезная поддержка требует денег и не малых — я даже не представляю затраты на разработку новой спецификации Java в условиях обеспечения 100% обратной совместимости, или на разработку тестов джавамашины.
Но помимо просто денежных вливаний (которые кстати, еще надо понимать как и куда вливать — в рекламу и откаты лицам принимающим решения, или вот в спецификации и стандартизацию) — есть некая техническая составляющая, которая делает инструмент надежным, прогнозируемым которому ты начинаешь доверять. Иначе после окончания вливаний и движухи — технология быстро сойдет на нет.
Джаве это удалось.
Я сомневаюсь, что Нуралиев, принимая решения о начале работ над «1С Enterprise Tools», был под чьим то денежным вливанием, когда принимал решение о том, что это будет написано на Java под Eclipse.
Удалось получить признание Джаваскрипту. даже стандартизирован, развивается.
Си с Плюсами развиваются тоже без особого жесткого маркетинга.
Дотнетам — имхо, ещё не факт, что удалось подобное. Пока майкрософт сам пилит продукт, пока платит за шумиху вокруг языка — оно будет жить. Но вот я не вижу пока такого же сообщества какое сложилось вокруг джавы. имхо.
Имхо, вливание не гарантирует. Хотя и необходимо.
Крайне редко говорят про сильную и слабую типизацию.
Вы первый или второй. Обычно говорят про динамическую-vs-статическую типизацию.
Особой корелляции между сильной-слабой типизацией и проблемами с разработкой не отмечал.
Проблемы с динамической типизацией изложил — с ростом объема кода, проблемы в разработке на динамических языках прастут «очень не линейно». Проблемы со статической типизацией — относительно линейно. Это мои оценки и наблюдения.
Тогда у нас дед-лок))
Исследований нет, и наверное не будет, ибо некому за это заплатить. нет — исследований — будет постоянное осуждение. Будет осуждение — проблему скорее всего не решить. Но принимать-то архитектурные решения надо! И стажеров надо обучать! Как быть?
Хотя согласен, в том плане, что попытки разведения неконструктивных споров надо подавлять в зародыше.
С моей же точки зрения, если выбирать между «статикой и динамикой» в типизации при выборе языка разработки, то мой опыт говорит мне следующее: выгода зависит от объема разрабатываемого кода. ( и я сейчас буду говорить только выгодах проекта, вытекающих из минимизации трудозатрат и технических рисков. Если последствия неадекватных технических решений будут лежать на ком-то другом, или «бизнес» планирует «отскочить» до проявления проблем или «еще как-то» (вплоть до полного наплевательства на последствия, или полного одупления (непонимания лицами принимающими решения технических проблем) ) — то «бизнес», естественно, будет принимать решения совсем с других, не связаных с техническими аспектами, позиций )
и так:
* на коротком периоде, для небольших задач, одноразовых, скриптования поведения «жесткой части» — удобнее/выгоднее динамическая типизация. Низкий порог входа, быстрое прототипирование — позволят экономить бюджет. До тех пор, пока кривая проблем не начала расти (не сдвинулась с места), или не начался рефакторинг, или число модулей в вашей системе не выросло до двух.
Отсюда и область применения: скрипты инициализации, тестирование, небольшие хранимки в бд, сайты с линейной логикой работы, различные примитивные СМО и пр.
* на длинном периоде, при относительно большом коде, с рисками изменения бизнес-логики, для задач сложнее чем на одну неделю, для кода которые надо будет поддерживать — лучше сразу начать писать на языках со статической типизацией ( возможно с включением скриптов на динамических языках ). Потому что линейный рост числа проблем (а не галлопирующий экспонентой) в зависимости от объема кода — очень даже комфортен. Причем выбирать стоит те языки, у которых как можно меньше проблем с обратной совместимостью.
А корелляции между «сильной» и «слабой» типизацией я не заметил.
Я не могу запретить вам его осуждать, но рассуждения, особенно логически стройные, буду рад услышать.
Я принял вас за очередного молодого адепта «новомодных языков». Извиняюсь)