LINUX.ORG.RU

Динамичекие языки на подъёме


0

0

Отличная статья о росте использования динамических языков программирования и о их несомненных преимуществах по сравнению с обычными (компилируемыми) языками. Также в статье вы найдете интервью с известными людьми из мира PHP/Python/Perl/Tcl/TK.

>>> Подробности

★★★★★

Проверено: K48 ()

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

anonymous
()

ну во, щас лиспуны будут тут жечь

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

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

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

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

Интерпретируемыми они быть не обязаны, строго говоря - см. Psycho, Parrot, Jython и т.д.

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

anonymous
()

Абсолютно бестолковая статья.

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

> а больше серьезных игроков на рынке где применимы питон с пхп нет.

Нет - будут. Делов-то... :-)

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

IMHO у MS всё же любимый С#, а vb и C++ постепенно сдают позиции.

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

А динамический это не тот где можно

i = new Object
i.new_method {
// do smth.
}
i.new_method

?

anonymous
()

_ГДЕ_ растет такая травка?!

> Отличная статья о росте использования динамических языков программирования

Вообще-то статья называется "Scripting languages"...

> и о их несомненных преимуществах по сравнению с обычными (компилируемыми) языками

Нет. В статье сравнивают _сильно_ низкоуровневые(C) языки с высокоуровневыми (Python). Что просто бред. Если уж так хочется сравнить compiled to byte-code vs compiled to native code, сравнили б LISP, Component Pascal, etc со своими любимыми цацками.

Кстати, авторам представляется (ввиду общей безграмотности), что "compiled to byte-code" и "compiled to native code" -- это взаимоисключающие возможности. Оттуда и идет бред вроде

> Scripting languages have a very important place in the hearts and minds of developers who pride themselves on rapid _ application development and delivery.

В силу все той же безграмотности авторы путают интерпретируемые языки и языки с автоматическим управлением памятью:

> Managing memory is seen as something that is best done by interpreters, and when specifications change at whim, software must evolve rapidly to fit new demands.

Прочую чушь просто лень комментировать...

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

> а больше серьезных игроков на рынке где применимы питон с пхп нет.

гыгык. ну ты ляпнул. 8) сходи спроси гугля, сколько процентов от общей массы ПО занимают вэб-разработки и там же поинтересуйся сколько процентов от оного составляют Python && php

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

что-то я на этой странице не вижу слова "sun"
зато вижу "powered by ASP.NET",
а не "ПХП" что характерно

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

> ну и сколько процентов веб-разработки делается на питоне? > два? > два с половиной?

Чуть меньше чем на Perl, но только пока. Мне кажется, что у этого языка потенциал гораздо больший чем у PHP и C# вместе взятых.

Python форева, одним словом!

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

>под интерпретируемыми обычно подразумевается что вообще по строчке код >парсится,

нет, под интерпретируемым языком подрузамевается то что
не переводится в машинные коды перед исполнением

anonymous
()

скоро ваще на Labview будут скрипты под веб писать ;)

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

> Чуть меньше чем на Perl, но только пока. Мне кажется, что у этого
> языка потенциал гораздо больший чем у PHP и C# вместе взятых.

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

Если хочешь посмотреть на что-то с потенциалом, и сделанное по уму -
погляди на Ruby.

int19h ★★★★
()
Ответ на: _ГДЕ_ растет такая травка?! от Dselect

> Нет. В статье сравнивают _сильно_ низкоуровневые(C) языки
> с высокоуровневыми (Python).

По-моему, там все больше говорят о Java и C#. Такое сравнение вполне
разумно, т.к. они воюют за одну нишу.

> Кстати, авторам представляется (ввиду общей безграмотности), что
> "compiled to byte-code" и "compiled to native code" -- это
> взаимоисключающие возможности. Оттуда и идет бред вроде

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

Короче, читаем внимательней...

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

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

Будущее - оно многолико.

Будущее "потребителей" (простых юзеров, чайников, ламеров и эникейщиков) в руках крупных игроков: транснациональных корпораций, крупных производителей софта и проихводителей железа. Да, ещё в руках _очень_ крупных opensouc'ных проектов (таких, как Linux или GNU).

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

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

Кстати о Ruby. Где можно о его интересных особенностях и о сравнении с другими языками его класса почитать?

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

И что же за язык тако ASP.NET? не знаете - нехера писать всякую чушь В ASP.NET я могу писать хоть на C# хоть на J# и т.д. в том числе могу писать и на их PHP...

anonymous
()
Ответ на: _ГДЕ_ растет такая травка?! от Dselect

"""Кстати, авторам представляется (ввиду общей безграмотности), что "compiled to byte-code" и "compiled to native code" -- это взаимоисключающие возможности. Оттуда и идет бред вроде."""

Как раз на эту тему:

Conway: If anything, I think the trend is in the other direction: interpreted or "just-in-time" compiled languages will increasingly take over from pre-compiled languages. Compilation will eventually come to be seen for what it is: merely an optimization tool, and one whose use is almost always premature.

И вообще большинство комментариев к этой статье относятся к разряду "буквоедство" когда человек придирается к мелочам не желая видеть то о чём пишут. И вообще авторы "обсуждаемой" статьи поступили мудро взяв интервью у 5 разных человек. То что они разные можно отчётливо видеть по ответам. Так же глупо требовать от отвечающих на вопросы абсолютной полноты определений. Это всё-таки интервью, которое предназначено для _людей_ отличающих goto от звуковой карты а не программа для машины. Кроме того, трудно заподозрить людей, серьёзно занимающихся подобными языками в том что они не понимают что делают.

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

ну про ниши ты ошибся. какой лозунг был при создании жабы? write once run anywhere. пока по прошедшей истории Dot Net мы подобного стремления не видим. совсем наоборот.

кстати питон у меня летает. а жаба тормозит причем памяти и проца достаточно даже чтоб КДЕ со всеми "красивостями" летал. так что делаем выводы господа

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

> кстати питон у меня летает. а жаба тормозит причем памяти и проца достаточно даже чтоб КДЕ со всеми "красивостями" летал. так что делаем выводы господа

KDE - штука весьма быстрая, кто бы что не говорил. Для своей сложности оно довольно экономно расходует память и процессор: весь KDE, вместе с конки, потребляет примерно столько же памяти, сколько один файрфокс.

А ява память жрет солидно. Но все равно, большие проекты на ней гораздо более возможны, чем на питоне (или нежно любимом мною перле, или руби, ли пхп): что-то я не слышал про чисто питоновские системы, сопоставимые по объему и сложности с Eclipse или J2EE контейнером. И именно потому, что накладные расходы питона (компиляция из исходников каждый раз) для них уже станут неподъемны для современного железа.

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

> что-то я не слышал про чисто питоновские системы, сопоставимые по объему и сложности с Eclipse или J2EE контейнером. И именно потому, что накладные расходы питона (компиляция из исходников каждый раз) для них уже станут неподъемны для современного железа.

иногда лучше помолчать, чем говорить всякую чушь:

http://www.python.org/doc/2.2.3/tut/node8.html

Some tips for experts:

* A program doesn't run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that's faster about .pyc or .pyo files is the speed with which they are loaded.

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

Ну может с производительностью программок типа хеллоу ворлд этои прокатит. Но вот в сложных системах наверное выскочат грабли в плане производительности с: 1. Динамичность языка, всякие риал тайм проверки и метаинформация сможет загрести памяти почище чем джава. 2. Современный джава аппликейшн сервера прошли очень длинный путь становления, в них вложены уймы бабок, и аппликейшн сервера от питона вряд ли так соптимизированы для больших продакшн систем как джава сервера. Имеется ввиду такие фичи как кластеризация бизнес логики с лоад балансингом, фсевозможные кеширования, персистентность и т д и т п. На питоне это прийдется переписывать все каждый раз самому, причем с бюджетом переписывания явно меньшим чем у Ай Би Эм и БЕА.

Абнормал

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

>Ну может с производительностью программок типа хеллоу ворлд..

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

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

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

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

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

ну ты точно жаба-мен ;) проблемы кластеризации? - http://openmosix.sourceforge.net/ проблемы безопасности? - это проблемы кривых рук разработчиков, жаба тут не поможет проблемы работы с базами данных? - а что за проблемы-то, и у кого? и т д? - и тд

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

Не хочу устраивать лик без а отвечу в твоем стиле: http://java.sun.com/j2se/1.5.0/docs/index.html http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html там все прочтешь. А вообще я вижу ты спец обливать грязью то в чем ваще нифига не шаришь и даже представления не имеешь.

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

> 1. Динамичность языка, всякие риал тайм проверки и метаинформация сможет загрести памяти почище чем джава.

Хоть раз приходилось в руках держать что-нибудь из изложенного в статье? Динамичность упомянутых Perl'ов и Python'ов заключается не в каких-то там "всяких риал тайм проверки и метаинформации". Это, если вы не в курсе есть и в Jave (как по Вашему работает "Garbage Collection"?). Их динамичность, в первую очередь в способности программ генерировать новые слассы и код внутри себя, что собственно и позволяет писать лаконичные с точки зрения кода, но крайне мощные с точки зрения функционала приложения. Это особенность вкупе с более высокооуровневой программной моделью чем у джавы, сильно упрощает этап прототипирования. Увеличение скорости с легкостью достигается переписыванием критических участков (после профилирования) на языке более низкого уровня, напр. на С или даже ассемблере. Благо это достаточно просто и для этого есть простые и понятные средства, напр. SWIG.

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

Ну и много Вы видели внедрений этих волшебных "аппликейшн серверов", особенно в родном отечестве? Даже когда это происходит, поверьте -- в основном это отмывание денег. Работающие внедрения в сколь-нибудь серьезном объеме можно сосчитать по пальцам. Да и то, обычно это не абстрактные аппликейшн сервера, а вполне конкретные прикладные системы, написанные черт знает когда и черт знает на чем, к которым сбоку прилеплен Java-API (напр. SAP, Oracle Applications и т.п.). Да и те в основном нужны на свете не для того что работающие системы делать, а что бы бабки отмывать :)

> Имеется ввиду такие фичи как кластеризация бизнес логики с лоад балансингом, фсевозможные кеширования, персистентность и т д и т п. На питоне это прийдется переписывать все каждый раз самому, причем с бюджетом переписывания явно меньшим чем у Ай Би Эм и БЕА.

Ну и? Когда-нибудь например на Python+Zope+Plone пыталсь взглянуть? Там тебе и кеширование, и кластеризация (ZEO), и персистентность, и для людей сделано... Пока все эти чудесные пиар-менеджеры из Ай Би Эмов, Санов, Ораклов и БЕА нам сказки рассказывают и на нас на бюджет разводят, народ делом занимается!

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

> Динамичность упомянутых Perl'ов и Python'ов заключается не в каких-то там "всяких риал тайм проверки и метаинформации". Это, если вы не в курсе есть и в Jave (как по Вашему работает "Garbage Collection"?). Их динамичность, в первую очередь в способности программ генерировать новые слассы и код внутри себя, что собственно и позволяет писать лаконичные с точки зрения кода, но крайне мощные с точки зрения функционала приложения.

Я не претендую на суперпроффесионализм, но где то ведь проскакивало, что в питоне хотят ввести опциональную строгую типизацию, что по мнению разработчиков должно немеряно поднять перфоменс. Хотя возможно что я и ошибаюсь. И вообще отсутствие строгой типизации на мой взгляд во много раз увеличивает возможность реал тайм ошибки, когда продукт уже стоит в продакшене, и фикс стоит на порядок больше чем на этапе девелопмента и тестирования.

> Ну и много Вы видели внедрений этих волшебных "аппликейшн серверов", особенно в родном отечестве? Даже когда это происходит, поверьте -- в основном это отмывание денег. Работающие внедрения в сколь-нибудь серьезном объеме можно сосчитать по пальцам.

Да ладно, я видел достаточно много.. И написанных с нуля.

> Ну и? Когда-нибудь например на Python+Zope+Plone пыталсь взглянуть? Там тебе и кеширование, и кластеризация (ZEO), и персистентность, и для людей сделано... Пока все эти чудесные пиар-менеджеры из Ай Би Эмов, Санов, Ораклов и БЕА нам сказки рассказывают и на нас на бюджет разводят, народ делом занимается

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

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

Всего лишь личное мнение видимо..

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

> Не хочу устраивать лик без а отвечу в твоем стиле: http://java.sun.com/j2se/1.5.0/docs/index.html http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html там все прочтешь. А вообще я вижу ты спец обливать грязью то в чем ваще нифига не шаришь и даже представления не имеешь.

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

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

Кстати, у меня возникли сильные подозрения, что ты недавно выучил жабу и другие языки отрицаешь со стойкостью фанатика жабы, мой тебе совет: потрать свой пыл фанатика на изучение ещё пятка языков, очень помогает для расширения знаний о существующих технологиях, их достоинствах и недостатках, заодно как следствие получишь бонус в виде способности решать проблемы более специализированными и соответственно лучшими в каждом конкретном случае решениями. Да есть проблемы совместимости если части написаны на разных языках, но есть стандарты на обмен данными и любой нормальный язык имеет кучу binding'ов к интерфейсным библиотекам. Удачи в профессиональном росте, профи рулят всегда.

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

> ну спасибо за ссылки на доки, без конкретных указаний какие проблемы можно мне и другим решить данной технологией (жаба).

Как ты выше сказал, джава претендует на всеохватность. Проблем очень много. МНе не хочется рыться в доках и искать для тебя решение конкретных проблем.

>Мой опыт и представления показывают (если уж речь зашла о них), что любая технология с претензией на всеохватность (жаба в данном случае) уделывается на раз специализированными решениями. Да, научив жабе кучку кодеров-обезьянок можно поиметь дешёвую команду, способную быстро шлёпать на жабе универсальные "решения", но в каждом конкретном случае специализированное решение, написанное профессионалом, заведомо выиграет у "универсального" решения.

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

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

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

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

>Майкрософт перекупила создателя jpython. Но остались и другие биндинги!

AFAIK самые быстрый(но не доделанный) из всех Питонов.

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

дальше от машины... но не ближе к человеку

> По-моему, там все больше говорят о Java и C#.

Разницы мало, IMHO. Java _самую малость_ выше уровнем, чем C. Если из низкоуровневого языка выкинуть адресную арифметику и прикрутить GC, то он не станет высокоуровневым.

> Такое сравнение вполне разумно, т.к. они воюют за одну нишу.

Такое сравнение, IMHO, неразумно, т.к. сравниваются совершенно разные вещи.

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

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

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

>Потенциал у Питона - нулевой. Точнее даже отрицательный, потому что действительно интересные фичи языка выкидываются, и остается еще один, ничем не выделяющийся императивный язык.

no youre wrong. all interesting features (include lists comprehension) are there and what is no more need to use is smth. like map/filter - I think it's right and Gvido have good understanding for usefullness to make Python more clear and easy for beginners

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

Потенциал очень высокий. По крайней мере на последней PyCon были представители и Microsoft Corporation в том числе http://pycon.org/dc2005/talks/keynote

Собственно период активного PR python в самом начале. Если почтитать статьи, то видно, что многие модные штуки пишутся python разработчиками и на python. Тот же Пол Грэхем или автор Bittorrent'а.

Многие гики переходят на python, например в Burning Man'е внутренние проекты делаются на Plone, работающем на Zope.

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

xen
()

Не хочу показаться банальным. Но! Так называемый "modern c++ way/design" водят на нет преимущества скриптовых языков в плане удобства и компактности кода. Единственное что остается так это динамичнось. Мы проводили сравнения одной и тойже программы на Python, Java и modern C++. Так по объему меньше всего программа была на C++, затем на Python и самая большая на Java. Ну а по скорости тут и говорить нечего. Новый C++ это не тот язык где вы работаете с указателями, где-то в коде пишете delete. Сейчас реально на C++ облегчают написание кода библиотеки STL, Boost, Loki. Почитайте Александреску А. (www.moderncppdesign.com) и вы поймете что вы не знаете C++.

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

>ну и сколько процентов веб-разработки делается на питоне? два? два с половиной?

этого посчитать невозможно, но известно, что на питоне писаны (по крайней мере вначале) Google, Inktomi, Yahoo Groups ... а сколько сайтов на Zope?... и это всё не хоумпэйджи Васи Пупкина

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

>Мы проводили сравнения одной и тойже программы на Python, Java и modern C++.

Код в студию!! Не верю!!

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