Использование $ перед именем переменной это наследие начала 90-х от perl и shell, атавизм

Сам ты атавизм. Повтори-ка на питоне:

set a b
set $a c
puts $b

Думаю, что уже ответил тебе предыдущим постом. Можно добавить еще:

set a if
$a 1 {puts true} {puts false}

Ну и где теперь твой питон?

set a if
$a 1 {puts true} {puts false}

а нахрена это нужно? Ты всегда так программируешь? а #define true false не делаешь?

set a b
set $a c
puts $b

^^^ что это делает?

Ну и где теперь твой питон?

В продакшене.

set $a 10 при а=15 раскроется как set 15 10, что смысла не имеет.

> что это делает?

Присваивает а строку 'b', затем значению строки a (т.е. b) присваивает с. Последний оператор выведет значение c.

Короче это такой хитровывернутый вариант указателя, которые в нормальных ЯВУ не нужны.

> что это делает?

Упс, не угадал :3

Оно просто выводит строку 'c'.

Оно просто выводит строку 'c'.

Спасибо, идею понял. Я с тобой полностью согласен по поводу важности и нужности этой фичи.

Повтори-ка на питоне

Никаких сложностей, из коробки такое есть. В питоне ты владеешь не объектами а ссылками на объект. Для некоторых built-in типов(типа str и int) есть особый behavior(документировано, почему так сделано очевидно), их оборачиваешь в singleton и всё.

>Та реализация что я тебе показывал с HTTPServer значительно продвинутей, она использует greenlets и позволяет писать приложения не заботясь о том что «тут чтение из сокета заблокирует, а тут запрос в БД повиснуть может» итд итп.

Я тебе привел примеры программ сохраняющих работоспособность 5 ...10 лет, а твои «питонопонты» не факт, что будут работать на следующей версии питона.

Поменять синтаксис: покажи примеры, я в гугле не нахожу ничего такого.

уже влом, ищи сам ...

Хотя это не изменит моё мнение о синтаксисе тикля.

Возможно. Ну, может выкрикивать глупости про tcl будет как-то зазорно, не ?

Использование $ перед именем переменной это наследие начала 90-х от perl и shell, атавизм.

Атавизм - это табы со времен 70-x от фортрана, кстати от табов в фортране уже отказались. И никто на стенку не лез защищать там этот маразм.

Можно нескромный вопрос? Ты действительно не любишь питон и любишь и программируешь на тикле или ты просто развлекаешься на лоре?

Да, можно и так сказать сказать - я не люблю питон
1. из-за нахальных и заносчивых его пользователей , что-то там вечно закапывающих.

2. нестабильности и плохой обратной совместимости.
3. плохого общего дизайна
И собственно, большая ошибка была тащить питон в гном.

Есть greenlets для tcl? Monkey patching tcl умеет?

Ты решил, что я буду изучать всю лабуду из названий к костылям у питона ?
Кстати, это тоже бесит.
Хватит, что посмотрел PyCherry - разговоров
полные штаны о нем, как что-то невероятное , а оказывается звучное название очередного полуфабриката. Даже книжечку настрочили об этом.
Иногда мне кажется , что появление пистона это как заговор технических писателей.
Он должен быть убог и ущербен от рождения . Вот тогда класс, куча работы для всех остальных.
Все будут что-то дописывать, описывать дописанное, обсуждать как правильно его прикрутить и какая метода лучше ...
Преписывать вновь «таблицу умножения», разумеется сей подвиг должен
быть назван звучно, не хуже как «Амонтильядо» , что-бы можно было щеголять названиями.))

> Повтори-ка на питоне:

exec(«%s=%s», a, c)

Еще примеры могучего метапрограммирования будут?

> $a 1 {puts true} {puts false}

А какую важную функцию выполняет этот оператор?

опять на круги своя вернулось. Вот, между прочим, несовместимость у тикля отнють не фонтан. Я даже сам с этим сталкивался ставил конкретные версии тикля согласно ТЗ клиентов(сам ковырялся с http://chat.spb.ru/ когда сисадмином работал на хостинге).

И все остальные твои доводы стоят того же, ты продолжаешь твердить одно и то же. Хотя нет, теперь пошли некие разговоры о «нестабильности» и «дизайна». Я тебе не буду больше писать, потому что ты конструктивно говорить не хочешь и я не верю в твой профессионализм чтобы рассуждать о дизайне ЯП вообще и питона в частности.

между прочим, greenlets это паттерн программирования такой, а все эти aio с колбэками что ты привёл в тикле и сокетами это прошлый век. Побольше бы таких «костылей»...

> опять на круги своя вернулось. Вот, между прочим, несовместимость у тикля отнють не фонтан. Я даже сам с этим сталкивался ставил конкретные версии тикля согласно ТЗ клиентов(сам ковырялся с http://chat.spb.ru/ когда сисадмином работал на хостинге).


трындеж, свиздеж и провокация

все из софта и на чистом tcl работает на новых версиях tcl.

И все остальные твои доводы стоят того же, ты продолжаешь твердить одно и то же.

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

между прочим, greenlets это паттерн программирования такой, а все эти aio с колбэками что ты привёл в тикле и сокетами это прошлый век.

Дооо ...

Побольше бы таких «костылей»...

))

> Я тебе не буду больше писать, потому что ты конструктивно говорить не хочешь и я не верю в твой профессионализм чтобы рассуждать о дизайне ЯП вообще и питона в частности.

Ты чем-то уже tia напоминаешь. Его хлебом не корми , а дай посюсюкать о хорошем пистоне.

ни слова о «хорошем питоне» не говорил. Я за объективность. Если будет средство лучше я пересяду на него. Я готов и дальше обсуждать, но только в объективном ключе. А когда сводится к тому что «мне отступы не нравятся, а вот $ перед переменными это круто»... Ну ты понел.

> Вы просто не осилили даже что-нибудь простейшее, что не императивное программирование.

А ты уже прошел процесс инициации в клуб улитных программистов - написал свой туториал по монадам? Или хотя бы читал сырцы библиотек из хэкеджа или руки дошли только до фибоначиевского хеллоуворда? Если читал, то, очевидно, видел, Data.Monad, Data.Monad.Control, Data.Monad.Applicative, Data.Typeable и тд и тп практически везде. Чтобы читать, писать или менять программы на хаскелле, нужно понимать что это такое - надо лезть в учебники по теоркату или хотя бы вику. Потом встретятся «***» «&&&» и множество других забавных математических абстракций. И все это нужно понимать хотя бы на начальном уровне, чтобы, например, воспользоваться простенькой библиотекой вроде hs-twitter или hjscript. Использование аналогичных библиотек на других языках (том же python и cl) - подобных глубоких знаний матана не требует, т.е. эти абстракции - это привнесенная в программу сложность, а не системная (в терминологии брукса). И это мешает рассуждать о проблеме, оно замусоривает программу ненужными, лишними языковыми абстракциями, отвлекает от конкретно решения задачи в ее терминах. Посчитать студентов в аудитории с помощью теоретико-множественного определения натурального числа и действий над ним - вот так поступает настоящий суровый хаскеллист.

Раньше, чтобы писать программы нужно было знать множество посторонней, не относящейся к сути решаемой проблемы, информации, как-то: в какой регистр писать, где выделять и освобождать память, как представляются числа в двоичном виде, endianess архитектуры, как работать с арифметикой над указателями и тд. Затем стали делать шаги к сведению работы программиста с более естественными абстракциями, чтобы он смог думать над задачей, чтобы уменьшить привнесенную сложность - GC, списки, хэш-таблицы, bignumbers, code reuse, OOP и тд. Мне кажется, что Haskell как раз отбрасывает нас в этом отношении назад, а не двигает вперед - писать (промышленный код) на нем может только человек, знающий достаточно хорошо теоркат и ghci. Вчерашние указатели стали сегодняшними стрелками и моноидами в хаскелле.

Я не спорю, что во всех языках есть то, что нужно знать хорошо - иде, стандартные библиотеки, best practices, что естественные языки в программировании не получатся и не нужны. Я говорю о том, что должен быть баланс между сложностью самого языка и плюшек, которые освоение этой сложности дает. Привнесенная сложность в низкоуровневых языках - дает производительность. А вот сложность haskellя, на мой взгляд, не стоит эфемерных плюсов чистого и математически формализованного фп - возможности оптимизации, автомемоизация, автораспараллеливание, практически идеальная модульность, автоматического доказательства некоторых свойств программы (гарантированное отсутствие дедлоков, например), ну и конечно, это билет в клуб элитных программистов-математиков, одной левой пишущих высоконадежные и невероятно сложные системы, пользуясь монадической и категориальной алхимией.

Справедливости ради — не всё. Помню, в crc32 из tcllib автор использовал свойство переполняемости целых чисел при битовых операциях. Когда на bignum-ы перешли в 8.5, вот было смеху-то.

речь о tcl/tk , а не о tcllib и ее версиях

> все из софта и на чистом tcl работает на новых версиях tcl.

Вот контрпример. Подсказка — tcllib написан на чистом tcl.

Вот: http://tcllib.cvs.sourceforge.net/viewvc/tcllib/tcllib/modules/crc/crc32.tcl?...

До патча на Tcl 8.5 просто зависало при попытке сделать package require crc32

> Я за объективность.

Вы & обьективность ?)) Смешно.
Пока все сводится у вас к каким-то голосовным набросам и «не пробовал, но осуждаю», «А у вас есть такая цацка ? Нет ? - закапывайте»

> Подсказка — tcllib написан на чистом tcl.

4.2 , например md5

Ладно, на самом деле для любителей математики. Но я бы не сказал, что теория категорий /много/ сложнее того же ООП.
(читал немного учебника по теории множеств, узнал и полюбил)

critcl и trf не считаются, благо в tcllib есть и чисто tclьная реализация.

Но в любом случае, речь идёт о чисто Tclьном модуле crc32. Ошибку вовремя исправили, но старая версия до сих пор валяется кое-где.

что-то вы пудрите мозги ))
смотрим:
Tcl/Tk 8.5.0 Release Candidates Mon, 10 Dec 2007 16:49:23 -0500
http://coding.derkeiler.com/Archive/Tcl/comp.lang.tcl/2007-12/msg00315.html

а дата патча tcllib:
revision 1.19 by andreas_kupries, Thu Aug 25 20:47:00 2005 UTC    revision 1.20 by andreas_kupries, Fri Aug 26 16:58:42 2005 UTC

т.е., вы пользовались нестабильной версией tcl 8.5 и теперь еще десять будете рассказывать страшилки .

Э, нет. Читали комментарий к патчу? Там ясно написано: (http://sourceforge.net/tracker/index.php?func=detail&aid=1274120&group_id=128...

Patch also adds int(.) coercion protection to the calculation of signbit to avoid trouble if/when Tcl converts to supporting bignums.

Т.е. пофиксили, имея в виду _потенциальное_ изменение. То, что заранее позаботились о совместимости, делает им честь, но бажная версия до сих пор валяется в виде старкитов.

Ну, от ошибок никто не застрахован, откапывание и устранение чего-то тподобного это нормальный процесс.
А «нестабильность» это таки совсем другое : удаление функций из стандартных либ, явные изменение в самом языке и затрагивающие обратную совместимость...
Понятно, что если вы используете обновляемый linux и видите только одну и самую последнюю версию ЯП и используете только софт из репозиториев , то этих вопросов и проблем можете и не увидеть.
Но, это не означает, что этих вопросов нет вообще и нет их для сторонних программ.

Если же, вздумают сознательно ломать что-то и в tcl ,
исходя из каких-то там благих побуждений и «развития», то я буду и их тоже критиковать. Так как, стоимость существующего софта (и репутации ЯП) уже превышает стоимость самого языка и каких-то иных профитов в виде увеличения быстродействия на 10...20% и компенсируемых естественным ростом вычислительной мощности CPU в индустрии за один год.

Ну такое вряд ли будет в обозримой перспективе, ибо основная тусовка сверхконсервативна.

Давай уже, код показывай.

так почему бы не ввести консистентность

exec(«%s=%s», a, c)

Это у вас такая консистентность? Do not want!

PS:

Python 2.7 (r27:82500, Oct 20 2010, 03:21:03) 
[GCC 4.5.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exec("%s=%s", a, c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

Еще примеры быдлокода будут?

Давай уже, код показывай.

продемонстрировать две ссылки на один объект? :)

class a: pass

b=a
print a
print b

> продемонстрировать две ссылки на один объект?

Нахрена мне твои ссылки, приведенный мною пример делает другое.

Специально для ниасиляторов:

Дано - строка, содержащая название переменной.

Надо - определить переменную с таким именем и присвоить ей произвольное значение (пусть для примера - 42).

лови:

x=10
locals()['x'] = 20
print x

Для объектов это делается ещё проще, без всяких locals()

Доо, locals()['x'] это конечно более консистентно, чем $x.

Python конечно. Lisp нужен только для срачей на ЛОРе.

вижу ты часто обращаешься к переменной зная только её имя. Тогда, конечно, tcl для тебя.

> Lisp нужен только для срачей на ЛОРе.

Однако, некоторые на нём ещё и программы пишут.

Вот да, в отличие от питона, на котором пишут в основном одноразовую скриптоту.

> вижу ты часто обращаешься к переменной зная только её имя

Да. Постой, а тебе для обращения к переменной нужно знать не только ее имя? OH SHI~

я тебя удивлю, в питоне у объектов вообще имён нету. ты мне, наверно, не поверишь...

опять den73 без пароля

Слушайте, а вот такой вопрос.

Я видел какую-то часть исходников VCL от Delphi. Какую-то часть исходников Qt. ООП я не люблю, но ясно, что такие огромные полчища сущностей нужно как-то упорядочивать. Идея распихать их по классам, в нулевом приближении, не выглядит бредовой. Ясно, каковы недостатки VCL: когда он был создан, не было множественного наследования и поэтому «алмазные диаграммы» реализованы убого. Также есть то, что проявляется как недостаток и в VCL, и в Qt. Privacy. Во-первых, privacy ведёт к дублированию кода без добавления функционала. А значит, функционал остаётся убогим, пока силы расходуются на писанину и чтение этой писанины. В итоге всегда оказывается, что именно мне (такому психу) нужны именно private поля и приходится применять хаки или просто копировать большие куски кода. Т.е., православный ООП (инкапсулирование, наследование, полиморфизм) выглядит явно неадекватным.

Скажу ещё, чем мне не нравится CLOS. Тормознутостью и отсутствием того самого синтаксиса instance.member (только не надо мне говорить, что я хочу странного, это не поможет). Если бы ещё не было ограничения на congruent lambda lists, то родовые функции прокатили бы. А так, учитывая то, что в лиспе проблемы ещё и с пр-вами имён, мы оказываемся в раскоряченной ситуации, когда мы хотим использовать две библиотеки с разными сигнатурами родовой функции add, к примеру.

Как же должен выглядить настоящий, правильный, ООП? Даже не ООП, а скорее, как правильно оформить, к примеру, библиотеку GUI видгетов, для которой характерно большое кол-во сущностей с большим количеством атрибутов?

Могут ли более продвинутые товарищи дать какие-то комментарии на эту тему в контексте обсуждения Python vs Lisp vs Haskell vs Tcl?

>Как же должен выглядить настоящий, правильный, ООП?

Smalltalk

Наверное ничего идеального нет
Но можно посоветовать посмотреть на конструкцию виджетов tcl.
В Тк ругают внешний вид под linux, однако связка tcl и tk вне критики.
Ничего более удачнее (и благодоря архитектуре виджетам tcl) пока не придумали.
Также радует что этот стиль стараются сохранить и для gtk в gnocl.

> сли бы ещё не было ограничения на congruent lambda lists, то родовые функции прокатили бы. А так, учитывая то, что в лиспе проблемы ещё и с пр-вами имён, мы оказываемся в раскоряченной ситуации, когда мы хотим использовать две библиотеки с разными сигнатурами родовой функции add, к примеру.

А пользоваться так (foo:add 1 2 3 4) и (bar:add «i» «hate» «lisp» :join " ") религия не позволяет?

> Еще примеры быдлокода будут?

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

И кстати...

Это у вас такая консистентность? Do not want!

Я ничего не говорил про «консистентность». Поздравляем вас, гражданин, соврамши.

den73

> Но можно посоветовать посмотреть на конструкцию виджетов tcl.
Ладно, посмотрю, как будет время. Честно говоря, tk мне не особо нравится. Нужно было прикрутить к лиспу хоть какую-нибудь показывалку результатов sql-запросов, прикрутил tkTable, поскольку это было быстрее всего. В общем, если сравнивать с дельфёвыми компонентами отображения таблиц, то... лучше даже и не сравнивать. Одновременно И слабые возможности И тормозная реализация.

А пользоваться так (foo:add 1 2 3 4) и (bar:add «i» «hate» «lisp» :join " ") религия не позволяет?

Не то, чтобы религия, скорее эстетство. В реальности это выглядит не так красиво, потому что имена пакетов обычно длинные.

Smalltalk

Про его тормоза мне известно ещё по шутауту. А что на нём написано хорошего и большого?

1. tkTable
http://tktable.sourceforge.net/
это самостоятельное сервисное решение и не единственное по это теме.

2. Важна именно реализация с двух концов: gui и яп.

> Не то, чтобы религия, скорее эстетство. В реальности это выглядит не так красиво, потому что имена пакетов обычно длинные.

Мне лично нравится многословие лиспа - длинные и полные имена - сразу понятно о чем речь, и не нравится многословие явы - длинные одинаковые шаблонные конструкции - т.н. паттерны. А 2 add с различной семантикой и одним коротким именем add - это obscure.