Прежде всего — я не планирую вести курс по Шарпу. Он и без меня уже ведется. Я просто хочу понять его. Вы ведь грозите , что скоро вообще все на .Net будет делаться, чуть ли не системные вызовы из него в ядро будут. А на пенсию мне еще рано
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
Влад, смею тебя заверить, что все это мне известно. Но это в основном перехват в пределах процесса или с патчем системных DLL.
VD>Понимаш ли... Когда человек задается вопросами вроде перехвата API-вызвов, то обычно он уже неплохо разбирается в сопуствующих технологиях (платформе Виндовс и ее API, С/С++, отладчиках). При этом он понимает что занимается чистой воды хакерством. Если же такими вещами начинает интересоваться программист, возможно и опытный в дугих делах, но в данной области не опытный, то ничего путного из этого не выйдет. Если же он еще попытается навязать свои привычки в эту новую для него область, то получится просто жудь.
Да кому же я пытаюсь их навязать ? Тебе и Sinclair ? Это смешно. Студентам — так я не буду их этому учить, во-первых, потому что не веду этот курс, во-вторых, потому что понимаю, что хакерству можно учить действительно, неплохо разбираясь в предмете. Но вот я и хочу разобраться, а по своей привычке всегда хочу знать, что там "унутре" делается.
VD>Честно говоря мне кажется (будем надеяться, то именно кажется), что программы по C# у вас не выйдет. Ну, нельзя научить других не желая учиться самому. У вас получится антипрограмма.
Зря кажется. Пока, впрочем, ни о какой реальной программе речи не идет, это все изучение предмета, не более. Но если доведется — все выйдет. Как выходило и раньше — с Алгола на Фортран, с Фортрана на ПЛ/1, с него — на Паскаль, потом на C, потом на C++. Да еще и Basic тут мимоходом въезжал . Я вполне понимаю, что в чужой монастырь со своим уставом не ходят, и доведется жить в этом монастыре — постараюсь по его уставам жить. А пока я этот монастырь имею возможность в качестве туриста наблюдать — почему бы мне и не сравнить его нравы с нравами в близлежащем городе и не поинтересоваться, нельяз ли все же в этом монастыре иногда кино показывать — триллеры или эротику . Естественно, у монахов это вызывает самый праведный гнев
VD>Не исповедуются в ней никакие прицыпы эффективности. В ней принципы надежности и простоты исповедуются. А ты все ищеш эффективность.
Вот именно. Об этом я собираюсь здесь отдельное сообщение написать, так что подожди его выхода, а потом набрасывайся со всем темпераментом
PD>> Так вот, главное, что я понять хочу — где в ней основные неэффективнсти находятся !!!
VD>А нахрена тебе вообще нужно поднимать вопросы эффективности если твоя задача обучить детей приципам платформы и языка?
Я не для этого язык и систему изучаю. Преподавание в данном случае ни при чем.
>Нахрена же детей калеками делать?! Ведь преподование дотнета отталкиваясь от эффективности ты именно маральных уродов из них и сделашь!
Хорошее заявление! Походе даже на манифест .Net. Обязательно его использую.
VD>Пойми же ты, что эффетивность кода даже в С и С++ является областью продвинутых знаний. Эта область напрямую свзяана с особенностями реализации компиляторов, процессоров и т.п. Ну, нельзя это все вываливать на людей с нулевым багажом.
Влад, не стучись в открытую дверь. Если бы даже мне пришлось C# преподавать — у меня хватит ума сначала их обычному программированию (как здесь принято) учить, в потом про Interop и т.д. рассказывать.
PD>> Когда я в С++ програмирую, я всегда знаю, что мне та или иная конструкция стоить будет.
VD>Нифига ты не знашь. Все зависит от тонны факторов. Только на конкретной платформе, с кокретным компилятором и конкретным процессором ты можешь что-то сказать уверенно.
И то для этого нужен конкретный опыт.
Естественно. Но с другими процессорами я уже 15 лет дела не имею, а для Unix не программирую.
VD>Дык, пока что ты начинающий в этой области. Поварись с наше и ты начнешь понимать, что дешево, а что дорого.
Я и пытаюсь
PD>> И вот я вижу конструкцию, которая мне подозрительной по эффективности кажется.
VD>Так расслабся и думах о хорошем. Всеравно фиг ты что угадашь.
Уже угадал — с матрицами. Открою секрет — я таких именно результатов и ждал.
VD>Нельзя. Вернее катигорически не нужно. Причем просто потому, что твоя погоня за мнимой эффективностью кода, ты выплескиваешь ребенка. Ты пыташся программировать на безопастном и простом языке сложно и глупо.
Не спешите с выводами, маэстро . Во-первых, почему мнимой ? Твои и других модификации моего матричного теста дают оптимизацию в 15 раз — это не мнимо! А во-вторых, почему это сложно ? Я пока что вроде не показывал никакого кода, где я пытался бы сделать что-то сложно...
Ну а насчет глупо — оставляю на твоей совести.
VD>Когда потом? Ты программу хочешь тесировать после того как полностью допишеш ее код? Нет ведь. Ты ее постоянно запускаешь и тестируешь. Ту, так что ты не видишь насколько быстро работает твой код?
Вот тут-то собака порылась. Допустим, я никакого C++ не знаю, а сразу на C# начинаю. И вот вижу я это жуткое время перемножения матриц. А почем мне знать, что оно жуткое ? Может, оно нормальное ? Или тот же GetFiles. Да не знаю я никакого Win32, мне и в голову не приходит, что можно иначе! А пишется все так просто и элегантно, и на каталоге в 100 файлов работает так хорошо, прямо замечательно. Все, оттестировали этот блок, поехали дальше. Потом я сам при окончательном тестировании запускаю все это для каталога в 100,000 файлов и привет
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>О господи, да когда же вы перестанете везде наезды искать ?
IT>А разве это не наезды?
Нет, конечно. Ну почему вы (дотнетчики) такие — как что покритикуешь, или даже усомнишься — сразу наезды ? Почему API-шники никаких наездов на себя не замечают ?
IT>1) Любит память, иногда потребляет её столько, что любители выжимать биты из байтов при виде этого падают в обморок.
Хорошая фраза — "выжимать биты из байтов". Не слышал такого, непременно когда-нибудь воспользуюсь. А по существу — отвечу в отдельном сообщении.
IT>2) Требует установки 20 мегабайтного фреймворка, что способствует замедлению распространения.
Ну это не надолго, до LongHorn. В 2003 Server он есть. Это-то как раз неважно ИМХО. В конце концов VCL Delphi тоже не с Windows XP поставляются
H>>Да бросьте Вы, есть решения изначально правильные, а есть по принципу "если очень хочется, то можно". VD>А есть вечно недовольные окружающим люди. И что им недовай они все ворчат.
Не надо грубить! Тема топика про следующий язык программирования. Тут надо смотреть вперед хотя бы лет на 5-10. Если Вас все устраивает в C#+.NET, то новый язык Вам не нужен.
Мне же нужен язык, который бы не просто позволял сделать окно и написать в нем "Hello, world!", а грамотно построить (design&build) приложение снижая вероятность ошибок и не требуя суперспециалистов в качестве исполнителей:
1. Начать с декларативного описания объектной модели: классы, методы, свойства. Причем модель может содержать произвольное кол-во дополнительной информации. Видимо это XML с моей собственной схемой. Но я бы хотел стандартную схему и ряд готовых инструментов для документирования объектной модели, генерации UML диаграмм и т.д.
2. Добавить описание GUI. Что-то типа верстки Web-страниц. Описать все предполагаемые виды форм: расположение элементов, размер, привязка к другим элементам, в том числе с возможностью наследованиея. Например базовая форма RootFrame имеет потомков RootFrameInfo с кнопкой OK и RootFrameQuestion с кнопками Yes, No, но разница в кнопках описывается на дочернем уровне. Короче наследование в интерфейсе.
3. По созданным в предыдущих пунктах моделям добавить реализации методов. Вот реализация может быть сделана на любом языке программирования, причем не обязательно ОО. Может быть импортирована из какого-либо глобального или корпоративного каталога кода.
Также на данном этапе можно попробовать какие-то элементы ИИ для автоматической генерации реализации по заданным спецификациям (test-cases).
На каждом из трех этапов я хочу иметь возможность использовать CVS.
Поддержка программирования как комплексного процесса, а не как набора слабо связанных процессов с достаточно сложной интеграцией, и даст нам новый язык программирования/проектирования приложений.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Dyoma, Вы писали:
D>>Есть замечательный подход: D>>1. Пишем продукт на чем удобно => экономим кучу времени на девелопменте, получаем более качественный (по функциональности и фичам) и сопровождаемый продукт. D>>2. Профилируем в предельных рабочих условия => мягко говорят тормозит, а точнее стоит и выжирает всю память.
IT>Обычно после вот этого весь подход и заканчивается
Нет, там еще есть пункты надо вставить
1.4 менеджмент думает о деньгах.
1.5 — прибегают юзверя и говорят все что думают, и что все стоит, и у кого какая мам.
1.6 — менеджмент думает, о деньгах
PD>Лично мне кажется, что все же должна мсмениться как-то парадигма. Т.е. будущее ИМХО за чем-то, что не явялется языками "операторного" типа. Что именно будет — не знаю. И согласен с тем, что до сих пор ничего такого не было. Но — все мы паровозники. Появится ли здесь наконец тепловозник — трудно сказать.
PD>Вспомни историю с Прологом и японским проектом 5 поколения. Замышлялась именно такая революция. Ничего не вышло, да. Но это не значит, что самам идея неверна. Может, здесь сыграло роль то, что для японцев создание ПО — не самый любимый национальный вид спорта . Может, американцы здесь большего добились бы, если бы взялись. Не знаю.
PD>Но в одном уверен. Если что-то революционное появится — вряд ли это мы предскажем здесь. Если, конечно, не считать революцией такие события, как введение в С++ темплейтов или появление байт-кода. На мой взгляд — на революцию не тянет все это. Точно так же, как серьезной революции я не вижу в переходе от Эниака к Пентиуму 4. Чистая эволюция. Вот если наконец появятся машины нефон-Неймановской архитектуры, тогда это будет революцией.
Тут еще вопрос доминирования. Существуют нейронные сети или нечеткая (fuzzy) логика, но они не решают большого спектра прикладных задач поэтому мы тут обсуждаем C#, а не язык проектирования нейронный сетей. Даже создание Java процессора для байт-кода оказалось менее продуктивной идеей, чем компиляция байт-кода в машинный (JIT). Идеология доминирующей аппаратной архитектуры накладывает сильный отпечаток на популярность языков программирования. Есть наработки в области химических, био, фотонных компьютеров, но их время еще не пришло. Скорей всего языки программирования будут постепенно эволюционировать на все более высокий уровень абстракции.
Здравствуйте, VladD2, Вы писали:
VD>Подход очень правильный... во многих случаях... Но...
Этот подход — частный случай более общей идеи обращения с проблемами:
Проблема возможна? -Да.
Что делать если она случится известно? -Да.
Затраты на ее решение (с учетом вероятности на нее наткнуться) меньше чем затраты/последствия подстилание коврика? -Да
Все хорошо — считаем что проблемы не бывает до тех пор пока на нее не наткнемся . Но в оценках времени учитываем, что возможно решать ее придется.
VD>1. Для "любого" средства банально может быть недоступен профайлер. Или доступен, но такой, что считай, что его нет.
В данном случае ответ на вопрос "Что делать?" отсутствует и такой подход не применим . Это правда не повод отказаться от любимого языка, но повод подумать еще раз и поискать другие пути к отсутплнию...
VD>2. Про задачу может быть заранее известно, что в ней слишком много нужно оптимизировать. Ну, опять же приведем в пример вычислительные задачи. Что толку искать в таких задачах узкие места профайлером? Он их конечно найдет, но это будет 80% кода.
Это весьма спорное место. С одной стороны точно известно что и где должно работать быстро. Но вычисления во многих случаях очень неплохо компилятся в оптимальный код. Тут все зависит от возможностей выбранного компилятора, интерпретатора и т.п.
Хотя был у меня опыт оптимизации очень грамотно написанного C++ кода методом расстановки __forceinline (в отличии от inline это не пожелание, а указание сделать обязательно). Удивительно, но факт, работать стало раза в 3 быстрее. В случае hotspot компиляторов это может не получиться.
VD>3. Если мест требующих оптимизации на другом языке относительно много, то гемороем может стать сама интеграция. Так же если мест 1-2 может оказаться неприятным таскать за собой чужеродные для основного средства разработки модули. Ну, и вообще чем больше интеграции тем болше проблем и гемороя.
Можно пробовать разделить систему на две части, одну удобно писанную, другую быструю. Например, UI писать удобно а логику эффективно. Если конечно получается разделить их небольшим интерфейсом. Руководствуясь общими идеями искать частные подходы...
VD>Я и не спорю. Просто ты видимо пропустил мое замечение: VD>
Это одно и тоже. Архитектура — это алгоритм на очень высоком уровне асбтракции. Но в целом согласен.
Нет, не пропустил, но все-таки мне следовало использовать другую терминологию. Проблемы того что я назыввю "алгоритмами" — проблемы локальные, если подсистема медленно работает ее можно оптимайзить, переписывать, но это не повлияет на остальной код приложения. А проблемы "архитектуры" — это проблемы гловальные, ее изменение может и сохранит отдельные части приложения, но все вцелом будет развалено и надо будет переделывать все и везде. Алгоритм можно оптимизировать, а архитектуру только менять
Здравствуйте, IT, Вы писали:
D>>2. Профилируем в предельных рабочих условия => мягко говорят тормозит, а точнее стоит и выжирает всю память.
IT>Обычно после вот этого весь подход и заканчивается
Угу бывает. А еще некоторые программисты думают что если прога скомпилилась (прошла проверку типов) то она будет работать. И тут они абсолютно правы, вот только воспрос "Что она при этом будет делать?" как-то забывается
Здравствуйте, Cyberax, Вы писали:
C>Чего-то я начинаю в этой истине сомневаться. Слишком часто все "не C>тормозит" (или не жрет памяти) в отдельности, но работает со скоростью C>улитки (или жрет гигибайты) в целом.
C>Причем наблюдается это, в основном, у современного софта — та же ICQ без C>зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20 C>метров. Вот так и не остается памяти для чего-нибудь полезного....
Есть другой взгяд на эту проблему. Все пользователи хотят что бы проги работали быстро и пользовали мало памяти, но только до тех пор пока за это не приходиться платить.
Что тебе больше нравится ICQ и WinAmp жрущие по 20Мb или обойтись без того и другого и в освободившихся 40Мb запустить что-нить полузное?
Dyoma wrote:
> C>Причем наблюдается это, в основном, у современного софта — та же ICQ > без > C>зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20 > C>метров. Вот так и не остается памяти для чего-нибудь полезного.... > Есть другой взгяд на эту проблему. Все пользователи *хотят* что бы > проги работали быстро и пользовали мало памяти, но только до тех пор > пока за это не приходиться *платить*.
А есть еще компании, двигающие "продуктивные" методы и языки.
> Что тебе больше нравится ICQ и WinAmp жрущие по 20Мb или обойтись без > того и другого и в освободившихся 40Мb запустить что-нить полузное?
Я предпочитаю поставить Miranda и Appolo, которые в сумме меньше 15
мегабайт.
Здравствуйте, eao197, Вы писали:
D>>Я например не помню что бы в C++ проектах использовалось столько нестандартных библиотек, сколько является нормой в проектах на java (про C# не знаю, но наверное ситуация похожа, или по крайней мере движется в ту же сторону). И это уже серьезный шаг вперед и не надо про него забывать.
E>Я не помню, когда бы я использовал в C++ больше двух стандартных библиотек: libc и STL. Все остальные библиотеки совершенно не стандартны.
Если ты пишешь под винды, то к стандартным библиотекам следует отнести все документированное api от MS (если документация тоже от MS). Я имел ввиду библиотеки от Васи Пупкина, или от ВасяПупкин Inc
Так же важно не само число использованных библиотек, а сколько кода не пришлось писать (получилось переиспользовать) и сколько фич это сделало возможным.
D>>Собственно а клоню я к тому что "язык" сейчас это уже не только сам язык (синаксис + семантика), а еще и стандарты и инструменты поддерживающие программирование. Более того под языком мы понимаем уже не только платформу, но еще и IDE. Особо заметно это стало с тех пор как IDE перестали быть текстовым редактором с прикрученным дебагером, а поумнели и вместо текстовых файлов стали видеть языковые конструкции.
E>Имхо, это все равно такой же "язык", каким был раньше. Из-за того, что ты перешел с C++ на Java твой стиль мышления в корне не изменился. Как мыслил ты объектами и объектными паттернами, так и продолжаешь. Только детальки различаются.
Мое мышление изменилось когда я с C++ перешел на Smalltalk, на java это было уже после. Я очень люблю Smalltalk, но под java так много написано и можно взять на халяву...
E>А вот если бы ты перешел на какую-нибудь новую парадигму (как это было при переходе от процедурного к объектному подходу) вот тогда бы мышление менять пришлось. И все эти фенечки, вроде IDE и стандартных всеобъемлющих фреймворков, показались бы так -- конфети под ногами.
Что касается других стилей мышления, то я писал и на функциональных языках (ML, Lisp), но стиль мышления это лишь одно из средств достичь результата такое же как reuse, диаграммы a-la UML, refactoring, debuger и все остальное что я использую или могу использовать в своей работе.
Обычно мне удобно смотреть на задачу видя в ней объекты. Но иногда удобно видеть ее как композицию функций и тогда получается функциональный код записанный на объектном языке — не очень удобно, но все-таки лучше, чем интеграция с ML/Lisp.
Ксати, виртуальные машины — это еще один шаг вперед, выбор языка становится менее важным если есть компилятор в эту VM.
E>И новый язык обязательно появится. Может быть его зачатки уже где-то рядом. Тот же Duck typing
, например. Вроде то же самое объектное программирование, но вид настолько сбоку, что крышу слегка сносит.
Наличие типов только в runtime открывает очень интересные возможности (за это я Smalltalk и люблю ), но и вызывает недоверие к компилятору, что мешает такому языку стать mailstream.
К моему большому сожалению Smalltalk нельзя скомпилировать ни в java ни в .Net (так чтобы результат потом еще приемлимо работал, конечно)
Здравствуйте, DarkGray, Вы писали:
DG>например, под C++ так сразу могу только вспомнить из тех, что мы, например, использовали или рассматривали для использования: boost, stingray.
А я вот вспоминаю то, что мы используем: ACE, Boost.Test, Crypto++, libiconv, libxml2 (до этого еще был xerces), xmlsec, PCRE и PCRE++, zlib, gSOAP, OpenSSL, Qt.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Dyoma, Вы писали:
D>>>Я например не помню что бы в C++ проектах использовалось столько нестандартных библиотек, сколько является нормой в проектах на java (про C# не знаю, но наверное ситуация похожа, или по крайней мере движется в ту же сторону). И это уже серьезный шаг вперед и не надо про него забывать.
E>>Я не помню, когда бы я использовал в C++ больше двух стандартных библиотек: libc и STL. Все остальные библиотеки совершенно не стандартны.
D>Если ты пишешь под винды, то к стандартным библиотекам следует отнести все документированное api от MS (если документация тоже от MS). Я имел ввиду библиотеки от Васи Пупкина, или от ВасяПупкин Inc
Правда?
А если я пишу под винды, по к WinAPI не обращаюсь? Через Qt, скажем.
А если пишу под Unix и использую POSIX Threads? Но так же не напрямую, а через ACE_Thread_Manager.
Интересно, а Dimitri van Heesch можно считать Васей Пупкиным? А то я что-то по поводу Doxygen стал беспокоится. Или Aleksey Sanin -- это тоже Вася Пупкин? А команда разработчиков SCons -- это ВасяПупкин Inc? Про Линуса вообще, вероятно, можно не вспоминать.
D>Так же важно не само число использованных библиотек, а сколько кода не пришлось писать (получилось переиспользовать) и сколько фич это сделало возможным.
А вот этого я не понял.
E>>Имхо, это все равно такой же "язык", каким был раньше. Из-за того, что ты перешел с C++ на Java твой стиль мышления в корне не изменился. Как мыслил ты объектами и объектными паттернами, так и продолжаешь. Только детальки различаются.
D>Мое мышление изменилось когда я с C++ перешел на Smalltalk, на java это было уже после. Я очень люблю Smalltalk, но под java так много написано и можно взять на халяву...
Вот в том-то и дело. Что при переходе к объектно-ориентированному программированию изменение мышления происходит. А вот следующей такой идеи, которая бы еще раз сознание перевернула, пока не видно.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вот в том-то и дело. Что при переходе к объектно-ориентированному программированию изменение мышления происходит. А вот следующей такой идеи, которая бы еще раз сознание перевернула, пока не видно.
Ну почему, одна из них уже прозвучала на RSDN некоторе время назад. Всем жить в деревне и про компы забыть. Но это никого не устраивает
Здравствуйте, eao197, Вы писали:
E>Правда? E>А если я пишу под винды, по к WinAPI не обращаюсь? Через Qt, скажем. E>А если пишу под Unix и использую POSIX Threads? Но так же не напрямую, а через ACE_Thread_Manager.
E>Интересно, а Dimitri van Heesch можно считать Васей Пупкиным? А то я что-то по поводу Doxygen стал беспокоится. Или Aleksey Sanin -- это тоже Вася Пупкин? А команда разработчиков SCons -- это ВасяПупкин Inc? Про Линуса вообще, вероятно, можно не вспоминать.
Уговорил Да действительно и на плюсах имел место реюз нестандартных библиотек, но это не было на столько массово. Не было нормой что почти все проекты, очень существенную часть берут со стороны.
D>>Так же важно не само число использованных библиотек, а сколько кода не пришлось писать (получилось переиспользовать) и сколько фич это сделало возможным.
E>А вот этого я не понял.
Например в моем текущем проекте, мы не писали парсеры XML и HTML, а без них проект был бы невозможен.
E>>>Имхо, это все равно такой же "язык", каким был раньше. Из-за того, что ты перешел с C++ на Java твой стиль мышления в корне не изменился. Как мыслил ты объектами и объектными паттернами, так и продолжаешь. Только детальки различаются.
D>>Мое мышление изменилось когда я с C++ перешел на Smalltalk, на java это было уже после. Я очень люблю Smalltalk, но под java так много написано и можно взять на халяву...
E>Вот в том-то и дело. Что при переходе к объектно-ориентированному программированию изменение мышления происходит. А вот следующей такой идеи, которая бы еще раз сознание перевернула, пока не видно.
Дело не только в языке java, а и в инструментах которые вокруг него есть. Вот отличия моего мышления сейчас, от того как я думал лет 5 назад, объекты оставим в стороне. В скобках — какие фенечки делают это возможным.
1. Unit тесты и TDD.
2. Я существенно меньше думаю до написания кода, и существенно больше во время. Потому что теперь есть средства быстро посмотреть что получается (find usages) и поменять свои решения на более адекватные, иногда в несколько нажатий (refactoring). Особо сказывается когда через месяц после написания подсистемы оказывается, что хотим от нее немного другого. И всместо того что бы искривлять все новое под ошибки старого смотрю на что повлияют изменения которые мне нужны (удобная навигация по коду, а не по текстовым файлам).
3. Не заморачиваюсь на проблемы какой объект когда помрет (managed code). За исключением вопроса почему он до сих пор жив.
4. Прямо сейчас вместо того чтобы писать свой собственный велосипед, я ищу подходящий, написанный кем-нить другим (поддежка reuse).
Здравствуйте, Dyoma, Вы писали:
E>>А вот этого я не понял.
D>Например в моем текущем проекте, мы не писали парсеры XML и HTML, а без них проект был бы невозможен.
Ты думаешь в C++ проектах все сплошь и рядом пишут свои парсеры XML и HTML?
Я в это не верю.
E>>Вот в том-то и дело. Что при переходе к объектно-ориентированному программированию изменение мышления происходит. А вот следующей такой идеи, которая бы еще раз сознание перевернула, пока не видно.
D>Дело не только в языке java, а и в инструментах которые вокруг него есть. Вот отличия моего мышления сейчас, от того как я думал лет 5 назад, объекты оставим в стороне. В скобках — какие фенечки делают это возможным.
D>1. Unit тесты и TDD.
Ну и причем тут языки?
D>2. Я существенно меньше думаю до написания кода, и существенно больше во время.
Давай перефразируем: "я меньше думаю до того, как переходить дорогу, чем когда иду на красный свет и гадаю, собьют ли на этот раз?". А современные системы тормозов у автомобилей и запреты водить машину в нетрезвом состоянии позволяют мне оставаться невредимым в большинстве случаев.
Если сначала о чем-то хорошенько подумать, то часто оказывается, что все гораздо проще и не требует навороченного инструмента.
D>3. Не заморачиваюсь на проблемы какой объект когда помрет (managed code). За исключением вопроса почему он до сих пор жив.
А в Smalltalk ты об этом заморачивался?
D>4. Прямо сейчас вместо того чтобы писать свой собственный велосипед, я ищу подходящий, написанный кем-нить другим (поддежка reuse).
И это опять не имеет прямого отношения к языкам.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
, хлопотал о будущей кандидатской. ЗХ>>Зашибись* там все. Всего каких-нибудь лет 20 — и он может быть выберется из ж*пы.
ГА>Так вроде бы ФП не в наших университетах развивается.
В наших тоже, редко, но бывает. Сумрачный русский гений породил, например, такую злую и беспощадную чорную магию, как рефал.
Здравствуйте, Gaperton, Вы писали:
G>В наших тоже, редко, но бывает. Сумрачный русский гений породил, например, такую злую и беспощадную чорную магию, как рефал.
рефал — функциональный язык?
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Так вроде бы ФП не в наших университетах развивается.
Насчет развивается, не сказал бы. Ну разве что Moscow ML. А вот преподается Lisp и Prolog — это да.
А ведь было, было. И Рефал писали, и Lisp для БЭСМ, и много чего еще. И для Эльбруса вычислитель был крутой да параллельный.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Gaperton, Вы писали:
G>>В наших тоже, редко, но бывает. Сумрачный русский гений породил, например, такую злую и беспощадную чорную магию, как рефал. GZ>рефал — функциональный язык?
Насколько я знаю — не без этого .
, что скоро вообще все на .Net будет делаться, чуть ли не системные вызовы из него в ядро будут. А на пенсию мне еще рано 
. Это правда не повод отказаться от любимого языка, но повод подумать еще раз и поискать другие пути к отсутплнию...
быстрее. В случае hotspot компиляторов это может не получиться.
