Выбор языка

Продолжать штудировать C++ до просветления и не ныть.

Рад за тебя, я бы сдался только только из-за фразы – «чтоб стать хорошим C++ программистом нужно 10 лет практической разработки на нем»

Бери Перл, не прогадаешь.

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

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

Го это что то среднее между Си и Растом. Уже есть кое какая инфраструктура, можно полу-автоматически все подтягивать и получить рабочий проект буквально мгновенно, но чуть менее удобно, чем в Раст - вместо единой команды на все, несколько команд, бинарники побольше выходят, модули похуже (чисто мое субъективное), синтаксис не настолько однозначный.

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

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

А чем молодые языки Go и Rust лучше старичков Delphi и Visual Basic? Ведь чем старше язык тем больше наработок под него должно существовать? Delphi и Visual Basic тоже входят в перечень языков, где можно получить первый рабочий проект за короткое время?

А чем молодые языки Go и Rust лучше старичков Delphi и Visual Basic?

Ты не найдешь сообщество которое пишет стати и код в актуальные проекты. Найдешь только кучу старой инфы, заброшенные либы, нерабочие плагины к IDE. Короче, окажешься один, без поддержки, без ответов на stack overflow.

Я пока не придумал что на это ответить. И врядли придумаю..

Сначала программирование выучи. Потом смотри на инструменты.

Учи С без плюсов, там есть char* а всего остального нет

Чего не сразу ассемблеры?

Невозможно понять компьютеры

Надо задачу понимать, а не компьютеры.

В Java с указателями еще сложнее, они скрыты. Изучай несколько языков, какой то да пойдет.

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

Java - Сервера, Android

C++ - Высокопроизводительные приложения, игры, десктопный софт

C - Классика

Ассемблер x86 - Я рекомендую

Python - Пригодится

JavaScript - Можно строить веб только на нем и HTML+CSS, может быть на клиенте и сервере

SQL - А как без баз данных?

Rust - После С/C++ можно посмотреть

Lisp, Forth - Для развития полезно

Shell/Bash - Актуально для Linux

Lazarus - Лучшее из доступных формошлепств под Linux

Ведь чем старше язык тем больше наработок под него должно существовать? Delphi и Visual Basic тоже входят в перечень языков, где можно получить первый рабочий проект за короткое время?

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

Ппц тут нытья навалили.

Бро, изучай С++ и не парься. Это мощный универсальный (многонишевый) язык, на котором написаны мегатонны софта и который не собирается сдавать позиций. Rust? Лет через 15 напомните глянуть снова.

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

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

По источникам: забей на Страуструпа, он так себе учитель и точно не для начинающих. Прата норм, но вообще лучше читать сразу несколько книг (сам так делал). И чатгпт тебе в помощь, он терпеливо объяснит всё что угодно и сколько угодно раз.

Ассемблер x86 - Я рекомендую.

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

Если уж смотреть на Ассемблер, то для микроконтроллеров с их сотней команд. Просто, понятно, полно работы вокруг.

Сотня команд и в x86, если отбросить расширения. К тому же он удобен для ручного программирования, все же CISC. А макросы FASM просто прекрасны даже отдельно от ассемблера.

Про пользу, можно смотреть на godbolt и читать -S или дизассемблер gdb. Легче заниматься всякими микро-оптимизациями, когда знаком хоть как то с моделью x86, а не просто абстрактной машиной.

Можно заниматься построением своей ОС, и своего компилятора. Свой редактор и плеер можно тоже на ассемблере написать.

У меня когнитивный диссонанс. Как в С++ при всей его древности, популярности, универсальности и прочее прочее так все через жопу сделано? Почему?

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

C++ популярен в основном потому быстрый и ООП, к нему все привыкли, а альтернативы !популярны||медленнее||жрут память||!ООП:

https://github.com/niklas-heer/speed-comparison

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

Мне раст зашел пока больше всех. А с полноценным ООП что есть приличное, если не брать С++?

Ну смотри. Мне надо подтянуть модули, собрать, запустить приложение. В том же расте это делается через cargo одной командой. Само подтянет, само соберет, все работает. Главное версию выбрать нормальную.

В том же го - двумя-тремя командами. В питоне тоже есть pip.

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

Для этого есть vcpkg, и в IDE есть графические интерфейсы для него.

Вот например, тебе нужен sdl2. Как это делается? Да одной командой:

vcpkg install sdl2

Спасибо, гляну. Но я понял, что надо базу подтянуть. Нужно еще документацию почитать, основы.

А для работы с zip-архивами не подскажешь что надо?

Я больше по С, для него есть очень простой и понятный libzip. Для С++ есть обвязка с названием libzippp:

ZipArchive zf("archive.zip");
zf.open(ZipArchive::Write);
zf.deleteEntry("myFile.txt");
zf.deleteEntry("myDir/subDir/");
zf.addData("helloworld.txt", textData, 12);
zf.close();

Как в С++ при всей его древности, популярности, универсальности и прочее прочее так все через жопу сделано? Почему?

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

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

В Java с указателями еще сложнее, они скрыты.

Ну, с точки зрения абстракции языка, в Java указателей нет вообще, зато есть ссылки. Но ссылки не являются указателями. Ссылки, по сути, являются системой имён. Даже на уровне работы JVM, ссылки реализуются не непосредственно указателями, а дескрипторами, где адрес в памяти является выводимой величиной.

Кажется до меня дошло. Раст это готовый продукт, выпускаемый одной фирмой, а С++ это стандарт, а не продукт. И этот стандарт каждый крутит сверху как хочет. В этом и беда. В итоге нужно искать кто что навертел у себя.

От того что внутри указатели не машинные, легче не становится. Очень легко по незнанию допустить ситуацию когда меняешь объект А, а где то еще теперь меняется и объект Б. В C/C++ есть копирование, поэтому там такое возможно допустить только осознанно с указателями.

Скоро появятся альтернативные компиляторы Rust. Об этом Страуструп еще писал давно, типа посмотрите на Java, все называют ее простой, но подождите пару лет, когда он станет распространенной, и вы увидите все те же проблемы что и у С++. И действительно, язык стал намного сложнее, есть всякие Ant, Maven, Gradle итд.

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

В С++ такого нет - нужно самому собрать рабочее из обрывков технологий.

С++ - самый расширяемый язык

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

Плюсы тоже так могут, но только тогда когда предоставляют C интерфейсы

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

rustc: g++
rust-doc: cppreference
rust-analyzer: clangd
cargo: cmake + vcpkg

Ну а больше у Rust вроде ничего и нет.

Я к тому, что это продукты разных компаний. Их изначально надо найти. Вот я до вчера не знал про vcpkg. Плюс к этому - это, вроде как, майкрософт.

И разрабатывают их разные группы с разным пониманием куда двигаться.

А инфраструктура тот же раста единая в рамках одной компании и одного вектора.

Я к тому, что это продукты разных компаний.

В этом я проблемы не вижу.

Их изначально надо найти.

В этом вижу, да. Но я выше список скинул, так что ты считай уже все нашел.

Плюс к этому - это, вроде как, майкрософт.

Microsoft владелец GitHub, куда от него сбежишь...

И разрабатывают их разные группы с разным пониманием куда двигаться.

Не думаю что движение разработчиков компиляторов, пересекается с движением разработчиков ПМ. В любом случае их всех объединяет стандарт который разрабатывается совместно.

И вот про этот «стандарт» можно поговорить отдельно. Очередной когнитивный диссонанс, когда вместо реального стандарта лютое нагромождение странных непоследовательных понятий.

Вот как в раст:

i8, i16, i32, i62

u8, u16, u32, u64

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

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

Так в С++ тоже все последовательно, https://en.cppreference.com/w/cpp/header/cstdint

int8_t, int16_t, int32_t, int64_t

uint8_t, uint16_t, uint32_t, uint64_t

А размер платформозависимых типов (int, long), ты и не должен пытаться угадать.

Охренеть! Вот это поворот! Спасибо. Ушел изучать.

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

Всякие uint*_t хороши там, где тебе надо разобрать либо наоборот записать файл или сетевой пакет жёстко заданного формата.

Скоро появятся альтернативные компиляторы Rust.

У кого-то на хабре бомбануло от Столярова (комментарий)

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

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

Платформозависимые типы обычно дают большую оптимизацию.

(u)int*_t это же typedef на платформозависимые типы, если мы говорим о x86. Для какой платформы твое утверждение верно? И не забываем что есть int_fast16_t, которые строятся на быстрых платформоразмерных типах.

Будут проблемы если работать с малыми типами на платформе у которой они медленные, но если выбран малый тип, то наверное так и нужно?

Это не связано с альтернативными имплементациями. Вообще ситуация распространенная, Firefox, Rust, PHP. JavaScript вроде бы свободен, но имя вообще принадлежит Oracle.

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

Ну и бредятина. Загляни в godbolt, посмотри какой год генерируется для int64_t на x86_32 где никаких 64-битных регистров нет.

Так что LightDiver советую поменьше слушать всяких экспертов. Все надо самому проверять.

Только Go, парень. Только Go. Без вариантов.

Добрый день. Когда-то у меня тоже был такой вопрос, когда душа требовала развитие. В итоге выбрал для заработка денег 1С, а MASM сменил на PureBasic. В итоге по работе почти все предприятия к себе зовут работать, а для себя на пурике прям офигенные проекты пишу. При этом имеются несколько предприятий в собственности (это результат работы с 1С). Рекомендую подумать как раз в таком направлении - заработки и реализация себя. Не надо быть похожим на кого-то, а достаточно для себя определить критерии успеха и неудачи и опираясь на них развиваться

Пурик, это только обёртка над FASM-ом, либо на Си. ООП там нет, но и на асме тоже нет. Спецы там реализуют все фишки ООП, но это кому надо. У меня текущий проект работает и под виндами и под линуксами и под х64 и под х32. Например, сервер комплекса крутится на древнем атоме под ВинХР, а клиенты от Debian х32 до Вин11. На Си или тем более на асме никогда бы не смог написать из-за масштабов, а на пурике прям легко. Проект представляет из себя комбайн:

• Резервирование изменеённых фалов
• Общие папки, работающие в медленном режиме
• Слежение за пользователями

Го и Питон не осилил из-за их разорванности и нелогичности. С# сразу откинул из списка рассматриваемых, т.к. он гвоздями прибит к винде. Джаву тоже потыкал и из-за тормознутости исключил из своего списка

Так что это просто совет - поглядите пошире

Лучший язык, это ADA

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

Любой язык харош по своему но по моему мнению

C - язык микроконтроллеров, чем проще твой код написан тем лучше главное в нем это проверки после каждого Чи-Ха

Bash - спасает часто когда тебе нужно быстро что-то сделать своё

Python - ну тут говорить нечем, ии, выжирать страницы

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

1c он только в СНГ распространён или я ошибаюсь?

И в США есть и в западной Европе, но тут смысл именно в направлении. А вообще для иностранных компаний можно изучать Когнос, САП, ну и т.д. Это не ЯП общего назначения, а именно среды разработки для решения задачек от бизнеса. Основная идея - это 1С-подобная среда для заработка и крутой ЯП для души. Как мне показалось, это прям идеальная связка Бывший коллега с С# на 1С перешёл, т.к. ну очень кушать хотелось. И ничего, свои 300-350 тысяч зарабатывает, ковыряясь в носу. А для души JS использует. Другие коллеги на предприятии Когнос ковыряют, а для души питон используют. Прям совсем не переживают за завтрашний день. Ну и т.д.

Мне было бы удобнее писать просто string, а тонкости чтобы додумывал компилятор.

Во-первых, так можно. А, во-вторых, если уж и хочешь изучить плюсы - изучи сначала си

O’Caml и т.д

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

вот допустим хочу я поработать с библиотекой sqlite3, там такая функция есть

именно хочется использовать sqlite3_exec или подойдет для изучения и Qt для доступа к БД ?

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

В книге Программирование на языке Rust все это разрисовано.