У меня есть чуть более показательный пример: пытался я по дуолинго японский выучить) Ну вот за 3 месяца (3 месяца, Карл) - он мне рассказал только про катакану, хирагану и примерно 50 слов.
Я забил на дуолинго и нанял репетитора. Я за первый день узнал о японской грамматике больше, чем за всё это время в дуолинго. Мне дали материалы с систематической информацией по языку, управжнения для развития письма и рекомендации, какие темы стоит ковырять новичку, а какие оставить на потом.
Кароч, я получил концентрат из которого я просто за неделю узнал больше, чем за несколько месяцев в дуолинго.
P.S. Итог правда один, я решил, что "чё-т сложновато" и бросил)
Ну, так оно в принципе и есть) У нас английский был со второго класса, и я до 11 класса по сути выучил околонихрена) Не мог даже простенькие тексты без словаря читать, не говоря уже том, чтобы хоть что-то связно говорить.
Не могу сказать, что прям вина учителей, просто до тех пор пока я для себя серьезно не поставил цель выучить язык и не начал заниматься по два часа в день каждый день, без выходных, и принудительно общаться на нём - нихрена он не учился. Ни в каком формате.
Duolingo бесполезен более чем полностью. Я за 3 месяца очных групповых курсов английского, выучил примерно в 15 раз больше, чем за 2 года этой балалайки)
Сделаю ремарку в начале: я не управленец и больших процессов "сверху" не видел. Расскажу как мне это всё видится "снизу".
Всё это действительно очень правильно, но я не вижу, чтобы эти идеи имели успех.
Чтобы предоставить бизнесу варианты, ИТ нужно "остановиться и подготовить анализ" - это не всегда тупо возможно в рамках согласованного бюджета. Проще и (политически) безопаснее рассказать о риске без анализа, довести ситуацию до катастрофы и разгрести последствия, чем объяснять бизнесу почему вдруг всё встало, ведь мы "анализируем".
Стоимость и последствия - это иллюзия и гадание на кофейной гуще (для обеих сторон) до следующего противоречия в процессах. Когда цифры в очердной раз не сойдутся - опять будет виновато ИТ.
Описанное в целом невыгодно никому из менеджмента (обеих сторон), кроме тех, кто непосредственно имеет профит от результатов работы бизнеса. Вы пытаетесь заставить людей нести ответственность, зачастую за вещи, которые они (пока что) не понимают. Никто такого не хочет.
Снизу весь "организационный хаос" и "техническое несовершенство" видится мне просто симптомами политической борьбы топ-менеджмента. Многие процессы намеренно построены так как построены - криво косо, с непонятной ответственностью, а иногда и специально для того, чтобы свалить вину на другой отдел в случае чего.
И подразделение ИТ, даже если будет очень стараться, даже если будет давать бизнесу все возможные анализы и варианты - не сможет решить эту проблему. В политических делах определённость, обещания и, упаси господи, ответственность - это враги, с которыми будут бороться.
Да в целом-то понятно, что платить приходится (правда Haskell тихонько хихикает над нами), но просто интересно насколько много. Например, как быстро начнет тупить IDE, сколько памяти будет жрать и как часто глючить.
Насколько вообще будет поддерживаемый этот код, ведь когнитивная нагрузка, чтобы понять что тут имел ввиду автор рефлексии игромно. Принесёт ли это баги в dynamic_cast)
Гораздо интереснее, что там будет в ошибках компиляции и как это будет дружить с IDE. Ну и немножко интересно, сколько этажей мусора будет в отладчике.
В целом, если сейчас даже большой шаблон падает - всё, конечно плохо, но любая ИИ-шка за 5 секунд найдет проблемный параметр, да и глазами это возможно, просто дольше
Мне признаться вообще насрать на задачи, на продукт и прочую корпоративную пое**нь. Конечно, я ей занимаюсь, двигаю таски в джире, и якобы забочусь о качестве продукта) Деньги надо зарабатывать, так что приходится играть в корпоративные игры.
Но на деле мне всегда просто интересно заставить железку делать, что я хочу)
Легко могу потратить неделю на чтение мануала Intel о работе их процессора, не потому что мне хочется сделать производительную фичу, а потому что мне хочется упереться в предел железа) Пощупать его и побенчмаркать.
Или вот хочется мне, чтобы корпоративное говно ставилось одной кнопкой, а не по инструкции на вики. Ну, так я напишу эту кнопку и другим ещё раздам. Не потому, что мне хочется чтобы команда эффективнее тратила время, а потому, что я знаю, что не одного меня бесит этим всем заниматься)
Не, иногда эти бесполезные знания приносят плоды и можно случайно оказаться полезным для продукта, но по опыту - почему-то для какого-то другого продукта в другой компании))
Нет. Компьютер никогда ничего не делает сам. Он не живой. Он не может ночью решить: «Сегодня удалю единственный бэкап БД с боевого сервера. Для разнообразия»
После уже почти 15 лет в IT - не согласен. Чего только не происходит в компьютере...
Ничего прикладного в стандартной библиотеке плюсов не найти. Ну, может только std::filesystem сойдёт за прикладное, всё остальное - просто базовые вещи: контейнеры, генераторы случайный чисел, немного математики.
Но довольно странно сравнивать документацию на язык с документацией на фреймворк (Qt), решающий прикладные задачи.
Плюсы - это язык для велосипедов) Тут всё все пишут сами, потому что... Так повелось)
Cpp Core Guidelines как раз говорит как не надо использовать функции.
Я чего-то не знаю про Core Guidelines? Вроде центральное место, на которое надо ссылаться, когда хочется показать "идиоматичный С++".
По остальному - лучше как-то предметно обсуждать, что вам было непонятно. Я уже 10+ лет на плюсах пишу, для меня ничего лучше cppreference просто не существует, глаз замылен. Я там буквально могу найти всю интересующую меня информацию.
Несмотря на то, что информация в статье в целом неплоха, часть про варианты записи лучше было бы конечно под спойлер убрать. Она занимает добрую треть, а у делу отношения мало имеет :)
Примерно по 30-45 минут.
У меня есть чуть более показательный пример: пытался я по дуолинго японский выучить) Ну вот за 3 месяца (3 месяца, Карл) - он мне рассказал только про катакану, хирагану и примерно 50 слов.
Я забил на дуолинго и нанял репетитора. Я за первый день узнал о японской грамматике больше, чем за всё это время в дуолинго. Мне дали материалы с систематической информацией по языку, управжнения для развития письма и рекомендации, какие темы стоит ковырять новичку, а какие оставить на потом.
Кароч, я получил концентрат из которого я просто за неделю узнал больше, чем за несколько месяцев в дуолинго.
P.S.
Итог правда один, я решил, что "чё-т сложновато" и бросил)
Ну, так оно в принципе и есть) У нас английский был со второго класса, и я до 11 класса по сути выучил околонихрена) Не мог даже простенькие тексты без словаря читать, не говоря уже том, чтобы хоть что-то связно говорить.
Не могу сказать, что прям вина учителей, просто до тех пор пока я для себя серьезно не поставил цель выучить язык и не начал заниматься по два часа в день каждый день, без выходных, и принудительно общаться на нём - нихрена он не учился. Ни в каком формате.
Да вот бы я помнил, это было лет 5 или 6 тому назад) В день закрывал обычно одну "таблетку" (один полноценный урок).
Duolingo бесполезен более чем полностью. Я за 3 месяца очных групповых курсов английского, выучил примерно в 15 раз больше, чем за 2 года этой балалайки)
Сделаю ремарку в начале: я не управленец и больших процессов "сверху" не видел. Расскажу как мне это всё видится "снизу".
Всё это действительно очень правильно, но я не вижу, чтобы эти идеи имели успех.
Чтобы предоставить бизнесу варианты, ИТ нужно "остановиться и подготовить анализ" - это не всегда тупо возможно в рамках согласованного бюджета. Проще и (политически) безопаснее рассказать о риске без анализа, довести ситуацию до катастрофы и разгрести последствия, чем объяснять бизнесу почему вдруг всё встало, ведь мы "анализируем".
Стоимость и последствия - это иллюзия и гадание на кофейной гуще (для обеих сторон) до следующего противоречия в процессах. Когда цифры в очердной раз не сойдутся - опять будет виновато ИТ.
Описанное в целом невыгодно никому из менеджмента (обеих сторон), кроме тех, кто непосредственно имеет профит от результатов работы бизнеса. Вы пытаетесь заставить людей нести ответственность, зачастую за вещи, которые они (пока что) не понимают. Никто такого не хочет.
Снизу весь "организационный хаос" и "техническое несовершенство" видится мне просто симптомами политической борьбы топ-менеджмента. Многие процессы намеренно построены так как построены - криво косо, с непонятной ответственностью, а иногда и специально для того, чтобы свалить вину на другой отдел в случае чего.
И подразделение ИТ, даже если будет очень стараться, даже если будет давать бизнесу все возможные анализы и варианты - не сможет решить эту проблему. В политических делах определённость, обещания и, упаси господи, ответственность - это враги, с которыми будут бороться.
Да в целом-то понятно, что платить приходится (правда Haskell тихонько хихикает над нами), но просто интересно насколько много. Например, как быстро начнет тупить IDE, сколько памяти будет жрать и как часто глючить.
Насколько вообще будет поддерживаемый этот код, ведь когнитивная нагрузка, чтобы понять что тут имел ввиду автор рефлексии игромно. Принесёт ли это баги в dynamic_cast)
Ладно, надо тестировать, спасибо за статью
Гораздо интереснее, что там будет в ошибках компиляции и как это будет дружить с IDE. Ну и немножко интересно, сколько этажей мусора будет в отладчике.
В целом, если сейчас даже большой шаблон падает - всё, конечно плохо, но любая ИИ-шка за 5 секунд найдет проблемный параметр, да и глазами это возможно, просто дольше
Azure Devops)
Вы так пишете, будто онанизм это что-то плохое)
Мне признаться вообще насрать на задачи, на продукт и прочую корпоративную пое**нь. Конечно, я ей занимаюсь, двигаю таски в джире, и якобы забочусь о качестве продукта) Деньги надо зарабатывать, так что приходится играть в корпоративные игры.
Но на деле мне всегда просто интересно заставить железку делать, что я хочу)
Легко могу потратить неделю на чтение мануала Intel о работе их процессора, не потому что мне хочется сделать производительную фичу, а потому что мне хочется упереться в предел железа) Пощупать его и побенчмаркать.
Или вот хочется мне, чтобы корпоративное говно ставилось одной кнопкой, а не по инструкции на вики. Ну, так я напишу эту кнопку и другим ещё раздам. Не потому, что мне хочется чтобы команда эффективнее тратила время, а потому, что я знаю, что не одного меня бесит этим всем заниматься)
Не, иногда эти бесполезные знания приносят плоды и можно случайно оказаться полезным для продукта, но по опыту - почему-то для какого-то другого продукта в другой компании))
После уже почти 15 лет в IT - не согласен. Чего только не происходит в компьютере...
Я не понимаю, в чем проблема положить болт на это? У меня вообще рабочий чат улетает в mute до следующего рабочего дня
Да какая разница? Бизнес увидел риск, бизнес решил: "нафиг надо". Правительство извинилось, но риск остался
Ответов обычно два:
Это есть в boost
Это есть в какой-то библиотеке
Ничего прикладного в стандартной библиотеке плюсов не найти. Ну, может только std::filesystem сойдёт за прикладное, всё остальное - просто базовые вещи: контейнеры, генераторы случайный чисел, немного математики.
Но довольно странно сравнивать документацию на язык с документацией на фреймворк (Qt), решающий прикладные задачи.
Плюсы - это язык для велосипедов) Тут всё все пишут сами, потому что... Так повелось)
Я чего-то не знаю про Core Guidelines? Вроде центральное место, на которое надо ссылаться, когда хочется показать "идиоматичный С++".
По остальному - лучше как-то предметно обсуждать, что вам было непонятно. Я уже 10+ лет на плюсах пишу, для меня ничего лучше cppreference просто не существует, глаз замылен. Я там буквально могу найти всю интересующую меня информацию.
Не знаю, у меня пока ни разу проблем не возникало с пониманием нафига эта функция нужна) Ну, может только для std::launder пришлось мозги напрягать)
Впрочем, с эрой появления LLM это уже всё не имеет значения)
Впрочем, если нужен ультимативный ресурс о том "как правильно использовать функции" - и такой есть. Cpp Core Guidelines.
Опыт наблюдений показывает, что даже если что-то дают за деньги - ты всё равно товар.
Я как буддийский монах, предпочитаю затерпеть) Просто повод молчаливо подумать про себя: "молодец, красавчик")
Спасибо за статью :)
Несмотря на то, что информация в статье в целом неплоха, часть про варианты записи лучше было бы конечно под спойлер убрать. Она занимает добрую треть, а у делу отношения мало имеет :)
Вы открывали cppreference? Этот ресурс по качеству документации даст прикурить практически всем популярным языкам)