Ну так о том и речь, что кросс-IDE особо и не нужны. Вон под .NET так же пишут все спокойно в Visual Studio под виндой, а запускают хоть на линуксе, хоть на макоси.
Свои нюансы при кроссплатформенной разработке безусловно есть, но это не то, что можно решить переносом IDE под другие ОС.
Вы как-то странно себе кроссплатформенную разработку представляете. По-вашему, на Java или Go каком-нибудь тоже надо 3 разных компа, чтобы скомпилировать программу под разные операционки?
Есть такая штука как кросс-компиляция, благодаря которой вы просто компилируете программу под разные ОС, независимо от ОС разработчика. А что-то там супер-пупер платформоспецифичное отлаживать нужно крайне-крайне редко. Это явно не часть повседневной работы.
На мой взгляд, современный язык должен иметь кросс-платформенный компилятор/интерпретатор. Вокруг него должны устраивать конференции или ещё какие-либо мероприятия. Ну и для позиционирования у него должен быть сайт в современном дизайне. Плюс удобный тулинг и поддержка со стороны IDE или LSP хотя бы.
Pharo этим критериям удовлетворяет, Delphi тем более, а вот по PL/I мне сходу ничего кроме пары сайтов аля "привет из 90-х" (
Почему сразу тупыми? Это обычная фаза бурного роста, когда есть 100500 разных способов делать или обсуждать одно и то же. Собственно, ISO основали в 1947 году, СИ (которая система единиц, а не язык) приняли в 1960 году и т.д. и т.п. Большинству инженерных стандартов существенно меньше 100 лет, это факт.
Строя очередной завод или корабль (как вершину технологического прогресса)
Прям цитата из рекламного буклета Титаника? ?
Я бы был благодарен за конкретику
Я ж указал названия нескольких книг. Я не думаю, что пытаться их пересказать в паре абзацев - хорошая идея.
а все равно как-то получилось и неплохо. И ведь не только у меня.
Я думаю, вы себе и всем нам льстите. Скажите ещё, что ни одна из команд, которыми вы управляли, ни разу не роняла прод))
Просто в IT пока что низкий уровень качества воспринимается как должное, отсюда и такая самонадеянность, что вы сами с усами.
Ну, отчасти вы правы. Человечество давно освоило командную работу, однако это по большей части касалось физического труда. Интеллектуальные команды инженеров, архитекторов и т.д. появились не так уж давно в исторических масштабах. Можно сказать, что ещё 100 лет назад никакой теоретической базы и стандартов не было на этот счёт.
А IT - отрасль ещё более молодая и со своей спецификой. Я бы не был так уверен, что любой прораб или капитан ВС сможет командой разработки руководить. Скорее наоборот, потому что книги, которые вы отрицаете, как раз и описывают почему тысячелетние наработки в стройке и армии не работают в IT. Да, они создают иллюзию понимания, как можно улучшить ситуацию, но в итоге всё сводится только к фрустрации из-за того, что стало только хуже.
Я вообще сторонник выбирать языки исходя из предметной области, которая наиболее интересна. Но в начале этого треда просили список высокооплачиваемых. C++ к таким языкам не относится. При этом безусловно отдельно взятый человек может на любом стеке много зарабатывать, хоть на Delphi, хоть на Smalltalk, хоть на Common Lisp, хоть на C++.
Я не про другие специальности. Вы читали книги, которые я выше упоминал? Они все для программистов, ну и отчасти для тимлидов. При этом они совсем не про код, но чтобы стать сеньором таких книг по сути надо прочитать чуть ли не больше, чем по технической части.
Ну, понимать разработку, как исключительно работу с программным кодом, тоже не совсем верно. Так было, когда можно было в одиночку написать какое-то ПО и оно могло стать коммерчески успешным. Сейчас всё уже сложнее.
Ну, тут придётся тогда с определениями сначала определиться)
Что считать гуманитарными аспектами, а что - нет. Если под этим подразумевать только то, что касается изучения общества, человека и культуры, то этого действительно не много. Тем не менее «Человеческий фактор. Успешные проекты и команды», «Мифический человеко-месяц», «Как пасти котов», «Психбольница в руках пациентов» и ещё множество классических книг по разработке как раз про это.
Ну, тут от должности зависит. Лид вообще 5% времени пишет код, 15% читает, а остальные 80% вообще другими делами занят))
Чтение кода само по себе не особо гуманитарное занятие. А вот написание и чтение всяких ADR, постановок, соглашений и прочей документации - очень даже.
В целом согласен с посылом статьи. Я уже не первый год желающим ворваться в IT рекомендую настраиваться на 3-4 года обучения и целиться сразу в мидла.
Добавлю ещё, что выгоднее выбирать не самые хайповые языки. Например, на Python и JS уже деваться некуда от новичков, их тупо раз в 10 больше, чем надо ?
Тут автор ещё несколько не в теме. Сами ЯП к гуманитарной части отношения не имеют, а вот отсутствие формализма при решении даже типовых задач как раз дают гуманитарный аспект.
На более высоких позициях, чем джун и мидл, уйма времени уходит на обсуждение, как с бизнес-заказчиками и аналитиками, так и с другими программистами и соседними департаментами (devops, sre, dataops, ml)
Самый тупой критерий, по которому можно выбирать ЯП, - это популярность. У разных языков разные области применения и задачи, под которые они подходят наилучшим образом. Молоток более востребован, чем бензопила, но это не значит, что надо спиливать дерево молотками. Поэтому все эти рейтинги популярных/востребованных языков чисто на недалёких вайтишников рассчитаны.
Ну так о том и речь, что кросс-IDE особо и не нужны. Вон под .NET так же пишут все спокойно в Visual Studio под виндой, а запускают хоть на линуксе, хоть на макоси.
Свои нюансы при кроссплатформенной разработке безусловно есть, но это не то, что можно решить переносом IDE под другие ОС.
Вы как-то странно себе кроссплатформенную разработку представляете. По-вашему, на Java или Go каком-нибудь тоже надо 3 разных компа, чтобы скомпилировать программу под разные операционки?
Есть такая штука как кросс-компиляция, благодаря которой вы просто компилируете программу под разные ОС, независимо от ОС разработчика. А что-то там супер-пупер платформоспецифичное отлаживать нужно крайне-крайне редко. Это явно не часть повседневной работы.
На мой взгляд, современный язык должен иметь кросс-платформенный компилятор/интерпретатор. Вокруг него должны устраивать конференции или ещё какие-либо мероприятия. Ну и для позиционирования у него должен быть сайт в современном дизайне. Плюс удобный тулинг и поддержка со стороны IDE или LSP хотя бы.
Pharo этим критериям удовлетворяет, Delphi тем более, а вот по PL/I мне сходу ничего кроме пары сайтов аля "привет из 90-х" (
"Pharo is an open source, cross-platform implementation of the classic Smalltalk-80 programming language and runtime"
https://days.pharo.org/
https://newcomers.pharo.org/
Кто и как оценивал объёмы написанного кода? Так то на Fortran тоже дофига чего написано, плюс он ещё и старше.
Автор в статье упомянул, что Fortran и Lisp вполне живы и хорошо себя чувствуют.
Хотя в этом контексте не очень понятно почему он решил похоронить Delphi (он же Object Pascal) и Pharo (он же Smalltalk)
Почему сразу тупыми? Это обычная фаза бурного роста, когда есть 100500 разных способов делать или обсуждать одно и то же. Собственно, ISO основали в 1947 году, СИ (которая система единиц, а не язык) приняли в 1960 году и т.д. и т.п. Большинству инженерных стандартов существенно меньше 100 лет, это факт.
Прям цитата из рекламного буклета Титаника? ?
Я ж указал названия нескольких книг. Я не думаю, что пытаться их пересказать в паре абзацев - хорошая идея.
Я думаю, вы себе и всем нам льстите. Скажите ещё, что ни одна из команд, которыми вы управляли, ни разу не роняла прод))
Просто в IT пока что низкий уровень качества воспринимается как должное, отсюда и такая самонадеянность, что вы сами с усами.
Ну, отчасти вы правы. Человечество давно освоило командную работу, однако это по большей части касалось физического труда. Интеллектуальные команды инженеров, архитекторов и т.д. появились не так уж давно в исторических масштабах. Можно сказать, что ещё 100 лет назад никакой теоретической базы и стандартов не было на этот счёт.
А IT - отрасль ещё более молодая и со своей спецификой. Я бы не был так уверен, что любой прораб или капитан ВС сможет командой разработки руководить. Скорее наоборот, потому что книги, которые вы отрицаете, как раз и описывают почему тысячелетние наработки в стройке и армии не работают в IT. Да, они создают иллюзию понимания, как можно улучшить ситуацию, но в итоге всё сводится только к фрустрации из-за того, что стало только хуже.
Ну что ж, соберу статистику как-нибудь. Буду сеньоров на собесах спрашивать.
А вообще, почитайте. То, что вы не интересовались этими темами, это фигово. И Кнут тут не спасёт, это про другие компетенции.
Я вообще сторонник выбирать языки исходя из предметной области, которая наиболее интересна. Но в начале этого треда просили список высокооплачиваемых. C++ к таким языкам не относится. При этом безусловно отдельно взятый человек может на любом стеке много зарабатывать, хоть на Delphi, хоть на Smalltalk, хоть на Common Lisp, хоть на C++.
Я не про другие специальности. Вы читали книги, которые я выше упоминал? Они все для программистов, ну и отчасти для тимлидов. При этом они совсем не про код, но чтобы стать сеньором таких книг по сути надо прочитать чуть ли не больше, чем по технической части.
Ну, понимать разработку, как исключительно работу с программным кодом, тоже не совсем верно. Так было, когда можно было в одиночку написать какое-то ПО и оно могло стать коммерчески успешным. Сейчас всё уже сложнее.
Ну, в любой выборке есть выбросы. Вопрос вероятности попадания в этот положительный выброс.
Недавно Habr Career публиковали.
Вот Top-5 самых высокооплачиваемых:
Objective-С, Scala, Swift, Elixir, Ruby
C++ по их же исследованию ценится в среднем примерно в 2 раза ниже, чем эти 5.
Ну, тут придётся тогда с определениями сначала определиться)
Что считать гуманитарными аспектами, а что - нет. Если под этим подразумевать только то, что касается изучения общества, человека и культуры, то этого действительно не много. Тем не менее «Человеческий фактор. Успешные проекты и команды», «Мифический человеко-месяц», «Как пасти котов», «Психбольница в руках пациентов» и ещё множество классических книг по разработке как раз про это.
Ну, тут от должности зависит. Лид вообще 5% времени пишет код, 15% читает, а остальные 80% вообще другими делами занят))
Чтение кода само по себе не особо гуманитарное занятие. А вот написание и чтение всяких ADR, постановок, соглашений и прочей документации - очень даже.
В целом согласен с посылом статьи. Я уже не первый год желающим ворваться в IT рекомендую настраиваться на 3-4 года обучения и целиться сразу в мидла.
Добавлю ещё, что выгоднее выбирать не самые хайповые языки. Например, на Python и JS уже деваться некуда от новичков, их тупо раз в 10 больше, чем надо ?
Тут автор ещё несколько не в теме. Сами ЯП к гуманитарной части отношения не имеют, а вот отсутствие формализма при решении даже типовых задач как раз дают гуманитарный аспект.
На более высоких позициях, чем джун и мидл, уйма времени уходит на обсуждение, как с бизнес-заказчиками и аналитиками, так и с другими программистами и соседними департаментами (devops, sre, dataops, ml)
Маск похерил Твиттер)
Самый тупой критерий, по которому можно выбирать ЯП, - это популярность. У разных языков разные области применения и задачи, под которые они подходят наилучшим образом. Молоток более востребован, чем бензопила, но это не значит, что надо спиливать дерево молотками. Поэтому все эти рейтинги популярных/востребованных языков чисто на недалёких вайтишников рассчитаны.
Ну, значит, у нас с вами разные выборки знакомых дизайнеров.