Комментарии 52
У меня все сильнее ощущение что все эти статьи из другого мира. Читаешь, совершенствуешься, сомневаешься, потом приходишь в крупную companyname а там дикие дилетанты за дикие бюджеты на коленке какими то дикими костылями код в продакшен хреначат в дикие сроки.
В большинстве фирм где я работал действительно большая часть народа просто «хреначила в продакшен». Но при этом всегда было как минимум несколько человек(а местами и целые отделы), которые как раз таки занимались архитектурой, концептами, оптимизацией и другими подобными вещами. И да, они не всегда получали больше денег или как минимум получали не сильно больше. Но «хреначить в продакшен» им было не надо.
И тут уже каждый может решать за себя чем из вышеупомянутого он лично хочет заниматься.
И тут уже каждый может решать за себя чем из вышеупомянутого он лично хочет заниматься.
«Хранечинье в продакшен» я давно готов пережить. Я не готов пережить когда перед этим «занимались архитектурой, концептами, оптимизацией и другими подобными вещами», причем годами, а на выходе все равно полная хрень, да и базируется все это часто на таком легаси что уж ей богу переписать снуля дешевле, но отделы которые должны этим заниматься тоже годами мучаются и рожают еще более веселую хрень.
Я правда верю, что где то есть те самые люди, которые прям разработчики, умные, компетентные, я их иногда даже встречаю то тут то там, но такое ощущение что они как динозавры, потому что если посмотреть на отдел крупной компании — боже что за жесть.
Я правда верю, что где то есть те самые люди, которые прям разработчики, умные, компетентные, я их иногда даже встречаю то тут то там, но такое ощущение что они как динозавры, потому что если посмотреть на отдел крупной компании — боже что за жесть.
To, что кто-то занимается «архитектурой, концептами, оптимизацией», само по себе конечно не гарантирует что на выходе не будет полной хрени.
Но на мой взгляд если этим вообще никто не занимается, то в более-менее крупном проекте у вас стопроцентно на выходе будет полная хрень.
И если этим занимается кто-то, кто не обладает необходимой для этого квалификацией, то тоже редко получается что-то хорошее. И на мой взгляд те самые computer science вполне себе полезно знатъ если хочешь заниматься такими вещами.
Но на мой взгляд если этим вообще никто не занимается, то в более-менее крупном проекте у вас стопроцентно на выходе будет полная хрень.
И если этим занимается кто-то, кто не обладает необходимой для этого квалификацией, то тоже редко получается что-то хорошее. И на мой взгляд те самые computer science вполне себе полезно знатъ если хочешь заниматься такими вещами.
Потому, что жизнь не учебник логики. Люди деньги зарабатывают в первую очередь ибо кушать хочется, а все остальное по обстоятельствам.
Ну почему дилетанты, продать хрень за "дикие бюджеты" — это вам не это. Это ж фактически самые дорогие специалисты получаются
Если не понимать, хотя-бы на подсознании, теорию - то любое программирование будет выглядеть «хренченьем в энтерпрайз». Один сделал так, другой - иначе. У первого тормозит, не масштабируется, и хрен фичу впишешь. У другого - все ништяк. Без теории это будет выглядеть как «второму просто повезло». С теорией (в самом широком смысле) - можно понять что было на входе, и почему у второго получилось.
А я не спорю, вот только судя по тенденции доля понимающих снижается с ужасающей скоростью и чем восточнее тем хуже.
Это нормально и это происходит или происходило не только в ИТ.
То есть в любой отрасли/направлении у вас сначала есть небольшое количество профессионалов, которые полностью разбираются во всех аспектах и можно сказать создают эту отрасль с нуля. Потом отрась начинает расти, аспектов становится больше, в неё приходит больше людей. В какой-то момент разбираться во всём уже невозможно и люди начинают специализироваться. Потом размер становится настолько большим что профессионалов начинает нехватать и происходит разделение на «мастеров» и «подмастерьев».
Если бы раньше был интернет и форумы, то можно было бы почитать как на эту тему ругались какие-нибудь электротехники или машиностроители. Но в принципе это можно увидеть и в том или ином художественном произведении :)
То есть в любой отрасли/направлении у вас сначала есть небольшое количество профессионалов, которые полностью разбираются во всех аспектах и можно сказать создают эту отрасль с нуля. Потом отрась начинает расти, аспектов становится больше, в неё приходит больше людей. В какой-то момент разбираться во всём уже невозможно и люди начинают специализироваться. Потом размер становится настолько большим что профессионалов начинает нехватать и происходит разделение на «мастеров» и «подмастерьев».
Если бы раньше был интернет и форумы, то можно было бы почитать как на эту тему ругались какие-нибудь электротехники или машиностроители. Но в принципе это можно увидеть и в том или ином художественном произведении :)
Все красиво говорите, но я наблюдаю в процессии ужасающее количество людей прикидывающихся «мастерами и подмастерьями», особенно «бородатых дядь», на высоких позициях (вплоть до CTO) которых не то что в тимлиды, в джуны я бы взять постеснялся. Ни о какой специализации тут речи не идет, банальные лень, обман, мимикрия, халтура итд
ЗЫ И еще раз, в конце концов, я за то чтобы каждый (!) просто делал свою работу.
ЗЫ И еще раз, в конце концов, я за то чтобы каждый (!) просто делал свою работу.
> Однако если наш продукт используется миллионами конечных пользователей, то нам всё равно необходимо писать высокооптимизированный код.
Я уже хочу в эту параллельную вселенную.
> Проще всего начинать с Python и JavaScript. Но если вы начнёте с языка C, то это даст вам больше преимуществ.
Стоило только сразу сказать, чем и в каком объеме придётся заплатить за эти преимущества.
Я уже хочу в эту параллельную вселенную.
> Проще всего начинать с Python и JavaScript. Но если вы начнёте с языка C, то это даст вам больше преимуществ.
Стоило только сразу сказать, чем и в каком объеме придётся заплатить за эти преимущества.
Си же очень простой язык. Изучается за несколько недель.
Ну а если человек в школе Паскаль учил, то может считать, что Си он знает с точностью до некоторых отличий в синтаксисе.
Проблема в том что «знать синтаксис языка программирования» это на мой взгляд не то же самое что «знать язык программирования».
И если кто-то «в школе Паскаль учил», то это совсем не означает что он знает Паскаль и уж тем более Си.
И если кто-то «в школе Паскаль учил», то это совсем не означает что он знает Паскаль и уж тем более Си.
Проблема в том что «знать синтаксис языка программирования» это на мой взгляд не то же самое что «знать язык программирования».Поспорю. Для компилируемого языка, синтаксис — это практически сам язык и есть. Другое дело, что знать синтаксис языка и/или сам язык, совсем не значит уметь программировать.
Те же джава и шарп вполне себе компилируемые языки. Но они имеют достаточное количество "подводных камней" и я вам гарантирую что зная только синтаксис вы в них далеко не уедете. То есть на мой взгляд чтобы претендовать на знание языка кроме просто самого синтаксиса надо знать и другие вещи. Тот же async/await в шарпе это немного больше чем просто синтаксис.
П.С. И кстати а почему вдруг именно компилируемые языки? Ну то есть почему именно это важно в данном контексте?
Имелись ввиду языки без толстого рантайма. В данном контексте имелись ввиду С и Паскаль, а не, например, Питон. Очевидно, что джава и шарп, в данном контексте, ближе к питону. И чтобы ими эффективно пользоваться надо иметь хорошее понимание JVM и .NET.
Но вот, именно понимание async/await относится скорее к общему «умению программировать», чем к «знанию языка».
Но вот, именно понимание async/await относится скорее к общему «умению программировать», чем к «знанию языка».
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Да, вы совершенно правы. Но все эти вещи: ООП, акторная модель, лямбда вычисления и т.п. это общие знания по программированию. Каррирование и инкапсуляция имеют более или менее одни и те же свойства во всех языках. Конечно есть и специфические вещи. Особенно богат ими C++. И для него, пожалуй, двух недель не будет достаточно. Но большинство остальных языков просто комбинируют стандартные концепции и знание синтаксиса сразу даёт подсказку, какие концепции тут реализованы.
В том же C, например, в стандарте языка описаны десятки, а то и сотни случаев вызывающих undefined behavior, и многие из них совсем не очевидны (типа того же aliasing'а). И не зная, не понимая и не умея отлавливать их, вы никогда не сможете писать корректный и надежный код на Си.Тут вы излишне категоричны. Можно писать надёжный и корректный код на С, просто следуя правилам «как надо». Конечно, даже в этом случае может встретиться редкий UB, но он проявит себя, либо падением, либо при смене платформы/компилятора и будет безжалостно изничтожен.
НЛО прилетело и опубликовало эту надпись здесь
У всех кого я видел получалось нормально. Продукты отгружались клиентам вовремя и достойного качества.Можно писать надёжный и корректный код на С, просто следуя правилам «как надо».Только вот почему-то мало у кого получается.
Если он ловится падением (которое, тем более, вам удалось связать с данным конкретным UB), то вам жутко повезлоНе совсем понимаю, в чём тут везение. Если ошибка повторяется, то её можно и нужно в конце концов связать с тем или иным феноменом.
А иногда их оказывается достаточно много для того, чтобы компилятор не менялся никогда. Или оптимизации не включались, потому что тогда этот дурацкий компилятор все портит.Тоже само по себе не страшно, если не тянет за собой техдолга или ещё каких-то проблем.
НЛО прилетело и опубликовало эту надпись здесь
Достаточно посмотреть на то, как регулярно находятся всевозможные CVE'шки и CWE'шки в даже казалось бы даже старых и проверенных продуктах. И в подавляющем большинстве они написаны именно на C и C++, да.Переполнения стека, переполнения буфферов, use after free и т.п. проблемы обращения с памятью являются наиболее распространёнными причинами уязвимостей. UB там редко когда причём.
Везение во-первых в том, что, как уже… причем в совершенно другом месте. UB оно такое, да…Всё что вы так ярко живописали, у нас — ежедневная рутина безо всяких UB, простите за нескромность. Принты меняют исполнение через увеличение секции кода, изменение времени исполнения или изменение расположения в кэше каких-то фрагментов (например, циклов). Безо всяких, повторюсь, UB.
В том-то и дело, что это влечет за собой непосредственно активное накопление техдолгаТехдолг — это когда код плохой. Виноват в этом не компилятор, а кривые руки
сколько бы вы не привязывались к одной и той же версии компилятора, рано или поздно (а очень часто так и вообще внезапно) может настать момент, когда всё-таки придется это сделать по разным причинамТеоретически, я с вами согласен, но практически, я использую gcc 4.6 с 2012-го года. За последнее время имел ровно одну проблему с frr. Там структура была смешно определена в заголовке с константным массивом нулевой длины на конце, а в коде разные экземпляры этой структуры имели разную реальную длину массива. Причём проблема была даже не с компилятором, а с линковщиком. Причём, не всегда, а только если сами элементы массива не легли сразу за структурой. Легко решилась заменой массива нулевой длины на указатель. А потом и апстрим это дело пропатчил
НЛО прилетело и опубликовало эту надпись здесь
Ну согласно стандарту C, use-after-free вполне себе относится к UB. Ровно как и invalid pointer operations типа выхода за границы буферов.Ну, э-э-э, как бы… Для того, чтобы проверять размеры пользовательских данных, не надо знать, что чтение за границами выделенной памяти — UB. То есть, вы конечно, в очередной раз правы, но все эти вещи происходят не оттого, что люди не знают, что это UB и делают так, в надежде, что вывезет как-нибудь.
Следовательно, всё изложенное Вами в следующем абзаце имеет место быть и напрямую влияет, выстрелит это UB или нет.
У всех кого я видел получалось нормально. Продукты отгружались клиентам вовремя и достойного качества.
Вопрос в том, сколько времени и трудов на это потребуется. Перед выпуском программы в свет, она должна пройти несколько раундов QC: один встроен в программиста, другие — у отдела тестирования. И если перед ними стоит хороший QC внутри компилятора, то нагрузка на программиста и отдел тестирования сильно меньше.
Это можно легко проверить, написав сложную бизнес-логику на Haskell и на Python. Да, результат будет работать одинаково хорошо и точно, но усталость будет несоизмерима.
>Мы сейчас активно набираем людей в проект с C++17 и Embedded Linux,
если не секрет, что за embedded продукт вы делаете?
C++ embedded довольно большую систему приходилось делать/участвовать,
типа одних процессоров разного типа за 100, код довольно тяжеловесный получился в результате, до сих пор думаю, а не лучше ли на C было с самого начала все делать
ps
про важность семантики vs синтаксис вы все правильно пишите конечно
если не секрет, что за embedded продукт вы делаете?
C++ embedded довольно большую систему приходилось делать/участвовать,
типа одних процессоров разного типа за 100, код довольно тяжеловесный получился в результате, до сих пор думаю, а не лучше ли на C было с самого начала все делать
ps
про важность семантики vs синтаксис вы все правильно пишите конечно
НЛО прилетело и опубликовало эту надпись здесь
ну понятно, когда-то сделал с нуля embedded rmon1 probe (все 9 групп) плюс snmp, ip, arp и все что связано, чем только не приходилось заниматься :),
проект после которого к C++ несколько охладел был этот (RS):
www.ven-tel.com/docs/CN-4200_Product-Brochure.pdf
вроде как product retired уже, дело старое лет 10 назад, не уверен, что преимущества C++ показал, хотя люди были сильные, код в общем косметически красивый, но очень громоздкий, и тяжелый в отладке, примерно так, как обычно строго imho
проект после которого к C++ несколько охладел был этот (RS):
www.ven-tel.com/docs/CN-4200_Product-Brochure.pdf
вроде как product retired уже, дело старое лет 10 назад, не уверен, что преимущества C++ показал, хотя люди были сильные, код в общем косметически красивый, но очень громоздкий, и тяжелый в отладке, примерно так, как обычно строго imho
Ну какая же это проблема? Это хорошо, что так. Плохо было бы если бы научиться программировать было бы так же легко, как об этом заявляют в рекламе платных курсов. Тогда бы все курьеры переквалифицировались в девелоперы и сеньёрам помидорам платили бы от 60 до 80 тысяч рублей.
А по поводу что такое знать язык, конечно знание синтаксиса это самый минимум, но остальные знания, такие как алгоритмы и структуры данных, а также грамотная организация кода нарабатываются независимо от языка.
Надо было написать не Си, а C++.
После метапрограммирования на шаблонах в C++ мне уже мало какие вещи в IT-индустрии кажутся сложными.
После метапрограммирования на шаблонах в C++ мне уже мало какие вещи в IT-индустрии кажутся сложными.
НЛО прилетело и опубликовало эту надпись здесь
Но контекст же следующий:
Проще всего начинать с Python и JavaScript. Но если вы начнёте с языка C, то это даст вам больше преимуществ.
У Python и особенно JavaScript столько всяких UB, больше чем звёзд на небе. Однако же люди на скорую руку осваивают эти языки и даже идут как-то работать. Я же и написал, что освоить си на таком уровне ничуть не сложнее питона или джаваскрипт, а наверное даже проще. (правда работу найти будет сложновато) А знать прям все-все подводные камни, это уже не начальный уровень, а близко к вершине мастерства.
Такое происходит в принципе в любой области. Например, можно работать администратором в аптеке, делать таблички для закупки лекарств, и формально ты тоже работаешь в «фарме», но для того, чтобы выдавать лекарства людям, тебе нужно образование.
Ну, или в строительстве: можно быть архитектором, а можно быть разнорабочим на стройке.
И, вот, такие флеймворные статьи говорят о том, что нужно учиться, но как это интерпретировать кодерам, которые и так хорошо себя чувствуют и ощущают спрос на свою работу на рынке? Не каждая медсестра хочет стать доктором, но что-то не видно призывов к мед.персоналу идти иучиться, потому что это светит чем-то большим. Оно часто и не надо.
Так и в IT: «Учитесь CS, будете нечто большим!», а надо ли оно? Кто захочет, сам выучится и поднимет левел, но, ведь, есть те, кому это и не надо. Пишет кто-то костыльные вспомогательные скрипты на работе у себя, или просто кодит под руководством software architect-ора, и ему хорошо. Пришёл в 10 на работу, заглянул в ТЗ, выдал свою порцию строчек кода, передал тестировщикам, и ушёл в пять домой играть с детьми и вырезать фигурки из дерева, и готово.
Такое ощущение, что кодеры — это плохо. Это просто есть и всё. Не каждый водитель камаза хочет стать гонщиком «Формулы-1».
Ну, или в строительстве: можно быть архитектором, а можно быть разнорабочим на стройке.
И, вот, такие флеймворные статьи говорят о том, что нужно учиться, но как это интерпретировать кодерам, которые и так хорошо себя чувствуют и ощущают спрос на свою работу на рынке? Не каждая медсестра хочет стать доктором, но что-то не видно призывов к мед.персоналу идти иучиться, потому что это светит чем-то большим. Оно часто и не надо.
Так и в IT: «Учитесь CS, будете нечто большим!», а надо ли оно? Кто захочет, сам выучится и поднимет левел, но, ведь, есть те, кому это и не надо. Пишет кто-то костыльные вспомогательные скрипты на работе у себя, или просто кодит под руководством software architect-ора, и ему хорошо. Пришёл в 10 на работу, заглянул в ТЗ, выдал свою порцию строчек кода, передал тестировщикам, и ушёл в пять домой играть с детьми и вырезать фигурки из дерева, и готово.
Такое ощущение, что кодеры — это плохо. Это просто есть и всё. Не каждый водитель камаза хочет стать гонщиком «Формулы-1».
Статья за всё хорошее против всего плохого?
Понимаю, что перевод, перевод годный.
занудство раз
По мнению большинства, слово «кодинг» имеет то же значение, что и слово «программирование». Однако нужно объяснить неочевидный факт.
Это не неочевидный факт, а употребление слов, к тому же нераспространенное (противоречащее мнению большинства). И "кодинг" и "программирование" действительно не так уж далеки по значению (может, на языке оригинала все иначе). То ли дело, например, "программирование/кодинг" и "разработка".
Заключение в статье не соответствует тезисам из содержания.
занудство два
Кодер может писать код на языке высокого уровня для компилятора или интерпретатора.
Программист может создавать полнофункциональные программные продукты при помощи минимизации ошибок.
чтобы стать программистом, необходимо изучить теории computer science
Не понял. На языках высокого уровня нельзя писать полнофункциональное ПО? Можно. Скажем, нужно ли знать, что такое хэш-таблицы и как устроено управление памятью, чтобы пользоваться, словарями в Python? Нет.
На всякий случай: первыми языками у меня были Pascal, C, C++. "Computer Science" изучал и понимаю ее ценность.
Теории могут улучшить ваши навыки решения задач
Ни больше ни меньше
ИМХО статья в принципе верная, но слишком поверхностная. Читаем:
Можно подумать, что нужно знать все напряжения в вольтах которые выдает БП для питания CPU. Бред. Хорошему программисту это знать не нужно. Если только у него возникнет проблема ремонта домашнего ПК.
Общие слова. Основа, прежде всего, в доказательстве правильности алгоритма, в теоретической оценке сложности для наихудшего случая. Если кодер не знает почему не надо употреблять сортировку пузырьком, то он действительно «кодер» в том смысле, какой в статье.
Много слов про оптимизацию. Но оптимизация может быть не только по времени выполнения, но и по памяти. И часто одна вредит другой. Автор не хочет видеть такие «мелочи».
Кодер может писать код на языке высокого уровня для компилятора или интерпретатора. Чтобы писать код, вам не нужно знать, как работает компьютер или его отдельные части. С другой стороны, программист тоже пишет код, но понимает и внутреннее устройство компьютера.
Можно подумать, что нужно знать все напряжения в вольтах которые выдает БП для питания CPU. Бред. Хорошему программисту это знать не нужно. Если только у него возникнет проблема ремонта домашнего ПК.
Основы computer science состоят из таких тем, как структуры данных, алгоритмы, принципы работы сетей, дискретная математика, искусственный интеллект, компьютерная графика, шаблоны проектирования и человеко-машинное взаимодействие.
Общие слова. Основа, прежде всего, в доказательстве правильности алгоритма, в теоретической оценке сложности для наихудшего случая. Если кодер не знает почему не надо употреблять сортировку пузырьком, то он действительно «кодер» в том смысле, какой в статье.
Много слов про оптимизацию. Но оптимизация может быть не только по времени выполнения, но и по памяти. И часто одна вредит другой. Автор не хочет видеть такие «мелочи».
Это все, конечно, красиво сказано. Но, как насчет вопросов по концепции программированию? Что могут сказать «теории Computer Science» относительно модульного программирования? Верно! – Ничего! Или, в лучшем случае, ограничится общими словами.
Поэтому, в собственном, реальном проекте, скажем, на С / С++, нужно самому изобретать велосипед модульного и итерационного программирования. Или делать монолиты, как в большинстве опенсорса, которые еще переварить надо из-за их монструозности.
В общем, как реклама для студентов сойдет, но практическая ценность статьи – минимальна…
Поэтому, в собственном, реальном проекте, скажем, на С / С++, нужно самому изобретать велосипед модульного и итерационного программирования. Или делать монолиты, как в большинстве опенсорса, которые еще переварить надо из-за их монструозности.
В общем, как реклама для студентов сойдет, но практическая ценность статьи – минимальна…
А, разве написание кода это не программирование? Язык это же просто инструмент. Код пишется не отвлечённо, а для решения задач, которые выполнит программа. Ну типа, знаешь ты синтаксис и что? Пишешь же ты конкретно инструкции для выполнения программы. А, так конечно, computer science, (информатику по-русски) знать это must have, я согласен.
А где можно выучить теорию онлайн?
Можно например курс HarvardX CS50 посмотреть. Есть в русской озвучке habr.com/ru/company/vertdider/blog/403823
upd: забавно получилось что и комментарий это 50
upd: забавно получилось что и комментарий это 50
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему каждому разработчику сначала стоит изучить теории Computer Science