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

B>Здравствуйте, Курилка, Вы писали:

К>>Так вот — хотелось бы рассмотреть вопрос: насколько синтаксис языка определяет его удобство для использования?

B>Прочитал я сейчас определение синтаксиса (естественного языка) и осознал, что в зону его влияния не входят слова языка (т.е. лексика), а входят лишь правила построения связной речи.

B>Может в этом и есть секрет таких языков как Lisp, Smalltalk, J, ... (продолжите список)? Ведь в них как раз и имеется минимальный синтаксис, который:
B>

B>* позволяет связывать различные слова друг с другом
B>* не пытается залезть на уровень лексики (минимальное количество ключевых слов)
B>

B>Я не силен в науке о русском языке (кстати, как называется?), так что поправьте если что.

Как же тогда быть с тем, что мы хотим, что бы язык находил в виде синтаксических ошибок некоторые наши логические ошибки? Ведь если не лезть, как вы выражаетесь в лексику, то и проверять нечего

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

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


VD>>Да, нам, тем кто программирует не на словах, а реально действитнльно не просто. Чтобы программа заработала без ошибок при исключении приходится создавать спецальный код востановления после ошибки. Перехватывать исключения и обеспечивать непротиворечивость инварината. Иногда это просто. Иногда не очень. Иногда вообще разумнее выдать окошко и закрыть программу от греха.

FR>Телепатия?

О чём вы? Ведь правильно всё сказано, а исходное сообщение было явно провокационным

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

ГВ>>>>Рисковано порой, вероятно, но...
FDS>>>В этом споре было сказано, что эта возможность применяется часто.
ГВ>>Я знаю. Значит, есть какие-то наработанные способы правильного использования такой фичи.
FDS>ГДЕ ОНИ. Я уже раза три просил сказать правила, в которых используются нелокальные возвраты.

Увы. Это — не ко мне. Хотя крик души понятен.

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

F>>Нет, я думаю что успешными можно назвать гораздо больше стартапов, про те, про которые ты или я или кто-то еще здесь — слышали. То, о чем становится известно по всему миру — это супер успешные стартапы.
FDS>Почему тогда эти супер успешные стартапы не на LISP?

Это надо у них самих спрашивать, почему они Lisp не взяли. В ФП ты по большей части только общие рассуждения услышишь.

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

ГВ>> Что-то подобное я и ожидал услышать. Но ты не понял. Я говорю о скуке, вызванной однообразием и примитивностью задач. Здесь уже ни кино ни стриптиз не помогут.

F>Вот это ключевой момент.
F>У меня вот почему-то такое впечатление, что такие однообразные и прмитивные задачи возникают не из-за некой темной силы мейнстрима, а из-за потребностей заказчиков в решении именно этих задач.

Ну да. Только не надо выворачивать всё наизнанку. Из того, что в мире много скучных задач ещё не следует, что такие задачи должны быть приоритетом для некоего отдельно взятого человека. И уж тем более не следует пренебрежительно относиться к тем, кто этими скучными задачами не занимается.

F>Если люди, которым нужно решить определенные задачи. И средство надо выбирать — которе позволит наиболее эффективно решить именно эти задачи, а не то, которое даст разработчку возможность хорошо поразвлекаться.

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

А возникает она порой из-за того, что нечто оказалось "принято, а следовательно — надо".

F>Программирование ради программирования — это как бег ради бега. Хорошее занятие — позволяет поддерживать себя в форме. И полученный навык зачастую может пригодиться в жизни. Однако на работу на другой конец города разумнее ездить в метро или на машине, а не бегать самому, даже если ты способен пробежать 30км без остановки.

Если бегать — удовольствие, то можно и на работу пробежаться. Ездят же на велосипеде на работу. "Разумность" здесь выражается в скорости доставки от дома до офиса и в том, что не нужно оборудовать офис душевой кабиной.

F>Каждой задаче — свое средство. Интересность/скучность задачи зависят от самой задачи, а никак не от используемого средства для ее решения.

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

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

VD>>Вот макросы — это способ сделать это не просто лучше, а почти идиально. Правда в компайлтайме, но все же.

FDS>Идеально?

Ага. Причем я в данном случае выступаю не как пользователь с некими предпочтениями, а как создатель конкурирующего продукта отказавшегося от своих подходов оценив подходы использованные в Немерле.

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

FDS>Я именно их и смотрел (и там, и там). Первым делом. Но создалось впечатление, что они пытаются научить языку по примерам. Я так и не нашёл ничего похожего на спецификаию C#.

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

FDS>Например, где найти ответ на вопрос, как работает это:
FDS>

FDS>    def F2(x: int): int -> int
FDS>    {
FDS>        def FC(y: int): int
FDS>        {
FDS>            2*y + x
FDS>        }
FDS>        FC
FDS>    }
FDS>    def F1(x: int): int
FDS>        {
FDS>                F2(x)(5)
FDS>    }
FDS>F1(5)
FDS>

FDS> и работает ли вообще? Как это будет воспринято компилятором?

За исключением того, что программа не использует значение функции F1 и ничего не выводит, она совершенно корректа. Далает она следующее. Функция F2() возвращает другую функцию которая производит вычисления над своим параметром y и значением параметра x захваченным замыканием. Далее производится вызов этой функии с передачей ее значения.

Вот только можно было бы опустить типы параметров. Все и так очевидно. Так что вот такой код:

using System.Console;

def F2(x)
{
  def FC(y) { 2 * y + x }

  FC
}

def F1(x) { F2(x)(5) }

WriteLine(F1(5))

выведет 15. А такой:

using System.Console;

def F2(x)
{
  def FC(y) { 2 * y + x }

  FC
}

def F1(x) { F2(x)(5) }

WriteLine(F1(100))

естественно 110.

Смысла он не имеет, но демонстриует одно из важных свойств языка — вычисления над фукнциями. Практически все тоже самое, но более грамоздко можно сделать и на C# 2.0. Вот аналогичный код:

using System;

delegate int MyDelegate(int x);

class Program
{
    static MyDelegate F2(int x)
    {
        MyDelegate FC = delegate(int y) { return 2 * y + x; };

        return FC;
    }

    static int F1(int x) { return F2(x)(5); }

    static void Main()
    {
        Console.WriteLine(F1(100));
    }
}

Думаю, вряд ли тот кто понимает последний код не поймет предыдущие варианты.

FDS>Или, например, я не нашёл ответ на вопрос: могу ли я во время компиляции выделить макросом кусок уже разобранного nemerle кода и выполнить с ним специфические действия (например, проверку на освобождение ресурсов или на диапазон выходных значений по заданным входным и выходным)?

Такие вопросы можно задать на форуме. Если вопрос действительно интересен, то отвечу — можно. Хотя это и не тривиально.

FDS> Могу ли я во время компиляции выполнить некоторые операции программы пользователя в штатном режиме (что-то вроде встроенного ЮТ)? [и как мне это сделать и где это описано]

Хм. До окончания компиляци кода копилируемого приложения нет. Так что выполнить его невозможно. Юнит-тесты можно вмонтировать в код сборки или даже незаметно создать еще одну сборку с юнит-тестами.

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

FDS>Может это и есть где-то, но я не заметил

На такие вопросы ответы в документации найти невозможно в принципе. Но их можно задать на форуме.

FDS>Если я макросом генерирую другой макрос, как мне избавиться от квазицитирования,

Насколко я знаю макросом нельзя сгенерировать другой макрос.

FDS>Почему это:
FDS>

FDS>macro m(x: int)
FDS>{
FDS>    for (mutable i = x - 1; i >= 0; i--) 
FDS>    {
FDS>        <[
FDS>            System.Console.WriteLine("ss {0}", $x);
FDS>        ]>
FDS>    }
FDS>//    <[()]>
FDS>};

FDS>----
FDS>macro1.n:14:1:14:25: ←[01;31merror←[0m: in argument #2 (tl) of list[System.Objec
FDS>t-], needed a list[Nemerle.Compiler.Parsetree.PExpr.Literal-], got list[int-]: c
FDS>ommon super type of types [Nemerle.Compiler.Parsetree.PExpr.Literal, int] is jus
FDS>t `System.Object', please upcast one of the types to `System.Object' if this is
FDS>desired
FDS>

FDS> даёт ошибку (приведена после черты)?

Видимо потому что нужно как-то так:

macro m(x : int)
{
  mutable result = [];

  for (mutable i = x - 1; i >= 0; i--) 
    result ::= <[ System.Console.WriteLine("ss {0}", $(x : int)); ]>;

  <[ { ..$result } ]>
}

1. Макрос обязан вернуть одно выражение. Тут же их много, так что нужно завернуть их в блок. Последняя команда как раз это и делает. В цикле же формируется список выражений которые потом помещаются в блок.
2. Параметр х является целым числом для макроса, а требуется литерал. Тут требется подсказка компилятору, что нужно преобразовать значение из переменной х в литерал. Конечно компилятор мог бы быть и по умнее. Но и так не плохо по сравению с тем что приходится вытворять в подобных случаях при других способах генерации кода.

FDS>В общем, некоторые вопросы рассеялись, когда я думал, что мне непонятно конкретно. Но всё равно, ощущение такое, что макросам нехватает целостности (строгости концепции).

С концепциями у них все в пордядке. Вот качественного описания действительно нехватает. Да и сообщения об ошибках могли бы быть по внятнее.

FDS>Локальные функции круче Хотя теперь не придётся создавать массивы.

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

VD>>2. Локальные функции.

FDS>В Delphi есть, кстати, безопаснее (хотя и менее функционально). Там, по крайней мере, нельзя написать то, что я привёл выше .

В Дельфи как локальные функции и на ёту не приближаются к этим. Эти являются замыканиями и могут использовать весе что объявлено перед ними.

А вот безопасными они как раз не являются. Дельфи вообще не безопасный язык. Если передать адрес на них извне основной функции будут еще те вылеты. В Дельфи НЭТ конечно все лучше.

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

Где ты увилил жертву безопасности? Это Дельфи небезопасна в туче мест. А Немрле один из самых безопасных языков которые я видел.

Что ты понимаешь под термином "безопасно" и "небезопасно".

VD>>4. Вывод типов.
FDS>Так и не понял, что это даёт. Кроме экономии кода, конечно (кажется, это уже обсуждали на форуме?)

Это и дает. Лишнего в коде нет. Код становится короче и стало быть понятнее. Если нужно изнать тип чего-то, то просто подвидишь мышьку в IDE и смотришь хинт.

VD>>8. Частичное применение функций и операторов.
VD>>9. Сплайсебл-строки.
FDS>Не нашёл ни 9, ни 8. Может дадите ссылку на конкретный документ?

Все описано в статье

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

. Сделай поиск по статье на $" (бакс и ковычка) и почитай что там написано. Частичному применению посвящен отдельный раздел Частичное применение и другие операции над функциями и операторами

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

.

VD>>11. Бесплатная концевая рекурсия.

FDS>Не заметил, спасибо. Я думал, что они там все на функциональном программировании совсем свихнулись

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

VD>>12. Краткий синтаксис работы со спискам и встроенные в язык списки.

FDS>А за чем они такие нужны (если их нельзя изменять)? В документации написано, что часто используются, но я так и не понял где

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

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

ГВ>С равным (совершенно равным!) успехом можно пульнуть исключение из любого метода в языке, подобном C++. Например, так:

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

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

ГВ>>Знаешь, порой много экономичнее вместо долгого разбора по кусочкам, многокилобайтного вычисления ошибок и их разбора, вычленения неправомерных обобщений и усилений... В общем, вместо анализа просто сказать: автор — ламер. Тем более, когда такие вещи видны не вооружённым глазом.

FDS>Варварство, бросание тухлых яиц...

Нет, просто обозначение вещей своими именами.

FDS>Нужно объяснять человеку где он ошибся, а не просто обзываться: ему то не понятно, раз он глупость написал

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

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

Но и оставлять глупости неоткомментированными тоже не хочется. Потому что иной колеблющийся может прочесть ахинею и принять её на веру. В итоге одним дураком станет больше, что не есть гуд.

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

VD>Вообще-то тут рядом был показан пример где это работало. Но даже если так, то это очень плохо, так как исаключение получать от вызова return как минимум странно.

Странно написать код при котором от return произойдет исключение.

VD>Изучай первоисточник:
VD>Re[6]: Насколько важен синтаксис языка?

Автор: Andrei N.Sobchuck
Дата: 05.09.06

VD>точнее начало здесь:
VD>Re[4]: Насколько важен синтаксис языка?

Автор: Andrei N.Sobchuck
Дата: 04.09.06

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

Но приведу этот пример сам и все-таки соглашусь с Вами. Действительно возможна ситуация когда метод выполняющий блок (переданный в качестве параметра) может не ожидать прерывания своей работы.

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

Но в подавляющем большинстве случаев возвратов из блоков все-таки полезен и не приводит к ошибкам:

includes: anObject 
    "Возвращает true если anObject является одним из элементов коллекции"
        
    | found |
    founded := false.
    self do: [:each | anObject = each ifTrue: [found := true]].
    ^found

В этом коде return в блоках нет. Но нам понадобилась дополнительная переменная found

includes: anObject 
    "Возвращает true если anObject является одним из элементов коллекции"

    self do: [:each | anObject = each ifTrue: [^true]].
    ^false

А в этом коде return в блоке есть. Видно, что код стал более понятным — мы избавились от лишней переменной. Оба return в данном коде (и в блоке, и вне) обозначают одно и то же — завершение работы метода и возврат значения.

Уверен, что Вы и сами часто используете эту технику.

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

Д>Многие "ученые" по модели существования от этой мышки ничем не отличаются. Только сжирают они не зерно, а гранты.

Если ты заметил, то слово "учёный" я в кавычки не брал.

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

FDS>Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>>>>Рисковано порой, вероятно, но...
FDS>>>В этом споре было сказано, что эта возможность применяется часто.

ГВ>>Я знаю. Значит, есть какие-то наработанные способы правильного использования такой фичи.

FDS>ГДЕ ОНИ. Я уже раза три просил сказать правила, в которых используются нелокальные возвраты.

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

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

FDS>>Я именно их и смотрел (и там, и там). Первым делом. Но создалось впечатление, что они пытаются научить языку по примерам. Я так и не нашёл ничего похожего на спецификаию C#.

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

Но лучше бы, если бы была

VD>Вот только можно было бы опустить типы параметров. Все и так очевидно. Так что вот такой код:
VD>

VD>using System.Console;

VD>def F2(x)
VD>{
VD>  def FC(y) { 2 * y + x }

VD>  FC
VD>}

VD>def F1(x) { F2(x)(5) }

VD>WriteLine(F1(100))
VD>

VD>естественно 110.

VD>Смысла он не имеет, но демонстриует одно из важных свойств языка — вычисления над фукнциями.

Я его тут скомпилировал. Прикол в том, что он у меня не работает: выдаёт exception. То ли у меня руки кривые и я его неправильно скомпилил, то ли не знаю что

FDS>>Или, например, я не нашёл ответ на вопрос: могу ли я во время компиляции выделить макросом кусок уже разобранного nemerle кода и выполнить с ним специфические действия (например, проверку на освобождение ресурсов или на диапазон выходных значений по заданным входным и выходным)?

VD>Такие вопросы можно задать на форуме. Если вопрос действительно интересен, то отвечу — можно. Хотя это и не тривиально.

Хм, на самом деле, было бы неплохо, если бы это описывалось в документации. Первое, что мне в голову пришло — это именно анализ дерева.

FDS>> Могу ли я во время компиляции выполнить некоторые операции программы пользователя в штатном режиме (что-то вроде встроенного ЮТ)? [и как мне это сделать и где это описано]

FDS>>Может это и есть где-то, но я не заметил

VD>На такие вопросы ответы в документации найти невозможно в принципе. Но их можно задать на форуме.

Видать, я жуткий бюрократ . А в каком их форуме задавать?

VD>Видимо потому что нужно как-то так:
VD>

VD>macro m(x : int)
VD>{
VD>  mutable result = [];

VD>  for (mutable i = x - 1; i >= 0; i--) 
VD>    result ::= <[ System.Console.WriteLine("ss {0}", $(x : int)); ]>;

VD>  <[ { ..$result } ]>
VD>}
VD>

VD>1. Макрос обязан вернуть одно выражение. Тут же их много, так что нужно завернуть их в блок. Последняя команда как раз это и делает. В цикле же формируется список выражений которые потом помещаются в блок.
VD>2. Параметр х является целым числом для макроса, а требуется литерал. Тут требется подсказка компилятору, что нужно преобразовать значение из переменной х в литерал. Конечно компилятор мог бы быть и по умнее. Но и так не плохо по сравению с тем что приходится вытворять в подобных случаях при других способах генерации кода.

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

FDS>>Локальные функции круче Хотя теперь не придётся создавать массивы.
VD>Незнаю причем тут массивы, но я бы поставил паттерн-матчинг выше по значимости. Кслати, его очень удобно исползовать в тех самых локальных фукнциях.

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

VD>>>2. Локальные функции.

...

VD>В Дельфи как локальные функции и на ёту не приближаются к этим. Эти являются замыканиями и могут использовать весе что объявлено перед ними.

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

VD>>>4. Вывод типов.
...

VD>Это и дает. Лишнего в коде нет. Код становится короче и стало быть понятнее. Если нужно изнать тип чего-то, то просто подвидишь мышьку в IDE и смотришь хинт.

Ага, а если нет интергации с MS VS (1. не могу скачать последнюю версию непомню уже чего, 2. нефига не понимаю и т.п., в общем у меня не работает даже "простая" интеграция с VS, точнее работает, но на половину )

VD>>>8. Частичное применение функций и операторов.
VD>>>9. Сплайсебл-строки.
FDS>>Не нашёл ни 9, ни 8. Может дадите ссылку на конкретный документ?

VD>Все описано в статье

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

. Сделай поиск по статье на $" (бакс и ковычка) и почитай что там написано. Частичному применению посвящен отдельный раздел Частичное применение и другие операции над функциями и операторами

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

.

Ужас. Прочитал. Вообще, я очень невнимательно читал статьи и документацию, виноват. Спасибо

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

FDS>>ГДЕ ОНИ. Я уже раза три просил сказать правила, в которых используются нелокальные возвраты.

B>А я уже несколько раз отвечал... Обычно это используется, когда надо прервать работу метода не доходя до его конца.Так же как и в прочих языках.

Не когда это используется, а какие ограничения в использовании. Вы же сами привели пример с транзакцией. Какие правила позволяют исключить такую ошибку? Проще говоря, при небезопасной возможности языка должно быть очевидное правило, которое позволяет его безопасно использовать. Судя по высказываниям любителей SmallTalk, это правило существует. Вот я и хочу знать, какое оно?

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

B>>Может в этом и есть секрет таких языков как Lisp, Smalltalk, J, ... (продолжите список)? Ведь в них как раз и имеется минимальный синтаксис, который:
B>>

B>>* позволяет связывать различные слова друг с другом
B>>* не пытается залезть на уровень лексики (минимальное количество ключевых слов)
B>>

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

Это позволит повышать уровень абстракции, а это приведет к снижению количества логических ошибок. Причем к уменьшению на порядки по сравнению с тем количеством, которые сможет выявить компилятор на предыдущем уровне абстракции (сравните ассемблер и Java/C#).

А проверять всегда есть чего
Представьте язык программирования, в котором можно описывать слова и оперировать ими. Определили мы конкретные существительные, глаголы, прилагательные (лексику) и составляем предложения из них. Но правила-то все-равно останутся: сказуемое (глагол) должно стоять после подлежащего (существительного), а определение (прилагательное) перед подлежащим, в предложении обязательно должно сказуемое ну и т.д. Проверяйте на здоровье. Вот

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

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

ГВ>>>Знаешь, порой много экономичнее вместо долгого разбора по кусочкам, многокилобайтного вычисления ошибок и их разбора, вычленения неправомерных обобщений и усилений... В общем, вместо анализа просто сказать: автор — ламер. Тем более, когда такие вещи видны не вооружённым глазом.

FDS>>Варварство, бросание тухлых яиц...

ГВ>Нет, просто обозначение вещей своими именами.

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

FDS>>Нужно объяснять человеку где он ошибся, а не просто обзываться: ему то не понятно, раз он глупость написал

ГВ>Не сочти за обиду, но видать, тебе мало приходилось объяснять другим их ошибки. Поверь, это крайне неблагодарное занятие. Тем более, когда ошибающийся даже слушать никого не хочет.

Согласен. Самое плохое, что это ещё и скучно — вот это уже препятствие.

ГВ>По моим наблюдениям, в среднем для того, чтобы разобрать ошибки, которые отдельные деятели могут уместить в небольшом абзаце, нужно потратить примерно раза в три больше букв и раз в десять больше времени. Это может быть интересно, если такой разбор представляет определённую ценность для самого разбирающего. В ином случае... На этот счёт есть восточная поговорка, которая звучит примерно так (есть вариации): "Иной дурак за час столько наговорит, что мудрец и за сто лет не разобрать".

Не обязательно разбирать всё.

ГВ>Но и оставлять глупости неоткомментированными тоже не хочется. Потому что иной колеблющийся может прочесть ахинею и принять её на веру. В итоге одним дураком станет больше, что не есть гуд.

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

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

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

B>>>Может в этом и есть секрет таких языков как Lisp, Smalltalk, J, ... (продолжите список)? Ведь в них как раз и имеется минимальный синтаксис, который:
B>>>

B>>>* позволяет связывать различные слова друг с другом
B>>>* не пытается залезть на уровень лексики (минимальное количество ключевых слов)
B>>>

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

B>Это позволит повышать уровень абстракции, а это приведет к снижению количества логических ошибок. Причем к уменьшению на порядки по сравнению с тем количеством, которые сможет выявить компилятор на предыдущем уровне абстракции (сравните ассемблер и Java/C#).

Да, но как уровень абстракции связан с лексической минимальностью?

B>А проверять всегда есть чего
B>Представьте язык программирования, в котором можно описывать слова и оперировать ими. Определили мы конкретные существительные, глаголы, прилагательные (лексику) и составляем предложения из них. Но правила-то все-равно останутся: сказуемое (глагол) должно стоять после подлежащего (существительного), а определение (прилагательное) перед подлежащим, в предложении обязательно должно сказуемое ну и т.д. Проверяйте на здоровье. Вот

Это немного не то. Сдесь синтаксис и больше ничего. Никакой связи с семантикой.

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

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

FDS>>>ГДЕ ОНИ. Я уже раза три просил сказать правила, в которых используются нелокальные возвраты.

B>>А я уже несколько раз отвечал... Обычно это используется, когда надо прервать работу метода не доходя до его конца.Так же как и в прочих языках.

FDS>Не когда это используется, а какие ограничения в использовании. Вы же сами привели пример с транзакцией. Какие правила позволяют исключить такую ошибку? Проще говоря, при небезопасной возможности языка должно быть очевидное правило, которое позволяет его безопасно использовать. Судя по высказываниям любителей SmallTalk, это правило существует. Вот я и хочу знать, какое оно?

Интересный вопрос. И на него трудно ответить, т.к., как уже говорилось, такие проблемы обычно не возникают
В случае частого возникновения такой проблемы я бы стремился:
1. Создавать методы, не имеющие побочных эффектов (не считаем побочным эффектом выполнение блока). Вообще-то это правило стоит применять постоянно, т.е. не только для ухода от проблемы (ФП, однако)
2. Вычислять блоки, передаваемые в качестве параметров, в самом конце работы метода, когда работа уже выполнена
3. Или наоборот вычислять блоки в самом начале, т.е. до использования ресурсов или изменения внутренних переменных класса

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

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

ГВ>>>>Знаешь, порой много экономичнее вместо долгого разбора по кусочкам, многокилобайтного вычисления ошибок и их разбора, вычленения неправомерных обобщений и усилений... В общем, вместо анализа просто сказать: автор — ламер. Тем более, когда такие вещи видны не вооружённым глазом.
FDS>>>Варварство, бросание тухлых яиц...
ГВ>>Нет, просто обозначение вещей своими именами.
FDS>Для того, что бы обозначить вещь своим именем, нужно сначала доказать, что эта вещь действительно так называется. Иначе это иногда приводит к странным ошибкам.

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

FDS>>>Нужно объяснять человеку где он ошибся, а не просто обзываться: ему то не понятно, раз он глупость написал
ГВ>>Не сочти за обиду, но видать, тебе мало приходилось объяснять другим их ошибки. Поверь, это крайне неблагодарное занятие. Тем более, когда ошибающийся даже слушать никого не хочет.
FDS>Согласен. Самое плохое, что это ещё и скучно — вот это уже препятствие.

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

ГВ>>По моим наблюдениям, в среднем для того, чтобы разобрать ошибки, которые отдельные деятели могут уместить в небольшом абзаце, нужно потратить примерно раза в три больше букв и раз в десять больше времени. Это может быть интересно, если такой разбор представляет определённую ценность для самого разбирающего. В ином случае... На этот счёт есть восточная поговорка, которая звучит примерно так (есть вариации): "Иной дурак за час столько наговорит, что мудрец и за сто лет не разобрать".

FDS>Не обязательно разбирать всё.

А если не разобрать всё или наиболее значимые моменты, то посыплются обвинения, что, мол, "по сути я хотел сказать совсем не то", "ты вырвал высказывания из контекста" и на сколько фантазии хватит. Поэтому в идеале нужно сначала сформулировать (за автора!) то, что он хотел сказать, найти и описать ошибки в его изложении и только после этого что-то утверждать. Работёнка на самом деле — адская. Особенно, когда речь заходит о тонких моментах, вроде "создания впечатления" или апелляциях к примитивным стереотипам.

ГВ>>Но и оставлять глупости неоткомментированными тоже не хочется. Потому что иной колеблющийся может прочесть ахинею и принять её на веру. В итоге одним дураком станет больше, что не есть гуд.

FDS>Поэтому лучше не совершать глупость и пусть нестрого, но показать, что действительно написана глупость. А то скажешь "глупость", а тебе потом втык сделают и сам дураком себя чувствовать будешь, когда объяснять, что ты ничего не понял

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

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

B>>Это позволит повышать уровень абстракции, а это приведет к снижению количества логических ошибок. Причем к уменьшению на порядки по сравнению с тем количеством, которые сможет выявить компилятор на предыдущем уровне абстракции (сравните ассемблер и Java/C#).

FDS>Да, но как уровень абстракции связан с лексической минимальностью?

С лексической минимальностью — связан. Представьте себе, что Вы хотите говорить на русском языке, а синтаксис языка программирования навязывает Вам слова английского, причем их нельзя изменить или убрать, а употреблять их нужно ну очень часто. Ну например, навязывает употреблять артикли перед каждым существительным. Ну зачем Вам в русском языке артикли?

С синтаксической — тоже. Синтаксис должен быть минимальным дабы не акцентировать на нем внимание при работе. А главное, он должен ненавязчиво позволять вводить новые абстракции.

B>>А проверять всегда есть чего
B>>Представьте язык программирования, в котором можно описывать слова и оперировать ими. Определили мы конкретные существительные, глаголы, прилагательные (лексику) и составляем предложения из них. Но правила-то все-равно останутся: сказуемое (глагол) должно стоять после подлежащего (существительного), а определение (прилагательное) перед подлежащим, в предложении обязательно должно сказуемое ну и т.д. Проверяйте на здоровье. Вот

FDS>Это немного не то. Сдесь синтаксис и больше ничего. Никакой связи с семантикой.

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

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

VD>Еще раз. У регекстов нет возможности превратить их в черный ящик. Возможно если бы это было возможно, то и использование их было бы более обширно. Создали бы библиотеку стандартных регексов и пользовались бы ими по имени.
Гы-гы.

System.Web.UI.BaseParser.aspCodeRegex
System.Web.UI.BaseParser.aspExprRegex;
System.Web.UI.BaseParser.commentRegex;
System.Web.UI.BaseParser.databindExprRegex;
System.Web.UI.BaseParser.directiveRegex;
System.Web.UI.BaseParser.endtagRegex;
System.Web.UI.BaseParser.gtRegex;
System.Web.UI.BaseParser.includeRegex;
System.Web.UI.BaseParser.ltRegex;
System.Web.UI.BaseParser.runatServerRegex;
System.Web.UI.BaseParser.serverTagsRegex;
System.Web.UI.BaseParser.tagRegex;
System.Web.UI.BaseParser.textRegex;

System.Web.Util.Wildcard.backslashRegex;
System.Web.Util.Wildcard.commaRegex;
System.Web.Util.Wildcard.metaRegex;
System.Web.Util.Wildcard.questRegex;
System.Web.Util.Wildcard.slashRegex;
System.Web.Util.Wildcard.starRegex;

...