Здравствуйте, VladD2, Вы писали:
VD>Функциональщину тоже не выбрасываем. Ее для новичков попросту не будет.
Да ты зря, на самом деле те люди которые пробовали Немерле к ней вроде положительно относятся.
Хотя бы на уровне сокращения количества лишних переменных и отсутствия необходимости писать return.
VD>В общих чертах я уже ответил. Остается только сказать, что кроме всего прочего надо создать ощущение, что при переходе на новый язык люди ничего не потеряют. А для этого нужно сделать ряд дел. Закончить поддержку IDE (знаю, что для тебя это не важно, но ты тут скорее искючение). Заставить работать все дизайнеры (ВыньФормс, WPF, WCF, ASP.Net и т.п.).
К слову дизайнер WPF в студии (Cider) в том виде в котором он есть сейчас не слишком доделан сам по себе (там, например, даже event handlers не генерируются по нажатию на кнопку : здесь ).
Здравствуйте, eao197, Вы писали:
E>Что останется от самого Nemerle, если запретить в нем использование макросов ... и отбросить функциональные вещи... ?
Если птысе отрезать крылья.
Если ноги отрезать то тоже.
То она умрёть от скуки.
Патамушта сидеть не сможет!
(с)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>.. физики обнаружили, что существует пять различных вариантов теории струн. Напомним, что их называют теориями типа I, типа IIА, типа IIВ, а также теориями гетеротических струн на основе групп О(32) (О-гетеротические струны) и Е8хЕ8 (Е-гетеротические струны).
M>Многие основные свойства этих теорий совпадают: колебательные моды определяют возможные массы и заряды, общее число требуемых пространственных измерений равно 10, их свернутые измерения должны быть многообразиями Калаби—Яу и т.д.
ага, популярные книжки — это круто
только (к сожалению) они не дают глубокого понимания
эти вещи понять можно только на языке математики...
PI>>тем более в более сложных теориях я не разбираюсь M>Ну я тоже не разбираюсь. От физики я еще дальше чем от математики, но книжка понравилась. Человеческим языком объяснили
единственный способ разобраться глубже — это изучать это дело
и вот эти вот теории на самом деле математические, а не физические...
и вообще, Яу — это тот китайский профессор, который хотел у Перельмана отобрать первенство в доказательстве гипотезы Пуанкаре
называть математику бредом....
.... .... так, пойду до 100 посчитаю, чтобы больше не писать ничего в эту ветку...
Здравствуйте, PhantomIvan, Вы писали:
VD>>Ребят. Теория суперс трун такая бредятина, что ее вообще обсуждать не стоит. А уж в этом форуме и подавно.
PI>я понимаю, что это шутка типа,
Какие шутки? Я за ваше психическое здоровье беспокоюсь. А то наговоритесь о суперструнах, напьетесь крсной ртутути и сгоря погочите жизнь самоубийством повесившись на супер-струне из 9-го измерения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Какие шутки? Я за ваше психическое здоровье беспокоюсь. А то наговоритесь о суперструнах, напьетесь крсной ртутути и сгоря погочите жизнь самоубийством повесившись на супер-струне из 9-го измерения.
гыгыгы
ну да, смешно..
просто кому поговорить, а кому работа
и вообще, пока физики второй десяток лет уже строят большой адронный коллайдер, тратя на них в том числе твои налоги
ты называешь бредятиной теорию струн
вот походи по ссылки, и найди там фамилию хоть одного мудака (астролога или хироманта, допустим)
и вообще, я непонял над чем шутить? этим исследованиям уже больше сотни лет, начиная Максвеллом, продолжая Эйнштейном, вплоть до этих современных попыток построить общую теорию поля
я понимаю, в школе этому не учат, но теория струн, по оценке ответсвенных товарищей, — единственная наиболее развивающаяся отрасль в математической физике в течение последних 20-30 лет
с этими исследованиями связаны надежды, и возможно, будущие разочарования цивилизации как таковой
а тебе тут шутки шутить
я не говорю, что ты без дела сидишь, но как части технической интеллигенции, тебе надо было бы знать эти вещи хотя бы на элементарном уровне
это что, схоластика по-твоему?
Здравствуйте, PhantomIvan, Вы писали:
PI>я лично говорил про 4 измерения (пространственные, время не учитывается) PI>основываясь на астрофизических исследованиях кривизны пространства
Тем не менее, невозможно доказать, что мир имеет 4 и только 4 измерения. Поэтому получается k-мерный (многомерный мир). И данную модель, представленную астрофизиками сделать частной по отношению к многомерной модели мира. Т. е. k=4. Или мы на разных языках разговариваем?
PI>>я лично говорил про 4 измерения (пространственные, время не учитывается) PI>>основываясь на астрофизических исследованиях кривизны пространства
TBG>Тем не менее, невозможно доказать, что мир имеет 4 и только 4 измерения.
вообще говоря, что "невозможно доказать" что-то, это тоже доказывать нужно
TBG> Поэтому получается k-мерный (многомерный мир). И данную модель, представленную астрофизиками сделать частной по отношению к многомерной модели мира.
ты не учитываешь, что это не просто измерения "сами по себе", а в теорию многомерности мира надо ещё все типы физических взаимодействий вписать (их 4 если не вдаваться в подробности, сильное, слабое, гравитационное, электромагнитное)
как-то объяснить феномены на макро- и микроуровне
и т.д.
TBG> Т. е. k=4. Или мы на разных языках разговариваем?
Здравствуйте, VladD2, Вы писали: VD>Ребят. Теория суперс трун такая бредятина, что ее вообще обсуждать не стоит. А уж в этом форуме и подавно.
Ты ее путаешь с торсионными полями. Суперструнная теория развивается в русле основной физики, в отличие от торсионщины.
В ней-то основной эффект состоит в финансировании, которое превышает ортодоксальные оценки на пять-шесть порядков.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, PhantomIvan, Вы писали:
PI>и вообще, пока физики второй десяток лет уже строят большой адронный коллайдер, тратя на них в том числе твои налоги PI>ты называешь бредятиной теорию струн PI>вот походи по ссылки, и найди там фамилию хоть одного мудака (астролога или хироманта, допустим)
Хм, боюсь показаться полным ламером, но по ссылке на сайте о коллайдере _ни слова_ про теорию струн. Или плохо смотрел?
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, PhantomIvan, Вы писали:
PI>>и вообще, пока физики второй десяток лет уже строят большой адронный коллайдер, тратя на них в том числе твои налоги PI>>ты называешь бредятиной теорию струн PI>>вот походи по ссылки, и найди там фамилию хоть одного мудака (астролога или хироманта, допустим)
CU>Хм, боюсь показаться полным ламером, но по ссылке на сайте о коллайдере _ни слова_ про теорию струн. Или плохо смотрел?
это потому что это "незавершённая статья по физике"
если посмотреть английский вариант, то может, яснее станет:
Physicists hope to use the collider to enhance their ability to answer the following questions:
Is the popular Higgs mechanism for generating elementary particle masses in the Standard Model violated? If not, how many Higgs bosons are there, and what are their masses? [2]
Will the more precise measurements of the masses of baryons continue to be mutually consistent within the Standard Model? Do particles have supersymmetric ("SUSY") partners?
Why are there violations of the symmetry between matter and antimatter? Are there extra dimensions, as predicted by various models inspired by string theory, and can we "see" them?
What is the nature of the 96% of the universe's mass which is unaccounted for by current astronomical observations?
Why is gravity so many orders of magnitude weaker than the other three fundamental forces?
кроме того, когда говорится о Стандартной Модели, это все в ту же степь, потому что теория струн в нек. смысле развитие и продолжение этих идей, более элегантное что-ли
и смотри по ссылке о теории струн
Струны в адронной физике
Струны как фундаментальные объекты были первоначально введены в физику элементарных частиц для объяснения особенностей строения адронов, в частности пи-мезонов (пионов).
ну и т.д.
это я для простоты на русский вариант даю ссылки, всё равно малая вероятность, что кто-то читать будет
но если интересно, на 1 шаг глубже можно шагнуть, просто переключаясь на англ. вариант в википедии, он обычно более завершённый, по сравнению с русской версией
это всё важные вещи, хотя всем подряд плевать на эту науку
но если человек не идёт к науке, то наука иногда приходит к нему
например, некоторые физики боятся, что на большом адронном коллайдере можно получить стабильную чёрную дыру
типа хана всем... так шо советую хоть вкурить, от чего мы все погибнуть можем не только от астероидов, которые Брюсь Уиллис пилит...
Здравствуйте, Sinclair, Вы писали:
S>Ты ее путаешь с торсионными полями.
Возможно. Я вообще-то хотел подчеркнуть, что это форум по программированию. И так далеко уводить темы просто нельзя. Это уже бред какой-то получается. Вообще нам пора ужесточать наказания за офтопик и флуд. Точнее вводить его. А то это форум уже становится помойкой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Возможно. Я вообще-то хотел подчеркнуть, что это форум по программированию. И так далеко уводить темы просто нельзя. Это уже бред какой-то получается. Вообще нам пора ужесточать наказания за офтопик и флуд. Точнее вводить его. А то это форум уже становится помойкой.
а по-мойму, всё нормально
просто сюда люди пообщаться приходят
а ты их выгоняешь за дверь просто — нехорошо-с
про помойку можешь не повторять — информации тут и так мало (и так помойка)
а, ещё забыл сказать
в принципе, в данном случае связь с программированием и философием программирования чёткая
видишь ли, большой адронный коллайдер не просто дорогой способ козявки по трубе гонять
фактически, этот проект (хотя может, не только он один) породил Internet-2, т.к. для таких объёмов экспериментальных данных, которые получают в результате экспериментов, просто невозможно организовать централизованное хранилище — эти данные растекаются интернет-2 по всему миру, в том числе в Россию и Украину
более того, обсчёт этих данных — весьма challenging-задача, под которую, возможно, не хватит сил суперкомпьютеров и даже халявного кластера на домашних компах
(по крайней мере, LHC@Home на платформе BOINC работает до сих пор — моделируют поведение пучка в целях не допустить нестабильностей в ходе будущих экспериментов)
а как они обсчитывать реальные эксперименты будут, даже не представляю
там, по идее, гигабайты информации будут по каждому разлёту козявок (не знаю точно, сколько)
Пять научных экспериментов с огромными детекторами будут исследовать процессы, происходящие при столкновении пучков частиц в LHC. Они обработают такое количество информации, сколько обрабатывается в Европейской сети телесвязи сегодня!
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>>>Но если для вас слово комплятор неотрывно следует за словом F5, то сомневаюсь, что вы сможете меня понять. VD>>Понять понимаю. Вот поддержать уже не могу.
TBG>Спасибо за попытку. Большой вам поклон. Но поддерживать и не надо. Мир не плоский. Он объемный.
А вот я не понимаю людей, которые в наше время маниакально следуют традиции 70-х всё и вся писать в vi+bash. У нас нынче уже следующий век! Ортодоксам я могу показать путь к IDE.
1. На самом деле, языки, используемые в bash и в cmd — языки-уродцы с кривым синтаксисом. А вот то же самое можно описать на C# (или, кому как нравится, на Python), благо, чтобы открыть/удалить/создать файл, запустить процесс и т.д. в библиотеках современных языков есть неплохая поддержка.
2. Чем вручную проверять все даты модификации, уместно задать декларативное описание и по нему вызывать нужные функции. Т.к. функции часто применяются, то их можно вынести в отдельную библиотеку и подключать по необходимости. В том же ортодоксальном юниксе есть make, но он не всегда позволяет сделать то, что нужно, да синтаксис bash, который непременно фигурирует в make-описаниях, кривоват, так что пользуются всякими autoconf+automake. И это всё при том, что такие вещи, как MSBuild и Ant гораздо мощнее и красивее.
3. Работать удобнее в GUI (можно даже пофлеймить об этом отдельно, не в этой ветке), причём тут нет никаких ограничений, т.к. я не рассматриваю Unix-сервер как подходящее рабочее место для программиста. Так что ортодокс в начале работы откроет cmd/Konsole/xterm и при каждлой перекомпиляции будет писать make/msbuild (или нажисать стрелку вверх и жать Enter). Но, во-первых, всегда удобнее нажать F5, во-вторых, мы просто экономим время, когда не ищем строку №XXX, а просто щёлкаем мышкой по ошибке и IDE сам показывает нам это место.
Кроме этих пунктов хочу отметить, что у редакторов VS и Eclipse всё-таки больше полезных фич, чем в vi (про фичи сомнительной полезности я умолчу). По крайней мере, это верно для C# и для Java, насчёт других языков я могу заблуждаться. Опять же, связка vi+bash+make позволяет в некотором приближении делать всё то, что я перечислил в трёх пунктах, их можно настроить для такой же удобной компиляции, как F5 в VS, но тогда уместнее говорить о среде vi+bash+make+собственный_набор_скриптов, т.е проблемы с перекомпиляцией отпадают автоматически. И всё-таки, я считаю, что можно банально поставить GUI и юзать себе на здоровье Eclipse, SharpDevelop, MonoDevelop, KDevelop или даже VS, если деньги найдутся, либо VS EE. И не надо при этом извращаться; если нашлись люди, которые автоматизировали процесс, а следовательно сделали его более быстрым и удобным, то надо обрадоваться и заюзать, а не впадать в приступы острой ортодоксии.
konsoletyper wrote: > 1. На самом деле, языки, используемые в bash и в cmd — языки-уродцы с > кривым синтаксисом. А вот то же самое можно описать на C# (или, кому как
Cmd для простоты имеет мучительно кривую семантику. Точнее, уже нет — но
она не влезла в синтаксис. Кривой синтаксис bash... Ну, синтаксис Си
вызывает не меньше вопросов. Часть из них остаётся до C#
> нравится, на Python), благо, чтобы открыть/удалить/создать файл, > запустить процесс и т.д. в библиотеках современных языков есть неплохая > поддержка.
Стоп. Открыть файл — отдельное действие. В bash это не всегда так, хотя
возможно.
> 2. Чем вручную проверять все даты модификации, уместно задать > декларативное описание и по нему вызывать нужные функции. Т.к. функции > часто применяются, то их можно вынести в отдельную библиотеку и > подключать по необходимости. В том же ортодоксальном юниксе есть make, > но он не всегда позволяет сделать то, что нужно, да синтаксис bash, > который непременно фигурирует в make-описаниях, кривоват, так что > пользуются всякими autoconf+automake. И это всё при том, что такие вещи, > как MSBuild и Ant гораздо мощнее и красивее.
MSBuild, вероятно, работает на таком же диапазоне систем? На которых
стоит кривой устаревший не совместимый ни с чем (особенно хоть с одним
стандартом) shell, и странный компилятор. Нормальные заменители make
существуют, вопрос, что не везде они есть.
> 3. Работать удобнее в GUI (можно даже пофлеймить об этом отдельно, не в > этой ветке), причём тут нет никаких ограничений, т.к. я не рассматриваю > Unix-сервер как подходящее рабочее место для программиста. Так что > ортодокс в начале работы откроет cmd/Konsole/xterm и при каждлой > перекомпиляции будет писать make/msbuild (или нажисать стрелку вверх и
Ой. Какой-то несчастный vim-щик, не способный воспользоваться :make. По
ошибкам оно ходить будет само, не надо грязи.
> жать Enter). Но, во-первых, всегда удобнее нажать F5, во-вторых, мы > просто экономим время, когда не ищем строку №XXX, а просто щёлкаем > мышкой по ошибке и IDE сам показывает нам это место.
Видел я человека, руками искавшего в студии строку. В vim я даже при
ненастроенном разборе ошибок строку не ищу, а называю.
> Кроме этих пунктов хочу отметить, что у редакторов VS и Eclipse всё-таки > больше полезных фич, чем в vi (про фичи сомнительной полезности я
Reverse completion: пишем код, использующий функцию, а потом объявление?
> умолчу). По крайней мере, это верно для C# и для Java, насчёт других > языков я могу заблуждаться. Опять же, связка vi+bash+make позволяет в > некотором приближении делать всё то, что я перечислил в трёх пунктах, их > можно настроить для такой же удобной компиляции, как F5 в VS, но тогда > уместнее говорить о среде vi+bash+make+собственный_набор_скриптов, т.е
Или стандартный... Только vim, а не vi.
> проблемы с перекомпиляцией отпадают автоматически. И всё-таки, я считаю, > что можно банально поставить GUI и юзать себе на здоровье Eclipse, > SharpDevelop, MonoDevelop, KDevelop или даже VS, если деньги найдутся, > либо VS EE. И не надо при этом извращаться; если нашлись люди, которые > автоматизировали процесс, а следовательно сделали его более быстрым и > удобным, то надо обрадоваться и заюзать, а не впадать в приступы острой > ортодоксии.
Если эти люди автоматизировали процесс, как им удобно, а я — как мне удобно?
Здравствуйте, raskin, Вы писали:
R>konsoletyper wrote: >> 1. На самом деле, языки, используемые в bash и в cmd — языки-уродцы с >> кривым синтаксисом. А вот то же самое можно описать на C# (или, кому как R>Cmd для простоты имеет мучительно кривую семантику. Точнее, уже нет — но R>она не влезла в синтаксис. Кривой синтаксис bash... Ну, синтаксис Си R>вызывает не меньше вопросов. Часть из них остаётся до C#
Вот как раз синтаксис одинаково кривой, что у bash, что у cmd. У C# синтаксис гораздо симпатичнее. А вот семантика и правда у cmd убогая.
R>MSBuild, вероятно, работает на таком же диапазоне систем? На которых R>стоит кривой устаревший не совместимый ни с чем (особенно хоть с одним R>стандартом) shell, и странный компилятор. Нормальные заменители make R>существуют, вопрос, что не везде они есть.
Вот у меня лежит дистрибутив Fedora Core 3 вместе с исходниками (ну да, не самый новый ). Исходники по большей части (приятное исключение — QT+KDE) написаны на C. Причём в половине из них используется устаревший синтаксис объявления функций, когда типы параметров вынесены отдельно — это несмотря на то, что стнадарт C99 такую штуковину отменил. Я понимаю в данном случае авторов ядра или драйверописцев, но я не могу понять, например, авторов Beep Media Player, который стал развиваться уже в Java-ную (и уж, тем более, в пост-C++) эпоху. Вроде как Linux с Явой дружит, и, хотя в Линуксе отсутсвовала Java, был её GNU-аналог. В README такие умельцы как раз и пишут про некоторую "совместимость", хотя C++ и Java давно стандартизированы и если где-то они не пойдут, так это на 0.5% устаревших машин.
>> 3. Работать удобнее в GUI (можно даже пофлеймить об этом отдельно, не в >> этой ветке), причём тут нет никаких ограничений, т.к. я не рассматриваю >> Unix-сервер как подходящее рабочее место для программиста. Так что >> ортодокс в начале работы откроет cmd/Konsole/xterm и при каждлой >> перекомпиляции будет писать make/msbuild (или нажисать стрелку вверх и R>Ой. Какой-то несчастный vim-щик, не способный воспользоваться :make. По R>ошибкам оно ходить будет само, не надо грязи.
Нажать F5 — одно касание, набрать <ESC>:make — 6 касаний. Вопрос: что дольше?
>> Кроме этих пунктов хочу отметить, что у редакторов VS и Eclipse всё-таки >> больше полезных фич, чем в vi (про фичи сомнительной полезности я R>Reverse completion: пишем код, использующий функцию, а потом объявление?
Generate method stub в VS?
>> проблемы с перекомпиляцией отпадают автоматически. И всё-таки, я считаю, >> что можно банально поставить GUI и юзать себе на здоровье Eclipse, >> SharpDevelop, MonoDevelop, KDevelop или даже VS, если деньги найдутся, >> либо VS EE. И не надо при этом извращаться; если нашлись люди, которые >> автоматизировали процесс, а следовательно сделали его более быстрым и >> удобным, то надо обрадоваться и заюзать, а не впадать в приступы острой >> ортодоксии. R>Если эти люди автоматизировали процесс, как им удобно, а я — как мне удобно?
А вот есть пара фич, удобных объективно. Например, подсветка имён типов. Или хинты при наведении мышки. Советую заюзать — это не кому-то удобнее, это, если преодолеть брезгливость, повысит производительность любого. Где такие фичи в vim?
konsoletyper wrote: >>> 1. На самом деле, языки, используемые в bash и в cmd — языки-уродцы с >>> кривым синтаксисом. А вот то же самое можно описать на C# (или, кому как > R>Cmd для простоты имеет мучительно кривую семантику. Точнее, уже нет — но > R>она не влезла в синтаксис. Кривой синтаксис bash... Ну, синтаксис Си > R>вызывает не меньше вопросов. Часть из них остаётся до C# > > Вот как раз синтаксис одинаково кривой, что у bash, что у cmd. У C# > синтаксис гораздо симпатичнее. А вот семантика и правда у cmd убогая.
Особенно мне симпатична возможность ставить ";" в случайном месте. Радует,
что программа не перестаёт компилироваться — только работать... У
некоторых людей for с пустым телом и с одной командой — без {} —
встречаются попеременно.
В shell что неприятно (если не пользоваться ``, которые давно устарели,
ибо $(), ну и ${} ставить полезно), так это нетривиальные случаи ${},
вроде ${A##b}.
> R>MSBuild, вероятно, работает на таком же диапазоне систем? На которых > R>стоит кривой устаревший не совместимый ни с чем (особенно хоть с одним > R>стандартом) shell, и странный компилятор. Нормальные заменители make > R>существуют, вопрос, что не везде они есть. > > Вот у меня лежит дистрибутив Fedora Core 3 вместе с исходниками (ну да, > не самый новый ). Исходники по большей части (приятное исключение — > QT+KDE) написаны на C. Причём в половине из них используется устаревший > синтаксис объявления функций, когда типы параметров вынесены отдельно — > это несмотря на то, что стнадарт C99 такую штуковину отменил. Я понимаю
Компиляторы, компилирующие только так, бывают. Компиляторы, которые
нельзя заставить это компилировать — редкость.
> в данном случае авторов ядра или драйверописцев, но я не могу понять, > например, авторов Beep Media Player, который стал развиваться уже в > Java-ную (и уж, тем более, в пост-C++) эпоху. Вроде как Linux с Явой > дружит, и, хотя в Линуксе отсутсвовала Java, был её GNU-аналог. В README > такие умельцы как раз и пишут про некоторую "совместимость", хотя C++ и > Java давно стандартизированы и если где-то они не пойдут, так это на
Э-э.. Стандартный Си++ — отличная вещь, жаль компилятор есть только
один и им никто не пользуется. > 0.5% устаревших машин.
Но ведь есть и такие. Хорошо с совместимостью у проектов, в которых у
авторов — разное по архитектуре железо. Но спорт писать переносимо есть,
иногда излишен.
Вопрос в том, что MSBuild не самосовместится даже на двух существенно
разных ОС (покойная 9x и NT — полторы, а не две..).
>>> 3. Работать удобнее в GUI (можно даже пофлеймить об этом отдельно, не в >>> этой ветке), причём тут нет никаких ограничений, т.к. я не рассматриваю >>> Unix-сервер как подходящее рабочее место для программиста. Так что >>> ортодокс в начале работы откроет cmd/Konsole/xterm и при каждлой >>> перекомпиляции будет писать make/msbuild (или нажисать стрелку вверх и > R>Ой. Какой-то несчастный vim-щик, не способный воспользоваться :make. По > R>ошибкам оно ходить будет само, не надо грязи. > > Нажать F5 — одно касание, набрать <ESC>:make — 6 касаний. Вопрос: что > дольше?
А кто сказал, что в :map не загнано?
>>> Кроме этих пунктов хочу отметить, что у редакторов VS и Eclipse всё-таки >>> больше полезных фич, чем в vi (про фичи сомнительной полезности я > R>Reverse completion: пишем код, использующий функцию, а потом объявление? > > Generate method stub в VS?
А как оно работает? Я пишу "function GetFi", жму completion, и мне
дописывают
имя? После чего говорю дать тело, и тело пишут по шаблону?
>>> проблемы с перекомпиляцией отпадают автоматически. И всё-таки, я считаю, >>> что можно банально поставить GUI и юзать себе на здоровье Eclipse, >>> SharpDevelop, MonoDevelop, KDevelop или даже VS, если деньги найдутся, >>> либо VS EE. И не надо при этом извращаться; если нашлись люди, которые >>> автоматизировали процесс, а следовательно сделали его более быстрым и >>> удобным, то надо обрадоваться и заюзать, а не впадать в приступы острой >>> ортодоксии. > R>Если эти люди автоматизировали процесс, как им удобно, а я — как мне > удобно? > > А вот есть пара фич, удобных объективно. Например, подсветка имён типов.
Это просто развитие syntax highlighting или я чего-то крупно не понял?
> Или хинты при наведении мышки. Советую заюзать — это не *кому-то*
Не уверен, что перенос рук на тачпад мне удобен. tags настроены, то есть
объявление быстро посмотреть можно — в одну комбинацию клавиш, если
курсор где надо.
> удобнее, это, если преодолеть брезгливость, повысит производительность > любого. Где такие фичи в vim?
Я не буду спрашивать, есть ли у VS фича не кушать много памяти или
запускаться за 10 секунд.
Но у меня уже много всего накручено на ViM (причём мною лично). Для
разных файлов. Автоматическое окружение выделенной области частыми
тегами — для HTML. Расстановка пробелов — для ТеХ. Переходы по связанным
файлам и шаблонная вставка — для Pascal. Ну и просто мне удобен поиск
как <esc>-/ — в том же окне — и переход к строке с данным номером <esc>:
. Мне не хочется всё это переписывать на язык без REPL или на BASIC.
: здесь ).
1.2.0 alpha rev. 655
