Фя & цикл vs рекурсия [Re: ИТ-образование]

VTISHKOV

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

Marinavo_0507

Далеко от жизни. Радость от написания вычислительных программ получают только фрики, у которых и так не будет проблем с обучением в сфере IT.

Julie16

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

Marinavo_0507

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

Julie16

Я учился в одной из двух лучших школ в городе. Наш город(Саров) - один из немногих научных городов(а это значит что образование у нас одно из лучших в стране, если не самое лучшее, во всяком случае отношение числа учащихся в МГУ к числу жителей города уж точно). Так вот. В моем классе кроме меня НИКТО бы не смог написать программу на ML. В остальных классах думаю тоже. Еще человек 10-15 во всем городе из моей параллели и старше тоже смогли бы. Все. Значит остальные - умственно отсталые? А что тогда говорить про остальную страну?

Marinavo_0507

> В моем классе кроме меня НИКТО бы не смог написать программу на ML.
Твой пример на Паскале переводится в ML заменой ключевых слов и библиотечных функций. Получается, и его никто из твоего класса никто не смог бы написать.

Julie16

ML - функциональный язык?

Marinavo_0507

фпоискнах

2354570

Давайте жить дружно.
Существующие методики обучения программированию в академической среде неоптимальные, но достаточно эффективные. Сужу по себе, пришедшему на ВМК с мизерным навыком программирования.
В общем, людям надо преподавать АСМ (чтобы знать, что всё что есть сейчас, надо ценить Си (чтобы понять, что Асм есть Асм, в какую обёртку его не заверни) и Си++ (ООП по самые гланды, чтобы ночью снилось остальное познаётся через этих зубров.

garikus

... остальное познаётся через этих зубров.
А я считаю, что всё сложное познаётся через простое гораздо эффективнее, чем наоборот.
---
Power of simplicity.

garikus

По крайней мере математикам, физикам, химикам достаточно будет простого языка для решения своих задач, нет необходимости использовать Fortran, С, и уж тем более C++, когда есть оберон.
Автоматическое управление памятью, строгая динамическая типизация, программирование без отладчика, очень быстрый компилятор, хорошо продуманный синтаксис => программы пишутся быстро и без ошибок. После этого я не понимаю, почему пишут на C++.
Системное программирование - это уже отдельная тема. Даже в этой области оберон используется эффективно (http://bluebottle.ethz.ch/)
Я не очень хорошо разбираюсь в программировании (потому что не учусь на ВМК и если у вас будут какие-нибудь сложные вопросы по оберону, можно спросить здесь: http://www.delphikingdom.com/asp/talktopic.asp?ID=285&Order=0&Count=10&pNo=1
Q: Вы все тут так расхваливаете оберон а чем он лучше Дельфи, Явы и С++ ? Только обьясните попростому на кой ляд им заниматься
.
A: Если уж совсем по простому, то есть ремесленный подход к программированию и есть научный подход к программированию. Дельфи, Явы и С++-сы - это, как бы, представители ремесленного подхода. Обероны - это, как бы, представители научного подхода. Спрашивается чем ремесленный подход хуже научного? Есть гипотеза, что научный подход дает:
.
1) ощутимый рост производительности коллективов программистов и повышение надежности программ измеряемое не процентами, а разами;
.
2) что хорошо подготовленные профессионалы должны быть гораздо эффективнее, чем вдохновенные любители. В их производительности должно быть различие, и притом существенное.
.
И эта гипотеза скорее верна чем не верна.

bleyman

>> ASSERT( ( stack.l >= 0 ) & ( stack.l < depth 20 );
Вот эта вот цифра 20 (и 21 в следующем ассерте) демонстрирует, что научный подход сосёт. Потому что сосут его подвижники. Потому что язык (включая внутренние установки программиста - типа стиля) должен быть таким, чтобы можно было подправить кусок кода через три года, и всё продолжило бы работать. Никакие "верифицируемые программы" этого не дадут, это появляется только с опытом и в результате ффтыкания в код других хороших программистов.
Гипотеза прекрасная, конечно. Только джава даёт прирост производительности, поэтому на ней пишут, а на обероне что-то я ни одной большой проги не встречал.
ИМХО фишка в том, что для Научного Познания нужны опытные факты, и много. А у Научных Программистов, в большинстве своём, с опытными фактами очень плохо. Поэтому появляются разнообразные сферические языки в вакууме, на которых можно написать гарантированно работающее красно-чёрное дерево, и это, пожалуй, единственное их достоинство.
>> программирование без отладчика
Это как, простите?
>> хорошо продуманный синтаксис
Синтаксиса лучше чем у С не бывает. Вот эта запись - 


BEGIN (*Postfix*)

	In.Open;

	GetSym;  Expression;

	Log.Ln

END Postfix;

Показывает, что синтаксис сосёт. Потому что приходится писать неуставные комментарии. Точки с запятой нет на последней строчке. А вот "IF zzz OR xxx OR yyy DO ... END" - это вообще человек с больной психикой придумал. Я понимаю - в паскале, BEGIN/END это операторные скобки, даже довольно последовательно они эту концепцию воплотили. Или в модуле2 (кажется) если уж END соответствует IF, то он так и называется - ENDIF. Но вот такое... Уххх!

Landstreicher

У меня есть знакомый, который учится сейчас в 10 классе обычной средней школе (не в Москве). Информатика у них нулевая. Чисто из собственного интереса купил хорошую книжку по C и начал читать (с другими языками программирования не знаком). Так вот, прочитал главы про for, while - все понятно. Пишет программы с циклами без проблем. Дошел до рекурсии, долго не мог понять, что это такое, как оно работает и зачем оно надо.
Все эти штуки - чрезвычайно абстрактные математические конструкции, детям их понять очень сложно. Бесполезно учить детей ML - не поймут.

Landstreicher

Я глубоко убежден, что программирование без отладичка невозможно.
Компилятор конечно может отловить ошибки типа опечаток, несоотвествия типов. Но большинство ошибок гораздо более сложные. Например, нарушение инвариантов (массив должен быть всегда отсортирован, а в него вставили элемент который нарушает это). Еще типичными являются ошибки типа race-condition при не mulithread-safe code. Такие ошибки можно найти только в отладчике и никак по-другому.

Julie16

>race-condition при не mulithread-safe code. Такие ошибки можно найти только в отладчике и никак по-другому.
Ух ты. Лично я убежден что такие ошибки в отладчике не найти.

bleyman

А это такие специальные Железные Люди, которые только синтаксические ошибки делают.
Вот я здесь сделал одну ошибку. Интересно, как этот Научный Кодер её найдёт?

MODULE Kurs2004ComplexStack;
IMPORT Math;
CONST depth = 10;
TYPE Complex* = RECORD x, y: REAL END;
VAR
stack: RECORD
l: INTEGER; (* level; first unused *)
a: ARRAY depth OF Complex;
END;
PROCEDURE Push* ( IN a: Complex );
BEGIN
ASSERT( ( stack.l >= 0 ) & ( stack.l < depth 20 );
stack.a[ stack.l ] := a;
INC( stack.l )
END Push;
PROCEDURE Pop* ( OUT a: Complex );
BEGIN
ASSERT( ( stack.l > 0 ) & ( stack.l <= depth 21 );
DEC( stack.l );
a := stack.a[ stack.l ];
END Pop;
PROCEDURE Add*;
PROCEDURE Add0 ( VAR a: Complex; IN b: Complex );
BEGIN
a.x := a.x + b.x;
a.y := a.y + b.y;
END Add0;
BEGIN
ASSERT( stack.l >= 2, 20 );
DEC( stack.l );
Add0( stack.a[ stack.l ], stack.a[ stack.l - 1] )
END Add;
Сравнивать с оригинальным - нечестно.

bleyman

Это да =)
По хорошему, их вообще никак не найти. Диагностические мессаги могут помочь, да, но такое ищется ффтыканием, причём даже не в код, а в что-то типа блоксхемы.

Marinavo_0507

Ну чё приебались, как будто это я хочу всех заставить сразу изучать рекурсию.
Ну не могут нормальные дети понять ни qsort, ни gui-библиотеки, ни обход дерева в глубину - туда им и дорога, тем быстрее значит погибнет человечество.
Я, если кто до сих пор не заметил, за то, чтобы отложить изучение языков на попозже.

Landstreicher

Такое конечно не всегда ловится, но довольно часто помогают разные методы типа:
1) поставить breakpoint на определенное место, пустить программу до нее
2) в этом месте посмотреть содержимое некоторых структур и поставить определенный hardware watchpoint
3) ждать пока этот watchpoint сработает в другом треде

Julie16

А если такое случается примерно раз в месяц работы программы?

Marinavo_0507

> А если такое случается примерно раз в месяц работы программы?
Нужно ставить watchdog, спроси у Глебиуса

Landstreicher

> Ну чё приебались, как будто это я хочу всех заставить сразу изучать рекурсию.
Так ведь в том то и дело, что все эти функциональные языки завязаны на рекурсии. Убери рекурсию из ML - и получишь что-то типа Pascal.

Marinavo_0507

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

Landstreicher

Значит неповезло
Или пустить все в screen + gdb и ждать, ждать, ....
Я не говорю что такие ошибки обязательно можно отловить в отладчике. Я хочу сказать, что при наличии отладчика можно хоть как-то попытаться их отловить, а без него - вообще никак.

VTISHKOV

Я предлагал их всем сразу изучать?
Это я предлагал. Однако я считаю, что если не объяснять, а дать пощупать, что такое рекурсия, то дети это отлично поймут. И в ML нужно совершенно минимум всего, почти как в ранних BASIC-ах, чтобы начать щупать.
P.S. Это как унификация в прологе - въехать по книжке невозможно, пока сам не попробуешь (только унификация концептуально сложнее рекурсии).

Marinavo_0507

Крутить краны на нефтяных трубах можно без рекурсии.

VTISHKOV

Крутить краны на нефтяных трубах можно без рекурсии.
Крутить краны на нефтяных трубах будут китайцы

VTISHKOV

Так ведь в том то и дело, что все эти функциональные языки завязаны на рекурсии. Убери рекурсию из ML - и получишь что-то типа Pascal.
А вот. Наоборот не получится - из паскаля ML. Зато в ML есть как строго функциониальное подмножество языка, так и поддержка императивного стиля - кому как больше ндравицца. Хотя, конечно, императивные конструкции идут немного вразрез с логикой языка.

Dasar

> Твой пример на Паскале переводится в ML заменой ключевых слов и библиотечных функций
Имхо, ML ближе к научному базису, чем к практике.
Но обучение обычно начинают с практики, а потом уже подводят теоретический базис:
сначала рассказывают что такое 1+1, а уже много позже рассказывают теорию поля.
Рекурсия сложнее, чем цикл - т.к. в цикле сохраняется равноправие элементов - они все одиннаково располагаются на одном уровне.
В рекурсии - же появляется глубина - и второй, третий и т.д. элемент - уже получаются намного менее равноправны, чем первый.
ps
Самое главное - не совсем понятно - зачем рассказывать про циклы и рекурсию - для объяснения действий:
взять элементы слева и положить их направо
взять все красные элементы и изменить их цвет на зеленый
Взять тот же sql - его даже многие менеджеры понимают и используют - при этом они умеют главное - умеют управлять информацией и они не задумываются (им не надо задумываться что есть какие-то циклы, рекурсии и т.д. - они просто сообщают компьютеры, что они хотят получить в итоге.

rosali

Взять тот же sql - его даже многие менеджеры понимают и используют - при этом они умеют главное - умеют управлять информацией и они не задумываются (им не надо задумываться что есть какие-то циклы, рекурсии и т.д. - они просто сообщают компьютеры, что они хотят получить в итоге.
Вообще-то в SQL-е как раз нет ни циклов ни рекурсий. Собственно поэтому на нем проще программировать. Кто-то умеет проводить доказательства по индукции, а кто-то в принципе не может такие доказательства понять и уж тем более придумать. Рекурсия это в точности то же самое. Вобщем это я к тому, что человеку, уже знакомому с математикой, понять рекурсию проще чем цикл. Вообще математика и программирование связаны гораздо теснее чем кажется на первый взгляд, взять хотя бы изоморфизм Карри-Ховарда.

garikus

>> ASSERT( ( stack.l >= 0 ) & ( stack.l < depth 20 );
Вот эта вот цифра 20 (и 21 в следующем ассерте) демонстрирует, что научный подход сосёт. Потому что сосут его подвижники. Потому что язык (включая внутренние установки программиста - типа стиля) должен быть таким, чтобы можно было подправить кусок кода через три года, и всё продолжило бы работать. Никакие "верифицируемые программы" этого не дадут, это появляется только с опытом и в результате ффтыкания в код других хороших программистов.
Можно и не писать 20 и 21. Тогда эти номера будут назначаться компилятором автоматически. В Си тоже есть макрос - assert (assert.h)
Синтаксис языка как раз такой, что можно без проблем подправить кусок кода через 3 года - в C++ перед исправлением много времени уходит на то, чтобы разобраться в написанном ранее коде (из-за сложности синтаксиса).
>> хорошо продуманный синтаксис
Синтаксиса лучше чем у С не бывает. Вот эта запись -


BEGIN (*Postfix*)

	In.Open;

	GetSym;  Expression;

	Log.Ln

END Postfix;

Показывает, что синтаксис сосёт. Потому что приходится писать неуставные комментарии.
В этом случае для удобочитаемости желательно (но не обязательно) указать с помощью комментария то место, где начинается процедура Postfix, т.к. у неё есть несколько вложенных процедур. Вообще вложенные процедуры используются редко, т.к. способствуют появлению side-effects.
Но после каждого END нужно указывать имя процедуры / модуля. В Си этого нет, и, если не вставлять комментарии, нужно больше времени для того, чтобы отличить то место, где заканчивается функция, от того, где заканчивается другая конструкция.
Точки с запятой нет на последней строчке. А вот "IF zzz OR xxx OR yyy DO ... END" - это вообще человек с больной психикой придумал. Я понимаю - в паскале, BEGIN/END это операторные скобки, даже довольно последовательно они эту концепцию воплотили. Или в модуле2 (кажется) если уж END соответствует IF, то он так и называется - ENDIF. Но вот такое... Уххх!
В конструкциях IF-THEN-ELSIF-ELSE-END, WHILE-DO-END, CASE-OF-ELSE-END после END не указывается, какую конструкцию они закрывают, потому что это было бы не так эффективно, как кажется, и только бы усложнило синтаксис. Тело этих конструкций редко занимает больше одного экрана по высоте исходного кода, в отличие от тела процедур.
В Modula-2 нет ENDIF-ов. Если они и были в Modula (в чём я не уверен то, думаю, их убрали как раз по этой причине.
Точку с запятой не нужно ставить перед END-ом, потому что ей там нечего разделять.
По поводу IF-THEN-END.
Если условия между IF-THEN не укладываются в одну строчку исходного кода (что бывает не так часто то можно писать и так:
IF
THEN
ELSE
END;
Я считаю, что конструкция


IF a THEN

    b

ELSIF c THEN

    d

ELSE

    e

END;

более удобная, чем аналогичная в Си:


if (a)

{

    b;

}

else if (c)

{

    d;

}

else

{

    f;

}

garikus

Гипотеза прекрасная, конечно. Только джава даёт прирост производительности, поэтому на ней пишут, а на обероне что-то я ни одной большой проги не встречал.
ИМХО фишка в том, что для Научного Познания нужны опытные факты, и много. А у Научных Программистов, в большинстве своём, с опытными фактами очень плохо. Поэтому появляются разнообразные сферические языки в вакууме, на которых можно написать гарантированно работающее красно-чёрное дерево, и это, пожалуй, единственное их достоинство.
Р. Богатырёв:
Согласен, что Oberon-сообщество очень небольшое, его активность у нас в стране стала проявляться лишь в последние 1-2 года. Если говорить об интересе к Oberon в остальном мире -- то сейчас он более чем сдержанный. Те, кто разобрались, в чем его плюсы, -- особенно не афишируют, используя его как конкурентное преимущество в своем бизнесе.
Одна из серьезнейших ошибок ETH была в том, что язык Oberon и его семейство в массы активно не продвигались. Ни финансы, ни время в это всерьез не инвестировали. Язык Oberon взращивался внутри системы Oberon, прелесть и своеобразие которой массовой аудитории понять непросто. Автономные IDE были коммерческими и на пиратских дисках не выходили. Пользоваться ими могли только единицы. Книг появилось мало (на русском языке -- так вообще нет собственные СМИ практически отсутствовали (если не считать сайтов из Oberon Ring).
ИТ-индустрия Oberon продвигать и не собиралась. Университеты попали сразу под две волны конца 1990-х – начала 2000-х годов: (1) сращивание с ИТ-индустрией (превращение вузов по сути в ремесленные училища, где выпускник готовится едва ли не под конкретное производство) и (2) искусственно взращенная всемирная Java-эйфория.
Для выхода языка на рынок требуется пройти следующие фазы.
I. Детство (5-10 лет):
1) пилотный проект создания инструментария (компилятор, IDE);
2) разработка библиотек, первые прикладные проекты, формирование ядра сообщества, собственные СМИ (user groups, бюллетени, сайты и т.п.).
II. Юность (5-10 лет):
3) создание первых коммерческих версий инструментария для массовой аудитории;
4) появление критической массы книг и статей;
5) расширение сообщества пользователей, начало стандартизации.
Затем наступает период рыночной зрелости языка.
На каждый из этапов в этих фазах требуется в среднем 2-4 года. Получается, что выход языка на рынок в нормальном случае происходит примерно через 15-20 лет после его появления на бумаге (первого препринта с описанием). В ненормальном (Java) -- за 3 года.
Вот мои прикидки по четырем самым известным языкам.
1. Паскаль: 1970-1980 (детство 1981-1988 (юность http://www.osp.ru/pcworld/2001/04/058.htm
2. Си: 1971-1977 (детство 1978-1988 (юность
http://www.osp.ru/pcworld/2001/08/126.htm
3. С++: 1983-1989 (детство 1990-1994 (юность http://www.osp.ru/pcworld/2003/01/144.htm
4. Java: 1994-1995 (детство 1996-1997 (юность http://www.osp.ru/pcworld/2002/09/144.htm
Как видно, язык Java толкали вперед так, что бедный ‘акселерат’ едва поспевал за своими опекунами (Sun и IBM) и теми авансами, которые ему выдавали. Он не успел созреть, а его, толком еще не окрепнувшего, бросили в горнило рыночных войн. При этом Java только сейчас пытается подойти к той задаче, ради которой его создавали -- микромиру встроенных систем для бытовых устройств.
У языка Oberon 1988-1995 гг. пришлись на детство, затем началась полоса юности, в которой отсутствовали многие важные элементы, не позволявшие технологически зрелому языку стать рыночно зрелым.
Можно смело говорить, что именно язык Java сыграл роль ‘могильщика’ Оберона. Java-волна накрыла Oberon, едва тот начал набирать силу. Более того, практически все лучшие кадры, занимавшиеся Oberon, вынужденно ‘переметнулись’ в лагерь Java, поскольку основные финансовые потоки в сфере образования и исследований, не говоря уже об индустрии, переключились на Java. Из-за этого в рыночном отношении последнее десятилетие для Oberon во многом было потерянным.
Если брать нынешнюю ситуацию, то основными промышленными языками в обозримом будущем видятся C++ и Java. Первый продвигается корпорацией Microsoft, второй -- IBM (в меньшей степени -- Sun). Язык Си благодаря огромному пласту UNIX-культуры, моды на Linux и роли высокоуровневого ассемблера свои позиции не потеряет...

garikus

Небольшая статья Component Pascal и Java: что лучше

Julie16

Угу. В 98 году может оно так и было

garikus

Да и сейчас почти всё так
Java - что это за язык такой, который всё время меняется ?
Для эффективного программирования нужно следить за тем, что нового там появляется, и что становится deprecated.

bastii

for each (цикл по перечисляемым коллекциям) в этих языках есть?

garikus

Нет, есть только 2 конструкции:


WhileStatement = WHILE Expression DO StatementSequence END.

ForStatement =

		FOR ident ":=" Expression TO Expression [BY ConstExpression]

		DO StatementSequence END.

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

bastii

Из языка для упрощения синтаксиса и для получения более эффективного компилятора были исключены даже такие средства, как типы-диапазоны (вместо них можно использовать один из стандартных целых типов) и перечисляемые типы (вместо них можно использовать целые константы)
Вирт хотел даже цикл FOR убрать, только WHILE оставить
теоретики, что с них взять
не знаю как у других, но я просто умерал пока for each и дженерики в Джава не появились

bleyman

А-ху-еть.
Специально нашёл пост в инете. http://www.delphikingdom.com/asp/talktopic.asp?ID=285&Order=0&Count=10&pNo=4 Мне чисто было интересно, когда он был написан. Я тааак удивился, когда увидел дату "08-06-2005 06:26"...
В сочетании со абзацем
Если брать нынешнюю ситуацию, то основными промышленными языками в обозримом будущем видятся C++ и Java. Первый продвигается корпорацией Microsoft, второй -- IBM (в меньшей степени -- Sun). Язык Си благодаря огромному пласту UNIX-культуры, моды на Linux и роли высокоуровневого ассемблера свои позиции не потеряет...
Образ Сферического Программиста Сферических Программ в Вакууме становится более чем реальным. Чувак, забивай на эту херню, Б-г с ними, с недостатками языка, тут же чудовищная атмосфера. Ты в ней потусуешься ещё, и тоже превратишься в вечного МНСа, с производительностью в полторы отдебаженных строчки в день, десятилетним отставанием от новостей ИТ, и кучей Умных Мыслей про Научное Программирование.

sergey_m

> но я просто умерал пока for each и дженерики в Джава не появились
умир бы, зачем мучался?

garikus

Не понимаю, откуда у тебя такие выводы, ты слишком всё обобщаешь. Есть области, где всё это нужно.

bastii

не умер, жил обещанием, что в следующей версии появятся, и не обманули

bastii

Например? (это я про области)
Fj одну из таких описал

bleyman

Что "это нужно"? Ты к чему это? Я про то, что там на форуме тусуются такие специальные люди... Такие...
Ну короче, я это к тому, что M$ уже года четыре С++ никуда не продвигает, а продвигает наоборот С# и .НЕТ, а аффтар этого не знает, но ему и не нужно, он весь в своём выдуманном мире, в котором ему легко и приятно от того, что его язык "научный". Ну то есть прям видишь его - в свитере, очёчках, сидит в каком-нибудь институте, переписывает двадцатилетней давности досовскую прогу Ведения Бухучета на своём обероне, причём именно с той эффективностью - полторы отдебаженных строчки в день. Зато у него много времени на перекуры и попиздеть на форумах.
Не тусуйся в такой компании, это ещё сильнее разрушает мозг чем бейсик!
Да, а ещё я не ффтыкаю, в чём "научность" языка, собственно? В шарпе/жаве/ВБ автоматический менеджмент памяти есть (а в плюсах не очень сложно делается ассерты тоже присутствуют. В приведённых примерах я заметил разве что несколько более развитую модульность (по сравнению с шарпом/жавой). И то хз, нужна ли она. В чём понтовость-то?

voronetskaya

Да, а ещё я не ффтыкаю, в чём "научность" языка, собственно?
я так понимаю в том, что пользователи этого языка занимаются наукой, а не программированием.

garikus

Если автор ничего не пишет про C#, то это не значит, что он про него ничего не знает, и что развитие оберона стоит на месте. В ETH занимаются разработкой языка и компилятора для .NET.
.NET, C#, Delphi, QNX, а также идеи по встраиванию многопоточности в язык - также обсуждаются в той ветке форума, если у тебя есть какие-нибудь вопросы, можешь задать их там.
Я не понимаю, откуда эти выводы про сферический вакуум. Технологии существуют, ими реально занимаются, но в силу своей специфики обероны не популярны. Почему - см. выше.
Я специально ничего не писал про C# и про .NET. C# - хороший язык. Но тут всё решает Microsoft. Ни в их интересах, ни в интересах Sun способствовать развитию оберона, каким бы хорошим он не был. Всё, что им нужно было от оберона (который появился в середине 80-х) при разработке своих языков, они взяли (у Java это получилось хуже).
Основные преимущества оберона перед другими технологиями в том, что он остаётся простым и не подвержен влиянию со стороны той же Microsoft, у которой свои интересы на счёт средств разработки.

bobby

Если автор ничего не пишет про C#, то это не значит, что он про него ничего не знает
зачем же он тогда распространяет заведомо неверную информацию?

bleyman

> но в силу своей специфики обероны не популярны. Почему - см. выше.
Посмотрел. Выше написано, что обероны непопулярны в силу отсутствия рекламы. Какая специфика у языка я что-то не уловил.
> Основные преимущества оберона перед другими технологиями в том, что он остаётся простым
Аххх. У меня времени нет, а вот ты можешь чисто по приколу найти таки ЕБНФ С и своего Оберона, и сравнить. Я почти уверен в результате. И если результат окажется таким, как думаю я, можешь ещё найти ЕБНФ шарпа. Конкретно по синтаксису они С почти не усложнили, хотя семантика стала несколько более загадочной (в основном из-за оверлоадинга).
> и не подвержен влиянию со стороны той же Microsoft, у которой свои интересы на счёт средств разработки.
А ещё Микрософт выкрали бортовой компьютер из летающей тарелки, потерпевшей крушение в Розуэлле в 1947 году, и вытаскивают из него технологии, не желая делиться с остальной общественностью.

garikus

Повышенная надёжность, беспилотные летательные аппараты, встраиваемые системы, спец. инструментальные системы (BAE Systems, BMW, Philips, NASA, DuPont Ballistic Lab, Esmertec)
математический софт, физика (CERN, Optech)
В Oberon Microsystems разрабатывали Java JIT-компилятор для Borland
Система управления каскадом ГЭС на Амазонке (Alstom Power федеральная система управления дорожным движением в Швейцарии.
другие - малоизвестны.

garikus

зачем же он тогда распространяет заведомо неверную информацию?
Он не распространяет заведомо неверную информацию. Он эту ниформацию просто не распространяет

garikus

А ещё Микрософт выкрали бортовой компьютер из летающей тарелки, потерпевшей крушение в Розуэлле в 1947 году, и вытаскивают из него технологии, не желая делиться с остальной общественностью.
очень интересно...
ну большинство техноголий оберонов общедоступны

sergey_m

а аффтар этого не знает, но ему и не нужно, он весь в своём выдуманном мире
То, что тебе совершенно неизвестно - не выдумано. У него вполне реальный свой мир, про который ты ничего не знаешь.
Большая часть участников этого раздела нашего форума не видят дальше своей тарелки. И ты, Fj, один из самых ярких
представителей этой проблемы. Из-за этой ограниченности многие ваши споры бесполезны и бесконечны.

garikus

Аххх. У меня времени нет, а вот ты можешь чисто по приколу найти таки ЕБНФ С и своего Оберона, и сравнить. Я почти уверен в результате. И если результат окажется таким, как думаю я, можешь ещё найти ЕБНФ шарпа. Конкретно по синтаксису они С почти не усложнили, хотя семантика стала несколько более загадочной (в основном из-за оверлоадинга).
Синтаксис компонентного паскаля в EBNF занимает 1 страницу печатного текста. Полное описание языка - 30 страниц. web-страница

sholeg

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

bleyman

> У него вполне реальный свой мир, про который ты ничего не знаешь.
Для начала конец поста, который AIX_D не запостил (и я, кажется, знаю, почему):
Если брать нынешнюю ситуацию, то основными промышленными языками в обозримом будущем видятся C++ и Java. Первый продвигается корпорацией Microsoft, второй -- IBM (в меньшей степени -- Sun). Язык Си благодаря огромному пласту UNIX-культуры, моды на Linux и роли высокоуровневого ассемблера свои позиции не потеряет. Что касается C#, то из-за провала планов блиц-крига Microsoft с повсеместным насаждением .NET (в лице Longhorn) его время еще не пришло (если вообще придет).
Что касается языка и среды Delphi, то их судьба более чем тревожная, прежде всего в силу превращения Borland в вотчину Microsoft. Java-инструментарий Borland (JIT-компилятор Java для Borland делался в Oberon microsystems) перспективы для развития имеет. Но Borland не без участия Microsoft все больше превращается в компанию, которая специализируется на системах поддержки жизненного цикла ПО (аналогично Rational для IBM). С уходом Delphi огромная армия Паскаль-программистов будет вынуждена искать альтернативы.
Но дело не только в более чем реальном уходе Delphi с рынка. Уже сейчас специалисты по Delphi остаются в индустрии невостребованными. А поскольку университеты стремительно сращиваются с индустрией, то Delphi будет вымываться из учебного процесса. Разумеется, если продолжать спокойно взирать на такое развитие событий.
Консерватизм отечественных преподавателей и защитная инертность России во многом спасает положение. Россия осталась, пожалуй, единственной страной в мире, где культура Паскаля (в том числе благодаря огромной многолетней популярности Turbo Pascal и Delphi) сохранилась в наибольшей степени. Было бы здорово, если бы мы смогли осознать, что в этом и состоит наше конкурентное преимущество.
Так вот, у аффтара мир, в котором M$ продвигает С++, а проект C# провалился. Этот мир к реальному миру имеет очень слабое отношение. И то, что он живёт в нереальном мире, его достаточно хорошо характеризует. В некотором смысле, я полагаю, это характеризует всех любителей языков, придуманных Никлаусом Виртом.
Ещё он очень забавно удивляется, как это так - жава стала широко используемым языком не за тридцать лет, а за пять. Выводов, правда, он сделать не может.
По поводу синтаксиса - да, у оберона он действительно проще. За счёт
а) отсутствия дополнительных слов типа register, static и т.д., которые нужны любому уважающему себя высокоуровневому ассемблеру;
б) вот тут я много смеялся. В обероне 3 уровна precedence of operators (сравнение, сложение, умножение 8(!) бинарных операторов: "+ - OR * / DIV MOD &" и 8 операторов сравнения. Нет, я тоже считаю, что 16 уровней приоритета операций в С - это немного многовато, их не очень просто запомнить, да. Но как люди могут жить без встроенного ксора, шифтов и инкремента - я не понимаю. Это неэффективно. Это замедляет работу программиста и УСЛОЖНЯЕТ восприятие кода: "if (a ^ b)" выглядит намного понятнее, чем "IF 0 # a & ~b) OR (~a & b THEN".
Вообще все паскалеподобные языки сосут из за своей многословности. Там где достаточно одного универсального символа "{" приходится писать разнообразные BEGIN, DO, THEN. А ещё Вирт, по ходу, вообще не знает слова "ортогональность". Ну как можно было сделать "OR" и "&" одновременно?
Если сравнивать оберон с С#, то у него нет шансов вообще. Ну вот пусть мне хоть один плюс оберона скажут!
ЗЫ: Я вижу дальше своей тарелки. Я вижу, что оберон, как и паскаль, - это язык подходящий для обучения студентов программированию. Очень странно видеть, что его пытаются использовать для решения реальных задач. Развитие Computer Science привело к появлению гораздо более удобных языков, которые и стОит использовать. Именно они в десятки и сотни раз повышают скорость написания высококачественного кода, а не "простота синтаксиса" (йоб йоб йоб твою мать, кто вообще такой бред придумал? Пишите на brainfuck, там ещё проще синтаксис бля. Объёмистый но логичный синтаксис рулит).
И я немножко нервничаю, когда вижу конец поста этого дяди. Потому что он означает, что этот дядя, ему подобные дяди и читающие тот форум легковнушаемые люди очень стремятся оказаться в роли преподавателей в школах и университетах и трахнуть детям мозги своей поебенью, от чего потом детям будет очень тяжело оправиться.

PS: А в чём "научность" языка, объясните мне кто-нибудь? В том, что его придумал профессор?
PPS: Да, двадцать лет назад была маза писать на обероне, наверное. Типа, он безопасней чем С конечно же. Хотя ада по слухам круче.

bleyman

> Если автор ничего не пишет про C#, то это не значит, что он про него ничего не знает, и что развитие оберона стоит на месте
А вы, батенька, пиздун. Извинитесь, что ли...

bleyman

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

garikus

Так вот, у аффтара мир, в котором M$ продвигает С++, а проект C# провалился.
Ну почему же, я считаю как раз наоборот. Откуда у тебя получаются такие странные выводы ? Я не запостил конец того поста, потому что мнение автора не совсем совпадает с моим и не относится к обсуждению твоего сообщения.
Ещё он очень забавно удивляется, как это так - жава стала широко используемым языком не за тридцать лет, а за пять. Выводов, правда, он сделать не может.
Я не забавно удивляюсь, я просто цитирую факт. Вообще, целью помещения той цитаты в тред был ответ на вопрос, почему оберон не популярен.
а) отсутствия дополнительных слов типа register, static и т.д., которые нужны любому уважающему себя высокоуровневому ассемблеру;
Оберон - не высокоуровневый ассемблер. Если нужен ассемблер - есть возможность писать в машинных кодах.


Code procedures

Code procedures make it possible to use special code sequences not generated by the compiler. They are 

declared using the following special syntax:

ProcDecl = PROCEDURE "[" SysFlag "]" IdentDef [FormalPars]

[ConstExpr {"," ConstExpr}] ";".

The list of constants declared with the procedure is interpreted as a byte string and directly inserted in the 

code ("in-line") whenever the procedure is called. If a parameter list is supplied, the actual parameters are 

pushed on the stack from right to left. The first parameter however is kept in a register. If the type of the first

 parameter is REAL or SHORTREAL, it is stored in the top floating-point register. Otherwise the parameter (or

 in the case of a VAR/IN/OUT parameter its address) is loaded into EAX. For function procedures the result 

is also expected to be either in the top floating-point register or in EAX, depending on its type. Be careful 

when using registers in code procedures. In general, the registers ECX, EDX, ESI, and EDI may be used. 

Parameters on the stack must be removed by the procedure.

Examples

PROCEDURE [codе] Sqrt (x: REAL): REAL (* Math.Sqrt *)

	0D9H, 0FAH; (* FSQRT *)

PROCEDURE [codе] Erase (adr, words: INTEGER) (* erase memory area *)

	089H, 0C7H, (* MOV EDI, EAX *)

	031H, 0C0H, (* XOR EAX, EAX *)

	059H, (* POP ECX *)

	0F2H, 0ABH; (* REP STOS *)

б) вот тут я много смеялся. В обероне 3 уровна precedence of operators (сравнение, сложение, умножение 8(!) бинарных операторов: "+ - OR * / DIV MOD &" и 8 операторов сравнения. Нет, я тоже считаю, что 16 уровней приоритета операций в С - это немного многовато, их не очень просто запомнить, да. Но как люди могут жить без встроенного ксора, шифтов и инкремента - я не понимаю. Это неэффективно. Это замедляет работу программиста и УСЛОЖНЯЕТ восприятие кода: "if (a ^ b)" выглядит намного понятнее, чем "IF 0 # a & ~b) OR (~a & b THEN".
Встроенный ксор и шифт нужны только для системного программирования. И эти средства есть, но они заключены в модуль SYSTEM.


Module SYSTEM contains certain procedures that are necessary to implement low-level operations. It is 

strongly recommended to restrict the use of these features to specific low-level modules, as such modules 

are inherently non-portable and usually unsafe. SYSTEM is not considered as part of the language 

Component Pascal proper.

Function procedures

	Name		Argument types	Result type		Description

	ADR(v)		any			INTEGER		address of variable v

	ADR(P)		P: PROCEDURE		INTEGER		address of Procedure P

	ADR(T)		T: a record type	INTEGER		address of Descriptor of T

	LSH(x, n)	x, n: integer type*	type of x	logical shift (n > 0: left, n < 0: right)

	ROT(x, n)	x, n: integer type*	type of x	rotation (n > 0: left, n < 0: right)

	TYP(v)		record type		INTEGER		type tag of record variable v

	VAL(T, x)	T, x: any type		T		x interpreted as of type T

	* integer types without LONGINT

Для бинарных операций над числами используются множества.
Инкремент / декремент есть - INC(a[, b]) / DEC(a[, b])
Насчёт "a & ~b) OR (~a & b" сейчас написать не могу
Вообще все паскалеподобные языки сосут из за своей многословности. Там где достаточно одного универсального символа "{" приходится писать разнообразные BEGIN, DO, THEN.
Спорное утверждение, что символы "{" и "}" лучше. Большую часть времени уходит на обдумывание алгоритма, а не на его кодирование. Поэтому на скорости написания это в конечном итоге не сказывается. Зато удобочитаемость лучше.
Ну как можно было сделать "OR" и "&" одновременно?
Это сделали для того, чтобы подчеркнуть, что у логического И более высокий приоритет (как и у отрицания, которое обозначается символом "~", а не "NOT").

garikus

> Если автор ничего не пишет про C#, то это не значит, что он про него ничего не знает, и что развитие оберона стоит на месте
А вы, батенька, пиздун. Извинитесь, что ли...
Можно поподробнее с этого места ?

garikus

Я вот в этом посте предложил прикольный чаллендж. Я внёс в исходный текст программы одну ошибку (вполне реальную и хочу посмотреть, как Апологет Программирования Без Дебаггера её найдёт. Сравнивать код с исходным - неспортивно. Ну-ка?
Делаю простой тест:


	PROCEDURE Do*;

		VAR a, b, c: Complex;

	BEGIN

		a.x := 1;

		a.y := 4;

		b.x := 2;

		b.y := 9;

		Push(a); Push(b); Add; Pop(c);

		StdLog.Real(c.x); StdLog.Real(c.y); StdLog.Ln

	END Do;

Запускаю. Вижу, что выводит всё время число a. Смотрю код процедур Add, а так же тех, которые она вызывает. Вижу, что Pop и Push написаны правильно (тестировать их бессмысленно). Понимаю, что ошибка в Add. Вспоминая логику работы, вижу, что значение суммы записывается не туда, куда нужно. Нахожу ошибку. Если бы было что-нибудь посложнее, использовал бы ASSERTы.
P.S.: Зная логику работы этого простейшего алгоритма, я бы не сделал такой ошибки. Я не считаю эту ошибку вполне реальной. Надо писать так, чтобы весь код состоял из небольших процедур / функций, и каждую нужно тестировать или вставлять ASSERTы для сохранения инвариантов там, где это не очевидно или когда уж совсем лень думать (дополнительные ASSERTы никогда не помешают).
Если ты надеялся на какие-то чудеса, то ты их не увидишь.

garikus

PPS: Да, двадцать лет назад была маза писать на обероне, наверное. Типа, он безопасней чем С конечно же. Хотя ада по слухам круче.
Спрашивается, на сколько C# лучше, чем оберон 20-летней давности ?

Dasar

> Спрашивается, на сколько C# лучше, чем оберон 20-летней давности ?
Смотря, какие задачи.
На практических - в разы.
ps
Попробуй, например, на обероне написать browser расшаренных файлов.

Dasar

> Если бы было что-нибудь посложнее, использовал бы ASSERTы
А теперь представь, что у тебя Word при какой-нибудь операции - налетел на Assert и вышел, вместе со всем текстом, который ты набирал несколько часов.
Как ощущения?
Как ты собираешься с этим бороться на Обероне?

rosali

Попробуй, например, на обероне написать browser расшаренных файлов.
А какое это имеет отношение непосредственно к C#? Просто в .NET богатая библиотека классов. Появится этот самый Zonnon (кажется так называется Oberon .NET?) и это все станет доступно из Oberona...
Просто C# настолько криво спроектированный язык, что никто не может отделить сам язык от библиотек, даже его создатели. Вроде бы IDisposable обычный библиотечный интерфейс, но нет, это часть языка (foreach, using). Также как и IClonable, IEnumerable, ISerializable, Object, ValueType, Exception,... Можно продолжать до бесконечности. У кого-то потом еще язык поворачивается говорить, что синтаксис C# записывать на одной странице. В итоге доходит до того, что уже всю библиотеку классов называют C#-ом. Хорошо хоть у C# всего одна реализация, а то вот бы комитет по стандартом ломал бы голову, какая реализация достойна называться C#-ом, а какая нет.

Dasar

> Просто C# настолько криво спроектированный язык, что никто не может отделить сам язык от библиотек
Зачем это надо?
Такой "синтактический сахар" сильно сокращает кол-во кода, увеличивает читабельность и уменьшает кол-во ошибок.
Ты видел код без использования foreach-а и using-а?
Тебе такой код нравится?

Dasar

> Также как и IClonable, IEnumerable, ISerializable, Object, ValueType, Exception,...
Где они используются в языке?
В языке только используется IEnumerable и IDisposable.

sasha79

а в throw можно кидать любые объекты или только инстансы потомков Exception?

bastii

в CLR любые вроде, в С# кидать только Exception, а ловить можно любые, используя catch без .

bastii

Какие проблемы. Так и надо. Все исключительно из прагматических соображений.

rosali

Какие проблемы. Так и надо. Все исключительно из прагматических соображений.
Проблемы такие, что вот захотели юниксоиды написать свой компилятор C#, а не могут понять, что программировать-то надо. У языка должно быть ядро, компиляцию которого и должен обеспечивать компилятор, и должны быть библиотеки, то что потом скомпилируется "само". А пока этого не будет, так и будем иметь один единственный C# от M$, который сам является своим определением.

Julie16

А какая разница-то? Грубо говоря, если штука ведет себя как надо, то значит все правильно. Пусть делают как угодно, лишь бы это согласовывалось с MS реализацией.

rosali

Где они используются в языке?
ISerializable и IClonable, насколько я понимаю компилятор имплементирует самостоятельно, так что это не "обычные" интерфейсы. Object и ValueType автоматически подставляются в предки для class-а и struct-уры, так что это тоже не "обычные" классы. Что еще?..

Dasar

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

Dasar

> ISerializable и IClonable, насколько я понимаю компилятор имплементирует самостоятельно, так что это
> не "обычные" интерфейсы. Object и ValueType автоматически подставляются в предки для class-а и struct-уры,
> так что это тоже не "обычные" классы.
Какое отношение это имеет к языку C#?

bastii

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

enochka1145

Java - что это за язык такой, который всё время меняется ?
Для эффективного программирования нужно следить за тем, что нового там появляется, и что становится deprecated.
Опять на Java наезжаешь?
1. Java не меняется, а расширяется (потихоньку)
2. Давай-ка вспомним... э-э...
- BASIC. Сколько их сейчас диалектов? Кто-нибудь считал?
- PASCAL. Можно возразить, что язык не менялся, это какой-нибудь Borland то Assign(file, filename то constructor, то ${I добавит. Только ведь без этого ничего особо интересного [широкой публике] не напишешь.
- C/C++. Кто-нибудь помнит, что такое auto? ОК, все помнят. А кто-нибудь видел? А overload? А исключения и RTTI с самого начала были? А ведь это относится к самому языку, а не к библиотечным функциям или классам, к которым относятся пометки "deprecated"

enochka1145

Далее.
// Для эффективного программирования нужно...
Для эффективного программирования нужно, чтобы сам процесс программирования был оперативным. Возьмём Eclipse, а лучше - IDEA. Переименовать переменную/класс/функцию? Не вопрос. Переместить код из одного места в другое? Один раз моргнуть. Дать совет по улучшению программы? Дай-ка секунду, ща обсудим твоих баранов...
Для такой работы IDE необходимо хорошее понимание того, как устроена программа. Ну, не когда остановится (или не остановится) на заданном входе , но хоть что-то. C++-у в этом смысле до Java пахать и пахать, и всё равно не допахать (из-за сравнительной простоты Java). Ну и нафига тогда столько универсальности?
ОК, давайте не наезжать на языки, а помнить, что для каждой задачи - свой инструмент.

Julie16

>для каждой задачи - свой инструмент.
Ага. И называется он С++.

bastii

Просто C# настолько криво спроектированный язык, что никто не может отделить сам язык от библиотек, даже его создатели. Вроде бы IDisposable обычный библиотечный интерфейс, но нет, это часть языка (foreach, using). Также как и IClonable, IEnumerable, ISerializable, Object, ValueType, Exception,...
Бред. Все там ясно (при желании разобраться, конечно что такое CLR, где язык и как он ложится на CLR. Все очень прозрачно. Так и задумывалось, и не только для C#. Наоборот основная идея, что есть вполне определенная CLR с библиотеками, а есть языки, каждый со своим синтаксисом. Языки с оригинальными конструкциями и особенной семантикой, но это вполне реально выразить в CLR, и, что более важно, ужить с CLI. Короче есть выбор, либо реализуй свой супер язык как супер дотнет язык (причем так, как ты этого хочешь, ограничений нет либо приводи его к виду, чтобы можно было взаимодействовать с другими языками. Все зависит о того, какие цели ты преследуешь. MS разработала CLS, как ориентир для создателей библиотек и языков, тебе решать как близко ты хочешь ей соответствовать.

bastii

Ага, согласен. Сегодня вообще важен общий экспириенс, теперь уже не только увязка языка с библиотеками, но и с IDE. По-настоящему чувствуешь разницу от использования дженериков при работе с коллекциями, когда работаешь в IDE уровня IDEA. Или взять к примеру partial classes в C# 2.0 -- сама фича бесполезная, но насколько проще код генерировать в отдельный файл.

bleyman

У меня складывается ощущение, что некоторая шизофреничность твоего склада ума в последнее время начинает приобретать угрожающие характеристики.
>
В ответ на:
--------------------------------------------------------------------------------
Так вот, у аффтара мир, в котором M$ продвигает С++, а проект C# провалился.
--------------------------------------------------------------------------------
Ну почему же, я считаю как раз наоборот. Откуда у тебя получаются такие странные выводы ? Я не запостил конец того поста, потому что мнение автора не совсем совпадает с моим и не относится к обсуждению твоего сообщения.
>
А мне пох как ТЫ считаешь. Я говорю про автора оригинального поста. Вы же разные люди, правильно? То, что ты не запостил конец его поста, а потом начал утверждать, что "автор не говорит о С# но знает о нём" - это пример наябывания общественности. Автор говорит о С#, причём такую херню, что лучше бы он не молчал. Автор и ты - разные люди!
----
> Спорное утверждение, что символы "{" и "}" лучше. Большую часть времени уходит на обдумывание
> алгоритма, а не на его кодирование. Поэтому на скорости написания это в конечном итоге не сказывается.
Когда решаешь олимпиадную задачку - да, иногда, особенно если ты идиот. В реальной жизни это не так совершенно. В реальной жизни зачастую обдумывают и кодируют вообще разные люди. Обдумывание, конечно, занимает своё время, но аргументировать этим то, что кодирование может быть и медленнее - это бред. Welcome to the real world!
> Зато удобочитаемость лучше.
Нет. Не лучше. Когда вообще все операторные скобки выглядят одинаково, а все остальные резервированные слова состоят из _одного_ слова, а не выглядят как "IF .. THEN .. ELSE .. ELIF .. THEN .. END", удобочитаемость лучше. Ну блиа, после пяти лет паскалепроганья и одной недели проганья на С мне стало это понятно.
> Встроенный ксор и шифт нужны только для системного программирования.
Да ну! У тебя просто опыта программирования нет, чувак.

bleyman

> Спрашивается, на сколько C# лучше, чем оберон 20-летней давности ?
Намного. То, что оберон имеет возраст 20 лет - это его недостаток а не плюс, между прочим. Ну и зачем вообще его использовать?
А, чуть не забыл:
> Это сделали для того, чтобы подчеркнуть, что у логического И более высокий приоритет (как и у
> отрицания, которое обозначается символом "~", а не "NOT").
У & такой же приоритет как у "* / DIV MOD". Выше чем у "+ - OR". Отрицание - вообще унарная операция. Чо-то я ваще не вижу систему
ЗЫ: Ну в чём же научность оберона, скажите мне!

bleyman

System namespace входит в стандарт. Некоторые его части - такие как System.Reflection, базовый тип Object, String, ValueType, Type, IDisposable, IEnumerable (и интерфейс для самого энумератора) просто нельзя оттуда выкинуть. Ну вот как ты Object выкинешь? Или Int32 хотя бы?

garikus

У & такой же приоритет как у "* / DIV MOD". Выше чем у "+ - OR". Отрицание - вообще унарная операция. Чо-то я ваще не вижу систему 


Logical operators:

	OR	logical disjunction

	&	logical conjunction

	~	negation

Arithmetic operators:

	+	sum

	-	difference

	*	product

	/	real quotient

	DIV	integer quotient

	MOD	modulus

Set operators:

	+	union

	-	difference (x - y = x * (-y

	*	intersection

	/	symmetric set difference (x / y = (x-y) + (y-x

String operators:

	+	string concatenation

Relations:

	=	equal

	#	unequal

	<	less

	<=	less or equal

	>	greater

	>=	greater or equal

	IN	set membership

	IS	type test

Всё.

garikus

Насчёт "a & ~b) OR (~a & b":
Нет, видимо, под двум причинам:
1) редко встречаются такие приложения, где эта операция постоянно нужна.
2) в отличие от OR и & ошибиться с ней гораздо легче.

garikus

Извините меня за то, что я такой дебил !
(~a & b) OR (a & ~b)
эквивалентно
a # b
похоже, мозги у меня совсем отсутствуют

sergey_m

Darkgray:
Попробуй, например, на обероне написать browser расшаренных файлов.
Darkgray:
А теперь представь, что у тебя Word при какой-нибудь операции - налетел на Assert и вышел, вместе со всем текстом, который ты набирал несколько часов.
Ну вот, опять примеривание к своей тарелке. На свете есть другие задачи!

Helga87

Посты читаем?

garikus

Кстати, и это можно.
OS Oberon написана на обероне. Там даже http-browser и ftp-client есть.

sergey_m

То есть практическими задачами считаем только задачи из своей тарелки?

Helga87

Практическими задачами считаем те, что встречаются чаще.
С этой точки зрения задача организации работы с расшаренными папками практическая.

sergey_m

Практическими задачами считаем те, что встречаются чаще.
Встречаются чаще тебе?

Dasar

> Ну вот, опять примеривание к своей тарелке. На свете есть другие задачи!
Приведи примеры. Пока мне кажется, что ты говоришь про каких-то сферических коней в вакууме.
Какое кол-во задач позволяет иметь пользователя и программиста в одном месте и в одно время?
Что происходит, если программа налетела на assert, и программиста нет в этот момент под рукой?
Ps
До сих пор вспоминаются проблемы с космической техникой, когда отказы компьютеры были вызваны переполнением в каких-то левых модулях, с последующей выдачей assert-ов и полным остановом программ.
pps
Приведи, пожалуйста, области - где полный останов программы лучше, чем какое-то хромание дальше?
Назови, пожалуйста, области в которых программист и пользователи находятся в одной флаконе.
Такое пример я знаю только один - offline расчеты - когда пользователь сам же и программирует расчет - после аварийного останова он может быстро увидеть ошибку, исправить ее и запустить расчет заново.

Helga87

Берем всех программистов. Смотрим, кто из них решал такую задачу. Делим на число программистов. Получаем то, насколько задача часто встречается.

Julie16

Я думаю это число будет == 0.

Helga87

Ты не прав. Я такую задачу решал, значит нулю число уже не равно

garikus

Что происходит, если программа налетела на assert, и программиста нет в этот момент под рукой?
...
Приведи, пожалуйста, области - где полный останов программы лучше, чем какое-то хромание дальше?
Какое может быть "хромание" дальше ? Ни о какой надёжности тогда речи быть не может.
А вообще есть возможность отключить все ASSERTы. Но нужно хорошо подумать перед тем, как это делать.

sergey_m

Берем всех программистов.
Каким образом?
Смотрим, кто из них решал такую задачу. Делим на число программистов. Получаем то, насколько задача часто встречается.
Скорее всего в лидерах задач будут веб-магазин или форум на php. Означает ли это что остальные задачи менее важны? Означает ли это, что все остальные языки не нужны?

Julie16

1/10^x == 0, x > 6.

Helga87

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

sergey_m

> Какое кол-во задач позволяет иметь пользователя и программиста в одном месте и в одно время?
Положительное и отличное от нуля. Это означает, что данные язык востребован.
> Что происходит, если программа налетела на assert, и программиста нет в этот момент под рукой?
core dumped
> Приведи, пожалуйста, области - где полный останов программы лучше, чем какое-то хромание дальше?
Ядро операционной системы.
> Назови, пожалуйста, области в которых программист и пользователи находятся в одной флаконе.
Научные рассчеты. Системное администрирование.

sergey_m

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

bastii

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

Helga87

Продолжи мысль. Остальные задачи не являются практическими?
Продолжаю. Среди остальных задач тоже дофига практических.

garikus

Там нет фич. Ничего лишнего.

Dasar

> Какое может быть "хромание" дальше ? Ни о какой надёжности тогда речи быть не может.
Это означает, что ты не ботал теорию.
Есть ряд направлений, которые как раз занимаются тем, что изучают как проектировать надежное ПО, которое работает в ненадежном окружении.

voronetskaya

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

sergey_m

Продолжаю. Среди остальных задач тоже дофига практических.
А как же: ?

garikus

согласен.. и где это можно почитать?

Dasar

> core dumped
Что в этом хорошего для пользователя?
> Ядро операционной системы.
Драйвер мышки тоже должен assert-ы выкидывать?
> Научные рассчеты. Системное администрирование.
Ок, согласен. В этих областях assert-ы уместны.
Каким образом должно быть спроектировано ПО в других областях? и можно ли там использовать assert-ы?

sergey_m

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

voronetskaya

вот именно с такой аргументацией

Helga87

Верно.
Но кто нас просил останавливаться на топ-2? Возьмем, например, топ-10000. Или топ-100000. Как ты понимаешь, четкой границы установить нельзя, есть только, как говорят физики, "характерная граница спектра".
Согласись, что задача, которую решает один человек на миллион назвать практической нельзя. Также очевидно, что задача, которую решает каждый из сотни - практическая.

garikus

и это зависит от языка ?

sergey_m

> Что в этом хорошего для пользователя?
Для него это меньшее зло, чем потерянные данные или вход программы в бесконечный цикл.
> Драйвер мышки тоже должен assert-ы выкидывать?
Конечно. Лучше падать, чем записывать данные по испорченному указателю.
Наверное мы говорим о разных вещах. Ты о проверке входных данных, а я об ошибках программирования. Возможность ловить assertы приводит к привычке использовать их для проверки валидности внешних данных. В моей тарелке assertы нельзя ловить, она все вызывают core dump. Они используются только для ловли багов. Конечно, это не отменяет необходимости проверки внешних данных, это даже увеличивает необходимость проверки. Только проверка делается классическими методами: число сравнивается с нулём перед тем, как на него делить, вместо того что бы делить и потом ловить assert.

sergey_m

Согласись, что задача, которую решает один человек на миллион назвать практической нельзя. Также очевидно, что задача, которую решает каждый из сотни - практическая.
Не соглашусь. Возьмём к примеру программу - DNS сервер. Таких программ написано очень мало - можно пересчитать по пальцам. Их пишет ничтожно малое количество человек, в сравнении с сообществом веб-программистов. Это не практическая задача?
За файловой системой UFS по большому счёту стоит 1 человек. Она (или её аналоги написанные еще горсткой людей) используются во множестве операционных систем.
Но эти вещи лежат на поверхности. Мы про них знаем потому, что ими пользуемся. А сколько лежит вне нашего поля зрения? Управление промышленными процессами. Метеопрогнозы. И т.д., и т.п.

Dasar

> Для него это меньшее зло, чем потерянные данные или вход программы в бесконечный цикл.
Почему ты думаешь, что данные теряеются только во время работы, а не во время останова?
Что мешает дополнить программу самодиагностикой? Которая отслеживает, и первые, и вторые проблемы, и как-то их решает?
Ты постянно забываешь про внешний мир.
Представь, что эта программа чем-то управляет (машиной, насосом, светом, водой, деньгами, безопасностью, сердцем и т.д.).
Что произойдет с этим управлением, если программа встанет?
Или программа, наоборот, собирает какие-то данные.
Что просходит со сбором данных, если программа стоит?
Что произойдет, если программа встает из-за того, что какой-то левый датчик отказал и начал выдавать данные за непредусмотренным диапазоном?

Dasar

> Не соглашусь. Возьмём к примеру программу - DNS сервер. Таких программ написано очень мало - можно пересчитать по пальцам. Их пишет ничтожно малое количество человек, в сравнении с сообществом веб-программистов. Это не практическая задача?
Давай возьмем совокупный параметр:
f(как много людей пользуются программой, как много людей пишут такие программы)
Таким критерием можно пользоваться?

sergey_m

> Почему ты думаешь, что данные теряеются только во время работы, а не во время останова?
И там и там теряются.
> Что мешает дополнить программу самодиагностикой? Которая отслеживает, и первые, и вторые проблемы, и как-то их решает?
Ни что не мешает. Я ведь не спорю с тем, что программа должна проверять все возможные проблемы. Я снова замечу, что мы вкладываем разные смыслы в понятие assert. Если я не ошибаюсь, ты имеешь в виду ошибку во внешних данных. Я же имею ввиду ошибку в логике программы. Я не спорю с тем, что все внешние данные надо тщательно проверять, и что нахождение ошибки в них не должно быть критическим событием.
Ты постянно забываешь про внешний мир.
Представь, что эта программа чем-то управляет (машиной, насосом, светом, водой, деньгами, безопасностью, сердцем и т.д.).
Что произойдет с этим управлением, если программа встанет?
Пиздец произойдёт.
Или программа, наоборот, собирает какие-то данные.
Что просходит со сбором данных, если программа стоит?
Опять пиздец. Не надо меня убеждать, что это плохо когда программа стоит. Я знаю.
Что произойдет, если программа встает из-за того, что какой-то левый датчик отказал и начал выдавать данные за непредусмотренным диапазоном?
Наверное возьмут за яйца автора драйвера(модуля) левого датчика. За то, что он допустил в драйвере ошибку - вся программа стопится, если отказал датчик.

sergey_m

Давай возьмем совокупный параметр:
f(как много людей пользуются программой, как много людей пишут такие программы)
Таким критерием можно пользоваться?
Таким наверное можно. Вот только сложно входные данные найти. Сколько людей пользуются программным обеспечением, которое управляет АЭС? Сколько людей пользуются программой управляющей светофорами в центре Москвы?
Сколько людей пользуются программой на редком языке, которой выполняется какой-то квантовый расчёт? Ноль. А если через 5 лет, будет найдено новое лекарство или новый материал? А если найдёт не эта программа, а программа которая писалась в соседней лабе? Можно ли первую считать бесполезной и не практической?

Dasar

> согласен.. и где это можно почитать?
из простейшего - например, транзакции - можно легко показать, что assert-ы (в виде останова) и транзакции не совместимы

Helga87

Не соглашусь. Возьмём к примеру программу - DNS сервер. Таких программ написано очень мало - можно пересчитать по пальцам. Их пишет ничтожно малое количество человек, в сравнении с сообществом веб-программистов. Это не практическая задача?
За файловой системой UFS по большому счёту стоит 1 человек. Она (или её аналоги написанные еще горсткой людей) используются во множестве операционных систем.
Отличные примеры.
Актуальные - да. Т.к. ими пользуются много людей.
"Задача проектирования и реализации файловой системы UFS" - непрактическая, т.к. с ней столкнулся всего один человек. А вот "задача реализации файловой системы" - практическая. Ею занимается дофига народу.
Про dns-сервер.
Редкий мутант сможет пересчитать количество реализаций dns-серверов по пальцам - их больше полусотни. Т.е задача достаточно практическая. Пусть и менее практическая, нежели тот же форум.

garikus

если действительно интересно - можешь установить, например, BlackBox (ftp://netinfo.hackers/pub/aix/blackbox15beta.exe) и посмотреть, что это такое.

sergey_m

"Задача проектирования и реализации файловой системы UFS" - непрактическая, т.к. с ней столкнулся всего один человек.
У тебя извращенное определение слова "практический". Ознакомься с толковым словарём:


 	ПРАКТИЧЕСКИЙ прил.

      1. Соотносящийся по знач. с сущ.: практика, связанный с ним.

      2. Занимающийся применением каких-л. знаний на деле, развивающий умения, знания, опыт в сфере какой-л. деятельности.

      3. Необходимый для практики в какой-л. области деятельности.

      4. Относящийся к сфере жизненного опыта, связанный с реальными потребностями быта.

      5. Хорошо разбирающийся в делах, интересах и потребностях быта; деловитый, опытный.

      6. Легко применяемый на деле, на практике; экономный, удобный, практичный.

Где здесь "количество людей", черт возьми?
Редкий мутант сможет пересчитать количество реализаций dns-серверов по пальцам - их больше полусотни. Т.е задача достаточно практическая. Пусть и менее практическая, нежели тот же форум.
Полусотни? Я вот только пять знаю и то, у двух название одинаковое. Ты наверное любую попытку считаешь программой? Тогда наверное число шеллов тоже очень велико - сколько студентов с ВМК выпустилось, т.к. каждый пытался шелл писать.

Helga87

У меня зашибись понятие практической задачи. Возьмем, например, задачу, которая является непрактической в моем определении. Из этого следует, что на практике я скорее всего с ней не столкнусь (определение 1). Значит, мне не обязательно обладать знаниями и опытом в области, относящейся к этой задаче. (определения 3-4).

Helga87

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

sergey_m

У меня зашибись понятие практической задачи. Возьмем, например, задачу, которая является непрактической в моем определении. Из этого следует, что на практике я скорее всего с ней не столкнусь (определение 1). Значит, мне не обязательно обладать знаниями и опытом в области, относящейся к этой задаче. (определения 3-4).
Молодец. Ты прекрасно проиллюстрировал то, что я называю "не видеть дальше своей тарелки".

sergey_m

Я погуглил, у меня получилась цифра в районе полусотни. Сколько из них популярно - не знаю. Но с этой задачей столкнулось довольно много народу, это факт.
Гуглил по запросу "DNS server"? Не понимаю, как с помощью поисковика можно оценить число софта реализующего DNS сервер.

Julie16

http://freshmeat.net/browse/149/

Helga87

Значит, мне не обязательно обладать знаниями и опытом в области, относящейся к этой задаче.
Добавлю для ясности. Если такая задача все-таки встретится, в этот момент и произойдет пополнение багажа знаний. Lazy learning

sergey_m

> http://freshmeat.net/browse/149/
Можно еще ls /usr/ports/dns.
Только это далеко не всё сервера, из тех что сервера, далеко не всё полноценные сервера, и далеко не все полноценные сервера пригодны к использованию.

Dasar

> Я ведь не спорю с тем, что программа должна проверять все возможные проблемы.
Сразу скажу, что это невозможно.
Допустим у нас есть N-функциональных точек, правильное прохождение (при отсутствии ошибок) - это один вариант,
вариантов же прохождения при наличии ошибок - это 2^N.
Ошибки - это и нехватка памяти, и отсутствие места на винте, и отказ датчиков, и нехватка ресурсов процессора, и ошибки в других модулях и т.д.
Резюмирую:
1. Все проблемы на этапе разработки предусмотреть нельзя (просто потому, что их кол-во растет экспонециально)
2. Поэтому программа должна вести себя адекватно, даже при наличии незапланированных ошибок.
соответственно core dump, assert - это утопическая полумера, т.к. эти средства не борются с незапланированными ошибками, а просто опускают руки при их наличии.
> Я же имею ввиду ошибку в логике программы.
Как ты отличаешь ошибку в логике программы от ошибки во внешних данных?


int a = b/c;

если 'c' может принимать значение 0 - это ошибка в логике, или во внешних данных?
если памяти перестало хватать - это ошибка в логике, или во внешних данных?

sergey_m

> Сразу скажу, что это невозможно.
Потому, что 2^N это много? Ты наверное хотел сказать, что это тяжело.
> 2. Поэтому программа должна вести себя адекватно, даже при наличии незапланированных ошибок.
А вот это как раз не возможно.
если 'c' может принимать значение 0 - это ошибка в логике, или во внешних данных?
Если может, то ошибка в логике.
если памяти перестало хватать - это ошибка в логике, или во внешних данных?
Во внешних данных. Поэтому её наличие надо всегда проверять.

Dasar

> Потому, что 2^N это много? Ты наверное хотел сказать, что это тяжело.
У меня в простенькой программе - функциональных точек больше 1000-чи.
Сколько будет 2 в степени 1000?
Это обозримое число?
> Во внешних данных. Поэтому её наличие надо всегда проверять.
Ну, проверил, памяти нет и что дальше?
Проблема в не самой проверке, а в том какое решение надо принять, если памяти нет?
Где-то можно задачу отложить, где-то можно использовать другое решение (может быть менее точное, но зато менее ресурсоемкое где-то можно попробовать повторить еще раз на удачу, где-то можно попросить пользователя высвободить память, где-то можно прервать текущую задачу, где-то можно приостановить задачу до лучших времен и т.д.
Для правильного решения - и необходимо расмотреть все 2^N вариантов

Dasar

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

sergey_m

И решение - завершить программу (core dumped) - самое простое и самое "детское" (внешний мир меня обидил, поэтому я больше ничего делать не буду).
Не так. "Во мне ошибка, я могу упасть от неправильного инпута, я больше ничего делать не буду."

sergey_m

У меня в простенькой программе - функциональных точек больше 1000-чи.
Сколько будет 2 в степени 1000?
Это обозримое число?
Ты мне заморочил голову. 2^N - это количество code path, но не количество проверок. Количество проверок - N.
Ну, проверил, памяти нет и что дальше?
Проблема в не самой проверке, а в том какое решение надо принять, если памяти нет?
Спасибо я знаю. В чём ты пытаешься убедить меня? В том, что какая то волшебная технология выберет решение за меня?

Dasar

> В чём ты пытаешься убедить меня? В том, что какая то волшебная технология выберет решение за меня?
В том, что отказавшись от core dumped, можно внешним образом запрограммировать несколько моделей поведения во время ошибки.
Например, возьмем desktop-приложения, одна из стратегий - откатить действие до момента нажатия пользователем на кнопку.

sergey_m

В том, что отказавшись от core dumped, можно внешним образом запрограммировать несколько моделей поведения во время ошибки. Например, возьмем desktop-приложения, одна из стратегий - откатить действие до момента нажатия пользователем на кнопку.
Программа записала мусором какой-то пойнтер, произошел segment violation, ты его поймал. Решил откатить действие. Но оказалось, что программа записала мусором и ту структуру, в которой ты хранил всю информацию для отката. Получился не откат, а переход в какое-то другое состояние.

Marinavo_0507

> откатить действие до момента нажатия пользователем на кнопку
кстати, когда уже это будет просто?
microsoft ничего не обещает по этому поводу?
просто - это типа такого:


a = 1; 

transaction {

  a = 2;

  rollback;

}
и на выходе a==1

Julie16

Кстати, о таком языке я мечтаю уже давно (только не надо про SQL)

Marinavo_0507

Есть мнение, что это не очень хорошо ложится на ООП, вот и приходится изобретать transaction servers всякие, к которым слово "просто" уже никак не применимо.

Julie16

> Есть мнение, что это не очень хорошо ложится на ООП
А почему? Где об этом подходе вообще можно почитать?

Dasar

> Программа записала мусором какой-то пойнтер, произошел segment violation, ты его поймал
Поэтому и идет речь о том, что надо выбирать такие языки, которые защищают от segment violation

Dasar

> Есть мнение, что это не очень хорошо ложится на ООП, вот и приходится изобретать transaction servers всякие, к которым слово "просто" уже никак не применимо.
На open ООП нормально ложится, на закрытый ООП - да, хуже.

Marinavo_0507

Ты вроде haskell собирался ботать. Наверняка там это просто сделать монадами.

Dasar

> Ты мне заморочил голову. 2^N - это количество code path, но не количество проверок. Количество проверок - N.
Нет, именно 2^N.
Допустим у нас есть задача - для нормального ее выполнения ей нужна память, винт, датчик.
Хороший - вариант один.
Ошибочных же вариантов - 2^N -1
1) Что делать если не хватает памяти?
2) Что делать если не хватает винта?
3) Что делать, если идет отказ датчика?
4) ЧТо делать, если одновременно не хватило памяти и отказал датчик?
5) ЧТо делать, если одновременно не хватило винта и отказал датчик?
и т.д.
варианты 1 и 3, 2 и 5 - не одиннаковы
т.к. если мы время отказа датчика - формируем сообщение и выводим его на винт.
то если мы не предусмотрели варианты 4 и 5, то будет все "плохо".
ps
Еще раз напоминаю, что ошибку мало диагностировать - необходимо еще сформировать адекватный выход из ошибки.
и если диагностик действительно N, то ситуаций требующих решения - 2^N

sergey_m

> Поэтому и идет речь о том, что надо выбирать такие языки, которые защищают от segment violation
По-моему я и описал случай такой защиты, не так ли?

sergey_m

Ошибочных же вариантов - 2^N -1
Если их комбинировать, то да. Но не могу представить себе случай, когда нужно действительно рассматривать все комбинации.

Dasar

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

Dasar

> Есть мнение, что это не очень хорошо ложится на ООП, вот и приходится изобретать transaction servers всякие, к которым слово "просто" уже никак не применимо.
Сложного там тоже ничего нет, применение скорее громоздкое, чем сложное.
Что может быть сложно в реализации интерфейса из трем методов - выполнение, фиксация, откат?
ps
На сколько я понимаю, ООП поэтому и рулит, что благодаря ООП - большая задача рубится на кучу мелких, которые решаются по отдельности.
В итоге, решение получается громоздкое, но зато каждый отдельный кусочек - сам по себе простой, и может быть легко реализован.

Marinavo_0507

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

Dasar

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

Dasar

Да, и второй путь - еще к тому же лучше масштабируется.

Marinavo_0507

Почему-то для трансляции из C в маш.код не нанимают помощников, а используют компилятор.

Dasar

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

Marinavo_0507

> просто оказалось - что работы по переводу C в Asm оказалось на столько
> много, и она оказалось настолько простая
Средства для перевода из C# в IL и далее в маш.код были придуманы раньше, чем появились люди, которым это "надо". Аналогично с Java.
Задачи эти тоже не простые, если принять во внимание необходимость оптимизации.
Поэтому я и спросил, не обещает ли Microsoft и про транзакции что-нибудь?

Dasar

> Поэтому я и спросил, не обещает ли Microsoft и про транзакции что-нибудь?
Транзакции намного сложнее, чем генерация кода.
Транзакции очень тяжело резать на независимые части.
Как ты собираешься автоматически восстанавливать состояние?

Marinavo_0507

> Как ты собираешься автоматически восстанавливать состояние?
А какие проблемы?

Julie16

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

Marinavo_0507

Это не зависит от того, вручную ты откатываешь или автоматически.

Julie16

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

Dasar

> А какие проблемы?
Проблема в том, что для правильного отката необходимо знать, что именно мы меняем.
Этим знанием обладает только программист, а программа этим знанием не обладает.
ps
Если в генерации кода все однозначно, то в транзакциях - нет, т.к. обратное действие можно делать разными способами, получая при этом разное поведение
В генерации кода - если написано a=2, то это всегда означает, что в переменную a надо положить 2.
Простенький пример:


a = 2

b = 3;

Откатывать мы можем так:


a = old_a;

b = old_b;

или так:?


b = old_b;

a = old_a;

или так:


world = old_world;

Равнозначны ли эти откаты?
Кто кроме программиста знает как правильно сделать откат в данном случае?

Dasar

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

Marinavo_0507

> Если возможно ручной откат, то это не означает автоматом, что можно
> запрограммировать автоматический откат.
В ряде случаев автоматический откат тривиален.
В частности, если если не было i/o.
А если было, то в общем случае придётся процедуру отката описывать явно (но во многих важных частных случаях можно надеятся на автоматическую (либо скрытую в библиотеке) генерацию).

Dasar

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

sergey_m

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

Dasar

> Еще раз повторю (который, уже раз? что я привык завершать программу при ошибке, которой "не может произойти", то есть при сбое логики программы
Т.е. при любой незапланированной ошибке ты завершаешь программу?
например, при нехватке памяти или отвале винта?
при чем даже, если это были вспомогательные действия?
> Ошибки, которые находит парсер, не являются ошибками в программе, так что это вообще не корректный пример.
Какая разница? Проблемы те же, действия те же...

evgen5555

например, при нехватке памяти или отвале винта?
при чем даже, если это были вспомогательные действия?

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

sergey_m

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

Dasar

> Лично мне не видится причин, по которым необходимо продолжать исполнение
Рассмотрим такой пример:
Редактируем картинку в photoshop-е, долго редактируем, несколько часов редактируем, но при вставке еще одного слоя - память кончилась - и photoshop зачем-то аварийно завершается, вместо того, чтобы просто откатить последнюю команду?
Нормальное ли это поведение с точки зрения пользователя?
Или другой пример:
У программы управления заводом, ракетом, автомобилем - при выдаче команды "включить насос" - кончилась память (или произошел обрыв цепи) - программа завершилась.
Насколько тяжелы последствия?
Что мешало заводу/ракете/автомобилю продолжать жить без этого насоса?

Dasar

> Чёрт возьми, неужели я так не понятен? Нет, нет и нет. При логической ошибке. При ошибке, которая никогда не произойдёт в идеальной программе, написанной без ошибок.
Я до сих пор не понимаю, почему и как ты отделяешь логические ошибки от других ошибок.
И как программа у тебя понимает, когда произошла логическая ошибка, а когда - нет?
Допустим нам надо было выполнить следующию последовательность действий:


A

B

C

Действие B, по тем или иным причинам, не выполнилось, хотя мы изначально предполагали, что оно должно всегда выполняться. Это логическая ошибка или нет?
> Нет. Проблемы не те же. Когда ты находишь ошибку в инпуте, то ты уверен в консистентности инвариантов программы. Когда же находишь ошибку в последних, то нет.
Вспоминая Фон Неймана - сама программа - это такие же входные данные, как и инпут.
Что мешает исправить программу, и ее состояние - на ходу?
Почему, например, живые организмы - правят себя на ходу - а не вылетают в кору?

Marinavo_0507

Для такого отката - на этапе компиляции(принятия решения) должен быть доступен весь код (чтобы можно было гарантировать отсутствие побочных эффектов).
Разве в .Net нельзя принять такое решение на этапе инсталляции приложения, когда анализируется код (в MSIL) всех библиотек?

Dasar

> Разве в .Net нельзя принять такое решение на этапе инсталляции приложения, когда анализируется код (в MSIL) всех библиотек?
В общем случае - нет, конечно, т.к. как минимум - часть кода можно сгенерить в runtime-е, или получить с другого компьютера, и самое главное - на этапе компиляции - никто не знает - какой кусок кода какой другой кусок кода будет вызывать.
Ключевая особенность .Net-а - это то что работа происходит через определенный виртуальный интерфейс, за которым может быть все что угодно.
И уже только при реальном исполнении, при чем только в самый последний момент мы можем понять - с каким кодом мы будем реально работать.

Marinavo_0507

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

Dasar

> Всё, исходя из моих слов, можно расширение C#, поддерживающее транзакции, сделать.
Поддерживающие транзакции - да, можно сделать.
но автоматический откат сделать нельзя - по крайней мере, в реальной жизни.

Marinavo_0507

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

Dasar

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

Marinavo_0507

> В мультиагентной системе - где окна это отдельные агенты - это будет
> сделано "само".
сейчас это делается?


button.setColor(BLACK);

transaction {

  ...

  button.setColor(RED);

  ...

  rollback;

  ...

}

Dasar

нет, не делается - потому что окна сейчас не являются агентами.

Marinavo_0507

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

bleyman

Господа, вы долбанулись.
Глебиус мастерски перевёл тему на "распространённые задачи" и "транзакционное программирование".
1) "Распространённых задач" не бывает. Но это не важно.
2) Я лично видел работающую схему откатов. В OpenGL она реализуется через glPushXXX/glPopXXX. Конечно, на ООП она плохо ложится, и жрёт дофига памяти и кода. Ещё можно писать все классы как Serializable и делать контрольные точки, это намного проще. Если как следует подумать, то это совсем просто.
3) Ваще-то мы обсуждаем недоязык Оберон. Я читал подиагонале, конечно, но! Я не заметил ответа на прямой вопрос: в какой конкретно задаче Оберон лучше чем С# ?
4) Ещё я не увидел комментариев к моему заявлению что простой синтаксис сосёт. Синтаксис должен быть ортогональным, логичным, но вот простым ему быть вовсе не обязательно, и даже наоборот - наличие большого количества синтактик шугара существенно упрощает и ускоряет как написание, так и понимание программы. Все согласны?
5) Так на чём всё-таки основывается заявление, что "оберон - это научный подход, а С - ремесленный"?

enochka1145

Присоединяюсь.
Хочу знать, почему Оберон научный и клёвый.
Хочу знать, почему Оберон научный и клёвый.
Хочу знать, почему Оберон научный и клёвый.

sergey_m

Я до сих пор не понимаю, почему и как ты отделяешь логические ошибки от других ошибок.
Проверки инвариантов. Проверка того, что сумма элементов в списке равна длине списка прописанной в его заголовке. Проверка того, что вход в функцию, осуществляющую неатомарное редактирование структуры происходит с взятым мьютексом. Проверка того, что мы не держим мьютексов когда блокируемся.
Допустим нам надо было выполнить следующию последовательность действий:A B C
Действие B, по тем или иным причинам, не выполнилось, хотя мы изначально предполагали, что оно должно всегда выполняться. Это логическая ошибка или нет?
Как это не выполнилось? Если B вернуло ошибку, то это не логическая ошибка, такое нужно обрабатывать. Если же B вернулось без ошибок, но не сделала что-то жизненно важное для C то надо падать, т.к. в программе ошибка.
Вспоминая Фон Неймана - сама программа - это такие же входные данные, как и инпут.
Что мешает исправить программу, и ее состояние - на ходу?
Почему, например, живые организмы - правят себя на ходу - а не вылетают в кору?
Мне даже лень отвечать серьёзно на этот вопрос. Если бы программа могла себя сама исправить, то почему бы программистам не писать наброски программ, а дальше они уже сами будут совершенствоваться. А что мешает программе написать себя самой?

Dasar

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

sergey_m

Если ты не умеешь писать самовосстанавливающиеся программы - это не означает, что никто не умеет.
А кто умеет?

Dasar

Хорошо пока никто не умеет,
заниматься, например, самолечением сейчас IBM начинает
http://www.google.ru/search?hl=ru&ie=UTF-8&q=self+healing+ibm&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=
http://www.internetnews.com/ent-news/article.php/3090091

Dasar

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

sergey_m

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

Dasar

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

Marinavo_0507

В некоторых случаях такого не получается.
Например, scrubbing для ecc memory считается полезной фичой.

Dasar

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

Julie16

Вообще говоря я не согласен. Кто будет проверять на правильность код, который исправляет ошибки? Еще один такой же код? И так до бесконечности? ИМХО надо делать autosave. А не придумывать мифические схемы исправления ошибок.

Marinavo_0507

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

Dasar

> Кто будет проверять на правильность код, который исправляет ошибки?
Тот же, кто сейчас проверяет правильность обычной программы
ps
Ты уверен - что в тебе, как в живом организме - все работает правильно?
но благодаря, самодиагностике и самовостановлению - ты продолжаешь жить и развиваться.
> ИМХО надо делать autosave
И что дальше?
В desktop-ных приложениях - это может быть поможет.
Как быть с управлением чего-либо, особенно если учесть, что save - это такая же часть программы, и в них тоже могут быть ошибки?
Да, я надеюсь - тебя не смущает, что текущие desktop-ные программы занимаются самолечением save-ов?

Marinavo_0507

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

Dasar

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

Julie16

>Как быть с управлением чего-либо
Программы управления чем-либо обычно очень маленькие и компактные, и к тому же для них можно рассчитать все необходимые ресурсы заранее(кстати в подавляющем большинстве случаев так и делается). И вообще: как ты представляешь себе самолечение в RT? ИМХО самолечение никак не укладывается в O(1 так как надо прочекать и проверить множество управляющих структур, а представь себе что прога по управлению реактором занялась самолечением, и в этот момент пошла неуправляемая ядерная реакция?(я конечно немного преувеличиваю, обычно такие вещи детектируются на аппаратном уровне)

Dasar

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

Julie16

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

Dasar

> ИМХО самолечение никак не укладывается в O(1 так как надо прочекать и проверить множество управляющих структур
Значит надо ставить компьютер, который может без напрягов рассчитать O(n) для n, например, меньше 1e7

Julie16

Нет. Нельзя. Так как такой комп заведомо очень сложен. И в опасную зону НИКТО не будет ставить такой комп. Так как риск очень велик. В таких системах до сих пор очень популярны процы класса 86 - 386.

Dasar

> Нет. И за такое и посадить могут.
Это если нет аварийных контуров.
Да, и контроллеры маленькими и компактными сейчас не назовешь.
Последнее время используются, в том числе, и 486-е с 16 метрами памяти.
ps
Из практики :
охлаждение внешнего контура реактора, охлаждение ТЭЦ, управление климат-контролем, управление мелкими заводами (дрожжевыми, сахарными, другими c/х - производством) - делается в том числе и на персоналках - просто потому, что разработка намного дешевле.

Dasar

Да, на западе - в банкоматы, на автомобили, на корабли - также обычно ставится, в том числе, и обычный windows.

Julie16

>на корабли
Помню, помню, было дело

maggi14

в метро мадридском, например, винда стоит. А иногда висит.

Ivan8209

4. Нет. Сосёт сложный синтаксис.
Число Ингве.
5. Читать про различие американской и европейской
конструкторской школы.
---
...Я работаю антинаучнымм аферистом...

Ivan8209

Из-за таких вот людей и считается,
что цикл проще рекурсивного соотношения.
Объяснить школьнику, знающему основы алгебры,
что такое рекурсия, труда не составляет.
В частности, именно таким образом вводят те же числа Фибоначчи.
Если кто захочет пример покруче, легко:
пусть напишет функцию Аккермана без рекурсии.
---
...Я работаю антинаучным аферистом...

Ivan8209

Оставайся глубоко убеждённым.
---
...Я работаю антинаучным аферистом...

FRider

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

Ivan8209

Считай её примером схемы решения задач, на которых так легко ломаются
те, кто не знает про рекурсию.
---
...Я работаю антинаучным аферистом...

FRider

Э... то есть это вещь в себе? Или просто не более чем учебный пример?

Ivan8209

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

FRider

Не понял опять.
Слово "рефакторинг" тут для красного словца, или есть виды рефакторинга, которые лучше делать с помощью функции Аккермана. И как это делается?

Landstreicher

> что цикл проще рекурсивного соотношения.
Есть какие-то свидетельства, что это не так?
> Объяснить школьнику, знающему основы алгебры,
> что такое рекурсия, труда не составляет.
Рекурсию надо долго объяснять, цикл -- понятен интуитивно.
> В частности, именно таким образом вводят те же числа Фибоначчи.
Те же числа Фибоначчи легко и просто считается циклом за линейное время. В то же время, рекурсия занимает экспоненциальное время, и какие-то способы ее сворачивания гораздо сложнее, чем цикл.
Рекурсия хороша для построения математических моделей. Но для практики, в частности, для написания работающих программ, она обычно непригодна. Не путайте написание программ и построение математических моделей - это 2 большие разницы!
> Если кто захочет пример покруче, легко:
> пусть напишет функцию Аккермана без рекурсии
Пример абсолютно бесполезной функции. Точнее, единственное ее применение - конструктивный пример рекурсивной, всюду определенной, но не примитивно-рекурсивной функции.

freezer

Объяснить школьнику, знающему основы алгебры,
> что такое рекурсия, труда не составляет.
Рекурсию надо долго объяснять, цикл -- понятен интуитивно.
А вот прикинь, был у меня ученик (или ученица, уже не помню которому оказалось проще сделать подсчет факториала через рекурсию, чем через цикл. Это же к Фибоначчи относится.
Рекурсия хороша для построения математических моделей. Но для практики, в частности, для написания работающих программ, она обычно непригодна. Не путайте написание программ и построение математических моделей - это 2 большие разницы!
А QuickSort без рекурсии сделать - каково? А ведь алгоритм простой и эффективный.

Marinavo_0507

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

Julie16

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

Landstreicher

> А QuickSort без рекурсии сделать - каково? А ведь алгоритм простой и эффективный.
Все это конечно верно. Есть алгоритмы, которые по своей природе существенно рекурсивны, и их естественно писать (и надо писать) через рекурсию.
Однако, есть некоторые граждане, пытаются упихать рекурсию абсолютно везде, например рекурсивное определяется функции типа map, length, foldr, обход списка -- вещи которые гораздо более естественно делать через цикл. Мне как раз это не нравится -- пытаться использовать рекурсию не как редкий специализированный механизм, а пытаться выдавать чуть ли не за основную конструкцию программирования. Особенно это касается функциональных языков - там такое очень любят.
Но скажем в том же quicksort-e -- рекурсию нужно явно разворачивать руками, иначе очень быстро получим stack overflow. Вообще, в рекурсии очень много подводных камней. Нужно постоянно следить насколько глубоко она может уйти. Иногда приходится организовать очередь руками (пример: smbclient, там много гемора из-за этого). И тогда она становится отнюдь не простой конструкцией.
> А вот прикинь, был у меня ученик (или ученица, уже не помню которому оказалось проще сделать
> подсчет факториала через рекурсию, чем через цикл. Это же к Фибоначчи относится.
Верю. Но скажи, сколько у тебя было учеников, которые поняли цикл, и которые испытывали проблемы с рекурсией?

Landstreicher

> Обход дерева в глубину - очень распространённая задача, опять же понятнее всего решается рекурсией.
Не согласен. В специальных случаях, когда дерево сбалансировано, может работать. На произвольных деревьях - верный способ получить stack overflow.

Julie16

>Но скажем в том же quicksort-e -- рекурсию нужно явно разворачивать руками, иначе очень быстро получим stack overflow.
Ахуеть. Или мне изменяет склероз, или глубина рекурсии не может быть больше чем log(n и если ты будешь утверждать что сортируешь массивы порядка 2^1000 элементов, то я первый брошу в тебя камень

Landstreicher

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

Julie16

>Парсер методом рекурсивного списка понять очень просто, в результате чего этот метод популярен.
ИМХО не очень популярен. Большинство парсеров пишутся далеко не вручную.

Marinavo_0507

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

Landstreicher

Если тебе каждый раз не везет и выбираешь элемент, который равен крайнему. В результате у тебя каждый раз массив длины n разделяется на 1 и n-1. Глубина будет O(N). Это получается только на специально тщательно подобранных массивах. На практике, такое редко встречается, но в надежных программах к этому надо быть готовым.

Landstreicher

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

Marinavo_0507

> ИМХО не очень популярен. Большинство парсеров пишутся далеко не вручную.
По-моему, простой парсер быстрее написать руками, чем юзать yacc.
Генераторы нужны, если язык сложен, и рекурсивным спуском не разобрать.

Julie16

Ты забыл как это решается? Один из подмассивов обрабатывается нерекурсивно(грубо говоря через goto всегда можно выбрать наибольший массив для этого.

Ivan8209

Кто это тебе сказал, что рекурсия занимает экспоненциальное время?
Человек не машина, он просматривает листок значительно быстрее, чем умножает.
Если рекурсия хороша для построения модели,
то она столь же хороша и для написания работающих программ.
Если для программы нет модели, то она чаще оказывается плохо работающей.
И кто тебе сказал, что постоение модели и написание программы
это такая разница? Это --- _одно_ _и_ _то_ _же_.
Откуда, по-твоему, у железки возьмётся модель мира,
если у неё самой никаких мозгов нету?
Из каких таких соображений она будет действовать, да ещё и правильно?
---
"...Разве было бы плохо перевернуть перевёрнутый мир?"

Marinavo_0507

> Самый понятный - да.
То есть, для ряда распространённых задач, рекурсия - самый понятный способ решения, и нельзя говорить об обучении программированию без её объяснения.

Landstreicher

> Один из подмассивов обрабатывается нерекурсивно(грубо говоря через goto)
Я как раз про это и говорю. Чтобы рекурсивный алгоритм работал, его приходится явно разворачивать, в данном случае - через goto. Чистая рекурсия бы содержала 2 рекурсивных вызова и не работала.

Marinavo_0507

> И тут, как правило, рекурсия пишется не просто так - нужно явно ее
> разворачивать и/или сворачивать и прочий геморрой.
Разве что из любви к искусству разворачивания
На практике как раз нормально всё

Julie16

практически любой парсер проще написать через lex/yacc. Хочешь я тебе покажу свой конечный автомат для разбора ini файлов на 500 строк? Что-либо сложнее писать вручную уже ОЧЕНЬ сложно.

Julie16

Ну это же не совсем разворачивание... Это рекурсия без увеличения стека. Я бы так сказал

Landstreicher

> Разве что из любви к искусству разворачивания
> На практике как раз нормально всё
Почему ты так считаешь? Я как раз видел программы, в которых это делается "не от хорошей жизни", например, тот же smbclient.

Marinavo_0507

> Чистая рекурсия бы содержала 2 рекурсивных вызова и не работала.
tail call спасёт ситуацию
преобразовать "наивный" quick sort к варианту с хвостовой рекурсией проще, чем вводя цикл

Landstreicher

> Если рекурсия хороша для построения модели,
> то она столь же хороша и для написания работающих программ.
Обоснуй. В реальной жизни нужно учитывать ограниченный объем памяти, кэша, стека, диска, конечный размер int и double и ряд других ограничений. В модели ничего такого нет. Поэтому выводы в модели могут не совпадать с тем что происходит в программе.
> И кто тебе сказал, что постоение модели и написание программы
> это такая разница? Это --- _одно_ _и_ _то_ _же_.
Обоснуй это утверждение.

freezer

ну в квиксорте бывают всякие вариации со случайным выбором порога. Поэтому случай когда у него получается O(N^2) вместо O(N*log(N - это скорее курьез, ну или хитрая атака.

Marinavo_0507

> Я как раз видел программы, в которых это делается "не от хорошей жизни",
> например, тот же smbclient.
Случаев, где жизнь хороша, побольше будет.
А по поводу плохой жизни, даже в ядре со стеком в 8K есть места, где без рекурсии трудно.

Ivan8209

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

Landstreicher

> ну в квиксорте бывают всякие вариации со случайным выбором порога. Поэтому случай когда у него получается O(N^2) вместо O(N*log(N - это скорее курьез, ну или хитрая атака.
Такое тоже нужно учитывать. Вдруг мы пишем программу которая работает в банке и считает деньги в режиме 24x7. Злобный хакер Вася, изучив программу может понять механизм выбора порога и попытаться ее уронить подсунув специально сконструированный (другой программой) файл с входными данными. По мне так - вполне реальная ситуация.

Marinavo_0507

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

Landstreicher

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

Ivan8209

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

Julie16

Одно дело память, а другое дело стек. Который в некоторых случаях просто невозможно увеличить(треды).

Marinavo_0507

> Одно дело память, а другое дело стек.
Рекурсивный алгоритм, не использующий системный стек, не перестаёт быть рекурсивным.

Ivan8209

Делал.
Упомянутого явления не наблюдал.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

А надо было 'а попросить, а не самому делать.

Julie16

А что тогда по твоему рекурсия?

rosali

Синтаксис должен быть ортогональным
Когда человек говорит про BEGIN/END/{/} а потом называет это "вопросами ортогональности синтаксиса", то это лишь вызывает сострадательную улыбку, вот такую

Ivan8209

Ты так часто общаешься с гарвардской?
Лео я ещё поверю, тебе --- нет.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

Определение некоторого преобразования, в котором используется оно само.
Стек - это детали реализации.

Landstreicher

> В реальной жизни, памяти дофига.
Никогда не приходилось заниматься внешней сортировкой? Или обсчитывать данные объемом 80 Гб?
> А там, где мало памяти, используют совершенно другие приёмы программирования.
Мало памяти - это ОЧЕНЬ типичная ситуация.
> Насчёт второго утверждения прочитай исходное сообщение до конца.
> Тогда и обоснование увидишь.
Не уходи от ответа, напиши явно. Без всяких разглагольствований про "модель мира" и "мозги у железки".

Julie16

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

Marinavo_0507

> Никогда не приходилось заниматься внешней сортировкой?
Для внешней сортировки замечательно сработает сортировка слиянием, определённая рекурсивно.

Ivan8209

Да, широко распространённая задача.
В очень узких кругах.
Это и есть явно.
Камню совершенно безразлично, в каком порядке давать импульсы,
соответственно правильность работы программы определяется человеком.
Человек, пока пишет программу, описывает какие-то отношения
внешнего мира, то есть, _создаёт_ _модель_ этого внешнего мира.
Будешь утверждать, что импульсная техника не имеет никакого
отношения к числам?
---
"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."

Ivan8209

Что тебе мешает выделить себе стек в другой области памяти?
---
...Я работаю антинаучным аферистом...

Julie16

Два стека? Жесть

Marinavo_0507

> Два стека? Жесть
Настоящая жесть - это когда треды юзают. Дофига стеков становится

Julie16

нееее.... Два стека в одном треде - вот это жесть А про то что ты сказал - это всем известно(кроме похоже КОНТРЫ) и никому не интересно

Landstreicher

> Настоящая жесть - это когда треды юзают. Дофига стеков становится
Волею судеб столкнулся с таким Могу подтвердить - действительно, жесть.
Имелось ввиду: много стеков на 1 тред.

Marinavo_0507

> Два стека в одном треде - вот это жесть
Тред - это тоже абстракция.
Процессоров-то в машине конечное и довольно постоянное число.
А то, что yacc заводит свой стек, тебя не смущает?

Ivan8209

У меня их четыре --- комплексов не испытываю.
---
...Я работаю антинаучным аферистом...

rosali

А про то что ты сказал - это всем известно
Кстати большая заслуга Явы в том, что в ней стек не привязан к определенному месту. На Ява-стеке могут храниться ссылки и примитивы, но не объекты, соответственно на стек нельзя сослаться (сравнить с .NET!) Поэтому JVM могла бы расширять стеки тредов когда вздумается, почему тем не менее в Яве размер стека ограничен - для меня полнейшая мистика...

Marinavo_0507

> Поэтому JVM могла бы расширять стеки тредов когда вздумается, почему
> тем не менее в Яве размер стека ограничен - для меня полнейшая мистика...
Ладно Ява. А вот почему такая же фигня в ocaml?

Julie16

А разве явовские треды не отображаются один в один в системные треды?

rosali

А разве явовские треды не отображаются один в один в системные треды?
Какое-то бессмысленное утверждение... В какой-то тебе известной JVM? Ну и что?

Marinavo_0507

> В какой-то тебе известной JVM?
Их не так уж много

bleyman

>Когда человек говорит про BEGIN/END/{/} а потом называет это "вопросами ортогональности
>синтаксиса", то это лишь вызывает сострадательную улыбку, вот такую
Дурилка картонная =) С чего ты взял, что я _это_ называю вопросами ортогональности синтаксиса? Ну вот не знаю, с чего ты это взял, но ты ошибся. Если забыть про & и OR, то у оберона довольно ортогональный синтаксис, правда, чудовищно бедный. Правда, ELSEIF говно, по моему, ну да ладно.
> На Ява-стеке могут храниться ссылки и примитивы, но не объекты, соответственно на стек нельзя
> сослаться (сравнить с .NET!) Поэтому JVM могла бы расширять стеки тредов когда вздумается,
Никак не уловлю, а в чём проблема с указателями на стек? Сборщик Мусора прекрасно умеет указатели патчить. бтв, а что, в жаве структуры это не value types?
2 Контра:
>Нет. Сосёт сложный синтаксис.
Нет, сосёт бедный синтаксис. Если добавить в Оберон операторы "<< >> & | ^ ++ --" и операторные присваивания, то он станет легче для восприятия. Потому что вместо методов будут операторы.
>Число Ингве.
А что такое Число Ингве? У меня щаз инета нет.
> Читать про различие американской и европейской конструкторской школы.
Да мне как-то насрать на это различие. Ты мне вот скажи, где в языке научность-то? Или, может быть, она в стандартных библиотеках?

bleyman

Ну, я думаю что в Мобильном Телефоне "системных тредов" нет вообще, а вот JVM есть. К чему бы это?

freezer

бтв, а что, в жаве структуры это не value types?
Издеваешься?

enochka1145

// бтв, а что, в жаве структуры это не value types?
Как ты, наверно, догадываешься, Java более простой по сравнению с C#. Структур там просто нет.

bleyman

Ой.
ГЫ ГЫ ГЫ.

bastii

На Ява-стеке могут храниться ссылки и примитивы, но не объекты, соответственно на стек нельзя сослаться (сравнить с .NET!)
А что c .NET? Двигать стек при желании и иам можно (ссылки всегда можно подправить).

Marinavo_0507

Ну и как, двигают?

freezer

Двигают. Лично на это напарывался, когда получал адрес массива, передавал его в API-шную функцию (буфер для асинхронной операции а он потом уползал Пока не объявил как fixed - не заработало.

Marinavo_0507

А глубокая рекурсия получается?

freezer

Не знаю, не пробовал.
Вообще, ссылки сборщик двигает, насколько я знаю...
может мы о разных вещах говорим?
---
ЗЫ на stack overflow напарывался. Значит не получается?

bastii

В отличии от Java в .NET могут быть указатели на (логический) стэк, но в случае verifiable IL такие указатели могут сидеть только в стэке. В каждом фрейме стека каждого метода есть указательно на структу, где описываются все указатели в этом фрейме в каждый момент выполнения метода. Поэтому довольно легко пробежаться по фреймам и найти все указатели на стэк, переместить стэк и подправить указатели.

Marinavo_0507

> Поэтому довольно легко пробежаться по фреймам и найти все указатели на > стэк, переместить стэк и подправить указатели.
Можно ещё не двигать, а использовать фрагментированный стек, выделяемый кусками при необходимости.

Julie16

Это наверное очень медленно будет. При каждой операции со стеком надо будет решать перейти ли на предыдущий/создать следующий кусок...

Marinavo_0507

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

bastii

Правда мне кажется, что с точки зрения работы GC длинный стек не очень хорошо.

Papazyan

>>кстати, когда уже это будет просто?
microsoft ничего не обещает по этому поводу?
просто - это типа такого:
code:
a = 1;
transaction {
a = 2;
rollback;
}
и на выходе a==1
>>>>>>>>>>>>
Это уже есть. Можно такое реализовать с помощью call with current continuation в Схеме, например. Или вообще в любом приличном языке типа Лиспа или ОКамла пользуясь CPS.

Marinavo_0507

> Это уже есть. Можно такое реализовать с помощью call with current
> continuation в Схеме, например. Или вообще в любом приличном языке типа
> Лиспа или ОКамла пользуясь CPS.
Это непросто и неэффективно.

Marinavo_0507

Да, и деструктивные обновления не откатит, если я правильно понимаю.
А без такого отката обычные исключения получатся.

Julie16

> Перемещать данные тоже не очень-то эффективно, однако...
Поэтому стек надо увеличивать не на константу, а в 2 раза. Тогда затраты на перемещение каждого элемента в среднем будут невелики и равны O(1).
>Для ускорения можно попробовать возможности проца использовать: ставить защитные страницы на границах кусков, и обрабатывать исключения.
Интересно. Но только грамотно реализовать это довольно сложо. Нужно толковое взаимодействие user space и kernel space...

Marinavo_0507

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

Julie16

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

Marinavo_0507

> >Ничего особенного, многие так делают.
> Кто?
Отладочные библиотеки, сборщики мусора (кажется даже в некоторых JVM).

Marinavo_0507

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

Papazyan

>>Это непросто и неэффективно.
Да ну? И что же в этом сложного и неэффективного?

Marinavo_0507

В "On Lisp" не включен пример code walker'а по причине сложности.
Про неэффективность там же сказано.

rosali

Если забыть про & и OR, то у оберона довольно ортогональный синтаксис, правда, чудовищно бедный. Правда, ELSEIF говно, по моему, ну да ладно.
Еще раз повторяю - про ЕРУНДУ пишешь. Вот то что в С нельзя переменную типа void завести, это вот неортогональность, очень мешает макросы писать, да и шаблоны вечно специализировать приходится. То что шаблонных typedef-ов нет, наподобие
 template<class T> typedef x<T,T> y<T>;

тоже неортогональность. Напомню еще про эту дурость
 Class object(double(argument;

Куча еще разных мелочей имеется. А && или OR разве не пофиг? Кстати в Си работает and и or.

rosali

Двигают. Лично на это напарывался, когда получал адрес массива, передавал его в API-шную функцию (буфер для асинхронной операции а он потом уползал
Так массив же в heap-е или как? То что heap двигают - это понятно.

freezer

вообще-то объекты все в heap-е создаются вроде... В стеке только ValueType

xronik111

FYI, в gcc переписаны парсеры С++ (с 3.4.х) и С (с 4.1) вручную, методом рекурсивного спуска. Почему это сделано для С, можно узнать здесь. Как я понимаю, чтобы легче было поддерживать и добавлять новые возможности.

Ivan8209

У форта, например, нет вообще никакого синтаксиса --- только семантика.
Слова, делающие << >> & | ^ называются, соответственно,
lshift rshift and or xor, ++ -- делают, если кому-то надо.
Научность подхода как раз и состоит в учёте восприимчивости всех
этих << >> & | ^ ++ и --. Если первые три знака воспринимаются
прилично, смысл следует из написания, то ни | , ни ^, ни ++ или
-- этими свойствами нисколько не обладают.
Кстати, "xor" никому нафиг не нужен, и при научном подходе это
очень хорошо видно.
Системные, требующие поразрядного доступа, вещи не рассматриваем,
для этих задач можно держать особо выделенные функции.
---
...Я работаю антинаучным аферистом...

rosali

вообще-то объекты все в heap-е создаются вроде... В стеке только ValueType
Ну так вот мы с Крёстным и интересуемся двигается ли в .NET-е стек, а ты про массивы...

rosali

У форта, например, нет вообще никакого синтаксиса --- только семантика.
А сделайте тред - ликбез по форту. Читать какую-то документацию по нему у меня, например, не хватит терпения, а в ненапряжной форумской обстановке может и осилил бы? Только хорошо бы там был еще кто-то кроме КОНТРы

Ivan8209

1. Зачем он тебе?
2. а) http://forth.org.ru/
б) http://dmoz.org/Computers/Programming/Languages/Forth/
искать Marcel Hendrix, размещающего у себя новую "Starting
Forth" after Leo Brodie.
---
...Я работаю антинаучным аферистом...

enochka1145

Нафига тебе Форт?! Хочешь стать КОНТРОЙ-II, нести всякую херню с опломбом дебила из-за того, что знаешь Форт?
Стековый язык, так что гораздо лучше изучить JVM (или CLR). В сети есть книга Programming for Java Virtual Machine, там кстати есть глава Compiling Scheme - может быть полезно.....

bastii

Да не двигается там стек. Зачем? Там и так проблем выше крыши.

Ivan8209

Так сложно подвинуть стек?
---
"...Так завещал великий и мудрый Сун."

bastii

В случае verifiable IL вроде не сложно. В случае unverifiable IL похоже, что невозможно, т.к. для стека в .NET вроде нет как для кучи возможности помечать объекты, что их нельзя двигать (хотя я точно не знаю). В счучае перехода в unmanged режим, тоже не понятно, совершенно не представляю, что они там делают и как оформляют стек.
Короче в общем случае также непросто как для простого unmanaged кода. Хотя по идее можно сделать разрывный стек, т.е. когда при вызове случается переполнение стека, то новый фрейм вызываемого метода просто помещается в начало выделеного нового фрагмента стека.

Ivan8209

Задавать указатели смещением от дна или верха не позволяет,
очевидно, религия.
Разрывный стек --- тоже.
---
"...Так завещал великий и мудрый Сун."

Dasar

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

Dasar

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

bastii

А зачем? В С++ стек двигают?

Ivan8209

Сложение адресов значительно быстрее выборки из памяти.
Тем более --- на винтеле.
Внешний код вдруг забыл про сегментированность памяти,
о которой тут недавно так вещал ПэЖэ?
С каким внешним кодом невозможно работать?
С тем, который не расчитан на винду?
Так винда с внешним кодом из *никсов всё равно не работает.
Не довод.
---
...Я работаю антинаучным аферистом...

Ivan8209

Чтобы, если потребуется, избавиться от упомянутого ограничения
в 8 Кбайт, которое может повлиять и в случае нерекурсивных
алгоритмов, учитывая стиль, в котором пишут некоторые насильники.
---
...Я работаю антинаучным аферистом...

bastii

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

bastii

В С++ как сегодня справляются с этой проблемой?
P.S. В CLR сейчас занимаются корректным поведением при нехватке памяти, может и до стека доберутся.

Ivan8209

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

Ivan8209

Даже если как-то справляются, мне наплевать.
Для простых сей принципиальных препятствий
(за исключением грязного хака с setjmp/longjmp)
не вижу.
---
...Я работаю антинаучным аферистом...

Ivan8209

Кстати, даже для setjmp/longjmp --- тоже не вопрос.
---
...Я работаю антинаучным аферистом...

bastii

Ну знаю я про сегментацию, хотя думал, что в винде все сегменты показывают на одно и тоже. Потом как это мне поможет, вижу следующте проблемы:
1) нужно вводить отделный вид указателя, который будет правильно джититься в код использующий правильный сегмент. Потом опять проблема с конвертацией в нормальные указатели. Плюс опять проблема с отслеживанием состояния, когда существуют обычные указатели на стек.
2) Потом не представляю, как можно при такой архитектуре повесить потоки на нити (получается с SQL Server, например, не будет работать)
P.S. Возможно я чего и подзабыл из системных дел

bastii

Про безопасный код я писал, что видимых проблем нет. Мы обсуждаем общий случай, т.к. в .NET он распространен.

Ivan8209

Видов указателей уже достаточно: auto XXX* и static XXX*,
вообще говоря, различаются. Соответственно, "обычного" указателя
на стек ты никак не получишь, если только не сделаешь
UNCHECKED_CONVERSION, которое осуществляется "AS IS WITHOUT ANY
WARRANTY, EXPRESSED OR IMPLIED."
Не вижу ничего принципиально сложного.
---
...Я работаю антинаучным аферистом...

Ivan8209

В самом общем случае, ничто особо не запрещает встречу
сферической лошади, спокойно переносящей вакуум.
А код должен быть безопасным, чтобы не было вышеупомянутого
core dump вместе с большим набранным текстом.
---
...Я работаю антинаучным аферистом...

rosali

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

rosali

В С++ стек двигают?
А вот у меня в калькуляторе вообще стека нету, так и надо?

garikus

>> программирование без отладчика
Это как, простите?
Точнее, так:
When a run-time error occurs, e.g., a division by zero, a "trap text" is opened which displays the procedure
call chain. It is possible to use this text to navigate through data structures. Several other commands are
useful when analyzing the state of the system.

Note that debugging is done completely within BlackBox; there is no separate debugger environment.
Debugging occurs "post mortem" with respect to commands, i.e., a command produces a run-time error, is
aborted, and then debugged. However, the run-time error usually does not affect the loaded modules and
the data structures which are anchored there, nor the open documents. In other words, debugging occurs
"run-time" with respect to the application as a whole.
Надо было написать "без пошагового отладчика"
web-страница
web-страница

Landstreicher

Не совсем понятно. Можно пояснить, какой отладчик пошаговый, а какой - нет. Рассмотреть, к примеру, gdb, SoftIce.

bleyman

> У форта, например, нет вообще никакого синтаксиса --- только семантика.
Не вполне корректно. У чистой форт-машины - да. Но таких в природе не существует, потому что нафиг не нужно. Как только у тебя появляются слова ":" и ";", которые надлежит использовать вот так ": <identifier> <definition> ;" и никак иначе - у тебя появляется синтаксис. Вот он, я его написал.
В форте _программируемый_ синтаксис. Чем он меня и поразил, собственно.
=====
Научность подхода как раз и состоит в учёте восприимчивости всех
этих << >> & | ^ ++ и --. Если первые три знака воспринимаются
прилично, смысл следует из написания, то ни | , ни ^, ни ++ или
-- этими свойствами нисколько не обладают.
=====
Ха ха три раза. Человек, не знакомый с программированием, символ "<<" не сможет воспринять никак. Человек, знакомый и с паскалем, и с С, нормально воспринимает как "i++", так и "inc(i)". Но "i++" короче, и может использоваться в сложных выражениях.
Говорить "я плохо воспринимаю символы !"№;, и не вижу как их смысл следует из написания => они плохо воспринимаемы и их смысл не следует из описания" - это не научный, это мудаческий подход. Привет!

Ivan8209

> Но таких в природе не существует,
"Расширь своё сознание."
> которые надлежит использовать вот так 


: later  r> r> swap >r >r ;

Это новый синтаксис?
"[" используется не только в паре с "]".
> Человек, не знакомый с программированием, символ "<<" не сможет воспринять никак.
Человек, хоть чуть знакомый с ПДД, воспримет легко.
> это не научный
Прочитай, как создают знаки для разного рода вокзалов и проч.
---
"Расширь своё сознание!"

bleyman

>> Но таких в природе не существует,
> "Расширь своё сознание."
Форт-машина, в которой не определён некоторый минимальный набор слов, не пригодна для программирования, потому что не соответствует по мощности машине Тьюринга. Например, если в ней не определена конструкция для определения новых слов (": ... ;") - а она, к твоему сведению, определяется и не является частью языка.
> Это новый синтаксис?
Да.
> "[" используется не только в паре с "]".
Ну и что?
>> Человек, не знакомый с программированием, символ "<<" не сможет воспринять никак.
> Человек, хоть чуть знакомый с ПДД, воспримет легко.
Чувак. "<<" означает "много меньше". Ещё евреи записывают числа слева-направо (наверное поэтому с их точки зрения вот такой шифт - "<<" должен _уменьшать_ число.
> это не научный
Прочитай, как создают знаки для разного рода вокзалов и проч.
В Японии белый цвет обозначает смерть а не чистоту, как в европейской культуре. Поэтому "знаки для разного рода вокзалов" в Японии должны отличаться от европейских как минимум по цветовой гамме.
Универсальных знаков не бывает.
К любой системе, обладающей внутренней логикой, можно привыкнуть, поняв эту логику.
Оставить комментарий
Имя или ник:
Комментарий: