Здравствуйте, 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 в одном процессе.

А этого никто и не обещал.

Здравствуйте, criosray, Вы писали:

c> Сравним (кратко):
c> C# 3

c>

c> class SomeClass<T>
c> {
c>    public T Property1 { get; set; }
c>    public T Property2 { get; set; }
c> }
c>

А нельзя просто:

class SomeClass<T>
{
    public T Property1;
    public T Property2;
}

?

Здравствуйте, vit.rsdn, Вы писали:

v> кстати, можете провести сравнительный анализ и указать, чем Django лучше, чем ряд этих готовых сайтов http://www.asp.net/community/projects/ или вот этих http://www.codeplex.com/site/search?projectSearchText=portal&sortBy=Relevance&licenses=| (более многочисленных)?

Вопрос был в том, какие средства предоставляет питон в сравнении с RoR и про ORM.
А если сравнивать сайты по количеству, то PHP порвет всех.

v> для особых любителей питона, можно и под дотнет Django запустить Microsoft shows Django running on IronPython

А зачем плодить лишние сущности?

Здравствуйте, gandjustas, Вы писали:

g> Вы так говорите как-будто mono не существует
g> Не надо выдавать желаемое за действительное.

Он существует, но как Неуловимый Джо. Вроде и есть, но мало кому нужен. Связано это как с большими рисками в отношении лицензионной политики MS (фиг знает, что им придет завтра в голову), так и с отсутствием реальной кросс-платформенности.

Здравствуйте, Константин Б., Вы писали:
КБ>А какие сложности нас подстерегают на этом пути?
Как это какие?
Элементарные сложности: где-то берем и меняем определение этих "анонимных данных". Например, вставили в [0] поле "Title", после которого пойдут FirstName и LastName, которые раньше были 0-м и 1-м. Весь код, построенный на индексах, поедет.
К примеру, что код, который формирует строку обращения к персоне, не хочется писать вот так:

string FullName(DataRow dr)
{
  return string.Format("{0} {1} {2} {3}", dr[22], dr[0], dr[2], dr[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 решится всерьез профинансировать моно, то джаву это убъет.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, gandjustas, Вы писали:

G>>>>Нет, я по меньшему колчичеству сайтов хожу.
C>>>Ну назовите сколько можете.
G>>http://www.ieaddons.com/en/webslices/?index=36&sort=Views&lang=en&browse=true
G>>Для начала думаю хватит.
CC>Не, не хватит.
CC>Что нить не микрософтовского авторства, пжалста.

А они там и так не микрософтовского авторства.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Константин Б., Вы писали:
КБ>>А какие сложности нас подстерегают на этом пути?
S>Как это какие?
S>Элементарные сложности: где-то берем и меняем определение этих "анонимных данных". Например, вставили в [0] поле "Title", после которого пойдут FirstName и LastName, которые раньше были 0-м и 1-м. Весь код, построенный на индексах, поедет.

S>К примеру, что код, который формирует строку обращения к персоне, не хочется писать вот так:
S>

S>string FullName(DataRow dr)
S>{
S>  return string.Format("{0} {1} {2} {3}", dr[22], dr[0], dr[2], dr[1])
S>}
S>

Ага, понятно. В таких случаях лучше использовать Dictionary.

def FullName(title, firstname, middlename, lastname, **otherparams):
   return "%s %s %s %s" % (title, firstname, middlename, lastname)

# и при вызове
person = {"title":"Mr.", "firstname":"Jhon", "middlename":"J", "lastname":"Smith", "other_data":42}
print FullName(**person)

Здравствуйте, Константин Б., Вы писали:
КБ>Ага, понятно. В таких случаях лучше использовать Dictionary.
Ок, то есть вопрос пригодности кортежей для работы с данными можно считать закрытым, так?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Константин Б., Вы писали:
КБ>>Ага, понятно. В таких случаях лучше использовать Dictionary.
S>Ок, то есть вопрос пригодности кортежей для работы с данными можно считать закрытым, так?

Можно. Вообще тут больше обсуждался вопрос необходимости объектов и ORM.

G>А что вы удивляетесь. Такой подход среди "приплюснутых" программистов встречается очень часто. Понавыдумывают себе проблем и геройски их решают с помощью C++. А самые продвинутые в С++ даже не знают что эти проблемы уже решены кучей других способов кроме написания своего кроссплатформенного фреймворка.

Если ты такой умный, можешь просветишь нас, как правильно решать проблемы?

Хочу заметить: речь идет о проекте, который был сдан в срок, и уже продается.

Здравствуйте, Sinclair, Вы писали:

S>Пока что всё что я видел — это быстрое построение приложений в стиле "универсальный редактор DBF-файлов". К сожалению, приложения этого типа я закончил писать (для десктопа) примерно году в 1994 — разочаровался в концепции. То, что сейчас dbedit сумели засунуть в веб, меня нисколько не возбуждает.

Какой зоопарк сущностей из разных языков уже наплодили:
A#, C#, F#, J#, Sing#, Spec#, X#, и это только начало...

Читая эти форумы, у меня складывается такое ложное впечатление, что профессия программиста будто бы стремительно превращается в профессию филолога-лингвиста. Хотя это далеко не так. Конечно, базы данных и создание кнопочек на формах филологи-лингвисты ещё кое-как осилят, но а вот что касается сложных математических алгоритмов — то есть большие сомнения.

По-моему важно уметь эффективно программировать хотя бы на одном распространенном языке, а не бессмысленно изучать по 15 штук, и превращаться в языковеда, вместо того чтобы больше внимания уделить проектированию, прикладной математике. Ведь программирование — это в первую очередь прикладная математика, а не лингвистика. Кстати, именно поэтому Intel делает ставку на C++ и Фортран.

Фортран широко используется в первую очередь для научных и инженерных вычислений. Одно из преимуществ современного Фортрана — большое количество написанных на нём программ и библиотек подпрограмм. Среди учёных, например, ходит такая присказка, что любая математическая задача уже имеет решение на Фортране, и, действительно, можно найти среди тысяч фортрановских пакетов и пакет для перемножения матриц, и пакет для решения сложных интегральных уравнений, и многие, многие другие. Ряд таких пакетов создавались на протяжении десятилетий и популярны (главным образом в научной среде) по сей день.

С++ интересен огромным числом библиотек. Распространенность, кроссплатформенность, гибкость и мощь языка привлекает большое число серьёзных программистов. С++ де-факто представляет собой промышленный стандарт. Содержит средства создания эффективных программ практически любого назначения, от низкоуровневых утилит и драйверов до сложных программных комплексов. Поддерживает различные стили и технологии программирования, включая традиционное директивное программирование, ООП. Имеется возможность работы на низком уровне с памятью, адресами, портами. Доступны компиляторы для большого количества платформ. Язык спроектирован так, чтобы дать программисту максимальный контроль над всеми аспектами структуры и порядка исполнения программы.