LINUX.ORG.RU

Lazarus 1.0

 , , ,


3

1

Вышла новая версия свободной среды разработки для компилятора FreePascal — Lazarus 1.0. В связи с этим важным событием нынешняя команда разработчиков Lazarus хотела бы поблагодарить всех людей, которые когда-либо были вовлечены в его разработку. Особая благодарность основателям проекта, которые начали работу над ним более десяти лет назад, в 1999 году: Клиффу Бэйсеману, Шейну Миллеру и Майклу А. Гессу.

История разработки.

Скачать.

Минимальные системные тебования:

  • Windows: 98, 2k, XP, Vista, 7, 32 или 64 бит.
  • FreeBSD/Linux: gtk 2.8 или Qt4.5, 32 или 64 бит.
  • Mac OS X: 10.4, с LCL только для 32 бит, без LCL можно использовать и для 64 бит.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: Binary (всего исправлений: 2)
Ответ на: комментарий от A-234

Дельфи, насколько я помню, делался компанией Borland как средство быстрой разработки клиентов к различным СУБД, в первую очередь к Oracle. Своеобразная альтернатива жабе

Жаба (если ты про Java) и Delphi появились одновременно, в 1995 году. А вот историю о том, как Delphi 1 чуть не получила имя VBK (Visual Basic Killer), рассказывали сами сотрудники Borland.

до версии 6 (дальше уже не интересовался), были нативные компоненты для postgres и oracle без использования ODBC.

Oracle - да, DOA и ODAC. А компоненты для постгре начали появляться, по-моему, уже позднее (Zeos DBO развивался уже после Delphi 7).

Вообще, в Delphi был заложен гораздо более мощный потенциал, чем многие представляют. Строго типизированный язык, нативная компиляция, GUI-тулкит с высоким уровнем абстракции от ОС (VCL). Очень жаль, что Borland не потянула проект Kylix, архитектура VCL прямо напрашивалась на кроссплатформенное развитие. Очередной пример того, как из-за маркетоидов проиграли технари.

В принципе, имея современную Qt, уже почти не жалко. Вот только, в отличие от Объектного Паскаля, в C++ полностью отсутствует такая штука как модульность, встроенная в язык (не путать с костылями для имитации модульности в виде #include и namespace). И это в больших проектах порою сильно подбешивает.

Хотя и в Объектном Паскале модульность реализована не идеально. Близка к идеалу упомянутая выше «жаба». Но у неё свои тараканы.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Очень похоже, что модульность идеально реализована в Component Pascal, жаль, что язык не очень распространен.

anonymous
()
Ответ на: комментарий от anonymous

Да там удачная концепция, как и в Модуле.

anonymous
()
Ответ на: комментарий от hobbit

Модульность это просто другой способ описания экспорта символов, в С для этого есть static. В паскале модуль имеет interface и его implementation. Все что объявлено в implementation это static. Поэтому не понимаю восторгов по поводу модульности.
Мне поначалу нравился борландовский объектный паскаль, например то что в нем можно было контролировать вызов конструктора базового класса. Но потом пошли всяческие сущности типа class которые отличались от object, что только добавило бардака.

A-234 ★★★★★
()
Последнее исправление: A-234 (всего исправлений: 1)
Ответ на: комментарий от hobbit

З.Ы. Еще мне всегда нравилась возможность создания нескольких деструкторов. Например, у класса описывающего файл в качестве деструктора могут выступать методы «delete» и «close», которые можно было бы вызвать явно. В плюсах такого увы нет :(

A-234 ★★★★★
()
Ответ на: комментарий от A-234

в С для этого есть static

Вы что-то путаете, static не для этого.

Поэтому не понимаю восторгов по поводу модульности.

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

unsigned ★★★★
()
Ответ на: комментарий от unsigned

так, чтобы он не тащил за собой ещё кучу хедеров

в модульных языках это из коробки

Это вовсе не значит что в паскале нет проблем с межмодульными зависимостями .

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

Это вовсе не значит что в паскале нет проблем с межмодульными зависимостями .

Ну, зависимости - это нормально. Плохо, когда импортируешь модуль А, а в пространстве имён оказывается ещё и Б.

unsigned ★★★★
()
Ответ на: комментарий от anonymous

Либо вы толком не пользовались, либо не поддерживали обросший «фичами», как мамонт говном, унаследованынй софт на, к примеру, 7-х дельфях, написанный программиздами, которые не знают, что не вредно отделять UI от базы, не ведают, что такое ортогональность, и «модульность искарпопки» используют не при помощи верхней головы... а по наитию нижней :) Взаимные ссылки, например, сплошь и рядом встречаются (легко превращаясь в циклические при попытке это переделать), визуальное наследование форм, выполненное ректальным способом или использованное не по назначению, версионность компонентов, которые их фанаты тащат в проект, абы какая (а без нее «повторное использование кода» может вынести неподготовленный моск), завязанные на порядок инициализации модули, из-за которых работоспособность софта зависит от фазы луны - после некоторого порога (хотите - меряйте в тысячах строчек кода) задачка по разруливанию зависимостей, которые были изначально, пущены на самотек, перестает быть тривиальной. (Или вы про сферический в вакууме «чистый паскаль» спрашиваете? :))

slackwarrior ★★★★★
()
Ответ на: комментарий от unsigned

Я о том, что без применения головы по назначению, «модульность искаропки» ничего не гарантирует :)

slackwarrior ★★★★★
()
Ответ на: комментарий от A-234

потом пошли всяческие сущности типа class которые отличались от object, что только добавило бардака.

Это спасибо BORLAND. Дедешка Вирт очень протестовал против этого, и сделал просто волшебный по синтаксису Oberon описание которого умещается на двух страницах и компилятор к которому может написать даже школьник.

vada ★★★★★
()
Ответ на: комментарий от slackwarrior

Так где тут проблема модульности паскаля?

Видел не меньше говно программ на C, C++, VB и, даже, asm.

anonymous
()
Ответ на: комментарий от slackwarrior

Это проблема именно головы. При программировании на С++ надо решать еще и проблемы модульности самого языка.

anonymous
()
Ответ на: комментарий от anonymous

При правильном использовании головы не надо :) Потому что это либо использование не по назначению, либо недостаток квалификации (экстенсивное использование антипаттернов проектирования «наитие», «чутье», «метод тыка»)

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

К сожалению никто. :( Есть несколько десятков фанатиков, но Оберон действительно хорош.
Успеха как язык программирования достигает не всегда лучший. Ни кто не скажет что фортран замечательный язык, однако он успешный и живой. Пролог наверное самый лучший язык для работы с базами данных/знаний, но кто им пользуется? Единицы.

vada ★★★★★
()
Ответ на: комментарий от slackwarrior

Тогда C++ вообще шлак!

anonymous
()
Ответ на: комментарий от slackwarrior

в случае С++ для того, чтоб не замечать проблем с модульностью «правильно» можно использовать голову можно только одним способом: засунуть ее в песок и делать вид что проблем с модульностью нет :)

anonymous
()
Ответ на: комментарий от vada

Ни кто не скажет что фортран замечательный язык, однако он успешный и нишевой

Ггг. Сколько опечаток в одном слове :)

slackwarrior ★★★★★
()
Ответ на: комментарий от vada

Да хорош. Еще мне Модула нравиться. Лучше бы её Борланд развивал вместо Паскаля.

anonymous
()
Ответ на: комментарий от slackwarrior

В С++ нет модульности. Есть костыли унаследованные из С.

Зато можно делать забавные штуки вроде #include «/dev/tty»

PolarFox ★★★★★
()
Ответ на: комментарий от anonymous

засунуть ее в песок и делать вид что проблем с модульностью нет :)

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

slackwarrior ★★★★★
()
Ответ на: комментарий от PolarFox

Можно бриться топором. И бензопилой яйца чесать. Но не долго и мучительно.

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

но ведь деланье через жопу - это как раз таки нормальный способ программирования на С++ :)) Женерики через шаблоны, модульность через инклюды :)

anonymous
()
Ответ на: комментарий от slackwarrior

Нет никакого самоустранения. Это проблема проектирования архитектуры ПО. Т.е. это совсем другая проблема.

anonymous
()
Ответ на: комментарий от anonymous

Нет никакого самоустранения.

«Он хотел и не мог!» (с) Эпитафия. Если самоустранения нет, тогда есть пробелы в образовании :)

slackwarrior ★★★★★
()
Ответ на: комментарий от anonymous

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

не могущего в языки с не C-like syntax :)

Паскалист в законе? :) Дай угадаю... 10 лет лагерей за быдлокод?

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

Вы КЭП?

А если серьезно, то подобие модуля можно создать даже на asm-е. Вопрос лишь в трудоемкости. При наличии в ЯП такой синтаксической единицы как модуль трудоемкость снижается по минимально возможной. Имитировать модуль с помощью препроцессора мало эффективно и порождает дополнительные ошибки.

В D, например, модули есть и это не случайность.

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

anonymous
()
Ответ на: комментарий от unsigned

Если у вас пересекаются имена воспользуйтесь namespace, хотя это не единственный способ. А static как раз ограничивает область видимости символа, и в чем тут различие с implementation?

A-234 ★★★★★
()
Ответ на: комментарий от vada

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

A-234 ★★★★★
()
Ответ на: комментарий от A-234

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

anonymous
()
Ответ на: комментарий от A-234

Так и есть. Тупо переносили и переносят фичи с С++.

anonymous
()
Ответ на: комментарий от A-234

Если у вас пересекаются имена воспользуйтесь namespace

Я думал, мы про си. Ну да, в си++ стало лучше, только опять лишние действия. А в других языках модуль всегда образует пространство имён.

А static как раз ограничивает область видимости символа

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

unsigned ★★★★
()
Ответ на: комментарий от unsigned

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

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

A-234 ★★★★★
()
Ответ на: комментарий от anonymous

dcu это скомпилированный модуль, значит вместе с ним я должен распространить еще его интерфейсную часть. Но использовать эту часть я могу только как справочное пособие, на процесс сборки она никакого влияния не оказывает. Если у меня поменялась библиотека (dcu файл) то как программа, его использующая, проверит версию этого файла? Ведь заголовочные файлы участвуют в сборке наряду с библиотеками а тут только библиотеки предлагается использовать. Если я все правильно понял.

A-234 ★★★★★
()
Последнее исправление: A-234 (всего исправлений: 1)
Ответ на: комментарий от A-234

Я не знаю точно, как происходит сборка в паскале. Но в си проблема тоже есть - если рассинхронизировались *.h и *.c, то не всегда об этом узнаешь. Я так потрясный баг однажды словил. Хотя в си++ пропустить такую ошибку, наверно, сложнее.

unsigned ★★★★
()
Ответ на: комментарий от A-234

111

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

anonymous
()
Ответ на: комментарий от unsigned

111

В паскале это невозможно, по определению.

anonymous
()
Ответ на: комментарий от unsigned

Но в си проблема тоже есть - если рассинхронизировались *.h и *.c, то не всегда об этом узнаешь.

Вне всякого сомнения это так. Проблема синхронизации *.h и *.c (вернее *.so, мы ведь исходники не поставляем) оставлена на откуп программисту, что он там себе понаставил и с чем линковать все это добро собрался. Разработчик библиотеки может облегчить решение этой проблемы но не обязан и язык не предлагает никакого решения в явном виде.

A-234 ★★★★★
()
Ответ на: комментарий от anonymous

Так это и в плюсах реализовано в виде манглинга. Но как программист, желающий использовать в своем проекте некий foo.dcu, поймет что именно в нем объявлено не имея интерфейса этого dcu? Или среда (сабж например) позволяет восстановить интерфейсную часть не имея исходников?

A-234 ★★★★★
()
Ответ на: комментарий от A-234

111

Документация нужна вообще-то. Не видел утилит для извлечения такой информации, но она в dcu имеется.

anonymous
()
Ответ на: комментарий от anonymous

Если в dcu визуальные компоненты (наследники TComponent), то можно установить штатными стредствами и published свойства будут видны в инспекторе. Если нет - нужно кинуть dcu туда где компилятор сможет ее найти. Автокомплит по Ctrl+Space работает, но, к сожалению, посмотреть весь интерфейс штатными средствами нельзя, очевидно недоработка IDE. Переносимости между версиями делфи нет - если dcu скомпилирована с использованием юнитов интерфейс которых отличается от интерфейса доступных юнитов, то компилятор выдаст ошибку (может можно вкомпилировать все статически, но я не знаю как).

anonymous
()
Ответ на: комментарий от A-234

Дядюшка Вирт вообще молодец, его Оберон должен был выкинуть борландовское поделие на помойку.

Кроме, того, он лауреат премии Тюринга. Не прислушиваться к мненю человека, получившего компьютерную «нобелевку» можно, но глупо. (Это я для quiet_readonly, которому стоило бы соотвествовать нику.)

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

Так и было. К Паскалу прикручивали фичи, чтоб было «не хуже чем в C++». Как всегда, маркетологи победили технарей.

anonymous
()
Ответ на: комментарий от anonymous

Очень похоже, что модульность идеально реализована в Component Pascal

Ничего удивительно, Component Pascal - это же название, под которым скрывается развитие Oberon 2.

Но говоря о модульности в яве, я имел в виду прежде всего то, что там не просто пакеты, а ещё и иерархически сгруппированные по именам пакеты, что полезно для ОЧЕНЬ больших проектов.

hobbit ★★★★★
()
Ответ на: комментарий от A-234

в С для этого есть static.

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

Поэтому не понимаю восторгов по поводу модульности.

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

Но потом пошли всяческие сущности типа class которые отличались от object, что только добавило бардака.

Это да, маркетологи надобавляли в Delphi явно лишних сущностей.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Ну так у вас все что в implementation понаобъявлено попадает в static, разве нет?

A-234 ★★★★★
()
Ответ на: комментарий от A-234

dcu используется для статической линковки. Для динамической те же самые so и dll. В delphi есть еще bpl для динамического связывания.

anonymous
()
Ответ на: комментарий от anonymous

Лохотрон с подменой типов integer и string при отключенной по умолчанию проверке на выход за диапазон явно лишний.

Napilnik ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.