Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 300
Забавно наблюдать, как меняется мода: еще недавно все хипстеры писали на Ruby, потом много шума было вокруг Scala, и, вот, теперь Go это наше всё! Интересно, какой язык будет следующим?
Может быть это не хипстеры, а люди, которые используют правильные технологии для правильных задач, и постоянно развиваются по мере того, как меняется мир? :)
Пока что я вижу в новостях на всяких opennet-ах кучу утилит на Go, целью написания которых является написание их на Go.
Утилиты типа Docker, Consul, Vault и Kubernetes?
Возьмите пример этой статьи — люди пишут код для себя. Вы об их софте, который решает необходимые им задачи, вряд ли узнаете на opennet-е.
Возьмите пример этой статьи — люди пишут код для себя. Вы об их софте, который решает необходимые им задачи, вряд ли узнаете на opennet-е.
Утилиты типа DockerЭто та самая обвязка вокруг готовых фич линуксового ядра, в которой нельзя поменять конфиг, не пересоздав контейнер? Хороший пример высот инженерной мысли, да.
Не правда что именно?
это просто процессЭто не процесс. Учите матчасть своего докера. Контейнер — это набор неймспейсов, слоёв aufs и сетевых устройств, в котором запущены один или несколько процессов. Соответственно, контейнеру сопоставлено его текущее состояние файловой системы. Вы не можете просто взять и поменять набор портов или внешних точек монтирования, проброшенных в уже существующий контейнер. Вы не можете для него поменять флаги для выдачи прав. Вам необходимо его остановить (если запущен), удалить и пересоздать, предварительно сделав docker commit с его текущим состоянием.
Не говоря уже о ряде странных технических решений типа невозможности задать контейнеру заранее заданый IP-адрес (с тем чтобы не издеваться с конфигами nginx-а на хосте, например) и пробросе по-умолчанию портов через прокси-процесс, что приводит к весьма забавным эффектам при попытке пробросить в контейнер диапазон из пары тысяч портов (нужно для вещей типа фрисвича).
Это процесс ограниченый неймспейсами и сигрупами.Ещё раз повторяю, контейнер — это не процесс. Вы про команду
docker exec вообще слышали? Выдержка из хэлпа:# docker exec --helpЕсли контейнер — это процесс, то как в процессе можно запустить команду? Докероконтейнер — по сути та же OpenVZшная виртуалка, но с набором слоёв aufs в качестве корневой ФС и с пользовательским исполняемым файлом в качестве процесса init.
Usage: docker exec [OPTIONS] CONTAINER COMMAND [ARG...]
Run a command in a running container
В смысле? Я могу хоть прямо в его ФС залезть в хостовой машины.
Есть запущенный контейнер, например:
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e580abee4ed0 myimage "/bin/myinit" 15 hours ago Up 15 hours 9.9.100.10:80->80/tcp, 9.9.100.10:5061->5061/tcp, 9.9.100.10:5080->5080/tcp, 9.9.100.10:16000-16100->16000-16100/udp mycontainerДобавьте сюда проброшенный порт не прибегая к командам docker rm и docker create, пожалуйста.
Вы НЕ поменяли конфиг контейнера, вы поменяли iptables. Когда контейнер перезапустят (
В общем, из разговора с вами сложилось впечатление, что:
1) вы не осознавали, что в контейнере может быть несколько процессов и обзываете контейнер процессом.
2) вы не осознаёте, что у контейнера есть состояние файловой системи, что контейнер можно останавливать и заново запускать, сохраняя это состояние
3) вы не понимаете как внутри работает докер и, по всей видимости, не пользуетесь половиной его возможностей
4) вы кидаетесь гифками, на которых делаете не то, о чём вас просят
Поведение достойное тролля или воинствующего школьника с ЛОРа. Далее какую-либо дискуссию продолжать не вижу смысла.
docker stop + docker start) ваши портмаппинги слетят.они реализованы при помощи iptablesПо-умолчанию задействован не iptables, а процесс прокся, отключать которую можно только с версии 1.7 (см.
userland-proxy)В общем, из разговора с вами сложилось впечатление, что:
1) вы не осознавали, что в контейнере может быть несколько процессов и обзываете контейнер процессом.
2) вы не осознаёте, что у контейнера есть состояние файловой системи, что контейнер можно останавливать и заново запускать, сохраняя это состояние
3) вы не понимаете как внутри работает докер и, по всей видимости, не пользуетесь половиной его возможностей
4) вы кидаетесь гифками, на которых делаете не то, о чём вас просят
Поведение достойное тролля или воинствующего школьника с ЛОРа. Далее какую-либо дискуссию продолжать не вижу смысла.
Мне кажется это скорее вы с самого начала не поняли человека. Я прекрасно понял, о чем он говорил изначально. Меня самого парит докер этим — уже упомянутые маппинги портов залочены за контейнером, их нельзя менять не удаляя и пересоздавая его. По крайней мере, я не знаю такого способа. Хотя, казалось бы, вот тебе JSON'чик со всеми конфигами. Бери да меняй. К слову, автозапуск я так вручную и добавлял туда, и все работало.
Не говоря уже о ряде странных технических решений типа невозможности задать контейнеру заранее заданый IP-адрес
Та кажись уже можно, даже бриджинг умеет. Но я лично не проверял. https://docs.docker.com/engine/userguide/networking/dockernetworks/#the-default-bridge-network-in-detail
Интересно читать ваш комментарий через 3 года.
Эммм… лично я люблю плюшки из новых языков программирования, но когда компания переезжает со Scala на Go, сразу ясно что это за люди. Вряд ли там сидят суровые прагматики. В этом случае причина перехода скорее в тяге к новому, чем в необходимости.
В этом и дело. Когда у вас 5 человек, где вы лично держите в голове код вашего сервиса — плюшки могут быть аргументом. Когда у вас 200+ человек, ваши плюшки — это помеха и торможение процессов.
Эта статья мне очень понравилась именно тем, что хорошо это демонстрирует.
Эта статья мне очень понравилась именно тем, что хорошо это демонстрирует.
Разъясните мне тогда, пожалуйста, такую вещь: когда компания, про которую в статье идет речь, обожглась, используя Scala, они решили уйти в Go. Они туда пошли за чем? За простотой? А что тогда они не ушли в Java?
Они всего-навсего пошли за другими, более модными плюшками, прикрываясь тем, что Go проще, и что Scala не масштабируется (какая ирония, учитывая название языка!).
Они всего-навсего пошли за другими, более модными плюшками, прикрываясь тем, что Go проще, и что Scala не масштабируется (какая ирония, учитывая название языка!).
Не знаю, работали ли вы в компаниях, которые растут с 3х человек до 50+, но ваши рассуждения очень поверхностны. «Пошли всего-навсего за плюшками» совсем не отражает тех процессов, когда рост компании приводит к реальным затыкам и проблемам в разработке и поддержке кода.
Тут же вообще весь процесс был инициирован снизу, самими разработчиками, поэтому вопрос «за чем они ушли» не совсем корректен. Они ушли, потому что Go позволял им быстрее и качественнее получать результат в масштабе компании. Только и всего.
Тут же вообще весь процесс был инициирован снизу, самими разработчиками, поэтому вопрос «за чем они ушли» не совсем корректен. Они ушли, потому что Go позволял им быстрее и качественнее получать результат в масштабе компании. Только и всего.
Не такие уж и поверхностные рассуждения. Сами разработчики инициировали процесс? А сколько из инициировавших разработчиков реально работало с Go в крупных проектах до этого? Думаю в лучшем случае единицы, так как язык довольно молодой, а на момент событий, описываемых автором и того младше. Т.е. реально у разработчиков не было опыта разработки коммерческих продуктов на Go и весь переход был обусловлен тем, что разработчика хлебом не корми, а дай поучить что-нибудь новое, да еще и за з\п. В итоге начался процесс перетягивания толпы специалистов с одной технологии на другую. И то, как я понял по статье не просто перетягивание. Теперь при найме разработчика он должен обладать навыками и в scala, и в go, так как часть кода все также написана на scala. Следовательно никто не дает гарантии, что новый разработчик секты Go не будет часами втупливать на какую-то legacy утилиту компании на scala. И что тогда поменялось? Может просто стоило делать ревью, ввести более строгий code style на scala, а не рубить с плеча?
Мне кажется, у них все чуть более грамотно построено, чем вы только что описали. Согласитесь, описанные вами проблемы сильно зависят от деталей процессов компании, которых мы не знаем.
Понятно )
секты Go
Понятно )
Я не гадаю, а говорю о том, что прочитал только что в статье. Не исключено, что причины вообще не такие, как описаны (если у Вас есть более подробная информация — изложите в статье и мы не будем гадать). Но по статье я вижу, что у них отсутствовал единый стиль (о чем автор сам сказал выделив две группы в команде), не было ревью (иначе 2 примера из статьи не прошли бы проверку), каждый разработчик старался повысить JSI (что абсолютно подтверждается примером с тем, что они не смогли разобраться в коде когда автор кода был в отпуске), а еще их старшие разработчики, работавшие в «крупнейших компаниях мира» не могут понять scala код и разобраться как работает SBT. Думаю это говорит достаточно об авторе оригинальной статьи и команде.
Не думаю. Статья довольно сжатая, чтобы рассказать обо всех разработчиках, описать детали, особенно на разных стадиях роста компании. Поэтому неверно будет хвататься за один описанный случай и экстраполировать его все процессы компании. Кроме того, у меня, к примеру нет опыта управления командой из 200 человек, и я не уверен, что в реальном бизнесе просто найти 200 людей, которые могут разобраться во всем досконально, особенно если на это уходят месяцы. Тут бывает сложно найти одного минимально толкового человека, а тут 200!
Или у вас есть другой опыт, и вы считаете, что найти 200 великолепных scala-гениев достаточно просто, нужен просто хороший тех.дир.?
Или у вас есть другой опыт, и вы считаете, что найти 200 великолепных scala-гениев достаточно просто, нужен просто хороший тех.дир.?
В том и дело, что Вы сами судите по сжатой статье о том, что у них все было идеально в организации, но scala мешала жить, а только благодаря Go все стало как в раю. А почти каждый комментирующий пытается убедить Вас в том, что не все так просто. Про мой опыт — Вы так спрашиваете об это у каждого, как будто это что-то изменит. Да, людей, которые управляли бы 200 разработчиками в мире единицы. Но это не значит, что эти люди принимает всегда только верные решения. Отвечая на Ваш вопрос — я управлял максимум 8 разработчиками. Да, это очень трудная задача даже с куда меньшими количествами. Но с другой стороны опыт Демарка и Спольски говорит, что 200 разработчиков не всегда лучше 20, особенно, если нет возможности нанять «scala-гениев» и начинаешь брать людей, которые не могут разобраться в sbt.
В том и дело, что Вы сами судите по сжатой статье о том, что у них все было идеально в организации
Вам не надоело еще приписывать мне слова, которые я не говорил? Я понимаю, что легко сказать шаблонную фразу, приписать её собеседнику и с ней бороться, но зачем? Где я сказал, что «у них все было идеально». Вот, пожалуйста, скопируйте текст из моих комментариев, где я такое говорю. Жду.
Про мой опыт — Вы так спрашиваете об это у каждого, как будто это что-то изменит. Да, людей, которые управляли бы 200 разработчиками в мире единицы. Но это не значит, что эти люди принимает всегда только верные решения. Отвечая на Ваш вопрос — я управлял максимум 8 разработчиками.
А вот тут уже начинается интересное и по сути. Безусловно, это не значит, что решения верные. Но это также и не значит, что нужно игнорировать чужой опыт, и с пеной у рта доказывать, что «просто плохой менеджер». Это признак некомпетентности. Любой действительно опытный и грамотный руководитель и программист никогда не будет кидаться подобными суждениями. Мне как раз эта статья нравится тем, что автор достаточно аккуратно пишет и о выборе технологий, и не бросается в крайности, а подчеркивает компромиссы и практичность решений. И это создает очень большой контраст с комментаторами на хабре, которые, не имея даже близко такого опыта, знают «как правильно» и у которых все неучи и неумехи.
пожалуйста, скопируйте текст из моих комментариев
Да хотя бы вот эти фразы «Заменяемость решает тем. что, как и описано в статье, можно взять человека почти с любым бекграундом и за недели иметь программиста, способного писать и поддерживать проекты на Go. Гайдлайны не нужны, потому что в Go очень мало способов сделать одно и то же разными способами, он сам по себе гайдлайн.», «как именно нужно было решить проблему сплита и нарастающего эффекта сложности входа в проект с помощью Хорошего Менеджера, причем так, чтобы это было явно лучше перехода на Go». Эти фразы я понимаю таким образом, что не перейдя они с «кривой» scala, все бы пошло прахом, а вот перешли на Go и все шикарно и другого выходы не было. Именно отсюда я и «приписал» Вам слова, просто описав суть в более короткой форме. Про «идеально в организации» — на основе того, что Вы постоянно пытаетесь спросить а есть ли у других такой крутой опыт. Я это понимаю как очень высокую оценку работы тех лида с Вашей стороны.
это также и не значит, что нужно игнорировать чужой опыт, и с пеной у рта доказывать, что «просто плохой менеджер». Это признак некомпетентности
Что ж Вы сами начинаете оценивать мою компетентность и игнорировать мой опыт, ведь это признак некомпетентности? Мало того, а что я должен делать с этой статьей? Молиться на нее, так как я не управляю 200 программистами? Я ее прочитал пытаясь получить новый опыт и понял, что почерпнуть я с нее ничего не могу, так как в своей команде я такого не допущу (также как и не допустят другие члены команды), так как мы пишем код не для того, чтобы заюзать модную штуку, а чтобы он работал стабильно и делал то, что от него требуется.
Code Reviews would have solved this issue as someone else would have stumbled on that symbol and asked for more clarity and understanding. That would have help introduced the library to the team easier than a surprise. Unfortunately, at Gravity we didn’t have required code reviews in place. We do have code reviews in place at CrowdStrike.
Взята из оригинальной статьи. Автор добавил эту приписку на сотни таких же комментариев, недоумевающих как такое можно было допустить в коде проекта. Т.е. по сути они писали говнокод, никак его не контроллировали, все пошло под откос (причем это было при предыдущем тех лиде судя по всему, этот вроде как не виноват. Но он сам же пишет, что на своем предыдущем месте работы также code review не использовался). В итоге приняли решение: перейти на Go и внедрить codereview (утрирую, а то Вы сейчас снова начнете бросаться фразами «где такое написано?!»). Ок, все получилось, все счастливы. Что же нам все таки помогло вылезти из ямы? Code review? Нет, конечно же это было Go ) Да, хороший тех лид, нечего сказать )
аккуратно пишет и о выборе технологий
Да он вообще никак не пишет о выборе технологии.
И в этот момент на сцену выходит Go
То ли его пчела ужалила, то ли он проводил недели бессонные пытаясь понять куда двигаться. Почему Go, почему не хаскел, почему не php, почему не 1С?! Поэтому не надо приписывать автору того, что он не говорил ;)
Да он вообще никак не пишет о выборе технологии.
Ну как же никак, если вся статья о выборе одной технологии и частичному отказу от другой?
Почему Go, почему не хаскел, почему не php, почему не 1С?! Поэтому не надо приписывать автору того, что он не говорил ;)
Автор описывал процесс, который уже свершился. Почему вы ожидаете от него табличного сравнения языков — мне не ясно.
Т.е. по сути они писали говнокод, никак его не контроллировали, все пошло под откос
Отсутствие системы код-ревью — это не совсем «говнокод». Тем более да, речь шла о компании, в которой он работал до этого. И, насколько я понимаю, spaceship operator — это фича языка. а не говнокод — как тут пытались уже сказать «а-ля вставить unicode-символ в код для диверсии». Это разные вещи.
Кстати, а вы у себя в компании какой системой контроля версий пользуетесь?
Ну как же никак, если вся статья о выборе одной технологии и частичному отказу от другой?
Да вот так. Выбор технологии это как минимум обоснование, а не:
И в этот момент на сцену выходит Go
Автор описывал процесс, который уже свершился. Почему вы ожидаете от него табличного сравнения языков — мне не ясно.
Так это Вы утверждаете, что автор:
аккуратно пишет и о выборе технологий
я же лишь Вам указал, что ни о каком выборе он не пишет. Лишь констатирует факт без обоснования.
Отсутствие системы код-ревью — это не совсем «говнокод». Тем более да, речь шла о компании, в которой он работал до этого. И, насколько я понимаю, spaceship operator — это фича языка. а не говнокод — как тут пытались уже сказать «а-ля вставить unicode-символ в код для диверсии». Это разные вещи.
И все таки отсутствие код-ревью в команде, которая пишет в разных стилях это почти диверсия.
Жаль, что вся дискуссия с Вами свелась к необходимости кидать цитаты, так как иначе Вы каждый раз утверждаете, что не говорили этого. В целом я понял Вашу точку зрения и не вижу необходимости переубеждать. Именно поэтому я и употребил термин «сектант Go», а не «программист на Go».
Теперь при найме разработчика он должен обладать навыками… и в go
Мы могли нанять практически любого программиста с разным бекграундом и знать, что он освоит Go за пару недель.
Плюс как раз в том, что можно брать человека вообще без опыта в Go и через несколько недель он уже сможет выдавать результаты.
А сколько из инициировавших разработчиков реально работало с Go в крупных проектах до этого?
Был выполнен тестовый проект. Наверняка не «Hello, world».
А так про любой язык, на котором реализовали крупный проект, можно сказать «а кто реально работал с * в крупных проектах?»
Мне вот больше интересно, а вопросов на ревью не возникло по поводу того кода на скала, что вызвал коллективный ступор?
ЗЫ не программист на скала.
ЗЫ не программист на скала.
О чем Вы вообще говорите, о каких еще хороших демонстрациях этой статьи!? Попытки рассуждать и делать выводы, опираясь на мнение какой-то одной компании(к тому же толком никому не известной) не есть хорошо.
По вашему в Twitter, Linkedin и других продуктах написанных на Scala работает 5 человек!? Да и посмотрите на Opensource проекты на Scala(какой там размер и количество контрибьюторов, для примера Spark например чекните) и не набрасывайте больше на вентилятор.
Там даже в комментах к оригиналу правильно люди пишут, что «команда» не удосужились почитать «scala best practices»… Налажали и побежали на новый язык. Мне почему то кажется, что они и когда на Scala переходили не понимали особо зачем им это надо, а просто поддались «тренду».
По вашему в Twitter, Linkedin и других продуктах написанных на Scala работает 5 человек!? Да и посмотрите на Opensource проекты на Scala(какой там размер и количество контрибьюторов, для примера Spark например чекните) и не набрасывайте больше на вентилятор.
Там даже в комментах к оригиналу правильно люди пишут, что «команда» не удосужились почитать «scala best practices»… Налажали и побежали на новый язык. Мне почему то кажется, что они и когда на Scala переходили не понимали особо зачем им это надо, а просто поддались «тренду».
Попытки рассуждать и делать выводы, опираясь на мнение какой-то одной компании(к тому же толком никому не известной) не есть хорошо.
Да ну, прислушиваться к опыту других — не есть хорошо? Уверен, если бы статья была о переходе с Go на Scala, вы бы сказали ровно наоборот.
По вашему в Twitter, Linkedin и других продуктах написанных на Scala работает 5 человек!?
Нет. С чего вы это взяли? Тем более, что автор упоминает, что эти компании столкнулись с теми же проблемами.
Мне почему то кажется, что они и когда на Scala переходили не понимали особо зачем им это надо, а просто поддались «тренду».
Вполне может быть. Но мне кажется, на тот момент, когда они выбирали Scala, это было вполне разумным решением. Но технологии меняются и прогрессируют, так что не вижу никакой проблемы в опыте этой компании.
>Но технологии меняются и прогрессируют
Хм… т.е. Go это прогресс по сравнению со Scala?
Хм… т.е. Go это прогресс по сравнению со Scala?
Только переход на Go это не прогресс, по крайней мере не в их случае. Это попытка прикрыть реальную проблему — менеджмент. Они начали писать на Scala без явного понимания, как это потом все поддерживать. Дошли до критической массы, когда проблемы уже не подъемные — перешли на Go. Последний никак не решает проблемы, которые есть у этой команды. Он лишь немного помогает в этом контексте, но в конечном итоге все проблемы этой команды приведут к тому, что и Go код они больше не смогут поддерживать. Опять переходить на что-то другое и переписывать с нуля? Или может додумаются, что проблема не в технологиях?
Только переход на Go это не прогресс, по крайней мере не в их случае.
Странно, а технический директор этой компании считает иначе. И раз уж мы заговорили о вопросах правильного менеджмента, спрошу, а у вас сколько максимальная команда была под вашим управлением?
Последний никак не решает проблемы, которые есть у этой команды.
А что решает? Расскажите.
Или может додумаются, что проблема не в технологиях?
Да нет, не додумаются. Куда им.
Странно, а технический директор этой компании считает иначе. И раз уж мы заговорили о вопросах правильного менеджмента, спрошу, а у вас сколько максимальная команда была под вашим управлением?
Аргумент «сначала добейся» начинает уже утомлять. Что не пост от вас, то одно и тоже.
А что решает? Расскажите.
Хороший менеджер.
Да нет, не додумаются. Куда им.
И я так думаю. Поэтому ждем, когда они разочаруются в Go и перейдут на новую модную технологию. Что у нас там на повестке дня?
И после таких комментариев вы еще кого-то упрекается за тон.
Тут скорее не аргумент «сначала добейся», а вопрос «какой у тебя опыт в рассматриваемом вопросе?». Нужно же понимать на сколько компетентен твой оппонент.
И после таких комментариев вы еще кого-то упрекается за тон.
Вас обидел вопрос о том, какой опыт у вас в вопрос менеджмента? Забавно.
Аргумент «сначала добейся» начинает уже утомлять. Что не пост от вас, то одно и тоже.
Причем тут «сначала добейся». Вы говорите о вещах, в которых практический очень важен. Говорите очень уверенно, поэтому резонно предположить, что вы не школьник, флудящий на хабре, а опытных тех. дир, который знает, что говорит, и имел опыт решения подобных организационных проблем методом «хорошего директора».
Поэтому ждем, когда они разочаруются в Go и перейдут на новую модную технологию.
Ждите, конечно. Тут в комментариях уже целая очередь ожидающих, пообщайтесь )
Хороший менеджер.
Я всё-таки попрошу вас не прятаться за фразами «у вас тут одно и то же», а рассказать, как именно нужно было решить проблему сплита и нарастающего эффекта сложности входа в проект с помощью Хорошего Менеджера, причем так, чтобы это было явно лучше перехода на Go. Желательно случай из личной практики, а не «мне так кажется». Спасибо.
Я знаю несколько хипстерокоманд, которые главным образом живут за счёт очередного инвестора, которому втюхали хрень про передовые технологии. И у них почему-то популярны Ruby/Scala/Go, да.
Там же написали почему ушли, в статье есть четкое перечисление почему они выбрали го, плюшек у го по сути и нет как таковых, у него строгость языка, простота языка, низкий порог входа. Время обучения одного человека и поддержка проекта стоит немалых денег, го (отнюдь не плюшками) в данной ситуации это решил. По сути и питон решил бы тоже их проблемы, возможно, но го быстрей, а им нужна была скорость.
А она и найдена. Под определенный тип задач руби с рельсами подходит ни чуть не хуже, чем пару лет назад.
И точно так же, как вы сейчас, адепты отвечали, что никакая это не мода и что серебрянная пуля наконец-то найдена
Зачем вы приписываете мне то, чего я не говорил, и даже более — говорил прямо противоположное?
Шум схож повод разный. Люди взрослеют и начинают понимать, что программы пишутся не для «уляля я знаю математику и программирование, а теперь моя программа математически доказуема, не трогай ее своими грязными руками невежда», а для других людей и чем проще она написана тем лучше. Т.е. от функциональности и сверх высокоуровневых абстракций обратно к простому народу. Конечно при этом го оперирует акторами прямо во всю но делает это максимально просто.
Конечно при этом го оперирует акторами прямо во всю но делает это максимально просто.
На dotGo'15 у Пайка был доклад как раз на эту тему — о том, как за простотой спрятана большая сложность, и баланс вот этого — что дать народу, а что спрятать под капотом — как раз самое важное и ключевое в дизайне языка.
www.youtube.com/watch?v=rFejpH_tAHM
Нет в Go никаких акторов. Модель акторов подразумевает first-class исполнители, обменивающиеся сообщениями адресно.
В Go CSP, где first-class объектами являются каналы, по которым исполнители обмениваются сообщениями.
В Go CSP, где first-class объектами являются каналы, по которым исполнители обмениваются сообщениями.
Хрен морковки слаще? Модель акторов это модель, писать в ее стиле и считать горутины акторами никто не мешает по сути ну и порождать горутины вполне можно и без каналов, каналы примитив для обмена данными между горутинами, да типа основной он, но это никак не мешает модели акторов.
Формально, конечно, особой разницы нет, потому что каналы легко выражаются через акторы, а акторы — чуть сложнее через каналы.
Фактически же разные подходы — читай, разные first-class citizens — приводят к разным решениям в итоге, и если сравнивать имеющиеся реализации, акторы все же выразительнее и позволяют иметь из коробки больше.
Фактически же разные подходы — читай, разные first-class citizens — приводят к разным решениям в итоге, и если сравнивать имеющиеся реализации, акторы все же выразительнее и позволяют иметь из коробки больше.
Хипстеры, это те люди которые с гордостью носят рубашки и очки в которых ходил мой дед? Тогда бейсик. Ну или PHP, на худой конец.
Мир мало меняется: посмотрите на место языков Scala и Go в рейтинге TIOBE. Это все действительно пока что хипстерские развлечения. Можно подумать, что перед наси первая в мире контора, которая выросла до двухсот человек.
TIOBE — это тот индекс, где считают количество поисковых запросов «LANG programming language»?
Ну да, главные хипстеры вроде Google, Dropbox и SpaceX только балуются. А серьезные гиганты рынка вроде rg software используют только правильные технологии с объективно правильным дизайном, ага.
Это все действительно пока что хипстерские развлечения.
Ну да, главные хипстеры вроде Google, Dropbox и SpaceX только балуются. А серьезные гиганты рынка вроде rg software используют только правильные технологии с объективно правильным дизайном, ага.
Жаль, что вы не в курсе метода определения рейтинга TIOBE, можете ознакомиться подробнее на досуге.
В любом случае, вы же не думаете, что именно такой гигант рынка как я, вывел все языки первой десятки TIOBE в первую десятку?
В этом рейтинге хорошо то, что его можно проследить хоть на 20 лет назад. Так вот, за последние десять лет в top 10 не изменилось решительно ничего (восемь из десяти языков те же). А если посмотреть на окрестности языков Scala и Go, вообще складывается очень интересная картинка реальной востребованности, моды и тому подобных вещей.
Кстати, если подскажете альтернативный рейтинг, основанный хоть на каких-то данных, буду очень благодарен.
В любом случае, вы же не думаете, что именно такой гигант рынка как я, вывел все языки первой десятки TIOBE в первую десятку?
В этом рейтинге хорошо то, что его можно проследить хоть на 20 лет назад. Так вот, за последние десять лет в top 10 не изменилось решительно ничего (восемь из десяти языков те же). А если посмотреть на окрестности языков Scala и Go, вообще складывается очень интересная картинка реальной востребованности, моды и тому подобных вещей.
Кстати, если подскажете альтернативный рейтинг, основанный хоть на каких-то данных, буду очень благодарен.
Жаль, что вы не в курсе метода определения рейтинга TIOBE, можете ознакомиться подробнее на досуге.
А чем мое понимание метода TIOBE отличается от описанного? Не считая, пропуска одного слова «результатов поисковых запросов». Проясните?
Так вот, за последние десять лет в top 10 не изменилось решительно ничего
И как это дает вам право игнорировать объективность и называть монстров рынка хипстерами?
Кстати, если подскажете альтернативный рейтинг, основанный хоть на каких-то данных, буду очень благодарен.
Есть некоторые попытки составить рейтинги по данным с гитхаба — githut.info
Есть занятный рейтинг от RedMonk — redmonk.com/sogrady/2015/07/01/language-rankings-6-15
А так да, задача довольно нетривиальная, но TIOBE довольно часто высмеивается за несерьезность. Тоесть он (как и другие рейтинги) может дать понимание, что C++ популярнее FORTRAN, но для более свежих языков мало что даст. Не говоря уже о том, что зачастую людям нужны не абсолютные цифры (скажем, учитывающие тонные legacy кода), а тренды.
Гитхаб — плохой показатель. Он показывает степень активности в опенсорсе людей, использующих тот или иной язык. Дотнетчики, например, традиционно в опенсорс не лезут и компоненты вместо этого пытаются продать.
Хорошо, будем считать, что мы оба понимаем методы TIOBE одинаково. Теперь про объективность. Объективность возможна только путём анализа численных данных. Слова вроде «монстры» или «хипстеры» ни о чём не говорят. Поэтому top 10 — это объективность, даже если методы расчёта рейтинга вам не нравятся. Предложите другой критерий, основанный на числах, а не разговорах.
«Тренды» (если опять обратиться к цифрам) ровно в том, что top 10 за последние десять лет более чем стабилен.
Гитхаб — интересно, хотя я вот им не пользуюсь. «Монстры рынка», кстати, тоже не пользуются (ну, выкладывают, может, чего-нибудь иногда в открытый доступ). RedMonk — тоже интересно, согласен, но всё же и эти ребята зачем-то ограничивают поиск сайтами Github и Stackoverflow. Довольно странно выбранный критерий, ну да их дело.
Я не то что бы сильно критикую, но просто как-то экстравагантно опираться на рейтинги, по сути сводящимися к кастрату TIOBE: те ищут двух десятках сайтах, а эти на двух. Возьмём уж тогда оригинал.
«Тренды» (если опять обратиться к цифрам) ровно в том, что top 10 за последние десять лет более чем стабилен.
Гитхаб — интересно, хотя я вот им не пользуюсь. «Монстры рынка», кстати, тоже не пользуются (ну, выкладывают, может, чего-нибудь иногда в открытый доступ). RedMonk — тоже интересно, согласен, но всё же и эти ребята зачем-то ограничивают поиск сайтами Github и Stackoverflow. Довольно странно выбранный критерий, ну да их дело.
Я не то что бы сильно критикую, но просто как-то экстравагантно опираться на рейтинги, по сути сводящимися к кастрату TIOBE: те ищут двух десятках сайтах, а эти на двух. Возьмём уж тогда оригинал.
Так, давайте вернемся к вашему изначальному комментарию. Вы сказали «мир мало меняется», опираясь на рейтинг TIOBE.
Тут я не согласен, так как мир меняется достаточно стремительно — ещё 10 лет не было айфонов и мобильного рынка приложений как класса, не было AWS, не было контейнеров, железо было дороже и медленее и тд и тп. Инструментарий меняется в ответ на меняющийся мир, и мне непонятно, почему так много людей вместо того, что развиваться, инвестировать в себя, изучать новые технологии, сидят на университетских знания и с пеной у рта доказывают, что их язык — единственный и неповторимый, а все остальное не нужно (это я об отдельных комментаторах выше). Вот често не понимаю.
Тут я не согласен, так как мир меняется достаточно стремительно — ещё 10 лет не было айфонов и мобильного рынка приложений как класса, не было AWS, не было контейнеров, железо было дороже и медленее и тд и тп. Инструментарий меняется в ответ на меняющийся мир, и мне непонятно, почему так много людей вместо того, что развиваться, инвестировать в себя, изучать новые технологии, сидят на университетских знания и с пеной у рта доказывают, что их язык — единственный и неповторимый, а все остальное не нужно (это я об отдельных комментаторах выше). Вот често не понимаю.
Вот для меня все эти айфоны и AWS ничего не меняют, потому что программирование — это процесс мышления прежде всего, а человеческий мозг мало меняется не только за десять, но и за сто лет.
Я же не против развития языков и технологий. Пусть появляются новые средства, скажем, для меня это Python, который я стал осваивать уже в достаточно зрелом возрасте.
Меня расстраивает, что каждый раз нам предлагают старое средство в новой обложке: вот, простота, трудно написать откровенный шлак, обезьяна освоит. Ну что, у человечества память как у золотых рыбок? Ведь и Fortran, и Basic приходили ровно с той же риторикой. И это неплохо, но ничего нового, а главное — не это ключ к хорошему и качественному будущему.
Инвестировать в себя нужно, но вот делать это правильно мало кто хочет. А я бы сказал, что чем выучить десять языков, надо взяться за два и освоить их досконально, вот от корки до корки. Ну как с иностранными языками: да, хорошо, что я могу в кафе и такси объясниться на десяти языках, но всё-таки для реального дела нужны знания совершенно иного масштаба. И в этом смысле мне кажется, что ценен специалист, который полностью владеет своим инструментом. А если владеет, то вопрос инструмента уже глубоко вторичен.
И данная статья тоже описывает печальную реальность. ОК, ребята, вы не знаете, что такое starship operator в Scalaz. Ну а на черта вы тогда в это дело влезли? Пользуйтесь теми инструментами, в которых разбираетесь, ё-моё…
Я же не против развития языков и технологий. Пусть появляются новые средства, скажем, для меня это Python, который я стал осваивать уже в достаточно зрелом возрасте.
Меня расстраивает, что каждый раз нам предлагают старое средство в новой обложке: вот, простота, трудно написать откровенный шлак, обезьяна освоит. Ну что, у человечества память как у золотых рыбок? Ведь и Fortran, и Basic приходили ровно с той же риторикой. И это неплохо, но ничего нового, а главное — не это ключ к хорошему и качественному будущему.
Инвестировать в себя нужно, но вот делать это правильно мало кто хочет. А я бы сказал, что чем выучить десять языков, надо взяться за два и освоить их досконально, вот от корки до корки. Ну как с иностранными языками: да, хорошо, что я могу в кафе и такси объясниться на десяти языках, но всё-таки для реального дела нужны знания совершенно иного масштаба. И в этом смысле мне кажется, что ценен специалист, который полностью владеет своим инструментом. А если владеет, то вопрос инструмента уже глубоко вторичен.
И данная статья тоже описывает печальную реальность. ОК, ребята, вы не знаете, что такое starship operator в Scalaz. Ну а на черта вы тогда в это дело влезли? Пользуйтесь теми инструментами, в которых разбираетесь, ё-моё…
Вот для меня все эти айфоны и AWS ничего не меняют, потому что программирование — это процесс мышления прежде всего, а человеческий мозг мало меняется не только за десять, но и за сто лет.
Вот и напрасно, потому что мышление — это абстракции в мозгу, а не конкретные инструменты, и люди, которые застряют на одном инструменте, остаются неизбежно позади.
Меня расстраивает, что каждый раз нам предлагают старое средство в новой обложке: вот, простота, трудно написать откровенный шлак, обезьяна освоит.
Не очень понимаю, почему вас это расстраивает. Так развивалась инженерная мысль с самого начала. Решались задачи, люди искали способ уменьшить «привнесенную сложность», придумывали новое, внедряли, реагировали на новые проблемы и сложности, которые появились взамен, искали или улучшали способы и так далее. В купе с тем, как меняется мир, этот процесс достаточно естественный и интересный.
Сейчас эпоха облаков, других скоростей разработки и аггрегированного опыта уже нескольких поколений программистов. Будет неверно считать, что ничего не меняется и не должно меняться. Сейчас важно уметь уже не биты ксорить, а строить распределенные системы, и понимать отличие CP от AP. Или, к примеру, еще 15 лет нормального тестирования не было в принципе ни в одной компании, а сейчас уже язык без встроенного тулинга для тестов считается неполноценным.
И данная статья тоже описывает печальную реальность. ОК, ребята, вы не знаете, что такое starship operator в Scalaz. Ну а на черта вы тогда в это дело влезли? Пользуйтесь теми инструментами, в которых разбираетесь, ё-моё…
Реальность такова как есть, печальность привносите вы :)
Вот я как раз печальность не привношу — я именно за то, чтобы люди пользовались инструментами, которыми хорошо владеют. Тогда и печали не будет. Знаете, в учебниках любили анализировать, какого рода ошибки программисты совершают чаще всего. Вот такое впечатление, что современный мир — это не про облака и другие скорости разработки, а про некомпетентность. Если почитать чужой код (приходится...), то оказывается, что 90% ошибок — это не классические ошибки логики или ошибки по невнимательности, а банальное незнание азов собственного инструментария.
Так что какие уж тут скорости разработки, право слово. Быстро разрабатываем, потом ещё неделю разгребаем тот ужас, что люди понаписали.
Так что какие уж тут скорости разработки, право слово. Быстро разрабатываем, потом ещё неделю разгребаем тот ужас, что люди понаписали.
Если бы все было как вы хотите, то сидели бы все на асемблере или с, ибо «люди пользовались инструментами, которыми хорошо владеют» зачем учить что-то новое, если я итак хорошо владею этим. И вообще я рад что вы ошибаетесь практически на всей ветке :) Консерваторы хороши лишь на больших проектах, и после окончания таких проектов они должны всю жизнь поддерживать их, а молодым путь в новые сферы.
Почему вы думаете, что я ошибаюсь? По крайней мере, я пытаюсь хоть как-то обосновывать свою логику, а не просто раздавать эпитеты.
.
Про «людей, сидящих на ассемблере» вы хватили уж совсем далеко — Фортран уже в пятидесятых годах существовал.
Разговоры про «консерваторов» и «молодых» — это вообще та ещё глупость. Нам постоянно ведь говорят, что инструмент это всего лишь инструмент, и не надо делать из него религии. Ну так давайте же и не делать, почему люди не хотят следовать своим рецептам?
Вот представьте, что я владею инструментом Х, и рассчитываю, что могу написать на нём некий проект за десять месяцев. Теперь вот есть новый инструмент Y, на освоение которого уйдёт год (будем реалистами, это крайне оптимистичная оценка), но затем я смогу справиться уже не за десять месяцев, а за восемь за счёт более высокой продуктивности (не надо предлагать мне увеличить продуктивность вдвое, это будет откровенное враньё).
Сколько проектов мне нужно закончить, чтобы получить выгоду от нового знания? Это не консерватизм, это абсолютно рациональное поведение. А если человек ещё ничего не умеет, и выбирает первую/вторую/третью для себя технологию, то ему тоже надо руководствоваться не какими-то абстрактно высокими соображениями, а мыслями о том, какая технология его сможет прокормить.
Пусть это будет что угодно, хоть Smalltalk, лишь бы он видел для себя будущее в этой области.
.
Про «людей, сидящих на ассемблере» вы хватили уж совсем далеко — Фортран уже в пятидесятых годах существовал.
Разговоры про «консерваторов» и «молодых» — это вообще та ещё глупость. Нам постоянно ведь говорят, что инструмент это всего лишь инструмент, и не надо делать из него религии. Ну так давайте же и не делать, почему люди не хотят следовать своим рецептам?
Вот представьте, что я владею инструментом Х, и рассчитываю, что могу написать на нём некий проект за десять месяцев. Теперь вот есть новый инструмент Y, на освоение которого уйдёт год (будем реалистами, это крайне оптимистичная оценка), но затем я смогу справиться уже не за десять месяцев, а за восемь за счёт более высокой продуктивности (не надо предлагать мне увеличить продуктивность вдвое, это будет откровенное враньё).
Сколько проектов мне нужно закончить, чтобы получить выгоду от нового знания? Это не консерватизм, это абсолютно рациональное поведение. А если человек ещё ничего не умеет, и выбирает первую/вторую/третью для себя технологию, то ему тоже надо руководствоваться не какими-то абстрактно высокими соображениями, а мыслями о том, какая технология его сможет прокормить.
Пусть это будет что угодно, хоть Smalltalk, лишь бы он видел для себя будущее в этой области.
Это не консерватизм, это абсолютно рациональное поведение.
Это рациональный консерватизм — пессимистичные оценки затрат ресурсов и выгоды от них.
Да ради бога, если мне предоставят другие оценки, я за них радостно ухвачусь. Любой из нас хочет работать эффективнее и не тратить часы на ерунду. Некоторые вещи самоочевидны (визуальный html редактор против ручного написания html тегов в тексте), но вот с языками программирования далеко не всё так просто.
Как писал Брукс, если бы хоть один язык давал гарантированно 5% прироста производительности по сравнению с конкурентами, все бы уже на нём сидели.
Как писал Брукс, если бы хоть один язык давал гарантированно 5% прироста производительности по сравнению с конкурентами, все бы уже на нём сидели.
Я согласен с основной вашей мыслью, что нужно быть профессионалом хоть в чём-то, а не просто прыгать с цветочка на цветочек. Но я так же согласен и с тем, что оценки нужно делать не опираясь на оптимизм или пессимизм.
Здесь очень много лукавства. Блокнот можно изучить за пару минут. А, например, если действительно интересен Python, то можно уже через пару месяцев изучения что-нибудь вроде этого писать (я этот код написал примерно через полтора месяца после того, как начал учить Python):
Я просто не знаю ни одного конкретного инструмента, который называется Y (Yorick? YQL?). Тяжело быть реалистом, когда не идёт речь о чём-то конкретном, что можно реально взять и оценить. В этом случае действительно получаются пессимистичные оценки, которые, если подумать, не имеют связи с реальностью, ведь вы в своё оправдание приводите ситуацию, которую сами же и придумали — ситуацию, которая подогнана под ваши слова.
В остальном, если углубиться в смысл явлений, инструменты остаются инструментами. В первую очередь лучше учить логику, математику и что-нибудь ещё (сопромат, например, который помогает оценивать материалы в зависимости от их характеристик). Если без этого фундамента начинать учить свой первый язык программирования, то он наложит отпечаток на всю оставшуюся карьеру и будет мешать думать правильно. Например, будет заставлять делать пессимистичные оценки в отношении языков, которые от него отличаются.
И вообще, тут есть какой-то трудноопределимый баланс. Плохо прыгать с языка на язык, потому что это в итоге станет похоже на жировые отложения — лишний, ненужный вес, который мешает летать. Но так же плохо замыкаться на одной единственной технологии, потому что в определённый момент развитие просто остановится. Главное — не впадать в крайности, отстаивая свою точку зрения.
Теперь вот есть новый инструмент Y, на освоение которого уйдёт год (будем реалистами, это крайне оптимистичная оценка)
Здесь очень много лукавства. Блокнот можно изучить за пару минут. А, например, если действительно интересен Python, то можно уже через пару месяцев изучения что-нибудь вроде этого писать (я этот код написал примерно через полтора месяца после того, как начал учить Python):
Скрытый текст
(lambda _: globals().__setitem__(_.lower().translate(dict(enumerate(('_', None),
1<<5))), lambda: _))((lambda _: ''.join([chr(int(''.join([len(s).__str__() for s
in''.join(_.split()).split('O')][i:i+15:5]))-111)for i in range(4,210,15)]))("""
0O0O0O0O0O0O0O0O0 O000 00000O0O0O
0O0O0000O0O0O0O0O0 O0O0O0 O0O0000O0O0
O0O0 O00 0O0 O0O 0O0 O00
O0O0 O0O 0O0 O0O 0O0O0O0000
0000 0O0 O0O0O0O00O0O 0O0 O0O0
0O0O0O0O0O00 O0O 0O0O0O00O0O0O0 O0O 00O0O0O0O0O0
00000000O0O 0O0 O0O0 0O0O 0O0 O0O0O0O0O0O
0O00O OO0O 0O0O0 O0O0 O0O0000O0O OO0O000O0O
0O0O0 O0O0O0 O0O0O 000000 000O0OO0O0O 0O0O0O0O0O0
0O0O0O0O0O000O0O OO0 O00 O0O 0O0 O0O00
O0O0O0OO00O0O0 O0O O00 00000O0O0O 0O0O0
0O0O0 O0O0O 0O0O0O0O0O00 000 O0O0 O0O0O
00O OOO O00OO0OO0O00OO OOO 00O0OOOO00OOOOO0
O O OOO0 OOOO O00 00OO0O0O0O0000
"""))
Я просто не знаю ни одного конкретного инструмента, который называется Y (Yorick? YQL?). Тяжело быть реалистом, когда не идёт речь о чём-то конкретном, что можно реально взять и оценить. В этом случае действительно получаются пессимистичные оценки, которые, если подумать, не имеют связи с реальностью, ведь вы в своё оправдание приводите ситуацию, которую сами же и придумали — ситуацию, которая подогнана под ваши слова.
В остальном, если углубиться в смысл явлений, инструменты остаются инструментами. В первую очередь лучше учить логику, математику и что-нибудь ещё (сопромат, например, который помогает оценивать материалы в зависимости от их характеристик). Если без этого фундамента начинать учить свой первый язык программирования, то он наложит отпечаток на всю оставшуюся карьеру и будет мешать думать правильно. Например, будет заставлять делать пессимистичные оценки в отношении языков, которые от него отличаются.
И вообще, тут есть какой-то трудноопределимый баланс. Плохо прыгать с языка на язык, потому что это в итоге станет похоже на жировые отложения — лишний, ненужный вес, который мешает летать. Но так же плохо замыкаться на одной единственной технологии, потому что в определённый момент развитие просто остановится. Главное — не впадать в крайности, отстаивая свою точку зрения.
Хорошо, давайте тогда поговорим о технологии, которая называется «язык программирования общего назначения». Я настаиваю, что быстрее, чем за год нельзя освоить ни один новый язык программирования общего назначения на более-менее профессиональном уровне. Чтобы просто писать не задумываясь, а не нырять в справочник каждые пять минут.
То, что приведённый код на Питоне можно накатать через два месяца обучения — верю легко, но меня интересует именно профессиональная разработка ПО, а не упражнения в однострочниках.
То, что приведённый код на Питоне можно накатать через два месяца обучения — верю легко, но меня интересует именно профессиональная разработка ПО, а не упражнения в однострочниках.
Я настаиваю, что быстрее, чем за год нельзя освоить ни один новый язык программирования общего назначения на более-менее профессиональном уровне. Чтобы просто писать не задумываясь, а не нырять в справочник каждые пять минут.
У вас есть какие-то фактические выкладки? Если нет, мы можем провести эксперимент, но я попрошу оплатить моё время. Это примерно 96 тысяч долларов.
Я не думаю, что этот эксперимент поможет, потому что в лучшем случае это докажет исключительно вашу личную способность к такому скоростному обучению.
А какого рода выкладки вас могут устроить хотя бы в теории? Желательно, чтобы они не требовали нереальных денег и ресурсов с моей стороны.
А какого рода выкладки вас могут устроить хотя бы в теории? Желательно, чтобы они не требовали нереальных денег и ресурсов с моей стороны.
Для примера, носитель английского активно использует около 40 000 слов в речи. Я понимаю под носителем того, для кого он является родным (и такой человек, получается, является, в некотором роде, профессионалом в своём языке). По данным languagemonitor на 1 января 2014-го в английском языке было больше миллиона слов. Получается, что для профессионализма нужно обладать словарным запасом примерно в 4 процента от общего количества слов.
По аналогии с этим, можно взять количество слов в языке программирования (включая сюда названия функций и классов стандартной библиотеки), выкинуть операторы (так как они являются знаками препинания) и выбрать 4% самых используемых (например, воспользовавшись данными из API Github в качестве отправной точки). Получится количество слов, которое нужно изучить для того, чтобы не лазать постоянно всловарь документацию, когда пишешь на этом языке.
Далее, по непроверенным данным, человек, изучая английский, может запоминать до 5-10 слов в день. Если распространить это на изучение языка программирования, то эти 4% слов нужно будет разделить на 5 и мы получим количество дней, нужное для запоминания профессионального словарного запаса.
Вот, примерно так я бы оформлял мысли, когда мне нужно было бы на чём-то настаивать.
По аналогии с этим, можно взять количество слов в языке программирования (включая сюда названия функций и классов стандартной библиотеки), выкинуть операторы (так как они являются знаками препинания) и выбрать 4% самых используемых (например, воспользовавшись данными из API Github в качестве отправной точки). Получится количество слов, которое нужно изучить для того, чтобы не лазать постоянно в
Далее, по непроверенным данным, человек, изучая английский, может запоминать до 5-10 слов в день. Если распространить это на изучение языка программирования, то эти 4% слов нужно будет разделить на 5 и мы получим количество дней, нужное для запоминания профессионального словарного запаса.
Вот, примерно так я бы оформлял мысли, когда мне нужно было бы на чём-то настаивать.
Я понимаю под носителем того, для кого он является родным (и такой человек, получается, является, в некотором роде, профессионалом в своём языке).
В этом месте у вас ошибка. Между носителем языка и профессионалом в его (языка) употреблении гигантская пропасть, хорошо видная по существованию таких профессий как «редактор» и «корректор».
По аналогии с этим, можно взять количество слов в языке программирования (включая сюда названия функций и классов стандартной библиотеки), выкинуть операторы (так как они являются знаками препинания) и выбрать 4% самых используемых (например, воспользовавшись данными из API Github в качестве отправной точки).
И снова, аналогия неверна. В естественных языках гигантская избыточность (именно поэтому так мало отношение активного вокабуляра к общему корпусу), а в языках программирования она меньше на порядки (и отличается в зависимости от языка), поэтому выбирать вам придется не единицы процентов, а десятки.
Далее, по непроверенным данным, человек, изучая английский, может запоминать до 5-10 слов в день. Если распространить это на изучение языка программирования, то эти 4% слов нужно будет разделить на 5 и мы получим количество дней, нужное для запоминания профессионального словарного запаса.
Вы, конечно же, знаете, что помимо словарного запаса есть еще грамматика (управление), словоупотребление, идиомы, стилистика и еще много мелочей, которые отличают человека, знающего язык, от человека, который выучил словарь? Ровно то же самое и с языками программирования.
Для изучения (естественного) языка нужна практика. Много практики. Причем практики, ориентированной на тот род деятельности, который ожидается (в IELTS, скажем, четыре разных экзамена — Listening, Speaking, Reading, Writing). Ровно то же самое возникает при изучении языка программирования: одно дело научиться его читать, другое дело — научиться его писать (кстати, навык письма еще не подразумевает навыка чтения, как ни странно). Как вы собираетесь оценивать необходимые для этого часы?
PS С одной стороны, приравнивать операторы к знакам препинания неверно, потому что в языках программирования операторы имеют существенно большее значение, нежели знаки препинания в языках естественных. А с другой стороны, не надо выкидывать знаки препинания из естественных языков, если вы не хотите однажды быть застреленным пандой.
В этом месте у вас ошибка. Между носителем языка и профессионалом в его (языка) употреблении гигантская пропасть, хорошо видная по существованию таких профессий как «редактор» и «корректор».
Но, всё же, этот человек разговаривает на более или менее профессиональном уровне, ведь ему не приходится каждые пять минут заглядывать в словарь. Это очень важный момент, так как я эти формулироваки использовал из-за отдельных фраз в предыдущих комментариях. Просто мне хотелось бы обратить ваше внимание, что такие формулировки изначально не у меня появились — я просто их принял.
Вы логично всё описываете, но я, в общем-то показывал, как можно перейти от выражения «быстрее, чем за год нельзя освоить ни один новый язык программирования общего назначения на более-менее профессиональном уровне» к выражению «новый язык программирования можно изучить примерно за X дней» — в этом выражении немного больше фактов, чем в первом. И его можно уточнять в деталях, получая более точный вариант в итоге. Я не давал точные цифры — просто ход мыслей, который позволяет хоть какую-то привязку сделать.
Но, всё же, этот человек разговаривает на более или менее профессиональном уровне,
Нет. Вы путаете «профессионально» и «без словаря». Это совершенно разные вещи (для естественного языка). Впрочем, для языка программирования — тоже: знание документации еще не достаточно для того, чтобы профессионально программировать (более того, и не необходимо).
Я не давал точные цифры — просто ход мыслей, который позволяет хоть какую-то привязку сделать.
К сожалению, ваш ход мысли ошибочен почти во всех своих пунктах. Правильный, на мой взгляд, ход мысли здесь называется «программа курса», благо ровно для этого они и придуманы — дать организации предсказуемые сроки и результаты.
Впрочем, есть и более простой подход: «правило» десяти тысяч часов.
Нет. Вы путаете «профессионально» и «без словаря».
Вы не совсем поняли мою мысль. Я вам процитирую того человека, который это определение ввёл.
на более-менее профессиональном уровне. Чтобы просто писать не задумываясь, а не нырять в справочник каждые пять минут.
Я, как я выше написал, просто принял такую формулировку, чтобы не скатываться в тысячу постов с выяснением истинности каждого слова.
Согласен, программа курса позволяет дать привязку точнее. :)
Я, как я выше написал, просто принял такую формулировку, чтобы не скатываться в тысячу постов с выяснением истинности каждого слова.
Эта формулировка неверна ни для естественного языка, ни для языка программирования. Как следствие, принимать ее за основу бессмысленно.
Я думал, мне не придётся пояснять, что программист — это не тот, кто без проблем читает код, но и тот, кто пишет. Обычному носителю языка редко приходится сочинять даже на родном языке более-менее внятные тексты. А программисту приходится, что подразумевает активное владение, а не пассивное, что требует совсем иных усилий.
Если требуется только читать и комментировать код — да какие проблемы, я так с десяток языков знаю весьма неплохо. Но на профессиональном активном уровне всё куда скромнее.
Если требуется только читать и комментировать код — да какие проблемы, я так с десяток языков знаю весьма неплохо. Но на профессиональном активном уровне всё куда скромнее.
К сожалению, ваши выкладки относительно естественного языка уже неверны: помимо активного запаса вам абсолютно необходим пассивный запас, который, по крайней мере, на порядок выше. Вряд ли вы активно используете слова вроде гнедая или форзац, однако представляете себе значения этих слов. Кроме того, помимо слов важны сочетания: важно понимать, что «морская свинка» и «свинка» — это совершенно разные вещи, никак не связанные между собой, а количество сочетаний уж совсем несравнимо с количеством слов. Таким же образом абсолютно неверно сводить изучение языка к изучению словаря.
Кстати, для естественных языков подобные выкладки имеются. Например, чтобы изучить английский на уровне C2 (а это по сути и есть профессиональное использование), потребуется 700-800 часов обучения с учителем, можете попробовать прикинуть, сколько лет жизни это в реалистичных условиях (ну и понятно, что 16 часов в день учиться бессмысленно, организм столько не вынесет).
Так что если бы я и в самом деле взялся за выкладки, то подошёл бы с другого конца: берём приличный учебник по языку (из списка рекомендованных в каком-нибудь достойном вузе), заставляем человека выполнить хотя бы 3/4 домашних заданий, затем написать хотя бы один полноценный проект (не слишком большой, но полноценный). Вот это мне кажется больше похоже на правду.
Кстати, для естественных языков подобные выкладки имеются. Например, чтобы изучить английский на уровне C2 (а это по сути и есть профессиональное использование), потребуется 700-800 часов обучения с учителем, можете попробовать прикинуть, сколько лет жизни это в реалистичных условиях (ну и понятно, что 16 часов в день учиться бессмысленно, организм столько не вынесет).
Так что если бы я и в самом деле взялся за выкладки, то подошёл бы с другого конца: берём приличный учебник по языку (из списка рекомендованных в каком-нибудь достойном вузе), заставляем человека выполнить хотя бы 3/4 домашних заданий, затем написать хотя бы один полноценный проект (не слишком большой, но полноценный). Вот это мне кажется больше похоже на правду.
Если укладывать 800 часов в год, то получится примерно 14 часов в неделю — два часа в день. Если делать перерыв в выходные — три часа в день пять дней в неделю.
Выглядит как лёгкая прогулка. К тому же, вы в этой цифре учли всё: и основы языка и построение предложений и т.п.
Выглядит как лёгкая прогулка. К тому же, вы в этой цифре учли всё: и основы языка и построение предложений и т.п.
Выглядит как лёгкая прогулка.
Только выглядит.
Впрочем, что важнее, это 800 (1200) часов занятий с учителем. «Принято считать», что для того, чтобы это было эффективно, нужно еще два раза по столько (или хотя бы столько же) самостоятельных занятий.
Год фулл-тайм. Если выдержите (на самом деле, если вспомните обучение в ВУЗе — поймете, что не выдержите).
Я всё так же считаю, что 800 часов в год — это примерно 14 часов в неделю — два часа в день. Выглядит лёгкой прогулкой. Если судить по моему опыту (по таймшитам у меня в этом году чуть меньше 400 часов обучения) это вообще не напряжно. Даже если бы время возросло в два раза — до пресловутых 800 часов, вряд ли бы это стало чем-то больше, чем лёгкая прогулка.
Согласен с вашими выводами, что фулл-тайм учёба — это тяжело. Понимаю, почему вы выделяете выражение «принято считать» в кавычки — я похожее соотношение только в информации об американских колледжах видел, и то только в ситуации с лекционными занятиями. Лабораторные занятия домашней работой не сопровождаются.
Если же брать ситуацию с ВУЗом, в Министерстве образования пишут, что соотношение должно быть 70% (с преподавателем) к 30% (самостоятельные занятия). Если ваши 1200 часов применить к российской системе образования, то получится 1560 часов. Либо это будет фулл-тайм в течение 9-ти месяцев, либо год с загрузкой 5-6 часов в день. Не год фулл-тайма.
А если перейти к реалиям — ближе к ситуации, о которой шла речь с самого начала (когда человеку, знающему язык программирования X, нужно выучить язык Y), не вижу ни одной причины тратить тысячу часов на занятия с учителем. Чему учитель будет учить человека, который и так программирует? Впустую ему читать лекции по программированию? Он и так умеет. Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию — всё. У меня подобное заняло примерно 3 месяца, когда я учил Python. Сделаем скидку на мою «гениальность» и увеличим срок в два раза — шесть месяцев на изучение нового языка. Вы хотя бы раз учили новый язык программирования (не программирование с нуля, а новый язык программирования — в дополнение к уже изученным)? Вам требовался год на это? Вам требовался учитель, который вам 1200 часов выдержки из документации декламировал или вас морально поддерживал, типа: «ну, не пугайся, давай, допиши ещё ввод из STDIN»?
Согласен с вашими выводами, что фулл-тайм учёба — это тяжело. Понимаю, почему вы выделяете выражение «принято считать» в кавычки — я похожее соотношение только в информации об американских колледжах видел, и то только в ситуации с лекционными занятиями. Лабораторные занятия домашней работой не сопровождаются.
Если же брать ситуацию с ВУЗом, в Министерстве образования пишут, что соотношение должно быть 70% (с преподавателем) к 30% (самостоятельные занятия). Если ваши 1200 часов применить к российской системе образования, то получится 1560 часов. Либо это будет фулл-тайм в течение 9-ти месяцев, либо год с загрузкой 5-6 часов в день. Не год фулл-тайма.
А если перейти к реалиям — ближе к ситуации, о которой шла речь с самого начала (когда человеку, знающему язык программирования X, нужно выучить язык Y), не вижу ни одной причины тратить тысячу часов на занятия с учителем. Чему учитель будет учить человека, который и так программирует? Впустую ему читать лекции по программированию? Он и так умеет. Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию — всё. У меня подобное заняло примерно 3 месяца, когда я учил Python. Сделаем скидку на мою «гениальность» и увеличим срок в два раза — шесть месяцев на изучение нового языка. Вы хотя бы раз учили новый язык программирования (не программирование с нуля, а новый язык программирования — в дополнение к уже изученным)? Вам требовался год на это? Вам требовался учитель, который вам 1200 часов выдержки из документации декламировал или вас морально поддерживал, типа: «ну, не пугайся, давай, допиши ещё ввод из STDIN»?
По правде говоря, я вот сейчас наступлю на горло собственной песне, но вот эти цифры «800 часов» мне самому кажутся слишком оптимистичными. Посмотрите, сколько лет мы учим родной язык в школе, и всё равно когда дело доходит до сочинения даже простеньких текстов, у людей уже возникают проблемы.
Сам я имел опыт изучения финского языка на групповых курсах в похожем интенсивном режиме: 4 часа в день плюс домашние задания пять дней в неделю. Это было очень утомительно, и по факту (это уже не личный опыт, а более-менее объективная статистика) считалось хорошим результатом за три семестра человека натаскать на средний уровень государственного экзамена (а это вовсе не уровень C2, а гораздо слабее).
Впрочем, мы и в представлении о компьютерных языках расходимся: «Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию» — ну и какой смысл тогда в изучении нового языка? Это же получается по старому выражению о том, что программу в стиле Фортрана можно написать на любом языке. Ясное дело, если вы учите старый язык в новой обложке, и трёх месяцев хватит. Суть же в том, чтобы на спинномозговом уровне освоить новый принцип написания программ, а пока он не освоен, то смысла в этом образовании мало — работайте тогда со старым языком, всё равно удобнее.
Сам я имел опыт изучения финского языка на групповых курсах в похожем интенсивном режиме: 4 часа в день плюс домашние задания пять дней в неделю. Это было очень утомительно, и по факту (это уже не личный опыт, а более-менее объективная статистика) считалось хорошим результатом за три семестра человека натаскать на средний уровень государственного экзамена (а это вовсе не уровень C2, а гораздо слабее).
Впрочем, мы и в представлении о компьютерных языках расходимся: «Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию» — ну и какой смысл тогда в изучении нового языка? Это же получается по старому выражению о том, что программу в стиле Фортрана можно написать на любом языке. Ясное дело, если вы учите старый язык в новой обложке, и трёх месяцев хватит. Суть же в том, чтобы на спинномозговом уровне освоить новый принцип написания программ, а пока он не освоен, то смысла в этом образовании мало — работайте тогда со старым языком, всё равно удобнее.
Вообще, C2 — это 1200 часов, а не 800 (это для C1 нужно столько часов). Я просто не стал поправлять чуть раньше, чтобы не отвлекаться.
Я думаю, человек, которому не хочется учить новый язык программирования или технологию, найдёт тысячу причин, которые подтвердят, что это очень сложно, очень долго и по временным затратам не оправданно. Я тоже так делаю.
В любом случае, для меня этот разговор был очень полезным. Спасибо. :)
Я думаю, человек, которому не хочется учить новый язык программирования или технологию, найдёт тысячу причин, которые подтвердят, что это очень сложно, очень долго и по временным затратам не оправданно. Я тоже так делаю.
В любом случае, для меня этот разговор был очень полезным. Спасибо. :)
Спасибо и вам :)
Ну с одной стороны да, тысяча причин, с другой стороны как объективно оценить, стоит оно того или нет? Я ведь по сути поднимаю эту дискуссию, но стопроцентно обоснованных ответов у меня нет.
Если бы были готовые ответы — занимает столько-то времени, сэкономит столько-то. А так одно гадание получается.
Ну с одной стороны да, тысяча причин, с другой стороны как объективно оценить, стоит оно того или нет? Я ведь по сути поднимаю эту дискуссию, но стопроцентно обоснованных ответов у меня нет.
Если бы были готовые ответы — занимает столько-то времени, сэкономит столько-то. А так одно гадание получается.
(Я боюсь, что наше основное разногласие — в критериях профессионального владения)
Завидую. У меня учебная нагрузка за последний год была меньше, а сил на нее ушло больше.
Это верно не для всех предметов (особенно учитывая, что то, куда вы ссылаетесь — это не рекомендация и не норматив, а просто объяснение, что такое «очная форма») и не для всех форм обучения.
А вы не задумывались о том, что «мои» (на самом деле — кембриджские) 1200 часов расчитаны на конкретную систему образования?
То есть вы считаете, что языки друг от друга отличаются только синтаксисом?
Учил. Но ни одним из тех, которые я учил за последние пару лет, я не владею профессионально.
Год нужен не на это. Год нужен на то, чтобы набрать опыта с разнородными задачами.
Если судить по моему опыту (по таймшитам у меня в этом году чуть меньше 400 часов обучения) это вообще не напряжно. Даже если бы время возросло в два раза — до пресловутых 800 часов, вряд ли бы это стало чем-то больше, чем лёгкая прогулка.
Завидую. У меня учебная нагрузка за последний год была меньше, а сил на нее ушло больше.
Если же брать ситуацию с ВУЗом, в Министерстве образования пишут, что соотношение должно быть 70% (с преподавателем) к 30% (самостоятельные занятия).
Это верно не для всех предметов (особенно учитывая, что то, куда вы ссылаетесь — это не рекомендация и не норматив, а просто объяснение, что такое «очная форма») и не для всех форм обучения.
Если ваши 1200 часов применить к российской системе образования, то получится 1560 часов.
А вы не задумывались о том, что «мои» (на самом деле — кембриджские) 1200 часов расчитаны на конкретную систему образования?
Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию — всё.
То есть вы считаете, что языки друг от друга отличаются только синтаксисом?
Вы хотя бы раз учили новый язык программирования (не программирование с нуля, а новый язык программирования — в дополнение к уже изученным)?
Учил. Но ни одним из тех, которые я учил за последние пару лет, я не владею профессионально.
Вам требовался год на это?
Год нужен не на это. Год нужен на то, чтобы набрать опыта с разнородными задачами.
(Я боюсь, что наше основное разногласие — в критериях профессионального владения)
Я думаю, вы просто в какой-то момент по инерции начали думать, что я называю профессиональным владением ситуацию, когда человек не лазает в документацию. Я повторюсь, иногда я считаю, что можно не придираться к словам человека, чтобы перейти к сути и не плодить слишком много текста. У каждого человека своё видение того, что значит профессионализм. На тот момент, я услышал, что одним из граничных условий является: «на более-менее профессиональном уровне. Чтобы просто писать не задумываясь, а не нырять в справочник каждые пять минут». У меня эта фраза не вызывает достаточно отторжения, чтобы тыкать человека в его ошибки. Зато она добавляет конкретики, на которую можно опираться. В противном случае, мы с ним ещё пару дней бы спорили, что такое «профессиональное владение» — и это была бы пустая трата времени. Это не позволило бы сразу взять и начать что-то оценивать.
То есть вы считаете, что языки друг от друга отличаются только синтаксисом?
Языки программирования отличаются синтаксисом и словами, которые в них есть. Остальные различия — в прокладке между стулом и монитором. Опытная прокладка найдёт тысячу способов сделать код лучше, используя особенности синтаксиса и подбирая правильные слова. К этому вполне можно всё свести. С другой стороны, можно усложнять любые явления до бесконечности, вводя дополнительные абстракции вроде pythonic way и т.п. — хотя это всё, опять же, является свойствами программиста, а не языка программирования. Сами подумайте, вы понимаете, что программа написана на конкретном языке программирования, когда видите её исходный код — синтаксис и слова. Какие ещё нужны признаки, чтобы отличить один язык от другого?
Какие ещё нужны признаки, чтобы отличить один язык от другого?
Идиомы, очевидно.
Какие ещё нужны признаки, чтобы отличить один язык от другого?
Тематический (к посту) пример:
Go-way:
n, err := io.ReadFull(c, byteArr)
Возьмем другой язык. Вот так будет, если просто «заменить синтаксис и слова»:
let (n, err) = io.ReadFull(b, byteArr)
А вот так — если писать идиоматично:
match io.ReadFull(b, byteArr) with | Success(n) -> ... | Failure(err) -> ...
И вот такие вещи и вырабатываются опытом и обучением.
А вот так — если писать идиоматично:
match io.ReadFull(b, byteArr) with | Success(n) -> ... | Failure(err) -> ...
Этот код будет работать в обоих ваших языках?
Конечно, нет.
А почему? Потому что синтаксис не подходит — отличается — да?
Отличающийся синтаксис — это только следствие. Он и в первом примере отличается, просто результирующее поведение более-менее одно и то же, поэтому можно сделать «дословный перевод». А реальное отличие состоит в том, что в первом языке просто нет таких концептуальных сущностей и механизмов, которые позволяли бы сделать (семантически) то же самое.
Отличающийся синтаксис — это факт, который помогает понять, что язык отличается. А остальные вещи уже характеризуют программиста, который писал этот код.
Ну уж нет. Каждому (по крайней мере, хорошему) языку присущи концептуальные решения, абстракции, идиомы и много других хороших (и плохих) вещей, которые, собственно, и определяют его смысл и ценность. Синтаксис — это только их следствие.
Собственно (и вам это уже написали), программиста, который берет от языка синтаксис, но игнорирует его семантику, нельзя считать владеющим этим языком на профессиональным уровне.
Собственно (и вам это уже написали), программиста, который берет от языка синтаксис, но игнорирует его семантику, нельзя считать владеющим этим языком на профессиональным уровне.
Собственно (и вам это уже написали), программиста, который берет от языка синтаксис, но игнорирует его семантику, нельзя считать владеющим этим языком на профессиональным уровне.
А я это отрицал где-нибудь? Я пишу про то, что языки можно различать про синтаксису и словам, которые в него входят, а вы утверждаете, что программиста, который берет от языка синтаксис, но игнорирует его семантику, нельзя считать владеющим этим языком на профессиональным уровне.
Вам не кажется, что я говорю про цвет помидоров, а вы про расстояние между точками А и Б? Я вам доказываю, что он красный, а вы мне противоречите и говорите, что вы суперточной рулеткой замеряли расстояние, и оно равно 10 метров, поэтому помидор не красный.
Хотя, вполне может быть, что именно я замеряю расстояние и делаю выводы о цвете на этом основании. Вы не напомните, о чём мы вообще спорим?
Вы не напомните, о чём мы вообще спорим?
Мы спорим о том, за сколько можно выучить язык на профессиональном уровне. В данную точку дискуссии мы пришли через промежуточный пойнт «для того, чтобы выучить язык, недостаточно выучить ключевые слова и синтаксис».
Собственно, это следствие того, что из моего вопроса «вы считаете, что языки отличаются только синтаксисом» вы сделали вопрос «как отличать языки», хотя это далеко не одно и то же.
(кстати, хорошая иллюстрация к тезису о владении естественным языком и о словарях)
То есть вы считаете, что языки друг от друга отличаются только синтаксисом?
Это ваш вопрос был? Я на него ответил. Вы ведь про язык спрашивали, а не про программиста.
А на вашу ремарку про уровень профессиональным владением я ответил, что споры на эту тему — пустая трата времени. Я так считаю, потому что это тема, которую нельзя измерить — это набор субъективных характеристик, а не объективных. Может я как-то неубедительно это говорил, из-за чего показалось, что я только для вида это прямым текстом говорю, а сам провоцирую на разговоры об анализе профессионализма? Если вы мне на такие провокации укажете, мне это очень поможет, так как я смогу в будущем формулировать мысли точнее — чтобы в них было меньше поводов для того, чтобы съезжать на другие темы.
Про профессионализм, я считаю, что для владения языком нужно знать его синтаксис и слова. И всё это — 1% от знаний и навыков, которые делают профессионалом. Остальные знания и навыки лежат в других предметных областях.
Это ваш вопрос был? Я на него ответил.
… и если этот ответ «да», то я не могу с ним согласиться. Языки можно (иногда) отличать по синтаксису, но отличаются они не только синтаксисом.
А на вашу ремарку про уровень профессиональным владением я ответил, что споры на эту тему — пустая трата времени.
Я не видел этого вашего ответа.
Я не видел этого вашего ответа.
Вот здесь я про это писал. Дополнительно, я это ещё раз процитирую.
(Я боюсь, что наше основное разногласие — в критериях профессионального владения)
Я думаю, вы просто в какой-то момент по инерции начали думать, что я называю профессиональным владением ситуацию, когда человек не лазает в документацию. Я повторюсь, иногда я считаю, что можно не придираться к словам человека, чтобы перейти к сути и не плодить слишком много текста. У каждого человека своё видение того, что значит профессионализм. На тот момент, я услышал, что одним из граничных условий является: «на более-менее профессиональном уровне. Чтобы просто писать не задумываясь, а не нырять в справочник каждые пять минут». У меня эта фраза не вызывает достаточно отторжения, чтобы тыкать человека в его ошибки. Зато она добавляет конкретики, на которую можно опираться. В противном случае, мы с ним ещё пару дней бы спорили, что такое «профессиональное владение» — и это была бы пустая трата времени. Это не позволило бы сразу взять и начать что-то оценивать.
… и если этот ответ «да», то я не могу с ним согласиться. Языки можно (иногда) отличать по синтаксису, но отличаются они не только синтаксисом.
Они отличаются в своей полезности многими параметрами, но понимать, что вот здесь один язык, а там — другой, можно по синтаксису и по использованным словам. Всё дело в формулировках. Вы выбрали такую формулировку вопроса — мой ответ в неё хорошо укладывается.
… и если этот ответ «да», то я не могу с ним согласиться. Языки можно (иногда) отличать по синтаксису, но отличаются они не только синтаксисом.
Можно обратиться к тому, как работает интерпретатор языка, чтобы понять, что остальные признаки — это результат восприятия конкретного человека, а не объективный признак языка. Всякие идиомы в первую очередь должны быть синтаксически верны. Интерпретатор делает синтаксический анализ. Была идиома или нет — интерпретатор выдаст ошибку, если синтаксис неправильный, или если встречается некорректное для этого языка слово.
Можно обратиться к тому, как работает интерпретатор языка, чтобы понять, что остальные признаки — это результат восприятия конкретного человека, а не объективный признак языка.
Мне не интересны «объективные признаки языка». Язык — это концепция, которая только потом находит выражение в грамматике.
А мне интересны объективные признаки, а не субъективные. Какой нам тогда смысл вообще спорить, если я про цвет говорю, а вы — про расстояния? Он же ни к чему не приведёт — только к раздажению.
Объективные признаки в человеческой индустрии? Очень мило, но не выйдет. Они, конечно, есть, но для формализации конкретной решаемой задачи их не хватит.
На каком языке написан этот код:
? Какие объективные критерии вы использовали?
$sum = 0;
for($i=0; $i < 10; $i = $i + 1) {
$sum = $sum + $i;
}
? Какие объективные критерии вы использовали?
На JavaScript. А на PHP он интерпретироваться не будет — потому что код на PHP должен содержать <?php перед кодом по синтаксису. Если это добавить явно, это уже будет ошибкой при интерпретации на JavaScript. То есть, условие про одинаковый текст, который работает в обоих интерпретаторах, не выполняется.
А кто сказал, что это полный текст файла?
Это читерство, я считаю. Потому что, например, знак «=» может использоваться в большинстве языков программирования. Если я вас попрошу угадать, что делает этот код:
=, что вы скажете? Присваивает что-нибудь? А я вам отвечу после вашего ответа: «а с чего вы взяли, ведь он являлся частью конструкции ==».Это достаточно длинный код, синтаксически корректный минимум для двух языков. Требование «должен содержать <?php» относится не к коду на PHP, а к одному из способов его передачи транслятору. Для других способов директива <?php не требуется. Например,
echo "echo \"It works\n\";" >test.php
php -a <test.php
А у вас нет, кстати, какого-нибудь примера, который покажет, что по синтаксису и словам нельзя определить, что это конкретный язык, а по другим признакам можно? Просто посмотреть на код и с уверенностью утверждать, что это код на каком-то конкретном языке, но не из-за синтаксиса и слов, а из-за других признаков.
Я согласен, что конструкция for, которую вы приводили, может работать и в PHP и в JS. Но вы сами сможете её отнести к конкретному языку, руководствуясь какими-то ещё признаками, которые выходят за рамки моих утверждений про синтаксис и слова?
Вы ведь это мне хотите показать — то, что я заблуждаюсь про только синтаксисическо-словесную разницу для определения принадлежности?
Я согласен, что конструкция for, которую вы приводили, может работать и в PHP и в JS. Но вы сами сможете её отнести к конкретному языку, руководствуясь какими-то ещё признаками, которые выходят за рамки моих утверждений про синтаксис и слова?
Вы ведь это мне хотите показать — то, что я заблуждаюсь про только синтаксисическо-словесную разницу для определения принадлежности?
С этой конструкцией, сложнее, а если воткнуть в цикл перебор элементов массива, то в javascript это будет работать быстрее, чем в php.
Вот этот пример кода с большей вероятностью написан на PHP, чем на JS. Во-первых, переменные начинаются с $, что для JS нетипично (кроме переменных только из $-ов), во-вторых, написал его я ))
Именно. Код может быть синтаксически корректным для нескольких языков, но его истинную принадлежность выдаёт стиль, используемые парадигмы, паттерны и т. п. Причём истинная принадлежность необязательно совпадает с языком, на котором этот код писался. Грубо говоря, в продакшене может выдаваться в браузер посетителя JS-код, но на самом деле это код PHP, даже если для PHP он не совсем синтаксически корректный.
Именно. Код может быть синтаксически корректным для нескольких языков, но его истинную принадлежность выдаёт стиль, используемые парадигмы, паттерны и т. п. Причём истинная принадлежность необязательно совпадает с языком, на котором этот код писался. Грубо говоря, в продакшене может выдаваться в браузер посетителя JS-код, но на самом деле это код PHP, даже если для PHP он не совсем синтаксически корректный.
Вот видите, вы употреблятете выражения «с большей вероятностью», «нетипично», «необязательно», «может». Они выдают предположение об истинной принадлежности, но не истинную принадлежность, доказанную объективными признаками. С их помощью нельзя точно сказать, что вот этот код написан на языке А, а этот — на языке Б. Но с помощью синтаксиса и слов языка — можно.
Если код на языке А синтаксически корректен, то никто не сможет оспорить, что этот код истинно является кодом на языке А — он работает. Даже если он написан с использованием каких-то стилей, паттернов и парадигм языка Б, невозможно оспорить, что он имеет право быть кодом на языке А. И кодом на языке Б он не станет только из-за того, что в нём используются парадигмы и стили из языка Б. Он им станет только если его синтаксис корректен для языка Б. Субъективные признаки дадут возможность сделать предположение о том, что код с определённой вероятностью принадлежит к языку Б. Но если по синтаксису этот код не является Б, он им не станет, даже если субъективных признаков будет миллион, а в каждом блоке комментариев в коде будет пометка, что это код на языке Б.
Если код на языке А синтаксически корректен, то никто не сможет оспорить, что этот код истинно является кодом на языке А — он работает. Даже если он написан с использованием каких-то стилей, паттернов и парадигм языка Б, невозможно оспорить, что он имеет право быть кодом на языке А. И кодом на языке Б он не станет только из-за того, что в нём используются парадигмы и стили из языка Б. Он им станет только если его синтаксис корректен для языка Б. Субъективные признаки дадут возможность сделать предположение о том, что код с определённой вероятностью принадлежит к языку Б. Но если по синтаксису этот код не является Б, он им не станет, даже если субъективных признаков будет миллион, а в каждом блоке комментариев в коде будет пометка, что это код на языке Б.
Но с помощью синтаксиса и слов языка — можно.
Я вам привёл простейший пример, что нельзя. А ведь есть языки, синтаксис которых настраивается «на лету», которые после определенного «прогрева» могут понимать любой синтаксис.
Если код на языке А синтаксически корректен, то никто не сможет оспорить, что этот код истинно является кодом на языке А — он работает.
А если работает не так, как задумывалось, то всё равно работает?
но если по синтаксису этот код не является Б, он им не станет
Не путайте «код» и «синтаксический корректный код». Если я в коде на PHP допущу синтаксическую ошибку (возможно как раз делающую его корректным кодом для JavaScript, например, вместо -> поставлю .), то это всё равно будет код на PHP. Синтаксически некорректный, но код на PHP.
Я вам привёл простейший пример, что нельзя.
Вы привели простейший пример того, что, по вашему мнению, истинную принадлежность выдаёт стиль, используемые парадигмы, паттерны и т. п. По моему мнению, это необъективные признаки. Для меня пример выглядит некорректным, потому что в его сути лежат субъективные явления.
А если работает не так, как задумывалось, то всё равно работает?
Ну да. Никто ведь ведь не в курсе, какие задумки были у прокладки между клавиатурой и стулом. Можно авторитено заявить, что это язык А, потому что у него корректный синтаксис для этого языка. Если синтаксис верен, то можно уверенно говорить, что это язык А. Если синтаксис неверен, никакие другие субъективные признаки не дадут 100%-й уверенности, что это код на языке А. Это может быть «вероятно, код на А» или «скорее всего, код на А», или «с очень большой вероятностью, код на А», но не определённо точно код на языке А.
Вот для примера:
<?php
echo "мам", PHP_EOL;
print (
" я\n\n"
); // выводит "ты"
echo " хачу", PHP_EOL; # делим на 2 *** Нужно не забыть ***
echo " литать" . PHP_EOL; /* *** сварить щи!!! *** */return print("пришей мне крылья"); //TODO: создать экземпляр класса. Компилировать с ключом --enable-opcache аот так: php happibizdey.php --enable-opcache
echo '!!!!!!!!!!!!!'; //@todo !!! разобратся поччему не выводиться !!!
Объективно, это код на PHP. Из комментариев понятно, что нужно сварить щи, но код этого не делает. И, если ещё подумать, он работает не так, как задумывалось, потому что восклицательные знаки не выводятся. Он от этого разве перестанет быть кодом на PHP?
Если я в коде на PHP допущу синтаксическую ошибку (возможно как раз делающую его корректным кодом для JavaScript, например, вместо -> поставлю .), то это всё равно будет код на PHP.
Ну да, будет считаться кодом на PHP. Просто будет ругаться на что-нибудь вроде «Object of class XXX could not be converted to string» (если не существует XXX::__toString()). Это не синтаксическая ошибка. Это оператор конкатенации (в ваших обстоятельствах, во всяком случае, когда вы поменяли «->» на точку), который является частью синтаксиса PHP. В то же самое время, он будет считаться кодом на JavaScript.
Мне, вам, кому-то ещё третьему-четвёртому-пятому можно считать этот код только кодом на PHP и говорить, что это стопроцентно не код на JavaScript, если это нужно. Но это субъективное мнение, которое объективным признаком не может стать.
Вот, например:
function trimString($string)
{
return trim($string);
}
Я считаю это кодом на JavaScript. Оппонент считает это кодом на PHP. И оба мы правы, потому что нет объективных признаков, чтобы стопроцентно отнести этот код к одному языку. Но мы можем спорить, что $ — признак PHP, или что в JS нет trim (я на это отвечу то же самое, что вы мне сказали чуть раньше). И всё равно мы оба останемся правы, потому что со стопроцентной уверенностью можно будет сказать что-то о принадлежности к конкретному языку только после того, как из объективных признаков это станет точно известно. Нетипичность использования $ в JS и то, что оппонент лично код написал на PHP — это субъективные признаки. Он может через несколько минут передумать и сказать, что писал на самом деле на JS — и этот аргумент будет таким же субъективным как и тот, где говорилось про PHP — и это не добавит ровным счётом ничего к объективным оценкам (не убавит тоже, кстати).
* * *
Если совсем хорошо подумать, то синтаксис, за который я так упорно цепляюсь, тоже не может быть объективным признаком, потому что можно интерпретатору PHP скормить «Войну и мир» под видом программного кода. Он выдаст ошибки, но это будут ошибки PHP. Их можно будет просто поправить, и всё заработает — «Война и мир» с самого начала была кодом на PHP, просто с ошибками была написана.
И раз синтаксис становится субъективным, то у него такое же право влиять на принадлежность к языку, как и у стилей, используемых парадигм, паттернов и т.п. Единственный объективный признак — контекст исполнения (пока не доказано обратное). :)
У меня один знакомый, кстати, часто использует $ в имени переменных на JS. Для него это типично. Я не понимаю до конца, чем он руководствуется при этом, потому что переменные без доллара он тоже использует рядом, но, в общем-то, его код работает нормально и ошибок не выдаёт.
Я это всё веду к тому, что я критерии различия указываю, и объясняю, почему они помогают различать вещи. Но меня оспаривают тем, что есть куча других критериев, и не объясняют, как именно они помогают различать вещи.
Ситуация, когда один и тот же код работает в нескольких интерпретаторах, мои слова не опровергает, потому что в то же самое время не находится каких-то других критериев, которые гарантированно покажут различие.
Я не утверждаю, что любой вообще код можно различить, опираясь на синтаксис и слова, ведь существует код, который может работать и там и там. Я говорю про то, что не требуется дополнительных критериев, чтобы оценивать принадлежность. И если в коде используются идиомы, характерные для языка A, но он работает в языке Б, у него одинаковое право быть кодом как на языке A, так и на языке Б. Но если будет различаться синтаксис, то у него не будет возможности быть одновременно кодом на языке А и на языке Б.
Ситуация, когда один и тот же код работает в нескольких интерпретаторах, мои слова не опровергает, потому что в то же самое время не находится каких-то других критериев, которые гарантированно покажут различие.
Я не утверждаю, что любой вообще код можно различить, опираясь на синтаксис и слова, ведь существует код, который может работать и там и там. Я говорю про то, что не требуется дополнительных критериев, чтобы оценивать принадлежность. И если в коде используются идиомы, характерные для языка A, но он работает в языке Б, у него одинаковое право быть кодом как на языке A, так и на языке Б. Но если будет различаться синтаксис, то у него не будет возможности быть одновременно кодом на языке А и на языке Б.
Я надеюсь, наличие <?php — это объективный критерий? Ведь это часть синтаксиса.
Как быть со случаями, когда один и тот же текст будет синтаксически корректным для двух разных интерпретаторов, но выдаст совершенно разные результаты?
Есть, как минимум, частично совместимые языки, например, С и C++ или PHP и JS, когда как минимум подмножество синтаксически корректного кода, а то и весь код на одном является и синтаксически корректным кодом на другом. Семантика же при этом может отличаться, например в нюансах типа наличия автоматической сборки мусора или других правил приведения типов.
Знание точных наук, алгоритмическое мышление, способности к математике и анализу. И прочее, и прочеее, и прочее. И куча всего остального, не относящегося к конкретному языку программирования вообще. Вот, это моё мнение про профессионализм. Оно может быть неправильным, но я не буду спорить об этом.
> видите её исходный код — синтаксис и слова
Я уже написал в другом месте, но мысль важная, поэтому повторю.
За любым языком стоит некая «новая философия», в противном случае непонятно, ради чего данный язык создавался. Неужели тысяч уже существующих языков мало?
Соответственно, профессиональное владение — это, разумеется, владение именно философией и идиоматикой данного языка. Причём именно на уровне письма. Если ей не владеть, то нет никакого смысла заморачиваться с его изучением. Для меня эти вещи самоочевидны, поэтому я их просто пропускал в диалоге.
Допустим, некто с опытом C «знает» также C++, но никогда не использует ключевое слово private, хотя и знает, что оно означает. По моему определению («пользоваться без словаря»), он, конечно, «владеет», но профессиональным владением назвать это никак нельзя.
Человек должен без запинки выдавать код, соответствующий идеологии используемого языка, иначе это просто профанация какая-то.
Я уже написал в другом месте, но мысль важная, поэтому повторю.
За любым языком стоит некая «новая философия», в противном случае непонятно, ради чего данный язык создавался. Неужели тысяч уже существующих языков мало?
Соответственно, профессиональное владение — это, разумеется, владение именно философией и идиоматикой данного языка. Причём именно на уровне письма. Если ей не владеть, то нет никакого смысла заморачиваться с его изучением. Для меня эти вещи самоочевидны, поэтому я их просто пропускал в диалоге.
Допустим, некто с опытом C «знает» также C++, но никогда не использует ключевое слово private, хотя и знает, что оно означает. По моему определению («пользоваться без словаря»), он, конечно, «владеет», но профессиональным владением назвать это никак нельзя.
Человек должен без запинки выдавать код, соответствующий идеологии используемого языка, иначе это просто профанация какая-то.
«Это не позволило бы сразу взять и начать что-то оценивать.»
Лучше всё-таки для начала сойтись в определениях… Ну чтобы не делать никому не нужную работу
Родственные (синтаксически языки): java, c, c++ — вот так взять и перейти с одного языка на другой… да на профессиональном уровне… имхо побольше года понадобится:
— отвыкнуть от старого синтаксиса (и не лепить его автоматом),
— принять language way (аннотации+генерики/макросы+шаблоны функций, и многое другое),
— изучить систему фреймворков в нужной области деятельности
и это я далеко не все нюансы перечислил.
Т.е. переходя с одного языка на другой, ты в лучшем случае теряешь условную ступеньку — был сеньором — станешь мидлом, был мидлом — станешь джуном. Условно, но близко к этому. А потом уже за год-два практики ты вернёшь старую ступень.
Лучше всё-таки для начала сойтись в определениях… Ну чтобы не делать никому не нужную работу
Родственные (синтаксически языки): java, c, c++ — вот так взять и перейти с одного языка на другой… да на профессиональном уровне… имхо побольше года понадобится:
— отвыкнуть от старого синтаксиса (и не лепить его автоматом),
— принять language way (аннотации+генерики/макросы+шаблоны функций, и многое другое),
— изучить систему фреймворков в нужной области деятельности
и это я далеко не все нюансы перечислил.
Т.е. переходя с одного языка на другой, ты в лучшем случае теряешь условную ступеньку — был сеньором — станешь мидлом, был мидлом — станешь джуном. Условно, но близко к этому. А потом уже за год-два практики ты вернёшь старую ступень.
Самое интересное, что хипстерам очень нравится Rust, он становится модным. И это — наконец-то — что-то хорошее среди «хипстерского».
А где про Катю? Про Катю где, я вас спрашиваю!?
Про Катю в другой статье.
Спасибо, мил человек, нагуглил и прочитал обе статьи про Катю. Теперь хотя бы в курсе последних тенденций в Go-тусовке. Буду ждать продолжения.
P.S. Обновились комменты — а тут уже люди и ссылки выложили, так что кому-то и гуглить не придется.
P.S. Обновились комменты — а тут уже люди и ссылки выложили, так что кому-то и гуглить не придется.
Вызываю c-darwin
Суть статьи
Функциональщина плохо читаема, у нас в команде каждый писал как хотел, мы нанимали новичков без опыта, которых приходилось обучать, перешли на Go, т.к. у него более С-подобный синтаксис и вообще он сам код форматирует и компилирует всё в один файл, ваааау, нашим новичкам понравилось, мы теперь тоже можем не умничать и 2+2 писать как 2+2.
Функциональщина плохо читаема, у нас в команде каждый писал как хотел, мы нанимали новичков без опыта, которых приходилось обучать, перешли на Go, т.к. у него более С-подобный синтаксис и вообще он сам код форматирует и компилирует всё в один файл, ваааау, нашим новичкам понравилось, мы теперь тоже можем не умничать и 2+2 писать как 2+2.
Непонятно, почему каждый Go-хейтер отличается таким неуважением к чужому опыту и мнению. Ещё более непонятно, почему считает необходимым это своё неуважение написать на в комментариях на хабре.
Я пересказал суть статьи, указав на проблемы, которые были у автора. С чем конкретно вы не согласны? С тем, что у них не было стандартов написания кода? Если бы они были, тогда бы 3 человека не стояли над кодом четвёртого и не пытались бы разобраться, что это за символ такой.
Что приходилось учить новичков? Чему учить-то? Нанимая в команду программистов их ничему учить не надо, если процессы и архитектура выстроены как положено. Объяснять — да, но не УЧИТЬ.
А из плюсов перехода на ГО автор описал самые типичные фичи golang, ничего нового. Так в чём моя интерпретация вашего перевода не совпадает с фактами?
P.S. я люблю и пишу на golang, в прошлых ваших статьях я его иногда защищал. Нужно быть реалистом и относиться ко всему без предвзятости. Тут же я вижу большие проблемы в команде, которые завуалировались механизмами написания на Go, он просто не даёт им совершить те же ошибки. Но это в то же время значит, что не будь у них типичных болячек неумелого IT лида, им бы не пришлось переписывать всё.
Что приходилось учить новичков? Чему учить-то? Нанимая в команду программистов их ничему учить не надо, если процессы и архитектура выстроены как положено. Объяснять — да, но не УЧИТЬ.
А из плюсов перехода на ГО автор описал самые типичные фичи golang, ничего нового. Так в чём моя интерпретация вашего перевода не совпадает с фактами?
P.S. я люблю и пишу на golang, в прошлых ваших статьях я его иногда защищал. Нужно быть реалистом и относиться ко всему без предвзятости. Тут же я вижу большие проблемы в команде, которые завуалировались механизмами написания на Go, он просто не даёт им совершить те же ошибки. Но это в то же время значит, что не будь у них типичных болячек неумелого IT лида, им бы не пришлось переписывать всё.
С чем конкретно вы не согласны?
Прежде всего с тональностью вашего комментария. Ну и дальше:
- «более С-подобный синтаксис» — в статье этого нет.
- мы нанимали новичков без опыта — тоже придумали сами, там речь идёт о входе в проект, а не в язык
- «ваааау, нашим новичкам понравилось» — снова отсебятина
автор описал самые типичные фичи golang, ничего нового
Как будто ценность статей измеряется «новизной». Я. хоть и читаю вообще все статьи про Go, в этой статье увидел достаточно нового, чтобы захотеть её перевести. А сам аргумент «ничего нового» — так себе. В вашем комментарии тоже ничего нового ведь.
Нужно быть реалистом и относиться ко всему без предвзятости.
Именно.
не будь у них типичных болячек неумелого IT лида
Интереса ради, а у вас был опыт управления компанией, которая выросла с 5 до 200 человек?
>Прежде всего с тональностью вашего комментария.
И тут Go-шники ведут себя как маленькие обиженные детки.
Хорошо хоть хабр не их комьюнити площадка, а то бы и тут начали выпиливать всех, кто посмел своей тональностью обидеть их горячо любимый Go.
И тут Go-шники ведут себя как маленькие обиженные детки.
Хорошо хоть хабр не их комьюнити площадка, а то бы и тут начали выпиливать всех, кто посмел своей тональностью обидеть их горячо любимый Go.
Тоесть, по вашему, если кому-то не нравится насмешливая тональность, в которой автор приносит свои предрассудки — то это «маленькие обиженные детки»? )
Как-то вы болезненно реагируете на то, что кому-то подобная тональность не нравится, вам не кажется?
Как-то вы болезненно реагируете на то, что кому-то подобная тональность не нравится, вам не кажется?
Чет ты какой-то сильно микроагрессивный, вообще не попадаешь в нормы поведения (golang.org/conduct) сообщества! Сейчас тебя забаним и пулл реквесты от тебя принимать не станем, понял?
П.С. Ссылки не работают? 0_O
П.С. Ссылки не работают? 0_O
Да, Пайк бы точно не одобрил такое поведение…
Почитайте Пайка на форумах. Любитель язвить и провоцировать людей, вместо поддержки конструктивной беседы.
Но кто же тогда составлял это? Почему же гоферы не следуют ему?
Это что-то новенькое. Покажите мне где Пайк язвит и провоцирует людей, вместо поддержки конструктивной беседы.
Только недавно читал про подсветку синтаксиса для Go groups.google.com/forum/#!topic/golang-nuts/hJHCAaiL0so, где Пайк кидался только шуточками и язвительными комментариями в духе «подсветка синтаксиса для детишек, я выше этого». В итоге пришел еще один человек из команды Go и заткнул рот тем, кто начал катить бочку на Пайка за такой настрой. Замечательная атмосфера просто.
Это типичный такой жирный троллинг.
Syntax highlighting is juvenile. When I was a child, I was taught
arithmetic using colored rods I grew up and today I
use monochromatic numerals.
Это типичный такой жирный троллинг.
Это типичный такой жирный троллинг.
Нет, Почитайте тред. Он начинается со слов «Новый Холивар», в котором Пайк, который относится к программистам, не любящих подсветку синтаксиса, в духе треда и ответил, и вполне невинно.
Но вы же себя только что изобразили знатоком постов Пайка, так что приведите, пожалуйста, ещё примеры, где Пайк «язвит» и «провоцирует людей, вместо поддержки конструктивной беседы». Я же полагаю, вы не станете называть единственный пример с текстом «новый холивар» конструктивной беседой?
По моим наблюдениям, Пайк отвечает очень лаконично, и там где нужен действительно его ответ — всегда по сути. Так что ваши наезды мне не сильно понятны.
И опять вы свернулись в клубок и выпустили иголочки. Никто на вашего Пайка не наезжал. Я всего лишь заметил, что он тот еще троль. Что тут говорить, я так же отвечал вам, когда мне надоело уже видеть непробиваемое фанбойство.
Я бы это вам посоветовал, ибо так нагло врать нехорошо. Никто там про хиловары не заикался. А Пайк всего лишь пришел и вбросил, больше ничего он не добавил в ту беседу.
Почитайте тред. Он начинается со слов «Новый Холивар», в котором Пайк, который относится к программистам, не любящих подсветку синтаксиса, в духе треда и ответил, и вполне невинно.
Я бы это вам посоветовал, ибо так нагло врать нехорошо. Никто там про хиловары не заикался. А Пайк всего лишь пришел и вбросил, больше ничего он не добавил в ту беседу.
Никто на вашего Пайка не наезжал. Я всего лишь заметил, что он тот еще троль.
мне надоело уже видеть непробиваемое фанбойство.
У меня к вам был простой вопрос — покажите ещё примеры, где Пайк «троллит», «язвит» и «провоцирует людей». Ведь если из 1000 ответов Пайка лишь один, и то, с натяжкой, подходит под ваше «не наезжание», то значит вы не правы и оскорбляете незаслуженно человека троллем. Я вас прошу либо доказать мне, что ваши слова — не пусты, либо признать ошибку.
А ваши личностные выпады в адрес всех подряд совсем не к месту.
У меня к вам был простой вопрос — покажите ещё примеры, где Пайк «троллит», «язвит» и «провоцирует людей».
Думаю, если привести ссылку по которой Пайк вежливо, коротко и по делу даёт ответ на поставленный вопрос, это будет не менее показательно.
Думаю, если привести ссылку по которой Пайк вежливо, коротко и по делу даёт ответ на поставленный вопрос, это будет не менне показательно.
Это 99% его ответов. И товарищ крекер это прекрасно знает.
Товарищ крекер может и знает, а вот я, например, ничего, кроме этого самого треда про подсветку не видел никогда. Да и многие другие тоже.
А что мешает зайти в группы golang-dev и golang-nuts и вбить в поиск «rob pike»?
Я попробовал, чего-то ничего показательного не нашёл. В основном какие-то другие люди рассказывают что-то про Роба Пайка.
Может, вы найдёте пример какого-нибудь ответа Роба Пайка? Вы их видели много, знаете где найти и какой выбрать. Вы наверняка сделаете это быстрее и самое главное лучше, чем я.
Может, вы найдёте пример какого-нибудь ответа Роба Пайка? Вы их видели много, знаете где найти и какой выбрать. Вы наверняка сделаете это быстрее и самое главное лучше, чем я.
Как это всё странно. Ну держите.
Спасибо!
Вообще любопытно, как Пайк по сравнению с Линусом Торвальдсом. Ну то есть понятно, что пассажа, подобного пассажу с NVidia у Пайка наверное не найти. Но вообще он где-нибудь оглашал своё мнение по поводу того, как надо реагировать на косяки разработчиков?
Вообще любопытно, как Пайк по сравнению с Линусом Торвальдсом. Ну то есть понятно, что пассажа, подобного пассажу с NVidia у Пайка наверное не найти. Но вообще он где-нибудь оглашал своё мнение по поводу того, как надо реагировать на косяки разработчиков?
Не знаю, он достаточно лаконично и кратко высказывается. В стиле «чем меньше скажешь, тем меньше поводов неправильно трактовать». Возможно, иногда слишком кратко, но уж точно не тролль и не язвитель, как это зачем-то придумал комментатор выше.
Была разве что статья у него про критиков: habrahabr.ru/post/197398
Была разве что статья у него про критиков: habrahabr.ru/post/197398
Зато Пайк бы одобрил, что ссылки не работают. Ибо подсветка синтаксиса и rich text не нужны.
Вроде про опыт и мнение в комментарии ничего не было, я прочитал это как критику статьи в первую очередь. И критика вполне справедливая, т.к. причинно-следственные связи в описании решений похрамывают. Да, действительно, в Scala есть проблема многообразия стилей и подходов, и вопрос не только в читабельности, но и в банальной совместимости библиотек. Но решается это банальным введением конвенций, что гораздо проще, чем изучение нового языка и переписывание существующей кодовой базы.
Что ещё более нелогично, так это то, что Scala всё ещё осталась в инструментарии этой компании. Т.е. если раньше было 2 стиля программирования на Scala, то теперь осталось всё те же 2 стиля плюс другой язык. И чего, спрашивается, они этим добились?
Скорее всего, описанная проблема — это только вершина айсберга, и на самом деле были гораздо более веские причины сменить язык. Но о них в статье ничего не сказано, почему она и вызывает недоверие.
Что ещё более нелогично, так это то, что Scala всё ещё осталась в инструментарии этой компании. Т.е. если раньше было 2 стиля программирования на Scala, то теперь осталось всё те же 2 стиля плюс другой язык. И чего, спрашивается, они этим добились?
Скорее всего, описанная проблема — это только вершина айсберга, и на самом деле были гораздо более веские причины сменить язык. Но о них в статье ничего не сказано, почему она и вызывает недоверие.
Чего вы сразу в штыки-то?
Вот я не являюсь го-хейтером, потому что я вообще почти не знаком с го) Говорят отличный язык, всё никак руки не доходят попробовать.
Но в статьей действительно об эттом
Кстати, о чём это говорит: го дружелюбен к новичкам, что очень неплохо на мой поверхностный взгляд. В общем, будьте проще, не надо рычать на всех, с кем вы не согласны.
Вот я не являюсь го-хейтером, потому что я вообще почти не знаком с го) Говорят отличный язык, всё никак руки не доходят попробовать.
Но в статьей действительно об эттом
Функциональщина плохо читаема, у нас в команде каждый писал как хотел, мы нанимали новичков без опыта, которых приходилось обучать, перешли на Go, т.к. у него более С-подобный синтаксис и вообще он сам код форматирует и компилирует всё в один файл, ваааау, нашим новичкам понравилось, мы теперь тоже можем не умничать и 2+2 писать как 2+2.
ответить
Кстати, о чём это говорит: го дружелюбен к новичкам, что очень неплохо на мой поверхностный взгляд. В общем, будьте проще, не надо рычать на всех, с кем вы не согласны.
Понимаете, один и тот же посыл можно сказать совершенно разными словами. Какова была цель и суть комментария, в котором автор придумал/приписал некоторые вещи, чтобы придать своей оценке надменно-насмешнического оттенка?
И почему люди, так ратующие за «будьте проще ко всем, с кем вы не согласны» не могут быть проще к тем, кто не согласны с ними?
И почему люди, так ратующие за «будьте проще ко всем, с кем вы не согласны» не могут быть проще к тем, кто не согласны с ними?
В эфире — ставшая почти регулярной рубрика «Переезжаем с *langName* на Go»
Или это такая активная пропаганда, или же действительно стоит что-то запустить на Go
Или это такая активная пропаганда, или же действительно стоит что-то запустить на Go
Меня как-то коробит сама постановка вопроса — «стоит что-то запустить на Go».
Язык — это инструмент для решения задач, ни больше, ни меньше. Запускать что-то ради языка — это как копать яму ради лопаты.
Если слышите, что много людей хвалят инструмент — познакомьтесь, оцените его подходящесть для ваших задач и исходите из прагматических соображений.
Язык — это инструмент для решения задач, ни больше, ни меньше. Запускать что-то ради языка — это как копать яму ради лопаты.
Если слышите, что много людей хвалят инструмент — познакомьтесь, оцените его подходящесть для ваших задач и исходите из прагматических соображений.
Обратите внимание что статьи пишут одни и те же люди, то что про Go «много говорят» в основном объясняется их продуктивностью в написании статей.
Я (сердце) отличные переводы
Видимо, автор не мог выбрать какой символ ♡ использовать.
Почему статью не назвали «Как мы перешли со Scalaz на Go»? Как бы Scalaz != Scala. Я например не использую эту либу в своем коде, потому что в стандартной скале и так много готовых хороших абстракций. Так же Scalaz не советуют использовать и текущие разработчики Scala.
Так и что же та кракозябра означает?
Не задавай глупые вопросы, а просто переходи на Go, что ты не понимаешь?
На самом деле этот вопрос интересовал многих scala-разработчиков (как я понимаю, сейчас эту штуку убрали, или переместили...).
И благодаря поисковику по подобным операторам я таки вышел на вопрос на SO. Если его долго читать, то наверно можно разобраться.
symbolhound.com/?q=%3C|*|%3E
stackoverflow.com/questions/2545248/function-syntax-puzzler-in-scalaz
А вот тут исходник сего оператора: github.com/scalaz/scalaz/blob/release/6.0.4/core/src/main/scala/scalaz/MA.scala#L52
Но вообще, это скорее пример того, как scala использовать не нужно.
И благодаря поисковику по подобным операторам я таки вышел на вопрос на SO. Если его долго читать, то наверно можно разобраться.
symbolhound.com/?q=%3C|*|%3E
stackoverflow.com/questions/2545248/function-syntax-puzzler-in-scalaz
А вот тут исходник сего оператора: github.com/scalaz/scalaz/blob/release/6.0.4/core/src/main/scala/scalaz/MA.scala#L52
Но вообще, это скорее пример того, как scala использовать не нужно.
Ошибка автора, как мне кажется, в неверной расстановки приоритетов при оценке коллег. Как только половина людей (по его словам) говорит «wtf», то автор кода, имхо, никак не может называться «выдающимся программистом».
Написать сложный one-liner много ума не надо. А вот написать код так, чтобы он легко читался и содержал как можно меньше шума…
https://youtu.be/TSAlj04_tkA (часть 1)
https://youtu.be/cPXTozVjSHo (часть 2)
В свое время этот доклад совершенно перевернул мое видение. Крайне советую всем посмотреть независимо от языка.
Написать сложный one-liner много ума не надо. А вот написать код так, чтобы он легко читался и содержал как можно меньше шума…
https://youtu.be/TSAlj04_tkA (часть 1)
https://youtu.be/cPXTozVjSHo (часть 2)
В свое время этот доклад совершенно перевернул мое видение. Крайне советую всем посмотреть независимо от языка.
При том, что я с вами согласен (в плане оценки коллег), я бы хотел ещё одну мысль в копилочку добавить: язык программирования задаёт рамки, которые могут затруднить или облегчить написание трудночитаемого кода. Go не даёт писать хитрый, сложный, нечитаемый код просто потому, что из него изъяли кучу конструкций, и этим он хорош.
Почему не взяли Кложу? Легче Скалы, но тот же JVM.
У меня такое ощущение, что «кто-то» там явно проплачивает все эти «переходы» на Go, уж больно обоснования бредовые и притянутые за уши… )
Да, именно так всё и происходит в реальном мире )
Да ладно, много конечно воды налили, но по сути го перекрыл доступ «умникам» к их «мега гениальным» конструкциям кода, чего не получалось сделать тимлиду в оффлайне палкой или чем он там пользуется. В конкретном случае го выполнил свою роль на ура именно простотой.
Я ничего не хочу сказать плохого про Go, но статья выглядит как «Мы не способны ввести единый стандарт кодирования в нашей команде, зато способны заставить всех разработчиков учить новый язык и теперь у нас три стандарта кодирования (два от scala и один от GO)». Если есть проблема с механизмом сборки SBT почему не взять другую систему сборки? Если проблемы в том что команда пишет в двух разных стилях, почему не разделить команду на разные проекты или железно заставить писать в одном стиле? Как code review пропустил код, написанный так, что его никто в команде больше не понимает?
В целом, решение чисто административных проблем, описанных в статье, переходом на новый язык выглядит как попытка переименовать милицию в полицию, в расчете что это победит коррупцию.
В целом, решение чисто административных проблем, описанных в статье, переходом на новый язык выглядит как попытка переименовать милицию в полицию, в расчете что это победит коррупцию.
.
Ну вот вы хорошие вопросы задаёте, но почему-то упускаете вопрос «Если есть язык, который людям больше нравится и подходит под задачи лучше — почему бы последовательно не перейти на него, особенно если позволяют сроки/планы». Повторюсь, язык это просто инструмент решения задачи, это не религия. Если есть инструмент более подходящий — почему бы не использовать его?
Язык инструмент решения задачи, но не инструмент решения проблем менеджмента. Статья не имеет никакого отношения к «Если есть язык, который людям больше нравится и подходит под задачи лучше — почему бы последовательно не перейти на него, особенно если позволяют сроки/планы»
Статья имеет прямейшее к этому отношение.
Вы же сами писали что изначально го никто не знал, и вам пришлось его учить. А тут вдруг «есть язык, который людям больше нравится». Это полностью противоречит тому что написано в статье :) Надо было просто навалять тому кто каракулину вставил в код, а если бы возникать начал, то уволить. тогда другие начали бы попроще код писать, в итоге всем было бы легче работать. идти на поводу у разработчиков не дело, прислушиваться нужно, но не потакать.
Я не упускаю, просто причины, указанные в статье, почему был осуществлен переход со Scala на Go — нелепые (говорю с точки зрения бывшего менеджера команды похожего размера, что в статье). Соотвествено, либо в статье не указаны реальные причины перехода, либо автор некомпентентен. В любом случее, доверять такой статьи нельзя категорически.
Пускай чисто административные проблемы. Но их же решили путём принятия административного решения: «теперь пишем на Go» :)
200 человек в одной команде? У них не с инструментами проблемы, у них с организацией процесса разработки проблемы. 200 человек внезапно оказались слишком разными? Просто удивительно. Всё-таки не каждый хороший разработчик автоматически становится хорошим руководителем. А статья не про Go, да, а про техдира-неумеху, который продолжает наступать на грабли.
Возможно, хотя в статье нет подробностей о том, как команды были разбиты. Хотя есть намеки на то, что было много команд.
А у вас сколько было максимум в команде, которой вы управляли?
А у вас сколько было максимум в команде, которой вы управляли?
В статье вобще нет подробностей почти ни о чем, кроме поиска непонятного бага и хвалебных од Go. У меня 20см а у вас?
Да там полно подробностей, и весьма интересных. Вы либо невнимательно читали, либо чрезмерно предвзяты ко всем статьям про Go.
Разумеется я чрезмерно предвзят ко всем статьям на Go. Я всё ещё не похоронил мысль о том, что он мне когда-нибудь пригодится. Но каждый раз я завершаю чтение с одними и теми же мыслями и выводами. Наверное, мешает личная симпатия к некоторым аспектам языка (к слову, документация, комьюнити, читабельность, поддерживаемость и масштабируемость к этим аспектам не относится, а для меня это важные вещи, поэтому для меня Go вряд ли когда-нибудь станет языком по-умолчанию).
Разумеется, я прочёл статью внимательно. И конечно же там много подробностей (три часа ночи, три программиста, Scala, Scalaz, .......). Но они не про Go.
Мне было бы очень любопытно взглянуть на кусок их кода на Go, взятый из примерно того же уровня абстракции, что приведённый фрагмент на scala.
Разумеется, я прочёл статью внимательно. И конечно же там много подробностей (три часа ночи, три программиста, Scala, Scalaz, .......). Но они не про Go.
Мне было бы очень любопытно взглянуть на кусок их кода на Go, взятый из примерно того же уровня абстракции, что приведённый фрагмент на scala.
Разумеется я чрезмерно предвзят ко всем статьям на Go.
Это слишком заметно.
Я всё ещё не похоронил мысль о том, что он мне когда-нибудь пригодится.
Но каждый раз я завершаю чтение с одними и теми же мыслями и выводами.
а для меня это важные вещи, поэтому для меня Go вряд ли когда-нибудь станет языком по-умолчанию
Да, господи, ничего в этом ужасного нет. Пишите на чём вам удобнее.
Вы так пишете, будто статьи на хабре пишутся для вас лично и всем очень важно знать вашу реакцию.
Это слишком заметно.
Действительно, я оставил несколько комментариев под вашими переводами. Но я не раскаиваюсь.
Вы так пишете, будто статьи на хабре пишутся для вас лично и всем очень важно знать вашу реакцию.
Можно попродробнее на этом моменте? Что навело вас на эту мысль? И, если вас не затруднит, детализируйте пожалуйста — «так пишете» — это как именно?
Вы слишком много и часто акцентируете внимание на своем «я». «Я делаю вывод», «я похоронил мысль», «мне важно», «у меня 20 см» и тд. Выглядит это несколько странно.
Выглядит это несколько странно.
Для кого это выглядит странным?
Спасибо, кстати, вот этот тред позволил мне, наконец, понять, чем меня так этот весь шум про го напрягает: активные сторонники всегда агрессивнее, косноязычнее и просто тупее, чем сомневающиеся, причем вот со всем этим джентльменским набором: «сколько человек ты прогибал», «иди мимо, это не для тебя» и так далее.
На простые вопросы ответить не хотят (не могут?), «Гугл переходит на го» в качестве вечного аргумента (у гугла столько слабосвязанных сервисов, что я не удивлюсь увидеть у них и ним/немерле в продакшене), в общем, от коммьюнити явно попахивает школотой.
При этом, как вы совершенно верно заметили, сам-то язык, может быть, и ничего. Просто я не вполне понимаю, зачем лично мне, профессионалу более-менее, выбирать команду и язык по принципу «обезьяна справится с порогом входа». Ну пусть обезбяны справляются, я очень рад за них, спецам-то это все зачем?
На простые вопросы ответить не хотят (не могут?), «Гугл переходит на го» в качестве вечного аргумента (у гугла столько слабосвязанных сервисов, что я не удивлюсь увидеть у них и ним/немерле в продакшене), в общем, от коммьюнити явно попахивает школотой.
При этом, как вы совершенно верно заметили, сам-то язык, может быть, и ничего. Просто я не вполне понимаю, зачем лично мне, профессионалу более-менее, выбирать команду и язык по принципу «обезьяна справится с порогом входа». Ну пусть обезбяны справляются, я очень рад за них, спецам-то это все зачем?
активные сторонники всегда агрессивнее, косноязычнее и просто тупее, чем сомневающиеся
в общем, от коммьюнити явно попахивает школотой.
Ваш комментарий, безусловно, демонстрирует образцовое общение. :)
А я и не претендую, я уже давно пишу комментарии, как мне нравится. И общаться с вами у меня никакого желания не было, поэтому я вам ничего и не написал.
И общаться с вами у меня никакого желания не было, поэтому я вам ничего и не написал.
Вы целых два комментария написали от вашего «нежелания общаться». ))))
Не надо обижать активных сторонников, вы щас высказали мнение из серии «блондинки тупые а брюнетки нет» :) Будьте лояльными, мы не все агрессивные, от людей зависит, как и в другой отрасли.
А я вообще считаю, что активные сторонники любого языка — люди ограниченные. Для одних задач хорошо подходит эрланг, для других — R, для третьих — си, для четвертых — java/scala. Своя безусловная ниша есть у lua, javascript, LISP, FORTRAN, SQL.
Таких задач, для которых лучше всего подходит го, насколько могу судить, нет. Ну, если не считать задачей «нанять двести обезьян по дешевке».
Поэтому как только товарищ начинает предъявлять «сперва добейся», товарищ идет нахрен. А так-то я со всей максимальной лояльностью :)
Таких задач, для которых лучше всего подходит го, насколько могу судить, нет. Ну, если не считать задачей «нанять двести обезьян по дешевке».
Поэтому как только товарищ начинает предъявлять «сперва добейся», товарищ идет нахрен. А так-то я со всей максимальной лояльностью :)
Для одних задач хорошо подходит эрланг, для других — R, для третьих — си, для четвертых — java/scala.
Именно то, что я пытаюсь донести в каждом втором комментарии.
Поэтому как только товарищ начинает предъявлять «сперва добейся», товарищ идет нахрен.
Ещё один обиженный. :) Как попускать каждую статью — так герои, а как ответить, сколько людей было в подчинении — так сразу в гопников играют. Ну и публика тут.
А вы не могли бы описать спектр задач, для которых Go подходит лучше всего остального?
Офигенная картинка! Откуда она?
И к какой части embedded оно так прекрасно подходит? Или в данном случае embedded это linux @ arm9/arm11/arm cortex-a/mips?
Даже меньше. Достаточно посмотреть на поддерживаемые комбинации GOOS и GOARCH golang.org/doc/install/source
Таких задач, для которых лучше всего подходит го, насколько могу судить, нет.
А по каким критериям вы определяете лучше подходит язык или хуже?
Ну, если не считать задачей «нанять двести обезьян по дешевке».
Экономические в их число не входят, да?
> А по каким критериям вы определяете лучше подходит язык или хуже?
По производительности, количеству и внятности кода, который нужно будет написать профессионалу, чтобы эту задачу решить.
> Экономические в их число не входят, да?
Не входят. Этот вопрос не про качество языка вообще, он лежит в перпендикулярной плоскости. Если бы статья была озаглавлена «как мы сэкономили бабла на качестве нашего продукта за счет найма хомяков» — я бы вообще слова не сказал.
По производительности, количеству и внятности кода, который нужно будет написать профессионалу, чтобы эту задачу решить.
> Экономические в их число не входят, да?
Не входят. Этот вопрос не про качество языка вообще, он лежит в перпендикулярной плоскости. Если бы статья была озаглавлена «как мы сэкономили бабла на качестве нашего продукта за счет найма хомяков» — я бы вообще слова не сказал.
Производительность (и программы, и программиста) — критерий важный прежде всего с экономической точки зрения. Количество кода — тоже. Внятность — аналогично.
Экономический критерий самый важный для коммерческой и близкой к ней разработки. И если какой-то язык позволяет решить задачу при найме 10 хомяков, а другой наймом одного профи, который хочет денег как 20 хомяков, то первый язык лучше при прочих равных.
Экономический критерий самый важный для коммерческой и близкой к ней разработки. И если какой-то язык позволяет решить задачу при найме 10 хомяков, а другой наймом одного профи, который хочет денег как 20 хомяков, то первый язык лучше при прочих равных.
А, простите, я просто думал, что хабр хоть в какой-то мере остался сообществом программистов. Как программисту, мне хотелось бы тут обсуждать преимущества языков не с экономической точки зрения. Мне хватает необходимости уделять экономическому аспекту проблемы кучу времени. Потому что в нашей скромной компании я вынужден принимать технологические стратегические решения.
Но и даже в этой ситуации я не вижу преимуществ го. Историй успеха нет. «Мы переписали все с руби на скала» и получили 20× преимущество — слышал. «Аккуратно переписали проксирование и получили 40×» — было. Написали свою виртуальную машину для обработки PHP — помню. А вот выбросили виртуальную машину Java в пользу го и теперь все круто — только на уровне недотеп из никому не известных компаний.
Да и само понятие «экономический аспект» вы понимаете неправильно. Наша контора, например, пока растет быстрее, чем развивается го. Поэтому на сегодняшний день я даже не рассматриваю го в качестве варианта на «попробовать микросервисы». Банально нет данных на отзывчивость под нагрузкой. А мы на одной неверной транзакции можем обанкротиться. Это не сервис гугла, и не инстаграм, где недопоказ картинки обернется максимум воплями имярека в бложике.
Так что экономически го тоже не фонтан. Если не пытаться сэкономить три копейки прямо сейчас, полностью наплевав на потенциальное будущее.
Но и даже в этой ситуации я не вижу преимуществ го. Историй успеха нет. «Мы переписали все с руби на скала» и получили 20× преимущество — слышал. «Аккуратно переписали проксирование и получили 40×» — было. Написали свою виртуальную машину для обработки PHP — помню. А вот выбросили виртуальную машину Java в пользу го и теперь все круто — только на уровне недотеп из никому не известных компаний.
Да и само понятие «экономический аспект» вы понимаете неправильно. Наша контора, например, пока растет быстрее, чем развивается го. Поэтому на сегодняшний день я даже не рассматриваю го в качестве варианта на «попробовать микросервисы». Банально нет данных на отзывчивость под нагрузкой. А мы на одной неверной транзакции можем обанкротиться. Это не сервис гугла, и не инстаграм, где недопоказ картинки обернется максимум воплями имярека в бложике.
Так что экономически го тоже не фонтан. Если не пытаться сэкономить три копейки прямо сейчас, полностью наплевав на потенциальное будущее.
Хотите обсуждать красоту синтаксиса? Можно. Но вот сколько задач вы сможете решить с помощью того или иного языка за один период рабочего времени — это уже экономический аспект. Равно как и сколько рабочего времени потребуется другим программистам, чтобы начать полноценно поддерживать эти ваши решения. И сколько серверов потребуется, чтобы ваши решения обслуживали 100500 запросов.
Так «не фонтан» или «нет данных»?
Так «не фонтан» или «нет данных»?
Видите ли, в продакшене «нет данных» ≡ «не фонтан».
Эрланг 30 лет боролся за свои 15 девяток. Я уже довольно давно решения для задач бизнеса выбираю не в детском саду.
Эрланг 30 лет боролся за свои 15 девяток. Я уже довольно давно решения для задач бизнеса выбираю не в детском саду.
В продакшене «нет данных» эквивалентно «мы ленивы и не провели тестирования».
Да ну? Куда ваши экономические критерии-то подевались? У меня нет свободных даже трех программистов, чтобы попробовать перевести что-нибудь на го и «провести тестирование».
А тестирование fps в вакууме — это вон к диванному аналитику с таким штатом в подчинении, что там можно полк отрядить тестировать.
А тестирование fps в вакууме — это вон к диванному аналитику с таким штатом в подчинении, что там можно полк отрядить тестировать.
На нет и суда нет. Так бы сразу и говорили, что ресурсов на стратегические исследования у вас нет.
У меня есть ресурсы на проведение стратегических исследований. У меня нет ресурсов на «попробовать хипстерский язык из-за невнятных статеек на хабре».
Я не могу себе позволить пробовать все, что нынче модно. Я вынужден выбирать. И основной критерий выбора — наличие очевидных плюсов в сравнении с имеющимся стеком. У го таких плюсов нет, пока что, по крайней мере.
Я не могу себе позволить пробовать все, что нынче модно. Я вынужден выбирать. И основной критерий выбора — наличие очевидных плюсов в сравнении с имеющимся стеком. У го таких плюсов нет, пока что, по крайней мере.
Видимо у Гугла, Дропбокса, Хероку, Докера, Монги и т. д. есть ресурсы на «попробовать хипстерский язык из-за невнятных статеек на хабре» :) Вот прямо мониторят Хабр и начинают после этого пробовать.
Не нет плюсов, а вы не знаете этих плюсов, потому что судите об языке лишь по «невнятным статейкам на хабре».
Не нет плюсов, а вы не знаете этих плюсов, потому что судите об языке лишь по «невнятным статейкам на хабре».
> Видимо у Гугла, Дропбокса, Хероку, Докера, Монги
Да, у гугла ресурсов больше. Это довольно внезапно, согласитесь, так-то обычно я привык к обратному.
> вы не знаете этих плюсов, потому что судите об языке лишь по «невнятным статейкам на хабре»
О, аргументы «ad hominem», это я люблю. «Это я бомбил Балканы, я зарезал Корвалана и Александра Мирзояна я планировал убить.»
Мне даже добавить-то нечего, настолько это все смешно и по-детски.
Да, у гугла ресурсов больше. Это довольно внезапно, согласитесь, так-то обычно я привык к обратному.
> вы не знаете этих плюсов, потому что судите об языке лишь по «невнятным статейкам на хабре»
О, аргументы «ad hominem», это я люблю. «Это я бомбил Балканы, я зарезал Корвалана и Александра Мирзояна я планировал убить.»
Мне даже добавить-то нечего, настолько это все смешно и по-детски.
А назовите, пожалуйста, причину, по которой тот же докер выбрал Go? Я из их презентаций не слышал киллер фичи, из-за которой он был выбран. И складывается как раз ощущение, что был выбран, потому что модно и интересно, а потом внезапно взлетело. Сам докер то внезапно взлетел, в его success-story не видно никакого планирования долгосрочного. Была внутренняя утилита, переписали для народа — внезапно взлетело.
Не думали что я могу быть активным сторонником нескольких языков? Не стоит путать активных сторонников и фанатиков. Я лично знаю 3 языка, и мне нравится выбирать между ними и писать на разных, я люблю изучить что-то новое, но при этом у меня есть личные предпочтения, и я старюсь быть обьективным глядя через призму своего опыта а не кричать с пеной у рта что го «самыйлучшийилучшенегонетиникогаднебудет!!!!». Так что не нужно преувеличивать.
Хотя есть намеки на то, что было много команд.
Ткните носом, пожалуйста. А я в ответ ткну вас в намёки о том, что команда была одна.
Ткните носом, пожалуйста. А я в ответ ткну вас в намёки о том, что команда была одна.
«предоставлять приятный DSL для наших аналитиков»
или вот
«Сейчас у нас большинство наших проектов написаны на Go, и последний сопротивляющийся Go программист буквально на днях написал свой первый Go проект и сказал мне следующее: «Ухты, я прочёл код библиотеки один раз и я знал, что она делае»
— очевидно, что если был разработчик, который сопротивлялся Go, значит у него была возможность работать над продуктами на Scala, а значит он был в своем микро-тиме.
Хотя, в любом случае очевидно, что 200 человек требуют определенную организацию и иерархию. Но в статье, и вправду. деталей про это нет. Можете написать автору, если очень интересно, думаю он с удовольствием откликнется.
В общем, компани хотят пользоваться готовыми недорогоми доступными на рынке разработчиками, а вкладываться в образование сотрудников не хотят.
А вы как бы поступали, если бы у вашего тима был выбор между двумя инструментами, которые подходят примерно одинаково, но на один вход занимает месяцы, а на другой недели?
Я бы предложил любителям использования scalaz прочитать по ней лекцию. Пара часов в неделю хватило бы, что бы подтянуть команду к общему уровню.
К тому же я не соглашусь, что инструменты «примерно одикановы». Scala лучше приспособлена для написания обобщенного и повторно используемого кода, в том числе DSL. С ростом проекта это может стать очень полезным.
К тому же я не соглашусь, что инструменты «примерно одикановы». Scala лучше приспособлена для написания обобщенного и повторно используемого кода, в том числе DSL. С ростом проекта это может стать очень полезным.
С ростом проекта это может стать очень полезным.
Интересно, но человек с достаточно хорошим опытом в этом плане пишет ровно наоборот. У вас другой опыт? Поделитесь?
В частности разработка достаточно примитивного DSL у нас помогла в разработке тестов — написанные на Scala получились проще и в общем то читабельнее, чем на питоне. (С небольшой поправкой — мы продолжили использовать асинхронное API, которое применяется и в основном коде, что оказалось не совсем просто объяснить питоновским тестерам.)
Вход в Scala занимает месяцы? Это где вы такое прочитали?
В статье же. И речь не про Scala, а про проекты на Scala, как я понял, ну или и то и другое.
Со Scala всегда сначала есть кривая обучения в JVM, мир Java контейнеров, тёмная магия тюнинга JVM и так далее.
Новые разработчики входили теперь в игру за недели, а не за месяцы.
Ну я в Scala пришел практически не зная Java — через Haskell и C++. Тюнить jvm приходилось очень редко и проблема как правило легко гуглилась.
Возможно у них в компании все так печально, у меня на первой работе на устновку JVM давали 4 часа. Ну и тюнингом новички обычно не занимаются. Да и какой там тюнинг, в 99% случаев его нет вообще, кроме 3х параметров "-server -Xms -Xmx". Java контейнеры это бинарники, просто JVM ориентированные, никакого там сюрприза для человека который например пользовался gcc до этого нет.
Статья произвела, так скажем, гнетущее впечатление.
Во-первых, про spaceship operator. В go можно использовать уникод в именах переменных: play.golang.org/p/CcskBn6Y8Y. Так что запутать код можно на отличненько, если захотеть.
Во-вторых, и видимо это главный движущий фактор всех этих переходов, на Go очень хорошо получается «тяп ляп и в продакшен», а за счёт отсутствующей системы типов каждый раз приходится переписывать базовые вещи типа коллекций, что, видимо, повышает, как это, instant gratification?
Не поймите меня превратно — я сам пишу на go довольно много, но то, что код на Go легче поддерживать, чем на Scala — опасное заблуждение :(
ЗЫ. Есть некоторые паттерны, которые превращают вашу жизнь в ад. Например:
os.Stdin, os.Stdout = os.Stdout, os.Stdin // lol
ну или чуть менее адово, но тоже весело:
io.EOF, io.ErrClosedPipe = io.ErrClosedPipe, io.EOF
Я уже не говорю о — нет, даже не о if err != nil, а о func (s *Foo) Bar() { if s == nil {… // прощайте запястья
Во-первых, про spaceship operator. В go можно использовать уникод в именах переменных: play.golang.org/p/CcskBn6Y8Y. Так что запутать код можно на отличненько, если захотеть.
Во-вторых, и видимо это главный движущий фактор всех этих переходов, на Go очень хорошо получается «тяп ляп и в продакшен», а за счёт отсутствующей системы типов каждый раз приходится переписывать базовые вещи типа коллекций, что, видимо, повышает, как это, instant gratification?
Не поймите меня превратно — я сам пишу на go довольно много, но то, что код на Go легче поддерживать, чем на Scala — опасное заблуждение :(
ЗЫ. Есть некоторые паттерны, которые превращают вашу жизнь в ад. Например:
os.Stdin, os.Stdout = os.Stdout, os.Stdin // lol
ну или чуть менее адово, но тоже весело:
io.EOF, io.ErrClosedPipe = io.ErrClosedPipe, io.EOF
Я уже не говорю о — нет, даже не о if err != nil, а о func (s *Foo) Bar() { if s == nil {… // прощайте запястья
В go можно использовать уникод в именах переменных
Вы утверждаете, что вот тот spaceship operator это то же самое, что вставить нарочно уникод символ для запутывания? И что, они, после того, как разобрались, кто написал это, не поняли диверсию? Или это всё же не одно и тоже?
на Go очень хорошо получается «тяп ляп и в продакшен»
Это вы так называете низкий порог входа? То-есть, по вашему, чем сложнее технология (в идеале несколько лет на хелло ворлд), там качественнее будет продакшен?
но то, что код на Go легче поддерживать, чем на Scala — опасное заблуждение
Обоснуйте, пожалуйста. Всё таки статью не школьник писал, а человек с приличным опытом и в Scala, и уже в Go.
Есть некоторые паттерны, которые превращают вашу жизнь в ад. Например:
os.Stdin, os.Stdout = os.Stdout, os.Stdin // lol
С какой стати код с подменой переменных стал «паттерном»?
жду следующих переводов этой же компании про «как мы перешли от Go к Pascal», потому что в Го есть кодогенерация и никто из нас не понимал, что она делает. А программист который это написал, был в отпуске.
Как отметили комментаторы выше — это просто попытка уйти от проблемы. Такие статьи — отличная антиреклама для Го
Как отметили комментаторы выше — это просто попытка уйти от проблемы. Такие статьи — отличная антиреклама для Го
жду следующих переводов этой же компании про «как мы перешли от Go к Pascal»
Что-то мне подсказывает, что вы не дождётесь)
Пока что я встречал только одну статью об уходе с Go (на питон), написана она была мозилловцем, который ратовал за Rust, и доказывал, что «питон сравним по использованию памяти с Go» с пометкой «если у Go потекут горутины» )))
Такие статьи — отличная антиреклама для Го
Думаю, наоборот )
Что-то мне подсказывает, что вы не дождётесь)
Ну или «Почему Go не решает проблемы».
Потому что с такими как у них процессами разработки все произойдет так:
1. Они будут кодить/быдлокодить на Go, потому что писать на новом языке нужно привыкать.
2. Зафигашат кучу кодогенерации при помощи сторонних самонаписанных утилит.
3. Никто кроме тех, кто их написал не будут знать, как они работают.
4. Вуяла, проблем стало еще больше.
Думаю, наоборот )
Вы вот словили тонны возмущения в комментариях и ничего не поняли?
Возмущения не потому, что Go — плохой язык или все любят Scala, а потому что статья совершенно мерзко относится к Go.
В статье сразу выставлен на показ корень проблем компании — у них не настроен процесс разработки. У них нет взаимозаменяемости между программистами, если один из них ушел в отпуск. У них нет code review, который пропустил такой кусок кода. У них нет приблизительных стандартов. У них вообще нет ничего, кроме стиля «каждый кодит как хочет».
Главный мотив статьи:
что он решает нам массу проблем со Scala на организационном уровне
В корне ошибочен. Go этого не делает. И это очевидно для всех, кроме вас и технического директора.
Ну а про анти-рекламу. То, что именно такая статья, которая имеет в себе очевидно ложный посыл и еще кучу ложных (Системы сброки для Go лучше, чем системы сборки из мира Java) и откровенно глупых фактов (Мы не осилили SBT только один из 50 человек знал, как она работает) дает впечетление, что для Go нельзя написать ничего лучше. Нельзя написать статей в стиле «Мы переписали наш адекватный проект с Scala на Go и получили 2-х кратный прирост производительности». Или «мы перешли со Scala на Go и смогли переписать наш ужасный код, который решал ужасную проблему в более простой форме».
Потому что с такими как у них процессами разработки все произойдет так:
Радует ваша уверенность в предсказании будущего ) У вас всё так просто и понятно.
Вы вот словили тонны возмущения в комментариях и ничего не поняли?
Поверьте, всю эту «тонну возмущения» пишут одни и те же люди, которых я знаю уже по никам наизусть. Тут у них своя тусовка Go-хейтеров. Они все знают, как правильно управлять командами 200+ человек. но сильно обижаются, когда спрашиваешь, был ли у них опыт управления хоть одним человеком. Так что не обольщайтесь.
В статье сразу выставлен на показ корень проблем компании — у них не настроен процесс разработки. У них нет взаимозаменяемости между программистами, если один из них ушел в отпуск. У них нет code review, который пропустил такой кусок кода. У них нет приблизительных стандартов. У них вообще нет ничего, кроме стиля «каждый кодит как хочет».
Вы отчасти правы, но лишь в теории. В мире нет компаний, у которых все идеально, люди работают как роботы по гайдлайнам, и в организационном плане никаких проблем. Это миф. Даже гиганты, которые тут добились хороших успехов, имеют массу головой боли. Не нужно себя обманывать — я поэтому и спрашиваю людей, был ли у них реальный опыт или они теоретизируют, опираясь на картинку в голове.
И именно поэтому, инструмент тоже играет важную роль, принося дополнительную сложность (accidental complexity) в том числе в организационные процессы разработки.
Ну а вы тут не правы в том, что вы взяли один пример, который автор привел для демонстрации, экстраполировали его на всю компанию, на все процессы и считаете, что понимаете степень их компетентности и уровня организации.
И это очевидно для всех, кроме вас и технического директора.
Зато мудрые хабравчане без опыта менеджмента всё видят. Эх, ваши б познания да в благое русло — столько денег могли бы срубить! )
Ну а про анти-рекламу… дает впечетление, что для Go нельзя написать ничего лучше.
Ну я понял ваш посыл, но считаю его в корне неверным из-за излишней предвзятости. Считаете, что после этой статьи тысячи программистов разбегутся и поставят на Go крест — пожалуйста, считайте. Я же убежден, что эффект будет иной.
Поверьте, всю эту «тонну возмущения» пишут одни и те же люди, которых я знаю уже по никам наизусть. Тут у них своя тусовка Go-хейтеров. Они все знают, как правильно управлять командами 200+ человек. но сильно обижаются, когда спрашиваешь, был ли у них опыт управления хоть одним человеком. Так что не обольщайтесь.
У вас проблемы с Go-хейтерами. Вы в каждом человеке видите такого.
Зато мудрые хабравчане без опыта менеджмента всё видят. Эх, ваши б познания да в благое русло — столько денег могли бы срубить! )
Подскажите тогда, раз вы у нас опытный и продвинутый, как именно Go решает такие проблемы как:
- Отсутствие code review
- Отсутствие заменяемости программистов
- Отсутствие гайдлайнов
И именно поэтому, инструмент тоже играет важную роль, принося дополнительную сложность (accidental complexity) в том числе в организационные процессы разработки.
И по этому над этими проблемами нужно работать. Если вы думаете, что в Go нельзя написать код, который никто не поймет, я уже привел вам выше пример. А еще там есть С-шный вставки прямо в комментариях. И так далее.
А еще в Go нет стандартного инструмента для сборки с управлениям зависимостями.
А еще в нем куча других организационных проблем.
У вас проблемы с Go-хейтерами. Вы в каждом человеке видите такого.
Да нет, это вы мне приписываете. У нас вообще с вами дискуссия в стиле " — Вы считаете, что 2х2=5. — Нет, я так не считаю.". Скучно же.
как именно Go решает такие проблемы как:
Отсутствие code review
Отсутствие заменяемости программистов
Отсутствие гайдлайнов
Код-ревью не решает, конечно же. Заменяемость решает тем. что, как и описано в статье, можно взять человека почти с любым бекграундом и за недели иметь программиста, способного писать и поддерживать проекты на Go. Гайдлайны не нужны, потому что в Go очень мало способов сделать одно и то же разными способами, он сам по себе гайдлайн.
А еще в нем куча других организационных проблем.
Никто ж не спорит. Вопрос в том, насколько эти проблемы сравнимы с проблемами при использовании других языков на практике.
Знаете, безотносительно Go я слабо верю в простоту.
Ведь мы это всё уже проходили. Помните 1996 год? :)
Java появилась ровно с тем же набором аргументов: C++ толстый язык, в нём масса сложного (указатели, препроцессор), масса всяких legacy-инструментов (include макросы и т.п.), а мы сейчас сделаем простое и удобное. И что? Прошло 20 лет, и теперь Java такой же монстр. И с C# та же точно история, сравните с чего язык начался, и к чему пришёл.
Соответственно, простой язык — это что-то вроде Эсперанто: либо он неизбежно начнёт усложняться от столкновения с реальным миром, либо обречён на использование некой узкой тусовкой (пусть даже и вполне достойной). Иного я не видел до сих пор, и не понимаю, почему что-то должно стать иначе.
Ведь мы это всё уже проходили. Помните 1996 год? :)
Java появилась ровно с тем же набором аргументов: C++ толстый язык, в нём масса сложного (указатели, препроцессор), масса всяких legacy-инструментов (include макросы и т.п.), а мы сейчас сделаем простое и удобное. И что? Прошло 20 лет, и теперь Java такой же монстр. И с C# та же точно история, сравните с чего язык начался, и к чему пришёл.
Соответственно, простой язык — это что-то вроде Эсперанто: либо он неизбежно начнёт усложняться от столкновения с реальным миром, либо обречён на использование некой узкой тусовкой (пусть даже и вполне достойной). Иного я не видел до сих пор, и не понимаю, почему что-то должно стать иначе.
Знаете, безотносительно Go я слабо верю в простоту.
Верю. Я знаю немало программистов, которые считают, что чем сложнее технология, тем она правильная. Или даже в другой форме — что сложную технологию нужно учить, потому что это даст финансовую выгоду. Но я прямо противоположного мнения, и, к счастью, мои взгляды совпадают с массой трудов, книг и статей на эту тему.
Java появилась ровно с тем же набором аргументов
Во-первых, не с ровно таким же. Go — это первый язык, где «выпиливание фич» сделано намеренно, принципиально и бесжалстно, и в том числе, из-за опыта Джавы. Во-вторых, даже если бы это было так — вы же не станете экстраполировать частное на общее. Законы логики ж помешают делать такой вывод :)
он неизбежно начнёт усложняться от столкновения с реальным миром
Не начнёт, авторы год за годом повторяются — язык меняться не будет. И их достаточно много атакуют за это, студенты-любители эксепшенов и дженериков. :) А с миром реальным он давно уже столкнулся, поверьте.
ОК, он меняться не будет, и значит, останется ровно там же, где и был.
Это тоже вполне нормальный метод существования: вот наши принципы, и мы не будем прогибаться.
Надо понимать, что Java / C++ / C# ровно потому и сидят уже десять лет в десятке, что готовы изменяться и усложняться.
В данном случае «сложность» — это не самоцель, фраза «чем сложнее технология, тем она правильная», конечно, бредова. Сложность — это что-то вроде функциональности MS Word: любому нормальному юзеру 90% всех функций нафиг не нужно. Проблема в том, что разным юзерам нужны разные 10%, и именно потому Word и лидер рынка, хоть от него и плюются.
Соответственно, у авторов языка есть выбор: либо становится монстром а-ля Word и обслуживать огромную массу пользователей с разными потребностями, либо становиться нишевым продуктом. Как раз эта логика подтверждается огромной массой практических примеров из самых разных областей.
Это тоже вполне нормальный метод существования: вот наши принципы, и мы не будем прогибаться.
Надо понимать, что Java / C++ / C# ровно потому и сидят уже десять лет в десятке, что готовы изменяться и усложняться.
В данном случае «сложность» — это не самоцель, фраза «чем сложнее технология, тем она правильная», конечно, бредова. Сложность — это что-то вроде функциональности MS Word: любому нормальному юзеру 90% всех функций нафиг не нужно. Проблема в том, что разным юзерам нужны разные 10%, и именно потому Word и лидер рынка, хоть от него и плюются.
Соответственно, у авторов языка есть выбор: либо становится монстром а-ля Word и обслуживать огромную массу пользователей с разными потребностями, либо становиться нишевым продуктом. Как раз эта логика подтверждается огромной массой практических примеров из самых разных областей.
либо он неизбежно начнёт усложняться от столкновения с реальным миром
Надо понимать, что Java / C++ / C# ровно потому и сидят уже десять лет в десятке, что готовы изменяться и усложняться.
Вам и если язык меняется — плохо, и если не меняется — тоже плохо. Как тяжело жить! :)
Go — это первый язык, где «выпиливание фич» сделано намеренно, принципиально и бесжалстно, и в том числе, из-за опыта Джавы
Странная логика. В чем отличие Java/С# от C++? В том что выпилили половину фич C++: макросы, указатели, хитрые способы работы с памятью, деструкторы и т.д. В Java 1 сознательно оставили процентов 20 от всех фич и возможностей С++. Так что говорить что Go такой первый язык — нелепо.
В Java 1 сознательно оставили процентов 20 от всех фич и возможностей С++. Так что говорить что Go такой первый язык — нелепо.
Ну, если вы правы, и в Java 1 действительно 20% от функционала С++, то наверное, и вправду, не первый. Но я не знаю так детально историю Java, не могу оценить насколько вы правы.
Код-ревью не решает, конечно же. Заменяемость решает тем. что, как и описано в статье, можно взять человека почти с любым бекграундом и за недели иметь программиста, способного писать и поддерживать проекты на Go. Гайдлайны не нужны, потому что в Go очень мало способов сделать одно и то же разными способами, он сам по себе гайдлайн.
Кодогенерация и сишные вставки решают.
На Go много способов сделать так, что бы код выглядел ужасно. Он собственно и будет так выглядеть, если вы пересадите программиста со Scala на Go.
У меня ощущение, что для адептов Go, есть специальные лагеря для тренировок поведения в комьюнити. По типу спецназовских. Где их специально натаскивают использовать все самые идиотские методы ведения дискуссий. Например софистики.
Редко увидишь такое слепое и самоуверенное следование своим выдуманным кумирам.
Ну как можно оспаривать мнение «целого технического директора компании из 200+ человек»?? Это же почти бог, который никогда не ошибается. Ему надо просто внемлить. И никак иначе.
У тебя нет опыта управления командой из 200+ человек? В топку. Ты лох и ничего не можешь иметь слова в этом вопросе. И пофиг, что все адекватные управленцы в один голос говорят, что если можешь управлять 10 людьми, то сможешь и 200. Принципы управления не изменятся.
И да, я сейчас говорю про управлять, а не числиться на должности управленца.
Редко увидишь такое слепое и самоуверенное следование своим выдуманным кумирам.
Ну как можно оспаривать мнение «целого технического директора компании из 200+ человек»?? Это же почти бог, который никогда не ошибается. Ему надо просто внемлить. И никак иначе.
У тебя нет опыта управления командой из 200+ человек? В топку. Ты лох и ничего не можешь иметь слова в этом вопросе. И пофиг, что все адекватные управленцы в один голос говорят, что если можешь управлять 10 людьми, то сможешь и 200. Принципы управления не изменятся.
И да, я сейчас говорю про управлять, а не числиться на должности управленца.
Редко увидишь такое слепое и самоуверенное следование своим выдуманным кумирам.
Каким кумирам? )
У тебя нет опыта управления командой из 200+ человек? В топку. Ты лох и ничего не можешь иметь слова в этом вопросе.
Как-то вы слишком болезненно все воспринимаете. Слово может иметь каждый, но, согласитесь, когда человек без опыта рассказывает «как надо» и оскорбляет человека с опытом, который ещё и делится с миром своим опытом, то это выглядит не в пользу первого. И Go тут не причем, это абсолютно любой темы касается.
У меня ощущение, что для адептов Go, есть специальные лагеря для тренировок поведения в комьюнити. По типу спецназовских.
Нет, это неадекватность отдельных хабраперсонажей создает закалку )) Повеселили, спасибо )
Почему не перешли со Scala на Java? Почему не отказались от SBT в пользу Maven? Потому что не модно?
Почему не перешли со Scala на Java?
Думаю, можно написать автору в твиттер. А в чём преимущества перехода на Java, по сравнению с Go?
В том что можешь продолжать использовать весь свой старый код на scala/java, свои привычные IDE и свои привычные инструменты разработки, в том что остается пусть урезаный, но функциональный стиль? В том что программистов Java любого уровня на рынке полно (в отличии от Go), а любой (скорее всего) программист на scala знает Java? Так что такого революционного дает Go по сравнению с Java, чтобы стоило отказываться от всего описанного выше?
Вы забыли что количество готового кода на Java несравнимо больше чем на Go, ну это так мелкое дополнение.
Возможно. Но этим и ценны подобные статьи, рассказывающие о реальном опыте, что по ним можно судить насколько те или иные моменты действительно проблемны или нет. К примеру. то что автор пишет про «расширился пул программистов, которых можем нанимать» кореллирует с моими наблюдениями в других компаниях, перешедших на Go, но идет в разрез с вашей гипотезой о том, что количество программистов на Java может быть преимуществом.
Офигенный тимлид, ага. Не знает о том, что спецсимволы в гугле игнорируются и несколько часов делает то, что grep делает за несколько секунд.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы перешли со Scala на Go