Помогите выбрать язык.

> Еще годик-другой назад у вас было, хм, как бы это сказать,

значительно больше пылкого юношеского запала в адрес некоторого,

хм, пресловутого языка.

Спокойно, на JavaScript я начал писать раньше, чем на Common Lisp и мне он всегда нравился. На Python я, кстати, тоже раньше начала писать и он мне тоже всегда нравился. Мне вообще все языки, на которых я писал, нравились и продолжают нравиться. Просто я не воспринимаю CL как язык для скриптов, а использую его для сервера приложений.

Конкретно же на JavaScript я пишу примерно столько же, сколько и на Common Lisp.

> Поэтому предполагается, что писать их будут нормальные люди,

а не скобкоманьяки.

Между тем, «скобкоманьяки» сделали cl-javascript (http://marijnhaverbeke.nl/cl-javascript/), реализацию JavaScript на CL, для скриптования программ на CL с помощью JavaScript ;)

Увы, под виндой использовать это хозяйство не доводилось.

AFAIK, у GObject Introspection нет официального билда под win, и не будет до релиза gtk3, поэтому как бы не было вкусно хозяйство, необходимость самосбора портит всю малину.

но встраивание выглядит немного вырвиглазно

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

#include <Python.h>

int
main(int argc, char *argv[])
{
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
                     "print 'Today is',ctime(time())\n");
  Py_Finalize();
  return 0;
}

(c) документация

> AFAIK, у GObject Introspection нет официального билда под win, и не будет до релиза gtk3

С другой стороны, выход GTK+3 вроде как не за горами. До тех пор можно и проскрипеть на самосборе или contributed build'ах - овчинка стоит выделки.

http://ru.wikipedia.org/wiki/JavaScript

спасибо, это как раз оттуда и взято было.

elipse> http://ru.wikipedia.org/wiki/JavaScript
Да точно не дочитал

annoynimous в информации о вас не указаны возможные средства для связи, поэтому решил обратиться через форум:

я только начал пользоваться форумом и уже получил бан на 6 псевдонимов(domovoy,dgovorun,dkuzma,kuzma,gnezdovoy,jt,jtj) Объясните мне пожалуйста, почему вы это делаете? я конечно самокритично к себе отношусь, но я не пойму, разве развитый модератор форума, участник общественного процесса, для которого существует важная информация и неважная, может ставить диагнозы по «телефону»? http://www.linux.org.ru/forum/general/5531935?lastmod=1289153554799

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

Смысл предпочесть тикль хотя бы из-за того, что GUI идет «изкаробки», потому что синтаксис Tcl проще лиспового (ИМХО). Так же «+» тикля то, что он не перегружен библиотеками как CL. Про скорость - а «лисп» разве быстрее tcl? Да и все равно скриптовые языки были и будут медленнее «асмы». И кстати - чем «тикль» менее продвинутый? Макры в тикле есть, следовательно запрограммировать можно что угодно. Функциональный стиль поддерживает, лямбды реализуются просто, ооп реализовано прекрасно. И кстати, а зачем учить грузный коммон лисп, если есть более легкий tcl? И еще - отчего отвращение к Tcl? Синтаксис из-за скобок?

> Про скорость - а «лисп» разве быстрее tcl?

ну, это смотря что за «лисп»:) gcl медленнее, а sbcl сиильно быстрее хоть и памяти жрет дофига. другой вопрос, если в tcl нужно что-нибудь ускорить, то дописываешь нужный кусок на C (даже в рантайме можно с помощью tclcc) и всякие там %MY_FAVORITE_LANGUAGE% начинают сосать шумно причмокивая. ну да это и в других скриптовых ЯП можно

ооп реализовано прекрасно

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

Смысл предпочесть тикль хотя бы из-за того, что GUI идет «изкаробки»

а вот здесь +100, мне не очень внешне нравится синтаксис тикля, скажем, руби посимпатичнее, но «кушаю кактус» :) уже лет 6 ибо нужен гуй, а сколько не искал, ничего сравнимого по удобству на практике с Tk/Ttk в других ЯП не видел. tkinter и проч. х... не предлагать.

Ну смотря какая именно реализация ООП. ПО карйней мере лучше чем в том же пистоне.

Про синтаксис - по моему он даже логичнее и удобнее лиспового и уж точно лучше «отступов» пистона

Ну смотря какая именно реализация ООП. ПО карйней мере лучше чем в том же пистоне.

Кстати, всегда интересовали возможности ООП в тикле. Что там можно сделать, чего нельзя в питоне?

> Про синтаксис - по моему он даже логичнее и удобнее лиспового и уж точно лучше «отступов» пистона

Дык я про Ruby говорю, там сахарку больше. Пистон УГ без вопросов - о нем и речи нет.

В общем, Вы меня уже почти уговорили взглянуть на tcl поподробнее. Будет совсем хорошо, когда вот здесь появится ещё строчка с tcl. http://shootout.alioth.debian.org/ Или как ещё Вы посоветуете оценить быстродействие?

Он до сих пор на одном ядре работает и запрещает завершение по Ctrl+C? (встраиваемый интерпретатор)

Он до сих пор на одном ядре работает

Это сделано для того чтобы не затормозить выполнение процеса на одном ядре. Или ты думаешь что это можно сделать без оверхеда? По этой причине патч который добавлял такой функционал был отклонён. Ограничение распространяется только на интерпретатор, сама прога может быть сколь угодно тредовой. Решений этого вопроса тьма, хотя бы модуль multiprocessing который иммитирует API нитей и перебрасывает данные между процессами с помощью picle. А есть ещё pympi который позволяет легко кластер развернуть и не думать о проблемах синхронизации и передачи данных. А ещё есть... А много чего есть.

и запрещает завершение по Ctrl+C? (встраиваемый интерпретатор)

Это ты сам придумал. Я тебе даже пример встраивания привёл, можешь проверить, например, с PyRun_SimpleString(«while True: pass\n») что ничего не блокируется. Не, ну я верю что если захотеть то можно всё что угодно повесить....

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

http://en.wikipedia.org/wiki/Global_Interpreter_Lock

чего нового я оттуда должен узнать?

Это сложный вопрос. Tcl не для забегов на скачках и не будет на тех тестах вставлять всех.
Исходно для тестирования берут не те задачи и не
так их решают. Ну и соответственно, получают не те выводы.))
80% задач на http://shootout.alioth.debian.org/ это камерные глупости
и мало встречающиеся на практике.
Короче:
Не следует применять tcl не по назначению и не понимая его ))

например:
http://www.yeraze.com/2006/12/tcl-vs-python/
исходный шмат быдлокода 1:
if {![info exists users($user)]} {
set users($user) 0
}
incr users($user)

очевидно же следовало заменить на:

if {![info exists users($user)]} {set users($user) 1
    } else { incr users($user)}

что будет быстрее работать, так как нет двойной работы с переменной users($user) по выполнению условия в if.

исходный шмат быдлокода 2:

if {[string range [lindex $entry 1] 0 1] == “P:”} {
set p [string range [lindex $entry 1] 2 end]
}

нетрудно видеть, что индекс элемента вычисляется два раза
и это отрицательно скажется на быстродействии и читаемости кода
И заменяем это на:

set sptr [lindex $entry 1]
if {[string range $sptr 0 1] == “P:”} {
set p [string range $sptr 2 end]
}

это можно записать иначе , если гонятся за числом строк в программе:

set sptr [lindex $entry 1]; if {[string range $sptr 0 1] == “P:”} {set p [string range $sptr 2 end]}

а на третий шмат быдлокода там есть ответ каментах тоже.

Выводы ?
Наверное средней руки программист имеет больше шансов настрочить поганых программ на tcl и сделать какие-то для себя отрицательные выводы.
Это вина tcl ? - Сомневаюсь.
Меня не беспокоят проблемы конвеера писак программ.
Всегда есть шанс, что кто-то свободой и гибкостью будет пользоваться не по назначению или просто ее не заметит вовсе.

Ну Вы привели только один заведомо пример, как пример плохого примера.

Но на шутауте всё достаточно объективно. Вы сами можете решить задачи и выложить своё решение. Однако, на вопрос о производительности Вы не ответили. Если она примерно такая же, как в питоне, то я начинаю сомневаться в нужности tcl. CL как раз тем хорош, что он масштабируется по быстродействию. Т.е., если сравнивать изящный синтаксис+гуй из коробки против нативный код+возможность статической типизации, то я однозначно выберу CL.

(я имею в виду нужность tcl не вообще, а для меня, учитывая мой уровень владения CL на сегодня и мои задачи; для новичка и для других задач расклады могут быть другими).

>Ну Вы привели только один заведомо пример, как пример плохого примера.

Я привел мнение такого же как вы и да,«заведомо»

Но на шутауте всё достаточно объективно. Вы сами можете решить задачи и выложить своё решение. Однако, на вопрос о производительности Вы не ответили.

меня не интересует питон , сl и замеры их производительности.
тесты по tcl там были и куда-то исчезли, а куда ? - это тоже меня не интересует.

Если она примерно такая же, как в питоне, то я начинаю сомневаться в нужности tcl.

А собственно, почему это меня должно беспокоить ?

CL как раз тем хорош, что он масштабируется по быстродействию.

И не по голове, язык занят постоянно собственными проблемами и концепциями.

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

Какие проблемы ? Это ваше право.

> язык занят постоянно собственными проблемами и концепциями.

У вас неверная информация.

Это не информация , а мои наблюдения ))
Вас все как-то больше беспокоит как правильно «клопа трахнуть», а не отсутствие за столько лет набора готовых решений и программ.

> Я привел мнение такого же как вы и да,«заведомо»
Чёто вы сразу в стойку встали, а я всего лишь опечатался :-) Я имел в виду, что там в комментах разобрано: код tcl написал плохо, код python - хорошо, т.е. по этому примеру нельзя ничего сравнить. Это и есть «заведомо».

тесты по tcl там были и куда-то исчезли, а куда ?

Ну может Вы помните, что там было, сопоставим ли он с Python, хотя бы в диапазоне +- 50%. Понимаете, сейчас ситуация такая, что мне в определённых случаях не хватает быстродействия лиспа. Пока это не очень бесит и я знаю, что делать, если начнёт бесить. А если бы это был tcl, то бесить бы начало раньше и бороться было бы труднее.

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

Да, это так, но для меня это уже (почти) пройденный этап. Меня в лиспе раздражали несколько вещей, в основном я с ними справился. Кроме того, я уже давно использую лисп в работе, а не только подкручиваю его.

> Это не информация , а мои наблюдения ))

Видимо, не там наблюдаете.

Вас все как-то больше беспокоит как правильно «клопа трахнуть»

На ЛОРе есть несколько лиспотроллей, не обращайте на них внимания.

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

Они есть.

По моей памяти, tcl по тестам там уступал в 50% тестов перлу, раза в два так, ...

Но все от задач зависит и условий. Я вполне могу создать условия только в пользу tcl - и все сольют.))
Вы решили что я продвигают tcl как универсальную затычку ?)) Не а, это не так.

> Я вполне могу создать условия только в пользу tcl - и все сольют.))

давай

лень, а этого хватит за глаза:
http://www.linux.org.ru/jump-message.jsp?msgid=4928606&cid=4930038

По моей памяти, tcl по тестам там уступал в 50% тестов перлу, раза в два так

Спасибо, понял.

Но все от задач зависит и условий. Я вполне могу создать условия только в пользу tcl - и все сольют.))

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

Вы решили что я продвигают tcl как универсальную затычку ?

Да я ничего не решил, просто вижу, что Вы знаете tcl и давно пользуете, вот и решил поспрашивать.

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

Вы меня заставляете говорить банальности.
Эти тесты ничего не отражают.
За каждым языком стоит своя парадигма, и не все сводится к тупому быстродействию.
Например: Как эти тесты позволяют оценить тот факт, что можно пополнять набор команд tcl и не пересобирая основной интерпретатор ?

по стандарту:
for {set x 0} {$x < 100000 } {incr x } {
# repeat this 100000 times
   set ass «ssssssssssssssss»
   set ass «1111111111111111»
}
получим
time tclsh test_old.tcl

real   0m0.099s
user   0m0.080s
sys   0m0.008s
а если использовать расширение tclmore, то получим:

package require more
more loop 100000 {
# repeat this 10000 times
   set ass «ssssssssssssssss»
   set ass «1111111111111111»
}

time tclsh test_more1.tcl

real   0m0.066s
user   0m0.048s
sys   0m0.016s

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

Эти тесты ничего не отражают.
За каждым языком стоит своя парадигма, и не все сводится к тупому
быстродействию.

То же самое верно для любого языка. Я не знаю, как бы не перейти к сравнению tcl vs CL, как не оставить Вас с ощущением, что я Вас хочу ущемить, и при этом закончить этот разговор. Вывод, который сделал я для себя: в определённых условиях я мог бы применять tcl (например, как чисто скриптовый язык). Например, если мне понадобится python, я сначала посмотрю на tcl. Но те задачи, которые я делаю на лиспе, наилучшим образом могут быть решены именно на лиспе. Поскольку интенсивность вычислений уже достаточно велика, чтобы производительность имела значение, и, собственно говоря, код на лиспе уже существует, а на tcl его бы пришлось писать заново. Кстати, я и сейчас использую tktable (раньше мы это уже обсуждали). Хотя, дельфёвые компоненты работы с данными гораздо быстрее работают и дают больше возможностей, может быть, перейду на них со временем. Сейчас это неактуальноо.

> Я не знаю, как бы не перейти к сравнению tcl vs CL, как не оставить Вас с ощущением, что я Вас хочу ущемить, и при этом закончить этот разговор.

Да ладно )) Вы свои задачи лучше же знаете и вам их решать.

Вывод, который сделал я для себя: в определённых условиях я мог бы применять tcl (например, как чисто скриптовый язык). Например, если мне понадобится python, я сначала посмотрю на tcl.

Ну, это уже некоторый позитив.
кстати, и почти в тему:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/5e37b5b551d...
немного смешно и грустно ...