рассказываю. Удобство тут в том, что потом не приходится чесать репу и думать "КОКОКОВА ХУЯ ТОЧНОСТЬ ТЕРЯЕТСЯ". В окамле (a + b) — b = a, но в общем случае (a +. b) -. b <> a. Если же это не нужно, и похуй, во что там отрезолвится "-" — брать pa_do либо Float.(a — b) либо let open Float in a + b / c. В чом проблемы?
До синтаксиса доебываться нужно, но не так, как вокер. Вот меня проеб end’ов в ruby уже просто доебал, я не могу на нем больше программировать. Один проеб охуительнее другого, блять. Синтакс еррор, ошибка в конце тысячестрочного файла. Чего, блять? Где искать? Вообще охуеть.
Тхесз на последнем MskHUG рассказывал, как он нахуярил Map’ов на простых интах на x86_64, и все тормозит GC. А потом он переделал все на int32, и все перестало тормозить. Я успокоил себя тем, что чего-то не понимаю.
потому что в окамле функция это функция, а не хуйня, требующая "словаря", rtti и прочего. Функция также связана с конкретным куском кода в программе, типы же стираются. Это полезно для производительности. Кроме того, выведи-ка тип выражения "fun x y → x + y".
Пиздец, посоны, я хую с вас, стоило сказать, что какой-то там язык обсирают, так все, пиздец, сразу онлаен-дискуссия, кококо, интерес. Нахуй так жить? Выйдите на улице уже!
тем, что интерфейсы — это не тайпклассы. А именно: 1. если есть конкретные функция/модуль/объект с конкретным интерфейсом, всегда известно, где смотреть его реализацию. В случае тайпклассов — не всегда известно, так как какой-нибудь левый модуль может переопределять инстанс. 2. тайпклассы не позволяют стирание типов: при их использовании от типов в общем случае остаётся "довесок" — рантайм-часть, соответствующая сигнатуре "(Num A)" (словарь штоле). Код получается медленнее как из-за косвенного вызова, так и из-за хранения-передачи дополнительного аргумента (словаря). 3. идея "щас по типу достанем значение" — сама по себе кривая, но почему-то продолжают лепить newtype, чтобы внезапно типы стали разными, чтобы подставить разные инстансы. Костыли.
1. Че7 2. СКОРАСТЬ! 3. Как давно х-ь разобрался с разными тайпклассами для строк vs списков символов? Раньше же была пичалька — если [Char], то брался тайпкласс для списков (то ли наоборот, для строк), но точно какой-то один. Да и вообще, вопорос "Че?" тут — как бы характерный. Уж я насколько не х-ист, а это знаю...
1. очень просто. Как минимум — заверну в другой модуль/объект и выставлю наружу то, что надо. В некоторых случаях достаточно ограничить интерфейс либо просто дописать в него что-то, это ещё проще. 2. хочешь ПИРИГУЗКИ АПИРАТАРОВ — пиздуй в C++. 3. это проблемы тайпклассов, вызвавшие проблемы реализации тайпклассов. NEWTYPE ОКОКОК.
1. зато отсутствие "перегрузки" и ВНЕЗАПНОГО переопределения. 2. 3. понятное дело, что если реализовывать кривые концепции, то проблемы реализации будут.
а дело не только в static (я вон для личных нужд вполне dynamic использую изредка), а в выразительности типов, в некоторых "минимальных гарантиях", которых динамикой добиться сложно всяко.
66 comments
recommend
bookmark
subscribe
все правильно написал
Блядь.
O RLY777
Типичный вокероаргумент: #tfinhe
ок!
Мне вообще было бы незападло рассказать, если "в коня корм", а не "бисер перед".
расскажи мне, как -. удобнее тайпклассов
Ну вокер считает, что язык должен быть ЧИСТЫМ, причем ЧИСТОТА обратно пропорциональна количеству букв, которое приходится набирать.
Олсо, рекомендую ему попробовать k.
проприетарная параша какая-то
Тогда j.
поднасрал ему в цоменты.
рассказываю. Удобство тут в том, что потом не приходится чесать репу и думать "КОКОКОВА ХУЯ ТОЧНОСТЬ ТЕРЯЕТСЯ". В окамле (a + b) — b = a, но в общем случае (a +. b) -. b <> a.
Если же это не нужно, и похуй, во что там отрезолвится "-" — брать pa_do либо Float.(a — b) либо let open Float in a + b / c.
В чом проблемы?
До синтаксиса доебываться нужно, но не так, как вокер.
Вот меня проеб end’ов в ruby уже просто доебал, я не могу на нем больше программировать. Один проеб охуительнее другого, блять. Синтакс еррор, ошибка в конце тысячестрочного файла. Чего, блять? Где искать? Вообще охуеть.
грамотно.
> let open Float in a + b / c.
чо
http://paste.in.ua/7862/
Тхесз на последнем MskHUG рассказывал, как он нахуярил Map’ов на простых интах на x86_64, и все тормозит GC. А потом он переделал все на int32, и все перестало тормозить. Я успокоил себя тем, что чего-то не понимаю.
а с интами будет работать?
не догнал мыслю.
Нуоще.
напиши соответствующий модуль Int и будет. Вплоть до Float.(12.34 + of_int Int.(12 + 34)).
Че? я могу получить функцию + которая будет работать и с int и c float?
А, блять, он там просто про ограниченность массивов говорит. Да так, ничего.
Я думал, что он на проеб одного бита в интах жалуется.
нет. Это значения разных типов, и "+" у них принципиально разный. см. /12
если программист не знает про специфику флоатов, то он долбоеб. почему разрабам нельзя было просто перегрузить арифметику для флотов?
значит так как с тайпклассами нельзя сделать. или, может, ПРЕПРОЦЕССОРОМ
ОБЪЕКТЫ ЗНАЕШ
потому что в окамле функция это функция, а не хуйня, требующая "словаря", rtti и прочего.
Функция также связана с конкретным куском кода в программе, типы же стираются. Это полезно для производительности.
Кроме того, выведи-ка тип выражения "fun x y → x + y".
"так, как с тайпклассами" и не нужно делать. Мне они не нравятся.
(Num A) => A → A → A — :cf
неужто в окмале нет экзистенциалов, такое не заработает?
тайпклассы ненужны.
а ИНТЕРФЕЙСЫ?
заработает конечно. Только нахуй нужно.
интерфейсы чего именно?
как это нахуй. ничего общего между целочисленным и флоатовым сложением не находишь?
http://en.wikipedia.org/wiki/Interface_(...
ничего. Типы данных разные, семантика разная, reasoning про сложение тоже разный (из разной семантики вытекает).
эти — нужны и обязательны, ящитаю.
а чем они отличаются от тайпклассов?
Пиздец, посоны, я хую с вас, стоило сказать, что какой-то там язык обсирают, так все, пиздец, сразу онлаен-дискуссия, кококо, интерес. Нахуй так жить? Выйдите на улице уже!
А там языки обсирают?
Нет, просто вспомнил про #tfgeif/52
ну дык, и я тоже
тем, что интерфейсы — это не тайпклассы. А именно:
1. если есть конкретные функция/модуль/объект с конкретным интерфейсом, всегда известно, где смотреть его реализацию. В случае тайпклассов — не всегда известно, так как какой-нибудь левый модуль может переопределять инстанс.
2. тайпклассы не позволяют стирание типов: при их использовании от типов в общем случае остаётся "довесок" — рантайм-часть, соответствующая сигнатуре "(Num A)" (словарь штоле). Код получается медленнее как из-за косвенного вызова, так и из-за хранения-передачи дополнительного аргумента (словаря).
3. идея "щас по типу достанем значение" — сама по себе кривая, но почему-то продолжают лепить newtype, чтобы внезапно типы стали разными, чтобы подставить разные инстансы. Костыли.
ОБОСРИТЕ МНЕ ЯЗЫК
1. Зато невозможно определить интерфейс для уже определенного модуля. Это важнее.
2. СКОРАСТЬ
3. Че?
1. Че7
2. СКОРАСТЬ!
3. Как давно х-ь разобрался с разными тайпклассами для строк vs списков символов? Раньше же была пичалька — если [Char], то брался тайпкласс для списков (то ли наоборот, для строк), но точно какой-то один. Да и вообще, вопорос "Че?" тут — как бы характерный. Уж я насколько не х-ист, а это знаю...
Похапе говно, ну.
мой язык до сих пор чист, как и ротовая полость. Спробуй ще!
1. Как ты определишь свой собственный интерфейс для других объектов?
2. Хочешь СКОРАСТИ — пиздуй на Си.
3. Это проблемы реализации.
2. Анус себе попиздуй.
1. очень просто. Как минимум — заверну в другой модуль/объект и выставлю наружу то, что надо. В некоторых случаях достаточно ограничить интерфейс либо просто дописать в него что-то, это ещё проще.
2. хочешь ПИРИГУЗКИ АПИРАТАРОВ — пиздуй в C++.
3. это проблемы тайпклассов, вызвавшие проблемы реализации тайпклассов. NEWTYPE ОКОКОК.
1. К0СTbIЛN
2. Я пиздую в руби.
3. Понятное дело, что если нихуя не реализовать то и проблем реализации не будет.
2. С десятью RPS’ами на 6 инстансах, ага. И с undefined method `huipizda' for nil:NilClass на продакшн-сайте.
ничего не поделаешь, зато не надо лишние кавычки писать!
Вокеровыбор языка.
язык, как и залупа, должен быть красив.
ВО ПЕРВЫХ СИМВОЛЫ ЭТО ПРОСТО КРАСИВО
1. зато отсутствие "перегрузки" и ВНЕЗАПНОГО переопределения.
2.
3. понятное дело, что если реализовывать кривые концепции, то проблемы реализации будут.
красивой залупе — красивый язык!
какамль хорош уже тем, что на нем можно набыдлить код, который будет работать со скоростью си.
2. Блядь, до слез.
всяко чуть медленнее, но мы любим его не только за это.
static typing is false sense of security!
а дело не только в static (я вон для личных нужд вполне dynamic использую изредка), а в выразительности типов, в некоторых "минимальных гарантиях", которых динамикой добиться сложно всяко.