Operators — <> уже заняты под редирект, выкрутились так
Escape Character — ` потому что \ в винде уже занято под разделитель файловых путей, а шелл предназначен во многом для работы с файлами
If Requires Curly Brackets — не знаю почему. Могу только добавить, что часто есть coding convention чтобы фигурные скобки ставили всегда, для читабельности.
Function Definitions — это достаточно часто в скриптовых языках потому, что определение функции это фактически команда добавить функцию в скоуп. Это можно сделать другой командой:
new-item -Name hello -Value { "Hello" }
Function Calls — думаю, так сделано чтобы легко определять свои команды и работать в привычном синтаксисе без лишних символов.
Script Syntax Check — автор текста, судя по всему, не знает, что такое поверка синтаксиса — он написал синтаксически правильный код.
Lack of Mandatory Variable Declarations — тут я согласен, неплохо бы включать строгий режим который этого не допускает.
Scope of Variables — это, наверное, средство предыдущего пункта. Если есть наследование областей видимости, то как отличать доступ к переменной из глобальной области к доступу из локальной с таким же именем — вот и решили, что если есть локальное присваивание это определение новой переменной. Никакого копирования, кстати, не происходит, это совершенно новая переменная. В питоне поступили по другому — для доступа к шлобальному контексту — ключевое слово global, но в функции контекст наследутся но изменять просто нельзя.
Словом, человек с опытом больших статических языков программирования применяет свои привычки к шеллу.
Шелл — это весьма специфический скриптоый язык. Вероятно так сделали, чтобы было привычнее админам, которые работали с cmd, command.com, bash и т.д.
Можете для сравнения посмотреть, на попытку сделать шелл на основе питона — ipython — там, например, чтобы вызвать исполнимый файл надо писать! перед командой
Обычно наоборот, конечно. Интерфейсы плохи тем, что их расширение это breaking change. Или кто-то соверинжинирил и сейчас ещё не нужен класс и интерфейс модно убрать лишнюю сущность, оставив только класс.
А меня наоборот. Теоретически это мешает переделывать интерфейс в класс и обратно (главное роль типа в программе, а интерфейс это или класс — вторична). Практически, правда, я соблюдаю нейминг конвеншнс того места, где я оказался.
Тогда оба варианта наилучшие. Так как оба меньше слона. Но вы, наверное, имели ввиду "быть как можно меньше".
Для основной мысли моего высказывания, впрочем, это не особенно важно — я просил т хотел показать что Ви зависимости от постановки меняется дизайн и без понимания того что мы дизайном и с какой целью трудно нельзя сказать что само собой разумеется, что метод X должен быть в классе Y
В дополнение к аналоги — тут на хабре была статья про то как владельцы ТЦ проталкивают своего поставщика инета и как боятся с альтернативами включая глушилки. Там правда, за него отдельно бабки просят
Допустим нас не интересует как кошку кормят разные люди и разница в кормушках для нас несущественна. Нам нужно знать только каким кошкам надо насыпать какой корм (в зависимости от породы, например)
Если мы смоделируем разницу в кормлении разных кошек в ооп языке внутри класса человека, то нам надо будет развозить какой-то паттерн матчинг и прочее.
Куда проще завести разные классы кошек с методом "прокормить" и описывать процесс кормления там а человека и кормушку вынести за скобки. Например человека вообще не включать в модель а кормушку использовать только для хранения ёмкости.
Это как раз менее важно — как только у того, кто пишет код квадрат и прямоугольник в коде станут обладать абсолютно теми же свойствами как и квадрат и прямоугольник в голове — противоречие снимется. Главное очень четко осознавать что именно он называет квадратом а что прямоугольником.
Если человек решит, что мутабельный прямоугольник с гарантией незвисимого изменения сторон для него тождественен понятию Прямоугольник, то он как логическое существо должен не наследовать от него квадрат и в обыденной жизни считать что. Если он решит, что прямоугольник это все прямоугольное, соответственно он должен либо убрать у прямоугольника в программе все остальные требования либо переименовать прямоугольник в программе, либо считать их омонимами.
Это не программирование, это схоластика, которая присуща только ООП. Причём это буквально так. В реальном мире не существует никакого наследования.
Это все про то, как человеку удобно думать про окружающий мир. Наследование это отражение того факта, что человеку удобно делить предметы на категории и подкатегории обладают по умолчанию свойствами надкатегорий (если все собаки хвостаты, а пудели — собаки, то пудели хвостаты).
Имхо при моделировании главное, понять, какой аспект реальности мы моделируем. В аэродинамических моделях продуваемых в аэжротрубе вряд ли делают маленьких пассажиров.
Модель это какая-то штука, которая в интересующем нас разрезе ведет себя как какая-то другая штука, но в чем-то удобнее.
Для меня из этого следует, что к какому классу принадлежит метод зависит от того, что мы моделируем а что отбрасываем. Например, если мы хотим смоделировать то, как Суворов берет крепости, вполне допустим и Измаил.Взять() (так как никаких других полководцев мы не рассматриваем и алгоритм взятия крепости зависит только от нее самой).
Поэтому, желательно, при рассмотрении каких-то, примеров приводить более подробные задания — что и для чего мы делаем.
При испытании лифта человека можно смоделировать мешком аналогичного веса, но другой формы, а при показе одежды манекеном похожей формы, но другого веса.
Соответственно это немного уменьшает неопределенность — или всех возможных вариантов останется два "неспособен написать hello world и не способен написать высоконагруженную систему", "не хочет писать задания" т.е. что-то говорит о кандидате в интересующем ключе.
Мы можем, например, дать простой "hello world", дать денег за hello world чтобы снизить влияние нежелания писать задания. Ну или не хотящих писать задания по какой-то другой причине отвергать.
Это вообще-то не прямоугольник, а некоторая другая сущность, с прямоугольником связанная только формой.
Это ничего особо не изменит в дискуссии *
Вся дискуссия ведётся от противоречия между свойствами математического прямоугольника, математического квадрата и того, что было выражено на языке программирования.
Если понять что на языке программирования кто-то словом "прямоугольник" и "квадрат" назвал нечто обладающее дополнительными ограничениями по сравнению с тем что мы привыкли называть прямоугольником и квадратом в обыденной жизни, то противоречие снимется.
Например, если сказать что сиреневый квадрат не является голубым прямоугольником это не породит дополнительной дискуссии.
Если у вас в рисовалке есть
изменяемые прямоугольники и квадраты, то либо класс фигуры должен меняться от изменения параметров; либо не надо требовать чтобы квадраты были прямоугольниками; либо надо обозначить что при изменении одной стороны прямоугольника не было бы ожидания, что у прямоугольника размеры сторон независимы. (Выделить Изменяемый прямоугольник отдельно и Изменяемый прямоугольник с независимыми сторонами отдельно)
Т.е. в этом как бы парадоксе вся соль в том что от прямоугольников и квадратов требуется больше чем прямоугольность и квадратность.
Operators — <> уже заняты под редирект, выкрутились так
Escape Character — ` потому что \ в винде уже занято под разделитель файловых путей, а шелл предназначен во многом для работы с файлами
If Requires Curly Brackets — не знаю почему. Могу только добавить, что часто есть coding convention чтобы фигурные скобки ставили всегда, для читабельности.
Function Definitions — это достаточно часто в скриптовых языках потому, что определение функции это фактически команда добавить функцию в скоуп. Это можно сделать другой командой:
Function Calls — думаю, так сделано чтобы легко определять свои команды и работать в привычном синтаксисе без лишних символов.
Script Syntax Check — автор текста, судя по всему, не знает, что такое поверка синтаксиса — он написал синтаксически правильный код.
Lack of Mandatory Variable Declarations — тут я согласен, неплохо бы включать строгий режим который этого не допускает.
Scope of Variables — это, наверное, средство предыдущего пункта. Если есть наследование областей видимости, то как отличать доступ к переменной из глобальной области к доступу из локальной с таким же именем — вот и решили, что если есть локальное присваивание это определение новой переменной. Никакого копирования, кстати, не происходит, это совершенно новая переменная. В питоне поступили по другому — для доступа к шлобальному контексту — ключевое слово global, но в функции контекст наследутся но изменять просто нельзя.
Словом, человек с опытом больших статических языков программирования применяет свои привычки к шеллу.
Шелл — это весьма специфический скриптоый язык. Вероятно так сделали, чтобы было привычнее админам, которые работали с cmd, command.com, bash и т.д.
Можете для сравнения посмотреть, на попытку сделать шелл на основе питона — ipython — там, например, чтобы вызвать исполнимый файл надо писать! перед командой
Они не шеллы. Шелл был cmd. И синтаксис похож на него.
А как вы это узнали?
Да, поэтому когда надо перелезать участок забора рефакторят.
Они этим одновременно плохи и хороши.
Обычно наоборот, конечно. Интерфейсы плохи тем, что их расширение это breaking change. Или кто-то соверинжинирил и сейчас ещё не нужен класс и интерфейс модно убрать лишнюю сущность, оставив только класс.
А меня наоборот. Теоретически это мешает переделывать интерфейс в класс и обратно (главное роль типа в программе, а интерфейс это или класс — вторична). Практически, правда, я соблюдаю нейминг конвеншнс того места, где я оказался.
Кстати в мире Гарри Поттера есть машина времени временные петли. Например, там было два Гарри Поттера — один наблюдал за другим.
Я не помню наблюдалось ли там две Совы но не помню также фундаментального ограничения на этот счёт.
Синглтоны также неудобны при юнит тестировании — многопоточное тестирование не запустить и каждый раз надо аккуратно восстанавливать состояние.
Тогда оба варианта наилучшие. Так как оба меньше слона. Но вы, наверное, имели ввиду "быть как можно меньше".
Для основной мысли моего высказывания, впрочем, это не особенно важно — я просил т хотел показать что Ви зависимости от постановки меняется дизайн и без понимания того что мы дизайном и с какой целью трудно нельзя сказать что само собой разумеется, что метод X должен быть в классе Y
То что вы написали после "нет" никак не отрицает ни основной мысли комментария ни процитированного текста :D.
" — собака куда меньше слона.
В дополнение к аналоги — тут на хабре была статья про то как владельцы ТЦ проталкивают своего поставщика инета и как боятся с альтернативами включая глушилки. Там правда, за него отдельно бабки просят
Допустим нас не интересует как кошку кормят разные люди и разница в кормушках для нас несущественна. Нам нужно знать только каким кошкам надо насыпать какой корм (в зависимости от породы, например)
Если мы смоделируем разницу в кормлении разных кошек в ооп языке внутри класса человека, то нам надо будет развозить какой-то паттерн матчинг и прочее.
Куда проще завести разные классы кошек с методом "прокормить" и описывать процесс кормления там а человека и кормушку вынести за скобки. Например человека вообще не включать в модель а кормушку использовать только для хранения ёмкости.
Или сделать таблицу смещений (подобно тому как при загрузке exe в досе было)
А как вы пишете тесты на перформанс и как избегание регрессий в перформансе?
Это как раз менее важно — как только у того, кто пишет код квадрат и прямоугольник в коде станут обладать абсолютно теми же свойствами как и квадрат и прямоугольник в голове — противоречие снимется. Главное очень четко осознавать что именно он называет квадратом а что прямоугольником.
Если человек решит, что мутабельный прямоугольник с гарантией незвисимого изменения сторон для него тождественен понятию Прямоугольник, то он как логическое существо должен не наследовать от него квадрат и в обыденной жизни считать что. Если он решит, что прямоугольник это все прямоугольное, соответственно он должен либо убрать у прямоугольника в программе все остальные требования либо переименовать прямоугольник в программе, либо считать их омонимами.
Это все про то, как человеку удобно думать про окружающий мир. Наследование это отражение того факта, что человеку удобно делить предметы на категории и подкатегории обладают по умолчанию свойствами надкатегорий (если все собаки хвостаты, а пудели — собаки, то пудели хвостаты).
Имхо при моделировании главное, понять, какой аспект реальности мы моделируем. В аэродинамических моделях продуваемых в аэжротрубе вряд ли делают маленьких пассажиров.
Модель это какая-то штука, которая в интересующем нас разрезе ведет себя как какая-то другая штука, но в чем-то удобнее.
Для меня из этого следует, что к какому классу принадлежит метод зависит от того, что мы моделируем а что отбрасываем. Например, если мы хотим смоделировать то, как Суворов берет крепости, вполне допустим и Измаил.Взять() (так как никаких других полководцев мы не рассматриваем и алгоритм взятия крепости зависит только от нее самой).
Поэтому, желательно, при рассмотрении каких-то, примеров приводить более подробные задания — что и для чего мы делаем.
При испытании лифта человека можно смоделировать мешком аналогичного веса, но другой формы, а при показе одежды манекеном похожей формы, но другого веса.
Соответственно это немного уменьшает неопределенность — или всех возможных вариантов останется два "неспособен написать hello world и не способен написать высоконагруженную систему", "не хочет писать задания" т.е. что-то говорит о кандидате в интересующем ключе.
Мы можем, например, дать простой "hello world", дать денег за hello world чтобы снизить влияние нежелания писать задания. Ну или не хотящих писать задания по какой-то другой причине отвергать.
Я про это:
Вся дискуссия ведётся от противоречия между свойствами математического прямоугольника, математического квадрата и того, что было выражено на языке программирования.
Если понять что на языке программирования кто-то словом "прямоугольник" и "квадрат" назвал нечто обладающее дополнительными ограничениями по сравнению с тем что мы привыкли называть прямоугольником и квадратом в обыденной жизни, то противоречие снимется.
Например, если сказать что сиреневый квадрат не является голубым прямоугольником это не породит дополнительной дискуссии.
Если у вас в рисовалке есть
изменяемые прямоугольники и квадраты, то либо класс фигуры должен меняться от изменения параметров; либо не надо требовать чтобы квадраты были прямоугольниками; либо надо обозначить что при изменении одной стороны прямоугольника не было бы ожидания, что у прямоугольника размеры сторон независимы. (Выделить Изменяемый прямоугольник отдельно и Изменяемый прямоугольник с независимыми сторонами отдельно)
Т.е. в этом как бы парадоксе вся соль в том что от прямоугольников и квадратов требуется больше чем прямоугольность и квадратность.