А что там с Groovy? Что с ним не так?

Навеяло аж отдельной статьей про выход Scala 3.
Да и некоторыми своими причинами

Вопрос джавистам — что с ним не так, с Groovy?
Кто щупал, какие личные впечатления, ощущения?

Для больших проектов понятно что незачем его брать, не даст ощутимого приращения скорости разработки. У больших проектов затраты времени на разработку не в ЯП.

Но в бытность в мире Джавы, казалось мне что что отличные перспективы у него:
Начинаем проект на Groovy, узкие места, модули — делаем/берем на Джаве

Виделось ему место для проектов где джанга, руби, пхп на ларавеле сдуваются. и т.д.
Да и бекендовая Нода, как бы не нужна была б, если б...
С такой надежной экосистемой Джавы...
Непонятно все таки с ним, чего с ним не так.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Груви — это было круто. Это был глоток свежего воздуха на фоне всем надоевшей седьмой джавы.
Там были лямбды, функции высшего порядка, миксины. Нормальное интерполирование строк, метапрограммирование, примитивы для построения ДСЛей. Программировать снова стало интересно.
Ну а тестирование через Spock.. Под капотом там конечно все не очень. Но вот чисто синтаксически, если смотреть на итоговый код тестов — это самый красивые, самые выразительные тесты, которые я видел, не зависимо от языка.
А ещё была ежегодная конференция в Копенгагене, с крафтовым пивом в день закрытия. И в отличие от джавы с сотней чемпионов но без Гослинга, Блоха, Гоетца, там реально были все: авторы второй версии груви, автор Грейлз, создатель Грейдла.

Но потом оказалось, что динамическая типизация уступает в производительности, причём в разы. Пришлось добавлять аннотации типов. А ещё отсутствие типов не улучшает поддерживаемость кода. Ну а переход на толстых клиентов несколько нивелировал преимущества Грейлз над JSP/JSF и что там ещё было монструозного в JavaEE.

Ну а потом таки вышел каменный цветок зарелизили восьмую джаву, а вслед и девятую. И несмотря на традиционно-громоздкий синтаксис, все те же фичи — лямбды, функции высшего порядка, миксины — вдруг стали доступны и без смены языка.

Ну а следом у Pivotal закончились деньги, и спустя ещё полгода оказался Груви очередным экспонатом в Apache...

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Для больших проектов понятно что незачем его брать

Groovy, таки дает серьезное сокращение кода, которое будет куда заметнее для больших проектов. Многих пугает динамическая типизация, но это вполне решается внятным code conventions и code review

Перспективы у него были, но потом появились Kotlin и Clojure:
— одним из design goals для Kotlin было — уметь делать все, что делает Groovy, но с принудительной статической типизацией, и минимальным оверхедом.
— для любителей динамической типизации и метапрограммирования Clojure предлагает много больше того, что было у Groovy.

Т.е. с самим Groovy все так, но
— вокруг него никогда не было хайпа, и его не продвигали большие организации
— он никогда не был популярным, и о нем знали единицы

Groovy зручний для скриптових завдань. Швидко написати і забути.
Там де потрібна підтримка, постійно читати і розбирати код, проект на Groovy перетворюється в нічний жах.
Після того, як Gradle перейшов c Groovy на Kotlin пару років назад, я взагалі забув про його існування.

Ще б подібне розуміння прийшло у фронтенд.

Динамическая типизация и выразительный язык, соответственно очень дорогой мейнтенанс. Пишешь быстро, разрабатывать приятно, поддерживать ужасно.

На самом деле стоит спросить: что с груви так, в чем его преимущество перед java?

Сильное сокращение кода.
В презентациях были цифры от 60% (только из-за синтаксиса) до 600% (из-за правильно применяемой динамической типизации)

1. В какой презентации?
2. Есть Scala, Kotlin, Clojure ets. Декларируются как более гибкие по сравнению с java при этом у каждого есть своя киллер-фича для ряда продуктов, чем груви их лучше?

1. Когда-то видел презентацию с анализом кодобазы groovy и java проектов — там приводились эти цифры. Сейчас за 5 мин нагуглить не смог.
2. Я и не утверждаю, что он лучше «Scala, Kotlin, Clojure ets».
Тем более, что Groovy возник, т.к. автор не знал про Scala

1. Ну ты же понимаешь, что какая-то презентация которую ты даже не смог найти не аргумент? На заборе тоже пишут
2. Так если он не лучше и не имеет своей ниши зачем он нужен? Все вышеперечисленные языки нишу имеют

1. цифры примерно сопадают с личным опытом (большой проект с Grails) но точных замеров я не делал.
2.

что с груви так, в чем его преимущество перед java?
Сильное сокращение кода.

Вы спрашивали про Java vs Groovy.
В контексте «других языков», я уже ответил

Недавно перешёл с Java на Groovy. Поиск ошибок та ещё боль. Скорость разработки увеличилась, но поиск ошибок компенсирует это. Фронтенд пришел к строгой типизации, а в Groovy наоборот

Недавно перешёл с Java на Groovy. Поиск ошибок та ещё боль.

все правильно.
на яп с дин типизацией надо по другому писать, структурировать код

вот наверное она, главная причина что с Groovy не так — переучиваться надо было с Java

Фронтенд пришел к строгой типизации

Угу. Точно так же как бекенд ушел в облака и серверлесс микросервисы

вот наверное она, главная причина что с Groovy не так — переучиваться надо было с Java

Груви какраз позволяет (в отличии от скал и кложур) писать как 1 в 1 на джаве, там совсем мало синтаксических изменений надо.
Другое дело что когда начинают использовать и злоупотреблять фишками языка, особенно динамику и дсл строение, это таки может превратиться в боль для читающих и поддерживающих. Ну прям как с дженкинсом и получилось )

Груви какраз позволяет (в отличии от скал и кложур) писать как 1 в 1 на джаве, там совсем мало синтаксических изменений надо.

Это было до java8 — синтаксис java7 был частью синтаксиса Groovy. С появлением лямбд в java это стало не так.

вот наверное она, главная причина что с Groovy не так — переучиваться надо было с Java

К стати, да
Для понимания, как его «правильно готовить и не обжечь пальцы» потребовался примерно год.

Будь-яка мова або платформа без серйозної комерційної підтримки приречена загнутися.

Подивіться на кубер або голанг. Або на тераформ. Або тайпскріпт. Або реакт. Вони всі активно розвиваються і програмісти активно пхають їх куди треба і не треба тому що великі компанії роблять потужний маркетинг.

Інструменти розробки (а мова це інструмент) це точно такий самий продукт як і будь-який інший. Його так само треба просувати та продавати інакше зась.

Очень долго писал на Groovy (около 8 лет). Был основным бекенд языком в проектах.
Сказать что он плохой не могу, немного только страдает performance (как правило, если делать не правильно).
Скорость разработки выше, кода меньше. Мне лично, синтаксис зашел и даже очень (после него на Java пишешь и кажется, что все долго).

Недавно почитал Kotlin, понял, что там 80% Groovy.

Не пониманию, почему он как-то стал уходить.

Груви нужен был для того, чтобы Java не умерла на 7-й версии, а всё же добавила все ключевые плюшки в 8-ю.

Но в любом случае, Kotlin убьет все JVM языки (если не уже, кроме Java пока что. И то Android уже под Kotlin).

Ага.
5 раз уже убил. Котлин или сконает через пару лет, как груви, или останется нишевым андроидоязом.

Ну так груви уже мёртв. Что там еще осталось? Scala? Я не слежу за этим языком, на ваше рассмотрение живучесть данного языка.

Под андроид большинство вакансий просит уже знание основного языка как котлин (и в дополнение уже жабу).
Сейчас котлин уже под веб выбивается потихоньку, не знаю как там успехи, но знаю одну контору, которая бэк пишет под котлин и норм.

Ключевая особенность котлина это конечно поддержка гугла и интелиджа. Из плюсов вывели язык в мир (ведь они точно так же, тот же груви могли вывести спокойно). Ну и из минусов это если им это надоест, язык быстро умрёт (если не успеет экосистемой обзавестись). Так что здесь как плюсы, так и минусы

но знаю одну контору, которая бэк пишет под котлин и норм.

Это потому что на котлин еще не прошел хайп.
Кроме того, у котлина есть «доп. жизнь» в виде того, что его пушит сам ЖетБрейнс

мое ощущение от Котлина — то что надо!
Но, опоздал.
Если б вот во времена 7ой Джавы вышел, то и на 8ую бы с него уже не возращались бы.

А так, очень правильные улучшения, без скаловской академичности, а практично-прагматичные

мое ощущение от Котлина — то что надо!

ЖетБрейнс же не зря статистику использования собирает.
Поэтому и сделал то, что нужно, а не воплощал влажные мечты трех с половиной функциональных гиков.
Вполне возможно, что котлин даже и неплох. Его портит идеологическая и фактическая вендор-зависимость. Поэтому, я думаю, котлин максимум останется нишевым языком для андроида.

По крайней мере, я бы не хотел жить в будущем, где российская компания владеет влиянием, близким к монопольному, на ЯП, получивший широкий адопшн, сравнимый с адопшнами языков типа джавы и питона.

российская компания

JetBrains s.r.o. is a Czech software development company
Headquarters: Prague 4, Prague, Czechia

то, что у них есть филиал разработки в России — это да.

то, что у них есть филиал разработки в России — это да.

список офисов вообще-то есть у них на сайте.
www.jetbrains.com/ru-ru/company

написано там
1500 сотрудников
Пражский офис специализируется на продажах продуктов JetBrains в Европе, Африке, Азии и Австралии. Сейчас в нем работают более 50 человек

Кто кому филиал...

Пражский офис специализируется на продажах продуктов JetBrains в Европе, Африке, Азии и Австралии. Сейчас в нем работают более 50 человек

Кто кому филиал...

То есть, слово headquarters ни о чём не говорит. Ясно-понятно.

Хоть 100500 сотрудников у них в Питере, формально — это именно филиал, или подразделение.

І яндекс не рфіянська компанія, бо зареєстрована в Нідерландах

о есть, слово headquarters ни о чём не говорит

слово?
говорит конечно.

только понимаете, я как-то склоняюсь в отношении к словам
На сарае х-й написано, а там дрова.

Но, тут каждый сам себе вырабатывает конечно, отношение к словам.
Говорят, если правильный набор слов сказать, такие наборы заклинаниями называются, то ого чего можно натворить!
главное ж — слова правильные знать. и все.

формально — это именно филиал

Что значит имя? Роза пахнет розой, Хоть розой назови ее, хоть нет.
У. Шекспир

Русня в керівництві компанії та майже всі розробники — то нічого. Головне шоб формально офіс був у Празі ;)

Русня

Зашкварена чи і вашим і нашим?

Русня в керівництві компанії

Одно слово «русня» уже выдаёт человека с патриотизмом головного мозга.
Среди совладельцев JetBrains есть российские чиновники, гос. структуры или, хотя бы, приближённые Путина?

Или это, всё же, частная компания, которой исторически не повезло быть основанной в России?

Одно слово «русня» уже выдаёт человека с патриотизмом головного мозга.

focus.ua/...​paciya-kryma—levadacentr

Или это, всё же, частная компания, которой исторически не повезло быть основанной в России?

Релокація і викидання вати за межі компанії

focus.ua/...​paciya-kryma—levadacentr

В реальности, среди именно IT специалистов в России есть немало адекватных ребят, которые всё прекрасно понимают и про Крым, и про Украину в целом. Другое дело, что многие боятся выражать своё мнение открыто — за поребриком, это может быть чревато вполне реальными неприятными последствиями.

Вместе с тем, поддерживать Путина и его политику уже считается моветоном среди тех россиян, которые умеют думать и анализировать. И об этом, в последнее время, уже даже не боятся писать в соц. сетях.

многие боятся выражать своё мнение открыто

dou.ua/...​/articles/moscow-riot/#11

Ви говорите красиві речі — реальність вона інша
www.epravda.com.ua/news/2016/05/20/593411
informnapalm.org/...​virusnaya-kompaniya-eset

умеют думать и анализировать

не допомагає від пропаганди
Воно якраз навпаки, дозволяє вам знаходити все більш і більш цікаві способи викривлювати реальність

многие боятся выражать своё мнение открыто
в последнее время, уже даже не боятся писать в соц. сетях.

Интересно что бы ему у нас бы сказали, если бы к нам русский приехал, и «Cлава России» писал бы?
Я сомневаюсь что реакция наших отличалась бы от реакции их.

Хоча б одне те, що у нас тут можуть виправдовувати поведінку рфін каже про ситуацію більше ніж треба

у нас тут можуть виправдовувати поведінку рфін

Не знаю, где ты тут такое прочёл. Поведение российских властей никто не оправдывает.

Разговор шёл только о том, что, по сравнению с 2015м годом, всё больше российских граждан прозревают и перестают поддерживать и оправдывать то, что творит их Пуйло.

dou.ua/...​/articles/moscow-riot/#11

Статья 2015 года. Я вполне верю, что на тот момент времени примерно так всё и было. Но, за пять с лишним лет, настроения россиян несколько поменялись (хотя, ваты, конечно, по-прежнему хватает).

informnapalm.org/...​virusnaya-kompaniya-eset
не допомагає від пропаганди

Видимо, действительно, «не допомагає», раз в качестве контр-аргумента ты сам приводишь пропагандистский источник, только украинский.

А що з 15 року змінилось?

Може Крим повернули чи на Донбас перестали посилати військових?

Там в тексті є лінки на оф відмазку від есета

пропагандистский источник, только украинский

Яка гарна гумореска

А що з 15 року змінилось?
Може Крим повернули чи на Донбас перестали посилати військових?

Изменилось отношение самих россиян к этой политике партии. Ну, по крайней мере, тех, кто умеет думать и самостоятельно анализировать ситуацию.

Было видео недавно из, кажется, Сантк-Петербурга — как раз, когда Пуйло наращивал войска вокруг Украины — шла процессия и скандировала «Нет войне с Украиной!»

И, да, Киселёва с Соловьёвым там сейчас нормальные люди не смотрят (ну а вата неизлечима).

Там в тексті є лінки на оф відмазку від есета

Вот эту?
www.welivesecurity.com/...​/Operation-Groundbait.pdf

Потрудись ткнуть пальцем, где именно там отмазка, и в чём состояли официальные претензии к ESET (а не домыслы неизвестных журналистов ИнформНапалма)?

Яка гарна гумореска

Дальнейший разговор не имеет смысла. Если ты не понимаешь, что пропаганда есть не только с российской, но и с украинской стороны, то разговаривать дальше просто не о чём.

Изменилось отношение самих россиян к этой политике партии. Ну, по крайней мере, тех, кто умеет думать и самостоятельно анализировать ситуацию.

Скільки це чоловік?
Наскільки їх стало більше в порівнянні з 15

І який відсоток підтримки дій держави треба, щоб можна було робити рф <=> рфіянці ?

где именно там отмазка

eset.ua/...​-the-operation-Groundbait
Пффф, до речі дякую, я хоч сам почитав тех доки

В реальности, среди именно IT специалистов в России есть немало адекватных ребят,

Никто из них не будет рисковать если что. Скажуть слить данные — сольют. В Яндексе то же большинтсво адекватных наверное, но это не мешало править карты во время Майдана и сливать данные о протестующих в Минске.

Про «рисковать» — это было не про отдельных сотрудников, а про компании.

У тех же Яндекса и ВКонтакте, по сути, нет платящих клиентов вне СНГ — поэтому, для них репутационные риски сотрудничества с российским правительством мизерные, а вот отказ от сотрудничества очень сильно ударит по их бизнесу.

Обсуждаемый же JetBrains очень даже заинтересован в «рукопожатности» в Европе и США, и им такие «зашквары» ни к чему. Да и рычагов давления, как я уже писал, на такие компании гораздо меньше — интеллектуальную собственность не отожмёшь, деньги тоже не особо (т.к. в Россию скорее всего заводятся суммы только для операционной деятельности).

выдаёт человека с патриотизмом головного мозга

Хлопче, ознайомся шо таке патріотизм для початку чи шо ;)

Світова спільнота наразі трохи впи-на, і недобачає наскільки агресивними та небезпечними є насправді більшість рускіх. Але все проходить і це пройде.
Тому досить скоро буде як мінімум поганим моветоном покладатись в своїх інформаційних рішеннях на російські продукти.

досить скоро буде як мінімум поганим моветоном покладатись в своїх інформаційних рішеннях на російські продукти

Начни с себя — удали nginx.
А также Acronis TrueImage и clickhouse, если используешь.

кстати да, создатель нгинкса действительно упоротый ватник

Є який комент на tj і більше щось нічого не видно з цього приводу

Є якісь лінки про це?

А выгораживание народа РФ в осуществлении военных преступлений власти, выдает человека с синдромом плюшевости.

Среди совладельцев JetBrains есть российские чиновники, гос. структуры или, хотя бы, приближённые Путина?

А сколько среди убивающих на Донбассе Путиных, Медведевых, Лавровых и Шойгу?

Или это, всё же, частная компания, которой исторически не повезло быть основанной в России?

Она заявила ноту протеста против политики страны и ухала с РФ с релокейтом сотрудников? Нет? Значит она поддерживает или относится нейтрально к происходящим преступлениям и финансирует эту машину своими налогами, а то и находится в кооперации с силовыми структурами. Есть гарантия что там точно нету слежки например?

выгораживание народа РФ в осуществлении военных преступлений власти

Ты сейчас какой-то полный бред написал. Военные преступления совершают власть, армия и наёмники. Какое отношение к этому имеет обычный программист или даже владелец ИТ компании, если только явно и публично не поддерживает словом и делом «политику партии» (но JetBrains, насколько я знаю, в таком замечены не были).

Да хотя, вон тот же Сысоев, которого тут назвали записным ватником — и что, это кому-то мешает пользоваться nginx?

А сколько среди убивающих на Донбассе Путиных, Медведевых, Лавровых и Шойгу?

На Донбассе убивают далеко не программисты и не менеджеры. Это либо солдаты, у которых приказ, либо наёмники. ОК, наверное, есть единичные случаи, когда у какого-то айтишника «упала планка» и он пошёл в наёмники или в армию, но это именно единичные случаи.

Она заявила ноту протеста против политики страны и ухала с РФ с релокейтом сотрудников? Нет? Значит она поддерживает или относится нейтрально к происходящим преступлениям и финансирует эту машину своими налогами, а то и находится в кооперации с силовыми структурами.

Сколько ты вообще знаешь бизнесов, которые поступали так, как ты описал выше? Не только в России, а вообще в мире. Сразу скажу — пример про уход из России западных технологических компаний невалиден, поскольку, хоть подаваться это могло и под соусом протеста, но, на самом деле, их бизнес в России как таковой потерял смысл по объективным причинам.

Если у тебя есть деньги в рф, и ты не приближён к едру и Путину — либо ты п***ун и денег у тебя нет, либо их совсем скоро не будет, если не пойдёшь проситься дружить и делиться. В Украине, тащемта, ничего иного.

В Украине, тащемта, ничего иного.

Именно так, поэтому не стоит путать «обычные» для стран бывшего совка коррупцию и крышевание бизнеса с сознательной поддержкой агрессии по отношению к Украине.

Среди совладельцев JetBrains есть российские чиновники, гос. структуры или, хотя бы, приближённые Путина?

Конечно же нет. Всем же ясно, что когда товарищ майор будет делать предложение от которого нельзя отказаться бравый девелопер с JetBrains откажет..

Ты мля серьезно вот эту шляпу постанул? Взрослый вроде человек...

Сам ты шляпа :) Юридически, что JetBrains, что Яндекс уже давно не российские компании.
А у кого где центры разработки находятся — так кого это волнует, кроме излишне озабоченных патриотизмом.

Ну это какая-то непуганная наивнота 9000.
Ты как будто откуда-то из 2008го года пишешь.

Можешь сразу поднять ставки до 10000 :) Нет, 10000 мало, до 20000.
Только вот, не знаю, как в 2008м, а в 2021м году очень много украинских разработчиков пользуются nginx и продуктами JetBrains.

И это я уже не говорю про официально благословлённую Гуглом Android Studio, которая собирается практически из той же кодовой базы, что и IntelliJ IDEA.

Но ты продолжай верить, что от этих продуктов откажутся только потому, что они разрабатываются в России.

Пойнт был в другом, ты не понял, ну и пускай.

Так, может, стоит нормально объяснить, вместо того, чтобы переходить на личности?

Если ты про то, что компании наподобие JetBrains настолько подконтрольны Путину, что он с их помощью способен устроить кибер-диверсию — то это звучит как слишком уж теория заговора.

Я потому и делаю акцент на том, что юридически эти компании не российские — скорее всего, вся их интеллектуальная собственность зарегистрирована на западную компанию, вся критическая инфраструктура тоже скорее всего там (как минимум, отзеркалирована), да и владельцы вряд ли живут в России, если не дураки.

Соответственно, что самого худшего может сделать российская власть, если захочет оказать давление (а добровольно на такие гадости ни одна компания, которая делает бизнес не только в СНГ, не пойдёт)?

Отжать офис? Ерунда, в пандемию все давно уже научились работать из дому.

Пересажать всех программистов в тюрьму? Ну, Путин, конечно, ...уйло, но не идиот, чтобы устраивать такое.

Это, разве что, если у их спецслужб есть серьёзный компромат на совладельцев... там, да, могут прижать втихую.

Еще оказалось он назван в честь скрепного Кроншдада где большивики расстреляли несколько тысяч матросов которые против них востали когда поняли, что комуняки хуже белых.

мое ощущение от Котлина — то что надо!

Как он может быть хорошим, если там обьявление типов точь в точь как в TS?
Что за двойные стандарты?

Что за двойные стандарты?

какие еще двойные стандарты?

а, да, для догматика адекватность, релятивизм так выглядят :D
я же писал уже вам — вы нифига не поняли за что я топлю.
и предложил найти в себе каплю мозга.
но, не нашли....

Если б вот во времена 7ой Джавы вышел, то и на 8ую бы с него уже не возращались бы.

Во времена java7 уже был Groovy2 с его @CompileStatic.
Но это его не сильно спасло.

Kotlin уже плотно влез в микросервисы, он уже не андроязык

ряд инвест банков уже давно крутит микросервисы на котлине

да и помимо них есть куча фирм большей и меньшей величины где крутят микросервисы на котлине

или тебе ссылка на гит нужна? если да, то её не получишь, да и никто тебе не даст

есть ли в Украине такие проекты? без понятия, в украинских фирмах давно не работаю, не знаю что они там делают

Я маю на увазі реальні приклади у вільному доступі про які я можу почитати

(Бо я можу приблизно те саме про cobol написати і навіть не сильно збрехати)

Котлин или сконает через пару лет, как груви, или останется нишевым андроидоязом.

На Kotlin backend сейчас уже полно вакансий, есть из чего повыбирать.

Ну и что?
Котлин на бекенде постигнет судьба груви.

Одного вашего желания (не учить новый язык) для этого будет мало

Кто щупал, какие личные впечатления, ощущения?

Я хоть не джавист, но щупал. Мне в целом понравился.

Непонятно все таки с ним, чего с ним не так.

Думаю, что с ним та же проблема, аналогичная у руби. У руби есть по сути только один популярный инструмент — рельсы. Вот и у груви — есть один или два востребованных инструмента (основное — это наверное Gradle, может Jenkins, может Groovy on Grails, может Griffon или Micronaut, что-то из этого), и все. Т.е. я бы сказал, что груви находиться в том же положении, что и руби с рельсами (типа умрут рельсы, умрет и руби, что-то такое думаю и насчет груви). ИМХО, конечно.

Непонятно все таки с ним, чего с ним не так.

Думаю с самим Groovy все так. Просто появился Kotlin.

Т.е. я бы сказал, что груви находиться в том же положении, что и руби с рельсами (типа умрут рельсы, умрет и руби)

аналогичные ощущения.
тоже большой, но уже другой вопрос — почему бывают ЯП только одного фреймворка?
что такого в ЯП, какие его свойства делают его таким?

ну как в писательском мире, не редкость — писатель одного романа. суперского!
остальное что писал — забылось, потому что постыдное гуано.

Редкость скорее обратное — много-где-применяемые языки. Многие популярные ЯП-ы сегодня — для определенного круга задач.

Многие популярные ЯП-ы сегодня — для определенного круга задач.

все так. причем, почти число случайно так вышло :)
на старте их авторы задумывали ЯП обычно для других задач

Swift -> под Apple
Kotlin -> если не под Android то зачем?
Dart -> прямиком под Flutter
Go -> для микросервисов и сетевых утилит
TypeScript -> для Node.js Back-End-а

Я бы не сказал, что прямо случайность. Особенно, если принять во внимание отутствие каких-бы то ни было явных попыток впихнуть подобный фреймворко(экосистемо)-зависимые язык куда бы то ни было еще

Swift -> под Apple

нет, Apple сделала Swift чтобы ни от кого не зависеть.
Они всё так стараются делать.

Kotlin -> если не под Android то зачем?

Авторы задумавали как улучшенню Джаву, видя что Скала — «ни шмагла»

Dart -> прямиком под Flutter

Дарт задумывался как замена Джавы на беке и особенно в Андроиде, чтобы больше с Ораклом не судиться

Go -> для микросервисов и сетевых утилит

Тут да, Пайк задумывал для этого

TypeScript -> для Node.js Back-End-а

Портированный Хейлсбергом C#, да.

Я бы не сказал, что прямо случайность

Java задумывалась для кофеварок, и прочего эмбедеда.
А стала — главной на серверах надолго.

JS задумывался как ЯП для мелких вставок кода выполняемого в браузере

Python задумывался как учебный ЯП, вместо Pascal, еще более упрошенный, для начинающих

PHP задумывался как просто тулза, даже не ЯП, для инлайнинга в html

нет, Apple сделала Swift чтобы ни от кого не зависеть.

А от кого они с Obj-C зависели ? 0_0 Я то по наивности думал, — что чтобы облегчить и ускорить разработку.

Я то по наивности думал, — что чтобы облегчить и ускорить разработку.

ну тогда используйте его вне экосистемы Apple, раз он ускоряет разработку
ну или примеры приведите

Apple делала его — для себя. Не пытаясь использовать что-то сторонее на замену Objective-C

Так же поступил FB и сейчас у них HHVM

То есть они не «сдедали, чтобы ни от кого не зависеть», так как и с Obj-C они ни от кого не зависели, а сделали все таки, чтобы ускорить и упростить разрабтку, просто сделали это в корпоративном стиле: создали собственный ЯП.

сделать для себя — не означает сделать себе плохо

мало того, сделать что-то ради того чтобы оно замедляло и усложняло разработку, ну... фик его знает, почему такая штука становится известной настолько что ее стоило упоминать...

а

Swift -> под Apple

и

создали собственный ЯП.

масло маслянное.

Ессно Swift -> под Apple потому что они его сделали — для себя :)

При этом в исходном посте было:

задумывали ЯП обычно для других задач

Является ли Apple — задачей?
как правая часть в остальных пунктах:
... -> если не под Android то зачем?
... -> прямиком под Flutter
... -> для микросервисов и сетевых утилит
... -> для Node.js Back-End-а

Так что вы хотели сказать то? ;)

Дарт задумывался как замена Джавы

не тільки
Ще задумувався як «покращений прискорений javascript», у них навіть якась там Dart VM для браузера була і компілятор Dart -> JS

здається що ні.
то вже потім, як не вийшло з заміню Джави, вирішили
а може для Dart -> JS?
нє, теж не пішло.

але може бути, що так відразу планували, не слідкував.

тоже большой, но уже другой вопрос — почему бывают ЯП только одного фреймворка?

Насколько я понимаю, так исторически складывается. Вот, например, взять еще один пример языка одного фреймворка — Elixir (с Phоenix’ом). Почему в эликсире юзается в основном феникс? Думаю тупо из-за того, что создатель эликсира — бывший разраб рельсов, и спроектировал эликсир по образу и подобию руби, а там уже по проторенной дорожке — Phoenix по подобию Rails.
Аналогично, насколько понимаю, произошло и с груви ранее, ибо насколько знаю Groovy во многом был вдохновлен рубями (и вроде бы чуть ли не сразу же после создания Groovy, был написан Grails).

P.S. Притом, что в руби, помимо рельсов есть еще Sinatra, Padrino, Hanami и еще несколько (также еще есть генератор статических сайтов Jekill, который правда поверх рельсов если не ошибаюсь). Кто-то их вроде юзает, но популярны и востребованы почему-то только рельсы (насколько я знаю). Думаю аналогичная фигня с Groovy и Elixir’ом. Почему? Хз, так исторически сложилось....

ну как в писательском мире, не редкость — писатель одного романа. суперского!
остальное что писал — забылось, потому что постыдное гуано.

Думаю в случае с художественной литературой — от писателя зависит. Если писатель смог написать один суперский роман, то это еще не значит, что остальные (менее удачные) — унылое г***, возможно это просто проходной середнячок ...хотя если это современный писатель, то есть большая вероятность, что такие романы действительно могут быть унылым г****)))

почему бывают ЯП только одного фреймворка?

Все очень просто, нужно только абстрагироваться от сферы.

Люди приносят в мир идеи.
Идеи, грубо говоря, можно поделить на 2 категории.
1 — простые, но неожиданные решения старых проблем, выход за рамки, которые становятся революционными, и заходят большому количеству людей, приобретают широчайший адопшн и остаются условно навсегда. Пример — книгопечатание, компьютер, смартфон, джава.

2 — сложные, которые базируются на «я сделаю свой лунапарк с блекджеком и шлюхами». Появляются, срывают хайп, взлетают на пике популярности, потом стухают и растворяются в истории почти без следа. Еще с момента начала реализации эти идеи уже являются аутсайдерами с ярлыком «не для всех». И вот именно сюда попадают все груви, скалы, и прочие котлины в стиле «мы сделаем новый JVM-язык с ... и ... »

Причина исчезновения идей 2й категории в том, что идея должна быть очень удачной, и буквально открывать новые горизонты, чтобы перейти в 1ю категорию, а не предлагать какие-то минорные улучшения, которые крайне важны только для полутора фриков.
Джава — да, стала революционной технологией по сравнению с С++.
Ни котлин, ни скала, ни груви не являются ни революционными, ни прорывынми, это просто «еще одна джава с новым синтаксическим сахаром и странным именем», которая, по сути, никому не нужна.
Для примера сюда же можно отнести и категорию смартфонов со складными экранами. Хайп, презентации, в итоге оказалось что это никто не покупает, потому что кроме ауры «технологической диковинки» 99% людей это на практике не нужно а оставшийся 1% никого не волнует.

Да и бекендовая Нода, как бы не нужна была б, если б...

Нода как раз принесла революцию — миллионы джс-макак смогли запустить свою мерзость не-только-в-хроме.

Хоть со Spring’ом работай в Groovy. Можно просто часть кода на нем писать.

Сдохнул, скоро так же сдохнет и скала.

Так давно уже, работу хрен найдещь.

у нас в городе уже давно :) я последний код на скале писал когда на спарке какую то залупу делал несколько лет назад

а на груви работы не было примерно никогда. Одного чувака знал с России так он там на грейлсах писал пока не перехал. 10 лет назад, больше я груви в не дсл форме не слышал даже

Разве шо тока на дженкинс всякое говно писать ака девопс.

Юзал более 10 лет назад. Я тогда думал что за груви будущее. Почему оно не взлетело тож досих пор хз — куча плюшек синтаксиса, легкая двустороняя интеграция с джавой, легкое скриптование, итд итп. Увы но нет.

Вот и я думал. Со Скалой у меня не было вопросов, когда я её копнул в период хайпа. Не жилец.

Ну скала какраз взлетела, и реально использовалась (потом померла). Груви — я не видел, очень мало вакансий было лет 10 назад, и то пропали.

Груви — я не видел

точно знаю, сайт Укртелекома был сделан на Grails
вылетел как-то стектрейс :D
потом посмотрел, да, урлы грейлсовские

Ну скала какраз взлетела

на хайпе много чего взлетает.

Еще помню, Clojure немало ахов и охов в джава тусовке вызвала.
и баталии между мечтающими перейти на скалу и мечтающими на кложу :)

хайп он такой, иногда вдохновляет и на действия, а не только на разговоры о высшей моде :)

помню белужий вой чуваков у которых была кложура на проде. очень плакали

До сих пор всякие быстрые тесты пишу в Groovy console в IDEA. Там, где нужно что-то проверить, скриптовым подходом.

за последние годы груви попадался только в виде dsl для чего либо другого и это было довольно противно по ощущениям. После груви в дженкинсе хочеться руки с мылом помыть

Имхо, проблема кагбы не в груви как таковом, а в тех руках что тот дсл писали...

результат одинаковый: все кто пробовал обычно оставался с привкусом говна и решал что он как то так постоит без груви.

в кубе. у меня ярости не хватит описать как я это говно не люблю

у меня ярости не хватит описать как я это говно не люблю

www.youtube.com/watch?v=DNfrmqotQYU

Якщо груві — скриптова мова, то його смерть не дивує. Кому в 2021 потрібні нові скриптові мови. Це як нова модель возу.

— Сину, ти чого в 14 років вживаєш горілку??!!
— В школі на уроці інформатики змусили писати на Javascript ;(
— Давай я тобі ще вина принесу...

шта?
он с 00-х, кагбы давно не новый язык.
Груви не (только) скриптовый язык — вполне компилируеться в джава байткод.

Груви — это было круто. Это был глоток свежего воздуха на фоне всем надоевшей седьмой джавы.
Там были лямбды, функции высшего порядка, миксины. Нормальное интерполирование строк, метапрограммирование, примитивы для построения ДСЛей. Программировать снова стало интересно.
Ну а тестирование через Spock.. Под капотом там конечно все не очень. Но вот чисто синтаксически, если смотреть на итоговый код тестов — это самый красивые, самые выразительные тесты, которые я видел, не зависимо от языка.
А ещё была ежегодная конференция в Копенгагене, с крафтовым пивом в день закрытия. И в отличие от джавы с сотней чемпионов но без Гослинга, Блоха, Гоетца, там реально были все: авторы второй версии груви, автор Грейлз, создатель Грейдла.

Но потом оказалось, что динамическая типизация уступает в производительности, причём в разы. Пришлось добавлять аннотации типов. А ещё отсутствие типов не улучшает поддерживаемость кода. Ну а переход на толстых клиентов несколько нивелировал преимущества Грейлз над JSP/JSF и что там ещё было монструозного в JavaEE.

Ну а потом таки вышел каменный цветок зарелизили восьмую джаву, а вслед и девятую. И несмотря на традиционно-громоздкий синтаксис, все те же фичи — лямбды, функции высшего порядка, миксины — вдруг стали доступны и без смены языка.

Ну а следом у Pivotal закончились деньги, и спустя ещё полгода оказался Груви очередным экспонатом в Apache...

подскажите как можно использовать нативно миксины в java?

Не зовсім так з Pivotal тільки.(Бо саме з 2014 до 2016 Pivotal сильно зростав). А підтримка була припинена в 2015.

Pivotal намагався продавати консалтинг з Groovy, але нікому це було потрібно з клієнтів.
Джава зрозуміло бо ентерпрайз, Ruby для стартапів. І ще вже зі три роки Скала набувала популярності.

Groovy не використовувався для внутрішніх сервісів (судячи з пошуку).

А потім ще й замість Jenkins вирішили зробити нормальний CI (перша публічна версія Concourse вийшла восени 2014) — і причин для філантропії не залишилось.

Добрими намірами вимощена дорога до пекла. Так і з груві, на папері класна штука, на ділі — розв’язує (і до цього не самим добросовісним) кодерам руки творити дичину.
В Intellij з ним працювати ще той гемор, бо не завжди коректно відпрацьовує авто-рефактор коду, пошук usage, білд може не звалитись ще на фазі компіляції, якщо тести написані на груві і мають помилки в коді, що з функціональними тестами інколи приводить до білдів по 30 хвилин (з рестартом тестових контекстів), які б не мали б по хорошому доходити навіть до старту тестів.
До java 8 альтернативи кложурам і роботи з колекціями в стандартній джава і правда не було, але з появою лямбд і streams API груві втратив свої основні козирі перед стандартною java, IMHO.
До речі сумісність лямбд і кложурів груві це окрема тема (це якщо розглядати продакшин код на джаві і тести на груві/споці)

Groovy залишився тільки у Jenkins pipeline, у gradle його витісняє котлін, в інших місцях python/js

та я знаю.
питання ж у тому — чому так сталося.

погана підтримка IDE в наслідок своєї природи динамічної типізації, зараз всі скрипти рухаються у статичну типізацію та гарний автокомпліт і безпеку. Он скільки у дженкінс багів із безпекою із-за groovy

погана підтримка IDE в наслідок своєї природи динамічної типізації,

у PHP суперська підтримка, навіть у Netbeans
Давно.
І аутокопліт — в цілому пристойно працює.

А для Go — не знадобилось підтримки в IDE.

зараз всі скрипти рухаються у статичну типізацію

так, про це модно казати.
а у житті — ніхто «аж бігом» туди не рухається :)
навіть з TS — всі ахають, круто, ура, ура, а як переходити з JS — то починається якийсь стогін та саботаж.

Але ок, дякую за версії.

TS — всі ахають, круто, ура, ура, а як переходити з JS — то починається якийсь стогін та саботаж.

А какие аргументы приводят?

рациональных — никаких.
это ж жизнь, реал, а не разговоры на форумах или собесах.
А хайповские доклады на тусовках — вообще искажают действительность :)

из рациональных слышал разве что — ну вот, а нету d.ts для нашей любимой либы!

но так как я писал и на таких, и на сяких ЯП, то мне кажется очевидным почему статическая типизация — не доставляет кайфа в разработке, когда привык к динамической.
да и до определенного масштаба проекта — вообще замедляет как разработку, так и саппорт.

это же можно наблюдать у фанов монги.
их же не «скорость работы» привлекает, в большинстве случаев.
а отсутствие необходимости «типизации», которой придется заниматься в РСУБД.

так что я бы наоборот, удивился б, если джаваскриптеры дружно, в 70+% ломанулись на TS

это ж как со Скалой было, когда на хайпе.
Что ни джавист, о, Скала, надо, надо осваивать, надо переходить!
Срочно, джава гуано, вот Скала то!

ну и ;)

а, сейчас в мире пыха тоже так.
возможности есть — все говорят, а как переходить?
ой. потом как нить.
ну хоть Psalm/Phpstan поставить? ДА, ДА....
потом.

так что разговоры в инетах, вместе с опросами — это одно.
а в жизни оно чуточку не так все.

мне кажется очевидным почему статическая типизация — не доставляет кайфа в разработке, когда привык к динамической.
да и до определенного масштаба проекта — вообще замедляет как разработку, так и саппорт.

Чем она замедляет?
Ты же все равно не вызовешь проперти или метод которого нет в классе, статическая типизация тебе сразу покажет что его нет, а динамическая при запуске, и ты уже забудешь что написать хотел в том месте.

из рациональных слышал разве что — ну вот, а нету d.ts для нашей любимой либы!

Никто не мешает на чистом JS библиотеки подключать же.

Чем она замедляет?

тем что приходится постоянно думать о согласовании типов, даже тогда когда это нафик не нужно, и код простой.
А код, при правильной декомпозиции, SOLID и прочая — будет в основном — простой.

От ошибок его интеграции, как в примере бага что привел в соседней теме, статическая плюс строгая типизация не спасает так же как юнит тесты.

Ты же все равно не вызовешь проперти или метод которого нет в классе

вызову. всего лишь магический метод. так много либ устроено.
в дин языках.
ни методов, ни пропертей нет, только служебно инфраструктурные.

а IDE автокомлитит по phpdoc, в случае php

На Джаве для такого надо городить Рефлексию, и т.д.

и ты уже забудешь что написать хотел в том месте.

миллионы мух, тьху, программистов пишут на питоне, пхп и js — и не забывают.
причем многие из них — как программисты слабые.
и ничё.

а скорость разработки на дин языке проектов до некоего размера — выше, доказано многократно
из свежих что помнится — компания что выпустила RoadRunner
у них проекты делаются на смеси PHP и Go

Вопрос из зала:
А почему вообще от PHP не откажетесь
Ответ:
Понимаете, пока команда на Go выкатывает первый релиз фичи — команда на пхп уже сдала третью фичу.

Потому про Groovy мне и непонятно.

Никто не мешает на чистом JS библиотеки подключать же.

как никто не мешает просто не заморачиваться, и не тратить на это свое время.
сила TS та же что у Groovy — опциональная типизация.
В пхп примерно такая же — тайп хинтинг, причем с возможностью выбора слабая строгая типизация
и упомянутые Psalm/Phpstan все это подхватывают для статического анализа.

В Python тоже такие штуки есть.

Но суть то — когда надо — пользуйся. Когда не надо — не пользуйся.

проперти или метод которого нет в классе, статическая типизация тебе сразу покажет что его нет, а динамическая при запуске

Опять этот пыльный сборник классических сказок)
IDE давным-давно показывают варининги исходя из анализа кода js, а семантика классов ES2015 вообще уже однозначно декларирует его структуру в ее глазах, с динамическим анализом кода она весьма недурно делает предположения как по структуре, так и типах. И все это без единой буквы избыточного кодирования в лице агрессивной аннотации типов. Ну если уж совсем нужно будет их уточнить, то берем JSDoc в нужных местах публичного API и заодно получаем на выходе документацию.

Еще один TS отрицатель.
На Node.js тоже без TS пишешь?
Нафига все эти костыли если можно просто TS использовать?
Что тебе дает чистый JS без TS?
Ты же все рано не вызовешь метод которого нет, смысл в такой полу статической типазации, если есть нормальная полностью стачисеская в TS?

Еще один TS отрицатель.

Ага, это уже оскорбление чувств верующих))

На Node.js тоже без TS пишешь?

Еще я не пишу на питоне под node. Ваш КЭП)

Нафига все эти костыли если можно просто TS использовать?

Костыль в экосистеме динамического типизируемого языка это как раз TS. Зачем он? Ну хз... кодер должен страдать, надо еще и memalloc ввести, ну его эти кучи с динамическим выделением памяти.

Что тебе дает чистый JS без TS?

Чистоту и дает. А что мне дает третья нога? По логике это ведь на 33% лучше- у паука их ведь 8. Почему бы не натянуть на С++ динамическую типизацию и назвать это вожделенным прорывом для экосистемы?

Ты же все рано не вызовешь метод которого нет, смысл в такой полу статической типазации

И в чем тут связь? А смысл выписывать поемы, чтобы на 20% улучшить варининги, с которыми ты в 99% случаев все ровно не столкнешься? Выходит сам говоришь что бесполезно дотошно описывать типы. Все ровно ведь не вызовешь метода, которого нет, не вызовешь и метод с неправильными аргументами, чтобы он правильно функционировал в тестах. Зачем еще один слой, который совсем не бесплатно пытается валидировать код, загоняя в жёсткие искусственные рамки и нивелируя преимущества ЯП? Уже есть IDE варнинги-> [jsdoc]->ESlint -> тесты -> runtime исключения. Зачем тут еще дорогой слой валидации? Что бы что? Иметь мизерный шанс покрыть уже не покрытое другими инструментами, и потратить на поиск редкой опечатки на пару секунд меньше? Да, оно стоит того.

если есть нормальная полностью стачисеская в TS?

с чего ты взял что она нормальная, особенно для динамического языка? Потому что ты так привык и ты хочешь что все вокруг было таким же? Ну так это дело субъективное.
Хотя сами тапинги d.ts я мог бы назвать стоящими, если бы они были опциональными, неагрессивными, как добавление, уточное, документирование кода. Но не сам язык. Мне не нужно влезать в ЯП и пытаться его фиксить, подводя под постулаты чужой церкви

Бачу у скриптофанів аргументи не змінилися. Нічого, еволюція поставить крапки.

Вот и я не пойму никак
Юнит тесты собственно и выполняют ту задачу которую делает статическая типизация.
ну не пройдут же если с типами накосячено совсем.

А правоверные это да :)
С тру функциональщиками пообщайтесь, согреет душу — как они костерят недопрограммистов малограмотных на джаве и сишарпе :)

Юнит тесты собственно и выполняют ту задачу которую делает статическая типизация.

Вот только не любой фронт-енд код экономически целесообразно покрывать юнит-тестами.

Зачем тебе покрывать 100% юнит тестами, и тратить на это больше времени чем на написание самого кода, если можно просто сразу на TS писать, так же быстро как и на JS?

и не надо будет юнит тестов писать? ;)
в том же и пойнт — зачем к статически типизированным ЯП пишут юнит тесты?

ответ у функциональщиков есть
а потому что нет правильной типизации, а есть ее пародия, калека, имитация.

а юнит тесты можно НЕ писать и на JS.
тестировщики и пользователи — очень быстро укажут на баги.

У нас на фронте нет тестов, вообще. Не нужны, хотя и полноценное SPA, а не как часто — у нас SPA — а за каждым чихом лезут на бек.
на беке — есть. в основном фукнциональные и приемочные (аcceptance в терминах Codeception)

и тратить на это больше времени чем на написание самого кода,

занятно) то есть тратить время на подписывание каждой переменной, метода и т.д, это не трата времени, а вот тесты, это трата времени ) При том что TS проверяет по сути только трезвый ли кодер, а тесты, что оно работает как должно.

если можно просто сразу на TS писать, так же быстро как и на JS?

хех) букв больше набирать? больше! Как можно делать больше работы быстрее ее части?

:bool или :string написать это же одна секунда.
А тесты при покрытии 80+% писать еще дольше чем сам код,
Как это блин вообще сравнивать можно, разница по времени же в стони раз.

хех) букв больше набирать? больше! Как можно делать больше работы быстрее ее части?

Ты наверно большие проекты никогда не писал, большой фронт даже на TS уже плохо работает, например деревья на фронте, а на JS ты вообще офигеешь, и не поймешь что происходит в коде.

:bool или :string написать это же одна секунда.

зачем писать то что можно — не писать?
зачем думать о том о чем можно не думать?

А тесты при покрытии 80+% писать еще дольше чем сам код,

обратитесь к рулящим разработкой, почему им нужен вот такой уровень покрытия, а не другой.

я пишу тесты чтобы убедиться что функциональность не сломается при изменении кода. типы в этом — по факту не помогают.
кому что надо — тот для того их и пишет.
я не пишу тесты для покрытия.

И, вот где усложняет все типизация, так это при написании тестов.
Такую хрень надо городить, чтобы замокать и т.д.

Ты наверно большие проекты никогда не писал

а вы, вообще не программист, если приводите аргумент
:bool или :string написать это же одна секунда

а на JS ты вообще офигеешь

не пишите монолиты для фронта, и не офигеете.

докладов как этого не делать, не офигевать в смысле, чтобы потом не надувать важно щеки «я такой офигевший, такой монстр у нас, у-у-у»
при этом создавая весьма сложные фронтенд приложения — полно.

и не поймешь что происходит в коде.

зависит больше от семантики кода, а не от ЯП

подделка под типизацию — никак тому не помогает.

в ЯП с автовыводом типов — тоже ж не пишут тип, верно?
зачем он нужен, этот автовывод типов в ЯП, пусть пишут!

зачем думать о том о чем можно не думать?

Гениально, и это ты мне еще пиешь:

а вы, вообще не программист, если приводите аргумент
не пишите монолиты для фронта, и не офигеете.

У меня одна страница сложнее чем некотрые сайты, тут ее на микрофронтенд не разобьешь уже.

Гениально

«Всем, у кого есть хоть капля мозгов — понятно.» писал некий John Kelly недавно в другой теме.
никакой гениальности.
просто — капля мозгов.

У меня одна страница сложнее чем некотрые сайты,

берегите щеки, лопнут еще, от важности.

никакой гениальности.
просто — капля мозгов.

Мне тяжело понять тех, кто топит против строгой типизации, пока не одного аргумента по сушеству никто не сказал, кроме того что это быстрее.
Для меня это равносильно топлению против DI облаков и SOLID.
На Хабре кто-то из рашки писал что облока это параша, так как надо свой монолит разбивать на разные сервисы, и правильно для них выбирать клауд нейтив сервисы, а это долго, проще на PHP написать все, и сервер поднять свой.

берегите щеки, лопнут еще, от важности.

Где ты тут важность увидел?
Логично что простое решение можно сделать на чем угодно, а для сложного уже не все инструменты подходят.

Мне тяжело понять тех, кто топит против строгой типизации

в том то и фокус, что это проще некуда, даже в этом обсуждении :)
когда рационально.

Для меня это равносильно топлению против DI облаков и SOLID.

я об этом и написал:

Рациональные аргументы против иррациональных, это как дубасить бейсбольной битой привидение.

ничем не могу помочь. тролить вас не за что.

разве что тест на каплю мозгов предложить:
назовите самые главные недостатки ваших убеждений, credo.
Себе, ни в коем случае не прилюдно, это интимный процесс. Потому что — умственный.
а не недостатки тех кто не разделяет ваши верования, понятно они тупые, хомячки, эникейщики, формошлепы, бла-бла-бла.

а то вы даже не поняли за что я топлю :D
хотя и это было написано несколько раз.
Капля мозгов, никакой гениальности.

Логично что простое решение можно сделать на чем угодно

лопнут таки щеки, ой лопнут...

На Хабре кто-то из рашки писал что облока это параша

зачем Хабр, я недавно на доу верования и догматы одного солюшн архитекта пробовал на зуб :)
там может и на капля мозгов, а полкружки, но — продраться к ним не получилось.

Кто ж посрамление веры истинной допустит!

это же одна секунда

и теперь умножь на количество переменных, функций и т.д
а потом вспомни, что

:bool или :string

IDE и без TS покажет варнинг, при этом не засоряя код километровыми описаниями типов и более сложных интерфейсов.

большой фронт даже на TS уже плохо работает

хех ДАЖЕ на TS ))) и при этом TS надмножество JS ))
а не надо накидывать Ангуляры везде, благодаря которому TS и выжил.

и не поймешь что происходит в коде.

понимаю еще со времен Prototype.js

и теперь умножь на количество переменных, функций и т.д

программист знает что он гораздо больше тратит времени на
чтение кода, а не написание.
следующим пунктом идет — изменение кода, а не написание нового

так что фигню он написал

берем теперь типичную историю,
есть метод, принимает
int

вызывается в 20 местах
опа, надо бы чтобы еще и массив intов принимал

на пыхе — да пофик, добавлю в метод — детект что пришло

жизнь идет, уже 40 мест вызова этого метода
опа, надо бы что бы EntityModel с id принимал

та, пофик, еще одна проверка.

А теперь берем статическую типизацию, и мужественно рефакторим (нам IDE помогает!!!) переписываем тесты, которые свялятся из-за несоответствия типов
а также напишем класс враппер, и т.д.
а потом еще согласуем такое изменение с другими командами

да, история выше — обычная, такая ситуация с QueryBuilder ами для SQL

Юнит тесты собственно и выполняют ту задачу которую делает статическая типизация.

Угу. ну вот смысл типизировать приватные переменные в функции? Чистое мракобесие) Типизация может и скорее должна быть только для публичных API модуля и только с соображений документирования, а не для валидации.

TS лично мне очень полезен как минимум по двум причинам
— когда есть апи со сложной структурой реквест бади / респонса и соответственно DTO сложнее, чем { firstName: string; lastName: string; } не нужно лезть в сваггер или куда-то ещё, чтобы понять структуру (естественно, я имею в виду, когда интеграция с этим апи уже написана и надо что-то подправить или просто разобраться). Или, например, есть метод библиотеки, в который передается объект options и там 10 разных пропертей возможно. Допустим, есть какая-то пропертя, про которую ты знаешь, что она делает, но забыл, как точно она называется. При наличии .d.ts посмотреть это секунда дела, без типов надо обязательно лезть в доки.
— синтаксический сахар появляется В РАЗЫ быстрее, чем в JS. Те же null coalescing и optional chaining капец как упростили написание кода начиная с версии 3.7. Немного грустно и смешно, что в том же C# это было уже очень давно, а тут прям революция, но что есть.

При наличии .d.ts

Ну да, что и было сказано в тут:

Хотя сами тапинги d.ts я мог бы назвать стоящими, если бы они были опциональными, неагрессивными, как добавление, уточное, документирование кода.

d.ts может быть как дополнение к JS в качестве документирования публичного API. Но сам TS нафик не нужон, тем более с его принуждением к бюрократическому описанию абсолютно всего, даже приватного.

без типов надо обязательно лезть в доки.

Лезть в .md файл автосгенерированных доков не медленнее чем d.ts и получить полную инфу включая примеры вызова, ссылки, сноски.
Но и у d.ts свои преимущества в более лаконичной семантике. Вот если втулять jsdoc аннотации в d.ts то самое оно :)

Зачем еще один слой, который совсем не бесплатно пытается валидировать код, загоняя в жёсткие искусственные рамки и нивелируя преимущества ЯП?

Ты и в TS можешь ложить один тип в другой, там все можно сделать что и в JS так как JS это подмножество TS.

Ты и в TS можешь ложить один тип в другой

Ну да я как бы в курсе, но сначала же нужно пострадать бюрократией и описать типы наперед, в динамическом ЯП )) Крайне тупо.

там все можно сделать что и в JS

можно, и все это с петлей на шее. TS это не чистый JS, только с типами в <>, оно транслируется в собственные структуры, а что то похожее на JS, но не JS мне не нужен. Семантики там другие, которые портят JS и пилят джаву.

Еще один TS отрицатель.

blog.logrocket.com/is-typescript-worth-it
хабр Чем меня разочаровал Typescript и стоит ли он того?
цитата:
Я должен повторить, что я фанат TypeScript и использую его в своей повседневной работе, но я чувствую, что он несовершенен и шумиха вокруг него не совсем оправдана.
...
Любой команде разработчиков, неважно, большая она или маленькая, пишет на TypeScript или нет, ради безопасности всегда стоит:
— Следить, чтобы хорошо написанные юнит тесты покрывали как можно больше кода в продакшене
— Использовать парное программирование: дополнительная пара глаз поможет поймать более серьезные вещи, чем просто синтаксические ошибки
— Качественно построить процесс code review и выявлять ошибки, которые не может найти машина
— Использовать линтер — такой как eslint
TypeScript хоть и добавляет дополнительный уровень безопасности поверх всего этого, но по моим ощущениям, он очень сильно отстает от других языков в этом плане. Объясню почему.
...
Меня фрустрирует факт, что количество тестов, которые я пишу, нисколько не уменьшилось с переходом на TypeScript (подставьте любой ЯП с стат типизацией). Когда я только начинал, то ошибочно решил, что смогу сократить тягомотную рутину написания большого количества юнит тестов.

он очень сильно отстает от других языков в этом плане

А JS блин обгоняет все языки?
Это блин гениальная идея, покрывать все на 100% тестами, и использовать парное програмирование вместо того что бы на TS пистаь🤦‍♀️

100% покриття не існує в природі, десь статтю кидали. А стат типізація допомагає в процесі написання коду. Плюс перформанс. Сучасні стат мови мають авто визначення типу змінної по тому що справа, тому сенсу в динамічних нема.

А JS блин обгоняет все языки?

у JS в базе есть то, чего нет у других.
И которое компенсирует многие отсутствующие в нем вещи.

Когда хейтят JS мне все время приходит на ум аналогичный москальский подход:
Да чьто это за телячья мова ваша? просто испорченный польским — русский язык!

JS уникальный язык, вне семейства наследников идей Страуструпа, и потому — к нему подходить надо с другим аршином.

Но, это ж рационально если.
А причина хейтинга — иррациональна

Рациональные аргументы против иррациональных, это как дубасить бейсбольной битой привидение.

Я как раз люблю JS и не воспринимаю TS как отдельный язык, а воспринимаю как новую версию JS.

как по мне, TS все же отдельный язык.
причем тоже, своеобразный
начиная с структурной типизации, а не номинальной как у Страуструпа и всем семействе C++, Java, PHP

ну и конечно, для транспайлинга TS учитывает возможности конечного языка. Компилировался бы в Джаву — имел бы черточки Джавы :)
В Ерланг — ерланговские.

Чим JS відрізняється від Lisp? Дужками?

від якого саме ліспа?
останній що я мацав був NewLisp. Цікавий діалект, працює під JVM

і головне, а чого ви витягли Lisp з могили?
Чи у нього є перспектива повернутись у мейнстрім?

На Node.js тоже без TS пишешь?
Нафига все эти костыли если можно просто TS использовать?

ИМХО, для ноды тайпскрипт — это костыль, а джаваскрипт — родное) Вот чтобы было наоборот надо юзать Deno. :-)

Ваз хороший автомобіль, на малих маршрутах їде швидше за BMW. І не треба сучасного салону. Он вже давно можна GPS навігатор на китайському планшеті поставити, і працює.

другое дело ваз-амфибия. Даже на всю свою неуклюжесть на дороге, дороговизну в обслуживании и долгом старте, он почти так же хорош на воде, как и резиновая лодка- есть шанс воспользоваться таким преимуществом в случае затопления улиц.

І не треба сучасного салону.

дерматиновый салон с деревянными вставками самый писк новых веяний, как и древняя строгая статическая типизация, которая появилась гораздо раньше ;)

Замедляет не типизация, она-то как раз ускоряет, а отсутствие REPL.

Я писал за деньги, и на С, и на FoxPro, и на 1С и на BP с ассемблерными вставками, и на Perl и на Java, и на JS а сейчас на PHP.
Типизацмя — замедляет разработку проектов размером/сложностью до некоего размера X. Размер команды тоже в этой величине.
Серебряной пули нет, но смаллталк с лиспом сгинули из за невозможности-сложности написать хороший компилятор для ЯП с дин типизацией. А не потому что писать на них было медленней чем на плюсах.

Так же как замедлил бы речь постоянный контроль — а это какая честь речи? А я тот падеж использую? А порядок слов правильный? То есть вечная дофлуэнт стадия.

На самом деле статическая типизация не столь на больших проектах нужна сколь на проектах где объекты имеют кучу свойств/методов. Обычно такие объекты плодят джуны, на больших проектах из-за того что они дольше и народ там разный, такие объекты чаще появляются, и там без типов будет сложно. Однако накосячить можно и на маленьком проекте, главное желание.

чем больше проект/команда — тем доля затрат времени на работу с кодом меньше.
поэтому становится все менее неважно — насколько быстро или медленно пишется код.

второй фактор — сами компьютеры, которым никакие ЯП не нравятся.
А, в том же PHP — вызовы функций методов — дороже по процессорному времени, чем после хорошего компилятора с ЯП с стат типизацией.
На небольшом проекте — незаметно.
Чем крупнее тот самый «монолит» — тем это ощутимее, и тупо серверов надо ставить больше.
И этот фактор — решающий: почему живут ЯП с стат типизацией.
Не было б этого фактора — ЯП с стат типизацией были бы маргинальными.
Конечно доказать такое «если бы да кабы» невозможно.

Но косвенным доказательством является разная learning curve
Python, Java, Haskell

И, на своем опыте рефлексии знаю, о чем я думаю, как у меня работает голова когда я пишу на ЯП с дин типизацией, и со стат.

И в частности, во время пристального интереса к Скала, читая форумы скалистов, подтверждают что у всех так, я не являюсь каким-то особенным (просто большинство людей почти никогда не рефлексируют. опять же, не мое особое мнение, а вполне известный факт).
Обсуждения на форумах скалистов напоминали скорее диспуты каких-то лингвиствов филологов, лит критиков поэзии, чем обычных программистов, которым надо:
«Вот эту ё-ую бизнес логику описать.
А потом, переписать на самый неожиданный вариант, который пришел в голову буйным маркетологам. Когда уже все в проде»

Однако накосячить можно и на маленьком проекте, главное желание.

Естественно.

Я писал за деньги, и на С, и на FoxPro, ... а сейчас на PHP.

Звучить як історія успіху :D

Я працюю над дуже складним багатомодульним мультиплатформенним проектом, збирається все за допомогою gradle, коли то були groovy скрипти то була жесть підтримувати, а зараз я все перевів на котлін і тут тобі повний аутокомпліт, документація, початкові коди з комментарями, зараз робити навіть складні таски для автоматизації білду стало як мінімум приємно.

Подписаться на комментарии