Насколько важен синтаксис языка? - Философия программирования

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

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

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

VD>Приведи текст исключения.

После тридцатого прочтения текста я, наконец, понял, что программе нужна сборка Nemerle.dll, а её нет в GAC. Тупею, тупею...

Всё заработало, спасибо.

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

VD>В документации все не опишешь. Примеры там есть в общем-то. Но ёжику понятно, что на все вопросы не отвитешь. Так что проще задавать вопросы на форумах.

Видать, у нас принципиально различные точки зрения. Для меня проще сделать вывод из документации, а если уж совсем плохо — тогда на форум. А в Nemerle практически только примеры и есть. Номальный файл описания очень помогает всё-таки, больше чем форум или разрозненная справка. (ну, не для спора сказано). Разве там есть описание обработки синтаксического дерева?

FDS>>кода проблемы появляются

, а со спецификацией я бы сам разобрался

VD>Думаешь у нас форум по донету лишний? На нем каждый день море вопросов. А ведь и по шарпу и по дотнету есть все спецификации.

Не видел ещё не одного вопроса по C#, на который нельзя было бы ответить после внимательного чтения спецификации (на это, правда, не все способны). Форумные вопросы в принципе должны возникать только от нестандартной реализации и багов (по крайней мере, что касается C#).

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

VD>В Дельфи перед ними можно объявить только параметры внешних функций. В общем, это вещи не сравнимые.

Не дошло. В Delphi можно так

procedure proc1;
var
  C1, C2: integer;

  procedure proc2;
  begin
    C1 := C2;
  end;
....

Что можно сделать в Nemerle круче? В примерах там вроде всё то же

Опять же, в каком документе это описано?

Этот язык, наверное, в несколько раз круче, чем я о нём думаю, и всё только потому, что документация чёрт знает как оформлена. Эх, ну почему они не из Microsoft?!

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

)

VD>А что не так?

С вашей интеграцией не так, что нужна последняя версия VSIP SDK. Насколько я понимаю, по Dial-Up её не скачать.

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

Предупреждение:

Warning 1 There is a circular reference involving the import of file "K:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets". This file may have been imported more than once, or you may have attempted to import the main project file. All except the first instance of this file will be ignored. K:\Program Files\Nemerle\Nemerle.MSBuild.targets 193 13 ClassLibrary1

Тут до меня вообще мало что доходит

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

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

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

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

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

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

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

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

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

Думаю, если эти проблемы обычно не возникают, то правила несколько иные. Видимо они слишком неформальны, что бы их описать.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

VD>>>>Это возможно, но не элементарно.

ANS>>>В каком-то частном случае — возможно. В общем — нет.

FDS>>Приведите мне такой случай для языка со строгой статической типизацией.

ANS>_Ты_ и Влад сказали, что это возможно вы и приводите.

Я должен приводить доказательство. А вы должны привести один единственный пример, подтверждающий, что вы правы. Согласитесь, это намного проще.

Ну, доказать не доаказать, но логика проста. Если язык статически типизирован, то мы можем определить, что в некоторую переменную записывается значение некоторого блока, так как иначе нужно допустить, что мы не знаем, что мы записываем в переменную. А мы это должны знать так как:
1. Язык статически типизирован и нельзя просто сослаться на некоторый участок памяти, который содержит неизвестный нам объект
2. Сам блок описывается в этом же методе
Ну, теорема доказана

Рискну предположить, что в Microsoft для такой верификации инструменты были уже много лет.

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

FDS>Рискну предположить, что в Microsoft для такой верификации инструменты были уже много лет.

А причём тут МС, собственно?

Другим слабо?

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

S>Здравствуйте, Дарней, Вы писали:
Д>>лучще приведи пример кода, где не жить не быть — но без нелокальных возвратов обойтись нельзя
S>Да нет такого кода. Но смысл я понял.
S>Там, где дотнету приходится делать два метода: FindFirst и Apply, смоллток обходится одним. Просто потому, что решение о том, продолжать итерацию или выйти "изо всего" принимается в "делегате".
S>В более сложных случаях давайте вспомним, как мы делали поиск по дереву. Конечно же рекурсия; и конечно же надо было обязательно оборудовать ее проверкой на продолжение и сохранением найденного элемента...
S>Если бы нелокальный возврат существовал бы в дотнете, это работало бы как-то так:
S>

S>public interface IRecursible<T>: IEnumerable<IRecursible<T>>;

S>public static void ForEach<T>(T root, Action<T> action)
S>  where T: IRecursible<T>
S>{
S>  action(root);
S>  foreach(T child in root)
S>      ForEach(child, action);
S>}
S>

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

S>

S>class MyItem: IRecursible<MyItem>
S>{
S>  // тривиальная реализация интерфейса поскипана
S>    public string Name;
S>}

S>public static PrintAll(MyItem root)
S>{
S>  ForEach(root, delegate(MyItem t) { Console.WriteLine(t.Name);});
S>}
S>

S>Тривиально, не правда ли? А теперь давайте кого-нибудь найдем:

S>

S>public static MyItem FindFirstStartingWith(MyTtem root, string start)
S>{
S>  ForEach(root, 
S>        delegate(MyItem t) 
S>        { 
S>            if (t.Name.StartsWith(start))
S>                super return t;
S>        } 
S>    );
S>}
S>

S>Здесь я применил "новый" оператор super return, чтобы намекнуть на нелокальный возврат (в отличие от обычного return, который все равно приведет к ошибке компиляции из-за несовпадения типа получившегося анонимого делегата с Action<MyItem>).
S>На что стоит обратить внимание?

Банально

public static void ForEach<T>(T root, Action<T> action)
where T: IRecursible<T>
{
action(root);
CRT Child = root.LoadFromDataBaseChildAndLock();
foreach(T Child in root)
{

ForEach(Child, action);
}
Child.Unlock();
}
S>[/c#]

и уже ошибка

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

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

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

N>>>В Smalltalk тоже нельзя прервать выражение.
N>>>Например:
N>>>

N>>>SomeClass>>foo
N>>>|a b|
N>>>    a := self bar. "возвращает что-то типа [:x | ^x + 42]"
N>>>    b :=  a value. "сюда мы уже не попадем, потому что предыдущая строка вызовет исключение"
N>>>    ...
N>>>

N>>>При попытке вызова этого метода в любезно предложенном отладчике мы увидим следующее (VisualWorks):
N>>>

N>>>cannotReturn: value 
N>>>    "Raise a signal which means that the reciever attempted to return 

N>[code]
N>>>    (with the supplied value), but its sender cannot be returned into 
N>>>    (e.g. sender is nil, probably because the receiver already returned). 
N>>>    This message is sent by the execution machinery (the VM or some
N>>>    execution simulator such as a debugger)."

N>>>    CannotReturnError new
N>>>        context: self;
N>>>        parameter: value;
N>>>        raise
N>>>

FDS>>Не дошло, почему исключение было вызвано? Можно прокомментировать подробнее?

N>Исключение возникает при попытке выполнения оператора возврата внутри блока, помещенного в переменную a (в моих комментария выше есть ошибка, я исправился здесь). Именно, приведенное выше сообщение cannotReturn: находится на вершине стека, а ниже лежит оператор возврата из блока. При этом в cannotReturn: в переменной self находится контекст метода bar, в котором sender=nil (это логично --- сообщение bar никто здесь не посылает), поэтому возврат из блока в данном случае вызывает исключение, а receiver --- собственно экземпляр класса SomeClass, которому послано сообщение foo.

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

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

FDS>Почему тогда эти супер успешные стартапы не на LISP?

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

Это раз.
Я имел в виду — что можно быть и не супер-успешным (и совершенно неизвестным), но хорошо себя чувствовать, это два

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

ГВ>И уж тем более не следует пренебрежительно относиться к тем, кто этими скучными задачами не занимается.

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

Например:

В мейнстриме, в основном, люди примитивные и ограниченные.

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

Я вот ничего оскорбительного в его словах не вижу

А вот простое отсутствие поклонения перед приобщенными к высшим таинствам — это уже пренебрежение?

Я чего-то не видел пока, чтобы кто-то вышел и прямомо сказал "Лисп — язык чисто для тунеядцев, нормальной работой заниматься они просто не хотят, вот и рисуют скобочки". Конечно, человека, заявляющего, что, например, "C# — исключительно для дебилов, ничего путного на нем сделать нельзя", люди, которые постоянно работают на C# — и которые видели удовольствие заказчиков от внедренных систем — попинают его непременно, и весьма жестко. Но ведь сам напросился, разве нет?

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

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

V>>>AutoCAD когда-то был весьма скромной программой. Им бы никто не дал хорошую расширяемую скрипт-машину по вменяемой цене на момент выхода, но зато написать интерпретатор Lisp-а способен даже студент-старшекурсник. (Примечание, VBA-среда появилась там уже в версиях, близких к 10-й, когда она стала вполне доступной по цене и наконец-то не такой уж глюкавой. Да и еще железки возмужали настолько, что стали адекватно переносить запуск среды редактирования VBA-макросов)

FDS>>Да, я сам пользовался AutoCAD, но какие преимущества даёт САМ ЛИСП, а не его лёгкость написания? Мы же говорим про программирование на ЛИСП, а не про его написание. С этим никто не спорит (хотя, что знает, кто знает)

К>Ты не с той стороны смотришь, тебе как пользователю автокада глубоко пофигу на чём там что написано — лишь бы работало, а вот если бы ты был автором — было бы совсем иначе

Это вы не поняли: ведь AutoCAD не на лисп написан. Это скрипты для AutoCAD пишутся на ЛИСП и мне, как пользователю это не всё равно, потому что скриптовый язык я должен знать.

К>А в данном топике важнее как раз точка зрения программиста как автора.

Полностью согласен.

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

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

FDS>>При этом подразумевается, что только у "плохих" есть предприимчивость

Д>почему?

Потому что такой пример. Хороший программист с предприимчивостью — это редкость.

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

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

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

FDS>>>Да, я сам пользовался AutoCAD, но какие преимущества даёт САМ ЛИСП, а не его лёгкость написания? Мы же говорим про программирование на ЛИСП, а не про его написание. С этим никто не спорит (хотя, что знает, кто знает)

К>>Ты не с той стороны смотришь, тебе как пользователю автокада глубоко пофигу на чём там что написано — лишь бы работало, а вот если бы ты был автором — было бы совсем иначе

FDS>Это вы не поняли: ведь AutoCAD не на лисп написан. Это скрипты для AutoCAD пишутся на ЛИСП и мне, как пользователю это не всё равно, потому что скриптовый язык я должен знать.

Вроде бы тут на рсдн на "вы" особо не принято

И сколько пользователей видела автокада, хоть бы кто-нибудь на нём скрипты писал

Но вот что кроме удобства написания (у тебя "лёгкости") ты пытаешься найти я так и понять не могу...
Задача хорошего языка — легко и удобно выражать мысли программиста так, чтобы их понимал компьютер. Или у тебя есть какие-то другие идеи?

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

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

ГВ>>>

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

Д>>Ну так привел бы ссылки на свои проекты, список научных публикаций и так далее. Чтобы, так сказать, придать весомость своим словам. В чем проблема то?
Д>>А вместо этого какие-то мутные аллегории про мышей, зерно и так далее. Не понимаю

G>ИМХО, это был еще вежливый ответ на вопрос, заданный в хамском стиле...

Нечего было "пальцы в бабочку" загибать. Так что...

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

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

ГВ>Так что, при жизни к учёному нужно относиться пренебрежительнее, чем к грызуну?

Вот как же ни ай-яй-яй!
Вроде еще в школе преподают, что нельзя скалыдвать (и сравнивать) стулья и яблоки.

Этак я могу сказать, что ВАЗ-шестерка — легко разгоняется до 120км/ч, а вот Субару-Импреза — потребляет бензин.

Таким образом шестерка — явно лучше, потому что она — ездит, а Субару-Импреза — плохая, потому что одни расходы на бензин.

Еще можно сравнить экскаватор, который за день прогопает огромную траншею (и она останется!) и самолет, который слетает в Самару и обратно (таким образом — ничего не сделает — он как был утром в Москве, так и будет там же вечером). А экскаватор — гораздо лучше, его канава осталась!

З.Ы.
И эти люди запрещают мне ковыряться в носу! (с) Анекдот

Как ты думаешь, почему считается некорректным приём дискуссии, называемый "апелляцией к опыту"? Никогда не задумывался?

Некорректные сравнения — куда как более грязный прием

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

FDS>>>При этом подразумевается, что только у "плохих" есть предприимчивость

Д>>почему?

FDS>Потому что такой пример. Хороший программист с предприимчивостью — это редкость.

Совершенно согласен, просто воте если взять что хороших программистов 1%, и хороших предпринимателей 1% (цифры с потолка), то вероятность совпадения получается 0,01%, а плохого программиста и хорошего предпринимателя 0,99%.
Хотя всё это не совсем корректные умозаключения (возможна корреляция и т.п.)

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

VK>Есть как минимум еще один такой мега-язык, называется Inform 7. Это DSL для создание игр в жанре interactive fiction(типа Adventure, Zork, итд).

Рассказал другу про этот язык, пишет:

17:58:23: вот это я понимаю язык
17:58:34: писал книгу а по ней игра сгенирилась
17:59:01: а потом еще сделают плагинчик и она будет генерить фильм и сразу мультсериал

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

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

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

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

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

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

Да, но где же здесь связь с лексической минимальностью? Разве ввести в C# процедуру сложнее, чем в ЛИСП или в другом языке?
int Func(int arg1, int arg2) {...} или (define (Func arg1 arg2) (...))

Неудачный синтаксис и минимальность ключевых слов не одно и то же.

B>>>А проверять всегда есть чего

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

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

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

Класс — это уже новое слово, и процедура то же.

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

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

FDS>>Рискну предположить, что в Microsoft для такой верификации инструменты были уже много лет.

К>А причём тут МС, собственно?

К>Другим слабо?

Это я пример привёл.

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

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

Не знаю, поняли ли Вы меня, но я Вас точно не понял. Если не сложно, сформулируйте вопрос иначе, или напишите пример.

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

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

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

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

FDS>>>>Да, я сам пользовался AutoCAD, но какие преимущества даёт САМ ЛИСП, а не его лёгкость написания? Мы же говорим про программирование на ЛИСП, а не про его написание. С этим никто не спорит (хотя, что знает, кто знает)

К>>>Ты не с той стороны смотришь, тебе как пользователю автокада глубоко пофигу на чём там что написано — лишь бы работало, а вот если бы ты был автором — было бы совсем иначе

FDS>>Это вы не поняли: ведь AutoCAD не на лисп написан. Это скрипты для AutoCAD пишутся на ЛИСП и мне, как пользователю это не всё равно, потому что скриптовый язык я должен знать.

К>Вроде бы тут на рсдн на "вы" особо не принято

К>И сколько пользователей видела автокада, хоть бы кто-нибудь на нём скрипты писал

Мы писали, когда учили

К>Но вот что кроме удобства написания (у тебя "лёгкости") ты пытаешься найти я так и понять не могу...

Её и пытаюсь найти

К>Задача хорошего языка — легко и удобно выражать мысли программиста так, чтобы их понимал компьютер. Или у тебя есть какие-то другие идеи?

Именно такая задача и есть. Легко и удобно, для программиста, естественно

	От:	Gadsky
	Дата:	08.09.06 10:02
	Оценка:

От:	FDSC	consp11.github.io блог
Дата:	08.09.06 10:09
Оценка:

От:	FDSC	consp11.github.io блог
Дата:	08.09.06 10:29
Оценка:

От:	FDSC	consp11.github.io блог
Дата:	08.09.06 10:34
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	08.09.06 10:37
Оценка:

	От:	fmiracle
	Дата:	08.09.06 10:55
	Оценка:	34 (3) +2

От:	ie	http://ziez.blogspot.com/
Дата:	08.09.06 11:07
Оценка: