Ты слышал про парня, который попрощался с OOП?
О нет. Ещё один? Что же он сказал?
Он описал все обещания OOП, и как ни одно из них на самом деле не было исполнено, и что все возможности ООП обходятся дороже, чем они реально стоят, и функциональное программирование лучше, и ...
Ох. Да, я слышал всё это раньше...
Таким образом, OOП окончательно умерло, и мы можем двигаться дальше.
Двигаться дальше к чему?
Ты чего? К следующему технологическому прорыву, конечно!
А, к этому… И что там у нас на очереди?
Не знаю, меня очень привлекает идея микро-сервисов; и я очень заинтересован в Elixr; и я слышал React по-настоящему крут; и ...
Да. Да. Маслобойка. Ты попался в Маслобойку.
Чего? Что ты хочешь этим сказать? Сейчас захватывающее время.
Как по мне, скорее удручающее.
Почему? Новые технологии возникают каждую неделю! Мы взбираемся на всё более высокие высоты.
Тю! Всё, что мы действительно делаем, заново изобретаем колесо, снова и снова. И мы напрасно тратим время и огромные усилия на это.
Ой, да ладно! Мы создаём ПРОГРЕСС.
Прогресс. В самом деле? Это не то, что я вижу.
Ну, и что же ты видишь?
Я вижу расточительство. Массовые, неисчислимые потери времени и средств. Расточительство помноженное на расточительство и помноженное на ещё большее расточительство.
Как ты можешь такое говорить?
Ну, рассмотрим хотя бы этот вопрос с OOП. OOП не умерло. OOП никогда не было живым. OOП является техникой, хорошей техникой. Утверждать, что оно мёртво, это как утверждать, что хорошая отвёртка мертва. Прощаться с OOП, это как прощаться с хорошей отвёрткой. Это пустая трата!
Но функциональное программирование лучше!
Мне очень жаль, но это как говорить, что молоток лучше отвёртки. Функциональное программирование не "лучше", чем объектно-ориентированное программирование. Функциональное программирование представляет собой метод, и весьма хороший, который может быть использован совместно с объектно-ориентированным программированием.
Это не то, что я слышал. Я слышал, что они взаимоисключающи.
Да нет, конечно. Они направлены на решение ортогональных проблем. Проблем, которые присутствуют во всех проектах.
Смотри, есть люди, которые думают, что развитие программного обеспечения представляет собой линейный прогресс. Типа мы поднимаемся на одну ступеньку лестницы раз за разом, и каждая "новая" ступенька лучше, чем предыдущая "старая". Но это так не работает.
И как же это работает по-твоему?
Прогресс в области программного обеспечения следует логарифмической кривой роста. В первые годы прогресс был резким и впечатляющим. В последующие годы прогресс стал гораздо более постепенным. В настоящее время прогресс практически отсутствует.
Смотри: ассемблер был гораздо лучше, чем машинный код. Fortran был намного лучше, чем ассемблер. C был существенно лучше, чем Fortran. C++ вероятно лучше, чем C. Java был улучшением по сравнению C++. Ruby вероятно немного лучше, чем Java.
Каскадная модель (водопад) была намного лучше, чем ничего. Agile была лучше, чем водопад. Lean был немного лучше, чем Agile. Kanban возможно был чем-то типа улучшения.
Каждый год, хотя мы прикладываем огромные усилия, мы делаем меньший прогресс, чем годом ранее. Потому что каждый год мы становимся всё ближе и ближе к асимптоте.
Асимптота?! Думаешь, есть верхний предел технологий разработки программного обеспечения?
Уверен. Более того, я думаю, что мы сейчас настолько близки к этому пределу, что любое дальнейшее усилие бесплодно. Мы уже прошли рубеж падения эффективности.
Что? Это звучит нелепо! И удручает!
Я понимаю. Но это потому, что мы привыкли к быстрому росту. Это были пьянящие дни, и мы хотим вернуть их. Но они ушли, и мы должны признать тот факт, что мы тратим время и усилия в массовом масштабе, пытаясь воссоздать их.
Но если мы не будем подстёгивать будущее — мы никогда не создадим его!
Поверь, я определенно хочу, чтобы мы подстёгивали будущее. Но это не то, что мы делаем. Мы просто тоскуем по прошлому.
Так к какому же будущему мы должны стремиться?
К продуктивному. К будущему, которое не подчинено расточительной маслобойке.
Что значит "расточительный" в данном контексте?
Ты когда-нибудь использовал IntelliJ или Eclipse для программирования на Java?
Конечно.
Это невероятно мощные инструменты. Опытный специалист может быть в высшей степени продуктивным с этими инструментами. Рефакторинг! Представления! Удобства! Боже мой, эти инструменты впечатляют!
Тем не менее, каждый раз, когда возникает новый язык, мы отказываемся от мощных инструментов, чтобы перейти к СЛЕДУЮЩЕЙ НОВОЙ ШТУКЕ. И инструменты для нового языка программирования выглядят как уровень жизни в странах третьего мира. Боже, зачастую там нет даже банального "rename" рефакторинга!
На создание приличного набора инструментов уходит время. Если мы будем продолжать переключаться с одного языка на другой, мы никогда не обеспечим их надёжным инструментарием.
Но новые языки лучше.
Да брось! Они отличаются, но они не лучше, по крайней мере не настолько лучше, чтобы оправдать возвращение набора инструментов обратно в каменный век.
А подумай о расходах на обучение для адаптации нового языка. Подумай во сколько обходится организациям использование 84 различных языков только из-за того, что программисты увлекаются новыми блестящими вещами каждые две недели.
Новые блестящие вещи? Звучит как-то обидно, не так ли?
Полагаю, что так, но зачастую всё сводится именно к этому. Новые языки не лучше, они просто блестящие. И поиск золотого руна в виде нового языка, или нового фреймворка, или новой парадигмы, или нового процесса достиг точки, когда это становится непрофессиональным.
Непрофессиональным?
Да! Это непрофессионально. Нам нужно осознать, что мы упёрлись в асимптоту. Пора остановить расточительное вспенивание языков и фреймворков, а также парадигм и процессов.
Пришло время, чтобы начать просто работать.
Нам нужно выбрать язык, или два, или три. Небольшой набор простых фреймворков. А затем выстроить наши инструменты. Кристаллизовать наши процессы. И стать настоящими профессионалами.
Комментарии (324)
DrPass
30.07.2016 22:18Подписался бы под каждым словом, кроме последнего. Не мы выбираем новые фреймворки, и не мы клюем как сороки на блестящее (по крайней мере, далеко не всегда мы). Заказчики клюют, маркетологи прикармливают и т.д… Не получается безоблачно радоваться Eclipse с Java, если, грубо говоря, очередной клиент тебе доказывает, что ему нужно непременно на NodeJS, т.к. это тренд. А прогнать клиента… ну тоже не вариант.
Shifty_Fox
30.07.2016 22:25+350\50. Если разработка идет под ключ, команда сама решает, какие инструменты использовать. Если компания сама владеет разработкой продукта, она сама решает, какие инструменты использовать. Если команда\компания делает заказ на аутсорсе, она сама навязывает, (или выбирает из исполнителей), какие инструменты они будут использовать. А вот если вы сами аутсорс, и присоединяетесь к чужой разработке, тогда да :).
Source
30.07.2016 22:45+2Статья немного провокационная… Бывает по разному, переключаться между технологиями вполне допустимо, если от этого есть практическая выгода. А прыгать между примерно одинаковыми вариантами — это уже непрофессионально.
В Вашем же примере речь скорее не о переключении, а об изначальном выборе технологий для проекта. И тут уже Ваша задача как профессионала обосновать свой выбор заказчику, если для его проекта Java идеально подходит.
eydemidov
31.07.2016 13:44Я бы сказал, тут и то, и другое. Не раз приходилось останавливать желание запилить проект (на который меня нанимают) на чём-то новом и блестящем без адекватного обоснование.
Сейчас вот опять думаю, есть ли адекватное обоснование новый небольшой проект сделать на Elixir/Phoenix вместо рельс, или это добавит клиенту геморроя больше, чем решит. Скорее всего, такого нет. Возможно, кто-нибудь когда-нибудь решит использовать это и наймёт, но пока нет.
А ещё я хотел попробовать перекатиться куда-нибудь в джавамир, но с учётом специфики этих проектов, это было бы как из пушки по воробьям, так что опять нет.
UA3MQJ
31.07.2016 22:41Ну я тут с ходу после ерланга взял эликсир. И… как-то на первых порах, типа помигать лампочкой, хелловорлд, там быстрее получается, но потом ударился головой об синтаксис. Шишка теперь )
nwalker
01.08.2016 13:29+1Там не только в синтаксисе грабли разложены, в stdlib и plug тоже есть чудесные вещи. Мне хочется написать об этом пост, но он получается какой-то очень гневный, не очень длинный и вообще руки не доходят.
Но в целом, несмотря на все грабли, писать удобнее и даже поприятнее.Source
01.08.2016 21:36stdlib вроде просто причёсана для пайпов, чтобы основной параметр всегда шёл первым… на что там гневаться то?
QtRoS
30.07.2016 22:39+11C был существенно лучше, чем Fortran
У языков немного разное целевое назначение, Fortran все же больше про вычисления, а C про системное программирование. Так сравнивать нечестно, ибо… Что лучше, SQL или Python?Source
30.07.2016 22:50+11Мало ли, возможно 40 с лишним лет назад их области применения пересекались гораздо сильнее, чем сейчас.
mayorovp
30.07.2016 23:48+3Но при этом задачу вычислений C тоже решает.
c4boomb
30.07.2016 23:57+4А ещё на нем можно писать сайты и мобильные приложения. (стоит ли ?)
У языка есть специализация.mayorovp
31.07.2016 00:31+3Да, но Фортран устарел даже в рамках своей собственной специализации.
naething
31.07.2016 00:36+4Минусующие этот комментарий видимо никогда не видели программы на F77.
grossws
31.07.2016 00:41+3Но количество legacy на фортране (типа того же blas/lapack/arpack и тонны научных библиотек) приводит к тому, что его компиляторы живут и здравствуют (и в gcc, и в intel). Интересно, много ли народа реально используют их на фортране, а не из c/python?
ogoNEKto
31.07.2016 13:26много. если иметь в виду по назначению
для примера: один и тот же расчет на python ~15 мин, fortran 90 — 30 c
магия однако
+ таки да, куча легаси кода, который переписывать на другия языки зная что станет в N раз медленнее очень лениво (я даже не говорю про " а кто за это быдет платить"?)mayorovp
31.07.2016 15:58+1Переписывать смысла нет. Но ведь язык живет пока на нем пишут — а не пока запускают программы, на нем написанные. Много вы знаете людей, которые при обсуждении нового проекта скажут: "а давайте сделаем его на Фортране"?
Что же до производительности расчетов — в этой ветке обсуждались Fortran и Си, а не Fortran и Python. То, что питон слабо подходит для чистых расчетов — не секрет. Но можете ли вы привести расчет, который будет выполняться на Си медленнее чем на Фортране?
MichaelBorisov
31.07.2016 23:20+2Я полагаю, тормозить могут расчеты, в которых участвуют дробные числа совместно с целыми. Дело в том, что в C довольно неудачно принято, что дробное число округляется до наименьшего (по модулю) целого. При расчетах это очень неудобно. Рождаются функции типа int roundi(double x) { return (int) floor(x+0.5); }, но это костыли. Сначала прибавляем 0.5, потом округляем до меньшего целого, потом преобразуем double->int. Каждое округление сопровождается переключением режимов сопроцессора, что приводит к сильным тормозам. Вместо этого можно было бы решить задачу одной ассемблерной командой fistp без переключения режимов сопроцессора. Возможно, в новых компиляторах так и делается, но Visual C++ 2005 так не мог — мне пришлось делать ассемблерную версию roundi.
Функция round() в math.h появилась тоже совсем недавно.
grossws
31.07.2016 16:11+1Такое соотношение с python'ом получается даже при использовании numpy, слинкованного с той же версией blas'а и предвыделением памяти? У меня получалась не столь значительная просадка производительности при том, что на Си использовался код с avx intrinsics и прилично векторизованный icc.
Source
31.07.2016 00:57+2А ещё на нем можно писать сайты и мобильные приложения. (стоит ли ?)
В статье Fortran -> C приведено для примера прогресса в начале 70-х годов, причём тут сайты и мобильные приложения?
sshikov
31.07.2016 09:02+6Agile была лучше, чем водопад.
В этом месте текста многие сравнения притянуты за уши. Кстати, слово "была" очень намекает… )
В реальности все несколько проще и сложнее. C существенно лучше фортрана на некоторых задачах. Но вовсе не на тех, для которых фортран был изначально предназначен, просто его за неимением лучшего применяли и для таких тоже.
Agile может быть лучше водопада — если у вас проект определенного типа. Но на некоторых типах, и для некоторых команд это было и будет ужасно.
bentall
31.07.2016 13:26+2Нету ничего в фортране (по крайней мере — в том фортране который делал Бэкус) ничего особо ориентированного на числодробилки. Просто там наработано много кода для научных расчётов, ну и (и это зависело от п.1) со временем, насколько я знаю, более-менее появились векторные операции. Плюс бедная семантика фортрана позволила в своё время придумать достаточно эффективные техники оптимизации при компиляции. Собственно, всё.
SBKarr
30.07.2016 22:52+25Беда случилась, когда разработчики языков и фреймворков начали использовать методы рекламщиков на программистах. Мы все подвержены влиянию рекламы в том или ином виде. В итоге выходит, что мы выбираем из различных buzzwords, а не оцениваем по реальным параметрам.
Однажды я принял неверное решение: использовать NoSQL базу там, где неплохо подходила и классическая реляционная. В момент принятия решения мне казалось, что всё прекрасно, замечательно и сценарии использования подходят идеально. Спустя два года, я понял, что черпал информацию скорее из «рекламных» статей о технологии, чем из реальных источников. Потребовалось полгода, чтобы заменить базу на PostgreSQL, но в итоге это дало мощный толчок развитию проекта из-за возможностей, которые за десяток лет уже были реализованы другими, а, кроме того, снизило загрузку серверов почти в 3 раза.
Теперь я намного осторожнее выбираю технологии и предпочитаю те, что проверены временем и невероятным числом сценариев использования. У меня порой возникает желание встроить в проект модули на Rust или Go вместо C++. Но пока то, что пишут об этих языках, слишком напоминает маркетинговые материалы.
web2033
30.07.2016 22:52+1Пока практика показывает, что статьи «язык X vs язык Y», привлекают много внимания, каждый стремится похвалить именно свое болото
Source
30.07.2016 23:02+4Именно такие статьи и побудили меня перевести эту, когда я её увидел… Люди часто забывают, что любая технология — это всего лишь инструмент со своей областью применения. А если выбирать из 3 примерно одинаковых инструментов, то выбор получится чисто субъективный.
Opaspap
30.07.2016 22:53+26> Ты когда-нибудь использовал IntelliJ или Eclipse для программирования на Java?
я пробовал использовать Eclipse для программирования, несколько раз, фактически, каждый раз я надеялся, что «его улучшили, мой компьютер стал в 10 раз мощнее чем в прошлый раз, и мне не придется ждать несколько секунд, при переводе строки». В общем ни разу мои надежды не оправдались.Source
30.07.2016 22:57+2Да, у IDE на Java всегда были приличные требования к железу.
Я подумывал заменить пример на Visual Studio для C#, но всё-таки решил оставить как в оригинале.
SBKarr
30.07.2016 23:01+1У меня Eclipse — основной рабочий инструмент, правда, для C/C++. Тормоза замечал с OpenJDK, с версией оракла проблем не замечал. Правда, мои рабочие машины призваны запускать Unreal Engine, возможно, дело в этом…
maxDanylenko
31.07.2016 14:59+1SSD, вам в помощь, у меня на слабом ноуте, все хорошо работает. Вы еще на javascript — e не писали, там ресурсов в разы больше расходуется!
Opaspap
31.07.2016 16:27я на js и пишу, атом в разы быстрее работает чем Eclipse, разница примерно как у атома и vim. В последний раз я проверял ее ещё до бума ssd, сейчас есть ssd, думаете стоит проверить? Вообще в тот раз как и во все предыдущие, эклипс безбожно утекал, т.е. запустить и начать что-то делать было ок, а вот делать целый день было невозможно.
VolCh
31.07.2016 16:34+9Есть подозрение, что atom — редактор файлов, а не IDE.
Opaspap
31.07.2016 19:55Ну и вообще неважно, если в IDE тормозит редактор, то оно уже не integrated development environment а «та штука которую я юзаю при крайней необходимости». Мало ли что оно мне позволяет, только если рефакторинг :%s// или perl -pi -e работает несколько быстрее, то такая IDE ненужна. (ну и опять же, ничего больше того редактора оно не может, ни из коробки ни с плагинами)
Suvitruf
01.08.2016 08:04-1Забавно, что за 5 лет работы с Eclipse я такого не наблюдал, но зато продукты от JetBrains частенько подвисают.
grossws
01.08.2016 11:47+2У меня ситуация обратная, и путь eclipse -> netbeans -> idea прошел более-менее мягко. Полностью от приложений на eclipse rcp, конечно, избавиться сложно: тот же apache directory studio полезен и относительно удобоварим, но в смысле разработки меня устраивают другие IDE. Например, для Си для контроллеров c eclipse cdt я ушел в qtcreator, т. к. тормоза при вводе в эклипсе затмевают всё.
Suvitruf
01.08.2016 11:49С Си там есть проблема, да. Правда, я имел дело с ndk только в контексте Android. Но даже ADT лучше, чем работа с C++ в IDEA (опять же, в контексте Android). Про Android Studio вообще молчу — там работа с C++ совсем никакая до сих пор.
grossws
01.08.2016 11:56Это довольно новый кусок, clion для меня пока сыроват, c++ в idea какбэ нет, а android studio я не пробовал (не пишу под android).
kvark
30.07.2016 23:07+4Вокруг каждого языка программирования формируется группа людей, считающих разработку и развитие новых языков потерей времени. Это называется не просто невежество, а воинствующее невежество.
Они отличаются, но они не лучше, по крайней мере не настолько лучше, чтобы оправдать возвращение набора инструментов обратно в каменный век.
Каждый стоящий новый язык тянет за собой новую парадигму. Если язык не заставляет вас мыслить иначе, значет его незачем изучать.
А все эти росказни про то, что утилиты обратно в каменный век, и что всё переписывать надо — это всё от лукавого. Инструменты должны изначально писаться не под конкретный язык, выделять свои функционально независимые блоки в отдельные взаимозаменяемые модули. Это вопрос развития экосистемы утилит и сред программирования, там ещё поле не пахано (посмотрите на тот же Light Table).
c4boomb
31.07.2016 00:02Речь не об этом. Кто сказал, что новая парадигма обязана заменить предшествующую?
Многие парадигмы могут существовать параллельно и не всегда смена языка стоит того.
Почему шейдеры (хорошие шейдеры) все ещё пишут на ассемблере? Почему не написать их на python или ruby?
kvark
31.07.2016 03:58+9Кто конкретно пишет на ассемблере? Я таких людей не знаю. Напротив, шейдеростроение потихоньку поднимает уровень используемых языков. Так, за сегодняшними HLSL и GLSL с их С-ишным синтаксивом мы видим новый Metal с шейдерами на упрощённом С++. Иронично (к вашему последнему вопросу), общая тенденция идёт к тому, чтобы писать шейдеры на том же языке, то и игру.
deniskreshikhin
31.07.2016 19:41Что там Metal, в Vulkan обещают что шейдеры можно будет писать на любом языке, нужно только написать компилятор (технология SPIR-V).
kvark
31.07.2016 21:06+1Так в том и смысл, чтобы писали на высокоуровневых языках. На SPIR-V же никто руками не пишет ;) И это не "обещают", а уже как полгода можно делать самому, при желании.
playermet
31.07.2016 18:42Почему шейдеры (хорошие шейдеры) все ещё пишут на ассемблере?
Впервые слышу. Но все же, объясните почему? Я нагуглил только то, что он быстрей компилируется и безнадежно устарел.
Почему не написать их на python или ruby?
На то есть много причин, но все они относятся скорее к реализации, чем к парадигмам или синтаксису этих языков.
Chaos_Optima
01.08.2016 18:24Почему шейдеры (хорошие шейдеры) все ещё пишут на ассемблере?
Серьёзно? Уже давно не видел таких шейдеров в основно все шейдеры пишутся в процедурном стиле с С подобным синтаксисом. А HLSL с 5 версии вообще добавил ООП в шейдеры, так что это миф.
Source
31.07.2016 00:13+4Каждый стоящий новый язык тянет за собой новую парадигму.
А можно парочку примеров?
Инструменты должны изначально писаться не под конкретный язык, выделять свои функционально независимые блоки в отдельные взаимозаменяемые модули
Это да. Но поддержку нового языка всё равно надо будет дописать, при этом не факт, что язык позволит использовать возможности такой IDE в полной мере.
В целом я согласен, что развитие инструментов должно продолжаться и там до асимптоты ещё далеко.kvark
31.07.2016 04:13+1А можно парочку примеров?
- Go — параллельное программирование на легковесных потоках
- Rust — безопасная работа с памятью без сборщика мусора
- Idris — зависимые типы
Randl
31.07.2016 05:30+6Но ведь корутины придумали по-моему в 1960ых, а зависимые типы чуть ли не в 1930ых. Что мешает использовать, например, те же корутины в Ruby?
kvark
31.07.2016 13:15+2Электромобили были ещё в 19-ом веке. Планшетов и карманных ПК тоже было немало до появления iPod и iPhone.
Что мешает использовать, например, те же корутины в Ruby?
Не знаю. В С++ точно ничего не мешает. Одно дело — поддерживать фичу, а другое — плясать вокруг неё при дизайне языка и его стандартной библиотеки.
Randl
31.07.2016 14:24+1Электромобили были ещё в 19-ом веке.
Элекромобили XIX века разительно отличались от современных. Разница между корутинами в Руби и Го минимальны. Я ж не говорю о корутинах в ассемблере. Чтобы заставить себя мыслить иначе, надо изучать именно эти фундаментальные идеи, а не новые языки.
Kemet
31.07.2016 06:46+8«параллельного программирования на легковесных потоках» было как грязи до появления Go, впрочем, и всё остальное тоже.
Source
31.07.2016 12:40+3Из трёх перечисленных я хорошо знаком только с Go. Но в Go скорее идёт компоновка старых и очень старых идей, чего-то реально нового там не видно.
Есть даже книжка «Communicating Sequential Processes. The First 25 Years» с материалами симпозиума от 2004 года.
В Rust, насколько я понимаю, из коробки реализована модель умных указателей. Но самим умным указателям тоже сто лет в обед.
По поводу зависимых типов, Idris — далеко не первый ЯП, в котором они используются. А тому же Coq уже больше 30 лет.
P.S. С другой стороны, если рассматривать отдельно взятого программиста, то Вы правы, тут идёт прогресс в мышлении по мере ознакомления с разными парадигмами и подходами. Но в рамках индустрии новых идей очень мало.
DrPass
31.07.2016 00:53+5> Каждый стоящий новый язык тянет за собой новую парадигму
Если это критерий «стоящности» языка, то их тогда вполне можно сократить до полутора десятков. Новых парадигм в программировании немного, и появляются они крайне нечасто.kvark
31.07.2016 04:20Парадигма — это способ мышления. Они продолжают развиваться и сегодня, как видно из примеров выше. Более того, современные инфраструктуры компиляторов (как LLVM) позволяют новым идеям воплощаться в жизнь как нельзя быстрее и легче. Новые языки появляются чуть ли не каждую неделю. В следующем году, как прогнозируют синоптики, что прирост языков удвоится ;)
charypopper
31.07.2016 13:29+1Извините за дотошность, но
парадигма — это совокупность фундаментальных научных установок, представлений и терминов, принимаемая и разделяемая научным сообществом и объединяющая большинство его членов. Обеспечивает преемственность развития науки и научного творчества.(вики))) ).
Это несколько отличается от вашего виденья, что это способ мышления. Если кто то предлагает бред, который невозможно использовать массово, поддерживать сообществом (естественно специалистов в области), то это не парадигма. Вот ООП, это действительно скачек, подавляющее большинство специалистов перестроили свое мышление и стали использовать. Функциональное тоже. Связки их сильных сторон, помогает делать удивительные вещи быстро, читабельно, и с приемлемой скоростью выполнения.kvark
31.07.2016 15:17+1В смотрите определение не в том контексте. Наука != программирование (в целом). Вот другое, из той же вики:
Паради?гма программи?рования — это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером[1].
VGrabko
30.07.2016 23:11-3Иногда это оправдано. Я учил всё как-то так: php -> js -> golang -> учу C/C++ и как по мне то это довольно правильный путь. Я с самого «высокого» уровня по немного перешел к ручному управлению памятью
TheSlavuti4
31.07.2016 16:33+2И зачем? Весь ваш список предназначен для решения совершенно различных задач
Delphinum
30.07.2016 23:46+1А разве ООП и микро-сервисы это две взаимоисключающие парадигмы?
deniskreshikhin
31.07.2016 00:03Проблема не в микросервисах, а то в каком контексте они упоминаются. Просто если почитать современные статьи, то получается вроде как что микросервисы можно писать только на современных модных функциональных языках.
Delphinum
31.07.2016 00:06Разве? Мне показалось, что автор противопоставил ООП микро-сервисам как некую альтернативу.
deniskreshikhin
31.07.2016 00:15В любом случае Роберт Мартин писал еще пару лет назад что сам использет микросервисную архитектуру и ничего против нее не имеет.
Не думаю что его взгляды поменялись.
Source
31.07.2016 00:53Там список для демонстрации непонимания самого понятия «альтернатива» со стороны тех, кто слишком подвержен хайпу. Если вчитаетесь, заметите, что в этот список свалено всё в одну кучу.
Alex_ME
31.07.2016 00:12+6Согласен со всем, что написано.
Иногда меня охватывает странное чувство: у нас современные языки, куча фреймворков и библиотек, которые призваны облегчать нам жизнь. И вроде бы они облегчают, и не нужно реализовывать то, что уже давно сделано умными людьми. И тем не менее, очень часто я чувствую, что параллельно с облегчением жизни все это ее усложняет: тратишь кучу времени на изучение, ищешь best practies, какой подход должен быть в каждом конкретном случае (а каждый крупный фреймворк навязывает свой подход) и т.д. и т.п. Иногда мне кажется, что приходиться бороться с инструментами, которые должны нам помогать.
mlg
31.07.2016 00:42+1Прогресс в области программного обеспечения следует логарифмической кривой роста.… Асимптота?! Думаешь, есть верхний предел технологий разработки программного обеспечения?
У логарифмической кривой нет горизонтальной асимптоты. Дядя Боб, наверное, имел в виду экспоненциальную кривую.deniskreshikhin
31.07.2016 01:05+3Под прогрессом он видимо имеет ввиду производную этой функции, которая действительно асимпотически стремится к нулю.
Source
31.07.2016 01:11Хорошее замечание. На мой взгляд, тут скорее математически неправильная трактовка понятия асимптота. Всё-таки появление нового оборудования, типа квантовых компьютеров, может принести что-то новое и в программирование, но процесс идёт крайне медленно…
AlexPu
31.07.2016 01:21+28Сильно подозреваю, что меня сейчас предадут анафеме, но…
Я не делаю мир лучше… Не в том смысле, что я этого не хочу — хочу конечно…
И не в том смысле, что я этому препятствую — если такое и случается, то непреднамеренно…
Просто я не занимаюсь этим профессионально… Единственно чем я занимаюсь профессионально, это повышением благосостояния своей семьи. Для этого я использую свои профессиональные навыки в области разработки программного обеспечения.
Теперь представим себе, что появляется новый фреймворк, или там язык программирования — что-то в таком роде (чего там представлять — чуть не каждый день происходит). Мои действия в связи с этим событиям всегда однотипны — я пытаюсь оценить — смогу я заработать на этом деньги или нет, и если ответ положительный, я стараюсь запрыгнуть в поезд, по возможности пораньше (но никогда первым — на набитии шишек много денег не заработаешь).
Если же ответ негативный, это вовсе не означает, что упомянутый фреймворк или ЯП плохой или бесперспективный… Может быть и так, но в случае отрицательного ответа мне это перестает быть интересным. Просто отрицательный ответ означает, что лично я не могу заработать на этом деньги… Ну или может и могу, но овчинка просто не стоит выделки лично для меня и конкретно там, где я пребываю сейчас или намереваюсь пребывать в обозримом будущем
Так что для меня вся эта свистопляска с фреймворками и ЯП это скорее хлеб насущный — если мне не составит сверхусилий сие освоить, и если я считаю, что оно скоро войдет в моду… да плевать мне насколько оно улучшит этот мир! Поскорее освоить и продать свое умение по наивысшему рейту, пока конкуренты не подтянулись и не опустили эти рейты — вот что главное!
Конечно я совершаю ошибки, но в сумме я всегда в плюсе ибо не складываю яйца в одну корзину… В качестве примеров:
— очень удачные выбор был сделан мною в 1998 г. в пользу JAVA — я определенно не прогадал, хотя в то время java была чем-то чуть большим чем курьезом (ранее я использовал delphi, и дополнительным скилзом было проектирование БД — причем последнее очень ценилось в то время как независимая профессиональная специализация). Очень скоро началась откровенная охота на java разработчиков и опыт в три года считался крутостью…
— Неправильное решение было принято мной в 2001-2002 гг — я посчитал, что работать с Javascript и вообще с веб разработкой это не барское дело — позже, в 2006-м мне пришлось нагонять упущенное, фактически запрыгнув на подножку уходящего поезда… И надо сказать, что я все еще в позиции догоняющего, так как сделал ставку на всякие js фреймфорки
— в начале двухтысячных я принял вполне осознанное решение не связываться с технологиями microsoft и в частности с платформой .NET — это было правильное решение, несмотря на то, что какое то время многие компании искали универсальных разработчиков .NET + java — я посчитал, что сие есть временное явление, и позже все равно придется выбирать одну из двух платформ. соответственно имея солидный опыт с java в условиях продолжающегося бума спроса на Java разработчиков, я посчитал, что мне невыгодно изучать платформу, в которой я буду новичком еще пару лет
— spring framework… когда же это было… примерно в 2004-м наверное… поначалу я сопротивлялся, ибо вообще не понимал нахрена оно мне надо… но пришлось… потом пригодилось раз, другой… И я полез изучать уже внимательно… И понял, что надо делать ставку на него… И не прогадал — сей фреймворк меня уже стабильно кормит десяток лет, правда уже давно перейдя в разряд заурядных инструментов, потянув за собой всякие там hibernate (надо сказать к последнему я относился скептически как человек с солидным опытом разработки БД, но в конце концов мне платят деньги не за распальцовки а за работающее программное обеспечение реализованное за разумные деньги и в разумные сроки и с приемлемым качеством)
— html5 + js — я конкретно хромал по части javascript и веб разработке — я конечно что-то мог делать, но до профессионализма было далековато… Да, я довольно ловко делал ставки на фреймворки типа jQuery, предположив, что именно он задавит конкурентов, но я в принципе не мог конкурировать с javascript разработчиками на рынке труда… С появлением html5 я понял, что это шанс, правда не помню точно когда именно это было… сосредоточился на canvas полагая что именно оно принесет мне счастье… не то чтобы я считал это самым важным — просто самым доступным на тот момент (с возможностью использования в одном из текущих проектов). И да — это я смог «продать»! Ну и что, что сейчас это банальность? Тогда было круто!
— сознательный отказ от clojure в 2013-м (опыт около года как с clojure так и с clojurescript) — этого слона я продать не смогу
— сделал ставку на scala — в том же году… Ставка пока не сыграла, но еще не все потеряно
— ставка на angular и сознательный отказ от reactJS -ставка себя оправдала на все сто, теперь очередь за angular 2 и typescript — считаю оправданной ставкой, причем последнее вне зависимости от angular
— раздумываю насчет dart и golang — первое сомнительно (для меня сомнительно а не вообще) второе… надо думать… надо ли оно мне…
— microservices — уже поставил, уже получаю бонусы, на удивление изобрел такой велосипед, который приводит потенциальных работодателей в восторг (частичное решение, одной не очень серьезной, но надоедливой проблемы… в общем расскажу, когда это уже никому не будет интересно)
— AWS — выбор неосознанный, но уж коли пошло оно, пусть будет оно — никаких преимуществ или недостатков по сравнению с конкурентами не усматриваю
— docker + devops — рассчитываю получить вторую устойчивую специализацию, которая постепенно превратится в основную… староват я уже код писать… а руководить ничем не желаю — не барское это дело
— отказ от изучения node.js — в корне ошибочное решение, но поезд уже ушел, сливок там уже не снять…Randl
31.07.2016 01:52+9А могли бы просто с 1998 писать на Java — количество вакансий по-моему только растёт, спасибо Android. Чисто ИМХО, 20летний опыт принесет больше профита, чем прыжки с технологии на технологию в надежде урвать кусок пока нет конкурентов.
AlexPu
31.07.2016 09:44+1Я не просто мог-бы, я именно так и поступаю… с 98-го года я специализируюсь на java технологиях, которые помимо собственно ЯП включают в семя много чего еще (ЯП собственно уже давно никого не интересует сам по себе)
Но есть одно но: количество java разработчиков также растет вместе с количеством вакансий… соответственно конкуренция за выскокодоходные рабочие места обостряется, а требования к разработчикам повышаются (а нередко и завышаются). И вот здесь освоение новейших и модных технологий, фреймворков, ЯП позволяет снять сливки на волне интереса к очередной серебряной пуле. В качестве примера — моя сегодняшняя работа (работаю уже 2 недели) была получена благодаря двум волшебным словам — «микросервисы» и «докер» (с наглядной демонстрацией своих скилзов в этой области) — задача перевести существующее монолитное приложение на архитектуру микросервисов. Деплоймент на AWS (собственно он и сейчас там)… 700 евро плюс (в смысле это повышение моей зарплаты по сравнению с предыдущем местом работы)…konsoletyper
31.07.2016 11:16+1В качестве примера — моя сегодняшняя работа (работаю уже 2 недели) была получена благодаря двум волшебным словам — «микросервисы» и «докер» (с наглядной демонстрацией своих скилзов в этой области) — задача перевести существующее монолитное приложение на архитектуру микросервисов. Деплоймент на AWS (собственно он и сейчас там)… 700 евро плюс (в смысле это повышение моей зарплаты по сравнению с предыдущем местом работы)…
Вот приходили ко мне люди, знающие «волшебные слова», а когда я их просил написать разворот списка — сливались. Изучить такие вещи на базовом уровне (чтобы показать скилы на интервью) опытный разработчик способен за пару недель, ну месяц в крайнем случае. Тем более, что в том же docker нет ничего принципиально нового для человека, который имел дело с OpenVZ пару лет в продакшене. А вот что действительно нужно — фундаментальные знания, светлая голова и прямые руки — никак не зависит от новых парадигм и shiny new things.AlexPu
31.07.2016 11:34+2Ко мне тоже такие приходили… и что? Ко мне даже приходили люди, которые не умеют читать!
Умеющий читать скажем легко обнаружит в моем тексте указание на тот факт, что все мои скилзы достаточно надежно подтверждаются (либо я честно говорю, что не имею практического опыта работы с теми или иными технологиями, но обладаю некоторыми теоретическими познаниями).
Подтверждения в моем случае это рекомендации с предыдущих мест работы, демонстрация ранее выполненных работ (по согласованию с предыдущими работодателями, либо код разработанный мной специально для демонстрации на условиях свободной лицензии), либо выполнение тестовых заданий — на самом деле я очень люблю последнее, хотя должен признать, что такой подход мало что демонстрирует, но я обычно на собеседовании предлагаю потенциальному работодателю выбор — посмотреть ранее написанный мной код который хранится в облачных репозиториях, либо выполнить ихнее задание… Сразу предупреждаю, что в последнем случае я могу использовать написанный код для демонстрации другим потенциальным работодателям — это если задача интересная… Но увы — достойных вариантов такого рода было только два, сейчас остался один (второй, то-есть первый — написанный 6 лет назад, банально устарел)
Source
31.07.2016 13:18Спасибо за подробный рассказ. По-моему у Вас вполне здравая позиция и выбор технологий по конкретным критериям. Только к чему переживать об упущенных поездах, на двух одновременно ехать всё равно не удобно. По-любому какой-то один будет основным.
AlexPu
31.07.2016 13:56+2А кто переживает? Я не переживаю а постоянно прикидываю как мне заработать больше денег… И речь кстати не только о зарплате, а иногда (если повезет) даже не столько…
Что касается «одного, который будет основным»… во первых «основной» у меня есть — это java (не столько язык сколько технологическая платформа). Другое дело, что как я уже упомянул, я уже староват для того, чтобы писать код… а до пенсии еще лет двадцать… Но в начальники не рвусь (и причина опять таки вполне банальная — если я то-то делаю руками, работу я себе найду всегда и почти в любом месте — я ведь успел поработать в добром десятке европейский стран — для какого нибудь менеджера проектов подобная мобильность довольно проблематична… если он конечно не имеет явного таланта). Поэтому вот рассматриваю альтернативы тому, что является «основным»
AlexPu
31.07.2016 13:58Кстати по поводу неудобства езды на двух поездах — я сейчас еду как раз на двух — java + javascript и чувствую себя вполне комфортно — этому даже название придумали — full stack developer
Source
31.07.2016 14:06+2Если Вы JavaScript для client-side используете, а Java — для backend, то это всё-таки 1 поезд, просто с двумя вагонами, можно ещё 3-й вагон SQL прицепить )
А вот если и то и то для backend, то интересно было бы послушать каким образом Вы это совмещаете.AlexPu
31.07.2016 14:11Ну… может вы и правы… Но все-таки языки разные и никак не пересекаются между собой. Вполне возможно существование отдельный специалистов — backend и frontend разработчики (собственно таких сейчас много)
ну и серверный javascript я таки тоже осваиваю — тоже-ж мода… а в связи я широким распространением микросервисов так вообще — сам господь велел…
VolCh
31.07.2016 16:37+1А что сложного совмещать? Другое дело есть ли в этом смысл для конкретного проекта.
AlexPu
31.07.2016 19:50Новейшая парадигма разработки информационных систем под названием микросервисы практич4ски провоцирует использование широчайшего спектра языков и фреймворков… примерно полгода назад познакомился с проектом (очень известный ритейлер в электронной торговле… в основном одежда-обувь, прибыльны уже лет десять) — тотальная переделка всей системы… причем по частям… микросервисы разрабатываются микрокоммандами, которые свободны в выборе инструментария, языков и фреймворков… не 5у определенные рамки конечно существуют, но оди довольно широкие… так что в даннос проекте java отлично соседствует с javascript и golang…
Надеюсь внедрить нечто подобное в текущем проекте — как раз завтра должен представить первые наброски, первые идеи… потом будем обсуждать… еще через недельку… собственно это в принципе то, ради чего меня нанимали… ну и я надеюсь под шумок получит практический опыт как в некоторых технологиях, которогоне не хватает…
sumanai
31.07.2016 22:41микрокоммандами, которые свободны в выборе инструментария, языков и фреймворков… не 5у определенные рамки конечно существуют, но оди довольно широкие…
А сопровождению это вообще поддаваться будет? Не, я понимаю, что во время разработки народу много, найдутся спецы по любому языку, но сопровождать то они не все будут…AlexPu
31.07.2016 23:24Легко! Если конечно проектом кто-то руководит…
AlexPu
31.07.2016 23:29Мое персональное определение термина «микросервис»: часть функционала реализуемая силами друх разработчиков за две-три недели, в виде независимо запускаемого в собственном адресном пространстве приложения(сервиса). Взаимодействие с этим сервисом осуществляетсяпосредством строго определенного (документированного) протокола
sumanai
01.08.2016 02:00Ну вот разрабатывали сервис 20 человек с использованием десятка языков, а сопровождать будет один.
Что, ему нужно знать десяток языков, используемых при разработке?VolCh
01.08.2016 07:39Если не знает и не хочет знать, то просто переписывает микросервис на известном ему языке, который лучше подходит для задачи.
AlexPu
01.08.2016 08:11как вариант… он может обратиться к жрецу вуду, может изучить соответствующие технологии, может отказаться от задачи и тогда ее передадут более компетентному сотруднику, может переписать сервис в отведенное время… с точки зрения бизнеса это безразлично
AlexPu
01.08.2016 08:09Опять-же вы в корне неверно уловили современные тенденции разработки… Грубо говоря (ну очень грубо) — те-же 20 человек и будут сопровождать сервис
mayorovp
01.08.2016 08:53Ха-ха. Говорю это как человек, к которому в итоге этот сервис на сопровождение попадет.
VolCh
01.08.2016 09:06Но в общем и в целом налицо ошибка управления процессами, если оказывается, что передают на поддержку проект с технологиями по которому внезапно нет специалистов. Ну или бизнес просчитал все риски, что имеющиеся «тыжепрограммисты» не справятся.
AlexPu
01.08.2016 09:40«внезапнонетспециалистов» = «вы не справляетесь со соими обязанностями, поищите себе другое место работы, а мы поищем таки специалиста»
VolCh
02.08.2016 07:08К счастью с таким не сталкивался. Если отказывался от проекта потому что там слишком много незнакомых (и не интересных) мне технологий, то или брали специалиста по ним, или пересматривали проект, или отказывались от него вообще.
AlexPu
01.08.2016 09:38Вы можете говорить ха-ха или хи-хи, но то что написал я это наступающая реальность… ей даже название специальное придумали — devops. Грань между разработкой и сопровождением стирается, а разработка является составной частью всего жизненного цикла продукта — прекращается в момент его смерти…
И так будет до тех пор, пока не придумают еще какой нибуль *ops — то-есть лет пять еще
DrPass
01.08.2016 09:41+1> современные тенденции разработки… Грубо говоря (ну очень грубо) — те-же 20 человек и будут сопровождать сервис
Есть и такая «тенденция». Но это как раз пример «worst practices» — грубейшей управленческой ошибки при ведении проекта. Если проект не монолитный, а раздроблен между массой подрядчиков, и нет генерального, который является единственной точкой ответственности перед заказчиком, и нет единого стека технологий, то… куратор данного Франкенштейна должен как минимум застрелиться.AlexPu
01.08.2016 09:50Ну честно говоря мне плевать какая это практика — это работает, мне за это платят деньги, это позволяет мне развивать те скилзы, за которые мне будут платить деньги завтра… Если вам угодно считать это «worst practices» — я не против :)
AlexPu
01.08.2016 10:08-2Вот кстати вспомнилось…
Когда начали промышленно добываить сланцевый газ в российской прессе появилось множество статей высмеивающих саму идею — дескать при такой стоимости добычи — не взлетит… и вообще — «ха-ха-за, они все дебилы». По мере падения стоимости добычи пресса стала все больге упирать на неэколоичность такого способа добычи газа… Недавно, когда стоимость добычи сланцевого газа сравнялась со стоимостью добычи обычного, появиись сообщения, что газпром срочно инвестирует средства в разработку методов добычи сланцевого газа…
Когда ЕС стал развивать альтернативную энергетику, в российской прессе появилось множество статей — дескать при такой стоимости киловатт-часа — не взлетит… и вообще — «ха-ха-за, они все дебилы» По мере падения стоимости выработки солнечной и ветро-энергии, тот статей сменился, упор в них делался на якобы сомнительную экологичность таких источников энегрнии (приводились пространные рассуждения, но ни разу не приводилось каких либо рассчетов), плюс детское — «Они дотируют! Это нечестно!». Недавно, когда стоимость выработки солнечной и ветро энергии сравнялась в некоторых странах со стоимостью генерации на тепловых электростанциях работающих на природном газе, а дотации стали постепенно отменяться (не без проблем правда, кое где сокращение и отмена дотаций поставили под вопрос рентабельность сопутствующей инфраструктуры, но это то, что называется болезнбю роста — пофиксят), а объемы выраотки достигли впечатляюзих величин, появились сообщения, что газпром срочно инвестирует средства в развитие альтернативных источников энергии…
И да… Если у вас возникли вопросы к чему это я пишу — во второй половине 90х гг. про java тоже много чего говорили и писали (с конечным выводом «не взлетит»)… аргументированно так…
В обзем, если вам кажется, что кто-то что-то делает не так как вам КАЖЕТСЯ правильным, не спешите объявлять этого кого-то придурком — может быть вы просто чего-то не знаете?grossws
01.08.2016 11:54У альтернативной энергетики основная проблема — отсутствие предсказуемой выработки энергии и большая неравномерность выработки, что приводит к необходимости запасать эту энергию до момента повышенного потребления, что начинает стоить совсем других денег чем обещают. Это может быть приемлемо для индивидуальных домохозяйств, но не для промышленных потребителей. Не говоря уже о том, что лития на такое количество батарей на планете просто не хватит.
AlexPu
01.08.2016 14:46Да, это проблема… Причем проблема решаемая. И ее таки решают, и решают вполне успешно. Хотя конечно серебрянной пули нет и не будет
Давно заметил, что в нашем менталитете слово проблема почему-то означает отстутсиве необходимости что-то делать…
DrPass
01.08.2016 10:20Понимаете, с одной стороны, я тоже люблю деньги, и зарабатывать их мне очень-очень приятно. С другой стороны, если я вижу, что технология, которую впарили клиенту, решает его проблемы неэффективно, и с большой переплатой, я постараюсь его переубедить. Ну просто потому, что у меня есть ещё какая-то профессиональная совесть, и я хочу разрабатывать софт для того, чтобы он решал задачи, и именно за это получать деньги, а не просто максимально доить своих клиентов любым доступным способом.
AlexPu
01.08.2016 11:18Ну если вам удается делать деньги именно на этом, отчего-ж нет?
Это я не рассматриваю тот факт, что есть некая, отличная от нуля вероятность, что ваша точка зрения не совсем верна, а тот кого вы пытаетесь убедить в справледивости вашей точки зрения не является идиотом, и возможно хорошенько подумал над тем, что он делает… Это в принципе не важно…VolCh
02.08.2016 07:13Впаривать дорогую технологию прекрасно понимая, что для заказчика это не лучший выбор попахивает не то, что сделками с совестью, а мошенничеством.
AlexPu
02.08.2016 08:28А вы каким-то образом уже успели оценить стоимость технологий, которые я «впариваю»? молодца! Вам нужно в битву экстрасенсов…
taujavarob
02.08.2016 15:59-1А вы каким-то образом уже успели оценить стоимость технологий, которые я «впариваю»? молодца! Вам нужно в битву экстрасенсов…
Но ведь это довольно быстрый и выгодный путь к обогащению? — А когда нет «тормозов» — то почему бы и нет?AlexPu
02.08.2016 16:34-1ЭТО — это что?
«тормоза» — это что?taujavarob
02.08.2016 17:08-1ЭТО — это что?
Это — это «впаривание».
«тормоза» — это что?
Это что-то что не даёт «впаривать».AlexPu
03.08.2016 08:22понятно… ваши фантазии в общем…
taujavarob
03.08.2016 16:20AlexPu > понятно…
Варианты:
— Работаю потому что интересно — но мне ещё за это и платят!
— Работаю потому что интересно — но мне мало за это платят.
— Работаю потому что интересно и нужно людям — платят немного.
— Работаю потому что не желаю выходить из «зоны комфорта», да и денег хватает.
— Работаю потому что не желаю выходить из «зоны комфорта», но вот только платят мало.
— Работаю потому что только и только хочу много заработать — сменил немало мест.
— Хочу при жизни узнать, попаду я в рай или нет? (ну, а то что стану миллиардером и обеспечу семью — это вторично), — (Эти люди двигают прогресс).
Каждый выбирает сам, но тут иное — если при этом у всех дорога совпадает — то есть что-то что их объединяет — то что можно «определить заранее» — и, в вашем случае, не вспрыгивать на подножку набирающего ход поезда, а заранее занять место в купе, да что в купе — в спальном вагоне, даже в ресторане!
Представляете, вы в 2016 году знаете что «выстрелит» через пару лет? Что из «гадкого утёнка» взлетит!
Source
31.07.2016 20:18Ну да, я в том числе подразумевал вопрос: что такого может дать Node.js чего не может дать Java?
AlexPu
31.07.2016 20:35ДЕНЬГИ!
Source
31.07.2016 21:09Ну, если верить indeed.com, то разница на уровне Senior всего 6-7% в пользу Node.js. Т.е. по факту всё будет зависеть от выбора компании и проекта, а не от выбора между этими двумя вариантами.
AlexPu
31.07.2016 23:14+1Выне правильно понимаете как делаются деньги в этом болоте :)
Source
01.08.2016 21:51Ну, каждому кулику своё болото понятнее… Хотя я Вашу идею понял, на Node.js у Вас просто меньше достойных конкурентов )
AlexPu
01.08.2016 22:09Ну насчет болота это вы верно заметили… Я-же просто отметил тот факт, что статистические выкладки о средних зарплатах тут не при чем (а если еще учесть, в различных регионах уровни зарплат различны — как в целом, так и по специальностям… Да и достоверность этих данных вызывает сомнения)
Здесь дело в другом — в какой-то момент может возникнуть всплеск интереса к определенным технологиям, и тогда носители специфических навыков в течение ограниченного времени получают серьезное преимущество… А если эти навыки сопровождаются и другими, более традиционными навыками, так и вообще…
Suvitruf
01.08.2016 08:10У нас часть сервисов на Java, часть на Node.js Вполне довольны и тем, и тем.
Мне очень нравится Java, но на node.js прототипировать быстрее. Так что, если есть время, то пишу на Java, если нужно побыстрее сделать работающий сервис, то node.js (несмотря на все его минусы).
marshinov
31.07.2016 20:49+1Еще один интересный аспект при выборе технологий: как вы можете использовать их вместе и монетизировать это знание. Особенно это актуально для технарей-управленцев: тимлидов всяких, тех.директоров и архитекторов конечно. Зачастую выбор правильных технологий на старте проекта может сэкономить просто астрономические суммы.
Довольно ограниченный круг наших коллег способен прагматично смотреть на технологии, поэтому зачастую обоснование использования технологии А или В сводится к «А — это модно и круто, а B — это полный отстой». А вот выбрать правильные технологии, взвесить риски и представить план проекта в оцифрованном виде (читай в $) — это вообще уникальная компетенция.
VasilioRuzanni
31.07.2016 21:53+1А какой профит принес сознательный отказ от React.js? (реально интересны причины, ибо сам работаю и с тем, и как раз профит был в скором освоении React-а).
marshinov
31.07.2016 22:06О, как раз изучаю эту тему сейчас. С React'ом не знаком. По началу отпугивала jsx-лапша. Сейчас посмотрел на Angular 2, понял, что никуда от лапши не деться.
- На сколько сложно переключаться между Angular и React?
- В свете того, что TypeScript объявил о поддержке React, а для Angular 2 TypeScript считается стандартом, моно ли сказать, что писать на TypeScript под Angular и ReactJs — хорошая идея или есть нюансы?
AlexPu
31.07.2016 23:22Оба фреймворка близки по функционалу… но мне просто плевать на преимущества и недостатки — я технически не могу «снять сливки» на обоих фреймворках одновременно, поэтому выбрал то, на чем в данный мент легче заработать… пройдет еще годик другой и ангуляр с реактом станут анальностью — тем или другим будет владеть каждый разработчик и зарплаты будут самые что ни на есть средние…
VasilioRuzanni
01.08.2016 08:10+1JSX-лапша (с которой гневно плевался, когда первый раз увидел) — это как наркотик :) Начинаешь любить эту лапшу один в один в такой вот ситуации — просто понимаешь, что в том или ином виде она есть везде, а тут это оказывается на удивление удобно и без лишних сюрпризов, она просто работает и все.
TypeScript — поскольку это надмножество JavaScript — по сути, писать на React с TypeScript можно уже давно. Сам предпочитаю Babel (ES6/7) + FlowType (иногда типизация — требование команды заказчика), но сути дела особо не меняет. Честно, в большинстве случаев на практике не ощущаю необходимости в типизации вообще, я не использую IDE с IntelliSense и иже с ними. Но одно можно сказать точно — надо осваивать, это будет востребованная/продаваемая тема, в том числе благодаря мощно продвигаемому Angular 2.naneri
01.08.2016 13:08Тоже не никогда не ощущал необходимости в типизации, но мне старшие разрабы (в плане опыта, сам я мидл, но считаю себя джуниором), говорят, что на больших проектах без неё очень трудно.
AlexPu
31.07.2016 23:18Никакого — просто нужно было выбрать что-то одно. В моем случае я оцелил количество разработчиков (вокруг меня) реакта существенно больше, чем ангулар… с чем это связано я не знаю, но я предполоил, что -то время разработчики ангуляр будут более дефицитны… так оно в общем то и было… и есть… пока… ангуляр больше популярен у работодателей, чем у разработчиков… пока…
VasilioRuzanni
01.08.2016 08:01У меня ровно противоположный опыт :) Angular был крайне популярен на западе, сейчас очень много проектов по переводу AngularJS 1 приложений на React (иногда еще серверный пререндеринг из коробки играет не последнюю роль). Впрочем, Angular 2 тоже фигурирует, но пока очень мало.
То, что основной/предпочтительный обычно один — соглашусь. Однако, от себя добавлю, что чтобы быть крутым фронтендером — освоить нужно бы оба. Изучение React поменяло то, как я пишу на Angular в свое время.AlexPu
01.08.2016 08:18Сейчас много проектов миграции с первой версии ангуляр на вторую… Именно за западе, причем не на всем западе, а конкретно в той его части, в которой я проживаю — в какой нибудь другой части все может быть иначе — например так, как это описали вы… Но меня это мало интересует — я думаю о том, как я буду зарабатывать деньги здесь и сейчас, и в течение ближайших двух-трех лет… если вдруг ангуляр перестанет быть популярным, можете бьть уверены, я даже поминок не буду справлять
Что касается «крутых фронтэндеров», то это явно не обо мне… я позиционирую себя как full stack developer и выбираю проекты соответствующие тому стеку технологий, который есть у меня в бэкраунде. А бэкграунд я прокачиваю исходя из своих предположений о востребованности тех или иных технологий в ближайшие два-три года
PainSector
01.08.2016 12:48+3Мне кажется у вас в голове только деньги (судя по следующим постам) и это до добра не доводит по определению. То, что семье нужны деньги, никто не сомневается, но счастье — не в них. Вот вообще от них никак не зависит. По опыту скажу, что люди, которые в голове крутят «деньги, деньги, деньги» делают свою работу не очень хорошо, зачастую — плохо. Пытаются взяться за вещи и влезть в места, где больше платят, не особо вдаваясь в детали, в итоге на выходе сырой продукт и, возможно, испорченные отношения.
Да и вообще, зачем вам программирование, идите и продавайте оружие, рабов и снимайте порнуху — там доход на порядки больше, чем рыться в тормозящих IDE, написанных на яве или решать умерло ли ООП.
Считаю, что первично — это желание работать, получать наслаждение от процесса, тогда и в «поезда» не надо будет запрыгивать, потому что вы будете хорошим спецом и за вашу голову сами будут охотиться (ну соответственно и деньги будут).
Не судите строго, но если не прав — пните меня. Удач!AlexPu
01.08.2016 12:58Вам все имнно КАЖЕТСЯ :)
Что касается того, чтом мне заниматься… вы знаете… я вполне способен самостоятельно решить каким образом мне зарабатывать деньги… В свои 47 лет я знаете ли кое что понимаю и в жизни и в разработке программного обеспечения, коим занимаюсь уже 24 года :)PainSector
01.08.2016 13:42+4Я не знаю, способны вы что-то решить или нет. И я не осуждал вас, как человека или семьянина. Мне просто не по душе такой подход к делу. А мир строится нами, и от нас многое зависит.
Моя мысль была в том, что художник, рисующий за деньги — не художник. Программист, создающий программы ради денег — не программист. Как человек, работающий с гос органами, сообщу, что если бы все не вертелось вокруг денег — жизнь была бы другой. А так — сплошные попилы, да поиск новых методов для присваивания денег.
Если ко мне приходит человек, в котором я заподозрю потребителя — его не стоит брать на работу. Потому что он банально уйдет к другим, стоит ему предложить чуть больше денег.
Любите деньги? Очень жаль, но приходится жить в таком мире, где это пропагандируется. В чем сила денег? Пример из вакуума — изнасиловали дочку, насильник откупился, заплатив полицейским, не прокатило — заплатил в прокуратуру. Вот она — сила денег.AlexPu
01.08.2016 14:48-1Ну мало ли что вам не по душе — это ведь совсем не обязательно говорит о вашей правоте, правда?
Вы можете работать бесплатно — с моей стороны никаких возражений… по крайней мере пока нахлдятся люди, готовые мне платить деньги за работу
Остальные ваши фантазии просто выдают в вас человека с криминальными наклонностямиVolCh
02.08.2016 07:23+1Следует различать «работать за деньги» и «работать ради денег». Вы, похоже, ради денег работаете. Положа руки на сердце, вы бы продолжили программировать за те же деньги, что и сейчас, если вам предложат больше денег за что-то другое, что вы умеете или, считаете, что быстро научитесь? Ну, например, из программистов переквалифицироваться в начальника программистов, заведомо понимая, что возможность программировать у вас будет только в личное время.
AlexPu
02.08.2016 08:35-2В «начальники программистов» я не переквалифицируюсь, о чем я писал ранее. Причина проста… точнее их две:
1) сомнение в своей профессиональной компетенции в качестве руководителя любого уровня
2) резкое сужение рынка найма — как разработчик я универсален и могу найти себе работу почти в любой точке земного шара… скажем на самом начале двухтысячных я переехал в UK… с тех пор пожил во многих странах, возвращался в РФ, потом опять уезжал… У меня не было бы такой свободы, если бы я был бы менеджером…
Все остальные ваши измышления есть всего лишь словоблудие и в частности того, что следует различать «работать за деньги» и «работать ради денег»… самое что ни на есть словоблудие…
PsyHaSTe
02.08.2016 17:48+1Речь тут только о том, что деньги — это компенсация, а не самоцель работы (по крайней мере у меня и у знакомых программистов). Человек выше имел ввиду, что уйти в начальники — это значит потерять возможность писать код (и творить в некотором роде). В то время как для вас это лишь сужение рынка, то есть опять «деньги деньги дребеденьги».
AlexPu
03.08.2016 09:30-1Наемный служащий отдает ЧАСТЬ СВОЕЙ ЖИЗНИ (в букавльном смысле — наемный работник продает свое время) работодателю в обмен на некое вознаграждение. Это вознаграждение не обязательно принимает денежную форму, но обязательно имеет денежное выражение. Вознаграждение также может включать в себя и нефиксированную часть, которая есть результат выполнения некоторых условий
Таким образом получается, что «вы и ваши знакомые программисты» отдаете часть СВОЕГО ВРЕМЕНИ работодателю не получая взамен какой либо компенсации? Ибо эта самая компенсация по вашим словам не является самоцелью при найме на работу?
А что там имел в виду «человек выше» этот самый человек в общем то и сам не в курсе… Да и вы тоже, считая, что единственный способ творить для всех людей есть написание программного кода, просто потому, что вам лично иные способы по какой-то причине недоступны
Вообще «вы и ваши знакомые программисты» явно вообразили, что «я и мои знакомые программисты» это такие мрачные люди, которые занимаются противным им делом, которое помимо всего прочего включает в себя какие то там «впаривания» итп… «вы и ваши знакомые программисты» в принципе не способны вообразить человека, обладающего ПОТВЕРЖДАЕМЫМИ профессиональными навыками, который прилагает усилия чтобы быть максимально востребованным на рынке, и продавать свое время по максимально возможной (для него лично) цене…
«вы и ваши знакомые программисты» просто напросто одержимы гордыней — вы считаете, что только вы являетесь высокоморальной личностью имеющей правол судить кто и что делает правильно, а кто нет… в принципе я тоже был таким… давно… и у вас пройдет — это у всех проходит — у одних раньше, у других позже… Кончено встреяаются инфантильные личности и в пенсионном возрасте, но это все-таки скрее исключение… ну… я надеюсь…
PsyHaSTe
03.08.2016 12:46+2А когда вы на рыбалку ездите, вы от кого возганраждение ожидаете получить? А в отпуске? Пришел на пляж — подайте-ка сотню баксов за это. Поплавал до буйков — ба, да это же все 200.
Получать деньги за то, чем нравится заниматься — это одно, работать исключительно ради денег — другое. Если в одном месте платят в полтора раза больше, чем на текущем, но там постоянно стрессовая ситуация, код эпохи 90 и атмосфера всеобщей спешки и отношения «ты начальник — я дурак» — я лучше останусь на текущем, а вы, судя по этим комментам, перейдете, «та же платять больше-та». Ну или в лучшем случае не перейдете, посчитав, сколько будет стоит компенсация этого всего психологами, лекарствами и пр.
«вы и ваши знакомые программисты» в принципе не способны вообразить
Ну в принципе можно и закончить, в ход пошли уже хрустальные шары.
«вы и ваши знакомые программисты» просто напросто одержимы гордыней — вы считаете, что только вы являетесь высокоморальной личностью имеющей правол судить кто и что делает правильно, а кто нет…
Пока что этим только вы тут занимаетесь — я ни слова не сказал вас или мое отношение к вам, зато тут же оказался юнцом и гордецом. Ну что ж, если вам так легче…
Ну и да, батрачить за еду в «интересном стартапе» никто не предлагал, просто обычно баланс между ЗП и удовлетворительностью места у людей находится ближе к золотой середине, а не к крайностям.AlexPu
03.08.2016 14:23Когда я еду на рыбалку, я не прошу никого это оплачивать.
>>Получать деньги за то, чем нравится заниматься — это одно, работать исключительно ради денег — другое.
Это исключительно в вашем вообрадении… С чего вы решили, что мне не нравится моя профессия? Придумали? Так вот — мне моя профессия нравится. Но это не означает, что я на работе занимаюсь исключительно приятными моему сердцу вещами, и это не означает, что я работаю не ражи денег, а ради чего-то еще… Если мне приспичит написать программный код не ради денег, а ради развлечения, я это сделаю в нерабочее время
>>Ну в принципе можно и закончить, в ход пошли уже хрустальные шары.
И тем не менее вы почему-то не заканчиваете…
>>Пока что этим только вы тут занимаетесь — я ни слова не сказал вас или мое отношение к вам, зато тут же оказался юнцом и гордецом. Ну что ж, если вам так легче…
Вы написали уйму предположений обо мне и о моем мирвозрении, не имея вообще никакой информации — вы просто придумали все что написали… Хрустальные шары, как вы изящно выразились…
>>Ну и да, батрачить за еду в «интересном стартапе» никто не предлагал, просто обычно баланс между ЗП и удовлетворительностью места у людей находится ближе к золотой середине, а не к крайностям.
О каких крайностях вы говорите? О тех, которые придумали? У меня никаких крайностей нет — я работаю за деньги, там, где считаю это приемлимым по разным соображениям, а работодатель платит мне деньги не за то, что я удовлетворяю свое эго, а за то, что я произвожу прибавочную стоимость, часть которой он, работодатель присваивает.
И соевершенно неважно стартап это или нет — последние три моих места работы к примеру были именно стартапами (не считая текущего места — оно уже не может считаться стартапом) — работал я там исключительно из-за днег, в том числе и тех, которые я потенциально мог получить (и в общем-то получал) в случае успешного развития стартапа… Мне просто не нужно себя оправдывать, на случай если стартап потерпел крах (дескать я работал не за деньги а за интерес, что эквивалентно высказыванию — делал продукт, который нахрен никому не нужен).
Более того, у меня имеются три вполне динамично развивающихся open source проекта — все они доступны под свододными лицензиями, но, возможно для вас сие будет сюрпризом — я занимаюсь ими исключительно ради денег :)
VolCh
03.08.2016 14:24+2Мы получаем компенсацию, но программируем не ради неё. Программировать будем, даже если придётся по денежным соображениями заниматься более высокооплачиваемой работой не связанной с программированием.
И мы не судим, а констатируем, что в профессии есть люди, для которых главным фактором нахождения в профессии вообще и на конкретном рабочем месте является денежное вознаграждение. Такие люди заметную часть личного, а то и рабочего времени тратят на мониторинг рынка труда и смежных рынков с целью продавать своё время по максимально возможной цене, с энтузиазмом осваивают только те технологии, которые выглядят обещающе с точки зрения максимизации доходов программистов.
И, да, с такими коллегами в одной команде нам работать не очень комфортно, хотя бы потому, что если условно объективно мы понимаем, что человеку в этой команде платят меньше чем он может получить в другом месте, значит этот человек скоро покинет команду.AlexPu
03.08.2016 15:12+1Ни в коем случае не возражаю против ващей точки зрения… Просто она ВАША… Это совсем не означает, что она единственно верная…
И да, НАМ не очень комфортно работать в одной команде с людьми, которые считают, что они должны самоудовлетворяться на работе, в то время как выполнять работу (в том числе и ту, которую они не способны выполнить в силу низкой квалификации), которую они посчитали для себя неприятной, должен кто-то другой… Ну а поскольку мое мнение по данным вопросам для моих работодателей достаточно ценно, я делаю все, чтобы в команде таких людей не было… В команде должны быть только те люди, которые ориентированны на разработку конечного продукта или сервиса, ради чего их собственно и наняли… все остальные идут развлекаться за свой счет…
0xd34df00d
03.08.2016 18:17+1Из желания самореализоваться в работе никак не следует, что они считают, что неприятную работу должен выполнять кто-то другой.
При этом, если я ещё могу понять силлогизм, приводящий вас к такому выводу, но представить, почему вы считаете, что это положительно коррелирует с низкой квалификацией, я не могу.
VolCh
03.08.2016 22:18+1Это не точка зрения, это грубое описание одного из множества возможных образов жизни и два типа из классификации профессиональных программистов.
А я делаю так, чтобы в команде не оставались люди, ориентированные на максимизацию зарплаты, особенно путём обучения «дорогим» технологиям в рабочем процессе. Обучаться в рабочем процессе нужно тем технологиям, которые нужны компании, а не выгодны работнику, который настоит на внедрение «дорогой» технологии (а то и начнёт внедрение втихаря), изучит её во время этого внедрения, а потом уйдёт туда, где больше платят за резюме со строчкой с этой технологией.
0xd34df00d
03.08.2016 18:12+3Да и вы тоже, считая, что единственный способ творить для всех людей есть написание программного кода, просто потому, что вам лично иные способы по какой-то причине недоступны
Просто интереса ради, а как творите вы?
Ну, сами понимаете, процитированное высказывание не может не привести к моему вопросу.
«вы и ваши знакомые программисты» в принципе не способны вообразить человека, обладающего ПОТВЕРЖДАЕМЫМИ профессиональными навыками, который прилагает усилия чтобы быть максимально востребованным на рынке, и продавать свое время по максимально возможной (для него лично) цене…
Вы, напротив, похоже, в принципе не способны представить человека с иной функцией полезности траты своего времени.
и у вас пройдет — это у всех проходит — у одних раньше, у других позже… Кончено встреяаются инфантильные личности и в пенсионном возрасте, но это все-таки скрее исключение… ну… я надеюсь…
Непроверяемое, почти религиозное утверждение. Люблю такое!
maxlips
02.08.2016 10:39что художник, рисующий за деньги — не художник
На вскидку, вспомню только Ван Гога и то, только потому, что его картины не хотели покупать :)
Если художник рисует за славу/известность это лучше или хуже?AlexPu
03.08.2016 09:38-1Любой художник ХОЧЕТ рисовать за деньги. Просто у некотоых это не получается.
Проблема здесь в том, что у одних художников это не получается потому, что у них отсутствует талант, а у друзих — потому, что они по разным причинам не способны продать свой труд. Это действительно проблема потому, что не существует надежного способа отличить первых от вторых, поэтому первые гордо себя причисляют ко вторым (нередко при этом обличая вторых в принадлежности к первым).
Среди разработчиков ПО ситуация полностью аналогична, за тем лишь исключением, что первая категория выявляется достаточно легко в процессе произвадственной деятельности. Но это ничуть не мешает им причислять себя ко второй категории при общении с теми, кто пока не имел чести ознакомится с результатами ихней производственной деятельности. Мне очень хотелось бы, чтобы это было не так, но к сожалению я имею чрезвычайно богатый опыт общения с подобными «творцами» (кстати и опыт успешного излечения от подобных болезней у меня тоже имеется)
taujavarob
01.08.2016 12:50+1AlexPu > Единственно чем я занимаюсь профессионально, это повышением благосостояния своей семьи.
Я прошёл почти такой путь как вы описали, но выбирал языки и технологии по «эстетическому принципу».
Есть только пара исключений — Дельфи меня не устроил наличием begin, — и я выбрал reactJS и (отверг typescript по причине что вы ранее указали: «не связываться с технологиями microsoft „).
Удивительно мне то, что цели выбора были у нас разные — вас интересовало только повышение благосостояния вашей семьи (вы фактически “Штольц в программировании»). А я переходил от языка к языку исключительно по «эстетическому принципу» (например, я считал С++ просто «языком С» с вынужденной нашлёпкой ООП).
А дорога то у меня и у вас вышла одна, но при таких разных парадигмах выбора.
Это заставляет меня задаться вопросом — не является ли "эстетический принцип" критерием при выборе технологий, что в практическом плане приводит к построению «дороги» по которой идут все остальные разработчики, разработчики просто желающие побольше заработать для повышение благосостояния своей семьи?
Иначе я не могу понять почему так — ибо я могу вам по всем вами вышеперечисленным языкам и технологиям, подробно пояснить почему я выбрал их, руководствуясь чисто «эстетическим принципом» выбора и вовсе не задумываясь о распределение зарплат по этим технологиям в будущем (критерий, которым руководствовались, как я понял, вы, выбирая эти же технологии, эти же языки).
Но прогнозируя будущее распределение зарплат по этим технологиям (которое так и произошло на практике), вы всё же выбирали как-то именно эти технологии, — то есть вы применяли всё же какой-то иной критерий выбора, ставя на эти технологии, критерий — который вы так и не указали в своём большом комментарии. Имхо.
AlexPu
01.08.2016 13:47+1Ну… пояснять мне ничего не надо — у каждого свои мотивы для тех или решений и поступков… Скажем мне решительно наплевать на наличие или отсутствие операторов begin и end в delphi (тем более, что к дельфи оные операторы не имеют непосредственного отношения) я просто в какой то момент решил, что delphi (несмотря на его тогдашнюю бешенную популятрость в РФ) не обеспечит мне стабильного заработка в будущем… Нет работу в принципе найти можно даже сейчас… и даже не только в РФ но… сами понимаете…
Когда я написал, что я решил не связываться с технологиями Micarosoft это вовсе не означало, что я считаю, что эти технологии чем-то плохи… Тут два момента — первый это строгая проприетарность этих технологий: я вынужден заботится о покупке/обновлени лицензий… ну или воровать ПО, что для устойчивого проффесионального роста неприемлимо, получать какие-то там сертификаты (это типично для проприетарных технологий) итп. В общем-то в какой-то момент это даже дает конкурентное преимущество, но уж больно геморно.
Кроме того проприетарность ставит разработчиков в зависимость от произвола компании-поставшика технологий и инструментов — что там им взбрыктется, то разработчики и будут кушать… Хотя должен сказать, что ситуация с java после продажи компании SUN Microsystems тоже стала приближаться к вышеописанной (и это в частности стимулирует меня «стелить соломку»), хотя пока еще не все так плохо (но в целом в этом отношении я доверяю Oracle не больше чем Microsoft).
что касается typescipt, то с ним ничего подобного не происходит — фактически это спецификация, которая хотя и вышла из стен корпорации, но не является проприетарной. И я прогнощирую, что именно Typescript будет вытеснять native javascript (хотя фанаты ES все равно останутся и будут востребованны)… ну… какое-то время… dart это хорошая альтернатива, но перспективы не ясны (и если бы дело было бы в эстетике, то при выборе между typescript и dart я бы отдал предпочтение последнему), в любом случае — не в ближайшие пару лет. Честно говоря я вообще бы предпочел scala.js но… здесь я точно был бы в меньшинстве — у меня-ж цель не эстетическое наслаждение — помните?
Второй момент емкость рынка — я в свое время как-то почуствовал, что java имеет огромный рыночный потенциал (хотя ощущения были очень смутными… такие термины как «технологический стек» тогда не использовались, но было понтно, что java в браузере это фигня полная), и что по сравнению с майкрософтовскими технологиями она с большей вероятностью позволит мне заработать… и судя по результатом общения с коллегами, эти ощущения были всеобщими (и всеобще-смутными — никто не мог сказать внятных аргументов, но все что-то чувствовали). И действительно — после двух проектов на java (первый вообще без каких либо фреймворков и библиотек! Я самолично писал ORM фреймвок, а мои коллеги нечто вроде аналога Struts! этот hardcore очень мне помог в дальнейшем), я обнаружил, что меня буквально рвут на части потенциальные работодатели! Я поехал в UK Я поехал в UK не владея толком английским языком — потребовалось около трех лет, чтобы я научился сносно говорить на этой варварской мове! Т.е я фактически оказался в первой волне тех, кто снимает сливки, пенки и прочую сметану на ажиотажном интересе к каким-то там технологиям…
И я продолжаю придерживаться описанной стратегии — пару раз мне удавалось повторить это, хотя эффект был уже пожиже — в частности эко касалось html5 (графика в браузере на основе Canvas — здесь я просто немного запоздал, просто потому, что был занят другим), и того, что сейчас именуют SPA (не поверите — на jquery едином писал полноценные web приложения, да еще и портировал их на simbian — сейчас как вспомню, так вздрогну… и ведь не так давно было)
Так что… никакой эстетики — просто деньги… И я ничуть этого не стыжусь — я работаю для того, чтобы заработать деньги — не всегда это может быть заработная плата — я охотно работаю в стартапах например, но всегда конечной целью являются именно они (даже если они выражены в «борзых щенках»)
Одно ясно — с java нынче надо быть осторожным — возросли «политические» риски поэтому надо стелить соломку (но стабильный кусок хлеба с маслом java платформа юудет обеспечивать еще долгие годы… Но с икрой поверх масла уже могут быть проблемы). Я пока вижу двух кандитатов — Node.js — это абсолютно бесспорно на данный момент и golang — если речь идет об архитектуре микросервисов (я бы не выбрал golang для разработки серьезного монолитного серверного приложения — по крайней мере сейчас)
Также фактором увеличивающим размер дохода еще примерно год-полтора будет являтьсяопыт работы с облачными платформами тима AWS (конкурент от гугла ничем не хуже) — оно как бы не обязательно, но дает серьезные бонусы при трудоустройстве… Только это должен быть серьезный опыт а не «поигрался немного с Free Tier»
docker… да… но тут ужескорее не сам он по себе а способность развернуть и управлять сотнями экземплярами… это то, обо что я сейчас бью свою башку…taujavarob
01.08.2016 17:11Скажем мне решительно наплевать на наличие или отсутствие операторов begin и end в delphi
Это ясно. Но я не об этом у вас спрашиваю.
я просто в какой то момент решил, что delphi (несмотря на его тогдашнюю бешенную популятрость в РФ) не обеспечит мне стабильного заработка в будущем… Нет работу в принципе найти можно даже сейчас… и даже не только в РФ но… сами понимаете…
Так и я решил, но я решил это именно на основании наличия begin и end. — А вы на каком основании это решили?
Когда я написал, что я решил не связываться с технологиями Micarosoft это вовсе не означало, что я считаю, что эти технологии чем-то плохи… Тут два момента — первый это строгая проприетарность этих технологий: я вынужден заботится о покупке/обновлени лицензий… ну или воровать ПО, что для устойчивого проффесионального роста неприемлимо, получать какие-то там сертификаты (это типично для проприетарных технологий) итп. В общем-то в какой-то момент это даже дает конкурентное преимущество, но уж больно геморно.
Так, теперь ясно про Microsoft.
что касается typescipt, то с ним ничего подобного не происходит — фактически это спецификация, которая хотя и вышла из стен корпорации, но не является проприетарной. И я прогнощирую, что именно Typescript будет вытеснять native javascript (хотя фанаты ES все равно останутся и будут востребованны)… ну… какое-то время… dart это хорошая альтернатива, но перспективы не ясны (и если бы дело было бы в эстетике, то при выборе между typescript и dart я бы отдал предпочтение последнему), в любом случае — не в ближайшие пару лет. Честно говоря я вообще бы предпочел scala.js но… здесь я точно был бы в меньшинстве — у меня-ж цель не эстетическое наслаждение — помните?
Это я помню. Но я так и не понял — что есть у вас за критерий? Вы пока рассуждаете типа как так — мне главное в рулетку выиграть — поэтому я поставил на красное.
Я же поставил на красное — потому что красное — это красивое! (для меня и многих).
Вы же типа пишите — я поставил на красное не потому что оно красивое (хотя я и понимаю что такое эстетика) — а потому что я просто хотел выиграть в эту рулетку.
Но вы так и не ответили на мой вопрос — Так почему вы выбрали красное?
Второй момент емкость рынка — я в свое время как-то почуствовал, что java имеет огромный рыночный потенциал (хотя ощущения были очень смутными… такие термины как «технологический стек» тогда не использовались, но было понтно, что java в браузере это фигня полная), и что по сравнению с майкрософтовскими технологиями она с большей вероятностью позволит мне заработать… и судя по результатом общения с коллегами, эти ощущения были всеобщими (и всеобще-смутными — никто не мог сказать внятных аргументов, но все что-то чувствовали). И действительно — после двух проектов на java (первый вообще без каких либо фреймворков и библиотек! Я самолично писал ORM фреймвок, а мои коллеги нечто вроде аналога Struts! этот hardcore очень мне помог в дальнейшем), я обнаружил, что меня буквально рвут на части потенциальные работодатели! Я поехал в UK Я поехал в UK не владея толком английским языком — потребовалось около трех лет, чтобы я научился сносно говорить на этой варварской мове! Т.е я фактически оказался в первой волне тех, кто снимает сливки, пенки и прочую сметану на ажиотажном интересе к каким-то там технологиям…
Так, опять вы пишите — «я в свое время как-то почуствовал, что java имеет огромный рыночный потенциал». Что это означает?
Я же оценил Java именно как суперновое — как язык С но без нашлёпок ООП (как в С++) — то есть я понял что Java взлетит именно из-за эстетики Javа.
Из вашего же ответа я не понял — что вы почувствовали? Что же именно в Java привело вас и ваших коллег в состояния волнения («никто не мог сказать внятных аргументов, но все что-то чувствовали»)?
Какая "эманация", имеющаяся в Java, подвигла вас тогда, когда Java была только для рисования в броузере, к изучению этого языка?
Так что… никакой эстетики — просто деньги…
Стоп. Опять вы уходите от моего вопроса — Какая "эманация", имеющаяся в Java, подвигла вас тогда, когда Java была только для рисования в броузере, к изучению этого языка?
Деньги — это уже потом. Что именно в такого в Java привело вас к решению — вот «оно», что принесёт мне деньги.
«Оно» — это что?
я работаю для того, чтобы заработать деньги
Это ясно, но критерием выбора технологий деньги не могут быть. — Они производное от правильного выбора.
Выбор технологий (которые принесут вам максимум прибыли) осуществляется по иным критериям.
И совпадение наших дорог намекает, что выбирая те или иные технологии, вы выбирали их чисто «эстетически» (возможно неосознанно), давя в себе эту «эстетику выбора».
Ваш комментарий и постоянное ваше упоминание, что ваш мотив "просто деньги" — говорит (имхо) том, что вы уже ощущаете как «эстетика выбора» — тот настоящий критерий, по которому вы фактически и выбираете технологии — уверяя себя что «никто не мог сказать внятных аргументов» просто пробивается к вам из вашего подсознания, но вы его сознательно давите своим «просто деньги».
Хм. Да. Фрейд. Да, намёк.
Да, вывод — вот это ваша фраза — «никто не мог сказать внятных аргументов» о Jаva, но все поняли что этот утёнок взлетит!
Эта ваша фраза и говорит мне, что все эти неосознаваемые при выборе аргументы, их невнятность, то есть неосознаваемость и есть тот «эстетический критерий», который я всё же осознал.
А иначе то и не ясно, почему вы всегда ставили на красное?
AlexPu
01.08.2016 17:47Как то трудно ответить на все сразу… По поводу дельфи все просто — его развитие явно застопорилось, у компании разработчика появились первые трудности…
И самое главное — разработчики уже поняли, что будущее за распределенными приложениями, в то время как нативный UI вторичен (хотя некоторые думают иначе даже сейчас)… А Борланд не могла представить внятной концепции что они готовы предложить для этого. В то время как Sun Microsystem уже тужилась на предмет EJB (и я был одним из первых кто стал эту фигню использовать — даже генератор кода написал). Иными словами java явно подавала надежды, а борланд — нет. Еще нюанс — наступала эра интернета (в 98-м все делали сайты электронной коммерции!) — здесь delhi… как бы помягче… не очень выигрышно смотрелся (хотя я лично зню героев, которые использовали delhi для разработки интернет-приложений)…
Теперь по поводу эстетики и денег… Вы напрасно меня пытаетесь уличить в том, что я делаю выбор из каких-то абстрактных представлений о красоте… Все проще, что я и описал изначально — каждая появляющаяс технология, фреймворк, язык анализируется мной на предмет того, могу ли я на этом заработать… И не потому, что красное это красное — я просто смотрю, насколько популярной становится эта штука в моем окружении и в мире вообще… Я общаюсь с коллегами, читаю всякие статьи, участвую в каких-то профессиональных тусовках, общаюсь с предпринимателями по разным поводам… Так или иначе информационный шум всегданаличествует… И если я могу с достаточным основанием предположить, что ценность технологии «Т» устойчиво будет расти (и она уже растет), тогда я анализирую, насколько геморно мне будет ее освоить, и смогу ли я где-то получить практический опыт… Если ответ и здесь положительный, тогда я прелпринимаю некие действия связи с этим… Если нет — просто послеживаю — а вдруг что изменится?
Но главный критерий это конечно ценность в глазах потенциальных работодателей/клиентов — если завтра в финляндии популярность react среди работодателей резко пойдет вверх (а я практически уверет, что этого не случится), то я немедлено переключусь на реакт, и сделаю все что в моих силах, чтобы перевести текущие проекты на реакт (это конечно не факт, что получится, но почти всегда что-то новое начинается там где я работаю, и уж тут моего веса вполне хватает)AlexPu
01.08.2016 17:50И это… java мне как раз сильно не понравился изначально… Меня вполне устраивал паскаль с его begin и end… Это к вопросу об эстетике… положа руку на сердце java в 98-м году была убога до крайности
taujavarob
01.08.2016 18:19AlexPu > И это… java мне как раз сильно не понравился изначально… Меня вполне устраивал паскаль с его begin и end… Это к вопросу об эстетике… положа руку на сердце java в 98-м году была убога до крайности
А не выбрать ли мне эту убогую Java, чтобы больше заработать?, — решили вы и начали её изучать.
Оно как-то не связывается у меня в голове это ваше решение. — Возможно только у меня такое.AlexPu
01.08.2016 18:44возможно только у вас не связывается… мне трудно судить что у вас там связывается…
taujavarob
01.08.2016 19:18AlexPu > возможно только у вас не связывается…
Выбор убогой Java c надеждой в будущем заработать на ней, предполагает что-то увидеть в ней помимо этой убогости, что-то, что позволило вам начать её изучение.AlexPu
01.08.2016 20:01Ничего это не предполагает… В java на тот момент я ничего особенного не увидел… Но увидел интерес рынка к java. И интерес весьма серьезный…
taujavarob
01.08.2016 20:19AlexPu > Но увидел интерес рынка к java. И интерес весьма серьезный…
Ясно. Почему рынок заинтересовался Java вам было не интересно.
taujavarob
01.08.2016 18:17По поводу дельфи все просто — его развитие явно застопорилось, у компании разработчика появились первые трудности…
Первые трудности? — Хм, напоминает теперешнее состояние с Java ЕЕ.
Все проще, что я и описал изначально — каждая появляющаяс технология, фреймворк, язык анализируется мной на предмет того, могу ли я на этом заработать… И не потому, что красное это красное — я просто смотрю, насколько популярной становится эта штука в моем окружении и в мире вообще…
Но разве вы не задумывались — почему эта штука становится популярной? — А иная не становится. Казалось бы — похожая штука, а не взлетает.
Так или иначе информационный шум всегданаличествует… И если я могу с достаточным основанием предположить, что ценность технологии «Т» устойчиво будет расти (и она уже растет),
И это всё, своё решение, вы принимаете на основании информационный шума? — То что в статье называется buzzwords? А причина этого buzzwords вас никогда не интересовала?
Но главный критерий это конечно ценность в глазах потенциальных работодателей/клиентов — если завтра в финляндии популярность react среди работодателей резко пойдет вверх
Тут вы себе противоречите. Ведь по Java вы сделали вывод до того, как Java перестала быть игрушкой. До того! И к её взлёту вы уже были готовы!AlexPu
01.08.2016 18:53>>Первые трудности? — Хм, напоминает теперешнее состояние с Java ЕЕ.
Точно!
>>Но разве вы не задумывались — почему эта штука становится популярной
Мне лично плевать — у меня в распоряжении много других вещей, над которыми намного приятнее задумываться
>>И это всё, своё решение, вы принимаете на основании информационный шума
Именно так. Могу сказать больше — вы тоже принимаете все свои решения на основании информационного шума, разве что вы делаете это неосознанно
>>Тут вы себе противоречите.
Только в вашем воображении — там у вас что-то не вяжется
>>Ведь по Java вы сделали вывод до того, как Java перестала быть игрушкой. До того! И к её взлёту вы уже были готовы!
Нет, готов не был — я просто сделал предположение о том, что эта технология будет выигрышной — в то время и на основании тех данных, что у меня были на тот момент, и в сравнении с теми технологиями, которые на тот момент наличествовали. А java, только-только перестав быть игрушкой УЖЕ вызывала чрезвычайный интерес у потенциальных работодателей. Я оказался в выигрыше просто потому. тто поставил на java чуть раньше других (и я не один такой был) — собственно в Петербурге в 98-м году было только две-три компании, которые что-то делали на java системно (не, ну еще писатели апплетов какие-то были...)
taujavarob
01.08.2016 19:25AlexPu > вы тоже принимаете все свои решения на основании информационного шума, разве что вы делаете это неосознанно
Трудно назвать эстетическое неприятия, например «begin», информационным шумом.
Конечно, buzzwords, влияет. — Выпустили Swift — я сразу же глянул — и мой эстетический фильтр его отверг. (про «эстетику» Object-C я молчу вообще). А сегодня смотрю рейтинг языков — Swift падает.
AlexPu
01.08.2016 20:06Люди которые принимают неосознанные решения на основе рекламы или пропаганды, считают это недостойным и изобретают для себя всякие оправдания…
эстетическое неприятие инструкций begin и end из этой серии — и в частности обсуждение этой особенности паскаля и было содержанием информационного шума посвященного языку паскаль в определенный период времени (это в частности канонические споры C++ vs pascal, которые позже сменили не менее дебильные споры C++ vs java, а еще позже C# vs java)taujavarob
01.08.2016 20:21AlexPu > которые позже сменили не менее дебильные споры C++ vs java, а еще позже C# vs java
Понятно. Из этих дебильных споров образуется поток, в который уносит и простых девелоперов, цель которых проста — деньги и только деньги.
0xd34df00d
02.08.2016 01:52Читаю я вас, и как-то страшно мне за своё будущее становится.
Я знаю плюсы. Ну, наверное, хорошо их знаю. Более того, они мне нравятся. Я на них даже в свободное время, по вечерам и выходным пописываю. За развитием слежу, стандарты новые, это всё. А другие мейнстрим-языки меня не привлекают. JS — фуфуфу, java — фуфуфу, питон — фуфуфу, ну и так далее.
А вот хаскель я тоже люблю. И тоже пишу на нём иногда по вечерам и выходным. Раст интересный. Агду-идрис-кок надо бы заботать. Но хаскелями и идрисами в команде особо не поработаешь, и этих ваших денег тоже особо не заработаешь.
Ещё мне нравится математика. И в ней я бесконечно хуже, чем в программировании, поэтому, кстати, её ботать как-то приятнее и полезнее.
И я хотел бы вот так и через 10 лет, писать на C++24, тыкать в готовящийся к выходу C++27, пописывать на приятных, но почти эзотерических языках и изучать что-то совсем непрограммистское.
Но деньги-то, деньги где? А то того и гляди, чтобы не бомжевать, придётся реакты, ноде.жс и прочее изучать. А это как-то неприятно, потому что программирование — и самоцель в том числе.AlexPu
02.08.2016 08:41если у вас программирование самоцель, то вы должны быть готовы оплачивать свое хобби
Хотя я не не совсем понимаю, почему C++ является проблемой? да, рост зарплат там по большей части определяется инфляционными факторами, но с другой стороны язык еще очень долго будет востребован… Не знаю как в РФ но в столичном регионе финляндии работы для разработчика C++ найти сравнительно несложно… ну… посложнее наверное чем java или javascript разработчику но с учетом того, что C++ разработчиков осталось не так чтобы уж очень много, и их количество сокращается… Кроме того, у C++ шире возможности удаленного трудоустройства…
Так что… хлеб с маслом вам в принципе гарантированны… насчет икры… сомнительно (но тоже в принципе возможно!) — это если вы не будете ставить во главу угла «нравится»/«не нравится», а будете заниматься тем, что ВОСТРЕБОВАННО0xd34df00d
02.08.2016 17:29Ну, конкретно сейчас у меня довольно неплохой хлеб с довольно неплохой икрой, с американским вкусом. Но смотрю я просто на окружающих, которые всё время новые технологии изучают, языки там всякие (причём, не принципиально новые языки-то, сдвига парадигмы не происходит от них), фреймворки, и периодически возникает ощущение, что я делаю что-то не так.
AlexPu
03.08.2016 09:57Вы немножко не поняли что именно я написал — я написал о том, что хлеб с маслом вам ГАРАНТИРОВАННЫ (по крайней мере в ближайшие лет 15), а вот икра поверх масла или поверх хлеба (если вы откажетесь от масла) или просто икра без хлеба и без масла (если вы откажетесь от них в пользу икры) вам НЕ ГАРАНТИРОВАНА, что конечно же не означает, что она невозможна в принципе. Так например я знаю (в данный момент времени) людей, которые имеют свою «икру», ведя разработки на delphi и cobol — однако их способность заработать на «икру» в случае их увольнения лично у меня вызывает некоторые сомнения (и у них тоже, но учитывая их предпенсионный возраст… по крайней мере тому, кто работает на cobol в общем-то ничего особо не угрожает… Ну кроме некоторого снижения размера пенсии в самом крайнем случае)
Что касается ваших ощущений… ну… вам виднее… Но почти в любой их существующих на сегоднящний момент технологических стеков есть возможность развиваться «в глубь»… Это даже проще, хотя и снижает востребованность таких специалистов первое время. С C++ ситуация сейчас даже несколько выигрышна потому, что популярность языка для прикладной разработки сильно упала, но вместе с тем очень сильно возрасла потребность в системной разработке (насколько я могу судить, здесь C++ в будущем придется конкурировать с Golang) — Я помню, когда Нокия сокращала около 7 тыс. чел. (включая 3 тыс чел., принудительно переведенны в штат accenture), все разработчики которые могли себя позиционировать как C++ разработчики (речь идет о прекращении разработки Simbian и MeeGo) были буквально нарасхват — некоторые компании сразу после обхявления о сокращениях объявили о маштабном расширении штатов — в общем без работы данныая категория разработчиков точно не осталаст… Но выбор конечно поменьше, чем у java разработчиков… намного меньше…0xd34df00d
03.08.2016 18:18Вот, кстати, что-то мне подсказывает, что C++ с Golang в той области, которой я занимаюсь, не придётся конкурировать, ну, никогда.
semenyakinVS
02.08.2016 12:43Как по мне, если язык действительно нравится, в него вкладываются силы и он не является прямо совсем эзотерическим — на нём почти всегда можно заработать. На плюсах живёт Gamedev класса ААА с очень интересными проектам, в которых как раз-таки требуется математика (и работа с изображением, и алгоритмы всякие интересные… что вообще ещё для счастья нужно?). Достаточно полутора лет опыта качественной, хорошей работы в компании класса ААА, немного активности в open source и на хабре — и вас потом HR будут вас сами зазывать с вашими плюсам (хм, каламбур вышел).
По поводу компаний — на просторах бывшего СССР можно с сходу назвать минимум четыре, пишущих игры на хорошем уровне: Ubisoft, Crytek, 4A Games (в России Vostok Games был — не знаю про его судьбу), Wargaming, Mail.ru. Это те, что конкретно у меня в кэше лежали. Уверен, если погуглить — ещё с десяток найти можно, уверен.
П.С.: Да и в науке плюсы тоже для оптимизации используются, если геймдев кажется несерьёзным направлением.AlexPu
02.08.2016 13:49Заработать МОЖНО даже на человеческих испражнениях (причем вроде как даже очень неплохо)… вопрос в том, для кого что проще… и где — тоже немаловажно…
0xd34df00d
02.08.2016 17:29Геймдев кажется стрёмным направлением с кучей овертаймов :)
А сейчас, да, я этакими полунаучными вещами на плюсах и занимаюсь, среди прочего.semenyakinVS
02.08.2016 17:45Ну, так если хочется рационального пути — его описал AlexPu. Геймдев — путь для фанатов. «Живи быстро, умри молодым!» (с)
А если серьёзно — не так уж там туго с овертаймами, как может показаться. Судя по общению со знакомыми в «серьёзном» программировании, под релиз овертаймы возникают почти везде. Геймдев объёмами этих овретаймов не особо выделялся. Возможно, мне просто повезло, не буду говорить за тенденции индустрии вообще… Но мне кажется, что если работа действительно приносит удовольствие — овертаймы не особо пугают. У нас многие (я в том числе) засиживались иногда в офисе допоздна по своей воле — просто потому, что на работе было интереснее, чем дома)AlexPu
03.08.2016 11:29Если серьезно, то я не понимаю, почему геймдев кому-то кажется стремным… Направления определенно выигрышное с точки зрения «рационального пути», и никаких особых овертаймов там тоже не наблюдается… я конечно имею в виду свою колокольню — у нас за необоснованные овертаймы наказывают так, что желания повторить не наблюдается ни у кого, да и организация производственного процесса тоже вполне рациональна, так что потребностей в овертаймах тоже не наблюдается. И опять же — в нашем конкретном болоте геймдев растет охрененными темпами и зарплаты там определенно выше чем в среднем по рынку (точнее сказать не совсем так — в сегменте разработчиков с опытьм работы менее 5-и лет зарплаты ниже, а у тех ку кого более 5-ти — выше чем в среднем по рынку) — это личное наблюдение не претендующее на поноту… как там на самом деле тайна за семью печатями…
Я лично проходил собеседования в две крупные компании этого сегмента… Первый раз я просто не дождался результата (у нас весь процес найма может растянуться месяца на три, особенно в крупных корпорациях), получив устраивающий меня job offer из другой компании. Во втором случае я «засыпался» на вопросе «в какие игры вы играете» — я был вынужден сказать, что ни в какие, и в ту-же минуту почуствовал снижение интереса ко мне…
С моей точки зрения у геймдева есть определенные недостатки, но это недостатки которые актуальны только для меня лично
1) высокая нестабильность самого бизнеса даже самые успешные компании работающие в этой области нестабильны с финансовой точки зрения — я регулярно наблюдаю как эти компании регулярно отправляют сотрудников в неоплачиваемые отпуска (от увольнений всячески стараются воздержаться)… конечно неоплачиваемый отпуск у нас не является такой уж катастрофой но… не приятно в любом случае…
2) Это отрасль про которую можно сказать «вход рубль, выход — два» — если вы пошли работать в геймдев, то ваша привлекательность в других предметных областях снижается (почему — не понимаю!), хотя привлекательность в самой отрасли кончено растет пропорционально стажу. Проблема даже не в том, что количсетво работодателей ограничено — по крайней мере в данныц момент это не проблема — у нас растет как количество вакансий, так и количество работодателей… Проблема в том, что сама отрасль тоже может стагнировать, и тогда начитают высвобождаться одномоментно большое количество разработчиков со специфичным опытьм мало востребованным в других отраслях… Нет работа конечно найдется в любом случае но… какое-то время придется обходиться без икры…Shifty_Fox
03.08.2016 12:49+1Про выход очень просто. Гейм-дев использует свои технологии, никак не коррелирующие с рынком. Где может еще потребоваться глубокий OpenGL\DirectX API, Lua, игровые движки и библиотеки? В других областях другие библиотеки, и на выходе из гейм дев индустрии мы вынуждены включаться в другие области практически с нуля
Про стремность, не знаю, это скорее ИМХО, но гейм дев постоянно ставит принципиально новые задачи, которые не решить старыми способами. Сколько не тренируйся и не набивай руку, приходит очередной менеджер с фичами, которые ему кажутся просто эволюцией старой, а по механике и оптимизации графики нужно изворачиваться заного. Стресс, овертаймы, неприятный осадок. :)
0xd34df00d
03.08.2016 18:19Так по своей воле — это совсем не то же самое, что из-за косяков планирования и кривого менеджмента :)
А дома у меня и своё программирование есть, и я не верю, что на работе оно когда-либо будет точно такое же, чтобы жертвовать домашним.
Railwayman
31.07.2016 01:22+9Котлеты. Они устарели. От них надо избавляться.
> О да, я вчера попробовал приготовить котлету из масла. Мне казалось, это будет хорошая абстракция. Но она потекла…
Вот. теперь в моде корзинки.
>Корзинки? Для чего они?
Ходить за грибами
> Точно! Если взять современную корзинку, с защитой от протекания… Завтра же пойду в лес, собирать масло
aliencash
31.07.2016 01:22-2А я считаю, что все еще есть поле для роста. Мы все еще не достигли стадии когда любой менеджер на интуитивно понятном ему уровне может запрограммировать себе любой бизнес-инструмент. А пену на пути к этому можно просто сдуть. )))
Shifty_Fox
31.07.2016 14:48-2Как выше сказали, этого не будет. Еще есть фактор, что сообщество разработчиков не будет рыть себе такую яму — когда кто-то один раз напишет супер изоморфный конвеер, и весь мир разработчиков останется без работы.
aliencash
31.07.2016 14:57Если бы все разработчики были инди, я бы с вами согласился. Но есть еще и бизнес. Начнется все с очередной попытки крупной софтверной/игродельной конторы ускорить разработку при снижении издержек, ради чего будет применен специализированный ИИ.
pengyou
31.07.2016 01:55Вирт был прав.
potan
01.08.2016 15:41И где сейчас его разработки?
При том, что виртовские продукты появлялись очень быстро и были отличного качества, они по долгу не удерживались ни на одной экологической нише. Думаю, он все-таки упустил что то важное.taujavarob
01.08.2016 17:14potan > Думаю, он все-таки упустил что то важное.
Они были некрасивы?potan
01.08.2016 17:29Наоборот, очень элегантны. По крайней мере для нефункциональщиков.
taujavarob
01.08.2016 17:35potan > Наоборот, очень элегантны. По крайней мере для нефункциональщиков.
Элегантны? — Это Вирт придумал begin?potan
01.08.2016 18:15Ни чем не хуже "{". И не лучше.
К тому же еще в Algol так было.taujavarob
01.08.2016 18:22potan > Ни чем не хуже "{". И не лучше. К тому же еще в Algol так было.
Ясно. Я думаю Вирт упустил из виду что такое «элегантность». — Это и есть ответ на ваше: «Думаю, он все-таки упустил что то важное ».
semenyakinVS
31.07.2016 03:04+9Просто бальзам на душу. Да! Автор молодец. Переводчик тоже молодец — потому, что нашёл и перевёл.
Именно! Нужно убрать наконец чёртовы эмоции из программирования и научиться смотреть на вещи прагматично. Нужно развивать то, что есть, не строить с нуля похожее ради дошивания желаемых рюшечек. Мысли трезвые… НО!
Чтобы это работало так, как хочет автор, нужно чтобы все технологии или языки имели идеальных людей у руля. Если опустить обсуждаемую тут тему маркетинга, можно сказать, что люди создают новые технологии и/или языки в том числе для того, чтобы банально было удобнее работать с какой-нибудь предметной областью.
Надеюсь, мысль в общем ясна — но дальше у меня будет оффтоп про С++. Наверняка тут будут кучкования по языкам и технологиями… Но пока спрячу лучше под кат — всё-таки у публикации тег web-разработка.
Оффтоп про С++На мой взгляд, народ никогда не дёрнулся бы писать Rust или Go, если бы в С++ всё было удобно и благополучно. Настроения «до основания и затем» не возникают на ровном месте. Если бы люди могли с лёгкостью создавать проекты в экосистеме языка (а она вообще есть — гомогенная экосистема для С++?), если бы люди ощущали, что их желания понимают стандартизаторы языка — они бы вкладывали свою творческую энергию в развитие экосистемы С++, а не Rust или Go. И это было бы правильно безотносительно эмоций по отношению к С++, Rust и Go. Безотносительно эмоций — лучше бы концепции Go и Rust были бы включены в С++, чем Go и Rust возникли бы как самостоятельные языки.
Я не исключаю того, что сам возможно перейду на Rust или Go, если они взлетят. Но, не смотря на это, во мне останется чувство досады по поводу того, насколько глупая история привела к созданию этих языков и насколько нерационально человечество потратило своё время в этом направлении.
К чему я всё это пишу…
Если мы будем продолжать переключаться с одного языка на другой, мы никогда не обеспечим их надёжным инструментарием
Золотые слова. Но если люди, стоящие у руля языка или технологии отрываются от реальности и не желают вникнуть в интересы программистов (или не объясняют по-человечески почему интересы программистов идут в разрез со здравым смыслом) — программисты желают создавать инструменты, которые решит конкретно их проблемы. Тратят на это время, да, пытаются создать сообщество — чтобы работа шла быстрее. И это не мотивация «клевать всё что блестит». Это отчасти акт отчаяния.
ИМХО, естественно. Надеюсь, не задел ничьих чувств.Randl
31.07.2016 03:29+4лучше бы концепции Go и Rust были бы включены в С++, чем Go и Rust возникли бы как самостоятельные языки.
Вносить концепции ломающие обратную совместимость не сильно отличается от создания нового языка, особенно если их много. Не считая того, что Go и Rust достаточно разные языки, и внести концепции обоих в один язык нереально.
kvark
31.07.2016 04:34+1Легковесные потоки Go вполне можно впихнуть в С++ в качестве библиотеки. Я так понимаю, совет С++ как раз эту тему разжёвывает сейчас очень активно (глядя на успехи Go). Есть же boost-fiber, в конце концов.
С Rust ситуация сложнее. Определённо есть попытки, но пока не похоже, что С++ сможет в принципе достичь того же уровня безопасности.
mejedi
31.07.2016 12:02+2Легковесные потоки Go вполне можно впихнуть в С++ в качестве библиотеки
Можно, но получится так себе.
Дело тут вот в чем — с легковесными потоками, большой вопрос — сколько памяти выделять под стек. Слишком мало, и код будет падать по переполнению стека. Слишком много, с запасом — тоже плохо. Самое разумное, «растить» стек динамически.
Это можно делать по-разному, но самое эффективное, это скопировать все данные со стека в новую непрерывную область памяти и поправить указатели, как делает это Go.
VGrabko
31.07.2016 04:39если бы в плюсы просто перетащил основные киллер фичи с обеих ЯП и сделал бы их использование подобно использованию Си в С++
Randl
31.07.2016 05:18+4Так если ломать обратную совместимость (а то, что ее не ломает, уже либо в языке, либо в proposals и рано или поздно появится в С++), зачем цепляться за её остатки?
Напомню, что создатели Go считают, что С++ слишком сложный и именно поэтому создали Go. Другой из основных идей является желание сократить количество ключевых слов. И сборщик мусора в Go тоже есть. И как эти концепции вносить в C++? Go вообще сомнительный конкурент C++.
VGrabko
31.07.2016 13:43сборку мусора сделать как в расте (на стадии компиляции) но с возможностью ручками освободить память. А так то я учу сейчас плюсы и больших различий между ними и Go не заметил (ну кроме ООП конечно. Предполагаю что именно его и считают сложным)
semenyakinVS
31.07.2016 15:19По поводу обратной совместимости… У меня была по этому поводу вот какая мысль. Почему начиная с какой-то версии нельзя разделить стандарты С++? Оставить старый стандарт с его кучей legacy-фич и сделать новый стандарт, сбросив языковое старьё с парохода истории? Да, при этом разработчикам новых компиляторов придётся в полтора раза больше работы делать, а существующие компиляторы для legacy, скорее всего, остановятся в развитии. Но можно смягчить удар описанием рекомендованных практик для создания полуавтоматических инструментов перевода кода из старого в новый и постепенно обновить legacy. Насколько я знаю, так, например, делают ребята из Apply со своим языком Swift, который пока стабилизируется в смысле синтаксиса. Соглашусь, эплам в этом смысле легче — они вводят подобные практики на своей, одной платформе. Но и в рамках плюсов, как мне кажется, вопрос решаемый…
mayorovp
31.07.2016 16:08+1Так уже два раза делали… Но что-то не спешат переходить с legacy C++ ни на D, ни на Rust.
Главная проблема, как мне кажется — библиотеки, и их описание в формате заголовочных файлов. Вот эти самые заголовочные файлы, остро зависимые от legacy-фишек, никуда автоматически не перетащить.
semenyakinVS
31.07.2016 17:44Ну, я вообще немного другое имел в виду, но с учётом желания стать наследниками С++ эти языки подойдут как пример. Про D говорить не буду, мало о нём знаю, но если говорить про Rust… Мне кажется, на него не переходят потому, что экосистема языка пока слабовата. А слабовата она — опять так, по моему, вероятно, достаточно поверхностному мнению — как раз потому, что этот язык создавали как конкурента, а не как наследника. Если бы комитетчики из С++ сказали: «Всё, Rust это теперь современная версия С++, делаем всё, чтобы перебраться на него» — то дело бы пошло. Но сказать они такого не скажут, я думаю. Во всяком случае, в ближайшем будущем.
Вообще же, в контексте уход от legacy меня воодушевила решимость Kronos Group с их Vulkan API. Делали OpenGL десятки лет — и нет-нет, да решились выкатить новое API. С С++ будет труднее — но, возможно, придут рано или поздно в Комитет молодые и решительные, и тоже сделают что-нибудь подобное?
Вот эти самые заголовочные файлы, остро зависимые от legacy-фишек, никуда автоматически не перетащить
А в чём проблема именно с заголовочными файлами? Я так понимаю, если будет создан инструмент для трансляции из С++ в Rust, то с заголовочными файлами не должно быть проблем?mayorovp
31.07.2016 17:56+1Не думаю, что такой инструмент будет — языки слишком разные. Одному только сырому указателю в Rust может соответствовать, ЕМНИП, 4 разные, но бинарно совместимые конструкции. Какую из них автоматически выбирать?
Выбрать-то может только человек, сверяясь с документацией.
semenyakinVS
01.08.2016 02:34Ну, понятно что всё не автоматизировать. Но полуавтоматическую тулзу, думаю, сделать реально более или менее.
Shifty_Fox
31.07.2016 14:50Это очень сильно отличается. Останется компилятор. Останется ide. Останется синтаксис языка. Останется стандартная библиотека языка. Останутся все предыдущие разработки на этом языке.
Randl
31.07.2016 14:59Где ж они останутся, если обратная совместимость тю-тю. Да, основа останется, но она остается и так, неужели вы думаете что JetBrains пишет каждую IDE с нуля или LLVM каждый раз пишут все заново? Все написанное на языке придется переписывать под новый стандарт, а у кучи кода нет поддержки уже десятки лет.
При этом переход на новую версию будет проходить очень неохотно. Посмотрите на питон — вторая версия до сих пор жива, несмотря на все усилия создателей и то что разница между версиями не такая уж и большая.
Shifty_Fox
01.08.2016 06:48+1Я же могу импортировать legacy модуль в legacy режиме. Это наверняка есть и в Rust, но могли бы сделать полный автомат, на уровне, подключил h файл, и в Rust появились все legacy C++ функции из модуля. Я просто не знаю, возможно там это и так есть. Существующие компиляторы, чтобы собиралось под ios и android. Как в Rust с этим, все хорошо? Синтаксис C++, который мне так любим, с этим в Rust все хорошо?
Если бы брали что есть в C++, и просто прикручивали сверху опционально новые возможности, сохраняя возможность использовать старое через директивы, было бы гораздо лучше. Не надо выкидывать старые компиляторы, они мне нужны, чтобы собираться на целевые платформы. Я не хочу ждать, пока новый язык расчехлится на способность собираться везде, где собирается C++ без stdlib. Давайте сначала ехать, а потом шашечки.Randl
01.08.2016 10:57+2Если бы брали что есть в C++, и просто прикручивали сверху опционально новые возможности,
… то С++ превратился бы в монстра, которого никто понять не может. К нему и так прикручено столько, что мама не горюй.
Не надо выкидывать старые компиляторы
Но надо их переписывать.
Shifty_Fox
01.08.2016 14:27Пусть будет монстром, собираясь под iOS с старыми и новыми фичами. Я как-нибудь справлюсь с чистотой кода самостоятельно.
Randl
01.08.2016 14:59Ну попробуйте написать proposal в комитет, может вы и правда правы и все поймут какая шикарная это идея.
Shifty_Fox
01.08.2016 18:24Комитет далек от желаний рынка и простых разработчиков. Он хочет чистый язык, годами выписывать стандарты. Да и незачем обращаться в комитет, если можно разработать свой транслятор. Увы, все упирается в время и ресурсы.
Randl
02.08.2016 02:44Ну если для вас написание proposal по сложности равноценно написанию транслятора, не понимаю какие у вас вообще могут быть проблемы в программировании
grossws
02.08.2016 13:08Желательно ещё приложить почку.
Every extension proposal should be required to be accompanied by a kidney. People would submit only serious proposals, and nobody would submit more than two.
— Jim WaldoIdot
02.08.2016 13:29Напомнило, то как в Афинах автор законопроекта надевал на шею петлю и становился на табурет, и если законопроект не набирал голосов, то табурет вышибали.
taujavarob
02.08.2016 16:07Напомнило, то как в Афинах автор законопроекта надевал на шею петлю и становился на табурет, и если законопроект не набирал голосов, то табурет вышибали.
Интересно. Но в наших сенатах это не покатит — там всё под контролем.
grossws
01.08.2016 12:06+2Я же могу импортировать legacy модуль в legacy режиме. Это наверняка есть и в Rust, но могли бы сделать полный автомат, на уровне, подключил h файл, и в Rust появились все legacy C++ функции из модуля. Я просто не знаю, возможно там это и так есть.
В случае rust есть bindgen, который генерирует ffi обёртки над сишным кодом, но они, естественно, unsafe.
Вызов кода на c++ из любого языка — проблема (даже из c++, если зависимость бинарная и собранная другим компилятором), если не предоставлен сишный интерфейс (через
extern "C", чтобы избавится от name mangling).
Я не хочу ждать, пока новый язык расчехлится на способность собираться везде, где собирается C++ без stdlib.
Это называется Си с темплейтами и классами. И небольшим кусочком libstd++, т. к. остальное требует аллокатора, который не всегда есть на bare metal.
Shifty_Fox
01.08.2016 18:26Да, поправлю себя, я за сишные биндинги, чтобы была бинарная совместимость. Обертка API уже на совести разработчика.
0xd34df00d
02.08.2016 02:13+1Добавили вот в плюсы, например, автоматическую проверку владения на этапе компиляции, как в Rust. И тут вы импортируете хедер, который берёт объект по старой сырой ссылке или указателю, и что делать?
Shifty_Fox
03.08.2016 10:54Ничего. Я же импортирую _legacy_ header, с чего бы на нем должны работать новые фичи? Он весь целиком пойдет unsafe.
0xd34df00d
03.08.2016 18:24+1Так они не работают не только в нём, но и во всех файлах на новом языке, которые его используют, и так далее до построения транзитивного замыкания.
Shifty_Fox
04.08.2016 14:25Нет, либо я делаю safe обертку, и сам отвечаю за это, либо конкретная функция, в которой есть вызов unsafe метода, становится unsafe.
grossws
04.08.2016 16:20Проблема в том, что реально unsafe распространяется до границы модуля, а т. к. в плюсах их нет, то, фактически, на всю программу/библиотеку. Простой пример нелокальности для unsafe rust см. https://doc.rust-lang.org/nomicon/working-with-unsafe.html
Shifty_Fox
04.08.2016 14:26Вот к примеру я делал на C++ raii аллокатор памяти. Само собой ни ffmpeg, ни png\jpg библиотеки ничего о нем не знали, но это не мешало мне писать врапперы под эти библиотеки, чтобы быть спокойным что утечек нет.
0xd34df00d
05.08.2016 17:12Хм, а как эти враппервы выглядели? Можете показать кусочек кода? А то я не уверен, что правильно вас понимаю.
Source
31.07.2016 13:21До Rust и Go уже был написан D. Если с C++ понятно, что ломать обратную совместимость никто не хочет, то вот почему не захотели вкладываться в D непонятно…
bogolt
31.07.2016 18:57+7Мне кажется у D просто не было своей ниши. У D есть сборка мусора, но тут уже есть Java и .Net
И теперь те кому нужна была максимальная производительсть и минимальные затраты памяти выбирали плюсы, а остальные старые проверенные технологии.
Rust — дает сравнимую с плюсами скорость работы программы и потребление памяти, при гораздо более удобной и безопасной модели работы.
Go — отличная многопоточность — тут и горутины и каналы для передачи данных. И все это элементы языка да еще и first class citizens.
Такчто имхо Раст и Го обречены найти свою аудиторию в отличае от D ну и вероятно отгрызут немалый кусок адептов си++.
asdf87
31.07.2016 20:21+2… почему не захотели вкладываться в D непонятно…
На сколько я знаю, авторы при создании допустили как минимум 1 большую ошибку. После стаблизации 1-ой версии языка они вместо того чтобы вкладываться в экосистему (стабилизацию стандартной библиотеки (их тогда было две в D), поддержку IDE и пр. tool-ов) они практически сразу приступили к активному пилению 2-ой версии языка, что и отпугнуло разработчиков от перехода с C++ на D. А потом уже появились стандарты С++11, C++14 и D стал уже не столь актуален даже при всей крутости своего метапрограммирования.
rkfg
31.07.2016 14:07+1По-моему, очень хорошо, что появляются новые языки, типа тех же Rust и Go. Это здоровая конкуренция, которая подстёгивает крупных и старых игроков (Java, C++), заставляя их шевелиться. В Java уже ввели лямбды, скоро будет автовывод типов. Надеюсь, async/await тоже не за горами.
В C++17 могут появиться концепты, ограничения и требования для шаблонов, выглядит как невероятно крутая фича, позволяющая описывать требования к типу на метаязыке вместо наследования или интерфейсов. Я не знаю Haskell, может, там есть что-то такое, но из других более-менее мейнстримных языков такого не видел нигде. Ограничения на generics накладываются обычно через иерархию типов (extends/super в Java), но не как тут предлагается, в виде вычисления произвольного выражения.
Интерфейсы в Go считаются, вроде как, самым прогрессивным путём для достижения слабой связанности, позволяя привлекать сторонние подходящие классы, которые не связаны с интерфейсом, кроме как по совпадению сигнатур функций. Концепты же позволяют применять такие классы, которые просто удовлетворяют некоей логике поведения! Как пример: http://en.cppreference.com/w/cpp/concept/SequenceContainer — выразить эту логику с помощью интерфейсов или дженериков, похоже, достаточно сложно.semenyakinVS
31.07.2016 15:01По-моему, очень хорошо, что появляются новые языки, типа тех же Rust и Go
Да. Здоровая конкуренция это хорошо. Но если говорить про эффективность человечества в целом и сообщества программистов в частности — лучше бы эта конкуренция существовала в рамках групп, развивающих существующий язык. Это минимум сэкономило бы огромное количество времени на создание с нуля новых экосистем: компиляторы, IDE, инструменты, библиотеки — всё, что не касается напрямую особенностей новых языков, но то, без чего эти языки просто не смогут существовать и развиваться.
Как я уже писал, по моему мнению авторы Go и Rust решили создавать эти языки не от хорошей жизни, а по причине застоя в экосистеме С++.
На мой взгляд, главное что может вернуть плюсы в русло стабильного развития — это внятная билд-система со встроенным пакетным менеджером. Это позволит делать новые проекты легко вкручивая в них старые и заняться развитием языка, вместо неэффективного велосипедопроизводства (почти в каждом крупном проекте с нуля создают стандартную библиотеку — это нормально вообще?).
П.С.: Концепты это круто, да. Смотрел немного их реализацию в gcc — уже выглядит хорошо. Если появятся в паре с рефлексией (которую сейчас приходиться костылить самому) — вообще замечательно было бы… Но билд-система и пакетный менеджер, как по мне, более актуальны.rkfg
31.07.2016 16:33+1лучше бы эта конкуренция существовала в рамках групп, развивающих существующий язык
Увы, языки — штука прикладная, без обширной аудитории не получится сделать хороший язык. В наших силах разве что, как и описано в статье, не покупаться на блестяшки и ждать, пока новый язык повзрослеет, обрастёт инструментами и библиотеками, чтобы можно было перейти или просто попробовать без негативных первых впечатлений. Было бы здорово иметь универсальный фреймворк для быстрого создания IDE под любой язык со всеми фичами уровня Eclipse для Java. Конечно, в самом Eclipse есть что-то для этого, но судя по состоянию поддержки даже JVM-языков (Kotlin, Ceylon), не так-то легко его использовать эффективно. А писать на новом языке без IDE — это совсем не как самурай с мечом, только без меча. Это боль, страдания и беготня в документацию на каждый чих.
внятная билд-система со встроенным пакетным менеджером
Это да, требование времени. В том же C++17 планируются модули, которые дадут возможность создавать пакеты, как я читал. Очень хочется Maven под C++, но пока самым вменяемым остаётся CMake, хотя бы как билд-система. Статическая линковка по-прежнему сложна и обычно требует пересборки библиотек (в моём случае Qt, OpenSSL, libtorrent), а без неё даже между Ubuntu 14.04 и Debian Stretch совместимости не добиться — старый OpenSSL в 14.04.
почти в каждом крупном проекте с нуля создают стандартную библиотеку — это нормально вообще?
Ненормально, но надо смотреть мотивацию. Вообще, хорошо, когда можно сделать даже стандартную библиотеку самостоятельно, т.е. язык это не запрещает и позволяет некоторую гибкость. В UE4 зачем-то сделаны даже свои смартпоинтеры, может, для совместимости с C++98? Большие проекты обычно подразумевают обширное покрытие конфигураций и платформ, так что если по каким-то причинам STL не может такого предоставить, приходится велосипедить.
semenyakinVS
31.07.2016 17:55Было бы здорово иметь универсальный фреймворк для быстрого создания IDE под любой язык
Ну, вроде как упомянутый Eclipse был создан в том числе чтобы на его основе можно было IDE делать (ссылка).
Это да, требование времени
На мой взгляд, это необходимое условие для развития любого языка. Помимо прямого назначения (подтягивание зависимостей), пакетный менеджер несёт ещё одну очень важную функцию — он даёт возможность централизованного поиска решений и, соответственно, поощряет выбор существующих библиотек вместо создания своих. Пакетный менеджер сможет сфокусировать сообщество программистов С++ на новом, а не на очередной переработке старого. Особенно если придумать и встроить в язык что-то вроде Dependency Injection, чтобы можно было легко подменять пакеты.
Очень хочется Maven под C++, но пока самым вменяемым остаётся CMake, хотя бы как билд-система
Я CMake не понимаю. Возможно, маловато опыта работы, но вот тут я описал свои эмоции от взаимодействия с ним.
0xd34df00d
02.08.2016 02:15+3В том же C++17 планируются модули
Я чувствую себя прям вестником плохих новостей для вас, но модули тоже решили отложить.taujavarob
02.08.2016 16:09Я чувствую себя прям вестником плохих новостей для вас, но модули тоже решили отложить.
Причина — рановато для C++ модули?
0xd34df00d
02.08.2016 02:14+1В C++17 могут появиться концепты
Уже не могут, отложили.
Я не знаю Haskell, может, там есть что-то такое
Да, typeclasses — это что-то такое. Только удобнее на порядок.
pengyou
31.07.2016 11:32Очень выгодно будет стать разработчиком "языка, или двух, или трёх", кстати. То же с двумя-тремя фреймворками для всей планеты. При этом понятно, что разрабатывать их будут те же люди, что и сегодня, то есть, метод и концепция не поменяются.
И это хорошо, если в дело не вмешается мифология. С такой мифологией нелегко иметь дело, так как её поддерживает мнение «всех», мнение «профессионалов», ссылки на «промышленную практику» и т.д. и т.п. (явление спонтанной намагниченности, когда атомам магнитного материала оказывается энергетически выгодно выстроиться в любом, но одинаковом направлении; перемагничивание такого материала в любом другом направлении требует затрат энергии — т.наз. явление магнитного гистерезиса.)
Получится добровольное погружение умных ИТ-шников в хорошую годную монополию условного Гугла, окончательное бетонирование результатов 30 лет отрицательного отбора технологий по нетехническим критериям имени человекообразных бизнесменов и рептилоидных топ-менеджеров.
Хотя, очевидно, что любая конкуренция ведёт к монополии, сейчас хотя бы спасает ситуацию тот факт, что в ИТ технологии не умирают, а просто лишаются хайпа. (потому что продукты в ИТ нематериальные, и условный проект на мёртвом Wicketе будет жить и поддерживаться годами).
mydoom
31.07.2016 11:55+3Две цитаты с интервалом буквально в один комментарий:
«Мне очень жаль, но это как говорить, что молоток лучше отвёртки.»
"...C++ вероятно лучше, чем C. Java был улучшением по сравнению C++. Ruby вероятно немного лучше, чем Java".
Такое ощущение, что в авторе сидят две личности — адекватный профессионал и школьник с лора, которые пытаются друг друга перекричать его ртом.
bolk
31.07.2016 12:38Вы так говорите как будто фраза «это как говорить, что молоток лучше отвёртки» универсальна. Автор приводит её в контексте ООП против ФП.
mitrym
31.07.2016 12:51+4А при чем тут программирование, о нем ли статья?
taujavarob
01.08.2016 17:19@ mitrym > А при чем тут программирование, о нем ли статья?
Вы правы. Статья о том — я устал от новизны, всё это было, пора остановиться.
Ну, типа того.
prika148
31.07.2016 12:51+6… логарифмической кривой роста
… приближаемся к асимптоте
Простите, не смог удержаться ))
Очень хороший пост, мне понравилось!
Когда знаешь, что у логарифма не асимптоты на бесконечности
vladimirgamalian
31.07.2016 12:52А ещё иногда такое бывает, что один парень не осилил (пока что) ООП, и пишет в процедурном стиле. А называет это почему-то функциональным стилем. Ну функции же пишет, а что? Так смешно бывает.
taujavarob
01.08.2016 17:21vladimirgamalian > А ещё иногда такое бывает, что один парень не осилил (пока что) ООП, и пишет в процедурном стиле. А называет это почему-то функциональным стилем. Ну функции же пишет, а что? Так смешно бывает.
Меня больше удивляет то, что в массы процедурный стиль именно через JavaScript пробивается. В массы. То есть массово! — Вот уж смешно так смешно. — Процедурный стиль в массы и через JavaScript!VolCh
02.08.2016 07:28+1Давно не встречал чисто процедурного кода на JS. Куда ни плюнь — смесь функциональщины и ООП, замыкания с колбэками/промисами и всё это в объектах и над объектами.
Zenitchik
02.08.2016 10:08Язык к тому располагает.
taujavarob
02.08.2016 16:10Язык к тому располагает.
JavaScript располагает к многому — может поэтому он такой животворящий в настоящее время?
Nipheris
31.07.2016 13:05+9Да что уж там языки и фреймворки.
Казалось бы, что могло подвинуть реляционные БД с постамента наиболее популярной модели хранения данных? Кто бы мог подумать 10-15 лет назад, что в половине новых проектов будут пихать реляционные данные в Монгу, и ночами реализовывать контроль целостности и некое подобие транзакций, ссылаясь на «возможности масштабирования и доступности». При том, что в 80% этих проектов никогда не понадобится репликация больше чем на пару серверов.
Люди в слове «NoSQL» получили отмазку от изучения теории и практики РБД: появилась причина назвать реляционные базы неповоротливым старьём, и не изучать их больше, а быстренько веъхать в более простые документные базы и быть, так сказать, готовым к бою. Но далеко не каждый понимал, что ему придётся заново пройти весь путь.
Есть немало языков, которые стоит изучить (не обязательно использовать в разработке, но изучить). Есть и немало языков, которые лучше бы вообще не появлялись. Когда C++ разработчик предлагает попробовать Rust потому, что видит в нём устоявшиеся практики по управлению временем жизни объектов (передача владения и пр.) в кристаллизованом виде — это профессионализм (разумеется, вкупе со здоровой оценкой состояния инструментов для языка). Когда C++ «разработчик» предлагает попробовать Rust только потому, что Плюсы он так и не осилил в необходимом объеме — это лень и невежество.
Я убежден, что разработчики сегодня слишком ленивы и невежественны.
Автору спасибо за перевод!taujavarob
01.08.2016 17:25Nipheris > Казалось бы, что могло подвинуть реляционные БД с постамента наиболее популярной модели хранения данных?
Лет 25 назад, до прихода реляционных баз, было столько написано документов по "сетевым базам данных" — целый мировой комитет CODASIL был. — Вот оно откуда и берётся это «новое». — «Оно» проснулось.
solarplexus
31.07.2016 13:16Года два кодил на CoIDE на базе Eclipse. Ох и глючная система! На ровном месте перестает работать (проблемы испытывал не только я). IAR, CoIDE, Keil — все такое отстойное. Хоть бы взяли и соединили все в кучку, выбрали бы все лучшее. Хоть в текстовых редакторах работай.
fpinger
31.07.2016 13:21+1Всё это сансара. Сколько не бегай по кругу, а вернёшься туда же. К страданию.
TimsTims
31.07.2016 14:18+1> Да! Это непрофессионально. Нам нужно осознать, что мы упёрлись в асимптоту. Нам нужно выбрать язык, или два, или три.
Не согласен с автором.
Представим себе человечество в 500 году до н.э.
Люди изготавливают корабли из дерева, своими руками. И тут самый прошаренный прораб всем говорит:
-Да достали вы уже со своими экспериментами! Кто из камня, кто из тросняка делает, кто смазывает корабли, кто как попало делает! Где-то это приносит пользу, а где-то нет! Согласитесь, это не профессионально! Мы уперлись в предел человеческих возможностей! Делайте корабли из ДЕРЕВА, а не из ЖЕЛЕЗА (которое ТОНЕТ, карл!), и не придумывайте чепухи! Даже если вы что-то и придумаете, то рост будет незначительный (1%, вместо +100% как раньше).
Прям 1-в-1 статья. А ведь пройдет еще ~2500 лет, люди обуздают металлы и будут все делать по-другому…Shifty_Fox
31.07.2016 14:53+5И правильно скажет. Сначала должно пройти 10 веков, должны появиться соответствующие технологии обработки металлов, соответствующие инструменты по проверки безопасности судна. Статья прямо пишет — не нужно переходить на новые языки, в которых уровень сопровождения еще в каменном веке. Некуда торопиться.
TimsTims
31.07.2016 20:24+1Опять, я с вами не согласен. Каменный век так и будет оставаться каменным, и не появятся инструменты сами собой из неоткуда. Тем более, пока будут всем указывать, чтобы ничего не изобретали. Может есть на свете гений(99.999%), который придумает новый виток развития. Но запретив ему, он этого не сделает. И кто знает, может мы так и просидим еще 1000 лет, а потомки будут про нас говорить, что они застряли в своих убеждениях в каменном веке!
Я дополню, что чаще всего программисты — это энтузиасты, которым эта сфера по душе, им нравится её бездонная неизвестность. И эти же люди любят изучать что-то новое. Тот, кто не любит это делать, кому это не нравится — ему и работа программистом не нравится. Из этого следует, что запрещать программистом развиваться и придумывать новые вещи — значит спорить с самой сутью нашего увлечения.Source
31.07.2016 20:45Так речь то не о том, чтобы запрещать что-то придумывать, речь о том, что за предыдущие, допустим, 10 лет практически ничего нового не придумали. На первый взгляд кажется, что это бред, вон же каждую неделю что-то новое появляется. Но если задуматься, то по сути то реально ничего нового, просто небольшие плюшки, аля синтаксический сахар.
TimsTims
31.07.2016 22:05+1Ну может и не явно запрещает, но явно указывает, что надо перестать это делать. Вот цитаты:
> Пора остановить расточительное вспенивание языков и фреймворков, а также парадигм и процессов.
Ну как это не запрет искать новые пути?
> Пришло время, чтобы начать просто работать.
Да, давайте просто тесать камни. Ничего уже не придумать, всё что можно — уже придумали. Берите в руки молотки.
>Нам нужно выбрать язык, или два, или три. Небольшой набор простых фреймворков. А затем выстроить наши инструменты.
Это как: выберите себе два инструмента на выбор, и будьте мастером только их: «молоток, пила, отвертка, плоскогубцы, гвоздь, дрель». Нафиг нам всякие там «кусачки, кувалда, электропила, итд итп», ведь всё это — «лишь синтаксический сахар», а дом строят из молотков и гвоздей, остальное «лишь немного облегчает строительство».
>Кристаллизовать наши процессы. И стать настоящими профессионалами.
Да, профессионалом по отесыванию камней и строительству домов из камней и песка. Но опять-же, этот призыв ограничиваться звучит бредово (про ограничение развития программистов я уже написал выше). И так можно и 1000 лет продолжать писать код в текущем стиле, призывая всех: КОЛЛЕГИ, ВЫ ТОЛЬКО НИЧЕГО НОВОГО НЕ ПРИДУМЫВАЙТЕ! И через 1000 лет про нас будут писать/говорить/думать/общаться через поток мыслей, что мы были тупыми дибилами, застрявшими в цифровой эпохе электрических компьютеров на 1000 лет.Source
01.08.2016 00:33Вы почему-то исходите из того, что текущий уровень языков программирования очень низок. Но по факту нам и правда надо хорошенько осмыслить то, что придумали за предыдущие 60 лет. На тех компьютерах, которые у нас сейчас есть, крайне сложно придумать что-то новое в области программирования. Более того CPU уже упёрлись в физические пределы производства. И даже на случай, если дальнейший рост пойдёт через увеличение кол-ва ядер на порядки, уже всё придумано.
застрявшими в цифровой эпохе электрических компьютеров на 1000 лет.
В том то и дело, что придумывать новые компьютеры в компетенции программистов не входит, это будут делать физики.
А если Вы реально хотите придумать что-то новое в плане программирования, смотрите в сторону появляющихся вариантов, типа квантовых компьютеров. Там прогресс будет, но это уже совсем другая история. Не имеющая отношения к написанию 100500 примерно одинаковых фреймворков/библиотек для одной и той же задачи.
Shifty_Fox
01.08.2016 06:52Изобретайте, на здоровье. На поприще академических языков. Пусть пройдут ваши 10 веков, и ваша технология начнет применяться, когда ваши наработки будут серьезным продуктом. Речь о том, что индустрия хватает все с печки, когда там еще сырая мука.
VolCh
01.08.2016 07:46+3То есть запрет не на изобретение, а на использование изобретений?
Zenitchik
01.08.2016 10:05Не на использование, а на коммерческое внедрение сырых изобретений.
Знаете почему автомат Калашникова до сих пор на вооружении? Потому что его замена на любой существующий автомат не даёт повышения боевой эффективности адекватного увеличению стоимости.
taujavarob
01.08.2016 17:29Zenitchik > Знаете почему автомат Калашникова до сих пор на вооружении?
Просто сейчас в мире всё смешное и одноразовое — от жилищ и автомобилей до компов.
Автомат — единственное что имеет право на надёжность.
VolCh
02.08.2016 07:31По своему опыту обычный бизнес не спешит внедрять сырые технологии, если нет уверенности, что они вот-вот повзрослеют. Если только его не введут в заблуждение технари, которым хочется попробовать что-то новое и модное.
taujavarob
02.08.2016 16:12По своему опыту обычный бизнес не спешит внедрять сырые технологии, если нет уверенности, что они вот-вот повзрослеют. Если только его не введут в заблуждение технари, которым хочется попробовать что-то новое и модное.
Тесла! Электромобили?VolCh
03.08.2016 14:29Это не обычный, а инновационный бизнес. И он не внедряет, а создаёт эти технологии.
taujavarob
03.08.2016 16:52VolCh > И он не внедряет, а создаёт эти технологии.
Электромобиль был создан более 100 лет тому назад.
Сейчас идёт попытка внедрить эту супер-старую технологию.VolCh
03.08.2016 22:20+1Электромобиль вообще — это не технология, это принцип. Сейчас создаются технологии, позволяющие колесным транспортным средствам с электроприводом стать массовым продуктам.
Beholder
31.07.2016 14:30+2Если посмотреть на новейшие языки, в частности Java 8, Kotlin, Rust — то видно, что там ООП уже вперемешку с функциональным стилем. Выбирай что хочешь.
VolCh
31.07.2016 16:42Да собственно и в новых версиях старых языков то же самое. И это правильно, в общем и в целом совмещение ООП и ФП в одном проекте — нормально и даже хорошо (если грамотно выбрать где ФП использовать, а где ООП)
old_bear
31.07.2016 20:23+11IMHO, вся проблема в том, что хипстеры проникли в среду программистов. :)
Ну и в рекламе, как уже высказывались выше.
saggid
01.08.2016 06:44Я согласен, в этих словах есть доля правды. Поэтому я и не стремился изучить руби, например. Разницы особой нет, пхп позволяет писать прекрасно работающие проекты, так зачем мне тратить время на другой язык, который даст мне то же самое?)
Важнее потратить время на множество других более важных дел. Джс изучить более глубоко. Пхп изучить более глубоко. Изучить методологии, через которые получается писать модульный и качественный код. Изучить более глубоко Linux и его подсистемы, прокачать опыт системного администрирования. Это все по большей части изобрели еще в прошлом веке, и это то, что очень редко изучают современные программисты, потому что это им не так интересно, как изучать всякие свистульки. Они часто даже не понимают, что качество достигается не свистульками, а терпением, старательностью, порядком, правильными принципами разработки.
Но также с другой стороны, утверждать, что в мире программирования закончились важные изобретения — тоже неверно. Много чего интересного люди делают. Следить за развитием технологий всё равно важно, это немного бредовое утверждение, что технологии развиваться больше не будут. Будут, скорее всего, куда они денутся..
taujavarob
01.08.2016 17:33saggid > зучить более глубоко Linux и его подсистемы, прокачать опыт системного администрирования. Это все по большей части изобрели еще в прошлом веке, и это то, что очень редко изучают современные программисты, потому что это им не так интересно, как изучать всякие свистульки.
Дело в цене. За это мало в среднем по рынку платят.
это немного бредовое утверждение, что технологии развиваться больше не будут. Будут, скорее всего, куда они денутся..
Бывает что развитие (в том числе и технологическое) и останавливается. Это не раз было в Истории человечества.
azsx
02.08.2016 09:38Как по моему мнению, вся статья может быть сведена к двум пунктам.
1. Вы хотите зарабатывать работая в большом светлом офисе. Тогда помимо знания java Вам необходимо знать стек новых популярных языков, фреймворков и технологий. Причина банальна Ваш идеальный работодатель выберет самое популярное словечко и заставит программировать именно на нем. Это минус такого работодателя (выбирает язык для написания нового продукта на основе каких-то статеек о новом, модном и классном). Плюсом будет то, что зарплата платится несообразно Вашему труду (тупо платит много, за Ваш умный вид на рабочем месте). Типа зачем зарабатывать хорошо, будучи хорошим специалистом по java, если можно зарабатывать прекрасно — умея лишь бы как нибудь писать на go, rust, scala и прочее?
2. Вы пишите для себя. Вам надо выбрать свой язык, они во многом одинаковые, для своих платформ. Прекрасно, если Вы этот язык уже заранее выучили (делфи, разумеется).AlexPu
02.08.2016 10:03Вы как бы предполагаете, что работодатель есть заведомый идиот, и он совершает выбор на основании сиюминутных капизов? И все эти идиоты, совсем не слушают советов гордых но бедных программистов, которые пишут код не для того, чтобы созлать конкурентоспособный и востребованный рынком продукт, а ради собственного удовольствия? Но каким-то неведомым образом делают какие-то сумашедшие состояния?
Да, так оно и есть!taujavarob
02.08.2016 16:14Но каким-то неведомым образом делают какие-то сумашедшие состояния?
Типа рулетка. Типа того. — Но многих предпринимателей ждёт и турма, при жизни.AlexPu
02.08.2016 16:36А разработчиков которые остаются верными старому доброму delphi ждет процветание и богатство, да?
taujavarob
02.08.2016 17:09А разработчиков которые остаются верными старому доброму delphi ждет процветание и богатство, да?
Нет, в дельфи нет эстетики.
azsx
02.08.2016 10:31+1AlexPu немного не так, если работодатель не идеален (не идиот по вашему), то вы будете писать на языке ранее одобренный специалистами для данной задачи и требовать с вас будут за троих, так как умеют оценивать эффективность труда программиста, а платить как одному, так как умеют считать и мотивировать на труд не только баблом и выговарами. Вкратце, специалист по java с хорошей зарплатой.
Вы лично как хотите зарабатывать хорошо или отлично?AlexPu
02.08.2016 10:42понятно, что немного не так! Идеальный работодатель конечно должен быть идиотом! Но он чаще всего не идиот… И принимает решения опираясь на мнения экспертов, если сам не является экспертом — как вариант…
Разницу между зарабатывать хорошо и отлично я не понимаю — я просто пытаюсь увеличить свои доходы — не всегда прямолинейным способом (как то увеличение номинального оклада). Для этого есть возможности, которые можно использовать или не использовать, и хотелки тут не при чем
Что касается «требовать с вас будут за троих, так как умеют оценивать эффективность труда программиста, а платить как одному» — извечный стон эксплуатируемого… дескать меня заставляют работать много (я всегда спрашиваю, кто мешает уволиться?)
По поводу «умеют считать и мотивировать на труд не только баблом и выговарами.» — мне просто интересно, а какую еще мотивацию вы бы лично хотели для себя лично? Ежедневная порция мороженного? Экскурсии в музей?azsx
02.08.2016 11:05> Идеальный работодатель конечно должен быть идиотом!
Глупость какая-то. Которую придумываете Вы. Возможно, Вам просто надо кого-то назвать идиотом, чтобы потом доказать, что работодатели не идиоты, а я не удался…
Или я неудачник, у меня кругом полно примеров, когда менеджер всегда знает какую надо выбрать СУДБ и язык для проекта и никогда не может ответить почему надо выбрать именно эти варианты. При этом он понимает, что если программист задает вопрос «боже, а почему надо делать именно на rust или nosql» — то ловить с программиста как с увлеченного специалиста уже нечего. Но доказать этого не может.
taujavarob
02.08.2016 16:18По поводу «умеют считать и мотивировать на труд не только баблом и выговарами.» — мне просто интересно, а какую еще мотивацию вы бы лично хотели для себя лично? Ежедневная порция мороженного? Экскурсии в музей?
Эстетическое удовольствие от написание кода. И — удивление — мне за это ещё и деньги платят?AlexPu
02.08.2016 16:37Т.е. РАБОТОДАТЕЛЬ должен прикладывать усилия к тому, чтобы вы получали удовольствие от «написания кода»???
Просто удивительно, что вам еще кто-то деньги платит… или не платит?taujavarob
02.08.2016 17:11Т.е. РАБОТОДАТЕЛЬ должен прикладывать усилия к тому, чтобы вы получали удовольствие от «написания кода»???
И бесплатное кофе с печеньем. Это так уже принято. Повсеместно. (Говорят за бугром и пиво по пятницам бесплатное).
OksikOneC
02.08.2016 17:37Приветствую. Прочитал Ваш интересный рассказ про себя и свои приключения, и мне он показался даже интересней, чем сама перевод. Но как и коллега выше, у меня после всех ваших описаний, остался один единственный вопрос — как находясь в текущем моменте вы так удачно предсказывали выстрелы? Вы упомянули, что в 98-ом вам дельфи уже показалось проигрышной, а Java — перспективной. И вы упомянули распределенные системы. Не могли бы подробнее этот момент осветить, т.е. вот находясь в 98-ом, что вы понимали под распределенными системами? Чем это было тогда? Я почему так интересуюсь активно — я сам был в таком же положении как и вы, но только чуть позже, и я, находясь в том времени, как вам сказать — даже не понял, вообще, что технология java — живая. Первый коммерческий проект я сворганил на аплетах JSP, городил обычное приложение для торговли с веб-мордой. Деньги за работу я получил, но продуктом пользоваться не смогли, т.к. выяснилось, что для сносной работы ему требовались минимум 3-ех мегабитный канал (анлимный естественно). В том времени, в областном центре, где я жил, у клиента был мегабит. Поднять скорость до трех, в месячном эквиваленте, означало фантастические деньги. При этом, халтурить по фрилансу, используя то что я знал, это JSP и swing, опять же в том времени, не удавалось по той же самой причине — в рунете заказов не было на эти технологии, в забугорье — заказы были, но на уровне — несколько ином для моих скилов. Год где-то помыковшись, я решил уйти в разработку мобильных приложений. Это было время только только выхода 9-ого симбиана, еще даже кирпичей не было в железе, его поддерживающих. Но в JBuilder был BMS, который в свою очередь поддерживал нативно NDS, и соответственно, не имея железяки, можно было пилить приложения, ожидая чуть-чуть выхода первых кирпичей в железе, к которым кстати, был обещан официальный маркет! Ну типа — прямо вот пару месяцев, и все. И можно будет свои приложения официально продавать на весь мир! Это вроде бы была середина 2004 года. А первый симбиан-дивайс я увидел живой в середине 2006. Причем я даже не смог его купить, т.к. он стоил как подержанный неплохой автомобиль :) При этом, в 2004 параллельно со стеком JB-BMS-NDS, был параллельный стек разработки Qt-C++, кстати, нативный и на нем неплохо писались всякие АРМы для разных других симбиан-девайсов. Но почему, тогда мне показалось — не хипстерским этом. Как-то мой первый путь казался более каким-то прямо сверх-технологичным, с учетом обещанного маркета + я как бэ javа уже освоил. И в итоге, после таких, получается трех-летних блужданий из огня да в полымя, я пришел к выводу на тот момент, что сама платформа java — мертвая :) Т.е. я не увидел, находясь в том времени и том географическом регионе, каких-то реальных мест, где эта технология могла бы просто обеспечить стабильных хлеб. Но это были нулевые года, у вас же подобные потуги были на пяток лет раньше. И именно поэтому, я именно только сквозь призму своего опыта, и спрашиваю вас — КАК? Как вы так умудрялись всегда снимать сливки, при зародышном состоянии самой технологии?
DrPass
02.08.2016 23:50+4> Как вы так умудрялись всегда снимать сливки, при зародышном состоянии самой технологии?
Он разве тут где-то выкладывал архив выписок со своего банковского счета? Есть старый анекдот, как раз про подобные ситуации:
— Доктор, у меня с женщинами совсем не ладится, что посоветуете?
— А сколько вам лет?
— Восемьдесят.
— Ну так что же вы хотите?
— Но мои друзья такого же возраста, и говорят, что у них всё в порядке.
— Ну так и вы тоже говорите.OksikOneC
04.08.2016 15:29+2Хм. Пока в треде обвинения по делу AlexPu собраны следующие моменты:
— не знает бест практикс по микросервисам;
— ему пояснено (кстати, Вами), что программист должен убеждать клиента опять же в том, что ему (клиенту), что-то впарили и то, что впарили — это не торт. Опять же торт/не торт решает сам программист на основании в т.ч. и своей профессиональной совести;
— ему вменено, что «Впаривать дорогую технологию — мошеничество», хотя он не давал суммовых оценок чего либо, кроме своей прибавки на новом месте работы.
— ему озвучили догму, что «Программист, создающий программы ради денег — не программист. Художник, рисующий за деньги — не художник», поэтому его оппоненты поясняют «Если ко мне приходит человек, в котором я заподозрю потребителя — его не стоит брать на работу. Потому что он банально уйдет к другим, стоит ему предложить чуть больше денег»;
— Ему объяснили в чем разница между «работать за деньги» и «работать ради денег». Постулировали тезис, что «деньги — это компенсация, а не самоцель работы». Опять же «Получать деньги за то, чем нравится заниматься — это одно, работать исключительно ради денег — другое»;
— ну и дальше совсем трешово: «Мы получаем компенсацию», «мы не судим, а констатируем», «с такими коллегами в одной команде нам работать не очень комфортно». И вот эти «мы» так поясняют, почему ж все так: «я делаю так, чтобы в команде не оставались люди, ориентированные на максимизацию зарплаты, особенно путём обучения «дорогим» технологиям в рабочем процессе. Обучаться в рабочем процессе нужно тем технологиям, которые нужны компании, а не выгодны работнику, который настоит на внедрение «дорогой» технологии (а то и начнёт внедрение втихаря), изучит её во время этого внедрения, а потом уйдёт туда, где больше платят за резюме со строчкой с этой технологией».
На все эти догмы, постулаты, аксиомы и тезисы, AlexPu ответил или пытался ответить. Суд, думаю, еще вынесет свой окончательный вердикт, но мне в этом деле интересны не попытки образумить, доказать, или наоборот опровергнуть правильность/ошибочность суждений AlexPu. Мне интересен другой фундаментальный вопрос, который я задал в своем первом вопросе, т.к. прочитав все ответы к текущему моменту, я так и не понял, как находясь в текущем моменте, можно ставить на технологию, которая находится при первом же ознакомлении, в состоянии зародыша. Вы, усомнились в самом факте того, что г-ну AlexPu, удалось снять сливки, т.е. подвергаете сомнению всю историю г-на AlexPu, из-за которой собственно и появилось дело. Со своей стороны отмечу, что я не подвергаю сомнению его историю и верю, что ему действительно удалось сделать все то, о чем он нам, кстати любезно, рассказал. И на основании этой веры, мне и хотелось бы услышать какие-то более развернутые контекстные ответы. Но я полагаю, что холивар «обвинения vs защита», который во всю бушует выше, даже не дал г-ну AlexPu спуститься ниже, чтобы прочесть чуточку более :) Но я еще надеюсь привлечь внимание!taujavarob
04.08.2016 16:34OksikOneC > прочитав все ответы к текущему моменту, я так и не понял, как находясь в текущем моменте, можно ставить на технологию, которая находится при первом же ознакомлении, в состоянии зародыша.
AlexPu уже ответил выше. Кратко: Он запрыгивает в поезд не на стадии зародыша, а на стадии когда поезд начинает уверенно набирать скорость.
Да, он всегда немного запаздывает — но он не играет в рулетку и он не Оракул.
Но, обычно(!) ему хватает того, что он не первый и не третий и даже не в десятке первых — но и не в последней тысячи.
Почему обычно? — потому что он также участвует в стартапах — то есть всё же у него есть желание оказаться в тройке призёров.
Имхо, конечно, имхо.AlexPu
04.08.2016 16:44>>AlexPu уже ответил выше. Кратко: Он запрыгивает в поезд не на стадии зародыша, а на стадии когда поезд начинает уверенно набирать скорость
Вы очень правильно меня поняли в данном вопросе, и очень точно изложили свое понимание
>> он также участвует в стартапах — то есть всё же у него есть желание оказаться в тройке призёров.
Здесь не совсем верно — меня приглашают в стартапы либо с самого начала, когда я определяю технологический стек (и тогда мои действия в этом направлении диктуются в основном соображениями минимизации рисков), либо когда уже определенный технологический стек соответствует (пусть не на 100%) моей квалификации…
В любом случае я работаю не за бесплатно даже в стартапах… ну как правило (был один стартап с которог я получал 250 евро в мес, но там я просто хотел помочь одному хорошему знакомому — до момент пока его стартап не получи первичного финансирования, и он не сможет нанят разработчиков фуллтайм). Вообще представления о том, что в стартапах работают чуть ли не за даром несколько преувеличены — как только стартап получает первичное финансирование из внешних источников, зарплаты наемных служащих становятся вполне конкурентными
AlexPu
04.08.2016 16:36Прошу прощени, но сейчас я уже не в состоянии уделять много времени на написание комментариев — срочно понадобилось поработать ради денег… потроллил бы еще тех кто косит под творцов-художников, но увы…
Так что коротенько:
>> как находясь в текущем моменте вы так удачно предсказывали выстрелы
Далеко не все мои предсказания выстрелов были удачными. В общем-то неудачных было наверное больше. Просто я в какой-то момент (в момент прохождения службы в одной из «горячих» точек) стал относиться ко всему предельно прагматично…
>> дельфи уже показалось проигрышной
Да — перспективные потенциальные работодатели отказывались иметь дело с дельфи. Были согласны на C++ (в.ч. в исполнении Борланд) и почему-то java
>>находясь в 98-ом, что вы понимали под распределенными системами? Чем это было тогда?
Под распределенными информационными системами тогда понимали архитектуру клиент-сервер — сообщество моих коллег тогда пришло к выводу, что клиент-сервер это круто, работодатели тоже так решили, что было намного важнее — разработчикам которые были готовы разрабатывать ИС на основе клиент-серверной технологии зарабатывали ощутибо больше, чем их коллеги, которые по разным причинам оставались вергы всяким Clipper, Paradox и иже с ними (сейчас может кому-то показаться странным, но целые банковские системы на клипере писались). В основном работали с двухзвенной архитектурой, но и идея многозвенной архитектуры уже дозрела — просто не было толковых инструментов — delphi правда предлагал на сей счет кое что, но уж больно мутно там все было… java как раз и предложил кое что полезное… ИДЕЮ ejb и вполне работоспособную реализацию servlet (имевшую к тому-же явные преимущества по сравнению с тогдашними реализациями CGI). Мой первый проект на java был как раз web-прложением (трехзвенная архитектура, как тогда говорили) на основе Servlet (без каких либо фреймворков… собственно мы сами писали эти фреймворки — темплейтный длижок, ORM меппиг… и… получилось на удивление толково). А следующий проект уже вовсю использовал EJB, которые я на тот момент воспринял просто как ORM фреймворк, только круче, чем тот, который я писал сам (только термина ORM тогда не было)
>>Первый коммерческий проект я сворганил на аплетах JSP
Ну я вообще не воспринял апплеты как перспективную технологию… Рынок этого не принял практически сразу… Со всякими флешами было сложнее… какое-то время Flash был на взлете, но я просто решил сосредоточиться на серверных технологиях
>>JSP и swing
JSP я никогда не воспринимал как нечто особое, нуждающееся в изучении, а swing… ну как я сказал, я решил сосредоточиться на серверных технологиях… в том числе и потому, что посчитал, что в текущей реализации java не годится для разработки клиентских приложений… Нет, у меня были надежда на то, что это как-то изменится но… сразу было видно, что за это толком платить не будут (отдельные исключения — не в счет)
>> в рунете заказов не было на эти технологии, в забугорье — заказы были, но на уровне — несколько ином для моих скилов
Я чистым фрилансом никогда не интересовался… Да, я работал (и сейчас работаю) контрактором, но это емного не то… Так что я ориентировался всегда не на фрилансерские заказы, а на требования работодателей… Причем не только зарубежных, но и российских, в бытность мою в РФ — значительная часть российских разраюотчиков работали и работают на аутсорсе, то-есть работают со технологическим стеком востребованого зарубежными клиентами.
Сейчас все эти тенденции отслеживать намного проще чем в начале двухтысячных — habrahabr это яркий пример отличного источника инвормации, позволяющей держать нос по ветру
deniskreshikhin
В точку!
Дядя Боб как всегда на высоте)
kemiisto
Дядя Боб как всегда в своём репертуаре: бла-бла-бла. Два раза перечитал, даже по оригиналу пробежался. Ну упомянуто пару тривиальных вещей (про немёртвый ООП, например), но к чему это всё я так и не понял. «Нам нужно выбрать язык, или два, или три.» Каким же образом, он собирается это сделать? Сказать то каждый может, а хочеться что-то большое увидеть от «гуру» или «Стратегический план в разработке»? «Небольшой набор простых фреймворков.» Так с этим дело тоже как-то не пошло… То ли языки не те, то ли в принципе невозможно? И тут тоже было бы интересно послушать хоть какие-то рассуждения, а не про «отвёртки». Но, «Дядя Боб как всегда на высоте)», чего уж там…
deniskreshikhin
Да в том и отличие настоящих профессионалов типа Дяди Боба, они никогда тебе не скажут конкретно что и как делать. Потому что если тебе кто-то говорит — пойди и сделай так как я тебе говорю, то это значит кто-то хочет тобой воспользоваться.
kemiisto
Какое у Вас интересное определение «настоящих профессионалов»… Но давайте поконкретнее. Возьмём призыв «Нам нужно выбрать язык, или два, или три.» Обращён он, очевидно, к программистскому сообществу. Вот как Вы себе это представляете в реальности? Ну послушали «настоящего профессионала», а дальше то что? Как конкретно Вы предлагает сообществу искать консенсус по этому языку, который нужно выбрать? Каковы критерии? Или Вы может даже сразу язык назовёте?
Temirkhan
Проще делить по сферам применения.
kemiisto
Что-то я про сферы применения у «настоящего профессионала» в тексте ничего не вижу. Да и 1-2-3 языка в каждой конкретной сфере применения — это настоящее, так что, думаю, там подразумевалось 1-2-3 языка вообще, а не в каждой сфере. Вы поймите, я ведь не против такого сценария, даже очень «за». Просто хотелось увидеть рассуждения о том, в чём автор видит преимущества такой унификации и что конкретно он хотел бы иметь в итоге (язык с какими свойствами) и как это можно сделать. Вот это было бы действительно интересно почитать и обсудить.
deniskreshikhin
Критерии вы должны выработать сами. Главное что бы это не были критерии из «маслобойки».
Другими словами, что бы сказать что язык X хорошо для задачи Y, должно пройти 2-3 года.
У меня самого были такие наваждения когда я думал, да черт возьми дайка я возьму YetAnotherModernLanguage, сколько уже можно тратить драгоценное время на устаревшие языки. Но разочарование приходит довольно быстро. Поэтому теперь я стал принюхиваться к языкам годами, снача использую в прототипах, потом пишу что-неть простое, но интересненькое. И уже на 2-3 год я смелу говорю, заказчику или работодателю, ребята давайте переходить. Ну или наоборот отговариваю от перехода на язык или технологию которая себе не оправдала.
Проблема в том, что никто не пишет из авторов современных технологий, будьте аккуратно, не спешите с нашим языком, может это совсем не для вас. Наоброт все стараются напустить тумана. Подтолкнуть к необдуманным решениям.
Пример из жизни, как то я разговаривал с одной командой, и они начали переписывать проект на Node.js будучи уверенным что он идеально подходит для распараллеливания задач. Каково же было их удивление, когда они узнали что асинхронный код это не то же самое что параллельное выполнение, т.к. все испольняется в одном потоке (или нужно создавать отдельные процессы). А все дело в том что авторы Node.js активно пиарили его как именно язык для параллельного исполнения задач (они называли это кластерным исполнением или чем-то таким).
Т.е. в этом Дядя Боб прав, языки нужно менять очень аккуратно. Если вас категорический не устраивает ваш текующий язык, ищите ему замену постепенно. Пусть он будет вторым или третьим языком. Но никак не основным, для этого должны пройти годы.
kemiisto
Хммм… Вы поняли текст совсем иначе: как призыв к каждому индивиду ограничиться парой языков и небольшой кучкой библиотек, и не вестись на «маркетинговый булшит». Это здравый смысл, конечно, но у меня стойкое ощущение, что в тексте речь совсем не об этом. Речь о том, что вся отрасль в целом должна остановиться на паре языков и нарабатывать на их основе библиотеки и инструменты. И этот тезис, к сожалению, лишь озвучен, но не раскрыт…