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

T>>http://thesz.livejournal.com/509595.html
G>Не надо доказывать что любую программу можно написать плохо. Это очевидно.

Но ведь хочется, чтобы плохую программу написать было тяжело, верно?

L>>>>5) энергичные
G>>>Лучше энергичность по-умолчанию, чем ленивость.
T>>Это контрпродуктивно с точки зрения программиста. Ниже модульность.
G>Как ленивость связана с модульностью?

Нет кучи имплементаций.

T>>http://thesz.livejournal.com/906786.html
G>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.

IEnumerable<T> — интерфейс. У него может быть много реализаций. Одна реализация ленивого мапа на месте может быть преобразована в энергичный. Наоборот — нет — везде надо будет явно thunk-и объявлять.

G>ИМХО для не-списков ленивость поумолчанию не нужна.

Это потому что тебе показали только ленивые списки.

L>>На Немерле удобнее писать ФП код?
Q>Пока что я прихожу к выводу, что на Nemerle удобнее писать код вообще. В том числе и функциональный, и объектно-ориентированный, и мета.

"Необходимость в метапрограммировании означает необходимость в языке более высокого уровня" Фред Брукс, "Мифический человеко-месяц", второе издание.

Из чего мы напрямую выводим, что Nemerle низкоуровневый язык.

L>>Не плохое. Менее ФП-шное.
Q>Лишь бы удобное и не сковывало. А менее труЪ оно, или более — вопрос философский и второстепенный.

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

Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная.

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

L>Оффтопик: на Java сложно писать без IDE, на Haskell — просто. Как причина отсутствия IDE a la IDEA для Haskell пойдёт?

L>Хотя — многое из того, что есть в IDEA и полезное для Haskell есть в том же Emacs haskell-mode. Или в vim.

Смысл не в том, нужна ли IDE для Haskell и будет ли она продаваться, так же хорошо, как Intellij IDEA. А в том, почему бы IDE для Java (ту же IDEA) не разрабатывать на Haskell, раз уж ФП вообще, и Haskell в частности, самое лучшее из того, что есть сейчас

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

Q>Пока что я прихожу к выводу, что на Nemerle удобнее писать код вообще. В том числе и функциональный, и объектно-ориентированный, и мета.

Я пришел к такому же выводу для Ocaml'а. И есть очень большое подозрение что Хаскель для функциональнальщины еще удобнее.

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

T>Другие примеры не подойдут? Только IDEA?

Ну, IDEA весьма показательна. Я тут пару лет назад поднимал тему о том, что IDE для языка программирования, написанная на нем самом, является хорошим примером универсальности языка
Но можно еще взять что-нибудь типа Web-браузеров, текстовых процессоров, CAD-систем (т.е. вещей, в которых ООП хорошо себя чувствует).

T>Galois, Inc не подойдёт?

А это чем-то круче SPARKAda? SPARK Ada, конечно, VSDL не генерирует, но подлежащие верификации программы с ее помощью разрабатывают.

Bluespec?

Понятия не имею, это для меня слишком специфический продукт.

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

T>Из чего мы напрямую выводим, что Nemerle низкоуровневый язык. ;)

Отлично. Хоть ассемблером его назови, менее удобным он не станет.

Q>>Лишь бы удобное и не сковывало. А менее труЪ оно, или более — вопрос философский и второстепенный.

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

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

T>Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная. ;)

И к сорока годам остеопороз с остеохондрозом.

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

T>"Необходимость в метапрограммировании означает необходимость в языке более высокого уровня" Фред Брукс, "Мифический человеко-месяц", второе издание.

О! Золотые слова! Тут, кстати, уже проскальзывала эта тема.
Называется "Являются ли макросы свидетельством недостаточной выр". Да, именно так, выр.

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

FR>Я пришел к такому же выводу для Ocaml'а.

OCaml тоже неплохой язык.

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

L>Разве тут нельзя опустить строчку mailslot_.sendStateNotify();, чтобы по прежнему программа компилировалась?

Я думаю, что и в Haskell-е при желании, можно будет сделать, чтобы queryState ничего не делал, но возвращал значение нужного типа

L>Может проблема в том, что мы говорим на разных языках?

Имхо, это уже давно очевидно.
Собственно, как и то, что ОО языки и ФП языки применяют разные люди в совершенно разных условиях. И, может быть, thesz здесь единственный, кому за Haskell деньги платят.

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

E>Смысл не в том, нужна ли IDE для Haskell и будет ли она продаваться, так же хорошо, как Intellij IDEA. А в том, почему бы IDE для Java (ту же IDEA) не разрабатывать на Haskell, раз уж ФП вообще, и Haskell в частности, самое лучшее из того, что есть сейчас

Не, Ява — лучшее! Поэтому этот продукт и написан на ней.

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

FR>Я пришел к такому же выводу для Ocaml'а. И есть очень большое подозрение что Хаскель для функциональнальщины еще удобнее.

Ух-ты!

T>>Другие примеры не подойдут? Только IDEA?
E>Ну, IDEA весьма показательна. Я тут пару лет назад поднимал тему о том, что IDE для языка программирования, написанная на нем самом, является хорошим примером универсальности языка

Java, AFAIK, это 1995+-1. IntelliJ IDEA — январь 2001. Время разработки не указано.

Ну, хрен его знает. Я думаю, что всё, входящее в первую версию IDEA, можно написать за считанные месяцы.

Разбор Java — месяц. Типизация — полмесяца. Редактор с подсветкой — месяц. Рефакторинги первой версии — месяц.

(тут меня посетила мысль — а деревянная структура проекта — это правильно ли?.. но поскольку это оффтопик, я её развивать не буду)

E>Но можно еще взять что-нибудь типа Web-браузеров, текстовых процессоров, CAD-систем (т.е. вещей, в которых ООП хорошо себя чувствует).

Точнее, куда вложили кучу времени разработчиков. Кстати, Bluespec — это CAD, своего рода. HDL.

T>>Galois, Inc не подойдёт?
E>А это чем-то круче SPARKAda? SPARK Ada, конечно, VSDL не генерирует, но подлежащие верификации программы с ее помощью разрабатывают.

У них много, чего есть. Cryptol только часть.

E>Bluespec?
E>Понятия не имею, это для меня слишком специфический продукт.

На ООП такого нет вообще.

L>>Хотя — многое из того, что есть в IDEA и полезное для Haskell есть в том же Emacs haskell-mode. Или в vim.
E>Смысл не в том, нужна ли IDE для Haskell и будет ли она продаваться, так же хорошо, как Intellij IDEA. А в том, почему бы IDE для Java (ту же IDEA) не разрабатывать на Haskell, раз уж ФП вообще, и Haskell в частности, самое лучшее из того, что есть сейчас

Инерция разработчиков, объём кода.

IDEA разрабатывают те же товарищи, что и MPS.

По результату дискуссии в (моём) ЖЖ могу передать, что когда разработчикам MPS намекнули про OCaml, то они ответствовали, что смотрели, но не смогли быстро нарисовать окошко на экране, и поэтому забросили.

По-моему, это говорит о многом.

(это я отвечал на вопрос "почему IntelliJ IDEA, скорее всего, никогда не будет на Хаскеле".)

T>>Из чего мы напрямую выводим, что Nemerle низкоуровневый язык.
Q>Отлично. Хоть ассемблером его назови, менее удобным он не станет.

И более удобным тем паче.

Q>>>Лишь бы удобное и не сковывало. А менее труЪ оно, или более — вопрос философский и второстепенный.
T>>Первое время приседать со стокилограммовой штангой очень неудобно и сковывает, ага.
Q>Я уже со счёта сбился, сколько раз за последнюю неделю встречал твою штангу по разнообразнейшим поводам.

Люблю, потому, что

А ещё у меня, как у целостной натуры, всё друг с другом связано.

T>>Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная.
Q>И к сорока годам остеопороз с остеохондрозом.

Так надо заниматься в 35+, когда тестостерон из пор кожи бьёт и все уже укрепилось.

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

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

E>Я думаю, что и в Haskell-е при желании, можно будет сделать, чтобы queryState ничего не делал, но возвращал значение нужного типа

Можно написать так, чтобы это было невозможно. Представь, что у тебя mailslot_.sendStateNotify() возвращает тип NonchangeableMailslotUsedSignal, а больше никак ты его создать не можешь в принципе. Это очень упрощённая схема, учти ещё, что можно сделать так, чтобы использовался только наш mailslot_ и что в функции только одно выражение (это же ФП)! Так мы получаем, что мы можем поиметь только одну реализацию этой функции.

Ограничения могут быть достаточно сложными. См. как пример Monad/ST
Вкратце, нельзя создать ST-ссылку в одном блоке, а использовать в другом. Это ограничено типом.

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

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

L>Представь, что у тебя mailslot_.sendStateNotify() возвращает тип NonchangeableMailslotUsedSignal, а больше никак ты его создать не можешь в принципе.

Ну как раз из-за того, что тип Mailslot "чужой" и не может подвергаться изменениям, мне и понадобился NonchangeableMailslotHolder, который и возвращает NonchangeableMailslotUsedSignal. А больше никак этот Signal получить нельзя.

L>Это очень упрощённая схема, учти ещё, что можно сделать так, чтобы использовался только наш mailslot_ и что в функции только одно выражение (это же ФП)!

А вот можно эту тему развить (только на пальцах, примеры на Haskell-е для меня как китайский язык)? Буду очень признателен. Особенно про то, как разделять отдельные mailslot-ы в программе.

L>>Может проблема в том, что мы говорим на разных языках?
E>Имхо, это уже давно очевидно.
E>Собственно, как и то, что ОО языки и ФП языки применяют разные люди в совершенно разных условиях. И, может быть, thesz здесь единственный, кому за Haskell деньги платят.

Здесь — да.

А в на моей прежней работе за него платили деньги, по-моему, 4-м человекам точно.

T>>"Необходимость в метапрограммировании означает необходимость в языке более высокого уровня" Фред Брукс, "Мифический человеко-месяц", второе издание.
L>О! Золотые слова! Тут, кстати, уже проскальзывала эта тема.
L>Называется "Являются ли макросы свидетельством недостаточной выр". Да, именно так, выр.

По-моему, макросы являются свидетельством излишней выр.

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

T>Энергичность по умолчанию предпочитают из-за производительности.

ЧСХ, ленивость по умолчанию многие тоже предпочитают из-за производительности. Дескать, она даёт возможность избежать ненужных вычислений.

T>Никаких других плюсов энергичность по умолчанию не даёт.

Даёт лучшую предсказуемость поведения (вспомни свои утечки невычисленных цепочек). (NB: Вот только не надо здесь поминать корень всех зол!)

T>В противном случае ты бы мыслил по-другому.

Т. е. не как прагматик, а как фанатик?

T>Выразительность, простота создания DS(E)L, модульность, строгая и мощная система типов.

И что, в этом плане Haskell впереди планеты всей, на два корпуса обгоняя F# и Nemerle? Нет убедительных оснований так считать.

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

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

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

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

T>>>http://thesz.livejournal.com/509595.html
G>>Не надо доказывать что любую программу можно написать плохо. Это очевидно.

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

L>>>>>5) энергичные
G>>>>Лучше энергичность по-умолчанию, чем ленивость.
T>>>Это контрпродуктивно с точки зрения программиста. Ниже модульность.
G>>Как ленивость связана с модульностью?
L>Нет кучи имплементаций.
Ну для этого существует много других способов, в том числе обобщенное программирование (generics и автоматическая генерализация как в F#).

G>>ИМХО для не-списков ленивость поумолчанию не нужна.
L>Это потому что тебе показали только ленивые списки.
Ну так покажите пример ленивости по-умолчанию без списков, где в ней реально есть смысл.
Причем пример не надуманный.