В моём случае скорее история «Потерпи ещё немного, тимлид вот-вот появится».
Учитывая, что «вот-вот» (по опыту) может длиться от полугода до бесконечности, похоже, что правильный вариант «бегите».
Только вот психологический портрет Пети подсказывает, что
1) Пете трудно всё это безобразие бросить (как же там релиз без него)
2) На новом месте Петя будет склонен к рецидиву.
Спасибо за прекрасную статью — читал и узнавал себя в Пете:)
В связи с этим возникает вопрос: что делать, если ты — Петя, а твой руководитель этого не знает/не понимает?
С этим я как раз и не спорю.
Главное, что мы определились, что физические модели (как и любые другие) являются абстракциями, а значит физика ничем принципиально не отличается от математики:)
Нет никакой привязки физики к реальному миру. По крайней мере в том смысле, что физика чем-то этому миру обязана.
Суть в том, что есть бесконечно многогранный мир, который мы пытаемся описать понятным языком — языком моделей. Поэтому все законы физики — это такие же абстракции, умозрительные правила, которые существуют лишь в нашей голове. Яблоко падает на голову не потому что существует механика Ньютона.
Единственное отличие физики от математики — в наблюдаемости описанных закономерностей. Хотя и это уже давно не так: пресловутые M-браны или кротовые норы такие же результаты математических выкладок, как и теоремы Гёделя.
Позвольте, но физические законы записывают на языке математики!
Да и сами эти законы — лишь модели, абстракции, которыми мы осмысливаем (описываем) реальный мир.
Получается, что физика как наука — такая же игра ума, как и математика?
Кстати говоря, если пастух считает овец на калькуляторе, то он и сегодня может получить 0 — ограничения машинной арифметики и всё такое.
Так что ещё вопрос, с чем мы чаще встречаемся в нашем мире — бесконечным рядом натуральных чисел или вот такими вычетами по модулю N.
В моём мире есть и пастухи, и овцы, и кольца вычетов, трагедии пока не случилось.
Ещё можно вспомнить, что в этом же самом мире не так давно (каких-то 500 лет назад) не было нуля и отрицательных чисел, однако пастухи справлялись с подсчётом овец.
Математика тем и прекрасна, что можно вообразить совершенно любой мир с любыми законами — лишь бы они были внутренне не противоречивы. Если здесь всё ровно, то я не вижу причин отказывать в существовании такому миру.
Подумайте над таким вопросом, было ли два плюс два было равно четырем до Большого Взрыва?
Этот вопрос не имеет смысла, поскольку предполагает, что есть это самое «до БВ», т.е. что время существовало независимо от БВ. Тогда как согласно современным представлениям, время появилось именно в результате БВ.
Поясню свою мысль.
Допустим, я читаю код, в котором есть вызов функции foo().
В лучшем случае, благодаря статической типизации и IDE я знаю, что эта функция возвращает объект типа Bar и этой информации обычно достаточно для понимания локального контекста. Поэтому нет нужды заглядывать внутрь — не важно, как она работает, ведь я знаю главное — её результат.
В худшем случае, мне таки придётся лезть в кишки foo() и разбираться в том, как она работает и что возвращает.
В этом и заключается недостаток динамической типизации — с ней не бывает «лучшего случая».
Помимо кода, рассматриваемого в локальной области, приходится изучать вызываемый код, а это лишняя когнитивная нагрузка.
Само собой, этот недостаток можно сгладить, например, подходящим наименованием — вроде методов с ! и ? в ruby. Но это всегда останется лишь соглашением, которое требует определённой работы, а при наличии статической типизации всё это есть у вас из коробки.
Я не знаю, какой код вы пишете, что вам приходится несколько тысяч раз за пару месяцев менять сигнатуры функций.
По моим субъективным ощущениям, менять сигнатуру приходится довольно редко. При этом широко распространено мнение, что код чаще читается, чем пишется.
В этом месте осторожно предположу, что описание типов аргументов занимает лишь небольшой процент в общем количестве изменений кода на протяжении жизни проекта. Впрочем, на истинности этого утверждения настаивать не буду.
нужно понимать не как функция _может_ использоваться, а как она _используется_ в этой конкретной программе
Вот как раз в этом вопросе статическая типизация помогает гораздо лучше — нет нужды заглядывать в исходники функции, потому что ваша IDE легко подскажет вам, результат какого типа она возвращает.
Вывод помогает при работе с перменными внутри функций, но боилерплейт остаётся при объявлении интерфейсов (это и функции если что).
Пожалуй, стоит определиться, что именно мы называем бойлерплейтом.
Лично мне комфортнее видеть сигнатуру функции, чтобы понимать её ограничения и область применения, при этом большой проблемы в указании типов аргументов/результата я не вижу.
Вопросс во времени, запуск Python, JS, PHP почти моментальный, сборка большого проекта с шаблонами на C++/Rust уже может занять десятки минут
Выше уже говорил, но повторюсь: вид типизации это свойство языка, а компилируемость — свойство реализации. Технически ничто не мешает сделать интерпретатор для Rust или компилятор для Python.
Время работы/запуска, тоже свойство реализации, а не языка.
От класса могут унаследоваться, у класса более сложный интерфейс
В js/python/php тоже есть классы, а в С их нету. Из ваших сообщений я всё ещё не могу уяснить, какие связи между утверждениями «X — компилируемый/интерпретируемый», «в X динамическая/статическая типизация» и «в X используются классы».
Опять же, не могу не отметить, что не вижу «прямой» связи между классами и связанностью, если под связанностью мы понимаем это.
В принципе, за компилируемый язык с ДТ вполне себе сойдёт ассемблер.
В целом же хочу обратить внимание, что вид типизации — это свойство языка, а компилируемость — свойство реализации.
Например, для Basic существовали и компилятор, и интерпретатор.
1) Благодаря выводу типов, во многих современных языках программирования не так часто требуется явно указывать типы переменных.
2) Динамическая/статическая типизация и компилируемость/интерпретируемость вещи ортогональные — ЯП может быть компилируемым и с ДТ, а может быть интерпретируемым, но с СТ.
3) Какая связь между объявлением класса и связанностью кода?
4) Не уверен, что правильно понял вашу мысль про конвейер, но если вы о чём-то вроде этого, то я совершенно не понимаю, что вы понимаете под связанностью кода. Потому что подобные подходы как раз и предназначены для уменьшения этой самой связанности.
Заодно было бы интересно узнать ваше мнение по вот какому вопросу: если динамическая типизация настолько хороша, почему во многих ДТ-языках (python, php, ruby) тренд на добавление возможностей СТ?
Будем знакомы — я мобильный разработчик и я не пользуюсь мобильными банками.
Учитывая, что «вот-вот» (по опыту) может длиться от полугода до бесконечности, похоже, что правильный вариант «бегите».
Только вот психологический портрет Пети подсказывает, что
1) Пете трудно всё это безобразие бросить (как же там релиз без него)
2) На новом месте Петя будет склонен к рецидиву.
В любом случае, спасибо за совет.
В связи с этим возникает вопрос: что делать, если ты — Петя, а твой руководитель этого не знает/не понимает?
Главное, что мы определились, что физические модели (как и любые другие) являются абстракциями, а значит физика ничем принципиально не отличается от математики:)
И именно поэтому она и является игрой разума.
Суть в том, что есть бесконечно многогранный мир, который мы пытаемся описать понятным языком — языком моделей. Поэтому все законы физики — это такие же абстракции, умозрительные правила, которые существуют лишь в нашей голове. Яблоко падает на голову не потому что существует механика Ньютона.
Единственное отличие физики от математики — в наблюдаемости описанных закономерностей. Хотя и это уже давно не так: пресловутые M-браны или кротовые норы такие же результаты математических выкладок, как и теоремы Гёделя.
Да и сами эти законы — лишь модели, абстракции, которыми мы осмысливаем (описываем) реальный мир.
Получается, что физика как наука — такая же игра ума, как и математика?
Так что ещё вопрос, с чем мы чаще встречаемся в нашем мире — бесконечным рядом натуральных чисел или вот такими вычетами по модулю N.
Ещё можно вспомнить, что в этом же самом мире не так давно (каких-то 500 лет назад) не было нуля и отрицательных чисел, однако пастухи справлялись с подсчётом овец.
Математика тем и прекрасна, что можно вообразить совершенно любой мир с любыми законами — лишь бы они были внутренне не противоречивы. Если здесь всё ровно, то я не вижу причин отказывать в существовании такому миру.
Берём кольцо вычетов по модулю 3 и вот уже 2+2 легко превращается в 1.
Этот вопрос не имеет смысла, поскольку предполагает, что есть это самое «до БВ», т.е. что время существовало независимо от БВ. Тогда как согласно современным представлениям, время появилось именно в результате БВ.
Допустим, я читаю код, в котором есть вызов функции
foo().В лучшем случае, благодаря статической типизации и IDE я знаю, что эта функция возвращает объект типа
Barи этой информации обычно достаточно для понимания локального контекста. Поэтому нет нужды заглядывать внутрь — не важно, как она работает, ведь я знаю главное — её результат.В худшем случае, мне таки придётся лезть в кишки
foo()и разбираться в том, как она работает и что возвращает.В этом и заключается недостаток динамической типизации — с ней не бывает «лучшего случая».
Помимо кода, рассматриваемого в локальной области, приходится изучать вызываемый код, а это лишняя когнитивная нагрузка.
Само собой, этот недостаток можно сгладить, например, подходящим наименованием — вроде методов с
!и?в ruby. Но это всегда останется лишь соглашением, которое требует определённой работы, а при наличии статической типизации всё это есть у вас из коробки.По моим субъективным ощущениям, менять сигнатуру приходится довольно редко. При этом широко распространено мнение, что код чаще читается, чем пишется.
В этом месте осторожно предположу, что описание типов аргументов занимает лишь небольшой процент в общем количестве изменений кода на протяжении жизни проекта. Впрочем, на истинности этого утверждения настаивать не буду.
Вот как раз в этом вопросе статическая типизация помогает гораздо лучше — нет нужды заглядывать в исходники функции, потому что ваша IDE легко подскажет вам, результат какого типа она возвращает.
Главное, что мы определились, что компилируемость/интерпретируемость и динамическая/статическая типизация — вещи ортогональные.
Пожалуй, стоит определиться, что именно мы называем бойлерплейтом.
Лично мне комфортнее видеть сигнатуру функции, чтобы понимать её ограничения и область применения, при этом большой проблемы в указании типов аргументов/результата я не вижу.
Выше уже говорил, но повторюсь: вид типизации это свойство языка, а компилируемость — свойство реализации. Технически ничто не мешает сделать интерпретатор для Rust или компилятор для Python.
Время работы/запуска, тоже свойство реализации, а не языка.
В js/python/php тоже есть классы, а в С их нету. Из ваших сообщений я всё ещё не могу уяснить, какие связи между утверждениями «X — компилируемый/интерпретируемый», «в X динамическая/статическая типизация» и «в X используются классы».
Опять же, не могу не отметить, что не вижу «прямой» связи между классами и связанностью, если под связанностью мы понимаем это.
В целом же хочу обратить внимание, что вид типизации — это свойство языка, а компилируемость — свойство реализации.
Например, для Basic существовали и компилятор, и интерпретатор.
1) Благодаря выводу типов, во многих современных языках программирования не так часто требуется явно указывать типы переменных.
2) Динамическая/статическая типизация и компилируемость/интерпретируемость вещи ортогональные — ЯП может быть компилируемым и с ДТ, а может быть интерпретируемым, но с СТ.
3) Какая связь между объявлением класса и связанностью кода?
4) Не уверен, что правильно понял вашу мысль про конвейер, но если вы о чём-то вроде этого, то я совершенно не понимаю, что вы понимаете под связанностью кода. Потому что подобные подходы как раз и предназначены для уменьшения этой самой связанности.
Заодно было бы интересно узнать ваше мнение по вот какому вопросу: если динамическая типизация настолько хороша, почему во многих ДТ-языках (python, php, ruby) тренд на добавление возможностей СТ?
Приятно познакомиться.