Заметки о разработке ПО (типо исторический экскурс)

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

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

«Разбор полетов» показал, что причин несколько. Во-первых, оказалось, что ПО значительно сложнее, чем практически все, с чем приходилось сталкиваться инженерам до того. Сложность проистекает как из-за сложности решаемых задач, так и из-за явных и неявных связей внутри программы. Причем именно связи зачастую представляют наибольшую сложность. Во-вторых, сколько-нибудь сложные проекты, которые делаются большой командой разработчиков, требуют большого количества коммуникаций внутри команды. Добавление людей в команду далеко не всегда ускоряет процесс разработки, а на поздних этапах проекта даже замедляет ее (знаменитая книжка «Мифический человеко-месяц» Брукса подробно разбирает этот вопрос). В-третих, производительность каждого члена команды значительно ниже в группе нежели индивидуально из-за необходимости тратить время на коммуникации с другими членами команды. В-четвертых, оказалось, что классический подход к решению инженерных задач не дает гарантированного результата. Вот как выглядит классический подход:

Видимо из-за схожести этой диаграммы с водопадом этот метод получил название waterfall (то есть водопад).
Практика показала, что после каждого из этих этапов зачастую возникает необходимость вернуться на предыдущий этап, а в процессе возврата вернуться еще на один этап выше и так далее, так что в реальной жизни процесс выглядел так:
.
(сорри, картинки тырил где попало, поэтому они слегка отличаются терминологией)
За этим кроется еще две проблемы: время реализации становится непредсказуемым, а цена (во всех смыслах) такого возврата многократно возрастает по мере приближения проекта к завершению.

Решение описанных выше проблем шло в разных направлениях. В первую очередь, видимо, следует упомянуть так называемое структурное программирование. Его главной целью было четкое структурирование программы, разделение кода на множество функций и устранение неявных связей по вызовам одних частей кода из других (так называемое «программирование без goto»). Такой подход позволял значительно уменьшить количество связей внутри программы. Структурное программирование, однако, не затрагивает связи по данным, в том числе неявные (через глобальные переменные). Дальнейшим развитием структурного программирования (а вовсе не заменой, как многие, почему-то, думают) стало появление объектно-ориентированного программирования. Оно позволило убрать неявные связи по данным и ограничить количество явных путем локализации в одном месте самих данных и методов работы с ними. Замечу, что ООП был настолько логичным и очевидным развитием структурного программирования, что они практически ровесники — структурное программирование появилось и оформилось в 60-х, в частности знаменитое письмо Дейкстры было опубликовано в 1968 году. Тогда же появилась и Simula 67, в которой были и классы, и виртуальные методы и наследование. Однако «появилось и оформилось» вовсе не значит, «быстро вошло в повседневную практику». Споры вокруг структурного программирования продолжались до конца 80-х, а ООП стало набирать популярность только к началу 90-х.

Структурное программирование и ООП позволяли решить многие проблемы, но далеко не все. В частности они никак не затрагивали организацию процесса разработки. Жесткое разделение на фазы подхлеснуло развитие методов проектирования ПО. Видимо первым шагом в этом направлении стало выделение из фазы проектирования отдельной фазы детального проектирования. Но даже детальное проектирование не позволило избежать возвратов. Расписанный до последнего класса и функции дизайн в процессе реализации все равно приходилось менять, а «цена возврата» стала даже выше, поскольку этап дизайна многократно усложнился, а процесс дизайна оброс многочисленными бумажками. В какой-то момент стало понятно, что причина не в качестве и детальности дизайна, а в самом процессе организации разработки.

Пожалуй, с самого начала появления программирования как области инженерной деятельности было известно, что эффективность работы отдельно взятого программиста достаточно высока. Бесчисленное множество известных программ создавались программистами-одиночками. Однако программист-одиночка не мог создавать большие программы. У каждого программиста есть предел сложности программы которую он может создать. К тому же такие программы (и, таким образом, ее пользователи) становились зависимы от конкретного человека, что допустимо далеко не всегда. Одной из первых попыток (и весьма удачной к тому же) решить обе эти проблемы было появление (аж в 1971-м году) метода разработки, который называется «бригада главного программиста». Идея достаточно простая — есть главный программист, второй программист, который берет на себя задачи главного в случае необходимости и полностью в курсе всех деталей проекта. Есть еще человек занимающийся документированием процесса и библиотекарь. В случае, когда проект слишком велик для одного человека, он делится на части и создается несколько бригад, главные программисты которых общаются для решения вопросов дизайна всей программы, распределяют части между бригадами, устаканивают интерфейсы и так далее. У этого метода есть несколько весьма существенных особенностей. В первую очередь очень короткая фаза дизайна. Естественно, отсутствует и фаза детального дизайна. Проектирование и разработка часть единого процесса, а «цена возврата» относительно низка. Есть и недостатки (для больших проектов). Части разрабатываются относительно изолировано, а в процессе их интеграции традиционно вылазит большое количество граблей.

Тут, пожалуй, имеет смысл вернуться к самому началу и посмотреть на разработку несколько с другой стороны. Одним из источников проблем для традиционого метода разработки являются изменяющиеся требования. Как бы не хотелось зафиксировать требования, изменения в них происходят постоянно. Источников и причин изменений великое множество, пытаться устранить их не получается. Этот факт подводит к, вобщем, простой мысли, что процесс создания программы должен быть приспособлен к изменению требований. Иначе говоря он должен быть адаптивным. Водопад же относится к совершенно другому типу, так называемым предиктивным процессам. Если провести аналогию с военным исскуством, то водопад это классическая артилерия, а процесс разработки — выстрел. Удалось предугадать требования — попали. Не удалось — промазали. Адаптивный процесс больше похож на выстрел самонаводящейся или управляемой ракетой. Стреляем примерно в нужном направлении и по ходу дела донаводим на цель. Даже если цель пытается скрыться, ракета корректирует направление и все равно поражает цель.
Да, эта мысль тоже не нова. Первой публикацией на тему адаптивности методов разработки принято считать статью «A Process for the Development of Software for Nontechnical Users as an Adaptive System» опубликованную в 1974-м году.
Одним из способов обойти эту проблему в предиктивных процессах является закладывание в дизайн избыточной гибкости и/или функциональности. Это приводит к тому, что значительная часть кода — мертвый груз, который никогда никем не используется. Другое последствие — оверинжиниринг, программа зачастую имеет архитектуру значительно более сложную, чем требуется для решения поставленных перед ней задач. А это, в свою очередь, усложняет ее написание, тестирование и сопровождение.

Как не сложно заметить из всего написанного выше, отдельные проблемы с разной степенью успешности так или иначе решались, причем давно. В какой-то момент кто-то должен был догадаться слить это вместе. И это произошло, точнее, началось в середине 90-х, когда начали появляться методы, которые позже получили общее название Agile Methods. Самих методов много, их отличают множество деталей, но есть несколько общих ключевых моментов описанных ниже. Реальные процессы разработки, которые складываются в командах редко (на моем опыте — никогда) соответствуют в точности конкретной методологии, но ключевые моменты остаются неизменными:

— Итеративная разработка. Процесс разработки разбивается на итерации равной длины (обычно 2-3 недели, редко 4). Каждая итерация включает в себя одновременно проектирование, написание кода, интеграцию и тестирование. Жесткого деления на фазы нет.
— Любые изменения возможны на любом этапе. Если понадобится полностью изменить архитектуру, это будет сделано, причем «цена изменений» в случае agile достаточно низка даже для таких глобальных переделок.
— Команда небольшого размера. Обычно 3-8 разработчиков.
— В команде нет деления по функциям (то есть нет отдельно разработчиков, тестеров, и так далее).
— В команде нет менеджеров. Есть тимлид, но он осуществляет техническое руководство и пишет наравне с остальными.
— Начиная с какой-то итерации (обычно после третей-четвертой, иногда раньше) есть продукт, который можно пощупать самому или показать заказчику. Он содержит только часть запланированной функциональности, но то, что уже реализовано полностью протестировано.
— Непрерывная интеграция (об этом чуть ниже).
— Вертикальное деление проекта на части для реализации (об этом чуть ниже)
— Постоянный рефакторинг. Он делается а) в процессе написания как предварительный этап перед добавлением новой функциональности, б) периодически уже написанный и протестированный код просматривается и при необходимости рефакторится.
— Минимальный объем документации (об этом тоже чуть ниже)
— Практически непрерывная коммуникация с заказчиком
— Общее владение кодом. Каждый разработчик может сделать любые необходимые изменения в любой части кода. «Владельцев» определенных частей нет.
— Минимальный код для получения требуемой функциональности. (об этом чуть ниже)

В технической стороне организации процессов видимо стоит отметить такие моменты:
— Обязательное наличие системы управления версиями кода
— Обязательное наличие CI сервера (то есть сервера непрерывной интеграции, где код проекта собирается и прогоняются автоматические тесты).

Чуть подробнее о некоторых пунктах из написанного выше:

Непрерывная интеграция. Этот пункт означает, что интеграция всех написанных разными разработчиками компонентов выполняется постоянно, с первого дня начала проекта. Возникающие проблемы немедленно решаются. Если очередной коммит сломал ранее работавшие тесты, то разработчик, который его делал, обязан исправить ошибки.

Вертикальное проектирование. Традиционно программа пишется «по слоям» (снизу вверх или сверху вниз — не существенно). Иначе говоря, делится горизонтально. Что зачастую приводит к ситуациям типа «мы фичу реализовали, но она не работает, а заработает когда допишем еще вот тот кусок» или «у нас есть все, что нужно, но сама фича не реализована». В случае вертикального проектирования каждая фича реализуется полностью. Если в процессе оказывается, что какие-то части надо доделать или переделать, то они доделываются или переделываются.

Минимальный объем документации означает, что проектная документация ведется ровно в том объеме, который нужен разработчикам на данном этапе. Это избавляет от необходимости переписывать документацию по мере изменения дизайна. Это так же признание того факта, что дизайном программы являются не бумажки, а ее исходный код (в том числе код тестов!). Бумажки могут устаревать, код — никогда. Код и только код является абсолютно точным описанием дизайна программы. Как следствие, код и тесты к нему пишутся максимально понятными и читабельными. Я не зря упомянул тесты. Помимо собственно тестирования они (ценой незначительных усилий со стороны разработчика) описывают ожидаемое поведение тестируемого кода. Зачастую для того, что бы разобраться с кодом, который писал другой разработчик, удобнее смотреть не в сам код, а в код тестов к нему.

Минимальный код для получения требуемой функциональности. Как я уже упоминал выше, традиционно в программу закладывают избыточную гибкость. В agile методах вместо этого пишется минимально работающий код. Если в процессе реализации другой функциональности, понадобится его изменить для реализации чего-то еще — это будет сделано. В итоге в конечный продукт войдет ровно то, что нужно, ничего лишнего.

Стоит заметить, что чего-то сильно нового в этих методах нет. В той или иной форме многие решения существовали задолго до появления agile. Организация команды сильно напоминает «бригаду главного программиста», только самих программистов больше одного, а вспомогательные функции в значительной мере перенесены на инструменты. Эволюционное проектирование и итеративная разработка тоже не новые подходы. Рефакторингом любой программист и так регулярно занимается, разве что раньше это считалось «непроизводительными затратами времени», а в agile методах признали, что это единственно возможный способ избежать переписывания больших кусков программы или всей программы с нуля.

Вобщем, где-то так. Что-то мог пропустить или забыть упомянуть, конечно. Но это, все-таки, заметки, а не учебник.

UPDATE: Для ембеддеров (впрочем, не только для них) будет полезно почитать «Test Driven Development for Embedded C». Кто не в курсе, Test Driven Development (TDD) одна из «екстремальных» практик в agile при которой тесты пишутся до того, как пишется рабочий код.
  • +11
  • 23 февраля 2013, 15:30
  • evsi

Комментарии (462)

RSS свернуть / развернуть
Два листа A4 это много букв.
А по статье сразу видно, что написано профессиональным тим лидером… Советую всем остальным перенимать опыт)))

Минус мой.
0
  • avatar
  • a9d
  • 23 февраля 2013, 16:02
Я не тимлид.
0
В-третих, оказалось, что классический подход
«В третьих» уже было.
знаменитое письмо Дейкстры было опубликовано в 1968 году
Дай линк на него отдельно, я то я уже забыл, о чем оно.
Вертикальное проектирование
Интересная идея. Стоит взять на вооружение.

Стоит признать, что как программист-одиночка я во многом следую модели ближе к водопаду. А вот в команде я работал ближе к agile, и, надо сказать, мне понравилось. Многие сложности оказались надуманными.
0
  • avatar
  • Vga
  • 23 февраля 2013, 16:03
Дай линк на него отдельно, я то я уже забыл, о чем оно.
Добавил.
0
А, это. Я было подумал, что на тему ООП письмо.
0
Полезно. Спасибо.
0
  • avatar
  • dekar
  • 23 февраля 2013, 19:48
Только вот почему именно ИНЖЕНЕРНЫЙ подход появился именно при кодинге (где и процветал говнокодинг, монолитные поделия сваяные в одиночку, велосипеды и вообще: кто в лес — кто по дрова), а не наоборот: т.е. КОДЕРЫ и их руководители(понабив шишек) взяли со временем то, что уже применялось ДАВНО в КБ и в ПРОМЫШЛЕННОСТИ, в частности в машиностроении/приборостроении и т.д.

Есть такие понятия основные у инженеров: ЦИКЛ проектирования, ЦИКЛ жизни изделия. Какое слово прозвучало? ЦИКЛ. Т.е. это НЕ ЗЛО некое, а просто РЕАЛЬНОСТЬ, как бы к ней не относились. А оборотов в этих циклах вполне может быть больше одного, точнее обычно по многу раз прокручиваются более мелкие циклы (которых множество), отвечающие за проектирование/переделку отдельного блока/детали в главном изделии, т.е. внутри основного цикла.

Пример: проектируют самолет — это основной цикл проектирования. Он, как часы состоит из большого множества взаимосвязанных или несвязанных друг с другом шестеренок — это внутренние циклы проектирования отдельного блока, узла в блоке, детали в узле и т.д. За которые отвечают отдельные КБ, проект.институты, отделы и отдельные люди. Допустим все готово, но тут оказывается, что такой-то детальки в таком-то узле такого-то блока по каким-то причинам не будет. Все — надо заменить на аналог и т.п. По проекту проходит как бы волна, излучаемая из места этой детальки, какие-то уже готовые узлы и блоки она не затрагивает, но некоторые (родные/соседние/зависимые) блоки/узлы надо переделать (чуть-чуть или полностью). В чем проблема? Циклы проектирования мелкие(блоков и узлов) прокручиваются(возможно многократно), после исправления/доделки/пределки все устаканивается. Изделие готово.

Многие изделия в промышленности живут 10, 20, 30 и даже 60 лет, например B-52 или Ту-95. При этом в своем цикле жизни многие их блоки и узлы перепроектируются и бывает по многу раз.

P.S. Для ускорения всех этих внутренних циклов в процессе проектирования в промышленности стали давно уже использовать системы СКВОЗНОГО ПРОЕКТИРОВАНИЯ на базе CAD и общей БД проекта. Т.е. суть не поменялась, но резко уменьшилось время прохождения волны проектирования/перепроектирования по проекту.
+1
КОДЕРЫ и их руководители(понабив шишек) взяли со временем то, что уже применялось ДАВНО в КБ и в ПРОМЫШЛЕННОСТИ

Дык почему не взяли, именно что взяли изначально существующий на то время подход. Взяли применяемый подход в производстве (промышленности) и отразили это на производство ПО.

То что Вы описываете (цикл проектирования, цикл производства, цикл испытаний) это и есть тот самый «водопад», который описан в начале. Именно эту схему и применяли изначально и применяли. И, к слову, до сих пор иногда применяют при разработке специфического ПО.

Просто, как правильно заметил автор – это схема управления проектом была не самой эффективной, она не обладала гибкостью. А agile методологии (например scrum) как раз, помимо всего прочего обладают большой гибкостью. Требования к ПО могут меняться в любой момент, и agile методологии с этим успешно справляются.
+2
Водопад — это некий кодерский термин, и подразумевает, что все движется сверху вниз ОДНОНАПРАВЛЕННО, а скачки назад по ступеням водопада или циклы — это ЗЛО. Я же вещаю о том, что в ЦИКЛЕ проектирования в пром-ти — это НЕ ЗЛО, это просто ОБЪЕКТИВНАЯ РЕАЛЬНОСТЬ, дополнительные обороты в мелких циклах могут быть, а могут и не быть, тем более многие из них крутятся совсем не зависимо от одних, но зависимо от других. Как еще сказать? — ну вот почему, например, существуют аксиомы и теоремы и особая процедура доказательств в математике — так надо, это — сложившаяся ОБЪЕКТИВНАЯ РЕАЛЬНОСТЬ этой отрасли.
0
Водопад — это некий кодерский термин

«Водопад» — это одно из названий, другое название «разработка сверху вниз».

Я же вещаю о том, что в ЦИКЛЕ проектирования в пром-ти — это НЕ ЗЛО, это просто ОБЪЕКТИВНАЯ РЕАЛЬНОСТЬ

Весь вопрос в стоимости такого цикла. В случае «водопада» возвращение из состояния «тестирование» в состояние «проектирование» — это очень дорого.

ну вот почему, например, существуют аксиомы и теоремы и особая процедура доказательств в математике — так надо, это — сложившаяся ОБЪЕКТИВНАЯ РЕАЛЬНОСТЬ этой отрасли.

Ключевые слова «этой отрасли». Разработка ПО имеет свои особенности, по сравнению с другими «классическими» отраслями производства.

Например, разработка ПО гибче сама по себе. Изменить стреловидность крыла сошедшего с конвейера самолета невозможно, нужно заново проектировать и изготовлять новый самолет с другой стреловидностью крыла. А вот внести изменение в ПО (пусть даже очень существенное) намного проще.
0
А agile методологии (например scrum) как раз, помимо всего прочего обладают большой гибкостью. Требования к ПО могут меняться в любой момент, и agile методологии с этим успешно справляются.
Совершенно верно. Скажем, у меня на одном из предыдущих проектов в процессе реализации изменившихся требований трижды кардинально менялась внутренняя архитектура разрабатываемой системы. Это прошло практически незаметно для заказчика и не потребовало больших усилий от команды.
0
Допустим все готово, но тут оказывается, что такой-то детальки в таком-то узле такого-то блока по каким-то причинам не будет. Все — надо заменить на аналог и т.п. По проекту проходит как бы волна, излучаемая из места этой детальки
Это не переделка, это интеграция.

А переделка — это когда начинали делать кукурузник, а вышел в итоге «Тенгу» из Red Alert 3.
+2
А переделка — это когда начинали делать кукурузник, а вышел в итоге «Тенгу» из Red Alert 3.

Это неправильное злонамеренное утрирование :)

Точнее сказать: сделали ЛАГГ-3, потом быстро заменили рядный движок вод.охлаждения на радиальный воздушн.охлаждения и получили ЛА-5(Ля-Фюфс). Затем еще кое что переделали и форсировали мотор — получили ЛА-5ФН(Ля-Фюфс Эф-Эн)
0
Нет, это не утрирование. Это суровая реальность разработки софта, даже смягченная. Обычно выходит не тенгу, а сразу оптимус прайм.
Точнее сказать: сделали ЛАГГ-3, потом быстро заменили рядный движок вод.охлаждения на радиальный воздушн.охлаждения и получили ЛА-5(Ля-Фюфс). Затем еще кое что переделали и форсировали мотор — получили ЛА-5ФН(Ля-Фюфс Эф-Эн)
Это различия между минорными релизами. Скажем, 1.2.3 и 1.2.4.
+1
Это неправильное злонамеренное утрирование :)
Как верно заметил камрад Vga, это таки суровая реальность.

Проблема с софтом заключается в том, что в подавляющем большинстве случаев заказчик плохо представляет себе что же на самом деле получится на выходе. Ценность agile методов как раз в том, что нечто, что заказчик может увидеть и пощупать получается очень быстро. Зачастую после того, как заказчик впервые увидел продукт, требования кардинально перепахиваются, поскольку у заказчика начинаются проблески понимания того, что же он на самом деле хочет и как это может выглядеть. С каждой итерацией поток изменений в требованиях уменьшается, а продукт приближается к тому что хочет заказчик.

В промышленности, когда начинается разработка того же самолета, то все, и разработчики и заказчики понимают что получится на выходе. Не бывает ситуаций, в которых заказчик приходит в Боинг заказывать самолет, а ему, на самом деле, надо было идти в Дженерал Дайнемикс что бы заказать субмарину. В программировании это сплошь и рядом.
0
Проблема с софтом заключается в том, что в подавляющем большинстве случаев заказчик плохо представляет себе что же на самом деле получится на выходе. Ценность agile методов как раз в том, что нечто, что заказчик может увидеть и пощупать получается очень быстро.

Это получается, что это все как рысканье в мутной воде — сделай то, не знаю что.

Может все же как-то выделить это все отдельно и как положено в НИОКР/ОКР и ПРЕДПРОЕКТНОЕ РЕШЕНИЕ. Изучить применимость той или другой технологии/платформы/языка и т.п., прикинуть, проанализировать, произвести сбор информации, провести консультации.

Потом на основе этого уже сделать ТЗ, нарисовать структуру/архитектуру, разбить на блоки, описать интерфейсы и т.д. После этого распределить задачи и закодировать.

Зачем сразу же бросатся кодировать, если ничего этого нет?

Может быть просто понять, что предпроектное решение и ОКР, а затем конструирование и проектирование структуры и архитектуры — это не ерунда, не мелочи какие, не лишняя работа — это просто половина или треть или три/четверти всей необходимой работы? Зачем сразу бросатся кодировать?
0
Может все же как-то выделить это все отдельно и как положено в НИОКР/ОКР и ПРЕДПРОЕКТНОЕ РЕШЕНИЕ. Изучить применимость той или другой технологии/платформы/языка и т.п., прикинуть, проанализировать, произвести сбор информации, провести консультации.
это вполне себе ощутимый кусок работы. который должен быть оплачен. логично? вот только не все заказчики это понимают.
0
это вполне себе ощутимый кусок работы. который должен быть оплачен. логично? вот только не все заказчики это понимают.

Если мы так материально приземлились, зачем тогда теоретезировать нам здесь? B) Есть масса способов замутить и впарить что-то… и вопросы программинга здесь уже на 3-м плане.
0
цена вопроса всегда есть. в том или ином виде.
0
И второе: есть масса проектов, которые делают не по заказу неких заказчиков-идиотов. Есть огромная масса СОБСТВЕННЫХ проектов, когда люди сами решают и знают что надо и как. И что? Они тоже таким методом рысканья на пустом месте ваяют — сразу бросаются кодировать?
0
Ваши слова выдают не понимание одной простой вещи (хотя я в тексте специально акцентировал на этом внимание) — «кодирование» это и есть проектирование.
0
кодирование это и есть проектирование

Об этом уже спорили с Вами. Ну вот не понимаю я этого, совсем не понимаю… может какая хитрость и что-то парадоксальное скрывается за этим?
0
Об этом уже спорили с Вами. Ну вот не понимаю я этого, совсем не понимаю… может какая хитрость и что-то парадоксальное скрывается за этим?
Что такое дизайн, в конечном итоге? Это проектная документация, взяв которую можно изготовить продукт от начала и до конца. Так? Ровно тоже самое и с софтом. Исходный код + конфигурация инструментов для сборки это и есть проектная документация софта. Готовый продукт — бинарники, а вовсе не исходный код.
0
Исходный код + конфигурация инструментов для сборки это и есть проектная документация софта. Готовый продукт — бинарники, а вовсе не исходный код.

Ну не знаю что даже сказать. Мне это до сих пор не понятно. Точнее не понятны ПЛЮСЫ всего этого, кроме сомнительных конечно, типа не писать документацию ни до, ни после. Ладно, на конечную можно плюнуть — работает, исходники есть — да и хрен с ней, с документацией. Но как начинать работать, как нанимать людей, как выдавать им задания и объяснить что вообще-то надо делать?
0
Но как начинать работать, как нанимать людей, как выдавать им задания и объяснить что вообще-то надо делать?
Команда самодостаточна, ей никто не выдает задания, а что надо делать команда решает самостоятельно общаясь с заказчиком и собирая требования в виде так называемых пользовательских историй.
0
Ну не знаю что даже сказать. Мне это до сих пор не понятно. Точнее не понятны ПЛЮСЫ всего этого, кроме сомнительных конечно, типа не писать документацию ни до, ни после.
Плюсов много, на самом деле. Документация имеет свойство быстро устаревать. Ее поддержание в актуальном виде требует затрат сил и времени. А так на момент существенных изменений в архитектуре устраивается дизайн-сессия с участием всех разработчиков. Результаты заносятся в вики или трекер. Туда же кладутся фотки с доски. Это и есть рабочая документация по дизайну верхнего уровня. По мере развития проекта что-то выбрасывается совсем как не актуальное, что-то заменяется. Формальной документации в общепринятом смысле вести необходимости нет.
+1
Точнее не понятны ПЛЮСЫ всего этого, кроме сомнительных конечно, типа не писать документацию ни до, ни после.
Дело здесь не в плюсах и минусах, а в том, что код по самой своей сути является документацией. Фаза производства же полностью автоматизирована и выполняется командой make.
Код можно сопровождать дополнительной документацией, но отнюдь не так уж много документации которая действительно нужна, и ключевой документацией всегда будет код.
0
Они тоже таким методом рысканья на пустом месте ваяют — сразу бросаются кодировать?
В точку!
+1
Алсо, вот. Только в табличке определенно не хватает пункта про документацию.
0
Потому, что это не работает.
0
Изучить применимость той или другой технологии/платформы/языка и т.п., прикинуть, проанализировать, произвести сбор информации, провести консультации.

Это все хорошо, только это теория. Вот Вы изучили, прикинули, проанализировали и т. д. После этого, основываясь на этих знаниях, Вы разработали некоторое «проектное решение». Пусть, в данном случае, это будет полная принципиальная схема большого и сложно устройства. Вы затратили кучу времени, на изучение, анализ и т. д. А, вот, Вы можете гарантировать, что собранное по этой схеме устройство будет работать (Вы уверенны, что при проектировании не было допущено ошибок)? Вы уверенны, что собрав законченное устройство и показав его заказчику – тот останется доволен?

Одна из идей agile методологии (я в данном случае все очень упрощаю) — сблизить теорию (проектирование) с практикой (разработка, тестирование, введение в эксплуатацию). Вместо того, чтобы заниматься проектированием огромного устройства «на бумаге» от начале и до конца (затратив на это огромные ресурсы), мы берем, проектируем небольшую часть функциональности, тут же реализуем ее и показываем результат заказчику. Да, это не полнофункциональное устройство, это только небольшая часть, но и риски меньше – если что-то пошло не так (ошибка в архитектуре, реализации, изменились требования заказчика) то отреагировать мы можем актуально и относительно безболезненно.

Это все очень-очень упрощенно, лучше не делайте поспешных выводов относительно эффективности agile и дождитесь продолжения цикла статей от коллеги evsi .
0
Может быть просто понять, что предпроектное решение и ОКР, а затем конструирование и проектирование структуры и архитектуры — это не ерунда, не мелочи какие, не лишняя работа — это просто половина или треть или три/четверти всей необходимой работы? Зачем сразу бросатся кодировать?
Индустрия ПО давно перешагнула полувековой рубеж. Как вы думаете, за это время никто не додумался применить такой подход?
0
Я работал в конторе, которая в 81 году всё это применила на практике (agile). Коллектив был молодой, гибкий. Этот метод позволил нам убедить старпёров в Москве и Киеве в необходимости финансирования работ, а затем и убедить руководителей главка во внедрении разработки. Наш руководитель просто продемонстрировал работу САПР в виде интерфейса пользователя. Структура управления проектом такова, что были выделены главный архитектор проекта (по программированию, думаю Билл Гейтс у нас идею стырил) и ведущие по темам программирования. А так как это был САПР механообработки, то был и ведущий инженер (де-факто это был я, но как всегда де-юре нашёлся другой, с боОльшей должностью, который спал дни напролёт:) Тогда же я занялся практическим программированием. Потом, в конце, всё решилось в мою пользу, но обидно всё же было…
Что ещё мы применяли: кодировать начинали с подробного описания алгоритма блока, прямо в виде комментариев, эти комментарии потом шло практически дословно в отчёты (как там этот генератор очёто называется, не припомню с ходу).
И точно, была избыточность, но эти куски интерфейса пользователя были и основой проектирования САПР в целом, и отчётами руководству о возможностях САПРа. Только тогда мы (а я и сейчас) этих слов и не знали :-)
Это всё интересно, но это работа в конторе. А как Вы начинаете и поддерживаете личные проекты?
-1
Это всё интересно, но это работа в конторе. А как Вы начинаете и поддерживаете личные проекты?
Примерно по той же схеме — юниттесты, сервер CI, сонар, трекер. Правда, на личные проекты сейчас нет времени :(
0
Что такое «сонар»?
0
Это автоматическая проверялка сорсов на соответствие определенным правилам. Она умеет ловить некоторые типичные ошибки и следит за соблюдением так называемых best practices.
0
Статический анализатор кода чтоль?
0
Типа того. Но это только часть. Он Считает покрытие кода, ведет историю изменений, следит за зависимостями между модулями и многие другие мелочи.
0
хм. прикольная штука. только не взлетела.
в винде не взлетела. знаю-знаю, что ССЗБ и проблемы индейцев. ;) бум разбираться, чего ей не хватает…
0
Да, хочу уточнить: в agile есть проектирование структуры и архитектруры на высоком уровне. Так же как НИОКР в виде так называемых спайков. Но это не месяцы и годы, а максимум дни (для спайков максимум — итерация).
0
Зачем сразу бросатся кодировать?
М.б. потому что большинство программ пишется на базе чего-то уже существующего и участники процесса просто не понимают объёма грабель, связанного с «небольшими изменениями»? :)
0
Полагаю вы очень плохого мнения об участниках процесса :) Примерно так же как well-man2000 полагает, что программисты глупее других инженеров и не додумались «сначала все спроектировать, а потом все закодировать».
0
Это да, в программироании я нуб :) У меня в системной интеграции процесс похож не на водопад, а на такую… ёлочку. Из одной точки сверху до огромной подошвы в финале… И соответственно, цена ошибки выше на поздних стадиях. Маленькое изменение в более ранних документах может вызвать вал правок в последующих, и хрен отследишь. Т.к. нормальной САПР (с базой данных и вайринг листами) у нас нет. Точнее есть несколько, но они настолько корявые, что уж лучше руками :)
+1
Есть такие понятия основные у инженеров: ЦИКЛ проектирования, ЦИКЛ жизни изделия. Какое слово прозвучало? ЦИКЛ. Т.е. это НЕ ЗЛО некое, а просто РЕАЛЬНОСТЬ, как бы к ней не относились.
Ровно так же разрабатывается софт в agile. По сути «релиз» это тот код, который есть после завершения очередной итерации.
0
Спасибо, интересно.
Где бы ещё почитать про автоматическое тестирование? Как и чем реализуется, что можно таким образом протестировать (алгоритм, типа сортировки — понятно, а к примеру пользовательский интерфейс?).
0
  • avatar
  • ACE
  • 23 февраля 2013, 20:48
Насчёт тестирования пользовательского интерфейса всё довольно сложно. Но есть методики. Например паттерны типа MVC или MVVM, помогают с тестированием логики UI, посколку она отделена от собственно представления. А если нужно тестировать именно нажатия на кнопи и т.д., то есть всякие инструметны и для этого.
У меня на одном проекте есть Continuous Integration Server, он раз в сутки забирает из системы контроля версий исходники, если они изменились, компилирует их, выполняет все модульные тесты. После создает виртуальную машину, в автоматическом режима устанавливает на на нее серверную часть продукта. Запускает еще одну виртуалку-клиент и тестирует на ней UI. После на CI сервере составляется отчет. Таким образом у нас всегда имеется свежая протестированная версия продукта, доступная заказчику 24/7.
+2
Насчет почитать, я, пожалуй, посоветую почитать Фаулера «Рефакторинг».

Большинство инструментов для тестирования специфичны для конкретного языка. В жабе это JUnit/TestNG/EasyMock/Mockito/Unitils/куча других фреймворков. Аналогичные наборы есть во многих других языках, включая С/С++. Да, с некоторыми усилиями автоматически протестировать можно практически все.
+2
Где бы ещё почитать про автоматическое тестирование? Как и чем реализуется, что можно таким образом протестировать
… для эмбеддед приложений можно посмотреть Tessy
0
У меня есть несколько вопросов по гибким методологиям разработки.

Каким образом осуществляется деление на итерации и как так получается, что они равной длинны? Означает ли такой подход, что тот, кто платит в 25-50$, по России, в час за работу одного человека начинает проект не имея ни пресейлс плана ни экзекушен плана, или в случае внутренней разработки не проводил хотя бы R&D фазы с грубым эстимейтом?

Так ли, что если изменения можно производить когда угодно, то они начнуться со следующей итерации или даже в текущей итерации?

За счёт чего '«цена изменений» в случае agile достаточно низка даже для таких глобальных переделок'? «Глобальные переделки» — это какие передели? Смена технологического стека, например, будет дешёвой глобальное переделкой, скажем за день до сдачи проекта?

Правильно ли я понял, что планирование списока фич на итерацию, в том числе в случае новых возникших фитч или фитч из бэклога, осуществляется демократическим путём — голосованием с клиентом на общем созвоне? И в случае слива, в том числе из-за фитч возникших в середине итерации, будет сказано что-то типа «итс аджаил мэн. ноу ван ин чардж вор зис дизастер. писа ю ту».

Каким образом узнают когда всё таки закончиться проект, если отсутствует глобальное планирование и как следствие нет определённых майлстоунов? И сколько он всё таки будет стоит денег? Это я про Брукса и ИБМ360, если не ошибся. Кто несёт ответственнось за соблюдение этого плана и за его ведение, если он всё таки есть? Или все несут одинаковую ответсенность за лажу? Или никто не отвечает за лажу? Или лажа несёт ответственность за всех? :]

На сколько я знаю, разные задачи требуют для из реализации разного количества «энергии». Правильно я понял, что все в гибкой команде получают одинаковую зарплату? И что, допустим, программист может начать тестировать? Состявлять тест-кейзы, тест планы или сказать, что проект большой и я ухожу в регрессию на итерацию, а то и на две, но платить мне будете как не как КУА-лиду, а как и раньше?

Из предыдущего вытекает ещё один вопрос: кто планирует ресуры? В статье написано, что чётких ролей нет, ПМа нет, есть тим лид. Но тим лид так же пишет код, т.е. времени у него не вагон.

Я всегда воспринимал инженерные подходы, как подходы позволяющие получить повторяемый и прогнозируемый результат, не в последнюю очередь за счёт контроля процессов. Какие виды контроля в гибких методологиях разработки применяются и кем они осуществляются? Ну кроме CI?
Кстати ci, на мой взгляд, это не штука которая заставляет разработчика сломавшего билд его чинить — а ряд мер направленных на автоматизацию процесса контроля качества ПО. Ситуация с автоматической сборкой описанной в статье скоорее означает то, что кто-то не довкомитился и на проекте используется сабвёршин/тфс etc, либо разработчиков мучают шелфами.

Постоянный рефакторинг или рефакторинги, — т.к., мне что-то подсказывает, они должны быть маленькие и их много и они опять так контроллируются (к стати как, если это так?), означает ли отсутствие глобальных рефакторинг-онли итераций/нескольких итераций? Знаю что есть такая штука как «стабилизация». Если рефакторинг идёт постоянно в соотвествием с планом итерации, то получает и стабилизировать нечего? Ведь код в таком случае должен получаться красивый, только нужный функционал, хорошо структурированный — т.к. постоянно подвергается реструктуризации?!

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

Непрерывное взаимодействие с заказчиком как часто и в какой форме должна осуществляться? Не превратиться ли это в микро менеджмент стейкхолдера, хорошего продавца и создателя, скажем, машы ваз2106, но совершенно ничего не понимающего в управлении программными проектами?
0
Думаю вам будет гораздо полезнее пообщаться со специалистами занимающимися внедрением agile напрямую. Сорри, я просто не могу выделить столько времени, что бы ответить на все эти вопросы тут.
0
… пресейлс плана ни экзекушен плана
… проводил хотя бы R&D фазы с грубым эстимейтом?
… Смена технологического стека
...«итс аджаил мэн. ноу ван ин чардж вор зис дизастер. писа ю ту».
… Состявлять тест-кейзы
… КУА-лид
… Это я про Брукса и ИБМ360
… Ну кроме CI?
… Постоянный рефакторинг или рефакторинги, — т.к., мне что-то подсказывает, они должны быть маленькие и их много и они опять так контроллируются (к стати как, если это так?), означает ли отсутствие глобальных рефакторинг-онли итераций/нескольких итераций
… Знаю что есть такая штука как «стабилизация»
… Ситуация с автоматической сборкой описанной в статье скоорее означает то, что кто-то не довкомитился и на проекте используется сабвёршин/тфс etc, либо разработчиков мучают шелфами.
… бизнес требования

А можно немного поподробнее и без жаргона? Это не хамство, просто я по сути все понял, но не понял многих словечек. Извиняюсь, если что — но здесь не хабр все же, а тема интересная.
+1
Забейте, человек, нависавший этот список вопросов, знает ответы на большинство из них (вернее знает, что на большинство из них нет однозначного «правильного» ответа).

Это просто такой «высокоинтеллектуальный» вброс.
+1
Да-а-а, это крутой чел к нам залетел сюда случайно с хабра. В дорогом клифте в тонкую красную шелковую полосочку. Даже сейчас еще носится здесь запах его дорогого одеколона и звучит в ушах голос с хорошо поставленным английским акцентом.
0
Да-а-а, это крутой чел к нам залетел сюда случайно с хабра.

Нет, Вы поняли, ИМХО, данный человек действительно «в теме», он задает «правильные» вопросы, но подозреваю, он сам знает ответы на эти вопросы. Просто, в контексте того, что данная статья является обзорной

(типо исторический экскурс)

комментарий данного товарища выглядит как попытка «тонкого» вброса (возможно, я ошибаюсь)
0
комментарий данного товарища выглядит как попытка «тонкого» вброса (возможно, я ошибаюсь)
Всякое может быть. В любом случае обстоятельный ответ это изрядный кусок писанины. Если на книжку и не потянет, то уж на серию статей точно. У меня просто нет столько времени, что бы давать такой ответ. Тем более, что на все эти вопросы можно найти ответы самостоятельно, благо статей и книг по agile предостаточно.
0
Но не очень обстоятельный, сравнимой с вбросом длины, почитать было бы интересно.
0
Попробую, но очень кратко и не на все.
Каким образом осуществляется деление на итерации и как так получается, что они равной длинны?
На итерации специально никто ничего не делит, ее длина просто устанавливается фиксированной. Длина итерации выбирается командой исходя из собственного опыта. Делать ее меньше 2 недель не имеет смысла. Начало и конец фазы сопровождаются дополнительными процедурами типа планирования итерации и ретроспективы, которые отнимают некоторое время, так что в случае более короткой итерации растут накладные расходы. Делать ее длинной тоже не имеет смысла, поскольку усложняется планирование и выход на «рабочую скорость» команды.

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

За счёт чего '«цена изменений» в случае agile достаточно низка даже для таких глобальных переделок'?
За счет постоянного рефакторинга и покрытия тестами на уровне близком к 100%.
«Глобальные переделки» — это какие передели? Смена технологического стека, например, будет дешёвой глобальное переделкой, скажем за день до сдачи проекта?
Длинная тема, требующая более детального описания процессов, в частности планирования итерации и других деталей.
Правильно ли я понял, что планирование списока фич на итерацию, в том числе в случае новых возникших фитч или фитч из бэклога, осуществляется демократическим путём — голосованием с клиентом на общем созвоне?
Все фичи запрошенные клиентом кладутся в беклог и сам клиент определяет их приоритет. Выбор задач на итерацию делает команда (с учетом приоритетов заданных клиентом, естественно). Клиент не знает (и ему это нафиг не уперлось знать) всех внутренних зависимостей в порядке имплементации.

И в случае слива, в том числе из-за фитч возникших в середине итерации, будет сказано что-то типа «итс аджаил мэн. ноу ван ин чардж вор зис дизастер. писа ю ту».
Фичи могут возникать когда угодно. В работу они пойдут не раньше начала следующей итерации.

Каким образом узнают когда всё таки закончиться проект, если отсутствует глобальное планирование и как следствие нет определённых майлстоунов?
Если совсем коротко, то майлстоуны в этом случае это список необходимых фич. Глобальное планирование делается, но оно имеет другой вид. После нескольких первых итераций (или если команда устоялась, по данным с предыдущего проекта) известна т.н. велосити команды. По списку фич от клиента делаются грубые естимейты. Из этих двух параметров можно достаточно точно планировать что и когда будет готово. В случае возникновения каких-то непредвиденных факторов (что-то оказалось значительно сложнее, чем оценивалось или наоборот), делается перепланирование (вместе с клиентом).

Правильно я понял, что все в гибкой команде получают одинаковую зарплату?
Нет.

И что, допустим, программист может начать тестировать?
То, что уже есть. Пишутся автоматические тесты (как минимум интеграционные, но в подавляющем большинстве случаев еще и регрессионные).
Одно существенное дополнение: фактически беклогов два — бизнес и технический. В каждую итерацию помимо бизнес задач включается и какой-то процент задач из технического беклога. Написание кусков для тестирования (скажем, оболочки поднимающей приложение в окружении близком к реальному и прогоняющей тесты) попадает в технический беклог. Последующее добавление тестов туда для реализованых фич, как правило, делается в рамках реализации тикета.

Я всегда воспринимал инженерные подходы, как подходы позволяющие получить повторяемый и прогнозируемый результат, не в последнюю очередь за счёт контроля процессов. Какие виды контроля в гибких методологиях разработки применяются и кем они осуществляются? Ну кроме CI?
Коротко ответить не получится, сорри.
Кстати ci, на мой взгляд, это не штука которая заставляет разработчика сломавшего билд его чинить — а ряд мер направленных на автоматизацию процесса контроля качества ПО. Ситуация с автоматической сборкой описанной в статье скоорее означает то, что кто-то не довкомитился и на проекте используется сабвёршин/тфс etc, либо разработчиков мучают шелфами.
Любой тикет закрывается не раньше, чем код будет вкомичен, билды на CI пройдут успешно и код пройдет ревью. Так что никаких шелфов или недовкомитов.
Постоянный рефакторинг или рефакторинги, — т.к., мне что-то подсказывает, они должны быть маленькие и их много и они опять так контроллируются (к стати как, если это так?), означает ли отсутствие глобальных рефакторинг-онли итераций/нескольких итераций?
Никаких «рефакторинг онли» или «тест онли» или «стабилизаций» нет. Если есть необходимость в каком-то большом рефакторинге, то соответствующая задача попадает в технический беклог. Отдельного контроля нет, такой тикет закрывается на равне с остальными и контролируется тестами.
В случае минимальной документации, кто хранит бизнес требования и в какой форме? Как эти знания оказываются в команде?
Бизнес требования описываются в виде пользовательских историй и хранятся в трекере. На этапе планирования они разбиваются на тикеты, эстимируются и берутся в работу.
Как формируются требования на фитчи?
Из общения с заказчиком. Подробнее, увы, не получится, тоже обширная тема.
Как сделать так, что бы при сдаче проекта не оказалось что клиент не хочет платить деньги — т.к. проект не реализует всех фитч, которые ему нужны?
Тоже очень коротко: к каждой пользовательской истории есть согласованный с заказчиком критерий (в некотором смысле тест) отвечающий на вопрос «как узнать, что фича реализована?»
Непрерывное взаимодействие с заказчиком как часто и в какой форме должна осуществляться?
Если совсем-совсем коротко: на стороне заказчика есть т.н. project owner, который может ответить на любые вопросы по бизнесу, он же устанавливает приоритеты задачам. С ним же идет общение по любым вопросам типа уточнения требований и так далее. Общаться может любой член команды в процессе работы над тикетом и так часто как это необходимо.
Не превратиться ли это в микро менеджмент стейкхолдера, хорошего продавца и создателя, скажем, машы ваз2106, но совершенно ничего не понимающего в управлении программными проектами?
В этом смысле команда достаточно хорошо изолирована от подобного вмешательства. Заказчик не может сказать кому, что и в каком порядке делать.

Думаю ответы породят еще больше вопросов.
0
Думаю ответы породят еще больше вопросов.
А то!)

Что такое бэклог, кстати? И что такое шелф?
И вот этот вопрос переведи на человеческий:
Не превратиться ли это в микро менеджмент стейкхолдера, хорошего продавца и создателя, скажем, машы ваз2106, но совершенно ничего не понимающего в управлении программными проектами?
0
Бэклог это список задач которые нужно сделать. Чаще всего это список открытых тикетов в трекере.
Шелф («полка») это механизм имеющийся в некоторых IDE (в частности в Idea и еклипсе с установленным плагином от TeamCity), который позволяет «положить на полку» текущие изменения в локальной копии сорсов и вернуться к последнему синхронизированному с системой контроля версий состоянию. Применяется, чаще всего, когда нужно приостановить работу над текущей задачей и сделать что-то другое. Когда работа над этим другим завершена, отложенные изменения можно вернуть на место и продолжить работу. Правда, появление таких ситуаций, как правило, означает, что что-то или кто-то имеет возможность вмешиваться в работу над текущей задачей, а это, в свою очередь, сигнал об появлении того, что упоминается в следующем вопросе — микроменеджменте.
И вот этот вопрос переведи на человеческий:
Если вкратце (и очень грубо), то есть две стратегии управления — а) руководитель дает задачу и проверяет результат не вмешиваясь в работу подчиненных и б) руководитель дает задачу и тщательно следит за тем, что и как делают подчиненные, постоянно вмешиваясь в их действия, лезет в детали и указывая им что и как делать. Вот последнее и называется микроменеджментом. Ну а стейкхолдер это вот такая штука. Надеюсь с этими пояснениями перевести вопрос не составит труда.
0
Правда, появление таких ситуаций, как правило, означает, что что-то или кто-то имеет возможность вмешиваться в работу над текущей задачей, а это, в свою очередь, сигнал об появлении того, что упоминается в следующем вопросе — микроменеджменте.

А случайно увидел баг? У меня так часто бывает.
0
А случайно увидел баг? У меня так часто бывает.
Баги фиксятся сразу, естественно.
0
Сразу но не вместе с остальными изменениями, надо разбить на разные коммиты.

Кстати не могу найти подходящего софта для этой задачи. В результате каждая фиксация называется «A lot of small changes».
0
Сразу но не вместе с остальными изменениями, надо разбить на разные коммиты.
Естественно.
Кстати не могу найти подходящего софта для этой задачи. В результате каждая фиксация называется «A lot of small changes».
Я в таких случаях рекомендую заводить тикет на багу. Иногда (чаще всего), тикет заводится сразу, заканчивается текущий тикет, а сразу за ним фиксится и комитится найденная бага. Тогда в трекере остается «след», а комит оказывается привязанным к тикету.
0
Да, по поводу коммитов забыл упомянуть такую вещь: у TeamCity (может уже и Jenkins сподобился) есть такая замечательная фича как Remote Run. Она позволяет прогнать определенные билды с тем котом, который планируется вкомитить (ну и автоматически вкомитить, если билды были успешными). Это позволяет изменить схему вкомитил-поломалось-пофиксил-вкомитил (и так, возможно, несколько раз) дна проверил — вкомитил или проверил — починил — вкомитил (тоже, возможно, несколько раз). Ну и, конечно, с ее использованием в транке всегда работающий код.
0
котом
кодом, конечно же.
0
«Многие словечки» довольно наглядно иллюстрируют насколько сильно отличается разработка софта от других видов инженерной деятельности. Специфика проектов (в смысле желаний заказчика) и «сырья» (то есть кода) потребовала полного пересмотра всех этапов процесса разработки и выработки совершенно новых подходов как к отдельным этапам, так и к разработке вцелом. Специалистам из других областей зачастую эти подходы кажутся неправильными или, как минимум, непривычными. Тут есть два варианта: вникнуть в подробности процессов, либо принять на веру, что люди, участвующие в выработке этих подходов, как минимум не глупее других инженеров, а, следовательно, раз развитие пошло по этому пути, на то есть какие-то причины. Есть еще вариант lifelover-а, конечно.
Данным топиком я попытался дать хотя бы краткий обзор причин, из-за которых разработка софта выглядит так как выглядит. Единственное, что хотелось бы добавить (точнее акцентировать на этом внимание): разработка софта меняется очень медленно. Не хочу углубляться в причины, лишь напомню факты уже упомянутые в статье — на принятие в повседневную практику даже самых очевидно правильных и полезных изменений зачастую уходят десятилетия. Казалось бы, структурное программирование совершенно правильный и логичный шаг. Тем не менее, оно появилось в 60-х, а в споры о нем продолжались минимум до средины-конца 80-х. ООП — те же 60-е, в повседневной практике — начало 90-х, «бригада главного программиста» и адаптивное проектирование — начало 70-х, agile manifesto — 2001-й, но в повседневной практике еще очень далеко не везде.
0
Вы забыли про МЕЛОК МАШЕНЬКА
0
ладно, немного раскрою тему.
начало
отжиг
конец
+3
Какой интересный доклад.
0
А Вы осилили? Я как-то не люблю видео-лекции, предпочитаю загрузить в книжку или прямо с экрана ПК читать. Я так понял, это «чистый» интернет-программист, мне их тяжело воспринимать. Так, пролистал кинушки… Я в прошлой жизни был инженер, им и остался. Поэтому для меня материя первична :-) Обычно там много слов и теории, красивые и сытые парни и девочки вещают… А жизнь, она приземлённей как-то…
+1
А Вы осилили?
да не, там вообще про программинг почти ни слова. посмотри — прикольно парень гонит.
+1
Осилил. Вначале подумал «ну нафиг длинное видео смотреть, гляну кратко о чем оно», а оно оказалось таким интересным, что просмотрел на одном дыхании.
0
Если всё работает плохо и медленно, можно с умным видом рассказать о методологиях разработки и сложности ПО. Если же вообще ничего не заработало, и подобные отговорки не годятся, тоже не беда, ведь всё равно есть некий функционал.
0
Все работает плохо и медленно исключительно у вас. У меня плохо и медленно работает только плохо написанный софт, которого с каждым годом становится все меньше. Как правило тот софт, который работает плохо и медленно, написан с применением рекомендуемых вами методов.
+2
У меня почему-то тоже плохо и медленно работает только плохо написанный софт, которого, к сожалению, с каждым годом становится все больше. Как правило тот софт, который работает плохо и медленно, написан с применением рекомендуемых вами методов.
0
У меня почему-то тоже плохо и медленно работает только плохо написанный софт, которого, к сожалению, с каждым годом становится все больше.
Это не удивительно, поскольку вы не раз убедительно доказали, что именно такой софт и выбираете.
Как правило тот софт, который работает плохо и медленно, написан с применением рекомендуемых вами методов.
Вообще-то вы ничего о методах написания софта не знаете. Это вы тоже неоднократно продемонстрировали.
+1
Это не удивительно, поскольку вы не раз убедительно доказали, что именно такой софт и выбираете.
Угу. Ведь зачастую выбирать не из чего. Впрочем, для меня лучший софт — максимально быстрый, надёжный и простой. Не примитивный, а простой. Впрочем, неспособность отличить простое и примитивное вы продемонстрировали многократно. Также как и то, что по-настоящему быстрого софта, очевидно, много лет не видели. Поскольку после такого софта желание пользоваться линухом и эклипсом пропадает начисто (да и нетбинс хорошо напрягает).
0
Поскольку после такого софта желание пользоваться линухом
Хм, ллео раскрыл хорошо раскрыл эту тему.
0
Ведь зачастую выбирать не из чего.
Вам — да.
Впрочем, неспособность отличить простое и примитивное вы продемонстрировали многократно.
Точнее, вам так хочется думать.
Также как и то, что по-настоящему быстрого софта, очевидно, много лет не видели.
Я им каждый день пользуюсь. Да, я в курсе, что у вас все тормозит. В том числе линух. Сочувствую, это карма.
0
Вам — да.
Разумеется. Говном пользоваться брезгливо как-то. (Упреждая ваш «остроумный» ответ, нет пользуетесь им вы, а не я).

Да, я в курсе, что у вас все тормозит. В том числе линух.
Не только у меня, но и у ллео.

Вообще-то вы ничего о методах написания софта не знаете.
Даже лурк о методах написания софта немного знает.
Но к энтерпрайзу это как раз и не относится: потянуть тысячи объектов из базы через ORM, чтобы посчитать что-нибудь в цикле — это для них обычное дело.
Впрочем, оставим лурк. Это всё же развлекательный ресурс. Но вот между тем, энтерпрайз-говносистемы добрались и до промышленности. Дело в том, что и там, бывает, хватает денег. Более того, иногда «требуется» сделать подороже. На спрос рождается и предложение. Существуют системы, созданные специально для того, чтобы можно было показать комиссии куда были потрачены средства. Стоп… А не на этом ли держится весь ваш «энтерпрайз»? Это пользователю бывает в лом поставить очередную плашку. А когда можно и нужно тратить «от души», не проблема на каждый чих по серверу поставить, минимум с 32GB RAM (впрочем, при желании и 1TB не проблема сунуть). Топовые видюхи в операторских станциях — обычное дело.

Сочувствую, это карма.
Вот и скажите про карму инженерам, которые всё это внедряют. Времени обычно едва хватает на установку обычной системы. Время, потраченное на борьбу с быдлокодерскими поделками приходится компенсировать свободным временем (фактически, на сон зачастую остаётся по 3 часа). Не думаю, что вашу шутку про карму правильно поймут.
-1
Говном пользоваться брезгливо как-то.
Но именно это вы продолжаете делать.
Даже лурк о методах написания софта немного знает.
Лурк может и знает, вы — нет.
Существуют системы, созданные специально для того, чтобы можно было показать комиссии куда были потрачены средства.
Наверное в вашей отрасли это встречается. У меня — нет.
Стоп… А не на этом ли держится весь ваш «энтерпрайз»?
Не переживайте, вам я не конкурент.
А когда можно и нужно тратить «от души», не проблема на каждый чих по серверу поставить, минимум с 32GB RAM (впрочем, при желании и 1TB не проблема сунуть).
Для вас — возможно. Во всех моих проектах потребление памяти редко превышает гиг. Речь идет о системах обслуживающих многие тысячи пользователей.
Вот и скажите про карму инженерам, которые всё это внедряют.
Я сам это все и внедряю.
Не думаю, что вашу шутку про карму правильно поймут.
Это не шутка, а попытка найти объяснение тому, что у вас все тормозит. Сначала я предположил, что виновата винда, но когда отписались камрады, у которых и под виндой ничего не тормозит, рациональные объяснения закончились, остались иррациональные.
0
Но именно это вы продолжаете делать.
Я уже это слышал. Вы это повторяете третий или четвёртый раз.
Упреждая ваш «остроумный» ответ, нет пользуетесь им вы, а не я.
Нет смысла повторять это снова и снова.

Не только у меня, но и у ллео.
Это тактично проскипали, ведь вся ваша аргументация держится на том, что «у меня всё плохо, а у всех хорошо». Если вдруг окажется, что моё мнение разделяют другие люди, аргументация рассыпается, а что-то более умное придумывать лень. Поэтому проще ссылку проигнорировать.

Наверное в вашей отрасли это встречается. У меня — нет.
Это всё пришло именно из «энтерпрайза». Просто выползло из жирных датацентров и приползло в промышленность. Туда где слишком много денег (впрочем, заниматься всем этим приходится обычным инженерам).

Это не шутка, а попытка найти объяснение тому, что у вас все тормозит.
У меня тормозит не всё, а только говнософт. Причём о том, что такое «тормозит», у меня своё понимание. Хотя для вашей «аргументации» проще, чтобы тормозило всё. Тогда даже не придётся рассуждать про разницу в «функционале», достаточно отплеваться в духе «а у него не тормозит». Впрочем, моё мнение такое же, как и у ллео. Да и сама статья отличная, я бы подписался почти под каждым словом.
-1
>>Не только у меня, но и у ллео.

Это тактично проскипали, ведь вся ваша аргументация держится на том, что «у меня всё плохо, а у всех хорошо». Если вдруг окажется, что моё мнение разделяют другие люди, аргументация рассыпается, а что-то более умное придумывать лень. Поэтому проще ссылку проигнорировать.
вы уверены, что хотите разбора «статьи великого» с точки зрения закоренелого виндузятника? ;)
прочитал первые два абзаца и по каждому реакция «сам дурак!» ну бред ведь написан и необоснованные наезды. бум читать дальше.
+1
дочитал. мнда. ну и бред обиженного хомячка.
+3
дочитал. мнда. ну и бред обиженного хомячка.
Я такой же обиженный хомячок. Впрочем, вот реакция на статью ещё одного человека.
xxx: www.razgovor.org/special/article588/
Как же хороша эта статья! :)
yyy: сейчас посмотрю, книжечку слушаю
yyy: читаю. пока что вещи очевидные для меня говорятся, просто очень эмоционально. Конкретных фактов о Линуксе я, конечно, не знал. Но подозревал, что он плох. Иначе бы все давно перешли на него, уж по крайней мере с семерки-то
xxx: Ну, мне кажется, эмоциональность тут оправдана. Более чем.
yyy: с другой стороны стоит ли источать такие эмоции в подобных случаях? пора уже привыкнуть, к подобному отношению со стороны корпораций к пользователям, это надо воспринимать как данность и бесстрастно думать как жить в такой атмосфере, что делать и т. д. не стоит тратить нервы на них
Вот уже третий.

ЛЛео? Как он разделался с либрусеком! Спасибо. Очень хороший пример и прецедент. Если он и хомячок, то ты — микроб. А очередной высер вроде этой статьи, призванный пояснить почему всё и должно быть так херово, как описал ЛЛео, возможно, действительно не стоит нервов и времени. Я ведь тоже хотел книжку почитать.
0
угу. статья просто «замечательная». сплошные «я хочу», «я требую», и «я не намерен разбираться». передергивания и некорректные сравнения (ХРень 2000гв и убунта 2008гв, еще и 98 хз зачем приплел).
1) он ничуть не авторитет. 2) я оцениваю конкретный высер.
Я такой же обиженный хомячок.
самокритично. )))
+2
Конкретных фактов о Линуксе я, конечно, не знал. Но подозревал, что он плох.
Авторитетное мнение, да.
+2
Вы аргументируйте почему у него бред написан, а то так можно на что угодно сказать бред. Ллео отчасти прав, правда дело не в линуксе, виндовсе итд.
0
я ведь следующим комментом написал почему. а устраивать разбор и провоцировать очередную ветку комментов нет желания.
0
У меня тормозит
пиши в спортлото
0
Честно говоря, надоело читать ответы в стиле «раз у других тормозит, значит я прав насчет причин происходящего, виноваты новомодные жабы и оопы. Вот вам писулька/скриншот, где все хреново, так же как и у меня». Попытки выяснить логические построения стоящую за вашими выводами ни к чему не привели, вы продолжаете отвечать не на те вопросы, которые вам задают и игнорируете аргументы. Пожалуй, на этом я перестану комментировать ваши опусы.
0
Я бы так громко не говорил что хром или фф, которые тормозят на 1 гиге это говнософт, Но в тоже время, я согласен.
0
Хром таки не настолько много жрет, в 280МБ он укладывается с полудесятком вкладок. Впрочем, для браузеров это нормально. А вот на системах без аппаратного ускорения графики он тормозит знатно)
0
при запуске да, при 10 вкладках жрет как не в себя.
0
Знаешь, после оперы с несколькими сотнями вкладок даже фуррифокс за экономичный сойдет.
0
вот и я о чем, что все таки проблема есть.
0
Да, она в том, что оперу я пользую неправильно. Она оптимизирована под скорость переключения вкладок, а не под то, что у меня будет несколько сотен вкладок, 90% которых я не открываю месяцами.
0
цифра 1 гиг, меня пугает, я конечно понимаю, вы linux-ы и windows-ы сами не пишете. Но боюсь через года два-три-четыре… при той же функциональности оно будет есть все 2-а гига, 3-гига… И вообще господа прекращали бы вы друг другом гавном поливать, все равно каждый останется при своем мнение.
+1
Почему при той же? Функциональность растет. К тому же, потребляемая системой память растет вместе с самой памятью хотя бы потому, что где-то нужно держать таблички страниц (которых становится больше), кэши таблиц ФС (которая тоже жрет все больше и больше, с ростом размеров дисков и количества файлов на них) и т.д.
Рост потребляемых ресурсов связан с тем, что растут сами ресурсы — можно задействовать больше ресурсов и решить задачу лучше. Экономия ресурсов сама по себе ничего не дает — ведь по сути простаивающий ресурс это то же самое, что истраченный впустую, поэтому те же ОС задействуют примерно один и тот же процент ресурсов от современного им железа, оставляющий разумный запас ресурсов для других программ. По этой же причине сами программы, за исключением резидентных, стараются задействовать максимум ресурсов для максимально качественного решения задачи (самый наглядный пример — это игры, задействующие все ресурсы и старающиеся выжать из них максимально хорошую картинку).
+1
«Лучше» — это настолько относительное понятие, что лучше его здесь не применять.

Я скорее говорю, что ресурсы используются не оптимально для поиска решения.
Потом здесь надо сказать, что я говорю об одной, неважно какой, конкретной задачи, а вы о множестве задач. На выполнение одной задачи выделяются все ресурсы, простой возможен только по выполнению.
Допустим одна задача имеет минимальное время решения 10 тактов. Но, при нехитрых манипуляциях эту же задачу можно решить за 20 тактов. Это уже дело оптимизации и умения программера. Но из-за низкой цены производительности программеру совершенно все равно будет выполнено 10 шагов или 1000. И вот это печально. А если это крутится в какой нибудь виртуальной машине/ОС/[еще что нибудь] к этим 1000 шагам надо добавить шаги на сборку, запуск итд, это плохо. Но удобно.
0
И что? Все это начинает иметь значение только тогда, когда ресурсов не хватает на решение задачи. Либо когда ресурсы можно было сэкономить и сэкономленное задействовать на улучшение решения задачи.
Оптимизация же там, где она не нужна — зачастую зло. Она или повысит цену разработки, или бажность программы, при этом не давая ничего.
Разумеется, это не значит, что оптимизировать не нужно. Но оптимизировать надо там, где это оправдано.
+1
это, конечно, скорее моя жадность. Но если размеры вычислительных систем постоянно растут, значит их не хватает.
Опять таки, улучшение — это оптимизация. Единственное что важно для тьюринговой машины количество шагов сделанных по алгоритму и размер затраченной памяти. Единственный «нет» оптимизации — это цена разработки ПО, но тогда они с лихвой компенсируются ценой аппаратных средств
0
Да, не хватает. Вопрос в том, на что их не хватает. Вот это и требует оптимизации. Если ты выигрываешь 10% в цикле работы алгоритма сжатия — это одно, а если 10% в цикле обработки сообщений окну, который более 99% времени проводит в ожидании следующего сообщения — это другое.
И цена — не единственная причина «нет» оптимизации. Вторая — читабельность, поддерживаемость и масштабируемость кода. В документации LZO, например, прямо сказано — «код нечитабелен, так как оптимизирован по скорости выполнения». Там эта оптимизация полностью оправдана, впрочем.
+2
другими словами вы поощряете костыли в коде? Возможно они конечно перекроються мегагерцами, как сказано было в видео выше, но зачем?

На самом деле я не говорю о практической части. Практическая часть местами зашла в такую жопу что выбраться от туда не представляется возможным. Как минимум для ПК, в электронике это еще не настолько видно, процент кто использует pic10 для того что бы подергать ногой выше, чем процент кто для этой задачи берет adruino с мегой32 наборту, хотя даже здесь я скорее всего неправ

В теории как раз наоборот, со стороны пользователя должно(!) ценится исключительно количество тактов его машины и соответственно количество памяти, потому что за это платит клиент, а не разработчик.
Да и конечного пользователя не должно в 99% волновать что у него под капотом. (в действительности выходит все именно наоборот, из-за этого качество кода падает ниже Марианской впадины)
0
другими словами вы поощряете костыли в коде?
Напротив, оптимизация зачастую и есть внесение костылей в код.
В теории как раз наоборот, со стороны пользователя должно(!) ценится исключительно количество тактов его машины и соответственно количество памяти, потому что за это платит клиент, а не разработчик.
Клиент, как раз таки, платит за оптимизацию. В самом прямом смысле, вечнозелеными баксами. Ну, если отвлечься от варианта, когда весь софт ломаный.
Даже если софт бесплатный, то оптимизация оплачивается багами, которые могли бы быть вместо нее пофикшены, или функциональностью, которая могла бы вместо нее быть добавлена.
Т.е. оптимизация отнюдь не бесплатна и отнюдь не безвредна. Поэтому оптимизировать надо с умом.

Еще один забавный момент — компромиссы. Здесь наглядны те самые браузеры, которые жрут память тоннами для снижения нагрузки на процессор.
+2
Извиняюсь, мне кажется мы говорим о разных вещах, отсюда столь большой холивар.
0
Но из-за низкой цены производительности программеру совершенно все равно будет выполнено 10 шагов или 1000. И вот это печально.
Узкое место в программе это примерно 3% кода. Остальное вылизывать смысла никакого нет, это ни на что не повлияет и скорость работы программы если и улучшится, то этого никто не заметит.

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

P.P.S. бывает и меньше 3%. на одном из последних проектов подняли производительность почти в 4 раза изменив в общей сложности около 10 (прописью: десяти) строчек в разных местах продукта (а всего кода там несколько миллионов строк).
+2
цифра 1 гиг, меня пугает, я конечно понимаю, вы linux-ы и windows-ы сами не пишете.
Для подобных систем 1 гиг это очень не много.
Но боюсь через года два-три-четыре… при той же функциональности оно будет есть все 2-а гига, 3-гига…
То, что пишу я — не будет. Да и сменят ее не через 3-4 года, а лет так через 20, а то и позже. Во всяком случае предыдущая версия системы где-то так и проработала.
0
цифра 1 гиг, меня пугает,
почему пугает? четыре гига нынче стоят вполне доступный полтинник.
0
Линукс можно обрезать как хочется, у меня сейчас используется 108 мб (~50 из них на luakit). И это мне почти ничего не стоит, я не патчу ядро и т.п. только выбыираю более легкий софт и собираю его только с тем, что мне надо.
+1
Даже лурк о методах написания софта немного знает.
В том-то и дело, что лурк знает и шутит для посвященных. Посвященный посмеется, непосвященному покажется, что говном поливают. Стоит заметить, по твоему любимому С на лурке тоже прошлись с сарказмом, как, впрочем, практически по всему.
0
ваш софт работает лучше от лучшей конфигурации того на чем оно запускается
0
У меня довольно большой зоопарк железа. И нового среди них почти нет (вот ноут новый, да, остальное покупалось 2-3 и больше лет назад). Я вполне допускаю, что конфигурация может оказаться и лучше, чем у lefelover-а, все-таки для меня это профессиональные инструменты, а не игрушки. Но я не понимаю, что мешает ему обновить железо, если его не устраивает существующее.

Почему-то в разговорах о «тормозах» софта совершенно выпало из рассмотрения то, что за последние 10-15 лет совершенно поменялся паттерн работы пользователей. «На заре» персональных компьютеров активный процесс был ровно один. С появлением многозадачности активных процессов стало больше, но, в основном, за счет мелочевки. Основная программа все равно была одна. Открываешь ворд — будь добр закрыть ексель, иначе тормозит. Открыл браузер и он тормозит — закрой ворд. Запустил среду разработкы — все остальное выкоси нафиг, иначе тормозит. И это не то «легкое» (хотя и раздражающее) притормаживание, которое чаще всего наблюдается сейчас. Нет, «тормозит» это значит, что система ушла в глубокий своппинг и можно спокойно идти пить кофе и курить, очнется она не раньше чем через несколько минут. Сейчас же у обычного пользователя активных программ десятки, бросить браузер, офис и еще кучу всего открытыми, что бы поиграться в любимую игрушку — норма. У людей активно использующих компьютер, активных (и достаточно тяжелых) программ — многие десятки, а то и сотни. И все они, как бы хорошо не были написаны, потребляют отнюдь не нулевое количество памяти и процессора. Да и диска тоже. Неужели кто-то всерьез полагает, что такое удобство и свобода достаются бесплатно, а в «тормозах» виноваты «оопы и явы»?
+5
Вот в точку сказано. В самое яблочко.
+2
Да и сам контент изменился. 1080p смотреть всем хочется.

Что далеко ходить, браузер много у них жрёт? А попробуйте открыть тем же хромом страничку с голым html. Нету такой? Вон оно чё, Михалыч!
Да вот ради интереса открыл исходный код этого самого треда. 13130 строк. Тринадцать тысяч строк! Плюс там скрипты, которые надо отрабатывать, там контент в виде како-го нибудь флеша и ещё хрен знает чего (не разбираюсь в вебе), которому нужна память. На этой вкладке железо 10-летней давности просто захлебнулось бы.
+1
Вы хороший писатель.
0
Писатель я, как раз, не очень. С трудом удается впихивать в сжатый текст нужный объем информации.
0
Мы, конечно, можем поспорить какой Вы не плохой писатель =)
Ну а впихивать невпихуемое трудно по определению, поэтому я и оставил комментарий. Успехов!
0
Мы, конечно, можем поспорить какой Вы не плохой писатель =)
Я трезво оцениваю свои способности в этом деле :)
Ну а впихивать невпихуемое трудно по определению, поэтому я и оставил комментарий. Успехов!
Спасибо.
0
Добавил в конце ссылку на одну весьма полезную книжку.
0
  • avatar
  • evsi
  • 02 марта 2013, 15:20
в брожении за этой книгой в одной из статей нашел просто замечательное высказывание:
Впрочем, и здесь очень многие понимают оптимальность встроенного ПО довольно своеобразно. Отчасти это своеобразие объясняется бедностью инструментальных средств для разработки встроенных систем, отчасти тем, что многие разработчики систем на основе микроконтроллеров владеют паяльником гораздо увереннее, чем языками программирования, и не имеют професиональных навыков в области программной инженерии. Как известно, природа не терпит пустоты — там, где нет знаний, их заменяют предрассудки, а там, где нет уверенности, ее успешно заменяет упертость. Один из наиболее живучих предрасудков — встроенное ПО следует разрабатывать только на ассемблере; код, написанный на языках высокого уровня (в частности, на C) заведомо ущербен и неоптимален. При этом, чем меньше навыков программирования, тем крепче упертость сторонника мифа. (Есть, конечно, и другие суеверия, но они лежат за рамками данной статьи).
и еще
Немногочисленные уцелевшие староверы гнут свою линию, что программирование на языках высокого уровня, особенно объектно-ориентированных — зло и сила в ассемблере, что использование разных оболочек (особенно .NET) — для убогих и выбор гуру — программирование на API, и т.д. Однако когда доходит до дела, обычно оказывается, что результат их воистину титанических усилий настолько незначителен, что не они сегодня определяют погоду на рынке ПО. Побеждают те, кто первым реагирует на потребность пользователя, а лишние мегабайты — кто их считает, когда гигабайтная планка памяти стоит чуть больше десяти долларов?
+2
Как много пафосных слов — «бедность инструментальных средств», «программной инженерии», «професиональных навыков» и прочее.

Тем не менее современные быдлокодеры ничего нормального написать не способны. Разве что если взять быдлокодера и требовать писменного отчёта о каждом потраченном байте, обоснования каждой написанной функции, получится программист. А так только и будет рассказывать о своей продвинутости и богатстве средств, выдавая всё более тормозное говно.
-1
Получится тонна бумаги и недописанный уродец.
+1
Зато поубавится желания разбрасываться гигагерцами и гигабайтами.
0
Врядли. Скорее появится желание сжечь менеджера в тонне написанных по его требованию отчетов.
0
Это никак не изменит вашего желания запускать 100500 программ, разбрасываясь гигагерцами и гигабайтами. И от этого не спасет никакая оптимизация и написание всего на С.
+1
Как много пафосных слов — «бедность инструментальных средств», «программной инженерии», «професиональных навыков» и прочее.
Правда глаза колет?
Тем не менее современные быдлокодеры ничего нормального написать не способны.
Да, от вас трудно ожидать чего-либо вменяемого.
Разве что если взять быдлокодера и требовать писменного отчёта о каждом потраченном байте, обоснования каждой написанной функции, получится программист.
Получится такой же быдлокодер.
А так только и будет рассказывать о своей продвинутости и богатстве средств, выдавая всё более тормозное говно.
Да, именно этим вы и занимаетесь, рассказывая как правильно надо писать программы. При том, что продемонстрировать эту правильность на практике вы не в состоянии.
+1
При том, что продемонстрировать эту правильность на практике вы не в состоянии.
А вы способны? Только и слышно от «продвинутых специалистов по программной инженерии» — «API — плохо, фреймворки — хорошо», «Ассемблер — плохо, ООП — хорошо». На деле результат — всё более унылое и раздутое говно.
0
А вы способны?
Да.
На деле результат — всё более унылое и раздутое говно.
Нет.
0
Да.
Не думаю. Правильность демонстрируют те, кто программируют компьютер Вояджера. А твои явы и оопы — это правильность только с точки зрения засирания памяти и загрузки CPU бесполезной работой.
0
Не думаю.
А вы вообще этого никогда не делаете, судя по той чуши, которую пишете.
А твои явы и оопы
Они не мои.
это правильность только с точки зрения засирания памяти и загрузки CPU бесполезной работой
Нет.
+1
Если бы фаерфокс писали программисты вояджера, то он бы не жрал, не тормозил, не глючил, имел бы функционал менее чем у IE6 и стоил мегабакс.
+2
и при этом мы наслаждались какой-нить версией 1.0.012 без поддержки стандартов. и быс страшным как грех.
0
1.0. Вояджерам апдейты не положены.
0
имел бы функционал менее чем у IE6
И это хорошо. Задача браузера — показывать странички, каждая из которых — немного текста и картинок. Не было бы стандартов, таких же раздутых и дерьмовых, как и всё остальное.
0
Сперва посчитай, сколько времени ты бы копил деньги, чтобы браузер купить. Напомню, его цена была бы $999999.
+1
«API — плохо, фреймворки — хорошо»
Ваша любимая межка — это фреймворк в чистом виде.
0
Ваша любимая межка — это фреймворк в чистом виде.
Чушь какая-то. Вот что такое фреймворк:

HelloWorld на zend framework.

А межка — это микроконтроллер.
-1
Чушь какая-то
Такой заголовок должен быть у каждого вашего поста на эту тему. А межка в терминах ПО это именно фреймворк. И когда вы на ней светодиодиком моргаете, то картина получается куда как печальнее, чем на той картинке. Другой вопрос, что вы никогда ее не пытались нарисовать во всех деталях.
+2
А межка в терминах ПО это именно фреймворк. И когда вы на ней светодиодиком моргаете, то картина получается куда как печальнее, чем на той картинке.
На эту тему можно отдельный холивар устроить зачем в устройство для мигания светодиодком вообще ставить «межку». И это будет также верно как зачем писать hello_world на java, вместо echo «hello world»,
А суть этого всего что стоит пользоваться достаточным минимумом. Но к сожалению он у всех разный. Я против использования фреймворков, сторонних библиотек, итд.., там где они не нужны.

вот скажите, для примера, что будет вернее? Создать обьектную модель mcu со всеми регистрами итд, или просто обратится по адресу?
0
Но к сожалению он у всех разный. Я против использования фреймворков, сторонних библиотек, итд.., там где они не нужны.
Каков критерий «нужности»?
вот скажите, для примера, что будет вернее? Создать обьектную модель mcu со всеми регистрами итд, или просто обратится по адресу?
«Объектная модель MCU»? Вы действительно думаете, что применение ООП предполагает именно это?
0
повторюсь, ооп удобно в интерфейсах, еще где нибудь где надо разбить нечто целое на отдельные обьекты и придумать взаимодействие этих обьектов. Но оно незачем если вы описываете один обьект и его взаимодействие со средой.
0
повторюсь, ооп удобно в интерфейсах, еще где нибудь где надо разбить нечто целое на отдельные обьекты и придумать взаимодействие этих обьектов. Но оно незачем если вы описываете один обьект и его взаимодействие со средой.
И что?
0
а то что оно ненадо там где оно ненадо, также и с фреймворками, а не то что раз ресурсов хватает можно лепить
0
а то что оно ненадо там где оно ненадо, также и с фреймворками, а не то что раз ресурсов хватает можно лепить
Вам это кому? И в каких ситуациях?

P.S. судя по тому, что вы предложили делать объектную модель контроллера и тому, что считаете, что у вас ровно один объект (даже без уточнения того, о какой задаче идет речь), об ООП и ООД вы имеете довольно смутное представление.
+2
я привел пример
хотя вы несомненно умнее других, напишите статью
0
я привел пример
Неудачный, причем.
хотя вы несомненно умнее других
Существует много людей, которые умнее меня. Себе в команду, например, я именно таких и набираю.
напишите статью
Зачем? Вы не знаете где в Херсоне находятся книжные магазины?
+1
я привел пример
Осталось понять, пример чего ты привел. Пока что, похоже — собственной компетентности.
+1
возможно, о своей компетентности не мне решать. Пример некорректного использования ооп
0
Смотря что понимать под некорректным. Ты, предположительно, приводил пример «из пушки по воробьям», а получился пример «как не надо проектировать объекты».
+1
скорее так как это чаще всего происходит
0
Это противоречит моим наблюдениям.
0
как насчет arduino?
0
Где в ардуино «объектная модель MCU со всеми регистрами»? Вообще, Wiring-фреймворк достаточно неплохо спроектирован и реализован.
0
а как тот же класс serial, хотя в подробности вдаватся не могу, особо не трогал
0
А что с ним не так? Вполне неплохая обертка на UART.
0
Хотя при ближайшем рассмотрении иерархия и архитектура выглядят несколько странными. Я бы спроектировал несколько иначе.
0
Как раз serial пример того, как не надо использовать плюсы в микроконтроллерах.
0
Гм, а что там так уж плохо?
0
По хорошему там совершенно не нужно наследование с виртуальными методами.
0
Да, про виртуальные методы я как-то забыл. Хотя ограниченное их применение возможно и полезно.
0
Причем сильно ограниченно. Только если есть много флеша и памяти, а задача реально этого требует (гуй, например).
0
Ардуина, как раз, пример не очень удачного (скорее даже неудачного) применения плюсов. Но это больше касается реализации, а не задумки.
0
Почему?
0
Там выше я написал. Там нафиг не надо наследование.
0
А как обеспечить совместимость HardwareSerial, SoftwareSerial и USBSerial (нинай есть ли такой, впрочем — предположим, это UART через CDC)?
0
Использовать запрос интерфейса, например.
В Delphi тот же VCL переработали в KOL без виртуальных методов.
0
Использовать запрос интерфейса, например.
Что есть интерфейс? В моих понятиях это класс, содержащий исключительно виртуальные функции.
В Delphi тот же VCL переработали в KOL без виртуальных методов.
Не совсем без виртуальных. Там заменили встроенные виртуальные методы самопальными. Выигрыш достигается тем, что стало проще контролировать, какие виртуальные методы будут слинкованы в итоговый ехе, а какие — нет.
Кроме того, есть библиотека AvL. Она дает размер ехе сравнимый с KOL, но при этом сделана на новой модели ООП и виртуальных функциях.
Основной выигрыш в обоих библиотеках, на самом деле, достигается отказом от лоадера форм и части функциональности VCL (так, более убогая AvL выдает всего 80кб ехе даже если вернуть туда лоадер форм, т.е. все классы контролов будут полностью скомпилированы и слинкованы в ехе — чисто за счет отсутствия мяса на контролах).
0
Это С++ так реализуются интерфейсы. В целом это и имеется ввиду. Получаем типа такого:
ISerial A::GetSerialInterface() {
    ISerial iS;
    iS.SetObject(this);
    iS.SetReader(&Read);
    iS.SetWriter(&Write);
    return iS;
};
Вообще в плюсах есть более правильные для этого средства. Это код, что бы отразить суть. Если код исмпользуется — он есть, если не используется — нафиг все удаляем.
Так если обращение только к HardwareSerial, то вызов напрямую и всё это не компилится. А вот если потребуется передать в нутра, для вывода из вложенных функций, то компилим и линкуем.
-1
Ну, по сути это та же VMT, только руками. Не знаю как в C++, а в Delphi виртуальные методы вполне успешно выпиливаются — если не используется объект класса TSomeClass, то и все методы класса, включая виртуальные выпиливаются.
Не работает это только с VCL, потому как там все компоненты используются в procedure Register, которая линкуется всегда, если модуль включен в проект. Нужно это для DFM-движка.
0
если не используется объект класса TSomeClass, то и все методы класса, включая виртуальные выпиливаются.
Ну и если ни у одного экземпляра TStream или его наследников не вызывать метод Write — то он тоже выпилится во всем дереве, хоть и виртуальный.
0
Но, не выпилится ни один, если хотя бы у одного класса наследника используется.
В прочем сведения могут устареть, и сейчас оптимизаторы нормально рубят это.
0
Если определенный наследник не создается — то и его реализации виртуальных методов выпиливаются. Т.е. если есть десяток наследников Serial, но создается только HardwareSerial — остальные 9 выпиливаются вместе с виртуальными функциями.
Впрочем, это опять же про дельфи, а не С++… Что-что, а смартлинк в дельфи всегда работал отлично.
0
Виртуальные методы предков остаются и не выпиливаются. Я про это.
0
Это да. С другой стороны, можно оптимизировать, имея только один настоящий метод в цепочке наследников, а остальные — абстрактные. Скажем, для разновидностей Serial виртуальными сделать только read, write и avail, которые будут реализованы только в листьях.
0
Поскольку в рантайме это не меняется, то можно воспользоваться чем-то вроде «duck typing на коленке»:
1. Пишем три класса с одинаковым интерфейсом (в смысле сигнатур методов, то есть без наследования)
2. Делаем инклуд в котором инклуд конкретной реализации и тайпдеф конкретного типа в Serial.
3. Всем, кому нужно пользовать Serial раздаем инклуд сделанный в #2

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

Второй вариант — пишем класс Serial, который (#ifdef-ами) наследуем от конкретного Hardware/USB/SoftwareSerial.

Первый вариант проще расширять, у второго меньше дублирование кода.
0
Но ведь в принципе хардверный и софтверный уарты могут использоваться одновременно, а на кортексах класс Print может реализовываться не только уартом, но и отладочным выводом через JTAG.
Кстати, насколько велики накладные расходы на виртуальные методы в С++?
0
Косвенный вызов, как ни крути. Даже при непосредственном обращении к методу объекта тут же созданного (снова, возможно устарели данные). Создание полной таблицы, даже если методы не используются.
0
глобальная VMT + указатель на нее в каждом экземпляре + косвенный вызов по индексу в таблице.
+1
Ну, это, в принципе, не так много — у предложенного angel5a интерфейса расходы аналогичны (только у каждого объекта личная копия VMT). Вот если оно примется компилировать и линковать все возможные реализации — тут да, будет писец.
P.S. А мне казалось VMT только дельфовый термин, по крайней мере плюсовики его не понимали.
0
Это такие плюсовики, значит :)
+1
Ну, они это зовут vtable. Где кроме Delphi применяется термин VMT (Virtual Method Table) — не знаю, но не в плюсах.
0
Борланд в свое время так называл эту таблицу и в своих плюсовых IDE/компиляторах.
0
Ну то состряпано на коленке. Можно использовать глобальные структуры указателей на функции, и возвращать их. Тогда расходы при использовании такие-же как у виртуальных методов (или не, чуть больше). Но нулевой оверхед, если абстрактность не требуется (линкер выкинет неиспользуемые таблицы и функции).
0
Если смартлинкер достаточно умный — практически такой же результат и на нормальных объектах получить можно.
0
class A
{
public:
	virtual void foo(void) = 0;
};

class B : public A
{
public:
	int b;
	void foo (void) {b = 1;};
};

class AA
{
public:
	void foo(void) {};
};

class BB : public AA
{
public:
	int b;
	void foo (void) {b = 1;};
};

-1
std::cout << "szA = " << sizeof(A) << std::endl;
	std::cout << "szB = " << sizeof(B) << std::endl;
	std::cout << "szAA = " << sizeof(AA) << std::endl;
	std::cout << "szBB = " << sizeof(BB) << std::endl;
szA = 4
szB = 8
szAA = 1
szBB = 8
В прочем пример не честный :)
-1
От такого «исследования» толку мало. Ну стало оно на 4 байта (указатель на vtable) больше — это мелочь) Но вопрос же этим не исчерпывается.
0
Ну размеры таблиц я хз как получить. Можно будет поэксперементировать. Ведь стало больше на 4 байта указатель на таблицу, и 4*N байт самой таблицы. Для обычных же функций указатели на методы не хранятся в классе.
И остаётся вопрос про inline'инг функций — не надо стек гонять, и ядро по переходам.
0
class AA, class BB: public AA

грубейшая ошибка — переопределение в наследнике не виртуальной функции.
Ни о каких vtable в данном случае речи не идет. просто есть не полное понимание описания механизма наследования в Спп. Подчеркиваю — именно «описания».
0
Там это просто для однородности. Ничего страшного в том в данном случае нет. Хотя полиморфизм для такой функции работать не будет, но и к другим ошибкам не приведет.
0
Ну «не приведёт» это очень оптимистично. В большом проекте это ещё как приведёт к ошибкам.
0
Это будут последствия отсутствия полиморфизма для этих функций. Других базовых ошибок не вызовет.
0
Одновременное использование невозможно. Допустим функция:
bool CopySerial(Serial* in, Serial* out);
Типа USB-UART конвертор делать. Поэтому вышенаписанный костыль от меня.
0
Ардуина, как раз, пример не очень удачного (скорее даже неудачного) применения плюсов. Но это больше касается реализации, а не задумки.
Реализации конкретных библиотек в Arduino? Но тут было столько мата в адрес библиотек STM32 и прочих, библиотеки Leaf Labs Maple тоже не правильно сделаны с точки зрения идеологии ARM — без CMSIS.

Идеальное ПО(IDE) для МК для меня лично представляется в виде иерархии следующих оберток и слоев:

1. Язык укрупненных блок схем типа ДРАКОН или Algorithm Builder для AVR. Плюс UML конструктор.

2. wiring + библиотеки

3. C/C++ + HAL

4. ASM
0
Да, что именно я считаю неправильным я написал там выше.
Но тут было столько мата в адрес библиотек STM32 и прочих, библиотеки Leaf Labs Maple тоже не правильно сделаны с точки зрения идеологии ARM — без CMSIS.
Это, как раз пофиг. На мой вкус, конечно.
1. Язык укрупненных блок схем типа ДРАКОН или Algorithm Builder для AVR. Плюс UML конструктор.
Разве что последнее. Впрочем, его польза тоже сомнительна.
2. wiring + библиотеки
3. C/C++ + HAL
С обеими этими задачами гораздо лучше справится библиотека шаблонов для С++. По читабельности это будет лучше вайринга (с его кашей из процедурных и ОО стилей), а по эффективности не хуже (а часто и лучше) чем С/С++ + HAL.
Нечто движущееся в этом направлении (хотя, как по мне, там еще пилить и пилить) можно посмотреть тут. Да, SPL для трех семейств эта штука уже заменяет.
0
Да, SPL для трех семейств эта штука уже заменяет.
Для каких? И в каких частях/направлениях ее еще пилить и пилить?
0
Для конфигурирования железа, описания управляющих регистров и так далее. Я бегло ее просмотрел, но на вскидку не нашел там «рабочих» методов для периферии типа «прочитать/записать значение» или «установить ногу в такое-то состояние».
0
*Для каких семейств? Только STM32?
Вообще, меня интересует HAL чуть шире. Скажем, поддерживающий несколько вариантов ARM'а (STM, LPC, etc). Или STM32 и STM8. Или даже шире. Пока из таких знаю только Wiring и CooCox.
0
STM32 F1/F2/F4. Думаю, при желании можно и под STM8 допилиьть.

P.S. увы, все то, что я видел, мне по тем или иным причинам не нравится. но эта либа шаг в правильном направлении, хотя выбранный вариант я и считаю излишне verbose.
0
А под STM8 есть C++?
0
Не в курсе. Я исходил из схожести периферии.
0
С обеими этими задачами гораздо лучше справится библиотека шаблонов для С++

Нечто движущееся в этом направлении можно посмотреть тут

Плохо, что только для пресловутого stm32 только заточено. Очередной велосипед, узкозаточенная цельнолитая болванка от очередного гуру(так как ОН это себе видит)? Буду ждать ПО под любой Cortex-Mx без выворачивания мозгов(C/C++) и time_waste_for_future тупления в даташиты неких чипов(практики прошлого века). Может ПО для Arduino допилят/переродят в ПО под любой ARM Cortex? B)
0
В кокосе вроде есть общая HAL под все поддерживаемые камни.
0
Плохо, что только для пресловутого stm32 только заточено.
Плохо. Но год назад и этого не было.
Очередной велосипед, узкозаточенная цельнолитая болванка от очередного гуру(так как ОН это себе видит)?
А охаивать обязательно?
Буду ждать ПО под любой Cortex-Mx без выворачивания мозгов(C/C++)
Выворачивание мозгов понадобится только если вы это будете сами писать. С использованием там все гораздо веселее.
Может ПО для Arduino допилят/переродят в ПО под любой ARM Cortex? B)
Судя по скорости, с которой они рожали Due, думаю, ждать придется долго.
0
Я почти не смотрел, но вроде для шаблонов код довольно понятный. Возможно потому, что вся чорная магия сныкана в бусте.
0
Хмм. Я что-то не заметил там буста. Где он инклудится не подскажешь?
0
Упс, сорри, это был не буст. Показалось.
0
Но вообще забавный подход — вам (судя по всему) нужно, но вы будете ждать. Если вам действительно нужно, то что мешает написать?
+2
Но вообще забавный подход — вам (судя по всему) нужно, но вы будете ждать. Если вам действительно нужно, то что мешает написать?

Нюхом чую, что-то должно кардинально перевернутся в пр-ве ПО для МК. Я многое понимаю, как это должно выглядеть, понимают и многие другие это — что-то должно произойти.

Хорошо, когда они(МК) были «маленькими» — и все было видно, программки короткие и поэтому ясные, перевариваемые, код для управления задачами крохотный и т.п.

Но сейчас новое кол-во(больше памяти, сверхобильная архитектура, float point и т.п.) переросло в новое кач-во, трудноперевариваемое для мозга. Даже с учетом того, что asm канул полностью в лету, но C/C++ явно не справляются с задачей здесь. Ясно же, что программа на C/C++ на порядок/два легче читается, если написана для Linux и stdio, например. Но когда это работа с переферией МК — это просто ужас какой-то, ничем не лучше, чем на asm.

P.S. Писать самому? У меня не хватит знаний просто :) Хотя бы по теории компилирования, формальных языков и т.п. Пока даже не смог разобратся полностью, как они этот «дешевый трюк» по преобразованию кода wiring в C++ проделывают через препроцессор.
0
Пока даже не смог разобратся полностью, как они этот «дешевый трюк» по преобразованию кода wiring в C++ проделывают через препроцессор.
А где ты там трюк нашел? То, что wiring язык — ЛПП. Обычный фреймворк. Язык там С++ как есть.
Типичный сорец для вайринга портируется на С++ заменой digitalRead/digitalWrite на макросы Волкова, замену Serial своей реализацией и добавлением в конец функции
int main(){
  setup();
  while (1) loop;
  return 0;
}
0
Упс, loop(). Вечно забываю эти скобочки. Ну и еще #include <Arduino.h> нужно выпилить. Хотя его в скетчах и не водится, скорее всего «IDE» автоматом вставляет.
0
Ну в общем смысле мне это все понятно, но… мелочи и нюансы реализации… Кода там не мало, тем не менее.

Почему обертки это не языки, там не всегда все делается тупо только через препроцессор подстановкой. Надо вкуривать хорошо ТЕМУ, что бы язык обертки был синтаксически надежен и не словить глюков или дыр.
0
Ну уж кода там немного. Полностью изучить можно за день.
Второй абзац просто не понял.
0
Кому-то не много, а мне показалось многовато, когда смотрел года 3 назад.

Про обертки. Ну вот есть такая обертка поверх JS называется Cofee Script(syntax sugar). Так и не вкурил, как они смогли додуматся до этого и как это полностью работает. Сейчас M$ выпустил для opensource c открытым кодом TypeScript — тоже обертка поверх JS, только очень мощная. Тоже мало понятно мне пока, как это работает.
0
Wiring к ним не относится.
0
Что это значит? Если в код wiring вписать «хитрый» код на C++, который отсутствует в синтаксисе wiring — что будет? Действует ли там только препроцессор или анализируется синтаксис кода?
0
Wiring — просто библиотечка для С++. Никакого «синтаксиса» wiring нет — это не язык.
0
Ну как же, а это — ключевые слова, Control Structures и т.п.
0
*facepalm* Ты что, не видишь, что это С++? Хоть бы поковырял уже, чтоли. Или поверил тому, кто уже ковырял — это чистейший С++, а Wiring — не более чем HAL-библиотека. Arduino — распиаренная сборка из AVR-GCC, Wiring, Processing IDE, AVRDUDE+AVRBOOT.
0
Arduino — распиаренная сборка из AVR-GCC, Wiring, Processing IDE, AVRDUDE+AVRBOOT.

Угу. И правильно сделали все, чем городить очередные велосипеды хорошо прикинули мозгами и собрали максимально из готового opensource. И сделали вещь, хотя если идти дальше — надо было прикручивать Eclipse, а не простенький редактор Processing IDE, но тут дело вкуса — минимализм тоже хорошо.

Но речь не о том, а об обертках таких поверх готовых языков. Вот мне, допустим, надо поверх JS сделать обертку похожую, например, для работы с некими графич.примитивами, естественно будет библиотека/объектная структура для них. Текст на этом псевдо-языке можно набирать в текст.окне браузера и тутже выполнять.

Как мне тогда это сделать c более-менее примитивным скриптом препроцессора, что бы ничего лишнего, кроме этих объектов и функций(из библиотеки) не было доступно юзеру, но весь функционал(объявл.переменных, структурн.конструкции и т.д.) JS работал. Порезать eval надо, что еще? Как обеспечить безопасность такого JS скрипта, даже в голову ничего не приходит?
0
Но речь не о том, а об обертках таких поверх готовых языков.
Вайринг — библиотека, а не обертка.
Если же говорить о таких вещах, как TypeScript, то это, AFAIK, полноценные компиляторы. Соответственно и делаются как компиляторы. Но с такими вопросами разумнее на форум программистов обращаться.
0
Как мне тогда это сделать c более-менее примитивным скриптом препроцессора, что бы ничего лишнего, кроме этих объектов и функций(из библиотеки) не было доступно юзеру, но весь функционал(объявл.переменных, структурн.конструкции и т.д.) JS работал. Порезать eval надо, что еще? Как обеспечить безопасность такого JS скрипта, даже в голову ничего не приходит?
То, что вы хотите, называется DSL (domain-specific language). То есть язык для конкретной предметной области. JS для этого можно применить, но он, по большому счету, не для этого. Есть языки, которые специально заточены под создание DSL, из того, с чем приходилось сталкиваться (но не пользоваться) сраза вспоминается Groovy.

P.S. по поводу ардуиновской IDE: поначалу я тоже плевался, потом по трезвому размышлению понял, что решение было правильным. пользоваться им я так и не стал, но мотивацию, которая стояла за этим решением, прекрасно понимаю и считаю выбор правильным. им бы еще кнопочку «експорт проекта в еклипс» (что не так уж сложно сделать, на самом деле) и ей бы вообще цены не было в смысле приобщения новичков, снижения до минимума порога вхождения и последующей простоты перехода на более взрослые инструменты.
0
JS это вообще отдельная тема. Там даже объектная модель существенно отличается, плюс местами все функциональщиной сдобрено. Но к теме вайринга это не имеет никакого отношения.
0
Нюхом чую, что-то должно кардинально перевернутся в пр-ве ПО для МК. Я многое понимаю, как это должно выглядеть, понимают и многие другие это — что-то должно произойти.
Угу. Близится ужас lifelover-a — жаба в каждом микроконтроллере :) Если, конечно, MS не опередит ее со своим .NetMS. Во всяком случае платы на F4 под него уже есть и давно (FEZ Cerberus, например).
Даже с учетом того, что asm канул полностью в лету, но C/C++ явно не справляются с задачей здесь.
Он справляется, но для эффективного применения нужны две вещи — профи способные переступить через предрассудки и знающие С++ (а это куда более сложный инструмент, чем просто С) и инструментарий в виде библиотек шаблонов.

P.S. Писать самому? У меня не хватит знаний просто :) Хотя бы по теории компилирования, формальных языков и т.п. Пока даже не смог разобратся полностью, как они этот «дешевый трюк» по преобразованию кода wiring в C++ проделывают через препроцессор.
Да, ладно, нету там никакого трюка. Лепят стандартный main() с заголовком и все.
0
Угу. Близится ужас lifelover-a — жаба в каждом микроконтроллере… для эффективного применения нужны две вещи — профи способные переступить через предрассудки и знающие С++
Каждый кулик свое болото хвалит(java), каждая шука(рак) в свой омут тянет(проф програм-е на C++). Так, да? ;)
Вам это хорошо, а вот мне это не нравится и еще многим. Java я не хочу учить — ну вот не хочу, ну не нравится он мне — тупить долго надо. «Проф» программирование на C++ я тоже не понимаю что такое, да и не нравится он мне тоже — слишком сложен, да еще какие-то техники «правильного» программирования, вот шаблоны проектирования я еще понимаю, но реализация их у всех разная, а мне надо как из кубиков из них собирать, но не вдаватся в подробности и мелочи и не боятся что их кто разрушит, полазив в их внутренностях(что бы это было закрыто самим языком/фремворком/IDE). Причем, возможно, я говорю не от самого себя лично, могут же быть задачи научить программированию кого-то с минимумом знаний, например, школьников, не проф.программистов и т.п. Учить их java и C++ или чему-то типа wiring?
0
Каждый кулик свое болото хвалит(java), каждая шука(рак) в свой омут тянет(проф програм-е на C++). Так, да? ;)
поверь, evsi знает толк и с жабе и в плюсах. и в промышленной разработке и в эмбедде для себя.
0
да и не нравится он мне тоже
дальше можно было уже и не продолжать.
+1
поверь, evsi знает толк и с жабе и в плюсах. и в промышленной разработке и в эмбедде для себя.
Я знаю, но я то веду речь не о том, не каждый может быть таким, как он, я вещаю об упрощении — я поклонник примитивизма.
0
я поклонник примитивизма.
товарищ, у меня для вас ужасные. нет, даже просто кошмарные новости. с примитивизмом скоро и в дворники не возьмут. «такова селяви»
0
а вот в помощники дворника возьмут. за мрот.
0
Ну да, ну да. Так я Вам и поверил. Оглянитесь вокруг — кругом каждый второй недоучился, переучилися, работает не там на что учился. Вполне себе припеваючи живут, а многие даже очень. Примитивизм — двигатель современного прогресса.
0
не, с вашим прогрессом мне не по пути.
0
Это еще началось во второй половине XX века. Бывший школьник закодировал BASIC в двоичных кодах для i8080, поднабить руку, работая на main_frain имел возможности — папа видный адвокат, мама работала в IBM. Еще он прочитал статью в научно-популярном журнале некоего Мура из руководства корпорации Intel про некий закон. Ничему и нигде потом он в итоге не учился, но заколотил n-ое кол-во млрд. $, сейчас на пенсии.

Тролль, вообще далекий от математики/электроники/программирования, связался с неким хакером электронщиком и съездил в исследоват.центр Xerox. Он курил марихуану и кушал ЛСД — хипповое поколение, нужно было получать просветления и вести паству к великому компьютерному будущему. Заработал кучу млрд. $, но посадил поджелудочную и печень (видимо ЛСД) и помер недавно.

Группы поцанов не имеющих никакого музыкального образования, раньше их бы не допустили и до таперов в самом дешевом синематографе, бацают на эл.гитарах и зарабатывают 10-ки млн.долларов. Некоторые из них вообще натуральная шпана из черных районов США.

И т.д. и т.п.
0
Ваши примеры говорят об обратном — способный человек вполне может чего-то достичь даже при полном отсуствии формального образования. Это, впрочем, началось отнюдь не во второй половине 20-го века.
+1
Я думаю вы даже где-то недооцениваете количество (не половина, а 2/3 или даже 3/4 более реалистичная оценка, на мой взгляд). Но в это же самое время оставшаяся часть продолжает активно развивать науку, технику, технологии и так далее. Попутно создавая массу товаров и удобств для упрощения жизни большинству (и таким образом еще больше усугубляя проблему). Увы, как с этим бороться я не представляю. Ну а чем это может закончиться фантасты уже расписали.
0
Ну а чем это может закончиться фантасты уже расписали.
Например?
0
Начиная, видимо, с Уэлса (в «Машине Времени», если память не изменяет).
0
А еще?
0
Видел еще минимум пару произведений на эту тему, но ни названий ни авторов не помню, увы :(
0
Каждый кулик свое болото хвалит(java), каждая шука(рак) в свой омут тянет(проф програм-е на C++). Так, да? ;)
Жаба не мое болото, хотя я и пишу на ней. И уж чего-чего, но ее достоинства и недостатки знаю достаточно хорошо, что бы не считать жабу оптимальным выбором для эмбеда (даже не смотря на то, что для нее вот уже больше 10 лет существует так называемая RTSJ — Real Time Specification for Java). Да и на плюсах я пописал достаточно, что бы не менее хорошо представлять, насколько сложный (хотя, безусловно, мощный) это инструмент, к тому же изрядно испорченный попыткой превратить его в инструмент для написания прикладного софта. Просто я исхожу из реалий — другого подходящего инструмента имеющего поддержку в виде инструментария и количества обученных специалистов пока нет. Есть, правда, D, но он далек от массового распространения. Есть еще goo, активно развиваемый гуглем, но он пока совсем зеленый.
По поводу «своего омута»: с развитием техники усложняются и инструменты. Никого ведь не удивляет, что для пайки схем теперь нужна паяльная станция (желательно с феном, да и столик с подогревом не помешает), хотя раньше бОльшую часть всего паяли совковым 40-ватником. Ровно та же ситуация с МК. Они усложняются (равно как и задачи под них), а значит усложняются и инструменты, в том числе компиляторы. Вытеснение асма из основного инструмента в очень узкую нишу произошло у меня (и думаю у вас) на глазах. Даже lifelover хвалит не асм, а «сишечку». Ровно то же произойдет и с сишечкой и другим инструментарием. В силу особенностей эмбеда это происходит с заметным опозданием, но это происходит и это объективная реальность данная нам в ощущениях. Ну и, естественно, более сложный инструмент требует навыков использования и сложнее в освоении. В ответ мы получаем возможность решать более сложные задачи.

По поводу жабы: как язык жаба намного проще С++ и даже С. Не смотря на внешнюю похожесть. Сложность в жабе составляет окружение (в частности библиотеки и фреймворки), но для эмбеда это не сушественно (думаю, в силу специфики эмбед будет мало пересекаться с прикладным программированием по либам и фреймворкам).

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

P.S. wiring == C++
0
судя по тому, что вы предложили делать объектную модель контроллера и тому, что считаете, что у вас ровно один объект (даже без уточнения того, о какой задаче идет речь), об ООП и ООД вы имеете довольно смутное представление.

Просто очень интересно узнать каковы задачи ООП для МК (сам не гуру в ООП и имею о нем довольно похабноепопулярное представление).

P.S. У ARM есть стандарт на SVD файл(появился в CMSIS 3.0) для описания периферии/HAL конкретного МК. Файл этот в формате XML, т.е. подробное объектное описание такого объекта, как МК. Где его будут юзать в будущем: в ПО для написанисания программ для МК, т.е. IDE или в самом ПО МК — это уже второй вопрос.

P.S. Для МК STM32 пока вроде не выложены файлы SVD, но для LPC они уже давно есть.
0
Просто очень интересно узнать каковы задачи ООП для МК (сам не гуру в ООП и имею о нем довольно похабноепопулярное представление).
«Задачи ООП»? Что имеется в виду?
0
«Задачи ООП»? Что имеется в виду?
Ну в чем они тогда? Если не представлять переферию МК(или ее какую-то часть) как сложный объект, как тогда программировать на ООП, т.е. без самих объектов?
0
Объекты могут быть не только для доступа к железу. Есть еще объекты доменной модели (то есть конкретной решаемой задачи). Скажем, печка для пайки SMD имеет профили нагрева, которые (один из вариантов) содержат информацию о количестве этапов, температуре и длительности каждого этапа, возможно дополнительные данные (скажем, этап фиксированный по температуре и длительности или этап заканчивающийся при достижении заданной температуры), текущее положение в профиле, методы типа сбросить, шаг, получить целевую температуру, проверить окончание и так далее.
0
вот скажите, для примера, что будет вернее? Создать обьектную модель mcu со всеми регистрами итд, или просто обратится по адресу?
Без контекста задачи вопрос некорректен.
Опять же, «объектная модель МК со всеми регистрами и т.д.» больше похоже на начало проектирования симулятора МК, а не программы под него.
0
побанить бы вас всех к еб.м.
0
побанить бы вас всех к еб.м.

Ну, побанить можно. Но что от этого изменится? Agile методология станет менее эффективной? Или неоправданные затраты на преждевременную оптимизацию станут более эффективными?
+1
я об эффективности срача.
А по теме, я уже вроде вкинул. Ничего не изменится, к сожалению лень/незнание/еще-что нибудь обходится дешевле чем планка ОЗУ, и значительно дороже оптимизации(исправления ошибок, узких мест, утечек и всего прочего) Так и живем
0
Ничего не изменится, к сожалению лень/незнание/еще-что нибудь обходится дешевле чем планка ОЗУ, и значительно дороже оптимизации(исправления ошибок, узких мест, утечек и всего прочего)
«лень/незнание/еще что-нибудь» вот там выше livelover демонстрирует. Гораздо проще поливать говном современный софт, чем разбираться в причинах.

P.S. оптимизация делается практически в каждом продукте, во всяком случае так было на всех без исключения моих проектах. равно как и с утечками/узкими местами обязательно борются, если этого не делать вообще никакой памяти не хватит.
+1
я не говорю об чьих-то именно продуктах. Потому что как-только перейдем на личности — тут начнется содомия еще та.
Дело в другом что количество кода в любом случае увеличивается, а качество падает. Расплата идет через аппаратные требования. Только для кого-то нормально сделать из своего компа пекарню, а кому-то (как мне) это очень не нравится
0
Дело в другом что количество кода в любом случае увеличивается, а качество падает.
Вы не поверите, но качество растет и сильно. Если бы при том же уровне ошибок, что был в софте 10-15 лет назад вы попробовали запустит современный софт, то он бы даже не стартовал.
Только для кого-то нормально сделать из своего компа пекарню, а кому-то (как мне) это очень не нравится
Ничего не мешает вам пользоваться компом так как в былые времена, запуская ровно одну программу и выкосив нафиг все удобства.
+2
Вы не поверите, но качество растет и сильно.
И правильно не поверим.
0
И правильно не поверим.
Да, я в курсе про вашу альтернативную реальность.
+1
Только для кого-то нормально сделать из своего компа пекарню, а кому-то (как мне) это очень не нравится
Так в чем проблема? Почему бы не откатиться на старый проц и старый софт?
Хотя пекарней оно от этого быть не перестанет, разумеется. Atom уделает старый проц и по производительности, и по экономичности. Примерно так же дела обстоят и в вилке старый софт vs новый софт.
+1
к сожалению лень/незнание/еще-что нибудь обходится дешевле чем планка ОЗУ, и значительно дороже оптимизации(исправления ошибок, узких мест, утечек и всего прочего)
Раз уж подняли вопрос оптимизации, это предиловие к статье, которая называется "Оптимизация: ваш злейший враг"
0
Еще один любитель не исправлять своих ошибок?
0
вы про предиСловие? ну проморгал. бывает.
0
я не о том, граммар нази во мне умер с первой написаной буквой. Я о том что оптимизация == исправления ошибок (имхо)
0
Я о том что оптимизация == исправления ошибок (имхо)
Нет.
+1
утечка памяти это ошибка, ее исправление это оптимизация. Будет ли программа с ошибкой работать — да.
0
Нет, ее исправление — это багфикс. Оптимизация — это когда оно было без ошибок и стало без ошибок, но быстрее.
+1
Утечка памяти это ошибка, а ее исправление это именно исправление ошибки. И да, есть немало ошибок, с которыми программы вполне работоспособны. Утечка, кстати, отнюдь не сама безобидная из них.
0
Зато самая заметная и сравнительно легко ловится.
0
автора оригинальной статьи в этом сложно заподозрить.
0
А кто автор? С полпинка не нашел указания.
0
мнда. там ведь прям под заголовком все есть:
Перевод с англ.: (C) Dale, 14.12.2010 — 17.12.2010.
Переведено с любезного разрешения автора.
Оригинал статьи: Optimization: Your Worst Enemy (Translated by permission).
0
Я было подумал, что Dale — переводчик. К тому же, я даже не слышал об этом авторе.
0
а это и есть переводчик.
ответы на вопрос по линку на оригинал статьи.
0
Там тоже ни одного известного мне имени. Так кто автор-то и чем известен?
0
ну блин, погугли сам. тем более линков в статье достаточно.
0
Ну блин, если ты говоришь
автора оригинальной статьи в этом сложно заподозрить.
значит знаешь, кто это и чем славен. Ответить на вопрос было бы быстрее, чем посылать поочередно в статью, оригинал и гугл :)
0
раз и резюме. достаточно?
0
Вот так бы сразу.
P.S. Фамилия у него, не сразу и поймешь что это фамилия. Круче только у American McGee.
0
развел все таки на гуглеж за тебя. ;)
хотя ответить можно в аналогичном ключе: чем добиваться «кто это», забил фио, и взял первые два результата. )))
0
забил фио
Я его не нашел :-[
0
кого? фио? дык, прям под статьей.
ладно, проехали.
0
Оптимизация: ваш злейший враг
Ещё бы. Если написать хорошо и оптимально, можно закрывать лавочку. А быдлокодеру для жизни нужно непрерывно выкатывать обновления.
-1
Если написать хорошо и оптимально
Интересно, вы в состоянии сформулировать эти критерии? Нет, не на примере конкретных программ, а простым человеческим языком.
+1
Интересно, вы в состоянии сформулировать эти критерии?
Они уже сформулированы давным давно, например, в виде «философии UNIX».
0
Они уже сформулированы давным давно,
Я спрашивал вашу формулировку.
например, в виде «философии UNIX».
Вы давно в пайп гуевые программы собирали?
+2
Вы давно в пайп гуевые программы собирали?
Пайп — это частность. Простое решение, из тех, на которые современные быдлокодеры не способны.
Я спрашивал вашу формулировку.
Хорошая программа — та, которая делает одно своё, чётко определённое дело, делает его качественно, быстро и не делает ничего другого. Как netcat, который однажды написан и больше не нуждается в модификациях.

Для интернета вполне можно разработать набор стандартов. Вот что нужно веб страничкам — отображение элементов разметки, взаимодействие с сервером. Ничего особо сложного. Достаточно разработать простой, лёгкий стандарт, закрепить, написать один хороший и быстрый браузер, тщательно оптимизировать, отладить, протестировать и больше не трогать лет 10-20. К сожалению, даже на выполнение первого пункта быдлокодеры не способны. В стандарте, например, постоянно не будет ничего хватать, поскольку разучились делать универсальные и полноценные инструменты, такие как пайпы. В стандарте будет много неоднозначности и браузеру придётся угадывать, как обработать определённую ситуацию, поскольку разучились делать простые и однозначные инструменты, как Си. Даже XHTML (попытка внести однозначность хотя бы современными унылыми инструментами быдлокодинга) был по сути отвергнут.

Хорошая операционная система должна выглядеть так: В корне диска есть папка system\. В папке system есть файлик kernel.bin — это ядро. Папка system\drivers\ — драйверы. В папке лежат файлы mouse.sys, video.sys и прочие — драйверы устройств. При загрузке система просто загружает все драйверы из папки. Установка драйвера устройства — скопировать файл драйвера в эту папку. Загрузить драйвер командой или перезагрузиться. Удаление — выгрузить драйвер командой и удалить файл. Папка programs\ — программки. В ней есть programs\command\cmd.exe — командный интерпретатор. programs\tools — стандартные утилитки. gui\gui.exe и gui\gui.ini — графический интерфейс и настройки. При установке системы гуя нет. Установка — создать \programs\gui\, скопировать туда gui.exe и добавить этот файл в autoexec.bat. Установка программы соответственно — создаём programs\%appname% и копируем туда файл программы. Если устанавливаем, допустим игру, будет game.exe и папка data\ (в ней будет textures\, models\ и прочее). Установка операционной системы: поместить на диск папку system, установить загрузчик командой boot-install, перезагрузиться.

Хорошая программа — принцип KISS, минимум сущностей, минимально возможный размер и потребление ресурсов, аккуратный интерфейс, универсальность.
0
простые и однозначные инструменты, как Си
опять 25 ))))))))))
+1
опять 25 ))))))))))
Чего 25?
На мой взгляд, это достоинство — код получается недвусмысленный, а это самый важное условие простоты. Можно сравнить пример C++ из «Темной сторона C++» (PDF, стр. 23 и далее). Если в C мы видим

baz = foo->bar(3);

то понимаем, что foo — указатель на структуру с полем bar, в котором указатель на функцию. Неясен только тип baz (он же тип значения bar).

А в C++ baz может быть reference, foo — классом с собственным оператором ->, bar — методом. Виртуальным, в большой иерархии классов. Или переопределенным на каком-то этапе. Перегруженным. Перегруженным с аргументами по умолчанию. Или вообще принимающим не int, а bool или enum, так что компилятор сообразит преобразовать типы. И неизвестно еще, что именно возвращает bar — может быть, нужно будет приводить тип к типу baz. И, кстати, может быть оператор = тоже переопределен. Как и оператор (). А может быть, при конверсии будет даже временный объект создан, с конструкторами и деструкторами. Может быть, тут шаблоны включаются — и не один. Кстати, текущее пространство имен неизвестно.

И автор оригинальной презентации находит еще есть какие-то варианты с typeof и алиасами, но тут уже я пас :)
Понятно, что быдлокодер и Си испортит. Тем не менее, только Си позволяет получить простой и аккуратный текст программки.
-1
код получается недвусмысленный,
Тем не менее, только Си позволяет получить простой и аккуратный текст программки.
))))))))))))))
+1
забудьте уже эту мантру. «сишечка» никогда не быля простой и однозначной.
+2
забудьте уже эту мантру. «сишечка» никогда не быля простой и однозначной.
Всегда была. То, что вы старательно выдумываете искусственные примеры и пишете мозговыносящие однострочники на Си, ни о чём не говорит. Си не препятствует этому, если вы этого хотите.
Тем не менее, + — это всегда оператор сложения, foo() — всегда вызов, -> — всегда обращение к элементу по указателю. Это и есть однозначность. То, что 95% быдлокодеров она не нужна — не удивительно. У них другие задачи — не дать простаивать ресурсам и прочее.
-1
то что я приводил — совсем не «старательно выдуманный однострочник», а вполне реальный пример. хоть и очень упрощенный.
0
foo() — всегда вызов
А теперь скажите мне с заявленной определенностью, что будет в результате выполнения
int a = 1, b = 2, c = 3;
	foo(c = a + b);
	printf("Hello World! c = %d\n", c);
Какой у данного кода всегда однозначный результат?

А теперь скажите, вы увыерены, что ни в одном из хедеров нет
#define foo(x)	/* nothing to call */
#define printf	(void)
-1
Стоит заметить, в оригинале была еще одна строчка: «Все это может быть извращено препроцессором. Но я люблю С, так что об этом забудем».
0
Тем не менее, только Си позволяет получить простой и аккуратный текст программки.
С явно не относится к простым, а уж тем более к однозначным инструментам. К тому же в С, фактически, сосуществуют два языка с разными грамматиками — собственно С и препроцессор. Да и способов сделать одну и ту же вешь зачастую значительно больше одного.
+1
К тому же в С, фактически, сосуществуют два языка с разными грамматиками — собственно С и препроцессор.
Препроцессор — вспомогательный инструмент для решения задач оформления и настройки. Признак хорошо спроектированной вещи — каждая деталька занимается своей и только своей задачей.
0
Признак хорошо спроектированной вещи — когда ей не нужны костыли для объявления констант и поддержки разделения кода на несколько файлов.
P.S.
#define TRUE FALSE //Счастливой отладки, суки
+1
Костыли — это read/write в паскале. И встроенные строки по 255 символов.

Препроцессор — это полноценный и простой инструмент для всех задач оформления, разделения, конфигурации. Сам Си только компилирует исполняемый код.
0
Это не костыли, это часть языка. Костылями оно обросло, когда паскаль стали адаптировать к практическому использованию.
Препроцессор — это полноценный и простой костыль. Хорошо спроектированное решение — это модули из Modula, которые, кстати, растащили по всем языкам, появившимся после нее. Кроме С++.
0
Препроцессор — вспомогательный инструмент для решения задач оформления и настройки.
Это кривейший костыль поставленный там, где авторы языка лажанулись.
Признак хорошо спроектированной вещи — каждая деталька занимается своей и только своей задачей.
Препроцессор решает отнюдь не только эти две задачи.
0
Хорошая операционная система должна выглядеть так: В корне диска есть папка system\...
Извини, но глубина проработки темы напоминает классику.
0
Извини, но глубина проработки темы напоминает классику.
И что. Это просто примеры, а не техническое описание. Принцип KISS, растолкованный для идиотов, которые не способны сами понять что такое «просто».
0
этот принцип хорош или для примитивных «осей» типа доса, которые никому не нужны. или для закрытого в плане апгрейда железа типа яблочных. для обычных компов такое не подойдет.
0
этот принцип хорош или для примитивных «осей» типа доса, которые никому не нужны.
Этот принцип хорош для любых хороших вещей, которые 95% не нужны. Им нужно, чтобы нажал кнопку и выпадал банан, а каким образом и какой ценой — неважно.
0
Это проработка того же уровня, что и «можно грабить корованы» применительно к игре.
BTW можешь реализовать это прямо сейчас, на Linux или NTOSKRNL. Получится немногим сложнее BolgenOS'а, правда весь софт придется писать самому. Но это не страшно, если получится хорошо — со временем появится база юзеров и сторонний софт.
+1
Но это не страшно, если получится хорошо — со временем появится база юзеров и сторонний софт.
Сомневаюсь. Сейчас подход к софту на уровне средневековья.
0
Попробуй. Не выстрелит — так хоть получишь опыт и перестанешь описывать ТЗ операционки в стиле «можно грабить корованы».
+1
Сомневаюсь. Сейчас подход к софту на уровне средневековья.
Согласен, не фонтан. Но то, что предлагаете вы, это вообще Земля до появления животных…
+1
Пайп — это частность.
Без него вся философия не работает.
Для интернета вполне можно разработать набор стандартов.
Судя по всему о существовании RFC вы не в курсе.
Вот что нужно веб страничкам — отображение элементов разметки, взаимодействие с сервером.
HTML5, RFC2616.
Ничего особо сложного.
HTTP один из самых простых протоколов, с минимальным оверхедом. И весьма универсален, к тому же.
Достаточно разработать простой, лёгкий стандарт, закрепить, написать один хороший и быстрый браузер,
Флаг в руки.
К сожалению, даже на выполнение первого пункта быдлокодеры не способны.
Попробуйте не говорить о себе в третем лице.
В стандарте, например, постоянно не будет ничего хватать, поскольку разучились делать универсальные и полноценные инструменты, такие как пайпы.
Вполне научились. Тот же HTTP вполне себе универсален.
В стандарте будет много неоднозначности и браузеру придётся угадывать, как обработать определённую ситуацию
Уже не придется, достаточно ему следовать. Вы, правда, скромно умолчали, что делать с уже существующим контентом и кто его будет переделывать.
Даже XHTML (попытка внести однозначность хотя бы современными унылыми инструментами быдлокодинга) был по сути отвергнут.
Туда ему и дорога.

(бред об операционке поскипан)
Вы выбрали забавный способ продемонстрировать убогость ваших представлений об операционных системах, удобстве и простоте. Попробуйте представить, например, что диск, с которого вы собрались читать драйверы, доступен только после загрузки драйвера. Или что драйвера нужно грузить в определенном порядке. Думаю, вы быстро обнаружите, что ваша операционка загнется не родившись.
Хорошая программа — принцип KISS, минимум сущностей, минимально возможный размер и потребление ресурсов, аккуратный интерфейс, универсальность.
В одном предложении вы умудрились совместить несовместимое. Универсальность зачастую предполагает сложность интерфейса, отнюдь не минимальное потребление ресурсов и размер. Не говоря уже о KISS. На досуге попробуйте не подглядывая в маны и подсказку сходу без ошибок написать сколько-нибудь сложную обработку текстового файла команд на 10-15. Думаю, это будет наглядным уроком о совместимости универсальности с kiss.
+2
Судя по всему о существовании RFC вы не в курсе.
Тоже мне «стандарты». Всё равно каждый день чтонить добавляют. Как один мой друг сказал,
напоминает про Резерфорда и его ученика, в журнале заметка была. Ученик очень гордился, что он много работает, Резерфорд его спрашивает: Что и в выходные? ДА! что и по ночам — да! Когда же вы думаете в таком случае?.. Так вот, когда же развиватели остановятся, чтобы подумать.
Вот эти твои RFC также развивают. Это не стандарты, а раздутые мешки говна. Которые всё больше и больше раздувают.

HTTP один из самых простых протоколов, с минимальным оверхедом. И весьма универсален, к тому же.
И причём тут HTTP? 20 лет назад ещё как-то умели делать. И то умудрились значительно раздуть за прошедшее время.

Попробуйте представить, например, что диск, с которого вы собрались читать драйверы, доступен только после загрузки драйвера.
Тоже самое, что разархивировать архиватор самим собой. И как ты это сделаешь в современных продвинутых ОС?

Или что драйвера нужно грузить в определенном порядке.
Также, как init-скрипты в линухе. Число в начале имени файла — порядок запуска.

Универсальность зачастую предполагает сложность интерфейса
Универсальность = простота. Универсальность — бит, машинное слово, указатель, резистор, проводок.
0
Вот эти твои RFC также развивают. Это не стандарты, а раздутые мешки говна. Которые всё больше и больше раздувают.
Это, как раз, стандарты. А раздутые мешки говна это ваши рассуждения.
И причём тут HTTP?
При том, что все уже давно придумано.
20 лет назад ещё как-то умели делать.
HTTP как протокол остался неизменным.
И то умудрились значительно раздуть за прошедшее время.
Сказали бы прямо — вы не в состоянии понять написанного.
Тоже самое, что разархивировать архиватор самим собой.
Удачи.
И как ты это сделаешь в современных продвинутых ОС?
Пытаться ликвидировать вашу безграмотность бесполезно, вы никого кроме себя не слышите.
Также, как init-скрипты в линухе. Число в начале имени файла — порядок запуска.
Хорошая иллюстрация к вашим разглагольствованиям о продуманности. Чуть-чуть примеров из реальной жизни и дизайн «поплыл».
Универсальность = простота.
У вас баг в высказывании.
Универсальность — бит, машинное слово, указатель, резистор, проводок.
Вы, как и раньше, путаете простоту с примитивностью.
+1
жжошшшшш!!! давай исчо :)
0
лень/незнание/еще-что нибудь
А вот не поскупились бы на планку, не жопили бы каждуй байт, то спеллчеккер бы вам подсветил «что-нибудь».
0
не, я сижу с планшета, а в фф под андроид почему-то нету myspell-а, впрочем это не отменяет моей неграмтности
0
Разве что если взять быдлокодера и требовать писменного отчёта о каждом потраченном байте, обоснования каждой написанной функции

Отличный подход! С таким подходом – любой проект обречен на смерь даже не родившись. Давайте заставим разработчиков писать кучу отчётов и согласовывать каждый потраченный байт.

Вот объясните, плиз, какой смысл заниматься абстрактным бит-хантингом помимо Вашей принципиальной любви к бит-хантингу?

Я не говорю, что ресурсы нужно транжирить просто так, но Вы так относитесь к вопросу, как будто объем ОЗУ – это некий истощаемый на планете ресурс, и если мы его будем использовать не самым рациональным путем, то нашим детям совсем не достанется ОЗУ.
+2
Вот объясните, плиз, какой смысл заниматься абстрактным бит-хантингом
Смысл в том, что потребление ресурсов ПО растёт в геометрической прогрессии. Раньше софт писался специалистами для специалистов. Сейчас — быдлокодерами для быдлоюзеров. Как ллео написал,
Я, будучи воспитан в традициях программирования старой школы, всю жизнь наивно полагал, что усовершенствование любого продукта включает в себя не только добавление новых алгоритмов, но и оптимизацию старых. Поэтому любая версия 2.0 по сравнению с 1.0 должна по идее не только обладать поддержкой новых форматов B,C,D, но занимать меньше места, жрать меньше ресурсов и работать со старыми A, B заметно быстрее за счет оптимизации старого кода. Скажите, я не прав? Нет, я понимаю, что я маньяк, и в 1988, помнится, даже переписал целиком некий свой код ради экономии в 2 (два) байта. А когда в начале 90-хх я писал программки для приборных чипов, там тоже каждый байт и каждый такт у меня был на счету: где надо — экономил именно байты, а где надо — наоборот, циклы разворачивал в линейку, чтоб выполнялось быстрее. Но я ж не требую настолько дотошной оптимизации! Но хоть какой-то мозг включать надо, товарищи разработчики! Написал себе минимальные требования к системе? Так поставь себе комп такой, и отладь на нем! Работает комфортно? Нет? Значит ты мудак и правь код, думай, отчего прежняя версия летала, а нынешняя тормозит.
Вот объясни почему WinNT поначалу хватало 64МБ, а сейчас нужно не меньше 1ГБ? Все те же программы так же запускаются. Плохо, что драйверов для Win2000 под новое железо не найти. Иначе я бы её использовал, поскольку в новых версиях ничего не улучшено, только ухудшено всё, особенно интерфейс, система забита говном, системные требования выросли в десятки раз!

Вот яблоку при всём его гламурности и отвратительности ненаплевать на производительность. Можно ведь нормально делать.
Ну и про скорость интерфейсов. Все производители смартфонов, кроме Apple исходят из двух просто замечательных предположений. Вот они:

a) В записной книжке — сотня-полторы контактов. Если у вас тысяча-полторы, то вполне нормально, что это будет тормозить, чего ж вы хотели?
b) Общая скорость реакции интерфейса должна быть «нормальной». Ну, приемлемой. То есть если немного притормаживает, где четверть, где полсекунды — это ничего. Вот если вообще не тормозит — значит у нас есть запас по ресурсам, можно его как-то использовать, облегчить жизнь программистам или добавить визуальных эффектов.

Так вот, господа, это — БЛЯДСТВО. Телефон НЕ ДОЛЖЕН тормозить. Ничего «нормального» в задержках интерфейса «на грани дискомфорта» — нет. То что телефон не хочется сразу швырнуть об стену еще не значит, что он прошел QA, не так ли?

Я не знаю, как это объяснить людям. Вот в Apple как-то своим объяснили. Может, заставили отлаживать на искусственно урезанных по ресурсам прототипах или еще каким непростым способом. Остальные не просто не могут, но и не хотят.
-1
Смысл в том, что потребление ресурсов ПО растёт в геометрической прогрессии.
Нет.
Раньше софт писался специалистами для специалистов. Сейчас — быдлокодерами для быдлоюзеров.
Для вас да. Но все так же специалистами.
+1
Но все так же специалистами.
Специалисты теперь пишут разве что для космоса. Как ллео написал,
Нет, я понимаю, что я маньяк, и в 1988, помнится, даже переписал целиком некий свой код ради экономии в 2 (два) байта. А когда в начале 90-хх я писал программки для приборных чипов, там тоже каждый байт и каждый такт у меня был на счету: где надо — экономил именно байты, а где надо — наоборот, циклы разворачивал в линейку, чтоб выполнялось быстрее. Но я ж не требую настолько дотошной оптимизации! Но хоть какой-то мозг включать надо, товарищи разработчики!
Ок, может в многих случаях такая оптимизация и не нужна. Однако, не пройдя этот путь, не научившись ценить маленькое и простое (маленькое по сути, а не по виду), быдлокодер никогда не станет специалистом.

Вот, то, что ты напейсал — «Минимальный код для получения требуемой функциональности» — это маленькое по виду. А специалист обязан ценить маленькое по сути.
0
Вот, то, что ты напейсал
И что вы, как обычно, не поняли.
это маленькое по виду.
Нет.
0
Смысл в том, что потребление ресурсов ПО растёт в геометрической прогрессии

Ужас! Только аппаратные ресурсы растут в той же прогрессии. И софт пишется под текущие аппаратные ресурсы. А запросы пользователей растут вообще экспоненциально. Какой смысл игнорировать прогресс в производительности ПК и заниматься бит-хантингом, оптимизировать софт под древние и неактуальные конфигурации?

Например, используя современные средства разработки программист «V» разработал за пару дней удобную «терминалку» для СОМ пота. Пусть данная программа потребляет N мегабайт. Этот же программист «V» мог уйти в глубокую оптимизацию, переписать множество готовых библиотек, углубиться в оптимизацию на уровне машинных инструкций и т. д. В итоге, он бы затратил несколько месяцев, но добился бы потребления памяти N/4 мегабайт. Вопрос, нафиг нужны такие затраты ресурсов (и личного времени) программиста «V», если среднестатистический объем памяти у типичного пользователя «териналки» составляет М гигабайт? Ведь никто, на практике, даже не заметит разницы?

Вот объясни почему WinNT поначалу хватало 64МБ

Потому что функциональность ОС была другой. А во времена раннего DOS — хватало тех самых 640 КБ. А на спектруме – 64 КБ.
+3
Только аппаратные ресурсы растут в той же прогрессии.
Ага, и это повод использовать ресурсы всё менее и менее эффективно путём написания всё более дерьмового говнокода.

Потому что функциональность ОС была другой.
В чём она была другой? Что принципиально изменилось? Нормальная программа спокойно запускается на любой версии ОС.
0
Ага, и это повод использовать ресурсы всё менее и менее эффективно путём написания всё более дерьмового говнокода.

Нет, это повод эффективно использовать существующие ресурсы, эффективно разрабатывать программы, которые соответствуют современным требованиям. Вам никто не запрещает на современном ПК запустить DOS. Работать в данной среде Вам будет тяжело, зато у Вас будет свободно 99.9% памяти (в абсолютном значении, с учетом того что DOS умел использовать верхнюю память только через извраты типа himem.sys). Вот только толку Вам от этих 99.9% процентов свободной памяти?

В чём она была другой?

А почему Вы сейчас не прольетесь WinNT 4.0, если, по-вашему, она ничем не отличается от современных ОС?
+2
Время — тоже ресурс, его тоже надо использовать эффективно. ТОлько об этом вы умалчиваете и абсолютно игнорируете, когда вам в пример приводят.
0
более того. время — невосполнимый ресурс. единственный такой особенный.
+1
Хороший софт и дерьмовый софт. Простой пример. Есть файловый менеджер с командой переименовать файл. Как быдлокодер реализует эту команду? SetFileName(GetUserInput());. А что ещё надо? Работает же. Как это реализует программист. Например, если пользователь введёт *.bin, команда изменит расширение файла на .bin, а имя файла оставит прежним. Более того, если выделено несколько файлов — программа заменить расширение всем файлам, оставив имя прежним. Вот чем отличается дерьмовый софт и хороший. Продумыванием мелочей. Увы, почти весь софт становится всё более дерьмовым, а функциональность — уменьшается. Ресурсов же требуется всё больше в геометрической прогрессии. И
Потому что функциональность ОС была другой. А во времена раннего DOS — хватало тех самых 640 КБ. А на спектруме – 64 КБ.
Может убедить только идиота.
-1
Вот чем отличается дерьмовый софт и хороший. Продумыванием мелочей.
Как правило, если быдлокодер рассказывает, что он переписал программу X с использованием ООП и более высокоуровневого языка, это означает, что он переписал только базовую функциональность, проигнорировав множество важных мелочей. Что программа стала потреблять гораздо больше ресурсов и стала менее стабильна.
0
Простой пример.
Можно ещё найти пример посложнее. Например, команда быдлокодеров написала среду для программирования ПЛК. Среда была «разработана» на C#. Давай всем рассказывать как быстро они это сделали. По факту оказывается, что среда при большом количестве блоков адово тормозит, соединения трассирует уродливо (и руками поправить зачастую невозможно), при выводе на печать — не способна нормально разбивать на листы и даже добавлять номера страниц. Сам вывод на печать совершенно не дружествен принтеру (цветной фон и прочее).
Другая среда написана на Си и времени потрачено в 5 раз больше. Однако все мелочи проработаны.

Идиот видит только то, что «времени потрачено в 5 раз больше». По факту, если на C# написать также хорошо, то времени потребовалось бы в 50 раз больше…
-1
Все разработчики идиоты. Они берут инструмент, который появился на рынке в 5 раз быстрее, разрабатывают своё устройство (роутер на 100Мбит, взамен модема на 56кбит) в 5 раз быстрее, выпускают на рынок, которую берут пользователи и качают фильмы в высоком разрешении, пускай тоже в 5 раз быстрее :)
Не, ну идиоты же разработчики, они же до сих пор могли бы ждать выхода вылизанной до блеска и написанной на чистом Си среды разработки, что бы начать разработку своего устройства. Спешить то не куда, по 56кбитному модему фильмы не покачаешь. Ведь действует прежний стандарт и сервера не поддерживают докачку при обрыве.
Но идеоты же, вместо ожидания они на еженедельно-обновляемой оптимизированной версии быстровыпущенного ПО оптимизируют свою быстровыпущенную разработку, и теперь получают 1Гбит.
Идиоты! Могли бы до сих пор сидеть на 56кбитном модеме и в ус не дуть, потому что сразу-оптимизированное ПО ещё не выпущено, оно ещё мишеться. А там ведь работают умные дядьки, и выпускают один единственный релиз, и тестируют всё своими руками, каждый баг отлавливают.
0
Вот чем отличается дерьмовый софт и хороший. Продумыванием мелочей
Это был весьма удачный пример быдлокодерского поделия для чайников с функциональностью в стиле «жалкое подобие левой руки». Если бы эту часть писал специалист и для специалистов, то там бы был регексп с подстановкой по подвыражениям и преобразованиями. Вот только пользоваться этим вы врядли бы смогли.
+1
причем ТОЛЬКО регэксп. :)))
+2
Это был весьма удачный пример быдлокодерского поделия для чайников с функциональностью в стиле «жалкое подобие левой руки».
Ты хоть когда-нить думаешь, прежде чем говорить? Зачем при любом переименовании файла регулярки?

Вот мне нужно переименовать программку и её инишку, я делаю так:


А регулярки — это уже задача для тяжёлой артиллерии
0
Ты хоть когда-нить думаешь, прежде чем говорить? Зачем при любом переименовании файла регулярки?
Потому, что выдать самый мощный и гибкий инструмент (и только его) — типичный подход «специалиста для специалистов». «Специалист для юзера» делает обычное переименование, иногда чуть круче, как в TC (в эксплорере на самом деле тоже есть мультипереименование, но с другой логикой, а еще для него есть плагин «от прогера для прогеров» с переименовывалкой по регэкспам).
+1
Ты хоть когда-нить думаешь, прежде чем говорить?
Всегда. А вы?
0
Ой, пруф
This application is written by Christian Ghisler in Delphi 2[3] (32-bit version) and Delphi 1 (16-bit version).
Не рассововерный Си! Заклеймить! Заклеймить! Заклеймить! Там строки-костыль, они изначально 255символьные только! Там ООП! Сжечь!!!
0
ну, в тотал я его уже тыкал носом. только как всегда решил не заметить неудобный факт.
и длинные пути тоже полечены.
0
Позвольте угадаю.
Дерьмовый софт, в данной формулеровке, не может быть написан на Си? А хороший софт может быть написан только на Си?
0
В итоге, он бы затратил несколько месяцев, но добился бы потребления памяти N/4 мегабайт.
На самом деле, программист «V» забил бы на проект уже через неделю :)
+1
Смысл в том, что потребление ресурсов ПО растёт в геометрической прогрессии.
ну и бред. будь так, ни я, ни вы, ни Vga уже не могли запускать софт. тем не менее я вполне прилично себя чувствую на C2D+8GB (уже C2Q, но это не имеет значения). практика наглядно демонстрирует, что вы в корне не правы.
0
вы себя не спрашиваои почему у вас 8гб?
+1
я точно знаю почему. и уже не один раз об этом говорил. потому, что мне часто нужны одновременно запущенные альтиум, солид, IDE, а нередко еще и кактус. они все неплохо кушают. а еще лиса с кучкой вкладок, и фоксит ридер с мануалками (про размер рефмана напомнить?). ну всякого по мелочи еще типа почтовика.
впрочем, справедливости ради надо заметить, что вторые 4гига я докупил не так давно. до этого прекрасно на четырех жил.
ну и основная причина — это всего полтинник (даже меньше — 300грн) за бОльшие удобства. предлагаете из принципа экономить на инструменте и скулить «быдлокодеры не умеют писать маленькие быстрые програмки»?
+2
та тут вот в чем проблема, для тебя 300 грн это 'хрень ради которой я бы жопу со стула не поднял', а для кого-то типа меня это 3 дня работы, мб 4-ре.
0
ну, не будем заниматься домыслами.
300грн за более комфортную работу — вполне целесообразное вложение денег в более эффективную работу.
+1
при условии окупаемости, а какая окупаемость в большинстве мультимедия приложений. К примеру мой hp 2730p уже захлебывается на full-hd, что впрочем не удивительно
0
вы вложения в личный комфорт тоже оцениваете с точки зрения окупаемости?
+1
сейчас во мне говорит мое жлобство, но да, я смотрю на всё со стороны окупаемости, иначе это простое выкидывание денег
0
вы и за компом сидите на колченогой табуретке, а сам он на ящике от монитора, например. или все-таки в кресле за столом? ;) о какой окупаемости речь?
+1
О любой окупаемости, если можно воспользоватся разумным минимумом, то пожалуй стоит им пользоватся, а не покупать кресло в брилиантах. это кстати, кода тоже очень касается. А сижу на стуле который старше меня, за столом, который, я думаю, тоже старше меня
0
ну, если проводишь за компом даже стандартный рабочий день (а у подавляющего большинства намного больше), удобное кресло суровая необходимость. иначе просто убьешь спину.
+2
Здесь, кстати, окупаемость прямая. Достаточно прикинуть стоимость лечения спины и кресло за полтора килобакса дорогим уже не кажется.
+1
ну да. я, правда, пока обошелся тем самым «разумным минимумом». просто обычное нормальное кресло. на совсем нормальное пока не получается уговорить зеленую…
0
скорее да, чем нет, но это мой рациональный минимум. Задачу сиденья жопой перед компом мой старый стул выполняет на 100%
0
в 23 на это еще можно забивать. хотя и не рекомендуется. ;)
+1
Ну и прекрасно. Впрочем, не знаю, что у тебя там за стул. Мой старый стул с трудом выполняет задачу собственного стояния.
Алсо, как перестал сидеть на обычном стуле на прежней работе да в институте — перестал похрустывать позвоночником при потягивании. Хз правда, о чем это говорит.
0
если можно воспользоватся разумным минимумом, то пожалуй стоит им пользоватся
Скупой платит дважды. Или даже трижды.

P.S. как правило оптимальный выбор в долгосрочной перспективе это «второй-третий сверху». во всяком случае у меня это наблюдение подтверждается весьма часто.
+2
Тогда медиаконтент вообще не окупается, так что обеспечением условий для кодеков можно не заморачиваться.
0
Если вспомнить, что планка памяти дешевле, чем один диск с тем самым Full HD контентом — затраты теряются в первых трех дисках (при этом весь сериал о 13 сериях выходит на 6-8 дисках).
0
ой! неужели диски еще кто-то покупает? тем более с сериальчиками? ;)
+1
Да, покупают. Не в России, разумеется. Причем как правило это напрямую определяет, продолжат понравившийся тебе (и оборванный на самом интересном месте) сериал или нет.
0
ну, имхо, сериальчики в основном зарабатывают не на продаже дисков, а на рекламе в нем самом при вещании.
0
Не только. Быть ли продолжению часто определяет интерес к дискам. Ессно, я по прежнему про свою область.
0
Хотя да, есть и PreCure, которые по сути являются рекламой сопутствующих товаров (плюс к ним обычно прилагается прямая реклама этих самых товаров, изрядно веселит кстати, в тех редких случаях, когда она не вырезана релизером). Я даже не уверен, выходят ли они на дисках — по сети в основном гуляют TV-рипы, а если и выходят — по 4-6 серий на диск, а не 1-2.
0
тем более с сериальчиками? ;)
Я же анимешник. У нас сериалы — основной контент, фильмы как правило имеют улучшенную картинку, но почиканный сюжет (2 часа экранного времени против 10, причем в сериалах сюжет сквозной сквозь серии — по сути это 10-часовой фильм, показываемый кусочками по полчаса) и идут как дополнение.
0
Я же анимешник.
ааа… да, этот момент я упустил.
0
Вложения в собственный инструментарий и собственное образование — одни из самых выгодных.
+2
а для кого-то типа меня это 3 дня работы, мб 4-ре.
Это вообще деньги? Я на инструмент (осцилл, комп, etc) охотно тратил зарплату за несколько месяцев.
0
и они окупились?
0
То, что я трачу на себя я не рассматриваю с точки зрения окупилось/нет. Только с точки зрения нравится/нет.
Комп окупился, ригол — нет.
0
Комп окупился, ригол — нет.
проблема в том, что эту самую «окупаемость» многие рассматривают исключительно с позиции материальной отдачи. а это ведь даже не основное.
+1
Я об этом же. Понятно, что в плане не-материальной отдачи и то и то полностью окупилось, именно это и показывает для меня критерий доволен/не доволен.
0
Потому, что они доступны, isn't it obvious?
У меня тоже было бы 8 гиг, не будь я настолько привязан к WinXP x32.
0
это все относительно, и как подсказывает история коммунизм не строится. С другой стороны если я нищеброд — это исключительно мои проблемы, а не проблемы программера который собрал это на 8 гигах и сказал что у него все норм.
0
это исключительно мои проблемы
Точно.
Впрочем, стоит заметить, что как правило потребление диктуется задачей. Хоть тресни, а H264 без хранения в памяти нескольких десятков распакованных кадров (каждый по 6 метров уже сегодня, и будет по 20 метров завтра) не распакуешь на современных процессорах. А без H264 картинку в Full HD в разумный размер файла не уложишь. А Full HD — это уже пожелание юзера, т.е. лично твое. По крайней мере сегодня еще есть выбор HD vs SD, и он за юзером.
+1
8 GB. Пиздец. А будет в десктопе 128 GB — и это засрут оптимально используют. Причём тормозить будет ещё хуже, а программы и останутся таким же говном. Быдлокодеров нужно развешивать по фонарям.
-1
угу. ну попробуйте запустить хоть альтиум с солидом на паре гиг. посмотрю на вас.
или возьмите типичного дизигнера. они вообще очень любят запустить фотошоп, короля дров и какую-нить майю/3дмакс одновременно. и при этом во всех открыты далеко не маленькие картинки…
+1
и при этом во всех открыты далеко не маленькие картинки…
Ага, «Долой 12 мегапиксельные 24 битовые картинки! 256 цветов с индексированной палитрой — наше все!».
+1
Ага, «Долой 12 мегапиксельные 24 битовые картинки! 256 цветов с индексированной палитрой — наше все!».
Хорошее оправдание чтобы без пользы засрать очередной гигабайт, в который этих картинок влезло бы сотня.
-1
вы просто не в курсе специфики работы всяких дизигнеров и 3дмоделеров. им это реально нужно.
+2
им это реально нужно.
Ок, допустим, нужно. Хотя сегодняшняя мазня гламурных дизайнеров — ещё то говно. А быдлокодеру — не нужно и очень вредно. Поскольку развращает «что не съем — то понадкусываю». Вот и появляются говнософтины, которые считают своим долгом засрать все ресурсы компа.
0
Это не оправдание, это объективная реальность. Нежатый BMP 320x200x256 цветов (что, кстати, в свое время после CGA оказывало убойный эффект на неокрепшую психику юного падавана :))) занимает грубо 64 килобайта плюс палитра. 12 МП 24 бита если не жать — грубо 36 мегабайт. 36/0,064 = 562 раза, всего-то. 4 мегабайта оперативы тогда и гектар сейчас — 256 раз. Да один десктоп у оси только по площади вырос в семь раз при увеличении разрядности цвета в восемь. Так что это — засирание ресурсов или объективная необходимость. Хотел бы я Вас видеть работающим с десктопом 640*480*16 цветов. Зато как летает!
Кстати, могу Sony Walkman кассетный подарить, классная штука! :)))
+2
Вот объясни почему WinNT поначалу хватало 64МБ, а сейчас нужно не меньше 1ГБ?
Открою маленький секрет, но я в древние времена ХР на 32 метрах запускал. И работало все это довольно сносно ровно до запуска антивируса. Хотя и с НОД32 в Фаерфоксе посерфить можно было. Главным тормозом был dialup канал. Сейчас до установки антивирусного пакета ХР нормально работает и на 64 метрах и на гиге. А вот с установкой антивируса (любого) об относительно комфортной работе можно не заикаться, если у тебя меньше 512 метров. Но тут вполне объективные причины — времена ловли вирусов только по сигнатурам давно канули в лету (году так 94, с появлением OneHalth), да и объем баз меньше не становится. А программы, которые нормально работают на 32 метрах, работают и сейчас, даже более новые версии. Основные пожиратели ресурсов — медиа (компрессоры/декомпрессоры/етц.), антивирус и браузер со 100500 открытыми вкладками. Так что ось хаять не стоит, нормально она работает.
+1
Тема почти неделю стояла прочно и спокойно на своих 2-х десятках сообщений, пока за нее не взялся Лайфловер… И она резко флудо взорвалась, как сверхновая на troll/holywar тему!

P.S. Посмотрел Whois Лайфловера, ему оказывается 22 года(сам студент, но все уже вокруг говнокодеры) и это местный «Элм Чан» — написал/списал/закодил стек TCP/IP для 8-битного МК и урвал таким образом себе китайский осцилл, как 1-й приз в конкурсе сообщества.
Я в недоумении, что сказать…
+1
Не, на цикл статей по сети на МК полезный, да и возраст способствует амбициям. То на то и вышло.
Конечно в стеке есть свои баги, неуниверсальности и неудобства. По скорости тоже не оптимально. Да и одним релизом не обошлось. Но вроде он и не претендовал на звание правильного программиста.
0
зато теперь на волне успеха, помахивая осциллом как доказательством, берется учить людей чуть больше понимающих в предметной области. и это печально. хотя половить лулзов смешно. :)))
0
А мне кажется, что всё он прекрасно понимает, но любит потроллить :)
+1
Боюсь, ты ошибаешься. По крайней мере у меня из общения с ним (в том числе в асечке, там можно эффективней спорить) впечатление другое — он действительно так считает.
0
Ну не знаю, плотно не общались.
0
впечатление другое — он действительно так считает.
ППЦ! других слов не находится.
0
Я в отличие от тебя могу сравнить Win2000 и Win7, и «да там возможностей больше» не годится как оправдание для 16-кратного роста требований. «Добавление возможностей» — это в нормальном мире даже не линейный рост, а вообще сраные копейки — поскольку основное уже так или иначе написано. А тут экспонента.
Когда-то посмеивались «M$ увеличивает требования, чтобы принуждать пользователей к апгрейду». Теперь вы считаете это нормальным. Есть теория, что когда пиздец превосходит все возможные пределы, все начинают старательно делать вид, что ничего не происходит. Очень похоже на правду.
0
хех. не надо рассказывать, что ты «в отличие от меня» можешь сравнить. неблагодарное это дело виртуально письками меряться.
«да там возможностей больше» не годится как оправдание для 16-кратного роста требований.
а ваши хотелки со времен 9х винды на сколько порядков выросли?
Есть теория, что когда пиздец превосходит все возможные пределы,
какой пиздец? вы о чем? нормальное следование технологий хотелкам юзверей.
+2
кстате. уже очень скоро юзвери захотят смотреть дома 4К видео. и за этой хотелкой тоже последует взрыв как процессорной мощи, так и потребности в памяти, и в емкости винтов.
смиритесь и продолжайте скулить на тему. а я просто буду пользоваться удешевлением железа для более комфортного решения моих задач.
+1
Угу. А учитывая, что я анимешник — очень скоро мне придется искать, чем можно с приемлемой скоростью декодировать H265 на моем компе… Новые технологии сжатия видео анимешники обкатывают первыми.
0
ну, у каждого свои тараканы. ))))
0
а я просто буду пользоваться удешевлением железа для более комфортного решения моих задач.
Вот как-то так…
Современная вещь старится и умирает физически еще быстрее, чем морально, хотя гад производитель и убеждает нас в обратном. Делает он это именно для того, чтобы мы не догадались о никчемности его товара. «Чувак, – говорит он, – будь крутым, выбрось эту мобилку, такую носят сейчас только лохи, а ты же не лох, ты думаешь про свой имидж, а еще лучше намажь его кетчупом и ебани об стенку – трах-бах, это прикольно, гы-гы-гы, вот смеху было, так поприкалывались». И ты, дебил, слушаешь его, мажешь кетчупом и лупишь свою цацку об стенку, смеешься, как счастливый даун, и идешь покупать себе другое пластмассовое говно – так тебе, мудаку, и надо. Потому что если ты этого не сделаешь, завтра цацка все равно сломается сама, а так мы бережем тебя от разочарований, а себя – от судов и рекламаций. А еще мы бережем свою драгоценную ауру от пробивной силы матюков, а еще нам удалось втюхнуть тебе, придурку, очередной приборчик, который тоже скоро сломается, но пока люби его быстротечной любовью, покупай ему футлярчик из крокодила, показывай своим прыщавым друзьям, трать свои денежки на дурацкие мелодии и играй в «змею» или какие-нибудь паззлы, пока не охренеешь. Приблизительно так думает эта товаропроизводительная сволочь, забрасывая нас всяким дерьмом, которое с каждым годом становится все хуже и хуже. И только игрушки мальчиков не подвержены этой чуме. Оружие производится с любовью и как бы без ограничения срока годности. Даже армейские ботинки, купленные мной в американском «военторге», как легендарный пиджак Ипполита Матвеича, не имеют сносу. Зато купленные месяц назад водопроводные краны в моей мастерской уже пускают неконтролируемые струи мне в нос, и я не знаю, кто в этом виноват – милейший Цезарь Карлыч, который мне их прикрутил, сука-продавец, который мне их продал, или противные девчонки, которые все это замутили.
Также и софт. Ресурсов в 2 раза больше, а софт — в 4 раза хуже.
-1
мнда. идею вы не поняли. а (говно/быдло)цитата вообще не в тему. впрочем, пристрастие к дутым авторитетам и цитаты не к месту мы уже все заметили.
свои мысли есть?
+1
свои мысли есть?
А у тебя есть кроме
уже очень скоро юзвери захотят смотреть дома 4К видео.
Кстати, видеокодек-то наверняка занимает десятки-сотни килобайт, написан на ужасном си (а то и о б-же оптимизирован асмом).
0
Кстати, видеокодек-то наверняка занимает десятки-сотни килобайт, написан на ужасном си (а то и о б-же оптимизирован асмом).
вы сильно-сильно льстите асму и сишечке.
и да. не надо приписывать слова. я нигде не говорил что С ужасен. научитесь читать и понимать.
+1
вы сильно-сильно льстите асму и сишечке.
Потому что таких хороших вещей слишком мало. В основном всякое дерьмо, созданное по принципам, описанным в этой цитате. Для тех, кому лишь бы разрешение видео побольше.
0
хм. да, мне нужно разрешение побольше и экран тоже больше размером. чтобы больше окошек разложить и в них больше инфы помещалось. и что?
и да, коношку я тоже хочу смотреть в нормальном качестве. развалившись в любимом кресле, а не тащиться в кинотеатр. и что?
+3
В основном всякое дерьмо
Дерьмо получается по тем принципам, которые отстаиваете вы. И да, в отличие от вас, я это проверял на практике.
+1
ну и по поводу
А у тебя есть кроме
>>уже очень скоро юзвери захотят смотреть дома 4К видео.
смотри сам. производители показали на выставках 4К моники. значит скоро они появятся на столах у юзверей. со всеми вытекающими. или анализ рынка выходит за сферу интересов? в таком случае мои соболезннования.
+1
анализ рынка выходит за сферу интересов?
Мне насрать на анализ рынка. Я называю хорошие вещи хорошими, а плохие — плохими. А то, что 95% не умеют отличить хорошее от плохого, для мя не секрет.
0
еще раз. прочитайте ВНИМАТЕЛЬНО. ПОЛНОСТЬЮ.
если получится, конечно.
+1
4K монитор — это плохо??? Ну-ну…
0
Я называю хорошие вещи хорошими, а плохие — плохими.
Сообразно своим убогим представлениям о плохом и хорошем.
+1
Кстати, видеокодек-то наверняка занимает десятки-сотни килобайт, написан на ужасном си (а то и о б-же оптимизирован асмом).
На самом деле скорее всего он реализуется аппаратно. Как вариант для тех, у кого нет соответствующего хардвера — С++ и CUDA.
+1
Я в отличие от тебя могу сравнить Win2000 и Win7, и «да там возможностей больше» не годится как оправдание для 16-кратного роста требований

Вроде бы Win 7 делалась уже как раз под обратную цель — появились Intel atom-ы и такой тип устр-в, как netbook-и. Т.е. делалось с поддержкой «хиляков» изначально и быстродействия. IMHO, мне всегда казалось, что Win 7 работает быстрее XP, и тем более Win 2000, или мне надо перекрестится?

P.S. Эти сволочи из M$ все же не зря жрут свой $100-150 кусок хлеба(который я им должен, пока :) — Win 7 влет обычно находит все, что есть внутре компа, в отличии от предыдущих версий. Радует и их ie 9 — молодцы — сейчас полностью в общей струе требований к браузерам, хоть я им и не пользуюсь.
+1
мне всегда казалось, что Win 7 работает быстрее XP, и тем более Win 2000,
не казалось. это объективная реальность. хрюша быстрее двушки. семерка быстрее хрени.
где-то видел сравнение даже восьмерки с хрюшей. хрюша сосала. за правдивость не ручаюсь, не смотрел. четную винду даже «на посмотреть» ставить не буду.
+1
Вообще, если смотреть на честные версии, то Vista, 7 и 8 — это 6.х, т.е. четные :)
0
95/98(1) ME(2) 2000/ХР(3) виста(4) 7(5) 8(6)
+1
95/98(1)
ОК, это Windows 4.x. Четная, кстати.
2000/ХР(3)
Windows NT 5.x.
виста(4) 7(5) 8(6)
Windows NT 6.x (6.0, 6.1, 6.2 соответственно, так что семерка нечетная только по минору и названию).
0
Миллениум, кстати, тоже относится к линейке Windows 4.x. На нем вся линейка и загнулась в пользу WinNT.
0
я по выходам считаю с 9х. а не по внутренним наименованиям. примерно как
— кто будет следующий президент?
— лысый!
+1
Восьмерка шустрее хрюши. по отношению к семёрке уже точно не скажу, то ли быстрее, то ли медленнее. Но даже если медленнее, не смотря на уже встроенную поддержку исошек в восьмерке, семёрка лучше.
0
Я в отличие от тебя могу сравнить Win2000 и Win7
Только с точки зрения юзера, да и то специфичного.
0
пытаешься поджечь виндолинуховый срач? ;)
0
вот жевака сюда затянуть… вот лулзов-то могло быть… )))
0
Нет. Все просто: сравнивать можно а) на своем опыте повседневной работы (на это всегда накладывается специфика конкретного пользователя), б) на основе некоего усредненного набора программ (это типичные сравнивалки во всяких журналах), в) профессионально. В последнем случае надо иметь очень хорошее представление о потрохах сравниваемых систем + кучу дополнительных знаний об внутренностях операцонок, принципов построения, вариантов дизайна важных подсистем в операционках (устройство VMM, алгоритмы планирования, IPC), некоторые знания об архитектуре компов на которых это все живет (SMP, NUMA и прочие тараканы).
Так вот lifelover далше варианта а) пока не ушел, хотя и считает свое мнение абсолютно верным и пригодным для обобщения не просто на всех, а на все IT и даже за его пределы.
+2
вариантов дизайна важных подсистем в операционках
Причем не только варианты знать, но и какой конкретно вариант в конкретной операционке.
0
Это само собой. Я имел в виду знать варианты за пределами тех, которые есть в сравниваемых операционках.
0
Так вот lifelover далше варианта а) пока не ушел, хотя и считает свое мнение абсолютно верным и пригодным для обобщения не просто на всех, а на все IT и даже за его пределы.
ты сильно-сильно мягко выразился, как по мне.
+1
Может быть это юношеский максимализм, помноженный на «головокружение от успехов»?

Конечно в стеке есть свои баги, неуниверсальности и неудобства. По скорости тоже не оптимально.
Это разного уровня задачи(на порядок, а может два) — закодить с нуля стек TCP/IP(естественно, он использовал и смотрел уже готовые реализации), и найти ошибки/неточности/не универсальнось в готовом ПО такого уровня.

Своими «идеями» он, как видно, пользуется и достигает решения задач. Может быть это просто философия/идеология такая в отношении к ПО, которая значит имеет право на жизнь, по скольку подкреплена делом?
+1
То был отсыл к его высказыванию о том, что (вольный пересказ, искать цитаты лень): нормальные программисты с нуля выпускают сразу готовый продукт, не требующий доработки, а не каждую неделю что-то обновляют.
0
нормальные программисты с нуля выпускают сразу готовый продукт, не требующий доработки, а не каждую неделю что-то обновляют.
Это же обычный/нормальный процесс. Почему же тогда мы не видим ПО только с цифрами 1.0, 2.0, 3.0, т.е. переделанное под новую моду/идеологию, добавление мега-фич новых. А постоянно видим что-то типа 2.2.24 и т.п. А баги, а патчи? А RTOS? Ну что вроде бы там писать — написал 1.0 и все, но меняли же постоянно релизы и не из-за поддержки новых чипов.
0
это конечно далекий оффтоп, но на самом деле видим — хром, фф, но там это скорее маркетинговый ход
0
фф повелся на оперу. «че мы как лохи с 3.5, 3.6 когда у остальных уже 18 версия есть!»
По мне, так «тупо по релизу старший номер увеличиваем» — отвратительный способ нумерации версий.
+1
маркетинговый ход — он маркнтинговый. Как кто-то заметил на хабре 25 > 3.5
0
Ну дак Lifelover же популярно и объяснил, потому что все программисты говнокодеры. причем версия должна быть 1.0 и всё. :)
0
не все, себя то гавном никогда не назовешь, так и выходит правило 95 процентов
+1
Своими «идеями» он, как видно, пользуется и достигает решения задач.
Нет, не пользуется. Если бы он протестировал так, как пропагандирует, вторая версия не понадобилась бы.
0
Может быть это юношеский максимализм
Максимализм — у вас, «максимум абстракции», «максимально быстро слепить» и прочее. С обычной чертёжной доской были спроектированы синхрофазатроны и ракетные двигатели. Теперь вы плату запихнуть в корпус не можете без солида.
0
Теперь вы плату запихнуть в корпус не можете без солида.
а зачем чертить на кульмане, когда можно в солиде повертеть модельку?
вот зачем придумывать себе сложности и потом строить из себя героя и преодолевать их ради решения утилитарной задачи запихнуть плату в корпус? маянипанимать.
+2
С обычной чертёжной доской были спроектированы синхрофазатроны и ракетные двигатели.
Вы уже собираете контроллеры на отдельных транзисторах? Нет? Ну тогда какие претензии к тому, что другие тоже хотят работать с таким же удобством?
+1
Вы уже собираете контроллеры на отдельных транзисторах? Нет? Ну тогда какие претензии к тому, что другие тоже хотят работать с таким же удобством?
право пользовать удобные (но тормозящие при этом!!!1111адинадин) инструменты даровано исключительно освященным первым призом на ве.ее! а остальное быдло обязано для воспитания силы духа пользоваться исключительно блокнотом и компилерами ком. строки.

если вдруг кто не понял — да! явно и недвусмысленно издеваюсь. )))
+1
велл-ман, ну вот нахера ты вспомнил, что он победитель конкурса был? это ведь у меня теперь станет любимой задрочкой персонажа…
0
зато теперь на волне успеха
Я всегда так считал. Просто ещё некоторое время назад юзали нормальные простые контроллеры, писали на Си и Асме. Теперь лезут со своим громоздким дерьмом.
0
авролавер?
бывает.
+1
Да не, просто теперь на его фразу «а я авр на асм пишу» народ реагирует не как раньше «ты крут», а «ты чё, больной?». А на написанную за 3 дня мигалку светодиодом в противовес ставят мигалку на ардуине за 5 минут и та же самая реакция :)
0
ну и правильно. все растет, все изменяется.
0
Мать, мать, мать…
Еле осилил все комментарии. Немудрено, что столь сложная и неоднозначная тема порождает столь бурные дискусии.
Как мне показалось, товариши, отстаивающие свои позиции, немного лукавят каждый. С моей точки зрения, надо четко разбить задачи на направления. Есть создание прикладного и системного ПО (преимущественно для PC-подобных архитектур), а есть создание встроенного ПО для встраиваемых систем (где до недавнего времени царили относительно простые архитектуры). Пардо за некую тавтологию.
И вот тут нас ждёт большая засада, ибо встраиваемые системы постепенно превращаются в некое подобие компьютеров: с ОС, распределением задач, прикладными программами и прочей требухой, ещё недавно нехарактерной для них. Отсюда и столь «серьёзный» подход к данному процессу. Естественно, нет смысла применять «солидные» инструменты там, где стоит задача «дрыгания» ножкой через детерминированные промежутки времени. Однако! Всё чаше и чаше данная задача встраивается в окружение сотен ей подобных, со своими зависимостями, динамическим распределением ресурсов и времени.
Я всё это веду к тому, что не стоит устраивать «срач», не оговорив контекст задач, к которым применяется тот или иной подход, а соответсвенно ему и всплывает тяжесть инструментария.
Вот, как-то так…
0
Лично я лежу бревном в инете или на диване, и жду…

1. Когда наконец-то в МК встроят программируемую логику по типу FPGA. Что бы все механизмы RTOS могли быть прошиты/перепрошиты в железе чипа и утверждены стандарты на него(как на SVGA для видео-карт или ATA для ж/д). И закончилось наконец это RTOS говнокодирование.

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

3. Когда они установят общий стандарт на все виды периферии, как сейчас на само ядро, системный таймер и контр.прерываний у ARM.

4. Когда сделают наконец ПО для разработки для «полных дебилов», чтобы не корчить и забивать мозг а-ля «программирую перфокарты для ткацкого станка XVIII века» или «зубрю иероглифы». Да, еще — чтобы его можно было изучить за 1 день.

И вот тогда-то я скажу: А нахрена мне это все надо? Я что — свой МОЗГ на помойке нашел? И быстренько затешусь в новопоявившееся и новомодное сообщество — пикейных жилетов изучающих квантовые компьютеры и ПО для них.
0
1. Нафига?
2. moeller.io/products/freesoc-mini-development-kit www.cypress.com/?id=2494
3. На все случаи стандартов не напасешся.
4. Увы, таким софтом сможет пользоваться только таргет-аудитория. Гуевых рисовалок чего-угодно было разработано море, в разработке софта, насколько мне известно, толком не прижилась ни одна. Рано или поздно приходится лезть в то, что подобные рисовалки генерят и вся гуевость идет лесом. Да и для автоматического тестирования и сборки подобные вещи пригодны плохо. Равно как и для сопровождения. Наконец, с ростом уровня инструментария растет и сложность решаемых задач, так что времени будет уходить столько же, а задача будет не подрыгать ножкой, а поуправлять ядерным реактором шаттла во время взлета и посадки.
0
Чтобы увидеть будущее — надо кое-что заметить в настоящем.

Это касается именно CYPRESS PSoC (особенно PSoC 5, который имеет ядро Cortex-M3 — текущ.пром.стандарт) и их ПО Creator. PSoC имеет внутреннюю архитектуру блоков схожую с FPGA с рядами взаимноперпендикулярных коммутационных линий с ключами(программируемые соеденительные линии). И они не поленились применить эту технологию и для внешних пинов. Но когда это применят массово другие?

Но PSoC пока относительно дорог и не распиарен, что возможно послужило бы толчком к появлению аналогов и дальнейшему удешевлению этой технологии. В любом случае такое хардвеа решение и особенно их Creator — это и есть современное видение ПО будущего — о чем я и говорил. Есть еще программируемые в FPGA процы Nios.

О стандартизации: это очень важно — без нее все так и останется просто хаосом, беспределом проприепритарщины и валом говнокода и велосипедов.
0
Чтобы увидеть будущее — надо кое-что заметить в настоящем.
Угу. Или в прошлом.
Но когда это применят массово другие?
Это первая ласточка, причем появившаяся сравнительно недавно. Если идея приживется, ее подхватят и другие.

По поводу стандартизации: у нее есть и свои плюсы и минусы. Она упрощает жизнь пользователям, но тормозит развитие. Так что, если перефразировать Жванецкого — «стандартизируй, но осторожно. но стандартизируй».
0
Что-то этот Мёллер уже год или больше всем мозги пудрит — в описании пишет о PSoC 5, а в схеме так и стоит PSoC 3.

Интересно, что он заюзал как USB-SWD мост для 3-х проводков(просто программатор или еще отладчик?) аж целый народный чип CY7C68013A(15A), который все юзают для логич.анализаторов Saleae/USBee. Причем 11 пинов просто бездействуют — какая буржуйская расточительность (наши нищеброды и Ляо — что-нибудь бы придумали)!
0
Что поделаешь, у EZ-USB FX2 меньше 56 пинов не бывает. :)
Почему именно его? Может, на нём ещё всякой всячины сделал. Вещь весьма универсальная.
0
Может, на нём ещё всякой всячины сделал. Вещь весьма универсальная.
Во-во, со свиным рылом(8051 — что PSoC 3, что CY7C68xx) — да в калашный ряд(типо ARM Cortex, как пиарит для лошков).
0
Бумажки могут устаревать, код — никогда. Код и только код является абсолютно точным описанием дизайна программы.
Только в случае т.н. самодокументированного кода. Т.е. со всеми комментариями и пояснениями прямо в листинге.
0
Угу. С одним уточнением: самодокументированный код предполагает минимум комментариев, только в тех случаях, когда они неизбежны (как раз потому, что комментарии это те же бумажки по сути). В моей практике эти случаи ограничиваются некоторыми нетривиальными алгоритмами типа шифрования или компресии/декомпрессии. Во всех остальных случаях более чем достаточно аккуратно написанного кода.
+1
Частично согласен, но только для случаев «в моей практике».

Есть такая мелкая фирмочка «Межделмаш»… Так вот у них в требованиях всегда было подробное комменирование листинга. Причина проста: хоть это и приводит к потере времени на такое документирование кода, оно сильно упрощает его последующее сопровождение.
0
Межделмашем индустрия не ограничивается. К тому же даже изначально межделмашевские поделки (или то, что делалось для них и на их деньги, например Visual Age Java превратившийся потом в Eclipse) далеко не всегда придерживаются правил тщательного писания комментариев. Более того, если внимательно посмотреть на Java, то уже на момент своего появления она содержала весьма продвинутые средства комментирования и документирования кода (javadoc). Однако довольно быстро выяснилось, что польза от них ограничивается генерацией ненужной (зато красивой и структурированной) документации для заказчика. На практике комментированию и документированию подвергаются только интерфейсы, оставшаяся часть кода пишется так, что бы в комментариях не было необходимости.
0
Эти правила постарше ваших примеров будут. Хотя, конечно, структурирования и прозрачности кода не отменяют.
0
Эти правила постарше ваших примеров будут
Как раз потому, что они «постарше», они и устарели. В те времена, когда они появились, не было многих инструментов, от IDE и до автоматизированного рефакторинга, которые помогают писать самодокументированный код.
0
Во имя холивара. Какой вечный кот? Где вы видели вечный код, ну или хотя бы не дряхлеющий. Код, как реализация _алгоритма_ чуть менее чем полность опирается и зависит от аппаратной (виртуальной) платформы. И с течением времени меняется многократно и молниеносно. Приведу как пример эволюцию 86. 16 бит. 32 бит. 64 бит. Новые регистры, новые понятия, старые умирают, возникают новые, гораздо эффективнее. Код тысячекратно меняется, адапируется.

Поэтому — алгоритмы. Они вечны, а кот, он временный.
0
Алгоритмы вечны, да. Однако и с кодом не все так просто. Часто код живет десятилетиями без существенных изменений. Это характерно для большинства языков, которые достаточно хорошо абстрагированы от платформы. Cobol, Fortran, Java — это только несколько примеров языков, код на которых, будучи однажды написанным, может жить десятилетиями, спокойно переживая смены железа, платформ и прочих заморочек.
+3
Дада… Отлично себе живет. Если не теребить. Или железяка не сломается. у меня — больше лет 5 ти не выходит. Либо железо, либо концепции.

Впрочем это уже тавтологии
-3
Сочувствую. Я знаю очень много проектов, которые прекрасно живут по много лет (значительно больше 5). Все прекрасно живет, переезжает с железки на железку, развивается и доделывается (именно доделывается, а не переделывается). Впрочем, вы их тоже знаете. Тот же еклипс 3.0 вполне нормально работает на любой современной железке (первый официальный релиз вышел в июне 2004-го, то есть больше 10 лет назад).
0
Иклипс меняет версии быстрей чем я носки. И с версиями архитектуру. Ну и пример непоказателен. Ибо java один из немногих языков с обратной совместимостью на деле.

Не появляйся новых требований к разработке — мы бы и сидели на иклипсе 1.0.
Сферический проект на сферической железяке может жить вечно. Не про них речь. В реалиях жизни — статичный проект == мертвый проект. И я даже полагаю что это хорошо.

По большому счету я вообще придерживась концепции описания алгоритма, а не кодирования. Кодирование можно переложить на машину (во многих случаях)
+1
Иклипс меняет версии быстрей чем я носки.
Ну и? Смена версий вызвана вовсе не сменой железа или платформы.
Ну и пример непоказателен. Ибо java один из немногих языков с обратной совместимостью на деле.
Я выше перечислил как минимум три языка (на практике их больше), которые спокойно переживают смену платформы.
По большому счету я вообще придерживась концепции описания алгоритма, а не кодирования.
Идея хорошая с одним небольшим замечанием: алгоритмы это только часть программы. Помните как книгу Вирта «алгоритмы + структуры данных = программы». На современном этапе я бы добавил еще " + взаимодействие".
+2
Взаимодействие кого или чего с кем или чем? Это важный момент.
0
Компонентов программы между собой. Наверное это можно было бы назвать алгоритмом, но алгоритм подразумевает описание последовательности действий, а тут такого описания нет. Зато есть структура «соединений» между компонентами.
0
Программа (код) == реализация алгоритма в текущей платформе + текущих реалиях задачи.
Под реалиями я вижу: скорость разработки, объемы задачи, требования от заказчика.
Быстро за 10 минут или качественно за день,
Для одной страницы данных или терабайтной базы,
С бутстрапом или в консоли.

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

И алгоритмы… это не часть программы )… это ее идея. Идея не часть, идея это с другого уровня.
+1
Программа (код) == реализация алгоритма в текущей платформе + текущих реалиях задачи.

Нет. Если уж мы тут философствуем, то программа может быть задана декларативно, и не иметь ни кода, ни привязки к платформе.
Например, «Поверните налево через 100 метров» — это тоже программа. Здесь есть алгоритм, структура данных, даже сами данные. Именно связка алгоритм + структура данных, это то, без чего программа существовать не может. Evsi правильно советует — почитайте Вирта.

А если уйти от философиях размышлений то на практике, особенно в энтерпрайзе, есть куча софта который живет десятилетиями. Просто потому, что он удовлетворительно выполняет свои функции и менять его на что-то другое экономически не выгодно. Например, древний sendmail под древней FreeBSD отлично справляется со своими задачами (просто недавно видел такой сервер на достаточно крупном предприятии – хвастались аптаймом сервера, там что-то около 8 лет аптайма).
0
Частный случай не доказывает ничего. Потому что тонет на фоне миллионов обратных ситуаций.

Соратники, не вижу смысла тянуть эту ветку дискуссий. В этой куче уже и императивное программирование и декларативное. Еще чуть и холивары хаскелистов против емаксоводов начнутся.

По существу — заведу отдельные тематики по конкретным темам в методологии разработки ПО. Там и продолжим.
0
выделил отдельную тему в топике we.easyelectronics.ru/Soft/zachem-vam-oop-ili-zaycu-stop-signal_2.html
0
Программа (код) == реализация алгоритма в текущей платформе + текущих реалиях задачи.
Какой алгоритм реализует типичное веб-приложение (да хотя бы тот же блог или магазин)?
0
Блог это:
1) инфраструктура сервера. Алгоритмы сетевого взаимодействия. Это алгоритмы в маршрутизаторе, в сетевом стеке ОС сервера.
2) Веб сервер. Апач или там нжиникс. Его прослойка с десятком-двумя алгоритмов.
3) Веб приложение: как правило базируется на реляционной базе с ее алгоритмами.
4) Компоненты веб приложения: картинки, разметка. Банальный жипег — алгоритм Хаффмана.

В чем вопрос? в том что у системы не имеющей явных признаков алгоритма нет алгоритмов? Так в его компонентах полно «алгоритмов» (реализаций)
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.