Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Прежде всего — я не планирую вести курс по Шарпу.
Хто хорошо, так как с таким отношеием как у тебя сейчас ты скорее анти-курс сможешь вести.
PD> Он и без меня уже ведется. Я просто хочу понять его. Вы ведь грозите , что скоро вообще все на .Net будет делаться, чуть ли не системные вызовы из него в ядро будут. А на пенсию мне еще рано
"Все" еще не скоро. Думаю, на твой век (ну, до пенсии хотя бы) работы плюсовику найдется.
Что до системных вызовов в ядро... Дык они так и делаются. Тут менеджед код мало чем отличается. Ядро то доступно через АПИ мапящйстя на память процесса.
В общем, если ты правда стремишся разобраться, то делашь это неверно. Как минимум до изучения вопросов производительности нужно изучить возможности и паттерны принятые в этой среде.
PD>Влад, смею тебя заверить, что все это мне известно.
Тогда зачем ты говоришь, что есть только один способ?
PD> Но это в основном перехват в пределах процесса или с патчем системных DLL.
Гы. А что процессы уже пеодалены? Если перехват не делается из нулевого кольца, как это, например, делает СофтАйс, то перехват возможен исключительно в рамках процесса. Межпроцессные вызовы идут только через ядро или через специальные механизмы которые один фиг в конце концов используют ядро для комуникации.
Так что твои слова про единственный метод просто неверны.
PD>Да кому же я пытаюсь их навязать ?
Всем окружающим. Возьмем пример с мемсет. Ты спрашивашь чем заменить memset(xx, 0) для структуры. Тебе отвечают new ИмяВэлюТипа(). Далее ты начинашь всех убеждать, что это не то, что это уродство и т.п., а в конце оказывается (и до этого можно только догадаться), что тебя смутило ключевое слово "new" которое ты привык видеть при динамическом распределении памяти и что ты оказывается боялся за эффективность.
PD> Тебе и Sinclair ? Это смешно.
Смешно, не смешно — это факт.
PD> Студентам — так я не буду их этому учить, во-первых, потому что не веду этот курс, во-вторых, потому что понимаю, что хакерству можно учить действительно, неплохо разбираясь в предмете. Но вот я и хочу разобраться, а по своей привычке всегда хочу знать, что там "унутре" делается.
Ну, тогда ты должен понять, что твои знания в дотнете на сегодня такие же как у тех студентов в области которой ты их учишь. И что то что ты просишь именно такое хакерство. И что если тебе просто показать "как это можно сделать", то эффект будет ровно обратным. Да и не так то просто объяснить казалось бы простые вещи если нет базовых знаний. Попробуй обяснить, к примеру, что такое memset человеку не представляющему как устроена память компьютера или незнакомому с адресной арифметикой. Отсюда и рождаются вопросы почему memset(intArray, 1, len) заполняет массив разной фигней, а не ожидаемой еденицей. Хм — скажет умудренный сишник — так тут все просто... Ан не просто. Не просто объяснить это простое если нет понимания работы с памятью и того что такое типы данных. У тебя именно этот случай. Ты не знашь как работает фрэймворк, зачем он так работает и т.п. но хочешь глубоких ответов.
К тому же из твоих вопросов не следует, что требуются глубокие ответы. Из низ видно что ты привык к другому миру и не понимашь почему так как ты привык нельзя. А между тем я не могу объяснить тебе что memmset в строготипизированном языке — это олный маразм, так как он нарушает ту самую строую типизацию. А ты про это даже думать не хочешь.
VD>>Честно говоря мне кажется (будем надеяться, то именно кажется), что программы по C# у вас не выйдет. Ну, нельзя научить других не желая учиться самому. У вас получится антипрограмма.
PD>Зря кажется.
Казатьс не может зря или с пользой. Это ощущение. Оно или есть, или его нет.
PD> Пока, впрочем, ни о какой реальной программе речи не идет, это все изучение предмета, не более.
Тогда может быть начать с качесвенной книги? Если ты привык разбираться во всем глубоко и основательно то читай Рихтера. Думаю, твои познания ВыньАПИ тоже с него начались. А потом были уже Русиновичи и т.п. То же самое в дотнете. Сначала Рихтер (благо как вызвать функцию и условие написать ты уже знашь). Потом можно Лидина почитать. А там глядишь и вопросов у тебя не останется. Пару тесто сделашь и снами результаты обсудишь.
PD> Но если доведется — все выйдет. Как выходило и раньше — с Алгола на Фортран, с Фортрана на ПЛ/1, с него — на Паскаль, потом на C, потом на C++. Да еще и Basic тут мимоходом въезжал .
Думаю, что реальными знаковыми переходами были C => C++, так как появилась ОО-парадигма, ну, и может ее Васик (как не странно), если это ВизуалВасик, так как в нем можно было освоить концепцию компонентного программирования. Другие языки отличались в основном синтаксисом и паттернами. Так вот дотент это еще один рубеж.
Поверь я как и ты гнался за скоростью создавая программы на С, а затем на С++. Но прогрессом в своем развитии скорее могу назвать не более быстрый код, а увеличение его понятности. Моя первая программа на С была написана что называется в столбик. Там функций то как таковых небыло. Был Мэйн с огромным свитчем и куча прямолинейного кода. А между тем это была ризидентная программка позволяющая просматривать гипертекстовые справочкники неограниченного размера. Весила она 25 кил, что на диске, что в памяти. По сравнению с моим тогдашним конкурентом — Нотрон Гайдом нанимавшим в памяти что-то около 70 кил это было круто. А ведь Нортон использовал ассемблер.
Последняя моя программа — Rsdn.Eritor — тоже требует производительности. Но задачи уже другие. Мне нужно, чтобы затраты памяти и скорость не напрягала людей на современном среденем компьютере где запускается дотнет. И я этого добился. Но добился не оптимизациями на каждом шагу и боязнью сделать что-то медленно, а здравым рассчетом и тестированием. Кроме того я добился того, что изменения в этот код вносить намного проще чем в код анменеджед аналогов.
PD> Я вполне понимаю, что в чужой монастырь со своим уставом не ходят, и доведется жить в этом монастыре — постараюсь по его уставам жить. А пока я этот монастырь имею возможность в качестве туриста наблюдать — почему бы мне и не сравнить его нравы с нравами в близлежащем городе и не поинтересоваться, нельяз ли все же в этом монастыре иногда кино показывать — триллеры или эротику . Естественно, у монахов это вызывает самый праведный гнев
Любишь аналогии? ОК. Сравнить моностыри можно. Но сравнить их напрямую можно только если это моностыри одной концесси. Если же ты попыташся сравнить моностырь буддийский с православным, то получится глупость и флэйм. Но можно сравнить их на более общем уровне. Мол подходы к воспитанию паствы, принципы самообеспечения. При этом нужно понималь, что буддисты, например, едят палочками не потому что у них религия не позволяет, а в следствии традиций и т.п.
Хотя конечно аналогии это лукавство.
VD>>Не исповедуются в ней никакие прицыпы эффективности. В ней принципы надежности и простоты исповедуются. А ты все ищеш эффективность.
PD>Вот именно. Об этом я собираюсь здесь отдельное сообщение написать, так что подожди его выхода, а потом набрасывайся со всем темпераментом
Прежде чем что-то писать лучше разберись в вопросе.
>>Нахрена же детей калеками делать?! Ведь преподование дотнета отталкиваясь от эффективности ты именно маральных уродов из них и сделашь!
PD>Хорошее заявление! Походе даже на манифест .Net. Обязательно его использую.
Где?
PD>Влад, не стучись в открытую дверь. Если бы даже мне пришлось C# преподавать — у меня хватит ума сначала их обычному программированию (как здесь принято) учить, в потом про Interop и т.д. рассказывать.
ОК. А то я уже испугался, что ты именно курс готовишь и с таким настроем хочешь детей учить. Тогда все роще и споконее.
VD>>Нифига ты не знашь. Все зависит от тонны факторов. Только на конкретной платформе, с кокретным компилятором и конкретным процессором ты можешь что-то сказать уверенно. PD>И то для этого нужен конкретный опыт.
Именно. И именно по этому я еще раз повторяю, что вопрос эффективного программирования на дотнете это не простой вопрос. Дотнет тем и хорош, что не поднимая его можно писать вполне себе эффективные программы. Поверь, что кодтетный джит порождает дейсвтительно неплохой машинный код, а значит большинство операций вроде if-ов, while-ов и т.п. окажутся такими же как если бы ты их написал на С. Однако есть и более дорогие операции. Но все это в итоге не так страшно и приводит максимум к 20 процентрой разнице. Бывают конечно исключения, но они не так часты. Хотя конечно смотря где. Те же матрицы или вычисления с doudle-ами могут вызвать некоторые проблемы. Но опять таки все это обходится.
И что интересно, оптимизации могут быть даже вредны. Я вот как "страый сишник" все время пытался вынести из проверок циклов доступ к размерам массивов помещая его в переменную. Оаказалось, что я делал ровно обратное задуманному. Оказывается я мешал джиту. Кстати, ты тоже на эти грабли наступил. Просто проверки границ массиво в твоем случае дали бы 1 секунду, что на 4 минутах (да и на 17 секундах) просто нельзя заметить.
PD>Естественно. Но с другими процессорами я уже 15 лет дела не имею, а для Unix не программирую.
Ну, вот представь себе что ты попал за другой процессор. Причем не за новое поколение, а за совершенно другую архитектуру. В нем есть куча потойных место о которых ты не знашь, но которые влияют на производительность. Но процессор спроектирован так, что если ты просто не будешь оптимизировать, то получишь довольно неплохой результат. Что-то типа того, что процессор принципильно был рассчитан на оптимизации действий лаботрясов.
PD>Уже угадал — с матрицами. Открою секрет — я таких именно результатов и ждал.
Хм... Каких? Твой тест чуть-чуть подправленый (без устранения основной проблемы — поперечного прохода по подмассивам) у меня на машине показывает 16 секунд против 13 для С++-варианта. Неужели это такая огромная разница? А ведь изменелись как раз только процессор и фрэймворк. Программа то та же.
С большой долей вероятности можно сказать, что дело в кэше процессора. Пока перебор идет в кэше скорость очень высокая. Как только размер подмассива вылетает за пределы кэша, то при каждом поперечном проходе происходит сброс кэша и если процессор у тебя Интеловски да еще и Целерон, то ты получишь охриненный тормоз. Ну, а разница с С++-ным объясняется тем, что дотет тратит дополнительное место для каждого объекта (примерно по 8 байт на объект). Так что твой тест где-то вылетил за кэш и пошли тормоза, а на С++ не вылитил. В общем, совпадение. Ну, а разница между 16 и 13 — это как раз проверка выхода за границу и другие дотнетные проблемы. Рано или поздно их устранят и разницы вообще не будет. А твоя программа останется прежней. Мой же процессор обладает мегабайтным кэшем и твоея матрица полностью в него входит в обоих случаях.
Зато ты получашь нажедность. Попробуй внеси ошибку в код и выйди за еределы массива в С++ и в шарпе. В С++ с огромной вероятностью ты получишь неверный результат и никакой диагностики. В шарпе же ты получишь исключение. Стоят ли эти 23 процента надежности? Если ответ да, то просто забей на это отстование. Если ответ — нет то используй ансэйф или интероп.
VD>>Нельзя. Вернее катигорически не нужно. Причем просто потому, что твоя погоня за мнимой эффективностью кода, ты выплескиваешь ребенка. Ты пыташся программировать на безопастном и простом языке сложно и глупо.
PD>Не спешите с выводами, маэстро . Во-первых, почему мнимой?
Потому что рельных проблем с ней у тебя нет. Ты поглядел результаты одного теста и увидил проблему. Далее сделал выводы по поводу всего дотнета на базе этого случая. А ты сделай тесты на плоском массиве (который и применяется в 99% случаев в программах). Увидишь, что разницы то почти и нет.
PD> Твои и других модификации моего матричного теста дают оптимизацию в 15 раз — это не мнимо!
Да нет никаких 15 раз. Это в твоих конкретных условиях получилось 15 раз. А в моих 23 процента. И эту разницу можно свести чуть ли не отрицатльной. Представь, что мы пишим аналогичные программы с данным вычислением. Оба лохи и выбрали самый не эффективный способ описанный тобой. Да, твоя программа окажется быстрее моей, но все равно она окажется медленее чем магла бы быть. Предположим так же что алгоритм используется в некотором пакетном процессе протекающем несклько минут и в котором алгоримт вызывается несколько раз (предположим 10). У тебя получится твоей алгоритм занимает на твоей машие 30 секунд, а на той что будет выполнять его в шатном режиме 20. Мой 160, но на конечной машине 3 минуты. Стало быть твоея программа будет работать 3.3 минуты, а моя 30 минут.
Что будет дальше? А вот что. Ты в силу того, что убил больше времени на отладку, доводку и программирование, а так же так как под рукой просто нет профайлера, а скорости более мнее как хватет забьеш на оптимизации. А мне скажут — не милок, 30 минут это перебор. И что сделаю я? Правильно запущу профайлер который укажем мне на узкое место. Тогда я подумаю, и перепису алгоритм испльзуя прямой проход. В итоге мой алгоритм будет исполняться уже 6 секунд на конечной машине. Это конечно на секудну медленее чем потенциальны С++-ный вариант, но! Но это в итге даст 1 митуту! И в итоге окажется, что реальное управляемое приложение в трое быстрее аналогичного неуправляемого.
Что? Не честно? Но какое дело пользователю до честности? Ведь у тебя просто нет времени на оптимизацию, а я его точно заполучу.
Вовод? Эффективность программиста очедь даже способна превратиться в эффективность конечного приложения.
Да, конечно, бывают случаи когда и на С/С++ выжимаются последние соки из приложения. Тогда конечно на С++ можно ожидать тех самых 20% производительности и иногда это может оказаться очень важно. Но!!! Но это очень частный случай встречающийся очень редко! Так зачем ломать копья.
PD> А во-вторых, почему это сложно ? Я пока что вроде не показывал никакого кода, где я пытался бы сделать что-то сложно... PD>Ну а насчет глупо — оставляю на твоей совести.
Сложно и глупо программировать заморачиваясь на каждом операторе думая не станет ли он узким местом. К сложности твоего кода это отношение не имеет. Хорошо что ты угадал с матрицами. Но я почти уверен, что первый твой тест был на простых массивах и "о чудо особой разницы нет".
PD>Вот тут-то собака порылась. Допустим, я никакого C++ не знаю, а сразу на C# начинаю. И вот вижу я это жуткое время перемножения матриц. А почем мне знать, что оно жуткое ? Может, оно нормальное ?
От. Правильная постановка вороса. А ответ таков — и не надо знать. Когда ты перейдешь из стадии учеников в стадию разработчиков, и когда твоя программа будет работать медленно, то ты поглядишь что приводит к этому результату и примешь верное решение нужно ли язык менять или обойтись изменением алгоритма. К тому времени ты за одно и опытк кое-какой приобретешь, так что будет проще выбрать правильное решение. К тому же с конеретной проблемой можно вылезти в форум (сделав тест, чтобы другие могли поглядеть), а там глядишь более опытные товарищи помогут.
Точно так же я писал на С и боялся, что не дай бог "вот это" затормозит мою программку. И только потом, когда я оптимизировал по скорости не одну программу я понял что бы не прав. Знания узких мест полезноно, но боязнь опасна. Так что если знаний нет, то лучше просто забить на все страхи и писатьк как получится.
PD>Или тот же GetFiles.
Я устал тебе повторять, что нет тут никаких проблем с производительностью. А память... 2 мега тебя не спасут. 56 же это от выбора неверной функции и от шибко большого объема оперативки на машие.
PD> Да не знаю я никакого Win32, мне и в голову не приходит, что можно иначе!
А нужно иначе? Опять же если это будет главное место где идет перерасход памяти, то профайлер тебе это покажет. А по скорости... см. выше.
PD> А пишется все так просто и элегантно,
Вот! Вот это и есть главное. Я думал, ты этого не заметил.
Значит согласен, что просто и элегантно? Тогда сделай тесты и пойми, что существенной разницы в скорости эти твои 56 метров не дают. И даже АПИ-шный вариант будет осуществлять полный перебор так же медленно. Так что ты пишишь быстро быстрый код жертвуя при этом в основном памятью. Что тебе дороже память или свое время? Хороший программист стоит от 1000 баксов в месяц (в Москве), а память несколько сотен за гиг. Я еще пойму если речь идет о продукте выпускающемся огромными тиражами и стоящем копейки, но большинство задач то как раз малотиражные и дорогие. Так что память для них не ресурс.
Ну, и опять же ты волен исползовать то же ВыньАПИ и получать практически такие же решения. Только еще ко всему прочему в твоем распоряжении отличный механизм позволяющий очень легко скрыть корявость АПИ за красивым фасадом. Это конечно можно сделать и на С++, но делать это несколько сложнее.
?
PD> и на каталоге в 100 файлов работает так хорошо, прямо замечательно. Все, оттестировали этот блок, поехали дальше. Потом я сам при окончательном тестировании запускаю все это для каталога в 100,000 файлов и привет
Что привет? 100 тысяч файлов это вообще случай экстра-ординарный. На такой каталог ни из одного файлового менеджера нормально посмотреть нельзя. Да и опять же повторюсь. Скорость перебора будет та же. Только расход памяти больше. И на строках это будет не так уж и много. Мег 10. Учитывая же, что никто не запрещал использовать АПИ напямую или (что разумнее) написать собственный варпер, то вообще не ясно о чем речь идет?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, конечно. Ну почему вы (дотнетчики) такие — как что покритикуешь, или даже усомнишься — сразу наезды ? Почему API-шники никаких наездов на себя не замечают ?
А кто это такие. Я вот могу даже поспорить, что знаю АПИ не хуже тебя.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — мой вопрос не в этом. Я не могу принять идею делать что бы то ни было с большими затратами ресурсов, чем надо. Неважно, 1000 там строк будет или 100000, если нужна одна. Вот с этим я не согласен в принципе. Почему — объясню потом, когда напишу сюда то, что собираюсь написать. Так что уж подожди немного
Не не можешь принять, что библиотеки пишутся под конкретный паттерн использования. Когда создавали дотнетные библиотеки посчитали, что:
1. В основном файлы в катлоге перебираются всегда все.
2. Список строк занимает не много места, так что если кому нужно он воспользуется строковым вариантом.
3. Количество файлов будет не так уж велико.
4. Хэндл перебора нужно закрывать, так что проще скинуть список в массив.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пишу с другого компьютера, под рукой DevStudio нет. Так что по памяти...
PD>DirectoryInfo di = new DirectoryInfo("путь"); PD>FileInfo[] fi = di.GetFiles();
PD>в каталоге "путь" 100,000 файлов.
Ну, и что мешает тебе заменить DirectoryInfo на Directory? По памяти сразу станет значительно легче.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Но массовый-то софт с компиляцией в байт-код начали писать именно на Java и C#.
Скорее на VB, а то и на Клипере, Кларионе и т.п.
А нового в Яве (опять же для массовых сед) было скорее не байт-код, а наличие виртуальной машины, которая включает и байткод, и защиту, и библиотеки, и рантайм-сервисы и много чего еше. В общем, новая была идея создать виртуальную ОС. Кроме того важным архитектурным решением в Яве и дотнете была ориентация на компонентный подход. Хотя он опять таки появился не в этих средах, а скорее в тех же васике и клариане (и в Дельфи конечно), но все равно важный шаг.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но в одном уверен. Если что-то революционное появится — вряд ли это мы предскажем здесь. Если, конечно, не считать революцией такие события, как введение в С++ темплейтов или появление байт-кода. На мой взгляд — на революцию не тянет все это. Точно так же, как серьезной революции я не вижу в переходе от Эниака к Пентиуму 4. Чистая эволюция. Вот если наконец появятся машины нефон-Неймановской архитектуры, тогда это будет революцией.
Ты с функциональными языками знаком?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
D>int sum = 0; // Какого фига я должен думать о том где храню результат?
D>for (int i = 0; i < array.length; i++) { // Переведи на русский и прочитай вслух :) "Для скобка цел и равно..." :)))
D> sum += array[i]; // Ну вот это собственно я и думал :)
D>} // Это тоже надо подумать...
D>
Массив всавил двоеточие ноль в двоеточие квадратная...
А на яве тоже ведь можно абстракции вводить. Тогда и на нае все не так страшно:
int sum = Sum(array);
...
static int Sum(int[] array)
{
int sum = 0;
for (int elem: array)
sum += elem;
return sum;
}
Так что не все так страшно когда к делу с умом подходишь.
D>ML: (за синтакцическую корректность не отвечаю, но только в деталях) D>fun sum(head::tail) = head + sum(tail) | sum([]) = 0.
B на яве можно писать рекурсивно:
static int Sum(Node list)
{
if (list.getNext() == null)
return 0;
return list.getValue() + Sum(list.getNext());
}
Вот толко одно "но". На Яве работа шла с массивом, а на МЛ-е со списком. Со списоком и на Яве будет короче. Но массив эффективнее.
D>Вариант от Smalltalk и ML это два разных способа мышления, а Java/C это сплошное спотыкание мысли и куча мусора.
Вообще-то в Смолтоке МЛ-е тоже мусора хоть отбавляй. А что касаемо образа мышления, то если рекурсию МЛ-я я легко понимаю, то Смолток мне кажется чистейшим нагромождением. Может ты к нему привык, но я нет. Мне даже ява ближе.
ЗЫ
А вот так это будет выглядеть на C# 3.0:
int[] array = { 1, 2, 3, 4, 5, 6 };
var sum = array.Sum();
Понятнее некуда.
Или "вариации на тему":
var sum = array.Fold((fold, second) => fold + second);
Ну, и самое простое... C# 1.0:
int sum = 0;
foreach (int elem in array)
sum += elem;
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Так я тебе про то и говорю, что есть сдвиг серьезная смена мышления при переходе от процедурного программирования к объектно-ориентированному (с Паскаля или C на C++ или Java). Переключение с C++/Java на Smalltalk/Ruby -- это тоже небольшая смена. Но не большая, т.к. понятия там все равно объектнно-ориентированные. Причем в случае с Ruby такой переход вообще очень плавно происходит, т.к. Ruby позволяет программировать в чисто императивном стиле.
E>А вот вся тема строится вокруг того, может ли появится такой язык, который бы потребовал такой же смены мышления, как переход с C на C++ или с Паскаля на Smalltalk? И если такой язык появится, то инструментарий существующих языков будет не столь важен.
Похоже дискуссия зашла в тупик...
Давай сначала разберемся, что стоит называть языком. Мне кажется, что тут есть серьезное расхождение во взгялах.
Когда-то все начиналось с синтаксиса и компилятора. Но сейчас дисскусия совсем не об этом.
Ты, например, говоришь об ОО, но это не языковое понятие. ОО решения можно запрограммировать и на плоском C и даже на asm. Другое дело, что C++, Java и т.п. поддерживают такой стиль программирования.
Когда-то структурное программирование применялось посвеместно, и, например, на C прогу писали как куча вызывающих друг-друга функций. Были "академические идеи" про ОО. И вот сделали язык (С++), совмесимый с существующим миром, но при этом упрощающий ОО подход. На нем все еще можно было писать прогу как кучу функций, но можно было писать и как кучу объектов. И со временем объектные решения стали нормой.
Возвращаемся к нашей дискусси. Есть две идеи:
1. Программа состоит из объектов, обменивающихся сообщениями — ОО. При написание программы ее стоит проектировать в терминах ОО.
2. Есть инструмент позволяющий менять дизайн, без изменения функциональности — refactoring. При написании программы стоит опираться на постоянный рефакторинг.
Почему ты первую идею считаешь относящейся к теме, а вторую нет? Может ты думаешь, что идея рефакторинга это меньший сдвиг мозгов?
Вход рефакторингов в массы сейчас очень похоже на появлении ОО 20 лет назад. Можно продолжать писать как раньше используюя действия типа extract method/varaible как средство написать метод/определить переменную за меньшее число нажатий на кнопки. А можно по другому смотреть на процесс проектирования. Не делать архитектуру, а потом ее кодить и на ее базе делать фичи. А начинаешь делать фичи (тут проектировать приходится, но локально), потом смотришь, что получилось и на какую архитектуру это похоже и какая тебе удобна, что бы сделать слудующую фичу.
Естественно так можно было делать всегда, но без инструментов... это было тяжело и ненадежно, т.е. не эффективно.
E>Абсолютно не значит. Но если кто-то программирует на Java в Idea или Eclipse он все равно будет вынужден строить практически такую же объектную модель, что и я на C++ в VIM. Т.к. модель строится не в редакторе/IDE, а в голове.
E>Более того, в VIM на той же Java я смогу сделать такое же решение, как ты в Idea. Может быть это будет медленнее. В первый раз. Но вот качество решения вряд ли будет различаться у кода, набранного в Far или VIM, и у кода из Eclipse/Idea. Потому что редакторы имеют к качеству кода очень посредственное отношение.
Дело не в том как построить такую же объектную модель, а в том как ты будешь строить модель. И если строит ее подругому, то и получится другая модель.
Аналог из "процедуры vs ОО": какая разница как писать функцию как метод какого-то объекта или как это делали всегда. Да конечно, это немного быстрее — один параметр передается неявно и его не надо писать. Но качество у кода, записанного с классами и без, врядли будет отличаться Похоже?
И, соответственно, мой ответ в свете той же аналогии: Если думать объектами то получатся другие функции (записанные как методы классов).
VladD2 wrote:
> C>Я предпочитаю поставить Miranda и Appolo, которые в сумме меньше 15 > C>мегабайт. > 15 мег на бизделушки?
Если в Appolo порезать буффер, то получается 5Мб
> Да как ты их терпишь. Я уверен, что те кто тебе наставили плюсов еще > помнят времена когда у них на компах крутились резидентные программки > делающие похожие вещи и жрали эти программки по 15 гилобайт.
Да, хорошие были времена....
> Может просто нужно понять, что память стоит копийки и лучше иметь > более полезну, программу чем сэкономив память возиться с менее > удобной? Я вот просто купил себе гиг пмяти и уже почти год как мне > проблемы памяти побарабану.
У меня тоже гигабайт, но мне ее жалко. Пусть лучше больше памяти в кэш
диска уйдет.
Здравствуйте, Dyoma, Вы писали:
D>Возвращаемся к нашей дискусси. Есть две идеи: D>1. Программа состоит из объектов, обменивающихся сообщениями — ОО. При написание программы ее стоит проектировать в терминах ОО. D>2. Есть инструмент позволяющий менять дизайн, без изменения функциональности — refactoring. При написании программы стоит опираться на постоянный рефакторинг. D>Почему ты первую идею считаешь относящейся к теме, а вторую нет? Может ты думаешь, что идея рефакторинга это меньший сдвиг мозгов?
Потому что первая идея -- это проектирование (суть изобретательство), вторая -- это реализация (суть технология). Ты же сам назвал это "инструментом".
Инструмент способен существенно поднять производительность труда, но не изменить ход мысли. Киркой и лопатой ты будешь прокладывать метро под рекой 100 лет. С помощью отбойных молотков -- 25. С помощью специальных комбайнов -- 5 лет. Но ты будешь прокладывать тонель метро. Ни один из этих инструментов не подтолкнет тебя к идее сделать над рекой железнодорожный мост, на который будут выходить пути метро.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Я позволил себе собрать твои высказывания, которые, как мне кажется, относятся к одному и тому же.
D>Когда-то все начиналось с синтаксиса и компилятора. Но сейчас дисскусия совсем не об этом. D>Ты, например, говоришь об ОО, но это не языковое понятие. ОО решения можно запрограммировать и на плоском C и даже на asm. Другое дело, что C++, Java и т.п. поддерживают такой стиль программирования. D>Когда-то структурное программирование применялось посвеместно, и, например, на C прогу писали как куча вызывающих друг-друга функций. Были "академические идеи" про ОО. И вот сделали язык (С++), совмесимый с существующим миром, но при этом упрощающий ОО подход. На нем все еще можно было писать прогу как кучу функций, но можно было писать и как кучу объектов. И со временем объектные решения стали нормой.
Идея о том, что ООП возможно на не ООП языках -- в большей степени академическая, чем практическая. И подкреплена она всего лишь несколькими успешными реализациями, которые, как исключения, всего лишь подтверждают основное правило (например, что-то похожее на ООП используется в реализации OpenSSL). Можно попробовать объявлять в процедурных языках структуры с указателями на методы, заменять их отдельные поля для поддержки полиморфизма и пр. В конце-концов, первые C++ компиляторы Cfront так и делали -- перегоняли C++-ный код в чистый C. Но это эмуляция ООП, т.к. программист начинает сам заботиться о поддержке ООП, в то время как парадигма подразумевает, что используемые тобой средства дают тебе возможность о таких вещах не думать.
На счет того, что к моменту появления C++ витали "академические идеи" про ООП. К моменту выхода первого коммерческого компилятора двадцать лет назад, уже были чисто ОО языки, прекрасно зарекомендававшие себя. Тот же Smalltalk, к примеру (ведь и сейчас, скажем, Smalltalk или Oberon нельзя считать академическими языками, т.к. это практические языки, только с очень малой распространенностью). И, имхо, C++ отнюдь не упрощает ООП. Прорыв C++ был в том, что он принес ООП в C-шный мир. И упростил написание программ, которые до этого делались на C. Т.е. C++ стал успешным мостом между процедурным и объектным подходом. (Здесь наши мнения сходятся довольно близко.)
Так вот, имхо, Java/C# стали всего лишь дальнейшей эволюцией C++ времен 1990-1992 годов, а то и еще более раннего периода. По крайней мере отсутствие шаблонов в первых версиях Java/C# говорит о том, что следующая важная стадия в развитии C++ была авторами этих языков упущена. Но вернемся к Java/C#. Эти языки сделали программирование в стиле C++ более простым, логичным и безопасным. Избавившись в конце-концов от совместимости с языком C удалось сделать более строгий синтаксис, что привело к упрощению синтаксического и семантического анализа кода на Java/C#. А это уже сделало возможным создание современных продвинутых IDE с навороченным рефакторингом. А отказ от принципа "ты платишь только за то, что используешь" позволил сохранять в программе массу дополнительной метаинформации. Что сделало возможным такие вещи, как рефлекшен. А использование байт-кода и виртуальной машины в Java позволило применять такие механизмы, как динамическая загрузка кода и интанцирование объектов по имени класса. Как и C++ в свое время, Java/C# стали мостом между С++ и другими языками (тем же Smalltalk и Oberon).
Но почему же лично я не считаю, что Java/C# совершили прорыв в смене сознания, как это сделал в свое время C++? Да потому, что C++ позволил массе реальных C-программистов применять ООП на практике. Java/C# не сделали этого, потому, что ООП уже не нужно было продвигать в массы. Все, что они сделали -- это создали новую, более эффективную (хотя это не бесспорно) технологию разработки ОО программ в духе C++. Но дальше они не пошли. Ведь что мы имеем в C++: статическая типизация; иерархия классов; объекты, которые не могут изменить свой тип (класс) в процессе жизни; передача сообщений между объектов в виде синхронного вызова методов. То же самое происходит в Java/C# с некоторыми изменениями/дополнениями (вложенные и анонимные классы в Java или делегаты в C#). Но здесь нет смены парадигмы. Понятно, что сменились некоторые приемы, где-то используется рефлекшен вместо шаблонов, где-то делегаты вместо указателей на методы. Но это не принципиально. Принципиальными изменениями, например, могли бы стать:
— асинхронная доставка сообщений;
— изменение иерархии классов по ходу работы программы;
— изменение типа (класса) объекта по ходу работы программы;
— поддержка одновременно динамической и статической типизации (причем первый шаг к этому в C# уже планируется в виде ключевого слова var (Краткий пересказ
Если же я попробую сказать, что бы я считал прорывом в области языков программирования, то это было бы что-то в роде: язык, который сделал бы возможным широкое использование одной или нескольких существующих сейчас и успешно зарекомендовавших себя идей, для которых пока нет технологий.
). Но он не смог стать популярным. Тому есть множество причин. Скажем, для меня способ написания программы в виде S-выражений не удобен (ни для написания, ни для чтения), хотя Лисп-программисты утверждают, что это не проблема. Тем не менее, факт остается фактом. Лисп показал себя не пригодным для широкого применения. А это значит, что огромная масса программистов, которые не знают Лиспа, даже не представляют себе, как же может выглядеть из приложение, написанное на нескольких DSL-ях (по своему DSL на каждом уровне абстракции). А теперь вообрази, что им дают в распоряжение такой язык и показывают, как это просто. Язык, который поддерживает DSL так же легко и естественно, как ОО-языки ООП. Вот лично ты готов сейчас представить свой текущий проект в виде всего лишь нескольких строчек на DSL верхнего уровня? Каждая из которых раскрывается в несколько строчек на DSL еще более низкого уровня, а те, в свою очередь, точно так же. И так до тех пор, пока дело не дойдет до обычного универсального языка программирования?
Готов? Лично я не готов.
Тем не менее, сейчас я сталкиваюсь с подобными вещами, когда программирую на Ruby. Например, моя система управления компиляцией C++ проектов Mxx_ru, проекты в ней -- это не что иное, как программы на DSL. Или вот такая поделка: Re: Использование метаданных в программах на языке C++
Пока все это совсем не большие проекты. Поэтому я и не знаю, как же подобный подход будет масштабироваться на разработки, которые сейчас имеют объем в сотни тысяч строк C++, состоящие из множества уровней абстракции. Но в то, что это возможно, я верю. И думаю, что для этого смена мышления таки потребуется. Вот взгляни на возглас VladD2: Re[6]: Следующий язык программирования
. Тем не менее, то, что Владу кажется ужасом и дикостью на самом деле очень интересная и полезная фишка (при разумном использовании, естественно). И уж если Влад гордится тем, что вовремя сумел перейти на более прогрессивный C#, то кто знает, может и подобные идеи через какое-то время будут для него обыденностью.
Теперь, вернемся к вопросу о соотношении языков и инструментов. Представь себе, что появился язык для удобного создания DSL-ей. Будут ли современные примочки типа unit-тестинга или рефакторинга востребованны в таком языке? Да безусловно. Но и они выйдут на совсем другой уровень. Представь себе unit-тестинг для семантической полноты DSL. Т.е. сейчас мы легко представляем себе unit-тест для проверки setter-ов/getter-ов. А unit-тест, который проверяет корректность одного предложения DSL (за которым может скрываться функциональность в миллионы строк C++ кода)? Или сейчас мы прекрасно представляем себе рефакторинг, который заменяет название у метода класса (с соответствующим изменением его вызова по всему проекту). А аналогичный рефакторинг для части DSL? Например, замена SQL-выражения SELECT на что-то похожее, по смыслу, но другое по написанию?
А теперь вдумайся: миллионы программистов по всему миру начинают считать нормой DSL-парадигму, а ООП рассматривают как ассемблер, к которому в конце-концов их компилятор транслирует их программы (как Cfront с C++ текстами). Вот это я и называю сменой мышления. И языки, которые поддерживают DSL-парадигму я бы назвал "следующими языками программирования".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Один и тот же блок, но в зависимости от того, в каком контексте он выполняется (определяется методом instance_eval) он вызывает разные методы:
VD>Ужас! За такое нужно руки отрывать!
VD>Зачем вообще подменять полиморфизм такими контекстными зависимостями? Это же можно совершенно случайно вносить ошибки в классах потомках.
Имхо, это не полиморфизм. И не попытка заменить полиморфизм чем-то другим. Это просто одна из возможностей языка, которая упрощает создание DSL на этом языке.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, henson, Вы писали:
VD>>А есть вечно недовольные окружающим люди. И что им недовай они все ворчат. H>Не надо грубить!
Где же я грублю?
H> Тема топика про следующий язык программирования. Тут надо смотреть вперед хотя бы лет на 5-10. Если Вас все устраивает в C#+.NET, то новый язык Вам не нужен.
Да как сказать... Меня устраивает многое из C#, но кое чего хотелось бы. Так же как мне нравится кое-что из других языков, но мное и не нравится.
H>Мне же нужен язык, который бы не просто позволял сделать окно и написать в нем "Hello, world!", а грамотно построить (design&build) приложение снижая вероятность ошибок и не требуя суперспециалистов в качестве исполнителей:
Вот тут как раз C# очень даже выгодно выглядит. Хотя любой типобезопастный язык создатели которого стремились облегчить создание приложений тоже интересен.
H>1. ...
H>2. ...
H>3. ...
все это уже можно делать существующими технологиями. Ты мечташь о том, что давно есть.
H>На каждом из трех этапов я хочу иметь возможность использовать CVS.
И в чем проблема?
H>Поддержка программирования как комплексного процесса, а не как набора слабо связанных процессов с достаточно сложной интеграцией, и даст нам новый язык программирования/проектирования приложений.
Язык? Нда... Ты описал IDE. Та же VS все это позволяет делать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
VD>>Думаю что на 100% нельзя. Все равно ведь привязка к координатам остается в некоторых местах. Хотя это зависит от интерпретации терминов. ZEN>Где, интересно? В последних версиях Delphi внедрено свойство для виджетов, позволяющее плавно масштабировать форму и все её элементы при изменении её размеров. Пока что это выглядит удручающе. Наверняка это — влияние принятых парадигм, которые затронуты по ссылке выше.
Это из серии "Спортэ мужчины"? Твои же слова модтверждают мои.
ZEN>Раз уж дискуссия в этом направлении организовалась между нами тремя, то почему бы не объединить мнения в одном посте?
Потому что путанница возникает. Я и так не пойму с кем ты споришь.
VD>>Кому вопрос задашь? ZEN>Всем.
Не просто это понять.
VD>>Ты форум в плоскую читашь, что ли? ZEN>Плоско. Ибо лазить по дереву для меня неудобно.
Ну, так подразумевай что другие читают дерево и им что лучше отвечать конкретно тому с кем не согласен или наоборот согласен. А то ведь путанница начианается.
ZEN>"Текстовые" системы хранения версий не могут понять различия между программными строками, если в них вставлены "оформительские символы" пробел/перевод строки/табуляция, хотя синтаксические конструкции могут быть абсолютно эквивалентными.
Пробельные символы нормальные диферы легко игнорируют. Не придумывай. А серьезное переформатирование кода происходит не часто. Я лично серьезных проблем не встречал в этом плане. Так что может тебе нужно задуматься над сменой дифера.
ZEN>Нужно идти по пути синтаксического анализа и сравнения исходников, совершенствования систем на этой основе.
Это тоже возможно. Берешь продукт вроде R#-а и вперед делать синтаксически дифер. Вот только такой дифер будет иметь проблемы с коментариями и т.п. Но сравнивать из-за этого объекты и темболее отказыватся от хранения кода в текстовых файлах смысла нет.
VD>>Чесно говоря завязку на переменные окружения считают не очень удобной... Да и говорил я о другом. Говорил я о ссылках на другие сборки в проектах. ZEN>Типа: import, using и т.д.? Но это же тавтология.
Нет не import/using, а ссылка на сборки. В дотнете все немного подругому. Тут уж тебе прийдется матчасть подучить, чтобы понять.
ZEN>Повторю идею, к которой мы стремимся. ZEN>Одинаково код должен выглядеть только для системы контроля версий. На местах разработчиков код должен выглядеть так, как удобно читать и анализировать конкретному человеку (ещё раз: это решается горячей клавишей или предустановками среды конкретного разработчика).
Мне кажется амбиции одного программиста нужно просто засунуть по дальше и не вынимать. Тогда и проблем с форматированием не будет.
Ведь кроме отступов и переносвов строк еще есть предпочтения по написанию коментариев, по разнесению типов по файлам (Ява этот процесс больше контролирует, но тем не мее дела это не меняет), по именованию переменных (или их тоже переименовывать под "клиента"?) и т.п. Так что проще выполнять требования форматирования.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Имхо, это не полиморфизм. И не попытка заменить полиморфизм чем-то другим. Это просто одна из возможностей языка, которая упрощает создание DSL на этом языке.
Незнаю, по мне так это уродливый полиморфизм приводящий к тому, что язык становится принципиально интерпретируемым.
Задачи построения ДСЛ и т.п. можно было бы решать и без таких жертв и непонятностей.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ты зря разделил мой ответ на две части. Это была одна мысль о том что ОО и рефакторин в некотором смысле идеи одного типа.
ОО предлагает поменять проектирование вводя свои понятия, а перейдя от проектирования к реализации предлагает средства эти понятия записать. И хотя некоторые языки поддерживают упрощенную запись понятий ОО, объекты — это способ думать о задаче. Например, можно взять C++ и имеющуюся поддержку ОО, использовать как поддержку функционального программирования, примеры можно посмотреть в stl, вроде хедер algorithm называется. C++ назвали "объектно ориентированный", а не "функционально ориентированный" язык потому что его авторы думали об объектах, а не потому что его нельзя применить по другому.
Рефакоринг предлагает изменить взгляд на баланс между проетированием и реализацией. Некоторые языки поддерживают автоматизацию рефакторингов.
С++ предлагает девелоперу думать о задаче объектами, а java + Idea/Eclipse (или C# + resharper/VS2005) предлагают девелоперу думать рефакторингами. Тут я еще раз хочу обратить внимание на то, что "думать рефакторингами" — решение не тактическое, а стратегическое. Оно предполагает изменить весь процесс разрабтки, строить архитектуру приложения не до реализации, а во время и после, опираясь на уже реализованное, на опыт полученный во время написания кода и на требования в насчтоящий момент времени.
И конечно же рефакторинги могут быть использованы по другому, как собственно, я уже писал, C++ можно использовать как струкурный язык или как функциональный.
D>>Возвращаемся к нашей дискусси. Есть две идеи: D>>1. Программа состоит из объектов, обменивающихся сообщениями — ОО. При написание программы ее стоит проектировать в терминах ОО. D>>2. Есть инструмент позволяющий менять дизайн, без изменения функциональности — refactoring. При написании программы стоит опираться на постоянный рефакторинг. D>>Почему ты первую идею считаешь относящейся к теме, а вторую нет? Может ты думаешь, что идея рефакторинга это меньший сдвиг мозгов?
E>Потому что первая идея -- это проектирование (суть изобретательство), вторая -- это реализация (суть технология). Ты же сам назвал это "инструментом".
Лтчно я не перестаю изобретать на любом уровне, и это при том что сейчас в моих руках java. А когда я писал на Smalltalk или C++, возможности изобретать было существенно больше.
E>Инструмент способен существенно поднять производительность труда, но не изменить ход мысли. Киркой и лопатой ты будешь прокладывать метро под рекой 100 лет. С помощью отбойных молотков -- 25. С помощью специальных комбайнов -- 5 лет. Но ты будешь прокладывать тонель метро. Ни один из этих инструментов не подтолкнет тебя к идее сделать над рекой железнодорожный мост, на который будут выходить пути метро.
Есть критическая производительность, которая делает технологию возможной (применимой). Строительство метро стало популярным когда появились "специальные комбайны", ОО — когда появились языки с на которых можно написать класс, а не ручками клепать vtbl. Теперь есть find usages, extract/inline/rename/... variablt/field/method/class/..., это делает возможным технологии ранее не эффеткивые, способы мышления, ранее нерациональные.
VladD2 wrote:
> Класс! "Ромозит... жаль 56 Мбайт". Так тормозит или памяти жаль? У > тебя ее 780 мег как ты сам признался. Ну, 56 мег на пару секунд и что?
Слетит 56Мб кэша диска, в котором лежит много вкусных и полезных файлов.
VladD2 wrote:
> C>Причем наблюдается это, в основном, у современного софта — та же ICQ > без > C>зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20 > C>метров. Вот так и не остается памяти для чего-нибудь полезного.... > Купи памяти или поставь ICQ и WinAmp пяти(и более)летней давности.
Памяти у меня хватает — 1Гб. Винамп до недавнего времени стоял 2001 года
выпуска (заменил на Appolo). Старую ICQ бы тоже поставил, так они
изменяли протокол несколько раз.
> Не кто же тебя не заставляет ставить на машину NT и последние версии > программ. Разработчики влючают в продукты новые возможности. Они жрут > память. Да и вообще если памяти много, то разработчик не обращает > внимание на оптимизацию рассчитывая, на то что на его рынке в среднем > памяти столько-то.
Я вот обращаю внимание. Точнее не внимание, у меня уже инстинкт такой —
экономить память и процессорное время. И пользователям нравится, как ни
странно.
Если перехват не делается из нулевого кольца, как это, например, делает СофтАйс, то перехват возможен исключительно в рамках процесса. Межпроцессные вызовы идут только через ядро или через специальные механизмы которые один фиг в конце концов используют ядро для комуникации.
