Не было в «старом добром прошлом» такой мощной автоматической аналитики для нашего поведения, и уж тем более никогда она не была такой персонализованой. Не оно.
Не было. Но из того, что чего-то не было, не следует, что это плохо или усугубляет проблему.
Статья утверждает, что к 21 веку проблема ещё сильнее усугубилась
Утверждает. Но это не так. К 21 веку проблема стала менее опасной и сейчас гораздо меньше шансов, что новый Гитлер убедит десятки миллионов своих соотечественников убивать себе подобных. Ну либо мы считаем, что подобное поведение — личный выбор отдельно взятого немца.
Короче, в комнате слон, которого стараются не замечать, потому что мозги заполонила пелена «старого доброго прошлого». Что довольно забавно в контексте «давайте мыслить критически».
Так а я о чем. Но в тексте написано про 21 век. Но пик единообразия и отсутствия выбора - век 20й. Хотя в 19м крепостным тоже не особо разнообразно было. Поэтому я и говорю, что выбор человека сейчас силён как никогда в истории.
Иными словами, статья основана на продаже несуществуюшего "старого доброго прошлого".
<i>Но в ХХІ веке случилась перемена. Первое — что большую часть своей познавательной деятельности человек стал проводить в интернете. Второе — что информационную среду человека перестал определять его выбор, будь то выбор газеты, бара или места жительства. </i>
Автор старательно пытается не замечать слона под названием "телевидение" и феномен массовой культуры второй половины 20 века, по сравнению с которым звезды 21 века - детский сад. Сейчас информационная среда определяется выбором человека как никогда в истории.
Абстрактно я понимаю. Но как это происходит в статье из Nature? Я там понял только что есть частицы которых пространство Минковского туда-сюда дергает. А нелокальность в какой момент появляется?
а вся его сумасшедшая сложность на 99.9% является либо издержками техпроцесса, либо просто балластом
Современные продукты кроссплатформенны, имеют много UI фишечек, могут работать в лагающей интернет-среде, многие автоматизируются (побочный эффект перехода на клиент-сервер и текстовые протоколы), а по качеству несравнимы с типичным для нулевых синхронным локальным windows-only кодом.
Можно, конечно, сказать, «а вот %проганейм% так могла в 2003, а сейчас %другаяпроганейм% так не может», но это будет ошибкой аргументации. Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.
Это будет разница между чертежом и инструкцией по эксплуатации. Я не знаю, кто ввинтил этот тупейший мем в массовое сознание.
Тупейший мем — это представление, что код не является частью конструкторской документации, а что это что-то типа пола, стен, потолка и прочие стоительно-машиностроительные метафоры.
Мой пост был о проектировании. Для документации UML в целом не плох и скорее даже хорош. Спасибо за посты с утилитами, положил в копилку многое. Но излишне подробная документация — зло, потому что через 10 лет никому эти подробности вперемежку с багами не будут нужны.
carto.com/blog/london-vs-new-york-building-heights ниочом
Ниочом — это основывать свою картину мира на неверных предпосылках, а потом чисто из принципа отстаивать ее. Чините факты об окружающем мире, а потом обсудим, что дешевле, человейники, или ИЖС.
Фотография_нью_йорка.жпг. tinyurl.com/2zcacfv2 s/продавайте/раздавайте даром/, чего уж ;)
Можно вместо паясничания какие-нибудь аргументы к моему тексту? Вот к конкретным моим словам, а не собственным додумываниям.
Строители строят многоэтажные человейники не потому что не умеют в одноэтажные котеджи на берегу живописной реки, а потому что так дешевле.
Так дешевле в коррупционной среде. Чиновник предпочитает брать взятки редко и от своих. Поэтому вкусные земли продаются по нерыночным ценам своим, и это создает дешевизну для этих самых своих. Ну то есть, за бюджет города в поле строится метро, а земля вокруг распродается подешевке. Естественно, что в такой ситуации будут сплошные человейники: это все дармовые деньги и никому возиться с индивидуальным жильем не интересно.
А на честном рынке ИЖС бьет человейники на раз-два, мировой опыт это показывает. Технологии-то проще намного. Транспорт — ну а вы продавайте землю у метро по рыночным ценам, и посмотрим, кто предложит больше, геттостроители, или средний класс, мечтающий свалить из своего хруща у ТТК. Но если строительная техника стоит — она приносит большие убытки. Поэтому если у заммэра племянник владеет строительной фирмой — она будет строить то, что умеет, а не то, что нужно рынку. Рынок — подождет.
Бывает крупносерийное, мелкосерийное и единичное производство, а также опытное. Отличаются они отношением стоимости выпуска партии к стоимости выпуска изделия. У разработки ПО оно примерно 1:1, оно максимально близко к опытному производству. Нет, миллионы потребителей ситуацию не меняют. Так же, как крупносерийным производством не является съемка фильмов, хотя баги в продукте могут огорчить миллионы. Это все равно штучная работа, которая потом тиражируется безо всяких усилий.
Опытные образцы на любом фольксвагене изготавливают свои Петровичи — у них свои станки, заточенные именно под штучную работу, свои бюджеты, и вообще сплошной аджайл. А далее возникает головная боль — адаптация к конвееру. И начинается — мелкая серия, испытания, крупная серия, испытания. Так много испытаний не потому что опытные образцы менее надежные, они более надежные, потому что разработчики их изучали под микроскопом, а потому что каждый этап масштабирования производства вносит новые ошибки и неопределенность.
В программировании же проблемы «адаптации к конвееру» нет. Та конструкторская документация, которая собирает опытный образец, точно так же собирает и миллион образцов. А если хочется надежности — нужно много QA, чудес не бывает. Софт ненадежен, потому что экономят на QA. В том числе и потому, что недобросовестные просиживатели штанов предпочитают программировать в визио и «ой, мы ща как макулатуры наплодим — и будет все надежно-надежно, платите мне, а не тестерам». Ну да блин, архитекторы у нас — гении, которые умеют программировать в визио и учитывать все нюансы. Знаем таких.
Такой подход в прошлом — результат того, что менджмент компаний компьютер первый раз в жизни увидел в 30 лет. Они тупо перенесли привычные практики, не очень понимая их суть. Глупо ожидать чего-то иного, если им для перехода на удаленку потребовался целый ковид. Но софт тех лет такая же забагованная хрень, как и всегда.
Только вот чтобы замоделировать паровоз, нужен чертеж паровоза.
Здесь же предлагается перед созданием чертежа паровоза сначала сделать UML-модель чертежа паровоза, в которой все нюансы вплоть до габаритных размеров отдельных деталей уже учтены, и, только построив эту модель, приступать, собственно, к черчению.
Чтобы связать морду и железо нужен четко очерченый протокол.
Как можно разработать четко очерченый протокол, не разработав его референсную имплементацию?
А если есть референсная имплементация — зачем нужно дублировать ее в виде UML?
По мне это просто уход от ответственности — когда архитектор вместо референса программирует в ворде и в случае косяков виноват кто угодно, но не он.
А далее вместо простейшего юнит-теста с обращением к референсу, приходится ломать глаза, вглядываясь в диаграмму и пытаясь понять, кто из вас троих мудак — ты, автор диаграммы, или автор программы на другом конце протокола.
Так мы о проектировании говорим, а не документировании. Цитата: «И если не продумать все в деталях, то вероятность запороть проект взлетит до небес.»
То есть делается утверждение: для проектирования нужно не брать редактор кода и не пилить там скрипт, делающий «основную деятельность программы», без излишних подробностей, а брать какую-то визуальную тулзу, и проектировать в ней, дебажа поведение общающихся конечных автоматов в уме. И якобы это ведет к лучшим продуктам.
Вот мне это вообще не очевидно.
Наоборот, чтобы описать коммуникационную стурктуру каждого компонента, там очень даже нужны диаграммы последовательности, диаграмма деятельности, блок-схемы и пр.
Почему это просто не закодировать?
Не было. Но из того, что чего-то не было, не следует, что это плохо или усугубляет проблему.
Утверждает. Но это не так. К 21 веку проблема стала менее опасной и сейчас гораздо меньше шансов, что новый Гитлер убедит десятки миллионов своих соотечественников убивать себе подобных. Ну либо мы считаем, что подобное поведение — личный выбор отдельно взятого немца.
Короче, в комнате слон, которого стараются не замечать, потому что мозги заполонила пелена «старого доброго прошлого». Что довольно забавно в контексте «давайте мыслить критически».
Так а я о чем. Но в тексте написано про 21 век. Но пик единообразия и отсутствия выбора - век 20й. Хотя в 19м крепостным тоже не особо разнообразно было. Поэтому я и говорю, что выбор человека сейчас силён как никогда в истории.
Иными словами, статья основана на продаже несуществуюшего "старого доброго прошлого".
<i>Но в ХХІ веке случилась перемена. Первое — что большую часть своей познавательной деятельности человек стал проводить в интернете. Второе — что информационную среду человека перестал определять его выбор, будь то выбор газеты, бара или места жительства. </i>
Автор старательно пытается не замечать слона под названием "телевидение" и феномен массовой культуры второй половины 20 века, по сравнению с которым звезды 21 века - детский сад. Сейчас информационная среда определяется выбором человека как никогда в истории.
Можно для тупых поподробнее?
Современные продукты кроссплатформенны, имеют много UI фишечек, могут работать в лагающей интернет-среде, многие автоматизируются (побочный эффект перехода на клиент-сервер и текстовые протоколы), а по качеству несравнимы с типичным для нулевых синхронным локальным windows-only кодом.
Можно, конечно, сказать, «а вот %проганейм% так могла в 2003, а сейчас %другаяпроганейм% так не может», но это будет ошибкой аргументации.
Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.
Это будет разница между чертежом и инструкцией по эксплуатации.
Я не знаю, кто ввинтил этот тупейший мем в массовое сознание.
Тупейший мем — это представление, что код не является частью конструкторской документации, а что это что-то типа пола, стен, потолка и прочие стоительно-машиностроительные метафоры.
ниочом
Ниочом — это основывать свою картину мира на неверных предпосылках, а потом чисто из принципа отстаивать ее. Чините факты об окружающем мире, а потом обсудим, что дешевле, человейники, или ИЖС.
tinyurl.com/2zcacfv2
s/продавайте/раздавайте даром/, чего уж ;)
Можно вместо паясничания какие-нибудь аргументы к моему тексту? Вот к конкретным моим словам, а не собственным додумываниям.
Так дешевле в коррупционной среде. Чиновник предпочитает брать взятки редко и от своих. Поэтому вкусные земли продаются по нерыночным ценам своим, и это создает дешевизну для этих самых своих. Ну то есть, за бюджет города в поле строится метро, а земля вокруг распродается подешевке. Естественно, что в такой ситуации будут сплошные человейники: это все дармовые деньги и никому возиться с индивидуальным жильем не интересно.
А на честном рынке ИЖС бьет человейники на раз-два, мировой опыт это показывает. Технологии-то проще намного. Транспорт — ну а вы продавайте землю у метро по рыночным ценам, и посмотрим, кто предложит больше, геттостроители, или средний класс, мечтающий свалить из своего хруща у ТТК. Но если строительная техника стоит — она приносит большие убытки. Поэтому если у заммэра племянник владеет строительной фирмой — она будет строить то, что умеет, а не то, что нужно рынку. Рынок — подождет.
Опытные образцы на любом фольксвагене изготавливают свои Петровичи — у них свои станки, заточенные именно под штучную работу, свои бюджеты, и вообще сплошной аджайл. А далее возникает головная боль — адаптация к конвееру. И начинается — мелкая серия, испытания, крупная серия, испытания. Так много испытаний не потому что опытные образцы менее надежные, они более надежные, потому что разработчики их изучали под микроскопом, а потому что каждый этап масштабирования производства вносит новые ошибки и неопределенность.
В программировании же проблемы «адаптации к конвееру» нет. Та конструкторская документация, которая собирает опытный образец, точно так же собирает и миллион образцов. А если хочется надежности — нужно много QA, чудес не бывает. Софт ненадежен, потому что экономят на QA. В том числе и потому, что недобросовестные просиживатели штанов предпочитают программировать в визио и «ой, мы ща как макулатуры наплодим — и будет все надежно-надежно, платите мне, а не тестерам». Ну да блин, архитекторы у нас — гении, которые умеют программировать в визио и учитывать все нюансы. Знаем таких.
Такой подход в прошлом — результат того, что менджмент компаний компьютер первый раз в жизни увидел в 30 лет. Они тупо перенесли привычные практики, не очень понимая их суть. Глупо ожидать чего-то иного, если им для перехода на удаленку потребовался целый ковид. Но софт тех лет такая же забагованная хрень, как и всегда.
Здесь же предлагается перед созданием чертежа паровоза сначала сделать UML-модель чертежа паровоза, в которой все нюансы вплоть до габаритных размеров отдельных деталей уже учтены, и, только построив эту модель, приступать, собственно, к черчению.
Можно еще с воробьями побороться.
Как можно разработать четко очерченый протокол, не разработав его референсную имплементацию?
А если есть референсная имплементация — зачем нужно дублировать ее в виде UML?
По мне это просто уход от ответственности — когда архитектор вместо референса программирует в ворде и в случае косяков виноват кто угодно, но не он.
А далее вместо простейшего юнит-теста с обращением к референсу, приходится ломать глаза, вглядываясь в диаграмму и пытаясь понять, кто из вас троих мудак — ты, автор диаграммы, или автор программы на другом конце протокола.
То есть делается утверждение: для проектирования нужно не брать редактор кода и не пилить там скрипт, делающий «основную деятельность программы», без излишних подробностей, а брать какую-то визуальную тулзу, и проектировать в ней, дебажа поведение общающихся конечных автоматов в уме. И якобы это ведет к лучшим продуктам.
Вот мне это вообще не очевидно.
Почему это просто не закодировать?