Здравствуйте, PPA, Вы писали:
PPA>Однако сейчас использую emacs и вместо блокнота в виндовз, потому что типовые операции в нем выполнять быстрее и с меньшим напряжением.
PPA>имхо в винде никто не пользовтался блокнотиком PPA>т.к. есть ворд (купленный/ворованый) Ворд, для простых текстовых операций, помилуйте
Водр хорош для написание документов, или у Вас по View Source и т.п. тоже ворд открывается?
PPA>а вот на счет что "в емаксе удобнее" PPA>не стоит обощать... удобство — это личное
Безусловно, имел ввиду что лично мне удобнее
Здравствуйте, lightSource, Вы писали:
S> Это похоже на проклятие...
Я год писал под linux Suse 7.1(desktop) (c++/QT) и Redhat 7.3(server) (с++/linux api)
работал в Kate (Kde advanced text editor) + комаандная строка для набора make...
отлаживаюсь исключительно всевозможными ассертами и трэйсами в дебуггер лажу очень редко (в год наверное раз 5).
документация — Assistant QT в этом смысле не хуже MSDN, man — если изучить пару комманд less (утилита для просмотра оных) — тоже очень приличная весчь.
Интеграцию (всё в одном) мне успешно заменило наличие N количества десктопов:
1. KTerminal (мо и не так называется — не помню уже) c кучей терминалов с разными манами, + Assistant,
2. Kate где я успешно редактировал исходники — (позволяет кстати создавать проекты из файлов) + консоль для сборки проекта
3. опять же терминалы (для закачки собранного сервера на удалённую машину, для запуска сервера этого сервера там, для запуска клиента у себя...)
4. как правило Konquerror (в котором я успешно, в перерывах созданных компиляциями — как известно gcc имеет 1 недостаток — тормознутость, лазил по инету и в том числе и rsdn.ru ) + SIM (icq)
Вот и всё... Чувствовал себя афигенно комфортно...
Требуется ещё заметить что допустим терминалы в Kterminal у меня были всегда в одном порядке (к примеру 1. сборка клиента, 2. сборка сервера 3. cvs и тд) так что всё было быстро...
При том что тачка почти не вырубалась — "почти" из за редких случаев отрубания электроэнергии — типа запланированные работы на подстанции от которых никуда не деться. И то — в этом случае KDE при старте само восстанавливало все приложения именно в том состоянии в котором они были... (не путать с hibernate в windows).
В винде я тоже MSDN предпочитаю юзать отдельно от MSVC, а в MSVC вырубать почти всё лишнее оставляя код и дерево исходников....
в винде между прочим тоже уйййймище всего для разработки... Digital Mars C++, Symantec C++, Intel C++ , MinGW + tools, Borland C++, Borland Builder C++,MS Visual C++... я многое ещё не указал... Уйма IDE для GCC под вынь...
Пока найдёшь себе то что понравится не один раз выругаешься вслух и на форуме ...
Но почему то как идеал вы выбираете MSVC... Почему? Да потому что всё остальное выглядит не родным на MS платформе... вот и всё... А родной MSVC так гладко вписывается в винду Самому нравится...
Но тогда зачем вы выбрали emacs?????? EMACS — это не Linux и не Windows и не freeBSD средство... это отдельная независимая платформа для разработки под любую платформу, на любой платформе и на любом языке. В эти рамки идеально вписываются gcc и gdb.
Если вы уже выбираете Emacs — вы должны выбрать его для разработки на всех платформах... Забыть о том что есть MSVC и всё остальное... И обретёте свою платформу везде! вам плевать будет где вы сидите, за Windows, MacOS, Linux с KDE, GNOME, вообще без иксов...
Я не пошёл по этому пути... Потому как это действительно нужно иметь особый (по крайней мере не такой как у меня) склад ума или характера... Не знаю... Но человек который хочет на это пойти должен сначало задать себе вопрос — "Хочу ли я потратить кучу времени на настройку своей платформы, не такой как у всех? Или проще мне привыкнуть к новым условиям?"
Я выбрал второе... Для меня действительно оказалось совсем не сложно переходить с платформы на платформы... Представьте себе я сейчас работаю с Mac OS X, дома у меня Win XP и Linux Slackware... Везде у меня свои настройки...
К примеру :
Operation | M | W | L
Copy | Alt + C | Ctrl + C | Ctrl + C
Смена Языка| Alt + Space| Ctrl + Shift| Ctrl + Alt + = (думаю линуксоиды догадаются почему равно и скажут что я ленив — хороший программер всегда ленив )
Ужас? ))
Я не хвалюсь... Я вот первых пару недель ругался матом когда приходил с работы и чтобы переключить раскладку упорно тыкал другой шоткат... Потом привык отличать системы на подсознательному уровне )
Человек такая тварь, что ко всему привыкает...
Так вот.. если хотите Интеграции и ничего не делать: Используйте под виндой MSVC + MSDN + встроенный дебуггер...... Под Linux KDE...под Mac OS X XCode...
И не кричите: "почему у вас мерседес не похожь на нашу волгу — где ручка что б во время морозов его с ручняка завести??? Я не могу жить без ручки!!!"
А либо ездьте на том что дают, либо таскайте свою волгу везде с собой (вариант когда вы пишите на MSVC всегда и везде используя эмуляторы), либо делаете свой танк-амфибию и говорите: "имел я вас всех ввиду — я сам по себе" (естессно это вариант с Emacs )
Вам выбирать
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, PPA, Вы писали:
PPA>Однако сейчас использую emacs и вместо блокнота в виндовз, потому что типовые операции в нем выполнять быстрее и с меньшим напряжением.
PPA>имхо в винде никто не пользовтался блокнотиком PPA>т.к. есть ворд (купленный/ворованый)
Да-да-да... Особенно мощен для написания шелл- и перл-скриптов...
В это плане (не считая, конечно, VBA\VBScript) его FAR уделывает...
Здравствуйте, lightSource, Вы писали:
S>Хочу начать писать на ПИТОНЕ в среде линукс.
Для начала прочитайте Pythin FAQ, раздел про транскрибирование. [пАЙтон], а не [пИтон]
Затем порекомендую прочитать "Unix programming environment" — это касаемо процесса разработки.
Насчет дзена — его нет, пока Вы его ищете. (с)wasm.ru
Да, в общем, это все вопрос мировоззрения... Поначалу, конечно же, утомляет...
Зацените, 21 век на дворе. Этож скоко надо знаааать что б написать книгу ...
Оригинал этой книги создан с использованием великолепного программного обеспечения, доступного в UNIX. Команда типографского набора выглядела следующим образом.
pic files | tbl | eqn | troff -ms
Pic — это язык Брайена Кернигана (Brian Kernighan) для набора рисунков; мы особо признательны Брайену за успешное удовлетворение наших обширных потребностей в иллюстрациях. tbl — это язык Майка Леска (Mike Lesk), предназначенный для макетирования таблиц; eqn — язык Брайена Кернигана (Brian Kernighan) и Лоринды Черри (Lorinda Cherry) для печати математических формул; troff — программа Джо Оссана (Joe Ossana) для форматирования текста при фотонаборе (в нашем случае — для Mergenthaler Linotron 202/N). Пакет макросов ms разработан Майком Леском (Mike Lesk). И наконец, с текстом мы работали с помощью make Стью Фельдман (Stu Feldman); перекрестные ссылки в тексте обрабатывались посредством awk, созданного Альфредом Ахо (Alfred Aho), Брайеном Керниганом (Brian Kernighan) и Петером Вайнбергером (Peter Weinberger), и sed Ли Мак-Мэхона (Lee McMahon).
Здравствуйте, maggres, Вы писали:
M>emacs — это мой выбор, не потому что он удобней MSVS, а потому что в моем случае он удобней чем все остальное. M>Да в нем надо разучивать команды, которые сначала кажуться дико нелогичными, M>ну почему M-w это копировать, а С-y вставить??
Потому что "write" и "yank" . Многие используют C-insert и S-insert.
Здравствуйте, Dj.ValDen, Вы писали:
DV>Но почему то как идеал вы выбираете MSVC... Почему? Да потому что всё остальное выглядит не родным на MS платформе... вот и всё...
Не-а. Потому что удобнее остального......
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Зацените, 21 век на дворе. Этож скоко надо знаааать что б написать книгу ...
KA>Оригинал этой книги создан с использованием великолепного программного обеспечения, доступного в UNIX. Команда типографского набора выглядела следующим образом.
KA>pic files | tbl | eqn | troff -ms
KA>Pic — это язык Брайена Кернигана (Brian Kernighan) для набора рисунков; мы особо признательны Брайену за успешное удовлетворение наших обширных потребностей в иллюстрациях. tbl — это язык Майка Леска (Mike Lesk), предназначенный для макетирования таблиц; eqn — язык Брайена Кернигана (Brian Kernighan) и Лоринды Черри (Lorinda Cherry) для печати математических формул; troff — программа Джо Оссана (Joe Ossana) для форматирования текста при фотонаборе (в нашем случае — для Mergenthaler Linotron 202/N). Пакет макросов ms разработан Майком Леском (Mike Lesk). И наконец, с текстом мы работали с помощью make Стью Фельдман (Stu Feldman); перекрестные ссылки в тексте обрабатывались посредством awk, созданного Альфредом Ахо (Alfred Aho), Брайеном Керниганом (Brian Kernighan) и Петером Вайнбергером (Peter Weinberger), и sed Ли Мак-Мэхона (Lee McMahon).
Я даже книгу эту знаю Исскуство программирования для Unix. Читаю её по крохам уже пару месяцев. Идеология — хороша и красива, как доходит до практики — там всё совсем по другому.
Здравствуйте, lightSource, Вы писали:
S>Здравствуйте, Kubyshev Andrey, Вы писали:
KA>>Зацените, 21 век на дворе. Этож скоко надо знаааать что б написать книгу ...
KA>>Оригинал этой книги создан с использованием великолепного программного обеспечения, доступного в UNIX. Команда типографского набора выглядела следующим образом.
KA>>pic files | tbl | eqn | troff -ms
KA>>Pic — это язык Брайена Кернигана (Brian Kernighan) для набора рисунков; мы особо признательны Брайену за успешное удовлетворение наших обширных потребностей в иллюстрациях. tbl — это язык Майка Леска (Mike Lesk), предназначенный для макетирования таблиц; eqn — язык Брайена Кернигана (Brian Kernighan) и Лоринды Черри (Lorinda Cherry) для печати математических формул; troff — программа Джо Оссана (Joe Ossana) для форматирования текста при фотонаборе (в нашем случае — для Mergenthaler Linotron 202/N). Пакет макросов ms разработан Майком Леском (Mike Lesk). И наконец, с текстом мы работали с помощью make Стью Фельдман (Stu Feldman); перекрестные ссылки в тексте обрабатывались посредством awk, созданного Альфредом Ахо (Alfred Aho), Брайеном Керниганом (Brian Kernighan) и Петером Вайнбергером (Peter Weinberger), и sed Ли Мак-Мэхона (Lee McMahon).
S>Я даже книгу эту знаю Исскуство программирования для Unix. Читаю её по крохам уже пару месяцев. Идеология — хороша и красива, как доходит до практики — там всё совсем по другому.
Это еще из книги Компиляторы. Принципы, технологии, инструменты.
... << RSDN@Home 1.1.4 @wamp>>
It’s never too late to take a fucked up life to a beautiful state.
(c) Crazy Town
Про automake/autoconf и прочие "крутые" средства в начале советую забыть.
Когда нужно будет портировать твою программу на несколько платформ — вспомнишь.
Интерфейс один: консоль.
Т.е. много-много xterm'ов.
vi — редактируем ВСЁ.
make — собираем/запускаем/тестируем.
Отладка — вывод в лог. Очень редко — запуск gdb (лично я его последний раз запускал больше года назад).
Средство автоматизации — скрипты на sh + sed/awk/всёостальное (Perl/Tcl/Python — по желанию).
Для интерактивных программ — expect.
Нужен твоей программе GUI — используешь Tk в связке со своим любимым скриптовым языком (Tcl? Python? Perl?).
Для получения представления "что такое `программировать под Unix'" читаешь здесь и здесь.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Зацените, 21 век на дворе. Этож скоко надо знаааать что б написать книгу ...
KA>Оригинал этой книги создан с использованием великолепного программного обеспечения, доступного в UNIX. Команда типографского набора выглядела следующим образом.
KA>pic files | tbl | eqn | troff -ms
KA>Pic — это язык Брайена Кернигана (Brian Kernighan) для набора рисунков; мы особо признательны Брайену за успешное удовлетворение наших обширных потребностей в иллюстрациях. tbl — это язык Майка Леска (Mike Lesk), предназначенный для макетирования таблиц; eqn — язык Брайена Кернигана (Brian Kernighan) и Лоринды Черри
Дык это же и круто, все программы независимы их можно использовать поотдельности и при этом совместимы. Еще их авторов помнят.
Интересно сколько таких внутренних языков скрыто в MSVC и похожих монолинтых мострах типа MS Word, Exel и т.д. и т.п.?
Здравствуйте, xvost, Вы писали:
DV>>Но почему то как идеал вы выбираете MSVC... Почему? Да потому что всё остальное выглядит не родным на MS платформе... вот и всё...
X>Не-а. Потому что удобнее остального......
Не-а. Потому что стоимость вхождения гораздо ниже.......
Не скажу за отладку и пр., а вот в качестве редактора vim удобнее, чем редакторы с Windows-key-binding (я имею в виду выделение посредством Shift, передвижение через стрелки и Ctrl/Alt/Shift комбинации, работа с клибордом).
Гораздо удобнее. После полутора лет использования vim-а. А предшествующее время приходится терпеть и отплевываться. А это очень большой срок.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, maggres, Вы писали:
M>Здравствуйте, lightSource, Вы писали:
S>> Неужели кто-то ДЕЙСТВИТЕЛЬНО удобно работает в emacs? Не кидает понты, что мне вот удобно, а сам втихаря стонет от множества мелких неудобств, а работает быстро, продуктивно и удобно? Я не вижу дзена, я не вижу цели в этом бесконечном путешествии.
M>Дзен наступает не сразу, в отсутсвии действительно системной документации по миру *nix качественный скачек(Дзен ) наступает только после набора некого критического объема информации и навыков. Это как в науке, может ничего и не наступить
Совершенно верно. Сначала удивляешься всему многообразию и неразберихе, а потом понимаешь насколько все лаконично и логично.
Для того, чтобы побыстрее "въехать" можно почитать "Исскуство программирования в Unix", там много интересного и полезного _всем_ программистам.
Это как ручная коробка передач против автоматической (MSVC). Автомат проще понять и освоить, но любой профи выберет ручную. И не потому что он профи, а потому что он понимает ее приемущества и умеет их использовать.
Если говорить о средах и средствах, то здесь я консервативен: vi, gdb, make, и масса других полезных unix утилит (awk, grep и т.д. и все не вылезая из vi).
Опыт работы с *nix системами подсказывает, что это единственное правильное решение (на счет редактора vi можно поспорить). Изначально пытался использовать разные ide, но перечисленные средства более удобны и просты в использовании при достаточном опыте работы с ними.
Отладка Питон-ых программ о которых так много говорили нужно производить при помощи модуля pdb (import pdb; pdb). Даже в нем интерфейс аналогичный gdb.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, execve, Вы писали:
E>>Средство автоматизации — скрипты на sh + sed/awk/всёостальное (Perl/Tcl/Python — по желанию).
Д>не все любят наборы "сделай сам" Д>некоторые хотят просто работать
О, я чую троля.
Отвечая на такие реплики не знаешь что делать: смеяться или плакать.
Откуда такой глубокомысленный вывод про "сделай сам"? Именно "сделай" и именно "сам"?
Откуда уверенность, что пользователи незнакомого тебе средства разработки не работают, а 99% рабочего времени что-то "дотачивают" и "делают сами"?
И кто им (нам) за это платит зарплату?
Здравствуйте, lightSource, Вы писали: S>Хочу начать писать на ПИТОНЕ в среде линукс. До этого программил три года на С++, всё время в студии и под Виндовс. Теперь появилось время и возвожность изучить Linux и соответственно хочу научиться девелопить и под этого зверька. Но больно уж он кусючий этот зверёк.
Да ну. Вполне можно взять удобные "видузятникам" среды разработки и вперед...
Сам с виндов переходил.
Для С++ понравилась Anjuta.
Для Python, Perl, Tcl очень хороша Komodo (она праавда комерческая, ну дак и студия под виндами не бесплатна).
Здравствуйте, execve, Вы писали:
E>Про automake/autoconf и прочие "крутые" средства в начале советую забыть. E>Когда нужно будет портировать твою программу на несколько платформ — вспомнишь.
E>Интерфейс один: консоль. E>Т.е. много-много xterm'ов.
E>vi — редактируем ВСЁ. E>make — собираем/запускаем/тестируем.
E>Отладка — вывод в лог. E>Очень редко — запуск gdb (лично я его последний раз запускал больше года назад).
E>Средство автоматизации — скрипты на sh + sed/awk/всёостальное (Perl/Tcl/Python — по желанию). E>Для интерактивных программ — expect.
E>Нужен твоей программе GUI — используешь Tk в связке со своим любимым скриптовым языком (Tcl? Python? Perl?).
E>Для получения представления "что такое `программировать под Unix'" читаешь здесь и здесь.
Вот за такой ответ — спасибо. Именно такой ответ я с самого начала и искал. Понятное дело, что путь описанный здесь не единственно верный, но в нём хоть какая-то целостность просматривается.
Здравствуйте, execve, Вы писали:
E>О, я чую троля.
сам ты тролль
E>Отвечая на такие реплики не знаешь что делать: смеяться или плакать.
вероятно — и то, и другое вместе
E>Откуда такой глубокомысленный вывод про "сделай сам"? Именно "сделай" и именно "сам"? E>Откуда уверенность, что пользователи незнакомого тебе средства разработки не работают, а 99% рабочего времени что-то "дотачивают" и "делают сами"?
во первых, откуда у тебя информация, что незнакомого? Во вторых, откуда взялась цифра в 99%?
E>И кто им (нам) за это платит зарплату?
Ну это уж тебе должно быть виднее. Зачем ты у меня то спрашиваешь?
Здравствуйте, execve, Вы писали: E>Про automake/autoconf и прочие "крутые" средства в начале советую забыть. E>Когда нужно будет портировать твою программу на несколько платформ — вспомнишь.
А вот здесь — поправлю... Для бывших виндузятников куда удобнее будет например SciTE в качестве редактора.
Для vi надо заметно перестраивать "думалку". Не всегда оправдано.
E>make — собираем/запускаем/тестируем. E>Отладка — вывод в лог. E>Очень редко — запуск gdb (лично я его последний раз запускал больше года назад).
Ну что тут сказать... логи рулят. Особенно, для многопоточных приложений.
E>Нужен твоей программе GUI — используешь Tk в связке со своим любимым скриптовым языком (Tcl? Python? Perl?).
В задумчивости... мы Tk под виндами используем. ( Хорошая штучка, интерфейсы получаются куда барще, чем в дельфях...) Но уж очень непривычная "мышатникам". Сужу по своим студентам...
Но выучить полезно в любом случае.
Ворд, для простых текстовых операций, помилуйте 
...
))
