[C++] Чего вам нехватает в языке?

Ничего не смущает в этом, далеко не полном, перечне?

А что должно? Разные предметные области, разные DSL, и что?

То, что все эти DSL должны в итоге реализовываться одним и тем же языком, т.е. - в рамках одной и той же абстрактной машины.

То, что все эти DSL должны в итоге реализовываться одним и тем же языком, т.е. - в рамках одной и той же абстрактной машины.

И?

И из этого вытекает довольно очевидное следствие. Тем, кому оно не очевидно, следует посмотреть на максимально близкий к заявленной цели язык - lisp.

очень хочется, чтоб лисперы перестали ныть в топиках по С++ и занялись бы делом, но так как это нереально, то пожелаю нормальной поддержки юникода + поддержку его во всех стадартных функциях, а wchar_t чтоб отправили на свалку истории

Тем, кому оно не очевидно, следует посмотреть на максимально близкий к заявленной цели язык - Haskell.

Fixed, ибо лисп рядом не стоял с заявленной целью «язык должен быть таким, чтобы DSL могли ложиться в него, не требуя расширения».

Смотрю. Дальше что?

А дальше я буду реквестировать DSL на хаскелле для флэш-игры. )))

А дальше я буду реквестировать DSL на хаскелле для флэш-игры.

Компилятора Haskell во флэш, вроде бы, пока не существует.

Не надо! Lisp (точнее, Scheme), если выкинуть макры, очень хороший язык. А то, что находятся идиоты, которые на нем DSL всякие делают, так ведь и на C кое кто паршиво пишет сознательно, есть даже Obfuscated C Contest.

Ок, поставлю вопрос по другому. Какие есть хорошие реализации на хаскелле событийно-ориентированной логики? Что можно посмотреть окромя xmonad?

> Ничего не смущает в этом, далеко не полном, перечне?

Прекрасный перечень задач, для которых идеальным языком был бы C или сильно кастрированный C++.

> Не надо! Lisp (точнее, Scheme), если выкинуть макры, очень хороший язык.

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

> Не надо! Lisp (точнее, Scheme), если выкинуть макры, очень хороший язык.

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

Какие есть хорошие реализации на хаскелле событийно-ориентированной логики?

М-м-м, вариации на тему FRP?

> Fixed, ибо лисп рядом не стоял с заявленной целью «язык должен быть таким, чтобы DSL могли ложиться в него, не требуя расширения».

что Вы понимаете под «расширением языка»?

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

Затем, чтобы никому в голову не приходило делать DSL/eDSL.

Макры опасны, и потому не нужны.

> А кто говорит, что он плохой?

Ты говоришь, что Лисп плохой. Ты говоришь, что на нём можно делать DSL/eDSL. А я говорю, что не на всяком Лиспе это можно делать, и не всякий Лисп провоцирует подобное безответственное поведение.

> Макры опасны, и потому не нужны.

отличная логика =)

C++ опасен и потому не нужен,

Автомобили опасны и потому не нужны,

...

> Прекрасный перечень задач, для которых идеальным языком был бы C

С для реализации xslt преобразований? Я бы сначала подумал. ))

Абстрактная машина С крайне удачна (за счет семантики указателей) и потому хорошо подходит для очень широкого круга задач. Но она, естественно, не универсальна, а разнобой в реализациях превосходит таковой для лиспов, что требует переизобретения колеса практически в любой программе.

> Ты говоришь, что на нём можно делать DSL/eDSL

Ты просто не понимаешь, что такое DSL. У тебя оно подменено извращенным пониманием фанатичных лисп-задротов. Любая (еще раз - _ЛЮБАЯ_) именованная абстракция - первый шаг к DSL.

Абстрактная машина С крайне удачна (за счет семантики указателей) и потому хорошо подходит для очень широкого круга задач.

Абстрактная машина C КРАЙНЕ неудачна, в первую очередь за счёт того, что слово «абстрактная» к ней весьма слабо применимо. Это, в свою очередь, во многом обусловлено семантикой указателей.

> C++ опасен и потому не нужен,

C++ не настолько опасен. Как ты с темплейтами не извращайся, а языка, слишком сильно не похожего на C++ из них не получишь.

> С для реализации xslt преобразований? Я бы сначала подумал. ))

А я не думаю. Я просто беру и делаю. Ничего сложного тут нет.

разнобой в реализациях превосходит таковой для лиспов

Найди мне Lisp для PIC16.

> Ты просто не понимаешь, что такое DSL.

Я хорошо понимаю, что такое DSL. Насмотрелся на говнокод.

У тебя оно подменено извращенным пониманием фанатичных лисп-задротов.

Например, пониманием тех фанатичных задротов, которые макру LOOP придумали. Потому и говорю, что CL + макры = плохо, а Scheme - макры = хорошо.

Любая (еще раз - _ЛЮБАЯ_) именованная абстракция - первый шаг к DSL.

Макролюбы делают слишком много шагов, тогда как одного, первого шага более чем достаточно.

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

Тогда правильный ответ скорее Хаскелль.

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

Затем, чтобы никому в голову не приходило делать DSL/eDSL.

Макры опасны, и потому не нужны.

Да, да... Убивай космонавтов, они лезут на небо и делают что недозволено Богом.

> первый шаг к DSL.

один шак к DSL.

> в первую очередь за счёт того, что слово «абстрактная» к ней весьма слабо применимо.


Ну надо же?! Обычно С упрекают за прямо противоположное. Мол битность численных типов не определена.. )))

Это, в свою очередь, во многом обусловлено семантикой указателей.

Каким образом семантика указателей делает язык более конкретным? Она частично пересекается с семантикой ссылок - ключевой элемент практически всех современных распространнёных ЯП. Можно спорить, какая из них «более абстрактна»; я смотрю на них как на вещи одного порядка.

Кроме того, С имеет развитую систему выводимых типов, чем многие «высокоуровневые» языки похвастаться не могут.

> Тогда правильный ответ скорее Хаскелль.

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

> шак

*шаг

(да что ж такое-то?..)

>> в первую очередь за счёт того, что слово «абстрактная» к ней весьма слабо применимо.

Ну надо же?! Обычно С упрекают за прямо противоположное. Мол битность численных типов не определена.. )))

Абстрактность и неопределенность вещи вроде как совершенно разные.

Кроме того, С имеет развитую систему выводимых типов, чем многие «высокоуровневые» языки похвастаться не могут.

Эм... не понял. Можно подробнее?

Мол битность численных типов не определена

Интересно, у кого определена...

Каким образом семантика указателей делает язык более конкретным?

Арифметика указателей практически диктует реализацию. Ссылки этой проблемы лишены.

С имеет развитую систему выводимых типов, чем многие «высокоуровневые» языки похвастаться не могут.

Чего-чего???

> Интересно, у кого определена...

Длинный список есть на википедии по статье «языки программирования». ))

Арифметика указателей практически диктует реализацию.

Нет. Арифметика указателей предоставляет один из способов реализации. Крайне удобный для той предметной среды, для которой создавался язык.

Чего-чего???

Того-того. Не такую как в Хаскелле, конечно, но явно лучше чем во многих мэйнстрим-языках.

>> Чего-чего???

Того-того. Не такую как в Хаскелле, конечно, но явно лучше чем во многих мэйнстрим-языках.

Напиши конкретнее пожалуйста.

> Того-того. Не такую как в Хаскелле, конечно, но явно лучше чем во многих мэйнстрим-языках.

Ты белины объелся? Где ты там вывод типов увидел?

Арифметика указателей предоставляет один из способов реализации.

Арифметика указателей - элемент языка, она не может предоставлять способ реализации языка.

Достаточно определить выражение, скажем, как
type1 (*name1[value1])(type2,type3);
чтобы комилятор в нижеследующем выражении
name2 = name1[value2]
вывел тип правой части присваивания как
type1 (*)(type2,type3)
а тип выражения «name2(value3,value4)» соответственно как «type1».

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

> она не может предоставлять способ реализации языка.

А где была речь о реализации языка? Я понял эту фразу:

Арифметика указателей практически диктует реализацию.

Как реализацию предметной области.

Для тебя тоже новость, что в С типы указателей, массивов и функций - производные? ;)))

Бедненький анон. ))

Я понял эту фразу:

Арифметика указателей практически диктует реализацию.

Как реализацию предметной области.

Мы говорили о том, насколько абстрактна «машина», на которой работает C. Так что понял ты неправильно.

Тогда да.

чтобы комилятор в нижеследующем выражении

Да, ты прав, настолько вывод типов, действительно, есть.

А кто умывает транслятор?

> C++ не настолько опасен. Как ты с темплейтами не извращайся, а языка, слишком сильно не похожего на C++ из них не получишь.

при чем тут темплейты С++? разве я написал «темплейты в С++ опасны»?

> Кроме того, С имеет развитую систему выводимых типов, чем многие «высокоуровневые» языки похвастаться не могут.

lol

> А кто умывает транслятор?

Любая динамика.

> Для тебя тоже новость, что в С типы указателей, массивов и функций - производные? ;)))

давай начнем с того, что в С нет типов «массив» и «функция». но это ладно, я в Си не щ=шарю, объясни мне из какого типа выводится тип «указатель»?

> s/щ=шарю/шарю/

> Абстрактная машина C КРАЙНЕ неудачна, в первую очередь за счёт того, что слово «абстрактная» к ней весьма слабо применимо. Это, в свою очередь, во многом обусловлено семантикой указателей.

Абстрактная машина C КРАЙНЕ удачна, в первую очередь за счёт того, что она близка к железу (и следовательно что слово «абстрактная» к ней весьма слабо применимо). Это, в свою очередь, во многом обусловлено семантикой указателей.

> withOpenFile :: String -> (File -> a) -> Maybe a

...

withOpenFile «file.txt» $ \foo -> myVeryCoolFunction foo

withOpenFile :: String -> (File -> a) -> IO a

...

result <- withOpenFile «file.txt» $ \foo -> myVeryCoolFunction foo

А еще то же самое для монады State. А еще то же самое для монады...

Получаем boilerplate. И где хваленая абстрактность языка???

З.Ы. для DSL требуется как минимум DDC. Кстати, к его эффектам доки написали или по-прежнему нет?

> Абстрактная машина C КРАЙНЕ удачна, в первую очередь за счёт того, что она близка к железу (и следовательно что слово «абстрактная» к ней весьма слабо применимо). Это, в свою очередь, во многом обусловлено семантикой указателей

разработчики С так не думают видимо, раз реализовали Limbo для Inferno...