1. Сухой осадок

Многие в это не верят (я сам не верил), но Perl действительно лучше, чем PHP. Вот одна из лучших книг по Perl: "Стивен Холзнер. Perl: специальный справочник. Санкт-Петербург, издательство "Питер", 2000". Яснее, чем там, нигде не напишут...

2. Несколько слов о PHP

PHP3, конечно, язык хороший... Во всяком случае, синтаксис у него на порядок проще и яснее, чем у Perl. И конструкций/инструкций меньше. Это достоинство. Например, в Паскале конструкций еще меньше, но это не мешает ему называться почти что одним из самых алгоритмизируемых языков.
С чем очень неприятным сталкивается каждый программист, который переходит на Perl? Конечно, с тем, что ошибки скрипта выводятся в log-и сервера, на не прямо в браузер. И нельзя это никак переключить (есть, правда, один стандартный модуль с громким параметром fatalsToBrowser, но в browser он выводит только эти самые fatals, а предупреждения - по-прежнему в логи). В PHP ошибки по умолчанию выводятся туда же, куда и обычные данные.
Следующее мерзкое свойство Perl - постоянно выдавать 500-ю ошибку. За подробностями, якобы, обращайтесь к логам сервера. Ага, сейчас... Причем эта самая 500-я ошибка выдается из-за того, что какой-то print проскочил раньше вывода заголовка "Content-type". В PHP никто не проскочит раньше его. Потому что там отслеживается: если что-то печатается, а заголовка нет, то вначале передается именно заголовок "Content-type".
Теперь насчет управления переменными. В PHP любая переменная начинается с "$". Никаких там мерзких "@", "%", "&" и других символов для переменных разных типов. Они - пережитки Юниксовского shell-а (кто не прочувствовал, посмотрите установочный файл Apache, написанный на csh - он занимает около 100 Кб). Зачем они интерпретатору? Он ведь и так знает, кто есть кто.
Обработка форм. Пожалуй, в PHP она работает почти идеально. И быстро. И с поддержкой массивов (правда, только одномерных). А также с поддержкой закачки - теперь для организации upload-а не нужно делать вообще ничего - сиди и жди, пока файл не придет, а потом забирай его из временной директории.
Базы данных. Чтобы обращаться к базам данных, нужно использовать модули, многие из которых имеют просто феноменально большой размер, что, конечно, сказывается на быстродействии. А в PHP поддержка БД встроена. Имеется практически полный набор функций для работы с почти всеми известными человечеству базами данных. На все случаи жизни.
Если душе хочется универсальности, то очень быстро отказываешься от того, чтобы выводить страницы при помощи скриптов через оператор print. Например, так:

print "Content-type: text/htmlnn";
print "n";
print "Hello!nHere is the numbers: ";
for(my $i=0; $i<10; $i++) { print $i; }
print "";

Этот вариант, конечно, не лезет ни в какие ворота. А что если нужно сделать редизайн? Лучше сразу повеситься. В то же время, в PHP можно комбинировать обычный html-такст с кодом скрипта. Например:

Hello!
Here is the numbers:
<?for(my $i=0; $i<10; $i++) { print $i; }?>

Я думаю, достаточно перечислять, чем PHP лучше Perl-а. Интереснее будет посмотреть, где он хуже. Итак...
Удивительная медлительность. Так, пустой цикл в PHP выполняется в 70 раз медленнее, чем в Perl. Регулярные выражения работают в 10 раз медленнее. Строковые операции - примерно в 5 раз медленнее. И как только они умудрились так написать?..
Вообще никакой поддержки модульности. Правда, ее можно все-таки организовать вручную, и потом работать с "модулями", почти как в Perl. Но получается очень медленно. Основное время выполнения скрипта оказывается затраченным на подключение модулей.
Немного недоделанный интерпретатор. Так, если функция возвращает массив, мы не можем обратиться к его, скажем, пятому элементу при помощи Func(10,20)[5] - только через промежуточный массив. Но, кстати, это не так уж и обременительно.
Пожалуй, все. Всего два крупных недостатка, но каких...

3. О Perl

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

Перенаправление ошибок в браузер - 100% как в PHP
500-я ошибка побеждена. Теперь все работает в точности так же, как в PHP.
Обработка форм - можно добиться возможностей, которые PHP и не снились. Причем относительно простыми средствами. Кстати, насчет стандартного CGI.pm - ужасный слон. Я поковырялся в нем, хотел понять, как там устроена обработка закачки. Лучше бы я этого не видел... И потом, вам не кажется, что 130 Кб кода на Perl (размер CGI.pm) - несколько чересчур?..
Сериализация реализуется довольно несложно, причем можно даже сделать ее совместимой с PHP-шной. Можно также воспользоваться модулем Storable, который работает очень быстро.
Вставки Perl-кода прямо в html-документ. Эта возможность, являющаяся ключевой в PHP, на Perl реализуется несколько сложнее, чем все вышеперечисленные. Но реализуется, причем, опять же, с большими возможностями, чем имеет сам PHP.
Итак, вывод: Perl по всем параметрам (ну почти) лучше, чем PHP. Он в несколько раз сложнее, это точно. Неоправданно сложнее, вот что обидно. Но привыкнуть, я думаю, можно. Поэтому, как только PHP-шная горячка несколько спала, впереди забрезжил свет. Свет языка Perl.

13 июня 2000, 16:52
Дмитрий Котеров
Лаборатория dk, ©2000

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

Кстати, с точки зрения маркетинга клиент вообще никогда не должен видеть сообщений об ошибках от интерпретатора php (и с точки зрения секюрити это тоже очень плохо), так что запись ошибок в лог можно смело записать в преимущества Перл!

В web области, по моему, основная причина это то, что mod_perl, в отличие от mod_php, моногамный в отношении web приложений. Такая архитектура mod_perl - это сила (для специалистов) и одновременно слабость (для новичков и для маленьких приложений).
Многое остальное вытекает из этого.

Я не погружен сейчас в mod_perl, и не понял семантики выражения
"mod_perl, в отличие от mod_php, моногамный в отношении web приложений"

Архитектура mod_perl такова, что в каждом конкретном рабочем процессе Apache создается лишь один единственный экземпляр интерпретатора perl. Соответственно perl модули загружаются один раз на протяжении всех жизни Apache процесса.

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

А когда у разработчиков руки растут не из того места или еще не хватает знаний, то под mod_php писать можно, а вот под mod_perl...

Поэтому массового хостинга под mod_perl нет, в отличии от mod_php. А где себя пробуют новички? Правильно, на бесплатном хостинге. А там mod_php и perl, запускаемый как cgi. Отсюда и появляются утверждения: "php на порядок быстрей perl сам проверял: Hello Word у меня на сайте выполняется быстрей!" :-)

Так что можно сказать, что perl и php в этом отношении (mod_*) в разных категориях.

Про Python - не вкусе, знаю, что рекомендуют не mod_python, а fastcgi использовать. Значит для массового хостинга ситуация аналогичная perl. Хотя, по моему, пассионарность Python сообщества выше, чем perl, да и пиаряться они лучше.

Так, что php ближе к новичкам и, поэтому более притягательный для них.

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

Вспомнил APL языки - у них подобная проблема: уровень вхождения очень высок.
Где-то была хорошая статься на тему: почему молодежь не использует APL языки.

Я лично не сравнивал производительность Python и Perl, но основная идея вот в чем: архитектура виртуальной машины Perl, насколько я знаю, стековая аккумуляторная (рабочий регистр один и параметры передаются через стек и переменные хранятся на стеке, который фактически работа с памятью), у Python параметры при возможности передаются не через стек а через регистры и хранятся соответственно тоже в регистрах, что есть быстрее.
У современных процессоров регистров очень много (даже у x86 их по-моему 16 штук, а у рисков 64 нормальное явление, а встречаются и 128) и поэтому производительность Python в разы превосходит Perl.

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

И еще супротив Python стоит отметить, что в Python есть встроенный недостаток - использование отступов для ограничения блоков опасно, поскольку требует чтобы весь код одного проекта редактировался с одинаковыми настройками количества пробелов в одном шаге табуляции у всех программистов, а у Perl5/Perl6 такого недостатка нет.

На самом деле мы несколько усложнили. Реально у Perl есть очень существенные достоинства, которые намного проще и видны лучше чем нюансы mod_perl.

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

Например аналогичная конструкция не будет выглядеть в PHP настолько-же понятно и выразительно:
($a,$b)=($b,$a);

Или вот буквально сегодня вспомнил:

sub listdir
{
  %defaults = (match=>"*", cols=>1, sort_by=>"name");
  %arg = (%defaults, @_);
  # собственно код функции
}
listdir(cols=>4, page=>1, hidden=>1, sep_dirs=>1);

Если кому не понятно, смысл данной конструкции в том что я именую параметры функции, благодаря чему я могу их передавать в любой последовательности.
Кроме того, в самой функции используется удобный механизм Perl для манипуляции данными: если преобразовать хеш в список пар "ключ-значение" (это происходит автоматически если в левой части выражения списочная переменная: @arg = (%defaults) ), можно в конец добавить новые пары с новыми значениями и затем опять загрузить в хеш, и таким образом красиво реализуются параметры по-умолчанию.

Совсем немногие языки имеют настолько красивые средства, и опять-же, конкретно в PHP такого точно нет.
Хотя конечно правда, порог вхождения позволяющий полноценно использовать свойства Perl заметно выше PHP, а использование Perl как простого заменителя Си конечно малоэффективно.

У Perl только один недостаток: сложность его синтаксиса (читай гибкость синтаксиса и языка как такового :) ), по сравнению с тем же питоном, не говоря уже о пыхыпы... Специально как-то гуглил на эту тему, так многие пхпшники писали, дескать, слышал, что Perl могуч, но попробовал и не смог -- пхп проще. Но то оно и Personal Home Page...
Насчет производительности тоже как-то искал, мало вразумительного, но для себя уяснил -- Perl если не превосходит Питон по производительности, но по крайней мере, не уступает ему...
А вот питоновые отступы, это да... засада...
Ну и напоследок о системном администрировании... Поадминьте-те ка на Питоне. Хороший язык, не спорю, но по сравнению с Perl в этой области и рядом не стоял... А я админ, мне нужно... :)

дадада. скорость написания простого и встроенные регвыражения. такого нигде нету)
плюс много модулей.

меня например очень расстраивает отсутствие нормального IDE под Перл (Win32, ес-сно :) )... пользуюсь programmer's notepad с дополнительной настройкой Tools.

я вот не веб-девелопер, поэтому мне тяжело судить, переходят ли с Перла на что-то другое веб-программисты. системные администраторы и программисты по ходу никуда с перла пересаживаться не собираются)

Когда-то, может год назад или два, когда из-за спора кто-то из разработчиков pattor получил вкусным тортом в лицо на какой-то конференции за то что на некоторых тестах python на своей виртуальной машине оказался быстрей, чем на parrot, и еще одним тортом на бис за деньги, которые пошли в фонд perl сообщества, в рассылке parrot-internal подробно обсуждалось эта проблема, а также преимущества python.

Точнее, обсуждалось и до этой конференции. Мужики за 2 недели спохватились, что не сделали одну оптимизацию, необходимую для python. Не успели, а может и не спешили - торт, это такое тактичное дело.

Что-то я сильно уклонился в сторону. Так вот. У питона производительности выше, когда код оперирует массивами и хешами, а не ссылками на них. Например, @foo = @too. Тут Python затыкает perl5 за пояс, потому что в первом есть COW (копирование при записи), а во втором нет. В parrot - есть. В других случаях скорость не так важна. Тем более, что в большинстве случаев скорость больших приложения определяется архитектурой и базой данных.

Впрочем, мы сильно уклонились в технические вопросы.

На ActiveState есть бесплатный KomodoEdit. Я скачивал для Линукс, но есть и под Венду. На первый взгляд понравился. Это гораздо круче, чем просто подсветка синтаксиса и расстановка отступов, которые есть в том же Crimson Editor

Поддерживаю. KomodoEdit весьма неплох. Я использую его уже больше 2 лет и переходить ни на что другое не собираюсь:)

Так чего там с Wiki? :)
- Я так смотрю, что главным недостатком перла является малая проинформированность о нем.

Бытует мнение, что perl - это writeonly язык.
Действительно, тут упоминалось, что синтаксис языка очень краток и выразителен.
Часто за этим скрывается ловушка - все записано насколько кратко и без комментариев, что постороннему без документации очень сложно разобраться. Новичков это отпугивает, но когда привыкаешь очень сложные вещи делать просто (кратко),
то действительно вместо того, чтобы разбираться как одну задачу переделать в другую иногда проще реализовать все с нуля.
Да и рефакторинг никто не отменял.
Переписывание заново - это и есть рефакторинг.
Все зависит от задачи, естественно.
Но если задача действительно заслуживает библиотечной реализации - для этого есть CPAN и очень гибкая и красивая реализации объектно ориентированного программирования.

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

а вот чего бы я хотел - это чтобы IDE подхватывала имена переменных и могла их выдавать по ctrl+space. притом без необходимости ввода $,%,@.

эх).

А почему бы не попробовать Komodo IDE?
Реальное ускорение процесса налицо!
Ну единственное, что русифицировать бы лицо IDE,
ну, не комфортно, как-то, когда не на родном языке!

Хотя конечно, на мой взгляд - все вышеперечисленное
не так удобно, как должно быть! Во первых не хватает
кросс-справки по Перлу. Жутко не хватает! Во вторых
нет изначально сделанного генератора синтаксических
конструкций - типа, метапрограммирование в IDE -
построение по шаблону, с указанием параметров - на
выходе готовый код на несколько сотен строк.

Еще один вариант IDE - Emacs!!! Идеально!
Но - необходимо владеть Лиспом, настроить окружение,
всяческие фенечки-рюшечки необходимые для комфортной
работы - очень большой объем подготовительных работ!

И вот такой вопрос - нет ли "редактора" базирующегося
на Перл-коде (типа Emacs на Перле)?

Еще вариант редактора - Notepad++, очень даже неплохо!

Кстати - мне очень нравиться IDE в SciLab-е, то бишь -
SciPad, написанный на Тикле. Приятная софтина! Есть
возможность расширения, и т.д., контекстная справка и пр.

По поводу производительности Перл - не нужно путать
привычность работы и производительность готовых на выходе
систем. Реально все зависит от алгоритмов, и производител.
Перл-кода и кода на С++ одинаково!!! Как бы это абсурдно
не было на первый взгляд! Кроме того, ну найдите мне хотя
одного толкового кодера на С++ - не найдете! Большинство
- ремесленники не имеющие представление даже о самых
простых, базовых понятиях С++! На фига такое надо! То что
есть в запасе С++ фантастика возможностей, но для кого!?
То-же самое и с Перлом, есть соображение или готовые для
использования модули - вперед и с песней. А по количеству
готовых для использования модулей Перл просто лидирует!
Кроме того, Перл очень сильно меняет образ мышления
разработчика, это большущий плюссс (Перл++) однако;)

mm.. Komodo IDE вроде платное.
английский язык любой программист сейчас просто обязан знать и относиться как к родному. Notepad++ после получасовых настроек по функционалу почти дошел до pn2).
да.. и последнее.. если ты не видел толкового кодера на си++, это не значит, что таковых нет.

Re "mm.. Komodo IDE вроде платное."
Да, и все Мы живем Америке и получаем по пять штук!
Дуракам закон не писан!
По поводу языка - может быть Вы читаете книжки на
английском, если есть перевод на русском?! Понимаю,
порой лучше прочитать на агл., потому что, перевод
бывает не совсем адекватен. Разговор о том, чтобы сделать
адекватный перевод под себя! Как удобно, не более!
Ну и конечно мы, живем в русскояз. окружении, потому и так!
Что есть pn2) ?

И еще раз по поводу Комодо, думаю некоторые
немного не договаривают!

Ну, я не думаю, что нужно быть столь критичным.
Насчет Komodo IDE - да, платная штука, но все равно пользуется спросом. Но есть Komodo Edit(http://activestate.com/Products/komodo_ide/komodo_edit.mhtml) - Komodo Edit is a free, open source editor from dynamic language experts.
Я сам использую именно Edit. Да, там нет debugger-а, встроенного proxy-сервера и многих других вещей, что присутствуют в IDE, но так и сам редактор достаточно неплох.

Тут вот, ковырялся с Атмеловскими микроконтроллерами
обнаружил - pn - Programer Notepad for WinAVR !
Ну наверно pn это круто! Еще лучше было, если
можно было прикрутить Перл к микроконтроллеру,
в принципе к АРМу можно, но много вопросов.

Я знаю как прикрутить Перл к практически любому микроконтроллеру. Но не вижу смысла в Перле без библиотек, а это значит что нужно делать достаточно полноценный компьютер (пусть и очень медленный), с ОЗУ мегабайтов хотя-бы 10 и с внешней памятью - например флешкой, хотя-бы на 50 мегабайтов.
Естественно, в таком случае нужно делать если не ОС, то хотя-бы монитор, написать на асме что-то вроде libc для такой машины ((m)alloc, io, process management), чтобы можно было писать на простом Перле (и использовать модули со CPAN), а не на как-то по особому, хотя безусловно могут быть варианты..

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

Очень интересная тема, согласен с вышесказаным.
Есть вопросы к аппаратной части, как реализовать,
где покупать платы и и т.д.

ну даете) перл к микроконтроллеру... не то русло.
pn2 да, с AVR тоже используется(так я о нем узнал :) )
но в основном его можно настроить под любой язык с полпинка, что я и сделал.
и до того удобно, что не могу оставить его в пользу вроде бы более продвинутых notepad++ и comodo edit.

Ну тут вобщем как и с любым сложным устройством - нужно сделать один достаточно хорошо повторяемый экземпляр и документацию для повторения, а уже потом тиражирование относительно недорого.
Скажем, я встречал прикидки достаточно опытных электронщиков, что на базе avr32 можно сделать linux-хост стоимостью около 15-20$ (это именно плата, на которой будет работать линукс).
Плюс есть варианты сделать специализированный компьютер на базе FPGA (программируемая логика) или даже на простой логике (на логике получается 50-150$) или на более простых микроконтроллерах (вообще может получиться 10$).

Да, на avr32 или FPGA безусловно нужно изготавливать печатную плату, а на дискретной логике или на простом микроконтроллере можно сделать и на макетной плате или даже навесным монтажом.

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

И я не разделяю скепсис по поводу реализации перл "в железе", как минимум потому что аналогичные вещи делались и делаются: в 70-е годы были коммерческие Лисп-компьютеры, сейчас существуют образовательные проекты "полужелезной" реализации Java, причем как в 70-е, так и сейчас язык существенно быстрее выполнялся на специализированном железе, чем на железе общего пользования.
Мало того - современные ОС унаследовали очень многое от Лисп-ОС, которые были разработаны для тех самых Лисп-компьютеров.

1) не случайно начальным словом расшифровки акронима
Perl является слово Practical - практический.

2) программы на Perl создаются с меньшими непроизводительными
затратами на борьбу с различными аспектами технологий
программирования.

3) Perl - объединяет целую группу стандартных Юникс тулов.
А именно - AWK, grep, sed, sh, bash ...
При этом нет необходимости знать особенности использования,
а также обойти ограничения этих многочисленных средств.
Причем все эти возможности реализуются внутри Perl-ядра.
Можно сказать: Perl - это Целый Мир!

4) Perl - это компилирующий интерпретатор! Программа вначале
полностью компилируется, преобразуется в объектный код, и
лишь затем выполняется. Из этого - синтаксические ошибки
выявляются сразу на начальном этапе работы программы, код
выполняется быстрей, чем при чистой интерпретации. Модули
подключаются исходя из потребностей - что также увеличивает
манёвренность конечной системы.

5) Мультипарадигма Perl. Одна и та же задача может быть решена
несколькими способами - кому как нравится. Результат -
практическая работа с задачей, а не занятия по проектированию
(попробуй не проектировать на С++ - потеряешь время и деньги!)
Кроме того, есть решения труднореализуемые в других языках.
К примеру - кто согласится писать самомодифицир. систему на С++
(даже на Питоне!) - бред полный - разумно невозможно. С этим
справится Лисп - главная проблема которого - чрезмерная сложность
спецификаций на язык. Есть конечно и Хаскель - это рульно, но уж
больно однобоко получается и в этом случае! Аспект использования
Perl в качестве инструмента для AI - пока недооценен! (Зря!)

6) Главная проблема Perl - отсутствие сколь либо понятной документации,
методик использования. Та, что есть - не сильно конкурирует с
доступностью. Ещё, в следствии того, что основная масса людей
работает с Явой и С++ имеем проблему - недостаток людей.
Оставшаяся масса работающих на Perl - не в состоянии быстро
решить все вопросы. Если Perl стал основным языком какой-либо
корпорации - это изменило ситуацию кардинальным образом. Сравните
денежный поток идущий в сторону С++, Явы и др. платформ, и в сторону
Perl - практически очень мало! (очень удивлен, тем что некоторые
корпорации используют экстравагантные решения вроде Objective C!
Корпорация которая могла бы использовать Perl - ABBY(R). )

7) Ещё один конкурент - Питон. Да, конкурент! Но где мультипарадигма?!
Нет! Питон - язык для людей, а не для автоматизированной системы.
В этом главный недостаток! Система сама не в состоянии заниматься
проектированием! Да, человек может это, но многие ли утруждают себя
этим?! Гибкость Perl - главное достоинство, которое выше всех
преимуществ Питона и др. подобных систем. Гибкость эта нужна прежде
всего не для людей, для ядра автоматизированной системы. Питон
слишком туп, Ява - тормоз, остальное не в счет! Кроме того, прогресс
развития Perl в значительной мере налицо, и впредь будет большим!

Это далеко не всё что хотелось обсудить и прокомментировать.

Хорошо-бы конкретизировать, что именно хочется делать - для многих вещей можно даже готовые демо-платы купить и там даже вероятно обойтись без пайки (пару контактов зажимами-крокодилами прицепить а все остальное на таких платах уже есть.
Для более специфичных и интересных вещей, демо-платы дороги, соответственно, есть смысл платы либо заказывать, либо самостоятельно делать, ну и конечно паять/отлаживать - там сам процесс дебага еще повеселей чем в программировании, потому что не всегда понятно, программа виновата или в железе баг.

Кстати, есть очень интересные платы, например OGD (к сожалению очень дорога): http://wiki.duskglow.com/tiki-index.php?page=Open-Graphics
вероятно, еще интереснее, но еще дороже, есть FPGA ускоритель для двухпроцессорных AMD - там тоже большая FPGA (в которой можно реализовать несколько процессоров), и она подключается через процессорную шину infiniband, то есть имеет быстрый прямой доступ к шине и к памяти машины.
Есть платы попроще - минимальная плата с FPGA возится в украину где-то за 150$, и на этой плате можно реализовать процессор, но памяти в такой плате нет совсем, то есть надо еще делать (покупать?) плату с памятью, есть даже проект OCM (One Chip MSX) - там вроде за 250$ (без учета доставки сюда), стоит FPGA и память, и на FPGA реализуется процессор, музыкальный сопроцессор и видео.

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