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

AVC>Не обижайтесь, Андрей, но Ваш пост получился весьма забавным.

Хотя бы повеселил. Уже хорошо.

AF>>С++. Добавьте сборку мусора, блоки инициализации, уберите указатели, шаблоны, макросы, переопределение операторов и delete и получаем Java

AVC>Можно оставить указатели и вернуть всем этим "новшествам" Явы родной паскалевский синтаксис.
AVC>Перед Вами портрет Оберона.

AF>>ИМХО в обероне придётся для этого поменять гораздо больше.

AVC>Неужели вернуть паскалеподобный синтаксис — больше, чем
AVC>

AVC>добавить сборку мусора, блоки инициализации, убрать указатели, шаблоны, макросы, переопределение операторов и delete

AVC>?!
AVC>Ну, попробуйте исполнить в Си++ хотя бы первое (добавить сборку мусора).

Очень сомневаюсь. Я не знаток оберона, но сам факт того, что великий и ужастный регулярно СГ хвастается тем, что в обероне фича X есть, а в поганом C# и Java — её нет, уже говорит о том, что как минимум в Обероне есть что-то ещё, кроме описанного выше.

AF>>Идею сборщика мусора придумали до Вирта, первые работы на эту тему были аж в 50-х.

AVC>Да, действительно, сборка мусора существовала как минимум со времен Лиспа, но только в интерпретируемых средах.
AVC>Насколько мне известно, Оберон был первым компилируемым императивным языком, в котором появилась сборка мусора.

Во первых до оберона был Algol 68 (об этом уже писали), а во-вторых, это вовсе не означает, что Java была срисована именно с Оберона. Если вы знаете идея общей шины и единого набора команд впервые была явлена массам в IBM-360, однако появилась значительно раньше (начало 50-х) и современные микропроцессоры вовсе не развивались именно оттуда. Да, идеи были взяты и из IBM-360 и теоретических работ и много ещё откуда, но прямого копирования или развития не было.

Подозреваю, что аналогичная ситуация была и с Java. К примеру те же лекции по оберону я послушал бы уже хотя бы ради того, что бы представлять, какие сложности могут возникнуть на этапе построения системы с использованием языка — то есть в JDK, а вовсе не в самой Java. Игорь здесь

Автор: eao197
Дата: 28.09.05

приводит хронологию, которая как раз подтверждает эту версию

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

AVC>Ну, попробуйте исполнить в Си++ хотя бы первое (добавить сборку мусора).
Без проблем: http://www.hpl.hp.com/personal/Hans_Boehm/gc/

#include "gc.h"
#include <assert.h>
#include <stdio.h>

int main()
{
  int i;

  GC_INIT();    /* Optional on Linux/X86; see below.  */
  for (i = 0; i < 10000000; ++i)
   {
     int **p = (int **) GC_MALLOC(sizeof(int *));
     int *q = (int *) GC_MALLOC_ATOMIC(sizeof(int));
     assert(*p == 0);
     *p = (int *) GC_REALLOC(q, 2 * sizeof(int));
     if (i % 100000 == 0)
       printf("Heap size = %d\n", GC_get_heap_size());
   }
  return 0;
}

Реально использовал в достаточно сложном приложении — проблем никаких.

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

GN>ИМХО (и не только моё), операции присваивания в этих языках далеки от "человеческого" представления.
GN>Для примера, возьмём записанный словами алгоритм: "Прибавить X к Y и поместить результат в Z".
GN>Как это выглядит сейчас:
GN>Z = X + Y // с точки зрения математика, это уравнение!
GN>Z := X + Y // это можно трактовать как "В Z помещяется сумма X и Y"
GN>Немного не по-русски звучит .
GN>А теперь, сравним с таким:
GN>X + Y => Z
GN>Такая запись в точности соответствует поставленной задаче, кроме того, она читается последовательно слева направо. В классической записи нам приходится "запоминать" куда же сохранится разультат, а потом "вспоминать", когда мы дошли до конца выражения. Следствием этого является и усложнение синтаксического анализатора в компиляторе.
Надеюсь меня можно считать человеком?
Как по мне, так
Z = X + Y
Z := X + Y
куда естественнее чем
X + Y => Z

Даже с той же точки зрения математики (не навороченной а простой, соответствующей уровню Z = X + Y) запись X + Y => Z выглядит как криво записанное неравенство X + Y больше либо равно Z. Также неестественны записи вида 5 => x тогда как х = 5 — естественна.
Естественность разумеется рассматривается с точки зрения чтения человеком. Поскольку машине все равно, естественна запись или нет — она ее все равно по правилам заданной ей грамматики читает

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

CC>Надеюсь меня можно считать человеком?
CC>Как по мне, так
CC>Z = X + Y
CC>Z := X + Y
CC>куда естественнее чем
CC>X + Y => Z

Полностью согласен, и я тоже так считаю.
Но провёл простой эксперимент — спросил ребёнка что он думает по этому поводу (знак "=>" был заменён на обычную стрелочку).

ИМХО мы просто путаем понятное и привычное .

CC>Даже с той же точки зрения математики (не навороченной а простой, соответствующей уровню Z = X + Y) запись X + Y => Z выглядит как криво записанное неравенство X + Y больше либо равно Z.

См. выше в скобочках. Проблема в выборе ASCII символах есть, но проблемы с отображением в редакторе понятного графического символа вместо этих ASCII нет.

Кстати, SourceInsight может показывать опрации присваивания в таком виде:
Z <- X + Y
(стрелочка там конечно не ASCII)
Так что все дебаты по поводу приимущества фаллического символа перед сишным "=" я считаю анахронизмом.

CC>Также неестественны записи вида 5 => x тогда как х = 5 — естественна.

Последняя запись естесствена для укзания того, что x равен 5. Где в ней скрытый смысл операции перемещения данных?

CC>Естественность разумеется рассматривается с точки зрения чтения человеком.

Поправлю — человека, не один год привыкшего так рассматривать запись.
Это важный момент. Он хорошо объясняет в том числе все эти holywar = vs :=

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


На закуску — alma mater всех этих споров о естественностях:

mov r0, r1

А теперь вопрос: что куда помещается?

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

GN>>>X + Y => Z
AVC>>Над этим можно подумать.

П>Вирту только не говорите, а то к выходу Oberon 3 идеальным синтаксисом начнет считаться польская нотация.

Вирт на такое никогда не пойдёт. В психологии есть такое понятие как ригидность, с возрастом она только усиливается.

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

GN>Так что все дебаты по поводу приимущества фаллического символа перед сишным "=" я считаю анахронизмом.
Хорошо сказано!

CC>>Также неестественны записи вида 5 => x тогда как х = 5 — естественна.
GN>Последняя запись естесствена для укзания того, что x равен 5. Где в ней скрытый смысл операции перемещения данных?
Ну, присваивание не всегда является перемещением. Скорее это копирование
За скрытым смыслом это не ко мне. Я практик. Я языки программирования использую для выражения нужных мне от компа действий.

GN>На закуску — alma mater всех этих споров о естественностях:
GN>

GN>mov r0, r1
GN>

А теперь вопрос: что куда помещается?
В зависимости от ассемблера
Есть и r0->r1 и r1->r0 варианты.
для x386: r1->r0 а для DEC: r0->r1

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

CC>>>Также неестественны записи вида 5 => x тогда как х = 5 — естественна.
GN>>Последняя запись естесствена для укзания того, что x равен 5. Где в ней скрытый смысл операции перемещения данных?
CC>Ну, присваивание не всегда является перемещением. Скорее это копирование

Согласен, я ошибся в выборе термина.

GN>>На закуску — alma mater всех этих споров о естественностях:
GN>>

GN>>mov r0, r1
GN>>

А теперь вопрос: что куда помещается?
CC>В зависимости от ассемблера
CC>Есть и r0->r1 и r1->r0 варианты.
CC>для x386: r1->r0 а для DEC: r0->r1

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

PS: Вы даже незаметно (?) для себя использовали мой вариант записи копирования . r0->r1

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

CC>>Z := X + Y
CC>>куда естественнее чем
CC>>X + Y => Z

GN>Полностью согласен, и я тоже так считаю.
GN>Но провёл простой эксперимент — спросил ребёнка что он думает по этому поводу (знак "=>" был заменён на обычную стрелочку).

Занятно. Smalltalk, который в процессе разработки постоянно "испытывали на детях", для знака присваивания использовал именно "стрелочку". Только, всё же, в более классическом варианте z <- x + y. Что, в профессиональных диалектах таки трансформировалось в :=.
Чем-то это напоминает вопрос о записи if и while после действий вместо "нормального"

Автор: eao197
Дата: 22.09.05

.

GN>ИМХО мы просто путаем понятное и привычное .

Похоже — да.
Привычка — вторая натура, однака.

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

Д>

Д>                                        Си++        Java    Oberon    C#
Д>Доступ к регистрам и памяти             Да          Нет     Да        Да

Каким образом получить доступ к регистрам CPU в C++ ?

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

AVC>>Насколько мне известно, Оберон был первым компилируемым императивным языком, в котором появилась сборка мусора.

uw>Возможно даже не первыми компилируемыми императивными языками со сборщиком мусора были PL/I и Algol 68.

Спасибо за информацию!
Похоже, я должен взять свои слова (о том, что Оберон был первым компилируемым языком со сборкой мусора) назад.
Действительно, по указанным Вами ссылкам я нашел упоминания о сборке мусора в языках PL/I и Algol-68.
Жаль, что эта информация весьма скупая. Я не смог пока составить себе представления о механизмах сборки мусора в
этих языках. Но сборка мусора упоминается, это факт.
Насчет скупости информации. Интересно, что дома у меня завалялась старая книжка по Алголу-68; в ней сборщик мусора вообще не был упомянут. Прямо военная тайна какая-то. Отсюда — личные заблуждения.
Прежде Cyberax высказывал предположение, что сборка мусора была до Оберона в Аде. Я тогда покопался в литературе,
но кроме туманной фразы Вегнера о "возможности" сборки мусора ничего не нашел, поэтому тогда остался "при своем мнении".

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

AVC>>Ну, попробуйте исполнить в Си++ хотя бы первое (добавить сборку мусора).
C>Без проблем: http://www.hpl.hp.com/personal/Hans_Boehm/gc/

C>

C>#include "gc.h"
C>#include <assert.h>
C>#include <stdio.h>

C>int main()
C>{
C>  int i;

C>  GC_INIT();    /* Optional on Linux/X86; see below.  */
C>  for (i = 0; i < 10000000; ++i)
C>   {
C>     int **p = (int **) GC_MALLOC(sizeof(int *));
C>     int *q = (int *) GC_MALLOC_ATOMIC(sizeof(int));
C>     assert(*p == 0);
C>     *p = (int *) GC_REALLOC(q, 2 * sizeof(int));
C>     if (i % 100000 == 0)
C>       printf("Heap size = %d\n", GC_get_heap_size());
C>   }
C>  return 0;
C>}
C>

C>Реально использовал в достаточно сложном приложении — проблем никаких.

Для меня это действительно интересная информация.
Последняя фраза даже вогнала меня в краску.
Почему-то мне до сих пор просто не пришло в голову использовать сборщик мусора Боэма в своих программах на Си/Си++.
Я ограничивался мыслью: так ведь это консервативный (не "прецизный") сборщик мусора, не весь мусор соберет...
я уж сам как нибудь...
Глупость какая-то! В любом случае, это лучше, чем ничего! (Речь, конечно, о достаточно сложных программах.)
Возможно, в какой-то степени я упустил из виду одну из тенденций последнего времени. Не всегда все надо делать на 100%: сжатие с потерями, рандомные алгоритмы (например, тест числа на "простоту" у Миллера и Рабина), консервативный сборщик мусора.
Надо будет над этим подумать.

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

AVC>Возможно, в какой-то степени я упустил из виду одну из тенденций последнего времени. Не всегда все надо делать на 100%: сжатие с потерями, рандомные алгоритмы (например, тест числа на "простоту" у Миллера и Рабина), консервативный сборщик мусора.
AVC>Надо будет над этим подумать.

Сюда же можно добавить "ленивые" вычисления и т.д. и т.п.

Что касается сборщика мусора в Си/Си++.
Конечно я имел в виду "прецизный" ("точный", "аккуратный" и т.п.; tracing garbage collector) сборщик мусора, наподобие обероновского.
(Не уверен, что сборщик мусора в Алгол-68 именно такой. Уверен, что в Си/Си++ такой сборщик мусора — на сегодня — невозможен.)
Просто сейчас мне пришла в голову мысль: а не "завышены" ли мои требования? М.б. и правда консервативного сборщика мусора вполне достаточно в большинстве случаев?

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

GN>>>X + Y => Z
AVC>>Над этим можно подумать.

П>Вирту только не говорите, а то к выходу Oberon 3 идеальным синтаксисом начнет считаться польская нотация.

Это не к Вирту, а к Муру (автору Форта).

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

GN>Каким образом получить доступ к регистрам CPU в C++ ?

__asm mov ax, my_var

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

GN>PS: Вы даже незаметно (?) для себя использовали мой вариант записи копирования . r0->r1
Отнюдь не незаметно. Как можно это не заметит когда только что о такой форме записи шла речь?

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

GN>Но провёл простой эксперимент — спросил ребёнка что он думает по этому поводу (знак "=>" был заменён на обычную стрелочку).

GN>ИМХО мы просто путаем понятное и привычное .

Код на Рапире:

A+B->C

почти идеальный язык для обучения детей. Жаль, что заброшен.

Возможно мне изменяет память, но не было в PL/I сборки мусора.
Что касается Algol-68, там было очень много интересных нововведений. Но к тому времени, как появились первые полноценные компиляторы, он уже стал историей.

Скорее всего главный претендент в номинации "первый компилируемый язык со сборкой мусора" — Симула-67.

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

Т>Возможно мне изменяет память, но не было в PL/I сборки мусора.

Мне тоже кажется, что не было. Если не ошибаюсь, в PL/1 вообще впервые появилась возможность динамического выделения/освобождения памятью, но о сборке мусора там я никогда ничего не слышал. И в оставшихся с тех времен книгах на эту тему нет ни слова. Вот с Algol-ами всеми сразу я разминулся — у нас все читалось на базе сначала Фортрана, а потом — Pl/1.

AVC wrote:

> Что касается сборщика мусора в Си/Си++.
> Конечно я имел в виду "прецизный" ("точный", "аккуратный" и т.п.;
> tracing garbage collector) сборщик мусора, наподобие обероновского.

В той реализации Оберона, которую я смотрел, нет полностью точного
сборщика GC. Он там "mostly precise" — куча собирается точно, но стек
рассматривается консервативно. Boehm GC так тоже умеет.

> (Не уверен, что сборщик мусора в Алгол-68 именно такой. Уверен, что в
> Си/Си++ такой сборщик мусора — на сегодня — невозможен.)

В C++/CLI будет возможен.

> Просто сейчас мне пришла в голову мысль: а не "завышены" ли мои
> требования? М.б. и правда консервативного сборщика мусора вполне
> достаточно в большинстве случаев?

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

--
С уважением,
Alex Besogonov (alexy@izh.com)