OlegZH

Хороший пример крайне расточительного применения машинного обучения…

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

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

Зачем же ставить перед машинным обучением заведомо некорректные задачи?

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

Интересно, а можно было бы сделать Интеренет, вообще, без HTML и JavaSscript?

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

В действительности, в реальном мире смешиваются следующие три вещи:

1. хранение документов в исходном виде (как записей некой базы данных);
2. форма представления документа для отображения на экране пользователю;
3. и форматы для передачи данных по сети

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

Трудно сказать, что могло бы быть альтернативой. Точнее, сказать-то, как раз легко: например, CORBA и то, что называется удалённым вызовом процедуры. Можно только гадать, как выглядело бы соответствующее программное обеспечение. Но одно можно сказать с полной определённостью: во главу угла был бы поставлен DOM и реализующий его сетевой протокол поверх HTTP. (Возможно, потребовалось бы дополнительная прослойка в виде специализированного протокола идентификации типа ресурса, чтобы иметь возможность надстраивать отдельные протоколы под работу с различными типами данных — эдакий обобщённый JSON, функционирующий на программно-аппаратном уровне сетевого протокола!) Следует понимать, что по сети должны передаваться только данные, а не документы. Но, если по сети передавать только данные (включая и метаданные), а реализацию конечных элементов отображения и управления отдавать на откуп нативным приложениям в своих родных операционных системах, то зачем надо будет городить огород многоэтажных технологий?

Графы — это моя ещё не реализованная мечта. Спрашивается: как её реализовать?

Ужас! Вот, я. Думаю, что мне делать. Просто так читать книги, да мануалы? Пополнять ряды ничего не умеющих «самозванцев»?… Их (тем, вопросов, сред разработки, библиотек, языков программирования) много. А я один.

Может быть подкинете мне мне какую-нибудь «домашку». Хочу сделать что-нибудь реальное. Работающее. Нужное. Заодно, изучу новое для себя. Испытаю свои силы. Стану лучше соображать.

А? Пожалуйста!

Самый главный враг любой грязи — это солнечный све

Вот про этот самый солнечный свет и хотелось бы прочитать больше всего, потому как, наука, получается, ничего не смогла дать индустрии разработки программного обеспечения. Если бы существовала теория создания программных систем, то на практике применялись бы её методы и модели. А так, получается, что годы усилий в отрасли под общем названием Computer Science прошли впустую. А если взять публикации за различные годы, то можно обнаружить обсуждения практически одних и тех же вопросов (с точностью до замены названий операционных систем, языков программирования, программных библиотек и текущих модных аббревиатур).

КОМОК ГРЯЗИ в программном коде всегда начинается с КОМКА ГРЯЗИ в размышлениях и рассуждениях, когда себе можно позволить любую сентенцию, любое произвольно взятое сравнение и соединение очередного ужа с очередным ежом и, при этом, не нести никакой ответственности за свои слова. Сколько было высказано всяких предложений и предложено всяких методик разработки программного обеспечения, но никто не может признаться, что в провале проекта повинно либо усиленное рвение по исполнению методики, либо неполная реализация той же методики, и всё это — при отсутствии какого-либо теоретического (хотя бы) критерия качества предлагаемой методики!

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

А задача-то ставится до ужаса просто и «примитивно»: что такое компонент? чем использование компонентов лучше, чем создание приложений? как следует разрабатывать программное обеспечение, чтобы собирать его из компонентов?

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

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

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

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

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

Я могу только предполагать, что документ с надписью «В архив не сдавать» хранится в архиве в папке с надписью «В архив не сдавать».

(Цитируется по книге Г.Дейтела «Введение в операционные системы», том 2, стр.28.)

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

Это любопытно лично вам. Мне вот например это совсем не любопытно.

Я очень жалею, что не увлёкся программированием (как этого, вообще говоря, следовало бы мне сделать) в школьные годы. Самым интересным делом для меня было бы создания своего собственного языка программирования. Я бы поставил задачу таким образом: создать генератор языков, позволяющий по описанию задачи (или семейства задач, то есть, по существу, по описанию модели), формировать язык. Но… я испугался нормальной формы Бэкуса-Науэра и так и не сделал свой собственный калькулятор! Хотя бы! (Думаете, время безнадёжно упущено?) Теперь приходится довольствоваться тем, чтобы освоить на должном профессиональном уровне хотя бы один язык программирования… Правда, многоязычие меня уже не пугает, а, скорее, привлекает.

Изобретения к этому не относятся.

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

Вы предлагаете всё заново перевести и изложить другими словами?

Здесь нужно определиться с тем, о чём речь: об информатике или о программировании.

Информатика — это наука о том, как нам представлять те или иные данные, как их хранить и как их обрабатывать. Здесь в дело идёт всё: от математической логики до языка структурированных запросов, от вычислительных структур до баз данных, от операционных систем до систем управления базами данных (и обратно). Информатика начинается в тот момент, когда мы пытаемся что-то закодировать, что-то куда-то передать, расшифровать и применить. Везде (на каждом шаге) возникают свои алгоритмы и способы их реализации. И всё это чрезвычайно интересно! И нужен талант Я.И.Перельмана, Бронштейна («Солнечное вещество») или Айзберга («Радио? Это очень просто!» и др. его книжки), быть может, Мартина Гарднера или Леона Купера (физика), для завлекательного и познавательного введения в предмет информатики. Я бы ещё вспомнил про Дональда Кнута (конкретно, его «Конкретная математика»))) и про Петцольда (его книга «Код»)…

В то же время, программирование — это средство для решения практических задач. Я бы поставил вопрос другим образом: если мы хотим решить задачу, нам нужен ясный алгоритм, который мы можем написать на псевдоязыке, но если мы хотим получить результат, то нам нужен конкретный язык программирования, компилятор/интерпретатор, среда разработки; что же нам помешает создать собственный язык программирования? В этом обучение программированию и может заключаться: в изобретении! Это как и с другими предметами: мы всегда повторяем путь предшественников, изобретая, например, вещественные и комплексные числа.

Но! Невозможно сочинять курс информатики в отрыве ото всего остального. Например, в школе было бы очень важным изучать, например, математическую логику. Да, и, вообще, логику, как таковую. И это не только вопрос владения «необходимым» и «достаточным». А ещё и знание и понимание наличия различных логик и различных исчислений. Я совершенно не понимаю, почему в обыкновенной школе не изучаются грамматики. Ведь, это чудовищно любопытно, как из ограниченного набора аксиом (термов) можно формировать сложные выражения.

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

В этом смысле, конкретные языки программирования, технологии и инструменты не так важны. Главный инструмент — это инструмент познания. Заставить мозги правильно структурированно работать. В конце концов, программа собственной жизни — это тоже программа и ошибки в её проектировании (и программировании) дорого обходятся самому человеку. (Могу засвидетельствовать сие на собственным примере: как много возможностей для получения важного опыта я пропустил, потому что толком не программировал свою жизнь, а, только, «латал» временные «дыры» наспех сделанными «заплатками» и объяснял собственные ошибки личностными «фичами». Но и тут можно внезапно отбросить все старые релизы и «перепрошить» собственный БИОС.)))

Бюрократия постоянно заставляет нас (людей) что-то писать. В том числе, и объяснительные записки. Может быть, ИИ уже давно изобретён и успешно действует?

Раньше (в советские времена) озвучивание фильмов занимало недели. Сейчас всё поставлено на поток. Могут озвучивать и за смену. Тут уже не до отбора актёров (раньше выбирали, почти как для реальной съёмки) и укладки (раньше укладчицу могли за ошибку и наказать).

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

А ещё, сейчас, нередко, актёрам озвучания не дают даже картинку, а, только, губы. И всё это — во избежание утечки копий и прочих «неприятностей». Во как!

И… сколько уже нет актёров, которых очень хорошо можно было слушать… Артём Карапетян, Юрий Волынцев, Анатолий Саранцев, Наталья Защипина, Надежда Румянцева, Ирина Губанова, Владимир Вихров, Виктор Петров, Алексей Инжеватов («Твин-Пикс» помните?), Алексей Борзунов…

А, уж, про актёрство за кадром актёры моли бы многое рассказать. Владимир Антоник, например, рассказывал о том, что было у Луи Де Фюнеса, и что сделал Кенигсон. Наоборот, если актёр просто пытается донести то, что есть на экране, то, может получиться и не очень хороший результат. В разных случаях — всё по разному.

А ещё бывает, что одно и тоже озвучивают несколько раз. Иногда это связано с авторскими правами. Иногда хочется «исправить» огрехи старого перевода. Но… становится, иногда, жалко, старые варианты. Был бы выбор (купить, например, старый фильм со старым кинотеатральным переоводом/озвучиванием, или, например, с новым), тогда — другое дело.

Примеры на Питоне мне очень нравятся и побуждают глубоко изучить этот язык программирования. Хотя, я уже очень давно выжил (именно так!) из школьного возраста. Но, правда, был бы рад вернуться в те годы, посмотреть на все свежим взглядом и со свежими силами броситься в омут практического программирования.

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

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

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

Всё это значит, во-первых, что главный навык программиста — это поиск изобразительных, адекватных задаче. А, во-вторых, это значит, что хорошо образованные программисты никогда не будут разводить «холиваров» ни по какому поводу, потому как, нет никаких «плохих» языков программирования, а есть только весьма различные изобразительные средства и умение грамотно ими пользоваться.

Единственное, что мне не очень понятно, почему, если язык программирования (например, Питон) предлагает довольно сильные изобразительные средства для краткого описания требуемых вычислительных концепций, именно этот язык не используется повсеместно? Почему нельзя сделать многоязычность неотъемлемой чертой разработки программного обеспечения? Почему нельзя, например, для скорости, безошибочности и максимальной управляемости создавать прототипы приложений на одних языках программирования (и с применением одних выразительных средств), а конечный код создавать в полуавтоматическом режиме из прототипа на других языках программирования (и с другими изобразительными средствами)?

Всё-таки, это было бы крайне интересно придумать новый учебник по информатике. Заинтересовать всех! Сделать красиво! Кто, как не хабровчание, смогут это сделать? Можно было бы совместными усилиями сделать. И для собственного удовольствия, и для того, чтобы было кого на работу брать.

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

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

Вот когда придумаете, тогда и будете говорить, что существующие подходы неправильные. Критикуешь — предлагай.

Полностью подписываюсь под каждым Вашим словом. Засим, разрешите эту тему закрыть. (На перучёт.)))

Большое спасибо за внимание и долготерпение.

Полностью подписываюсь под каждым Вашим словом. (Как, там, это называется? ПППКС?!?)))

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

Но системное решение заключается не в том, чтобы сразу дать под объект кучу битов или байтов («Бери пока дают!»), а в том, чтобы провести классификацию всех символов и найти для них оптимальное кодовое представление.

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

Но!

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

В этом смысле, вспоминается «Конкретная математика» Дональда Кнута, «Инофрматика» Бауэра и Гооза.

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

Правда, у любой монеты есть оборотная сторона. Если мы начинаем повышать планку, то как мы сможем её, затем, опустить. Ведь, самое сильное разочарование, которые получает выпускник школы и института, заключается в том, что на практике всё оказывается совершенно другим, чем в теории. Приходишь на работу, а том тебя просят забыть всё, что ты учил раньше, и учиться приходится совершенно новому делу (причем, именно, делу) и учиться совершенно заново.

Если бы можно было бы добиться, хотя бы, совпадения теории с практикой, то… была бы сделана добрая половина дела!

Я согласен. Возможно, я сильно задумываюсь над тем, над чем не очень-то и следует задумываться. (Наверное, лучше всего, разработать и реализовать нечто реальное и осязаемое.) Но мне удаётся видеть ситуацию немножко не стой стороны, с которой это ожидается.

Вот, Вы пишете:

Пример доработки — заказчик захотел поменять цвет кнопки «Купить» с синего на зеленый. Или передвинуть ее из девого угла в правый. Вы предлагаете это прописывать в стандарте предметной области?

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

Короче! Если ставить задачу ребром: можно ли разрабатывать программное обеспечение таким образом, чтобы 1) по сети всегда передавались только данные (исключением может быть только удалённая установка программного обеспечения); 2) само программное обеспечение хранилось бы у пользователя на компьютере в базе данных и управлялось бы операционной системой; 3) поставщики данных и услуг были бы освобождены от вопросов создания диалоговых форм?

Представьте себе, что Вы — торговая фирма. Вы берёте, входите в Сеть и… регистрируйтесь… как торговая фирма. Ваши контрагенты в Сети уже есть: Вы их находите и присоединяете к себе. Для этого нужен некий Единый План Счетов, где каждая такая операция описывается как проводка по определённому счёту. Например: «Связать клиента А с фирмой Б». Это будет, очевидно, семантически нагруженная связь, а это значит, что сетевая инфраструктура должна реализовывать семантические сети в качестве одного из базовых протоколов. И что, при этом, будет требовать реализации? Только понятие объектов, узлов, связей между ними и ролей объектов. Заметьте, это всё очень напоминает идею «трансвключения», когда между различными документами Сети создаётся «живая» связь, позволяющая условно говоря, включить содержание одного документа в другой документ. Гиперссылка, которая изначально предполагалась именно для трансвключения, реализует только лишь простой переход между документами…

К чему приведёт такая организация дела? Например, к тому, что, во-первых, никогда не возникнет вопроса о первичных ключах и уникальных идентификаторах, во-вторых, легко единообразно применить любую форму отчётности, и, в-третьих, все бюджеты будут направлены на поддержание оперативной деятельности, а не на обслуживание оной. А чем издательская деятельность отличается от торговли? А образовательная? А проведение научных исследований? Везде можно найти аналоги складов, измерений, разрезов и всевозможных «счетов»! (Не хотите ли 1C в мировом масштабе?)))) А если суть происходящего укладывается в «прокрустово ложе» неких стандартных абстрактных объектов, операций и схем, то реализовывать нужно слой именно этой «абстракции». В качестве основного слоя представления для операционной системы. А уже все остальные задачи строить над ним.

Да. Универсального решения нет. Я и не предлагаю. Но думать над этим полезно. Может быть, кто-нибудь додумается, как это всё сделать. Когда-нибудь.

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

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

P.S. Могу привести один пример такого «технологического» решения, о котором мало говорят, если сказать, не говорят совсем, или, иногда, говорят слишком много. В своё время для кодировки символов стали использовать один байт. Это породило большую проблему кодировок. А теперь представьте, что, в своё время, разработчики специально задались бы вопросом: а как нам надо представлять символы? Можно ли признать решение в один байт хорошим решением? Нет, нельзя. А в четыре байта? А в восемь байтов? Вопрос, ведь, не в количестве байтов, хотя в стародавние времена экономический аспект был одним из важнейших, если не самый главный. Вопрос в архитектуре. Есть простые символы национальных алфавитов, есть диакритика. Есть управляющие символы с кодами (ASKII от 0 до 31), есть цифры, есть символы псевдографики. Всё это просто взяли и сложили в единый диапазон от 0 до 255. И что? Unicode решило эту проблему? Лишь, частично! А, теперь, представьте, каким был бы мир (от клавиатуры до компиляторов и офисных пакетов), если бы было найдено системное решение. Например, взяли бы и кодировали бы каждый символ тройками: <тип символа, номер символа, начертание символа> (надо бы это всё хорошенько продумать!). При этом, можно было бы организовать память таким образом, чтобы под каждый элемент тройки отводить своё количество байтов или битов. Это же можно было бы создать что-то вроде XML, только на самом низком уровне представления информации!

Да, стрельба очередями приносит свои плоды…

Веб-сайт это система

«Холодно». Вы исходите из того, что есть сайт, и мы на него заходим. Я же исхожу из условий задачи и смотрю на это дело с противоположной стороны (я рассуждаю гипотетически, поэтому не навязываю своих правил): есть торговая система, а сайт — это просто некий узел доступа к этой системе. Для меня первичным является сама задача автоматизации торговли, и, если и может быть некий стандарт, то этот стандарт может быть связан именно с торговлей. По крайней мере, такой стандарт будет иметь смысл.

компонент операционной системы

Чуть «теплее». Но и здесь не очень понятно, что именно требует стандартизации. Гораздо важнее вопрос: а что такое компонент? Чем должен являться компонент.

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

Вот это уже гораздо ближе к делу и составляет предмет моего теоретического интереса.

Вернёмся к началу Вашей реплики.

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

Требования к чему? К тому, какие данные и в каком виде отображать? К тому, как именно организовывать операции?

Либо опишите стандарт, который учтет все возможные доработки, либо признайте, что доработки не являются ошибками проектирования.

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

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

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

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

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

Мне кажется, что, если мы действительно хотели бы реализовать такой компонент, то нам потребовалось бы иметь достаточно высокий уровень абстракции в трёх точках: 1) в операционной системе должен быть справочник под условным названием «Номенклатура», где была бы позиция «Комментарий»; 2) в Интернете должно быть единое адресное пространство комментариев (чтобы каждый комментарий мог бы быть или был бы полноценным сайтом), чтобы на каждый можно было бы сослаться (как здесь, на Хабре; само слово hab нас «провоцирует»); 3) поддержка со стороны протокола. Проблема всякого проектирования, на мой взгляд, в том и заключается, что мы пытаемся сделать локальную версию того, что должно быть реализовано глобально. Системный подход это и означает: Вы не можете сделать что-то одно, если не сделаете что-то другое…

Но это всё — тема большого разговора. Извините меня, пожалуйста, увлёкся. Больше не буду.

Довольно странный ответ. «С полной выкладкой» означает, что он должен выполнить все предписанные некоей неписанной методологией этапы. То есть, даже в простом случае, делать всё, что полагается делать в сложном случае. Чтобы не кусать локти, когда поезд уже ушёл. К тому же, многие большие приложения начинались с маленьких, поэтому в больших приложениях остаются все огрехи «туманной юности».

P.S. Если Вам не понятна реплика, спрашивайте, а не «минусуйте»: виноват, надо выражаться яснее. Но… юмор оценил.

А это хороший вопрос: как следует обучать программированию? Что является самом сложным в программировании? Наверное, самое сложное — это понять, что даже в простых случаях надо действовать с полной выкладкой. Разве проблемы проектирования (больших систем) не проистекают от того, что разработчики дали себе «слабину» ещё на этапе малых дел?

Возражаете, возражаете, а тут… Зачем кому-то мог бы понадобиться стандарт на сайт? Речь идёт о деятельности, которая не имеет никакого отношения к сайту. Если такой стандарт (на деятельность) есть, то что мешает запрограммировать его в виде компонента операционной системы? И зачем тогда нужен будет сайт? Нужен будет только поставщик данных и получатель данных.

А почему метод должен возвращать именно константу, обозначающую статус соединения? Кажется, что метод проверки валидности переданного значения должен возвращать булевское (логическое) значение TRUE/FALSE, а статус соединения — это должен быть отдельный объект. Логика здесь такая: если соединение установлено некорректно, то у него не может быть какого-либо собственного внутреннего статуса.

Менее тривиальный ответ получить можно? Гораздо интереснее обращаться к реальному собеседнику, который даст грамотный совет (что делать и что искать, например). Статья на Хабре может (и должна) хорошо сориентировать целеустремлённого соискателя полезного опыта. (Например.)

И это Вы говорите мне, который в студенческие времена хорошо ориентировался в различных пределах, сходимостях, свободно оперировал эпсилон-дельта-языком?!? Как я низко пал! Сколько надо восстанавливать: сплошные «бэд-сектора»!

Да! Было бы крайне любопытно узнать, какой есть хороший способ стать успешным фронтенд-разработчиком. Я, например, не имею никаких знаний в этой области. Чистая доска! (Если не считать давних попыток писать на чистом HTML и делать что-то на ASP.) Хочется написать на этой доске правильные письмена. Кто поможет?

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

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

Мне кажется во втором тезисе вы что-то перепутали)

Возможно. На истину в последней инстанции не претендую. Просто, мысли вслух.

Лично мне в библиотеках очень не хватает такой возможности, как получение печатного варианта требуемой мне информации в нужном мне виде.

Поясню о чём речь.

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

Другое дело, что, если всё находится в цифре, то удобнее всё получать по интернету. Но бумажный вариант часто удобнее электронного. (В плане утомляемости.)

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

На самом деле, бумажные копии нужно хранить как зеницу ока. И создавать многочисленные производные книги, содержащие всевозможные подборки публикаций. Вот на что должны быть направлены основные силы. Электричество недолговечно, а бумага может «стерпеть» много веков.

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

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

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

И ещё один момент, который мало кто учитывает. Реальные приложения — это некие «конструкции», которые возведены над ОС и другими «конструкциями». Строго говоря, нельзя возвести хорошее здание без хорошего фундамента. Но программисты всегда пользуются тем, что есть. А Вы попробуйте поставить вопрос: как должна выглядеть ОС, чтобы мы писали эффективные приложения? Но тогда выяснится, что разработчики ОС просто выдали какое-то своё решение и получили за это свои деньги, а как им будут пользоваться, не подумали: продали — и ладно. А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!

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

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

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

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

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

Зачем плодить сущности сверх необходимости?

Есть номинальные понятия, связанные с тем, какую функцию выполняет человек в определённый момент времени. Есть определённые позиции или вакансии. Вопрос в том, что является результатом своего труда.

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

Роли, здесь, не играют… никакой роли.

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

Да. Всё это должно быть так. Но, к сожалению, так происходит не всегда. Часто один и тот же человек вынужден совмещать различные функции.

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

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

P.S. Нет-нет-нет. Надо будет обязательно перечитать. Забыл. Но, сначала, следует хорошенько подумать самому. Математика тем хороша, что, если рассуждаешь логично, то, в итоге, приходишь к правильному результату. Так можно многое вывести. Надо, только, знать, что вспоминать.

Осталось изобрести неотключаемое электричество.

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

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