Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 15 16 17 18 [19]
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 73
Особняк
Рынок информационных сейчас делят именно ERP-системы, у которых есть обобщенное программирование. Это именно SAP. 1С, OEBS. Но это не Парус и другие подобные системы. А ведь когда-то Парус и 1С являлись прямыми конкурентами


это нишевые системы. причем у Паруса и 1С, не смотря на их схожесть, "подниши" сильно отличаются. и, я правильно понял, что "обобщенное программирование" - это разработка конфигураций на платформе? если так, то зачем столько шума из ничего
14 апр 18, 00:23    [21338388]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 73
Особняк
Это очень сильные игроки на рынке ПО


для своих ниш - да. но этим не ограничивается автоматизация
14 апр 18, 00:24    [21338391]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 120
love_bach
Особняк
Рынок информационных сейчас делят именно ERP-системы, у которых есть обобщенное программирование. Это именно SAP. 1С, OEBS. Но это не Парус и другие подобные системы. А ведь когда-то Парус и 1С являлись прямыми конкурентами


это нишевые системы. причем у Паруса и 1С, не смотря на их схожесть, "подниши" сильно отличаются. и, я правильно понял, что "обобщенное программирование" - это разработка конфигураций на платформе? если так, то зачем столько шума из ничего
Сейчас поясню.
1. Чтобы доминировать в своей нише нужно иметь обобщенное программирование.
Сейчас Парус и 1С не сравнивают: у одних есть обобщенное программирование, у других - нет.
2. К сожалению не все платформы используют обобщенное программирование.
SAP и 1С используют и у них все нормально.
А платформа Ethereum - нет. И это фигня.
3. Платформа с обобщенным программированием - это высшая форма развития ПО.
14 апр 18, 08:07    [21338597]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
WebSharper
Member

Откуда:
Сообщений: 268
darth
От того, что производитель заюзал такой "интерфейс", соединение стало лучше? Нет конечно. Но гемороя обслуживающему персоналу добавилось.


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

Тоже самое сегодя и в ИТ, с этими растами, свифтами и прочими оккамами.


Аргументация будет?
14 апр 18, 13:20    [21339044]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
mirudom
Member

Откуда:
Сообщений: 866
Особняк
Для тех, кто приступил к использованию выделенных проектировщиков,
считаю важным дать список дополнительной литературы по обобщенному программированию, в котором я немного разбираюсь, ИМХО.
Уважаемый Особняк,
Вы понимаете разницу между математическим аппаратом, который стоит за обобщенным программированием
и выбором правильной абстракции при решении задачи разработки ПО применительно к какому-либо домену ?
15 апр 18, 12:48    [21340629]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 120
mirudom
Особняк
Для тех, кто приступил к использованию выделенных проектировщиков,
считаю важным дать список дополнительной литературы по обобщенному программированию, в котором я немного разбираюсь, ИМХО.
Уважаемый Особняк,
Вы понимаете разницу между математическим аппаратом, который стоит за обобщенным программированием
и выбором правильной абстракции при решении задачи разработки ПО применительно к какому-либо домену ?
Надеюсь, что немного это понимаю. ИМХО.

Наверно, более правильно сказать так: математика в обобщенном программирование желательна, но не обязательно.
Ну то есть, без фанатизма в этом вопросе.

Кстати, обобщенное программирование у SAP,OEBS и 1С реализовано без математики. Или там гомеопатическая доза математики.
При этом у них все очень достойно. Конкурентам и не снилось.

Математика дает колоссальное количество задач, которые можно реализовать в парадигме обобщенного программирования.
Студентам можно без повторения давать задания, Хватит на сто лет.
Очень небольшая часть этих задач может иметь практическую ценность.

Обобщенное программирование без математике и все по-делу - это отлично.
Обобщенное программирование с математикой и все по-делу, - это отлично, реально круто и фундаментально.
15 апр 18, 13:58    [21340729]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
apech-SQL
Member

Откуда:
Сообщений: 15
Спасибо форумчанам – меня озарило!

Я сообразил, каким образом донести до заказчика информацию о том, какая система ему предлагается и одновременно донести до подрядчика (программиста) информацию о том, какую систему ему заказывают. Понимаю, что непонятно (КаломБур) и поэтому поясняю…
В данном случае я позиционируюсь как архитектор, которому заказали Проект некоей Системы, предназначенный для:
• найма Подрядчика, призванного создать Систему;
• обеспечения Подрядчика всей информацией, необходимой для создания Системы;
• организации контроля деятельности Подрядчика в процессе создания Системы;
• организации мотивированной оплаты деятельности Подрядчика в процессе создания Системы;
• организации приемки Системы в эксплуатацию (по фрагментам и в целом);
• при необходимости смены Подрядчика – обеспечения сохранности уже вложенных инвестиций;
• и еще много чего…

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

И чувствовал я в этом некую дыру, а именно: какой комплект документов передавать претендентам на роль подрядчика, чтобы они могли обоснованно называть свои стоимости и сроки. Если передавать весь проект – можно напороться на ситуацию, когда претендент растает в тумане и через некоторое время начнет клепать подобные системы для других заказчиков. Кроме того, всегда стояла проблема демонстрации Заказчику возможностей будущей Системы. Идеальное решение – демонстрация работающего прототипа. Но пока мне не удалось сработать по схеме с прототипом. Вернее - прототип принимался в эксплуатацию и до создания целевой системы не доходило.
И вот – Озарение. Необходимо в Проект добавить раздел
• инструкции пользователей.
Написание инструкций – дело неблагодарное и обычно его оставляют «на потом». Однако, при их написании в процессе проектирования открывается новая возможность: считать Системой то, что способно обеспечить выполнение инструкций.
Вообще-то, раздел «описания бизнес-процессов» содержит в себе всю информацию для инструкций. Но неявно, разбросанно и без картинок. Это тоскливый текст на псевдокоде вида:
«PROCESS Перевод
actors{
КЛТ клиент
ПМК приемщик
ПЧК переводчик
НТР нотариус
}
{
ON ПМК:(Обратился Клиент %КЛТ )
{
ПМК: Принимает %Текст от %КЛТ;
ПМК: Оценивает %Текст.Стоимость,%Текст.СрокВыполнения;
ПМК: Сообщает %Текст.Стоимость,%Текст.СрокВыполнения /* клиенту */ %КЛТ;
IF КЛТ:(Согласен)
{ПМК: Заполняет %Заявка;
КЛТ: Подписывает %Заявка; //? Кто подписывает со стороны ТПП
ПМК: Формирует %Квитанция;
ПМК: Передает %Квитанция /* клиенту */ %КЛТ;
ПМК: Передает %Текст /* Переводчику */ %ПЧК;
EXIT;
}
ELSE …»
Он рассчитан на восприятие программистом. Практика показала, что заказчика тоже можно заставить его читать, но с элементами принуждения. А вот хорошо оформленные инструкции – другое дело. Кроме того инструкции – необходимая часть любой системы.
В общем, выходит, что комплект инструкций можно использовать для
• ознакомления Заказчика с возможностями Системы;
• мотивированного выбора подрядчика. При этом подрядчику передается комплект инструкций, логическая схема сетевого графика и дополнительные требования (временныЫе, надежностные и т. п.). А подрядчик на основании этих документов должен назвать стоимость и прописать сроки в сетевой график.

В общем – вроде все вяжется. Дело за Заказчиками. А с ними – тоскливо… Интересно, почему? Ведь работа по проектной схеме направлена, прежде всего, на соблюдение их интересов. Или им приятнее ходить обвешенными лапшой из «спринтов» и «микросервисов»?
Может быть, форумчане поделятся своими соображениями о том, почему проектный подход столь мало востребован, невзирая на его очевидные достоинства? Интересует мнение, прежде всего, потенциальных заказчиков (IT – директоров, руководителей организаций и т. п.).
Если кто-то не хочет писать в форум во избежание шакальих нападок – пишите мне на apech52@gmail.com. Я постараюсь обобщить и выложу в форум…
19 апр 18, 05:55    [21350721]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
L_argo
Member

Откуда:
Сообщений: 19
Абсолютно дурацкий псевдокод. Умничание.

Просто напишите алгоритм словами.
И читать легче (особенно неспециалистам) и тонкие нюансы можно подробно описать.
19 апр 18, 09:45    [21351017]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Никанор Кузьмич
Member

Откуда: Москва
Сообщений: 286
Особняк
Кстати, обобщенное программирование у SAP,OEBS и 1С реализовано без математики. Или там гомеопатическая доза математики.
При этом у них все очень достойно.
Не знаю, что там достойного вы у них нашли. Мне как-то везло, не сталкивался с ними, но вот год назад свела судьба с OEBS-ом - хочется оторвать руки не только тем, кто это проектировал и программировал, но и всем, кто просто рядом стоял, включая уборщиц. О внутренностях САПа и одинэса слышал примерно такие же отзывы. Хороших - не слышал.

Особняк
Или там гомеопатическая доза математики.
Для начала, там гомеопатическая доля здравого смысла.
19 апр 18, 09:49    [21351036]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Алекссс
Member

Откуда:
Сообщений: 1746
Никанор Кузьмич, что там не так конкретно?
19 апр 18, 10:44    [21351309]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 52110
Блог
Алекссс
Никанор Кузьмич, что там не так конкретно?

Всё.
19 апр 18, 11:09    [21351420]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Никанор Кузьмич
Member

Откуда: Москва
Сообщений: 286
Алекссс
Никанор Кузьмич, что там не так конкретно?
Уже ничего. Заявление на увольнение я вчера написал, остальное не мои проблемы.

***

Больше всего не нравится, что все выглядит жутко переусложненным. Такое ощущение, что проектировщики разрабатывали по принципу: "мы придумаем любые, самые безумные функциональные возможности, какие только может захотеть заказчик, и все их запрограммируем, а если кому-нужно что-то попроще, мы упростим за дополнительную плату".
Правда, кроме OEBSа у нас куча всякого го всякой всячины, я не уверен, что правильно понимаю границы, где OEBS, а где уже нет.
19 апр 18, 11:19    [21351467]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Никанор Кузьмич
Member

Откуда: Москва
Сообщений: 286
softwarer
Алекссс
Никанор Кузьмич, что там не так конкретно?

Всё.


У меня первой мыслью было написать тоже самое, но я постеснялся. В конце концов, меня только краешком зацепило, вдруг я что-то не так понял.
19 апр 18, 11:21    [21351477]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Никанор Кузьмич
Member

Откуда: Москва
Сообщений: 286
Особняк
обобщенное программирование у SAP,OEBS и 1С
Да, самое главное забыл спросить: что вы называете "обобщенным программированием" применительно к OEBS, например? Википедия определяет это как "парадигма программирования, заключающаяся в таком описании данных и алгоритмов, которое можно применять к различным типам данных, не меняя само это описание" (там дальше примеры для ООП-языков идут). В PL/SQL такого тупо нет. Можно конечно извратиться и сделать через динамический SQL, но это будет именно что извращение, и в OEBS я такого не видел.
19 апр 18, 12:09    [21351647]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Алекссс
Member

Откуда:
Сообщений: 1746
Никанор Кузьмич
описании данных и алгоритмов, которое можно применять к различным типам данных, не меняя само это описание" (там дальше примеры для ООП-языков идут). В PL/SQL такого тупо нет.

ref cursor, object types, overriding или что имеется в виду?
Никанор Кузьмич
Можно конечно извратиться и сделать через динамический SQL, но это будет именно что извращение, и в OEBS я такого не видел.

динамический SQL - няшка, но если для вас изват, то по вашей же логике OEBS то что надо
19 апр 18, 12:24    [21351691]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 120
Никанор Кузьмич
Особняк
Кстати, обобщенное программирование у SAP,OEBS и 1С реализовано без математики. Или там гомеопатическая доза математики.
При этом у них все очень достойно.
Не знаю, что там достойного вы у них нашли. Мне как-то везло, не сталкивался с ними, но вот год назад свела судьба с OEBS-ом - хочется оторвать руки не только тем, кто это проектировал и программировал, но и всем, кто просто рядом стоял, включая уборщиц. О внутренностях САПа и одинэса слышал примерно такие же отзывы. Хороших - не слышал.

Особняк
Или там гомеопатическая доза математики.
Для начала, там гомеопатическая доля здравого смысла.
У Вас симптомы передозировки ERP-системами.
Давайте начнем с маленьких гомеопатических доз.
Рассмотрим гипотетическую ИС, которая занимается только классификаторами (по научному MDM).
1. Вы пробовали использовать классификаторы в ERP-системах?
Без всякого программирования в настройках настраивается классификатор.
Если заказчик или аналитик забыли какой-то классификатор, то трагедии Шекспира не получится.
2. Вы кстати за что:
за то, чтобы запрограммировать классификаторы
за то, чтобы настроить классификаторы?
3. Мое самое скромное ИМХО. Любая уважающая сама себя ИС должна иметь настраиваемые классификаторы. Это закон IT.

4. Вы меня в следующем посте спросили, что такое обобщенное программирование.
Отвечаю. Настраиваемые классификаторы - это пример обобщенного программирования.
19 апр 18, 12:31    [21351705]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 120
apech-SQL
И чувствовал я в этом некую дыру, а именно: какой комплект документов передавать претендентам на роль подрядчика, чтобы они могли обоснованно называть свои стоимости и сроки. Если передавать весь проект – можно напороться на ситуацию, когда претендент растает в тумане и через некоторое время начнет клепать подобные системы для других заказчиков. Кроме того, всегда стояла проблема демонстрации Заказчику возможностей будущей Системы. Идеальное решение – демонстрация работающего прототипа. Но пока мне не удалось сработать по схеме с прототипом. Вернее - прототип принимался в эксплуатацию и до создания целевой системы не доходило.
Мы с Вами стратегические союзники, поскольку Вы признаете выделенных проектировщиков.
Вы рассматриваете даже более принципиальную ситуацию, когда проектировщики, разработчики и заказчики - это три юридических лица.
Вы подняли очень интересный и сложный вопрос: "Какие документы и кому нужно показывать". Попытаюсь на него ответить

1. Упрощенно проектировщики разрабатывает концепции, ТЗ и прототипы.
Все, что не нужно в ТЗ, попадает в концепции.
2. Разработчикам нужно показывать ТЗ и прототипы.
3. Заказчику нужно показать
- концепцию "Что у заказчика есть сейчас."
- концепцию "Как будет после внедрения ПО"
- концепцию "Как будет через 5-10 лет. Взгляд снаружи"
- ТЗ и прототипы (по желанию)
4. У проектировщика остаются
- концепция "Почему сейчас ПО нужно сделать именно так."
-концепция "Как будет через 5-50 лет. Взгляд изнутри".
И это очень много.
5. Процесс познания ПО бесконечен во времени, поэтому без работы не останетесь.
19 апр 18, 13:35    [21351919]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 15958
автор
Чтобы доминировать в своей нише нужно иметь обобщенное программирование


WAT?
19 апр 18, 14:00    [21351994]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7886
Никанор Кузьмич

Такое ощущение, что проектировщики разрабатывали по принципу: "мы придумаем любые, самые безумные функциональные возможности, какие только может захотеть заказчик, и все их запрограммируем, а если кому-нужно что-то попроще, мы упростим за дополнительную плату".

Думаю, примерно так и есть :)
Говоря о тиражируемых ERP надо понимать, что их проектировщики не ставили перед собой целью создать простую, прозрачную, легкую в обращении и поддержке систему - это напрямую противоречит бизнесу :)
Тиражируемая ERP, рассчитывающая на коммерческий успех и серьезную долю рынка, должна быть
- мощной
- расширяемой
- достаточно надежной
- иметь средневысокий порог вхождения (полезно для vendor lock-а, бизнеса по обучению и т.п.)
Все эти качества присутствуют у 1С, OEBS и, подозреваю, SAP. Поэтому отрывать руки, конечно, никому не надо - люди решали стоящие перед ними задачи и решили вполне хорошо.
Другое дело, что если некто говорит "Я сделаю в своей (совершенно нетиражируемой, для внутреннего использования) системе так же как в 1С, потому что 1С это круто!" - с его компетентностью как архитектора имхо тоже все ясно :)
19 апр 18, 14:23    [21352059]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Никанор Кузьмич
Member

Откуда: Москва
Сообщений: 286
Особняк
4. Вы меня в следующем посте спросили, что такое обобщенное программирование.
Отвечаю. Настраиваемые классификаторы - это пример обобщенного программирования.
А, вот оно чо. Тогда понятно.

Особняк
Давайте начнем с маленьких гомеопатических доз.
Гомеопатия, как известно, не работает.
Но прежде чем что-то начинать, позвольте поинтересоваться.
Вот, допустим, существует некая информационная система совсем-совсем без настраиваемых классификаторов. И? Она не имеет права называться информационной системой? Она не имеет права на существование? Она недостойна быть внедренной в банке, работать в котором большая честь? Еще какие-то опции? Обозначьте как-то ее экзистенциальный статус, пожалуйста.

Алекссс
динамический SQL - няшка, но если для вас изват
Конечно няшка! Но. Я хотел узнать, что такое "обобщенное программирование" в OEBS. В википедии в качестве примера приводится конструкция на С++:
template <typename T> T max(T x, T y)
...
В PL/SQL таких нет, но их, теоретически, можно имитировать с помощью динамического SQL. Вот это я и назвал извращением. Как оказалось, все намного приличнее, чем я боялся.
19 апр 18, 14:54    [21352189]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 120
Никанор Кузьмич
Особняк
4. Вы меня в следующем посте спросили, что такое обобщенное программирование.
Отвечаю. Настраиваемые классификаторы - это пример обобщенного программирования.
А, вот оно чо. Тогда понятно.

Особняк
Давайте начнем с маленьких гомеопатических доз.
Гомеопатия, как известно, не работает.
Но прежде чем что-то начинать, позвольте поинтересоваться.
Вот, допустим, существует некая информационная система совсем-совсем без настраиваемых классификаторов. И? Она не имеет права называться информационной системой? Она не имеет права на существование? Она недостойна быть внедренной в банке, работать в котором большая честь? Еще какие-то опции? Обозначьте как-то ее экзистенциальный статус, пожалуйста.

Алекссс
динамический SQL - няшка, но если для вас изват
Конечно няшка! Но. Я хотел узнать, что такое "обобщенное программирование" в OEBS. В википедии в качестве примера приводится конструкция на С++:
template <typename T> T max(T x, T y)
...
В PL/SQL таких нет, но их, теоретически, можно имитировать с помощью динамического SQL. Вот это я и назвал извращением. Как оказалось, все намного приличнее, чем я боялся.
Я вижу, что гомеопатия на Вас не действует, а большие дозы могут убить.
Я отвечу, но за правильность выбора дозы я ответственности не несу.

1. Я всего лишь написал, что мне не нравятся системы, использующие не настраиваемые классификаторы. И сто раз написал слово ИМХО. Мы здесь рассуждаем как настоящие гуманитарии в терминах "нравится" и "не нравится". И не более того.
2. Про обобщенное программирование я завел речь, потому что считаю, что это удел выделенных проектировщиков. Вот такой фигней им придется заниматься, если они выделенные.
3.По поводу определения обобщенного программирования.
Оно не удачное.
Никогда не читайте его перед обедом.
От Википедии может сложится впечатление, что если в языке нет абстрактных классов и интерфейсов, то в нем нельзя делать обобщенное программирование.
Вообще ООП можно реализовывать на чистом С. Были такие работы. Не хочу их гуглить сейчас.
Однозначно, обобщенное программирование можно реализовывать без шаблонов и дженериков.
Как правило обобщенное программирование требует писать динамический код и динамический SQL. И Ваша догадка об этом абсолютно верна.

Важно суть.
Обобщенное программирование - это реализация обобщенных алгоритмов для разных вариантов данных.
Может так лучше.
19 апр 18, 16:13    [21352451]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
serge79y
Member

Откуда: Москва
Сообщений: 20
Особняк
Важно суть.
Обобщенное программирование - это реализация обобщенных алгоритмов для разных вариантов данных.
Может так лучше.


Тавтология получается. Любой алгоритм предназначен для решения определенного класса задач, а класс задач и есть обобщения конкретных случаев. В итоге любое программирование будет обобщенным программированием.
19 апр 18, 19:23    [21352938]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 120
serge79y
Особняк
Важно суть.
Обобщенное программирование - это реализация обобщенных алгоритмов для разных вариантов данных.
Может так лучше.


Тавтология получается. Любой алгоритм предназначен для решения определенного класса задач, а класс задач и есть обобщения конкретных случаев. В итоге любое программирование будет обобщенным программированием.
Лично для Вас вторая попытка определения обобщенного программирование.
Обобщенное программирование - это реализация обобщенных алгоритмов, которые умеют работать с более чем одним вариантом данных.

Если для каждого классификатора ИС делается своя реализация, то это не обобщенное программирование.
Если одна реализация обслуживает два классификатора - то это обобщенное программирование.
19 апр 18, 20:49    [21353067]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 15 16 17 18 [19]
Все форумы / Работа Ответить