Кажется, сегодня я понял почему ФП это ООП для бедных, и наоборот Но трейд не совсем об этом.
В ООП все методы распределены по объектам, там-же находятся и данные. В ФП функции(а так-же процедуры в ПП) и данные существуют отдельно, к тому-же функции могут быть разбросаны по программе как угодно(не считая ограничений вносимых областями видимости имён).
Пример на Scala(с ошибками и который можно переписать проще):
class T(t:Int) extends Int{
val v = if(t > 100) 100 else t
def size():Int = 100
def add(a:T):T = {val s = a + v; (if(s > 100) 100 else s).asInstanceOf[T]}
overrid def toString():String = v + "%"
}
class Main{
def main(){
val t = new T(1)
val sz = t.size
val sm = t add new T(2)
println( sz + "," + sm )
}
}
Пример на функционально-императивный ЯП, который я сейчас пилю:
T DATA 0..100 //Примитивный(как например int,boolean в Java) тип данных, заданный в виде диапазона.
//
T>Int = {t) t #> Int (}:Typecast //Несколько тайпкастов для типа "T", чтоб не захламлять код явными приведениями.
Int>T = {i) (if i > 100 => 100 else => i) #> T (}:Typecast //"#>" - оператор преобразования типов, как в Паскале.
T>Str = {t) t:Int:Str + "%" (}:Typecast
//
size = {T) 100 (Int} //Функция "size"
+ = {a:T,b:T) a:Int + b:Int (T} //Функция "+"
//
t = 1:T //Определение значения типа T.
sz = t.size() //Сахар для: sz = size(t)
sm = t + 2:T //Сахар для: sm = +(t,2:T)
print( sz + "," + sm )
Сей ЯП ориентирован на быстрое написание несложных, небольших программ (как Python). В данном контексте, думаю такой, гибридный ЯП будет лучшим выбором чем ООЯП, так как он несколько проще и гибче. Во первых — здесь данные и функции разделены, что будет проще для понимания людьми не знакомыми с ОО парадигмой (типа "вот у нас циферки и буковки, а вот у нас команды которые чего-то с ними делают"). Во вторых — не нужно особо структурировать программу, т.е. распределять функции и данные по классам, "пишем где удобно". Ну и в третьих — чтобы добавить какие-то новые методы для работы некоторым типом не нужно расширять класс, можно просто определить эти методы там где они нужны.
Собственно вопрос: Как вы считаете, верен ли мой выбор? Почему?
Спасибо.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB> Собственно вопрос: Как вы считаете, верен ли мой выбор? Почему?
Без понимания, кто, как и с какой целью будет применять твой ЯП, дать ответ на этот вопрос не представляется возможным.
Здравствуйте, C.A.B, Вы писали:
CAB> В ООП все методы распределены по объектам, там-же находятся и данные.
В мейнстриме все сложнее. Данные и методы распределены по объектам и по типам (sic!)
CAB> В ФП функции(а так-же процедуры в ПП) и данные существуют отдельно, к тому-же функции могут быть разбросаны по программе как угодно
В ФП всю картину портит возможность трактовать функции как данные. Можно ведь положить функции в record и эмулировать потом все OOP. Передавать ли всем функциям сам объект или оставить его в замыкании в месте определения функций — отдельный вопрос.
CAB> Во первых — здесь данные и функции разделены, что будет проще для понимания людьми не знакомыми с ОО парадигмой (типа "вот у нас циферки и буковки, а вот у нас команды которые чего-то с ними делают").
Это ровно до тех пор, пока не нужно делать полиморфное поведение в рантайме. Оно же — связывание имени процедуры вместе с кодом процедуры. Явная передача функций (и вообще трактовка их как значений) может снести крышу этим вашим "циферки и буковки". Явное создание замыканий или интерфейсов будет похоже на OOP.
CAB> Во вторых — не нужно особо структурировать программу, т.е. распределять функции и данные по классам, "пишем где удобно".
Вы не правы. Точно так же в ООП можно писать функции в "любых" объектах. Создаем объект "compilation unit N123" и пишем в этом объекте код. Это будет примерно то же, что и модуль в ocaml. Так что о правильном структурировании думать придется. И о правильном подключении нужных модулей тоже. Или вы все хотите в одно глобальное пространство загнать? Тогда вопрос не имеет никакого отношения ни к ООП, ни к ФП.
CAB> Ну и в третьих — чтобы добавить какие-то новые методы для работы некоторым типом не нужно расширять класс, можно просто определить эти методы там где они нужны.
И здесь вы ошибаетесь. Вы ведь не добавить методы хотите. Можно ведь добавить метод, работающий с объектом, и не расширяя сам оъект (класс). Можно определить метод в другом объекте. На самом деле вы хотите вызова c.a(<args>) вместо otherObject.a(c, <args>). Это можно делать на уровне синтаксического сахара. Да, с объектами scoping и выбор метода будет сложнее, но сахар реализуем. Причем для ФП хочется обратного сахара: a(c, <args>) = c.a(<args>). Да и в ООП можно все загнать в синтаксис "без точки". Отличительной чертой является не это. Отличие будет в "позднем связывании" функции с ее реализацией (во время исполнения, на основе типа первого аргумента).
CAB> Собственно вопрос: Как вы считаете, верен ли мой выбор? Почему?
Для начала можно честно реализовать модули и абстрактные типы данных (когда клиенту не доступна реализация). Если вам повезло, и утилиты действительно простые, этим и ограничится. Если нет, стоит и "объекты" в классическом понимании добавить. Например, ручное размеченное замыкание. Все таки явные "методы привязанные к состоянию" могут быть читаемее там, где мы этими методами реализуем интерфейс (по сравнению с замыканиями на аргументы функции).
В общем, для простого языка тащить ООП в качестве базы не стоит. И для сложного в mainstream виде — тоже. Стоит его облагородить модульностью (отвязанной от классов) и свободно стоящими функциями (привязанными к модулю), большим количеством метатипов (records, discriminated unions, functional types). Т.е. использовать различные механизмы для различных задач, а не пытаться впихнуть все в одну парадигму.
Здравствуйте, C.A.B, Вы писали:
CAB> Кажется, сегодня я понял почему ФП это ООП для бедных, и наоборот Но трейд не совсем об этом. CAB> В ООП все методы распределены по объектам, там-же находятся и данные. В ФП функции(а так-же процедуры в ПП) и данные существуют отдельно, к тому-же функции могут быть разбросаны по программе как угодно(не считая ограничений вносимых областями видимости имён).
Зачем противопоставлять то, что можно и нужно объединять? Обычные функции — это объекты, функциональные объекты ("делегаты") — тоже объекты, методы — это функции с дополнительным аргументом, отвязку от классов сделать элементарно (простейшая фича, обратная методам-расширениям — для любого объекта obj класса MyClass вызов obj.Method() можно заменить на MyClass.Method(&obj); и почему ее в С++ не сделали?). Любой метод объекта — это и объект, и функция. А уж если класс поддерживает operator(), то объект этого класса — тоже функция. Получаем, что все есть все.
Пространства имен должны иметь право быть везде, в том числе внутри классов и функций (тоже элементарно делается).
Народ же или закицливается на супер-строгом ООП, или погружается в математизированные дебри ФП. Не по-хакерски все это, не по-хакерски.
Здравствуйте, 0x7be, Вы писали: 0>Без понимания, кто, как и с какой целью будет применять твой ЯП, дать ответ на этот вопрос не представляется возможным.
Будет использоваться для написания компонентов
StringFilter PROTO{ //Внутри этих скобок отдельное пространство имён(не доступное из вне), в котором можно размещать функции, переменные и т.п.
//Код инициализации, создаёт и связывает пару дополнительных компонентов(может размещается в другом месте).
constructor = {)
connect text to new io/TextBuffer
connect console to new system/Console
(}
//Как бы АПИ(на подобии импорта в Python).
jack text:Text
jack console:Out
//Главная функция(как main в Си).
doer = {)
text.fromFile("D:\\t.txt")
while text.hasNext do
s = text.next
if(! comp(s,"hide string")) => console.println(s)
end
(}
//Функция для сравнения строк
def comp = {a:Str, b:Str)
a == b
(Bool}
}
Не точный аналог на скале на Scala:
class StringFilter {
val text = scala.io.Source.fromFile("D:\\t.txt")
val console = System.out
def main(args: Array[String]): Unit = {
while(text.hasNext){
val c = text.next()
if(! comp(c,'h')) console.println(c)}
}
def comp(a:Char,b:Char):Boolean = {
a == b
}
}
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, maxkar, Вы писали: M>Это ровно до тех пор, пока не нужно делать полиморфное поведение в рантайме. Оно же — связывание имени процедуры вместе с кодом процедуры. Явная передача функций (и вообще трактовка их как значений) может снести крышу этим вашим "циферки и буковки". Явное создание замыканий или интерфейсов будет похоже на OOP.
Связывание в рантайме это другой вопрос
. Допустим у нас уже всё связано, уже есть некоторый API и нам нужно только реализовать какое-то внутреннее поведение, т.е. какой-то код, чего-то делающий с этим API.
M>Вы не правы. Точно так же в ООП можно писать функции в "любых" объектах. Создаем объект "compilation unit N123" и пишем в этом объекте код. Это будет примерно то же, что и модуль в ocaml. Так что о правильном структурировании думать придется. И о правильном подключении нужных модулей тоже. Или вы все хотите в одно глобальное пространство загнать? Тогда вопрос не имеет никакого отношения ни к ООП, ни к ФП.
Скажем так, функции будут находится в некотором "пространстве", это изолированное и достаточно большое пространство(больше чем класс). В прицепе, в этом пространстве можно разрешить размещать и класса, но я думаю это будет overkill.
CAB>> Ну и в третьих — чтобы добавить какие-то новые методы для работы некоторым типом не нужно расширять класс, можно просто определить эти методы там где они нужны. M>И здесь вы ошибаетесь. Вы ведь не добавить методы хотите. Можно ведь добавить метод, работающий с объектом, и не расширяя сам оъект (класс). Можно определить метод в другом объекте.
ИМХО, это нарушение принципов ООП(когда дугой объект чего-то делает с данными, которые инкапсулирует первым).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, NeoCode, Вы писали: NC>Зачем противопоставлять то, что можно и нужно объединять?
Борьба бобра с со сложностью И ООП это огромный "кусок" сложности, который я бы хотел выкинуть. NC>Обычные функции — это объекты, функциональные объекты ("делегаты") — тоже объекты, методы — это функции с дополнительным аргументом, отвязку от классов сделать элементарно (простейшая фича, обратная методам-расширениям — для любого объекта obj класса MyClass вызов obj.Method() можно заменить на MyClass.Method(&obj); и почему ее в С++ не сделали?). Любой метод объекта — это и объект, и функция. А уж если класс поддерживает operator(), то объект этого класса — тоже функция. Получаем, что все есть все.
Идея "всё объекты" красива столько в теории. На практике она превращается в леса мигрирующих рантайм зависимостей.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
NC>>Зачем противопоставлять то, что можно и нужно объединять? CAB>Борьба бобра с со сложностью И ООП это огромный "кусок" сложности, который я бы хотел выкинуть.
В реальном кодигне сложность в том, что вот надо бы воспользоваться какой-то возможностью, а ее нет. И появляются монстры типа Boost, метапрограммирования на шаблонах, куча классов там где достаточно обойтись одной строчкой кода и т.п. Потому что в любом языке чего-то, да нет: функционального программирования, рефлексии, структурной типизации, динамического связывания, отправки сообщений, нормального метапрограммирования на макросах, низкоуровневых возможностей... И программисты городят безумные огороды, пытаясь с помощью существующих скудных средств имитировать те фичи, которых в языке недостает.
Я например уже давно занимаюсь разработкой собственного хакерского языка программирования, который бы, сохраняя старый добрый си-подобный синтаксис и сишную идеологию, объединял бы максимум фич большинства языков программирования, таких как C, C++, С++/Qt, Objective C, Delphi, D, C#, Java, Scala, Nemerle, Go, Rust, JavaScript, Python, Ruby, Comega и некоторых других.
CAB>Идея "всё объекты" красива столько в теории. На практике она превращается в леса мигрирующих рантайм зависимостей.
Ничего подобного, идея столь же проста и низкоуровнева, как пересылка двух байт по сети. Главное — не превращать ее в ограничение "все объекты и только объекты". Потому что любая фича — добро, а любое ограничение — зло.
Здравствуйте, C.A.B, Вы писали:
CAB>Что-вpоде такого: CAB>
CAB> StringFilter PROTO{ //Внутри этих скобок отдельное пространство имён(не доступное из вне), в котором можно размещать функции, переменные и т.п.
CAB> //Код инициализации, создаёт и связывает пару дополнительных компонентов(может размещается в другом месте).
CAB> constructor = {)
CAB> connect text to new io/TextBuffer
CAB> connect console to new system/Console
CAB> (}
CAB> //Как бы АПИ(на подобии импорта в Python).
CAB> jack text:Text
CAB> jack console:Out
CAB> //Главная функция(как main в Си).
CAB> doer = {)
CAB> text.fromFile("D:\\t.txt")
CAB> while text.hasNext do
CAB> s = text.next
CAB> if(! comp(s,"hide string")) => console.println(s)
CAB> end
CAB> (}
CAB> //Функция для сравнения строк
CAB> def comp = {a:Str, b:Str)
CAB> a == b
CAB> (Bool}
CAB> }
CAB>
Ну, насколько я понял синтаксис и структуру кода, все равно получается практически описание класса.
В чем профит?
NC>Я например уже давно занимаюсь разработкой собственного хакерского языка программирования, который бы, сохраняя старый добрый си-подобный синтаксис и сишную идеологию, объединял бы максимум фич большинства языков программирования, таких как C, C++, С++/Qt, Objective C, Delphi, D, C#, Java, Scala, Nemerle, Go, Rust, JavaScript, Python, Ruby, Comega и некоторых других.
Я пробовал так делать
, получилось гора фичь где и чёрт ногу сломит, в общем не айс(но может я плохо пробовал). Как следствие я пришел к выводу что просто добавлять фичи в ЯП не достаточно, нужно дать программерам возможность подключать и отключать их по мере необходимости, и добавлять свои (путём расширения компилятора), т.е. синтаксис должен быть изменяемым. NC>Ничего подобного, идея столь же проста и низкоуровнева, как пересылка двух байт по сети. Главное — не превращать ее в ограничение "все объекты и только объекты". Потому что любая фича — добро, а любое ограничение — зло.
Обратите внимание на этот
проект, думаю вам понравится, там практически не будет ни каких ограничений.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
NC>Потому что любая фича — добро, а любое ограничение — зло.
это либо стеб, либо непонимание базовых вещей.
Кроме написания кода и его выполнения есть еще нужда в разнообразных (максимально автоматизированных) операциях над кодом.
Начиная с оптимизирующей компиляции, инструментирования, подсчета code coverage, совместной параллельной разработки большой командой людей, отладки, рефакторинга и заканчивая доказательствами корректности, и даже в некоторых случаях решением проблемы остановки.
И все эти операции тем проще делать, чем фич меньше, чем более они продуманы, и чем ограничений больше.
0>Ну, насколько я понял синтаксис и структуру кода, все равно получается практически описание класса.
Не совсем так, почти все определения внутри скобок (за "PROTO") не доступны из вне(в примере выше не одна из функций не может быть вызвана из вне), а также есть внутренний поток выполнения, ну и отличная от ООПшной политика использования компонентов. Т.е. это ближе к небольшим приложению, чем к классу(хотя конечно можно и классы писать в таком стиле, но это не они). 0>В чем профит?
Меньшая зависимость от окружения.
Отсутствие необходимости понимания ОО парадигмы.
Наличие специальных фич и прибамбасов для компонентного программирования(в целом задача: сделать так чтобы большие программы можно было бы просто("программирование мышкой") собирать из маленьких компонентов, и чтобы эти компоненты можно было легко создавать).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, dilmah, Вы писали:
D>это либо стеб, либо непонимание базовых вещей. D>Кроме написания кода и его выполнения есть еще нужда в разнообразных (максимально автоматизированных) операциях над кодом. D>Начиная с оптимизирующей компиляции, инструментирования, подсчета code coverage, совместной параллельной разработки большой командой людей, отладки, рефакторинга и заканчивая доказательствами корректности, и даже в некоторых случаях решением проблемы остановки. D>И все эти операции тем проще делать, чем фич меньше, чем более они продуманы, и чем ограничений больше.
Все эти операции никак не коррелируют с количестом фич. А многое из того, что вы перечислили, нужно по большому счету всяким менеждерам (которые идут конечно лесом), а не настоящим программерам.
А непонимание базовых вещей... я не случайно упомянул Boost. Это именно оно, это все те фичи, которые могли бы быть грамотно, органично встроены в язык, но не были встроены, и реализуются через одно место — препроцессор, метапрограммирование на шаблонах и т.д.
Программисты все равно реализовали все эти фичи. Получилось местами криво, с массой скрытых внутренних ограничений, иногда несовместимым между разными фичами способом (или требующим писать еще какой-то код-прослойку), отнимающий кучу времени при компиляции...
Я считаю, было бы лучше, если бы все это было встроено в язык, чтобы была делатьно проработана взаимосвязь всех фич (а она на самом деле не такая уж и сложная, стоит только немножно подумать... некоторые вещи вообще лежат на поверхности). Причем при грамотном подходе оказывается, что фичи из казалось бы разных областей дополняют друг друга автоматически в самых неожиданных местах.
А библиотеки должны быть маленькими и решать конкретные прикладные задачи — например, криптографию, сложные математические расчеты, обработку изображений, сетевые протоколы и т.п. Но не строки и не коллекции, не многопоточность и не сигналы/слоты.
, получилось гора фичь где и чёрт ногу сломит, в общем не айс(но может я плохо пробовал). Как следствие я пришел к выводу что просто добавлять фичи в ЯП не достаточно, нужно дать программерам возможность подключать и отключать их по мере необходимости, и добавлять свои (путём расширения компилятора), т.е. синтаксис должен быть изменяемым.
Как раз нет, синтаксис должен быть фиксированным, иначе программистам придется изучать каждый раз новый язык. Просто он должен быть универсальным, в нем не должно быть бессмысленных ограничений. То есть если есть например фичи X и Y, то должны быть и иметь предсказуемый смысл суперпозиции фич X(Y) и Y(X).
CAB>Обратите внимание на этот
проект, думаю вам понравится, там практически не будет ни каких ограничений.
Обращал. Они молодцы (хотя-бы потому что делают что-то практически), но ИМХО полезли несколько не в ту степь Языковой фреймворк — это весьма специфическая вещь, разрабатывать свой язык под каждую задачу ИМХО излишне. Достаточно просто взять все лучшее и соединить вместе, не просто "свалить в кучу", а именно соединить, с максимальным взаимопроникновением.
Здравствуйте, NeoCode, Вы писали:
NC>Зачем противопоставлять то, что можно и нужно объединять? Обычные функции — это объекты, функциональные объекты ("делегаты") — тоже объекты, методы — это функции с дополнительным аргументом, отвязку от классов сделать элементарно (простейшая фича, обратная методам-расширениям — для любого объекта obj класса MyClass вызов obj.Method() можно заменить на MyClass.Method(&obj); и почему ее в С++ не сделали?). Любой метод объекта — это и объект, и функция. А уж если класс поддерживает operator(), то объект этого класса — тоже функция. Получаем, что все есть все. NC>Пространства имен должны иметь право быть везде, в том числе внутри классов и функций (тоже элементарно делается).
Боюсь, потом кому-то придется разгребать кучу индокода.
NC>Народ же или закицливается на супер-строгом ООП, или погружается в математизированные дебри ФП. Не по-хакерски все это, не по-хакерски.
Не по хакерски, ясное дело. Промышленное программирование предъявляет другие требования к ЯП.
Здравствуйте, NeoCode, Вы писали:
NC>В реальном кодигне сложность в том, что вот надо бы воспользоваться какой-то возможностью, а ее нет. И появляются монстры типа Boost, метапрограммирования на шаблонах, куча классов там где достаточно обойтись одной строчкой кода и т.п. Потому что в любом языке чего-то, да нет: функционального программирования, рефлексии, структурной типизации, динамического связывания, отправки сообщений, нормального метапрограммирования на макросах, низкоуровневых возможностей... И программисты городят безумные огороды, пытаясь с помощью существующих скудных средств имитировать те фичи, которых в языке недостает.
Лучше пусть будет пара безумных огородов в тех местах, где без них не обойтись, чем весь код будет представлять из себя один безумный огород.
NC>Я например уже давно занимаюсь разработкой собственного хакерского языка программирования, который бы, сохраняя старый добрый си-подобный синтаксис и сишную идеологию, объединял бы максимум фич большинства языков программирования, таких как C, C++, С++/Qt, Objective C, Delphi, D, C#, Java, Scala, Nemerle, Go, Rust, JavaScript, Python, Ruby, Comega и некоторых других.
Интересно будет посмотреть на результат.
NC>Потому что любая фича — добро, а любое ограничение — зло.
Нет. Фича может быть добром — и то не всегда — только если она полностью ортогональна всем другим фичам, чего в реальности достичь обычно невозможно. В реальных ЯП имеем фичи, с разной степенью кривизны согласованные друг с другом, и чем больше фич, тем больше кривизны и специальных случаев.
Здравствуйте, AlexRK, Вы писали:
ARK>Нет. Фича может быть добром — и то не всегда — только если она полностью ортогональна всем другим фичам, чего в реальности достичь обычно невозможно. В реальных ЯП имеем фичи, с разной степенью кривизны согласованные друг с другом, и чем больше фич, тем больше кривизны и специальных случаев.
Потому что разработчики языков не умеют согласовывать фичи. А не умеют, потому что исходят из неверных предпосылок. Мысль у них в основном одна: что-бы такое ограничить и запретить, чтобы бедные глупые программисты не ошиблись... Но программистам (настоящим Программистам конечно) все равно неймется, они и из урезанного набора возможностей пытаются выжать максимум. А поскольку набор урезанный, в "экстремальных" вариантах использования проявляется то, о чем разработчики языка даже и подумать не могли. Отсюда берется и кривизна, и специальные случаи.
CAB>>Как следствие я пришел к выводу что просто добавлять фичи в ЯП не достаточно, нужно дать программерам возможность подключать и отключать их по мере необходимости, и добавлять свои (путём расширения компилятора), т.е. синтаксис должен быть изменяемым. NC>Как раз нет, синтаксис должен быть фиксированным,
Тогда мы просто получим ещё один C++, такой же но другой NC>иначе программистам придется изучать каждый раз новый язык.
Это очень сильное преувеличении, нужно будет изучать только новые фичи. Посмотрите как это сделано в Scala.
При фиксированном синтаксисе исправление ошибок в начальном дизайне и удаление устаревших фич будет обходится очень и очень дорого. И если вы собираетесь развивать ваш ЯП и при этом не хотите превратить его в "болото" то, ИМХО, лучше отказаться от фиксированного синтаксиса. NC>Просто он должен быть универсальным, в нем не должно быть бессмысленных ограничений. То есть если есть например фичи X и Y, то должны быть и иметь предсказуемый смысл суперпозиции фич X(Y) и Y(X).
Даже если и возможно сделать ЯП с универсальным синтаксисом, он будет нереально сложным. С++ — пример попытки сделать такой ЯП.
Даже если и получится сделать УЯП, пройдёт совсем не много времени и в него захочется добавить что-то новое (технологии не стоят на месте), что чуть менее чем наверняка разрушит всю идиллию.
Большое достоинство фиксированного синтаксиса это возможность использовать старый и чужой код, при изменяемом синтаксисе это будет проблемой. Но и эта проблема решаема, например я в своём проекте
выбрал такой подход: Приложение состоит из небольших "кусочков" — компонентов. Процесс разработки ориентирован больше на переписывание компонентов, нежели на их исправление/дополнение. Т.е. например, какой-то старый(написаны с исп. устаревшего синтаксиса) компонент в приложении стал проблемой, вместо того чтобы разберется и править древний код, старый компонент выкидывается и вместо него пишется новый, лучше отвечающий актуальным требованиям и с использованием современных фич языка.
CAB>>Обратите внимание на этот
проект, думаю вам понравится, там практически не будет ни каких ограничений. NC>Обращал. Они молодцы (хотя-бы потому что делают что-то практически), но ИМХО полезли несколько не в ту степь Языковой фреймворк — это весьма специфическая вещь, разрабатывать свой язык под каждую задачу ИМХО излишне.
Я имел виду что это (возможно) будет весьма полезный для ленгмейкеров инструмент, который позволит экспериментировать(с комбинациями фич в частности) почти без ограничений.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
NC>>Как раз нет, синтаксис должен быть фиксированным, CAB>Тогда мы просто получим ещё один C++, такой же но другой
Нет, проблема С++ в том, что синтаксис изначально кривой, а не в том что он фиксированный. Как можно было бы решить проблему С++ — я написал ниже.
CAB>При фиксированном синтаксисе исправление ошибок в начальном дизайне и удаление устаревших фич будет обходится очень и очень дорого. И если вы собираетесь развивать ваш ЯП и при этом не хотите превратить его в "болото" то, ИМХО, лучше отказаться от фиксированного синтаксиса.
Решается легко и элементарно. Каждые N лет создается новый стандарт. В большинстве случаев изменения бедет незначительными — несколько новых ключевых слов, какие-то изменения в библиотеке. На примере C# мы видим, что ничего страшного не случается.
Если вдруг развитие computer science породит какую-то принципиально новую парадигму, которая потребует серьезного внесения изменений в существующий синтаксис, или если становится очевидно что накопилось слишком много ошибок дизайна языка — просто берем цифру 2 (3,4...) и приписываем к расширению файла. И говорим, что теперь компилятор будет поддерживать оба варианта синтаксиса (например cpp и cpp2). Поскольку такое будет происходить не чаще чем раз в 10 лет, у программистов будет куча времени и чтобы выучить новую модификацию, и чтобы переписать на нее код... или не переписывать, ведь от старого варианта никто не отказывается. Совместное использование обоих вариантов, разумеется, тоже возможно. А хорошему модульному компилятору все равно, сколько там вариантов — backend все равно остается общим.
CAB>Даже если и возможно сделать ЯП с универсальным синтаксисом, он будет нереально сложным. С++ — пример попытки сделать такой ЯП. CAB>Даже если и получится сделать УЯП, пройдёт совсем не много времени и в него захочется добавить что-то новое (технологии не стоят на месте), что чуть менее чем наверняка разрушит всю идиллию.
В том-то и дело, что можно сделать гораздо проще чем С++. Именно благодаря универсальности и изначально правильному подходу к архитектуре. Когда делали С++, об этом даже не думали, одни #include чего стоят.
CAB>Большое достоинство фиксированного синтаксиса это возможность использовать старый и чужой код, при изменяемом синтаксисе это будет проблемой. Но и эта проблема решаема, например я в своём проекте
выбрал такой подход: Приложение состоит из небольших "кусочков" — компонентов. Процесс разработки ориентирован больше на переписывание компонентов, нежели на их исправление/дополнение. Т.е. например, какой-то старый(написаны с исп. устаревшего синтаксиса) компонент в приложении стал проблемой, вместо того чтобы разберется и править древний код, старый компонент выкидывается и вместо него пишется новый, лучше отвечающий актуальным требованиям и с использованием современных фич языка.
Для соединения ваших компонентов, написанных на разных синтаксисах, все равно нужен общий синтаксис.
CAB>>ИМХО, лучше отказаться от фиксированного синтаксиса. NC>Решается легко и элементарно. Каждые N лет создается новый стандарт. В большинстве случаев изменения бедет незначительными — несколько новых ключевых слов, какие-то изменения в библиотеке.
Т.е. вы считаете большие изменения но редко, лучше чем маленькие но часто? Почему? NC>На примере C# мы видим, что ничего страшного не случается.
C# ещё молод, он только обрастает фичами и насколько мне известно(а известно мне не много) из него ещё не выкидывали ничего серьёзного(например делегаты). NC>Если вдруг развитие computer science породит какую-то принципиально новую парадигму, которая потребует серьезного внесения изменений в существующий синтаксис, или если становится очевидно что накопилось слишком много ошибок дизайна языка — просто берем цифру 2 (3,4...) и приписываем к расширению файла. И говорим, что теперь компилятор будет поддерживать оба варианта синтаксиса (например cpp и cpp2). Поскольку такое будет происходить не чаще чем раз в 10 лет, у программистов будет куча времени и чтобы выучить новую модификацию, и чтобы переписать на нее код... или не переписывать, ведь от старого варианта никто не отказывается. Совместное использование обоих вариантов, разумеется, тоже возможно. А хорошему модульному компилятору все равно, сколько там вариантов — backend все равно остается общим. И вместо одного теперь у нас будет два слабо совместимых ЯП, т.е. проблемы_одного_ЯП * 2 + проблемы_совместимости.
По такому пути пошел Python, результат: "Мы разрушили их Мир"(от сюда) CAB>>Даже если и возможно сделать ЯП с универсальным синтаксисом, он будет нереально сложным. С++ — пример попытки сделать такой ЯП. NC>В том-то и дело, что можно сделать гораздо проще чем С++. Именно благодаря универсальности и изначально правильному подходу к архитектуре. Когда делали С++, об этом даже не думали, одни #include чего стоят.
Очень интересно, у вас есть конкретные идеи как это сделать? CAB>>Большое достоинство фиксированного синтаксиса это возможность использовать старый и чужой код, при изменяемом синтаксисе это будет проблемой. Но и эта проблема решаема, например я в своём проекте
выбрал такой подход... NC>Для соединения ваших компонентов, написанных на разных синтаксисах, все равно нужен общий синтаксис.
Не совсем так:
1)Соединения относятся семантики, синтаксически это может быть оформлено как угодно.
2)Компоненты могут соединятся только с совместимыми, т.е. общая семантика должна быть только у совместимых соединений.
Хотя конечно, в этом случае, "соединения" это наиболее узкое место с точки зрения изменяемости ЯП.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Но трейд не совсем об этом.
И ООП это огромный "кусок" сложности, который я бы хотел выкинуть. 
