Спасибо за ссылку. Однако, я имел в виду вариант прототипирования целых предприятий, чтобы иметь возможность «прокрутить» систему на полигоне. (Или Вы предлагаете что-то вроде «13-го этажа», то есть за полную симуляцию окружающего мира?)
Лично мне в библиотеках очень не хватает такой возможности, как получение печатного варианта требуемой мне информации в нужном мне виде.
Поясню о чём речь.
В обычной ситуации, если у Вас есть подборка библиографических ссылок, то Вам приходится запрашивать все издания. Более того, если есть журнал, то хочется посмотреть все публикации одного автора. Было бы удобно взять в библиотеке отдельную книгу, которая, разумеется, печатается прямо в библиотеке по требованию читателя.
Другое дело, что, если всё находится в цифре, то удобнее всё получать по интернету. Но бумажный вариант часто удобнее электронного. (В плане утомляемости.)
В действительности, библиотекам угрожает только пресловутый копирайт. А то получается, что в библиотеке, в отрытом доступе лежит то, что на сайте издательства требует немалой оплаты. В то же время, есть определённый аромат в том, чтобы пройтись вдоль полок и по дороге узнать много нового, что в электронном варианте не так просто сделать.
На самом деле, бумажные копии нужно хранить как зеницу ока. И создавать многочисленные производные книги, содержащие всевозможные подборки публикаций. Вот на что должны быть направлены основные силы. Электричество недолговечно, а бумага может «стерпеть» много веков.
И, конечно, вечная проблема каталогов и каталогизации. Вот я в юную пору активно пользовался библиотекой им. Маяковского (г. Санкт-Петербург). Так вот, там до сих пор книги по программированию лежат в открытом доступе в большой куче, расположенные по алфавиту (без разделения на языки программирования, общие вопросы и инструменты разработки). Как повелось ещё в советские годы, таки осталось. В этом смысле, библиотечное дело крайне консервативное. Вот где нужны специалисты по информатике: чтобы показать оптимальный способ расположения книг, оптимальный способ описания книг и оптимальный способ поиска нужных книг. (И все это при наличии некоего оптимального способа написания книг, чтобы было больше нужного и полезного.)
А Всемирной библиотекой должен был стать интернет, где у каждой книжки, у каждого издания, у каждого текста, у каждой публикации, у каждого автора, была бы своя страница (как единое адресное пространство), и всё было бы едино, а читатель всегда мог бы доехать до библиотеки, чтобы собственными глазами увидеть то, для чего ему мало электронного варианта.
А, разве, со временем отличия не скрадываются? Не получается так, что промышленная команда (в погоне за гибкостью или, наоборот, за системностью) начинает походить на «гаражного программиста»? Когда какая-то промышленным образом разработанная система требует постоянной доработки, то, просто, мало кто воспринимает это негативно. Как можно выпустить «сырой» программный продукт? Это, конечно, сильный ход — сделать доработку частью жизненного цикла системы. Но, получается, что исправление ошибок проектирования выносится на этап эксплуатации. В реальных конструкторских разработках, хотя бы, используются натурные и полунатурные эксперименты. А в программировании таких экспериментов нет. Всё по живому.
И ещё один момент, который мало кто учитывает. Реальные приложения — это некие «конструкции», которые возведены над ОС и другими «конструкциями». Строго говоря, нельзя возвести хорошее здание без хорошего фундамента. Но программисты всегда пользуются тем, что есть. А Вы попробуйте поставить вопрос: как должна выглядеть ОС, чтобы мы писали эффективные приложения? Но тогда выяснится, что разработчики ОС просто выдали какое-то своё решение и получили за это свои деньги, а как им будут пользоваться, не подумали: продали — и ладно. А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!
А теперь, внимание, вопрос: что будет, если, даже, создание простых программ (программ, решающих отдельные простые задачи) будет полноценной разработкой? Я усматриваю, здесь, корень проблемы. Если этого разделения не было бы, и мы относились с одинаковым вниманием к задачам различной сложности, то избежали бы множества ловушек и делали бы ПО высочайшего качества.
Во-первых, в любую минуту может придти Некто, кто попросит даже в самом простом приложении прикрутить «вот эту фичу». Современные монструозные программы (ставшие целыми пакетами!) начинались с маленьких программок.
Во-вторых, Вы всегда будете думать о том, что было бы, если бы у Вас была готовая инфраструктура для создания различных приложений, наличие которой гарантировало бы Вам определённый (высокий) уровень качества программного кода. Сколько было за последние 30 лет предложено всевозможных «фреймвёрков», многие из которых уже давно исчезли из обихода? А если бы эта инфраструктура была бы ещё и частью ОС?
В-третьих, всегда возникает соблазн разбить большие приложения на маленькие. Зачем же мы создавали многофункциональное устройство, чтобы разрезать его на части? Может быть, было бы логичнее, иметь набор маленьких приложений, решающих маленькие задачи, и средство для сборки маленьких приложений для решения больших задач по требованию пользователя (в рамках ОС).
Только, где мы найдём таких разработчиков, которые смогут выявить эти самые элементарные кирпичики и составить из них полноцветные мозаики? На этот вопрос статья ответа не даёт.
Есть номинальные понятия, связанные с тем, какую функцию выполняет человек в определённый момент времени. Есть определённые позиции или вакансии. Вопрос в том, что является результатом своего труда.
Если результатом труда является программа, то речь идёт о программировании. В конце-концов, программа (в самом широком смысле) — это упорядоченная (в том числе, и во времени) совокупность предписаний, что и когда делать, позволяющая перевести систему из одного положения (полное отсутствие автоматизации) в другое (полная автоматизация всех бизнес-процессов).
Роли, здесь, не играют… никакой роли.
Хорошие программисты могут, конечно, между собою называть плохих программистов «кодерами», но особого смысла в этом нет. Другое дело, что в программировании для большинства программистов можно найти более продвинутых программистов, умеющих что-то ещё. В итоге, хороший программист — это тот прграммист, который знает, что ему всегда надо узнать что-то ещё. В этом смысле, все классификации заведомо слабы, поскольку никак не учитывают живую природу человека, который, если он не бездельник, завтра будет, уж точно не таким, как вчера.
Да. Всё это должно быть так. Но, к сожалению, так происходит не всегда. Часто один и тот же человек вынужден совмещать различные функции.
Но, лучше не «спотыкаться о термины», а говорить о том, что можно и нужно писать хорошие программы, а можно (хотя и это неприемлемо) писать плохие. Можно расписать красивую структуру требований и подзадач, но ошибиться в анализе и промахнуться в реализации. Недаром, говориться «Семь раз отмерь...». Кто же просит программиста стразу резать? Никто. Только он сам.
Смутно вспоминаю теорему о том, что функция, непрерывная на отрезке, интегририуема на нём. Наверное, это как-то связано с тем, что, что функция, непрерывная на отрезке, равномерно непрерывна на нём. Это значит, что мы можем для всякого положительного эпсилон разбить отрезок на части так, чтобы колебание в пределах каждой части не превосходило заранее заданное эпсилон. Отсюда следует, что нарушение интегрируемости связано, в свою очередь, с нарушением только что приведённого условия.
P.S. Нет-нет-нет. Надо будет обязательно перечитать. Забыл. Но, сначала, следует хорошенько подумать самому. Математика тем хороша, что, если рассуждаешь логично, то, в итоге, приходишь к правильному результату. Так можно многое вывести. Надо, только, знать, что вспоминать.
Всё уже напрочь забылось (мною). Придётся вспоминать. А когда-то я это всё хорошо знал… Любая ли непрерывная функция является интегрируемой? (Обычно, уточняют, ещё, по Риману или по Лебегу.) Крепко задумался…
Хотелось бы всё это самому проверить в деле и почувствовать. Как это всё рисуется? Где именно происходит «отрисовка»?
А ещё хотелось бы знать, кто-нибудь питался приспособить эти фракталы к распознаванию образов? Я имею в виду хитрое (существенно нелинейное) разбиение признакового пространства, которое позволяет обойти гипотезу компактности. Ведь, реально объекты различных классов существенно «зацеплены» друг за друга, и любые классификаторы будут, очевидно, существенно «ошибаться».
Почему-то вспоминается совет-наставление, которое давали на курсах по 1С: структура регистров должна быть заточена под будущие отчёты: каковы отчёты, таковы и должны быть регистры. Если есть возможность предусмотреть специальный регистр, который помогает составлять некоторый отчёт, то этот регистр обязательно нужно создавать. Ну и, конечно, никому не помешает универсальный совет: составляйте изначально максимально оптимальные запросы к базе данных. Если есть возможность сделать внешнее соединение, то его обязательно нужно сделать. Была бы таблица (например, регистр), а соединение найдётся.
На мой чисто субъективный взгляд, возможность совместить быструю разработку и высокую производительность можно будет успешно решить только, если часть технологической платформы встроить в операционную систему (что кажется довольно логичным). Монолитность программного обеспечения порождает проблемы. Но ещё никто не сказал, что нельзя сделать само отображение предметной области на объектную модель данных эффективнее чем это сделано, например, в 1С.
В случае с 1С, правда, срабатывает ещё и такой аргумент: лучше медленная, но прозрачная и, значит, управляемая система с устоявшейся терминологией и устоявшимся рынком поддержки, чем шустрая система с постоянно меняющейся терминологией и без толковой службы поддержки. Я могу ошибаться, но, я думаю, что консерватизм нередко заставляет отказываться от более эффективного в пользу более привычного.
Картинка красивая, но вызывает чувства противоречивые. С одной стороны, хочется присоединиться к лидеру. С другой — потеснить его. Если говорит серьёзно, то с чем в этом списке присутствует Microsoft? Как это у них называется? Аксапта? Навижн? А Oracle? Ещё я слышал когда-то о Компасе. У них тоже, вроде, есть какая-то своя типология объектов предметной области?
Я думал, что такие проблемы решаются на уровне СУБД. По моим (правда, сильно устаревшим) представлениям, регистры более всего «заточены» именно под постоянное добавление новых данных. Да, регистры сведений предусматривают перезапись. Но без полного и точного описания Вашей конкретной ситуации, трудно понять, что лучше всего следует делать. Может быть, Вам нужны периодические регистры (регистры с отметкой времени в качестве одного из измерений), чтобы запросы всегда получали актуальную информацию на момент запроса? Может быть, и отмена проведения не потребуется — я не знаю.
Поясню о чём речь.
В обычной ситуации, если у Вас есть подборка библиографических ссылок, то Вам приходится запрашивать все издания. Более того, если есть журнал, то хочется посмотреть все публикации одного автора. Было бы удобно взять в библиотеке отдельную книгу, которая, разумеется, печатается прямо в библиотеке по требованию читателя.
Другое дело, что, если всё находится в цифре, то удобнее всё получать по интернету. Но бумажный вариант часто удобнее электронного. (В плане утомляемости.)
В действительности, библиотекам угрожает только пресловутый копирайт. А то получается, что в библиотеке, в отрытом доступе лежит то, что на сайте издательства требует немалой оплаты. В то же время, есть определённый аромат в том, чтобы пройтись вдоль полок и по дороге узнать много нового, что в электронном варианте не так просто сделать.
На самом деле, бумажные копии нужно хранить как зеницу ока. И создавать многочисленные производные книги, содержащие всевозможные подборки публикаций. Вот на что должны быть направлены основные силы. Электричество недолговечно, а бумага может «стерпеть» много веков.
И, конечно, вечная проблема каталогов и каталогизации. Вот я в юную пору активно пользовался библиотекой им. Маяковского (г. Санкт-Петербург). Так вот, там до сих пор книги по программированию лежат в открытом доступе в большой куче, расположенные по алфавиту (без разделения на языки программирования, общие вопросы и инструменты разработки). Как повелось ещё в советские годы, таки осталось. В этом смысле, библиотечное дело крайне консервативное. Вот где нужны специалисты по информатике: чтобы показать оптимальный способ расположения книг, оптимальный способ описания книг и оптимальный способ поиска нужных книг. (И все это при наличии некоего оптимального способа написания книг, чтобы было больше нужного и полезного.)
А Всемирной библиотекой должен был стать интернет, где у каждой книжки, у каждого издания, у каждого текста, у каждой публикации, у каждого автора, была бы своя страница (как единое адресное пространство), и всё было бы едино, а читатель всегда мог бы доехать до библиотеки, чтобы собственными глазами увидеть то, для чего ему мало электронного варианта.
И ещё один момент, который мало кто учитывает. Реальные приложения — это некие «конструкции», которые возведены над ОС и другими «конструкциями». Строго говоря, нельзя возвести хорошее здание без хорошего фундамента. Но программисты всегда пользуются тем, что есть. А Вы попробуйте поставить вопрос: как должна выглядеть ОС, чтобы мы писали эффективные приложения? Но тогда выяснится, что разработчики ОС просто выдали какое-то своё решение и получили за это свои деньги, а как им будут пользоваться, не подумали: продали — и ладно. А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!
Во-первых, в любую минуту может придти Некто, кто попросит даже в самом простом приложении прикрутить «вот эту фичу». Современные монструозные программы (ставшие целыми пакетами!) начинались с маленьких программок.
Во-вторых, Вы всегда будете думать о том, что было бы, если бы у Вас была готовая инфраструктура для создания различных приложений, наличие которой гарантировало бы Вам определённый (высокий) уровень качества программного кода. Сколько было за последние 30 лет предложено всевозможных «фреймвёрков», многие из которых уже давно исчезли из обихода? А если бы эта инфраструктура была бы ещё и частью ОС?
В-третьих, всегда возникает соблазн разбить большие приложения на маленькие. Зачем же мы создавали многофункциональное устройство, чтобы разрезать его на части? Может быть, было бы логичнее, иметь набор маленьких приложений, решающих маленькие задачи, и средство для сборки маленьких приложений для решения больших задач по требованию пользователя (в рамках ОС).
Только, где мы найдём таких разработчиков, которые смогут выявить эти самые элементарные кирпичики и составить из них полноцветные мозаики? На этот вопрос статья ответа не даёт.
Есть номинальные понятия, связанные с тем, какую функцию выполняет человек в определённый момент времени. Есть определённые позиции или вакансии. Вопрос в том, что является результатом своего труда.
Если результатом труда является программа, то речь идёт о программировании. В конце-концов, программа (в самом широком смысле) — это упорядоченная (в том числе, и во времени) совокупность предписаний, что и когда делать, позволяющая перевести систему из одного положения (полное отсутствие автоматизации) в другое (полная автоматизация всех бизнес-процессов).
Роли, здесь, не играют… никакой роли.
Хорошие программисты могут, конечно, между собою называть плохих программистов «кодерами», но особого смысла в этом нет. Другое дело, что в программировании для большинства программистов можно найти более продвинутых программистов, умеющих что-то ещё. В итоге, хороший программист — это тот прграммист, который знает, что ему всегда надо узнать что-то ещё. В этом смысле, все классификации заведомо слабы, поскольку никак не учитывают живую природу человека, который, если он не бездельник, завтра будет, уж точно не таким, как вчера.
Но, лучше не «спотыкаться о термины», а говорить о том, что можно и нужно писать хорошие программы, а можно (хотя и это неприемлемо) писать плохие. Можно расписать красивую структуру требований и подзадач, но ошибиться в анализе и промахнуться в реализации. Недаром, говориться «Семь раз отмерь...». Кто же просит программиста стразу резать? Никто. Только он сам.
P.S. Нет-нет-нет. Надо будет обязательно перечитать. Забыл. Но, сначала, следует хорошенько подумать самому. Математика тем хороша, что, если рассуждаешь логично, то, в итоге, приходишь к правильному результату. Так можно многое вывести. Надо, только, знать, что вспоминать.
А ещё хотелось бы знать, кто-нибудь питался приспособить эти фракталы к распознаванию образов? Я имею в виду хитрое (существенно нелинейное) разбиение признакового пространства, которое позволяет обойти гипотезу компактности. Ведь, реально объекты различных классов существенно «зацеплены» друг за друга, и любые классификаторы будут, очевидно, существенно «ошибаться».
В случае с 1С, правда, срабатывает ещё и такой аргумент: лучше медленная, но прозрачная и, значит, управляемая система с устоявшейся терминологией и устоявшимся рынком поддержки, чем шустрая система с постоянно меняющейся терминологией и без толковой службы поддержки. Я могу ошибаться, но, я думаю, что консерватизм нередко заставляет отказываться от более эффективного в пользу более привычного.