Выбор языка для новичка

> интерфейсы управления некоторыми мелкими телескопами написаны на Tcl/Tk

- мелкими? это Хаббл-то? :D

python /thread

С, Python, Go

Некоторые особо упоротые на нем даже сайты пишут.

а это таки заразно ))

Раз пишешь — значит пробовал? И как — есть смысл? Что посоветуешь почитать? А то назревает задача одна — смотрелка графиков (изменяющихся со временем, с возможностью масштабирования) для локальной сети. Пока сделал в виде смеси быдлокодов на php и js — но выходит неважно, тормозит на больших объемах данных, причем тормозит именно на отрисовке графика. Standalone клиент (на Tcl/Tk, естественно :-) ) при этом рисует большие массивы без проблем. Можно ли использовать для этих целей ту же blt?

о трассировке переменной — не ты ли мне тогда дал исчерпывающий ответ?

да

Еще раз огромное тебе спасибо — все прекрасно работает :-)

Ссылочку можно?

если железяка дешевая и скорость некритична - скриптовый язык вполне подойдет

Так а топикстартер вроде не говорил, что собирается в реальном времени управлять атомными реакторами :-) Конечно, для высоких скоростей и реалтайма лучше Си, имхо, ничего нет.

Ну, с моей точки зрения все равно С проще, чем тот же Tcl.

// интересно, что еще никто фортран не посоветовал :)

ну тут есть несколько вариантов реализации:
1. использовать tcl pluging в браузере и запускать прикладную программу (Standalone клиент на Tcl/Tk) с сервера по браузере клиента.

2. динамически формировать встроенную картинку svg в xhtml на tcl, это будет красиво и модняво, хотя тут нужны уже другие знания и навыки.

А у меня «смотрелка графиков» использует gnuplot. На сервере формируется svg, который уже отдается клиенту. Довольно быстро получается.

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

Ну, с моей точки зрения все равно С проще, чем тот же Tcl.

Мне как раз наоборот показалось. Но это мое мнение, я его не навязываю. Просто имея на руках чистый С, приложение с графическим интерфейсом не сделаешь, все равно что-то придется искать. А TCL и Ел — это как партия и Ленин :-)

интересно, что еще никто фортран не посоветовал :)

Слишком нишевый язык. Кроме математики, что-либо еще на нем делать трудно. Я как-то пытался освоить «Visual Fortran» для офтопика. Это ужос, летящий на крыльях ночи.

Tcl это язык высокого уровня, а С сравнительно простоват и даже слишком.)

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

Сделаешь - с использованием glut.

Слишком нишевый язык. Кроме математики, что-либо еще на нем делать трудно.

Я и математику на нем не осилил, С использую.

ну тут есть несколько вариантов реализации: 1. использовать tcl pluging в браузере и запускать прикладную программу (Standalone клиент на Tcl/Tk) с сервера по браузере клиента.

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

2. динамически формировать встроенную картинку svg в xhtml на tcl, это будет красиво и модняво, хотя тут нужны уже другие знания и навыки.

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

А у меня «смотрелка графиков» использует gnuplot. На сервере формируется svg, который уже отдается клиенту. Довольно быстро получается.

Заказчик хочет масштабирование. Там особенность графиков такая — может очень долго идти почти прямая, а в некоторых местах быть выбросы, и вот эти выбросы они хотят смотреть подробнее. А так я бы тоже сделал на gnuplot — как-то игрался с подобными вещами.

Заказчик хочет масштабирование. Там особенность графиков такая — может очень долго идти почти прямая, а в некоторых местах быть выбросы, и вот эти выбросы они хотят смотреть подробнее. А так я бы тоже сделал на gnuplot — как-то игрался с подобными вещами.

gnuplot генерирует SVG, а вы с этим SVG можете делать что угодно - небольшой код на javascript, и будет вам масштабирование!

Я и математику на нем не осилил, С использую.

Меня Numerical Recipes in C спугнула количеством указателей, так что пришлось ковырять фортран. :-) Ну а потом я увидел матлаб и все заверте...

gnuplot генерирует SVG, а вы с этим SVG можете делать что угодно - небольшой код на javascript, и будет вам масштабирование!

Хм, а ведь это идея. Большое спасибо, приму на вооружение!

> А у меня «смотрелка графиков» использует gnuplot.

На сервере формируется svg, который уже отдается клиенту.

А смысл ?
В tcl инструмент для генерации xhtml и svg может быть общий.

Нет, вариантов решения может быть много. Не в лесу же живем. ))

Какой смысл велосипедить свой алгоритм построения графиков, если уже есть гнуплот?

> Ну и масштабирования тоже, скорее всего, в этом варианте не выйдет.

)) масштабирование заложено в самом svg и его функций преобразования.

Учи Scala, ее уже в native компилировать начали http://greedy.github.com/scala/

Ну тут дело такое .
Бывает так, что обуздание неких «готовых» возможностей отнимает ресурсов ровно на самостоятельную реализацию этого «готового». Увы.))

Ну и масштабирования тоже, скорее всего, в этом варианте не выйдет.

)) масштабирование заложено в самом svg и его функций преобразования.

Это очень обнадеживает, спасибо. Буду смотреть в сторону svg.

Pascal, а затем Scheme, разумеется. После - сможешь выбирать любой язык.

Собственно, svg это просто xml-файл и содержащий внутри команды исполняемые браузером . Все просто. ))

согласен с гиклесом. Мне недостаточно секса и я пишу на C++ и иногда на С и капельку на разных видах Assembler =))

Когда совсем секса не хватает, то ещё пишу на разных вариациях Ecmascript, Perl, {fuuu} C#, {omg!!!} PHP, {omfg!!!} Object Pascal и Brainfuck =))

Вот поглядываю на D, Go, Python, Haskell и Lisp =)))

А вообще: советую выбрать путь дзен-программирования и пусть программы пишутся сами =)

> хочу серьезно этим занятся

хочу чтото универсальное, может с++ попробовать?

Универсальное - это C. Начинай в любом случае с него. Потом, что захочешь. Если всё же не «серьёзно», а именно «понять», то паскаль.

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

А на чём же его пишут?

какой вы темпераментный мусчина... давай встречаццо!

> Эта смесь «скриптов на баше и javascripta» уже десятки лет управляет телескопами — какая разница, как она выглядит?

А COBOL десятки лет управляет финансовыми и транспортными потоками. Что не отменяет того, что COBOL - лютое, бешеное, яростное УГ, а его абсурдная распространенность, даже в XXI веке - следствие недальновидности тогдашних IT-теоретиков и идиотизма менеджеров.

подозреваю что хацкель и эрланг, еще возможно жаба

> Кодогенерация [на лиспе] — вещь. Изучи её. (c) За нею будущее. Не сможешь — так и будешь лапками _все_ свои программы набирать. В отличие от. :)

А за лисперов умные компутиры набирают. Уже 50 лет, ага. :)

Вот вы можете ответить? Я тут мнения собираю, для коллекции. Если лисперы такие мегапродуктивные, программы лапками не набирают - то почему на них до сих пор (за 50 лет) не обратили внимание крупные коммерческие заказчики и производители ПО? Ведь нанять несколько мегапродуктивных лисперов по-любому будет на порядок дешевле, чем штат быдло-monkey-кодеров. Спасибо.

> Если лисперы такие мегапродуктивные ... то почему на них до сих пор (за 50 лет) не обратили внимание крупные коммерческие заказчики и производители ПО?

Я кажется догадался: это следствие недальновидности теперешних IT-теоретиков и идиотизма менеджеров?

> Scheme
> лисп
> coq, agda
> Tcl

Раз уж тред скатился в клоунаду, до кучи порекомендую Haskell, Smalltalk, APL, J и K.

Если серьезно - не стоит заниматься программированием вообще. Профессия уже лет пять как утратила престиж, и ситуация вернулась к 60-ым годам, когда программист был чем-то вроде обслуживающего персонала для продырявливания перфокарт. На данный момент интересная карьера в программировании невозможна, почитайте замечательную статью "Why a career in computer programming sucks?". Если хочется гимнастики для мозгов и общего развития, займитесь лучше математикой, физикой, биологией, химией. Но если прямо вот хочется именно программирования в качестве гимнастики - таки да, тут можно брать и лисп, и хаскель. Для решения олимпиадных задачек - самое оно.

А как же лисп?

> Я кажется догадался: это следствие недальновидности теперешних IT-теоретиков и идиотизма менеджеров?

Окей, запишем: «Потому что все - идиоты». Довольно распространенное мнение.

А теперь подумайте: каким надо быть идиотом, чтобы пройти мимо золотых гор, которые, согласно легенде, должно сулить использование лиспа? Такие бывают, как думаете?

какой типичный тред

> почему на них до сих пор (за 50 лет) не обратили внимание крупные

коммерческие заказчики и производители ПО?

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

Ведь нанять несколько мегапродуктивных лисперов

Дело в том, что их очень мало. Зато много разных троллей. Лисп в руках недостаточно компетентного специалиста, не способного обуздать свои «фантазии» - страшная сила, в прямом смысле страшная ) Выделить толковых лисперов - ещё та задача для отдела кадров, поэтому большой компании ставить ставку на лисп - совершенно безрассудно.

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

Не в десятки раз, конечно. И нельзя говорить, что CL делает всех людей более производительными. Может быть другая команда с Python или даже с C++ будет более производительной. Языки разные и это отражает разницу между людьми. Если кто-то наиболее эффективен когда пишет на Ruby, то другой может свернуть горы с CL, но будет не так хорош с Ruby.

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

Учи сначала родной, потом иностранные (начиная с английского)

Затем - ЯП

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

Вновь могу ответить почти вашими же словами: золотые горы «согласно легенде» сначало сулило использование COBOL, затем Java, сейчас шарп.

Окей, запишем: «Потому что все - идиоты». Довольно распространенное мнение.

Вовсе нет, все как обычно гораздо сложнее, но это и так уже полный офтопик. END

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

Несколько толковых товарищей могут преодолеть все эти проблемы на любом ЯП который им близок - дело ж не в CL а в толковости этих товарищей;-) Но реально толковых товарищей вообще крайне мало, а лисперов так небось по пальцам пересчитать можно - ЯП то нераспространенный...

У нас первый поток учил С/С++, второй поток учил паскаль. Кого чему научили, тот на том потом как правило и пишет, для изучения нового ЯП нужна либо аццкая любознательность либо какие то какие то сильные стимулы (новое место работы с обязат знанием С# и зп в 10k$/мес напр;-)). А учат обычно тому, что преподы знают. Фортран вон УГ в общем то, но поскольку в опред среде он является стандартом то так и предается из поколения в поколение до сих пор...

ТС-у - связка C++/Python довольна универсальна и я бы сказал естественна. А вообще ЯП конечно надо подбирать под круг задач. Начните с Питона (как калькулятор его юзайте), а там уж как пойдет... Паскаль не стоит смотреть - он только для обучения хорош, при практ применении его возможности куда скромнее чем у С++.

Лисп, конечно — уже боевой CL, а не урезанную scheme

Для обучения схема подходит лучше, а потом можно уже и не CL перейти.

Не так и редко оно оправдано. Дело даже не в поддержке ООП, она, как уже сказали, и в С организуется, если надо. А всякие километровые иерархии и множественные наследования - это имхо зло, в коде потом хрен разберешься.

Лиспы позволяют гораздо меньше думать о всякой рутине типо освобождения ресурсов в случае ошибки (GC). И это очень сильно сокращает спектр ошибок, которых можно наделать. И код более емким становится, больше смысла, меньше вознию. Ну и благодаря defmacro там куда более богатые возможности в компайл тайме. Чего стоят хотя бы loop, iter. А если уж про haskell (грядущий мейнстрим) говорить...

P.S. не мог не исправить.

Я бы посоветовал assembler в синтаксисе AT&T + С и заняться написанием драйверов, т.к. это будет полезней некуда для нашего сообщества чем очередной калькулятор или порт оператора биореактора под айфон

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

> иерархии и множественные наследования - это имхо зло, в коде потом хрен разберешься.

Так и запишем: ниасилил.

defmacro ... Чего стоят хотя бы loop, iter.

Так и запишем: для реализации самых примитивных конструкций нужны костыли (макро). Жабщики и плюсовики смотрят на тебя, как на говно.

haskell (грядущий мейнстрим)

Юноша бледный со взором горящим. Тут вон ещё один такой же считает, что будущее — за кодогенерацией на CL. Что же вы не можете с соседями по секте договориться? Почему вы противоречите друг другу?

>> loop, iter.

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

Жабщики и плюсовики не имеют конструкций, сопоставимых по мощности и удобности с iter. Так что не надо про примитивные конструкции, iter совсем не примитивный.

Что же вы не можете с соседями по секте договориться?

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