Просто я упомянул то что ты наверное не видел, не понимаешь

Duff's device уже стало rocket science, известной только посвященным?

надо прибегать к аутотренингу и повторять «PHP разъел твой мозг».

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

Буриданову ослу пить и жрать было нечего.

С логикой у тебя тоже всё плохо.

Коллега, вы бы лучше промолчали.

Таки да, порабощать у цивилизованных людей кишка тонка.

Коллега, вы бы лучше не указывали что мне делать.

С логикой у тебя тоже всё плохо.

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

Почитаешь иногда этих спорщиков ruby vs python ... Вроде бы не тупые, но относительно высокий урвень абстракции этих языков заставляет их и мыслить абстрагируясь от физических ограничений и фактов.

Ruby будет в 2-3 раза быстрее и сможет заменить Java потому что тоже объектно ориентирован?

Все эти языки просто интерпретаторы байткода в стековой машине. Это всё изучено и перепробованно на протяжении нескольких десятилетий в ведущих университетах мира.

Одно из немногих существенных различий ruby и python в реализации сборщика мусора. В python это в каждом объекте счётчик ссылок на него, как в библиотеках Delphi(object pascal). В ruby mark'n'sweep, что как раз облегчает написание СИ расширений.

Коллега, вы бы лучше не указывали что мне делать.

Коллега, я не указываю что вам делать, я подсказываю что вам не делать.

У рубистов хорошо с ООП! Но с логикой очень плохо Релиз Ruby 2.1 (комментарий)

Их цивилизованности и сотни лет нет, не мнимо ли, кто бы рассказал.

Коллега, по вашим подсказкам garbage collector плачет.

С логикой у тебя тоже всё плохо.

Нет

Да.

это у вас с гвидо жутко плохо с ооп и таки с английским.

У Гвидо с этим всё в порядке, да и я понимаю, что _метод_ join объекта 'строка' - это не функция join; вполне логично, что метод объекта использует этот объект для объединения элементов списка.

А функция join - это ".join(somelist)

Duff's device уже стало rocket science, известной только посвященным?

Представь себе.

А я вообще обращал внимание как раз на предельную простоту реализации. Это используется во встраиваемой ОС Contiki.

Реализация protothreads это всего несколько небольших файлов. Имея экономный одноядерный процессор можно писать программы уже как многопотоковые, что облегчает задачу описания задач :) управления некоторыми устройствами работающими в автономном режиме.

Не сказать что эта реализация гениальна(хотя кому как), но она простая. Это сочетание и кажется лично мне красотой. В данном конкретном случае.

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

Все эти языки просто интерпретаторы байткода в стековой машине. Это всё изучено и перепробованно на протяжении нескольких десятилетий в ведущих университетах мира.

И какой вывод? Pascal и Ява были интерпретатороми байткода стековой машины, C# на концептуальном уровне - тоже, да тысячи их.

Логика указывает на то что split/join должны быть взаимно обратными операциями. В нормальных языках так и есть. У Ruby это не так...

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

Что логичного, что метод, который во всех вменяемых языках программирования запихнули бы в один класс, гвидо в питоне запихнул в другой?

Купи в магазине вазу, разбей её, склей, и сдай обратно. Когда тебе откажут, попробуй использовать свою логику.

Но ведь есть Perl.

Зачем нужен хаскелль, если есть божественный лиспик?

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

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

join логично делать и методом, и функцией. И прикинь...

>>> import string
>>> string.join
<function join at 0xf74b9614>
>>> string.join(['a', 'b'])
'a b'
>>> string.join(['a', 'b'], sep ='')
'ab'
>>> 

Хочешь - используй метод, хочешь - функцию. В чем претензия-то?

Мы сейчас про языки программирования разговариваем или про вазы?

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

И какой вывод? Pascal и Ява были интерпретатороми байткода стековой машины, C# на концептуальном уровне - тоже, да тысячи их.

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

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

Это видно на примере истории Mono.

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

В чем претензия-то?

А ты чем слушаешь? Ответил совсем не в тему.

Что логичного, что метод, который во всех вменяемых языках программирования запихнули бы в один класс, гвидо в питоне запихнул в другой?

По хорошему метод join должен быть в списке, а не в строке.

Смотри сообщение того анонимуса, если не дошло: Релиз Ruby 2.1 (комментарий)

единственный путь это написание JIT компилятора.

Единственный путь куда и к чему ты вообще клонишь?

Тот же Matsumoto в таком случае полностью теряет контроль над языком.

Что за чушь. Для Явы существует куча интерпретаторов (и JIT), для Lua есть LuaJIT (фактический отдельная реализация интерпретатора), для Python - куча реализаций интерпретаторов (и минимум 1 JIT), и ничего - никто контроля не потерял.

По хорошему метод join должен быть в списке, а не в строке.

Кхм. И в каких языках принято это укуренное решение? Что именно возвращает метод join объекта-списка?

Смотри сообщение того анонимуса, если не дошло: Релиз Ruby 2.1 (комментарий)

Зачем мне Руби-наркомания? Я отвечал на претензии к Python.

Кхм. И в каких языках принято это укуренное решение?

Да примерно во всех языках, кроме упоротого питона, принято обрабатывать объекты в их собственных классах, а не в строке.

И в каких языках принято это укуренное решение?

Да примерно во всех языках

Не стесняйся, называй имена.

Прошу прощения...

... но что-то мне это напомнило Виртовскую работу, Lilith, ЕМНИП она называлась. Навеяло так сказать...

А вот Duff's device штука на мой взгляд вредная. Ибо спагетти-код и затрудняет работу оптимизатора в компиляторе и сводит почти на нет работу предсказателя инструкций. По-моему, у Даффа был слишком большой опыт на ассемблере. С моей точки зрения (я, как и tailgunner программист-системщик, следовательно С-программист), лучше бы импользовать конечные автоматы в их явном представлении. Сложнее накосячить. Возможно, конечные автоматы в неявном представлении (это было использовано в protothreads?) имеют право на жизнь, но на С можно обойтись и без этого. По крайней мере, С позволяет представить состояния и переходы автомата достаточно просто и явно.

Это же избавляет от условных ветвлений связанных с типом параметров. Кроме того, изменения для одного типа объектов однозначно не затронут другие типы. В-третьих я могу создавать еще объекты с методом join и использовать их наряду с теми, для которых этот метод стандартен. Универсальность.

Не стесняйся, называй имена.

Жаба, кресты, шарп - ни в одном ты не найдёшь такой упоротой обработки списков в строке, как в питоне.

Не стесняйся, называй имена.

Жаба, кресты, шарп

Мде.

anonymous> метод join должен быть в списке

Поздравляем вас, гражданин, соврамши. Ни в крестах, ни в яве нет операции join на списках.

написание JIT компилятора. А это очень дорогая рутина

Ололо. Что там такого сложного?

Это же избавляет от условных ветвлений связанных с типом параметров

Что «это», епт?

Кроме того, изменения для одного типа объектов однозначно не затронут другие типы. В-третьих я могу создавать еще объекты с методом join и использовать их наряду с теми, для которых этот метод стандартен. Универсальность.

И к чему ты это написал?

написание JIT компилятора. А это очень дорогая рутина

Ололо.

Много JIT написал? Для каких языков?

Что там такого сложного?

Сложно сделать его эффективным.

Потому, что ты вызываешь метод foo, который возвращает nil.

Да блин...

... есть одна проблемка.

Ололо. Что там такого сложного?

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

Как ни сравнивают, а всё-равно проигрывают по отношению к С. Может, JIT это что-то навроде «вечного двигателя»?

Что за чушь. Для Явы существует куча интерпретаторов (и JIT), для Lua есть LuaJIT (фактический отдельная реализация интерпретатора), для Python - куча реализаций интерпретаторов (и минимум 1 JIT), и ничего - никто контроля не потерял.

Единственная полноценная реализация от Sun/Oracle. Я использую Netbeans. Куча реализаций Python кроме Jython мне неизвестны. То есть легко найти, но зачем они мне нужны? Играться ними как аутист?

Luajit лучший пример. Это реализация одного очень умного человека из Германии, и всё на нём. Работает в университете насколько помню. Сам язык Lua четко знает свою нишу. Только в паре с СИ.

А за JIT в Java и javascript V8(ещё некоторые малоизвестные языки) стоит один датчанин который всю жизнь работал над виртуальными машинами с JIT компиляцией. Он и разрaбатывал HotSpot.

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

А плохие JIT не нужны, сделай удобным интерфейс к СИ, и это будет на порядок лучше и полезнее.

Что «это», епт?

Вызов метода из объекта, епт.

И к чему ты это написал?

К использованию. Предположим я хочу повесить хук на join хэша и только хэша (банально для отладки), в данном случае я столкнусь с трудностями. И предположим я хочу, чтобы универсальный метод string.join обрабатывал объекты MySuperClass, и я вновь сталкиваюсь с трудностями.. не так ли?

Единственная полноценная реализация от Sun/Oracle. Я использую Netbeans. Куча реализаций Python кроме Jython мне неизвестны.

Я так и не понял, к чему ты вел, но расспрашивать надоело.

anonymous> метод join должен быть в списке
Поздравляем вас, гражданин, соврамши. Ни в крестах, ни в яве нет операции join на списках.

Ты опять передёргиваешь. Метод join в списке есть например в руби и похорошему должен там же быть в питоне.

В жабе, крестах и шарпе нет такого бардака с типами, поэтому и метода такого в списках нет.

Но, раз ты забыл я тебе напомню, мы обсуждаем упоротый питон. Иди обойди ещё раз жабу, кресты и шарп и посмотри все методы доступные на объекте строки. Все они относятся к данной строке, а не к левым объектам, как в упоротом питоне.

Вызов метода из объекта, епт.

В том же Ruby у строки нет метода join. И что?

Предположим я хочу повесить хук на join хэша и только хэша (банально для отладки), в данном случае я столкнусь с трудностями. И предположим я хочу, чтобы универсальный метод string.join обрабатывал объекты MySuperClass, и я вновь сталкиваюсь с трудностями.. не так ли?

Пока ты не перечислил проблем - не так.

В жабе, крестах и шарпе нет такого бардака с типами, поэтому и метода такого в списках нет.

Примеры привел ты. Зачем - х тебя з.

Но, раз ты забыл я тебе напомню, мы обсуждаем упоротый питон.

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

Иди обойди ещё раз жабу, кресты и шарп и посмотри все методы доступные на объекте строки. Все они относятся к данной строке

А метод join в Python не относится к данной строке? Да ты упоротый.

Я использую php с symfony, composer. Это идеально для WEB, узкая ниша.

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

С моей точки зрения JIT и даже СИ расширения в скриптовых языках не очень полезны. Даже Lua это ерунда...

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

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

Примеры привел ты. Зачем - х тебя з.

Чтоб ты туда заглянул и понял упоротость питона. Когда до тебя это не допёрло, я даже написал «Иди обойди ещё раз жабу, кресты и шарп и посмотри все методы доступные на объекте строки.» А ты опять хз, да хз. Ты безнадёжен.

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

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

А метод join в Python не относится к данной строке? Да ты упоротый.

Это ты с гвидо упоротый. Что следующее? Наверное «lol».widgetwithtitle(), оно же относится к данной строке.

В том же Ruby у строки нет метода join. И что?

Причем здесь это? Я говорю о том, что string.join будет проверять тип подставленного объекта и выполнять соответствующий фрагмент кода. А [].join содержит только код склеивания объектов своего типа, без ветвлений.

Пока ты не перечислил проблем

' '.join(MySuperClass()) вернул TypeError, как мне научить join работать с моим классом, это вообще возможно?

Ты безнадёжен.
Ты опять передёргиваешь.
ты с гвидо упоротый.

Good, good.

Good, good.

Ты не ответил на вопрос.

Все пытаются придать эмоциональную окраску тому с чем работают. To python упорот, то ruby тормозит..

Мол, ruby это драгоценный камень, python это рептилия во всех проектах(хотя изначально совсем не так).

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

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

А недовольство форматированием отступами в python, это какие-то случаи шизофрении.