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

> Лисповоды могут нести зачётки сразу?

Они все, кхмм, лисповоды, в нектором роде, да. Писали программы на... Autolisp. Поэтому лисп не вклюнен.

> ИМХО Mono - это единственный способ пересадить часть прогеров с Win на Линукс. Без переучивания.

Chto znachit bez pereuchivaniya?

Esli tak nazyvaemyj 'proger' ne mozhet osilit' novyj yazyk ili platformu, on BYDLO-proger i emu ne stoit etim zanimat'sya voobshe.

>ИМХО Mono - это единственный способ пересадить часть прогеров с Win на Линукс. Без переучивания.

Java достаточно.

Ладно, господа. Гвозди в гроб забили, хорошее вспомнили, пора закапывать!

Аминь!

>Скорее развитие тех, кто пользуется дельфи пошло не туда.

Всегда удивлялся откуда берутся уроды, программирующие на 1С и дельфи...

> Всегда удивлялся откуда берутся уроды, программирующие на 1С и дельфи...

А на чем ты сам писал мелкие и чуть больше мелкого БД году в 1995-1998? На Лиспе? И что ты внедряешь для официального бухучета в конторах на 50 человек? SAP?

И кстати, поделки на делфи и 1С хоть под вайном пускаются. :)

а зачем системному программисту дизайнер форм ?

>Моно действительно работает или это вечная альфа-версия?

Работает. Только писать надо "под нее". ПО, написанное под виндовый дотнет вряд ли нормально будет работать под моно. WindowsForms отображается в моно не красиво, а порой, просто неверно (кстати, есть разница в прорисовке WindowsForms с помощью виндовой и линуксовой версией моно). Если писать Gtk# приложения, то они выглядят нормально.

Многопоточные приложения тож работают только в путь, все конструкции языка C# на уровне 2.0 поддерживаются.

Есть неплохая среда разработки под Линукс - MonoDevelop (ее виндовый аналог SharpDevelop).

Так что не все так грустно.

Если человек не может осилить кириллицу.... :))

>>> Ну какой прок в массиве из Object

>> А что случилось с generics containers? O_o

>Там делается то же самое, что я описал, только неявно. Зачем ещё до кучи и неявная потеря производительности?

Там нет неявной потери производительности (дотнет 2.0). Например:

List<int> MyList = new List<int>();
MyList.Add(3);
int a = MyList[0];

Посмотри в IL коде - там даже боксинга-анбоксинга не будет.

А зачем нужны системные программисты? В основном нужны прикладники, пишущие под заказ. Им нужен дизайнер форм. Как минимум. А в основном - фреймворк, заточенный под задачи, которые он решает.

>две крайне полезные функции succ и pred которые дают следующее-предыдущее значение типа с учером размерности типа и контроля overflow-underflow

Ап стену Паскалист сраный!

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

>"множество перечисляемых типов"

Ап железобетонную стену! С разбегу!

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

>Изучивший паскаль, потом на C/C++ будет писать хорошо И отсасывать у Вирта и Страуса http://www.sql.ru/forum/actualthread.aspx?tid=466654

>А вот изучивший бейсик Идет работать

>Собственно говоря, delphi с тех пор и не ушло никуда, плодит вагоны говна, а не код.

А вы, вместо того, чтобы издавать звуки женскими половыми органами, взяли бы отладчик да и посмотрели, что он там "плодит" на самом деле. Я писал реализацию байт-код машины на дельфи (для ICFP Programming Contest 2006, если кому интересно), а потом сравнил ее производительность с реализацией этом же машины, написанной на "кошерном" ANSI C. На чисто вычислительных задачах они были по производительности примерно одинаковы (+/- 3%), а вот на "условно реальных" задачах (которые требовалось запускать на этой машине), моя выигрывала 30-50%

>а не тормозить всю программу Integer Overflow checking Отключается одним щелчком мыши в настройках компилятора

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

>>Собственно говоря, delphi с тех пор и не ушло никуда, плодит вагоны говна, а не код.

>А вы, вместо того, чтобы издавать звуки женскими половыми органами, взяли бы отладчик да и посмотрели, что он там "плодит" на самом деле. Я писал реализацию байт-код машины на дельфи (для ICFP Programming Contest 2006, если кому интересно), а потом сравнил ее производительность с реализацией этом же машины, написанной на "кошерном" ANSI C.

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

>>>> Ну какой прок в массиве из Object

>>> А что случилось с generics containers? O_o

>> Там делается то же самое, что я описал, только неявно. Зачем ещё до кучи и неявная потеря производительности?

> Там нет неявной потери производительности (дотнет 2.0).

в какой книжке ты это прочитал? наверно в той же, в которой пишут что у дотнета нет проблемы с дорогим форком

> Например: Посмотри в IL коде - там даже боксинга-анбоксинга не будет.

распечатку в студию.

> Паскаль - та же императивная чача что и С. Более многословная на пустом месте тока, и с отрезанным "опасным" функционалом без давания чего-либо взамен.

в паскале есть $R+, чем он удобнее на этапе проектирования и отладки, чем С. и не говорите, что Вы никогда мимо массива не промахивались.

>А на чем ты сам писал мелкие и чуть больше мелкого БД году в 1995-1998? >На Лиспе? И что ты внедряешь для официального бухучета в конторах на 50 >человек? SAP? Я писал на Клиппере и Оракле, работаюь, кстати, до сих пор. А ты, что на турбобейсике? Караул...

>> Вообще, я считаю ущербной идею наличия общего предка у всех классов

> Как раз это является самым нормальным решением. Числа это такие же обьекты. Только они представляются как объекты когда нужно, во время упаковки. Все оптимально.

Вот ассемблеристы признают только одну структуру данных - одномерный массив, а остальное считают подарком от лукавого. А мне, как математику, важно, чтобы программа была логичной и делала только разрешённые действия с объектами, а не приводила толстое и красное к одному типу. Кстати, потому же я избегаю использования сишных низкоуровневых возможностей в c++.

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

> И что там можно наворотить? В С++ таких монстров на каждом шагу можно накрутить, что потом матерится другой будет.

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

---

> Ну ты сравни - кто такой этот Вирт, рядом с такими монстрами как Карделли и Милнер - а они оба нехило повлияли на развитие системы типов в .NET вообще и в C# в частности.

Поржал, спасибо. Может для .net way их монстроподобные улучшения и хороши, но мне с ними не по пути.

Вегда удивлялся, почему еще пищат программисты быдлоподелий на Фоксе/Клиторе?. Неужели не все сдохли с голодухи?

>> Паскаль - та же императивная чача что и С. Более многословная на пустом месте тока, и с отрезанным "опасным" функционалом без давания чего-либо взамен.

>в паскале есть $R+, чем он удобнее на этапе проектирования и отладки, чем С. и не говорите, что Вы никогда мимо массива не промахивались.

Не промахивался =). У меня в каждой функции не более одного цикла, а lowerBound & upperBound всегда передается параметрами. С моим стилем кодирования конечно пригодились бы вложенные функции, но я нормально обхожусь без них. А то что в паскале строгая типизация на пустом месте и при этом нет никаких генриков чтобы нормально с этим жить, вот это плохо.

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

Прям не узнаю ЛОР, такие все вежливые...

Нет чтоб написать "Калич отправился втопку, где ему самое место."

>>> Паскаль - та же императивная чача что и С. Более многословная на пустом месте тока, и с отрезанным "опасным" функционалом без давания чего-либо взамен.

>> в паскале есть $R+, чем он удобнее на этапе проектирования и отладки, чем С. и не говорите, что Вы никогда мимо массива не промахивались.

> Не промахивался =). У меня в каждой функции не более одного цикла, а lowerBound & upperBound всегда передается параметрами.

На тупой однопроходной итерации мало кто ошибается :)

Как, например, выглядит у Вас решение СЛАУ методом Холецкого без вложенных циклов и с передачей нижней/верхней границы как параметра? И в этом можно потом разобраться?

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

Можно эту фразу поподробнее?

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

В новом freepascal'е появились шаблоны(generics). А ещё есть какой-то коммерческий паскаль под .net и mono, где они давно были.

>Вегда удивлялся, почему еще пищат программисты быдлоподелий на >Фоксе/Клиторе?. Неужели не все сдохли с голодухи?

На "фоксе-клиторе" в свое время было создано 95 процентов всего работающего в этой стране программного продукда, в отличие от глюкавого паскаля и парадокса (не говорю уже о делфи)... А насчет голода, то да, тут вы впереди планеты всей. Намутить экранных форм, за которыми НОЛЬ смысла и сорвать на этом тупом мерцании экрана на хлеб с маслом, это делфи!

>>>> Паскаль - та же императивная чача что и С. Более многословная на пустом месте тока, и с отрезанным "опасным" функционалом без давания чего-либо взамен. >>> в паскале есть $R+, чем он удобнее на этапе проектирования и отладки, чем С. и не говорите, что Вы никогда мимо массива не промахивались.

>> Не промахивался =). У меня в каждой функции не более одного цикла, а lowerBound & upperBound всегда передается параметрами.

>На тупой однопроходной итерации мало кто ошибается :)

>Как, например, выглядит у Вас решение СЛАУ методом Холецкого без вложенных циклов и с передачей нижней/верхней границы как параметра? И в этом можно потом разобраться?

А что, его принципиально на примитивные функции не разбить? Не верю.

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

>Можно эту фразу поподробнее?

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

>> Как, например, выглядит у Вас решение СЛАУ методом Холецкого без вложенных циклов и с передачей нижней/верхней границы как параметра? И в этом можно потом разобраться?

> А что, его принципиально на примитивные функции не разбить? Не верю.

Можно. Но будет нечитаемо. И ни один математик не поймёт, что там написано. А там всего-то пара циклов и одна сложенная сумма.

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

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

>> Можно эту фразу поподробнее?

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

Ясно. Согласен.

s/сложенная/вложенная/

Наезд был и на 1Сников. Кажется все программы, написанные "суперкрутыми прогерами" в эпоху дикого капитализма уже заменены 1С.

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

Имена полей блин поназывают - SSUK, SUVSK - хрена лысого потом разберешь! Хорошо, что по данным можно понять (если они строковые), а если - валюта...

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

Почему нельзя? Указатели, работа с памятью и приведение типов в Паскале есть.

Ну будет вместо

void qsort(void *base, size_t nel, size_t width, int (*compar)(const void *, const void *))

такая процедура

uses UnixType;

type TCompareFunction = function(const arg1, arg2): integer;

procedure qsort(var base; nel, width: size_t; compare: TCompareFunction);

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

>Почему нельзя? Указатели, работа с памятью и приведение типов в Паскале есть.

Интересует не то, что Паскаль хуже или не хуже С, а то чем он лучше С. В данном коде видим мы те же яйца, в том же ракурсе. Размер буффера не проверяется, тип элементов тоже не проверяется. Вирт был бы против.

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

ты просто никогда не писал mission critical программ, систем управления. После ada паскаль самый уместный там, где проверок лишних не бывает

З.ы. Но вы не переживайте, продолжайте плакать и ловить сегфолты

> ты просто никогда не писал mission critical программ, систем управления. После ada паскаль самый уместный там, где проверок лишних не бывает

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

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

>ты просто никогда не писал mission critical программ, систем управления. После ada паскаль самый уместный там, где проверок лишних не бывает

Как-то Луговский пришел срать в fido7.su.c-cpp из-за невозможности математически обосновать корректность С программы. Один из ответов был: "Я вот использую Лисп в том ньюcридере в котором пишу это письмо (Emacs). И он глючный надо сказать - пометка "прочитанное" периодически едет. В С я бы мог предположить что где-то неинициализированная переменная. Но Лиспе это же невозможно!!!. Как в *Лиспе* может быть баг? Как они умудрились??? Они пререхитрили *Лисп* !!!"

Блин .Net/Java решает все эти проблемы.

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

>Блин .Net/Java решает все эти проблемы.

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

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

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

> здрасте - в паскале подобных языках всегда был аналог union-а называлась запись с вариантами - учите матчасть 8-)

Что первее появилось, товарищ знаток, паскаль или си? На каком языке прграммы понятнее? Мне например на си, может потому что я его действительно изучал?

> Дельфи не выиграла у VB6 и сдалась под натиском .NET, причем тут Java?

Когда .Net только появилась Java уже уделала Delphi, поэтому никому выбирать междо Delphi и .Net собственно и не приходилось

Воздержусь от флуда, так вами любимого...

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

Ну да, знаю я Вас, быдлокодеров, любой эксчепшн катчите, лишь бы не разбираться в сути ошибки :)

А ты предлагаешь гулять по всей памяти и писать туда всякую хрень? Поздравляю! Вы вывели новую формулу защищенного программирования!

Товарищ! С связи полным отсутствием дальнейших перспектив у Делфинистов по работе именно оттуда в нашей стране наблюдается отток в DotNet.

http://www.sql.ru/forum/actualthread.aspx?bid=9&tid=472788&pg=1 http://forum.privet.com/viewtopic.php?t=123845&postdays=0&postorder=a...

А Ява и DotNet - это параллельно существующие реальности. У Явистов есть главный козырь - Java Enterprise. Ну и реальная кроссплатформенность.

Ява и Делфи никогда не конкурировали. Они существовали совместно (пример - сервер приложений на Ява, клиент - Делфи)

> А ты предлагаешь гулять по всей памяти и писать туда всякую хрень? Поздравляю! Вы вывели новую формулу защищенного программирования!

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

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

Товарищ. На Делфи вообще нет квалифицированных специалистов, одни Button1Click-быдлокодеры. Да и какой бы крутой прогер не был, он всегда делает ошибки, мелкие ошибки. Отсутствие в Делфи сборки мусора, постоянные AccessViolation (так хочется Делфи назвать AccessViolation-системой), возникающие в быдло-компонентиках, написанных Button1Click-быдлокодерами все это основные преимущества этой быдлосистемы. Я уже не говорю о язычке. В ObjectPascal дебильнейшая концепция модулей. От перемены порядка подключения модулей в uses программа может перестать работать. Ебанатство. С ужасом представляю частичные классы в Pascal. Вообщем ObjectPascal - говно, которому нет места в профессиональном мире разработки ПО.

+1

Так что не ебитесь товарищи с этим говном, а переходите на .NET.