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

E>

E>bash$ sort text.txt > out.txt
E>

Уел! Но, сугубо флейма для, изменим постановку задачи. Пусть требуется вывести перестановку, упорядочивающую файл.

"out.txt" 0: $< 0: "text.txt"

А как это будет на bash?

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

FR>Пока ты будешь писать свой пробельный язык я давно уже решу эту же задачу одной строкой кода в питоне. Разработку питон сильно ускоряет.

Да, зато DSL (Domain Specific Language) по времени выгоднее. Стоимость старта определенно выше, зато из-за того, что DSL лучше подходит под решение задачи (собственно, для этого он разрабатывается), стоимость разработки на DSL ниже.

Есть вообще мнение, что выгоднее вместо General Purpose Languages использовать DSL и развитие в ближайшем будущем должно идти в сторону удешевления создания DSL.

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

FR>Угу я вот недавно задолбался править одну Java утилитку, на каждый чих нагородили классов, в этих {} уже как в лисповских скобках начал путатся, если бы переписать это хоть на си, не говоря уже о питоне в процедурном стиле было бы намного проще.
На что спорим что я на питоне закриптую программу так что ты в ней озвереешь разбираться.

FR>Лично я не использую подобные утилиты, и не знаю есть ли подобное для питона, но не вижу проблем в ее написании для питона(кроме большого объема работы).
Есть очень большая проблема: Отсутствие статической типизации.

FR>Сам не объявит
За то очепятка очень даже может...

FR>Так ты же пользуешся левой утилитой ReSharper?
ReSharper не проверяет код. Он помогает его набивать, модифицировать и осуществлять навигацию. Те это часть IDE, а не компилятора.
Что называется почувствойте разницу.
FR>Раньше и для си был lint очень похож на PyCheker.
Вот только когда пишешь на С++ потребности во всяких lint'ах почемуто не возникает. Может из-за статической типизации?

FR>Проще писать программы, интерфейс файловых объектов стандартен, легко писать процедуры работающие с любыми файловыми объектами,
В .НЕТ тоже решается библиотекой.
FR>при этом для своих файловых объектов не требуется наследование от базового класса.
Сомнительное преймущество.

FR>Я видел скрипты из реальных игр,
Я тоже.
FR>и очень небольшая часть их выглядит также.
Ну не знаю например скрипты в "Vampire: The Masquerade Bloodlines" выглядят так как я показал. И не смотря на то что они написаны на питоне ниодной питоновской мегафичи я там не видел.
FR>Возможностей питона для них тоже вполне хватает,
Я с этим и не спорю вот только стоит ли связываться с питоном если есть C#2
FR>и как плюс они будут короче и понятней, осбенно настроечные скрипты с которыми работают дизайнеры, то есть те кто мало разбирается в кодировании.
Сильно сомневаюсь

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

Т>>Чисто для прикола:
Т>>

Т>>"out.txt" 0: t[<t: 0: "text.txt"]
Т>>

FR>Ruby?
Не, не Ruby. Это — Gaperton знает что.
FR>По моему питон читабельней, хотя Ruby тоже не плох
Согласен и с тем, и с другим.

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

FR>>Возможностей питона для них тоже вполне хватает,
WH>Я с этим и не спорю вот только стоит ли связываться с питоном если есть C#2

Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?

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

FR>>Лично я не использую подобные утилиты, и не знаю есть ли подобное для питона, но не вижу проблем в ее написании для питона(кроме большого объема работы).
WH>Есть очень большая проблема: Отсутствие статической типизации.

Здесь была большая тема по этому поводу: Типизация

Автор: Quintanar
Дата: 02.03.05

Причем начинал я в ней учавствовать стоя на таких же непримиримых позициях сторонника статической типизации.
Но затем стал более лояльным к таким динамическим языкам как Pyhton (убрать бы все-таки из него структуризацию посредством пробелов!) и Ruby. Имхо, динамическая типизация -- это интересная возможность. Просто нужно к ней по другому подходить. Ни и не для всех задач, имхо, она пригодно. Например, мне было бы стремно писать маршрутизатор SMS-трафика на Ruby именно из-за того, что я не смогу создать достаточное количество unit-тестов, чтобы весь код проверить (а сторонники динамически-типизированных языков часто приводят в качестве довода то, что нельзя доверять коду, который не был протестирован). А в случае статически типизированного языка я хотя бы могу быть уверен в отсутствии синтаксических ошибок даже в самых редкоиспользуемых ветвях моего кода. Но для небольших программ тот же Ruby может дать существенный прирост производительности в кодировании. А если к этому добавить, что сложные задачи можно решать правильно комбинируя простые и маленькие инструменты (т.н. unix way), то получается, что из маленьких Python (Ruby, Perl,...) скриптиков можно строить весьма сложные решения.

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

Т>Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?
Да стоит.
1)C# статически типизирован что позволяет отловить множество ошибок еще до тестирования.
2)Если все делать на C# то интеграция скриптов и основного кода получится автоматически и без оверхеда.
3)Для C# существуют мощные IDE с возможностью рефакторинга и прочими вкусностями.
4)C# исполняется быстрее.

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

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

Т>"out.txt" 0: $< 0: "text.txt"
Т>

"перестановка, упорядочивающая файл"?
Что тут написано? Попробовал подсунуть этот текст Эрлангу и Хаскелю — они его не поняли. Какой ещё язык Гапертон знает? Clean что ли?

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

E>Имхо, динамическая типизация -- это интересная возможность.
Нет она как парашют. В подавляющем большинстве случаев только мешается. Но иногда без нее никак. Вот на эти иногда возможностей .НЕТ болие чем достаточно.
E>Просто нужно к ней по другому подходить.
К ней вобще по возможности не нужно подходить.
E>Ни и не для всех задач, имхо, она пригодно. Например, мне было бы стремно писать маршрутизатор SMS-трафика на Ruby именно из-за того, что я не смогу создать достаточное количество unit-тестов, чтобы весь код проверить
E>(а сторонники динамически-типизированных языков часто приводят в качестве довода то, что нельзя доверять коду, который не был протестирован).
С этим никто не спорит вопрос в необходимом объеме тестов и времени на их прогонку.
E>А в случае статически типизированного языка я хотя бы могу быть уверен в отсутствии синтаксических ошибок даже в самых редкоиспользуемых ветвях моего кода.
И многих семантических.
E>Но для небольших программ тот же Ruby может дать существенный прирост производительности в кодировании.
Ты на шарпе с решарпером писал?
E>А если к этому добавить, что сложные задачи можно решать правильно комбинируя простые и маленькие инструменты (т.н. unix way), то получается, что из маленьких Python (Ruby, Perl,...) скриптиков можно строить весьма сложные решения.
Вот только без интеграционных тестов оно всеравно работать не будет.

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

E>"перестановка, упорядочивающая файл"?
E>Что тут написано? Попробовал подсунуть этот текст Эрлангу и Хаскелю — они его не поняли. Какой ещё язык Гапертон знает? Clean что ли?
Я думаю К

Автор: Трурль
Дата: 19.04.05

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

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

FR>>Угу я вот недавно задолбался править одну Java утилитку, на каждый чих нагородили классов, в этих {} уже как в лисповских скобках начал путатся, если бы переписать это хоть на си, не говоря уже о питоне в процедурном стиле было бы намного проще.
WH>На что спорим что я на питоне закриптую программу так что ты в ней озвереешь разбираться.

Конечно напишешь Но суть в том что создатели java и C# выкинув процедурный стиль просто принуждают из простейших вещей делать криптокод.

FR>>Лично я не использую подобные утилиты, и не знаю есть ли подобное для питона, но не вижу проблем в ее написании для питона(кроме большого объема работы).
WH>Есть очень большая проблема: Отсутствие статической типизации.

Чем ее отсутствие помешает преименовыванию методов и т. п.

FR>>Сам не объявит
WH>За то очепятка очень даже может...

FR>>Так ты же пользуешся левой утилитой ReSharper?
WH>ReSharper не проверяет код. Он помогает его набивать, модифицировать и осуществлять навигацию. Те это часть IDE, а не компилятора.
WH>Что называется почувствойте разницу.

и что?

FR>>Раньше и для си был lint очень похож на PyCheker.
WH>Вот только когда пишешь на С++ потребности во всяких lint'ах почемуто не возникает. Может из-за статической типизации?

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

FR>>Проще писать программы, интерфейс файловых объектов стандартен, легко писать процедуры работающие с любыми файловыми объектами,
WH>В .НЕТ тоже решается библиотекой.
FR>>при этом для своих файловых объектов не требуется наследование от базового класса.
WH>Сомнительное преймущество.

угу также как и шаблоны в плюсах

FR>>Я видел скрипты из реальных игр,
WH>Я тоже.
FR>>и очень небольшая часть их выглядит также.
WH>Ну не знаю например скрипты в "Vampire: The Masquerade Bloodlines" выглядят так как я показал. И не смотря на то что они написаны на питоне ниодной питоновской мегафичи я там не видел.
FR>>Возможностей питона для них тоже вполне хватает,
WH>Я с этим и не спорю вот только стоит ли связываться с питоном если есть C#2

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

FR>>и как плюс они будут короче и понятней, осбенно настроечные скрипты с которыми работают дизайнеры, то есть те кто мало разбирается в кодировании.
WH>Сильно сомневаюсь

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

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

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

FR>>Пока ты будешь писать свой пробельный язык я давно уже решу эту же задачу одной строкой кода в питоне. Разработку питон сильно ускоряет.

WF>Да, зато DSL (Domain Specific Language) по времени выгоднее. Стоимость старта определенно выше, зато из-за того, что DSL лучше подходит под решение задачи (собственно, для этого он разрабатывается), стоимость разработки на DSL ниже.

WF>Есть вообще мнение, что выгоднее вместо General Purpose Languages использовать DSL и развитие в ближайшем будущем должно идти в сторону удешевления создания DSL.

http://www.iso.ru/journal/articles/print/264.html

Трурль wrote:
> Здравствуйте, WolfHound, Вы писали:
> Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?
стоит ли шить сапоги если мы уже умеем плести лапти?
Питон безусловно хорошая вещь (это я по дискуссии сужу), но для своих
целей. И как лапти хороши сегодня для сувенира иностранцу, так сапоги
для того, чтобы использовать их в качестве обуви. В лаптях конечно тоже
можно ходить (ну ходили же наши предки), но не далеко.
Да, конечно, прикольно не иметь статической типизации, все мочить в коде
и т.д. Но это вряд ли сильно положительно скажется на простоте поддержки
разрабатываемой системы, ее расширяемости, простоте отладки и т.д.
Юнит-тесты это хорошо, но строгая типизация — куда более строгий
инструмент. И вряд ли отсутствие типизации ускорит разработку, учитывая
что юнит-тестов надо написать куда больше, плюс отлаживаться придется
дольше. Благо дизайн приложений уже довольно развит, что дает
дополнительный аргумент в пользу наличия типизации. Такие штуки,
наверное, хороши для написания пакета утилит для администрирования и
т.п. для собственного пользования. Но писать промышленную систему,
которая будет здорово развиваться, я бы на них не стал.
Что касается библиотеки, то да, .NET предлагает менее развитую в
рассмотренных отношениях библиотеку. Но он ориентирован на разработку
корпоративных приложений, автоматизации бизнеса, а не утилит и игр. Если
есть специфическая потребность — ее надо осмыслить и один раз написать
нужную библиотеку.
Итого, всему свое место в жизни

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

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

E>>Просто нужно к ней по другому подходить.
WH>К ней вобще по возможности не нужно подходить.


Прикольно. Но это, имхо, вопрос религии.

E>>Ни и не для всех задач, имхо, она пригодно. Например, мне было бы стремно писать маршрутизатор SMS-трафика на Ruby именно из-за того, что я не смогу создать достаточное количество unit-тестов, чтобы весь код проверить
E>>(а сторонники динамически-типизированных языков часто приводят в качестве довода то, что нельзя доверять коду, который не был протестирован).
WH>С этим никто не спорит вопрос в необходимом объеме тестов и времени на их прогонку.

Так ведь чем больше тестов для статически типизированных программ, тем лучше. Если речь идет о качестве продукта, то вопрос не стоит ни в объеме ни во времени. Здесь этот аргумент сторонников динамически-типизированных языков непоколебим.

Хотя лично я уверен, что есть масса случаев, когда unit-тесты или автоматические integration- или regression-тесты просто неприменимы. Иметь в таких случаях поддержку со стороны статически типизированного языка -- это очень большой плюс.

E>>Но для небольших программ тот же Ruby может дать существенный прирост производительности в кодировании.
WH>Ты на шарпе с решарпером писал?

Нет. Я сейчас на C++ и vim . А сложные куски программ сначала на бумаге пишу -- зато потом и рефакторинг не нужен

E>>А если к этому добавить, что сложные задачи можно решать правильно комбинируя простые и маленькие инструменты (т.н. unix way), то получается, что из маленьких Python (Ruby, Perl,...) скриптиков можно строить весьма сложные решения.
WH>Вот только без интеграционных тестов оно всеравно работать не будет.
Ну эти слова можно отнести и к комплексам из программ, написанных на статически типизируемых языках.

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

FR wrote:
> Угу я вот недавно задолбался править одну Java утилитку, на каждый чих нагородили классов, в этих {} уже как в лисповских скобках начал путатся, если бы переписать это хоть на си, не говоря уже о питоне в процедурном стиле было бы намного проще.
кто ж спорит: низкокачественный код можно на чем угодно написать. И не
потому, что java плоха, а потому что руки у автора кривы Ну, либо
написано нормально, а чтец не привык к языку

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

WF>>Есть вообще мнение, что выгоднее вместо General Purpose Languages использовать DSL и развитие в ближайшем будущем должно идти в сторону удешевления создания DSL.

FR>http://www.iso.ru/journal/articles/print/264.html

До LISP-а ему в этом плане все равно далеко. В случае LISP-а мы имеем:

1) Любой синтаксис, который нам понравится.

2) DSL будет компилироваться (в LISP-код, а затем и в нативный при необходимости), а не интерпретироваться. В том числе есть обширные возможности для оптимизации или применения Partial Evaluation. И это все будет работать при компиляции кода, а не при его выполнении.

FR wrote:

> WH>На что спорим что я на питоне закриптую программу так что ты в ней
> озвереешь разбираться.
> Конечно напишешь Но суть в том что создатели java и C# выкинув
> процедурный стиль просто принуждают из простейших вещей делать криптокод.

Объясните, что вы понимаете под "процедурным стилем"? Код с глобальными
переменными и фукнциями?

> WH>Есть очень большая проблема: Отсутствие статической типизации.
> Чем ее отсутствие помешает преименовыванию методов и т. п.

Вот такой код:

class Test
    def test_method(self):
       ...
...
tst=some_external_function()
tst.test_method()

Предположим, что код класса "Test" и переменная tst расположены в разных
файлах в большом проекте из 5000 классов. Как нам теперь переименовать
метод test_method в new_test_method?

В языках со статической типизацией все просто — переименовываем метод и
компилируем программу, а потом по сообщениям об ошибках находим все
точки использования метода test_method. Или если язык достаточно просто
(типа Java или C#), то IDE может проанализировать код и заменить все без
перекомпиляции.

> WH>Что называется почувствойте разницу.
> и что?

А то, что с ReShaper'ом или IDEA "производительность" получается ничуть
не хуже, чем у питонистов.

> WH>Сомнительное преймущество.
> угу также как и шаблоны в плюсах

Темплейты в С++ — это огромное его преимущество, и ничуть не сомнительное.

> Может наоборот? Тем более пока C#2 нет, а переносимые варианты
> появятся еще позже.

Переносимый вариант (Mono) выйдет через пол-года.

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

Не факт.

> FR>>и как плюс они будут короче и понятней, осбенно настроечные
> скрипты с которыми работают дизайнеры, то есть те кто мало разбирается
> в кодировании.
> WH>Сильно сомневаюсь
> зря, только то, что питон подерживает процедурный стиль уже гигантское
> упрощение, код можно писать без всякой обвязки, и читатся он будет не
> сложнее чем ini файл.

Только если при этом он будет делать примерно то же, что и "hello world".

--
С уважением,
Alex Besogonov (alexy@izh.com)

WFrag wrote:

> 1) Любой синтаксис, который нам понравится.
> 2) DSL будет компилироваться (в LISP-код, а затем и в нативный при
> необходимости), а не интерпретироваться. В том числе есть обширные
> возможности для оптимизации или применения Partial Evaluation. И это
> все будет работать при компиляции кода, а не при его выполнении.

3) Lots of Incredibly Stupid Parentheses

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

FR>Конечно напишешь Но суть в том что создатели java и C# выкинув процедурный стиль просто принуждают из простейших вещей делать криптокод.
Может уже пора писать в объектно-ориентированом стиле?

FR>Чем ее отсутствие помешает преименовыванию методов и т. п.
Ну попробуй переименовать функцию some принимающею три параметра типов int, float, string сласса foo. Причем так чтобы ничего не поломалось ни при каких наворотах в коде.

WH>>ReSharper не проверяет код. Он помогает его набивать, модифицировать и осуществлять навигацию. Те это часть IDE, а не компилятора.
WH>>Что называется почувствойте разницу.
FR>и что?
А то что ReSharper не берет на себя функции компилятора по проверки программы на наличие ошибок.

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

FR>Тем более пока C#2 нет,
Уже есть бета 2
FR>а переносимые варианты появятся еще позже.
Микрософт перенесет его везде где есть винда очень быстро. А всякие линухи лично меня не волнуют.
FR>А связыватся стоит, так как портировать питон
Ну для того чтобы портировать .НЕТ надо только прекомпилировать JIT и GC под конкретную платформу. А библиотеки те что чисто managed портируются автоматически.
FR>и настраивать под определенную задачу гораздо легче чем шарп,
Это чем же?
FR>и памяти он кушает намного меньше.
Ой да брось ты. .НЕТ жрет памяти сколько винде не жалко. Но как только винде понадобится память .НЕТ ее отдает еще до того как винда потянит свои ручки к свопу.

FR>зря, только то, что питон подерживает процедурный стиль уже гигантское упрощение,
Ну в программе из 10 строк это можно заметить. А вот в программе на несколько мегабайт исходников ты это и под микроскопом не увидишь.
FR>код можно писать без всякой обвязки, и читатся он будет не сложнее чем ini файл.
Очень обманчивое "преймущество". Взять тотже "Vampire: The Masquerade Bloodlines" блин все руки надо пообравать этим горе программерам которые эти скрипты писали.
Замет все задается строками и магическими числами. И так везде.

def mercurioFight():
    npc = Find("Mercurio")
    pc = __main__.FindPlayer()
    state = pc.GetQuestState("Astrolite")
    if(state == 5):
        npc.SetModel("models/character/npc/unique/Santa_Monica/Mercurio/Mercurio.mdl")
        npc.SetDisposition("Neutral", 1)
        teleporter = Find("healthy_mercurio_spot")
        teleporter.Teleport()
        script = Find("mercurio_turn_around")
        script.StartSchedule()
        trigger = Find("mercurio_angry_talk_trigger")
        trigger.Enable()
        journal = Find("mercurio_journal")
        journal.ScriptUnhide()
        sparklies = Find("journal_sparklies")
        sparklies.ScriptUnhide()
    if(__main__.IsDead("Mercurio")):
        npc.Kill()

Представляю сколько времени они это отлаживали... Ведь одна опечатка в одном строковом литерале и...

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

FR>>Тем более пока C#2 нет,
WH>Уже есть бета 2
FR>>а переносимые варианты появятся еще позже.
WH>Микрософт перенесет его везде где есть винда очень быстро. А всякие линухи лично меня не волнуют.

Жаль, что гуру, говоря о достоинствах .NET-а, часто отмахиваются от наличия других платформ
Лично мне очень жаль, что Microsoft не занимается сама портированием .NET и C# хотя бы на Unix-ы (типа Linux-а и BSD). Моно и ДотГНУ -- это хорошо, то далеко не Microsoft.

WH>Очень обманчивое "преймущество". Взять тотже "Vampire: The Masquerade Bloodlines" блин все руки надо пообравать этим горе программерам которые эти скрипты писали.
WH>Замет все задается строками и магическими числами. И так везде.
WH>

WH>def mercurioFight():
WH>    npc = Find("Mercurio")
WH>    pc = __main__.FindPlayer()
WH>    state = pc.GetQuestState("Astrolite")
WH>    if(state == 5):
WH>        npc.SetModel("models/character/npc/unique/Santa_Monica/Mercurio/Mercurio.mdl")
WH>        npc.SetDisposition("Neutral", 1)
WH>        teleporter = Find("healthy_mercurio_spot")
WH>        teleporter.Teleport()
WH>        script = Find("mercurio_turn_around")
WH>        script.StartSchedule()
WH>        trigger = Find("mercurio_angry_talk_trigger")
WH>        trigger.Enable()
WH>        journal = Find("mercurio_journal")
WH>        journal.ScriptUnhide()
WH>        sparklies = Find("journal_sparklies")
WH>        sparklies.ScriptUnhide()
WH>    if(__main__.IsDead("Mercurio")):
WH>        npc.Kill()
WH>

WH>Представляю сколько времени они это отлаживали... Ведь одна опечатка в одном строковом литерале и...

+1

Кстати да, очень часто в скриптовых программках натыкаешься на такой hard-coding. Это не значит, что на Python-е (Ruby) нельзя писать без hard-coding-а (равно как на C++, Java и C# легко писать с hard-coding-ом). Но часто именно на такой код нарываешься.