Что ты называешь промышленным кодом?

код, который используется в промышленности

Система автоматической классификации фоток с микроскопа рак/не рак?

например. а так же системы автоматизации банкинга, АРМы и инфраструктура железнодорожных компаний, существенное количество сайтов на ASP.Net. да мало ли чего - поинтересуйся, на кого работают C#-программисты во всяких Luxoft'ах

Самое серьезное применение шарпа

у Sing# с шарпами общего мало

профейлилось

вообще-то - успешно завершилось. можешь показать хоть один отчёт с констатацией провала?

но уровень логических заключений мне понравился. вот, например, самое серьёзное применение языка C - ядро HURD. сколько лет завершается? с каким успехом?

нет, только обычная очередь, STL поддерживает многопоточность?

имутабелность строк, UCS-2 как внутренняя кодировка

печально, но надо было предусмотреть

http://blogs.msdn.com/b/ruericlippert/archive/2011/08/08/strings-immutability...

Все уже предусмотрено :) Меньше всего Хейлсберга и Ко волновала печаль неправильно юзающих строки С#. Не фиг конкатенировать через + и все нормально будет.

Ну померить, как оно будет. :)

＞Не фиг конкатенировать через +

Сначала изобретём себе проблемы… :]

А зачем JIT?

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

добавить примитивный JIT, и разница станет малозаметной

мне тут заявляли, что и без JIT байткод рулит.

Проблемы у doing it wrong будут всегда. Ныли про неправильные, «самострелоопасные» плюсы? Ок, нате безопасные и огороженные жабы с шарпами. Но определенный сорт людей будет жаловаться всегда: при любом правительстве и с любым инструментом, который им непременно подсунули враги, у которых конечно же есть хитрый коварный план. Анекдот про стеклянный 5.1 же :)

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

Это yield return в C# умеет. Может это и удобно иногда... Но я пока не испытывал необходимости в таком трюке. Генераторы - делал, да. Но в итоге ж всёравно итератор получается, просто последовательность в памяти не висит...

Нужно ли C++ менять синтаксис?

Менять - может и нет, согласен. Тут я погорячился.

Примеры того, что нужно возложить?

Выше упоминали кортежи. Я бы не отказался от них в C++ на уровне языка, а не на уровне библиотеки, т.к. иногда приходится объявлять структуры из-за пары функций. Сахар в виде yield. Это то, что прямо сейчас в голову приходит.

Где?

Как раз логично, т.к. ИМХО нет смысла плодить отдельные лишние сущности, как это сделано в C# и Java.

Вот тут и кроется маленькая разница между нами. Я в такой ситурации предпочту чуть-чуть сахара для отделения паттерна «интерфейс» :)

Серебряная пуля, которая реально работает, есть только одна. В голову мечтателей о серебряной пуле :) Но она сильно проигрывает свинцовой.

jtootf:

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

вот я и продемонстрировал пример

Где вы увидели серебряную пулю? Идите уже спать, вам явно пора.

А проверить действие с числами на переполнение? А перейти к длинной арифметике, если значение не поместилось?

Серебряная пуля - она вечна (если хотите, персистентна в программистском коллективно бессознательном) аки грааль в ПГМ, независимо от того, видите вы ее, или в упор не замечаете в своем смутном желании некоторого «ползучего улучшизма», который всегда корнями находится в желании внезапных перемен к лучшему (совпадения с ожиданиями), которое, ЧСХ, не проходит независимо от любых перемен (и совпадения редки). «Менять синтаксис», «обсахаривать» его всякой модной всячиной можно бесконечно. Исполнятся ваши мечты об улучшениях (в виде очень нужной вам yield'ы) - мало того, что найдется толпа недовольных, так еще и у вас щастья не прибавится :)

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

А потом еще чуть-чуть... И еще :)

Любую программу можно улучшить/упростить. Главное, с критериями определиться :)

Я про то, что в данном случае какая-либо значительная разница между компилируемым и интерпретируемым вариантом стирается. А в питоне помимо intов и bigintов есть ещё floatы и прозрачная поддержка комплексных чисел >_<

По недавней статистике ASP.NET это около 23% сайтов, овер 75 на похапэ. И похапэ все больше. Так что лидером веба я бы не назвал это дело.

На С сейчас написаны ядра линуха (спроси у Линуса почему не на плюсах) и *сюрприз* NT. И уходить оттуда оно как-то не собирается. И еще оверстотыщ разных ртосин на любой вкус и цвет.

Сингулярити насколько я читал громкие новости уже к 2010 позиционировали как ядро будущей винды. Но однако Win8 все еще на том же NT ядре. Писать же дрова в менеджед коде это крайне странный подход, как мне кажется. И то, что за все время своего существования оно не выползло куда-то за пределы MS research уже показатель.

Опять таки, из личного опыта, 90% задач ради который расчехляют шарп, я делаю либо в двадцать строчек на баше, либо беру эрланг/питон, хоть последний и недолюбливаю.

и *сюрприз* NT

Сюрприз для тех, кто не знает, откуда растут ноги NT, с чего ворова^Wтворчески заимствовался код беглым Катлером и командой, и в каком состоянии в то время были плюсы с точки зрения написания действительно сложных систем с какой-никакой переносимостью :)

лидером веба я бы не назвал

и я бы не назвал. и что?

*сюрприз*

для кого?

оверстотыщ разных ртосин

а поверх этих ртосин работают высокоуровневые языки. и, опять же, что с того? если ты принял мой сарказм за искреннее мнение, то вынужден тебя разочаровать - я не считаю HURD единственной целью существования языка C. равно как не считаю таковой Singularity для C# (тем более, что, как я уже заметил, Singularity написана не на C#)

насколько я читал громкие новости

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

то, что за все время своего существования оно не выползло куда-то за пределы MS research уже показатель

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

90% задач ради который расчехляют шарп, я делаю либо в двадцать строчек на баше, либо беру эрланг/питон, хоть последний и недолюбливаю

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

благая весть
C# наконец-то обогнал С++

а казачок-то засланный!

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

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

имутабелность строк, UCS-2 как внутренняя кодировка

печально, но надо было предусмотреть

http://blogs.msdn.com/b/ruericlippert/archive/2011/08/08/strings-immutability-an...

Все уже предусмотрено :) Меньше всего Хейлсберга и Ко волновала печаль неправильно юзающих строки С#. Не фиг конкатенировать через + и все нормально будет.

Как на счет разбиения строки на подстроки?) Следует отметить что те же проблемы присутствуют в JVM и механизмы обхода их тоже есть, но это не отменяет саму проблему.

сомневаюсь в никогда

ну что ж, ymmv. мне подобного встречать, к счастью, не довелось

Тоже мне, благая весть...

Это ещё что ты почитай выше, тред вендузятников и яволюбов.

Лишь бы не Ruby!

Чуть-чуть сахара - это еще одно усложнение языка. C++ и так достаточно большой, для его усложнения (и уж тем более для введения компонента, который заменяет уже присутствующие), ИМХО, нужен весьма весомый повод.

Или тебя настолько утомляет писать virtual для каждого метода? (меня вот гораздо больше утомляет C# и Java, где для каждого метода нужно писать спецификаторы доступа...)

C# есть и в Linux :)

Или тебя настолько утомляет писать virtual для каждого метода? (меня вот гораздо больше утомляет C# и Java, где для каждого метода нужно писать спецификаторы доступа...)

На C# я пишу только в VS, а с тамошним автокомплитов таких мелочей вообще не замечаешь.

Мне в этом не нравится то, что вместо введения банального слова interface нужно делать class с virtual методами которые ещё и = 0. Это какой-то костыль имхо.

Чуть-чуть сахара - это еще одно усложнение языка. C++ и так достаточно большой, для его усложнения (и уж тем более для введения компонента, который заменяет уже присутствующие), ИМХО, нужен весьма весомый повод.

Таки да, именно поэтому ничерта не поменяют и C++ будет всё больше задыхаться от своей сложности. Ну и чёрт с ним)

Позор ЛОРу!

И откуда столько народу нетрадиционной ориентации повылезало?

На C# я пишу только в VS, а с тамошним автокомплитов таких мелочей вообще не замечаешь.

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

Мне в этом не нравится то, что вместо введения банального слова interface нужно делать class с virtual методами которые ещё и = 0.

interface == class, у которого все методы абстрактные (хотя =0 - это ИМХО не лучшее обозначение для абстрактных методов, которое можно было придумать (хотя я отлично понимаю причины, по которым было введено такое обозначение, но это не делает его лучше)). Вот и единственный минус C++-ного объявления - нужно для каждого метода писать virtual и =0.

[благая весть][mono]C# наконец-то обогнал С++ в рейтинге TIOBE !

Воистину, Шайтанама воскресе.

Каким бы хорошим ни был автокомплит, даже несмотря на то, что сейчас он есть везде

Есть то он есть, но вот его качество может различаться на порядки. В той же VS2010 качество автокомплита для C# и C++ оч. различается. Ну а то, что ты им не пользуешься - это уже твоё личное дело, а я слишком ленив, чтобы не использовать его :)

interface == class, у которого все методы абстрактные

Тут уже будет чистый холивар множественное наследование vs интерфейсы и одиночное наследование. Не хочу в него скатываться. А причины = 0 я тоже понимаю, но код от этого удобоваримей не становиться увы.

Честно, я не особо следил за сингулярностью. Но основная фича ее, в принципе понятно - дрова на манагед коде, что делает ее якобы «непотопляемой». Очень малая часть сингулярити на asm/c++. И все же реального применения этому выc^Wэксперименту не видно. В тоже самое время, многие другие «чисто исследовательские» в самом начале проекты вполне себе сейчас занимают коммерческую нишу. А учитывая как микрософт любит тянуть в продакшн новые «революционные» технологии, которые сам потом закапывает, я до сих пор удивляюсь как код сингулярити никуда так и не попал.

Если просуммировать почему лично меня не устраивает шарп:
* Мутная лицензия (не верю я в эти заверения мс)
* Завязки на win32 (моно в догоняющих, фичи не все умеет, а что-то Мигелюшка вообще хотел запилить «не как у всех». Кстати чем закончилось?)
* Как и 1С: плодит кучу малоадекватных людей мнящих себя богами программирования и производящих костыли.
* Следствие из пред. пункта: Намного выше вероятность присоединившись к проекту увидеть в сырцах лютую содомию, от которой хочется перестрелять всех.

джавой от MS C# был во времена .Net 1.0.

Так ЧЕМ он все таки лучше джавы?

Ну у NT ноги растут из VMS (так оно вроде называлось). Но с тех пор ядро знатно «мутировало».

Есть то он есть, но вот его качество может различаться на порядки.

Например, в MonoDevelop автокомплит для C# ничем не хуже, чем в MSVS.

В той же VS2010 качество автокомплита для C# и C++ оч. различается

Это везде так. Написать одновременно быстрый и качественный автокомплит для C# намного проще, чем для C или C++ (хотя, есть примеры абсолютно точных и достаточно быстрых реализаций автокомплита и для C и C++). Кстати, можно засчитать как недостаток этих двух языков (обусловлен препроцессором и шаблонами).

* Мутная лицензия (не верю я в эти заверения мс)

На моно - не мутная :)

* Завязки на win32

В моно - нет. А вне моно нет кроссплатформенности :)

Моно повторяет реализацию МС, и обречено быть в догоняющих.

Не повторяет.

как микрософт любит тянуть в продакшн новые «революционные» технологии, которые сам потом закапывает

не надо путать MS Research и MS. при общем источнике финансирования, это две компании, имеющие существенно разные цели. в первой, к слову, большая часть сотрудников работает под Linux

код сингулярити никуда так и не попал

код сингулярити вряд ли куда-либо когда-либо попадёт. код проектов, основанных на неё - вполне может

моно в догоняющих, фичи не все умеет

Mono - это аналог .Net, а не C#. поддержка языка в Mono сделана достаточно хорошо (вплоть до C# 4.0)

плодит кучу малоадекватных людей мнящих себя богами программирования

любая технология плодит таких людей. Haskell, CL, C++, Java, C - кругом есть ушибленные фанатики

Намного выше вероятность присоединившись к проекту увидеть в сырцах лютую содомию

ко многим проектам на C# ты присоединялся? модульность у него получше, чем у того же C++, да и тёмных углов стандарта поменьше

Так ЧЕМ он все таки лучше джавы?

вот списочек. обрати внимание на количество отсутствующих фич у Java и на скорость впиливания оных в один и другой язык

Моно повторяет реализацию МС

вообще-то, нет. как минимум, Mono не реализует и не использует COM (отсюда, к слову, масса проблем с переносимостью и интероперабельностью)

обрати внимание на количество отсутствующих фич у Java и на скорость впиливания оных в один и другой язык

ты ещё скажи, что C++ лучше C, потому что там фич больше.

ты ещё скажи, что C++ лучше C, потому что там фич больше.

речь идёт о фичах, которые обеспечивают ту же функциональность при большей лаконичности кода

но вообще я не заметил постановки вопроса: изначально я утверждал не превосходство одного языка над другим, а факт различия их возможностей. C# 4.0 - это не Java от MS. C# 5.0 - это совсем не Java от MS

Так эт к слову, почему в NT используется С для ядра. «K & R» в инкарнации Dec C/VAX C(он же «HP C»/«COMPAQ C»), наверное, было проще адаптировать к MSVC привычным к нему программистам, чем перестраиваться на НЕХ «Си с классами», для которой еще и стандарта не было де факто, не говоря о комитетах по стандартам. А «мутации ядра» уже погоды не делали: проект определился своим наследием (более того - установкой на обратную совместимость с хреновой тучей унаследованных приложений) и проектными решениями, которые сейчас можно огородить заборами из костылей и подпереть велосипедами, но не изжить, пока NT-шная линейка не заменится чем-то «принципиально новым, с нескучными обоями».

А как же D?