Здравствуйте, eao197, Вы писали:

E>Тем более, есть у меня подозрения, что большинство из противников shell и binutils просто никогда не занимались более-менее внимательным их изучением.

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

Здравствуйте, VladD2, Вы писали:

E>> Они адаптированны под такие цели не хуже (если не лучше), чем современные IDE
VD>Это алогизм. Они вообще не могут сравниваться с IDE как не может сравниваться с IDE библиотека. С IDE надо сравнивать редактор в котором ты редактируешь шел-скрипты. А сами шел-скрипты с ЯП сравнивать. Вот тогда будет все логично.

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

Здравствуйте, konsoletyper, Вы писали:

K>К слову. Если я не ошибаюсь, то интеграция пишется без использования IDE (кстати, а кто что использует?). Вот когда интеграция будет писаться на интеграции, тогда и посмотрим, какая будет производительность (хотя объективно её оценивать нельзя по вышеназванным причинам).

А никто не хочет пописать интеграцию на готовой интеграции MonoDevelop? Сам не смотрел, но учитал в features'ах строчку "Nemerle Project Support".

Здравствуйте, IT, Вы писали:

IT>интеграции (и который ты не учёл в своём анализе), с другой VS SDK, вообще ещё находящаяся в активной разработке. В-третьих, многие из тех, кто участвует в проекте делают то, что они делают первый раз в жизни и делают это на новом для них языке. В лучшем случае у некоторых есть

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

Здравствуйте, konsoletyper, Вы писали:

K>Я говорил не про скорость программирования а про скорость кодинга. ИМХО, это разные понятия. Я никогда не пишу код, пока точно не

Скорость кодинга в таком случае повысят специальные шлемы для кодеров.

К>>А тут могут быть полезны диаграмки классов и т.п. инструменты.
K>Никогда не юзал диаграммки классов. Обычно, то что нужно обдумывать отдельно, я держу в голове. Там, где нужно проектировать, я долго думаю,

А зря. Обычно это не просто диаграммки, с которыми поигрался, это еще и то, что останется другим. Кстати, подумайте о подобной моей фантазии:

Никогда не пользовал рефакторинг. Обычно я сажусь и пишу что мне нужно. Зачем не эта IDE?

K>обсуждаю с другими, думаю, сажусь за комп, запускаю студию, думаю, набиваю черновики интерфейсов, обдумываю то, что написал и т.д. Просто, ИМХО, набить скелет класса или интерфейс быстрее и проще, чем что-то рисовать. А потом можно по интерфейсам построить в студии диаграммы, распечатать их и начать обсуждать с другими.

Диаграммы, еще раз диаграммы. Без диаграм ваша IDE и не I вовсе, а специализированный редактор кода.

Здравствуйте, VladD2, Вы писали:

VD>Лично у меня основное время уходит именно на эксперементы с кодом.

Подчеркнем слово лично?

VD>Вот на что я действительно трачу время в остуствии полноценной IDE, так это на добычу нужной информации и на разберательство с чужим кодом. Стало быть мы опять упираемся в важность IDE если хотим чтобы наша роизводительность труда была высокой.

Гугль тоже помогает добыть нужную информацию..

VD>А диаграмы классов это тоже часть современной IDE. Правда полезны они скорее не для проектирования, а скорее для изучения (на высоком уровне) чужого кода.

А также документирования своего (чтобы потом изучить могли такие же).

Здравствуйте, Turtle.BAZON.Group, Вы писали:

IT>>И чем же тебе дебагер не угодил

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

Первый раз сталкиваюсь с таким мнением. Тем не менее не удивительно, что оно из серии закручивания гвоздей отвёрткой.

Вообще же, до сегодняшнего дня, все те, кто мне встречался в жизни и негативно отзывался об отладчике просто не умели им пользоваться. Но если вдруг припекало, то после небольшого лекбеза всё становилось на свои места. Некоторые даже с восторгом потом рассказывали как это кульно, когда отладчик сам останавливается в случае возникновения исключения. Вау! Круто!

Это относится обсолютно ко всем тем, с кем я когда-либо работал и кто клеймил по чём зря и сам отладчик и тех кто им пользуется. Я даже сам когда-то был таким. Боюсь, в онлайн эта ситуация (неприятие из-за непонимания, а не из-за чего-либо по делу) мало чем отличается, для этого просто нет никаких причин. По-крайней мере, до сих пор их никто не озвучил. Непонимание, неумение, домыслы, заблуждения, необоснованные суждения (как в твоём случае) — этого хоть отбавляй, но вот реальных фактов я пока не встречал ни разу. По-этому, хочется пожелать только одного — учите мат. часть и учитесь пользоваться инструментарием, который имеется в вашем распоряжении. Это гораздо полезей, чем хаить то, чего не понимаешь и чем не умеешь пользоваться.

Здравствуйте, Turtle.BAZON.Group, Вы писали:

IT>>интеграции (и который ты не учёл в своём анализе), с другой VS SDK, вообще ещё находящаяся в активной разработке. В-третьих, многие из тех, кто участвует в проекте делают то, что они делают первый раз в жизни и делают это на новом для них языке. В лучшем случае у некоторых есть

TBG>Это и хотелось отметить при споре об IDE. В этом случае фенечки не помогут. Ибо знание области, в которой работаешь, никто не отменял. И уж что в этом случае будует — редактор или интерактив — дело лишь приятных мелких дополнений.

Всё как раз с точностью до наоборот. Одна из основных проблем с которой приходится сталкиваться при написании интеграции — это отсутствие навигации по коду. Для того, чтобы понять как работает тот или иной класс или метод нужно перейти к его объявлению и посмотреть как оно там всё устроено. При нормально работающей "фенечке" — это одно нажатие кнопки.

По этой причине все интеграции, которые я до сих пор видел, написаны не на языках для которых они пишутся, а на C#. У нас тоже часть интеграции написана на C# и планов переписывать её на N пока нет. А то, что мы всё-таки часть интеграции, касающуюся работы с самим компилятором, пишем на самом Немерле, так это только потому, что на C# это было бы на порядок сложнее и многословнее.

Здравствуйте, Turtle.BAZON.Group, Вы писали:

VD>>Лично у меня основное время уходит именно на эксперементы с кодом.

TBG>Подчеркнем слово лично?

Это ты о фразе Курилки:

Это всё здорово, конечно, но есть другой вопрос — скорость программирования у тебя определяется скоростью набора на клавиатуре? ИМХО это далеко не так и гораздо больше времени уходит на обдумывание и проектирование.

?

Да, согласен, "лично" здесь было куда лучше чем "у тебя".


VD>>Вот на что я действительно трачу время в остуствии полноценной IDE, так это на добычу нужной информации и на разберательство с чужим кодом. Стало быть мы опять упираемся в важность IDE если хотим чтобы наша роизводительность труда была высокой.

TBG>Гугль тоже помогает добыть нужную информацию..

Молодец. Вставил весоме слово. И хотя к делу оно не относится, но типа поддержал беседу.

Здравствуйте, Turtle.BAZON.Group, Вы писали:

VD>>Это алогизм. Они вообще не могут сравниваться с IDE как не может сравниваться с IDE библиотека. С IDE надо сравнивать редактор в котором ты редактируешь шел-скрипты. А сами шел-скрипты с ЯП сравнивать. Вот тогда будет все логично.

TBG>А по-моему, надо выделить слово цели и рассматривать с этих позиций. Вполне допустимо, что при таком положении возможно сравнение с IDE, хотя с другой позиции и нет.

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

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>shell обладает теми возможностями, которми наделяет ее тот, кто этим shell'ом пользуется.

Извини, но твои сообщения все более и более бессмысленны. Я даже не понимаю что на них отвечать то?

VladD2 wrote:
> VD>>Это алогизм. Они вообще не могут сравниваться с IDE как не может
> сравниваться с IDE библиотека. С IDE надо сравнивать редактор в котором
> ты редактируешь шел-скрипты. А сами шел-скрипты с ЯП сравнивать. Вот
> тогда будет все логично.
>
> TBG>А по-моему, надо выделить слово *цели* и рассматривать с этих
> позиций. Вполне допустимо, что при таком положении возможно сравнение с
> IDE, хотя с другой позиции и нет.
>
> Надо было в институте логику изучать, тогда трепаться на тему сравнения
> мягкого с теплым даже говорить не захотелось бы.
Ну почему же, если сравнивать набор "IDE+язык для которого она
+стандартная библиотека+часто всеми используемые библиотеки" для
какого-нибудь универсального языка и "command-line shell и редактор
вроде vim+язык shell+POSIX-утилиты и builtins+консольные программы,
установленные на большинстве систем" — то вроде бы вполне сравнивается
полный набор с полным набором. И утверждение состоит ровно в том, что
есть задачи, которые для многих людей второй набор решает проще, быстрее
и удобнее, хотя задач, которые он за разумные усилия не решает, намного
больше.

Здравствуйте, IT, Вы писали:

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

IT>Первый раз сталкиваюсь с таким мнением. Тем не менее не удивительно, что оно из серии закручивания гвоздей отвёрткой.

Не. Оно скорее напоминает обругивание молотка за то что кто-то им болты пытается забивать.

IT>По-этому, хочется пожелать только одного — учите мат. часть и учитесь пользоваться инструментарием, который имеется в вашем распоряжении. Это гораздо полезей, чем хаить то, чего не понимаешь и чем не умеешь пользоваться.

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

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>Здравствуйте, konsoletyper, Вы писали:

K>>А если по делу, то мне непонятно, зачем одновременно пользоваться утилитами командной строки и IDE, если есть IDE? Зачем пользовать vim, если есть Eclipse, MinGWDeveloperStudio, SharpDevelop, а для простейших нужд по модификации текста с головой хватит gedit (или kate, кому как нравится).

TBG>А давайте произнесем это по другому. Зачем пользоваться Eclipse, MinGWDeveloperStudio, SharpDevelop, если есть vim?

Ты и сам знаешь. Затем, что редактируется не "текст", а код некоторой программной системы — проект.

TBG> Если нужно произвести редактирования текста?

Если текст на разговорном языке, то для этого есть специализированные редакторы вроде МС Ворда или Стар офисовского Ворда.

vim хорош там где нет более мощьных продуктов так как его можно настроить больше чем простой редактор. По сути vim — это практически IDE, только по слабее чем лучшие аналоги.

TBG> И не более того? Почему не kate и gedit? Потому что не привык я к ним. Мне проще vim. И удобнее, и продуктивнее. Да и не умеет kate lisp форматировать как мне нравится.

А другим vim не привычнее. И что?

TBG>Когда не хочется думать, а просто посидеть, поразмышлять о вечном, то тогда чашечка чая, интерактивная отладка.

Хм. А кто-то радяом спрашивал "зачем нружен отладчик?". Это не ты был?

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>А никто не хочет пописать интеграцию на готовой интеграции MonoDevelop? Сам не смотрел, но учитал в features'ах строчку "Nemerle Project Support".

Ты бы сначало спросил можно ли ее вообще использовать.

На сегодня она вообще не работает. Я когда начинал Интеграцию ддя студии использовал как раз движок созданный для MonoDevelop. Так вот он практически не работал. Там все было на соплях, да и назвать "это" словом "было" тоже натяжка. Там были зачатки комплита. Которые работали в 1 случае из 10. Плюс кривая подсветка реализованная на шарпе в самом проекте MonoDevelop.

Учитывая что даже сейчас полноценно использовать Интеграцию для собственной разработки практически невозможно, то понятно, что говорить об использовании MonoDevelop вообще не серьезно.

Здравствуйте, VladD2, Вы писали:

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

Так давай его забаним как троля на недельку.

Здравствуйте, raskin, Вы писали:

R>Ну почему же, если сравнивать набор

"Если" замечательное слово. На практике же сравниваются язык с утилитой, а Turtle.BAZON.Group вообще дошел до сравнения утилиты с IDE.

R>вроде vim+язык shell+POSIX-утилиты и builtins+консольные программы,
R>установленные на большинстве систем"

На большинстве систем?

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

Впрос в том, что не все задачи предусмотренны grep-ом или другой часто используемой утилитой. В таком случае приемущество шела резко исчезает.
И еще в том, что все приемущества резко заканчиваются как только в универсальном языке появляется аналог утилиты.

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

Изначально сравнивались не "общие решения", а языки. Со стороны наших оппонентов прозвучал тезис о том, что именно шел-скрипты лучше чем хороший универсальный ЯП.
Надеюсь, на данный помент уже всем очевидно, что это утверждение ошибочно.

VladD2 wrote:
> R>Ну почему же, если сравнивать набор
>
> "Если" замечательное слово. На практике же сравниваются язык с утилитой,
> а Turtle.BAZON.Group <http://rsdn.ru/Users/Profile.aspx?uid=40386&gt;
> вообще дошел до сравнения утилиты с IDE.
>
> R>вроде vim+язык shell+POSIX-утилиты и builtins+консольные программы,
> R>установленные на большинстве систем"
>
> На большинстве систем?
Да, неадекватно сказал, надо было сказать большинство систем, на которых
вообще есть shell. Ну или большинство web-серверных систем (по
численному большинству — чтобы Apache/unix-like всех обогнал).

> R> — то вроде бы вполне сравнивается
> R>полный набор с полным набором. И утверждение состоит ровно в том, что
> R>есть задачи, которые для многих людей второй набор решает проще, быстрее
> R>и удобнее, хотя задач, которые он за разумные усилия не решает, намного
> R>больше.
>
> Впрос в том, что не все задачи предусмотренны grep-ом или другой часто
> используемой утилитой. В таком случае приемущество шела резко исчезает.
> И еще в том, что все приемущества резко заканчиваются как только в
> универсальном языке появляется аналог утилиты.
case по строкам — по wildcard. В каком компилируемом языке он есть и
сколько лет как? Ну и ясно, что появиться он в принципе может очень не
во многих.

> А раз так, то мы имеем стуацию когда для решения задач используются
> менее удобные инструменты только потому, что в месте с ними поставляются
> готорые утилиты.
Возможных конкурентов для shell в его задачах из универсальных языков я
вижу. Штуки две-три. Можно написать макросов для Nemerle или замучить
scsh (ну или с нуля другую Scheme, вроде guile). Будет это иногда на
одном экране кода давать незначительное преимущество — и то не всегда. И
их нигде не установлено... И при этом пригодность в качестве login shell
у первого явно отсутствует, да и у второго не так велика — на одной
команде уже начинают раздражать лишние символы (2 из 10)...

> Изначально сравнивались не "общие решения", а языки. Со стороны наших
> оппонентов прозвучал тезис о том, что именно шел-скрипты лучше чем
> хороший универсальный ЯП.
> Надеюсь, на данный помент уже всем очевидно, что это утверждение ошибочно.
Ну, мне это не очевидно, так как преувеличение не может быть очевидно
верным.

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

IT>Так давай его забаним как троля на недельку.

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

PI>>а у тебя автоматизирован компайл в нём?
PI>>(чтоб рядом dvi всегда отображался актуальным, и не нужно было каждый раз компиляцию жать)

TBG>В TeX автоматизированный компайл и не нужен, ведь это логическая разметка текста, а не верстка календарика. И зачем каждый раз компиляцию жать? Ведь это надо по сути в конце только.

ха, это как кому
вот, открыл файл, копирую случайную формулу оттуда:

\begin{equation}
\left\{\begin{array}{l}
    \label{GeneralizedSystemLastCoordinateNulled}
    \dot x_1=\alpha_1x_1f_1(x_2)-\beta_1x_1^2-k_1x_1-\alpha_2x_1x_2f_2(x_3)\\
    \dot x_2=\alpha_2x_1x_2f_2(x_3)-\beta_2x_2^2-k_2x_2-\alpha_3x_2x_3f_3(x_4)\\
    \quad\ldots\\
    \dot x_i=\alpha_ix_{i-1}x_if_i(x_{i+1})-\beta_ix_i^2-k_ix_i-\alpha_{i+1}x_ix_{i+1}f_{i+1}(x_{i+2})\\
    \quad\ldots\\
    \dot x_{n-3}=\alpha_{n-3}x_{n-4}x_{n-3}f_{n-3}(x_{n-2})-\beta_{n-3}x_{n-3}^2-k_{n-3}x_{n-3}-\alpha_{n-2}x_{n-3}x_{n-2}f_{n-2}(x_{n-1})\\
    \dot x_{n-2}=\alpha_{n-2}x_{n-3}x_{n-2}f_{n-2}(x_{n-1})-\beta_{n-2}x_{n-2}^2-k_{n-2}x_{n-2}-\alpha_{n-1}x_{n-2}x_{n-1}f_{n-1}(0)\\
    \dot x_{n-1}=\alpha_{n-1}x_{n-2}x_{n-1}f_{n-1}(0)-\beta_{n-1}x_{n-1}^2-k_{n-1}x_{n-1}\\
    \dot x_n=0
\end{array}\right.
\end{equation}

и ты мне говоришь, что компилить совсем-совсем не нужно?

TBG> Или в промежутке когда устал, хочется чем-то позаниматься отвлеченным. А вообще, TeX посмотрите.

а что мне на него смотреть? я с ним работаю давно — даже TeX Book читал (до середины)

TBG> Или docbook, если нравится.

(ла)тех — для формул, а не для "логической разметки текста"
чисто для разметки html хватает, он для этого предназначен