Утилитарность против академичности

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

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

Не кривой и глючный лисапед имени умельца Васи тюненх-гаража ПукинXP, а Trek за 300$ из Спортмастера. Может быть и тяжеловатый и не супер быстрый, но гарантированно рассчитанный на прямое попадание 15 летнего подростка в седло.

>Ты бы согласился жыть в пёсьей конуре, которую слепила из всяких нечистот бригада из полсотни высокооплачиваемых расп#@дяев и от которой постоянно что-нибудь отваливается только потому что оные расп#@сдяи не соглашаются учиться?

дык других то нету. Возьмем к примеру 1с, сколько не кричали по этому поводу, но конкурентов в этом месте и не видать,

> Может быть и тяжеловатый и не супер быстрый, но гарантированно рассчитанный на прямое попадание

Как же безграмотно налабанный софт может быть гарантированно рассчитанным на что-либо вообще если он падает даже самопроизвольно, без всяких видимых признаков? Как он может быть дешёвым если только на его добавочную техподдержу и сопутствующие расходы, вызванные глякавостью, может уходить на порядки больше средств, чем стоимость написания полноценного с нуля?

>Все правильно, ПТУ - решают кадровые вопросы.

В этой шутке есть большая доля правды. Я вижу тут некоторые не понимают, что для того, чтобы кодить и админить сетки, высшего образования не надо. У меня есть приятель, который до второго курса Бауманки доучился и бросил. Вообще забил на высшее образование. И сейчас в крупной конторе администратором системным работает. И он прав, когда говорит, что ему для его работы вся эта Бауманка не нужна. И без нее работается. Вот я и хочу местных ораторов попросить: либо пусть меняют мозги, либо пусть не лезут со своим бредом в академическую среду и ВУЗы. Во истину ПТУ или техникумы нужно для них.

А какие тут шутки. Я считаю, что это бездарное расточительство кадров, 6 лет обучать чел-ка в МГУ или Бауманском, чтобы он потом цыски программировал или солярку администрировал.

> дык других то нету.

Дык "пипл хавает", даже в тех случаях, когда есть намного более качественная замена. Потому что не может или не хочет проводить независимую экспертизу ПО. Потому что безграмотен не только в компьютерных делах. Потому что в ВУЗах (!!!) готовят в самом лучшем случае квалифицированных каменщиков, и который каменщик говорит "В этом месяце мы будем делать перекрытия между этажами. В прошлом месяце мы мостили тротуар дорожным кирпичём, и тротуар этот не развалился и не упал вниз. Поэтому перекрытия между этажами мы будем также делать дорожным кирпичём, ведь это надёжное и проверенное решение" становится тим лидером и менеджером, и получает потом дополнительное бабло от закащика за установку подпорок под каждый кирпичик перекрытия, когда оно всё целиком йопнулось на бошку этого самого закащика в первый же день...

> А какие тут шутки.

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

нет (с).

К сожалению мозг нужен и програмисту и сисадмину. Без этого выбираются неоптимальные решения.. Если не сказать хуже. Сколько я уж видел такого.

Решения должны выбираться более высококвалифицированными

> Технологичность, батенька.

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

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

Проблема на самом деле еще и в том, что мало кто занимается выделением типов софта. Например, MS Word и OpenOffice Writer: оба продукта --- ручная работа, причем низкого качества. Т.е. все недостатки допромышленного способа производства и раннего массового производства (миллионы _абсолютно_ одинаковых экземпляров): велики затраты и слабая удовлетворенность потребителя.

>К сожалению мозг нужен и програмисту и сисадмину. Без этого выбираются неоптимальные решения.. Если не сказать хуже. Сколько я уж видел такого.

Но это знание совершенно не требует 6 лет учебы! У меня друган уехал в GB. Пошел там на курсы (не в ВУЗ!), где в течении там года или двух обучают всяким админским делам. Не просто "нажал на кнопочку и появилось окошко". А некоторое более углубленное изучение конекретного ремесла плюс некоторая теория, которая может пригодится, но далеко не каждому. Я знаю это, так как решал ему туда задачи по теории вероятностей и статистике применительно к вероятностям прохождения пакетов по сети и т. д. Причем теория только ограничена практическими применениями. Остальное просто не дают. Плюс у них там небольшой курс по Java. Все! И в путь, дорогие господа! Экзамен сдаешь хорошо, то могут посодействовать в трудоустройстве (подробностей не знаю). Не сдаешь -- твои проблемы.

Главное в этом мире: Уметь работать с людьми, а не с техникой и байтами. Этому ни на каких курсах и ни в каких университетах не учат.

Требует.
Без системного подхода наворотят...

Люди -- втч разработчики, админы, ДБА -- совершали на моих глазах абсолютно очевидные логические ошибки, полагались на non-exhaustive matches(как это сказать по-русски?), делали математические ошибки(не могли прикинуть в уме распределения, отклонения, моды), выбирали кривые пути решения, иногда даже не решающие вопрос. Именно для борьбы с этим и нужна теория алгоритмов, логика, дискретная математика, статистика, методология.

Беда в том, что грамотных реализаторов чужих идей тоже нехватает.

"Безграмотно налабанный" и "академически некрасивый" это два пересекающихся множества. С точки зрения Таненбаума, Linux, FreeBSD и Венда "академически некрасивые", но нельзя их назвать "безграмотно налабанными" (без фанатизма). В тоже время Plan9 академически красив но фантастически бесполезен. А Hurd - академически красив, но с точки зрения Линуса "безграмотно налабан".

+1. Только еще есть такие люди, которые вместо хорошего инструмента предлагают красивый, а есть, которые вместо удобного инструмента предлагают хороший. А вот когда хороший и удобный инструменты пересекутся, наступит счастье.

Но к уровню проектирования предприятия его все равно нельзя подпускать. Хочет ли он всю жизнь крутить хвосты хабам?

Вечная дилемма: человек с хорошими знаниями долго на неинтересном месте не просидит, вот и сидит там человек с плохими знаниями. Частично это решают процедурами, но в некоторых местах это экономически не оправданно. Вот и получается, что в МВидео продавец принтеров, который, c#ка, на них весь день пялится, чтобы сказать, сколько тут DPI идет в подсобку за инструкцией.

> И всё-таки, _зачем_ для этого использовать те средства, которые никто из компетентных людей не считает удобными?

Компетентные люди это группа аналитиков с ЛОРа или кучка профессоров, которые продакшена в глаза не видели ?

> Компетентные люди это группа аналитиков с ЛОРа или кучка профессоров, которые продакшена в глаза не видели?

Твой вариант?

> Он хорош в Ашан за пивом после работы ездить

Куда-куда? В мир пятых Героев?!

> То, как оно устроено сейчас, не имеет ничего общего с технологичностью. Технологично --- это когда есть конвейер ...

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

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

> Да и то, сумму и произведения ряда куда девать? Самый что ни на есть "for". :) До бесконечноти? =) И во времени? Нет! Это функция от последовательности, бесконечного вектора... Одна из норм. =) Функан. =)

> Твой вариант?

мой вариант чего ? компетентных людей ?

>Требует. >Без системного подхода наворотят...

Ты спроси тут местных ораторов, нужно ли им было прикидывать распределение в уме когда-нибудь. :)

Ну так 6 лет ему зачем. Физика, химия, мат. анализ, линейная алгебра, культурология, история? Это же целых три года можно выкинуть (обязательные предметы). А также выкинут половину из того, что дальше. Ну вот теория информации. Ну зачем ему знать про границу Шеннона, например, или что такое ортогональность в кодивании, коды Рида-Соломона или Хемминга). Задачи, которые этот специалист должен решать, весьма ограничены по сути. Но эти специалисты неизбежно нужны: базы данных кто-то делать должен, окошки рисовать, кнопочки размещать. Но молчать, когда при них люди занимаются созданием трансляторов, компиляторов, решением сложных задач, оптимизационными алгоритмами и всякими численными методами. "Сферический конь" у них, понимаешь. Они не понимают, что это не сферический конь, а жерло биореактора с ржущим и потирающим ладони Луговским. :)

Мне больше нравится конкретика. Вот пример из практики моей. Реализация протоколов обмена с устройствами. Если интересно, то это была многопроцессорная плата на DSP для обработки звука. Так вот дали эту задачку одному явно недоучившему студенту. Уже на последнем курсе. Недоучившийся студент -- это который не учился. :)

Надо было реализовать грамотный протокол обмена. Этот товарищ такое наимплементил, что у меня глаза на лоб полезли. Ну вот что делает грамотный специалист, который учился, если надо сделать свой протокол обмена? Он сядет и начнет разрисовывать автоматы состояний приемника, передатчика. Надо знать методику разработки протоколов, знать, что такое автомат. Вообще-то в голове у него много еще чего сопутсвующего должно быть (многим известная семиуровневая модель, например). Он должен быть в курсе того, какие уже стандарты есть на этот счет. Не придумывает ли он велосипед (а он придумывал, так как был протокол BSC, который имеет аналог в ГОСТ)? Ой, я же забыл! Он должен знать, что такое помехоустойчивое кодирование. Знать, например, что за страшный такой образующий полином и как считать CRC хотя бы (табличный метод или делением на полином), быть в курсе таких вещей, как методы обеспечения исправления ошибок на стороне приемника. Такие определения, как кодовое расстояние, знать должен. Как выбрать спецсимволы, как обеспечить кодопрозрачность (о такой вещи, как фильтрующий спецсимвол, он даже не знал, хотя это практика типичная в знакоориентированных протоколах). Хорошо, что таймеры ожидания догадался сделать, но только после этого у него начинался бардак. Он же автомат не рисовал, вот у него и впадал приемник с передатчиком в какие-то странные состояния, в которых он из-за сложности своего спагетти-кода, не смог разобраться даже. А ведь знал бы он, как потом красиво по автомату можно код сделать. Но он не знал. Один из его перлов -- это стартовый (синхросимволы пакета) -- 0x00 0x00. Я рыдал. Форматы кадров у него были -- один смех. Пришлось тыкать его в литературу, где показано, как делается спецификация. А потом такие приходят на форумы и говорят всем, что все это мура, вы все яйцеголовые. Наплодили вас тут.

Со скрежетом зубовным, но тут я с тобой соглашусь :)

Если чертова прорва народа, которая спит и видит - как бы сделать-переделать всю требуемую работу. Вся задача сводится к "им ее дать, чтобы не простаивали".

> Они не понимают, что это не сферический конь, а жерло биореактора с ржущим и потирающим ладони Луговским. :)

В фортунки! :)

>Они не понимают, что это не сферический конь, а жерло биореактора с ржущим и потирающим ладони Луговским. :)

Ему вроде и так там, в биореакторе, неодиноко, или он каждому новому человеку радуется?

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

Ладно, если бы они небоскреб строили. "А то обычно строят как сарай, а внедряют, как небоскреб" (C)

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

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

:-))

А кроме этого есть чего возразить ?

Складывается впечатление, что вы знаете о программерских конторах только по книжкам и глянцевым журналам. :) Брукса читали?

Тебе просто неповезло. Брось то болото, в котором сидишь. Поработай в конторе, где есть нормальное разделение труда и где каждый знает свои обязанности.

> Мсье не доучился.

Почему, полные 11 классов. Закончил с пятёркой по алгебре, ещё до ЕГЭ. Единственное что у нас по алгебре сознательно пропустили погрешности и почему-то логарифмы, что впрочем очень доходчиво объяснили в первые полгода в инсте.

И претензии по поводу мат.значков не понимаю, если честно.

> присваивания нет

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

> Ну дык. На пролог похоже, на императивщину - нет.

IF теорема(условие) THEN: IF X=Y THEN A=B ELSE B=C END IF

Если end if глаза мозолит, можно в одну строчку:

IF теорема(условие) THEN IF X=Y THEN A=B ELSE B=C

Если это не "императивщина", то я ничего не понимаю.

> Тебе просто неповезло. Брось то болото, в котором сидишь. Поработай в конторе, где есть нормальное разделение труда и где каждый знает свои обязанности.

Мимо. Я работаю в очень толковой конторе и уходить не собираюсь. Однако процесс разработки ПО гораздо сложнее, чем думают отдельные теоретики вроде вас, и трудности, с которыми приходится бороться, проистекают из фундаментальных свойств человеческого сознания, а вовсе не из плохого разделения труда или неэффективного руководства. Ещё раз переспрашиваю, вы Брукса читали?

> IF теорема(условие) THEN: IF X=Y THEN A=B ELSE B=C END IF

Давайте, всё-таки, спорить не о бейсике, а о традиционной математике. :) В какой именно теореме, по-вашему, используется операция присваивания?

> А кроме этого есть чего возразить ?

Есть, но не в этом формате. Ибо возражать на то, чего не существует, мягко говоря, непрактично, а грубо выражаясь, глупо.

> "Безграмотно налабанный" и "академически некрасивый" это два пересекающихся множества

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

> С точки зрения Таненбаума, Linux, FreeBSD и Венда "академически некрасивые", но нельзя их назвать "безграмотно налабанными" (без фанатизма).

Хм, если говорить о двух первых, то есть аргументы в пользу именно такого их построения. И чтобы спорить на этот счёт, нужно иметь соответствующуюю квалификацию. Т.е. можно предполжить какие-то огрехи "в большом", в общей структуре, но трудно обосновать что это именно огрехи. Но такая квалификация нужна редко ибо мало проектов, требующих квалификации такого уровня. А вот в более простых случаях, как например участок кода из реального проекта: bool foo (bool x) {if (x == true) return false; else if (x == false) return true; else return !false && !true;} или, того хуже, виндовсь, которая (без фанатизма) кишит очевидными несуразицами наподобие синхронных операций с сетью в главном цикле событий, незакрываемыми портами, двояким способом передачи имени сетевого ресурса в зависимости от длины этого имени и прочими ништяками, безгамотны совершенно очевидно.

> В тоже время Plan9 академически красив но фантастически бесполезен.

Потому что ты не знаеш как его применить или по каким-то другим соображениям?

> А Hurd - академически красив, но с точки зрения Линуса "безграмотно налабан".

Видать недостаточно красив, ибо используя тривиальное пи-исчисление можно было бы лишить его проблемы рейсов. Или ты считаеш пи-исчисление лженаучным, раз уж оно не сочетается с "академически красивым" хурдом?

> Поработай в конторе, где есть нормальное разделение труда и где каждый знает свои обязанности.

Например, в Майкрософт. Там одну задачу умудрилисть разделить на 40 с лишком человек, причем каждый, не сомневаюсь, отлично знает свои обязанности. В отличие от нас. Мы хоть и партнеры Майкрософт, до сих пор никак не можем без смеха перевести на русский язык ребус под названием "shared manager". Не говоря уж о том, что подобный зверь вообще не упоминается в MSF. Никак, очередное секретное оружие Майкрософт...

> Давайте, всё-таки, спорить не о бейсике, а о традиционной математике.

Щас придет Саныч и скажет, что лучше всего спорить о бабах.

> Например, в Майкрософт. Там одну задачу умудрилисть разделить на 40 с лишком человек, причем каждый, не сомневаюсь, отлично знает свои обязанности. В отличие от нас.

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

> Аха, я приводил ссылу на это здесь.

Эту ссылу только ленивый не приводил. Уже пол-тырнета ташшится. А мы еще и профессионально.

Читали, читали... во многом бред тот еще.

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

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

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

Вы видно, таки не читали Брукса. Или просто не поняли его. Достаточно было запомнить фразу, что "девять беременных женщин никогда не выносят ребенка за один месяц". Вот такое вот фундаментальное свойство человеческого сознания получается...

Или, вот сегодня пробежал коммент в старую тему:

http://www.developers.org.ua/archives/max/2006/05/15/metod-bigbook-dlya-mened...

...К следующему совещанию каждый разработчик купил и принес с собой экземпляр книги Брукса, положив в общую стопку, повторяя руководителю: "Это очень срочно! Вы должны немедленно прочесть эту книгу. Мы купили вам несколько копий чтобы вы могли читать ее быстрее."

> Ну и? Разработка операционной системы сложная, уникальная задача.

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

> Риск провала такого проекта всегда присутствует.

По статистике более 90% проектов разработки программного обеспечения -- провальные. Неужели это все операционные системы?

> Есть, но не в этом формате. Ибо возражать на то, чего не существует, мягко говоря, непрактично, а грубо выражаясь, глупо.

:) Да уж. Боюсь даже спращивать как же тогда партнеры мекрософта разрабатывают программное обеспечение. Вы лучше подчеркните правильное:

a) У вас нету человека, который отвечает за формализацию требований заказчика и разработку постановок задач

б) У вас нету человека который отвечает за общую архитектуру программного обеспечения и техническое руководство программистами

в) У вас нету программистов которые реализуют и интегрируют подсистемы программного обеспечения

г) У вас нету человека отвечающего за организацию тестирования ПО

д) У вас нету людей которые внедряют программное обеспечение заказчику

е) У вас нету людей отвечающих за написание документации

е) У вас нету людей которые осуществляют административное руководство

Какой из перечисленных сотрудников у вас отсутствует ?

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

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

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

> Вы видно, таки не читали Брукса. Или просто не поняли его. Достаточно было запомнить фразу, что "девять беременных женщин никогда не выносят ребенка за один месяц". Вот такое вот фундаментальное свойство человеческого сознания получается...

Странно, вроде бы это фундаментальное свойство не мешает создавать космические корабли и подводные лодки, а писать программы оно мешает ?

Просто нужно устанавливать реальные сроки и всегда закладываться на "всякий случай".

А брукс как обычно либо говорит банальность либо гонит насчет того, что программисты это такие уникальные гуманоиды с другой планеты и все у них не так и все не эдак.

> ...К следующему совещанию каждый разработчик купил и принес с собой экземпляр книги Брукса, положив в общую стопку, повторяя руководителю: "Это очень срочно! Вы должны немедленно прочесть эту книгу. Мы купили вам несколько копий чтобы вы могли читать ее быстрее."

О! Какое откровение! Ну конечно это применимо только к разработке ПО