Приветствую всех.
Рад, что есть люди, которых интересует перл не только с прикладной стороны.
Со своей стороны хочу сказать, что идеи продвижения Perl уже находят выход.
Приглашаю ознакомиться и, если захотите, присоединиться.
http://moscow.pm.org/
особенно рекомендую подписаться на список рассылки
http://mail.pm.org/mailman/listinfo/moscow-pm/

P.S. Я вхожу в moscow.pm но пишу исключительно от себя

Ммм. Внесу свои пять копеек. Perl - язык, который может спасти весь проект в две строчки, уж не помню где вычитал 

Хм... хочу пополнить их ряды, но что то без опыта работы от года никто не хочет брать :0)
Мне кажется настоящих кодеров(перл-гуру) не только по перлу: вообще - мало))), так сказать... 

Это сообщение отредактировал(а) DaemonSuw - 28.8.2008, 23:13

Уважаемый опытный!
Я так понимаю, что отличить конвертер от компилятора вы не в силах.
(того который конвертит текст в текст, от того, который компилит в машинный код)

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

Например делается проект на перле, но если сервак начинает загибаться, то часть кода перекидывается на клиентов, без дополнительного программирования на яваскрипте ( та же обработка данных бд, поиск в тексте, подсчёт чего-либо) 

Причём код весь писан на перле. и только автоматом конвертится в яваскрипт

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

И вот тогда сервак дохнет окончательно.. подумайте какое количество сетевых вызовов будет между JS и backend ?
Если вы хотите скинуть часть нагрузки на клиента - писать все прийдется руками.. Мы, например построение html делаем на клиенте, с помощью xml + xslt... Можно посмотреть в сторону Google Gears - они вообще все сильно на клиента перекладывают. 



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

Вы усе правильно понимаете 

Вы просто замечательный мечтатель. 

Ну так собсно о том и разговор, конвертер приводит какие-то имеющиеся конструкции к одному знаменателю, к перлу, который модифицируется программистом.

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

Вот к примеру:

Есть сервер. на сервере оборудование, типа осциллографа подключено к компорту. на сервере поднят вебсерверочек и на перле написана интерактивная страничка, которая это оборудование опрашивает и выводит данные.

реализовать хочется на с++  - непосредственная работа с датчиками и скоростная обрадотка данных ( отсеивание лишнего) затем на перле скриптик для отдачи данных и страничка с отображением этих самых данных в динамике.

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

вы представили какая это работа? Даже если писать perl <-> php надо набрать человек по 5  и они должны быть в курсе любых "событий", построить "сообщество" и т.д..
Т.е. как пример, представить что "конвертор" perl <-> php это одна из сборок линукса  , далее структура аналогична - поддержка, разработка как у них. Кто из линуксойдов, думаю, меня поймут и согласятся 

За счет такой структуры как у линуксов, всегда можно получить новый "пакетик", или наоборот поучавствовать в разработке того или иногого компонента.
А вообще конвертор perl <-> php имхо реализуем, даже кем-нибудь из нас , но с простыми скриптами, со сложными вряд ли.

Это сообщение отредактировал(а) nitr - 10.9.2008, 15:02

Это по-моему аццкий труд, тут нужно быть не просто гуру, а еще и "гик"ом. Perl+XML/XSLT+JavaScript+MySQL и то иной раз гикаешься.   

Я согласен, что это не так чересчур просто. А даже наоборот.

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

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

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

И делать - то всё я так думаю можно достаточно просто:

каркас - класс, который принимает регулярное выражение для замены и натравливает его на конвертируемый код и какой-то список, по разным файлам-языкам, в которых эти выражения собраны.

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

где-то я такое встречал 

Языки разные, в программировании больше "исключений" или "непереводимых слов", как это бывает с латинским, английским ;)

Ребята, конвертер исходник -> исходник - это имхо бессмысленная вещь.

Зачем нужен исходик вообще ? что бы его мог читать человек!
Если бы не надо было читать людям, то программы бы распространялись в виде байт-кода и компилированных модулей.

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

Кроме того: Вот есть у нас обожаемый CGI модуль  - с кучей фенек. Есть скрипт который его активно использует. Как конвертить этот скрипт в PHP. только с CGI модулем. А ведь в PHP наверняка есть свои аналоги. И для создания нормального кода нужно использовать их, а не вывернутый наизнанку CGI


А вот написание проекта  на нескольких языках одновременно - идея крайне здравая! Позволяет абстрагироваться от программиста =). Знаешь perl - пиши на нем. PHP ? - не проблема. Да хоть на haskell.  Все это компилируется в один байт-код и работает на одном сервере. Такие решения сейчас активно продвигают - Parrot например, Слышал что пишут кучу трансляторов для java машины, что бы любой язык мог поверх jvm работать.

Потому что они переходят на PHP(раньше, для веба) и Python с Ruby.
Сам раньше на перле писал? теперь же его жутко ненавижу «за испорченное детство».

Подтолкнул он меня в правильном направлении, но потом я увидел более приемлемые для себя инстркументы.
А ведь сразу мне говорили(еще давно): «Вот нахрена тебе перл, Python учи!» А не послушался же и писал на перле, жалею.

Теперь по вопросу: почему мало?
А ответьте на такой вопрос: а какие преимущества дает Perl перед Python и Ruby(ну кроме скорости относительно ruby)?

холивара захотелось ? =)

перл более гибкий, как мне кажется. Множество всяких мелких фич позволяют легко решать сложные задачи.
Но, для программирования на перл - надо быть ХОРОШИМ программистом, что бы держать себя в руках, что бы писать 
элегантные программы, а не спагетти-скрипты.

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

 Конкретику, товарищь, конкретику!

 Как и хуже.
Но зато избегают ошибок эффективнее - это плюс питона.

Вернемся к нашим баранам: плюсам перла. Расскажи их?