OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 14 Октябрь, 2019 18:30

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 143 ]  На страницу Пред.  1, 2, 3, 4, 5, 6 ... 8  След.
Автор Сообщение
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 13:58 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Валерий Лаптев писал(а):
возрождение функциональщины и проникнивение ее в императивщину - это не просто некое поветрие, а именно некое развитие программирования?


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 14:23 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8180
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
Но не кажется ли вам, что сейчас возрождение функциональщины и проникнивение ее в императивщину - это не просто некое поветрие, а именно некое развитие программирования?
Честно скажу, не кажется. Оберон изначально язык синтетический, и все возможности такого рода там, в общем, открыты. Причем без потери изначального достоинства императивщины.

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

Но "профессиональным программерам", особенно "компьютерным гениям" надо же подтверждать свой профессионализм и особенно гениальность.
Вот и рождаются монстры на пустом месте. Был С++ -- надоедать стал. Теперь ФЯ.

"Суета и томление духа."


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 14:48 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Peter Almazov писал(а):
Но удивительно, что сторонник ФП (во всяком случае, не противник?), в распоряжении которого функции как переменные первого рода, лямбда-выражения и замыкания предлагает решать задачу с обработкой файла с помощью макросов! По-моему наглядная демонстрация части 2 высказывания viewtopic.php?p=35207#p35207 (ничего личного, у кого из нас нет дефектов).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 15:43 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 530
Откуда: Москва
Geniepro писал(а):
В Лиспе ФП -- побочное явление, там с помощью макросов можно реализовать любую известную человечеству парадигму программирования, хоть ФП, хоть ООП, хоть ЛП, хоть что...
Это сильно!
Да, видимо я неисправимый блаб-программист, т.к. для меня слова "макрос" и "отстой" практически синонимы :(


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 21:15 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Давайте конкретно, без высокопарных слов про понимание, мэйнстрим, и т.п. :wink:
У нас в системе есть конкретный элемент - FastMathParse
Fast, потому-что, в отличие от просто MathParse, он сначала компилирует строку "по-настоящему", и далее просто передает управление этому бинарному коду. Многократно, до вызова метода doMathStr.
Далее, в 99% случаев эта строка - просто константа времени исполнения (где-то я это уже читал :) ), а метод doMathStr просто не используется юзером.

Какие будут КОНКРЕТНЫЕ предложения в стиле модульного программирования :?:
Мне кажется правильным для такого случая делать вышеозначенную "компиляцию" в Compile-Time, и не иметь коды "компилятора" в целевой программе.
Кстати говоря, у нас FMP - не один с такими "потребностями", много где хочется писать коды времени компиляции... Меня давно этот вопрос мучает, по-большому счету-то...


P.S. Извините коллеги, но пока беседа напоминает мне древний анекдот
Цитата:
......
К: На чем вы ездите на работу?
С: на автобусе
К: А на чем вы ездите в театр?
С: на автобусе
К: А на чем вы ездите в гости?
С: на автобусе
К: А на чем вы ездите за границу?
С: не надо мне туда
К: А если вам туда надо, на чем вы ездите за границу?
С: не надо мне туда
К: А если беж вас там не обойтись, на чем вы ездите за границу?
С: на танке!!!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 21:37 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Galkov писал(а):
Какие будут КОНКРЕТНЫЕ предложения в стиле модульного программирования :?:
Мне кажется правильным для такого случая делать вышеозначенную "компиляцию" в Compile-Time, и не иметь коды "компилятора" в целевой программе.


Примерно так:

Код:
PROCEDURE CompileExpr (IN expr: ARRAY OF CHAR);
  VAR txt: TextModels.Model;
        ok: BOOLEAN;
BEGIN
  TextModels.dir.NewFromString("MODULE MySpecialModule; ... PROCEDURE ... " + compiledExpr + "END ... END");
  DevCompiler.CompileText(txt, 0, ok);
  ASSERT(ok, 100)
END CompileExpr;

PROCEDURE CallExpr (...): REAL;
  TYPE ExprProc = PROCEDURE (....): REAL;
  VAR item: Meta.Item;
        val: RECORD
          proc: ExprProc
        END;
        ok: BOOLEAN;
BEGIN
  Meta.Lookup("MySpecialModule", item);
  ASSERT(item.obj = Meta.modObj, 100);
  item.Lookup(procedureName, item);
  ASSERT(item.obj = Meta.procObj, 101);
  item.GetVal(val, ok);
  ASSERT(ok);
  RETURN val.proc(..)
END CallExpr;


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

Захочу, буду делать вставки в код специальными графическими объектами, в три строчки сделаю парсинг из кода этих объектов, вытаскивание из них макропараметров - и генерацию кода (хоть на их же место; хоть модулями же динамическими...) Захочу - эти графические объекты в коде будут содержать не текст, а схемы (типа Вашего HiAsma), и из них что-то будет порождаться.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 22:35 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья, извините, но то, что Вы сказали, выглядит примерно так: для определенного класса задач потребители (программисты) нашего "компилятора", создавая свою программу, требуют уже от своего пользователя иметь у себя на компе Flex+Bison
Хотя достаточно было бы запустить их у себя один раз.

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


Мне кажется, ее (идею надежности программирования) можно было бы развивать и без доведения до абсурда. Концепция визуальных сред типа ДРАКОН или HiAsm позволяют совместить надежность программирования и "пластелиновый" язык.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 22:39 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Погодите, уточните, что именно Вас беспокоит. Я не понимаю пока.

Генерируйте модуль на стороне разработчика. На стороне клиента выполняйте только вторую процедуру - Call. Динамическая загрузка - неотъемлемая часть современного рантайма.

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

Я и сказал "пофигу" в том смысле, что могу обеспечить это хоть в develop-time, хоть в use-time (так точнее, смысла в compile-time и run-time тут как раз мы не видим).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 22:49 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Да даже и не надо, если чисто develop-time, петрушки с загрузкой через Meta. Модуль импортируется статически, через IMPORT. А генерируется разработчиком запуском процедуры-генератора.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 23:02 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Galkov писал(а):
Концепция визуальных сред типа ДРАКОН или HiAsm позволяют совместить надежность программирования и "пластелиновый" язык.


Совершенно верно. То, что я называю САПРами.

Только САПР должен на что-то опираться.

Если создание таких сред традиционными средствами - целое событие, то поверх Оберона/ББ - это может быть весёлой работой, с быстрым результатом, с возможностью сделать это просто по конкретной нужде. Наконец, это не будет обособленный мирок, а ещё один компонент. Включающийся в интегральный эффект.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба и макросах
СообщениеДобавлено: Четверг, 01 Октябрь, 2009 23:58 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Погодите, уточните, что именно Вас беспокоит. Я не понимаю пока.

Генерируйте модуль на стороне разработчика
Опять же, именно эти Ваши слова относятся НЕ к Автору кодов конкретного элемента, а к программисту. О надежности работы которого мы как бы заботимся.
Мое понимание этой заботы - не говорить ему таковых слов. Обратите внимание, для других элементов тоже можно провести аналогичную "беседу". А под компиляцией можно понимать просто оптимизационные действия по превращению НКА в ДКА, что может быть употребимо не только при вычислении формулы.
Это если смотреть в суть вопроса, а не зацикливаться на деталях...
Элементарно все - действия, которые могут быть вычислены в Compile-Time - там и должны быть выполнены.
Именно там - мне не пофигу где, хотя и известно, сколько пофигистов породил мэйнстрим.
И при всем при этом, Автор уже элемента (назовем его модулем) понятия не имеет о не использовании метода doMathStr. Узнать это - это провести некий вычислительный процесс в Compile-Time, коды которого Автор и написал.


Илья Ермаков писал(а):
Динамическая загрузка - неотъемлемая часть современного рантайма.

Да даже и компилятор - один и на все случаи - особенно не утянет
Типичные слова представителя мэйнстрима.
Мы, разработчики инструмента, решили за вас, что это нечто - неотемлимая часть. Назвали свое решение самым современным. Да, это потребует неких затрат, но это же немного!!! :wink:
Ничего не перепутал ???


Илья Ермаков писал(а):
В том и прелесть, что компактность всего этого хозяйства позволяет иметь его на борту любого приложения, если нужно. Персональная ОС под приложение
Не убедительно. Меня больше интересуют embeded.
И особенно нравится (и получалось), когда буржуины используют ADSP за сотну вечнозеленых, решать ту же задачу на Atmega8 за 50 рублев.
И мне нужен инструмент (нет его у меня еще) помогающий в этой благородной цели.
В общем - другая система ценностей. Не усмотрел прелестей, затраты усмотрел.
Как-то так получилось, что в отличие от массы, охмуренной мэйнстримом, мне известны истинные цены некоторых задач. В байтах, тиках, и тп...


Илья Ермаков писал(а):
Только САПР должен на что-то опираться
Угу. И мне кажется, что без кодов исполнения в Compile-Time - не очень хорошо.
Не то, чтобы кажется... Пробовали.

Про легкую прогулку.
Возможно, что замена Дельфи на CP - будет и красивше.
Только хорошо - не будет. Не первый год плаваем.
Числодробительные задачи - может получиться хуже чем у бэйсиков...
Получаются страшные требования к оптимизации, и нет таких языков, которые это делают.
Например, уже мы должны решать call/inline для каждого метода. Именно решать, сделать всегда call и сказать: "и так сойдет" - уже не катит.
Другая фаза наступает. Если по Жванецкому, то: "Общим видом овладели, теперь подробности не надо пропускать"
Много их, блин, этих подробностей :|


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба и макросах
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 00:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Galkov писал(а):
Элементарно все - действия, которые могут быть вычислены в Compile-Time - там и должны быть выполнены.
Именно там - мне не пофигу где, хотя и известно, сколько пофигистов породил мэйнстрим.

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

Я же пояснил - команду CompileExpr можно вызывать при компиляции программы. Вписать её в последовательность команд компиляции проекта, например.

Илья Ермаков писал(а):
Типичные слова представителя мэйнстрима.
Мы, разработчики инструмента, решили за вас, что это нечто - неотемлимая часть. Назвали свое решение самым современным. Да, это потребует неких затрат, но это же немного!!! :wink:
Ничего не перепутал ???

Почему неотъемлемая? Хотите берите - хотите нет. Дело разработчика - сделать таким лёгким, чтобы можно было взять, если нужно.

Илья Ермаков писал(а):
Не убедительно. Меня больше интересуют embeded.

Меня и они тоже.

Илья Ермаков писал(а):
Угу. И мне кажется, что без кодов исполнения в Compile-Time - не очень хорошо.
Не то, чтобы кажется...

Да почему хоть без. См. выше.

Цитата:
Числодробительные задачи - может получиться хуже чем у бэйсиков...
Получаются страшные требования к оптимизации, и нет таких языков, которые это делают.
Например, уже мы должны решать call/inline для каждого метода. Именно решать, сделать всегда call и сказать: "и так сойдет" - уже не катит.

За счёт чего это прямо так и хуже? Вон Info21 сколько лет решает задачи..
Ну, нужно оптимизировать - соптимизируется. На Фортране куски написать, откомпилировать в DLL. И т.п.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба и макросах
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 00:52 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Я же пояснил - команду CompileExpr можно вызывать при компиляции программы. Вписать её в последовательность команд компиляции проекта, например
Ну вот опять....
А я пояснил, что лично я - не знаю какая схема будет у пользователя нашей среды. И рассказывать пользователю премудрости использования командной строки, супер-пупер дополнительных инструментов для целей оптимизации - ни малейшего желания. С учетом того, что теоретически, речь может идти не только о FMP, но и о некоторых других элементах, предположительно способных к оптимизации.

Блин, как сегодня работают: пишут скрит для некого язычка ориентированного на задачу, запускают Flex, Bison, собирают все вместе и снова компилируют, матюгаясь и преодолевая нестыковки.
Вы нам это предлагаете ??? И называете это надежным программированием ???
И все по причине того, что "макросы" - это от лукавого, оказывается.

Кстати говоря, типовой лексер, это больше 1000 строк кода. Работают - от силы 20 (обыкновенный табличный автомат). Чем занимаются остальные ???
Предпроцессинг - вычисления в Compile-Time


Илья Ермаков писал(а):
Дело разработчика - сделать таким лёгким, чтобы можно было взять, если нужно.
Ну я пока сомневаюсь, что какой-нибудь "вычислитель" (одна/две/три тупых формулы для конкретной инженерной задачи), сделанный на ББ как форма винды (дружественный интерфейс), можно будет передать пользователю как exe с кодовым сегментом в 1K.
Я ни в коем случае не утверждаю, что именно так надо абсолютно всегда. Утверждаю, что именно такова (с запасом) истинная цена задачи.
А еще, что достигнуть такого уровня оптимизации (начиная с компонентной разбивки) без исполнения в в Compile-Time - фигу получится.

А вы на это "исполнение" нападаете так усердно.
Да, надеюсь не надо объяснять, что перекладывать этот Compile-Time на пользователя - у меня и в мыслях не было.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба и макросах
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 00:59 

Зарегистрирован: Суббота, 12 Май, 2007 08:41
Сообщения: 102
Откуда: Беларусь, Минск
Peter Almazov писал(а):
Но удивительно, что сторонник ФП (во всяком случае, не противник?), в распоряжении которого функции как переменные первого рода, лямбда-выражения и замыкания предлагает решать задачу с обработкой файла с помощью макросов!

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

Евгений Темиргалеев писал(а):
После знакомства с языками Оберон-ветки я не признаю клепаемые языки, хакеры которых видят смысл жизни чтобы всунуть туда побольше фич. Неделя - новый релиз - версия +0.001, пара месяцев - часть старых фич становится "deprecated", год - версия A не совместипа с A+1 т.к. совсем старые "deprecated" фичи выкинули. Из этого неизбежно следует, что использовать их буду только под давлением непреодолимых обстоятельств.

Ну и причём здесь макросы? Ну вот ANSI Common Lisp вроде с 94 года не менялся, в Scheme вообще хз когда последний раз что-то новое включали. В Clojure, правда, относительно часто включают новые вещи из clojure.contrib, ну так и самому языку то официально 2 года всего, и стандарт ещё никто не закреплял.
Или вы думаете, что макросы делают новый язык? Ну да, внешне так и получается, лисперы вот всё время говорят, что синтаксиса в их языке вообще нет. Но по сути то ничего нового от макросов в языке не появляется, равно как и от новых пользовательских функций. deprecated макросы тоже вещь крайне редкая - после компиляции в бинариках никаких макросов нет, ниоткуда исключать их не недо и таскать старые библиотеки для поддержки старого же кода тоже нет необходимости. Ну и где вы здесь видите проблему "новых фич"? Я ещё раз говорю, вы сначала попрактикуйтесь в использовании, а потом уже говорите что эта фича сложная, а эта вообще не нужна.

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

Вы не "правильную" архитектуру строите, а архитектуру, котороя позволяет обойти ограничения языка вместо того, чтобы сделать напрямую то, что вам нужно. Вообще говоря, это очень глупо затрагивать проблемы архитектуры при обсуждении базовых средств языка - это вопрос другого порядка, но я всё же позволю себе один пример. В Java, как известно, нет нормального понятия модуля, такого, как есть в том же Обероне. При этом может возникнуть множество проблем, таких как сокрытие данных, и наоборот, межклассовое взаимодействие в одном пакете. Но ещё веселее, когда на Java вам нужно получить именно модульную функциональность, например, создать некий объект, который будет существовать в системе в единственном варианте. В Обероне у вас даже не возникнет вопросов - таким объектом ялвяется модуль! А что на Java? А там тоже нет проблем, есть же паттерны! Ну конечно же, кто не знает известнейший паттерн Singleton! Вот, вроде и решили проблему с единственным экземпляром. И что, теперь справляться с задачи модульности на Java так же удобно, как и на Обероне? Да ни разу. Даже если не вспоминать о проблемах, связанных с классами-синглтонами, паттерны и рядом не лежат с нормальной, хорошо организованной модульностью (особенно при том, что паттернов разных - тьма, а понятия модульности - одно, причём простое для освоения и применения). С этим вы согласны? Так почему тогда вы считаете, что куча паттернов и "местных обезболивающих" лучше одного проверенного штатного средсва?

В общем, если есть что-то конструктивное, я вас слушаю, ну а если "не надо мне туда", как правильно выразился Galkov, то уж извините, при всём уважении не вижу смысла дальше с вами спорить и что-то доказывать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 07:46 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
... автор какого-нибудь чудища - языка с макросами, думающий, что он может предвидеть все потребности реальных ситуаций.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба и макросах
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 08:18 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
kreol писал(а):
Ну запихнёте вы нужные выражерния в лямбда-функцию, ну передадите её в другую, ну получите тот же результат - и что, это будет проще? В случае макроса time, например, вам нужно обернуть кусок кода в пару выражений для замера времени, именно обернуть и именно кусок кода. И макросы позволяют сделать это самым прямым путём. Так зачем тогда искусственно усложнять задачу и дописывать какие-то лямбда-выражения или, тфу тфу тфу, выносить функционал в отдельную статическую процедуру? Наиболее простой и естественный способ сделать что-то почти всегда является лучшим - принцип Калашникова, не так ли?

Проще не будет, но и сложнее не будет тоже. Вам нужно где-то определить макрос time, верно, так чем это отличается от определения функции?
Вызов этой функции тоже сложнее не будет -- написали имя функции, передали ей замеряемый кусок кода, этот кусок кодя сдвинули вправо для красоты (скобки некрасиво выглядят).
Было:
Код:
        if openFileDialog.ShowDialog() = DialogResult.OK
        then
            Application.DoEvents()
            match AppData.importReport openFileDialog.FileName this.goods with
            | None          -> ()
            | Some newgoods -> this.goods <- newgoods
                               this.FillNoCatGoods this.goods
Стало:
Код:
        if openFileDialog.ShowDialog() = DialogResult.OK
        then
            Application.DoEvents()
            Utils.timeIt "loading report" <| fun _ ->
                match AppData.importReport openFileDialog.FileName this.goods with
                | None          -> ()
                | Some newgoods -> this.goods <- newgoods
                                   this.FillNoCatGoods this.goods
где функция timeIt определяется в вспомогательном модуле Utils так:
Код:
//////////////////////////////////////////////////////////////////////////////////////////////////////
/// Замеряет время выполнения подаваемого на вход кода и выводит сообщение с этим временем
//
let timeIt str action =
    let t0       = System.DateTime.Now
    let retvalue = action()
    let t1       = System.DateTime.Now
    ignore <| MessageBox.Show ((t1 - t0).ToString(), str, MessageBoxButtons.OK, MessageBoxIcon.Information)
    retvalue
Ну да, приходится дописывать "fun _ ->", ну так 8 символов дописать не так уж и трудно, зато не надо париться с закрывающими скобками... :wink:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 08:33 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3091
Откуда: Астрахань
Info21 писал(а):
С.Перовский с DelphiKingdom говорил, что программист -- не профессия.
Я с ним согласен в том смысле, что программирование это некая ограниченная вещь вроде элементарной арифметики или исчисления предикатов, которую выучил и пользуй. А то, что идет дальше, это нечто совсем другое и притом разное.
Но "профессиональным программерам", особенно "компьютерным гениям" надо же подтверждать свой профессионализм и особенно гениальность.
Вот и рождаются монстры на пустом месте. Был С++ -- надоедать стал. Теперь ФЯ.
"Суета и томление духа."

О "профессиональных программерах" говорить не будем. НО!...
Когда-то объемы бочек вычисляли вручную Пока не появились интегралы.
Вы в программировании сейчас остаетесь на уровне тех самых ручных вычислений объемов.
А в программировании зарождается "интегральное исчисление".

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

Пример Ильи Ермакова меня почти убедил, что мне ничего не потребуется, кроме ББ. Окончательно удостоверюсь при конкретной работе.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба и макросах
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 08:38 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
kreol писал(а):
... в Scheme вообще хз когда последний раз что-то новое включали.

Разве Вы забыли, как R6RS расколол скимеров на три лагеря -- за новый стандарт (R6RS), за старый стандарт (R5RS), и за альтернативу новому стандарту (ER5RS)?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба и макросах
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 08:57 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4508
Откуда: Россия, Орёл
Galkov писал(а):
...Вы нам это предлагаете ??? И называете это надежным программированием ???
Как я понял, Вам нужно вычислять записанные пользователем мат. выражения (viewtopic.php?p=35400#p35400):
Galkov писал(а):
У нас в системе есть конкретный элемент - FastMathParse
Fast, потому-что, в отличие от просто MathParse, он сначала компилирует строку "по-настоящему", и далее просто передает управление этому бинарному коду.
Предложенный Ермаковым вариант решения на ББ/КП:
* преобразовать мат. выражение в текст процедуры-функции на КП (и завернуть в модуль ест-но)
* передать текст штаному компилятору (получаем кодовый файл модуля)
* штаными средствами вызвать функцию из этого модуля

(кодовые файлы можно кэшировать в некой подсистеме)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О парадоксе Блаба и макросах
СообщениеДобавлено: Пятница, 02 Октябрь, 2009 09:28 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4508
Откуда: Россия, Орёл
kreol писал(а):
Евгений Темиргалеев писал(а):
После знакомства с языками Оберон-ветки...
Ну и причём здесь макросы?
Прочитайте внимательно сообщение, которое Вы цитируете (viewtopic.php?p=35352#p35352). Вам там отвечено не про макросы.

Было время, когда я активно использовал макросы для уменьшения писанины. Своё текущее мнение про макросы изложил тут (выделено в цитате): viewtopic.php?p=35331#p35331. Вы меня не переубедите (вернутся к тому, от чего уже отказался). Вас переубеждать не собираюсь (используйте, если Вам удобно). Из дискуссии о необходимости макросов удаляюсь.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 143 ]  На страницу Пред.  1, 2, 3, 4, 5, 6 ... 8  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB