Зазвичай, після всіх цих реєстрацій вони дають пряме посилання для завантаження ISO або instaler-a.

http://altd.embarcadero.com/download/ra … _1_esd.exe

Cередовище (IDE) вiд борланд та ембаркадер все ховають та ховають, та все нiяк, живе курилка та прикурити даэ )
А от вiзьмiть CodeThypon, та рiзницi не вiдчуэте )))

Як на мене, це трохи попахує некрофілією. До речі, у паскалі так і залишилося оголошення змінних лише перед begin будь-якої функції/процедури і головної програми? Це бісило ще від початку.
Ну і по популярності делфі/паскаль таки пасе задніх, взяти хоча би теги на Stackoverflow, на перших 2 сторінках точно нема ні того, ні другого.

var для одної описової конструкції, розміщуваний між begin та end (як це дозволили робити в пізніх діалектах) — з моєї точки зору, не по-паскалівськи. Хоча, якби описові секції дозволялось робити перед begin усередині блоку, а область видимості оголошених таким чином змінних поширювалась лише на цей внутрішній begin...end, було б цілком логічно.

Про вкладені функції, здається, всі знають. Але вкладені блоки з власними змінними дають такі переваги, як економію імен, розміщення всіх дій в одному місці (не треба бігти на початок функції/програми, щоб подивитись, що робить вкладений блок), можливість безпосереднього виходу з кількох рівнів вкладеності (функції таке можуть лише через ексепшени).

Якщо. Часто сконструювати осмислене однозначно зрозуміле унікальне ім'я складніше, ніж написати код, який під цим ім'ям виконується. Короткі імена недостатньо інформативні, довгі можуть нести більше інформації, але не забуваймо, що це ім'я використовується в двох місцях — якщо в голову прийшла ідея назвати одноразову функцію якось більш осмислено, треба бути обережним, щоб не відредагувати щось не те. Якщо ж одне й те ж ім'я використовується в різних областях видимості, дуже легко зробити помилку й викликати не ту функцію.

Щоб зробити код читабельнішим, для разової дії краще написати коментар, який виконує суто інформативну роль і не може викликати подібних конфліктів.

Економія імен: чим менше іменованих об'єктів у коді, тим менша ймовірність конфлікту імен (напр., якщо ми підключимо модуль, що містить функцію з таким же ім'ям, то ім'я власної функції в програмі доведеться змінювати — уникаючи зайвих імен, ми уникнемо й необхідності робити подібні виправлення) і важче сплутати одне ім'я з іншим.

Вихід із кількох рівнів вкладеності: маю на увазі щось назразок такого:

function f:char;
begin
    ...
    var i: integer;
    begin
        ...
        var c:char;
        begin
            ...
            result=c;
            exit;
        end;
        ...
    end;
    ...
end;

У випадку, якщо кожен вкладений блок зі змінними реалізувати як окрему вкладену функцію, ми не зможемо використати exit у вкладеній функції для виходу з зовнішньої функції.

Це якщо розбивка на підпрограми справді хороша. В іншому випадку, ми отримаємо те, що прийнято називати макаронним кодом, який важко читати через рознесеність по програмі й низьку інформативнісь імен. Крім того, не забуваймо, це паскаль, де спершу йде заголовок функції, потім — вкладені в неї функції, і тільки після того — тіло головної функції (відмічене лише begin'ом, який не є унікальним ім'ям взагалі), тоді як для розуміння загальної схеми роботи програми доцільніше спершу читати тіло головної функції, і лише потім функції, які вона викликає  — якщо вкладених підпрограм забагато, це дещо утруднює навігацію в коді.

Кілометрові підпрограми з коментарями іще гірші. Якщо виникла така ситуація, як ви описали, то треба рефакторити в сторону класів.

Якщо вкладених підпрограм забагато - то це також привід зайнятися рефакторингом. А навігація - це взагалі справа IDE.

Якщо велика глибина, то тим більше треба розбивати. Причому винесенням одних лише підпрограм такому коду уже не допоможеш, треба виносити в окремі класи.

Якщо у вас код з великою кількістю рівнів вкладеності, то з нього стовідсотково можна виділити сутності для нових класів.