Здесь нужно определиться с тем, о чём речь: об информатике или о программировании.
Информатика — это наука о том, как нам представлять те или иные данные, как их хранить и как их обрабатывать. Здесь в дело идёт всё: от математической логики до языка структурированных запросов, от вычислительных структур до баз данных, от операционных систем до систем управления базами данных (и обратно). Информатика начинается в тот момент, когда мы пытаемся что-то закодировать, что-то куда-то передать, расшифровать и применить. Везде (на каждом шаге) возникают свои алгоритмы и способы их реализации. И всё это чрезвычайно интересно! И нужен талант Я.И.Перельмана, Бронштейна («Солнечное вещество») или Айзберга («Радио? Это очень просто!» и др. его книжки), быть может, Мартина Гарднера или Леона Купера (физика), для завлекательного и познавательного введения в предмет информатики. Я бы ещё вспомнил про Дональда Кнута (конкретно, его «Конкретная математика»))) и про Петцольда (его книга «Код»)…
В то же время, программирование — это средство для решения практических задач. Я бы поставил вопрос другим образом: если мы хотим решить задачу, нам нужен ясный алгоритм, который мы можем написать на псевдоязыке, но если мы хотим получить результат, то нам нужен конкретный язык программирования, компилятор/интерпретатор, среда разработки; что же нам помешает создать собственный язык программирования? В этом обучение программированию и может заключаться: в изобретении! Это как и с другими предметами: мы всегда повторяем путь предшественников, изобретая, например, вещественные и комплексные числа.
Но! Невозможно сочинять курс информатики в отрыве ото всего остального. Например, в школе было бы очень важным изучать, например, математическую логику. Да, и, вообще, логику, как таковую. И это не только вопрос владения «необходимым» и «достаточным». А ещё и знание и понимание наличия различных логик и различных исчислений. Я совершенно не понимаю, почему в обыкновенной школе не изучаются грамматики. Ведь, это чудовищно любопытно, как из ограниченного набора аксиом (термов) можно формировать сложные выражения.
И ещё. Школа не может дать систематических представлений, потому что для систематических представлений нужна база. Для того, чтобы что-то познать, нужно уже это как-то «предзнать». Вот, школа и даёт это предзнание. И тут самое важное — это опыт. Этот опыт (который, «сын ошибок трудных»), а, точнее, труд — и есть самое главное. Таким образом, основная задача — сделать систематическим организацию труда.
В этом смысле, конкретные языки программирования, технологии и инструменты не так важны. Главный инструмент — это инструмент познания. Заставить мозги правильно структурированно работать. В конце концов, программа собственной жизни — это тоже программа и ошибки в её проектировании (и программировании) дорого обходятся самому человеку. (Могу засвидетельствовать сие на собственным примере: как много возможностей для получения важного опыта я пропустил, потому что толком не программировал свою жизнь, а, только, «латал» временные «дыры» наспех сделанными «заплатками» и объяснял собственные ошибки личностными «фичами». Но и тут можно внезапно отбросить все старые релизы и «перепрошить» собственный БИОС.)))
Бюрократия постоянно заставляет нас (людей) что-то писать. В том числе, и объяснительные записки. Может быть, ИИ уже давно изобретён и успешно действует?
Раньше (в советские времена) озвучивание фильмов занимало недели. Сейчас всё поставлено на поток. Могут озвучивать и за смену. Тут уже не до отбора актёров (раньше выбирали, почти как для реальной съёмки) и укладки (раньше укладчицу могли за ошибку и наказать).
Раньше была хорошая школа и новые поколения актёров учились мастерству у старших. Сейчас всё размылось. Отдельные исключения есть, но это и есть исключения. К тому же, сейчас, легко могут взять на озвучивание хорошо раскрученных медийных персонажей, а не профессиональных актёров.
А ещё, сейчас, нередко, актёрам озвучания не дают даже картинку, а, только, губы. И всё это — во избежание утечки копий и прочих «неприятностей». Во как!
И… сколько уже нет актёров, которых очень хорошо можно было слушать… Артём Карапетян, Юрий Волынцев, Анатолий Саранцев, Наталья Защипина, Надежда Румянцева, Ирина Губанова, Владимир Вихров, Виктор Петров, Алексей Инжеватов («Твин-Пикс» помните?), Алексей Борзунов…
А, уж, про актёрство за кадром актёры моли бы многое рассказать. Владимир Антоник, например, рассказывал о том, что было у Луи Де Фюнеса, и что сделал Кенигсон. Наоборот, если актёр просто пытается донести то, что есть на экране, то, может получиться и не очень хороший результат. В разных случаях — всё по разному.
А ещё бывает, что одно и тоже озвучивают несколько раз. Иногда это связано с авторскими правами. Иногда хочется «исправить» огрехи старого перевода. Но… становится, иногда, жалко, старые варианты. Был бы выбор (купить, например, старый фильм со старым кинотеатральным переоводом/озвучиванием, или, например, с новым), тогда — другое дело.
Примеры на Питоне мне очень нравятся и побуждают глубоко изучить этот язык программирования. Хотя, я уже очень давно выжил (именно так!) из школьного возраста. Но, правда, был бы рад вернуться в те годы, посмотреть на все свежим взглядом и со свежими силами броситься в омут практического программирования.
То, что касается обучения, то мне более всего нравится многоязычный подход. Как, например, в Вашем сообщении. Я бы так и писал учебник по программированию, приводя примеры различных реализаций одного и того же.
Сам алгоритм, конечно, удобнее описывать на некотором псевдокоде, свободном от синтаксических условностей конкретного языка программирования. Зато, сравнительный анализ реализаций одного и того же алгоритма на различных языках программирования способен дать очень много пиши для размышлений и создать в голове обучающегося некие вехи или опорные точки.
С одной стороны, алгоритм — это некий инвариант, который реализуется в целом, а реализации различаются, только, лишь, набором изобразительных средств, которые весьма различны в различных языках программирования. С другой стороны, мы никогда не имеем алгоритм в чистом виде, а только его реализацию, которая полностью обуславливает поведение программы, где используется реализованный алгоритм.
Всё это значит, во-первых, что главный навык программиста — это поиск изобразительных, адекватных задаче. А, во-вторых, это значит, что хорошо образованные программисты никогда не будут разводить «холиваров» ни по какому поводу, потому как, нет никаких «плохих» языков программирования, а есть только весьма различные изобразительные средства и умение грамотно ими пользоваться.
Единственное, что мне не очень понятно, почему, если язык программирования (например, Питон) предлагает довольно сильные изобразительные средства для краткого описания требуемых вычислительных концепций, именно этот язык не используется повсеместно? Почему нельзя сделать многоязычность неотъемлемой чертой разработки программного обеспечения? Почему нельзя, например, для скорости, безошибочности и максимальной управляемости создавать прототипы приложений на одних языках программирования (и с применением одних выразительных средств), а конечный код создавать в полуавтоматическом режиме из прототипа на других языках программирования (и с другими изобразительными средствами)?
Всё-таки, это было бы крайне интересно придумать новый учебник по информатике. Заинтересовать всех! Сделать красиво! Кто, как не хабровчание, смогут это сделать? Можно было бы совместными усилиями сделать. И для собственного удовольствия, и для того, чтобы было кого на работу брать.
И если вы вместо того, чтобы спрашивать, подумаете, как именно это сделать, то поймете почему.
Да, было бы очень заманчиво додумать мысль до конца и либо, всё-таки, сделать что-то осмысленное и предъявить сие благородному сообществу, либо признать ошибочность собственных посылок и представлений. В любом случае, вариант беспроигрышный.
Вот когда придумаете, тогда и будете говорить, что существующие подходы неправильные. Критикуешь — предлагай.
Полностью подписываюсь под каждым Вашим словом. Засим, разрешите эту тему закрыть. (На перучёт.)))
Полностью подписываюсь под каждым Вашим словом. (Как, там, это называется? ПППКС?!?)))
Маленькое примечание. Когда появилась возможность использовать большие объёмы памяти, имело бы смысл делать новые компьютеры, и делать их на новых принципах. Но, поскольку, ничего этого сделано не было, всё, что мы имеем сегодня, суть наследие прошлого. Со всеми вытекающими.
Но системное решение заключается не в том, чтобы сразу дать под объект кучу битов или байтов («Бери пока дают!»), а в том, чтобы провести классификацию всех символов и найти для них оптимальное кодовое представление.
Тут всё очень противоречиво. Школа, сама по себе, даёт только общие представления и призвана, в основном, научить думать, решать задачи, искать информацию и целенаправленно работать. С другой стороны, ученики делает свои проекты. Нынешним школьникам, которые растут вместе с гаджетами, легко разбираться с языками программирования и средствами разработки. Чего же хотят от образования? Обеспечить всех потенциальных работников общей высокой математической культурой (дискретная математика+теория алгоритмов+схемотехника) и культурой ведения проектов (чтобы все создавали программное обеспечение по единым лекалам, а не на коленке)? Вузы, вообще, живут по своим общеобразовательным стандартам и выполняют определённые учебные планы. И… чему учить? Программированию вообще или проектированию в определённой среде разработки? Всё-равно, программированию нельзя научиться, наблюдая как это делают другие.
Но!
Можно обратить внимание школьника на то, сколько вокруг нас разных алгоритмов! Везде выполняются какие-то операции. Есть определённые последовательности действий. И что многое можно посчитать!
В этом смысле, вспоминается «Конкретная математика» Дональда Кнута, «Инофрматика» Бауэра и Гооза.
А, вообще, информатика начинается с такой задачи как кодирование, передача информации и системы организации хранения данных. Было бы крайне любопытно создать такой синтетический вводный курс в информатику.
Правда, у любой монеты есть оборотная сторона. Если мы начинаем повышать планку, то как мы сможем её, затем, опустить. Ведь, самое сильное разочарование, которые получает выпускник школы и института, заключается в том, что на практике всё оказывается совершенно другим, чем в теории. Приходишь на работу, а том тебя просят забыть всё, что ты учил раньше, и учиться приходится совершенно новому делу (причем, именно, делу) и учиться совершенно заново.
Если бы можно было бы добиться, хотя бы, совпадения теории с практикой, то… была бы сделана добрая половина дела!
Я согласен. Возможно, я сильно задумываюсь над тем, над чем не очень-то и следует задумываться. (Наверное, лучше всего, разработать и реализовать нечто реальное и осязаемое.) Но мне удаётся видеть ситуацию немножко не стой стороны, с которой это ожидается.
Вот, Вы пишете:
Пример доработки — заказчик захотел поменять цвет кнопки «Купить» с синего на зеленый. Или передвинуть ее из девого угла в правый. Вы предлагаете это прописывать в стандарте предметной области?
У меня сразу же в такой ситуации возникает вопрос: а почему заказчика, вообще, интересует цвет кнопки и её местоположение на форме? Да, я понимаю, что заказчик заинтересован в хорошей подаче и хорошей отдаче. Но что будет, если оформление всегда будет определяться конечным пользователем, а заказчик будет только получать запросы на получение конкретных данных и отдавать такие конкретные данные?
Короче! Если ставить задачу ребром: можно ли разрабатывать программное обеспечение таким образом, чтобы 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.) Хочется написать на этой доске правильные письмена. Кто поможет?
Вот это-то меня и беспокоит: когда меняется представление о том, «как надо». Если бы для каждого вида деятельности существовал некий стандарт, и все неукоснительно соблюдали бы выбранный стандарт, то разработчикам не надо было бы общаться с клиентами, а, просто, брать готовый стандарт и реализовывать именно его. Но, это так, мои мысли вслух, заметки, так сказать, на полях.
Информатика — это наука о том, как нам представлять те или иные данные, как их хранить и как их обрабатывать. Здесь в дело идёт всё: от математической логики до языка структурированных запросов, от вычислительных структур до баз данных, от операционных систем до систем управления базами данных (и обратно). Информатика начинается в тот момент, когда мы пытаемся что-то закодировать, что-то куда-то передать, расшифровать и применить. Везде (на каждом шаге) возникают свои алгоритмы и способы их реализации. И всё это чрезвычайно интересно! И нужен талант Я.И.Перельмана, Бронштейна («Солнечное вещество») или Айзберга («Радио? Это очень просто!» и др. его книжки), быть может, Мартина Гарднера или Леона Купера (физика), для завлекательного и познавательного введения в предмет информатики. Я бы ещё вспомнил про Дональда Кнута (конкретно, его «Конкретная математика»))) и про Петцольда (его книга «Код»)…
В то же время, программирование — это средство для решения практических задач. Я бы поставил вопрос другим образом: если мы хотим решить задачу, нам нужен ясный алгоритм, который мы можем написать на псевдоязыке, но если мы хотим получить результат, то нам нужен конкретный язык программирования, компилятор/интерпретатор, среда разработки; что же нам помешает создать собственный язык программирования? В этом обучение программированию и может заключаться: в изобретении! Это как и с другими предметами: мы всегда повторяем путь предшественников, изобретая, например, вещественные и комплексные числа.
Но! Невозможно сочинять курс информатики в отрыве ото всего остального. Например, в школе было бы очень важным изучать, например, математическую логику. Да, и, вообще, логику, как таковую. И это не только вопрос владения «необходимым» и «достаточным». А ещё и знание и понимание наличия различных логик и различных исчислений. Я совершенно не понимаю, почему в обыкновенной школе не изучаются грамматики. Ведь, это чудовищно любопытно, как из ограниченного набора аксиом (термов) можно формировать сложные выражения.
И ещё. Школа не может дать систематических представлений, потому что для систематических представлений нужна база. Для того, чтобы что-то познать, нужно уже это как-то «предзнать». Вот, школа и даёт это предзнание. И тут самое важное — это опыт. Этот опыт (который, «сын ошибок трудных»), а, точнее, труд — и есть самое главное. Таким образом, основная задача — сделать систематическим организацию труда.
В этом смысле, конкретные языки программирования, технологии и инструменты не так важны. Главный инструмент — это инструмент познания. Заставить мозги правильно структурированно работать. В конце концов, программа собственной жизни — это тоже программа и ошибки в её проектировании (и программировании) дорого обходятся самому человеку. (Могу засвидетельствовать сие на собственным примере: как много возможностей для получения важного опыта я пропустил, потому что толком не программировал свою жизнь, а, только, «латал» временные «дыры» наспех сделанными «заплатками» и объяснял собственные ошибки личностными «фичами». Но и тут можно внезапно отбросить все старые релизы и «перепрошить» собственный БИОС.)))
Раньше была хорошая школа и новые поколения актёров учились мастерству у старших. Сейчас всё размылось. Отдельные исключения есть, но это и есть исключения. К тому же, сейчас, легко могут взять на озвучивание хорошо раскрученных медийных персонажей, а не профессиональных актёров.
А ещё, сейчас, нередко, актёрам озвучания не дают даже картинку, а, только, губы. И всё это — во избежание утечки копий и прочих «неприятностей». Во как!
И… сколько уже нет актёров, которых очень хорошо можно было слушать… Артём Карапетян, Юрий Волынцев, Анатолий Саранцев, Наталья Защипина, Надежда Румянцева, Ирина Губанова, Владимир Вихров, Виктор Петров, Алексей Инжеватов («Твин-Пикс» помните?), Алексей Борзунов…
А, уж, про актёрство за кадром актёры моли бы многое рассказать. Владимир Антоник, например, рассказывал о том, что было у Луи Де Фюнеса, и что сделал Кенигсон. Наоборот, если актёр просто пытается донести то, что есть на экране, то, может получиться и не очень хороший результат. В разных случаях — всё по разному.
А ещё бывает, что одно и тоже озвучивают несколько раз. Иногда это связано с авторскими правами. Иногда хочется «исправить» огрехи старого перевода. Но… становится, иногда, жалко, старые варианты. Был бы выбор (купить, например, старый фильм со старым кинотеатральным переоводом/озвучиванием, или, например, с новым), тогда — другое дело.
То, что касается обучения, то мне более всего нравится многоязычный подход. Как, например, в Вашем сообщении. Я бы так и писал учебник по программированию, приводя примеры различных реализаций одного и того же.
Сам алгоритм, конечно, удобнее описывать на некотором псевдокоде, свободном от синтаксических условностей конкретного языка программирования. Зато, сравнительный анализ реализаций одного и того же алгоритма на различных языках программирования способен дать очень много пиши для размышлений и создать в голове обучающегося некие вехи или опорные точки.
С одной стороны, алгоритм — это некий инвариант, который реализуется в целом, а реализации различаются, только, лишь, набором изобразительных средств, которые весьма различны в различных языках программирования. С другой стороны, мы никогда не имеем алгоритм в чистом виде, а только его реализацию, которая полностью обуславливает поведение программы, где используется реализованный алгоритм.
Всё это значит, во-первых, что главный навык программиста — это поиск изобразительных, адекватных задаче. А, во-вторых, это значит, что хорошо образованные программисты никогда не будут разводить «холиваров» ни по какому поводу, потому как, нет никаких «плохих» языков программирования, а есть только весьма различные изобразительные средства и умение грамотно ими пользоваться.
Единственное, что мне не очень понятно, почему, если язык программирования (например, Питон) предлагает довольно сильные изобразительные средства для краткого описания требуемых вычислительных концепций, именно этот язык не используется повсеместно? Почему нельзя сделать многоязычность неотъемлемой чертой разработки программного обеспечения? Почему нельзя, например, для скорости, безошибочности и максимальной управляемости создавать прототипы приложений на одних языках программирования (и с применением одних выразительных средств), а конечный код создавать в полуавтоматическом режиме из прототипа на других языках программирования (и с другими изобразительными средствами)?
Большое спасибо за внимание и долготерпение.
Маленькое примечание. Когда появилась возможность использовать большие объёмы памяти, имело бы смысл делать новые компьютеры, и делать их на новых принципах. Но, поскольку, ничего этого сделано не было, всё, что мы имеем сегодня, суть наследие прошлого. Со всеми вытекающими.
Но системное решение заключается не в том, чтобы сразу дать под объект кучу битов или байтов («Бери пока дают!»), а в том, чтобы провести классификацию всех символов и найти для них оптимальное кодовое представление.
Но!
Можно обратить внимание школьника на то, сколько вокруг нас разных алгоритмов! Везде выполняются какие-то операции. Есть определённые последовательности действий. И что многое можно посчитать!
В этом смысле, вспоминается «Конкретная математика» Дональда Кнута, «Инофрматика» Бауэра и Гооза.
А, вообще, информатика начинается с такой задачи как кодирование, передача информации и системы организации хранения данных. Было бы крайне любопытно создать такой синтетический вводный курс в информатику.
Правда, у любой монеты есть оборотная сторона. Если мы начинаем повышать планку, то как мы сможем её, затем, опустить. Ведь, самое сильное разочарование, которые получает выпускник школы и института, заключается в том, что на практике всё оказывается совершенно другим, чем в теории. Приходишь на работу, а том тебя просят забыть всё, что ты учил раньше, и учиться приходится совершенно новому делу (причем, именно, делу) и учиться совершенно заново.
Если бы можно было бы добиться, хотя бы, совпадения теории с практикой, то… была бы сделана добрая половина дела!
Вот, Вы пишете: У меня сразу же в такой ситуации возникает вопрос: а почему заказчика, вообще, интересует цвет кнопки и её местоположение на форме? Да, я понимаю, что заказчик заинтересован в хорошей подаче и хорошей отдаче. Но что будет, если оформление всегда будет определяться конечным пользователем, а заказчик будет только получать запросы на получение конкретных данных и отдавать такие конкретные данные?
Короче! Если ставить задачу ребром: можно ли разрабатывать программное обеспечение таким образом, чтобы 1) по сети всегда передавались только данные (исключением может быть только удалённая установка программного обеспечения); 2) само программное обеспечение хранилось бы у пользователя на компьютере в базе данных и управлялось бы операционной системой; 3) поставщики данных и услуг были бы освобождены от вопросов создания диалоговых форм?
Представьте себе, что Вы — торговая фирма. Вы берёте, входите в Сеть и… регистрируйтесь… как торговая фирма. Ваши контрагенты в Сети уже есть: Вы их находите и присоединяете к себе. Для этого нужен некий Единый План Счетов, где каждая такая операция описывается как проводка по определённому счёту. Например: «Связать клиента А с фирмой Б». Это будет, очевидно, семантически нагруженная связь, а это значит, что сетевая инфраструктура должна реализовывать семантические сети в качестве одного из базовых протоколов. И что, при этом, будет требовать реализации? Только понятие объектов, узлов, связей между ними и ролей объектов. Заметьте, это всё очень напоминает идею «трансвключения», когда между различными документами Сети создаётся «живая» связь, позволяющая условно говоря, включить содержание одного документа в другой документ. Гиперссылка, которая изначально предполагалась именно для трансвключения, реализует только лишь простой переход между документами…
К чему приведёт такая организация дела? Например, к тому, что, во-первых, никогда не возникнет вопроса о первичных ключах и уникальных идентификаторах, во-вторых, легко единообразно применить любую форму отчётности, и, в-третьих, все бюджеты будут направлены на поддержание оперативной деятельности, а не на обслуживание оной. А чем издательская деятельность отличается от торговли? А образовательная? А проведение научных исследований? Везде можно найти аналоги складов, измерений, разрезов и всевозможных «счетов»! (Не хотите ли 1C в мировом масштабе?)))) А если суть происходящего укладывается в «прокрустово ложе» неких стандартных абстрактных объектов, операций и схем, то реализовывать нужно слой именно этой «абстракции». В качестве основного слоя представления для операционной системы. А уже все остальные задачи строить над ним.
Да. Универсального решения нет. Я и не предлагаю. Но думать над этим полезно. Может быть, кто-нибудь додумается, как это всё сделать. Когда-нибудь.
(Однако, изначально, я смел виду гораздо более простой вариант «выкладки», когда мы формализуем все свои шаги, ничего не держим в голове, и делаем, даже, если делаем только для себя, делаем так, как если бы делали это для других.)
P.S. Могу привести один пример такого «технологического» решения, о котором мало говорят, если сказать, не говорят совсем, или, иногда, говорят слишком много. В своё время для кодировки символов стали использовать один байт. Это породило большую проблему кодировок. А теперь представьте, что, в своё время, разработчики специально задались бы вопросом: а как нам надо представлять символы? Можно ли признать решение в один байт хорошим решением? Нет, нельзя. А в четыре байта? А в восемь байтов? Вопрос, ведь, не в количестве байтов, хотя в стародавние времена экономический аспект был одним из важнейших, если не самый главный. Вопрос в архитектуре. Есть простые символы национальных алфавитов, есть диакритика. Есть управляющие символы с кодами (ASKII от 0 до 31), есть цифры, есть символы псевдографики. Всё это просто взяли и сложили в единый диапазон от 0 до 255. И что? Unicode решило эту проблему? Лишь, частично! А, теперь, представьте, каким был бы мир (от клавиатуры до компиляторов и офисных пакетов), если бы было найдено системное решение. Например, взяли бы и кодировали бы каждый символ тройками: <тип символа, номер символа, начертание символа> (надо бы это всё хорошенько продумать!). При этом, можно было бы организовать память таким образом, чтобы под каждый элемент тройки отводить своё количество байтов или битов. Это же можно было бы создать что-то вроде XML, только на самом низком уровне представления информации!
Вернёмся к началу Вашей реплики.Требования к чему? К тому, какие данные и в каком виде отображать? К тому, как именно организовывать операции?Если бы (обратите внимание на эту важную оговорку «если бы»!) у нас был стандарт проведения операций (для определённой предметной области), то этот стандарт (единожды прописанный) мог бы быть один раз реализован без необходимости каких-либо доработок.Это не стандарт на производство программного обеспечения, это стандарт, в формализованном виде описывающий предметную область, модель предметной области. Весь вопрос в том, можно ли построить полную модель предметной области. Но если мы пытаемся строить такую модель, то мы, по моему скромному мнению, однажды придём к пониманию того, что такая модель должна быть органической частью операционной системы и использоваться для работы со всеми торговыми площадками, а сайты окажутся, в таком случае, простыми адресами для подключения к удалённому источнику/приёмнику данных. При такой «бизнес-модели», предприятия концентрируются исключительно на самой торговой деятельности, все IT-отделы на предприятиях упраздняются, остаются только грамотные OPS-ы, которые администрируют хранилища оперативных и аналитических данных, а то, как именно отображается информация и оформляется доступ к операциям, оставляется конечному пользователю.
Теперь, вернёмся в конец и прочитаем следующую реплику в качестве постановки задачи:Мне кажется, что, если мы действительно хотели бы реализовать такой компонент, то нам потребовалось бы иметь достаточно высокий уровень абстракции в трёх точках: 1) в операционной системе должен быть справочник под условным названием «Номенклатура», где была бы позиция «Комментарий»; 2) в Интернете должно быть единое адресное пространство комментариев (чтобы каждый комментарий мог бы быть или был бы полноценным сайтом), чтобы на каждый можно было бы сослаться (как здесь, на Хабре; само слово hab нас «провоцирует»); 3) поддержка со стороны протокола. Проблема всякого проектирования, на мой взгляд, в том и заключается, что мы пытаемся сделать локальную версию того, что должно быть реализовано глобально. Системный подход это и означает: Вы не можете сделать что-то одно, если не сделаете что-то другое…
Но это всё — тема большого разговора. Извините меня, пожалуйста, увлёкся. Больше не буду.
P.S. Если Вам не понятна реплика, спрашивайте, а не «минусуйте»: виноват, надо выражаться яснее. Но… юмор оценил.