Вхід і реєстрація
Розробка · 27 вересня 2009, 16:16 162
anonymous

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Ни к чему не обязывающий мысленный эксперимент, навеянный чтением Дейкстры и Киллелиа с легкого похмелья.

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

Джихады типа «embedded vs. outsorce» и «сишники против джаверов», естественно, не благословляются.

Теми: парадигмы программирования
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
anonymous 01.10.2009 21:08

Ваш тон, Grez, наводит на мысль, что вы не заинтересованы в продуктивном исходе холиворчика. Учите матчасть, в числе прочего Inside F#.

где вы здесь, в С#-ом примере ООП увидели?
Можно я не буду комментировать это высказывание, а просто дам пруф?

Interaction design for software engineering: boost into programming future by Claude Knaus, Interactions, vol. 15, #4 (07−08/2008). p. 71−74.

Ваш пример действительно по всему интернету разбросан, и его задача показать мосч и силу F#
Правильно, я никогда и не претендовал на копирайт в отношении этого куска кода.: -)

Upd. Извините, пожалуйста, но вас бы не затруднило копипастить текст из M$ Word с включенным спеллчекером, а то читать неприятно для глаз?

Відповісти
Підтримати
Grez 01.10.2009 20:46
«Вернемся же к нашему холивору, мой декларативный друг».
Ваш пример действительно по всему интернету разбросан, и его задача показать мосч и силу F# по сравнению с классической императивной парадигмой (где вы здесь, в С#-ом примере ООП увидели?). Имхо, этот пример демонстрирует целый ряд недостатков F#, впрочем не буду оффтопить.

Что самое главное — я понять никак не могу, как данный пример вяжеться с тем, что вы раньше постили. Чего он такого демонстрирует, в чом чистая функциональная парадигма имеет сногшибательное преимуущество перед ООП в виде отсуствия «танцев плясок с бубном».

Відповісти
Підтримати
anonymous 29.09.2009 17:06

Я не сособо вижу разницы между упаковыванием математических (статических) функций в оболочку класса, и упаковыванием их же в отдельный модуль

А, ну я так и знал.^_^ Вот самый что ни на есть бородатый пример, восходящий к руководствам МакКракена по Фортрану 66. Задача: дана стартовая точка на плоскости и примерный координатный разброс нескольких следующих точек, найти кратчайшее расстояние от ГМ этих точек до стартовой. Решение на С#: 

static class PointMath
{
static double Distance(Point p1, Point p2)
{
double xDist = p1.X - p2.X;
double yDist = p1.Y - p2.Y;
return Math.Sqrt(xDist * xDist + yDist * yDist);
}
public static Point ClosestPoint(Point p, IList<Point> points)
{
double shortestDistance = Double.PositiveInfinity;
Point closestPoint = null;
foreach (var point in points)
{
double distance = Distance(p, point);
if (distance < shortestDistance)
{
shortestDistance = distance;
closestPoint = point;
}
}
return closestPoint;
}
}

Решение на F# в стиле руководств Санчеса и Макнамары: 

let distance (x1, y1) (x2, y2) : double =
let xDistance = x1 - x2
let yDistance = y1 - y2
sqrt (xDistance * xDistance + yDistance * yDistance)
let closestPoint toPoint fromPoints = List.min_by (distance toPoint) fromPoints
Відповісти
Підтримати
Александр Маненко 29.09.2009 16:48

Кстати, кто знает, F# будет уже интегрирован в M$ Visual Studio 2010

Yep

Відповісти
Підтримати
Grez 29.09.2009 16:38
2hellip Я не сособо вижу разницы между упаковыванием математических (статических) функций в оболочку класса, и упаковыванием их же в отдельный модуль. Кроме того есть такая замечательная штука как import static, которая эту разницу еще более стирает.

А на счет того, что не следует кидать новичков в ООП, в лоб, я с вами согласен, но альтернатив, похоже, становиться все меньше...

Відповісти
Підтримати
anonymous 29.09.2009 11:39

2 Михаил Сорочан да, 5233 поста — это сильно, нам еще расти и расти до них: -)

Відповісти
Підтримати
It's me 29.09.2009 11:04
Свою собственную — MFSP.
Опубликованных материалов по ней особо нет, уж извините.

Ключевые моменты идеологии (не в контексте программирования) можно найти здесь.

Відповісти
Підтримати
Михаил 29.09.2009 11:01

К теме предыдущих постов — интересный топик по функциональному программированию. Там чтива почти на месяц. Нашел там много интересных ссылок и мыслей.

Відповісти
Підтримати
anonymous 29.09.2009 10:43
Я думал STL это Standard Template Library, оказывается... after all, STL stands for STepanov and Lee:)

Да уж. Некоторые олдфаги, вовремя приспособившие реальность под свои мыслительные процессы, оказываются способны высказывать весьма конструктивные, хотя и парадоксальные вещи. Я когда-то пытался изучать С++ по Прате. Прочитал первые шесть глав и захлопнул книгу. Долго попускало, пришлось перейти на Дейтела и Бьярне, и тогда более-менее пошло. Когда ООП-парадигма подается в лоб, без обсуждения и интеграции (при случае) каких-либо альтернатив, и сопровождается зубодробительными проповедями о мире объектов, это имхо лучший способ запудрить нубасу моск и превратить его в сферического быдлокодера в вакууме, клиента всяких сутенеров типа Developers Club ^-)) On the other hand, я не отрицаю, что у функциональных языков есть существенные траблы при типизациях для кода Win/Web Forms.

Відповісти
Підтримати
anonymous 29.09.2009 10:31

Извинение принято: -)) По существу сабжа

Ну и какое это имеет отношение к десктоп аппу?
Уфф, объясняю по-русски. Вот представьте себе, скажем, что вы используете командный шаблон, реализуя его через класс Command или интерфейс с методом Execute. ООП-парадигма as is требует многократной возни с теми самыми «сущностями», которые не рекомендует умножать принцип бритвы Оккама, как то — класс Command, интерфейс, метод Execute, более конкретные подтипы, участвующие в воплощении шаблона в реальном коде.

А программа на языке, использующем функциональную парадигму, не нуждается во всех этих плясках с бубном. Тип функции (напр., int-> unit) является необходимым, достаточным и единственным нужным описанием интерфейса, и даже любое лямбда-выражение корректного синтаксиса может быть теперь применено в качестве верного воплощения шаблона. Но ведь такие вышеперечисленные шаги, как моделирование с шаблонами, декомпозиция и инкапсуляция, имеют определяющее значение для кошерного десктоп аппа. Отпадает необходимость и упаковывать математические функции в оболочку классов, хотя более естественным с точки зрения общей математической структуры программы является их определение в открытом модуле и более свободное обращение с ними, включая вызовы по коротким именам. Соответственно, интеграция функционального программирования, как в том же F#, может быть более полезной для проектирования десктопа, чем следование рамкам одной парадигмы. Вот как-то так. Кстати, кто знает, F# будет уже интегрирован в M$ Visual Studio 2010?

Відповісти
Підтримати
Grez 29.09.2009 08:00
Ну и какое это имеет отношение к десктоп аппу?

З.Ы. по поводу русского, прошу меня простить, и больше к этому вопросу не возврашаться; -)

Відповісти
Підтримати
Михаил 29.09.2009 07:58

Я думал STL это Standard Template Library, оказывается... after all, STL stands for STepanov and Lee:)

Відповісти
Підтримати
anonymous 28.09.2009 23:19

Grez, поправьте немного русскую орфографию и вдумайтесь в следующие строки:

I was fortunate, however, to see some great mathematicians at work and became totally immune to a pseudo-mathematical rigor that unfortunately is so common in Computer Science. So becoming a programmer was a really good thing for me. (...) William of Occam used to say “Entia non sunt multiplicanda” — I could translate that as " [abstract] objects are unnecessary". It seems that you have applied the razor of Occam to OOP. I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. The problem that I find with OOP is not just that it is slow, but that it does not allow me to express simplest possible algorithms.

© угадайте кто, это, кстати, и к вопросу о том, можно ли программировать после сорока лет...

Відповісти
Підтримати
Grez 28.09.2009 19:41

Если говоирить про десктоп апп, то помойму ООП настолько сейчас распространено, что рассматривать альтернативные парадигмы, можна только в ключе «нефиг-делать, поэксперементируем».

Відповісти
Підтримати
anonymous 28.09.2009 07:29
Слишком уж широк набор входных параметров задачи — вопрос больше имеет смысл в эффективности того или иного метода для конкретной one. Драйвер железяки ведь тоже можно с использованием соответствующей парадигмы и на Прологе написать, если они мне, к примеру по душе, а толку от него? Есть разные классы задач, грубо:
1. Hardware/RTL
2. RTOS/Drivers
3. Embedded Apps
4. Simple Server Apps
5. Desktop/Client Apps
6. Web Dev
7. HA apps/clusters
8. AI

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

Відповісти
Підтримати
anonymous 27.09.2009 20:23

vs. при том, что здесь недавно публиковалась обросшая мини-холиваром статья «Уявна криза аутсорсу». Я позволю себе процитировать один коммент к ней, имхо, его достаточно:

Сильно сомневаюсь я, что будет толк от этого в Украине. Дело не в оборудовании даже (...) Дело в законах рынка. Берем типичного студента. У него есть выбор — либо влазить в непонятно какое электричество, либо как все нормальные люди заниматься web, java итд (...) У нас нет спроса. Раньше спрос на embedded был в промышленности. Но сейчас ситуация изменилась...

Відповісти
Підтримати
Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 27.09.2009 17:10

Джихады типа «embedded vs. outsorce»

А причём тут versus?

если драйвер — то событийное,

Если драйвер, то выбора, как правило, нет.

Відповісти
Підтримати
anonymous 27.09.2009 16:35
Если бы это была игра или система документооборота — то ООП,
если бы это была вычислительная система — процедурное,
если драйвер — то событийное,
если нужно обрабатывать/анализировать текст по каким-либо правилам — автоматное
и т.д.
Получается — всему своё место.

Но ближе всего к сердцу ООП. Уж очень оно совпадает с тем, как информация представлена в голове.

Відповісти
Підтримати

Підписатись на коментарі

Не підписуватись