Если не считать требование к фичи, которые как-бы по умолчанию должны быть раньше кода, то по моему опыту писать документ вместо кода в подавляющем большинстве случаев малопродуктивно.
Потому что документ, в отличии от кода, невозможно отладить, протестировать и т.д. и т.п. И когда заставлют писать, скажем дизайн перед кодом, то получается, что придумали какой-то более менее рабочий дизайн, написали документ, пошли писать код и столкнулись с какой-то проблемой. Код правится чтобы обойти эту проблему, на дизайн все уже забили, он же уже написан!. и в результате дизайн не отражает код и в таком виде практически не имеет никакой ценности.
Возможно, если вместо текста использвоать какие-то специальные инструменты (ну например, пример из головы, какой-нибудь анализатор SQL запросов), то это могло бы быть эффективней написание кода, но простой текст и/или диаграмки все-же не тянут.
На эту тему недавно здесь на хабре была статейка в которой предлагалась писать дизайн на некотором формализованном языке и "тестировать" ее относительно кода, вот в таком подходе возможно было-бы все лучше, но и то я думаю написать хороший дизайн перед написанием когда целиком никогда не получится, максимум итеративный подход, когда на первой итерации прикидываем какой-то подход, пробуем его закодировать, вылавливаем проблеммы, исправляем паралелльно дизайн и код. И чтобы документ реально исправлялся нужны автоматические инструменты, типа "тестов" соответсвия дизайна-кода, иначе нельзя быть уверенным, что дизайн актуален.
Мне кажется вы перепутали документацию "о программе" и требования "к программе". Хотя чисто формально требования и можно считать документацией, но на смом деле они практически ничего вам не скажут о программе. 10 программистов получив одни и те-же требоваия напишут 10 разных программ.
А вот когда идет речь про документацию "о программе": дизайн, описание интерфеса, user manual тот-же самый и т.п., то это уже реально "выдержка из комментариев", плюс в 99% случаях не соответсвует реальной программе, т.к. код првится часто (баги-то надо править), а документация только когда прижмет.
Для автопилотов низкого уровня вы безусловно правы. Я если честно вообще не понимаю зачем оно надо, ну кроме разьве что хоть как-то отбить инвестиции во всю эту историю... Со всех остальных точек зрения глупость сплошная.
А вот для полного автопилота уже все по-другому. Всяким агрегаторам такси, перевозчикам грузов и т.д. и т.п. гораздо выгодней потратиться один раз на автопилот, чем постоянно платить водителям зарплату.
Потому что в C/C++ все функции - это функции. Тавталогия да. Я это к чему: если назвать этот класс функций просто функциями, то как понять о каких функциях идет речь? А так выделили "функции реализующие стандартные алгоритмы обработки информации" в отдельный "модуль", назвали его "алгоритмы" и всем сразу понятно о чем речь.
Для меня это немного больная тема, т.к. у нас в одном легаси проекте какие-то умники сделали класс Function, от которого наследуются "функции", которые рализуют БЛ. И вот очень блин все время выбешивает когда надо эти классы как-то обозвать...
И здесь создается впечатление, что закон ориентируется в первую очередь на бум беспилотных авто в бизнесе, а не частном секторе.
И это логично. Как только все составляющие (техническая, юридическа, моральная и .т.д.) "сойдутся". То частных владельцев будут выдавливать со страшной силой, потому что они никому, кроме производителей автомобилей, нафиг не упали.
Техническая грамотность "специалистов" поражает. Не могу ничего сказать насчет Apple, разумееется, а вот на Android-е "механизм блокировки краденных устройств" действует с точностью до наоборот от описанного "специалистом", т.е. блокирует телефон именно после перепрошивки. А если речь идет о функции "Find my phone", которой в том числе можно блокировать телефон, так ее несложно выключить на телефоне в настройках и никакой блокировки...
На мой взгляд критика с одной стороны справедливая, потому что "по сути" все так и есть и все перечисленные недостатки присутсвуют.
Но с другой стороны, не совсем корректная, т.к. очевидно, что человек применил свой подход именно в той предметной области и к тем проектам с которыми он работает, и ввел ограничения удобные именно для его ситуации. Сразу строить систему которая бы охватывала все возможные случаи и подходила бы всем и каждуому было-бы невозможно чисто по временным и техническим (надо на чем-то это все тоже тестировать!) причинам.
Тут скорее тем кому не подходит это решение в лоб нужно творчески подойти к вопросу и если можно так выразиться провести "рефакторинг", чтобы расширить возможности применения этой идеи.
Ну почему, зависит от размера этой сети и насколько хорош движок по ее обсчету.
А вот то, что они предлагают использовть эту сеть в видеонаблюдении, при учете того, что во время восстановления видео сеть явно будет часть деталей "придумывать", это несколько кажется странным как минимум...
Ну строго говоря, раньше во времена "пионеров компьютерных наук", когда память измерялась дай бог килобайтами, а частоты процессоров единицами мегагерц, все эти знания "двоичной арифметики и архитектуры микропроцессоров" (про "глубокое знание полупроводников" это все-же перебор) были очень даже полезны. Но по мере увеличения мощностей железа и улучшения оптимизаторов все это стало не актуально, да.
Передача объекта как аргумент функции с лишним свойством
Помоему это совсем не проблема, и оно так работает во всех ООП языках. Всегда можно использовать объект с типом потомка там, где используется тип базового класса.
То что в TS "наследование" может быть неявным - это уже отдельный разговор...
А то, что возникает ошибка когда вы передаете литеральный объект - ну там просто не происходит "наследования" и лишние проперти уже лишние.
В начале этой статьи написан откровенный бред. Это еще можно было-бы понять когда люди смотрели на первые версии HarmonyOS "снаружи" и им было сложно понять как оно устроенло внутри. Но теперь-то HarmonyOS выложена в open source и любой желающий может увидеть, что там нет ни одной строчки из Android. Да, многие "идеологические" вещи китайцы из него передрали. Но код весь переписан с нуля.
В первых версиях был не "замаскированный" андроид, а обычная dual framework система, когда поверх linux-а и андроидного HAL-а параллельно работало 2 разных фреймворка: для андроидных приложений - андроидный, для хармони приложений - соответсвенно хармонивский. Сейчас они просто допилили свой HAL и выкинули андроид совсем. А не весь вот этот бред, что написан в начале...
Все-же не совсем соглашусь с вашим тезисом. Висит у меня в закладках огнелиса один сайт на котором минимум JS, его даже можно там отключить совсем и функционал просядет не сильно, только мелкие приятности пропадут. И разметка на нем довольно минималистична, т.е. браузер 2007 года потянет его без проблем. И все равно, когда я смотрю статистику потребления ресурсов эта закладка почему-то жрет 200-300Мб памяти, почему??? (Объем загружаемого HTML изменряется максимум в сотнях килобайт, графики практически нет).
А зачем человеку учить язык "для галочки" на уровень больший чем ему нужно? При этом не особенно важно для чего нужно, для работы, для игр, для чтения худлит. В большинстве случаев, когда появляется именно необходимость изучить язык, то он изучается до необходимого минимума, потому что дальше учить - лень и не имеет смысла.
На моем опыте, по-настоящему начал учить язык, только когда начал играть в англоязычные игры (еще в школе), потом продолжил чтением технической литературы, потом письменным общением по работе, потом устным общением по работе и наконец чтением художественной литературы. Не знаю какой у меня уровень, никогда не проходил никаких атестаций/экзаменов, но подозреваю что вряд-ли больше какого-нибудь Upper Intermediate и мне этого вполне хватает и я не собираюсь вкладываться в какие-нибудь курсы или что-то подобное, только для того чтобы иметь оффициальную бумажку.
Более того, даже с IT-шниками ситуация примерно такая-же :)
На своем опыте: общаемся с ними на английском, т.к. понятно мы не знаем китайский - они русский, так вот качество знания их IT-шниками английского нифига не лучше, чем у наших IT-шников, и даже где-то хуже, поскольку у нас был опыт общения с американцами, а у них видимо не особо...
Вот чесно не понял логики. Как могут хорошие юнит-тесты в этом случае быть вредными. У вас же нет тесов на модуль B, значит и уверенности в его корректности у вас быть не может. Такого рода ошибки отлавливаются интеграционными и E2E тестами, не важно автоматическими или ручными.
Например, когда президент (а не США) объявляет войну Вьетнаму, огромное число американцев (а не США) выходит на акции протеста.
Ну и почему-же того-же самого не случилось когда бомбили Югославию, нападали на Ирак и проводили кучу других, более мелких конфликтов по всему миру?
А ответ очень простой, против войны во Вьетнаме по большей части протестовали не по моральным соображениям, типа "мы мирные люди...", а потому что на эту войну забирали по призыву всех подряд. Это и было основной причиной многочисленных протестов. Как только США перешла на контрактную армию, так сразу все протесты против войн прекратились (ну наверно не совсем все, но массовые точно).
Да, были случаи, когда спецслужбы надавливали на бизнес, заставляя принимать решения согласно линии правящей партии.
Да не надо никаких спецслужб, что вы, достаточно принять "драконовские" законы за взаимодествие с российскими компаниями и физ. лицами как бизнесу вдруг сразу становится не выгодно работать с русскими. И все эти "моральные" оправдания всего-лишь для PR, так сказать сохраняем хорошую мину при плохой игре.
Не хотелось бы влезать в длинную морально-политическую дискуссию, но хотелось бы узнать ответ на один простой вопрос: почему все что делает США или другая сторона с одобрения США (члены НАТО), в том числе развязывание войны с другими странами - это морально, а если это не одобряется США - то это аморально. Естественно с точки зрения вот этого:
Это не "заговор западных элит" и не "ущемление по расовому признаку", это обычная человеческая мораль.
Чтобы удостовериться что текщий блок верен, достаточно старого состояния (оно уже записано в блокчейне), diff-а от старого состояния к новому (по сути сумма всех транзакций в блоке, этакий микро-миксер) и хэша нового состояния. Не обязательно хранить именно каждую транзакцию отдельно.
succinct blockchains - не изучал эту тему, но на первый взгляд движение в правильном направлении.
А в чем новость? Помоему винда уже больше года пытается при каждом обновлении "подсадить" на облачную учетку...
Если не считать требование к фичи, которые как-бы по умолчанию должны быть раньше кода, то по моему опыту писать документ вместо кода в подавляющем большинстве случаев малопродуктивно.
Потому что документ, в отличии от кода, невозможно отладить, протестировать и т.д. и т.п. И когда заставлют писать, скажем дизайн перед кодом, то получается, что придумали какой-то более менее рабочий дизайн, написали документ, пошли писать код и столкнулись с какой-то проблемой. Код правится чтобы обойти эту проблему, на дизайн все уже забили, он же уже написан!. и в результате дизайн не отражает код и в таком виде практически не имеет никакой ценности.
Возможно, если вместо текста использвоать какие-то специальные инструменты (ну например, пример из головы, какой-нибудь анализатор SQL запросов), то это могло бы быть эффективней написание кода, но простой текст и/или диаграмки все-же не тянут.
На эту тему недавно здесь на хабре была статейка в которой предлагалась писать дизайн на некотором формализованном языке и "тестировать" ее относительно кода, вот в таком подходе возможно было-бы все лучше, но и то я думаю написать хороший дизайн перед написанием когда целиком никогда не получится, максимум итеративный подход, когда на первой итерации прикидываем какой-то подход, пробуем его закодировать, вылавливаем проблеммы, исправляем паралелльно дизайн и код. И чтобы документ реально исправлялся нужны автоматические инструменты, типа "тестов" соответсвия дизайна-кода, иначе нельзя быть уверенным, что дизайн актуален.
Мне кажется вы перепутали документацию "о программе" и требования "к программе". Хотя чисто формально требования и можно считать документацией, но на смом деле они практически ничего вам не скажут о программе. 10 программистов получив одни и те-же требоваия напишут 10 разных программ.
А вот когда идет речь про документацию "о программе": дизайн, описание интерфеса, user manual тот-же самый и т.п., то это уже реально "выдержка из комментариев", плюс в 99% случаях не соответсвует реальной программе, т.к. код првится часто (баги-то надо править), а документация только когда прижмет.
Для автопилотов низкого уровня вы безусловно правы. Я если честно вообще не понимаю зачем оно надо, ну кроме разьве что хоть как-то отбить инвестиции во всю эту историю... Со всех остальных точек зрения глупость сплошная.
А вот для полного автопилота уже все по-другому. Всяким агрегаторам такси, перевозчикам грузов и т.д. и т.п. гораздо выгодней потратиться один раз на автопилот, чем постоянно платить водителям зарплату.
Потому что в C/C++ все функции - это функции. Тавталогия да. Я это к чему: если назвать этот класс функций просто функциями, то как понять о каких функциях идет речь? А так выделили "функции реализующие стандартные алгоритмы обработки информации" в отдельный "модуль", назвали его "алгоритмы" и всем сразу понятно о чем речь.
Для меня это немного больная тема, т.к. у нас в одном легаси проекте какие-то умники сделали класс Function, от которого наследуются "функции", которые рализуют БЛ. И вот очень блин все время выбешивает когда надо эти классы как-то обозвать...
И это логично. Как только все составляющие (техническая, юридическа, моральная и .т.д.) "сойдутся". То частных владельцев будут выдавливать со страшной силой, потому что они никому, кроме производителей автомобилей, нафиг не упали.
Техническая грамотность "специалистов" поражает. Не могу ничего сказать насчет Apple, разумееется, а вот на Android-е "механизм блокировки краденных устройств" действует с точностью до наоборот от описанного "специалистом", т.е. блокирует телефон именно после перепрошивки. А если речь идет о функции "Find my phone", которой в том числе можно блокировать телефон, так ее несложно выключить на телефоне в настройках и никакой блокировки...
На мой взгляд критика с одной стороны справедливая, потому что "по сути" все так и есть и все перечисленные недостатки присутсвуют.
Но с другой стороны, не совсем корректная, т.к. очевидно, что человек применил свой подход именно в той предметной области и к тем проектам с которыми он работает, и ввел ограничения удобные именно для его ситуации. Сразу строить систему которая бы охватывала все возможные случаи и подходила бы всем и каждуому было-бы невозможно чисто по временным и техническим (надо на чем-то это все тоже тестировать!) причинам.
Тут скорее тем кому не подходит это решение в лоб нужно творчески подойти к вопросу и если можно так выразиться провести "рефакторинг", чтобы расширить возможности применения этой идеи.
Ну почему, зависит от размера этой сети и насколько хорош движок по ее обсчету.
А вот то, что они предлагают использовть эту сеть в видеонаблюдении, при учете того, что во время восстановления видео сеть явно будет часть деталей "придумывать", это несколько кажется странным как минимум...
Ну строго говоря, раньше во времена "пионеров компьютерных наук", когда память измерялась дай бог килобайтами, а частоты процессоров единицами мегагерц, все эти знания "двоичной арифметики и архитектуры микропроцессоров" (про "глубокое знание полупроводников" это все-же перебор) были очень даже полезны. Но по мере увеличения мощностей железа и улучшения оптимизаторов все это стало не актуально, да.
Помоему это совсем не проблема, и оно так работает во всех ООП языках. Всегда можно использовать объект с типом потомка там, где используется тип базового класса.
То что в TS "наследование" может быть неявным - это уже отдельный разговор...
А то, что возникает ошибка когда вы передаете литеральный объект - ну там просто не происходит "наследования" и лишние проперти уже лишние.
Вы ошибаетесь, если вы можите читать код на C/C++ то можете сами сравнить открытый код HarmonyOS: https://gitee.com/openharmony и AOSP.
В начале этой статьи написан откровенный бред. Это еще можно было-бы понять когда люди смотрели на первые версии HarmonyOS "снаружи" и им было сложно понять как оно устроенло внутри. Но теперь-то HarmonyOS выложена в open source и любой желающий может увидеть, что там нет ни одной строчки из Android. Да, многие "идеологические" вещи китайцы из него передрали. Но код весь переписан с нуля.
В первых версиях был не "замаскированный" андроид, а обычная dual framework система, когда поверх linux-а и андроидного HAL-а параллельно работало 2 разных фреймворка: для андроидных приложений - андроидный, для хармони приложений - соответсвенно хармонивский. Сейчас они просто допилили свой HAL и выкинули андроид совсем. А не весь вот этот бред, что написан в начале...
Все-же не совсем соглашусь с вашим тезисом. Висит у меня в закладках огнелиса один сайт на котором минимум JS, его даже можно там отключить совсем и функционал просядет не сильно, только мелкие приятности пропадут. И разметка на нем довольно минималистична, т.е. браузер 2007 года потянет его без проблем. И все равно, когда я смотрю статистику потребления ресурсов эта закладка почему-то жрет 200-300Мб памяти, почему??? (Объем загружаемого HTML изменряется максимум в сотнях килобайт, графики практически нет).
А зачем человеку учить язык "для галочки" на уровень больший чем ему нужно? При этом не особенно важно для чего нужно, для работы, для игр, для чтения худлит. В большинстве случаев, когда появляется именно необходимость изучить язык, то он изучается до необходимого минимума, потому что дальше учить - лень и не имеет смысла.
На моем опыте, по-настоящему начал учить язык, только когда начал играть в англоязычные игры (еще в школе), потом продолжил чтением технической литературы, потом письменным общением по работе, потом устным общением по работе и наконец чтением художественной литературы. Не знаю какой у меня уровень, никогда не проходил никаких атестаций/экзаменов, но подозреваю что вряд-ли больше какого-нибудь Upper Intermediate и мне этого вполне хватает и я не собираюсь вкладываться в какие-нибудь курсы или что-то подобное, только для того чтобы иметь оффициальную бумажку.
Более того, даже с IT-шниками ситуация примерно такая-же :)
На своем опыте: общаемся с ними на английском, т.к. понятно мы не знаем китайский - они русский, так вот качество знания их IT-шниками английского нифига не лучше, чем у наших IT-шников, и даже где-то хуже, поскольку у нас был опыт общения с американцами, а у них видимо не особо...
Вот чесно не понял логики. Как могут хорошие юнит-тесты в этом случае быть вредными. У вас же нет тесов на модуль B, значит и уверенности в его корректности у вас быть не может. Такого рода ошибки отлавливаются интеграционными и E2E тестами, не важно автоматическими или ручными.
Ну и почему-же того-же самого не случилось когда бомбили Югославию, нападали на Ирак и проводили кучу других, более мелких конфликтов по всему миру?
А ответ очень простой, против войны во Вьетнаме по большей части протестовали не по моральным соображениям, типа "мы мирные люди...", а потому что на эту войну забирали по призыву всех подряд. Это и было основной причиной многочисленных протестов. Как только США перешла на контрактную армию, так сразу все протесты против войн прекратились (ну наверно не совсем все, но массовые точно).
Да не надо никаких спецслужб, что вы, достаточно принять "драконовские" законы за взаимодествие с российскими компаниями и физ. лицами как бизнесу вдруг сразу становится не выгодно работать с русскими. И все эти "моральные" оправдания всего-лишь для PR, так сказать сохраняем хорошую мину при плохой игре.
Не хотелось бы влезать в длинную морально-политическую дискуссию, но хотелось бы узнать ответ на один простой вопрос: почему все что делает США или другая сторона с одобрения США (члены НАТО), в том числе развязывание войны с другими странами - это морально, а если это не одобряется США - то это аморально. Естественно с точки зрения вот этого:
Чтобы удостовериться что текщий блок верен, достаточно старого состояния (оно уже записано в блокчейне), diff-а от старого состояния к новому (по сути сумма всех транзакций в блоке, этакий микро-миксер) и хэша нового состояния. Не обязательно хранить именно каждую транзакцию отдельно.
succinct blockchains - не изучал эту тему, но на первый взгляд движение в правильном направлении.