Холивары вокруг C++

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

На этом форуме живет один мой очень древний знакомый Андрээ С, который здесь точно и однозначно был админом. когда то давно он даже активно пытался меня банить, когда я любил немного пошалить и потролить кодеров. Так вот, прошло лет 10, а наша основная тема спора оказывается до сих пор актуальна. Спор у меня недавно возник с другим кодером, потому с Андрэ Мандрэ мы очень давно не общались. Суть спора можно объяснить одной его фразой: "С# это кастрированный с++". ну типа существует язык цпп для реальных программистов, а си шарп это какая та дичь не понятно для кого вообще и не понятно зачем.

Дело в том, что я даже поверил этому и начал один из своих проектов кодить на цпп. Ну думал такой, что щас подтяну знания реально крутого языка, на котором написаны почти все крупные проекты. ФИГ!
Я не помню точно на чем я забуксовал, но точно помню финальную мысль - это кал вонючий, на котором нету вообще никаких удобств, траблы с библиотеками (может быть сейчас не актуально уже) и вообще как работать с объектами когда всё настолько хреново.

вот простые моменты, от которых жопа сразу сгорает мгновенно:
1. статические массивы. если мне надо добавить что-то в середине массива, то это танцы с бубном с пересозданием.
2. надо следить за памятью и чистить все неиспользуемые переменные, ибо память бесконтрольно засирается
3. отсутствие таких коллекций как List<T>, ObservableCollection, dictionary и тд... просто без комментариев
4. отсутсвие linq
n. примитивная низкоуровневость

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

в си шарпе у меня объекты на объектах, они крупные и каждый класс насыщен большим количеством логики. я просто не представляю сколько времени мне бы пришлось убить на возню в с++, это просто страшно.
я понимаю конечно, что как бы "СКОРОСТЬ РАБОТЫ РЕШАЕТ!", что софт на шарпе по определению работает медленнее потому что управляемый код и тд... но всему своё место. я не майнер пишу, который должен быть оптимизирован по максимуму.
есть смысл всю логику перегонять на быстрые языки, если это игровой движок - ну там чем быстрее код работает, тем больше объектов отрисовывает, тут как бы ок. есть смысл нанять толпу батанов из вычислительного центра НАСА, чтобы кодили 24/7 каждую мелочь на цпп и гнались за каждой выйгранной миллисекундой, вполне возможно это действительно оправдано.

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

0

alecss131, тогда боль ещё впереди вся) Задумка у SwiftUI хорошая, тут отрицать сложно. Но вот реализация для реальных проектов подходит очень условно...

0

Что C++, что C#, что все остальные популярные ныне ЯП - это по сути представители древней морально устаревшей концепции текстовых ЯП. Для того, чтобы в этом убедиться - достаточно посмотреть на развитие других смежных IT отраслей и сравнить с софтинженерией. Что предлагается для других специалистов? Системы с богатыми визуальными инструментами. Возьмите хоть дизайнеров, хоть экономистов, хоть инженеров, хоть ученых. Везде существует мощный софт где и в голову не приходит заставить пользователя писать простыни текста на неких искусственных языках.
И только в области разработки подобный устаревший подход все еще всеобще практикуется. Потому вывод тут очевиден. Выбирать нужно не из плюсов, шарпов или десятков других ЯП. Нужно думать наперед и изучать фундаментальные основы IT, чтобы не остаться за бортом, когда этот отмирающий атавизм наконец то отвалится и современные интеллектуальные средства разработки наконец то дойдут и до IT.

0

Катафалк, фига себе какую кучу навалил на вентилятор моё почтение

1

Сообщение от Катафалк ...достаточно посмотреть на развитие других смежных IT отраслей и сравнить с софтинженерией. Что предлагается для других специалистов? Системы с богатыми визуальными инструментами.

Есть тот же SysML, чисто графический, который закрывает изрядную часть задач программной инженерии: анализ, работа с требованиями, архитектура высокоуровневая и низкоуровневая, а также сценарии тестов от модульных до приемочных. И есть неплохая технология Model Based System Engineering (MBSE), которая его интенсивно использует. По крайней мере, я на данный момент не нашел ничего лучше для проектирования, особенно если проект включает в себя еще и разработку оборудования (например, микроконтроллеры); впрочем, для чистого софта тоже вполне годится.

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

Еще где-то в параллельной вселенной существует чисто графический язык ДРАКОН, который яростно продвигает небольшая группа сектантов. Но насколько могу судить, 99.(9)% разработчиков (включая меня) пока не оценила.

Ну и для полноты картины - есть еще какие-то еще эзотерические поделки для детей типа Scratch, которые пока не торопятся во взрослый мир.

0

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

А можно на этих "не атавизмах" написать какой нибудь браузер? компилятор? БД? Может даже чего уже сделано?

Добавлено через 3 минуты

Сообщение от steelcraft Есть тот же SysML,

На чем написана сама эта система?

0

Сообщение от voraa На чем написана сама эта система?

Даже не знаю, как на этот вопрос ответить...

SysML - это не система, это язык (графический), то есть нотация. Ему аналогичны языки электрических схем, машиностроительных чертежей и т.п.

На чем написан, к примеру, язык электрических схем? На русском языке есть соответствующие ГОСТы, определяющие общие правила этого языка. Должны (обязаны!) быть соответствующие национальные и международные стандарты, но лично я их не изучал (не было необходимости строго соблюдать их). Ну и множество картинок, поясняющих текст.

Спросите что-нибудь конкретнее. Например, на чем написан конкретный инструмент, позволяющий строить модели на SysML (не в Paint же рисовать эти диаграммы). Тут уже больше ясности. Например, Papyrus написан на Java; это легко проверить, потому что он open source. Enterpise Architect, которым я пользуюсь, проприетарный, его исходники не посмотреть. Полагаю, что написан на .NET (кажется, при инсталляции потребовал обновить .NET Runtime; но на Библии не присягну, поскольку устанавливал давно).

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

0

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

0

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

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

0

Сообщение от Катафалк Что C++, что C#, что все остальные популярные ныне ЯП - это по сути представители древней морально устаревшей концепции текстовых ЯП.

А что, Метапрог уже релизнулся?!

0

Сообщение от COKPOWEHEU А что, Метапрог уже релизнулся?!

Конечно!

0

Это ж какой-то текстовый недо-язычок, как можно в контексте о графическом программировании рекламировть такое. Вы бы еще С++ упомянули. Есть же прекрасные разработки графических языков, тот же Метапрог https://www.linux.org.ru/forum... /14882171/ Кажется, на нем уже пишут полноценные десктопные приложения вроде будильника (правда, он течет, но это мелочи)

0

Сообщение от voraa А можно на этих "не атавизмах" написать какой нибудь браузер? компилятор? БД? Может даже чего уже сделано?

Пока что, к сожалению, на них нельзя написать ничего за их отсутствием. Зато можно написать очередной стопятисотый фреймворк для вебоговнокодеров, на который они будут переписывать все до чего дотянутся и смогут выбить бюджет на протирание штанов.
Увы, но современная IT-индустрия в глубоком кризисе и развитие инструментов разработки остановилось на уровне полувековой давности. С тех по не было сделано по сути ничего в этом направлении. Чем отличается какой-нибудь паскаль 70-х годов рождения от питона, или от любого другого ЯП, который сегодня повсеместно используется? Вместо begin и end придумали отступы или скобочки. На этом пожалуй принципиальные отличия и заканчиваются. Разработка ведется все также в виде формализованного текстового кода. Что, если взглянуть на вещи объективно, абсурд. Но вместо разработки современных интеллектуальных систем проектирования ПО индустрия предпочитает лепить очередные устаревшие текстовые ЯП, переставляя скобочки и ключевые слова.

1

Сообщение от Катафалк Разработка ведется все также в виде формализованного текстового кода.

Люди за всю историю не придумали более эффективного способа общения, чем текст. Чего вы от программистов-то хотите?

0

Сообщение от Катафалк Увы, но современная IT-индустрия в глубоком кризисе и развитие инструментов разработки остановилось на уровне полувековой давности. С тех по не было сделано по сути ничего в этом направлении. Чем отличается какой-нибудь паскаль 70-х годов рождения от питона, или от любого другого ЯП, который сегодня повсеместно используется? Вместо begin и end придумали отступы или скобочки. На этом пожалуй принципиальные отличия и заканчиваются. Разработка ведется все также в виде формализованного текстового кода. Что, если взглянуть на вещи объективно, абсурд. Но вместо разработки современных интеллектуальных систем проектирования ПО индустрия предпочитает лепить очередные устаревшие текстовые ЯП, переставляя скобочки и ключевые слова.

Это означает только, что у разных ЯП общее ядро и общая логика.
А так - общая логика плюс разные диалекты для кавалеров разных орденов.

Добавлено через 8 минут

Сообщение от COKPOWEHEU Люди за всю историю не придумали более эффективного способа общения, чем текст.

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

Добавлено через 1 час 30 минут
Логика универсальна.
А люди думают каждый на свой манер.
Зато у вас есть выбор.
Выбирайте - begin end или скобочки.
Выбор большой, каждый найдёт себе язык по душе.

0

Сообщение от Ludwig Valentin Это означает только, что у разных ЯП общее ядро и общая логика.

Да не сказал бы. Один список парадигм (процедурное, функциональное, объектно-ориентированное, ...) чего стоит. Нельзя сказать, что lisp отличается от ассемблера только формой скобочек begin/end.

Сообщение от Ludwig Valentin Текст и образы. Сгруппированный текст в таблице.

В смысле отступы в коде? В Питоне с этим даже перестарались: ну не должно оформление пересекаться с функциональностью.

Сообщение от Ludwig Valentin А современные ЯП группируют данные для пользователей.

Не понял фразу. ЯП ведь не для пользователей, а для программистов.

0

Сообщение от COKPOWEHEU процедурное, функциональное, объектно-ориентированное,

на самом деле функция - это процедура с одним возаращаемым аргументом.
а вот объектное - это отдельная парадигма.

Сообщение от COKPOWEHEU В смысле отступы в коде? В Питоне с этим даже перестарались: ну не должно оформление пересекаться с функциональностью.

питона не знаю.

Сообщение от COKPOWEHEU Не понял фразу. ЯП ведь не для пользователей, а для программистов.

да уж.
программист=бог, юзверя=люди, народ.

0

Сообщение от Ludwig Valentin на самом деле функция - это процедура с одним возаращаемым аргументом

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

Это то на сколько я понял отличие процедурной от функциональной парадигм.

0

Сообщение от Ludwig Valentin на самом деле функция - это процедура с одним возаращаемым аргументом.

Но вот сам функциональный подход кардинально отличается от процедурного. Ознакомьтесь с тем же Лиспом.

Сообщение от Ludwig Valentin да уж. программист=бог, юзверя=люди, народ.

Ну, при желании, наверное, можно и так считать

0

Сообщение от alecss131 Не верно, в функциях нету состояний и функция зависит только от входных параметров, по хорошему даже циклов нету.

не совсем понятно.
кто вам мешает использовать цикл в теле функции?

Сообщение от COKPOWEHEU Но вот сам функциональный подход кардинально отличается от процедурного. Ознакомьтесь с тем же Лиспом.

не согласен. дело в записи, а не в принципах.

0

Сообщение от Ludwig Valentin Но вот сам функциональный подход кардинально отличается от процедурного. Ознакомьтесь с тем же Лиспом. не согласен. дело в записи, а не в принципах.

То есть не ознакомились... Это принципиально другой подход к программированию, не тот, к которому вы привыкли

1