Comments 326
UFO just landed and posted this here
Дядя Боб как всегда в своём репертуаре: бла-бла-бла. Два раза перечитал, даже по оригиналу пробежался. Ну упомянуто пару тривиальных вещей (про немёртвый ООП, например), но к чему это всё я так и не понял. «Нам нужно выбрать язык, или два, или три.» Каким же образом, он собирается это сделать? Сказать то каждый может, а хочеться что-то большое увидеть от «гуру» или «Стратегический план в разработке»? «Небольшой набор простых фреймворков.» Так с этим дело тоже как-то не пошло… То ли языки не те, то ли в принципе невозможно? И тут тоже было бы интересно послушать хоть какие-то рассуждения, а не про «отвёртки». Но, «Дядя Боб как всегда на высоте)», чего уж там…
UFO just landed and posted this here
Какое у Вас интересное определение «настоящих профессионалов»… Но давайте поконкретнее. Возьмём призыв «Нам нужно выбрать язык, или два, или три.» Обращён он, очевидно, к программистскому сообществу. Вот как Вы себе это представляете в реальности? Ну послушали «настоящего профессионала», а дальше то что? Как конкретно Вы предлагает сообществу искать консенсус по этому языку, который нужно выбрать? Каковы критерии? Или Вы может даже сразу язык назовёте?
UFO just landed and posted this here
Что-то я про сферы применения у «настоящего профессионала» в тексте ничего не вижу. Да и 1-2-3 языка в каждой конкретной сфере применения — это настоящее, так что, думаю, там подразумевалось 1-2-3 языка вообще, а не в каждой сфере. Вы поймите, я ведь не против такого сценария, даже очень «за». Просто хотелось увидеть рассуждения о том, в чём автор видит преимущества такой унификации и что конкретно он хотел бы иметь в итоге (язык с какими свойствами) и как это можно сделать. Вот это было бы действительно интересно почитать и обсудить.
UFO just landed and posted this here
Хммм… Вы поняли текст совсем иначе: как призыв к каждому индивиду ограничиться парой языков и небольшой кучкой библиотек, и не вестись на «маркетинговый булшит». Это здравый смысл, конечно, но у меня стойкое ощущение, что в тексте речь совсем не об этом. Речь о том, что вся отрасль в целом должна остановиться на паре языков и нарабатывать на их основе библиотеки и инструменты. И этот тезис, к сожалению, лишь озвучен, но не раскрыт…
ката бы хватило
Все верно.
Подписался бы под каждым словом, кроме последнего. Не мы выбираем новые фреймворки, и не мы клюем как сороки на блестящее (по крайней мере, далеко не всегда мы). Заказчики клюют, маркетологи прикармливают и т.д… Не получается безоблачно радоваться Eclipse с Java, если, грубо говоря, очередной клиент тебе доказывает, что ему нужно непременно на NodeJS, т.к. это тренд. А прогнать клиента… ну тоже не вариант.
50\50. Если разработка идет под ключ, команда сама решает, какие инструменты использовать. Если компания сама владеет разработкой продукта, она сама решает, какие инструменты использовать. Если команда\компания делает заказ на аутсорсе, она сама навязывает, (или выбирает из исполнителей), какие инструменты они будут использовать. А вот если вы сами аутсорс, и присоединяетесь к чужой разработке, тогда да :).
Статья немного провокационная… Бывает по разному, переключаться между технологиями вполне допустимо, если от этого есть практическая выгода. А прыгать между примерно одинаковыми вариантами — это уже непрофессионально.
В Вашем же примере речь скорее не о переключении, а об изначальном выборе технологий для проекта. И тут уже Ваша задача как профессионала обосновать свой выбор заказчику, если для его проекта Java идеально подходит.
В Вашем же примере речь скорее не о переключении, а об изначальном выборе технологий для проекта. И тут уже Ваша задача как профессионала обосновать свой выбор заказчику, если для его проекта Java идеально подходит.
Я бы сказал, тут и то, и другое. Не раз приходилось останавливать желание запилить проект (на который меня нанимают) на чём-то новом и блестящем без адекватного обоснование.
Сейчас вот опять думаю, есть ли адекватное обоснование новый небольшой проект сделать на Elixir/Phoenix вместо рельс, или это добавит клиенту геморроя больше, чем решит. Скорее всего, такого нет. Возможно, кто-нибудь когда-нибудь решит использовать это и наймёт, но пока нет.
А ещё я хотел попробовать перекатиться куда-нибудь в джавамир, но с учётом специфики этих проектов, это было бы как из пушки по воробьям, так что опять нет.
Сейчас вот опять думаю, есть ли адекватное обоснование новый небольшой проект сделать на Elixir/Phoenix вместо рельс, или это добавит клиенту геморроя больше, чем решит. Скорее всего, такого нет. Возможно, кто-нибудь когда-нибудь решит использовать это и наймёт, но пока нет.
А ещё я хотел попробовать перекатиться куда-нибудь в джавамир, но с учётом специфики этих проектов, это было бы как из пушки по воробьям, так что опять нет.
Ну я тут с ходу после ерланга взял эликсир. И… как-то на первых порах, типа помигать лампочкой, хелловорлд, там быстрее получается, но потом ударился головой об синтаксис. Шишка теперь )
C был существенно лучше, чем Fortran
У языков немного разное целевое назначение, Fortran все же больше про вычисления, а C про системное программирование. Так сравнивать нечестно, ибо… Что лучше, SQL или Python?
Мало ли, возможно 40 с лишним лет назад их области применения пересекались гораздо сильнее, чем сейчас.
А вот и зануды подтянулись… Человек не об этом вообще-то говорит.
«А на вопросы надо смотреть ширше...» (с)
«А на вопросы надо смотреть ширше...» (с)
Но при этом задачу вычислений C тоже решает.
А ещё на нем можно писать сайты и мобильные приложения. (стоит ли ?)
У языка есть специализация.
У языка есть специализация.
Да, но Фортран устарел даже в рамках своей собственной специализации.
Минусующие этот комментарий видимо никогда не видели программы на F77.
Но количество legacy на фортране (типа того же blas/lapack/arpack и тонны научных библиотек) приводит к тому, что его компиляторы живут и здравствуют (и в gcc, и в intel). Интересно, много ли народа реально используют их на фортране, а не из c/python?
много. если иметь в виду по назначению
для примера: один и тот же расчет на python ~15 мин, fortran 90 — 30 c
магия однако
+ таки да, куча легаси кода, который переписывать на другия языки зная что станет в N раз медленнее очень лениво (я даже не говорю про " а кто за это быдет платить"?)
для примера: один и тот же расчет на python ~15 мин, fortran 90 — 30 c
магия однако
+ таки да, куча легаси кода, который переписывать на другия языки зная что станет в N раз медленнее очень лениво (я даже не говорю про " а кто за это быдет платить"?)
Переписывать смысла нет. Но ведь язык живет пока на нем пишут — а не пока запускают программы, на нем написанные. Много вы знаете людей, которые при обсуждении нового проекта скажут: "а давайте сделаем его на Фортране"?
Что же до производительности расчетов — в этой ветке обсуждались Fortran и Си, а не Fortran и Python. То, что питон слабо подходит для чистых расчетов — не секрет. Но можете ли вы привести расчет, который будет выполняться на Си медленнее чем на Фортране?
Я полагаю, тормозить могут расчеты, в которых участвуют дробные числа совместно с целыми. Дело в том, что в C довольно неудачно принято, что дробное число округляется до наименьшего (по модулю) целого. При расчетах это очень неудобно. Рождаются функции типа int roundi(double x) { return (int) floor(x+0.5); }, но это костыли. Сначала прибавляем 0.5, потом округляем до меньшего целого, потом преобразуем double->int. Каждое округление сопровождается переключением режимов сопроцессора, что приводит к сильным тормозам. Вместо этого можно было бы решить задачу одной ассемблерной командой fistp без переключения режимов сопроцессора. Возможно, в новых компиляторах так и делается, но Visual C++ 2005 так не мог — мне пришлось делать ассемблерную версию roundi.
Функция round() в math.h появилась тоже совсем недавно.
Функция round() в math.h появилась тоже совсем недавно.
Такое соотношение с python'ом получается даже при использовании numpy, слинкованного с той же версией blas'а и предвыделением памяти? У меня получалась не столь значительная просадка производительности при том, что на Си использовался код с avx intrinsics и прилично векторизованный icc.
А ещё на нем можно писать сайты и мобильные приложения. (стоит ли ?)В статье Fortran -> C приведено для примера прогресса в начале 70-х годов, причём тут сайты и мобильные приложения?
Помнится, у меня был преподаватель, любимой фразой которого было «Maple — лучше чем C»…
Agile была лучше, чем водопад.
В этом месте текста многие сравнения притянуты за уши. Кстати, слово "была" очень намекает… )
В реальности все несколько проще и сложнее. C существенно лучше фортрана на некоторых задачах. Но вовсе не на тех, для которых фортран был изначально предназначен, просто его за неимением лучшего применяли и для таких тоже.
Agile может быть лучше водопада — если у вас проект определенного типа. Но на некоторых типах, и для некоторых команд это было и будет ужасно.
Нету ничего в фортране (по крайней мере — в том фортране который делал Бэкус) ничего особо ориентированного на числодробилки. Просто там наработано много кода для научных расчётов, ну и (и это зависело от п.1) со временем, насколько я знаю, более-менее появились векторные операции. Плюс бедная семантика фортрана позволила в своё время придумать достаточно эффективные техники оптимизации при компиляции. Собственно, всё.
Беда случилась, когда разработчики языков и фреймворков начали использовать методы рекламщиков на программистах. Мы все подвержены влиянию рекламы в том или ином виде. В итоге выходит, что мы выбираем из различных buzzwords, а не оцениваем по реальным параметрам.
Однажды я принял неверное решение: использовать NoSQL базу там, где неплохо подходила и классическая реляционная. В момент принятия решения мне казалось, что всё прекрасно, замечательно и сценарии использования подходят идеально. Спустя два года, я понял, что черпал информацию скорее из «рекламных» статей о технологии, чем из реальных источников. Потребовалось полгода, чтобы заменить базу на PostgreSQL, но в итоге это дало мощный толчок развитию проекта из-за возможностей, которые за десяток лет уже были реализованы другими, а, кроме того, снизило загрузку серверов почти в 3 раза.
Теперь я намного осторожнее выбираю технологии и предпочитаю те, что проверены временем и невероятным числом сценариев использования. У меня порой возникает желание встроить в проект модули на Rust или Go вместо C++. Но пока то, что пишут об этих языках, слишком напоминает маркетинговые материалы.
Однажды я принял неверное решение: использовать NoSQL базу там, где неплохо подходила и классическая реляционная. В момент принятия решения мне казалось, что всё прекрасно, замечательно и сценарии использования подходят идеально. Спустя два года, я понял, что черпал информацию скорее из «рекламных» статей о технологии, чем из реальных источников. Потребовалось полгода, чтобы заменить базу на PostgreSQL, но в итоге это дало мощный толчок развитию проекта из-за возможностей, которые за десяток лет уже были реализованы другими, а, кроме того, снизило загрузку серверов почти в 3 раза.
Теперь я намного осторожнее выбираю технологии и предпочитаю те, что проверены временем и невероятным числом сценариев использования. У меня порой возникает желание встроить в проект модули на Rust или Go вместо C++. Но пока то, что пишут об этих языках, слишком напоминает маркетинговые материалы.
UFO just landed and posted this here
> Ты когда-нибудь использовал IntelliJ или Eclipse для программирования на Java?
я пробовал использовать Eclipse для программирования, несколько раз, фактически, каждый раз я надеялся, что «его улучшили, мой компьютер стал в 10 раз мощнее чем в прошлый раз, и мне не придется ждать несколько секунд, при переводе строки». В общем ни разу мои надежды не оправдались.
я пробовал использовать Eclipse для программирования, несколько раз, фактически, каждый раз я надеялся, что «его улучшили, мой компьютер стал в 10 раз мощнее чем в прошлый раз, и мне не придется ждать несколько секунд, при переводе строки». В общем ни разу мои надежды не оправдались.
Да, у IDE на Java всегда были приличные требования к железу.
Я подумывал заменить пример на Visual Studio для C#, но всё-таки решил оставить как в оригинале.
Я подумывал заменить пример на Visual Studio для C#, но всё-таки решил оставить как в оригинале.
я два раза перечитал.
Кхм… Eclipse конечно канонический пример «не быстрой» IDE… но ведь Visual Studio-то ничуть не лучше на среднем/слабом железе!..
Ну и насчет IDEA — вот она и на среднем железе не относится к «не быстрой» (хотя согласен, ей нужно иногда дать время на сбор и обновление индексов)… Единственное но — они любят память. Если у тебя меньше 4х Гб оперативки — лучше не запускать. Ведь 1.5 гига съест система, гиг браузер, гиг IDE и начнётся своппинг…
Ну и в цитате не про скорость работы а про мощность инструмента (за которую приходится платить)…
Ну и насчет IDEA — вот она и на среднем железе не относится к «не быстрой» (хотя согласен, ей нужно иногда дать время на сбор и обновление индексов)… Единственное но — они любят память. Если у тебя меньше 4х Гб оперативки — лучше не запускать. Ведь 1.5 гига съест система, гиг браузер, гиг IDE и начнётся своппинг…
Ну и в цитате не про скорость работы а про мощность инструмента (за которую приходится платить)…
У меня Eclipse — основной рабочий инструмент, правда, для C/C++. Тормоза замечал с OpenJDK, с версией оракла проблем не замечал. Правда, мои рабочие машины призваны запускать Unreal Engine, возможно, дело в этом…
У меня комп 5 летней давности, и никаких тормозов при переводе строки я не замечал.
«мой компьютер стал в 10 раз мощнее» — что это за бред, когда тебя разморозили.
«мой компьютер стал в 10 раз мощнее» — что это за бред, когда тебя разморозили.
SSD, вам в помощь, у меня на слабом ноуте, все хорошо работает. Вы еще на javascript — e не писали, там ресурсов в разы больше расходуется!
я на js и пишу, атом в разы быстрее работает чем Eclipse, разница примерно как у атома и vim. В последний раз я проверял ее ещё до бума ssd, сейчас есть ssd, думаете стоит проверить? Вообще в тот раз как и во все предыдущие, эклипс безбожно утекал, т.е. запустить и начать что-то делать было ок, а вот делать целый день было невозможно.
Есть подозрение, что atom — редактор файлов, а не IDE.
для js eclipse тоже редактор файлов :) только медленный очень.
Ну и вообще неважно, если в IDE тормозит редактор, то оно уже не integrated development environment а «та штука которую я юзаю при крайней необходимости». Мало ли что оно мне позволяет, только если рефакторинг :%s// или perl -pi -e работает несколько быстрее, то такая IDE ненужна. (ну и опять же, ничего больше того редактора оно не может, ни из коробки ни с плагинами)
Забавно, что за 5 лет работы с Eclipse я такого не наблюдал, но зато продукты от JetBrains частенько подвисают.
У меня ситуация обратная, и путь eclipse -> netbeans -> idea прошел более-менее мягко. Полностью от приложений на eclipse rcp, конечно, избавиться сложно: тот же apache directory studio полезен и относительно удобоварим, но в смысле разработки меня устраивают другие IDE. Например, для Си для контроллеров c eclipse cdt я ушел в qtcreator, т. к. тормоза при вводе в эклипсе затмевают всё.
Извините… Я не понял…
Вокруг каждого языка программирования формируется группа людей, считающих разработку и развитие новых языков потерей времени. Это называется не просто невежество, а воинствующее невежество.
Они отличаются, но они не лучше, по крайней мере не настолько лучше, чтобы оправдать возвращение набора инструментов обратно в каменный век.
Каждый стоящий новый язык тянет за собой новую парадигму. Если язык не заставляет вас мыслить иначе, значет его незачем изучать.
А все эти росказни про то, что утилиты обратно в каменный век, и что всё переписывать надо — это всё от лукавого. Инструменты должны изначально писаться не под конкретный язык, выделять свои функционально независимые блоки в отдельные взаимозаменяемые модули. Это вопрос развития экосистемы утилит и сред программирования, там ещё поле не пахано (посмотрите на тот же Light Table).
Речь не об этом. Кто сказал, что новая парадигма обязана заменить предшествующую?
Многие парадигмы могут существовать параллельно и не всегда смена языка стоит того.
Почему шейдеры (хорошие шейдеры) все ещё пишут на ассемблере? Почему не написать их на python или ruby?
Многие парадигмы могут существовать параллельно и не всегда смена языка стоит того.
Почему шейдеры (хорошие шейдеры) все ещё пишут на ассемблере? Почему не написать их на python или ruby?
Кто конкретно пишет на ассемблере? Я таких людей не знаю. Напротив, шейдеростроение потихоньку поднимает уровень используемых языков. Так, за сегодняшними HLSL и GLSL с их С-ишным синтаксивом мы видим новый Metal с шейдерами на упрощённом С++. Иронично (к вашему последнему вопросу), общая тенденция идёт к тому, чтобы писать шейдеры на том же языке, то и игру.
Почему шейдеры (хорошие шейдеры) все ещё пишут на ассемблере?Впервые слышу. Но все же, объясните почему? Я нагуглил только то, что он быстрей компилируется и безнадежно устарел.
Почему не написать их на python или ruby?На то есть много причин, но все они относятся скорее к реализации, чем к парадигмам или синтаксису этих языков.
Почему шейдеры (хорошие шейдеры) все ещё пишут на ассемблере?
Серьёзно? Уже давно не видел таких шейдеров в основно все шейдеры пишутся в процедурном стиле с С подобным синтаксисом. А HLSL с 5 версии вообще добавил ООП в шейдеры, так что это миф.
Каждый стоящий новый язык тянет за собой новую парадигму.А можно парочку примеров?
Инструменты должны изначально писаться не под конкретный язык, выделять свои функционально независимые блоки в отдельные взаимозаменяемые модулиЭто да. Но поддержку нового языка всё равно надо будет дописать, при этом не факт, что язык позволит использовать возможности такой IDE в полной мере.
В целом я согласен, что развитие инструментов должно продолжаться и там до асимптоты ещё далеко.
А можно парочку примеров?
- Go — параллельное программирование на легковесных потоках
- Rust — безопасная работа с памятью без сборщика мусора
- Idris — зависимые типы
Но ведь корутины придумали по-моему в 1960ых, а зависимые типы чуть ли не в 1930ых. Что мешает использовать, например, те же корутины в Ruby?
Электромобили были ещё в 19-ом веке. Планшетов и карманных ПК тоже было немало до появления iPod и iPhone.
Что мешает использовать, например, те же корутины в Ruby?
Не знаю. В С++ точно ничего не мешает. Одно дело — поддерживать фичу, а другое — плясать вокруг неё при дизайне языка и его стандартной библиотеки.
То, что в Ruby интерпретатор абсолютно под них не заточен и гемора будет больше, чем профита?
«параллельного программирования на легковесных потоках» было как грязи до появления Go, впрочем, и всё остальное тоже.
Из трёх перечисленных я хорошо знаком только с Go. Но в Go скорее идёт компоновка старых и очень старых идей, чего-то реально нового там не видно.
Есть даже книжка «Communicating Sequential Processes. The First 25 Years» с материалами симпозиума от 2004 года.
В Rust, насколько я понимаю, из коробки реализована модель умных указателей. Но самим умным указателям тоже сто лет в обед.
По поводу зависимых типов, Idris — далеко не первый ЯП, в котором они используются. А тому же Coq уже больше 30 лет.
P.S. С другой стороны, если рассматривать отдельно взятого программиста, то Вы правы, тут идёт прогресс в мышлении по мере ознакомления с разными парадигмами и подходами. Но в рамках индустрии новых идей очень мало.
Есть даже книжка «Communicating Sequential Processes. The First 25 Years» с материалами симпозиума от 2004 года.
В Rust, насколько я понимаю, из коробки реализована модель умных указателей. Но самим умным указателям тоже сто лет в обед.
По поводу зависимых типов, Idris — далеко не первый ЯП, в котором они используются. А тому же Coq уже больше 30 лет.
P.S. С другой стороны, если рассматривать отдельно взятого программиста, то Вы правы, тут идёт прогресс в мышлении по мере ознакомления с разными парадигмами и подходами. Но в рамках индустрии новых идей очень мало.
> Каждый стоящий новый язык тянет за собой новую парадигму
Если это критерий «стоящности» языка, то их тогда вполне можно сократить до полутора десятков. Новых парадигм в программировании немного, и появляются они крайне нечасто.
Если это критерий «стоящности» языка, то их тогда вполне можно сократить до полутора десятков. Новых парадигм в программировании немного, и появляются они крайне нечасто.
Парадигма — это способ мышления. Они продолжают развиваться и сегодня, как видно из примеров выше. Более того, современные инфраструктуры компиляторов (как LLVM) позволяют новым идеям воплощаться в жизнь как нельзя быстрее и легче. Новые языки появляются чуть ли не каждую неделю. В следующем году, как прогнозируют синоптики, что прирост языков удвоится ;)
Слушайте астрологов. Они прогнозируют удвоение прироста с точностью до недели.
Извините за дотошность, но
парадигма — это совокупность фундаментальных научных установок, представлений и терминов, принимаемая и разделяемая научным сообществом и объединяющая большинство его членов. Обеспечивает преемственность развития науки и научного творчества.(вики))) ).
Это несколько отличается от вашего виденья, что это способ мышления. Если кто то предлагает бред, который невозможно использовать массово, поддерживать сообществом (естественно специалистов в области), то это не парадигма. Вот ООП, это действительно скачек, подавляющее большинство специалистов перестроили свое мышление и стали использовать. Функциональное тоже. Связки их сильных сторон, помогает делать удивительные вещи быстро, читабельно, и с приемлемой скоростью выполнения.
парадигма — это совокупность фундаментальных научных установок, представлений и терминов, принимаемая и разделяемая научным сообществом и объединяющая большинство его членов. Обеспечивает преемственность развития науки и научного творчества.(вики))) ).
Это несколько отличается от вашего виденья, что это способ мышления. Если кто то предлагает бред, который невозможно использовать массово, поддерживать сообществом (естественно специалистов в области), то это не парадигма. Вот ООП, это действительно скачек, подавляющее большинство специалистов перестроили свое мышление и стали использовать. Функциональное тоже. Связки их сильных сторон, помогает делать удивительные вещи быстро, читабельно, и с приемлемой скоростью выполнения.
В смотрите определение не в том контексте. Наука != программирование (в целом). Вот другое, из той же вики:
Паради́гма программи́рования — это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером[1].
Иногда это оправдано. Я учил всё как-то так: php -> js -> golang -> учу C/C++ и как по мне то это довольно правильный путь. Я с самого «высокого» уровня по немного перешел к ручному управлению памятью
Но ведь… Rust такой классный...
А разве ООП и микро-сервисы это две взаимоисключающие парадигмы?
Согласен со всем, что написано.
Иногда меня охватывает странное чувство: у нас современные языки, куча фреймворков и библиотек, которые призваны облегчать нам жизнь. И вроде бы они облегчают, и не нужно реализовывать то, что уже давно сделано умными людьми. И тем не менее, очень часто я чувствую, что параллельно с облегчением жизни все это ее усложняет: тратишь кучу времени на изучение, ищешь best practies, какой подход должен быть в каждом конкретном случае (а каждый крупный фреймворк навязывает свой подход) и т.д. и т.п. Иногда мне кажется, что приходиться бороться с инструментами, которые должны нам помогать.
Прогресс в области программного обеспечения следует логарифмической кривой роста.… Асимптота?! Думаешь, есть верхний предел технологий разработки программного обеспечения?У логарифмической кривой нет горизонтальной асимптоты. Дядя Боб, наверное, имел в виду экспоненциальную кривую.
UFO just landed and posted this here
Хорошее замечание. На мой взгляд, тут скорее математически неправильная трактовка понятия асимптота. Всё-таки появление нового оборудования, типа квантовых компьютеров, может принести что-то новое и в программирование, но процесс идёт крайне медленно…
Хотя на деле скорее логистическая.
UFO just landed and posted this here
А могли бы просто с 1998 писать на Java — количество вакансий по-моему только растёт, спасибо Android. Чисто ИМХО, 20летний опыт принесет больше профита, чем прыжки с технологии на технологию в надежде урвать кусок пока нет конкурентов.
UFO just landed and posted this here
В качестве примера — моя сегодняшняя работа (работаю уже 2 недели) была получена благодаря двум волшебным словам — «микросервисы» и «докер» (с наглядной демонстрацией своих скилзов в этой области) — задача перевести существующее монолитное приложение на архитектуру микросервисов. Деплоймент на AWS (собственно он и сейчас там)… 700 евро плюс (в смысле это повышение моей зарплаты по сравнению с предыдущем местом работы)…
Вот приходили ко мне люди, знающие «волшебные слова», а когда я их просил написать разворот списка — сливались. Изучить такие вещи на базовом уровне (чтобы показать скилы на интервью) опытный разработчик способен за пару недель, ну месяц в крайнем случае. Тем более, что в том же docker нет ничего принципиально нового для человека, который имел дело с OpenVZ пару лет в продакшене. А вот что действительно нужно — фундаментальные знания, светлая голова и прямые руки — никак не зависит от новых парадигм и shiny new things.
Полностью согласен с подходом.
Спасибо за подробный рассказ. По-моему у Вас вполне здравая позиция и выбор технологий по конкретным критериям. Только к чему переживать об упущенных поездах, на двух одновременно ехать всё равно не удобно. По-любому какой-то один будет основным.
UFO just landed and posted this here
UFO just landed and posted this here
Если Вы JavaScript для client-side используете, а Java — для backend, то это всё-таки 1 поезд, просто с двумя вагонами, можно ещё 3-й вагон SQL прицепить )
А вот если и то и то для backend, то интересно было бы послушать каким образом Вы это совмещаете.
А вот если и то и то для backend, то интересно было бы послушать каким образом Вы это совмещаете.
UFO just landed and posted this here
А что сложного совмещать? Другое дело есть ли в этом смысл для конкретного проекта.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Если не знает и не хочет знать, то просто переписывает микросервис на известном ему языке, который лучше подходит для задачи.
UFO just landed and posted this here
Ха-ха. Говорю это как человек, к которому в итоге этот сервис на сопровождение попадет.
> современные тенденции разработки… Грубо говоря (ну очень грубо) — те-же 20 человек и будут сопровождать сервис
Есть и такая «тенденция». Но это как раз пример «worst practices» — грубейшей управленческой ошибки при ведении проекта. Если проект не монолитный, а раздроблен между массой подрядчиков, и нет генерального, который является единственной точкой ответственности перед заказчиком, и нет единого стека технологий, то… куратор данного Франкенштейна должен как минимум застрелиться.
Есть и такая «тенденция». Но это как раз пример «worst practices» — грубейшей управленческой ошибки при ведении проекта. Если проект не монолитный, а раздроблен между массой подрядчиков, и нет генерального, который является единственной точкой ответственности перед заказчиком, и нет единого стека технологий, то… куратор данного Франкенштейна должен как минимум застрелиться.
UFO just landed and posted this here
UFO just landed and posted this here
У альтернативной энергетики основная проблема — отсутствие предсказуемой выработки энергии и большая неравномерность выработки, что приводит к необходимости запасать эту энергию до момента повышенного потребления, что начинает стоить совсем других денег чем обещают. Это может быть приемлемо для индивидуальных домохозяйств, но не для промышленных потребителей. Не говоря уже о том, что лития на такое количество батарей на планете просто не хватит.
Понимаете, с одной стороны, я тоже люблю деньги, и зарабатывать их мне очень-очень приятно. С другой стороны, если я вижу, что технология, которую впарили клиенту, решает его проблемы неэффективно, и с большой переплатой, я постараюсь его переубедить. Ну просто потому, что у меня есть ещё какая-то профессиональная совесть, и я хочу разрабатывать софт для того, чтобы он решал задачи, и именно за это получать деньги, а не просто максимально доить своих клиентов любым доступным способом.
UFO just landed and posted this here
Впаривать дорогую технологию прекрасно понимая, что для заказчика это не лучший выбор попахивает не то, что сделками с совестью, а мошенничеством.
UFO just landed and posted this here
А вы каким-то образом уже успели оценить стоимость технологий, которые я «впариваю»? молодца! Вам нужно в битву экстрасенсов…
Но ведь это довольно быстрый и выгодный путь к обогащению? — А когда нет «тормозов» — то почему бы и нет?
UFO just landed and posted this here
ЭТО — это что?
Это — это «впаривание».
«тормоза» — это что?
Это что-то что не даёт «впаривать».
UFO just landed and posted this here
AlexPu > понятно…
Варианты:
— Работаю потому что интересно — но мне ещё за это и платят!
— Работаю потому что интересно — но мне мало за это платят.
— Работаю потому что интересно и нужно людям — платят немного.
— Работаю потому что не желаю выходить из «зоны комфорта», да и денег хватает.
— Работаю потому что не желаю выходить из «зоны комфорта», но вот только платят мало.
— Работаю потому что только и только хочу много заработать — сменил немало мест.
— Хочу при жизни узнать, попаду я в рай или нет? (ну, а то что стану миллиардером и обеспечу семью — это вторично), — (Эти люди двигают прогресс).
Каждый выбирает сам, но тут иное — если при этом у всех дорога совпадает — то есть что-то что их объединяет — то что можно «определить заранее» — и, в вашем случае, не вспрыгивать на подножку набирающего ход поезда, а заранее занять место в купе, да что в купе — в спальном вагоне, даже в ресторане!
Представляете, вы в 2016 году знаете что «выстрелит» через пару лет? Что из «гадкого утёнка» взлетит!
Варианты:
— Работаю потому что интересно — но мне ещё за это и платят!
— Работаю потому что интересно — но мне мало за это платят.
— Работаю потому что интересно и нужно людям — платят немного.
— Работаю потому что не желаю выходить из «зоны комфорта», да и денег хватает.
— Работаю потому что не желаю выходить из «зоны комфорта», но вот только платят мало.
— Работаю потому что только и только хочу много заработать — сменил немало мест.
— Хочу при жизни узнать, попаду я в рай или нет? (ну, а то что стану миллиардером и обеспечу семью — это вторично), — (Эти люди двигают прогресс).
Каждый выбирает сам, но тут иное — если при этом у всех дорога совпадает — то есть что-то что их объединяет — то что можно «определить заранее» — и, в вашем случае, не вспрыгивать на подножку набирающего ход поезда, а заранее занять место в купе, да что в купе — в спальном вагоне, даже в ресторане!
Представляете, вы в 2016 году знаете что «выстрелит» через пару лет? Что из «гадкого утёнка» взлетит!
Ну да, я в том числе подразумевал вопрос: что такого может дать Node.js чего не может дать Java?
UFO just landed and posted this here
Быстрее на нём разработка происходит, вот и всё. Это в некоторых случаях перекрывает все его минусы.
У нас часть сервисов на Java, часть на Node.js Вполне довольны и тем, и тем.
Мне очень нравится Java, но на node.js прототипировать быстрее. Так что, если есть время, то пишу на Java, если нужно побыстрее сделать работающий сервис, то node.js (несмотря на все его минусы).
Мне очень нравится Java, но на node.js прототипировать быстрее. Так что, если есть время, то пишу на Java, если нужно побыстрее сделать работающий сервис, то node.js (несмотря на все его минусы).
Еще один интересный аспект при выборе технологий: как вы можете использовать их вместе и монетизировать это знание. Особенно это актуально для технарей-управленцев: тимлидов всяких, тех.директоров и архитекторов конечно. Зачастую выбор правильных технологий на старте проекта может сэкономить просто астрономические суммы.
Довольно ограниченный круг наших коллег способен прагматично смотреть на технологии, поэтому зачастую обоснование использования технологии А или В сводится к «А — это модно и круто, а B — это полный отстой». А вот выбрать правильные технологии, взвесить риски и представить план проекта в оцифрованном виде (читай в $) — это вообще уникальная компетенция.
Довольно ограниченный круг наших коллег способен прагматично смотреть на технологии, поэтому зачастую обоснование использования технологии А или В сводится к «А — это модно и круто, а B — это полный отстой». А вот выбрать правильные технологии, взвесить риски и представить план проекта в оцифрованном виде (читай в $) — это вообще уникальная компетенция.
А какой профит принес сознательный отказ от React.js? (реально интересны причины, ибо сам работаю и с тем, и как раз профит был в скором освоении React-а).
О, как раз изучаю эту тему сейчас. С React'ом не знаком. По началу отпугивала jsx-лапша. Сейчас посмотрел на Angular 2, понял, что никуда от лапши не деться.
- На сколько сложно переключаться между Angular и React?
- В свете того, что TypeScript объявил о поддержке React, а для Angular 2 TypeScript считается стандартом, моно ли сказать, что писать на TypeScript под Angular и ReactJs — хорошая идея или есть нюансы?
UFO just landed and posted this here
JSX-лапша (с которой гневно плевался, когда первый раз увидел) — это как наркотик :) Начинаешь любить эту лапшу один в один в такой вот ситуации — просто понимаешь, что в том или ином виде она есть везде, а тут это оказывается на удивление удобно и без лишних сюрпризов, она просто работает и все.
TypeScript — поскольку это надмножество JavaScript — по сути, писать на React с TypeScript можно уже давно. Сам предпочитаю Babel (ES6/7) + FlowType (иногда типизация — требование команды заказчика), но сути дела особо не меняет. Честно, в большинстве случаев на практике не ощущаю необходимости в типизации вообще, я не использую IDE с IntelliSense и иже с ними. Но одно можно сказать точно — надо осваивать, это будет востребованная/продаваемая тема, в том числе благодаря мощно продвигаемому Angular 2.
TypeScript — поскольку это надмножество JavaScript — по сути, писать на React с TypeScript можно уже давно. Сам предпочитаю Babel (ES6/7) + FlowType (иногда типизация — требование команды заказчика), но сути дела особо не меняет. Честно, в большинстве случаев на практике не ощущаю необходимости в типизации вообще, я не использую IDE с IntelliSense и иже с ними. Но одно можно сказать точно — надо осваивать, это будет востребованная/продаваемая тема, в том числе благодаря мощно продвигаемому Angular 2.
UFO just landed and posted this here
У меня ровно противоположный опыт :) Angular был крайне популярен на западе, сейчас очень много проектов по переводу AngularJS 1 приложений на React (иногда еще серверный пререндеринг из коробки играет не последнюю роль). Впрочем, Angular 2 тоже фигурирует, но пока очень мало.
То, что основной/предпочтительный обычно один — соглашусь. Однако, от себя добавлю, что чтобы быть крутым фронтендером — освоить нужно бы оба. Изучение React поменяло то, как я пишу на Angular в свое время.
То, что основной/предпочтительный обычно один — соглашусь. Однако, от себя добавлю, что чтобы быть крутым фронтендером — освоить нужно бы оба. Изучение React поменяло то, как я пишу на Angular в свое время.
Мне кажется у вас в голове только деньги (судя по следующим постам) и это до добра не доводит по определению. То, что семье нужны деньги, никто не сомневается, но счастье — не в них. Вот вообще от них никак не зависит. По опыту скажу, что люди, которые в голове крутят «деньги, деньги, деньги» делают свою работу не очень хорошо, зачастую — плохо. Пытаются взяться за вещи и влезть в места, где больше платят, не особо вдаваясь в детали, в итоге на выходе сырой продукт и, возможно, испорченные отношения.
Да и вообще, зачем вам программирование, идите и продавайте оружие, рабов и снимайте порнуху — там доход на порядки больше, чем рыться в тормозящих IDE, написанных на яве или решать умерло ли ООП.
Считаю, что первично — это желание работать, получать наслаждение от процесса, тогда и в «поезда» не надо будет запрыгивать, потому что вы будете хорошим спецом и за вашу голову сами будут охотиться (ну соответственно и деньги будут).
Не судите строго, но если не прав — пните меня. Удач!
Да и вообще, зачем вам программирование, идите и продавайте оружие, рабов и снимайте порнуху — там доход на порядки больше, чем рыться в тормозящих IDE, написанных на яве или решать умерло ли ООП.
Считаю, что первично — это желание работать, получать наслаждение от процесса, тогда и в «поезда» не надо будет запрыгивать, потому что вы будете хорошим спецом и за вашу голову сами будут охотиться (ну соответственно и деньги будут).
Не судите строго, но если не прав — пните меня. Удач!
UFO just landed and posted this here
Я не знаю, способны вы что-то решить или нет. И я не осуждал вас, как человека или семьянина. Мне просто не по душе такой подход к делу. А мир строится нами, и от нас многое зависит.
Моя мысль была в том, что художник, рисующий за деньги — не художник. Программист, создающий программы ради денег — не программист. Как человек, работающий с гос органами, сообщу, что если бы все не вертелось вокруг денег — жизнь была бы другой. А так — сплошные попилы, да поиск новых методов для присваивания денег.
Если ко мне приходит человек, в котором я заподозрю потребителя — его не стоит брать на работу. Потому что он банально уйдет к другим, стоит ему предложить чуть больше денег.
Любите деньги? Очень жаль, но приходится жить в таком мире, где это пропагандируется. В чем сила денег? Пример из вакуума — изнасиловали дочку, насильник откупился, заплатив полицейским, не прокатило — заплатил в прокуратуру. Вот она — сила денег.
Моя мысль была в том, что художник, рисующий за деньги — не художник. Программист, создающий программы ради денег — не программист. Как человек, работающий с гос органами, сообщу, что если бы все не вертелось вокруг денег — жизнь была бы другой. А так — сплошные попилы, да поиск новых методов для присваивания денег.
Если ко мне приходит человек, в котором я заподозрю потребителя — его не стоит брать на работу. Потому что он банально уйдет к другим, стоит ему предложить чуть больше денег.
Любите деньги? Очень жаль, но приходится жить в таком мире, где это пропагандируется. В чем сила денег? Пример из вакуума — изнасиловали дочку, насильник откупился, заплатив полицейским, не прокатило — заплатил в прокуратуру. Вот она — сила денег.
UFO just landed and posted this here
Следует различать «работать за деньги» и «работать ради денег». Вы, похоже, ради денег работаете. Положа руки на сердце, вы бы продолжили программировать за те же деньги, что и сейчас, если вам предложат больше денег за что-то другое, что вы умеете или, считаете, что быстро научитесь? Ну, например, из программистов переквалифицироваться в начальника программистов, заведомо понимая, что возможность программировать у вас будет только в личное время.
UFO just landed and posted this here
Речь тут только о том, что деньги — это компенсация, а не самоцель работы (по крайней мере у меня и у знакомых программистов). Человек выше имел ввиду, что уйти в начальники — это значит потерять возможность писать код (и творить в некотором роде). В то время как для вас это лишь сужение рынка, то есть опять «деньги деньги дребеденьги».
UFO just landed and posted this here
А когда вы на рыбалку ездите, вы от кого возганраждение ожидаете получить? А в отпуске? Пришел на пляж — подайте-ка сотню баксов за это. Поплавал до буйков — ба, да это же все 200.
Получать деньги за то, чем нравится заниматься — это одно, работать исключительно ради денег — другое. Если в одном месте платят в полтора раза больше, чем на текущем, но там постоянно стрессовая ситуация, код эпохи 90 и атмосфера всеобщей спешки и отношения «ты начальник — я дурак» — я лучше останусь на текущем, а вы, судя по этим комментам, перейдете, «та же платять больше-та». Ну или в лучшем случае не перейдете, посчитав, сколько будет стоит компенсация этого всего психологами, лекарствами и пр.
Ну в принципе можно и закончить, в ход пошли уже хрустальные шары.
Пока что этим только вы тут занимаетесь — я ни слова не сказал вас или мое отношение к вам, зато тут же оказался юнцом и гордецом. Ну что ж, если вам так легче…
Ну и да, батрачить за еду в «интересном стартапе» никто не предлагал, просто обычно баланс между ЗП и удовлетворительностью места у людей находится ближе к золотой середине, а не к крайностям.
Получать деньги за то, чем нравится заниматься — это одно, работать исключительно ради денег — другое. Если в одном месте платят в полтора раза больше, чем на текущем, но там постоянно стрессовая ситуация, код эпохи 90 и атмосфера всеобщей спешки и отношения «ты начальник — я дурак» — я лучше останусь на текущем, а вы, судя по этим комментам, перейдете, «та же платять больше-та». Ну или в лучшем случае не перейдете, посчитав, сколько будет стоит компенсация этого всего психологами, лекарствами и пр.
«вы и ваши знакомые программисты» в принципе не способны вообразить
Ну в принципе можно и закончить, в ход пошли уже хрустальные шары.
«вы и ваши знакомые программисты» просто напросто одержимы гордыней — вы считаете, что только вы являетесь высокоморальной личностью имеющей правол судить кто и что делает правильно, а кто нет…
Пока что этим только вы тут занимаетесь — я ни слова не сказал вас или мое отношение к вам, зато тут же оказался юнцом и гордецом. Ну что ж, если вам так легче…
Ну и да, батрачить за еду в «интересном стартапе» никто не предлагал, просто обычно баланс между ЗП и удовлетворительностью места у людей находится ближе к золотой середине, а не к крайностям.
Мы получаем компенсацию, но программируем не ради неё. Программировать будем, даже если придётся по денежным соображениями заниматься более высокооплачиваемой работой не связанной с программированием.
И мы не судим, а констатируем, что в профессии есть люди, для которых главным фактором нахождения в профессии вообще и на конкретном рабочем месте является денежное вознаграждение. Такие люди заметную часть личного, а то и рабочего времени тратят на мониторинг рынка труда и смежных рынков с целью продавать своё время по максимально возможной цене, с энтузиазмом осваивают только те технологии, которые выглядят обещающе с точки зрения максимизации доходов программистов.
И, да, с такими коллегами в одной команде нам работать не очень комфортно, хотя бы потому, что если условно объективно мы понимаем, что человеку в этой команде платят меньше чем он может получить в другом месте, значит этот человек скоро покинет команду.
И мы не судим, а констатируем, что в профессии есть люди, для которых главным фактором нахождения в профессии вообще и на конкретном рабочем месте является денежное вознаграждение. Такие люди заметную часть личного, а то и рабочего времени тратят на мониторинг рынка труда и смежных рынков с целью продавать своё время по максимально возможной цене, с энтузиазмом осваивают только те технологии, которые выглядят обещающе с точки зрения максимизации доходов программистов.
И, да, с такими коллегами в одной команде нам работать не очень комфортно, хотя бы потому, что если условно объективно мы понимаем, что человеку в этой команде платят меньше чем он может получить в другом месте, значит этот человек скоро покинет команду.
UFO just landed and posted this here
UFO just landed and posted this here
Это не точка зрения, это грубое описание одного из множества возможных образов жизни и два типа из классификации профессиональных программистов.
А я делаю так, чтобы в команде не оставались люди, ориентированные на максимизацию зарплаты, особенно путём обучения «дорогим» технологиям в рабочем процессе. Обучаться в рабочем процессе нужно тем технологиям, которые нужны компании, а не выгодны работнику, который настоит на внедрение «дорогой» технологии (а то и начнёт внедрение втихаря), изучит её во время этого внедрения, а потом уйдёт туда, где больше платят за резюме со строчкой с этой технологией.
А я делаю так, чтобы в команде не оставались люди, ориентированные на максимизацию зарплаты, особенно путём обучения «дорогим» технологиям в рабочем процессе. Обучаться в рабочем процессе нужно тем технологиям, которые нужны компании, а не выгодны работнику, который настоит на внедрение «дорогой» технологии (а то и начнёт внедрение втихаря), изучит её во время этого внедрения, а потом уйдёт туда, где больше платят за резюме со строчкой с этой технологией.
UFO just landed and posted this here
UFO just landed and posted this here
AlexPu > Единственно чем я занимаюсь профессионально, это повышением благосостояния своей семьи.
Я прошёл почти такой путь как вы описали, но выбирал языки и технологии по «эстетическому принципу».
Есть только пара исключений — Дельфи меня не устроил наличием begin, — и я выбрал reactJS и (отверг typescript по причине что вы ранее указали: «не связываться с технологиями microsoft „).
Удивительно мне то, что цели выбора были у нас разные — вас интересовало только повышение благосостояния вашей семьи (вы фактически “Штольц в программировании»). А я переходил от языка к языку исключительно по «эстетическому принципу» (например, я считал С++ просто «языком С» с вынужденной нашлёпкой ООП).
А дорога то у меня и у вас вышла одна, но при таких разных парадигмах выбора.
Это заставляет меня задаться вопросом — не является ли "эстетический принцип" критерием при выборе технологий, что в практическом плане приводит к построению «дороги» по которой идут все остальные разработчики, разработчики просто желающие побольше заработать для повышение благосостояния своей семьи?
Иначе я не могу понять почему так — ибо я могу вам по всем вами вышеперечисленным языкам и технологиям, подробно пояснить почему я выбрал их, руководствуясь чисто «эстетическим принципом» выбора и вовсе не задумываясь о распределение зарплат по этим технологиям в будущем (критерий, которым руководствовались, как я понял, вы, выбирая эти же технологии, эти же языки).
Но прогнозируя будущее распределение зарплат по этим технологиям (которое так и произошло на практике), вы всё же выбирали как-то именно эти технологии, — то есть вы применяли всё же какой-то иной критерий выбора, ставя на эти технологии, критерий — который вы так и не указали в своём большом комментарии. Имхо.
Я прошёл почти такой путь как вы описали, но выбирал языки и технологии по «эстетическому принципу».
Есть только пара исключений — Дельфи меня не устроил наличием begin, — и я выбрал reactJS и (отверг typescript по причине что вы ранее указали: «не связываться с технологиями microsoft „).
Удивительно мне то, что цели выбора были у нас разные — вас интересовало только повышение благосостояния вашей семьи (вы фактически “Штольц в программировании»). А я переходил от языка к языку исключительно по «эстетическому принципу» (например, я считал С++ просто «языком С» с вынужденной нашлёпкой ООП).
А дорога то у меня и у вас вышла одна, но при таких разных парадигмах выбора.
Это заставляет меня задаться вопросом — не является ли "эстетический принцип" критерием при выборе технологий, что в практическом плане приводит к построению «дороги» по которой идут все остальные разработчики, разработчики просто желающие побольше заработать для повышение благосостояния своей семьи?
Иначе я не могу понять почему так — ибо я могу вам по всем вами вышеперечисленным языкам и технологиям, подробно пояснить почему я выбрал их, руководствуясь чисто «эстетическим принципом» выбора и вовсе не задумываясь о распределение зарплат по этим технологиям в будущем (критерий, которым руководствовались, как я понял, вы, выбирая эти же технологии, эти же языки).
Но прогнозируя будущее распределение зарплат по этим технологиям (которое так и произошло на практике), вы всё же выбирали как-то именно эти технологии, — то есть вы применяли всё же какой-то иной критерий выбора, ставя на эти технологии, критерий — который вы так и не указали в своём большом комментарии. Имхо.
UFO just landed and posted this here
AlexPu
Это ясно. Но я не об этом у вас спрашиваю.
Так и я решил, но я решил это именно на основании наличия begin и end. — А вы на каком основании это решили?
Так, теперь ясно про Microsoft.
Это я помню. Но я так и не понял — что есть у вас за критерий? Вы пока рассуждаете типа как так — мне главное в рулетку выиграть — поэтому я поставил на красное.
Я же поставил на красное — потому что красное — это красивое! (для меня и многих).
Вы же типа пишите — я поставил на красное не потому что оно красивое (хотя я и понимаю что такое эстетика) — а потому что я просто хотел выиграть в эту рулетку.
Но вы так и не ответили на мой вопрос — Так почему вы выбрали красное?
Так, опять вы пишите — «я в свое время как-то почуствовал, что java имеет огромный рыночный потенциал». Что это означает?
Я же оценил Java именно как суперновое — как язык С но без нашлёпок ООП (как в С++) — то есть я понял что Java взлетит именно из-за эстетики Javа.
Из вашего же ответа я не понял — что вы почувствовали? Что же именно в Java привело вас и ваших коллег в состояния волнения («никто не мог сказать внятных аргументов, но все что-то чувствовали»)?
Какая "эманация", имеющаяся в Java, подвигла вас тогда, когда Java была только для рисования в броузере, к изучению этого языка?
Стоп. Опять вы уходите от моего вопроса — Какая "эманация", имеющаяся в Java, подвигла вас тогда, когда Java была только для рисования в броузере, к изучению этого языка?
Деньги — это уже потом. Что именно в такого в Java привело вас к решению — вот «оно», что принесёт мне деньги.
«Оно» — это что?
Это ясно, но критерием выбора технологий деньги не могут быть. — Они производное от правильного выбора.
Выбор технологий (которые принесут вам максимум прибыли) осуществляется по иным критериям.
И совпадение наших дорог намекает, что выбирая те или иные технологии, вы выбирали их чисто «эстетически» (возможно неосознанно), давя в себе эту «эстетику выбора».
Ваш комментарий и постоянное ваше упоминание, что ваш мотив "просто деньги" — говорит (имхо) том, что вы уже ощущаете как «эстетика выбора» — тот настоящий критерий, по которому вы фактически и выбираете технологии — уверяя себя что «никто не мог сказать внятных аргументов» просто пробивается к вам из вашего подсознания, но вы его сознательно давите своим «просто деньги».
Хм. Да. Фрейд. Да, намёк.
Да, вывод — вот это ваша фраза — «никто не мог сказать внятных аргументов» о Jаva, но все поняли что этот утёнок взлетит!
Эта ваша фраза и говорит мне, что все эти неосознаваемые при выборе аргументы, их невнятность, то есть неосознаваемость и есть тот «эстетический критерий», который я всё же осознал.
А иначе то и не ясно, почему вы всегда ставили на красное?
Скажем мне решительно наплевать на наличие или отсутствие операторов 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, но все поняли что этот утёнок взлетит!
Эта ваша фраза и говорит мне, что все эти неосознаваемые при выборе аргументы, их невнятность, то есть неосознаваемость и есть тот «эстетический критерий», который я всё же осознал.
А иначе то и не ясно, почему вы всегда ставили на красное?
UFO just landed and posted this here
UFO just landed and posted this here
AlexPu > И это… java мне как раз сильно не понравился изначально… Меня вполне устраивал паскаль с его begin и end… Это к вопросу об эстетике… положа руку на сердце java в 98-м году была убога до крайности
А не выбрать ли мне эту убогую Java, чтобы больше заработать?, — решили вы и начали её изучать.
Оно как-то не связывается у меня в голове это ваше решение. — Возможно только у меня такое.
А не выбрать ли мне эту убогую Java, чтобы больше заработать?, — решили вы и начали её изучать.
Оно как-то не связывается у меня в голове это ваше решение. — Возможно только у меня такое.
UFO just landed and posted this here
AlexPu > возможно только у вас не связывается…
Выбор убогой Java c надеждой в будущем заработать на ней, предполагает что-то увидеть в ней помимо этой убогости, что-то, что позволило вам начать её изучение.
Выбор убогой Java c надеждой в будущем заработать на ней, предполагает что-то увидеть в ней помимо этой убогости, что-то, что позволило вам начать её изучение.
UFO just landed and posted this here
AlexPu > Но увидел интерес рынка к java. И интерес весьма серьезный…
Ясно. Почему рынок заинтересовался Java вам было не интересно.
Ясно. Почему рынок заинтересовался Java вам было не интересно.
AlexPu
Первые трудности? — Хм, напоминает теперешнее состояние с Java ЕЕ.
Но разве вы не задумывались — почему эта штука становится популярной? — А иная не становится. Казалось бы — похожая штука, а не взлетает.
И это всё, своё решение, вы принимаете на основании информационный шума? — То что в статье называется buzzwords? А причина этого buzzwords вас никогда не интересовала?
Тут вы себе противоречите. Ведь по Java вы сделали вывод до того, как Java перестала быть игрушкой. До того! И к её взлёту вы уже были готовы!
По поводу дельфи все просто — его развитие явно застопорилось, у компании разработчика появились первые трудности…
Первые трудности? — Хм, напоминает теперешнее состояние с Java ЕЕ.
Все проще, что я и описал изначально — каждая появляющаяс технология, фреймворк, язык анализируется мной на предмет того, могу ли я на этом заработать… И не потому, что красное это красное — я просто смотрю, насколько популярной становится эта штука в моем окружении и в мире вообще…
Но разве вы не задумывались — почему эта штука становится популярной? — А иная не становится. Казалось бы — похожая штука, а не взлетает.
Так или иначе информационный шум всегданаличествует… И если я могу с достаточным основанием предположить, что ценность технологии «Т» устойчиво будет расти (и она уже растет),
И это всё, своё решение, вы принимаете на основании информационный шума? — То что в статье называется buzzwords? А причина этого buzzwords вас никогда не интересовала?
Но главный критерий это конечно ценность в глазах потенциальных работодателей/клиентов — если завтра в финляндии популярность react среди работодателей резко пойдет вверх
Тут вы себе противоречите. Ведь по Java вы сделали вывод до того, как Java перестала быть игрушкой. До того! И к её взлёту вы уже были готовы!
UFO just landed and posted this here
AlexPu > вы тоже принимаете все свои решения на основании информационного шума, разве что вы делаете это неосознанно
Трудно назвать эстетическое неприятия, например «begin», информационным шумом.
Конечно, buzzwords, влияет. — Выпустили Swift — я сразу же глянул — и мой эстетический фильтр его отверг. (про «эстетику» Object-C я молчу вообще). А сегодня смотрю рейтинг языков — Swift падает.
Трудно назвать эстетическое неприятия, например «begin», информационным шумом.
Конечно, buzzwords, влияет. — Выпустили Swift — я сразу же глянул — и мой эстетический фильтр его отверг. (про «эстетику» Object-C я молчу вообще). А сегодня смотрю рейтинг языков — Swift падает.
UFO just landed and posted this here
AlexPu > которые позже сменили не менее дебильные споры C++ vs java, а еще позже C# vs java
Понятно. Из этих дебильных споров образуется поток, в который уносит и простых девелоперов, цель которых проста — деньги и только деньги.
Понятно. Из этих дебильных споров образуется поток, в который уносит и простых девелоперов, цель которых проста — деньги и только деньги.
UFO just landed and posted this here
UFO just landed and posted this here
Как по мне, если язык действительно нравится, в него вкладываются силы и он не является прямо совсем эзотерическим — на нём почти всегда можно заработать. На плюсах живёт Gamedev класса ААА с очень интересными проектам, в которых как раз-таки требуется математика (и работа с изображением, и алгоритмы всякие интересные… что вообще ещё для счастья нужно?). Достаточно полутора лет опыта качественной, хорошей работы в компании класса ААА, немного активности в open source и на хабре — и вас потом HR будут вас сами зазывать с вашими плюсам (хм, каламбур вышел).
По поводу компаний — на просторах бывшего СССР можно с сходу назвать минимум четыре, пишущих игры на хорошем уровне: Ubisoft, Crytek, 4A Games (в России Vostok Games был — не знаю про его судьбу), Wargaming, Mail.ru. Это те, что конкретно у меня в кэше лежали. Уверен, если погуглить — ещё с десяток найти можно, уверен.
П.С.: Да и в науке плюсы тоже для оптимизации используются, если геймдев кажется несерьёзным направлением.
По поводу компаний — на просторах бывшего СССР можно с сходу назвать минимум четыре, пишущих игры на хорошем уровне: Ubisoft, Crytek, 4A Games (в России Vostok Games был — не знаю про его судьбу), Wargaming, Mail.ru. Это те, что конкретно у меня в кэше лежали. Уверен, если погуглить — ещё с десяток найти можно, уверен.
П.С.: Да и в науке плюсы тоже для оптимизации используются, если геймдев кажется несерьёзным направлением.
UFO just landed and posted this here
UFO just landed and posted this here
Ну, так если хочется рационального пути — его описал AlexPu. Геймдев — путь для фанатов. «Живи быстро, умри молодым!» (с)
А если серьёзно — не так уж там туго с овертаймами, как может показаться. Судя по общению со знакомыми в «серьёзном» программировании, под релиз овертаймы возникают почти везде. Геймдев объёмами этих овретаймов не особо выделялся. Возможно, мне просто повезло, не буду говорить за тенденции индустрии вообще… Но мне кажется, что если работа действительно приносит удовольствие — овертаймы не особо пугают. У нас многие (я в том числе) засиживались иногда в офисе допоздна по своей воле — просто потому, что на работе было интереснее, чем дома)
А если серьёзно — не так уж там туго с овертаймами, как может показаться. Судя по общению со знакомыми в «серьёзном» программировании, под релиз овертаймы возникают почти везде. Геймдев объёмами этих овретаймов не особо выделялся. Возможно, мне просто повезло, не буду говорить за тенденции индустрии вообще… Но мне кажется, что если работа действительно приносит удовольствие — овертаймы не особо пугают. У нас многие (я в том числе) засиживались иногда в офисе допоздна по своей воле — просто потому, что на работе было интереснее, чем дома)
UFO just landed and posted this here
Про выход очень просто. Гейм-дев использует свои технологии, никак не коррелирующие с рынком. Где может еще потребоваться глубокий OpenGL\DirectX API, Lua, игровые движки и библиотеки? В других областях другие библиотеки, и на выходе из гейм дев индустрии мы вынуждены включаться в другие области практически с нуля
Про стремность, не знаю, это скорее ИМХО, но гейм дев постоянно ставит принципиально новые задачи, которые не решить старыми способами. Сколько не тренируйся и не набивай руку, приходит очередной менеджер с фичами, которые ему кажутся просто эволюцией старой, а по механике и оптимизации графики нужно изворачиваться заного. Стресс, овертаймы, неприятный осадок. :)
Про стремность, не знаю, это скорее ИМХО, но гейм дев постоянно ставит принципиально новые задачи, которые не решить старыми способами. Сколько не тренируйся и не набивай руку, приходит очередной менеджер с фичами, которые ему кажутся просто эволюцией старой, а по механике и оптимизации графики нужно изворачиваться заного. Стресс, овертаймы, неприятный осадок. :)
UFO just landed and posted this here
Котлеты. Они устарели. От них надо избавляться.
> О да, я вчера попробовал приготовить котлету из масла. Мне казалось, это будет хорошая абстракция. Но она потекла…
Вот. теперь в моде корзинки.
>Корзинки? Для чего они?
Ходить за грибами
> Точно! Если взять современную корзинку, с защитой от протекания… Завтра же пойду в лес, собирать масло
> О да, я вчера попробовал приготовить котлету из масла. Мне казалось, это будет хорошая абстракция. Но она потекла…
Вот. теперь в моде корзинки.
>Корзинки? Для чего они?
Ходить за грибами
> Точно! Если взять современную корзинку, с защитой от протекания… Завтра же пойду в лес, собирать масло
А я считаю, что все еще есть поле для роста. Мы все еще не достигли стадии когда любой менеджер на интуитивно понятном ему уровне может запрограммировать себе любой бизнес-инструмент. А пену на пути к этому можно просто сдуть. )))
Вирт был прав.
И где сейчас его разработки?
При том, что виртовские продукты появлялись очень быстро и были отличного качества, они по долгу не удерживались ни на одной экологической нише. Думаю, он все-таки упустил что то важное.
При том, что виртовские продукты появлялись очень быстро и были отличного качества, они по долгу не удерживались ни на одной экологической нише. Думаю, он все-таки упустил что то важное.
Наоборот, очень элегантны. По крайней мере для нефункциональщиков.
potan > Наоборот, очень элегантны. По крайней мере для нефункциональщиков.
Элегантны? — Это Вирт придумал begin?
Элегантны? — Это Вирт придумал begin?
Ни чем не хуже "{". И не лучше.
К тому же еще в Algol так было.
К тому же еще в Algol так было.
potan > Ни чем не хуже "{". И не лучше. К тому же еще в Algol так было.
Ясно. Я думаю Вирт упустил из виду что такое «элегантность». — Это и есть ответ на ваше: «Думаю, он все-таки упустил что то важное ».
Ясно. Я думаю Вирт упустил из виду что такое «элегантность». — Это и есть ответ на ваше: «Думаю, он все-таки упустил что то важное ».
Просто бальзам на душу. Да! Автор молодец. Переводчик тоже молодец — потому, что нашёл и перевёл.
Именно! Нужно убрать наконец чёртовы эмоции из программирования и научиться смотреть на вещи прагматично. Нужно развивать то, что есть, не строить с нуля похожее ради дошивания желаемых рюшечек. Мысли трезвые… НО!
Чтобы это работало так, как хочет автор, нужно чтобы все технологии или языки имели идеальных людей у руля. Если опустить обсуждаемую тут тему маркетинга, можно сказать, что люди создают новые технологии и/или языки в том числе для того, чтобы банально было удобнее работать с какой-нибудь предметной областью.
Надеюсь, мысль в общем ясна — но дальше у меня будет оффтоп про С++. Наверняка тут будут кучкования по языкам и технологиями… Но пока спрячу лучше под кат — всё-таки у публикации тег web-разработка.
Именно! Нужно убрать наконец чёртовы эмоции из программирования и научиться смотреть на вещи прагматично. Нужно развивать то, что есть, не строить с нуля похожее ради дошивания желаемых рюшечек. Мысли трезвые… НО!
Чтобы это работало так, как хочет автор, нужно чтобы все технологии или языки имели идеальных людей у руля. Если опустить обсуждаемую тут тему маркетинга, можно сказать, что люди создают новые технологии и/или языки в том числе для того, чтобы банально было удобнее работать с какой-нибудь предметной областью.
Надеюсь, мысль в общем ясна — но дальше у меня будет оффтоп про С++. Наверняка тут будут кучкования по языкам и технологиями… Но пока спрячу лучше под кат — всё-таки у публикации тег web-разработка.
Оффтоп про С++
На мой взгляд, народ никогда не дёрнулся бы писать Rust или Go, если бы в С++ всё было удобно и благополучно. Настроения «до основания и затем» не возникают на ровном месте. Если бы люди могли с лёгкостью создавать проекты в экосистеме языка (а она вообще есть — гомогенная экосистема для С++?), если бы люди ощущали, что их желания понимают стандартизаторы языка — они бы вкладывали свою творческую энергию в развитие экосистемы С++, а не Rust или Go. И это было бы правильно безотносительно эмоций по отношению к С++, Rust и Go. Безотносительно эмоций — лучше бы концепции Go и Rust были бы включены в С++, чем Go и Rust возникли бы как самостоятельные языки.
Я не исключаю того, что сам возможно перейду на Rust или Go, если они взлетят. Но, не смотря на это, во мне останется чувство досады по поводу того, насколько глупая история привела к созданию этих языков и насколько нерационально человечество потратило своё время в этом направлении.
К чему я всё это пишу…
Золотые слова. Но если люди, стоящие у руля языка или технологии отрываются от реальности и не желают вникнуть в интересы программистов (или не объясняют по-человечески почему интересы программистов идут в разрез со здравым смыслом) — программисты желают создавать инструменты, которые решит конкретно их проблемы. Тратят на это время, да, пытаются создать сообщество — чтобы работа шла быстрее. И это не мотивация «клевать всё что блестит». Это отчасти акт отчаяния.
ИМХО, естественно. Надеюсь, не задел ничьих чувств.
Я не исключаю того, что сам возможно перейду на Rust или Go, если они взлетят. Но, не смотря на это, во мне останется чувство досады по поводу того, насколько глупая история привела к созданию этих языков и насколько нерационально человечество потратило своё время в этом направлении.
К чему я всё это пишу…
Если мы будем продолжать переключаться с одного языка на другой, мы никогда не обеспечим их надёжным инструментарием
Золотые слова. Но если люди, стоящие у руля языка или технологии отрываются от реальности и не желают вникнуть в интересы программистов (или не объясняют по-человечески почему интересы программистов идут в разрез со здравым смыслом) — программисты желают создавать инструменты, которые решит конкретно их проблемы. Тратят на это время, да, пытаются создать сообщество — чтобы работа шла быстрее. И это не мотивация «клевать всё что блестит». Это отчасти акт отчаяния.
ИМХО, естественно. Надеюсь, не задел ничьих чувств.
лучше бы концепции Go и Rust были бы включены в С++, чем Go и Rust возникли бы как самостоятельные языки.
Вносить концепции ломающие обратную совместимость не сильно отличается от создания нового языка, особенно если их много. Не считая того, что Go и Rust достаточно разные языки, и внести концепции обоих в один язык нереально.
Легковесные потоки Go вполне можно впихнуть в С++ в качестве библиотеки. Я так понимаю, совет С++ как раз эту тему разжёвывает сейчас очень активно (глядя на успехи Go). Есть же boost-fiber, в конце концов.
С Rust ситуация сложнее. Определённо есть попытки, но пока не похоже, что С++ сможет в принципе достичь того же уровня безопасности.
Легковесные потоки Go вполне можно впихнуть в С++ в качестве библиотеки
Можно, но получится так себе.
Дело тут вот в чем — с легковесными потоками, большой вопрос — сколько памяти выделять под стек. Слишком мало, и код будет падать по переполнению стека. Слишком много, с запасом — тоже плохо. Самое разумное, «растить» стек динамически.
Это можно делать по-разному, но самое эффективное, это скопировать все данные со стека в новую непрерывную область памяти и поправить указатели, как делает это Go.
если бы в плюсы просто перетащил основные киллер фичи с обеих ЯП и сделал бы их использование подобно использованию Си в С++
Так если ломать обратную совместимость (а то, что ее не ломает, уже либо в языке, либо в proposals и рано или поздно появится в С++), зачем цепляться за её остатки?
Напомню, что создатели Go считают, что С++ слишком сложный и именно поэтому создали Go. Другой из основных идей является желание сократить количество ключевых слов. И сборщик мусора в Go тоже есть. И как эти концепции вносить в C++? Go вообще сомнительный конкурент C++.
сборку мусора сделать как в расте (на стадии компиляции) но с возможностью ручками освободить память. А так то я учу сейчас плюсы и больших различий между ними и Go не заметил (ну кроме ООП конечно. Предполагаю что именно его и считают сложным)
По поводу обратной совместимости… У меня была по этому поводу вот какая мысль. Почему начиная с какой-то версии нельзя разделить стандарты С++? Оставить старый стандарт с его кучей legacy-фич и сделать новый стандарт, сбросив языковое старьё с парохода истории? Да, при этом разработчикам новых компиляторов придётся в полтора раза больше работы делать, а существующие компиляторы для legacy, скорее всего, остановятся в развитии. Но можно смягчить удар описанием рекомендованных практик для создания полуавтоматических инструментов перевода кода из старого в новый и постепенно обновить legacy. Насколько я знаю, так, например, делают ребята из Apply со своим языком Swift, который пока стабилизируется в смысле синтаксиса. Соглашусь, эплам в этом смысле легче — они вводят подобные практики на своей, одной платформе. Но и в рамках плюсов, как мне кажется, вопрос решаемый…
Так уже два раза делали… Но что-то не спешат переходить с legacy C++ ни на D, ни на Rust.
Главная проблема, как мне кажется — библиотеки, и их описание в формате заголовочных файлов. Вот эти самые заголовочные файлы, остро зависимые от legacy-фишек, никуда автоматически не перетащить.
Ну, я вообще немного другое имел в виду, но с учётом желания стать наследниками С++ эти языки подойдут как пример. Про D говорить не буду, мало о нём знаю, но если говорить про Rust… Мне кажется, на него не переходят потому, что экосистема языка пока слабовата. А слабовата она — опять так, по моему, вероятно, достаточно поверхностному мнению — как раз потому, что этот язык создавали как конкурента, а не как наследника. Если бы комитетчики из С++ сказали: «Всё, Rust это теперь современная версия С++, делаем всё, чтобы перебраться на него» — то дело бы пошло. Но сказать они такого не скажут, я думаю. Во всяком случае, в ближайшем будущем.
Вообще же, в контексте уход от legacy меня воодушевила решимость Kronos Group с их Vulkan API. Делали OpenGL десятки лет — и нет-нет, да решились выкатить новое API. С С++ будет труднее — но, возможно, придут рано или поздно в Комитет молодые и решительные, и тоже сделают что-нибудь подобное?
А в чём проблема именно с заголовочными файлами? Я так понимаю, если будет создан инструмент для трансляции из С++ в Rust, то с заголовочными файлами не должно быть проблем?
Вообще же, в контексте уход от legacy меня воодушевила решимость Kronos Group с их Vulkan API. Делали OpenGL десятки лет — и нет-нет, да решились выкатить новое API. С С++ будет труднее — но, возможно, придут рано или поздно в Комитет молодые и решительные, и тоже сделают что-нибудь подобное?
Вот эти самые заголовочные файлы, остро зависимые от legacy-фишек, никуда автоматически не перетащить
А в чём проблема именно с заголовочными файлами? Я так понимаю, если будет создан инструмент для трансляции из С++ в Rust, то с заголовочными файлами не должно быть проблем?
Это очень сильно отличается. Останется компилятор. Останется ide. Останется синтаксис языка. Останется стандартная библиотека языка. Останутся все предыдущие разработки на этом языке.
Где ж они останутся, если обратная совместимость тю-тю. Да, основа останется, но она остается и так, неужели вы думаете что JetBrains пишет каждую IDE с нуля или LLVM каждый раз пишут все заново? Все написанное на языке придется переписывать под новый стандарт, а у кучи кода нет поддержки уже десятки лет.
При этом переход на новую версию будет проходить очень неохотно. Посмотрите на питон — вторая версия до сих пор жива, несмотря на все усилия создателей и то что разница между версиями не такая уж и большая.
Я же могу импортировать legacy модуль в legacy режиме. Это наверняка есть и в Rust, но могли бы сделать полный автомат, на уровне, подключил h файл, и в Rust появились все legacy C++ функции из модуля. Я просто не знаю, возможно там это и так есть. Существующие компиляторы, чтобы собиралось под ios и android. Как в Rust с этим, все хорошо? Синтаксис C++, который мне так любим, с этим в Rust все хорошо?
Если бы брали что есть в C++, и просто прикручивали сверху опционально новые возможности, сохраняя возможность использовать старое через директивы, было бы гораздо лучше. Не надо выкидывать старые компиляторы, они мне нужны, чтобы собираться на целевые платформы. Я не хочу ждать, пока новый язык расчехлится на способность собираться везде, где собирается C++ без stdlib. Давайте сначала ехать, а потом шашечки.
Если бы брали что есть в C++, и просто прикручивали сверху опционально новые возможности, сохраняя возможность использовать старое через директивы, было бы гораздо лучше. Не надо выкидывать старые компиляторы, они мне нужны, чтобы собираться на целевые платформы. Я не хочу ждать, пока новый язык расчехлится на способность собираться везде, где собирается C++ без stdlib. Давайте сначала ехать, а потом шашечки.
Если бы брали что есть в C++, и просто прикручивали сверху опционально новые возможности,
… то С++ превратился бы в монстра, которого никто понять не может. К нему и так прикручено столько, что мама не горюй.
Не надо выкидывать старые компиляторы
Но надо их переписывать.
Пусть будет монстром, собираясь под iOS с старыми и новыми фичами. Я как-нибудь справлюсь с чистотой кода самостоятельно.
Ну попробуйте написать proposal в комитет, может вы и правда правы и все поймут какая шикарная это идея.
Комитет далек от желаний рынка и простых разработчиков. Он хочет чистый язык, годами выписывать стандарты. Да и незачем обращаться в комитет, если можно разработать свой транслятор. Увы, все упирается в время и ресурсы.
Желательно ещё приложить почку.
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 Waldo
Я же могу импортировать legacy модуль в legacy режиме. Это наверняка есть и в Rust, но могли бы сделать полный автомат, на уровне, подключил h файл, и в Rust появились все legacy C++ функции из модуля. Я просто не знаю, возможно там это и так есть.
В случае rust есть bindgen, который генерирует ffi обёртки над сишным кодом, но они, естественно, unsafe.
Вызов кода на c++ из любого языка — проблема (даже из c++, если зависимость бинарная и собранная другим компилятором), если не предоставлен сишный интерфейс (через extern "C", чтобы избавится от name mangling).
Я не хочу ждать, пока новый язык расчехлится на способность собираться везде, где собирается C++ без stdlib.
Это называется Си с темплейтами и классами. И небольшим кусочком libstd++, т. к. остальное требует аллокатора, который не всегда есть на bare metal.
UFO just landed and posted this here
Ничего. Я же импортирую _legacy_ header, с чего бы на нем должны работать новые фичи? Он весь целиком пойдет unsafe.
UFO just landed and posted this here
Нет, либо я делаю safe обертку, и сам отвечаю за это, либо конкретная функция, в которой есть вызов unsafe метода, становится unsafe.
Проблема в том, что реально unsafe распространяется до границы модуля, а т. к. в плюсах их нет, то, фактически, на всю программу/библиотеку. Простой пример нелокальности для unsafe rust см. https://doc.rust-lang.org/nomicon/working-with-unsafe.html
Вот к примеру я делал на C++ raii аллокатор памяти. Само собой ни ffmpeg, ни png\jpg библиотеки ничего о нем не знали, но это не мешало мне писать врапперы под эти библиотеки, чтобы быть спокойным что утечек нет.
До Rust и Go уже был написан D. Если с C++ понятно, что ломать обратную совместимость никто не хочет, то вот почему не захотели вкладываться в D непонятно…
Мне кажется у D просто не было своей ниши. У D есть сборка мусора, но тут уже есть Java и .Net
И теперь те кому нужна была максимальная производительсть и минимальные затраты памяти выбирали плюсы, а остальные старые проверенные технологии.
Rust — дает сравнимую с плюсами скорость работы программы и потребление памяти, при гораздо более удобной и безопасной модели работы.
Go — отличная многопоточность — тут и горутины и каналы для передачи данных. И все это элементы языка да еще и first class citizens.
Такчто имхо Раст и Го обречены найти свою аудиторию в отличае от D ну и вероятно отгрызут немалый кусок адептов си++.
И теперь те кому нужна была максимальная производительсть и минимальные затраты памяти выбирали плюсы, а остальные старые проверенные технологии.
Rust — дает сравнимую с плюсами скорость работы программы и потребление памяти, при гораздо более удобной и безопасной модели работы.
Go — отличная многопоточность — тут и горутины и каналы для передачи данных. И все это элементы языка да еще и first class citizens.
Такчто имхо Раст и Го обречены найти свою аудиторию в отличае от D ну и вероятно отгрызут немалый кусок адептов си++.
… почему не захотели вкладываться в D непонятно…
На сколько я знаю, авторы при создании допустили как минимум 1 большую ошибку. После стаблизации 1-ой версии языка они вместо того чтобы вкладываться в экосистему (стабилизацию стандартной библиотеки (их тогда было две в D), поддержку IDE и пр. tool-ов) они практически сразу приступили к активному пилению 2-ой версии языка, что и отпугнуло разработчиков от перехода с C++ на D. А потом уже появились стандарты С++11, C++14 и D стал уже не столь актуален даже при всей крутости своего метапрограммирования.
На сколько я знаю, авторы при создании допустили как минимум 1 большую ошибку. После стаблизации 1-ой версии языка они вместо того чтобы вкладываться в экосистему (стабилизацию стандартной библиотеки (их тогда было две в D), поддержку IDE и пр. tool-ов) они практически сразу приступили к активному пилению 2-ой версии языка, что и отпугнуло разработчиков от перехода с C++ на D. А потом уже появились стандарты С++11, C++14 и D стал уже не столь актуален даже при всей крутости своего метапрограммирования.
По-моему, очень хорошо, что появляются новые языки, типа тех же Rust и Go. Это здоровая конкуренция, которая подстёгивает крупных и старых игроков (Java, C++), заставляя их шевелиться. В Java уже ввели лямбды, скоро будет автовывод типов. Надеюсь, async/await тоже не за горами.
В C++17 могут появиться концепты, ограничения и требования для шаблонов, выглядит как невероятно крутая фича, позволяющая описывать требования к типу на метаязыке вместо наследования или интерфейсов. Я не знаю Haskell, может, там есть что-то такое, но из других более-менее мейнстримных языков такого не видел нигде. Ограничения на generics накладываются обычно через иерархию типов (extends/super в Java), но не как тут предлагается, в виде вычисления произвольного выражения.
Интерфейсы в Go считаются, вроде как, самым прогрессивным путём для достижения слабой связанности, позволяя привлекать сторонние подходящие классы, которые не связаны с интерфейсом, кроме как по совпадению сигнатур функций. Концепты же позволяют применять такие классы, которые просто удовлетворяют некоей логике поведения! Как пример: http://en.cppreference.com/w/cpp/concept/SequenceContainer — выразить эту логику с помощью интерфейсов или дженериков, похоже, достаточно сложно.
В C++17 могут появиться концепты, ограничения и требования для шаблонов, выглядит как невероятно крутая фича, позволяющая описывать требования к типу на метаязыке вместо наследования или интерфейсов. Я не знаю Haskell, может, там есть что-то такое, но из других более-менее мейнстримных языков такого не видел нигде. Ограничения на generics накладываются обычно через иерархию типов (extends/super в Java), но не как тут предлагается, в виде вычисления произвольного выражения.
Интерфейсы в Go считаются, вроде как, самым прогрессивным путём для достижения слабой связанности, позволяя привлекать сторонние подходящие классы, которые не связаны с интерфейсом, кроме как по совпадению сигнатур функций. Концепты же позволяют применять такие классы, которые просто удовлетворяют некоей логике поведения! Как пример: http://en.cppreference.com/w/cpp/concept/SequenceContainer — выразить эту логику с помощью интерфейсов или дженериков, похоже, достаточно сложно.
По-моему, очень хорошо, что появляются новые языки, типа тех же Rust и Go
Да. Здоровая конкуренция это хорошо. Но если говорить про эффективность человечества в целом и сообщества программистов в частности — лучше бы эта конкуренция существовала в рамках групп, развивающих существующий язык. Это минимум сэкономило бы огромное количество времени на создание с нуля новых экосистем: компиляторы, IDE, инструменты, библиотеки — всё, что не касается напрямую особенностей новых языков, но то, без чего эти языки просто не смогут существовать и развиваться.
Как я уже писал, по моему мнению авторы Go и Rust решили создавать эти языки не от хорошей жизни, а по причине застоя в экосистеме С++.
На мой взгляд, главное что может вернуть плюсы в русло стабильного развития — это внятная билд-система со встроенным пакетным менеджером. Это позволит делать новые проекты легко вкручивая в них старые и заняться развитием языка, вместо неэффективного велосипедопроизводства (почти в каждом крупном проекте с нуля создают стандартную библиотеку — это нормально вообще?).
П.С.: Концепты это круто, да. Смотрел немного их реализацию в gcc — уже выглядит хорошо. Если появятся в паре с рефлексией (которую сейчас приходиться костылить самому) — вообще замечательно было бы… Но билд-система и пакетный менеджер, как по мне, более актуальны.
лучше бы эта конкуренция существовала в рамках групп, развивающих существующий язык
Увы, языки — штука прикладная, без обширной аудитории не получится сделать хороший язык. В наших силах разве что, как и описано в статье, не покупаться на блестяшки и ждать, пока новый язык повзрослеет, обрастёт инструментами и библиотеками, чтобы можно было перейти или просто попробовать без негативных первых впечатлений. Было бы здорово иметь универсальный фреймворк для быстрого создания 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 не может такого предоставить, приходится велосипедить.
Было бы здорово иметь универсальный фреймворк для быстрого создания IDE под любой язык
Ну, вроде как упомянутый Eclipse был создан в том числе чтобы на его основе можно было IDE делать (ссылка).
Это да, требование времени
На мой взгляд, это необходимое условие для развития любого языка. Помимо прямого назначения (подтягивание зависимостей), пакетный менеджер несёт ещё одну очень важную функцию — он даёт возможность централизованного поиска решений и, соответственно, поощряет выбор существующих библиотек вместо создания своих. Пакетный менеджер сможет сфокусировать сообщество программистов С++ на новом, а не на очередной переработке старого. Особенно если придумать и встроить в язык что-то вроде Dependency Injection, чтобы можно было легко подменять пакеты.
Очень хочется Maven под C++, но пока самым вменяемым остаётся CMake, хотя бы как билд-система
Я CMake не понимаю. Возможно, маловато опыта работы, но вот тут я описал свои эмоции от взаимодействия с ним.
UFO just landed and posted this here
UFO just landed and posted this here
Вот только у логарифмической кривой нет горизонтальных асимптот.
Очень выгодно будет стать разработчиком "языка, или двух, или трёх", кстати. То же с двумя-тремя фреймворками для всей планеты. При этом понятно, что разрабатывать их будут те же люди, что и сегодня, то есть, метод и концепция не поменяются.
И это хорошо, если в дело не вмешается мифология. С такой мифологией нелегко иметь дело, так как её поддерживает мнение «всех», мнение «профессионалов», ссылки на «промышленную практику» и т.д. и т.п. (явление спонтанной намагниченности, когда атомам магнитного материала оказывается энергетически выгодно выстроиться в любом, но одинаковом направлении; перемагничивание такого материала в любом другом направлении требует затрат энергии — т.наз. явление магнитного гистерезиса.)
Получится добровольное погружение умных ИТ-шников в хорошую годную монополию условного Гугла, окончательное бетонирование результатов 30 лет отрицательного отбора технологий по нетехническим критериям имени человекообразных бизнесменов и рептилоидных топ-менеджеров.
Хотя, очевидно, что любая конкуренция ведёт к монополии, сейчас хотя бы спасает ситуацию тот факт, что в ИТ технологии не умирают, а просто лишаются хайпа. (потому что продукты в ИТ нематериальные, и условный проект на мёртвом Wicketе будет жить и поддерживаться годами).
Две цитаты с интервалом буквально в один комментарий:
«Мне очень жаль, но это как говорить, что молоток лучше отвёртки.»
"...C++ вероятно лучше, чем C. Java был улучшением по сравнению C++. Ruby вероятно немного лучше, чем Java".
Такое ощущение, что в авторе сидят две личности — адекватный профессионал и школьник с лора, которые пытаются друг друга перекричать его ртом.
«Мне очень жаль, но это как говорить, что молоток лучше отвёртки.»
"...C++ вероятно лучше, чем C. Java был улучшением по сравнению C++. Ruby вероятно немного лучше, чем Java".
Такое ощущение, что в авторе сидят две личности — адекватный профессионал и школьник с лора, которые пытаются друг друга перекричать его ртом.
А при чем тут программирование, о нем ли статья?
… логарифмической кривой роста
… приближаемся к асимптоте
Простите, не смог удержаться ))
Очень хороший пост, мне понравилось!
Когда знаешь, что у логарифма не асимптоты на бесконечности
А ещё иногда такое бывает, что один парень не осилил (пока что) ООП, и пишет в процедурном стиле. А называет это почему-то функциональным стилем. Ну функции же пишет, а что? Так смешно бывает.
vladimirgamalian > А ещё иногда такое бывает, что один парень не осилил (пока что) ООП, и пишет в процедурном стиле. А называет это почему-то функциональным стилем. Ну функции же пишет, а что? Так смешно бывает.
Меня больше удивляет то, что в массы процедурный стиль именно через JavaScript пробивается. В массы. То есть массово! — Вот уж смешно так смешно. — Процедурный стиль в массы и через JavaScript!
Меня больше удивляет то, что в массы процедурный стиль именно через JavaScript пробивается. В массы. То есть массово! — Вот уж смешно так смешно. — Процедурный стиль в массы и через JavaScript!
ъ, jQuery победит?
Да что уж там языки и фреймворки.
Казалось бы, что могло подвинуть реляционные БД с постамента наиболее популярной модели хранения данных? Кто бы мог подумать 10-15 лет назад, что в половине новых проектов будут пихать реляционные данные в Монгу, и ночами реализовывать контроль целостности и некое подобие транзакций, ссылаясь на «возможности масштабирования и доступности». При том, что в 80% этих проектов никогда не понадобится репликация больше чем на пару серверов.
Люди в слове «NoSQL» получили отмазку от изучения теории и практики РБД: появилась причина назвать реляционные базы неповоротливым старьём, и не изучать их больше, а быстренько веъхать в более простые документные базы и быть, так сказать, готовым к бою. Но далеко не каждый понимал, что ему придётся заново пройти весь путь.
Есть немало языков, которые стоит изучить (не обязательно использовать в разработке, но изучить). Есть и немало языков, которые лучше бы вообще не появлялись. Когда C++ разработчик предлагает попробовать Rust потому, что видит в нём устоявшиеся практики по управлению временем жизни объектов (передача владения и пр.) в кристаллизованом виде — это профессионализм (разумеется, вкупе со здоровой оценкой состояния инструментов для языка). Когда C++ «разработчик» предлагает попробовать Rust только потому, что Плюсы он так и не осилил в необходимом объеме — это лень и невежество.
Я убежден, что разработчики сегодня слишком ленивы и невежественны.
Автору спасибо за перевод!
Казалось бы, что могло подвинуть реляционные БД с постамента наиболее популярной модели хранения данных? Кто бы мог подумать 10-15 лет назад, что в половине новых проектов будут пихать реляционные данные в Монгу, и ночами реализовывать контроль целостности и некое подобие транзакций, ссылаясь на «возможности масштабирования и доступности». При том, что в 80% этих проектов никогда не понадобится репликация больше чем на пару серверов.
Люди в слове «NoSQL» получили отмазку от изучения теории и практики РБД: появилась причина назвать реляционные базы неповоротливым старьём, и не изучать их больше, а быстренько веъхать в более простые документные базы и быть, так сказать, готовым к бою. Но далеко не каждый понимал, что ему придётся заново пройти весь путь.
Есть немало языков, которые стоит изучить (не обязательно использовать в разработке, но изучить). Есть и немало языков, которые лучше бы вообще не появлялись. Когда C++ разработчик предлагает попробовать Rust потому, что видит в нём устоявшиеся практики по управлению временем жизни объектов (передача владения и пр.) в кристаллизованом виде — это профессионализм (разумеется, вкупе со здоровой оценкой состояния инструментов для языка). Когда C++ «разработчик» предлагает попробовать Rust только потому, что Плюсы он так и не осилил в необходимом объеме — это лень и невежество.
Я убежден, что разработчики сегодня слишком ленивы и невежественны.
Автору спасибо за перевод!
Nipheris > Казалось бы, что могло подвинуть реляционные БД с постамента наиболее популярной модели хранения данных?
Лет 25 назад, до прихода реляционных баз, было столько написано документов по "сетевым базам данных" — целый мировой комитет CODASIL был. — Вот оно откуда и берётся это «новое». — «Оно» проснулось.
Лет 25 назад, до прихода реляционных баз, было столько написано документов по "сетевым базам данных" — целый мировой комитет CODASIL был. — Вот оно откуда и берётся это «новое». — «Оно» проснулось.
Года два кодил на CoIDE на базе Eclipse. Ох и глючная система! На ровном месте перестает работать (проблемы испытывал не только я). IAR, CoIDE, Keil — все такое отстойное. Хоть бы взяли и соединили все в кучку, выбрали бы все лучшее. Хоть в текстовых редакторах работай.
Всё это сансара. Сколько не бегай по кругу, а вернёшься туда же. К страданию.
> Да! Это непрофессионально. Нам нужно осознать, что мы упёрлись в асимптоту. Нам нужно выбрать язык, или два, или три.
Не согласен с автором.
Представим себе человечество в 500 году до н.э.
Люди изготавливают корабли из дерева, своими руками. И тут самый прошаренный прораб всем говорит:
-Да достали вы уже со своими экспериментами! Кто из камня, кто из тросняка делает, кто смазывает корабли, кто как попало делает! Где-то это приносит пользу, а где-то нет! Согласитесь, это не профессионально! Мы уперлись в предел человеческих возможностей! Делайте корабли из ДЕРЕВА, а не из ЖЕЛЕЗА (которое ТОНЕТ, карл!), и не придумывайте чепухи! Даже если вы что-то и придумаете, то рост будет незначительный (1%, вместо +100% как раньше).
Прям 1-в-1 статья. А ведь пройдет еще ~2500 лет, люди обуздают металлы и будут все делать по-другому…
Не согласен с автором.
Представим себе человечество в 500 году до н.э.
Люди изготавливают корабли из дерева, своими руками. И тут самый прошаренный прораб всем говорит:
-Да достали вы уже со своими экспериментами! Кто из камня, кто из тросняка делает, кто смазывает корабли, кто как попало делает! Где-то это приносит пользу, а где-то нет! Согласитесь, это не профессионально! Мы уперлись в предел человеческих возможностей! Делайте корабли из ДЕРЕВА, а не из ЖЕЛЕЗА (которое ТОНЕТ, карл!), и не придумывайте чепухи! Даже если вы что-то и придумаете, то рост будет незначительный (1%, вместо +100% как раньше).
Прям 1-в-1 статья. А ведь пройдет еще ~2500 лет, люди обуздают металлы и будут все делать по-другому…
И правильно скажет. Сначала должно пройти 10 веков, должны появиться соответствующие технологии обработки металлов, соответствующие инструменты по проверки безопасности судна. Статья прямо пишет — не нужно переходить на новые языки, в которых уровень сопровождения еще в каменном веке. Некуда торопиться.
Опять, я с вами не согласен. Каменный век так и будет оставаться каменным, и не появятся инструменты сами собой из неоткуда. Тем более, пока будут всем указывать, чтобы ничего не изобретали. Может есть на свете гений(99.999%), который придумает новый виток развития. Но запретив ему, он этого не сделает. И кто знает, может мы так и просидим еще 1000 лет, а потомки будут про нас говорить, что они застряли в своих убеждениях в каменном веке!
Я дополню, что чаще всего программисты — это энтузиасты, которым эта сфера по душе, им нравится её бездонная неизвестность. И эти же люди любят изучать что-то новое. Тот, кто не любит это делать, кому это не нравится — ему и работа программистом не нравится. Из этого следует, что запрещать программистом развиваться и придумывать новые вещи — значит спорить с самой сутью нашего увлечения.
Я дополню, что чаще всего программисты — это энтузиасты, которым эта сфера по душе, им нравится её бездонная неизвестность. И эти же люди любят изучать что-то новое. Тот, кто не любит это делать, кому это не нравится — ему и работа программистом не нравится. Из этого следует, что запрещать программистом развиваться и придумывать новые вещи — значит спорить с самой сутью нашего увлечения.
Так речь то не о том, чтобы запрещать что-то придумывать, речь о том, что за предыдущие, допустим, 10 лет практически ничего нового не придумали. На первый взгляд кажется, что это бред, вон же каждую неделю что-то новое появляется. Но если задуматься, то по сути то реально ничего нового, просто небольшие плюшки, аля синтаксический сахар.
Все ЯП — синтаксический сахар для ассемблера ;)
Ну может и не явно запрещает, но явно указывает, что надо перестать это делать. Вот цитаты:
> Пора остановить расточительное вспенивание языков и фреймворков, а также парадигм и процессов.
Ну как это не запрет искать новые пути?
> Пришло время, чтобы начать просто работать.
Да, давайте просто тесать камни. Ничего уже не придумать, всё что можно — уже придумали. Берите в руки молотки.
>Нам нужно выбрать язык, или два, или три. Небольшой набор простых фреймворков. А затем выстроить наши инструменты.
Это как: выберите себе два инструмента на выбор, и будьте мастером только их: «молоток, пила, отвертка, плоскогубцы, гвоздь, дрель». Нафиг нам всякие там «кусачки, кувалда, электропила, итд итп», ведь всё это — «лишь синтаксический сахар», а дом строят из молотков и гвоздей, остальное «лишь немного облегчает строительство».
>Кристаллизовать наши процессы. И стать настоящими профессионалами.
Да, профессионалом по отесыванию камней и строительству домов из камней и песка. Но опять-же, этот призыв ограничиваться звучит бредово (про ограничение развития программистов я уже написал выше). И так можно и 1000 лет продолжать писать код в текущем стиле, призывая всех: КОЛЛЕГИ, ВЫ ТОЛЬКО НИЧЕГО НОВОГО НЕ ПРИДУМЫВАЙТЕ! И через 1000 лет про нас будут писать/говорить/думать/общаться через поток мыслей, что мы были тупыми дибилами, застрявшими в цифровой эпохе электрических компьютеров на 1000 лет.
> Пора остановить расточительное вспенивание языков и фреймворков, а также парадигм и процессов.
Ну как это не запрет искать новые пути?
> Пришло время, чтобы начать просто работать.
Да, давайте просто тесать камни. Ничего уже не придумать, всё что можно — уже придумали. Берите в руки молотки.
>Нам нужно выбрать язык, или два, или три. Небольшой набор простых фреймворков. А затем выстроить наши инструменты.
Это как: выберите себе два инструмента на выбор, и будьте мастером только их: «молоток, пила, отвертка, плоскогубцы, гвоздь, дрель». Нафиг нам всякие там «кусачки, кувалда, электропила, итд итп», ведь всё это — «лишь синтаксический сахар», а дом строят из молотков и гвоздей, остальное «лишь немного облегчает строительство».
>Кристаллизовать наши процессы. И стать настоящими профессионалами.
Да, профессионалом по отесыванию камней и строительству домов из камней и песка. Но опять-же, этот призыв ограничиваться звучит бредово (про ограничение развития программистов я уже написал выше). И так можно и 1000 лет продолжать писать код в текущем стиле, призывая всех: КОЛЛЕГИ, ВЫ ТОЛЬКО НИЧЕГО НОВОГО НЕ ПРИДУМЫВАЙТЕ! И через 1000 лет про нас будут писать/говорить/думать/общаться через поток мыслей, что мы были тупыми дибилами, застрявшими в цифровой эпохе электрических компьютеров на 1000 лет.
Вы почему-то исходите из того, что текущий уровень языков программирования очень низок. Но по факту нам и правда надо хорошенько осмыслить то, что придумали за предыдущие 60 лет. На тех компьютерах, которые у нас сейчас есть, крайне сложно придумать что-то новое в области программирования. Более того CPU уже упёрлись в физические пределы производства. И даже на случай, если дальнейший рост пойдёт через увеличение кол-ва ядер на порядки, уже всё придумано.
А если Вы реально хотите придумать что-то новое в плане программирования, смотрите в сторону появляющихся вариантов, типа квантовых компьютеров. Там прогресс будет, но это уже совсем другая история. Не имеющая отношения к написанию 100500 примерно одинаковых фреймворков/библиотек для одной и той же задачи.
застрявшими в цифровой эпохе электрических компьютеров на 1000 лет.В том то и дело, что придумывать новые компьютеры в компетенции программистов не входит, это будут делать физики.
А если Вы реально хотите придумать что-то новое в плане программирования, смотрите в сторону появляющихся вариантов, типа квантовых компьютеров. Там прогресс будет, но это уже совсем другая история. Не имеющая отношения к написанию 100500 примерно одинаковых фреймворков/библиотек для одной и той же задачи.
Изобретайте, на здоровье. На поприще академических языков. Пусть пройдут ваши 10 веков, и ваша технология начнет применяться, когда ваши наработки будут серьезным продуктом. Речь о том, что индустрия хватает все с печки, когда там еще сырая мука.
То есть запрет не на изобретение, а на использование изобретений?
Не на использование, а на коммерческое внедрение сырых изобретений.
Знаете почему автомат Калашникова до сих пор на вооружении? Потому что его замена на любой существующий автомат не даёт повышения боевой эффективности адекватного увеличению стоимости.
Zenitchik > Знаете почему автомат Калашникова до сих пор на вооружении?
Просто сейчас в мире всё смешное и одноразовое — от жилищ и автомобилей до компов.
Автомат — единственное что имеет право на надёжность.
Просто сейчас в мире всё смешное и одноразовое — от жилищ и автомобилей до компов.
Автомат — единственное что имеет право на надёжность.
По своему опыту обычный бизнес не спешит внедрять сырые технологии, если нет уверенности, что они вот-вот повзрослеют. Если только его не введут в заблуждение технари, которым хочется попробовать что-то новое и модное.
По своему опыту обычный бизнес не спешит внедрять сырые технологии, если нет уверенности, что они вот-вот повзрослеют. Если только его не введут в заблуждение технари, которым хочется попробовать что-то новое и модное.
Тесла! Электромобили?
Это не обычный, а инновационный бизнес. И он не внедряет, а создаёт эти технологии.
VolCh > И он не внедряет, а создаёт эти технологии.
Электромобиль был создан более 100 лет тому назад.
Сейчас идёт попытка внедрить эту супер-старую технологию.
Электромобиль был создан более 100 лет тому назад.
Сейчас идёт попытка внедрить эту супер-старую технологию.
Если посмотреть на новейшие языки, в частности Java 8, Kotlin, Rust — то видно, что там ООП уже вперемешку с функциональным стилем. Выбирай что хочешь.
IMHO, вся проблема в том, что хипстеры проникли в среду программистов. :)
Ну и в рекламе, как уже высказывались выше.
Ну и в рекламе, как уже высказывались выше.
Я согласен, в этих словах есть доля правды. Поэтому я и не стремился изучить руби, например. Разницы особой нет, пхп позволяет писать прекрасно работающие проекты, так зачем мне тратить время на другой язык, который даст мне то же самое?)
Важнее потратить время на множество других более важных дел. Джс изучить более глубоко. Пхп изучить более глубоко. Изучить методологии, через которые получается писать модульный и качественный код. Изучить более глубоко Linux и его подсистемы, прокачать опыт системного администрирования. Это все по большей части изобрели еще в прошлом веке, и это то, что очень редко изучают современные программисты, потому что это им не так интересно, как изучать всякие свистульки. Они часто даже не понимают, что качество достигается не свистульками, а терпением, старательностью, порядком, правильными принципами разработки.
Но также с другой стороны, утверждать, что в мире программирования закончились важные изобретения — тоже неверно. Много чего интересного люди делают. Следить за развитием технологий всё равно важно, это немного бредовое утверждение, что технологии развиваться больше не будут. Будут, скорее всего, куда они денутся..
saggid > зучить более глубоко Linux и его подсистемы, прокачать опыт системного администрирования. Это все по большей части изобрели еще в прошлом веке, и это то, что очень редко изучают современные программисты, потому что это им не так интересно, как изучать всякие свистульки.
Дело в цене. За это мало в среднем по рынку платят.
Бывает что развитие (в том числе и технологическое) и останавливается. Это не раз было в Истории человечества.
Дело в цене. За это мало в среднем по рынку платят.
это немного бредовое утверждение, что технологии развиваться больше не будут. Будут, скорее всего, куда они денутся..
Бывает что развитие (в том числе и технологическое) и останавливается. Это не раз было в Истории человечества.
Как по моему мнению, вся статья может быть сведена к двум пунктам.
1. Вы хотите зарабатывать работая в большом светлом офисе. Тогда помимо знания java Вам необходимо знать стек новых популярных языков, фреймворков и технологий. Причина банальна Ваш идеальный работодатель выберет самое популярное словечко и заставит программировать именно на нем. Это минус такого работодателя (выбирает язык для написания нового продукта на основе каких-то статеек о новом, модном и классном). Плюсом будет то, что зарплата платится несообразно Вашему труду (тупо платит много, за Ваш умный вид на рабочем месте). Типа зачем зарабатывать хорошо, будучи хорошим специалистом по java, если можно зарабатывать прекрасно — умея лишь бы как нибудь писать на go, rust, scala и прочее?
2. Вы пишите для себя. Вам надо выбрать свой язык, они во многом одинаковые, для своих платформ. Прекрасно, если Вы этот язык уже заранее выучили (делфи, разумеется).
1. Вы хотите зарабатывать работая в большом светлом офисе. Тогда помимо знания java Вам необходимо знать стек новых популярных языков, фреймворков и технологий. Причина банальна Ваш идеальный работодатель выберет самое популярное словечко и заставит программировать именно на нем. Это минус такого работодателя (выбирает язык для написания нового продукта на основе каких-то статеек о новом, модном и классном). Плюсом будет то, что зарплата платится несообразно Вашему труду (тупо платит много, за Ваш умный вид на рабочем месте). Типа зачем зарабатывать хорошо, будучи хорошим специалистом по java, если можно зарабатывать прекрасно — умея лишь бы как нибудь писать на go, rust, scala и прочее?
2. Вы пишите для себя. Вам надо выбрать свой язык, они во многом одинаковые, для своих платформ. Прекрасно, если Вы этот язык уже заранее выучили (делфи, разумеется).
AlexPu немного не так, если работодатель не идеален (не идиот по вашему), то вы будете писать на языке ранее одобренный специалистами для данной задачи и требовать с вас будут за троих, так как умеют оценивать эффективность труда программиста, а платить как одному, так как умеют считать и мотивировать на труд не только баблом и выговарами. Вкратце, специалист по java с хорошей зарплатой.
Вы лично как хотите зарабатывать хорошо или отлично?
Вы лично как хотите зарабатывать хорошо или отлично?
UFO just landed and posted this here
> Идеальный работодатель конечно должен быть идиотом!
Глупость какая-то. Которую придумываете Вы. Возможно, Вам просто надо кого-то назвать идиотом, чтобы потом доказать, что работодатели не идиоты, а я не удался…
Или я неудачник, у меня кругом полно примеров, когда менеджер всегда знает какую надо выбрать СУДБ и язык для проекта и никогда не может ответить почему надо выбрать именно эти варианты. При этом он понимает, что если программист задает вопрос «боже, а почему надо делать именно на rust или nosql» — то ловить с программиста как с увлеченного специалиста уже нечего. Но доказать этого не может.
Глупость какая-то. Которую придумываете Вы. Возможно, Вам просто надо кого-то назвать идиотом, чтобы потом доказать, что работодатели не идиоты, а я не удался…
Или я неудачник, у меня кругом полно примеров, когда менеджер всегда знает какую надо выбрать СУДБ и язык для проекта и никогда не может ответить почему надо выбрать именно эти варианты. При этом он понимает, что если программист задает вопрос «боже, а почему надо делать именно на rust или nosql» — то ловить с программиста как с увлеченного специалиста уже нечего. Но доказать этого не может.
По поводу «умеют считать и мотивировать на труд не только баблом и выговарами.» — мне просто интересно, а какую еще мотивацию вы бы лично хотели для себя лично? Ежедневная порция мороженного? Экскурсии в музей?
Эстетическое удовольствие от написание кода. И — удивление — мне за это ещё и деньги платят?
Приветствую. Прочитал Ваш интересный рассказ про себя и свои приключения, и мне он показался даже интересней, чем сама перевод. Но как и коллега выше, у меня после всех ваших описаний, остался один единственный вопрос — как находясь в текущем моменте вы так удачно предсказывали выстрелы? Вы упомянули, что в 98-ом вам дельфи уже показалось проигрышной, а Java — перспективной. И вы упомянули распределенные системы. Не могли бы подробнее этот момент осветить, т.е. вот находясь в 98-ом, что вы понимали под распределенными системами? Чем это было тогда? Я почему так интересуюсь активно — я сам был в таком же положении как и вы, но только чуть позже, и я, находясь в том времени, как вам сказать — даже не понял, вообще, что технология java — живая. Первый коммерческий проект я сворганил на аплетах JSP, городил обычное приложение для торговли с веб-мордой. Деньги за работу я получил, но продуктом пользоваться не смогли, т.к. выяснилось, что для сносной работы ему требовались минимум 3-ех мегабитный канал (анлимный естественно). В том времени, в областном центре, где я жил, у клиента был мегабит. Поднять скорость до трех, в месячном эквиваленте, означало фантастические деньги. При этом, халтурить по фрилансу, используя то что я знал, это JSP и swing, опять же в том времени, не удавалось по той же самой причине — в рунете заказов не было на эти технологии, в забугорье — заказы были, но на уровне — несколько ином для моих скилов. Год где-то помыковшись, я решил уйти в разработку мобильных приложений. Это было время только только выхода 9-ого симбиана, еще даже кирпичей не было в железе, его поддерживающих. Но в JBuilder был BMS, который в свою очередь поддерживал нативно NDS, и соответственно, не имея железяки, можно было пилить приложения, ожидая чуть-чуть выхода первых кирпичей в железе, к которым кстати, был обещан официальный маркет! Ну типа — прямо вот пару месяцев, и все. И можно будет свои приложения официально продавать на весь мир! Это вроде бы была середина 2004 года. А первый симбиан-дивайс я увидел живой в середине 2006. Причем я даже не смог его купить, т.к. он стоил как подержанный неплохой автомобиль :) При этом, в 2004 параллельно со стеком JB-BMS-NDS, был параллельный стек разработки Qt-C++, кстати, нативный и на нем неплохо писались всякие АРМы для разных других симбиан-девайсов. Но почему, тогда мне показалось — не хипстерским этом. Как-то мой первый путь казался более каким-то прямо сверх-технологичным, с учетом обещанного маркета + я как бэ javа уже освоил. И в итоге, после таких, получается трех-летних блужданий из огня да в полымя, я пришел к выводу на тот момент, что сама платформа java — мертвая :) Т.е. я не увидел, находясь в том времени и том географическом регионе, каких-то реальных мест, где эта технология могла бы просто обеспечить стабильных хлеб. Но это были нулевые года, у вас же подобные потуги были на пяток лет раньше. И именно поэтому, я именно только сквозь призму своего опыта, и спрашиваю вас — КАК? Как вы так умудрялись всегда снимать сливки, при зародышном состоянии самой технологии?
> Как вы так умудрялись всегда снимать сливки, при зародышном состоянии самой технологии?
Он разве тут где-то выкладывал архив выписок со своего банковского счета? Есть старый анекдот, как раз про подобные ситуации:
— Доктор, у меня с женщинами совсем не ладится, что посоветуете?
— А сколько вам лет?
— Восемьдесят.
— Ну так что же вы хотите?
— Но мои друзья такого же возраста, и говорят, что у них всё в порядке.
— Ну так и вы тоже говорите.
Он разве тут где-то выкладывал архив выписок со своего банковского счета? Есть старый анекдот, как раз про подобные ситуации:
— Доктор, у меня с женщинами совсем не ладится, что посоветуете?
— А сколько вам лет?
— Восемьдесят.
— Ну так что же вы хотите?
— Но мои друзья такого же возраста, и говорят, что у них всё в порядке.
— Ну так и вы тоже говорите.
Хм. Пока в треде обвинения по делу AlexPu собраны следующие моменты:
— не знает бест практикс по микросервисам;
— ему пояснено (кстати, Вами), что программист должен убеждать клиента опять же в том, что ему (клиенту), что-то впарили и то, что впарили — это не торт. Опять же торт/не торт решает сам программист на основании в т.ч. и своей профессиональной совести;
— ему вменено, что «Впаривать дорогую технологию — мошеничество», хотя он не давал суммовых оценок чего либо, кроме своей прибавки на новом месте работы.
— ему озвучили догму, что «Программист, создающий программы ради денег — не программист. Художник, рисующий за деньги — не художник», поэтому его оппоненты поясняют «Если ко мне приходит человек, в котором я заподозрю потребителя — его не стоит брать на работу. Потому что он банально уйдет к другим, стоит ему предложить чуть больше денег»;
— Ему объяснили в чем разница между «работать за деньги» и «работать ради денег». Постулировали тезис, что «деньги — это компенсация, а не самоцель работы». Опять же «Получать деньги за то, чем нравится заниматься — это одно, работать исключительно ради денег — другое»;
— ну и дальше совсем трешово: «Мы получаем компенсацию», «мы не судим, а констатируем», «с такими коллегами в одной команде нам работать не очень комфортно». И вот эти «мы» так поясняют, почему ж все так: «я делаю так, чтобы в команде не оставались люди, ориентированные на максимизацию зарплаты, особенно путём обучения «дорогим» технологиям в рабочем процессе. Обучаться в рабочем процессе нужно тем технологиям, которые нужны компании, а не выгодны работнику, который настоит на внедрение «дорогой» технологии (а то и начнёт внедрение втихаря), изучит её во время этого внедрения, а потом уйдёт туда, где больше платят за резюме со строчкой с этой технологией».
На все эти догмы, постулаты, аксиомы и тезисы, AlexPu ответил или пытался ответить. Суд, думаю, еще вынесет свой окончательный вердикт, но мне в этом деле интересны не попытки образумить, доказать, или наоборот опровергнуть правильность/ошибочность суждений AlexPu. Мне интересен другой фундаментальный вопрос, который я задал в своем первом вопросе, т.к. прочитав все ответы к текущему моменту, я так и не понял, как находясь в текущем моменте, можно ставить на технологию, которая находится при первом же ознакомлении, в состоянии зародыша. Вы, усомнились в самом факте того, что г-ну AlexPu, удалось снять сливки, т.е. подвергаете сомнению всю историю г-на AlexPu, из-за которой собственно и появилось дело. Со своей стороны отмечу, что я не подвергаю сомнению его историю и верю, что ему действительно удалось сделать все то, о чем он нам, кстати любезно, рассказал. И на основании этой веры, мне и хотелось бы услышать какие-то более развернутые контекстные ответы. Но я полагаю, что холивар «обвинения vs защита», который во всю бушует выше, даже не дал г-ну AlexPu спуститься ниже, чтобы прочесть чуточку более :) Но я еще надеюсь привлечь внимание!
— не знает бест практикс по микросервисам;
— ему пояснено (кстати, Вами), что программист должен убеждать клиента опять же в том, что ему (клиенту), что-то впарили и то, что впарили — это не торт. Опять же торт/не торт решает сам программист на основании в т.ч. и своей профессиональной совести;
— ему вменено, что «Впаривать дорогую технологию — мошеничество», хотя он не давал суммовых оценок чего либо, кроме своей прибавки на новом месте работы.
— ему озвучили догму, что «Программист, создающий программы ради денег — не программист. Художник, рисующий за деньги — не художник», поэтому его оппоненты поясняют «Если ко мне приходит человек, в котором я заподозрю потребителя — его не стоит брать на работу. Потому что он банально уйдет к другим, стоит ему предложить чуть больше денег»;
— Ему объяснили в чем разница между «работать за деньги» и «работать ради денег». Постулировали тезис, что «деньги — это компенсация, а не самоцель работы». Опять же «Получать деньги за то, чем нравится заниматься — это одно, работать исключительно ради денег — другое»;
— ну и дальше совсем трешово: «Мы получаем компенсацию», «мы не судим, а констатируем», «с такими коллегами в одной команде нам работать не очень комфортно». И вот эти «мы» так поясняют, почему ж все так: «я делаю так, чтобы в команде не оставались люди, ориентированные на максимизацию зарплаты, особенно путём обучения «дорогим» технологиям в рабочем процессе. Обучаться в рабочем процессе нужно тем технологиям, которые нужны компании, а не выгодны работнику, который настоит на внедрение «дорогой» технологии (а то и начнёт внедрение втихаря), изучит её во время этого внедрения, а потом уйдёт туда, где больше платят за резюме со строчкой с этой технологией».
На все эти догмы, постулаты, аксиомы и тезисы, AlexPu ответил или пытался ответить. Суд, думаю, еще вынесет свой окончательный вердикт, но мне в этом деле интересны не попытки образумить, доказать, или наоборот опровергнуть правильность/ошибочность суждений AlexPu. Мне интересен другой фундаментальный вопрос, который я задал в своем первом вопросе, т.к. прочитав все ответы к текущему моменту, я так и не понял, как находясь в текущем моменте, можно ставить на технологию, которая находится при первом же ознакомлении, в состоянии зародыша. Вы, усомнились в самом факте того, что г-ну AlexPu, удалось снять сливки, т.е. подвергаете сомнению всю историю г-на AlexPu, из-за которой собственно и появилось дело. Со своей стороны отмечу, что я не подвергаю сомнению его историю и верю, что ему действительно удалось сделать все то, о чем он нам, кстати любезно, рассказал. И на основании этой веры, мне и хотелось бы услышать какие-то более развернутые контекстные ответы. Но я полагаю, что холивар «обвинения vs защита», который во всю бушует выше, даже не дал г-ну AlexPu спуститься ниже, чтобы прочесть чуточку более :) Но я еще надеюсь привлечь внимание!
OksikOneC > прочитав все ответы к текущему моменту, я так и не понял, как находясь в текущем моменте, можно ставить на технологию, которая находится при первом же ознакомлении, в состоянии зародыша.
AlexPu уже ответил выше. Кратко: Он запрыгивает в поезд не на стадии зародыша, а на стадии когда поезд начинает уверенно набирать скорость.
Да, он всегда немного запаздывает — но он не играет в рулетку и он не Оракул.
Но, обычно(!) ему хватает того, что он не первый и не третий и даже не в десятке первых — но и не в последней тысячи.
Почему обычно? — потому что он также участвует в стартапах — то есть всё же у него есть желание оказаться в тройке призёров.
Имхо, конечно, имхо.
AlexPu уже ответил выше. Кратко: Он запрыгивает в поезд не на стадии зародыша, а на стадии когда поезд начинает уверенно набирать скорость.
Да, он всегда немного запаздывает — но он не играет в рулетку и он не Оракул.
Но, обычно(!) ему хватает того, что он не первый и не третий и даже не в десятке первых — но и не в последней тысячи.
Почему обычно? — потому что он также участвует в стартапах — то есть всё же у него есть желание оказаться в тройке призёров.
Имхо, конечно, имхо.
UFO just landed and posted this here
извините, пожалуйста, за опечатку. Выговор.
UFO just landed and posted this here
Маслобойка