Спустя восемь лет

← →
Marser © (2010-09-03 18:48) [0]

Благодаря тегу "нервический смех" и нику автора мне удалось выудить у Хайяма сказочный артефакт - обсуждение здесь .NET восемь лет назад. По-моему, очень даже забавно :-)

http://delphimaster.net/view/14-15267

← →
Marser © (2010-09-03 18:55) [1]

Мой камент в сабжевой ветке уныл чуть менее, чем полностью, зато уже через два года я участвовал в гораздо более интересном обсуждении :-)
С Deep"ом, Пашей-Маразматиком и Mystic"ом мы обсуждали будущее программирования и я, тогда уже практикующий (после пар, третий курс) падаван не мог поверить в слова этих мудрых джедаев, что виртуальные машины зохавают всех, кричал, что с нейтивных компиляторов уйду в ембеддед (там-де VM не будет)...
Прошло ещё три года и я обнаружил себя в стане .NET, где обретаюсь уже два года...

← →
Дмитрий Белькевич (2010-09-03 19:42) [2]

Жалко только, что ничего революционного из .net так и не получилось. Мегабайты лишней энтропии - ничего более.

← →
Германн © (2010-09-03 19:50) [3]

Вскоре после этого Romkin ушёл на "исходники". С чего бы это?
:)

← →
Pavia © (2010-09-03 19:55) [4]

> Мегабайты

А у меня почему то гигабайты.

← →
Marser © (2010-09-03 20:42) [5]

> Дмитрий Белькевич (03.09.10 19:42) [2]
>
> Жалко только, что ничего революционного из .net так и не
> получилось. Мегабайты лишней энтропии - ничего более.

О, а что революционного ждал мсье от .NET? :-)

← →
Кто б сомневался © (2010-09-03 20:49) [6]

Скоро выйдет новый язык от MS - Axum. Улучшенный C#. Ждите он уже анонсирован.
И опять придется перебегать.

← →
Marser © (2010-09-03 20:55) [7]

А разве перебегать это какая-то проблема? :)

← →
antonn © (2010-09-03 21:02) [8]

> Германн © (03.09.10 19:50) [3]
>
> Вскоре после этого Romkin ушёл на "исходники". С чего бы
> это?
> :)
>

я бы не сказал что "вскоре", в базе 2005-2006 довольно много его постов

← →
AlexDn © (2010-09-03 21:17) [9]

Как в песне, "..и Игорь Шевченко, такой молодой":))

← →
Кто б сомневался © (2010-09-03 21:27) [10]

> Marser © (03.09.10 20:55) [7]

По факту это новый язык, со своими ньюансами.
Если решено переходить то те у кого свое дело, придется нанимать новых людей, или переучивать старых, - те кто один - переучиваться самому. А это немалые расходы и время с пол года - год минимум (на опыт работы с IDE и языком).
А так проблем нет конечно...

← →
DVM © (2010-09-03 21:31) [11]

> Кто б сомневался ©

Это язык специальный, для параллельного программирования. Очень похож на C#. C# пришел надолго. MS некоторые свои продукты переписала на нем, это показатель.

← →
antonn © (2010-09-03 21:38) [12]

> AlexDn © (03.09.10 21:17) [9]
>
> Как в песне, "..и Игорь Шевченко, такой молодой":))

И вновь начинается бой, И сердцу тревожно в грудииии... И Игооорь такой молодой, и юный октябрь впереди!
=)

классная песня, мне в таком исполнении нравится http://antonn.com/media_host/index.php?play=zz_koms19.mp3

← →
Marser © (2010-09-03 21:39) [13]

> DVM © (03.09.10 21:31) [11]
>
>
> > Кто б сомневался ©
>
> Это язык специальный, для параллельного программирования.
> Очень похож на C#. C# пришел надолго. MS некоторые свои
> продукты переписала на нем, это показатель.

Вот именно.
Тем не менее, скорую смерть ему пророчат всю дорогу. При этом напирают на "вечные ценности", коими называют Плюсы и почему-то Джаву :-)

А я могу только вздохнуть по поводу того предубеждения, что было у меня против Шарпа. Если бы не оно, я бы ушёл со старой работы намного раньше. Может, недобрал бы интересного опыта, зато и нервов сохранил бы...

← →
Старый маразматик (2010-09-03 22:12) [14]

> было у меня против Шарпа

прошу прощения, а это что такое за зверь? и, я никогда не кричал, что машины всех захавают, это ошибка! более того, я бы даже сказал, глубокая заблуждения! я стока не выпью, хотя на здоровье не жалуюсь, звыняйте.
второе пришествие шварцнэгира. гыгы

зы. > Marser дарова

← →
Inovet © (2010-09-03 22:14) [15]

> [12] antonn © (03.09.10 21:38)
> классная песня, мне в таком исполнении нравится

А в таком Егора Летова - это он без всякого стёба
http://redmusic.ucoz.ru/load/0-0-0-90-20
Тут видео а исполнение и звук совсем хуже
http://www.youtube.com/watch?v=tk1dyKGwYB8

← →
Псалтырь © (2010-09-04 00:46) [16]

> Старый маразматик (03.09.10 22:12) [14]

13 сентября. Семинар. Я буду. И Пашка Голубь. Не пропустить. Задача.

← →
Старый маразматик (2010-09-04 03:51) [17]

> Псалтырь © (04.09.10 00:46) [16]

в понедельник? 13? ужос. а шо за семинар, по #?
короче, ломись сюдой 280037410, я машину выключать не буду на выходные. к тезке я в аську достучаться не могу, у него антиспам, а я, как назло, забыл "какая оббревиатура у Союза Советских Социалистических Республик".

зы. звыняйте за оффтоп

← →
Копир © (2010-09-04 05:09) [18]

Удалено модератором

← →
AlexDn © (2010-09-04 06:34) [19]

Удалено модератором

← →
Alkid © (2010-09-04 11:24) [20]

> Кто б сомневался © (03.09.10 20:49) [6]
> Скоро выйдет новый язык от MS - Axum. Улучшенный C#. Ждите
> он уже анонсирован.
> И опять придется перебегать.

Это исследовательский язык. Вряд ли они его выпустят as-is. Скорее всего его фитчи появятся в C# в будущем.

← →
Alkid © (2010-09-04 11:28) [21]

> Marser © (03.09.10 21:39) [13]
> Вот именно.
> Тем не менее, скорую смерть ему пророчат всю дорогу. При
> этом напирают на "вечные ценности", коими называют Плюсы
> и почему-то Джаву :-)

Кстати, Плюсы уже не столь вечны и ценны :) Сейчас наблюдается некий ренессанс unmanaged языков, ориентированных на ту же нишу, что и C++.

← →
Marser © (2010-09-04 14:56) [22]

> Старый маразматик (03.09.10 22:12) [14]
>
>
> > было у меня против Шарпа
>
>
> прошу прощения, а это что такое за зверь? и, я никогда не
> кричал, что машины всех захавают, это ошибка! более того,
> я бы даже сказал, глубокая заблуждения! я стока не выпью,
> хотя на здоровье не жалуюсь, звыняйте.
> второе пришествие шварцнэгира. гыгы
>
> зы. > Marser дарова

Привет :-)
Ну я не ручаюсь, что ты тоже настаивал, но Витя по этому поводу точно напирал :-)

> Псалтырь © (04.09.10 00:46) [16]
>
>
> > Старый маразматик (03.09.10 22:12) [14]
>
> 13 сентября. Семинар. Я буду. И Пашка Голубь. Не пропустить.
> Задача

А ты кто? :-)
Вроде знаю... :-)

>
> Кстати, Плюсы уже не столь вечны и ценны :) Сейчас наблюдается
> некий ренессанс unmanaged языков, ориентированных на ту
> же нишу, что и C++.

Щас функциональное программирование входит в моду, а managed или нет, я не вникал пока :-)

← →
Компромисс (2010-09-04 15:05) [23]

> Marser © (03.09.10 20:55) [7]
> А разве перебегать это какая-то проблема? :)
> <Цитата>

Конечно, проблема. Не в изучении синтаксиса, разумеется. В изучении стандартных классов и сторонних библиотек.

← →
jack128_ (2010-09-04 17:53) [24]

> Сейчас наблюдается некий ренессанс unmanaged языков, ориентированных
> на ту же нишу, что и C++.

например? какие языки?

← →
Alkid © (2010-09-04 19:03) [25]

> jack128_ (04.09.10 17:53) [24]
> например? какие языки?

D, Go, Rust

← →
Alkid © (2010-09-04 19:05) [26]

> Компромисс (04.09.10 15:05) [23]
> Конечно, проблема. Не в изучении синтаксиса, разумеется.
> В изучении стандартных классов и сторонних библиотек.

Ну-ка перебеги мне с Delphi на Prolog :)
Я посмотрю, сколько у тебя времени уйдет на понимание... синтаксиса.... :)

← →
Kerk © (2010-09-04 19:13) [27]

> Alkid © (04.09.10 19:05) [26]

Вот уж у пролога синтаксис крайне примитивный.
Но толку-то? :)
Чтобы хорошо играть в шахматы, не достаточно знать как хотят фигуры :)

← →
Alkid © (2010-09-04 19:52) [28]

> Kerk © (04.09.10 19:13) [27]
> Вот уж у пролога синтаксис крайне примитивный.
> Но толку-то? :)
> Чтобы хорошо играть в шахматы, не достаточно знать как хотят
> фигуры :)

Вот именно :) Правила шахмат учатся моментально, а играть можно всю жизнь учиться :) Просто люди, которые утверждают, что другой язык изучить - это дело двух недель (дескать синтаксис другой, а так все такое же), видимо не знают о том, что есть разные парадигмы.

← →
Компромисс (2010-09-04 20:32) [29]

Alkid © (04.09.10 19:52) [28]

> Просто люди, которые утверждают, что другой язык изучить
> - это дело двух недель (дескать синтаксис другой, а так
> все такое же), видимо не знают о том, что есть разные парадигмы.
>

Нет, эти люди зарабатывали деньги, делая лабы другим студентам за деньги и по прологу, и по лиспу, так что представление имеют о существовании процедурных, логическиз и функциональных языков.
Имеют они и опыт перехода с SQL на Delphi, с Delphi на Java и с Java на Flex. Повторяю еще раз: синтаксис - фигня, а вот на изучение классов и API уходит очень много времени и сил.

← →
Marser © (2010-09-04 20:46) [30]

> Alkid © (04.09.10 19:52) [28]
>
>
> > Kerk © (04.09.10 19:13) [27]
> > Вот уж у пролога синтаксис крайне примитивный.
> > Но толку-то? :)
> > Чтобы хорошо играть в шахматы, не достаточно знать как
> хотят
> > фигуры :)
>
> Вот именно :) Правила шахмат учатся моментально, а играть
> можно всю жизнь учиться :) Просто люди, которые утверждают,
> что другой язык изучить - это дело двух недель (дескать
> синтаксис другой, а так все такое же), видимо не знают о
> том, что есть разные парадигмы.

Необязательно :-)
Я вот о парадигмах в курсе. А ещё я знаю, что магические буквы OOD сейчас в моде, а они указывают на вполне конкретную парадигму ;-)

← →
картман © (2010-09-04 22:38) [31]

переход на другой язык. А он нужен - переход? Зачем тратить время на изучение уже знакомых классов, парадигм и т.д.? В одной из своих статей э-эх, автора забыл(участвовал в создании экселя. Пива надо меньше пить) говорил об этом - пока мы изучаем очередную фиговину от микрософт, те придумывают следующую, а мы на месте.
Потому да, изучить новый язык - проблема. Проблема потерянного времени.

← →
картман © (2010-09-04 22:39) [32]

вспомнил - Джоэл Спольски.

← →
Marser © (2010-09-04 22:44) [33]

Правильно :-)
Лучше всего нанять студентов и давать им клепать сайты :-)

← →
картман © (2010-09-05 00:13) [34]

я не совсем о том. Нужно ли Шумахеру учить карты всех городов мира(Москвы, хотя бы - поперек я быстрее его пересеку город. Что, я лучше?) или нужно учиться ездить еще круче? Микрософты заставляют нас учить никому ненужные карты под видом очередной супервсёрешающей технологии.

← →
Германн © (2010-09-05 00:45) [35]

> В одной из своих статей э-эх, автора забыл(участвовал в
> создании экселя. Пива надо меньше пить) говорил об этом

Шедевр!
:)

← →
картман © (2010-09-05 01:34) [36]

> Германн © (05.09.10 00:45) [35]

я старался - день города, как-никак)

да-а, ща перечитал))

← →
Alkid © (2010-09-05 10:39) [37]

> картман © (05.09.10 00:13) [34]
> Микрософты заставляют нас учить никому ненужные карты под видом очередной
> супервсёрешающей технологии.

"Микрософты" нас делать ничего не заставляют :)

← →
Marser © (2010-09-05 11:58) [38]

> Потому да, изучить новый язык - проблема. Проблема потерянного
> времени.

А ещё кто-то говорил, что программисту постоянно надо учиться, потому им и платят так хорошо ;-)

← →
Компромисс (2010-09-05 15:10) [39]

Многим врачам тоже надо постоянно учиться, но платят им в наших странах гораздо меньше. ИМХО местные цены на программистов опеределяются мировыми ценами на программистов, в этом основная причина.

← →
Старый маразматик (2010-09-05 17:39) [40]

> Многим врачам тоже надо постоянно учиться

дабы дольше получить на лапу. а которые не учатся - тем не дают.

← →
Alkid © (2010-09-05 19:38) [41]

> Компромисс (04.09.10 20:32) [29]
> Нет, эти люди зарабатывали деньги, делая лабы другим студентам
> за деньги и по прологу, и по лиспу, так что представление
> имеют о существовании процедурных, логическиз и функциональных
> языков.
> Имеют они и опыт перехода с SQL на Delphi, с Delphi на Java
> и с Java на Flex.

Тогда надо оговариваться, что не просто "другой язык программирования", а "в пределах известных парадигм". Что бы новую парадигму освоить иногда надо голову поломать.

← →
Alkid © (2010-09-05 19:39) [42]

> Marser © (04.09.10 20:46) [30]
> Необязательно :-)
> Я вот о парадигмах в курсе. А ещё я знаю, что магические
> буквы OOD сейчас в моде, а они указывают на вполне конкретную
> парадигму ;-)

Ну, эпоха OOD как "единственно верной идеологии" уже прошли. Её распробовали, поняли, что это не серебряная пуля и пошли дальше.
Сейчас, например, ФП набирает силу.

← →
Компромисс (2010-09-05 19:57) [43]

Alkid © (05.09.10 19:38) [41]

Тогда надо оговариваться, что не просто "другой язык программирования", а "в пределах известных парадигм". Что бы новую парадигму освоить иногда надо голову поломать.

Извините, все равно не согласен, парадигма осваивается за день-два, неделя максимум. У человека так мозг устроен, что понять и запомнить одну даже очень трудную вещь гораздо легче, чем 20, пусть и простых вещей. Почему для каждого языка требуется опыт от года и более? Потому что только за это время человек начинает более-менее ориентироваться в классах и выбирает наилучший способ решения проблемы без излишних исследований, даже если задача для него новая

← →
Rouse_ © (2010-09-05 22:20) [44]

А чего забавно то? :) Что есть такое ".Net" Ромыч озвучил восемь лет назад, так это и теперь актуально, даже в африке :)

← →
Marser © (2010-09-05 23:54) [45]

> Alkid © (05.09.10 19:39) [42]
>
>
> > Marser © (04.09.10 20:46) [30]
> > Необязательно :-)
> > Я вот о парадигмах в курсе. А ещё я знаю, что магические
> > буквы OOD сейчас в моде, а они указывают на вполне конкретную
> > парадигму ;-)
>
> Ну, эпоха OOD как "единственно верной идеологии" уже прошли.
> Её распробовали, поняли, что это не серебряная пуля и пошли
> дальше.
> Сейчас, например, ФП набирает силу.

Читать как "сейчас, например, ФП с 0.01% решений поднялось до 0.1% решений - OOD уходит, не серебряная пуля". Эдакий программистский вендекапец ;-)

← →
Marser © (2010-09-05 23:56) [46]

> Rouse_ © (05.09.10 22:20) [44]
>
> А чего забавно то? :) Что есть такое ".Net" Ромыч озвучил
> восемь лет назад, так это и теперь актуально, даже в африке
> :)

Тебе не смешно, не читай :-)
А то скажу что-то очевидное, ещё обидишься :-)

← →
Rouse_ © (2010-09-05 23:57) [47]

> Marser © (05.09.10 23:56) [46]

Излагай :)

← →
Marser © (2010-09-06 00:03) [48]

> Rouse_ © (05.09.10 23:57) [47]
>
>
> > Marser © (05.09.10 23:56) [46]
>
> Излагай :)

Ну победил .NET, победил :-)
Delphi существует в считанных решениях. И даже систему, над которой я работал 3.5 года, переводят с Delphi на C#...

← →
Rouse_ © (2010-09-06 00:15) [49]

Когда он будет заявлен на всех платформах (он-же кросс платформенный) тогда и стоит делать такое заявление. А пока что уныл он, медленный, незащищенный ну и до кучи не требующий высокой квалификации :) Для домохозяек пойдет :)

← →
6x8 (2010-09-06 05:01) [50]

> Rouse_ © (06.09.10 00:15) [49]
>
> Когда он будет заявлен на всех платформах (он-же кросс платформенный)
> тогда и стоит делать такое заявление. А пока что уныл он,
> медленный, незащищенный ну и до кучи не требующий высокой
> квалификации :) Для домохозяек пойдет :)

http://www.rsdn.ru/article/devtools/perftest3.xml

← →
6x8 (2010-09-06 05:03) [51]

> А пока что уныл он,
> > медленный, незащищенный ну и до кучи не требующий высокой
> > квалификации :) Для домохозяек пойдет :)

Это Вы о Delphi?

← →
Alkid © (2010-09-06 09:49) [52]

> Компромисс (05.09.10 19:57) [43]
> Извините, все равно не согласен, парадигма осваивается за
> день-два, неделя максимум.

Категорически не верю :)
Нет, я допускаю, что ты гений и у тебя действительно это всего лишь неделю занимает, но мой опыт говорит о том, что людям сложно осваивать альтернативные парадигмы. Большинство программистов существуют в рамках одной - полутора парадигм и неохотно воспринимают альтернативы. Причины этого явления - это отдельная, очень интересная история.

← →
Alkid © (2010-09-06 09:54) [53]

> Marser © (05.09.10 23:54) [45]
> Читать как "сейчас, например, ФП с 0.01% решений поднялось
> до 0.1% решений - OOD уходит, не серебряная пуля". Эдакий
> программистский вендекапец ;-)

Нет, я не говорил, что будет "ООПкапец", его не будет. Так же как пока не наступил "процедурный капец", которого тоже не будет. Парадигма - это инструмент, который имеет свою область применения. Проблемы с парадигмой начинаются тогда, когда её пытаются распространить на все, сделать универсальным решением. С ООD эта история приключилась, оно одно время было просто идолищем поганым, объектом карго-культа среди разработчиков. Так вот, я говорю лишь о том, что проходит это неоправданное очарование OOD.

← →
Alkid © (2010-09-06 09:56) [54]

> Rouse_ © (06.09.10 00:15) [49]
> Когда он будет заявлен на всех платформах (он-же кросс платформенный)
> тогда и стоит делать такое заявление. А пока что уныл он,
> медленный, незащищенный ну и до кучи не требующий высокой
> квалификации :) Для домохозяек пойдет :)

Сколько пафоса :)
Ну ладно медленный, ну ладно незащищенный... но квалификация??? :)
Я ж столько наслушался воплей (особенно от С++-сообщества) о том, что .NET "слишком простой" и теперь настало время "студентов-быдлокодеров"... А тут ты с таким разрывом шаблона :)

← →
oxffff © (2010-09-06 10:07) [55]

> Спустя восемь лет

Мысль человека не остановилась. И люди как и раньше ищут методы борьбы со сложностью.

← →
Marser © (2010-09-06 11:38) [56]

← →
Дмитрий Белькевич (2010-09-06 11:45) [57]

> А у меня почему то гигабайты.

Если интегрально по миру собрать, то неиллюзорный ужас получится :)

> Delphi существует в считанных решениях. И даже систему,
> над которой я работал 3.5 года, переводят с Delphi на C#.
> ..

На Жаве я, например, вообще ничего припомнить распространённого не могу, что не мешает ей занимать первое место по числу разработчиков на ней (известный индекс tiobe). Так что не нужно говорить про "считанные решения". Если они не распространены - это не значит, что их нет. В конце концов на Делфи (в отличие от той же Жавы) можно хоть что-то массовое вспомнить - tc/skype, как минимум.

> Когда он будет заявлен на всех платформах (он-же кросс платформенный)
> тогда и стоит делать такое заявление. А пока что уныл он,
> медленный, незащищенный ну и до кучи не требующий высокой
> квалификации :

Дотнет вобрал в себя два минуса:

1. Тормознутость жавы по тем же причинам, что и у жавы.
2. Отсутствие кросс-платформенности, по причине жадности MS.

Если бы не MS и тонны рекламы дотнет не смог бы прижиться никогда.
В нём просто отсутствует необходимость.
Для кросс-платформенности существует Жава.
Для нативного Wintel"а существует Делфи.

Дотнет не нужен ;)

← →
Дмитрий Белькевич (2010-09-06 11:51) [58]

> http://www.rsdn.ru/article/devtools/perftest3.xml

Вот это хорошо:

"Джава, это черепаха с тяжёлым панцирем. Он защищает от дурака, но его нельзя сбросить и побежать "по человечески". Хотя любители всё время подпиливают панцирь и уверяют, что она скоро зайца обгонит..."

Дотнет там же.

← →
DVM © (2010-09-06 11:56) [59]

Не такой уж C# и NET и тормозной. И даже я бы сказал наоборот.

← →
Игорь Шевченко © (2010-09-06 11:58) [60]

"завидую тем у кого длинный нос.
Ибо фраза - дальше своего носа не видит - им почти комплимент"
(c) Думкин

← →
Rouse_ © (2010-09-06 13:55) [61]

> DVM © (06.09.10 11:56) [59]
>
> Не такой уж C# и NET и тормозной. И даже я бы сказал наоборот.
>

Ну это надо сравнивать не на синтетических тестах, типа сортировки и т.п. а на реальных.
Например в цикле:
1. Создали IStorage (А) на диске
2. Создали в нем IStream (Б)
3. Записали в него радномное число
4. Закрыли IStorage (А)
5. Создали новый IStorage (В)
6. Открыли предыдущий IStorage (А)
7. Прочитали из число из сохраненного IStream (Б)
8. Записали в новый IStream (Г) это число увеличенное на 10
9. Убили оба файла.
10. повторить 10 тысяч раз.
11. замерить время

← →
Romkin © (2010-09-06 14:58) [62]

Rouse_ © (06.09.10 13:55) [61] И протестишь ты в конце производительность диска :)

← →
Rouse_ © (2010-09-06 15:14) [63]

И его в том числе - но там просто есть нюанс...

← →
DVM © (2010-09-06 15:54) [64]

> Rouse_ © (06.09.10 15:14) [63]

А что там за нюанс?

Так мы будем в данном случае тестить не c# а конкретные реализации конкретных вещей в тех или иных библиотеах. В данном случае потестим еще диск действительно. Так не правильно. Тестить надо как раз сортировками и проч. И писать их самому.

Могу предложить потестить C#+WPF vs Delphi+GDI - тут даже гадать не надо что при соответствующей видеокарте получится. Но опять же это будет сравнение производительности не C# vs Delphi.

← →
Marser © (2010-09-06 15:59) [65]

> Romkin © (06.09.10 14:58) [62]
>
> Rouse_ © (06.09.10 13:55) [61] И протестишь ты в конце
> производительность диска :)

О, а вы всё ещё в Делфи? :-)

Вообще, много тут народу в нём осталось?
ИШ, Розыч, Эга рядом, Тессеракт вроде...

>
> Могу предложить потестить C#+WPF vs Delphi+GDI - тут даже
> гадать не надо что при соответствующей видеокарте получится.
> Но опять же это будет сравнение производительности не C#
> vs Delphi.

Надо интегральные показатели выводить, потому что большинству безразлична разница в быстродействии в +-10%.
А вот если взять суммарные показатели, оценивающие разработку, отладку, тестирование, сопровождение, устойчивость и так далее, то есть, и производственный цикл, тогда картина будет более-менее.

← →
Marser © (2010-09-06 16:19) [66]

>
> Вообще, много тут народу в нём осталось?
> ИШ, Розыч, Эга рядом, Тессеракт вроде...

Керк, конечно же :)
Как-то уже не ассоциирую своего закадыку с форумом :-)

← →
Rouse_ © (2010-09-06 16:22) [67]

> Marser © (06.09.10 15:59) [65]
> О, а вы всё ещё в Делфи? :-)
> Вообще, много тут народу в нём осталось?
> ИШ, Розыч, Эга рядом, Тессеракт вроде...

Ну я лет семь как не только на Дельфи пишу, поэтому скажем - дельфя, всего-то один из многочисленных инструментов :)

← →
Alkid © (2010-09-06 17:17) [68]

> Дмитрий Белькевич (06.09.10 11:45) [57]
> Дотнет вобрал в себя два минуса:
>
> 1. Тормознутость жавы по тем же причинам, что и у жавы.
> 2. Отсутствие кросс-платформенности, по причине жадности
> MS.
>
> Если бы не MS и тонны рекламы дотнет не смог бы прижиться
> никогда.
> В нём просто отсутствует необходимость.
> Для кросс-платформенности существует Жава.
> Для нативного Wintel"а существует Делфи.
>
> Дотнет не нужен ;)

Тормознутость .net преувеличена. В тех задачах, где его применяют его производительности достаточно.
Настоящей кросс.платформенности у .net нету, но это issue только тогда, когда кроссплатформенность является требованием. Зато там хороший Framework, есть интересные языки, да и C# программировать сухо и прельстиво.
В итоге остается, что .net - это очень удобный инструмент для разработки под платформу Windows, если нет ограничения на нативность. Собственно, как программист в проекте на C# ответственно заявляю, что он там справляется.

← →
Alkid © (2010-09-06 17:32) [69]

> Rouse_ © (06.09.10 13:55) [61]
>
> Ну это надо сравнивать не на синтетических тестах, типа
> сортировки и т.п. а на реальных.

Ну вот у нас реальная задача: получить от почтового сервера MIME, отдать его на сканирования антивирусному ядру, антиспамовому ядру, положить, если надо в карантин, отдать сервису. Все это, естественно, под хорошей нагрузкой (в смысле потока писем). Параллельно собирать и сохранять статистику, рассылать уведомления, скачивать новые базы, проводить кое-какие проверки по расписанию, следить за лицензией и т.п. Ядра и модуль обновления нативные, остальное все - дотнет. Кое-что другое изначальное было нативное, но потом переписали на .net. При этом, замечу, мы там очень активно используем Reflection, который считается очень медленным, и linq, который тоже считается небыстрым.

← →
картман © (2010-09-06 18:24) [70]

> Alkid © (06.09.10 17:32) [69]

Класс! Перепишите лучше "...антивирусному ядру, антиспамовому ядру.." на дотнет.

← →
Alkid © (2010-09-06 20:11) [71]

> картман © (06.09.10 18:24) [70]
> Класс! Перепишите лучше "...антивирусному ядру, антиспамовому
> ядру.." на дотнет.

Да я бы рад, но кто ж нам даст :)

← →
Rouse_ © (2010-09-06 20:33) [72]

> Alkid © (06.09.10 17:32) [69]

Ну у нас тоже примерно такого-же плана есть, только все в одной большой куче - и запросы на лицензирование и крипт входящих данных с отдачей наружу результата, и раздача базенок/обновлений. Только мы не используем ничего - чего не написали бы сами, поэтому не паримся с рефлекшеном и не жалуемся на скорость :)

← →
Alkid © (2010-09-06 20:49) [73]

> Rouse_ © (06.09.10 20:33) [72]
> Ну у нас тоже примерно такого-же плана есть, только все
> в одной большой куче - и запросы на лицензирование и крипт
> входящих данных с отдачей наружу результата, и раздача базенок/обновлений.
> Только мы не используем ничего - чего не написали бы сами,
> поэтому не паримся с рефлекшеном и не жалуемся на скорость
> :)

А я разве сказал, что мы жалуемся на скорость? Наоборот, мой посыл был в том, что на скорость мы совсем не жалуемся и даже позволяем себе пользоваться всякими наворотами с рефлекшеном ради своего удобства.

← →
Alkid © (2010-09-06 20:49) [74]

← →
Дмитрий Белькевич (2010-09-06 21:58) [75]

> Ну вот у нас реальная задача: получить от почтового сервера
> MIME, отдать его на сканирования антивирусному ядру, антиспамовому
> ядру, положить, если надо в карантин, отдать сервису. Все
> это, естественно, под хорошей нагрузкой (в смысле потока
> писем). Параллельно собирать и сохранять статистику, рассылать
> уведомления, скачивать новые базы, проводить кое-какие проверки
> по расписанию, следить за лицензией и т.п. Ядра и модуль
> обновления нативные, остальное все - дотнет. Кое-что другое
> изначальное было нативное, но потом переписали на .net.
> При этом, замечу, мы там очень активно используем Reflection,
> который считается очень медленным, и linq, который тоже
> считается небыстрым.

Надо писать не так: у нас задача - обработать 1-2 гб видеонформации в реальном (для юзеры) времени. А то, что вы там десяток-другой байт перекинете пусть и десятью задачами - так на современных процах это, конечно, пук в воду.

← →
Alkid © (2010-09-06 23:04) [76]

> Дмитрий Белькевич (06.09.10 21:58) [75]
> Надо писать не так: у нас задача - обработать 1-2 гб видеонформации
> в реальном (для юзеры) времени. А то, что вы там десяток-
> другой байт перекинете пусть и десятью задачами - так на
> современных процах это, конечно, пук в воду.

Десяток-другой байт? Вы явно недооцениваете современный почтовый траффик :) Можно сказать, всех спаммеров сейчас оскорбили ;)

← →
Дмитрий Белькевич (2010-09-07 01:48) [77]

> Десяток-другой байт? Вы явно недооцениваете современный
> почтовый траффик :) Можно сказать, всех спаммеров сейчас
> оскорбили ;)

Я утрировал, конечно :) Но не думаю, что объёмы обработки - гигабайты за десяток миллисекунд.

← →
Дмитрий Белькевич (2010-09-07 02:14) [78]

Нет, я не принципиально против C# и .net. Я против такого C# и .net, какой получился у MS. Как в том анекдоте про милиционера в бане - ты или кобуру сними или трусы одень.

Сделала бы MS нативный C#, или, еще лучше, действительно кросс-платформенный дотнет - честь и хвала. А так - творческий онанизм и массовая генерация энтропии.

← →
Marser © (2010-09-07 02:38) [79]

> Как в том анекдоте про милиционера в бане - ты или кобуру
> сними или трусы одень.

Бр-р...
В оригинале - Фима, вы или трусы оденьте, или крестик снимите ;-)

>
> Сделала бы MS нативный C#, или, еще лучше, действительно
> кросс-платформенный дотнет - честь и хвала. А так - творческий
> онанизм и массовая генерация энтропии.

Для нативности есть С++.

← →
oxffff © (2010-09-07 08:36) [80]

Все вкусности С# вытекают из GC(решение проблемы потерянных ссылок(хотя в Delphi есть reference count), а главное циклических ссылок).

Allen Bauer - в комманде с самого рождения Delphi.

Привожу комментарий [27] из http://blogs.embarcadero.com/abauer/2010/02/16/38916

Allen Bauer
Says от February 19th, 2010 at 1:08 pm
@Warren,

Uh.. everything could reference counted… but the cycles would kill you

I think having a GC would enable whole new programming idioms that would make things more usable. It could also *increase* performance in some scenarios. If we are to attract "new blood", having a GC may help attract some of those fresh-from-college CS guys that learned on managed or dynamic languages more comfortable.

It would also make FreeAndNil moot ;-).

← →
Alkid © (2010-09-07 10:01) [81]

> Дмитрий Белькевич (07.09.10 01:48) [77]
> Я утрировал, конечно :) Но не думаю, что объёмы обработки
> - гигабайты за десяток миллисекунд.

Нет, конечно :) Высоконагруженные системы на .net писать я бы не стал. Но "просто нагруженные" получаются и работают.

> Нет, я не принципиально против C# и .net. Я против такого
> C# и .net, какой получился у MS. Как в том анекдоте про
> милиционера в бане - ты или кобуру сними или трусы одень.
>
> Сделала бы MS нативный C#, или, еще лучше, действительно
> кросс-платформенный дотнет - честь и хвала. А так - творческий
> онанизм и массовая генерация энтропии.

Вот не согласен. Как я понимаю, главная претензия к наличию управляемого кода (MSIL) и виртуальной машины, которая этот код как бы исполняет (на самом деле JIT-компилирует). Вот только сути этой претензии уловить не могу. Управляемый код - это не только средство обеспечения кросс-платформенности но и "2-3 килограмма диетического высокоусвояемого мяса". В смысле, что от него есть много других полезных бенефитов. В итогде .NET в том виде, в котором он есть - это очень хороший инструмент для решения очень широкого класса задач в экосисеме Windows.

← →
Alkid © (2010-09-07 10:06) [82]

> oxffff © (07.09.10 08:36) [80]
> Все вкусности С# вытекают из GC(решение проблемы потерянных
> ссылок(хотя в Delphi есть reference count), а главное циклических
> ссылок).

Не все, хотя большиство :)

← →
brother © (2010-09-07 10:07) [83]

> Управляемый код - это не только средство обеспечения кросс-
> платформенности

> это очень хороший инструмент для решения очень широкого
> класса задач в экосисеме Windows

Это как расценивать?

← →
Alkid © (2010-09-07 10:16) [84]

> brother © (07.09.10 10:07) [83]
> Это как расценивать?

Очень просто - насколько я понял аргумент Дмитрия, он спрашивает: "зачем в .net ввели промежуточный код и ВМ, если реально кроссплатформенности из этого не вышло".

Я отвечаю: промежуточный код и ВМ нужны не только для кроссплатформенности.

← →
Alex Konshin © (2010-09-07 10:22) [85]

Хм, посмотрел Axum. Это похоже будет первый реальный широко используемый язык который основам на принципе DataFlow ( http://en.wikipedia.org/wiki/Dataflow_architecture ).
То есть, такие системы были и есть, но они мало используются. А MS уж точно может пробить его. Причём такой язык давно ожидается потому, что ядер в обычных PC становится всё больше и больше, а писать многопоточные приложения непросто и всё равно никогда не будешь 100% уверен, что нигде нет потенциальных мест для deadlock. Это откроет дорогу для действительно многопроцессорных настольных систем с десятками ядер, и заодно даст ещё один повод для более тесной интеграции с GPU, а в дальнейшем и сращивании его с CPU.

← →
Anatoly Podgoretsky © (2010-09-07 10:22) [86]

> brother (07.09.2010 10:07:23) [83]

Расценивай как И

← →
Styx (2010-09-07 10:26) [87]

Alkid © (07.09.10 10:01) [81]
> В смысле, что от него есть много других полезных бенефитов.

А каих, если не секрет?

← →
Alkid © (2010-09-07 10:40) [88]

> Styx (07.09.10 10:26) [87]
> А каих, если не секрет?

1. Language interoperability,
2. Reflection,
3. Динамическая кодогенерация
4. Верификация кода.
5. Возможность оптимизирующей компиляции в машинный код с использованием особенностей контекста (собранная статистика по путям исполнения, использование особенностей аппаратуры и т.п.)

Это то, что навсидку вспомнил.

> Alkid © (07.09.10 10:40) [88]
>
> > Styx (07.09.10 10:26) [87]
> > А каих, если не секрет?
>
> 1. Language interoperability,
> 2. Reflection,
> 3. Динамическая кодогенерация
> 4. Верификация кода.
> 5. Возможность оптимизирующей компиляции в машинный код
> с использованием особенностей контекста (собранная статистика
> по путям исполнения, использование особенностей аппаратуры
> и т.п.)
>
> Это то, что навсидку вспомнил.

1. Сомнительно. Поскольку все языки становятся очень похожими друг на друга во всяком случае с течением времени. Поскольку на самом деле язык один MSIL. Это больше марпетинг.
2. В Delphi тоже есть RTTI
3. Непонятно как это связано с промежуточным представлением. Никто не мешает даже сейчас генерировать код на Delphi и отдавать его компилятору командой строки. Смысл тот же.
4 Непонятно как это связано с промежуточным представлением. Никто не мешает даже сейчас делать верификация кода на Delphi и отдавать его компилятору командой строки. Смысл тот же.

5. Вот это действительно +.

> 5. Вот это действительно +.

Однако и сейчас никто не мешает делать тоже самое на delphi. Это конечно не JIT, однако аналог ngen.

← →
jack128_ (2010-09-07 11:12) [91]

> поэтому не паримся с рефлекшеном

У используется RTTI для маппинга данных из базы на объекты. Ты просто не в курсе :-)

← →
jack128_ (2010-09-07 11:21) [92]

я се слабо представляю как можно сделать верификацию кода если у тя есть указатели, доступ к нативным либам и тд. Если же дельфи всего этого лишить - то мы получим туже самую песочницу, что .NET.

Да и чисто технически - верификацию нативного кода гораздо тяжелее реализовать, хотя наверно и возможно.

> jack128_ (07.09.10 11:21) [92]
> я се слабо представляю как можно сделать верификацию кода
> если у тя есть указатели, доступ к нативным либам и тд.
> Если же дельфи всего этого лишить - то мы получим туже самую
> песочницу, что .NET.
>
> Да и чисто технически - верификацию нативного кода гораздо
> тяжелее реализовать, хотя наверно и возможно.

Почему есть всякие уровни доверия к коду в .NET.

1.8 Verifiability and correctness
Memory safety is a property that ensures programs running in the same address space are correctly isolated from one another (see Partition I). Thus, it is desirable to test whether programs are memory safe prior to running them. Unfortunately, it is provably impossible to do this with 100% accuracy. Instead, the CLI can test a stronger restriction, called verifiability. Every program that is verified is memory safe, but some programs that are not verifiable are still memory safe.
Correct CIL is CIL that executes on all conforming implementations of the CLI, with well-defined behavior as specified in this standard. However, correct CIL need not result in identical behavior across conforming implementations; that is, the behavior might be implementation-specific.
It is perfectly acceptable to generate correct CIL code that is not verifiable, but which is known to be memory safe by the compiler writer. Thus, correct CIL might not be verifiable, even though the producing compiler might know that it is memory safe. Several important uses of CIL instructions are not verifiable, such as the pointer arithmetic versions of add that are required for the faithful and efficient compilation of C programs. For non-verifiable code, memory safety is the responsibility of the application programmer.
Correct CIL contains a verifiable subset. The Verifiability description gives details of the conditions under which a use of an instruction falls within the verifiable subset of CIL. Verification tracks the types of values in much finer detail than is required for the basic functioning of the CLI, because it is checking that a CIL code sequence respects not only the basic rules of the CLI with respect to the safety of garbage collection, but also the typing rules of the CTS. This helps to guarantee the sound operation of the entire CLI.
The verifiability section of each operation description specifies requirements both for correct CIL generation and for verification. Correct CIL generation always requires guaranteeing that the top items on the stack correspond to the types shown in the stack transition diagram. The verifiability section specifies only requirements for correct CIL generation that are not captured in that diagram. Verification tests both the requirements for correct CIL generation and the specific verification conditions that are described with the instruction. The operation of CIL sequences that do not meet the CIL correctness requirements is unspecified. The operation of CIL sequences that meet the correctness requirements, but which are not verifiable, might violate type safety and hence might violate security or memory access constraints.

> oxffff © (07.09.10 10:59) [89]
> 1. Сомнительно. Поскольку все языки становятся очень похожими
> друг на друга во всяком случае с течением времени. Поскольку
> на самом деле язык один MSIL. Это больше марпетинг.

"Похожие друг на друга" там C# и VB.
F# и C# уже очень не похожи друг на друга.
А есть еще ряд маргинальных языков, например имплементация моего любимого пролога.
Он похож на C#? :)

> 2. В Delphi тоже есть RTTI

RTTI имеющийся в Delphi 7 (самая новая версия с которой я знаком) серьезно проигрывает по возможностям.
К сожалению, я не в курсе дальнейших продвижений в этой области у Delphi.
Наверное ты прав в том смысле, что Refelction и промежуточный язык ортогональные фитчи, а убогость его реализации в unmanaged языках (оговорюсь - известных мне) - это всего лишь совпадение.

> 3. Непонятно как это связано с промежуточным представлением.
> Никто не мешает даже сейчас генерировать код на Delphi
> и отдавать его компилятору командой строки. Смысл тот же.

Смысл тот же, но имплементация на совершенно разном уровне.
Какие есть типовые решения (фреймворки) для дельфи, реализующие DI и аспекты без необходимости писать руками обертки? Я не знаю пока таких, хотя теоретически их можно сделать. Компилятор командной строки есть же :)

> 4 Непонятно как это связано с промежуточным представлением.
> Никто не мешает даже сейчас делать верификация кода на
> Delphi и отдавать его компилятору командой строки. Смысл
> тот же.

Чем более высокоуровневый код, тем его проще верифицировать. MSIL проще верифицировать, чем машинные коды.
Анализ исходных текстов тут не в тему, ибо речь о run-time.

> Alkid © (07.09.10 12:28) [94]
>
> > oxffff © (07.09.10 10:59) [89]
> > 1. Сомнительно. Поскольку все языки становятся очень похожими
>
> > друг на друга во всяком случае с течением времени. Поскольку
>
> > на самом деле язык один MSIL. Это больше марпетинг.
>
> "Похожие друг на друга" там C# и VB.
> F# и C# уже очень не похожи друг на друга.
> А есть еще ряд маргинальных языков, например имплементация
> моего любимого пролога.
> Он похож на C#? :)

Еще не вечер. Одиночное наследование, замыкания, bounded полиморфизм, рефлексия - это все ноги и ограничения MSIL.
Тем не менее функциональные языки реализуются на ООП ВМ со сборкой мусора. Мать то одна.

А почему ты не упомянул именно о способе их взаимодействия?
Ведь во всех них есть некие аналоги сборки, класса, метода, свойства. Они по другому не смогут взаимодействовать. Так что все приведется к общему знаменателю - MSIL.

> > 2. В Delphi тоже есть RTTI
>
> RTTI имеющийся в Delphi 7 (самая новая версия с которой
> я знаком) серьезно проигрывает по возможностям.
> К сожалению, я не в курсе дальнейших продвижений в этой
> области у Delphi.
> Наверное ты прав в том смысле, что Refelction и промежуточный
> язык ортогональные фитчи, а убогость его реализации в unmanaged
> языках (оговорюсь - известных мне) - это всего лишь совпадение.
>

Следуют посмотреть для развития кругозора.

> Чем более высокоуровневый код, тем его проще верифицировать.
> MSIL проще верифицировать, чем машинные коды.
> Анализ исходных текстов тут не в тему, ибо речь о run-time.
>

Верифицировать будешь исходный код на delphi в run time, а не машинные коды.

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

> oxffff © (07.09.10 12:39) [95]
> Еще не вечер. Одиночное наследование, замыкания, bounded
> полиморфизм, рефлексия - это все ноги и ограничения MSIL.

Хм. А вот есть язык Eiifel, который имеет реализацию под .net.
И ничего, реализуют множественное наследование.
Может эти "ограничения MSIL" не такие уж и ограничения?

> Тем не менее функциональные языки реализуются на ООП ВМ
> со сборкой мусора. Мать то одна.
>
> А почему ты не упомянул именно о способе их взаимодействия?
>
> Ведь во всех них есть некие аналоги сборки, класса, метода,
> свойства. Они по другому не смогут взаимодействовать. Так
> что все приведется к общему знаменателю - MSIL.

Это заблуждение.
Говорить, что все .net языки должны быть похожи друг на друга, потому что "приводятся к единому знаменателю MSIL", это все равно, что утверждать, что все нативные языки должны быть похожи, ибо приводятся к "единому знаменателю машинных кодов". Во всех ведь есть бинарные модули, сегменты, указатели, подпрограмы...

> Верифицировать будешь исходный код на delphi в run time,
> а не машинные коды.

Это уже изменение условия задачи :) Если ты собираешься тащить в run-time исходники, то стоит задуматься над тем, надо ли тебе вообще иметь дело с такими языками, как Delphi, C#, C++. Логичнее будет выглядеть какой-нибудь питон или лисп.

> Alkid (07.09.2010 13:36:37) [97]

> все нативные языки должны быть похожи, ибо приводятся к "единому
> знаменателю машинных кодов".

Приводятся к Английскому с американским акцентом.

> Alkid (07.09.2010 13:36:37) [97]

Чем тебе не нравится C# в ASP.NET это один из основных языков, работает на
основе исходников, прозначно и незаметно. Очень удобно.

> Alkid © (07.09.10 13:36) [97]
>
> > oxffff © (07.09.10 12:39) [95]
> > Еще не вечер. Одиночное наследование, замыкания, bounded
>
> > полиморфизм, рефлексия - это все ноги и ограничения MSIL.
>
>
> Хм. А вот есть язык Eiifel, который имеет реализацию под
> .net.
> И ничего, реализуют множественное наследование.
> Может эти "ограничения MSIL" не такие уж и ограничения?

Может все же прочитать как это сделано? И что это ненастоящее множественное наследование, а просто делегация.

Multiple Inheritance
Multiple inheritance was, as noted, recognized from the start as a key implementation issue. The reader may indeed wonder how we can provide multiple inheritance on a platform that doesn"t support it, especially with the requirement stated above that other languages should see the Eiffel multiple inheritance structure.

The solution used relies on the ability of a .NET Framework class to inherit multiply from interfaces—completely abstract classes without any implementation at all. In the generated code, the compiler shadows every class with interface.

http://msdn.microsoft.com/en-us/library/ms973898.aspx

> > Тем не менее функциональные языки реализуются на ООП ВМ
>
> > со сборкой мусора. Мать то одна.
> >
> > А почему ты не упомянул именно о способе их взаимодействия?
>
> >
> > Ведь во всех них есть некие аналоги сборки, класса, метода,
>
> > свойства. Они по другому не смогут взаимодействовать.
> Так
> > что все приведется к общему знаменателю - MSIL.
>
> Это заблуждение.
> Говорить, что все .net языки должны быть похожи друг на
> друга, потому что "приводятся к единому знаменателю MSIL",
> это все равно, что утверждать, что все нативные языки должны
> быть похожи, ибо приводятся к "единому знаменателю машинных
> кодов". Во всех ведь есть бинарные модули, сегменты, указатели,
> подпрограмы...

Вот только не стоит подменять понятия. В таком случае можно абсолютно про все языки существуеющие сказать что они Language interoperability.
Под Language interoperability как и подразумевается их взаимодействие через единый понятный .NET языкам механизм (сборки->классы->методы).

> > Верифицировать будешь исходный код на delphi в run time,
>
> > а не машинные коды.
>
> Это уже изменение условия задачи :) Если ты собираешься
> тащить в run-time исходники, то стоит задуматься над тем,
> надо ли тебе вообще иметь дело с такими языками, как Delphi,
> C#, C++. Логичнее будет выглядеть какой-нибудь питон или
> лисп.

Отчего же?
.NET языки же тащат промежуточное представление в виде байкода и таблиц метаданных в exe. То есть тащат исходники.
Почему же нельзя тащить Delphi код?

> oxffff © (07.09.10 14:31) [100]
> Может все же прочитать как это сделано? И что это ненастоящее
> множественное наследование, а просто делегация.

В нативных языках в конечном итоге все тоже выливается совсем не в ООП с наследованием :)

> Вот только не стоит подменять понятия. В таком случае можно
> абсолютно про все языки существуеющие сказать что они Language
> interoperability.
> Под Language interoperability как и подразумевается их взаимодействие
> через единый понятный .NET языкам механизм (сборки->классы-
> >методы).

Да кто же их подменяет? :)
Да, в нативном мире тоже есть свой Language Interoperability: ABI, COM.
Просто там это дается с бОльшим геморроем.
Примерно так же, как и с кодогенерацией - в нативном мире тебе тоже никто не запрещает ни кодогенерироваться, ни интероперироваться. Просто уровень реализации разный

> Отчего же?
> .NET языки же тащат промежуточное представление в виде байкода
> и таблиц метаданных в exe. То есть тащат исходники.

Вот это и есть самая натуральная подмена понятий :)
MSIL не есть исходники.
Или даже так, если MSIL считать исходниками, то машинный код тоже получается исходники.
Тогда смысл разделения понятий "исходный код" и "скомпилированный код" совсем теряется :)

> Alkid © (07.09.10 14:47) [101]
>
> > oxffff © (07.09.10 14:31) [100]
> > Может все же прочитать как это сделано? И что это ненастоящее
>
> > множественное наследование, а просто делегация.
>
> В нативных языках в конечном итоге все тоже выливается совсем
> не в ООП с наследованием :)

Видимо есть некоторые особенности раз такого не сделали для managed С++.

> Да кто же их подменяет? :)
> Да, в нативном мире тоже есть свой Language Interoperability:
> ABI, COM.
> Просто там это дается с бОльшим геморроем.
> Примерно так же, как и с кодогенерацией - в нативном мире
> тебе тоже никто не запрещает ни кодогенерироваться, ни интероперироваться.
> Просто уровень реализации разный

Я просто сколько читал описание .NET различных языков везде в том или ином виде присутствуют ссылки на сборки и классы в качестве Language Interoperability.

> Вот это и есть самая натуральная подмена понятий :)
> MSIL не есть исходники.
> Или даже так, если MSIL считать исходниками, то машинный
> код тоже получается исходники.
> Тогда смысл разделения понятий "исходный код" и "скомпилированный
> код" совсем теряется :)

Машинный код не является исходниками. Поскольку например из него нельзя получить информацию о типах данных. Байт код является аналогом семантического дерева из которого можно получить например информацию о типах данных.
Если представить шаги, то все очень просто

C#->MSIL+Metadata->x86
Delphi->Delphi.dcu->x86

> C#->MSIL+Metadata->x86
> Delphi->Delphi.dcu->x86

Однако Delphi->Delphi.dcu не является аналогом C#->MSIL+Metadata, а является аналогом C#->MSIL+Metadata->x86.
Поэтому в некотором смысле шага C#->MSIL+Metadata нет, то есть это просто другая запись того же самого.

> Машинный код не является исходниками. Поскольку например
> из него нельзя получить информацию о типах данных

Странные у тебя критерии исходников

> Игорь Шевченко © (07.09.10 16:16) [104]
>
> > Машинный код не является исходниками. Поскольку например
>
> > из него нельзя получить информацию о типах данных
>
>
> Странные у тебя критерии исходников

Почему очень даже не странные.

Вот аналоги на разных языках

Delphi
var a,b:integer;
begin
a:=b;

C#
Int32 a,b;
a=b;

MSIL
.locals init(int32 a,int32 b)
ldloc b
stloc a

Однако mov eax,ebx не является их аналогом. Здесь речь идет об исходниках которые необходимо type check и verify.

> oxffff © (07.09.10 15:45) [102]
> Видимо есть некоторые особенности раз такого не сделали
> для managed С++.

Я полагаю, что особенность простая - нижележащая система не имеет понятия о множественном наследовании. Следовательно, отображения "один к одному" на её понятия не получится. Следовательно, надо думать и исследовать, как множественное наследование реализовывать в экосистеме CLR.
В нативном коде все то же самое - никакой ООП и, тем более, множественное наследование не отображаются прямо на понятия машинного кода.

> Я просто сколько читал описание .NET различных языков везде
> в том или ином виде присутствуют ссылки на сборки и классы
> в качестве Language Interoperability.

Ну и что? А вот под Windows, например, все языки каким-то удивительным образом производят восновном либо exe, либо dll модули. И для интеропа стабильно используют два механизма - либо ABI, либо COM.
Но это ничего не говорит о похожести самих языков. Среди них есть и логические, и процедурные, и ООП и функциональные и так далее.

> Машинный код не является исходниками. Поскольку например
> из него нельзя получить информацию о типах данных. Байт
> код является аналогом семантического дерева из которого
> можно получить например информацию о типах данных.
> Если представить шаги, то все очень просто
>
> C#->MSIL+Metadata->x86
> Delphi->Delphi.dcu->x86

Хм. Всегда думал, что исходники - это по определению то, из чего исходят. То есть то, что пишет программист.
Дай свое определение исходников.

> Однако mov eax,ebx не является их аналогом

однако будучи записано строкой является исходником.
Давай ты если вводишь какие-то свои, отличные от общеупотребительных, понятия, ты их заранее будешь декларировать

← →
Дмитрий Белькевич (2010-09-07 19:43) [108]

> за одно то, что не надо делать .Free уже надо памятник ставить.
> А местные пикейные жилеты все про Бриана

Интересно, кстати, менеджер памяти с GC на Делфи принципиально невозможен?

> Дмитрий Белькевич (07.09.10 19:43) [108]
>
> Интересно, кстати, менеджер памяти с GC на Делфи принципиально
> невозможен?

http://codecentral.embarcadero.com/Item/21646

Правда, использовать не пробовал.

> Дмитрий Белькевич (07.09.10 19:43) [108]
> Интересно, кстати, менеджер памяти с GC на Делфи принципиально
> невозможен?

Принципиально возможен, но сборщик мусора в любом языке, в котором есть прямой доступ к памяти и арифметика указателей реализовать проблематично (хотя и возможно) и он будет обладать определенными ограничениями. В прошлой моей конторе пытались реализовать и внедрить свой GC, работающей на дикой смеси подсчета ссылок и mark"n"sweep. Идея с треском рухнула, вобрав в себя кучу человеко-лет и нервов программистов.

Забыл добавить - там писали на С++.

> Alkid © (07.09.10 16:30) [106]
>
> > oxffff © (07.09.10 15:45) [102]
> > Видимо есть некоторые особенности раз такого не сделали
>
> > для managed С++.
>
> Я полагаю, что особенность простая - нижележащая система
> не имеет понятия о множественном наследовании. Следовательно,
> отображения "один к одному" на её понятия не получится.
> Следовательно, надо думать и исследовать, как множественное
> наследование реализовывать в экосистеме CLR.
> В нативном коде все то же самое - никакой ООП и, тем более,
> множественное наследование не отображаются прямо на понятия
> машинного кода.

То есть таким образом ты признаешь, что все .NET языки в каком то смысле подобны, то есть есть костяк за рамки которого они не могут выйти?
И вопрос только во времени, когда все они станут идентичны по механизмам, но различны по синтаксису.

> > Я просто сколько читал описание .NET различных языков
> везде
> > в том или ином виде присутствуют ссылки на сборки и классы
>
> > в качестве Language Interoperability.
>
> Ну и что? А вот под Windows, например, все языки каким-то
> удивительным образом производят восновном либо exe, либо
> dll модули. И для интеропа стабильно используют два механизма
> - либо ABI, либо COM.
> Но это ничего не говорит о похожести самих языков. Среди
> них есть и логические, и процедурные, и ООП и функциональные
> и так далее.

Хорошо сейчас я дома. И могу наконец могу достать из шкафа ... молоток. :)
Рихтера.
Дословно Language Interoperability

.NET обеспечивает интеграцию разных языков, то есть один язык может использовать типы, созданные на других языках. Например, CLR позволяет создать на С++ класс, производный от класса, реализованного на VB. В CLR это возможно из-за наличия общей системы типов (CLS), которую должны использовать все языки, ориентированные на CLR. А поскольку опять же сборки, классы, методы являются основой CLR, то все языки должны в том или ином виде реализовывать такие понятия(примитивы).

>
> Хм. Всегда думал, что исходники - это по определению то,
> из чего исходят. То есть то, что пишет программист.
> Дай свое определение исходников.

Исходники тут не причем. Разговор изначально зашел о том, для верификации в run time нужен промежуточный язык. А я стараюсь тебе показать, что это совсем необязательно.

> Игорь Шевченко © (07.09.10 17:30) [107]
>
> > Однако mov eax,ebx не является их аналогом
>
>
> однако будучи записано строкой является исходником.
> Давай ты если вводишь какие-то свои, отличные от общеупотребительных,
> понятия, ты их заранее будешь декларировать

И?

> oxffff © (07.09.10 21:16) [112]
> То есть таким образом ты признаешь, что все .NET языки в
> каком то смысле подобны, то есть есть костяк за рамки которого
> они не могут выйти?
> И вопрос только во времени, когда все они станут идентичны
> по механизмам, но различны по синтаксису.

Опять 25.
Ну почему они должны стать идентичными по механизмам?
Нативные языки должны в перспективе обрести такую же идентичность?
Если нет, то объясни мне качественную разницу между нативными платформами и .net.
Причем такую, которая объясняла бы, почему на нативе может быть дивергенция, а в .net мы должны конвергировать к какому-то семантически единому языку.
И приведи мне примеры этой конвергенции.
Пока я вижу только параллельную эволюцию C# и VB, которая осуществляется как сознательная политика MS.
Хейлсберг об этом явно заявил.
Так же я вижу дивергенцию - .net имеет ООП природу, но на нем уже реализованы языки всех основных парадигм (процедурной, ООП, функциональной, логической), причем в разных "вкусах" (разные системы типизации, разный уровень динамичности и т.п.). Причем разнообразие реализованных языков лишь растет со временем.

> Хорошо сейчас я дома. И могу наконец могу достать из шкафа
> ... молоток. :)
> Рихтера.
> Дословно Language Interoperability
>
> .NET обеспечивает интеграцию разных языков, то есть один
> язык может использовать типы, созданные на других языках.
> Например, CLR позволяет создать на С++ класс, производный
> от класса, реализованного на VB. В CLR это возможно из-за
> наличия общей системы типов (CLS), которую должны использовать
> все языки, ориентированные на CLR. А поскольку опять же
> сборки, классы, методы являются основой CLR, то все языки
> должны в том или ином виде реализовывать такие понятия(примитивы).

Они должны их реализовывать, но:
1. Эти концепции могут быть лишь деталью реализации яызка на .NET и не проявляться в самом языке.
2. Эти концепции не ограничивают концептуальное богатство языка.

Все нативные программы, работающие на платформе Wintel так же должны в себе как-то реализовывать такие концепции, как модули (PE-модули), должны "знать" о регистрах, об LPC и т.п.

Вот примитивная программа на С:
int main() { return 0; }
Где все, что я перечислил?

А вот код на F#
// подключаем лайт-синтаксис #light // C# : using System; open System // скажем миру привет printfn "Hello, World! What is your name, user?" // а как нас зовут? C# : var name = Console.ReadLine(); let name = Console.ReadLine() // определим функцию, которая будет говорить "привет" аргументу who. // приблизительный аналог на C#: // public delegate void SaySomethingDelegate(string toWho); // SaySomethingDelegate sayHello = who => Console.WriteLine("Hello, {0}!", who); let sayHello who = printfn "Hello, %s!" who // привет, Хабрахабр! sayHello name // а в функциях можно использовать и стандартные методы .Net Framework: let sayHelloDotNet who = Console.WriteLine("Hello from F# via .Net, " + name + "!") // и опять привет! sayHelloDotNet name // в качестве бонуса посчитаем числа Фибоначчи :) let rec fib i = // рекурсивная функция от одного аргумента match i with // которая смотрит на что похож этот аргумент | 1 | 2 -> 1 // если он 1 или 2, то возвращаем 1 | i -> fib(i-1) + fib(i-2) // если он похож только на себя - то рекурсивно вызываем эту же функцию // смотрим, что у нас получилось printfn "%i" (fib 20)
Сколько классов мы тут объявили?

> Исходники тут не причем. Разговор изначально зашел о том,
> для верификации в run time нужен промежуточный язык. А
> я стараюсь тебе показать, что это совсем необязательно.

Это не обязательно.
Промежуточный код это лишь одна из возможных стратегий.

> Alkid (07.09.2010 21:36:54) [114]

Промежуточный язык, в не код, был разработан не для верификации, а для
кроссплатформенности. Промежуточный язык он общий для всех платформ, затем
он компилируется в нативный код для платформы и независим от процессора и
его разрядности,

> Anatoly Podgoretsky © (07.09.10 21:47) [115]
> Промежуточный язык, в не код, был разработан не для верификации,
> а для
> кроссплатформенности. Промежуточный язык он общий для всех
> платформ, затем
> он компилируется в нативный код для платформы и независим
> от процессора и
> его разрядности,

Это не единственная польза и мотивация от введения IL.

> Alkid (07.09.2010 22:00:56) [116]

Разумеется, но сколько я не читал, основной упор делался на компиляцию из
промежуточного языка, независимого от платфрормы. На каждой платформе будет
свой компилятор, который и сделает родной код и достаточно IL файла
перенести на другую платформу и ничего изменять не надо.

Ну MS на кроссплатформенность плевать. Им это не нужно по большому счету.

Промежуточный код нужен для взаимодействия между сборками написанными на различных NET совместимых языках.

> Alkid © (07.09.10 21:36) [114]
>
> > oxffff © (07.09.10 21:16) [112]
> > То есть таким образом ты признаешь, что все .NET языки
> в
> > каком то смысле подобны, то есть есть костяк за рамки
> которого
> > они не могут выйти?
> > И вопрос только во времени, когда все они станут идентичны
>
> > по механизмам, но различны по синтаксису.
>
> Опять 25.
> Ну почему они должны стать идентичными по механизмам?
> Нативные языки должны в перспективе обрести такую же идентичность?
>
> Если нет, то объясни мне качественную разницу между нативными
> платформами и .net.
> Причем такую, которая объясняла бы, почему на нативе может
> быть дивергенция, а в .net мы должны конвергировать к какому-
> то семантически единому языку.
> И приведи мне примеры этой конвергенции.
> Пока я вижу только параллельную эволюцию C# и VB, которая
> осуществляется как сознательная политика MS.
> Хейлсберг об этом явно заявил.
> Так же я вижу дивергенцию - .net имеет ООП природу, но на
> нем уже реализованы языки всех основных парадигм (процедурной,
> ООП, функциональной, логической), причем в разных "вкусах"
> (разные системы типизации, разный уровень динамичности и
> т.п.). Причем разнообразие реализованных языков лишь растет
> со временем.

По мне так растет лишь разнообразие синтаксиса, а механизмы становятся идентичными.

Фундамент CLR
статическая типизация, ООП, делагаты, F-bounded полиморфизм, сборка мусора.

C#, Oxygene, VB#, Pascal.ABC, F#, Nemerle, Eiifel ...
Напоминает лозунг: А у вас уже есть LINQ? Лямбды? Замыкания? Функции высших порядков? ...
плюшки одних языков пошли в другие.

Насчет динамической типизации. Ну нет в .NET динамической типизации и не было. Однако, появился магический способ построенный на отражении и семантическом дереве, который позволяет добавить магию. И теперь я ожидаю посредством ООП абстрации все языки будут нацеплять на себя возможность построения семантического дерева в момент компиляции. Но это миф. Это уже язык в языке получается посредством ООП.
А по честному костыли.

> > Хорошо сейчас я дома. И могу наконец могу достать из шкафа
>
> > ... молоток. :)
> > Рихтера.
> > Дословно Language Interoperability
> >
> > .NET обеспечивает интеграцию разных языков, то есть один
>
> > язык может использовать типы, созданные на других языках.
>
> > Например, CLR позволяет создать на С++ класс, производный
>
> > от класса, реализованного на VB. В CLR это возможно из-
> за
> > наличия общей системы типов (CLS), которую должны использовать
>
> > все языки, ориентированные на CLR. А поскольку опять же
>
> > сборки, классы, методы являются основой CLR, то все языки
>
> > должны в том или ином виде реализовывать такие понятия(примитивы).
>
>
> Они должны их реализовывать, но:
> 1. Эти концепции могут быть лишь деталью реализации яызка
> на .NET и не проявляться в самом языке.
> 2. Эти концепции не ограничивают концептуальное богатство
> языка.
>
> Все нативные программы, работающие на платформе Wintel так
> же должны в себе как-то реализовывать такие концепции, как
> модули (PE-модули), должны "знать" о регистрах, об LPC и
> т.п.
>
> Вот примитивная программа на С:
>
> int main()
> {
> return 0;
> }
>
> Где все, что я перечислил?

Тебе и Рихтер не показатель?
Перечитай внимательно, для того чтобы использовать тип одного языка в другом языке тебе нужно указать сборку и тип.

> А вот код на F#
>
> // подключаем лайт-синтаксис
> #light
> // C# : using System;
> open System
> // скажем миру привет
> printfn "Hello, World! What is your name, user?"
> // а как нас зовут? C# : var name = Console.ReadLine();
> let name = Console.ReadLine()
> // определим функцию, которая будет говорить "привет" аргументу
> who.
> // приблизительный аналог на C#:
> // public delegate void SaySomethingDelegate(string toWho);
>
> // SaySomethingDelegate sayHello = who => Console.WriteLine("Hello,
> {0}!", who);
> let sayHello who = printfn "Hello, %s!" who
> // привет, Хабрахабр!
> sayHello name
> // а в функциях можно использовать и стандартные методы
> .Net Framework:
> let sayHelloDotNet who = Console.WriteLine("Hello from F#
> via .Net, " + name + "!")
> // и опять привет!
> sayHelloDotNet name
> // в качестве бонуса посчитаем числа Фибоначчи :)
> let rec fib i = // рекурсивная функция от одного
> аргумента
> match i with // которая смотрит на что похож этот
> аргумент
> | 1 | 2 -> 1 // если он 1 или 2, то возвращаем 1
> | i -> fib(i-1) + fib(i-2) // если он похож только на себя
> - то рекурсивно вызываем эту же функцию
>
> // смотрим, что у нас получилось
> printfn "%i" (fib 20)
>
> Сколько классов мы тут объявили?

В твоем коде

> .Net Framework:
> let sayHelloDotNet who = Console.WriteLine("Hello from F#
> via .Net, " + name + "!")

Это что? Матчинг? Сим-салябин редукция?

> > Исходники тут не причем. Разговор изначально зашел о том,
>
> > для верификации в run time нужен промежуточный язык.
> А
> > я стараюсь тебе показать, что это совсем необязательно.
>
>
> Это не обязательно.
> Промежуточный код это лишь одна из возможных стратегий.

Напоминаю.В [88] ты утверждаешь, что именно наличие виртуальной машины и байткода позволяет достичь run-time верификации. Я тебе привел пример, что использование кода на delphi или например использование некоторого промежуточного представления в dcu(как это например делается для generics) и отдача этого в run-time компилятору командной строки позволит достичь той же цели.

> DVM (07.09.2010 22:24:58) [118]

Это таже самая кроссплатформенность, независимость ни от платформы, ни от
языка.
И неважно наплевать или нет, это было изначально заложено в платформу, а
будут или нет разрабатываться рантайм и комплиторы, это действительно особо
Микрософт не колышет, они дали для этого платформу.

> oxffff (07.09.2010 22:32:59) [119]

Какая еще виртуальная мвшина и байт код?

почему-то никого не удивляет, что все языки, на, допустим, x86-платформе, превращаются в набор команд процессора (который их тоже, по большому счету, интерпретирует в набор микропрограмм), а когда те же самые языки превращается в аппаратно-независимый набор команд, тут же начинаются вопли, что это не кросс-платформенно, медленно и вообще мастдай

> oxffff © (07.09.10 22:32) [119]
> По мне так растет лишь разнообразие синтаксиса, а механизмы
> становятся идентичными.

На этом дискуссию можно сворачивать, ибо мы исходим из слишком разных оценок существующих в .net языков. Что бы продолжать обсуждение надо качественно перетереть экосистему .net и живущие в ней языки.

> Фундамент CLR
> статическая типизация, ООП, делагаты, F-bounded полиморфизм,
> сборка мусора.

С этим не спорю. Напоминаю лишь еще раз, что фундамент - это фундамент. На его базе может быть построено нечто совершенно иное, равно как на фундаменте Wintel строятся совершенно разные языки.

> C#, Oxygene, VB#, Pascal.ABC, F#, Nemerle, Eiifel ...
> Напоминает лозунг: А у вас уже есть LINQ? Лямбды? Замыкания?
> Функции высших порядков? ...
> плюшки одних языков пошли в другие.

Абсолютно то же самое наблюдается и в нэйтиве.
Языки тырят друг у друга идеи только в путь.
Но конвергенции пока нет.

Кстати, посмотри на JVM. Там тоже есть целый зоопарк языков, в том числе и радикально отличающихся от самой Java. Это при том, что JVM более консервативна, чем .net. Там даже дженерики реализованы чисто как compile-time фитча без поддержки рантайма. Тем не менее, поверх JVM реализуются очень интересные и совсем не похожие на Java языки. Например, Scala и Coljure.

> Насчет динамической типизации. Ну нет в .NET динамической
> типизации и не было. Однако, появился магический способ
> построенный на отражении и семантическом дереве, который
> позволяет добавить магию. И теперь я ожидаю посредством
> ООП абстрации все языки будут нацеплять на себя возможность
> построения семантического дерева в момент компиляции. Но
> это миф. Это уже язык в языке получается посредством ООП.
>
> А по честному костыли.

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

> Тебе и Рихтер не показатель?
> Перечитай внимательно, для того чтобы использовать тип одного
> языка в другом языке тебе нужно указать сборку и тип.

Рихтер хорошо пишет о том, как устроен .net. Но из его книг не следует ничего, что противоречило бы моим словам. На базе CLR можно реализовать ЛЮБОЙ язык, произвольно далеко отстоящий от MSIL концептуально. Просто чем ближе он будет к CLR, тем его реализация будет проще и тем меньше будет impendance mismatch при контактировании с экосистемой CLR. Я скажу больше - на любой платформе можно реализовать любой язык, вопрос только в сложности реализации.

> В твоем коде
>
> > .Net Framework:
> > let sayHelloDotNet who = Console.WriteLine("Hello from
> F#
> > via .Net, " + name + "!")
>
> Это что? Матчинг? Сим-салябин редукция?

Нет, матчинг был в другой части примера.
Здесь мы объявляем именованную функцию.
Кстати, матчинг поддерживается MSIL?
А алгебарические типы?

> Напоминаю.В [88] ты утверждаешь, что именно наличие виртуальной
> машины и байткода позволяет достичь run-time верификации.
> Я тебе привел пример, что использование кода на delphi
> или например использование некоторого промежуточного представления
> в dcu(как это например делается для generics) и отдача этого
> в run-time компилятору командной строки позволит достичь
> той же цели.

Напоминаю, что в [88] я сказал, что VM + IL являются средством для верификации программ, но я не говорил, что это единственно возможное средство :) Даже не говорил что лучшее.

> Alkid © (07.09.10 23:13) [123]

> Нет, матчинг был в другой части примера.
> Здесь мы объявляем именованную функцию.
> Кстати, матчинг поддерживается MSIL?
> А алгебарические типы?

Там вообще что еще и вызывается.

По остальному я так понимаю: Москва->Вобла->пиво. :)

> oxffff © (07.09.10 23:29) [124]
> По остальному я так понимаю: Москва->Вобла->пиво. :)

Вот это я понимаю, деловой разговор. А то всякие лямбда матчинги...
У тебя есть какие-то планы по набеганию на столицу?

> Alkid © (07.09.10 23:32) [125]
>
> > oxffff © (07.09.10 23:29) [124]
> > По остальному я так понимаю: Москва->Вобла->пиво. :)
>
> Вот это я понимаю, деловой разговор. А то всякие лямбда
> матчинги...
> У тебя есть какие-то планы по набеганию на столицу?

У меня нет. А у работодателя должны быть в следующем году.

Спустя восемь лет Найти похожие ветки