Результаты поиска по запросу «[парадигмы]» / Хабр

Публикации Хабы Компании Пользователи Комментарии

razon 23 ноя 2023 в 15:19

2024. Ви́дение развития ИТ-отрасли

3 мин

1.5K

IT-инфраструктура*Исследования и прогнозы в IT*Учебный процесс в ITИскусственный интеллектБудущее здесь

Протестирую здесь формат новости (не статьи). Составил видение развития ИТ-отрасли.

Проблемы постановки вопросов перед текущим развитием отрасли: ориентация на существующие методологии, технологии и проблемы; устаревание тем; отсутствие взгляда в будущее.

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

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

- подъём по ветви спирали, всё новое — хорошо забытое и переосмысленное старое. Условный разбор изобретённого в 70х в СССР и отложенного на будущее

- методологии прогностиков, Future-темы, предугадывание актуальности тем

Итак, сам вижн:

1. Инженерия разработки
2. Поиск новых парадигм в ИТ
3. Безопасность и стабильность

fierce-katie 15 фев 2021 в 15:19

Сильные стороны функционального программирования

6 мин

15K

Блог компании TypeableПрограммирование*Функциональное программирование*

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

Основной язык разработки у нас в Typeable — Haskell, и, пока все спорили о том, готов ли Haskell для продакшена, мы просто его использовали и считали конкурентным преимуществом. Нам хотелось бы поделиться своим мнением, основанным на этом опыте.

Читать дальше →

+22

IvanBatechko 21 окт 2022 в 17:02

«Устанавливаем правила игры». 10 парадигм, которые должен соблюдать каждый сотрудник (часть 1)

8 мин

4.8K

Управление персоналом*

Если мы захотим пройти обучение по “Делегированию и контролю” — гугл нам предложит сотни разных книг, курсов и тренингов. Но все эти обучения направлены на руководителей. Руководителей обучают, как правильно готовится к постановке задач, как правильно декомпозировать задачи, как провести встречу по делегированию, как проконтролировать результат. А самих сотрудников не обучают этому (как принимать задания и взаимодействовать во время их выполнения)….

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

Итого, можно сказать, что в этом вопросе сложилось определенное правило и стереотип — руководитель ответственен за порученное задание. С этим мы спорить, конечно, не будем — при любом раскладе руководитель ответственен за результат. Невозможно на 100% делегировать эту ответственность, ведь именно руководитель выбирает сотрудника для выполнения задания. Если под задание выбран сотрудник, квалификация которого не позволяет это задание выполнить, виноват в этом только руководитель. Но что, если разделить ответственность за задание между руководителем и сотрудником? “Постойте, но это же итак понятно” — скажете вы. Да, об этом много говорится, везде написано, но как это работает в жизни? Какую именно ответственность разделяет руководитель с сотрудником? Понимает ли сотрудник, что он берет на себя эту ответственность? А одинаково ли вы с сотрудником понимаете его ответственность? Рассмотрим несколько примеров…

Читать дальше →

kivsiak 14 окт 2010 в 05:04

Как избавиться от пристрастия к синхронности

6 мин

5.7K

Веб-разработка*

Перевод

При сравнении асинхронное программирование превосходит синхронное, как по потреблению памяти, так и по производительности. Мы знакомы с этим фактом уже годы. Если посмотреть на Django или Ruby on Rails, возможно два самых многообещающих веб-фреймворка, появившихся за последние несколько лет, оба написаны из расчета на синхронный стиль. Почему даже в 2010 году мы пишем программы, полагающиеся на синхронное программирование?

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

Дальше много текста

+52

129

adely-originsecurity 15 июн 2023 в 12:45

Обзор современных парадигм обеспечения ИБ

Простой

10 мин

5.1K

Информационная безопасность*IT-инфраструктура*

Обзор

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

apache2 15 ноя 2021 в 18:27

Какой вклад внесло функциональное программирование в современные языки?

10 мин

18K

Блог компании TypeableПрограммирование*Функциональное программирование*

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

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

В своей недавней статье мы рассказывали о практических применениях Лиспа и упомянули, что он сильно повлиял на развитие других языков программирования, но не стали вдаваться в детали. Пришло время более подробно раскрыть эту тему и разобраться, какой вклад функциональное программирование в целом (не только Лисп!) внесло в развитие других языков. Поскольку мы используем Haskell как основной язык разработки, и наша команда разработчиков состоит из ФП-энтузиастов, мы не смогли пройти мимо такой темы.

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

Читать дальше →

+47

norguhtar 3 фев 2007 в 21:26

Про парадигмы программирования

1 мин

1.1K

Чулан

Думать надо верхней жопой. Вот и вся парадигма.

maxstroy 22 дек 2014 в 12:09

Знакомство с парадигмами построения моделей предметной области

11 мин

24K

Семантика*Анализ и проектирование систем*Математика*

Введение

Возможно, кто-то задаст вопрос, а причем тут математика? Отвечу сразу: все, что здесь изложено, относится непосредственно к математике.
Изучая литературу по теории построения моделей предметной области, я обнаружил серьезный пробел. Авторы статей и книг сразу берут одну из нотаций моделирования: ER-диаграммы, или диаграммы классов, и в быстром темпе начинают их использовать для описания предметной области. При этом описание парадигмы, в которой производится это моделирование остается вообще не раскрытым. А следовательно, не раскрытыми остаются ограничения той или иной нотации. Увы, мы все умеем строить модели, но мало кто умеет объяснить то, что он построил в одной из существующих парадигм. Поэтому я часто слышу дикие с точки зрения любой парадигмы термины: класс типов, типы классов, виды типов и так далее, но ни разу не слышал корректный термин «класс классов». Этот пробел в нашем образовании очень серьезен. И я объясню почему.

Давайте зададим аналитикам простой вопрос.

Те, кто моделировал процессы, наверно, знакомы с нотацией BPMN. Очень часто при моделировании операции по заключению договора я встречаю такой фрагмент диаграммы:

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

Бумажка с печатью
Бумажки с печатью
Класс бумажек с печатью
Договор
Договоренность
Информация о договоренности
Файл MS Word с названием договор
Запись в базе данных
Поток каких-то объектов

Пока я наблюдаю отсутствие согласия между аналитиками на предмет того, что же все-таки передается, и что значат термины «договор», «поток», «договоренность», «информация», «данные». Чтобы ответить на этот вопрос, мне пришлось копать глубоко и в сторону парадигм. Причем, ответ потребовал разбиения вопроса на два. Первый вопрос был: «Как корректно сформулировать вопрос?» А второй был: «Как на него ответить?». Для правильной формулировки нужно было выбрать подходящую парадигму. Эта статья посвящена рассказу о двух парадигмах: Аристотелевской и логической, и почему я выбрал логическую в качестве рабочей. Ответа на поставленный вопрос в этой статье я не дам. Ответ я дам в другой статье.

Читать дальше →

+13

maxstroy 29 дек 2014 в 11:42

Что такое событие, или зачем четырехмерная геометрия бизнес-аналитику?

12 мин

21K

Семантика*Анализ и проектирование систем*Математика*

Петька, ну как? Сдал экзамен?
Нет, Василий Иванович! Меня попросили квадратный трехчлен разложить. А я его не то что разложить, я его представить не могу!

Постановка вопроса

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

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

Чем ИСО 15926 мне не понравился

В прошлых статьях я давал определения физического объекта.

Физический объект — это любое подмножество 4-Д пространства-времени.

Кроме того, я давал определения функционального и информационного объектов.

Физический и информационный объекты — это физические объекты в 4-Д пространстве-времени, которые с точки зрения наблюдателя выполняют определенные функции, или служат определенным целям.

Читать дальше →

166

maxstroy 2 янв 2015 в 16:58

Физические и функциональные объекты (Продолжение)

9 мин

23K

Семантика*Анализ и проектирование систем*Математика*

Есть три способа описания процесса:

Чем они отличаются?

Описание сущего

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

Природа пространства-времени

Начнем с того, что воспринимаемый нами мир – это четырехмерное пространство-время. Но не то пространство-время, которое используют математики в своих рассуждениях. Скорее это то пространство, которое используют физики. Разница в том, что в физическом мире нет точек. Есть объекты, которые с точки зрения наблюдателя можно считать точечными. Но при ближайшем рассмотрении эти точки могут рассматриваться как бесконечные пространства. Мы часто не различаем воспринимаемый нами мир и математическую абстракцию, созданную для описания этого восприятия. В абстракции, созданной для описания воспринимаемого мира, есть понятие точка. В реальном мире нет точек. В этом огромная разница между моделируемым миром и его моделью. В неразличении этих двух сущностей кроется причина части холиваров, возникших на основе предыдущей статьи. Например, мы не способны воспринять срез пространственно-временного континуума поперек временной оси, как нам предлагает поступить ИСО 15926, для определения понятия событие. Поэтому далее я продолжу рассуждения, не отвлекаясь на такие понятия как точки, срезы пространственно-временного континуума и прочие абстрактные объекты. Мы будем работать только с реально воспринимаемыми нами объектами 4-Д пространства-времени.

Читать дальше →

maxstroy 9 янв 2015 в 06:39

BPMN: Моделирование физических событий

12 мин

29K

Семантика*Анализ и проектирование систем*Математика*

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

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

Определение события

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

Экстент — это любая 4-Д область из 4-Д пространства-времени. Дело в том, что наше пространство четырехмерно. Просто одно из измерений мы переживаем специфическим образом – как нечто, что разворачивается перед нами в одном направлении. Но для моделирования такая особенность нашего восприятия не имеет значения.
Считается, что экстент, который мы считаем событием, с точки зрения рассказчика имеет нулевую временную ширину. То есть с точки зрения рассказчика событие – это мгновение. Однако, всегда существует точка зрения, в которой шириной события уже нельзя пренебречь и нам понадобится рассмотреть временную ширину этого экстента.
Событие имеет физический смысл – это факты и ничего, кроме фактов. Мы рассматриваем такое событие как набор фактов без их трактовок. Например, в примере с маяком есть событие смотритель сидит на дровне и отдыхает. Такое событие мы будем называть физическое событие.
Кроме физического события существует множество трактовок этого физического события разными субъектами. Например, при описании маяка одно и то же физическое событие «Смотритель отдыхает» может быть описано как: «Розжиг закончен» и «Тушение начато». Такое событие мы будем называть функциональное событие.

В итоге мы имеем такую иерархию объектов:

Читать дальше →

103

maxstroy 29 янв 2015 в 11:53

Особенности моделирования предметной области с помощью ООП

6 мин

35K

Семантика*Анализ и проектирование систем*ООП*

Введение

Хочу заметить, что тем, кто пользуется терминами ООП, будет очень трудно понять меня. Дело в том, что ООП подменил понятия. В ООП под классом понимается не множество, как обычно принято в математике, или лингвистике. В ООП классом называют тип объектов, как у Аристотеля. Было бы правильно в ООП вместо термина класс объектов использовать термин тип объекта. Однажды, съехав с правильной терминологии, вернуться в лоно правильных терминов оказывается очень трудно. В данной статье я попробую помочь тем, кто желает разобраться с терминологической кашей, заваренной ООП. В своих рассуждениях я буду использовать термины в их первоначальном смысле, а не в смысле ООП. Термин класс будет взят из логической парадигмы моделирования предметных областей, которая, в свою очередь, заимствовала этот термин из теории множеств. Термины тип и экземпляр будет взят из теории типов, построенной на парадигме Аристотеля о существовании типов.

Адепту ООП очень трудно понять, что термин экземпляр класса в русском языке указывает на класс объектов, а не на созвучный этому термину элемент класса – объект класса. Для многих, кто изучал ООП, термины экземпляр и элемент – неразличимы. Давайте разберемся с этими терминами внимательно.

Читать дальше →

555

sand14 29 янв 2015 в 14:55

На тему моделирования предметной области в терминах ООП

3 мин

15K

Веб-разработка*Семантика*Программирование*Анализ и проектирование систем*ООП*

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

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

Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:

класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП);
класс/таблицу вида «Список машин»;
класс/таблицу вида «Машина».

Далее с помощью механизмов ООП и реляционной модели «подсущности» связываются между собой.

Причем термины «сущность» и «подсущность» применимы именно к модели предметной области в терминах теории множеств,
а в терминах ООП/реляционной модели уместны термины «метасущность» и «сущность» соответственно.
Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.

А далее следуют ожидаемые проблемы:

Читать дальше →