Переход с Java на C++

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

Пердолингом с субмодулями?

apt, rpm, pacman, emerge и есть пакетный менеджер для инфрасктуры С/C++.

Нет.

Пердолинг мы не одобряем.

Почти все юзкейсы закрываются добавлением директории deps, в которую скриптом из системы сборки скачиваются и собираются либы. Ты конечно скажешь: «в cargo проще». А я и соглашусь, но замечу, что на это тратится всего несколько минут, то есть примерно 0% от общего времени разработки. Поэтому проблема выдумана.

Java - религия.
Плюс C++ сложнее, модным синьорам не комфортно снова джунами себя чувствовать.
Так что без шансов.

Если и есть ПМ то только vcpkg!

не возвращаться во всё это после Java или C#

Не берусь судить про Java, но вот система сборки C# - это мрак. Файлы проектов свершенно неудобопонимаемые из-за пристрастия к UUID и всяким ID, вручную их тоже трудно поправить, если что-то не так.

Плюс C++ сложнее, модным синьорам не комфортно снова джунами себя чувствовать.

Почему обязательно джунами? К тому же некоторые знания о C/C++ у большинства Java синьёров уже есть, пусть и весьма старые, покрывшиеся паутиной. Но согласись, что такому будет гораздо проще войти в мир C++14 и выше, чем настоящему джуну.

Забавно, что при этом шарпающие обычно любят везде заявлять, что у них всё на много лучше, чем в Java. :-)

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

Но система сборки - мрак.

Не берусь судить про Java, но вот система сборки C# - это мрак. Файлы проектов свершенно неудобопонимаемые из-за пристрастия к UUID и всяким ID, вручную их тоже трудно поправить, если что-то не так.

вообще нет UUID и ID. Всё пишется легко в ручную, поэтому и поправить всё легко. Ты явно что-то путаешь в .Net лучшая система сборки, вот почитай faq: https://fake.build/fake-what-is-fake.html

https://fake.build/

Что там в F# - не берусь судить. Я про .csproj и .sln файлы

Типа такого

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{32504A71-97E5-4566-B7A5-5E32E4E20A03}</ProjectGuid>
    <OutputType>Exe</OutputType>
    <RootNamespace>NoRTServer</RootNamespace>
    <AssemblyName>NoRTServer</AssemblyName>
    <TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <Deterministic>true</Deterministic>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <PlatformTarget>AnyCPU</PlatformTarget>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
...
  <ItemGroup>
    <Reference Include="Gnu.Getopt, Version=0.9.1.0, Culture=neutral, PublicKeyToken=d014b4ccdc53511a, processorArchitecture=MSIL">
      <HintPath>..\packages\Gnu.Getopt.0.9.2\lib\net20\Gnu.Getopt.dll</HintPath>
    </Reference>
    <Reference Include="Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
      <HintPath>..\packages\Newtonsoft.Json.12.0.2\lib\net45\Newtonsoft.Json.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Core" />
...

Типа такого

Так тут почти всё удалить можно: https://natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/

Смотри «new» варианты. И для новых проектов просто выбирай .Net Core, даже если нужен Framework, просто потом в TargetFramework меняешь на какую нужно версию Framework.

ну у меня monodevelop, тут немного поменьше возможностей. Ну или я не понял, как

ну у меня monodevelop, тут немного поменьше возможностей

Ну да, я тут погуглил, есть такая проблема.

1. .Net core есть под Linux.

2. Можно с новым форматом сказать, что собираем не .Net core, а Mono.

3. Но Monodevelop не понимает этот формат, так что с новым форматом будет работать лишь VSCode, но не Monodevelop.

А ещё вот что нашёл. В 8 версии вроде нормально работает .Net core формат проектов, но только Monodevelop для Linux помер :(

Печаль:

https://github.com/mono/monodevelop/issues/8006

https://user-images.githubusercontent.com/16335601/70079376-ea9c1800-1604-11ea-8ffe-49984b7bc16a.png

Каждый второй питонщик заткнет того архитектора NLP и прочим матаном.

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

Например современные программисты на C++ уже почти перестали пользоваться операторами new и delete

Нет. Потому что, как я писал выше, во многих библиотеках используются new/delete (delete редко), и при использовании этих библиотек ты тоже вынужден их использовать.

Да тот же Qt. Там постоянно используются new, ну конечно вместо delete там объект.deleteLater() (а также автоматическое удаление по иерархии), но как бы все равно иногда ручной вызов deleteLater() нужен.

Тут ещё надо уточнить, что такое программист C/C++. Потому как тут есть несколько плохо пересекающихся направлений. Как я понимаю, основные три ветки - Qt, игры, embeded. Последний тоже делится на 2,5 ветки - устройства на linux, мощные ARM-микроконтроллеры, маломощные (и устаревшие) микроконтроллеры (8051, PIC и т.д.).

Так вот в Qt, вероятно, ещё можно перейти, теоретически, а на счёт остальных веток сомневаюсь. Например, программист embeded должен знать электронику (АЦП, ЦАП, ШИМ, всякие интерфейсы типа UART, SPI и т.д. не говоря уже о всяких компараторах и выходах с открытым коллектором).

Кстати, есть ещё штука, которая полезна программистам из разных областей, но почему-то обычно её понимают только embeded-программисты. Я говорю о гистерезисе. Кроме того, программисты на C# и Java обычно плохо понимают, что такое миллисекунды, не говоря уже о микросекундах.

Обратный переход тоже имеет проблемы. Если, например, попросить embeded-программиста сделать приложение с GUI, то он, скорее всего, либо не осилит, либо чего-нибудь навелосипедит на чистом Win API. Как это безобразие потом поддерживать его не особо волнует.

АЦП, ЦАП, ШИМ, всякие интерфейсы типа UART, SPI и т.д. не говоря уже о всяких компараторах и выходах с открытым коллектором

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

Кстати, есть ещё штука, которая полезна программистам из разных областей, но почему-то обычно её понимают только embeded-программисты. Я говорю о гистерезисе

чем гистерезис полезен программистам?

А оно им надо?! Еще обижать будут за ламерство. А в джабке такое — норма.

чем гистерезис полезен

он вреден )

темы довольно простые и это основы при программировании микроконтроллеров

Темы простые, но на практике надо знать всякие тонкости, типа чем отличаются интегрирующие АЦП (к которым можно отнести и сигма-дельта) от АЦП последовательного приближения, надо знать типы погрешностей АЦП, влияние устройства выборки-хранения на процесс измерения (тут же особенности использования мультиплексора). UART, например, тоже не сам по себе обычно используют. Поверх него Modbus налепляют. Есть что поизучать.

чем гистерезис полезен программистам?

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

Не видел таких примеров. Почему? Потому что на C/C++ другие задачи и с самим инструментом сложнее работать.

Как я понимаю, основные три ветки - Qt, игры, embeded.

Нет. А highload и bigdata куда дел? Qt кстати загибается, всё давно в web переехало, Qt нахер никому не надо.

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

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

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

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

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

А highload и bigdata куда дел?

Я в этом не разбираюсь. Мелких веток может быть ещё больше. Кроме того, в вакансиях на эти темы чаще встречается Java, C#, go, и даже python с PHP.

Qt кстати загибается

В hh.ru:

Qt: 103 вакансии.
bigdata: 56 вакансий
highload: 92 вакансии

В последней вакансии больше нужны девопсы и тестировщики.

ведущий инженер-программист

Qt кстати загибается, всё давно в web переехало, Qt нахер никому не надо.

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

Кроме того, в вакансиях на эти темы чаще встречается Java, C#, go, и даже python с PHP.

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

В hh.ru:

Ты думаешь, что в вакансии про highload будет присутствовать это слово? Вот тут этого слова нет: https://yandex.ru/jobs/vacancies/dev/distr_syst_dev-expert_yd/

ведущий инженер-программист

А куда и кого он ведет?

неведущих инженеров-программистов к светлому будущему в виде получения зарплаты

проводники к АЦП микроконтроллера ведёт

Вы всё верно говорите. Но что это доказывает? В узкую нишу перебраться ещё сложнее.

Если человек ковырял на java что-нибудь типа hadoop-стека, то он и эту нишу осилит. Я знаю несколько таких товарищей.

Хорошо. Вот и ответ на вопрос темы. То есть важнее предметная область, а не язык.

Разупорись! Что может более отталкивающим, чем системы сборки в жабе? о_О

А что в них не так? Я правда пользовался только maven, gradle, npm+webpack, везде было все ок. На самом деле самая не тру сборка была во времена ant, когда зависимости/библиотеки бережно складировались прямо в проект, в отдельную директорию lib, и заливались на CVS/SVN.

которую скриптом из системы сборки скачиваются и собираются либы

Каким ещё скриптом? А если зависимость не использует любимую систему сборки и нужно писать свой костыль?

Мне приходилось сталкиваться с maven и gradle и почему-то они кажутся очень серьезно заоверинжиниренными. Впрочем, после того как потребовалось собрать tensorflow и я столкнулся с bazel, я понял, что у них все ок.

За годы пользования maven я так к нему привык, что я не думаю о скрытой сложности, теперь он для меня как старый, ламповый телевизор, знаю куда стукнуть чтоб он заработал :) Gradle для меня чуть сложнее, но я привыкаю.

Я понимаю о чем ты, я сам испытал шок взглянув на тулы для бэкапов, начал читать про Borg, мне показалось это оверинжиниринг, испугался что я не смогу вытащить бэкап если что-то поломаю. Опыта тут у меня нету! В итоге написал скрипт для шифрованных бэкапов с использованием tar + openssl.

Каким ещё скриптом? А если зависимость не использует любимую систему сборки и нужно писать свой костыль?

Зависимость использует какую-то систему сборки, вот ее и надо дернуть скриптом из системы сборки твоего проекта. Ещё зависимость может не иметь исходников (раст так может, кстати? Наверное надо будет делать биндинг?), тогда просто скачать и все.

Зависимость использует какую-то систему сборки, вот ее и надо дернуть скриптом из системы сборки твоего проекта.

Дёргать autotools из cmake? У вас там всё хорошо?

Конечно, у меня все хорошо. Если ты говоришь о CMake, он это поддерживает через ExternalProject_Add.

Ответь про раст, правда интересно.

Что может более отталкивающим, чем системы сборки в жабе? о_О

Системы сборки в крестах

Системы сборки в крестах

Притом это одни и те же системы сборки :)

https://mesonbuild.com/

supported languages include C, C++, D, Fortran, Java, Rust

Из наиболее банального - удобные геттеры и сеттеры.

В Java давно появился Lombok, делающий жизнь проще. Хотя и не все джаваисты его одобряют.

Но система сборки - мрак.

Почитал сейчас про NuGet. Вроде бы почти тот же Maven, но для .NET

Ну для меня хорошесть системы сборки в значительной степени определяется возможностью поправить руками если что то пошло не так. И тут все не очень хорошо. Хотя возможно формат net core и получше

Разупорись! Что может более отталкивающим, чем системы сборки в жабе? о_О

Что же там такого отталкивающего? По твоему писать Makefiles приятнее?

Тут ещё надо уточнить, что такое программист C/C++.

В данном случае речь идёт о переходе лишь на C++, причём современный.