> Ну да, и знатно садиться в лужу. Все как всегда.

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

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

Если тебе хочется веселить публику - зачем мешать?

> Т.е. та же nuitka умеет уже только сильно урезанный диалект?
> Ну окай. ЧуЙствуется очередной Эксперт.

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

> О, хоть один из анонимов соизволил наконец прочитать мое первое сообщение и
> пересказать его мне же, своими словами? Гениально! Так держать!

Да вы там всей толпой наспамили километр.

> Т.е. все же толк (о чем, как бы, и была речь) от них есть?

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

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

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

> вы осознали хорошо, а теперь, главный вопрос: что насчет возможностей? Можно
> так делать в Си или нельзя? Ведь там нет ИИ!

ИИ требуется для того чтобы привести динамические типы в статические без выполнения кучи проверок в рантайме (интерпретатор в качестве решения проблемы - еще тяжеловеснее).

Чтобы сложить 2 и 3 как эффективное "add r1, r2" - надо быть уверенным что r1 и r2 остаются именно integer'ами, и не превращаются, например, в строку. В этом месте Тюринг дает пендаль: чтобы получить эту уверенность путем предвычислений во время сборки, без кучи проверок в рантайме, надо быть AI. Сишникам с их типами (которые вообще фэйк) Тюринг тоже порой икается, по поводу чего есть "register", "volatile" и т.п..

> Все в лучших традициях анонима )

Да ты фигачь все массивами, посмотришь что получится.

> Вообще, это был намек в сторону "появления новых типов". А то, если
> послушать анонимов, оные прям из ниоткуда берутся.

Откуда бы они ни брались, это подразумевает ряд действий. В рантайме. Т.е. замедление этого куска кода по сравнению с тривиальным add r1, r2, априори в разы.

> И, как мы видим – вполне сработало, анонимы один за другим упорно лажались )

Ты тоже хорош, предложил какой-то дурацкий способ и доволен по уши.

> Благо, как уже упоминалось раннее, пройти мимо "guard"-ов  очень таки сложно.

Вот ежкин кот. Я сказал про проверки. Guard насколько я понимаю частный случай и есть. Тебя не смущает что это будут какие-то дополнительные действия, далекие от add r1, r2 для тех же integer'ов?

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

Так ты покажи где в этой логике промах?

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

По-моему я довольно фундаментальную проблему озвучил, какое-то следствие из Тюринга. Заранее просчитать в build time все варианты изменения типов в динамических ЯП невозможно. А рантайм-проверки - можно, но они замедляют выполнение, однако. С точки зрения оптимизации, предвычисление в build time гораздо лучше чем вычисления в run time.

> guardы оказывается входят в более общее понятие "проверки типов".

А что, не входят?

...
> Что, анонимы совсем отчаялись и пытаются использовать любой призрачный шанс? =)

Если оппонент затупляет - что ж поделать.

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

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

> включение в «более общее понятие 'проверки типов'» вообще-то отдает очередной,
> сугубо личной верованием^W терминологией очередного анонима.

Не к чему докопаться - займись буквоедством? Можешь еще орфографические ошибки поискать, дарю идею.

> Так что, увы, очередная попытка спрыгнуть не удалась и вы опять расслабляетесь
> в лечебной грязи =)

Ты на этом так переклинен что это уже напоминает синдром утенка, чтоли.

> Давайте давайте, переводите стрелки, авось и получится разок )

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

> То, что конкретный jit чего-то не может, как бы вообще не показатель.

Это не "конкретный jit" а некий constraint: чем более качественный код мы хотим получить, тем больше времени надо потратить на анализ. Не уверен что есть строгая теория доказывающая это, но на практике вот так. Хорошо видно на примере скорости компиляции clang по версиям ;).

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

Не той стороной, дядя Федор, бутерброд ешь. Они хотят заиметь нормальный IR. Не навязывающий динамическую типизацию, в отличие от JS, и позволяющий эффективную трансляцию в машинный код. Динамические типы гэ в плане оптимизации. Поверх низкоуровневго рантайма - можно сделать и динамические типы, если хочется. С оверхедом только у любителей динамических типов, без отравления жизни остальным. Это как раз нормальный шаг в сторону более вменяемого рантайма, не зависящего от ЯПов.

> Ну вон, выше, анонимы были не в курсе преимуществ, которые может дать
> байтод (как раз из-за различных уровней/вариантов оптимизаций,

Питону это как мертвому припарки. Те кто посообразительнее, и кто на деньги из-за тормозняков попадает - уже сделали выводы. У гугля есть go, дропбокс в который там уже раз переписывают. Что-то showcases производительности превратились в failboat.

> заладили про что-то, что якобы jit ну никак не может, ну
> и про нагрев воздуха не забыли – видимо наболело )

Ты прав, JIT и даже AOT на стороне юзера - больная тема. Сомневаешься? Посмотри сколько времени .NET в винде после установки генерит сборки в нативном коде из абстрактного. Всего полдня лагания компа - и готово.

>> В си можно работать и без libc, и без выделения памяти malloc'ом.
>> Как тебе такой оборот?
> Опять свинчивание с темы. Анонимы такие анонимы!

А в чем свинчивание? В том что кто-то смеет пользоваться возможностями ЯП и компилятора? Так си тем и хорош - хочешь, пользуешься либой. Не хочешь - не пользуешься. Модно самому себе свой libc написать, с шахматами и поэтессами. Если это зачем-то надо.

> А glibc у нас теперь на динамичном языке, да?

Glibc - всего лишь одна из реализаций libc, которая может использоваться а может и не использоваться, на усмотрение програмера.

> Или почему его нельзя использовать?

Можно. Если его свойства устраивают - мы им пользуемся. А если не устраивают - не пользуемся. И просто берем что-нибудь другое или пишем свое. Инструментарий позволяет. А не лезем доказывать с синдромом утенка что "не такой уж он и плохой".

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

Это "увы" не ощущается. Увы.

> Спасибо, Маэстро Луж, вы опять были неповторимы!

Да не за что, меня эта дискуссия тоже поулыбала.

> ЗЫ: молодца, взял и зарегистрировал ник.
>> Участник:    Нимано
>> ФИО:    Лох Педальный
> Ну да – крутой аргумент, прям слов нет.

Ты так активно педалировал тему анонимов, что он стал НЕаноним :P.

>  Знатно у вас припекает )

Уверен что у меня? :) Впрочем, если тебе нужен этот ник - напиши какую-нибудь ненужную почту в ответе - я тебе пароль туда вышлю, пока не забыл. Мне этот ник не требуется.