Re[6]: Python VS Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.07 00:54
Оценка:
Здравствуйте, novitk, Вы писали:

N>Языки по выразительности принципиально одинаковы (различий меньше чем у Явы с Шарпом). Питон на мой взгляд лучше читаем — меньше перлизмов, и более компактен из за отступов.


Я бы сказал, что Руби будет по выразительнее.

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


Ну, по библиотекам вообще побидителями будут Ява с дотнетом или какой-нить ПХП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Python VS Ruby
От: novitk США  
Дата: 22.03.07 02:44
Оценка:
VD>Я бы сказал, что Руби будет по выразительнее.

В чем конкретно, кроме анонимных "больших" лямбд? Замечу что синтакс на отступах можно не любить, но выразительности он добавляет существенно.

VD>Ну, по библиотекам вообще побидителями будут Ява с дотнетом или какой-нить ПХП.


Про ПХП — просто чушь. Правильный пример перл.

Дотнетовские библиотеки сильнее только в GUI. При этом есть и серьёзные дыры, например в математике. Про Unix можно забыть, так как все что может моно, делается на Питоне проще и быстрее. С явой по библиотекам согласен, но с ней другие проблемы. Язык не выразителен, и нет нормального скрипта. Вот народ и занимается всякой ахинеей, когда связка проводиться кучей ХМЛа и навороченным контейнером. Если нужно интегрировать с C/C++, то становится совсем неудобоваримо.

Так что, Влад, доделывай с ребятами интеграция Немерле и тогда поговорим, а пока Питон рулит.
Re[9]: Python VS Ruby
От: novitk США  
Дата: 22.03.07 02:58
Оценка:
N>> Питоновские библиотеки давно уже догнали (IMHO даже перегнали) Руби даже в той области где он традиционно силен — ROR.
VD>Догнали? Руби явно сильно моложе будет. Это ему догонять нужно было.

Речь идет о Ruby On Rails, которой руби сильно обязан своей популярностью. В момент выхода реальных конкурентов у не было ни для питона, ни для жабы с шарпом. Сейчас они есть, вот и все.
Re[10]: Python VS Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.07 19:43
Оценка: +3
Здравствуйте, novitk, Вы писали:

N>>> Питоновские библиотеки давно уже догнали (IMHO даже перегнали) Руби даже в той области где он традиционно силен — ROR.

VD>>Догнали? Руби явно сильно моложе будет. Это ему догонять нужно было.

N>Речь идет о Ruby On Rails, которой руби сильно обязан своей популярностью. В момент выхода реальных конкурентов у не было ни для питона, ни для жабы с шарпом. Сейчас они есть, вот и все.


Откровенно говоря РОР не сильно превосходит ASP.NET 1.0. А уж 2.0 и подавно. Может для начинающих это проще, но для большого сильносвязанного сайта РОР вряд ли даст приемущества.

Ну, а питон действительно почему-то не шибко для веба использовался. Хотя не ясно почему. Уж точно лучше чем ПХП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Python VS Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.07 19:43
Оценка:
Здравствуйте, novitk, Вы писали:

VD>>Я бы сказал, что Руби будет по выразительнее.


N>В чем конкретно, кроме анонимных "больших" лямбд? Замечу что синтакс на отступах можно не любить, но выразительности он добавляет существенно.


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

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

В общем, это конечно дело в куса.

Ну, так вот. В Руби мне больше нравится синтаксис и подход к выражению конструкций.
Все эти __ляляля__ мне категорически не нравятся. Блоки код тоже в Руби очень красиво сделаны (вот их передача значительно хуже уже).
Континюэшоны вообще супер! Идея совмещения сишного блока { } и "end"-а тоже очень красива. Любой стрэйтмент == выражение, тоже правильное решение. Функциональный подход лепится на ура. Вот отсуствие перегрузки по количеству параметров — это лажа конечно. В прочем выкручиваются за счет хэш-таблицы и сахара с ними связанного.

Если говорить в двух словах, то код на Руби мне понятен даже без подготовки, что нельзя сказать про код на Питоне.

Хотя конечно согласен, что приблизительно выразительные средства у этих языков равны.

VD>>Ну, по библиотекам вообще побидителями будут Ява с дотнетом или какой-нить ПХП.


N>Про ПХП — просто чушь. Правильный пример перл.


Почему чушь? Ты погляди сколько там для вебя наклепано. Причем зачастую не на самом ПХП. Я видел библиотечки помощьнее дотнетных. Так что это ты зря. Другое дело, что сам язык для даунов. Ну, так он и нишу соотвествующую отъел.

N>Дотнетовские библиотеки сильнее только в GUI. При этом есть и серьёзные дыры, например в математике.


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

N> Про Unix можно забыть, так как все что может моно, делается на Питоне проще и быстрее.


Ну, изобрази что там проще делается на питоне в области того же веба? Моно поддерживает АСП.НЭТ очень прилично. Даи и нелозя сравнивать код на скриптах с кодом компилируемым. Ты волен сам писать сложные библиотеки, а скрпты все же только для прикладной части не требовательной к произвоидтельнсоти пригодны.

N> С явой по библиотекам согласен, но с ней другие проблемы. Язык не выразителен, и нет нормального скрипта.


По мне так скрипты вообще в 21 веке это такой же пережиток как С++. Погоня за ветром в поле.
А что до Явы как языка, то есть Скала. Да и со скрптами там не все так плохо. От JRuby, до Груви.

N> Вот народ и занимается всякой ахинеей, когда связка проводиться кучей ХМЛа и навороченным контейнером. Если нужно интегрировать с C/C++, то становится совсем неудобоваримо.


Ну, интеграция с С++ — это ахинея еще большая. А что до ХМЛ-ех, то согласен идиотизм. Придумали себе религию поклонения одному языку с лозунгом "язык должен быть единым, чтобы никому думтаь не пришлось", а на прктике изобретают новые языки только с синтаксисом в ХМЛ-е.
В прочем ОРМ-фрэймворки все же получаются и пользоваться ими можно (медленные тольео).
Дык тут надо в другую сторону копат. Те же макросы или им подобные решения могли бы спасти отцов русской демократии. Немреле как раз тот самый путь.

N>Так что, Влад, доделывай с ребятами интеграция Немерле и тогда поговорим, а пока Питон рулит.


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

Так что никуда они не рулят. Но если делать выбор именно между скриптовыми языками, то я все же выбрал бы Руби. Красивее, однако.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Python VS Ruby
От: novitk США  
Дата: 22.03.07 21:56
Оценка:
VD> Выразительности он не добавляет. Есть люди считающие, что чем компактнее код тем лучше.
VD> Я к ним не отношусь. Я слишком долго занимался полиграфией и версткой чтобы любить
VD> напиханные без отсупов конструкции. По сути код на отсупах и над с явным форматированием
VD> выражет одно и то же, но форматирование, по-моему, позоляет лучше выхватывать суть.
VD> Компактность же ведь очень опасная. Погоня за ней часто приводит к совершенно
VD> нечитаемому коду.
Компактность без потери читаемости и есть выразительность, согласен? Тут как раз этот случай. То что это полезно, доказывает заимственность в многих новых языках(F#, хаскель). Вроде и в Немерле есть режим (нужно бы зделать дефолтным, да шарписты вроде тебя обидятся ).

VD> Если говорить в двух словах, то код на Руби мне понятен даже без подготовки,

VD> что нельзя сказать про код на Питоне.
Довольно странно, учитывая твою квалификация. Может не надо быть таким предубеждённым

N>>Про ПХП — просто чушь. Правильный пример перл.

VD>Почему чушь? Ты погляди сколько там для вебя наклепано. Причем зачастую не на самом ПХП.
VD>Я видел библиотечки помощьнее дотнетных.
Во-первых хотелось бы пример библиотек покруче. Во-вторых вебом мир не ограничен.

VD> Сложная математика вряд ли нужна в скрптах. Она и в дотнете то с явой не очень то нужна.

Ну у всех потребности разные. Питоном с SciPy, можно уже сегодня заменить MATLAB.

VD> Задачи обычно не те. Да и если что нет проблем подключить Интловские С-шные библиотеки.

Дак вообще нет проблем для людей с головой, кроме нехватки времени.

VD>А вот по общему охвату вряд ли кто приблизится. По сути что ява, что дотент в

VD>осноном это библиотечный код. Если вспомнить Framework 3.0, то вообще и говорить
VD>не о чем. Никто и рядом не стоял. Один WPF чего стоит?
Чего? Теперь ГУЙ можно в ХМЛ описывать, прогресс однако. Ну и синтегрировали контролы с Direct3D. Для игровиков наверно полезно, для большинства нет.

N>> Про Unix можно забыть, так как все что может моно, делается на Питоне проще и быстрее.

VD>Ну, изобрази что там проще делается на питоне в области того же веба?
VD>Моно поддерживает АСП.НЭТ очень прилично.
Да ладно не смеши, посмотри TurboGears, Pylon, Django, CherryPy и т.д.

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

VD>Ты волен сам писать сложные библиотеки, а скрпты все же только для прикладной
VD>части не требовательной к произвоидтельнсоти пригодны.
Да, а пацаны и не знали. Я думал мы сравниваем библиотеки, а ты мне тут банал врубил.

VD> А что до Явы как языка, то есть Скала.

Спасибо, я осведомлен. Согласен, вещь не плохая, но не скрипт.

VD> Да и со скрптами там не все так плохо. От JRuby, до Груви.

Это полные альфы, даже тут питон (Jython) впереди...

VD>Ну, интеграция с С++ — это ахинея еще большая.

Ты в каком мире живешь? В моем есть куча легаси кода, который завтра не исчезнет, даже если MS обьявит завтра, что Немерле это C# 4.
Re[10]: Python VS Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.07 23:34
Оценка:
Здравствуйте, novitk, Вы писали:

N>Компактность без потери читаемости и есть выразительность, согласен?


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

N> Тут как раз этот случай. То что это полезно, доказывает заимственность в многих новых языках(F#, хаскель).


F# и Хаскель это прямые клоны ML-я полностью заимствовшие у него синтаксис. Я встречал очень много народа сетовавшего на то, что приколы с отступами в Хаскеле приводят к проблемам в программах.

N> Вроде и в Немерле есть режим (нужно бы зделать дефолтным, да шарписты вроде тебя обидятся ).


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

N>Довольно странно, учитывая твою квалификация. Может не надо быть таким предубеждённым


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

VD>>Я видел библиотечки помощьнее дотнетных.

N>Во-первых хотелось бы пример библиотек покруче. Во-вторых вебом мир не ограничен.

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

N>Ну у всех потребности разные. Питоном с SciPy, можно уже сегодня заменить MATLAB.


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

N>Дак вообще нет проблем для людей с головой, кроме нехватки времени.

Согласен.

N>Чего? Теперь ГУЙ можно в ХМЛ описывать, прогресс однако. Ну и синтегрировали контролы с Direct3D. Для игровиков наверно полезно, для большинства нет.


Ошибаешся. Просто это только начло пути. Пройдет лет 5 и сам увидишь что это была небольшая революция.

N>Да ладно не смеши, посмотри TurboGears, Pylon, Django, CherryPy и т.д.


И что там не будет что есть в АСТ.НЭТ?

N>Да, а пацаны и не знали. Я думал мы сравниваем библиотеки, а ты мне тут банал врубил.


Вообще то мы сравнивали языки. Питон и Руби.

VD>> А что до Явы как языка, то есть Скала.

N>Спасибо, я осведомлен. Согласен, вещь не плохая, но не скрипт.

А на кой тебе скрип-то если язык не менее гибок?
Это что волшебство какое-то "скрипт"?
Я вон погляжу фанаты Питона и Руби дико обижаются когда их языки скриптами называют. А ты роде как за приемущество это считашь.

VD>> Да и со скрптами там не все так плохо. От JRuby, до Груви.

N>Это полные альфы, даже тут питон (Jython) впереди...

Груви вроде еще год назад работал.

VD>>Ну, интеграция с С++ — это ахинея еще большая.

N>Ты в каком мире живешь?

В рельном. Обхожусь без С++ вот уже лет 5 и меня от этог все больше и больше прет.

N> В моем есть куча легаси кода, который завтра не исчезнет, даже если MS обьявит завтра, что Немерле это C# 4.


Ну, каждый сам выбирает что и как делать. Я бы по любому постарался избавиться от С++-ного кода. На худой конец завернул бы его в КОМ-обертку и считал бы, что это такой не изменяемый баласт. А все нове писал бы без него.

И ведь хрен поверит кто, что 7 лет назад я переубеждал Дельфистов писать на С++,
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Python VS Ruby
От: Jenyay http://jenyay.net
Дата: 23.03.07 05:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Куда он рулит? Меня лично от одного его синтаксиса воротит. А уж без паттерн-матчинга я уже вообще ломку начинаю испытвать. IDE для него вообще полноценных нет (а как их сделать то, без наличия статической информации о типах?).


По крайней мере к Eclipse есть плагин для питона. Свиду очень даже неплохо, даже какой-то рефакторинг есть, который правда иногда отказывается рефакторить.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Софт, исходники и фото
Re[11]: Python VS Ruby
От: novitk США  
Дата: 23.03.07 16:47
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD> Матлаб не знаю. Может он такой тормозной. А вот для реальных рассчетов Питон не пригоден даже с

VD> костылями прекомпиляции. Тут как-то проскативала пенисометрия — альфа-блэнд рассчитывали. Питон
VD> там отстал так, что его даже в рассчет было нельзя брать. И это с PyPy.

SciPy это библиотека для Питона написанная на C/Fortran. Качественная и большая. В дотнете такой нет. Альфа-блэнд на ней сделать весьма просто и скорость будет сишная, но к скорости питона это отношения не имеет, нам обоим это понятно. Но заказчику ведь все равно как оно там внутри, главное что бы было сделанно быстро и качественно.

VD> А на кой тебе скрип-то если язык не менее гибок? Это что волшебство какое-то "скрипт"?

VD> Я вон погляжу фанаты Питона и Руби дико обижаются когда их языки скриптами называют.
VD> А ты роде как за приемущество это считашь.

Я, как наверное и болшинство народа, занимаюсь внутренней автоматизацией, а не написанием целевого пакета. Если на каждый чих создавать проект, с мейками/антами бороться, компилять/линкать, то жизни не хватит. Нужен инструмент в котором я могу быстро интегрировать куски, пистать тесты, делать оболочки. ИМХО в данный момент лучше Питона на эту роль кандидата нет. При этом динамика мне нафиг не сдалась, а вот от интерпретатора я отказаться не могу. Он для меня, юниксоида-емаксиста, важнее всех твоих примочек в студии. Так что реальных кандидатов на замешения Питона на сегодня для меня два — Хаскелл и Немерле. Хаскелле очень приятен, но библиотеки пока до уровня Питона довольно далеки, поэтому и на Немерле смотрю с надеждой. А руби для меня это просто "reinvent the wheel", вкусовая добавка для тех кто к синтаксу на отступах не проникся.
Re[10]: Python VS Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.03.07 03:04
Оценка:
Здравствуйте, Jenyay, Вы писали:

J>По крайней мере к Eclipse есть плагин для питона. Свиду очень даже неплохо, даже какой-то


Плагины есть для всего. Но это слезы. Сравни хотя его функциональность хотя бы с той же для Явы в том же Эклипсе. Об IDEA я вообще молчу.

J>рефакторинг есть, который правда иногда отказывается рефакторить.


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

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

Статическая типизация — это как наличие карты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Python VS Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.03.07 03:05
Оценка:
Здравствуйте, novitk, Вы писали:

N>SciPy это библиотека для Питона написанная на C/Fortran.


Это я понял.

N> Качественная и большая. В дотнете такой нет.


В чем проблема импортировать? А интеловские могут и по шустрее оказаться.

N> Альфа-блэнд на ней сделать весьма просто и скорость будет сишная,


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

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


Боюсь ни того, ни другого так и не выйдет.

N>Я, как наверное и болшинство народа, занимаюсь внутренней автоматизацией, а не написанием целевого пакета. Если на каждый чих создавать проект, с мейками/антами бороться, компилять/линкать, то жизни не хватит.


Открываем к примеру студию. Жмет Ctrl+Shift+N выбираем тип проекта и начинам писать нужный нам код. Где в этом сценарии "борьба с ..."?

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


Ну, вот и объясни мне что она тебе дает? Я вот почему-то могу все тоже делать хоть на Шарпе. Среда с успехом заменяет интерпретатор.

N> Он для меня, юниксоида-емаксиста, важнее всех твоих примочек в студии.


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

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


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

N> А руби для меня это просто "reinvent the wheel", вкусовая добавка для тех кто к синтаксу на отступах не проникся.


А чё по англицки то? Изебретение колеса тоже неплохо звучит.

Незнаю. Мое эстетическое чувство ближе к Руби. Потом он если закрыть глаза на Перловые приколы (которые вроде как уже запрещены) по чище спроектирован. ООП в нем по приличнее (привычнее для человека с С-бэкграундом) поддерживается. И нет этих __жуть__ идентификаторов.
Ну, а на практике они мне оба не нужны. Я привык к винде со студией. А вней скрипты лишние. Я даже ВБ-шный скрипт в студии только в режиме запись/восроизведение пользую.
Когда возникает задачка что-то по бырому автоматизировать, то раньше брал шарп (может не так компактно как на Руби или Питоне, но зато быстро, быстрее чем многие на скрипатх ваяют). Сейчас вот уже на Немерле пробую. Если бы не глюки собственного творчества (гы-гы), то вообще класно. Как-то недели 2 (или 3?) назад надо было досовский файлик:
---------T--T-------T----------------------T--------------------T---------T---------------T---------------¬
¦ 1.02.07¦01¦    311¦30102 810 600000000001¦40502810700000000740¦ 44525848¦        хххх.хх¦               ¦
+--------+--+-------+----------------------+--------------------+---------+---------------+---------------+
¦ 1.02.07¦09¦      1¦70107 810 400001720370¦                    ¦        0¦          хх.хх¦               ¦
+--------+--+-------+----------------------+--------------------+---------+---------------+---------------+
...

разобрать. Ну, так в лучшем виде мнут за 20 наклепал программку в студии на Немерле. Воспользовался макрос-регекспапрсером. Дабавли пару преобразований и получил за в итоге Exele-евский файлик.
Мелочь, а приятно.
Ну, и нафига мне скрипты при этом? Не, я не спрорю, что наврено по объему кода было бы примерно так же. Но блин, интелисенс и знакомый фрэймворк его ведь не пропьешь!
Плюс никаких сомнений, что код из любомго положения летать будет как сверхзвуковой истербитель. И если что смогу это в серьезную программу переложить без проблем.
Получается я на одном языке и скрипт напишу за милую душу, и серьезную программу требующую произоводительности, и объемный проект. Так зачем не забивать винт и голову скриптами? Я о них лучше почитают . Может где интересная идея или еще что.
Вот сейчас становится актуальным параллельное программирование. Ждать пока к Руби или Питону что-то прикрутят? В Эрланге уже то что нужно есть, но вдеь это еще один язык/рантайм/проблемы. А тут я могу все что нужно сам прикрутить. А може кто-то другой прикрутит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Python VS Ruby
От: novitk США  
Дата: 25.03.07 07:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Там был вполне конкретный алгоритм. Да и не сможешь ты за один вызов

VD>все посчитать как надо. А любой переход в интерпретатор сразу посадит VD>производительность. В общем, одно дело вызывать готовое, а другое иметь
VD>вомзожность свое написать.

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

VD>Открываем к примеру студию. Жмет Ctrl+Shift+N выбираем тип проекта и

VD>начинам писать нужный нам код. Где в этом сценарии "борьба с ..."?

Можно вопрос? Ты bat-файлами в винде пользуешься или все время на Ctrl+Shift+N жмешь. Ответ я знаю, ты скажешь редко и очень маленькими. Ну а теперь представь большую корпоративную систему — 24х7, с громадными ночными бэтчами, кучей фидов, грид-фермой и т.д. и т.п. Ты предлагаешь ехешник на каждый процесс собирать?
А если какой-то параметр быстро поменять надо, а в конфигурационных файлах его нет, сколько времени уйдёт на то что бы собрать и оттестировать все как нужно в большой системе?

N> Нужен инструмент в котором я могу быстро интегрировать куски, пистать тесты,

N> делать оболочки. ИМХО в данный момент лучше Питона на эту роль кандидата нет.
N> При этом динамика мне нафиг не сдалась, а вот от интерпретатора я отказаться
N> не могу.

N>> Он для меня, юниксоида-емаксиста, важнее всех твоих примочек в студии.


VD> Вот с этого надо и начинать было. Там где нет приличной интегрированной

VD> среды, так скрипт предоставляет ее возможности в боле бедной среде.
VD> Но что если все же она есть?

Не хочу начинать очередной флейм, но ты вероятно мало видал реальных емаксистов. Да, на тренинг уходят годы, но правильно настроенный емакс в кодировании не сравнить ни с чем. Мне самому очень нравится студия, дебагер у них отменный, но емакс в умелых руках это нечто. Посмотри скринкаст какого-нибудь фанатика лиспа (Лисп сам по себе тут не причем, просто они все в емаксе), типа "Wiki in ten minutes" — должно впечатлить.

VD>А чё по англицки то? Изебретение колеса тоже неплохо звучит.

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

VD>Ну, а на практике они мне оба не нужны. Я привык к винде со студией.

VD>А вней скрипты лишние. Я даже ВБ-шный скрипт в студии только в режиме VD>запись/восроизведение пользую.
VD>Когда возникает задачка что-то по бырому автоматизировать, то раньше брал
VD>шарп (может не так компактно как на Руби или Питоне, но зато быстро, быстрее
VD>чем многие на скрипатх ваяют). Сейчас вот уже на Немерле пробую. Если бы не
VD>глюки собственного творчества (гы-гы), то вообще класно. Как-то недели 2 (или
VD>назад надо было досовский файлик:
--skipped--

Вот, смотри. Тут тебе было нужно регексп отладить, так? Можно воспользоваться где он встроен: грепом, студией, сайтом... Но кто сказал что там оно как в дотнете. Или просто инструмента нет. Ну например лист компрехеншен проверить на живых данных в дебагере. С библиотекой поиграться ,которую только что написал — сходу, без всяких там юнит тестов и прочих глупостей. Все делается в секунды с интерактивным рантаймом.

Потом как ты настраиваешь свои ехешники? Конфиг-файлами? Ну дак это все дополнительные телодвижения — читать, писать, таскать. Я зная что в студии это все хорошо сделано, но оно надо? У меня вся конфигурация хранится в программе, а про ХМЛ я вспоминая только когда мне какой-нибудь интероп нужен.

VD>Вот сейчас становится актуальным параллельное программирование. Ждать пока к Руби или Питону что-то прикрутят? В Эрланге уже то что нужно есть, но вдеь это еще один язык/рантайм/проблемы. А тут я могу все что нужно сам прикрутить. А може кто-то другой прикрутит.


Это ты про макросы в N? Я только за. Обидно только что их компилировать надо отдельно. Я понимая технические причины, но мне кажется — будет это весьма неудобно. Да и регресс по сравнению с плюсами не приятен.

А что до Эрланг, то кому нужно его и к питону прикрутит. Смотри Candygram и Stackless Python. Убого? Ну дак подтянут, если нужно будет. Главное в Эрланге не концепты, а качество исполнение. Вот со статической типизацией, которую вроде к Питону прикручивают, сложнее. Тут без серьёзной потери совместимости, боюсь, не обойтись. Но я слышал, что VB.NET вроде гибридный язык, где динамика и статика живёт вместе. Надо будет на досуге посмотреть.
Re[13]: Python VS Ruby
От: Пацак Россия  
Дата: 25.03.07 10:11
Оценка: :))
Здравствуйте, VladD2, Вы писали:

N>> А руби для меня это просто "reinvent the wheel", вкусовая добавка для тех кто к синтаксу на отступах не проникся.

VD>А чё по англицки то? Изебретение колеса тоже неплохо звучит.

ИМХО "изобретать велосипед" в контексте больше подходит.
Ку...
Re[14]: Python VS Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.03.07 16:50
Оценка:
Здравствуйте, novitk, Вы писали:

N>Нашёл оригинальную ветку — задача очень низкоуровневая. Согласен, динамика тут просядет конкретно, но я в общем и не предлагаю на питонах драйвера писать.


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

Варинтов получается не много. Или снова С++ в 20-30% кода. Или все же язык сравнимый со скриптами в выразительности и сравнимый с С++ в произвоидительности.

N>Можно вопрос? Ты bat-файлами в винде пользуешься или все время на Ctrl+Shift+N жмешь. Ответ я знаю, ты скажешь редко и очень маленькими.


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

N>Ну а теперь представь большую корпоративную систему — 24х7, с громадными ночными бэтчами, кучей фидов, грид-фермой и т.д. и т.п. Ты предлагаешь ехешник на каждый процесс собирать?

N>А если какой-то параметр быстро поменять надо, а в конфигурационных файлах его нет, сколько времени уйдёт на то что бы собрать и оттестировать все как нужно в большой системе?

Хороший вопрос. С удовольствиеми отвечу. На сегодня я склоняюсь к двум путям. Первый из них использование для автоматизации околопрограммистских процессов не командных интерпретаторов или даже скриптовых языков, а с помощью утилит вроде MSBuild, NAnt или Ant (что по сути одно и то же). Они обладают существнно большими возможностями. Это не просто способ передать управление внешней утилите (зависящей к тому же от платформы или наличия какого нибудь Цигвина), это полноценные среды управления контентом. Их можно расширять за счет внешних сборок/классов. Причем эти сборки пишутся на высокопроизводительных и безопасных языках из семейства .Net/Java. Таким образом решения получается весьма переносимыми и гибгими.

MSBuild/Ant это по сути make и batch в одном флаконе.

Ну, а когда нужно сделать просто некие действия (утилиту) можно и проектик создать.

Кстати, проекты VS2005 на сегодня — это MSBuild-файлы. Так что получается весьма комплексное решение.

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

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

N>Не хочу начинать очередной флейм, но ты вероятно мало видал реальных емаксистов.


В живую конечно мало. Но на форумах тут их море.

N> Да, на тренинг уходят годы, но правильно настроенный емакс в кодировании не сравнить ни с чем.


Это их глубокое заблуждение. По факту произвоидетльность "правильных емаксистов" не толко не привосходит производительность "правлиьных визуальщиков" (назовм их так), но и зачастую уступает им. Проверно на практике.

N>Мне самому очень нравится студия, дебагер у них отменный, но емакс в умелых руках это нечто. Посмотри скринкаст какого-нибудь фанатика лиспа (Лисп сам по себе тут не причем, просто они все в емаксе), типа "Wiki in ten minutes" — должно впечатлить.


Смотрел. Откровенно говоря не впечатляет. Согласен, что есть многое что есть в современных средах, но не более того. И уж причем тут скрипты я вообще понять не могу.
Мы же вроде бы о скриптах говорили? Так вот прелесть студии в том, что она за счет своей интегрированности и своих фич нивелирует приемущества скрптов. Так если равнить интерактивность разработки, то она практически идентичная. Согласен, что не сравнить интерактивность скрипта с шелом и C# без оного, но вот уже с оным в виде студии сравнить можно. И C# отнюдь не проигрывает.

N>Пожалуй, тормознул. Пытался секунд двадцать подобрать русский оборот, потом плюнул, и подумал — так пройдёт.




N>Вот, смотри. Тут тебе было нужно регексп отладить, так?


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

N> Можно воспользоваться где он встроен: грепом, студией, сайтом... Но кто сказал что там оно как в дотнете.


Дык для отладки регекспов существуют охринительные визуальтые утилиты. Например:
http://www.codeproject.com/dotnet/expresso.asp
Была вообще офигительная утилита, но адресс ее не помню. Она была проста как три копейки, но удобна до обалдения. Просто выделяла разобранные выражения жирным, но было очень удобно.

N> Или просто инструмента нет. Ну например лист компрехеншен проверить на живых данных в дебагере.


Откровенно говря не нравится мне он. Больше предпочитаю с фнкциями работать. Но опять же какие пролемы? В C# есть поддержка окна Imediate в котором можно выполнить простенький код. Для того же немерла есть Nemerlish.

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


Тоже не проблема. Создал тесковый проектим или из того Imediate/Nemerlish. Кому что удобнее.

N>Потом как ты настраиваешь свои ехешники? Конфиг-файлами? Ну дак это все дополнительные телодвижения — читать, писать, таскать. Я зная что в студии это все хорошо сделано, но оно надо? У меня вся конфигурация хранится в программе, а про ХМЛ я вспоминая только когда мне какой-нибудь интероп нужен.


Непонимаю, а в чем тут разница? Ну, храни конфигурацию в коде если тебе нравится. А захочешь вынести, то же не проблема.

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

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

N>Это ты про макросы в N?


Ага.

N> Я только за. Обидно только что их компилировать надо отдельно. Я понимая технические причины, но мне кажется — будет это весьма неудобно. Да и регресс по сравнению с плюсами не приятен.


На самом деле это довольно удобно. Нужа только поддержка в IDE. В принципе в последних версиях нашей Интеграции она уже имется. Слабая пока, но все же можно скомпилировать код макроса и поглядеть на то что он генерирует (в хинте).
Все же расширения языка — это не скрипты на пять минут. Так что отдельная их компиляция вполне размна.

N>А что до Эрланг, то кому нужно его и к питону прикрутит.


Сильно сомневаюсь.

N> Смотри Candygram и Stackless Python. Убого?


Не видел.

N> Ну дак подтянут, если нужно будет. Главное в Эрланге не концепты, а качество исполнение. Вот со статической типизацией, которую вроде к Питону прикручивают, сложнее. Тут без серьёзной потери совместимости, боюсь, не обойтись. Но я слышал, что VB.NET вроде гибридный язык, где динамика и статика живёт вместе. Надо будет на досуге посмотреть.


VB.NET статически-типизированный язык с возможностью преходить на динамику. Это немного не то. Это скорее ближе к макросу Немерла late. Только там это управляется опциями компиляции. Не влючил strict и можно у лбого object-а вызвать методы в надежде на то, что в рантайме они будут.

Питон же пытается идти по пути Немерла или даже скоре Бу. Там будет вывод типов плюс аннотации типов. Но в отличии от Немерла если тип не выводится и не указан явно, то будет беззвучный переход в резим динамики. Что на мой взгляд плохо. Я за явное указание своих действий.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Python VS Ruby
От: novitk США  
Дата: 26.03.07 22:47
Оценка:
VD>MSBuild/Ant это по сути make и batch в одном флаконе. Ну, а когда нужно сделать
VD>просто некие действия (утилиту) можно и проектик создать. Понимаю, что на сегодня
VD>мало кто смотрел на проблему "скриптов" под таким углом, но мне кажется этот взгляд
VD>очень перспективен. Ну, а чтобы пдобными решениями могли пользоваться не только гуру,
VD>но и менее продвинутое население нужно создать некие визуальные утилиты которые
VD>нивелируют синтаксическое усложнение. По сути VS2005 одна из таких утилит .

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

Для меня кажется перспективней обратный подход — контент менежмент как компонента, внутри нормального языка. Пример смотри здесь http://www.scons.org/.

--Пропущен обоюдный флейм про емакс со студией--
VD>Мы же вроде бы о скриптах говорили?
Я это начал про то, что для меня "on the fly compilation" (не зная правильного термина на русском, подскажи. Динамическая компиляция?) имеет приоритет перед фишками IDE. И уж поверь мне, что студию и решарпер я знаю и очень ценю, но истина дороже.

VD>Так вот прелесть студии в том, что она за счет своей интегрированности и своих фич

VD>нивелирует приемущества скрптов. Так если равнить интерактивность разработки, то она
VD>практически идентичная. Согласен, что не сравнить интерактивность скрипта с шелом и
VD>C# без оного, но вот уже с оным в виде студии сравнить можно. И C# отнюдь не проигрывает.

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

N>>Вот, смотри. Тут тебе было нужно регексп отладить, так?

VD>Ага. Регексп был не самый просто, но все же на уровне того что я почти на изусть могу написать.
N>> Можно воспользоваться где он встроен: грепом, студией, сайтом... Но кто сказал что там оно как в дотнете.
VD>Дык для отладки регекспов существуют охринительные визуальтые утилиты. Например:
VD>http://www.codeproject.com/dotnet/expresso.asp
VD>Была вообще офигительная утилита, но адресс ее не помню.

Ну дак я так и сказал — для регекспов есть куча инструментов. А вот для моей библиотеки XYZ, пока нет и не предвидеться —
мне нужна универсальная отвёртка.

N>> Или просто инструмента нет. Ну например лист компрехеншен проверить на живых данных в дебагере.

VD>Откровенно говря не нравится мне он. Больше предпочитаю с фнкциями работать.

Напрасно, пермутировать(есть такое слово в русском новоязе?) быстро и удобно. В питоне они кстати быстрей чем мэп с фильтром, но это конечно из-за отсутствия инлайнов.

VD>В C# есть поддержка окна Imediate в котором можно выполнить простенький код. Для того же немерла есть Nemerlish.

VD>Тоже не проблема. Создал тесковый проектим или из того Imediate/Nemerlish. Кому что удобнее.

Вот это шаг в правильном направлении. Что IronPython-то не упомянул?

VD>Непонимаю, а в чем тут разница? Ну, храни конфигурацию в коде если тебе нравится.

VD>А захочешь вынести, то же не проблема.

Если не вынести, то пересобирать на каждый чих не охота, да и как определить что именно захардкодол. А вынести — код писать лень.

VD>Вот и получается, что скрпты это больше привычка. А если я к ним не приык, то мне проще как раз без них обойтись.

VD>Динамическая типизация позволила скоранить код за счет остуствия типов. Но времена меняеются. Появляются языки
VD>лишенные недостатокв С++. И роль скриптов нивелируется.

Почти согласен. Динамическая типизация — плохо. А вот динамическая компиляция рулез. Для меня главное в скриптах именно это.

N>>А что до Эрланг, то кому нужно его и к питону прикрутит.

VD>Сильно сомневаюсь.

Я привёл проекты которые создают среду Эрланга в питоне. Stackless — лёгкие нити и сопрограммы, а Candygram — паттерн матчинг и каналы.

VD>VB.NET статически-типизированный язык с возможностью преходить на динамику. Это немного не то.

VD>Это скорее ближе к макросу Немерла late. Только там это управляется опциями компиляции.
VD>Не влючил strict и можно у лбого object-а вызвать методы в надежде на то, что в рантайме они будут.
VD>Питон же пытается идти по пути Немерла или даже скоре Бу. Там будет вывод типов плюс аннотации типов.
VD>Но в отличии от Немерла если тип не выводится и не указан явно, то будет беззвучный переход в резим
VD>динамики. Что на мой взгляд плохо. Я за явное указание своих действий.

Понял, спасибо.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.