LINUX.ORG.RU

[Тред-совет] ЯП с динамической типизацией


0

6

Присматриваю для себя - чего бы нового изучить. Железная, непоколебимая статика - хорошо конечно, но начинает надоедать. Аккуратности кода уже вроде набрался, можно попробовать динамику. Вот и стою перед выбором - куда податься - Python, Ruby, JS или что там еще?

Итак, императивный, лаконичный, кроссплатформенный ЯП, с динамической типизацией, с развитой инфраструктурой, продукты которого жрут минимум памяти, адекватные по скорости, можно с вкраплениями функционального программирования, и совсем хорошо, если компилируемый - что посоветует многоуважаемый All?? (желательно с обоснованием)

Цель - создание серверных, десктопных и веб-приложений. Будет Ъ, если можно использовать один код для веб и десктопа (по типу Eclipse RAP/RCP)

Спасибо

★★★★★

Python

императивный

Да

лаконичный

Да

кроссплатформенный

Да

с динамической типизацией

Да

с развитой инфраструктурой

Да

продукты которого жрут минимум памяти

Более-менее

адекватные по скорости

Скорость адекватна для решаемых задач

можно с вкраплениями функционального программирования

Да

совсем хорошо, если компилируемый

Да

Zenom ★★★ ()

под такие противоречивые требования только python подходит

bik ★★ ()

Цель - создание серверных, десктопных и веб-приложений. Будет Ъ, если можно использовать один код для веб и десктопа (по типу Eclipse RAP/RCP)

groovy

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

>Python

совсем хорошо, если компилируемый

Да


вы в этом уверены?

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

Python

Питон - для девочек. Ну и tailgunner'а.

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

> Ну и tailgunner'а.

Ты так говоришь, словно у него короткие волосы.

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

> Питон - для девочек. Ну и tailgunner'а.

Ч0рт, куда ж попрятались все эти девочки?

А под список требований Python вполне подходит.

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

А под список требований Python вполне подходит.

Pythin уныл ;)

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

> Ч0рт, куда ж попрятались все эти девочки?

В поисках жены-питонистки?

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

В поисках жены-питонистки?

знаешь как питон заглатывает кролика? ммм...

shty ★★★★★ ()

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

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

JavaScript интересен как язык своей гибкостью, прототипами, this зависящим от контекста и функциональщиной. Под твои условия не попадает. :)

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

> Pythin уныл ;)

Да ладно! Иной раз смотришь на код — обхохатываешься!

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

>Под твои условия не попадает. :)

единственное под что он не попадает - это под твои фантазии:

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


а

создание серверных, десктопных и веб-приложений


JS умеет и хорошо.

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

>под такие противоречивые требования только python подходит

ммм, а в чем противоречия, не укажете?

да, Python подходит.
Собственно сейчас у меня на рассмотрении Python, Groovy и JS.

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

да, записал.
Groovy мне наверное ближе своей Java-инфраструктурой (платформой), в сравнении с Python.

dib2 ★★★★★ ()

> императивный, лаконичный, кроссплатформенный ЯП, с динамической типизацией, с развитой инфраструктурой, продукты которого жрут минимум памяти, адекватные по скорости, можно с вкраплениями функционального программирования

Под описание подходят несколько жизнеспособных современных языков. Давайте разберем три из них: Python, JavaScript и один JVM-based, например, Groovy. Как языки они все весьма неплохи и должны удовлетворить вашим требованиям, поэтому останавливаться на чисто языковых «фичах» мы не будем.

Python: Самая большая проблема - с производительностью. Приличного JIT-компилятора нет до сих пор, перспективы PyPy неясны, проект Unladen Swallow почил в бозе. Потребление памяти среднее. Инфраструктура на четверочку с плюсом: стандартный рантайм довольно богат, есть довольно большое количество сторонних библиотек, но не все они хорошо поддерживаются. Особенно в контексте миграции на Python 3 и вообще постоянно меняющихся спецификаций языка.

JavaScript: сразу будем рассматривать две реализации: Seed (базирующийся на вебкитовом JavaScriptCore) и GJS (SpiderMonkey). Оба обладают хорошими, зрелыми JIT-компиляторами, над которыми постоянно работают команды WebKit и Mozilla, соответственно (и, надо сказать, от этой гонки браузеров сам язык только выигрывает). Стандартный runtime минималистичен, но благодаря GObjectIntrospection открывается вся мощь платформ GLib/GTK+/GNOME и кучи библиотек, использующих парадигму GObject. Поддержка в Anjuta IDE. Итог: инфраструктура на пятерку с минусом.

Наконец, Groovy. Все плюсы и минусы Groovy - это плюсы и минусы JVM. О них, полагаю, подробно рассказывать не надо, так как вы производите впечатление человека, знакомого с Java. Плюсы: мощный JIT и «батарейки», минус - время запуска и потребление памяти. Отличная поддержка в IDE. Итог по инфраструктуре: 5+.

> совсем хорошо, если компилируемый

Вы хотите статической компиляции в ELF? Этому требованию из динамических языков удовлетворяют только некоторые коммон-лиспы и схемы. Но при этом они имеют кучу родовых травм, нивелирующих этот «бонус». (О них, разумеется, невдомек вбрасывающим про Common Lisp в первом же комментарии Reset'ам - потому что они либо не писали на Common Lisp ничего сложнее «Hello, World!», либо явно троллят. Следовательно, «disregard them, they suck cocks». (C))

Собственно, и сама «бонусность» тут сомнительна. Для обеспечения динамизма в статически компилированном коде приходится прибегать к ухищрениям в виде 60-мегабайтного рантайма со встроенным ad hoc, informally-specified, bug-ridden, slow implementation of half of GCC. Более адекватный путь, выбранный цивилизованным IT-миром - JIT-компиляция. Из выше рассмотренных языков стабильным и зрелым JIT-компилятором располагают, напоминаю, JavaScript и JVM-based языки.

> Цель - создание серверных, десктопных и веб-приложений. Будет Ъ, если можно использовать один код для веб и десктопа (по типу Eclipse RAP/RCP)

Требование довольно экзотическое. Полагаю, проще будет доточить тот же RAP/RCP до возможности скриптинга его на Groovy. Но сперва поинтересуйтесь, вдруг такое уже возможно - тогда тема должна быть сразу же закрыта.

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

Можно подробнее про «родовые травмы» ? Про 60 мегабайт рантайма это не аргумент.

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

> Python: Самая большая проблема - с производительностью.

Ты или теоретик, или пытаешься использовать Питон не по назначению.

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

> Можно подробнее про «родовые травмы» ?

Охотно. К самому языку это слабо относится: язык как язык, хотя и со своими тараканами. Отметим проблемы с переносимостью между реализациями и платформами. Но в основном претензии относятся к последнему пункту - инфраструктуре. Хорошо, что ТС уделяет ему особенное внимание: это свидетельствует о зрелости специалиста. Адепты же лиспа, наоборот, этот пункт устойчиво игнорируют. Посему ТСу будет предложены Emacs+SLIME вместо IDE, а вместо библиотек - кучки неподдерживаемого и непортируемого кода с CLiki. Ну или другой вариант: везде использовать FFI. Но в чем тогда профит от использования лиспа? В том же Питоне гораздо более приличное FFI, да и нет в нем особенной надобности. В макросах, метапрограммировании и мифической «выразительности»? Другие фичи, типа лямбда-выражений (которые лисперы привыкли незаслуженно присваивать себе), уже давно есть в во всех нормальных языках.

Про 60 мегабайт рантайма это не аргумент.


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

Итак, если ТС готов пожертвовать ради сомнительной выгоды использования макросов а) нормальными IDE, 2) богатым рантаймом и качественными библиотеками, 3) переносимостью, 4) отчасти собственной психикой - то добро пожаловать в розовый мир Коммон Лиспа!

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

Вообще, лучше меня о «родовых травмах» расскажут сами лисперы. Курите многочисленные посты того же den73, в которых он описывает массу фатальных проблем, из-за которых он вынужден был отказаться от лиспа (кстати, в пользу Python). Пробегал тут также юноша бледный, который пытался применять Common Lisp в махровом enterprise - очень неплохо все расписал после прозрения. Попытки запихнуть лисп в числодробильню наталкивались на непреодолимые архитектурные ограничения, связанные с tagged values, и так далее.

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

>С этим надо идти к ТСу.

все ничего, но

2) богатым рантаймом и качественными библиотеками, 3) переносимостью


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

dib2 ★★★★★ ()

Учи яваскрипт. До петухона всегда успеешь добраться, а вот как доберешься скажешь что js не нужен.

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

> Ты или теоретик, или пытаешься использовать Питон не по назначению.

Лично я питон не пытаюсь использовать :) Хотя вру. Использовал три раза в жизни. Для stored-процедуры под PostgreSQL, в качестве «клея» для NumPy, и для небольшого системного демона. Для _моих_ задач производительности Python вполне хватало, в чем я и отдавал себе отчет.

Но ТС требует «адекватной производительности». Изучив задачи и бэкграунд ТСа, делаем справедливый вывод, что требуется производительность, сравнимая с Java. А питон там и рядом не валялся. Посему проблемность питона в этом плане следует воспринимать по отношению к JVM.

Чистая логика, никакого мошенства.

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

> Теоретик без практики он.

...только почему-то этот «теоретик» знает о лиспе и его проблемах больше, чем многие здешние «лисперы» ;) Если что, я не о тебе конкретно.

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

>Учи яваскрипт. До петухона всегда успеешь добраться, а вот как доберешься скажешь что js не нужен.

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

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

> спасибо большое за трактат. учту.

Рад помочь, обращайтесь.

реальные ответы на них можно получить только из практики


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

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


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

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

>> Ты или теоретик, или пытаешься использовать Питон не по назначению.

Лично я питон не пытаюсь использовать :)

В этом случае разумный человек (ты выбрал именно такой имидж) воздержался бы от высказывания своего мнения.

Но ТС требует «адекватной производительности». Изучив задачи и бэкграунд ТСа, делаем справедливый вывод, что требуется производительность, сравнимая с Java.

Гладко излагаешь. Но ты знаешь не бэкграунд ТС, а только используемую им платформу. А веб, о котором ТС упомянул, по определению I/O-bound.

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

Прочёл все посты. Удивился. Неужели нужно такое обильное словоизлияние, чтобы сказать: «ТС, для твоих требований подходят Groovy, JS, в меньшей степени Python, но никак не Lisp и его клоны».

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

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

> В этом случае разумный человек (ты выбрал именно такой имидж) воздержался бы от высказывания своего мнения.

Как известно, не надо быть поваром, чтобы понять, что мясцо слегка подтухло ;) К тому же, «не пытаюсь» относится к настоящему времени, а упоминание о прошлом опыте ты ловко проигнорировал.

А веб, о котором ТС упомянул, по определению I/O-bound.


Но это не значит, что он _только лишь_ I/O-bound. Видимо, мой опыт с веб-программированием несколько богаче твоего (nothing personal), поэтому я и воспринимаю этот термин немножко шире. Hint: transaction processing, business rules, expression language, business intelligence.

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

> Неужели нужно такое обильное словоизлияние, чтобы сказать: «ТС, для твоих требований подходят Groovy, JS, в меньшей степени Python, но никак не Lisp и его клоны».

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

И сладострастно обсасывать недостатки лиспов тоже не было необходимости.


Вы склонны видеть эмоции там, где есть только голые факты.

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


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

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

> Курите многочисленные посты того же den73,

он вынужден был отказаться от лиспа (кстати, в пользу Python)

Дык вроде бы наоборот констатировал что Pythin для инкрементной разработки не подходит и остался на синтакически расширеном CL.

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

>> В этом случае разумный человек (ты выбрал именно такой имидж) воздержался бы от высказывания своего мнения.

Как известно, не надо быть поваром, чтобы понять, что мясцо слегка подтухло ;)

На лурк.

А веб, о котором ТС упомянул, по определению I/O-bound.

Но это не значит, что он _только лишь_ I/O-bound

В своих предположениях ты заходишь всё дальше.

Видимо, мой опыт с веб-программированием несколько богаче твоего (nothing personal)

Мой, как ты говоришь, «бэкграунд» - системный программист.

Hint: transaction processing,

I/O-bound.

business rules

Jess, Drools и прочее? Там интерпретатор на Яве - качественно от Jython не отличается.

expression language

Не знаю, что это, но предполагаю еще один интерпретатор.

business intelligence.

Матобработка большого количества данных? Делается на numpy.

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

(попытка предыдущего наезда деликатно проигнорирована)

Дык вроде бы наоборот констатировал что Pythin для инкрементной разработки не подходит и остался на синтакически расширеном CL.


Это, на самом деле, не главное. Главное - то, что он открыто, компетентно и много говорил о проблемах Common Lisp, которые он массово огребал во время своей практики. Инкрементальная разработка - достоинство лиспа (хоть и не безусловное), и, полагаю, это достоинство в случае Дена73 перевесило все недостатки.

ТС же на такие жертвы не готов.

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

> И да, вас никто не заставлял читать мой трактат.

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

Вы склонны видеть эмоции там, где есть только голые факты.

Я склонен видеть то, что вижу. Кто-то знает об этом лучше, чем я?

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

Да брось ты это лицемерие. Я не понимаю смысла агиток как «за лисп», так и «против лиспа». Если человек выбирает инструмент для работы и серьёзно подходит к этому, то он сам найдёт инфо про инструмент и разберётся: нужен он ему или нет. А прочие пусть сами «шишки набивают».

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

> Мой, как ты говоришь, «бэкграунд» - системный программист.

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

Hint: transaction processing,

I/O-bound.


Да что ви гойворите. Системный погромист детектед. :)

Там интерпретатор на Яве - качественно от Jython не отличается.


Ага, значит, уже всплыл Jython ;)

Не знаю, что это, но предполагаю


Не читал, но осуждаю :) А предположение верное.

Матобработка большого количества данных? Делается на numpy.


А как работает связка Jython+NumPy? Если там все в порядке, то я признаю, что Jython - очень хорошая кандидатура для всего вышеописанного.

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

> я сначала внимательно читаю то, что меня заинтересовало, и после этого имею право высказать своё мнение

Заинтересовался, прочитал, оказалось неинтересно. Ну, и кто тут виноват?

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


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

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

> Ты же не будешь отрицать, что web- и enterprise-задачи имеют свою, сильно отличающуюся специфику?

fixed

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

> он открыто, компетентно и много говорил о проблемах Common Lisp, которые он массово огребал во время своей практики.

Опять же надуваешь муху размером с слона. Он давно говорил об отсутсвии webdev библиотеки. И имел несколько претензий к синтаксису в районе let-а и доступа к слотам.

А вот компилируемую динамиу найти довольно сложно. Ну это так к слову.

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