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

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

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

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

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

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

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

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

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

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

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

Автор: C.A.B
Дата: 15.04.13

. Допустим у нас уже всё связано, уже есть некоторый 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, мы должны уметь его строить по любому коду. И т.д. Из этого, конечно, следует, что ограничения нужно пихать везде. Но начальные посылки не верны. Нам обычно не нужно оптимизировать все! Тогда в тех местах, где нужна оптимизация, мы будем использовать "хорошо оптимизируемый язык". Причем если нас не волнует "тотальность", этот язык можно сделать более узким (если же нужна тотальность, приходится идти на компромиссы, чтобы какие-то другие задачи были удобными).

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

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

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


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

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

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 помешал? Почему нельзя параметризировать просто именами, строками, произвольными фрагментами кода?

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

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

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

Автор: NeoCode
Дата: 17.04.13

", с чем ещё можно связать "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 сложности.

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

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



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

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

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

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

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