Видео с насосом из МОТа это такой лютый фейк, что рука тянется поставить автору минус. Не из злорадства, но, пардон, это насколько надо быть лишённым критического мышления, чтобы такое включать в статью?
В МГД-установке должен быть и источник магнитого поля, и источник перпендикулярного электрического. Должно быть два электрода, которые пропускают через рабочее тело ток. У него такими электродами могли бы быть две половинки трубы, распиленной продольно пополам. Я всё ждал, когда он будет пилить трубу, но он так и не стал. Никакого подвода проводов к электродам, да и отсутствие самих электродов.
Магнитное поле у него переменное. Воздушный зазор в сердечнике огромный. Может быть какие-то токи там и возникают, но только токи Фуко в самой трубе.
А самое главное, обратного клапана на трубе нет. Наверное установка ещё и вакуум умеет создавать в пустой трубе, чтобы подсосать туда первоначальную порцию воды и начать работать с безразрывной струёй
Радость отдельных людей по поводу обнаружения своей специальности всё равно что пленники, которые радуются, что их не убьют, а всего лишь отрубят руки.
«Three organs...three organs!.. better than termination!» — фраза персонажа Стенли Твидла, персонажа одного старого фантастического сериала, который всё же согласился на принудительное изъятие трёх органов в качестве наказания за высосанную из пальца провинность, правда решился на за минуту до закрытия центра отправления наказаний и не успел туда попасть, за что был приговорён к уничтожению.
По-моему проблему надо решать на другом уровне и не вопросом того, кто получит освобождение от могилизации.
Спрос на сишников стабильный в каком масштабе? В масштабе последних пары лет? Возможно, да, стабильный, точнее стабильно низкий. Если бы не шло третье десятилетие, как я пишу на Си, я бы поверил в ваш оптимизм.
С короновирусом случилась величайшая несправедливость, как мне кажется: виноваты в закреплении варианта через «а» тупые журналисты и несознательные переводчики.
Писать «коронавирус» мне настолько же больно и неудобно, как писать вагонаопрокидыватель, волнарез или волнавод.
В 2012 меня пригласили в один околомедицинский стартар из долины. Хотя я был приглашён сделать один весьма низкоуровневый механизм, которым стали бы пользоваться люди, занимающиеся бизнес-логикой, и оставить им его, я сам остался в проекте и тоже стал заниматься бизнес-логикой.
В проекте БД использовалась именно как «тупое хранилище». Все проверки, обеспечивающие консистентность и поддерживающие благоразумие, были в PHP-коде бэкенда. Я стал агитировать за и планомерно собственноручно проводить трансформацию БД в умное хранилище. Потому что существовавшие проверки очень дурно пахли, а кроме того, как оказалось, в коде проекта совершенно не придерживались DRY-идеологии, так что одна и та же сущность в БД могла порождаться не из одного, а из множества разных мест, разбросанных по коду, и эти места даже не всегда были результатом копи-паста, так что в каждом месте был свой способ и набор проверок, не всегда тождественных
В какой-то момент в проект вернулся человек, который у руководителя проекта имел репутацию очень крутого программиста, и который в данном проекте был родоначальником кодовой базы, потом был тимлидом, когда у него появились подчинённые программисты, а потом оставил проект. Когда он, вернувшись, увидел мои нововведения в плане БД, он был в бешенстве. Руководитель проекта к моим новшествам относился скептически, этот бывший вернувшийся тимлид — резко негативно. Ох, сколько агрессивных баталий пришлось пройти, чтобы отстоять точку зрения, что СУБД должна сопротивляться попыткам запихнуть в неё ахинею. Чего я только не наслушался: что я отстал от жизни, что изобретаю велосипед, что это не соответствует современным канонам и портит весь проект... И, мол, тебя ведь пригласили писать низкоуровневые вещи и под дизассемблером реверсить то, что нам нужно — зачем ты суёшься в дизайн БД.
И это медицинский продукт, Карл! Одна забытая или неправильно проведённая проверка — и вот одна и та же машина скорой помощи с одним и тем же экипажем в одно и то же время должна ехать к двум совершенно разным пациентам в разных концах города. А там все проверки (те что на уровне PHP-бэкенда и в WET-духе при этом) были сделаны так, будто мир однопоточен и параллельно обрабатываемых бэкендом запросов и быть не может.
Что-то с трудом верится про микроволновку. Там такой фейлсейф...
Помимо того, что ряд концевых выключателей разбирает цепь питания магнетрона, нормально-замкнутые контакты этих же концевиков закорачивают питание магнетрона, так что даже если контакты где-то залипли, приварились, если где-то из-за повреждения изоляции питание шпарит в обход размыкающих концевиков, просто выгорит предохранитель.
Окей, глупость сморозил: я посчитал, что для формы
Bar(...);
под капотом вызывается operator new, хотя на самом деле экземпляр порождается на стеке и оператор new не вызывается.
Я точно знаю, что за А + Б скрывается вызов оператора + с аргументами А и Б
Нет, вы точно не знаете, что именно там вызывается. Возможно A и Б является числовыми переменными и происходит обычная арифметическая операция, а возможно это экземпляры классов (разных или одинаковых), для которых определён свой оператор сложения, а возможно они экземпляры классов, но для них определён operator int(), и два объекта приводятся к типу int и совершается банальная арифметика, а возможно только один из объектов приводится к типу int, потому что существует оператор сложения, работающий с классом и int в роли операндов.
Просто глядя на место в коде, где находится А+Б, вы не знаете заранее и наверняка, какая комбинация из приведений типов будет задействована и какая будет реализация оператора сложения будет вызвана.
В Си без плюсов вы знаете, что за А+Б стоит сложение с применением целочисленной или FP-арифметики. И (распространяя и обобщая), что если в коде вашей функции нет явных вызовов других функций, то говоря о результирующем машинном коде, там не будет инструкции CALL или заинлайненного кода какой-то другой функции. Зависимости и побочные эффекты очевидны. Но не в С++.
Стекло не пылит, если его не обрабатывать абразивным инструментом. Асбест, по видимому, пылит сам по себе, особенно от циклов намокания-высыхания, замерзания-разерзания.
Ну не храните воду в асбестовых кувшинах, на крыше то чем он вреден или в стене?
Мне сейчас вентиляцию в многоквартирном доме делают из асбесто-цементного листа. И как показывает обратный клапан, вентиляция не работает 100% времени как отточная — обратный клапан постоянно перекладывается из открытого положения в закрытое, а значит, если бы я его не установил, 50% времени воздух шёл бы из шахты вентиляции в квартиру.
В си вы знаете, что это вызов функции, куда передаётся возврат от другой функции. Вы знаете, что за вызовом каждой функции может скрываться в теории что угодно, а на практике из названия функции вы скорее всего понимаете, что примерно там будет происходить.
Но главное, что отследив историю изменений кода (например, git blame), вы знаете, что если эту строчку не меняли с момента написания, то суть происходящего здесь тоже не меняется (вызов двух функций). По крайней мере, даже просто окинув взглядом тело функции, где нет никаких Bar(Foo() или же наоборот есть, вы сходу, за долю секунду получаете представления о том, как выглядит call tree для родительской функции: вызывается ли отсюда что-либо ещё (что требует расмотрения, анализа, оптимизацию), или мы на «низшей ступени».
Но если переместиться в мир C++, то и за A+B может стоять что угодно (вплоть до вызова sleep или показ какого-то UI — это конечно пример чудовищного говнодизайна приложения, но эта возможно), и за Bar(Foo()) может скрываться не только вызов функции, но и порождение экземпляра классов Foo или Bar, если вдруг это классы. А за порождением экземпляров может (и будет) скрываться обращение к куче, причём оператор new может быть перегружен и это может оказаться какая-то специальная, возможно не самая эффективная куча. То есть за тем, что выглядит как простой вызов функции, может скрываться что-то, что в 10 000 раз тяжелее, чем простой вызов функции. К тому же, если у конструктора Foo тип аргумента не Bar, а какой-то другой, возможно сработает неявное приведение типа.
Я не говорю, что то, что я выше написал — это однозначное зло. В конце-концов, иначе С++ оказался бы в аутсайдерах. Но это и не однозначное добро. По крайней мере, это как со старыми жигулями: если там на приборной панели показывается, что давление масла нормальное и температура охлаждающей жидкости в порядке — значит так оно и есть. А примеры из современной техники, когда, скажем, устройство показывает завышенный заряд батареи, чтобы пользователь думал, что устройство способно долго сохранять заряд. Реальный заряд маппится на отображаемый функцией с как бы выгнутым графиком. Зато потом, когда устройство на издыхании, отображаемый процент заряда начинает быстрыми темпами приближаться к нулю.
Проблема в том, что когда вы видите foo+bar в сишном коде, вы знаете, что здесь происходит. Но в cpp-коде то же самое может означать что угодно, за этим может скрываться миллион неочевидных операций. Придётся распутывать клубок наследований, перегрузок.
А зачем? У вас цель в решении задачи, в создании программного продукта, или же в абстрактном следовании фен-шую ради следовании фен-шую?
Если решить задачу с применением олдскульных подходов получается быстрее и проще, может это повод задуматься, что не всё так хорошо с новомодными подходами?
Видео с насосом из МОТа это такой лютый фейк, что рука тянется поставить автору минус. Не из злорадства, но, пардон, это насколько надо быть лишённым критического мышления, чтобы такое включать в статью?
В МГД-установке должен быть и источник магнитого поля, и источник перпендикулярного электрического. Должно быть два электрода, которые пропускают через рабочее тело ток. У него такими электродами могли бы быть две половинки трубы, распиленной продольно пополам. Я всё ждал, когда он будет пилить трубу, но он так и не стал. Никакого подвода проводов к электродам, да и отсутствие самих электродов.
Магнитное поле у него переменное. Воздушный зазор в сердечнике огромный. Может быть какие-то токи там и возникают, но только токи Фуко в самой трубе.
А самое главное, обратного клапана на трубе нет. Наверное установка ещё и вакуум умеет создавать в пустой трубе, чтобы подсосать туда первоначальную порцию воды и начать работать с безразрывной струёй
Радость отдельных людей по поводу обнаружения своей специальности всё равно что пленники, которые радуются, что их не убьют, а всего лишь отрубят руки.
«Three organs...three organs!.. better than termination!» — фраза персонажа Стенли Твидла, персонажа одного старого фантастического сериала, который всё же согласился на принудительное изъятие трёх органов в качестве наказания за высосанную из пальца провинность, правда решился на за минуту до закрытия центра отправления наказаний и не успел туда попасть, за что был приговорён к уничтожению.
По-моему проблему надо решать на другом уровне и не вопросом того, кто получит освобождение от могилизации.
Keep It Simple, Stupid
Спрос на сишников стабильный в каком масштабе? В масштабе последних пары лет? Возможно, да, стабильный, точнее стабильно низкий. Если бы не шло третье десятилетие, как я пишу на Си, я бы поверил в ваш оптимизм.
И много вы таких знаете, кто идентифицирует себя как фортранист и может похвастаться, что с поиском работы проблем нет?
Тут уже, будучи сишником, понимаешь, что перспективы далеко не радужные.
С короновирусом случилась величайшая несправедливость, как мне кажется: виноваты в закреплении варианта через «а» тупые журналисты и несознательные переводчики.
Писать «коронавирус» мне настолько же больно и неудобно, как писать вагонаопрокидыватель, волнарез или волнавод.
Когда научились в копирайтинг, но не научились в физику.
В 2012 меня пригласили в один околомедицинский стартар из долины. Хотя я был приглашён сделать один весьма низкоуровневый механизм, которым стали бы пользоваться люди, занимающиеся бизнес-логикой, и оставить им его, я сам остался в проекте и тоже стал заниматься бизнес-логикой.
В проекте БД использовалась именно как «тупое хранилище». Все проверки, обеспечивающие консистентность и поддерживающие благоразумие, были в PHP-коде бэкенда. Я стал агитировать за и планомерно собственноручно проводить трансформацию БД в умное хранилище. Потому что существовавшие проверки очень дурно пахли, а кроме того, как оказалось, в коде проекта совершенно не придерживались DRY-идеологии, так что одна и та же сущность в БД могла порождаться не из одного, а из множества разных мест, разбросанных по коду, и эти места даже не всегда были результатом копи-паста, так что в каждом месте был свой способ и набор проверок, не всегда тождественных
В какой-то момент в проект вернулся человек, который у руководителя проекта имел репутацию очень крутого программиста, и который в данном проекте был родоначальником кодовой базы, потом был тимлидом, когда у него появились подчинённые программисты, а потом оставил проект. Когда он, вернувшись, увидел мои нововведения в плане БД, он был в бешенстве. Руководитель проекта к моим новшествам относился скептически, этот бывший вернувшийся тимлид — резко негативно. Ох, сколько агрессивных баталий пришлось пройти, чтобы отстоять точку зрения, что СУБД должна сопротивляться попыткам запихнуть в неё ахинею. Чего я только не наслушался: что я отстал от жизни, что изобретаю велосипед, что это не соответствует современным канонам и портит весь проект... И, мол, тебя ведь пригласили писать низкоуровневые вещи и под дизассемблером реверсить то, что нам нужно — зачем ты суёшься в дизайн БД.
И это медицинский продукт, Карл! Одна забытая или неправильно проведённая проверка — и вот одна и та же машина скорой помощи с одним и тем же экипажем в одно и то же время должна ехать к двум совершенно разным пациентам в разных концах города. А там все проверки (те что на уровне PHP-бэкенда и в WET-духе при этом) были сделаны так, будто мир однопоточен и параллельно обрабатываемых бэкендом запросов и быть не может.
Оба фактора могут присутствовать одновременно.
Ну не совсем так, мёртвые тела разбирались на полезные запчасти, из них собирались жуткого вида роботы.
Что-то с трудом верится про микроволновку. Там такой фейлсейф...
Помимо того, что ряд концевых выключателей разбирает цепь питания магнетрона, нормально-замкнутые контакты этих же концевиков закорачивают питание магнетрона, так что даже если контакты где-то залипли, приварились, если где-то из-за повреждения изоляции питание шпарит в обход размыкающих концевиков, просто выгорит предохранитель.
А я наоборот мечтаю о возможности форкнуться и распараллелить между форками все те задачи, которые мы свалились на меня одного.
Окей, глупость сморозил: я посчитал, что для формы
под капотом вызывается operator new, хотя на самом деле экземпляр порождается на стеке и оператор new не вызывается.
Нет, вы точно не знаете, что именно там вызывается. Возможно A и Б является числовыми переменными и происходит обычная арифметическая операция, а возможно это экземпляры классов (разных или одинаковых), для которых определён свой оператор сложения, а возможно они экземпляры классов, но для них определён operator int(), и два объекта приводятся к типу int и совершается банальная арифметика, а возможно только один из объектов приводится к типу int, потому что существует оператор сложения, работающий с классом и int в роли операндов.
Просто глядя на место в коде, где находится А+Б, вы не знаете заранее и наверняка, какая комбинация из приведений типов будет задействована и какая будет реализация оператора сложения будет вызвана.
В Си без плюсов вы знаете, что за А+Б стоит сложение с применением целочисленной или FP-арифметики. И (распространяя и обобщая), что если в коде вашей функции нет явных вызовов других функций, то говоря о результирующем машинном коде, там не будет инструкции CALL или заинлайненного кода какой-то другой функции. Зависимости и побочные эффекты очевидны. Но не в С++.
Стекло не пылит, если его не обрабатывать абразивным инструментом. Асбест, по видимому, пылит сам по себе, особенно от циклов намокания-высыхания, замерзания-разерзания.
Мне сейчас вентиляцию в многоквартирном доме делают из асбесто-цементного листа. И как показывает обратный клапан, вентиляция не работает 100% времени как отточная — обратный клапан постоянно перекладывается из открытого положения в закрытое, а значит, если бы я его не установил, 50% времени воздух шёл бы из шахты вентиляции в квартиру.
В си вы знаете, что это вызов функции, куда передаётся возврат от другой функции. Вы знаете, что за вызовом каждой функции может скрываться в теории что угодно, а на практике из названия функции вы скорее всего понимаете, что примерно там будет происходить.
Но главное, что отследив историю изменений кода (например, git blame), вы знаете, что если эту строчку не меняли с момента написания, то суть происходящего здесь тоже не меняется (вызов двух функций). По крайней мере, даже просто окинув взглядом тело функции, где нет никаких Bar(Foo() или же наоборот есть, вы сходу, за долю секунду получаете представления о том, как выглядит call tree для родительской функции: вызывается ли отсюда что-либо ещё (что требует расмотрения, анализа, оптимизацию), или мы на «низшей ступени».
Но если переместиться в мир C++, то и за A+B может стоять что угодно (вплоть до вызова sleep или показ какого-то UI — это конечно пример чудовищного говнодизайна приложения, но эта возможно), и за Bar(Foo()) может скрываться не только вызов функции, но и порождение экземпляра классов Foo или Bar, если вдруг это классы. А за порождением экземпляров может (и будет) скрываться обращение к куче, причём оператор new может быть перегружен и это может оказаться какая-то специальная, возможно не самая эффективная куча. То есть за тем, что выглядит как простой вызов функции, может скрываться что-то, что в 10 000 раз тяжелее, чем простой вызов функции. К тому же, если у конструктора Foo тип аргумента не Bar, а какой-то другой, возможно сработает неявное приведение типа.
В Си то, что выглядит как утка, является уткой.
Я не говорю, что то, что я выше написал — это однозначное зло. В конце-концов, иначе С++ оказался бы в аутсайдерах. Но это и не однозначное добро. По крайней мере, это как со старыми жигулями: если там на приборной панели показывается, что давление масла нормальное и температура охлаждающей жидкости в порядке — значит так оно и есть. А примеры из современной техники, когда, скажем, устройство показывает завышенный заряд батареи, чтобы пользователь думал, что устройство способно долго сохранять заряд. Реальный заряд маппится на отображаемый функцией с как бы выгнутым графиком. Зато потом, когда устройство на издыхании, отображаемый процент заряда начинает быстрыми темпами приближаться к нулю.
Проблема в том, что когда вы видите foo+bar в сишном коде, вы знаете, что здесь происходит. Но в cpp-коде то же самое может означать что угодно, за этим может скрываться миллион неочевидных операций. Придётся распутывать клубок наследований, перегрузок.
А зачем? У вас цель в решении задачи, в создании программного продукта, или же в абстрактном следовании фен-шую ради следовании фен-шую?
Если решить задачу с применением олдскульных подходов получается быстрее и проще, может это повод задуматься, что не всё так хорошо с новомодными подходами?
Я ещё со времён висты/семёрки кричал, что все выравнивания элементов везде, где только можно, похерены.
Но все молча проглотили. Хорошая же ОС, аэро-фигаэро, чо там!
Они нужны, полезны и частоиспользуемы в любой сфере, если только вы не работаете в сфере написания Hello world программ.
5) Перепробовав гору аутсорсерлв, снова хочет все писать сам