OberonCore

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

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




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

Зарегистрирован: Суббота, 12 Май, 2007 08:41
Сообщения: 102
Откуда: Беларусь, Минск
Peter Almazov писал(а):
Ну так я же недаром написал, что профан в Немерле, да еще и смайлик в конце поставил. А вот если бы Вы привели примеры, было бы очень здорово. Иначе рассуждения о пользе макросов выглядят весьма абстрактно. Актуальность задачи "проверить коннект к БД во время компиляции", скажем так, не очевидна.

Проверка коннекта к БД во время компиляции нужна по тем же причинам, по которым нужна проверка сигнатур модулей, с той лишь разницей, что отсутствие соединения должно генерировать не ошибку, а ворнинг. Ну не нравится БД, возьмите для примера сетевое соединение, или проверку опреационной системы, или доступных компонент, или версии рантайма, или чего угодно - вам доступен весь набор функций языка не только во время исполнения программы, но и прямо на этапе компиляции.
Привер про замер времени: попробуйте написать на Обероне (С++, Java, C#) конструкцию, позволяющую замерить время выполнения следующего кода:
Код:
x := 5;
y := 10;
z := Math.Power(x, y);
Log.Real(z);

Для этого вам придётся замерять время перед выполнением кода, затем после него и сравнить результаты (код, я думаю, приводить не надо?). И так каждый раз, где вы хотите узнать время выполнения кода, ни в какую конструкцию обернуть это вы не сможете.
В Clojure это будет выглядеть так (если, конечно, пытаться писать императивно):
Код:
(time
    (def x 5)
    (def y 10)
    (def z (power x y))
    (println z))

Одной строчкой вы задаёте шаблон для кода, шаблон, который потом сможете использовать многократно.
Ещё один пример приведён в статье на Википедии, ссылку на которую приводили выше. Там количество строк уменьшено почти в два раза. На деле можно уменьшить код гораздо сильнее. Например, в Java одно обращение к БД через обычный JDBC занимает строк 10-12, которые с помощью макросов можно сжать до 1-2. То же самое с геттерами и сеттерами, которые в бинах занимают 90% кода класса. В C# (как и в анансируемой Java 7) чтобы избавиться от такой недоработки в языке ввели properties (да, я знаю, что Хейлсберг притянул их ещё из Делфи, смысла это не меняет), то есть новую конструкцию. В Common Lisp для введения ООП со встроенной генерацией аксессоров понадобилось всего лишь написать макрос. Вы представляете, что значит ввести в язык новую парадигму обычными, штатными средствами этого языка?
А как насчёт ленивых вычислений? Операторы and, or и т. д. во всех, даже энергичных языках (к которым относится и Оберон) являются ленивыми, т. к. вычисляют свои аргументы только по мере надобности, и это делает их уникальными. В Лиспе они реализованы всего лишь как макросы. Вообще, если в вашем языке есть макросы, то у вас отпадает необходимость вводить огромное количество ключевых слов, специальных операторов и уникальных функций. Следовательно, ядро языка минимизируется. Как-то слышал о том, что энтузиасты написали ядро лисп-машины на 400-500 строках ассемлерного кода, а весь остальной язык создали с помощью макросов на базе существующего ядра.
Если после всего вышесказанного у вас всё ещё возникает вопрос "а зачем мне всё это?", то я вас поздравляю, вы - блаб-программист ;)


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3096
Откуда: Астрахань
Блестяще!!!!!
Спасибо!


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
К вопросу о...
Экспорт read-only снимает большую часть страданий по поводу геттеров... А случаи, когда была бы необходима процедура SetОтдельноеЗначение, вообще редки, если нормально проектировать, а не пытаться сделать RECORD в виде класса с заменой полей на Get-Set.
Обычно установка значений идёт композиционно, с параллельным контролем их соотношений, с проверкой того, что изменение соответствует логическому состоянию (протоколу) объекта, и т.п.

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

Но, конечно, сразу же станет скучно и неинтересно. Так всё просто - и просто работает :)


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4520
Откуда: Россия, Орёл
kreol писал(а):
Для этого вам придётся замерять время перед выполнением кода, затем после него и сравнить результаты (код, я думаю, приводить не надо?). И так каждый раз, где вы хотите узнать время выполнения кода, ни в какую конструкцию обернуть это вы не сможете.
Код завернули в процедуру, для замера используем общую процедуру ЗамерьВремя(строка-qualIdent). Типа Dev->Timed Execute (DevProfiler.Execute)
kreol писал(а):
Одной строчкой вы задаёте шаблон для кода, шаблон, который потом сможете использовать многократно.
А процедуры для чего?


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8185
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
А ББ никьто не рекламирует и не продает).
Вы хотите купить? Платите прямо мне. Я с Ominc договорюсь 8D


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

Зарегистрирован: Суббота, 12 Май, 2007 08:41
Сообщения: 102
Откуда: Беларусь, Минск
Илья Ермаков писал(а):
Экспорт read-only снимает большую часть страданий по поводу геттеров...

Это вы по поводу введения в язык новых конструкций или по поводу уменьшения объёма кода? Если второе, то тут можно было бы поспорить, но не буду. Во-первых, потому что частично с вами согласен, а во-вторых, потому что это длинный разговор и он сильно выходит за предело темы.
Если же первое, то, как бы, read-only экспорт тоже является синтаксической конструкцией, которую другими средствами языка вы не синтезируете.

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

Вспомните ту же условную компиляцию в С++ (которая через #ifdef, #ifndef) - задача именно собрать из исходников программу для данных конкретных условий. То есть вот вы даёте кому-то исходник, даёте билд-файл и предлагаете скомпилировать на его машине с его ОС, с его базой и так далее. При вашем подходе человеку придётся не просто запускать билд-файл (в случае Лиспа - просто загрузить один файл), а пользоваться дополнительной программой-установщиком, которая сначала всё проверит, а потом скомпилирует. Немножко не то, о чём говорил я, не так ли?

Евгений Темиргалеев писал(а):
Код завернули в процедуру, для замера используем общую процедуру ЗамерьВремя(строка-qualIdent). Типа Dev->Timed Execute (DevProfiler.Execute)

Я вам подскажу способ проще - ставить в начало и в конец нужного блока проверку текущего времени и потом их сравниваете - и никаких дополнительных процедур городить не надо. Ой, это же что получается, мы пришли к началу?!
К тому же вы забываете про scope процедуры. Все переменные вы тоже предлагаете передавать через параметры?

Евгений Темиргалеев писал(а):
А процедуры для чего?

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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
kreol писал(а):
Вспомните ту же условную компиляцию в С++ (которая через #ifdef, #ifndef) - задача именно собрать из исходников программу для данных конкретных условий. То есть вот вы даёте кому-то исходник, даёте билд-файл и предлагаете скомпилировать на его машине с его ОС, с его базой и так далее.
При вашем подходе человеку придётся не просто запускать билд-файл (в случае Лиспа - просто загрузить один файл), а пользоваться дополнительной программой-установщиком, которая сначала всё проверит, а потом скомпилирует. Немножко не то, о чём говорил я, не так ли?

Какая разница, компилятор человеку всё равно нужен. Клюкнет один раз по коммандеру. Или программа сама при запуске сгенерирует и подгрузит модуль. В динамической системе проблема надумана. Разделение между средствами времени компиляции и времени выполнения - старая штука, неудобно. Лучше я сам решу, какой из модулей что генерирует, компилирует и подгружает.

Евгений Темиргалеев писал(а):
Вы явно не понимаете смысл макросов. Очень часто встречается код, который отличается несколькими строками..


Вах, как увлечённо объясняете, с каким огнём в глазах :)
Вы с Латехом, кстати, работали? Пример мощной макросистемы. Занятно, перепробовано вдоволь :) Но я предпочту составной документ; и дайте мне возможность писать на нормальном современном императивном языке, его обрабатывая. И не надо себе компостировать мозги никакими тонкостями комбинаций макросов (а тонкостей там, уж поверьте, возникает дофига..).


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4520
Откуда: Россия, Орёл
kreol писал(а):
Вы явно не понимаете смысл макросов.
Мне кажется, прекрасно понимаю.

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

Если писать метдом пошагового уточнения и думать законченными действиями алгоритма, а не строками кода, то "сделай что-то" это как раз процедура с закрытым локализованным контекстом, который никуда передавать не надо.

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


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

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

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

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


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

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


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

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


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4520
Откуда: Россия, Орёл
Тут говорится об идее универсального компилятора (легкое создание/расширение ЯП). Макросы - тоже, но более мелкого пошиба.
Вирт, Compiler Construction, 5.3 писал(а):
When using a table-driven parser, the tables expressing the syntax may easily be extended also to represent the attribute rules. If the evaluation and translation rules are also contained in associated tables, one is tempted to speak about a formal definition of the language. The general, table-driven parser grows into a general, table-driven compiler. This, however, has so far remained a utopia, but the idea goes back to the 1960s.
...
Figure 5.1. Schema of a general, parametrized compiler.

Ultimately, the basic idea behind every language is that it should serve as a means for communication. This means that partners must use and understand the same language. Promoting the ease by which a language can be modified and extended may therefore be rather counterproductive. Nevertheless, it has become customary to build compilers using table-driven parsers, and to derive these tables from the syntax automatically with the help of tools. The semantics are expressed by procedures whose calls are also integrated automatically into the parser. Compilers thereby not only become bulkier and less efficient than is warranted, but also much less transparent. The latter property remains one of our principal concerns, and therefore we shall not pursue this course any further.


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

Зарегистрирован: Суббота, 12 Май, 2007 08:41
Сообщения: 102
Откуда: Беларусь, Минск
Илья Ермаков писал(а):
Какая разница, компилятор человеку всё равно нужен. Клюкнет один раз по коммандеру. Или программа сама при запуске сгенерирует и подгрузит модуль. В динамической системе проблема надумана. Разделение между средствами времени компиляции и времени выполнения - старая штука, неудобно. Лучше я сам решу, какой из модулей что генерирует, компилирует и подгружает.

Во-первых, неудобно. Вам кроме исходных текстов придётся распространять скомпилированную утилиту, которая будет всё это проверять (в вашем примере - собственно БлекБокс со встроенным "загрузчиком").
А что, если у вас нету этой готовой утилиты для целевой платформы, а есть только компилятор? Вполне реальная ситуация, не так ли?
Если вы считаете, что проверка параметров системы не нужна при компиляции, попробуйте собрать любую сишную программу под Linux. Скорее всего, вам придётся выполнить три комманды:
Код:
./configure
make
make install

То есть сначала вам с помощью скрипта придётся сконфигурировать будущую программу, а затем уже компилировать. Если У вас есть возможность совместить эти две стадии, причём обычная, штатная возможность языка, не является ли это плюсом? Не, можно и с configure/make, кто ж помешает Блаб-программисту, только вам для создания дистрибутива своей программы придётся не только свой основной язык знать, но и ещё один, скриптовый для целевой платформы. Причём для разных платформ скрипты тоже придётся писать разные.
Это было всё ещё "во-первых", а во-вторых, что вы будете делать, если нужно заменять некоторые параметры внутри текста программы? Я же не зря вспомнил про условную компиляцию в С++. Например, вам нужно написать библиотеку, вызывающую функции операционной системы, но в зависимости от того, Linux это или Windows, функции, естественно, будут отличаться. Без условной компиляции вы не то, чтобы свалить при выполнении программы, вы даже собрать её не сможете. И не надо тут говорить о грамотном проектировании и необходимости вынесения всех системозависимых функций в отдельный модуль - такая возможность может и не представиться или оказаться крайне неудобной.

Илья Ермаков писал(а):
Вы с Латехом, кстати, работали? ... (а тонкостей там, уж поверьте, возникает дофига..).

Увы, не довелось. Тонкостей много в Латексе? Возможно, вам виднее. В Лиспе никаких тонкостей нет - всё прозрачно до безобразия. Насчёт Nemerle не знаю, но судя по тому, что они даже статическую проверку типов в макросы ввели, думаю, там с этим тоже всё ок.

Илья Ермаков писал(а):
По конкретному примеру - частая проектная ошибка: делать процедуру Open&... Открытие конкретного файла, закрытие и т.п. - дело верхнего уровня, "скриптовой логики", так сказать.

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

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

Вы конкретный пример приведите. Я вот предложил два широко распространённых макроса - time и with-open-file. У первого никаких параметров, у второго - имя файла и направление в/в. И их хоть где применяй, хоть как комбинируй, сложность каждого макроса в отдельности останется константной, а всех вместе - линейнозависимой от их количества. Такой же, как и при использовании функций, только гораздо меньше, потому что строк кода гораздо меньше, а программисту проще писать и читать получившуюся программу.
И заметьте, ничего неявного в этих макросах нет: можно подумать сложно догадаться, что скрывается за макросом time.

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

То же самое - когда найдёте конкретный пример "безграмотной писанины для клепальщиков", тогда будет о чём поговорить. Пока что вы просто кидаетесь красивыми словами и ведетё себя как типичный Блаб-программист. И если уж Пол Грехем вас не переубедил, то мне и подавно это не удастся.
Цитата:
Впрочем, из этого утверждения редко делается вывод. Программисты старше определенного возраста редко меняют язык по своей воле. Они будут считать достаточно хорошим тот язык, к которому привыкли.



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

Естественно не часто, потому что это жутко неудобно - сначала вынести все нужные функции в отдельную процедуру, потом создать RECORD, и только после этого передать всё это в функцию. А в Лиспе я просто дописываю одну строчку вверх, и всё. Язык формирует способ нашего мышления (с).

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


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2931
Откуда: г. Ярославль
О-о, описание достоинств макросов сильно напомнило мне старые добрые кларион-времена. Описываем словарь данных, потом запускаем визатрон и генерируем набор шаблонов. Шаблоны написаны на макроязыке, являются обобщением стандартных ситуаций и призваны генерировать исходники в зависимости от пожеланий пользователя. Оч. удобно.


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

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 530
Откуда: Москва
2 kreol: большое спасибо за ликбез и развернутые ответы.
Но удивительно, что сторонник ФП (во всяком случае, не противник?), в распоряжении которого функции как переменные первого рода, лямбда-выражения и замыкания предлагает решать задачу с обработкой файла с помощью макросов! По-моему наглядная демонстрация части 2 высказывания viewtopic.php?p=35207#p35207 (ничего личного, у кого из нас нет дефектов).


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4520
Откуда: Россия, Орёл
Вы упустили часть цитаты. Вставил жирным:
kreol писал(а):
И если уж Пол Грехем вас не переубедил, то мне и подавно это не удастся.
Цитата:
А как насчет Perl четвертой версии? В Perl 5 в язык были добавлены лексические замыкания (lexical closures). Большинство Perl хакеров согласятся, что Perl 5 мощнее, чем Perl 4. Но раз вы это признали, вы признали, что один высокоуровневый язык может быть мощнее другого. Из этого неизбежно следует, что использовать нужно самый мощный язык.

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

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

P.S. уточню про относительность (сначала думал и так понятно): простоте и постоянству -- в сравнении с майнстримом


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

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 530
Откуда: Москва
Евгений Темиргалеев писал(а):
И если я к чему и привык, то не к языку с определённым набором фич, а к свойству языков -- простоте и постоянству.
Извините, не удержался... :D
А.Н. Островский писал(а):
Трактат о вреде реформ вообще

Артикул 1-й. Всякая реформа вредна уже по своей сущности. Что заключает в себе реформа? Реформа заключает в себе два действия: 1) отмену старого и 2) поставление на место оного чего-либо нового. Какое из сих действий вредно? И то и другое одинаково: 1-е) отметая старое, мы даем простор опасной пытливости ума проникать причины, почему то или другое отметается, и составлять таковые умозаключения: отметается нечто непригодное; такое-то учреждение отметается, значит, оно непригодно. А сего быть не должно, ибо сим возбуждается свободомыслие и делается как бы вызов обсуждать то, что обсуждению не подлежит.
2-е) поставляя новое, мы делаем как бы уступку так называемому духу времени, который есть не что иное, как измышление праздных умов.


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

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

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

Код:
Это было всё ещё "во-первых", а во-вторых, что вы будете делать, если нужно заменять некоторые параметры [i]внутри[/i] текста программы?

Имея двоичный формат документа - легко, средствами Framework.

Цитата:
Я же не зря вспомнил про условную компиляцию в С++. Например, вам нужно написать библиотеку, вызывающую функции операционной системы, но в зависимости от того, Linux это или Windows, функции, естественно, будут отличаться. Без условной компиляции вы не то, чтобы свалить при выполнении программы, вы даже собрать её не сможете.

Делал сто раз. Никакой условной компиляции в модульном языке нафиг не надо.
Даже внутри одного модуля. Если в стандартной библиотеке среды программирования есть функция LoadLib и GetProcFromLib.

Все эти ifdef и make - старьё, которое во где уже у всех сидит.

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

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

Илья Ермаков писал(а):
with-open-file. У первого никаких параметров, у второго - имя файла и направление в/в. И их хоть где применяй, хоть как комбинируй, сложность каждого макроса в отдельности останется константной, а всех вместе - линейнозависимой от их количества.

with-open-file - дурнейшая вещь, слышал про неё давно. Единственная её цель - позволить писать что-то в одну строчку. (Тьфу, опять PHP вспоминается - там огромная куча функций такого рода; для "поиспользовал раз и выкинул").
У меня в системах могут гулять многие разновидности файлов (in-memory, лежащие внутри других файлов с версионированием..) - и открытие файла такое редкое и локализованное где-то наверху, в частной конфигурационной логике событие...

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

kreol писал(а):
Пока что вы просто кидаетесь красивыми словами и ведетё себя как типичный Блаб-программист. И если уж Пол Грехем вас не переубедил, то мне и подавно это не удастся.


Он и не переубеждал. Переубеждать - значит, излагать какой-то смысл, а не изливать некий фонтан стукнувших внезапно в голову ощущений. Как же программёры ведутся на это, как и гуманитарии. Ещё кто-то жалуется о навязывании им математики. Хотя бы для того кормить ей, что "ум в порядок приводит".


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2931
Откуда: г. Ярославль
Илья Ермаков писал(а):
Никакой условной компиляции в модульном языке нафиг не надо.
Даже внутри одного модуля. Если в стандартной библиотеке среды программирования есть функция LoadLib и GetProcFromLib.


Во! Как раз этим и занимаюсь! Делаю абстрактный интерфейс предметной логики, а реализации под MySQL или под SQLite или под чОрта лысаго лежат в разных модулях. Их-то я и могу легко подключить в рантайме, без перекомпиляции.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3096
Откуда: Астрахань
Мне кажется, ББ-народ несколько узковато понимает слово "макрос", почти исключительно как текстовыеи подстановки. Между тем, для меня слово "смешанные вычисления Ершова" в настоящее время сильно ассоциируется со словом макрос. Сейчас этим словом можно назвать, например, Рефал. Рефал - язык макросов! Ибо в основе - та же подстановка.
Понятно, что в чисто императивном языке передавать блок кода как неисполняемую сущность в качестве параметра, а потом использовать этот параметр как исполняемый код - это потрясение основ.
Но не кажется ли вам, что сейчас возрождение функциональщины и проникнивение ее в императивщину - это не просто некое поветрие, а именно некое развитие программирования?


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

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

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


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

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


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

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


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

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