Начал изучать Python. Первые впечатления.

[RXL]

Собираюсь в этой теме писать свои впечатления о Python. Ну, и если что-то будет не понятно, то и вопросы.

Читаю книгу "Программирование на Python 3. Подробное руководство." Марка Саммерфилда.

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


1. Встроенные типы. К ним относится только int и str, или bool, float и complex тоже?

2. Прочел о неизменности встроенных объектов. Пояснение к вопросу:

obj.x = 1
a = obj.x
obj.x = 2
# a = 1, obj.x = 2

Хочу, чтобы и a изменялось. Т.е. иметь ссылку в понимании других языков (C++, Perl, PHP). Иначе это просто принцип copy-on-write - создание нового объекта при изменении. По сути - присваивание по значению. Хочу полноценную ссылку. Такое тут есть?

3. Комбинирование логических операторов.

1 <= a <= 3 # понятный аналог из SQL: a between 1 and 3

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

4. Оператор is. Я так понял, это похоже на === в Java и PHP. Правильно?

5. Оператор in. Очень приятная неожиданность, что он не только с коллекциями работает, но и со строками. Хорошо ли это на самом деле - покажет практика.

6. Как я понял, в Питоне нет автоматического приведения числовых и строковых типов, как во многих скриптовых языках. Это так?

[.]

1.все типы, которые ты можешь найти в __builtins__ (там еще много других)
2. когда ты говоришь
a = obj.x
в си:
void *a, *x;
a = x;
x= y; // a  не изменилось

здесь так же
3. отсутствует напрочь, как и в C/C++, Java, c#
придется записывать полностью: a <= 1 and a <=3
4. сравнение по ссылке. есть некоторое множество объектов (Классы - это тоже объекты), которые являются синглтонами.
для ==  вызывается __eq__ класса, если есть, в противном случае сравниваются всегда уникальные id (это может быть,например, адрес в памяти)
5.  работает в любых классах, где есть функция __contains__
6. есть только с числами. (1.3 + 33) даст верные 34.3.
а вот ("a"+1) даст ошибку, нужно написать "a" + str(1).
тип str(a) вызовет a.__str__(), repr(a) вызовет a.__repr__()

[RXL]

2. Твой пример неверен. Посмотри мой еще раз. Главное - изменение и доступность нового значения через ранее полученные ссылки.

4. Не о том, но расцениваю как "да"

5. Пока мне до этого читать и читать. Книга мне уже не нравится. т.к. столько воды, что начинаю читать по диагонали и могу пропустить что-то полезное.

6. Понятно. В общем-то, это верное решение.

Новые вопросы:

7. Можно ли разбивать выражение на несколько строк?

a = b + c
  + d + e

8. Есть ли какие-либо ограничители для команд? Мне их не хватает. Создается ощущение, что работаешь с VB.

9. Константы True, False и None чувствительны к регистру написания? Неудобно писать их в большой буквы. Опять ощущение VB.


Добавлено через 12 минут и 14 секунд:
10. Книга пока не осветила вопросы отступов. Будут ли идентичны следующие отступы?

# "." - пробел, "t------" - табуляция.

Код:

............# 12 пробелов
t---t---t---# 3 табуляции (из расчета по 4 позиции)
t-------....# 1 табуляция (из расчета по 8 позиций) и 4 пробела
...t----....# 3 + табуляция + 4

Вопрос важный, т.к. разные редакторы работают по разному.

[npak]

Рома, по поводу ссылок на встроенные типы - а где это иначе? В Java, Javascript, PHP - при присваивании переменной или поля объекта, содержащего примитивный тип, значение копируется.

[RXL]

Коль, вот тебе пример из PHP.

Код:

<?php

$a = 1;
$b = &$a;
$a = 2;

echo "$a, $b\n"
# 2, 2

?>

именно это я имел ввиду - создание ссылок на изменяемое значение.
Тоже самое в Perl. Насчет JS - там нет таких ссылок.

[Dimka]

RXL, как-то не очень понятна суть проблемы. Понятно, что в том же Perl есть синтаксические правила обращения к сложному объекту по ссылке, но в то же время непонятен смысл ссылки на значение простого типа - его копирование не дороже копирования ссылки.

И различается это как-то даже интуитивно:

Код: (Javascript)

// Копирование значений
var a = 1;
var b = a;
a = 2;
WScript.Echo(String(a) + ", " + String(b));

// Работа со ссылками
var a = {x: 1};
var b = a;
b.x = 2;
WScript.Echo(String(a.x) + ", " + String(b.x));

>cscript test.js
Сервер сценариев Windows (Microsoft R) версия 5.8
c Корпорация Майкрософт (Microsoft Corp.), 1996-2001. Все права защищены.

2, 1
2, 2

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

[RXL]

Дим, я просто пытаюсь выяснить, есть ли подобная возможность в Питоне. В Перле можно ссылаться на что угодно - даже на скаляр. В и PHP можно, и в C++ можно.
Практическая сторона, к примеру - передача скаляра по ссылке в функцию.

[Sla]

8. Есть ли какие-либо ограничители для команд? Мне их не хватает. Создается ощущение, что работаешь с VB.

Код:

hello = "This is a rather long string containing\n\
several lines of text just as you would do in C.\n\
    Note that whitespace at the beginning of the line is\
 significant."

print hello

Добавлено через 31 минуту и 48 секунд:
а вот прикольный примерчик

Код:

hello = r"This is a rather long string containing\n\
several lines of text much as you would do in C."

print hello

Обрати внимание на r


Добавлено через 5 минут и 35 секунд:
интересен доступ к строке

word = 'Help'
word[3]
'p'
word[0:2]
'He'
word[2:4]
'lp'


'<' + word*5 + '>'
<HelpHelpHelpHelpHelp>'




Добавлено через 23 минуты и 55 секунд:
в этом месте меня клинит

word[0] = 'x'

Ошибка...
Т.е. получается что word[0] - это функция, а не элемент строки.








Добавлено через 18 минут и 43 секунды:
не люблю такие конструкции

Код:

a, b = 0, 1 # здесь еще можно согласиться
while b < 10:
     print b
     a, b = b, a+b  # здесь - никогда.

Кстати, можно несколько операторов на одной строке?
где  показанном коде конец ограничитель цикла? Пустая строка?

[RXL]

в этом месте меня клинит

word[0] = 'x'

Ошибка...
Т.е. получается что word[0] - это функция, а не элемент строки.

Просто строка неизменная. Можно склеить из частей:

word = 'x' + word[1:]


Добавлено через 3 минуты и 25 секунд:

не люблю такие конструкции

Код:

a, b = 0, 1 # здесь еще можно согласиться
while b < 10:
     print b
     a, b = b, a+b  # здесь - никогда.

Кстати, можно несколько операторов на одной строке?
где  показанном коде конец ограничитель цикла? Пустая строка?

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

Ограничителем блока (цикла) будет другой отступ. Такая вот хрень. По этому меня очень интересует вопрос 10.


Добавлено через 1 минуту и 46 секунд:

Код:

hello = r"This is a rather long string containing\n\
several lines of text much as you would do in C."

print hello

Обрати внимание на r

В чем фишка?

[Вад]

интересен доступ к строке

word = 'Help'
word[3]
'p'
word[0:2]
'He'
word[2:4]
'lp'

>>> word[-4:-1]
'Hel'

[Sla]

да с отрицательными "индексами" интересно - почитал

но я в ступоре

Код:

      if c < self.base:
         c = self.base
      if d < self.base:
         d = self.base
      if n < self.base:
         n = self.base
      if c > self.top:
         c = self.top
      if d > self.top:
         d = self.top
      if n > self.top:
         n = self.top
      self.c = c

Где здесь концы блоков if?

[Вад]

Где здесь концы блоков if?

Должны быть согласно отступа. Отступ одинаковый - if-ы на одной глубине, отступ больше - if вложенный.

[Dimka]

Дим, я просто пытаюсь выяснить, есть ли подобная возможность в Питоне.

Так вот мне и стала любопытна причина такого интереса. Я бы именно этой возможностью заинтересовался в последнюю очередь, а может быть никогда бы не заинтересовался.

Практическая сторона, к примеру - передача скаляра по ссылке в функцию.

Очень редко сталкиваюсь.

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

Где здесь концы блоков if?

Полагаю, нужно считать отступы

[Sla]

считать отступы... Взрыв мозга

\tif  :
\t\t...
_______________...

Где конец блока?

________if :
__________...
_________...

Где конец блока?


зы читаю вот это

[npak]

Код:

a, b = 0, 1 # здесь еще можно согласиться
while b < 10:
     print b
     a, b = b, a+b  # здесь - никогда.

Кстати, можно несколько операторов на одной строке?
где  показанном коде конец ограничитель цикла? Пустая строка?

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

[Sla]

Ткните ссылкой на синтаксис языка.

про отступы понятно интуитивно

[npak]

Sla, не уверено, что "интуитивно", зато исчерпывающе:
http://docs.python.org/reference/lexical_analysis.html

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

Код:

if 1900 < year < 2100 and 1 <= month <= 12 \
   and 1 <= day <= 31 and 0 <= hour < 24 \
   and 0 <= minute < 60 and 0 <= second < 60:   # Looks like a valid date
        return 1

Табуляция разворачивается в пробелы таким образом, чтобы длина отступа была кратна 8. То есть
\t\t - развернутся в 16 пробелов
___\t (три пробела и табуляция) - развернутся в восемь пробелов

Пустые строки игнорируются

[npak]

Где конец блока?

________if :
__________...
_________...

Где конец блока?

В примере с if отступы сформатированы неправильно. отступ последней строки не соответствует ни отступу if, ни отступу предыдущей строки. Поэтому интерпретатор питона на такой текст сругается: IndentationError: unindent does not match any outer indentation level

[npak]

Так, с индентацией вроде разобрались

Теперь про ссылки. Ссылок (в смысле PHP и С++) в питоне нет. в этом он ближе к Java. Как написал Арсений, выражения a.x = 0 лучше рассматривать как аналог Сишных поинтеров:

Код:

*(a->x) = 0

Пример RXL переписывается на "Си" так:

Код:

/ *obj.x = 1
a = obj.x
obj.x = 2 */
some_class * obj = /* какой-то объект */;
/* тип obj->x - УКАЗАТЕЛЬ на значение, а не само значение! */
object * a; /* тип переменной - УКАЗАТЕЛЬ на значение, а не само значение */
*(obj->x) = 1;
*a = *(obj->x);
*(obj->x) = 2

Вполне логично, что после повторного присваивания obj.x его значение будет отличаться от сохраненного в переменной а. Разумеется, эта Си-подобная метафора не показывает всей правды - для встроенных типов может быть предусмотрена более эффективная схема хранения, но в общем случае она работает.

Поэтому для того, чтобы передать в функцию ссылку на число, нужно передавать туда объект, в котором число будет полем. Например

Код:

class NumRef:
    ref = 0
    def __init__(self, x): self.ref = x;

Тогда можно реализовать Си++-шную идиому, когда основное значение возвращается из функции, а дополнительные - через ссылки:

Код:

// C++
char * read(int& count) { /* число прочитанных символов передается через size */ }
#Python
def read(sizeRef): 
    # что-то делаем
    sizeRef.ref = size
    return buf

Но в питоне специально для этого придумали возвращать тьюплы (tuple) - можно вернуть несколько значений пачкой:

Код:

def read():
    # что-то делаем
    return buf, size

res,size = read()

Следовательно, нет необходимости передавать что-то по ссылке. Необходимое значение можно передать либо как поле объекта-параметра, либо в тьюпле

[.]

неизменность внутренних объектов - есть неизменность внутреннего содержания объектов. мой пример верен.
то есть если
>>> a = 'hello'
>>> a.replace('l','b')
'hebbo'
>>> a
'hello'

[RXL]

Вот - потенциальная проблема при работе с виндовыми редакторами, интерпретирующими табуляцию не по кратной 8 позиции.

Добавлено через 10 минут и 46 секунд:
npak, Арсений(TjSoft), в общем, понятно.

[.]

я использую настроенный vim
"чисто питоновских" редакторов очень много. См. страничку на python.org

[Sla]

я так понял, что инструкций switch и case не существует
есть
if :
elif :

[RXL]

Арсений, наверно я все же не буду изменять своим привычкам ради одного языка: cedit в Linux и nodepad++ в винде. Оба редактора вполне адекватны. Опасность неправильных табуляций больше в совместной работе, чем в одиночной.

Добавлено через 1 минуту и 3 секунды:
Слава, да, таких ключевых слов нет. Собственно, я так понимаю, все на if делается.

Добавлено через 1 минуту и 30 секунд:

Switch statements in Python

Python doesn’t support a native switch statement. I’ve found myself using the following coding idiom instead recently which seems to work pretty well:

{'option1': function1,
 'option2': function2,
 'option3': function3,
 'option4': function4}[value]()

This works with lambdas as well, for inline calculations. Here’s a switch statement that assigns to a variable in PHP:

switch ($value) {
    case 'a':
        $result = $x * 5;
        break;
    case 'b':
        $result = $x + 7;
        break;
    case 'c':
        $result = $x - 2;
        break;
}

And here’s the equivalent code in Python:

result = {
  'a': lambda x: x * 5,
  'b': lambda x: x + 7,
  'c': lambda x: x - 2
}[value](x)

Через массив лямбда-функций. Прочие значения отлавливать через exeception?

Добавлено через 9 минут и 47 секунд:
Кстати, не трудно догадаться, почему в Питоне нет switch-case: все дело в тех же отступах - сложно будет определить блок.

Вот обсуждение 2006-2008 годов: http://www.python.org/dev/peps/pep-3103/

[.]

я так понял, что инструкций switch и case не существует

Видимо - пока. хотя особых преимуществ этой конструкции не вижу. if-elif-else - более гибкая

Добавлено через 1 минуту и 7 секунд:
RXL,  и не только через лямбду!

[Dimka]

хотя особых преимуществ этой конструкции не вижу. if-elif-else - более гибкая

Этот вопрос уже обсуждался на форуме. Switch для простых типов может быть преобразован транслятором языка в хэш-таблицу, алгоритмическая сложность выбора элемента из которой равна 1. Цепочка if-elif всегда вычисляется как последовательность условий и переходов, поэтому её алгоримическая сложность равна n.

Это преимущество, которое ты не видишь: таблица функций (опуская затраты на конструирование таблицы) работает быстрее. Особенно актуально в случае программирования сложных автоматов с длинными switch'ами атомарных/скалярных значений.

[RXL]

Пробуя примеры с исключениями наткнулся на ошибку интерпретатора.

 File "./t1.py", line 7
    except EnvironmentError as e:
                             ^
SyntaxError: invalid syntax

Версия имеющего Python - 2.4.3.
Смысла ошибки не понимаю, т.к. в доке на их сайте на нашел упоминания, чтобы конструкция as была введена в какой-то определенной версии языка.

[.]

ты небось доку по 2.7 читаешь?

Добавлено через 1 минуту и 41 секунду:
открываем для 2.4.3 и видим, что никакого as нету
http://docs.python.org/release/2.4.3/ref/try.html#try

[RXL]

Читал это: http://docs.python.org/reference/compound_stmts.html#except
Версия там не указана.

Да-да, на самом верху, в углу написано - 2.7...

Добавлено через 11 минут и 2 секунды:
Честно говоря, такие скачки синтаксиса у языка 20 лет отроду пугают.

[.]

Последние  годы он очень сильно развивается. Особенно благодаря

[npak]

Switch для простых типов может быть преобразован транслятором языка в хэш-таблицу, алгоритмическая сложность выбора элемента из которой равна 1. Цепочка if-elif всегда вычисляется как последовательность условий и переходов, поэтому её алгоримическая сложность равна n.

Верно. Но почему-то создатели скриптовых языков пошли по другому пути. Perl, Javascript, PHP - везде switch вычисляется последовательно, от первого case до последнего.

Это преимущество, которое ты не видишь: таблица функций (опуская затраты на конструирование таблицы) работает быстрее. Особенно актуально в случае программирования сложных автоматов с длинными switch'ами атомарных/скалярных значений.

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


Добавлено через 43 секунды:
RXL, можно подумать, Perl и PHP меньше менялись. В особенности PHP

[RXL]

npak, в Perl switch нету. ВО всяком случае в 5.
Уточнение: появился в 5.10. Я пока использую 5.8

Добавлено через 2 минуты и 36 секунд:
PHP от 3 до 5 поменялся очень мало (а это считай лет 10). Синтаксис существовавших операторов не изменился. Варианты блоков с двоеточием до сих пор работают.

Добавлено через 6 минут и 19 секунд:
Синтаксис Perl5 (начиная с 5.6) не изменился, а это 10 лет.

[npak]

RXL, зато они бурлили и кипели в части объектно-ориентированного программирования. То есть вводились новые фундаментальные концепции.

А в питоне концептуальная база, заложенная в первой версии, сохраняется по сей день. Только "синтаксический сахар" подбавляют.

[RXL]

Однако совместимость осталась.

[npak]

Ну, не знаю. За что мне понравился десять лет назад Питон - за внутреннюю стройность. За это я простил ему прибабахи с синтаксисом.

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

Короче, не понимаю я Перл - Питон понятней и проще. ИМХО, разумеется.

[RXL]

Коль, с Перл надо использовать use strict и сразу станет легче. Язык это не сложный и главное — логичный и однозначный, а значит программу можно контролировать.


Думаю, у меня сишные привычки. Хотя Fortran-подобные языки меня не пугают при всей своей громоздкости, но VB и Python почему-то не пришлись по душе. Стереотипы...

[.]

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

[npak]

Рома, "хум хау"
Это я насчет логичности Перла. Похоже, что не для меня, искалеченного строгой типизацией и формальными методами

[RXL]

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

[.]

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

вопрос договорённости протоколов и хорошего тимлида

[Sla]

видимость переменных

Код:

i =1
def test():
  i +=1

print i
test()
print i

1
1

Почему-то
nonlocal i
             ^
SyntaxError: invalid syntax

global i - прокатило

И где "любимое" i++
Кстати, а почему они посчитали что это плохо?

[.]

i++ не является прозрачно понятной операцией
Если ты помнишь вопросы вроде, что будет выведено на экран:

Код:

void a(int i){return i++;}
int main(){
i = 0;
printf("%d, %d", a(++i++),i);
return 0;
}

Добавлено через 8 минут и 11 секунд:
С видимостью переменных всё хитрее: на чтение видны все, на запись - после объявления.

Код:

>>> a = 0
>>> def test1():
...          print a+1
>>> test1()
1
>>> def test2():
...           a += 1
>>> test2()
Traceback (Most recent call last):
   File <stdin>, line 1 in <module>
   File <stdin>, line 2 in a
UnboundLocalError: local variable 'a' referenced before assignment

[Dimka]

За что мне понравился десять лет назад Питон - за внутреннюю стройность. За это я простил ему прибабахи с синтаксисом.

Любопытно, что именно за отсутствие хорошей теоретической основы (что для меня означает "внутренняя стройность") мне лет 6 назад Python и не понравился. И как раз такое впечатление создали прибабахи с синтаксисом. В смысле синтаксического сахара Ruby на мой взгляд выглядит "стройнее" - нет такого множества правил и специальных методов, а сам синтаксис свободнее.

[RXL]

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

вопрос договорённости протоколов и хорошего тимлида

Эх, твоими бы устами да мед пить... Как говорится, мечтать не вредно. Хорошо еще, если собутыльники коллеги не ленивые — и на том спасибо.

Добавлено через 3 минуты и 4 секунды:

видимость переменных

Код:

i =1
def test():
  i +=1

print i
test()
print i

1
1

Почему-то
nonlocal i
             ^
SyntaxError: invalid syntax

global i - прокатило

Автоматом локальные — хорошая практика. Правда, при написании кода неудобная. Вспомни PHP.

И где "любимое" i++
Кстати, а почему они посчитали что это плохо?

Видимо автор языка не любил Си. Хороший оператор. Не обязательный, но правильный.

Добавлено через 1 минуту и 28 секунд:

i++ не является прозрачно понятной операцией
Если ты помнишь вопросы вроде, что будет выведено на экран:

Код:

void a(int i){return i++;}
int main(){
i = 0;
printf("%d, %d", a(++i++),i);
return 0;
}

Во всех языках есть приоритет операций. Наверно только в Си есть неопределенность результата "++i++".

Добавлено через 1 минуту и 44 секунды:

С видимостью переменных всё хитрее: на чтение видны все, на запись - после объявления.

Опа... Вот это новость! Конечно, это тоже не плохо, но как-то совсем нестандартно.
Разработчики как-то комментировали данный выбор?

Добавлено через 1 минуту и 35 секунд:
Dimka, а выскажись по той же линии о C++, Java, PHP, Perl и JavaScript. Интересно.

[Sla]

RXL, они столько много наговорили о видимости, что я так и не понял

вот здесь

[.]

Dimka, а выскажись по той же линии о C++, Java, PHP, Perl и JavaScript. Интересно.

хе-хе

Добавлено через 4 минуты и 28 секунд:
http://docs.python.org/reference/executionmodel.html#naming-and-binding если быть более точным
для предыдущих версий аналогично  следующему пути в документации: Python v2.7 documentation » The Python Language Reference »  Execution model

[Dimka]

Видимо автор языка не любил Си. Хороший оператор. Не обязательный, но правильный.

Опять мои пять копеек Когда-то я писал i++, потому что "все так пишут". Потом узнал разницу между ++i и i++ - в первом случае происходит простой инкремент, во втором - сначала копируется значение i (в общем случае могущее быть большим и тяжёлым объектом), и только потом происходит инкремент старой копии. Поэтому я стал писать ++i. Однако потом меня захватила идея читабельности кода, и с тех пор мне кажется, что выражение i += 1 более "говорящее", чем ++i Так что вопрос правильности - субъективный, зависит от мотивов

Dimka, а выскажись по той же линии о C++, Java, PHP, Perl и JavaScript. Интересно.

Про PHP мне сказать нечего - я на нём только 3 строчки написал и то давно. Мнения не имею.

Говорить о C++ можно только в контексте C. В стародавние времена 70-х годов, когда переменные были не длиннее 8 символов, нажатие кнопки на клавиатуре терминал отрабатывал десятки миллисекунд, а экран был 30х20 символов или около того, синтаксис с обилием значков, компактных синтаксических конструкций и префиксов у переменных реально ускорял процесс набора кода и повышал читабельность. Сейчас с использованием автогенераторов кода и средств ускорения набора это не актуально. В то же время более "словесный" синтаксис Algol и последующих языков с моей точки зрения выглядит более аккуратным.

Возможность в C/C++ напрямую работать с памятью, чёткое разделение указателей и значений - вещь незаменимая в своём классе задач. В то же время добавление в C++ ссылок на мой взгляд создало элемент неочевидности в коде: в отдельно взятом алгоритме, вызывающем другие функции, нельзя гарантировать сохранность значений переменных - это отдано на откуп программисту - возникает потенциал для ошибок. Математическим идеалом (на практике при работе с железом недостижимым) с моей точки зрения являются stateless вычисления, к которым тяготеет функциональное программирование. Наличие состояний, изменяющихся со временем областей памяти, на которые ведут постоянные ссылки - это всё ослабление инкаспусляции и повышение рисков ошибок, от которых в принципе не может защитить строгая типизиация. Указатель сразу "сигнализирует" о том, что в данном месте используется скорее всего разделяемая в нескольких местах кода область памяти; ссылка же выглядит, как обычная переменная (в традициях структурного подхода локальная), а работает как глобальная переменная со всем из этого вытекающим. Особенно это важно в нынешние времена параллельных вычислений.

Множественное наследование, вытекающее из отстутствия синтаксической конструкции (и тем самым выраженной в языке концепции) interface, на мой взгляд является не очень хорошим атавизмом в C++. Более поздние языки, запрещающие множественное наследование, но разрешающие реализацию множества интерфейсов, в этом вопросе выглядят "стройнее". Почему так - это отдельная тема

Java, если говорить о синтаксисе, язык неплохой, нормально реализующий концепции ООП (для языка со строгой типизацией). Про стиль синтаксиса C-образный или Algol-образный я выше сказал. Pure ООП приводит к громоздкости кода - на всякий чих нужно заводить маленький классик. Однако структура программы, принципы размещения кода по файлам и файлов по пакетам в Java довольно приятные, чем-то похожие на Python. Все эти маленькие классики хорошо инкапсулируются в файлах и не портят общую структуру программы. У Java есть проблемы на уровне виртуальной машины, связанные с оптимизацией и производительностью, поэтому я слышал жалобы на то, что компилятор вынуждает программиста некоторые вещи писать неочевидным способом - это, на мой взгляд, не проблема синтаксиса, поэтому эту часть языка я комментировать не буду. Последние версии в рамках непонятно какой общей тенденции во всех языках добавляют всякий синтаксический сахар для упрощения кода, избавления от маленьких классиков, от излишнего boxing'а простых типов в объекты. Что-то полезное, что-то нет, но по сравнению с вакханалией в C# Java выглядит лучше.

Синтаксис Java, не различающий явным образом переменные ссылок и значений (лишь по типам) и необходимость для некоторых вещей использовать механизм boxing'а (особенно автоматического) вместе с не очень эффективным в данном вопросе компилятором приводят к неочевидному коду, дающему неожиданные для программиста последствия в части производительности. Введение generic-типов в 5-й версии во многом позволяет снизить остроту этой проблемы. Сама идея освободить синтаксис от "лишних" значков, различающих ссылки и значения, скорее всего правильная, но "дырявые абстракции" и неэффективные компиляторы сильно портят преимущества этой идеи. Опять же вылезает то обстоятельство, что нет stateless-вычислений, поэтому именно программист всегда должен помнить, где у него ссылка, а где значение - это важно для операций сравнения, для внесения изменений (нужно копировать перед изменением или нет). При stateless-вычислениях этот вопрос не возникает - в общем случае считается, что всегда происходит копирование (например, такая идея реализована при работе со строками в .NET), а чтобы повысить производительность, достаточно интеллектуальный транслятор языка сам должен определять, что можно не копировать в данном месте, заменив ссылкой и сэкономив память и время исполнения, а что нужно копировать обязательно.

Про Perl я могу говорить лишь осторожно. Я не использовал его богатые библиотеки и не уверен, что знаю многие приёмы программирования на нём. Тем не менее его синтаксис на мой взгляд совершенно невменяемый - не видно никакого центрального стержня, любая фенечка реализуется дополнительной синтаксической конструкцией со всякими префиксами. Сами конструкции тоже не обладают каким-то однообразием, вернее, они однообразно разнообразны - стиль Perl . Инстанцирование модулей (позволяющее реализовать ООП) сама по себе идея неплохая, но на уровне синтаксиса она выливается в некие соглашения о кодировании и наименованиях, что я не приветствую. Если есть какая-то программистская концепция, по-моему она должна выражаться в синтаксисе языка непосредственно, так, чтобы на уровне трансляции сразу было понятно, что программист реализовал, а что забыл. Т.е. применение ключевых слов предпочтительнее, чем применения специально выделенных для этого методов, атрибутов, переменных и т.п. Можно и так сказать: если некая концепция является элементом языка, то нужны ключевые слова и синтаксические конструкции, если же она является элементом библиотеки языка, то, напротив, она должна реализовываться через элементы языка (транслятор не должен о ней знать). Эти два уровня должны чётко различаться, причём первый уровень должен стремиться к минимализму. Можно ввести промежуточный уровень "синтаксического сахара", каждый элемент которого должен иметь понятную реализацию (или макроопределение) через базовые средства языка (как это делается, например, в Ruby). В Perl же (по моим впечатлениям) все эти уровни имеют некую общую пересекающуюся "серую зону", что усложняет транслятор и делает код более запутанным.

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

RXL, зная твою любовь к Perl, я заранее согласен с тем, что моё мнение несправедливо, что Perl, если внимательно посмотреть, стройнее и логичнее, красивее и объектно-ориентированнее, и что я Perl знаю плохо. Но ты спросил - я ответил

Ну что сказать о JavaScript... Чего-то особо выдающегося в плане синтаксиса у этого языка я не вижу. В части производительности - тоже. В части стандартных средств, встроенных типов - тоже. Всё типично для скриптовых языков. Чем кардинально отличается JavaScript (и Lua) от других языков - так это безклассовой версией ООП. Язык, в котором есть объекты, но на уровне синтаксиса нету классов. Благодаря этому синтаксис языка упрощается. В теоретическом плане единственной абстракцией является ассоциативный массив (он же словарь). Функции рассматриваются как данные, поэтому сохраняются в переменных и словарях наравне с прочими данными. И в этом смысле по стройности своей теоретической основы JavaScript и Lua ближе к Lisp, нежели все остальные языки. Конечно, в языке есть синтаксические надстройки, позволяющие пытаться использовать информацию о типах (в случае объектов типом признаётся функция-конструктор), но я не уверен, что это положительное явление. Отсутствие АТД (и классов) приводит к существенному падению производительности исполняемых программ, поскольку на каждый вызов функции через переменную интерпретатор вынужден производить дополнительные проверки корректности вызова, при этом каждый раз не имея информации (обычно определяемой классом или хранящейся как RTTI), что в данном случае подразумевается под тем или иным вызовом. Тем не менее большой проблемой это не видится, так как и сами проверки значительно упрощаются. ООП без классов задействует альтернативные механизмы обобщения и повторного использования кода: наследование классов заменяется делегированием объектов через их прототипы. Тем не менее в JavaScript это делегирование с прототипами несколько однобоко. Прототип определяется у конструктора объекта, и все объекты, созданные одним конструктором, имеют один общий объект-прототип - программист не может простым способом управлять этой привязкой и выбирать между общим прототипом или индивидуальными прототипами для каждого объекта. Общий прототип удобен для создания примесей (к коим, как к концепции, я отношусь скептически), но в общем случае как альтернатива наследованию он чаще всего неудобен. Однако это неудобство несложно обойти, поскольку имеется возможность вызвать цепочку конструкторов для одного объекта (замыкания в памяти) - информация о типе потеряется, но объект унаследует все свойства, которые в нём создали и переопределили всего его конструкторы в порядке их исполнения.

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

[Алексей++]

в первом случае происходит простой инкремент, во втором - сначала копируется значение i (в общем случае могущее быть большим и тяжёлым объектом), и только потом происходит инкремент старой копии

полагаю, что для итераторов и простых типов оптимизатор не будет делать копию для случаев, когда не происходит дальнейшего присвоения
например
for( ; ; it++)
{
}

[.]

Dimka, снимаю шляпу. я не умею так излагать мысли. учусь.