Здравствуйте, dmz, Вы писали:
К>>вот с продакшном в клине как-то, я бы постремался
dmz>Это да. Они даже линк на скачивание прислать не могут, потому что, видимо, я запрос отправил в выходной.
Здравствуйте, dmz, Вы писали:
dmz>>>>Haskell — очень хорошо. Lisp не знаю. dmz>Это да. Они даже линк на скачивание прислать не могут, потому что, видимо, я запрос отправил в выходной.
dmz>По моему, все это говорит о том, что вы не разобрались в предмете.
Есть такое. Чтобы написать язык, нужна семантика. Прежде чем задать семантику, нужно удостовериться, что она логична и удобна. Чтобы в этом удостовериться, нужно написать значительный объем кода с ее использованием. Чтобы написать гарантированно правильный код, не противоречащий семантике, нужна ее реализация. Для реализации нужна спецификация. В общем, замкнутый круг и не понятно, с какого звена начинать. Скорее всего, это порочный подход, но я начинаю с реализации. Для облегчения изменения семантики начали появляться метавозможности и сейчас, например, смена передачи по значению / по ссылке происходит с помощью изменения одного идентификатора в программе.
dmz>Если такая передача параметров (совершенно естественная)
Не согласен, что она естественная, кому как. Удобная — да, но только до определенной сложности решаемой задачи.
dmz>Если нужен частый рефакторинг с изменением типов, то это сразу наводит на мысли, что просто нужен язык с сильной статической типизацией.
Пробовал C++. Замкнутый мирок шаблонов меня никак не устраивал. Конкретные примеры привести не могу, но у меня часто возникала ситуация, когда из ф-и нужно было возвратить результат такого типа, который не устраивал компилятор.
dmz>Например, питоноподобным языком со статическими типами является Boo. Есть языки и более высокого уровня, которые использовать для решения такого рода исследовательских задач было бы резоннее. Почему они не рассматривались?
С опасением отношусь к нераспространенным языкам. В принципе, все что я делаю сейчас, можно написать и на них и, возможно, в пять раз быстрее, но если мой проект выйдет на серьезный уровень, то рано или поздно понадобятся возможности, которых в них нет.
Чувствую, что назревает вопрос: какого черта я тогда говорю о своем языке, который еще вообще нигде не используется. Просто я рассчитывал, что у кого-то будет интерес другого рода, не практический, а исследовательский.
Еще про нестандартные языки: если я реализую проект на Лиспе и решу перенести, скажем, на С, это значит, что мне сначала придется реализовывать на С Лисп, либо полностью переделывать дизайн. Или я что-то упустил?
dmz>А какие языки рассматривались, позвольте спросить?
Дельфи — у меня еще тогда была такая идея: реализовать интерфейс ввода в СУБД, чтобы облегчить/устранить парсинг и "бесплатно" приобрести некоторые другие полезные возможности. Потом я от нее отказался, а недавно нашел в инете сайт, где программист именно так написал язык. От Дельфи отказался из-за ее глюкавости.
C# — факт, что для создания любых данных в программе нужно объявлять класс, сразу заставил меня искать другой язык.
С++ — объединение низкоуровневости с монстрообразностью и постоянными ударами по рукам, когда хочется сделать что-то по-настоящему интересное и мощное. Когда я только начинал на нем писать, была идея создать встроенный язык, для обработки которого использовался бы сам С++. Как я был наивен в этом плане! С++ — последний язык, который подходит для таких целей.
Ассемблер — слишком низкоуровневый (сложно реализовывать нетривиальные алгоритмы), почти ни с чем не совместим, большое количество исключений в дизайне языка и архитектуре процессора, серьезные баги в МАСМе. Несмотря на все это, какое-то время был моим любимым языком и оказал на меня огромное влияние.
Лисп — писал я на нем очень мало, 99% времени потратил на изучение языка и культуры. После прочтения книги "If it works, it's not AI" (или что-то в этом роде) и, в частности, фразы "В своем новом проекте они решили избавиться от "Lisp handcuffs" и использовать С++", я тоже решил на нем не писать, но сомнения терзают до сих пор.
Специализированные языки — SML, Scheme не использовал.
dmz>И с какой стати, в питоне кого-то особенно интересует, где расположены его данные (которые расположены на хипе, кроме примитивных типов — но это совершенно неважно) ?
Я не о куче, а о логической организации данных.
dmz>Делюсь опытом. dmz>1) Не надо что-то делать, если есть возможность этого избежать. Неделание — лучше чем делание.
А как же приобретение опыта? Одними книжками сыт не будешь.
dmz>2) Надо четче ставить цели. Кому и зачем нужен язык. Почему не подходят существующие. То, что озвучено про питон, извините, выглядит смехотворно. Т.е. у питона есть проблемы, конечно — но вот вышеприведенное не проблема совершенно. Если же вы настаиваете, что это проблема — приведите сравнительные кейсы. Т.е. как нечто делается на питоне делается плохо, на вашем языке — хорошо, и почему так.
Надеюсь, в обозримом будущем я смогу аргументированно ответить. А пока еще рано. Сейчас я точно знаю только, чего я не хочу.
Программировать сложно. Но не программировать еще сложнее.
DS>Пробовал C++. Замкнутый мирок шаблонов меня никак не устраивал. Конкретные примеры привести не могу, но у меня часто возникала ситуация, когда из ф-и нужно было возвратить результат такого типа, который не устраивал компилятор.
Haskell, OCaml ?
dmz>>1) Не надо что-то делать, если есть возможность этого избежать. Неделание — лучше чем делание. DS>А как же приобретение опыта? Одними книжками сыт не будешь.
DSblizzard,
DS>Повторю ссылку на всякий случай: DS>http://files.rsdn.ru/48064/Drive%2022.04.09.zip
DS>Серьезно говорить о продвижении того, что я написал, пока рано, я интересовался больше теоретически, на будущее. Большое спасибо всем, кто ответил, напишу несколько более подробно, как и почему я решил создать ЯП.
Разумеется, чем тебе заниматься, решаешь ты и только ты. Я просто бы хотел предостеречь тебя от мартышкиного труда, от которого ни ты, ни окружающие кайфа не словят. Идея создания Ъ-суперъ-пуперъ-языка время от времени посещает всех, кто поработав какое-то время с мейнстримовыми и не-совсем-мейнстримовыми ЯП обнаруживает, что они обладают ненулевой степенью кривизны, и начинает фантазировать на тему улучшений и обобщений. Это хороший знак, это означает, что у человека есть фантазия и исследовательская чёрточка в характере. Только хватать бензопилу и бросаться валить лес очень часто оказывается не самым лучшим вектором приложения сил.
Вот, смотри, что пишет один энтузазист:
Ребята, а давайте залудим ЛЯП!
Поскольку посетители LtU такие продвинутые в языках программирования, почему бы нам не сбацать "Лучший Язык Программирования" (The (Ultimate) programming language), сокращённо — ЛЯП. Давайте запостим все наши предложения сюда чтобы сделать ЯП, одинаково хороший для всех. Это будет эксперимент, сдобренный толстым слоем фана. Я могу сделать компилятор, если мы продвинемся до некоторого "стандарта". Я прошу прощения, если такое уже предлагалось (и очевидно не материализовалось, иначе бы я знал о таком языке).
Мои самые базовые требования — следующие два:
1. Сделать базу компилятора как можно более меньшей. Сделать ЛЯП настолько гибким, чтобы все высокоуровневые концепции могли бы быть легко выражены в базовых терминах.
2. Самый низкий уровень ЛЯП-а должен уметь быть прямо преобразован в железо, то есть это должен быть некоторый вид ассемблера, чтобы позволить желающим совершать Очень Низкоуровневое Программирование. Но ЛЯП вместе с тем должен быть достаточно изменчивым, чтобы обеспечить возможность строить Многослойные Абстракции, так что любой может выбрать подходящий Уровень Абстракции для своей предметной области.
А вот один из лучших ответов, который я имел удовольствие читать (от товарища Frank Atanassow):
Небольшой совет по поводу дизайна языка программирования
Перед тем, как ты погрузишься в изобретение Твоего Языка Программирования (далее ТЯП), задай себе несколько вопросов:
1. Какую задачу новый язык решает? Как сформулировать ответ наиболее точно?
2. Как я могу продемонстрировать красоту решения зтой задачи с помощью нового языка? Как сформулировать ответ наиболее точно?
3. Существуют ли другие решения? Решают ли другие языки эту задачу? Как? Какие преимущества твоего решения? Преимущества их решения? Какие недостатки у твоего решения? Недостатки их решения?
4. Как я могу продемонстрировать, что моё решение не может быть выражено в терминах другого языка? То есть, каково уникальное свойство моего языка, которое отсутствует в других, благодаря чему это решение стало возможным?
5. Какие части моего языка существенны для этого уникального свойства?
Если ты отвечаешь на 1 как "он чище", можешь отваливать. Если отвечаешь "он имеет чрезвычайно маленькое ядро, так что всё на свете можно определить с его помощью", всем на это пофиг. (Ну, на самом деле мне может быть не пофиг, однако ты никогда не убедишь меня заинтересоваться, если не сформулируешь некоторые вещи математически строго. Мы уже знаем про базис из одного единственного комбинатора для нетипизированных вычислений. SKI уже известен несколько десятков лет. Для типизированных языков всё несколько сложнее, но тоже маловероятно, что будет иметь смысл.)
Если ты отвечаешь на 2 как "я буду писать программы на нём после того, как у меня появится прототип", значит ты мало думал, или получение обратной связи для тебя занимает чересчур большой интервал времени. Если в твоём ответе есть хотя бы одно модное слово, ты сам морочишь себе голову.
Если ты отвечаешь на 3 как "я не знаю", значит у тебя маленький кругозор. Всегда существует более одного решения. (Поверь мне; я больше никогда не пишу "the solution to this problem is...", и когда я встречаю это словосочетание и не вижу доказательство единственности, то автор зачастую не знает ещё целую кучу решений.) Если твой ответ включает только языки с какой-либо одной парадигмой, то же самое. Вперёд изучать Scheme, Prolog, ML, Haskell, Charity, Lucid, Synchrone, Obj, Erlang, Smalltalk. Посмотри на Epigram или Coq или HOL или LEGO или Nuprl. Помимо Java, все они существенны и важны. Если ты свободно владеешь всеми этими языками, твоя позиция намного прочнее. Если же ты программировал только на C/C++/Java, Lisp и скриптовых языках, ты всю жизнь смотрел на парад с галёрки. Perl, Python, Ruby, PHP, Tcl и Lisp — это всё один и тот же язык. (Scheme выделяется на их фоне благодаря гигиеническим макросам и продолжениям.)
Если у тебя нет ответа на 4, то твоё решение на самом деле библиотечное, а не языковое. Фактически, люди на LtU — это самые лучшие кадры чтобы спроектировать хорошие библиотеки, и библиотеки в среднем гораздо ценнее, чем собственно языки. Дизайн библиотек также даётся намного легче, и ты не спустишь в трубу дофига своего время на синтаксис. (Да, ты убъёшь много времени лишь на синтаксис. Ты убъёшь почти всё своё время лишь на синтаксис.)
Если ты отвечаешь на 5 как "только это и это", выкуси эти штуки из своего языка и добавь в уже существующий. ("Рефакторь безжалостно".) Если твой ответ "почти всё имеет значение", я могу почти гарантировать, что ты неправ. (Если всё же нет, то ты вероятно учёный/исследователь.)
Причина, по которой большинство новых ЯП вообще не имеют смысла, что люди редко отвечают на эти вопросы честно. То есть, это именно поэтому дизайн нового языка программирования так труден, и поэтому исследователи почти никогда не делают новые языки.
Да, я знаю, что следующие слова будут пропущены мимо ушей, но: не соблазняйтесь изобретением нового синтаксиса. Выберите стиль какого-нибудь другого языка. Java, Lisp, Python, Haskell — не важно. Просто решитесь раз и навсегда и закройте тему. Если вклад вашего языка чисто синтаксический — вам ничто не поможет.
Думайте о фичах языка в терминах асимптотической сложности — не в терминах времени/памяти, а в терминах сложности. (Я бы сказал "семантики", но это уже ругательство.) Изменения в синтаксисе могут снизить сложность лишь в константу раз. Хорошая фича способна изменить сложность в n^2 или в n*log(n) или в n раз. Хорошая фича увеличивает модульность делая локальным то, что раньше было глобальным. Самые лучшие фичи делают это без особых жертв для других фич (например, типобезопасность).
Я бы ещё добавил, что существует гораздо больше возможностей для изобретения новых типизированных языков, чем нетипизированных, также и больше возможностей для параллельных языков, чем для последовательных. (Лично я думаю, из действительно интересного в в нетипизированных последовательных языках остались delimited continuations, narrowing и компиляция.)
И да наступит здесь конец сего Урока...
Между прочим в дискуссии упоминается и твоё улучшение Лиспа: DS>У языка унифицированный префиксный синтаксис:
def( f(X)
ret(X)
)
и ответ, почему получится хуже:
"Я определённо нахожу foo() намного читабельнее, чем (foo)"
Возможно вы просто привыкли к языкам-отпрыскам Алгола?
Это просто соглашение — первый элемент в неквотированном списке _всегда_ имя функции. Вынос его наружу сломает всеобъемлющую концепцию code-is-data-is-code из-за маленьких мелочей, которых просто нет, если вам известно это соглашение.
Это также усложнит парсинг.
Если ты просто не можешь привыкнуть к Лиспу, то может быть сначала узнать о других попытках улучшения синтаксиса Лиспа: Лисп без скобок
Здравствуйте, Lazy Cjow Rhrr, Вы писали: LCR>Если ты просто не можешь привыкнуть к Лиспу, то может быть сначала узнать о других попытках улучшения синтаксиса Лиспа: Лисп без скобок
В добавок к уже сказанному. Думаю, первый вопрос, на который тебе нужно ответить (самому себе) — чем твой язык лучше, чем scheme, common lisp или clojure (с этой троицой очень рекомендую познакомиться, раз уж тебя занесло в унифицированный синтаксис и префиксную нотацию).
Здравствуйте, Mr.Cat, Вы писали:
MC>чем твой язык лучше, чем scheme, common lisp или clojure
Вот это действительно нокаутирующий вопрос. Единственный плюс, который я вижу в своем языке по сравнению с перечисленными — в нем нет макросов. Мощная штука, спору нет, но как можно к ней относиться как к полноценной части языка, когда профи на Лиспе рекомендуют поменьше их использовать?
Программировать сложно. Но не программировать еще сложнее.
Спасибо за участие, но я читал это сообщение. Я вообще прочитал или просмотрел уже практически все, что есть в англоязычном инете по созданию ЯП и трансляторов. Это совсем немного, у меня на компе — около 150 МБ. Почему я в этом так уверен — просто когда я пытаюсь найти что-то новое, не получается.
"Я определённо нахожу foo() намного читабельнее, чем (foo)". И это сообщение я читал. И именно из-за него я решил принять такой синтаксис. Этот программист выражает интересы большинства. Правда, настоящее большинство все равно уже потеряно, потому что +(1 2) гораздо неудобнее, чем 1 + 2. В общем, пришлось пойти на компромисс. Если я решу, что возможности языка важнее, определение ф-и будет выглядеть так:
(def f[X]
(ret X)
)
Программировать сложно. Но не программировать еще сложнее.
Здравствуйте, DSblizzard, Вы писали:
MC>>чем твой язык лучше, чем scheme, common lisp или clojure
DS>Вот это действительно нокаутирующий вопрос. Единственный плюс, который я вижу в своем языке по сравнению с перечисленными — в нем нет макросов. Мощная штука, спору нет, но как можно к ней относиться как к полноценной части языка, когда профи на Лиспе рекомендуют поменьше их использовать?
Профи на Лиспе рекомендуют их использовать ровно там, где надо, где без них уже никак. Макросы, вводят новый уровень абстракции. Без макросов, вышеперечисленные языки теряют всю свою мощь, именно макросы в связке с префиксной нотацией, позволяют легко и изящно оперировать кодом, как данными. Рекомендую ознакомиться с Practical Common Lisp (Peter Seibel) и On Lisp (Paul Graham), вот вторая книга и даст понять, где и когда использовать мощь макросов, а первая книга, это базовый туториал, чтобы понять вторую книгу
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, DSblizzard, Вы писали: DS>Единственный плюс, который я вижу в своем языке по сравнению с перечисленными — в нем нет макросов.
Многие сочли бы это минусом. Кто-то — исключительно с точки зрения "наличие лучше, чем отсутствие", кто-то просто привык к макросам и с подозрением относится к языкам без оных.
Не знаю, правильно ли я делаю, чтопытаюсь увести разговор в сторону лиспов. Просто когда я увидел пример кода, первая мысль была — "да это же лисп". Поэтому сравнение с лиспами напрашивается у меня (возможно, не только у меня) само собой. Т.е. например:
— Scheme — это минималистичное ядро языка, плюс гигиенические макросы и континуации.
— Clojure — это (насколько я понял) многопоточность, stm, тесная интеграция с java (т.е. упор не на дизайн языка, а на качество реализации).
— Твой язык — это ...
Повторюсь, возможно, твой язык не является очередным лиспом, но просто уж очень похож (и информации ты пока совсем немного дал).
DS>Мощная штука, спору нет, но как можно к ней относиться как к полноценной части языка, когда профи на Лиспе рекомендуют поменьше их использовать?
Ну смотря в каком контексте даются такие рекомендации, применительно к решению каких задач. Например, если хочется построить DSL поверх лиспа — лучше от макросов не отказываться.
Небольшой совет по поводу дизайна языка программирования
LCR>Перед тем, как ты погрузишься в изобретение Твоего Языка Программирования (далее ТЯП), задай себе несколько вопросов:
LCR>1. Какую задачу новый язык решает? Как сформулировать ответ наиболее точно?
LCR>2. Как я могу продемонстрировать красоту решения зтой задачи с помощью нового языка? Как сформулировать ответ наиболее точно?
LCR>3. Существуют ли другие решения? Решают ли другие языки эту задачу? Как? Какие преимущества твоего решения? Преимущества их решения? Какие недостатки у твоего решения? Недостатки их решения?
LCR>4. Как я могу продемонстрировать, что моё решение не может быть выражено в терминах другого языка? То есть, каково уникальное свойство моего языка, которое отсутствует в других, благодаря чему это решение стало возможным?
LCR>5. Какие части моего языка существенны для этого уникального свойства?
Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от Б.Страуструпа, Дж.Госслинга, А.Хэйлсберга, Г.в.Россума, Я.Матцумото...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
К сожалению, функциональное программирование и ООП мне не слишком нравятся. Возможно, потому, что я их изучал не по Хаскелю и Смоллтоку. К тому же уже некогда точить пилу, пора пилить
Программировать сложно. Но не программировать еще сложнее.
Здравствуйте, DSblizzard, Вы писали:
DS>Прочел обе и еще пару. Хотелось бы прочитать еще Anatomy of Lisp, но нигде не могу найти.
У нее есть современный аналог: Lisp in Small Pieces — и ее можно найти
5/5
The best book available on Lisp implementation, December 22, 1999 By Peter Norvig (Palo Alto, CA USA)
(REAL NAME)
This is an excellent book on Lisp implementation. You'll get a lot out of it, whether you are interested in writing compilers and interpreters (for Lisp or any language) or whether you just want to see how Lisp works. It is the modern day successor to Allen's "Anatomy of Lisp".
Здравствуйте, eao197, Вы писали:
E>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от Б.Страуструпа, Дж.Госслинга, А.Хэйлсберга, Г.в.Россума, Я.Матцумото...
Конечно, особенно, если еще и учитывать хронологию появления языков в масштабе времени.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
E>>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от Б.Страуструпа, Дж.Госслинга, А.Хэйлсберга, Г.в.Россума, Я.Матцумото...
Y>Конечно, особенно, если еще и учитывать хронологию появления языков в масштабе времени.
Хронология здесь не причем. Особенно это касается первых версий Java и C# -- на тот момент они вообще не предлагали ничего нового (оберонщики и приверженцы ObjectiveC до сих пор считают, что Java была испорченной версией их языков и даже использовала их технологии у себя внутри). Так что такие успешные мейнстримовые языки, как C++, Java, C#, Python и Ruby всего лишь являются очень понравившейся многим упаковкой для чужих идей. И я не вижу, почему такая же ситуация не может произойти с новыми языками в будущем. Взять, к примеру, Scala.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>DSblizzard,
Насоящий ЛЯП давно придуман и сделан. Компилятор такой, что меньше не бывает. Интерпретатор тоже. Позволяет выражать не только абстракции, но и категории самого себя. Имеет некоторый вид ассемблера, на ассемблер непохожий, что адептам особенно приятно. Реализуется в железе так, что железо только трещит. Умолчу про Многослойные Абстракции.
Мы же с вами про Forth?
LCR>1.
Сделать базу компилятора как можно более меньшей. Сделать ЛЯП настолько гибким, чтобы все высокоуровневые концепции могли бы быть легко выражены в базовых терминах.
LCR>2.
Самый низкий уровень ЛЯП-а должен уметь быть прямо преобразован в железо, то есть это должен быть некоторый вид ассемблера, чтобы позволить желающим совершать Очень Низкоуровневое Программирование. Но ЛЯП вместе с тем должен быть достаточно изменчивым, чтобы обеспечить возможность строить Многослойные Абстракции, так что любой может выбрать подходящий Уровень Абстракции для своей предметной области.
Здравствуйте, yumi, Вы писали:
E>>Хронология здесь не причем. Y>Спасибо, после выделенного с Вами дальше можно не продолжать беседу.
А со мной будешь? Моя русский каросый!
Возьми один из следующих языков: C#, Nemerle, Scala, Ruby, Python, и попробуй дать вразумительные ответы на эти вопросы, которыми их авторам якобы следовало задаться перед созданием.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
