Мейнфрейм — это очень «толстый» сервер. Современный аналог мейнфрейма — облачное хранилище, которое предоставляет возможность обработки данных на месте (в самом облаке). А в малом, тот же подход реализуется смартфонами: смартфоны — это «тонкие» клиенты, которые подключаются к удалённым серверам. Время только изменило масштабы системы и добавила распределённости.
Невозможно же до бесконечности писать про архитектуру, подводные камни языков, практики разработки. Может быть обсосали уже все темы?
Разумеется. Но есть ещё и вопрос глубины изложения. А глубина изложения — это результат труда, а, вот, сейчас мало кто рискнёт потрать значительные усилия на глубокие исследования. Глубокие исследования всегда интересны. Специалист, который перестаёт исследовать, перестаёт быть специалистом.
Как бы мне объяснить Вам, что именно меня беспокоит?
Допустим, мы хотим сделать какое-то приложение, требующее какой-то базы данных. Мы начинаем описывать сами хранимые данные, объекты, отношения, ограничения целостности, права и роли. И всё это — на уровне баз данных! А потом наступает момент написания клиентского приложения, где... многие элементы уже сделанного нами ранее описания воспроизводятся. Не буквально, но довольно близко к первоисточнику. Спрашивается, зачем?
Набор базовых идиом языка должен быть ограничен, особенно в таком языке, как Питон, который является и клеем и языком работы с данными и еще 100 примененией.
А давайте, уж, простите мне такую фамильярность, рассмотрим подробнее эту самую работу с данными.
Где у нас данные? В файлах? В базах данных? Как мы хотели бы видеть работу с данными?
Лично мне очень интересен такой вопрос: почему мы не можем расписать всю логику работы своего приложения на сервере (в самой базе данных) и, просто, подключаться тонким клиентом к серверу и делать всё, что нам нужно?
Понятное дело, что Python здесь, как бы, ни при чём. Но было бы интересно посмотреть на то, может ли разработка приложений выглядеть как-то по другому.
Время новизны и прорывного характера информационных технологий давно прошли.
Любой ресурс — это люди. А люди меняются. Многие уходят. Все куда-то перемещаются. И по личным причинам, и по чисто форумным причинам (несогласие с руководством/оппонентами, усталость от дискуссий, которые часто ни к чему не приводят). (По моим ощущениям, здесь на Хабре, немного сменилась аудитория после 22.02.2024. Но это только по моим.)
Сейчас, вообще, не очень-то до информационных технологий.
Плохо, что в почте появился html. Красиво, но не безопасно. Если хотите красивые картинки и ссылки, создавайте новый протокол, который будет надстройкой над почтовым, и вперёд. А я хочу получать на почту письма, открывая которые, я буду уверен, что с моим компьютером ничего не случится. Да и со мною тоже.
Да. Типовой. И, считаю, что в этом и может быть единственно смысл компонентного проектирования программ. Три важных премущества:
Единообразие. Один раз научились — пользуемся везде и всегда. И разработчикам прикладного ПО проще — единый API.
Безопасность. Хорошо проработанный и консервативный к изменениям протокол взаимодействия — залог того, что не будут появляться новые дыры.
Удобство. Пользователь сам решает, в каком виде ему сейчас нужно управлять информацией.
Для этого и нужен системный анализ, чтобы выделить общие элементы разнородных систем, привести их, так сказать, к одному знаменателю, и предоставить программисту общую систему координат.
Никаких технических препятствий для того, чтобы что-то сделать, нет. Проблема рекламы не в том, что она есть, а в том, что её навязывают в самой неудобной форме (перекрывающей основное содержание, прерывающее произведение и т.д. и т.п.), а у меня нет возможности (когда это нужно) заплатить за то, чтобы рекламы не было.
И ещё. Вот мы здесь пишем сообщения. что будет, если мы за возможность читать наши сообщения, будет требовать плату? Не знаю. Просто, я о том, что нельзя требовать платы где-то в одном месте, не требуя платы где-то в другом месте. Можно провозгласить принцип: каждая работа должна быть оплачена. За все ли работы предоставляется оплата? Всё ли воспринимается как работа?
А, уж, отобразить что-то — дело десятое. Тут Вы правы. Конечно же.
Вопрос совершенно в другом: зачем подгружать какой-то код? Пока мне никто не объяснил, зачем это нужно делать. Например, если у меня есть почтовый клиент, то я загружаю письма и всё, более мне ничего не требуется.
Это может показаться удивительным, но ОС и есть та система, которая сооружает для пользователя такую "песочницу". Было бы здорово иметь все нужные права. Да, кто-ж, даст-то?
А сколько за последние десятилетия сочинено всяких библиотек и фпеймворков? Сколько просто ушло в утиль? Вот, работала бы сегодня какая-нибудь программка на FoxPro, Turbo Vision или MFC и работала бы...
А теперь представьте, как это могло бы быть организовано, например, в виде внутреннего модуля в ОС, который просто подключается к серверу HABR по специальному протоколу, загружает всё в локальную базу данных и отображает сообщения в стандартной форме. Кто-то оставил в теме новое сообщение? — Получили несколько Кб. А если несколько форумов? — Несколько вкладок, но поток данных один (только идентификатор форума меняется). Посылаете сообщение? — Опять же! Несколько Кб в обратную сторону. Никаких GET, POST и PUT.
Вместо того, чтобы расписывать местами довольно банальные рассуждения (о том, что может быть, а может и не быть, но... не суть важно! Всё будет обязательно как-то и так и как-то не так), лучше было бы порассуждать о том, каким должен стать сам язык программирования.
Что должен предложить программисту Python? Каким мог бы быть Python 4.0? Как должна измениться сама разработка на Python?
Следующий шаг в развитии языка обязательно будет связан с развитием его синтаксиса. Смысл синтаксиса языка программирования заключается в том, чтобы предложить программисту точные изобразительные средства для решения повседневных задач. В Python'е такими средствами являются отступы, генераторы, итераторы и декораторы (замыкания и yield'ы), всевозможные коллекции и возможность реализовать собственный вычислительный объект, функционирующий как коллекция. Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка. Есть ли у Вас такая идиома на примете?
Лично мне, кажется логичным, сделать f-строки некоторым стандартом, то есть — отбросить приставку f. Но если требуется какое-то специальное форматирование, то можно было бы использовать специальную синтаксическую конструкцию по типу старой Python-овской функции format(), которая описывает этот самый формат.
Проблема всякого языка программирования — это опора на библиотеки: есть предметная область — создаём библиотеку функций для решения соответствующих задач. А развитие языка программирования заключается в том, чтобы реализовать требуемые функции в виде явных синтаксических конструкций. Спрашивается, если у нас есть numpy.array, то почему у нас не может быть явного синтаксического способа работы с массивами? Да, никто не мешает использовать словари: например, можно реализовать простые матрицы с доступом по двум координатам — A[(i,j)]. Но! Хотелось бы иметь возможность писать A[i,j]. (Возможно, я что-то пропустил, и этим своим замечанием попадаю просто в небо?!! И всё уже давно реализовано в Python 3.14.x.) Мы могли бы на уровне языка явно определять. как мы храним элементы обыкновенной плоской матрицы (или. даже, многомерного числового массива) — по строкам или по столбцам (как в MATLAB/OCVTAVE), или, вообще, используется какое-нибудь особое представление (вроде диагонального), не говоря уже и о возможности применения "разреженных" (sparse) матриц (словарь, в этом смысле, как раз, и воспроизводит эту самую разреженную матрицу).
Думается, в Python-е можно было предусмотреть специальные локальные (предметно-ориентированные) языки для решения узких задач. Ведь, ещё одна проблема — это значительная перегрузка функций и операторов. Если бы можно было бы создавать локальные вычислительные модели, тогда можно было избавиться от встроенного косноязычия Python-е, когда приходится создавать объект определённого класса и мириться с его реализацией и выбранными способами доступа...
Лично мне не хватает в Python-е угловых скобок (типа <>), при помощи которых можно было бы обозначать кортежи, а круглые скобки освободить для функций. (Тогда не придётся писать (,) для обозначения пустого кортежа.)
Позволю конкретизировать свой вопрос. Что же такое модульность на уровне программной логики? Пусть у нас есть два модуля — модуль А и модуль Б. Можно ли. например, выделить модуль (А) для обслуживания загрузки/выгрузки приложения и модуль (Б) для печати? Можно ли выделить модуль (А) для работы с пользовательским интерфейсом и модуль (Б) для работы с базами данных? Можно ли выделить модуль (А) для работы с заказами и модуль (Б) для работы с накладными? И всё это — на уровне программной логики?
Пример: допустим, есть какая-нибудь CRM. Бизнес захотел, чтобы в карточке клиента появился аттрибут "персональный менеджер".
Если рассматривать Ваш пример не как учебный, а как реальный, то получается, что на этапе составления требований упустили очевидное бизнес-правило: когда у каждого клиента должен быть свой персональный менеджер.
Для этого нам нужно:1. Добавить поле в БД, написать миграцию для этого.
А что, если содержимое карточки описывается подчинённой таблицей, где каждая строка соответствует отдельному полю карточки? Вместо того, чтобы добавлять новое поле в существующую таблицу, Вы в специальном редакторе полей карточки добавляете новое.
2. Добавить работу с этим полем в 3 SQL-запроса (insert, update, select) или в аналогичные выражения ORM
Если у нас есть таблица полей (из предыдущего пункта), то мы может всегда использовать один и то же запрос с группировкой. Добавив новое поле в карточку, мы просто увеличим на одну позицию длину списка для каждой группы. При этом логика работы не изменилась.
3. Добавить атрибут в объект данных (entity), возможно не в один
А что это такое?
4. В зависимости от архитектуры, изменить интерфейсы и добавить новую логику в несколько слоев бэкенда: репозиторий, сервис, контроллер, допилить валидацию
Неужели трудно в подавляющих случаях строить интерфейс на лету. Вернёмся к списку полей карточки клиента. Что мешает один описать всю логику работы с данным полем (персональный менеджер) в одном месте?
5. Расширить API бэкенда
Интересно, что Вы имеете здесь в виду? Возможность организации запросов вида "Все действующие (персональные) менеджеры", "История работы персонального менеджера" и "История взаимоотношения с клиентом (через посредство работы с одним или несколькими персональными менеджерами)"?
6. Дополнить еще пару слоёв во Фронтенде
Уже было сказано.
7. И только теперь добавить в UI новый элемент.
Уже было сказано.
8. Дописать тесты
Дописывать тесты приходится всегда, когда появляется новая функция. А какие тест-кейсы Вы здесь ожидаете?
Вопрос терминологии. Не более.
Мейнфрейм — это очень «толстый» сервер. Современный аналог мейнфрейма — облачное хранилище, которое предоставляет возможность обработки данных на месте (в самом облаке). А в малом, тот же подход реализуется смартфонами: смартфоны — это «тонкие» клиенты, которые подключаются к удалённым серверам. Время только изменило масштабы системы и добавила распределённости.
Опечатка! Поправлять не буду. Пусть висит в назидание. Самому себе.
Разумеется. Но есть ещё и вопрос глубины изложения. А глубина изложения — это результат труда, а, вот, сейчас мало кто рискнёт потрать значительные усилия на глубокие исследования. Глубокие исследования всегда интересны. Специалист, который перестаёт исследовать, перестаёт быть специалистом.
Хотя... можно было бы пофантазировать о том, как мог бы выглядеть Python 4.0...
Как бы мне объяснить Вам, что именно меня беспокоит?
Допустим, мы хотим сделать какое-то приложение, требующее какой-то базы данных. Мы начинаем описывать сами хранимые данные, объекты, отношения, ограничения целостности, права и роли. И всё это — на уровне баз данных! А потом наступает момент написания клиентского приложения, где... многие элементы уже сделанного нами ранее описания воспроизводятся. Не буквально, но довольно близко к первоисточнику. Спрашивается, зачем?
А давайте, уж, простите мне такую фамильярность, рассмотрим подробнее эту самую работу с данными.
Где у нас данные? В файлах? В базах данных? Как мы хотели бы видеть работу с данными?
Лично мне очень интересен такой вопрос: почему мы не можем расписать всю логику работы своего приложения на сервере (в самой базе данных) и, просто, подключаться тонким клиентом к серверу и делать всё, что нам нужно?
Понятное дело, что Python здесь, как бы, ни при чём. Но было бы интересно посмотреть на то, может ли разработка приложений выглядеть как-то по другому.
Есть три соверешенно объективные вещи:
Время новизны и прорывного характера информационных технологий давно прошли.
Любой ресурс — это люди. А люди меняются. Многие уходят. Все куда-то перемещаются. И по личным причинам, и по чисто форумным причинам (несогласие с руководством/оппонентами, усталость от дискуссий, которые часто ни к чему не приводят). (По моим ощущениям, здесь на Хабре, немного сменилась аудитория после 22.02.2024. Но это только по моим.)
Сейчас, вообще, не очень-то до информационных технологий.
Плохо, что в почте появился
html. Красиво, но не безопасно. Если хотите красивые картинки и ссылки, создавайте новый протокол, который будет надстройкой над почтовым, и вперёд. А я хочу получать на почту письма, открывая которые, я буду уверен, что с моим компьютером ничего не случится. Да и со мною тоже.Да. Типовой. И, считаю, что в этом и может быть единственно смысл компонентного проектирования программ. Три важных премущества:
Единообразие. Один раз научились — пользуемся везде и всегда. И разработчикам прикладного ПО проще — единый API.
Безопасность. Хорошо проработанный и консервативный к изменениям протокол взаимодействия — залог того, что не будут появляться новые дыры.
Удобство. Пользователь сам решает, в каком виде ему сейчас нужно управлять информацией.
Для этого и нужен системный анализ, чтобы выделить общие элементы разнородных систем, привести их, так сказать, к одному знаменателю, и предоставить программисту общую систему координат.
Что мешает сейчас использовать? Проблем с безопасностью было бы на порядок меньше.
Никаких технических препятствий для того, чтобы что-то сделать, нет. Проблема рекламы не в том, что она есть, а в том, что её навязывают в самой неудобной форме (перекрывающей основное содержание, прерывающее произведение и т.д. и т.п.), а у меня нет возможности (когда это нужно) заплатить за то, чтобы рекламы не было.
И ещё. Вот мы здесь пишем сообщения. что будет, если мы за возможность читать наши сообщения, будет требовать плату? Не знаю. Просто, я о том, что нельзя требовать платы где-то в одном месте, не требуя платы где-то в другом месте. Можно провозгласить принцип: каждая работа должна быть оплачена. За все ли работы предоставляется оплата? Всё ли воспринимается как работа?
А, уж, отобразить что-то — дело десятое. Тут Вы правы. Конечно же.
Вопрос совершенно в другом: зачем подгружать какой-то код? Пока мне никто не объяснил, зачем это нужно делать. Например, если у меня есть почтовый клиент, то я загружаю письма и всё, более мне ничего не требуется.
Это может показаться удивительным, но ОС и есть та система, которая сооружает для пользователя такую "песочницу". Было бы здорово иметь все нужные права. Да, кто-ж, даст-то?
Всё уже давно придумано до нас: Remote Procedure Call и CORBA.
А сколько за последние десятилетия сочинено всяких библиотек и фпеймворков? Сколько просто ушло в утиль? Вот, работала бы сегодня какая-нибудь программка на FoxPro, Turbo Vision или MFC и работала бы...
А теперь представьте, как это могло бы быть организовано, например, в виде внутреннего модуля в ОС, который просто подключается к серверу HABR по специальному протоколу, загружает всё в локальную базу данных и отображает сообщения в стандартной форме. Кто-то оставил в теме новое сообщение? — Получили несколько Кб. А если несколько форумов? — Несколько вкладок, но поток данных один (только идентификатор форума меняется). Посылаете сообщение? — Опять же! Несколько Кб в обратную сторону. Никаких GET, POST и PUT.
ИИ-гадание на кофейной (привет Java!))) гуще. ;-)
Вместо того, чтобы расписывать местами довольно банальные рассуждения (о том, что может быть, а может и не быть, но... не суть важно! Всё будет обязательно как-то и так и как-то не так), лучше было бы порассуждать о том, каким должен стать сам язык программирования.
Что должен предложить программисту Python? Каким мог бы быть Python 4.0? Как должна измениться сама разработка на Python?
Следующий шаг в развитии языка обязательно будет связан с развитием его синтаксиса. Смысл синтаксиса языка программирования заключается в том, чтобы предложить программисту точные изобразительные средства для решения повседневных задач. В Python'е такими средствами являются отступы, генераторы, итераторы и декораторы (замыкания и yield'ы), всевозможные коллекции и возможность реализовать собственный вычислительный объект, функционирующий как коллекция. Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка. Есть ли у Вас такая идиома на примете?
Лично мне, кажется логичным, сделать f-строки некоторым стандартом, то есть — отбросить приставку
f. Но если требуется какое-то специальное форматирование, то можно было бы использовать специальную синтаксическую конструкцию по типу старой Python-овской функцииformat(), которая описывает этот самый формат.Проблема всякого языка программирования — это опора на библиотеки: есть предметная область — создаём библиотеку функций для решения соответствующих задач. А развитие языка программирования заключается в том, чтобы реализовать требуемые функции в виде явных синтаксических конструкций. Спрашивается, если у нас есть
numpy.array, то почему у нас не может быть явного синтаксического способа работы с массивами? Да, никто не мешает использовать словари: например, можно реализовать простые матрицы с доступом по двум координатам —A[(i,j)]. Но! Хотелось бы иметь возможность писатьA[i,j]. (Возможно, я что-то пропустил, и этим своим замечанием попадаю просто в небо?!! И всё уже давно реализовано в Python 3.14.x.) Мы могли бы на уровне языка явно определять. как мы храним элементы обыкновенной плоской матрицы (или. даже, многомерного числового массива) — по строкам или по столбцам (как в MATLAB/OCVTAVE), или, вообще, используется какое-нибудь особое представление (вроде диагонального), не говоря уже и о возможности применения "разреженных" (sparse) матриц (словарь, в этом смысле, как раз, и воспроизводит эту самую разреженную матрицу).Думается, в Python-е можно было предусмотреть специальные локальные (предметно-ориентированные) языки для решения узких задач. Ведь, ещё одна проблема — это значительная перегрузка функций и операторов. Если бы можно было бы создавать локальные вычислительные модели, тогда можно было избавиться от встроенного косноязычия Python-е, когда приходится создавать объект определённого класса и мириться с его реализацией и выбранными способами доступа...
Лично мне не хватает в Python-е угловых скобок (типа
<>), при помощи которых можно было бы обозначать кортежи, а круглые скобки освободить для функций. (Тогда не придётся писать(,)для обозначения пустого кортежа.)Довольно прямолинейный подход. Здесь пригодилась бы какая-нибудь подходящая ортогонализация. Как в математике. кто предложит?
Позволю конкретизировать свой вопрос. Что же такое модульность на уровне программной логики? Пусть у нас есть два модуля — модуль А и модуль Б. Можно ли. например, выделить модуль (А) для обслуживания загрузки/выгрузки приложения и модуль (Б) для печати? Можно ли выделить модуль (А) для работы с пользовательским интерфейсом и модуль (Б) для работы с базами данных? Можно ли выделить модуль (А) для работы с заказами и модуль (Б) для работы с накладными? И всё это — на уровне программной логики?
Если рассматривать Ваш пример не как учебный, а как реальный, то получается, что на этапе составления требований упустили очевидное бизнес-правило: когда у каждого клиента должен быть свой персональный менеджер.
А что, если содержимое карточки описывается подчинённой таблицей, где каждая строка соответствует отдельному полю карточки? Вместо того, чтобы добавлять новое поле в существующую таблицу, Вы в специальном редакторе полей карточки добавляете новое.
Если у нас есть таблица полей (из предыдущего пункта), то мы может всегда использовать один и то же запрос с группировкой. Добавив новое поле в карточку, мы просто увеличим на одну позицию длину списка для каждой группы. При этом логика работы не изменилась.
А что это такое?
Неужели трудно в подавляющих случаях строить интерфейс на лету. Вернёмся к списку полей карточки клиента. Что мешает один описать всю логику работы с данным полем (персональный менеджер) в одном месте?
Интересно, что Вы имеете здесь в виду? Возможность организации запросов вида "Все действующие (персональные) менеджеры", "История работы персонального менеджера" и "История взаимоотношения с клиентом (через посредство работы с одним или несколькими персональными менеджерами)"?
Уже было сказано.
Уже было сказано.
Дописывать тесты приходится всегда, когда появляется новая функция. А какие тест-кейсы Вы здесь ожидаете?