OOP, и это облегчает разработку?

> в Iron Python уши .Net торчат настолько, что определить его как Питон можно только по вторичным половым признакам.

И ты хочешь сказать, что это является недостатком VM? Следствием ее объектной ориентированности и стековости?

Он хочет сказать, что ни хрена не понимает в IL. Не знает, что там есть не только классы, но и структуры, например.

> там есть не только классы, но и структуры, например.

Да там много интересного, так сказать Java "Lessons Learned" Edition.

Жаль, что ее придумали враги. Репутация испорчена by default.

> Да там много интересного, так сказать Java "Lessons Learned" Edition.

Именно. Потому и использую .NET (Mono), а не Java.

> Жаль, что ее придумали враги. Репутация испорчена by default.

Это только в глазах красноглазых. А на репутацию в среде красноглазой шпаны, ясное дело, всем серьёзным, мыслящим людям в лучшем виде наплевать.

> И ты хочешь сказать, что это является недостатком VM?

Скорее всего, да.

> Следствием ее объектной ориентированности и стековости?

Похоже, что да.

> Скорее всего, да.

Читать как "жопой чую, но обосновать не могу". Не стыдно самому, а?

Удивил. К тому же в банальном цпп объект класса может распологаться на стеке, в то время как в .Net для этого нужно структуру объявлять, а для класса - шиш.

Ы. А примеры? Насколько я помню, Python VM тоже стековая. Ну и объектная ориентированность .NET VM вряд ли мешает объектно-ориентированному Питону.

Тебя никто не заставляет объявлять классы где не надо.

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

>в банальном цпп объект класса может распологаться на стеке, в то время как в .Net для этого нужно структуру объявлять, а для класса - шиш.

Низачот. В стеке может располагаться объект с семантикой значений, который примерно соответствует C#-ной структуре. Нормальный полиморфный объект в стек поместить невозножно.

> Нормальный полиморфный объект в стек поместить невозножно.

Ура, поток ударных фраз продолжается!

>> Нормальный полиморфный объект в стек поместить невозножно.

>Ура, поток ударных фраз продолжается!

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

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

BTW это бессмыссленно к тому же.

>>> Нормальный полиморфный объект в стек поместить невозножно.

>>Ура, поток ударных фраз продолжается!

>Положить локально в пределах блока конечно можно

Вообще-то меня приколола фраза "полиморфный объект". Про "полиморфизм" знаю, это такое отношение между разными объектами. А что такое "полиморфный объект", с кем у него полиморфизм? O_o

> А примеры?

Для Питона не вспомню, ковырять некогда.

> Насколько я помню, Python VM тоже стековая.

Возможно, что для Питона оно не влияет. Для Лиспа помню затык был в немутабельных строках.

> Ну и объектная ориентированность .NET VM вряд ли мешает объектно-ориентированному Питону.

Там объектаня модель другая.

>Вообще-то меня приколола фраза "полиморфный объект". Про "полиморфизм" знаю, это такое отношение между разными объектами. А что такое "полиморфный объект", с кем у него полиморфизм? O_o

Что Саттер что Александреску проводят четкую границу между "объектами - значениями" у которых есть конструктор копирования, operator= и swap() и "полиморфными объектами" которые, если не ковырять в носу, размещать надо в куче и работать с ними через виртуальные функции. Возможно это кривой перевод.

> Для Лиспа помню затык был в немутабельных строках.

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

> Там объектаня модель другая.

Вполне вписывающаяся однако в модель, реализуемую в IL.

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

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

char[] заюзать было не судьба?

> char[] заюзать было не судьба?

В Лиспе?

>> char[] заюзать было не судьба?

>В Лиспе?

Да, в лиспе. Сделать Лисповские строки враппером вокруг простых символьных массивов.

> Лиспу на мутабельность строк как бы по хрену.

Но в стандарте, однако, прописано.

> Кроме того, представлений для строк много разных.

Ага. Для мазохистов.

> Вполне вписывающаяся однако в модель, реализуемую в IL.

Ссылки на бенчмарки тут уже давали. Очевидно, "впихуемость любой ценой" -- это Ваш девиз?

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

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

>>> char[] заюзать было не судьба?

>> В Лиспе?

> Да, в лиспе.

Несколько странный синтаксис для Лиспа, не находите?

> Сделать Лисповские строки враппером вокруг простых символьных массивов.

Я ж говорю -- для мазохистов.

> В Лиспе?

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

Ну когда же ты прекратишь позориться то, а?

> Но в стандарте, однако, прописано.

Лиспов много разных. Мутабельне строки - это не строки .NET, это массивы или списки char-ов.

> Ага. Для мазохистов.

А в x86 вообще такого типа данных, как строка, просто нет. Там любая реализация - "для мазохистов", да, ламерьё? Ты сам то хоть один компилятор хотя бы самого простого языка написал, чтоб такую чушь нести с таким уверенным тоном?

> Для меня хватило осмыслить, что динамику в .Net-based языках использовать нельзя.

Значит, не хватило. Моск маленький, даже простейшие вещи в него не лезут.

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

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

Я не понял ваш пост. Дело в том, что например в Яве несмотря на то что встроенная строка - это immutable тип, она предоставляет собой враппер вокруг char[]. Если нужна мутабельность, можно использовать голый char[]. Подозреваю, что в CLR дела обстоят точно так же и если для Лиспа не годится дефолтовый стринг они могут создать свой.

В CLR строки иммутабельны, поскольку статические строки разделяемые. Нормальное такое, умное решение, примерно так же, как символы в Лиспе. Ну да откуда этому красноглазому недоучке в таких тонкостях разбираться?

Вот тут мое сообщение удалили, как ответ на удаленное ваше (ибо ваше содержало оскорбления). Но я еще раз напишу. Хорошь здесь уже оскорблять всех подряд, попридержи язык, придурок неуравновешанный. Сиди в своей Висте, а сюда не ходи помойку развозить и пропоганду.

P.S. А .Net - тормоз.

> .Net - тормоз.

Если верить shootout, C# Mono в 2+ раза медленнее GCC C++. Считать ли это "тормозом" - дело личных предпочтений. Я - не считаю (C# делает Python с Psyco в разы)

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&...

Я говорю про .Net, а не C#. Высокоуровневые языки по-типа Питона, Руби, Лиспа и хаскелля на .Net работают ужасно медленно. Как многоязыковый фреймворк он годится только для нескольких языков со схожой семантикой, по-типа C# и C++.

> Если верить shootout, C# Mono в 2+ раза медленнее GCC C++. Считать ли это "тормозом" - дело личных предпочтений.

И при этом такой продвинутый Mono сливает "по полной" такой "говенной" жабке...

К тому же сама идея многоязыковости тупа: если как в UNIX way разбивать программу на составляющие - проги и либы, каждая нацеленная на свою часть работы, и написанная на разных языках, то это удобно, красиво и хорошо стыкуется. А многоязыковость .Net может подарить только возможность в одном составляющей единице лепить то на одном, то на другом языке из десяти штук, кому что нравится, кто что умеет. В итоге в этом сам черт не разберется.

Опять ты, красноглазое...

Оно сливает только на определённом классе задач. А если тот же ML с типичной для него нагрузкой сравнивать, то сливает уже JVM, причём хорошо так сливает.

> Я говорю про .Net, а не C#

Я тоже. Приведен C# как самый "вылизанный".

> Высокоуровневые языки по-типа Питона, Руби, Лиспа и хаскелля

Первые 3 - динамические языки, им особого внимания не уделяется (или раньше не уделялось), отсюда и результаты. Насчет Хаскеля - хз, он вообще для .NET есть?

Кстати, JRuby сливает Ruby1.9 по полной - это значит, что нормальных быстрых VM не существует вообще? 8)

> такой продвинутый Mono сливает "по полной" такой "говенной" жабке...

А ты сравни ресурсы, которые вкачали в Яву и Моно, и срок разработки.

> ML с типичной для него нагрузкой

И какова "типичная для ML" нагрузка? Компилятор ML? o_O

> Опять ты, красноглазое...

И я тебя люблю, дорогая...

> Оно сливает только на определённом классе задач.

Угу, и имя этому классу задач - shootout :))))

> А ты сравни ресурсы, которые вкачали в Яву и Моно, и срок разработки.

А как мне этим "баблом" добиваться "скорострельности" от программ?

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

>> А ты сравни ресурсы, которые вкачали в Яву и Моно, и срок разработки.

> А как мне этим "баблом" добиваться "скорострельности" от программ?

Тебе - никак. Если нужна максимально быстрая программа, выбирай ту VM, которая может это обеспечить. Вроде ж это очевидно, не?

> Или при сравнении скоростных характеристик будем делить время на количество вложенных средств?

Сравнение скоростей VM не сильно интересно. При сравнении "VM вообще" мы будем принимать в расчет затраченные на разработку деньги и время, да.

> Тогда LLVM будет впереди планеты всей...

Надеюсь.

Просто ты не умеешь конструировать и планировать. Проблема не в ООП.

> Вроде ж это очевидно, не?

не хорошее слово... ;)

Тогда зачем эти песни про "продвинутость" VM?

> При сравнении "VM вообще" мы будем принимать в расчет затраченные на разработку деньги и время, да.

Ну, мне точно так-же не интересно сравнивать затраченные средства на разработку VM - они уж точно _ни под какие условия_ ТЗ не "подколятся" - в лучшем случае дадут некоторую уверенность в том, что развитие и поддержку VM завтра не бросят.

>> Вроде ж это очевидно, не?

> не хорошее слово... ;)

Особенно если его использовать уместно.

> Тогда зачем эти песни про "продвинутость" VM?

Потому что это потенциал. Потому что не всем и не всегда нужна raw speed.

Не нравятся песни - не слушай. Или свои пой.

> Ну, мне точно так-же не интересно сравнивать затраченные средства на разработку VM

Не сравнивай.

> Потому что это потенциал.

Согласен. Но тогда надо брать во внимание _все_ "потенциалы".

Есть хоть какая-то надежда на то, что кто-то "крупный" (интересно - кто? :D) начнёт вкладывать средства в Mono?

Есть надежда на то, что в угоду развития в Mono пойдут на разрыв совместимости с M$.NET?

ИМХО, если уж нет обязательной привязки к JVM, то лучше выбрать LLVM не смотря на практически полную неготовность к "промышленному использованию" как "VM+среда".

> Но тогда надо брать во внимание _все_ "потенциалы".

Конечно.

> Есть хоть какая-то надежда на то, что кто-то "крупный" (интересно - кто? :D) начнёт вкладывать средства в Mono?

Во-первых, есть Novel. Во-вторых, прикол в том, что Моно до некоторой степени может пользоваться наработками .NET (прикладными) и Явы (ибо открытый проект), поэтому Моно сможет развиваться менее затратно, чем Ява или .NET.

> Есть надежда на то, что в угоду развития в Mono пойдут на разрыв совместимости с M$.NET?

Совместимости по VM? Не думаю. Совместимости по библиотекам? Так и будет, ИМХО.

> если уж нет обязательной привязки к JVM, то лучше выбрать LLVM не смотря на практически полную неготовность к "промышленному использованию" как "VM+среда"

Выбрать для какой задачи? Если для сферической бизнес-задачи в вакууме, то не стоит.

> Выбрать для какой задачи? Если для сферической бизнес-задачи в вакууме, то не стоит.

Для "сферической бизнес-задачи в вакууме" (не основанной на M$-технологиях) - только Java. В противном случае или это не "бизнес-задача", или вакуум не полный, или сфера не идеальная... :)

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

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

>приходиться держать в памяти кучу классов, что откуда наследовалось

проектировать нужно так, чтобы не нужно было держать много информации в голове одновременно; это, кстати, относится не только к ООП, а к разработке вообще.

>Ц++ я (да и многие другие) вообще не считаю объектно-ориентированным язык

Ваше мнение для нас всех, несомненно, очень важно! Пойду помолюсь моим индийским богам и пересяду с богомерзского цэпэпэ на каноническую джаву...

>Множественное наследование в большинстве случаев не нужно

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

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

полностью разделяю сию точку зрения. сиречь +1

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

> проектировать нужно так, чтобы не нужно было держать много информации в голове одновременно; это, кстати, относится не только к ООП, а к разработке вообще.

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

>Так то это так, но говорил я про стандартную библиотеку классов жабы, с которой ничего не поделать.

Приведи пример какого-либо ненужного усложнения в библиотеке классов Явы.