Это что - игра такая от «нечегоделать»? Зачем с языка на язык переводить? Можно ведь оформить как модуль и подключить к проекту на другом ЯП...

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

А вообще, как пример - BLAS и некоторые другие математические пакеты, которые с фортрана были переведены на C/C++.

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

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

Только для полноценной статьи одного своего опыта мало.

Хм, а «переводчики» где-то публиковали, как они это осилили? Была ли сформирована методология или каждый раз - как Аллах на душу положит да как левая пятка решит?

Ну, например, что-нибудь с java на приличный ЯП переписать... Или вернуть rosegarden на GTK... Да даже не знаю, у меня своих велосипедных задач по уши, но идей переписывания чего-то с одного языка на другой пока, вроде бы, не возникало .

Что-то мне подсказывает, что там даже не «перевод» был, а написание с нуля (т.к. появились новые алгоритмы). Тот же CUBLAS вряд ли имеет много общего с «традиционным» BLAS'ом.

Ну вот как раз написание с нуля оно как-то не так.

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

hizel'a скастуй, он с питона на жабу что-то недавно переписывал для движка AFAIK.

Я делал, но только маленький проект (около 10k cloc на php + html). Переписывал на питон. Правда не один-в-один, а с рефакторингом — поменялась логика и поправил архитектуру. Да, было это во времена, когда взор пылал и энтузиазма было хоть отбавляй.

Косяка было три.

1) Я не писал тесты для нового кода. В старом их тоже не было.

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

3) Я взялся за эту задачу без наличия должного опыта. Только месяц питона и неделя джанги. В общем, из говна на одном языке, я сделал говно на другом.

Было ли это оправдано? Да, проект до сих пор живой, за пять лет вылизался, оброс кучей функционала (а не костылей), сейчас его поддержка практически ничего не стоит.

Стоило еще упомянть такие детали, как:

1. Ваш опыт разработки на PHP; 2. Фреймворк на PHP, использовавшийся на старом сайте (да, конечно, pure PHP проекты чаще всего очень трудно поддерживать).

А что за проект? В двух словах. Ну предметная область и целевая аудитория.

>А еще я тролль и девственник, так что чем еще заняться-то?

Найди уже себе бабу в конце-концов.

Вот есть, допустим, хрень на перле, а ее бы хотелось перевести на питон.

суксесс лучше получится, если это будет не сферический перевод в ваккууме

Насколько полезно стопроцентное покрытие тестами старого продукта

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

а уж писать тесты на код, который собираешься выкинуть - хммм...

и да 100% покрытие - не надо, 100% - это упороться и не встать и 100% гарантии всё равно нет, в общем, как показывает практика - 70-80% достаточно

Это посмотри.

Переводил с фортрана на связку С++-питон программу 1995 года выпуска по моделированию газодинамики горения (4000 строк и практ без комментариев). Ну чего... фортрана я вообще не знаю, но разобрался с хранением данных в памяти и f2c мне помог;-)

guitar pro, насколько я знаю, перетащили с дельфей на qt

Twitter переписал часть своей системы с Ruby на Scala.

Микрософт при написании Windows в свое время перешел с паскаля на си++. Следы паскаля еще долго оставались с соглашении о вызовах некоторых системных функций.

МО США до черта своего софта перевело на Ада в 80-е годы.

Из собственного опыта. Хотел я как-то перевести мною же ранее написанный небольшой скрипт с перла на питон. Даже полностью переписал. Но перловая версия оказалось чище, проще и понятнее, притом что я понимал только очень небольшую часть перла, которую и использовал. Мое же понимание и знание питона было в разы лучше.

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

Переводил пару своих библиотек с C++ на Java - чтобы отвязаться от оффтопика. Первая библиотека - вычисления, вторая связана с ГИС.

С алгоритмами проблем практически не было, графику пришлось серьезно переделать.

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

А CUBLAS?

Писалось с нуля.

Стоило еще упомянть такие детали, как:

1) Два года

2) CakePHP, где-то с год.

Агрегатор балансов пользователей корпоративных счетов. То есть, товарищи продают корпоративные симки, с как бы своими тарифами, а эта хреновина ведет учет потраченных средств конкретными абонентами. Основная трудность парсинг, иногда с капчами, билинг, рассылка, SMS-гейт, для проведения операций через телефон… Да много уже чего понаверчено.

Эхх.. Кто бы Yum с Python на C переписал...

Сразу надо было на православном С писать.

Эхх.. Кто бы Yum с Python на C переписал...

Ты хочешь поменять еле работающий ПМ на сегфолтящийся? Затык там, как всегда, в io, просто кое-кому надо руки выправить.

>> Эхх.. Кто бы Yum с Python на C переписал...

Ты хочешь поменять еле работающий ПМ на сегфолтящийся?

У меня как раз YUM сегфолтился долгое время... Точнее сам питон...

Хрестоматийная история успеха: Yahoo, после приобретения ViaWeb, переписал неработающее лиспоподелие г-на Пола Грэхема на С++ и Перле.

В настоящий момент Google переписывает с лиспа на нормальные языки «флагманский продукт» приобретённого ими ITA Software.

> В настоящий момент Google переписывает с лиспа на нормальные языки «флагманский продукт» приобретённого ими ITA Software.

Откуда такая информация? Раскалывайся! Никак в гугле работаешь?

> Откуда такая информация?

Исключительно из логики и соображений здравого смысла. В Гугле ведь не дураки сидят? Не дураки. Значит — переписывают.

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

Sodipodi > Inkscape = C > C++

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

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

Это с какого перепугу лисп-код «не поддерживаемый в принципе»?

> большинство лисп-машин живут в своей экосистеме

Ты про что вообще? Где ты видел «лисп-машины» в XXI веке? Все современные реализации Common Lisp прекрасно работают на распространённом железе типа Intel или AMD.

> Ты про что вообще? Где ты видел «лисп-машины»

Имелись в виду рантаймы.

> Все современные реализации Common Lisp прекрасно работают на распространённом железе типа Intel или AMD.

А у них на POSIX API где можно посмотреть?
А на подключение сишных библиотек?

Я понимаю, что у них одна половина компилится в сишный код, вторая половина имеет JIT, и еще есть полтора интерпретатора, но не уметь подвязывать внешние библиотеки или делать это через задницу в XXI веке — себя не уважать.

> У меня как раз YUM сегфолтился долгое время... Точнее сам питон...

А как ты отличал сегфолт Python от сегфолта yum?

> А у них на POSIX API где можно посмотреть?

Причём тут POSIX API? Я ему про Фому, а он мне про Ерёму. Если речь идёт о стандартной библиотеке, то http://www.lispworks.com/documentation/HyperSpec/Front/

А на подключение сишных библиотек?

CFFI

> Причём тут POSIX API? Я ему про Фому, а он мне про Ерёму. Если речь идёт о стандартной библиотеке, то http://www.lispworks.com/documentation/HyperSpec/Front/

Ну сравни это с докой на стандартную библиотеку питона хотя бы.

В том же, если не меньшем, объеме доки у тебя есть работа с файлами, работа с сетью, парсеры нескольких распространенных форматов, работа с командной строкой, работа с самим интерпретатором (интроспекция на стероидах).

Вот мне надо сделать асинхронную работу с сокетом (O_NONBLOCK, select()). Где мне читать об этом в лиспе? Я ведь понимаю, HyperSpec этого не содержит. Зато слово «HyperSpec» написано так каллиграфически, это супермегафича.

>А как ты отличал сегфолт Python от сегфолта yum?
По выхлопу в abrt

> Ну сравни это с докой на стандартную библиотеку питона хотя бы. В том же, если не меньшем, объеме доки у тебя есть работа с файлами

http://www.lispworks.com/documentation/HyperSpec/Body/20_a.htm

работа с сетью

http://common-lisp.net/project/usocket/

парсеры нескольких распространенных форматов

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

работа с командной строкой

http://cl-cookbook.sourceforge.net/os.html

работа с самим интерпретатором (интроспекция на стероидах).

Ты вообще в курсе о существовании MOP, REPL, eval и reader macros? Хотя вряд ли... иначе бы не позорился так.

Вывод: в Common Lisp спецификация языка и стандартной библиотеки содержит базовое минимальное ядро. Остальные вещи выносятся в сторонние библиотеки, или же делаются on-demand за несколько минут, настолько они тривиальны. Только в слабых, неполноценных языках есть необходимость в bloated стандартной библиотеке. Потому что в слабых языках любая банальщина превращается в нетривиальную задачу и требует усилий по её решению.

Вот мне надо сделать асинхронную работу с сокетом (O_NONBLOCK, select()). Где мне читать об этом в лиспе?

Делается за пять минут через CFFI, в чём проблема? Только в тебе.

Зато слово «HyperSpec» написано так каллиграфически, это супермегафича.

Что не так? Это устоявшееся соглашение по написанию технического термина. Ведь свои любимые «JavaBeans» ты тоже напишешь вышеприведённым образом, не так ли?

>> А как ты отличал сегфолт Python от сегфолта yum?

По выхлопу в abrt

Ну то есть никак... Си-программа (yum содержит Си-библиотеки) после повреждения памяти может упасть в совершенно неожиданном месте.

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

Делается за пять минут через CFFI, в чём проблема? Только в тебе.

Проблема в том, что каждый раз их нужно «сделать за пять минут». Их нет уже сделанных один раз и хорошо, чтобы взять и не отвлекаться.

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

Вывод: в Common Lisp спецификация языка и стандартной библиотеки содержит базовое минимальное ядро. Остальные вещи выносятся в сторонние библиотеки

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

Вообще, подход «все можно сделать тучей способов» глубоко ущербен, потому как для 95% программистов он звучит как призыв делать все максимально возможным количеством способов. В том же перле (говорю о том, с чем работаю) CPAN полон говна, потому что модули пишутся абы как, тестируются абы как, используют соглашения, за которые в приличном обществе бьют канделябром.

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

Или, например, есть несколько модулей для одной задачи. 90% из них заброшены. Половина документации посвящена поливанию говном альтернатив. Вторая половина либо написана шестистопным амфибрахием, либо содержит предысторию ни о чем и какую-то беллетристику, либо отсутствует. Кратким постскриптумом в виде особого счастья объясняются костыли (почему-то называемые design decisions) в виде ответа на вопрос: подключил ваш модуль, все остальное сломалось, ЧЯДНТ?

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

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

И даже если реализация нестандартна, то есть хотя бы стандартный интерфейс, которому можно и нужно соответствовать. А в лиспе есть такое? Наверное, можно «легко сделать за два часа», да только никто не делает, потому что всем похеру, потому что удел лиспа ­— академическая среда, где велосипедизм всячески поощряется, а на предсказуемость кладется болт. А если нужно делать _продукт_, а не proof of concept, такое недопустимо.

И вообще, раз речь пошла о лиспе

то стоит почитать, почему в одно время cmucl'у дали пенделя из Debian. Если вкратце, то причина была в том, что новую версию нельзя было забутстрапить из предыдущей, майнтейнер паковал ее руками с помощью бинарных патчей, unrar.rar и такой-то матери. Стали в дебиане автоматизировать сборку всего и вся, тут оно и накрылось медным тазиком.

Это очень ответственный и серьезный подход к разработке ПО, конечно же.

> Проблема в том, что каждый раз их нужно «сделать за пять минут». Их нет уже сделанных один раз и хорошо, чтобы взять и не отвлекаться.

Так в чём проблема-то? Тебе жалко потратить 5 минут на тривиальную задачу? Да ты будешь дольше курить документалово по Пайтону.

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

сопровождается и документирован

«Сопровождение» - это такой процесс, типа аппарата искусственного дыхания, для решений на неполноценных языках. Решение на Лиспе обычно исчерпывающе, и просто работает. К тому же, можно изменить поведение Лисп-библиотеки нужным образом, даже не меняя её исходников. Сюрприз?

Насчёт документации - это такой же костыль, необходимый ущербным языкам. Для кода на Лиспе наилучшей, наиочевиднейшей и наиудобнейшей документацией является сам код на Лиспе.

Только не надо мне заливать, что раз программа написана на лиспе, то она всегда безошибочна и ее безошибочность математически доказана. Хрен там.

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

(куча перлопроблем, не присущих нормальным языкам, поскипана)

удел лиспа ­— академическая среда

Может, тебя просто не пускают в те области, где Лисп востребован и распространён? Подумай об этом.

> стоит почитать, почему в одно время cmucl'у дали пенделя из Debian. Если вкратце, то причина была в том, что новую версию нельзя было забутстрапить из предыдущей

Всё вышеописанное - проблемы Дебиана и его криворуких мантейнеров, причём тут Common Lisp вообще?

Это очень ответственный и серьезный подход к разработке ПО, конечно же.

Каким боком (не)возможность бутстрапа имеет отношение к «ответственности и серьёзности»? Тебе его кто-то обещал, договор подписывал?

> Да ты будешь дольше курить документалово по Пайтону.

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

> Каким боком (не)возможность бутстрапа имеет отношение к «ответственности и серьёзности»? Тебе его кто-то обещал, договор подписывал?

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

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

Хз, может, за это Пола Грэма и его молодую команду из яхи и попросили вежливо?