Вышел Lazarus 0.9.28

Ты мне предлагаешь учителю ЭТО выдать?

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

вот еще одна достаточно неплохая программка написанная в Lazarus http://peazip.sourceforge.net/

> Извиняюсь за флейм.

Дык, на ЛОРе ведь) Если б каждый за флейм извинялся... ))

>> прощайте менеджеры компоновки и упакованные боксы!

>Ну кому-то (не мне), наоборот, абсолютное размещение милее.

>Если нужны менеджеры компоновки, можно 1) перейти на Qt, где этого добра навалом; 2) попробовать написать самому, благо все исходники открыты.

Дык уже пишут, правда не все хотят это видеть в апстриме. Но в fpgui (который не-апстрим) уже есть :)

А на соусрсфорже нельзя никак сделать фильтрацию проектов по языку? Интересно было бы посмотреть и сравнить количество проектов на разных языках.

smplayer, куча браузеров, гномокеды и куча софта к ним, виртуалбокс, vlc (ну, кому-то нравится), psi (и то, что на нём), любимец публики фотошоп и его "младший брат" гимп, большинство игр, explorer.exe :), различные консолеэмуляторы, мсофис, опенофис, Flash, µTorrent, *spell'ы, Fluxbox, FBReader, Code::Blocks, DOSBox (пускать старые игрушки, в них ещё играют, да), InfraRecorder, непонятно всеми любимый под Windows Notepad++, FAR, Media Player Classic, CDex и многие другие.

>smplayer, куча браузеров, гномокеды и куча софта к ним, виртуалбокс, vlc (ну, кому-то нравится), psi (и то, что на нём), любимец публики фотошоп и его "младший брат" гимп, большинство игр, explorer.exe :), различные консолеэмуляторы, мсофис, опенофис, Flash, µTorrent, *spell'ы, Fluxbox, FBReader, Code::Blocks, DOSBox (пускать старые игрушки, в них ещё играют, да), InfraRecorder, непонятно всеми любимый под Windows Notepad++, FAR, Media Player Classic, CDex и многие другие.

Да не заморачивайся ты с этими списками. И так понятно, что на Сях больше всего софта. Самое главное здесь то, что на Делфи тоже пишут софт и очень даже успешный. Не зря же они выбирают Делфи. Значит, есть какой-то смысл. Не из жалости же к Борланду и КодГеар. Ведь так?

А все-таки, хотелось бы сравнить количество софта на Delphi и Qt. :-P

>Значит мы друг-друга так не поняли. Говоря о динамической типизации в Питоне как о минусе, я имел ввиду обучение программированию в школах, в ВУЗах.

Не нужна, согласен. Максимум пара предложений о её существовании.

>компилятором fpc поддерживается тип variant, можно грабить корованы.

Главное, чтол его поддерживает bpc. Было бы странно, если бы fpc это не умел.

Главное, что lazarus и fpc свободны и развиваются.

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

[qoute]И паскалисты не будут теперь гореть в Геене огненной за «ворованную delphi» [/qoute] Они скорее своруют, чем будут портировать.

>Они скорее своруют, чем будут портировать.

Кто они?

Те, кто развивает лазарус спасутся от геены огненной.

Большинство любителей крякнутой Делфи. Будут говорить, что пересесть с делфи на Лазаря тоже самое, что пересесть с мерса на жигуль. Хотя точнее со старого москвича на запорожец.

Пусть говорят, нам больше девственниц достанется

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

Delphi - RAD, что намекает на быстрый способ разработки. В паскале от Borland реально высокая скорость компиляции. Да, иногда вследствии этого получаются кривые поделки, но уверяю вас, что в руках профессионалов рождаются качественные приложения.
Lazarus пока болеет низкой скоростью компиляции, что несколько снижает производительность при разработке П.О. И да, в паскале с обработкой строк намного легче чем, в С., + в реализациях паскаля есть проверка выхода за границы массивов, это реально снижает вероятность появления ошибок. Однако, современные библиотеки (Qt) решили для C++ проблему обработки строк и намного лучше решают проблему Интернационализации приложений. И еще в С и производных есть убогий switch, паскалевский case намного удобнее. Хотя циклы в С выглядят симпатичнее.
Можно долго перечислять достоинства и недостатки различных языков и сред. Каждый сам решает, что для него важнее.

Не знаю, в чём именно проблема,

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

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

Ну не знаю. Я хз что такого в делфях мешает писать хороший софт. Но я вот подумал. из всех перечисленных проектов с OpenSource более-менее понятно: свободных инструментов для паскале для написания графических приложений, да еще и кроссплатформенных, всего 1 (ага, сабж), а на Делфях OpenSource писать как-то некошерно. С не-OpenSource тоже ясно: в основном они пишутся с использованием VisualStudio. Наверно, потому что от MS. Возможно, поэтому Delphi не так популярен.

Delphi - RAD

В делфи от RAD только название. Хотя в последних версиях Делфя начала приобретать человеческий облик, но за то бвбло, что за нее хотят мало кому она нужна будет.

Да, иногда вследствии этого получаются кривые поделки, но уверяю вас, что в руках профессионалов рождаются качественные приложения.

Не, чаще наоборот. Иногда качественные, а чаще плохие. У нее была своя ниша, где ей было хорошо. Но ее быстренько просрали.

Покажи мне сишный аналог Фрутилупс =))))

>большинство игр

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

>непонятно всеми любимый под Windows Notepad++

ЕМНИП он на дотнете

>консолеэмуляторы, мсофис, опенофис, Flash, µTorrent, *spell'ы, Fluxbox, FBReader, Code::Blocks, DOSBox

глюк на глюке это а не софт

Кто это и зачем он нужен?

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

Какая часть из этого пишется на дельфи? Про «сетевая часть на дотнете» это ты загнул.

он на дотнете

Для компиляции исполняемого файла (notepad++.exe), вы можете использовать VC++ 7 или MinGW 3.0 / 2.X (используйте makefile)

Да?

консолеэмуляторы, мсофис, опенофис, Flash, µTorrent, *spell'ы, Fluxbox, FBReader, Code::Blocks, DOSBox

глюк на глюке это а не софт

Покажи мне глюк на глюки в эмулторах nes/snes, *spell, fbreader? Офисы сами по себе тяжёлые. Ну, можешь вспомнить абиворд, полегчало? :}

> компилятором fpc поддерживается тип variant, можно грабить корованы.

который жутко неудобен и создает ощущение, что корованы грабят тебя.

Да, блин...

Просмотрев тред, я еще раз убедился : ждать чего либо нормально написанного от этого поколения не приходится... Полнейший бред в 99% 8)

>который жутко неудобен

чего, по-твоему, не хватает?

>Delphi - RAD, что намекает на быстрый способ разработки.

только визуально. По идее, концептуально правильный RAD -- это MDA, CASE и тому подобное. Да, есть two-way editing, и местами UML, но понятие RAD шире, хотелось бы всяких CASE.

>В паскале от Borland реально высокая скорость компиляции.

С год назад попробовал для себя язык D, уж много шумихи вокруг него было. Оказалось вполне практично, по скорости компиляции и разработки напомнило Delphi. Есть всякие non-issue проблемы, вроде "по 2 версии всего: языка, компилятора, стандартной библиотеки (Tango к тому же довольно часто перекраивается в SVN, в итоге приходится либо брать последний релиз , либо переписывать остальные библиотеки на thrunk; благо, что компилятор выдаёт deprecated warning'и и в документации и ChangeLog'е можно найти breaking changes). Под windows в DMD toolchain есть проблемы со стандартным линкером, и концепцией модульности в языке вообще (циклические зависимости не поддерживаются). Поэтому надо либо выкручиваться с DDL и самому грузить библиотеки руками (например, ELF на windows), либо брать LDC и дописать руками SEH-код (где это нужно).
В целом, работать вполне можно: Poseidon + DWT или Entice + DFL позволяют лепить простой GUI.

>Да, иногда вследствии этого получаются кривые поделки, но уверяю вас, что в руках профессионалов рождаются качественные приложения.

Поделки, написанные на Delphi часто просто визуально заметно. (Подельщики) Там не имеют понятия о Layout managers, поэтому, формы часто съезжают в кучку на неродном разрешении экрана, не прорисовываются иконки из-за ограничения на GDI handles, если мало свободной памяти (утечка ресурсов по хендлам, было и в Qt4<=4.5, на тему non-native widgets). У меня под WinXP случился один глюк: не прорисовывались кнопки\контролы\формы съезжали "в кучку", так что сразу было видно, когда программа на Delphi или инсталлятор на InnoSetup. Особенно забавно было этот глюк в инсталляторах наблюдать и вслепую жать Tab, Space, Enter несколько раз (потом взял распаковщик InnoSetup, и установил софт руками).
Сам Delphi тут не очень виноват -- я видел и собственные layout manager'ы в win32 API или MFC приложениях, было бы желание. Но поделок много, их просто сразу заметно.

>Lazarus пока болеет низкой скоростью компиляции, что несколько снижает производительность при разработке П.О.

Гм.. Можно сказать, было чуть ли не единственное преимущество перед D, и его угробили (хотя остаётся ещё GUI designer).

Можно взять eC http://www.ecere.com/action.html или Euphoria http://www.rapideuphoria.com/readme.htm http://www.rapideuphoria.com/bench.txt -- там есть нормальный SDK "из коробки", с GUI designer'ом и отладчиком; язык с Си-подобным синтаксисом, но с расширениями; трансляция в Си, интероперабельность и сравнимая с Си производительность.

> Можно долго перечислять достоинства и недостатки различных языков и сред.

надо сказать, паскалевский RTTI (в версии Delphi) гибче, и static methodы используются чаще, базовых классов выходит меньше. Но, в D1, а тем более в D2 есть нормальный typeinfo, можно построить нормальный reflection API + метапрограммирование через шаблоны и миксины. В D2 есть аналогичный C++0x concept механизм, можно построить CTFE мультиметоды.

Из недостатков D 1/2 на текущий момент можно упомянуть разве что проблемы с линкером в dmd toolchain под windows (но можно взять ldc, да и gdc наконец немного реанимировали) + отсутствие GUI средств "из коробки" -- в том виде, как это есть в том же eC SDK. Но вполне себе работают Entice с DFL, DWT, GtkD с Glade; можно пробовать QtD, и если повезёт, не наткнуться при этом на проблемы с линкером.

В остальном D очень симпатичная среда; а eC или Euphoria к тому же и работают "из коробки".

я другой анонимус, но попробую ответить. Вот в D есть тип variant, а есть и тип auto (аналогичный var в JS или в C# 3.0). Во втором случае это вывод типов, в первом -- костыль в целях совместимости с COM и куча ручных проверок.
Можно попробовать написать, например, сериализацию -- на D2 c typeinfo, __traits и сделать свой reflection API (через вывод типов + object.typeof + CTFE макросы) или на паскале с RTTI и типом variant и сопутсвующими костылями. Общего вида такую сериализацию, когда опросом метаданных класса мы можем сериализовать любой класс, потом добавить в него поле или метод, и сериализация не сломается, продолжит работать, ибо написана в "общем виде", по метаданным.
Reflection API можно и на С++ сделать при желании, используя шаблоны для pattern matching и хак с sizeof члена класса в конечном шаблоне. Конечно, решение в духе наивной С++ сериализации вручную каждого поля мы не засчитываем -- старый код должен продолжать работать при добавлении нового поля.

>Какая часть из этого пишется на дельфи?

С каких пор это Дельфи=Паскаль? Ты случаем не виндузятник?? А вообще лучше уж делфи чем визуал студио

>Про "сетевая часть на дотнете" это ты загнул.

А ты попробуй запустить тот же Баттлфилд2 при снесенном дотнете - синглплеер претЪ а вот сетевая - нетЪ

>fbreader

были как-то проблемы с поиском и копированием текста

>Офисы сами по себе тяжёлые

и не в последнюю очередь благодаря способу разработки

>Ну, можешь вспомнить абиворд

ну если для тебя абивор эталон безглючности то ты и на 98 винде глюков не заметишь

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

кстати, пример с факториалом. На его основе можно показать смысл и полезность ФП, нужность его конструкций, ограничений и этих, как его, tradeoff в реализации. Берём рекурсивное определение факториала n!=(n-1)!*n в качестве программы (1) и преобразовываем эту программу, эквивалентно.
След. образом:
1). Рекурсивное определение, без аккумулятора. Считается через стек, скрытые накладные расходы на глубину стека.
2). Рекурсивное определение с аккумулятором. Можем применить хвостовую рекурсию.
3). Итеративное определение. Аналогично 2) в силу хвостовой рекурсии, но до 3) в этом случае додумается и сам компилятор.
4). Memoizing. Запоминаем K предыдущих значений, "кешируем" вычисление. Наличие list comprehensions в языке нам поможет.
5). Функциональные структуры данных, ленивость вычислений. Можно сказать, что 4) -- это подвид 5), когда используются "серии", ряды, list comprehensions (в 4). В (5) структура данных будет более хитрая, которая будет лениво вычисляться по необходимости. Будут большие накладные расходы (структура данных непростая). Типо как в алгоритме packrat parser: описано преобразование простой структуры данных + хитрого алгоритма в простой алгоритм над данными хитрой, лениво вычисляющейся структуры. Собственно, нам нужна ленивость, вывод типов, система типов.
6). Построение Lookup table. Смотрим, как мы собираемся использовать наш факториал, по call sites. Выясняем, что n=1..100, накладные расходы на структуру в 5) приемлимые. Можем упростить эту структуру, до простой lookup table. Ленивое вычисление значений производится во время компиляции, от языка нужны CTFE, макросы, шаблоны, pattern matching, система типов, multiple dispatch и т.п.

В итоге, одну простую программу можем свести от O(N!) по времени вычисления к O(N) ценой накладных расходов на построение Lookup table. На каждом след. этапе можно программу этого этапа получать автоматически из предыдущей, экв. преобразованиями. При этом мы постепенно уточняем "модель задачи", используя всё больше ограничений (соотв. конструкциями языка), и переносим сложность из runtime в compile time.

С аккерманом, конечно, GADT кучерявее выходит :))

>Кто это и зачем он нужен?

Музыкантам нужен и тем кто себя музыкантами считает. А вообще плохому танцору и яйца мешают и не в языке тут дело. В си/си++ выстрелить себе в ногу куда как легче но когда программирование начинали учить с паскаля средняя квалификация кодеров была куда выше чем сейчас

>С каких пор это Дельфи=Паскаль?

а что это, как не Object Pascal ? ЯзыкЪ ГлаголЪ & ОберонЪ ???

>А вообще лучше уж делфи чем визуал студио

чем лучше? чем грузины ;-) ?
C# очень похож на Delphi, с точностью по Хейселберга :))

>>Офисы сами по себе тяжёлые

>и не в последнюю очередь благодаря способу разработки

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

не, свойство Align и Dock не канает на замену нормального layout manager'а. Берём 32" экран и разрешение 2048x1536, делаем нормальный размер, на весь экран, пробуем ресайзить. Потом переключаемся в 640x480 и повторяем. Переключаем локаль рус\англ, смотрим на надписи на кнопках. Если кнопки в кучку не съехали, форма сохранила пропорции, надписи на кнопках остались читаемыми, сделав кнопки шире\уже -- поздравляем, у нас нормальный layout manager и GUI toolkit (одно вообще-то от другого не зависит, но быдлокодерам обычно лень писать свой layout manager, если его нет готового в toolkit'е). Иначе это поделие 90-х годов прошлого века в стиле "вырви глаз".

//c: zombies 38-foot O_o

>Инструментария под c/c++ действительно больше, это факт. И это весомый выбор в пользу указанных языков для начала серьёзной разработки.

>Но это не потому, что паскаль плох. Просто "так получилось".

а если немного подумать, почему получилось именно так? Почему ядро обычно пишется на Си, всякие биндинги что к Gtk что к DirectX для паскакаля выходят позднее и не полными, почему под него мало нормальных системных библиотек, но много воплей по форумам "дайте мне компоненту с БОЛЬШОЙ КРАСНОЙ КНОПКОЙ" как на qt-apps.com ?
При этом есть ли там Alien FFI, в этом паскакале? А так от него только и останется воспоминаний, что метод вызова PASCAL в Win32 по умолчанию (да и то в Win64 ABI уже не такой).

>так и вижу... мама читает маленькому баллмеру на ночь исходные коды MacOS classic и объясняет сложные места :)

кстате.. перечитывал намедни в сортире win16 api и System 7, на ThinkPascal. Вот почему, почему, паскаль оттудова убрали???

>на твой пример темплейта С++ был дан некий хаскелевский аналог

а я про что и говорю, только паскаль тут за бортом остался... уж так вышло

>> OCaml, Python

>А у окамла со змеюкой конечно же много реализаций и все они вменяемы?

у OCaml в меньшей степени, у Python в большей...

>Вообще не понял смысл этого требования. Зачем Вам более одной вменяемой реализации стандарта?

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

>> C# куда более вменяемый

>критерий вменяемости?

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

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

олололо :) сорри, кэп, не признал...

а то я не знаю... в нём не появилось другого, того что есть в Haskell или Erlang...

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

>А теперь о Си..

А в С++ ещё всё хужее. Там три языка в одном:
1."тупой препроцессор" "ассемблер высокого уровня" Си, без модулей (раздельная компиляция есть... прекомпилированные хедеры, да: #define WIN32_LEAN_AND_MEAN -- и у нас уже другой состав включённого API; а потом добавим сюда шаблоны С++ в духе ATL, WTL и т.п. 3-4 уровня вложенности, дуст, буст, STL -- опа, простая программа собирается полчаса)
2. язык шаблонов. Есть мнение, что это примитивный ФП с pattern matching относительно констант-миксинов (typeclass, sizeof(T) и т.п.). Есть мнение, что это мнение льстит языку шаблонов. Нифига это не макросы и не ФП , по-нормальному.
3. ООП расширение. Которое сделано чуть ли не самым худшим образом. Почему virtual нужно писать, по умолчанию non-virtual -- а не поставить какой-нибудь nonvirtual/sealed, а сделать виртуальными по умолчанию? Какой смысл у невиртуального деструктора? Какой смысл у константного указателя на константу и почему константность нетранзитивна? Зачем нам и ссылки и указатели? Что такое nullable ссылки? В чём разница указателей, ссылок и нормальных символов? Ссылки на auto переменную в стеке -- зачем? Стек или куча? Ссылки или значения? Наследование или аггрегация? Зачем нам 4 типа кастинга: static_cast, dynamic_cast, reinpreter_cast и старый из Си? Что такое Fragile Base Class Problem? Ну и single dispatch, костыли в стиле visitor (хотя это больше вкусовщина)

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

>>эхъ, "перетончил" походу....

>Луркаем "я тебя просто троллил", недотролль вы наш.

"Страницы с названием «я тебя просто троллил» не существует. Создать страницу."

http://lurkmore.ru/Служебная:Search?search=%D1%8F+%D1%82%D0%B5%D0%B1%D1%8F+%D...

ещё замечательные идеи?

>С не-OpenSource тоже ясно: в основном они пишутся с использованием VisualStudio.

трололо, вендузятник детектед... :)

неужели про gcc ни разу не слышали, Eclipse-СDT не пускали?

Хаскель, Хаскель.. Список вменяеняемых приложений на нём -- в студию! Вроде того, что был для Delphi.

FreeArc, Yi, xmonad.. Ещё хотя бы десяток наберётся?

>гы. В FPC вроде уже и шаблоны есть, и перегрузка операций.

ЕМНИП, про перегрузку операций там правильней было бы написать не уже есть, а уже очень давно есть :)

> перечитывал намедни в сортире win16 api и System 7, на ThinkPascal. Вот почему, почему, паскаль оттудова убрали???

это не я, честное слово :)

>перечитывал намедни в сортире win16 api и System 7, на ThinkPascal. Вот почему, почему, паскаль оттудова убрали???

или Вы про сортир??? :)

>Хаскель, Хаскель.. Список вменяеняемых приложений на нём -- в студию!

да фтопку список... язык интереснее для изучения чем тот же lisp... а значит больше людей станут на него попо-часы тратить...

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

>просто чёт я не в курсе что все дрова были на паскале там... и, честно говоря, это очень сомнительно... но я всё ещё жду пруфа, а вдруг не прав :)


Есть браузер http://68kmla.net/forums/viewtopic.php?f=15&t=6767&start=200 . Но он на Think C, вот блин.

http://www.lysator.liu.se/~ingemar/tp45d4/think.html

http://www.fh-jena.de/contrib/fb/gw/gmueller/Kurs_halle/systeme/thinkpas.html

Насколько я помню ядрёное апи классики, там вроде бы соглашения о вызове функций паскалевские были, как в Win16?

>А чем плох Паскаль, можешь сказать?

1. Многословный синтаксис. Почему сдох Dylan, этот лисп с алгольным синтаксисом, прозрачно транслируемый в Си? Да просто он был феерически многословен. Идея модулей и библиотек -- как пакеты в лиспе, а не как в том же паскале или обероне. Типизированные макросы, и т.п.
При этом, о чудо -- многословный синтаксис всё равно короче паскалевского.
2. Интеграция с Native OS API. То есть, с Си, си соглашения вызова.
3. Те проблемы, из-за которых Вирт изобрёл Модулу и Оберон.
4. Мало возможностей метапрограммирования: макросы, хвостовая рекурсия, система типов с выводом. Ну по крайней мере, не сильно хуже Си. Можно было бы ожидать чего-то вроде Vala или eC с генерацией Си кода, какого-то языка, транслируемого в Паскаль -- да вот сюрприз, почему-то не пишут. Хотя я в своё время, например, и формочки на дельфи кодогенерировал.

Больше особых проблем и не припомню. Вкусовщина какая-то, то с синтаксисом, то с семантикой.

На лоре всё как обычно. Программисты меряются языками, а не программами, это как холостяки меряются х...аризмами, а не количеством детей.