Вот именно о задачах, которым соответствует описываемый язык — в статье нет ни слова. Не о чем делать аналитические заключения. Статья — реклама, рассчитанная на восторженного наивного, не отягощенного практикой новичка. Потому и "срач". Имхо.
Вы, вместо громогласных заявлений, ответили бы для начала хотя бы на часть вопросов.
Рубисты/питонисты говорили точно так. Но нет, подташнивает. А ещё, все знают об "успехах" рубистов на проекте в росреестре. Сданый вовремя проект, довольный заказчик, коммерческий успех компании подрядчика, безоблачные перспективы команды проекта… ага...
Следующие свои проекты, особенно после прочтения статьи "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-статическую типизацию.
Особой корелляции между сильной-слабой типизацией и проблемами с разработкой не отмечал.
Проблемы с динамической типизацией изложил — с ростом объема кода, проблемы в разработке на динамических языках прастут «очень не линейно». Проблемы со статической типизацией — относительно линейно. Это мои оценки и наблюдения.
И до тех пор, пока не будет исследований, показывающих, какая типизация действительно лучше с точки зрения, подчеркиваю, бизнеса/заказчика в различных контекстах применения, я всегда на подобные споры и попытки их разведения буду смотреть осуждающе.
Тогда у нас дед-лок))
Исследований нет, и наверное не будет, ибо некому за это заплатить. нет — исследований — будет постоянное осуждение. Будет осуждение — проблему скорее всего не решить. Но принимать-то архитектурные решения надо! И стажеров надо обучать! Как быть?
Хотя согласен, в том плане, что попытки разведения неконструктивных споров надо подавлять в зародыше.
С моей же точки зрения, если выбирать между «статикой и динамикой» в типизации при выборе языка разработки, то мой опыт говорит мне следующее: выгода зависит от объема разрабатываемого кода. ( и я сейчас буду говорить только выгодах проекта, вытекающих из минимизации трудозатрат и технических рисков. Если последствия неадекватных технических решений будут лежать на ком-то другом, или «бизнес» планирует «отскочить» до проявления проблем или «еще как-то» (вплоть до полного наплевательства на последствия, или полного одупления (непонимания лицами принимающими решения технических проблем) ) — то «бизнес», естественно, будет принимать решения совсем с других, не связаных с техническими аспектами, позиций )
и так:
* на коротком периоде, для небольших задач, одноразовых, скриптования поведения «жесткой части» — удобнее/выгоднее динамическая типизация. Низкий порог входа, быстрое прототипирование — позволят экономить бюджет. До тех пор, пока кривая проблем не начала расти (не сдвинулась с места), или не начался рефакторинг, или число модулей в вашей системе не выросло до двух.
Отсюда и область применения: скрипты инициализации, тестирование, небольшие хранимки в бд, сайты с линейной логикой работы, различные примитивные СМО и пр.
* на длинном периоде, при относительно большом коде, с рисками изменения бизнес-логики, для задач сложнее чем на одну неделю, для кода которые надо будет поддерживать — лучше сразу начать писать на языках со статической типизацией ( возможно с включением скриптов на динамических языках ). Потому что линейный рост числа проблем (а не галлопирующий экспонентой) в зависимости от объема кода — очень даже комфортен. Причем выбирать стоит те языки, у которых как можно меньше проблем с обратной совместимостью.
А корелляции между «сильной» и «слабой» типизацией я не заметил.
Я не могу запретить вам его осуждать, но рассуждения, особенно логически стройные, буду рад услышать.
я сам был таким))
Не очень понятен этот снисходительный тон.
Я принял вас за очередного молодого адепта «новомодных языков». Извиняюсь)
Мне кажется, автор, хоть и косвенно и спорно, но затронул одну важную тенденцию последних лет. На самом деле, имхо, очень плохую тенденцию.
Звучит она, на мой взгляд как «Больше языков. Аляпистых. Новых. МОДНЫХ. И не важно что будет потом».
Лично мое впечатление такое, что подавляющее число «создателей новых языков программирования», не имеют серьезного опыта разработки, и вообще подходят к этому делу как к приключению, к блогу, созданию развлечения для фанатов.
— «Обратная совместимость выпускамых ими версий языков? Зачем, ведь у нас есть новая вкуссная фича, мы впилили ее — вот, смотрите!». А то что вы не сможете перевести свой проект на новую версию потому, что вам надо будет переписывать мегатонны кода — это их уже не волнует.
«Ну и что! Зато смотрите как у нас бложик с этой фичей красиво обрабатывает тысячи твитов в секунду!» — Ну вот разве не так? Посмотрите на новость о снятии с поддержки руби 1.8 (кажется, поправьте меня). Мол, «грустно, конечно, что снимается с поддержки, прошло 2.5 года с момента выпуска, но эта версия до сих пор используется, потому, что код написанный для руби 1.8 не работает на интерпретаторе версии 2». (Так, или почти дословно.).
Занавес. Привлекли, поигрались, и кинули.
Не предупреждают создатели «самых правильных языков» своих «последователей», и о тм, что «язык для быстрого написания прототипов», «динамической типизацией» и «идеально правильным ООП» — на самом деле крайне редко подходит для серьезных задач, больших систем со сложной логикой, и суровых будней поддержки промышленного кода. А может и не могут предупредить, потому, что сами не знают, или не думают что их последователи будут «пихать невпихуемое». А может и знают, но хотят посмотреть что из этого выйдет — ведь не своими деньгами рискуют, а «если что» скажут типа — «Ну наш язык же для быстрого написания прототипов, о чем вы, не надо было конечно так делать».
В общем статья хоть и «кривоватая», но она о правильной проблеме — будьте осторожны с очередным «самым новым языком». Скорее всего это просто очередная мода.
И особенно осторожны будьте, пока не увидите проблемы и границы применимости языка, пока язык не найдет свою нишу.
Как всякий логический и технический инструмент, язык программирования — имеет свою область применения. Применять технический инструмент, не понимая когда этого делать не надо — это чистой воды глупость. Но как раз о недостатках своего детища — в эпоху «рекламы и красивых бложиков» — создатель нового языка, "который, как оказалось, понравился не только ему" — не предупреждает.
прямых доказательств нет и не будет))) зато есть куча косвенных. умеющий уши да слышит))) шучю. но ситуация примерно такова и есть, имхо.
полномасштабных исследований наверное нигде нет, разве что какой нибудь институт, который поддерживает методы оценки трудоемкости разработки, в результате своих исследований, выставит завышенные коэффициенты связанные с языком напротив языков с динамической типизацией.
но вот проблема в том, что серьезные большие институты, ориентированные на исследование промышленных методов разработки ПО — не очень интересуются языками с динамической типизацией. ну… мне так показалось, когда я исследовал вопрос о методиках оценки трудоемкости разработки.
я говорю о методиках оценки типа FPA (метод баллов функциональности), COCOMO / COCOMO 2, UCP (usecase point analisys? — как FPA, но только принимает на вход прецеденты использования.).
Поясню про коэффициенты связанные с языком разработки: во всех этих методиках, как правило вычисляются некие баллы сложности алгоритма/структры которая описывается в задании на разработку, а потом эти баллы пересчитываются в человекочасы умножением на кучу разных коэффициентов. среди прочих коэффициентов есть и связанные с языками разработки.
и тут такая особенность: институты, которые разрабатывают эти методики нацелены на промышленные, «серьезные области» — собственно там, где методы оценки трудоемкости очень важны. те области, где сбой в работе по имеет серьезные экономические или даже материальные последствия. или где комплекс программ сложный а процессы — часто запутаны. где проблем много, даже если системы не обрабатывают массовые заявки (т.е. гуглемейл или вконтактик с одноклассниками и фейсбуками например — они не показательны ни разу — это не промышленная разработка. они массовы, огромны, но их «бизнеспроцессы» достаточно примитивны и потому легко масштабируются. они очень просты по сути, даже в сравнении с обычной СЭД, или системой бухгалтерского или складского учета).
так вот — в этих областях традиционно(?) языки с динамической типизацией не выживают. не востребованны они теми, кто несет серьезную ответсвенность. как то вот так случилось.
и в результате, ничего что касается языков с «динамической» типизацией, я в исследованиях больших институтов я не видел. были коэффициенты для C/C++, Java, Paskal. даже бейсик кажется был. но джаваскрипта, руби, питона там я не помню.
занимался исследованием методов оценки лет 5 назад, может сейчас что и изменилось, поправьте если что))
я к чему: ссылаться на статстику — нельзя. никто не будет проводить масштабные сраврительные исследования для кучки популярных в этом году технологий. простите, но пхп был популярен пять лет назад, питон был популярен в позапрошлом году. в этом руби на коне… никто не заплатит за такие исследования.
поэтому мы можем основываться только на собственном опыте и анализе успеха длительных промышленных проектов с которыми столкнулись и в которых участвовали.
и на модели, котрые описывают как мы ведем разработку, типовые проблемы, ситуации в работе, которые мы можем легко или сложно решить используя разные языки.
(например, рубисты вынуждены ренерить xml кож вручную, и вручную писать правила проверки, что бы xml соответвовал требуемому xsd; на джава же этой проблемы нет вообще — на основе xsd кодогенератором делаются классы с анотациями, и при парсинге/сериализации все правила xsd проверяются автомтатически == следовательно на джава разработать алгоритмы для wsdl-вебсервисов быстрее).
или другой прмер: при рефактоинге кода, изменнии структуры классов и их методов, для динамических языков нет методов которые позволили бы понять, где используется изменяемый класс. что бы выявить все эти места, нужно проводить масштабное тестирование, что трудоемко. а в случае языков со статической типизацией — все места использования класса, типа, метода проверяются сразу компилятором, и более того — IDE спомбна выполнить 90%работы по анализу кода за нас. == рефакторинг кода написанного на ryby/javascript это более трудоемкая процедура, чем скажем рефакторинг кода на java илиc++.
логические рассуждения, не больше)))
по поводу опыта могу вам сказать так: только через 8-10 лет после института, я начал понимать почему, например, на PHP очень геморройно делать большую сложную систему типа СЭД. и что проблема не в пряморукости, а в глубинных свойствах самого языка и инструментария.
и то, я начал это понимать только после того, как сам поучаствовал аналитиком 2 года на одном проекте внедрения системыдокументооборота, написанрой на пхп, как поразбирал багрепорты, как безуспешно разработчики пытались решить эти проблемы, и как система постепенро дохла, вплоть до невозможности собрать статстику по обработке поручений за неделю в течении 6 часов.
то что вы скептически относитесь к утверждениям, что статическая/жесткая типизация помогает контроллировать код — мне очень понятно. я сам был таким))
Вот именно о задачах, которым соответствует описываемый язык — в статье нет ни слова. Не о чем делать аналитические заключения. Статья — реклама, рассчитанная на восторженного наивного, не отягощенного практикой новичка. Потому и "срач". Имхо.
Вы, вместо громогласных заявлений, ответили бы для начала хотя бы на часть вопросов.
Рубисты/питонисты говорили точно так. Но нет, подташнивает. А ещё, все знают об "успехах" рубистов на проекте в росреестре. Сданый вовремя проект, довольный заказчик, коммерческий успех компании подрядчика, безоблачные перспективы команды проекта… ага...
Следующие свои проекты, особенно после прочтения статьи "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-статическую типизацию.
Особой корелляции между сильной-слабой типизацией и проблемами с разработкой не отмечал.
Проблемы с динамической типизацией изложил — с ростом объема кода, проблемы в разработке на динамических языках прастут «очень не линейно». Проблемы со статической типизацией — относительно линейно. Это мои оценки и наблюдения.
Тогда у нас дед-лок))
Исследований нет, и наверное не будет, ибо некому за это заплатить. нет — исследований — будет постоянное осуждение. Будет осуждение — проблему скорее всего не решить. Но принимать-то архитектурные решения надо! И стажеров надо обучать! Как быть?
Хотя согласен, в том плане, что попытки разведения неконструктивных споров надо подавлять в зародыше.
С моей же точки зрения, если выбирать между «статикой и динамикой» в типизации при выборе языка разработки, то мой опыт говорит мне следующее: выгода зависит от объема разрабатываемого кода. ( и я сейчас буду говорить только выгодах проекта, вытекающих из минимизации трудозатрат и технических рисков. Если последствия неадекватных технических решений будут лежать на ком-то другом, или «бизнес» планирует «отскочить» до проявления проблем или «еще как-то» (вплоть до полного наплевательства на последствия, или полного одупления (непонимания лицами принимающими решения технических проблем) ) — то «бизнес», естественно, будет принимать решения совсем с других, не связаных с техническими аспектами, позиций )
и так:
* на коротком периоде, для небольших задач, одноразовых, скриптования поведения «жесткой части» — удобнее/выгоднее динамическая типизация. Низкий порог входа, быстрое прототипирование — позволят экономить бюджет. До тех пор, пока кривая проблем не начала расти (не сдвинулась с места), или не начался рефакторинг, или число модулей в вашей системе не выросло до двух.
Отсюда и область применения: скрипты инициализации, тестирование, небольшие хранимки в бд, сайты с линейной логикой работы, различные примитивные СМО и пр.
* на длинном периоде, при относительно большом коде, с рисками изменения бизнес-логики, для задач сложнее чем на одну неделю, для кода которые надо будет поддерживать — лучше сразу начать писать на языках со статической типизацией ( возможно с включением скриптов на динамических языках ). Потому что линейный рост числа проблем (а не галлопирующий экспонентой) в зависимости от объема кода — очень даже комфортен. Причем выбирать стоит те языки, у которых как можно меньше проблем с обратной совместимостью.
А корелляции между «сильной» и «слабой» типизацией я не заметил.
Я не могу запретить вам его осуждать, но рассуждения, особенно логически стройные, буду рад услышать.
Я принял вас за очередного молодого адепта «новомодных языков». Извиняюсь)
Звучит она, на мой взгляд как «Больше языков. Аляпистых. Новых. МОДНЫХ. И не важно что будет потом».
Лично мое впечатление такое, что подавляющее число «создателей новых языков программирования», не имеют серьезного опыта разработки, и вообще подходят к этому делу как к приключению, к блогу, созданию развлечения для фанатов.
— «Обратная совместимость выпускамых ими версий языков? Зачем, ведь у нас есть новая вкуссная фича, мы впилили ее — вот, смотрите!». А то что вы не сможете перевести свой проект на новую версию потому, что вам надо будет переписывать мегатонны кода — это их уже не волнует.
«Ну и что! Зато смотрите как у нас бложик с этой фичей красиво обрабатывает тысячи твитов в секунду!» — Ну вот разве не так? Посмотрите на новость о снятии с поддержки руби 1.8 (кажется, поправьте меня). Мол, «грустно, конечно, что снимается с поддержки, прошло 2.5 года с момента выпуска, но эта версия до сих пор используется, потому, что код написанный для руби 1.8 не работает на интерпретаторе версии 2». (Так, или почти дословно.).
Занавес. Привлекли, поигрались, и кинули.
Не предупреждают создатели «самых правильных языков» своих «последователей», и о тм, что «язык для быстрого написания прототипов», «динамической типизацией» и «идеально правильным ООП» — на самом деле крайне редко подходит для серьезных задач, больших систем со сложной логикой, и суровых будней поддержки промышленного кода. А может и не могут предупредить, потому, что сами не знают, или не думают что их последователи будут «пихать невпихуемое». А может и знают, но хотят посмотреть что из этого выйдет — ведь не своими деньгами рискуют, а «если что» скажут типа — «Ну наш язык же для быстрого написания прототипов, о чем вы, не надо было конечно так делать».
В общем статья хоть и «кривоватая», но она о правильной проблеме — будьте осторожны с очередным «самым новым языком». Скорее всего это просто очередная мода.
И особенно осторожны будьте, пока не увидите проблемы и границы применимости языка, пока язык не найдет свою нишу.
Как всякий логический и технический инструмент, язык программирования — имеет свою область применения. Применять технический инструмент, не понимая когда этого делать не надо — это чистой воды глупость. Но как раз о недостатках своего детища — в эпоху «рекламы и красивых бложиков» — создатель нового языка, "который, как оказалось, понравился не только ему" — не предупреждает.
Об этом статья. Имхо.
полномасштабных исследований наверное нигде нет, разве что какой нибудь институт, который поддерживает методы оценки трудоемкости разработки, в результате своих исследований, выставит завышенные коэффициенты связанные с языком напротив языков с динамической типизацией.
но вот проблема в том, что серьезные большие институты, ориентированные на исследование промышленных методов разработки ПО — не очень интересуются языками с динамической типизацией. ну… мне так показалось, когда я исследовал вопрос о методиках оценки трудоемкости разработки.
я говорю о методиках оценки типа FPA (метод баллов функциональности), COCOMO / COCOMO 2, UCP (usecase point analisys? — как FPA, но только принимает на вход прецеденты использования.).
Поясню про коэффициенты связанные с языком разработки: во всех этих методиках, как правило вычисляются некие баллы сложности алгоритма/структры которая описывается в задании на разработку, а потом эти баллы пересчитываются в человекочасы умножением на кучу разных коэффициентов. среди прочих коэффициентов есть и связанные с языками разработки.
и тут такая особенность: институты, которые разрабатывают эти методики нацелены на промышленные, «серьезные области» — собственно там, где методы оценки трудоемкости очень важны. те области, где сбой в работе по имеет серьезные экономические или даже материальные последствия. или где комплекс программ сложный а процессы — часто запутаны. где проблем много, даже если системы не обрабатывают массовые заявки (т.е. гуглемейл или вконтактик с одноклассниками и фейсбуками например — они не показательны ни разу — это не промышленная разработка. они массовы, огромны, но их «бизнеспроцессы» достаточно примитивны и потому легко масштабируются. они очень просты по сути, даже в сравнении с обычной СЭД, или системой бухгалтерского или складского учета).
так вот — в этих областях традиционно(?) языки с динамической типизацией не выживают. не востребованны они теми, кто несет серьезную ответсвенность. как то вот так случилось.
и в результате, ничего что касается языков с «динамической» типизацией, я в исследованиях больших институтов я не видел. были коэффициенты для C/C++, Java, Paskal. даже бейсик кажется был. но джаваскрипта, руби, питона там я не помню.
занимался исследованием методов оценки лет 5 назад, может сейчас что и изменилось, поправьте если что))
я к чему: ссылаться на статстику — нельзя. никто не будет проводить масштабные сраврительные исследования для кучки популярных в этом году технологий. простите, но пхп был популярен пять лет назад, питон был популярен в позапрошлом году. в этом руби на коне… никто не заплатит за такие исследования.
поэтому мы можем основываться только на собственном опыте и анализе успеха длительных промышленных проектов с которыми столкнулись и в которых участвовали.
и на модели, котрые описывают как мы ведем разработку, типовые проблемы, ситуации в работе, которые мы можем легко или сложно решить используя разные языки.
(например, рубисты вынуждены ренерить xml кож вручную, и вручную писать правила проверки, что бы xml соответвовал требуемому xsd; на джава же этой проблемы нет вообще — на основе xsd кодогенератором делаются классы с анотациями, и при парсинге/сериализации все правила xsd проверяются автомтатически == следовательно на джава разработать алгоритмы для wsdl-вебсервисов быстрее).
или другой прмер: при рефактоинге кода, изменнии структуры классов и их методов, для динамических языков нет методов которые позволили бы понять, где используется изменяемый класс. что бы выявить все эти места, нужно проводить масштабное тестирование, что трудоемко. а в случае языков со статической типизацией — все места использования класса, типа, метода проверяются сразу компилятором, и более того — IDE спомбна выполнить 90%работы по анализу кода за нас. == рефакторинг кода написанного на ryby/javascript это более трудоемкая процедура, чем скажем рефакторинг кода на java илиc++.
логические рассуждения, не больше)))
по поводу опыта могу вам сказать так: только через 8-10 лет после института, я начал понимать почему, например, на PHP очень геморройно делать большую сложную систему типа СЭД. и что проблема не в пряморукости, а в глубинных свойствах самого языка и инструментария.
и то, я начал это понимать только после того, как сам поучаствовал аналитиком 2 года на одном проекте внедрения системыдокументооборота, написанрой на пхп, как поразбирал багрепорты, как безуспешно разработчики пытались решить эти проблемы, и как система постепенро дохла, вплоть до невозможности собрать статстику по обработке поручений за неделю в течении 6 часов.
то что вы скептически относитесь к утверждениям, что статическая/жесткая типизация помогает контроллировать код — мне очень понятно. я сам был таким))
но поразмыслите детально, и педантично.