> Я понял на счет возраста — хорошо, вы победили. 18-летние тоже теперь не круто.

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

> А как вам незабвенный подвиг-пример Стрелки и Белки, у них вон, тоже опыта не было, так зачем переплачивать?

Они добровольно всю жизнь учились ради этого подвига?

Всё, я дальше постараюсь молчать. Сказанного достаточно;)

а что по-вашему должен уметь джун?

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

Описанная sashaeve классификация некорректна потому, что не указывает уровень сложности решения. Вот избитый пример. Есть несколько алгоритмов сортировки, уже реализованы, надо выбрать правильный. Но один не сохраняет порядок равных ключей (а это важно для задачи), у второго есть плохие случаи как раз на данных, которые типичны для задачи, третий всем хорош, кроме недопустимых трат памяти, четвёртый медленный. Выбор из этих очевиден — четвёртый. Может такой выбор сделать «джун»? Да, может. Он может его обосновать? Да, может. Так что, он уже «сеньор»? Наверно, нет — он, может быть, вообще ничего сложнее лабораторной работы не писал. Тогда в чём проблема? А проблема в том, что такая классификация, как у sashaeve, работает только тогда, когда знания порождаются из практики и подаются вслед за ней — то есть сначала «джун» должен научиться писать код на самом нижнем уровне (присвоения, условия и т.д.) и только тогда ему скажут, какие есть методы. А это и есть чистейшее ПТУ. Плюс к этому подобная постановка проблемы вообще возникает только тогда, когда есть жёсткая иерархия на основании постоянных условий работы. Опять же это не программирование. Я вот вполне себе «архитектор», по этой классификации, в своих областях (например, мониторинг), но я скорее всего буду «джун» в игровой графике.

За первую основу эта классификация, конечно, годится. Но её надо дополнить разделением как минимум на 3 слоя, сочетающихся в каждом человеке -
1) общая зрелость (пригодная для всего, от копания канав для программирования), включающая в себя такие свойства, как психологический опыт (работа в коллективе, предупреждение и решение конфликтов...)
2) общий уровень в IT, не зависящий от направления (включает в себя всё от понимания и умения разных VCS и бэкапов и заканчивая общими принципами программирования, которые проявляются везде)
3) способности в конкретной области

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

У меня есть очень простая классификация ИТ специалистов:

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

Как-то у вас очень странно получается — юниоры вообще тупые ПТУшники. Это такие кадры в ваших краях?

Раньше 27 лет (армия + обязательное высшее образование для того, чтобы иметь теоретическую возможность работать в ИТ отласли) айтишников вообще не найдешь.

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

900-1200 тогдашнему программисту можно было получить только при высочайшей квалификации, работе в две смены ежедневно, работе по трудовым договорам, а не в штате, и ещё и мелким обманом (например, числилось 3 человека при одном исполняющем). Иначе такие зарплаты не прошли бы ни локальный контроль, ни ОБХСС, который напортил бы нервов не менее, чем современная налоговая.

То есть я рад способностям Вашего отца, но это откровенно исключительный случай. Для большинства потолком были общестандартные 250, и то если повезёт.

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

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

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

Вот им и будет польза от такого изменения.

але якщо концептуально відмовилися від обробки виняткових ситуацій, наслідування, значить на те є причини.

Ага. И основной причиной — личное ниасиливание. Смотря на некоторых участников его core team, я в этом не сомневаюсь — там получилось потрясающее сборище типа “сделаем Си, но не такой как Си. что? хоть одна концепция разработки после 80-го года? да идите в сад!”

відкомпільованих різними компіляторами (або з різними опціями компілятора)

Возможно, это специфика мира Windows? В Unix все согласовали необходимые параметры, и пока нет принципиального нарушения ABI типа прыжков между 32- и 64-битным кодом, нет проблемы согласования кода разных компиляторов.

або юзати extern “C”.

Для связей не с C++ - да, это основной метод, и что в нём удивляет?

іноді треба просто відключати рантайм бібліотеки (разом з сапортом ексепшенів)

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

Якщо брати історію, Sun 10 років тому теж мав ще нерозкручену Java.

Вы как-то странно знаете историю. Java стала достаточно раскрученной — на ней начали создавать приложения — уже в 97-м.

що Го створене в коропрації “бобра”

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

Це фіча!

“Я инвалид нулевой группы, и это фича” :)

А як же “теплий ламповий С”, де навіть повертаєм через ретурн код обробки\помилки, а через жо-пу дані?

Вы не знаете C. Возврат структуры из функции существует как минимум со стандарта 85-го года. Ну а называть указатель жопой... извините, я не могу принять такой жаргон в качестве допустимого на работе.

Та й прогресивний С++11, щось не пішов далі, не повертає навіть два параметра через ретурн.

Запросто решается, например, в boost на том же уровне, что в Go. Зачем вводить это в язык?

А обробка ексепшенів — супер досягнення 20 століття, і кидання виняткової ситуаціїї і намагання її піймати хіба не черговий костиль?

Всё костыль. Но разной степени полезности и с разными побочными эффектами.

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

Не зря, как только идея *параметризованных* исключений была сформулирована, она начала массово приниматься в языки. (А вообще механизм исключений существовал ещё в 60-е, хоть и в достаточно своеобразном виде.)

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

А шо, використання синхронного обміну непристойніше за goto?

Оно часто просто неадекватно. Когда вы передаёте что-то длинное, но одновременно надо и принимать кадр данных с другой стороны (в котором может быть, например, и приказ немедленно остановить передачу) — на синхронные методы это в принципе не ложится.

Я розумію, всі такі розумні пишуть код, який повинен розгортатися на будь якій сферичній платформі у вакуумі, і портуватися у всіх ортогональних напрямах, і лише я один неуч, намагаюся робити поменше і попростіше (привіт K.I.S.S.), бо високі абстракціїї напрягають мій мозок і ускаладнюють систему.

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

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

Пан Маестро не представляє з чого складається і як працює система

Пока что я не увидел оснований для такого вывода. Вам первое возражение против Go состояло вообще в отсутствии исключений и IDE. Какое они имеют отношение к “нагромождению абстракций”?

а VHDL можна сюда якимось боком приплести.

Ко взаимодействию разных компонентов? Ну если Вас устроит представление любых данных в виде массива линий со значениями 0/1/x/z, то да, можно и на VHDL:) Только не думаю, что много задач такое выдержат как нормальный вариант.

компільований та й без особливих заворотів

Отсутствие исключений это теперь “без особых заворотов”?

читабельний.

Не-а. Синтаксис тошнотворен.
Начиная с деления на операторы (повторены и “улучшены” ляпы Javascript с аналогами), продолжая разделением экспорта регистром букв при отсутствии алиасов имён, и заканчивая тем, что в XXI веке у его авторов не хватило ума убрать 0 как префикс восьмеричных констант, хотя для этого достаточно умственного уровня улитки.

ну і з потоками ніби “дружить” без зайвих приблуд.

Когда нельзя даже просто выяснить, создалась “горутина” или нет... это не дружба, это патология.

Разумеется, есть и хорошие решения (хотя, всё новое не оригинально, а всё оригинальное не ново). Например, система типов, или оператор выбора с возможностью чтения из потоков (хотя не все реально нужные полезности есть). После Erlang хотелось бы видеть выбор по принципу “из такого-то канала — сообщение по такому-то шаблону, но просмотр вглубь не далее заданного количества сообщений”, но даже просто выбор из нескольких каналов приёма уже колоссальное достижение.

В целом, он способен играть где-то на том же поле, что Erlang, после некоторой доработки (построить аналог OTP, обеспечить контроль порождения и завершения горутин, сделать исключения). Как альтернативу C++, однако, я его бы не рассматривал. Реальное преимущество на сейчас у него по сравнению с C++ и хорошей дисциплиной управления памятью отсутствует начисто; тут лучше смотреть на D, чем на Go, если вообще не на Java/C#/Scala/etc.

І нормального синхронного обміну даними.

Всё, дальше можно не продолжать. Если кто-то в принципе не представляет себе ситуации, когда вместо “нормального синхронного обмена данными” идут непредсказуемые данные, потому что это заложено в протокол, а большинство портов вместо прямого UART проброшена через разнообразные удлинители, включая IPMI и TCP транспорты... то ему просто надо вылезти из песочницы.

Результат: глюки обміну по UART.

Это никак не результат “абстрактных базовых классов”. Разве что результат ASIO, но я его не знаю и ругать не буду.

А Вам в ответ не понравилась моя фамилия.

Вы походя оскорбили пол-Европы, сравнив с рабами, на основании своих высосанных непонятно из чего рассуждений, а теперь рассказываете про Китай и «не понравилась фамилия»?

Поэтому смысла вести дискуссию как бы нет.

Да, согласен. С тем, кто меняет позицию принципиально на каждом сообщении и не помнит, что сказал раньше — дискуссия невозможна просто технически.