Ну да, а в том, является ли неиспользуемая переменная ошибкой или нет, ага.
Помнится, когда Яву запускали — всех тоже бесила особенность, что нельзя не обрабатывать исключение.
«Мы же умные, мы же сами решим когда их обрабатывать, а когда не обрабатывать».
Ну а авторы языка на момент создания Явы имели жизненный опыт, который говорил им, что программы, в т.ч. и тщательно отлаженные, вроде бы. А все равно могут неожиданно «падать в кору» из-за того, что программисты всё же забывают обрабатывать исключительные ситуации. И они решили принудить.
И обмазали Яву с ног до головы необходимостью всё декларировать.
Именно потому что программисты, вроде бы, и знают как нужно правильно делать, но не делают этого в реальности.
У разных гуру, как обычно, разные мнения. Разработчики объектных языков говорят о принципиальных новшествах, для реализации которых они сделали свои языки. Это Бьерн Страуструп, разрабатывавший в 1979-1986 первый вариант языка C++. Практически параллельно с ним работал Бред Кокс, автор Objective-C (1982), Бертран Майер, разработавший Eiffel (1985) с концепцией design by contract, и другие.
Однако, рассказывая историю языков, статьи вики всячески подчеркивают, что это были не оригинальные идеи, они уже были в ранее разработанных языках, и авторы концептов не просто были с ними знакомы, а использовали эти языки. Этого же мнения придерживаются некоторые гуру, разрабатывавшие структурное программирование. Например, Николаус Вирт, работавший над Алголом, а позднее разработавший Паскаль. Он полагает, что в Алголе объекты «почти были», а С++ и другие объектные языки ничего принципиально нового они не принесли.
Мы привыкли, что каждые пару лет — по новой версии Andoroid да по новому iPhone.
В других отраслях все не так быстро происходит.
Вон тормозной механизм в моем автомобиле сконструирован 30 лет назад и сохраняется сквозная совместимость со всеми моделями этого производителя, выпущенными за 30 лет.
От языка программирования тоже не следует ожидать, что он «прямо-таки уникальной-новый». Принципы подавляющего большинства мейнстримовых языков тянутся аж и 196x-198x годов
Сейчас в том же сишарпе тул предложит импортировать Error и на выбор выдаст все пакеты, откуда он может быть получен. Автоматически это решить просто невозможно.
В Go — аналогично.
Если не однозначно, то IDE вас спросит.
Если однозначно — сама подставит.
И кстати, да, в Go у вас было бы не так как в вашем примере, а так:
module1.Error Foo() { }
Ибо внешние объекты в Go указываются вместе с именем пакета.
А это уже упрощает получение подсказок/автоимпорта от IDE.
То есть в коде уже есть подсказка на вероятный правильный модуль.
Почему в одном языке должны быть те же принципы, что и в другом? Зачем тогда вообще разные языки?
Только ради синтаксической вкусовщины, чтобы у программистов была возможность, например, объявлять переменные по разному?
тип название_переменной;
название_переменной: тип;
название_переменной тип
Разница-то в языках не только в этом.
Чтобы в проекте не было ворнингов достаточно использовать куда менее драконовские меры, без потери качества. Но, видимо пока их не продаст гугл, никто про них думать не будет.
Да ладно вам демонизировать.
Есть же и Python выросший тоже под крылом Google. И он другой.
Просто языки — они разные.
В этом и смысл.
Один язык не обязан следовать принципам принятым в другом языке. Иначе и смысла придумывать разные языки не было бы никакого.
1) поддержка Линукс сильно зависит от железа, где-то всё работает из коробки, а где-то нет.
2) ну и заявлять что Windows из коробки работает всегда — это тоже не правда.
Конечно, есть разные вероятности.
Ну вы же знаете истину.
Где больше и лучше поддержка, а где больше вероятность нарваться на проблемы.
P.S.:
На серверах у меня всё прекрасно работает на FreeBSD/Linux еще с 2004.
Но на десктопе.
Делал уже множество подходов в разные годы.
Всё надеялся, что вот уже допилили.
Но то модем, то принтер, то какой софт, то еще какие-то проблемы.
Linux хорошо работает, но только в довольно узком диапазоне.
мне кажется, что их проще банить на уровне принятия в репо пакетовв. Или на уровне конвенций об именах делать их униками (ну, как, в джаве — com.gitlab.component.my — многословно, но этот код автогенерируется IDE)
Полное имя пакета — да, уникальное.
И в импорте указывается именно оно.
Но в основной части кода при обращении к объекту из этого пакета указывается только последняя часть.
Мне это видится проблемами с ветряными мельницами. Слишком умный тул, который ошибается, поэтому есть второй тул… А можно было просто не делать неиспользуемый импорт ошибкой компиляции.
Это чисто архитектурное решение.
Принципы unix — каждая утилита имеет свою узкую область ответственности, а полностью решение осуществляется группой утилит.
Вы об этом узнали просто потому что с вами поделился опытом человек, использующий vim, а там да, нужно самому поставить.
В реальной развитой IDE все эти вещи глубоко под капотом.
А можно было просто не делать неиспользуемый импорт ошибкой компиляции.
Вы же не думаете, что об этом забыли позаботиться?
Это осознанное решение разработчиков язык.
Неиспользуемые куски кода сигнализируют о потенциальных ошибках.
Лично меня уже неоднократно выручали такие сообщения. Смотрю и ошибку и понимаю, ба, действительно тут косяк.
А как оно будет работать если функция в двух подключенных пакетах есть? Пример из жизни, у меня есть микросервис, который опрашивает 5 других микросервисов. Каждый из которых выставляет типа ServiceA.Error, ServiceB.Error,… Как эта штука будет определять, какой именно Error я имел в виду в закомментированной строке?
Поскольку Go это язык со статической типизацией — у IDE довольно-много информации, чтобы решить самой.
Ибо кроме имени функции есть еще её сигнатура.
Таким образом, реальные дубли, где можно ошибиться автоматики и нужно спрашивать человека — относительно редко встречающиеся ситуации.
Тут 2 варианта что делать при наличие дублей:
1) Или каждый раз спрашивать у человека.
2) Или запоминать последнее используемое.
Спрашивается, и зачем тогда эти импорты в файле, если программист их не вводит и даже не смотрит на них..
Потому что иногда программисту нужно иметь возможность на импорты влиять вручную. Компьютеры, всё же, пока еще не пишут программы полностью за программистов.
Например, в случае одноименных пакетов. В частности IDE Jetbrains подключает импорты молча, если они однозначные. И задает вопрос, если есть сходные имена (как выше с примером rand)
В Intellij можно поставить галочку «оптимизировать импорты» во время выполнения форматирования кода. Не знаю, как все, а я часто прожимаю этот шорткат на автомате (прямо как Ctrl+S некоторые).
Э… нет, господа.
Это именно строка, но пришедшая из внешнего источника. Он нас не зависящая.
Например, строка из файла-шаблона для формирования HTML.
Как раз людям, которым компьютер нужен только в вебе сидеть — Линукс пригоден давно.
А вот если копнуть глубже, на более широкий круг задач — тут уже нужно лишний раз подумать.
Пример был не про языки, а про тенденцию.
Современная тенденция — больше диагностики.
Помнится, когда Яву запускали — всех тоже бесила особенность, что нельзя не обрабатывать исключение.
«Мы же умные, мы же сами решим когда их обрабатывать, а когда не обрабатывать».
Ну а авторы языка на момент создания Явы имели жизненный опыт, который говорил им, что программы, в т.ч. и тщательно отлаженные, вроде бы. А все равно могут неожиданно «падать в кору» из-за того, что программисты всё же забывают обрабатывать исключительные ситуации. И они решили принудить.
И обмазали Яву с ног до головы необходимостью всё декларировать.
Именно потому что программисты, вроде бы, и знают как нужно правильно делать, но не делают этого в реальности.
Угу. Есть такая тенденция.
Сравните хотя бы диагностику GCC и Clang
У меня порядка 15 лет опыта подъема десктопов на X11 и пр. друзьях Linux.
Должен констатировать, что и сейчас всецело полагаться на десктопный Linux нельзя.
В ситуациях с проверенным кругом ПО/железа Linux вполне юзабелен.
Чего нельзя сказать про общий случай.
Но своя ниша у Linux есть.
Про Солярку не скажу. А на FreeBSDшную тюрьму Докер переплюнул довольно быстро. За пару лет.
Ну авторы Go и не скрывают, что там еще идеи Хоара. А они — 197x-е годов.
В этом Go не одинок:
habr.com/ru/company/oleg-bunin/blog/516218
Мы привыкли, что каждые пару лет — по новой версии Andoroid да по новому iPhone.
В других отраслях все не так быстро происходит.
Вон тормозной механизм в моем автомобиле сконструирован 30 лет назад и сохраняется сквозная совместимость со всеми моделями этого производителя, выпущенными за 30 лет.
От языка программирования тоже не следует ожидать, что он «прямо-таки уникальной-новый». Принципы подавляющего большинства мейнстримовых языков тянутся аж и 196x-198x годов
В Go — аналогично.
Если не однозначно, то IDE вас спросит.
Если однозначно — сама подставит.
И кстати, да, в Go у вас было бы не так как в вашем примере, а так:
module1.Error Foo() { }
Ибо внешние объекты в Go указываются вместе с именем пакета.
А это уже упрощает получение подсказок/автоимпорта от IDE.
То есть в коде уже есть подсказка на вероятный правильный модуль.
Так отказывают вам в компиляции не потому что всё в программе идеально, так же?
Почему в одном языке должны быть те же принципы, что и в другом? Зачем тогда вообще разные языки?
Только ради синтаксической вкусовщины, чтобы у программистов была возможность, например, объявлять переменные по разному?
тип название_переменной;
название_переменной: тип;
название_переменной тип
Разница-то в языках не только в этом.
Да ладно вам демонизировать.
Есть же и Python выросший тоже под крылом Google. И он другой.
Просто языки — они разные.
В этом и смысл.
Один язык не обязан следовать принципам принятым в другом языке. Иначе и смысла придумывать разные языки не было бы никакого.
Конечно, есть разные вероятности.
Ну вы же знаете истину.
Где больше и лучше поддержка, а где больше вероятность нарваться на проблемы.
P.S.:
На серверах у меня всё прекрасно работает на FreeBSD/Linux еще с 2004.
Но на десктопе.
Делал уже множество подходов в разные годы.
Всё надеялся, что вот уже допилили.
Но то модем, то принтер, то какой софт, то еще какие-то проблемы.
Linux хорошо работает, но только в довольно узком диапазоне.
Полное имя пакета — да, уникальное.
И в импорте указывается именно оно.
Но в основной части кода при обращении к объекту из этого пакета указывается только последняя часть.
В вашем примере это будет:
my.A()
my.B
my.C{}
И если есть пакет
com.gitlab.other_component.my
то в нем могут быть ровное все те же:
my.A()
my.B
my.C{}
Но началось с обращения к конечному заказчику.
А затем быстро перешло к техническим нюансам, которые он никогда и не узнает.
Вот ведь какой вы любитель халявы…
Зачем мне на это тратить ресурсы?
Ради вас?
Незачем.
Это чисто архитектурное решение.
Принципы unix — каждая утилита имеет свою узкую область ответственности, а полностью решение осуществляется группой утилит.
Вы об этом узнали просто потому что с вами поделился опытом человек, использующий vim, а там да, нужно самому поставить.
В реальной развитой IDE все эти вещи глубоко под капотом.
Вы же не думаете, что об этом забыли позаботиться?
Это осознанное решение разработчиков язык.
Неиспользуемые куски кода сигнализируют о потенциальных ошибках.
Лично меня уже неоднократно выручали такие сообщения. Смотрю и ошибку и понимаю, ба, действительно тут косяк.
Поскольку Go это язык со статической типизацией — у IDE довольно-много информации, чтобы решить самой.
Ибо кроме имени функции есть еще её сигнатура.
Таким образом, реальные дубли, где можно ошибиться автоматики и нужно спрашивать человека — относительно редко встречающиеся ситуации.
Тут 2 варианта что делать при наличие дублей:
1) Или каждый раз спрашивать у человека.
2) Или запоминать последнее используемое.
Потому что иногда программисту нужно иметь возможность на импорты влиять вручную. Компьютеры, всё же, пока еще не пишут программы полностью за программистов.
Например, в случае одноименных пакетов. В частности IDE Jetbrains подключает импорты молча, если они однозначные. И задает вопрос, если есть сходные имена (как выше с примером rand)
Как и ваш частный опыт не подтверждает обратного.
Разве по default не включена?