Зачем мне работать в таком месте, когда я могу пойти туда, где коллеги будут тянуть не назад, а вперед.
Ну, это просто утрированный случай… На практике сложно найти работу, где все коллеги будут тянуть вперёд… Точнее, в начале карьеры несложно, но чем больше опыта, тем чаще приходится самому кого-то тянуть )))
Языки разные знать надо… Нельзя себя только одним типом языков ограничивать, даже джуниорам. Есть общие критерии, по которым можно представить себе язык даже если ты его никогда раньше не видел:
Если эти критерии сами по себе понятны, то от языка понадобится только синтаксис и стандартная библиотека. Для ещё более хорошего описания список критериев можно слегка расширить простыми пунктами типа: мутабельность данных, мономорфность операторов и т.п.
Иногда проекту как бы не нужна эта польза. Трудно ее приносить, когда вокруг тебя одни просиживающие штаны дядьки, сидящие на этом рабочем месте по N-дцать лет.
Так это, на мой взгляд, идеальная ситуация для проверки той самой состоятельности… Тут либо конформистское поведение возмёт верх, либо профессиональная этика. Всегда есть выбор: делать как коллеги (как начальство сказало, как «быстрее») или исходя из своего представления как должно быть. Иногда эти варианты могут и совпадать, но далеко не всегда.
Так что я думаю, что человек состоялся, как программист тогда, когда он сам для себе это решил
О, это ощущение обычно бывает ещё в первый год… потом, правда, у адекватных людей проходит на значительное время )
Платформы разные. Но в принципе платформ ограниченное количество (и гораздо меньше, чем языков). Так что, при желании, хоть в какой-то мере можно с каждой ознакомиться… Но это конечно уже не про джуниоров, да и вообще холиварная тема вглубь vs вширь.
В данном контексте можно такой: «забыл про PHP, как про страшный сон» :-)
А если серьёзно, то на мой взгляд состоявшемуся программисту должно быть не суть важно какой язык или стек, он причинит проекту пользу в любом случае )))
Разница, конечно, есть. Но в идеале программист не должен сильно быть привязан к какому-то конкретному языку программирования. Опыт естественно набирается в основном на 2-3 языках, но это не блокирует возможность программировать на любом другом.
Кстати, если Вам не нравится метафора с серверами… то есть ещё более удачная: объекты — это сотрудники завода, чётко следующие должностным инструкциям. А сама программа — это завод, который на вход принимает сырьё (пользовательский ввод), а на выход даёт готовую продукцию (результат вычислений на основе ввода)
Я понял, что Вам это кажется неправильным, но не понял почему Вам так кажется… Единственный аргумент, который Вы привели, что объект-сервер возвращает управление обратно серверу-инициатору сообщения или в main-loop… если быть точнее, то возможен ещё вариант передачи управления следующему объекту-серверу (аля конвеер). Что в этом неправильного? Да и как иначе, сделать 1 единственный объект на всю программу, который никому управление не отдаст, ну ok… вот это как раз и будет процедурное программирование :-)
it is an independent entity with its own life cycle, its own behavior, and its own habits.
Я полностью согласен с таким определением объекта (впрочем, точнее было бы называть это субъектом или актором). Но вот дальнейшие примеры в статье показывают профессиональную деформацию от долгого программирования на мейнстрим-языках. Взять тот же файл, это совершенно пасивная сущность, без какого-либо собственного поведения, по сути тупо набор байтов. А XmlParser — это очевидно активная сущность, представляет она человека, читающего и интерпретирующего файл. Другими словами, любая человеческая активность может быть выражена объектом. Похожая метафора с того же OOPSLA97: «An object is a virtual server».
Таким образом, годный объект — это виртуальный сервер, обеспечивающий выполнение/автоматизацию некоторой активности, которая могла бы быть выполнена человеком, над некоторым набором данных (состояние объекта), на основании обработки входящих сообщений (аля приказы начальника, просьбы коллеги и т.п.)
Фиговые объекты сразу видно по действиям, которые описываются возвратными глаголами (с постфиксом -ся). Например, файл открывается, строка пишется, файл закрывается.
По поводу источника «Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to happen to computing since MS-DOS.» — это из выступления на OOPSLA97
P.S. Лично я считаю, что ООП не вредно, как средство высокоуровневого проектирования. Вред приносят попытки искусственно сделать всё объектами… Во-первых, они довольно корявы во всех мейнстрим-реализациях. Во-вторых, это не даёт никаких практических преимуществ.
Поэтому мне ближе ООП в том виде, в котором оно существует в BEAM (где в роли объектов выступают легковесные процессы, внутренняя реализация которых насквозь функциональна), а не то, что может предложить JVM.
Вам же, насколько я понял, нравится придерживаться идеи, что всё является объектами… Поэтому интересно было бы почитать Ваше мнение на тему Smalltalk.
Автоформаттер — это про читаемость кода, но совсем не про выразительность языка… К тому же не так много языков страдает от наличия конкурирующих style guides. И тут я за более мягкие решения вопроса, типа Hound CI
если я правильно понял, в Go существует из коробки эдакий менеджмент зависимостей(я про import с git репозиториев) мне эта идея тоже нравится.
Поверьте, import тупо master-ветки с git репозиториев — это далеко не лучшая затея. Я давно не следил за прогрессом Go в этой области, но по крайней мере раньше у них даже не было штатного менеджера зависимостей. А когда у вас куча зависимостей на master-ветки репозиториев — это вообще не весело. Поэтому догадайтесь что там происходило пару лет назад… Правильно! Все, кому не лень, писали свои менеджеры зависимостей, коих было не меньше десятка.
Забавно, когда пытаются что-то объяснить на примерах, оторванных от реальности… Что самое главное в практической работе с числами Фибоначчи? Главное — это возможность мемоизации! Соответвенно, объект Fibo бесполезен чуть менее, чем полностью, и на практике нужен будет единственный на всю программу объект FiboServer, который не будет повторно считать уже вычисленные числа.
Also, in some languages object interactions are way easier to test, thanks to interfaces and fake objects. I can’t remember a language, which allows to define such a separated schema for a function.
Ахах, т.е. заглушки — это просто, а заменить функцию в pipeline — сложно?
Впрочем, спору нет, что благодаря IoC и железной дисциплине в команде можно добиться от объектов того же уровня тестопригодности, который в любом функциональном языке присутствует by design (с нулевыми усилиями).
Обоснуйте! Каким образом по-вашему это проявляется в масштабах экосистемы?
Например, я вижу в экосистеме Go большую тягу к велосипедостроительству… Это выражается в том, что для решения одной задачи создаются порой десятки вариантов решений, т.е. отсутвует консолидация усилий…
В языках, где можно легко и быстро включиться в разработку, наоборот преобладают тенденции к созданию де-факто стандартных пакетов под каждую задачу.
Да, если я ничего не путаю, ещё в первоисточнике (PoEAA) было примечание, что Active Record нарушает SRP и не рекомендуется использовать его в случаях сложнее, чем тривиальные.
А можно пример?
Ну, это просто утрированный случай… На практике сложно найти работу, где все коллеги будут тянуть вперёд… Точнее, в начале карьеры несложно, но чем больше опыта, тем чаще приходится самому кого-то тянуть )))
Языки разные знать надо… Нельзя себя только одним типом языков ограничивать, даже джуниорам. Есть общие критерии, по которым можно представить себе язык даже если ты его никогда раньше не видел:
Если эти критерии сами по себе понятны, то от языка понадобится только синтаксис и стандартная библиотека. Для ещё более хорошего описания список критериев можно слегка расширить простыми пунктами типа: мутабельность данных, мономорфность операторов и т.п.
О, это ощущение обычно бывает ещё в первый год… потом, правда, у адекватных людей проходит на значительное время )
А если серьёзно, то на мой взгляд состоявшемуся программисту должно быть не суть важно какой язык или стек, он причинит проекту пользу в любом случае )))
Таким образом, годный объект — это виртуальный сервер, обеспечивающий выполнение/автоматизацию некоторой активности, которая могла бы быть выполнена человеком, над некоторым набором данных (состояние объекта), на основании обработки входящих сообщений (аля приказы начальника, просьбы коллеги и т.п.)
Фиговые объекты сразу видно по действиям, которые описываются возвратными глаголами (с постфиксом -ся). Например, файл открывается, строка пишется, файл закрывается.
В принципе, можно у него самого уточнить…
В Вашей коллекции не хватает:
I'm sorry that I long ago coined the term «objects» for this topic because it gets many people to focus on the lesser idea. © http://c2.com/cgi/wiki?AlanKayOnMessaging
Ну и несколько статей на тему (хотя возможно Вы их уже читали):
Ten Things I Hate About Object-Oriented Programming
The Deep Insights of Alan Kay
Object Oriented Programming is an expensive disaster which must end
Fifty Questions for a Prospective Language Designer
P.S. Лично я считаю, что ООП не вредно, как средство высокоуровневого проектирования. Вред приносят попытки искусственно сделать всё объектами… Во-первых, они довольно корявы во всех мейнстрим-реализациях. Во-вторых, это не даёт никаких практических преимуществ.
Поэтому мне ближе ООП в том виде, в котором оно существует в BEAM (где в роли объектов выступают легковесные процессы, внутренняя реализация которых насквозь функциональна), а не то, что может предложить JVM.
Вам же, насколько я понял, нравится придерживаться идеи, что всё является объектами… Поэтому интересно было бы почитать Ваше мнение на тему Smalltalk.
Поверьте, import тупо master-ветки с git репозиториев — это далеко не лучшая затея. Я давно не следил за прогрессом Go в этой области, но по крайней мере раньше у них даже не было штатного менеджера зависимостей. А когда у вас куча зависимостей на master-ветки репозиториев — это вообще не весело. Поэтому догадайтесь что там происходило пару лет назад… Правильно! Все, кому не лень, писали свои менеджеры зависимостей, коих было не меньше десятка.
Ахах, т.е. заглушки — это просто, а заменить функцию в pipeline — сложно?
Впрочем, спору нет, что благодаря IoC и железной дисциплине в команде можно добиться от объектов того же уровня тестопригодности, который в любом функциональном языке присутствует by design (с нулевыми усилиями).
«C++ is history repeated as tragedy. Java is history repeated as farce.»
– Scott McKay
«Java, the best argument for Smalltalk since C++»
– Frank Winkler
Например, я вижу в экосистеме Go большую тягу к велосипедостроительству… Это выражается в том, что для решения одной задачи создаются порой десятки вариантов решений, т.е. отсутвует консолидация усилий…
В языках, где можно легко и быстро включиться в разработку, наоборот преобладают тенденции к созданию де-факто стандартных пакетов под каждую задачу.