Здравствуйте, McSeem2, Вы писали:
MS>Так уж исторически сложилось, что я привык спорить с вменяемыми собеседниками. А риторику я не изучал и в ней не силен. Извини еще раз.
Ну, что достойная позиция в споре — вместо аргументов начать разбираться во вменяемости оппонента. Что и следовало ожидать.
Думаю, ты еще не раз задумаешся над вопросом кто из нас более вменяем.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> V> Это цифры только по восточной Азии (Япония, Корея и пр.)
> Тоже не верю, так как я видил как минимум одну японскую игрушку с более чем двух миллионным тиражом (Хало что ли...). Даже при цене в 2 бакса она уже перекрывает эту цифру.
По-моему, ты путаешь объем продаж одной фирмы в одном регионе с деньгами, вырученными другой фирмой из того же региона, но в результате продаж по всему миру.
> V>Что-то я не улавливаю связи между C#2 и приставками
> Ты много чего не улавливашь.
Фи
> Думаю среди сильных мира сего дело будет развиваться так. Сначала дотнет появится в виде скриптовых движков и дополнительных средств. А со временем вытеснит нэтив код. Случится это по моим прикидкам году эдак к 2010-2015.
В том числе на приставках, где пирог намного лакомее, чем на PC, и где не ю?
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Думаю, ты еще не раз задумаешся над вопросом кто из нас более вменяем.
Ну давай вкурим твою фразу с точки зрения формальной логики. Допустим, что я являюсь невменяемым. Если так, то я никогда не признаю свою невменяемость по причине невменяемости и задумываться об этом не буду. Если же принять допуoщение о твоей невменяемости, то нафига мне об этом "не раз задумываться"?! Если же я все-таки буду "не раз задумываться", то это ставит под сомнение мою собственную вменяемость.
С логикой у тебя точно не лады.
Мне вспомнилась цитата из известного произведения.
- Вы, Шариков, чушь говорите. И возмутительнее всего то, что вы говорите это безапелляционно и уверенно.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
MS>>Иными словами, это ничего не говорит ни в пользу C# ни против него. С формальной логикой у тебя все-таки не лады VD>Здесь обсуждался вопрос неприемлемости использования Шарпа в 3D-играх. По этому поводу какие-нибудь аргументы есть? Или признаем все попытки признать это мнение обычной инсинуацией?
Так и признаем. Притом инсинуациями занимаешься вроде как ты. Исходно речь велась о некоторых проблемах применения .Net и C# для разработки 3D-движков. Ну, ПК по неосторожности упомянул...
Впрочем, мы усвоили десять великих истин форума RSDN/Философия:
1. Если хочешь знать, что .Net — это всегда хорошо, то сначала обратись к RSDN/VladD2, а если этого не хватило, то возьми Janus, да проверь;
2. Если хочешь тестирований производительности для 3D, то возьми Janus, да проверь;
3. Если хочешь убедиться, что на .Net можно написать всё, то снова возьми Janus, да проверь;
4. Если хочешь убедиться, что продукты, разработанные на .Net не имеют проблем, то снова возьми Janus, да проверь;
5. Если хочешь убедиться, что гибкость продуктов, написанных с использованием .Net немерянна, то опять, возьми, балбес, Janus, да проверь;
6. Если хочешь логических доказательств и объяснений, то или обратись в RSDN/Философия, или возьми, наконец, Janus, да проверь;
7. Если хочешь убедиться, что C# "делает" C++ по всем статьям, то, обратно, возьми Janus, да проверь;
8. И вообще — возьми Janus, да проверь, как ты, кретин, ошибаешься;
9. Если ещё не считаешь себя лузером, то сообщи об этом в форуме "Философия", дабы развеять сомнения;
10. Если в чём-то ещё не убеждён до краёв тапочек, то начни с пункта 1. или хотя бы возьми Janus, да проверь.
Слава RSDN/Философии — вечному источнику универсального мнения всех. Кто не с нами, тот сам себе злобный Буратино!
PS. Всё вышесказанное — проявление моей (недостойного!) недостойной (же!) позиции в споре, достойной всяческого порицания.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, prVovik, Вы писали:
VD>>>Ну, проблемы неграмотного кода никто устронять не собирался. Диспоз вообще по идее не должнен генерировать исключений.
VD>>>И уж если ты работаешь с ресурсами в диспозе, то ставь using или try/catch|finally защищающие код. V>>Гы, а что мешает делать то же самое в С++?
VD>Тут вроде бы уже 100 раз это говорили. Теоритически ничего. Практически весь дизайн языка.
Истерика какая-то. Сам же сказал, что что в деструкторах, что в диспозе исключения кидаться не должны. А насчет дизигна языка — а можно конкрено описать, как дизайн языка мешает мне как разраюотчику писать try/catch в деструкторе и не выпускать оттуда исключения?
VD>Ну, давай еще раз по пунктам: VD>1. Повторная генерация исключения в диспозе или вообще не приводит к фатальным проблемам, или приводит обычно к потере одного ресурса, так как остальные диспозы вызываются из любого положения. При этом с огромной долей вероятности потерянный ресурсный объек реализует и финалайзер, так что он будет подобран при первой же сборке мусора. Если он не успел попасть в первое поколение, то это вопрос нескольких десятых долей секунды (максимум секунд). В С++ же повтораное генерирование исключений обычно приводит к вылету всейго приложения. Именно по этому при малейшем сборее мы видим AV-диалоги у большинства приложений окружающих нас сегодня.
Мы их видим не потому, что они на плюсах. Мыих видим потому что руки из задницы у кого-то растут. Языка ваще играет очень тертью роль во многих случаях.
VD>2. Необходимость ручного контроля в С++ не только за ресурсами ОС, но и за любыми динамически занятыми областями памяти. Это приводит или к ловле ликов и попыткам "окуратного" программирования, или к наклепыванию оберток на каждый чих. Четыре года назад наша контора придерживалась второго подхода, но тем не менее в конце концов пришлось писать нехилую систему отлова утечек памяти и в общемй сложнсоти убить не млао времяни на отладку в общем-то рабочего кода.
Все обертки давно наклеины Ваще долго тут читал ваши споры, много интересных мыслейЮ, но блин не смог сдержаться Тебя послушать, так до появляения .нет писалово программ было сущим адом — и обертки приклей, и лики лови годами, и надежности никакой, и сплошной AV. жуть... как же жыли то раньше...
VD>3. Отсуствие того же finally.
Да не сказать, что прям такая уж необходимая и незаменимая вещь. Мож чегол-то не знаю конечно, но в моей практике ни разу на плюсах не понадобилась
VD>4. Ненацелленность многих С/С**-библиотек на автоматический контроль ресурсов. Вспомним хотя бы CreateFile или fopen.
ну ты вспомнил ты еще какой нить int открывающий файл вспоми тот же std::ofstream абсолютно нормально особождает ресурс после разрушения. При чем детерминированно...
VD>Для того чтобы просто не получить кучи проблем, программист должен постоянно придерживаться целой кучи паттернов оберегающих его от граблей, и по стуи избегать тех самых мощьных возможностей С++, коими многие так часто гордятся. В итоге мы получаем ситуацию, ктода для написания одного и того же кода (что с точки зрения функциональности, что с точки зрения производительности) нам требуется соврершенно разный уровень квалификации программиста, совершенно разное время на решение задачи, и совершенно разное количество усилий.
Да не должен он ничего избегать — все мощные возможности в его распоряжении. Покажи мне пожалуйста пример того, как программисту на с++ приходится отказываться от какой-нить мощной возможности, чтоб не наступить на грабли?
Насчет времени готов спорить... Все очень зависит от задачи. Действительно, есть класс задач, в которых шарп выиграет по скорости разработки. Это задачи, которые не обладают сколь-нибудь значимой алгоритмической сложностью, а являются просто компоновкой тех или иных фич, типа там файлик открыли, прочитали, в мемо в окошке содержимое вывели, закрыли. Всякий там бухучет, который некритичен по времени исполнения, и который есть просто нагромождение кучи возможностей по выгребалову данных из юазы и их отображению, то есть где по сути все сводится к функциональностям типа add/delete/update/print report. Да, тут писать быстрее на шарпе, спору нет. Но как мне лично кажется на более/менее серъезной задаче (авиасимуляторы, компиляторы, сложные системы управления оборудованием, математические программы, графика) время проектирования, разработки алгоритмов и тому подобные вещи занимают настолько много времени, что выигрышь в собственно кодировании будет весьма условный. Тут уже не в языке дело по сути, потому что что в плюсах, что в шарпе — везде есть свои нюансы — тамследишь за памятью, там завызовами диспозов — и все зависит от задачи. Но все таки в защиту моих плюсов могу сказать что пока что, насколько мне известно, такие монстры как МС, EA, Adobe, Sun и т.д. весьма активно пользуют плюсы — можно судить хотя бы по требованиям к вакансиям на их сайте. почему так? Наверное потому что плюсы их устраивают. То есть (как мне лично кажется) не имеет смысла переходить на новую технологию с уже обкатанной, если производственный процесс укладывается в установленные рамки. А то что мы видим сейчас в области .НЕТ — это чистый маркетинг. То есть не продукт подгоняется под рынок, а во многих случаях рынок подгноняется под продукт. Ваще это очень модный подход, и не только в ИТ — всякие там кока-колы и т.п., да практически все крупные компании, так делают. С точки зрения бизнеса конечно очень эффективно.
VD>Остается только один вопрос... Нафига козе баян?
Здравствуйте, VladD2, Вы писали:
VD>Пока. Как видишь первые ласточки уже есть. Со временем народ поймет, что писать несистемный код на С/С++ — это тоже самое, что зарывать деньги в песок на поле дураков. Думаю, что когда появится официальный C# 2.0, и когда выдет в свет Феникс, разговоры о применении C# в любой сфере прикладного программирования (за исключением наверно приложений реального времени) уйдут в небытие.
Помню слышал те же слова от явовщиков... Ну и как, Java заменила С++?
... << RSDN@Home 1.1.4 beta 3 rev. 240>>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>По-моему, ты путаешь объем продаж одной фирмы в одном регионе с деньгами, вырученными другой фирмой из того же региона, но в результате продаж по всему миру.
Возможно. Но обсуждать узость раныка на базе его части тоже довольно странно. Не находишь?
>> Думаю среди сильных мира сего дело будет развиваться так. Сначала дотнет появится в виде скриптовых движков и дополнительных средств. А со временем вытеснит нэтив код. Случится это по моим прикидкам году эдак к 2010-2015.
ПК>В том числе на приставках
Несомненно в том числе и на приставках. Не даром же МС делал ХБокс?
ПК>, где пирог намного лакомее, чем на PC, и где не ю?
Пироги обычно просто делят или не делят. Рынок PC-игр — это очень богатый рынок. И на нем более чем достаточно места.
PC-игры значительно более передовые вещи нежели приставочные. Приставки в виду некоторых проблем подхода не могут так быстро наращивать технологии. Так на РС прошло уже 7 поколений видиокарт. А та же Sony PS пока что пережила только два поколения.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
VD>>Думаю, ты еще не раз задумаешся над вопросом кто из нас более вменяем.
MS>Ну давай вкурим твою фразу с точки зрения формальной логики. Допустим, что я являюсь невменяемым. Если так, то я никогда не признаю свою невменяемость по причине невменяемости и задумываться об этом не буду. Если же принять допуoщение о твоей невменяемости, то нафига мне об этом "не раз задумываться"?! Если же я все-таки буду "не раз задумываться", то это ставит под сомнение мою собственную вменяемость.
MS>С логикой у тебя точно не лады.
С логикой нелады у тебя:
MS>Если же принять допуoщение о твоей невменяемости, то нафига мне об этом "не раз задумываться"?
И:
MS>Так уж исторически сложилось, что я привык спорить с вменяемыми собеседниками.
Ну, и ко всему еще и продолжашь спорить.
MS>Мне вспомнилась цитата из известного произведения. MS>
MS>- Вы, Шариков, чушь говорите. И возмутительнее всего то, что вы говорите это безапелляционно и уверенно.
Ну, что же этим, очередным, оскорблением ты сорвал аплодисменты почти всех тех кому так не нравится Влад или его мысли. И за одно расписался в полной своей несостоятельности как оппонента и трезво мыслящего человека. Так держать!
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Здесь обсуждался вопрос неприемлемости использования Шарпа в 3D-играх. По этому поводу какие-нибудь аргументы есть? Или признаем все попытки признать это мнение обычной инсинуацией? ГВ>Так и признаем.
Ну, раз аргументов нет, то и ладно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Glоbus, Вы писали:
G>Истерика какая-то.
У кого?
G> Сам же сказал, что что в деструкторах, что в диспозе исключения кидаться не должны. А насчет дизигна языка — а можно конкрено описать, как дизайн языка мешает мне как разраюотчику писать try/catch в деструкторе и не выпускать оттуда исключения?
Ничего не мешат. Как и обходить все остальные заботливо уложенные грабли.
G>Мы их видим не потому, что они на плюсах. Мыих видим потому что руки из задницы у кого-то растут. Языка ваще играет очень тертью роль во многих случаях.
Правильно. Так и есть. Все беды из-за того, что руки из задницы растут. Но это же не мы?! Правда?! А те кто считает иначе они невменяемые уроды. Надо закрывать тему и идти учить ассэблер и машинные коды.
G>Все обертки давно наклеины
Расскажи это тем кто матерится на лики памяти и вылеты программ. Или... ах, да. Эти программы же пишутся криворукими уродами, а не нами.
G> Ваще долго тут читал ваши споры, много интересных мыслейЮ, но блин не смог сдержаться Тебя послушать, так до появляения .нет писалово программ было сущим адом — и обертки приклей, и лики лови годами, и надежности никакой, и сплошной AV. жуть... как же жыли то раньше...
Писать хорошие программы и после появления дотнета, и еще очень долго-долго после его смерти будет сущим адом. Мне искренне жаль тех кто этого не осознает. Я могу придумать интересную программу в считанные минуты (ну, максимум дни), а на ее реализацию мне нужны годы. И не просто мне. Годы нужны огромным коолективам. При этом очень часто получается так, что по прошествии многих лет от того плана, не побоюсь этого слова, от той изначальной светлой мечты, остается бледная тень. В итоге мы имеем глючный ворд и никуда не годных конкурентов. Мы имеем 10 лет назад марально устаревшие РСУБД вместо ООБД и ХМЛБД. Имеем игры интеллект ботов в которых ниже интеллекта таракана на кухне. В обещм, имеем полную задницу.
Поэтому даже малейший шаг на встречу облечению этого сущего ада должно приветствоваться как приветствуются глоток воздука после трехминутной задержки дыхания.
G>Да не сказать, что прям такая уж необходимая и незаменимая вещь. Мож чегол-то не знаю конечно, но в моей практике ни разу на плюсах не понадобилась
Видимо те кто ввели ее в свои языки небыли знакомы с твоей передавой практикой.
G>Да не должен он ничего избегать — все мощные возможности в его распоряжении. Покажи мне пожалуйста пример того, как программисту на с++ приходится отказываться от какой-нить мощной возможности, чтоб не наступить на грабли?
Так и вижу себе архитектора системы планирующего места размещения грабель и благодарного программиста обнаруживающего их своим лбом.
Если серьезно, то ты действительно думашь, что чтобы наступить на грабли, нужно их искать?
G>Насчет времени готов спорить...
Спорь.
G> Все очень зависит от задачи. Действительно, есть класс задач, в которых шарп выиграет по скорости разработки. Это задачи, которые не обладают сколь-нибудь значимой алгоритмической сложностью, а являются просто компоновкой тех или иных фич, типа там файлик открыли, прочитали, в мемо в окошке содержимое вывели, закрыли.
Есть мнение, что решение любых задачь программирования — это процесс компоновки тех или иных паттернов и алгоритмов. И чем проще их компоновать, тем проще решать задачи.
G> Всякий там бухучет, который некритичен по времени исполнения, и который есть просто нагромождение кучи возможностей по выгребалову данных из юазы и их отображению, то есть где по сути все сводится к функциональностям типа add/delete/update/print report.
Ну, да. Бесспорно! Задачи бухучета — это тупой последовательный вызов методов add/delete/update/print. Мы то с тобой как архитекторы это знаем. Не правда ли?
G> Да, тут писать быстрее на шарпе, спору нет. Но как мне лично кажется на более/менее серъезной задаче (авиасимуляторы, компиляторы, сложные системы управления оборудованием, математические программы, графика) время проектирования, разработки алгоритмов и тому подобные вещи занимают настолько много времени,
Скажи, так почему все таки бухгалтерские системы далеть на Шарпе проще? Ну, должно же быть этому логическое объяснение? Ну, не могия же это? Или магия?
И почему эта магия, по-твоему, не срабатывает на других задачах?
Да, и за одно ответь:
1. Почему авиасимулятор Ил2 использует Яву, а не написан целиком на С++? Он что бухгалтерию считает?
2. Почему я даже не мог подумать о создании собственного парсера на С++, а на Шарпе взялся и успешно его делаю?
3. Почему МС предпочел дотнет для реализации большей части АПИ Авалона? Ведь это же графика нового поколения. Что же они совсем дебилы выбрать ничего не дающие технологии? А ведь им еще и людей переучивать пришлось. Ведь у них раньше были одни С++-ники.
Не кажется все это странным?
G> что выигрышь в собственно кодировании будет весьма условный.
Понимаш ли. Выгрыш в скорости реализации проектов создаваемых на базе дотнета определяется совершенно прагматическими соображениями. И выбор Шарпа в качестве основного языка тоже.
Все очень просто. Дотнет позволяет сократить объем ошибок, а это значит меньше времени на отладку и экономия денег. Шарп позволяет не заморачиваться на поддржку разных паттернов, и больше сосредоточиться на процессе проектирования и идее/фичах программы. Вот такие банальные предпосылки. Но самое смешно, они работают. Чтобы убедиться в этом достаточно попробовать.
G> Тут уже не в языке дело по сути, потому что что в плюсах, что в шарпе — везде есть свои нюансы — тамследишь за памятью, там завызовами диспозов — и все зависит от задачи.
Бесспорно нюансы есть везде. Вот только объем этих нюаносв и их уровень совершенно разный. Это как при сравненнии ассемблера и С. Вроде возможностей у асма даже больше. И нюансы есть у обоих. Но вот объем и характер нюансов совершенно разный.
G> Но все таки в защиту моих плюсов могу сказать что пока что, насколько мне известно, такие монстры как МС, EA, Adobe, Sun и т.д. весьма активно пользуют плюсы — можно судить хотя бы по требованиям к вакансиям на их сайте.
Используют. Что с того? МС даже С во всю использует. Ворд говорят в основном на С написан. (Видимо от того и глючит так безбожно .) Но тем неменее, в МС понимают, что деньги нужно экономить и уже переводит гору разработок на тот же Шарп. Сан тоже многое делает на Яве. Ну, да ява к сожалению не очень то притендует на универсальность.
G> почему так?
А ты помнишь сколько писали приложений на С++ в 1987 году? А ведь С++-у было как раз 2 года от роду. Как раз как сейчас дотнету. МС начал переходить с С на С++ только в 90-ых. С момента появления С++, к тому моменту, прошло почти 10 лет.
G> Наверное потому что плюсы их устраивают. То есть (как мне лично кажется) не имеет смысла переходить на новую технологию с уже обкатанной, если производственный процесс укладывается в установленные рамки.
Ну, судя по Авалону и Индиге все же стоит.
G> А то что мы видим сейчас в области .НЕТ — это чистый маркетинг. То есть не продукт подгоняется под рынок, а во многих случаях рынок подгноняется под продукт. Ваще это очень модный подход, и не только в ИТ — всякие там кока-колы и т.п., да практически все крупные компании, так делают. С точки зрения бизнеса конечно очень эффективно.
Слава богу у менеджеров из МС хватило разума, чтобы понять, что успех продвижение новых технологий на 90% зависит от маркетинга. Ну, не умеют люди с благодарностью принимать плоды прогресса. Не отказыватья же от них по этому поводу? Мы так бы и сидели в командной строке запуская бач-файлы если бы не маркетологи из Эпла.
VD>>Остается только один вопрос... Нафига козе баян?
G>Глубоко философский вопрос...
Выходит так, раз такая куча народу не понимает стольк простых истин.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
S>>Помню слышал те же слова от явовщиков... VD>А я вот не помню.
Значит, ты не застал ту пору, когда Java только-только выпихивалась на рынок.
S>>Ну и как, Java заменила С++? VD>В создании ПО для бизнеса — полностью.
Это в какой местности такая беда стряслась?
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
У тебя, старичек
VD>Ничего не мешат. Как и обходить все остальные заботливо уложенные грабли.
А Dispose спасает нас от этого?
G>>Мы их видим не потому, что они на плюсах. Мы их видим потому что руки из задницы у кого-то растут. Языка ваще играет очень тертью роль во многих случаях.
VD>Правильно. Так и есть. Все беды из-за того, что руки из задницы растут. Но это же не мы?! Правда?! А те кто считает иначе они невменяемые уроды. Надо закрывать тему и идти учить ассэблер и машинные коды.
Не понимаю ваще о ком ты — какие невменяемые уроды, че это за твари такие невиданные? Я говорю о том, что ошибки в программах и всякие андефайнед-поведения от языка не зависят.
VD>Расскажи это тем кто матерится на лики памяти и вылеты программ. Или... ах, да. Эти программы же пишутся криворукими уродами, а не нами.
Не знаю, о чем ты — кто же такие криворукие уроды?
Насчет мемори ликов — ну так будут у тебя не мемори лики, а какая-нить другая лажа, не знаю какая и гадать не буду. Если у человека как программера уровень низкий, он напортачит на любом языке — что с гц что без. Серебрянной пули-то нету, понимаешь.. Язык с примочками не спасает от всех несчастий — он просто пытается заткнуть дыры насколько это возмжно. А насчет учить асм — очччень бы не помешало многим из тех, то себя называет прогарммером — не для того чтобы писать на нем все че ни попадя, а для того, чтобы выработался определенный способ мышелния.
VD>Писать хорошие программы и после появления дотнета, и еще очень долго-долго после его смерти будет сущим адом. Мне искренне жаль тех кто этого не осознает. Я могу придумать интересную программу в считанные минуты (ну, максимум дни), а на ее реализацию мне нужны годы. И не просто мне. Годы нужны огромным коолективам. При этом очень часто получается так, что по прошествии многих лет от того плана, не побоюсь этого слова, от той изначальной светлой мечты, остается бледная тень. В итоге мы имеем глючный ворд и никуда не годных конкурентов. Мы имеем 10 лет назад марально устаревшие РСУБД вместо ООБД и ХМЛБД. Имеем игры интеллект ботов в которых ниже интеллекта таракана на кухне. В обещм, имеем полную задницу.
Ну и какое отношение языки программирования имеют к ообд и интеллекту ботов? Не путай прогресс в науке и прогресс в инструментарии. А язык программирвоания — это не более чем инструмент решения задачи.
VD>Поэтому даже малейший шаг на встречу облечению этого сущего ада должно приветствоваться как приветствуются глоток воздука после трехминутной задержки дыхания.
Я приветствую Писал на шарпе сам, знаю че это такое — да, приятная вещь, то только как я уже сказал для определенного круга задач.
G>>Да не сказать, что прям такая уж необходимая и незаменимая вещь. Мож чегол-то не знаю конечно, но в моей практике ни разу на плюсах не понадобилась
VD>Видимо те кто ввели ее в свои языки небыли знакомы с твоей передавой практикой.
А к чему это тысказал?
VD>Так и вижу себе архитектора системы планирующего места размещения грабель и благодарного программиста обнаруживающего их своим лбом.
Давай ты будешь предметный разговор вести. А то "грабли!грабли!" а сказать ничего толком не хочешь.
VD>Если серьезно, то ты действительно думашь, что чтобы наступить на грабли, нужно их искать?
См. про грабли выше
G>>Насчет времени готов спорить...
VD>Спорь.
VD>Есть мнение, что решение любых задачь программирования — это процесс компоновки тех или иных паттернов и алгоритмов. И чем проще их компоновать, тем проще решать задачи.
Есть много разных мнений...
VD>Ну, да. Бесспорно! Задачи бухучета — это тупой последовательный вызов методов add/delete/update/print. Мы то с тобой как архитекторы это знаем. Не правда ли?
Да, мы калачи тертые... Раскинь-ка мне, почему такие сложные системы бухучета пишутся всеми кому ни лень — любая контора размером около 20 человек, не имеющих даже порой законченого высшего образования, с радостью берется слобать такой прожектец, чтоб на своем сайтиле в портфолио гордо вписать "системы бух. учета".
G>> Да, тут писать быстрее на шарпе, спору нет. Но как мне лично кажется на более/менее серъезной задаче (авиасимуляторы, компиляторы, сложные системы управления оборудованием, математические программы, графика) время проектирования, разработки алгоритмов и тому подобные вещи занимают настолько много времени,
VD>Скажи, так почему все таки бухгалтерские системы далеть на Шарпе проще? Ну, должно же быть этому логическое объяснение? Ну, не могия же это? Или магия?
Читаешь плохо? Я ж сказал — потому что бух. системы по своей сути не несут никакой тяжелой алгоритмичесмкой нагрузки — с точки зрения разработки 80% времени уходит именно на кодирование (которое на шарпе конечно быстрее чем на плюсах, но далеко не намного ) — то есть: нет никакого ресерча, зачастую не присутсвует оптимизация по скорости и данным (память и все такое — оно ведь не ресурс), то есть главное на что обращаем внимание — кодирование. Да, на шарпе оно проще — все-таки синтаксис попроще будет, за ресурсами следить не надо — то есть по времени процентов 10-15 будет выигрышь по сравнению с теми же плюсами. Для прожекта где, 80% — это то самое кодирование — это приличный плюс.
VD>И почему эта магия, по-твоему, не срабатывает на других задачах?
VD>Да, и за одно ответь: VD>1. Почему авиасимулятор Ил2 использует Яву, а не написан целиком на С++? Он что бухгалтерию считает?
Могу ошибаться, но на жабе писаны некритичные по сокрости его части.
Вопрос встречный: почему борланд ЖБульдер такой тормозный?
VD>2. Почему я даже не мог подумать о создании собственного парсера на С++, а на Шарпе взялся и успешно его делаю?
Это твои маленькие интимные трудности о чем ты там думал Я честно говоря не могу даже представить, что тебя сдерживало от написалова парсера на плюсах — если на такой задче язык играет для тебя настолько важную роль, то уменя есть сомнения относительно твоего проф. урвня — ты уж прости. Такая задача как написалово парсера от языка не зависит — можно хоть на бейсике сделать. Я вот прекрасно делал и делаю парсер на плюсах. Я могу и на шарпе написать без проблем. Могу и на паскакале (если вспомню его).
VD>3. Почему МС предпочел дотнет для реализации большей части АПИ Авалона? Ведь это же графика нового поколения. Что же они совсем дебилы выбрать ничего не дающие технологии? А ведь им еще и людей переучивать пришлось. Ведь у них раньше были одни С++-ники.
Что такое авалон, где применяется, какие системные требования? Если минимум на 3ГГц + 128 м видео — тада смело отвечу — мс предпочел дотнет для писалова апи для авалона шоб лучше продавались новые процы от интела
Насчет ничего не дающих технологий ты это зря... Я ж говорил, что понимаю достоинства .нета, но в то же время я вижу грань их применимости. а ты вот похоже не очень.
VD>Не кажется все это странным?
Нет.
G>> что выигрышь в собственно кодировании будет весьма условный.
VD>Понимаш ли. Выгрыш в скорости реализации проектов создаваемых на базе дотнета определяется совершенно прагматическими соображениями. И выбор Шарпа в качестве основного языка тоже.
Повторюсь в тридцатый раз. Если мы с тобой, мы вдвоем, как два реальных пацана, Влад, (понимаешь, без лишних людей, шоб это было нашей маленькой тайной), выйдем за пределы прожектов, которые делаются в 90% контор на просторах снг, то увидим, что в подавляющем большенстве случаев язык реализации есть третье дело. В наших с тобой странах специфика другая — в основном требуется просто кодинг, где да — шарп дает преимущество в 10%, которого вполне достаточно, чтоюбы контора, регшающая задачи на .нете обошла контору решающую точно такие же задачи на плюсах. Но как имне видется так будет не всегда.
VD>Все очень просто. Дотнет позволяет сократить объем ошибок, а это значит меньше времени на отладку и экономия денег. Шарп позволяет не заморачиваться на поддржку разных паттернов, и больше сосредоточиться на процессе проектирования и идее/фичах программы. Вот такие банальные предпосылки. Но самое смешно, они работают. Чтобы убедиться в этом достаточно попробовать.
Каких ошибок? Синтаксических? Может быть. Но синтаксические ошибки не критичны — они отлавливаются мгновенно на этапе компиляции и не увеличивают время разработки. Логические? Но тут тебе уже язык не поможет. Если дизайн приложения крив, или у программиста квалификация недостаточно высокая, то на каком языке не делай, а его тока могила исправит.
Далее. Инетерсная фраза
Шарп позволяет не заморачиваться на поддржку разных паттернов
О чем это было сказано — какие паттерны? кто на что замарачивается? Ну хоть один пример приведи граблей или там заморочек.
Далее. Насчет сосредоточится на процессе проектирования. Не играет рояли на каком языке ты пишешь. Если ты реально сосредотачиваешся на проектировании, то тебе должно быть очень параллельно, на каком языке будет реализована система. Во многих случаях с этим определяются уже после разработки структуры системы и детального его планирования.
VD>Бесспорно нюансы есть везде. Вот только объем этих нюаносв и их уровень совершенно разный. Это как при сравненнии ассемблера и С. Вроде возможностей у асма даже больше. И нюансы есть у обоих. Но вот объем и характер нюансов совершенно разный.
Как я уже упоминал, это не играет рояли — человек с хорошим уровнем как программер способен писать на любом языке — язык эт овсего лишь инструмент. Например. У знакомого в конторе работал человек-глыба по плюсам. Но его какого-то хрена засадили лобать на жабаскрипте минюшки и всякую подобеную лабуду. Он уже через неделю мог написать на жабаскрипте такой код, который работал и нормально отображался под любые браузеры, со всякими выплывающими фигнями и тп. Все-таки уровень знаешь ли...
G>> Но все таки в защиту моих плюсов могу сказать что пока что, насколько мне известно, такие монстры как МС, EA, Adobe, Sun и т.д. весьма активно пользуют плюсы — можно судить хотя бы по требованиям к вакансиям на их сайте.
VD>Используют. Что с того? МС даже С во всю использует. Ворд говорят в основном на С написан. (Видимо от того и глючит так безбожно .) Но тем неменее, в МС понимают, что деньги нужно экономить и уже переводит гору разработок на тот же Шарп. Сан тоже многое делает на Яве. Ну, да ява к сожалению не очень то притендует на универсальность.
Не с целью поспорить — а откуда инфа, что мс переводит своих разработчиков на шарп?
А то что ява не претендует на универсальность — дык правильно делает. И плюсы не претендуют кстати тоже. И шарпу того же желаю
VD>А ты помнишь сколько писали приложений на С++ в 1987 году? А ведь С++-у было как раз 2 года от роду. Как раз как сейчас дотнету. МС начал переходить с С на С++ только в 90-ых. С момента появления С++, к тому моменту, прошло почти 10 лет.
Ну и что? То есть думаешь что через 10 лет они перейдут на шарп? Сомневаюсь. Хотя бы просто потому что щас конторы намного больше чем щас, а занчит более инертные. Это как минимум. А в реале как я уже сказал, то потому что для таких контор вопросы моды на новое не играет рояль. Играет рояль эффективность. А эффективность зависит в данном случае далеко не от языка. Если бы они писали на коболе и имели такой же успех как щас используя плюсы то вопрос — зачем переводить такие большие конторы на другие, новые, необкатанные рельсы, если учесть что выгоды сомнительны — качественного скачка не будет точно, а убчтки будут однозначно.
VD>Ну, судя по Авалону и Индиге все же стоит.
А что такое авалон и индига?
G>> А то что мы видим сейчас в области .НЕТ — это чистый маркетинг. То есть не продукт подгоняется под рынок, а во многих случаях рынок подгноняется под продукт. Ваще это очень модный подход, и не только в ИТ — всякие там кока-колы и т.п., да практически все крупные компании, так делают. С точки зрения бизнеса конечно очень эффективно.
VD>Слава богу у менеджеров из МС хватило разума, чтобы понять, что успех продвижение новых технологий на 90% зависит от маркетинга. Ну, не умеют люди с благодарностью принимать плоды прогресса. Не отказыватья же от них по этому поводу? Мы так бы и сидели в командной строке запуская бач-файлы если бы не маркетологи из Эпла.
Тут обеими за. Маркетинг это хорошо и я очень мс за эт оуважаю (ваще за многое их уважаю). Но опять же как в случае с кока-колой — во многом рынок был создан искуственно.
..
VD>Выходит так, раз такая куча народу не понимает стольк простых истин.
Каких истин. Ни одной не было. Были рассуждения на тему...
Здравствуйте, Glоbus, Вы писали:
VD>>У кого?
G>У тебя, старичек
Ты меня с кем-то путаешь. Я пока не старичем (30 все же не возраст), и истерики у меня не случаются.
G>А Dispose спасает нас от этого?
Программа останется жить. Это не мало.
А потом те кто не сталкивался с реальной практикой программирования на дотнете просто не понимают, что Dispose — это большая редкость. И проблемы с ним возникают крайне редко. А вот с деструкторами сплошь и рядом.
G>Не понимаю ваще о ком ты — какие невменяемые уроды, че это за твари такие невиданные? Я говорю о том, что ошибки в программах и всякие андефайнед-поведения от языка не зависят.
Ну, и я о том же. Ошибки она у криворуких. А это естественно не мы.
Какая разница на Шарпе ты пишишь или на ассемблере? Ошибки ведь от языка не зависят.
Мало ли что в спецификации Шарпа в первых строка написано:
A program that does not contain any occurrences of the unsafe modifier cannot exhibit any undefined behavior.
Мы то знаем, что так не бывает!
VD>>Расскажи это тем кто матерится на лики памяти и вылеты программ. Или... ах, да. Эти программы же пишутся криворукими уродами, а не нами.
G>Не знаю, о чем ты — кто же такие криворукие уроды? G>Насчет мемори ликов — ну так будут у тебя не мемори лики, а какая-нить другая лажа, не знаю какая и гадать не буду.
А зачем говорить если не знаешь? Ты уж назови лажу, что есть в Шарпе нет в С++. А то выходит избавление от вечной головной боли — это вроде как и не достижение.
G> Если у человека как программера уровень низкий,
Опять старая песня. Как ты думашь, мой "программерский" уровень низкий? Ну, хотя бы ниже твоего? Так вот мой уровень как раз тем и высок, что я знаю цену ошибкам и понимаю важность системной борьбы с ними. Хорошие проивычки всегда хуже принципиальной невозможности. Лучше я потрачу свой уровень на борьбу с оставшимися проблемами, на повышение уровня своих програм, а не буду вспоминать, куда еще нельзя наступать.
G> он напортачит на любом языке — что с гц что без. Серебрянной пули-то нету,
Откровенно говоря я еще не видел людей которые не ошибаются. Конечно бывают неопытные люди и откровенные ламеры которые могут в двух соснах запутаться. Но эта ситуация мало интересна, да и даже в ней безопасный язык, качественные библиотеки, избавление ума от необходимости следить за памятью и разными антиграбельными паттернами сильно облегчают жизнь. Даже если неопытный прграммист ошибется, на Шарпе я найду ошибку значительно быстрее чем на С++. Ведь поведение принципиально поределено. Ни один ламер не написав слова unsafe не сможет испортить память или перейти по случайному указателю.
Поверь мне, я знаю что говорю. Я в свое время задолбался искать непонятные ошибки сделанные даже не мною. Порой можно было потратить несколько дней и так и не найти ошибки. А на шарпе я вылавливаю ошибки за считанные минуты. В худшем случае часы.
Да для этого тоже нужен не нулевой уровень. Но обладая оным я значительно увеличиваю свою производителность.
G> понимаешь.. Язык с примочками не спасает от всех несчастий — он просто пытается заткнуть дыры насколько это возмжно.
Не понимаю. Вернее ты не понимашь. Ты смотришь на то что не понимашь и не можешь понять что это я в нем нашел. А не видешь ты то, что это не язык с примочками. Это язык более тщательно спроектированный. Его концепции стройны и логичны. А главное просты. Нет 200 разных нюансов в казалось бы простещих вопросах. Например: Имена функций и указатели на функции
Наоборт все просто и очевидно. Причем если что-то недостаточно просто, то это скорее недостаток языка нежели кульная фича. Так все примочке по оптимизации производительности (вроде структур и отсуствия у них дефолтных конструкторв) — это проблема на наличие которой пошли скрипя сердцем и проверив, что это не вызовет огромных проблем. Кстати, чтобы проблем небыло специально запретили наследование структур.
G> А насчет учить асм — очччень бы не помешало многим из тех, то себя называет прогарммером — не для того чтобы писать на нем все че ни попадя, а для того, чтобы выработался определенный способ мышелния.
Ага бто-инструционный. Т.е. вместо дизайна — битовые оптимизации на каждом шагу. Я уже не раз встречал подобных орлов. Это смерть любому серьезному проекту. Они обычно просто не способны мыслить абстрактно.
Конечно занать общие принципы работы процессора нужно. И знать ассмблер тоже неплохо. Плохо зацикливаться на необхоимости этих знаний.
Здесь же речь о другм. Здесь речь, о том, что ты понимашь ущербность программирования на ассемблере, но не понимашь, что разница между ассемблером и тем же С только в защищенности от большоко количества подробностей и необходимости реализовывать те или иные вещи в иде паттернов.
VD>>Писать хорошие программы и после появления дотнета, и еще очень долго-долго после его смерти будет сущим адом. Мне искренне жаль тех кто этого не осознает. Я могу придумать интересную программу в считанные минуты (ну, максимум дни), а на ее реализацию мне нужны годы. И не просто мне. Годы нужны огромным коолективам. При этом очень часто получается так, что по прошествии многих лет от того плана, не побоюсь этого слова, от той изначальной светлой мечты, остается бледная тень. В итоге мы имеем глючный ворд и никуда не годных конкурентов. Мы имеем 10 лет назад марально устаревшие РСУБД вместо ООБД и ХМЛБД. Имеем игры интеллект ботов в которых ниже интеллекта таракана на кухне. В обещм, имеем полную задницу.
G>Ну и какое отношение языки программирования имеют к ообд и интеллекту ботов?
Прямейшее. Они не позволют абстрагироваться от часностей, а стало быть сложность основной задачи умножается (а то и возводится в степень) сложности борьбы с мелкими частностями с которыми вынуждает возиться выбранный язык/платформа.
G> Не путай прогресс в науке и прогресс в инструментарии. А язык программирвоания — это не более чем инструмент решения задачи.
Инструмент не инструмент... без разницы как его называть. Язык — это средство выражения мыслей. Можно сказать средство материализации мыслей. Ну, и за одно — это барьер между мыслью и ее воплощением.
Собственно инструмент, вроде текстового редаткора или утилиты рефакторинга, тоже имеет отношение к невозможности написать лучшего бота или ООБД. Ведь если они ускорят или упростят процесс материализации эдеи, то помогут решить стоящую задачу более качественно.
G>Я приветствую Писал на шарпе сам, знаю че это такое — да, приятная вещь, то только как я уже сказал для определенного круга задач.
Да нет этого круга. Это самовнушение. Есть области где дотнет как рантайм не способствует его применению. Эти области — это создание драйверов к анменеджед-ОС и реалтайм задачи. Других — нет.
G>А к чему это тысказал?
К тому-что то, что от того что ты ты что-то не используешь оно не становится ненужным. Я уже говорил, что ассемблерные программисты обходятся без многого того что ты считашь удобным и даже необходимо. Но тут ты их не понимашь и считашь их мнение взглядом из каменного века.
Так вот люди ввели finally так как это удобно. Шарп и так не простой язык, а одна из задач, стоявшая перед его разработчиками, была создать простой в использовании язык. Так что думая включать finally или нет они делали нелегкий выбор. Так что взгляд вроде "а я и без этого могу" для меня — это такой же взгляд из каменного века, как для тебя "а я и goto обойдусь".
finally дает полноту концепции обработки исключений. Я могу обработать его и/или сделать что-то несмотря на него. Без finally жить можно. Но его прийдется эмулировать с помощью некоторых паттернов, что обязательно усложнит код.
Конечно можно писать и без finally. И даже возможно, что finally действительно не нужен в некоторой программе. Но так же возможно, что не использование finally говорит только о том, что программист не использовал потенциала языка и мыслил понятиями более низкоуровневого/менее мощьного языка.
VD>>Так и вижу себе архитектора системы планирующего места размещения грабель и благодарного программиста обнаруживающего их своим лбом.
G>Давай ты будешь предметный разговор вести. А то "грабли!грабли!" а сказать ничего толком не хочешь.
Да я то толком говорю. Это вот слова:
Покажи мне пожалуйста пример того, как программисту на с++ приходится отказываться от какой-нить мощной возможности, чтоб не наступить на грабли?
как раз уводят разговор в сторону.
Грабли не застовляют не использовать мощных возможностей. Они подстерегают тех, кто забывает о мелких нюансах и не "живет по паттернам".
VD>>Есть мнение, что решение любых задачь программирования — это процесс компоновки тех или иных паттернов и алгоритмов. И чем проще их компоновать, тем проще решать задачи.
G>Есть много разных мнений...
Так как из них ты разделяшь? Я то высказл такое академическое мнение о том, что процесс создания ПО — это в первую очередь процесс его проектировния.
Просто любые задачи являются компоновко. Нужно только уметь их компоновать. А лобовые решения обычно как раз ущербны.
VD>>Ну, да. Бесспорно! Задачи бухучета — это тупой последовательный вызов методов add/delete/update/print. Мы то с тобой как архитекторы это знаем. Не правда ли?
G>Да, мы калачи тертые... Раскинь-ка мне, почему такие сложные системы бухучета пишутся всеми кому ни лень — любая контора размером около 20 человек, не имеющих даже порой законченого высшего образования, с радостью берется слобать такой прожектец, чтоб на своем сайтиле в портфолио гордо вписать "системы бух. учета".
А потому что задача эта настолько сложная и спицифичная для каждого предприятия, что еще никому не удалось создать решение удовлетворяющиее всех или хотя бы многих. Более менее удачне решения (очень далекие от идеала) стоят огромные деньги именно по тому, что спрос превышает предложение.
VD>>Скажи, так почему все таки бухгалтерские системы далеть на Шарпе проще? Ну, должно же быть этому логическое объяснение? Ну, не могия же это? Или магия?
G>Читаешь плохо?
Ну, или ты излагаешь. Третьего не дано.
G> Я ж сказал — потому что бух. системы по своей сути не несут никакой тяжелой алгоритмичесмкой нагрузки — с точки зрения разработки 80% времени уходит именно на кодирование
Стоп! А на что уходит 80% времени в других областях? И почему эти 80% нельзя устранить с помощь супер-пупер средств какого-нибудь С++?
G> (которое на шарпе конечно быстрее чем на плюсах, но далеко не намного )
Да чем же конечно? Ну, что там if за два в С++ что ли идет?
G> — то есть: нет никакого ресерча, зачастую не присутсвует оптимизация по скорости и данным (память и все такое — оно ведь не ресурс), то есть главное на что обращаем внимание — кодирование.
Вот тебе на. Значит в каких-нибудь ворде с экселями гигабайты данных и супер-сложные рассчеты, а в финансах данные крошечные и расчетов никаких. Надо мужикам рассказать, а то они то и не знают.
Мне то казалось, что как раз в области управления объемы данных огромны, а требуемые рассчеты и программирование зависимостей как раз и составляют львиную долю времени.
Прикинь как было бы здорово если бы перед создателями финансового и управленческого софта не стояли проблемы скорости и объема. Все данные оформляем в виде списков объектов, забираем в память и без напряга пересчитываем. Хотя пересчеты тоже напряжно писать. Лафа. Вот только на практике возникают опять частности. Данные все за раз в память не поднимишь. Вычислять каждый раз все тоже нельзя (каждое нажатие оператора выльется в недельный пересчет). Начинаются те самые оптимизации. Появляются разные структуры призванные ускорить рассчеты. Это усложняет модель. В итоге сложность вырастает до невироятных высот.
Ну, а то что многим кажется, что все просто как раз и приводит к тому, что все больше народу берется за решение этих задач. Так же количество участников рынка обусловлено тем, что решить конкретную задачу несравнимо легче чем решить ее универсально. Появлются конторы сидящие на шее у заказчиков и заказчики превращающиеся в софтвреные конторы.
G> Да, на шарпе оно проще — все-таки
Та чем?
G>синтаксис попроще будет,
Чушь. Обем синтаксиса (размер граматики и ее описание) у Шарпа на треть больше чем у С++.
G> за ресурсами следить не надо
О! Вот это уже верные слова...
Отбпросим примитивные задачи, там где нужно просто миллион строк в столбик посчитать. Возьмем как раз сложные сферы требующие сложных моделей и нетривиальной логики. Что же, по-твоему, отсуствие необходимости слежения за ресурсами не дало бы приемущества в этих сферах? Ведь если я вынужден следить за освобождением памяти, то я уже не смогу столько же внимания потратить на основную логику.
G> — то есть по времени процентов 10-15 будет выигрышь по сравнению с теми же плюсами.
Даже предположим 10-15. Что они на дороге валяются? И что контроль памяти это единственно на что нужно отвлекаться программисту и архитектору?
G> Для прожекта где, 80% — это то самое кодирование — это приличный плюс.
Любой проэкт — это планирование и кодирование. Всякие там отладки есть просто досадные мелочи на которые приходится отвлекаться. Так вот среда лучше приспособленная для проектирования и сборки проекта из высоко абстрактных блоков дает приемущество над средствами позволющими работать с блоками меньшей абстракции или вовсе не поволяющей (или хотя бы даже не подталкивающие) их использовать.
Единственная проблема заключается в том, что повышение абстракции в следствии действия закона сохранения энергии приводит к тому, что падает производительность получаемых решений. При этом основной задачей встающей перед создателями средств разработки становится разработка такого решения которая, во-первых, выжымала бы максимум производительности не жертвуя уровнем абстрации, а во-вторых, выдерживала бы оптимальный баланс между уровнем абстракции, скоростью и надежностью.
Так вот дотнет + Шарп — это попытка повысить уровень абстракции при этом минимально жертвуя производительностью. Причем баланс смещается в сторону надежности и повышения уровня абстракции, в ущерб скорости и особенно ресурсоемкости. Но это и разумно, так как скорость процессоров растет, память дешевеет. Главное, чтобы жертвы исчислялись в процентах, а полученный эффект в разах (а лучше порядках, но до этого пока далеко).
На мой взгляд, к сожалению, те кто делают дотнет упускают некоторые аспекты повышения уровня абстракции и возмоностей системы. Так в дотнете признается важность декларативности, но все же средств упрощения создания декларативных решений явно недостаточно. Многие сторонники С++ здраво уповают на том, что шаблоны С++ мощьная вещь, и что их мощи нехватает в Шарпе. Но они обычно не осознают, что мощь шаблонов не в их гибкости, а втом, что они позволяют делать кое-что не запланированное их создателями. Они позволяют заниматься метапрограммированием. И хотя позволют они это делать очень ограниченно, все же несомненно само наличие возможности является огромным подспорьем в увеличении мощьности языка.
По сути С++ убог до безобразия. Но благодаря метапрогрммным возможностям шаблонов в последние годы удалось залотать многие дыры этого языка.
Однако С++ имеет слишком плохую наследственность, в нем слишком много меликих нюансво не повзолящих оторваться от "земли". К тому же метапрограммирование на шаблонах очень сложно и доступно только специалистам очень высокого класса.
Я думаю, что для того чтобы у дотнета и Шарпа вовсе не осталось узких мест в него нужно просто добавить средства метапрограммирования. Причем добавить их явно, продуманно, и максимально прозрачно. Так чтобы метапрограммирование перестало быть уделом гуру. Так же важно чтобы метапрограммирование имело как можно меньше ограничений.
Забавно что в приведенной зесь статье высказываются очень сходные мысли. Правда про Лисп, но как не странно сикретным оружием преподносится не функциональные изыски, а метапрограмирование.
G>Могу ошибаться, но на жабе писаны некритичные по сокрости его части.
Ага. Логика игры. Совсем такая некритичная вещь. Ну, и сборка мусра (о которой тут рядом внушал ПК) тоже оказалась не критичной. Вот ведь как бывает?
G>Вопрос встречный: почему борланд ЖБульдер такой тормозный?
Я его не видел. Могу только препологать... Сильно торопились и не стали оптимизировать, или посчитали, что и так сойдет. Замечу, что IDEA и Эклипс тоже написаны на менеджед-продукте (Яве), но они почему-то не особо тормозят. Так же говорят довольно сносно работает ReSharper полностью написанный на дотнете. А те же http://arenawars.krawall.de/com/ вообще летает у меня на машине.
VD>>2. Почему я даже не мог подумать о создании собственного парсера на С++, а на Шарпе взялся и успешно его делаю?
G> Это твои маленькие интимные трудности о чем ты там думал
Это мои большие публичные победы в выборе правильного средства и подхода.
G> Я честно говоря не могу даже представить, что тебя сдерживало от написалова парсера на плюсах
Сложность и объем работ. Я как бы не за зарплату его пишу, а от случая к случаю. Межу отдыхом от дуракавалянием и основной работой (которой и так море).
G> — если на такой задче язык играет для тебя настолько важную роль, то уменя есть сомнения относительно твоего проф. урвня
Слава богу я достиг положения когда сам стал выносить приговоры по проф.пригодности, и в оценке орлов вроде тебя не нуждась. Мне есть чем подкрепить свою проф. пригодность. А вот подобные заявлния от лично тебля выглядят не смешно. Неговоря уже, о то, что это прямое оскорбление и нарушение правил форума.
G> — ты уж прости.
Бог простит. Что ты не понимашь, я пытаюсь объяснит вот уже второе писмо подряд. Поймешь, хрошо. Не поймешь, ну, не дано. Проживешь и без понимания.
G> Такая задача как написалово парсера от языка не зависит — можно хоть на бейсике сделать. Я вот прекрасно делал и делаю парсер на плюсах. Я могу и на шарпе написать без проблем. Могу и на паскакале (если вспомню его).
Я тоже могу. Но не без проблем. Тут я не так крут. А так как меньше всего проблем на Шарпе, вот и выбрал его. Причем явно не промазал.
VD>>3. Почему МС предпочел дотнет для реализации большей части АПИ Авалона? Ведь это же графика нового поколения. Что же они совсем дебилы выбрать ничего не дающие технологии? А ведь им еще и людей переучивать пришлось. Ведь у них раньше были одни С++-ники.
G>Что такое авалон,
В большинстве GUI-я следующей версии Виндвс (Лонгхорне).
G> какие системные требования?
В Лонгхорне Лонгхорновские (пока не объявлены).
Для ХРюши и Вынь2003:
Microsoft "Avalon" Community Technology Preview requires Microsoft® Windows® XP Service Pack 2 or Microsoft® Windows® 2003 Server.
1. From the CD or download package, select autorun.htm and select the Installation link.
2. On the Installation page, install Microsoft® .NET Framework v2.0 Beta 1, the Microsoft "Avalon" Community Technology Preview.
3. Optional: Install Microsoft® Visual Studio® 2005 Beta 1.
4. Finally, install the WinFX SDK.
5. Follow the instructions in the WinFX SDK Setup wizard.
G> Если минимум на 3ГГц + 128 м видео — тада смело отвечу — мс предпочел дотнет для писалова апи для авалона шоб лучше продавались новые процы от интела
О! МС уже прцессоры Интела продает!
G>Насчет ничего не дающих технологий ты это зря...
Нет. Это ты зря.
G> Я ж говорил, что понимаю достоинства .нета, но в то же время я вижу грань их применимости. а ты вот похоже не очень.
И что же мешает тебе сформулировать аспкты этой грани? Ты тут пытался, но так смог.
G>Повторюсь в тридцатый раз. Если мы с тобой, мы вдвоем, как два реальных пацана, Влад, (понимаешь, без лишних людей, шоб это было нашей маленькой тайной), выйдем за пределы прожектов, которые делаются в 90% контор на просторах снг, то увидим, что в подавляющем большенстве случаев язык реализации есть третье дело.
Боюсь я не увижу. Я уже 30 лет смотрю и никак не могу видеть.
G> В наших с тобой странах специфика другая — в основном требуется просто кодинг, где да — шарп дает преимущество в 10%, которого вполне достаточно, чтоюбы контора, регшающая задачи на .нете обошла контору решающую точно такие же задачи на плюсах. Но как имне видется так будет не всегда.
Думаю, ты резко занизил процент. Я бы говорил где-то о процентах начинающихся с 100.
G>Каких ошибок? Синтаксических?
Скорее семантическийх.
G> Может быть.
Точно. Я бы даже сказал 100%.
G> Но синтаксические ошибки не критичны — они отлавливаются мгновенно на этапе компиляции и не увеличивают время разработки. Логические? Но тут тебе уже язык не поможет.
Мне помогает.
G> Если дизайн приложения крив,
Какое отношение дизайн имеет к ошибкам программирования?
G> или у программиста квалификация недостаточно высокая,
Снова старая песня. Давай о квалификации говорить, например, с твоим менеджером проекта (у тебя он есть?), ну, или директором. В общем, с теми кто за это отвественнен должностным положением или личными бабками. Вот если они мне расскажут, что все их программисты имеют такую квалификацию, что проблем с отладкой никогда не случается, то я поверю.
G> то на каком языке не делай, а его тока могила исправит.
Все имеет значение. И квалификация, и опыт, и язык, и платформа, даже какой у вас в конторе воздух и маральная обстановка. Но сейчас идет речь о языке. И давай придерживаться предпосылки, что прочие условия равны.
G>Далее. Инетерсная фраза G>
G>Шарп позволяет не заморачиваться на поддржку разных паттернов
G>О чем это было сказано — какие паттерны? кто на что замарачивается? Ну хоть один пример приведи граблей или там заморочек.
Понимашь ли... Любой человек использует некий набор паттернов. Ну, например, я вскгда кладу ключи во вне комнаты, чтобы нечаяно их не захлопнуть. Влом менять замок, да и у других родственников он есть.
Та же фигня у программистов. Только в звисимости от языка уровень паттернов разный. У ассемблерщика есть такие паттерны как if, switch, for... ну ты понял. У сишника таких паттенов нет, так как они встроены в язык. Зато у С-ишника есть такие патерны как инкапсуляция, клсс, хэндл, колбэк. У С++ программиста таких паттернов нет, так как все нужно встроено в язык. За то у него есть такие паттерны, как интерфейс, ресурсная обертка, запрет присвоения в if-ах, обертка над указателями и т.п. У C# программиста таких... ну, короче, ты понял. У C#-программиста конечно тоже есть свои паттерны, но они уже ближе к паттернам проектирования GOF.
Надеюсь, я внятно изложил про то что я имею в виду под патернами?
G>Далее. Насчет сосредоточится на процессе проектирования. Не играет рояли на каком языке ты пишешь.
Ну, см. выше.
G> Если ты реально сосредотачиваешся на проектировании, то тебе должно быть очень параллельно, на каком языке будет реализована система.
Отнюдь. Проектирование, в отличии от процесса планирования фич, как раз четко завязано на язык реализации. Конечно его можно разделить на стадии совсем логического проектирования и физического (как в области РБД), но это всего лишь часность. Фактически архитектор должен составить четкое задание для исполнителей (программистов). И тут приходится проектировать в рамках имеющихся абстракций — паттернов. Если это ассемблерных софт, то проект окажется программой на С. Если сишный, то он будет смахивать на программу на С++, если С++-ных, то на програму на Шарпе, Шарповский — то на некий язык следующего поколения. Это конечно утрировано, но в общих чертах так оно и есть.
Кстати, зачастую у хороших ассемблершиков можно увидеть такой прием. Над ассемблерной процедурой стоят комментарии в котрых кроме общего обяснения присуствует так же аналогичный код на С, а в коде комментарии со ссылками на части этого кода и на объяснения почему тот или иной фрагмент откходит от С-проекта.
G> Во многих случаях с этим определяются уже после разработки структуры системы и детального его планирования.
Такие случае обычно не очень удачно кончаются.
Обычно со средствами определяются после этапа планированя фич (формирования требований к системе). А то и в процессе формирования общей идеи будущей программы.
VD>>Бесспорно нюансы есть везде. Вот только объем этих нюаносв и их уровень совершенно разный. Это как при сравненнии ассемблера и С. Вроде возможностей у асма даже больше. И нюансы есть у обоих. Но вот объем и характер нюансов совершенно разный.
G>Как я уже упоминал, это не играет рояли — человек с хорошим уровнем как программер способен писать на любом языке — язык эт овсего лишь инструмент.
Ну, то есть тебе нет разницы писать на асме или на на С++?
В общем то далее говорить не о чем. Ты думаешь на ассемблере и тебя ни в чем не переубедить. Чтобы ты меня понял ты должен начать думать на более высоком уровне.
G> Например. У знакомого в конторе работал человек-глыба по плюсам. Но его какого-то хрена засадили лобать на жабаскрипте минюшки и всякую подобеную лабуду. Он уже через неделю мог написать на жабаскрипте такой код, который работал и нормально отображался под любые браузеры, со всякими выплывающими фигнями и тп. Все-таки уровень знаешь ли...
Остается позвать этого человека сюда и поинтересоваться его мнением о безразличии к средствам разработки.
G>Не с целью поспорить — а откуда инфа, что мс переводит своих разработчиков на шарп?
Дык из МС. Плюс этот самый Авалон у меня сейчас на винте лежит и моей квалификации большее чем достаточно чтобы определить, что он в основном написан на C#.
G>А то что ява не претендует на универсальность — дык правильно делает. И плюсы не претендуют кстати тоже. И шарпу того же желаю
Да как раз С++ не только претендует, но и на сегодня является универсальным языком общего назначения.
VD>>А ты помнишь сколько писали приложений на С++ в 1987 году? А ведь С++-у было как раз 2 года от роду. Как раз как сейчас дотнету. МС начал переходить с С на С++ только в 90-ых. С момента появления С++, к тому моменту, прошло почти 10 лет.
G>Ну и что?
То что через десять лет ты будешь делать вид, что своих слов не говорил. Или оцениш насколько ты ошибался.
G> То есть думаешь что через 10 лет они перейдут на шарп? Сомневаюсь.
Боюсь тебя огорчить, но они уже частично перешли на шарп. И делают это все больше и больше. Думаю, ты удивишся увидив сколько кода в Лонгхорне написано на нем.
G> Хотя бы просто потому что щас конторы намного больше чем щас, а занчит более инертные. Это как минимум. А в реале как я уже сказал, то потому что для таких контор вопросы моды на новое не играет рояль. Играет рояль эффективность. А эффективность зависит в данном случае далеко не от языка. Если бы они писали на коболе и имели такой же успех как щас используя плюсы то вопрос — зачем переводить такие большие конторы на другие, новые, необкатанные рельсы, если учесть что выгоды сомнительны — качественного скачка не будет точно, а убчтки будут однозначно.
G>А что такое авалон и индига?
Здравствуйте, VladD2, Вы писали:
VD>Ну, что же этим, очередным, оскорблением ты сорвал аплодисменты почти всех тех кому так не нравится Влад или его мысли. И за одно расписался в полной своей несостоятельности как оппонента и трезво мыслящего человека. Так держать!
Извини, Влад. Как там сказал главный злодей в Kill Bill-2, "I overreacted". Что же касается "аплодисментов", то это не те аплодисменты, которые мне льстят. Но люди имеют право, и мы с тобой живем в этом социуме, пусть даже и виртуальном. И должны относиться к этому с уважением.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Знаешь, старик, очень долго читал, а как дочитал твой пассаж понял, что отвечать на него буду еще дольше и это было бы абсолютно бессмысленно А так как дискуссия зашла в тупик в очередной раз просто хочу озвучить мысль, что по моему мегасубъективному мнению ты крупно ошибаешся относительно того, что язык играет настолько фундаментальную роль, как ты это преподносишь — не играет рояли на чем напмсан конечный продукт. Ты очень часто делаешь упор на вопрос проектирования и привязки проектирвоания к языку — на мой взгляд, это неправильно — объяснения почему так смотри выше в предыдущем посте.
А ваще время рассудит, что там для чего выгоднее, шарп или плюсы Вот лет через 10 бы эту ветку поднять — вот тогда было бы интересно перетереть...
Здравствуйте, Шахтер, Вы писали:
Ш>На самом деле, самым правильным решением было бы реализация каскадирования исключений. Т.е. один объект исключения должен уметь цепляться к другому. А для этого в современный С++ надо всего лишь добавить функцию, возвращающую текущий объект-исключение.
Ш>
только вот проблема в том, что тип исключения неизвестен во время компиляции.
Так что какой бы хорошей эта идея ни была, она нереализуема, пока мы можем выкидывать любые типы исключений.
Вот если лимитировать эти типы до наследников std::exception — тогда да.
С другой стороны, необходимость этого сомнительна.
Т.е. если у тебя сгенерилось исключение и началась раскрутка стека, во время которой опять возникает исключительная ситуация, то 90%, что она является следствием первой.
Если это не так, то в дизайне какой-то косяк.
По крайней мере, я не могу придумать реального примера.
Скажем, если отвалилась сеть и ты не можешь записать что-то важное в файл, доступный по nfs, и генеришь исключение, то очевидно, что все деструкторы хендлов файлов, которые должны их закрыть, тоже бросят исключение, только вот зачем оно нужно?
На самом деле во всех вторичных случаях достаточно просто прописать в лог то, что случилось — если это необходимо, человек залезет в него и посмотрит, когда решит основную проблему. Но это вряд ли.
VD>По сути С++ убог до безобразия. Но благодаря метапрогрммным возможностям шаблонов в последние годы удалось залотать многие дыры этого языка.
Чем же он убог до безобразия, блин, а мне казалось, что С# — это кастрированный С++
VD>Однако С++ имеет слишком плохую наследственность, в нем слишком много меликих нюансво не повзолящих оторваться от "земли". К тому же метапрограммирование на шаблонах очень сложно и доступно только специалистам очень высокого класса.
Иногда отрыв от земли завершаеться падением на задницу (с) моё.
Наличие сборки мусора это не панацея от кривых рук.
Видел чудеса на VB 6, там крутые перцы вовсю Win API используют, но это не значит что VB круче вареных яиц
Vlad2 мне надо бросить C++ и пересесть на C#, только для моей задачи — это однозначно похороны
Что и следовало ожидать. 
.) Но тем неменее, в МС понимают, что деньги нужно экономить и уже переводит гору разработок на тот же Шарп. Сан тоже многое делает на Яве. Ну, да ява к сожалению не очень то притендует на универсальность.
