Здравствуйте, yumi, Вы писали:
E>>Хронология здесь не причем.
Y>Спасибо, после выделенного с Вами дальше можно не продолжать беседу.
...и бояре иноземные, Федор, не чета нашим, россейским: мылом моютца и вина вусмерть не пьют, особливо с утра. И наукам разным с младых ногтей обучаются -- то у них "образование" зовется. Одкель даже с холопами своими по культурному разговаривают. Наш-то барин, как что не по нем, так: "Пшел прочь, смерд!" А ихний: "с Вами дальше можно не продолжать беседу". И вот чудно: умишком-то чуешь, что послал он тебя туды же, а на душе все равно приятно...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Кодёнок,
Кё>А со мной будешь? Моя русский каросый!
Кё>Возьми один из следующих языков: C#, Nemerle, Scala, Ruby, Python, и попробуй дать вразумительные ответы на эти вопросы, которыми их авторам якобы следовало задаться перед созданием.
Хм, не скажу про всю Одессу, но про Scala кое-что можно возразить
И про Nemerle — информация о типах в макросах ещё не встречалась ни в Лисп, ни в Dylan, ни в PLOT, и по очевидным причинам эта фича не может быть выкушена оттуда и добавлена в уже существующий язык .
Да, видел я сайт и презентацию языка PLOT. Однако, думаю ты согласишься, что вклад этого языка чисто синтаксический. И, кроме того, это (пока?) чисто мысленный эксперимент без имплементации вообще. Поэтому у него, увы, будущее в тумане.
Здравствуйте, Mr.Cat, Вы писали:
MC>информации ты пока совсем немного дал
Информации немного в основном потому, что сделал еще не очень много.
MC>- Твой язык — это ...
Ленивые вычисления, программирование задач, в которых требования изменяются так быстро, что жесткие структуры данных не имеют особого смысла, совмещение декларативного и императивного стиля.
Но пока выполнена только первая часть, да и то не полностью. Вот еще несколько деталей:
Возможно присваивание значения результату функции:
=(x() X)
Не припомню, чтобы я видел язык, где такое реализовано. Для обращения к глубинам какой-либо структуры приходится писать две ф-и — геттер и сеттер. По-моему, не слишком удобно. Я понимаю, что это помогает сокрытию данных, но здесь речь не об этом. Мой способ и сокрытие данных в принципе не противоречат друг другу.
Переменные имеют следующие области видимости: программа, ф-я со вложенными ф-ями, тело ф-и. Некоторые ф-и будут иметь два варианта, деструктивный и недеструктивный, какая именно будет вызываться, будет определяться первым параметром: f(ds X), f(nd X).
Элементы программы максимально атомизированы. Например, переменная не связано жестко ни со своим значением, ни с именем, мы можем сменить имя и при этом это будет та же переменная. Та же философия атомизации, возможно, приведет к именам из нескольких слов. К сожалению, это не будет выглядеть как f n x, потому что программист где-нибудь забудет, к чему относилось n — к f или x: f_n(x), f(n_x). Это будеть выглядеть так: ir(f n)(x)
Указатели будут реализованы прозрачно, а точнее, с изменяемой прозрачностью. Т. е. обычно они не будут видны, но когда понадобятся — их можно будет получить и использовать.
Но семантику я пока оставил на потом. Первоочередная цель — оптимизация.
Вот более приличная версия, чем та, которую я оставил раньше, правда, еще нет сборки мусора и обработки ошибок: http://files.rsdn.ru/48064/Drive%200.rar
Программировать сложно. Но не программировать еще сложнее.
Небольшой совет по поводу дизайна языка программирования
LCR>>Перед тем, как ты погрузишься в изобретение Твоего Языка Программирования (далее ТЯП), задай себе несколько вопросов:
LCR>>1. Какую задачу новый язык решает? Как сформулировать ответ наиболее точно?
LCR>>2. Как я могу продемонстрировать красоту решения зтой задачи с помощью нового языка? Как сформулировать ответ наиболее точно?
LCR>>3. Существуют ли другие решения? Решают ли другие языки эту задачу? Как? Какие преимущества твоего решения? Преимущества их решения? Какие недостатки у твоего решения? Недостатки их решения?
LCR>>4. Как я могу продемонстрировать, что моё решение не может быть выражено в терминах другого языка? То есть, каково уникальное свойство моего языка, которое отсутствует в других, благодаря чему это решение стало возможным?
LCR>>5. Какие части моего языка существенны для этого уникального свойства?
E>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от E>Б.Страуструпа,
Да, конечно. C++ был создан в 1983-м году с целью решить вполне конкретные задачи, которые не мог адекватно решить C: абстрактные и пользовательские типы данных, ООП, обощённое программирование. Причём, нужны были также возможность низкоуровневого доступа, и совместимость с унаследованным кодом на C. Ни один из существующих тогда (1983-й если я не ошибаюсь) языков не мог решать все эти задачи так же успешно, как C++. (Lisp, Smalltalk, Forth и т.п. конечно могли многое, но компилировать код на C увы нет).
E>Дж.Госслинга,
Да. На 1995-й год виртуальная машина (секьюрность, переносимость), сборка мусора, чистая объектная система, рефлексия и динамическая загрузка классов — это фичи, в полной мере отсутствующие в С++. Smalltalk не мог выполнять роль Java из-за динамической типизации.
E>А.Хэйлсберга,
Ммм, удовлетворила бы разве что относительно C# >=2.0 — дженерики, лямбды и прочее. Причиной разработки C# называют множество вещей, но кажется главная в том, что Java была разработана не в Microsoft.
E>Г.в.Россума, Я.Матцумото...
Вот здесь сомнительно. "Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language."
Небольшой совет по поводу дизайна языка программирования
LCR>>>Перед тем, как ты погрузишься в изобретение Твоего Языка Программирования (далее ТЯП), задай себе несколько вопросов:
LCR>>>1. Какую задачу новый язык решает? Как сформулировать ответ наиболее точно?
LCR>>>2. Как я могу продемонстрировать красоту решения зтой задачи с помощью нового языка? Как сформулировать ответ наиболее точно?
LCR>>>3. Существуют ли другие решения? Решают ли другие языки эту задачу? Как? Какие преимущества твоего решения? Преимущества их решения? Какие недостатки у твоего решения? Недостатки их решения?
LCR>>>4. Как я могу продемонстрировать, что моё решение не может быть выражено в терминах другого языка? То есть, каково уникальное свойство моего языка, которое отсутствует в других, благодаря чему это решение стало возможным?
LCR>>>5. Какие части моего языка существенны для этого уникального свойства?
E>>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от E>>Б.Страуструпа, LCR>Да, конечно. C++ был создан в 1983-м году с целью решить вполне конкретные задачи, которые не мог адекватно решить C: абстрактные и пользовательские типы данных, ООП, обощённое программирование. Причём, нужны были также возможность низкоуровневого доступа, и совместимость с унаследованным кодом на C. Ни один из существующих тогда (1983-й если я не ошибаюсь) языков не мог решать все эти задачи так же успешно, как C++. (Lisp, Smalltalk, Forth и т.п. конечно могли многое, но компилировать код на C увы нет).
Не C. А Simula. Проблема была в том, что Simula предоставляла необходимые абстракции, но не давала должной эффективности. Язык C вылез просто как удобная платформа для эффективной реализации идей. (Как JVM в случае со Scala). Тем более, что обобщенное программирование, множественное наследование и обработка исключений появились в C++ уже впоследствии, в районе 1988-1989-годов. Т.е. через десять лет после начала работ над C with Classes.
При этом, если взглянуть на упомянутые вопросы:
1. Тут вроде бы ответ есть.
2. Никакой красоты.
3. Существуют. Та же Simula. И недостатки лежат не в самом языке Simula, а в деталях реализации.
4. Нельзя продемонстрировать. То, что позволял делать C with Classes, позволяли делать и другие языки. Различия только в степени эффективности.
E>>Дж.Госслинга, LCR>Да. На 1995-й год виртуальная машина (секьюрность, переносимость), сборка мусора, чистая объектная система, рефлексия и динамическая загрузка классов — это фичи, в полной мере отсутствующие в С++. Smalltalk не мог выполнять роль Java из-за динамической типизации.
А как же Objective-C и Modula с Oberon-ами? Приверженцы этих языков очень сильно убеждены, что Java -- это вовсе не C++, а сильно испорченные C++ным синтаксисом их творения.
E>>А.Хэйлсберга, LCR>Ммм, удовлетворила бы разве что относительно C# >=2.0 — дженерики, лямбды и прочее. Причиной разработки C# называют множество вещей, но кажется главная в том, что Java была разработана не в Microsoft.
Ну вот в том-то и дело. Очень яркий пример, когда язык не добавляет ничего нового. Просто является несколько другой реализацией уже известных идей (С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi) + перегрузка операторов (хорошо известная по C++ и куче других языков)). Зато это отличная площадка для дальнейшего развития в свою сторону.
Почти то же самое произошло и с C++, и с Python, и c Ruby.
Так что на поверхности лежат яркие примеры того, как успешные и восстребованные языки создавались явно не в соответствии с данным опросником.
Если мне не изменяет склероз, с Haskell-ем сложилась почти аналогичная картина. Когда хотели сделать современный общедоступный функциональный язык, то на роль базиса предлагался Miranda. Но Miranda был коммерческим языком, и его владельцы не сильно горели желанием делиться своими детищем с общественностью. Поэтому-то и было решено создавать новый язык, чтобы затем в нем можно было реализовывать разные новые идеи без оглядки на коммерческие интересы поставщиков средств разработки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197,
E>>>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от E>>>Б.Страуструпа, LCR>>Да, конечно. C++ был создан с целью решить вполне конкретные задачи, которые не мог адекватно решить C: абстрактные и пользовательские типы данных, ООП, обощённое программирование. Причём, нужны были также возможность низкоуровневого доступа, и совместимость с унаследованным кодом на C. Ни один из существующих тогда (1983-й если я не ошибаюсь) языков не мог решать все эти задачи так же успешно, как C++. (Lisp, Smalltalk, Forth и т.п. конечно могли многое, но компилировать код на C увы нет).
E>Не C. А Simula. Проблема была в том, что Simula предоставляла необходимые абстракции, но не давала должной эффективности.
см. ниже E> Язык C вылез просто как удобная платформа для эффективной реализации идей. (Как JVM в случае со Scala). Тем более, что обобщенное программирование, множественное наследование и обработка исключений появились в C++ уже впоследствии, в районе 1988-1989-годов. Т.е. через десять лет после начала работ над C with Classes. E>При этом, если взглянуть на упомянутые вопросы: E>1. Тут вроде бы ответ есть. E>2. Никакой красоты.
Ну как же? Специально поднял книжку Страуструпа, там вон что написано:
Красота!
E>3. Существуют. Та же Simula. И недостатки лежат не в самом языке Simula, а в деталях реализации. E>4. Нельзя продемонстрировать. То, что позволял делать C with Classes, позволяли делать и другие языки. Различия только в степени эффективности.
Я повторю тут твою фразу выше: E>... А Simula. Проблема была в том, что Simula предоставляла необходимые абстракции, но не давала должной эффективности...
И следовательно, не предоставляла решения указанных задач. Ибо в данном случае, под глаголом "решает" конечно же имеется ввиду вопросы практического решения, ибо с теоретическими решениями давно всем всё ясно.
Более того:
From the earliest days of Simula, containers (such as lists) had been intrusive: An
object could be put into a container if and only if its class had been (explicitly or
implicitly) derived from a specific “Link” or “Object” class containing the link
information needed by the compiler.
Simula containers and arrays had this irregular treatment of built-in and user-defined
types (only some of the latter could be in containers) and of containers and arrays (only
arrays could hold fundamental types; arrays couldn’t hold user-defined types, only
references to user-defined types).
В C++ этих бородавок по крайней мере нет (но, конечно, дофига своих собственных).
У Objective-C насколько мне помнится были те же самые проблемы с производительностью, "благодаря" которым он почти впал в забвение (второе рождение ему подарила Apple своей Cocoa). То есть решение как-бы есть, но воспользоваться им Страуструп не мог — тормоза-с...
E>>>Дж.Госслинга, LCR>>Да. На 1995-й год виртуальная машина (секьюрность, переносимость), сборка мусора, чистая объектная система, рефлексия и динамическая загрузка классов — это фичи, в полной мере отсутствующие в С++. Smalltalk не мог выполнять роль Java из-за динамической типизации.
E>А как же Objective-C и Modula с Oberon-ами? Приверженцы этих языков очень сильно убеждены, что Java -- это вовсе не C++, а сильно испорченные C++ным синтаксисом их творения.
E>>>А.Хэйлсберга, LCR>>Ммм, удовлетворила бы разве что относительно C# >=2.0 — дженерики, лямбды и прочее. Причиной разработки C# называют множество вещей, но кажется главная в том, что Java была разработана не в Microsoft.
E>Ну вот в том-то и дело. Очень яркий пример, когда язык не добавляет ничего нового. Просто является несколько другой реализацией уже известных идей (С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi) + перегрузка операторов (хорошо известная по C++ и куче других языков)). Зато это отличная площадка для дальнейшего развития в свою сторону.
E>Почти то же самое произошло и с C++, и с Python, и c Ruby.
E>Так что на поверхности лежат яркие примеры того, как успешные и восстребованные языки создавались явно не в соответствии с данным опросником.
C++ и Python я бы вычеркнул. Про C++ я сказал выше, а у Питона на момент создания не было альтернатив, он же метил на "language for everyone". Lisp не может претендовать на "language for everyone" из-за свободы, которую он даёт. А свобода — явно не для всех, иначе можно было бы ограничиться просто indentation-фронтендом для всех.
E>Если мне не изменяет склероз, с Haskell-ем сложилась почти аналогичная картина. Когда хотели сделать современный общедоступный функциональный язык, то на роль базиса предлагался Miranda. Но Miranda был коммерческим языком, и его владельцы не сильно горели желанием делиться своими детищем с общественностью. Поэтому-то и было решено создавать новый язык, чтобы затем в нем можно было реализовывать разные новые идеи без оглядки на коммерческие интересы поставщиков средств разработки.
Ну вот и ответ: на пункт 3 ответ был отрицательный, и новые фичи невозможно было добавить в уже существующий язык Miranda, поэтому новый язык и взял старт. И вообще:
1. Haskell решает задачу построения таких абстракций, которые трудны/невозможны в других языках, задачу практического применения чистого функционального программирования и ленивых вычислений.
2.
-- Primes list
primes = nubBy (((==0) .) . (flip mod)) [2..]
-- Fibonacci list
fibonacci = 0 : 1 : zipWith (+) fibs (tail fibs)
-- Fork processes, print their results
main = do
prim <- run primes
fibs <- run fibonacci
mapM_ print $ zip prim fibs
3. Миранда, LazyML и другие клоны ML, Clean, Lisp, Scheme — все они не годились по разным причинам.
...in particular, we sought the freedom for anyone to extend or modify the
language, and to build and distribute an implementation.
— цитата из "History of Haskell"
4. Такой комбинации фич как в Haskell пока нет нигде.
5. Важна именно комбинация чистоты, ленивости и системы типов (не самой примитивной вдобавок ).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Так что, никаких противоречий
Данное утверждение сильно преувеличено. Но, поскольку у нас слишком разные взляды на некоторые вещи, а практической пользы наш спор все равно никому не принесет, то предлагаю его не развивать.
А вот по поводу предложения -- я полностью согласен!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197,
E>Данное утверждение сильно преувеличено. Но, поскольку у нас слишком разные взляды на некоторые вещи, а практической пользы наш спор все равно никому не принесет, то предлагаю его не развивать.
Да, тем более как растёт популярность языков (и не только языков) уже неоднократно обсуждались здесь, так что поддерживаю!
DS>Спасибо за участие, но я читал это сообщение. Я вообще прочитал или просмотрел уже практически все, что есть в англоязычном инете по созданию ЯП и трансляторов.
Ну, ты даёшь.
У меня наоборот — как выйду поискать про ЯП в интернете, так куча новой информации.
DS>Это совсем немного, у меня на компе — около 150 МБ. Почему я в этом так уверен — просто когда я пытаюсь найти что-то новое, не получается.
Видимо, ты не прочитал эти 150МБ. Я уверен, что не прочитал. Это, всё же, порядка семи с половиной тысяч страниц (~20К на страницу).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>(С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi)
В Дельфи нет делегатов. Там обычные указатели на методы.
E> + перегрузка операторов (хорошо известная по C++ и куче других языков)).
+ value типы с автобоксингом + foreach + ref/out параметры + свойства + наверняка еще что то забыл. Каждая фича по отдельности — где нибудь да была, а вот в совокупности ...
... << RSDN@Home 1.2.0 alpha 4 rev. 1212 on Windows Vista 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>+ value типы с автобоксингом + foreach + ref/out параметры + свойства + наверняка еще что то забыл. Каждая фича по отдельности — где нибудь да была, а вот в совокупности ...
Здравствуйте, AndrewVK, Вы писали:
E>>(С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi)
AVK>В Дельфи нет делегатов. Там обычные указатели на методы.
Ну пусть так. Почему-то у меня в памяти осталось впечатление, что Хэйлсберг где-то говорил, что делегаты в C# стали развитием его работы над делегатами Delphi. Видимо, мой склероз мне изменил.
E>> + перегрузка операторов (хорошо известная по C++ и куче других языков)).
AVK>+ value типы с автобоксингом + foreach + ref/out параметры + свойства + наверняка еще что то забыл.
про автобоксинг, имхо, говорили где-то со времен Java 1.1 и Java 1.2.
foreach был в динамических языках чуть ли не с рождения (Smalltalk, Perl, Python, Puby).
ref-параметры были в Turbo Pascal, out-параметры (если не ошибаюсь) в IDL.
свойства Borland добавил еще в C++Builder 1.0.
AVK>Каждая фича по отдельности — где нибудь да была, а вот в совокупности ...
Ну я, вообще-то, стал иронизировать по поводу перечня вопросов потому, что этот перечень сильно напоминает сакральный вопрос "А в чем научная новизна?" в советской (да и постсоветской) науке. На который бесполезно было отвечать в духе "а вот в совокупности". Имхо, успешные практические языки как раз были учень удачной переупаковкой ранее известных идей. И эта тенденция, имхо, наблюдается с 1980-х, если не с конца 1970-х.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Несмотря на такое количество плюсов, все-таки замечу, что вы не правы. Я читаю до 200 страниц в день, а в среднем, наверное, не меньше 50. 50 * 365 * 3 = 54750. Естественно, я читаю не только про языки, но на них приходится значительная доля.
Программировать сложно. Но не программировать еще сложнее.
Здравствуйте, eao197, Вы писали:
E>Ну пусть так. Почему-то у меня в памяти осталось впечатление, что Хэйлсберг где-то говорил, что делегаты в C# стали развитием его работы над делегатами Delphi. Видимо, мой склероз мне изменил.
О как ты ловко. Да, делегаты наверняка развитие указателей на методы, только это не значит, что это одно и то же.
E>про автобоксинг, имхо, говорили где-то со времен Java 1.1 и Java 1.2.
Говорить можно много
E>foreach был в динамических языках чуть ли не с рождения (Smalltalk, Perl, Python, Puby).
Был
E>ref-параметры были в Turbo Pascal, out-параметры (если не ошибаюсь) в IDL.
Были
E>свойства Borland добавил еще в C++Builder 1.0.
Добавил.
Обрати внимание — множества у тебя непересекающиеся, однако.
E>Ну я, вообще-то, стал иронизировать по поводу перечня вопросов потому, что этот перечень сильно напоминает сакральный вопрос "А в чем научная новизна?"
ИМХО этот список прежде всего чтобы заставить задуматься, а не некий формальный критерий годности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1212 on Windows Vista 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
E>>Ну пусть так. Почему-то у меня в памяти осталось впечатление, что Хэйлсберг где-то говорил, что делегаты в C# стали развитием его работы над делегатами Delphi. Видимо, мой склероз мне изменил.
AVK>О как ты ловко. Да, делегаты наверняка развитие указателей на методы, только это не значит, что это одно и то же.
Было сказано: "С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi)". Я не утверждал, что делегаты в Delphi и C# одно и то же. Но уж Хэйлсберг то точно хорошо знал о делегатах из Delphi, об их важности, деталях реализации и ограничениях.
E>>Ну я, вообще-то, стал иронизировать по поводу перечня вопросов потому, что этот перечень сильно напоминает сакральный вопрос "А в чем научная новизна?"
AVK>ИМХО этот список прежде всего чтобы заставить задуматься, а не некий формальный критерий годности.
Ну так мне и интересно, задумались бы озвученные мной товарищи над созданием собственного языка, если бы использовали данный перечень вопросов?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Было сказано: "С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi)". Я не утверждал, что делегаты в Delphi и C# одно и то же.
А как тогда трактовать фразу про то, что делегаты Хейлсбергу известны по Дельфи были, если в Дельфи делегатов нет?
E> Но уж Хэйлсберг то точно хорошо знал о делегатах из Delphi
..., В ДЕЛЬФИ ДЕЛЕГАТОВ НЕ БЫЛО!
... << RSDN@Home 1.2.0 alpha 4 rev. 1212 on Windows Vista 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Было сказано: "С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi)". Я не утверждал, что делегаты в Delphi и C# одно и то же.
AVK>А как тогда трактовать фразу про то, что делегаты Хейлсбергу известны по Дельфи были, если в Дельфи делегатов нет?
E>> Но уж Хэйлсберг то точно хорошо знал о делегатах из Delphi AVK>..., В ДЕЛЬФИ ДЕЛЕГАТОВ НЕ БЫЛО!
.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
