Мысли об обобщенном программировании, шаблонах и UML

[Utkin]

Цитирую wiki:

Напрасно. Эта информация мне известна. Вам неизвестна по Хаскеллу. Хотя чего уже там, если для Вас Шеме темный лес, то так и быть оставайтесь в плену иллюзий с++ .

Я говорю что его наличие или отсутствие не считаю за большой плюс или минус

А должны считать большим плюсом. Ибо программисты сами за собой толком подтереть не могут.

Это мое субъективное мнение сложившееся после прочтения учебника по этому языку и не сумев найти хоть одного достойного приложения на нем.

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

Макросы, вы издеваетесь? o_O

Давайте сразу с Вами договоримся - Вы не трындите попусту. Не нужно разглагольствовать о вещах, про которые не имеете ни малейшего представления. Зачем и дальше показывать свое невежество?

Вы бы мне не набор библиотек показали, а реально работающие программы. Которую я могу скачать, запустить и оценить. Т.к. я могу кучу ссылок на библиотеки для др. языков дать.

Про это я уже написал.

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

При чем здесь размер кода?

[MooNDeaR]

С такой радостью читаю эту тему Столько борьбы Я, в общем-то, даже понятия не имел о чем она начиналась, однако по мере дискуссии узнал немного нового
А так...
Scheme is a very simple language, much easier to implement than any other language. © Wiki

[Kostia]

А должны считать большим плюсом. Ибо программисты сами за собой толком подтереть не могут.

Говорите за себя!

[Utkin]

Говорите за себя!

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

[grenles]

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

Для меня все сводится к решению задачи. Я могу не знать новомодных тенденций. Я могу отстать от мира модных программ и реализаций. Мне это и не надо. Для меня важно сделать для клиента задачу так, чтобы она делала то, что нужно ему. А для этого я могу использовать даже в эмуляции fox pro for dos или salary, которую никто и не знает.

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

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

А по поводу кривых программистов - согласен, сам такой. В том смысле, что универсальность, высота языков высокого уровня, не знание каких-то моментов расслабляют. Мысли в духе - "сборщик системы подберет". "а памяти и так много, пользователь еще купит". " диск большой. зачем удалять временные файлы". и прочее. Это я к чему - обилие возможностей развращает мысль, не утруждая поиском оптимальных решений. Иногда надо быстро, но не оптимально.

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

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

[Utkin]

Или будет рождена новая идея и реализована?

Я как раз такую вынашиваю в своем биореакторе .

[Kostia]

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

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

В общем постарался взять понемногу от тех языков которые знаю и которые изучал поверхностно.
1. Всё - объекты
2. Всё доступно для изменения, даже возможность изменить сам язык
3. Динамическая типизация, не строгая
4. Сборка мусора
5. Классы обмениваются данными с помощью сообщений и никак иначе

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

Также возможность динамически расширять объекты прямо во время выполнения. Т.е. если мы добавим новое поле или метод(обработчик сообщений) к TObject, то эти изменения примут все объекты.

Возможность прямо на лету собрать новый объект из кусочков имеющихся.

Возможность отменить действие, если то привело к появлению ошибки.

Каждый объект обрабатывает сообщения в отдельном потоке и если в нем произойдет ошибка, то завершится только поток и к классу отправившему сообщение вызвавшее ошибку, будет отправлено сообщение об ошибки, чтобы тот предпринял меры.

Сообщения тоже есть объекты, которые можно расширять и котором тоже можно посылать сообщения, а также можно послать сообщение самого себя самому себе.

Конструкции if, for, while, рекурсия и т.д. реализуются с помощью сообщений и их обработчиков.

Внутри одного обработчика могут быть другие обработчики и поля, в силу того что это тоже объект и их можно расширять и делать все что можно делать с обычным объектом.

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

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

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

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

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

Самый близкие языки к данной идеи это Smalltalk(Squeak), Ruby, PHP, Python, Lisp, Erlang...

Спасибо.

[Utkin]

for паскалевский или сишный?

[Kostia]

for паскалевский или сишный?

Не совсем понятен вопрос. В общем, оба и к ним в придачу if, while, case, итераторы, рекурсия, все реализуется одним и тем же механизмом.

Каждый объект реализует идею сопоставления входного сообщения с образцом, что-то типа такого(из Ela):

let x = match (expr)
  on [x, 2, y] -> x + y,
  on _ -> 0;

let price = match (product)
  on Cellphone(x) -> x – 5.25
  on Laptop(x) -> x – 29.99
  on Printer(x) -> x – 18.24;

Идея посылки сообщений в большей мере была заимствована не из конкретного языка а из подхода в web программировании, ajax. Можно послать синхронное или асинхронное сообщение, указать обратный адрес. т.е. можно послать сообщение из одного объекта, а приемником указать другой. Можно послать несколько ответов последовательно или вообще DDoS'ить не покладая рук, или просто не послать ответа.
Также хотелось бы убрать и модификаторы доступа, у всех будет возможность прострелить себе ногу, но и также у всех будет возможность отменить изменения. Т.е. расширяя какой либо объект, который был реализован уже давно и не вами, вы рискуете нарушить работу всей системы, поэтому хотелось бы предусмотреть некое подобие инкубатора, попробовали, протестировали, внедрили. При этом программа продолжает работать, а какой-то отдельный поток проводит эти эксперименты и даже если происходит фатальная ошибка, то приложение не крашится, а убивается только поток испытуемого класса, а мы получаем отчет по которому можем сделать некоторые выводы.(потоки камикадзе, это из Erlang)

Как-то так все это видится, но вплотную к этому еще не подходил, совсем нет времени:

class MyInt //описание класса MyInt

  Integer i; //поле

  class + (Integer x) //описание класса +, являющегося обработчиком, принимающего строго только Integer переменные, тут думаю class можно и опускать
     i +: x; //посылаем обработчику + поля i сообщение x
  end+;
...
end;

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

Можно и такие конструкции мутить:

sync varible handler1:handler2:handler3: message -> target;
sync Console write: target;

или в одну строчку

sync varible handler1:handler2:handler3: message -> Console write;

Как-то так, но тут думать нужно. В этом плане по большей мере буду руководствоваться синтаксисом Smalltalk.

[Utkin]

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

Каждый объект реализует идею сопоставления входного сообщения с образцом, что-то типа такого(из Ela):

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