(на правах грустного юмора) Почему мне не быть хорошим программистом несмотря на 15 лет опыта:
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Мне интересно, как написан код библиотек\фреймворков и т.д., но мне всё равно, как устроен компьютер (знаю на уровне школьника и ладно)
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом.
Я не хочу потерять день на решение проблемы мучаясь дебагом, которое способен мгновенно выдать интернет\коллега\мануал.
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Решит коллега. Поменяю саму задачу или способ решения.
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.
Нет, ведь самое трудное еще впереди. Или просто еще 10 таких же проблем (тикетов)
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.
Когда мне было 20 — все давалось легко и быстро. Теперь я точно знаю, что мне не понять, например, криптографию и другую высшую математику, и просто туда не лезу.
Если вы ленитесь думать и вы считаете сконцентрированное размышление скучной рутинной обязанностью, вам не стать успешным программистом.
Потому что, шьёрт побьери, это рутина! Это выматывает! Это бессонные ночи и литры кофе! И вообще, очевидное и изящное решение, как известно, приходит во сне неожиданно, само.
Изучая что-то новое, очень часто мы чувствуем что наших знаний и опыта недостаточно для того, чтобы иметь собственное мнение. Выступить с инициативой, сделать или сказать что-то неправильно кажется очень рискованным.
От нас требуется писать быстро и без ошибок, у нас нет времени на рефакторинг и глобальные переделки, нет мотивации среди нескольких неплохих решений долго выбирать наилучшее. ***к ***к и в продакшн!
Поэтому важно работать в команде. За годы работы на почти каждую проблему сразу всплывает собственный типичный подход «я всегда так делал», и уже не видно альтернатив.
Если воспринимать конечную цель программирования как нахождение верного решения, а не спектра возможных решений, вам ни за что не стать успешным программистом.
Когда-то я доводил код до формы, устраивающей меня. Сначала писал простыню говнокода, которая просто работает, а потом рефакторил, придавая универсальность и гибкость, в попытках написать идеальный код… Теперь я останавливаюсь на простыне, которая хотя бы не плоха — идеальный код никому не нужен, да и тот код, что я нахожу красивым, врядли *всем* покажется тоже красивым.
Если вы пренебрегаете деталями и упускаете из вида мелочи, вам ни за что не стать успешным программистом.
Я крайне нетерпелив и невнимателен. Тот код, который еще мной же не пересматривался и не правился, набит ошибками «нулевого указателя» и «лишней единицы». Я это знаю, а потому не проверяю, как учитель орфографию учеников, а пишу юнит-тесты. Только тесты могут выявить эти глупые ошибки из невнимательности. Я не стараюсь.
А потому, у меня много опыта и я не был и не буду хорошим программистом :D
Ты смотри, что творится… Толстый, жирный, зеленый — какая прелесть... Тема крайне холиварная, древняя, как окаменелость мамонта.
И как-то в ходе дискуссий забыли про определения. Надо исправлять. Итак: Тип данных — множество значений и операций над ними. Т.е. кучу данных мы разбиваем на группы (числа, строки, структуры) и определяем операции для них. Именно благодаря типу мы знаем, что вот эти 4 байта — это дробное (float) число, а не целое (int), и без указания типа эти данные для нас бессмысленны, а операции — не определены (1+2 это 3 или 12 или 10.0?). Заметьте, включение в данное определение операций также важно, поскольку для каждого типа свои операции (могут совпадать, могут не совпадать). Т.е. вообще без типов мы не сможем написать даже hello world (да, даже в машинных кодах)
Далее — типизация может быть статическая (типы заданы при обьявлении и более не меняются) и динамическая (тип определяется при присваивании). Внимание, не более того! В этом определении нет даже понятий «компиляция», «рантайм», а потому так много ошибок в суждениях тех, кто здесь видит эти понятия.
Для размытия границ используется приём вывода типов (неявное, но все же однозначное указание типа), и зачастую не очень очевидное, что и сбивает многих с толку.
Далее, типизация бывает сильная (строгая) и слабая, различие их в том, возможно ли (неявное) приведение одного типа к другому. Тоже скользский момент, потому что часто свойство сильной\слабой относят к статической\динамической, а также часто расходятся во мнениях, приведение типов невозможно вообще или только неявное приведение.
И еще одна характеристика системы типов — способ разделения на типы — тоже подпадает под раздачу в термины «статическая\динамическая», хотя и сильно зависит от первых двух характеристик и варьируется несколькими факторами. Это ООП\ОП\прототипная\утиная типизация.
Таким образом, заданы важные вопросы:
Значение (переменная\поле\обьект...) как правильно интерпретировать? (число, строка или что-то еще?)
Как с этим работать? (складывать, присваивать, хранить, взаимодействовать с другими данными)
Относится ли значение к одной группе? (можно ли одно положить в другое?)
В какой момент времени мы можем это знать? А также, сколько информации останется в момент выполнения? (имеется ввиду возможность получение описания значения, т.е. это зона рефлексии\шаблонов\генериков)
Возможно ли в принципе, и, если да, то как корректно значение одного типа присвоить другому, или использовать одно вместо другого? (присваивание, наследование, расширение)
Для динамической типизации — есть ли возможность изменение структуры сложного значения (такое, как добавление новых полей к обьектам)
Таким образом, у места-значения (переменной\поля\...) есть 3 базовых свойства:
имя (идентификатор, адрес в памяти)
тип (формат, структура, размер, простое\сложное, набор операций — как встроенных в язык, так и программно, т.е. методы обьекта)
текущее значение (возможно константное)
и эти свойства, как, впрочем, и все определения выше, универсальны для любого языка с любой типизацией; без этих определений нет смысла.
и самое важное: в этих определениях нет указаний ни на внутреннее содержание (тип — это не только «физическое» разделение число-строка-структура-..., оно может быть и более, и менее строгим, например, «значение конечного множества (любого из)», «положительные целые четные числа от 1 до 100» ), ни на форму описания (в статье «церемонии»)
более того, строгость требования (обязательно указывать тип\может быть выведен\будет известен в момент выполнения) также вариативна, и удобна от задачи к задаче.
еще более того, лично у меня не отваливаются руки «лишний раз» написать типы, а кодогенерация и современные языки позволяют уменьшить количество бойлерплейта — не нужно ругать всю типизацию из-за неудачного применения в конкретных языках.
и вот за что смело можно минусовать — удивительно, но проектировать (писать частично рабочий код и смотреть, какие решения идут удачно, какие нет) лично мне неожиданно удобнее на таком простигосподи языке с такой же х… орошей статической типизацией и бойлерплейтом, как java, а не на чудных kotlin-scala-python-ruby и т.д.
Между прочим, человек сначала замок снял, а потом его разобрал, чтобы посмотреть, как устроено и какой же был код — чтобы аккуратно поставить обратно и закрыть.
> Это ты сам придумал или где-то прочитал?
вспомнил, что когда-то давно придумал читал
>Критика goto
вот именно
> Похоже, что отлаживать спагетти-код никогда не приходилось.
Хех, какой только говнокод не приходилось отлаживать… И не только отлаживать (отладчиками), но и, простигосподи, пользоваться print\write\alert
break\continue с метками и так сильно критиковали, мол, это то же самое, что измененный goto label; очевидно, ограничение потому и наложено, чтобы не использовали управляющую конструкцию для того, для чего она не предназначена.
для сравнения:
в бейсиках 80х годов каждый оператор обязан был иметь числовую метку (не совсем так, можно было группировать операторы) и называлась метка номером строки, а условные операторы не могли быть сложными (не было понятия {блок}), и потому постоянно приходилось использовать goto: в какой-то момент ненависть к такому принуждению визуально прыгать по частям кода зашкалила и оператор выдрали с корнем из всех языков
> assert может принимать 2 аргумента
при том, что assert может не работать совсем — все зависит от флагов запуска.
> strictfp
лучше не использовать float, а использовать double, а еще лучше — использовать StrictMath
> При вызове vararg-метода без аргументов всё равно создаётся пустой массив
что очень удобно в циклах, ну и логично, если помнить, что vararg — это всего лишь syntax sugar
> Выражение switch-case не поддерживает java.lang.Class
А для чего это может понадобиться? Нет ли специфичного запашка?
>
Нет, остальное вообще, извините, детсад, комментарий аж застрял.
использование меток тянется еще со времен Си, причем не только в continue, но и break, можно «прыгать» как вперед, так и назад, ограничение одно: метка не должна выходить за пределы цикла.
удобная штука, когда надо прервать из вложенного цикла во внешний.
з.ы. но стоит отметить, что эта фича используется столь редко, что давно считается дурным тоном — т.е. если вам она понадобилась, то стоит присмотреться к коду, нельзя ли его написать иначе и лучше? (а в некоторых статических анализаторах, например, встроенном в Jetbrains Idea, есть даже предупреждения об использовании break,continue, меток и вложенных циклов)
если она хочет попробовать, то пусть заплатит за свою порцию.
Все именнно так с их точки зрения.
Хотелки и далее идут — например, если я купил музыку, чтобы слушать на мобилке, то чтобы ее ж послушать на компьютере, я должен купить ее отдельно, еще раз. (источник инфы не помню, извините)
*грустно* мне кажется, Яндекс в будущее смотрит. Ты ищешь слово (то же «ъуъ»), а заботливая ПС тебе впаривает предлагает товары и услуги, ассоциированные с этим образом, а справочная и энциклопедическая информация — на 10ой странице мелким шрифтом, и так будут делать все.
Мне интересно, как написан код библиотек\фреймворков и т.д., но мне всё равно, как устроен компьютер (знаю на уровне школьника и ладно)
Я не хочу потерять день на решение проблемы мучаясь дебагом, которое способен мгновенно выдать интернет\коллега\мануал.
Решит коллега. Поменяю саму задачу или способ решения.
Нет, ведь самое трудное еще впереди. Или просто еще 10 таких же проблем (тикетов)
Когда мне было 20 — все давалось легко и быстро. Теперь я точно знаю, что мне не понять, например, криптографию и другую высшую математику, и просто туда не лезу.
Потому что, шьёрт побьери, это рутина! Это выматывает! Это бессонные ночи и литры кофе! И вообще, очевидное и изящное решение, как известно, приходит
во сненеожиданно, само.От нас требуется писать быстро и без ошибок, у нас нет времени на рефакторинг и глобальные переделки, нет мотивации среди нескольких неплохих решений долго выбирать наилучшее. ***к ***к и в продакшн!
Поэтому важно работать в команде. За годы работы на почти каждую проблему сразу всплывает собственный типичный подход «я всегда так делал», и уже не видно альтернатив.
Когда-то я доводил код до формы, устраивающей меня. Сначала писал простыню говнокода, которая просто работает, а потом рефакторил, придавая универсальность и гибкость, в попытках написать идеальный код… Теперь я останавливаюсь на простыне, которая хотя бы не плоха — идеальный код никому не нужен, да и тот код, что я нахожу красивым, врядли *всем* покажется тоже красивым.
Я крайне нетерпелив и невнимателен. Тот код, который еще мной же не пересматривался и не правился, набит ошибками «нулевого указателя» и «лишней единицы». Я это знаю, а потому не проверяю, как учитель орфографию учеников, а пишу юнит-тесты. Только тесты могут выявить эти глупые ошибки из невнимательности. Я не стараюсь.
А потому, у меня много опыта и я не был и не буду хорошим программистом :D
Ты смотри, что творится… Толстый, жирный, зеленый — какая прелесть...Тема крайне холиварная, древняя, как окаменелость мамонта.И как-то в ходе дискуссий забыли про определения. Надо исправлять. Итак:
Тип данных — множество значений и операций над ними. Т.е. кучу данных мы разбиваем на группы (числа, строки, структуры) и определяем операции для них. Именно благодаря типу мы знаем, что вот эти 4 байта — это дробное (float) число, а не целое (int), и без указания типа эти данные для нас бессмысленны, а операции — не определены (1+2 это 3 или 12 или 10.0?). Заметьте, включение в данное определение операций также важно, поскольку для каждого типа свои операции (могут совпадать, могут не совпадать). Т.е. вообще без типов мы не сможем написать даже hello world (да, даже в машинных кодах)
Далее — типизация может быть статическая (типы заданы при обьявлении и более не меняются) и динамическая (тип определяется при присваивании). Внимание, не более того! В этом определении нет даже понятий «компиляция», «рантайм», а потому так много ошибок в суждениях тех, кто здесь видит эти понятия.
Для размытия границ используется приём вывода типов (неявное, но все же однозначное указание типа), и зачастую не очень очевидное, что и сбивает многих с толку.
Далее, типизация бывает сильная (строгая) и слабая, различие их в том, возможно ли (неявное) приведение одного типа к другому. Тоже скользский момент, потому что часто свойство сильной\слабой относят к статической\динамической, а также часто расходятся во мнениях, приведение типов невозможно вообще или только неявное приведение.
И еще одна характеристика системы типов — способ разделения на типы — тоже подпадает под раздачу в термины «статическая\динамическая», хотя и сильно зависит от первых двух характеристик и варьируется несколькими факторами. Это ООП\ОП\прототипная\утиная типизация.
Таким образом, заданы важные вопросы:
Значение (переменная\поле\обьект...) как правильно интерпретировать? (число, строка или что-то еще?)
Как с этим работать? (складывать, присваивать, хранить, взаимодействовать с другими данными)
Относится ли значение к одной группе? (можно ли одно положить в другое?)
В какой момент времени мы можем это знать? А также, сколько информации останется в момент выполнения? (имеется ввиду возможность получение описания значения, т.е. это зона рефлексии\шаблонов\генериков)
Возможно ли в принципе, и, если да, то как корректно значение одного типа присвоить другому, или использовать одно вместо другого? (присваивание, наследование, расширение)
Для динамической типизации — есть ли возможность изменение структуры сложного значения (такое, как добавление новых полей к обьектам)
Таким образом, у места-значения (переменной\поля\...) есть 3 базовых свойства:
имя (идентификатор, адрес в памяти)
тип (формат, структура, размер, простое\сложное, набор операций — как встроенных в язык, так и программно, т.е. методы обьекта)
текущее значение (возможно константное)
и эти свойства, как, впрочем, и все определения выше, универсальны для любого языка с любой типизацией; без этих определений нет смысла.
и самое важное: в этих определениях нет указаний ни на внутреннее содержание (тип — это не только «физическое» разделение число-строка-структура-..., оно может быть и более, и менее строгим, например, «значение конечного множества (любого из)», «положительные целые четные числа от 1 до 100» ), ни на форму описания (в статье «церемонии»)
более того, строгость требования (обязательно указывать тип\может быть выведен\будет известен в момент выполнения) также вариативна, и удобна от задачи к задаче.
еще более того, лично у меня не отваливаются руки «лишний раз» написать типы, а кодогенерация и современные языки позволяют уменьшить количество бойлерплейта — не нужно ругать всю типизацию из-за неудачного применения в конкретных языках.
и вот за что смело можно минусовать — удивительно, но проектировать (писать частично рабочий код и смотреть, какие решения идут удачно, какие нет) лично мне неожиданно удобнее на таком простигосподи языке с такой же х… орошей статической типизацией и бойлерплейтом, как java, а не на чудных kotlin-scala-python-ruby и т.д.
Впрочем, зачастую помогает интуиция\здравый смысл.
вспомнил, что когда-то давно
придумалчитал>Критика goto
вот именно
> Похоже, что отлаживать спагетти-код никогда не приходилось.
Хех, какой только
говнокод не приходилось отлаживать… И не только отлаживать (отладчиками), но и, простигосподи, пользоваться print\write\alertдля сравнения:
в бейсиках 80х годов каждый оператор обязан был иметь числовую метку (не совсем так, можно было группировать операторы) и называлась метка номером строки, а условные операторы не могли быть сложными (не было понятия {блок}), и потому постоянно приходилось использовать goto: в какой-то момент ненависть к такому принуждению визуально прыгать по частям кода зашкалила и оператор выдрали с корнем из всех языков
при том, что assert может не работать совсем — все зависит от флагов запуска.
> strictfp
лучше не использовать float, а использовать double, а еще лучше — использовать StrictMath
> При вызове vararg-метода без аргументов всё равно создаётся пустой массив
что очень удобно в циклах, ну и логично, если помнить, что vararg — это всего лишь syntax sugar
> Выражение switch-case не поддерживает java.lang.Class
А для чего это может понадобиться? Нет ли специфичного запашка?
>
Нет, остальное вообще, извините, детсад, комментарий аж застрял.
удобная штука, когда надо прервать из вложенного цикла во внешний.
з.ы. но стоит отметить, что эта фича используется столь редко, что давно считается дурным тоном — т.е. если вам она понадобилась, то стоит присмотреться к коду, нельзя ли его написать иначе и лучше? (а в некоторых статических анализаторах, например, встроенном в Jetbrains Idea, есть даже предупреждения об использовании break,continue, меток и вложенных циклов)
Все именнно так с их точки зрения.
Хотелки и далее идут — например, если я купил музыку, чтобы слушать на мобилке, то чтобы ее ж послушать на компьютере, я должен купить ее отдельно, еще раз. (источник инфы не помню, извините)
2008: Говорили, зачем еще один браузер, когда есть IE\Firefox\Opera
2020: Chromium поглотил браузеры.
впариваетпредлагает товары и услуги, ассоциированные с этим образом, а справочная и энциклопедическая информация — на 10ой страницемелким шрифтом, и так будут делать все.Недавно? Ах да, мелочи в масштабах вселенной…
А по сути — та же продажа перс.данных, только без реальной продажи.
Я всегда думал, что он из Челябинска