LINUX.ORG.RU

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

 


0

0

Может бессмысленный топик, но хотелось бы знать мнение: каких фич языка не хватает по вашему в c++?

З.Ы. Убедительная просьба фанатам других языков программирования воздержаться от комментариев.

★★★★

> Зачем хочеть изменений в бородатом языке с большим legacy?..

Скажу за себя: если *вызывать готовые* функции и шаблоны, то legacy не так уж сильно проявляется и его вполне возможно обуздать специально сделанными против него механизмами. (в противовес созданию кода, натыкаясь на legacy синтаксис и legacy семантику)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Кстати, ты говорил у тебя были какие-то нароботки на тему расширяемого языка. Как там дела обстоят с ними? Если, конечно, не коммерческая тайна.

theos ★★★
()
Ответ на: комментарий от theos

> Кстати, ты говорил у тебя были какие-то нароботки на тему расширяемого языка. Как там дела обстоят с ними? Если, конечно, не коммерческая тайна.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Да ладно, ты сознательно превратил тред в тред о DSLях ;) Идеи есть у всех, я думал ты уже прототипом занялся. Смотри не стань маниловым с пыльной книжкой раскрытой на 14 странице ;)

theos ★★★
()
Ответ на: комментарий от www_linux_org_ru

Мне вот даже про «демократичность» пришлось сказать типа «читайте мои посты, чтобы понять, что это такое.

Так что *проще* обсуждать конкретные фичи, которые хочется иметь, а не общие принципы.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от theos

> Идеи есть у всех, я думал ты уже прототипом занялся. Смотри не стань маниловым с пыльной книжкой раскрытой на 14 странице ;)

постараюсь

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от lisprocks

>Особенно не нужны DSLы на C++.

Спасибо, К.О.!

Не надо прототипов. DSLы не нужны. Нужны языки, идеально интегрирующиеся в IDE.

Чувак, просыпайся! Парадигма Language Workbench уже давно не только придумана но и реализована. Man Jetbrains MPS ;)

theos ★★★
()
Ответ на: комментарий от theos

> Чувак, просыпайся! Парадигма Language Workbench уже давно не только придумана но и реализована. Man Jetbrains MPS ;)

Она там херовенько реализована, во первых. И во вторых сама парадигма дурацкая. DSL не нужны ни в каком виде, ни под каким соусом. Язык, который можно произвольным образом менять, это по определению write only язык. Никакая подсветка синтаксиса, типов и прочего не поможет, когда язык не читается в момент с листа визуально. Поддержка IDE это в первую очередь возможность бить кодера по рукам, когда он пытается умничать, а вовсе не потакание в этом самом умничаньи.

lisprocks
()
Ответ на: комментарий от lisprocks

Язык, который можно произвольным образом менять, это по определению write only язык.


Как раз наоборот. Опыт имеется ;)

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


DSL по оперделению читается лучше.

Она там херовенько реализована, во первых.


Сколько ты с ним работал?

theos ★★★
()
Ответ на: комментарий от theos

> Как раз наоборот. Опыт имеется ;)

Твой опыт не интересен. Интересен был бы опыт программиста, который поддерживал бы твой код после того, как ты ушел.

DSL по оперделению читается лучше.

Да да да. После того, как прочитается вся документация по этому DSL (если разработчику хватило ума и таланта её хорошо написать). И после того, как на каждом из мелких DSLей в проекте ты понапишешь достаточно кода для приобретения опыта чтения с листа.

Уж лучше когда есть один язык, и его все заведомо хорошо понимают. Лучше всего, чтобы этот язык был очень простым. Как Java. Или как Scheme без макросов.

Сколько ты с ним работал?

Достаточно. И с ним, и с Nemerle, и с mbase, и с другими глупыми цацками, претендующими на «расширяемость». Для попонтоваться перед другими кодерами - годится. Для реальной работы не подходит абсолютно.

lisprocks
()
Ответ на: комментарий от lisprocks

DSL не нужны ни в каком виде, ни под каким соусом. Язык, который можно произвольным образом менять, это по определению write only язык.

Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

В принципе, библиотека функций на C - это уже некоторым образом DSL. Другое дело, что так получаются только очень убогие DSL-и.

Miguel ★★★★★
()
Ответ на: комментарий от LamerOk

Я нигде не писал, что это будет работать на всех платформах.

Booster ★★
()
Ответ на: комментарий от Miguel

> Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

Да, именно это и нужно.

Еще желательно чтобы какая-то информация (хотя бы об AST, приоритетах) была доступна (взглядом) даже тому, кто не знает сам DSL. Т.е. изменяемый синтаксис не мог разрушить все до основания.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Еще желательно чтобы какая-то информация (хотя бы об AST, приоритетах) была доступна (взглядом) даже тому, кто не знает сам DSL. Т.е. изменяемый синтаксис не мог разрушить все до основания.

В общем, язык может быть любым, если это Хаскель.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

>> Так предметная область ничем не ограничена.

Тогда это не предметная область.


Ок, каковы ограничения предметной области программирования?

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Ок, каковы ограничения предметной области программирования?

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

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

> Кто-то пишет один DSL для всех возможных применений программирования?

Это у вас надо спросить. ))

Я отвечал вот на это:

Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

LamerOk ★★★★★
()
Ответ на: комментарий от Miguel

> В общем, язык может быть любым, если это Хаскель.

В общем, язык может быть любым, если в нем можно устоить Хаскель как embedded DSL. // FIXED

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Miguel

> Кто-то пишет один DSL для всех возможных применений программирования? Ну-ну, пока что это никому не удалось.

Кстати, насколько нелокальный вывод типов применяется в практическом хаскеле?

ИМХО вывод типов нужен когда мы определяем нечто *формулой*, и дальше наплевать (например, возведение в натуральную степень через умножение); интересно, что возведение в целую степень уже потребует каких-то аксиом (типа а*1/а=1); тут все локально (ограничено 1 функцией, может 2?)

самый нелокальный вывод типов, о котором я могу предположить — это например парсер для грамматики (где все фактически завязано в граф); все ограничено модулем

применяется ли более нелокальный вывод типов? зачем?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

какие есть примеры вывода типов, где он ограничен не одной функцией?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от LamerOk

Я отвечал вот на это:

Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

И? Какое отношение к этому имеет «предметная область программирования»?

Miguel ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Кстати, насколько нелокальный вывод типов применяется в практическом хаскеле?

Не понял, что имеется в виду. Совершенно.

Miguel ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> Еще желательно чтобы какая-то информация (хотя бы об AST, приоритетах) была доступна (взглядом) даже тому, кто не знает сам DSL

С листа? На бумаге? Или только после часового мышевозюканья поверх кода?

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

anonymous
()
Ответ на: комментарий от anonymous

Если первое, то тогда никакого DSL и быть не может и не должно.

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

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Но главное, он будет читабельным и поддерживабельным. И поймет его каждый, кто знает Си.

Что невозможно с DSL, полученным расширением языка.

anonymous
()
Ответ на: комментарий от anonymous

>Но главное, он будет читабельным и поддерживабельным. И поймет его каждый, кто знает Си.

Что невозможно с DSL, полученным расширением языка.

Неправда. Не будет он читабельным. И не поймет его сходу никто. Толку от того, что ты знаешь, что в месте Х вызов функции Y нету никакого. Нужно будет либо долго вникать в реализацию всех функций либы либо читать доки по либе. И то и другое можно делать и с DSL, только вот DSL есть шанс сделать менее грамоздким.

Waterlaz ★★★★★
()
Ответ на: комментарий от anonymous

Что невозможно с DSL, полученным расширением языка.

И мы возвращаемся к моему исходному тезису: язык должен быть таким, чтобы DSL могли ложиться в него, не требуя расширения.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

> >> Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

И? Какое отношение к этому имеет «предметная область программирования»?


А DSL'и никак не связаны с предметной областью?

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

А DSL'и никак не связаны с предметной областью?

Связаны. А при чём тут «предметная область программирования»?

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

При том, что получаемые DSL'и в теории должны одинаково хорошо подходить как для управления кассой с полумегабайтом памяти, последовательной линией связи, лсд-экранчиком в 60*3 и устройством печати, так и для моделирования физпроцессов теплообмена в газовых турбинах, xslt-преобразований, пакмана/тетриса для мобильного телефона или флэш-игры.

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

>При том, что получаемые DSL'и в теории должны одинаково хорошо подходить как для управления кассой с полумегабайтом памяти, последовательной линией связи, лсд-экранчиком в 60*3 и устройством печати, так и для моделирования физпроцессов теплообмена в газовых турбинах, xslt-преобразований, пакмана/тетриса для мобильного телефона или флэш-игры.

Меня вот смущает твой бессвязный ответ.

Waterlaz ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

И?

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

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

Miguel ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

Miguel ★★★★★
()
Ответ на: комментарий от LamerOk

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

lisprocks
()
Ответ на: комментарий от Miguel

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

lisprocks
()
Ответ на: комментарий от lisprocks

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

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

lisprocks
()
Ответ на: комментарий от lisprocks

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

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

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

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

...

korvin_ ★★★★★
()
Ответ на: комментарий от lisprocks

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

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

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

LamerOk ★★★★★
()
Ответ на: комментарий от lisprocks

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

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

Miguel ★★★★★
()
Ответ на: комментарий от korvin_

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

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

lisprocks
()
Ответ на: комментарий от LamerOk

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

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

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

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

lisprocks
()
Ответ на: комментарий от LamerOk

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

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

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

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

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

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

lisprocks
()
Ответ на: комментарий от LamerOk

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

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

Waterlaz ★★★★★
()
Ответ на: комментарий от lisprocks

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

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

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

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

Waterlaz ★★★★★
()
Ответ на: комментарий от Miguel

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


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

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


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

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

LamerOk ★★★★★
()
Ответ на: комментарий от Waterlaz

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

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

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

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

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

Waterlaz ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

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

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

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

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

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

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

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

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


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

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


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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

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

Waterlaz ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

anonymous
()
Ответ на: комментарий от LamerOk

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

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

Miguel ★★★★★
()
Ответ на: комментарий от Waterlaz

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

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

LamerOk ★★★★★
()
Ответ на: комментарий от Miguel

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

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

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


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

LamerOk ★★★★★
()
Ответ на: комментарий от anonymous

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

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

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

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

Miguel ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

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

Miguel ★★★★★
()
Ответ на: комментарий от lisprocks

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от LamerOk

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

lol

korvin_ ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от Miguel

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

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

разработчики С нас к сожалению не радуют языками — go откровенно убог, limbo, судя по его низкой популрности, вероятно тоже

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> limbo, судя по его низкой популрности, вероятно тоже

просто замечательная логика...

korvin_ ★★★★★
()
Ответ на: комментарий от LamerOk

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

Reactive

YAMPA

FieldTrip

Grapefruit

Что можно посмотреть окромя xmonad?

BlueTile

Frag

а вот тут можно посмотреть примеры событийно-ориентированного кода на Reactive. достаточно?

jtootf ★★★★★
()
Ответ на: комментарий от LamerOk

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

В смысле, динамическая типизация? Да нет, там тип вполне надёжно определяется в рантайме.

Miguel ★★★★★
()
Ответ на: комментарий от LamerOk

Вполне. Спасибо.

если что, самыми актуальными являются Reactive и Grapefruit; однако наиболее показательный в смысле выразительности проект (Frag) написан с использованием YAMPA

здесь есть полный список доступных на сегодня FRP-библиотек на Haskell (19 штук). если что - готов отвечать на вопросы по теме, с FRP возился (и потихоньку продолжаю)

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

19 штук

не, нифига не 19, штук шесть всего. вот блин, размазали по пакетам

jtootf ★★★★★
()
Ответ на: комментарий от Miguel

А толку то, что он определяется? Я никакого dbc на нем сделать не могу, кроме как в ручную.

Если мне нужен an_array, который в коде будет работать так:

an_array.each { |duck| duck.quak() }

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

an_array.push(el)

для каждого el гарантируется наличие метода quak()

А фигушки.

LamerOk ★★★★★
()
Ответ на: комментарий от jtootf

Еще раз спасибо. Предложением начну пользоваться где-то через месяц.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> для каждого el гарантируется наличие метода quak()
Щито? Может тебе ещё и для каждого числа метод split? А то ай-ай-ай получается, нехорошо.
Никто не запрещает определить свой класс с своим методом push.

mix_mix ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.