LINUX.ORG.RU
ФорумTalks

Почему C++хейтеры не огрызаются на Си?

 ,


0

7

Я давно наблюдаю за плюсохейтерами, и заметил у них характерный поведенческий шаблон. Вернее даже два шаблона.

Во-первых, плюсохейтеры обвиняют C++ в своих собственных ошибках. Ошибки у них одного и того же сорта: пишем программу как на жаве, головой не думаем из принципа, проектирование придумали слабаки, проблемы «решаем» по месту их возникновения любой ценой и считаем это «обработкой». Из последнего, как я понял из недавней дискуссии на тему «как вы обработаете ошибку коммита в базу данных», и растет бомбаж задних торцов плюсохейтеров на тему «исключения в деструкторах». Причем проблемы с плюсами у хейтеров повторяются.

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

Ведь на Си писать еще геморойнее. Ооп вручную, методов нет, операторы перегрузить нельзя(например для операций с векторами и матрицами). То есть проблем даже больше. Я можно сказать ветеран Си. Я писал GObjectы руками. Си это боль. Он хуже.

Так почему плюсохейтерыне лают на си?

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

В чем причина? Почему плюсохейтеры не вякают на Си?

OK, ты, конечно, упоротый, но я в хорошем настроении. Давай объясню.

Первое. Насчёт «обвиняют в собственных ошибках» и «головой не думаем». Я лично склонен считать, что все языки программирования, начиная с ассемблера, придумываются, в первую очередь, для того, чтобы освободить голову. Понимаешь (хотя, конечно, нет), у каждого человека есть определённые границы — о скольких вещах он в состоянии думать одновременно. У кого-то больше, у кого-то меньше, но у всех ограничения есть. И если язык программирования занимает большую часть — значит, меньше остаётся на действительно важные вещи. Отсюда следствие: если в языке легко сделать ошибку — значит, он неудобен. Если особенности языка нужно постоянно держать в голове — он неудобен.

«Исключения в деструкторах» — это как раз то самое, о чём я говорю. Это аккуратно уложенные на дороге грабли. Да, их несложно обойти — но об этом нужно думать, нужно держать это в памяти.

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

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

Miguel ★★★★★
()
Ответ на: комментарий от Manhunt

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

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

asaw ★★★★★
()
Ответ на: комментарий от i36_zubov

На плюсах можно писать не используя всех фич.

А читать?

Esper
()

Почему плюсохейтеры не вякают на Си?

ИМХО всё очень просто. что они ставят? MSVC какой там язык? С++ (можно и на с писать, но это уже напрягаться надо).

вот поэтому С они и не ругают.

samy_volosaty ★★★★★
()
Ответ на: комментарий от Quasar

к нему претензий просто нет

И всего остального то же.

uin ★★★
()
Ответ на: комментарий от uin

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

Хотите креативно работать под iOS - однозначно, Objective-C.

Хотите хорошо зарабатывать - учите Java.

Умничать будете на собеседовании.

«Ловушек» в Жабе я знаю много, очень много.

Просто умора, когда, например,

Integer i = -128;
Integer j = -128;
System.out.println(i == j);
Integer i = 128;
Integer j = 128;
System.out.println(i == j);

И соискатель, минуту назад гнущий пальцы, дает в 80% случаев неверный ответ.

Bioreactor ★★★★★
()
Последнее исправление: Bioreactor (всего исправлений: 1)
Ответ на: комментарий от stevejobs

потому что Си используется очень редко

ЧТО?
https://www.opennet.ru/opennews/art.shtml?num=43643

в качестве вставок для оптимизации чего-то машинно-специфичного.

ЧТОО?
Что в Си машино-специфичного? С Ассемблером не путаешь?

C++ позиционируется как средство для написания высокоуровневой бизнес-логики очень обобщенным универсальным способом

Кем позиционируется? Что такое «бизнес-логика»?
Ты очень ошибаешься.

Kroz ★★★★★
()
Ответ на: комментарий от Bioreactor

А зачем два раза об одном и том же? Кстати, это показатель ущербности языка. Как и, например, неочевидность последствий того, что строки в жабе неизменяемые. Человек думает он получил ссылку, по которой объект можно менять, а фиг вам. И вот, вроде бы, хотели уберечь разных индусов от граблей C++, а получается, что разбросали кучу новых.

asaw ★★★★★
()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от Bioreactor

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

stevejobs ★★★★☆
()
Ответ на: комментарий от Bioreactor

Ээээм. А в чем проблема то? Сложно вспомнить про кеширование числовых примитивов? Ну или как это правильно называется?

Можно еще вот такой код показать.

Integer i = -128;
Integer j = -128;
Integer k = new Integer(-128);
System.out.println(i == j);
System.out.println(i == k);

P.S.: Скидку на нервы на собеседовании делаешь? Может человек просто забыл границы кеширования?

TheKnight ★★★
()
Ответ на: комментарий от TheKnight

Нет никаких «границ кэширования», которые нужно помнить или знать, а тем более - спрашивать о них. Это публичный онанизм. Если интервьювер имеет в виду именно это, то он сам некомпетентен как интервьювер, и не знает кто и зачем ему нужен.

asaw ★★★★★
()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от Bioreactor

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

flyshoot
()
Ответ на: комментарий от Kroz

Что в Си машино-специфичного? С Ассемблером не путаешь?

так он и есть современная замена ассемблеру

потому что Си используется очень редко

Да, ты пишешь на каком-нибудь другом языке (Erlang, Haskell, Java/Scala, F#/C#), и иногда случается corner case, когда нужно использовать еще не виртуализованную аппаратную фичу. Например, нужно заиспользовать SSE/SIMD векторизацию - всё перечисленное выше в автовекторизацию умеет, но плохо (может у хаскеля получше?).

То есть нужно написать кусок кода на Си (даже возможно - на Си собранном С++ компилятором) и встроить. У Хашкеля есть FFI/C, у Эрланга есть port drivers, у Жабы есть JNI, у Шарпов InteropServices/DLLImport, итп.

Ситуация, когда в современных платформах и рантаймах, оборудованных JIT и AOT, необходимо было бы делать такие вещи, в среднем очень редка. (была бы «почти не нужна», если бы не определенные классы задач, где без этого не обойтись).

Как только какая-то фича становится нужна реальному коммерческому заказчику, настолько что он готов заплатить за разработку, соответствующие компании-разработчики тут же впиливают её в комплияторы. Например, который год Intel пытается добавить в процессоры транзакционную память, бажная её версия во всех современных процессорах. И сюрприз-сюрприз: уже сейчас у Oracle есть универсальное решение для работы с транзакционной памятью (кстати надо узнать, попало ли оно в openjdk), но в целом если сильно нужно - надо брать ассемблер, ну или __transaction_atomic из gcc (там какая-то гибридная хрень, которая по возможности использует HLE/RTM, но если не получается - юзает стандартные локи). Но как только транзакционная память станет мейнстримом, она тут же появится везде.

Вот это имелось в виду под «Си используется очень редко».

Кем позиционируется?

Язык C++ разрабатывается коммитетом, в который входят члены крупнейших компаний-разработчиков компиляторов и крупнейших компаний-пользователей. Плюс там есть Страуструп и прочие теоретики, которые задают идеологическую базу. Всё вместе формирует понимание разработчиков стандарта, «зачем нужен этот язык».

Например, то, как позиционирует его Страуструп, можно почитать у Страуструпа в совершенно любом интервью, в книге «Дизайн и эволюция C++», в «The c++ programming language», итп. Он видит его именно как язык общего назначения, для написания высокого абстрактного кода. Совсем не как средство для подпихивания редких «ассемблерных вставок» в код на Эрланге и Жабе.

stevejobs ★★★★☆
()

А почему питерско-бангалорское поделие отсасыет с проглотом у mesa написанной на «C»?

steemandlinux ★★★★★
()
Ответ на: комментарий от flyshoot

Можно ли где-то почитать про подобные ловушки?

ответ на этот вопрос состоит из двух частей.

если тебе серьезно нужно изучить тонкости джавы, то советую смотреть всё, что публикует https://www.youtube.com/user/JUGRuVideo

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

ну и почитать какую-нибудь классику, типа Джошуа Блоха Effective Java, Java Concurrency in Practice, итп (тут нужно думать над списком классической литературы)

по тонкостям дизайна базовой джавы придется прочитать стандарт: Java Language Specification и Java Virtual Machine Specification

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

таким образом можно узнать что-нибудь теоретически полезное, например как устроен HashMap, и своим мозгом понять какая по нему скорость поиска

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

(для Hibernate это как минимум древняя дока Hibernate Annotations, с тех пор там ничего не менялось. Для Spring это целиком полностью HTML с их официального сайта - она простая, но очень нудная и длинная, в первый раз я ее осилил только за неделю).

На основании этого складывается понимание дизайна фреймворка. И вот только после этого можно начинать писать на нём совершенно новый проект.

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

===

если тебе нужно пройти собеседование. И общаться на собеседовании с придурками, одержимыми своим ЧСВ, которые спрашивают идиотские вопросы про сравнение интов через ==, то нужно:

- подготовиться по материалам для Oracle Java Certified * (Associate, Programmer, Architect, ...) какие найдешь на торрентах. Там просто отборная порция идиотии, придумать самостоятельно это нереально :)

- посмотреть что написано в вакансии (например, «Hibernate»), и
--- загуглить по запросу типа «Java Hibernate interview questions»
--- загуглить по кейворду «Hibernate Cheatsheet», особенно в гуглокартинках как ни странно, и зазубрить всё что увидишь на этих шпаргалках. Обычно там написано то, на что не решаются пойти авторы профильных книг - иначе бы это показало бессмысленность чтения этих книг
--- прочитать соотстветствующую документацию (древняя дока Hibernate Annotations, простыня HTML с сайта Srping, вот это всё). Запомнить в голове хотя бы оглавление, чтобы понимать список фич фреймворка. По возможности еще и закэшировать в голове синтаксис, идиоты любят спрашивать задачи типа «сообщите точный список параметров у @RequestMapping».

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)

Почему C++хейтеры не огрызаются на Си?

Потому, что С++ имеет много из того функционала, который есть в Java, PHP и т. п., а значит может рассматриваться как конкурент. Что они не понимаю, так это то, что С++ всё еще более низкоуровневый чем перечисленные языки и требует обучения. Те, кто бездумно пытается писать на С++ с подходом Java натыкаются на уйму подводных камей и винят... конечно же не себя. Ведь им и в голову не может прийти, что каждый инструмент для своих целей, и каждый инструмент требует обучения работы с ним.

Си же практически не имеет «высокоуровневого» функционала. Java'исты и PHP'шикик даже и не пытаются его пробовать: а как же жить без ООП, лямбд, автоматизации работы со строками? А если и пробуют, не заходят далее hello-word'а. А потому и вынесли его в отельную категрию с ассемблером - «машиноспецифичные».

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

Kroz ★★★★★
()
Ответ на: комментарий от stevejobs

так он и есть современная замена ассемблеру

В то же мере что и Java - тоже замена ассемблеру.

нужно заиспользовать SSE/SIMD векторизацию

Си тебе с этим не поможет. Только ассемблер.

Вот это имелось в виду под «Си используется очень редко».

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

Он видит его именно как язык общего назначения, для написания высокого абстрактного кода.

Как и 90% современных языков. И что?

Совсем не как средство для подпихивания редких «ассемблерных вставок» в код на Эрланге и Жабе.

Я правильно тебя понял? «Си это средство пропихивания ассемблерных вставок в Java»???

Kroz ★★★★★
()
Ответ на: комментарий от stevejobs

WOW, спасибо за развёрнутый ответ. Вообще я хочу решать различные обратные задачи и отображать графически результат решения. Вообще недавно размышлял, правильный ли я хочу использовать инструмент (java). Возможно более правильный выбор это С\С++, но в них меня смущает UB, управление памятью, выход за пределы массива и другие популярные ошибки, допускаемые даже опытными программистами и которые обязательно буду делать я. Т.к. обрабатывать предстоит большие объёмы данных, то нужен язык с хорошей производительностью, потому и смотрю пока в сторону Java. Даже думал создать на этом форуме отдельную тему с обсуждением, что скажете стоит?

flyshoot
()
Ответ на: комментарий от Kroz

всё это строго имхо, не кипятись так ;) Я пишу про СЕБЯ в первую очередь, рассказывать что делать другим людям - это плохо ;)

В то же мере что и Java - тоже замена ассемблеру.

джава - говённая замена ассемблеру. Если ты изучишь машинный код, который генерит джава, то это никаким образом не поможет тебе писать более правильный высокоуровневый код на Java. Нельзя провернуть фарш назад и получить кошку. А в C/C++ - можно.

Си тебе с этим не поможет. Только ассемблер.

ассемблер и Фортран! :3

ващет поможет, лол. Зачем люди приносят все эти кровавые жертвы, если бы их боги им не помогали?

Интеловский компилятор, pure C:

void add_floats(float *a, float *b, float *c, float *d, float *e, int n) {
 int i;
 #pragma simd
 for (i=0; i<n; i++){
  a[i] = a[i] + b[i] + c[i] + d[i] + e[i];
 } 
}
icl vect.c -nologo -Qvec-report2 vect.c 
  d:\git\cpptest\vect.c(4): (col. 3) remark: SIMD LOOP WAS VECTORIZED.

Майкрософтовский компилятор, параллелизация C++ по-умолчанию (но можно отключить):

int A[1000];
void test() {
#pragma loop(hint_parallel(0))
    for (int i=0; i<1000; ++i) {
        A[i] = A[i] + 1;
    }

    for (int i=1000; i<2000; ++i) {
        A[i] = A[i] + 1;
    }
}
cl d:\git\cpptest\par.cpp /O2 /Qpar /Qpar-report:2
--- Analyzing function: void __cdecl test(void)
d:\git\cpptest\par.cpp(4) : loop parallelized
d:\git\cpptest\par.cpp(4) : loop not parallelized due to reason '1008'

То же самое для векторизации: автоматом юзаются SSE2/4.2, AVX, AVX2, NEON, и отключается через #pragma loop(no_vector).

Ну и я не думаю, что существуют люди в здравом уме, которые будут писать на чистом ассемблере. Можно писать на C/C++ с ассемблерными вставками. И полученное уже вставлять куда-то дальше по иерархии абстракций.

Как и 90% современных языков. И что?

Си к ним не относится, поэтому и спроса с него нет. C++ к ним относится, по крайней мере такова легенда.

Более того, C++ фанатики уже все уши прожужжали своей херней про «современный язык программирования», «идеальное средство для написания логики». Хочется вот просто взять и ударить в пятак!

Я правильно тебя понял? «Си это средство пропихивания ассемблерных вставок в Java»???

Ну почему же только в Java :)))

Высокоуровневые приложения должны писаться на высокоуровневых яыках, а нижняя платформа (в том числе «пропихивание аппаратных функций») делается уже на C/C++. Какая-то такая идея.

Например, если ты пишешь веб-приложение на PHP, ясно же что команда «положить в поток буковку» написана на Си. Чтобы добавить в PHP какую-то новую функцию - нужно вначале написать её на Си. Но упаси бог использовать эту функцию напрямую, без прослойки в виде PHP!

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от flyshoot

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

Может оказаться, что фичи C++ таки будут тащить и жечь напалмом (хотя бы вот эта авто-параллелизациея и авто-векторизация, и возможность более просто без написания оберток обращаться к GPU, итп), против джавы где можно всё то же самое но придется серьезно побиться башкой об стену (например окажется, что ты так накодил кот, что у тебя там в stream() гоняются миллиарды объектов, которые жрут RAM тоннами, оптимизировать такое будет ничуть не проще, чем байтоёбствовать в крестах).

Ну и вообще, истинно байтоёбский код на Java не особенно отличается от такого же на C++ :))
Прикол в том, что в основном никто таким не занимается. Например, в ынтерпрайз-приложениях огромное количество времени ответа и ресурсов жрут вызовы БД и рендеринг в веб-интерфейс, когда у тебя творится такой цирк экономить RAM и такты не имеет никакого смысла.
Если у тебя не так, то многие «хорошие практики» могут резко оказаться не такими уж и хорошими

еще у меня есть друг-байтоёб, который очень котирует Фортран. Похоже, фортран действительно крут, но времени разобраться с этим никогда не было. Может имеет смысл добавить еще один бенчмарк рядом с C++ и Java - еще и Fortran.

олсо по «развернутому комментарию» выше. Для байтоёбства нужно изучать другое. Java Collections, NIO, Сoncurrency. Из книжек - Java Concurrency in Practice и Java VM Specification. Про коллекции нужно четко понимать, из чего они состоят, какую сложность работы имеют, какие ресурсы жрут. Почитать как работает GC, какие есть типы памяти (смотреть сразу Java8), почитать про off heap memory. Спринг, хибернейт и прочий шлак - в топку.

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 3)
Ответ на: комментарий от stevejobs

Но упаси бог использовать эту функцию напрямую, без прослойки в виде PHP!

Ну да, сейчас рукожопам всегда нужна дополнительная защита, а то бахнет!

reprimand ★★★★★
()
Ответ на: комментарий от stevejobs

Нельзя провернуть фарш назад и получить кошку. А в C/C++ - можно.

В С++ - сомневаюсь. Ты никак не возвратишь, прапример, шаблоны.

ващет поможет, лол. Зачем люди приносят все эти кровавые жертвы, если бы их боги им не помогали?

Ты про Java?

Интеловский компилятор, pure C:

Ты путаешь вендоро-специфичные фичи со стандартом С/С++.

Си к ним не относится, поэтому и спроса с него нет

stevejobs, открой глаза. На С пишется подавляющее большинство кода для декстопа. То есть не просто спроса нет, а он №1. Для Enterprise - здесь первенство завоевала Java, в основом потому, что бинес может позволить себе мощные компьютеры. Но даже там Cи + С++ + Objective C в числе распростаненных.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

потому, что бинес может позволить себе мощные компьютеры

нет. Потому, что нужна штабильность и надежность. Ну и сесурити в довесок.

Никто платить за мощные компьютеры лишний раз не хочет потому что это бизнес.

reprimand ★★★★★
()
Ответ на: комментарий от Kroz

Ты про Java?

я про использование внутри проекта нескольких разных языков. Это огромная жертва

Ты путаешь вендоро-специфичные фичи со стандартом С/С++.

насколько я знаю программистов на C++, они начхали на стандарт. Это на Java пишут «на стандарте», а на крестах пишут на вполне конкретной реализации :) И да, прибиваются к этой реализации гвоздями, живут с ней, трахаются с ней, такая вот у профессиональных крестовиков работа full time job =)

В С++ - сомневаюсь. Ты никак не возвратишь, прапример, шаблоны.

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

на Java это можно только с большими оговорками. В принципе, почитать выхлоп JIT можно. В Java9 будут большие подвижки на тему того, что ты можешь сам подпихнуть для JIT оптимальную реализацию метода. В Java8 тебе для этого всё еще нужно пересобирать сам JDK. Но для типичного продукта на Java, электронного интернет-магазина писанного 2 быдлокодерами, это оверкилл =)

На С пишется подавляющее большинство кода для декстопа.

для линукс-десктопа? Может быть. Только пользователей декстопного линукса - 2% =) Поэтому весь линукс-десктоп можно сразу выбросить из статистики, вместе со всеми GTKами и прочим

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

на OSX пока еще доминирует ObjC, но скоро везде будет Swift.
Яблочники просто с ума посходили от свифта

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

мне почему-то всегда казалось (с) что на Си пишут в основном железячники

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 3)
Ответ на: комментарий от mv

У Си меньше неявного поведения. Софт легче писать, когда доходит до его отладки.

Отлаживать его немного легче, писать - намного сложнее.

tailgunner ★★★★★
()
Ответ на: комментарий от Miguel

Относительно C. У него мало возможностей, это факт. Но у него практически нет каких-то загогулин, которые занимают голову.

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

tailgunner ★★★★★
()

Потому что Си прекрасен!

sergej ★★★★★
()
Ответ на: комментарий от reprimand

Потому, что нужна штабильность и надежность. Ну и сесурити в довесок.

«штабильность» «надежность» «ну и сесурити» зависит от программиста. А там, где не зависит, компиляторы С/C++ будут одиними из первых по данным критериям.

Никто платить за мощные компьютеры лишний раз не хочет потому что это бизнес.

Именно: бизнес. И дяди наверху договорились, что компания А сделает продукт для компании Б. А компания Б хочет заработать, потому она набирает дешевых вчерашних (или сегодняшних) студентов. А значит их нужно быстро обучить. И здесь Java как раз хороша в сравнении с Си/С++.

А требования к железу - они часто обсуждаются уже после подписания контракта. Но даже я уже встречался с ситуациями когда клиент охреневал от изменений в требованиях к жалезу после очередной, как казалось, не такой уж и сложной доработки. Просто программист, плохо знакомый с тем, как программа работает, способен «завалить» любого мамонта, даже если бы они писал на ассемблере. Да и железо сейчас относительно дёшево.

Kroz ★★★★★
()

С — вещь в себе. У языка есть ниша и есть четкий стандарт проверенный временем. Поэтому когда стреляешь себе в ногу, при попытке использовать ООП, понимаешь, что ССЗБ и язык тут не при чем.
Совсем другое дело, когда в ООП языке стреляешь себе в ногу при использовании ООП

I60R ★★
()
Ответ на: комментарий от Kroz

«штабильность» «надежность» «ну и сесурити» зависит от программиста.

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

А там, где не зависит, компиляторы С/C++ будут одиними из первых по данным критериям.

Отлично. Уже есть НЕ люди, которые пишут код чтобы убрать человеческий фактор?

Именно: бизнес. И дяди наверху договорились, что компания А сделает продукт для компании Б. А компания Б хочет заработать, потому она набирает дешевых вчерашних (или сегодняшних) студентов. А значит их нужно быстро обучить. И здесь Java как раз хороша в сравнении с Си/С++.

Ну, с такой точки зрения, конечно, да.

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

Кстати, у меня тут есть одна офигенная история. Как одна конторка пилит настолько толстый интернет магазин, что чтобы нормально работать нужны RAID SSD (HDD не подходят), 12 core CPU, 32 гб памяти. Причем ни о каких убернагрузках речи не шло.

reprimand ★★★★★
()
Ответ на: комментарий от flyshoot

Т.к. обрабатывать предстоит большие объёмы данных

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

asaw ★★★★★
()
Ответ на: комментарий от stevejobs

я про использование внутри проекта нескольких разных языков. Это огромная жертва

Соглашусь

насколько я знаю программистов на C++, они начхали на стандарт.

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

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

Ты опять же путаешь реверс-инжиниринг и оптимизацию программ.

на винде главенствует C#, на C++ всякое легаси, на Си - хз.

Это откуда такая информация? Уверен, что на Винде то же самое. Правда здесь сложнее - код закрыт, официальной статистики нет. Но не забывай, что C# появился не так давно. Раньше всё использовали С. И я очень сомневаюсь, что они разогнали штат своих С-программистов с многолетним опытом.
Как я знаю (хотя могу ошибаться) С# - просто аналог Java, с теми же свойствами.

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

Например вот: https://www.opennet.ru/opennews/art.shtml?num=43643 . Можно поискать еще, но уверен, что там статистика таже.

для линукс-десктопа? Может быть. Только пользователей декстопного линукса - 2%

Нет, я говорю про софт, который требует JVM.
и, кстати, не забывай, что на серверных платформах Linux+BSD доминируют как ОС, а там почти всё на Си написано.

Kroz ★★★★★
()

Все знают, что Java (JVM) написана на С++, JavaScript (V8/IronMonkey) тоже на C++, а Python и Perl на C. А вот на чём написан PHP? Кто подскажет?

EXL ★★★★★
()
Ответ на: комментарий от Kroz

и, кстати, не забывай, что на серверных платформах Linux+BSD доминируют как ОС, а там почти всё на Си написано.

у нас в банке всё написано на Java. Вообще всё.

кроме ядра и базовых гнушных утилит типа find и grep, конечно.

раньше работал над «электронным правительством россии» - там тоже всё на java. Даже небо, даже Аллах

И я очень сомневаюсь, что они разогнали штат своих С-программистов с многолетним опытом.

конечно разогнали. Гуйню на Си невозможно клепать на той же скорости, что и C#, там даже не порядки разница

например, я работал в компании, которая писала на C++, Java и Flash игры, писал MMORPG. Однажды руководство сказало, что в современном мире эти технологии устарели. И что теперь совершенно все будут писать на Unity - т.е. на JavaScript и C#. Либо на UnrealEngine, но тоже на JavaScript.

размер компании - около 500 человек на тот момент. Какая-то очень незначительная часть разрабов уволилась (включая меня), все остальные сказали okay.jpg и пошли изучать JavaScript и C#.

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

stevejobs ★★★★☆
()
Ответ на: комментарий от reprimand

Но что я могу сделать, если «интерпрайз» мнение состоит в том, что java отчасти решает проблему рукожопости?

Это да.

Уже есть НЕ люди, которые пишут код чтобы убрать человеческий фактор?

«люди» -> «проектная команда». Я про то, что компилятор С/С++ (наиболее популярные из них) - весьма хорош.

Kroz ★★★★★
()
Ответ на: комментарий от stevejobs

у нас в банке всё написано на Java. Вообще всё.

Это не нужно экстраполировать на всё остальное.

Гуйню на Си невозможно клепать на той же скорости, что и C#, там даже не порядки разница

На Си, наверное, нет. Visual Studio, вроде, что-то там для этого делали, но я не смог с ним подружиться. А вот в Borland C++ Builder отлично работать с GUI. C C# не сталкивался.

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

Вот. Хоть речь не про Javа, но это вточности характеризую и Java. C C# не сталкивался.

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 1)

Потому что если не нравится какая-то фича С++ (ООП например), то можно обвинять во всех смертных грехах С++

А в Си если ты наговногодил, то ты наговнокодил, и никто кроме тебя виноват быть не может.

RisuX3
()
Ответ на: комментарий от annulen

в ядре тоже можно писать на С++. так ядро макоси сделано например. и божежьмой, насколько оно удобнее! даже в винде есть WDF где можно быстро и резко накатать драйвер usb-устройства для user-space и он заработает бесплатно без регистрации и смс.

на osdev даже мануал есть как это делается.

и только в линуксе надо всё писать дедовским способом без реюзания кода.

i36_zubov
() автор топика
Ответ на: комментарий от i36_zubov

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

даже в винде есть WDF

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

дедовским способом без реюзания кода

ну это ты что-то неправильно делаешь

annulen ★★★★★
()
Ответ на: комментарий от annulen

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

И количество людей в этих канторах несоизмеримо меньше,чем в одном $MS

shpinog ★★★★
()
Ответ на: комментарий от Miguel

«Исключения в деструкторах» — это как раз то самое, о чём я говорю. Это аккуратно уложенные на дороге грабли. Да, их несложно обойти — но об этом нужно думать, нужно держать это в памяти.

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

Там какой-то анонимный и упоротый товарищ придумал умный, как ему казалось, юзкейс, где С++ «не работал». Вот собственно начало этого цирка. Решил товарищ, что ошибку надо обрабатывать в деструкторе, и всё. С++ теперь ему виноват в его проблемах, и объяснить сумасшедшему, что деструкторы сделаны для других целей, невозможно.

Тем более невозможно объяснить рукожопам, что «обработка ошибок» - это не ловля исключения. Исключения - это механизм передачи данных об ошибке, с фичей освобождения временных ресурсов по дороге.

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

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

i36_zubov
() автор топика
Ответ на: комментарий от annulen

это все фантастика

что фантастика? существование IOKit и Window Driver Foundation?

и при чем тут «большее количество контор»?

i36_zubov
() автор топика
Ответ на: комментарий от shpinog

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

И количество людей в этих канторах несоизмеримо меньше,чем в одном $MS

Глупости.

tailgunner ★★★★★
()
Ответ на: комментарий от stevejobs

высокоуровневой бизнес-логики очень обобщенным универсальным способом, т.е. претендует чуть ли не лавры Common Lisp. И соответственно огребает пиздюлей

Когда покажешь эти тонны бизнес-логики на Common Lisp, расскажешь про лавры и пиздюли :) То что ты называешь «лаврами» — это несбыточные мечты фанатов мамкиного борща с 70-х годов «познающих мир» после каждого выпу(с)ка очередного закрытого специнтернатавыводка «юношей обдумывающих житье» как «войти в ИТ».

slackwarrior ★★★★★
()
Ответ на: комментарий от asaw

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

Умственно оцталый, не знающий хотя бы «процедурного подхода», не говоря уж о прости-вообр.др-г «ООП руками», будет на Си не клепать, а говнокодить, так же как на бейсике :)

Такой минимальный язык, который можно применять на практике.

Си, как пистолет или бензопилу, надо уметь «применять» и «использовать», и знать тонкую разницу между :)

slackwarrior ★★★★★
()
Ответ на: комментарий от flyshoot

Эти «отточенные под шиндовс» игори потом однажды попадают в паблик домейн в виде сорцов потому что издатель давно уволил всех кто что-то знал, но хотел многа денег, а потом тех, кто много денег не хотел, но из сорцов ничо не понял, и закрыл «нинужное подразделение», и толпа мамкиных «гейдевелоперов», которые ныли что жаль нет сорцов, а то бы они «девелопнули» и «портировали» на сосноли, утюги и фоторамки, понимают, что «сорцы есть, а щастья нет» — потому что игорь гвоздями прибит к... одной версии шиндовс, а кто понимал, как это работает — уже застрелился от бзсхднстине понимает («чо, бесплатно? это как?») или уволился еще тогда, когда издатель прогнулся под ЦА и надовил, чтоб «дропнули все ненужное, и так не успеваем» :)

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.