Обсудим идеи как можно радикально облегчить и упростить программирование?

Цитата

pattern matching

Появился ещё в 70-х годах прошлого века.
Это наше будущее?

И это форум программистов
Прикреплённый файл_____________________________________.png (34,46 Кбайт, скачиваний: 1278)

Добавлено 12.02.16, 14:20
[img]http://forum.sources.ru/index.php?act=Attach&type=post&id=3652736&attach_id=48774[/img]

Цитата Исмаил Прокопенко @ 07.02.16, 14:57

Важность формы представления задачи трудно переоценить. Иногда чтобы решить задачу достаточно выбрать правильную форму её представления и решение станет очевидным.

Неверно. Форма представления всего-лишь определяет путь решения задачи. А после этого этим путем нужно пройти, то есть, написать тот самый миллион строк plain text. И, хотя путь будет очевиден, работающей программы (и решения задачи) по-прежнему не будет, пока plain text не будет написан.

Цитата Исмаил Прокопенко @ 07.02.16, 14:57

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

Опять неверно. Изменение точки зрения (залезть на колокольню) всего-лишь облегчает выбор пути, расширяя горизонты. Но это не является решением задачи.

Экономия времени существует лишь одна - если с колокольни видно, что уже существует программа, которая решает ТЗ с приемлемой точностью.

А для этого нужно, чтобы прога была уже написана.

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

Но тут (как обычно) возникает задача "не увидеть за деревьями леса". То есть, в этом хламе из готового кода, нужно ориентироваться.

И эту задачу с собственных плеч все время пытаются переложить на чужие - то на компилятор, то на ИИ. И по-прежнему безуспешно. И далее все будет точно также мрачно и беспросветно. Потому что критерии точности и приемлемости выходных данных можно определить только лично. А вот желания это сделать - нет. Отсюда и проблемы. И это - вечные проблемы. Они нерешаемы в принципе.

Цитата Исмаил Прокопенко @ 07.02.16, 14:57

PLAIN-текст такой формой не является ни с какой стороны.

Plain text является абсолютно точным инструментом изложения алгоритма, поэтому он незаменим (как и клавиатура). Все попытки подменить точность какой-то бредовой аморфной нечеткой логикой обречены на провал.

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

А в реальных условиях эксплуатации в ней начинают всплывать баги. Потому что она начинает работать с другими данными. И прога бессильна снять с себя эти ограничения, которые в нее были заложены программистом. Ни ИИ, ни прочие CASE-средства (Computer Aided Software Engineering) самостоятельно это решить не могут, потому что творцом программы всегда является человек, а они (CASE и прочее) - всего-лишь инструменты помощи. Которые можно юзать, а можно на них забить.

Но есть сроки, в которые нужно уложиться. И тут действительно есть фактор не уложиться в сроки. Но это не означает, что не придется писать код. К тому же, этот уже готовый код может продаваться по такой цене, что все сразу решат, что потратить в три раза больше времени на собственную разработку - очень выгодно.

Вообще тема - баян.

Еще в 1975 году была издана книжка "Мифический человеко-месяц", которая по-прежнему актуальна.

Все попытки попереливать из пустого в порожнее закончатся также бесперспективно - серебряной пули нет.

И не будет.

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

Абстракция растет, никто не загорает пикселы, чтобы нарисовать линию. Уже есть линии в квадрат, квадрат в куб и еще вращаться это может уже и т.д.
Но даже с заливкой текстур это будет только мультфильм (вектор), а не кинофильм (растр), который передает всё многообразие окружающего мира да и то в плоскости. Как из векторов построить требуемый растр? Попиксельно только...

Хотя сейчас по сути все программы - это мультики, собранные из кирпичиков.
Только много этих разных кирпичиков, и не сложней ли в них ориентироваться будет в общем случае.
Один человек не может знать всего даже уже известное человечеству.
Нужна специализация и т.д. и что-то это уже напоминает идущую эволюцию. Хорошо, если на новом ветке ее спирали.
Сколько всего в WinAPI, Net Frameworke'e, а есть еще и много всего разного и на разных платформах и с разной степенью абстракции и вложенности.

А ближе к реальности - это юридические законы надо переписывать на алгоритмических языках, а не программы переписывать на естественном языке. На данном уровне развития.

А потом появился 3D принтер, который строит дома. Только строит он их по другому принципу, а не из кирпичиков и слоя цемента между ними.
А потом появился 3Д принтер, который напечатал другой 3Д принтер.
Прогресс в ИИ не стоит на месте, куда-то все движется с разной степенью успешности. Краткосрочно - видно, долгосрочно - поживем, увидим мы или далекие потомки.

А пока ссылка на ДРАКОН вот была. Может это и есть не самая плохая реализация этих идей на данном уровне развития.

Цитата nash @ 24.02.16, 00:00

А ближе к реальности - это юридические законы надо переписывать на алгоритмических языках

Только представьте во что превратится раскрытие строки:

if( езда_в_пьяном_виде )

Там же и возраст человека, и его состояние, состояние прибора, вид транспорта, фильм это или нет, испытание ли машины/прибора, ... Не осилить.

Цитата Славян @ 24.02.16, 01:24

Не осилить.

с нечеткой логикой это делается на раз

Цитата

Даже в программе, написанной на объектно-ориентированном языке

Именно ООП и есть зло.

То обстоятельство, что многие пытаются запаковать в черный ящик свой код и выдать для других на выходе КОНФЕТКУ, а на деле получается что большинству нужна именно то что запрятано... И лезут более продвинутые через одно место поправлять, то что сделано другим. Отсюда и все беды. Ведь для того что бы сделать объект, который просто повторно использовать - тратится в десятки раз больше времени, нежели, если просто скопировать и вставить нужный код и обойтись функциональным программированием.

Цитата cezar @ 21.06.16, 20:37

Именно ООП и есть зло.

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

Цитата cezar @ 21.06.16, 20:37

Именно ООП и есть зло.

Поддержу коллегу.

Вот существует стереотип, что якобы ООП якобы помогает бороться со сложностью задачи.
Что в ООП путем разбивки задачи на классы и уменьшения связности/зависимости мы уменьшаем сложность задачи.

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

Но давайте разберемся и вникнем в детали (реализации). Ведь, как известно, «дьявол в деталях»©.

Говорят «интерфейс» и «реализация».
А что такое «интерфейс» класса?
А это ни что иное как список заголовков PUBLIC методов.
А что такое «заголовок метода»?
Это имя метода плюс список ТИПОВ его параметров.
И вот мы подходим к ключевому моменту: А что такое «типы параметров»?
А это не что иное как КЛАССЫ, которые описаны вне данного класса, и которые также имеет интерфейс.

Бинго!
Получается, что раскрутив всю логическую цепочку, мы видим, что фактически интерфейсом класса является СПИСОК ОПИСАННЫХ ВОВНЕ ДРУГИХ КЛАССОВ. А у тех классов интерфейс – это тоже список описанных вне их классов. И т.д.

Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ.
Т.е. при ООП никакого упрощения программирования не происходит.
Напротив, из-за того, что «ВСЕ СВЯЗАНО СО ВСЕМ» произошло существенное усложнение программирования.
Миф об ООП развенчан.
Спасибо за внимание.

© Все права защищены.
При цитировании этой информации где-бы то ни было, ссылки на меня обязательны

Цитата Исмаил Прокопенко @ 06.11.16, 09:50

Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ.

Так это ж круто, это ж как получить 2=2 : и красиво, и понятно, и ничему не противоречит!

Цитата Исмаил Прокопенко @ 06.11.16, 09:50

Т.е. при ООП никакого упрощения программирования не происходит.

А это почему? Откуда появился этот вывод "Т.е." ?

Цитата Славян @ 06.11.16, 11:11

Откуда появился этот вывод

А поднять глаза на сообщение выше Вашего никак?

Добавлено 06.11.16, 11:33

Цитата Славян @ 06.11.16, 11:11

Так это ж круто

Ага. До тех пор пока не возникнет потребность что-то изменить.
А такая потребность возникает постоянно

Добавлено 06.11.16, 11:36

Цитата Славян @ 06.11.16, 11:11

Цитата Исмаил Прокопенко @ 06.11.16, 09:50

Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ.

Так это ж круто

Если кто не понял - это была "гипербола" (литературный прием такой).
Естественно что буквально когда "все связано со всем" реально не бывает.
Я просто так эмоционально хотел показать свой негатив по поводу большого кол-ва возникающих запутанных связей при ООП.

Так как хоть и не "все связано со всем" но реально кол-во связей при ООП возникает гораздо больше, чем пишут в книжках и учебниках

Добавлено 06.11.16, 11:40
И получается что никакой "инкапсуляции" по факту нет

Так ты не можешь изменить внешний класс "без оглядки" на тот, где он используется как параметр, поле или базовый.

Например, в общем случае, ты не можешь НЕЗАВИСИМО изменять число методов, их имена и сигнатуры

Добавлено 06.11.16, 11:41
Т.е. при проектировании ты должен, как минимум, продумывать имена и сигнатуры методов СРАЗУ ВСЕХ взаимосвязанных классов и потом не можешь их менять. Вот где попа.

СРАЗУ ВСЕХ, Карл.

И это называется "решать задачу по частям"?

Сообщение отредактировано: Исмаил Прокопенко - 06.11.16, 11:47

Цитата

Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ.

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

Цитата

из-за того, что «ВСЕ СВЯЗАНО СО ВСЕМ» произошло существенное усложнение программирования

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

Цитата

И получается что никакой "инкапсуляции" по факту нет

А что тут подразумевается под "инкапсуляцией"? Чем не нравится сокрытие деталей реализации?

Цитата

Т.е. при проектировании ты должен, как минимум, продумывать имена и сигнатуры методов СРАЗУ ВСЕХ взаимосвязанных классов и потом не можешь их менять.

Не могу представить такую ситуацию. Разве что наложить кучу божественных классов, каждый из которых и шьет, и жнет, и на дуде играет. Но ведь это неправильный подход! Похожее поведение у разных по сути классов? Есть интерфейсы и примеси. Одинаковые имена методов с разным поведением? Это можно предвидеть заранее и сразу давать методам понятные имена, чем специфичнее поведение, тем специфичнее имя.

Цитата AVA12 @ 06.11.16, 15:04

Вообще-то иерархия

А классы-параметры?
А классы-поля?
Или "тут видим, а тут не видим"(с)?

Добавлено 06.11.16, 15:55

Цитата AVA12 @ 06.11.16, 15:04

так что никаких "все со всеми" быть не может

"Тут читаем, а тут не читаем"(с)?
Я же написал:

Цитата Исмаил Прокопенко @ 06.11.16, 11:31

Если кто не понял - это была "гипербола" (литературный прием такой).
Естественно что буквально когда "все связано со всем" реально не бывает.
Я просто так эмоционально хотел показать свой негатив по поводу большого кол-ва возникающих запутанных связей при ООП.

Добавлено 06.11.16, 15:56

Цитата AVA12 @ 06.11.16, 15:04

Нифига. В прцедурном подходе

А при чем тут он?
Я о нем не говорил.

Добавлено 06.11.16, 15:57

Цитата AVA12 @ 06.11.16, 15:04

Чем не нравится сокрытие деталей реализации?

Тем что эти "детали" зависят от внешних классов.
А значит не инкапсуляция это никакая

Сообщение отредактировано: Исмаил Прокопенко - 06.11.16, 15:58

Цитата Исмаил Прокопенко @ 06.11.16, 15:54

А классы-параметры?
А классы-поля?
Или "тут видим, а тут не видим"(с)?

Почему обязательно классы? Это могут быть интерфейсы или вовсе параметры шаблона неведомого типа.