Среды разработки уже давно умеют выравнивать в соответствии с предыдущей строкой. А ещё есть такая магическая команда как автоформат.
Это надо было наверное лет 30 на необитаемом острове провести, что бы пропустить такой прорыв.
Что значит будут плавать? У каждого своя IDE со своими настройками, каждый видит код именно так как он настроил отображение в своей среде разработки. Так что это вообще никого не должно касаться у кого какие табы — это дело вкуса, который не уходит дальше разработчика. Или погромисты нынче бедные пошли и и работают на одной машине в блокноте вдесятером по очереди?
Тем более табуляция сохраняет пропорции в коде независимо от разрешения экрана.
А вот с пробелами как раз все плывет: кто-то любит дважды жахнуть по клавише, кто-то четырежды, кто сидит за моником 4:3, кто-то за 16: 9, а кто-то 16:10. Табуляция позволяет сохранить пропорции отступов, пробелы нет.
Детский сад какой-то. Не, ну можно, конечно, отказаться от табуляции, всех обязать печатать определенное количество пробелов в той или иной ситуации, посадить за одинаковые машины, одинаково постричь(налысо) и одеть, пришить номера на одежду, а печатать синхронно с в темпе барабанщика (или надзирателя с хлыстом) — ляпота…
В общем виде — ничем. Все мета-эвристические алгоритмы можно свести к (или вывести из) генетическим алгоритмам.
Вся разница только в особенностях применения и реализации их эвристик: как осуществляется поиск и исследование в решений. На простых функциях они все в итоге дают похожий результат, а вот для сложных задач: на разных задачах разные алгоритмы ведут себя по-разному. Гибридные методы работают надёжнее.
Также вполне естественно, что человек, который перебирает таких бумажек в день сотни и вынужден продираться через чью-то безграмотность, будет, как минимум, раздражен
Вполне естественно, что он даже не заметит с вероятность 145% (ну если ему специально не приплачивают за проверку орфографии).
Внезапно, человеки читают не по слогам как школьники, а распознают слова в тексте по общему очертанию, первым и последним буквам, ну и по контексту. При этом, если сознание не заострено на орфограммах, то для читающего нет особой разницы между «искусством» и «искуством». Иными словами, нормальный человек, вообще не читает текст в школьном смысле. Он смотрит на кусок, и сразу понимает его смысл. А вот излишнее «заострение» уже кагбэ намекает на некоторые проблемы, например, такое наблюдается при церебральном атеросклерозе, да и не только при нем — вообще это относится ананкастному (обсессивно-компульсивному) расстройству личности.
Подумайте, как это повлияет на ответ
Если повлияет, то гнать такого чиновника поганой метлой. Такие запросы должны рассматриваться только «по-существу», и никак иначе, чай работать пришел, а не свататься по деловой переписке.
А есть вообще такое заболевание — дисграфия называется, когда человек в принципе не может писать без ашипок (грубо говоря). Примерно каждый 10-ый страдает таким расстройством, но на общее развитие интеллекта это как правило не влияет. Понятно, что это очень удобно — писать отказы по какой-нибудь явной причине, например, потому что у человека нет ноги или волосы не того цвета, но в цивилизованных странах так не принято.
Так что VenomBlood прав — англоговорящие (за исключением англичан) действительно не заостряют внимание на уровне владения письменным и устным английским языком (вероятно это считается неприличным, так-то), конечно, если это не входит в профессиональную компетенцию (это отдельная тема). И кстати да, в инглише нет никакого единого регулятора языка, иначе бы не было всех этих: «defense», «color», «no worries», «lighted», «wanna», «doco», «freeway» и миллионы других океюшек. Отношение к языку у них более чем свободное.
Как там обстоит дело со скоростью например при работе с охрененно гигантскими матрицами? Ну там крутить-вертеть их туда-сюда, перемножать и т.д. и паралельно крутить мозгокрутные конечные автоматы, ну и так далее?
А чем это отличается от G/LabVIEW? Там конкурентность и параллелизм на уровне синтаксиса. И кстати Alice еще есть. По идее можно было бы наверное и Verilog с VHDL вспомнить, там правда конкурентность ИМХО под вопросом, т.к. определяется таймингами, но зато там чистый параллелизм. Еще наверное можно и Erlang с Go сюда же добавить (ну или хотя бы объяснить разницу, если нет).
Язык Aurora — образчик символического программирования.
Опять таки не упомянули LabVIEW — куда более известная и устоявшаяся штука (в отличии от Авроры, которую походу вообще ради фана делали), а также VisSim, SystemView, и JMCAD, а также все языки стандарта IEC 61131-3 и их потомки(символическое/графическое программирование, наверное наверное самое распространенное для промышленного программирования управления охрененно больших и дорогих штук). Ну Наверное еще и HiAsm и Simulink — правда я хз, можно ли вот эти два считать уже полноценными ЯП или нет.
Требуем больше хлеба и зрелищь больше примеров и сравнений!
Ну тут гипербола. Просто оперировать «вот мы щас пилим проект на Расте и нам этого достаточно» — выглядит не совсем корректно. Я вот как-то запилил целый Asteroids на F# (самом деле XNA+C#+F#), но это не делает его языком выбора, не смотря на все его достоинства и няшность. И естественно я никому его не навязываю (не смотря на его няшность). И даже кое-что на Расте заговнокодил (есть у меня подозрение, не для того, для чего его обычно используют), что и его не превращает в язык выбора (тем более F# няшнее)…
А еще у меня в универе был знакомый который на протяжении нескольких лет запилил на асме игровой движок (ТрыДэ!) — что, конечно, круто, но не понятно, нафига это. Ну в общем хвалиться не прикольно.
Впрочем у Раста в этом плане все же дела лучше — хз на сколько, но вот про вакансии Java-программистов с опытом разработки в Rust и Golang 0_0 я уже слышал, ну и по крайней мере его хотя бы Samsung начал активно педалить. Но все равно пока это «самый любимый язык программирования на котором никто не кодит» https://stackoverflow.com/insights/survey/2016#technology-most-loved-dreaded-and-wanted
а самымой популярной технологией по-прежнему остается богомерзкий ЖабаСкрипт https://stackoverflow.com/insights/survey/2016#technology-most-popular-technologies
Хз, может он и через пару лет выбъется в топ-20 используемых языков общего назначения (и холивары Go vs Rust станут еще более острее, что не может не огорчать)
Сообществу .NET был предоставлен сразу рабочим (ну почти, где-то за год подписчики msdn получили бета-версию .NET, меня в их числе естественно тогда еще не было — я с говнокодингом на нем познакомился лишь в 2005 году), после чего он очень шустро был стандартизирован, и тут же пошел в продакшен и начал набирать популярность. Java конечно он не переплюнул, но вполне с ней конкурирует и даже вопреки политике Microsoft стал кросс-платформенным языком, да и Java куда старее и к моменту появления C# у неё уже было устойчивое сообщество погромистов. И всю свою публичную историю существования этот язык идет по пути расширения и добавления новых свистелок и переделок.
И это важно, т.к. предыстория появления языка может быть очень долгой и богатой — вообще C# можно считать потомком Delphi, создавали их одни и те же люди, вообще папа Delphi и C# — создатель компилятор Turbo Pascal, так что при желании можно отследить историю языка начиная с даты рождения Вирта. А еще у Корпорации Добра была своя Жаба.
Но вот история конкретно языка начинается все же с его обнародования и начала использования — официальная дата его рождения: 2000-ый год (я так понимаю его тогда анонсировали), а в 2002..2003 пришла Visual Studio.NET где он был. Так что история использования языка и платформы .NET начинается с 2002 года. Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).
Причём мне что-то подсказывает, что видение конечного результата было уже сформировано.
Об этом я собственно и толкую. С видением проект у создателей Раста явно какие-то проблемы (но сейчас вроде обещают, что все стало норм), а вот у создателей его ровесника (и вероятно конкурента) — Golang, который тоже кстати показали людям до того как выкатился в релиз, с этим дело обстоит вероятно несколько лучше. С видением всяких Java и прочьих дотНетов вероятно вообще все замечательно.
Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.
Об этом я тоже где-то здесь уже писал (Оракл и его тысячи и тысячи индусов). Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL. А еще вот всопмнился язык D — его тоже одиночки поднимали. Не сказать что он убер-популярный, скорее совсем непопулярный, но кое-кто им пользуется, я даже кусок живого проекта на нем видел.
Ок Гугл, покажи мне Nelder-Mead: Languages
14 C#
13 C++
11 Python
4 C
2 JavaScript
2 Jupyter Notebook
2 Matlab
1 Go
1 Java
1 Julia
Хм… чего-то не хватает. Ок, Гугл, нука покажи nonlinear optimization: Languages
26 Matlab
17 C++
14 C
11 Python
6 Java
6 R
5 Julia
4 Fortran
4 Jupyter Notebook
3 Haskell
Хм… Хаскель — есть, C# — есть, Фортран — есть, Джулия — есть, Пухтон тоже есть, как и R, C/C++, C#, Java, внезапно даже сбаж [если не забыли, то говорили о Go] есть.
Хм, что я делаю не так? Ах да, точно, можно же было бы посмотреть сводную статистику, например тут https://octoverse.github.com/
Понимайте, мне нет нужды целенаправленно выискивать сорцы языка Мозиллы и прожектеров, т.к. есть 20 десятка наиболее везде-используемых языков + нишевые специализированные языки (типа Verilog или VHDL), на половине из которых я худо-бедно говнокодю. А еще на них говнокодят миллионы других людей, а еще больше пользуются их продуктами.
А вот по логике веще, что-то выискивать и показывать должны фанбои Раста. В контексте холивара я даже привел пример Докера и список компаний использующих Golang, в ответ: какие-то скриншоты и обещания: «вот мы на нем говнокодим, скоро-скоро будет релиз, и вы все офигейте».
Но вообще-то для конструктивной беседы было бы хорошо провести сравнение с языком сабжа [еще раз напомню — это Go]: какие компании пользуют, сколько выпущено реальных проектов, какой был получен перфоманс в индусо-часах при переводе проекта на этот язык, сделать разбивку по нишам и секторам, ну и провести прочий серьезный анализ. И все это даже влезет в компактную таблицу, которая будет играть явно не в пользу Rust. При этом Go и Rust вообще-то ровесники.
Может быть, когда-нибудь, когда на Марсе начнут сажать яблони (а может даже и завтра), к Rust проснется вторая волна интереса и на нем начнут массово писать, тогда да, тогда Rust будет интересен, сейчас куда более интересен тот же COBOL, например.
Нет, просто я не очень понимаю:
1) Какое это имеет отношение к сабжу (если забыли, то это Go)
2) Как это имеет отношение к срачу про наследование
То что Вы осилили Java.lang.Thread.getStackTrace() меня, конечно, несказанно радует, но не обязательно об этом на каждом углу кричать? А то вдруг набижит бородатый погромист и выложит свой дамп :-)
С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.
С таких, что компонентно-ориентированное программирование это независимая парадигма программирования, которая была придумана Виртом для решения проблем внезапно возникших у ООП, и реализованная в языке, который является ОО менее чем никак
https://ru.wikipedia.org/wiki/Оберон_(язык_программирования)
Оттуда КОП ушло в ныне мейнстримовые языки и стало их частью, т.к. действительно, в большинстве случаев композиция предпочтительнее наследования. Тут же на хабре, уже ни раз обсуждали разницу между КОП и ООП.
Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API
Вот только недавно это на работе обсуждали, правда в контексте Python 2 RIP: программа написанная на С++ в 1989 году, компилится в 2017, программа написанная на C# под .NET 1.0 в 2002..2003 годах (язык был стандартизирован по ISO в 2003 вроде бы, а бета-версию вроде как опубликовали эдак в году 2001), точно также внезапно скомпилится и заработает в 2017 году. Хотя там тоже бывали костыли, например, до появления Джнерик-типов в .NET 2.0, в общем обратная совместимость худо-бедно выполняется. Хз, чего там у Жабы — не занимался такой глубокой интроспекцией в ней, но думаю худо-бедно норм.
Однако в большинстве своем все не так безоблачно.
Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?
Ну потому что, то что зарыто внутри фреймворка, разработчика уже не касается, т.к. отнаследовавшись один раз для него вот энта проблема:
https://ru.wikipedia.org/wiki/Хрупкий_базовый_класс
еще не актуальна, все что внутри фреймворка — это уже головная боль его создателей. К счастью, у них индусов (в штате, на аутсорсе, на аутстафее) вероятно больше чем классов а также есть вумные архитекторы-надсмоторщики с кнутами, так что они могут себе позволить сопровождать, поддерживать и развивать ПО где объемы наследования очень-очень велики.
Так что в условиях неограниченных ресурсов (как индусо-часы, так и ресурсы вычислительных машин) — это работает. Но у большинства ресурсы ограниченные — и тут выясняется, что сложность программы (как разработки, так и цикломатическая сложность) растет экспоненциально от глубины наследования. В тоже время какой-то учитель математики по фамилии Степанов в 3.5 написал STL, которая уже больше 20 лет успешно используется и включена в стандарт. Заранее предупрежу, что STL это тоже не про ООП, а Степановтак вообще один из самых ярых критиков ОО-подхода.
Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах.
Слабое мобильное устройство — это Нокиа 1100, еще космические спутники (там до сих пор летают на 51-ой архитектуре и килобайтами памяти). А современные говносмартфоны и говнопланшеты по вычислительной мощности круче домашних писюков начала 2000-ых. К слову сказать Unreal и Quake были изначально написаны на чистом Си еще в 90-ых
Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.
Вы просто всего 2 движка знайте
… способен выдавать 60+ fps сложной логики с физикой....
Уравнения Максвелла тожее умеет решать, или кварк-глюонную плазму смоделирует? В физике там ничего особенного: коллизии, 2-ой закон Ньютона, уравнение движение и т.п. — примерно 1-ый курс… потом студенты в рамках лабораторных работ/курсовых сами пишут куда более сложные физические модели.
способен выдавать 60+ fps
Если там на сцене живет 3.5 МоноБихеавор, то да, а так:
https://forum.unity3d.com/threads/general-performance-optimization-tips-for-unity.386338/
В общем удже давно известно, что производительность и Юнити ТрыДэ это несовместимые понятия. Но Unity3D не за это любят, а за
Это универсальный игровой движок
Но за все надо платить https://ru.wikipedia.org/wiki/Технический_долг
Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.
Обычно там внутри что-то типа такого:
https://www.youtube.com/watch?v=rX0ItVEVjHc&t=270s
Что тоже не ООП. У меня вон тоже, когда говнокодю на C# начинают плодиться всякие unsafe:
public unsafe static Matrix UnsafeMultiplication(Matrix A, Matrix B)
{
int h = A.Height;
int w = B.Width;
int l = A.Width;
Matrix resultMatrix = new Matrix(h, w);
unsafe
{
fixed (double* pM = resultMatrix._matrix, pA = A._matrix, pB = B._matrix)
{
int indexA, indexB;
for (int i = 0; i < h; i++)
{
indexA = i * l;
for (int j = 0; j < w; j++)
{
indexB = j;
double result = 0;
for (int k = 0; k < l; k++, indexB += w)
{
result += pA[indexA + k] * pB[indexB];
}
pM[i * w + j] = result;
}
}
}
}
return resultMatrix;
}
Это примерно раз в 10 быстрее чем вот такое:
public static Matrix NaiveMultiplication(Matrix A, Matrix B)
{
Matrix resultMatrix = new Matrix(A.Height, B.Width);
for (int i = 0; i < resultMatrix.Height; i++)
{
for (int j = 0; j < resultMatrix.Width; j++)
{
resultMatrix[i, j] = 0;
for (int k = 0; k < A.Width; k++)
{
resultMatrix[i, j] += A[i, k] * B[k, j];
}
}
}
return resultMatrix;
}
Правда unsafe это вообще не про .NET, а так — грязный трюк (да, мыши кололись, плакали, но продолжали жрать кактус). И ООП тут встречается в гомеопатических количествах, лишь при описании собственного класса Matrix. Впрочем к версии 4.5 .NET все же узнал, шо есть такая офигенная штука как SIMD (Intel Pentium MMX, 1997 год, 16кБ L1, 166 МГц), так что жить стало лучше, жить стало веселее.
Потом да, потом это все будет обернуто со стороны клиента уже в читабильный ООП-код
Странно шо Вы не выложили снимок всего дампа памяти. Вы просто путайте стэк вызовов с наследованием. Можно и в Сях без всякого наследования получить не меньше, а если еще и функция рекурсивная…
Другое дело, шо как форма отражения цикломатической сложности, снимок стэка вызовов должен отразить её повышение при использовании наследования
По-моему вы путаетесь в показаниях. Либо ООП «не взлетело», либо «смогло захватить мир». Либо ничего серьезно лучше нет — либо одно из двух (с).
Открою тайну — это два разных понятия, если не догадались. Что значит «не взлетело» — я пояснил, что значит «захватило мир» — я тоже пояснил, так что Ваше непонимание вызывает у меня недоумение 0_0
Да, про Оракл вы просто гоните
Т.е. Вы считайте, что у них классов все же больше чем индусов? Ну допустим.
Не везле, далеко не везде — скажем, один класс из десятков, но такая вложенность встречается, во вполне промышленных количествах.
Так не везде или все же в промышленных масштабах? Определитесь уже. Вы похоже пытайтесь выдать исключительную ситуацию за рядовую, при этом мой рекорд в 20+ иерархий наследования так и не побили. При этом я могу дать подсказку (по крайней мере для .NET), где искать большую вложенность — обычно в компонентах UI любят наплодить дофига наследников (но правда 20+ Вы там все равно не найдете), на то даже есть свои причины
Конечно не путаются, ведь разработчики не могут добраться своими кривыми ручками до Object (внезапно), который является родителем всего и всея (внезапно). Добрые дяди уже позаботились, так что можете работать лишь с наследниками MonoBeheavor, все что выше — уже Вас не касается — это черный ящик. Правда Юнити далеко не образчик стабильности — после каждого обновления обнаруживается несовместимость со старым API, да и производительность движка оставляет желать лучшего, что кагюбэ намекает ;-)
Но в любом случае имеем в Юнити всего 4 иерархии наследования, не 5, а именно 4 — отделяйте мух от котлет, точнее говнокод от фреймоврка, вы еще посчитайте сколько иерархий наследований в сорцах ОС и тоже их добавьте ;-)
При этом: object — в принципе обязательный (без него никак), а component — необходимый для реализации игровой логики, т.к. Юнити это вообще не про ООП, там изначально используется компонентная модель, если что.
Ну также можно запилить проект на Брейнфаке, и это наверное будет очень показательно…
Проект на Растет и у меня был, но пока не наберется критической массы таких проектов, говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво. Голэнг уже успешен, Растт — нет, он даже в 20-ку языков по версии IEEE и TIOBE не входит — гордо тусуется в компании всяких узкоспециализированных Верилогов (но им не стыдно, ибо эртээльщики народ особый и их мало), а вот Scratch входит :-)
Это надо было наверное лет 30 на необитаемом острове провести, что бы пропустить такой прорыв.
Тем более табуляция сохраняет пропорции в коде независимо от разрешения экрана.
А вот с пробелами как раз все плывет: кто-то любит дважды жахнуть по клавише, кто-то четырежды, кто сидит за моником 4:3, кто-то за 16: 9, а кто-то 16:10. Табуляция позволяет сохранить пропорции отступов, пробелы нет.
Детский сад какой-то. Не, ну можно, конечно, отказаться от табуляции, всех обязать печатать определенное количество пробелов в той или иной ситуации, посадить за одинаковые машины, одинаково постричь(налысо) и одеть, пришить номера на одежду, а печатать синхронно с в темпе барабанщика (или надзирателя с хлыстом) — ляпота…
Вся разница только в особенностях применения и реализации их эвристик: как осуществляется поиск и исследование в решений. На простых функциях они все в итоге дают похожий результат, а вот для сложных задач: на разных задачах разные алгоритмы ведут себя по-разному. Гибридные методы работают надёжнее.
Вполне естественно, что он даже не заметит с вероятность 145% (ну если ему специально не приплачивают за проверку орфографии).
Внезапно, человеки читают не по слогам как школьники, а распознают слова в тексте по общему очертанию, первым и последним буквам, ну и по контексту. При этом, если сознание не заострено на орфограммах, то для читающего нет особой разницы между «искусством» и «искуством». Иными словами, нормальный человек, вообще не читает текст в школьном смысле. Он смотрит на кусок, и сразу понимает его смысл. А вот излишнее «заострение» уже кагбэ намекает на некоторые проблемы, например, такое наблюдается при церебральном атеросклерозе, да и не только при нем — вообще это относится ананкастному (обсессивно-компульсивному) расстройству личности.
Если повлияет, то гнать такого чиновника поганой метлой. Такие запросы должны рассматриваться только «по-существу», и никак иначе, чай работать пришел, а не свататься по деловой переписке.
А есть вообще такое заболевание — дисграфия называется, когда человек в принципе не может писать без ашипок (грубо говоря). Примерно каждый 10-ый страдает таким расстройством, но на общее развитие интеллекта это как правило не влияет. Понятно, что это очень удобно — писать отказы по какой-нибудь явной причине, например, потому что у человека нет ноги или волосы не того цвета, но в цивилизованных странах так не принято.
Так что VenomBlood прав — англоговорящие (за исключением англичан) действительно не заостряют внимание на уровне владения письменным и устным английским языком (вероятно это считается неприличным, так-то), конечно, если это не входит в профессиональную компетенцию (это отдельная тема). И кстати да, в инглише нет никакого единого регулятора языка, иначе бы не было всех этих: «defense», «color», «no worries», «lighted», «wanna», «doco», «freeway» и миллионы других океюшек. Отношение к языку у них более чем свободное.
А чем это отличается от G/LabVIEW? Там конкурентность и параллелизм на уровне синтаксиса. И кстати Alice еще есть. По идее можно было бы наверное и Verilog с VHDL вспомнить, там правда конкурентность ИМХО под вопросом, т.к. определяется таймингами, но зато там чистый параллелизм. Еще наверное можно и Erlang с Go сюда же добавить (ну или хотя бы объяснить разницу, если нет).
Опять таки не упомянули LabVIEW — куда более известная и устоявшаяся штука (в отличии от Авроры, которую походу вообще ради фана делали), а также VisSim, SystemView, и JMCAD, а также все языки стандарта IEC 61131-3 и их потомки(символическое/графическое программирование, наверное наверное самое распространенное для промышленного программирования управления охрененно больших и дорогих штук). Ну Наверное еще и HiAsm и Simulink — правда я хз, можно ли вот эти два считать уже полноценными ЯП или нет.
Требуем
больше хлеба и зрелищьбольше примеров и сравнений!Ну или хотя бы 15к
Еще такой вопрос. А как там с поддержкой распараллеливания и CUDA?
Т.к. я тащусь от больших матриц, а вот Scilab (по крайней мере раньше) — нет
А еще у меня в универе был знакомый который на протяжении нескольких лет запилил на асме игровой движок (ТрыДэ!) — что, конечно, круто, но не понятно, нафига это. Ну в общем хвалиться не прикольно.
Впрочем у Раста в этом плане все же дела лучше — хз на сколько, но вот про вакансии Java-программистов с опытом разработки в Rust и Golang 0_0 я уже слышал, ну и по крайней мере его хотя бы Samsung начал активно педалить. Но все равно пока это «самый любимый язык программирования на котором никто не кодит» https://stackoverflow.com/insights/survey/2016#technology-most-loved-dreaded-and-wanted
а самымой популярной технологией по-прежнему остается богомерзкий ЖабаСкрипт https://stackoverflow.com/insights/survey/2016#technology-most-popular-technologies
Хз, может он и через пару лет выбъется в топ-20 используемых языков общего назначения (и холивары Go vs Rust станут еще более острее, что не может не огорчать)
Сообществу .NET был предоставлен сразу рабочим (ну почти, где-то за год подписчики msdn получили бета-версию .NET, меня в их числе естественно тогда еще не было — я с говнокодингом на нем познакомился лишь в 2005 году), после чего он очень шустро был стандартизирован, и тут же пошел в продакшен и начал набирать популярность. Java конечно он не переплюнул, но вполне с ней конкурирует и даже вопреки политике Microsoft стал кросс-платформенным языком, да и Java куда старее и к моменту появления C# у неё уже было устойчивое сообщество погромистов. И всю свою публичную историю существования этот язык идет по пути расширения и добавления новых свистелок и переделок.
И это важно, т.к. предыстория появления языка может быть очень долгой и богатой — вообще C# можно считать потомком Delphi, создавали их одни и те же люди, вообще папа Delphi и C# — создатель компилятор Turbo Pascal, так что при желании можно отследить историю языка начиная с даты рождения Вирта. А еще у Корпорации Добра была своя Жаба.
Но вот история конкретно языка начинается все же с его обнародования и начала использования — официальная дата его рождения: 2000-ый год (я так понимаю его тогда анонсировали), а в 2002..2003 пришла Visual Studio.NET где он был. Так что история использования языка и платформы .NET начинается с 2002 года. Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).
Об этом я собственно и толкую. С видением проект у создателей Раста явно какие-то проблемы (но сейчас вроде обещают, что все стало норм), а вот у создателей его ровесника (и вероятно конкурента) — Golang, который тоже кстати показали людям до того как выкатился в релиз, с этим дело обстоит вероятно несколько лучше. С видением всяких Java и прочьих дотНетов вероятно вообще все замечательно.
Об этом я тоже где-то здесь уже писал (Оракл и его тысячи и тысячи индусов). Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL. А еще вот всопмнился язык D — его тоже одиночки поднимали. Не сказать что он убер-популярный, скорее совсем непопулярный, но кое-кто им пользуется, я даже кусок живого проекта на нем видел.
Languages
14 C#
13 C++
11 Python
4 C
2 JavaScript
2 Jupyter Notebook
2 Matlab
1 Go
1 Java
1 Julia
Хм… чего-то не хватает. Ок, Гугл, нука покажи nonlinear optimization:
Languages26 Matlab
17 C++
14 C
11 Python
6 Java
6 R
5 Julia
4 Fortran
4 Jupyter Notebook
3 Haskell
Хм… Хаскель — есть, C# — есть, Фортран — есть, Джулия — есть, Пухтон тоже есть, как и R, C/C++, C#, Java, внезапно даже сбаж [если не забыли, то говорили о Go] есть.
Хм, что я делаю не так? Ах да, точно, можно же было бы посмотреть сводную статистику, например тут https://octoverse.github.com/
Понимайте, мне нет нужды целенаправленно выискивать сорцы языка Мозиллы и прожектеров, т.к. есть 20 десятка наиболее везде-используемых языков + нишевые специализированные языки (типа Verilog или VHDL), на половине из которых я худо-бедно говнокодю. А еще на них говнокодят миллионы других людей, а еще больше пользуются их продуктами.
А вот по логике веще, что-то выискивать и показывать должны фанбои Раста. В контексте холивара я даже привел пример Докера и список компаний использующих Golang, в ответ: какие-то скриншоты и обещания: «вот мы на нем говнокодим, скоро-скоро будет релиз, и вы все офигейте».
Но вообще-то для конструктивной беседы было бы хорошо провести сравнение с языком сабжа [еще раз напомню — это Go]: какие компании пользуют, сколько выпущено реальных проектов, какой был получен перфоманс в индусо-часах при переводе проекта на этот язык, сделать разбивку по нишам и секторам, ну и провести прочий серьезный анализ. И все это даже влезет в компактную таблицу, которая будет играть явно не в пользу Rust. При этом Go и Rust вообще-то ровесники.
Может быть, когда-нибудь, когда на Марсе начнут сажать яблони (а может даже и завтра), к Rust проснется вторая волна интереса и на нем начнут массово писать, тогда да, тогда Rust будет интересен, сейчас куда более интересен тот же COBOL, например.
1) Какое это имеет отношение к сабжу (если забыли, то это Go)
2) Как это имеет отношение к срачу про наследование
То что Вы осилили Java.lang.Thread.getStackTrace() меня, конечно, несказанно радует, но не обязательно об этом на каждом углу кричать? А то вдруг набижит бородатый погромист и выложит свой дамп :-)
С таких, что компонентно-ориентированное программирование это независимая парадигма программирования, которая была придумана Виртом для решения проблем внезапно возникших у ООП, и реализованная в языке, который является ОО менее чем никак
https://ru.wikipedia.org/wiki/Оберон_(язык_программирования)
Оттуда КОП ушло в ныне мейнстримовые языки и стало их частью, т.к. действительно, в большинстве случаев композиция предпочтительнее наследования. Тут же на хабре, уже ни раз обсуждали разницу между КОП и ООП.
Вот только недавно это на работе обсуждали, правда в контексте Python 2 RIP: программа написанная на С++ в 1989 году, компилится в 2017, программа написанная на C# под .NET 1.0 в 2002..2003 годах (язык был стандартизирован по ISO в 2003 вроде бы, а бета-версию вроде как опубликовали эдак в году 2001), точно также внезапно скомпилится и заработает в 2017 году. Хотя там тоже бывали костыли, например, до появления Джнерик-типов в .NET 2.0, в общем обратная совместимость худо-бедно выполняется. Хз, чего там у Жабы — не занимался такой глубокой интроспекцией в ней, но думаю худо-бедно норм.
Однако в большинстве своем все не так безоблачно.
Ну потому что, то что зарыто внутри фреймворка, разработчика уже не касается, т.к. отнаследовавшись один раз для него вот энта проблема:
https://ru.wikipedia.org/wiki/Хрупкий_базовый_класс
еще не актуальна, все что внутри фреймворка — это уже головная боль его создателей. К счастью, у них индусов (в штате, на аутсорсе, на аутстафее) вероятно больше чем классов а также есть вумные архитекторы-надсмоторщики с кнутами, так что они могут себе позволить сопровождать, поддерживать и развивать ПО где объемы наследования очень-очень велики.
Так что в условиях неограниченных ресурсов (как индусо-часы, так и ресурсы вычислительных машин) — это работает. Но у большинства ресурсы ограниченные — и тут выясняется, что сложность программы (как разработки, так и цикломатическая сложность) растет экспоненциально от глубины наследования. В тоже время какой-то учитель математики по фамилии Степанов в 3.5 написал STL, которая уже больше 20 лет успешно используется и включена в стандарт. Заранее предупрежу, что STL это тоже не про ООП, а Степановтак вообще один из самых ярых критиков ОО-подхода.
Слабое мобильное устройство — это Нокиа 1100, еще космические спутники (там до сих пор летают на 51-ой архитектуре и килобайтами памяти). А современные говносмартфоны и говнопланшеты по вычислительной мощности круче домашних писюков начала 2000-ых. К слову сказать Unreal и Quake были изначально написаны на чистом Си еще в 90-ых
Вы просто всего 2 движка знайте
Уравнения Максвелла тожее умеет решать, или кварк-глюонную плазму смоделирует? В физике там ничего особенного: коллизии, 2-ой закон Ньютона, уравнение движение и т.п. — примерно 1-ый курс… потом студенты в рамках лабораторных работ/курсовых сами пишут куда более сложные физические модели.
Если там на сцене живет 3.5 МоноБихеавор, то да, а так:
https://forum.unity3d.com/threads/general-performance-optimization-tips-for-unity.386338/
В общем удже давно известно, что производительность и Юнити ТрыДэ это несовместимые понятия. Но Unity3D не за это любят, а за
Но за все надо платить https://ru.wikipedia.org/wiki/Технический_долг
Обычно там внутри что-то типа такого:
https://www.youtube.com/watch?v=rX0ItVEVjHc&t=270s
Что тоже не ООП. У меня вон тоже, когда говнокодю на C# начинают плодиться всякие unsafe:
Это примерно раз в 10 быстрее чем вот такое:
Правда unsafe это вообще не про .NET, а так — грязный трюк (да, мыши кололись, плакали, но продолжали жрать кактус). И ООП тут встречается в гомеопатических количествах, лишь при описании собственного класса Matrix. Впрочем к версии 4.5 .NET все же узнал, шо есть такая офигенная штука как SIMD (Intel Pentium MMX, 1997 год, 16кБ L1, 166 МГц), так что жить стало лучше, жить стало веселее.
Потом да, потом это все будет обернуто со стороны клиента уже в читабильный ООП-код
Другое дело, шо как форма отражения цикломатической сложности, снимок стэка вызовов должен отразить её повышение при использовании наследования
Открою тайну — это два разных понятия, если не догадались. Что значит «не взлетело» — я пояснил, что значит «захватило мир» — я тоже пояснил, так что Ваше непонимание вызывает у меня недоумение 0_0
Т.е. Вы считайте, что у них классов все же больше чем индусов? Ну допустим.
Так не везде или все же в промышленных масштабах? Определитесь уже. Вы похоже пытайтесь выдать исключительную ситуацию за рядовую, при этом мой рекорд в 20+ иерархий наследования так и не побили. При этом я могу дать подсказку (по крайней мере для .NET), где искать большую вложенность — обычно в компонентах UI любят наплодить дофига наследников (но правда 20+ Вы там все равно не найдете), на то даже есть свои причины
Но в любом случае имеем в Юнити всего 4 иерархии наследования, не 5, а именно 4 — отделяйте мух от котлет, точнее говнокод от фреймоврка, вы еще посчитайте сколько иерархий наследований в сорцах ОС и тоже их добавьте ;-)
При этом: object — в принципе обязательный (без него никак), а component — необходимый для реализации игровой логики, т.к. Юнити это вообще не про ООП, там изначально используется компонентная модель, если что.
Проект на Растет и у меня был, но пока не наберется критической массы таких проектов, говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво. Голэнг уже успешен, Растт — нет, он даже в 20-ку языков по версии IEEE и TIOBE не входит — гордо тусуется в компании всяких узкоспециализированных Верилогов (но им не стыдно, ибо эртээльщики народ особый и их мало), а вот Scratch входит :-)