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

FDS>Инициативность в области продвижения товара. И всё. А у программиста инициативность в области программирования. Чувствуешь разницу?

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

Здравствуйте, McSeem2, Вы писали:
MS>И ты должен это учитывать, несмотря на всякие "преведы" уважаемого Влада (извини, Влад, но слово "отвичаю" я приравниваю к слову "превед" в твоей лексике — пожалуйста, избегай впредь падонковщины, иначе я буду причислять тебя к неуважаемым мною падонкам). Такие дела.

Никогда не замечал за ним падонковского языка. Он просто много пишет и быстро а посему много опечаток

Здравствуйте, IT, Вы писали:
IT>Кстати, по поводу малого объёма исходников компилятора.

Кстати, по поводу компилятора: это только у меня так что hello.n собирается 3-4 сек. ? На той же машине 1.2M солюшн ребилдится за макс 1 сек. полностью...

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

S>Здравствуйте, IT, Вы писали:
IT>>Кстати, по поводу малого объёма исходников компилятора.

S>Кстати, по поводу компилятора: это только у меня так что hello.n собирается 3-4 сек. ? На той же машине 1.2M солюшн ребилдится за макс 1 сек. полностью...

У меня компилиться секунд за 6

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

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

FDS>>Инициативность в области продвижения товара. И всё. А у программиста инициативность в области программирования. Чувствуешь разницу?

Д>Да, навык полезный. Но чтобы продвигать товар, нужно для начала чтобы он был. Если товара (или идеи) нет — то и обсуждать нечего.
Д>Бывают конечно гении от маркетологии, которые ухитряются продать шкуру неубитого медведя (который к тому же находится в противоположном земном полушарии, за оградой из колючей проволоки и под охраной), но это уже вырожденный случай.

Прежде чем его продавать, надо знать, что будут покупать. Проще говоря:
1. У программиста гениальная идея (но никто её не будет покупать)
2. "Блин, какую ты фигню придумал, давай лучше из твоей идеи сделаем .."
3. Программист работает
4. Предприимчивый человек продаёт

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Нет, не совсем так. Если ты имел в виду, что прервется выполнение макроса — это не соответствует действительности
СТ>Макрос выполняется на этапе компиляции, и этот return (которым, кстати, по умолчанию нельзя воспользоваться) для макроса — просто узел AST.

Да, мне известно как работают макросы.

СТ>Если же ты имел в виду, что прервется выполнение "развернутого" кода до освобождения ресурсов — то, таки, да. Но это небольшая недоработка в макросе.

Это я и имел ввиду. Но Вы же не будете отрицать возможность возникновения такой проблемы при создании других макросов?!

СТ>Всего-то надо завернуть объекты DbCommand и DbDataReader в юзинг.

А это уже частности. В Smalltalk всего-то надо использовать сообщение ensure: (при использовании ресурсов так и делается, мало ли какое исключение выскочит?)

method: aBlock
    ["используем ресурсы, делаем что-то полезное, в т.ч. вычисляем aBlock"] 
        ensure: ["освобождаем ресурсы - этот код обязательно будет выполнен, даже если в aBlock был возврат"]

СТ>Так что в данном конкретном случае у Nemerle нет проблем.

В данном конкретном случае проблема таки есть — макрос-то "прервался". Просто Вы нашли способ освободить ресурсы (обошли проблему). Я же хотел донести другую мысль. При определенных обстоятельствах макросы Nemerle могут вызывать аналогичную проблему, но, думаю, что в подавляющем большинстве случаев обычно не учитывают проблемы такого плана, а всецело полагаются на программиста, который использует эти макросы. И никаких проблем это не вызывает.

Возьмите тот же макрос "for" в Nemerle (это же макрос?). Если Вы поставите return в теле цикла, то все итерации цикла не будут выполнены. Есть ли в этом макросе какой-либо код для устранения этой проблемы? Нет. Аналогична ситуация и в Smalltalk. Но является ли это вообще проблемой, о которой нужно так много говорить?

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

B>Здравствуйте, Сергей Туленцев, Вы писали:

СТ>>Нет, не совсем так. Если ты имел в виду, что прервется выполнение макроса — это не соответствует действительности
СТ>>Макрос выполняется на этапе компиляции, и этот return (которым, кстати, по умолчанию нельзя воспользоваться) для макроса — просто узел AST.

B>Да, мне известно как работают макросы.

СТ>>Если же ты имел в виду, что прервется выполнение "развернутого" кода до освобождения ресурсов — то, таки, да. Но это небольшая недоработка в макросе.

B>Это я и имел ввиду. Но Вы же не будете отрицать возможность возникновения такой проблемы при создании других макросов?!

СТ>>Всего-то надо завернуть объекты DbCommand и DbDataReader в юзинг.

B>А это уже частности. В Smalltalk всего-то надо использовать сообщение ensure: (при использовании ресурсов так и делается, мало ли какое исключение выскочит?)

B>

B>method: aBlock
B>    ["используем ресурсы, делаем что-то полезное, в т.ч. вычисляем aBlock"] 
B>        ensure: ["освобождаем ресурсы - этот код обязательно будет выполнен, даже если в aBlock был возврат"]
B>

СТ>>Так что в данном конкретном случае у Nemerle нет проблем.

B>В данном конкретном случае проблема таки есть — макрос-то "прервался". Просто Вы нашли способ освободить ресурсы (обошли проблему). Я же хотел донести другую мысль. При определенных обстоятельствах макросы Nemerle могут вызывать аналогичную проблему, но, думаю, что в подавляющем большинстве случаев обычно не учитывают проблемы такого плана, а всецело полагаются на программиста, который использует эти макросы. И никаких проблем это не вызывает.

Стоп, стоп. стоп. Ну вам же сказали, что нужно использовать using: если я правильно понял, он аналогичен ensure

B>Возьмите тот же макрос "for" в Nemerle (это же макрос?).

Угу.

B> Если Вы поставите return в теле цикла, то все итерации цикла не будут выполнены. Есть ли в этом макросе какой-либо код для устранения этой проблемы? Нет. Аналогична ситуация и в Smalltalk. Но является ли это вообще проблемой, о которой нужно так много говорить?

А что, в сишном коде for (int i = 0; i < count; i++) {return;} будут выполнены все итерации? Это стандартное поведение никак нельзя счтитать ошибкой, наоборот, если бы было иначе, то это была бы ошибка

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

СТ>>Если же ты имел в виду, что прервется выполнение "развернутого" кода до освобождения ресурсов — то, таки, да. Но это небольшая недоработка в макросе.

B>Это я и имел ввиду. Но Вы же не будете отрицать возможность возникновения такой проблемы при создании других макросов?!

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

СТ>>Всего-то надо завернуть объекты DbCommand и DbDataReader в юзинг.

B>А это уже частности. В Smalltalk всего-то надо использовать сообщение ensure: (при использовании ресурсов так и делается, мало ли какое исключение выскочит?)

А чем этот ensure отличается от using?

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

IT>>Желающие могут переписать это на свой лад и даже поприменять разные паттерны, но боюсь что более компактного кода, чем на Nemerle не получится.

G>О сколько нам открытий чудных.

Толи ещё будет

G>Оказывается — это паттерн-матчинг с алгебраическми типами, дернутыми из ML нам так помог, а не макросы. Ты меня разочаровываешь.

Так я это не для тебя писал. Я это писал для людей со здоровым скепсисом, которым важно не только знать о крутости фичи по наслышке от таких просвящённых уников как ты, но ещё и понимать что за этим реально кроется и как это работет. Тому же FDSC, например, надо просто немножко помочь, что-то объяснить, что-то подсказать, т.к. ему самому неверняка глубоко копать нет времени да и пока не надо было.

От вас же, просвящённых, только пока и слышно: мы знаем что такое pattern matching, поэтому мы умные. Так вот. Мы будем рассказывать людям что такое pattern matching и как он работает, они тоже будут становиться умными, а вы будете потихоньку превращаться в Неуловимых Джо.

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

G>А я думал — что мэйнстрим у нас самое лучшее.

По крайней мере, мэйнстрим к этому стремится, что лично меня не может не радовать. Замыкания у нас уже есть примерно с год, короткая форма лямбды, анонимные типы и вывод типов будет через пол года. В джаве, по рассказам джавистов (за достоверность не ручаюсь), ввели некоторое подобие алгебраических типов. Остался только по большому счёту pattern matching. Каринг фича приятная, но не принципиальная. Что у вас ещё осталось? Да практически больше ничего. А у нас помимо всего вышеперечисленного есть ещё бронепоезд на запасном пути, у которого первая буква названия — это первая буква слова Nemerle

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

ГВ>>Глупость это была бы несусветная.
Д>с чего это вдруг? Тебе составляет какие-то проблемы привести список выполненных тобой работ? И мы со Владом сразу отправимся посыпать голову пеплом и сгорать от стыда.

Ты хоть разберись толком, к кому обращался Влад.

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

Д>Псевдо-логический вывод "умных меньшинство, я следую за меньшинством — значит, умный", похоже, очень популярен на этом форуме.

Что-то мне так не показалось. Скорее уж популярно псевдологическое: "кто не следует за большинством, тот совершает глупость". Разницу не чуешь?

Д>Я конечно могу понять, что эта точка зрения очень притягательна для людей определенного склада ума, и посамоутверждаться за счет высказываний "все в мэйнстриме глупые, а я не в мэйнстриме и поэтому умный" — самый простой способ поднять свою самооценку. Но кажется мне, что наличие таких высказываний говорит о прямо противоположном уровне интеллекта.

Вот интересный момент. Когда радетели следования за большинством начинают пинать меньшинство (просто в силу количественных показателей), это самоутверждением не считается. В обратной ситуации сразу же крик про "самоутверждение". Как думаешь, в чём тут дело?

Здравствуйте, Сергей Туленцев, Вы писали:

B>>Это я и имел ввиду. Но Вы же не будете отрицать возможность возникновения такой проблемы при создании других макросов?!

СТ>Не буду, это было бы глупо. Но для того и нужна голова, чтобы думать.

Об этом и речь

СТ>А чем этот ensure отличается от using?

Ensure — это аналог try-finally в других языках

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

FDS>Стоп, стоп. стоп. Ну вам же сказали, что нужно использовать using: если я правильно понял, он аналогичен ensure

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

B>> Если Вы поставите return в теле цикла, то все итерации цикла не будут выполнены. Есть ли в этом макросе какой-либо код для устранения этой проблемы? Нет. Аналогична ситуация и в Smalltalk. Но является ли это вообще проблемой, о которой нужно так много говорить?

FDS>А что, в сишном коде for (int i = 0; i < count; i++) {return;} будут выполнены все итерации? Это стандартное поведение никак нельзя счтитать ошибкой, наоборот, если бы было иначе, то это была бы ошибка

А Вы думаете в Smalltalk все наоборот? Пример

0 to: count-1 do: [:i | "это блок переданн в качестве параметра" ... ]

Для реализации этого метода все равно: передан блок с возвратом или обычный блок, т.е. никаких проверок нет. И он делает то, что Вы от него ожидаете. Будете передан обычный блок — будут выполнены все итерации цикла, будет передан блок с возвратом (return) — не будут. Ну в чем здесь проблема???

Вернемся к макросам Nemerle. Пусть у нас есть макрос, с параметром body (код). И пусть этот параметр используется в середине макроса. Т.е. при развертывании макроса получится код:

    // выполняем какой-то код 1
    // здесь будет код $body
    // выполняем какой-то код 2

Если Вы передадите в этот макрос код, внутри которого есть return , то код 2 выполнен не будет

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

S>Кстати, по поводу компилятора: это только у меня так что hello.n собирается 3-4 сек. ?

Есть такое дело. Первый раз долго поднимается компилятор. Потом всё значительно быстрее.

S>На той же машине 1.2M солюшн ребилдится за макс 1 сек. полностью...

1.2M чего?

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

G>>Оказывается — это паттерн-матчинг с алгебраическми типами, дернутыми из ML нам так помог, а не макросы. Ты меня разочаровываешь.
IT>От вас же, просвящённых, только пока и слышно: мы знаем что такое pattern matching, поэтому мы умные.
Ну я понимаю, что некоторые тут чувствуют себя неудобно, когда рядом кто-то шибко умные слова говорит, паттерн-матчинг там или карринг. Прям свербит, хочется в харю очкастым умникам дать, правда? Но ничего, это пройдет.

IT>Так вот. Мы будем рассказывать людям что такое pattern matching и как он работает, они тоже будут становиться умными, а вы будете потихоньку превращаться в Неуловимых Джо.
А тебе не приходило в голову, что мы, очкастые умники, чти-нибудь еще умное за это время выучим, пока вы с паттерн-матчингом разбираетесь?

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

Ой, какой кошмар — не успеем, и поезд уйдет — IT c Владом все-превсе расскажут про паттерн-матчинг, и все в форуме "философия" сразу станут умными, а "мы" останемся в дураках. Ну и напугал ты меня. Времени-то много осталось, до ухода поезда?

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

IT>Есть такое дело. Первый раз долго поднимается компилятор. Потом всё значительно быстрее.
Возможно. Я только одиночные файлы собирал.

IT>1.2M чего?
Исходников

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

VD>Мы тут с IT во всю колбасим на языке котрый Lisp за предка считает и [...]

Если мне не изменяет память, то где-то когда-то я уже слышал что-то о наследнике C++. М-м-м-м... Кажется, в названии этого языка был такой значок... как его, а, вот такой: '#', или я его путаю с названием каких-то островов в Тихом океане?

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

VK>Я бы сказал, что для императивного программиста уже хорошо знакомого как минимум с C# 2.0 и C++.

+1

VD>>Похоже баг.
VK>Это не баг. Мне кажется это by design, просто с невнятным сообщением об ошибке.

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

VK> Объявление локальных функций предусматривает создание нового класса

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

Вот только по мне так поддерживать ref/out в локальных функциях вообще не стоит. Это будет полдталкивать тех кто раньше писал на Шарпе использовать плохой стиль программирования. Немерле обладает намного более красивыми возможностями, чтобы использовать эти ref/out.

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

IT>Кстати, по поводу малого объёма исходников компилятора. Вообще-то, к таким заявлениям я всегда отношусь скептически. Ничего из ничего не получается. Не бывает так, что если компилятор — это довольно сложный автомат, то в нём мало логики. Ну не бывает так. А если логики много, то как кода может быть мало? Куда он мог подеваться.

Дык ты путашь две вещи. Объем исходников и объем логики. Обем логики в нем дай бог каждому. А объем исходнико получается меньше из-за более коротких конструкций и сахара. Ну, конечно из-за проектных решений еще. Просто мнокие вещи требующие на чистых ООЯ создания моря классов и соотвествующей инфраструктуры утут заменяется вариантом содержащим все описание в одном месте и очень компактно. Далее распознование этих вариантов выглядит тоже гораздо компактнее. Ведь одно вхождение match-а может заменить целую кучу фифов и свитчей. Код распознователя паттерн-матчинга — это очень не кислый хайтек (см. ncc\typing\DecisionTreeBuilder.n). Далее идут квази-цитирование и макросы. То что описывается на страницу в терминах классов АСТ можно описать очень компактно с помщью квази-цитирования. Макросы позволяют устранить дублирование кода. А для компиляторов это очень актуально.

IT>Оказалось, что так оно и есть, логики в компиляторе много, а кода действительно мало. Разработчикам удалось её упаковать в pattern matching и варианты (алгебраические типы).

О том и речь. Но упакованная таким образом она как не странно воспринимается намного лучше чем поря if-ов и разброснные по всему коду классы. Что уж там говорить о Посетителях на 10 экранов?

IT>Пример.

IT>Распаршенные выражения в компиляторе представляются классом PExpr примерно такой структуры:

IT>

IT>public variant PExpr
IT>{
IT>  | Array       { rank : PExpr; args : PExpr; }
IT>  | Literal     { val  : Literal; }
IT>  | ListLiteral { elements : list [PExpr]; }
IT>  // ...
IT>}

IT>public variant Literal
IT>{
IT>  | Void
IT>  | Integer { val : ulong; is_negative : bool; mutable treat_as : MType.Class; }
IT>  // ...
IT>}
IT>

IT>Опции варианта реализуются как сабклассы варианта. Т.е аналогичная запись на C# была бы такая:

IT>

IT>public class PExpr
IT>{
IT>  public class Array : PExpr
IT>  {
IT>    public PExpr rank;
IT>    public PExpr args;
IT>  }

IT>  public class Literal : PExpr
IT>  {
IT>    public Literal val;
IT>  }

IT>  public class ListLiteral : PExpr
IT>  {
IT>    public list<PExpr> elements;
IT>  }

IT>  // ...
IT>}

IT>public class Literal
IT>{
IT>  public class Void : Literal
IT>  {
IT>  }

IT>  public class Integer : Literal
IT>  {
IT>    public ulong       val;
IT>    public bool        is_negative;
IT>    public MType.Class treat_as;
IT>  }

IT>  // ...
IT>}
IT>

IT>Т.е. уже здесь видна компакность записи подобных структур данных.

Ты забыл конструкторы. Они тоже много места занимаю при этом являясь для данного случая чистым шумом. Меж тем макросики вроде [Record] позволяют добавить к классу конструктор соврешенно декларативно — в одно слово. Так что выигрышь увеличивается, а вот сложность программы только уменьшается. Нам ведь совсем не интересно смотреть на стократно повторяющиеся реализации тупых конструкторов? Зато увидав надписть [Record] и сразу понимашь, что конструктор не содержит ошибок и банально инициализирует поля.

IT>Но это всё оказалось цветочки, по сравнению с обработкой этих данных. Вот кусочек компилятора:
...
IT>Желающие могут переписать это на свой лад и даже поприменять разные паттерны, но боюсь что более компактного кода, чем на Nemerle не получится.

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

IT>Такой код легко писать, легко понимать. У компилятора появляются дополнительные возможности по оптимизации. А унас поднимается планка наших возможностей.

Именно, но мудрые дядки из Сана и МС боятся что народ не поймет сложностей. А в Сан еще и компостируют мозг разводя ноя что-то вроде "это же не объектно ориентированно...". В общем, театр абсурда.

IT>Как любил поговаривать мой первый шеф — качество/сложность чего-либо не может превышать на порядок качества/сложности инструмента, с помощью которого оно сделано.

Именно. И именно потому я поставил паттерн-матчинг и варианты выше.

Интересно сколько нужно времени и сил, чтобы такими очевидными вещам прониклись современные "ОО-программеры"? И интересно какого черта это не видят ни в МС, ни в Сан?

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Исключения исключениям рознь. В джаве и дотнете при вылете исключения редко когда можно сделать что-то осмысленное. Но на них свет не сошелся.

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

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

Еще один пример — открытие файла. Файла может не быть или он может быть недоступен для чтения (защита, сбои, ...). Тут логично обернуть функцию открывающую файл в tye/catch чтобы в случае исключения показать соощение об ошибке и предложить выбрать другой файл.

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