Python2.7 vs Python3 vs Tcl

советую использовать python 2.7, так как для 3-й версии мало библиотек портировали. с Tcl не знаком. По поводу библиотек, то тут нужно составить для себя более подробное ТЗ. Или сделать детальную постановку задачи.

Мне хватило Tcl но про Python я ничего не знаю, поэтому не выбирал. Не могу сказать что есть для «работы с TeX/LaTex, .odt, .doc, .docx, .pdf, .xls» но все остальное умеет.

Правда при работе с Redis у меня возникли некоторые проблемы - имеющийся пакет биндинга содержит какую-то мелкую ошибку и не умеет UTF. Пришлось переделать чуть-чуть. Если вдруг понадобится - стукни. Выложить все никак не соберусь...

Perl тоже под описание подходит

Perl не знаю, изучать не вижу смысла до стаблизации Perl6

Кстати, а вы не знаете как сейчас обстоят дела с Perl6? Он ожил или до сих пор в коме?

Самый лучший язык - тот который лучше знаешь.

Я бы взял питон 2.7 - говорят для третьего каких то либ еще нету, и потом я 2.7 лучше знаю;-)

Насчет возможностей Tcl я толком опять таки ниче не знаю, но для части озвученных задач мы питон используем вполне успешно.

Насчет возможностей Tcl я толком опять таки ниче не знаю, но для части озвученных задач мы питон используем вполне успешно.

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

Пилят потихоньку

Смысл есть: стабилизируют не скоро, перелапачивать базу под 6-й буду и того дольше. 5 ветка вполне себе еще 10 лет протянет, имхо.

Рассматриваются именно эти языки т.к. необходим набор виджетов Tk

во-первых: привязки к Tk есть у кучи языков

во-вторых: никто не заставляет писать всё целиком на одном языке, вполне возможно чисто северную часть на одном, а гуёвые привязки на другом

Если в С вкорячить guile, то может выйти и удобнее, чем на перл/питон/тикле.

Если в С вкорячить guile, то может выйти и удобнее, чем на перл/питон/тикле.

Ты предлагаешь всё написать на guile или куски на С? Или учитывая, что ТС нужны параллельные вычисления, ты предполагаешь что на С всё равно писать придёться?

библиотеки для работы с TeX/LaTex, .odt, .doc, .docx, .pdf, .xls, реялицонные базы данных, нереляционыне базы данных (с указанием какие именно)

В принципе для такого зоопарка батареек у питона явно больше. С другой стороны если мы говорим о *nix то можно вспомнить что для многого из этих «хотелок» есть консольные утилиты.

Рассматриваются именно эти языки т.к. необходим набор виджетов Tk,

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

настолько примитивный, что позволяет строить свой велосипед если чего-то нет.

Это конечно зависит от личных представлений чего-там нет, но помоему именно в Tk низкоуровневые вертелки для чего-то такого вырезаны и вынесены в Tk Library. И тот же Qt более строный в этом смысле, хоть и тяжелый конечно.

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

Ему нужно, но он просто об этом не знает;-).

Аб чем разговор вообще? Все что должно работать быстро пишется на С/C++/Паскале/ФОртране/берется в уже написанном кем то виде.

Все что сверху пишется на питоне/Тсl/яве/перле или одном из 100500 скриптовых ЯП (да хоть на баше).

Ты предлагаешь всё написать на guile или куски на С?

Техзадание слишком расплывчато, чтобы можно было обосновано судить. Мне кажется будет правильным ядро программы, обеспечивающее паралелилизм и взаимодействие с внешним миром написать на С, а уже логику его сервера приложений заскриптовать на guile. Всё целиком писать только на guile --- не вариант совсем, но можно почти всё написать на нём, а в критических местах дёргать С. Однако, тут, скорее всего, не тот случай.

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

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

Отлично решаю: посмотри в моем профиле ссылочки на уже решенные задачи.

Тогда вопрос сам собой отпал спасибо!

советую использовать python 2.7, так как для 3-й версии мало библиотек портировали

теперь ещё одна появится?

Рассматриваются именно эти языки т.к. необходим набор виджетов Tk

А вот это-то нахрена? Какого хрена сдался Tk, когда есть веб-интерфейсы? Тем более, в «клиент-серверной» среде... Кроме того, я лично сомневаюсь, что есть хоть какое-то оправдание чтобы не использовать HTTP для сабжа.

Есть опыт построения среднего кроссплатформенного проекта (около 3М кода) на связке python2.X+Tcl. Если интересно, наделаю скриншотов, но интерфейс там довольно навороченный. Тиклевские, а еще больше Tile-вские, виджеты хоть и легкие и искоробочные, но имеют массу неочевидных граблей, недоработок и слабо документированны. Использовать связку питон + тикль имело смысл до выхода pyQT4. Был проект такой sK1, его ребята с ЛОР-а вели и новости о нем постили. У них тоже была подобная связка. И они тоже от нее отказались.

По итогам скажу сразу - бери Java. Если хочешь использовать python - есть вполне живой и стабильный jython. По сравнению с CPython он где-то быстрее, где-то медленее, но за то, ты используешь лучшее из двух миров. Ведь, если python и поставляется с какими-то там батарейками, то java поставляется со встроенной электростанцией.

библиотеки для работы с TeX/LaTex, .odt, .doc, .docx, .pdf, .xls

В случае с python pабудь.

принципе для такого зоопарка батареек у питона явно больше.

И они мертвы.

И тот же Qt более строный в этом смысле, хоть и тяжелый конечно

Смотря где :)

Какого хрена сдался Tk, когда есть веб-интерфейсы?

Ести просят какой-нибудь АРМ со сложной логикой пользовательского интерфейса, то гуй лучше. А если еще и печать (как раз этот случай), то однозначно лучше гуй.

Требования к инструменту: возможность сделать масштабируемый серер приложений, кроссплатформенный, работа с многопоточностью и паралельными вычислениями, библиотеки для работы с TeX/LaTex, .odt, .doc, .docx, .pdf, .xls, реялицонные базы данных, нереляционыне базы данных (с указанием какие именно).

напоминает ТЗ на кнопку «cделать за@#ись» :)

для отдельных приложений с «odt, .doc, .docx, .pdf, .xls, реялицонные базы данных» я бы выбрал tcl + gnocl (http://www.gnocl.org/) и отказался от Tk.

Если тебе нужна математика взгляни на R.

B TableList в добавок

как понял, опыта у автора маловато, вряд ли он сам сможет портировать нужные ему библиотеки на 3-ку. А так как автор пишет «для себя», то чем меньше проблем, тем лучше

на Tcl версий вплоть до 8.4 поддерживаемые приложения писать неудобно - это, всё-таки, в большей мере язык для решения задач

на Tcl 8.6, думаю, вполне можно слабать приемлемую архитектуру, но поддерживать код будет сложней, чем на Python (разве что софтина для эмбедщиков, которые Tcl, как правило, знают)

С многонитевостью для вычислений у Питона довольно плохо.

Блин, а чем принципиально 8.6 в этом отношении лучше? Поддержкой dict? Так они и в 8.5 есть. Да и не так это принципиально...

А кстати тут встречный вопрос ко всем - у кого из скриптовых, подходящих для web языков, самая шустрая математика?

Javascript (который google v8).

у кого из скриптовых, подходящих для web языков,

Что значит «подходящий под веб» - клиент или сервер?

самая шустрая математика?

Зависит от математики. Вряд ли кто-то обгонит матричные операции NumPy или numexpr.

Сервер разумеется.

Не верится что математика js быстра... Хотя надо смотреть. Но в любом случае js на стороне сервера для меня немного необычно.

чем принципиально 8.6 в этом отношении лучше?

модульностью

«Пользуясь случаем» хочу спросить: есть ли способ установить utf-8 кодировкой по умолчанию у Tcl на оффтопике (вместо cp1251). Можно encoding system utf-8 вначале скрипта делать, но вроде где-то натыкался, этот способ не рекомендуется, потому, что может криво работать ввод/вывод. Есть вариант запускать tclsh c ключом -encoding, но у wish нет такого ключа. (cast Suntechnic jtootf)

питон 2.7 ибо более распространен.

ДА и еще: меня бесит отсутствие обратной совместимости

Черт его знает что там в этом оффтопике... Кстати, а зачем? Чем cp1251 не устраивает?

Можно encoding system utf-8 вначале скрипта делать, но вроде где-то натыкался, этот способ не рекомендуется, потому, что может криво работать ввод/вывод.

Так попробуйте?! Я вот сомневаюсь что с вводом/выводом будут проблемы. А вот с чем-нибудь вроде string toupper проблем можно огрести.

Черт его знает что там в этом оффтопике... Кстати, а зачем? Чем cp1251 не устраивает?

Дома utf-8 по умолчанию, на работе cp1251.

string toupper

отличный способ проверить корректность кодировок :)

отличный способ проверить корректность кодировок :)

proc {string totitle} {str} {
  return [encoding convertto utf-8 [string totitle [encoding convertfrom utf-8 $str]]]
}

;)

Требования к инструменту: возможность сделать масштабируемый серер приложений, кроссплатформенный, работа с многопоточностью и паралельными вычислениями, библиотеки для работы с TeX/LaTex, .odt, .doc, .docx, .pdf, .xls, реялицонные базы данных, нереляционыне базы данных

Python 2

LuaJIT, v8

Пиши на ruby

Если Tk, то работать проще всего с ним из Tcl, конечно. Про то, какие там библиотеки — сам смотри.

отличная тема!

то есть — «тема-детектор» старпёров пишущих на недоразвитом Python-2.

поставлю всем вам пометки соответствующие в профиль :-) :-D

Ведь, если python и поставляется с какими-то там батарейками, то java поставляется со встроенной электростанцией.

Причем тащишь ее на себе. Чтобы питать фонарик.