For the technical historians in the crowd, here's a copy of the Oak 0.2 manual. It dates from a while after the completion of Green, but it's the oldest manual I've found. It's the last manual I wrote (mostly).

AVC>А вообще, очень рад тебя слышать.

AVC>WHILE cond DO
AVC>  ...тут тело цикла
AVC>END;
AVC>(* точка A, следующая за циклом *)
AVC>

AVC>Такое вот синтаксическое удобство.

VAR brokenglass:BOOLEAN; (* выдернуть шнур, выдавить стекло *)
.....
(* двадцать строк спустя *)
brokenglass := FALSE;
WHILE NOT brokenglass & cond DO
  .....
  brokenglass := TRUE; (* типа, break сделали *)
  .....
END;

   IF shortcut() THEN
     BREAK
   END;
   (* оставшаяся часть тела *)

   IF shortcut() THEN
     brokenglass:=TRUE (* здесь хоть брейкпоинт можно поставить *)
   END;
   IF ~brokenglass THEN (* оставшаяся часть тела *) END;

   brokenglass:=brokenglass|shortcut(); (* а это как отлаживать? *)
   IF ~brokenglass THEN (* оставшаяся часть тела *) END;

Эпиграф: Гослинг и его команда использовали C++ как руководство — чего нужно избегать.

Для разработчика, язык выглядел совершенно как C++. Но в душе Java взяла очень много от Smalltalk, Lisp и Pascal. Моя заслуга в том, что я смог их совместить. (Джеймс Гослинг)

П>А для неграмотных вкратце здесь можно рассказать?

extern int f(int x);

int g(int x)
{
  return f(x) + 1;
}

MODULE B;

  IMPORT A;

  PROCEDURE g(x: INTEGER): INTEGER;
  BEGIN
    RETURN A.f(x) + 1
  END g;

END B.

#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;
}

(define  m ...)
(define  n ...)

(define (PoschitatDeterminant)  
   ;детерминант матрицы m

(define  (UmnozhitMatricy)  
  ;произведеие матриц m и n
...
(define  d (PoschitatDeterminant)) 
...
(define  m (UmnozhitMatricy))

Д>>>Оказывается, Ява — это испорченный Оберон. Чем дальше, тем лохмаче

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

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

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

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

MODULE Oberon1;

  TYPE
    Object* = POINTER TO RECORD
      handler-: Handler;
      (*...*)
    END;

    Message* = RECORD END;

    Handler* = PROCEDURE(obj: Object; VAR msg: Message);


  PROCEDURE Handle (obj: Object; VAR msg: Message);
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    obj.handler := Handle;
    (*...*)
  END NewObject;

END Oberon1.

MODULE Oberon2;

  TYPE
    Object* = POINTER TO RECORD
      (*...*)
    END;

    Message* = RECORD END;


  PROCEDURE (obj: Object) Handle* (VAR msg: Message);
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    (*...*)
  END NewObject;

END Oberon2.

MODULE ComponentPascal;

  TYPE
    Object* = POINTER TO EXTENSIBLE RECORD
      (*...*)
    END;

    Message* = RECORD END;


  PROCEDURE (obj: Object) Handle* (VAR msg: Message), NEW, EXTENSIBLE;
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    (*...*)
  END NewObject;

END ComponentPascal.

К>VAR brokenglass:BOOLEAN; (* выдернуть шнур, выдавить стекло *)
К>.....
К>(* двадцать строк спустя *)
К>brokenglass := FALSE;
К>WHILE NOT brokenglass & cond DO
К>  .....
К>  brokenglass := TRUE; (* типа, break сделали *)
К>  .....
К>END;
К>

  (* локальная процедура *)
  PROCEDURE LoopWasBroken (* здесь какое-нибудь содержательное имя *) (): BOOLEAN;
  BEGIN
    WHILE cond DO
      НачалоТелаЦикла;
      IF ЧтоТоУжасное THEN
        RETURN TRUE
      END;
      КонецТелаЦикла;
    END;
    RETURN FALSE
  END LoopWasBroken;
BEGIN
  ...
  IF LoopWasBroken THEN ОбработкаЭтойПечальнойСитуации END;

AVC>Такое вот синтаксическое удобство.

(define (f (cond _cond f ...тут тело цикла)))

SIMULA 67

Алгоритмический язык Simula 67 (от “simulation” – моделирование) является первым полноценным объектно-ориентированных языком, который представлял собой все основные концепции объектного моделирования (инкапсуляция, полиморфизм, наследование). Simula был разработан в начале 60-х гг. в Norwegian Computing Centre для моделирования дискретных событий в реальном физическом мире.

Синтаксис языка Simula взят из Алгола-60. Основными новшествами были понятия объекта, класса и наследования. Симула не навязывает строгую инкапсуляцию данных и не заботится о деталях реализации. Модули можно перекомпилировать по отдельности, не меняя внешние интерфейсы. Проверка типов осуществляется во время компиляции. Сборка мусора осуществляется системой поддержки работающей программы.

В Simula имеется поддержка моделирования физических процессов реального времени. Для этого Simula может оперировать понятиями Модель (Simulation) и Процесс (Process).

Для инкапсуляции (сокрытие реализации, принцип “черный ящика”) в Simula было введено строгое контролирование к доступу информации, однако “черный ящик” в объектной модели является в открытым к изменениям. Создавая свою модель на подобием существующей (наследуясь от нее) можно сделать изменения в базовой модели для своего объекта. Это достигается за счет техники полиморфизма.

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

Среда

Переносимая система Simula (S-Port) содержит независимый пакет, состоящий из компилятора, генерирующего промежуточный язык S-code, систему поддержки работающей программы и символьного отладчика. Также есть система, зависимая от целевой машины, содержащая компилятор, транслирующий S-code в целевой код, и набор программ интерфейса. Планируется создать дополнительные средства и библиотеку предопределенных модулей.

Поставщики

Первая реализации на Univac 1107 появилась в начале 70-х гг. С этих пор язык был реализован на большинстве платформ, от больших ЭВМ до персоналок. В настоящее время Simula развивается и выступает на рынке под названием Simula a.s., установленным норвежской фирмой в 1984 г.

Переносимая система Simula (S-Port) — является основой многочисленных версий, включая PC Simula.
<...>
Сформированная в 1972 г. организация Simula Standards Group осуществляет контроль за развитием языка: самая последняя версия была выпущена в 1986г. Изменения в язык вносит Simula Developement Group. Кроме того, есть ассоциация пользователей языка Simula.

! The program defines the main class "Geometry".;
! It represents a theory with terms "point, rectangle, circle, and line".;
Class Geometry;
Begin
  Class Point(X,Y); Real X,Y;
  Begin
    Procedure Print; Begin  ...  End;
    Procedure Shift(Dx, Dy); Real Dx, Dy; Begin  ...  End;
    Print;                  ! Life of point;
  End of Point;

  Class Rectangle(RecName, Width, Height);
       Text RecName; Real Width, Height;
  Begin
    Real Area, Perimeter;
    Procedure Update; Begin  ...  End;
    Procedure Show; Begin  ...  End;
    Update; Show;           ! Life of rectangle;
  End of Rectangle;

  Class Circle(Radius, Center); Real Radius; Ref(Point) Center;
  Begin
    Procedure Shift(Dx, Dy); Real Dx, Dy; Begin  ...  End;
    OutText("Circle created at "); ! Life of circle;
    Center.Print;
  End of Circle;

  Class Line(M,N); Ref(Point) M,N; ! Line defined by two points;
  Begin
    Real Slope;
    Slope :=  ...  ;       ! Life of line;
  End of Line;

  !Variables declared in geometry:;
  Ref(Point) Origin, A, B;
  Ref(Line) X,Y;

  !Life of geometry:;
  Origin :- New Point(0,0); ! Creating the origin;
  A :- New Point(1,0); B :- New Point(0,1);
  X :- New Line(Origin, A); ! Creating the axes;
  Y :- New Line(Origin, B);
  OutText("*** Geometry initialized ***"); OutImage;
End of Geometry;

Next program is using the main class Geometry. Note how the classes declared in Geometry are used to declare subclasses specialized to the problem being solved. Later it is possible to declare and use reference variables qualified into both imported and locally declared classes. This is the fundamental idea of Simula based packages or user defined languages (what is the difference?)

External Class Geometry;
Geometry Begin
  ! Subclasses declared in the prefixed block:;
  Point Class Color_Point(C); Character C; Begin  ...  End;
  Rectangle Class Square; Begin  ...  End;

  ! Variables declared in the prefixed block:;
  Ref(Color_Point) A1;
  Ref(Point) C, D;
  Ref(Circle) K;
  Ref(Line) E, F;
  Ref(Rectangle) R1;
  Ref(Square) S1;

  ! Block body:;
  C :- New Point(5,6);
  D :- New Point(20,30);
  A1 :- New Color_Point(3, 4, 'G');
  K :- New Circle(10, C);
  E :- New Line(C, D);
  F :- X;
  K.Shift (1,1);
  R1 :- New Rectangle("Rec_R1", 5, 4);
  S1 :- New Square("Square_S1", 4, 6);
  S1.Show;
End of prefixed block;

program blah;
var
    d  : Integer;
    m,n : array [1..4][1..4] of real;

procedure PoschitatDeterminant;
begin
{Тут считают детерминант матрицы m}
end;

procedure UmnozhitMatricy;
begin
{Тут умножают матрицу m на n}
end;

begin
{что-то еще}
end.

создать_новый_объект
pop ax ; В ax будет адрес нового объекта
<-- И тут врубается полный цикл GC, запущеный из другого потока
mov var_1,ax ;Запишем ax в переменную

;В ax лежит адрес объекта
push ax ;Кладем его в стек
push some_parameter
<-- Приходит пушной зверек GC
call SomeFunction
...

AVC>Совпадение в этом отношении (автоматическое управление памятью и безопасность типов) с Обероном — чистая случайность, конечно.

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

AVC>Что касается ":=", то признай, что ты не смог подобрать примера опечатки с ":=". Я все прощу!

AVC>Где??!

ЗХ>А то как же

Просто невозможно поблагодарить всех тех, кто так или иначе подпитывал своими идеями то, что
теперь называется Oberon. Большинство идей пришло от использования и изучения
существующих языков, таких как Modula-2, Ada, Smalltalk и Cedar, которые часто предостерегали
нас от того, как не надо делать.

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

A+B->C

                                        Си++    Java    Oberon
Модульность и раздельная компиляция     Нет     Да     Да
Шаблоны                                 Да      Нет    Нет
Сборка мусора                           Нет     Да     Да
Деструкторы                             Да      Нет    Нет
Объединения (union)                     Да      Нет    Нет
Многомерные открытые массивы            Нет     Да     Да
Наследование                            Мн.     Од.    Од.
Оператор goto                           Да      Нет    Нет

I went to a Pascal conference in Southampton in 1977 and Brinch-Hansen described Concurrent
Pascal. When asked what he thought of Modula (that Wirth just had brought out), he replied that
you might do something clever but then "Claus" would come with the worked-through elegant version of it!

//a и b - это value-типы
a:=b; //Обычное копирование. После него a=b.

b:=c;
a<=b; //Перемещение, 'a' равно 'c', но b - пусто.

Что в Java действительно ново?

При ближайшем рассмотрении довольно быстро обнаруживается, что революционных новшеств в
Java совсем немного. Правильнее сказать, что Java объединяет ряд давно известных идей, причем
поразительно многие из них восходят к работам Никлауса Вирта и его исследовательской группы в
Швейцарском федеральном технологическом институте (ETH) в Цюрихе.
• Переносимость Java основана на наличии виртуальной машины [Линдхольм и др.],
позволяющей легко имитировать большое число архитектур. Идея виртуальной машины была
очень популярна уже более двадцати лет назад, хотя впоследствии о ней забыли. Тогда речь
шла о Pascal-P — созданной в ETH реализации Паскаля [Нори и др.], которая сыграла
решающую роль в распространении этого языка. Интересно, что виртуальные машины для
Паскаля и Java весьма схожи по архитектуре: в обеих используются однобайтовые
инструкции без адресов (операнды помещаются в стек).
• Не нова также идея строгой типизации с поддержкой динамических типов и системы "сборки
мусора", причем роль первооткрывателя здесь тоже сыграл цюрихский ETH. Многие из
аргументов, с помощью которых команда разработчиков Java обосновывает отказ от
использования указателей, были сформулированы за пять лет до выхода Java в среде
"сообщества модульных языков" (modular language community) при обсуждении
разработанного Виртом языка программирования Оберон [Вирт 88]. С давних пор в
виртовских языках [Вирт 71, 82, 88] принимаются и другие меры по усилению надежности,
такие как проверка индекса при добавлении элементов в массив, — однако до сих пор
программисты рассматривали их скорее как досадное ограничение, чем как преимущество.
По-видимому, рекламная кампания Sun привела к определенному перелому в общественном
мнении по данному вопросу.
• Мысль о том, что язык со строгой типизацией делает возможным построение программ,
переносимых с одной архитектуры на другую, в 1990-93 гг. нашла в ETH воплощение в целом
семействе [Брандис и др.] реализаций Оберон-систем [Вирт-Гуткнехт 89, 92]. Они отличались
не только единым интерфейсом прикладных программ для всех аппаратно-программных сред
[Франц 93], но и единой машинно-независимой архитектурой документов [Шиперский], уже в
то время предусматривавшей встраивание в текст "плавающих" активных объектов.
Созданный в развитие идеи пакет Oberon System 3 [Гуткнехт] идет еще дальше, заменяя
присущее современным Java-браузерам концептуально неудовлетворительное разграничение
между текстом и объектами на единую интегрированную объектную модель.
• Программы на Java могут состоять из нескольких независимо компилируемых единиц,
которые "динамически" собираются воедино только в момент загрузки [Франц 97]. В Java
поддерживается "истинная" раздельная компиляция, при которой компилятор производит
проверку границ между модулями. Программистам, имеющим дело в основном с Си/Си++,
это, возможно, покажется значительным усовершенствованием, поскольку там для
раздельной обработки применяется крайне примитивный механизм включения
непосредственно в текст так называемых "заголовочных файлов". Однако в мире модульного
программирования возможности, эквивалентные имеющимся в Java, на протяжении уже
более чем десяти лет являются стандартом. Краеугольный камень здесь также заложил
Никлаус Вирт, создав язык Модула-2 [Вирт 82].
• Даже преподносимая сейчас в качестве главной инновации Java идея не зависящих от
платформы мобильных программ в сочетании с генерацией кода в процессе выполнения
еще раньше появилась в ETH. Выполненная под руководством Вирта диссертация автора
этих строк [Франц 94] посвящена описанию динамически расширяемой системы, в
которой исполняемый объектный код "на лету" порождается из промежуточного
машинно-независимого формата. В этой диссертации, опубликованной на английском
языке в феврале 1994 г., т. е. более чем за год до самой первой презентации Java, уже
появляется слово applet и описывается ряд сценариев, весьма сходных с
существующими сегодня на Java. В настоящее время автор работает над дальнейшим
развитием своей системы, обладающей несколькими преимуществами по сравнению с
Java [Франц-Кистлер]. В связи с этим может быть интересно то обстоятельство, что в
марте 1994 г. автором был прочитан в Калифорнии ряд докладов по теме диссертации,
причем один из них — в Sun Laboratories, Inc. Кроме того, упомянутый выше Билл Джой,
который переориентировал проект Java на WWW, стал одним из первых обладателей
лицензии на Оберон-систему ETH, и в конце 1994 — начале 1995 г. он неоднократно
связывался с ETH; в процессе контактов выяснилось, что он читал мою диссертацию.

In computer programming, a virtual machine executing p-code, the p-Code machine or pseudo-code machine was the target of some early Pascal implementations. That is, the programming language Pascal was translated not to machine code instructions (understandable directly to a processor), but to p-code instructions. To execute the program, another program is used that interprets this code.

The Business Operating System (BOS) of the 1980s was a cross-platform operating system designed to exclusively run p-code based programs.

The UCSD p-System was a portable machine independent operating system based on p-code.

Д>                                    Си++ Java Oberon C#
Д>Модульность и раздельная компиляция Да**  Да    Да    Да
Д>Сборка мусора                       Нет   Да    Да    Да
Д>Наследование                        Мн.   Мн.*  Од.   Мн.*
Д>Виртуальная машина                  Нет   Да    Нет   Да
Д>Отражение                           Нет   Да    Нет   Да
Д>Прямой доступ к памяти              Да    Нет   Да    Да

Д>* только для интерфейсов, но не для реализаций
Д>** без поддержки ООП
Д>

E>Нифига не понятно. Как вообще в этом разобраться, если нет грамматик для FieldList, IdentDef, FormalPars, DeclSeq, StatementSeq.

System flags for record types

Name    Value    Description
untagged    1    No type tag and no type descriptor is allocated.
        The garbage collector ignores untagged variables.
        NEW is not allowed on pointers to untagged variables.
        No type-bound procedures are allowed for the record.
        Pointers to untagged record type or extensions of this
        record type inherit the attribute of being untagged.
        The offsets of the fields are aligned to
        MIN(4-byte, size), where size is the size of the field.
        The size of the record and the offsets of the fields are
        aligned to 32-bit boundaries.
noalign    3    Same as untagged but without alignment.
align2    4    Same as untagged but with
        MIN(2-byte, size) alignment. 
align8    6    Same as untagged but with
        MIN(8-byte, size) alignment. 
union    7    Untagged record with all fields allocated at offset 0.
        The size of the record is equal to the size of the
        largest field.
        Used to emulate C union types.

System flags for array types
Name    Value    Description
untagged    1    No typetag and no type descriptor is allocated.
        The garbage collector ignores untagged variables.
        NEW is not allowed on pointers to untagged variables.
        Pointers to this array type inherit the attribute of
        being untagged.
        Only one-dimensional untagged open arrays
        are allowed.
        For open untagged arrays, index bounds are
        not checked.

System flags for pointer types
Name    Value    Description
untagged    1    Not traced by the garbage collector.
        No type-bound procedures are allowed for the pointer.
        Must point to an untagged record.

System flags for VAR parameters
Name    Value    Description
nil    1    NIL is accepted as formal parameter.
        Used in interfaces to C
        functions with pointer type parameters.

System flags for procedures
Name    Value    Description
code    1    Definition of a Code procedure (see below).
ccall    -10    Procedure uses CCall calling convention.

    PROCEDURE [code] Sqrt (x: REAL): REAL        (* Math.Sqrt *)
        0D9H, 0FAH;            (* FSQRT *)

    PROCEDURE [code] Erase (adr, words: INTEGER)    (* erase memory area *)
        089H, 0C7H,            (* MOV EDI, EAX *)
        031H, 0C0H,            (* XOR EAX, EAX *)
        059H,            (* POP ECX *)
        0F2H, 0ABH;            (* REP STOS *)

MODULE MyInterface ["MyDll"];
    PROCEDURE Proc1*;                (* Proc1 from MyDll *)
    PROCEDURE Proc2* ["BlaBla"];                (* BlaBla from MyDll *)
    PROCEDURE Proc3* ["OtherDll", ""];                (* Proc3 from OtherDll *)
    PROCEDURE Proc4* ["OtherDll", "DoIt"];                (* DoIt from OtherDll *)
END MyInterface.

    RECORD [noalign]    (* untagged, size = 7 bytes *)
        c: SHORTCHAR;    (* offset 0, size = 1 byte *)
        x: INTEGER;    (* offset 1 , size = 4 bytes *)
        i: SHORTINT    (* offset 5, size = 2 bytes *)
    END

MODULE Ddraw ["DDRAW.DLL"];

TYPE
  GUID = ARRAY 4 OF INTEGER;

  PtrIUnknown = POINTER TO RECORD [untagged]
    vtbl: POINTER TO RECORD [untagged]
      QueryInterface: PROCEDURE (this: PtrIUnknown; IN iid: GUID; OUT obj: PtrIUnknown): INTEGER;
      AddRef: PROCEDURE (this: PtrIUnknown): INTEGER;
      Release: PROCEDURE (this: PtrIUnknown): INTEGER;
    END
  END;

  PtrDirectDraw = POINTER TO RECORD [untagged]
    vtbl: POINTER TO RECORD [untagged]
      QueryInterface: PROCEDURE (this: PtrDirectDraw; IN iid: GUID; OUT obj: PtrIUnknown): INTEGER;
      AddRef: PROCEDURE (this: PtrDirectDraw): INTEGER;
      Release: PROCEDURE (this: PtrDirectDraw): INTEGER;
      Compact: PROCEDURE (this: PtrDirectDraw): INTEGER;
      ...
      SetCooperativeLevel: PROCEDURE (this: PtrDirectDraw; w, x: INTEGER): INTEGER;
      ...
    END
  END;

PROCEDURE DirectDrawCreate* (IN guid: GUID; OUT PDD: PtrDirectDraw; outer: PtrIUnknown) : INTEGER;

END Ddraw.

MODULE GDI ["GDI32"];

    CONST
        WhiteBrush* = 0; BlackBrush* = 4; NullBrush* = 5;
        WhitePen* = 6; BlackPen* = 7; NullPen* = 8;
        PSSolid* = 0; PSDash* = 1; PSDot* = 2;

    TYPE
        Bool* = INTEGER;
        Handle* = INTEGER;
        ColorRef* = INTEGER;
        Point* = RECORD [untagged] x*, y*: INTEGER END;
        Rect* = RECORD [untagged] left*, top*, right*, bottom*: INTEGER END;

    PROCEDURE CreatePen* (style, width: INTEGER; color: ColorRef): Handle;
    PROCEDURE CreateSolidBrush* (color: ColorRef): Handle;
    PROCEDURE GetStockObject* (object: INTEGER): Handle;
    PROCEDURE SelectObject* (dc, obj: Handle): Handle;
    PROCEDURE DeleteObject* (obj: Handle): Bool;
    PROCEDURE Rectangle* (dc: Handle; left, top, right, bottom: INTEGER): Bool;
    PROCEDURE SelectClipRgn* (dc, rgn: Handle): INTEGER;
    PROCEDURE IntersectClipRect* (dc: Handle; left, top, right, bottom: INTEGER): INTEGER;
    PROCEDURE SaveDC* (dc: Handle): INTEGER;
    PROCEDURE RestoreDC* (dc: Handle; saved: INTEGER): Bool;

END GDI.

AVC>Ну что же, Оберон вполне подходит. Только он не в пример читабельнее Смолтока.

def hello
    puts "hello"
end

# Это не правильно!
def hello puts "hello" end

def hello; puts "hello"; end

def f(a); a.inspect; end

f :a => 3, :b => 4, :c => 5
f( :a => 3, :b => 4, :c => 5 )
f( { :a => 3, :b => 4, :c => 5 } )

c.field :name => :source_addr_ton,
                :type => "oess_1::uchar_t",
                :bit_mask => 0x1,
                :default => 0

while line = gets.chop
    if "quit" == line
        break
    elsif line =~ REQUIRE_REGEX
        exception_guard do
            require REQUIRE_REGEX.match( line )[ 1 ]
        end
    elsif line =~ CALL_METHOD_REGEX
        exception_guard do
            m = t.method( CALL_METHOD_REGEX.match( line )[ 1 ] )
            m.call
        end
    elsif line =~ EVAL_REGEX
        exception_guard do
            eval EVAL_REGEX.match( line )[ 1 ]
        end
    end

    print "=>"
end

def exception_guard
    begin
        yield
    rescue StandardError => x
        puts x
    end
end

class Project < ActiveRecord::Base
    belongs_to              :portfolio
    has_one                 :project_manager
    has_many                :milestones
    has_and_belongs_to_many :categories
end

AVC>Но здесь выходит, что на стройке надо ходить без каски. Тогда, мол, строители будут осторожнее.

void f()
{
    std::auto_ptr< Some_Class > my_object( new Some_Class() );
}

std::auto_ptr< Some_Class >
create_object()
    {
        return std::auto_ptr< Some_Class >( new Some_Implementation_Class() );
    }

def f
    my_object = Some_Class.new
end

def create_object
    return Some_Implementation_Class.new
end

irb(main):014:0> a = {}
=> {}
irb(main):015:0> a.class.name
=> "Hash"
irb(main):016:0> a.instance_variables
=> []
irb(main):017:0> a.class.instance_methods
=> ["reject", "[]=", "send", "object_id", "value?", "size", "singleton_methods", "to_hash", "__send__",
"member?", "equal?", "taint", "find", "frozen?", "instance_variable_get", "each_with_index",
"each_pair", "kind_of?", "delete_if", "merge!", "instance_eval", "require", "to_a", "replace",
"collect", "merge", "all?", "entries", "type", "store", "protected_methods", "extend", "detect", "eql?",
"values", "zip", "instance_variable_set", "hash", "is_a?", "empty?", "default", "map", "to_s", "any?",
"class", "sort", "tainted?", "private_methods", "default=", "default_proc", "key?", "min", "f",
"require_gem_with_options", "untaint", "find_all", "keys", "reject!", "invert", "each", "id",
"has_key?", "inject", "inspect", "delete", "==", "indexes", "===", "sort_by", "clone", "public_methods",
"fetch", "each_value", "max", "values_at", "respond_to?", "display", "index", "select", "freeze",
"shift", "update", "clear", "length", "has_value?", "__id__", "rehash", "partition", "=~", "methods",
"require_gem", "method", "indices", "nil?", "grep", "dup", "each_key", "instance_variables", "include?",
"[]", "instance_of?"]

AVC>При наличии статической типизации.

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

В чем я вижу преимущества динамической типизации на примере
Lisp/Smalltalk (многие перечисленные преимущества являются следствием
предыдущих):

* Маленькое количество правил языка, простой, но очень гибкий и
выразительный синтаксис

* Нет необходимости писать много лишнего кода для многократного
указания типов

* Широкии возможности интроспекции/рефлекшна

* Наличие мощных конструкции вроде closures, continuations, green threads

* Более высокий уровень абстракции, благодаря чему можно на самом
языке можно создавать domain-specific languages

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

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

NGG>Отличный набор слов, звучит убидительно — только ссмысла в них нет, поскольку j2ee и j2me реализуют разные интерфейсы

Write once, run everywhere

NGG>Даже распоследний ассемблер. Был бы только компилятор под нужную платформу

L>А разве компилятор не может изменить физичекий порядок следования полей в структуре?

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.