Re[15]: А почему vs ? - Философия программирования

Здравствуйте, C.A.B, Вы писали:

CAB> Кажется, сегодня я понял почему ФП это ООП для бедных, и наоборот

Но трейд не совсем об этом.
CAB> В ООП все методы распределены по объектам, там-же находятся и данные. В ФП функции(а так-же процедуры в ПП) и данные существуют отдельно, к тому-же функции могут быть разбросаны по программе как угодно(не считая ограничений вносимых областями видимости имён).

Зачем противопоставлять то, что можно и нужно объединять? Обычные функции — это объекты, функциональные объекты ("делегаты") — тоже объекты, методы — это функции с дополнительным аргументом, отвязку от классов сделать элементарно (простейшая фича, обратная методам-расширениям — для любого объекта obj класса MyClass вызов obj.Method() можно заменить на MyClass.Method(&obj); и почему ее в С++ не сделали?). Любой метод объекта — это и объект, и функция. А уж если класс поддерживает operator(), то объект этого класса — тоже функция. Получаем, что все есть все.
Пространства имен должны иметь право быть везде, в том числе внутри классов и функций (тоже элементарно делается).
Народ же или закицливается на супер-строгом ООП, или погружается в математизированные дебри ФП. Не по-хакерски все это, не по-хакерски.

Здравствуйте, 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). Т.е. использовать различные механизмы для различных задач, а не пытаться впихнуть все в одну парадигму.

NC>Потому что любая фича — добро, а любое ограничение — зло.

это либо стеб, либо непонимание базовых вещей.
Кроме написания кода и его выполнения есть еще нужда в разнообразных (максимально автоматизированных) операциях над кодом.
Начиная с оптимизирующей компиляции, инструментирования, подсчета code coverage, совместной параллельной разработки большой командой людей, отладки, рефакторинга и заканчивая доказательствами корректности, и даже в некоторых случаях решением проблемы остановки.
И все эти операции тем проще делать, чем фич меньше, чем более они продуманы, и чем ограничений больше.

Здравствуйте, AlexRK, Вы писали:

ARK>Нет. Фича может быть добром — и то не всегда — только если она полностью ортогональна всем другим фичам, чего в реальности достичь обычно невозможно. В реальных ЯП имеем фичи, с разной степенью кривизны согласованные друг с другом, и чем больше фич, тем больше кривизны и специальных случаев.

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

Здравствуйте, C.A.B, Вы писали:

Z>>Не-не-не! Девид Блейн, ты изобрел Nemerle?
CAB>Без ~~ГМО~~ МП

Нет, правда, не могу понять, почему все авторы языков упорно ставят в преимущества всякие "без": "без МП", "без ООП", "без указателей", "без ручного управления памятью" или "без сборки мусора", "без goto", "без изменяемых переменных" и т.д.???

Неужели вы хотите из Хакеров, из Мастеров Кода, из Гениев Программирования превратиться в тупых конвейерных рабочих? Хотите, чтобы, для того чтобы стать Профессиональным Программистом, достаточно было закончить двухнедельные курсы в каком-нибудь подвальчике?
Программирование должно быть простым и приятным... для Профессионалов. Профессионал должен наслаждаться красттой и гармонией кода, в том числе красотой и гармонией инструментов, которыми он пользуется. И МП, и ФП, и ООП, и низкоуровневые приемы программирования прекрасны. И видеть язык, в котором чего-то нет, весьма печально — такой язык воспринимается как калека.
А новички... те, кому программирование действительно интересно — почувствуют эту красоту и гармонию и придут к совершенству. А те, кому все равно что делать, лишь бы деньги платили — пускай идут к станку, сейчас в стране рабочих нехватает.

Здравствуйте, C.A.B, Вы писали:

CAB>>>"Переменных в Haskell просто нет" от сюда.
I>>

 >>> v <- newIORef 0
CAB>

CAB>Ok, кроме тех что живут в монадах.
В haskell действительно есть переменные, но под этим словом подразумевается нечто отличное от значения в императивном мире.
http://www.haskell.org/haskellwiki/Variable

а по поводу IORef — лучше о нем думать как о типизированном файле или таблице в памяти, имеющим(ей) одну позицию для записи. Все взаимодействие хаскеля с IORef осуществляется через IO, то есть фактически это внешний, изменяемый мир.

Здравствуйте, NeoCode, Вы писали:

NC>Практически все фичи языков программирования уже известны. Они хаотично разбросаны по множеству языков, и все что нужно — собрать их воедино, привести к единому виду и вылизать до идеального состояния и идеального взаимодействия.

"Поскольку дров на постройку сарая нет, перейдем сразу к строительству коммунизма" (с)

Почему вы думаете, что задача "собрать их воедино, привести к единому виду и вылизать до идеального состояния и идеального взаимодействия" имеет решение?

CAB>>статическую и динамическую типизацию(без костылей навроде "dynamic"),
NC>dynamic — это не костыль, а красивое решение. Программист использует статические типы, а там где надо — явно объявляет переменную динамического типа и использует ее.
В Python'е нет ни каких "dynamic" и есть д.типизация, т.е. "dynamic" не нужен для неё, т.е. это таки костыль. Исходя из принципа "фичи не должны быть изолированы от других", с чем ещё можно связать "dynamic"?
CAB>>изменение состояния и имутабельность(без костылей навроде монад или var'ов),
NC>Есть константы, есть переменные. Программист использует то что ему нужно. Где костыли?
Имутабельность это фича функциональных языков, суть её в том что нет изменяемых переменных.
CAB>>передачу по ссылке и передачу по значению,
NC>В С++ давно уже можно передавать и так, и так.
Я не говорю что нельзя, я спрашиваю как это сделать "простыми, естественными и открытыми".
CAB>>ручную работу с памятью и GC,
NC>А в чем проблема? Ну будет один оператор для динамического выделения памяти и создания объекта без GC, другой — с GC, третий — для удаления объекта и освобождения памяти. Программист решает, как он хочет создать объект — в GC или без него. Не забываем еще, что объекты могут быть созданы на стеке или глобально.
И вот у нас ещё три новых костыля, и сложность продолжает расти а надёжность падать

CAB>>примитивные типы и классы
NC>Чем они несовместимы? В чем например проблема реализовать наследование от примитивных типов?
Наследование это только одна проблем. Если у нас есть две разновидности типов, значит нам нужно как-то их различать, нужно два набора средств для работы с ними и/или нужны специальные правила(ограничения) для них(например в Java есть правило "объекты всегда посылке, примитивные всегда по значению", а в С++(а может и не в нём, не помню) есть специальный синтаксис позволяющий передавать или по ссылке или по значению). Всё это так-же увеличивает сложность.
CAB>>множественное наследование и отсутствие "ромбовидной проблемы",
NC>С наследованием многие проблемы решаются путем объединения концпеций "наследования" и "агрегации". Кое-что реализовано в языке Go, кое-что решается введением имен (псевдопеременных) для предков при наследовании.
Это определённо сложней чем просто запретить м. наследование, как Java.
CAB>>безопасность и быстродействие,
NC>Быстродействие на первом месте. Где нужна безопасность — используются безопасные подмножества, специальные атрибуты для функций, классов и модулей, которые запрещают некоторые вещи внутри (например указатели), добавляют дополнительные проверки и т.д. Нечто подобное сделано в D.
Ещё +100500 сложности.
CAB>>Например где в большой программе на Java д. типизация может быть полезна? И где в маленьком скрипте статическая не вредна?
NC>Статическая типизация естественна, удобна, а потому имеет приоритет над динамической.
А я(и наверняка все Питонщики, Рубисты, Перлист,...) считаю что динамическая более естественна и удобна, а статическая лиш полезна (это к тому что далеко не все разделяют ваши вкусы).
NC>В то же время бывают ситуации, когда нужен "вариантный тип", причем количество вариантов может быть заранее неизвестно. В таких случаях логично применять динамический тип.
Ещё +0.5 сложности.

Z>МП это не некромантия, это когда пишется код, цель которого генерировать другой код.
Да, я знаю, но считаю что при прочих равных, проще, лучше, быстрей и надёжней писать код который будет непосредственно решать задачу, чем код который будет генерировать код, который будет решать задачу.

Кажется, сегодня я понял почему ФП это ООП для бедных, и наоборот

Но трейд не совсем об этом.

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

Пример на 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> Собственно вопрос: Как вы считаете, верен ли мой выбор? Почему?
Без понимания, кто, как и с какой целью будет применять твой ЯП, дать ответ на этот вопрос не представляется возможным.

Здравствуйте, 0x7be, Вы писали:
0>Без понимания, кто, как и с какой целью будет применять твой ЯП, дать ответ на этот вопрос не представляется возможным.
Будет использоваться для написания компонентов.
Что-вpоде такого:

  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>Ничего подобного, идея столь же проста и низкоуровнева, как пересылка двух байт по сети. Главное — не превращать ее в ограничение "все объекты и только объекты". Потому что любая фича — добро, а любое ограничение — зло.
Обратите внимание на этот проект, думаю вам понравится, там практически не будет ни каких ограничений.

0>Ну, насколько я понял синтаксис и структуру кода, все равно получается практически описание класса.
Не совсем так, почти все определения внутри скобок (за "PROTO") не доступны из вне(в примере выше не одна из функций не может быть вызвана из вне), а также есть внутренний поток выполнения, ну и отличная от ООПшной политика использования компонентов. Т.е. это ближе к небольшим приложению, чем к классу(хотя конечно можно и классы писать в таком стиле, но это не они).
0>В чем профит?
Меньшая зависимость от окружения.
Отсутствие необходимости понимания ОО парадигмы.
Наличие специальных фич и прибамбасов для компонентного программирования(в целом задача: сделать так чтобы большие программы можно было бы просто("программирование мышкой") собирать из маленьких компонентов, и чтобы эти компоненты можно было легко создавать).

Здравствуйте, dilmah, Вы писали:

D>это либо стеб, либо непонимание базовых вещей.
D>Кроме написания кода и его выполнения есть еще нужда в разнообразных (максимально автоматизированных) операциях над кодом.
D>Начиная с оптимизирующей компиляции, инструментирования, подсчета code coverage, совместной параллельной разработки большой командой людей, отладки, рефакторинга и заканчивая доказательствами корректности, и даже в некоторых случаях решением проблемы остановки.
D>И все эти операции тем проще делать, чем фич меньше, чем более они продуманы, и чем ограничений больше.

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

Я считаю, было бы лучше, если бы все это было встроено в язык, чтобы была делатьно проработана взаимосвязь всех фич (а она на самом деле не такая уж и сложная, стоит только немножно подумать... некоторые вещи вообще лежат на поверхности). Причем при грамотном подходе оказывается, что фичи из казалось бы разных областей дополняют друг друга автоматически в самых неожиданных местах.
А библиотеки должны быть маленькими и решать конкретные прикладные задачи — например, криптографию, сложные математические расчеты, обработку изображений, сетевые протоколы и т.п. Но не строки и не коллекции, не многопоточность и не сигналы/слоты.

Здравствуйте, C.A.B, Вы писали:

CAB>Я пробовал так делать, получилось гора фичь где и чёрт ногу сломит, в общем не айс(но может я плохо пробовал). Как следствие я пришел к выводу что просто добавлять фичи в ЯП не достаточно, нужно дать программерам возможность подключать и отключать их по мере необходимости, и добавлять свои (путём расширения компилятора), т.е. синтаксис должен быть изменяемым.

Как раз нет, синтаксис должен быть фиксированным, иначе программистам придется изучать каждый раз новый язык. Просто он должен быть универсальным, в нем не должно быть бессмысленных ограничений. То есть если есть например фичи 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>Потому что любая фича — добро, а любое ограничение — зло.

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

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)Компоненты могут соединятся только с совместимыми, т.е. общая семантика должна быть только у совместимых соединений.
Хотя конечно, в этом случае, "соединения" это наиболее узкое место с точки зрения изменяемости ЯП.

Здравствуйте, C.A.B, Вы писали:

CAB>Т.е. вы считаете большие изменения но редко, лучше чем маленькие но часто? Почему?

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

CAB>C# ещё молод, он только обрастает фичами и насколько мне известно(а известно мне не много) из него ещё не выкидывали ничего серьёзного(например делегаты).

А зачем их _выкидывать_?

CAB>

И вместо одного теперь у нас будет два слабо совместимых ЯП, т.е. проблемы_одного_ЯП * 2 + проблемы_совместимости.
CAB>По такому пути пошел Python, результат: "Мы разрушили их Мир"(от сюда)

С и С++. И это несколько десятилетий назад. Сейчас можно сделать то-же самое, но с учетом прежних ошибок.

CAB>1)Соединения относятся семантики, синтаксически это может быть оформлено как угодно.

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

Здравствуйте, C.A.B, Вы писали:

CAB>Здравствуйте, maxkar, Вы писали:
M>>Это ровно до тех пор, пока не нужно делать полиморфное поведение в рантайме. Оно же — связывание имени процедуры вместе с кодом процедуры. Явная передача функций (и вообще трактовка их как значений) может снести крышу этим вашим "циферки и буковки". Явное создание замыканий или интерфейсов будет похоже на OOP.
CAB>Связывание в рантайме это другой вопрос. Допустим у нас уже всё связано, уже есть некоторый API и нам нужно только реализовать какое-то внутреннее поведение, т.е. какой-то код, чего-то делающий с этим API.

У вас не получится сделать API без решения вопросов со связыванием функций. Допустим, у вас вообще нет ссылок на функции (и объектов). Тогда вы даже sort не сможете положить в библиотеку. sort'у же нужно компаратор передавать. И придется у вас каждый раз сортировку реализовывать по месту. С другой стороны, если взять FP, у вас определенно будет возможность связывать имя (переменной функционального типа) с ее значением во время выполнения. При этом в "хорошем" FP вы сможете даже создавать новые функции в runtime (сравните с C, где функцию передать можно, а создать — нет). Где-то посередине находится ООП. В нем функция не является объектом первого класса (т.е. ее нельзя явно передать), но можно в runtime объединять поведение (композиция объектов).

Вот даже ваш пример по ссылке можно рассмотреть. У вас явно написан цикл. Он понятен. Но он неудобен! Сравните:

lines = text.FromFile("D:\\t.txt").asLinesIterator()
forEach(lines, function(line) {
  if(! comp(s,"hide string")) => console.println(s)
})

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

forEach(text.FromFile("D:\\t.txt").asLinesIterator(), when(("hide string" ==), console.println))

forEach и when — обычные пользовательские функции (причем простые внутри). Правда (==) разжалован в обычную функцию. Как показывает практика, это очень удобно и полезно — не приходится писать кучу заглушек, а такие примитивы нужны относительно часто для композиции.

Можно не останавливаться на достигнутом. Введем инфиксное применение функций (haskell). Сделаем (или в стандартной библиотеке, или для себя) функцию, которая сразу возвращает файл как iterator. Тогда все будет еще лучше:

linesIterator("D:\\t.txt") `forEach` (console.println `when` (x => x == "hide string"))

Здесь when изменила сигнатуру по сравнению с предыдущим примером.

И мы еще не рассматривали случаи дальнейшего усложнения. Можно научить этот фрагмент кода работать с любыми потоками, итерируемыми по строкам (stdio тот же). Можно научить его выводить в не в консоль, а в другой файл. Можно передавать ему строку извне. Если вы делаете компонентную систему, нужно уметь легко комбинировать компоненты (создать несколько фильтров для разных строк, например). Т.е. "компонент" — аналог объекта и может существовать не в одном экземпляре. А если вы претендуете на место питона, вам потребуются функциональные комбинаторы (см. последний вариант). Хотя бы потому, что на питоне я подобное могу написать в одну строку (причем относительно понятно и на обычных функциях), а у вас приходится циклы раскручивать. А еще в питоне утиная типизация, что тоже упрощает типичные для него задачи.

Лирическое отступление. У вас компоненты планируются first-class сущностями или нет? Т.е. можно ли будет создать новый экземпляр компонента во времени выполнения? Как показывает практика, чем больше first-class объектов, тем меньше нужно писать монотонного синтетического кода. Вот посмотрите на ocaml. Там в конце концов сделали first-class modules. И осталась там не из first-class вроде бы только система типов.

CAB>>> Ну и в третьих — чтобы добавить какие-то новые методы для работы некоторым типом не нужно расширять класс, можно просто определить эти методы там где они нужны.
M>>И здесь вы ошибаетесь. Вы ведь не добавить методы хотите. Можно ведь добавить метод, работающий с объектом, и не расширяя сам оъект (класс). Можно определить метод в другом объекте.
CAB>ИМХО, это нарушение принципов ООП(когда дугой объект чего-то делает с данными, которые инкапсулирует первым).

Нет. Здесь нет нарушения инкапсуляции. В типичном сценарии новый метод прекрасно выражается через публичное API объекта. Даже некоторые библиотечные функции (которые обычно принадлежат объекту) тоже являются такими "extension method". Если отказаться от вызова через точку, то разницы между "собственными" и "несобственными" методами не будет. Будут только методы, определенные в различных "единицах компиляции (модулях/пакетах и т.п.)". Да, там тоже останется контроль доступа. Но он ничем принципиально отличаться от объектного не будет. Либо у вас будут абстрактные типы данных (где какие-то поля доступны только из определенных мест) с точно такими же проблемами при доступе ко внутреннему состоянию (когда не в любое место можно добавить метод), либо не все внутренности объекта будут скрыты, т.е. инкапсуляции вообще не будет.

Здравствуйте, dilmah, Вы писали:

NC>>Потому что любая фича — добро, а любое ограничение — зло.

D>это либо стеб, либо непонимание базовых вещей.
Да нет, есть в этом что-то новаторское и интересное. Не совсем понятно, как с этим потом жить в реальном мире и к чему кокнретно это приведет, но все же...

D>Кроме написания кода и его выполнения есть еще нужда в разнообразных (максимально автоматизированных) операциях над кодом.
У вас слишком традиционный взгляд на вещи. "Есть код, есть компилятор, есть сборка". У вас "язык" фиксирован потому, что фиксирован компилятор. А вы попробуйте отказаться от такого понимания. С точки зрения "большой картины" нам код не нужен. Нам нужно что-то, что производит в результате целевой "модуль" (модули). Результатом могут быть библиотеки (dll/lib/obj), исполняемый код (exe тот же), какие-то другие артефакты. Заметьте, здесь кода нет. Теперь посмотрим, что же у нас на самом деле производит нужные модули. Код? Нет. Компилятор? Нет. Его нужно запустить, сказать, что откуда брать и т.п. Скрипт сборки? Да, он. Он сам запускает компилятор и в результате формирует требуемые артефакты. Затем работа идет с этими артефактами.

Еще раз повторю процесс. Мы что-то запустили и получили в результате требуемый артефакт. Где же здесь код и зачем он нужен? Фактически, это дополнительные данные для скрипта сборки. Какая-то модель. Да, артефакты генерируются "компилятором". Но почему мы жестко фиксируем здесь компилятор (c/java/c#)? Зачем это нам? Давайте возьмем несколько разных библиотек и соберем свой "компилятор". Пусть одна хорошо оптимизирует математику, другая — хорошо генерирует DTO, третья еще что-то делает. И с использованием этих инструментов соберем наш целевой артефакт.

Таким образом, мы больше не пытаемся сделать "one compiler fits all". Мы для разных задач берем маленькие фрагменты и интегрируем их на базе одной платформы. Вероятно, нужно будет написать немного кода (в среде сборки), чтобы интегрировать эти модели (адаптировать соглашения о вызове и т.п.).

D>Начиная с оптимизирующей компиляции, инструментирования, подсчета code coverage,
А зачем под все эти задачи пытаться делать "one language fits all"? Только в этом случае возникает проблема "любых фичей". Зачем вы хотите "тотально" все оптимизировать? Зачем вы хотите все универсально "инструментировать" на неприспособленной для этого модели? Не лучше ли взять небольшой и ограниченнй язык, который допускает очень хорошую оптимизацию и использовать его для некоторых фрагментов? Да и зачем придумывать один оптимизатор, сводить все к одной универсальной модели "код на каком-то языке" а затем пытаться из нее восстановить высокоуровневые конструкции, которые нужно оптимизировать. Можно ведь сразу сделать несколько оптимизаторов на различных уровнях (специализированных по сферам применения). Аналогично с инструментацией — по "высокоуровневой модели, предусматривающей инструментацию" удобнее производить инструментацию (и в нужное время), чем по чему-то универсальному. Если мы размечаем инструментацию с некоторыми ограничениями (например, только на границах методов), то мы можем еще и оптимизирующий компилятор использовать внутри этих границ (внутри метода).

D>совместной параллельной разработки большой командой людей, отладки, рефакторинга и заканчивая доказательствами корректности, и даже в некоторых случаях решением проблемы остановки.
Да, с разработкой/рефакторингом не очень. Но на "своих" моделях приложения это можно делать не слишком сложно. Доказательства корректности же как раз удобно проводить на специальных подмножествах языка (ровно там, где эти доказательства хорошо автоматически работают).

D>И все эти операции тем проще делать, чем фич меньше, чем более они продуманы, и чем ограничений больше.
Да, все правильно. Чем меньше фич, тем проще это делать. Но вы страдаете той же болезнью, что и математики. Вы приемлете только глобальные решения. Если оптимизировать, мы должны уметь оптимизировать все. Если строить test coverage, мы должны уметь его строить по любому коду. И т.д. Из этого, конечно, следует, что ограничения нужно пихать везде. Но начальные посылки не верны. Нам обычно не нужно оптимизировать все! Тогда в тех местах, где нужна оптимизация, мы будем использовать "хорошо оптимизируемый язык". Причем если нас не волнует "тотальность", этот язык можно сделать более узким (если же нужна тотальность, приходится идти на компромиссы, чтобы какие-то другие задачи были удобными).

Так что возможность иметь фичи — это хорошо. Причем "фичи" на самом высоком уровне. Т.е. я сначала собираю компилятор (компиляторы), а затем уже ими собираю артефакты. И так для каждого проекта/модуля. Причем я именно собираю компилятор из нужных мне фич. Не путать с макросами, где опять тот же "тотальный" подход ("весь код процессится одинаково раскрытием макросов"). При хорошем наборе и удобстве добавления фичей это не будет большой проблемой. Все таки читать что-то на "родном" языке проще, чем то же самое, переведенное на "минимальный набор фич". Во втором случае банальные вещи записываются гораздо многословней.

M>У вас не получится сделать API без решения вопросов со связыванием функций. Допустим, у вас вообще нет ссылок на функции (и объектов).
Ссылок на функции нет, но функции == значения(предполагается функционально-императивный ЯП).
M>При этом в "хорошем" FP вы сможете даже создавать новые функции в runtime (сравните с C, где функцию передать можно, а создать — нет). Где-то посередине находится ООП. В нем функция не является объектом первого класса (т.е. ее нельзя явно передать), но можно в runtime объединять поведение (композиция объектов).

ФП интересная штука, но сложная. На прошлой неделе на курсе Functional Programming in Scala был assignment где нужно было написать набор функций для работы с множествами(создание, объединение, проверка содержится ли элемент, фильтрация и прочее), причём весь код не содержит ни одной переменой, даже не изменяемой(элементы множества тоже функции). Всей реализации строк 20, но медитировал я над ней с пол дня.
M>Вот даже ваш пример по ссылке можно рассмотреть. У вас явно написан цикл. Он понятен. Но он неудобен! Сравните:
M>forEach и when — обычные пользовательские функции (причем простые внутри). Правда (==) разжалован в обычную функцию. Как показывает практика, это очень удобно и полезно — не приходится писать кучу заглушек, а такие примитивы нужны относительно часто для композиции.
Эти и подобные вещи я собираюсь реализовывать в виде синтаксического сахара, т.е. перенести их в компилятор.
M>Лирическое отступление. У вас компоненты планируются first-class сущностями или нет? Т.е. можно ли будет создать новый экземпляр компонента во времени выполнения?
Да, здесь замета об компонентной части, она большая и нудная, потому лучше просмотреть по диагонали.

Здравствуйте, AlexRK, Вы писали:

ARK>Почему вы думаете, что задача "собрать их воедино, привести к единому виду и вылизать до идеального состояния и идеального взаимодействия" имеет решение?

А почему нет? Это не создание принципиально новой парадигмы, которая еще неизвестно как себя поведет в реальной жизни. Это просто аккуратная и крополтивая работа.

Здравствуйте, NeoCode, Вы писали:
NC>А почему нет? Это не создание принципиально новой парадигмы, которая еще неизвестно как себя поведет в реальной жизни. Это просто аккуратная и крополтивая работа.
Вы, по-видимому, опираетесь на предположение о том, что все "фичи" ортогональны, так что можно по каждой из них принять наилучшее решение. На практике — нет, не ортогональны. И решения, принятые в одном месте, неизбежно скажутся в других местах.
Это означает, что "идеального" решения некоторых вопросов в принципе найти нельзя — вам придётся выбирать между двумя и более плохими вариантами, а не между плохим и хорошим.

NC>Практически все фичи языков программирования уже известны. Они хаотично разбросаны по множеству языков, и все что нужно — собрать их воедино, привести к единому виду и вылизать до идеального состояния и идеального взаимодействия.
Пол вечера вчера думал над этим предложением и возникло несколько вопросов:
Вы хотите объединить в одно ЯП все(ну или большинство) существующих фич, например такие как возможность передавать функции через аргументы из Haskell'я и указатели из Си?
Что вы будете делать с несовместимыми фичами, например статическая и динамическая проверка типа?
Почему вы считаете, что большое количество фич(а их реально много придумано за последние 50 лет) в одном ЯП не перегрузит его синтаксис и у вас не получится новый, но гораздо более страшный, С++.
Например мне хватает наверно процентов 10-30 от возможностей ЯПов которыми я пользуюсь(вероятно для других программистов это тоже справедливо), и эти ЯПы содержат не так уж и много фичь. Т.е. каждый будет использовать из вашего ЯП только небольшой процент фич. Т.е. фактически все они будут писать на разных языках. Т.е. изучение вашего языка(до такой степени чтобы понимать что написали другие люди), будет по сложности сопоставимо с изучением нескольких разных языков. Что с этим делать?
Набор фич ЯП определяет в какой области(домене) он будет использоваться. Причём фичи полезные в одной области, могут бессмысленными или даже вредными в другой. Например динамическая типизация полезна в Python'е и вредна в Java. Что с этим делать?

M>Так что возможность иметь фичи — это хорошо. Причем "фичи" на самом высоком уровне. Т.е. я сначала собираю компилятор (компиляторы), а затем уже ими собираю артефакты. И так для каждого проекта/модуля. Причем я именно собираю компилятор из нужных мне фич. Не путать с макросами, где опять тот же "тотальный" подход ("весь код процессится одинаково раскрытием макросов"). При хорошем наборе и удобстве добавления фичей это не будет большой проблемой. Все таки читать что-то на "родном" языке проще, чем то же самое, переведенное на "минимальный набор фич". Во втором случае банальные вещи записываются гораздо многословней.
Cool

Я как раз проектирую такой компилятор. Идея такова: компилятор фактически представляет из себя пакет компонентов, в который входят разные служебный компоненты(типа логера, лодеров и т.п.) и компоненты реализующие трансляцию разных фич и сахара в IL. В начале каждого файла исходного текста можно будет на специальном DSL подключать/отключать фичи языка. При компиляции этот DSL будет интерпретироваться спец. компонентом, который выстроит цепочку из компонентов-трансляторов, через которую пройдёт исходный текст.

Здравствуйте, C.A.B, Вы писали:

CAB>Вы хотите объединить в одно ЯП все(ну или большинство) существующих фич, например такие как возможность передавать функции через аргументы из Haskell'я и указатели из Си?
Функции через аргументы давно уже передаются во всех языках, например C# или D. И это не указатели.

CAB>Что вы будете делать с несовместимыми фичами, например статическая и динамическая проверка типа?
В том же C# есть тип dynamic, который представляет собой динамический тип внутри системы статической типизации. Все работает.

CAB>Почему вы считаете, что большое количество фич(а их реально много придумано за последние 50 лет) в одном ЯП не перегрузит его синтаксис и у вас не получится новый, но гораздо более страшный, С++.
Потому что можно свалить все в кучу (как это в основном и делается), а можно построить наикрасивейшую архитектуру, в которой все фичи будут логически связаны и вытекать одна из другой.

CAB>Т.е. фактически все они будут писать на разных языках. Т.е. изучение вашего языка(до такой степени чтобы понимать что написали другие люди), будет по сложности сопоставимо с изучением нескольких разных языков. Что с этим делать?
Фичи должны быть простыми, естественными и открытыми. То есть опять то, о чем я говорю — связность конкретной фичи с другими, целостность языка. Если фича изолирована от других, не связана с ними, то мало того что ей никто не пользуется — использование ее затруднительно, потому что появляются конструкции, которые вроде бы логичны с точки зрения языка, но не компилируются. И нормальных программистов это раздражает.

CAB>Набор фич ЯП определяет в какой области(домене) он будет использоваться. Причём фичи полезные в одной области, могут бессмысленными или даже вредными в другой. Например динамическая типизация полезна в Python'е и вредна в Java. Что с этим делать?
Она не вредна и не полезна. Есть места в программах, где она может быть полезна, и это не связано с тем, на каком языке программа написана. А если ее нет — то людям приходится выкручиваться и придумывать обходные пути там, где логичнее было бы применить эту самую динамическую типизацию.

CAB>>Почему вы считаете, что большое количество фич(а их реально много придумано за последние 50 лет) в одном ЯП не перегрузит его синтаксис и у вас не получится новый, но гораздо более страшный, С++.
NC>Потому что можно свалить все в кучу (как это в основном и делается), а можно построить наикрасивейшую архитектуру, в которой все фичи будут логически связаны и вытекать одна из другой.
Хотелось бы примеров

, хотя бы для нескольких не тривиальных фич.
CAB>>Т.е. фактически все они будут писать на разных языках. Т.е. изучение вашего языка(до такой степени чтобы понимать что написали другие люди), будет по сложности сопоставимо с изучением нескольких разных языков. Что с этим делать?
NC>Фичи должны быть простыми, естественными и открытыми. То есть опять то, о чем я говорю — связность конкретной фичи с другими, целостность языка.
Сказано красиво но, как например объединить:
статическую и динамическую типизацию(без костылей навроде "dynamic"),
изменение состояния и имутабельность(без костылей навроде монад или var'ов),
передачу по ссылке и передачу по значению,
ручную работу с памятью и GC,
примитивные типы и классы,
множественное наследование и отсутствие "ромбовидной проблемы",
безопасность и быстродействие,
в одном ЯП?
CAB>>Набор фич ЯП определяет в какой области(домене) он будет использоваться. Причём фичи полезные в одной области, могут бессмысленными или даже вредными в другой. Например динамическая типизация полезна в Python'е и вредна в Java. Что с этим делать?
NC>Она не вредна и не полезна. Есть места в программах, где она может быть полезна, и это не связано с тем, на каком языке программа написана. А если ее нет — то людям приходится выкручиваться и придумывать обходные пути там, где логичнее было бы применить эту самую динамическую типизацию.
Например где в большой программе на Java д. типизация может быть полезна? И где в маленьком скрипте статическая не вредна?

Здравствуйте, NeoCode, Вы писали:

NC>Здравствуйте, C.A.B, Вы писали:

CAB>>Т.е. вы считаете большие изменения но редко, лучше чем маленькие но часто? Почему?

NC>Практически все фичи языков программирования уже известны. Они хаотично разбросаны по множеству языков, и все что нужно — собрать их воедино, привести к единому виду и вылизать до идеального состояния и идеального взаимодействия.

Фичи известны, а так же известны и ограничения.

Для того, что бы ввести скажем списки, туплы, АлгТД, ПМ в язык, надо чем то пожертвовать — синтаксисом, скобочками теми же, оверхедом который убьет перформанс императивного кода, перерасходом памяти на всяких структурах, который снова убьет преимущества императивного кода.

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

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

Здравствуйте, NeoCode, Вы писали:

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

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

Здравствуйте, C.A.B, Вы писали:

CAB>Сказано красиво но, как например объединить:
CAB>статическую и динамическую типизацию(без костылей навроде "dynamic"),
dynamic — это не костыль, а красивое решение. Программист использует статические типы, а там где надо — явно объявляет переменную динамического типа и использует ее.

CAB>изменение состояния и имутабельность(без костылей навроде монад или var'ов),
Есть константы, есть переменные. Программист использует то что ему нужно. Где костыли?

CAB>передачу по ссылке и передачу по значению,
В С++ давно уже можно передавать и так, и так.

CAB>ручную работу с памятью и GC,
А в чем проблема? Ну будет один оператор для динамического выделения памяти и создания объекта без GC, другой — с GC, третий — для удаления объекта и освобождения памяти. Программист решает, как он хочет создать объект — в GC или без него. Не забываем еще, что объекты могут быть созданы на стеке или глобально.

CAB>примитивные типы и классы
Чем они несовместимы? В чем например проблема реализовать наследование от примитивных типов?

class MyInt : public int {
public: string toString();
};
MyInt x = 100;
x += 200;
x.toString();

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

CAB>множественное наследование и отсутствие "ромбовидной проблемы",
С наследованием многие проблемы решаются путем объединения концпеций "наследования" и "агрегации". Кое-что реализовано в языке Go, кое-что решается введением имен (псевдопеременных) для предков при наследовании.

CAB>безопасность и быстродействие,
Быстродействие на первом месте. Где нужна безопасность — используются безопасные подмножества, специальные атрибуты для функций, классов и модулей, которые запрещают некоторые вещи внутри (например указатели), добавляют дополнительные проверки и т.д. Нечто подобное сделано в D.

CAB>Например где в большой программе на Java д. типизация может быть полезна? И где в маленьком скрипте статическая не вредна?
Статическая типизация естественна, удобна, а потому имеет приоритет над динамической. В то же время бывают ситуации, когда нужен "вариантный тип", причем количество вариантов может быть заранее неизвестно. В таких случаях логично применять динамический тип.

Здравствуйте, AlexRK, Вы писали:

ARK>Можете привести пару-тройку примеров наикрасивейшей архитектуры? Просто хотелось бы обсудить что-нибудь более существенное, чем простые лозунги.

Да пожалуйста.

1. В С++ есть классы, вложенные в классы; классы, вложенные в функции; функции в классах; но нет функций, вложенных в другие функции. Не "лямбды", а просто одна фунцкия, объявленная внутри другой. Мелочь, а неприятно.

2. Шаблоны. Оставим за скобками синтаксическую кривизну и то что они не могут быть в библиотеках (lib). Могут быть шаблонные функции и шаблонные структуры (классы). Где шаблонное все остальное? Например, я бы не отказался от свободных фрагментов кода (не функций, а просто именованных кусков кода), которые можно параметризировать и вставлять в реальный код. Зачем? Лично мне такое бывает нужно в разработке программ для микроконтроллеров. Приходилось городить огроды из #define
Ну и параметризация — параметром может быть или тип, или целочисленная константа. Ну почему целочисленная-то? Чем float помешал? Почему нельзя параметризировать просто именами, строками, произвольными фрагментами кода?

Здравствуйте, NeoCode, Вы писали:

NC>1. В С++ есть классы, вложенные в классы; классы, вложенные в функции; функции в классах; но нет функций, вложенных в другие функции. Не "лямбды", а просто одна фунцкия, объявленная внутри другой. Мелочь, а неприятно.
NC>2. Шаблоны. Оставим за скобками синтаксическую кривизну и то что они не могут быть в библиотеках (lib). Могут быть шаблонные функции и шаблонные структуры (классы). Где шаблонное все остальное? Например, я бы не отказался от свободных фрагментов кода (не функций, а просто именованных кусков кода), которые можно параметризировать и вставлять в реальный код. Зачем? Лично мне такое бывает нужно в разработке программ для микроконтроллеров. Приходилось городить огроды из #define
NC>Ну и параметризация — параметром может быть или тип, или целочисленная константа. Ну почему целочисленная-то? Чем float помешал? Почему нельзя параметризировать просто именами, строками, произвольными фрагментами кода?

Это как-то слишком просто.

А можно будет параметризовать модулями или неймспейсами? Будет ли наследование функций? И, кстати, будет ли множественное наследование (классов)?

Здравствуйте, C.A.B, Вы писали:

CAB>Имутабельность это фича функциональных языков, суть её в том что нет изменяемых переменных.

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

Здравствуйте, AlexRK, Вы писали:

ARK>Это как-то слишком просто.
ARK>А можно будет параметризовать модулями или неймспейсами?
Да, любыми фрагментами кода, которые можно представить в виде ноды AST. Какая разница что это?
Модули и неймспейсы кстати логично объединить в одно понятие (module) и разрешить создавать модули в том числе и внутри классов и функций.

ARK>Будет ли наследование функций?
ARK>И, кстати, будет ли множественное наследование (классов)?
Сначала нужно довести до идеального состояния обычное наследование, а потом думать над "наследованием функций". Мне не очень понятно что это вообще такое.

Здравствуйте, Ikemefula, Вы писали:
CAB>>Имутабельность это фича функциональных языков, суть её в том что нет изменяемых переменных.
I>

I>Иммутабельно не в том, что нет изменяемых переменных, а в том, что можно построить вычисления на неизменяемых переменных. А изменяемые переменные есть практически везде.
"Переменных в Haskell просто нет" от сюда.

Здравствуйте, 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

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

Здравствуйте, C.A.B, Вы писали:

CAB>"Переменных в Haskell просто нет" от сюда.

 > v <- newIORef 0
 > readIORef v
 0

 > writeIORef v 7
 > readIORef v
 7

CAB>>"Переменных в Haskell просто нет" от сюда.
I>

 >> v <- newIORef 0

Ok, кроме тех что живут в монадах.

Здравствуйте, C.A.B, Вы писали:

CAB>Cool

Здравствуйте, Ziaw, Вы писали:
CAB>>Cool

Я как раз проектирую такой компилятор. Идея такова: компилятор фактически представляет из себя пакет компонентов, ...
Z>Не-не-не! Девид Блейн, ты изобрел Nemerle?
Без ~~ГМО~~ МП

Здравствуйте, C.A.B, Вы писали:

CAB>>>Cool

Я как раз проектирую такой компилятор. Идея такова: компилятор фактически представляет из себя пакет компонентов, ...
Z>>Не-не-не! Девид Блейн, ты изобрел Nemerle?
CAB>Без ~~ГМО~~ МП

Я тебя сейчас немного расстрою. Компоненты, про которые ты пишешь, это код который создает код, то есть МП.

З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), вместо макросов.

Здравствуйте, NeoCode, Вы писали:

NC>Нет, правда, не могу понять, почему все авторы языков упорно ставят в преимущества всякие "без": "без МП", "без ООП", "без указателей", "без ручного управления памятью" или "без сборки мусора", "без goto", "без изменяемых переменных" и т.д.???

Потому что авторы языков разбираются в программировании.

NC>Программирование должно быть простым и приятным... для Профессионалов.

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

NC>Профессионал должен наслаждаться красттой и гармонией кода, в том числе красотой и гармонией инструментов, которыми он пользуется.

Профессионал должен делать свою работу, за которую ему платят.

NC>И МП, и ФП, и ООП, и низкоуровневые приемы программирования прекрасны. И видеть язык, в котором чего-то нет, весьма печально — такой язык воспринимается как калека.

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

NC>А новички... те, кому программирование действительно интересно — почувствуют эту красоту и гармонию и придут к совершенству. А те, кому все равно что делать, лишь бы деньги платили — пускай идут к станку, сейчас в стране рабочих нехватает.

Просто ради любопытства — не скажете, вам сколько лет?

Здравствуйте, C.A.B, Вы писали:

CAB>Это(на сколько я понял) у вас кодогенератор.
Скорее, генератор бинарников. Все-таки под кодогенератором понимается штука, которая на выходе дает код и тот код потом еще компилируется. А у меня дополнительной компиляции выходу программы не требуется.

CAB>В целом ваш подход (наверно) похож на тот что используется в Nemerle, только у вас код генерируется функциями из библиотек (из п.1), вместо макросов.
Не

. Если я правильно понимаю, в немерле генерируется далеко не тот код, который у меня. В немерле генерируется некое промежуточное дерево (граф) с полноценными выражениями, statements, declarations, etc.... Эатем это дерево дается на вход компилятору, который его преобразует и генерирует целевой код. У меня уровень ниже (фактически, я уже произвожу ассемблер и использую только его сериализатор). Соответственно, и проблемы у компонентов другие (нужно имена сразу бинарные давать, т.е. сервисы вроде import не доступны, а чтобы сделать их доступными, нужно будет участвовать в 3-4 фазном процессе). Вот если бы макросы участвовали в многофазном разрешении имен (определения типов, определения методов, генерации кода) и банальные операторы были бы тоже макросами (а чего, у меня стековый калькулятор на выходе, так что никаких expressions, а линейная последовательность команд), тогда мы с Nemerle бы были ближе друг к другу.

	От:	NeoCode
	Дата:	15.04.13 07:32
	Оценка:	6 (1) +3

	От:	Ziaw
	Дата:	20.04.13 11:06
	Оценка:	+3

	От:	maxkar
	Дата:	14.04.13 17:00
	Оценка:	11 (2)

	От:	dilmah
	Дата:	15.04.13 17:51
	Оценка:	+2

	От:	NeoCode
	Дата:	16.04.13 05:17
	Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	17.04.13 16:43
Оценка:	6 (1)

От:	C.A.B	LinkedIn
Дата:	17.04.13 12:15
Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	17.04.13 06:25
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	17.04.13 09:58
Оценка: