продолжая беседу

[juan_gandhi]

Т.к. есть такое европейское мнение, что рефакторинг - это метросексуальный аджальный метод продажи навоза юзерам, то я вдруг задумался - а что в Европе делают, когда их хакают и информацию воруют? Ну понятно, против воровства в Европе есть законы, например, GDPR; а в Швейцарии так даже масс шутинги запрещены (это мне швейцарцы когда-то сказали); но вот если случилось, так что тогда? Компьютеры сжигают на свалке, покупают новые, и пишут для них новые программы?

Ведь, я слышал, в Европе сначала на Z-notations и на Rational Rose весь дизайн правильно напишут, так что европейская программа не может быть неправильной, так что и рефакторить там нечего. Она совершенна.

И вот если она сломалась, то чо. Неужели с нуля переписывают?

Тесты-то понятное дело что не нужны; программист выполняет приказ менеджера, а менеджер не может ошибаться; и только плохой программист пишет код с ошибками. Немецкий код работает везде и без ошибок. Ой, тут сразу вспоминается Энигма, и три ушлых поляка, которые ее кракнули как раз перед Второй Мировой. 

Comments

[juan_gandhi]

Советы твитеру и фесбуку выглядят смешно, конечно.

[juan_gandhi]

Good point with GDPR. I'd like to see German Engineers designing their designs keeping in mind that GDPR will show up 10 years later, as well as all those Russian bots and viruses.

That's the thing with German Engineers, they are unaware that the world is changing all the time.

[juan_gandhi]

У меня уже давно подозрение, что такое явление объясняется страхом перед собственно программированием.

[vit_r]

Это когда Chrome падает, и его надо перезапускать, все видят.

Когда на немецком ICE перезапускают систему - это тоже все видят. Поезд стоит и ждёт, пока всё снова не запустится.

[anonim_legion]

>Твитер с фейсбуком
Говно.
>хром с андроидом
Дважды говно.

1.
Все мы знаем сайты с бесконечной прокруткой. Началось это безобразие с твиттера, потом дошло до Tumblr и далее везде. Пользователь докручивает страницу до низа, она снизу подгружается, и так без конца. Обычно это сопровождается отсутствием поиска по дате и вообще какого бы то ни было поиска.

Рано или поздно любая подобная страница начинает тормозить, потому что элементов в ней становится больше, чем способен вовремя обработать движок браузера и какие-то промежуточные скрипты на странице. Внимание, вопрос — а почему никто вместе с добавлением элементов в конец страницы не удаляет их из начала? То есть, после определённого количество "разрастаний" страницы, добавление каждого следующего элемента ленты влечёт за собой еще и удаление элемента из начала. В результате, страница будет иметь хоть и большой, но всё же конечный размер.

2.
Проблема: в некоторых случаях браузер жрёт немерянно много памяти. С недавних пор Firefox стал 64битным и не ограниченным адресным пространством в 2гб. Вдобавок, он еще и многопроцессный. Иногда, видимо из вредительских целей, вкладки с google translate на некоторых сайтах отжирают по 6 ГБ, а все процессы браузера - больше 12ГБ, и через некоторое время вся система уходит в жесткий своппинг.

В браузере такой настройки "не жрать, сука!" почему-то нет. Job objects, которые виндовые ограничения, не могут быть вложенными (начиная с Win 8 могут, но у меня Win 7), а Firefox уже использует оные job'ы для своих дочерних процессов, и еще одно ограничение наложить не получается.

Какая же дрянь это современное айти.

[anonim_legion]

>doesn't scale.

Doesn't web scale?

>We can start selling AWS service at the beginning of its lifecycle.
И это явление нужно засунуть обратно, туда, откуда оно вылезло. И еще добавить к софту гарантийные требования, вместо "AS IS".

[anonim_legion]

>...and your super-duper "postfix/dovecot" solution wouldn't need that, because...?

Да, не требует, в отличие от.

[anonim_legion]

У них деньги из тумбочки.

[sassa_nf]

"Думаете его проще спроектировать..., чем забабахать какой-нибудь data parsing & processing"

to the same level of completeness? ("nothing else left to fix" level)

yes, obviously.



"нет "market pressure for bug-free" code"

Of course. There is market pressure for MTTF and MTTR.

Intel doesn't have a production line for i5. They only have i7. Then i5 are those i7 that didn't pass the test (and subsequently the connections to the second thread of each core is burned out before packaging). Do you blame them for not sufficiently perfecting their i7 production line? It is the same thing as knowing how to sell bugs in the code.

[ppk_ptichkin]

А такое бывает? Я последний раз ездил в немецком поезде лет 6 назад, и это было в Китае...

[vit_r]

Всякое бывает. Пассажирам, естественно, не объявляют, из-за чего именно стоим.

[snowps]

Почему смешно? Они зарабатывают деньги и если эти деньги слабо зависят от того, говнокод у них или экстаз программистского совершенства, зачем вообще заморачиваться качественным бэкэндом? Если он будет работать на Скале и не падать каждые несколько дней, имея при этом эффективность в 10% от сишного бэкэнда, который должны были бы ваять дольше более квалифицированные и трудоспособные программисты, то никто из управленцев не будет париться и менеджмент благополучно выберет непадающий неэффективный говнокод вместо непадающего эффективного хорошего кода. That's how contemporary IT-business works, мы как-то с Пропессором это ещё в ЖЖ обсуждали и пришли к консенсусу.

[snowps]

То есть полагаете вот этот вот ящик проще спроектировать безглючным, чем код в каком-нибудь парсере? :) Я даже комментировать эту безграмотную оценку не буду, извините, особенно после упоминания ниже MTTF и MTTR.

Вы вообще представляете себе технологические проблемы чипмейкров и стоимость оборудования, к примеру, для фотолитографии (а также то, что их до сих пор выпускают всего три фирмы в мире, две из которых - японские, а третья - голландская)? Сравнить wafer production и программирование можно только при полном отсутствии хотя бы минимального инженерного кругозора.

[snowps]

Меняется не мир, а довольно тонкая пенка, которая на виду, активно себя пропагандирует и поэтому привлекает много внимания, а так-то фундамент по-прежнему базируется на старых проверенных технологиях, потому что на пенке фундамент не построишь. :)

[sassa_nf]

"в каком-нибудь парсере?"

no, the parser some team spent the same amount of time making as that box you are talking about. Why would you suggest to compare 200*2 year project and 1*2 weeks project, and then laugh about how clever you are?


"MTTF и MTTR"

is the real metric people care about. A lay owner of a hard drive has no interest in knowing how they achieve that: through man-hours spent on perfecting the design, or through quaruply-redundant hardware.


"при полном отсутствии хотя бы минимального инженерного кругозора."

that's a projection.

You can't seem to even discern the example of a wafer production line is exactly that: the production line actually utilizes redundancy to account for errors in the process. By no means am I comparing the quality. I am only pointing out that you think one of them as a feat of engineering worthy of worship, and the other - it's just engineers being lazy.


PS I don't even see why you choose to argue. In the other thread above you admit the same thing - different business requirements is the cause of a different development process, and a different way of achieving the necessary reliability. (More error-prone RoR twitter can be mitigated through higher redundancy, once it scales horizontally by design - there is no business need to perfect the design; it is even against the business goals, as perfecting the design extends the time to market.)

[juan_gandhi]

Talking about error-prone RoR twitter. RoR, being error-prone, was the reason for switching to Scala Lift. Which, I'm not sure, did it ever fail? Twitter was hacked once, but I don't believe it was because of Lift.

[juan_gandhi]

К вашему сведению, это не фундамент базируется на технологиях, а технологии на фундаменте. Который вы, почему-то, совершенно игнорируете.

[snowps]

Если имеется в виду математика, то это не реальный фундамент, а абстракция, blueprint, и если материалы при постройке по этому чертежу будут неудачные или проект не будет учитывать особенности климата, то вместо дома получится недоразумение, независимо от красоты первоначального замысла. И именно поэтому в Sagrada Familia невозможно сделать офис, в офисе из стекла и бетона с фриспейсом никому не придёт в голову делать квартиру, а гипсокартонные дома из bay area никто не будет строить на Аляске.

[thedeemon]

Curiously, even space probes get software updates and patches long after leaving Earth orbit.

Some fun bits here:
https://www.itworld.com/article/2823083/enterprise-software/88716-8-famous-software-bugs-in-space.html

[vit_r]

Уход в абстракции всегда чреват отрывом от предмета разговора.

Сейчас начнётся обсуждение того, какой фундамент фундаментальнее.

[snowps]

Именно потому, что Вам приходит в голову сравнивать по трудозатратам чисто программный проект длительностью разработки в две недели с аппаратно-програмным законченным автономным устройством на нестандартной элементной базе, которое должно работать в бродкаст-среде 24/7/365, я и не вижу смысла это далее обсуждать. Двумя постами выше я как раз и задал вопрос для того, чтобы выяснить, считаете ли Вы квалификацию инженера, который пишет двухнедельные чисто софтовые проекты, достаточной для участия в проектах проектирования устройств, подобных тому эффект-процессору, и Вы недвусмысленно ответили на него той ахинеей, которую я и ожидал. Давайте больше не будем об этом.

Нет, среднестатистических людей интересует то, сколько они скорости и надёжности получают за вложенный доллар. В мире финансового софта и компаний, получающих деньги от рекламы и социальной аналитики, ситуация иная, очень много лишних денег, поэтому в Гугле, Фейсбуке, Твиттере, Линктине и прочих аналогичных сервисах столько говнокода и плохих архитекторов системы, а нормальные программисты после нескольких лет работы там бегут оттуда, сломя голову, в другие конторы и персональные проекты.

Это не projection, а выводы на основе безграмотности Ваших комментариев, а уж являются ли они осознанной неправдой или незамутнённым отсутствием кругозора - я разбираться не буду.

Я спорю не с тем, что сущствуют разные потребности бизнеса, - это очевидно, - а с тем, что измерять удовлетворением локальных потребностей некомпетентного в кухне написания софта заказчика объективное качество создаваемого для него кода - это полное безумие; это всё равно как если бы на основе мнения человека, покупающего USB-флешку, которую он сломает или потеряет через месяц, делать вываоды о износостойкости используемой в ней MLC NAND.

[snowps]

Я в своё время общался с достаточным количеством академической публики и сделал устойчивое наблюдение: если люди избыточно озабочены теоретической стороной вопроса, они почти всегда считают практические аспекты чем-то ниже своего достоинства, не стоящими внимания мелочами, реализовывать которые надо поручать людям, очевидно находящимся с точки зрения просветлённых теоретиков в вопросах принятия решений ниже по иерархии, чем они. При этом люди часто были умнейшие, с прекрасно работающими мозгами и умеющие делать в сфере своих теоретических изысканий то, что остальные делать не могли, однако любое столкновение с элементарными практическими проблемами, выходящими за рамки их основной сферы интересов, почти всегда приводило их в полный ступор и им надо было разъяснять элементарные вещи, и предлагать совершенно очевидные решения, которые они не могли самостоятельно найти месяцами. Тут проблема не в том, какой фундамент фундаментальнее, а в потере дифференциации инструментов и целей. Цель любого программного продукта - это решение задач, которые человек сам решить не может из-за недостатка производительности и надёжности его умственного труда. Можно сколько угодно рассуждать о том, что ситуация изменилась, что сейчас проще купить сто серверов, чем заплатить программистам за оптимизацию, но это всё вторично, базовая цель осталась прежней: код должен быть максимально производительным для используемого железа и максимально надёжным. Для достижения этой цели можно пользоваться разными инструментами: оптимизацией математики, оптимизацией исполнения кода на железе, правильным построением кластерной архитектуры, проектированием и использованием специализированного железа и т.д., и т.п. Однако с начала этого века, со всеми этими доткомами, циркуляцией больших денег и преувеличенными ожиданиями, сформировался новый класс IT-публики, которая стала воспринимать программирование примерно как современные художники - своё "актуальное" искусство, где форма (выбор инструментов) стала преобладать над содержанием (целью). Оттуда и растёт это презрительное отношение к "ретро-технологиям" вроде использования ANSI C, процедурного программирования, желания создавать проекты как законченные решения, а не как компонент brand new and shiny cloud technology, поскольку именно это противопоставление "прогресса" "упадническому ретроградству" и приносит энтузиазм в деятельности. При этом - как и с современным искусством - в программировании прекрасно срабатывает стоппардовская мысль: "Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets. Imagination without skill gives us modern art." В приенении к программированию skill - это не умение писать код в своей конкретной области, а именно умение видеть картину целиком, от процессора до интерфейса, и именно это умение сейчас не только отсутствует у нового поколения, но и постоянно подвергается башингу, как не модное (как тут недавно прочитал у одного фаната клауд компьютинга "файлы - это скучно"). При этом - с чем никому не приходит в голову спорить, - это самое процедурное программирование, еретический си и низкий уровень - это та часть современной технологии, без которой не будет работать ни-че-го, и этот факт современное программистское псевдоискусство напрочь игнорирует, как неудобный и рушащий все иллюзии.

[sassa_nf]

"квалификацию инженера"

no, you didn't

[snowps]

Вот и поговорили, всё в лучших традициях. :)

[vit_r]

если люди избыточно озабочены теоретической стороной вопроса, они почти всегда считают практические аспекты чем-то ниже своего достоинства,

Люди озабочены тем, за что им платят деньги. Теоретики должны постоянно двигать новые теории и придумывать новые трюки. На утверждении, что старые технологии прекрасно работают, научную карьеру не сделаешь. Потому практика их не интересует. Если и интересуют, то они пытаются искать какое-нибудь необычное решение.

код должен быть максимально производительным для используемого железа и максимально надёжным.

Код должен решать задачу. После достаточно малозатратного достижения оптимальных величин стоимость дальнейшего увеличения как производительности, так и надёжности начинает расти экспоненциально.

А с нынешним уровнем разработчиков на многих задачах точка перелома достигается на таком уровне качества, что становится стыдно за человечество.