LINUX.ORG.RU

К специалистам по паралленым вычислениям (языкам) - детский вопрос - что есть в природе в этом стиле (+)?


0

0

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

Итак, какие типовые средства разхработки параллельных приложений есть (из тех что я знаю:-))? Всякие шреды-форки и т.д., но общая методология следующая - пишеться функция (или как то оформленный кусок кода), которая запущаеться в отдельной нити (процессе или чем то еще). И этот кусок кода каким то образом жениться (взаимодействует) с другими кусками, что то разумное деланет. Я говорю сейчас о общепринятых технологиях, не затрагивая таких мостров как НОРМА, DVM, и т.д.

Теперь с-но мысль. Чего бы хотелось (речь идет о питоне)? Хотелось бы написать типа напр:

p1 = new_thread()

p2 = new_process('alpha.mycompani.ru')

p1.a = (1,2,3,4,5)

p2.Import('mymodul')

p2.a= p2.mymodul.A()

b = lambda i : i*i

p2.a.run_super_calc(b, p1.a, p2.mymodul.super_calc_init1())

и т.д. В общем идея - можно создавать новые процессы, нити и т.д. (неважно кого, назовем их пезантами)))). Каждый пезант имеет свое пр-во имен. Можно просто писать код, можно в код вставлять инструкции для отдельных пезантов. Гарантируется что сетевой трафик будет минимизоравться. Передача исходников м-ду хостами происходит автоматически. ИНструкции для пезантов не блокируют основную нить программы, даже если пезент занят, а становяться в очередь. Есть средства барьерной синхронизации, типа sync(p1,p2), ну и тут много всякого разного моно придумать.... напр продолжение работы пезантов при закрытии родительского процесса, с возможностью восстановления соединения при запуске нового родительского процесса)))

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

Про безопасность я пока не думал:-)

★★★★★

"Какой удар со стороны классика"...

До тебя всё изобрели. В Лиспе это - очень стандартный шаблон - message passing с обменом исполнимыми s-выражениями. В Erlang это - основа языка. На Occam при желании реализуется. В одном из вариантов этот подход зовётся agent based programming.

В общем - хочешь заниматься параллелизмом - начни с теории. Изучи пи-исчисление...

vsl
()
Ответ на: комментарий от vsl

Я уже им занимаюсь, правда оно со своей спецификой:-)

Ок, спасибо.

А что то подобное для питона есть?

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

> А что то подобное для питона есть?

В питоне коряво выглядит динамическое формирование исходного текста (была речь про передачу исходных кодов)

Если передавать только код (байт-код)... Тогда надо "научится" по коду и прочим атрибутам строить функции. Я не смог. Плюнул и пошел ковырять Lisp :))))

P.S. Или я не в тему?.. :)

anonymous
()
Ответ на: комментарий от anonymous

А в чем именно его корявость? и зачем его формировать динамически? Передал сам .py модуль, проимпортирвоал... как раз управление импортом там очень гибкое.

Вообще ИМНО питон практ идеальное (из известных мне императивных ОО языков) средство для подобных игрищ, за счет встроенной сериалиазации и гибкости. Любой объект пиклишь, пропихиваешь через сокет, восстанавливаешь. Передача исходников для восстановления тож не оч. проблематична, сейчас как раз потихонечнку ваяю проект к-й автоматом пихает импортируемые модули под CVS, дальше дело за сетевым репозитроием)))

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

> Любой объект пиклишь, пропихиваешь через сокет, восстанавливаешь.

На той стороне уже должны быть готовые классы, объекты которых ты запиклил.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

Нефига. На той стороне должны быть исходники содержащие классы (функции) объекты к-х я запиклил. Исходники импортируются при анпикле про мере необходимости. Если одноименный исходник уже проимпортирован то класс (функция) беруться из него.

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

Питон крайне далёт от идеала. Лисп лучше - у него сериализация гораздо естественнее, AST ортогональнее.

vsl
()

Вообще говоря для параллельных вычислений лучше всего действительно Лисп и ФОРТРАН 95 (скоро и стандарт 2003 поддерживаться будет полностью). Но Ф. имеет свою специфику, хотя сейчас он имеет сильный аппарат ООП и высокую надежность для параллельных вычислений.

popov_da
()
Ответ на: комментарий от AIv

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

vsl
()
Ответ на: комментарий от vsl

Остапа понесло......

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

Я напр. знаю класс задач где С++ с питоном дают весьма неплохие результаты. Не знаю как используемые там методы распаралеливания соотносятся с пи-исчислением, но тем не менее все работает и задача шкалируется почти со 100проц эффективностью на 1000 процессоров.

Вас не затруднит дать какую нить ссылку, где на доступном уровне рассказано про то самое пи-исчисление?

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

Фортран вообще тут не при делах ни разу.

Лисп - ровно настолько, насколько удобна его сериализация (и, соответственно, реализация обмена сообщениями).

http://en.wikipedia.org/wiki/Pi_calculus

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

vsl
()
Ответ на: комментарий от vsl

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

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

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

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

:)

WFrag ★★★★
()
Ответ на: комментарий от WFrag

полностью согласен с пред. оратором!

Любай программ переводиться в машинные коды, что теперь токо на асме писать?:-)

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

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

Банальностиж пишу наверное:-)

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

> полностью согласен с пред. оратором!
>
> Любай программ переводиться в машинные коды, что теперь токо на асме
> писать?:-)
>
> Языки программирования по моему и делаются для того, что бы описывать
> задачу не в терминах машины а в терминах реального мира, самой
> задачи... а уж как это потом натягиваяться на архитектуру машины и
> т.д. - дело разработчика языка.

Ты несколько путаешь фундаментальность математическую и
фундаментальность в смысле близости к железу.

int19h ★★★★
()
Ответ на: комментарий от WFrag

Не передёргивай. У МТ есть одно мерзкое свойство - её код - write only. Ты не можешь из него делать выводы. Из лямбды или пи - можешь. Соответственно, возможностей оптимизации и доказательства у тебя - вагон.

Ну а по теме - предложи параллельный язык, который ты считаешь хорошим, и мы тут посмеёмся. Ок?

vsl
()
Ответ на: комментарий от AIv

Пи - как раз не далеко от предметной области уходит. Ты можешь предложить более абстрактную мат. модель параллелизма? Не можешь...

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

Да, и ещё - твой Питон - полное убожество. Почему - я уже объяснял, а ты - не понял. Язык с таким говённым AST, язык без нормальных замыканий, язык, настолько сильно неортогональный - идёт туда, куда ему и дорога - в мелкие детские скриптики.

vsl
()
Ответ на: комментарий от vsl

>Не передёргивай.

Да просто доказательство мне показателось несколько натянутым...

Против пи-исчисления ничего не имею - может это действительно лучшая модель для описания параллелизма.

>Ну а по теме - предложи параллельный язык, который ты считаешь хорошим, и мы тут посмеёмся. Ок?

Erlang :) Я его не знаю, но насколько я понял - там пи-исчисление в чистом виде.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

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

Для Питона это - нереально, он всегда будет с костылями... Фортран - тем более - НЭНАВИЖУ PVM И MPI!!!!!!

vsl
()
Ответ на: комментарий от vsl


> Да, и ещё - твой Питон - полное убожество. Почему - я уже объяснял, а
> ты - не понял. Язык с таким говённым AST, язык без нормальных
> замыканий, язык, настолько сильно неортогональный - идёт туда, куда
> ему и дорога - в мелкие детские скриптики.

Бог с ним, с питоном, но вот что такое AST? =)

int19h ★★★★
()
Ответ на: комментарий от vsl

Re Re: Re: Re: Re: Re: Re: Re: "Sun необходимо приобрести Red Hat или Novell"

>Ну а по теме - предложи параллельный язык

NESL, ZPL, Erlang, Charm++ сходу всех не упомню ;)

ЗЫ: о прямизне костылей пускай теоретики рассуждают, а практики берут OpenMP,MPI,PVM и чихали они на радиус кривизны этих костылей ;)

sS ★★★★★
()
Ответ на: комментарий от vsl

Ой-ееееее.......

>Пи - как раз не далеко от предметной области уходит. Ты можешь >предложить более абстрактную мат. модель параллелизма? Не можешь...

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

>Да, и ещё - твой Питон - полное убожество. Почему - я уже объяснял, а >ты - не понял. Язык с таким говённым AST, язык без нормальных >замыканий, язык, настолько сильно неортогональный - идёт туда, куда ему >и дорога - в мелкие детские скриптики.

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

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

Ну а про скорость разработки - Лисп тут Питону даст громадную фору. Да, по сравнению со всяким там убожеством вроде Жабы или С++ Питон - просто рай, но по сравнению с Лиспом он от Жабы не шибко далеко ушел, такая же детская игрушка.

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

vsl
()
Ответ на: комментарий от AIv

>...ну не люблю я скобочки...

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

WFrag ★★★★
()
Ответ на: комментарий от vsl

Перечисленное в начале поста - да. Но это к решаемым конкретным задачам никак не относиться, просто пришла мысля, вот решил ее провентилировать....

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

Про лисп-который-должен-знать-каждый и отстойных программистов - если брать статистику, думаю что большинство девелоперов не знают ни лиспа ни хаскеля ни даже питона:-), но я бы не рискнул их называть отстойными... поаакуратней в выражениях, а? :-) Пахнет каким то оглтелым фанатизамом, кто то тут от хаскеля пЫсает и кричит чтоб все его учили, кто то от лиспа, но нуно понимать все таки что нет универсальных языков по большому счету-то.... каждому свое. И когда чел. долго сидевший в своей специяльной области на заточенных пож эту область средствах разработки чуток ее расширяет в другую область, с другими средствами разаработки, то ему вовсе не обязательно все ьросать и начинать учить лисп (перл, колд-фьюжн или вижуал байсик), если он не собираеться конечно менять специалтзацию. ИМНО:-)

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

Пи - минимально. Если у тебя есть хотя бы два взаимодействующих параллельных потока - то у тебя уже есть ПОЛНАЯ математика пи-исчисления. Если потоки не взаимодействуют - то это уже вырожденный случай, не думаю, что он тебе может быть интересен, это для разработчиков scheduler-а задачка. Про узкоспециализированные инструменты - ты абсолютно, полностью прав. И именно по этой причине у Лиспа нет конкурентов - Лисп - это не просто язык, это среда для разработки узкоспециализированных языков. Ты всё же попробуй Лисп изучить, иначе никогда программистом не станешь.

Про отстойных - я свои слова брать назад не намерен. Те, кто не знает самые основы computer science, кто не знаком СО ВСЕМИ существующими парадигмами - тот не имеет права называться программистом, тот - всего лишь кодер, то есть, существо весьма никчёмное. Покажи мне якобы программиста, который не знаком с Лиспом, и я легко докажу, что он - фигня полная.

vsl
()
Ответ на: комментарий от anonymous

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

vsl
()
Ответ на: комментарий от Cantor

Особенно если учесть, что от скобочек избавиться - задача тривиальнейшая.

И почему тут никто со мной не захотел на 100GBP спорить, что я легко обойдусь вообще без скобок (любых!) в Лиспе? ;)

vsl
()
Ответ на: комментарий от vsl

> Особенно если учесть, что от скобочек избавиться - задача
> тривиальнейшая.
>
> И почему тут никто со мной не захотел на 100GBP спорить, что я легко
> обойдусь вообще без скобок (любых!) в Лиспе? ;)

На пиво - согласен =) Просто чтоб посмотреть...

Еще одно пиво - если сделаешь из лиспа что-нибудь визуально навроде
Nemerle

int19h ★★★★
()
Ответ на: комментарий от int19h

Ок, согласен.

Мне это всё равно делать надо, так что не напрягусь.

vsl
()
Ответ на: комментарий от vsl

python vs lisp - мнение тупого кодера:-)

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

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

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

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

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

Счас придет vsl, и скажет что за 10м.куб. пива он в течегнии получаса причешет лисп к такому виду, что я в жизни не догадаюсь что это не С++:-) неповерю опять таки.... если это дейсвительно так просто - почему этого до сих пор не сделано? ФИшка пользовалась бы популярностью, я бы во всяком случае юзал с удовольствием, интерпретатора С++ напр иногда ну очень не хватает - для тех же прототипов....

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

AIv ★★★★★
() автор топика
Ответ на: python vs lisp - мнение тупого кодера:-) от AIv

> В общем чего я хочу сказать. Что такое ортоганальность и замыкания я
> не знаю -как тупому кодеру мне это не нужно:)

А ты все-таки узнай. Тогда, собственно, и будет о чем говорить.

> Вообще ИМНО, как и везде в нашей непростой жизни, глупо кричать о
> недостататках и достоинствах, поскольку одни естественным образом
> вытекают из других, а можно корректно говорить лишь об особенностях.
> Если автор языка сделал именно так, значит это было кому нибуть
> нужно)))

Скажи это тем, кто дизайнил COBOL и BASIC.

> Так вот, у питона есьть две особенности коих лисп имхо лишен, и
> которые для меня лично очень важны - простота изучения и близкие к
> традиционным языкам (С++ напр) синтаксис и идеологию.

C++ - традиционный язык? Гы =)

По истории - два.

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

Сие есть следствие того, что "тупой кодер" обычно знает Delphi, Java,
или VB(.NET), в крайнем случае - C/C++. Т.е. к достоинствам собственно
языка отношения никакого не имеет

> Вторая позволяет легко переводить сляпанные на коленке за 15 мин.
> питоновские прототипы в рабочие С++ модули. Если вы мне скажете что
> программа на Лиспе переводиться в С++ так же легко (руками!), я не
> поверю - больно уж они разные...

Несколько странный критерий - если язык самодостаточнен (о чем в данном
случае и идет речь), зачем переводить его в C++ модули?

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

А с какого боку Common Lisp в емаксе? Там свой диалект, причем весьма
отличный.

> Счас придет vsl, и скажет что за 10м.куб. пива он в течегнии
> получаса причешет лисп к такому виду, что я в жизни не догадаюсь что
> это не С++:-)

Он будет прав.

> неповерю опять таки.... если это дейсвительно так
> просто - почему этого до сих пор не сделано?

Потому что это никому не нужно. Зачем тем, кто пишет на лиспе, делать
из своего инструмента куда более убогие плюсы?

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

Если тебе нужен интерпретатор C++ - они есть. Google is your friend.

> Да, как тупой кодер я являюсь конечным потребителем всяких высоких
> технологий, и к мои словам стоит прислушиваться:-)))

Не думаю, что стоит. Результаты таких прислушиваний - те же COBOL и VB.

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

Тут без комментариев. Придет Виталий, он подробно распишет, на какие
именно удобрения стоит пустить всех тупых кодеров, чтоб настало в мире
счастье =)

int19h ★★★★
()
Ответ на: комментарий от int19h

>C++ - традиционный язык? Гы =)

>По истории - два.

Гы. Из скромного личного опыта - все с кем я общаюсь пишут на С/С++. Так что для меня и моего круга общения именно что традиционный. Причем здесь история? Даже Страусруп в свеом интервью признает его широкое распространение))))

>Несколько странный критерий - если язык самодостаточнен (о чем в данном случае и идет речь), зачем переводить его в C++ модули?

Для той же производительности хотя бы... для экономии ресурсов (паямти напр).

>Если тебе нужен интерпретатор C++ - они есть. Google is your friend.

уже не нужен, питона хвататает)))

>> Да, как тупой кодер я являюсь конечным потребителем всяких высоких >> технологий, и к мои словам стоит прислушиваться:-)))

>Не думаю, что стоит. Результаты таких прислушиваний - те же COBOL и VB.

У меня друг уехал в Штаты неск лет назад, и получал за программирование на ВБ совершенно дикие, даже по их меркам, деньжищи. Я конечно смеялся, но смех-смехом а зарплата-зарплатой...

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от int19h

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

>Сие есть следствие того, что "тупой кодер" обычно знает Delphi, Java, >или VB(.NET), в крайнем случае - C/C++. Т.е. к достоинствам собственно >языка отношения никакого не имеет

Напротив... Какое основное достоиство английского? Простотота построения фраз? или его широкое распрорастранение? :-) И что тут первично?

AIv ★★★★★
() автор топика
Ответ на: python vs lisp - мнение тупого кодера:-) от AIv

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

ага только учитывай что emacs lisp и common lisp это совершенно разные вещи .. emacs lisp примерно такойже как maclisp в 60-х годах

сейчас lisp по скорости подчас C уделывает для многих задач

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

lg ★★
()
Ответ на: комментарий от lg

Было бы очень интересно посмотреть хотя бы трехдиагональную прогонку написанную на лиспе... особенно с его префиксной формой записи:-)

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

>Было бы очень интересно посмотреть хотя бы трехдиагональную прогонку написанную на лиспе...

Дай я попробую.

Напиши, плиз, формулы - я их забыл.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

напр http://algorithm.narod.ru/ln/tridiag.html - вроде даже код какой то на С есть...

На самом деле я неудачный пример привел, тут пожалуй чмстая задача на ФП. В лиспе есть массивы и структуры а-ля С/C++?

AIv ★★★★★
() автор топика
Ответ на: python vs lisp - мнение тупого кодера:-) от AIv

Ты главного не понял. Если ты программист, то ты обязан знать все парадигмы. Вообще все. А не ограничиваться "традиционным" убожеством. Ну а как кодер - да кому ты на фиг нужен? Кодеров не должно быть.

Плохой ты кодер, если даже так сильно нужный тебе интерпретатор C++ не нашел (http://root.cern.ch/, качать CINT)...

vsl
()
Ответ на: комментарий от AIv

Есть конечно же. И часто - более эффективно реализованные, чем в C++ (потому как GC умный, см. соседний тред).

vsl
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.