Ну print им, видимо, ну уж очень сильно мешал чтоб заменять его на print().

Re^2: Вышел Python 3.0 final

> Зачем он нужен, когда есть tcl?


Это миф

Re^2: Вышел Python 3.0 final

> Похоже, что ты не знаешь хорошо ни java ни vb.

> Дополнительные вопросы лично для тебя.

> Разрабатывал ли ты ПО на заказ? Если да, то какие ощущения были от дальнейшей поддержки твоего продукта?


Я могу разработать робота типа тебя очень просто, вот шаблон:
1. Поиск поста по слову "python" (программа расширяема, в будущем можно дописать в конец массива слова "ruby" и "php", не то что в Java)
2. Ответ фразой: "чем оно лучше Java?"
3. Бесконечно на всё дальнейшее отвечать: "да джава это энтэрпрайз! А вы все дети!"

Но предвещаю судьбу Томми подобному поделию.

>На ушибленного жабой не похожи...

жаба не нужен

руби не нужен

моно не нужен

перл нужен

вала нужен

С нужен

джаваскрипт нужен

лисп нужен

эрланг нужен

> перефразирую доступнее для тебя: почему не было предоставленно неоспоримых и неопровержимых фактов которые бы однозначно поставили точку в вопросе и доказали правоту отрицающих?

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

Чтобы не было приведено в качестве доказательств, всегда нафдется повод для сомнений.

>жаба не нужен
>руби не нужен
>моно не нужен
>перл нужен
>вала нужен
>С нужен
>джаваскрипт нужен
>лисп нужен
>эрланг нужен

Точно, ушибленный...

> IDE LOR 2008 включает в себя...

А почему подсветки синтаксиса нет, и встроенной интерактивной справочной системы? Кстати она поддерживает Python 3.0?

> ...искренне пытяясь разобраться в этом языке. Так и не смог.

Вот я тоже боялся признаться в этом. Каюсь, смалодушничал. Наверное все-таки C++ умрет скоро, нет?

жаба нужен

руби не нужен

моно не нужен

C++ не нужен

вала не нужен

перл нужен

С нужен

Objective C нужен

джаваскрипт не нужен

лисп нужен

эрланг нужен

>>> а за цитирование капчи что, резать перестали?

0) Модеры еще спят, да и нет тут настоящих нормальных и вменяемых модераторов!. 1) Просто в борьбе со спамом дошли до полной нечитабельности капчи. Тому кто там спрограммил - паяльник в ж№пу без права помилования.

А, пистон тоже не нужен. И RMS не нужен.

Завтра можете не выходить!

>> как побелела; как получить я уже и сам понял :)

Запостил в толксах ссылку ну совсем не в тему

>> не, всё равно не буду писать на лиспе, там скобок слишком много :) а я уже подсел на синтаксический сахарок...

вот и меня что-то на сладке поятнуло :)) И RealWorldHaskell как-то воврмея вышла. RWH - это то чего мне не хватало, чтобы присмотрется к хаскелю поближе :))

>>> Завтра можете не выходить!

Типа он у тебя "мальчик выходного дня?"

> Типа он у тебя "мальчик выходного дня?"

Не, он спрятался на машине времени ЛОРа, а теперь застрял, где-то там в прошлом. Но на связь он выйдет, там же скучно.

> Ты упоротый чтоле?! У меня на моей доисторической рухляди разницы между питоном и, скажем, C/C++ на глаз не видно. Только если специально мерять.

Обычный Hello World на PyGTK отожрал 7.5 Mb RSS, а на C - 1.1 mb

> Я, кстати, лет 10 назад купил пачку книжек "для чайников" по С++, честно пытаясь разобраться.

Книжка "С++ для чайников" она всего одна и она зе бест книжка для чайников по С++, ИМХО.

> Именно от нее пошел синтаксис door.getZamok().insertKey(key).turn(key)

Быдлокод! у turn не может быть аргументом key, ибо это безсмысленно! Если перед этим не было insertKey, то turn должен кидать исключение.

А вот turn(left) и turn(right) имеет смысл делать, т.к. тогда замок может открываться и закрываться одним методом. да и не на один оборот, что делает программу гибче и позволит описать больше реальных замков.

> Фокус в том что я питоном практически не пользуюсь, неколько раз писал какуюто фигню для составления представления о языке. И он находится на втором месте после пыхепе по нелогичности и костылявости стандартных библиотек и структуры языка

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

>> Именно от нее пошел синтаксис door.getZamok().insertKey(key).turn(key)

> Быдлокод!

Быдлокод это не поэтому, у замка не может быть метода insertKey.

key(door.getLock()).insertToDoor().turn(key.RIGHT)

>А вот по С/С++ так ни одной понятной не нашлось, хотя покупал я их больше всех, искренне пытяясь разобраться в этом языке. Так и не смог.

Книжки для чайников по cpp только запутывают и не дают ни понимания что это такое ни как в нём работать... самая грамотная книжка, которая встречалась мне по C++ для начального и среднего уровня - это Professional C++ (http://www.amazon.com/Professional-C-Programmer-Nicholas-Solter/dp/0764574841 или russian edition http://www.ozon.ru/context/detail/id/2847443/). Написано очень толково. Рассмотрены основные вещи, но не забыты ни шаблоны ни паттерны.

>9 страниц флейма ни о чем, а ведь мне пистон не нужен...

fixed

> key(door.getLock()).insertToDoor().turn(key.RIGHT)

Ужас.

>> key(door.getLock()).insertToDoor().turn(key.RIGHT)

>Ужас.

Вообще-то с точки зрения ООП именно так проектировать и надо, я бы даже сделал вот так new_door_interactor = door_interactor(key,door.get_lock()) new_door_interactor.insert_key() new_door_opener.turn(direction.right)

сорри, забыл про 2 ентера

new_door_interactor = door_interactor(key,door.get_lock())

new_door_interactor.insert_key()

new_door_opener.turn(direction.right)

> Вообще-то с точки зрения ООП именно так проектировать и надо

Нет. И ещё там у двери не более одного замка, у ключа параметр создания -- замок, бредовые методы и Right вместо Clockwise (и это поля ключа!)

> я бы даже сделал вот так new_door_interactor = door_interactor(key,door.get_lock())

Вот так как раз гораздо лучше. Осталось понять, что замков в двери м.б более одного, и выкинуть ООП :)

>Вот так как раз гораздо лучше. Осталось понять, что замков в двери м.б более одного, и выкинуть ООП :)

Ну в задаче и не говорилось про несколько замков. Была задача - открыть дверь с замком.

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

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

ЗЫ А если не ООП, то что?

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

Кароче если хочешь универсальности - придется описать все)) но зато если это сделаешь правильно, то пр добавлении замка к двери или при добавлении нового типа замка никаких проблем не возникнет, в отличие от структурного програмирования

>у ключа параметр создания -- замок

а это простите зачем? замок является частью двери, неотъемлемой частью, а вот ключ - не зависит от замка, чисто теоретичеески может подойти ключ и от другого замка, главное, чтоб он по типу был такой же(личинковый, сувальный), да и можно вместо ключа подсунуть отмычку ))

> вау. Какое достижение - наконец-то сподобиться к 2008-му на юникод

Адьёт. Уникод там есть с махровых времён, просто для обратной совместимости с обычными строками в отдельном типе.

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

Старая мантра ООП. А потом выясняется, что ООП-моделировать вообще было нечего и незачем, потому что на самом деле это была задача на конкретные embended-замок в виде КА.

(open-door key ((lock 1 (right)) (lock 2 (left right)) (lock 3 (left left left)))) ?

(open-door ((lock 1 (key 1) (right)) (lock 2 (key 1) (left right)) (lock 3 (key 1) (left left left)))) ключи-то мабыть, разные :)

>(open-door ((lock 1 (key 1) (right)) (lock 2 (key 1) (left right)) (lock 3 (key 1) (left left left))))

а если у дверки еще и цепочечка?

>Старая мантра ООП. А потом выясняется, что ООП-моделировать вообще было нечего и незачем, потому что на самом деле это была задача на конкретные embended-замок в виде КА.

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

>Старая мантра ООП. А потом выясняется, что ООП-моделировать вообще было нечего и незачем, потому что на самом деле это была задача на конкретные embended-замок в виде КА.

кстати, а что такое embended?

(door-open-close ((lock 1 (key 1) (right)) (lock 2 (key 1) (left right)) (lock 3 (key 2) (left left left))) (chain-open-close (chain 1 open) (chain 2 open)))

ы?

"Духовно неразвитые" - это и есть невежественные и тупые.

> Молодой человек, когда вы проработаете программистом хотя бы 11 лет, тогда, может быть, и вы поймете, что программистам плятят не за базовые понятия и не за теорию "в общем", а за сделанную в срок и качественно _конкретную_ работу. Как сказал в свое время Райкин, "забудьте про индукцию и дедукцию, давайте продукцию"...

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

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

> И теперь посмотрите в какой мы клоаке по инновациям по сравнению, к примеру, с практичными и пресловутыми американцами.

Дурак. Сравни объём базовых знаний, которые в CMU и в MIT дают, с теми крохами, которые перепадают нашим. А потом уж выступай.

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

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

> а что тут непонятного то? "just for fun" прочитай, может поймешь, если возраст да опыт позволят

Ну вот, в ответ на откровенную быдлятину - не многим более интеллигентный ответ. Стыдно.

По этой теме надо читать Жида, Сартра, Камю, Кьеркегора и Достоевского, и уж только потом - "Just For Fun".

>Про склад ума - миф.

Не миф, а объективная реальность.

> Однако, я, как и множество людей (находящихся в теме) с которыми я говорил, далеко не уверены в том что высадка на Луну американей таки состоялась.

Говноклоун из быдлоМАИ продолжает жечь. После смачного выперда про 150 килобайт весёлых мотивирующих лекций он ударился в пидарусский быдлопатриотизм антиамериканско-безмозглого уклона. Ну да что от такой ничтожной скотины ожидать?

> Не миф, а объективная реальность.

Много ты о реальности знаешь. Я вот точно скажу - не в двадцать с херком лет судить о своём складе ума, потому как через десять лет всё равно взгляды придётся кардинально пересмотреть, в свете нового опыта. Кроме того, я ещё не встречал тех, кто не способен при желании научиться всем этим нехитрым делам. А уж чтобы интеллектуал умудрялся не находить удовольствие в интеллектоёмких задачах (а таких в бизнесе большинство) - такого точно не бывает.

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

Не-лузер отличается от лузера тем, что в любой ситуации не ноет, а извлекает максимум из возможного. Посмотри вокруг - дачки то трёхэтажные народ и в твоей провинции себе понастроил, не так ли? Они что, из какого-то другого сорта мяса сделаны?

> Кароче если хочешь универсальности - придется описать все)) но зато если это сделаешь правильно, то пр добавлении замка к двери или при добавлении нового типа замка никаких проблем не возникнет, в отличие от структурного програмирования

Ключевая фраза - "если сделаешь правильно". На деле же правильно спроектировать онтологию классов не так просто, особенно если понятия предметной области не очень то вписываются в рамки OOD. На ЛОРе периодически мелькают примеры, показывающие как трудно моделировать объекты реального мира в терминах ООП. Вспомните тот же чайник, или вот этот пример с дверью и замком. Только с третьего раза удалось получить что то более менее вразумительное. И это для элементарнейшей модели! Причём сразу стало ясно, что без внушительной иерархии не обойтись, иначе преимуществ ООП здесь вообще не видно.

Ну уж не тебе, такому невежественному и тупому, говорить что-то там о "не-специалистах". Ты же вообще дремучее говно, ты не знаешь абсолютно ничего (собственно, так и должно быть, в этом быдятнике МАИ ничему и не могут научить).

> А, вот даже как? Надеюсь это всё были пилотируемые полёты о коих мы сейчас говорим? Ну что-ж готов признать свою некомпетентность, при условии предоставления грамотного пруфлинка. Жду.

Ты на редкость дремучий. Подтверждаешь одним своим существованием все студенческие байки про МАИ.

>Ключевая фраза - "если сделаешь правильно". На деле же правильно спроектировать онтологию классов не так просто, особенно если понятия предметной области не очень то вписываются в рамки OOD. На ЛОРе периодически мелькают примеры, показывающие как трудно моделировать объекты реального мира в терминах ООП. Вспомните тот же чайник, или вот этот пример с дверью и замком. Только с третьего раза удалось получить что то более менее вразумительное. И это для элементарнейшей модели! Причём сразу стало ясно, что без внушительной иерархии не обойтись, иначе преимуществ ООП здесь вообще не видно.

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

ЗЫ. к тому же про ключ был не пример ООП, а просто пример синтаксиса, это просто кому-то не понравилось, что там криво написано