CrossKylix прекратил свое развитие

>>И какое оно страшное все-таки... или можно собрать сам лазарус под gtk2/qt4?

>Под gtk2, вроде бы, можно.

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

>>>И какое оно страшное все-таки... или можно собрать сам лазарус под gtk2/qt4?

>>Под gtk2, вроде бы, можно.

>IDE (0.9.22) соберётся и с qt4, но, скорее всего, будет падать. Проверил сам вчера с qt4.3.1. А вот примитивное тестовое приложение работает без падений. Похоже, глюки в каком-то из компонентов.

Тьфу, то есть в биндингах где-то, не в компонентах.

> Ты когда нибудь пробовал создавать приложение БД в Делфи и VB6? В Делфи все кажется сначала круто и красиво, а вот потом.... В VB6 - наоборот.

Только в Дельфи. И начинал я не с рисования форм, а создания костылей для фильтрации-групировки чего угодно и подобных вещей. Возможно поэтому сначал было фигово, а потом гораздо веселее? Зависит от оператора ПЭВМ, так сказать?

>>Управляемое выполнение - решение проблем перехода за пределы массива и т.п. вещей!

>Ну будет он кидать ArrayIndexOutOfBoundsException, ну и что?

>Так ты сможешь обработать это исключение! А хрена лысого Access Violation обработаешь или еще хуже затрешь совершенно левую область памяти!

Его еще надо грамотно обработать, чтобы не разрушить внутреннее состояние объекта. Реализовать парадигму "Прием-или-Откат" так сказать. Быдлокодеры это делать как правило не умеют, так что работоспособность программы после возникновения исключения как правило под вопросом - спасает лишь то что на Джаве пишут чаще всего серверную часть, и возникший Екзепшен может разрушить лишь контекст текущей транзакции, не более того. По поводе утечек памяти - GC это не панацея. Есть еще т.н "висячие ссылки".

> Я писал на Клиппере и Оракле, работаюь, кстати, до сих пор.

Типа Клиппер лучше Дельфей, да-да. Я писал на Дельфи и Interbase-Firebird, рабоает, зараза, тоже до сих пор.

> Намутить экранных форм, за которыми НОЛЬ смысла и сорвать на этом тупом мерцании экрана на хлеб с маслом, это делфи!

Видимо дело в том, что я знал, что не формах счаcтье, а надо кодить? :)

> Что первее появилось, товарищ знаток, паскаль или си?

Pascal - 1970-ый год
C - 1972-ый год

> На каком языке программы понятнее?

В среднем - на паскале. При хорошем стиле програмирования и адекватной задаче - на C.

> Когда .Net только появилась Java уже уделала Delphi

Чем, Swing'ом? Смешно. Адрес дилера кинь.

> В ObjectPascal дебильнейшая концепция модулей.

Вообще-то главная проблема паскаля - отсутвие генериков, итераторов, ассоциативных массивов, анононимных функций (ну и далее везде) и т.д., а с модулями там против этого все нормально.

>> В ObjectPascal дебильнейшая концепция модулей.

>Вообще-то главная проблема паскаля - отсутвие генериков, итераторов, ассоциативных массивов, анононимных функций (ну и далее везде) и т.д., а с модулями там против этого все нормально.

Да не скажи - там нужно расширить какой-то монструозный класс и зарегистрировать его в каком-то репозистроии. Я как-то халтурил на Дельфи, и разбираться в этом мне было влом, обошелся без этого. Хотя в одном-двух местах было бы грамотно завести именно отдельный custom компонент.

> Да не скажи - там нужно расширить какой-то монструозный класс и зарегистрировать его в каком-то репозистроии.

Это компоненты, а не модули. Это разные вещи. ;)

Ну, справедливости ради, надо сказать, что иногда бывает важен порядок перечисления модулей в uses. Например, если хочешь использовать свой менеджер памяти. Или, как ещё один пример, во freepascal'е для использования класса TThread модуль pthreads должен идти раньше Classes, иначе программа не скомпилируется.

> Какой прок учить язык? Учить надо ИНСТРУМЕНТ. Именно он определяет, что можно сделать, а что нельзя. Язык -дело "пятое".

Ну да, это как сказать музыканту, что учить музыку не надо, а главное выучить ИНСТРУМЕНТ. Гитару, например. Или губную гармошку.

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

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

> Common Lisp - язык интересный. Но опять же, где инструменты, которые смогут заменить инструменты C/C++?

Он сам по себе инструмент. В конце-концов, вызовы сторонних библиотек никто не отменял. И на http://www.cliki.net/index заглядывал?

> Язык без инструментов - всего лишь yet another syntax.

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

>Пример в студию!

Легко!

http://slil.ru/24923453 (906 kb)

К сожалению, исходники, видимо, ушли в Страну Вечной Охоты за давностью лет. Но эксперты ЛОРа, я думаю, без труда установят, что написано именно в Делфи. Це-версия собрана в Dev-C++ 4.9.9.2, делфи-версия - в Делфи 7.

Для запуска тестов надо (о, ужас!) MS Windows и примерно 300 Мб свободной памяти (я думаю, что основная часть теряется просто из-за фрагментации)

>Ап стену Паскалист сраный! i++, i-- - а контроль будешь делать сам, а не тормозить всю программу Integer Overflow checking

Дятел. Ты, видать, ни того, ни другого не знаешь.

>На ANSI С qsort(...) и binary_search(...) в stdlib есть, на Паскале такие функции написать невозможно из-за строгой типизации и отсутствия генериков.

генерики есть.

>>На ANSI С qsort(...) и binary_search(...) в stdlib есть, на Паскале такие функции написать невозможно из-за строгой типизации и отсутствия генериков.

>генерики есть.

Нет, нету генериков. То что они там есть в каком-то диалекте никого не колышет. Лет десять назад Борланд делал голосование на своем сайте "хотите генерики или нет". Типичная Дельфийская публика ответила "Против".

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

Согласен. Знание абстракций первично.

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

Ты меня не совсем правильно понял. Yet another syntax - ещё один синтаксис.

Инструмент - средство (транслятор, линкёр etc.) получения результата (образ процесса, разделяемая библиотека etc.).

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

То есть, с практической точки зрения, имеют значение теория и инструмент (средство применения теории).

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

>По-поводу Оберона. Я не настаиваю, что его надо использовать в профессиональной деятельности...

А почему бы и нет. Проблема в инструментах.

По поводу CL. Почитал стандарт, заинтересовался. Поковырял SBCL и Corman Lisp, понял, что для моих задач они не подходят. Опять проблема в инструментах. Язык подходит, инструмент - нет.

>для ICFP Programming Contest 2006, если кому интересно

>К сожалению, исходники, видимо, ушли в Страну Вечной Охоты за давностью лет.

За давностью лет говоришь?

А алгоритмов этой программы ты уже не помнишь даже в общих моментах, хоть убей? И тоже за давностью лет. Верно?

Разница в 30%-50% существенна. Неужели программы абсолютно идентичны?

>> лучшая формула защищённого программирования - это брать на работу квалифицированных опытных программистов

> Товарищ. На Делфи вообще нет квалифицированных специалистов, одни Button1Click-быдлокодеры.

Сейчас - нет. Да и не было во времена расцвета дельфи подобных. А вот на паскале очень даже неплохо считали всякие мелочи типа ыундаментов ГЭС и т.д.

PS. дотнет идёт на йух. Эффективного кода как в C от него не добъёшься из-за понатыканных повсюду неотключаемых мусорщиков, антилогичной иерархии классов(это я про общего предка) и никому не нужной унификации совершенной разных языков, которая сделала из всех них какое-то "говно# .NET". А уж гуйки я и на tcl нормально попишу, благо там гуй разрабатывается в разы быстрее, чем в delphi/qt/windows::forms.

> http://www.sql.ru/forum/actualthread.aspx?bid=9&tid=472788&pg=1

Там, кажется, ВСЛ отметился

> По поводу CL. Почитал стандарт, заинтересовался. Поковырял SBCL и Corman Lisp, понял, что для моих задач они не подходят. Опять проблема в инструментах. Язык подходит, инструмент - нет.

Высшее образование на младших курсах эта проблема ну совершенно не волнует (иначе SICP бы давно сожгли ;). И это правильно.

>За давностью лет говоришь?

Залил на болванку, вчера искать лениво было.

>А алгоритмов этой программы ты уже не помнишь даже в общих моментах, хоть убей? И тоже за давностью лет. Верно?

А какие там особые алгоритмы? В спецификации подробно описан каждый чих этого псевдопроцессора. Бери да реализуй. Но вопрос-то не в этом был. А в том, как, по выражению господина mv, "вагоны говна" умудряются работать как минимум не хуже (см вычислительный тест), чем код, сгенерированный из *правильного* языка?

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

Поясняю для проспавших курс философии - знание языков связано со способом мышления, даже если их не используешь. Например, если человека лет пять долбить паскалем и явой, то самая идея языков без описания типов переменных ему кажется такой же странной и нелевой, как мысль ходить по улице в семейных трусах. На этой почве у людей появляется чувство неуверенности в себе и злоба в адрес "скриптовых недоязычков" :)

> злоба в адрес "скриптовых недоязычков" :)

Да, следить за quoting-ом и escaping-ом после "классического" языка как-то сложно.

>антилогичной иерархии классов(это я про общего предка) На Java тоже будем наезжать? Там тоже для всего есть общий предок.

>Эффективного кода как в C от него не добьёшься из-за понатыканных повсюду не отключаемых мусорщиков Циклы в С# уже быстрее чем в С, товарищ! А Using мама не разрешает использовать? Унификация языков очень нужна (ну это только всякие Tcl-быдлокодеры могут не этого не понимать). Нет нужды писать очередные неэффективные быдло-интерпретаторы для язычков, не имеющих под собой никакой основы. Переводи в IL-код и все.

>>> антилогичной иерархии классов(это я про общего предка) На Java тоже будем наезжать? Там тоже для всего есть общий предок.

>> Эффективного кода как в C от него не добьёшься из-за понатыканных повсюду не отключаемых мусорщиков

> Циклы в С# уже быстрее чем в С, товарищ!

Это не с гетзефакс случаем? ;) Не верю, потому что быстрее некуда.

> А Using мама не разрешает использовать?

Это к чему?

> Унификация языков очень нужна. Нет нужды писать очередные интерпретаторы для язычков, не имеющих под собой никакой основы. Переводи в IL-код и все.

Задам один вопрос, по результатам которого решу, стоит ли разговаривать дальше: Вы уверены, что может существовать язык, на котором будет удобно писать _любые_ задачи?

Ну и ещё, пока не забыл: а почему в байт-код, а не в ассемблер соответствующего процессора?

>Циклы в С# уже быстрее чем в С, товарищ!

Intel C++ некоторые циклы разворачивает, например при перемножении матриц 4x4 он разворачивает внутренние циклы. Можно ли ускорить отсутствие цикла (0 тактов) в этом случае?

>а почему в байт-код, а не в ассемблер соответствующего процессора?

Отвечаем для особо одаренных: потому что ни ОДИН ИЗ КОМПИЛЯТОРОВ не сможет заоптимизировать код под ВСЕ машины ОДНОВРЕМЕННО! Ну не может! А JIT генерирует машкод на машине где БУДЕТ РЕАЛЬНО ИСПОЛНЯТЬСЯ ПРОГРАММА! Попробуйте такое с обычными программами? А если архитектуры процессоров разные?

Даже для AMD и Intel нужно применять разные

Вот и получаем кучу дистров одной и той же программы: здесь для Интелов, здесь для АМД, здесь для чего-то другого.

> А Using мама не разрешает использовать?

Это к чему?

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

>Задам один вопрос, по результатам которого решу, стоит ли разговаривать дальше: Вы уверены, что может существовать язык, на котором будет удобно писать любые задачи?

А к чему вопрос? Для ДотНета есть МНОГО языков. IL-код - один. Ява - аналогично.

>> а почему в байт-код, а не в ассемблер соответствующего процессора?

> Отвечаем для особо одаренных: потому что ни ОДИН ИЗ КОМПИЛЯТОРОВ не сможет заоптимизировать код под ВСЕ машины ОДНОВРЕМЕННО! Ну не может! А JIT генерирует машкод на машине где БУДЕТ РЕАЛЬНО ИСПОЛНЯТЬСЯ ПРОГРАММА!

JIT НЕ МОЖЕТ оптимизировать код, т.к. оптимизирующий компилятор ВСЕГДА работает медленнее обычного. Соответственно, все фишки конкретного процессора будут съедаться.

> Вот и получаем кучу дистров одной и той же программы: здесь для Интелов, здесь для АМД, здесь для чего-то другого.

проблема уже давно решена в linux.

>>> А Using мама не разрешает использовать?

>> Это к чему?

> А документацию мама тоже запрещает читать. Он гарантирует освобождение ресурсов при выходе из блока.

Скажем так, не ранее, чем закончится блок выполнения. На самом деле, данные остаются в памяти, пока мусорщик не соберётся их почистить всем скопом. А если памяти не хватает, мусорщик сначала пытается почистить, потом дефрагментировать память, а потом валится с OutOfMemoryException. На всё это уходит колоссальное время: полчаса, при ограничении на память JVM в 128 мб.

>> Задам один вопрос, по результатам которого решу, стоит ли разговаривать дальше: Вы уверены, что может существовать язык, на котором будет удобно писать любые задачи?

> А к чему вопрос? Для ДотНета есть МНОГО языков. IL-код - один. Ява - аналогично.

Все дотнет-базирующиеся языки отличаются ТОЛЬКО синтаксисом, а не ПАРАДИГМОЙ. Они все объектно-ориентированные. Ну и нах мне десять сишарпов, различающихся только тем, как там обозначается цикл о преация присваивания?

И ещё: не может JIT-компилятор из IL восстановить тип конкретной задачи и оптимизировать именно под неё. Просто потому, что не все ялгоритмы можно равнять под один гребень.

>>> а почему в байт-код, а не в ассемблер соответствующего процессора?

>> Отвечаем для особо одаренных: потому что ни ОДИН ИЗ КОМПИЛЯТОРОВ не сможет заоптимизировать код под ВСЕ машины ОДНОВРЕМЕННО! Ну не может! А JIT генерирует машкод на машине где БУДЕТ РЕАЛЬНО ИСПОЛНЯТЬСЯ ПРОГРАММА!

> JIT НЕ МОЖЕТ оптимизировать код, т.к. оптимизирующий компилятор ВСЕГДА работает медленнее обычного. Соответственно, все фишки конкретного процессора будут съедаться.

И шшо: всё равно придётся для каждой архитектуры писать свой JIT-компилятор. Какая в попу разница?

> Унификация языков очень нужна (ну это только всякие Tcl-быдлокодеры могут не этого не понимать). Нет нужды писать очередные неэффективные быдло-интерпретаторы для язычков, не имеющих под собой никакой основы. Переводи в IL-код и все.

Это ничего что IL-код очень плохо-плохо поддерживает динамические языки? Или IronPython уже генерит классы, которые можно использовать из C#? Нет? А кто тут тогда быдлокодер, кстати?

> А к чему вопрос? Для ДотНета есть МНОГО языков. IL-код - один. Ява - аналогично.

Но нормальный питон, увы, только CPython. JRuby впрочем пилят.

> А к чему вопрос? Для ДотНета есть МНОГО языков. IL-код - один. Ява - аналогично.

В общем наше все - Parrot. В будущем :)

>Это ничего что IL-код очень плохо-плохо поддерживает динамические языки?

Для особо одаренных и контуженных, находящихся в танках в анабиозе: http://en.wikipedia.org/wiki/Dynamic_Language_Runtime

http://www.go-mono.com/archive/1.2.5/

Dynamic Language Runtime

This release fixes various issues that were exposed by IronPython 2.0 preview release and the Dynamic Language Runtime from Microsoft. They are both functional on this release.

>Или IronPython уже генерит классы, которые можно использовать из C#? Скачай с http://www.codeplex.com/IronPython - узнаешь!

DotNet - уже наше фсё! В настоящем!

А попугайчег, он кем поддерживается? Какими фирмами с оборотами хотя бы 10% оборота МС?

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

У Сан они есть. Поэтому Ява - это обеспеченная технология. У МС они тоже есть.

А кто стоит за Попугайчиком? Оно кстати - тоже виртуальная машина. А тут как бы наезжают на ДотНет!

> Скачай с http://www.codeplex.com/IronPython - узнаешь!

$ dpkg-query -L ironpython | grep 'bin/'
/usr/bin/ipy


Раньше не было. Допилили?

>> Это ничего что IL-код очень плохо-плохо поддерживает динамические языки?

> Для особо одаренных и контуженных, находящихся в танках в анабиозе: http://en.wikipedia.org/wiki/Dynamic_Language_Runtime

DLR - надстройка поверх CLR, что и т.д. Для динамических языков пришлось сделать свой рантайм, рантайм статических языков не подошел. Как привязать классы к DLR к CLR пока не прочел, буду потом смотретью

Впрочем я только за Iron*.

> У Сан они есть. Поэтому Ява - это обеспеченная технология.

Почитай получше спецификации J2EE, pojo и апокрифы Better Faster Lighter Java - посмотришь на вопрос бабла под другим углом.

>Нет, нету генериков. То что они там есть в каком-то диалекте никого не колышет. Лет десять назад Борланд делал голосование на своем сайте "хотите генерики или нет". Типичная Дельфийская публика ответила "Против".

Есть генерики.

http://svn.freepascal.org/svn/fpcbuild/tags/release_2_2_0/install/doc/whatsne...

> DotNet - уже наше фсё! В настоящем!

Аргумент "все быдлокодеры используют дотнет" не катит.

Лучше растолкуйте мне, непонятливому, что я заблуждаюсь, говоря про неэффективность оптимизаций JIT-компилятора, дорогой fork() из-за присутствия JIT-компиляции, малоэффективный неотключаемый "мусорщик" и вредные архитектурные вещи типа общего предка у всех классов и подстригания всех языков под одну гребёнку.

Гаа, ты чё, тупой или прикидываешься?

>неэффективность оптимизаций JIT-компилятора JIT генерирует в разы эффективней, чем доблестный GCC

>дорогой fork() из-за присутствия JIT-компиляции Во блин, завелся на ЛОРе спец по форкам. У тебя они все мозги съели!

>малоэффективный неотключаемый "мусорщик" Еще раз читает описание using. Когда тебе мама все-таки разрешит читать документацию! http://msdn2.microsoft.com/en-US/library/yh598w02(VS.80).aspx

А насколько эффективен сборщик мусора в Питоне? В Попугае? В Лиспе?

>вредные архитектурные вещи типа общего предка у всех классов Ктулху GCC однозначно съел твой мосх. Или что там было...

>подстригания всех языков под одну гребёнку А когда мы переводим в машкод, мы ведь тоже подстригаем все языки под одну гребенку, быдло!

Вообще-то в Делфи 2007 есть генерики! http://hallvards.blogspot.com/2007/08/highlander2-beta-generics-in-delphi-for...

>> неэффективность оптимизаций JIT-компилятора

> JIT генерирует в разы эффективней, чем доблестный GCC

Эффективней - это быстрее? Да, gcc не быстр. Но он исполняется ОДИН РАЗ на этапе компиляции а не КАЖДЫЙ РАЗ при запуске, так что тут скорость особого значения не имеет. Кстати, кроме гцц существует ещё огромный выбор компилятором, в т.ч. и бесплатных. Например, сановский компилятор.

>> дорогой fork() из-за присутствия JIT-компиляции

> Во блин, завелся на ЛОРе спец по форкам. У тебя они все мозги съели!

Просто это неопровержимый довод, подтвержающий ущербность дотнета и жабы.

В нашем проекте была вещь на жабе, запускавшая удалённо программу и возвращавшая её вывод(rsh/ssh не катил из-за того, что он смешивает локальный и удалённый stderr). Утилита запускалась довольно часто. После того, как мы переписали её на C, мы получили 25% прирост в скорости всего нашего продукта. Вот он, дорогой форк.

>> малоэффективный неотключаемый "мусорщик" > Еще раз читаем описание using. Когда тебе мама все-таки разрешит читать документацию! http://msdn2.microsoft.com/en-US/library/yh598w02(VS.80).aspx

Взято с урла из секции "Remarks": "The release of memory is non-deterministic; memory is released whenever the CLR decides to perform garbage collection." Это как раз то, что я и написал.

Про юзинг: мне то, в каждую процедуру вставлять этот юзинг? Вот в c++ я знаю, что удаление будет производиться при выходе из области видимости. А тут мне приходится постоянно указывать "удали-ка мне вот эту вещь прям щас". Неудобно.

> А насколько эффективен сборщик мусора в Питоне? В Попугае? В Лиспе?

Лисп не претендует на звание языка "для написания всего".

>> вредные архитектурные вещи типа общего предка у всех классов

> Ктулху GCC однозначно съел твой мосх. Или что там было...

Ещё раз повторяю: мне, как математику, эта возможность не нравится из-за её противоречией с банальной логикой. Парадокс Рассела(http://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%BE%D0%BA%D1%81...) в чистом виде. Именно для избежания его в теории множеств ввели типизацию.

>> подстригания всех языков под одну гребёнку

> А когда мы переводим в машкод, мы ведь тоже подстригаем все языки под одну гребенку!

Трансляция сразу в машкод позволяет более чётко выразить логику работы программы на машинном языке, избежав ненужных операций. Например, даже замена "a=b/2" в случае целых чисел a и b на "a=b>>1" позволяет заметно увеличить производительность.

PS. Хамство поскипано.

>Да, gcc не быстр. Но он исполняется ОДИН РАЗ на этапе компиляции а не КАЖДЫЙ РАЗ при запуске, так что тут скорость особого значения не имеет. Кстати, кроме гцц существует ещё огромный выбор компилятором, в т.ч. и бесплатных. Например, сановский компилятор.

Про Ngen и AOT тебе так же напомнить? Мама тебе точно читать запрещает!

JIT compilation is considered advantageous in many scenarios because of its portability, flexibility and performance. The only major drawback is the startup time delay. Various technologies exist for reducing this delay. "Native Image Generator" (Ngen.exe) by Microsoft is one of the examples. Ngen pre-compiles (or pre-jits) bytecode in a Common Intermediate Language image into machine native code. As a result, no runtime compilation is needed. .NET framework 2.0 shipped with Visual Studio 2005 runs Ngen.exe on all of the Microsoft library DLLs right after the installation. Pre-jitting provides a way to improve the startup time.

http://msdn2.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

http://en.wikipedia.org/wiki/AOT_compiler

>Лисп не претендует на звание языка "для написания всего".

Ты так и не ответил на вопрос про сборщик мусора в Питоне. Может его там нет и все объекты уничтожаются по окончанию программы? :-)))))))))))))))))

>Tрансляция сразу в машкод позволяет более чётко выразить логику работы программы на машинном языке, избежав ненужных операций. Например, даже замена "a=b/2" в случае целых чисел a и b на "a=b>>1" позволяет заметно увеличить производительность.

Для особо одаренных: JIT тоже это делает!

>Про юзинг: мне то, в каждую процедуру вставлять этот юзинг? Вот в c++ я знаю, что удаление будет производиться при выходе из области видимости. А тут мне приходится постоянно указывать "удали-ка мне вот эту вещь прям щас". Неудобно.

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

А ты что, каждый обьект размещаешь на стеке? No comments... Ты сколько лет в анабиозе был? Сейчас все объекты в куче создаются!

Да и еще касательно освобождения ресурсов: Это надо быть полным дауном писать в деструкторах код освобождения ресурсов (не памяти!!!). Если мы размещаем обьекты на стеке, мы не знаем порядок вызова деструкторов. А если какой-то С++ быдлокодер напишет освобождение ресурсов, завязанное на порядок вызовов или ссылающиеся на другие обьекты, которые могут быть уже уничтожены - то пипец такой быдлопрограммульке.

А на С# я пишу специальный метод освобождения ресурсов и его детерминированно и когда нужно вызываю!

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

>> Да, gcc не быстр. Но он исполняется ОДИН РАЗ на этапе компиляции а не КАЖДЫЙ РАЗ при запуске, так что тут скорость особого значения не имеет. Кстати, кроме гцц существует ещё огромный выбор компилятором, в т.ч. и бесплатных. Например, сановский компилятор.

> Про Ngen и AOT тебе так же напомнить? Мама тебе точно читать запрещает!

http://msdn2.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx http://en.wikipedia.org/wiki/AOT_compiler

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

>> Лисп не претендует на звание языка "для написания всего".

> Ты так и не ответил на вопрос про сборщик мусора в Питоне. Может его там нет и все объекты уничтожаются по окончанию программы?

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

>> Tрансляция сразу в машкод позволяет более чётко выразить логику работы программы на машинном языке, избежав ненужных операций. Например, даже замена "a=b/2" в случае целых чисел a и b на "a=b>>1" позволяет заметно увеличить производительность.

> Для особо одаренных: JIT тоже это делает!

Для особо тупых: никакой оптимизирующий компилятор не сделает из плохого кода хороший. А дотнет и жаба с их запретами на написание достаточно эффективного кода из-за из небезопасности этого кода для быдлокодера(а вдруг он память не освободит или что-то не туда ненароком запишет!) эффективный intermediate-код не создадут. А неэффективный IL в эффективный машкод никто не сможет в общем случае перевести.

>> Про юзинг: мне то, в каждую процедуру вставлять этот юзинг? Вот в c++ я знаю, что удаление будет производиться при выходе из области видимости. А тут мне приходится постоянно указывать "удали-ка мне вот эту вещь прям щас". Неудобно.

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

> А ты что, каждый обьект размещаешь на стеке? No comments... Ты сколько лет в анабиозе был? Сейчас все объекты в куче создаются!

Меня не волнует Ваше извращённое дотнетное мировосприятие.

> Да и еще касательно освобождения ресурсов: Это надо быть полным дауном писать в деструкторах код освобождения ресурсов (не памяти!!!). Если мы размещаем обьекты на стеке, мы не знаем порядок вызова деструкторов. А если какой-то С++ быдлокодер напишет освобождение ресурсов, завязанное на порядок вызовов или ссылающиеся на другие обьекты, которые могут быть уже уничтожены - то пипец такой быдлопрограммульке.

Быдлокодер на любом языке напишет плохо. В чём вопрос?

> Если тебе известно, память, выделенная собственно под объект несозмеримо мала, по сравнению с ресурсами, которые этот объект использует!

И какие такие ресурсы, кроме памяти, может использовать программа? Вы заговариваетесь, батенька!

>Засунь сам знаешь куда эти Биллькины грамоты от микрософта. Они ж свой язык хамить не будут. Пример, когда вся это жабодотнетная хрень заметно тормозит я приводил.

Так и запишем: чел не осилил Ngen. А ведь после установки DotNet-Решения именно им и пользуются для ускорения начального запуска приложения.

>А дотнет и жаба с их запретами на написание достаточно эффективного кода из-за из небезопасности этого кода для быдлокодера

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

А IL-код достаточно высокоуровневый и позволяет генерировать очень оптимальный машинный код под конкретный процессор, а не под виртуальный 386.

>Меня не волнует Ваше извращённое дотнетное мировосприятие.

А меня не волнует ваше Dynamic-Cast-быдловосприятие. Все разработчики перейдут на DotNet. Это факт. Так же как и перешли с ассембера на Си. Тогда тоже было: а нахрена это нужно? Как компилятор Си можен генерировать эффективный код? Я ведь сам, такой крутой, могу на асме забацать и у меня все будет под контролем!

>Быдлокодер на любом языке напишет плохо. В чём вопрос?

Кол-во быдлокодеров на Си с крестами значительно больше, чем на DotNet и Java. А в России C++ быдл - подавляющее большинство.

И сидят они без работы! http://www.sql.ru/forum/actualthread.aspx?tid=466654

>И какие такие ресурсы, кроме памяти, может использовать программа?

Ктулхуй тебе не грозит, по причине отсутствия мозга.

> Так и запишем: осилил Ngen. А ведь после установки DotNet-Решения именно им и пользуются для ускорения начального запуска приложения.

А нахера, пардон, тогда городить огород из MSIL, если потом всё равно перекомпилировать на месте приходится? Гентушничество какое-то.

>> А дотнет и жаба с их запретами на написание достаточно эффективного кода из-за из небезопасности этого кода для быдлокодера

> Эти ограничения, наоборот, способствуют более эффективной оптимизациии.

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

> А IL-код достаточно высокоуровневый и позволяет генерировать очень оптимальный машинный код под конкретный процессор, а не под виртуальный 386.

Мсье не осилил флаг -m=arch у GCC?

> Все разработчики перейдут на DotNet. Это факт.

Опять довод из серии "все быдлокодеры пишут на дотнете".

>> Быдлокодер на любом языке напишет плохо. В чём вопрос?

> Кол-во быдлокодеров на Си с крестами значительно больше, чем на DotNet и Java.

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

>> И какие такие ресурсы, кроме памяти, может использовать программа?

> Ктулхуй тебе не грозит, по причине отсутствия мозга.

Давай перечисляй ресурсы, а не оскорблениями кидайся.

>А нахера, пардон, тогда городить огород из MSIL, если потом всё равно перекомпилировать на месте приходится? Гентушничество какое-то.

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

http://en.wikipedia.org/wiki/Common_Intermediate_Language

CIL is a CPU- and platform-independent instruction set that can be executed in any environment supporting the .NET framework. CIL code is verified for safety during runtime, providing better security and reliability than natively compiled binaries.

Преимущества байт-кода для Ява и .Net: 1) Кроссплатформенность 2) JIT гораздо быстрее и эффективней работает, чем GCC! 3) Надежность 4) Объекто-ориентированность 5) Верифицируемость

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

Вообще-то она подходит для всего!

>Мсье не осилил флаг -m=arch у GCC?

С этим флажком ты будешь на каждой машине клиента компилировать исходники программы? А если там нет GCC?

Сравнение с Генту? Ну бля сено-солома! С какого дуба ты упал? AOT и NGEN входят в состав среды исполнения Моно и .Net. А GCC - это как бы компилятор.

>Давай перечисляй ресурсы, а не оскорблениями кидайся.

Ну хорошо мальчик. Открываем учебник по программированию и читаем, что такое ресурс.

http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D1%82...

> Преимущества байт-кода для Ява и .Net:
Меня сильно утруждает повторять одно и то же по нескольку раз, но всё-таки повторю:

> 1) Кроссплатформенность
Она есть только там, куда портирован runtime языка. То есть официально дотнета на не-win32 и не-intel платформах нет. mono - это глючная недоделка, в которой говорить о производительности бессмысленно.

> 2) JIT гораздо быстрее и эффективней работает, чем GCC!
Повторяю, не-JIT компилятор запускается ОДИН РАЗ, а не КАЖДЫЙ РАЗ. Поясняю: с "обычным" компилятором мы теряем один раз 10 минут на компиляцию. С JIT - каждый раз по 10 секунд(в 60 раз меньше времени). Но если запустить дотнетную программу 600 раз, потери во времени будут больше, чем в скомпилированной.
А применение NGEN, который должен быть установлен на результирующей машине, еквивалентно тому, что на ней будет установлен GCC и весь проект будет перед использованием скомпилирован из сорсов.

> 3) Надежность
Давно машинный код стал ненадёжным?

> 4) Объекто-ориентированность
А как быть с остальными языками из этого списка? Выше по треду уже говорилось, что CLR для динамических языков не подходит. Ждём, когда МС напишет FLR для функциональных языков.
(http://ru.wikipedia.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B...)
Классы языков программирования
* Функциональные
* Императивные
* Процедурные
* Языки векторного программирования
* Аспектно-ориентированные
* Декларативные
* Языки динамического программирования
* Учебные
* Описания интерфейсов
* Прототипные
* Объектно-ориентированные
* Рефлексивные
* Языки логического программирования
* Языки параллельного программирования
* Сценарные, или скриптовые
* Эзотерические

> 5) Верифицируемость
Зачем перепроверять код, уже проверенный компилятором? Кроме того, от лигических ошибок это не спасает.

>> Повторяю: эффективную оптимизацию для общего случая сделать нельзя. Для гуйков и быдломорд к базам данных, не спорю, дотнетная оптимизация вполне подходит.
> Вообще-то она подходит для всего!
Понятно, анонимусу промыли мозги маркетологи из МС.
http://www.developing.ru/com/what_to_know_com_recruit.html - тут написано про "великолепную" технологию COM. Почему же Вы её не используете? Не потому ли, что придумав дотнет, микрософт стал активно обсирать свои "устаревшие" технологии, чтобы перетащить подавляющий контингент (сами знаете приставку:) )-кодеров на дотнет, чтобы стричь с них бабло?

>> Мсье не осилил флаг -m=arch у GCC?
> С этим флажком ты будешь на каждой машине клиента компилировать исходники программы? А если там нет GCC?
А если там нет .NET runtime? Ситуации совершенно аналогичны.

>Сравнение с Генту? AOT и NGEN входят в состав среды исполнения Моно и .Net. А GCC - это как бы компилятор.
Уже сказал выше.

>> Давай перечисляй ресурсы, а не оскорблениями кидайся.
> Ну хорошо мальчик. Открываем учебник по программированию и читаем, что такое ресурс.
Типы вычислительных ресурсов
* Процессорное время
его нельзя "выделить в конструкторе" и "освободить в деструкторе", как говорилось выше.
* Память (оперативная и виртуальная)
ПАМЯТЬ!
* Место на жёстком диске (постоянная память)
ПАМЯТЬ!
* Пропускная способность сети.
Аналогично процессорному времени, её из конструктора не выделишь.
Кстати, я смоневаюсь, что этот пункт всунут туда не "от балды", потому что таким образом можно учитывать и пропускную способность USB-шины.

Долбоеб он и в африке долбоеб. Особенно С++ долбоеб!

>1) Кроссплатформенность

На Ява - тоже наезжать будем?

>А применение NGEN, который должен быть установлен на результирующей машине, еквивалентно тому, что на ней будет установлен GCC и весь проект будет перед использованием скомпилирован из сорсов.

Опять путаешь сено с соломой! NGEN/АОТ - часть виртуальной машины! Его не нужно устанавливать дополнительно!

>> 4) Объекто-ориентированность

А ассембелер процессора с каких это пор стал объектно-ориентированным? А вот IL-байткод - объектно-ориентированный! И какого хрена вы привели список классов языков? Есть и Lisp.Net, Prolog.Net.

А DLR реализуется для того, чтобы программы с динамической типизацией работали так же быстро, что и со статической. Метод прошивания типов, может слышал о таком? На этапе выполнения уже будет известен тип. Это уже реализовано в LINQ.

>тут написано про "великолепную" технологию COM. Почему же Вы её не используете?

А кто сказал, что я ее не использую? DotNet великолепно интегрируется с COM. В отличие от Ява. А рынок COM исчисляется миллиардами долларов.

А какова доля этих... как их там... блин в Линуксе даже нет ничего похожего на COM... a! Shared Objects! Хоть ДЛЛ реализовали!

А Сан пришлось для Open Office реализовывыть свою UNO (работает только с ОО), а вот МС благополучно использует COM. Про качество и юзабилити Уно спросите у прогеров ОО: http://community.i-rs.ru/index.php/board,9.0.html

> 5) Верифицируемость Зачем перепроверять код, уже проверенный компилятором? Кроме того, от лигических ошибок это не спасает.

Продолжаем ликбез:

Валидация кода выполняется при конвертации кода MSIL в родной машинный код компилятором JIT. Она подтверждает, что программа не сможет получить доступ к памяти либо другим ресурсам, на которые у нее нет прав доступа. Проверенный код также является безопасным с точки зрения контроля типов (type-safe). Валидация выполняется, даже если программа компилируется в родной машинный код, хотя при этом нет полной гарантии ее правильности, поскольку результат проверки зависит от метаданных других модулей. Если вы поставляете готовый машинный код, то существует определенный риск того, что на конечной машине какой-нибудь комплект будет изменен, что сделает программу уязвимой с точки зрения корректности использования типизированных данных.

http://www.argc-argv.relc.com/56_2001/net.html

> Долбоеб он и в африке долбоеб. Особенно С++ долбоеб!
Уж определитесь, кто я в Вашем понимании: tcl-быдлокодер или цпп-долбоёб :)

>> 1) Кроссплатформенность
> На Ява - тоже наезжать будем?
Будем. Там то же самое.

>> А применение NGEN, который должен быть установлен на результирующей машине, еквивалентно тому, что на ней будет установлен GCC и весь проект будет перед использованием скомпилирован из сорсов.
> Опять путаешь сено с соломой! NGEN/АОТ - часть виртуальной машины! Его не нужно устанавливать дополнительно!
Но виртуальную машину-то надо ставить! дотнет только в висту изкоробки встроен, в остальных виндах надо dotnetfx*.exe запускать.

>> 4) Объекто-ориентированность
> А ассембелер процессора с каких это пор стал объектно-ориентированным?
Никогда им не был. Я этого не говорил. Но он не является прослойкой между высокоуровневым языком и не транслируется более ни во что, кроме конкретных действий процессора.

> А вот IL-байткод - объектно-ориентированный! И какого хрена вы привели список классов языков?
С того хрена, что язык должен иметь _свой_ личный компилятор для получения максимальной эффективности. Ведь сами же Вы сказали, что DLR создан для большей эффективности кода динамических языков.

>> тут написано про "великолепную" технологию COM. Почему же Вы её не используете?
> А кто сказал, что я ее не использую? DotNet великолепно интегрируется с COM. В отличие от Ява. А рынок COM исчисляется миллиардами долларов.
Это из той же серии, что и анонимус с контрактом на 20*10^6 у.е. тут выделывался :)
Кстати, я не в курсе, ActiveX ещё жив?

> А какова доля этих... как их там... блин в Линуксе даже нет ничего похожего на COM... a! Shared Objects! Хоть ДЛЛ реализовали!
шаред либы в UNIX появились раньше, чем в виндах. а КОМ там не нужен, ибо unix way.

> А Сан пришлось для Open Office реализовывыть свою UNO (работает только с ОО), а вот МС благополучно использует COM. Про качество и юзабилити Уно спросите у прогеров ОО
Советую почитать про DCOP. А то, что санки решили не завязываться не KDE, это их проблемы.

>> 5) Верифицируемость Зачем перепроверять код, уже проверенный компилятором? Кроме того, от лигических ошибок это не спасает.
> Она подтверждает, что программа не сможет получить доступ к памяти либо другим ресурсам, на которые у нее нет прав доступа.
man chroot, man selinux, man chmod

> Проверенный код также является безопасным с точки зрения контроля типов (type-safe).
В языках со строгим контролем типов это проверяет компилятор.

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

PS. Я так понимаю, что Вы прочувствовали разницу между JIT и не-JIT, и теперь не наезжаете на быстродействие gcc?
PPS. Про ресурс "память", как я вижу, я Вас тоже убедил.