Обсуждение

Вполне возможно, что толковые экс-сотрудники Cycorp тоже "keeping a very low profile". За последнее десятилетие был заметен только Гуха, у которого все продукты не на микротеориях, а на кривых схемах для метаданных.

Ну, Гуха никогда не держал low profile. А я когда Lenat исчез, сильно расстроился: я его задолго до веб-революции отслеживал, ещё с середины 80-х (работы по Eurisco были моим любимым чтивом в те годы). А потом обрадовался, когда где-то в 1996 или 1997 году нашёл вебсайт CYC. Но информации там, конечно, никакой не было -- кроме того, что Lenat продолжает пахать. Моя собеседница, которая там работала, сказала, что там очень и очень есть чем гордиться и что показывать. И что CYC и тамошние технологии современным миром сильно недооценены. И она была бы счастлива над этими всеми идеями поработать, но внутренняя дисциплина компании не даёт возможности работать над тем, чем хочется, а только над тем, что нужно лично Lenat. Ну, люди приходят и уходят, по пути рождая удивительные технологии (отнюдь не все из которых потом отливаются в продукты и вообще показываются).

а что ест доступного по чтению об Eurisco?

А погуглите Lenat Eurisco -- и будет вам счастье. Ежели рассматривать жизненный цикл человеческого знания, то наилучшей формулировкой, которую я нашел на настоящий день, является lerning by discovery, или Accretion Model of Theory Formation Дугласа Лената. Компактифицирование знания, его рефакторинг, изменение формы презентации являются существенными стадиями этого жизненного цикла (конечно, эти стадии пересекаются!). Переведу заново эту "модель прироста в формировании теорий" (http://eksl.isi.edu/files/library/Lenat-1983-theory-formation-by-heuristic-search-AIJ-heuristics.pdf, а более ранняя цитируемая там работа -- http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA096511&Location=U2&doc=GetTRDoc.pdf): 1. Когда дано немного новых (не полностью исследованных) определений, объектов, операций, правил и т.д., немедленно собери о них эмпирические данные: найди их примеры, попробуй их применить и т.д. 2. По мере того, как это продвигается, пробуй заметить в данных регулярности, паттерны и исключения для паттернов. 3. Из этих наблюдений сформируй новые и модифицируй старые гипотезы. В мире, который ты можешь как-то контролировать, спланируй и проведи эксперименты для проверки этих гипотез. 4. По мере того, как развивается набор догадок, экономизируй путем создания новых определений, которые укорачивают формулировки наиболее полезных догадок. Весь циклический процесс сейчас начнется заново с шага 1, на материале этих новых определений. 5. По мере прохождения цикла (шаги 1-4), становится необходимо время от времени обобщать некоторые новые специализированные эвристики, перерабатывая прошедший опыт обучаемого [тут нужно учесть, что Ленат описывает "обучение открытиями" -- lerning by discovery] 6. В еще более редких случаях будет необходимо дополнить или сдвинуть репрезентацию, в которой кодировано знание о предметной области. 7. Для всех шагов в этой модели, даже для шагов 5, 6 и 7, достаточно собирать и использовать набор эвристик, неформальных правил рассуждения, которые ведут исследователя к наиболее приемлемым альтернативам и уводят от наиболее неприемлемых. Это я когда-то писал в http://ailev.livejournal.com/872954.html (и часть этой программы даже выполнил -- книжка "Системноинженерное мышление в управлении жизненным циклом" в существенной мере про это, а сейчас продолжаю двигать в направлении системного языка).

Где-то в 1990 я читал "Компьютер обретает разум" издательства Мир (переводы изданий Artificial Intelligence и Computer Images от Time-Life), там в числе прочего было о проектах Лената. Выглядело очень вдохновляюще, а для школьника без собственного компьютера (хотя и с МК-52) так вообще из области мечтаний.

Картинка хороша. Так и хочется дописать "computer science" vs "software engineering".

Именно! Я всегда так и объясняю: software engineering всегда сортирует пузырьком, а computer science такое в голову даже не приходит.

Нет, нет. Там разница тоньше. Во-первых в software engineering сортируют обычно функцией sort(), а вот тем, кто свой алгоритм сортировки выдумывает, откручивают уши. Во-вторых, разница, скорее, в том, что в CS задача считается решённой, когда для валидных данных есть валидное решение. А в software engineering задача считается решённой, когда программа перестаёт падать. То есть большая часть, а в идеале все bad path превратились в sad path (вместо Segmentation fault программа начала возвращать ошибки на невалидные данные). Упор на разное. Острее всего заметно это у программистов на хипстерских языках, а ля питон/эрланг, когда показать трейс пользователю считается нормой.

Раньше в России сочетание computer science и software engineering можно было встретить в Новосибирске, Ростове, Москве и Питере. А теперь везде software engineering осталась в какой-то мере, а вот computer science разговор людьми, которые и в software engineering понимают, поддерживается главным образом только в Питере. Ужас в том, что ни олимпиадные задачки, ни тупые залежи тупо работающих кодов не дают должного качества на выходе. Нужно знать обе дисциплины, а это почему-то оказывается невозможным по совокупности причин.

Я человек глубоко травмированный разведённым программистами CS на предыдущем месте работы, и я могу сказать почему это. Обычно программист либо думает о том, как его код будет работать, либо он думает о том, как его код он будет писать. Если думает о том, как код работать будет - это software engineering. Если о том, как он код писать/дописывать будет - это уже ближе к CS, потому что хочется красиво, правильно и так, чтобы всё было ровненько. И обычно эти вещи почти ортогональные, потому что надо _либо_ чтобы оно работало (и тогда надо красотой жертвовать), либо красота (алгоритмы!) важнее.

Правильный подход -- это хорошо писать, и добиваться, чтобы хорошо работало. И для этого в ключевых точках должны быть правильные алгоритмы (т.е. программист не должен уклоняться от дискуссии, как лучше обойти его случай дерева: сверху вниз, снизу вверх или сикось накось. Он должен знать о существовании такой дискуссии и основных аргументах сторон ещё до написания кода!). Но или человек долго возится с usability и agile, либо дружит с математикой и читал Кнута. Гармоничный баланс двух умений плохо получается. Возможно, нужно использовать разделение труда: иметь в команде как минимум одного чокнутого алгоритмиста и одного чокнутого человека с инженерным взглядом на жизнь, и талантливого менеджера, который сможет обеспечить их дружную работу с "конструктивным конфликтом" (а не деструктивной сварой с утра до вечера). Это отличается от "иметь в бригаде языковеда", ибо знакомство с алгоритмами обычно означает языковедение на очень и очень заковыристых языках, недоступных простым императивным смертным.

Не-не-не, я про другое. Когда надо "хорошо писать", но выясняется, что для обхода бага "а" в сторонней библиотеке надо всобачить большой воркэраунд, а для поддержки старой конфигурации серверов надо пойти и написать кусок стандартной библиотеки с ifdef'ами или условной сборкой, а для обработки "странной фигни" надо прогнать регэксп над xml перед тем, как его разбирать, то возникает два подхода: * Ок, это важно и мы будем эти хаки вставлять. Оно отлично работает не смотря на баги софта вокруг. Хотя код выглядит мрачновато. * Я хочу иметь чистый красивый код. Пусть у нас будет специальная фабрика, которая возвращает классы в зависимости от необходимых багфиксов, но код самой фабрики будет чистый и эстетичный, а фиксы будут вынесены в отдельные файлы с помощью DSL'я. Баги и кривости вокруг - константа. Остаются два подхода. Вот инженеры выбирают первый - потому что за минимальное количество усилий они получают исправление проблемы. CS/абстрактные программисты выбирают второе, потому что они хотят видеть core проекта, написанным так, чтобы оно вызывало эстетическое чувство красоты. Вот второй подход по моим наблюдениям разрушителен для проектов. Потому что к моменту написания DSL'я окажется, что один из новообрнаруженных фиксов он не может реализовать, и надо либо его весь передумывать/переписывать, либо всобачивать фикс на живое, причём поверх сложного кода фабрики. Это вызывает фрустрацию и у программиста (желание переписать таки фабрику), и у менеджера проекта (у которого нафиг несдавшуюся фабрику классов переписывают уже третий раз).

Вы смешиваете в одну кучу софтваре инжиниринг и программирование/кодинг. А CS тут вообще не причем. Просто софтваре инжиниринг - более общеее явление нежели просто кодинг. Как известно тестирование требует от 50-80% усилий. Ну и в жызненном цикле софта, сопровождение также занимает большую часть. А собственно программирование и кодинг - это 5-15%, ну точнее конечно в нонешних условиях, в мелких проектах это не совсем так. Но просто организация труда несколько другая. А суть в том, что софтваре инжиниринг заботится о долгосрочных затратах, потому и думаю как код писать/сопровождать/тестировать и проч. Ну а программеры/кодиры - сугубо о локальных проблемах. А компьютер сайнс - это вобще что-то другое.

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

А ведь верное замечание! Я считал это само собой разумеющимся, но понял, что это нужно оговаривать отдельно. В самой системной инженерии (сугубо инженерной дисциплине) понятие полного жизненного цикла появилось только в самых свежих стандартах (по факту только в ISO 15288), все стандарты до этого обращали внимание только на часть "разработки" (иногда даже не доходя до "изготовления" -- поэтому и испытания после изготовления вообще выпадали из предмета).

Насчет сомика, кстати,- аналогичный случай был в нашем офисном аквариуме. Я поверить не мог, что его маленькие рыбки съели за ночь без остатка. Грешил на уборщицу до вашего поста ).

Или таки "so long, and thanks for all the fish"? :-)

Надеюсь, последствия будут поменьше ))

о! это прекрасно.