Здравствуйте, Andrei N.Sobchuck, Вы писали:
WH>>Особенно мне интересно что ты будешь делать с подобными выкрутасами:
ANS>Аналог именно этого не потребует даже визитора!
Папа мне любил говаривать в детстве — "Трепачь — находка для шпионов.". Похоже я теперь понял о ком он говорил.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Потребует 1-го (одного) виртуального метода под названием prettyPrint принимающего 1 (один) параметр — поток вывода и классы в количестве соответсвующем количеству матчей. Или тебя пугает необходимость создавать классы в ОО программе?
Охриниельное решение. Ты мега-крут!
Если серьезно, то попробуй все же изучить что такое паттерн-матчинг. Думаю после этого ты подобную глупость уже не скажешь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ты прикидывашся или действительно не понимаешь что это сотая того кода который тебе надо наколбасить чтобы воспроизвести то что привел Вольфхануд?
Паттерны приведенные Вольфхаундом разбирают конкретные случае сочетания веток АСТ и форматируют вывод в зависимости от этого. Ты же привел примитивнейший случай в котором всегда один параметр и пофику какой метод. Параметров же может быть ноль, один, два... двадцать пять. Метод может быть констуктором или еще чем-то. В коде Вольфхаунда это анализируется. Только вместо кучи if-ов есть один паттерн.
В этом и сила паттерн-матчинга. Он позволяет декларативно отобразить то, что на языках без паттерн-матчинга тербует написания тучи императивного кода с проверками и выборами.
Так что твой любимый Смолток ничем не отличается от C#. Кон на нем всгде будет длинее по сравнению с аналогичным написанным на языке с паттерн-матчингом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ANS>Тут таже фигня, что я говорил раньше — в ОО программе никто не будет совать кучу параметров в масив, а потом выковыривать из него параметры кучей if-ов и switch-ей. (И я не понимаю, почему адепты Nemerle считают это обычной практикой в C#).
Ты не трепись по чем заря. Ты просто тупо напиши аналогичный код и увидишь, что он в разы длинее и запутаннее. А то твои расуждения выглядят как попытка уйти от ответа.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>В лиспе не было вывода типов, ленивости, паттерн матчинга в общем очень многого из того что появилось в новых функциональных языках.
VD>Оно появлялось паралельно с развитием Лиспа и сегодня все это есть в различных его диалектоах.
Только по моему часто сначала появлялось на других языках
FR>>Да и вообще лисп не чистый функциональный язык.
VD>Чистых на 100% вообще быть не может. Так как это сфероконь вакумный. Кому нужен язык не умеющий общаться с внешним миром? А такое общение — это побочный эффкт.
Ну хаскель притендует
VD>Фнукционаьный язык — это не язык где нет изменения переменных, а язык позволяющий удобно и продуктивно писать в функцональном стиле.
Здравствуйте, eao197, Вы писали:
E>Идея писать код без учета т.н. exception safety не менее ущербна.
У меня с этим проблем нет.
E>Именно поэтому писать exception safety код очень сложно и этим часто пренебрегают. Или даже не догадываются о том, что написанный код не является exception safety.
Говори за себя — "Мне на С++ писать exception safety код очень сложно...".
VD>>К тому же закладываться или не закладываться здесь в общем-то не так важно. Важно другое. Важно, что ты уже не можешь читая код делать предположение о его последовательности. Так читая код на C# я могу быть уверненым, что длинное выражение что бы не вычилсялось всегда попадет в переменную, если оно стоит с права от присонения ей значения. И я всегда уверен, что управление из этого вражения перейдет на следующую строку, а не убежит черти куда.
E>Такие рассуждения еще можно применять к C (и то без учета всяких longjmp-ов) или к Виртовскому Паскалю.
Ерунду говоришь. У тебя очень неврено мнение о том что такое исключения и зачем они нужны. Исключения придуманы для того чтобы писать программу так как будто их вообще не существует. А уж они нужны чтобы можно было если программа попала в состояние в котором не может продолжать корректную работу можн было бы или завершить программу или привести ее в рабочее состояние.
Если подходить к ислючениям так, то они никогда не нарушают вычислительную модель, а является благом. Если же их рассматривать как средство неструктурной передачи управления, то конечно твоя жизнь будет очень сложна, и я бы даже сказал, мрачна.
E> Но вот по отношению к современным языкам, в которых бросание исключений является основным способом информирования о любых ошибках, такие рассуждения звучат, по меньшей мере, наивно.
Твое заблуждение заключается в том, что ты считаешь исключения "способом информирования об ошибках". А это не так. Ислючение не информирует. Оно просто живет в другом измерении. Это средство востановиться или умереть, а не информировать кого-то.
E>Для разминки, уверен ли ты, что переменная dataRows всегда получит причитающееся ей значение в таком примере: E>
Уверен. Хотя код конечно бредовый.
E>А теперь представь, что makeDataSpecificExtension это блок в SmallTalk или Ruby.
Тогда не уверен.
E> Выполненый из него return прерывает данное выражение точно так же, как и выброшенное где-нибудь в load() исключение.
Не не так же. В логике моей программы нет нарушения структурности. А исключение это ИСКЛЮЧИТЕЛЬНАЯ СИТУАЦИЯ которая не вписывается в логику моей программы. Ты же нахватался модных слов вроде "exception safety" вложив в них совершенно иной смысл. Так что ищи проблему не в исключениях, а в твоем их восприятии.
E> Поэтому, если использующий блоки кода фрагмент написан в соответствии с принципами exception safety, то ему безразлично, был ли он прерван исключением или нелокальным return-ом.
Нда. Код написанный в стиле реализации ветвления на исключениях является кошмаром. И я вам желаю от чистого сердца с ним никогда не связываться. А Смолтокерам выражаю свои искренние соболезнования. Они не только используют скрипт прошлого поколения, но еще и вынуждены жить в мире коде корректно выражение в соврешенно нормальных условиях может никогда не вернуть результат. Для меня это приговор языку. Но если кому-то нравятся экстравогантности, то ради бога.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
VD>>Оно появлялось паралельно с развитием Лиспа и сегодня все это есть в различных его диалектоах.
FR>Только по моему часто сначала появлялось на других языках
Ошибашся. Я как-то читал, что эксперемены по паттерн-матчингу были за долго до МЛ-я.
FR>Ну хаскель притендует
На место в кунскамере?
VD>>Фнукционаьный язык — это не язык где нет изменения переменных, а язык позволяющий удобно и продуктивно писать в функцональном стиле.
FR>
А что ты улыбашся? Это между прочим общепринятое определение. И те же ML-языки только ему и удовлетворяют.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Beam, Вы писали:
VD>>Ага. Ужасно неудобно. Потому в C# и Nemerle это делается очень редко. Вместо этого используется using. Знаком с такой конкцепцией?
B>Знаком. Синтаксический сахар.
Ага. Он самый. У меня в коде он встречается постоянно. А вот try-finally почти отсуствует.
B>Да я же говорю про другие грабли
Какие?
B> Пока что Вы избегаете давать ответ на мой вопрос.
Ты бы вопрос что-ли сформулировал. А то ощущение, что ты просто не понимашь о чем говоришь. Ты говоришь о макросах как о функциях, что бессмыселнно.
B> Посмотрите предыдущие посты. Вы пытаетесь уйти в сторону от обсуждения проблемы. Давайте не будем говорить о частностях. Смотрите шире.
Я просто понимаю о чем говорю. Ты же похоже — нет.
B>
B>Пусть у нас есть макрос, с параметром body (код). И пусть этот параметр используется в середине макроса. Т.е. при развертывании макроса получится код:
B>
B> // выполняем какой-то код 1
B> // здесь будет код $body
B> // выполняем какой-то код 2
B>
B>Если передать в этот макрос код, внутри которого есть return , то код 2 выполнен не будет.
Написать:
def a = { if (x) 1 else return 0; };
в Немерле, как и в любом другом более менее продуманном современном языке невозможно физически.
return не доступен внутри выражений. Он может быть только там где управление можно прервать. Другими словами return — это statment, а не expression (если тебе что-то говорят эти слова). И return не может передать управление черти куда. Только выйти из текущей функции. Вот это назвается соотвествовать правилам структурного программирования.
И самое забавное. Пока ты тут отстаиваешь славные традиции сишного нелокального goto в том самом Немреле вообще можно обходиться без return. Оператор return в нем эмулируется. И реально используется очень редко.
Вот такие вот тенденции. А вы тут стройными рядами идете к давно процденым граблям. Неужели лоб не жалко?
B>Разве не эту проблему Вы увидели в блоках Smalltalk? Пока что я не услышал вразумительного ответа — все вокруг да около.
Пока что ты так привык к граблям, что считашь их нормой. Разубедить тебя нельзя. Это вера. Если тебе действительно интересен ответ, то напрягись и прочти хоть что-то по принципам структурного программирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Klapaucius, Вы писали:
K>Вот это мне, как раз, не очень нравится, хотя почему такую возможность оставили я понимаю.
Дык людям же нужно привыкнуть! Иначе они могут бросить язык раньше чем разбирутся в нем и смогут оценить отсуствие возможности попрыгать.
K>Непонятно мне другое. Почему возможность прыгнуть в Nemerle является оправдание возможности прыгнуть (причем, как я понял, гораздо дальше) в смолтоке? Тут, конечно, были примеры по существу вопроса, как использование ^ помогает сократить код, но вот это вообще к делу отношения не имеет.
Забвно, что код на том самом Немерле (чуть не сказал Мюнхаузене ) будет как минимум не длиннее. А реально гараздо более кратким так как тот же паттерн-матчинг даст фору любым выпендрежам с крышками. А уж о частичном применени функций и вообще о вычислениях над функциями и говорить не приходится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Beam, Вы писали:
B>В Smalltalk тоже можно вообще не прыгать. Прыгание используется в тех же ситуациях, в которых оно используется в Java/C#. Заметьте, что и в них тоже можно не прыгать, а спокойненько дойти до конца метода.
А, то есть пример был дан не как доказательство крутости, а как пример того как можно не далать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Klapaucius, Вы писали:
K>ПОнятно, что в ряде случаев проблемными средствами можно продолжать пользоваться. Однако не стоит отрицать проблемность этих средств.
Золотые слова, однако!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, pavel74, Вы писали:
P>Ну наконец-то . Полностью согласен, за это и любят динамические языки.
Кто-то любит. Я лично за "это" недолюбливаю. Люблю знаете ли полагаться на компилятор, а не на тестирование.
VD>>но с другой постоянно можно получить рантайм-ошибку. Это приводит к юнит тестированию на каждый чих и т.п. P>Тоже верно, просто каждый для себя делает свою оценку этих плюсов/минусов, на основе своего опыта. Теоретизировать на эту тему смысла нет.
Это ты про фразу "за это и любят динамические языки"?
P>И еще замечу такую странность , те кто реально программирует на динамических языках — этот недостаток не считают фатальным (в сравнению с получаемыми упрощениями). А те кто только теоритически рассуждает — считают фатальным.
А я заметил другую странность. Когда какие-то фанатики прославляют свою любимую игрушку, то они очень часто пытаются записать тех кто с ними несогласен в эдаких теоретиков/незнаек рассуждающих о том, что в клаза не видели. Вот только проблема в том, что это не всегда так. Я вот не мало в свое мремя пописал на разных динамических языках. И обсуждаемые языки тоже смотрел. Так что и мнение смог выработать, и выбор сделал осознанно.
P>Для реальной работы роль играет не токо на скоко в языке есть те или иные возможности, но и на скоко качетсвенны и функциональны IDE для них, а в этом плане с мегабаблом вкладываемым MC в VS и .Net тягаться уже сложнее.
Вот тут полностью согласен. Но казалось бы аргумент явно не в пользу динамики.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Eugene Beschastnov, Вы писали:
EB>Совсем не обязательно. Достаточно того, чтобы метод, реализующий сложение, умел обрабатывать аргументы разных типов (что в случае динамической типизации выполняется элементарно, если все ожидаемые типы имеют одиаковый набор методов, использующихся в данном).
Жык это еще хуже. Чтобы этот метод выбрать нужно взять каждый объект узнать его теальный тип (в массиве он ведь не приведенным к базовому типу вроде object лижит) и только потом вызвать метод. Причем все дожно быть по ссылке. Никакие джит-компиляторы тут ничего сделать не согут. Это будет опасный и тормозной код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Eugene Beschastnov, Вы писали:
EB>>Совсем не обязательно. Достаточно того, чтобы метод, реализующий сложение, умел обрабатывать аргументы разных типов (что в случае динамической типизации выполняется элементарно, если все ожидаемые типы имеют одиаковый набор методов, использующихся в данном).
VD>Жык это еще хуже. Чтобы этот метод выбрать нужно взять каждый объект узнать его теальный тип (в массиве он ведь не приведенным к базовому типу вроде object лижит) и только потом вызвать метод. Причем все дожно быть по ссылке. Никакие джит-компиляторы тут ничего сделать не согут. Это будет опасный и тормозной код.
Блин, ну Влад, ну это уже просто неприлично. Ты бы хоть немного изучил ту тему, по которой с таким апломбом высказываешься.
VD> в массиве он ведь не приведенным к базовому типу вроде object лижит
Объект всегда и везде лежит со своим собственным типом, ни к чему не приведённый. И виртуальной машине не требуется ничего дополнительно выяснять — класс объекта записан в самом объекте. При первом же взгляде на объект сразу видно его класс. Сам подумай — если бы тип лежал приведённым к чему-либо, то мы бы потеряли всю, хранящуюся в полях, созданных в классах, дочерних относительно того, к которому тип приведён.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
VD>>>Оно появлялось паралельно с развитием Лиспа и сегодня все это есть в различных его диалектоах.
FR>>Только по моему часто сначала появлялось на других языках
VD>Ошибашся. Я как-то читал, что эксперемены по паттерн-матчингу были за долго до МЛ-я.
Ну не знаю не силен в истории, может злобные функциональщики просветят
Хотя вполне допускаю что многие из новых языков прототипировались на лиспе.
FR>>Ну хаскель притендует
VD>На место в кунскамере?
Зря, вещь очень интересная, жаль у меня времени нет плотнее его изучить.
VD>>>Фнукционаьный язык — это не язык где нет изменения переменных, а язык позволяющий удобно и продуктивно писать в функцональном стиле.
FR>>
VD>А что ты улыбашся? Это между прочим общепринятое определение. И те же ML-языки только ему и удовлетворяют.
Да я согласен в общем. Просто по этому определению и руби и питон тоже функциональные языки.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Eugene Beschastnov, Вы писали:
EB>>Совсем не обязательно. Достаточно того, чтобы метод, реализующий сложение, умел обрабатывать аргументы разных типов (что в случае динамической типизации выполняется элементарно, если все ожидаемые типы имеют одиаковый набор методов, использующихся в данном).
VD>Жык это еще хуже. Чтобы этот метод выбрать нужно взять каждый объект узнать его теальный тип (в массиве он ведь не приведенным к базовому типу вроде object лижит) и только потом вызвать метод. Причем все дожно быть по ссылке. Никакие джит-компиляторы тут ничего сделать не согут. Это будет опасный и тормозной код.
Конечно может быть и так как ты описываешь, если вызывающий код сам явно проверяет проверяет типизацию. Но для динамики гораздо полезнее думать в терминах сообщений, объект получает запрос если может обработать обрабатывает, если не может вылетает с исключением, то есть ровно наооборот тому что ты описал.
А джит компиляторы это уже успешно делали до того как вообще менеджед языки со статической типизацией появились.
using System;
class MainApp
{
public static int get(int x)
{
if (x > 5)
{
throw new System.NotSupportedException();
}
return x + 1;
}
public static void Main()
{
int x = get(10);
Console.WriteLine(x);
}
}
Здравствуйте, VladD2, Вы писали:
P>>И еще замечу такую странность , те кто реально программирует на динамических языках — этот недостаток не считают фатальным (в сравнению с получаемыми упрощениями). А те кто только теоритически рассуждает — считают фатальным.
VD>А я заметил другую странность. Когда какие-то фанатики прославляют свою любимую игрушку, то они очень часто пытаются записать тех кто с ними несогласен в эдаких теоретиков/незнаек рассуждающих о том, что в клаза не видели. Вот только проблема в том, что это не всегда так. Я вот не мало в свое мремя пописал на разных динамических языках. И обсуждаемые языки тоже смотрел. Так что и мнение смог выработать, и выбор сделал осознанно.
Того что выделено не достаточно. Я тоже когда смотрел придерживался практически такого же мнения о динамике как ты сейчас. eao197 тоже помнится говорил здесь об этом же. А насчет пописал на разных динамических языках можешь сказать на каких именно и примерный объем кода.
Здравствуйте, VladD2, Вы писали:
E>>Идея писать код без учета т.н. exception safety не менее ущербна.
VD>У меня с этим проблем нет.
no comments
E>>Именно поэтому писать exception safety код очень сложно и этим часто пренебрегают. Или даже не догадываются о том, что написанный код не является exception safety.
VD>Говори за себя — "Мне на С++ писать exception safety код очень сложно...".
Ok. Но более точно будет сказать так: "Мне тяжело писать exception safety код, вне зависимости от языка, на котором это делается". Просто потому, что когда исключения повсюду, очень легко забыть, что они повсюду.
И черт побери, я бы очень хотел, чтобы среди всех окружающих меня программистов написанный именно мной код был самым плохим и не exception safe.
Все остальное написанное тобой я могу назвать только чепухой. Либо ты не понимаешь, что такое exception safety (ой ли?), либо ты просто не хотел вдумчиво прочитать написанное мной и так же вдумчиво ответить. Если есть желание, то ответь, пожалуйста, нормально и по существу. Обвинения в незнании и непонимании оставь для кого-нибудь RSDN-овского новичка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>А я заметил другую странность. Когда какие-то фанатики прославляют свою любимую игрушку, то они очень часто пытаются записать тех кто с ними несогласен в эдаких теоретиков/незнаек рассуждающих о том, что в клаза не видели. Вот только проблема в том, что это не всегда так. Я вот не мало в свое мремя пописал на разных динамических языках. И обсуждаемые языки тоже смотрел. Так что и мнение смог выработать, и выбор сделал осознанно.
эта фраза настолько абсрактна, что ее можно выдавайть обратно, с небольшими вариациями относительно динамичности/императивности языка, автору при любом высказывании про немерле/шарп
