Концепция X as a code наверняка надолго переживет докер.
В целом идея говорить компьютеру не как делать, а что ожидается не нова, но мало где получила широкое распространение кроме SQL из-за технической сложности реализации таких инструментов. Сейчас мы как раз подошли к тому уровню, когда задачи такой сложности вполне по зубам.
Вполне вероятно, что императивное программирование, про которое вы говорите
но не код в контекте того, что я пишу
отойдет на задний план как более низкоуровневое, чем оперирование контейнерами и конфигурациями. Уже сейчас есть четкая тенденция к реализации систем через композицию контейнеров, как раньше была композиция классов. Уже сейчас нормально вместо загрузки библиотеки в приложение запускать готовый контейнер сайдкаром для тех же задач.
По поводу переменных — если их делать много, но для каждой делать вменяемое значение по-умолчанию, вшитое куда-нибудь в программу или дефолтный конфиг файл, то внезапно переменных оказывается мало, а количество от прод. окружения к девелоперскому и вовсе стремится к нулю.
Что касается X as a code — это вполне себе код. Разнца только в том, что это декларативный код, а не императивный, как большинство ЯП.
И IDE в этом случае делает то же, что и в любом другом — пытается эмулировать воспроизведение этого кода его интерпретатором/компилятором, обычно за счет анализа.
При этом будь то код, написанный на питоне, будь то С++, будть то докерфайл или куб конфиг, для IDE разницы между ними намного меньше, чем для программиста.
Если вопрос в том, что не все IDE пока умеют хорошо с этим справляться — вопрос времени и установки плагинов.
Если вопрос в том, что IDE не может проанализировать, что там внутри контейнера за этими переменными скрывается — то это общая интеграционная проблема, у вас и в коде приложения ни одна IDE не покажет, что конфиг подключения к внешней системе как-то невалиден.
Скорее всего это исправится со временем, когда появятся стандарты для описания фасада контейнера в явном виде (сейчас можно только список ENV прописать, но это больше хороший тон, нежели стандарт).
Вроде как сегодня каждый выбирает, где и как ему работать, и какой процент отдавать обертке в виде аутсорса/аутстафа, если он не хочет/не может работать напрямую.
Это не проблема ERP, это проблема того, что ERP и реальные бизнес-процессы живут в параллельных мирах. И приходится натягивать одно на другое так или иначе.
Тоже зависит. Алгоритмы важны, но их тоже нужно правильно преподавать. Если они даются в виде "мы выучим за полгода 10 популярных алгоритмов, которые нужно зазубрить на экзамен в виде блок-схемы, и которые вам больше не пригодятся в остальном курсе ближайшие 4 года", то толку в этом немного, тупо забудется сразу же после экзамена.
Тут все начали про то "зачем нужен ВУЗ" и что "а ВУЗы на самом деле для другого", но я позволю себе добавить свой комментарий.
Конечно, современное программирование — это уже давно не узкая дисциплина, а широкое направление, где есть и инжерены, и ученые, и "формошлепы" с низкой квалификацией. И вполне логично, что первых может готовить условный политех, вторых условный универ, третих — ПТУ (колледж).
Но в реальности никто никого из перечисленных специалистов не готовит.
В ВУЗах по CS учат кое-как — то строить схемы, то изучать ассемблер, то писать компилятор на C, и прочее. Общаться со студентами таких факультетов тяжело — а приходилось общаться с разными — от воронежского ВГУ до Иннополиса. Везде похожие проблемы — высокое мнение о своем образовании, трудность думать вне забитой им в головы профессорами концепции (вроде С — лучший язык, все можно написать на С, потому что программа должна быть оптимизированной), и почти полная неспособность работать в реальных проектах.
Конечно, программистам нужны и ученые, которые будут придумывать новые криптоалгоритмы и более эффективные деревья поиска в БД. Но большинство специальностей, которым обучают в ВУЗах — прикладные, и говорить, что, мол, ВУЗ не для этого — наивно. Если ВУЗ не для этого, то почему в программе курса и на дне открытых дверей ВУЗ не говорит, что вы станете крутым ученым в CS (не станете), а говорит, что станете программистом и будете заколачивать бабки?
На данный момент, все, чему может реально научить ВУЗ программиста (говорю про большинство, возможно есть прям очень крутые программы в отдельных ВУЗ) — это умение ориентироваться в потоке информации, искать ее и изучать, а также хорошую базу. Но базу не вида "я знаю, как построить блок-схему", а вида " понимаю устройство БД, понимаю работу CPU с данными, и знаю, как это использовать в своей работе". А также "я знаю, как строить современные распределенные системы, как управлять потоками данных в ней, и я могу прийти в компанию и задизайнить нужное решение, потому что меня 5 лет учили, как это правильно делать."
В реальности же выпускника от CS от не выпускника CS в большинстве случаев отличает знание ассемблера и C, ну и более упорядоченные базовые знания, но кроме этого куча мусора и вбитых в голову суждений професоров, писавших реальные программы лет 30 назад в последний раз.
Не советую указывать Software Engineer или нечто подобное, вызывает раздражение и дополнительные вопросы
Вызывает раздражение у кого? Моя профессия называется Software Engineer, мне что надо писать вместо этого "байт жокей"? Нигде не было вопросов или раздражения по этому поводу. Причем ни в иностранных, ни в российских компаниях, а CV я везде на английском посылаю.
Лена, спасибо за статью. Мне как раз предстоит рефакторинг сервиса с подобными проблемами, и я думаю, как лучше за это взяться. Теперь есть хорошее понимание
Да вроде не такое плохое сравнение. Два языка вообще невозможно сравнивать изнутри, потому что в них всегда разные подходы, и найдется тот, кто скажет: "вы просто не умеете пользоваться X", и будет прав. А вот сравнивая извне (память, быстродействие и пр.) — вполне можно.
Если бы я разрабатывал программы только для Linux, или если бы Linux была бы операционной системой, представляющей для меня наибольший интерес.
Вот это очень странный поинт, учитывая кросс-компиляцию Го.
В целом почти все пункты итогового сравнения относятся к обоим ЯП, разве что го действительно проще для понимания, а раст действительно лучше по памяти.
Так ему не нужно знать, куда лететь, ему главное дрон ловить. Сориентировать на цель вне поля действия пушки, а дальше ему команды оператора не нужны.
Зачем грузики — есть же дрон, который ловит дроны
После вашего комментария выглядит еще хуже, если честно
Поделитесь, а как вы организуете "Нереальный нетворкинг (250 человек на одной площадке)" в условиях пандемии?
Я вот опасаюсь митап на 15 человек собрать, есть какие-то эффективные меры безопасности?
UPD: вопрос, очевидно, не составителям дайджеста, а оргам (которые, возможно, прочитают сообщение), а также ко всем, у кого найдется ответ.
Концепция X as a code наверняка надолго переживет докер.
В целом идея говорить компьютеру не как делать, а что ожидается не нова, но мало где получила широкое распространение кроме SQL из-за технической сложности реализации таких инструментов. Сейчас мы как раз подошли к тому уровню, когда задачи такой сложности вполне по зубам.
Вполне вероятно, что императивное программирование, про которое вы говорите
Зашел почитать про кофе, а тут про какие-то нейронки :)
По поводу переменных — если их делать много, но для каждой делать вменяемое значение по-умолчанию, вшитое куда-нибудь в программу или дефолтный конфиг файл, то внезапно переменных оказывается мало, а количество от прод. окружения к девелоперскому и вовсе стремится к нулю.
Что касается X as a code — это вполне себе код. Разнца только в том, что это декларативный код, а не императивный, как большинство ЯП.
И IDE в этом случае делает то же, что и в любом другом — пытается эмулировать воспроизведение этого кода его интерпретатором/компилятором, обычно за счет анализа.
При этом будь то код, написанный на питоне, будь то С++, будть то докерфайл или куб конфиг, для IDE разницы между ними намного меньше, чем для программиста.
Если вопрос в том, что не все IDE пока умеют хорошо с этим справляться — вопрос времени и установки плагинов.
Если вопрос в том, что IDE не может проанализировать, что там внутри контейнера за этими переменными скрывается — то это общая интеграционная проблема, у вас и в коде приложения ни одна IDE не покажет, что конфиг подключения к внешней системе как-то невалиден.
Скорее всего это исправится со временем, когда появятся стандарты для описания фасада контейнера в явном виде (сейчас можно только список ENV прописать, но это больше хороший тон, нежели стандарт).
Спасибо, если когда-нибудь еще будет можно доехать до Барселоны — зайду попробовать.
Эмм… ну да
Зарплату плотют, нет?
Вроде как сегодня каждый выбирает, где и как ему работать, и какой процент отдавать обертке в виде аутсорса/аутстафа, если он не хочет/не может работать напрямую.
Это не проблема ERP, это проблема того, что ERP и реальные бизнес-процессы живут в параллельных мирах. И приходится натягивать одно на другое так или иначе.
Самый вкусный борщ ел в Армении, btw, в придорожном кафе "Батя".
Тоже зависит. Алгоритмы важны, но их тоже нужно правильно преподавать. Если они даются в виде "мы выучим за полгода 10 популярных алгоритмов, которые нужно зазубрить на экзамен в виде блок-схемы, и которые вам больше не пригодятся в остальном курсе ближайшие 4 года", то толку в этом немного, тупо забудется сразу же после экзамена.
Тут все начали про то "зачем нужен ВУЗ" и что "а ВУЗы на самом деле для другого", но я позволю себе добавить свой комментарий.
Конечно, современное программирование — это уже давно не узкая дисциплина, а широкое направление, где есть и инжерены, и ученые, и "формошлепы" с низкой квалификацией. И вполне логично, что первых может готовить условный политех, вторых условный универ, третих — ПТУ (колледж).
Но в реальности никто никого из перечисленных специалистов не готовит.
В ВУЗах по CS учат кое-как — то строить схемы, то изучать ассемблер, то писать компилятор на C, и прочее. Общаться со студентами таких факультетов тяжело — а приходилось общаться с разными — от воронежского ВГУ до Иннополиса. Везде похожие проблемы — высокое мнение о своем образовании, трудность думать вне забитой им в головы профессорами концепции (вроде С — лучший язык, все можно написать на С, потому что программа должна быть оптимизированной), и почти полная неспособность работать в реальных проектах.
Конечно, программистам нужны и ученые, которые будут придумывать новые криптоалгоритмы и более эффективные деревья поиска в БД. Но большинство специальностей, которым обучают в ВУЗах — прикладные, и говорить, что, мол, ВУЗ не для этого — наивно. Если ВУЗ не для этого, то почему в программе курса и на дне открытых дверей ВУЗ не говорит, что вы станете крутым ученым в CS (не станете), а говорит, что станете программистом и будете заколачивать бабки?
На данный момент, все, чему может реально научить ВУЗ программиста (говорю про большинство, возможно есть прям очень крутые программы в отдельных ВУЗ) — это умение ориентироваться в потоке информации, искать ее и изучать, а также хорошую базу. Но базу не вида "я знаю, как построить блок-схему", а вида " понимаю устройство БД, понимаю работу CPU с данными, и знаю, как это использовать в своей работе". А также "я знаю, как строить современные распределенные системы, как управлять потоками данных в ней, и я могу прийти в компанию и задизайнить нужное решение, потому что меня 5 лет учили, как это правильно делать."
В реальности же выпускника от CS от не выпускника CS в большинстве случаев отличает знание ассемблера и C, ну и более упорядоченные базовые знания, но кроме этого куча мусора и вбитых в голову суждений професоров, писавших реальные программы лет 30 назад в последний раз.
Так и нужно было писать, что название в резюме должно быть 1:1 как название вакансии. А не "раздражает".
Вызывает раздражение у кого? Моя профессия называется Software Engineer, мне что надо писать вместо этого "байт жокей"? Нигде не было вопросов или раздражения по этому поводу. Причем ни в иностранных, ни в российских компаниях, а CV я везде на английском посылаю.
Лена, спасибо за статью. Мне как раз предстоит рефакторинг сервиса с подобными проблемами, и я думаю, как лучше за это взяться. Теперь есть хорошее понимание
Да вроде не такое плохое сравнение. Два языка вообще невозможно сравнивать изнутри, потому что в них всегда разные подходы, и найдется тот, кто скажет: "вы просто не умеете пользоваться X", и будет прав. А вот сравнивая извне (память, быстродействие и пр.) — вполне можно.
Возможно автор имеет cgo или особенности виндовой консоли в сравнении с линуксовым терминалом, но тогда не понятно, при чем тут го и раст.
Вот это очень странный поинт, учитывая кросс-компиляцию Го.
В целом почти все пункты итогового сравнения относятся к обоим ЯП, разве что го действительно проще для понимания, а раст действительно лучше по памяти.