Ычан: [d | b / bro / gf / hr / l / m / med / mi / mu / o / ph / r / s / sci / tran / tu / tv / x | es / vg | au / tr | a / aa / abe / c / fi / jp / rm / tan / to / vn / vo]
[Назад] [Вся нить] [Последние 50 сообщений]
Ответ в нить
Имя
Animapcha image [@] [?]
Тема   ( ответ в 21353)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, XCF, ZIP размером до 5000 кБ.
  • Ныне 3097 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
155032195450.jpg-(63.68KB, 720×720, civilized_argument_popukko.jpg)
21353
No. 21353    
Попробуем создать нить, в которой уважаемые разработчики могут поспорить на любые темы:

— Какая IDE удобнее?
— Какой язык лучше?
— Какой фреймворк православнее?
— Agile или не Agile?
— ООП нужно, или не нужно?
— Настоящий разработчик вы, или нет?

Здесь разработчики смогут невозбранно обсудить эти, и другие животрепещущие а иногда и извечные темы.
Развернуть все изображения
No. 21357    
%очевидный вброс%
No. 21358    
>>21357
На самом деле, у нас просто появились диспутеры.
В частности >>21348 и >>21349 куны из нити для помощи.
Сама идея этой нити, кстати, тоже назревала давно.
No. 21364    
>>21358
Что-то спорщики сразу остыли.
No. 21367    
155038337266.jpg-(67.08KB, 960×720, 847339-milfeulle_sakuraba_1280x960_8.jpg)
21367
Что вы тут устроили, а меня не позвали?

>>21364
Ну, я ответ на свой вопрос «A или B» давно получил, на побочный вопрос «почему не C» ответил и позицию свою пояснил, надеюсь, понятно. Продолжать бесполезные споры о том, какой из “Best 100 JS template engine 2018” лучше, когда они все делают одинаковые вещи за одинаковое время, с боевыми Семёнами не вижу смысла.

Ну и лучше было бы сделать «Больных ублюдков тред», по аналогии с «Ненормальным программированием» на Хабре, где обсуждались бы странные вещи, вроде разбора бинарных данных перловыми регулярками это можно сделать, там флаг специальный есть.
No. 21368    
>>21367
>динаковые вещи
Да.
>за одинаковое время
Нет.
Если тебе три строчки отрендерить, то пофигу, а допустим на треде из 500 постов уже сильно заметно.
No. 21370    
>>21368
Специально замеряла время рендеринга этого >>19666 треда, когда парсер оптимизировала. На P4-M Northwood 1.2 GHz (режим энергосбережения) Opera Presto 12.18 оно составляет жалкие 0.15 s у Handlebars и JsRender. Надо ли говорить, что на более современных Лисе и Хроме рендеринг вообще пролетает со свистом, т.е. минимум в 5 раз быстрее. Инкрементальное обновление вообще находится на уровне погрешности измерения. Ни нада мне тут сказочки про тормоза рассказывать, я их сама кому хочешь могу рассказать. Разница замечается лишь при рендеринге от 100 тыс. элементов и выше.
No. 21404    
155117521687.jpg-(819.05KB, 1280×1024, galaxy_angel_36.jpg)
21404
>>21378
Строго говоря, аппаратных декодеров инструкций в процессорах нет со времён Windows XP, т.е. с 2003-го года. Даже в моём Нортвуде уже нет. Т.е. ваши х86 инструкции на лету преобразуются в последовательности внутренних инструкций процессора и весь экшон, вроде кэширования и предсказания, происходит уже с ними. Производитель процессора в свою очередь не только оставил за собой право менять таблицы трансляции по своему усмотрению, он изначально ввёл возможность менять их в рантайме. Посему ваш x86-ассемблер сейчас — это такая же абстракция, как и байткод в Бидоне или Джаве. Просто зацените юмор, если можете.
>Зависит от понимания понятия "понимать".
>Вот возьмём условие: if cond then trueBranch else falseBranch.
В 70-х было экспериментально доказано, что условные конструкции доступны для понимания шимпанзе, т.е. для их освоения антропоидами нужен просто язык в котором они есть.
Более сложный пример:
Код

Y := 0;
if X > 0 then
   Y := 1;
end if;

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

if X > 0 then
   Y := 1;
else
   Y := 0;
end if;

Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?
>Если же тебя интересует низкий уровень - что там во что транслируется, и куда переходы генерируются, то митовский курс как раз заставляет тебя пилить самый обычный современный ARM-процессор.
99% упирающихся лбом в производительность людей, интересует, как работает конкретный процессор или семейство процессоров с которыми им приходится работать, а не сферическая теория в вакууме. А поскольку производители процессоров такой инфой делиться не хотят, лично я предпочитаю аутировать в виртуальной машине и пинать производителя за то, что эта машина на его процессорах медленно работает.
>Сишка живее всех живых.
>Кресты переживают второе рождение.
Кто-то пишет на них не под конкретное железо?
>А у тебя весь мир жабой ограничивается.
У вас. Я про Тьюрингову яму не просто так вспоминала.
>А так же модные нынче штуки уровня input.split(x).map(split(y)).flatten().filter(a).map(b).filter(c).reduce(w).
Это и есть лапша в функциональном стиле. Чем она вам не нравится? Вы же сами советуете припасть к ключу мудрости ФП, только забываете о проблемах ФП, над которыми лучшие умы 20-ть лет бились.
>А потом я сижу за таким вот веб-сайтом и удивляюсь, как сраная страничка может отжирать полгига памяти и тормозить.
А я вот смотрю на страницу с темами у Лисы: туда горе-дизайнер напихал CSS-анимаций, они грузят проц на 100% и вешают лису намертво. А у вас всё Джава виновата.
Ну и вообще, любая оптимизация — это дополнительный код и дополнительная сложность. Люди, которые не знают, куда деть 128 GB RAM, за них платить не хотят. Так какого беса ради кто-то должен бесплатно снижать, допустим, потребление памяти с _n!_ до хотя бы _n^3_ ?
No. 21407    
>>21404
> Строго говоря, аппаратных декодеров инструкций в процессорах нет со времён Windows XP, т.е. с 2003-го года. Даже в моём Нортвуде уже нет. Т.е. ваши х86 инструкции на лету преобразуются в последовательности внутренних инструкций процессора
Если бы аппаратного декодера не было, то приходилось бы преобразовывать ассемблерные инструкции в µops микропрограммой. В современных x86-процессорах (Transmeta не считается) такое делается только для сложных инструкций, для которых необходимо много µops, например для CPUID, POPF и IDIV. Ты, по-видимому, под "аппаратным декодером" имел в виду то, как было в Pentium MMX и ниже, но это конец 90-х, а не 2003.
> весь экшон, вроде кэширования и предсказания, происходит уже с ними.
Кэширование происходит с обычными инструкциями (но не в твоих Northwood и других NetBurst) и в некоторых процессорах также с микрооперациями (Intel, начиная с Sandy Bridge).
> он изначально ввёл возможность менять их в рантайме.
Ты имеешь в виду macro-op fusion (который не является полноценным изменением в run-time и по сути статичен) или обновление микрокода?
> 99% упирающихся лбом в производительность людей, интересует, как работает конкретный процессор или семейство процессоров с которыми им приходится работать, а не сферическая теория в вакууме. А поскольку производители процессоров такой инфой делиться не хотят
Для таких людей производители выпускают руководства по оптимизации и понаделали кучу счётчиков микроархитектурных событий.
> лично я предпочитаю аутировать в виртуальной машине и пинать производителя за то, что эта машина на его процессорах медленно работает
Как успехи в пинании производителя процессоров?
> Кто-то пишет на них не под конкретное железо?
Да.
No. 21409    
>>21407
«Если бы у бабушки был член, была бы она дедушкой.» Имелся в виду аппаратный декодер, не надо тут лить, что «он у нас в целом аппаратный, но некоторые части — софтовые».
>производители выпускают руководства по оптимизации и понаделали кучу счётчиков микроархитектурных событий
Содержание этих специфичных талмудиков в лучшем случае описывается известной фразой: «Ты туда не хады, ты сюда хады, а то снег в башка пападёт — савсэм мёртвий будэшь!» В худшем... Про NetBurst рассказывать надо? «Она работает странно, но мы вам об этом не скажем. Аутируйте ночами в счётчики микроархитектурных событий и пытайтесь понять, что происходит в черном ящике. А мы пока подготовим новую версию ящика, где заменим половину кишок, чтоб вы не расслаблялись.» Мне как-то уже не интересно подобной фигнёй заниматься, к тому же бесплатно.
>Как успехи в пинании производителя процессоров?
Как-то даже задумываться не приходилось, какой там процессор. Вот об алгоритмах думать приходится часто. Забавным здесь видится ещё то, что по итогу тормозит всё всегда почему-то у железячника.
>Да.
laba10.cpp? Потому что что-то сложнее приходится портировать.
No. 21416    
>>21409
> Имелся в виду аппаратный декодер, не надо тут лить, что «он у нас в целом аппаратный, но некоторые части — софтовые».
В современных процессорах обычно есть несколько аппаратных декодеров, которые могут декодировать большинство инструкций (в твоём Нортвуде есть только один аппаратный декодер). В старых x86 (где x < 6) принципиально декодер тоже не был полностью аппаратным, микрокод для декодирования использовался ничуть не меньше. Непонятно, откуда мог взяться твой тезис о существовании аппаратных декодеров ранее и их исчезновении в 2003 году.
> laba10.cpp? Потому что что-то сложнее приходится портировать.
Платформа для отличных от ассемблера языков есть не столько архитектура "железа", сколько интерфейсы используемых библиотек и программ. Проблем с портированием с x86-64 на 32-битный ARM почти нет, если речь идёт не об одновременном переносе под другую ОС.
No. 21417    
>>21404
> Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?
Чем откомпилированный и в какой среде выполняющийся первый вариант кода работает в разы быстрее? Очевидно, что оптимизирующий компилятор, как правило, должен преобразовывать оба варианта в одинаковый машинный код, а в случае компиляции без оптимизации более быстрым может оказаться любой из вариантов в зависимости, например, от того, будет ли во время выполнения X положительным или разместит ли компилятор X в регистре или в памяти.
No. 21485    
>>21474
>На два уровня вверх — это тоже уже неприятно, и по-хорошему, от такого тоже надо избавляться.
Вообще пофигу, если этот код помещается на один экран, лол.
>Я бы, в описанной ситуации, для начала попробовал бы выделить случаи с break в отдельный метод.
Я не понял, чем твое решение фундаментально отлично от моего.
>Эксепшен, хотя бы, ведет точно вверх и, поднявшись по цепочке, всегда можно найти, где он ловится…
Ну низнаю. Если так рассуждать, всегда можно открыть дебаггер и найти значение глобальной переменной, лол. А в силу сложности отлова этого безобразия, имеет смысл использовать много разных переменных (или битфлагов), чтобы понять, где проблема, как только она возникла.
Эксэпш же, не знаю, его хорошо использовать как идею, чтобы например прибраться, если наша программа конкретно сходила под себя, но обрабатывать ими какие-то ошибки будет выглядеть не сильно лучше, чем retvalue handling, а если мы хотим именно сократить нашу императивную лапшу, я не вижу, каким образом глобальные переменные для этого так уж плохи. Проблема в том, что все функции, использующие это, не будут чистыми, лол, но я какбэ за ответственное и внимательное использование этого. Просто если и правда у нас условные 10 уровней обработки ошибок, то даже если мы планируем что-то, у нас будут такие развесистые условия/вызовы функций, что мы офигеем раз десять, пока будем это писать. Или пока будем писать try/catch или что там.
Я думаю, что я в принципе исхожу из того, что программирование исполнителя - это управление состоянием. И корректное описание возможных состояний через пусть и глобальные переменные - не настолько страшно, чтобы оправдать перевод контроля куда-то вообще черт-те куда (so much for managing the state LOL), что определяется рантаймом и не запрограммировано мной как управителем этого исполнителя.
В общем, мне бы хотелось просто примера (можно линкануть реальный код чегото в опенсосе), где глобальные переменные (ну, или в случае с ооп, какие-то приватные члены класса, которые управляются через методы) будут хуже кидания исключений по
а) краткости кода
б) простоте отладки
No. 21489    
>>21404
>>21417

>Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?

Разницу в скомпилированных инструкциях двух вариантов действительно хотелось бы посмотреть. А также то что идёт дальше, поскольку это может повлиять на общую производительность. Но предположу что имелась ввиду компиляция "влоб" без оптимизаций. Тогда первый вариант будет работать быстрее _для ситуаций X<=0_ просто из-за того что операция на запись ячейки памяти отправится в увлекательное путешествие по иерархиям кеша/памяти ДО непосредственной проверки значения, что приведёт к меньшему кол-ву кеш-миссов и меньшим задержкам на ожидание. Всё потому что спекулятивное выполнение не подразумевает изменений внешней памяти(в том числе кешей), иначе неудачный бранч нельзя было бы просто так взять и отменить.
No. 21505    
>>21489
>Разницу в скомпилированных инструкциях
С огромной вероятностью с любым нормальным современным компилятором разницы не будет. Можешь у годболта посмотреть - мне лень, но я очень сильно в этом уверен. Наивный (очень наивный, уровня того, который Креншоу учил писать) компилятор сгенерирует что-то вроде этого:

mov [y], 0
cmp [x], 0
jle .endif
mov [y], 1
.endif:

для первого варианта, и

cmp [x], 0
jg .elseif
mov [y], 0
jmp .endif
.elseif:
mov [y], 1
.endif:

для второго. Первый вариант должен быть немного быстрее. Вот только чтобы это объяснить нужно как раз знать ассемблер. Объяснение это, правда, будет делаться пост-фактум. Тем не менее, это всё не отменяет того факта, что некоторые сишные идиомы не очень хорошо перекладываются в асм, и компилятору оптимизировать их не так просто, как вот этот пример.
Но это всё - подмена предмета спора. Изначальный вопрос был: "что учить для расширения сознания", на что наш преподаватель вылезла с "если нельзя выучить до конца, то учить вообще не стоит". Ну что тут можно сказати...
No. 21526    
>Вот только чтобы это объяснить нужно как раз знать ассемблер.

Скорее микроархитектуру современных процессоров, хоть это и связанные вещи. Без предсказателя ветвлений и многоуровневых кешей, которые сейчас везде, отличий в производительности заметных у тебя не будет.

>Но это всё - подмена предмета спора.

Мимокрокодящий зануда спорит с тем с чем считает интересным кеке

>Наивный компилятор сгенерирует что-то вроде этого

Именно такое я и предполагал. Вооще хотел было проверить по-быстрому какая будет разница, но сгорел от документации к gccшным интринсикам пусть горят в аду её авторы! Подожду пока остыну или не найду другой способ подсунуть нужный ассемблерный код.

>Изначальный вопрос был: "что учить для расширения сознания", на что наш преподаватель вылезла с "если нельзя выучить до конца, то учить вообще не стоит". Ну что тут можно сказати...

С поправкой на женскую логику и общую некомпетентность преподавателей, она скорее всего имела ввиду то что если ты не способен выучить тему настолько чтобы _получать из этих знаний выгоду_ то на изучение можно забить. Спорная для гика точка зрения, но вполне жизнеспособная. Подтверждено сотнями тысяч Вась-формошлёпов и Маш-интерфейсоделок.
No. 21527    
>>21526
Джампы - они-таки не бесплатные, что бы интол там не говорил об их дешёвости. Но заметных отличий, тем более на фоне остального кода, там действительно не будет.
>хотел было проверить по-быстрому какая будет разница
Используй фасм же. У интола где-то был профилировщик, который может все бранч-миспредикшены и конвеер-столлы показывать, да ещё и советы давать о том, как перемешать инструкции, чтобы быстрее было, но я не помню, как он называется. Можешь попробовать его украсть и посмотреть.
>получать из этих знаний выгоду
Но выгода-то будет. Хотя бы просто возможность мыслить на низком, высоком и формошлёпском уровне уже позволит тебе решать некоторые проблемы проще и быстрее.
No. 21531    
155268610477.jpg-(302.53KB, 700×963, 2011-04-26-397529.jpg)
21531
Вы своими попытками отлично иллюстрируете то, что я пыталась донести в >>21376 и >>21377. Ладно, дам подсказку: мы на этапе семантического анализа вольны делать с кодом что угодно, пока это не изменяет видимые эффекты, порождаемые кодом.

>>21526
>Спорная для гика точка зрения, но вполне жизнеспособная.
Гик — это мимоинтересующийся дилетант. Он не производит продукта, он лишь потребляет специально для него произведённый продукт. С чего вы взяли, что мне интересно мнение людей этой группы?

>>21527
>Но выгода-то будет. Хотя бы просто возможность мыслить на низком, высоком и формошлёпском уровне уже позволит тебе решать некоторые проблемы проще и быстрее.
Приведите пример, как знание ассемблера помогает лучше отражать товарооборот http://1c.ru/news/finnews/finnews.jsp?id=439
No. 21532    
>>21531
Так в какой среде выполнения разница в разы?
No. 21534    
155271505191.jpg-(464.21KB, 855×1114, 2012-03-21-485650.jpg)
21534
>>21532
В той, фронтэнд которой добавляет служебный код в базовые и/или условные блоки (бывает, что в виде вызова служебных подпрограмм из библиотеки времени выполнения; особенно GNAT это любит). Обычно это фронты строго-типизированных ЯП и JIT-компиляторы. Побочные временные эффекты зависят от специфики ЯП и крутости человека, писавшего семантический анализатор. Иногда это описано в документации на компилятор в разделе, посвящённом производительности, однако чаще всего просто декларируется непредназначенность данного компилятора для приложений реального времени или для них имеется отдельный профиль.

Теперь положите, что счётчики производительности внедряются в начало каждого базового блока, и посчитайте количество блоков в обоих вариантах. Особенно заметно на древних JIT-компиляторах JavaScript.
No. 21536    
>>21534
А, гонки на асфальтоукладчиках... Какая именно версия GNAT так делает?
> Теперь положите, что счётчики производительности внедряются в начало каждого базового блока, и посчитайте количество блоков в обоих вариантах.
2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
> Особенно заметно на древних JIT-компиляторах JavaScript.
В скомпилированной версии кода счётчиков уже быть не должно, так ведь? А медлительность интерпретируемых участков не должна заметной (кроме как на стадии запуска), ведь критичные для общей производительности участки кода будут скомпилированы.
No. 21538    
>>21536
> 2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
То есть, конечно, 2 и 3, если не забыть о самом операторе сравнения, или "1 с небольшим" и "2 с небольшим", если перед этим кодом длинная линейная последовательность инструкций без переходов и ветвлений.
No. 21545    
155278583977.jpg-(16.83KB, 604×401, 1521587716949.jpg)
21545
>>21531

Что за нездоровый шовинизм? Почему это увлечённый человек(использованное мной значения слова гик) не может ничего создавать и увлечён только мимолётно? По себе судите небось? Прямо стошнило и передёрнуло. Куча разработчиков opensource софта с Линусом во главе смотрят на вас с укоризной
No. 21547    
155285811811.jpg-(547.38KB, 1382×1000, Simoun_Morinas_69150.jpg)
21547
>>21536
Все. Так не делают лишь компиляторы примитивных ЯП вроде Фортрана и C. Чем больше вы сваливаете на компилятор, тем больше неконтролируемого программистом кода он порождает.
>2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
Базовый блок — это максимальная ненулевая последовательность инструкций промежуточного представления без ветвлений. Определяется после разворачивания высокоуровневых конструкций языка в промежуточную форму (из-за чего семантический анализ становится итеративным процессом). Все оптимизации производятся над базовыми блоками. Поскольку есть множество способов трансляции исходного кода в промежуточную форму, мы можем только гадать, во что преобразовался код из примера.
Если допустить, что трансляция происходит прямолинейно, то блоков будет 4 и 5 соответственно; если допустить, что имеет место перегрузка операторов, то не всё так однозначно. Есть здесь опасность начать ванговать, что в одиночном if-е одна ветвь потока управления окажется неразорванной бранчами, но мы не знаем этого точно и даже дизассемблер нам не сильно поможет, поскольку компилятор блоки может транслировать по-разному руководствуясь набором эвристик.
Если это JIT, следующий вопрос, которым надо задаться, — а что вообще принято за единицу компиляции? Это может быть метод, блок, цикл, искусственно выделенная область.
>В скомпилированной версии кода счётчиков уже быть не должно, так ведь?
Зависит от выбранной схемы компиляции. Она вполне себе может быть многоступенчатой, с кучей эвристик, что, когда и как компилировать. Здесь каждый дрочит как он хочет, особенно когда разницы с конкурентами не видно, и не особо распространяется о кровавых подробностях, тем более, что они могут быть коммерческой тайной. С другой стороны, программисты решают высокоуровневые задачи и здесь проблемы производительности относятся к компилятору также, как биохимия мозга слесаря относится к постройке дамбы Гувера.

Резюмируя: если только вы не выполняете гос.заказ под странный военный процессор с ограниченными ресурсами, или занимаетесь высокопроизводительными вычислениями (опять же под конкретную архитектуру/процессор и конкретный компилятор), думать о том, что происходит на уровне промежуточного представления в компиляторе вам не только бессмысленно (поскольку от вас ничего не зависит даже авторы GCC затрудняются сказать, когда и какая подпрограмма будет инлайнится), но и вредно: http://samlib.ru/m/marxjashin_s_n/roboty_bozhy.shtml

>>21545
Потому, что создавать — это 10% удовольствия и 90% унылой рутины. Мне сложно представить случайного человека, который согласится тратить большую часть своего времени на унылую херню, которая вместо фана 45% времени приносит головную боль, а оставшиеся 45% не приносит вообще ничего, кроме искривления позвоночника и близорукости. Ну и я ещё не встречала ни одного гика ушедшего дальше чтения научпопа (поскольку универские курсы или слишком скучные, или слишком сложные). Ну и если начнёте интересоваться личностями программистов, писавших код в Линуксе, то заметите, что основная их масса или имеет профильное образование, или учёную степень по CS.
No. 21549    
Аватарка имеет поинт на тему, что теперь разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему. Также она имеет поинт на тему, что какие-то СЧЕТЧИКИ СОБЫТИЙ не позволят тебе узнать, как работает черный ящик процессор, а позволят узнать, какая операция занимает меньше событий.
Но по-моему, это всего лишь значит, что не стоит учить работу процессоров по современным проприетарным системам. Открытое железо ЕСТЬ - https://en.wikipedia.org/wiki/Open-source_computing_hardware#Fully_open-source_hardware - хотя его немного, и один процессор - это еще не вся машина, на которой можно было бы работать.
Бойкот x86, amd64, ARM, MIPS etc - они не ваши друзья, лол.
No. 21551    
>>21547
> Чем больше вы сваливаете на компилятор, тем больше неконтролируемого программистом кода он порождает.
Но не в таких абсурдно больших пропорциях же. В каждый, даже самый маленький базовый блок добавлять — это чересчур, если только это не интерпретируемый язык с JIT-компиляцией или отладочная сборка (либо сборка для профилирования, оценки покрытия кода тестами и т.п.).
> Если допустить, что трансляция происходит прямолинейно, то блоков будет 4 и 5 соответственно
Почему 4 и 5? Будет по 6-7 инструкций промежуточного представления и 2-3 базовых блока. Ты включаешь в количество базовых блоков тот блок, который перед этим фрагментом, и тот, который следует за ним? Тогда да, 4 и 5.
> если только вы не выполняете гос.заказ под странный военный процессор с ограниченными ресурсами
Ты сводишь всю область встраиваемых систем к каким-то военным госзаказам. В сочетании с упоминанием Ada это наводит на мысль, что ты пишешь на этом языке под "странные военные процессоры".
>>21549
> теперь разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему
Неудачный пример, потому что разница между этими инструкциями есть: "xor eax, eax" действует на флаги и большинством процессоров распознаётся как инструкция, разрывающая зависимость следующих операций от предыдущего значения EAX. "XOR eax, eax" на современных Intel'ах даже не достигает стадии выполнения, а обрабатывается на стадии переименования и выделения регистров. "MOV eax, 0" не действует на флаги, но не распознаётся, как правило, как нечто отличное от любой другой инструкции вида "MOV eax, число".
No. 21552    
>>21549
>Аватарка имеет поинт
Не имеет. Аватарка уводит разговор в сторону от изначальной темы и гнёт законы логики и ведения дискуссии об колено.
>разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему
Присутствует. Потому что интол так сделал и написал об этом в своих мануалах. Но их же читать нинужно, потому что всё равно не выучишь работу процессора до конца.
Ну, если их не читать, то действительно "фиг поймешь почему".
No. 22541    
>>21353
emacs or vi?
No. 22542    
>>22541
PyCharm
No. 22548    
156692672532.jpg-(258.76KB, 880×960, 2017-02-21-889777.jpg)
22548
>Agile или не Agile?
“The End of Agile”: https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/

>>22541
TECO
А если серьёзно, то ни тот, ни другой не покрывают современные юзкейсы, а конфиги ковырять всё-равно в каком.
No. 22561    
>>22548
>то ни тот, ни другой не покрывают современные юзкейсы
И что же они не покрывают?
No. 22565    
>>22561
Готовность к работе из коробки и плавную кривую обучения?
No. 22566    
156724700055.jpg-(242.74KB, 1015×770, 2017-02-21-889779.jpg)
22566
>>22561
Проекты в которых более 50-и файлов, т.е. практически любой современный проект. Поддержки работы с проектом нет, поддержки синтаксиса и семантики формальных языков, используемых в проекте нет. Отсюда вытекает отсутствие средств для рефакторинга. Поддержки документации нет.

Это как Paint и AutoCAD сравнивать, такое себе.
No. 22568    
>>22566
Всё это в плагинах есть. Мы же не говорим об оригинальном vi? Конечно, стоит заметить, что качество и производительность работы этих плагинов на больших проектах порой оставляют желать лучшего.
No. 22570    
>>22568
Если говорить про Vim, то его потолок — это подсветка синтаксиса регулярками, которые спотыкаются об HTML с JS-ом и вызывают кислотного Залго. Остальные его достоинства — это прикольный режим редактирования, который, правда, предполагает, что ты много-много пишешь руками, а не набираешь три буквы и жмакаешь Ctrl-Space и Enter, поскольку контекстно-зависимое автодополнение обычно выбирает нужный вариант.

Можно, конечно, было бы пофиксить сломаное и дописать недостающее, но это кулибинство уровня «из палок, камней и лиан сделать себе инструменты промышленного уровня вместо того, чтобы купить в магазине готовые». Ну и инструменты используют для достижения какой-то цели, а не потому, что они прикольные.
No. 22573    
>>22570
>его потолок — это подсветка синтаксиса регулярками
Нет.
No. 22574    
>>22573
А что в нём ещё есть такого, чего нет в модерновых редакторах? Причём в последних оно сделано для решения современных задач, а не задач, которые решали инженеры 30-ть лет назад при помощи тогдашнего оборудования, когда то, что сейчас делает IDE из коробки, прилагалось к программе на физическом носителе в виде книжечки в твёрдом переплёте. Я только единственный кейс могу припомнить, где он тащит, — это поиск регулярками в 200-метровом бинарнике.
No. 22583    
>>22574
>чего нет в модерновых редакторах
Про это никто не утверждал.
No. 22585    
156743531457.png-(139.38KB, 654×826, 2018-01-04-943532.png)
22585
>>22583
Тогда выходит, что сейчас это просто чудной текстовый редактор, один из многих: Editpad, Alkelpad, Notepad++, SublimeText, e.t.c. Конфиги ковырять подойдёт любой из них, для чего-то более серьёзного они не подходят.
No. 22587    
>>22585
Мир не делится на конфиги и 20гб жаваподелия.
No. 22588    
156747256225.png-(126.94KB, 762×640, 2018-01-04-943531.png)
22588
>>22587
Мир вот уже ~20-ть лет не решает задачки, код которых можно за вечер написать в тетрадке , утром сдать преподу и получить зачёт. Посмотри хотя бы на требования, предъявляемые к industrial grade показометру: ты его ассемблере будешь писать года четыре и по итогу поедешь кукухой от сложности поставленной задачи.

>20гб жаваподелия
Спринг — это вообще такая забавная религия, в основе которой лежит отрицание существования промежутка времени 2011-2019 годов. Они уже «изобрели» фреймворк, позволяющий сделать энтерпрайзный апп-сервер из Jetty своими руками. Теперь они «изобретают» кластер.
Непонятно только, при чем тут они.
No. 22590    
>>22588
Что такое показометр и какие требования к нему предъявляются? То что есть в гугле не делает смысла в контексте беседы.
No. 22592    
156754232617.jpg-(358.91KB, 680×680, 2017-06-12-909572.jpg)
22592
>>22590
Девайс, который некую физическую величину отображает при помощи датчика в виде цифер на семисегментном дисплейчике. Раньше были довольны тем, что он просто показывает эти циферы, сейчас в него надо напихать фарша по уши, чтобы просто быть конкурентноспособным, т.е. то, что ты можешь написать драйвера и измерительную модель — это entry-level, студент с лабой; теперь запили калибратор, предустановленные поправки для разных типов датчиков, возможность добавлять свои поправки, конвертор величин, режимы отображения, цифровые фильтры и трансляцию данных дальше по цепочке таких девайсов, коммуникацию по какому-нибудь протоколу с сервером измерительного комплекса, ивенты в цифре и релейке; плюс нужна самодиагностика и error-handling; плюс настроечки и user-friendly интерфейс, чтобы киповец и технолог могли с ним работать (а ещё желательно, чтобы UI был на их языке, и тут мы выкидываем семисегментный индикатор и драйвера для него, берём экран, способный рисовать графику и пердолимся теперь с ней).

И так везде. Сложность, она не в том, что сейчас используются какие-то хитромудые алгоритмы, понятные 3,5 математикам, а в том, что всего очень много, т.е. не качественная, а количественная. Много функционала, который пользователи считают само собой разумеющимся (не задумывался, кстати, в какую жопу выливается недавний реквест Соуса?), много данных, много типов данных, много систем, много взаимодействий между системами.
No. 22593    
>>22592
> чтобы просто быть конкурентноспособным
При всех его неисчислимых достоинствах подобный умный индикатор безнадёжно проигрывает простому преобразователю с RTD на 4-20, к которому прикручен тот самый семисегментный индикатор, по цене и, вероятно, надёжности.

Однако сколько на один проект по разработке индикатора придётся проектов шкафов управления для десятка исполнительных механизмов и полдюжины таких датчиков, которые собираются из стандартных блоков и элементарной логики, которые имея ТЗ можно буквально на ассемблере за вечер написать?

В мире всё ещё достаточно места для простых программ.
No. 22599    
156771093219.png-(236.96KB, 800×486, 2017-07-09-913558.png)
22599
>>22593
Производству от подобного девайса нужно, чтобы проблемы с девайсом могли решиться за 10-ть минут штатным специалистом. Это замена одной коробочки на другую. Если с твоим девайсом надо пердолиться дольше, производству он не нужен, ибо убытки от простоя будут на порядки больше, чем стоимость железки.
А надёжность — это процент отказов за гарантийный период в партии из 10-100 тыс. изделий при нормальном режиме эксплуатации. Кроме надёжности есть ещё отказоустойчивость, безопасность, ремонтопригодность, простота технического обслуживания и эксплуатации, и ещё куча подобных характеристик, перечисление которых в талмуде занимает около десяти листов.

>безнадёжно проигрывает
Любой девайс, работающий с аналогом обязан иметь механизмы калибровки, иначе тебе нужны йоба-датчики, откалиброванные на заводе, но они во-первых, выходят дороже самого йоба-показометра, а во-вторых, зачастую датчики в промышленных установках являются расходниками и их стремятся сделать как можно проще и дешевле. Это во первых.
Во-вторых, производство сейчас имеет информационную систему учёта и контроля, она просто в силу невозможности запихать цеха в серверную является распределённой. Типично для ЖКХ, когда производственные объекты разбросаны по городу и окрестностям. Твой девайс должен уметь интегрироваться в эту систему.

>проектов шкафов управления
Логика == ПЛК, Siemens, например. Никто не проектирует ПЛК для шкафа управления, берут готовые промышленные решения. Проблемы с ПЛК должны решаться за 10-ть минут заменой коробочки. Модернизация логики должна осуществляться через AutoCAD-подобную программу, с которой будет работать штатный релейщик. ПЛК должен уметь интегрироваться в инфраструктуру распределённого измерительного комплекса.
В случае ЖКХ надо в этот шкаф, помимо ПЛК, воткнуть концентратор и GSM-модуль с автономным питанием, которые будут собирать и лить данные на сервер 24/7, поскольку даже шкаф управления насосом в говнокачке сейчас является частью внутренней информационной системы и ведет с сервером высокоинтеллектуальные беседы.

Недавно «Яндекс» сделал сервис к своим картам, позволяющий отслеживать движение автобусов в реальном времени. Такая система в ЖКХ использовалась ещё десять лет назад в целях мониторинга местоположения боевых юнитов, т.е. нихрена не инновация. Для этого надо в каждый автобус запихать йоба-девайс, который умеет в GPS, Глонасс и GSM, но его обслуживание должно быть доступно простому автоэлектрику. Т.е. эта коробка тоже уже не простая, и «на ассемблере за вечер» ей «мозги» не напишешь.

>которые имея ТЗ можно буквально на ассемблере за вечер написать?
Самоделкин — это враг производства в средне- и долгосрочной перспективе, поскольку:
а) физически не может дать никаких гарантий на свои поделки;
б) не имеет понятия о проектировании (типичное «я художник, я так вижу» и «и так сойдёт»);
в) имеет свойство внезапно сваливать в туман, и тогда никто не знает, что делать с его поделками.
На внедрение самодела заместо готовых решений идут только ушлые управленцы, которые самоделкины потуги представляют начальству как аналоговнет проект по модернизации, начальство радуется, что всё не так сложно и дорого оказалось, и выделяет деньги на реализацию и премию очень толковому управленцу. Отсюда самоделкин является ещё и самому себе врагом.

>В мире всё ещё достаточно места для простых программ.
Единственное их место — это инструменты командной строки, которые человеком используются для ковыряния конфигов и логов в ситуациях, когда всё сломалось. В остальных случаях человек предпочитает их не видеть. Кто, по-твоему, пишет GUI к консольным программам, какие-то специальные люди, бродящие в ночи по ГитХабу и ищущие, к чему бы ещё гуй написать?
No. 22602    
>>22599
Я всё ещё не вижу, чем умный датчик с кучей настроек и протоколов лучше тупого с одним 4-20 в случае неспециализированного массового применения.
Ремонт в любом случае производится заменой коробочки на заранее настроенную другую, сложность настройки с временем простоя не коррелирует. Калибровка, если под ней понимается определение крайних точек шкалы, с тем же успехом делается в ПЛК. Собственно говоря, сомневаюсь, что сильно распределённые системы делают на одних датчиках, без контроллеров. Скорее это ПЛК объекта интегрируется в систему, а датчики через соответствующий интерфейсный модуль к нему подключаются и в высоких материях общения с сервером вовсе не обязаны разуметь.

> йоба-девайс, который умеет в GPS, Глонасс и GSM
Звучит как обычный мобильник. И мне кажется электрик чтобы его обслуживать не нужен, по крайней мере ни разу не видел в кабине автобуса рядом с водителем электриков. Предполагаю, что в случае поломки эту коробочку заменят в лучшем случае по возвращению машины с маршрута, а специально обученного человека, который будет этим заниматься, достаточно одного на автопарк, что снижает требования к простоте обслуживания.

> Проблемы с ПЛК должны решаться за 10-ть минут заменой коробочки.
В идеальном мире - да. На практике в распределённых информационных системах с зоопарком устройств и не слишком жёсткими требованиями к времени простоя нужной коробочки может и не найтись. А уж из-за одного сгоревшего входа при наличии свободных запасных контроллер никто менять не будет, ибо дорого и даже не факт что быстрее, чем логику поменять.

А логику в ПЛК ты за программу не считаешь? Есть же задачи, которые вполне способен осмыслить и реализовать один человек, но недостаточно простые, чтобы делать их на одних релейных схемах. А IDE, эти самые AutoCAD-подобные, в плане написания кода недалеко ушли от наших продвинутых блокнотов.
No. 22607    
156781373719.jpg-(540.09KB, 700×900, 2016-10-21-866607.jpg)
22607
>>22602
>Я всё ещё не вижу
Тем, что для неспециализированного применения он ненужен. Сейчас даже автомат на 400 А имеет микропроцессорное управление и является частью информационной системы.

>сложность настройки с временем простоя не коррелирует
Настройка нетехнологом в кабинете под неидеальные датчики и неидеальный тех.процесс — это рассуждения из идеального мира.

>Калибровка
Уравнение y=kx+b в простом случае, кривые, заданные таблично, в сложном.

>Скорее это ПЛК объекта интегрируется в систему
Радиальная архитектура. Количество узлов в под-дереве одного узла зависит от особенностей конкретного объекта. Можешь физически завести всё в один шкаф — узлом будет или ПЛК или частотник. Не можешь — у тебя появится один ПЛК-мама, и кучка ПЛК/УПП/частотников/показометров-дочек, каждая в своём шкафчике. Как и в системах электроснабжения, эта архитектура имеет рекурсивное определение.

>И мне кажется электрик чтобы его обслуживать не нужен,...
Да, она едет под «жопой» у водилы, есть не просит. В гараже вечером автоэлектрик заменяет коробку, старую забирает инженер АСУТП, которому надо постфактум определить, что с ней не так. Т.е. коробка должна иметь интерфейс для связи с ПЭВМ, графическую программу для тех.обслуживания, систему самодиагностики и подробные логи. Также она должна уметь трекать своё перемещение в офлайне, когда выходит из зоны приёма, самостоятельно дозваниваться до сервера, когда снова войдёт в зону приёма и сливать записанный маршрут. Также она должна уметь в security, поскольку её данные секретны. Сложность подобного изделия выходит за рамки «на ассемблере за ночь».

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

>А уж из-за одного сгоревшего входа при наличии свободных запасных контроллер никто менять не будет
До объекта трястись в служебной машине 5 (пять) часов в одну сторону. Дешевле, проще и быстрее заменить коробочку, а с этой разобраться постфактум. Одна из задач, которую в ЖКХ решают подобные системы, — это самодиагностика необслуживаемых объектов и бибиканье нужным людям «мне плохо, навести», т.е. на объект ты можешь зарулить по дороге. Отсюда: 1) тебе надо возить с собой набор коробочек; 2) зоопарка быть не может — если решили ставить Грюндфос, значит везде будет Грюндфос. Другой вариант — это заранее заложить в программу для ПЛК возможность выбора входов, т.е. нужна отдельная менюха для этого, а сам ПЛК должен иметь графический интерфейс на языке потребителя в терминах решаемой бизнес-проблемы, или тебе надо возить с собой ещё и набор инструкций. Тем не менее в объект может просто ебануть молния.

>ибо дорого
>производство (особенно ЖКХ)
Кек. (Они сейчас с роботами играются.) Дорого — это от миллиона. Эти люди не мыслят самоделкиными категориями, у них другие масштабы и задачи. Они и шкафы управления заказывают у специальных организаций, а не собирают сами. Сами они производят только установку и пуско-наладку совместно со специалистами производителя.

>А логику в ПЛК ты за программу не считаешь?
Эту логику делает фирма, занимающаяся производством контроллеров для нужд производства. Она месяцами тестируется в самой фирме, потом подтверждается тестами сторонних организаций в виде сертификатов соответствия, потом подтверждается эксплуатацией у потребителей данной продукции. Сложность подобного изделия выходит за рамки «на ассемблере за ночь». Никто в здравом уме не полезет хачить ПЛК, если только от безысходности в случае дремучего легаси (от самоделкина).

>Есть же задачи, которые вполне способен...
Улыбнул, содомит. Это какие такие задачи решает специализированная ЭВМ (которая конечный автомат по определению), которые специалист не может описать в виде конечного автомата?

>А IDE, эти самые AutoCAD-подобные, в плане написания кода недалеко ушли от наших продвинутых блокнотов.
1) Они — специализированный продукт под конкретные изделия. 2) Это — рекомендованный производителем способ работы с изделием. Как правило производитель снимает с себя ответственность при работе с его изделием какими-то иными способами.

В общем, мой пойнт в том, что все простые задачи человечество уже решило за последние 20-ть лет и все простые программы уже написаны, опробованы и либо канули в небытие, либо эволюционировали в совренные. Остались или сложные, или очень сложные задачи; эти задачи родом из реального мира, а не из голов академиков, не имеют чётких формулировок, границ и набора компонентов, т.е. их нельзя посидеть и заботать.
No. 22609    
>>22607
> уметь в security
"Security" — это нечто отличное от "безопасность"?
> её данные секретны
Лолчто?
No. 22613    
156788748150.jpg-(58.97KB, 800×576, 66f.jpg)
22613
Фоська дело говорит, в целом согласен, но все очень идеализированно, в реальном мире все намного грустнее, так что вставлю свои 5 копеек.
Так уж вышло, что я знаю какие коробчки ездят под «жопой» у водилы.
У типичного автобуса на борту установлены:
Датчик уровня топлива. Емкостной. Так как двух одинаковых бак не бывает, его нужно тарировать, т.е. ему нужна система калибровки. Датчик общается по rs485 с коробочкой. В бак наливают N литров топлива, нажимают в коробочке на кнопку в меню, та записывает в память датчика соответствие уровня и объема в таблицу. Повторяют до полного бака.
Датчики температуры. От 2 до 8 штук. Обычные DS18B20 никто не калибрует, но так как все они соединены в общий провод 1-wire, необходимо задавать соответствие, какой датчик стоит где. (Иногда их проводку монтируют "звездой", и поэтому от наводок вы регулярно видите в бегущей строке -100 градусов Цельсия)
Датчики пассажиропотока, по одному на дверь. Стоят сверху. Работают как обычная оптопара на отражение. Интерфейс RS485. Штука понятно неточная, так как протиснуться сбоку легко и мимо них.
Датчик дыма и огня, чтобы водила не думал курить в салоне, ну и на случай пожара. В народе "сиська" за характерную полусферическую форму с цилинром на конце. Дискретный выход.
Твревожная кнопка.
Система видеонаблюдения - аналоговые или IP-камеры, от 4 до 12 штук, видеорегистратор с HDD или SSD на 1-2 Тб, wi-fi роутер, который автоматически сгружает содержимое регистратора на сервер при заходе в парк, где видеозаписи хранятся до востребования, и удаляются по прошествии времени, если происшествий не было. В видерегистратор так же можно вставлять SIM-карту, чтобы он сообщал на сервер о состоянии сигнализаций (от акселлерометра или от датчика
Бесперебойник для питания видеонаблюдения. Умный, способен следить за состоянием батареи, считает количество циклов, имеет софтину для настройки. Помимо этого на борту есть несколько преобразователей и стабилизаторов напряжения, но они тупые и аналоговые.
GPS+GLONASS-навигатор с GPRS, типичный представитель - "Гранит-навигатор 2.07", но есть и другие. К нему подключаются датчики пассажиропотока, температуры, уровня топлива, информацию о местоположении и показания датичков он отсылает на сервер. К нему подключается тангента для связи с диспетчером, на него можно дозвониться с обычного мобильника. Так же по тангенте можно матюгаться через динамики в салоне (хотя я ни разу не слышал, чтоб это делали на маршруте, им проще крикнуть). Так же конкретно эта модель поддерживает фотокамеру, и может по запросу отсылать фотку в диспетчерскую, но не видел, чтобы эта фича использовалась.
Табло светодиодные: переднее, заднее, боковое, табло "СТОП", бегущая строка, дополнительные. Если "Гранит-навигатор" поддерживает управление конкретной моделью табло, то используется он, если нет, то автоинформатор от производителья табло. Автоинформатор имеет флешку, на которую записываются файлы маршрутов и аудиофайлы объявления остановок. Так же к нему подключается тангента для объявления ртом.
Валидаторы и турникет (раньше). Валидатор - сложное устройство, которое поддерживает несколько систем платежей, помимо самого билета, должна регулярно связываться с серверами транспортной кампании, и лишь относительно недавно из них выпилили принтер.
Радиостанция "хитон" - представляет собой обычную китайскую голосовую рацию для дальнобойщиков, к которой прикрутили GPS-модуль, чтобы он по радиоканалу отбивал положение в диспетчерскую так же, как это делает навигатор по мобильной связи. Добавление GPS-модуля в китайскую рацию превращает ее в отечественную разработку и добавляет наценку 500% за такое ноу-хау. По сути является резервной системой, все функции которой и так выполняет навигатор, но стоит на случай потери с какого-то перепуга мобильной связи.
В новых автобусах - LCD-экраны с рекламой. Внутри у них андроид.
В новых автобусах все эти коробочки (видеорегистратор, автоинформатор, навигатор) заменены одним бортовым компьютером на Win 10, со специальной софтиной.
Это все вводная часть.
No. 22614    
156789258188.jpg-(42.55KB, 800×283, 184008_800.jpg)
22614
>>22607
> Также она должна уметь в security, поскольку её данные секретны.
Лол. Самое больше секьюрити - это пароль "123456" перед меню критических настроек, чтобы водила не баловался. В остальном - на IP камерах включен telnet, и к ним легко получить рут, например. Но это при условии, что попадешь в их сеть. Принципиально секьюрити основано на том, что IP серверов в оборудовании прописаны в настройках, и больше они ни с чем не связываются, но например GPS-навигаторы имеют интерфейс настройки через SMS, протокол описан в инструкции и находится в свободном доступе. Все, что нужно, чтобы влезть туда - это знать номер телефона.
Это конечно не касается валидаторов, так как там замешаны деньги и банки, по сути, к ним такие же требования, как к любому кассовому терминалу.
> Также она должна уметь трекать своё перемещение в офлайне, когда выходит из зоны приёма
Нет, не должна. Сигнал от GPS пропадет гораздо скорее, чем мобильная связь, ибо он идет из космоса, и его можно загородить любым высотным домом, а мобильная сеть обеспечивается столбами, понатыканными чуть ли не через каждые 100 метров. В целом, всем плевать, если часть маршрута пропала, автобус за это время не мог улететь на луну. В принципе, на этот случай предусмотрена рация "хитон", но как бы у нее-то сигнал еще хуже, так как она должна добивать напрямую до базовой станции.
> Сложность подобного изделия выходит за рамки «на ассемблере за ночь».
Если брать навигатор, то я бы не назвал устройство таким уж сложным. Это если брать не комбайн, вроде "Гранита 2.07", а просто навигатор. GPS-модуль общается по UART с МК, причем на него не нужно слать никаких запросов и записывать ему какие-то регистры, он просто выплевывает в ASCII текущее положение по стандартному протоколу, достаточно просто написать парсер. В GSM-модуле уже есть сетевой стек, и ему достаточно AT-командами сказать "отошли на такой-то айпишник вот эти координаты", добавь к этому пару дискретных входов и DS18B2, текстовый ЖК экран для отображения координат. Это работа на пару вечеров для самодельщика, естественно такого, кто видит все это не в первый раз.
Потом правда приходит жалоба от потребителя, что у вас коробочка глючная, разработчик делает за вечер фикс, отправляет новую прошивку по принципу "собралось - в продакшен" и "пользователь - лучший тестировщик", с новой прошивкой потом обслуживающей организации приходится бегать ночами с программаторами по 1000 автобусов, в каждом раскрутил-прошил-закрутил. Потом выясняется, что в новой прошивке новые баги, и все повторяется сначала.
No. 22615    
> На внедрение самодела заместо готовых решений идут только ушлые управленцы
Дело в том, что любой эффективный и не очень менеджер если есть вариант "нанять 10 инженеров чтобы спроектировать девайс за 1 год" или "нанять 1 самоделкина, чтоб он запилил нам все за неделю" выберут второй вариант, без исключений. Это касается и производителей показометров в том числе, так что не факт, что готовое решение всегда окажется лучше, чем самопал. Были случаи, что на звонок в техподдержку производителя показометров с вопросом отвечали: "извините, проектировщик показометра помер, а мы тут ничерта не понимаем". И иногда лучше и проще иметь при себе исходники и устройство, которое сделано под конкретную задачу и которое можно модифицировать, чем доставать ТП с помагитеунасничегонеработает и получать фигу.
> «я художник, я так вижу»
Я видел провода питания, на которых на одном конце у разъема 1-й контакт красный, другой черный, а на другом точно такой же разъем, но 1-й контакт черный.
> «и так сойдёт»
Как насчет девайса, в котором тысячи точек пайки сделаны вручную, под флюсом ЛТИ-120, намазанным малярной кисточкой по плате и не смытым, где некоторые ножки просто забыли запаять, дроссели намотаны вручную и не виток-к-витку, а как попало, из-за чего те звенят своими ферритовыми чашками как школьный звонок, радиаторы сделаны из алюминиевых уголков, отрезанных ножовкой, а сами платы держатся саморезами на деревянных брусках. Деревянных, Карл!
Все это "готовые решения", выпущенные тиражом в десятки тысяч штук. Так что иногда принцип "хочешь хорошо - сделай это сам" работает.
Собственно, принцип наколеночного производства практикуется везде где можно и где нельзя, даже в критичных сферах, таких как медицина или авиация, даже Боинг нанимает индусов на аутсорсе.
> Эту логику делает фирма, занимающаяся производством контроллеров для нужд производства. Она месяцами тестируется в самой фирме, потом подтверждается тестами сторонних организаций в виде сертификатов соответствия
В этой фирме работают такие же самоделкины, как и везде, а сертификаты выдаются единожды на наименование устройство, из которого можно потом полностью вынуть потроха, и заменить на другие, не меняя при этом существенно TTX, и сертификат продолжит действовать. Что до испытаний, испытания на ЭМС можно провести просто включив прибор в сеть, но не выводя его из спящего режима или не подключая нагрузку, и все хорошо.
Было где-то какое-то расследование, где говорилось о том, как КБ, которому поручили разработку софта для управления шлюзами на реке поручило всю разработку студенту за еду, а профит соответственно оставило себе.
Так или иначе, самоделкины - основа производства, а все сертификаты и испытания иногда не более, чем бумажки.
Ну и о ЖЖ юзера fixik-papus я так понимаю, ты знаешь.
No. 22616    
>>22588
>Мир вот уже ~20-ть лет не решает задачки, код которых можно за вечер написать в тетрадке
Я пишу лямбды на AWS.
И вообще, микросервисы рулят.
No. 22635    
156808519290.jpg-(543.35KB, 800×1132, 2018-02-10-949861.jpg)
22635
>>22613
Я про системы, которые внедряли в ЖКХ примерно десять лет назад говорю. Навигаторы ставились на древние ЗИЛ-ы и трактора, так что они бывало реально ехали под сиденьем водителя, ибо больше места им не было. В эти проекты спецом закладывалась возможность тех.обслуживания неквалифицированным персоналом заказчика у которого зарплата была 16 тыр/месяц, и они в гробу видали дополнительную работу. Работает по сей день, кстати, т.е. подход себя оправдывает.

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

Что я у тебя могу спросить, так это кто должен обслуживать такой йоба-автобус, какая у него должна быть квалификация, и какая зарплата? Потому, что есть множество попильных проектов, которые после торжественного внедрения проработали неделю, что-то сломалось, чинить некому, и их тихонько свернули. Те же электронные очереди в поликлиниках, которые не работают, поскольку необходимая квалификация работника и возможная зарплата не пересекаются.

>>22615
Производство интересует, кого пинать в случае невыполнения обязательств перед заказчиком/клиентами по причине отказа того или иного оборудования. Услуги адвокатов стоят на порядки дороже коробочных решений не говоря уже о том, что незадачливого директора собственник может просто закатать в бетон и нанять более толкового. Как там дела обстоят в дохлых КБ, я не в курсе — не доводилось бывать, извини.

>>22616
>микросервисы
>пишем бойлерплейт для проверок консистентности бизнес-данных
>откатываем распределённые транзакции
Кого будет пинать финансовая организация, например, в случае потери денег из-за того, что клерк получил неконсистентные данные, уже решили? Или, опять таки, для серьёзных применений не подходит?
No. 22637    
>>22635
>для проверок консистентности
>пишем бойлерплейт
? Я, кажется, уже говорил, что не надо писать 20гб Жаваподелия. Жсон-валидатор в зубы и вперёд.
No. 22638    
>>22637
>“undefined is not valid SNILS id”
Лол. Я и говорю, для задач, где в информационной модели более одной сущности, не подходит. Не-не-не, пишите сами учётные системы на микросервисах, делайте руками работу СУБД при помощи чего хотите, только нормальных людей не трогайте.

З.Ы.: Про распределённые транзакции я так понимаю сказать нечего?
No. 22639    
>>22638
>undefined
?
Валидируйте правильно, вам кто запрещает?
>пишите сами учётные системы
Ну я же говорю, мир не делится на конфиги и 40гб 1Сы.
>Про распределённые транзакции я так понимаю сказать нечего?
У меня с ними проблем нет. Ванговать, что у вас за юзкейс, и почему горе-разработчики не могут без 20гб брйлержавакода с ним работать я не собираюсь. Принесите хотя бы ТЗ, тогда с вами можно будет дискутировать.
Удалить сообщение []
Пароль  
[Mod]