. А поскольку я уже просто валюсь с ног, а завтра бы эту тему опять забыл завести, то обозначу только тезисы, а дальше по ходу разберемся.
Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
2. Он кажется слишком простым, пока не увидишь темы от nikov'a. Низкий порог для вхождения -> высокий порог для использования языка в полной мере -> и toSheridan: why so serious?
уже не кажется таким уж забавным, по сравнению с тем, что иногда встречаешь в шарповском коде, написанным профессиональными разработчиками при ревью
3. Он мешает развиваться дальше. Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников.
KV>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. Низкий порог для вхождения -> высокий порог для использования языка в полной мере -> ...
А вот это мне непонятно, в смысле а зачем использовать его в полной мере? Язык там уже в Visual Studio .Net 2003 был достаточный. Не язык нужно расширять, а набор классов и методов для решения тех или иных задач — вот в чём суть. Сейчас .Net расширяется и в ту и в другую сторону, я же считаю, что нужно сосредоточится исключительно на расширении возможностей FCL.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
. А поскольку я уже просто валюсь с ног, а завтра бы эту тему опять забыл завести, то обозначу только тезисы, а дальше по ходу разберемся.
KV>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
KV>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
Это еще надо обосновать. Если C# низкоуровневый, то какой язык высокоуровневый?
KV>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. Низкий порог для вхождения -> высокий порог для использования языка в полной мере -> и toSheridan: why so serious?
уже не кажется таким уж забавным, по сравнению с тем, что иногда встречаешь в шарповском коде, написанным профессиональными разработчиками при ревью
Многие увидели темы от nikov и тем не менее C# кажется таким же простым после этого. В этюдах показываются тонкие места стандарта, в реальных проектах такой код увидеть почти невозможно, например в отличие от "const char const *c".
KV>3. Он мешает развиваться дальше. Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников.
Ну сразу бы написал что "Прогрммист должен каждый год изучать новый язык (а лучше два)", было бы правильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>1. Он слишком низкоуровневый. KV>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. KV>3. Он мешает развиваться дальше.
4. Он не позволяет решать весь спектр задач. Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
AF>вопрос — а на что переходить?
Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
Здравствуйте, shrecher, Вы писали:
AF>>вопрос — а на что переходить?
S>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
. А поскольку я уже просто валюсь с ног, а завтра бы эту тему опять забыл завести, то обозначу только тезисы, а дальше по ходу разберемся.
KV>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
KV>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
найдите время, пожалуйста, расписать подробнее
пока не совсем очевидно
KV>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. Низкий порог для вхождения -> высокий порог для использования языка в полной мере -> и toSheridan: why so serious?
уже не кажется таким уж забавным, по сравнению с тем, что иногда встречаешь в шарповском коде, написанным профессиональными разработчиками при ревью
такие "пёрлы" чаще встречаются у разработчиков на других языках/платформах
увы.
KV>3. Он мешает развиваться дальше. Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников.
C#1.0 C#3.0 — это по сути, достаточно разные языки. C# 4.0, F# — это ли не интесивное развитие? причем, такое развитие, что,кажется, я сишарп начну с нуля изучать!
и, для желающих, в дотнете есть IronRuby/IronPython
KV>Ну вот собственно и все
эээээээ, нет
сегодня 8 Марта
надо поздравлять любимых
а вот завтра ждётся обстоятельное объяснение вашей аргументации
Здравствуйте, shrecher, Вы писали:
AF>>вопрос — а на что переходить?
S>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
есть IronPython под дотнет
язык — это хорошо, но важна и ПЛАТФОРМА
вот. допустим, ASP.NET MVC — это мощная платформа для быстрой и качественной веб-разработки.
у Руби есть менее производительное и более нестабильное решение Ruby on Rails
а чем таким обладает питон?
учитывайте еще мощные встроенные механизмы безопасности дотнета, мощные средства для работы с БД
есть ли всё это для питона?
или какие-то самописные ORM?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, shrecher, Вы писали:
AF>>>вопрос — а на что переходить?
S>>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
L>Какие преимущества есть в питоне (как языке)?
Во-первых, все это привязано к Винде, которая сама по себе, очень не безопасна.
Во-вторых, насколько реально все средства дотнета используются рядовыми разработчиками? Все это только усложняет язык и платформы.
VR>мощные средства для работы с БД VR>есть ли всё это для питона? VR>или какие-то самописные ORM?
а чем "самописные ORM" лучше других, тоже самописных? Весь код, как бы кем-то написан.
Кстати говоря, ORM для C# тоже самописные (не Microsoft).
Здравствуйте, shrecher, Вы писали:
VR>>учитывайте еще мощные встроенные механизмы безопасности дотнета,
S>Во-первых, все это привязано к Винде, которая сама по себе, очень не безопасна.
Это не мешало бы для начала доказать.
VR>>или какие-то самописные ORM?
S>а чем "самописные ORM" лучше других, тоже самописных? Весь код, как бы кем-то написан.
S>Кстати говоря, ORM для C# тоже самописные (не Microsoft).
Я так понимаю, Linq2Sql, Linq2Entities вы за ORM не считаете?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, shrecher, Вы писали:
L>>>Какие преимущества есть в питоне (как языке)?
S>>Простота. Понятный синтаксис.
L>Оч. субъективно. Имхо, C# в этом отношении лучше.
Начать с того, что C# требует VS, где нужно устанавливать "References", в тоже время в Питоне все текстовое. C# наворочено куча разных примочек типа "manifest", GAC, токенов, которые усложняют весь процесс разработки. "Переученному крестьянену" все это непонятно, уводит в какие-то дерби, вместо того, чтобы писать код.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, shrecher, Вы писали:
VR>>>учитывайте еще мощные встроенные механизмы безопасности дотнета,
S>>Во-первых, все это привязано к Винде, которая сама по себе, очень не безопасна.
L>Это не мешало бы для начала доказать.
The worm exploits a known vulnerability in the Windows Server service used by Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008, and the Windows 7 Beta
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
0. Он привязан к одной ОС. Дальше и обсуждать нечего.
Здравствуйте, shrecher, Вы писали:
L>>Оч. субъективно. Имхо, C# в этом отношении лучше.
S>Начать с того, что C# требует VS, где нужно устанавливать "References", в тоже время в Питоне все текстовое.
C# не требует VS. Если очень хочется можешь работать с обычными текстовыми файлами и компилировать через командную строку. Просто в студии это делать удобнее.
S>C# наворочено куча разных примочек типа "manifest", GAC, токенов, которые усложняют весь процесс разработки. "Переученному крестьянену" все это непонятно, уводит в какие-то дерби, вместо того, чтобы писать код.
В 99%-ов случаем это не нужно и не используется, так что "усложнение" сильно преувеличено.
S>The worm exploits a known vulnerability in the Windows Server service used by Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008, and the Windows 7 Beta
И что? Где сравнительный анализ win и lin платформ?
Здравствуйте, shrecher, Вы писали:
S>>>Кстати говоря, ORM для C# тоже самописные (не Microsoft).
L>>Я так понимаю, Linq2Sql, Linq2Entities вы за ORM не считаете?
S>О такой экзотике я даже не слышал, но думаю, не сравнить с hibernate.
Здравствуйте, gandjustas, Вы писали:
KV>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит. G>Это еще надо обосновать. Если C# низкоуровневый, то какой язык высокоуровневый?
Пролог
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, shrecher, Вы писали:
L>>>Оч. субъективно. Имхо, C# в этом отношении лучше.
S>>Начать с того, что C# требует VS, где нужно устанавливать "References", в тоже время в Питоне все текстовое.
L>C# не требует VS. Если очень хочется можешь работать с обычными текстовыми файлами и компилировать через командную строку. Просто в студии это делать удобнее.
Да, но производительность написания кода резко упадет.
Здравствуйте, shrecher, Вы писали:
L>>C# не требует VS. Если очень хочется можешь работать с обычными текстовыми файлами и компилировать через командную строку. Просто в студии это делать удобнее.
S>Да, но производительность написания кода резко упадет.
Конечно упадет. До уровня производительность написания кода на питоне.
S>>The worm exploits a known vulnerability in the Windows Server service used by Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008, and the Windows 7 Beta
L>И что? Где сравнительный анализ win и lin платформ?
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, shrecher, Вы писали:
AF>>>>вопрос — а на что переходить?
S>>>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
L>>Какие преимущества есть в питоне (как языке)?
S>Простота. Понятный синтаксис.
спорный момент
сишарп, до версии 3.0 имел очень понятный и ясный синтаксис
сча, согласен, как накрутили всяких лямбд, синтаксис становится всё запутанней и запутанней, но и даже сейчас каким-то "непростым" трудно его назвать
Здравствуйте, neFormal, Вы писали:
F>4. Он не позволяет решать весь спектр задач. Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом.
А что вообще есть "зависимость от Шарпов"? Любой человек, пишущий на C# считается зависимым? Но это же глупо. Я так могу сказать, что у 50% населения планеты есть религиозная зависимость от лифтов — пользуемся же.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, vit.rsdn, Вы писали:
VR>>Здравствуйте, shrecher, Вы писали: VR>>а чем таким обладает питон?
S>Все есть. http://www.djangoproject.com/
VR>>учитывайте еще мощные встроенные механизмы безопасности дотнета,
S>Во-первых, все это привязано к Винде, которая сама по себе, очень не безопасна. S>Во-вторых, насколько реально все средства дотнета используются рядовыми разработчиками? Все это только усложняет язык и платформы.
многие используют на полную катушку все возможности
кстати, если аналог механизма .NET Membership-ов (со всеми сопутствующими технологиями) для питана/руби?
VR>>мощные средства для работы с БД VR>>есть ли всё это для питона? VR>>или какие-то самописные ORM?
S>а чем "самописные ORM" лучше других, тоже самописных? Весь код, как бы кем-то написан.
S>Кстати говоря, ORM для C# тоже самописные (не Microsoft).
Linq2SQL
LinqToEntitites
ADO.NET Entity Framework
это то, что сама МС поддерживает
и есть кучи всяких там самописных NHibernate и прочих (если не устраивают оригинальные от МС-а)
мощные средства для внедрения АОР и DI в проекты а-ля Enterprise Library/Unity
где аналоги для питона/руби?
когда до ума доведут (думаю, в течении этого года доведут) ASP.NEt MVC, то предсказуемо быстро можно будет разрабатывтаь как простые сайты (как быстро это сча можно сделать на руби/питоне), так и сложные системы со сложной логикой.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>1. Он слишком низкоуровневый. KV>>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. KV>>3. Он мешает развиваться дальше.
F>4. Он не позволяет решать весь спектр задач.
в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально), дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, vit.rsdn, Вы писали:
v>> у Руби есть менее производительное и более нестабильное решение Ruby on Rails v>> а чем таким обладает питон?
AB>Django?
почитал линку, вообще не нашел ничего такого, чего нет в дотнете, что бы там не было интегрировано сразу
кстати, можете провести сравнительный анализ и указать, чем Django лучше, чем ряд этих готовых сайтов http://www.asp.net/community/projects/ или вот этих http://www.codeplex.com/site/search?projectSearchText=portal&sortBy=Relevance&licenses=| (более многочисленных)?
под дотнет кучи готовых решений, и чем среди них выделяется Djngo
для особых любителей питона, можно и под дотнет Django запустить Microsoft shows Django running on IronPython
Здравствуйте, shrecher, Вы писали:
S>Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
Это всё замечательно, но что он мне даст полезного для решения моих задач?
wxWidgets — быстрая, удобная, компактная, многофункциональная, кроссплатформенная библиотека для написания программ любых видов сложности с использованием таких языков как С++ и Питон.
Включает классы (Windows/Linux/MacOS/...):
— работа с базами данных
— потоки, таймеры
— файловая система, работа с архивами
— обработка и вывод XML/HTML, HTML widget
— удобная юникодная строка и RichText
— быстрые алгоритмы работы со структурами данных
— работа со стандартными диалогами, окнами, готовые шаблоны, AUI, MDI, Doc/View, font mapping, layout, курсор, DC (графика), события
— унифицированные контролы на базе нативных API разных операционных систем, расширяемые и многофункциональные
— работа с FTP/HTTP/Sockets, можно использовать СURL
— IPC (interprocess communication) через TCP
— Preview and Printing framework
— Drag and Drop, Clipboard
— логи для отладки, средства создания контекстной помощи на базе HTML
— парсер коммандной строки, работа с процессами
Быстрая генерация кода, компактный размер бинарника, высокая скорость работы программ.
Лицензия лучше чем LGPL. Позволяет линковать статически и закрывать код.
Помощь коммьюнити через форумы. Много дополнительных библиотек.
Здравствуйте, vit.rsdn, Вы писали:
F>>4. Он не позволяет решать весь спектр задач. VR>в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально), дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
это невозможно в принципе, т.к. оно заточено под одну платформу..
и критерии качества в студию!.
Здравствуйте, MxKazan, Вы писали:
F>>4. Он не позволяет решать весь спектр задач. Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом. MK>А что вообще есть "зависимость от Шарпов"?
отказ от других способов решения задач, попытки сделать всё через единственный инструмент, презрительное отношение
Здравствуйте, vit.rsdn, Вы писали:
VR>сишарп, до версии 3.0 имел очень понятный и ясный синтаксис VR>сча, согласен, как накрутили всяких лямбд, синтаксис становится всё запутанней и запутанней, но и даже сейчас каким-то "непростым" трудно его назвать
Ну то, что Вы его не знаете еще не делает его синтаксис непонятным. Наоборот в 3.0 было сделано много именно косметических улучшений. Те же лямбды раньше реализовывались анонимными делегатами.
Сравним (кратко):
С# 2
class SomeClass<T>
{
private T _property1;
private IList<T> _listProperty;
public T Property1
{
get { return _property1; }
set { _proprty1 = value; }
}
public IList<T> ListProperty
{
get { return _property2; }
set { _proprty2 = value; }
}
}
SomeClass<string> someClass = new SomeClass<string>();
someClass.Property1 = "some string";
someClass.ListProperty = new List<string>();
someClass.ListProperty.Add("string1");
someClass.ListProperty.Add("string2");
C# 3
class SomeClass<T>
{
public T Property1 { get; set; }
public T Property2 { get; set; }
}
var someClass = new SomeClass<string>
{
Property1 = "some string",
ListProperty = { "string1", "string2" }
};
и т.д. еще многое другое.
Мы недавно переводили проект с С# 2 на С# 3 — код стал гораздо лаконичнее и читабельнее.
Здравствуйте, Константин Б., Вы писали:
КБ>Есть SqlAlchemy для абрагирования от диалектов SQL. КБ>А ORM как таковые в питоне не особо и нужны, в силу динамической типизации языка.
Каким образом динамическая типизация откидывает необходимость в ОРМ?
Здравствуйте, vit.rsdn, Вы писали:
F>>4. Он не позволяет решать весь спектр задач. VR>в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально),
А что не так с WCF? Restful сервисы и MSMQ (NServiceBus) прекрасно работают...
VR>дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
Здравствуйте, vit.rsdn, Вы писали:
S>>Кстати говоря, ORM для C# тоже самописные (не Microsoft). VR>Linq2SQL VR>LinqToEntitites
Это не ОРМ. VR>ADO.NET Entity Framework
Это ОРМ с натяжкой, т.к. data-centric подход. VR>это то, что сама МС поддерживает VR>и есть кучи всяких там самописных NHibernate и прочих (если не устраивают оригинальные от МС-а) VR>мощные средства для внедрения АОР и DI в проекты а-ля Enterprise Library/Unity VR>где аналоги для питона/руби?
Вообще говоря, сравнивать питон/руби с дотнет это равносильно сравнению с 1С — ускоспециализированное с общего назначения. Про производительность и масштабируемость вообще и речи нет. Особенно, если смотреть на руби.
Единственный полноценный конкурент у .NET это Java в web/enterprise секторе.
VR>когда до ума доведут (думаю, в течении этого года доведут) ASP.NEt MVC, то предсказуемо быстро можно будет разрабатывтаь как простые сайты (как быстро это сча можно сделать на руби/питоне), так и сложные системы со сложной логикой.
Да уже давно разрабатываются. В том числе на ASP.NET MVC. А до ASP.NET MVC были Castle Monorail и Spring.NET
Несмотря на многие истерики дотнетчиков на форумах, я всё же осмелюсь ещё раз сказать, что да, С++ также прост как и С шарп. А может быть даже ещё проще, если кодировать в варианте только как С с классами. Про FastCGI вообще все молчат, будто бы это что-то такое очень страшное — а по сути, просто не распиаренная, но тем не менее простая и чрезвычайно эффективная технология запуска любых консольных бинарников на серверах.
Миф о "сложности" следует из человеческой любви к новизнам (есть такое типично ошибочное поведение, вид страсти у людей). Некоторые корпорации пользуются недостатками человеческой природы, и всегда рады подбросить в огонь что-нибудь новое, и предложить очередную революционную "технологию".
Вообще, эта любовь к новизнам обычно плохо заканчивается -- распыление, отсутствие концентрации, разбазаривание ресурсов и т.д.
Здравствуйте, shrecher, Вы писали:
S>Начать с того, что C# требует VS, где нужно устанавливать "References", в тоже время в Питоне все текстовое. C# наворочено куча
Открою Вам тайну: в C# тоже все текстовое.
S>разных примочек типа "manifest", GAC, токенов, которые усложняют весь процесс разработки. "Переученному крестьянену" все это непонятно, уводит в какие-то дерби, вместо того, чтобы писать код.
"Много умных непонятных мне слов" (с) Шеридан
. А поскольку я уже просто валюсь с ног, а завтра бы эту тему опять забыл завести, то обозначу только тезисы, а дальше по ходу разберемся.
KV>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
KV>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
oO Вы шутите? Скажите, что шутите... и не пугайте больше так.
KV>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. Низкий порог для вхождения -> высокий порог для использования языка в полной мере -> и toSheridan: why so serious?
уже не кажется таким уж забавным, по сравнению с тем, что иногда встречаешь в шарповском коде, написанным профессиональными разработчиками при ревью
Язык должен быть максимально мощным с минимальной сложностью (максимальной читабельностью кода не в ущерб лаконичности). С#, F#, Nemerle, Boo... — прекрасные образчики этого.
KV>3. Он мешает развиваться дальше.
Каким образом мешает-то? Наоборот, я уверен, многие про те же лямбды узнали только благодаря С#.
KV>Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников.
10 лет назад я был "оголтелым плюсником"
KV>Ну вот собственно и все
Так а чего "слазить надо"? Я так и не понял...
Здравствуйте, Anonim12, Вы писали:
A>Несмотря на многие истерики дотнетчиков на форумах, я всё же осмелюсь ещё раз сказать, что да, С++ также прост как и С шарп.
tl;dr
Ваши грубые и неумелые попытки троллинга несколько утомили. Потому просто -1.
Здравствуйте, neFormal, Вы писали:
F>4. Он не позволяет решать весь спектр задач. F>Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом.
Вот это Ваше сообщение порождено религиозными убеждениями, а не здравым смыслом.
Единственное, что не позволяет дотнет — писать драйверы.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>Есть SqlAlchemy для абрагирования от диалектов SQL. КБ>>А ORM как таковые в питоне не особо и нужны, в силу динамической типизации языка.
C>Каким образом динамическая типизация откидывает необходимость в ОРМ?
Главный плюс ОРМ — статическая типизация. Если ее нет, то зачем городить еще что-то поверх SQL?
C>Вот в том же Руби есть ActiveRecord — ORM.
Ну есть и есть. Нафиг он нужен то?
Здравствуйте, shrecher, Вы писали:
S>>>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
Кстати, гигантский минус питону — отсутствие сравнимой по удобству и мощности среды разработки, аналогичной VS+Resharper.
Здравствуйте, criosray, Вы писали:
F>>4. Он не позволяет решать весь спектр задач. F>>Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом. C>Вот это Ваше сообщение порождено религиозными убеждениями, а не здравым смыслом.
какими еще убеждениями?.
C>Единственное, что не позволяет дотнет — писать драйверы.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, criosray, Вы писали:
C>>Здравствуйте, Константин Б., Вы писали:
КБ>>>Есть SqlAlchemy для абрагирования от диалектов SQL. КБ>>>А ORM как таковые в питоне не особо и нужны, в силу динамической типизации языка.
C>>Каким образом динамическая типизация откидывает необходимость в ОРМ? КБ>Главный плюс ОРМ — статическая типизация. Если ее нет, то зачем городить еще что-то поверх SQL?
Нужно как-то преобразовывать результирующий recordset в объекты, а также изменения в объектах записывать в БД.
Сам маппинг полей таблиц в свойства объектов уже давно является тривиальной задачей.
VR>>а чем таким обладает питон?
S>Все есть. http://www.djangoproject.com/
VR>>учитывайте еще мощные встроенные механизмы безопасности дотнета,
S>Во-первых, все это привязано к Винде, которая сама по себе, очень не безопасна.
Ой ли? Вы лет на 10 с этим утверждением опоздали.
S>Во-вторых, насколько реально все средства дотнета используются рядовыми разработчиками? Все это только усложняет язык и платформы.
О каких средствах речь-то? .NET не является ускоспециализированной платформой, поэтому сам фреймворк за последние годы разросся до монструозных 200+ МБ и давно обогнал все другие фреймворки по функциональности.
Например, WCF стал гигантским шагом вперед в сравнении с WSE3 для вебсервисов.
WPF стал гигантским шагом вперед в сравнении с WinForms.
и т.д.
VR>>мощные средства для работы с БД VR>>есть ли всё это для питона? VR>>или какие-то самописные ORM?
S>а чем "самописные ORM" лучше других, тоже самописных? Весь код, как бы кем-то написан. S>Кстати говоря, ORM для C# тоже самописные (не Microsoft).
Что Вы к словами цепляетесь? Человек поинтересовался есть ли полноценные ORM для питона.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, neFormal, Вы писали:
F>>4. Он не позволяет решать весь спектр задач. F>>Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом. C>Вот это Ваше сообщение порождено религиозными убеждениями, а не здравым смыслом.
C>Единственное, что не позволяет дотнет — писать драйверы.
Неправда, см Singularity.
Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС".
Вообще-то существет только одно область даже потенциально недоступная для .NET — это realtime системы.
Но эта область настолько узкая, что MS может никогда и не соберется перерабатывать CLR чтобы он давал таие гарантии.
F>дотнет позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
И как это противоречит тому, что я написал?
F>следовательно, дотнет — это панацея и серебряная пуля современного программирования..
Нет никаких серебрянных пуль. Просто есть пули, которые позволяют бить, как воробья, так и слона.
.NET к ним относится.
Здравствуйте, gandjustas, Вы писали:
КБ>>Главный плюс ОРМ — статическая типизация. Если ее нет, то зачем городить еще что-то поверх SQL? G>Нужно как-то преобразовывать результирующий recordset в объекты, а также изменения в объектах записывать в БД. G>Сам маппинг полей таблиц в свойства объектов уже давно является тривиальной задачей.
А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах?
Здравствуйте, criosray, Вы писали:
C>Кстати, гигантский минус питону — отсутствие сравнимой по удобству и мощности среды разработки, аналогичной VS+Resharper.
лол сравнивали языки, а сравнили в итоге IDE-шки..
вопрос: а какие среды для разработки на питоне ты уже попробовал?.
Здравствуйте, Anonim12, Вы писали:
A>Несмотря на многие истерики дотнетчиков на форумах, я всё же осмелюсь ещё раз сказать, что да, С++ также прост как и С шарп. А может быть даже ещё проще, если кодировать в варианте только как С с классами. Про FastCGI вообще все молчат, будто бы это что-то такое очень страшное — а по сути, просто не распиаренная, но тем не менее простая и чрезвычайно эффективная технология запуска любых консольных бинарников на серверах.
А сами то на FastCGI писали че-нить? Или только на форумах троллите?
A>Миф о "сложности" следует из человеческой любви к новизнам (есть такое типично ошибочное поведение, вид страсти у людей). Некоторые корпорации пользуются недостатками человеческой природы, и всегда рады подбросить в огонь что-нибудь новое, и предложить очередную революционную "технологию".
И зачем вполне определенной корпорации это делать если они с большенства технологий бабла не получают?
A>Вообще, эта любовь к новизнам обычно плохо заканчивается -- распыление, отсутствие концентрации, разбазаривание ресурсов и т.д.
Моя небольшая статистика показывает что большенство неудовлетворенности новыми технологиями получают те, кто не смог её в достаточной мере изучить.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, vit.rsdn, Вы писали:
S>>>Кстати говоря, ORM для C# тоже самописные (не Microsoft). VR>>Linq2SQL VR>>LinqToEntitites C>Это не ОРМ. VR>>ADO.NET Entity Framework C>Это ОРМ с натяжкой, т.к. data-centric подход.
ОРМом нынче считается только hibernate и похожие на него поделки?
VR>>это то, что сама МС поддерживает VR>>и есть кучи всяких там самописных NHibernate и прочих (если не устраивают оригинальные от МС-а) VR>>мощные средства для внедрения АОР и DI в проекты а-ля Enterprise Library/Unity VR>>где аналоги для питона/руби? C>Вообще говоря, сравнивать питон/руби с дотнет это равносильно сравнению с 1С — ускоспециализированное с общего назначения. Про производительность и масштабируемость вообще и речи нет. Особенно, если смотреть на руби.
Непонятно как сравнивать язык и платформу, для который также есть реализация языка.
В отличие от 1С питон и руби являются языками общего назначения.
КБ>>>Есть SqlAlchemy для абрагирования от диалектов SQL. КБ>>>А ORM как таковые в питоне не особо и нужны, в силу динамической типизации языка.
C>>Каким образом динамическая типизация откидывает необходимость в ОРМ? КБ>Главный плюс ОРМ — статическая типизация. Если ее нет, то зачем городить еще что-то поверх SQL?
При чем тут статическая типизация? O/RM позволяет декларативно мэппить реляционные данные на объекты. Если есть объекты, значит должен быть и O/RM.
Ruby ActiveRecord подтверждает это.
C>>Вот в том же Руби есть ActiveRecord — ORM. КБ>Ну есть и есть. Нафиг он нужен то?
1. DB agnostic
2. domain-centric
3. Банальное удобство
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, vit.rsdn, Вы писали:
F>>>4. Он не позволяет решать весь спектр задач. VR>>в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально), дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
F>это невозможно в принципе, т.к. оно заточено под одну платформу..
И чем это мешает?
F>и критерии качества в студию!.
Качество = удовлетворение пользователей/затраченное бабло
Здравствуйте, criosray, Вы писали:
F>>следовательно, дотнет — это панацея и серебряная пуля современного программирования.. C>Нет никаких серебрянных пуль. Просто есть пули, которые позволяют бить, как воробья, так и слона. C>.NET к ним относится.
к таким пулям относятся большинство языков.. те же плюсы..
тем более применение плюсов возможно более широкое, чем шарпа..
разница только в том, что плюсы не пихают куда только можно, а шарп пихают..
Здравствуйте, gandjustas, Вы писали:
F>>>4. Он не позволяет решать весь спектр задач. F>>>Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом. C>>Вот это Ваше сообщение порождено религиозными убеждениями, а не здравым смыслом.
C>>Единственное, что не позволяет дотнет — писать драйверы. G>Неправда, см Singularity. G>Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС".
Я в курсе про сингулярити. Но сингулярити это проект на бумаге, так что не вижу смысла его упоминать...
G>Вообще-то существет только одно область даже потенциально недоступная для .NET — это realtime системы. G>Но эта область настолько узкая, что MS может никогда и не соберется перерабатывать CLR чтобы он давал таие гарантии.
Конечно.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Константин Б., Вы писали:
КБ>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах?
F>например, чтобы работать с объектами, а не с голыми данными..
А в чем профит-то? Данные они и есть данные, что в виде объекта, что в виде кортежа. Если надо вместе с данными куда-то передать и функции их обработки, то в питоне это не проблема. Даже гибче получается, потому что можно в разных местах разные функции использовать.
F>довольно удобно и почти не заставляет задумываться о структуре базы..
Ну в кортежи тоже не обязательно мапить из БД один-в-один.
Согласен, прогнал
но, для изучения всех этих ништяков, нужно приложить усилие, в следствии чего, многие lazy developers предпочтут питон,руби
C>Здравствуйте, vit.rsdn, Вы писали:
VR>>сишарп, до версии 3.0 имел очень понятный и ясный синтаксис VR>>сча, согласен, как накрутили всяких лямбд, синтаксис становится всё запутанней и запутанней, но и даже сейчас каким-то "непростым" трудно его назвать
C>Ну то, что Вы его не знаете еще не делает его синтаксис непонятным. Наоборот в 3.0 было сделано много именно косметических улучшений. Те же лямбды раньше реализовывались анонимными делегатами.
C>Сравним (кратко):
C>С# 2
<skipped>
C>C# 3
<skipped>
C>Мы недавно переводили проект с С# 2 на С# 3 — код стал гораздо лаконичнее и читабельнее.
Здравствуйте, Константин Б., Вы писали:
КБ>>>Главный плюс ОРМ — статическая типизация. Если ее нет, то зачем городить еще что-то поверх SQL? G>>Нужно как-то преобразовывать результирующий recordset в объекты, а также изменения в объектах записывать в БД. G>>Сам маппинг полей таблиц в свойства объектов уже давно является тривиальной задачей.
КБ>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах?
Потому данные сами по себе в отрыве от доменной модели ценности не несут.
O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали: КБ>>Главный плюс ОРМ — статическая типизация. Если ее нет, то зачем городить еще что-то поверх SQL?
C>При чем тут статическая типизация? O/RM позволяет декларативно мэппить реляционные данные на объекты. Если есть объекты, значит должен быть и O/RM.
А зачем городить в питоне объекты для реляционных данных?
C>>>Вот в том же Руби есть ActiveRecord — ORM. КБ>>Ну есть и есть. Нафиг он нужен то? C>1. DB agnostic C>2. domain-centric C>3. Банальное удобство
Раскройте пожалуйста эти тезисы поподробнее. А то слишком уж они неоднозначны.
Здравствуйте, neFormal, Вы писали:
C>>Кстати, гигантский минус питону — отсутствие сравнимой по удобству и мощности среды разработки, аналогичной VS+Resharper.
F>лол сравнивали языки, а сравнили в итоге IDE-шки..
Да тут все подряд сравнивалось. Язык без хорошей IDE имеет малую ценность.
F>вопрос: а какие среды для разработки на питоне ты уже попробовал?.
Glade, Eric, Komodo, и еще штук 5 уж и названий не помню. Все очень примитивно в сравнении с VS+Resharper.
Здравствуйте, vit.rsdn, Вы писали:
VR>но, для изучения всех этих ништяков, нужно приложить усилие, в следствии чего, многие lazy developers предпочтут питон,руби
правильно.. поэтому стоит обвинить в "lazy" всех шарперов, потому что они не хотят изучать внутренности буста..
а ведь нужно всего лишь приложить усилие.. но нет.. они не способны на это.. тьху..
Здравствуйте, gandjustas, Вы писали:
S>>>>Кстати говоря, ORM для C# тоже самописные (не Microsoft). VR>>>Linq2SQL VR>>>LinqToEntitites C>>Это не ОРМ. VR>>>ADO.NET Entity Framework C>>Это ОРМ с натяжкой, т.к. data-centric подход. G>ОРМом нынче считается только hibernate и похожие на него поделки?
Не нынче, а всегда. ОРМ изобретался именно для domain-centric подхода, а МС зачем-то исказила идею и переиначила на более data-centric.
C>>Вообще говоря, сравнивать питон/руби с дотнет это равносильно сравнению с 1С — ускоспециализированное с общего назначения. Про производительность и масштабируемость вообще и речи нет. Особенно, если смотреть на руби. G>Непонятно как сравнивать язык и платформу, для который также есть реализация языка. G>В отличие от 1С питон и руби являются языками общего назначения.
Не являются.
Здравствуйте, criosray, Вы писали:
КБ>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах?
C>Потому данные сами по себе в отрыве от доменной модели ценности не несут.
Что есть по вашему "доменная модель" и почему для нее обязательно нужны объекты?
C>O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д.
... и другие костыли, которые нужны если мы начинаем городить объекты. А если не создавать объекты, то это все и не нужно.
Здравствуйте, Константин Б., Вы писали:
КБ>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах?
C>>Потому данные сами по себе в отрыве от доменной модели ценности не несут.
КБ>Что есть по вашему "доменная модель" и почему для нее обязательно нужны объекты?
Google в тооооом направлении -->
Объяснять элементарное и базовое не в моих принципах.
C>>O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д.
КБ>... и другие костыли,
Костыли? КБ>которые нужны если мы начинаем городить объекты. А если не создавать объекты, то это все и не нужно.
Мда...
Здравствуйте, Константин Б., Вы писали:
КБ>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах? F>>например, чтобы работать с объектами, а не с голыми данными.. КБ>А в чем профит-то? Данные они и есть данные, что в виде объекта, что в виде кортежа. Если надо вместе с данными куда-то передать и функции их обработки, то в питоне это не проблема. Даже гибче получается, потому что можно в разных местах разные функции использовать.
профит в инкапсуляции..
еще например, в django можно при объявлении члена класса указать какого типа будет поле, какие у него настройки, указать некоторые настройки для таблицы и т.п.. Потом вызвать один скрипт и всё это будет создано в базе..
Здравствуйте, vit.rsdn, Вы писали:
VR>Согласен, прогнал VR>но, для изучения всех этих ништяков, нужно приложить усилие, в следствии чего, многие lazy developers предпочтут питон,руби
Ну и славно, если так. Значит меньше низкопробных программистов останется на дотнет. Может и индусы перейдут на пайтон... Очень хотелось бы верить.
Здравствуйте, neFormal, Вы писали:
F>>>следовательно, дотнет — это панацея и серебряная пуля современного программирования.. C>>Нет никаких серебрянных пуль. Просто есть пули, которые позволяют бить, как воробья, так и слона. C>>.NET к ним относится.
F>к таким пулям относятся большинство языков.. те же плюсы..
Естественно. Но у плюсов много минусов (извиняюсь за каламбур).
F>тем более применение плюсов возможно более широкое, чем шарпа..
Если речь о рациональном применении, то нет. Конечно не более широкое. Другое — да, более широкое — уж никак нет. F>разница только в том, что плюсы не пихают куда только можно, а шарп пихают..
Это шутка такая?
Здравствуйте, criosray, Вы писали:
VR>>но, для изучения всех этих ништяков, нужно приложить усилие, в следствии чего, многие lazy developers предпочтут питон,руби C>Ну и славно, если так. Значит меньше низкопробных программистов останется на дотнет. Может и индусы перейдут на пайтон... Очень хотелось бы верить.
хочется побыть илитой?.
изучи буст, покажи шаблонную магию им.Александреску.. и все будут тебе завидовать..
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, shrecher, Вы писали:
S>>>http://en.wikipedia.org/wiki/Conficker
S>>>
S>>>The worm exploits a known vulnerability in the Windows Server service used by Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008, and the Windows 7 Beta
S>Самый уязвимый браузер — Explorer, самый безопасный — Firefox
Бред в основном эксперты пишут. Я постоянно работаю с разными браузерами, так вот именно с помощью файерфокс большенство XSRF-атак можно выполнять, кроме того FF медленнее всех работает с DOM, очень часто падает на экзотических джаваскриптах.
К IE только две претензии: медленный и не очень соотвествует стандартам (до 8 версии)
Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, только работает также небыстро.
Здравствуйте, neFormal, Вы писали:
VR>>>но, для изучения всех этих ништяков, нужно приложить усилие, в следствии чего, многие lazy developers предпочтут питон,руби C>>Ну и славно, если так. Значит меньше низкопробных программистов останется на дотнет. Может и индусы перейдут на пайтон... Очень хотелось бы верить.
F>хочется побыть илитой?.
Простите что? F>изучи буст,
Давно (хотя мои знания про boost наверняка устарели).
F>покажи шаблонную магию им.Александреску.. и все будут тебе завидовать..
Нет там никакой магии. Вот AOP, основанное на IL-weaving куда больше похоже на магию.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего.
Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком.
Для устройств на базе ARM или Blackfin есть .NET Micro Framework.
А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу).
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Константин Б., Вы писали:
КБ>>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах? F>>>например, чтобы работать с объектами, а не с голыми данными.. КБ>>А в чем профит-то? Данные они и есть данные, что в виде объекта, что в виде кортежа. Если надо вместе с данными куда-то передать и функции их обработки, то в питоне это не проблема. Даже гибче получается, потому что можно в разных местах разные функции использовать. F>профит в инкапсуляции..
Раскройте этот момент поподробнее. Инкапсуляции чего от чего.
F>еще например, в django можно при объявлении члена класса указать какого типа будет поле, какие у него настройки, указать некоторые настройки для таблицы и т.п.. Потом вызвать один скрипт и всё это будет создано в базе..
Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
Здравствуйте, gandjustas, Вы писали:
G>Бред в основном эксперты пишут. Я постоянно работаю с разными браузерами, так вот именно с помощью файерфокс большенство XSRF-атак можно выполнять, кроме того FF медленнее всех работает с DOM, очень часто падает на экзотических джаваскриптах.
Про DOM это давно не так.
Про javascript — noscript рулит.
G>К IE только две претензии: медленный и не очень соотвествует стандартам (до 8 версии)
А что 8ка наконец соответствует стандартам? 6ка и 7ка это СУЩИЙ ужас для javascript разработчика. Посмотрите код ExtJs — СПЛОШНЫЕ костыли в js и css для IE...
G>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити,
Не заметил.
Здравствуйте, criosray, Вы писали:
F>>тем более применение плюсов возможно более широкое, чем шарпа.. C>Если речь о рациональном применении, то нет. Конечно не более широкое. Другое — да, более широкое — уж никак нет.
и, конечно же, этому есть подтверждение?.
F>>разница только в том, что плюсы не пихают куда только можно, а шарп пихают.. C>Это шутка такая?
какие уж тут шутки?. десктоп, веб, игры и прочее.. везде туда пихают шарп..
мэйнстрим такой мэйнстрим..
Здравствуйте, criosray, Вы писали:
КБ>>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах? C>>>Потому данные сами по себе в отрыве от доменной модели ценности не несут. КБ>>Что есть по вашему "доменная модель" и почему для нее обязательно нужны объекты?
C>Google в тооооом направлении --> C>Объяснять элементарное и базовое не в моих принципах.
Я там уже был. Что из этого вы имеет ввиду.
C>>>O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д.
КБ>>... и другие костыли, C>Костыли?
Разве нет? В чем же профит от этих штук?
КБ>>которые нужны если мы начинаем городить объекты. А если не создавать объекты, то это все и не нужно. C>Мда...
Здравствуйте, Константин Б., Вы писали:
КБ>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
Вы похоже совершенно не понимаете о чем речь? Вот у нас доменная модель на более сотни сущностей. Как со всей этой кухней работать без ОРМ и без объектов???
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, vit.rsdn, Вы писали:
v>> у Руби есть менее производительное и более нестабильное решение Ruby on Rails v>> а чем таким обладает питон?
AB>Django?
в дополнение, интересный момент ,почему гугл включила весьма ограниченную поддержку этого проекта в своих Google Appsю Полноценная поддержка вызвала бы лавинообразный рост количество Python-девелоперов, мигрируеющий с РНР/ Ruby
Здравствуйте, Константин Б., Вы писали:
F>>профит в инкапсуляции.. КБ>Раскройте этот момент поподробнее. Инкапсуляции чего от чего.
инкапсуляция данных и средств работы с бд..
на всякий случай:
Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
КБ>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
нет, мы приходим к вопросу "делать всё руками или автоматизировать?"
ясен пень, можно всё сделать самому.. но зачем, если можно проще?.
F>>>тем более применение плюсов возможно более широкое, чем шарпа.. C>>Если речь о рациональном применении, то нет. Конечно не более широкое. Другое — да, более широкое — уж никак нет.
F>и, конечно же, этому есть подтверждение?.
Сплошь и рядом. Весь корпоративный спектр приложений по-сути.
F>>>разница только в том, что плюсы не пихают куда только можно, а шарп пихают.. C>>Это шутка такая?
F>какие уж тут шутки?. десктоп, веб, игры и прочее.. везде туда пихают шарп..
Шарп в играх? Просвятите. В Веб ему самое место. Ему и джаве. Десктоп пока что-то не заметил, чтоб было много программ на дотнет. Share/Free ware почти все на С++.
F>мэйнстрим такой мэйнстрим..
И?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
C>Вы похоже совершенно не понимаете о чем речь? Вот у нас доменная модель на более сотни сущностей. Как со всей этой кухней работать без ОРМ и без объектов???
Здравствуйте, Константин Б., Вы писали:
КБ>>>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах? C>>>>Потому данные сами по себе в отрыве от доменной модели ценности не несут. КБ>>>Что есть по вашему "доменная модель" и почему для нее обязательно нужны объекты?
C>>Google в тооооом направлении --> C>>Объяснять элементарное и базовое не в моих принципах.
КБ>Я там уже был. Что из этого вы имеет ввиду.
http://en.wikipedia.org/wiki/Domain-driven_design
C>>>>O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д.
КБ>>>... и другие костыли, C>>Костыли?
КБ>Разве нет? В чем же профит от этих штук?
Ну разберитесь для начала что это за штуки, тогда сами поймете в чем же профит.
КБ>>>которые нужны если мы начинаем городить объекты. А если не создавать объекты, то это все и не нужно. C>>Мда... КБ>Не согласны?
Естественно.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
F>>>>4. Он не позволяет решать весь спектр задач. F>>>>Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом. C>>>Вот это Ваше сообщение порождено религиозными убеждениями, а не здравым смыслом.
C>>>Единственное, что не позволяет дотнет — писать драйверы. G>>Неправда, см Singularity. G>>Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС". C>Я в курсе про сингулярити. Но сингулярити это проект на бумаге, так что не вижу смысла его упоминать...
У кого-то на бумаге, а у меня на виртуалке очень даже запускается.
КБ>>>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
C>>Вы похоже совершенно не понимаете о чем речь? Вот у нас доменная модель на более сотни сущностей. Как со всей этой кухней работать без ОРМ и без объектов???
КБ>А в чем проблема то?
КБ>
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
F>>>это невозможно в принципе, т.к. оно заточено под одну платформу.. G>>И чем это мешает?
F>тем, что невозможно это применить во многих случаях.. с достаточной эффективностью..
В каких случаях, и что такое достаточная эффективность?
Здравствуйте, gandjustas, Вы писали:
C>>>>Единственное, что не позволяет дотнет — писать драйверы. G>>>Неправда, см Singularity. G>>>Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС". C>>Я в курсе про сингулярити. Но сингулярити это проект на бумаге, так что не вижу смысла его упоминать... G>У кого-то на бумаге, а у меня на виртуалке очень даже запускается.
Запускается — чудесно... Ну а дальше-то что?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>>>Главный плюс ОРМ — статическая типизация. Если ее нет, то зачем городить еще что-то поверх SQL? G>>>Нужно как-то преобразовывать результирующий recordset в объекты, а также изменения в объектах записывать в БД. G>>>Сам маппинг полей таблиц в свойства объектов уже давно является тривиальной задачей.
КБ>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах?
C>Потому данные сами по себе в отрыве от доменной модели ценности не несут.
Хм.. например вам нужно отобразить список заказов (номер и сумма) с именем клиента. Вы же не тянете для этого полный объект (domain object) заказа с объектом клиента и списком всех позичий заказа?
Здравствуйте, criosray, Вы писали:
C>>>Если речь о рациональном применении, то нет. Конечно не более широкое. Другое — да, более широкое — уж никак нет. F>>и, конечно же, этому есть подтверждение?. C>Сплошь и рядом. Весь корпоративный спектр приложений по-сути.
и?. где обещаная широта?.
F>>>>разница только в том, что плюсы не пихают куда только можно, а шарп пихают.. C>>>Это шутка такая?
F>>какие уж тут шутки?. десктоп, веб, игры и прочее.. везде туда пихают шарп.. C>Шарп в играх? Просвятите.
http://unity3d.com/unity/features/scripting
Красивая, интересная технология, но довольно спорная имхо.. Шарп там один из возможных средств разработки..
F>>мэйнстрим такой мэйнстрим.. C>И?
ничего в этом хорошего..
нас всегда учили, что инструмент выбирают под задачу, а не задачу под инструмент и уж тем более не затачивают инструмент для применения всегда и везде..
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Константин Б., Вы писали:
F>>>профит в инкапсуляции.. КБ>>Раскройте этот момент поподробнее. Инкапсуляции чего от чего.
F>инкапсуляция данных и средств работы с бд.. F>на всякий случай: F>
F>Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры?
КБ>>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
F>нет, мы приходим к вопросу "делать всё руками или автоматизировать?" F>ясен пень, можно всё сделать самому.. но зачем, если можно проще?.
Неправда. Ваш вариант — написать руками объекты и из них сгенерить CREATE TABLE. Мой — сразу написать CREATE TABLE. И там и там приходится писать руками.
Здравствуйте, gandjustas, Вы писали:
F>>>>это невозможно в принципе, т.к. оно заточено под одну платформу.. G>>>И чем это мешает? F>>тем, что невозможно это применить во многих случаях.. с достаточной эффективностью.. G>В каких случаях
в случаях, выходящих за эту единственную платформу
G>и что такое достаточная эффективность?
Здравствуйте, Anonim12, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>А сами то на FastCGI писали че-нить? A>Это не язык вообще-то.
Я знаю.
Как FastCGI помогает запустить "любой бинарник"?
A>А вы что, разве никогда консольных приложений не писали? Дотнет не позволяет так "низко" опуститься?
писал, FastCGI тут причем?
F>>инкапсуляция данных и средств работы с бд.. F>>на всякий случай: F>>
F>>Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
КБ>Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры?
Никто не предлагает работать с БД через интерфейс объекта. Почитайте про Repository патерн и про UnitOfWork патерн.
КБ>Неправда. Ваш вариант — написать руками объекты и из них сгенерить CREATE TABLE. Мой — сразу написать CREATE TABLE. И там и там приходится писать руками.
Перед тем, как что-то писать руками надо подумать головой. Преимущество Domain Driven Design в том, что оно позволяет сконцентрироваться непосредственно на решении бизнес задачи и домен это есть домен самой бизнес задачи. База с данными это всего-лишь бэкенд.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
S>>>>>Кстати говоря, ORM для C# тоже самописные (не Microsoft). VR>>>>Linq2SQL VR>>>>LinqToEntitites C>>>Это не ОРМ. VR>>>>ADO.NET Entity Framework C>>>Это ОРМ с натяжкой, т.к. data-centric подход. G>>ОРМом нынче считается только hibernate и похожие на него поделки? C>Не нынче, а всегда. ОРМ изобретался именно для domain-centric подхода, а МС зачем-то исказила идею и переиначила на более data-centric.
Кто сказал что ОРМ именно для этого предназначен?
Сам акроним ORM обозначает Object-Relational Mapper, что означает маппинг реляционных данных на объекты, это вообще говоря не обязывет иметь эти самые объекты в памяти и уж тем более наделять их каким-либо "поведением"
C>>>Вообще говоря, сравнивать питон/руби с дотнет это равносильно сравнению с 1С — ускоспециализированное с общего назначения. Про производительность и масштабируемость вообще и речи нет. Особенно, если смотреть на руби. G>>Непонятно как сравнивать язык и платформу, для который также есть реализация языка. G>>В отличие от 1С питон и руби являются языками общего назначения. C>Не являются.
Доказательства?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>>>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах? C>>>>>Потому данные сами по себе в отрыве от доменной модели ценности не несут. КБ>>>>Что есть по вашему "доменная модель" и почему для нее обязательно нужны объекты?
C>>>Google в тооооом направлении --> C>>>Объяснять элементарное и базовое не в моих принципах.
КБ>>Я там уже был. Что из этого вы имеет ввиду.
C>http://en.wikipedia.org/wiki/Domain-driven_design
Здорово. Только вот нигде там не увидел, что доменная модель — должна быть объектной моделью. Да и сама DDD — весьма спорная методология.
C>>>>>O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д. КБ>>>>... и другие костыли, C>>>Костыли? КБ>>Разве нет? В чем же профит от этих штук? C>Ну разберитесь для начала что это за штуки, тогда сами поймете в чем же профит.
Может вы тогда мне вообще не будете отвечать, чтобы не засорять форум? Я уверен обязательно найдется кто-то еще не настолько высокомерный, чтобы отвечать на мои вопросы.
Здравствуйте, Константин Б., Вы писали:
КБ>Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры?
они лежат на другом уровне..
F>>нет, мы приходим к вопросу "делать всё руками или автоматизировать?" F>>ясен пень, можно всё сделать самому.. но зачем, если можно проще?. КБ>Неправда. Ваш вариант — написать руками объекты и из них сгенерить CREATE TABLE. Мой — сразу написать CREATE TABLE. И там и там приходится писать руками.
в Вашем варианте точно так же надо будет писать руками структуры для хранения полученных данных..
если, конечно же, задача не сводится к "просто получить что то из базы"
Здравствуйте, gandjustas, Вы писали:
C>>Не нынче, а всегда. ОРМ изобретался именно для domain-centric подхода, а МС зачем-то исказила идею и переиначила на более data-centric. G>Кто сказал что ОРМ именно для этого предназначен?
Martin Fowler G>Сам акроним ORM обозначает Object-Relational Mapper, что означает маппинг реляционных данных на объекты, это вообще говоря не обязывет иметь эти самые объекты в памяти и уж тем более наделять их каким-либо "поведением"
При чем тут это?
C>>>>Вообще говоря, сравнивать питон/руби с дотнет это равносильно сравнению с 1С — ускоспециализированное с общего назначения. Про производительность и масштабируемость вообще и речи нет. Особенно, если смотреть на руби. G>>>Непонятно как сравнивать язык и платформу, для который также есть реализация языка. G>>>В отличие от 1С питон и руби являются языками общего назначения. C>>Не являются. G>Доказательства?
Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Бред в основном эксперты пишут. Я постоянно работаю с разными браузерами, так вот именно с помощью файерфокс большенство XSRF-атак можно выполнять, кроме того FF медленнее всех работает с DOM, очень часто падает на экзотических джаваскриптах. C>Про DOM это давно не так.
3 дня назад было так.
Простая анимация застваляла FF (и вторая и третья версия) хавать 30% cpu, остальные бразуеры не хавали больше 3 процентов. C>Про javascript — noscript рулит.
может и рулит, но FCKEditor (визивиг редактор) в каждом втором релизе валит одну из версий FF, а без него — никуда.
G>>К IE только две претензии: медленный и не очень соотвествует стандартам (до 8 версии) C>А что 8ка наконец соответствует стандартам? 6ка и 7ка это СУЩИЙ ужас для javascript разработчика. Посмотрите код ExtJs — СПЛОШНЫЕ костыли в js и css для IE...
Восьмерка в плане js вполне соотвествует.
G>>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, C>Не заметил.
А поставить себе восьмерку не пробовали?
Здравствуйте, criosray, Вы писали:
КБ>>Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры? C>Никто не предлагает работать с БД через интерфейс объекта. Почитайте про Repository патерн и про UnitOfWork патерн.
Почитал. Оба паттерна просто великолепно могут работать с кортежами.
КБ>>Неправда. Ваш вариант — написать руками объекты и из них сгенерить CREATE TABLE. Мой — сразу написать CREATE TABLE. И там и там приходится писать руками.
C>Перед тем, как что-то писать руками надо подумать головой. Преимущество Domain Driven Design в том, что оно позволяет сконцентрироваться непосредственно на решении бизнес задачи и домен это есть домен самой бизнес задачи. База с данными это всего-лишь бэкенд.
Нет не позволяет. Она предлагает выдумывать какие-то суррогатные сковзные сущности, вместо того чтобы обратить внимание на реальную модель данных и на реальные потоки данных.
КБ>>>Я там уже был. Что из этого вы имеет ввиду.
C>>http://en.wikipedia.org/wiki/Domain-driven_design
КБ>Здорово. Только вот нигде там не увидел, что доменная модель — должна быть объектной моделью.
Доменная модель по определению объектная модель.
C>>>>>>O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д. КБ>>>>>... и другие костыли, C>>>>Костыли? КБ>>>Разве нет? В чем же профит от этих штук? C>>Ну разберитесь для начала что это за штуки, тогда сами поймете в чем же профит.
КБ>Может вы тогда мне вообще не будете отвечать, чтобы не засорять форум? Я уверен обязательно найдется кто-то еще не настолько высокомерный, чтобы отвечать на мои вопросы.
Мне здесь не платят за чтение курса лекций. А Вы явно не понимаете о чем вообще речь. Разберетесь — обсудим, а пока не вижу смысла тратить время.
Здравствуйте, criosray, Вы писали:
C>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон.
я пользую штуки 3..
у остальных как то не спрашивал на чём они сделаны..
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>>>Единственное, что не позволяет дотнет — писать драйверы. G>>>>Неправда, см Singularity. G>>>>Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС". C>>>Я в курсе про сингулярити. Но сингулярити это проект на бумаге, так что не вижу смысла его упоминать... G>>У кого-то на бумаге, а у меня на виртуалке очень даже запускается. C>Запускается — чудесно... Ну а дальше-то что?
И драйверы там работают, на управляемом коде, аналоге .NEY, совсем не на бумаге
Здравствуйте, neFormal, Вы писали:
КБ>>Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры? F>они лежат на другом уровне..
А вон criosray предлагает паттерны Repository и UnitOfWork. Чем они хуже чем то что вы предлагаете? А ведь они такой инкапсуляции не требуют.
. КБ>>Неправда. Ваш вариант — написать руками объекты и из них сгенерить CREATE TABLE. Мой — сразу написать CREATE TABLE. И там и там приходится писать руками.
F>в Вашем варианте точно так же надо будет писать руками структуры для хранения полученных данных.. F>если, конечно же, задача не сводится к "просто получить что то из базы"
Ну вот из-за того что в питоне есть кортежи, никаких структур писать не надо )
Здравствуйте, gandjustas, Вы писали:
G>>>Бред в основном эксперты пишут. Я постоянно работаю с разными браузерами, так вот именно с помощью файерфокс большенство XSRF-атак можно выполнять, кроме того FF медленнее всех работает с DOM, очень часто падает на экзотических джаваскриптах. C>>Про DOM это давно не так. G>3 дня назад было так. G>Простая анимация застваляла FF (и вторая и третья версия) хавать 30% cpu, остальные бразуеры не хавали больше 3 процентов. C>>Про javascript — noscript рулит. G>может и рулит, но FCKEditor (визивиг редактор) в каждом втором релизе валит одну из версий FF, а без него — никуда.
Сколько пользуюсь FF — ни разу не видел.
G>>>К IE только две претензии: медленный и не очень соотвествует стандартам (до 8 версии) C>>А что 8ка наконец соответствует стандартам? 6ка и 7ка это СУЩИЙ ужас для javascript разработчика. Посмотрите код ExtJs — СПЛОШНЫЕ костыли в js и css для IE... G>Восьмерка в плане js вполне соотвествует.
Ок, будет время поковыряюсь...
G>>>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, C>>Не заметил. G>А поставить себе восьмерку не пробовали?
Да стоит RC1 — до FF ей как до неба.
Здравствуйте, neFormal, Вы писали:
F>http://unity3d.com/unity/features/scripting F>Красивая, интересная технология, но довольно спорная имхо.. Шарп там один из возможных средств разработки..
Съезжать не надо. unity3d на щарпе написана.
Здравствуйте, gandjustas, Вы писали:
C>>>>>>Единственное, что не позволяет дотнет — писать драйверы. G>>>>>Неправда, см Singularity. G>>>>>Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС". C>>>>Я в курсе про сингулярити. Но сингулярити это проект на бумаге, так что не вижу смысла его упоминать... G>>>У кого-то на бумаге, а у меня на виртуалке очень даже запускается. C>>Запускается — чудесно... Ну а дальше-то что? G>И драйверы там работают, на управляемом коде, аналоге .NEY, совсем не на бумаге
Да конечно же на бумаге, т.к. практического применения ей ровно ноль.
Здравствуйте, neFormal, Вы писали:
C>>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон.
F>я пользую штуки 3.. F>у остальных как то не спрашивал на чём они сделаны..
Названия?
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
F>>>>>это невозможно в принципе, т.к. оно заточено под одну платформу.. G>>>>И чем это мешает? F>>>тем, что невозможно это применить во многих случаях.. с достаточной эффективностью.. G>>В каких случаях F>в случаях, выходящих за эту единственную платформу
Ну и какие это случаи?
G>>и что такое достаточная эффективность? F>эффективность = rand()%вероятность_что_заработает * (проблемы/время)
Бредоваяы формула, проблемы в числителе, чем больше проблем -> тем больше эффективность.
Здравствуйте, criosray, Вы писали:
КБ>>>>Я там уже был. Что из этого вы имеет ввиду. C>>>http://en.wikipedia.org/wiki/Domain-driven_design КБ>>Здорово. Только вот нигде там не увидел, что доменная модель — должна быть объектной моделью. C>Доменная модель по определению объектная модель.
Ну я же просил привести ваше определение. А вы мне в место этого дали ссылку где написано прямо противоположное.
C>Мне здесь не платят за чтение курса лекций. А Вы явно не понимаете о чем вообще речь. Разберетесь — обсудим, а пока не вижу смысла тратить время.
Дык не тратьте. Считайте что я задаю вопросы в воздух. А вовсе не конкретно вам.
Здравствуйте, Константин Б., Вы писали:
КБ>>>Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры? F>>они лежат на другом уровне.. КБ>А вон criosray предлагает паттерны Repository и UnitOfWork. Чем они хуже чем то что вы предлагаете? А ведь они такой инкапсуляции не требуют.
его право.. каждый сам выбирает средства.. сравнивать не могу..
F>>в Вашем варианте точно так же надо будет писать руками структуры для хранения полученных данных.. F>>если, конечно же, задача не сводится к "просто получить что то из базы" КБ>Ну вот из-за того что в питоне есть кортежи, никаких структур писать не надо )
т.е. кортежи будут путешествовать по всему проекту и из них всё будет выниматься по индексу или распаковкой?.
ну, мб в этом есть какой то смысл, но он не по мне
Здравствуйте, Константин Б., Вы писали:
КБ>Ну вот из-за того что в питоне есть кортежи, никаких структур писать не надо )
1. Надо.
2. В дотнет тоже есть кортежи, ага. Только применения им очень мало. Так как не удобно. Так как поля должны быть именованы.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Не нынче, а всегда. ОРМ изобретался именно для domain-centric подхода, а МС зачем-то исказила идею и переиначила на более data-centric. G>>Кто сказал что ОРМ именно для этого предназначен? C>Martin Fowler
Это для вас авторитет?
Чаще всего они пишет то, что на данным момент неактуально. Кроме того многие его выводы сильно вызывают сомнение.
G>>Сам акроним ORM обозначает Object-Relational Mapper, что означает маппинг реляционных данных на объекты, это вообще говоря не обязывет иметь эти самые объекты в памяти и уж тем более наделять их каким-либо "поведением" C>При чем тут это?
При том что domain-centric подход совершенно необязателен. ОРМ — прежде всего удобство работы с данными.
C>>>>>Вообще говоря, сравнивать питон/руби с дотнет это равносильно сравнению с 1С — ускоспециализированное с общего назначения. Про производительность и масштабируемость вообще и речи нет. Особенно, если смотреть на руби. G>>>>Непонятно как сравнивать язык и платформу, для который также есть реализация языка. G>>>>В отличие от 1С питон и руби являются языками общего назначения. C>>>Не являются. G>>Доказательства? C>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон.
А причем тут десктоп приложения? Основная область применения скриптовых языков совершенно другая.
При этом написать десктоп приложение на руби или питоне вполне возможно, в отличие от веб-приложения на 1C.
Здравствуйте, Константин Б., Вы писали:
КБ>>>Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры? F>>они лежат на другом уровне..
КБ>А вон criosray предлагает паттерны Repository и UnitOfWork. Чем они хуже чем то что вы предлагаете? А ведь они такой инкапсуляции не требуют.
Может довольно эту ахинею нести? UoW и Repository это патерны основанные на использовании объектов. Но Вы конечно снова решили написать, не понимая о чем пишете.
КБ>. КБ>>>Неправда. Ваш вариант — написать руками объекты и из них сгенерить CREATE TABLE. Мой — сразу написать CREATE TABLE. И там и там приходится писать руками.
F>>в Вашем варианте точно так же надо будет писать руками структуры для хранения полученных данных.. F>>если, конечно же, задача не сводится к "просто получить что то из базы"
КБ>Ну вот из-за того что в питоне есть кортежи, никаких структур писать не надо )
Ну-ну.
Здравствуйте, criosray, Вы писали:
C>>>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон. F>>я пользую штуки 3.. F>>у остальных как то не спрашивал на чём они сделаны.. C>Названия?
gajim, eric..
в принципе еще есть blender, но это не моё..
консольные тулзы приводить смысла нет..
Здравствуйте, gandjustas, Вы писали:
F>>http://unity3d.com/unity/features/scripting F>>Красивая, интересная технология, но довольно спорная имхо.. Шарп там один из возможных средств разработки.. G>Съезжать не надо. unity3d на щарпе написана.
куда съезжать?. ты адекватен вообще?.
"один из" потому, что:
Unity supports three scripting languages: JavaScript, C#, and a dialect of Python called Boo.
Здравствуйте, gandjustas, Вы писали:
RO>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. G>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком.
Здравствуйте, gandjustas, Вы писали:
C>>>>Не нынче, а всегда. ОРМ изобретался именно для domain-centric подхода, а МС зачем-то исказила идею и переиначила на более data-centric. G>>>Кто сказал что ОРМ именно для этого предназначен? C>>Martin Fowler G>Это для вас авторитет?
Авторитет. G>Чаще всего они пишет то, что на данным момент неактуально. Кроме того многие его выводы сильно вызывают сомнение.
Да? Серьезно? MVC/MVP/UoW/ORM/DDD/DSL/AoP/DI/IoC и т.д. не актуально?..
Мдааааааа.
C>>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон. G>А причем тут десктоп приложения? Основная область применения скриптовых языков совершенно другая.
О чем и речь. G>При этом написать десктоп приложение на руби или питоне вполне возможно,
Нет, не возможно. Возможен интероп к низкоуровневой подсистеме.
Здравствуйте, neFormal, Вы писали: КБ>>А вон criosray предлагает паттерны Repository и UnitOfWork. Чем они хуже чем то что вы предлагаете? А ведь они такой инкапсуляции не требуют. F>его право.. каждый сам выбирает средства.. сравнивать не могу..
Почему не можете? Описания патернов здесь и здесь.
Очень хочу знать ваше мнение.
F>>>в Вашем варианте точно так же надо будет писать руками структуры для хранения полученных данных.. F>>>если, конечно же, задача не сводится к "просто получить что то из базы" КБ>>Ну вот из-за того что в питоне есть кортежи, никаких структур писать не надо )
F>т.е. кортежи будут путешествовать по всему проекту и из них всё будет выниматься по индексу или распаковкой?. F>ну, мб в этом есть какой то смысл, но он не по мне
Ну я понимаю что для большинства идея немного непривычная.
Здравствуйте, Константин Б., Вы писали:
F>>т.е. кортежи будут путешествовать по всему проекту и из них всё будет выниматься по индексу или распаковкой?. F>>ну, мб в этом есть какой то смысл, но он не по мне
КБ>Ну я понимаю что для большинства идея немного непривычная.
От чего бежали, к тому и прибежали. Добро пожаловать в 90ые.
Здравствуйте, Roman Odaisky, Вы писали:
RO>>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. G>>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. RO>И что?
Здравствуйте, Roman Odaisky, Вы писали:
RO>>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. G>>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком.
RO>И что?
Что значит что? Ваш тезис был опровергнут. Вот Вам и что.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>Ну вот из-за того что в питоне есть кортежи, никаких структур писать не надо ) C>1. Надо.
А зачем?
C>2. В дотнет тоже есть кортежи, ага. Только применения им очень мало. Так как не удобно. Так как поля должны быть именованы.
По вопросам необходимости ORM в дотнете это к IB и Cyberax'у ) Я говорю только о питоне.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>Бред в основном эксперты пишут. Я постоянно работаю с разными браузерами, так вот именно с помощью файерфокс большенство XSRF-атак можно выполнять, кроме того FF медленнее всех работает с DOM, очень часто падает на экзотических джаваскриптах. C>>>Про DOM это давно не так. G>>3 дня назад было так. G>>Простая анимация застваляла FF (и вторая и третья версия) хавать 30% cpu, остальные бразуеры не хавали больше 3 процентов. C>>>Про javascript — noscript рулит. G>>может и рулит, но FCKEditor (визивиг редактор) в каждом втором релизе валит одну из версий FF, а без него — никуда. C>Сколько пользуюсь FF — ни разу не видел.
Значит мало пользуетесь.
G>>>>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, C>>>Не заметил. G>>А поставить себе восьмерку не пробовали? C>Да стоит RC1 — до FF ей как до неба.
Ага, FF уже научился использовать Accelerators в полной мере и показывает web-slices.
Не смешите мои тапочки.
Здравствуйте, Константин Б., Вы писали:
КБ>>>Ну вот из-за того что в питоне есть кортежи, никаких структур писать не надо ) C>>1. Надо.
КБ>А зачем?
Затем, что с анонимными данными работать не возможно кроме самых приметивных случаев.
C>>2. В дотнет тоже есть кортежи, ага. Только применения им очень мало. Так как не удобно. Так как поля должны быть именованы.
КБ>По вопросам необходимости ORM в дотнете это к IB и Cyberax'у ) Я говорю только о питоне.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>>>>>Единственное, что не позволяет дотнет — писать драйверы. G>>>>>>Неправда, см Singularity. G>>>>>>Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС". C>>>>>Я в курсе про сингулярити. Но сингулярити это проект на бумаге, так что не вижу смысла его упоминать... G>>>>У кого-то на бумаге, а у меня на виртуалке очень даже запускается. C>>>Запускается — чудесно... Ну а дальше-то что? G>>И драйверы там работают, на управляемом коде, аналоге .NEY, совсем не на бумаге C>Да конечно же на бумаге, т.к. практического применения ей ровно ноль.
По вашей логике миллионы программ сущестуют "на бумаге", потому что вам от них толку ноль.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>>>Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры? F>>>они лежат на другом уровне..
КБ>>А вон criosray предлагает паттерны Repository и UnitOfWork. Чем они хуже чем то что вы предлагаете? А ведь они такой инкапсуляции не требуют. C>Может довольно эту ахинею нести? UoW и Repository это патерны основанные на использовании объектов. Но Вы конечно снова решили написать, не понимая о чем пишете.
Конечно не понимаю. Я не понимаю почему эти паттерны не могут быть использованы с кортежами.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
F>>>http://unity3d.com/unity/features/scripting F>>>Красивая, интересная технология, но довольно спорная имхо.. Шарп там один из возможных средств разработки.. G>>Съезжать не надо. unity3d на щарпе написана.
F>куда съезжать?. ты адекватен вообще?.
F>"один из" потому, что: F>
F>Unity supports three scripting languages: JavaScript, C#, and a dialect of Python called Boo.
Ты видимо неадекватен.
Этот фреймворк написан на шарпе, не дошло?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>>>Ну вот из-за того что в питоне есть кортежи, никаких структур писать не надо ) C>>>1. Надо. КБ>>А зачем? C>Затем, что с анонимными данными работать не возможно кроме самых приметивных случаев.
А какие сложности нас подстерегают на этом пути?
C>>>2. В дотнет тоже есть кортежи, ага. Только применения им очень мало. Так как не удобно. Так как поля должны быть именованы. КБ>>По вопросам необходимости ORM в дотнете это к IB и Cyberax'у ) Я говорю только о питоне. C>Да какая разница?
1. Кортежи в дотнете не так удобны.
2. ORM в дотнете и яве дает статическую типизацию. А это при всех недостатках, дает некоторый контроль времени компиляции и возможность использовать мощь VS+Resharper и IDEA.
Здравствуйте, gandjustas, Вы писали:
G>>>>>Бред в основном эксперты пишут. Я постоянно работаю с разными браузерами, так вот именно с помощью файерфокс большенство XSRF-атак можно выполнять, кроме того FF медленнее всех работает с DOM, очень часто падает на экзотических джаваскриптах. C>>>>Про DOM это давно не так. G>>>3 дня назад было так. G>>>Простая анимация застваляла FF (и вторая и третья версия) хавать 30% cpu, остальные бразуеры не хавали больше 3 процентов. C>>>>Про javascript — noscript рулит. G>>>может и рулит, но FCKEditor (визивиг редактор) в каждом втором релизе валит одну из версий FF, а без него — никуда. C>>Сколько пользуюсь FF — ни разу не видел. G>Значит мало пользуетесь.
Несколько лет, ежедневно, интенсивно. Ни разу не видел, чтоб какой-то там редактор завалил FF.
G>>>>>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, C>>>>Не заметил. G>>>А поставить себе восьмерку не пробовали? C>>Да стоит RC1 — до FF ей как до неба. G>Ага, FF уже научился использовать Accelerators
Зачем?
G>в полной мере и показывает web-slices.
Много вы видели сайтов с поддержкой этих самых веб слайсыс? G>Не смешите мои тапочки.
Давайте я еще посмешу Ваши тапочки: NoScript, AdBlock, Flashblock, Firebug, All-In-One Sidebar, Tab Mix Plus и т.д. и т.д.
КБ>1. Кортежи в дотнете не так удобны.
Ой ли? Честно-честно? Еще один пример того, что Вы вообще не знаете о чем говорите. КБ>2. ORM в дотнете и яве дает статическую типизацию.
Да при чем тут статическая типизация???? КБ>А это при всех недостатках, дает некоторый контроль времени компиляции и возможность использовать мощь VS+Resharper и IDEA.
Короче, я заканчиваю этот спор. Как разберетесь в вопросе — продолжим. Можете не тратить свое время на ответ.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>>>Не нынче, а всегда. ОРМ изобретался именно для domain-centric подхода, а МС зачем-то исказила идею и переиначила на более data-centric. G>>>>Кто сказал что ОРМ именно для этого предназначен? C>>>Martin Fowler G>>Это для вас авторитет? C>Авторитет.
Очень зря, своей головой думать надо.
G>>Чаще всего они пишет то, что на данным момент неактуально. Кроме того многие его выводы сильно вызывают сомнение. C>Да? Серьезно? MVC/MVP/UoW/ORM/DDD/DSL/AoP/DI/IoC и т.д. не актуально?.. C>Мдааааааа.
Фаулер про MVP и MVC писал когда такой подход использовали уже лет 10. Он только его попляризировал.
В своей знаменитой книге фаулер не привел описания современного (даже на тот момент) ORM, он только собрал в кучу причнципы, которые уже были использованы в существующих ORM.
C DI и IoC они описал в своей статье когда это были вполне зрелые, но неочень популярные подходы, принцип DI появился гораздо раньше.
Фактически фаулер ничего нового не придумал, и сомневаюсь что он участвовал в создании новых технологий, принципов итп.
В основном он играет роль популяризатора, но при этом дает не очень объективную оценку.
C>>>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон. G>>А причем тут десктоп приложения? Основная область применения скриптовых языков совершенно другая. C>О чем и речь. G>>При этом написать десктоп приложение на руби или питоне вполне возможно, C>Нет, не возможно. Возможен интероп к низкоуровневой подсистеме.
Если я напишу на IronRuby десктопное приложение это будет считаться?
Не очень понимаю критерии.
Вот на 1С с любым интеропом не получится веб-приложение.
Здравствуйте, gandjustas, Вы писали:
C>>>>>>Не нынче, а всегда. ОРМ изобретался именно для domain-centric подхода, а МС зачем-то исказила идею и переиначила на более data-centric. G>>>>>Кто сказал что ОРМ именно для этого предназначен? C>>>>Martin Fowler G>>>Это для вас авторитет? C>>Авторитет. G>Очень зря, своей головой думать надо.
Не понял какое отношение одно имеет к другому.
С чем конкретно Вы не согласны с Фаулером и почему?
G>>>Чаще всего они пишет то, что на данным момент неактуально. Кроме того многие его выводы сильно вызывают сомнение. C>>Да? Серьезно? MVC/MVP/UoW/ORM/DDD/DSL/AoP/DI/IoC и т.д. не актуально?.. C>>Мдааааааа. G>Фаулер про MVP и MVC писал когда такой подход использовали уже лет 10. Он только его попляризировал.
И что?
G>В своей знаменитой книге фаулер не привел описания современного (даже на тот момент) ORM, он только собрал в кучу причнципы, которые уже были использованы в существующих ORM.
И что?
G>C DI и IoC они описал в своей статье когда это были вполне зрелые, но неочень популярные подходы, принцип DI появился гораздо раньше.
И что?
G>Фактически фаулер ничего нового не придумал, и сомневаюсь что он участвовал в создании новых технологий, принципов итп.
И что??
G>В основном он играет роль популяризатора, но при этом дает не очень объективную оценку.
И что???
Файлер описал. Описал доступно и качественно. Какая проблема? В чем лично Вы не согласны с Фаулером? Этого я так и не понял...
C>>>>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон. G>>>А причем тут десктоп приложения? Основная область применения скриптовых языков совершенно другая. C>>О чем и речь. G>>>При этом написать десктоп приложение на руби или питоне вполне возможно, C>>Нет, не возможно. Возможен интероп к низкоуровневой подсистеме. G>Если я напишу на IronRuby десктопное приложение это будет считаться?
Нет конечно.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Andrei F., Вы писали:
AF>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
AF>>вопрос — а на что переходить?
S>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
Можешь официально вытянуть с Микрософта за бесплатно. Только писать в блокноте придётся.
Здравствуйте, criosray, Вы писали:
G>>>>>>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, C>>>>>Не заметил. G>>>>А поставить себе восьмерку не пробовали? C>>>Да стоит RC1 — до FF ей как до неба. G>>Ага, FF уже научился использовать Accelerators C>Зачем?
Не поверите, затем что они работу в инете ускоряют.
G>>в полной мере и показывает web-slices. C>Много вы видели сайтов с поддержкой этих самых веб слайсыс?
Много.
G>>Не смешите мои тапочки. C>Давайте я еще посмешу Ваши тапочки: NoScript, AdBlock, Flashblock, Firebug, All-In-One Sidebar, Tab Mix Plus и т.д. и т.д.
Скока страшных слов...
Здравствуйте, criosray, Вы писали:
КБ>>1. Кортежи в дотнете не так удобны. C>Ой ли? Честно-честно? Еще один пример того, что Вы вообще не знаете о чем говорите.
А само введение кортежей в дотнет вас не настораживает? Зачем по вашему их вообще туда ввели?
КБ>>2. ORM в дотнете и яве дает статическую типизацию. C>Да при чем тут статическая типизация???? КБ>>А это при всех недостатках, дает некоторый контроль времени компиляции и возможность использовать мощь VS+Resharper и IDEA. C>Короче, я заканчиваю этот спор. Как разберетесь в вопросе — продолжим. Можете не тратить свое время на ответ.
Ничего страшного. Вы уже не впервый раз его заканчиваете. А мне сейчас все равно нечем заняться.
Здравствуйте, gandjustas, Вы писали:
G>>>>>>>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, C>>>>>>Не заметил. G>>>>>А поставить себе восьмерку не пробовали? C>>>>Да стоит RC1 — до FF ей как до неба. G>>>Ага, FF уже научился использовать Accelerators C>>Зачем? G>Не поверите, затем что они работу в инете ускоряют.
Нет, не поверю. Потому, что в 99% случаев ничего они не ускоряют. Слишком уж слабая поддержка и ограниченное применение.
G>>>в полной мере и показывает web-slices. C>>Много вы видели сайтов с поддержкой этих самых веб слайсыс? G>Много.
Сотню назовете?
G>>>Не смешите мои тапочки. C>>Давайте я еще посмешу Ваши тапочки: NoScript, AdBlock, Flashblock, Firebug, All-In-One Sidebar, Tab Mix Plus и т.д. и т.д. G>Скока страшных слов...
Уже не смешно?
Здравствуйте, max-maxtor, Вы писали:
S>>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
MM>Можешь официально вытянуть с Микрософта за бесплатно. Только писать в блокноте придётся.
Ну почему же. Есть SharpDevelop, MonoDevelop и Vim.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>>>>>Не нынче, а всегда. ОРМ изобретался именно для domain-centric подхода, а МС зачем-то исказила идею и переиначила на более data-centric. G>>>>>>Кто сказал что ОРМ именно для этого предназначен? C>>>>>Martin Fowler G>>>>Это для вас авторитет? C>>>Авторитет. G>>Очень зря, своей головой думать надо. C>Не понял какое отношение одно имеет к другому.
См. ниже.
C>С чем конкретно Вы не согласны с Фаулером и почему?
не хочу расписывать, тема отдельного холивара.
C>Файлер описал. Описал доступно и качественно. Какая проблема? В чем лично Вы не согласны с Фаулером? Этого я так и не понял...
Еще раз. То что фаулер описал десяток существующих подходов не далеает его авторитетом и всегда правым в разработке ПО, поэтому верить каждому его слову, как вы делаете, не стоит.
C>>>>>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон. G>>>>А причем тут десктоп приложения? Основная область применения скриптовых языков совершенно другая. C>>>О чем и речь. G>>>>При этом написать десктоп приложение на руби или питоне вполне возможно, C>>>Нет, не возможно. Возможен интероп к низкоуровневой подсистеме. G>>Если я напишу на IronRuby десктопное приложение это будет считаться? C>Нет конечно.
а каков критерий десктопной программы сделанной на каком-то языке?
Здравствуйте, neFormal, Вы писали:
КБ>>Ничего страшного. Вы уже не впервый раз его заканчиваете. А мне сейчас все равно нечем заняться. F>примите участие в каком-нибудь python-проекте.. популяризуйте, так сказать
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>>>>>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, C>>>>>>>Не заметил. G>>>>>>А поставить себе восьмерку не пробовали? C>>>>>Да стоит RC1 — до FF ей как до неба. G>>>>Ага, FF уже научился использовать Accelerators C>>>Зачем? G>>Не поверите, затем что они работу в инете ускоряют. C>Нет, не поверю. Потому, что в 99% случаев ничего они не ускоряют. Слишком уж слабая поддержка и ограниченное применение.
Не надо верить, вы попробуйте.
G>>>>в полной мере и показывает web-slices. C>>>Много вы видели сайтов с поддержкой этих самых веб слайсыс? G>>Много. C>Сотню назовете?
Нет, я по меньшему колчичеству сайтов хожу.
G>>>>Не смешите мои тапочки. C>>>Давайте я еще посмешу Ваши тапочки: NoScript, AdBlock, Flashblock, Firebug, All-In-One Sidebar, Tab Mix Plus и т.д. и т.д. G>>Скока страшных слов... C>Уже не смешно?
Да все также смешно.
Чего вы доказать пытаетесь? Что у FF больше всего плагинов? Я это и так знаю.
Здравствуйте, gandjustas, Вы писали:
C>>С чем конкретно Вы не согласны с Фаулером и почему? G>не хочу расписывать, тема отдельного холивара.
Нет уж, извольте, раз начали.
C>>Файлер описал. Описал доступно и качественно. Какая проблема? В чем лично Вы не согласны с Фаулером? Этого я так и не понял... G>Еще раз. То что фаулер описал десяток существующих подходов не далеает его авторитетом и всегда правым в разработке ПО, поэтому верить каждому его слову, как вы делаете, не стоит.
Что значит верить? Можно быть согласным или несогласным. Вы не согласны — ваше право, но извольте описать конкретно с чем не согласны и почему.
На моей практике все основопологающие принципы, описанные Фоулером оказывались очень эффективными и удобными в разработке.
C>>>>>>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон. G>>>>>А причем тут десктоп приложения? Основная область применения скриптовых языков совершенно другая. C>>>>О чем и речь. G>>>>>При этом написать десктоп приложение на руби или питоне вполне возможно, C>>>>Нет, не возможно. Возможен интероп к низкоуровневой подсистеме. G>>>Если я напишу на IronRuby десктопное приложение это будет считаться? C>>Нет конечно. G>а каков критерий десктопной программы сделанной на каком-то языке?
Самодостаточность без необходимости интеропа к более низкоуровневой подсистеме.
Hi vit.rsdn
KV>>>1. Он слишком низкоуровневый. KV>>>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. KV>>>3. Он мешает развиваться дальше.
F>>4. Он не позволяет решать весь спектр задач. VR>в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально), дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
Точно? А то я, например, знаю проект, который ну никак не сделать на .NET. Причем не такой уж и сложный.
Здравствуйте, gandjustas, Вы писали:
G>>>>>>>>>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити, C>>>>>>>>Не заметил. G>>>>>>>А поставить себе восьмерку не пробовали? C>>>>>>Да стоит RC1 — до FF ей как до неба. G>>>>>Ага, FF уже научился использовать Accelerators C>>>>Зачем? G>>>Не поверите, затем что они работу в инете ускоряют. C>>Нет, не поверю. Потому, что в 99% случаев ничего они не ускоряют. Слишком уж слабая поддержка и ограниченное применение. G>Не надо верить, вы попробуйте.
Да я то пробовал. "Не смешите мои тапочки" (с)
G>>>>>в полной мере и показывает web-slices. C>>>>Много вы видели сайтов с поддержкой этих самых веб слайсыс? G>>>Много. C>>Сотню назовете? G>Нет, я по меньшему колчичеству сайтов хожу.
Ну назовите сколько можете.
G>>>>>Не смешите мои тапочки. C>>>>Давайте я еще посмешу Ваши тапочки: NoScript, AdBlock, Flashblock, Firebug, All-In-One Sidebar, Tab Mix Plus и т.д. и т.д. G>>>Скока страшных слов... C>>Уже не смешно? G>Да все также смешно. G>Чего вы доказать пытаетесь? Что у FF больше всего плагинов? Я это и так знаю.
Что у FF на порядок выше юзабилити.
Здравствуйте, criosray, Вы писали:
G>>>>>>Ага, FF уже научился использовать Accelerators C>>>>>Зачем? G>>>>Не поверите, затем что они работу в инете ускоряют. C>>>Нет, не поверю. Потому, что в 99% случаев ничего они не ускоряют. Слишком уж слабая поддержка и ограниченное применение. G>>Не надо верить, вы попробуйте. C>Да я то пробовал. "Не смешите мои тапочки" (с)
Ну если также как с EF, то можно не продолжать.
G>>>>>>в полной мере и показывает web-slices. C>>>>>Много вы видели сайтов с поддержкой этих самых веб слайсыс? G>>>>Много. C>>>Сотню назовете? G>>Нет, я по меньшему колчичеству сайтов хожу. C>Ну назовите сколько можете. http://www.ieaddons.com/en/webslices/?index=36&sort=Views&lang=en&browse=true
Для начала думаю хватит.
G>>>>>>Не смешите мои тапочки. C>>>>>Давайте я еще посмешу Ваши тапочки: NoScript, AdBlock, Flashblock, Firebug, All-In-One Sidebar, Tab Mix Plus и т.д. и т.д. G>>>>Скока страшных слов... C>>>Уже не смешно? G>>Да все также смешно. G>>Чего вы доказать пытаетесь? Что у FF больше всего плагинов? Я это и так знаю. C>Что у FF на порядок выше юзабилити.
NoScript, AdBlock, Flashblock каким образом влияют на юзабилити?
C>>>Файлер описал. Описал доступно и качественно. Какая проблема? В чем лично Вы не согласны с Фаулером? Этого я так и не понял... G>>Еще раз. То что фаулер описал десяток существующих подходов не далеает его авторитетом и всегда правым в разработке ПО, поэтому верить каждому его слову, как вы делаете, не стоит. C>Что значит верить? Можно быть согласным или несогласным. Вы не согласны — ваше право, но извольте описать конкретно с чем не согласны и почему. C>На моей практике все основопологающие принципы, описанные Фоулером оказывались очень эффективными и удобными в разработке.
и что? а если бы их описал не фаулер, вы бы продолжали также ему верить?
C>>>>>>>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон. G>>>>>>А причем тут десктоп приложения? Основная область применения скриптовых языков совершенно другая. C>>>>>О чем и речь. G>>>>>>При этом написать десктоп приложение на руби или питоне вполне возможно, C>>>>>Нет, не возможно. Возможен интероп к низкоуровневой подсистеме. G>>>>Если я напишу на IronRuby десктопное приложение это будет считаться? C>>>Нет конечно. G>>а каков критерий десктопной программы сделанной на каком-то языке? C>Самодостаточность без необходимости интеропа к более низкоуровневой подсистеме.
Черт, оказывается любой язык не является языком общего назначения, для всех требуется интероп к API операционной системы.
Только ассемблер — язык, на нем можно самодостаточную программу ниписать, остальные — не языки.
gandjustas однажды (8 марта 2009 17:06) писал в rsdn.flame.comp:
> RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего. > Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. > Для устройств на базе ARM или Blackfin есть .NET Micro Framework. > А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу).
А что из этого поддерживается микрософтом?
Здравствуйте, Sheridan, Вы писали:
S>gandjustas однажды (8 марта 2009 17:06) писал в rsdn.flame.comp:
>> RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего. >> Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. >> Для устройств на базе ARM или Blackfin есть .NET Micro Framework. >> А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу). S>А что из этого поддерживается микрософтом?
Все кроме моно.
criosray однажды (8 марта 2009 16:18) писал в rsdn.flame.comp:
> Ваши грубые и неумелые попытки троллинга несколько утомили. Потому просто -1.
Не нравится — не читай.
Это ты вставил сюда Александреску, чтоб обозначить свою принадлежность к «илите»? Что это за мода такая — поминать Андрея всуе, когда кто-то хочет толсто намикнуть, что он ни***ццо крутой плюсист? Тогда уж Абрахамса—Гуртового вставляй, их красная книжка позабористей.
F>и все будут тебе завидовать.. :))
Начинай мне завидовать.
F>изучи буст, покажи шаблонную магию им.Александреску..
А потом хоть краем глаза глянь на вменяемые языки и технологии, чтоб осознать костыльную природу Буста и «техник Александреску».
Здравствуйте, max-maxtor, Вы писали:
MM>Можешь официально вытянуть с Микрософта за бесплатно. Только писать в блокноте придётся.
есть же Visual Studio Express + SQL Server Express которые абсолютно бесплатны
Здравствуйте, neFormal, Вы писали:
F>правильно.. поэтому стоит обвинить в "lazy" всех шарперов, потому что они не хотят изучать внутренности буста..
Немалой своей частью шарперы — это те, кто уже изучил Буст, а потом перешёл на .NET, чтобы забыть этот Буст как страшный сон. Библиотеки в других языках призваны решать программистские проблемы, а Буст — языковые.
Здравствуйте, neFormal, Вы писали:
F>нет, тебя в пору пожалеть..
Изучение внутренностей Буста и тёмных углов C++ не более достойное занятие, чем разгрузка вагона с углём или перебирание гречки. К программированию не имеет никакого отношения. Я это занятие бросил, жаль, что недостаточно рано. Да, в этом смысле меня можно пожалеть.
Hi criosray
G>>>>Если я напишу на IronRuby десктопное приложение это будет считаться? C>>>Нет конечно. G>>а каков критерий десктопной программы сделанной на каком-то языке? C>Самодостаточность без необходимости интеропа к более низкоуровневой подсистеме.
Оооо, бедняга .NET. Ни одна .NET-ская программа не обходится без интеропа. Присто он там неявно торчит.
Или ты под самодостаточностью подразумевал интероп, который руками дергаешь? Тогда в Питоне с этим вполне нормально и такой необходимости особо и нет.
Hi criosray
C>>>>>Вообще говоря, сравнивать питон/руби с дотнет это равносильно сравнению с 1С — ускоспециализированное с общего назначения. Про производительность и масштабируемость вообще и речи нет. Особенно, если смотреть на руби. G>>>>Непонятно как сравнивать язык и платформу, для который также есть реализация языка. G>>>>В отличие от 1С питон и руби являются языками общего назначения. C>>>Не являются. G>>Доказательства? C>Много Вы видели десктоп приложений на пайтоне или руби? Я вот видел только одно на пайтоне и то, только частично было написано на пайтон.
Я лично одну десктопную прогу написал на питоне. Это была морда к серверу моей электронной библиотеки. Вся морда была сделана только на питоне. В качестве GUI-библиотеки использовался wxPython.
Здравствуйте, Qbit86, Вы писали:
F>>нет, тебя в пору пожалеть.. Q>Изучение внутренностей Буста и тёмных углов C++ не более достойное занятие, чем разгрузка вагона с углём или перебирание гречки. К программированию не имеет никакого отношения. Я это занятие бросил, жаль, что недостаточно рано. Да, в этом смысле меня можно пожалеть.
нет, тебя можно пожалеть только за то, что сейчас ты воюешь с ветряными мельницами
Hi criosray
AV>>Точно? А то я, например, знаю проект, который ну никак не сделать на .NET. Причем не такой уж и сложный.
C>Поделитесь знанием.
Я уже как-то приводил его в пример. Но еще раз можно.
Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках. Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang. И не хватало бы скорости. А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал.
gandjustas однажды (8 марта 2009 19:02) писал в rsdn.flame.comp:
>>> RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего. >>> Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. >>> Для устройств на базе ARM или Blackfin есть .NET Micro Framework. >>> А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу). > S>А что из этого поддерживается микрософтом? > Все кроме моно.
Тоесть шарп по большому счету тока под виндой. Приехали.
criosray однажды (8 марта 2009 17:57) писал в rsdn.flame.comp:
> RO>>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. > G>>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. > RO>И что? > Что значит что? Ваш тезис был опровергнут. Вот Вам и что.
А ты двулик однако.
То тебе опенсорц — дерьмо. То сам его предлагаеш пользовать.
Делаеш как тебе удобно? Ну я другого и не ожидал
S>The worm exploits a known vulnerability in the Windows Server service used by Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008, and the Windows 7 Beta
Ой-ой-ой. А вот здесь вы прочитали?
Или вы думаете, в Lin червей не бывает? Или time to patch у них существенно меньше?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, criosray, Вы писали:
RO>>>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. G>>>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. RO>>И что? C>Что значит что? Ваш тезис был опровергнут. Вот Вам и что.
Mono же не является полной реализацией .NET (это (почти) невозможно). Полноценно .NET работает только на одной платформе.
Здравствуйте, ambel-vlad, Вы писали:
L>>Немного не так: он привязан к 95% установленным ОС. ;) AV>Позволю еще одно уточнение. К 95% установленных десктопных ОС.
И то, это значило бы недооценить долю Мак ОС раза в два.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, shrecher, Вы писали:
L>>>C# не требует VS. Если очень хочется можешь работать с обычными текстовыми файлами и компилировать через командную строку. Просто в студии это делать удобнее.
S>>Да, но производительность написания кода резко упадет.
L>Конечно упадет. До уровня производительность написания кода на питоне.
нифига. На Питоне и C#+VS пишется примерно с одной и тойже скоростью. Вот если из связки C# VS убрать VS, то все — труба, погрязнешь в рутине.
Здравствуйте, Кывт, Вы писали:
К>Но вот мне надо разработать кроссплатформенное приложение, которое должно работать, в том числе, на Win CE и Symbian.
Широкий размах. Только каких-нибудь 6-битных криптопроцессоров со своими тараканами не хватает, для полного комплекта
К>Для C++ — гарантия есть, для C# — ?
Сильно зависит от того, что за приложение Вы делаете, и для каких конкретно платформ. Например, если там сплошной навороченный GUI, и всё должно работать на ведущих сотовых телефонах, то о Вашей мечте — "единости" code base — лучше забыть. И ваять под каждую платформу отдельно, на самых эффективных "родных" framework'ах/платформах соответствующего толка. В данном примере это будет J2ME для обычных мобил; Cocoa сотоварищи для iPhone; и на выбор .NET CF, либо native на C/C++ для Windows Mobile.
Здравствуйте, ambel-vlad, Вы писали:
AV>Оооо, бедняга .NET. Ни одна .NET-ская программа не обходится без интеропа. Присто он там неявно торчит. AV>Или ты под самодостаточностью подразумевал интероп, который руками дергаешь? Тогда в Питоне с этим вполне нормально и такой необходимости особо и нет.
Черт, ну как же это прикольно. Амбил-влад умеет говорить! Бедняга...
Здравствуйте, ambel-vlad, Вы писали:
AV>MxKazan, а сообщения несущие смысл умеешь писать?
Нет, ты что! Вот и обрадовался, что могу у тебя поучицца! А то все "сохласен / не сохласен"... А тут интероп. О. Сила
Здравствуйте, Qbit86, Вы писали:
Q>он ни***ццо крутой плюсист?
Он не ни***ццо крутой плюсист, он темплейтный псих.
Подрастающие с++сники будучи укушенными александреску творят жуткие непотребства.
Требуются месяцы рукоприкладства чтобы потом заставить их понять, что шаблоны надо применять только там где надо а не вообще везде.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Ага, FF уже научился использовать Accelerators в полной мере и показывает web-slices.
А что это и где на это можно посмотреть?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>>>Ага, FF уже научился использовать Accelerators C>>Зачем? G>Не поверите, затем что они работу в инете ускоряют.
Гм. И каким образом?
C>>Много вы видели сайтов с поддержкой этих самых веб слайсыс? G>Много.
Ссылку!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>>>Нет, я по меньшему колчичеству сайтов хожу. C>>Ну назовите сколько можете. G>http://www.ieaddons.com/en/webslices/?index=36&sort=Views&lang=en&browse=true G>Для начала думаю хватит.
Не, не хватит.
Что нить не микрософтовского авторства, пжалста.
G>NoScript, AdBlock, Flashblock каким образом влияют на юзабилити?
Они грохают эту $%#$@#скую рекламу которая просто задрала.
Без них серфить кошмарно неудобно.
Наличие качественной банерорезалки в браузере ИМХО просто must have.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, neFormal, Вы писали:
F>http://unity3d.com/unity/features/scripting F>Красивая, интересная технология, но довольно спорная имхо.. Шарп там один из возможных средств разработки..
Куда более интересно что на этом unity из игр релизнулось?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
RO>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. G>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком.
И я смогу под моно запустить прогу с WPF?
Ну или хотяб требующую FW 2.0?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, ambel-vlad, Вы писали:
AV>>MxKazan, а сообщения несущие смысл умеешь писать? MK>Нет, ты что! Вот и обрадовался, что могу у тебя поучицца! А то все "сохласен / не сохласен"... А тут интероп. О. Сила
Я понимаю, восьмое марта, праздник.
Но писать на форум "под шафе" пожалуй не стоит, прекращай.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
D>Сильно зависит от того, что за приложение Вы делаете, и для каких конкретно платформ. Например, если там сплошной навороченный GUI, и всё должно работать на ведущих сотовых телефонах, то о Вашей мечте — "единости" code base — лучше забыть. И ваять под каждую платформу отдельно, на самых эффективных "родных" framework'ах/платформах соответствующего толка.
Уже наваяли — есть и сложный нестандартный GUI (кроссплатформенный GUI engine) и единый codebase на C++ для всех платформ: Win XP, Win CE/Mobile, Symbian S60.
Планируется Linux, Android, iPhone, Blackberry OS, Web OS.
Под iPhone, конечно, придется, наверно писать UI на родном фреймворке, потому что пытаться переплюнуть интерфейс Айфона нет смысла.
Но если писать для каждой платформы полностью на ее родном фреймворке — где взять столько денег, чтобы нанять столько разработчиков? И как потом поддерживать такой огромный codebase с продублированной много раз функциональностью?
C++ уже меня изрядно достал, C# — замечательный язык, но мог бы я его использовать вместо C++ в своем проекте?
Здравствуйте, vit.rsdn, Вы писали:
VR>в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально), дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
Ваша неправда про ВЕСЬ спектр. Простейший контрпример: программа-инсталлятор на C#, которая как-то должна быть работоспособной при неустановленном .net. Если уж с такой простой задачей на нём не справится — то дальше и обсуждать нечего Про драйвера вообще молчу, впрочем если эта болезнь через годы доберётся и туда, Intel с AMD и производители памяти будут несказанно рады.
Здравствуйте, FirstStep, Вы писали:
FS>Здравствуйте, vit.rsdn, Вы писали: VR>>в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально), дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем) FS>Ваша неправда про ВЕСЬ спектр. Простейший контрпример: программа-инсталлятор на C#, которая как-то должна быть работоспособной при неустановленном .net. Если уж с такой простой задачей на нём не справится — то дальше и обсуждать нечего
С распространением новых Windows, эта отмазка становится всё менее значимой.
FS>Про драйвера вообще молчу, впрочем если эта болезнь через годы доберётся и туда, Intel с AMD и производители памяти будут несказанно рады.
Про драйвера можно и промолчать. Уверен, там есть места, где без ассемблера никак. Выходит любой язык приравнивается к нулю. Давайте не будем придумывать нечего нового, пока оно не повторяет полностью старое. И никого никогда не смущала радость nVidia и ATI при выходе очередных Квейков
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, criosray, Вы писали:
VR>>>но, для изучения всех этих ништяков, нужно приложить усилие, в следствии чего, многие lazy developers предпочтут питон,руби C>>Ну и славно, если так. Значит меньше низкопробных программистов останется на дотнет. Может и индусы перейдут на пайтон... Очень хотелось бы верить.
F>хочется побыть илитой?. F>изучи буст, покажи шаблонную магию им.Александреску.. и все будут тебе завидовать..
где-то слышал выражение, что магия отличается от колдовства/волшебства/ведовства тем, что маг не понимает сути магии. Просто знает, что каким словом вызвать что-то и все. Имхо, Александреску — это из колдовства
Здравствуйте, Кывт, Вы писали:
К>Уже наваяли — есть и сложный нестандартный GUI (кроссплатформенный GUI engine) и единый codebase на C++ для всех платформ: Win XP, Win CE/Mobile, Symbian S60.
Этого я и ожидал. И GUI engine, поди, самопальный ?
К>Под iPhone, конечно, придется, наверно писать UI на родном фреймворке,
А там, разве, по-другому получится ? UI же вроде только через Cocoa, никаких низкоуровневых чудес не выдаётся.
К>Но если писать для каждой платформы полностью на ее родном фреймворке — где взять столько денег, чтобы нанять столько разработчиков?
А Вам точно нужны все эти платформы ? И если нужны, то точно нужны все-здесь-и-прямо-сейчас ?
Я вот для такого зоопарка как-то слабо представляю consumer-приложение сочетающееся с Вашими требованиями. Обычно есть явно доминирующая платформа, с которой получаем доход, и тогда все остальные это о-малое. Либо это web-приложение должно быть.
А у Вас всё выглядит как системный компонент какой-то. А-ля видеокодек, или там даже framework. Ну так с них и доход совсем другим макаром и совсем другого масштаба получается, обычно. Путём лицензирования производителю собственно девайса/платформы.
К>И как потом поддерживать такой огромный codebase с продублированной много раз функциональностью?
Осторожно и аккуратно. С кучей тестов. Поддерживая единство не на уровне языка/платформы, а на более высоких: архитектура, форматы и т.п.
Да, это нетривиальная задача.
К>C++ уже меня изрядно достал, C# — замечательный язык, но мог бы я его использовать вместо C++ в своем проекте?
Здравствуйте, shrecher, Вы писали:
L>>Я так понимаю, Linq2Sql, Linq2Entities вы за ORM не считаете?
S>О такой экзотике я даже не слышал, но думаю, не сравнить с hibernate.
Тот факт, что эта "экзотика" является частью стандартного фреймворка говорит лишь о твоей неспособности адекватно оценивать фреймворк ввиду незнания предмета.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi criosray
AV>>>Точно? А то я, например, знаю проект, который ну никак не сделать на .NET. Причем не такой уж и сложный.
C>>Поделитесь знанием.
AV>Я уже как-то приводил его в пример. Но еще раз можно.
AV>Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках. Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang. И не хватало бы скорости. А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал.
Я вообще не уверен что вас что-то спасет при такой архитектуре. Посмотрите на IIS старых версий, ISAPI — фильтры можно писать на любом языке, который может быть скомпилен в DLL и экспортировать некоторые функции, но это приводит к тому что любая ошибка в фильтре валит app pool, любая дыра в безопасности позволяет получить доступ к целевой системе. Хотя сама выгода от писания на любом языке очень призрачна, ведь реально для разработки приложения для какого-то самописного аппсервера будет использоваться всего пара языков.
Гораздо лучший путь не писать аппсервер, а писать приложение так, чтобы абсолютно пофиг было что используется для реализации компонент. SOA для этого подходит идеально.
Здравствуйте, Кывт, Вы писали:
К>Это все очень здорово, что так много всего есть.
К>Но вот мне надо разработать кроссплатформенное приложение, которое должно работать, в том числе, на Win CE и Symbian.
К>Речь идет о реальных деньгах, вложенных в проект, которыми нельзя рисковать. Если ничего не выйдет — стартапу крышка. К>Могу ли я реально использовать C#, имея гарантию, что все получится и будет работать нормально? К>Для C++ — гарантия есть, для C# — ?
.NET CF вроде как нету для Symbian (поправьте ели ошибаюсь), поэтому не ломайте голову и делайте на С++.
Здравствуйте, Sheridan, Вы писали:
S>gandjustas однажды (8 марта 2009 19:02) писал в rsdn.flame.comp:
>>>> RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего. >>>> Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. >>>> Для устройств на базе ARM или Blackfin есть .NET Micro Framework. >>>> А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу). >> S>А что из этого поддерживается микрософтом? >> Все кроме моно. S>Тоесть шарп по большому счету тока под виндой. Приехали.
А можешь написать цепочку умозаключений, позволяющих сделать такой вывод?
Мне кажется что ты (очередной раз) бредятину написал.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, criosray, Вы писали:
RO>>>>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. G>>>>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. RO>>>И что? C>>Что значит что? Ваш тезис был опровергнут. Вот Вам и что.
RO>Mono же не является полной реализацией .NET (это (почти) невозможно). Полноценно .NET работает только на одной платформе.
Смотря что надо от "полноценной" работы. Весь комплект enterprise фич платформы MS не станет портировать на другие ОС, иначе сильно потеряет позиции на рынке ОС.
С другой стороны оно и не нужно, ведь для крупного enterprise решения цена ОС имеет малое значение, а для мелочи можно и бесплатный Windows Web Server взять.
Сила Моно состоит именно в десктопных приложениях, там где реально нужна кроссплатформенность. А для десктопа 100% фич .NET и не нужно, даже MS это понимает создавая .NET Client Profile (20 метров всего)
ЗЫ. Для очень большой части всех приложений для полноценной работы за глаза хватает web-интерфейса с аяксом, которому пофиг что за технология на сервере.
Здравствуйте, shrecher, Вы писали:
S>Этого достаточно, чтобы минимизировать использование продуктов MS.
Я правильно понимаю, что тебе достаточно одной фразы из интервью, чтобы принимать решение о целесообразности использования тех или иных продуктов в своем бизнесе?
Здравствуйте, gandjustas, Вы писали:
KV>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит. G>Это еще надо обосновать. Если C# низкоуровневый, то какой язык высокоуровневый?
Разумеется тот, который предоставляет разработчику более широкий набор высокоуровневых абстракций
KV>>3. Он мешает развиваться дальше. Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников. G>Ну сразу бы написал что "Прогрммист должен каждый год изучать новый язык (а лучше два)", было бы правильнее.
Ну, я пытался донести несколько другую мысль, но все же спрошу: разве программист (да вообще, любой профессионал) не должен развиваться, чтобы поддерживать свой уровень?
Здравствуйте, vit.rsdn, Вы писали:
KV>>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
KV>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
VR>найдите время, пожалуйста, расписать подробнее VR>пока не совсем очевидно
Ок. Какие конкретно абстракции, из доступных разработчику на C#, реализует и поддерживает язык, а не сама платформа?
KV>>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. Низкий порог для вхождения -> высокий порог для использования языка в полной мере -> и toSheridan: why so serious?
уже не кажется таким уж забавным, по сравнению с тем, что иногда встречаешь в шарповском коде, написанным профессиональными разработчиками при ревью
VR>такие "пёрлы" чаще встречаются у разработчиков на других языках/платформах VR>увы.
Хорошо, пусть так. Но это не значит, что в С# эта проблема отсуствует, нет?
KV>>3. Он мешает развиваться дальше. Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников. VR>C#1.0 C#3.0 — это по сути, достаточно разные языки. C# 4.0, F# — это ли не интесивное развитие?
А с какого бока тут F#?
VR>причем, такое развитие, что,кажется, я сишарп начну с нуля изучать! VR>и, для желающих, в дотнете есть IronRuby/IronPython
Все, что я тут написал, я написал относительно одного языка, а не платформы.
KV>>Ну вот собственно и все VR>эээээээ, нет VR>сегодня 8 Марта VR>надо поздравлять любимых VR>а вот завтра ждётся обстоятельное объяснение вашей аргументации
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего.
Во-первых, речь шла о том, чтобы помимо использования C# изучать еще и другие языки. И я думаю, что для тех, кто УЖЕ пишет на С#, его привязка к ОС глубоко параллельна. А во-вторых, он не привязан к ОС, как уже написали выше.
Здравствуйте, Roman Odaisky, Вы писали:
C>>Что значит что? Ваш тезис был опровергнут. Вот Вам и что.
RO>Mono же не является полной реализацией .NET (это (почти) невозможно). Полноценно .NET работает только на одной платформе.
Как ты быстро с заявления о том, что С# (язык) привязан к винде, перескочил к привязке к винде всей .NET (в т.ч. и FCL) C# 3.0 к платформе не привязан, и на нем ты можешь писать и под mono.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
RO>>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. G>>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. CC>И я смогу под моно запустить прогу с WPF?
Здравствуйте, Sheridan, Вы писали:
S>gandjustas однажды (8 марта 2009 19:02) писал в rsdn.flame.comp:
>>>> RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего. >>>> Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. >>>> Для устройств на базе ARM или Blackfin есть .NET Micro Framework. >>>> А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу). >> S>А что из этого поддерживается микрософтом? >> Все кроме моно. S>Тоесть шарп по большому счету тока под виндой. Приехали.
Шеридан, вот можешь мне на пальцах объяснить свою логику? С одной стороны, ты как ярый сторонник опенсорса, ратуешь за то, чтобы стандарты были открытыми, дабы сообщество, в лучших традициях опенсорса могло принимать участие в разработке их реализаций. С другой стороны, ты утверждаешь, что моно (построенное по открытым стандартам) должно поддерживаться именно микрософтом и ничем другим. Где тут логика?
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, shrecher, Вы писали:
L>>>>C# не требует VS. Если очень хочется можешь работать с обычными текстовыми файлами и компилировать через командную строку. Просто в студии это делать удобнее.
S>>>Да, но производительность написания кода резко упадет.
L>>Конечно упадет. До уровня производительность написания кода на питоне.
S>нифига. На Питоне и C#+VS пишется примерно с одной и тойже скоростью. Вот если из связки C# VS убрать VS, то все — труба, погрязнешь в рутине.
Это вы сравниваете скорость написания текста?
Конечно для динамического языка скорость написания текста выше, многие ошибки будут выявлены только в рантайме.
Для языков со статической типизацией время написания текста чуть больше, потому что программист должен позаботиться о соотвествии типов, продумать интерфейсы и прочее.
При росте размера проекта время написания программы (с отладкой, тестированием и пр.) для динамических языков растет гораздо быстрее.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>>>Ага, FF уже научился использовать Accelerators C>>>Зачем? G>>Не поверите, затем что они работу в инете ускоряют. CC>Гм. И каким образом?
Банально меньше кликов и более быстрый доступ к нужной инфе.
C>>>Много вы видели сайтов с поддержкой этих самых веб слайсыс? G>>Много. CC>Ссылку! http://www.ieaddons.com/en/webslices/?index=36&sort=Views&lang=en&browse=true
gandjustas однажды (9 марта 2009 00:43) писал в rsdn.flame.comp:
>>>>> RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего. >>>>> Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. >>>>> Для устройств на базе ARM или Blackfin есть .NET Micro Framework. >>>>> А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу). >>> S>А что из этого поддерживается микрософтом? >>> Все кроме моно. > S>Тоесть шарп по большому счету тока под виндой. Приехали. > А можешь написать цепочку умозаключений, позволяющих сделать такой вывод? > Мне кажется что ты (очередной раз) бредятину написал.
Друг мой. Не тупи. Ты же сам сказал что моно микрософтом не поддерживается.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Шеридан, вот можешь мне на пальцах объяснить свою логику? С одной стороны, ты как ярый сторонник опенсорса, ратуешь за то, чтобы стандарты были открытыми, дабы сообщество, в лучших традициях опенсорса могло принимать участие в разработке их реализаций.
.NET — он по большей части не стандартизован. Только небольшая часть его находится в стандарте ISO.
Так что почти любая программа на .NET на практике привязана к Windows.
kochetkov.vladimir однажды (9 марта 2009 00:52) писал в rsdn.flame.comp:
> Шеридан, вот можешь мне на пальцах объяснить свою логику? С одной стороны, ты как ярый сторонник опенсорса, ратуешь за то, чтобы стандарты были открытыми, дабы сообщество, в > лучших традициях опенсорса могло принимать участие в разработке их реализаций. С другой стороны, ты утверждаешь, что моно (построенное по открытым стандартам) должно > поддерживаться именно микрософтом и ничем другим. Где тут логика?
Ты не понял. Моно — дерьмо.
Здравствуйте, FirstStep, Вы писали:
FS>Здравствуйте, vit.rsdn, Вы писали:
VR>>в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально), дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
FS>Ваша неправда про ВЕСЬ спектр. Простейший контрпример: программа-инсталлятор на C#, которая как-то должна быть работоспособной при неустановленном .net. Если уж с такой простой задачей на нём не справится — то дальше и обсуждать нечего
А ему и не надо справляться, есть msi, его с головой хватает. Свой инсталлятор писать незачем.
FS>Про драйвера вообще молчу, впрочем если эта болезнь через годы доберётся и туда, Intel с AMD и производители памяти будут несказанно рады.
Дык уже там. Смотри Singularity.
В архитектуре современных ОС нету возможности использовать дрова на управляемом коде, но это не является недостатком платформы или языка.
Здравствуйте, Sheridan, Вы писали:
>> Шеридан, вот можешь мне на пальцах объяснить свою логику? С одной стороны, ты как ярый сторонник опенсорса, ратуешь за то, чтобы стандарты были открытыми, дабы сообщество, в >> лучших традициях опенсорса могло принимать участие в разработке их реализаций. С другой стороны, ты утверждаешь, что моно (построенное по открытым стандартам) должно >> поддерживаться именно микрософтом и ничем другим. Где тут логика? S>Ты не понял. Моно — дерьмо.
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Кывт, Вы писали:
К>>Уже наваяли — есть и сложный нестандартный GUI (кроссплатформенный GUI engine) и единый codebase на C++ для всех платформ: Win XP, Win CE/Mobile, Symbian S60. D>Этого я и ожидал. И GUI engine, поди, самопальный ?
К>>Под iPhone, конечно, придется, наверно писать UI на родном фреймворке, D>А там, разве, по-другому получится ? UI же вроде только через Cocoa, никаких низкоуровневых чудес не выдаётся.
К>>Но если писать для каждой платформы полностью на ее родном фреймворке — где взять столько денег, чтобы нанять столько разработчиков? D>А Вам точно нужны все эти платформы ? И если нужны, то точно нужны все-здесь-и-прямо-сейчас ? D>Я вот для такого зоопарка как-то слабо представляю consumer-приложение сочетающееся с Вашими требованиями. Обычно есть явно доминирующая платформа, с которой получаем доход, и тогда все остальные это о-малое. Либо это web-приложение должно быть. D>А у Вас всё выглядит как системный компонент какой-то. А-ля видеокодек, или там даже framework. Ну так с них и доход совсем другим макаром и совсем другого масштаба получается, обычно. Путём лицензирования производителю собственно девайса/платформы.
К>>И как потом поддерживать такой огромный codebase с продублированной много раз функциональностью? D>Осторожно и аккуратно. С кучей тестов. Поддерживая единство не на уровне языка/платформы, а на более высоких: архитектура, форматы и т.п. D>Да, это нетривиальная задача.
К>>C++ уже меня изрядно достал, C# — замечательный язык, но мог бы я его использовать вместо C++ в своем проекте? D>Аналогичным образом — не можете, разумеется.
А что вы удивляетесь. Такой подход среди "приплюснутых" программистов встречается очень часто. Понавыдумывают себе проблем и геройски их решают с помощью C++. А самые продвинутые в С++ даже не знают что эти проблемы уже решены кучей других способов кроме написания своего кроссплатформенного фреймворка.
Здравствуйте, Sheridan, Вы писали:
S>gandjustas однажды (9 марта 2009 00:43) писал в rsdn.flame.comp:
>>>>>> RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего. >>>>>> Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. >>>>>> Для устройств на базе ARM или Blackfin есть .NET Micro Framework. >>>>>> А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу). >>>> S>А что из этого поддерживается микрософтом? >>>> Все кроме моно. >> S>Тоесть шарп по большому счету тока под виндой. Приехали. >> А можешь написать цепочку умозаключений, позволяющих сделать такой вывод? >> Мне кажется что ты (очередной раз) бредятину написал. S>Друг мой. Не тупи. Ты же сам сказал что моно микрософтом не поддерживается.
И что?
Программы на моно отлично работают. А с C# там гораздо лучше, чем у MS. Там как минимум есть repl для C#, который MS только разрабатывает.
Hi gandjustas
AV>>>>Точно? А то я, например, знаю проект, который ну никак не сделать на .NET. Причем не такой уж и сложный.
C>>>Поделитесь знанием.
AV>>Я уже как-то приводил его в пример. Но еще раз можно.
AV>>Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках. Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang. И не хватало бы скорости. А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал.
G>Я вообще не уверен что вас что-то спасет при такой архитектуре. Посмотрите на IIS старых версий, ISAPI — фильтры можно писать на любом языке, который может быть скомпилен в DLL и экспортировать некоторые функции, но это приводит к тому что любая ошибка в фильтре валит app pool, любая дыра в безопасности позволяет получить доступ к целевой системе.
Не, спасибо. Во-первых, уже поздно. Проект успешно развивается. Во-вторых, данная модель абсолютно не подходит под требования заказчика.
G>Хотя сама выгода от писания на любом языке очень призрачна, ведь реально для разработки приложения для какого-то самописного аппсервера будет использоваться всего пара языков.
Кол-во языков заранее неизвестно было. Причем по ходу развития проекта новые языки могут добавляться. На данный момент на этом сервере крутятся приложения написанные на .NET, Java, Python, Ruby и старые знакомые C/C++. И это, при необходимости, можно спокойно все смешивать в одном приложении.
Знаю что заказчик играется еще и с OCaml.
G>Гораздо лучший путь не писать аппсервер, а писать приложение так, чтобы абсолютно пофиг было что используется для реализации компонент. SOA для этого подходит идеально.
Если это возможно, то можно посмотреть и в эту сторону. А если нет?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Шеридан, вот можешь мне на пальцах объяснить свою логику? С одной стороны, ты как ярый сторонник опенсорса, ратуешь за то, чтобы стандарты были открытыми, дабы сообщество, в лучших традициях опенсорса могло принимать участие в разработке их реализаций. C>.NET — он по большей части не стандартизован. Только небольшая часть его находится в стандарте ISO.
.NET стандартизоват ISO? Я думал стандартизацией .NET ecma занимается.
Да и стандартизовано там только язык — C#, рантайм — CLR и вроде как связанная с ней часть библиотеки, называемая CLI.
C>Так что почти любая программа на .NET на практике привязана к Windows.
Вы так говорите как-будто mono не существует и Silverlight не запускается под маком.
Здравствуйте, Sheridan, Вы писали:
S>kochetkov.vladimir однажды (9 марта 2009 00:52) писал в rsdn.flame.comp:
>> Шеридан, вот можешь мне на пальцах объяснить свою логику? С одной стороны, ты как ярый сторонник опенсорса, ратуешь за то, чтобы стандарты были открытыми, дабы сообщество, в >> лучших традициях опенсорса могло принимать участие в разработке их реализаций. С другой стороны, ты утверждаешь, что моно (построенное по открытым стандартам) должно >> поддерживаться именно микрософтом и ничем другим. Где тут логика? S>Ты не понял. Моно — дерьмо.
Меня, почему-то, такой ответ с твоей стороны, совершенно не удивил
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>>>Точно? А то я, например, знаю проект, который ну никак не сделать на .NET. Причем не такой уж и сложный.
C>>>>Поделитесь знанием.
AV>>>Я уже как-то приводил его в пример. Но еще раз можно.
AV>>>Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках. Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang. И не хватало бы скорости. А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал.
G>>Я вообще не уверен что вас что-то спасет при такой архитектуре. Посмотрите на IIS старых версий, ISAPI — фильтры можно писать на любом языке, который может быть скомпилен в DLL и экспортировать некоторые функции, но это приводит к тому что любая ошибка в фильтре валит app pool, любая дыра в безопасности позволяет получить доступ к целевой системе.
AV>Не, спасибо. Во-первых, уже поздно. Проект успешно развивается. Во-вторых, данная модель абсолютно не подходит под требования заказчика.
И что за такие нереальные требования у заказчика, что надо свой аппсервер писать?
G>>Хотя сама выгода от писания на любом языке очень призрачна, ведь реально для разработки приложения для какого-то самописного аппсервера будет использоваться всего пара языков. AV>Кол-во языков заранее неизвестно было. Причем по ходу развития проекта новые языки могут добавляться. На данный момент на этом сервере крутятся приложения написанные на .NET, Java, Python, Ruby и старые знакомые C/C++. И это, при необходимости, можно спокойно все смешивать в одном приложении.
Сильно сомневаюсь что удастся запустить рантайм разных версий .NET в одном процессе.
G>>Гораздо лучший путь не писать аппсервер, а писать приложение так, чтобы абсолютно пофиг было что используется для реализации компонент. SOA для этого подходит идеально. AV>Если это возможно, то можно посмотреть и в эту сторону. А если нет?
Сложно пирумать случай когда это невозможно.
Может быть только из соображений быстродейсвтия, но для таких систем скорость обработки одного запроса мало значения имеет, а возможности масштабирования (наращивания пропускной способности) при SOA гораздо выше.
Здравствуйте, criosray, Вы писали:
KV>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит. C>oO Вы шутите? Скажите, что шутите... и не пугайте больше так.
А что пугает?
KV>>3. Он мешает развиваться дальше. C>Каким образом мешает-то? Наоборот, я уверен, многие про те же лямбды узнали только благодаря С#.
На мой взгляд, по перечисленным в исходном сообщении причинам, он создает иллюзию отсутствия необходимости в дальнейшем развитии разработчика при том, что арсенал средств, предоставляемых шарпом не такой уж и богатый.
KV>>Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников. C>10 лет назад я был "оголтелым плюсником"
А какие лет 10 назад были альтернативы?
KV>>Ну вот собственно и все C>Так а чего "слазить надо"? Я так и не понял...
Да я видимо рановато обронил эту фразу, мне еще тяжело четко сформулировать свою т.з., при всей моей словоохотливости Последний год, я довольно много времени посвящал изучению различных средств, отсутствующих/отсутствовавших/неразвитых в шарпе. Метапрограммирование, вывод типов, неизменяемые объекты, динамическая типизация, азы функционального программирования, и т.п. Столько средств, позволяющих действительно улучшить свой код, сделать его более эффективным, читаемым... Средств, о существовании которых, пару лет назад, я даже и не подозревал, считая что шарп полностью покрывает все мои потребности. И теперь, когда мне приходится писать или читать код на нем, я ощущаю неслабый дискомфорт от периодической нехватки/неразвитости в шарпе тех или иных языковых средств, с которыми я успел познакомиться. Я написал не так уж и много кода за последние несколько лет, по сравнению с профессиональными программерами, т.к. в силу своей специализации я все больше читаю, нежели пишу. Но сейчас я отчетливо вижу в своем старом коде места, которые я бы переписал на том же шарпе, куда более грамотно и качественно под влиянием других языков. А значит время на их изучение было потрачено не зря и об этом стоит рассказать здесь. Вдруг это поможет кому-нибудь еще открыть для себя новые горизонты развития?
Здравствуйте, x64, Вы писали:
KV>>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. Низкий порог для вхождения -> высокий порог для использования языка в полной мере -> ...
x64>А вот это мне непонятно, в смысле а зачем использовать его в полной мере?
Ну, чтобы не городить кучу if'ов вместо switch, например
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
Не, ну что за народ? Черным по белому читают выделенное, и тут же уточняют:
AF>вопрос — а на что переходить?
Hi gandjustas
AV>>>>>>Точно? А то я, например, знаю проект, который ну никак не сделать на .NET. Причем не такой уж и сложный.
C>>>>>Поделитесь знанием.
AV>>>>Я уже как-то приводил его в пример. Но еще раз можно.
AV>>>>Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках. Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang. И не хватало бы скорости. А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал.
G>>>Я вообще не уверен что вас что-то спасет при такой архитектуре. Посмотрите на IIS старых версий, ISAPI — фильтры можно писать на любом языке, который может быть скомпилен в DLL и экспортировать некоторые функции, но это приводит к тому что любая ошибка в фильтре валит app pool, любая дыра в безопасности позволяет получить доступ к целевой системе.
AV>>Не, спасибо. Во-первых, уже поздно. Проект успешно развивается. Во-вторых, данная модель абсолютно не подходит под требования заказчика. G>И что за такие нереальные требования у заказчика, что надо свой аппсервер писать?
Ну там было совсем весело. Первоначально это была лишь часть совсем другого проекта. Необходимо было сделать инфраструктуру на базе которой будет все остальное крутиться. А потом, по мере развития было решено выделить это все в отдельный проект.
G>>>Хотя сама выгода от писания на любом языке очень призрачна, ведь реально для разработки приложения для какого-то самописного аппсервера будет использоваться всего пара языков. AV>>Кол-во языков заранее неизвестно было. Причем по ходу развития проекта новые языки могут добавляться. На данный момент на этом сервере крутятся приложения написанные на .NET, Java, Python, Ruby и старые знакомые C/C++. И это, при необходимости, можно спокойно все смешивать в одном приложении. G>Сильно сомневаюсь что удастся запустить рантайм разных версий .NET в одном процессе.
Вопрос был в том, какие средства предоставляет питон в сравнении с RoR и про ORM.
А если сравнивать сайты по количеству, то PHP порвет всех.
v> для особых любителей питона, можно и под дотнет Django запустить Microsoft shows Django running on IronPython
Здравствуйте, gandjustas, Вы писали:
g> Вы так говорите как-будто mono не существует g> Не надо выдавать желаемое за действительное.
Он существует, но как Неуловимый Джо. Вроде и есть, но мало кому нужен. Связано это как с большими рисками в отношении лицензионной политики MS (фиг знает, что им придет завтра в голову), так и с отсутствием реальной кросс-платформенности.
Здравствуйте, Константин Б., Вы писали: КБ>А какие сложности нас подстерегают на этом пути?
Как это какие?
Элементарные сложности: где-то берем и меняем определение этих "анонимных данных". Например, вставили в [0] поле "Title", после которого пойдут FirstName и LastName, которые раньше были 0-м и 1-м. Весь код, построенный на индексах, поедет.
К примеру, что код, который формирует строку обращения к персоне, не хочется писать вот так:
Кто будет этот код маинтейнить? Как отследить при удалении поля, где какой код на него ссылается?
Если у Питона есть какой-то ответ на эти простые вопросы, я его с удовольствием выслушаю.
Пока что всё что я видел — это быстрое построение приложений в стиле "универсальный редактор DBF-файлов". К сожалению, приложения этого типа я закончил писать (для десктопа) примерно году в 1994 — разочаровался в концепции. То, что сейчас dbedit сумели засунуть в веб, меня нисколько не возбуждает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ambel-vlad, Вы писали:
AV>Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках.
Каких именно? Неужели у вас серъезную долю рынка "частей приложений" занимают языки, с которых нет компиляции в .Net? Вообще, желание писать компоненты сервера приложений на неуправляемой платформе в 2009 году — это уже клиника.
AV> Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang.
Это место непонятно. Во-первых, непонятно, почему интероп "двойной". В дотнете интероп происходит только при unmanaged-вызове. Один раз. Либо ноль раз, если call target — менеджед.
И не хватало бы скорости.
Во-вторых, непонятно, почему это так влияет на производительность. К примеру, сам IIS работает в unmanaged коде, но делает managed вызовы в код ASP.NET. При этом потери в большинстве случаев пренебрежимо малы.
Почему? Потому, что гранулярность вызовов достаточно велика. В большинстве случаев границу между managed и unmanaged можно провести так, чтобы свести накладные расходы практически к нулю. Еще один, более абстрактный пример: если вы хотите делать обработку изображений, то не надо вызывать unmanaged фильтр на каждый пиксел. Нужно запинить весь битмэп и передать его в фильтр целиком.
AV>А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал.
С другими платформами вопрос достаточно тонкий.
Поэтому сервера приложений сейчас в основном пишут на java. Если когда-нибудь MS решится всерьез профинансировать моно, то джаву это убъет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Константин Б., Вы писали: КБ>>А какие сложности нас подстерегают на этом пути? S>Как это какие? S>Элементарные сложности: где-то берем и меняем определение этих "анонимных данных". Например, вставили в [0] поле "Title", после которого пойдут FirstName и LastName, которые раньше были 0-м и 1-м. Весь код, построенный на индексах, поедет.
S>К примеру, что код, который формирует строку обращения к персоне, не хочется писать вот так: S>
Здравствуйте, Константин Б., Вы писали: КБ>Ага, понятно. В таких случаях лучше использовать Dictionary.
Ок, то есть вопрос пригодности кортежей для работы с данными можно считать закрытым, так?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Константин Б., Вы писали: КБ>>Ага, понятно. В таких случаях лучше использовать Dictionary. S>Ок, то есть вопрос пригодности кортежей для работы с данными можно считать закрытым, так?
Можно. Вообще тут больше обсуждался вопрос необходимости объектов и ORM.
G>А что вы удивляетесь. Такой подход среди "приплюснутых" программистов встречается очень часто. Понавыдумывают себе проблем и геройски их решают с помощью C++. А самые продвинутые в С++ даже не знают что эти проблемы уже решены кучей других способов кроме написания своего кроссплатформенного фреймворка.
Если ты такой умный, можешь просветишь нас, как правильно решать проблемы?
Хочу заметить: речь идет о проекте, который был сдан в срок, и уже продается.
Здравствуйте, Sinclair, Вы писали:
S>Пока что всё что я видел — это быстрое построение приложений в стиле "универсальный редактор DBF-файлов". К сожалению, приложения этого типа я закончил писать (для десктопа) примерно году в 1994 — разочаровался в концепции. То, что сейчас dbedit сумели засунуть в веб, меня нисколько не возбуждает.
Какой зоопарк сущностей из разных языков уже наплодили:
A#, C#, F#, J#, Sing#, Spec#, X#, и это только начало...
Читая эти форумы, у меня складывается такое ложное впечатление, что профессия программиста будто бы стремительно превращается в профессию филолога-лингвиста. Хотя это далеко не так. Конечно, базы данных и создание кнопочек на формах филологи-лингвисты ещё кое-как осилят, но а вот что касается сложных математических алгоритмов — то есть большие сомнения.
По-моему важно уметь эффективно программировать хотя бы на одном распространенном языке, а не бессмысленно изучать по 15 штук, и превращаться в языковеда, вместо того чтобы больше внимания уделить проектированию, прикладной математике. Ведь программирование — это в первую очередь прикладная математика, а не лингвистика. Кстати, именно поэтому Intel делает ставку на C++ и Фортран.
Фортран широко используется в первую очередь для научных и инженерных вычислений. Одно из преимуществ современного Фортрана — большое количество написанных на нём программ и библиотек подпрограмм. Среди учёных, например, ходит такая присказка, что любая математическая задача уже имеет решение на Фортране, и, действительно, можно найти среди тысяч фортрановских пакетов и пакет для перемножения матриц, и пакет для решения сложных интегральных уравнений, и многие, многие другие. Ряд таких пакетов создавались на протяжении десятилетий и популярны (главным образом в научной среде) по сей день.
С++ интересен огромным числом библиотек. Распространенность, кроссплатформенность, гибкость и мощь языка привлекает большое число серьёзных программистов. С++ де-факто представляет собой промышленный стандарт. Содержит средства создания эффективных программ практически любого назначения, от низкоуровневых утилит и драйверов до сложных программных комплексов. Поддерживает различные стили и технологии программирования, включая традиционное директивное программирование, ООП. Имеется возможность работы на низком уровне с памятью, адресами, портами. Доступны компиляторы для большого количества платформ. Язык спроектирован так, чтобы дать программисту максимальный контроль над всеми аспектами структуры и порядка исполнения программы.
Здравствуйте, Anton Batenev, Вы писали:
AB>А нельзя просто:
AB>
AB>class SomeClass<T>
AB>{
AB> public T Property1;
AB> public T Property2;
AB>}
AB>
Почему нельзя? Можно. Но это будут члены класса торчащие наружу. В общем случае такой подход считается моветоном. Ну и кроме того, для свойств можно определять скоуп аксессоров: public T Property1 { get; private set; }
Hi Sinclair
AV>>Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках. S>Каких именно?
Я уже писал. На данный момент на этом сервере крутятся приложения написанные на .NET, Java, Python, Ruby и старые знакомые C/C++. Еще заказчик пробует Ocaml. Есть еще биндинг для Перла.
S>Неужели у вас серъезную долю рынка "частей приложений" занимают языки, с которых нет компиляции в .Net? S>Вообще, желание писать компоненты сервера приложений на неуправляемой платформе в 2009 году — это уже клиника.
А на чем ты предлагаешь писать сервер, который может работать взаимодействовать с кодом на любом языке? Тем более, что стоит учитывать, что проект начинался не в 2009 году, а в 2005.
AV>> Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang. S>Это место непонятно. Во-первых, непонятно, почему интероп "двойной". В дотнете интероп происходит только при unmanaged-вызове. Один раз. Либо ноль раз, если call target — менеджед.
ОК. Еще раз. Вот у тебя сервер на .NET. Тебе надо дернуть код написанный на Java или Питон. Какие переходы будут сделаны? Из .NET в unmanaged. И из unmanaged в Java или Питон. Так? Вот тебе и двойной интероп. В нашем случае только один переход между managed и unmanaged.
S>И не хватало бы скорости.
Да, скорости было бы в притык к требованиям. Проверяли. Да и с переносимостью кода между системами до сих пор не все так прекрасно как хотелось бы. Mono далеко не всегда спасает. Тем более в то время когда начинался проект.
AV>>А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал. S>С другими платформами вопрос достаточно тонкий. S>Поэтому сервера приложений сейчас в основном пишут на java.
И как у них с вызовами кода из других языков, которые не изпользуют JVM?
S>Если когда-нибудь MS решится всерьез профинансировать моно, то джаву это убъет.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит. C>>oO Вы шутите? Скажите, что шутите... и не пугайте больше так.
KV>А что пугает?
Утверждение про низкоуровневость С#. Если С# низкоуровневый, то я даже и не знаю какой язык считать высокоуровневым. Разве что, упомянутый уже Пролог...
KV>>>3. Он мешает развиваться дальше. C>>Каким образом мешает-то? Наоборот, я уверен, многие про те же лямбды узнали только благодаря С#.
KV>На мой взгляд, по перечисленным в исходном сообщении причинам, он создает иллюзию отсутствия необходимости в дальнейшем развитии разработчика при том, что арсенал средств, предоставляемых шарпом не такой уж и богатый.
Любой полный по Тьюрингу язык может создавать такую иллюзию. И что с того?
KV>>>Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников. C>>10 лет назад я был "оголтелым плюсником"
KV>А какие лет 10 назад были альтернативы?
Джава.
KV>>>Ну вот собственно и все C>>Так а чего "слазить надо"? Я так и не понял...
KV>Да я видимо рановато обронил эту фразу, мне еще тяжело четко сформулировать свою т.з., при всей моей словоохотливости Последний год, я довольно много времени посвящал изучению различных средств, отсутствующих/отсутствовавших/неразвитых в шарпе. KV>Метапрограммирование, вывод типов,
С# 3, больше в С# 4.
KV>неизменяемые объекты,
С# 4
KV>динамическая типизация,
С# 4
KV>азы функционального программирования, и т.п.
Функциональные элементы были с самой первой версии и сильно развились с тех пор. Конечно многого еще нету, но не забывайте, что это все-таки императивный язык и его не так уж просто смешать с функциональщиной. Хотя F# в этом плане заметно дальше продвинулся.
KV>Столько средств, позволяющих действительно улучшить свой код, сделать его более эффективным, читаемым...
У каждого языка есть свои плюсы и минусы. С# это компромисс (и удачный) между рациональной функциональностью и объективной эффективностью. При всем при том он еще и массово распространен (в отличии от того же Nemerle или F#, к примеру). JIT архитектура позволяет делать очень интересные вещи (см. SpecSharp, Aspect#), сохраняя при этом производительность, присущую компиллируемым языкам и эффективный полноценный интероп с неуправляемым кодом.
Да, в следующей версии фреймворка появится DLR и дотнет наконец получит возможность выполнения интерпретируемых языков (*машет рукой Шеридану*)...
KV>Средств, о существовании которых, пару лет назад, я даже и не подозревал, считая что шарп полностью покрывает все мои потребности. И теперь, когда мне приходится писать или читать код на нем, я ощущаю неслабый дискомфорт от периодической нехватки/неразвитости в шарпе тех или иных языковых средств, с которыми я успел познакомиться. Я написал не так уж и много кода за последние несколько лет, по сравнению с профессиональными программерами, т.к. в силу своей специализации я все больше читаю, нежели пишу. Но сейчас я отчетливо вижу в своем старом коде места, которые я бы переписал на том же шарпе, куда более грамотно и качественно под влиянием других языков.
Естественно, С# не отменяет необходимости изучения других языков и даже в большей мере — парадигм программирования для саморазвития, как программиста. Мне, например, было очень интересно почитать про Erlang. Но при этом я понимаю, что С# таков, каков он есть в 3.0 с лихвой покрывает все мои потребности и даже более — я все еще не использую язык на все 100%, я более чем уверен в этом.
KV>А значит время на их изучение было потрачено не зря и об этом стоит рассказать здесь. Вдруг это поможет кому-нибудь еще открыть для себя новые горизонты развития?
Но я все еще не понимаю зачем "нужно слазить с С#", а главное — куда. Но да ладно, не берите в голову...
Здравствуйте, gandjustas, Вы писали:
G>.NET стандартизоват ISO? Я думал стандартизацией .NET ecma занимается.
C# и CLR/CLI стандартизованы в ECMA и ISO.
G>Да и стандартизовано там только язык — C#, рантайм — CLR и вроде как связанная с ней часть библиотеки, называемая CLI.
Об этом я и говорю.
C>>Так что почти любая программа на .NET на практике привязана к Windows. G>Вы так говорите как-будто mono не существует и Silverlight не запускается под маком.
Не существует и не запускается.
Официального Silverlight под Линукс нет, и никто не гарантирует, что версия Silverlight под Мак не исчезнет через полгода. Это называется "кроссплатформенность от MS".
G>Не надо выдавать желаемое за действительное.
Это реальность.
KV>Ну, чтобы не городить кучу if'ов вместо switch, например
Что-то я не понял примера. При чём здесь switch-то? Он и раньше был, пусть и в C# будет, не мешает. А вот зачем городить в C# что-то ещё кроме того, что уже есть в C++?
Здравствуйте, gandjustas, Вы писали:
G>>>>>Ага, FF уже научился использовать Accelerators C>>>>Зачем? G>>>Не поверите, затем что они работу в инете ускоряют. CC>>Гм. И каким образом? G>Банально меньше кликов и более быстрый доступ к нужной инфе.
How many steps does it take with your current browser to map an address, translate a word, or perform other routine tasks online? Until now it was likely a series of cutting and pasting information from one webpage to another. Now there's a better way. The new Accelerators in Internet Explorer 8 help you quickly perform your everyday browsing tasks without navigating to other websites to get things done. Simply highlight text from any webpage, and then click on the blue Accelerator icon that appears above your selection to obtain driving directions, translate and define words, email content to others, search with ease, and more. For example, with the "Map with Live Maps" Accelerator in Internet Explorer 8, you can get an in-place view of a map displayed directly on the page.
Зачем все это? В тех редких случаях, когда мне нужно взять кусок текста с одного сайта и использовать его на другом (что случается хорошо, если раз в месяц) гораздо проще сделать банальный копи-пейст, т.к. сайты все-равно будут открыты в разных закладках.
Зато конечно это ж, блин, так удобно, когда реклама моргает на каждом шагу, попапы выпрыгивают и прочая рекламная дрянь.
Вот скажите еще, раз в ие8 такой классный юзабилити... как мне его настроить, чтоб закладки открывались: 1) в три ряда, 2) чтоб загруженные на фоне подсвечивались, 3) чтоб новая вкладка, открываемая по клику по урлу средней кнопкой мыши, открывалась сразу за текущей вкладкой, а не где-то у черта на куличках?..
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Константин Б., Вы писали: КБ>>>Ага, понятно. В таких случаях лучше использовать Dictionary. S>>Ок, то есть вопрос пригодности кортежей для работы с данными можно считать закрытым, так?
КБ>Можно. Вообще тут больше обсуждался вопрос необходимости объектов и ORM.
Для динамических языков вообще мало разницы между словарями и объектами, в джаваскрипте например вообще такой разницы нету.
Здравствуйте, gandjustas, Вы писали:
G>Сила Моно состоит именно в десктопных приложениях, там где реально нужна кроссплатформенность. А для десктопа 100% фич .NET и не нужно, даже MS это понимает создавая .NET Client Profile (20 метров всего)
Кстати, а где Вы нашли этот самый профаил на 20 метров?
Здравствуйте, Кывт, Вы писали:
G>>А что вы удивляетесь. Такой подход среди "приплюснутых" программистов встречается очень часто. Понавыдумывают себе проблем и геройски их решают с помощью C++. А самые продвинутые в С++ даже не знают что эти проблемы уже решены кучей других способов кроме написания своего кроссплатформенного фреймворка.
К>Если ты такой умный, можешь просветишь нас, как правильно решать проблемы?
Могу, если вам нужна кроссплатформенность, то лучше смотреть в сторону веба, а не писать кроссплатформенный фреймворк на С++.
Здравствуйте, FirstStep, Вы писали:
VR>>в том-то и дело, с доведенными до ума ASP.NEt MVC, Azure Services, ADO.NEt Entity Framework, WCF (думаю, в течении этого года реально), дотнет(C#/F#) позволит предсказуемо качественно решать ВЕСЬ спектр задач для разработчиков (от простых сайтов до сложнейших систем)
FS>Ваша неправда про ВЕСЬ спектр. Простейший контрпример: программа-инсталлятор на C#,
Запускается бутстраппер на 277 кб, который скачивает все необходимое и ставит, затем через тот же COM-интероп цепляется дотнет сборка(и) и продолжается инсталляция.
Здравствуйте, Roman Odaisky, Вы писали:
L>>>Немного не так: он привязан к 95% установленным ОС. AV>>Позволю еще одно уточнение. К 95% установленных десктопных ОС.
RO>И то, это значило бы недооценить долю Мак ОС раза в два.
На нашем (стран СНГ) рынке даже переоценили, а не недооценили.
KV>Да я видимо рановато обронил эту фразу, мне еще тяжело четко сформулировать свою т.з., при всей моей словоохотливости Последний год, я довольно много времени посвящал изучению различных средств, отсутствующих/отсутствовавших/неразвитых в шарпе. Метапрограммирование, вывод типов, неизменяемые объекты, динамическая типизация, азы функционального программирования, и т.п. Столько средств, позволяющих действительно улучшить свой код, сделать его более эффективным, читаемым... Средств, о существовании которых, пару лет назад, я даже и не подозревал, считая что шарп полностью покрывает все мои потребности. И теперь, когда мне приходится писать или читать код на нем, я ощущаю неслабый дискомфорт от периодической нехватки/неразвитости в шарпе тех или иных языковых средств, с которыми я успел познакомиться. Я написал не так уж и много кода за последние несколько лет, по сравнению с профессиональными программерами, т.к. в силу своей специализации я все больше читаю, нежели пишу. Но сейчас я отчетливо вижу в своем старом коде места, которые я бы переписал на том же шарпе, куда более грамотно и качественно под влиянием других языков. А значит время на их изучение было потрачено не зря и об этом стоит рассказать здесь. Вдруг это поможет кому-нибудь еще открыть для себя новые горизонты развития?
ок, и как всё вышеописанное "покрывает" питон, раз уж не покрывет C# в связке с новым F#?
тем более. что тут http://rsdn.ru/forum/Default.aspx?mid=3319257&flat=0
Здравствуйте, Anton Batenev, Вы писали:
AB>А нельзя просто: AB>
AB>class SomeClass<T>
AB>{
AB> public T Property1;
AB> public T Property2;
AB>}
AB>
AB>?
Чем же это проще? Завтра понадобится при доступе к полю делать проверку или слать уведомление, будешь вынужден сделать поле свойством — тут-то у тебя бинарная совместимость и нарушится, придётся перекомпилировать клиенты твоего класса. Да и вообще, вне контекста Сишарпа, публичные поля — нарушение инкапсуляции.
Здравствуйте, shrecher, Вы писали:
L>>>>C# не требует VS. Если очень хочется можешь работать с обычными текстовыми файлами и компилировать через командную строку. Просто в студии это делать удобнее.
S>>>Да, но производительность написания кода резко упадет.
L>>Конечно упадет. До уровня производительность написания кода на питоне.
S>нифига. На Питоне и C#+VS пишется примерно с одной и тойже скоростью. Вот если из связки C# VS убрать VS, то все — труба, погрязнешь в рутине.
Вы вообще видели VS 2k8 + Resharper 4.1 связку? Явно не видели...
Как скорость может быть одинаковой, если нету ни мощных средств для рефакторинга, ни intellisense, ни удобных и быстрых средств для навигации по коду, ни средств для динамического анализа кода на соответствие определенным правилам, ни удобного отладчика, ни модуля для запуска модульных тестов, ни модуля для взаимодействия с системой контроля версий, ни модуля для дизайна схемы классов, ни модуля для дизайна форм, ни модуля для дизайна страниц, ни... много другого?
Здравствуйте, ambel-vlad, Вы писали:
AV>>>Точно? А то я, например, знаю проект, который ну никак не сделать на .NET. Причем не такой уж и сложный.
C>>Поделитесь знанием.
AV>Я уже как-то приводил его в пример. Но еще раз можно.
AV>Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках. Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang. И не хватало бы скорости. А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал.
Сложно себе представить кому потребовался проект с ТАКИМИ требованиями... Ну да ладно, соглашусь, что дотнет для ТАКОГО не лучший выбор.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
C>>>Какое уродство...
КБ>>Вы снова с нами В чем по вашему заключается уродство? )
C>В отвратительной читабельности кода, очевидно. Вы этого сами не замечаете?
gandjustas однажды (9 марта 2009 12:02) писал в rsdn.flame.comp:
> К>Если ты такой умный, можешь просветишь нас, как правильно решать проблемы? > Могу, если вам нужна кроссплатформенность, то лучше смотреть в сторону веба, а не писать кроссплатформенный фреймворк на С++.
Угу, правильно. Лучше пусть тормозит, ибо к трудностям мы непрывычные.
Так?
Здравствуйте, Sheridan, Вы писали:
>> RO>>>0. Он привязан к одной ОС. Дальше и обсуждать нечего. >> G>>Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком. >> RO>И что? >> Что значит что? Ваш тезис был опровергнут. Вот Вам и что. S>А ты двулик однако. S>То тебе опенсорц — дерьмо. То сам его предлагаеш пользовать. S>Делаеш как тебе удобно? Ну я другого и не ожидал
Вы меня ни с кем не путаете? Где я называл опенсоурс "дерьмом"?
Забавно, ведь у нас 80+% библиотек и утилит, применяемых в разработке наших (коммерческих) приложений — опенсоурс.
Здравствуйте, Sheridan, Вы писали:
>> Ваши грубые и неумелые попытки троллинга несколько утомили. Потому просто -1. S>Не нравится — не читай.
А с чего Вы решили, что я читаю?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, vit.rsdn, Вы писали:
v>> кстати, можете провести сравнительный анализ и указать, чем Django лучше, чем ряд этих готовых сайтов http://www.asp.net/community/projects/ или вот этих http://www.codeplex.com/site/search?projectSearchText=portal&sortBy=Relevance&licenses=| (более многочисленных)?
AB>Вопрос был в том, какие средства предоставляет питон в сравнении с RoR и про ORM. AB>А если сравнивать сайты по количеству, то PHP порвет всех.
по соотношению количество/качество дотнет рвёт всех.
по тупому критерию "количество" рвёт РНР
ну и ?
питон, где-то завис непонятно где и достоинств, что на нём пишут в Гугле и, может быть, в Яндексе, увы, мало
к сожалению, в данной ветке наплодили уже под три сотни постов, но так и объяснить, где и в чем питон "рвёт" РНР, кроме как (утрирую) [i]"эх. желательно выучить еще один язык, и, возможно, Питон, т.к. если МС загнется, то где мне найти на кусок хлеба бывшему дотнетчику"]/i] — увы, нету.
кстати, чего там гугл не поддерживает полностью Django в своих Google Apps
есть соображения?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Константин Б., Вы писали:
КБ>>Здравствуйте, Sinclair, Вы писали:
S>>>Здравствуйте, Константин Б., Вы писали: КБ>>>>Ага, понятно. В таких случаях лучше использовать Dictionary. S>>>Ок, то есть вопрос пригодности кортежей для работы с данными можно считать закрытым, так?
КБ>>Можно. Вообще тут больше обсуждался вопрос необходимости объектов и ORM.
G>Для динамических языков вообще мало разницы между словарями и объектами, в джаваскрипте например вообще такой разницы нету.
Ну не совсем. Заменить объект словарем можно почти везде. А вот наоборот не получится.
criosray однажды (9 марта 2009 12:15) писал в rsdn.flame.comp:
>>> Ваши грубые и неумелые попытки троллинга несколько утомили. Потому просто -1. > S>Не нравится — не читай. > А с чего Вы решили, что я читаю?
с того, что отвечаеш
Здравствуйте, Sheridan, Вы писали:
>> К>Если ты такой умный, можешь просветишь нас, как правильно решать проблемы? >> Могу, если вам нужна кроссплатформенность, то лучше смотреть в сторону веба, а не писать кроссплатформенный фреймворк на С++. S>Угу, правильно. Лучше пусть тормозит, ибо к трудностям мы непрывычные. S>Так?
Шеридан, может довольно проецировать свое незнание/неумение на других? Поймите же, что здесь не все так "гениальны", чтоб писать e.NewVal == IsChanged ? true : false
G>Могу, если вам нужна кроссплатформенность, то лучше смотреть в сторону веба, а не писать кроссплатформенный фреймворк на С++.
??? Интересное предложение. У нас оффлайновая программа для мобильных устройств. Она, возможно, будет скачивать данные по GPRS, но не более того.
Повторю, у нас все вполне успешно, проект сдан в срок.
«Кроссплатформенный фреймворк» мы и не думали писать, лишь несложный GUI-движок. Для мобильных устройств это нормальный подход. У всех наших конкурентов тоже «самопальные» GUI-движки. Потому что других вариантов особо нет (по крайней мере, когда проект начинался, не было).
Здравствуйте, vit.rsdn, Вы писали:
VR>ну и ? VR>питон, где-то завис непонятно где и достоинств, что на нём пишут в Гугле и, может быть, в Яндексе, увы, мало VR>к сожалению, в данной ветке наплодили уже под три сотни постов, но так и объяснить, где и в чем питон "рвёт" РНР и С#(дотнет),
criosray однажды (9 марта 2009 12:19) писал в rsdn.flame.comp:
> Шеридан, может довольно проецировать свое незнание/неумение на других? Поймите же, что здесь не все так "гениальны", чтоб писать e.NewVal == IsChanged ? true : false
Других недочетов, следует понимать, нет, раз за такую мелочь все зацепились?
Но насколько я понимаю, возразить по теме тебе нечего, раз наа личности переходиш
Так держать!
Здравствуйте, Sheridan, Вы писали:
>> Шеридан, может довольно проецировать свое незнание/неумение на других? Поймите же, что здесь не все так "гениальны", чтоб писать e.NewVal == IsChanged ? true : false S> S>Других недочетов, следует понимать, нет, раз за такую мелочь все зацепились?
Без понятия. Я дальше этого читать не стал. А надо?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Сила Моно состоит именно в десктопных приложениях, там где реально нужна кроссплатформенность. А для десктопа 100% фич .NET и не нужно, даже MS это понимает создавая .NET Client Profile (20 метров всего) C>Кстати, а где Вы нашли этот самый профаил на 20 метров?
C>1. Client Profile Online installer (bootstrapper) http://www.microsoft.com/downloads/details.aspx?FamilyId=8CEA6CD1-15BC-4664-B27D-8CEBA808B28B&displaylang=en 277 kB загружает все из инета. C>2. Client Profile Offline installer http://www.microsoft.com/downloads/details.aspx?familyid=992CFFCB-F8CE-41D9-8BD6-31F3E216285C&displaylang=en 255 MB (!!!!!)
C>
А ставить не пробовали? Ставится около 30 метров, онлайн интсаллятор качает около 20 из интернета для установки.
Оффлайн версия Client Profile содержит полный фреймворк внутри себя, хотя ставит малую часть.
Здравствуйте, Sheridan, Вы писали:
>>>> Ваши грубые и неумелые попытки троллинга несколько утомили. Потому просто -1. >> S>Не нравится — не читай. >> А с чего Вы решили, что я читаю? S>с того, что отвечаеш
У г-на Анонима12 достаточно прочитать первое предложение, чтоб получить представление о той чуши, которая последует дальше.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>.NET стандартизоват ISO? Я думал стандартизацией .NET ecma занимается. C>C# и CLR/CLI стандартизованы в ECMA и ISO.
Номер ISO стандарта?
G>>Да и стандартизовано там только язык — C#, рантайм — CLR и вроде как связанная с ней часть библиотеки, называемая CLI. C>Об этом я и говорю.
И что вам не нравится?
C>>>Так что почти любая программа на .NET на практике привязана к Windows. G>>Вы так говорите как-будто mono не существует и Silverlight не запускается под маком. C>Не существует и не запускается.
Бред.
C>Официального Silverlight под Линукс нет, и никто не гарантирует, что версия Silverlight под Мак не исчезнет через полгода. Это называется "кроссплатформенность от MS".
Ну также как адоба не гарантирует что не исчезнет флеш. МС банально невыгодно закрывать SL под мак.
G>>Не надо выдавать желаемое за действительное. C>Это реальность.
Это плоды вашего воспаленного воображения.
Здравствуйте, vit.rsdn, Вы писали:
VR>питон, где-то завис непонятно где и достоинств, что на нём пишут в Гугле и, может быть, в Яндексе, увы, мало
я так понимаю, шарп выбирают, потому что на нём пишут в микрософте?. -_^
VR>кстати, чего там гугл не поддерживает полностью Django в своих Google Apps VR>есть соображения?
а он должен?.
это ж, блин, не шарп какой нибудь, где без фреймворка тяжело и больно.. тут можно выкинуть джангу и всять другой фреймворк.. или свой написать..
G>>>Сила Моно состоит именно в десктопных приложениях, там где реально нужна кроссплатформенность. А для десктопа 100% фич .NET и не нужно, даже MS это понимает создавая .NET Client Profile (20 метров всего) C>>Кстати, а где Вы нашли этот самый профаил на 20 метров?
C>>1. Client Profile Online installer (bootstrapper) http://www.microsoft.com/downloads/details.aspx?FamilyId=8CEA6CD1-15BC-4664-B27D-8CEBA808B28B&displaylang=en 277 kB загружает все из инета. C>>2. Client Profile Offline installer http://www.microsoft.com/downloads/details.aspx?familyid=992CFFCB-F8CE-41D9-8BD6-31F3E216285C&displaylang=en 255 MB (!!!!!)
C>> G>А ставить не пробовали? Ставится около 30 метров, онлайн интсаллятор качает около 20 из интернета для установки. G>Оффлайн версия Client Profile содержит полный фреймворк внутри себя, хотя ставит малую часть.
Ну это здорово, но в чем смысл? В экономии сотни метров на диске? Самая идея client profile`а, как я понял, в упрощенной доставке самого фреймворка клиенту. Не понимаю почему нельзя было сделать оффлайновый инсталлятор только на те 30 метров, которые, собственно, ставятся...
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>>>Ага, FF уже научился использовать Accelerators C>>>>>Зачем? G>>>>Не поверите, затем что они работу в инете ускоряют. CC>>>Гм. И каким образом? G>>Банально меньше кликов и более быстрый доступ к нужной инфе.
C>
C>How many steps does it take with your current browser to map an address, translate a word, or perform other routine tasks online? Until now it was likely a series of cutting and pasting information from one webpage to another. Now there's a better way. The new Accelerators in Internet Explorer 8 help you quickly perform your everyday browsing tasks without navigating to other websites to get things done. Simply highlight text from any webpage, and then click on the blue Accelerator icon that appears above your selection to obtain driving directions, translate and define words, email content to others, search with ease, and more. For example, with the "Map with Live Maps" Accelerator in Internet Explorer 8, you can get an in-place view of a map displayed directly on the page.
C>Зачем все это? В тех редких случаях, когда мне нужно взять кусок текста с одного сайта и использовать его на другом (что случается хорошо, если раз в месяц) гораздо проще сделать банальный копи-пейст, т.к. сайты все-равно будут открыты в разных закладках.
Еще раз спрашиваю, вы пользовались IE8?
не хочу вести разговор о вкусе устриц с человеком который их не пробовал.
C>Лезвие Оккама...
Парадокс Блаба.
C>Вот скажите еще, раз в ие8 такой классный юзабилити... как мне его настроить, чтоб закладки открывались:
1) в три ряда,
Не открывайте столько вкладок чтобы нужно было 3 ряда.
У меня например широкоформатный ноут и мне очень важна высота окна, поэтому несколько рядов табов совершенно не подходят.
2) чтоб загруженные на фоне подсвечивались,
Зачем? Есть же Лезвие Оккама.
3) чтоб новая вкладка, открываемая по клику по урлу средней кнопкой мыши, открывалась сразу за текущей вкладкой, а не где-то у черта на куличках?..
Оно так и работает.
На этой радостной ноте разговор о юзабилити браузеров заканчиваю, ибо кроме своего ФФ вы мало чего видели.
Здравствуйте, shrecher, Вы писали:
L>>Какие преимущества есть в питоне (как языке)?
S>Простота. Понятный синтаксис.
Я последнее время склоняюсь к мысли, что самый простой для изучения язык, при этом обладающий самым простым синтаксисом — brainfuck. Восем простых команд, никаких излишеств.
Простота и понятный синтаксис важны, но не являются и не могут являться решающими при выборе языка. По моему скромному мнению решающими факторами является соответствие языка решаемым задачам. А тут уже не только и не столько язык важен.
Здравствуйте, ambel-vlad, Вы писали:
AV>ОК. Еще раз. Вот у тебя сервер на .NET. Тебе надо дернуть код написанный на Java или Питон. Какие переходы будут сделаны? Из .NET в unmanaged. И из unmanaged в Java или Питон. Так? Вот тебе и двойной интероп. В нашем случае только один переход между managed и unmanaged.
Здравствуйте, gandjustas, Вы писали:
C>>Зачем все это? В тех редких случаях, когда мне нужно взять кусок текста с одного сайта и использовать его на другом (что случается хорошо, если раз в месяц) гораздо проще сделать банальный копи-пейст, т.к. сайты все-равно будут открыты в разных закладках.
G>Еще раз спрашиваю, вы пользовались IE8?
А я Вам еще раз отвечаю: да, пользовался.
C>>Лезвие Оккама... G>Парадокс Блаба.
По Блабу мне не следует доверять Вам касательно ИЕ8
C>>Вот скажите еще, раз в ие8 такой классный юзабилити... как мне его настроить, чтоб закладки открывались: G>1) в три ряда, G>Не открывайте столько вкладок чтобы нужно было 3 ряда.
Ага, то есть юзабилити теперь у нас выражается в том, чтоб говорить пользователю что ему НЕ делать? Забавно...
G>У меня например широкоформатный ноут и мне очень важна высота окна, поэтому несколько рядов табов совершенно не подходят.
У меня тоже широкоформатный и мне нужны три ряда вкладок. Ну так где хваленое "юзабилити"-то? Ведь вкладки это далеко не единственный пример.
G>2) чтоб загруженные на фоне подсвечивались, G>Зачем? Есть же Лезвие Оккама.
Потому что это необходимо, когда вы открываете много вкладок на фоне и не хотите кликать по каждой, чтоб узнать, что контент загрузился + видно, какие вкладки уже прочтенные, а какие — нет.
G>3) чтоб новая вкладка, открываемая по клику по урлу средней кнопкой мыши, открывалась сразу за текущей вкладкой, а не где-то у черта на куличках?.. G>Оно так и работает.
Не всегда, к сожалению.
G>На этой радостной ноте разговор о юзабилити браузеров заканчиваю, ибо кроме своего ФФ вы мало чего видели. То есть Ваши аргументы иссякли? Да-а, быстренько что-то... Впрочем, не удивительно, Вы ведь сами понимаете, что я прав и ИЕ8 о юзабилити до ФФ, как до неба, хотя не желаете этого признать.
Здравствуйте, SE, Вы писали:
S>>Простота. Понятный синтаксис. SE>Я последнее время склоняюсь к мысли, что самый простой для изучения язык, при этом обладающий самым простым синтаксисом — brainfuck. Восем простых команд, никаких излишеств.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Как ты быстро с заявления о том, что С# (язык) привязан к винде, перескочил к привязке к винде всей .NET (в т.ч. и FCL) :)) C# 3.0 к платформе не привязан, и на нем ты можешь писать и под mono.
Я тебе больше скажу: C# не привязан к компьютеру, как и любой другой язык программирования, как и любой человеческий язык. А вот программы, написанные на C#, имеют дурную привычку требовать что-нибудь, что будет отвечать их ожиданиям насчет CLR как минимум.
Проблема-то в том, что для последовательности букв, которую майкрософтовский компилятор C# считает программой на C#, Mono может и не осилить создать исполняемый файл.
Здравствуйте, criosray, Вы писали:
L>>>>Немного не так: он привязан к 95% установленным ОС. ;) AV>>>Позволю еще одно уточнение. К 95% установленных десктопных ОС. RO>>И то, это значило бы недооценить долю Мак ОС раза в два. C>На нашем (стран СНГ) рынке даже переоценили, а не недооценили. :xz:
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>Сила Моно состоит именно в десктопных приложениях, там где реально нужна кроссплатформенность. А для десктопа 100% фич .NET и не нужно, даже MS это понимает создавая .NET Client Profile (20 метров всего) C>>>Кстати, а где Вы нашли этот самый профаил на 20 метров?
C>>>1. Client Profile Online installer (bootstrapper) http://www.microsoft.com/downloads/details.aspx?FamilyId=8CEA6CD1-15BC-4664-B27D-8CEBA808B28B&displaylang=en 277 kB загружает все из инета. C>>>2. Client Profile Offline installer http://www.microsoft.com/downloads/details.aspx?familyid=992CFFCB-F8CE-41D9-8BD6-31F3E216285C&displaylang=en 255 MB (!!!!!)
C>>> G>>А ставить не пробовали? Ставится около 30 метров, онлайн интсаллятор качает около 20 из интернета для установки. G>>Оффлайн версия Client Profile содержит полный фреймворк внутри себя, хотя ставит малую часть. C>Ну это здорово, но в чем смысл? В экономии сотни метров на диске? Самая идея client profile`а, как я понял, в упрощенной доставке самого фреймворка клиенту. Не понимаю почему нельзя было сделать оффлайновый инсталлятор только на те 30 метров, которые, собственно, ставятся...
онлайн инсталлер фреймворка 3.5 SP1 качает около 90 метров (если не считать языковой пакет), при том что оффлайн инсталлер весит 250. Догадываетесь почему?
Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все.
Вот почему не будет client profile на 30 метров.
Здравствуйте, gandjustas, Вы писали:
G>>>.NET стандартизоват ISO? Я думал стандартизацией .NET ecma занимается. C>>C# и CLR/CLI стандартизованы в ECMA и ISO. G>Номер ISO стандарта?
ISO/IEC 23270:2003 , ISO/IEC 23271:2006 и т.д. — так сложно в Гугл было заглянуть?
G>>>Вы так говорите как-будто mono не существует и Silverlight не запускается под маком. C>>Не существует и не запускается. G>Бред.
Нет, это практическая реальность, которая только в теории не отличается от теории.
C>>Официального Silverlight под Линукс нет, и никто не гарантирует, что версия Silverlight под Мак не исчезнет через полгода. Это называется "кроссплатформенность от MS". G>Ну также как адоба не гарантирует что не исчезнет флеш. МС банально невыгодно закрывать SL под мак.
Адобу выгодно иметь кроссплатформенное решение — они операционки не делают. А вот MS такой трюк уже пару раз делали — им доверия нет никакого.
Учитывая, что с .NET ещё связаны куча патентов, а MS стали с недавнего времени патентным троллем — так вообще их продукты являются токсичными для всех остальных ОС.
Здравствуйте, neFormal, Вы писали:
VR>>питон, где-то завис непонятно где и достоинств, что на нём пишут в Гугле и, может быть, в Яндексе, увы, мало F>я так понимаю, шарп выбирают, потому что на нём пишут в микрософте?. -_^
Вот как раз в МС на шарпе не особо много продуктов пишут.
Уже обсуждалось.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>Вот почему не будет client profile на 30 метров.
Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi?
В чем непреодолимая трудность то?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Кывт, Вы писали:
G>>Могу, если вам нужна кроссплатформенность, то лучше смотреть в сторону веба, а не писать кроссплатформенный фреймворк на С++.
К>??? Интересное предложение. У нас оффлайновая программа для мобильных устройств. Она, возможно, будет скачивать данные по GPRS, но не более того.
И что эта программа делает?
К>«Кроссплатформенный фреймворк» мы и не думали писать, лишь несложный GUI-движок. Для мобильных устройств это нормальный подход. У всех наших конкурентов тоже «самопальные» GUI-движки. Потому что других вариантов особо нет (по крайней мере, когда проект начинался, не было).
А почему тогда java не взяли, вот уж она есть почти везде?
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, vit.rsdn, Вы писали:
VR>>питон, где-то завис непонятно где и достоинств, что на нём пишут в Гугле и, может быть, в Яндексе, увы, мало
F>я так понимаю, шарп выбирают, потому что на нём пишут в микрософте?. -_^
потому что крайне удобно на нём писать
VR>>кстати, чего там гугл не поддерживает полностью Django в своих Google Apps VR>>есть соображения?
F>а он должен?. F>это ж, блин, не шарп какой нибудь, где без фреймворка тяжело и больно.. тут можно выкинуть джангу и всять другой фреймворк.. или свой написать..
в шарпе можно и без фреймворка прекрасно писать, как и на любом другом языке. И даже гораздо поудобней, чем на питоне (мой субъективный взгляд).
только, изобретать "велосипеды" каждый раз....
тоже про джаву: достаточно посредственный язык, но мощнейшие фреймворки/библиотеки — С++ ушёл на задворки. Потом появился дотнет и из плюсов вытянул тех, кто не успел перейти на джаву
увы, плюсам остались достаточно узкие ниши. хотя. как язык, С++ на тот момент времени был "круче" чем дотнет и джава.
отсутствие вменяемых фреймворков — это гарантия того, что каждый раз каждый девелопер будет изобретать "велосипед" заново.
Что катастрофически влияет на продуктивность и время, через которое заказчик получит проект
такие девелоперы просто не выдержат конкуренцию с другими, кто испльзует язык в связке с платформой и не изобретают нон-стоп велосипедов.
Здравствуйте, gandjustas, Вы писали:
G>онлайн инсталлер фреймворка 3.5 SP1 качает около 90 метров (если не считать языковой пакет), при том что оффлайн инсталлер весит 250. Догадываетесь почему? G>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>Вот почему не будет client profile на 30 метров.
Так это бред. Зачем паковать все в один дистрибутив, если можно разбить его на х86 и х64 и IA64... как было сделано с случае того же MS SQL Server?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Проблема-то в том, что для последовательности букв, которую майкрософтовский компилятор C# считает программой на C#, Mono может и не осилить создать исполняемый файл.
Есть и примеры обратного — в «догоняющем» Mono уже есть фичи (compiler as service), которые будут доступны в майкрософтовском компиляторе только через версию, в 5.0.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Зачем все это? В тех редких случаях, когда мне нужно взять кусок текста с одного сайта и использовать его на другом (что случается хорошо, если раз в месяц) гораздо проще сделать банальный копи-пейст, т.к. сайты все-равно будут открыты в разных закладках.
G>>Еще раз спрашиваю, вы пользовались IE8? C>А я Вам еще раз отвечаю: да, пользовался.
Ну видимо также как EF.
C>>>Лезвие Оккама... G>>Парадокс Блаба. C>По Блабу мне не следует доверять Вам касательно ИЕ8
C>>>Вот скажите еще, раз в ие8 такой классный юзабилити... как мне его настроить, чтоб закладки открывались: G>>1) в три ряда, G>>Не открывайте столько вкладок чтобы нужно было 3 ряда. C>Ага, то есть юзабилити теперь у нас выражается в том, чтоб говорить пользователю что ему НЕ делать? Забавно...
G>>У меня например широкоформатный ноут и мне очень важна высота окна, поэтому несколько рядов табов совершенно не подходят. C>У меня тоже широкоформатный и мне нужны три ряда вкладок. Ну так где хваленое "юзабилити"-то? Ведь вкладки это далеко не единственный пример.
Вы удобство с привычностью путаете.
G>>2) чтоб загруженные на фоне подсвечивались, G>>Зачем? Есть же Лезвие Оккама. C>Потому что это необходимо, когда вы открываете много вкладок на фоне и не хотите кликать по каждой, чтоб узнать, что контент загрузился + видно, какие вкладки уже прочтенные, а какие — нет.
Не знаю ни одного человека которому такое требовалось.
G>>3) чтоб новая вкладка, открываемая по клику по урлу средней кнопкой мыши, открывалась сразу за текущей вкладкой, а не где-то у черта на куличках?.. G>>Оно так и работает. C>Не всегда, к сожалению.
У меня всегда.
G>>На этой радостной ноте разговор о юзабилити браузеров заканчиваю, ибо кроме своего ФФ вы мало чего видели. C> То есть Ваши аргументы иссякли? Да-а, быстренько что-то... Впрочем, не удивительно, Вы ведь сами понимаете, что я прав и ИЕ8 о юзабилити до ФФ, как до неба, хотя не желаете этого признать.
Ну для вас ФФ лидер по юзабилити, потому что ничего другого не видели.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Проблема-то в том, что для последовательности букв, которую майкрософтовский компилятор C# считает программой на C#, Mono может и не осилить создать исполняемый файл.
Пример в студию.
Mono2 полностью поддерживает C# 3.0
Здравствуйте, Cyberax, Вы писали:
G>>>>Вы так говорите как-будто mono не существует и Silverlight не запускается под маком. C>>>Не существует и не запускается. G>>Бред. C>Нет, это практическая реальность, которая только в теории не отличается от теории.
Можете в это и дальше верить.
C>>>Официального Silverlight под Линукс нет, и никто не гарантирует, что версия Silverlight под Мак не исчезнет через полгода. Это называется "кроссплатформенность от MS". G>>Ну также как адоба не гарантирует что не исчезнет флеш. МС банально невыгодно закрывать SL под мак. C>Адобу выгодно иметь кроссплатформенное решение — они операционки не делают. А вот MS такой трюк уже пару раз делали — им доверия нет никакого.
Интернет никак от ОС не зависит, так что за судбу SL можете не волноваться.
C>Учитывая, что с .NET ещё связаны куча патентов, а MS стали с недавнего времени патентным троллем — так вообще их продукты являются токсичными для всех остальных ОС.
Ну хватит уже, 300 раз обсасывали тему что MS патенты нужны для защиты.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>>Вот почему не будет client profile на 30 метров.
CC>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>В чем непреодолимая трудность то?
А зачем? Берете онлайн инсталлер и качаете то что нужно.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, SE, Вы писали:
S>>>Простота. Понятный синтаксис. SE>>Я последнее время склоняюсь к мысли, что самый простой для изучения язык, при этом обладающий самым простым синтаксисом — brainfuck. Восем простых команд, никаких излишеств.
F>WhiteSpace F>2 команды: пробел и enter
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>онлайн инсталлер фреймворка 3.5 SP1 качает около 90 метров (если не считать языковой пакет), при том что оффлайн инсталлер весит 250. Догадываетесь почему? G>>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>>Вот почему не будет client profile на 30 метров.
C>Так это бред. Зачем паковать все в один дистрибутив, если можно разбить его на х86 и х64 и IA64... как было сделано с случае того же MS SQL Server?
У меня диск с MS SQL 2008, все версии ставятся с одного дистрибутива.
Хотя в случае большого дистра (который не влезет на один диск например) имеет смысл разбивать его на несколько по целевой архитектуре\ОС.
В общем случае один большой дистр на всех кажется мне более правильным решением.
Здравствуйте, gandjustas, Вы писали:
G>>>Ну также как адоба не гарантирует что не исчезнет флеш. МС банально невыгодно закрывать SL под мак. C>>Адобу выгодно иметь кроссплатформенное решение — они операционки не делают. А вот MS такой трюк уже пару раз делали — им доверия нет никакого. G>Интернет никак от ОС не зависит, так что за судбу SL можете не волноваться.
"Интернет" от ОС никак не зависит, а вот проигрыватель SL — очень даже.
Ты можешь гарантировать, что если SL получит распространение, то МС в один день не перестанет разрабатывать версии для Маков? Ну или даже просто выпускать их с опозданием на год-два.
C>>Учитывая, что с .NET ещё связаны куча патентов, а MS стали с недавнего времени патентным троллем — так вообще их продукты являются токсичными для всех остальных ОС. G>Ну хватит уже, 300 раз обсасывали тему что MS патенты нужны для защиты.
Да-да. Примерно как Гитлеру потребовалось на СССР нападать заранее для защиты. Или как США напала на Ирак для защиты себя.
Здравствуйте, criosray, Вы писали:
>>>>> Ваши грубые и неумелые попытки троллинга несколько утомили. Потому просто -1.
Извините пожалуйста, если моё скромное мнение не совпало с Вашим, и каким-то образом нечаянно причинило Вам страдание, или нарушило душевное равновесие.
C>У г-на Анонима12 достаточно прочитать первое предложение, чтоб получить представление о той чуши, которая последует дальше.
Виноват. Согласен. Буду исправляться.
Мне нравится С++, вам — С#. Я просто выразил свою позицию (или даже собственное мировозрение по-отношению к тенденциям в программировании). Она конечно же может отличаться от Вашей.
Хотя топик в принципе неактуален, потому что на вкус и цвет приятелей нет, а ещё есть такое понятие как мирное сосуществование.
Здравствуйте, vit.rsdn, Вы писали:
VR>>>питон, где-то завис непонятно где и достоинств, что на нём пишут в Гугле и, может быть, в Яндексе, увы, мало F>>я так понимаю, шарп выбирают, потому что на нём пишут в микрософте?. -_^ VR>потому что крайне удобно на нём писать
так почему ты отказываешь в этом удобстве питону?.
просто есть еще один язык, на котором тоже можно написать "почти что угодно".. со своим синтаксисом, со своими библиотеками.. обладающий реальной кроссплатформенностью..
достоинства не поймешь, пока не напишешь на нём что нибудь..
недостатки, собственно, тоже
несколько не в тему, но...
Вот сколько читаю споры шарповцев и других, все там речь идет о доступе к данным. Неужели эти языки применяются только для работы с БД?
К чему вопрос: хочу изучить C# (после плюсов интересно), но работа со всякими БД никогда не интересовала.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>Ну также как адоба не гарантирует что не исчезнет флеш. МС банально невыгодно закрывать SL под мак. C>>>Адобу выгодно иметь кроссплатформенное решение — они операционки не делают. А вот MS такой трюк уже пару раз делали — им доверия нет никакого. G>>Интернет никак от ОС не зависит, так что за судбу SL можете не волноваться. C>"Интернет" от ОС никак не зависит, а вот проигрыватель SL — очень даже. C>Ты можешь гарантировать, что если SL получит распространение, то МС в один день не перестанет разрабатывать версии для Маков? Ну или даже просто выпускать их с опозданием на год-два.
Ну вот если MS хочет захватывать интернет-рынок, то им как раз очень выгдоно поддерживать SL на куче платформ.
Здравствуйте, March_rabbit, Вы писали:
M_>несколько не в тему, но... M_>Вот сколько читаю споры шарповцев и других, все там речь идет о доступе к данным. Неужели эти языки применяются только для работы с БД? M_>К чему вопрос: хочу изучить C# (после плюсов интересно), но работа со всякими БД никогда не интересовала.
тогда скажи, что тебя интересует, и тебе посоветуют..
Здравствуйте, gandjustas, Вы писали:
C>>>>Зачем все это? В тех редких случаях, когда мне нужно взять кусок текста с одного сайта и использовать его на другом (что случается хорошо, если раз в месяц) гораздо проще сделать банальный копи-пейст, т.к. сайты все-равно будут открыты в разных закладках.
G>>>Еще раз спрашиваю, вы пользовались IE8? C>>А я Вам еще раз отвечаю: да, пользовался. G>Ну видимо также как EF.
Да так же — в достаточной мере для того, чтоб полноценно оценить и сделать соответствующие выводы.
G>>>У меня например широкоформатный ноут и мне очень важна высота окна, поэтому несколько рядов табов совершенно не подходят. C>>У меня тоже широкоформатный и мне нужны три ряда вкладок. Ну так где хваленое "юзабилити"-то? Ведь вкладки это далеко не единственный пример. G>Вы удобство с привычностью путаете. При чем тут привычность?
G>>>2) чтоб загруженные на фоне подсвечивались, G>>>Зачем? Есть же Лезвие Оккама. C>>Потому что это необходимо, когда вы открываете много вкладок на фоне и не хотите кликать по каждой, чтоб узнать, что контент загрузился + видно, какие вкладки уже прочтенные, а какие — нет. G>Не знаю ни одного человека которому такое требовалось.
Теперь знаете как минимум одного. А то, что доля пользователей ФФ стремительно растет, а доля пользователей ИЕ — падает, не смотря на его гигантскую фору в плане предустановленности с ОС, лишь свидетельствует о моей правоте.
G>>>3) чтоб новая вкладка, открываемая по клику по урлу средней кнопкой мыши, открывалась сразу за текущей вкладкой, а не где-то у черта на куличках?.. G>>>Оно так и работает. C>>Не всегда, к сожалению. G>У меня всегда.
А у меня нет. ЧЯДНТ?
G>>>На этой радостной ноте разговор о юзабилити браузеров заканчиваю, ибо кроме своего ФФ вы мало чего видели. C>> То есть Ваши аргументы иссякли? Да-а, быстренько что-то... Впрочем, не удивительно, Вы ведь сами понимаете, что я прав и ИЕ8 о юзабилити до ФФ, как до неба, хотя не желаете этого признать. G>Ну для вас ФФ лидер по юзабилити, потому что ничего другого не видели.
Видел. Это скорее Вы не видели ФФ, судя по Вашим ответам...
Здравствуйте, gandjustas, Вы писали:
G>>>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>>>Вот почему не будет client profile на 30 метров. CC>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>В чем непреодолимая трудность то? G>А зачем? Берете онлайн инсталлер и качаете то что нужно.
Есть масса случаев (ситуаций), когда нет возможности качать онлайновым инсталлятором.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>>>>Вот почему не будет client profile на 30 метров. CC>>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>>В чем непреодолимая трудность то? G>>А зачем? Берете онлайн инсталлер и качаете то что нужно. C>Есть масса случаев (ситуаций), когда нет возможности качать онлайновым инсталлятором.
Скачивание версии для одной конкретной платформы вряд ли относится к этим случаям.
Здравствуйте, Anonim12, Вы писали:
A>Мне нравится С++, вам — С#. Я просто выразил свою позицию (или даже собственное мировозрение по-отношению к тенденциям в программировании). Она конечно же может отличаться от Вашей.
Не приравнивайте меня к себе. Это оскорбительно. Я в отличие от Вас не троллю, поливая откровенно лживой клеветой то, что мне нравится.
Здравствуйте, gandjustas, Вы писали:
G>>>>>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>>>>>Вот почему не будет client profile на 30 метров. CC>>>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>>>В чем непреодолимая трудность то? G>>>А зачем? Берете онлайн инсталлер и качаете то что нужно. C>>Есть масса случаев (ситуаций), когда нет возможности качать онлайновым инсталлятором. G>Скачивание версии для одной конкретной платформы вряд ли относится к этим случаям.
Кто говорил что-то о выкачивании? Оффлайновый инсталлятор потому и оффлайновый, что его можно включить в пакет инсталляции, распространяемый на DVD.
Здравствуйте, vit.rsdn, Вы писали:
VR>ок, и как всё вышеописанное "покрывает" питон, раз уж не покрывет C# в связке с новым F#?
А почему вопрос адресован мне? Все что я сказал на тему пайтона и шарпа это
Я вот, в т.ч. и с шарпа на пайтон пересел (который у тебя в печке, пару лет назад благополучно сгорел) и потихоньку в nemerle ковыряюсь
и
Не-не-не vit.rsdn, не-не-не (с). Ты меня неправильно понял. Я не агитирую переходить с шарпа на пайтон, просто этот язык исключительно подошел мне под мои задачи, по целому ряду критериев. Это не значит, что он также подойдет кому-то еще.
Здравствуйте, gandjustas, Вы писали:
C>>"Интернет" от ОС никак не зависит, а вот проигрыватель SL — очень даже. C>>Ты можешь гарантировать, что если SL получит распространение, то МС в один день не перестанет разрабатывать версии для Маков? Ну или даже просто выпускать их с опозданием на год-два. G>Ну вот если MS хочет захватывать интернет-рынок, то им как раз очень выгдоно поддерживать SL на куче платформ.
Если ты не заметил, то MS получает основные деньги от продажи операционной системы. Поэтому им может быть выгодно придушить кроссплатформенность в Сети. Скажем, Adobe это не выгодно — они ОСи не делают.
Здравствуйте, Anonim12, Вы писали:
A>По-моему важно уметь эффективно программировать хотя бы на одном распространенном языке, а не бессмысленно изучать по 15 штук, и превращаться в языковеда, вместо того чтобы больше внимания уделить проектированию, прикладной математике.
Программист на C++ не может в полной мере уделять внимание проектированию и прикладной математике, потому что он должен уделять это внимание языку.
A>С++ интересен огромным числом библиотек.
Hi gandjustas
AV>>ОК. Еще раз. Вот у тебя сервер на .NET. Тебе надо дернуть код написанный на Java или Питон. Какие переходы будут сделаны? Из .NET в unmanaged. И из unmanaged в Java или Питон. Так? Вот тебе и двойной интероп. В нашем случае только один переход между managed и unmanaged.
G>Так у вас все в одном процессе крутится?
Если есть возможность, то все компоненты одного приложения могут крутиться в одном процессе. А могут и в нескольких. А могут и совсем на разных машинах. Как сконфигурируешь сервак, так и будет.
Hi criosray
AV>>>>Точно? А то я, например, знаю проект, который ну никак не сделать на .NET. Причем не такой уж и сложный.
C>>>Поделитесь знанием.
AV>>Я уже как-то приводил его в пример. Но еще раз можно.
AV>>Надо было разработать Application server. Причем под несколько платформ и чтобы приложения (или их части) можно было писать на различных языках. Но даже если ограничиться только одной виндой, то на .NET все равно не получается вытянуть. Потому что получался бы двойной интероп. .NET->C->Other lang. И не хватало бы скорости. А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал.
C>Сложно себе представить кому потребовался проект с ТАКИМИ требованиями...
Вполне может.
C>Ну да ладно, соглашусь, что дотнет для ТАКОГО не лучший выбор.
Вот и ладненько. Разобрались. Значит первоначальный посыл был не совсем верен.
Здравствуйте, criosray, Вы писали:
A>>Мне нравится С++, вам — С#. Я просто выразил свою позицию (или даже собственное мировозрение по-отношению к тенденциям в программировании). Она конечно же может отличаться от Вашей. C>Не приравнивайте меня к себе.
Мы как раз отличаемся, как минимум в выборе основного языка.
C>Это оскорбительно.
Извините за оскорбление. Не хочу выяснять конкретно где я виноват, но если мои посты причинили вам страдание — то безусловно виноват именно я. Поэтому как уже говорил, буду исправляться. Например, более мягко подавать материал.
C>Я в отличие от Вас не троллю, поливая откровенно лживой клеветой то, что мне нравится.
Спасибо за ценное замечание. Я это обязательно учту при дальнейшем участии на форуме. Указывать где находится клевета на C# — нет необходимости.
Здравствуйте, x64, Вы писали:
KV>>Ну, чтобы не городить кучу if'ов вместо switch, например
x64>Что-то я не понял примера. При чём здесь switch-то? Он и раньше был, пусть и в C# будет, не мешает.
Я привел абсурдный пример, чтобы показать излишнюю обобщенность твоего утверждения.
x64>А вот зачем городить в C# что-то ещё кроме того, что уже есть в C++?
Т.е., следуя твоей же логике, языки программирования должны отличаться друг от друга только синтаксисом и стандартной библиотекой?
Здравствуйте, Cyberax, Вы писали:
C>Ты можешь гарантировать, что если SL получит распространение, то МС в один день не перестанет разрабатывать версии для Маков? Ну или даже просто выпускать их с опозданием на год-два.
А разве поддержку SL под мак делает MSFT? Ничего не путаете?
Здравствуйте, Qbit86, Вы писали:
A>>По-моему важно уметь эффективно программировать хотя бы на одном распространенном языке, а не бессмысленно изучать по 15 штук, и превращаться в языковеда, вместо того чтобы больше внимания уделить проектированию, прикладной математике. Q>Программист на C++ не может в полной мере уделять внимание проектированию и прикладной математике, потому что он должен уделять это внимание языку.
Можно писать просто как С с классами. Никто не заставляет везде использовать шаблоны.
A>>С++ интересен огромным числом библиотек. Q>Разношёрстных, неконсистентных библиотек.
Почему? Например, в wxWidgets — уже есть хорошая готовая бесплатная база удобных эффективных библиотек.
Про Qt — и так все знают. Многие говорят даже так: "Зачем вообще джава, если есть кьют?"
Здравствуйте, SE, Вы писали:
SE>Здравствуйте, Cyberax, Вы писали:
C>>Ты можешь гарантировать, что если SL получит распространение, то МС в один день не перестанет разрабатывать версии для Маков? Ну или даже просто выпускать их с опозданием на год-два.
SE>А разве поддержку SL под мак делает MSFT? Ничего не путаете?
Здравствуйте, Qbit86, Вы писали:
Q>Программист на C++ не может в полной мере уделять внимание проектированию и прикладной математике, потому что он должен уделять это внимание языку.
Не проецируй свои неспособности на всех.
A>>С++ интересен огромным числом библиотек. Q>Разношёрстных, неконсистентных библиотек.
Читай: не от одного поставщика?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Qbit86, Вы писали:
RO>>Проблема-то в том, что для последовательности букв, которую майкрософтовский компилятор C# считает программой на C#, Mono может и не осилить создать исполняемый файл. Q>Есть и примеры обратного — в «догоняющем» Mono уже есть фичи (compiler as service), которые будут доступны в майкрософтовском компиляторе только через версию, в 5.0.
В итоге бардак. Прога на MS.NET может не завестись в mono равно как и прога под mono может не завестись под MS.NET
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Anonim12, Вы писали:
A>Мы как раз отличаемся, как минимум в выборе основного языка.
Если прикинуть примерную статистику по обеим сторонам (условно «плюсисты» и «шарперы») последних холиваров на RSDN, то получается следующее. Основное отличие между среднестатистическим «шарпером» и среднестатистическим «плюсистом» в том, что «шарпер» знаком как с технологиями C++, так и с технологиями .NET, а заядлый «плюсист» ничего (по большему счёту) кроме плюсов не видел. (Краткая суть предыдущего предложения: 1 + 1 > 1.) Разумеется, «слышал звон на cybersecurity» и статьи в Википедии за ознакомление с технологией не засчитывается. Мозг «плюсистов» заполнен стереотипами типа «тормозит», «быдлокодеры», «Империя Зла», «у вас негров линчуют» и прочим булшитом.
A>Мы как раз отличаемся, как минимум в выборе основного языка.
Основное отличие как раз не в этом, а в том, что «шарперы» делают свой выбор осознанно, на основе опыта разработки как на C++, так и на .NET. А «плюсисты» делают свой «выбор» на основе всяких «общих рассуждений», подогнанных под удобную точку зрения. (Чёрт, не могу найти тот демотиватор, в тему иллюстрирующий «плюсистов».)
P.S. Повторю, что под «плюсистами» и «шарперами» я понимаю не вообще программистов на C++ и C#, это просто условное обозначение противоборствующих сторон (диалектика, фигли) последних веток КСВ.
Здравствуйте, Qbit86, Вы писали:
Q>Если прикинуть примерную статистику по обеим сторонам (условно «плюсисты» и «шарперы») последних холиваров на RSDN, то получается следующее. Основное отличие между среднестатистическим «шарпером» и среднестатистическим «плюсистом» в том, что «шарпер» знаком как с технологиями C++, так и с технологиями .NET, а заядлый «плюсист» ничего (по большему счёту) кроме плюсов не видел. (Краткая суть предыдущего предложения: 1 + 1 > 1.) Разумеется, «слышал звон на cybersecurity» и статьи в Википедии за ознакомление с технологией не засчитывается. Мозг «плюсистов» заполнен стереотипами типа «тормозит», «быдлокодеры», «Империя Зла», «у вас негров линчуют» и прочим булшитом.
Здравствуйте, CreatorCray, Вы писали:
Q>>Разношёрстных, неконсистентных библиотек.
CC>Читай: не от одного поставщика? :))
Читай: неединообразных, разноуровневых (plain C API, Си-с-классами, шаблонные), с разными соглашениями об именовании, с разными подходами к проектированию, с противоположными требованиями к вызывающему коду. Сопрягать этот зоопарк (врапперы, прокси) — то ещё удовольствие.
Здравствуйте, Anonim12, Вы писали:
A>Можно писать просто как С с классами. Никто не заставляет везде использовать шаблоны.
Куда ж без них, родимых? Без назквозь шаблонных Boost.Function + Boost.Bind в плюсах практически нельзя манипулировать ФВП, толку мне от Си-с-классами?
S> > Могу, если вам нужна кроссплатформенность, то лучше смотреть в сторону веба, а не писать кроссплатформенный фреймворк на С++.
S> Угу, правильно. Лучше пусть тормозит, ибо к трудностям мы непрывычные. S> Так?
Кроссплатформенный софт на С++ — это тоже не сахар.
Здравствуйте, Qbit86, Вы писали:
Q>Если прикинуть примерную статистику по обеим сторонам (условно «плюсисты» и «шарперы») последних холиваров на RSDN, то получается следующее. Основное отличие между среднестатистическим «шарпером» и среднестатистическим «плюсистом» в том, что «шарпер» знаком как с технологиями C++, так и с технологиями .NET, а заядлый «плюсист» ничего (по большему счёту) кроме плюсов не видел. (Краткая суть предыдущего предложения: 1 + 1 > 1.)
Я наверное буду исключением. Можно сказать тоже "как бы" из лагеря C++, но ещё очень много писал на асме во времена DOS, Pascal, Watcom C++. После Win95: RAD Delphi, Builder, MFC C++ (COM+), Access VBA, VB6, немного знаком с Python, Standard ML, также знаком c С# .NET — но после осознания политики MS уже желания на нём писать нет никакого, сейчас wxWidgets и Qt, для Web: Apache + PHP, Perl (Mysql, sqlite); lighttpd + FastCGI + C++.
Q>Разумеется, «слышал звон на cybersecurity» и статьи в Википедии за ознакомление с технологией не засчитывается. Мозг «плюсистов» заполнен стереотипами типа «тормозит», «быдлокодеры», «Империя Зла», «у вас негров линчуют» и прочим булшитом.
Это cкорее приколы кодеров с ЛОРа. Там такое действительно бывает. Они вообще могут сказать при упоминании .NET : "не трогайте разбухший труп"
Q>Основное отличие как раз не в этом, а в том, что «шарперы» делают свой выбор осознанно, на основе опыта разработки как на C++, так и на .NET. А «плюсисты» делают свой «выбор» на основе всяких «общих рассуждений», подогнанных под удобную точку зрения. (Чёрт, не могу найти тот демотиватор, в тему иллюстрирующий «плюсистов».)
У меня другая точка зрения. «Плюсисты» делают свой выбор осознанно, на основе печального опыта разработки используя глючные и закрытые инструменты Microsoft. А «шарперы» делают свой «выбор» на основе пиара от Microsoft и всяких «общих рассуждений» о крутости «технологий» доступа к данным, подогнанных под удобную точку зрения корпорации.
Q>P.S. Повторю, что под «плюсистами» и «шарперами» я понимаю не вообще программистов на C++ и C#, это просто условное обозначение противоборствующих сторон (диалектика, фигли) последних веток КСВ.
Здравствуйте, Qbit86, Вы писали:
A>>Можно писать просто как С с классами. Никто не заставляет везде использовать шаблоны. Q>Куда ж без них, родимых? Без назквозь шаблонных Boost.Function + Boost.Bind в плюсах практически нельзя манипулировать ФВП, толку мне от Си-с-классами?
Здравствуйте, Qbit86, Вы писали:
F>>учитывая, что это пишет "шарпер", делаем выводы Q>Учитывай лучше то, что это пишет вчерашний «плюсист».
Причем, судя по тону "ниасиливший, и оттого комплексующий, 'плюсист'"
Взрослые дяди спокойно пишут на том из известных им языков, который лучше других подходит под задачу. И кстати не кричат что язык Х подходит ваще под все задачи поэтому он лучше языка Y, пишущие на котором должны немедленно умереть от рака мозга. И не кривят презрительно морду, дескать "мы выше этого, это для лохов".
Флеймеры блин, угомонитесь!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Anonim12, Вы писали:
A>...но после осознания политики MS уже желания на нём писать нет никакого, сейчас wxWidgets и Qt...
Интересно, а почему вдруг Qt? Ведь до недавнего времени политика Trolltech (или Nokia?) была гораздо жёстче, чем политика Microsoft в отношении бесплатного .NET-фреймворка, не требующего отчислений за его коммерческое использование?
Здравствуйте, CreatorCray, Вы писали:
F>>>учитывая, что это пишет "шарпер", делаем выводы Q>>Учитывай лучше то, что это пишет вчерашний «плюсист». CC>Причем, судя по тону "ниасиливший, и оттого комплексующий, 'плюсист'"
Скорее человек, который узнал каким может быть язык и платформа — простыми, удобными, но одновременно мощными и функциональными, а от того осознал на сколько убог С++ по нынешним меркам.
Здравствуйте, Qbit86, Вы писали:
F>>как люди до буста жили, ума не приложу..
Q>Развлекались наскальной живописью. Не всем, правда, такое хобби по душе.
Отсутствие буста на начальных порах породило армию последователей Александреску...
Здравствуйте, CreatorCray, Вы писали:
CC>Взрослые дяди спокойно пишут на том из известных им языков, который лучше других подходит под задачу.
Кстати, давненько мне не встречалось задач, для которых С++ подходил бы больше, чем .NET или Java.
Здравствуйте, Qbit86, Вы писали:
A>>...но после осознания политики MS уже желания на нём писать нет никакого, сейчас wxWidgets и Qt... Q>Интересно, а почему вдруг Qt? Ведь до недавнего времени политика Trolltech (или Nokia?) была гораздо жёстче, чем политика Microsoft в отношении бесплатного .NET-фреймворка, не требующего отчислений за его коммерческое использование?
Так ведь Trolltech жила за счёт этих отчислений. При этом они честно делали кроссплатформенный продукт — это у них фича такая была.
Здравствуйте, gandjustas, Вы писали:
RO>>Проблема-то в том, что для последовательности букв, которую майкрософтовский компилятор C# считает программой на C#, Mono может и не осилить создать исполняемый файл. G>Пример в студию. G>Mono2 полностью поддерживает C# 3.0
Я рад за Мигеля. Но много ли толку от C# x.y, если в Mono нет последних версий .NET Framework?
Здравствуйте, criosray, Вы писали:
CC>>Взрослые дяди спокойно пишут на том из известных им языков, который лучше других подходит под задачу. C>Кстати, давненько мне не встречалось задач, для которых С++ подходил бы больше, чем .NET или Java.
Это говорит лишь о том, что ты крутишься в той области, где такие задачи не встречаются.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, CreatorCray, Вы писали:
F>>>>учитывая, что это пишет "шарпер", делаем выводы Q>>>Учитывай лучше то, что это пишет вчерашний «плюсист». CC>>Причем, судя по тону "ниасиливший, и оттого комплексующий, 'плюсист'"
C>Скорее человек, который узнал каким может быть язык и платформа — простыми, удобными, но одновременно мощными и функциональными, а от того осознал на сколько убог С++ по нынешним меркам.
Опять флейм начинаешь? Простота, удобство и мощность понятия косвенные.
Давай лучше сойдемся на том, что "инструмент выбираем по задаче" и "серебряной пули не бывает".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Qbit86, Вы писали:
A>>...но после осознания политики MS уже желания на нём писать нет никакого, сейчас wxWidgets и Qt... Q>Интересно, а почему вдруг Qt? Ведь до недавнего времени политика Trolltech (или Nokia?) была гораздо жёстче, чем политика Microsoft в отношении бесплатного .NET-фреймворка, не требующего отчислений за его коммерческое использование?
Да, конечно. Сейчас всё поменялось в лучшую сторону. Кроме этого, Qt можно сказать как бы дополняет wxWidgets.
Вот что я имею ввиду — wxWidgets удобен для написания ультрабыстрых кроссплатформенных программ малого размера. А Qt — для больших кроссплатформенных проектов, где важнее богатая функциональность при высокой скорости разработки.
F> Q>Куда ж без них, родимых? Без назквозь шаблонных Boost.Function + Boost.Bind в плюсах практически нельзя манипулировать ФВП, толку мне от Си-с-классами?
F> как люди до буста жили, ума не приложу..
Тут уже был флейм по поводу, "а зачем буст". Из всего буста народ пользуется довольно малой частью
CC> C>Скорее человек, который узнал каким может быть язык и платформа — простыми, удобными, но одновременно мощными и функциональными, а от того осознал на сколько убог С++ по нынешним меркам.
CC> Опять флейм начинаешь? Простота, удобство и мощность понятия косвенные. CC> Давай лучше сойдемся на том, что "инструмент выбираем по задаче" и "серебряной пули не бывает".
Ненене Мы в КСВ или где? Кто согласен, поставит плюсик, а флейм вспыхнет новой силой
Здравствуйте, Anton Batenev, Вы писали:
AB>Он существует, но как Неуловимый Джо. Вроде и есть, но мало кому нужен. Связано это как с большими рисками в отношении лицензионной политики MS (фиг знает, что им придет завтра в голову), так и с отсутствием реальной кросс-платформенности.
По поводу рисков. Во-первых, между Novell (которому принадлежит Mono) и Microsoft существует патентное "соглашение о не нападении". Во-вторых, потенциальные лицензионные иски возможны только в отношении некоторых майкросовтовских библиотек, таких как WinForms, ASP.NET и пр. Но ничего не мешает использовать opensource аналоги, коих полно, и как следствие иметь гарантированную лицензионную чистоту.
Здравствуйте, Mamut, Вы писали:
M>Ненене Мы в КСВ или где? Кто согласен, поставит плюсик, а флейм вспыхнет новой силой
чОрт!
Только массовые расстрелы спасут RSDN!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, mrTwister, Вы писали:
T>По поводу рисков. Во-первых, между Novell (которому принадлежит Mono) и Microsoft существует патентное "соглашение о не нападении". Во-вторых, потенциальные лицензионные иски возможны только в отношении некоторых майкросовтовских библиотек, таких как WinForms, ASP.NET и пр. Но ничего не мешает использовать opensource аналоги, коих полно, и как следствие иметь гарантированную лицензионную чистоту.
А нафиг тогда .NET вообще? Проще взять Java, где всё нормально с лицензией и реальной кроссплатформенностью.
Тем более, что под .NET до сих пор не так уж и много OpenSource-библиотек по сравнению с той же Java.
Здравствуйте, ambel-vlad, Вы писали: AV>Я уже писал. На данный момент на этом сервере крутятся приложения написанные на .NET, Java, Python, Ruby и старые знакомые C/C++. Еще заказчик пробует Ocaml. Есть еще биндинг для Перла.
Прекрасно. То есть J#, IronPython и F#. Крутить там старых знакомых — очень-очень смелый ход. С учетом того, что фрагменты поставляются программистами неизвестной заранее квалификации.
AV>А на чем ты предлагаешь писать сервер, который может работать взаимодействовать с кодом на любом языке?
На чем угодно. Взаимодействие с другим кодом от языка не зависит. Если интересует Windows ABI, то есть DLL и всё такое — никаких проблем. Если интересует большая платформенная независимость — никаких проблем, хоть Named Pipes хоть XML/HTTP.
Что вы называете "взаимодействием"?
AV>Тем более, что стоит учитывать, что проект начинался не в 2009 году, а в 2005.
Ну, то есть когда уже был дотнет 2.0.
AV>ОК. Еще раз. Вот у тебя сервер на .NET. Тебе надо дернуть код написанный на Java или Питон. Какие переходы будут сделаны? Из .NET в unmanaged. И из unmanaged в Java или Питон. Так?
Нет. IronPython исполняется в управляемой среде. Никакого интеропа. С джавой чуть похитрее, да.
S>>И не хватало бы скорости.
AV>Да, скорости было бы в притык к требованиям. Проверяли. Да и с переносимостью кода между системами до сих пор не все так прекрасно как хотелось бы. Mono далеко не всегда спасает. Тем более в то время когда начинался проект.
AV>>>А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал. S>>С другими платформами вопрос достаточно тонкий. S>>Поэтому сервера приложений сейчас в основном пишут на java. AV>И как у них с вызовами кода из других языков, которые не изпользуют JVM?
Точно также — JNI и вперед, на танки. Это если очень охота выстрелить себе в ногу. В сервере приложений лучше этого избегать — нет там задач, в которых нужен код на неуправляемом языке. AV>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>>>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>>>>>>Вот почему не будет client profile на 30 метров. CC>>>>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>>>>В чем непреодолимая трудность то? G>>>>А зачем? Берете онлайн инсталлер и качаете то что нужно. C>>>Есть масса случаев (ситуаций), когда нет возможности качать онлайновым инсталлятором. G>>Скачивание версии для одной конкретной платформы вряд ли относится к этим случаям. C>Кто говорил что-то о выкачивании? Оффлайновый инсталлятор потому и оффлайновый, что его можно включить в пакет инсталляции, распространяемый на DVD.
Ну так и пихайте на DVD полновесный инсталлер, который гарантированно установит фреймворк на любой комп, в чем проблема?
Здравствуйте, Anonim12, Вы писали:
A>По-моему важно уметь эффективно программировать хотя бы на одном распространенном языке, а не бессмысленно изучать по 15 штук, и превращаться в языковеда, вместо того чтобы больше внимания уделить проектированию, прикладной математике. Ведь программирование — это в первую очередь прикладная математика, а не лингвистика. Кстати, именно поэтому Intel делает ставку на C++ и Фортран.
Какое у вас узкое представление о программировании. Это всё равно, что говорить, что спиртные напитки — это в первую очередь водка, иногда с пивом. Современное программирование — это в первую очередь лингвистика. Потому что оно сводится к переводу спецификаций с одних языков на другие. Именно поэтому, кстати, Интел делает ставку на разработку универсальной оптимизирующей платформы, пригодной как для статической компиляции, так и динамического инструментирования управляемого кода.
A>Фортран широко используется в первую очередь для научных и инженерных вычислений.
А также во вторую, третью, и четвертую очереди фортран используется только для них же.
Что, в общем-то, логично. Глупо ожидать могучих алгоритмов обработки текстов от языка, в котором нормальная поддержка строк появилась на закате популярности
A> Одно из преимуществ современного Фортрана — большое количество написанных на нём программ и библиотек подпрограмм. Среди учёных, например, ходит такая присказка, что любая математическая задача уже имеет решение на Фортране, и, действительно, можно найти среди тысяч фортрановских пакетов и пакет для перемножения матриц, и пакет для решения сложных интегральных уравнений, и многие, многие другие. Ряд таких пакетов создавались на протяжении десятилетий и популярны (главным образом в научной среде) по сей день.
Отлично. Осталось понять, какую долю вычислений, выполняемых среднестатистическим современным компьютером, составляют матрицы (кроме 4*4, которые чудесно умножаются аппаратно в акселераторе видеоплаты) и сложные интегральные уравнения.
Осталось понять, какая из этих библиотек поможет написать, к примеру, отказоустойчивый масштабируемый сервер аудиовидеоконференций.
A>С++ интересен огромным числом библиотек. Распространенность, кроссплатформенность, гибкость и мощь языка привлекает большое число серьёзных программистов. С++ де-факто представляет собой промышленный стандарт. Содержит средства создания эффективных программ практически любого назначения, от низкоуровневых утилит и драйверов до сложных программных комплексов. Поддерживает различные стили и технологии программирования, включая традиционное директивное программирование, ООП. Имеется возможность работы на низком уровне с памятью, адресами, портами. Доступны компиляторы для большого количества платформ. Язык спроектирован так, чтобы дать программисту максимальный контроль над всеми аспектами структуры и порядка исполнения программы.
Приколись, чувак, я это еще в 1993 году знал. Только я с тех пор еще много чего узнал, чего и тебе желаю.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, vit.rsdn, Вы писали:
VR>>объяснить, где и в чем питон "рвёт" РНР
KV>Пайтон строго типизирован. В принципе, этого уже достаточно.
Ну также строго как PHP.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>ОК. Еще раз. Вот у тебя сервер на .NET. Тебе надо дернуть код написанный на Java или Питон. Какие переходы будут сделаны? Из .NET в unmanaged. И из unmanaged в Java или Питон. Так? Вот тебе и двойной интероп. В нашем случае только один переход между managed и unmanaged.
G>>Так у вас все в одном процессе крутится?
AV>Если есть возможность, то все компоненты одного приложения могут крутиться в одном процессе. А могут и в нескольких. А могут и совсем на разных машинах. Как сконфигурируешь сервак, так и будет.
Тогда к чему разговры о тормознутости интеропа если передача по TCP на другой сервер будет во много раз медленее?
Здравствуйте, Anonim12, Вы писали:
A>Здравствуйте, Qbit86, Вы писали:
Q>>Если прикинуть примерную статистику по обеим сторонам (условно «плюсисты» и «шарперы») последних холиваров на RSDN, то получается следующее. Основное отличие между среднестатистическим «шарпером» и среднестатистическим «плюсистом» в том, что «шарпер» знаком как с технологиями C++, так и с технологиями .NET, а заядлый «плюсист» ничего (по большему счёту) кроме плюсов не видел. (Краткая суть предыдущего предложения: 1 + 1 > 1.)
A>Я наверное буду исключением. Можно сказать тоже "как бы" из лагеря C++, но ещё очень много писал на асме во времена DOS, Pascal, Watcom C++. После Win95: RAD Delphi, Builder, MFC C++ (COM+), Access VBA, VB6, немного знаком с Python, Standard ML, также знаком c С# .NET — но после осознания политики MS уже желания на нём писать нет никакого, сейчас wxWidgets и Qt, для Web: Apache + PHP, Perl (Mysql, sqlite); lighttpd + FastCGI + C++.
"знаком c С# .NET" — это почитал статью в википедии?
"после осознания политики MS" — это почитал ЛОР?
Вы уже показали на этом форуме свое незнание .NET, слабое представление о развитии отрасли программирования и текущей необходимости разработки.
Не надо теперь понтоваться своими "достижениями".
Q>>Основное отличие как раз не в этом, а в том, что «шарперы» делают свой выбор осознанно, на основе опыта разработки как на C++, так и на .NET. А «плюсисты» делают свой «выбор» на основе всяких «общих рассуждений», подогнанных под удобную точку зрения. (Чёрт, не могу найти тот демотиватор, в тему иллюстрирующий «плюсистов».)
A>У меня другая точка зрения. «Плюсисты» делают свой выбор осознанно, на основе печального опыта разработки используя глючные и закрытые инструменты Microsoft.
Большенство убежденных плюсистов, не написали ни одной программы на .NET, а сам фреймворк видели еще версии 1.1
A>А «шарперы» делают свой «выбор» на основе пиара от Microsoft и всяких «общих рассуждений» о крутости «технологий» доступа к данным, подогнанных под удобную точку зрения корпорации.
А с чего вы взяли что MS что-то так сильно пиарит? Вы посмотрите доклады с PDC, ни в одном нет голого пиара, везде вполне рабочие технологии показаны. Использовать их или нет — ваше право.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Qbit86, Вы писали:
F>>>учитывая, что это пишет "шарпер", делаем выводы Q>>Учитывай лучше то, что это пишет вчерашний «плюсист». CC>Причем, судя по тону "ниасиливший, и оттого комплексующий, 'плюсист'"
CC>Взрослые дяди спокойно пишут на том из известных им языков, который лучше других подходит под задачу. И кстати не кричат что язык Х подходит ваще под все задачи поэтому он лучше языка Y, пишущие на котором должны немедленно умереть от рака мозга. И не кривят презрительно морду, дескать "мы выше этого, это для лохов".
Только не дает покоя "плюсистам" мысль о том что C++ подходит далеко не для всех задач, для которых он используется.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>По поводу рисков. Во-первых, между Novell (которому принадлежит Mono) и Microsoft существует патентное "соглашение о не нападении". Во-вторых, потенциальные лицензионные иски возможны только в отношении некоторых майкросовтовских библиотек, таких как WinForms, ASP.NET и пр. Но ничего не мешает использовать opensource аналоги, коих полно, и как следствие иметь гарантированную лицензионную чистоту. C>А нафиг тогда .NET вообще? Проще взять Java, где всё нормально с лицензией и реальной кроссплатформенностью.
C>Тем более, что под .NET до сих пор не так уж и много OpenSource-библиотек по сравнению с той же Java.
codeplex.com несколько поколебает ваши утверждения
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, gandjustas, Вы писали:
RO>>>Проблема-то в том, что для последовательности букв, которую майкрософтовский компилятор C# считает программой на C#, Mono может и не осилить создать исполняемый файл. G>>Пример в студию. G>>Mono2 полностью поддерживает C# 3.0
RO>Я рад за Мигеля. Но много ли толку от C# x.y, если в Mono нет последних версий .NET Framework?
Хватит уже одно и тоже повторять, правдой оно не станет.
Mono не будет иметь всех enterprise фич платформы .NET, оно ему и не надо.
Моно — кросплатформенная библиотека, поэтому основной прицел у них на десктоп.
Кроме того рантайм и библиотека моно позволяют выкинуть ненужные части и использовать его во всяких устройствах на базе *nix.
Здравствуйте, vit.rsdn, Вы писали:
C>>Тем более, что под .NET до сих пор не так уж и много OpenSource-библиотек по сравнению с той же Java. VR>codeplex.com несколько поколебает ваши утверждения
Где там аналог JBoss Rules? Как насчёт _нормального_ открытого аналога JBPM? А нормального LDAP-сервера, типа Apache Directory Server, случайно там нет? А где бы взять аналог GWT?
На codeplex — куча непонятного унылого г., среди которого иногда попадаются нормальные проекты. Примерно как на codeproject до этого.
Здравствуйте, gandjustas, Вы писали:
RO>>Я рад за Мигеля. Но много ли толку от C# x.y, если в Mono нет последних версий .NET Framework? G>Хватит уже одно и тоже повторять, правдой оно не станет. G>Mono не будет иметь всех enterprise фич платформы .NET, оно ему и не надо.
Гнилая отмазка. WPF не нужен на десктопе, например? А его ещё ооооочень долго не будет в Mono.
Если бы MS серьёзно делала кросс-платформеный фреймворк, то никто не мешал бы им портировать и enterprise-фичи. У SUN это ведь как-то получилось, значит это не невозможно.
G>Моно — кросплатформенная библиотека, поэтому основной прицел у них на десктоп. G>Кроме того рантайм и библиотека моно позволяют выкинуть ненужные части и использовать его во всяких устройствах на базе *nix.
Оно на этих устройствах на три буквы никому не сдалось.
Здравствуйте, Sinclair, Вы писали:
AV>>Я уже писал. На данный момент на этом сервере крутятся приложения написанные на .NET, Java, Python, Ruby и старые знакомые C/C++. Еще заказчик пробует Ocaml. Есть еще биндинг для Перла. S>Прекрасно. То есть J#
J# — это вымысел, горячечный бред. Его не существует.
Здравствуйте, gandjustas, Вы писали:
C>>Кто говорил что-то о выкачивании? Оффлайновый инсталлятор потому и оффлайновый, что его можно включить в пакет инсталляции, распространяемый на DVD. G>Ну так и пихайте на DVD полновесный инсталлер, который гарантированно установит фреймворк на любой комп, в чем проблема?
На мой ноут, например, .NET 3.5 уже не устанавливается — инсталлятор выпадает с ошибкой (в Windows Update висят 4 патча для .NET, которые тоже не устанавливаются). Почему — лень разбираться.
От знакомых, которые делают бухгалтерский софт на .NET — похожая ситуация у многих.
Здравствуйте, gandjustas, Вы писали:
G>Вы уже показали на этом форуме свое незнание .NET, слабое представление о развитии отрасли программирования и текущей необходимости разработки.
Хорошо-хорошо. Пусть будет по вашему. Показал слабое представление о развитии отрасли программирования а-ля Microsoft... И слава Богу.
G>А с чего вы взяли что MS что-то так сильно пиарит? Вы посмотрите доклады с PDC, ни в одном нет голого пиара, везде вполне рабочие технологии показаны.
Ну так это и есть пиар. Описать новую "технологию" и показать как всё прекрасно. Как ещё может выглядеть пиар для программистов?
Вообще, у MS семь пятниц на неделе. Сегодня у них одна "технология", завтра — другая, послезавтра — третья и т.д. Нет никакого постоянства.
В одном месте они что-то прикручивают, в другом — отваливается, а потом следует перезагрузка и очередная "революция". А программеры пускай учат. Надо же развиваться.
Правда, если всё развитие заключается в постоянном переучивании очередных версий "технологий" от Майкрософт, то какой же смысл такого "развития" ?
Здравствуйте, gandjustas, Вы писали:
CC>>Взрослые дяди спокойно пишут на том из известных им языков, который лучше других подходит под задачу. И кстати не кричат что язык Х подходит ваще под все задачи поэтому он лучше языка Y, пишущие на котором должны немедленно умереть от рака мозга. И не кривят презрительно морду, дескать "мы выше этого, это для лохов".
G>Только не дает покоя "плюсистам" мысль о том что C++ подходит далеко не для всех задач, для которых он используется.
Насколько я вижу как раз плюсистам на это дело плевать. А вот некоторым другим, которые кстати так и норовят лишний раз напомнить, что дескать "предавалися еретическим деяниям и молилися лживому богу Сиплусплусу, но озарил их свет единственно верного святого Сишарпа Дотнетского, и отринули они языческие святыни, поправ их сапогами на форумах" почему то "мысль о том что C++ подходит далеко не для всех задач, для которых он используется" аж спать не даёт.
Хотя казалось бы, ну нашел ты то, что тебе больше по нраву — сиди и радуйся, раз тебе хорошо. Нет, блин, надо устроить крестовый поход и всех из флеймомёта обращать в свою веру, вне зависимости от того, хотят они или нет.
Я понимаю что КСВ, но блин фанаты с обеих сторон уже задрали!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
RO>>>Я рад за Мигеля. Но много ли толку от C# x.y, если в Mono нет последних версий .NET Framework? G>>Хватит уже одно и тоже повторять, правдой оно не станет. G>>Mono не будет иметь всех enterprise фич платформы .NET, оно ему и не надо. C>Гнилая отмазка. WPF не нужен на десктопе, например? А его ещё ооооочень долго не будет в Mono.
С WPF действительно зря они тормозят.
C>Если бы MS серьёзно делала кросс-платформеный фреймворк, то никто не мешал бы им портировать и enterprise-фичи. У SUN это ведь как-то получилось, значит это не невозможно.
А нужно ли оно MS?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Кто говорил что-то о выкачивании? Оффлайновый инсталлятор потому и оффлайновый, что его можно включить в пакет инсталляции, распространяемый на DVD. G>>Ну так и пихайте на DVD полновесный инсталлер, который гарантированно установит фреймворк на любой комп, в чем проблема? C>На мой ноут, например, .NET 3.5 уже не устанавливается — инсталлятор выпадает с ошибкой (в Windows Update висят 4 патча для .NET, которые тоже не устанавливаются). Почему — лень разбираться.
C>От знакомых, которые делают бухгалтерский софт на .NET — похожая ситуация у многих.
Прям сборище неудачников.
У всех моих знакомых нормально .NET любой версии ставится.
Здравствуйте, gandjustas, Вы писали:
G>У всех моих знакомых нормально .NET любой версии ставится.
В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Anonim12, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>А с чего вы взяли что MS что-то так сильно пиарит? Вы посмотрите доклады с PDC, ни в одном нет голого пиара, везде вполне рабочие технологии показаны. A>Ну так это и есть пиар. Описать новую "технологию" и показать как всё прекрасно. Как ещё может выглядеть пиар для программистов?
Работающая программа это пиар? Ну ладно, пусть пиар, кому от этого хуже...
A>Вообще, у MS семь пятниц на неделе. Сегодня у них одна "технология", завтра — другая, послезавтра — третья и т.д. Нет никакого постоянства.
Ну да, то что .NET продвигают последние 7 лет (и будут еще лет 5 как минимум) — не считается.
A>В одном месте они что-то прикручивают, в другом — отваливается, а потом следует перезагрузка и очередная "революция". А программеры пускай учат. Надо же развиваться.
Ну и где в очередной раз отвалилось?
A>Правда, если всё развитие заключается в постоянном переучивании очередных версий "технологий" от Майкрософт, то какой же смысл такого "развития" ?
Вы о чем говорите? я в 2006 году начал изучать .NET, с тех пор писал для десктопов, для веба, для мобильных устройств, писал серверные приложения с немалой нагрузкой, enterprise системы и мне ни разу не пришлось изучать новую платформу со своими идиомами, особенностями и прочим.
Здравствуйте, criosray, Вы писали:
C>Вы вообще видели VS 2k8 + Resharper 4.1 связку? Явно не видели...
Я видел . Хорошая, отличная функциональность . Главное что бы эта туша сломала тренд ресурсо-пожирания.
C>Как скорость может быть одинаковой, если нету ни мощных средств для рефакторинга, ни intellisense, ни удобных и быстрых средств для навигации по коду, ни средств для динамического анализа кода на соответствие определенным правилам, ни удобного отладчика, ни модуля для запуска модульных тестов, ни модуля для взаимодействия с системой контроля версий, ни модуля для дизайна схемы классов, ни модуля для дизайна форм, ни модуля для дизайна страниц, ни... много другого?
Ни в жисть не поверю, что для питона нету IDE.
Здравствуйте, gandjustas, Вы писали:
C>>Гнилая отмазка. WPF не нужен на десктопе, например? А его ещё ооооочень долго не будет в Mono. G>С WPF действительно зря они тормозят.
Кто "тормозят"? У Mono (Novell) никогда не будет достаточно ресурсов, чтобы вовремя дублировать все технологии MS.
C>>Если бы MS серьёзно делала кросс-платформеный фреймворк, то никто не мешал бы им портировать и enterprise-фичи. У SUN это ведь как-то получилось, значит это не невозможно. G>А нужно ли оно MS?
Нет, коненчо. Это же тогда может привести к тому, что будут покупать меньше Windows'ов!
Вот поэтому .NET — он портабельный только в теории, а не на практике.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали: G>>У всех моих знакомых нормально .NET любой версии ставится. CC>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей.
Да, но в том то и дело, что по словам Cyberax'а никакого багрепорта не было, им "лень разбираться".
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
CC>>>Взрослые дяди спокойно пишут на том из известных им языков, который лучше других подходит под задачу. И кстати не кричат что язык Х подходит ваще под все задачи поэтому он лучше языка Y, пишущие на котором должны немедленно умереть от рака мозга. И не кривят презрительно морду, дескать "мы выше этого, это для лохов".
G>>Только не дает покоя "плюсистам" мысль о том что C++ подходит далеко не для всех задач, для которых он используется. CC>Насколько я вижу как раз плюсистам на это дело плевать.
Странно, а кто же темы в КСВ создает?
CC>А вот некоторым другим, которые кстати так и норовят лишний раз напомнить, что дескать "предавалися еретическим деяниям и молилися лживому богу Сиплусплусу, но озарил их свет единственно верного святого Сишарпа Дотнетского, и отринули они языческие святыни, поправ их сапогами на форумах" почему то "мысль о том что C++ подходит далеко не для всех задач, для которых он используется" аж спать не даёт.
Этот поток создания остался для меня непонятен.
CC>Хотя казалось бы, ну нашел ты то, что тебе больше по нраву — сиди и радуйся, раз тебе хорошо. Нет, блин, надо устроить крестовый поход и всех из флеймомёта обращать в свою веру, вне зависимости от того, хотят они или нет.
Вера чаще всего свзаня с отрицанием фактов, получается что .NET это совсем не вера, а вот C++ очень даже.
Здравствуйте, gandjustas, Вы писали:
C>>От знакомых, которые делают бухгалтерский софт на .NET — похожая ситуация у многих. G>Прям сборище неудачников. G>У всех моих знакомых нормально .NET любой версии ставится.
Прости, но ставят софт не твоим знакомым, а бухгалтерам с пиратскими Windows, непонятно как работающими.
Я мог бы разобраться со своим ноутом. Но просто банально лень, тем более что ни одной нужной мне программы на .NET я не знаю.
Здравствуйте, MxKazan, Вы писали:
CC>>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей. MK>Да, но в том то и дело, что по словам Cyberax'а никакого багрепорта не было, им "лень разбираться".
и с каких пор разбираться почему падает — обязанность пользователя?
Здравствуйте, CreatorCray, Вы писали:
CC>Хотя казалось бы, ну нашел ты то, что тебе больше по нраву — сиди и радуйся, раз тебе хорошо. Нет, блин, надо устроить крестовый поход и всех из флеймомёта обращать в свою веру, вне зависимости от того, хотят они или нет.
Да нет же! Посмотри на последние темы КСВ! Они созданы не .Net девелоперами и не ради прославления .Net.
Здравствуйте, Antikrot, Вы писали:
CC>>>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей. MK>>Да, но в том то и дело, что по словам Cyberax'а никакого багрепорта не было, им "лень разбираться". A>и с каких пор разбираться почему падает — обязанность пользователя?
Предлагаешь Микрософту телепатически подключится к ноуту Cyberax'а и выяснить все проблемы? Конечно, в идеале всё должно всегда работать без проблем. Но такого не бывает практически ни с одной программой. И да, иногда пользователю приходится разбираться с проблемой или хотя-бы потрудится оповестить о проблеме разработчика. Просто потому, что всего на свете предусмотреть нельзя.
Здравствуйте, MxKazan, Вы писали:
CC>>Хотя казалось бы, ну нашел ты то, что тебе больше по нраву — сиди и радуйся, раз тебе хорошо. Нет, блин, надо устроить крестовый поход и всех из флеймомёта обращать в свою веру, вне зависимости от того, хотят они или нет. MK>Да нет же! Посмотри на последние темы КСВ! Они созданы не .Net девелоперами и не ради прославления .Net.
они созданы самыми на данный момент знатными провокаторами ни плюсы, ни до-диез тут ни при чём.
Здравствуйте, master_of_shadows, Вы писали:
C>>Вы вообще видели VS 2k8 + Resharper 4.1 связку? Явно не видели... __>Я видел . Хорошая, отличная функциональность . Главное что бы эта туша сломала тренд ресурсо-пожирания.
Ресурсы вот только жрёт как бесплатные. Надо было на одном проекте одновременно держать открытыми 4 студии с разными солюшенами — это была %опа. Пришлось решарпер снести и поставить VAX, иначе комп это все провернуть не мог.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MxKazan, Вы писали:
CC>>Хотя казалось бы, ну нашел ты то, что тебе больше по нраву — сиди и радуйся, раз тебе хорошо. Нет, блин, надо устроить крестовый поход и всех из флеймомёта обращать в свою веру, вне зависимости от того, хотят они или нет. MK>Да нет же! Посмотри на последние темы КСВ! Они созданы не .Net девелоперами и не ради прославления .Net.
Скатываются то всё равно в одно и то же.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>>>Только не дает покоя "плюсистам" мысль о том что C++ подходит далеко не для всех задач, для которых он используется. CC>>Насколько я вижу как раз плюсистам на это дело плевать. G>Странно, а кто же темы в КСВ создает?
Дай ка гляну:
безопасник kochetkov.vladimir
жавист race1
линухоид Sheridan
дотнетчик criosray
??? Aleх
??? kot2009
дотнетчик gandjustas
прям и не знаю даже
G>Этот поток создания остался для меня непонятен.
CC>>Хотя казалось бы, ну нашел ты то, что тебе больше по нраву — сиди и радуйся, раз тебе хорошо. Нет, блин, надо устроить крестовый поход и всех из флеймомёта обращать в свою веру, вне зависимости от того, хотят они или нет. G>Вера чаще всего свзаня с отрицанием фактов
Вера еще связана с фанатизмом и яростным говнополиванием "старой, неправильной веры". И еще очень много с чем связана.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MxKazan, Вы писали:
A>>и с каких пор разбираться почему падает — обязанность пользователя? MK>Предлагаешь Микрософту телепатически подключится к ноуту Cyberax'а и выяснить все проблемы? Конечно, в идеале всё должно всегда работать без проблем. Но такого не бывает практически ни с одной программой. И да, иногда пользователю приходится разбираться с проблемой или хотя-бы потрудится оповестить о проблеме разработчика. Просто потому, что всего на свете предусмотреть нельзя.
пользователь должен самостоятельно сделать только одно — сообщить о проблеме. дальнейшие разбирательства, как то запрос лога инсталляции и прочее, уже проблема техподдержки.
Здравствуйте, CreatorCray, Вы писали:
CC>Ресурсы вот только жрёт как бесплатные. Надо было на одном проекте одновременно держать открытыми 4 студии с разными солюшенами — это была %опа. Пришлось решарпер снести и поставить VAX, иначе комп это все провернуть не мог.
Угу. Я максимум 3-и штуки запускаю, и то редко, ибо даже два инстанса еле ворочаются.
Здравствуйте, MxKazan, Вы писали:
G>>>У всех моих знакомых нормально .NET любой версии ставится. CC>>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей. MK>Да, но в том то и дело, что по словам Cyberax'а никакого багрепорта не было, им "лень разбираться".
А кому в MS мне делать багрепорт? Я не знаю, чтобы у них был публичный багтрекер, где я бы мог следить за состоянием баги.
Здравствуйте, CreatorCray, Вы писали: G>>У всех моих знакомых нормально .NET любой версии ставится. CC>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей.
В приличных компаниях юзеру, который "поломал" себе винду, сначала мозги вправляют, потом оставляют без премии. После чего у всех остальных (а иногда и у самого злополучного юзера тоже) чудесным образом все ставится.
Hi gandjustas
AV>>>>ОК. Еще раз. Вот у тебя сервер на .NET. Тебе надо дернуть код написанный на Java или Питон. Какие переходы будут сделаны? Из .NET в unmanaged. И из unmanaged в Java или Питон. Так? Вот тебе и двойной интероп. В нашем случае только один переход между managed и unmanaged.
G>>>Так у вас все в одном процессе крутится?
AV>>Если есть возможность, то все компоненты одного приложения могут крутиться в одном процессе. А могут и в нескольких. А могут и совсем на разных машинах. Как сконфигурируешь сервак, так и будет.
G>Тогда к чему разговры о тормознутости интеропа если передача по TCP на другой сервер будет во много раз медленее?
А если в пределах одной машины? А одного процесса?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, ambel-vlad, Вы писали: AV>>Я уже писал. На данный момент на этом сервере крутятся приложения написанные на .NET, Java, Python, Ruby и старые знакомые C/C++. Еще заказчик пробует Ocaml. Есть еще биндинг для Перла. S>Прекрасно. То есть J#, IronPython и F#. Крутить там старых знакомых — очень-очень смелый ход.
Ага, неси седло. Начнем с того, что J# это совсем не Java. Во-вторых и толку от них, если надо именно Java, Python, а не то, что ты написал? А в-третих, как у этого добра с переносимостью на другие платформы? Только не надо про Mono. А учитывая времена начала проекта?
S>С учетом того, что фрагменты поставляются программистами неизвестной заранее квалификации.
А как оценить квалификацию программеров из Microsoft и других? Полагаться только на имя? А в данном случае заказчик имел возможность контролировать программеров и их код. И тестеры сидять у заказчика. Так что тут еще бабушка надвое сказала.
AV>>А на чем ты предлагаешь писать сервер, который может работать взаимодействовать с кодом на любом языке? S>На чем угодно. Взаимодействие с другим кодом от языка не зависит. Если интересует Windows ABI, то есть DLL и всё такое — никаких проблем. Если интересует большая платформенная независимость — никаких проблем, хоть Named Pipes хоть XML/HTTP.
Неее, конечно, можно многое нагородить. Только надо ли? А то и в Москву из Минска можно летать через НуЁрк, но я предпочиту, даже, на поезде через Смоленск. Не говоря про самолет напрямик.
S>Что вы называете "взаимодействием"?
Из кода, написанного на одном языке, дернуть код, написанный на другом языке.
AV>>Тем более, что стоит учитывать, что проект начинался не в 2009 году, а в 2005. S>Ну, то есть когда уже был дотнет 2.0.
И толку от него на Linux или на HP-UX?
AV>>ОК. Еще раз. Вот у тебя сервер на .NET. Тебе надо дернуть код написанный на Java или Питон. Какие переходы будут сделаны? Из .NET в unmanaged. И из unmanaged в Java или Питон. Так? S>Нет. IronPython исполняется в управляемой среде. Никакого интеропа. С джавой чуть похитрее, да.
Ты читать умеешь? Говорилось про Python, а не про IronPython. Итого получается два перехода. Для любого кода, который не скомпилиован в .NET.
S>>>И не хватало бы скорости.
AV>>Да, скорости было бы в притык к требованиям. Проверяли. Да и с переносимостью кода между системами до сих пор не все так прекрасно как хотелось бы. Mono далеко не всегда спасает. Тем более в то время когда начинался проект.
AV>>>>А если добавить и другие платформы, то дело совсем плохо. Потому что даже Mono не спасал. S>>>С другими платформами вопрос достаточно тонкий. S>>>Поэтому сервера приложений сейчас в основном пишут на java. AV>>И как у них с вызовами кода из других языков, которые не изпользуют JVM? S>Точно также — JNI и вперед, на танки. Это если очень охота выстрелить себе в ногу.
Ага, опять двойной интероп. А учитывая скорость JNI, то более менее частые переходы между разными языками положат производительность так, что и смотреть не захочется.
Здравствуйте, MxKazan, Вы писали:
A>>и с каких пор разбираться почему падает — обязанность пользователя? MK>Предлагаешь Микрософту телепатически подключится к ноуту Cyberax'а и выяснить все проблемы? Конечно, в идеале всё должно всегда работать без проблем. Но такого не бывает практически ни с одной программой. И да, иногда пользователю приходится разбираться с проблемой или хотя-бы потрудится оповестить о проблеме разработчика. Просто потому, что всего на свете предусмотреть нельзя.
У MS сплошные проблемы с устойчивостью и дизайном софта. Для установки .NET Runtime оно лезет куда попало, ставит какие-то системные сервисы оптимизации байт-кода и т.п. Естественно, всё это получается весьма хрупким.
А вот, к примеру, Sun JVM не требует установки вообще — её можно положить в каталог с твоим продуктом и оттуда запускать. Без всяких проблем. Соответственно, инсталлятор у неё тоже очень надёжный — он просто банально распаковывает Java в нужный каталог, и настраивает несколько ключей в реестре, ломаться нечему.
Здравствуйте, Cyberax, Вы писали:
C>Вот поэтому .NET — он портабельный только в теории, а не на практике.
Стоп, а кто-то говорил про портабельность всего .NET? Даже маркетологи MS о таком говорят очень осторожно.
Разговор ведь начался с того что на C# можно вести разработку на любой ОС, но никто не говорил о 100% кроссплатформенности любого кода на C#.
Никто даже не говорил что код на шарпе под винду спортируется под невинду.
Если хотите кросплатформенное приложение на .NET, берите моно и разрабатывайте на нем, тогда ваш код будет работать везде.
Здравствуйте, master_of_shadows, Вы писали:
CC>>Ресурсы вот только жрёт как бесплатные. Надо было на одном проекте одновременно держать открытыми 4 студии с разными солюшенами — это была %опа. Пришлось решарпер снести и поставить VAX, иначе комп это все провернуть не мог. __>Угу. Я максимум 3-и штуки запускаю, и то редко, ибо даже два инстанса еле ворочаются.
Я оставил VAX в результате. Он конечно попроще, но достаточен. А вот в скорости работы и потреблении вообще офигенная разница.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>>>ОК. Еще раз. Вот у тебя сервер на .NET. Тебе надо дернуть код написанный на Java или Питон. Какие переходы будут сделаны? Из .NET в unmanaged. И из unmanaged в Java или Питон. Так? Вот тебе и двойной интероп. В нашем случае только один переход между managed и unmanaged.
G>>>>Так у вас все в одном процессе крутится?
AV>>>Если есть возможность, то все компоненты одного приложения могут крутиться в одном процессе. А могут и в нескольких. А могут и совсем на разных машинах. Как сконфигурируешь сервак, так и будет.
G>>Тогда к чему разговры о тормознутости интеропа если передача по TCP на другой сервер будет во много раз медленее?
AV>А если в пределах одной машины?
В пределах одной машины есть пайпы, передача данных по ним тоже небыстрая, по сравнению с интеропными вызовами.
AV>А одного процесса?
А в пределах одного процесса я бы не стал запускать managed и unmanaged код.
Здравствуйте, CreatorCray, Вы писали:
CC>Я оставил VAX в результате. Он конечно попроще, но достаточен. А вот в скорости работы и потреблении вообще офигенная разница.
ReSharper — это реальность данная мне в ощущениях лецензионной политики компании . Так что или РеШарпер — или ничего.
Здравствуйте, master_of_shadows, Вы писали:
CC>>Я оставил VAX в результате. Он конечно попроще, но достаточен. А вот в скорости работы и потреблении вообще офигенная разница. __>ReSharper — это реальность данная мне в ощущениях лецензионной политики компании . Так что или РеШарпер — или ничего.
Соболезную. Мне повезло больше
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, ambel-vlad, Вы писали:
S>>Что вы называете "взаимодействием"? AV>Из кода, написанного на одном языке, дернуть код, написанный на другом языке.
Для этого уже существует много способов, самый универсальный — ws-* вебсервисы, инфраструктуру создавать не надо, оно уже есть.
На вебсервисах есть сотни систем, которые работают в том числе под высокой нагрузкой.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
A>>>и с каких пор разбираться почему падает — обязанность пользователя? MK>>Предлагаешь Микрософту телепатически подключится к ноуту Cyberax'а и выяснить все проблемы? Конечно, в идеале всё должно всегда работать без проблем. Но такого не бывает практически ни с одной программой. И да, иногда пользователю приходится разбираться с проблемой или хотя-бы потрудится оповестить о проблеме разработчика. Просто потому, что всего на свете предусмотреть нельзя. C>У MS сплошные проблемы с устойчивостью и дизайном софта. Для установки .NET Runtime оно лезет куда попало, ставит какие-то системные сервисы оптимизации байт-кода и т.п. Естественно, всё это получается весьма хрупким.
Всё это демагогия. Так ведут себя тонны разного софта под Винду, но их никто за это не клеймит. Да и написал я только о том, что если о проблеме не знает разработчик, то и решения этой проблемы требовать неправильно. Нам ли об этом не знать Или здесь только у меня не получалось создать серьезную и при этом абсолютно безглючную программу, на которую заказчик не написал ни одного фидбэка?
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, MxKazan, Вы писали: A>>>и с каких пор разбираться почему падает — обязанность пользователя? MK>>Предлагаешь Микрософту телепатически подключится к ноуту Cyberax'а и выяснить все проблемы? Конечно, в идеале всё должно всегда работать без проблем. Но такого не бывает практически ни с одной программой. И да, иногда пользователю приходится разбираться с проблемой или хотя-бы потрудится оповестить о проблеме разработчика. Просто потому, что всего на свете предусмотреть нельзя. A>пользователь должен самостоятельно сделать только одно — сообщить о проблеме. дальнейшие разбирательства, как то запрос лога инсталляции и прочее, уже проблема техподдержки.
Согласен. Слово "разбираться" употребил Cyberax, я только процитировал его. И позже добавил "хотя-бы потрудится оповестить о проблеме разработчика"
Здравствуйте, Cyberax, Вы писали:
C>А кому в MS мне делать багрепорт? Я не знаю, чтобы у них был публичный багтрекер, где я бы мог следить за состоянием баги. http://support.microsoft.com/gp/hublist/
Не знаю что там с трекером. Для WPF периодически натыкаюсь на подобное, но ссылку не вспомню.
Для грядущей Студии 2010 инсайдеры приводили на форуме линк куда слать сообщения об ошибках.
Hi gandjustas
AV>>А одного процесса? G>А в пределах одного процесса я бы не стал запускать managed и unmanaged код.
Почему? Если уверен к качесте unmanaged кода? И тем более есть возможность в случае необходимости в течении пары секунд сделать так, чтобы unmanaged код выполнялся в отдельном процессе?
А если есть два куска managed кода, но на разных языках?
Hi gandjustas
S>>>Что вы называете "взаимодействием"? AV>>Из кода, написанного на одном языке, дернуть код, написанный на другом языке. G>Для этого уже существует много способов, самый универсальный — ws-* вебсервисы, инфраструктуру создавать не надо, оно уже есть. G>На вебсервисах есть сотни систем, которые работают в том числе под высокой нагрузкой.
В случае заказчика этой скорости не хватало. Поэтому и пришлось создавать свою инфраструктуру.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
G>>"знаком c С# .NET" — это почитал статью в википедии? G>>"после осознания политики MS" — это почитал ЛОР?
F>я так понял, про питон ты даже этого не сделал
Конечно не сделал, я только написал пару программ на питоне для саморазвития, но руби мне больше приглянулся.
Здравствуйте, criosray, Вы писали: C>Как скорость может быть одинаковой, если нету ни мощных средств для рефакторинга, ни intellisense, ни удобных и быстрых средств для навигации по коду, ни средств для динамического анализа кода на соответствие определенным правилам, ни удобного отладчика, ни модуля для запуска модульных тестов, ни модуля для взаимодействия с системой контроля версий, ни модуля для дизайна схемы классов, ни модуля для дизайна форм, ни модуля для дизайна страниц, ни... много другого?
Теперь, внимание вопрос: "зачем все эти навороты нужны, если разработчиские задачи на Питане нормально и быстро решаются в notepad++?".
Вся это монстровая VS туша напоминает MS Office, где люди используют 5% фич, но за все остальные они тоже платят.
C>ни модуля для дизайна страниц,
PS. не разу не слыщал, что бы VS рекомедавался профессионалами для дизайна страниц. Обычно идут продукты Adobe.
Здравствуйте, Cyberax, Вы писали:
MK>>Да, но в том то и дело, что по словам Cyberax'а никакого багрепорта не было, им "лень разбираться". C>А кому в MS мне делать багрепорт? Я не знаю, чтобы у них был публичный багтрекер, где я бы мог следить за состоянием баги.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>А одного процесса? G>>А в пределах одного процесса я бы не стал запускать managed и unmanaged код.
AV>Почему? Если уверен к качесте unmanaged кода?
Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет. А если кто-то другой, то в принципе не могу быть уверенным что не упадет unmanaged и не утянет за собой кучу managed модулей.
AV>И тем более есть возможность в случае необходимости в течении пары секунд сделать так, чтобы unmanaged код выполнялся в отдельном процессе?
Тогда не совсем понял как реализован интероп, если так просто вынести в отдельный процесс.
AV>А если есть два куска managed кода, но на разных языках?
SOA и пайпы\TCP\HTTP как транспорт.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
S>>>>Что вы называете "взаимодействием"? AV>>>Из кода, написанного на одном языке, дернуть код, написанный на другом языке. G>>Для этого уже существует много способов, самый универсальный — ws-* вебсервисы, инфраструктуру создавать не надо, оно уже есть. G>>На вебсервисах есть сотни систем, которые работают в том числе под высокой нагрузкой.
AV>В случае заказчика этой скорости не хватало. Поэтому и пришлось создавать свою инфраструктуру.
Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
Здравствуйте, shrecher, Вы писали:
S>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
Питоньи программы довольно сложно распостранять без исходников. Особенно в линухе, как не смешно.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, shrecher, Вы писали:
S>>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
Pzz>Питоньи программы довольно сложно распостранять без исходников. Особенно в линухе, как не смешно.
Это решается с использованием правильных лицензий. Кроме того, скомпилированный C# читается более-менее легко, так что считать это какой-либо защитой не стоит.
Здравствуйте, shrecher, Вы писали:
Pzz>>Питоньи программы довольно сложно распостранять без исходников. Особенно в линухе, как не смешно.
S>Это решается с использованием правильных лицензий. Кроме того, скомпилированный C# читается более-менее легко, так что считать это какой-либо защитой не стоит.
Я не про защиту от подглядывания — я вообще в нее не верю, поскольку превратить программу на любом языке в читабельный текст — это чисто механическое усилие, решаемое вполне умеренными деньгами.
Но несмотря на это, у меня могут быть 1) причины не публиковать исходные тексты 2) причины не заставлять своих пользователей самостоятельно собирать программу.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>Для разных архитектур компа и разных ОС нужны разные бинарники фреймворка, онлайн интсаллер имеет возможность выкачать только то что надо, оффлайновый инсталлер должен таскать все. G>>Вот почему не будет client profile на 30 метров.
CC>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>В чем непреодолимая трудность то?
гм.... а ничего, в линуксе это такая работа "маленький инсталлятор для дистра + закачка из инета остального" считается нормой? Сможете найти дистр, к которому не нужен будет инет для любого применения (Не берем ДВД поставку)?
Здравствуйте, March_rabbit, Вы писали:
CC>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>В чем непреодолимая трудность то? M_>гм.... а ничего, в линуксе это такая работа "маленький инсталлятор для дистра + закачка из инета остального" считается нормой? Сможете найти дистр, к которому не нужен будет инет для любого применения (Не берем ДВД поставку)? Посмеялся, спасибо . Есть куча дистров, которым не нужен инет, это раз. А во вторых, где связь между дистрами Линуха и их установкой, и тем, что МС не выложила Фреймоворк разбитым на разные платформы?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Здравствуйте, vit.rsdn, Вы писали:
VR>>>объяснить, где и в чем питон "рвёт" РНР
KV>>Пайтон строго типизирован. В принципе, этого уже достаточно. G>Ну также строго как PHP.
Отнюдь, похоже ты путаешь динамическую/статическую и строгую/слабую типизацию.
Здравствуйте, criosray, Вы писали:
c> Почему нельзя? Можно. Но это будут члены класса торчащие наружу. В общем случае такой подход считается моветоном.
А делать простое get-set свойство, которое ни чем (по сути) не отличается? Хотя мне тут сказали про бинарную совместимость — это действительно повод для некоторых случаев.
Здравствуйте, vit.rsdn, Вы писали:
v> питон, где-то завис непонятно где и достоинств, что на нём пишут в Гугле и, может быть, в Яндексе, увы, мало
А какие аргументы считаются достаточными? Питон есть как данность. С возложенными на него задачами в его нише, как мы видим, вполне справляется. Каких "подвигов" ты от него еще хочешь?
v> кстати, чего там гугл не поддерживает полностью Django в своих Google Apps v> есть соображения?
Я не видел Google Apps в практическом использовании и не могу ничего сказать по этому поводу.
Здравствуйте, Mamut, Вы писали:
M> c> Есть масса случаев (ситуаций), когда нет возможности качать онлайновым инсталлятором. M> Скажите это линуксоидам с поголовно онлайновыми репохиториями
Здравствуйте, MxKazan, Вы писали:
MK> Или здесь только у меня не получалось создать серьезную и при этом абсолютно безглючную программу, на которую заказчик не написал ни одного фидбэка?
Тебе ли не знать, что абсолютно безглючных программ не бывает? А если заказчик не написал ни одного фидбэка — это повод задуматься, что что-то идет не так (например, программой не пользуются, или с некоторыми недостатками просто мирятся).
Здравствуйте, mrTwister, Вы писали:
T> По поводу рисков. Во-первых, между Novell (которому принадлежит Mono) и Microsoft существует патентное "соглашение о не нападении".
Если Novell / SuSe не будет преследоваться MS, это еще не говорит о том, что можно жить спокойно всему сообществу.
T> Во-вторых, потенциальные лицензионные иски возможны только в отношении некоторых майкросовтовских библиотек, таких как WinForms, ASP.NET и пр. Но ничего не мешает использовать opensource аналоги, коих полно, и как следствие иметь гарантированную лицензионную чистоту.
Я и так могу взять opensource аналоги, но без Mono, коих окажется на порядок больше. Где "сладкое"?
Здравствуйте, Anton Batenev, Вы писали:
MK>> Или здесь только у меня не получалось создать серьезную и при этом абсолютно безглючную программу, на которую заказчик не написал ни одного фидбэка? AB>Тебе ли не знать, что абсолютно безглючных программ не бывает? А если заказчик не написал ни одного фидбэка — это повод задуматься, что что-то идет не так (например, программой не пользуются, или с некоторыми недостатками просто мирятся).
Чё то я не понял Я об том же самом написал...
Здравствуйте, Anton Batenev, Вы писали:
AB>А делать простое get-set свойство, которое ни чем (по сути) не отличается? Хотя мне тут сказали про бинарную совместимость — это действительно повод для некоторых случаев.
Повод делать property — это более OO-way . В будущем, как уже заметили, будет меньше проблемм.
S> > Кроссплатформенный софт на С++ — это тоже не сахар.
S> Держи рецепт успеха: Qt
Нет. Истинная кроссплатформенность — это "write once, run everywhere" (написал однажды, запустил везде)
C++ с боооольшим натягом изредка предлагает "write once, compile everywhere" (написал однажды, скомпилировал везде)
Действительно серьезного большого кросплатформенного софта (и чтобы еще на слузу) на Qt я особо не видел. Ну, кроме Qoogle Earth и Skyope (который, несмотря на всю кросплатформенность Qt, для Линукса развивается с большим опозданием)
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Не, ну что за народ? Черным по белому читают выделенное, и тут же уточняют:
AF>Если сказал А — скажи и Б. То есть — какие языки более высокоуровневые
Здравствуйте, March_rabbit, Вы писали:
M_>несколько не в тему, но... M_>Вот сколько читаю споры шарповцев и других, все там речь идет о доступе к данным. Неужели эти языки применяются только для работы с БД?
Не замечал, чтобы эта тема как-то особенно в подобных спорах выделялась
M_>К чему вопрос: хочу изучить C# (после плюсов интересно), но работа со всякими БД никогда не интересовала.
А придется, если не хочешь в спорах глупо выглядеть
Здравствуйте, criosray, Вы писали:
KV>>А что пугает? C>Утверждение про низкоуровневость С#. Если С# низкоуровневый, то я даже и не знаю какой язык считать высокоуровневым. Разве что, упомянутый уже Пролог...
Я там спросил, может ты ответишь?
KV>>>>3. Он мешает развиваться дальше. C>>>Каким образом мешает-то? Наоборот, я уверен, многие про те же лямбды узнали только благодаря С#.
KV>>На мой взгляд, по перечисленным в исходном сообщении причинам, он создает иллюзию отсутствия необходимости в дальнейшем развитии разработчика при том, что арсенал средств, предоставляемых шарпом не такой уж и богатый.
C>Любой полный по Тьюрингу язык может создавать такую иллюзию. И что с того?
А может и не создавать. Вот виртовские языки, например, не создают
KV>>>>Ну вот собственно и все C>>>Так а чего "слазить надо"? Я так и не понял...
KV>>Да я видимо рановато обронил эту фразу, мне еще тяжело четко сформулировать свою т.з., при всей моей словоохотливости Последний год, я довольно много времени посвящал изучению различных средств, отсутствующих/отсутствовавших/неразвитых в шарпе. KV>Метапрограммирование, вывод типов, C>С# 3, больше в С# 4.
А когда зарелизится Nemerle, он вообще всех будет рвать, даже там, где не собирался. Ага.
KV>>неизменяемые объекты, C>С# 4
Это где там они?
KV>>динамическая типизация, C>С# 4
Ну тогда уж, частично-динамическая Язык как был, так и остался статически-типизированным.
KV>>азы функционального программирования, и т.п. C>Функциональные элементы были с самой первой версии и сильно развились с тех пор.
Что было функционального в первой версии?
C>Конечно многого еще нету, но не забывайте, что это все-таки императивный язык и его не так уж просто смешать с функциональщиной.
А главное — целесообразность этого смешивания, его авторы признали совсем недавно
C>Хотя F# в этом плане заметно дальше продвинулся.
он как-бы, с этого "плана" и начинался, вообще-то.
C>У каждого языка есть свои плюсы и минусы. С# это компромисс (и удачный) между рациональной функциональностью и объективной эффективностью. При всем при том он еще и массово распространен (в отличии от того же Nemerle или F#, к примеру). JIT архитектура позволяет делать очень интересные вещи (см. SpecSharp, Aspect#), сохраняя при этом производительность, присущую компиллируемым языкам и эффективный полноценный интероп с неуправляемым кодом.
Да я вроде нигде достоинств С# и не принижал, наоборот, писал, что он слишком хорош
KV>>А значит время на их изучение было потрачено не зря и об этом стоит рассказать здесь. Вдруг это поможет кому-нибудь еще открыть для себя новые горизонты развития? C>Но я все еще не понимаю зачем "нужно слазить с С#", а главное — куда.
Здравствуйте, Cyberax, Вы писали:
C>А нафиг тогда .NET вообще?
Отсутствие привязки к языку программирования, более современная и технологичная платформа, C# гораздо выразительнее явы, Linq, DLR и др.
C>Проще взять Java, где всё нормально с лицензией и реальной кроссплатформенностью.
У Моно тоже все нормально.
C>Тем более, что под .NET до сих пор не так уж и много OpenSource-библиотек по сравнению с той же Java.
Какая у тебя интересная классификация...
G>>Странно, а кто же темы в КСВ создает? CC>Дай ка гляну: CC>безопасник kochetkov.vladimir
Наверное все-таки дотнетчик в данном контексте. +можно и питонистом назвать, наверное.
CC>линухоид Sheridan
считающий себя плюсником...
еще тут отмечался в создании тем Роман Одайский (плюсник, питонист) и куча другого народа, о чьих специализациях мне ничего неизвестно. CC>прям и не знаю даже
G>>Вера чаще всего свзаня с отрицанием фактов CC>Вера еще связана с фанатизмом и яростным говнополиванием "старой, неправильной веры". И еще очень много с чем связана.
Отрицание фактов, как правило, является признаком того, что человек руководствуется верой, а не здравым смыслом. Он это имел ввиду, IMHO
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Гнилая отмазка. WPF не нужен на десктопе, например? А его ещё ооооочень долго не будет в Mono. G>>С WPF действительно зря они тормозят. C>Кто "тормозят"? У Mono (Novell) никогда не будет достаточно ресурсов, чтобы вовремя дублировать все технологии MS.
Sun тоже не дублирует все технологии MS, это кому-то мешает использовать яву?
Здравствуйте, mrTwister, Вы писали:
G>>>С WPF действительно зря они тормозят. C>>Кто "тормозят"? У Mono (Novell) никогда не будет достаточно ресурсов, чтобы вовремя дублировать все технологии MS. T>Sun тоже не дублирует все технологии MS, это кому-то мешает использовать яву?
Только вот Java не играет роль "догоняющего". Как ты думаешь, что будут использовать пользователи MS — интегрированые с VisualStudio продукты или OpenSource-решения, которые не интегрированы и по которым нет тысяч книг "Изучи blah-blah за 21 день"?
Здравствуйте, mrTwister, Вы писали:
C>>А нафиг тогда .NET вообще? T>Отсутствие привязки к языку программирования
Ага, с богатым выбором языков: C# или VB.
JVM тоже к языку не привязана — я вот сейчас пишу проект с Java, Groovy и немного Scala.
T>более современная и технологичная платформа
Спорно. JVM до сих пор технологичнее MS .NET VM (не говоря уж про Mono с его консервным сборщиком).
T>C# гораздо выразительнее явы
Это не мешает Java.
T>Linq, DLR и др.
Hibernate, JRuby, dynamic invoke.
C>>Проще взять Java, где всё нормально с лицензией и реальной кроссплатформенностью. T>У Моно тоже все нормально.
Нет.
C>>Тем более, что под .NET до сих пор не так уж и много OpenSource-библиотек по сравнению с той же Java. T>Как сравнивал?
Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось.
Здравствуйте, Mamut, Вы писали:
S>> Держи рецепт успеха: Qt M>Нет. Истинная кроссплатформенность — это "write once, run everywhere" (написал однажды, запустил везде) M>C++ с боооольшим натягом изредка предлагает "write once, compile everywhere" (написал однажды, скомпилировал везде)
Тут не согласен. Бинарная портируемость не особо-то нужна. Нормальной source code portability достаточно, тем более, что часто для каждой системы по мелочи надо затачивать определённые вещи.
M>И Qt поможет далеко не всегда: http://www.rsdn.ru/forum/message/3316885.1.aspx
Бывает...
M>Действительно серьезного большого кросплатформенного софта (и чтобы еще на слузу) на Qt я особо не видел. Ну, кроме Qoogle Earth и Skyope (который, несмотря на всю кросплатформенность Qt, для Линукса развивается с большим опозданием)
На Windows он просто Skype не использует, вроде.
Здравствуйте, MxKazan, Вы писали:
C>>А кому в MS мне делать багрепорт? Я не знаю, чтобы у них был публичный багтрекер, где я бы мог следить за состоянием баги. MK>http://support.microsoft.com/gp/hublist/
Ага, и меня пошлют к поддержке OEMа. Которая, вроде в Англии, заутсорсеная в Индию, где мне час придётся слушать индуса, читающего по бумажке. Оно мне надо?
MK>Не знаю что там с трекером. Для WPF периодически натыкаюсь на подобное, но ссылку не вспомню. MK>Для грядущей Студии 2010 инсайдеры приводили на форуме линк куда слать сообщения об ошибках.
Так проблемы не в Студии.
Здравствуйте, MxKazan, Вы писали:
C>>У MS сплошные проблемы с устойчивостью и дизайном софта. Для установки .NET Runtime оно лезет куда попало, ставит какие-то системные сервисы оптимизации байт-кода и т.п. Естественно, всё это получается весьма хрупким. MK>Всё это демагогия. Так ведут себя тонны разного софта под Винду, но их никто за это не клеймит.
То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM?
MK>Да и написал я только о том, что если о проблеме не знает разработчик, то и решения этой проблемы требовать неправильно. Нам ли об этом не знать Или здесь только у меня не получалось создать серьезную и при этом абсолютно безглючную программу, на которую заказчик не написал ни одного фидбэка?
К программе установки Sun JVM у меня вопросов никогда не возникало, например.
Здравствуйте, gandjustas, Вы писали:
C>>Вот поэтому .NET — он портабельный только в теории, а не на практике. G>Стоп, а кто-то говорил про портабельность всего .NET? Даже маркетологи MS о таком говорят очень осторожно. G>Разговор ведь начался с того что на C# можно вести разработку на любой ОС, но никто не говорил о 100% кроссплатформенности любого кода на C#.
Его нужно специально разрабатывать, аккуратно следя за портируемостью. И тут оказывается, что он не особо-то и лучше QT.
* C#: Most widely used CLI language, bearing similarities to C++ and Java. Implementations provided by .NET Framework, Portable.NET and Mono.
* C++/CLI: A version of C++ including extensions for using CLR objects. Implementation provided only .NET Framework. Can produce either CIL-based managed code or mixed-mode code that mixes both managed code as well as native code. The compiler is provided by Microsoft.
* F#: A multi-paradigm CLI language supporting functional programming as well as imperative object-oriented programming disciplines. Variant of ML and is largely compatible with OCaml. The compiler provided by Microsoft.
* J#: A CLS-compliant implementation of Java. The compiler is provided by Microsoft. Microsoft has announced that J# will be discontinued.
* Windows PowerShell: An object-oriented command-line shell. PowerShell can dynamically load .NET assemblies that were written in any CLI language. PowerShell itself uses a unique scripting syntax, uses curly-braces, similar to other C-based languages.
* JScript.NET: A CLI implementation of ECMAScript version 3, compatible with JScript. Contains extensions for static typing. Deprecated in favor of Managed JScript.
* IronPython: An open-source CLI implementation of Python, currently being re-designed to leverage the DLR.
* IronRuby: An open-source CLI implementation of Ruby, built on top of the DLR.
* Managed Extensions for C++: A version of C++ targeting the CLR. Deprecated in favor of C++/CLI.
* Managed JScript: A CLI implementation of JScript built using the Dynamic Language Runtime. Conforms to ECMAScript version 3.
* VBx: A dynamic version of VB.NET built on top of the Dynamic Language Runtime. See VBScript and VBA as this could be thought of being used like a Managed VBScript (though so far this name has not been applied to this) and could be used to replace VBA as well.
* VB.NET: A redesigned, object-oriented dialect of Visual Basic. Implementations provided by .NET Framework and Mono.
* A#: CLI implementation of Ada.
* Boo: A statically typed CLI language, inspired by Python.
* Cobra: A CLI language with both static as well as dynamic typing.
* Oxygene: An Object Pascal-based CLI language.
* Component Pascal: A CLI language inspired by Pascal and Oberon.
* IronLisp: A CLI implementation of Lisp. Deprecated in favor of IronScheme.
* L#: A CLI implementation of Lisp.
* Lexico: A didactic in Spanish object-oriented language.
* Mondrian: A CLI based functional language designed to provide an easy way of scripting components.
* Nemerle: A functional/imperative hybrid language similar to C#, Perl and Lisp.
* P#: A CLI implementation of Prolog
* Phalanger: An implementation of PHP with extensions for ASP.NET
* Phrogram: A custom CLI language for beginners and intermediate users produced by The Phrogram Company
* PowerBuilder: Can target CIL since version 11.1.
* #S — A CLI language that implements Scheme (a port of Peter Norvig's Jscheme).
* #Smalltalk — a CLI implementation of Smalltalk
* AVR.NET — a CLI implementation of RPG
* Active Oberon — a CLI implementation of Oberon
* APLNext — a CLI implementation of APL
* Common Larceny- a CLI implementation of Scheme
* Delphi.NET — a CLI language implementation of the Delphi language.
* Delta Forth .NET — a CLI implementation of Forth from Dataman
* DotLisp — a CLI language inspired by Lisp
* EiffelEnvision — a CLI implementation of Eiffel
* Fortran .NET: Fortran compiling to .NET
* Gardens Point Modula-2/CLR — an implementation of Modula-2 that can target CIL
* Haskell for .NET — a CLI language inspired by Haskell
* Haskell.net — an upcoming CLI language inspired by Haskell
* Hugs for .NET — a CLI language inspired by Haskell
* IronScheme — a R6RS compliant Scheme implementation based on parts of the Microsoft DLR (about 15% and shrinking)
* Ja.NET — an open source implementation of a Java 5 JDK (Java development tools and runtime) for .NET
* LOLCode.NET — a CLI implementation of LOLCODE
* Lua.NET — a CLR implementation of Lua. There is also Nua for DLR.
* Mercury on .NET — an implementation of Mercury that can target CIL
* Net Express — a CLI implementation of COBOL
* NetCOBOL — a CLI implementation of COBOL
* OxygenScheme — a CLI implementation of Scheme
* S# — a CLI implementation of Smalltalk
* IoNET — a CLI implementation of Io
* PL/IL — a CLI implementation of PL/I
* sml.net — a CLI implementation of Standard ML
* Wildcat Cobol — a CLI implementation of COBOL
* X# — a CLI implementation of ASM developed for Cosmos. X# was also the codename for the XML-capabilities of Cω.
T>>Linq, DLR и др. C>Hibernate, JRuby, dynamic invoke.
Это тут при чем?
T>>У Моно тоже все нормально. C>Нет.
Какие там проблемы?
C>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось.
Стало быть обратное работает: все .NET либы автоматически появляются в на яве?
Здравствуйте, Cyberax, Вы писали:
C>Только вот Java не играет роль "догоняющего".
Роль догоняющего — это даже плюс. Можно избежать чужих ошибок.
C>Как ты думаешь, что будут использовать пользователи MS — интегрированые с VisualStudio продукты или OpenSource-решения, которые не интегрированы и по которым нет тысяч книг "Изучи blah-blah за 21 день"?
Что посчитают нужным, то и будут использовать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>У MS сплошные проблемы с устойчивостью и дизайном софта. Для установки .NET Runtime оно лезет куда попало, ставит какие-то системные сервисы оптимизации байт-кода и т.п. Естественно, всё это получается весьма хрупким. MK>>Всё это демагогия. Так ведут себя тонны разного софта под Винду, но их никто за это не клеймит. C>То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM?
Что мешало его сделать как Sun JVM не знаю, не задумывался, наверняка есть причины. Пока на вскидку могу сказать, что FW — это не просто набор файлов. Там еще и средства администрирования, редиректы версий сборок. И в конце концов, хотите вы того или нет, но постепенно Win XP отомрёт, а новые ОС Микрософта уже содержат FW.
G>А почему тогда java не взяли, вот уж она есть почти везде?
Да, Java, в принципе — тоже вариант.
C++ был выбран из соображений наименьшего риска проблем с производительностью в сочетании с хорошими перспективами портируемости.
Все-таки, на практике, если не вдаваться в крайние случаи, с C++ меньше вероятность попасть в ситуацию, когда проект не может быть сдан вовремя, так как возникли непреодолимые в течение приемлемого срока проблемы с использованием памяти или быстродействием. Плюс-минус, с C++ можно быть уверенным, что код все-таки удастся оптимизировать до нужного уровня. С Java по этому параметру сложнее.
Кроме того, с J2ME тоже не все так просто. Я слышал леденящие душу истории от многих разработчиков игр на J2ME, как они в целях оптимизации программы уменьшали число классов в программе.
В такой ситуации программирование на Джаве — еще большая головная боль, чем на C++. То есть в данном случае мы получаем уровень абстракции, с которым потом боремся, вместо того, чтобы получать от него выгоду.
Кстати, я, хоть и имею большой опыт разработки на C++, не являюсь упертым адептом этого языка или вообще какой-либо одной технологии.
Я считаю, что любой достаточно квалифицированный программист способен менять инструменты разработки, коими, в том числе, являются и языки программирования, в зависимости от требований конкретной задачи, не испытывая особенных трудностей.
Мне очень нравятся и Java, и C#.
C# я вообще считаю великолепным языком. Я бы с удовольствием писал бы на нем все свои приложения, будь он действительно кроссплатформенным.
Сейчас я вообще подумываю о том, что надо действительно верхнюю часть кроссплатформенного приложения, включающую бизнес-логику и UI писать на чем-нибудь вроде Питона, и только самые критичные для быстродействия части — на C++.
C>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось. http://csharp-source.net/open-source/rule-engines
это знаю
остальные были не нужны (аналоги как из джавы, которые вы писали) поэтому, где они обитают — не знаю.
Здравствуйте, Cyberax, Вы писали:
C>То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM?
Спасибо, но лучше не надо. Та ещё кривень...
C>К программе установки Sun JVM у меня вопросов никогда не возникало, например.
Редко ставите видать, да в стерильных условиях Вот у меня возникало, и много. К инсталлятору .NET, впрочем, тоже претензий хватает. Начиная с 3.5 там знатный бардак в этом моменте учинили.
Здравствуйте, drol, Вы писали:
C>>То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM? D>Спасибо, но лучше не надо. Та ещё кривень...
Чем?
C>>К программе установки Sun JVM у меня вопросов никогда не возникало, например. D>Редко ставите видать, да в стерильных условиях Вот у меня возникало, и много. К инсталлятору .NET, впрочем, тоже претензий хватает. Начиная с 3.5 там знатный бардак в этом моменте учинили.
Для клиентов её вообще не ставим — она без установки идёт вместе с приложением. Приложение обычным NSIS'ом ставится.
Здравствуйте, vit.rsdn, Вы писали:
C>>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось. VR>http://csharp-source.net/open-source/rule-engines VR>это знаю VR>остальные были не нужны (аналоги как из джавы, которые вы писали) поэтому, где они обитают — не знаю.
Я их тоже знаю. Только вот одна маленькая проблема. Единственный из них сколь-либо нормальный — это Drools.NET. И он тоже совсем недоделаный до неюзабельности.
Здравствуйте, mrTwister, Вы писали:
C>>Только вот Java не играет роль "догоняющего". T>Роль догоняющего — это даже плюс. Можно избежать чужих ошибок.
На практике — большой минус. Так как является большим препятствием.
C>>Как ты думаешь, что будут использовать пользователи MS — интегрированые с VisualStudio продукты или OpenSource-решения, которые не интегрированы и по которым нет тысяч книг "Изучи blah-blah за 21 день"? T>Что посчитают нужным, то и будут использовать.
Ну вот поэтому OpenSource под .NET, конкурирующий с продуктами MS — это весьма странное занятие.
Здравствуйте, mrTwister, Вы писали:
T>>>Отсутствие привязки к языку программирования C>>Ага, с богатым выбором языков: C# или VB. T>http://en.wikipedia.org/wiki/List_of_.NET_languages
В списке языков для JVM что-то около тысячи штук их было ещё 8 лет назад.
Смысла только в них мало.
T>>>Linq, DLR и др. C>>Hibernate, JRuby, dynamic invoke. T>Это тут при чем?
Аналоги.
T>>>У Моно тоже все нормально. C>>Нет. T>Какие там проблемы?
Он сам ненормальный.
C>>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось. T>Стало быть обратное работает: все .NET либы автоматически появляются в на яве?
Откуда такой вывод? Многие библиотеки изначально появляются в Java, а потом портируются в .NET. Обратных примеров я, честно говоря, даже не припомню.
Здравствуйте, gandjustas, Вы писали:
G>>>"знаком c С# .NET" — это почитал статью в википедии? G>>>"после осознания политики MS" — это почитал ЛОР? F>>я так понял, про питон ты даже этого не сделал G>Конечно не сделал, я только написал пару программ на питоне для саморазвития, но руби мне больше приглянулся.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>>>Отсутствие привязки к языку программирования C>>>Ага, с богатым выбором языков: C# или VB. T>>http://en.wikipedia.org/wiki/List_of_.NET_languages C>В списке языков для JVM что-то около тысячи штук их было ещё 8 лет назад. C>Смысла только в них мало.
И тем не менее, приведенный список подтверждает "отсутствие привязки к языку программирования"...
Да, это правда. Мне вот, например, приходилось делать нелёгкий выбор между увеличением .jar'а с midlet'ом на 2.5Кб (вследствии разделения "толстого" класса на два), и возможностью нормально пользоваться IntelliJ IDEA (она дико тормозила на большом "монолитном" исходнике).
*Выбрал второе. JetBrains навсегда
А что Вас так пугает ? Это всего-лишь следствия ограничения конкретных платформ. Ежели 32Кб на midlet выдают, то там каждый байт даже метаданных на счету. На C++ приходилось бы экономить ровно в том же духе. То бишь никаких тебе STL/boost, всё на статических массивах и т.д.
К>В такой ситуации программирование на Джаве — еще большая головная боль, чем на C++.
Это в лучшем случае та же самая боль. А обычно хуже, бо даже базовые API J2ME позволяют очень много чего делать "одним росчерком", в отличии от C/C++ аналогов.
К>C# я вообще считаю великолепным языком. Я бы с удовольствием писал бы на нем все свои приложения, будь он действительно кроссплатформенным.
На мой взгляд, в большинстве случаев кроссплатформенность в Вашем понимании вообще не нужна. Это даже не касаясь момента, что в реале всё равно ведь получается "write once, debug everywhere". И надо точить...
Hi gandjustas
S>>>>>Что вы называете "взаимодействием"? AV>>>>Из кода, написанного на одном языке, дернуть код, написанный на другом языке. G>>>Для этого уже существует много способов, самый универсальный — ws-* вебсервисы, инфраструктуру создавать не надо, оно уже есть. G>>>На вебсервисах есть сотни систем, которые работают в том числе под высокой нагрузкой.
AV>>В случае заказчика этой скорости не хватало. Поэтому и пришлось создавать свою инфраструктуру.
G>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово.
И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер.
Hi gandjustas
AV>>>>А одного процесса? G>>>А в пределах одного процесса я бы не стал запускать managed и unmanaged код.
AV>>Почему? Если уверен к качесте unmanaged кода? G>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль.
G> А если кто-то другой, то в принципе не могу быть уверенным что не упадет unmanaged и не утянет за собой кучу managed модулей.
AV>>И тем более есть возможность в случае необходимости в течении пары секунд сделать так, чтобы unmanaged код выполнялся в отдельном процессе? G>Тогда не совсем понял как реализован интероп, если так просто вынести в отдельный процесс.
Ничего сложного в этом нет. Если невдаваться в подробности, то в момент создания компонента определяется где он должен располагаться и далее от этого пляшем.
AV>>А если есть два куска managed кода, но на разных языках? G>SOA и пайпы\TCP\HTTP как транспорт.
Не все ложится на SOA. Далеко не все.
Далее, зачем использовать пайпы\TCP\HTTP как транспорт в пределах одного процесса, если есть возможность задействовать более быстрые механизмы?
Здравствуйте, MxKazan, Вы писали:
C>>В списке языков для JVM что-то около тысячи штук их было ещё 8 лет назад. C>>Смысла только в них мало. MK>И тем не менее, приведенный список подтверждает "отсутствие привязки к языку программирования"...
Тут опять разница между теорией и практикой проявляется.
Hi Cyberax
C>>>Кто говорил что-то о выкачивании? Оффлайновый инсталлятор потому и оффлайновый, что его можно включить в пакет инсталляции, распространяемый на DVD. G>>Ну так и пихайте на DVD полновесный инсталлер, который гарантированно установит фреймворк на любой комп, в чем проблема? C>На мой ноут, например, .NET 3.5 уже не устанавливается — инсталлятор выпадает с ошибкой (в Windows Update висят 4 патча для .NET, которые тоже не устанавливаются). Почему — лень разбираться.
Кстати, есть такое. На работе на моей машине и еще нескольких админы с различными кувырканиями ставили и 3.0 и 3.5. Автоматом ставиться не захотело.
Hi SE
G>>>У всех моих знакомых нормально .NET любой версии ставится. CC>>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей. SE>В приличных компаниях юзеру, который "поломал" себе винду, сначала мозги вправляют, потом оставляют без премии.
Значит CreatorCray работает в неприличной компании. Так как и я. Потому что у нас надо только сообщить админам. И они разбираются в проблеме. Тем более, что таких компов не один был.
SE> После чего у всех остальных (а иногда и у самого злополучного юзера тоже) чудесным образом все ставится.
Ага, как же. Как 3.0 ставилась с приключениями, так и 3.5 просто не накатилась.
Здравствуйте, ambel-vlad, Вы писали:
G>>>>У всех моих знакомых нормально .NET любой версии ставится. CC>>>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей. SE>>В приличных компаниях юзеру, который "поломал" себе винду, сначала мозги вправляют, потом оставляют без премии. AV>Значит CreatorCray работает в неприличной компании. Так как и я. Потому что у нас надо только сообщить админам. И они разбираются в проблеме. Тем более, что таких компов не один был. Изначально
речь шла о том, что человеку лень разбираться в проблеме. FW не хочет ставится, но вместо поиска решения, он просто заносится в черный список. Мало ли в чем проблема была, может и не в инсталлере вовсе. А, кстати, в чём?
SE>> После чего у всех остальных (а иногда и у самого злополучного юзера тоже) чудесным образом все ставится. AV>Ага, как же. Как 3.0 ставилась с приключениями, так и 3.5 просто не накатилась.
У меня всё прошло без приключений и не один раз и у заказчиков также. Как принято писать: что я делаю не так?
Здравствуйте, SE, Вы писали:
SE>Здравствуйте, CreatorCray, Вы писали: G>>>У всех моих знакомых нормально .NET любой версии ставится. CC>>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей. SE>В приличных компаниях юзеру, который "поломал" себе винду, сначала мозги вправляют, потом оставляют без премии. После чего у всех остальных (а иногда и у самого злополучного юзера тоже) чудесным образом все ставится.
В приличных компаниях, подавляющее большинство юзеров не могут себе поломать винду, даже если сильно того захотят. Просто к сведению.
Здравствуйте, MxKazan, Вы писали:
MK>А, кстати, в чём?
У инсталлятора 3.5 есть затруднения с накаткой на предыдущие версии .NET FW, при наличии некоторых дежурных фиксов установленных на эту самую предыдущую версию Windows Update'ом. Либо сдыхает в процессе тупо, либо сам .NET FW не работает после установки.
Лечится полным сносом всех .NET FW и их фиксов через Add/Remove Programs, и последующей установкой "на пустой желудок".
Hi drol
MK>>А, кстати, в чём?
D>У инсталлятора 3.5 есть затруднения с накаткой на предыдущие версии .NET FW, при наличии некоторых дежурных фиксов установленных на эту самую предыдущую версию Windows Update'ом. Либо сдыхает в процессе тупо, либо сам .NET FW не работает после установки.
D>Лечится полным сносом всех .NET FW и их фиксов через Add/Remove Programs, и последующей установкой "на пустой желудок".
Да, при геморрое с 3.5 админы все сносили. Но еще что-то делали.
Hi MxKazan
G>>>>>У всех моих знакомых нормально .NET любой версии ставится. CC>>>>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей. SE>>>В приличных компаниях юзеру, который "поломал" себе винду, сначала мозги вправляют, потом оставляют без премии. AV>>Значит CreatorCray работает в неприличной компании. Так как и я. Потому что у нас надо только сообщить админам. И они разбираются в проблеме. Тем более, что таких компов не один был. MK>Изначально
речь шла о том, что человеку лень разбираться в проблеме. FW не хочет ставится, но вместо поиска решения, он просто заносится в черный список. Мало ли в чем проблема была, может и не в инсталлере вовсе.
А в чем может быть проблема, если пускается инсталлер FW 3.5 или 3.0, а оно не хочет ставить.
MK>А, кстати, в чём?
А черт его знает. У нас этим админы занимались. Для установки 3.0 что-то там с IIS кувыркались. При нсталяции 3.5 на что-то там связанное с WCF материлось. В детали не вникал, потому что у нас для этого есть админы.
SE>>> После чего у всех остальных (а иногда и у самого злополучного юзера тоже) чудесным образом все ставится. AV>>Ага, как же. Как 3.0 ставилась с приключениями, так и 3.5 просто не накатилась. MK>У меня всё прошло без приключений и не один раз и у заказчиков также. Как принято писать: что я делаю не так?
Так у нас на контопе тоже практически у всех нормально встало. Только на нескольких машинах пришлось админам геморроиться.
Здравствуйте, drol, Вы писали:
D>Здравствуйте, MxKazan, Вы писали: MK>>А, кстати, в чём? D>У инсталлятора 3.5 есть затруднения с накаткой на предыдущие версии .NET FW, при наличии некоторых дежурных фиксов установленных на эту самую предыдущую версию Windows Update'ом. Либо сдыхает в процессе тупо, либо сам .NET FW не работает после установки. D>Лечится полным сносом всех .NET FW и их фиксов через Add/Remove Programs, и последующей установкой "на пустой желудок".
Засчитано. Видать у меня не было этой магической комбинации апдейтов.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi MxKazan AV>А в чем может быть проблема, если пускается инсталлер FW 3.5 или 3.0, а оно не хочет ставить.
Какой антивирь хитрый, с реестром чего-то или еще какие приблуды. Щас чего только не встретишь
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, SE, Вы писали:
SE>>Здравствуйте, CreatorCray, Вы писали: G>>>>У всех моих знакомых нормально .NET любой версии ставится. CC>>>В приличных обществах программеру, сказавшему в ответ на багрепорт "ничё не знаю, на моём компе всё работает" выписывают звездюлей. SE>>В приличных компаниях юзеру, который "поломал" себе винду, сначала мозги вправляют, потом оставляют без премии. После чего у всех остальных (а иногда и у самого злополучного юзера тоже) чудесным образом все ставится. KV>В приличных компаниях, подавляющее большинство юзеров не могут себе поломать винду, даже если сильно того захотят. Просто к сведению.
А ведь и правда. Более того, в приличных компаниях админы не говорят "а нам лень разбираться, что мы там наворотили, это поблема майкрософта, что дотнет не ставится".
Хотя бывает иногда прикольно. С месяц назад у меня ну ни в какую не ставился Windows Live Messenger с весьма странной записью в ивент логе. Поскольку такие проблемы у нас решают админы, то я весьма искренне развеселился после фразы "мы ж не программисты, мы не знаем, что такое ивент вьювер"
Или вот еще случай — начала студия падать, причем явная зависимость от фаз луны прослеживалась.
В общем, расследование показало, что в обоих случаях пакостил антивирус. По видимому не только нам пакостил, потому что вся контора переехала на другой антивирус.
Hi MxKazan
AV>>Hi MxKazan AV>>А в чем может быть проблема, если пускается инсталлер FW 3.5 или 3.0, а оно не хочет ставить. MK>Какой антивирь хитрый,
Здесь точно мимо. Потому что у всех стоит один и тот же антивирь.
MK>с реестром чего-то или еще какие приблуды.
Тоже вряд ли. Потому что все что касается .NET у меня только от MS. И Resharper. Но что-то я сильно сомневаюсь, что он может так сказаться. В любом случае инсталлер не сообщает практически ничего вразумительного. А должен бы.
Здравствуйте, ambel-vlad, Вы писали:
AV>Тоже вряд ли. Потому что все что касается .NET у меня только от MS. И Resharper. Но что-то я сильно сомневаюсь, что он может так сказаться. В любом случае инсталлер не сообщает практически ничего вразумительного. А должен бы.
А в Event Viewer?
Здравствуйте, MxKazan, Вы писали:
MK>Засчитано. Видать у меня не было этой магической комбинации апдейтов.
В основной репозиторий Windows Update кривые фиксы достаточно регулярно попадают. Их потом оттуда вычищают, разумеется, но те кто уже успел "освежиться" наблюдают интересные спецэффекты.
Лично я вот и с Office'ом похожую ситуацию имел. Вообще анекдот. После очередного фикса, перестали ставиться новые фиксы
D>Это в лучшем случае та же самая боль. А обычно хуже, бо даже базовые API J2ME позволяют очень много чего делать "одним росчерком", в отличии от C/C++ аналогов.
Фикс
Это в худшем случае та же самая боль. А обычно для C/C++ всё гораздо хуже, бо даже базовые API J2ME позволяют очень много чего делать "одним росчерком", в отличии от.
Hi MxKazan
AV>>Тоже вряд ли. Потому что все что касается .NET у меня только от MS. И Resharper. Но что-то я сильно сомневаюсь, что он может так сказаться. В любом случае инсталлер не сообщает практически ничего вразумительного. А должен бы. MK>А в Event Viewer?
Практически столько же. Да, нам этой информации в конце концов оказалось достаточно чтобы в течение часа-двух найти решение. Но не стоит сравнивать нас и обычного пользователя.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>В приличных компаниях, подавляющее большинство юзеров не могут себе поломать винду, даже если сильно того захотят. Просто к сведению.
судя по количеству плюсиков, представителей приличных компаний тут всего три человека.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
Согласен, но справедливости ради, 3-й шарп в этом плане уже не так уж и плох. Хотя все равно, особенно если до этого много писать на Lisp, Haskell, OCaml. Такое ощущение, будто тебе руки отрезали.
KV>2. Он кажется слишком простым, пока не увидишь темы от nikov'a. Низкий порог для вхождения -> высокий порог для использования языка в полной мере -> и toSheridan: why so serious?
уже не кажется таким уж забавным, по сравнению с тем, что иногда встречаешь в шарповском коде, написанным профессиональными разработчиками при ревью
Тоже согласен.
KV>3. Он мешает развиваться дальше. Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников.
Смотря кому. Тем кто хочет развивиться, ничто не помешает, а тем кто не хочет развиваться уже ничего не поможет.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
S>>>>>>Что вы называете "взаимодействием"? AV>>>>>Из кода, написанного на одном языке, дернуть код, написанный на другом языке. G>>>>Для этого уже существует много способов, самый универсальный — ws-* вебсервисы, инфраструктуру создавать не надо, оно уже есть. G>>>>На вебсервисах есть сотни систем, которые работают в том числе под высокой нагрузкой.
AV>>>В случае заказчика этой скорости не хватало. Поэтому и пришлось создавать свою инфраструктуру.
G>>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
AV>Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово.
Большой объем интеропа уже ненормально. Существуюищие аппсерверы обычно не допускают такого.
AV>И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер.
Ну оно всегда так и начинается.
Здравствуйте, ambel-vlad, Вы писали:
AV>А как оценить квалификацию программеров из Microsoft и других? Полагаться только на имя? А в данном случае заказчик имел возможность контролировать программеров и их код. И тестеры сидять у заказчика. Так что тут еще бабушка надвое сказала.
Квалификацию программеров из MS оценивать не надо — не они пишут модули для вашего сервера. Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
А у вас как-то странно — разработчиков вы контролируете, а платформу, на которой они пишут — нет. Даже ОС заранее неизвестна.
AV>Из кода, написанного на одном языке, дернуть код, написанный на другом языке.
"дернуть" — вообще можно чем угодно. Передача данных пользовательских типов, я так понимаю, не входит в понятие "дернуть"?
AV>Ты читать умеешь? Говорилось про Python, а не про IronPython.
И в чем разница? Ваши питоновские исходники не работают под IronPython?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений. Стоит ли говорить о том, что пристрастия, которые таки являются определяющими, у всех разные, а работодатель не больной на голову, чтоб инвестировать в переучивание всей толпы на новые фишки "современных технологий".
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>>>А одного процесса? G>>>>А в пределах одного процесса я бы не стал запускать managed и unmanaged код.
AV>>>Почему? Если уверен к качесте unmanaged кода? G>>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
AV>Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль.
Да ну. Далеко не для всех языков интероп с другими делается легко. Например с C++ итеропать на бинарном уровне не очень умеет даже сам C++.
Использование кучи языков и выливается в создание нереальной инфраструктуры, вместо решения задачи.
AV>>>И тем более есть возможность в случае необходимости в течении пары секунд сделать так, чтобы unmanaged код выполнялся в отдельном процессе? G>>Тогда не совсем понял как реализован интероп, если так просто вынести в отдельный процесс.
AV>Ничего сложного в этом нет. Если невдаваться в подробности, то в момент создания компонента определяется где он должен располагаться и далее от этого пляшем.
AV>>>А если есть два куска managed кода, но на разных языках? G>>SOA и пайпы\TCP\HTTP как транспорт.
AV>Не все ложится на SOA. Далеко не все.
Как раз на SOA ложится гораздо больше, чем вы можете себе представить.
AV>Далее, зачем использовать пайпы\TCP\HTTP как транспорт в пределах одного процесса, если есть возможность задействовать более быстрые механизмы?
Абстракция однако.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Sinclair, Вы писали:
S>>Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
H>Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений.
Это как раз отсуствие контроля.
H>Стоит ли говорить о том, что пристрастия, которые таки являются определяющими, у всех разные, а работодатель не больной на голову, чтоб инвестировать в переучивание всей толпы на новые фишки "современных технологий".
В первую очередь работодатель не больной на голову чтобы набирать людей с абсолютно разными пристрастиями. Я вообще не видел ни одной конторы, где писали бы более чем на трех языках, причем решения по интеропу между языками заранее продуманы и не допускают произвольного дергания кода на одном языке и кода на другом языке.
Hi gandjustas
G>>>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
AV>>Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово. G>Большой объем интеропа уже ненормально. Существуюищие аппсерверы обычно не допускают такого.
И много ты знаешь серверов на которых я могу использовать разные языки? Причем не из одного семейства.
AV>>И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер. G>Ну оно всегда так и начинается.
Да не сказал бы. Апп сервер сейчас отдельный продук, который используется не только на первоначальном проекте. И который заказчик уже сумел даже продать, несмотря на то, что на тот момент даже альфа-версии не было.
Hi Sinclair
AV>>А как оценить квалификацию программеров из Microsoft и других? Полагаться только на имя? А в данном случае заказчик имел возможность контролировать программеров и их код. И тестеры сидять у заказчика. Так что тут еще бабушка надвое сказала. S>Квалификацию программеров из MS оценивать не надо — не они пишут модули для вашего сервера.
Ааа, в этом отношении. Так никто из внешних программистов не пишет модули для сервера. Они пишут только куски программ, которые крутятся под аппсервером. Даже если ляжет какой-то модуль, то он утянет за собой только одно приложение. Которое использует этот модуль. Если разработчик программы так сомневается в качестве используемого компонента, то он может первоначально создавать за пределами основного процесса. Да, при этом упадет производительность. И лишь потом, когда сможет убедиться, что он нормально функционирует, может использовать как inproc. При этом пересобирать остальной код не надо будет. Так что не так все страшно.
S>Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
Да нет, не всегда. Например, может оказаться, что разные части задачи выгоднее решать на разных языках.
S>А у вас как-то странно — разработчиков вы контролируете, а платформу, на которой они пишут — нет. Даже ОС заранее неизвестна.
Ну, набор ОСей известен. Просто он не ограничивается одной. Зачем абсолютно точное знание информации под какой ОС.
Заказчик контролирует код самого сервера, а не приложений работающих под ним.
AV>>Из кода, написанного на одном языке, дернуть код, написанный на другом языке. S>"дернуть" — вообще можно чем угодно. Передача данных пользовательских типов, я так понимаю, не входит в понятие "дернуть"?
Не правильно понимаешь, входит. Потому что в в противном случае толку было бы немного.
AV>>Ты читать умеешь? Говорилось про Python, а не про IronPython. S>И в чем разница? Ваши питоновские исходники не работают под IronPython?
Начнем с того, что толку с IronPython не под виндой мало. На чем мне его пускать? Опять вспоминаем Mono?
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Я выше в этой теме на данный вопрос ответил.
AF>Где? Тема большая.
Hi gandjustas
G>>>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
AV>>Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль. G>Да ну. Далеко не для всех языков интероп с другими делается легко. Например с C++ итеропать на бинарном уровне не очень умеет даже сам C++.
А никто и не обещал, что будет все просто. Иначе мы и не нужны были бы.
G>Использование кучи языков и выливается в создание нереальной инфраструктуры, вместо решения задачи.
Нормальная там инфраструктура. Не так уж оно и страшно. Когда мы думали браться или нет, то тоже казалось, что все страшно сложно делать. А потом, по мере въезжания в задачу все становилось понятно. А заказчик спокойно решает свою задачу, без каких-то напрягов.
AV>>>>А если есть два куска managed кода, но на разных языках? G>>>SOA и пайпы\TCP\HTTP как транспорт.
AV>>Не все ложится на SOA. Далеко не все. G>Как раз на SOA ложится гораздо больше, чем вы можете себе представить.
Знаю, но все таки далеко не все.
AV>>Далее, зачем использовать пайпы\TCP\HTTP как транспорт в пределах одного процесса, если есть возможность задействовать более быстрые механизмы? G>Абстракция однако.
За которую приходится платить. Что не всегда может оказаться возможным.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
G>>>>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
AV>>>Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово. G>>Большой объем интеропа уже ненормально. Существуюищие аппсерверы обычно не допускают такого.
AV>И много ты знаешь серверов на которых я могу использовать разные языки? Причем не из одного семейства.
IIS, только произвольно звать один код и другого никто не даст.
Да и вообще это плохая идея, как уже обяснили многократно.
AV>>>И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер. G>>Ну оно всегда так и начинается.
AV>Да не сказал бы. Апп сервер сейчас отдельный продук, который используется не только на первоначальном проекте. И который заказчик уже сумел даже продать, несмотря на то, что на тот момент даже альфа-версии не было.
Это не является достоинством продукта.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
G>>>>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
AV>>>Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль. G>>Да ну. Далеко не для всех языков интероп с другими делается легко. Например с C++ итеропать на бинарном уровне не очень умеет даже сам C++.
AV>А никто и не обещал, что будет все просто. Иначе мы и не нужны были бы.
Самое интересно что любую задачу можно решить просто.
G>>Использование кучи языков и выливается в создание нереальной инфраструктуры, вместо решения задачи.
AV>Нормальная там инфраструктура. Не так уж оно и страшно. Когда мы думали браться или нет, то тоже казалось, что все страшно сложно делать. А потом, по мере въезжания в задачу все становилось понятно. А заказчик спокойно решает свою задачу, без каких-то напрягов.
Ну в нормальном случае такое даже не потребовалось бы.
Hi gandjustas
G>>>>>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
AV>>>>Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль. G>>>Да ну. Далеко не для всех языков интероп с другими делается легко. Например с C++ итеропать на бинарном уровне не очень умеет даже сам C++.
AV>>А никто и не обещал, что будет все просто. Иначе мы и не нужны были бы. G>Самое интересно что любую задачу можно решить просто.
Ага, для любой задачи есть простое, лежащее на поверхности решение. И при этом неверное.
G>>>Использование кучи языков и выливается в создание нереальной инфраструктуры, вместо решения задачи.
AV>>Нормальная там инфраструктура. Не так уж оно и страшно. Когда мы думали браться или нет, то тоже казалось, что все страшно сложно делать. А потом, по мере въезжания в задачу все становилось понятно. А заказчик спокойно решает свою задачу, без каких-то напрягов. G>Ну в нормальном случае такое даже не потребовалось бы.
Ага, вот так не зная задачи ты сразу установил, что надо, а что не надо. Могёшь.
Hi gandjustas
G>>>>>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
AV>>>>Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово. G>>>Большой объем интеропа уже ненормально. Существуюищие аппсерверы обычно не допускают такого.
AV>>И много ты знаешь серверов на которых я могу использовать разные языки? Причем не из одного семейства. G>IIS, только произвольно звать один код и другого никто не даст.
Еще раз, IIS для первоначальной задачи не подходил. Кстати, как запустить IIS под HP-UX не подскажешь?
G>Да и вообще это плохая идея, как уже обяснили многократно.
Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
AV>>>>И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер. G>>>Ну оно всегда так и начинается.
AV>>Да не сказал бы. Апп сервер сейчас отдельный продук, который используется не только на первоначальном проекте. И который заказчик уже сумел даже продать, несмотря на то, что на тот момент даже альфа-версии не было. G>Это не является достоинством продукта.
Полагаю, если бы это не нужно было бы, то вряд ли бы получилось продать кому-то. При этом показывая лишь рабочую версию.
AV>>Заказчик контролирует код самого сервера, а не приложений работающих под ним.
G>Так всетаки unmanaged код может завалить весь процесс, даже с managed модулями?
Одного приложения или всего сервера? Если только одного приложения, то да, может. Если будет выполняться в одном процессе. Если сервер завалить, то нет. Даже теоретически такой возможности нет.
Здравствуйте, March_rabbit, Вы писали:
CC>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>В чем непреодолимая трудность то? M_>гм.... а ничего, в линуксе это такая работа "маленький инсталлятор для дистра + закачка из инета остального" считается нормой?
Мне всё равно что там в линухе.
Я спрашиваю конкретно под винду: что именно мешает создать отдельные маленькие .NET Runtime дистрибутивы?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Какая у тебя интересная классификация...
CC>>безопасник kochetkov.vladimir KV>Наверное все-таки дотнетчик в данном контексте. +можно и питонистом назвать, наверное.
Ну, как скажешь
CC>>линухоид Sheridan KV>считающий себя плюсником...
Шеридан это вообще отдельная категория, за пределами зла и добра.
KV>еще тут отмечался в создании тем Роман Одайский (плюсник, питонист) и куча другого народа, о чьих специализациях мне ничего неизвестно.
Я смотрел в первых нескольких темах в янусе.
Да в общем то в КСВ не столько важно кто тему создал, сколько к чему она в итоге приходит. Сцепились двое фанатов — и всё, подветку смело можно помечать как "ответы по теме прочитаны" чтоб больше этого срача не видеть.
KV>Отрицание фактов, как правило, является признаком того, что человек руководствуется верой, а не здравым смыслом. Он это имел ввиду, IMHO
Голые факты еще и трактовку могут иметь через призму мировосприятия трактующего. Потому и выходит, что факт то один, а понимают стороны его по-разному. Для кого-то может это и не факт вовсе.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
m> M_>гм.... а ничего, в линуксе это такая работа "маленький инсталлятор для дистра + закачка из инета остального" считается нормой? Сможете найти дистр, к которому не нужен будет инет для любого применения (Не берем ДВД поставку)?
m> Посмеялся, спасибо . Есть куча дистров, которым не нужен инет, это раз. А во вторых, где связь между дистрами Линуха и их установкой, и тем, что МС не выложила Фреймоворк разбитым на разные платформы?
Яркий пример странной двусторонней логики линуксоидов
Здравствуйте, CreatorCray, Вы писали:
KV>>еще тут отмечался в создании тем Роман Одайский (плюсник, питонист) и куча другого народа, о чьих специализациях мне ничего неизвестно. CC>Я смотрел в первых нескольких темах в янусе. CC>Да в общем то в КСВ не столько важно кто тему создал, сколько к чему она в итоге приходит. Сцепились двое фанатов — и всё, подветку смело можно помечать как "ответы по теме прочитаны" чтоб больше этого срача не видеть.
Тогда уж проще от КСВ отписаться, тут везде срач фанатов
C> M>Нет. Истинная кроссплатформенность — это "write once, run everywhere" (написал однажды, запустил везде) C> M>C++ с боооольшим натягом изредка предлагает "write once, compile everywhere" (написал однажды, скомпилировал везде)
C> Тут не согласен. Бинарная портируемость не особо-то нужна. Нормальной source code portability достаточно, тем более, что часто для каждой системы по мелочи надо затачивать определённые вещи.
А то
C> M>Действительно серьезного большого кросплатформенного софта (и чтобы еще на слузу) на Qt я особо не видел. Ну, кроме Qoogle Earth и Skyope (который, несмотря на всю кросплатформенность Qt, для Линукса развивается с большим опозданием)
C> На Windows он просто Skype не использует, вроде.
Здравствуйте, gandjustas, Вы писали:
S>>>Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
H>>Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений. G>Это как раз отсуствие контроля.
Очень смешно. Предлагаешь устроить повальный террор в виде массовых увольнений?
H>>Стоит ли говорить о том, что пристрастия, которые таки являются определяющими, у всех разные, а работодатель не больной на голову, чтоб инвестировать в переучивание всей толпы на новые фишки "современных технологий". G>В первую очередь работодатель не больной на голову чтобы набирать людей с абсолютно разными пристрастиями.
Смысл фразы о программистах из разных поколений от тебя ускользнул? Я поясню: пришли на работу молодые программисты, но не на место старых... Так понятно?
G>Я вообще не видел ни одной конторы, где писали бы более чем на трех языках, причем решения по интеропу между языками заранее продуманы и не допускают произвольного дергания кода на одном языке и кода на другом языке.
То, что ты не видел таких контор, говорит только о твоем опыте. А ты видел не софтверные конторы, где программистов >200? Я в такой работал, и даже не возьмусь посчитать сколько языков там использовалось.
Здравствуйте, ambel-vlad, Вы писали:
AV>Ааа, в этом отношении. Так никто из внешних программистов не пишет модули для сервера. Они пишут только куски программ, которые крутятся под аппсервером. Даже если ляжет какой-то модуль, то он утянет за собой только одно приложение.
Вот в этом месте мне и непонятно. Если у вас приложения настолько изолированы от апп.сервера, то не всё ли равно, на чём он написан?
Если не изолированы — то неуправляемые языки, мягко говоря, несут некоторый риск.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
S>>>>Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
H>>>Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений. G>>Это как раз отсуствие контроля. H>Очень смешно. Предлагаешь устроить повальный террор в виде массовых увольнений?
А причем тут это? Контролем в данном случае является банальное ограничение на используемые языки и технологии.
Если каждый программист начнет писать модули на том, что вздумается, то никакой аппсервер делу не поможет.
G>>Я вообще не видел ни одной конторы, где писали бы более чем на трех языках, причем решения по интеропу между языками заранее продуманы и не допускают произвольного дергания кода на одном языке и кода на другом языке. H>То, что ты не видел таких контор, говорит только о твоем опыте. А ты видел не софтверные конторы, где программистов >200? Я в такой работал, и даже не возьмусь посчитать сколько языков там использовалось.
Я имел ввиду количество языков на одном проекте.
G>>Да и вообще это плохая идея, как уже обяснили многократно. AV>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности, а если они запускаются в разных процессах, то получится SOA.
Здравствуйте, gandjustas, Вы писали:
H>>>>Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений. G>>>Это как раз отсуствие контроля. H>>Очень смешно. Предлагаешь устроить повальный террор в виде массовых увольнений? G>А причем тут это? Контролем в данном случае является банальное ограничение на используемые языки и технологии. G>Если каждый программист начнет писать модули на том, что вздумается, то никакой аппсервер делу не поможет.
Запретительные меры ничего не решают. Работа просто встанет.
G>>>Я вообще не видел ни одной конторы, где писали бы более чем на трех языках, причем решения по интеропу между языками заранее продуманы и не допускают произвольного дергания кода на одном языке и кода на другом языке. H>>То, что ты не видел таких контор, говорит только о твоем опыте. А ты видел не софтверные конторы, где программистов >200? Я в такой работал, и даже не возьмусь посчитать сколько языков там использовалось. G>Я имел ввиду количество языков на одном проекте.
И я об одном проекте говорю -- об автоматизации производственной деятельности. Это не просто бухгалтерия или документооборот, это задачи предметной области компании. Там есть программисты пишущие, например, на Paradox и офигенно разбирающиеся в геологии. Попробуй заменить такого человека вновь пришедшим, со знаниями супер новинок. Результат будет плачевным, увы. Таких специалистов выращивают годами, и ценятся они вовсе не знания новинок.
Здравствуйте, gandjustas, Вы писали:
G>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности, а если они запускаются в разных процессах, то получится SOA.
Hi gandjustas
G>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,
Это ты так решил? Так тебя никто не заставляет. А во вторых, как быть с разными managed? Разносить по разным процессам? Спасибо, но иногда лучне не делать так.
Hi Sinclair
AV>>Ааа, в этом отношении. Так никто из внешних программистов не пишет модули для сервера. Они пишут только куски программ, которые крутятся под аппсервером. Даже если ляжет какой-то модуль, то он утянет за собой только одно приложение. S>Вот в этом месте мне и непонятно. Если у вас приложения настолько изолированы от апп.сервера, то не всё ли равно, на чём он написан?
Основная часть аппсервер изолирована от конкретного приложения. Но часть функционала сервера, которая касается непосредственно выполнения приложения, внесена в процесс конкретного приложения. Но если эта часть завалится, то серверу ничего не будет. Ляжет только одно приложение. А сам сервер будет работать дальше как ни в чем не бывало.
Здравствуйте, Mamut, Вы писали:
C>> M>Действительно серьезного большого кросплатформенного софта (и чтобы еще на слузу) на Qt я особо не видел. Ну, кроме Qoogle Earth и Skyope (который, несмотря на всю кросплатформенность Qt, для Линукса развивается с большим опозданием) C>> На Windows он просто Skype не использует, вроде. M>Эээ? Не понял?
Тормозил, на Windows Skype не использует QT. Изначально его вообще не Дельфи писали.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности, а если они запускаются в разных процессах, то получится SOA.
H>И давно, скажем, COM считается SOA?
COM-объекты не являются сервисами в понимании SOA, хотя общие принципы можно найти везде.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
G>>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,
AV>Это ты так решил?
Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.
AV>А во вторых, как быть с разными managed? Разносить по разным процессам?
Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы.
AV>Спасибо, но иногда лучне не делать так.
Слово "иногда" звучит очень часто?
Что это за "иногда"? Как часто это "иногда" случается?
Такое ощущение, что вся затея с аппсервером только из-за этого "иногда".
Hi gandjustas
G>>>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,
AV>>Это ты так решил? G>Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.
А AV обязательно будет при использовании unmanaged? Да и не так он страшен в данном случае. Так как это никак не скажется на работе самого сервера.
AV>>А во вторых, как быть с разными managed? Разносить по разным процессам? G>Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы.
Медленно. Тем более, что хост-процесс еще много чего делает полезного.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
G>>>>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>>>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,
AV>>>Это ты так решил? G>>Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.
AV>А AV обязательно будет при использовании unmanaged?
Обязательно, гарантировать обратное вы не можете.
AV>Да и не так он страшен в данном случае. Так как это никак не скажется на работе самого сервера.
Все умрут один сервер останется? Кому он только нужен будет?
AV>>>А во вторых, как быть с разными managed? Разносить по разным процессам? G>>Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы. AV>Медленно. Тем более, что хост-процесс еще много чего делает полезного.
Ну если вызовы нечасты, то пофиг медленно или нет. А если часты, то все равно не все вызовы будут managed-managed и часть пойдет через теже пайпы.
Ну это кончено если вы заботитесь о безопасности и надежности.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Тогда уж проще от КСВ отписаться, тут везде срач фанатов
Да регулярно отписываюсь, тока потом скучно становится. Все таки иногда тут и интересное почитать можно пока флеймеры да тролли не проснулись.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
VR>>вот. допустим, ASP.NET MVC — это мощная платформа для быстрой и качественной веб-разработки.
DS>Хороший пример этому rsdn...
Ну во-первых, rsdn не имеет ровным счетом никакого отношения к ASP.NET MVC.
Во-вторых, если бы он написан на том же python, то скорее-всего он бы вообще загнулся под такими-то нагрузками.
Hi gandjustas
G>>>>>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>>>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>>>>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,
AV>>>>Это ты так решил? G>>>Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.
AV>>А AV обязательно будет при использовании unmanaged? G>Обязательно, гарантировать обратное вы не можете.
Ага. А вероятность встретить/не встретить мамонта тоже 50/50.
И как же ты программируешь, извелся весь наверное. Ведь твои проги крутятся на системе, которая вся насквозь unmanaged.
AV>>Да и не так он страшен в данном случае. Так как это никак не скажется на работе самого сервера. G>Все умрут один сервер останется? Кому он только нужен будет?
Да, бедный заказчик. Не знает, что у него только один сервер работает, а все проги свалились.
AV>>>>А во вторых, как быть с разными managed? Разносить по разным процессам? G>>>Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы. AV>>Медленно. Тем более, что хост-процесс еще много чего делает полезного. G>Ну если вызовы нечасты, то пофиг медленно или нет. А если часты, то все равно не все вызовы будут managed-managed и часть пойдет через теже пайпы.
Зачем пайпы использовать, если можно просто дернуть нужный метод у нужного компонента?
G>Ну это кончено если вы заботитесь о безопасности и надежности.
Пока в этой части никаких вопросов не возникало претензий. Потому что надежность достаточная.
Здравствуйте, criosray, Вы писали:
C>Ну во-первых, rsdn не имеет ровным счетом никакого отношения к ASP.NET MVC.
Ну тогда извините, я не большой знаток МСовских базвордов
C>Во-вторых, если бы он написан на том же python, то скорее-всего он бы вообще загнулся под такими-то нагрузками.
Здравствуйте, DoubleSlash, Вы писали:
C>>Ну во-первых, rsdn не имеет ровным счетом никакого отношения к ASP.NET MVC.
DS>Ну тогда извините, я не большой знаток МСовских базвордов
Здравствуйте, ambel-vlad, Вы писали:
G>>Ну это кончено если вы заботитесь о безопасности и надежности.
AV>Пока в этой части никаких вопросов не возникало претензий. Потому что надежность достаточная.
Hi criosray
G>>>Ну это кончено если вы заботитесь о безопасности и надежности.
AV>>Пока в этой части никаких вопросов не возникало претензий. Потому что надежность достаточная.
C>Знаете что говорят про ружье на стене?
Знаю, поэтому и были предприняты необходимые действия, чтобы патрона не оказалось.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi criosray
G>>>>Ну это кончено если вы заботитесь о безопасности и надежности.
AV>>>Пока в этой части никаких вопросов не возникало претензий. Потому что надежность достаточная.
C>>Знаете что говорят про ружье на стене?
AV>Знаю, поэтому и были предприняты необходимые действия, чтобы патрона не оказалось.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
G>>>>>>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>>>>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>>>>>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,
AV>>>>>Это ты так решил? G>>>>Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.
AV>>>А AV обязательно будет при использовании unmanaged? G>>Обязательно, гарантировать обратное вы не можете.
AV>Ага. А вероятность встретить/не встретить мамонта тоже 50/50.
Причем тут вероятность?
Вы же продаетет фактически аппсервер, который может запустить в одном хост-процессе managed и unmanaged код, как вы гарантируете что AV в unmanaged коде не свалит кучу managed модулей, которые могут никак не относиться к тому приложению, которому требуется unmanaged модуль.
AV>И как же ты программируешь, извелся весь наверное. Ведь твои проги крутятся на системе, которая вся насквозь unmanaged.
Для ядра этой системы все подряд модули не пишут, а процессы пользовательского режима как раз изолированны друг от друга.
AV>>>>>А во вторых, как быть с разными managed? Разносить по разным процессам? G>>>>Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы. AV>>>Медленно. Тем более, что хост-процесс еще много чего делает полезного. G>>Ну если вызовы нечасты, то пофиг медленно или нет. А если часты, то все равно не все вызовы будут managed-managed и часть пойдет через теже пайпы. AV>Зачем пайпы использовать, если можно просто дернуть нужный метод у нужного компонента?
Что значит "просто", с учетом того что я написал выше про гарантии?
G>>Ну это кончено если вы заботитесь о безопасности и надежности. AV>Пока в этой части никаких вопросов не возникало претензий. Потому что надежность достаточная.
Все админы делятся на две категории — те кто делает бекапы, и те кто их будет делать
Hi gandjustas
G>>>>>>>>>Да и вообще это плохая идея, как уже обяснили многократно. AV>>>>>>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно. G>>>>>>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,
AV>>>>>>Это ты так решил? G>>>>>Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.
AV>>>>А AV обязательно будет при использовании unmanaged? G>>>Обязательно, гарантировать обратное вы не можете.
AV>>Ага. А вероятность встретить/не встретить мамонта тоже 50/50. G>Причем тут вероятность? G>Вы же продаетет фактически аппсервер, который может запустить в одном хост-процессе managed и unmanaged код, как вы гарантируете что AV в unmanaged коде не свалит кучу managed модулей, которые могут никак не относиться к тому приложению, которому требуется unmanaged модуль.
А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера. И как же AV в компоненте одного приложения может оказать влияние на другие приложения и сам сервер?
AV>>И как же ты программируешь, извелся весь наверное. Ведь твои проги крутятся на системе, которая вся насквозь unmanaged. G>Для ядра этой системы все подряд модули не пишут, а процессы пользовательского режима как раз изолированны друг от друга.
Так и модули для аппсервера тоже все подряд не пишут. Только конкретные приложения. И они тоже изолированы друг от друга. Плюс особо стремные компоненты ты можешь вынести в отдельный процесс. В этом случае при так тобой разрекламированного AV в компоненте даже приложение не упадет. И приложение при этом не надо пересобирать.
AV>>>>>>А во вторых, как быть с разными managed? Разносить по разным процессам? G>>>>>Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы. AV>>>>Медленно. Тем более, что хост-процесс еще много чего делает полезного. G>>>Ну если вызовы нечасты, то пофиг медленно или нет. А если часты, то все равно не все вызовы будут managed-managed и часть пойдет через теже пайпы. AV>>Зачем пайпы использовать, если можно просто дернуть нужный метод у нужного компонента? G>Что значит "просто", с учетом того что я написал выше про гарантии?
Смотри выше.
G>>>Ну это кончено если вы заботитесь о безопасности и надежности. AV>>Пока в этой части никаких вопросов не возникало претензий. Потому что надежность достаточная. G>
G>
G>Все админы делятся на две категории — те кто делает бекапы, и те кто их будет делать
Если пользоваться этой фразой, то бекапы были с самого начала.
Здравствуйте, criosray, Вы писали:
C>Вы вообще видели VS 2k8 + Resharper 4.1 связку? Явно не видели...
Решарпер действительно бесподобен, но и вы слишком категоричны, вот напрмиер по своему опыту python+eclipse:
C>Как скорость может быть одинаковой, если нету ни мощных средств для рефакторинга,
мощных как в решарпере нет, простые вполне есть.
C>ни intellisense,
есть
C> ни удобных и быстрых средств для навигации по коду,
есть
C>ни средств для динамического анализа кода на соответствие определенным правилам,
есть, PyLint — во многом устраняет недостатки "динамичности" (проверяет вызовы методов и т.п. — т.е. те ошибки которые как пправило в рантайме )
C>ни удобного отладчика,
выделенное — субъективно, а так — есть
C>ни модуля для запуска модульных тестов,
есть
C>ни модуля для взаимодействия с системой контроля версий,
есть
C>ни модуля для дизайна схемы классов,
нет, но я этим и в стуии ни разу не пользовался.
C>ни модуля для дизайна форм, ни модуля для дизайна страниц, ни... много другого?
html редактор есть, редактор форм — а каких? winforms чтоли ? если например для GUI на python взять PyQT — то там вполне себе нормальный дизайнер
Здравствуйте, ambel-vlad, Вы писали:
AV>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.
Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?
Здравствуйте, Mamut, Вы писали:
C>> Тормозил, на Windows Skype не использует QT. Изначально его вообще не Дельфи писали. M>Однако 0_о. Что, в принципе, только подтверждает тот факт, что все дело н в языке программирования и н в платформе, а в руках M>Правда, у вынь- и макос-версии скайпа почти паритет пофичам, по-моему. А вот в Линуксе — увы
Вообще-то, сейчас в Линуксовой версии вроде все фичи Виндовой есть. Насколько я понимаю, они постепенно переходят к общей кодовой базе для всех платформ.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>3. Он мешает развиваться дальше. Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников.
От имени оголтелых плюсников решительно заявляю
1. C# никуда не денется и никакого конца ему не будет. Его претензии на всеобщность будут похоронены и он просто займет свое место в мире ИТ. Точнее, уже занял.
2. Все прочие языки — то же самое. Включая С++
Здравствуйте, mogadanez, Вы писали:
C>>Вы вообще видели VS 2k8 + Resharper 4.1 связку? Явно не видели...
M>Решарпер действительно бесподобен, но и вы слишком категоричны, вот напрмиер по своему опыту python+eclipse:
Вы невнимательно читали ветку. Речь шла о том, что мол на пайтоне можно писать код так же быстро, как на C#, но без использования специальных сред разработки.
Что до эклипс — да, там почти все есть только на фоне VS+Resharper весьма и весьма слабо.
Здравствуйте, shrecher, Вы писали:
S>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.
Питон плохая замена овсу, тфу ты, Шарпу.
Уроветь у него примерно такой же как у Шарпа, но ко всему прочему Питон интерпретатор. Все что можно получить в питоне — это скриптообразное метапрограммирование.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, shrecher, Вы писали:
S>Да, но производительность написания кода резко упадет.
Дохотр, а у меня производительность на питоне в 30 раз ниже чем не шарпе. На на немерле еще раз в 5-1- выше. Что я делаю не так?
Если серьезно, то в первую очередь, писать лучше на том что хорошо знаешь. Скажем С++-ник плохо знакомый с питоном и дотнетом скажет, что вы оба ламеры и писать все проще на С++. Так что все ваши заявления — это не большее чем не умение абстрагироваться от собственных привычек.
Рельно языки отличаются только:
1. Возможностями. И тут у питона и шарпа даш на даш. Питон имеет мощьное метапрограммирование и по причинам своей динамической природы упрощает создание обобщенных реализаций, но при этом Питон резко проигрывает по скорости получаемых програм, не имеет возможностей вроде LINQ-а, имеет значительно более слабую поддержку IDE (и это не лечится по причине скриптовости).
2. Особенностями рантайма. Шарпа требует дотнет, а Питон собственный рантайм. При этом Шарп компилируется в эффективный машинный код, а Питон — нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, shrecher, Вы писали:
S>нифига. На Питоне и C#+VS пишется примерно с одной и тойже скоростью. Вот если из связки C# VS убрать VS, то все — труба, погрязнешь в рутине.
Фанат ты. Потому и мнение у тебя такое.
Писать на чем угодно в нотпэде медленее чем если есть мощьная IDE подсказывающая тебе список функций (методов) и предоставляющая рефакторинг.
Но даже если считать твое мнение серьезным, то все равно не ясно зачем переходить на Питон. Ведь IDE же уже есть (и не одна), а с ней разницы в скорости кодирования и поддержки кода нет. Так зачем же получать более медленный исполняемые файлы не получая за это ничего в замен?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, master_of_shadows, Вы писали:
__>Здравствуйте, Anton Batenev, Вы писали:
AB>>А делать простое get-set свойство, которое ни чем (по сути) не отличается? Хотя мне тут сказали про бинарную совместимость — это действительно повод для некоторых случаев.
__>Повод делать property — это более OO-way . В будущем, как уже заметили, будет меньше проблемм.
Вопрос начинающего шарпера: Что мона сделать с полем, но нельзя сделать со свойством, кроме передачи в метод по ссылке??
То есть на мой взгляд:
class MyClass
{
int Prop;
}
и
class MyClass
{
int Prop {get; set;};
}
кроме упомянутого выше отличия со ссылками — свойства и поля — эквивалентны. Или я не прав?
Здравствуйте, criosray, Вы писали:
C>Вы вообще видели VS 2k8 + 4.1 связку? Явно не видели...
Может сначала следовало бы дождаться ответа?
C>Как скорость может быть одинаковой, если нету ни мощных средств для рефакторинга, ни intellisense, ни удобных и быстрых средств для навигации по коду, ни средств для динамического анализа кода на соответствие определенным правилам, ни удобного отладчика, ни модуля для запуска модульных тестов, ни модуля для взаимодействия с системой контроля версий, ни модуля для дизайна схемы классов, ни модуля для дизайна форм, ни модуля для дизайна страниц, ни... много другого?
А кто тебе сказал, что для Питона нет IDE?
Они конечно не такие мощные как Resharper, но в купе с динамичностью языка получается весьма не плохо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Hi gandjustas
AV>>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.
G>Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?
Затем же зачем и другие аппсервера.
Тем более, что работа всех компонентов приложения в пределах одного процесса совсем не обязательное требование. Они могут вообще быть на разных концах света. Но в этом случае будет падение производительности.
Здравствуйте, vit.rsdn, Вы писали:
VR>спорный момент VR>сишарп, до версии 3.0 имел очень понятный и ясный синтаксис VR>сча, согласен, как накрутили всяких лямбд, синтаксис становится всё запутанней и запутанней, но и даже сейчас каким-то "непростым" трудно его назвать
Разочарую тебя. В Питоне всякие лябды были с самого рождения (ну, или очень довно). Так что тем у кого мозг не в силах освоить всякие лямбды в этом мире становится жить все сложнее и сложнее. Даже в Яве есть локальные классы и подобие замыканий, что в сущности не доработанные лябды.
Но есть один выход! Нашей необъятной родине очень нужны дворники!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, criosray, Вы писали:
C>Те же лямбды раньше реализовывались анонимными делегатами.
Уважаемый, запомни на будущее. То о чем ты ведешь речь называется "анонимными методами".
C>Мы недавно переводили проект с С# 2 на С# 3 — код стал гораздо лаконичнее и читабельнее.
Если бы вы перевели его скажем на Немерле или F# (с умом), то он бы стал еще более лаконичным и читабельным (раз эдак в 5).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Qbit86, Вы писали:
Q>А потом хоть краем глаза глянь на вменяемые языки и технологии, чтоб осознать костыльную природу Буста и «техник Александреску».
Осталось только озвучить список нормальных языков .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, March_rabbit, Вы писали:
F>>хочется побыть илитой?. F>>изучи буст, покажи шаблонную магию им.Александреску.. и все будут тебе завидовать.. M_>где-то слышал выражение, что магия отличается от колдовства/волшебства/ведовства тем, что маг не понимает сути магии. Просто знает, что каким словом вызвать что-то и все. Имхо, Александреску — это из колдовства
Все с точностью до наоборот. Маги — это фокусники. Их магия — это упорная тренировка или отличный инвентарь. А вот колдуны — это действительно больные на голову люди или обманщики которые творят черти что.
Алексондреску же — это банальный инжинер который пытался подкрутить недоработанный язык чтобы вдохнуть в него жизнь. На сегодня он вроде бы с этим завязал и сейчас участвует в развитии D.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.
G>>Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?
AV>Затем же зачем и другие аппсервера.
Другие аппсерверы имеют другие цели.
AV>Тем более, что работа всех компонентов приложения в пределах одного процесса совсем не обязательное требование. Они могут вообще быть на разных концах света. Но в этом случае будет падение производительности.
Так вы изобрели свой вариант компонентной модели типа COM или CORBA (видимо изначальное отсуствтие COM\DCOM на целевой платформе и побудило создание такого), только зачем аппсервер как самостоятельная программа?
Hi gandjustas
AV>>>>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.
G>>>Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?
AV>>Затем же зачем и другие аппсервера. G>Другие аппсерверы имеют другие цели.
AV>>Тем более, что работа всех компонентов приложения в пределах одного процесса совсем не обязательное требование. Они могут вообще быть на разных концах света. Но в этом случае будет падение производительности. G>Так вы изобрели свой вариант компонентной модели типа COM или CORBA (видимо изначальное отсуствтие COM\DCOM на целевой платформе и побудило создание такого),
Да, пришлось и это делать. Вот только платформ там не мало. А COM больше из мира винды. Хотя для некоторых систем есть и коммерческие реализации. Но не для всех.
Здравствуйте, VladD2, Вы писали:
VD>Если бы вы перевели его скажем на Немерле или F# (с умом), то он бы стал еще более лаконичным и читабельным (раз эдак в 5).
Ну так переведи вышепроцитированный код на немерле или f#, а мы поаппладируем в восхищении!
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>>>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.
G>>>>Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?
AV>>>Затем же зачем и другие аппсервера. G>>Другие аппсерверы имеют другие цели.
AV>
AV>>>Тем более, что работа всех компонентов приложения в пределах одного процесса совсем не обязательное требование. Они могут вообще быть на разных концах света. Но в этом случае будет падение производительности. G>>Так вы изобрели свой вариант компонентной модели типа COM или CORBA (видимо изначальное отсуствтие COM\DCOM на целевой платформе и побудило создание такого),
AV>Да, пришлось и это делать. Вот только платформ там не мало. А COM больше из мира винды. Хотя для некоторых систем есть и коммерческие реализации. Но не для всех.
Здравствуйте, Cyberax, Вы писали:
T>>>>Linq, DLR и др. C>>>Hibernate, JRuby, dynamic invoke. T>>Это тут при чем? C>Аналоги.
Что из этого является аналогом Linq?
T>>Какие там проблемы? C>Он сам ненормальный.
Чем ненормальный?
C>>>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось. T>>Стало быть обратное работает: все .NET либы автоматически появляются в на яве? C>Откуда такой вывод? Многие библиотеки изначально появляются в Java, а потом портируются в .NET. Обратных примеров я, честно говоря, даже не припомню.
Погоди, у тебя что-то с логикой. Ты утверждаешь, что ява имеет больше библиотек основываясь на факте существования непортированных на нет явовских библиотек. То есть ты говоришь: если существует явовская библиотека, которую не портировали на нет, следовательно в нете меньше библиотек. Но ведь и в дотнете есть библиотеки, непортированные на яву, и, пользуясь твоей логикой, можно сделать вывод, что в яве меньше библиотек.
Здравствуйте, mrTwister, Вы писали:
T>>>>>Linq, DLR и др. C>>>>Hibernate, JRuby, dynamic invoke. T>>>Это тут при чем? C>>Аналоги. T>Что из этого является аналогом Linq?
Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png
T>>>Какие там проблемы? C>>Он сам ненормальный. T>Чем ненормальный?
Тормозной, особенно при работе с памятью (консервативный GC, однако).
C>>Откуда такой вывод? Многие библиотеки изначально появляются в Java, а потом портируются в .NET. Обратных примеров я, честно говоря, даже не припомню. T>Погоди, у тебя что-то с логикой. Ты утверждаешь, что ява имеет больше библиотек основываясь на факте существования непортированных на нет явовских библиотек.
Да.
T>То есть ты говоришь: если существует явовская библиотека, которую не портировали на нет, следовательно в нете меньше библиотек. Но ведь и в дотнете есть библиотеки, непортированные на яву, и, пользуясь твоей логикой, можно сделать вывод, что в яве меньше библиотек.
Не совсем. Для некоторых вещей на .NET вообще нет библиотек, хотя они есть для Java. Уникальные для .NET бибилиотеки — обычно слишком спецефичные, чтобы их портировать на Java.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>>>>>Linq, DLR и др. C>>>>>Hibernate, JRuby, dynamic invoke. T>>>>Это тут при чем? C>>>Аналоги. T>>Что из этого является аналогом Linq? C>Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png
на картинке жалкое подобие Linq2SQL.
Можно ли такой же запрос написать для коллекции объектов?
Будут ли типы проверяться при компиляции?
Здравствуйте, gandjustas, Вы писали:
C>>Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png G>на картинке жалкое подобие Linq2SQL. G>Можно ли такой же запрос написать для коллекции объектов?
Нет (ну если свой провайдер не напишешь). Для XML — можно.
G>Будут ли типы проверяться при компиляции?
Да, на этапе инспекции.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png G>>на картинке жалкое подобие Linq2SQL. G>>Можно ли такой же запрос написать для коллекции объектов? C>Нет (ну если свой провайдер не напишешь). Для XML — можно.
Не надо мне такого счастья.
G>>Будут ли типы проверяться при компиляции? C>Да, на этапе инспекции.
Какой инспекции?
Здравствуйте, Cyberax, Вы писали:
T>>То есть ты говоришь: если существует явовская библиотека, которую не портировали на нет, следовательно в нете меньше библиотек. Но ведь и в дотнете есть библиотеки, непортированные на яву, и, пользуясь твоей логикой, можно сделать вывод, что в яве меньше библиотек. C>Не совсем. Для некоторых вещей на .NET вообще нет библиотек, хотя они есть для Java. Уникальные для .NET бибилиотеки — обычно слишком спецефичные, чтобы их портировать на Java.
Здравствуйте, gandjustas, Вы писали:
C>>Не совсем. Для некоторых вещей на .NET вообще нет библиотек, хотя они есть для Java. Уникальные для .NET бибилиотеки — обычно слишком спецефичные, чтобы их портировать на Java. G>Примеры в студию.
Встраиваемый LDAP сервер — из недавнего.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Не совсем. Для некоторых вещей на .NET вообще нет библиотек, хотя они есть для Java. Уникальные для .NET бибилиотеки — обычно слишком спецефичные, чтобы их портировать на Java. G>>Примеры в студию. C>Встраиваемый LDAP сервер — из недавнего.
Учитывая что .NET в полном варианте работает под Windows, то встраивавемый LDAP не сильно нужен так как есть AD.
Это как раз пример слишком специфичного компонента, который .NET не очень нужен.
Здравствуйте, gandjustas, Вы писали:
C>>Нет (ну если свой провайдер не напишешь). Для XML — можно. G> G>Не надо мне такого счастья.
Ну вот просто пока никому не нужно было.
G>>>Будут ли типы проверяться при компиляции? C>>Да, на этапе инспекции. G>Какой инспекции?
Выполнение инспекций кода в IDE.
LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Нет (ну если свой провайдер не напишешь). Для XML — можно. G>> G>>Не надо мне такого счастья. C>Ну вот просто пока никому не нужно было.
Почему на C# всем нужно?
C>LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей.
Это вам так кажется потому что Linq полноценно не пользовали.
Здравствуйте, gandjustas, Вы писали:
G>>>Примеры в студию. C>>Встраиваемый LDAP сервер — из недавнего. G>Учитывая что .NET в полном варианте работает под Windows, то встраивавемый LDAP не сильно нужен так как есть AD.
Только вот нужен был LDAP для специального сервера, который должен работать параллельно с AD, предоставляя некоторую очень специфическую функциональность.
G>Это как раз пример слишком специфичного компонента, который .NET не очень нужен.
Да-да. Как видишь, мне вот оказалось нужно.
Для Java таки решение сразу же нашлось — http://wiki.interldap.objectweb.org/xwiki/bin/view/Main/ Пришлось по-быстрому написать всё нужное на Java и интегрировать через локальные веб-сервисы. Жуть, в общем — хорошо что это приложение не нужно было распространять.
Прелесть LInq — это не ORM, а возможность писать статически типизированные запросы с единым стандартным синтаксисом к любым источникам данных и не надо никаких ИДЕ, провайдеров и пр.
C>Тормозной, особенно при работе с памятью (консервативный GC, однако).
Зато, в отличии от .Net Framework, поддерживает расширенные инструкции процессоров (SSE, например). Да и проигрыш в производительности по памяти имхо не фатальный.
Здравствуйте, gandjustas, Вы писали:
G>>>Не надо мне такого счастья. C>>Ну вот просто пока никому не нужно было. G>Почему на C# всем нужно?
Потому что в C# не умеют пользоваться Hibernate. Вон, даже целый Entity Framework из-за этого начали писать, и забросили LINQ2SQL.
C>>LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей. G>Это вам так кажется потому что Linq полноценно не пользовали.
Я его использовал. Ещё раз повторяю — в Java для большинства случаев Hibernate вполне хватает.
Здравствуйте, Cyberax, Вы писали:
C>LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей.
LINQ — это не только запросы к произвольным источникам данных (достаточно лишь реализации интерфейса IEnumerable, и никаких провайдеров). LINQ — это лямбда-функции, анонимные типы, in-line инициализаторы, extension методы. После шарпа очень трудно заставлять себя писать на яве, ибо оно выглядит как УГ. Там совершенно нет фана.
Здравствуйте, Cyberax, Вы писали:
G>>Можно ли такой же запрос написать для коллекции объектов? C>Нет (ну если свой провайдер не напишешь). Для XML — можно.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>Примеры в студию. C>>>Встраиваемый LDAP сервер — из недавнего. G>>Учитывая что .NET в полном варианте работает под Windows, то встраивавемый LDAP не сильно нужен так как есть AD. C>Только вот нужен был LDAP для специального сервера, который должен работать параллельно с AD, предоставляя некоторую очень специфическую функциональность.
Для этого можно и реляционную базу прикрутить.
G>>Это как раз пример слишком специфичного компонента, который .NET не очень нужен. C>Да-да. Как видишь, мне вот оказалось нужно.
А вот мне нужно Linq, extension methods, anonymous types итп, а также GUI типа WPF, ничего этого мнету в java.
Причем все эти страшные слова используются во много раз чаще, чем встраиваемый LDAP.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>Не надо мне такого счастья. C>>>Ну вот просто пока никому не нужно было. G>>Почему на C# всем нужно? C>Потому что в C# не умеют пользоваться Hibernate. Вон, даже целый Entity Framework из-за этого начали писать, и забросили LINQ2SQL.
C>>>LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей. G>>Это вам так кажется потому что Linq полноценно не пользовали. C>Я его использовал.
Наверное "смотрел" а не "использовал".
C>Ещё раз повторяю — в Java для большинства случаев Hibernate вполне хватает.
В java конечно хибернейта хватает, язык то не позволяет сделать что-то типа Linq при всем желании.
Здравствуйте, gandjustas, Вы писали:
G>>>Почему на C# всем нужно? C>>Потому что в C# не умеют пользоваться Hibernate. Вон, даже целый Entity Framework из-за этого начали писать, и забросили LINQ2SQL. G>
Ну так что сделать...
C>>Я его использовал. G>Наверное "смотрел" а не "использовал".
Использовал.
C>>Ещё раз повторяю — в Java для большинства случаев Hibernate вполне хватает. G>В java конечно хибернейта хватает, язык то не позволяет сделать что-то типа Linq при всем желании.
При всём желании есть Scala, где сейчас аналог LINQ вроде уже соорудили.
Здравствуйте, mrTwister, Вы писали:
C>>Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png T>Прелесть LInq — это не ORM, а возможность писать статически типизированные запросы с единым стандартным синтаксисом к любым источникам данных и не надо никаких ИДЕ, провайдеров и пр.
Так я же говорю — LINQ лучше, но в Java и того что есть хватает.
C>>Тормозной, особенно при работе с памятью (консервативный GC, однако). T>Зато, в отличии от .Net Framework, поддерживает расширенные инструкции процессоров (SSE, например). Да и проигрыш в производительности по памяти имхо не фатальный.
Абсолютно фатальный — в СОТНИ раз медленнее на вырожденных случаях. Да и оптимизатор в Mono не блещет красотой. А SSE и автовекторизация помогают очень уж редко.
Здравствуйте, mrTwister, Вы писали:
G>>>Можно ли такой же запрос написать для коллекции объектов? C>>Нет (ну если свой провайдер не напишешь). Для XML — можно. T>Провайдер будет работать через рефлекшен?
Можешь написать ускорить с компиляцией байт-кода. Как в том же OGNL...
Здравствуйте, gandjustas, Вы писали:
C>>Только вот нужен был LDAP для специального сервера, который должен работать параллельно с AD, предоставляя некоторую очень специфическую функциональность. G>Для этого можно и реляционную базу прикрутить.
Нельзя. Можно было бы — прикрутил.
G>>>Это как раз пример слишком специфичного компонента, который .NET не очень нужен. C>>Да-да. Как видишь, мне вот оказалось нужно. G>А вот мне нужно Linq, extension methods, anonymous types итп, а также GUI типа WPF, ничего этого мнету в java.
GUI типа WPF — это SWING. Анонимные типы в Java есть уже лет 12, extension methods — кривы.
G>Причем все эти страшные слова используются во много раз чаще, чем встраиваемый LDAP.
Тем не менее, под Java нашёлся LDAP, а под .NET — нет. И так много раз уже было.
Здравствуйте, Cyberax, Вы писали:
C>GUI типа WPF — это SWING. Анонимные типы в Java есть уже лет 12, extension methods — кривы.
Это совсем не тоже самое, что анонимные типы в шарпе. Причем я не говорю, что шарповские анонимные типы хуже явовских анонимных классов — это просто разные вещи.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Только вот нужен был LDAP для специального сервера, который должен работать параллельно с AD, предоставляя некоторую очень специфическую функциональность. G>>Для этого можно и реляционную базу прикрутить. C>Нельзя. Можно было бы — прикрутил.
Почему нельзя? Видел проекты где LDAP хранилище было на реляционной БД, а учитывая что вы функционал получаете через сервисы, то вообще пофиг какое там хранилище.
G>>>>Это как раз пример слишком специфичного компонента, который .NET не очень нужен. C>>>Да-да. Как видишь, мне вот оказалось нужно. G>>А вот мне нужно Linq, extension methods, anonymous types итп, а также GUI типа WPF, ничего этого мнету в java. C>GUI типа WPF — это SWING.
И декларативный байндинг умеет?
C>Анонимные типы в Java есть уже лет 12, extension methods — кривы.
А толку от анонимных классов без вывода типов в языке? Разве что для делегатов\функторов.
G>>Причем все эти страшные слова используются во много раз чаще, чем встраиваемый LDAP. C>Тем не менее, под Java нашёлся LDAP, а под .NET — нет. И так много раз уже было.
Да уж, многих базовых фич в джаве нету и не будет в ближайшее время, зато можно понтоваться кучей библиотек.
Здравствуйте, mrTwister, Вы писали:
C>>Абсолютно фатальный — в СОТНИ раз медленнее на вырожденных случаях. T>В реальной жизни такое не наблюдается.
Эххх... Опять я нереальный...
Переносили специальный комбинаторный алгоритм на .NET — так он работал торррррмозно на Mono (тогда ещё на альфе 2.0) из-за того, что создавалось очень большое количество временных объектов. На .NET FW оно работало прилично.
Здравствуйте, Cyberax, Вы писали:
G>>>>Это как раз пример слишком специфичного компонента, который .NET не очень нужен. C>>>Да-да. Как видишь, мне вот оказалось нужно. G>>А вот мне нужно Linq, extension methods, anonymous types итп, а также GUI типа WPF, ничего этого мнету в java. C>GUI типа WPF — это SWING. Анонимные типы в Java есть уже лет 12, extension methods — кривы.
Это Вы только что SWING c WPF сравнили?..
Кстати, а что для свинга есть что-то похожее на MS Expression Blend?
G>>Причем все эти страшные слова используются во много раз чаще, чем встраиваемый LDAP. C>Тем не менее, под Java нашёлся LDAP, а под .NET — нет. И так много раз уже было.
Здравствуйте, Cyberax, Вы писали:
G>>>>Не надо мне такого счастья. C>>>Ну вот просто пока никому не нужно было. G>>Почему на C# всем нужно? C>Потому что в C# не умеют пользоваться Hibernate.
Зачем же обощать... C>Вон, даже целый Entity Framework из-за этого начали писать, и забросили LINQ2SQL.
Просто Майкрософт внезапно осознало, что пора бы сделать свои версии популярных OS библиотек. Вот и вышли на свет: Unity (IoC / DI / AoP), ASP.NET MVC (web model view controller framework) и EF ("O/RM" tool).
Жаль только с EF вышел промах — они не так поняли концепцию O/RM. Вместо идеологически верного domain centric подхода вернулись к более data centric ориентированному. К тому же, вместо чистой модели с POCO (plain old c# objects), решили "загрязнить" модель атрибутами. Зачем это сделано было мне не понятно, т.к. мэппинг в xml описании модели это ни разу не отменило... Ну и много других мелочей, которые пока делают EF неконкурентом NH.
C>>>LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей. G>>Это вам так кажется потому что Linq полноценно не пользовали. C>Я его использовал. Ещё раз повторяю — в Java для большинства случаев Hibernate вполне хватает.
В .NET тоже. Только Linq это далеко не только язык запросов для O/RM...
Здравствуйте, Cyberax, Вы писали:
C>extension methods — кривы.
Забыл спросить... в каком плане они кривы? Хотя это синтаксический сахар, я их все же нахожу очень удобными в ряде ситуаций.
Андерсу, кстати, предлагали ввести extension events и extension properties в язык, но он признался, что они пока не видят способа для реализации extension свойств да так, чтоб оно не выглядело грязным хаком, а вписывалось в язык...
VD> 1. Возможностями. И тут у питона и шарпа даш на даш. Питон имеет мощьное метапрограммирование и по причинам своей динамической природы упрощает создание обобщенных реализаций, но при этом Питон резко проигрывает по скорости получаемых програм, не имеет возможностей вроде LINQ-а, имеет значительно более слабую поддержку IDE (и это не лечится по причине скриптовости).
Если под словом скриптовость подрзумевать динамическую типизацию
VD> Питон плохая замена овсу, тфу ты, Шарпу.
VD> Уроветь у него примерно такой же как у Шарпа, но ко всему прочему Питон интерпретатор. Все что можно получить в питоне — это скриптообразное метапрограммирование.
Mamut однажды (11 марта 2009 01:46) писал в rsdn.flame.comp:
> VD> Уроветь у него примерно такой же как у Шарпа, но ко всему прочему Питон интерпретатор. Все что можно получить в питоне — это скриптообразное метапрограммирование. > Что не мшает, скажем, тому же Ютубу
вебу пофигу. У него всеравно скорость передачи результата пользователю зачастую медленнее чем собственно обработка.
А вот локально... Локально таки да, будут тормоза. Сам понимаеш.
S> > VD> Уроветь у него примерно такой же как у Шарпа, но ко всему прочему Питон интерпретатор. Все что можно получить в питоне — это скриптообразное метапрограммирование.
S> > Что не мшает, скажем, тому же Ютубу
S> вебу пофигу. У него всеравно скорость передачи результата пользователю зачастую медленнее чем собственно обработка. S> А вот локально... Локально таки да, будут тормоза. Сам понимаеш.
Нет, не понимаю. Тормоза конкретно в чем?
ЗЫ. Прежде, чем ты опозоришься, отвечу сам. Есть классы задач, где производительность рулит. Типа числодробилки какие-нибудь. Или там кодеки. Если это ГУИ, то если время отклика такого гуи будет меньше скорости реакции человека, то пофиг на чем оно будет написано. Хоть на VB.
Здравствуйте, gandjustas, Вы писали:
C>>Нельзя. Можно было бы — прикрутил. G>Почему нельзя? Видел проекты где LDAP хранилище было на реляционной БД, а учитывая что вы функционал получаете через сервисы, то вообще пофиг какое там хранилище.
Мне нужно именно _LDAP_ было. Для внешней системы. Песни про DAO мне можно не петь.
C>>GUI типа WPF — это SWING. G>И декларативный байндинг умеет?
С нужными библиотеками. И даже в XML тоже умеет сериализовать.
А, ну ещё JavaFX забыл.
C>>Анонимные типы в Java есть уже лет 12, extension methods — кривы. G>А толку от анонимных классов без вывода типов в языке? Разве что для делегатов\функторов.
Ну примерно для этого и используется.
C>>Тем не менее, под Java нашёлся LDAP, а под .NET — нет. И так много раз уже было. G>Да уж, многих базовых фич в джаве нету и не будет в ближайшее время, зато можно понтоваться кучей библиотек.
Это говорит о том, что эти "базовые фичи" не являются обязательным требованием.
И они уже давно есть в других языках для JVM, например, в Scala.
Mamut однажды (11 марта 2009 01:59) писал в rsdn.flame.comp:
> Нет, не понимаю. Тормоза конкретно в чем?
В пониженной производительности.
> ЗЫ. Прежде, чем ты опозоришься, отвечу сам. Есть классы задач, где производительность рулит. Типа числодробилки какие-нибудь. Или там кодеки. Если это ГУИ, то если время отклика > такого гуи будет меньше скорости реакции человека, то пофиг на чем оно будет написано. Хоть на VB.
Ты как всегда, "на высоте". Представляю себе ГУИ тогоже CS, написанное на VB...
Люди, вы постоянно забываете что на компе хоть у пользователя, хоть на серваке работает НЕ ТОЛЬКО ваша с таким трудом написанная программа.
Здравствуйте, Cyberax, Вы писали:
C>>>GUI типа WPF — это SWING. G>>И декларативный байндинг умеет? C>С нужными библиотеками. И даже в XML тоже умеет сериализовать.
Какое отношение к этому имеет XML сериализация?
Но в самом деле, интересно, какие факторы позволили записать SWING в аналог WPF?
C>>>Анонимные типы в Java есть уже лет 12, extension methods — кривы. G>>А толку от анонимных классов без вывода типов в языке? Разве что для делегатов\функторов. C>Ну примерно для этого и используется.
Еще интересно, что кривого в extension methods?
C>>>Тем не менее, под Java нашёлся LDAP, а под .NET — нет. И так много раз уже было. G>>Да уж, многих базовых фич в джаве нету и не будет в ближайшее время, зато можно понтоваться кучей библиотек. C>Это говорит о том, что эти "базовые фичи" не являются обязательным требованием.
Ну и к библиотекам тоже самое... вообще пугает меня это разнообразие библиотек в проектах, тонны всего стороннего..
Оно что, правда весьма безглючно, надежно и не требует грабель?
C>И они уже давно есть в других языках для JVM, например, в Scala.
"Тут опять разница между теорией и практикой проявляется"
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, criosray, Вы писали:
КБ>>>Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры? C>>Никто не предлагает работать с БД через интерфейс объекта. Почитайте про Repository патерн и про UnitOfWork патерн.
КБ>Почитал. Оба паттерна просто великолепно могут работать с кортежами.
КБ>>>Неправда. Ваш вариант — написать руками объекты и из них сгенерить CREATE TABLE. Мой — сразу написать CREATE TABLE. И там и там приходится писать руками.
C>>Перед тем, как что-то писать руками надо подумать головой. Преимущество Domain Driven Design в том, что оно позволяет сконцентрироваться непосредственно на решении бизнес задачи и домен это есть домен самой бизнес задачи. База с данными это всего-лишь бэкенд.
КБ>Нет не позволяет. Она предлагает выдумывать какие-то суррогатные сковзные сущности, вместо того чтобы обратить внимание на реальную модель данных и на реальные потоки данных.
Не будь так категоричен. Бывают самые разные случаи. Где-то надо просто тупо вытащить из б.д на форму, плюс CRUD-операции. В подобных случаях, в самом деле, смысла городить объектную модель нет. Однако, существуют следующие случаи, когда это может оказаться очень уместным.
1. Над объектами предметной области выполняются нетривиальные операции, требующие соответствующего уровня абстракции.
2. Нужно заперсистить уже готовое приложение с ОО-дизайном в б.д. — частый случай.
3. Нужно сделать сервисную морду для данных объектов.
Вот как раз тогда такие удобные и мощные ОРМ, как хибернейт становятся очень полезны.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Sheridan, Вы писали:
S>Люди, вы постоянно забываете что на компе хоть у пользователя, хоть на серваке работает НЕ ТОЛЬКО ваша с таким трудом написанная программа.
Чё, серьезно? А мы то дураки отлаживаемся, отключая всё лишнее
Здравствуйте, criosray, Вы писали:
C>>GUI типа WPF — это SWING. Анонимные типы в Java есть уже лет 12, extension methods — кривы. C>Это Вы только что SWING c WPF сравнили?..
Да. Идеология похожая, хотя SWING на более старых технологиях сделан.
C>Кстати, а что для свинга есть что-то похожее на MS Expression Blend? http://www.netbeans.org/features/javafx/
G>>>Причем все эти страшные слова используются во много раз чаще, чем встраиваемый LDAP. C>>Тем не менее, под Java нашёлся LDAP, а под .NET — нет. И так много раз уже было. C>Novell LDAP .NET?
Мне нужен _сервер_. Встраиваемый.
Здравствуйте, MxKazan, Вы писали:
C>>С нужными библиотеками. И даже в XML тоже умеет сериализовать. MK>Какое отношение к этому имеет XML сериализация?
XAML и всё такое...
MK>Но в самом деле, интересно, какие факторы позволили записать SWING в аналог WPF?
Явное разделение вида и модели, отход от оконной модели интерфейса. Точнее, тут уж скорее WPF будет аналогом SWING'а, если смотреть на приоритет.
Естественно, WPF получился ещё и более развитым.
C>>Ну примерно для этого и используется. MK>Еще интересно, что кривого в extension methods?
Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём.
G>>>Да уж, многих базовых фич в джаве нету и не будет в ближайшее время, зато можно понтоваться кучей библиотек. C>>Это говорит о том, что эти "базовые фичи" не являются обязательным требованием. MK>Ну и к библиотекам тоже самое... вообще пугает меня это разнообразие библиотек в проектах, тонны всего стороннего..
Более того, оно ещё умеет автоматически устанавливаться по зависимостям!
MK>Оно что, правда весьма безглючно, надежно и не требует грабель?
Основные проекты (Spring, Hibernate, Apache *, ...) — надёжны, мне баги в фреймворках проблем не создают вообще.
C>>И они уже давно есть в других языках для JVM, например, в Scala. MK>"Тут опять разница между теорией и практикой проявляется"
Да, до некоторой степени, к сожалению. Но Скала постепенно становится практикой — она начинает поддерживаться в IDEA ( http://plugins.intellij.net/preview/popup/?sid=1682&pid=1347 )
Опять же, реально уже вполне есть нормальные альтернативные языки для JVM, которые широко поддерживаются фреймворками. Тот же Groovy и BeanShell.
Здравствуйте, Cyberax, Вы писали:
C>>Кстати, а что для свинга есть что-то похожее на MS Expression Blend? C>http://www.netbeans.org/features/javafx/
Это не совсем то... или скорее совсем не то. http://www.microsoft.com/expression/products/Overview.aspx?key=blend
G>>>>Причем все эти страшные слова используются во много раз чаще, чем встраиваемый LDAP. C>>>Тем не менее, под Java нашёлся LDAP, а под .NET — нет. И так много раз уже было. C>>Novell LDAP .NET? C>Мне нужен _сервер_. Встраиваемый.
Хм, ну так это ведь как-раз из упомянутой Вами категории — специфичных крайне мало востребованных вещей.
Здравствуйте, criosray, Вы писали:
C>>Потому что в C# не умеют пользоваться Hibernate. C>Зачем же обощать...
Ну кто-то умеет, согласен. Но не в целом все.
C>>Вон, даже целый Entity Framework из-за этого начали писать, и забросили LINQ2SQL. C>Просто Майкрософт внезапно осознало, что пора бы сделать свои версии популярных OS библиотек.
Ну дык. "Но у неё был фатальный недостаток..."
G>>>Это вам так кажется потому что Linq полноценно не пользовали. C>>Я его использовал. Ещё раз повторяю — в Java для большинства случаев Hibernate вполне хватает. C>В .NET тоже. Только Linq это далеко не только язык запросов для O/RM...
Таки именно для этого — как lightweight ORM для мэппинга результатов запросов из РБД на туплы. Естественно, LINQ можно использовать и для других целей, но изначально они таки для доступа к БД делался.
Здравствуйте, Cyberax, Вы писали:
MK>>Но в самом деле, интересно, какие факторы позволили записать SWING в аналог WPF? C>Явное разделение вида и модели, отход от оконной модели интерфейса. Точнее, тут уж скорее WPF будет аналогом SWING'а, если смотреть на приоритет.
Ну. Ладно. Я надеялся увидеть больше конкретики, но т.к. Swing не знаю, спорить не буду.
C>>>Ну примерно для этого и используется. MK>>Еще интересно, что кривого в extension methods? C>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём.
Extension methods используют публичный контракт класса, так что по факту никакого нарушения инкапсуляции нет.
G>>>>Да уж, многих базовых фич в джаве нету и не будет в ближайшее время, зато можно понтоваться кучей библиотек. C>>>Это говорит о том, что эти "базовые фичи" не являются обязательным требованием. MK>>Ну и к библиотекам тоже самое... вообще пугает меня это разнообразие библиотек в проектах, тонны всего стороннего.. C>Более того, оно ещё умеет автоматически устанавливаться по зависимостям!
Что устанавливаться, куда устанавливаться? Setup-проект в Студии тоже все сборочки упаковывает "по зависимостям".
MK>>Оно что, правда весьма безглючно, надежно и не требует грабель? C>Основные проекты (Spring, Hibernate, Apache *, ...) — надёжны, мне баги в фреймворках проблем не создают вообще.
Баги = фичи?
C>>>И они уже давно есть в других языках для JVM, например, в Scala. MK>>"Тут опять разница между теорией и практикой проявляется" C>Опять же, реально уже вполне есть нормальные альтернативные языки для JVM, которые широко поддерживаются фреймворками. Тот же Groovy и BeanShell.
Не, ну это уже двойные стандарты
Да, NetBeans это умеет, но не так гламурно.
C>>>Novell LDAP .NET? C>>Мне нужен _сервер_. Встраиваемый. C>Хм, ну так это ведь как-раз из упомянутой Вами категории — специфичных крайне мало востребованных вещей.
Так ещё бы. И вот на Java они есть, а на .NET — .нет
C>>>С нужными библиотеками. И даже в XML тоже умеет сериализовать. MK>>Какое отношение к этому имеет XML сериализация? :) C>XAML и всё такое...
:) Правильно ли я воспроизвёл твою мыслительную цепочку: «WPF как-то связан с XAML», «XAML как-то связан с XML», «XML связан в том числе и с сериализацией», «в Java есть возможности XML-сериализации», «Для Java есть GUI фреймворк Swing» ⇒ «GUI типа WPF — это SWING»?
MK>>Еще интересно, что кривого в extension methods? C>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём.
Хорошо известные «плюсистам» Герб С. (в Майкрософте, кстати, работает) и Андрей А. в своей Красной Книжке пишут:
44. Предпочитайте функции, которые не являются ни членами, ни друзьями.
Функции, не являющиеся членами или друзьями классов, повышают степень инкапсуляции путём снижения зависимостей: тело такой функции не может зависеть от закрытых и защищённых членов класса. Они также разрушают монолитность класса, снижая связность...
Свободные функции в C++ и статические методы в C# (а таковыми, по сути, и являются extension methods) хоть и не одно и то же, но для последних приведённая цитата остаётся в силе. Extension methods, помимо прочего, являются поддерживаемыми языком constraint'ами. Они гарантируют, что метод зависит только от публичного интерфейса, и при изменении деталей реализации его поведение достоверно не изменится, коль скоро не изменится публичный API. Это и есть инкапсуляция, а не «все методы класса должны быть в нём».
Здравствуйте, Cyberax, Вы писали:
C>>>С нужными библиотеками. И даже в XML тоже умеет сериализовать. MK>>Какое отношение к этому имеет XML сериализация? C>XAML и всё такое...
Гы! Сериализация сериализации рознь. XML-сериализация в том же .NET существует с незапамятных времён. Однако к XAML'у это не имеет никакого отношения.
MK>>Но в самом деле, интересно, какие факторы позволили записать SWING в аналог WPF? C>Явное разделение вида и модели,
Понятно. WPF Вы видели только на фотографии... причём чёрно-белой Swing, впрочем, похоже тоже.
Модель всегда отделена от её визуального представления, как минимум на логическом уровне. На то она и модель собственно. И задача состоит не в отделении, бо оно аксиома, а в обеспечении мощных и в то же время выразительных, простых и удобных механизмов связи модели с её конкретной визуализацией. Их и предоставляет WPF — binding'и для dependency property. Подобных вещей в Swing'е просто не существует.
C>отход от оконной модели интерфейса.
М-м-м... А где это в Swing'е-то можно увидеть ???
MK>>Еще интересно, что кривого в extension methods? C>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём.
Чушь. С инкапсуляцией здесь всё в порядке. Мы просто тип расширяем. Можете смотреть на этот момент как на облегчённую форму наследования, например.
Здравствуйте, Cyberax, Вы писали:
C>>>Ну примерно для этого и используется. MK>>Еще интересно, что кривого в extension methods? C>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём.
Где нарушение инкапсуляции?
C>>>И они уже давно есть в других языках для JVM, например, в Scala. MK>>"Тут опять разница между теорией и практикой проявляется" C>Да, до некоторой степени, к сожалению. Но Скала постепенно становится практикой — она начинает поддерживаться в IDEA ( http://plugins.intellij.net/preview/popup/?sid=1682&pid=1347 )
У меня на этом форуме стойкое чувство дежавю. Когда начинают говорить про фичи ФП в джаве сразу начинают рекомендовать скалу.
Далеко не все могут изучить еще один язык, а те кто могут изучить не всегда смогут его использовать.
gandjustas однажды (11 марта 2009 10:18) писал в rsdn.flame.comp:
> У меня на этом форуме стойкое чувство дежавю. Когда начинают говорить про фичи ФП в джаве сразу начинают > рекомендовать скалу. Далеко не все могут изучить еще один язык, а те кто могут изучить не всегда смогут его использовать.
Ой, не говори. Стоит вспомнить про дотнет — так сразу столько диалектов всплывает....
Здравствуйте, Cyberax, Вы писали:
G>>>>Это вам так кажется потому что Linq полноценно не пользовали. C>>>Я его использовал. Ещё раз повторяю — в Java для большинства случаев Hibernate вполне хватает. C>>В .NET тоже. Только Linq это далеко не только язык запросов для O/RM... C>Таки именно для этого — как lightweight ORM для мэппинга результатов запросов из РБД на туплы. Естественно, LINQ можно использовать и для других целей, но изначально они таки для доступа к БД делался.
Фигню говорите. Linq изначально язык объектых запросов, Linq2SQL прикрутили к релизу .NET 3.5 именно как proof of concept, а потом забросили, потому что параллельно развивался EF.
EF кстати вполне может и без Linq работать.
Здравствуйте, Sheridan, Вы писали:
>> У меня на этом форуме стойкое чувство дежавю. Когда начинают говорить про фичи ФП в джаве сразу начинают >> рекомендовать скалу. Далеко не все могут изучить еще один язык, а те кто могут изучить не всегда смогут его использовать. S>Ой, не говори. Стоит вспомнить про дотнет — так сразу столько диалектов всплывает....
Стоит вспомнить про дотнет, как сразу оно..то есть ты...короче и так понятно что всплывает.
Здравствуйте, Sheridan, Вы писали:
S>Люди, вы постоянно забываете что на компе хоть у пользователя, хоть на серваке работает НЕ ТОЛЬКО ваша с таким трудом написанная программа.
Еще там работает шеридан... а шеридану надо много много много ресурсов, чтоб писать много много много чуши на КСВ.
S> > Нет, не понимаю. Тормоза конкретно в чем? S> В пониженной производительности.
В пониженной производительности чего?
S> > ЗЫ. Прежде, чем ты опозоришься, отвечу сам. Есть классы задач, где производительность рулит. Типа числодробилки какие-нибудь. Или там кодеки. Если это ГУИ, то если время отклика S> > такого гуи будет меньше скорости реакции человека, то пофиг на чем оно будет написано. Хоть на VB.
S> Ты как всегда, "на высоте". Представляю себе ГУИ тогоже CS, написанное на VB...
Это ты, как всегда пукаешь в лужу. CS — это, с одной стороны, как раз пример приложения, где производительность важна, и с другой — пример приложения, которое не является постоянно используемым. Кстати, в первом CS все диалоги в меню можно было вытягивать из ресурсов — они чуть ли не MFC-шными были. Потому что именно для GUI даже в играх нафиг не нужна запредельная производительность.
S> Люди, вы постоянно забываете что на компе хоть у пользователя, хоть на серваке работает НЕ ТОЛЬКО ваша с таким трудом написанная программа.
Здравствуйте, Sheridan, Вы писали:
S>gandjustas однажды (11 марта 2009 10:18) писал в rsdn.flame.comp:
>> У меня на этом форуме стойкое чувство дежавю. Когда начинают говорить про фичи ФП в джаве сразу начинают >> рекомендовать скалу. Далеко не все могут изучить еще один язык, а те кто могут изучить не всегда смогут его использовать. S>Ой, не говори. Стоит вспомнить про дотнет — так сразу столько диалектов всплывает....
Ты исключительно по половине предложения читаешь?
Покажи где хоть раз предлагали использовать другой .NET язык для такой банальной вещи как ФВП?
Здравствуйте, Mamut, Вы писали:
S>> Люди, вы постоянно забываете что на компе хоть у пользователя, хоть на серваке работает НЕ ТОЛЬКО ваша с таким трудом написанная программа.
M>Ты постоянно забываешь о том, что здесь все работают за компьютерами. И прекрасно понимают, о чем говорят. Например: http://www.rsdn.ru/forum/message/3312548.aspx
И пофиг, что часть из этого написано далеко не на С++. Оно работает быстрее скорости моей реакции.
Мамутик! Ты ли это! Не узнаю... Ведь доказывал мне когда-то, что FF таааакой тормоз в сравнении с Opera в плане отклика пользовательского интерфейса...
Здравствуйте, Cyberax, Вы писали:
C>>>>Novell LDAP .NET? C>>>Мне нужен _сервер_. Встраиваемый. C>>Хм, ну так это ведь как-раз из упомянутой Вами категории — специфичных крайне мало востребованных вещей. C>Так ещё бы. И вот на Java они есть, а на .NET — .нет
C>Говорит о многом.
О многом говорит то что в дваве нету возможностей, используемых тысячами программистов каждый день.
А отсуствие какой-то редкоиспользуемой библиотеки не говорит ни о чем.
И пофиг, что часть из этого написано далеко не на С++. Оно работает быстрее скорости моей реакции.
kuj> Мамутик! Ты ли это! Не узнаю... Ведь доказывал мне когда-то, что FF таааакой тормоз в сравнении с Opera в плане отклика пользовательского интерфейса...
Изыди
ЗЫ. ФФ — страшный тормоз уже по сравнению со всем.
Здравствуйте, Mamut, Вы писали:
kuj>> M>Ты постоянно забываешь о том, что здесь все работают за компьютерами. И прекрасно понимают, о чем говорят. Например: http://www.rsdn.ru/forum/message/3312548.aspx
И пофиг, что часть из этого написано далеко не на С++. Оно работает быстрее скорости моей реакции.
kuj>> Мамутик! Ты ли это! Не узнаю... Ведь доказывал мне когда-то, что FF таааакой тормоз в сравнении с Opera в плане отклика пользовательского интерфейса...
M>Изыди
M>ЗЫ. ФФ — страшный тормоз уже по сравнению со всем.
Здравствуйте, Mamut, Вы писали:
M>ЗЫ. ФФ — страшный тормоз уже по сравнению со всем.
Вот чОрт! А пацаны то и не знают.
А я то, дурак, на FF перелез с IE/Maxthon именно по причине кошмарных тормозов IE. Причем что IE6 что IE7 — одна хрень, тормозидло.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Mamut, Вы писали:
kuj>> M>ЗЫ. ФФ — страшный тормоз уже по сравнению со всем. kuj>> Тьфу ты блин
M>Просто в отличие от некоторых фанатов, я имею счастье/несчастье наблюдать его на постоянной основе в сравнении с Safari 4.
M>Как только в Safari допилят developer tools до firebug'а, FF отправится на свалку истории на одном отдельно взятом компе.
Просто мак и линукс — ацтой. ФФ на них действительно тормоз. ФФ под виндой — летает.
Здравствуйте, Mamut, Вы писали:
kuj>> Мамутик! Ты ли это! Не узнаю... Ведь доказывал мне когда-то, что FF таааакой тормоз в сравнении с Opera в плане отклика пользовательского интерфейса... M>Изыди M>ЗЫ. ФФ — страшный тормоз уже по сравнению со всем.
Кстати, FF 3.5 — вполне так ничего по скорости. На уровне с остальными браузерами (Chrome и Safari).
CC> M>ЗЫ. ФФ — страшный тормоз уже по сравнению со всем.
CC> Вот чОрт! А пацаны то и не знают. CC> А я то, дурак, на FF перелез с IE/Maxthon именно по причине кошмарных тормозов IE. Причем что IE6 что IE7 — одна хрень, тормозидло.
Тормозил вряд ли IE, а тормозил почти наверняка собственно Maxthon. Хотя IE — тоже не подарок, соглашусь.
C> M>ЗЫ. ФФ — страшный тормоз уже по сравнению со всем. C> Кстати, FF 3.5 — вполне так ничего по скорости. На уровне с остальными браузерами (Chrome и Safari).
Хм. Надо будет попробовать. Подожду, пока на него Firebug переползет
Здравствуйте, Mamut, Вы писали:
CC>> M>ЗЫ. ФФ — страшный тормоз уже по сравнению со всем.
CC>> Вот чОрт! А пацаны то и не знают. CC>> А я то, дурак, на FF перелез с IE/Maxthon именно по причине кошмарных тормозов IE. Причем что IE6 что IE7 — одна хрень, тормозидло.
M>Тормозил вряд ли IE, а тормозил почти наверняка собственно Maxthon. Хотя IE — тоже не подарок, соглашусь.
Как оболочка может тормозить? Думай Мамутик, думай. ;>
Здравствуйте, Mamut, Вы писали:
M>Тормозил вряд ли IE, а тормозил почти наверняка собственно Maxthon.
Не. Проверял на двух разных компах на одних и тех же сайтах IE6/Maxthon/FF и IE7/Maxthon/FF.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
CC> M>Тормозил вряд ли IE, а тормозил почти наверняка собственно Maxthon. CC> Не. Проверял на двух разных компах на одних и тех же сайтах IE6/Maxthon/FF и IE7/Maxthon/FF.
Тогда меняю свою позицию с
ФФ — страшный тормоз уже по сравнению со всем.
на
ФФ — страшный тормоз уже по сравнению со всем, кроме IE
И все-таки ты не последовал моему совету... Как обычно перевел спор на лживую аналогию. Ну каким боком миллион плагинов фокса относится к безплагинной оболочке Maxton?
Эхх, мамутик мамутик... все тот же... все такие же двойные стандарты и взгляд на мир сквозь розовые очки...
M>Все, kuj уходит в полный и окончательный игнор
"Не верю!"
Здравствуйте, Mamut, Вы писали:
CC>> M>Тормозил вряд ли IE, а тормозил почти наверняка собственно Maxthon. CC>> Не. Проверял на двух разных компах на одних и тех же сайтах IE6/Maxthon/FF и IE7/Maxthon/FF.
M>Тогда меняю свою позицию с M>
M>ФФ — страшный тормоз уже по сравнению со всем.
M>на M>
M>ФФ — страшный тормоз уже по сравнению со всем, кроме IE
M>
Тогда уж:
ФФ — страшный тормоз уже по сравнению со всем под маком и линухом
Здравствуйте, Sheridan, Вы писали:
>> такого гуи будет меньше скорости реакции человека, то пофиг на чем оно будет написано. Хоть на VB. S>Ты как всегда, "на высоте". Представляю себе ГУИ тогоже CS, написанное на VB...
Шеридан, он не на высоте, он где был, там и стоит. Это просто ты с каждым сообщением оказываешься все глубже и глубже
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Mamut, Вы писали:
Вот можете мне объяснить простую вещь? (я ко всем обращаюсь) Почему когда мы обсуждали в т.ч. FF, вы плавно съехали на замыкания в императивных языках, а теперь, когда я завел тему про императивный язык, вы начали обсуждать FF?
Здравствуйте, kuj, Вы писали:
kuj>Как оболочка может тормозить?
Это Вы сильно неподумавши написали. Бо совершенно очевидно, что ещё как может.
Например, если сделать оболочку с нормальной security-изоляцией для IE (наподобие схемы Google Chrome), то производительность во многих местах запросто рухнет в разы.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Почему когда мы обсуждали в т.ч. FF, вы плавно съехали на замыкания в императивных языках, а теперь, когда я завел тему про императивный язык, вы начали обсуждать FF?
Возможно потому что они читают форум в древовидной форме, а Вы в плоской
Здравствуйте, drol, Вы писали:
D>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Почему когда мы обсуждали в т.ч. FF, вы плавно съехали на замыкания в императивных языках, а теперь, когда я завел тему про императивный язык, вы начали обсуждать FF?
D>Возможно потому что они читают форум в древовидной форме, а Вы в плоской
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Почему когда мы обсуждали в т.ч. FF, вы плавно съехали на замыкания в императивных языках, а теперь, когда я завел тему про императивный язык, вы начали обсуждать FF?
D>>Возможно потому что они читают форум в древовидной форме, а Вы в плоской
KV>Т.е. название темы вас не смущает?
Здравствуйте, Qbit86, Вы писали: Q>Основное отличие как раз не в этом, а в том, что «шарперы» делают свой выбор осознанно, на основе опыта разработки как на C++, так и на .NET. А «плюсисты» делают свой «выбор» на основе всяких «общих рассуждений», подогнанных под удобную точку зрения. (Чёрт, не могу найти тот демотиватор, в тему иллюстрирующий «плюсистов».)
Это точно. Вон Шеридан так и вообще, мнение про C# построил на основе Страуструпа (если не ошибаюсь, третье издание, хотя с него станется пользоваться и вторым).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
Q>>Основное отличие как раз не в этом, а в том, что «шарперы» делают свой выбор осознанно, на основе опыта разработки как на C++, так и на .NET. А «плюсисты» делают свой «выбор» на основе всяких «общих рассуждений», подогнанных под удобную точку зрения. (Чёрт, не могу найти тот демотиватор, в тему иллюстрирующий «плюсистов».) S>Это точно. Вон Шеридан так и вообще, мнение про C# построил на основе Страуструпа (если не ошибаюсь, третье издание, хотя с него станется пользоваться и вторым).
k> >> такого гуи будет меньше скорости реакции человека, то пофиг на чем оно будет написано. Хоть на VB. k> S>Ты как всегда, "на высоте". Представляю себе ГУИ тогоже CS, написанное на VB... k> Шеридан, он не на высоте, он где был, там и стоит.
Эээ. Это намек на то, что я не развиваюсь? Ыыыыы. Пошел читать SICP, даром, что он уже полгода дома валяется
Здравствуйте, kuj, Вы писали: kuj>Страуструп писал о С#? Что-то я пропустил...
Нет, не писал. Но Шеридан свое мнение про C# основывает исключительно на нём. Потому как никаких книг по шарпу он не читал.
Зато вот в обсуждении стоимости виртуального вызова в CLR он приводил скриншоты именно из Страуструпа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
k>> >> такого гуи будет меньше скорости реакции человека, то пофиг на чем оно будет написано. Хоть на VB. k>> S>Ты как всегда, "на высоте". Представляю себе ГУИ тогоже CS, написанное на VB... k>> Шеридан, он не на высоте, он где был, там и стоит.
M>Эээ. Это намек на то, что я не развиваюсь?
Не, ну представь, что на высоте в несколько сот метров из одной точки, одновременно, выпустили в свободное движение наковальню и воздушный шарик...
M>Ыыыыы. Пошел читать SICP, даром, что он уже полгода дома валяется
Здравствуйте, criosray, Вы писали:
C>>Эта пиииииииииииииииииии требует Silverlight для просмотра роликов. Блин. C>Архив с роликами (54 MB) C>http://download.microsoft.com/download/9/A/9/9A929DCE-7272-4055-88C2-2817B95A162C/05_blend2_Nugget.zip
Ага, посмотрел. Такого гламурного нет.
C>>Да, NetBeans это умеет, но не так гламурно. C>Прямо все-все умеет? И 3D рисовать, и timeframes для анимации, и аналог silverlight для web и т.д.?
JavaFX — это и есть аналог Silverlight. Timeframes для анимации там есть. 3D там пока нет, но есть 2D-анимация.
C>>Говорит о многом. C> C>Говорит только о том, что на дотнет оно как-то особо не нужно.
Нет, говорит о том, что многие разработчики не рассматривают его как вариант.
Здравствуйте, MxKazan, Вы писали:
C>>Явное разделение вида и модели, отход от оконной модели интерфейса. Точнее, тут уж скорее WPF будет аналогом SWING'а, если смотреть на приоритет. MK>Ну. Ладно. Я надеялся увидеть больше конкретики, но т.к. Swing не знаю, спорить не буду.
Что именно более конкретно нужно? Сам по себе Swing мало похож на WPF, но идеология в них сходная.
MK>>>Еще интересно, что кривого в extension methods? C>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём. MK>Extension methods используют публичный контракт класса, так что по факту никакого нарушения инкапсуляции нет.
Они маскируются под методы класса. Это уже нарушение.
MK>>>Ну и к библиотекам тоже самое... вообще пугает меня это разнообразие библиотек в проектах, тонны всего стороннего.. C>>Более того, оно ещё умеет автоматически устанавливаться по зависимостям! MK>Что устанавливаться, куда устанавливаться? Setup-проект в Студии тоже все сборочки упаковывает "по зависимостям".
См.: Maven2. Я прописываю в файле зависимость от org.hibernate:hibernate:3.2 и оно мне скачает Hibernate 3.2 с зависимостями из публичнго репозитория (http://repo2.maven.org/maven2/) и добавит в проект.
MK>>>Оно что, правда весьма безглючно, надежно и не требует грабель? C>>Основные проекты (Spring, Hibernate, Apache *, ...) — надёжны, мне баги в фреймворках проблем не создают вообще. MK>Баги = фичи?
Недокументированые фичи.
MK>>>"Тут опять разница между теорией и практикой проявляется" C>>Опять же, реально уже вполне есть нормальные альтернативные языки для JVM, которые широко поддерживаются фреймворками. Тот же Groovy и BeanShell. MK>Не, ну это уже двойные стандарты
Почему? Я не рассматриваю какой-нибудь Haskell для Java — его просто для практических целей не существует. А вот Groovy нормально поддерживается IDEA и Eclipse, т.е. им можно пользоваться.
Здравствуйте, gandjustas, Вы писали:
C>>Таки именно для этого — как lightweight ORM для мэппинга результатов запросов из РБД на туплы. Естественно, LINQ можно использовать и для других целей, но изначально они таки для доступа к БД делался. G>Фигню говорите. Linq изначально язык объектых запросов, Linq2SQL прикрутили к релизу .NET 3.5 именно как proof of concept, а потом забросили, потому что параллельно развивался EF.
The original idea of integrating data access into the general purpose programming language first appeared in the Cω research project at Microsoft Research. The data access possibilities integrated in Cω includes working with databases and structured XML data. The LINQ project is mostly based on Cω, however there are some differences.
Собственно, где-то были статьи про то, что LINQ добавили из-за того, что наиболее частой задачей для C# является работа с базами данных, и надо было как-то её упростить. То что LINQ можно использовать для запросов к нереляционным источникам — вполне логичное продолжение.
Здравствуйте, gandjustas, Вы писали:
MK>>>Еще интересно, что кривого в extension methods? C>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём. G>Где нарушение инкапсуляции?
Методы маскируются под объектные...
C>>Да, до некоторой степени, к сожалению. Но Скала постепенно становится практикой — она начинает поддерживаться в IDEA ( http://plugins.intellij.net/preview/popup/?sid=1682&pid=1347 ) G>У меня на этом форуме стойкое чувство дежавю. Когда начинают говорить про фичи ФП в джаве сразу начинают рекомендовать скалу.
Ну да. Это как-бы аналог C# в мире Java, когда сама Java — аналог VB.NET.
G>Далеко не все могут изучить еще один язык, а те кто могут изучить не всегда смогут его использовать.
То же относится к ФПшным фичам в C#.
gandjustas однажды (11 марта 2009 11:33) писал в rsdn.flame.comp:
> Покажи где хоть раз предлагали использовать другой .NET язык для такой банальной вещи как ФВП?
Почитай, тут сплошь и рядом скачки от немерля к Цшарпу и Фшарпу и обратно.
kuj однажды (11 марта 2009 10:51) писал в rsdn.flame.comp:
> Стоит вспомнить про дотнет, как сразу оно..то есть ты...короче и так понятно что всплывает.
И тебе здравствовать, феерически мудрый сенсей...
Здравствуйте, Cyberax, Вы писали:
MK>>>>Еще интересно, что кривого в extension methods? C>>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём. G>>Где нарушение инкапсуляции? C>Методы маскируются под объектные...
Они не маскируются. Они и есть объектные. RTFM про то, как реализованы extensions methods.
Sinclair однажды (11 марта 2009 14:23) писал в rsdn.flame.comp:
> Шеридан так и вообще, мнение про C# построил на основе Страуструпа (если не ошибаюсь, третье издание, хотя с него станется пользоваться и вторым).
Третье, "Специальное". А также "дизайн и эволюция С++".
Sinclair однажды (11 марта 2009 14:57) писал в rsdn.flame.comp:
> Здравствуйте, kuj, Вы писали: > kuj>Страуструп писал о С#? Что-то я пропустил... > Нет, не писал. Но Шеридан свое мнение про C# основывает исключительно на нём. Потому как никаких книг по шарпу он не читал.
Читал какието когдато давно, когда еще я нус помогал писать... Уже и не помню что, раздарил...
> Зато вот в обсуждении стоимости виртуального вызова в CLR он приводил скриншоты именно из Страуструпа.
Это из "Дизайн и эволюция С++"
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Таки именно для этого — как lightweight ORM для мэппинга результатов запросов из РБД на туплы. Естественно, LINQ можно использовать и для других целей, но изначально они таки для доступа к БД делался. G>>Фигню говорите. Linq изначально язык объектых запросов, Linq2SQL прикрутили к релизу .NET 3.5 именно как proof of concept, а потом забросили, потому что параллельно развивался EF. C>
C>The original idea of integrating data access into the general purpose programming language first appeared in the Cω research project at Microsoft Research. The data access possibilities integrated in Cω includes working with databases and structured XML data. The LINQ project is mostly based on Cω, however there are some differences.
C>Собственно, где-то были статьи про то, что LINQ добавили из-за того, что наиболее частой задачей для C# является работа с базами данных, и надо было как-то её упростить. То что LINQ можно использовать для запросов к нереляционным источникам — вполне логичное продолжение. Идея встроенного языка запросов появилась потому что хочется типизированно работать с БД.
Но утверджать что Linq создавался для доступа к данным ошибочно.
ЗЫ. В википедии в статье по Cω приводится пример именно работы с коллекциями объектов.
S> > Покажи где хоть раз предлагали использовать другой .NET язык для такой банальной вещи как ФВП?
S> Почитай, тут сплошь и рядом скачки от немерля к Цшарпу и Фшарпу и обратно.
В случае ФВП таких скачков не было. Хотя... Ты же не знаешь, что такое ФВП...
Здравствуйте, drol, Вы писали:
C>>XAML и всё такое... D>Гы! Сериализация сериализации рознь. XML-сериализация в том же .NET существует с незапамятных времён. Однако к XAML'у это не имеет никакого отношения.
Да я знаю. Просто я имею в виду, что есть именно аналоги XAML, а не просто дампы деревьев объектов.
MK>>>Но в самом деле, интересно, какие факторы позволили записать SWING в аналог WPF? C>>Явное разделение вида и модели, D>Понятно. WPF Вы видели только на фотографии... причём чёрно-белой Swing, впрочем, похоже тоже.
D>Модель всегда отделена от её визуального представления, как минимум на логическом уровне. На то она и модель собственно.
Она не отделена в WinForms и других подобных фреймворках. Скажем, в WinForms текстовое поле просто содержит строку, которую ты берёшь как "ctrl.Text".
Для сравнения, в Swing'е для JTextField для хранения и редактирования текста используется модель документа — http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/Document.html , который ты можешь реализовать поверх чего угодно. Вообще, в Swing'е даже у combobox'а есть своя модель (ComboBoxModel).
Аналогично и в WPF — только там для этого используется обобщённый DependencyObject.
D>И задача состоит не в отделении, бо оно аксиома, а в обеспечении мощных и в то же время выразительных, простых и удобных механизмов связи модели с её конкретной визуализацией. Их и предоставляет WPF — binding'и для dependency property. Подобных вещей в Swing'е просто не существует.
В Swing'е это реализуется с помощью виртуальных моделей. Binding реализуется с помощью сторонних библиотек — https://binding.dev.java.net/ , к примеру.
В WPF оно всё сделано более обобщённо и красиво, но суть та же самая осталась.
C>>отход от оконной модели интерфейса. D>М-м-м... А где это в Swing'е-то можно увидеть ???
Что именно? В Swing'е рисованием компонентов занимается look&feel, который отделён от самого контрола и может меняться (в том числе в runtime'е). Это можно на SwingSet2 посмотреть из поставки JDK. В JavaFX оно ещё больше отделено — есть явная концепция scene graph'а, на котором можно запускать анимации.
C>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём. D>Чушь. С инкапсуляцией здесь всё в порядке. Мы просто тип расширяем. Можете смотреть на этот момент как на облегчённую форму наследования, например.
Лучше явно выделять такие сервисы в сервисные классы.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>Явное разделение вида и модели, отход от оконной модели интерфейса. Точнее, тут уж скорее WPF будет аналогом SWING'а, если смотреть на приоритет. MK>>Ну. Ладно. Я надеялся увидеть больше конкретики, но т.к. Swing не знаю, спорить не буду. C>Что именно более конкретно нужно? Сам по себе Swing мало похож на WPF, но идеология в них сходная.\
Конкретно в чем заключается схожесть? Если в MVC, то что конкретно понимается под идеей MVC в Swing и WPF?
MK>>>>Еще интересно, что кривого в extension methods? C>>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём. MK>>Extension methods используют публичный контракт класса, так что по факту никакого нарушения инкапсуляции нет. C>Они маскируются под методы класса. Это уже нарушение.
Нет, они не маскируются под методы класса. Intelliscense, как и MSDN, явно выделяет extension методы. Но даже, если бы это было не так, я по прежнему не вижу, что они нарушают. Не согласен, приведи реальный пример, где использование extension methods опасно с точки зрения ООП.
MK>>>>Ну и к библиотекам тоже самое... вообще пугает меня это разнообразие библиотек в проектах, тонны всего стороннего.. C>>>Более того, оно ещё умеет автоматически устанавливаться по зависимостям! MK>>Что устанавливаться, куда устанавливаться? Setup-проект в Студии тоже все сборочки упаковывает "по зависимостям". C>См.: Maven2. Я прописываю в файле зависимость от org.hibernate:hibernate:3.2 и оно мне скачает Hibernate 3.2 с зависимостями из публичнго репозитория (http://repo2.maven.org/maven2/) и добавит в проект.
Ты правда считаешь, что это какая-то мега-супер-фича? А как ты узнал, что нужно прописать зависимость в виде строки "org.hibernate:hibernate:3.2"? Нашел? Ну так и я нужную библиотечку найду. Мест полно.
MK>>>>Оно что, правда весьма безглючно, надежно и не требует грабель? C>>>Основные проекты (Spring, Hibernate, Apache *, ...) — надёжны, мне баги в фреймворках проблем не создают вообще. MK>>Баги = фичи? C>Недокументированые фичи.
И после этого ты указываешь нам на кривизну extension методов?
MK>>>>"Тут опять разница между теорией и практикой проявляется" C>>>Опять же, реально уже вполне есть нормальные альтернативные языки для JVM, которые широко поддерживаются фреймворками. Тот же Groovy и BeanShell. MK>>Не, ну это уже двойные стандарты C>Почему? Я не рассматриваю какой-нибудь Haskell для Java — его просто для практических целей не существует. А вот Groovy нормально поддерживается IDEA и Eclipse, т.е. им можно пользоваться.
Уверен, можно пользоваться: C#, VB.Net, C++\CLI, Delphi.Net, F#, J#, Nemerle, IronPython. Мало?
Здравствуйте, MxKazan, Вы писали:
C>>Что именно более конкретно нужно? Сам по себе Swing мало похож на WPF, но идеология в них сходная.\ MK>Конкретно в чем заключается схожесть? Если в MVC, то что конкретно понимается под идеей MVC в Swing и WPF?
Ответил в другом письме.
C>>Они маскируются под методы класса. Это уже нарушение. MK>Нет, они не маскируются под методы класса. Intelliscense, как и MSDN, явно выделяет extension методы. Но даже, если бы это было не так, я по прежнему не вижу, что они нарушают. Не согласен, приведи реальный пример, где использование extension methods опасно с точки зрения ООП.
Ext. methods часто используются для нарушения SRP.
C>>См.: Maven2. Я прописываю в файле зависимость от org.hibernate:hibernate:3.2 и оно мне скачает Hibernate 3.2 с зависимостями из публичнго репозитория (http://repo2.maven.org/maven2/) и добавит в проект. MK>Ты правда считаешь, что это какая-то мега-супер-фича?
Ага.
MK>А как ты узнал, что нужно прописать зависимость в виде строки "org.hibernate:hibernate:3.2"? Нашел? Ну так и я нужную библиотечку найду. Мест полно.
Узнать — это фигня. В общем, читай предидущие флеймы про Maven.
MK>>>Баги = фичи? C>>Недокументированые фичи. MK>И после этого ты указываешь нам на кривизну extension методов?
Ну вообще-то, это достаточно общепринятое определение
C>>Почему? Я не рассматриваю какой-нибудь Haskell для Java — его просто для практических целей не существует. А вот Groovy нормально поддерживается IDEA и Eclipse, т.е. им можно пользоваться. MK>Уверен, можно пользоваться: C#, VB.Net, C++\CLI, Delphi.Net, F#, J#, Nemerle, IronPython. Мало?
J# — нельзя, Nemerle — весьма условно, VB.NET — зачем? Iron.Python и F# — это да, хорошие вещи.
Здравствуйте, Cyberax, Вы писали:
D>>Чушь. С инкапсуляцией здесь всё в порядке. Мы просто тип расширяем. Можете смотреть на этот момент как на облегчённую форму наследования, например. C>Лучше явно выделять такие сервисы в сервисные классы.
:) А extension methods, по-твоему, как реализуются? Ты даже можешь писать не так:
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
MK>>>>Еще интересно, что кривого в extension methods? C>>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём. G>>Где нарушение инкапсуляции? C>Методы маскируются под объектные...
Ну и что? Где нарушение инкапсуляции?
Нарушение инкапсуляции это когда для работы с объектом требуется знать о нем больше, чем только публичный контракт. Распухший публичный контракт класса говорит о том что инкапсуляция у вас была где-то нарушена.
Экстеншен методы не требуют дополннительных знаний, кроме того вынос некотороых методов класса в экстеншены позволяет упростить публичный контракт, что только улучшит инкапсуляцию.
C>>>Да, до некоторой степени, к сожалению. Но Скала постепенно становится практикой — она начинает поддерживаться в IDEA ( http://plugins.intellij.net/preview/popup/?sid=1682&pid=1347 ) G>>У меня на этом форуме стойкое чувство дежавю. Когда начинают говорить про фичи ФП в джаве сразу начинают рекомендовать скалу. C>Ну да. Это как-бы аналог C# в мире Java, когда сама Java — аналог VB.NET.
В VB.NET тоже много фич, которых в Java нету и в ближайшее время не будет.
Вообще в свете выравнивания VB.NET и C# по фичам в десятой\четвертой версии уже нет смысла рассматривать их как сильно разные языки.
G>>Далеко не все могут изучить еще один язык, а те кто могут изучить не всегда смогут его использовать. C>То же относится к ФПшным фичам в C#.
С чего бы это? Не нужна ни другая среда, ни другой компилятор, да и основные идиомы остаются теми же, да и не видел я ни одного случая когда человек который пишет на 2008 студии не использовал бы фичи C# 3.0
Здравствуйте, Sheridan, Вы писали:
S>gandjustas однажды (11 марта 2009 11:33) писал в rsdn.flame.comp:
>> Покажи где хоть раз предлагали использовать другой .NET язык для такой банальной вещи как ФВП? S>Почитай, тут сплошь и рядом скачки от немерля к Цшарпу и Фшарпу и обратно.
Если не занешь — молчи.
C# и F# поддерживают функции фвысшего порядка.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>Что именно более конкретно нужно? Сам по себе Swing мало похож на WPF, но идеология в них сходная.\ MK>>Конкретно в чем заключается схожесть? Если в MVC, то что конкретно понимается под идеей MVC в Swing и WPF? C>Ответил в другом письме.
Я честно говоря вообще не увидел связи между ComboBoxModel и DependencyObject. Давай лучше так. Вот у меня есть "модель документа". Как оно используется?
C>>>Они маскируются под методы класса. Это уже нарушение. MK>>Нет, они не маскируются под методы класса. Intelliscense, как и MSDN, явно выделяет extension методы. Но даже, если бы это было не так, я по прежнему не вижу, что они нарушают. Не согласен, приведи реальный пример, где использование extension methods опасно с точки зрения ООП. C>Ext. methods часто используются для нарушения SRP.
"Вы это по матерному, а-ли по научному" (c) Куклу
Конкретнее, без теории, ближе к практике.
MK>>А как ты узнал, что нужно прописать зависимость в виде строки "org.hibernate:hibernate:3.2"? Нашел? Ну так и я нужную библиотечку найду. Мест полно. C>Узнать — это фигня. В общем, читай предидущие флеймы про Maven.
Значит геммора тоже хватает. Ну...
C>>>Почему? Я не рассматриваю какой-нибудь Haskell для Java — его просто для практических целей не существует. А вот Groovy нормально поддерживается IDEA и Eclipse, т.е. им можно пользоваться. MK>>Уверен, можно пользоваться: C#, VB.Net, C++\CLI, Delphi.Net, F#, J#, Nemerle, IronPython. Мало? C>J# — нельзя, Nemerle — весьма условно, VB.NET — зачем? Iron.Python и F# — это да, хорошие вещи.
Зачем, зачем... Чтобы Шеридан наконец научился хоть что-то толковое под .Net писать.
И без того имеем разные другие хорошие вещи, на чем думаю данный абзац можно завершить
C>>>Они маскируются под методы класса. Это уже нарушение. MK>>Нет, они не маскируются под методы класса. Intelliscense, как и MSDN, явно выделяет extension методы. Но даже, если бы это было не так, я по прежнему не вижу, что они нарушают. Не согласен, приведи реальный пример, где использование extension methods опасно с точки зрения ООП. C>Ext. methods часто используются для нарушения SRP.
Это как?
Здравствуйте, MxKazan, Вы писали:
C>>Ответил в другом письме. MK>Я честно говоря вообще не увидел связи между ComboBoxModel и DependencyObject. Давай лучше так. Вот у меня есть "модель документа". Как оно используется?
Вот у тебя есть список элементов — реализуешь ListBackedListModel, и твой комбо-бокс будет отображать элементы этого списка.
А можешь реализовать BindingListModel, которая занимается binding'ом к другому свойству.
C>>Ext. methods часто используются для нарушения SRP. MK>"Вы это по матерному, а-ли по научному" (c) Куклу MK>Конкретнее, без теории, ближе к практике.
Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email".
C>>Узнать — это фигня. В общем, читай предидущие флеймы про Maven. MK>Значит геммора тоже хватает. Ну...
Нет, там .NET-овцы тоже утверждали, что потребности в колбасе нет.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>Ответил в другом письме. MK>>Я честно говоря вообще не увидел связи между ComboBoxModel и DependencyObject. Давай лучше так. Вот у меня есть "модель документа". Как оно используется? C>Вот у тебя есть список элементов — реализуешь ListBackedListModel, и твой комбо-бокс будет отображать элементы этого списка. C>А можешь реализовать BindingListModel, которая занимается binding'ом к другому свойству.
Я ничего не понял. Для меня WPF — это прежде всего шаблонность. Возможность через XAML изменять визуальное представление любого элемента управления без всякой строчки кода, используя любые примитивы. Ничего не стоит за 10 минут сворганить гибрид ListView с ListBox'ами в качестве item'ов, где элементы ListBox'а располагаются по горизонтали, а не по вертикали... И это только малая часть. Как это решается в Swing?
C>>>Ext. methods часто используются для нарушения SRP. MK>>"Вы это по матерному, а-ли по научному" (c) Куклу MK>>Конкретнее, без теории, ближе к практике. C>Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email".
Если в моём конкретном проекте класс String должен уметь валидировать email, то почему-бы и нет?
Здравствуйте, Cyberax, Вы писали:
C>>>Ext. methods часто используются для нарушения SRP. MK>>"Вы это по матерному, а-ли по научному" (c) Куклу MK>>Конкретнее, без теории, ближе к практике. C>Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email".
Если почитать про SRP, то можно понять что экстеншены не нарушают этот принцип.
Вообще экстеншены — не добавление методов в класс, вызов через точку — синтаксический сахар. Вполне мог бы быть вызов через любой другой значок, например -|- или ==]======>.
Здравствуйте, Cyberax, Вы писали:
C>Нет, там .NET-овцы тоже утверждали, что потребности в колбасе нет.
Раз овца, значит Долли, раз множественное число, значит много, раз много и Долли, значит клоны, раз много клонов, значит стадо... Граждане! Он вас стадом тупых клонированных овец обозвал!
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, gandjustas, Вы писали:
G>>==]======>. MK>call by dick
Я же вроде стер член и нирисовал меч.
Спалился блин...
kochetkov.vladimir однажды (11 марта 2009 17:47) писал в rsdn.flame.comp:
> C>Нет, там .NET-овцы тоже утверждали, что потребности в колбасе нет. > Раз овца, значит Долли, раз множественное число, значит много, раз много и Долли, значит клоны, раз много клонов, значит стадо... Граждане! Он вас стадом тупых клонированных овец > обозвал!
Чтото поздновато ты спохватился...
Здравствуйте, Cyberax, Вы писали:
C>>>Ответил в другом письме. MK>>Я честно говоря вообще не увидел связи между ComboBoxModel и DependencyObject. Давай лучше так. Вот у меня есть "модель документа". Как оно используется? C>Вот у тебя есть список элементов — реализуешь ListBackedListModel, и твой комбо-бокс будет отображать элементы этого списка.
C>А можешь реализовать BindingListModel, которая занимается binding'ом к другому свойству.
Здравствуйте, MxKazan, Вы писали:
C>>Вот у тебя есть список элементов — реализуешь ListBackedListModel, и твой комбо-бокс будет отображать элементы этого списка. C>>А можешь реализовать BindingListModel, которая занимается binding'ом к другому свойству. MK>Я ничего не понял. Для меня WPF — это прежде всего шаблонность. Возможность через XAML изменять визуальное представление любого элемента управления без всякой строчки кода, используя любые примитивы.
Это лишь способ сериализации свойств контролов. Есть аналогичные решения для Java, только вот не особо прижились.
MK>Ничего не стоит за 10 минут сворганить гибрид ListView с ListBox'ами в качестве item'ов, где элементы ListBox'а располагаются по горизонтали, а не по вертикали... И это только малая часть. Как это решается в Swing?
Таблицы и списки с кастомными контролами — сколько угодно. Просто их rendering делегируется нужному элементу: http://www.java2s.com/Code/Java/Swing-Components/RadioButtonTableExample.htm
MK>>>Конкретнее, без теории, ближе к практике. C>>Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email". MK>Если в моём конкретном проекте класс String должен уметь валидировать email, то почему-бы и нет?
Это не задача для класса строк (или его легковесного наследника).
Здравствуйте, Cyberax, Вы писали:
C>>>Ext. methods часто используются для нарушения SRP. MK>>"Вы это по матерному, а-ли по научному" (c) Куклу MK>>Конкретнее, без теории, ближе к практике. C>Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email".
String.ValidateEmail это просто плохой пример. Хорошим будет String.Reverse().
Фишка extension methods в том, что они позволяют очень просто реализовывать fluent интерфейс без существенных модифицаций существующих классов.
>>>> ФФ — страшный тормоз уже по сравнению со всем под маком и линухом
S>>>Осторожнее с рекурсией
C>>Где Вы там узрели рекурсию?
L>Существует ФФ для линукса, следовательно ФФ — страшный тормоз по сравнению с ФФ в том числе.
Бредятина.
Для тех, кто в танке и эстонцев уточняю:
ФФ под маком и линухом — страшный тормоз в сравнении с остальными браузерами под маком и линухом.
ФФ под виндой — не уступает, а местами даже обходит другие браузеры за счет более мощных банерорезалок.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>Вот у тебя есть список элементов — реализуешь ListBackedListModel, и твой комбо-бокс будет отображать элементы этого списка. C>>>А можешь реализовать BindingListModel, которая занимается binding'ом к другому свойству. MK>>Я ничего не понял. Для меня WPF — это прежде всего шаблонность. Возможность через XAML изменять визуальное представление любого элемента управления без всякой строчки кода, используя любые примитивы. C>Это лишь способ сериализации свойств контролов. Есть аналогичные решения для Java, только вот не особо прижились.
В WPF xaml определяет внешний вид элемента, в SWING видимо такого нет.
MK>>Ничего не стоит за 10 минут сворганить гибрид ListView с ListBox'ами в качестве item'ов, где элементы ListBox'а располагаются по горизонтали, а не по вертикали... И это только малая часть. Как это решается в Swing? C>Таблицы и списки с кастомными контролами — сколько угодно. Просто их rendering делегируется нужному элементу: C>http://www.java2s.com/Code/Java/Swing-Components/RadioButtonTableExample.htm
А без кода такое возможно?
MK>>>>Конкретнее, без теории, ближе к практике. C>>>Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email". MK>>Если в моём конкретном проекте класс String должен уметь валидировать email, то почему-бы и нет? C>Это не задача для класса строк (или его легковесного наследника).
Естественно это не его задача. Поэтому и выносят такие методы в экстеншен.
Здравствуйте, gandjustas, Вы писали:
C>>Это лишь способ сериализации свойств контролов. Есть аналогичные решения для Java, только вот не особо прижились. G>В WPF xaml определяет внешний вид элемента, в SWING видимо такого нет.
XAML — это просто формат сериализации графа объектов, заточенный под сериализацию контролов. В Swing'е аналогичное делается с помощью кода.
Есть и чистые XML-решения типа XAML, но они не получили распространения.
C>>Таблицы и списки с кастомными контролами — сколько угодно. Просто их rendering делегируется нужному элементу: C>>http://www.java2s.com/Code/Java/Swing-Components/RadioButtonTableExample.htm G>А без кода такое возможно?
Можно, например на JavaFX (который не совсем код).
Это же просто вопрос организации связей между объектами.
C>>Это не задача для класса строк (или его легковесного наследника). G>Естественно это не его задача. Поэтому и выносят такие методы в экстеншен.
Такие методы нужно выносить в отдельные сервисы.
C>>>Это лишь способ сериализации свойств контролов. Есть аналогичные решения для Java, только вот не особо прижились. G>>В WPF xaml определяет внешний вид элемента, в SWING видимо такого нет. C>XAML — это просто формат сериализации графа объектов, заточенный под сериализацию контролов. В Swing'е аналогичное делается с помощью кода.
XAML это в первую очередь стандарт.
G>>Естественно это не его задача. Поэтому и выносят такие методы в экстеншен. C>Такие методы нужно выносить в отдельные сервисы.
Ну так и есть. Просто они оформляются в виде extension methods. Банально удобно. Очень удобно.
Здравствуйте, Cyberax, Вы писали:
C>>>То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM? D>>Спасибо, но лучше не надо. Та ещё кривень... C>Чем?
Глюки при установке Java Plug-in. Глюки при установке в добавление к уже установленным JDK/JRE. Особенно если они другой "большой" версии, тут вообще бывали совсем жёсткие эффекты. Ну и мой любимый номер: у ихнего инсталлятора нет отдельной msi-базы для поддержки удаления. Они держат весь дистрибутив в этом качестве. И это полный капут, после года эксплуатации с апдейтами в этом бедном каталоге инсталлятора запросто накапливаются гигабайты. Очень "смешно" бывает в случае какой-нибудь виртуализации...
C>Для клиентов её вообще не ставим — она без установки идёт вместе с приложением. Приложение обычным NSIS'ом ставится.
Вот я и говорю — не ставили Вы её, родимую, en mass. Тащить с собой каждый раз тоже ничего хорошего. В итоге на машинах вечно по n-штук JRE разбросано в разных местах...
Здравствуйте, Cyberax, Вы писали:
C>XAML — это просто формат сериализации графа объектов, заточенный под сериализацию контролов. В Swing'е аналогичное делается с помощью кода.
XAML — это не просто ценный мех. Кроме графа объектов там есть ещё расширения синтаксиса XML — синтаксис привязок в атрибутах:
Читая г-на Cyberax нон-стоп ловлю какое-то "дежа вю" и связано оно с Делфи
когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). Увы, как язык джава сильно отстал от шарпа. Шарп бурно развивается ,стирая постепенно грань между функциональщиной и императивностью. Оно и неудивительно, МС вкладывает кучу денег в исследования и разработку. Развивается бурно и сам дотнет-фреймворк, дополняясь морем полезных классов. Бурно растут разлиные опен-соурс проекты для дотнета. Sun же пока считает убытки. Не до джавы ему, однако. Еще пару-тройку лет, и джаве, увы, будет уготована роль некогда могучего и популярного делфи. Уж очень похожа ситуация, уж очень похожи аргументы сторонников "тогда" и "сейчас".
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Это лишь способ сериализации свойств контролов. Есть аналогичные решения для Java, только вот не особо прижились. G>>В WPF xaml определяет внешний вид элемента, в SWING видимо такого нет. C>XAML — это просто формат сериализации графа объектов, заточенный под сериализацию контролов. В Swing'е аналогичное делается с помощью кода.
"аналогичное" и "с помощью кода" слегка противоречат друг другу.
C>Есть и чистые XML-решения типа XAML, но они не получили распространения.
Значит им до "типа XAML" очень далеко.
C>>>Таблицы и списки с кастомными контролами — сколько угодно. Просто их rendering делегируется нужному элементу: C>>>http://www.java2s.com/Code/Java/Swing-Components/RadioButtonTableExample.htm G>>А без кода такое возможно? C>Можно, например на JavaFX (который не совсем код).
Ну и где оно работает? Да и не SWING это вообще.
C>Это же просто вопрос организации связей между объектами.
Любая программа "просто вопрос организации связей между объектами".
C>>>Это не задача для класса строк (или его легковесного наследника). G>>Естественно это не его задача. Поэтому и выносят такие методы в экстеншен. C>Такие методы нужно выносить в отдельные сервисы.
Ну так они и выносятся, вызов через точку — сахар, чтобы не помнить все имена сервисов.
имеет ли господин Cyberax мнение, относительно того, почему первоначально любофф гугла к джаве, окончилась так быстро?
выпустили GWT, частично gmail на джаве сделали, и — всё. С++ и Python — вот языки на которых пишут в гугле.
ну, с плюсами понятно.
а вот, чего джаву задвинули и вместо неё Python? видимо, не читали рсдн.ру(КСВ и посты г-на Cyberax) гугловцы и не в курсе, что джава — это мегакруто и там есть библиотечки на все случаи жизни (ну, там есть и багов много, но г-н Cyberax предложил их считать недокументированными фичами )
П.С. как-то уверенности в будущем питона существенно больше, чем в будущем джавы. Увы.
Здравствуйте, vit.rsdn, Вы писали:
VR>имеет ли господин Cyberax мнение, относительно того, почему первоначально любофф гугла к джаве, окончилась так быстро? VR>выпустили GWT, частично gmail на джаве сделали, и — всё. С++ и Python — вот языки на которых пишут в гугле.
Умм... Как насчёт Android'а?
В Гугле вообще много чего пишут на Java — Adwords, Google Apps и т.д.
VR>ну, с плюсами понятно. VR>а вот, чего джаву задвинули и вместо неё Python?
Это просто означает, что в Гугле _не_ _только_ на Java пишут
Как-то нормальные защитники Java не утверждают, что это один язык, который всё должен заменить.
Здравствуйте, gandjustas, Вы писали:
G>>>А без кода такое возможно? C>>Можно, например на JavaFX (который не совсем код). G>Ну и где оно работает?
Там где есть Java.
G>Да и не SWING это вообще.
Именно что Swing JavaFX — это просто обёртка над ним.
G>>>Естественно это не его задача. Поэтому и выносят такие методы в экстеншен. C>>Такие методы нужно выносить в отдельные сервисы. G>Ну так они и выносятся, вызов через точку — сахар, чтобы не помнить все имена сервисов.
Это неправильный сахар.
Здравствуйте, vit.rsdn, Вы писали:
VR>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки).
Так ведь, действительно, компоненты были...
VR>Увы, как язык джава сильно отстал от шарпа. Шарп бурно развивается ,стирая постепенно грань между функциональщиной и императивностью. Оно и неудивительно, МС вкладывает кучу денег в исследования и разработку.
Sun зато вкладывает кучу денег в исследования и разработку самой JVM. Она до сих пор намного технологичнее .NET VM остаётся — в Java более умные gargage collector'ы, есть адаптивная оптимизация (технология HotSpot), и т.д.
А прикладными языками там занимаются отдельные товарищи.
VR>Развивается бурно и сам дотнет-фреймворк, дополняясь морем полезных классов. Бурно растут разлиные опен-соурс проекты для дотнета. Sun же пока считает убытки. Не до джавы ему, однако. Еще пару-тройку лет, и джаве, увы, будет уготована роль некогда могучего и популярного делфи. Уж очень похожа ситуация, уж очень похожи аргументы сторонников "тогда" и "сейчас".
Вообще-то, если ты не заметил, Дельфи превратился именно в .NET
Здравствуйте, drol, Вы писали:
D>Глюки при установке Java Plug-in. Глюки при установке в добавление к уже установленным JDK/JRE. Особенно если они другой "большой" версии, тут вообще бывали совсем жёсткие эффекты.
Не встречал.
D>Ну и мой любимый номер: у ихнего инсталлятора нет отдельной msi-базы для поддержки удаления. Они держат весь дистрибутив в этом качестве. И это полный капут, после года эксплуатации с апдейтами в этом бедном каталоге инсталлятора запросто накапливаются гигабайты. Очень "смешно" бывает в случае какой-нибудь виртуализации...
Это из-за того, что они используют инкрементальные обновления. Хотя старые версии всё же неплохо было бы очищать.
C>>Для клиентов её вообще не ставим — она без установки идёт вместе с приложением. Приложение обычным NSIS'ом ставится. D>Вот я и говорю — не ставили Вы её, родимую, en mass. Тащить с собой каждый раз тоже ничего хорошего. В итоге на машинах вечно по n-штук JRE разбросано в разных местах...
Мы сейчас как альтернативу используем WebStart — никаких проблем. Пользователь идёт на java.com и делает download. Отдельный дистрибутив — для клиентов без инета.
Здравствуйте, vit.rsdn, Вы писали:
VR> Читая г-на Cyberax нон-стоп ловлю какое-то "дежа вю" и связано оно с Делфи VR>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). Увы, как язык джава сильно отстал от шарпа. Шарп бурно развивается ,стирая постепенно грань между функциональщиной и императивностью. Оно и неудивительно, МС вкладывает кучу денег в исследования и разработку. Развивается бурно и сам дотнет-фреймворк, дополняясь морем полезных классов. Бурно растут разлиные опен-соурс проекты для дотнета. Sun же пока считает убытки. Не до джавы ему, однако. Еще пару-тройку лет, и джаве, увы, будет уготована роль некогда могучего и популярного делфи. Уж очень похожа ситуация, уж очень похожи аргументы сторонников "тогда" и "сейчас".
Это ты перегнул палку. У джава есть ниша, из которой ее пока ничто и никто не выбьет.
Гы! Ну так и уважаемый MxKazan глюков инсталлятора .NET FW тоже не встречал
А я вот компромат на обоих имею
C>Мы сейчас как альтернативу используем WebStart — никаких проблем.
JWS мне всегда нравился. ClickOnce в .NET практически тоже самое, но как-то подозрительно мне оно всё равно...
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>Вот у тебя есть список элементов — реализуешь ListBackedListModel, и твой комбо-бокс будет отображать элементы этого списка. C>>>А можешь реализовать BindingListModel, которая занимается binding'ом к другому свойству. MK>>Я ничего не понял. Для меня WPF — это прежде всего шаблонность. Возможность через XAML изменять визуальное представление любого элемента управления без всякой строчки кода, используя любые примитивы. C>Это лишь способ сериализации свойств контролов. Есть аналогичные решения для Java, только вот не особо прижились.
Вот я про Swing не стал спорить именно потому, что его не знаю (да я вообще в Java не бум-бум, а жаль). И советую про WPF тоже не спорить, потому что я сам, общаясь с некоторыми своими коллегами с бывшей работы, вижу огромное неприятие WPF. Но потом оказывается, что они его просто не знают и не понимают! На самом деле WPF это ГОРАЗДО больше чем очередной WinForms с сериализацией свойств. Это даже вообще не WinForms и не WinAPI. Но это трудно описать, с этим надо работать самому.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, vit.rsdn, Вы писали:
VR>> Читая г-на Cyberax нон-стоп ловлю какое-то "дежа вю" и связано оно с Делфи VR>>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). Увы, как язык джава сильно отстал от шарпа. Шарп бурно развивается ,стирая постепенно грань между функциональщиной и императивностью. Оно и неудивительно, МС вкладывает кучу денег в исследования и разработку. Развивается бурно и сам дотнет-фреймворк, дополняясь морем полезных классов. Бурно растут разлиные опен-соурс проекты для дотнета. Sun же пока считает убытки. Не до джавы ему, однако. Еще пару-тройку лет, и джаве, увы, будет уготована роль некогда могучего и популярного делфи. Уж очень похожа ситуация, уж очень похожи аргументы сторонников "тогда" и "сейчас".
kuj>Это ты перегнул палку. У джава есть ниша, из которой ее пока ничто и никто не выбьет.
у Делфи была ниша "из которой её никто не выбьет"
у плюсов была ниша "из которой их никто не выбьет" — а над новопявившейся тогда джавой не смеялся только самый ленивый плюсовик, однако , она и стала ,по сути, первым могильщиком плюсов
и т.д. и т.п.
Здравствуйте, Cyberax, Вы писали:
VR>>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). C>Так ведь, действительно, компоненты были...
Их и сейчас на любой вкус и цвет
C>Вообще-то, если ты не заметил, Дельфи превратился именно в .NET
Не надо грязи. Дельфи живет своей, отдельной от .Net жизнью
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vit.rsdn, Вы писали:
VR>>имеет ли господин Cyberax мнение, относительно того, почему первоначально любофф гугла к джаве, окончилась так быстро? VR>>выпустили GWT, частично gmail на джаве сделали, и — всё. С++ и Python — вот языки на которых пишут в гугле. C>Умм... Как насчёт Android'а?
C>В Гугле вообще много чего пишут на Java — Adwords, Google Apps и т.д.
конечно, тогда(несколько лет назад) делали ставку на джаву. Написали на ней кучу кода и потратили тысячи человеко-часов. И сейчас переписывать всё на помесь питона и плюсов, просто глупо. Проще и выгодней сопровождать.
а вот новое уже стараются делать на питоне.
VR>>ну, с плюсами понятно. VR>>а вот, чего джаву задвинули и вместо неё Python? C>Это просто означает, что в Гугле _не_ _только_ на Java пишут
C>Как-то нормальные защитники Java не утверждают, что это один язык, который всё должен заменить.
тю. Когда г-н Cyberax любит козырять "а вот у джавы есть чудо-библиотечка" при каждом удобном случае, увы, складывается именно такое впечатление
Здравствуйте, hattab, Вы писали:
VR>>>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). C>>Так ведь, действительно, компоненты были... H>Их и сейчас на любой вкус и цвет
Всё же, Дельфи намного ограниченнее в этой области была. Успешные компоненты так или иначе обычно были связаны с GUI.
В Java как раз строго обратное — большинство библиотек для server-side делаются.
C>>Вообще-то, если ты не заметил, Дельфи превратился именно в .NET H>Не надо грязи. Дельфи живет своей, отдельной от .Net жизнью
Перефразируя одного дельфиста: ".NET — рулез! Пишешь как не Дельфи, но не при этом стыдно говорить на чём пишешь".
Здравствуйте, vit.rsdn, Вы писали:
C>>В Гугле вообще много чего пишут на Java — Adwords, Google Apps и т.д. VR>конечно, тогда(несколько лет назад) делали ставку на джаву. Написали на ней кучу кода и потратили тысячи человеко-часов. И сейчас переписывать всё на помесь питона и плюсов, просто глупо. Проще и выгодней сопровождать.
Так зачем тогда они новые проекты на _Java_ начинают?
VR>а вот новое уже стараются делать на питоне. http://www.controlenter.in/2008/10/google-developer-day-bangalore-google-app-engine-to-support-java-android-sdk-release-on-oct-22/ — в Google App Engine будет Java работать. Упс.
C>>Как-то нормальные защитники Java не утверждают, что это один язык, который всё должен заменить. VR>тю. Когда г-н Cyberax любит козырять "а вот у джавы есть чудо-библиотечка" при каждом удобном случае, увы, складывается именно такое впечатление
Есть. Просто иногда всякие мелочи удобнее на Питоне писать. Например, у меня в проекте на Java есть система миграции БД на (о ужас!) Питоне.
Здравствуйте, MxKazan, Вы писали:
C>>Это лишь способ сериализации свойств контролов. Есть аналогичные решения для Java, только вот не особо прижились. MK>Вот я про Swing не стал спорить именно потому, что его не знаю (да я вообще в Java не бум-бум, а жаль). И советую про WPF тоже не спорить, потому что я сам, общаясь с некоторыми своими коллегами с бывшей работы, вижу огромное неприятие WPF. Но потом оказывается, что они его просто не знают и не понимают! На самом деле WPF это ГОРАЗДО больше чем очередной WinForms с сериализацией свойств. Это даже вообще не WinForms и не WinAPI. Но это трудно описать, с этим надо работать самому.
Естественно. Аналогичная история случается с новичками в Swing'е.
Здравствуйте, Cyberax, Вы писали:
C>>>Так ведь, действительно, компоненты были... H>>Их и сейчас на любой вкус и цвет C>Всё же, Дельфи намного ограниченнее в этой области была. Успешные компоненты так или иначе обычно были связаны с GUI.
Собствено, в какую нишу она и позиционировалась
C>>>Вообще-то, если ты не заметил, Дельфи превратился именно в .NET H>>Не надо грязи. Дельфи живет своей, отдельной от .Net жизнью C>Перефразируя одного дельфиста: ".NET — рулез! Пишешь как не Дельфи, но не при этом стыдно говорить на чём пишешь".
Щас, найду... Цитата из NVRN.HUMOR 2003 года:
Программирование под Майкрософт.Net — это как секс с представителем своего
пола — пока этим не займешься, сама мысль об этом кажется извращением. После
того, как этим займешься, понимаешь, что наверное что-то в этом есть, но
друзьям признаться стыдно.
kuj>>Это ты перегнул палку. У джава есть ниша, из которой ее пока ничто и никто не выбьет. VR>у Делфи была ниша "из которой её никто не выбьет"
Какая к черту ниша у делфи? Не было у Делфи ниши. В гомноинститутах, разве что, учить гомнопрограммирование на гомноязыке (delphi language).
VR>у плюсов была ниша "из которой их никто не выбьет" — а над новопявившейся тогда джавой не смеялся только самый ленивый плюсовик, однако , она и стала ,по
сути, первым могильщиком плюсов
Что за чушь? У С++ как была своя ниша, так и осталась и никуда она не делась. Пертурбации конечно были, но никаких кардинальных изменений не было. Java заняла корпоративный сектор, где С++ почти и не пахло-то никогда.
VR>и т.д. и т.п.
Да чего далее-то? У Джавы пока нет вменяемых конкурентов в ее нише. Конкуренция есть на уровне выбора платформы — xNix или Win, а на уровне языков нет конкуренции. Мало кто, выбрав Windows платформу, предпочтет дотнету джаву, про xnix говорить нечего — там царство джавы.
Здравствуйте, vit.rsdn, Вы писали:
VR>>>имеет ли господин Cyberax мнение, относительно того, почему первоначально любофф гугла к джаве, окончилась так быстро? VR>>>выпустили GWT, частично gmail на джаве сделали, и — всё. С++ и Python — вот языки на которых пишут в гугле. C>>Умм... Как насчёт Android'а?
C>>В Гугле вообще много чего пишут на Java — Adwords, Google Apps и т.д. VR>конечно, тогда(несколько лет назад) делали ставку на джаву. Написали на ней кучу кода и потратили тысячи человеко-часов. И сейчас переписывать всё на помесь питона и плюсов, просто глупо. Проще и выгодней сопровождать. VR>а вот новое уже стараются делать на питоне.
Зашибись... может поведаешь нам нафига переходить с нормальной платформы на помесь гомноязыка со скриптом? Какой в этом сакральный смысл?
Здравствуйте, kuj, Вы писали:
kuj>>>Это ты перегнул палку. У джава есть ниша, из которой ее пока ничто и никто не выбьет. VR>>у Делфи была ниша "из которой её никто не выбьет" kuj>Какая к черту ниша у делфи? Не было у Делфи ниши. В гомноинститутах, разве что, учить гомнопрограммирование на гомноязыке (delphi language).
Да блин, что же это — из крайности в крайность. Не забывай, кто является главным архитектором C#.
По мне, так C# и .Net идеологически очень схожи с Delphi.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, vit.rsdn, Вы писали:
VR>>>>имеет ли господин Cyberax мнение, относительно того, почему первоначально любофф гугла к джаве, окончилась так быстро? VR>>>>выпустили GWT, частично gmail на джаве сделали, и — всё. С++ и Python — вот языки на которых пишут в гугле. C>>>Умм... Как насчёт Android'а?
C>>>В Гугле вообще много чего пишут на Java — Adwords, Google Apps и т.д. VR>>конечно, тогда(несколько лет назад) делали ставку на джаву. Написали на ней кучу кода и потратили тысячи человеко-часов. И сейчас переписывать всё на помесь питона и плюсов, просто глупо. Проще и выгодней сопровождать. VR>>а вот новое уже стараются делать на питоне. kuj>Зашибись... может поведаешь нам нафига переходить с нормальной платформы на помесь гомноязыка со скриптом? Какой в этом сакральный смысл?
вопрос не ко мне
для меня тоже загадка
если бы про джаву речь была бы, я бы не удивился
но, питон
собственно, надеялся в этой ветке получить ответ, но, пока я его не нашёл
Здравствуйте, MxKazan, Вы писали:
kuj>>>>Это ты перегнул палку. У джава есть ниша, из которой ее пока ничто и никто не выбьет. VR>>>у Делфи была ниша "из которой её никто не выбьет" kuj>>Какая к черту ниша у делфи? Не было у Делфи ниши. В гомноинститутах, разве что, учить гомнопрограммирование на гомноязыке (delphi language). MK>Да блин, что же это — из крайности в крайность. Не забывай, кто является главным архитектором C#.
Что совсем не отменяет того факта, что Делфи превратился в гомноязык по нынешним меркам с тех пор, как Хаелсберг покинул Борланд.
MK>По мне, так C# и .Net идеологически очень схожи с Delphi.
Бугагагага... Пиши еще.
Здравствуйте, hattab, Вы писали:
H>>>Щас, найду... Цитата из NVRN.HUMOR 2003 года: MK>>Я не понимаю, для чего цитировать дебилов.
H>Не принимай близко к сердцу. Лучше чувство юмора прокачай
Здравствуйте, kuj, Вы писали:
MK>>По мне, так C# и .Net идеологически очень схожи с Delphi. kuj>Бугагагага... Пиши еще.
Вот IT в соседней ветке писал о вызове через точку
. Это можно отнести к влиянию Явы, а можно и к Делфи, где тоже только точка. Та же фигня со свойствами. Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи. Сейчас C#, конечно, далеко ушел от Делфи, но, когда я в брался за изучение еще первого .Net, не покидало ощущение эдакого о-Делфённого Си.
Здравствуйте, olexandr, Вы писали:
G>>ЗЫ. В википедии в статье по Cω приводится пример именно работы с коллекциями объектов. O>Cω это шо такое? Си с яйцами? (:
Cω (pronounced C omega, /Ō-mē'gɘ/ or /Ō-mĕg'ɘ/;[1] usually written as "Cw" or "Comega language") is a free extension to the C# programming language, developed by the WebData team in Microsoft SQL Server in collaboration with Microsoft Research in the UK and Redmond. It was formerly known as the codenames "X#" (X Sharp) and "Xen". It was renamed Cω after Polyphonic C#, another research language based on Join calculus, was integrated into it.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Cyberax, Вы писали:
VR>>>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). C>>Так ведь, действительно, компоненты были... H>Их и сейчас на любой вкус и цвет
Только в делфи компоненты гуевые, а в джаве компонентный подход есть на всех уровнях приложения.
C>>Вообще-то, если ты не заметил, Дельфи превратился именно в .NET H>Не надо грязи. Дельфи живет своей, отдельной от .Net жизнью
"Живет" громко сказано, новые проекты на делфи начинают только там, где разработчики ничего другого не знают.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Cyberax, Вы писали:
C>>>>Так ведь, действительно, компоненты были... H>>>Их и сейчас на любой вкус и цвет C>>Всё же, Дельфи намного ограниченнее в этой области была. Успешные компоненты так или иначе обычно были связаны с GUI. H>Собствено, в какую нишу она и позиционировалась
В мировом масштабе ниши у делфи никогда не было.
На территории Росии и СНГ делфи пользовалась значительной популярностью по причине того что делфи изучали во всех вузах, в отличие даже от С\С++.
C>>>>Вообще-то, если ты не заметил, Дельфи превратился именно в .NET H>>>Не надо грязи. Дельфи живет своей, отдельной от .Net жизнью C>>Перефразируя одного дельфиста: ".NET — рулез! Пишешь как не Дельфи, но не при этом стыдно говорить на чём пишешь".
H>Щас, найду... Цитата из NVRN.HUMOR 2003 года: H>
Программирование под Майкрософт.Net — это как секс с представителем своего
H>пола — пока этим не займешься, сама мысль об этом кажется извращением. После
H>того, как этим займешься, понимаешь, что наверное что-то в этом есть, но
H>друзьям признаться стыдно.
H>Как, слушай, изменились взгляды
Да уж, NVRN.HUMOR — прямо источник объективности.
Лучше бы цитаты с баша приводили.
Здравствуйте, Cyberax, Вы писали:
VR>>Увы, как язык джава сильно отстал от шарпа. Шарп бурно развивается ,стирая постепенно грань между функциональщиной и императивностью. Оно и неудивительно, МС вкладывает кучу денег в исследования и разработку. C>Sun зато вкладывает кучу денег в исследования и разработку самой JVM. Она до сих пор намного технологичнее .NET VM остаётся — в Java более умные gargage collector'ы, есть адаптивная оптимизация (технология HotSpot), и т.д.
Но при этом Java тормознее .NET.
Здравствуйте, gandjustas, Вы писали:
VR>>>>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). C>>>Так ведь, действительно, компоненты были... H>>Их и сейчас на любой вкус и цвет G>Только в делфи компоненты гуевые, а в джаве компонентный подход есть на всех уровнях приложения.
Вообще, если ты потрудишься прочитать отквоченное, то сможешь увидеть, что никакого противопоставления Delphi Java тут нет. А компоненты в Delphi не только для гуя.
C>>>Вообще-то, если ты не заметил, Дельфи превратился именно в .NET H>>Не надо грязи. Дельфи живет своей, отдельной от .Net жизнью G>"Живет" громко сказано, новые проекты на делфи начинают только там, где разработчики ничего другого не знают.
Здравствуйте, gandjustas, Вы писали:
H>>Собствено, в какую нишу она и позиционировалась G>В мировом масштабе ниши у делфи никогда не было. G>На территории Росии и СНГ делфи пользовалась значительной популярностью по причине того что делфи изучали во всех вузах, в отличие даже от С\С++.
И Борланд делал Delphi исключительно для CCCP/России. Еще одна газированная лужа.
Здравствуйте, gandjustas, Вы писали:
>>Sun зато вкладывает кучу денег в исследования и разработку самой JVM. Она до сих пор намного технологичнее .NET VM остаётся — в Java более умные gargage collector'ы, есть адаптивная оптимизация (технология HotSpot), и т.д. G>Но при этом Java тормознее .NET.
Почему? По тестам — обратный результат.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
VR>>>>>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). C>>>>Так ведь, действительно, компоненты были... H>>>Их и сейчас на любой вкус и цвет G>>Только в делфи компоненты гуевые, а в джаве компонентный подход есть на всех уровнях приложения.
H>Вообще, если ты потрудишься прочитать отквоченное, то сможешь увидеть, что никакого противопоставления Delphi Java тут нет.
Противопоставления нет, сравнение есть.
H>А компоненты в Delphi не только для гуя.
Ну и для чего еще?
В делфи очень сильная завязка всего на гуй, при желании её можно не использовать, то среда разработки диктует именно такой стиль.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
>>>Sun зато вкладывает кучу денег в исследования и разработку самой JVM. Она до сих пор намного технологичнее .NET VM остаётся — в Java более умные gargage collector'ы, есть адаптивная оптимизация (технология HotSpot), и т.д. G>>Но при этом Java тормознее .NET. C>Почему? По тестам — обратный результат.
По каким?
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, kuj, Вы писали:
MK>>>По мне, так C# и .Net идеологически очень схожи с Delphi. kuj>>Бугагагага... Пиши еще. MK>Вот IT в соседней ветке писал о вызове через точку
. Это можно отнести к влиянию Явы, а можно и к Делфи, где тоже только точка. Та же фигня со свойствами. Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи. Сейчас C#, конечно, далеко ушел от Делфи, но, когда я в брался за изучение еще первого .Net, не покидало ощущение эдакого о-Делфённого Си.
Сама платформа .NET строилась по образу и подобию Java, а язык C# гораздо больше похож на Delphi(чуть слабее на Java) чем на C++.
Здравствуйте, gandjustas, Вы писали:
VR>>>>>>когда-то тоже делфисты на каждому углу кричали "зато у нас есть куча компонент на все случаи жизни" (Cyberax тоже самое кричит про джава-библиотеки). C>>>>>Так ведь, действительно, компоненты были... H>>>>Их и сейчас на любой вкус и цвет G>>>Только в делфи компоненты гуевые, а в джаве компонентный подход есть на всех уровнях приложения.
H>>Вообще, если ты потрудишься прочитать отквоченное, то сможешь увидеть, что никакого противопоставления Delphi Java тут нет. G>Противопоставления нет, сравнение есть.
Где ты увидел сравнение?. Речь шла исключительно о компонентах Delphi, а точнее об их наличии в прошлом и настоящем.
H>>А компоненты в Delphi не только для гуя. G>Ну и для чего еще?
Покури относительно невизуальных компонентов.
G>В делфи очень сильная завязка всего на гуй, при желании её можно не использовать, то среда разработки диктует именно такой стиль.
Этот вопрос уже обсуждался. Среда ничего не диктует. Вакуум в голове техническими средствами не лечится.
H>>>А компоненты в Delphi не только для гуя. G>>Ну и для чего еще? H>Покури относительно невизуальных компонентов.
Ага, и они тоже кладутся в дизайнере на формочки.
G>>В делфи очень сильная завязка всего на гуй, при желании её можно не использовать, то среда разработки диктует именно такой стиль. H>Этот вопрос уже обсуждался. Среда ничего не диктует. Вакуум в голове техническими средствами не лечится.
Еще как лечится.
Особенно хорошо лечится принципиальной невозможностью сделать что-то неправильно, также отлично лечится средством Threat Warnings As Errors, а также статической проверкой кода (для которой тоже включен Threat Warnings As Errors в некоторых местах)
Здравствуйте, hattab, Вы писали:
C>>>>Вообще-то, если ты не заметил, Дельфи превратился именно в .NET H>>>Не надо грязи. Дельфи живет своей, отдельной от .Net жизнью G>>"Живет" громко сказано, новые проекты на делфи начинают только там, где разработчики ничего другого не знают. H>Газированные лужи...
А вот и нет. Именно все так и есть. Там, где разработчики другого не знают. Потому что Delphi уже нет. Есть только то, что было создано раньше и это надо поддерживать. Не берусь судить, к сожалению или к счастью, но Delphi как серьезное и перспективное средство разработки уничтожена.
G>В мировом масштабе ниши у делфи никогда не было. G>На территории Росии и СНГ делфи пользовалась значительной популярностью по причине того что делфи изучали во всех вузах, в отличие даже от С\С++.
+ Япония, Китай, Болгария ну и конечно солнечная Бразилия.
Здравствуйте, MxKazan, Вы писали:
MK>>>По мне, так C# и .Net идеологически очень схожи с Delphi. kuj>>Бугагагага... Пиши еще. MK>Вот IT в соседней ветке писал о вызове через точку
. Это можно отнести к влиянию Явы,
Это и есть влияние Явы.
MK>а можно и к Делфи, где тоже только точка. Та же фигня со свойствами.
Свойства — да, но это не делает C# "идеологически похожим на Делфи".
По твоей логике дженерики, тернарные операторы, перегрузка и т.д. делают С# "идеологически похожим на С++" — так чтоли?.
MK>Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи.
Не пиши такой чуши больше.
MK>Сейчас C#, конечно, далеко ушел от Делфи, но, когда я в брался за изучение еще первого .Net, не покидало ощущение эдакого о-Делфённого Си.
Это просто потому, что ты кроме делфи ничего больше не знал.
Здравствуйте, MxKazan, Вы писали:
G>>>ЗЫ. В википедии в статье по Cω приводится пример именно работы с коллекциями объектов. O>>Cω это шо такое? Си с яйцами? (: MK>
Cω (pronounced C omega, /Ō-mē'gɘ/ or /Ō-mĕg'ɘ/;[1] usually written as "Cw" or "Comega language") is a free extension to the C# programming language, developed by the WebData team in Microsoft SQL Server in collaboration with Microsoft Research in the UK and Redmond. It was formerly known as the codenames "X#" (X Sharp) and "Xen". It was renamed Cω after Polyphonic C#, another research language based on Join calculus, was integrated into it.
Тьфу блин... где эту кнопку омега на клавиатуре найти-то? Лазить в alt-коды чтоли постоянно...
Здравствуйте, kuj, Вы писали:
MK>>а можно и к Делфи, где тоже только точка. Та же фигня со свойствами. kuj>Свойства — да, но это не делает C# "идеологически похожим на Делфи". kuj>По твоей логике дженерики, тернарные операторы, перегрузка и т.д. делают С# "идеологически похожим на С++" — так чтоли?.
Ну хорошо, слово "идеологически" я, пожалуй, зря употребил. Скажем так, ряд концепций заимствовано из Делфи.
MK>>Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи. kuj>Не пиши такой чуши больше.
В чем же чушь?
>>>Sun зато вкладывает кучу денег в исследования и разработку самой JVM. Она до сих пор намного технологичнее .NET VM остаётся — в Java более умные gargage collector'ы, есть адаптивная оптимизация (технология HotSpot), и т.д. G>>Но при этом Java тормознее .NET. C>Почему? По тестам — обратный результат.
Да покажите тесты-то.
Особенно интересно посмотреть на тесты с активным использованием дженериков. ;>
Здравствуйте, kuj, Вы писали:
G>>>>ЗЫ. В википедии в статье по Cω приводится пример именно работы с коллекциями объектов. O>>>Cω это шо такое? Си с яйцами? (: kuj>Тьфу блин... где эту кнопку омега на клавиатуре найти-то? Лазить в alt-коды чтоли постоянно...
Копи-паст рулит
Здравствуйте, gandjustas, Вы писали:
MK>>>>По мне, так C# и .Net идеологически очень схожи с Delphi. kuj>>>Бугагагага... Пиши еще. MK>>Вот IT в соседней ветке писал о вызове через точку
. Это можно отнести к влиянию Явы, а можно и к Делфи, где тоже только точка. Та же фигня со свойствами. Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи. Сейчас C#, конечно, далеко ушел от Делфи, но, когда я в брался за изучение еще первого .Net, не покидало ощущение эдакого о-Делфённого Си. G>Сама платформа .NET строилась по образу и подобию Java, а язык C# гораздо больше похож на Delphi(чуть слабее на Java) чем на C++. Нда... От тебя такого бреда не ожидал.
Здравствуйте, MxKazan, Вы писали:
MK>>>а можно и к Делфи, где тоже только точка. Та же фигня со свойствами. kuj>>Свойства — да, но это не делает C# "идеологически похожим на Делфи". kuj>>По твоей логике дженерики, тернарные операторы, перегрузка и т.д. делают С# "идеологически похожим на С++" — так чтоли?. MK>Ну хорошо, слово "идеологически" я, пожалуй, зря употребил. Скажем так, ряд концепций заимствовано из Делфи.
Ну ясное дело заимствовано. Особенно, если учесть, что архитектор один.
MK>>>Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи. kuj>>Не пиши такой чуши больше. MK>В чем же чушь?
Открой дфм и посмотри сам.
Здравствуйте, criosray, Вы писали:
M>>Решарпер действительно бесподобен, но и вы слишком категоричны, вот напрмиер по своему опыту python+eclipse: C>Вы невнимательно читали ветку. Речь шла о том, что мол на пайтоне можно писать код так же быстро, как на C#, но без использования специальных сред разработки.
а "писать на C#" можно только со средствами разработки?.
Здравствуйте, kuj, Вы писали:
MK>>>>Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи. kuj>>>Не пиши такой чуши больше. MK>>В чем же чушь? kuj>Открой дфм и посмотри сам.
А чего его смотреть. Суть та же самая сериализация свойств.
Здравствуйте, MxKazan, Вы писали:
MK>>>>>Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи. kuj>>>>Не пиши такой чуши больше. MK>>>В чем же чушь? kuj>>Открой дфм и посмотри сам. MK>А чего его смотреть. Суть та же самая сериализация свойств.
Какая нафиг сериализация свойств? Открой InitializeComponents и посмотри внимательно что там. И больше такой чуши не пиши.
Здравствуйте, gandjustas, Вы писали:
H>>>>А компоненты в Delphi не только для гуя. G>>>Ну и для чего еще? H>>Покури относительно невизуальных компонентов. G>Ага, и они тоже кладутся в дизайнере на формочки.
Можно и на формочки, а можно и ручками. В чем проблема то? Типа для шарпа в VS не так
G>>>В делфи очень сильная завязка всего на гуй, при желании её можно не использовать, то среда разработки диктует именно такой стиль. H>>Этот вопрос уже обсуждался. Среда ничего не диктует. Вакуум в голове техническими средствами не лечится. G>Еще как лечится. G>Особенно хорошо лечится принципиальной невозможностью сделать что-то неправильно, также отлично лечится средством Threat Warnings As Errors, а также статической проверкой кода (для которой тоже включен Threat Warnings As Errors в некоторых местах)
Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее?
Здравствуйте, MxKazan, Вы писали:
G>>>"Живет" громко сказано, новые проекты на делфи начинают только там, где разработчики ничего другого не знают. H>>Газированные лужи... MK>А вот и нет. Именно все так и есть. Там, где разработчики другого не знают. Потому что Delphi уже нет. Есть только то, что было создано раньше и это надо поддерживать. Не берусь судить, к сожалению или к счастью, но Delphi как серьезное и перспективное средство разработки уничтожена.
Здравствуйте, kuj, Вы писали:
MK>>А чего его смотреть. Суть та же самая сериализация свойств. kuj>Какая нафиг сериализация свойств? Открой InitializeComponents и посмотри внимательно что там. И больше такой чуши не пиши.
Там тоже самое только оформленное другим образом. Идея абсолютно такая же: при помощи дизайнера форм генерируется некоторый файл, позволяющий при создании окна повторить дизайн в рантайме.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>>>А компоненты в Delphi не только для гуя. G>>>>Ну и для чего еще? H>>>Покури относительно невизуальных компонентов. G>>Ага, и они тоже кладутся в дизайнере на формочки.
H>Можно и на формочки, а можно и ручками. В чем проблема то? Типа для шарпа в VS не так
Не так
При всем желании SQLConnection на формочку не положишь.
Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен.
Даже костыль для этого дела придумали, DataModule вроде зовется.
G>>>>В делфи очень сильная завязка всего на гуй, при желании её можно не использовать, то среда разработки диктует именно такой стиль. H>>>Этот вопрос уже обсуждался. Среда ничего не диктует. Вакуум в голове техническими средствами не лечится. G>>Еще как лечится. G>>Особенно хорошо лечится принципиальной невозможностью сделать что-то неправильно, также отлично лечится средством Threat Warnings As Errors, а также статической проверкой кода (для которой тоже включен Threat Warnings As Errors в некоторых местах)
H>Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее?
Ну это и ежу понятно.
Другое дело что сама IDE в делфи подталкивает такие ошибки совершать.
Здравствуйте, MxKazan, Вы писали:
MK>>>А чего его смотреть. Суть та же самая сериализация свойств. kuj>>Какая нафиг сериализация свойств? Открой InitializeComponents и посмотри внимательно что там. И больше такой чуши не пиши. MK>Там тоже самое только оформленное другим образом. Идея абсолютно такая же: при помощи дизайнера форм генерируется некоторый файл, позволяющий при создании окна повторить дизайн в рантайме.
Да нифига оно не тоже самое. Ты можешь перенести содержимое InitializeComponents непосредственно туда, где она вызывалась и форма будет работать, как работала. Никакой ровным счетом аналогии с делфи здесь нет и никогда не было.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, gandjustas, Вы писали:
MK>>>>>По мне, так C# и .Net идеологически очень схожи с Delphi. kuj>>>>Бугагагага... Пиши еще. MK>>>Вот IT в соседней ветке писал о вызове через точку
. Это можно отнести к влиянию Явы, а можно и к Делфи, где тоже только точка. Та же фигня со свойствами. Возьми WinForms — генерация кода в InitializeComponent практически тоже самое, что DFM в Делфи. Сейчас C#, конечно, далеко ушел от Делфи, но, когда я в брался за изучение еще первого .Net, не покидало ощущение эдакого о-Делфённого Си. G>>Сама платформа .NET строилась по образу и подобию Java, а язык C# гораздо больше похож на Delphi(чуть слабее на Java) чем на C++. kuj> Нда... От тебя такого бреда не ожидал.
Ну если сравнить C# с C++ и делфи по языковым фичам, то окажется что от делфи там гораздо больше. За исполючением C-подобного синтаксиса.
Здравствуйте, kuj, Вы писали:
kuj>Да нифига оно не тоже самое. Ты можешь перенести содержимое InitializeComponents непосредственно туда, где она вызывалась и форма будет работать, как работала. Никакой ровным счетом аналогии с делфи здесь нет и никогда не было.
То что InitializeComponents можно куда-то прокопировать, ровным счетом ничего не значит. Это лишь как бонус от кодо-генерации. Да и сомнительный, ведь если я решу чего поменять, снова надо копировать. А в какой ужас превращается наследование форм, я вообще молчу. В Делфи с этим получше было. Да и DFM тоже можно программно считать при желании.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, mogadanez, Вы писали:
C>>>Вы вообще видели VS 2k8 + Resharper 4.1 связку? Явно не видели...
M>>Решарпер действительно бесподобен, но и вы слишком категоричны, вот напрмиер по своему опыту python+eclipse:
C>Вы невнимательно читали ветку. Речь шла о том, что мол на пайтоне можно писать код так же быстро, как на C#, но без использования специальных сред разработки.
честно говоря мне все равно кто начал на кого наезжать, но смысла сравнивать с одной стороны максимально навороченый комплект, а с другой стороны минималистический особо не вижу.
Здравствуйте, MxKazan, Вы писали:
kuj>>Да нифига оно не тоже самое. Ты можешь перенести содержимое InitializeComponents непосредственно туда, где она вызывалась и форма будет работать, как работала. Никакой ровным счетом аналогии с делфи здесь нет и никогда не было. MK>То что InitializeComponents можно куда-то прокопировать, ровным счетом ничего не значит. Это лишь как бонус от кодо-генерации.
Мда...
MK>Да и сомнительный, ведь если я решу чего поменять, снова надо копировать. А в какой ужас превращается наследование форм, я вообще молчу. В Делфи с этим получше было. Да и DFM тоже можно программно считать при желании.
Ну и какой же в дотнет ужас с наследованием форм? Поведай-ка. А еще расскажи, как в Делфи сделать форму, реализующую ряд интерфейсов, как эту форму можно зарегистрировать в IoC-контейнере с Lifecycle=Pool, то бишь пул на N форм. Внимательно слушаю.
Q>Мозг «плюсистов» заполнен стереотипами типа «тормозит», «быдлокодеры», «Империя Зла», «у вас негров линчуют» и прочим булшитом... Q>...«Плюсисты» делают свой «выбор» на основе всяких «общих рассуждений», подогнанных под удобную точку зрения. (Чёрт, не могу найти тот демотиватор, в тему иллюстрирующий «плюсистов».)
Q>P.S. Повторю, что под «плюсистами» и «шарперами» я понимаю не вообще программистов на C++ и C#, это просто условное обозначение противоборствующих сторон (диалектика, фигли) последних веток КСВ.
Здравствуйте, kuj, Вы писали:
G>>>Но при этом Java тормознее .NET. C>>Почему? По тестам — обратный результат. kuj>Да покажите тесты-то.
К примеру: http://www.shudo.net/jit/perf/
kuj>Особенно интересно посмотреть на тесты с активным использованием дженериков. ;>
Если не использовать примитивные контейнеры — разницы в скорости особой нет.
Здравствуйте, gandjustas, Вы писали:
H>>Можно и на формочки, а можно и ручками. В чем проблема то? Типа для шарпа в VS не так G>Не так G>При всем желании SQLConnection на формочку не положишь.
Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт.
G>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен.
Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой.
G>Даже костыль для этого дела придумали, DataModule вроде зовется.
Это как раз один из способов выделения бизнес-логики.
H>>Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее? G>Ну это и ежу понятно. G>Другое дело что сама IDE в делфи подталкивает такие ошибки совершать.
Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kuj, Вы писали:
G>>>>Но при этом Java тормознее .NET. C>>>Почему? По тестам — обратный результат. kuj>>Да покажите тесты-то. C>К примеру: http://www.shudo.net/jit/perf/
Во-первых где код?
Большенство тестов, которые показывают что кто-то там быстрее написаны с использованием техник оптимизации на одном языке и без них на другом.
Во-вторых так .NET версии 1.1.
С тех пор он побыстрее стал.
В-третьих там в основном математика, для которой гораздо лучше написать один раз неуправляемый код на C.
Здравствуйте, Cyberax, Вы писали:
G>>>>Но при этом Java тормознее .NET. C>>>Почему? По тестам — обратный результат. kuj>>Да покажите тесты-то. C>К примеру: http://www.shudo.net/jit/perf/
Зашибись. Еще более древнего найти не мог?
kuj>>Особенно интересно посмотреть на тесты с активным использованием дженериков. ;> C>Если не использовать примитивные контейнеры — разницы в скорости особой нет.
Ну я не знаю я не сравнивал. Но дженерики в основном как-раз во всяких контейнерах и используются.
Здравствуйте, hattab, Вы писали:
H>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт.
G>>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен.
H>Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой.
Зашибись. А если у объекта два разных владельца?
G>>Даже костыль для этого дела придумали, DataModule вроде зовется.
H>Это как раз один из способов выделения бизнес-логики.
Это один из примеров почему делфи самое место в том месте, где она сейчас находится — в топке.
H>>>Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее? G>>Ну это и ежу понятно. G>>Другое дело что сама IDE в делфи подталкивает такие ошибки совершать.
H>Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая.
Ну ка, ну ка, покажи нам вменяемую реализацию MVC или MVP под делфи. Слабо? ;]
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Можно и на формочки, а можно и ручками. В чем проблема то? Типа для шарпа в VS не так G>>Не так G>>При всем желании SQLConnection на формочку не положишь. H>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт.
Ути какой шустрый.
В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии.
То есть TComponent в делфи нужен для гуя.
G>>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен. H>Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой.
Бред говоришь.
Я IoC-контейнер использую и сам задаю время жизни нелокальных объектов независимо от того где они используются.
G>>Даже костыль для этого дела придумали, DataModule вроде зовется. H>Это как раз один из способов выделения бизнес-логики.
Это костыль для формоклепателей, да еще и нарушающий инкапсуляцию ведь все компоненты — public.
Почему нельзя обычный класс написать?
H>>>Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее? G>>Ну это и ежу понятно. G>>Другое дело что сама IDE в делфи подталкивает такие ошибки совершать. H>Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая.
Чтобы развеять свое убеждение посмотри на ASP.NET MVC.
Здравствуйте, gandjustas, Вы писали:
H>>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт. G>Ути какой шустрый. G>В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии. G>То есть TComponent в делфи нужен для гуя.
TComponent нужен для поддержки дизайн-тайма. Учи матчасть.
G>>>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен. H>>Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой. G>Бред говоришь. G>Я IoC-контейнер использую и сам задаю время жизни нелокальных объектов независимо от того где они используются.
Еще раз подумай над тем, что я написал.
G>>>Даже костыль для этого дела придумали, DataModule вроде зовется. H>>Это как раз один из способов выделения бизнес-логики. G>Это костыль для формоклепателей, да еще и нарушающий инкапсуляцию ведь все компоненты — public. G>Почему нельзя обычный класс написать?
Кто тебе сказал, что нельзя?
H>>>>Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее? G>>>Ну это и ежу понятно. G>>>Другое дело что сама IDE в делфи подталкивает такие ошибки совершать. H>>Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая. G>Чтобы развеять свое убеждение посмотри на ASP.NET MVC.
Я жутко не люблю повторяться, но приходится... (... от которых ничего не спасет)
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт. G>>Ути какой шустрый. G>>В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии. G>>То есть TComponent в делфи нужен для гуя. H>TComponent нужен для поддержки дизайн-тайма. Учи матчасть.
Да ну, и какие же члены TComponent нужны для дизайн-тайма? И для чего нужны остальные члены?
G>>>>Даже костыль для этого дела придумали, DataModule вроде зовется. H>>>Это как раз один из способов выделения бизнес-логики. G>>Это костыль для формоклепателей, да еще и нарушающий инкапсуляцию ведь все компоненты — public. G>>Почему нельзя обычный класс написать? H>Кто тебе сказал, что нельзя?
Ну если такой костыль придумали — значит нельзя было.
Здравствуйте, gandjustas, Вы писали:
H>>>>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт. G>>>Ути какой шустрый. G>>>В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии. G>>>То есть TComponent в делфи нужен для гуя. H>>TComponent нужен для поддержки дизайн-тайма. Учи матчасть. G>Да ну, и какие же члены TComponent нужны для дизайн-тайма? И для чего нужны остальные члены?
RTTI он получает наследуясь от TPersistent. Весь остальной функционал направлен на реализацию компонентной модели, которую собственно дизайнер и использует.
G>>>Почему нельзя обычный класс написать? H>>Кто тебе сказал, что нельзя? G>Ну если такой костыль придумали — значит нельзя было.
Здравствуйте, hattab, Вы писали:
G>>>>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен. H>>>Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой. G>>Бред говоришь. G>>Я IoC-контейнер использую и сам задаю время жизни нелокальных объектов независимо от того где они используются.
H>Еще раз подумай над тем, что я написал.
Не надо проецировать проблемы гомносреды программирования (делфи) на нормальные. В дотнет компоненты это обычные классы и как всякий обычный экземпляр обычного класса вовсе не обязан иметь владельца.
H>>>Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая. G>>Чтобы развеять свое убеждение посмотри на ASP.NET MVC.
H>Я жутко не люблю повторяться, но приходится... (... от которых ничего не спасет)
Иди лучше RTFMь про нормальные фреймворки вместо того, чтоб восхвалять тут мертвечину.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>>>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт. G>>>>Ути какой шустрый. G>>>>В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии. G>>>>То есть TComponent в делфи нужен для гуя. H>>>TComponent нужен для поддержки дизайн-тайма. Учи матчасть. G>>Да ну, и какие же члены TComponent нужны для дизайн-тайма? И для чего нужны остальные члены?
H>RTTI он получает наследуясь от TPersistent. Весь остальной функционал направлен на реализацию компонентной модели, которую собственно дизайнер и использует.
То есть пришли к тому с чего начали: вся компонентая модель делфи направлена на гуй (кидание компонентов на формочку).
Здравствуйте, gandjustas, Вы писали:
H>>>>TComponent нужен для поддержки дизайн-тайма. Учи матчасть. G>>>Да ну, и какие же члены TComponent нужны для дизайн-тайма? И для чего нужны остальные члены?
H>>RTTI он получает наследуясь от TPersistent. Весь остальной функционал направлен на реализацию компонентной модели, которую собственно дизайнер и использует. G>То есть пришли к тому с чего начали: вся компонентая модель делфи направлена на гуй (кидание компонентов на формочку).
Ты под гуем дизайн-тайм подразумеваешь, что ли? Если так, тогда все верно: компонентая модель служит для "создания компонентов через гуй".
Здравствуйте, Cyberax, Вы писали:
D>>Гы! Сериализация сериализации рознь. XML-сериализация в том же .NET существует с незапамятных времён. Однако к XAML'у это не имеет никакого отношения. C>Да я знаю. Просто я имею в виду, что есть именно аналоги XAML, а не просто дампы деревьев объектов.
Ну так что это за аналоги-то ? Я вот лично таких не знаю. Есть вещи в которых присутствуют разные отдельные куски идей стоящих за XAML, но чтобы всё это было грамотно сведено в одном месте — такого не припоминаю.
D>>Модель всегда отделена от её визуального представления, как минимум на логическом уровне. На то она и модель собственно.
C>Она не отделена в WinForms и других подобных фреймворках. Скажем, в WinForms текстовое поле просто содержит строку, которую ты берёшь как "ctrl.Text".
И в Swing'е всё ровно также: getText() и телемаркет.
C>Для сравнения, в Swing'е для JTextField для хранения и редактирования текста используется модель документа — http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/Document.html , который ты можешь реализовать поверх чего угодно.
Так это не та модель. Это модель элемента UI. А точнее её часть, бо его остальные ~100 свойств в неё почему-то не входят. И зачем оно нужно ???
C>Аналогично и в WPF — только там для этого используется обобщённый DependencyObject.
Так вот ничего аналогичного. В WPF для связывания с моделями данных приложения доступны все свойства соответствующих элементов UI, причём связывание включает поддержку выражений, и можно "бродить" как по модели, так и по дереву UI. И при всей этой мощи, в 90% случаев сия связь задаётся всего одной строкой в XAML-представлении. И "реализовывать поверх чего угодно" ничего не нужно.
D>>И задача состоит не в отделении, бо оно аксиома, а в обеспечении мощных и в то же время выразительных, простых и удобных механизмов связи модели с её конкретной визуализацией. Их и предоставляет WPF — binding'и для dependency property. Подобных вещей в Swing'е просто не существует.
C>В Swing'е это реализуется с помощью виртуальных моделей.
У jgoodies-binding с binding'ом WPF общее только одно — слово "binding".
C>В WPF оно всё сделано более обобщённо и красиво, но суть та же самая осталась.
Приехали. В WinForms вон тоже есть binding, и даже в WebForms есть. Суть та же, говно только...
C>>>отход от оконной модели интерфейса. D>>М-м-м... А где это в Swing'е-то можно увидеть ??? C>Что именно?
"Отход от оконной модели интерфейса". В Ваших постингах я его так и не вижу.
C>В Swing'е рисованием компонентов занимается look&feel, который отделён от самого контрола и может меняться (в том числе в runtime'е).
Ну занимается. Ну может меняться. Да, жизнь разработчиков Swing Team из Sun, видимо, облегчилась. Может ещё каким героям скиноваяния тоже стало чуть веселее. А вот мне, как обычному разработчику, совершенно по-барабану. Бо подход к рендерингу UI при этом совершенно не изменился. И написать свой look&feel к Swing'у, даже для пары control'ов, это куча работы. Тогда как заскинить control в WPF не представляет никаких затруднений. Более того, для этого в большинстве случаев я даже практически не нужен. Всё может сделать и непосредственно дизайнер.
C>В JavaFX оно ещё больше отделено — есть явная концепция scene graph'а, на котором можно запускать анимации.
Гы! Так JavaFX и появился после того, как в Sun увидели WPF. Однако до WPF ему пока ещё очень далеко, в том числе и концептуально. И это понимают, бо штучка позиционируется прежде всего в роли новой UI-платформы для J2ME.
D>>Чушь. С инкапсуляцией здесь всё в порядке. Мы просто тип расширяем. Можете смотреть на этот момент как на облегчённую форму наследования, например. C>Лучше явно выделять такие сервисы в сервисные классы.
Они и так выделены. Extension-методы есть методы статических классов. Если Вас напрягает instance-ный синтаксис вызова, то Вы можете вызывать их и обычным образом.
Здравствуйте, drol, Вы писали:
C>>Да я знаю. Просто я имею в виду, что есть именно аналоги XAML, а не просто дампы деревьев объектов. D>Ну так что это за аналоги-то ? Я вот лично таких не знаю. Есть вещи в которых присутствуют разные отдельные куски идей стоящих за XAML, но чтобы всё это было грамотно сведено в одном месте — такого не припоминаю.
Их много разных: http://java-source.net/open-source/xml-user-interface-toolkits — есть и с возможностью байндинга отдельных свойств.
C>>Она не отделена в WinForms и других подобных фреймворках. Скажем, в WinForms текстовое поле просто содержит строку, которую ты берёшь как "ctrl.Text". D>И в Swing'е всё ровно также: getText() и телемаркет.
Это не более чем удобный аксессор.
C>>Для сравнения, в Swing'е для JTextField для хранения и редактирования текста используется модель документа — http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/Document.html , который ты можешь реализовать поверх чего угодно. D>Так это не та модель. Это модель элемента UI. А точнее её часть, бо его остальные ~100 свойств в неё почему-то не входят. И зачем оно нужно ???
За большую часть остальных свойств отвечает:
1) Система layout'ов, внешняя по отношению к контролу.
2) Look&Feel.
D>Так вот ничего аналогичного. В WPF для связывания с моделями данных приложения доступны все свойства соответствующих элементов UI, причём связывание включает поддержку выражений, и можно "бродить" как по модели, так и по дереву UI. И при всей этой мощи, в 90% случаев сия связь задаётся всего одной строкой в XAML-представлении. И "реализовывать поверх чего угодно" ничего не нужно.
Это всё есть в SWING'е, даже брожение по дереву контролов с помощью декларативного языка — http://www.opensymphony.com/ognl/html/LanguageGuide/introduction.html или http://commons.apache.org/jxpath//users-guide.html#Nested_Bean_Property_Access
D>Ну занимается. Ну может меняться. Да, жизнь разработчиков Swing Team из Sun, видимо, облегчилась. Может ещё каким героям скиноваяния тоже стало чуть веселее. А вот мне, как обычному разработчику, совершенно по-барабану. Бо подход к рендерингу UI при этом совершенно не изменился. И написать свой look&feel к Swing'у, даже для пары control'ов, это куча работы. Тогда как заскинить control в WPF не представляет никаких затруднений. Более того, для этого в большинстве случаев я даже практически не нужен. Всё может сделать и непосредственно дизайнер.
Специально для тебя сделали skinnable L&F'ы...
C>>В JavaFX оно ещё больше отделено — есть явная концепция scene graph'а, на котором можно запускать анимации. D>Гы! Так JavaFX и появился после того, как в Sun увидели WPF. Однако до WPF ему пока ещё очень далеко, в том числе и концептуально. И это понимают, бо штучка позиционируется прежде всего в роли новой UI-платформы для J2ME.
JavaFX они варили достаточно долго, аж с 2004-го года. Оно больше как конкурент Silverlight/Flash.
C>>Лучше явно выделять такие сервисы в сервисные классы. D>Они и так выделены. Extension-методы есть методы статических классов. Если Вас напрягает instance-ный синтаксис вызова, то Вы можете вызывать их и обычным образом.
Если вызывать обычным способом — то они и не нужны.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, March_rabbit, Вы писали:
CC>>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>>В чем непреодолимая трудность то? M_>>гм.... а ничего, в линуксе это такая работа "маленький инсталлятор для дистра + закачка из инета остального" считается нормой? CC>Мне всё равно что там в линухе. CC>Я спрашиваю конкретно под винду: что именно мешает создать отдельные маленькие .NET Runtime дистрибутивы?
я не микрософт, но предположу: никому не надо. Лишняя работа программистов, тестеров и еще кучи людей.
Здравствуйте, MxKazan, Вы писали:
O>>>>Cω это шо такое? Си с яйцами? (: kuj>>Тьфу блин... где эту кнопку омега на клавиатуре найти-то? Лазить в alt-коды чтоли постоянно... MK>Копи-паст рулит
Здравствуйте, KipDblK, Вы писали:
O>>>>>Cω это шо такое? Си с яйцами? (: kuj>>>Тьфу блин... где эту кнопку омега на клавиатуре найти-то? Лазить в alt-коды чтоли постоянно... MK>>Копи-паст рулит
KDK>Это суть технологии?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Только вот нужен был LDAP для специального сервера, который должен работать параллельно с AD, предоставляя некоторую очень специфическую функциональность. G>>Для этого можно и реляционную базу прикрутить. C>Нельзя. Можно было бы — прикрутил.
Расскажи это ребятам из Quest Software (кстати привет бывшим коллегам, если они тут есть , команде разработчиков MS Exchange — это только те, кого сходу вспомнил. Так что не стоит недостаток собственных знаний выдавать за недостаток технологии...
Здравствуйте, koandrew, Вы писали:
C>>Нельзя. Можно было бы — прикрутил. K>Расскажи это ребятам из Quest Software (кстати привет бывшим коллегам, если они тут есть , команде разработчиков MS Exchange — это только те, кого сходу вспомнил. Так что не стоит недостаток собственных знаний выдавать за недостаток технологии...
Ещё раз медленно: у меня НЕ стояла задача как-то хранить данные. Стояла задача как-то сделать LDAP-интерфейс для сторонней системы. Как его сделать — было не особо важно. Хоть на DBF-файлах и bash-скриптах.
Здравствуйте, Cyberax, Вы писали:
C>Ещё раз медленно: у меня НЕ стояла задача как-то хранить данные. Стояла задача как-то сделать LDAP-интерфейс для сторонней системы. Как его сделать — было не особо важно. Хоть на DBF-файлах и bash-скриптах.
Ещё раз медленно: ставишь AD, расширяешь его схему как тебе нужно — и дело в шляпе. Что тут непонятного?
Здравствуйте, koandrew, Вы писали:
C>>Ещё раз медленно: у меня НЕ стояла задача как-то хранить данные. Стояла задача как-то сделать LDAP-интерфейс для сторонней системы. Как его сделать — было не особо важно. Хоть на DBF-файлах и bash-скриптах. K>Ещё раз медленно: ставишь AD, расширяешь его схему как тебе нужно — и дело в шляпе. Что тут непонятного?
Нельзя было использовать AD (я же написал, что оно должно было работать параллельно с AD). Ты думаешь, мы такие тупые, что не догадались бы воткнуть схему в AD и наслаждаться жизнью?
Здравствуйте, Cyberax, Вы писали:
D>>Ну так что это за аналоги-то ? Я вот лично таких не знаю. Есть вещи в которых присутствуют разные отдельные куски идей стоящих за XAML, но чтобы всё это было грамотно сведено в одном месте — такого не припоминаю. C>Их много разных: http://java-source.net/open-source/xml-user-interface-toolkits — есть и с возможностью байндинга отдельных свойств.
Мне не нужны "много разных" наколенных студенческих поделок. Покажите аналог XAML, то бишь нормальную production quality библиотеку сериализации поддерживающую все концепции XAML. Достаточно "одной штуки".
C>>>Она не отделена в WinForms и других подобных фреймворках. Скажем, в WinForms текстовое поле просто содержит строку, которую ты берёшь как "ctrl.Text". D>>И в Swing'е всё ровно также: getText() и телемаркет. C>Это не более чем удобный аксессор.
Отличный комментарий! "Удобный"
D>>Так это не та модель. Это модель элемента UI. А точнее её часть, бо его остальные ~100 свойств в неё почему-то не входят. И зачем оно нужно ??? C>За большую часть остальных свойств отвечает: C>1) Система layout'ов, внешняя по отношению к контролу. C>2) Look&Feel.
Ещё раз повторяю: мне не нужны "много разных" expression engine'ов. Мне нужен binding модели данных приложения к элементам UI Swing'а, с поддержкой выражений, и корректно интегрированный.
D>>Ну занимается. Ну может меняться. Да, жизнь разработчиков Swing Team из Sun, видимо, облегчилась. Может ещё каким героям скиноваяния тоже стало чуть веселее. А вот мне, как обычному разработчику, совершенно по-барабану. Бо подход к рендерингу UI при этом совершенно не изменился. И написать свой look&feel к Swing'у, даже для пары control'ов, это куча работы. Тогда как заскинить control в WPF не представляет никаких затруднений. Более того, для этого в большинстве случаев я даже практически не нужен. Всё может сделать и непосредственно дизайнер.
C>Специально для тебя сделали skinnable L&F'ы...
О да-а-а!!! Synth и его border'ы на картинках. Мегатехнология каменного века. И Вы эту ерунду пытаетесь выдать за WPF power ??? Или Вы о каком-то другом "представителе семейства" ???
C>JavaFX они варили достаточно долго, аж с 2004-го года.
Про то и говорю. WPF начали показывать ещё в 2003.
C>Оно больше как конкурент Silverlight/Flash.
Дык одно другому не мешает. Конкуренты Silverlight/Flash на J2ME-платформах. Desktop'ы там пока что только ради расширяемости и "униформности".
C>>>Лучше явно выделять такие сервисы в сервисные классы. D>>Они и так выделены. Extension-методы есть методы статических классов. Если Вас напрягает instance-ный синтаксис вызова, то Вы можете вызывать их и обычным образом. C>Если вызывать обычным способом — то они и не нужны.
Неправда. Это позволяет без проблем пользоваться библиотечными extension-методами не только нормальным людям, понимающим зачем они нужны, но и всяким пуристам от ООП вроде Вас
Здравствуйте, Cyberax, Вы писали:
C>Нельзя было использовать AD (я же написал, что оно должно было работать параллельно с AD). Ты думаешь, мы такие тупые, что не догадались бы воткнуть схему в AD и наслаждаться жизнью?
Тогда я не понимаю значение слова "параллельно" — если в смысле "одновременно с", то расширение схемы — то, что доктор прописал. Не опишешь поподробнее? (не флейма ради — мне просто интересно, плюс потенциально полезно)
Здравствуйте, drol, Вы писали:
C>>Их много разных: http://java-source.net/open-source/xml-user-interface-toolkits — есть и с возможностью байндинга отдельных свойств. D>Мне не нужны "много разных" наколенных студенческих поделок. Покажите аналог XAML, то бишь нормальную production quality библиотеку сериализации поддерживающую все концепции XAML. Достаточно "одной штуки". http://xul.sourceforge.net/counter.html — там немного другие концепции, такой же ТОЧНО — нет.
C>>Это не более чем удобный аксессор. D>Отличный комментарий! "Удобный"
Ну да. Не писать же каждый раз:
(именно так getText() и реализован).
C>>2) Look&Feel. D>А мне-то (как пользователю Swing'а) какое до этого дело ??? Для визуализации модели данных приложения используется весь спектр свойств элементов UI — цвета, размеры, положение, шрифты и т.д. Так вот ещё раз повторяю вопрос. Зачем часть (очень малая) свойств элементов UI "отпилена" в отдельную иерархию интерфейсов ???
Выделена отдельная часть, связанная с выдачей данных. Всё что связано с общим стилем контрола — управляется внешними системами. Нормальное разделение, на самом деле.
C>>Это всё есть в SWING'е, даже брожение по дереву контролов с помощью декларативного языка — http://www.opensymphony.com/ognl/html/LanguageGuide/introduction.html или http://commons.apache.org/jxpath//users-guide.html#Nested_Bean_Property_Access D>Неправда. Ни OGNL, ни JXPath в Swing'е нет.
Они отдельно есть
D>Ещё раз повторяю: мне не нужны "много разных" expression engine'ов. Мне нужен binding модели данных приложения к элементам UI Swing'а, с поддержкой выражений, и корректно интегрированный.
Вот час назад только написал: "context.setValue("root_panel//checkbox[@weekday='tuesday']",true);"
В смысле — делается binding при желании. Готового полностью юзабельного нет, но для самоделок полно решений.
C>>Специально для тебя сделали skinnable L&F'ы... D>О да-а-а!!! Synth и его border'ы на картинках. Мегатехнология каменного века. И Вы эту ерунду пытаетесь выдать за WPF power ??? Или Вы о каком-то другом "представителе семейства" ???
А что такое Synth? Я больше про http://www.l2fprod.com/skinlf/converter/index.php
C>>Оно больше как конкурент Silverlight/Flash. D>Дык одно другому не мешает. Конкуренты Silverlight/Flash на J2ME-платформах. Desktop'ы там пока что только ради расширяемости и "униформности".
Они сейчас заняты тем, что все платформы стараются унифицировать.
Здравствуйте, koandrew, Вы писали:
C>>Нельзя было использовать AD (я же написал, что оно должно было работать параллельно с AD). Ты думаешь, мы такие тупые, что не догадались бы воткнуть схему в AD и наслаждаться жизнью? K>Тогда я не понимаю значение слова "параллельно" — если в смысле "одновременно с", то расширение схемы — то, что доктор прописал. Не опишешь поподробнее? (не флейма ради — мне просто интересно, плюс потенциально полезно)
Оно должно работать на прикладных компьютерах как "прокси" для AD, добавляя лишнее дерево в его лес (либо вообще автономно, если AD не используется).
Здравствуйте, Cyberax, Вы писали:
D>>Отличный комментарий! "Удобный" :)) C>Ну да. Не писать же каждый раз:
... C>(именно так getText() и реализован).
Конечно не писать. Мне в WPF вообще почти никогда не приходится писать m_someGuiControl.Text. Более того, я даже имён контролам не даю, потому что из кода к ним не обращаюсь. В своём коде я использую ViewModel.MyPropertyWithMeaningfulName, а его значение устанавливается байндингом, который декларативно описывается в XAML'е.
Ещё раз, во фреймворке с богатыми средствами байндинга тебе никогда не придётся делать вызов типа someTextBox.getText(), тебе даже не обязательно знать имя того или иного контрола, один раз указал привязку и забыл.
C>>>Это не более чем удобный аксессор.
Самый удобный аксессор это тот, который тебе не приходится вызывать.
Здравствуйте, Cyberax, Вы писали:
C>Оно должно работать на прикладных компьютерах как "прокси" для AD, добавляя лишнее дерево в его лес (либо вообще автономно, если AD не используется).
Ну так это можно (и ИМХО нужно) было сделать с помощью ADSI-экстеншена, который нужно будет проинсталлить на целевые машины. Или я опять чего-то не знаю/не понимаю? Можете пояснить на примере? Как я понимаю задачу:
есть дерево
Здравствуйте, koandrew, Вы писали:
C>>Оно должно работать на прикладных компьютерах как "прокси" для AD, добавляя лишнее дерево в его лес (либо вообще автономно, если AD не используется). K>Ну так это можно (и ИМХО нужно) было сделать с помощью ADSI-экстеншена, который нужно будет проинсталлить на целевые машины. Или я опять чего-то не знаю/не понимаю? Можете пояснить на примере? Как я понимаю задачу:
Оно должно работать и без AD вообще.
K>есть дерево
Вам нужно заставить клиентов думать, что есть ещё dc=virtualdomain,dc=forest, dc=com. Так чтоли?
Вообще отдельное дерево (с предопределённым именем) типа "ou=somename, dc=blah".
Здравствуйте, Qbit86, Вы писали:
C>>(именно так getText() и реализован). Q>Конечно не писать. Мне в WPF вообще почти никогда не приходится писать m_someGuiControl.Text. Более того, я даже имён контролам не даю, потому что из кода к ним не обращаюсь. В своём коде я использую ViewModel.MyPropertyWithMeaningfulName, а его значение устанавливается байндингом, который декларативно описывается в XAML'е.
А байндинг данные откуда берёт? Из свойства с именем "MyPropertyName"?
Q>Ещё раз, во фреймворке с богатыми средствами байндинга тебе никогда не придётся делать вызов типа someTextBox.getText(), тебе даже не обязательно знать имя того или иного контрола, один раз указал привязку и забыл.
Ну это сказки даже в WPF, особенно если нужно делать хитрую логику.
PS: конкретно для байндинга я себе собираюсь прикрутить систему линз из Augeas'а (переписанную и адаптированую). Всякие WPFы будут лежать в глубоком осадке.
Здравствуйте, Cyberax, Вы писали:
Q>>Ещё раз, во фреймворке с богатыми средствами байндинга тебе никогда не придётся делать вызов типа someTextBox.getText(), тебе даже не обязательно знать имя того или иного контрола, один раз указал привязку и забыл. C>Ну это сказки даже в WPF, особенно если нужно делать хитрую логику.
0_o Да что ты говоришь! Эта сказка называется «паттерн MVVM», смотри, например, презентацию (100 Мб) Джейсона Долинджера, особенно обрати внимание на окрестности момента времени 00:21:44:
You are on the right track when you almost NEVER have a need to name a control with x:Name.
Ну что, объясни мне, что заставляет тебя раз за разом упрямо демонстрировать свою недалёкость, кичиться некомпетентностью в вопросах, в которых ни черта не смыслишь?
C>Ну это сказки даже в WPF, особенно если нужно делать хитрую логику.
Хитрая логика работает с моделью вида, а не с гуёвыми контролами.
C>А байндинг данные откуда берёт? Из свойства с именем "MyPropertyName"?
При создании байндинга ему указывается source — ViewModel.MyPropertyName, само свойство является target'ом (например, Text элемента myTextBox), направление привязки (←, →, ⇄), плюс конвертер (если нужен). Всё, после этого о someControl.getText() можно забыть.
C>Всякие WPFы будут лежать в глубоком осадке.
Учитывая твой уровень владения матчастью, «глубокий осадок» вполне мог бы рассмешить. Если бы меня не печалило подобное навязчивое бравирование невежеством.
Здравствуйте, Qbit86, Вы писали:
Q>0_o Да что ты говоришь! Эта сказка называется «паттерн MVVM», смотри, например, презентацию (100 Мб) Джейсона Долинджера, особенно обрати внимание на окрестности момента времени 00:21:44:
You are on the right track when you almost NEVER have a need to name a control with x:Name.
Ну что, объясни мне, что заставляет тебя раз за разом упрямо демонстрировать свою недалёкость, кичиться некомпетентностью в вопросах, в которых ни черта не смыслишь?
Ключевое слово здесь "almost", обрати на него внимание.
C>>Ну это сказки даже в WPF, особенно если нужно делать хитрую логику. Q>Хитрая логика работает с моделью вида, а не с гуёвыми контролами.
Что получается одно и то же, если нужно делать хитрые визуальные действия.
C>>А байндинг данные откуда берёт? Из свойства с именем "MyPropertyName"? Q>При создании байндинга ему указывается source — ViewModel.MyPropertyName, само свойство является target'ом (например, Text элемента myTextBox), направление привязки (←, →, ⇄), плюс конвертер (если нужен). Всё, после этого о someControl.getText() можно забыть.
Это я к тому, что имя объекта можно банально генерировать (как я и делаю, кстати).
C>>Всякие WPFы будут лежать в глубоком осадке. Q>Учитывая твой уровень владения матчастью, «глубокий осадок» вполне мог бы рассмешить. Если бы меня не печалило подобное навязчивое бравирование невежеством.
Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше.
Здравствуйте, Qbit86, Вы писали:
C>>Я прекрасно знаю как работает WPF, так как я его использовал. Q>Ой, перестань. Ты уже демонстрировал своё «прекрасно знаю».
И таки ни одной моей ошибки ты не указал...
Здравствуйте, Qbit86, Вы писали:
C>>И таки ни одной моей ошибки ты не указал... Q>Самовнушение как неприятие реальности? Мои комментарии выше от этого никуда не денутся.
Ну так показывай конкретно ошибки. Я использовал WPF — байндинг мне оттуда понравился, всё остальное не особо впечатлило. SWING тут мало кто использовал, так что критика часто совсем не по делу.
Здравствуйте, Cyberax, Вы писали:
C>>>И таки ни одной моей ошибки ты не указал... Q>>Самовнушение как неприятие реальности? Мои комментарии выше от этого никуда не денутся. C>Ну так показывай конкретно ошибки. Я использовал WPF — байндинг мне оттуда понравился, всё остальное не особо впечатлило. SWING тут мало кто использовал, так что критика часто совсем не по делу.
Да ошибок то как таковых нет, но то, что ты пишешь уж больно напоминает типичное поведение людей, которые, столкнувшихся с WPF, решили не тратить время для серьезного изучения (такое же мы наблюдаем на форуме КСВ в отношении .Net вообще). Если пишешь на .Net, то единственной причиной отказа от WPF я могу понять необходимость наличия графики игрового уровня, тут WPF мало чем поможет, скорее даже помешает. Но всё остальное — это просто банальное нежелание осваивать одно, а взамен втащить какую-нить "адаптированную", но привычную стороннюю штуковину в проект.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Qbit86, Вы писали:
Q>>0_o Да что ты говоришь! Эта сказка называется «паттерн MVVM», смотри, например, презентацию (100 Мб) Джейсона Долинджера, особенно обрати внимание на окрестности момента времени 00:21:44:
You are on the right track when you almost NEVER have a need to name a control with x:Name.
Ну что, объясни мне, что заставляет тебя раз за разом упрямо демонстрировать свою недалёкость, кичиться некомпетентностью в вопросах, в которых ни черта не смыслишь? C>Ключевое слово здесь "almost", обрати на него внимание.
Этот вопрос уже обсуждали, "almost" появляется там, где нужно байндить между сосбой визуальные контролы.
При этом в коде обращений не будет.
C>>>Ну это сказки даже в WPF, особенно если нужно делать хитрую логику. Q>>Хитрая логика работает с моделью вида, а не с гуёвыми контролами. C>Что получается одно и то же, если нужно делать хитрые визуальные действия.
Не получается, все хитрые визуальные действия задаются в xaml, и свзяюваются триггерами (тоже в xaml).
C>>>Всякие WPFы будут лежать в глубоком осадке. Q>>Учитывая твой уровень владения матчастью, «глубокий осадок» вполне мог бы рассмешить. Если бы меня не печалило подобное навязчивое бравирование невежеством. C>Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше.
"Использовал" надо заменить на "видел".
Здравствуйте, gandjustas, Вы писали:
C>>Ключевое слово здесь "almost", обрати на него внимание. G>Этот вопрос уже обсуждали, "almost" появляется там, где нужно байндить между сосбой визуальные контролы. G>При этом в коде обращений не будет.
Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность? У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей.
C>>Что получается одно и то же, если нужно делать хитрые визуальные действия. G>Не получается, все хитрые визуальные действия задаются в xaml, и свзяюваются триггерами (тоже в xaml).
Триггеры предназначены, прежде всего, для простых действий, типа установки фокуса в нужное место при нажатии или запуска анимации. У меня всё сложнее.
C>>Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше. G>"Использовал" надо заменить на "видел".
Нет, именно использовал. В первый раз ещё в 2007-м, если не ошибаюсь (до появления XAML-редактора).
Здравствуйте, gandjustas, Вы писали:
C>>Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше. G>"Использовал" надо заменить на "видел".
Кстати, мне тут бросили ссылку на XAML для Java: http://www.soyatec.com/eface/documentation/eFaceOverview/
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Ключевое слово здесь "almost", обрати на него внимание. G>>Этот вопрос уже обсуждали, "almost" появляется там, где нужно байндить между сосбой визуальные контролы. G>>При этом в коде обращений не будет. C>Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность?
В WPF — нет. зато я знаю множество людей, которые не знают\не понимают возможностей байндинга в WPF.
C>У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей.
Может стоит повнимательнее изучить существующие?
C>>>Что получается одно и то же, если нужно делать хитрые визуальные действия. G>>Не получается, все хитрые визуальные действия задаются в xaml, и свзяюваются триггерами (тоже в xaml). C>Триггеры предназначены, прежде всего, для простых действий, типа установки фокуса в нужное место при нажатии или запуска анимации.
Это кто такую глупость сказал? Триггер может запустить Storyboard, а он в свою очередь может сделать парктически все.
C>У меня всё сложнее.
Также сложно как с embedded LDAP?
Мне кажется что вы очередной раз выдумываете сложности.
C>>>Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше. G>>"Использовал" надо заменить на "видел". C>Нет, именно использовал. В первый раз ещё в 2007-м, если не ошибаюсь (до появления XAML-редактора).
А последний?
Здравствуйте, gandjustas, Вы писали:
C>>Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность? G>В WPF — нет. зато я знаю множество людей, которые не знают\не понимают возможностей байндинга в WPF.
Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко.
C>>У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей. G>Может стоит повнимательнее изучить существующие?
Изучил.
C>>Триггеры предназначены, прежде всего, для простых действий, типа установки фокуса в нужное место при нажатии или запуска анимации. G>Это кто такую глупость сказал? Триггер может запустить Storyboard, а он в свою очередь может сделать парктически все.
И чем это отличается от простой передачи события? Ответ: ничем.
Ещё раз повторяю: всякая красивая анимация мне нафиг не нужна. Я прекрасно знаю, как делать всякие мигающие кнопки в WPF. Неинтересно.
C>>У меня всё сложнее. G>Также сложно как с embedded LDAP? G>Мне кажется что вы очередной раз выдумываете сложности.
Нет. Такая реальность — нужно делать интерфейсы к сложным legacy-системам.
G>>>"Использовал" надо заменить на "видел". C>>Нет, именно использовал. В первый раз ещё в 2007-м, если не ошибаюсь (до появления XAML-редактора). G>А последний?
Где-то перед Новым Годом — коннектор делал для одних клиентов.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность? G>>В WPF — нет. зато я знаю множество людей, которые не знают\не понимают возможностей байндинга в WPF. C>Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко.
А человек, который должен с этими формами работать, он справлялся?
Кстати попрдробнее про циклические связи можно? Как оно вообще работает?
ИМХО очередная надуманная сложность как embeddep LDAP.
C>>>У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей. G>>Может стоит повнимательнее изучить существующие? C>Изучил.
Судя по постам — не совсем.
C>>>Триггеры предназначены, прежде всего, для простых действий, типа установки фокуса в нужное место при нажатии или запуска анимации. G>>Это кто такую глупость сказал? Триггер может запустить Storyboard, а он в свою очередь может сделать парктически все. C>И чем это отличается от простой передачи события? Ответ: ничем.
Передачи события кому?
C>>>У меня всё сложнее. G>>Также сложно как с embedded LDAP? G>>Мне кажется что вы очередной раз выдумываете сложности. C>Нет. Такая реальность — нужно делать интерфейсы к сложным legacy-системам.
И почему эти интерфейсы должны быть сложными?
Здравствуйте, gandjustas, Вы писали:
C>>Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко. G>А человек, который должен с этими формами работать, он справлялся?
С трудом. Для того софт и пишем.
G>Кстати попрдробнее про циклические связи можно? Как оно вообще работает?
Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое.
Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет).
G>ИМХО очередная надуманная сложность как embeddep LDAP.
Ничуть.
G>>>Это кто такую глупость сказал? Триггер может запустить Storyboard, а он в свою очередь может сделать парктически все. C>>И чем это отличается от простой передачи события? Ответ: ничем. G>Передачи события кому?
Обработчику событий.
G>>>Также сложно как с embedded LDAP? G>>>Мне кажется что вы очередной раз выдумываете сложности. C>>Нет. Такая реальность — нужно делать интерфейсы к сложным legacy-системам. G>И почему эти интерфейсы должны быть сложными?
Так уж получается.
Здравствуйте, Cyberax, Вы писали:
G>>Кстати попрдробнее про циклические связи можно? Как оно вообще работает? C>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое.
Two-way binding + converter вы считаете такой сложностью? WPF с этим спокойно справляется.
C>Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет).
Это уже MVVM использовать надо, и байндиться на свойства ViewModel.
Та и другая задача вполне спокойно решается в WPF.
Здравствуйте, Cyberax, Вы писали:
C>>>Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность? G>>В WPF — нет. зато я знаю множество людей, которые не знают\не понимают возможностей байндинга в WPF. C>Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко.
Пример "циклической связи" в студию.
C>>>У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей. G>>Может стоит повнимательнее изучить существующие? C>Изучил.
Не заметно.
Здравствуйте, gandjustas, Вы писали:
C>>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое. G>Two-way binding + converter вы считаете такой сложностью? WPF с этим спокойно справляется.
А теперь идём дальше. Например, нужно учитывать, что если мы редактируем деньги, то нам нужно иногда округлять их до десятков центов.
Т.е. имеем сумму $5.00 в поле денег, и 100% в поле ввода процентов. Меняем 100% на 73% — должно получиться $3.60 ($3.65 округлённый в меньшую сторону), так что процент должен скомпенсироваться до 72%. Или наоборот, нужно иметь целые проценты, но при редактировании суммы дробные проценты нужно округлять.
И иногда это нужно делать через цепочку промежуточных преобразований.
В простых случаях можно пробовать вызывать из ConvertBack из Convert (и наоборот), но если нужно что-то более сложное — то упс. Ну и сам интерфейс конвертера не особо приятный. Мало информации о контексте преобразования и его истории, нет чётких механизмов ветирования и отката изменений до вычисленного корректного состояния и т.п.
Плюс, многие формулы валидации работают в одном направлении (и решать их в обратном направлении — совсем недосуг). Мне для binding'а пришлось вообще прикручивать логический движок, а ты говоришь "простой two-way"...
Мне пока единственное что не нравится — у меня биективные преобразования ничем не проверяются (т.е. из-за глюков они бывают и не биективными), поэтому и хочется механизм линз прикрутить и переделать на них большую часть вычислений. Единственное, что пока не разобрался что делать с решателем ограничений.
C>>Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет). G>Это уже MVVM использовать надо, и байндиться на свойства ViewModel.
И она будет повторять визуальную модель.
Здравствуйте, Cyberax, Вы писали:
C>>>Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко. G>>А человек, который должен с этими формами работать, он справлялся? C>С трудом. Для того софт и пишем.
G>>Кстати попрдробнее про циклические связи можно? Как оно вообще работает? C>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое.
И где здесь циклическая связь?
Обычный двунаправленный байндинг на два поля. При обновлении одного из них контроллер (ViewModel) обновляет второе.
C>Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет).
Ты, похоже, вообще не понимаешь что такое WPF, что такое MVVM... ппц Лучше не пиши больше — не позорься так.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое. G>>Two-way binding + converter вы считаете такой сложностью? WPF с этим спокойно справляется. C>А теперь идём дальше. Например, нужно учитывать, что если мы редактируем деньги, то нам нужно иногда округлять их до десятков центов.
C>Т.е. имеем сумму $5.00 в поле денег, и 100% в поле ввода процентов. Меняем 100% на 73% — должно получиться $3.60 ($3.65 округлённый в меньшую сторону), так что процент должен скомпенсироваться до 72%. Или наоборот, нужно иметь целые проценты, но при редактировании суммы дробные проценты нужно округлять.
C>И иногда это нужно делать через цепочку промежуточных преобразований.
Если честно, совсем не понимаю вашей проблемы. Как уже неоднократно упоминали, MVVM в руки, вся необходимая логика сосредоточена в классах View Model, проценты, налоги, округления, что хотите. При этом все вопросы отображения берёт на себя декларативный xaml. Какие возникают сложности именно с визуализацией ваших данных?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое. G>>Two-way binding + converter вы считаете такой сложностью? WPF с этим спокойно справляется. C>А теперь идём дальше. Например, нужно учитывать, что если мы редактируем деньги, то нам нужно иногда округлять их до десятков центов.
C>Т.е. имеем сумму $5.00 в поле денег, и 100% в поле ввода процентов. Меняем 100% на 73% — должно получиться $3.60 ($3.65 округлённый в меньшую сторону), так что процент должен скомпенсироваться до 72%. Или наоборот, нужно иметь целые проценты, но при редактировании суммы дробные проценты нужно округлять.
C>И иногда это нужно делать через цепочку промежуточных преобразований.
В таком случае все нетривиальные операции надо проделывать через ViewModel.
C>В простых случаях можно пробовать вызывать из ConvertBack из Convert (и наоборот), но если нужно что-то более сложное — то упс. Ну и сам интерфейс конвертера не особо приятный. Мало информации о контексте преобразования и его истории, нет чётких механизмов ветирования и отката изменений до вычисленного корректного состояния и т.п.
Никогда бы не подумал что простому байндингу нужно "чёткий механизм ветирования и отката изменений до вычисленного корректного состояния и т.п".
делайте это во ViewModel.
C>Плюс, многие формулы валидации работают в одном направлении (и решать их в обратном направлении — совсем недосуг). Мне для binding'а пришлось вообще прикручивать логический движок, а ты говоришь "простой two-way"...
C>Мне пока единственное что не нравится — у меня биективные преобразования ничем не проверяются (т.е. из-за глюков они бывают и не биективными), поэтому и хочется механизм линз прикрутить и переделать на них большую часть вычислений. Единственное, что пока не разобрался что делать с решателем ограничений.
Вы уже раза три подтвердили что неумете использовать WPF. Хватит уже народ смешить.
Как я и говорил что не бывает случаев недостаточной мощности байндинга, бавают случаи неумения его использовать.
C>>>Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет). G>>Это уже MVVM использовать надо, и байндиться на свойства ViewModel. C>И она будет повторять визуальную модель.
А что такое визуальная модель?
Может посмотрите видео по ссылке которую Qbit давал?
Только не надо рассказывать то вы знаете что такое MVVM — это не так.
Здравствуйте, User239, Вы писали:
C>>И иногда это нужно делать через цепочку промежуточных преобразований. U>Если честно, совсем не понимаю вашей проблемы. Как уже неоднократно упоминали, MVVM в руки, вся необходимая логика сосредоточена в классах View Model, проценты, налоги, округления, что хотите. При этом все вопросы отображения берёт на себя декларативный xaml. Какие возникают сложности именно с визуализацией ваших данных?
Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам. И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий.
Здравствуйте, gandjustas, Вы писали:
G>Никогда бы не подумал что простому байндингу нужно "чёткий механизм ветирования и отката изменений до вычисленного корректного состояния и т.п". G>делайте это во ViewModel.
Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Никогда бы не подумал что простому байндингу нужно "чёткий механизм ветирования и отката изменений до вычисленного корректного состояния и т.п". G>>делайте это во ViewModel. C>Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов?
А как другим способом обеспечить двустороннюю передачу данным между свойством "специального синтетического объекта" (который все нормальные люди называют ViewModel), без написани тонны инфраструктурного кода.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, User239, Вы писали:
C>>>И иногда это нужно делать через цепочку промежуточных преобразований. U>>Если честно, совсем не понимаю вашей проблемы. Как уже неоднократно упоминали, MVVM в руки, вся необходимая логика сосредоточена в классах View Model, проценты, налоги, округления, что хотите. При этом все вопросы отображения берёт на себя декларативный xaml. Какие возникают сложности именно с визуализацией ваших данных? C>Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам.
Может перевести слово binding? По русски оно и будет "привязка".
В впф байндинг нужен именно для "тупой привязки к свойствам".
C>И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий.
Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами.
Здравствуйте, gandjustas, Вы писали:
C>>Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам. G>Может перевести слово binding? По русски оно и будет "привязка". G>В впф байндинг нужен именно для "тупой привязки к свойствам".
Мне нужен _не_ тупой байндинг. У меня есть модель данных, которая для вычислений преобразовывается специальным образом (как я уже говорил). Модель данных достаточно далека от того, что видит пользователь.
Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно.
C>>И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий. G>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами.
Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам. G>>Может перевести слово binding? По русски оно и будет "привязка". G>>В впф байндинг нужен именно для "тупой привязки к свойствам". C>Мне нужен _не_ тупой байндинг. У меня есть модель данных, которая для вычислений преобразовывается специальным образом (как я уже говорил). Модель данных достаточно далека от того, что видит пользователь.
Это всегда так.
C>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно.
Это "счастье" называет MVVM, вы считаете такой подход ненужным?
А MVC и MVP ?
Не надо обвинять WPF в свойе некомпетентности.
C>>>И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий. G>>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами. C>Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде.
Давайте весь код, уж очень интересно во сколько раз удастся его сократить.
Здравствуйте, gandjustas, Вы писали:
C>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>Это "счастье" называет MVVM, вы считаете такой подход ненужным?
Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами.
G>>>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами. C>>Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде. G> G>Давайте весь код, уж очень интересно во сколько раз удастся его сократить.
Весь код я всё равно не дам. Его там сейчас 180 килобайт, не считая библиотек. Пример вечером могу прислать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Никогда бы не подумал что простому байндингу нужно "чёткий механизм ветирования и отката изменений до вычисленного корректного состояния и т.п". G>>делайте это во ViewModel. C>Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов?
Ну так байндинг для того и нужен, чтобы отделить вашу логику от представления.
С>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно.
Конечно код для "чёткого механизма ветирования и отката изменений до вычисленного корректного состояния" за вас не напишет ни один фреймворк на свете. Вопрос лишь в том, где писать этот код. Если это не "промежуточный слой визуальных моделей", тогда что? Обработчики кнопок (образно)? В этом случае код явно будет больше, чем при байндинге (чего стоят одни getText, setText). Не говоря уж о том, насколько увеличится подверженность различным ошибкам.
Здравствуйте, Cyberax, Вы писали:
C>>>Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам. G>>Может перевести слово binding? По русски оно и будет "привязка". G>>В впф байндинг нужен именно для "тупой привязки к свойствам". C>Мне нужен _не_ тупой байндинг. У меня есть модель данных, которая для вычислений преобразовывается специальным образом (как я уже говорил). Модель данных достаточно далека от того, что видит пользователь.
C>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно.
Я ржал... Ты либо туп либо притворяешься. Тебя уже десять раз ткнули носом, разжевали и положили в клюв, дали мультик посмотреть, а ты все еще не допер как работает MVVM и зачем вообще придумали MVC? Ндааааааааа.....
C>>>И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий. G>>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами. C>Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде.
Здравствуйте, Cyberax, Вы писали:
G>>Давайте весь код, уж очень интересно во сколько раз удастся его сократить.
C>PS: вообще поражают меня сторонники ${ПОСЛЕДНЯЯ_ТЕХНОЛОГИЯ}, думающие, что она решает все проблемы. Маловато нестандартных задач, видимо, решают...
Ну давай просвяти нас дурней — расскажи какие такие задачи построения пользовательского интерфейса WPF не решает. Внимательно слушаем тебя, умник.
Здравствуйте, Cyberax, Вы писали:
C>Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов?
Если воспринимать Binding как тупую трансляцию свойств, то, конечно, нафиг оно не нужно. Только Binding в WPF — это не просто пересылка значения. Это еще и отслеживание изменений, это преобразование типов, это фильтрация, это сортировка, это в конце концов декларативное выражение связей, которое гораздо читабельнее (впрочем я давно заметил, что последнее совсем не аргумент, ага). Посмотрел бы я, как ты программно обеспечишь привязку между контролами разных уровней визуального дерева в ситуации, когда содержимое этого дерева постоянно меняется. Там прилично нюансов и заботится о них нет никакого желания.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали: G>>Давайте весь код, уж очень интересно во сколько раз удастся его сократить. C>PS: вообще поражают меня сторонники ${ПОСЛЕДНЯЯ_ТЕХНОЛОГИЯ}, думающие, что она решает все проблемы. Маловато нестандартных задач, видимо, решают...
А меня поражают сторонники, что одна крайность лучше другой. Тупое нежелание осваивать ${ПОСЛЕДНЯЯ_ТЕХНОЛОГИЯ} ничем не лучше. И очень забавляет, как эта "директива" действует на некоторых голосовальщиков
Здравствуйте, Cyberax, Вы писали:
C>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>>Это "счастье" называет MVVM, вы считаете такой подход ненужным? C>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами.
А че бы тогда вообще не перестать использовать ООП. Пиши всё на голом C, на фиг тебе лишнии слои? Ну право, несмешно ведь уже. Ясно видно, что ты не пробовал изменить взгляд на вещи и начать разрабатывать интерфейс приложения по другому: когда логика в одном классе, представление в другом (хотя вроде ссылался на что-то подобное). Только, разрабатывая нечто подобное, можно понять все плюсы этого подхода. Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM. А ты лишний слой... Это как торт из печенки! Можно сделать слоями и всё будет вкусно, а можно накидать превратить всё это в кашу и потушить — тоже есть можно, но уже не то...
Здравствуйте, MxKazan, Вы писали:
C>>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>>>Это "счастье" называет MVVM, вы считаете такой подход ненужным? C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. MK>А че бы тогда вообще не перестать использовать ООП. Пиши всё на голом C, на фиг тебе лишнии слои? Ну право, несмешно ведь уже. Ясно видно, что ты не пробовал изменить взгляд на вещи и начать разрабатывать интерфейс приложения по другому: когда логика в одном классе, представление в другом (хотя вроде ссылался на что-то подобное). Только, разрабатывая нечто подобное, можно понять все плюсы этого подхода. Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM. А ты лишний слой... Это как торт из печенки! Можно сделать слоями и всё будет вкусно, а можно накидать превратить всё это в кашу и потушить — тоже есть можно, но уже не то...
Просто Cyberax не слышал ни о single responsibility principle, ни о separation of concepts, ни о testability.
Здравствуйте, kuj, Вы писали:
C>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. kuj>Я ржал... Ты либо туп либо притворяешься. Тебя уже десять раз ткнули носом, разжевали и положили в клюв, дали мультик посмотреть, а ты все еще не допер как работает MVVM и зачем вообще придумали MVC? Ндааааааааа.....
Тебе, куй, вообще говорить что-то бесполезно. Кроме себя ты никого больше не слышишь. Примерно как Шеридан.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kuj, Вы писали:
C>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. kuj>>Я ржал... Ты либо туп либо притворяешься. Тебя уже десять раз ткнули носом, разжевали и положили в клюв, дали мультик посмотреть, а ты все еще не допер как работает MVVM и зачем вообще придумали MVC? Ндааааааааа..... C>Тебе, куй, вообще говорить что-то бесполезно. Кроме себя ты никого больше не слышишь. Примерно как Шеридан.
Бугага, ты то все слышишь. Когда тебе десять человек одно и то же твердят, а ты продолжаешь свое "ла-ла-ла".
Вытащи бревно из своего глаза прежде, чем указывать на сучок в чужом, умник.
kuj>>Просто Cyberax не слышал ни о single responsibility principle, ни о separation of concepts, ни о testability.
AV>Точно? Я с ним водку за одним столом не пил и не работал с ним тоже, но у меня сложилось совсем обратное впечатление.
Зашибись. Впечатление теперь складывается исключительно после распития поллитры.
Лезь обратно под то бревно, из-под которого вылез.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Давайте весь код, уж очень интересно во сколько раз удастся его сократить.
C>PS: вообще поражают меня сторонники ${ПОСЛЕДНЯЯ_ТЕХНОЛОГИЯ}, думающие, что она решает все проблемы. Маловато нестандартных задач, видимо, решают...
Так вас просили привести пример нестандартной задачи, а вы привели пример который в WPF решается стандартным (де-факто) подходом.
А если вы придумываете нестандартные решения для стандартных задач, то не стоит этим так бравировать, это вам чести не сделает.
ЗЫ. Кто-то сказал что у любой программистской задачи есть два решения: "правильно" и "по-своему" вы видимо выбрали второй путь.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
Как по мне, по многим параметрам C# (да и Java тоже) занимает промежуточное положение, что делает их более-менее пригодным для решения большого круга задач. Но очень часто для конкретной задачи удобнее и предпочтительнее был бы язык со специальными возможностями. Но именно эта универсальность и не даст загнуться языкам C# и Java.
Здравствуйте, Mystic, Вы писали:
KV>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
M>Как по мне, по многим параметрам C# (да и Java тоже) занимает промежуточное положение, что делает их более-менее пригодным для решения большого круга задач. Но очень часто для конкретной задачи удобнее и предпочтительнее был бы язык со специальными возможностями. Но именно эта универсальность и не даст загнуться языкам C# и Java.
kuj>>>Просто Cyberax не слышал ни о single responsibility principle, ни о separation of concepts, ни о testability.
AV>>Точно? Я с ним водку за одним столом не пил и не работал с ним тоже, но у меня сложилось совсем обратное впечатление.
kuj>Зашибись. Впечатление теперь складывается исключительно после распития поллитры.
Зашибись, читаем только то, что хочется. Вторую половину (про работу) уже, видать, не осилил.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>>Это "счастье" называет MVVM, вы считаете такой подход ненужным? C>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами.
Так может вы еще и MVC и MVP не применяете? тоже обходитесь "другиси способами"?
Надеюсь эти способы не сводятся к запихиванию всего в OnClick?
G>>>>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами. C>>>Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде. G>> G>>Давайте весь код, уж очень интересно во сколько раз удастся его сократить. C>Весь код я всё равно не дам. Его там сейчас 180 килобайт, не считая библиотек. Пример вечером могу прислать.
Можете выслать.
Я тут написал небольшой пример с вашими процентами, получилось значительно меньше 180 кб.
Здравствуйте, MxKazan, Вы писали:
C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. MK>А че бы тогда вообще не перестать использовать ООП. Пиши всё на голом C, на фиг тебе лишнии слои? Ну право, несмешно ведь уже. Ясно видно, что ты не пробовал изменить взгляд на вещи и начать разрабатывать интерфейс приложения по другому: когда логика в одном классе, представление в другом (хотя вроде ссылался на что-то подобное). Только, разрабатывая нечто подобное, можно понять все плюсы этого подхода.
У Anatolix'а есть замечательная подпись: "Любая проблема решается введением дополнительного уровня абстракции, кроме слищком большого числа уровней абстракции". Я не против добавлять лишние слои там, где это надо.
Но только чтоб оно было идеологически правильно со стороны WPF? Зачем?
MK>Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM.
Не, ну хватит мне сказки рассказывать. Надоело уже.
Здравствуйте, User239, Вы писали:
C>>Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов? U>Ну так байндинг для того и нужен, чтобы отделить вашу логику от представления.
Нет. Бйндинг нужен чтобы связать представление и данные. Какие именно данные — это вопрос. Иногда можно сразу реальные данные модели приложения использовать.
С>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. U>Конечно код для "чёткого механизма ветирования и отката изменений до вычисленного корректного состояния" за вас не напишет ни один фреймворк на свете. Вопрос лишь в том, где писать этот код. Если это не "промежуточный слой визуальных моделей", тогда что? Обработчики кнопок (образно)? В этом случае код явно будет больше, чем при байндинге (чего стоят одни getText, setText). Не говоря уж о том, насколько увеличится подверженность различным ошибкам.
У меня другой результат — мне проще было всё написать с классическими getText()/setText(), чем использовать более сложные механизмы. Как раз из-за того, что при этом от GUI-фреймворка получается меньше самодеятельности там, где она не нужна.
Простой пример: у меня есть элементы ввода A, B, C, D, где C=A+B, а D=сложное_вычисление(C). Мне в модели нафиг не нужно отдельное поле для C — но мне его придётся сделать, если я захочу использовать байндинг. Так как привязаться к значению формулы нормально с помощью стандартного механизма не получится (почему так, я уже писал).
Именно поэтому я всегда выбираю фреймворки, которые позволяют удобно при необходимости падать на самый низкий уровень.
Здравствуйте, Cyberax, Вы писали:
C>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем?
Иди ртфмь http://ru.wikipedia.org/wiki/Model-View-Controller
и не задавай больше глупых вопросов.
C>Простой пример: у меня есть элементы ввода A, B, C, D, где C=A+B, а D=сложное_вычисление(C). Мне в модели нафиг не нужно отдельное поле для C — но мне его придётся сделать, если я захочу использовать байндинг. Так как привязаться к значению формулы нормально с помощью стандартного механизма не получится (почему так, я уже писал).
Афигеть, дайте два! А теперь расскажи нам как ты будешь писать юнит тесты. Слушаем.
Здравствуйте, Cyberax, Вы писали:
C>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем?
Затем, что ты пишешь на WPF! Но это так сложно понять, что другой инструмент требует другого подхода и только, начав применять этот подход, ты сможешь ощутить преимущества. Применимо и к .Net и к WPF.
MK>>Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM. C>Не, ну хватит мне сказки рассказывать. Надоело уже.
Ну. Ок. Мне тоже надоело.
Здравствуйте, Cyberax, Вы писали:
C>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем?
Это не со стороны WPF, а со стороны всякого фреймворка, поддерживающего богатые средства байндинга. Вообще, про MVVM я впервые услышал от коллеги, которые программирует на Flex'е.
C>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF
Этот «лишний слой» как раз является идиоматическим примером разрыва связей (твоих «циклических зависимостей»). Вместо горизонтальной зависимости мы вводим общую сущность, и вертикальные зависимости. Преимущество налицо: если у тебя было n сущностей на одном уровне, то всевозможных связей у тебя n(n−1)/2 (нарисуй полный граф и посчитай число рёбер); вводя дополнительную сущность на верхний уровень, ты устанавливаешь связи только с ней, всего n связей.
C>Не, ну хватит мне сказки рассказывать. Надоело уже.
В свою очередь, просто перестань уже на эти «сказки» отвечать. Продолжай себе программировать в стиле Button1_Click, всё остальное от лукакового, ага.
Здравствуйте, Qbit86, Вы писали:
C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF
Q>Этот «лишний слой» как раз является идиоматическим примером разрыва связей (твоих «циклических зависимостей»). Вместо горизонтальной зависимости мы вводим общую сущность, и вертикальные зависимости. Преимущество налицо: если у тебя было n сущностей на одном уровне, то всевозможных связей у тебя n(n−1)/2 (нарисуй полный граф и посчитай число рёбер); вводя дополнительную сущность на верхний уровень, ты устанавливаешь связи только с ней, всего n связей.
Дело даже не столько в сущностях, сколько в невозможность модульного тестирования юзер интерфейса.
Здравствуйте, MxKazan, Вы писали:
C>>Не, ну хватит мне сказки рассказывать. Надоело уже. MK>Ну. Ок. Мне тоже надоело.
Я завтра сделаю модельный пример того, что мне нужно добиться. Мне интересно, как бы это малыми силами и расширяемо можно было бы сделать на WPF.
Здравствуйте, Qbit86, Вы писали:
C>>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем? Q>Это не со стороны WPF, а со стороны всякого фреймворка, поддерживающего богатые средства байндинга. Вообще, про MVVM я впервые услышал от коллеги, которые программирует на Flex'е.
Я про MVVM услышал от WPFовцев, но использовал её ещё раньше в JFace (система байндинга для SWT), году так в 2003 (AFAIR).
C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF Q>Этот «лишний слой» как раз является идиоматическим примером разрыва связей (твоих «циклических зависимостей»). Вместо горизонтальной зависимости мы вводим общую сущность, и вертикальные зависимости. Преимущество налицо: если у тебя было n сущностей на одном уровне, то всевозможных связей у тебя n(n−1)/2 (нарисуй полный граф и посчитай число рёбер); вводя дополнительную сущность на верхний уровень, ты устанавливаешь связи только с ней, всего n связей.
Не понял что ты этим хочешь сказать. У меня сейчас есть модель данных (исходные данные), есть набор формул (промежуточные результаты вычислений которых могут быть привязаны к графическим элементам) и всё. Даже результат вычислений в явном виде нигде не хранится (а каждый раз при необходимости вычисляется).
У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF.
Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI. Так как простой декларативный двусторонний байндинг (пусть и с фильтрами и конвертерами) мне не подходит.
C>>Не, ну хватит мне сказки рассказывать. Надоело уже. Q>В свою очередь, просто перестань уже на эти «сказки» отвечать. Продолжай себе программировать в стиле Button1_Click, всё остальное от лукакового, ага.
Я не программирую в стиле Button1_Click — ты меня за дельфиста принимаешь, что ли?
Просто я хочу донести до вас, что стиль WPF не является единственно верным, и иногда приводит к избыточности.
Здравствуйте, Cyberax, Вы писали:
C>Я завтра сделаю модельный пример того, что мне нужно добиться. Мне интересно, как бы это малыми силами и расширяемо можно было бы сделать на WPF.
Только, будь добр, не здесь, а лучше в [dotnet.gui][WPF], ок?
Здравствуйте, Cyberax, Вы писали:
C>Я про MVVM услышал от WPFовцев...
Сам термин придумали WPF'овцы, но разновидность MVVM описывал ещё и Мартин Фаулер — Presentation Model (мне, впрочем, эта статья не нравится). В принципе, паттерн можно использовать практически в любом GUI фреймворке, но если он не поддерживает привязок, то получится слишком много рутинного boilerplate кода. В своей статье Мартин с этой мыслью солидарен:
Probably the most annoying part of Presentation Model is the synchronization between Presentation Model and view. It's simple code to write, but I always like to minimize this kind of boring repetitive code. Ideally some kind of framework could handle this, which I'm hoping will happen some day with technologies like .NET's data binding.
C>но использовал её ещё раньше в JFace (система байндинга для SWT), году так в 2003 (AFAIR).
Но ты ведь отдаёшь себе отчёт в том, что буквально каждая твоя реплика выдаёт в тебе верхоглядство и дилетантизм? Серьёзно, не обижайся. Нет ничего плохого в незнании какой-то области, неприятно лишь явное пускание пыли в глаза. Хорошо хоть, что эта ветка подтолкнула тебя (судя по всему) на лету осваивать матчасть.
C>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF.
А можешь подробнее, с конкретикой? В WPF байндинг тоже изменяет свойства контролов.
C>Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI.
Возможно, для этого и есть модель представления (не путать с моделью данных).
C>Просто я хочу донести до вас, что стиль WPF не является единственно верным, и иногда приводит к избыточности.
Если честно, по-моему здесь никто особо и не обеспокоен «единственно верностью» WPF'а. Более того, у меня даже есть предположение, что байндинги в том же Flex'е мощнее и удобнее таковых в WPF.
Здравствуйте, Qbit86, Вы писали:
C>>Я про MVVM услышал от WPFовцев... Q>Сам термин придумали WPF'овцы, но разновидность MVVM описывал ещё и Мартин Фаулер — Presentation Model (мне, впрочем, эта статья не нравится). В принципе, паттерн можно использовать практически в любом GUI фреймворке, но если он не поддерживает привязок, то получится слишком много рутинного boilerplate кода.
Если покопаться, то тут можно до Smalltalk'а дойти, где тоже подобный паттерн широко использовался. Там и байндинг был очень прозрачный — язык-то динамический, с поддержкой интроспекции.
C>>но использовал её ещё раньше в JFace (система байндинга для SWT), году так в 2003 (AFAIR). Q>Но ты ведь отдаёшь себе отчёт в том, что буквально каждая твоя реплика выдаёт в тебе верхоглядство и дилетантизм?
А может просто тебе так кажется?
Q>Серьёзно, не обижайся. Нет ничего плохого в незнании какой-то области, неприятно лишь явное пускание пыли в глаза. Хорошо хоть, что эта ветка подтолкнула тебя (судя по всему) на лету осваивать матчасть.
Я вообще-то матчасть знаю, просто смотрю на неё с другой точки зрения. Мне многое в WPF просто неинтересно — типа анимирования всех свойств или добавления контролов на грани вращающегося кубика.
C>>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF. Q>А можешь подробнее, с конкретикой? В WPF байндинг тоже изменяет свойства контролов.
В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход.
C>>Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI. Q>Возможно, для этого и есть модель представления (не путать с моделью данных).
И вот мне её не хочется делать.
Здравствуйте, Cyberax, Вы писали:
C>>>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем? Q>>Это не со стороны WPF, а со стороны всякого фреймворка, поддерживающего богатые средства байндинга. Вообще, про MVVM я впервые услышал от коллеги, которые программирует на Flex'е. C>Я про MVVM услышал от WPFовцев, но использовал её ещё раньше в JFace (система байндинга для SWT), году так в 2003 (AFAIR).
C>>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF Q>>Этот «лишний слой» как раз является идиоматическим примером разрыва связей (твоих «циклических зависимостей»). Вместо горизонтальной зависимости мы вводим общую сущность, и вертикальные зависимости. Преимущество налицо: если у тебя было n сущностей на одном уровне, то всевозможных связей у тебя n(n−1)/2 (нарисуй полный граф и посчитай число рёбер); вводя дополнительную сущность на верхний уровень, ты устанавливаешь связи только с ней, всего n связей. C>Не понял что ты этим хочешь сказать. У меня сейчас есть модель данных (исходные данные), есть набор формул (промежуточные результаты вычислений которых могут быть привязаны к графическим элементам) и всё. Даже результат вычислений в явном виде нигде не хранится (а каждый раз при необходимости вычисляется).
C>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF.
Открой для себя INotifyPropertyChanged.
C>Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI. Так как простой декларативный двусторонний байндинг (пусть и с фильтрами и конвертерами) мне не подходит.
Ты сам-то хоть знаешь почему он тебе не подходит? Уверен, что нет...
Цирк.
Q>>В свою очередь, просто перестань уже на эти «сказки» отвечать. Продолжай себе программировать в стиле Button1_Click, всё остальное от лукакового, ага. C>Я не программирую в стиле Button1_Click — ты меня за дельфиста принимаешь, что ли?
C>Просто я хочу донести до вас, что стиль WPF не является единственно верным, и иногда приводит к избыточности.
Здравствуйте, Cyberax, Вы писали:
C>>>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF. Q>>А можешь подробнее, с конкретикой? В WPF байндинг тоже изменяет свойства контролов. C>В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход.
Нет слов... Ты все еще не допер, что контролы в WPF привязываются не к данным, а к контроллеру.
Здравствуйте, kuj, Вы писали:
Q>>Более того, у меня даже есть предположение, что байндинги в том же Flex'е мощнее и удобнее таковых в WPF.
kuj>Расскажи подробнее здесь http://rsdn.ru/forum/message/3325376.flat.aspx
Ничем не могу помочь, сам с радостью послушал бы. Один знакомый, ко мнению которого прислушиваюсь, вкратце рассказывал о кое-каких фишках Flex'а. В частности, если я правильно понял, в объявлении привязки можно указывать выражение над привязываемым полем — ну там домножить на что-нибудь, записать результат вызова функции над источником, etc. В WPF же, даже если надо взять просто отрицание какого-нибудь булевского поля, приходится городить конвертор.
На всякий случай повторю, вышеизложенное недостоверно, с чужих слов, требует более глубокого ознакомления с предметом. Кстати, надо подписать упомянутого коллегу изложить мысли по поводу Flex'а в ту ветку.
Здравствуйте, Qbit86, Вы писали:
Q>Ничем не могу помочь, сам с радостью послушал бы. Один знакомый, ко мнению которого прислушиваюсь, вкратце рассказывал о кое-каких фишках Flex'а. В частности, если я правильно понял, в объявлении привязки можно указывать выражение над привязываемым полем — ну там домножить на что-нибудь, записать результат вызова функции над источником, etc.
А можно спросить отсюда более подробно? В частности, мне было бы это очень интересно.
Здравствуйте, gandjustas, Вы писали:
C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. G>Так может вы еще и MVC и MVP не применяете? тоже обходитесь "другиси способами"? G>Надеюсь эти способы не сводятся к запихиванию всего в OnClick?
Нет.
G>Можете выслать.
Готовлю...
G> OnPropertyChanging("Money"); G> OnPropertyChanging("MoneyPercent");
Сломается.
G> _money = Math.Round(value * MaxMoney / 100, 1); G> OnPropertyChanged("Money"); G> OnPropertyChanged("MoneyPercent");
Сломается, если шаг инкремента поля ввода процентов (спиннера) будет меньше минимального шага.
(мелочи типа неправильного поведения Math.Round опускаю).
Ну и у меня всё это уложится примерно в 5 строк прикладного кода
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
M>Как по мне, по многим параметрам C# (да и Java тоже) занимает промежуточное положение,
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. G>>Так может вы еще и MVC и MVP не применяете? тоже обходитесь "другиси способами"? G>>Надеюсь эти способы не сводятся к запихиванию всего в OnClick? C>Нет.
G>>Можете выслать. C>Готовлю...
G>> OnPropertyChanging("Money"); G>> OnPropertyChanging("MoneyPercent"); C>Сломается.
Как сломается?
G>> _money = Math.Round(value * MaxMoney / 100, 1); G>> OnPropertyChanged("Money"); G>> OnPropertyChanged("MoneyPercent"); C>Сломается, если шаг инкремента поля ввода процентов (спиннера) будет меньше минимального шага.
Какого инкремента?
Там текстбоксы.
C>Ну и у меня всё это уложится примерно в 5 строк прикладного кода
Ага, и 180 кб фреймворка.
Здравствуйте, Cyberax, Вы писали:
C>>>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF. Q>>А можешь подробнее, с конкретикой? В WPF байндинг тоже изменяет свойства контролов. C>В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход.
И как при таком подходе тестировать логику UI?
C>>>Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI. Q>>Возможно, для этого и есть модель представления (не путать с моделью данных). C>И вот мне её не хочется делать.
И для этого надо говродить немалый фреймвок.
Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие.
Здравствуйте, gandjustas, Вы писали:
C>>В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход. G>И как при таком подходе тестировать логику UI?
А накой её тестировать? GUI должны тестировать живые люди.
Автоматически тестировать надо формулы, чему моя система только способствует.
C>>И вот мне её не хочется делать. G>И для этого надо говродить немалый фреймвок. G>Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие.
Мои проблемы не решаются простыми способами...
Здравствуйте, gandjustas, Вы писали:
G>>> OnPropertyChanging("Money"); G>>> OnPropertyChanging("MoneyPercent"); C>>Сломается. G>Как сломается?
Лень объяснять.
C>>Сломается, если шаг инкремента поля ввода процентов (спиннера) будет меньше минимального шага. G>Какого инкремента? G>Там текстбоксы.
Ну попробуй для спиннера сделать.
C>>Ну и у меня всё это уложится примерно в 5 строк прикладного кода G>Ага, и 180 кб фреймворка.
У меня таких полей около 5 тысяч штук. Будем считать экономию?
Здравствуйте, gandjustas, Вы писали:
G>Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие.
Заметь, что при этом эти же джависты рассказывают нам басни о том, что под джава больше библиотек и что это дотнетчики изобретают велосипеды, либо копируют их из джава.
Здравствуйте, Cyberax, Вы писали:
C>>>И вот мне её не хочется делать. G>>И для этого надо говродить немалый фреймвок. G>>Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие. C>Мои проблемы не решаются простыми способами...
То что ваши поблемы не решаются простыми способами я даже не сомневаюсь.
А вот код который вы пишите вполне мог бы быть проще раз в 10 при использовании соотвествуюещего подхода.
C>>>В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход. G>>И как при таком подходе тестировать логику UI? C>А накой её тестировать? GUI должны тестировать живые люди.
C>Автоматически тестировать надо формулы, чему моя система только способствует.
Состояния модели тестировать уже не надо? Зашибись...
G>>И для этого надо говродить немалый фреймвок. G>>Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие. C>Мои проблемы не решаются простыми способами...
Угу, поэтому вы себе и того больше усложняете жизнь. Индусологика. тьфу
G>>>> OnPropertyChanging("Money"); G>>>> OnPropertyChanging("MoneyPercent"); C>>>Сломается. G>>Как сломается? C>Лень объяснять.
Еще бы. Это в стандартах местных линухоидов — сначала ляпнуть чушь, потом съехать с темы "мне лень объяснять"... тьфу
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>> OnPropertyChanging("Money"); G>>>> OnPropertyChanging("MoneyPercent"); C>>>Сломается. G>>Как сломается? C>Лень объяснять.
C>>>Сломается, если шаг инкремента поля ввода процентов (спиннера) будет меньше минимального шага. G>>Какого инкремента? G>>Там текстбоксы. C>Ну попробуй для спиннера сделать.
Теперь понял к чему ты клонишь.
При UpdateSourceTrigger=PropertyChanged проперти апдейтится, а новое значение не считывается, чтобы избежать зацикливания (например изменение A меняет B, изменение B при этом меняет A).
Для текстбоксов по умолчанию UpdateSourceTrigger=LostFocus и считываение нового значения происходит при потере фокуса, а не при изменении.
Для сайдера лечится очень простым обработчиком ValueChanged:
private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
{
var slider = sender as Slider;
slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
}
C>>>Ну и у меня всё это уложится примерно в 5 строк прикладного кода G>>Ага, и 180 кб фреймворка. C>У меня таких полей около 5 тысяч штук. Будем считать экономию?
Мне вас очень жаль ваших пользователей если у вас столько полей в программе.
Здравствуйте, gandjustas, Вы писали:
C>>Ну попробуй для спиннера сделать. G>Теперь понял к чему ты клонишь. G>При UpdateSourceTrigger=PropertyChanged проперти апдейтится, а новое значение не считывается, чтобы избежать зацикливания (например изменение A меняет B, изменение B при этом меняет A).
Это тоже, особенно если в этом участвует ещё три-четыре контрола.
G>
G>private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
G>{
G> var slider = sender as Slider;
G> slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
G>}
G>
А теперь учти, что у тебя оно иногда будет "непередвигаемым", так как некоторые состояния слайдера будут невалидными.
G>>>Ага, и 180 кб фреймворка. C>>У меня таких полей около 5 тысяч штук. Будем считать экономию? G>Мне вас очень жаль ваших пользователей если у вас столько полей в программе.
Не в одной форме, естественно. С количеством ничего не сделать, это не мы придумываем эти формы.
Здравствуйте, kuj, Вы писали:
kuj>Заметь, что при этом эти же джависты рассказывают нам басни о том, что под джава больше библиотек и что это дотнетчики изобретают велосипеды, либо копируют их из джава.
kuj>Двойные стандарты на лицо.
Ну, в последнем флейме, например, речь шла об open-source библиотеках, которые можно было бы использовать на Mono без опаски лицензионного преследования со стороны МС. WPF к таким библиотекам не относится
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Ну попробуй для спиннера сделать. G>>Теперь понял к чему ты клонишь. G>>При UpdateSourceTrigger=PropertyChanged проперти апдейтится, а новое значение не считывается, чтобы избежать зацикливания (например изменение A меняет B, изменение B при этом меняет A). C>Это тоже, особенно если в этом участвует ещё три-четыре контрола.
Неважно. Этот эффект распространятеся только на активный контрол.
G>>
G>>private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
G>>{
G>> var slider = sender as Slider;
G>> slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
G>>}
G>>
C>А теперь учти, что у тебя оно иногда будет "непередвигаемым", так как некоторые состояния слайдера будут невалидными.
Визуально слайдер на эти состояния не попадает.
G>>>>Ага, и 180 кб фреймворка. C>>>У меня таких полей около 5 тысяч штук. Будем считать экономию? G>>Мне вас очень жаль ваших пользователей если у вас столько полей в программе. C>Не в одной форме, естественно. С количеством ничего не сделать, это не мы придумываем эти формы.
Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate.
Кроме того можно применить генерацию темплейтов по метаданным.
Сильно сомневаюсь что даже половину из этих 5 тысяч контролов надо описывать в xaml.
G>>>private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
G>>>{
G>>> var slider = sender as Slider;
G>>> slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
G>>>}
G>>>
C>>А теперь учти, что у тебя оно иногда будет "непередвигаемым", так как некоторые состояния слайдера будут невалидными. G>Визуально слайдер на эти состояния не попадает.
Почему? Вполне может. Просто это как раз первая реальная проблема была, с которой я столкнулся. В некоторых случаях модель может быть неконсистентной, и надо приостановить передачу данных до восстановления целостности.
А при восстановлении целостности тоже интересные результаты — несколько контролов одновременно могут решить пересчитаться, что вызывает проблемы с зависимостями. И это даже не у одного меня встречается —
G>>>Мне вас очень жаль ваших пользователей если у вас столько полей в программе. C>>Не в одной форме, естественно. С количеством ничего не сделать, это не мы придумываем эти формы. G>Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate.
Они заметно разные.
G>Кроме того можно применить генерацию темплейтов по метаданным. G>Сильно сомневаюсь что даже половину из этих 5 тысяч контролов надо описывать в xaml.
Кое-что там общее, но много различий. Это формы налоговой и страховой отчётности, для всех 50 штатов в США и десятка крупных страховых компаний. Хорошо хоть, что мы купили готовые формы в виде XMLей с описанием полей и таблицы расчёта налогов.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>
G>>>>private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
G>>>>{
G>>>> var slider = sender as Slider;
G>>>> slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
G>>>>}
G>>>>
C>>>А теперь учти, что у тебя оно иногда будет "непередвигаемым", так как некоторые состояния слайдера будут невалидными. G>>Визуально слайдер на эти состояния не попадает. C>Почему? Вполне может. Просто это как раз первая реальная проблема была, с которой я столкнулся. В некоторых случаях модель может быть неконсистентной, и надо приостановить передачу данных до восстановления целостности.
Это уже похоже на выдумывание проблем на ходу.
Зачем модели быть неконсистентной, если нам ничего не стоит постоянно поддерживать её конситентность?
Кстати приведенный мной код, вместе с последним добавлением, полностью решает описанную вами проблему с двумя контролави редактирования бабла и процентов.
Если вы продолжаете считать что WPF не подходит для ваших задач можете попробоавть другую проблему описать, которую вам не удалось решить.
C>А при восстановлении целостности тоже интересные результаты — несколько контролов одновременно могут решить пересчитаться, что вызывает проблемы с зависимостями. И это даже не у одного меня встречается —
Да вот видимо только у вас одно это всречается. Вам Qbit уже написал почему вынос зависимостей во viewmodel помогает.
Вкратце объясняю: у вас не будет бешеных зависимостей между контролами.
G>>>>Мне вас очень жаль ваших пользователей если у вас столько полей в программе. C>>>Не в одной форме, естественно. С количеством ничего не сделать, это не мы придумываем эти формы. G>>Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate. C>Они заметно разные.
Да ну, напишите мне в личку чем отличаются друг от друга все 5000, я даже почитаю.
G>>Кроме того можно применить генерацию темплейтов по метаданным. G>>Сильно сомневаюсь что даже половину из этих 5 тысяч контролов надо описывать в xaml. C>Кое-что там общее, но много различий. Это формы налоговой и страховой отчётности, для всех 50 штатов в США и десятка крупных страховых компаний. Хорошо хоть, что мы купили готовые формы в виде XMLей с описанием полей и таблицы расчёта налогов.
Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы.
Здравствуйте, gandjustas, Вы писали:
C>>Почему? Вполне может. Просто это как раз первая реальная проблема была, с которой я столкнулся. В некоторых случаях модель может быть неконсистентной, и надо приостановить передачу данных до восстановления целостности. G>Это уже похоже на выдумывание проблем на ходу. G>Зачем модели быть неконсистентной, если нам ничего не стоит постоянно поддерживать её конситентность?
Это невозможно. Например, ты редактируешь форму, поправил что-то в одном поле — другое поле ушло в отрицательное значение, что для него невозможно.
Чтобы восстановить положительное значение — тебе надо поправить третье поле. В ряде случаев можно автоматически корректировать третье поле, в ряде случаев нельзя.
Ещё есть шутки с граничными условиями. Например, у нас есть два режима вычисления при значении N ползунка N>50 и N<50. Мы подводим к 49 и из-за округления он устанавливается на 51, а обратное вычисление скидывает его на 50, которое округляется до 49, которое снова устанавливается в 51 и т.д.
G>Кстати приведенный мной код, вместе с последним добавлением, полностью решает описанную вами проблему с двумя контролави редактирования бабла и процентов.
Я её слишком упростил.
G>Если вы продолжаете считать что WPF не подходит для ваших задач можете попробоавть другую проблему описать, которую вам не удалось решить.
Сложно просто модельный пример сделать, где всякие тонкие эффекты видно было бы.
C>>А при восстановлении целостности тоже интересные результаты — несколько контролов одновременно могут решить пересчитаться, что вызывает проблемы с зависимостями. И это даже не у одного меня встречается — G>Да вот видимо только у вас одно это всречается. Вам Qbit уже написал почему вынос зависимостей во viewmodel помогает. G>Вкратце объясняю: у вас не будет бешеных зависимостей между контролами.
А не деться от них никуда. Такие зависимости в формулах.
G>>>Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate. C>>Они заметно разные. G>Да ну, напишите мне в личку чем отличаются друг от друга все 5000, я даже почитаю.
Нет, контролы сами не отличаются. Их там что-то всего штук 10 видов. Отличаются вычисления, привязанные к ним.
Если ты представляешь себе что такое налоговая отчётность, то должно быть понятно.
C>>Кое-что там общее, но много различий. Это формы налоговой и страховой отчётности, для всех 50 штатов в США и десятка крупных страховых компаний. Хорошо хоть, что мы купили готовые формы в виде XMLей с описанием полей и таблицы расчёта налогов. G>Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы.
Так написали. Создать контролы и показать их — это фигня, мелочь. Проблема что с ними дальше делать.
Здравствуйте, Cyberax, Вы писали:
C>Это невозможно. Например, ты редактируешь форму, поправил что-то в одном поле — другое поле ушло в отрицательное значение, что для него невозможно.
В WPF есть ещё такая штука как value coercion. Правила согласования значений можно передать через CoerceValueCallback, afair. И это помимо средств собственно валидации, которыми можешь просто запретить/ограничить неверный ввод.
C>А не деться от них никуда. Такие зависимости в формулах.
Эти зависимости не должны разруливаться в терминах гуёвых контролов. Иначе ты не сможешь заменить морду при необходимости (например, нацепить веб-интерфейс).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Почему? Вполне может. Просто это как раз первая реальная проблема была, с которой я столкнулся. В некоторых случаях модель может быть неконсистентной, и надо приостановить передачу данных до восстановления целостности. G>>Это уже похоже на выдумывание проблем на ходу. G>>Зачем модели быть неконсистентной, если нам ничего не стоит постоянно поддерживать её конситентность? C>Это невозможно. Например, ты редактируешь форму, поправил что-то в одном поле — другое поле ушло в отрицательное значение, что для него невозможно. C>Чтобы восстановить положительное значение — тебе надо поправить третье поле. В ряде случаев можно автоматически корректировать третье поле, в ряде случаев нельзя.
Так не надо валить в кучу валидность и databinding. В wpf эти задачи разделены, есть Binding для связывания, а есть IDataErrorInfo для доставки пользователю информации о валидноси введенных данных.
Вы нарушаете SRP от этого у вас проблемы. WPF тут не при чем.
C>Ещё есть шутки с граничными условиями. Например, у нас есть два режима вычисления при значении N ползунка N>50 и N<50. Мы подводим к 49 и из-за округления он устанавливается на 51, а обратное вычисление скидывает его на 50, которое округляется до 49, которое снова устанавливается в 51 и т.д.
А причем тут интерфейс? Вы и код не сможете написать что бы он так работал, у вас сразу же бесконечный цикл получится.
Короче не надо сказки выдумывать.
G>>Если вы продолжаете считать что WPF не подходит для ваших задач можете попробоавть другую проблему описать, которую вам не удалось решить. C>Сложно просто модельный пример сделать, где всякие тонкие эффекты видно было бы.
Конечно сложно, потому что таких тонкостей, по которые вы сказки рассказываете просто нету, а если есть, то очень легко обходятся.
C>>>А при восстановлении целостности тоже интересные результаты — несколько контролов одновременно могут решить пересчитаться, что вызывает проблемы с зависимостями. И это даже не у одного меня встречается — G>>Да вот видимо только у вас одно это всречается. Вам Qbit уже написал почему вынос зависимостей во viewmodel помогает. G>>Вкратце объясняю: у вас не будет бешеных зависимостей между контролами. C>А не деться от них никуда. Такие зависимости в формулах.
Ну и пусть будут в формулах, интерфейс тут при чем?
Вы пытаетесь все свалить в одну кучу: интерфейс, байндинг, валидацию и еще что-то, а потом геройски боретесь с получившимися проблемами путем создания фреймворков на сотни килобайт кода.
G>>>>Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate. C>>>Они заметно разные. G>>Да ну, напишите мне в личку чем отличаются друг от друга все 5000, я даже почитаю. C>Нет, контролы сами не отличаются. Их там что-то всего штук 10 видов. Отличаются вычисления, привязанные к ним.
Тогда вообще проблем не вижу, делаете наследников абстрактного viewmodel в которых реализуете вычисления и проверки.
C>>>Кое-что там общее, но много различий. Это формы налоговой и страховой отчётности, для всех 50 штатов в США и десятка крупных страховых компаний. Хорошо хоть, что мы купили готовые формы в виде XMLей с описанием полей и таблицы расчёта налогов. G>>Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы. C>Так написали. Создать контролы и показать их — это фигня, мелочь. Проблема что с ними дальше делать.
При нормальном подходе больше ничего с контролами делать не надо, все остальные проблемы ложаться на viewmodel. В которой нету трахов с байндингом, валидацией и прочей мутью.
Здравствуйте, MxKazan, Вы писали:
C>>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>>>Это "счастье" называет MVVM, вы считаете такой подход ненужным? C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. MK>А че бы тогда вообще не перестать использовать ООП. Пиши всё на голом C, на фиг тебе лишнии слои? Ну право, несмешно ведь уже. Ясно видно, что ты не пробовал изменить взгляд на вещи и начать разрабатывать интерфейс приложения по другому: когда логика в одном классе, представление в другом (хотя вроде ссылался на что-то подобное). Только, разрабатывая нечто подобное, можно понять все плюсы этого подхода. Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM. А ты лишний слой... Это как торт из печенки! Можно сделать слоями и всё будет вкусно, а можно накидать превратить всё это в кашу и потушить — тоже есть можно, но уже не то...
Ну всё, пошли стандартные доколупалки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Cyberax, Вы писали:
C>Тебе, куй, вообще говорить что-то бесполезно. Кроме себя ты никого больше не слышишь. Примерно как Шеридан.
Да тут их вообще гнездо! В ответе на этот пост
Здравствуйте, gandjustas, Вы писали:
G>Так не надо валить в кучу валидность и databinding. В wpf эти задачи разделены, есть Binding для связывания, а есть IDataErrorInfo для доставки пользователю информации о валидноси введенных данных. G>Вы нарушаете SRP от этого у вас проблемы. WPF тут не при чем.
Я уж десять раз повторяю, что мне для отдельного контрола байндинг особого смысла не имеет. Нужно делать байндинг на уровне всей формы (или группы форм сразу), с учётом связей и зависимостей.
Как доставить ошибки для рисования — это ТАКАЯ мелочь.
C>>Ещё есть шутки с граничными условиями. Например, у нас есть два режима вычисления при значении N ползунка N>50 и N<50. Мы подводим к 49 и из-за округления он устанавливается на 51, а обратное вычисление скидывает его на 50, которое округляется до 49, которое снова устанавливается в 51 и т.д. G>А причем тут интерфейс? Вы и код не сможете написать что бы он так работал, у вас сразу же бесконечный цикл получится.
Смогу. У меня есть детектор таких циклов (зря ты думаешь оно 180Кб занимает и использует rule engine?) — в этом случае прекращается вычисление всей зацикленной группы контролов и они помечаются как ошибочные.
G>>>Да ну, напишите мне в личку чем отличаются друг от друга все 5000, я даже почитаю. C>>Нет, контролы сами не отличаются. Их там что-то всего штук 10 видов. Отличаются вычисления, привязанные к ним. G>Тогда вообще проблем не вижу, делаете наследников абстрактного viewmodel в которых реализуете вычисления и проверки.
Блиииииинннн.
G>>>Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы. C>>Так написали. Создать контролы и показать их — это фигня, мелочь. Проблема что с ними дальше делать. G>При нормальном подходе больше ничего с контролами делать не надо, все остальные проблемы ложаться на viewmodel. В которой нету трахов с байндингом, валидацией и прочей мутью.
Не, ну ладно. Сделали для каждого контрола поле во viewmodel, которое автоматически синхронизируется с контролом. Причём куча полей будет абсолютно искусственными, так как привязать поле к результату вычисления напрямую — сложно.
И чего мы в итоге добились? Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
Здравствуйте, Cyberax, Вы писали:
C>И чего мы в итоге добились? Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
0_o Так я не понял, у тебя что, имена ещё и литералами задаются? Т. е. компилятор не проверит в compile time корректность имени контрола и его типа? OMFG, facepalm.jpg.
C>Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
Тем, что во втором случае ты не можешь просто заменить одну морду на другую (тестовую/эмулирующую или просто альтернативную), придётся копипастить и править логику представления — ведь она у тебя прямо завязана на контролы. Ты даже не можешь без приключений переименовать контрол, потому что это придётся делать не с помощью синтаксического анализатора, а с помощью небезопасного лексического (тупой поиск строки в текстовых литералах). Не говоря уже о том, что ViewModel.UserAge куда выразительнее отражает идею, чем int.parse(getControl("userNameTextBox").getText()).
почти все отметились Q>О, CreatorCray, а ты здесь какими судьбами? Уже решил на C++ задачку с фильтрацией строк файла?
А вот и еще птенец из гнезда подтянулся.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Qbit86, Вы писали:
Q>0_o Так я не понял, у тебя что, имена ещё и литералами задаются? Т. е. компилятор не проверит в compile time корректность имени контрола и его типа? OMFG, facepalm.jpg. C>>Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
Они задаются аннотациями в скриптах, но это мелочи. Контроля компилятора нет, есть специальная утиллита проверки.
Q>Тем, что во втором случае ты не можешь просто заменить одну морду на другую (тестовую/эмулирующую или просто альтернативную), придётся копипастить и править логику представления — ведь она у тебя прямо завязана на контролы. Ты даже не можешь без приключений переименовать контрол, потому что это придётся делать не с помощью синтаксического анализатора, а с помощью небезопасного лексического (тупой поиск строки в текстовых литералах). Не говоря уже о том, что ViewModel.UserAge куда выразительнее отражает идею, чем int.parse(getControl("userNameTextBox").getText()).
Чем? У меня НЕТ поля ViewModel.UserAge в модели данных. Грубо говоря, у меня есть DataModel.DateOfBirth, которую надо привязать к контролу с возрастом. Как ты это будешь делать?
У меня это ровно одна строчка кода типа: "context.DateOfBirth <[coerceYear[context.Now().subtract(_1.millis)]]> controls.someform.UserAge". Считай, что метод CalculateAge у тебя есть.
Здравствуйте, ambel-vlad, Вы писали:
MK>>Амбил-Влад, тебе помочь расставить плюсо-минусы AV>Нда, не знал, что у тебя еще и с глазами проблемы.
Мне думается, коллега, что это наступление весны вызывает сезонное обострение у тех, кто любит покидаться какашками на форумах.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Cyberax, Вы писали:
C>Чем? У меня НЕТ поля ViewModel.UserAge в модели данных.
В модели данных его и не должно быть, очевидно.
C>Грубо говоря, у меня есть DataModel.DateOfBirth, которую надо привязать к контролу с возрастом. Как ты это будешь делать?
А какие проблемы? Во ViewModel может быть как возраст, так дата рождения, в зависимости от того, что удобнее, и что лучше отражает представление (ViewModel — модель представления, а не представление модели).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Так не надо валить в кучу валидность и databinding. В wpf эти задачи разделены, есть Binding для связывания, а есть IDataErrorInfo для доставки пользователю информации о валидноси введенных данных. G>>Вы нарушаете SRP от этого у вас проблемы. WPF тут не при чем. C>Я уж десять раз повторяю, что мне для отдельного контрола байндинг особого смысла не имеет. Нужно делать байндинг на уровне всей формы (или группы форм сразу), с учётом связей и зависимостей.
Нут так это и есть viewmodel.
C>>>Ещё есть шутки с граничными условиями. Например, у нас есть два режима вычисления при значении N ползунка N>50 и N<50. Мы подводим к 49 и из-за округления он устанавливается на 51, а обратное вычисление скидывает его на 50, которое округляется до 49, которое снова устанавливается в 51 и т.д. G>>А причем тут интерфейс? Вы и код не сможете написать что бы он так работал, у вас сразу же бесконечный цикл получится. C>Смогу. У меня есть детектор таких циклов (зря ты думаешь оно 180Кб занимает и использует rule engine?) — в этом случае прекращается вычисление всей зацикленной группы контролов и они помечаются как ошибочные.
Так пусть он этим в коде и занимается, причем тут UI и контролы?
G>>>>Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы. C>>>Так написали. Создать контролы и показать их — это фигня, мелочь. Проблема что с ними дальше делать. G>>При нормальном подходе больше ничего с контролами делать не надо, все остальные проблемы ложаться на viewmodel. В которой нету трахов с байндингом, валидацией и прочей мутью. C>Не, ну ладно. Сделали для каждого контрола поле во viewmodel, которое автоматически синхронизируется с контролом. Причём куча полей будет абсолютно искусственными, так как привязать поле к результату вычисления напрямую — сложно.
Ну так правильно, ваш vewmodel становится контейнером всей сложной логики, вам тогда вообще пофигу становится вся работа с UI.
Это же прекрасно.
C>И чего мы в итоге добились? Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
myViemodel.name типизировано гораздо сильнее, чем getControl("controlName").getText().
Кроме того myViemodel.name очень легко покрыть тестами, а getControl и все что через него делается — нереально.
Здравствуйте, Cyberax, Вы писали:
Q>>Тем, что во втором случае ты не можешь просто заменить одну морду на другую (тестовую/эмулирующую или просто альтернативную), придётся копипастить и править логику представления — ведь она у тебя прямо завязана на контролы. Ты даже не можешь без приключений переименовать контрол, потому что это придётся делать не с помощью синтаксического анализатора, а с помощью небезопасного лексического (тупой поиск строки в текстовых литералах). Не говоря уже о том, что ViewModel.UserAge куда выразительнее отражает идею, чем int.parse(getControl("userNameTextBox").getText()). C>Чем? У меня НЕТ поля ViewModel.UserAge в модели данных. Грубо говоря, у меня есть DataModel.DateOfBirth, которую надо привязать к контролу с возрастом. Как ты это будешь делать?
А кто сказал что такое поле должно быть в модели данных?
MVVM, как и MVP и MVC создаются чтобы абстрагировать UI от модели данных и логики работы с ними.
Здравствуйте, ambel-vlad, Вы писали:
AV>Да перестал уже различать людей
То, что я отвечаю на постинг CreatorCray не означает, что я в нем не могу обращаться к другим людям. Заметь, плюсик то ты поставил. Это именно то, что я имел ввиду
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, VladD2, Вы писали:
VD>>Если бы вы перевели его скажем на Немерле или F# (с умом), то он бы стал еще более лаконичным и читабельным (раз эдак в 5). O>Ну так переведи вышепроцитированный код на немерле или f#, а мы поаппладируем в восхищении!
Вот этот что ли:
class SomeClass<T>
{
public T Property1 { get; set; }
public T Property2 { get; set; }
}
var someClass = new SomeClass<string>
{
Property1 = "some string",
ListProperty = { "string1", "string2" }
};
?
Он слшком примитивен, чтобы на нем получить серьезный выигрышь. К тому же он не несет смысловой нагрузки. Так что тяжело понять задачу.
К тому же код откровенно ошибочен. Что за ListProperty? И где Property2?
Подозреваю, что имелось в виду что-то вроде:
class SomeClass<T>
{
public T Property1 { get; set; }
public List<T> ListProperty { get; set; }
}
var someClass = new SomeClass<string>
{
Property1 = "some string",
ListProperty = { "string1", "string2" }
};
Могу предложить два вариата. Первый чисто синтаксические улучшения:
[Record] // этот макрос создает конструктор который инициализирует все члены классаclass SomeClass[T]
{
public Property1 : T { get; private set; }
public ListProperty : list[T] { get; private set; }
}
def someClass = SomeClass("some string", ["string1", "string2"]);
Уже имеем выигрыш в 4 строки плюс SomeClass стал неизменяемой структурой данных, что упростит отладку и увеличит надежность кода.
Другой вариант вместо класса использовать вариантный тип. Такой вариант подходит когда нужно описать некие связанные сущности (аля иерархия классов):
[Record] // этот макрос создает конструктор который инициализирует все члены класса
variant SomeVariant[T]
{
| SomeVariantOption1 { data : T; listData : list[T]; }
| другие вхождения
}
def some = SomeVariant.SomeVariantOption1("some string", ["string1", "string2"]);
[/c#]
Далее варианты можно распознавать с помощью мощьного оператора match:
match (some)
{
| SomeVariantOption1(data, ["string1", "string2"]) => что-то делаем... в data значение поля "data".
| _ => обработка не распознанных вариантов...
}
Обрати внимание. Указывать параметры типов не нужно во все. А мощность оператора match настолько велика, что он позволяет распознавать сложные иерархии объектов.
В купе с другими фичами языка это позволят сокращать код от двх, до десятков раз.
И это только возможности языка. А если к ним прибавить возможности макросов, то можно достигнуть многократного приемущества. Так ты можешь просто создать совой ДСЛ и описать логику на нем. А макросы сгенерируют оптимальный код реализации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Могу предложить два вариата. Первый чисто синтаксические улучшения: VD>
VD>[Record] // этот макрос создает конструктор который инициализирует все члены класса
VD>class SomeClass[T]
VD>{
VD> public Property1 : T { get; private set; }
VD> public ListProperty : list[T] { get; private set; }
VD>}
VD>def someClass = SomeClass("some string", ["string1", "string2"]);
VD>
VD>Уже имеем выигрыш в 4 строки плюс SomeClass стал неизменяемой структурой данных, что упростит отладку и увеличит надежность кода.
Так это не правильно. Во-первых, в оригинале нет никакого конструктора (кроме по-умолчанию). Во-вторых, а что произойдет, если свойств не 2, а 20 или 40? Ну и наконец нечитабельно ведь — надо смотреть на сигнатуру этого конструктора, которой у нас, собственно, ведь нету в design time.
VD>Другой вариант вместо класса использовать вариантный тип. Такой вариант подходит когда нужно описать некие связанные сущности (аля иерархия классов):
VD>[Record] // этот макрос создает конструктор который инициализирует все члены класса VD>variant SomeVariant[T] VD>{ VD> | SomeVariantOption1 { data : T; listData : list[T]; } VD> | другие вхождения VD>}
VD>def some = SomeVariant.SomeVariantOption1("some string", ["string1", "string2"]); VD>[/c#]
Интересно.. а что нам дает такая конструкция? Можно чуть подробнее?
VD>Далее варианты можно распознавать с помощью мощьного оператора match: VD>
VD>match (some)
VD>{
VD> | SomeVariantOption1(data, ["string1", "string2"]) => что-то делаем... в data значение поля "data".
VD> | _ => обработка не распознанных вариантов...
VD>}
VD>
VD>Обрати внимание. Указывать параметры типов не нужно во все. А мощность оператора match настолько велика, что он позволяет распознавать сложные иерархии объектов.
Да, это полезно.
VD>В купе с другими фичами языка это позволят сокращать код от двх, до десятков раз.
Здравствуйте, criosray, Вы писали:
VD>>Уже имеем выигрыш в 4 строки плюс SomeClass стал неизменяемой структурой данных, что упростит отладку и увеличит надежность кода.
Кстати, по поводу выигрыша по строками на таком простом примере выигрывает все-таки С#:
1 class SomeClass<T>
2 {
3 public T Property1 { get; set; }
4 public List<T> ListProperty { get; set; }
5 }
6 var someClass = new SomeClass<string> { Property1 = "some string", ListProperty = { "string1", "string2" }};
против
1 [Record] // этот макрос создает конструктор который инициализирует все члены класса
2 class SomeClass[T]
3 {
4 public Property1 : T { get; private set; }
5 public ListProperty : list[T] { get; private set; }
6 }
. Главное что бы эта туша сломала тренд ресурсо-пожирания.
