Забавно. В статье написано, что правила файрвола не распространяется на WSL.
В моем же случае пинговать даже локальную Windows из под WSL не получается. Хотя к глобальной сети доступ из под WSL есть.
Слышал про такой нежелательный эффект слишком раннего обучения чтению, что потом когда ребенок приходит в 1 класс, там, как правило, далеко не все дети умеют читать, и его будут учить заново.
Не.
Сейчас, как правило, наоборот.
В первом классе почти все читают.
Но и это не проблема — сразу тестируют и раскидывают на два класса с разным уровнем.
Linux, несмотря на все усилия предпринимаемыми десятилетиями уже, всё равно отстает по удобству от MacOS и Windows.
Это конечно не означает, что пользоваться Linux совсем нельзя.
Но до сих пор приходится сталкиваться… вот нужно было мне подключиться к интернету в дороге через сотовую связь — в Linux для этого пришлось кучу танцев с бубнами проделать (для которых, к слову, нужен доступ к интернету для инструкций), потратил 3 часа, плюнул, перезагрузился в Windows и
все заработало сразу.
И да, в Linux это не завелось ни через Wi-Fi ни через прямое подключение к смартфону по кабелю, ни через прямое подключение к USB-модему. В Windows всё заработало сразу же для любого из трёх упомянутых выше способов. Железо хорошее и не старое. ОС Linux свежая.
P.S.:
Плотно использую unix-системы с 2004 года как админ и как разрабочик.
Полагаю, я всё же смог бы разобраться, если бы потратил еще времени. Но у меня есть куда потратить эти часы времени. На работу. Или на хобби. Или на семью. Или на спорт.
Но не на то, чтобы бороться со своим инструментом.
И какова целевая платформа разработки?
Если целевая платформа десктопный Linux с GUI, то тут и вопросов нет, нужно использовать для разработки Linux. Но это не про WSL.
WSL — это про то если целевая платформа серверный Linux.
И тут использование локального Linux далеко не всегда помогает.
Даже нередко вводит в заблуждение типа «а у меня всё работает, почему у вас там на сервере не работает — не знаю».
Просто потому что софтовая конфигурация сервера серьезно отличается от конфигурации Linux'a разработчика. Другое ядро, другие установленные пакеты, другая конфигурация системы.
Для идеальной проверки как будет функционировать разрабатываемое вами ПО на Linux-сервере вам всё равно нужно тестировать это ПО в изолированной среде (типа Docker хотя бы или в полноценной виртуальной машине).
Так что на чем разрабатывать — не зависит от целевой платформы.
Исключение только разработка под десктоп Linux, тут разумно использовать Linux и разработчику.
А потом на практике окажется что метод пузырьком будет быстрее на малом объеме данных, потому-что кеш.
А потом окажется, что время, бездарно потраченное потраченное на множество оптимизаций до таких незначительных мелочей, превращает изначально коммерчески перспективный проект в убыточный.
Вы уверены, что на нынешнем железе стоит тратить на это время?
При том, что львиная затрата времени вашей программы идет вовсе не на сортировку в кэше или не в кэше, а на совсем иные вещи:
Задержки по сети, задержки на диске, ожидание ввода пользователя.
Все пункты спорны, но вот про 2 и 3 откомментирую: когда я игрался с кодом на Go то любое экспериментирование в стиле «давайте закомментируем использование этой переменной и попробуем всесто неё использовать константу» приводило к лавинообразному «неиспользуется там/неиспользуется здесь». В итоге я по 5 минут занимался тем, чтобы комментировать разные куски кода, или тем паче его редактировать, а потом после игрищ нужно было как-то помержить результат исследования с изначальным видом кода.
Совершенно согласен, что это раздражает.
Но при этом я кучи незаметных ошибок избежал (переменную подготовил, задумал её использовать, а потом ушел в другое место программы и забыл про эту переменную; но умница компилятор подсказал; оказывается, всё правильно он мне подсказал, нужно было эту переменную использовать; компилятор помог не допустить логической ошибки в программе), так что как бы не раздражало, но смысл в этих проверках есть.
Тут можно привести пример Хаскеля, где подобные вещи на порядок более жестко проверяются. И, в шутку или в серьезно про программу на Хаскеле можно сказать так: «если ваша программа на Хаскеле вообще смогла скомпилироваться, то она, с большой вероятность и задачу вашу решит корректно».
Так вот все эти доп. проверки в Go позволяют избежать некорректно работающих программ не только в техническом смысле, а и в смысле уменьшения количества ошибок для целей решения конечной задачи, ради которой программа и была создана.
Ну как пример обратный:
Тот же С позволяют и ногу себе отстрелить.
Но на сегодня сложные проекты целесообразнее создавать на Rust, где компилятор делает кучу дополнительных проверок, чтобы уменьшить вероятность остаться без ноги.
Да это раздражает, пока прорываешься через сообщения компилятора.
Но лучше иметь эти сообщения.
А это легко решается вызовом форматтера на стороне гит сервера, который проверит, что код корректно написан. Вы правда думаете, что дописать одну проверку сложно?
Я правда думаю, что этого никто делать не будет. Если не принуждать.
За очень редкими исключениями предприятий высокой культуры коды.
Я правда думаю, что этого никто делать не будет, как мы это видим в других языках программирования, несмотря на наличие для них code style и соответствующих утилит.
В результате мы имеем очень разномастный код в других языках в публичных пакетах/библиотека.
Чем это плохо? Глазу нужно время чтобы настроится.
А код на Go читается гораздо легче и быстрее всегда, там глаз всегда настроен на одно и то же, потому что авторы языка Go продавили определенный стандарт на code style немножко насильно.
К слову: автор утилиты go fmt даже сам не был согласен с конкретными правилами code style, принятыми для Go. Но при этом он понимал, что всё равно эти правила должны быть едиными для всех, независимо от его личного вкуса.
Скажем, потому что мне не хочется учитывать уйму подводных камней Go.
Вы привели в пример довольно-таки ангажированный список. Там есть некоторое количество подводных камней, но в реальности их гораздо меньше, чем в упомянутой вами статье.
Смотрите что там написано:
Пункт 1) Достоинство выдаваемое за недостаток. В других языка заводят специальные большие документы по code style и пишут дополнительные утилиты, чтобы избежать проблемы, которой в Go нет из коробки. И уж чем, чем, а именно подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 2) Позволяет уменьшить количество ошибок в коде. Это достоинство языка, опять таки, выдаваемое за недостаток. Но автор статьи с непонятных причин выставляет это как недостаток. Подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 3) Достоинство языка, выдаваемое за недостаток, то же что и пункт 2. Подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 4) Вкусовщина. Подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 5) Вот мы добрались до первого подводного камня. Пятым в списке претензий к языку обнаружился первый подводный камень, что говорит нам о низком качестве проработки «претензий» в упомянутой вами статье.
Пункт 6) Вкусовщина. Подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 7) Можно засчитать как половина подводного камня, так как это зачастую даже нужно самому программисту. Хотя да, приходится быть внимательнее. Решается включением статического анализатора.
Пункт 8) Автор статьи требует нарушить принципы языка Go — делать вещи по возможности явными.
Пункт 9) Ну так то речь вообще о разных вещах. Автор ожидает что и у функции и у простого присваивания будет одинаковое поведение. Что? Проблема в голове автора.
Пункт 10) Это второй однозначно подводный камень. Он идет 10-ым в списке претензий. Что показывает притянутость за уши большей части претензий.
Пункт 11) Совершенно логично сделано в языке.
Ну и так далее в том же духе.
Реальных подводных камней в статье приведено раз-два и обчелся.
Остальные претензии автора — или личная вкусовщина автора той статьи или, даже, он достоинства языка выставляет за недостатки.
Причем подавляющая часть претензий к тому, что «компилятор не дает так делать». Но, позвольте, такое поведение уж к подводным-то (незаметным) камням отнести никак нельзя.
Вы напрасно ссылаетесь на тот список, как на какой-то авторитет.
А у меня локально установленный PostgreSQL не видно из под WSL2.
По IP на 127.0.0.1
Подозреваю, нужно какой другой адрес указывать. Руки не доходили разобраться.
А вот если сравнивать с письменным официальным (письма, жалобы, юридические документы, тех.документация), то неожиданно
там тоже есть алгоритмы, паттерны, концепции, код.стайлы
Code Style — да.
А вот алгоритмы и концепции в каком-то официальном документе — это уже другая область человеческого знания, например, юриспруденция.
Но это не собственно знание самого языка.
А так то — да. Любая область человеческой деятельности использует язык как минимум как вспомогательный инструмент.
Знать человеческий язык — уметь выразить письменно на этом языке свою мысль так, чтобы тебя поняли именно так, как тебе надо. Ну и в обратную сторону — понять, что тут тебе написали.
То есть программисты, если они действительно хорошие программисты, то они априори способны написать хорошее художественное произведение?
Я очень хорошо помню тим-лида, который сказал: «Я всегда предпочту программиста, который использует встроенную в язык функцию, а не начнёт изобретать что-то своё». «Гугл-программисты» — это требование рынка. Других просто не возьмут. Те, кто умеют думать и могут придумать что-то без готового решения называют «изобретателями велосипедов» и отбраковывают.
Не-а.
Вы упускаете что будет если таковой функции не существует и её всё же надо написать.
Автор статьи написал об этом «выход на плато, без дальнейшего роста производительности».
P.S.:
А не писать то, что уже написано до вас нужно было еще и в прошлом веке, это никакое не требование сегодняшнего рынка.
Приравнивать десятки слов компьютерного языка, дающих полное понимание языка программирования,
А я не про понимания языка программирования. Я про понимание и написание всей программы. Где уже надо знать, что вызываемые функции делают. Которых функций и классов — сильно побольше, чем десяток.
Это как?
Вы приравниваете понимание работы алгоритма к изучению человеческого языка?
Понимаете человеческий язык и язык программирования — это о разном.
«это же само собой разумеющееся, мы думали, что ты это сделаешь, поэтому ты это должен сделать бесплатно» — есть ли шанс представить в этот момент что заказчик может быть прав и постараться найти причину в процессе почему так произошло?
Это же зависит только от сложности (и соответственно стоимости) разработки.
Если мелочи — то фиг с ним. Делаем бесплатно. Это нормально.
А если заказчик добавил к описанию задачи одно слово — а это месяц работы, то нет. Такие доработки только за счет заказчика.
Ключевые слова и конструкции в ЯП больше соответствуют грамматическим конструкциям в естественных языках.
При этом знание языковых конструкций дает вам понимание всего языка программирования.
А знание всех языковых конструкций живого языка не дает вам ничего.
Ибо Вам нужно заучить тысячи слов.
И не только слов, а еще и выражений (потому что слова на другой язык далеко не всегда переводятся однозначно, исключение только в простейших словах, типа местоимений, те, да, переводятся просто).
В моем же случае пинговать даже локальную Windows из под WSL не получается. Хотя к глобальной сети доступ из под WSL есть.
Не.
Сейчас, как правило, наоборот.
В первом классе почти все читают.
Но и это не проблема — сразу тестируют и раскидывают на два класса с разным уровнем.
Linux, несмотря на все усилия предпринимаемыми десятилетиями уже, всё равно отстает по удобству от MacOS и Windows.
Это конечно не означает, что пользоваться Linux совсем нельзя.
Но до сих пор приходится сталкиваться… вот нужно было мне подключиться к интернету в дороге через сотовую связь — в Linux для этого пришлось кучу танцев с бубнами проделать (для которых, к слову, нужен доступ к интернету для инструкций), потратил 3 часа, плюнул, перезагрузился в Windows и
все заработало сразу.
И да, в Linux это не завелось ни через Wi-Fi ни через прямое подключение к смартфону по кабелю, ни через прямое подключение к USB-модему. В Windows всё заработало сразу же для любого из трёх упомянутых выше способов. Железо хорошее и не старое. ОС Linux свежая.
P.S.:
Плотно использую unix-системы с 2004 года как админ и как разрабочик.
Полагаю, я всё же смог бы разобраться, если бы потратил еще времени. Но у меня есть куда потратить эти часы времени. На работу. Или на хобби. Или на семью. Или на спорт.
Но не на то, чтобы бороться со своим инструментом.
Если целевая платформа десктопный Linux с GUI, то тут и вопросов нет, нужно использовать для разработки Linux. Но это не про WSL.
WSL — это про то если целевая платформа серверный Linux.
И тут использование локального Linux далеко не всегда помогает.
Даже нередко вводит в заблуждение типа «а у меня всё работает, почему у вас там на сервере не работает — не знаю».
Просто потому что софтовая конфигурация сервера серьезно отличается от конфигурации Linux'a разработчика. Другое ядро, другие установленные пакеты, другая конфигурация системы.
Для идеальной проверки как будет функционировать разрабатываемое вами ПО на Linux-сервере вам всё равно нужно тестировать это ПО в изолированной среде (типа Docker хотя бы или в полноценной виртуальной машине).
Так что на чем разрабатывать — не зависит от целевой платформы.
Исключение только разработка под десктоп Linux, тут разумно использовать Linux и разработчику.
А потом окажется, что время, бездарно потраченное потраченное на множество оптимизаций до таких незначительных мелочей, превращает изначально коммерчески перспективный проект в убыточный.
Вы уверены, что на нынешнем железе стоит тратить на это время?
При том, что львиная затрата времени вашей программы идет вовсе не на сортировку в кэше или не в кэше, а на совсем иные вещи:
Задержки по сети, задержки на диске, ожидание ввода пользователя.
Совершенно согласен, что это раздражает.
Но при этом я кучи незаметных ошибок избежал (переменную подготовил, задумал её использовать, а потом ушел в другое место программы и забыл про эту переменную; но умница компилятор подсказал; оказывается, всё правильно он мне подсказал, нужно было эту переменную использовать; компилятор помог не допустить логической ошибки в программе), так что как бы не раздражало, но смысл в этих проверках есть.
Тут можно привести пример Хаскеля, где подобные вещи на порядок более жестко проверяются. И, в шутку или в серьезно про программу на Хаскеле можно сказать так: «если ваша программа на Хаскеле вообще смогла скомпилироваться, то она, с большой вероятность и задачу вашу решит корректно».
Так вот все эти доп. проверки в Go позволяют избежать некорректно работающих программ не только в техническом смысле, а и в смысле уменьшения количества ошибок для целей решения конечной задачи, ради которой программа и была создана.
Ну как пример обратный:
Тот же С позволяют и ногу себе отстрелить.
Но на сегодня сложные проекты целесообразнее создавать на Rust, где компилятор делает кучу дополнительных проверок, чтобы уменьшить вероятность остаться без ноги.
Да это раздражает, пока прорываешься через сообщения компилятора.
Но лучше иметь эти сообщения.
Я правда думаю, что этого никто делать не будет. Если не принуждать.
За очень редкими исключениями предприятий высокой культуры коды.
Я правда думаю, что этого никто делать не будет, как мы это видим в других языках программирования, несмотря на наличие для них code style и соответствующих утилит.
В результате мы имеем очень разномастный код в других языках в публичных пакетах/библиотека.
Чем это плохо? Глазу нужно время чтобы настроится.
А код на Go читается гораздо легче и быстрее всегда, там глаз всегда настроен на одно и то же, потому что авторы языка Go продавили определенный стандарт на code style немножко насильно.
К слову: автор утилиты go fmt даже сам не был согласен с конкретными правилами code style, принятыми для Go. Но при этом он понимал, что всё равно эти правила должны быть едиными для всех, независимо от его личного вкуса.
Вы привели в пример довольно-таки ангажированный список. Там есть некоторое количество подводных камней, но в реальности их гораздо меньше, чем в упомянутой вами статье.
Смотрите что там написано:
Пункт 1) Достоинство выдаваемое за недостаток. В других языка заводят специальные большие документы по code style и пишут дополнительные утилиты, чтобы избежать проблемы, которой в Go нет из коробки. И уж чем, чем, а именно подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 2) Позволяет уменьшить количество ошибок в коде. Это достоинство языка, опять таки, выдаваемое за недостаток. Но автор статьи с непонятных причин выставляет это как недостаток. Подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 3) Достоинство языка, выдаваемое за недостаток, то же что и пункт 2. Подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 4) Вкусовщина. Подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 5) Вот мы добрались до первого подводного камня. Пятым в списке претензий к языку обнаружился первый подводный камень, что говорит нам о низком качестве проработки «претензий» в упомянутой вами статье.
Пункт 6) Вкусовщина. Подводным камнем не является, так как вам не удастся сделать это незаметно, компилятор вам не даст.
Пункт 7) Можно засчитать как половина подводного камня, так как это зачастую даже нужно самому программисту. Хотя да, приходится быть внимательнее. Решается включением статического анализатора.
Пункт 8) Автор статьи требует нарушить принципы языка Go — делать вещи по возможности явными.
Пункт 9) Ну так то речь вообще о разных вещах. Автор ожидает что и у функции и у простого присваивания будет одинаковое поведение. Что? Проблема в голове автора.
Пункт 10) Это второй однозначно подводный камень. Он идет 10-ым в списке претензий. Что показывает притянутость за уши большей части претензий.
Пункт 11) Совершенно логично сделано в языке.
Ну и так далее в том же духе.
Реальных подводных камней в статье приведено раз-два и обчелся.
Остальные претензии автора — или личная вкусовщина автора той статьи или, даже, он достоинства языка выставляет за недостатки.
Причем подавляющая часть претензий к тому, что «компилятор не дает так делать». Но, позвольте, такое поведение уж к подводным-то (незаметным) камням отнести никак нельзя.
Вы напрасно ссылаетесь на тот список, как на какой-то авторитет.
WSL это инструмент не юзера, а инструмент разработчика.
Начинать в наше время новый проект на С — это должны быть аргументы.
По IP на 127.0.0.1
Подозреваю, нужно какой другой адрес указывать. Руки не доходили разобраться.
Но может кто знает готовое решение?
А можно конкретику?
Ну а если их 300 разработчиков всего?
Настоящих программеров все равно должно быть 3?
А остальные 297 — тупые просто приложения к клавиатуре?
P.S.:
Индустрия разработки ПО существует вот уже более полусотни лет, всё уже рассчитано до нас.
Например, один из классических трудов по организации разработки ПО «Мифический человеко-месяц» Ф. Брукса опубликован еще в 1975 году.
И старших разработчиков нужно довольно много. Типично, на каждые 2-5 человек обычных разработчиков — 1 старший.
А вовсе не:
Code Style — да.
А вот алгоритмы и концепции в каком-то официальном документе — это уже другая область человеческого знания, например, юриспруденция.
Но это не собственно знание самого языка.
А так то — да. Любая область человеческой деятельности использует язык как минимум как вспомогательный инструмент.
То есть программисты, если они действительно хорошие программисты, то они априори способны написать хорошее художественное произведение?
Это вы напрасно.
Не-а.
Вы упускаете что будет если таковой функции не существует и её всё же надо написать.
Автор статьи написал об этом «выход на плато, без дальнейшего роста производительности».
P.S.:
А не писать то, что уже написано до вас нужно было еще и в прошлом веке, это никакое не требование сегодняшнего рынка.
Это как?
Вы приравниваете понимание работы алгоритма к изучению человеческого языка?
Понимаете человеческий язык и язык программирования — это о разном.
То, что в реальности нужно знать программисту помимо синтаксиса — алгоритмы, паттерны, концепции — это вовсе не слова зубрить.
Имхо, за уши притянуто сравнение человеческого языка и языка программирования.
Это же зависит только от сложности (и соответственно стоимости) разработки.
Если мелочи — то фиг с ним. Делаем бесплатно. Это нормально.
А если заказчик добавил к описанию задачи одно слово — а это месяц работы, то нет. Такие доработки только за счет заказчика.
При этом знание языковых конструкций дает вам понимание всего языка программирования.
А знание всех языковых конструкций живого языка не дает вам ничего.
Ибо Вам нужно заучить тысячи слов.
И не только слов, а еще и выражений (потому что слова на другой язык далеко не всегда переводятся однозначно, исключение только в простейших словах, типа местоимений, те, да, переводятся просто).