MIT переходи со схемы на... - Философия программирования

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

EC>>>>Но ты даже, если и согласен со мной, то всё равно это не признаешь, но я на это и не рассчитываю.
WH>>>А теперь поднимись по ветке выше и увидишь что eao197 наезжает на возможность менять синтаксис...
E>>Тогда причем здесь EvilChild?
WH>Вот и я думаю зачем он влез?

То, что он влез в разговор с PhantomIvan вовсе не означает, что ему можно приписывать чужие слова и чужие мнения.

WH>>>Просто тут утверждают что возможность менять синтаксис усложняет код.
E>>Усложняет восприятие кода и, соответственно, его сопровождение.
E>>Имхо, "усложнение кода" и "усложнение восприятия кода" -- это разные вещи, поскольку первое относится к моменту написания, а второе к моменту чтения.
WH>Правда?

Воистину так.

WH>Ты действиельно думаешь что обход коллекции при помощи foreach читать труднее чем тоже самое сделаное при помощи рекурсивных вложенных функций?

Смотря какой foreach. Кстати, а откуда взялись рекурсивные вложенные функции? Если это способ реализации макроса foreach в Nemerle -- то это проблемы Nemerle. Для многих языков foreach это базовая конструкция. И если сравнивать некоторые foreach-и с простыми for-ами, то еще не всегда можно сделать однозначный вывод в пользу foreach-а (скажем решение задачи о расположении N ферзей на шахматной доске):

  def placeQueens(k: int): List[List[int]] =
    if (k == 0) List(List())
    else {
      for {
          val queens <- placeQueens(k - 1)
          val column <- List.range(1, n + 1)
          isSafe(column, queens, 1) }
        yield column :: queens
    }

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

join(
  spawn { producerThread( q, MESSAGES ) },
  spawn { consumerThread( q ) } )

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

def join( threads: Thread* ) {
  for( val t <- threads ) t.join
}

и к

def spawn( body: => unit ) = new Thread {
  start
  override def run = body
}

а оттуда к классу java.lang.Thread и к знаниям о том, как {bla-bla-bla} превращаются в unit.
Между тем более длинная запись:

val producer = new ProducerThread( q, MESSAGES );
val consumer = new ConsumerThread( q );

producer.start
consumer.start

producer.join
consumer.join

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

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

В общем, стандартная дилемма Reuse vs. Compression, только при условии, что макросы делают сжатие более плотным.

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

WH>>Ты действиельно думаешь что обход коллекции при помощи foreach читать труднее чем тоже самое сделаное при помощи рекурсивных вложенных функций?
E>Смотря какой foreach.
Обычный foreach.
E>Кстати, а откуда взялись рекурсивные вложенные функции? Если это способ реализации макроса foreach в Nemerle -- то это проблемы Nemerle.
Почему проблема? Ведь если использовать foreach то программист их не видит. А что там делает компилятор это дело десятое.
E>Для многих языков foreach это базовая конструкция.
Это не дает им никаких преймуществ. Те совсем никаких.
E>И если сравнивать некоторые foreach-и с простыми for-ами, то еще не всегда можно сделать однозначный вывод в пользу foreach-а (скажем решение задачи о расположении N ферзей на шахматной доске):
А это уже форменная демагогия. Нигде не утверждалось что foreach хорошо работает ВСЕГА. Так что не нужно опровергать то что ты сам толькочто придумал.

E>К тому же я говорю о более сложных чем foreach конструкциях. Например, запись:
хъ
E>достаточно компактна и удобна при написании. Только вот чтобы понять ее нужно гораздо больше усилий. Поскольку она требует возврата к:
Точно также можно наехать на любую конструцию языка высокого уровня... for конечно удобен но для того чтобы его понять нужно прочитать книжку по С... толи дело куча jmp, jnz... все просто и понятно...
Короче сворачивай демагогию.

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

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

WH>Короче сворачивай демагогию.

Как обычно, все свелось к генеральной линии партии, п.3.
Так бы сразу и сказал.

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

WH>>Короче сворачивай демагогию.
E>Как обычно, все свелось к генеральной линии партии, п.3.
E>Так бы сразу и сказал.
Ну а что делать если на вопрос:

Ты действиельно думаешь что обход коллекции при помощи foreach читать труднее чем тоже самое сделаное при помощи рекурсивных вложенных функций?

Получаю пространные рассуждения про то что foreach плохо подходит для:

решение задачи о расположении N ферзей на шахматной доске

И как это еще можно назвать кроме как демагогия?

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

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

WH>Ну а что делать если на вопрос:
WH>

WH>Ты действиельно думаешь что обход коллекции при помощи foreach читать труднее чем тоже самое сделаное при помощи рекурсивных вложенных функций?

WH>Получаю пространные рассуждения про то что foreach плохо подходит для:
WH>

решение задачи о расположении N ферзей на шахматной доске

WH>И как это еще можно назвать кроме как демагогия?

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

Демагогия -- отождествление всех возможных макросов с единственным макросом foreach. То, что в Nemerle у человека есть выбор только между рекурсивными функциями обхода коллекций и макросом foreach, который эти функции от программиста прячет -- это частный случай. А вот когда кто-нибудь сделает свой макрос async под названием remote_async, то будет ли это для читателя кода более понятно, о какой конкретно remote идет речь?

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

E>Демагогия -- это твой вывод о том, что foreach плохо подходит для решения задачи о расположении ферзей. Я такого не говорил. Я сказал, что между некоторыми foreach-ами и некоторыми элементарными for-ами сложно сделать однозначный вывод о лучшей читабельности. Т.е. приписывание собеседнику собственных мыслей.
Может у меня плохо с восприятием реальности (а может ты плохо выражаешься) но ИМХО это одно и тоже.
Те раз foreach подходит плохо то возможно другое средство использовать лучше

E>Демагогия -- отождествление всех возможных макросов с единственным макросом foreach. То, что в Nemerle у человека есть выбор только между рекурсивными функциями обхода коллекций и макросом foreach, который эти функции от программиста прячет -- это частный случай. А вот когда кто-нибудь сделает свой макрос async под названием remote_async, то будет ли это для читателя кода более понятно, о какой конкретно remote идет речь?
Демагогия это когда ты высасываешь из пальца какието гепотетические макросы писанные какимито индусами которые делают черт знает что.
Такми темпами можно докатится до того что библиотеки это плохо ибо работа функции может быть не очивидна исходя из ее названия.

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

E>  def placeQueens(k: int): List[List[int]] =
E>    if (k == 0) List(List())
E>    else {
E>      for {
E>          val queens <- placeQueens(k - 1)
E>          val column <- List.range(1, n + 1)
E>          isSafe(column, queens, 1) }
E>        yield column :: queens
E>    }
E>

Это простой for? Это тот for который есть в Scala, который как раз аналог foreach в Nemerle и имеет весьма отдаленное отношение к

for(statement1;expr2;statement2) body

который в Немерле в отличие от Скалы есть.

На Немерле твой пример запишется еще короче:

  def placeQueens(k) {
    | 0 => [[]]
        | _ =>
            $[ column :: queens |
                 queens in placeQueens(k-1),
                 column in $[1..n+1],
                 isSafe(column,queens,1) ]
  }

И заметь: ни одного указания типа

.

E>К тому же я говорю о более сложных чем foreach конструкциях. Например, запись:
E>

E>join(
E>  spawn { producerThread( q, MESSAGES ) },
E>  spawn { consumerThread( q ) } )
E>

E>достаточно компактна и удобна при написании. Только вот чтобы понять ее нужно гораздо больше усилий.
Первый раз да. Потом если часто используется привыкаешь.

E> Поскольку она требует возврата к:
E>

E>def join( threads: Thread* ) {
E>  for( val t <- threads ) t.join
E>}
E>

E>и к
E>

E>def spawn( body: => unit ) = new Thread {
E>  start
E>  override def run = body
E>}
E>

E>а оттуда к классу java.lang.Thread и к знаниям о том, как {bla-bla-bla} превращаются в unit.

{bla-bla-bla} превратились не в unit (что есть void в Scala), а в замыкание делегата (=> unit) (или void->void если в более привычных терминах).

E>Между тем более длинная запись:
E>

E>val producer = new ProducerThread( q, MESSAGES );
E>val consumer = new ConsumerThread( q );

E>producer.start
E>consumer.start

E>producer.join
E>consumer.join
E>

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

. Это то же самое если бы ты сказал: вот C — какие-то if, for — что это такое, какие там инструкции

. А ассемблерный листинг — сразу видно — jnz, jz, push, pop...

E>Если же сюда вмешаются еще и макросы, которые, к примеру, val развернут во что-нибудь хитрое, тогда без поллитры можно и не разобраться.
Умная IDE с показом по запросу развернутого тела макроса, мгновенной навигацией к определению и документации а также разумное наименование для макросов и хорошая документация к ним снимают эти проблемы. Встроенный for в Scala никак уж не проще для понимания чем макрос foreach в Nemerle.

E>В общем, стандартная дилемма Reuse vs. Compression, только при условии, что макросы делают сжатие более плотным.
Они поднимают уровень абстракции, так же как C поднимает уровнень абстракции по сравнению с ассемблером. Если выбирать хорошие абстракции проблем с их пониманием нет (по крайней мере у достаточно квалифицированного человека, другим их и в руки давать не стоит, им только VB и PHP, а лучше вообще в менеджеры

).

Ну и макросы — они ограниченного применения, в основном для фреймворков и стандартных библиотек.

Я пописал немного на Nemerle и пока стандартных макросов хватает. Желания написать новые пока особо нет (правда, есть одна идейка по расширению языка).

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

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

E>>Демагогия -- это твой вывод о том, что foreach плохо подходит для решения задачи о расположении ферзей. Я такого не говорил. Я сказал, что между некоторыми foreach-ами и некоторыми элементарными for-ами сложно сделать однозначный вывод о лучшей читабельности. Т.е. приписывание собеседнику собственных мыслей.
WH>Может у меня плохо с восприятием реальности (а может ты плохо выражаешься) но ИМХО это одно и тоже.
WH>Те раз foreach подходит плохо то возможно другое средство использовать лучше

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

WH>Демагогия это когда ты высасываешь из пальца какието гепотетические макросы писанные какимито индусами которые делают черт знает что.

Так а какие в Nemerle есть языковые средства защиты от таких макросов и индусов?
Пока я вижу только одно такое средство -- язык Nemerle никем, кроме небольшой группы энтузиастов, не используется.

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

Можно и даже нужно. Поскольку есть объективные меры к повышению читабельности -- простой синтаксис, простая семантика, отсутствие неявных преобразований (типов, кода и пр.). Так вот я наблюдаю такой эффект: чем более свободный синтаксис (опускание скобок, опускание точек при вызове методов объектов), тем хуже становится при злоупотреблении этими возможностями. Макросы в этом смысле идут еще дальше. А вот языки со строгим синтаксисом (вроде Pascal, Modula, Eiffel или D (Оберон-а, к сожалению не знаю)) хоть и приводят к более многословным программам, но зато их читабельность не страдает от злоупотреблений с синтаксическим сахаром.

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

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

E>Но, с другой стороны, компактность уменьшает ее читабельность.
Далеко не всегда.

E>Так а какие в Nemerle есть языковые средства защиты от таких макросов и индусов?
Подключение макросов к проекту очень легко контролировать. И при аутсорсинге в индию можно просто прописать в контракте что нельзя подключать не стандартные макросы.
И посматривать как они проекты собирают... как только появляется ключик компилятора которым подключают макросы так

E>Можно и даже нужно. Поскольку есть объективные меры к повышению читабельности -- простой синтаксис, простая семантика, отсутствие неявных преобразований (типов, кода и пр.). Так вот я наблюдаю такой эффект: чем более свободный синтаксис (опускание скобок, опускание точек при вызове методов объектов), тем хуже становится при злоупотреблении этими возможностями. Макросы в этом смысле идут еще дальше. А вот языки со строгим синтаксисом (вроде Pascal, Modula, Eiffel или D (Оберон-а, к сожалению не знаю)) хоть и приводят к более многословным программам,
Тут у тебя логическая ошибка.
Макросы и опускание точек со сокобочками находятся в разных измерениях и путать их нельзя.

Грамотно написанный макрос как и грамотно написанная библиотека только улучшают читабельность, а плохо написанная библиотека (даже если она написана на обероне) ничуть не лучше чем плохо написанный макрос.

E>но зато их читабельность не страдает от злоупотреблений с синтаксическим сахаром.
За то их читабильность страдает от присутствия огромного синтаксического шума.

E>Но, я вижу, фанатам Nemerle об этом пока рано говорить. Вам, вероятно, надо столкнуться с индуским кодом на Nemerle.
Индусячий код на чем угодно (хоть на обероне) читать/править не возможно.

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

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

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

E>>>Демагогия -- это твой вывод о том, что foreach плохо подходит для решения задачи о расположении ферзей. Я такого не говорил. Я сказал, что между некоторыми foreach-ами и некоторыми элементарными for-ами сложно сделать однозначный вывод о лучшей читабельности. Т.е. приписывание собеседнику собственных мыслей.
WH>>Может у меня плохо с восприятием реальности (а может ты плохо выражаешься) но ИМХО это одно и тоже.
WH>>Те раз foreach подходит плохо то возможно другое средство использовать лучше

E>Ничего не одно и то же.
E>foreach хорошо подходит для решения этой задачи по таким показателям, как компактность, скорость и ресурсоемкость.
Наоборот, он может быть медленнее, чем те же итераторы на C++, которые часто сводятся к просто указателям.

E> С одной стороны, комактность уменьшает вероятность ошибки. Но, с другой стороны, компактность уменьшает ее читабельность.
Наоборот. Повышение уровня абстракции — положительно. В C куда проще совершить ошибку потому то очень многое приходится делать руками и никто тебя не контролирует. Больше кода — больше места для ошибки.
Если надо, то то что макрос нагенерировал всегда можно посмотреть (особенно легко это в IDE. Навел мышку — он показал).

E> И по этому показателю foreach хуже.

О да,

foreach(e in myArray)

куда нечитабельнее

for(vector<int>::const_iterator it = myArray.begin(),
                                                                eit = myArray.end();
        it != eit;
        ++it)

WH>>Демагогия это когда ты высасываешь из пальца какието гепотетические макросы писанные какимито индусами которые делают черт знает что.

E>Так а какие в Nemerle есть языковые средства защиты от таких макросов и индусов?
1) Макросы обязаны быть в отдельной подключаемой сборке. Доступ к ее исходному коду естественно можно отслеживать и контролировать.
2) Так как Немерле в отличие от динамических языков обладает строгой системой типов если макрос сгенерирует неверный код это тут же вылезет.

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

E>Можно и даже нужно. Поскольку есть объективные меры к повышению читабельности -- простой синтаксис, простая семантика, отсутствие неявных преобразований (типов, кода и пр.).
+10.

Здесь как раз динамика выглядит очень плохо.
Как пишет Девид Поллак здесь

I've also had the insight that using Lists of 'case classes' is a nice way to do variable length, named parameters in a type-safe, more clearly documented manner. A lot nicer than the Rails "I guess I have to look at the source code to figure out what parameters this method's taking this week."

И Скала с неявным приведением к замыканиям в этом смысле немного путает.

Ну а некоторые и J любят.

E>Так вот я наблюдаю такой эффект: чем более свободный синтаксис (опускание скобок, опускание точек при вызове методов объектов), тем хуже становится при злоупотреблении этими возможностями.
Именно. Кто бы говорил (тот кто пишет на Руби).

E> Макросы в этом смысле идут еще дальше.
Макросы C — о да! Макросы Немерле — нет.
В макросах Немерле ты можешь контролировать все до мельчайших подробностей и выводить сообщения об ошибках.

E> А вот языки со строгим синтаксисом (вроде Pascal, Modula, Eiffel
,С#, Nemerle

E>или D
D со строгим

:
1) А небезопасные unionы?
2) А никакого контроля над указателями, которые можно получить даже для GC объектов.
3) Там как раз обсуждают сейчас стоит ли отменить неявное преобразование массивов в указатели;
4) А возможность всегда получить UB возвратив делегат из функции
Re[3]: D и замыкания.
5) А отсутствие сообщений об ошибок даже для самых частых из них:
здесь.
6) Наконец, шаблоны D весьма мощны, можно многое накрутить, так что твое замечание и для D годится.

E> хоть и приводят к более многословным программам, но зато их читабельность не страдает от злоупотреблений с синтаксическим сахаром.
В Nemerle вполне строгая семантика. Компилятор даже не даст тебе просто так проигнорировать если функция возвращает значение и ты его ничему не присвоил.

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

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

L>Я действительно не знаю КОП. Дай линки почитаю подробнее

Думаю, что знаешь — твой основной рабочий инструмент его поддерживает

now playing: Autechre — Goz Quarter

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

PI>>CF.NET не поддерживается
Таки не поддерживается. Валится при попытке компиляции.
Создал файлик compile.bat по аналогии с компиляцией для C#
Шарповый вариант успешно компилится.

@echo off

if "%NETCF_PATH%" == "" (
  set NETCF_PATH=C:\Program Files\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE)
                 
if DEFINED REF ( set REF= )

set REF=%REF% "-r:%NETCF_PATH%\MsCorlib.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.Data.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.Drawing.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.Messaging.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.Net.IrDA.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.Web.Services.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.Windows.Forms.DataGrid.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.Windows.Forms.dll"
set REF=%REF% "-r:%NETCF_PATH%\Microsoft.WindowsCE.Forms.dll"
set REF=%REF% "-r:%NETCF_PATH%\System.Xml.dll"

ncc -nostdlib  %REF% %*

В качестве простейшего приложения взял пример из Tutorials And Examples, который поставляется с Немерле.


using System.Drawing;
using System.Windows.Forms;
 
class MyFirstForm : Form {
   public static Main() : void {
      Application.Run(MyFirstForm());
   }
}

Приложение куда уж проще.

Запускаю на компиляцию.

C:\Projects\Nemerle\Mobile>compile.bat MyFirstForm.n
<[01;31merror<[0m: internal compiler error: got some unknown exception of type S
ystem.TypeLoadException: Неправильное использование атрибута Runtime Impl.
   в System.Reflection.Assembly.GetExportedTypes()
   в Nemerle.Compiler.LibraryReferenceManager.LoadTypesFrom(LibraryReference lib
)
   в Nemerle.Compiler.LibraryReference..ctor(Assembly assembly)
   в Nemerle.Compiler.LibraryReferenceManager.AddAssembly(Assembly assembly)
   в Nemerle.Compiler.LibraryReferenceManager.AddLibrary(String name)
   в Nemerle.Compiler.Passes._N_static_proxy50438.apply_void(String _N_sp_parm50
445)
   в Nemerle.Collections.List.Iter['a](list`1 l, FunctionVoid`1 f)
   в Nemerle.Compiler.Passes.LoadExternalLibraries()
   в Nemerle.Compiler.Passes.Run()
   в Nemerle.CommandlineCompiler.MainClass.main_with_catching()

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

... << RSDN@Home 1.2.0 silent >>

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

E>>foreach хорошо подходит для решения этой задачи по таким показателям, как компактность, скорость и ресурсоемкость.
АХ>Наоборот, он может быть медленнее, чем те же итераторы на C++, которые часто сводятся к просто указателям.

Про C++ здесь вообще речи не было.

АХ>2) Так как Немерле в отличие от динамических языков обладает строгой системой типов если макрос сгенерирует неверный код это тут же вылезет.

Речь идет не о проверке кода, а о его понятности.

E>>Так вот я наблюдаю такой эффект: чем более свободный синтаксис (опускание скобок, опускание точек при вызове методов объектов), тем хуже становится при злоупотреблении этими возможностями.
АХ>Именно. Кто бы говорил (тот кто пишет на Руби).

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

E>>или D
АХ>D со строгим

:
АХ>1) А небезопасные unionы?
АХ>2) А никакого контроля над указателями, которые можно получить даже для GC объектов.

Какое отношение это имеет к синтаксису?

АХ>3) Там как раз обсуждают сейчас стоит ли отменить неявное преобразование массивов в указатели;

Верной дорогой идут товарищи.

АХ>4) А возможность всегда получить UB возвратив делегат из функции
АХ>Re[3]: D и замыкания.

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

АХ>5) А отсутствие сообщений об ошибок даже для самых частых из них: здесь.

Обычная проблема роста. Язык-то даже еще не зарелизен.

АХ>6) Наконец, шаблоны D весьма мощны, можно многое накрутить, так что твое замечание и для D годится.

Годится. Потому мне и не понравилось во что D превращается.

АХ>В Nemerle вполне строгая семантика. Компилятор даже не даст тебе просто так проигнорировать если функция возвращает значение и ты его ничему не присвоил.

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

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

E>>Но, с другой стороны, компактность уменьшает ее читабельность.
WH>Далеко не всегда.

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

E>>Так а какие в Nemerle есть языковые средства защиты от таких макросов и индусов?
WH>Подключение макросов к проекту очень легко контролировать. И при аутсорсинге в индию можно просто прописать в контракте что нельзя подключать не стандартные макросы.
WH>И посматривать как они проекты собирают... как только появляется ключик компилятора которым подключают макросы так

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

WH>Макросы и опускание точек со сокобочками находятся в разных измерениях и путать их нельзя.

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

WH>Грамотно написанный макрос как и грамотно написанная библиотека только улучшают читабельность, а плохо написанная библиотека (даже если она написана на обероне) ничуть не лучше чем плохо написанный макрос.

+1
Но в библиотеках таки концы искать проще, особенно когда ее исходники не доступны. В статически типизированных языках хотя бы видно, что функция возвращает. А вот во что макрос код преобразует? Ведь в Nemerle, если не ошибаюсь, макросы могут быть в скомпилированном виде -- как тогда концы искать?

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

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

E>Так вот и я думаю, что когда макросы в Nemerle являются всего лишь инструментами разработчика языка, то это одно дело. Тогда получается типичная микроядерная архитектура. Но если макросы отдаются в свободное владение пользователям языка, тогда это уже не столько достоинство, сколько лишняя головная боль.
Если пользователь грамотный то это скорее избавление от боли. У меня были случаи когда макросы были ну очень нужны... а их небыло

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

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

E>+1
E>Но в библиотеках таки концы искать проще, особенно когда ее исходники не доступны. В статически типизированных языках хотя бы видно, что функция возвращает. А вот во что макрос код преобразует? Ведь в Nemerle, если не ошибаюсь, макросы могут быть в скомпилированном виде -- как тогда концы искать?
Небольшой отчет о сделанной работе
Там в конце есть картинка с отетом на твой вопрос.

E>Резюмируюя: макросы как инструмент для разработчиков компилятора -- да сколько угодно. А вот макросы как еще одна фича для пользователей языка мне не нравится.
А мне нравится.

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

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

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

Ужас. А во что он раскроется-таки? И если макрос какой-то вроде async?

WH>А мне нравится.

Вот в том-то и дело, что тебе нравится, а мне -- нет

Вот и весь итог

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

E>Резюмируюя: макросы как инструмент для разработчиков компилятора -- да сколько угодно. А вот макросы как еще одна фича для пользователей языка мне не нравится.

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

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

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

PI>кстати, как ФВП расшифровывается?
Функции высшего порядка.

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

L>>Т.е. поскольку на Немерле пишет всего лишь Влад и ещё четыре человека значит, что проблема именно в Немерле?

На Немерле пишут гораздо, больше, билив ми. Влад и еще четыре человека, кроме того что пишут на нем, еще и говорят о Немерле

L>>В общем, это тоже сплошной блаб.

PI>немерле очень молод, и с этим связана его непопулярность
PI>неприятие немерле рсдн-ом пугает
PI>одно из двух — либо тут собрались "маргиналы" (фанатики "маргинальных" языков), решающие весьма специфичные задачи,
PI>либо немерле обладает каким-либо концептуальным изъяном.
Давать любому желающему менять семантику языка -- Андрес Хелсберг на такое, к примеру, с шарпом никогда не пойдет. Концептуальный изьян один -- Немерле писали не Они

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

	От:	FR
	Дата:	01.12.06 12:44
	Оценка:	-2

От:	eao197	http://eao197.blogspot.com
Дата:	01.12.06 12:55
Оценка:	15 (2) +3 -2

	От:	WolfHound
	Дата:	01.12.06 14:06
	Оценка:	+2

От:	eao197	http://eao197.blogspot.com
Дата:	01.12.06 14:15
Оценка:	-1

	От:	WolfHound
	Дата:	01.12.06 14:55
	Оценка:	+2

	От:	Андрей Хропов
	Дата:	01.12.06 15:41
	Оценка:	28 (1) +1

	От:	EvilChild
	Дата:	01.12.06 18:12
	Оценка:	12 (1)

От:	IT	linq2db.com
Дата:	01.12.06 20:17
Оценка:	+1