Re[2]: Java vs C# vs C++ - Философия программирования

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

_>>Да, и всё это является бледным подобием нормальных решений в C++ (или скажем в D). Причём не потому что Linq делали идиоты, а просто потому что C# не позволяет большего. Для настоящих умных решений требуется наличие элементов метапрограммирования в языке.
S> Тогда вам нужен Немерле, а он как известно на Нет

Для таких целей достаточно того метапрограммирования, что есть в C++.

_>>Там речь шла про Linq2SQL (и аналоги из других языков), где как раз происходит генерация текстовых запросов.
S>И я говорю, про Линк для ЕФ или ОДАТА или коллекций. Там абстрагируешься от того, во что в итоге преобразуется Линк. А еще блин метапрограммисты.

Так EF же генерирует текстовые запросы, не так ли? ) И этот код кто-то должен был написать. Так же как и в C++ есть аналогичные библиотеки.

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

_>Ну и? ) Ты по сути подтверждаешь мои слова. Да, и если что, можно быть лидером рынка и с 5% от него — всё зависит от расклада по остальным участникам. )))

Ну да, чуть не 99% у Джаваскрипта, а лидер популярности — С++

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

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

Каких ещё вендоров софта? ))) Там нет подобного рынка, т.к. нет никаких общих стандартов — прошивки не переносимы между разными железками. И да, там пока ещё чаще C, а не C++. В основном из-за инерции.

I>С автомобилями ровно то же. Кроме того, по известным мене проектам там необязательно С++, а часто более низкоуровневый язык, чтото среднее между фортраном и ассемблером. Но есть, кстати говоря, и Джава.

В подавляющем числе случаев там C, иногда чуть модифицированный. )))

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

I>>Джаваскрипт что ли стал уже сиплюсплюсом или что ?

EP>Поясняю. Нормального компилятора C++ -> JVM я не знаю

Лучше остановиться на этом и начать с того, почему же так вышло. До кучи, посмотреть в дотнет, там аналогичная ситуация. Мерять синтетику, как ты придложил, не интересно. Мерять нужно реальные задачи.

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

_>>Для динамических языков IDE в любом случае весьма слабые и не имеют особых преимуществ перед обычными мощными редакторами.
S> Значит ты VS не пробовал

Когда-то давно (во времена VS 6.0) это был основной инструмент, т.к. он на голову превосходил всех своих конкурентов. Но со временем он сдал свои позиции и мы перешли на более мощные IDE.

S> А вот я работая с 1С где интеллисенсе очень убогий это сразу чувствую. Смысл в подсказках плюс выявления синтаксических ошибок еще на этапе кодирования.

А ты что с чем сравниваешь то? ) В VS у тебя какой язык? ) Если C#, то это очевидно некорректное сравнение.

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

_>>Насколько я понял, Code First — это всего лишь какая-то библиотечка ORM. Какое это имеет отношение к абстракциям языка? ) Подобное можно ввести в виде библиотеки в большинстве современных языков. Кстати, как раз вопрос различных ORM (а так же их эффективности) и обсуждался в темке, на которую кинул ссылку Евгений. И судя по ней, к Entity Framework с большим сомнением относятся даже любители C#. )))
S> Это не библиотечка. Она входит в состав Entity Framework для отображения модели на БД. http://infostart.ru/public/393228/
S>А это ни что иное как абстракция. По ней генерятся прокси классы, миграция итд.

А Entity Framework — это не библиотечка? ))) А что тогда? )

_>>COM — это вообще внеязыковая технология. Если же обсуждать некие обёртки вокруг неё в конкретных языках, служащие для облегчения работы с ним, то таких библиотек опять же может быть множество. Кстати, какой конкретно аспект COM интересует? Создание своих объектов/интерфейсов. Или использование чужих?
S> COM в Net это совсем другое, так как идет скрещивание ужа с колючей проволокой.
S>Меня не интересует. Я знаю. А в 1С там голый IDispatch без tld и ITypeInfo. В С# разруливается через dynamic

IDispatch — это самый убогий подвид COM, предназначенный для поддержки таких языков как VB. Работа с этим интерфейсом из нормальных языков — это не понимание всех базовых принципов COM.

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

I>>Это мягко говоря, заблуждение. На все бытовые устройства будет хорошо если десяток вендоров софта и там далеко не факт, что будет целиком С++.

_>Каких ещё вендоров софта? ))) Там нет подобного рынка, т.к. нет никаких общих стандартов — прошивки не переносимы между разными железками. И да, там пока ещё чаще C, а не C++. В основном из-за инерции.

"Рынка нет"

Рынок это не стандарты, это спрос и предложение. Есть и то и другое. Стандарты — это регулирование рынка, а не его наличие.

И не надо искать там разное железо, там почти все одно и то же. Я ж сказал — около десятка вендоров. То есть, по большому счету, всего десяток команд пилит прошивки.

I>>С автомобилями ровно то же. Кроме того, по известным мене проектам там необязательно С++, а часто более низкоуровневый язык, чтото среднее между фортраном и ассемблером. Но есть, кстати говоря, и Джава.

_>В подавляющем числе случаев там C, иногда чуть модифицированный. )))

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

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

I>>>Джаваскрипт что ли стал уже сиплюсплюсом или что ?
EP>>Поясняю. Нормального компилятора C++ -> JVM я не знаю
I>Лучше остановиться на этом и начать с того, почему же так вышло. До кучи, посмотреть в дотнет, там аналогичная ситуация. Мерять синтетику, как ты придложил, не интересно. Мерять нужно реальные задачи.

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

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

S>> Это не библиотечка. Она входит в состав Entity Framework для отображения модели на БД. http://infostart.ru/public/393228/
S>>А это ни что иное как абстракция. По ней генерятся прокси классы, миграция итд.

_>А Entity Framework — это не библиотечка? ))) А что тогда? )

Это, внезапно фреймворк, для особо не умных там даже это в названии указано : Entity Framework

S>> COM в Net это совсем другое, так как идет скрещивание ужа с колючей проволокой.
S>>Меня не интересует. Я знаю. А в 1С там голый IDispatch без tld и ITypeInfo. В С# разруливается через dynamic

_>IDispatch — это самый убогий подвид COM, предназначенный для поддержки таких языков как VB. Работа с этим интерфейсом из нормальных языков — это не понимание всех базовых принципов COM.

IDispatch — это не com, а интерфейс. И предназначен он для поддержки сom'a языками без vtbl.

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

_>>Какая ещё динамическая типизация в C#? )))
S> ключевое слово dynamic

Это не имеет никакого отношения к динамической типизации в языке. В таком смысле можно и какой-нибудь тип Variant обозвать динамической типизацией. Или вообще указатель на IUnknown. )))

_>>Это всё уже давно обсуждалось на этом форуме. Главные преимущества Java и C# хорошо известны — эти языки позволяют достаточно безопасно использовать не особо квалифицированных программистов, что является крайне удобным для большинства не IT компаний (так называемый enterprise, но только своими силами, а не через заказ у профильных компаний).
S> То есть скорость разработки и инструментов не важны?

Важны. Но для мейнстрим языков (а у нас тут сейчас в обсуждение только такие и участвуют) это всё находится на приблизительно равном уровне. Собственно производители инструментов одни и те же обычно. )))

S>А вот представь, что я программирую на нескольких языках. Мне нужно найти примеры для решения огромного круга задач. Совместить их с 1С.
S>Для C# я нахожу все быстро и применяю.
S> Для большинства задач скорости выше крыши. Те недостатки которые есть не являются критическими, а в основных реалиях код на C# генерит тот же машинный код, что и C++.
S> А вот для многих и C# и Java тоже оочень сложны.

А я разве где-то говорил, что тебе надо переходить на C++ или ещё куда-то? )

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

S>>Мало того, за кучей может следить GC в отдельном потоке.

EP>Точно — конкурентная гадость, которая скорей всего не lock-free.

Специально не поленился и поисал для тебя
http://www.oszone.net/18549/

.NET 4.5 мы внесли некоторые изменения для более эффективного использования фрагментов памяти в LOH, особенно в плане того, как мы управляем списком свободной памяти. Изменения относятся к сбору мусора (garbage collection, GC) как на рабочей станции, так и сервере. Но обратите внимание на то, что это не отменяет лимит в 85 000 байтов на размер объекта в LOH.

Фоновый GC для сервера В .NET 4 мы включили фоновый GC для рабочих станций. С того времени мы все чаще наблюдаем использование куч с размерами в диапазоне от нескольких до десятков гигабайт. Даже такому оптимизированному параллельному сборщику, как у нас, могут потребоваться секунды на сбор столь больших куч, а значит, потоки приложения будут блокированы примерно на то же время. Введение фонового GC для сервера обеспечивает поддержку нашим серверным сборщиком параллельных процедур сбора. Это сводит к минимуму длительные блокирующие операции сбора мусора, почти не влияя на высокую пропускную способность приложения.

Если вы используете серверный GC, вам не нужно ничего делать для того, чтобы задействовать преимущества этой новой функциональности; фоновый GC для сервера выполняется автоматически. Высокоуровневые характеристики фонового GC одинаковы как для клиента, так и для сервера:
•в фоне может выполняться только полный GC (объектов поколения 2);
•при фоновом GC сжатие не осуществляется;
•активный (не в фоне) GC (объектов поколений 0 и 1) возможен в процессе фонового GC. Серверный GC выполняется выделенными серверными GC-потоками;
•полностью блокирующий GC также осуществляется выделенными серверными GC-потоками.

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

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

Тест на одной платформе — это оба компилера писаные именно под эту платформу.

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

_>>Каких ещё вендоров софта? ))) Там нет подобного рынка, т.к. нет никаких общих стандартов — прошивки не переносимы между разными железками. И да, там пока ещё чаще C, а не C++. В основном из-за инерции.
I>"Рынка нет"

Рынок это не стандарты, это спрос и предложение. Есть и то и другое. Стандарты — это регулирование рынка, а не его наличие.
I>И не надо искать там разное железо, там почти все одно и то же. Я ж сказал — около десятка вендоров. То есть, по большому счету, всего десяток команд пилит прошивки.

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

_>>В подавляющем числе случаев там C, иногда чуть модифицированный. )))
I>Не знаю где ты "подавляющее" увидел, но основные европейские концерны используют софт который к си имеет весьма далёкое отношение.

Эээ, что? ) Какие ещё концерны? ) Ты думаешь они могут выбирать? ))) Они же не являются производителями микроэлектроники (кстати, а вот таких производителей действительно уже можно по пальцам руки перечислять), а только пользуются их продукцией. Существует набор из нескольких архитектур, и для них соответственно пишут компиляторы с разных языков. Обычно это делает только сам производитель этих процессоров и обычно ограничивается языком C (или его модификацией). Причём там это всё достаточно убого и закрыто. Хорошо что в последнее время сильно развились ARM микроконтроллеры, для которых есть мощный gcc (с полноценным C++ и не только).

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

_>>А Entity Framework — это не библиотечка? ))) А что тогда? )
K>Это, внезапно фреймворк, для особо не умных там даже это в названии указано : Entity Framework

И в чём отличие от библиотеки? )))

_>>IDispatch — это самый убогий подвид COM, предназначенный для поддержки таких языков как VB. Работа с этим интерфейсом из нормальных языков — это не понимание всех базовых принципов COM.
K>IDispatch — это не com, а интерфейс. И предназначен он для поддержки сom'a языками без vtbl.

Я именно это и сказал. Использовать IDispatch из C++ — это от очень кривой архитектуры.

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

_>Так EF же генерирует текстовые запросы, не так ли? ) И этот код кто-то должен был написать. Так же как и в C++ есть аналогичные библиотеки.
Еще раз Linq это абстракция. Не важно, во что это транслируется
На самом деле нужно понять где область применения Net
В каких приложениях процент проседания на определенных задачах будет минимален.
1. Декстопные приложения где общее время выполнения кода минимально
2. Серверные ASP.Net HTTP сервисы WCF
3. Сейчас есть возможность создавать кроссплатформенные приложения для мобильных приложений и ASP net

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

инструмент, т.к. он на голову превосходил всех своих конкурентов. Но со временем он сдал свои позиции и мы перешли на более мощные IDE.

S>> А вот я работая с 1С где интеллисенсе очень убогий это сразу чувствую. Смысл в подсказках плюс выявления синтаксических ошибок еще на этапе кодирования.

_>А ты что с чем сравниваешь то? ) В VS у тебя какой язык? ) Если C#, то это очевидно некорректное сравнение.
TypeScript

Здравствуйте, alex_public, Вы писали:
S>> То есть скорость разработки и инструментов не важны?

_>Важны. Но для мейнстрим языков (а у нас тут сейчас в обсуждение только такие и участвуют) это всё находится на приблизительно равном уровне. Собственно производители инструментов одни и те же обычно. )))

S>>А вот представь, что я программирую на нескольких языках. Мне нужно найти примеры для решения огромного круга задач. Совместить их с 1С.
S>>Для C# я нахожу все быстро и применяю.
S>> Для большинства задач скорости выше крыши. Те недостатки которые есть не являются критическими, а в основных реалиях код на C# генерит тот же машинный код, что и C++.
S>> А вот для многих и C# и Java тоже оочень сложны.

_>А я разве где-то говорил, что тебе надо переходить на C++ или ещё куда-то? )
Раз все находится на одном уровне, то какой язык нужно выбрать?
Или все таки есть отличия? И вы применяете питон вместо C++.

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

_>И в чём отличие от библиотеки? )))

http://stackoverflow.com/questions/3057526/framework-vs-toolkit-vs-library

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

EP>>>>Дальше что? Ты так и не сказал свой основной тезис. Тебе не нужен C++ — ну и замечательно

S>>> Наконец то!
EP>>Ты ради этого развёл флуд? Чтобы намекнуть что лично тебе, для твоих задач C++ не нужен?
EP>>А — Адекватность

S> Я тебе специально стишок привел. Мамы разные нужны, мамы разные важны. Понадобится мне C++ поверь применю и его. Блюя, но применю.

А теперь прочитай мой первый же ответ тебе:

EP>>>По факту же в большинстве кода не нужны никакие владеющие указатели.
S>> Так в итоге C#, Java, JS в топку? Все на С++?

EP>Не, не в топку. Я сам частенько использую Python. И по секрету скажу, недавно даже на C# написал несколько сотен строк — правда это был пример использования C++ библиотеки, но тем не менее.
EP>А вообще непонятно как ты сделал вывод про "в топку"

То есть ты сам придумал что "C#/etc в топку", и сам же пытаешься это опровергнуть. Это вообще какая-то жесть

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

EP>>1. Про замыкание результаты в первом сообщении темы — ввод замыкания на C# дал десятикратное замедление и гигабайты аллокаций. На C++ результат идентичен ручному коду. Или ты хочешь сказать что C# без замыканий мог обогнать C++? — не, несерьёзно.
S> Так дай конкретную ссылку. Я не ленюсь и даю людям информацию.

Ты издеваешься? Ссылка была буквально чуть выше, в том что ты только что удалил отвечая на сообщение:

EP>>>Чем пример про замыкание
Автор: Evgeny.Panasyuk
Дата: 23.12.14
не устроил?

S>А когда говорят об гигабайты аллокаций это вообще сумасшедший сценарий и неправильный выбор алгоритма.

Алгоритм тот же самый

Разница только в наличии/отсутствии замыканий.

EP>>>>Ты не учитываешь например указатели на стэке. Предполагаю что ситуация в которой в нулевом поколении не выжил никто — маловероятна.
S>>> Она как раз самая, что вероятная, особенно в серверных вариантах.
EP>>Приведи статистику.
S> Почитай статей огромное количетво.

Я вижу огромное количество статей и советов как не обжечься на GC.

S>>>Мало того, за кучей может следить GC в отдельном потоке.
EP>>Точно — конкурентная гадость, которая скорей всего не lock-free.
S> Я давно не интересовался. Меня GC давно не беспокоит. Только вызываю его при работе с ком.

Я тебя поздравляю, действительно есть задачи где от него нет проблем. Я в первом же сообщении этой ветки тебе сказал что сам частенько использую Python.

S>>> Ну ты же поешь, про то что на C++ можно делать все.
EP>>Где? Это враньё.
EP>>Ты не знаешь C++, и делаешь предположения что там нет какой-то фичи, хотя она есть, или что там нужно писать жутко уродливый код, хотя и это не так.
EP>>Я и отвечаю — мол то-то и то-то реализуется. Из этого не следует что на нём можно всё.
EP>>Есть реальные пробелы, но ты их не указываешь

S> Ну так почему столько программистов 1С программирующих на чудовищно медленном интерпретаторе. Значит скорость бизнес слоя в итоге не важна.

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

S>>> На ваши итераторы без слез смотреть тяжело.
S>>>...
EP>>Ты показывал что-то про коллекции?
EP>>Вот пример Boost.Range для коллекций:
EP>>

EP>>values | filtered(_1 > 5) | transformed(_1 * 111)
EP>>

причём на выходе можно получить bidirectional range.
EP>>Покажи аналог LINQ — сравним выразительность.
S>

S> from value in values
S>where value > 5
S>Select new {value* 111}
S>

S>или
S>

S>values.where(value =>value > 5).Select(value =>value* 111)
S>

Сравниваем. Вариант Boost.Range:
1. Лаконичнее, красивее.
2. Быстрее. Там под копотом кстати те самые итераторы.
3. Выдаёт bidirectional последовательность вместо forward/single pass.

S>>>>>// Этот запрос получает значения периодического реквизита с ID 9697 в порядке убывания даты, времени, и строки документа
S>>>>>...
S>>>>>Генерируется следующий запрос
EP>>>>Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме.
S>>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.
EP>>В результате генерируется текст запроса, так понятнее
S> В итоге мне наплевать, вто что трансформирутся Linq запрос.

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

	От:	alex_public
	Дата:	04.10.15 15:03
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	04.10.15 15:06
Оценка:

	От:	alex_public
	Дата:	04.10.15 15:07
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	04.10.15 15:09
Оценка:

	От:	alex_public
	Дата:	04.10.15 15:11
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	04.10.15 15:20
	Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	04.10.15 15:32
Оценка: