Задумался тут.... А зачем они нужны?

Использование из Питона или Руби FCL или библиотек Java? Удовольствие сомнительное и вряд ли такое уж нужно.
Использовать программируя на .NET каких-то Руби библиотек? Тоже как-то обходились.
Писать .NET сборки на них, возможным не представляется, ибо компилятора в байт код нету.

Я понимаю что интеграция всего и вся рулит, но многие ли это реально будут использовать? —

Здравствуйте, ie, Вы писали:

ie>Задумался тут.... А зачем они нужны?

ie>Использование из Питона или Руби FCL или библиотек Java? Удовольствие сомнительное и вряд ли такое уж нужно.
ie>Использовать программируя на .NET каких-то Руби библиотек? Тоже как-то обходились.
ie>Писать .NET сборки на них, возможным не представляется, ибо компилятора в байт код нету.

ie>Я понимаю что интеграция всего и вся рулит, но многие ли это реально будут использовать? —

Ну, сейчас как бы принято считать, что "идеальная среда" для разработки — серьезная платформа (Net, Java) с серьезным надежным языком (C#, Java) плюс "несерьезный" (нестрогий) язык с примесью функциональщины и кучей синтаксического сахара (помимо Python и Ruby есть еще с десяток, наверное проектов по скрещиванию раной степени безумности). Более подробная информация по этим вопросам с полпинка находится в Гугле. Также можно сходить на сайт OSCON'а и посмотреть название докладов на последней конференции. Или вот (цитата из описания последней JavaOne):

...Решение от Sun [платформа Java], продолжающее оставаться далеко впереди по переносимости программ, постепенно сокращает разрыв и в количестве языков, доступных разработчику. Помимо Java и свежеобъявленного VB, на конференции обсуждались Jython (Python for Java), Jruby (Ruby for Java), Groovy (существующая только на этой платформе помесь Python, Ruby и Smalltalk) и даже PHP — в этой области никаких революционных новостей не было, но темпы эволюционного развития продолжают оставаться очень высокими.

Здравствуйте, ie, Вы писали:

ie>Задумался тут.... А зачем они нужны?

ie>Использование из Питона или Руби FCL или библиотек Java? Удовольствие сомнительное и вряд ли такое уж нужно.
ie>Использовать программируя на .NET каких-то Руби библиотек? Тоже как-то обходились.

Ну скрипты писать. Используют же СPython + C++, теперь можно будет IronPython + .NET.
Просто другая платформа.

ie>Писать .NET сборки на них, возможным не представляется, ибо компилятора в байт код нету.
Ну и ладно, как всегда, в исходниках. IronPython овский движок можно встраивать в свои приложения.

ie>Я понимаю что интеграция всего и вся рулит, но многие ли это реально будут использовать? —

Ну если используют Python и Ruby, почему бы не иcпользовать IronPython и JRuby.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Ну, сейчас как бы принято считать, что "идеальная среда" для разработки — серьезная платформа (Net, Java) с серьезным надежным языком (C#, Java) плюс "несерьезный" (нестрогий) язык с примесью функциональщины и кучей синтаксического сахара (помимо Python и Ruby есть еще с десяток, наверное проектов по скрещиванию раной степени безумности).

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

Здравствуйте, ie, Вы писали:

ie>Задумался тут.... А зачем они нужны?

ie>Использовать программируя на .NET каких-то Руби библиотек? Тоже как-то обходились.
ie>Писать .NET сборки на них, возможным не представляется, ибо компилятора в байт код нету.

Интеграция Руби и пр. и .net/java хороша, например, тем, что мы можем писать ядро приложения на "серьезном" языке, а обвязку на скриптах. Т.е. для тех же задач, для которых предназначен JScript.Net. Вот только нельзя не признать, что JScript куда менее приятный язык, чем Python или Ruby. Ну хотя бы с точки зрения выразительности языков и оверхеда™.

Здравствуйте, Красин, Вы писали:

К>Интеграция Руби и пр. и .net/java хороша, например, тем, что мы можем писать ядро приложения на "серьезном" языке, а обвязку на скриптах.

Проблема в том, что "серьезным" языкам такая обвязка практически не нужна, так как их уровень (по крайней мере C# 2.0, а уж 3.0 и подавно) практически идентичен. Так что рельной выгоды увидить не получится. Вот связка С++ + Руби/Питон может и имела смысл в прошлом (или там где Ява/дотнет не применимы).

Здравствуйте, Красин, Вы писали:

К>Здравствуйте, ie, Вы писали:

ie>>Задумался тут.... А зачем они нужны?

ie>>Использовать программируя на .NET каких-то Руби библиотек? Тоже как-то обходились.
ie>>Писать .NET сборки на них, возможным не представляется, ибо компилятора в байт код нету.

К>Интеграция Руби и пр. и .net/java хороша, например, тем, что мы можем писать ядро приложения на "серьезном" языке, а обвязку на скриптах. Т.е. для тех же задач, для которых предназначен JScript.Net. Вот только нельзя не признать, что JScript куда менее приятный язык, чем Python или Ruby. Ну хотя бы с точки зрения выразительности языков и оверхеда™.

Кстати JScript.Net это уже JavaScript 2.0 насколько мне память не изменяет.
А это вообще далеко не тот язык что традиционно думается про JS.

JavaScript 2.0 это:

Typed and typeless variables
Classes (inheritance, function overloading, etc)
Packages

Здравствуйте, VladD2, Вы писали:

К>>Интеграция Руби и пр. и .net/java хороша, например, тем, что мы можем писать ядро приложения на "серьезном" языке, а обвязку на скриптах.

VD>Проблема в том, что "серьезным" языкам такая обвязка практически не нужна, так как их уровень (по крайней мере C# 2.0, а уж 3.0 и подавно) практически идентичен. Так что рельной выгоды увидить не получится. Вот связка С++ + Руби/Питон может и имела смысл в прошлом (или там где Ява/дотнет не применимы).

Поясни что ты имеешь ввиду? "Их уровень практически идентичен" ... чему? Скриптовым языкам?
Какой смысл ты вкладываешь в словосочетание "скриптовый язык"?

Здравствуйте, c-smile, Вы писали:

CS>Поясни что ты имеешь ввиду? "Их уровень практически идентичен" ... чему? Скриптовым языкам?

Лучшим их представителям — Руби и Питону.

CS>Какой смысл ты вкладываешь в словосочетание "скриптовый язык"?

Динамически тпизированным языкам не требующим стадии компиляции.
http://en.wikipedia.org/wiki/Scripting_programming_language
Если угодно можно заменить название на динамически типизированные. Суть от этого не изменится.

Здравствуйте, VladD2, Вы писали:

К>>Интеграция Руби и пр. и .net/java хороша, например, тем, что мы можем писать ядро приложения на "серьезном" языке, а обвязку на скриптах.

VD>Проблема в том, что "серьезным" языкам такая обвязка практически не нужна, так как их уровень (по крайней мере C# 2.0, а уж 3.0 и подавно) практически идентичен. Так что рельной выгоды увидить не получится. Вот связка С++ + Руби/Питон может и имела смысл в прошлом (или там где Ява/дотнет не применимы).

А вот мы у себя прикрепляем поддержку скриптов к генератору отчётов. В частности, по-умолчанию будет работать реализация с IronPython. Кончено, может можно прикрутить и C#. Но как скомпилировать вот такое выражение:

document.Write(a + b);

не прописывая using, class и static? И вообще, что-то я не видел хороших C#-парсеров, заточенных вот под такие задачи. А на Python

print a + b

уже законченная программа. И вообще, в таких "скриптовых" вещах, типа обработки форматированного текста и графики очень много вещей с нестрогой типизацией. На C# пришлось бы писать кучу скобок, as и is, что бы преобразовать что-то к чему-то. А ещё пришлось бы писать типы переменных, чтобы их объявить. Так что в отчётах лучше смотрятся (и проще туда встраиваются) скриптовые языки типа JavaScript, Python или ... Лисп

Здравствуйте, c-smile, Вы писали:

CS>Кстати JScript.Net это уже JavaScript 2.0 насколько мне память не изменяет.
CS>А это вообще далеко не тот язык что традиционно думается про JS.

CS>JavaScript 2.0 это:

CS> Typed and typeless variables
CS> Classes (inheritance, function overloading, etc)
CS> Packages

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

2.times { print "lala" }

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

Здравствуйте, Красин, Вы писали:

К>Все это очень полезно, но JavaScript остается неудобным языком в силу того, что он мало пользуется преимуществами своей динамичности. В отличие от всяких руби и питонов, в которых можно делать что-то типа:
К>

2.times { print "lala" }

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

Выразительность кода — это важно. Согласен.

Но в принципе это вот не сильно хуже:

while(n--) { stdout << "lala" }

Здравствуйте, konsoletyper, Вы писали:

K>А вот мы у себя прикрепляем поддержку скриптов к генератору отчётов. В частности, по-умолчанию будет работать реализация с IronPython. Кончено, может можно прикрутить и C#.

Хочешь добрый совет который сэкономит вам пару лет работы?

Купите Report Sharp Shooter. Он уже работает и использует в качестве скриптов C#.

K>Но как скомпилировать вот такое выражение:

K>

K>document.Write(a + b);
K>

K>не прописывая using, class и static?

Думаю ты достаточно умен чтобы и сам додуматься до того как решить эту не самую сложную проблему.

K>уже законченная программа. И вообще, в таких "скриптовых" вещах,

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

K> типа обработки форматированного текста и графики очень много вещей с нестрогой типизацией.

К сведению... У Руби и Питона очень строгая типизация. Просто она динамическая. Что в сущности огромный недостаток. Но не все это понимают.

K> На C# пришлось бы писать кучу скобок, as и is, что бы преобразовать что-то к чему-то.

Неявные приведения типов (в размуных пределах) спасут отцов русской демократии.

K> А ещё пришлось бы писать типы переменных, чтобы их объявить.

А еще можно было бы получить интелисенс который нивилировал бы эту проблему.

K> Так что в отчётах лучше смотрятся (и проще туда встраиваются) скриптовые языки типа JavaScript, Python или ... Лисп

Боюсь Лисп это не для тех кто будет заниматься отчетами. А JavaScript и Python не имеют реальных приемуществ по сравнению с Шарпом.

Здравствуйте, Красин, Вы писали:

К>

2.times { print "lala" }

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

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

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

2.times (() => print("lala"))

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

Здравствуйте, c-smile, Вы писали:

CS>Но в принципе это вот не сильно хуже:

CS>

while(n--) { stdout << "lala" }

Это намного хуже.
1. n может быть равна -1.
2. Речь об общих принципах, а не о частном случае. Декомпозиция функций в с исползованием лямбд (анонимных блоков если вести речь о Руби), замыканий и функций высшего порядка несмоненно позволяет создать более краткий понятный код. Вот только к динамике это отньшения не имеет.

Здравствуйте, VladD2, Вы писали:

K>>А вот мы у себя прикрепляем поддержку скриптов к генератору отчётов. В частности, по-умолчанию будет работать реализация с IronPython. Кончено, может можно прикрутить и C#.

VD>Хочешь добрый совет который сэкономит вам пару лет работы?

VD>Купите Report Sharp Shooter. Он уже работает и использует в качестве скриптов C#.

У нас не так много денег, чтобы покупать подобные вещи. А вообще стоит подумать. Может быть, стоит просто подождать и купить сторонюю софтину. Однако, к тому же Report Sharp Shooter позволяет прикручивать разные языки для скриптов? У нас же есть уже рабочий, проверенный генератор отчётов, прикрутить поддержку Python'а к нему будет не так уж и трудно, благо всё для этого имеется (потому не пару лет, а всего 1 человеко-месяц, просьба не смеяться ).

K>>Но как скомпилировать вот такое выражение:

K>>

K>>document.Write(a + b);
K>>

K>>не прописывая using, class и static?

VD>Думаю ты достаточно умен чтобы и сам додуматься до того как решить эту не самую сложную проблему.

В том то и проблема, что штатных средств в том же Framework нет. Нужно пользоваться сторонними библиотеками. Но и они не приспособлены для таких задач. Придётся извращаться. Или писать свой парсер. Короче, с Python всё гораздо проще. А вообще у нас на работе было немало споров по этому вопросу, однако ж все пришли к единому мнению, что kexit прикрутить Python.

K>>уже законченная программа. И вообще, в таких "скриптовых" вещах,

VD>Это отчеты, то скриптовая вещь? А мне казалось, что отчеты делают редко, а используют часто. Тут просто сама собой просится компиляция.

У нашей софтины среди преимуществ числится:

высокая адаптивность к бизнес-процессам предприятия

Порой бывает, что звонят клиенты и срочно требуют прикрутить какую-то фичу. В общем, код отчётов модифицируется весьма часто. Кстати, те же сайты тоже пишутся один раз, а используются много. Почему же они пишутся на Ruby, PHP, Python? На самом деле, и в случае отчётов, и в случае с сайтами подошла бы и компиляция, благо для нескольких строк C# она делается моментально. Хотя, тот же Python можно компилировать. Просто ключевым является слово "текст", который в языках типа Pyhon'а обрабатывать проще.

K>> типа обработки форматированного текста и графики очень много вещей с нестрогой типизацией.

VD>К сведению... У Руби и Питона очень строгая типизация. Просто она динамическая. Что в сущности огромный недостаток. Но не все это понимают.

Да, точно. В этой терминоглогии столько нюансов, что я аж путаюсь. А вот в Лиспе нестрогая типизация или она вообще отсутствует?

K>> А ещё пришлось бы писать типы переменных, чтобы их объявить.

VD>А еще можно было бы получить интелисенс который нивилировал бы эту проблему.

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

K>> Так что в отчётах лучше смотрятся (и проще туда встраиваются) скриптовые языки типа JavaScript, Python или ... Лисп

VD>Боюсь Лисп это не для тех кто будет заниматься отчетами.

Это была шутка. Конечно же, Лисп мощнее, но не всякий смирится с (write (+ a b)).

VD>А JavaScript и Python не имеют реальных приемуществ по сравнению с Шарпом.

Как языки — да (хотя по поводу Python'а можно поспорить). Для решения конкретной задачи они подходят лучше. Вообще, неразумно для решения всех задач использовать один мегаязык. Лучше использовать несколько языков, каждый для решения определённого класса задач. Хотелось бы, чтобы между ними можно было без проблем наладить взаимодейсвие.

Здравствуйте, Зверёк Харьковский, Вы писали:

ie>>Я понимаю что интеграция всего и вся рулит, но многие ли это реально будут использовать? —

ЗХ>Ну, сейчас как бы принято считать, что "идеальная среда" для разработки — серьезная платформа (Net, Java) с серьезным надежным языком (C#, Java) плюс "несерьезный" (нестрогий) язык с примесью функциональщины и кучей синтаксического сахара (помимо Python и Ruby есть еще с десяток, наверное проектов по скрещиванию раной степени безумности).

Да я с этим то согласен. Просто в таком виде в котором это есть сейчас (сужу по IronPython) — область применения еще надо поискать.

Здравствуйте, Андрей Хропов, Вы писали:

ie>>Использование из Питона или Руби FCL или библиотек Java? Удовольствие сомнительное и вряд ли такое уж нужно.
ie>>Использовать программируя на .NET каких-то Руби библиотек? Тоже как-то обходились.

АХ>Ну скрипты писать. Используют же СPython + C++, теперь можно будет IronPython + .NET.
АХ>Просто другая платформа.

Да, пожалуй, применение то найдут, но для меня это пока сродни экзотике.

ie>>Писать .NET сборки на них, возможным не представляется, ибо компилятора в байт код нету.
АХ>Ну и ладно, как всегда, в исходниках. IronPython овский движок можно встраивать в свои приложения.

Вот это уже интересней. Надо попробовать.
А вообще мне понравилось, как в этом плане поступили с JScript, компилятор втыкает движок сам.

ie>>Я понимаю что интеграция всего и вся рулит, но многие ли это реально будут использовать? —
АХ>Ну если используют Python и Ruby, почему бы не иcпользовать IronPython и JRuby.

Вот я и хочу спросить у людей использующих IronPython и JRuby (именно их, а не тех что юзают Python и Ruby), зачем они это делают

Здравствуйте, konsoletyper, Вы писали:

K>У нас не так много денег, чтобы покупать подобные вещи.

Ладно тебе. Он стоит не так уж дорого. Уж точно дешевле чем зарплата тех кто создает аналог самостоятельно.

K> А вообще стоит подумать.

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

K> Может быть, стоит просто подождать и купить сторонюю софтину. Однако, к тому же Report Sharp Shooter позволяет прикручивать разные языки для скриптов?

Незнаю. Я его давно смотрел. Тогда был тольк C#. Но принципиально там проблем быть не должно. Я сам за день клепал пример динамической компиляции. Да вот же он. С тех пор в файлах валяется.

K> У нас же есть уже рабочий, проверенный генератор отчётов, прикрутить поддержку Python'а к нему будет не так уж и трудно, благо всё для этого имеется (потому не пару лет, а всего 1 человеко-месяц, просьба не смеяться ).

А мне на вот тот компилятор пришлось потратить ровно 3 часа.

K>В том то и проблема, что штатных средств в том же Framework нет. Нужно пользоваться сторонними библиотеками.

Да, ладно тебе. Конкатинации строк более чем достаточно.

K> Но и они не приспособлены для таких задач. Придётся извращаться. Или писать свой парсер. Короче, с Python всё гораздо проще. А вообще у нас на работе было немало споров по этому вопросу, однако ж все пришли к единому мнению, что kexit прикрутить Python.

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

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

А вот в рантайме вы сэкономите не мало процессоного времени, так как уже второй прогон будет давать реальный выигрышь в быстродействии.

K> Кстати, те же сайты тоже пишутся один раз, а используются много. Почему же они пишутся на Ruby, PHP, Python?

По-моему, по глупости. ASP.NET тут ни в чем скриптам не уступает. Динамичность та же. Возможностей больше.

K> На самом деле, и в случае отчётов, и в случае с сайтами подошла бы и компиляция, благо для нескольких строк C# она делается моментально. Хотя, тот же Python можно компилировать.

Python? Его можно пытаться компилировать на довольно сырых средствах.

K> Просто ключевым является слово "текст", который в языках типа Pyhon'а обрабатывать проще.

Это смотря с чем сравнивать. Хотя для отчетов вам вообще нужны очень примитивные фукнции которы почти на любом языке сделать можно.

K>Да, точно. В этой терминоглогии столько нюансов, что я аж путаюсь. А вот в Лиспе нестрогая типизация или она вообще отсутствует?

Лисп динамически типизировный, типобезопасный язык (причем, например Common Lisp позволяет делать необязательные аннотации типов, что зволяет компилировать части кода). Отсуствовать типизация строго говоря не может быть. Она может быть "плохой". Термины "строгая" и "не строгая" в плохи так как допускают разную трактовку. Правильно говорить "типобезопасный" и "не типобезопасный". Вот например:

        Статически (+)                     С обязательной
        типизировный       Типобезопасный  аннотацией типов
-----------------------------------------------------------
C       +                  -               +
C++     +                  -               +
Lisp    -                  +               -
Ruby    -                  +               -
Pyton   -                  +               -
C#      +                  +               +
Java    +                  +               +
Nemerle +                  +               -

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

А кто же их заставляет делать?
К тому же я лично представляю себе редактирование отчета в неком дизайнере. Тогда эти строки будут не более чем маленькие выражения которые покзываются только по требованию (именно так и было в ШарпШутере).

K>Это была шутка. Конечно же, Лисп мощнее, но не всякий смирится с (write (+ a b)).

Вот именно.

K>Как языки — да (хотя по поводу Python'а можно поспорить). Для решения конкретной задачи они подходят лучше. Вообще, неразумно для решения всех задач использовать один мегаязык.

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

K> Лучше использовать несколько языков, каждый для решения определённого класса задач. Хотелось бы, чтобы между ними можно было без проблем наладить взаимодейсвие.

Лучше использовать специализированные зяки (DSL-и), которые очень легко изучать и которые позволяют лучше контролировать процесс. А универсальный язык лучше иметь одни на проект.

Так что введение второго языка должно иметь очень серьезные основания.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:

CS>>Но в принципе это вот не сильно хуже:

CS>>

while(n--) { stdout << "lala" }

VD>Это намного хуже.
VD>1. n может быть равна -1.

согласен. (n-- >= 0) тогда.или for

Синтакчическая конструкция 2.times для компилятора — грабли еще те — хуже только C++ .

VD>2. Речь об общих принципах, а не о частном случае. Декомпозиция функций в с исползованием лямбд (анонимных блоков если вести речь о Руби), замыканий и функций высшего порядка несмоненно позволяет создать более краткий понятный код. Вот только к динамике это отньшения не имеет.

"Декомпозиция функций в с исползованием лямбд"

каждое слово в отдельности понимаю. вместе — нет. Колись давай что ты имеешь ввиду.

Касательно лямбд. В JS они есть.

[4,3,2,1].sort( function(l,r){return l<r} );

Что "шумит" немного больше чем аналогичное выражение в Ruby.

У меня в tiscript кстати это выглядит так

[4,3,2,1].sort( @(l,r){return l<r} );

Но это уже не суть важно.