Ответ на »сообщение 266« ()
___________________________

Вопрос в том, КАК была получена первая сборка Delphi, с помощью которой и пишется все остальное (в том числе и новая сборка Delphi).  Т.е. как возникло "яйцо", из которого должна появиться будущая "несушка".

Чего-то я не понимаю. Чисто теоретически, компилятор языка можно написать на любом языке, если в нем есть функция вывода в файл. Ведь нужно всего лишь создать exe, не так ли?

А если так, то что особенного в том, что Delphi написана на Delphi?

Далее просто компилятор ПОМ напишут на Delphi, а далее на самом ПОМ можно его же (ПОМ) и развивать.

Ответ на »сообщение 264« (Руслан Богатырев)
___________________________

Небольшая поправка: разумеется, на 6-ти и 7-ми дискетах.

Ответ на »сообщение 255« (panda)
___________________________

Delphi 1 была написана на Delphi 1.

История -- вещь весьма деликатная, вот и в этом конкретном случае далеко не все ясно.

Вот выдержка из интервью Андерса Хейльсберга (март 2005 г., http://dotnet.sys-con.com/read/48156_3.htm

I wanted to write an ALGOL compiler because I liked ALGOL, but my partner said there was a new thing called Pascal, so we should go and check it out. It is a simpler language both to teach and to implement, so we went with that!

As far as Pascal for .NET, Delphi is backwards-compatible all the way back to Turbo Pascal, and it can create .NET code quite nicely! Delphi is what Turbo Pascal became. In fact, the 16-bit Delphi was the actual Turbo Pascal code base!


Предположение напрашивается такое: Delphi 1 делался в несколько этапов и первоначально для его разработки использовался Turbo Pascal.

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

Как пишет Чак Язджевски (Chuck Jazdzewski, июнь 1998 г.), руководитель проекта Borland Delphi, "Имя Delphi было предложено Дэнни Торпом (Danny Thorpe) во время одной мозговой атаки. Мы хотели, чтобы в имени отразились уникальные способности продукта к работе с базами данных, и Delphi как нельзя лучше перекликалось с таким заслуженным именем в этой области, как Oracle, по крайней мере для тех, кому сочетание "дельфийский оракул" о чем-то говорит... Кроме того, рассматривались (и были отвергнуты) такие имена, как Wasabi, AppBuilder, Mango и VisualFoo. Золотым самородком блеснуло имя VBK (Visual Basic Killer), но увы, было тут же отвергнуто бывшим президентом компании..."

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

Ранние бета-версии (которые шли сначала на 6-ти, а потом и 7-ми дисках), носили имя Wasabi. На CD-версиях  были указаны уже имена Delphi и Delphi 95. А имя AppBuilder фигурировало на приглашениях к бета-тестированию продукта.

В то же время в Музее Borland есть документ "Delphi Product Definition. 3rd Draft", написанный Заком Урлокером (Zack Urlocker), который тогда занимал должность product manager для нового продукта Borland. Он датирован 13 мая 1993 г. В нем явно используется имя Delphi.
http://bdn.borland.com/article/0,1410,32971,00.html

Насколько мне известно, первый публичный preview-релиз Delphi 1 появился в марте 1994 г., почти за год до официального запуска продукта, который состоялся в День Святого Валентина 14 февраля 1995 г.

Ответ на »сообщение 262« (Ack_IO)
___________________________
>>> Но как правило самый читаемый и понятный код - "влоб", без оптимизации.
Э-э-э-э... А что значит "влоб"? И кому понятный?

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

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

Я в свое время сильно пободался со своим боссом: она у меня не программист, да к тому же еще и женщина. Но пыталась указывать мне, как надо правильно писать программы. Кошмар! Короче, все нормализовалось после того, как я стал во всем с ней соглашаться, но писать так, как надо, а не так, как требовала она :-)

Ответ на »сообщение 261« (Geo)
___________________________

Ответ на »сообщение 260« (Ack_IO)
___________________________
До тех пор, пока выполнение машинных команд занимает время, отличное от нуля, всегда найдется задача, которая заставит тормозить любой сколь угодно мощный компьютер :-)

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

А вот насчет читаемости кода, так это и была основная мысль моей ремарки:) Но как правило самый читаемый и понятный код - "влоб", без оптимизации.

Ответ на »сообщение 260« (Ack_IO)
___________________________
До тех пор, пока выполнение машинных команд занимает время, отличное от нуля, всегда найдется задача, которая заставит тормозить любой сколь угодно мощный компьютер :-)

А по отношению к оптимизации, хочу сказать две вещи.

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

Второе. Перейдя на Паскаль, я "заболел" рекурсией. Болезнь протекала в острой форме, так как началась достаточно поздно (на Фортране рекурсия невозможна в принципе). Слава богу, достаточно быстро выздоровел. И вынес из этой болезни два принципа:
1. Не надо применять рекурсию там, где ее не надо применять.
2. Не надо избегать рекурсии там, где ее не надо избегать.

Эти два принципа вполне применимы и к оптимизации.

Hi,Уважаемые! Может быть это сообщение и не впишется в контекст разговора, но посмотрев тему думаю будет простительно...
Вот какая мысль меня посетила по поводу оптимизации кода. Вобще говоря само это понятие возникло из необходимости максимально уменьшить размер программы, занимаемый ею объем памяти, во времена "килобайтов" это еще было оправдано, но сейчас по-моему само это понятие должно стать историей. Не зря думаю языки программирования прошли такой эволюционный путь. Конечно, с опытом "красота" кода приходит сама собой, но лучше потратить время на составление грамотного алгоритма, чем думать "а можем можно еще покруче оптимизировать". Собственно чем козыряют многие на C-льники, тем что C изящный, красивый, просто конфетка, ну а о том, что чтобы сконцентрироваться на самой задаче нужно постоянно держать под рукой гору справочников почему-то умалчивают. Короче заканчиваю этот банальный бред :) Delphi forever!!!

Прочитал я примерно половину темы и вспомнил несколько старых как сам мир истин.
Истина первая: люди существа необычные и почему-то боятся того, что не понимают.
Истина вторая: хочешь, чтобы все было сделано хорошо - делай это сам.
Истина третья: жизнь слишком коротка, чтобы писать на ассемблере.
А теперь серьезно.
Несколько лет назад в каком-то источнике я встретил следующую рекомендацию: "...использование оператора Goto не рекомендуется. Если же вы его все-таки используете, то постарайтесь, чтобы весь связанный с ним код уместился на одной странице."
За дословность не ручаюсь - давно это было.
Примечание: не припомню ни одного случая употребления мною данного оператора - необходимости не было. За исключением классического Бейсика, где нет иной альтернативы.
Относительно "вымирающего" ассемблера: имея Athlon XP решил я воспользоваться имеющимися у него командами SSE (зачем добру пропадать) для вычисления примитивного XOR128 для ~1-5 Мб данных - хоть убейте не смог я дурак написать на Object Pascal эту 10-ти строчную функцию - писал на встроенном ассемблере Delphi 7. А что касается создания драйверов из кубиков Лего, то боюсь не дожить мне до этого счасливого момента.
Небольшой пример со стороны. Для написания прошивок для микроконтроллеров (они же однокристальные микроЭВМ) можно использовать почти все - от ассемблера и С++ до Бейсика, наверное и Паскаль можно при желании достать. Так вот я для этих целей использую, смеяться будете, встроенный ассемблер компилятора Бейсик - бесплатно, удобно, ручная оптимизация и где-то за спиной маячит вся "мощь" Бейсика, что удобно при создании наброска прошивки. А клиентскую часть я по-прежнему пишу на Дельфи, невзирая на необходимость сделать вставку на ассемблере или подключить С-библиотеку (чтобы недокументированный WinAPI на Паскаль не переводить).

А теперь итог - каждый инструмент имеет свое предназначение - и Goto, и микроскоп. Не забивайте гвозди микроскопом, не суйте Goto куда не надо, не пишите драйвера на Дельфи (иногда и так делают), комбинируйте различные средства для достижения наилучшего по всем параметрам результата. И быть может тогда наконец утихнут бессмысленные споры между приверженцами С++ и Паскаль, Linux и Windows, и т.д. Помните, что "если звезды светят, то это кому-нибудь нужно".

Ответ на »сообщение 257« (panda)
___________________________
>>> Так речь то шла в первую очередь о инструментальных средах, а отнюдь не о компиляторах
Слова уж очень многозначные. Под Delphi можно понимать только IDE, в можно -- весь пакет, включая компилятор.