Естественно, ни то, ни другое. На фига из говномёта по дрозофилам шмалять? Tcl тут выше крыши хватит, или Guile/Gtk, или Python...

>Tcl
вы предлагаете на нем писать пользовательский интерфейс?
его look and feel ужасен.

>Python

а ему gtk+ для интерфейса не понадобиться?
а сама среда?

тогда уж лучше на Java.

но мой совет: lisp - алгоритмы поиска в словарях,
C++ интерфейс и остальная функциональность.

> а ему gtk+ дл интерфейса не понадобиться? а сама среда?

чем gtk-интерфейс не устраивает?
на pygtk гуй пишется легко и непринужденно

>а ему gtk+ для интерфейса не понадобиться?

Нет, если ты будешь писать на Qt. :)

Tk - не так уж и кошмарен, если его правильно сготовить.

GTK+ - уж всяко лучше, чем Swing, да и любой из перечисленных языков - на порядки лучше, чем кошмарная Жаба.

И уж тем более нелепо писать на C++ морду. Не для того он нужен...

>И уж тем более нелепо писать на C++ морду. Не для того он нужен...

а для чего если не секрет, это язык общего назначения

>чем gtk-интерфейс не устраивает?

ну если потребуется gtk, то нафига python,
если можно написать на C++

ИМХО, лучше на АСМе

>ну если потребуется gtk, то нафига python, если можно написать на C++

гыгы. спасибо, насмешил =)

ны самом деле для морды питона + гтк - выше крыши. И пишется в разы быстрее, чем Ц++ =)

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

>ны самом деле для морды питона + гтк - выше крыши. И пишется в разы быстрее, >чем Ц++ =)

а ты я прям вижу гений програмирования,
примеры в студию
pygtk vs gtkmm

что там в разы быстрее будет?

>хотя и питон и биндинги к нему в большинстве дистрибутивов есть

а FreeBSD вы в расчет не берете?
Solaris?
Windows?

Дык как язык Питон на порядки лучше, чем убогонький и кривенький C++...

не понял, а чем не нравится stadict? морда gtk2, лицензия gpl

опять заново переписывают то, что уже есть?

>что там в разы быстрее будет?

разработка быстрее будет. бо не надо ждать, пока этот грёбаный C++ соизволит скомпиляться

предлагаю вариант, может не такой уж и простой:

* делаешь dbus сервера, который будет хавать слова для перевода и выплёвывать, собственно, сам перевод
* делаешь к нему морду _на чём хочешь_, и желательно несколько штук - под GTK, QT, или FLTK :)

P.S. это если кроссплатформенность не интересует :)

>разработка быстрее будет. бо не надо ждать, пока этот грёбаный C++ соизволит скомпиляться

медленная скорость компиляции с лихвой окупается количеством и качеством компонентов, которые реализованы в QT. Их НЕ НУЖНО писать самому, в противовес некоторым компонентам в GTK :)

P.S. компоненты - я имел ввиду элементы интерфейса.

Вы тут все ничего не понимаете.

Фокал самый лучший для всего.

ШВИМ

>медленная скорость компиляции с лихвой окупается количеством и качеством компонентов, которые реализованы в QT. Их НЕ НУЖНО писать самому, в противовес некоторым компонентам в GTK :)

а что мешает писать на pyqt? :)

брат бэкашник :) хотя если по уму то фокал это сплав бейсика с фортраном причем от каждого языка он взял самое худшее :)

Господа, ИМХО конечно, но пишите на C++ нынешний мир породил, столько мастодонтов на чем-то-там-тк, что простейшие операции поиска съедают столько времени и ресурсов, что отцы компьютеров, просто застрелились бы, если бы узнали как последующее поколение, использует результаты их труда. Вроде бы удобнеее на скриптовом языке, да не это цель. Цель автоматизации - удобство для пользователя, грамотное использование его ресурсов, а программисту может быть удобен, стул, стол, клавиатура, средства труда, но не как сам труд. Согласись если бы тебе вместо клавиатуры принесли кусок пластика, мол нашим рабочим неудобно было отливать формы - горячий пластик плохо пахнет, поэтому будь добр купить напильник и выпилить ее сам. Это работа! А портируемость... линь, бсд и солярка очень похожи, и если вы правильно подойдете к разработке, портирование будет несложным. Удачи! Про преумножение сущностей не слушайте! Это глупость, поскольку джинсы на каждом втором из нас, по этим понятиям тоже преумножение сущности, шкуры мамонта.

> брат бэкашник :) хотя если по уму то фокал это сплав бейсика с фортраном причем от каждого языка он взял самое худшее :)

БК рулит. Это был мой самый первый компьютер. Я тогда еше был еще в младшей школе.

>Господа, ИМХО конечно, но пишите на C++

ты хотел сказать _не_ пишите? =)

>мастодонтов на чем-то-там-тк, что простейшие операции поиска съедают столько времени и ресурсов

а поиск к морде какое отношение имеет? =)

grep достаточно.

> ы хотел сказать _не_ пишите? =)

Были предложены 2 варианта Java и C++

> а поиск к морде какое отношение имеет? =)

Как вариант осуществлять промежуточное временоое кэширование запросов пользователя, для сокращения объема расходуемого трафика к dict-серверу.

А вообще это сказано относительно неоправданно расходуемых ресурсов. А то трепатся на тему идеальных алгоритмов тут все мастера, а алгоритм это только верхушка большого айсберга под названием ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ. И грош цена тут навороченым алгоритмам имени Шницель-Штрудель-Розы-Люксембург, если их реализация по сути дела происходит лишь в мозгу разработчика, а реально это разбадяжено такой кучей интерпритаторов,прослоек,прокладок и костылей... что в результате мы получаем очередного мамонта, который передвигается с трудом, и имеет тенденции спотыкатся.

Писать надо на рефале

А алгоритмы вообще сосут. Как сказал "алгоритм" сразу понятно - ламер, шагом марш в биореактор Луговского

Вот ведь баран... Ну кто тебе сказал, что у C++ есть хоть какие-то преимущества в производительности перед скриптовыми языками в такой задаче - если и то, и другое, просто будет за Berkeley DB или там SQLlite дёргать.

>разработка быстрее будет. бо не надо ждать, пока этот грёбаный C++ соизволит >скомпиляться

тебя обидел C++ программист?

а ты знаешь что существуют объектные файлы и утилита make?

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

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

1: Аглритмы сосут ? 2: Если ты думаешь, что алгоритмы не сосут, то 3 , иначе 100 3: Ударься головой о стол 4: переход на 1 100: чтд

Биореактор Луговского ukez адназначно

>тебя обидел C++ программист?

нет 8) мне в принципе непонятно, зачем нужны эти костыли (C++)

>а ты знаешь что существуют объектные файлы и утилита make?

представь себе - знаю

>может кому-нибудь и важна скорость компиляции чтобы проверять каждую строчку,

извращенцы

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

ты пишешь по целому модулю без ошибок? или ты инопланетянин, или у тебя микроскопические модули =)

>ты пишешь по целому модулю без ошибок? или ты инопланетянин, или у тебя >микроскопические модули =)

почему без ошибок?
две три опечатки.

> мне в принципе непонятно, зачем нужны эти костыли (C++)

ну приведи пример,
если написать на C++ будет занимать множество строчек, а на питоне
всего пару?

>если написать на C++ будет занимать множество строчек, а на питоне

это ты так измеряешь эффективность языка? LOL. я валяюсь

ps: отправляйся в биореактор, пока не поздно

>ну приведи пример, если написать на C++ будет занимать множество строчек, а на питоне всего пару

Где-то в devel был вопрос про посчитать сумму чисел второй колонки текстового файла.

from sys import stdin

print sum((long(line.split(None,2)[1] for line in sys.stdin)))

Ровно пара. Давай эквивалент на C++ :-)

> Вот ведь баран... Ну кто тебе сказал, что у C++ есть хоть какие-то преимущества в производительности перед скриптовыми языками

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

> Ровно пара. Давай эквивалент на C++ :-)

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

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

Алгоритмы сосут ....

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

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

> Абзац... И какой же отладчик сравнится с REPL?!?

Мда.... виталя определенно йопнтуый...

gdb

>а потом посчитаем, сколько тактов питонщики выкинули в пустоту...

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

PS: колько тактов питонщики выкинули в пустоту

Кстати, у меня вчера компютер почти не работал. Приезжай, отдам скопившиеся такты (аж 5.4e13 штук) за пару литров пива.

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

Ох софисты... я говорю о выполнении задачи на машине а не в уме.

>Ох софисты... я говорю о выполнении задачи на машине а не в уме.

хы. почетай ещё раз, и может ты поймешь, что о выполнении задачи в уме никто и не говорил =)

>я говорю о выполнении задачи на машине а не в уме.

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

Так кто больше ресурсов на ветер выбрасывает?

Ты должен сдохнуть.

Ещё раз - какая на фиг отладка, когда в языке есть repl? gdb сраный засунь себе в жопу, ламерьё безграмотное.