Здравствуйте VladD2, Вы писали:
ZEN>>Swing -- просто библиотека GUI, независимая от ОС. Напишите свою -- будет ещё одна альтернатива. Кстати, есть SWT (http://www.eclipse.org/) -- системно-зависимая библиотека (как AWT), возможный конкурент Swing по компактности и быстродействию.
VD>За ссылку спасибо, но писать свои ГУИ-ёвые библиотеки... Пускай уж это делает MS и Sun. Пока у MS это получается несравненно лучше.
Не Влад, ты не въехал. Эту библиотечку пишет третий монстр — IBM.
VD>Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем.
Здесь ты не прав. Совместимость снизу вверх он гарантирует.
VD>>>JSP содрано с ASP.
Ни в коей мере. Php и mod_perl моложе и asp и jsp. А вот asp.net явно содрана с jsp.
Влад, похоже предыдущий мой ответ глюканул и осталась одна цитата. Восстанавливать лень. Вкратце — сегодня поковырялся в доке по бинам — ты прав, BeanInfo может перекрыть информацию рефлекшена. Это криво. Но не так страшно поскольку есть интроспектор. Не лезь к бинам напрямую и тебе будет пофигу — BeanInfo там или еще что.
VD>Ну, поставь рядом эти два средства. Разберись в обоих и поймешь, что Билдер просто детская игрушка по сравнению с VS.Net и ее CodDom.
Примерно тоже есть и в современных java средах. Но там нет стандарта. Впрочем и MS до конца дело не довел.
ZEN>>А Delphi -- это вообще убожество с DFM-описаниями форм! Чуть версия не та -- заново формочку строй. VD>Отстал ты от жизни. У них вот уже пару версий по умолчанию текстовый формат используется, который имеет намного большую совместимость.
Да и раньше они без проблем конвертировались при первом открытии проекта. Проблемы были только когда пытались обратно в старой среде открыть.
VD>Код дом — это не хмл. Это библиотека двунаправленной генерации кода с очень серьезными способностями к расширению. Одна из особенностей независимоть от языка. В VS.Net формы можно даже на Яве (J#) клепать.
По моему название CodeDOM (code document object model) очень точно отражает суть. Это объектная модель кода.
VD>Это вообще не средство разработки. Это средства проектирования. Сдесь речь шала о другом. VS.Net — это компонентная среда разработки. В Розе можно спроектировать компонент, но нельзя положить его на форму и использовать.
Влад, справедливости ради — Together был пожалуй первым полномасштабным reverse engineering $ UML tool. Он и сейчас в этом плане покруче студии будет. Да и сериализация свойств из дизайнера в код появилась впервые в джаве.
ZEN>>Мне нет. Swing на порядок стройнее и продуманней. VD>Ну, тогда сравни результат. В свинге все компоненты — этнтри-лэвел. В VCL и WiтForms используются отлаженные и удобные контнолы из виндовс.
Тут про eclipse project вовремя напомнили — ну очень интересный проект. Если у ибм желание не пропадет то она будет не хуже winforms по быстродействию.
Здравствуйте AndrewVK, Вы писали:
VD>>За ссылку спасибо, но писать свои ГУИ-ёвые библиотеки... Пускай уж это делает MS и Sun. Пока у MS это получается несравненно лучше. AVK>Не Влад, ты не въехал. Эту библиотечку пишет третий монстр — IBM.
Ну, ему можно. Только ен верится, что что-нибудь путное выйдет. Они уже много начинаний делали. Но пока что зарабатывают на окучивании больших контор.
VD>>Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем. AVK>Здесь ты не прав. Совместимость снизу вверх он гарантирует.
Это написано в описании деприкэтед. К тому же уже были прицеденты.
VD>>>>JSP содрано с ASP. AVK>Ни в коей мере. Php и mod_perl моложе и asp и jsp. А вот asp.net явно содрана с jsp.
Кроме компонентов (с трудом отличимы от инклюдов) я особо ничего нового в Asp.Net не заметил. Просто изменили язык на компилируемый. Остальное последствия. Ну, а то, что JSP содрано с ASP оно даже Sun-ом не отрицается. Первична была идея активных страниц (код и разметка в одном флаконе). Все остальное мелочи.
AVK>Влад, похоже предыдущий мой ответ глюканул и осталась одна цитата. Восстанавливать лень. Вкратце — сегодня поковырялся в доке по бинам — ты прав, BeanInfo может перекрыть информацию рефлекшена. Это криво. Но не так страшно поскольку есть интроспектор. Не лезь к бинам напрямую и тебе будет пофигу — BeanInfo там или еще что.
Может для кого и не страшно. Я уже с OLE натрахался. Вот у где непоследовательность. После этого опыта мне вся непоследовательность кажется засадой. Тут оно как... Как спроектируешь, так и работать будет. :( А у меня как раз в задачах создание контейнера, только не IDE, а интеллектуального такого.
VD>>Ну, поставь рядом эти два средства. Разберись в обоих и поймешь, что Билдер просто детская игрушка по сравнению с VS.Net и ее CodDom. AVK>Примерно тоже есть и в современных java средах. Но там нет стандарта. Впрочем и MS до конца дело не довел.
Их вообще убить моло. Создать такую гору кода, и даже ее не документировать! Ну, а на счет примерно... тоже... ты попробуй дизасемблить это дело и сравнить объемы. Я только посмотрел из дали... Глаза округлились.
Надо будет в будующем раскопать все это дело. Благо с дизасемблером и отладчиком это возможно.
VD>>Код дом — это не хмл. Это библиотека двунаправленной генерации кода с очень серьезными способностями к расширению. Одна из особенностей независимоть от языка. В VS.Net формы можно даже на Яве (J#) клепать. AVK>По моему название CodeDOM (code document object model) очень точно отражает суть. Это объектная модель кода.
Ну, видишь люди из-за схожетси с XmlDom путают ее с Xml-ем вообще. Да и "объектная модель кода" это слишком абстрактно, чтобы понять что это такое, если раньше этого дела не видел. Но по сути так оно и есть...
AVK>Влад, справедливости ради — Together был пожалуй первым полномасштабным reverse engineering $ UML tool. Он и сейчас в этом плане покруче студии будет. Да и сериализация свойств из дизайнера в код появилась впервые в джаве.
Я говорю о том, что это разные продукты. Разные подходы. Зачем сравнивать UML и VS? В VS тоже Визио входит, но речь, то я вел не о том. Я конечно понимаю, что у них есть общее разбор и генерация кода, но они разное делают. В CodDom генерация кода — это способ сериализации.
AVK>Тут про eclipse project вовремя напомнили — ну очень интересный проект. Если у ибм желание не пропадет то она будет не хуже winforms по быстродействию.
Моло верится. К тому же скорее всего проподет. Но если вдруг получится, то будет замечательно, так как конкуренция нужна однозначно!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Ну, ему можно. Только ен верится, что что-нибудь путное выйдет. Они уже много начинаний делали. Но пока что зарабатывают на окучивании больших контор.
Ну пока выходит очень даже ничего.
VD>>>Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем. AVK>>Здесь ты не прав. Совместимость снизу вверх он гарантирует. VD>Это написано в описании деприкэтед. К тому же уже были прицеденты.
Например?
VD>>>>>JSP содрано с ASP. AVK>>Ни в коей мере. Php и mod_perl моложе и asp и jsp. А вот asp.net явно содрана с jsp.
VD>Кроме компонентов (с трудом отличимы от инклюдов) я особо ничего нового в Asp.Net не заметил. Просто изменили язык на компилируемый. Остальное последствия.
Ты просто не разобрался — сам механизм преобразования активной страницы к исходникам класса и компиляции его на лету 1 в 1 содран с jsp. Причем содран вплоть до мелочей. Единственное отличие asp.net от jsp это web forms.
VD>Первична была идея активных страниц (код и разметка в одном флаконе). Все остальное мелочи.
Эта идея была реализована задолго до появления asp.
VD>Их вообще убить моло. Создать такую гору кода, и даже ее не документировать!
Вот я и говорю — не успевали они похоже. Будем надеяться что в следующей версии они доделают.
AVK>>Тут про eclipse project вовремя напомнили — ну очень интересный проект. Если у ибм желание не пропадет то она будет не хуже winforms по быстродействию.
VD>Моло верится.
Скачай посмотри.
VD> К тому же скорее всего проподет.
ИБМ хочет на основе коммерческий проект сделать. Eclipse это не только swt но еще и универсальная платформа для инструментальных средств. Что то вроде студии.
VD> Но если вдруг получится, то будет замечательно, так как конкуренция нужна однозначно!
Да уже почти получилось.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте iZEN, Вы писали:
ZEN>>Тесты Java2 vs. Delphi: ZEN>>http://www.beep.ru/~izen/projects/projects.html ZEN>>См. "JavaTest" и "DelphiTest" ZEN>>Результаты на сортировки более-менее одинаковы: кто-то в одних алгоритмах впереди, кто-то -- в других. ZEN>>Результаты в вычислениях с плав.точкой просто потрясают. VD>К сожалению теста для Дельфи там нет (дэд-линк). Но и без этого теста я могу сказать (базируясь на наших тестах), что Дельфи будет быстрее во всех тестах (кроме строк) даже при сравнении с Ява 1.3. Если брать не вылизанные тесты, а реальные программы, то разныв в пользу Дельфи даже увеличится, потому что кодируя на Яве мало кто утруждает себя расстановкой сэйледов и других файналов.
Ничего особого не "вылизывал". Алгоритмы, формы почти один-в-один.
Вот они:
JavaTest -- http://www.beep.ru/~izen/projects/bin/javatest.zip
DelphiTest(обновил ссылку -- работает) -- http://www.beep.ru/~izen/projects/bin/delphitest.zip
ZEN>>Swing -- просто библиотека GUI, независимая от ОС. Напишите свою -- будет ещё одна альтернатива. Кстати, есть SWT (http://www.eclipse.org/) -- системно-зависимая библиотека (как AWT), возможный конкурент Swing по компактности и быстродействию. VD>За ссылку спасибо, но писать свои ГУИ-ёвые библиотеки... Пускай уж это делает MS и Sun. Пока у MS это получается несравненно лучше.
Почему же. AWT, например, писал один человек за полтора-два месяца. :) Кстати, из-за проявленной спешки она "неудобна".
AVK>>>> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.
И надёжность.
ZEN>>Не согласен. Есть промышленные приложения реального времени. Иногда (укладывается во временные рамки) Java подходит для этого из-за устойчивости (нет утечек памяти) и стабильности. VD>Ява вообще не применима для реального времени, так как ее реализация GC дает разные временные характиристики на одной и той же задаче. Реалное время — это прежде всего гарантированные временные задержки.
Иногда Java больше подходит, чем C/C++...
ZEN>>Он и не требует. Можно НЕ ИСПОЛЬЗОВАТЬ BeanInfo, поставляемое с Java-компонентом, а обойтись стандартным Introspector-ом. VD>Нельзя. Это спецификация.
Можно. Никто не заставляет придерживаться спецификации до последней буквы. Есть два пути: простой(BeanInfo) и сложный(врукопашную с Introspector).
ZEN>>JBuilder прекрасно включает в свою палитру визуального дизайнера любые классы и можно работать с ними без напряга, но если есть BeanInfo, то будут и иконки, и спец.редакторы свойств. :)) VD>Это как раз подтверждает мои слова. Обойтись можно, но в Sun сочли, что ради иконки можно запороть всю компонентную модель.
А мне нравится их подход: отделение Design-time-кода от Run-time-кода.
ZEN>>Все классы -- это компоненты -- да, но только в общем смысле этого слова. VD>У этого слова частных смыслов я незнаю. То что Sun называет ява бобами, все остальные вот уже около 10 лет называют контролами. ZEN>>Почему же "ересь"? Просто другой подход: скрываемые поля и специфицированные (Get..(), Set..(), Is..()) методы работы с ними. Вот так и никак иначе. VD>Это и называется нет. Есть эмуляция, а свойств нету. Причем это всего лишь выпендреж Sun-а... Если ты о свойствах.
Да, эмуляция. А, например, в Delphi настоящие свойства лучше? Ничуть -- иногда доходит до абсурда: дублирование одних вещей разными средствами.
ZEN>>BeanInfo может вернуть только ДОПОЛНИТЕЛЬНУЮ информацию. VD>Насколько я помню, там можно получить список методов. Может я заблуждаюсь?
Да, можно. А также дополнительную информацию по ним из самого BeanInfo.
VD>>>Если п.3 верен, то автоматом должен быть верен и этот пункт. Так как если пасажир может выбрать два пути, то водитель должен иметь горючее на самый длинный из них. ZEN>>Нет. Нельзя сравнивать методологию MS (весь офис в одном флаконе и игрушки к системе) и Java. Это из другой жизни...:) VD>Это ты о пасажире или о пути? ;)
Обо всём. :)
ZEN>>Когда есть BeanInfo, используется BeanInfo. Когда нет BeanInfo, а срочно нужна информация о структуре класса, используется Introspector и Reflection. VD>Дык BeanInfo если что эмулируется на рефлекшоне, так что можно всегда через него. ZEN>>На вкус и цвет... ZEN>>Меня, например, раздражает объектная модель Delphi VCL -- такой корявой структуры я больше нигде не видел. VD>Тебя раздржает не ОО-модель дельфи. А структура их библиотеки. Это азные вещи. Сама ОО-модель в Дельфи проста и последовательна. Хотя слишком проста и совсем недокументирована.
Вспомните MVC (паттерн проектирования Model-View-Controller). Думаете, VCL придерживается его? Отнюдь.
VD>>>>>8. Компонентная модель Нэта красива, стройна и почти не противоречива. ZEN>>У вас такой вкус...:) VD>Я сравниваю две модели. VD>>>На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое. ZEN>>Опять же, ваше личное мнение о красоте не всегда совпадает с мнениями других. ZEN>>Спорить о красоте, в этом случае, глупо. VD>А я и не отрицаю, что это мое мнение. И соглашаться никого не заставляю. ;) VD>>>Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?
Решили данные отделить от кода и придумали XML. В EJB данные о распространении и "инсталляции" в контейнеры засунули в deployment-descriptor(XML формата).
Контейнеры разные, у каждого свой способ инстанцирования EJB-бина и обработок транзакций.
Вот когда договорятся производители App-серверов о поддержке какого-либо унифицированного BeanInfo для EJB, тогда можно будет говорить о "настоящей бобовости" EJB-бинов.
Но зачем это нужно? Другой вопрос. Бобы с BeanInfo разработаны гораздо раньше EJB, технология BeanInfo стара(?) и непригодна(?) для быстроменяющихся условий бизнеса.
Выскажете свои "за" и "против". Как вы видите решение этой проблемы "BeanInfo для EJB"?
ZEN>>Голословное утверждение. Приведите пример, когда срочно необходим BeanInfo, когда без него не обойтись. VD>Всегд где нужна информация о типах для ява боба. Иначе работать будет не все.
???
Что "не всё"?
VD>>>IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?
Через Reflection можно получить всю информацию о run-time-"свойствах" класса.
ZEN>>Можно, но зачем это нужно? BeanInfo, в отличие от прямого reflection, обеспечивает более "человеческий" уровень понимания свойств компонента. VD>Свойств в Ява вообще нет. В Нэте они есть и "понимать" через решлекшон их как раз плюнуть.
Да, простите, свойств действительно нет (пусть будет в кавычках: "свойства").
VD>>>Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать?
Да. Они же представлены в бинарном неизменном виде (*.class-файлами).
VD>>>Да и дело в том, что не совместимы они с теми же Ё-бабами.
В чём несовместимы? В том, что какой-нибудь "левый" класс, допустим наследник кнопки, не может стать EJB-бином? Зачем так извращаться? :)
В принципе, для EJB-бина можно сделать BeanInfo, но это кому надо? EJB-бины -- "интеллектуальные процедуры" по изменению и сохранению бизнес-данных.
VD>>>Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.
BeanInfo -- "примочка" для предоставления красочно-описанной информации о компоненте, неважно, каком. Надо вам -- делаете, никто не заставляет.
VD>Воветую глянуть на Нэт. Там таких примочек нет, а красочность ни чуть не хуже. Правда там атрибуты есть, но файкт остается фактом.
ZEN>>Нужно для разработчика, чтобы было приятно и удобно работать со свойствами компонента во время разработки приложения. VD>Практика показывает, что можно и без них.
???
VD>>>Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/ ZEN>>Мне VCL не нравится. Но я же не кричу об этом на всю улицу. VD>Извени, а что ты делаешь? ;)
ИзвИняю. :)) VD>Не будем говорить кто это был... Но это был слоненок! :)
;) VD>>>Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)
ZEN>>deprecated-методы имеют в своём теле вызов "улучшенного" нового метода, так что они -- просто заглушки для использования старым кодом новых улучшенных функций. VD>Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем.
Нет, они просто устаревшие и меют в своём теле не прежний(старый) код, а вызовы новых методов.
VD>>>>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему. ZEN>>Когда это я менял тему? VD>См. свой спор на счет сравнения размеров JRE и .Net Runtime. В середине разговора, ты акуратно превел тему на клиентский компьютер, так и не ответив зачем на нем вообще нужна Ява.
То, что предлагали скачивать клиенту (.Net Redist), я сравнил с размерами и функциональностью JRE. Оказалось, что JRE в ТРИ раза (~32 Мбайт против ~11 Мбайт) весит меньше, а функциональность такая же. Кроме того, зачем .Net-клиенту нужен серверный код? Он компилить что-то будет?
VD>>>JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.
ZEN>>Так ли? В том же JBuilder визуальный дизайнер полностью two-way-tools, обходится без двоичных ресурсных файлов (не читая картинок). Редактируешь текст -- получаешь в визуале, ворочаешь визуал -- получаешь текст.
VD>Ну, поставь рядом эти два средства. Разберись в обоих и поймешь, что Билдер просто детская игрушка по сравнению с VS.Net и ее CodDom.
Почему игрушка? Нет лишних (.dfm, .res, .xml) файлов -- всё в чистейшем виде (only .java).
ZEN>>А где MS? "Редактируйте" res-файлы только мышкой в дизайнере! VD>Не понял. :???:
Это о версиях VS для C++.
ZEN>>А Delphi -- это вообще убожество с DFM-описаниями форм! Чуть версия не та -- заново формочку строй. VD>Отстал ты от жизни. У них вот уже пару версий по умолчанию текстовый формат используется, который имеет намного большую совместимость.
Знаю я это. Совместимость близка к нулю (из-за UNICODE в последних версиях и "новшествах" в VCL :)
ZEN>>Если CODEDOM -- это представление ресурсов визуальных форм в виде xml-дерева, то это реализовано в Java IDE NetBeans. Только это дерево полностью отчуждаемо от проекта. VD>Код дом — это не хмл. Это библиотека двунаправленной генерации кода с очень серьезными способностями к расширению. Одна из особенностей независимоть от языка. В VS.Net формы можно даже на Яве (J#) клепать.
Оно конечно. Это необходимо для поддержки нескольких языков. Я не спорю.
VD>>>Назови хоть один продукт который поддерживает двунаправленную генерацию кода на нескольких языках и при этом позволяет создавать встраиваемые генераторы кода для компонентов и их отдельных частей. ZEN>>Rational Rose, Together. VD>Это вообще не средство разработки. Это средства проектирования. Сдесь речь шала о другом. VS.Net — это компонентная среда разработки. В Розе можно спроектировать компонент, но нельзя положить его на форму и использовать.
VD>>>Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :( ZEN>>Вы системы разработки "клепаете" что-ли? Тогда, очевидно, в некоторые моменты понадобится использовать BeanInfo. Для "обычных" приложений BeanInfo излишне. VD>Не, теперь я скорее буду использовать .Net.
Ага. Вы хотели получить что-то похожее на OLE-контейнер для Java-приложений? Я прав?
VD>>>Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели. ZEN>>Не дублирование, но дополнение. Как вы это всё ещё не поймёте? VD>То что в BeanInfo больше информации я не спорю. Но там есть откровенный дубляж. Для любого кто хочет использовать компонентную модель, хочет чтобы она была просто, последовательна и непротиворечива. Дублях это точно не здорово. VD>>>Компонентная модель там не храмая. Многим нарвится и сама библиотека. ZEN>>Мне нет. Swing на порядок стройнее и продуманней. VD>Ну, тогда сравни результат. В свинге все компоненты — этнтри-лэвел. В VCL и WiтForms используются отлаженные и удобные контнолы из виндовс.
Мне не нравятся интерфейсные элементы Windows. Мне что, повесится из-за этого?
В Java2 Swing можно нарисовать любой GUI, отличный от системного.
ZEN>>InfoWorld, США" VD>Ну, на пресрелизы достаточно и ссылки.
Ну так как? JavaOS жива? ;)
Живее всех живых. Просто не замечаем небольшие вещи за спинами монстров. :user:
Здравствуйте Lloyd, Вы писали:
L>P.S. Под интегрировнностью я понимаю невозможность сущетствования, того, во что интергировано, без того, что интергрированно. L>Пример -- IE интергрирован в Windows.
Я конечно не специалист по Linux, но разве Вы можете работать в Linux'е без shell (bash, etc)?
IE для Windows является примерно тем же, что и shell для Linux, к тому же MS вместе с IE распространяет свежие версии своих библиотек.
L>В этом смысле Apache вовсе не интергрирован в Linux (прекрасно существует и без него).
Windows тоже прекрасно обходиться без IIS.
С уважением,
Кирилл Филиппов
Никакую проблему нельзя решить на том же уровне, на котором она возникла
(c) Альберт Энштейн
Приветствую.
IT>В-четвётых, а давай сравнивать не в мегобайтах, а в языках программирования. Java — это "Java, Sun Java" (c) Дж. Бонд. К .NET только от MS прилагаются C#, VB, MC++, JScript, Java (!!!). Плюс уже есть с полтора десятка языков от всяких левых производителей. Поэтому, я запросто стогу писать под .NET на Java, а вот сможешь ли ты писать под Java на C#? :)))
Мне кажется, этим самым шагом "платформа для всех языков" Microsoft пытается монополизовать спектр рынка ПО для разработчиков. И свидетельством тому есть то, что язык Java уже "подгребли" под свою .NET платформу...
Если Sun выстоит и начнет антимонополистическую программу разработки мультиязыковой платформы (кстати, это сделать можно было ого-го когда) только тогда все будет хорошо, а если не выстоит, даже не хочется думать и гадать об этом...
Ничего принципиально нового в принципе нету в мультиплатформенности. Об этом задумывались еще раньше,... гораздо раньше,... уж простите меня, не могу назвать примерные даты.
С уважением, Руслан
WBR, Руслан
Re[19]: В чем счастье в С#
От:
Аноним
Дата:
17.05.04 08:42
Оценка:
Здравствуйте, Tall, Вы писали:
T>Я конечно не специалист по Linux, но разве Вы можете работать в Linux'е без shell (bash, etc)?
Не можете. Но в Windows аналогом shell является Windows Explorer (explorer.exe), а не Internet Explorer (iexplore.exe).
T>IE для Windows является примерно тем же, что и shell для Linux, к тому же MS вместе с IE распространяет свежие версии своих библиотек.
Отсюда: IE для Windows является тем же, что и Mozilla для Linux. А без Мозиллы Линукс вполне неплохо работает.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Tall, Вы писали:
T>>Я конечно не специалист по Linux, но разве Вы можете работать в Linux'е без shell (bash, etc)? А>Не можете. Но в Windows аналогом shell является Windows Explorer (explorer.exe), а не Internet Explorer (iexplore.exe).
Я бы сказал, что это 2 шелла. Проверить это легко — наберите в адресных строках iexplore и explorer C:\ и найдите 10 отличий. А>Отсюда: IE для Windows является тем же, что и Mozilla для Linux. А без Мозиллы Линукс вполне неплохо работает.
Нет. У меня, например, включен Active Desktop. Никакая мозилла этого не делает. Хотя винда сама по себе неплохо работает. А еще можно запустить в качестве шелла Far и снести експлорер. На работоспособность сервера это не повлияет.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, shmakov, Вы писали:
S>Может быть... я вообще на JAVA пишу -как то разницы не заметил. Так ради тренеровки навоял простенький клиент-сервер на C#. Что же... если за это будут платить буду писать и на этом добре . Хотя я уже давно понял — на чем бы не писать, какая разница, все одно while...for...if... )
Это потому, что Вы ничего кроме императивных языков не видели. Хотите нового? Смотрите Eiffiel, Haskel, ML, OCaml, Lisp, Prolog...
Да и императивные языки весьма отличаются, если подняться чуть выше банальных if, for, while.
Здравствуйте, AndrewVK, Вы писали:
AVK>Влад, мне кажется значимость шаблонов ты несколько преувеличиваешь. Ну будут они, я думаю ничего кардинально не изменится. Та же Дельфи, при отсутствии шаблонов, множественного наследования и много чего еще вполне успешно конкурирует с С++.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, shmakov, Вы писали:
kuj>Это потому, что Вы ничего кроме императивных языков не видели. Хотите нового? Смотрите Eiffiel, Haskel, ML, OCaml, Lisp, Prolog...
kuj>Да и императивные языки весьма отличаются, если подняться чуть выше банальных if, for, while.
Угу, посмотрите на Smalltalk, там нет конструкций языка типа if, for, while...
Здравствуйте, shmakov, Вы писали:
S>Народ -а в чем фан в C#. S>Вот написал пару приложний — все слизали с JAVA... S>Многоплатформенности нет так как нет платформ поддерживающих .NET реально. S>Я бы сказал C# = JAVA for Windows... в чем фан то....
В чем sexy? А в том, что от MS. Больше ничего особенного там нет. Особенно — это .NET.
ZEN>Читали притчу о Вавилонской башне? Почему её не могли построить, знаете? ZEN>В одной голове несколько языков -- обалдеть можно! Либо один, но отлично, либо много, но удовлетворительно. Есть что изучать до старости...
Это наверное от сложности языков. Java,C#,Delphi одного поля ягоды и переход с одного на другой дело малого времени, но есть конкуренция и соответственно языки должны развиваться и затачиваться под конкретные задачи, что явно лучше когда монополистом оказывается один язык.
Так для решения конкретной задачи может подходить один язык (Васик.Нет для позднего связывания, построение сложных полиморфных классов на Delphi с использованием метаклассов, С# имеет тоже кучу достоинств, развиваются языки для спецфиских задач, но они легко объединяются в одно целое. А специализацию в любом случае ни кто не отменял. И не нужен экскаватор где можно решить задачу лопатой.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, Serginio1, Вы писали:
S>>И не нужен экскаватор где можно решить задачу лопатой.
K>И не стоит браться за лопату, если масштабы для экскаватора
Неее без лопаты никак нельзя
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
)
