, а вот Bash — жуткое дерьмо. Да, в нём есть ограничения по сравнению в обычными языками (т. к. для вызова программы мы не можем, к примеру, поюзать вызов функции, сразу должна запускаться программа), но даже школьник мог бы придумать синтаксис в 1000 раз лучше.
bash позволяет писать довольно выразительный код для своего класса задач. В качестве примера можно смотреть исходники git. А школьники уже все придумали: сначала получился cmd, чуть позже — power shell).
Практически любую полезную штуку можно попытаться сломать или поджечь. Иногда это вполне безобидно и даже забавно.
JavaScript в современном Web является скорее низкоуровневым языком, в который транслируются программы, которые пишутся на более высокоуровневых языках и DSL типа TypeScript, PureScript, JSX и т.п. Как универсальный «ассемблер» он достаточно хорош ввиду хорошей поддержки просто огромным количеством рантаймов.
Ну как и в любом очень популярном языке программирования в него приходят очень много разных людей. И многим из этих людей, так скажем, лучше уж было бы садить картошку и разводить кролей, чем кодить.
Если посмотреть на всю массу решений с высоты птичьего полета, то ситуация очень напоминает эволюцию с естественным отбором. Усложнять — просто, упрощать — сложно. Средний уровень подготовки разработчиков вынуждает искать максимально простые решения, отстреливая различную заумь.
Интерфейс AircraftRepository является частью доменных сервисов, в то время, как AircraftController и реализация AircraftRepository, являются частями инфраструктурного слоя
Интерфейс AircraftRepository является контрактом между контроллером (высокоуровневой частью) и репозиторием (низкоуровневой частью). Поэтому размещение интерфейса в нижних слоях будет нарушать DIP, т.к. у контроллера появляется зависимость в обратном направлении.
Dependency Inversion Principle говорит нам о том, что модули верхнего уровня не должны зависеть от модулей нижних уровней, оба должны зависеть от абстракций. Это нужно для возможности менять низкоуровневые части, не затрагивая компоненты более высокого уровня. Если с деталями реализации все более-менее понятно, то размещение абстракций по слоям часто вызывает вопросы.
Идея примерно в следующем. Допустим вы организация (высокоуровневая часть, клиент), которая выбирает исполнителя (низкоуровневую часть). Пусть вашим исполнителем будет клининговая компания. Выбрав какую-то одну из них вы собираетесь заключить договор. Есть два варианта два:
1. Прямой — подписать стандартный договор клининговой компании (контракт низкоуровневой стороны). Недостатком является то, что принимая чужие условия, вы будете вынуждены как-то под них прогнуться. Это привязывает вас к особенностям оказания услуг конкретного исполнителя. В случае проблем, заменить исполнителя на другого быстро не получиться, т.к. вы уже подстроились под условия текущего, и будете вынуждены перестраиваться под условия нового.
2. Инверсный — вы сами составляете договор, где указываете нужные вам критерии и предлагаете исполнителю его подписать. Тогда контроль за ситуацией остается на вашей стороне. Кроме того, вы получаете возможность менять исполнителя, используя тот же самый шаблон договора, без каких-либо изменений на своей стороне.
Оба варианта имеют право на жизнь. Но собственно, второй — это и есть то, что предлагает нам DIP. Владеть интерфейсом должен высокоуровневый слой. Недостатком будет увеличение количества церемоний для соблюдения границ. Вероятно высокоуровневые интерфейсы придется выносить в отдельный пакет, чтобы доставить низкоуровневому слою. А на низкоуровневой стороне создавать адаптеры потому, что в общем случае требования клиента могут отличаться в деталях от принятых у исполнителя внутренних соглашений. В целом получается сложнее. Поэтому на практике данный подход оправдан лишь на границах разделения слоев или во фреймворках.
Есть такая штука как интерференция навыков. Это когда освоенное мешает овладевать новым. Возможно они базируются на противоположных принципах. Кто после лыж пробовал встать на сноуборд, точно поймет.
Язык подталкивает мыслить определенным образом. Если думать как на хаскелях, а писать на c++, то будет вот такая ерунда с неочевидостями. Песенки на детском утреннике и классическая опера — разные вещи, для разной аудитоии. Попробуйте переформулировать код так, чтобы в нем мог разобраться любой, при помощи популярного в этой среде учебника.
JS это ещё больше днище, чем С++. Там написать понятно, красиво и без ошибок, это mission impossible. Вы можете обвешаться фреймворками как супероружием или идти в продакшен с голыми руками, но в итоге все решает удача, отвага и слабоумие. Отчасти поэтому после плюсов и питона я выбрал его. До сих пор интересно.
Смена контекстов по общей программе «ясли-сад-школа-институт-армия-работа» и возможность что-то менять это две разные вещи. Что вы тут принципиально можете изменить? Это общие социальные требования.
Вот когда программы уже нет, и ни кто особо ни чего от тебя не требует, тогда появляются предпосылки, чтобы начать менять свою жизнь всерьез и осознанно. Возможно первый раз в жизни. Кажется это называется кризисом среднего возраста.
Говорят, что первое решается. Отдыхом, режимом дня, здоровым питанием, прогулками на свежем воздухе, физухой, сменой обстановки, новыми амбициозными вызовами. Учитесь слушать свой организм, а не только лекции по математике.
Про второе я не уверен). Можно лишь поменять свое отношение к языку и своему ремеслу. Язык как материал. Мастерство гончара состоит в том, чтобы из куска г лины делать если не произведения искусства, то максимально полезные или ценные вещи. С++ самый что ни на есть говноязык с упопротым комитетом, грудой легаси и кастылей. А значит вполне подходит для того, чтобы оттачивать свое мастерство и писать шедевры. Вы не находите?
Сидеть лучше чем стоять) Чисто бытовые привычки у людей довольно разнообразны. Кто-то может и в тапочках, а кто-то без макияжа даже мусор за дверь не готов вынести. Про жизнь в замкнутом коллективе было много исследований, результаты которых показывают, что этот маленький нюанс провоцирует массу конфликтов и драматически меняет поведение.
Взять хотя бы такой привычный офисный момент как клининг. Интересно, как они решают этот вопрос в условиях изоляции. Спец персонал запирается вместе с банковскими служащими или директора наравне с подчинёнными будут драить туалеты?
Архитектура в большинстве случаев определяется структурой команд и тех.процессами. Возьмём например слоёный торт: корж, сгущенка, корж, крем, вишенка. С точки зрения производства, эти элементы эффективнее производить отдельно — один лепит коржи, другой варит сгущенку и т.д. Потом все это собирается вместе. На выходе получается кусок солёной еды.
Аналогичным образом можно разрабатывать приложения, если выстроить соответствующий тех. процесс. Важно, чтобы изготовление каждого слоя в отдельности имело под собой какой-то смысл. Такой как специализация сотрудника или специфичный домен.
Честно говоря, я ни разу не встречал подобных решений на фронте. Здесь разработка делится по фичам/страницам/экранам и для каждой ведётся в одну каску, максимум две — CSS и JS. По аналогии, это больше напоминает пельмени: тесто, фарш. Поэтому ритуалы с дополнительными слоями внутри, как в тортах, кажутся несколько избыточными.
Clean Architecture это крутая книга, где автор рассказывает о принципах разработки сложных систем, показывая примеры решений на разных уровнях абстракции — от самых нижних на уровне кодинга, до самого верха на уровне управления конфигурациями и релизами. Только не нужно принимать примеры за универсальные догмы, как это произошло с шаблонами проектирования.
В хаскеле есть product и sum, но между типами нет ни какого порядка. Bottom это наименьшее значение в poset. Иными словами, для существования Bottom между типами необходимо (но не достаточно) хотя бы номинально определить отношение «меньше или равно».
Спасибо, вроде сейчас стало понятно. Фича кажется полезной в частном случае:
function error(message: string) : never {
throw new Error(message)
}
error("foo")
console.log('bar') // Unreachable code detected.
Но вот здесь тайп чекер уже не может найти ошибку:
function error(message: string) : never {
throw new Error(message)
}
function run(test: Boolean) : number {
if (test) {
return error("foo")
} else {
return 1;
}
}
const res: number = run(true)
console.log('bar')
Видимо потому, что сумма number|never ни чем не отличается от number, так?
Проблема в том, что в деление контента по возрастным группам вбухивается куча бабла (не сами же собой появляются эти значки в титрах), про него говорят в рекламе, под предлогом защиты детей политики вводят все новые и новые ограничения. Но с точки зрения детей, на практике это работает от слова никак, и всем по большому счету пофиг.
В девяностых-нулевых, была проблема что по телевизору показывают слишком много чернухи (привет, НТВ с Чикатило) вместе с рекламой пива
В девяностых-нулевых НТВ был приличным каналом, не стеснявшейся всерьез поднимать политические и остро социальные проблемы. Он стал таким, о чем вы пишите, ближе к середине нулевых после известных событий, когда с канала «ушли» основных журналистов.
Когда вы возвращаете боттом вместо числоа можно сказать, что вы вернули подтип, а можно сказат, что там было написано number | bottom, и был возвращён правый вариант.
У Пети нет яблок, их 0. А у Маши есть одно яблоко. Можно сказать, что у Маши их 1. Но 1 = 1 + 0. Поэтому можно сказать, что Машино яблоко находится в суперпозиции существующего и отсутствующего яблока. А значит сказать однозначно сколько у Маши яблок становится проблемой. Так что-ли?
Любая формальная система либо неполна, либо противоречива. Система типов это модель, которая нужна чтобы помочь программисту делать меньше ошибок (определенного класса). Она не может претендавать на абсолютную полноту и безошибочность, по определению.
never, в системе типов typescript, является подтипом все других типов, т.е. наименьшим элементом, т.е. это bottom по всем формальным признакам. Вы же не с этим утверждением спорите?
Насколько я понял ваши аргументы, есть проблема останова и она не решается. Теоретически это можно выразить в системе типов, введя дополнительный тип, который может быть еще «меньше». Но так ни кто не делает. В самом деле, зачем в систему типов вводить дополнительные свойства, ради задач, которые она все равно не может решить, какова польза?
JavaScript в современном Web является скорее низкоуровневым языком, в который транслируются программы, которые пишутся на более высокоуровневых языках и DSL типа TypeScript, PureScript, JSX и т.п. Как универсальный «ассемблер» он достаточно хорош ввиду хорошей поддержки просто огромным количеством рантаймов.
Интерфейс AircraftRepository является контрактом между контроллером (высокоуровневой частью) и репозиторием (низкоуровневой частью). Поэтому размещение интерфейса в нижних слоях будет нарушать DIP, т.к. у контроллера появляется зависимость в обратном направлении.
Dependency Inversion Principle говорит нам о том, что модули верхнего уровня не должны зависеть от модулей нижних уровней, оба должны зависеть от абстракций. Это нужно для возможности менять низкоуровневые части, не затрагивая компоненты более высокого уровня. Если с деталями реализации все более-менее понятно, то размещение абстракций по слоям часто вызывает вопросы.
Идея примерно в следующем. Допустим вы организация (высокоуровневая часть, клиент), которая выбирает исполнителя (низкоуровневую часть). Пусть вашим исполнителем будет клининговая компания. Выбрав какую-то одну из них вы собираетесь заключить договор. Есть два варианта два:
1. Прямой — подписать стандартный договор клининговой компании (контракт низкоуровневой стороны). Недостатком является то, что принимая чужие условия, вы будете вынуждены как-то под них прогнуться. Это привязывает вас к особенностям оказания услуг конкретного исполнителя. В случае проблем, заменить исполнителя на другого быстро не получиться, т.к. вы уже подстроились под условия текущего, и будете вынуждены перестраиваться под условия нового.
2. Инверсный — вы сами составляете договор, где указываете нужные вам критерии и предлагаете исполнителю его подписать. Тогда контроль за ситуацией остается на вашей стороне. Кроме того, вы получаете возможность менять исполнителя, используя тот же самый шаблон договора, без каких-либо изменений на своей стороне.
Оба варианта имеют право на жизнь. Но собственно, второй — это и есть то, что предлагает нам DIP. Владеть интерфейсом должен высокоуровневый слой. Недостатком будет увеличение количества церемоний для соблюдения границ. Вероятно высокоуровневые интерфейсы придется выносить в отдельный пакет, чтобы доставить низкоуровневому слою. А на низкоуровневой стороне создавать адаптеры потому, что в общем случае требования клиента могут отличаться в деталях от принятых у исполнителя внутренних соглашений. В целом получается сложнее. Поэтому на практике данный подход оправдан лишь на границах разделения слоев или во фреймворках.
Язык подталкивает мыслить определенным образом. Если думать как на хаскелях, а писать на c++, то будет вот такая ерунда с неочевидостями. Песенки на детском утреннике и классическая опера — разные вещи, для разной аудитоии. Попробуйте переформулировать код так, чтобы в нем мог разобраться любой, при помощи популярного в этой среде учебника.
Вот когда программы уже нет, и ни кто особо ни чего от тебя не требует, тогда появляются предпосылки, чтобы начать менять свою жизнь всерьез и осознанно. Возможно первый раз в жизни. Кажется это называется кризисом среднего возраста.
Выгорание и С++ это две разные проблемы.
Говорят, что первое решается. Отдыхом, режимом дня, здоровым питанием, прогулками на свежем воздухе, физухой, сменой обстановки, новыми амбициозными вызовами. Учитесь слушать свой организм, а не только лекции по математике.
Про второе я не уверен). Можно лишь поменять свое отношение к языку и своему ремеслу. Язык как материал. Мастерство гончара состоит в том, чтобы из куска г лины делать если не произведения искусства, то максимально полезные или ценные вещи. С++ самый что ни на есть говноязык с упопротым комитетом, грудой легаси и кастылей. А значит вполне подходит для того, чтобы оттачивать свое мастерство и писать шедевры. Вы не находите?
Тем лучше для рейтингов. "Они даже не подозревают..."
Взять хотя бы такой привычный офисный момент как клининг. Интересно, как они решают этот вопрос в условиях изоляции. Спец персонал запирается вместе с банковскими служащими или директора наравне с подчинёнными будут драить туалеты?
Аналогичным образом можно разрабатывать приложения, если выстроить соответствующий тех. процесс. Важно, чтобы изготовление каждого слоя в отдельности имело под собой какой-то смысл. Такой как специализация сотрудника или специфичный домен.
Честно говоря, я ни разу не встречал подобных решений на фронте. Здесь разработка делится по фичам/страницам/экранам и для каждой ведётся в одну каску, максимум две — CSS и JS. По аналогии, это больше напоминает пельмени: тесто, фарш. Поэтому ритуалы с дополнительными слоями внутри, как в тортах, кажутся несколько избыточными.
Clean Architecture это крутая книга, где автор рассказывает о принципах разработки сложных систем, показывая примеры решений на разных уровнях абстракции — от самых нижних на уровне кодинга, до самого верха на уровне управления конфигурациями и релизами. Только не нужно принимать примеры за универсальные догмы, как это произошло с шаблонами проектирования.
Но вот здесь тайп чекер уже не может найти ошибку:
Видимо потому, что сумма
number|neverни чем не отличается отnumber, так?В девяностых-нулевых НТВ был приличным каналом, не стеснявшейся всерьез поднимать политические и остро социальные проблемы. Он стал таким, о чем вы пишите, ближе к середине нулевых после известных событий, когда с канала «ушли» основных журналистов.
У Пети нет яблок, их 0. А у Маши есть одно яблоко. Можно сказать, что у Маши их 1. Но 1 = 1 + 0. Поэтому можно сказать, что Машино яблоко находится в суперпозиции существующего и отсутствующего яблока. А значит сказать однозначно сколько у Маши яблок становится проблемой. Так что-ли?
never, в системе типов typescript, является подтипом все других типов, т.е. наименьшим элементом, т.е. это bottom по всем формальным признакам. Вы же не с этим утверждением спорите?Насколько я понял ваши аргументы, есть проблема останова и она не решается. Теоретически это можно выразить в системе типов, введя дополнительный тип, который может быть еще «меньше». Но так ни кто не делает. В самом деле, зачем в систему типов вводить дополнительные свойства, ради задач, которые она все равно не может решить, какова польза?