Здравствуйте, C.A.B, Вы писали:
CAB>В Python'е нет ни каких "dynamic" и есть д.типизация, т.е. "dynamic" не нужен для неё, т.е. это таки костыль. Исходя из принципа "фичи не должны быть изолированы от других
", с чем ещё можно связать "dynamic"?
dynamic — это просто тип. Скриптовый подход к использованию переменных вообще без объявления меня не интересует. Но зато есть Go и оператор := с помошью которого можно минимальным количеством символов объявлять переменные с выводом типов.
CAB>Имутабельность это фича функциональных языков, суть её в том что нет изменяемых переменных.
И если вдруг позарез понадобилась изменяемая, то нужно писать костыли для ее имитации.
NC>>В С++ давно уже можно передавать и так, и так. CAB>Я не говорю что нельзя, я спрашиваю как это сделать "простыми, естественными и открытыми".
Способ более чем простой — амперсанд перед именем аргумента. Один символ. Для симмметрии можно добавить какой-нибудь другой символ для явной передачи по значению, но вряд ли это оправдано.
CAB>И вот у нас ещё три новых костыля, и сложность продолжает расти а надёжность падать
Пишите на Бейсике Но закрывать от программиста возможность создания объекта в неуправляемой памяти для системного языка — глупо.
CAB>>>примитивные типы и классы NC>>Чем они несовместимы? В чем например проблема реализовать наследование от примитивных типов? CAB>Наследование это только одна проблем. Если у нас есть две разновидности типов, значит нам нужно как-то их различать, нужно два набора средств для работы с ними и/или нужны специальные правила(ограничения) для них(например в Java есть правило "объекты всегда посылке, примитивные всегда по значению", а в С++(а может и не в нём, не помню) есть специальный синтаксис позволяющий передавать или по ссылке или по значению). Всё это так-же увеличивает сложность.
Они не "две разновидности типов". Все типы равноправны. И объекты классов, и объекты "примитивных типов" должны иметь право создаваться в стеке, глобально, в управляемой куче и в неуправляемой куче. По поводу правил передачи — я еще не решил, вопрос очень тонкий. Очевидно, что передачу по ссылке можно сделать свойством типа (и тогда точно потребуется явный оператор передачи по значению), а можно сделать свойством аргумента.
CAB>>>множественное наследование и отсутствие "ромбовидной проблемы", NC>>С наследованием многие проблемы решаются путем объединения концпеций "наследования" и "агрегации". Кое-что реализовано в языке Go, кое-что решается введением имен (псевдопеременных) для предков при наследовании. CAB>Это определённо сложней чем просто запретить м. наследование, как Java.
CAB>>>безопасность и быстродействие, NC>>Быстродействие на первом месте. Где нужна безопасность — используются безопасные подмножества, специальные атрибуты для функций, классов и модулей, которые запрещают некоторые вещи внутри (например указатели), добавляют дополнительные проверки и т.д. Нечто подобное сделано в D. CAB>Ещё +100500 сложности.
Еще раз, пишите на Бейсике! "Простых" языков создано уже немеряно, я не вижу смысла порождать еще один. А Хакерских — по пальцам пересчитать: древний Си, который не поддерживает ничего кроме императивного программирования; сложный, но непродуманный С++ с огромным хвостом legacy; и частично Objective C, Go и D.
CAB>А я(и наверняка все Питонщики, Рубисты, Перлист,...) считаю что динамическая более естественна и удобна, а статическая лиш полезна (это к тому что далеко не все разделяют ваши вкусы).
Динамическая типизация полностью включается в статическую. Вы можете использовать ТОЛЬКО тип dynamic и никакие другие.
Здравствуйте, NeoCode, Вы писали:
ARK>>А можно будет параметризовать модулями или неймспейсами? NC>Да, любыми фрагментами кода, которые можно представить в виде ноды AST. Какая разница что это? NC>Модули и неймспейсы кстати логично объединить в одно понятие (module) и разрешить создавать модули в том числе и внутри классов и функций.
Понятно. Хотелось бы посмотреть на наикрасивейшую реализацию этой идеи.
ARK>>Будет ли наследование функций? ARK>>И, кстати, будет ли множественное наследование (классов)? NC>Сначала нужно довести до идеального состояния обычное наследование, а потом думать над "наследованием функций".
А вдруг потом выяснится, что в ваше идеальное состояние новые фичи не вписываются?
Кстати, а не поделитесь мыслями об идеальном наследовании? А то вдруг оно не совсем и идеальное.
NC>Мне не очень понятно что это вообще такое.
Мне тоже. Но у вас же "всё есть всё". Кстати, не забудьте про наследование модулей.
NC>dynamic — это просто тип. Скриптовый подход к использованию переменных вообще без объявления меня не интересует.
Почему? Это классная фича. Экономит ресурс клавиатуры. NC>Но зато есть Go и оператор := с помошью которого можно минимальным количеством символов объявлять переменные с выводом типов.
Вывод типов это совсем не тоже самое. CAB>>Имутабельность это фича функциональных языков, суть её в том что нет изменяемых переменных. NC>И если вдруг позарез понадобилась изменяемая, то нужно писать костыли для ее имитации.
Ну или использовать готовые. Но при этом теряются такая фича ФП "устойчивость к случайному изменению значения переменной", а если есть фича "переменные доступны внутри других функций на чтение" то теряется фича "детерминированность функций", ни и если есть фича "переменные доступны внутри других функций на чтение и на запись", то теряется ещё и фича "отсутствие сайдэффектов". NC>Пишите на Бейсике Но закрывать от программиста возможность создания объекта в неуправляемой памяти для системного языка — глупо.
Думаю тем кто пишет на Бейсике не нужна возможность управления памятью, а тем кто пишет системные вещи на С, не нужны встроенные в язык операторы доступа к файлам. Зачем всё это в одном ЯП? NC>Еще раз, пишите на Бейсике! "Простых" языков создано уже немеряно, я не вижу смысла порождать еще один. А Хакерских — по пальцам пересчитать: древний Си, который не поддерживает ничего кроме императивного программирования; сложный, но непродуманный С++ с огромным хвостом legacy; и частично Objective C, Go и D.
Ассемблер наше увсё! (с)clerk
Это замечательно что вы делаете свой ЯП, но спорить дальше нет желтения. Надеюсь вы нам покажете что нибудь интересненькое
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
CAB>>"Переменных в Haskell просто нет" от сюда. I>
>> v <- newIORef 0
Ok, кроме тех что живут в монадах.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>>>"Переменных в Haskell просто нет" от сюда. I>>
>>> v <- newIORef 0
CAB>
CAB>Ok, кроме тех что живут в монадах.
В haskell действительно есть переменные, но под этим словом подразумевается нечто отличное от значения в императивном мире. http://www.haskell.org/haskellwiki/Variable
а по поводу IORef — лучше о нем думать как о типизированном файле или таблице в памяти, имеющим(ей) одну позицию для записи. Все взаимодействие хаскеля с IORef осуществляется через IO, то есть фактически это внешний, изменяемый мир.
Здравствуйте, C.A.B, Вы писали:
CAB>Cool Я как раз проектирую такой компилятор. Идея такова: компилятор фактически представляет из себя пакет компонентов, в который входят разные служебный компоненты(типа логера, лодеров и т.п.) и компоненты реализующие трансляцию разных фич и сахара в IL. В начале каждого файла исходного текста можно будет на специальном DSL подключать/отключать фичи языка. При компиляции этот DSL будет интерпретироваться спец. компонентом, который выстроит цепочку из компонентов-трансляторов, через которую пройдёт исходный текст.
Здравствуйте, Ziaw, Вы писали: CAB>>Cool Я как раз проектирую такой компилятор. Идея такова: компилятор фактически представляет из себя пакет компонентов, ... Z>Не-не-не! Девид Блейн, ты изобрел Nemerle?
Без ГМО МП
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>>>Cool Я как раз проектирую такой компилятор. Идея такова: компилятор фактически представляет из себя пакет компонентов, ... Z>>Не-не-не! Девид Блейн, ты изобрел Nemerle? CAB>Без ГМО МП
Я тебя сейчас немного расстрою. Компоненты, про которые ты пишешь, это код который создает код, то есть МП.
Здравствуйте, C.A.B, Вы писали:
Z>>Не-не-не! Девид Блейн, ты изобрел Nemerle? CAB>Без ГМО МП
Нет, правда, не могу понять, почему все авторы языков упорно ставят в преимущества всякие "без": "без МП", "без ООП", "без указателей", "без ручного управления памятью" или "без сборки мусора", "без goto", "без изменяемых переменных" и т.д.???
Неужели вы хотите из Хакеров, из Мастеров Кода, из Гениев Программирования превратиться в тупых конвейерных рабочих? Хотите, чтобы, для того чтобы стать Профессиональным Программистом, достаточно было закончить двухнедельные курсы в каком-нибудь подвальчике?
Программирование должно быть простым и приятным... для Профессионалов. Профессионал должен наслаждаться красттой и гармонией кода, в том числе красотой и гармонией инструментов, которыми он пользуется. И МП, и ФП, и ООП, и низкоуровневые приемы программирования прекрасны. И видеть язык, в котором чего-то нет, весьма печально — такой язык воспринимается как калека.
А новички... те, кому программирование действительно интересно — почувствуют эту красоту и гармонию и придут к совершенству. А те, кому все равно что делать, лишь бы деньги платили — пускай идут к станку, сейчас в стране рабочих нехватает.
ЗZ>>>Не-не-не! Девид Блейн, ты изобрел Nemerle? CAB>>Без ГМО МП Z>Я тебя сейчас немного расстрою. Компоненты, про которые ты пишешь, это код который создает код, то есть МП.
Ну если считать например scalaс плагины МП, то тогда конечно да.
PS: Я делаю особую, компонентную магию
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
NC>Нет, правда, не могу понять, почему все авторы языков упорно ставят в преимущества всякие "без": "без МП", "без ООП", "без указателей", "без ручного управления памятью" или "без сборки мусора", "без goto", "без изменяемых переменных" и т.д.???
Следует читать это как: "без МП и проблем к которым оно приводит", "без ООП и сложности которую оно привносит", etc. NC>Неужели вы хотите из Хакеров, из Мастеров Кода, из Гениев Программирования превратиться в тупых конвейерных рабочих? Хотите, чтобы, для того чтобы стать Профессиональным Программистом, достаточно было закончить двухнедельные курсы в каком-нибудь подвальчике?
Да, я чертовски этого хочу! Почему? Всё просто: я не хочу быть профессиональным(т.е. тратить много время на изучение этого) электронщиком чтобы собрать себе домашний кинотеатр, я не хочу быть профессиональным экономистом чтобы посчитать домашний бюджет. И я думаю профессиональный экономист и электронщик не хотят быть профессиональными программистами чтобы написать скрипт автоматизации или простенькое приложение. NC>А те, кому все равно что делать, лишь бы деньги платили — пускай идут к станку, сейчас в стране рабочих нехватает.
Меня, как профессионального слесаря, волнует вопрос: почему вы внезапно решили что, программирование существенно отличается от стояния за станком?
PS: Я совсем не против МП, в умеренных количествах.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
Z>>Я тебя сейчас немного расстрою. Компоненты, про которые ты пишешь, это код который создает код, то есть МП. CAB>Ну если считать например scalaс плагины МП, то тогда конечно да.
Ну конечно МП. Мне кажется у тебя некая МП-фобия. МП это не некромантия, это когда пишется код, цель которого генерировать другой код.
CAB>PS: Я делаю особую, компонентную магию
Здравствуйте, C.A.B, Вы писали:
CAB>Я как раз проектирую такой компилятор.
Только это не такой. Вы пишите компилятор, пусть и настраиваемый. И именно "компилятор" у вас производит результат. Я предлагал отказаться от этого. Вот у меня сейчас примерно так библиотека собирается:
1. Запускаем scala compiler и компилируем небольшой код (с использованием библиотек)
2. Запускаем скомпилированный продукт. На вход он вообще ничего не требует. На выходе получаем 90% библиотеки, сразу в нужном формате (*.jar). Все, что строится по упрощенным моделям и не требует специальной обработки.
3. Еще раз запускаем scala compiler (линкуется с библиотекой из п. 2) и докомпилируем оставшиеся 10%, которые по упрощенной модели не строятся.
Итого. 90% библиотеки произведено "чем-то" непонятного статуса. Ясно только, что это не компилятор (у него входных данных нет). И "компилятор" он не использует (используется только низкоуровневая модель целевого кода, даже без оптимизаторов и прочего, ибо не нужно). Потом при генерации будет использоваться уровень чуть повыше (ассемблер под JVM с выводом типов). Делать из программы "компилятор" лень — нужно будет парсер писать, ошибки обрабатывать и т.п. А необходимую модель я и в коде построю (с использованием helper methods для некоторых повторяющихся вещей).
M>Итого. 90% библиотеки произведено "чем-то" непонятного статуса. Ясно только, что это не компилятор (у него входных данных нет). И "компилятор" он не использует (используется только низкоуровневая модель целевого кода, даже без оптимизаторов и прочего, ибо не нужно). Потом при генерации будет использоваться уровень чуть повыше (ассемблер под JVM с выводом типов). Делать из программы "компилятор" лень — нужно будет парсер писать, ошибки обрабатывать и т.п. А необходимую модель я и в коде построю (с использованием helper methods для некоторых повторяющихся вещей).
Это(на сколько я понял) у вас кодогенератор. В целом ваш подход (наверно) похож на тот что используется в Nemerle, только у вас код генерируется функциями из библиотек (из п.1), вместо макросов.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Z>МП это не некромантия, это когда пишется код, цель которого генерировать другой код.
Да, я знаю, но считаю что при прочих равных, проще, лучше, быстрей и надёжней писать код который будет непосредственно решать задачу, чем код который будет генерировать код, который будет решать задачу.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, NeoCode, Вы писали:
NC>Нет, правда, не могу понять, почему все авторы языков упорно ставят в преимущества всякие "без": "без МП", "без ООП", "без указателей", "без ручного управления памятью" или "без сборки мусора", "без goto", "без изменяемых переменных" и т.д.???
Потому что авторы языков разбираются в программировании.
NC>Программирование должно быть простым и приятным... для Профессионалов.
Программирование должно быть предсказуемым и простым для среднестатистического программиста.
NC>Профессионал должен наслаждаться красттой и гармонией кода, в том числе красотой и гармонией инструментов, которыми он пользуется.
Профессионал должен делать свою работу, за которую ему платят.
NC>И МП, и ФП, и ООП, и низкоуровневые приемы программирования прекрасны. И видеть язык, в котором чего-то нет, весьма печально — такой язык воспринимается как калека.
Язык должен позволять наилучшим образом решать задачи того типа, для которых он предназначен. А не быть свалкой мусора из всего на свете.
NC>А новички... те, кому программирование действительно интересно — почувствуют эту красоту и гармонию и придут к совершенству. А те, кому все равно что делать, лишь бы деньги платили — пускай идут к станку, сейчас в стране рабочих нехватает.
Просто ради любопытства — не скажете, вам сколько лет?
Здравствуйте, C.A.B, Вы писали:
CAB>Да, я знаю, но считаю что при прочих равных, проще, лучше, быстрей и надёжней писать код который будет непосредственно решать задачу, чем код который будет генерировать код, который будет решать задачу.
Естественно. При прочих равных применять МП глупо. МП оправдано в тех случаях, когда оно сокращает размер или "макаронность" кода на один-два порядка. И в отличии от взаимозаменяемых ФП/ООП, МП в этих случаях заменить совершенно нечем.
Здравствуйте, C.A.B, Вы писали:
CAB>Это(на сколько я понял) у вас кодогенератор.
Скорее, генератор бинарников. Все-таки под кодогенератором понимается штука, которая на выходе дает код и тот код потом еще компилируется. А у меня дополнительной компиляции выходу программы не требуется.
CAB>В целом ваш подход (наверно) похож на тот что используется в Nemerle, только у вас код генерируется функциями из библиотек (из п.1), вместо макросов.
Не . Если я правильно понимаю, в немерле генерируется далеко не тот код, который у меня. В немерле генерируется некое промежуточное дерево (граф) с полноценными выражениями, statements, declarations, etc.... Эатем это дерево дается на вход компилятору, который его преобразует и генерирует целевой код. У меня уровень ниже (фактически, я уже произвожу ассемблер и использую только его сериализатор). Соответственно, и проблемы у компонентов другие (нужно имена сразу бинарные давать, т.е. сервисы вроде import не доступны, а чтобы сделать их доступными, нужно будет участвовать в 3-4 фазном процессе). Вот если бы макросы участвовали в многофазном разрешении имен (определения типов, определения методов, генерации кода) и банальные операторы были бы тоже макросами (а чего, у меня стековый калькулятор на выходе, так что никаких expressions, а линейная последовательность команд), тогда мы с Nemerle бы были ближе друг к другу.
Здравствуйте, maxkar, Вы писали:
M>Итого. 90% библиотеки произведено "чем-то" непонятного статуса. Ясно только, что это не компилятор (у него входных данных нет). И "компилятор" он не использует (используется только низкоуровневая модель целевого кода, даже без оптимизаторов и прочего, ибо не нужно). Потом при генерации будет использоваться уровень чуть повыше (ассемблер под JVM с выводом типов). Делать из программы "компилятор" лень — нужно будет парсер писать, ошибки обрабатывать и т.п. А необходимую модель я и в коде построю (с использованием helper methods для некоторых повторяющихся вещей).
Очень похоже на форт-систему...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
