Ок, благодарю за ответ. Но один момент остался не ясным — будут ли какие-то отличия в Ultimate Edition для Scala, которых не будет в Community Edition?
artspb, насколько я понимаю, Вы представитель Jetbrains. Если Вы не против, то я задам вопрос тут, думаю он почти всем любителям Scala будет интересен.
Раз теперь продукт с подпиской, то выходит что подразумевается, что пользователи платят за багфиксы, апдейты и т.д. Отсюда вопрос: что будет со Scala плагином, он так же будет в Community Edition, или же вы как-то планируете его развивать и следовательно тем кто хочет побольше плюшек имеет смысл брать лицензию? С Java то все понятно — хочешь плюшки плагинов для Spring etc. — бери, а вот для Scala профит не совсем ясен.
Мне всегда казалось, что путь программиста очень похож на путь музыканта — есть те кто заканчивает филармонии, а есть те кто просто берет в руки инструмент и настолько начинает любить свое ремесло, что добивается любых высот.
P.S. Я пришел в программирование потому что просто быстро умел печатать и не знал где применить свой навык. Вбив в гугл «какой профессии надо быстро уметь печатать» увидел список из всяких копирайтеров, рерайдеров etc. и… программиста. Если бы мне тогда кто-то сказал, что я за эти 3 года пройду путь php -> java -> scala, я бы подумал что человек сбредил или какие-то заклинания произносит.
На самом деле новая лицензия не плохая, особенно для случаев когда человек только купил IDE, и буквально через несколько месяцев выходит новая версия. Да и цены вполне ок. Огорчает только «откат к старой версии» — так то оно логично, не платишь — не получишь, но зачем забирать то что есть не понятно. Я даже представляю как эта задумка пришла менеджерам в голову:
-А как мы подстегнем пользователей продлевать лицензию?
-А давайте раз в год выпускать новую мажорную версию, а потом ее отбирать — пусть почувствуют боль!
Имхо, нужно было позиционироваться не на отбирании, а на покупке ради новых обновлений.
К счастью(а может быть и к сожалению, если расценивать как опыт) начал с 1.7, об сложностях программирования на Java до 1.5 знаю только по наслышке…
P.S. пользуясь моментом хочу поблагодарить Мартина Одерски за то, что дал Java генериксы :-D
Как то работал над кодом которому лет 7-10, написанному еще на Java 1.6. И впечатления, мягко говоря, печальные. Из того что самое печальное из воспоминаний — местами не юзались темплейт енджайны и данные юзеру отдавались слепленные стрингбилдером…
Проблема в таких проектах даже не в том, что языковые конструкции устарели, или что фрэймворки/либы старых версий. А проблема в том, что раз они дошли до нас в таком состоянии, то разработка изначально была построена не правильно. Проект не обновлялся из версии к версии языка/либы/фрэймворка, не рефакторился и т.д. Отношение к коду в этих проектах было такое — что сделай быстро запладку, не важно как. И проект весь на запладках и разобрать что, где и как — это еще та проблема.
В общем мораль такова — жадный заказчик платит дважды, а то и трижды, а то и весь жизненный цикл своего кривого проекта…
Не густо, если честно, больше похоже на куски кода из StackOverFlow… Надо было хотя бы показать не стандартные ситуации — например написать свой интерцептор для случая когда template engine не дефолтный, например Mustache/Handlebars etc.
Согласен, ситуации бывают разные. Но я говорил конкретно в контексте истории описанной в статье. Если судить о каком-нибудь проекте, который запущен на 1000 машинах, то это логично, что 1ГБ в итоге сэкономит приличную сумму денег.
Автор(статьи, а не перевода естественно) видимо хотел запиариться. А вышло так, что со стороны выглядит, будто они сначала не правильно юзали Java, а потом еще и переписали на Go ради экономии 1ГБ оперативки, которая стоит куда дешевле чем труд разработчиков. Сомнительный мув, имхо…
Хм, достаточно интересно. Но в принципе ничего удивительно, зная то насколько Python хорошо подходит для data mining и т.д., можно с легкостью предположить, что и для финансовых операций он отлично подойдет. Не в курсе как у него с транзакциями и т.д., но думаю что язык вполне подходящий под эту нишу.
Если вчитаться, то можно увидеть, что они его юзают именно для веба. Речь то шла совсем о другом. Если гугл себе состряпает сайт для одного из сотни своих сервисов на Node.js, то не будем же мы говорить, что гугл на Node.js написан… Пока мы не увидим реально большие вещи на Node.js(например как инфраструктура Amazon'а), то даже и обсуждать нечего. Ничего не имею против Node.js(даже напротив очень рад что появилась такая быстрорастущая платформа), но надо понимать, что у него совсем другая ниша.
Go больше по прикладному на замену Java/Python/Perl/Nodejs
Спорное утверждение, как альтернативу еще может быть, но чтобы прям замену… Да и к тому же даже у этих казалось бы чаще применимых на бэкэндах языков отчасти разные ниши. Не будете же Вы для банков ПО писать на NodeJS. А если сравнить Python и Go в разрезе разработки сферического веб-сайта в вакууме, то победитель тоже очевиден.
Не в курсе про то, что Haskell лучший язык для написания компиляторов. Мне казалось, что он больше академический, чем для практических нужд. Пожалуй пересмотрю свое мнение по поводу Haskell'а
Раз теперь продукт с подпиской, то выходит что подразумевается, что пользователи платят за багфиксы, апдейты и т.д. Отсюда вопрос: что будет со Scala плагином, он так же будет в Community Edition, или же вы как-то планируете его развивать и следовательно тем кто хочет побольше плюшек имеет смысл брать лицензию? С Java то все понятно — хочешь плюшки плагинов для Spring etc. — бери, а вот для Scala профит не совсем ясен.
P.S. Я пришел в программирование потому что просто быстро умел печатать и не знал где применить свой навык. Вбив в гугл «какой профессии надо быстро уметь печатать» увидел список из всяких копирайтеров, рерайдеров etc. и… программиста. Если бы мне тогда кто-то сказал, что я за эти 3 года пройду путь php -> java -> scala, я бы подумал что человек сбредил или какие-то заклинания произносит.
-А как мы подстегнем пользователей продлевать лицензию?
-А давайте раз в год выпускать новую мажорную версию, а потом ее отбирать — пусть почувствуют боль!
Имхо, нужно было позиционироваться не на отбирании, а на покупке ради новых обновлений.
P.S. пользуясь моментом хочу поблагодарить Мартина Одерски за то, что дал Java генериксы :-D
Проблема в таких проектах даже не в том, что языковые конструкции устарели, или что фрэймворки/либы старых версий. А проблема в том, что раз они дошли до нас в таком состоянии, то разработка изначально была построена не правильно. Проект не обновлялся из версии к версии языка/либы/фрэймворка, не рефакторился и т.д. Отношение к коду в этих проектах было такое — что сделай быстро запладку, не важно как. И проект весь на запладках и разобрать что, где и как — это еще та проблема.
В общем мораль такова — жадный заказчик платит дважды, а то и трижды, а то и весь жизненный цикл своего кривого проекта…
Спорное утверждение, как альтернативу еще может быть, но чтобы прям замену… Да и к тому же даже у этих казалось бы чаще применимых на бэкэндах языков отчасти разные ниши. Не будете же Вы для банков ПО писать на NodeJS. А если сравнить Python и Go в разрезе разработки сферического веб-сайта в вакууме, то победитель тоже очевиден.
Не знаю подробностей, но порадуюсь за любимого докладчика )