[C++?] Серьезный вопрос.

>http://rebol.ru/

ндя. спортачился сайт :(

> В винде проблемы с исключениями нет. Там даже при разыменовании нуллпоинтера кидается SEH-исключение.

Пора бы уже понять, что SEH -- это ни коим боком не C++.

>> В винде проблемы с исключениями нет. Там даже при разыменовании нуллпоинтера кидается SEH-исключение.

>Пора бы уже понять, что SEH -- это ни коим боком не C++.

Речь по моему шла о том что если платформа - MSVC, то смысла запрещать исключения нет никакого. В винде даже ведро с исключениями. MFC и ATL и не запрещают.

> А в стандарте хаскеля говорится *точно*, что должна печатать на консоль head [] ? Если не говорится, то тогда разные реализации хаскеля могут печатать разное, и хаскель надо признать опасным языком, как и С.

Это уже пошла софистика. Какая практическая ценность стандартизации сообщений об ошибках с точностью до буквы?

> Речь по моему шла о том что если платформа - MSVC, то смысла запрещать исключения нет никакого. В винде даже ведро с исключениями. MFC и ATL и не запрещают.

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

> если принять, что выразительность кода - это количество символов в программе, то это очень выразительный язык. но фак мой мозг! как это читать??!

s/символов/лексем/

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

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

>Какая практическая ценность стандартизации сообщений об ошибках с точностью до буквы?

на форуме об этом потроллить можно. иной пользы, в общем-то, нет

>на форуме об этом потроллить можно. иной пользы, в общем-то, нет

Кстати, это утверждение в полной мере применима к такой изотерике, как хаскель и окамль.

Сильно вряд ли.

>Кстати, это утверждение в полной мере применима к такой изотерике, как хаскель и окамль.

ваше мнение очень важно для нас

>>Сильно вряд ли.

>ваше мнение очень важно для нас

fixed

>Кстати, это утверждение в полной мере применима к такой изотерике, как хаскель и окамль.

Утверждение применимА? _И_зотерика? Граммар наци негодуэ.. х_Х

Конечно, когда больше нечего сказать, начинают придираться к опечаткам. Тебе ведь нечего сказать, не правда ли?

Давайте не будем лукавить... слово "изотерика" прозвучало в этом треде n-дцать раз

Да. Нужно минусануть anonimus_naxа=)

> Конечно, когда больше нечего сказать, начинают придираться к опечаткам. Тебе ведь нечего сказать, не правда ли?

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

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

Исходя из ваших утверждений Эйнштейн вообще был пришибленным на всю голову.

> Исходя из ваших утверждений Эйнштейн вообще был пришибленным на всю голову.

Энштейн плохо учился в школе, в основном, потому что не любил зубрёжку и спорил с учителями.

>Энштейн плохо учился в школе, в основном, потому что не любил зубрёжку и спорил с учителями.

А еще он не знал С++.

> Энштейн плохо учился в школе, в основном, потому что не любил зубрёжку и спорил с учителями.

Почему linuxfan не мог поступать точно так же?

> А еще он не знал С++.

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

>> А еще он не знал С++.

>Т.е. плюсофобия ему, в отличии от вас, не мешала адекватно воспринимать жизнь.

Как раз адекватное восприятие жизни не вяжется с плюсофилией. С унылым прагматизмом вида "да говно, но поделать ничего нельзя" вяжется, но с плюсофилией - не может, т.к в ++ все решения кроме совместимости с С полностью перепендикулярны реальной жизни.

> т.к в ++ все решения кроме совместимости с С полностью перепендикулярны реальной жизни.

Что и позволило плюсам стать одним из самых восстребованных языков программирования. Так и запишем: "Перпендикулярность реальной жизни -- залог востребованности и успешности. Доказано Абсурдом".

>> т.к в ++ все решения кроме совместимости с С полностью перепендикулярны реальной жизни.

>Что и позволило плюсам стать одним из самых восстребованных языков программирования.

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

> Статическое ООП не работает например, так как формализовать код можно только по факту наличия кода задним числом.

Это полный 3.14здец! Читать http://www.bolero.ru/books/9785750202553.html до просветления.

>> Статическое ООП не работает например, так как формализовать код можно только по факту наличия кода задним числом.

>Это полный 3.14здец!

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

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

Ну что тут остается сказать... Выражение "Смотришь в книгу, а видишь фигу" явно не на пустом месте появилось.

Как из книги Буча могло получиться, что статическое ООП не работает? Если мне не изменяет склероз, во втором издании вообще все примеры только на C++ приводятся.

>Как из книги Буча могло получиться, что статическое ООП не работает?

Ну наверное надо еще критически осмысливать прочитанное. Чтобы что-то уметь делать надо это сделать. Для кода одного акта написания достаточно. Таким образом умение произвести декомпозицию данной конкретной задачи в терминах ОО всегда происходит постфактум. Остается только писать по возможности аккуратно и самодокументируемо, а интерфейсы взаимодействия с внешним кодом делать простыми и интуитивно понятными, с проверкой данных получаемых от стороннего кода конечно. ++ конечно добавит палки в колеса на всех пунктах этих простых правил, так что умение писать на ++ это умение писать не благодаря, а вопреки.

> Ну наверное надо еще критически осмысливать прочитанное...Таким образом умение произвести декомпозицию данной конкретной задачи в терминах ОО всегда происходит постфактум....

Понятно, вместо вдумчивого прочтения было критическое осмысливание. И вы вынесли из книги что-то свое, но вовсе не то, что туда закладывал Буч.

Тоже самое у вас наблюдается и по отношению к C++.

> Понятно, вместо вдумчивого прочтения было критическое осмысливание. И вы вынесли из книги что-то свое, но вовсе не то, что туда закладывал Буч.

Нет парадигмы, кроме ООП и Буча -- пророка её. Аминь.

> вместо прочтения было осмысливание

так ведь это же хорошо

> Нет парадигмы, кроме ООП и Буча -- пророка её. Аминь.

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

> так хорошо

не хорошо из цитат значимые слова выбрасывать, не правда ли?

>Наличие большого количества ошибок в тексте говорит о том, что субъект плохо учился в школе

Школу окончил с золотой медлью. Такие дела.

>И что в функциональном программировании никогда не бывает так, что более лучшее решение находится уже после получения работающего результата?

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

>++ конечно добавит палки в колеса на всех пунктах этих простых правил, так что умение писать на ++ это умение писать не благодаря, а вопреки.

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

>Школу окончил с золотой медлью. Такие дела.

Это много о тебе говорит. И в комбинации с твоим унылым троллингом, только плохое.

>Практика показывает

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

>высокоуровневые абстракции крайне хреново ложатся на тупые современные вычислители

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

>для функциональной декомпозиции мозги включать не нужно?

нужно. но при чём тут Буч - непонятно

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

бывает. и как раз тут чистота очень способствует рефакторингу, ибо любой чистый модуль/функцию можно рефакторить в полном отрыве от всего остального проекта. low coupling, доведённый до предела - это ли не счастье?

>Кстати, это утверждение в полной мере применима к такой изотерике, как хаскель и окамль.

http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-...

SPJ в рассылку подкинул чудесное. enjoy!

> >для функциональной декомпозиции мозги включать не нужно?

> нужно. но при чём тут Буч - непонятно

А то, что Буч рассказывает, как можно проектировать с использованием ООП. Если после его рассказов оказывается, что "статическое ООП не работает", то это полный приплыздец.

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

Рефакторинг здесь очень косвенно.

> low coupling, доведённый до предела - это ли не счастье?

И по поводу low coupling-а сильно сомневаюсь, и по поводу чистоты соменеваюсь. Нет больших работающих систем на чисто функциональных языках. Нет. Есть только на Erlang-е (ну еще и на Lisp-ах с OCaml-ом что-то), только вот не чистые это языки. Причем специально не чистые.

Так что расскажите про достоинства ФП ученым-языковедам. А если 99% назначения программы -- это производство побочных эффектов, то чистота идет лесом.

>если 99% назначения программы -- это производство побочных эффектов

то это плохая программа :)

> то это плохая программа :)

Ну, лучшая программа -- это не написанная программа.

>ибо высокоуровневые абстракции крайне хреново ложатся на тупые современные вычислители.

Опять двадцать пять. На лиспе и вероятно в D можно написать макрос вида (affine-transform (x y z 1) (scale s s s) (move a b c) (rotate phi ro theta)) который разворачивается в одну большую простыню без циклов и вызовов функций, а на С++ - нет т.к циклы не инлайнятся.

>если 99% назначения программы -- это производство побочных эффектов -- то это плохая программа :)

Алекс Степанов вначале пытался написать STL функциональненько на scheme, а у Martin Odersky перед Scala был Funnel (a programming language for functional nets).

Потом оба поумнели.

> Опять двадцать пять. На лиспе и вероятно в D можно написать макрос вида (affine-transform (x y z 1) (scale s s s) (move a b c) (rotate phi ro theta)) который разворачивается в одну большую простыню без циклов и вызовов функций, а на С++ - нет т.к циклы не инлайнятся.

Ы?!

откуда дровишки, особенно насчет for(i=0; i<3; i++) ?

________________________

частично применять функции должен компилятор (ну или суперкомпилятор), делать же это вместо него руками (и макросами) -- это мазохизм и источник багов.

>Алекс Степанов вначале пытался написать STL функциональненько на scheme

Очень интересно наверное пытаться написать for_each на схеме (у меня дежавю...)

> дык абстракции они на то и абстракции - от нижнего уровня до верхнего, избегая утечек. ищем низкоуровневые, которые ложатся хорошо, а уж поверх них строим те, что повыше. профит!

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

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