Александр

Добрый вечер! Столкнулся с такой проблемой: Мне очень нравятся семейство языков Си, у меня есть выбор учить C++ либо C#, хочу разрабатывать ПО для ПК. Подумал начать с C++ и говорят что сначала поучить чистый СИ, а после переходить на C++, так что же из этого правильно? Надо ли учить Си? Или может лучше начать с C#, а дальше уже выучу C++?

Тема сравнения С/C++/C# в публичном пространстве - опасная тема. Она обычно заканчивается
топиком в 1000 страниц и великой войной всех против всех. Я видел много таких войн.
Они ничем не заканчиваются. Специалисты остаются при своих мнениях. А зритель просто развлекается.

Сам по себе выбор языка ставят только новички. Професиионалу безразличен язык (почти). Его может больше интересует отрасль, стек технологий, стандарты и протоколы. С моей точки зрения сегодня
таким стандартом может быть выбор облака (AWS, Azure, GCP).

Чистый СИ учить смысла нет. Учи сразу С++. Но даже его создатель Бьорн Страуструп считает что С++ это
сложный язык и он настаивает чтобы новички не брались учить все фичи сразу. Исключение по языку
СИ может быть в том случае, если ты собрался быть инженером по разработке микро-контроллеров
и у тебя скорее всего будет только СИ как основной (на 80-90%) инструмент взаимодействия с таким железом. Выйти на мидловый или синьорный уровень в С++ очень тяжело. Тяжелее чем в других языках.
Поэтому будь готов терпеть. Вот когда виски станут седые - тогда и будешь господин-синьор.

C# - это очень сильно корпоративный стандарт от Microsoft. Никакой связи с С++ он не имеет. Он конечно
внешне похож но это сходство обманчиво. Да изучать его тоже можно. Он учится легко. Существуют книги
вроде ".... C# за 14 дней". Разработка бизнес-приложений на шарпах идет гораздо быстрее чем на С++
например. И завалить систему в синий экран в этом языке гораздо труднее. В нем реализованы методы
защиты памяти и нельзя грязно трюкачить с указателями как это любят в С или С++. Производительность
шарпов в численных методах будет слабее чем в С++ но обычно бизнес не ставит таких задач и чаще
надо будет писать веб-хендлеры или хендлеры MQ-систем. Кач уровней синьорити идет быстрее в шарпах.

Ассемблер полезен при анализе прошивок на безопасность.
При изучении того как работает софт без исходного кода (обратный инжинеринг)
и при решении задач интеграции разных слоёв софта.

Ассемблер также очень близко стоит к разработке компилляторов. И если у вас нет
соотвествующих знаний то строить свой компиллятор вы не сможете. Или вам нужно
будет изучать готовые back-ends, virtual-machines.

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

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

1) Можно создать 7 фолдеров типа /disk1, /disk2 .... и примонтировать диски через mount.
2) Можно собрать ZFS pool из 7 дисков и подключить их все как один большой диск (zpool create).
3) Программный JBOD на базе Btrfs (mkfs.btrfs ... )
4) LVM как уже писали выше

1. Java (JDK/JRE) не содержит в себе драйверов доступа к БД вообще. В ней определен только базовый
интерфейс java.sql.* и существует некий стандарт на то как драйверы должны работать. Например когда мы делаем ResultSet::close, или Statement::close, драйвер может ничего и не делать в этот момент. Все зависит от того
как производитель (Oracle, MSSQL) реализовал под капотом работу драйвера. Поэтому как работает внутри драйвер это - тайна.

2. Обычно если в приложении тебе часто и много нужно создавать объектов Connection, то используют пулы коннектов (Hikari Connection pool, DBCP, C3PO). Почитай в этом направлении. Пулы экономят сессионные
объекты на стороне БД и создают новые коннекты быстрее за счет переиспользования сущесвтующих коннектов.
В обычном (прямом режиме) работы с БД процесс установки соединения может занимать несколько секунд.
Это может быть запредельно медленно для некоторых алгоритмов.

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

Бизнес успех таких сетей как VK, Facebook слабо связан со стеком. Они все стартовали с PHP но просто
очень умно кешировали контент и децентрализовывали. Поэтому в первую очередь важен скилл
специалистов которые будут видеть узкие места в системе и сумеют быстро их пофиксить.

Популярность.

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

Скорее всего коды SQL ошибок зависят от DBMS. Например я по старой памяти помню что если
в коде вы видите ORA-00001 то вы скорее всего используете Oracle и ваша ошибка
связана с нарушением Primary KEY во время INSERT/UPDATE.

Другие DBMS (Postgres/MySQL) будут иметь другие коды ошибок.

В конце 20-го века, когда Эдгар Кодд развивал свою реляционную теорию было очень
модно все данные нормализовывать для хранения их в БД. Это соотвествовало экономии
ресурсов (диски мерялись килобайтами и мегабайтами) и нормализация хорошо ложилась на
техно-стек. Все данные должны быть атомарны. И ты - плохой DBA и программист если
кладешь в ячейку что-то более комплексное чем просто атом.

В 2000х развитие веб и XML(XHTML/SGML, XSLT, XPath) дало толчок новым видам
хранения информации в виде markup languages. Появляются технологии семанического веба.
Мечтатели-теоретики создают RDF, OWL. Базы данных пытаются успеть втянуть в себя новые типы.
Oracle начинает поддерживать XML+Schema как тип данных в таблице. Браузер начинает
поддерживаеть трансформацию XML и обогащение его стилями. XML - моден. Его внедряют
везде где можно и где не нужно. Даже в конфигах Apache Http и в сборщике Maven.

Параллельно Дуглас Крокфорд работает над Java Scrip Obj Notation и создает лайтовый язык
для описания объектов и документов. Они - конкурируют с XML но JSON практически побеждает
в вебе, полностью захватывая веб протоколы (Ajax, WebSockets, e.t.c). И интеракцию с сервером.
JSON становится более популярный для REST. Многие БД тоже начинают поддерживать JSON.
Postgres даже делает бинарный JSON и добавляет спец-индексы для быстрого поиска атрибутов.
Узко-специализированные системы такие как Mongo изначально заточены на храннение JSON
информации.

BigData плавно проростает в 2007 (кажется) и где-то в 2014 (или позже) году фреймворк Spark начинает поддерживать DataFrames + Structured Types которые по сути являются зеркалом JSON. Фреймворк
позволяет грузить в бигдату JSON-lines датасеты, автоматически выводя схему.

Это - финал. Я считаю что после такой конвергенции в бигдату JSON получил путевку везде где только можно.
Сегодня вы можете без стыда использовать JSON везде в любых уровнях стека (даже в Redis) если
у вас хватает памяти и вы уже порешали вопросы бизнес-согласованности данных и умеете эти
данные инвалидировать и обновлять.

Если поискать анти-паттерны применения JSON в базах данных - то я-бы предложил такую метрику.
Если вы очень часто обновляете маленькое поле внутри большого JSON документа и это создает
сильные I/O нагрузки то скорее всего вам надо перепроектировать вашу БД как-то по другому
и вынести это поле во вне по отношению к документу

Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

Главный поинт при создании immutable String - безопасность кода. Когда компиллятор точно
знает что value строки не изменится - то он может доказать много кейсов и гарантировать что
разделяемая память не будет сломана. Особенно это важно для мультипоточки. Когда
разные потоки владеют строкой и здесь сам вопрос доказательства вдруг становится очень важным.

Язык С++ например такой защитой не обладает и для него строка как фундаментальный тип
может иногда мутировать. Тоесть если вы старались писать правильно то она конечно не мутирует.
Но в этом есть большая разница между C++ и Java. На уровне платформы гарантировано отсуствие
какого-то класса ошибок.

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

Специально для уменьшения этой проблемы (реаллокации и копирования) был создан StringBuilder.
Это вообще не строка а как-бы мутирующий буфер куда можно добавлять в хвост строки. И в конце
когда все готово - из буфера берется иммутабельная строка и на этом работа билдера закончена.

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