Flying in a blue dream

(весь нижеследующий текст будет понятен только программистам и интересующимся)

Итак, если кто не знает, сегодня утром в лектории политехнического музея была лекция "History and perspectives of Oberon language". Читал её Никлаус Вирт самолично.

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

Организация была "на высоте", как и всегда. Российские традиции блюлись со всей строгостью: толпа из примерно пятисот вполне приличных людей — студенты, программисты, институтские преподаватели — честно стояла в очереди за пригласительными, выдававшиеся двумя девушками, неспешно водившими пальчиком по спискам. Ровно половину аудитории (естественно, лучшую) отгородили "для вип-персон". Таковых оказалось десяток или два — однако всех остальных на эти ряды не пускали ещё долго. Перед лекцией какая-то тётка долго и упоно рассказывала, в каких славных стенах проходит действо. А переводчик, который переводил лекцию — это вообще отдельная песня. Но про это — потом.

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

Гораздо интереснее были ответы на вопросы из зала. Очень чётко прорисовались все те идеи, которые сейчас активно продвигают оберономаны: это-таки идеи Вирта, а не кого-то ещё. Если вкратце, то:

1) Хороший язык — это простой язык. Жёстки, чёткий, логичный, с максимально строгой типизацией.
2) Оберон является таким языком. На обероне можно писать всё что угодно, а ещё лучше — всё сразу. Пресловутая Lilith тому примером.
3) Оберон не является промышленным стандартом потому, что ему не учат в университетах. А в университетах не учат оберон, потому что он не является промышленным стандартом. Порочный круг.
4) С/С++ и другие языки, которые сейчас этими стандартами являются, стали таковыми в основном благодаря маркетингу и громадной финансовой мощи тех, кто их продвигал.
5) Open source — это классно.
6) Java и C# позаимствовали из Оберона кой-какие идеи, но они были извращены синтаксисом С (так и сказал — corrupted with C syntax) и потому плохи. Но явно лучше, чем С и С++.

Сам Вирт как человек — очень симпатичен. Классический старенький профессор с седой головой, спокойным и приятным (хотя немного дрожащим) голосом, ясным умом, чистой и аккуратной речью и иногда просыпающимся чувством юмора. Английский у него IMHO очень неплохой, хотя говорил он довольно просто — лично я понимал его речь без проблем — но акцент очень сильный и довольно чудной. Наверное, учиься у него было бы классно.

Но, к сожалению, лекция была ОЧЕНЬ сильно испорчена переводом. Переводил какой-то придурковатый растрёпанный хамоватй мужичок, видимо — штатный переводчик политехнического. Мало того, что он не знал терминов и нёс всякую чушь (tree structures — три-структуры, open source — открытые источники, concurrency — то совместимость, то конкуренция, hard drive — твёрдый диск, 7-pass compiler — семиразрядный компилятор, compilation — исчисление и пр.), так он ещё и обычные фразы переводил совершенно похабно. Похабно не по смыслу, а по тону и подбору слов. Если Вирт говорил в стиле университетской лекции, то переводчик — не то в стиле журнала "Хакер", не то в стиле мартышки из зоопарка. Интересно, Вирт понял, что часто возникавший сдавленный ржач в зале относился не к нему, а к очередным "большим массивам программирования"?

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

Профессор ответил на вторую часть вопроса, потонувшую в гоготе: "И, если говорить шире, появятся ли машины, способные полностью заменить человека?" Ответ был — "Completely? Well, I think I wouldn't like her." Молодец деда

---

Перечитал написанное, и понял, что ничего не сказал о самом главном:

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

Кстати, теперь у меня на последней страничке зачёки примостился скромный и аккуратный "зачёт" от профессора Вирта. Ещё один повод "потерять" её перед выдачей диплома

AF> А если посмотреть чуть шире (в то в философском смысле) оказывается, что наколеночные технологии (C, C++, Java, C#, Perl, Ruby, Tcl/Tk, ...) в целом гораздо успешнее, чем наработки теоретические (ADA, Pascal, Oberon...). По моему это получается в следствие учёта реальных потребностей тех, кому технология нужна и для кого она предназначени, а так же обратной связи от них. В случае же теоретических разработок если потребности чьи-то и учитываются, то только не тех, кому с технологией работать.

if( something )
    do_that()

do_that() if( something )

E>if( 10 == a ) do_something();
E>

E>if( a == 10 ) do_something();
E>

"Если a равно десяти, то..."
"Если 10 равно а то..."

void* (*pointerVarName)(void*);
typedef void* (*FuncPointerTypeName)(void*);

delegate object DelegateTypeName(object param);

*(a += i)

_FR>А что за необходимость? чем практически постфиксная запись отличается от префиксной

cmd_line = "ruby " + a_config.action_script_name
a_config.action_script_params.each do |pair|
    cmd_line << " " << pair[ 0 ]
    cmd_line << "=" << pair[ 1 ] if pair[ 1 ]
end

cmd_line = "ruby " + a_config.action_script_name
a_config.action_script_params.each do |pair|
    cmd_line << " " << pair[ 0 ]
    if pair[ 1 ]
        cmd_line << "=" << pair[ 1 ]
    end
end

cmd_line = "ruby " + a_config.action_script_name
a_config.action_script_params.each do |pair|
    cmd_line << " " << pair[ 0 ]
    if pair[ 1 ] then cmd_line << "=" << pair[ 1 ] end
end

paths = []
config.each_element( CONFIG_PATH_TAG ) do |e|
    paths << Config.mandatory_attr( e, CONFIG_PATH_NAME_ATTR )
end unless nil == config.elements[ CONFIG_PATH_TAG ]

paths = []
if nil != config.elements[ CONFIG_PATH_TAG ]
    config.each_element( CONFIG_PATH_TAG ) do |e|
        paths << Config.mandatory_attr( e, CONFIG_PATH_NAME_ATTR )
    end
end

public class Rhymes {
   private static Random rnd = new Random();
   public static void main(String[] args) {
     StringBuffer word = null;
     switch(rnd.nextInt(2)) {
       case 1: word = new StringBuffer('P');
       case 2: word = new StringBuffer('G');
       default: word = new StringBuffer('M');
     }
     word.append('a');
     word.append('i');
     word.append('n');
     System.out.println(word);
   }
}

What Does It Print?
(a) Pain, Gain, or Main (varies at random)
(b) Pain or Main (varies at random)
(c) Main (always)
(d) None of the above

public class NameGame {
   public static void main(String args[]) {
     Map m = new IdentityHashMap();
     m.put("Mickey", "Mouse");
     m.put("Mickey", "Mantle");
     System.out.println(m.size());
   }
}

What Does It Print?
(a) 0
(b) 1
(c) 2
(d) It varies

public class Names {
   private Map m = new HashMap();
   public void Names() {
     m.put("Mickey", "Mouse");
     m.put("Mickey", "Mantle");
   }
   public int size() { return m.size(); }
   public static void main(String args[]) {
     Names names = new Names();
     System.out.println(names.size());
   }
}

What Does It Print?
(a) 0
(b) 1
(c) 2
(d) It varies

public class Gray {
   public static void main(String[] args){
     System.out.println(X.Y.Z);
   }
}
class X {
   static class Y {
     static String Z = "Black";
   }
   static C Y = new C();
}
class C {
   String Z = "White";
}

What Does It Print?
(a) Black
(b) White
(c) Won’t compile
(d) None of the above

There have been (to our knowledge) no complete, thorough, scientific studies conducted comparing the productivity of development using Java vs. C. But we have a few random data points:

Sun and many others quote a study by IDC called "Java Pays -- Positively" that claimed a 40% savings in using Java for development and 30% in maintenance. Unfortunately, that report was published back in May, 1998 and is nowhere to be found today.

A personal web page by Robert Wells entitled Java offers Increased Productivity contains some analysis and references, but no hard numbers.

The paper entitled An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl by Lutz Prechelt compares multiple languages on performance. It has a section on "Program Reliability" and another on "Work time and productivity", but it finds no significant difference in programs written in C vs. Java.

A second paper by the same author and based on the same experimental data, Comparing Java vs. C/C++ efficiency differences to inter-personal differences finds that differences in programmers' ability was a bigger factor in determining code efficiency than the language used. The same lesson also applies to choosing a programming language: it's more important to choose good developers than to choose a good language. With that said, it's still the case that given that you have a particular set of developers, choosing one language over another does make a big difference.

A web page called Java From The Trenches by Jim Frost claims that "Java's feature set is such that most developers see a 200% to 300% improvement in time to completion versus C++, and much better code reliability to boot. In some cases, such as server applications, Java productivity is an order of magnitude better than C++...". The page does not say where those numbers came from.

It would seem that software cost estimating models and tools would take into account which programming language is being used. Surprisingly, it seems that most do not. The COCOMO II model, the most popular model for software cost estimation, does not care which programming language is being used: the cost of developing 1000 non-comment lines of source code is independent of the programming language. Of course, it would take far more lines of assembly language than C to accomplish a particular task. If you believe this, then whether it takes more or less lines of Java code to do a particular task is critical. See the "Software Cost Estimation" section below for more on counting lines of code.

In two cases, management made a decision to directly port cash cow C and C++ products to Java. They believed that creating a multi-platform product in Java would decrease long-term development costs and time to market.

The development teams bought into the concept completely and did their best to handle the port within the allotted time frame. Unfortunately, line-in-the-sand deadlines combined with crushing workloads working in a language that did not lend itself well to the port resulted in the creation of products that did not work as planned. The original applications were fast, reliable, easy to set up and non-consumptive, but the Java versions were not.

One of the companies made the mistake of converting their C and C++ code base directly into Java hoping that the end result would work well enough to release. It did not. The direct port resulted in a poor imitation of the original, but the company released the product anyway.

Both products failed to gain sustained acceptance after release. The development teams reacted by working harder than before to optimize the code, reduce bugs, and make adoption more palatable to the customer. Unfortunately, the damage had been done and new sales went flat.

> AVC>while (*dest++ = *source++)
> AVC>   ;
> AVC>

bool a = ...;
bool b = ...;

if ( a = b )
{
   . . .
}

D>Java — тоже язык для дебилов?

void changeArgument( SomeClass someObject )
{
    someObject.setSomething( "a" );
    ...
}

void initiateChanging()
{
    SomeClass someObject = new SomeObject();
    someObject.setSomething( "b" );
    changeArgument( someObject );
    // Вот тут someObject.getSomething() будет возвращать "a", а не "b".
}

bool find_something( const key_t & k, int & a, int & b, int & c )
    {
        ...
        a = ...;
        b = ...;
        c = ...;
        ...
    }
...
int a, b, c;
find_something( k, a, b, c );

boolean findSomething( Key k, int[] res )
{
    ...
    res[ 0 ] = ...;
    res[ 1 ] = ...;
    res[ 2 ] = ...;
}
...
int[] abc = new int[ 3 ];
findSomething( k, abc );

4) С/С++ и другие языки, которые сейчас этими стандартами являются, стали таковыми в основном благодаря маркетингу и громадной финансовой мощи тех, кто их продвигал.

E>>Просто попробуй

action = new widget_action_t(
        is_connected ? impl::c_connected_group : impl::c_disconnected_group,
        ip, m_action_group );
action->setText( channel_name );
action->setIconSet( srv_icon );
action->setToolTip( channel_name );
action->setStatusTip( channel_name );

int group = impl::c_disconnected_group;
if( is_connected )
    group = impl::c_connected_group;
action = new widget_action_t( group, ip, m_action_group );
action->setText( channel_name );
action->setIconSet( srv_icon );
action->setToolTip( channel_name );
action->setStatusTip( channel_name );

class ArrayDefaultTag{};
template<class T, int N, class Tag = ArrayDefaultTag>
struct Array
{
    T& operator[](int i)
    {
        return arr[i];
    }
    T const& operator[](int i)const
    {
        return arr[i];
    }
    int Length()const
    {
        return N;
    }
private:
    T arr[N];
};

typedef Array<int, 3> A;
typedef Array<int, 3> B;

void fa(A & v)
{    
}

void fb(B & v)
{
}

int main()
{
    A a;
    B b;
    fa(b);
    fb(a);
}

class ArrayATag{};
class ArrayBTag{};
typedef Array<int, 3, ArrayATag> A;
typedef Array<int, 3, ArrayBTag> B;

ПК>int a[5] = { 0, 1, 2, 3, 4 };
ПК>

void foo(int *p)
{
    /* сначала немного любимой адресной арифметики */
    p[-1] = 666; /* раз */
    5[p]  = 666; /* два */

    /* да, и, кстати, как же здесь отличить массив от указателя? :xz:  */
    free(p);     /* три */
}

void bar()
{
    static int a[5] = { 0, 1, 2, 3, 4 };

    foo(a);
}

x = 1

----------------------------------------
— Почему пячь попал в сосдеское стекло?
— Наверное не сработало ваше земное притяжение.

void strcpy(char* to, char* from)
{
    while (*to++ = *from++);
}

// ... some code
while (a=foo()) {
    boo(a);
}
// ... some code

// ... some code
while (a==foo()) {
    boo(a);
}
// ... some code

  TYPE
    Vector3D = ARRAY 3 OF REAL; (* value-type, SIZE(Vector3D) = 3*8 = 24 *)

  PROCEDURE f(v: Vector);
  ...

Т>VAR
Т>  f: FuncWithoutArgs;
Т>  x: REAL;
Т>  ...
Т>  f := Random; (* использование в качестве процедурной константы *)
Т>  x := Random; (* вызов функции *)
Т>

TYPE
  F = PROCEDURE(): F;

VAR
  f, g, h: F;
BEGIN
  ...
  g := f;
  h := f(); (* f и f() - разные вещи *)

typedef struct tagString
{
    size_t length;
    char *data;
} String;

String createString(const char *str)
{
    String res;
    res.length=strlen(str);
    res.data=strdup(str);
    return res;
}
void deleteString(String *str)
{
    res->length=0;
    free(res->data);
}
void appendString(String *dst,String *src)
{
    dst->length+=src->length;
    char *tmp=calloc(dst->length+1);
    strcat(tmp,dst->data);
    strcat(tmp,src->data);
    free(dst->data); dst->data=tmp;
}

String str;

str=createString("This is a string");
deleteString(str);

VAR
  f: FuncWithoutArgs;
  x: REAL;
  ...
  f := Random; (* использование в качестве процедурной константы *)
  x := Random; (* вызов функции *)

EE>Мировосприятием и настроением программиста в данный, конкретный момент времени Строго говоря, разница только на эстетическом уровне. Вот парочка примеров.

  if (cond1)
  {
     do_some1() if (cond2);
     do_some3() if (cond3);
  }

E>action = new widget_action_t(
E>        is_connected ? impl::c_connected_group : impl::c_disconnected_group,
E>        ip, m_action_group );
E>action->setText( channel_name );
E>action->setIconSet( srv_icon );
E>action->setToolTip( channel_name );
E>action->setStatusTip( channel_name );
E>

E>int group = impl::c_disconnected_group;
E>if( is_connected )
E>    group = impl::c_connected_group;
E>action = new widget_action_t( group, ip, m_action_group );
E>action->setText( channel_name );
E>action->setIconSet( srv_icon );
E>action->setToolTip( channel_name );
E>action->setStatusTip( channel_name );
E>

E>Неужели всторой вариант проще?

action = new widget_action_t( GetGroup(), ip, m_action_group );

A character-string containing a single string-element shall denote a
value of the required char-type
(see 6.4.2.2). A character-string containing more than one
string-element shall denote a value of
a string-type (see 6.4.3.2) with the same number of components as the
character-string contains
string-elements. All character-strings with a given number of components
shall possess the same
string-type.
There shall be an implementation-defined one-to-one correspondence
between the set of alternatives
from which string-elements are drawn and a subset of the values of the
required char-type. The
occurrence of a string-element in a character-string shall denote the
occurrence of the corresponding
value of char-type.

E>>hint: размещать константу слева от знака равенства. Тогда выражение if( 10 = a ) просто не скомпилируется.

if( 10 == a ) do_something();

if( a == 10 ) do_something();

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

result = if 10 == a
        do_something()
    else
        do_something_else()
    end

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

AVC>>Очень интересно, как можно опечататься с ":=", так чтобы компилятор этого не заметил?

GZ>var
GZ>a:boolean;
GZ>b:boolean;
GZ>begin
GZ>   if (a:=b)then
GZ>.....
GZ>end;

Т>VAR
Т>  f: FuncWithoutArgs;
Т>  x: REAL;
Т>  ...
Т>  f := Random; (* использование в качестве процедурной константы *)
Т>  x := Random; (* вызов функции *)
Т>

TYPE ProcType = PROCEDURE(): ProcType;
PROCEDURE Auto(): ProcType;
BEGIN
...
END Auto;
VAR fp: ProcType;
...
  fp := Auto; (* и что здесь означает Auto: процедурную константу или вызов функции? *)

4) С/С++ и другие языки, которые сейчас этими стандартами являются, стали таковыми в основном благодаря маркетингу и громадной финансовой мощи тех, кто их продвигал.