Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: Начал изучать Python. Первые впечатления.  (Прочитано 79050 раз)
0 Пользователей и 1 Гость смотрят эту тему.
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #30 : 01-11-2010 21:13 » 

Switch для простых типов может быть преобразован транслятором языка в хэш-таблицу, алгоритмическая сложность выбора элемента из которой равна 1. Цепочка if-elif всегда вычисляется как последовательность условий и переходов, поэтому её алгоримическая сложность равна n.
Верно. Но почему-то создатели скриптовых языков пошли по другому пути. Perl, Javascript, PHP - везде switch вычисляется последовательно, от первого case до последнего.
Это преимущество, которое ты не видишь: таблица функций (опуская затраты на конструирование таблицы) работает быстрее. Особенно актуально в случае программирования сложных автоматов с длинными switch'ами атомарных/скалярных значений.
Согласен, но это сильно узкая задача. Редко кому из пользователей скриптовых языков приходится писать сложные автоматы. Да и в этом случае явная таблица переходов предпочтительней чем специальная конструкция. Вот и выходит, что ни к чему городить отдельную инструкцию, которая почти не будет использоваться в жизни.


Добавлено через 43 секунды:
RXL, можно подумать, Perl и PHP меньше менялись. В особенности PHP
« Последнее редактирование: 01-11-2010 21:46 от npak » Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #31 : 01-11-2010 21:13 » 

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

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

Добавлено через 6 минут и 19 секунд:
Синтаксис Perl5 (начиная с 5.6) не изменился, а это 10 лет.
« Последнее редактирование: 01-11-2010 21:24 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #32 : 01-11-2010 21:34 » 

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

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

« Последнее редактирование: 01-11-2010 21:41 от npak » Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #33 : 01-11-2010 21:36 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #34 : 01-11-2010 21:44 » 

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

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

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

« Последнее редактирование: 01-11-2010 21:49 от npak » Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #35 : 02-11-2010 04:53 » 

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


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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
.
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #36 : 02-11-2010 07:47 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #37 : 02-11-2010 08:04 » 

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

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #38 : 02-11-2010 08:32 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
.
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #39 : 03-11-2010 13:44 » 

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

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #40 : 03-11-2010 14:53 » 

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

Код:
i =1
def test():
  i +=1

print i
test()
print i

1
1

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

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
.
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #41 : 03-11-2010 15:11 » 

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
« Последнее редактирование: 03-11-2010 15:19 от TJSoft » Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #42 : 03-11-2010 15:29 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #43 : 03-11-2010 20:07 » 

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

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

Добавлено через 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. Интересно.
« Последнее редактирование: 03-11-2010 20:16 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #44 : 03-11-2010 20:18 » 

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

вот здесь
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
.
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #45 : 03-11-2010 22:39 » 

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
« Последнее редактирование: 03-11-2010 22:43 от TJSoft » Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #46 : 04-11-2010 10:02 » 

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

Цитата: RXL
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 динамическая типизации я предпочтений не имею. Каждый способ типизации влечёт за собой свои особенности организации процесса разработки. Если их учитывать, эффективность разработки больших программ на языках с первым и вторым способом типизиации будет примерно одинаковой, просто по-разному будет выстроен производственный процесс.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #47 : 04-11-2010 10:26 » 

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

.
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #48 : 08-11-2010 13:09 » new

Dimka, снимаю шляпу. я не умею так излагать мысли. учусь. Ага
Записан
Страниц: 1 [2]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines