Твое мнение насчет "научность vs инженерность" разработки понятна. Если они предоставят какие-то новые парадигмы и подходы мировому сообществу, то может быть ты прав. А если эта разработка будет закрытым образом использована MS, т.е. использована напрямую в практических целях, то согласно твоему же определению, это будет просто макетирование очередной инженерной разработки.
И насчет инноваций — неплохо тебе ознакомится с JavaMe, и конкретно с устройствами, типа @Blackberry. Тогда мы сможем поговорить о степени инноваций.
VD>В общем, я не против обсудить эту тему. Но объяснять все с нуля не буду. Как минимум я не имею должной компитенции, а вопрос разянен в тонне статей доступных в Интернете. Так что если хочешь конструктива, прочти любое введение.
Я вот только одного не понимаю, почему когда я пытаюсь развить тему привязки HAL к железу и уровне его абстракции, ты отсылаешь меня к микроядерной архитектуре??? Еще при этом пытаешься выставить за ламера. Я реально имел дело с совершенно различными по уровню HAL, и знаю о чем говорю. Понятие HAL никак не пересекается с архитектурой ОС.
Более того, если ты уж так подробно интересовался микроядерной архитектурой, то ты должен прекрасно понимать, что для микроядерной архитектуры требуется самый что ни на есть высокий уровень абстракции от железки. Ибо в микроядерной архитектуре общение с драйверами происходит наиболее затратно, т.е. наличие лишнего драйвера дорогого стоит. Именно из-за этой затратности эра микроядерных архитектур еще не наступила, скорее всего будет рулить еще один класс, помимо монолитных и микроядерных, о которых ты не упомянул — различные смешанные архитектуры. Конкретно, новая BSD, которую пишут на именно на основе микроядра, все же не будет полностью микроядерной. Необходимо будет делать некие компромиссы. Компроммисы уходят либо в HAL (что проще), либо в "монолитные" драйвера, что чуть сложнее, т.к. потребует от операцинки поддерживать 2 модели драйверов, "внешних" и "внутренних".
Именно поэтому я и считаю, что для каждой новой железки для этой Сингулярити придется приличную часть НЕПЕРЕНОСИМОГО кода по-любому писать в unmanaged.
----------
И по поводу моего незнания C#. А-я-яй опять дергать из контекста. Я говорил про прямой доступ не только к памяти, но и к портам и прерывания. Работа с прерываниями — это задание своих точек входа на обработчики. Я спрашивал — возможно ВСЕ это? НЕТ. На C# вряд ли можно написать корректную точку входа для обработки прерывания для конкретного проца. Т.е. в ф-ии HAL помимо всего того, что прочтешь по ссылке выше, надо будет добавлять нечто вроде SetStaticMethodAsIRQEntry, это тянет за собой еще одну проблему — надо обеспечить, чтобы указанный метод был явно загружен джитом, ибо обработка прерываний по сути должна иметь быструю реакцию, а не ждать, пока джит что-то там разджитит, т.е. в API надо добавлять еще методы по явному управлению VM (пусть даже во внутренние API OС).
В общем, когда они дойдут до более-меннее реальной системы и откроют всю информацию по ней, тогда можно будет судить, что именно и где managed, а где нет.
Простое заявление "у нас драйвера на C#" говорит слишком мало.
Здравствуйте, mrozov, Вы писали:
M>Здравствуйте, vdimas, Вы писали:
V>>Согласен. Дотнет отберет прилично задач не только у Явы, но и у С++. Ну и на здоровье. Самое правильное — использовать наиболее подходящий инструмент для каждой задачи. С++ приобретет легкий оттенок "системного" языка, а про С мы наверно забудем.
M>Я тут, собственно, именно об этом и говорю. А меня бьют лопатами.
А тут не все разрабатывают заказной софт. Софт для рынка имеет свои законы, и "удобство и скорость разработки" далеко не первый аргумент. Хотя, это очень сильный аргумент в заказных единичных задачах.
Опять же, во многих конторах уже накопилось весьма и весьма объемные и функциональные наработки на том же С++, т.е. вполне возможна ситуация, что некоторый класс даже заказных разработок будет выполнен быстрее и качественнее с применением обкатанных наработок, чем на .Net. Т.е. вопрос "целесообразности" — это такой многофакторный вопрос, и действительно, чей-то конкретный опыт не обязательно хорошо ложится на общий случай. Тебя "били лопатами" те, у кого дело примерно так и обстоит.
Поясню. В наработки входят не только либы/решения. Конторы "обрастают" всевозможными самописными тулзами и целыми интегрированными системами/надстройками. Т.е. в поддержание самого процесса целевых разработок было вложено немало сил, и эти вложения все еще неплохо себя оправдывают. Начинание с 0-ля может быть болезненным.
Для .Net только буквально к 2004-2005-му году сформировался достаточный список вспомогательного инструментария/либ. Многие весьма платные. Например, в Java ситуация пока что гораздо интереснее и больше свободы выбора.
В целом согласен. И о согласии с этой точкой зрения неоднократно заявлял выше, уважаемые товарищи с лопатами.
Но! Осмелюсь утверждать, что не "посмотрим через годик", а "посмотрели год назад".
Здравствуйте, mrozov, Вы писали:
M>В целом согласен. И о согласии с этой точкой зрения неоднократно заявлял выше, уважаемые товарищи с лопатами. M>Но! Осмелюсь утверждать, что не "посмотрим через годик", а "посмотрели год назад".
Да вот фиг там — год назад. С ORM ситуация все еще неясная, стандартов нет, полный хаос. В серверной и вообще высокоуровневой архитектуре АБСОЛЮТНО НИКАКИХ наработок. Каждый изголяется как может. Сравни с тем же Struts или Spring в Java. Наличие стандартов у них подталкивает разработку все более и более удобного инструментария для высокоуровневого макетирования/реализации приложений (эти стадии на том высоком уровне управляемости уже мало различимы, как тебе?).
Далее.
Из тулзов UML<->код ни одного более-менее адекватного халявного. RationalXDE и PD11 стоят просто каких-то заоблачных денег. Бесплатного дизайнера отчетов и вообще нормального опен-сорс ReportDesigner+engine — нет. Есть недорогой SharpShooter, но у него бока и глюки при подстановке своих компонентов (Chart от Infragistics, например). Есть еще от DevExpress — но какой-то бледненький редактор отчетов в нем, я бы не рискнул поставлять систему, где требуется Run-time ReportDesigning в production с ним.
Ах-ах-ах — Resharper... Блин, 2001-й год, IDEA. Здрасьььте, внезапно обнаружили, что в язаках типа C# оказывается можно точно определить множество вариантов подстановок в каждом конкретном случае.. приплыли. Вернее, разработчики все теже, просто это мы только проснулись.
Я смотрю на ситуацию для дотнета — ну вот просто нихрена нет, кроме "фреймворка" и каких-то слабосвязанных полу-поделок со стороны.
Дотнет (пока) еще не показал своего потенциала. По количеству и качеству околодотнетного инструментария мы еще барахтаемся на уровне Java примерно 2000-го года. Правда, довольно быстро набирает сторонников и общий "вес" всех "поделок". Но, насчет годика — это я прогнал. Как минимум года 3 надо еще посмотреть, там видно будет.
--------
Мы сами используем на одной из составных частей нашей системы C#. И пол-года назад я прошерстил весь интернет на предмет наличия готовых нормальных высокоуровневых фреймворков (а что, раз уж принято решение использовать C#, дык его надо выдоить до последней капли), ан нет... Как я уже высказался — куча слабосвязанных поделок, многие из которых претендуют максимум на слабоотработанный макет. Поэтому приличную часть енжина в своей системе делали ручками. Спасибо IT за удачную реализацию маппинга.
V>-------- V>Мы сами используем на одной из составных частей нашей системы C#. И пол-года назад я прошерстил весь интернет на предмет наличия готовых нормальных высокоуровневых фреймворков (а что, раз уж принято решение использовать C#, дык его надо выдоить до последней капли), ан нет... Как я уже высказался — куча слабосвязанных поделок, многие из которых претендуют максимум на слабоотработанный макет. Поэтому приличную часть енжина в своей системе делали ручками. Спасибо IT за удачную реализацию маппинга.
Ну а мы сделали свой. Хватает с головой. Причем реализация для Java потребовала бы не меньше усилий. Точно также могу сказать, что для java ничего нет. Хотя там ситуация намного лучше.
Но я, честно говоря, не очень понимаю, как это мы ловко перескочили на java? При чем тут она? Java — рулит, но какое это имеет отношение к предмету разговора?
mrozov wrote:
> Ну а мы сделали свой. Хватает с головой. Причем реализация для Java > потребовала бы не меньше усилий. Точно также zмогу сказать, что для > java ничего нет. Хотя там ситуация намного лучше.
Для Java есть Hibernate (http://www.hibernate.org), которого обычно
вполне хватает. Есть порт на .NET — NHibernate, но он в вечной альфе.
Вообще, для Java есть такая огромная куча свободного софта, что .NETу
еще оооочень долго придется догонять Java.
C>Для Java есть Hibernate (http://www.hibernate.org), которого обычно C>вполне хватает. Есть порт на .NET — NHibernate, но он в вечной альфе.
Да ну? Релиз проспали? =)
Обычно — да, но не нам.
C>Вообще, для Java есть такая огромная куча свободного софта, что .NETу C>еще оооочень долго придется догонять Java.
У Java нет за спиной MS. Поэтому java .net не догонит вообще никогда
Но! Я еще раз спрашиваю — при чем тут вообще Java, товарищи? И сам же себе отвечаю — непричем. Про .net vs java — это совсем в другую ветку.
Здравствуйте, mrozov, Вы писали:
M>Но! Я еще раз спрашиваю — при чем тут вообще Java, товарищи? И сам же себе отвечаю — непричем. Про .net vs java — это совсем в другую ветку.
Но как это не при чем? Обсуждается, куда же с плюсов уходить. Хорошим тоном на RSDN считается, что в .NET и C#
А вот такая альтернатива, как Java, почему-то не рассматривается. Хотя, как верно здесь подмечают, сейчас Java обвешана сопутствующими инструментами и технологиями гораздо круче C#.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, mrozov, Вы писали:
M>Но я, честно говоря, не очень понимаю, как это мы ловко перескочили на java? При чем тут она? Java — рулит, но какое это имеет отношение к предмету разговора?
Я тебе говорил про накопленный багаж инструментария для разработки. Уходя в .Net мы оказываемся на довольно-таки голом месте. Я тебе показываю пальцем на Java (из одной весовой категории же), и говорю "хочу так же!!!".
Джаву не люблю, но разнообразию и качеству инструментов должен отдать должное. Взять тот же Эклипс с его бесплатными сотнями прибамбасов от UML до поддержки высокоуровневых вещей, типа struts и spring. Ты наверно не обратил внимание на эти 2 названия, а они весьма сильнозвучащие. Это такие технологии лепки сложных систем на-лету. Мизинцем левой ноги. На .Net все еще предстоит трахаться ручками и самостоятельно и довольно-таки много, ибо, кроме платформы практически ничего больше нет.
Никто не собирается обсуждать Java vs C#. Априори, базовая платформа .Net мощнее (не берусь утверждать насчет сравнения с 1.5). Но на этом пока все. С прикладными наработками ой как туго. Я просто чуствую себя в каменном веке, по сравнению с Java-программистом по уровню организации труда. Это тем более неприятно, что инструмент потенциально более мощный.
А с чего ветка-то началась?.. А, ну да, есть ли смысл переходить на дотнет ВСЕМ прямо сейчас...
Здравствуйте, vdimas, Вы писали:
V>Джаву не люблю, но разнообразию и качеству инструментов должен отдать должное. Взять тот же Эклипс с его бесплатными сотнями прибамбасов от UML до поддержки высокоуровневых вещей, типа struts и spring. Ты наверно не обратил внимание на эти 2 названия, а они весьма сильнозвучащие. Это такие технологии лепки сложных систем на-лету. Мизинцем левой ноги. На .Net все еще предстоит трахаться ручками и самостоятельно и довольно-таки много, ибо, кроме платформы практически ничего больше нет.
Ты не обращал внимание на такое? struts vs ASP.NET Spring.NET
mrozov wrote:
> C>Для Java есть Hibernate (http://www.hibernate.org), которого обычно > C>вполне хватает. Есть порт на .NET — NHibernate, но он в вечной альфе. > Да ну? Релиз проспали? =) Обычно — да, но не нам.
Ух, а еще месяца 4 назад все в альфе было.
> C>Вообще, для Java есть такая огромная куча свободного софта, что .NETу > C>еще оооочень долго придется догонять Java. > У Java нет за спиной MS. Поэтому java .net не догонит вообще никогда
Коллеги, я верю в MS. Гораздо больше, чем во всех других производителей ПО вместе взятых. Пока эта вера меня не подводила.
За весь RSDN ответить не берусь.
Но! Разобравшись с .net, я пожалел, что не взялся за java в 2000 г. Однако, сейчас (и даже год назад) .net считаю лучшей ставкой. Но так как технологии близкие, то и веских аргументов (более веских, чем масса MS) у меня нет.
Примерно так. Но только топик вроде не об этом. все-таки.
Здравствуйте, GlebZ, Вы писали:
GZ>Ты не обращал внимание на такое? GZ>struts vs ASP.NET
по этой ссылке сравнение несколько однобокое, я дочитал до сравнения способов работы с данными и криво усмехнулся, не все они пишут о том, что принято в Java.
GZ>Spring.NET
Спасибо за линк, даже как-то не приходило в голову поискать такое. Посмотрим, и наличие инструментария в т.ч.
На счет микроядра. Вспомните (или возьмите последенее 4-ое издание Руссиновича, стр 40, врезка, особенно последнее предложение), что там сказано по поводу микроядра — ничего общего с Вашими утверждениями. А между прочим, рецензия (да и продвижение тоже) книги — МС-овская.
VD>Ты сходи на страничку проекта и потыках мышкой на профайлы этий самый "инженеров". Погляди где они работают, какие степени имеют и чем занимаются.
+1000. Оригинально! А они что кушать не хотят, и занимаются исключительно теми вещами, которые исходят из из собственной философской ориентации жизненного пути в этом мире . И просто "по-человечески" их не купить. А с такими же Именами (с большой буквы), но не работающие в одной "малоизвестной" фирме — уже не авторитет. Здорово! еще плюс тыща.
Здравствуйте, GlebZ, Вы писали:
GZ>Ты не обращал внимание на такое? GZ>struts vs ASP.NET
Интересное чтиво. Складывается впечатление "Белые начинают и прогрывают" Где "белые" -- это Sun и Java, а проигрывают как раз из-за того, что первыми начинают, набивают шишки, выбират направление, прокладывают просеку... И оказываются укатанными в асфальт катком марки ASP.NET под управлением .NET Framework
Но мне там одна фраза понравилась:
Unlike J2EE, in which the Application Server is completely independent from the OS, the .NET Application Server is the Microsoft Windows® Operating System (and the services provided by Windows). The .NET Framework was designed to integrate closely with IIS and COM+ to provide reliable application hosting services and native support for Web services standards like XML, SOAP, UDDI and WSDL. This integration provides a significant performance boost to .NET applications, but requires platform monogamy. The level of integration is much tighter than with any J2EE server, and results in more features and faster performance.
Понятно, что речь здесь идет, в основном, об ASP.NET, но и вся платформа .NET производит такое же впечатление. Поэтому, если кто-то занимается кроссплатформенной разработкой на C++ и хочет перейти на другую платформу/язык, то ему нужно смотреть не в сторону .NET от MS, а в сторону Mono или dotGNU. Не знаю, какие перспективы у Mono (хотя де Иказа был замечен в успешно стартовавших, но не доведенных до конца проектах, вроде Midnight Commander), а вот разработки GNU отличаются длительными сроками реализации (достаточно вспомнить GNU Classpath).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, GlebZ, Вы писали:
GZ>>Ты не обращал внимание на такое? GZ>>struts vs ASP.NET
E>Интересное чтиво. Складывается впечатление "Белые начинают и прогрывают" Где "белые" -- это Sun и Java, а проигрывают как раз из-за того, что первыми начинают, набивают шишки, выбират направление, прокладывают просеку... И оказываются укатанными в асфальт катком марки ASP.NET под управлением .NET Framework
Есть и еще кое-что. ASP.Net-среда (организация инструментария) так и подталкивает на написание кода в стиле Дельфи (с переносом на особенности web). Напротив, struts прямо-таки навязывает компонентный слабосвязанный подход. В сочетании со Spring можно получить практически тот самый идеально-утопический процесс построения приложений из кирпичиков-компонентов и ничего более. Т.е. механизм как бы уже есть, осталось развить соотв. базу CASE-средств по визуальному обслуживанию/конфигурированию этого механизма. Помните, были весьма популярны все эти обсуждения CASE-подходов в 95-98-м. ИМХО, ситуация близка к воплощению тех задумок, правда, немного с противоположной стороны. Сначала разработана гибкая среда исполнения компонентов, а потом стало очевидно, что, раз уж управление связями компонентов задается в run-time путем конфигурирования, то этот процесс вполне поддается автоматизации.
В той же ASP.Net, даже если мы вели разработку "правильно", т.е. создавали свои специализированные Web-контролы и компоненты, их объединение и layout выполняется все-равно в design-time в целевых web-страницах.
Здравствуйте, vdimas, Вы писали:
V>В той же ASP.Net, даже если мы вели разработку "правильно", т.е. создавали свои специализированные Web-контролы и компоненты, их объединение и layout выполняется все-равно в design-time в целевых web-страницах.
Мне вообще-то сложно судить о веб-разработках, но вот наткнулся на интересный взгляд на Java: It's the End of the World as We Know It. Примечательна последняя фраза:
But most of all, what Java needs -- for the first time I can think of -- is not just someone who can design software or APIs well, it needs "the vision thing".
Вполне возможно, преимущество M$ сейчас как раз в наличии этой "the vision thing".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
КДВ>> Они хоть на бумаге могут писать эти драйвера. Это ж Research!!!
VD>А какая разница? Я не призивал использовать Сингулярити для создания копрпоротивных веб-порталов. Я просто заметил, что есть VD>таки вполне разумные люди — ученые, которые пишут драйверы на C#. Пускай это пока что игрушка ученых, но идея эта уже далеко VD>не бредовая.
Ну если существуют ОС, полностью написанные на Java (JavaOS) и на Обероне, почему бы и не существовать ОС, полностью написанной на C#?
А вот будет ли эта ОС развиваться и практически применяться — вопрос другой...
... << RSDN@Home 1.2.0 alpha rev. 619 on Windows 2003 5.2.3790.65536 2.0.50727.42>>
Здравствуйте, Ligen, Вы писали:
L>"Слава, слава дракону!" L>Навеяно агрессивными постами дотНетовцев, похвально стремящихся к мировому господству (ветка писал на с++
). L>Дескрипшн: No holy wars. Зачем?
L>Можно наблюдать интереснейшую тенденцию:
Профессиоанальное становление :
1)Приобритение стиля .
2)способ реализации адвектный требованиям проекта .
3)И знания при этом никогда лишними не бывают.
Реальность такова пусть то .NET пусть C++ или еще какие либо модные слова/технологии.
Практическая сторона сроки X денег Y и реально работающие вещи ,а то что кому то хочется
чтобы это было хорошо написано в форуме пускай так оно и будет
Здравствуйте, vdimas, Вы писали:
V>Ориентируясь же на произвольную архитектуру необходимо операционке предоставить унифицированный доступ к этим фичам. Разумеется, не через inp() и outp(), а именно через более высокий абстрактный уровень.
Да какая разница где и как будет реализовано абстрагирование от тонкостей аппаратуры? Ты же ведь другое изначально утверждал. Ты утверждал, что невозможно на C# писать ОС так как он что-то там не может. Синклер тебе верно заметил, что то что действительно не возможно вылевается в 2-3 функции работы с портами. А все остальное пишется с их использованием. Функции эти в общем-то примитивный и могут быть просто написаны в машинных кодах. Вот погляди как ТК в свое время сделал стаб-код для работы с APC в Виндовс.
В общем, хреново ты развеял "заблуждения" Синклера.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
