Comments 130
Тернарным условием сейчас никого не удивишь, поскольку она пришло из C++. В данном контексте куда интереснее восклицательный знак. Человек, не знающий языка, просто не сможет правильно прочесть это предложение.
* DDD стремится избежать концептуальных классов, стремясь, чтобы они слились с архитектурными классам, этим не только уменьшается объем работы и документации, но и вводится единый язык.
* В современных проектах документирование пишется в комментариях к коду и на основе его мы получаем чистовую документацию.
Don’t repeat yourself, DRY (рус. не повторяйся) — это принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы»
Здесь ни слова не говорится про то, что он применим только к коду.
Если же приходится выдавать справки в виде псевдокода, мы получаем следующие минусы:
* Дополнительная работа для программиста, которая отрывает его от основной работы.
* Устаревание информации. Через некоторый интервал времени сведения устаревают, после чего требуется псевдокод писать заново.
* Отсутствие цельной картины. Тот кто работал с аналитикой, поймет, что выдавая псевдокод, мы формируем срез по решению конкретной проблемы. Эти отрывочные данные не позволяют увидеть всю многомерную картину.
а об отсутствии преимуществ у альтернативных языков перед Go.
Но ведь это не правда, у других языков полно преимуществ по сравнению с GO просто эти преимущества усложняют понимание кода (хотя это тоже спорное утверждение, читать код на D для меня было проще). Про простоту чтения тоже сомнительное утверждение, да может читать код в go проще например 50 против 20 в другом языке, но насколько я вижу многие вещи в го выражаются куда более многословнее, и получается что в го нужно прочитать 15 строк против 2 в другом языке. Такое себе ускорение.
И ещё
Однако, только короче, но не правильней, поскольку в реализации на D полностью игнорируется проблема обработки ошибок.
Но в ведь в коде GO тоже нет никакой обработки ошибок.
В языке имеются достаточные средства для реализации подобных конструкций. Например, вполне подойдет обобщенное программирование.
Это все прекрасно до тех пор, пока не нужно передавать, например, слайс интерфейсов. Слайс переменных []T, где T — некоторый тип, не удовлетворяет []iface, где iface — некоторый интерфейс.
Варианты:
- Передавать
interface{}и сношаться с рефлексией (как вариант: свести использование до какой-то функции из библиотеки, в том числе стандартной, где сношаются с рефлексей за вас) - Накопипастить / нагенерировать нужные функции
- Каждый раз создавать новый
[]ifaceиз[]T(либо в явном виде, либо через unsafe-магию) Жрать кактусЖдать дженериков, а пока использовать 1, 2 или 3
Именно поэтому разработчики Go не стали реализовывать серебрянную пулю.
Они уже в процессе, на самом деле, но сроков пока нет https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
Я тут недавно yaml с гибкой спецификацией парсил, было весело:
d := map[string]map[string]interface{}{}Так-то это так. Но на деле при парсинге подобного, если по заданной спецификации это возможно, то часто нужно проверить, не является ли этот произвольный тип в своё время картой:
mValue, ok := value.(map[string]interface{})
// далее - проверка ok и возможное использование mValue как map[string]interface{}Действие кажется достаточно безобидным, однако читаемость быстро ухудшается, когда это нужно сделать на нескольких уровнях вложенности структуры yaml.
именно так. ПО хорошему надо было бы в именованные типы вынести, но оно не очень помогает из-за вороха дальнейших кастов (как верно подметил TonyLorencio выше).
Но да, будь в языке дженерики можно было бы сделать у слайса метод который создает такую копию с нужным типом
не позволяющий получить эстетического удовольствия от результата своей работы
Объясните теперь зачем по 8+ часов в день заниматься тем, что не даёт получить эстетическое удовольствие даже теоретически?
Большинство других языков требуют очень тщательного предварительного проектирования. Этим они ближе к водопадной модели создания ПО.
Если же программист желает получать эстетическое удовольствие — добро пожаловать в Haskell.
Если же командная работа имеет приоритет выше, чем личные амбиции, если важен быстрый результат и его непрерывная эволюция, если вас интересует минимизация потребляемых ресурсов и их эффективное использование, то, безусловно, вы остановите свой выбор на Go.
Использую Haskell в проде, всё норм, брат жив, скорость разработки огого, дружественность к рефакторингу тоже. С конкурентностью и параллельностью всё просто супер.то есть и жена и любовница довольны?
:D
PS: с удовольствием почитал ваш ответ про парсер. (да и весь тред ниже)
Какой индустриальный стандарт?
Вы же сами процитировали Пайка
Ключевой момент здесь, что наши программисты не исследователи. Они, как правило, весьма молоды, идут к нам после учебы, возможно изучали Java, или C/C++, или Python. Они не в состоянии понять выдающийся язык, но в то же время мы хотим, чтобы они создавали хорошее ПО. Именно поэтому язык должен прост для понимания и изучения.
Читаем буквально.
Ключевой момент здесь, что наши программисты не
Ну что же… Все логично. Я полностью солидарен с Пайком.
Только вот вывод из цитаты получается строго противоположный заголовку статьи…
Delphi пишется не заглавными буквами, и это IDE, язык же называется object pascal.
Почему нет таких развернутых апологий для котлина? дарта? тайпскрипта? Ведь все они тоже новые модные языки с кучей крутых гитик!
Как мне кажется, все дело в том, что у Go, как языка есть очень жесткие недостатки (обработка ошибок, отсутствие дженериков, синтаксическая бедность) из-за чего он резко констрастирует с тем, как представляется большинством программистов нормальный язык программирования.
Для ряда задач (например, микросервисы или какие-то прокси-сервера) его преимущества, такие как конкурентная модель, позволяют пренебречь этими недостатками, но за пределами этих задачах его преимущества становятся не настолько полезными, а отого и очевидными. А в силу того, что большинство людей не любит не универсальные языки, случаются такие казусы, когда вдохновленные Go люди, которые попробовали его на подходящих проектах, особенно после условной Java EE, кучу абстракций которых они не понимают (а возможно, они им и правда были не нужны) пытаются его впихнуть везде.
Однако, только короче, но не правильней, поскольку в реализации на D полностью игнорируется проблема обработки ошибок.
Я возможно тупой, но не вижу ни обработку ошибок в Go-коде, ни вообще необходимость какой бы то не было обработки ошибок во время сложения и вычитания чисел. Ну и да, одна строчка кода конечно же читается куда легче, чем пол сотни.
Что касается длины программы, то отвечу цитатой про читаемость на языке PERL:
У этого языка есть миллион способов сделать код другого человека полностью нечитаемым, а его немногословность заставляет даже самые простые вещи выглядеть невнятно.
Ну так если мы не делим, то никакой обработки ошибок не надо. Вот когда появится необходимость делить, тогда и добавим. YAGNI во всей красе. И да, в хорошем ЯП отрефакторить код чтобы он начал прокидывать ошибки совершенно несложно.
Да нормальный ГО язык. Нанял пачку манкикодеров из азии и го я создал.
Большое спасибо за статью, хотел обстоятельно пройтись по всем пунктам, получилось довольно много, необессудьте:
Go очень просто научиться, настолько просто, что читать код можно практически без подготовки вообще. Эту особенность языка используют во многих мировых компаниях, когда код читают вместе с непрофильными специалистами (менеджерами, заказчиками и т. д.).
Это неправда, потому что строго говоря на ГО сложных программ вообще не пишут. Несмотря на то, что формально Кубернитес написан на Go, фактически там реализована своя система типов, "класс" Object, реализованы правила именования, идентификации и реестр типов (type registry), соответствие типов проверяется в рантайме (в случае чего выдаётся “no kind is registered for the type …”). Подробнее можно почитать здесь. Интересно, зачем они это сделали?
Роб Пайк (главный идеолог языка) создавал язык Go, как индустриальный язык, который легок в восприятии, эффективен в использовании.
Язык прост в написании кода, но он непрост в выражении предметной области. Например, вопрос, что делает этот цикл:
for i := 1; i <= 10; i++ {
item := a[i]
...
}...
Не догадались?
А вот аналог на каком-нибудь функциональном языке
let result = a.map(|item| ... )И я из сигнатуры вижу, что у нас получается коллекция элементов из оригинального массива a. Мне не нужно смотреть тело цикла чтобы это понять, я вижу это сразу просто по названию. Если надо, я могу углубиться, но часто этой информации мне достаточно чтобы пойти читать код дальше. В го мне придется читать тело цикла в любом случае.
Мудрые слова, не правда ли?
Мудрые для кого? Я вижу в этом только мудрость "давайте использовать студентов во вред им, потому что это сэкономить нам (гуглу) миллиарды". Раньше разработчиков учили, на это тратилось время, но потом они могли писать хороший поддерживаемый код. Теперь разработчиков сажают сразу на манки работу, где сломанный компонент проще переписать заново, но так как программисты только из универа, они очень дешевые, и это получается выгодно. За чей счет банкет? За счет разработчиков. Кто в итоге в плюсе? Бедный-бедный гугл.
Быть простым — это одно из важнейших стремлений в любом дизайне. Как известно, совершенный проект это не тот проект, куда нечего добавить, а тот – в из которого нечего удалить.
Тогда безусловно самый лучший язык это brainfuck, как ближайший аналог тьюринг машины. И вот из него действительно нечего удалить, потому что без любой операции машина не сможет выполнять программы.
Может, простота это не единственный критерий?
Многие мигранты жалуются, что язык не содержит элегантных абстракций. Да, это так, однако это и есть одно из главных достоинств языка.
Свобода это рабство, мир это война. Отсутствие элегантных абстракций это достоинство.
Решение этой же задачи на языке D хотя и выглядит несколько короче, однако, читается ничуть не проще
Я не знаю D, однако программу на нем я понял сразу. В го я зарылся в то, что такое Scanner. И хотя со второго взгляда все стало очевидным, мне понадобилось совершить когнитивное усилие чтобы восстановить алгоритм. В D написано практически по-английски ЧТО нужно получить, в Go написано императивно КАК это сделать. А нас, как разработчиков, обычно больше волнует цель кода, а не то, как он работает. В одном случае мы эту информацию можем получить прямо из исходного кода, в другом случае нужно самостоятельно дедуктивно это определить. ИМХО просто прочитать это из исходника проще.
Новички постоянно жалуются на Go в плане отсутствия дженериков. Для решения этого вопроса большинство из них используют прямое копирование кода.
Поэтому давайте использовать непрямое :) Да, ваш второй вариант будет содержать меньше копи-паста, но все равно foo32 и foo64 придется делать. В случае если мы работаем с интами или любой другой фиксированной иерархией все отлично. Как только диапазон типов в котором надо работать становится открытым, упс.
В языке имеются достаточные средства для реализации подобных конструкций. Например, вполне подойдет обобщенное программирование.
Это не обобщённое программирование. Обобщенные дословно на английский переводится как Generics, угадайте о чем речь.
Однако, только короче, но не правильней, поскольку в реализации на D полностью игнорируется проблема обработки ошибок.
Простите, а какие ошибки тут возможны? На пустой коллекции я думаю будет вариант None возвращаться, а больше ничего плохого случиться не может вроде. И да, я не знаю Go, поэтому давайте сравним реализацию на расте и Го. Пусть есть программа, которая принимает массив строк, и печатает либо вектор распаршенных чисел (если все парсинги завершились успешно) либо ошибку, если хотя бы одно число распарсить не удалось:
fn main() {
do_job(&["1", "2", "3"]);
do_job(&["1", "Not a number", "3"]);
}
fn do_job(input: &[&str]) {
let ints = input.iter().map(|x| {
println!("Trying to parse: {}", x);
x.parse::<i32>()
});
let result: Result<Vec<i32>, _> = ints.collect();
println!("{:?}", result);
}Причем как мы видим, результат выполнения функции оптимальный, на первой же ошибке остановка, мы не пытаемся продолжить выполнение если что-то пошло не так.
Здесь по сути 3 строчки (не считая отладочной печати): парсинг чисел, формирование результата из него, печать результата. Давайте пример аналогичной программы на го, которая делает эту задачу еще проще и понятнее. Правда, очень любопытно было бы глянуть.
В реальной жизни, когда сложность логики возрастает, разрыв стремительно сокращается. Еще стремительней разрыв сокращается, когда требуется выполнить действие, которое не может быть выполнено при помощи стандартных операторов языка.
Нет, разрыв возрастает, потому что происходит комбинаторный взрыв, который в других языках решает компилятор с генериками. Именно поэтому он так долго компилирует. Использовать простым образом ваши комбинаторы у авторов других программ не выйдет. Но это не проблема, ведь копипаст в го является одной из основ идеологии. Что интересно, это является антипаттерном в других языках.
Обобщенное программирование в ряде случаев дает нам неоспоримую выгоду. Это наглядно иллюстрирует нам пакет sort. Так, для сортировки любого списка нам достаточно реализовать интерфейс sort.Interface.
Честно говоря, не вижу в программе ничего про "реализую sort.Interface", только набор несвязных объявленных функций. Чтобы про них узнать, видимо, нужно читать документацию. Как догадаться, какие функции объявлять и с какими сигнатурами не имею представления.
Если Вы возьмете любой open source проект и выполните команду grep "interface{}" -R, то увидите, как часто используются путые интерфейсы.
Пустые интерфейсы это аналог dynamic в C# или другими словами отключение системы типов. Зачем тогда го вообще? Используйте Python. Он, конечно, не поможет на этапе компиляции отловить ошибку "вы пишете в переменную String число", но зато он позволит истинно обобщенное программирование, без рефлексии.
Возьмем к примеру язык DELPHI. Несмотря на наличие у него этих самых дженериков, он содержит специальный тип VARIANT для операций с произвольными типами данных. Аналогично поступает и язык Go.
Хотел давно задать вопрос, а почему мы сравниваем Го с языком 33 летней давности? Неужели с тех пор ничего полезного не изобрели? И да, этот VARIANT остается тем, чем я сказал, признанием в бессилии системы типов и переходом в динамику.
И да, генерики в го есть, но они не для всех. Можно ведь создать []string или []T, с любым T. Видимо, деление на граждан первого сорта (разработчикам языка, которым можно генерики) и всех остальных (которым нельзя) тоже очень важно в го. Вот уж где много магии, когда нельзя скопировать код стандартной библиотеки так, чтобы они скомпилировались.
Кроме того, по эффектвности garbage collector превосходит большинство известных на текущий момент реализаций и уже может быть использован для многих real time задач.
Citation needed
Параллельность и конкурентность языка выше всяких похвал. Ни один низкоуровневый язык не может даже отдаленно конкурировать с языком Go.
Citation needed
Статическая типизация и вывод типов позволяют существенно сократить число ошибок в коде даже без написания тестов. Я знаю некоторых программистов, которые вообще обходятся без написания тестов и при этом качество их кода существенно не страдает.
Но ведь у нас нет системы типов :) Мы постоянно пишем interface {} и отказываемся от них. Из системы типов у нас одни только примитивы, по сути. Да и с типами ничего сделать нельзя, потому что они раскрываются вкупе с обобщенным программированием (которое Generic), а его и нет. А с interface {} никакие типы не нужны, можно было бы как в питоне писать и все бы работало.
Мощная стандартная библиотека, что позволяет в большинстве проектов обходиться без сторонних фреймворков.
Стандартная библиотека не мощная. В нее напихано куча всякой фигни вроде работы с HTTP, но зато до сих пор нет метода удаления элемента из массива. На дворе 2019 год, а люди до сих пор пишут a = append(a[:i], a[i+1:]...).
Язык достаточно мощный, чтобы концентрироваться на задаче, а не на методах ее решения и в то же время достаточно низкоуровневый, чтобы задачу можно было решить эффективно.
Пример выше показывает, что приходится концентрироваться на "как выразить этот очевидный однострочник этими скудными АПИшками". Причем как правило проще нагуглить результат на stackoverflow, где у этого ответа 245 лайков. Сколько сотен тысяч раз был скопирован этот код из-за того, что в стандартной библиотеке его не оказалось? Не берусь считать.
Поскольку основной идеей языка является уменьшение магии, язык стимулирует разработчиков выполнять обработку ошибок явно. И это правильно, поскольку в противном случае, он просто будет забывать вообще про обработку ошибок.
Попробуйте забыть обработку ошибки на примере раста, пожалуйста. Explicit != verbose.
Для тех программистов, у которых личное эго превалирует над командным духом, а также теоретиков, которые любят академические задачи и бесконечное "самосовершенствование", язык действительно плох, поскольку это ремесленнический язык общего назначения, не позволяющий получить эстетического удовольствия от результата своей работы и показать себя профессионалом перед коллегами (при условии, что мы измеряем ум именно этими критериями, а не коэффициентом IQ).
И тут БАХ, и всех несогласных объявили "эгоистами-диванными-теортиками с низким IQ". Это, конечно, очень способствует позитивному восприятию статьи.
Go был разработан, чтобы быть простым и он преуспел в этой цели. Он был написан для умных программистов
У меня нет возражений по всем пунктам, которые явно не выделил в цитатах, но этот хотел отметить отдельно. Я абсолютно полностью с ним согласен. Го действительно получился очень простым. И он действительно написан для умных программистов. Я вообще всегда считал, что чем ближе язык к динамическим, тем умнее надо быть чтобы на нем программировать. На языке с генериками, типами и ограничениями не получится использовать несуществующее поле, изменить неизменяемое значение, записать строку в число, не нужно пользоваться рефлексией чтобы написать обобщенный код, а достаточно сделать генерик-плейсхолдер Т… В динамическом языке нужно держать всё это в голове, знать все поля всех объектов в программе (при том, что типы явно не объявлены, и нужно помнить все инстансы!). Го определенно ближе именно ко второй границе.
Статье поставил плюс. Спасибо за интересное чтение.
Автор ответил чуть ниже, если интересно продолжение обсуждения ищите там :)
λ> parseAll ws = show $ sequence (readEither <$> ws :: [Either String Int])
λ> :t parseAll
parseAll :: [String] -> StringНу по сути тут в одну строчку то же самое записано, что у меня.
Только я не совсем понял, в каком моменте мы от Seq<Either<_, _>> перешли к Either<Seq<_>, _>
Или, если вы не боитесь значков и расширений языка:
Боюсь :)
mapM (readEither Int) ws
Оно нам вернет Either? Потому что я хотел набить данными структуру, а не тупо распечатать :)
Ну, да, идея там ровно та же, просто не нужны никакие iter(), ну и всякие $ и <$> помогают композабельности.
Тут уже особенности языка, когда для итерирования нужно явно создать объект-итератор (с помощью соответствующего метода). Ну а $ и <$> я пока не изучал, решил начать со скалы, ибо она вроде попрактичнее будет. Хотя чем больше изучаю, тем больше кажется, что из-за оопэ раскидали костылей очень обильно. Не считая того, что сахара в стандартной библиотеке хватит для диабета.
Ну а в целом все понятно, да. Большое спасибо. Закончу читать красную книгу, обязательно вернусь в learnyouhaskell :)
Я лично не пробовал, но настрой примерно такой. Хотя жвм и все остальное расстраивают, равно как и угробищный синтаксис.
Что касается ссылки то вроде все не так уж страшно. По сути у нас есть баунды, и вопрос звучит как «почему функа принимающий ковариантный параметр T и возвращающая контрвариантный генерик V контрвариантного типа U не является подтипом T => V[U]»
Вообще, я не вижу хорошего языка на который можно было бы влезть. Вот чтоб как хаскель, но с рынком как у джавы :) Что-то похожее может представлять собой раст, но если его окончательно запинают под шконку системного программирования этого не случится. Плюс некоторые процессы принятия решений в команде языка не очень нравятся. Не сами решения, а именно процессы, которые к ним приводят. Посмотрим, конечно.
Я как понимаю, вам хотелось бы увидеть полноценные do-нотацию и монады? :) Мне кажется, что разработчики решили не расходовать и без того опустошённый strangeness budget (особенно на такие меметичные вещи как монады) и пойти по пути меньшего сопротивления добавив костыли которые покроют львиную долю юзкейсов встречаемых на практике, вместо поиска какого-то более обобщённого решения. Т.е. рассказывать людям приходящим с JS/Питона/etc. об async/await и ? значительно проще и это будет вызывает меньше отторжения по сравнению с монадами. Хотя, конечно, вместо Pin/Unpin я бы тоже предпочёл иметь более общее решение для ссылающихся на самих себя структур.
Другим моментом является сколько времени понадобится на выработку дизайна и стабилизацию данной функциональности, что бы оно ещё и компилировалось в эффективные бинарники за разумное время? Сколько уже мурыжат весьма урезанные по функциональности const generics? Боюсь на do-нотацию и обобщённую систему эффектов ушло бы существенно больше времени и всё это время мы бы жили без удобств которые дают `?` и `async`/`await`, что, опять же, сказалось бы достаточно негативно на популярности языка.
В общем, в сферически-вакуумной ситуации я бы вероятно тоже предпочёл более мощный и обобщённый язык, но в условиях жёсткой конкуренции за разработчиков и учитывая что без богатой экосистемы библиотек разрабатываемой и поддерживаемой большим сообществом какой бы язык не был классный его ценность в индустрии будет низкой, мне кажется использование подобных «костылей» достаточно разумный и просчитанный шаг. Иначе говоря: «лучшее враг хорошего».
У общих решений есть плюс, что ими можно пользоваться порционно. Например, можно было бы сделать do и единственной монадой был бы Either и Option. Как сейчас оно и есть с ?, просто был бы другой синтаксис. Потом добавили бы await. Потом еще что-нибудь. Это ведь просто вопрос удобства и переиспользования.
Другим моментом является сколько времени понадобится на выработку дизайна и стабилизацию данной функциональности, что бы оно ещё и компилировалось в эффективные бинарники за разумное время? Сколько уже мурыжат весьма урезанные по функциональности const generics?
Нисколько, потому что их не делают вообще. Они заблокированы chalk'ом, которого нет.
Разница подхода в том, что Раст стремится стать «успешным», т.е. в каком-то смысле противоположно «avoid success at all costs».
Эта фраза немного другое означает, и в оригинальной формулировке я даже с ней согласен.
Возьмем к примеру язык DELPHI. Несмотря на наличие у него этих самых дженериков, он содержит специальный тип VARIANT для операций с произвольными типами данных.
ЕМНИП дженерики в делфи завезли в версии 2009 года. При этом вариантами пользовались чуть ли не с первой версии… Так себе аналогия получается
Вкратце пройдусь по некоторым пунктам Вашего комментария.
Раньше разработчиков учили, на это тратилось время, но потом они могли писать хороший поддерживаемый код. Теперь разработчиков сажают сразу на манки работу, где сломанный компонент проще переписать заново, но так как программисты только из универа, они очень дешевые, и это получается выгодно. За чей счет банкет? За счет разработчиков. Кто в итоге в плюсе? Бедный-бедный гугл.
У каждой медали две стороны. Вы заняли пессимистическую позицию. Представьте ситуацию: токарь 30 лет работал, вытачивал одну и ту же деталь. Причем вытачивал в совершенстве. В один прекрасный момент пришел инженер изменил конструкцию так, что эта деталь стала не нужна. Вопрос: что от этого потерял мир? Так может лучше остановить технический прогресс вообще?
Тогда безусловно самый лучший язык это brainfuck, как ближайший аналог тьюринг машины. И вот из него действительно нечего удалить, потому что без любой операции машина не сможет выполнять программы.
Язык Go хорош тем, что он легко читается даже непосвященным человеков (практически не тяжелее псевдокода).
Свобода это рабство, мир это война. Отсутствие элегантных абстракций это достоинство.
Любые элегантные абстракции возможны только на предметно-ориентированном языке. Так, ни в одном языке нет всей полноты математических выражений, встроенных в язык. За все в этом мире нужно платить, в том числе и за элегантные абстракции.
Но ведь у нас нет системы типов :) Мы постоянно пишем interface {} и отказываемся от них. Из системы типов у нас одни только примитивы, по сути. Да и с типами ничего сделать нельзя, потому что они раскрываются вкупе с обобщенным программированием (которое Generic), а его и нет. А с interface {} никакие типы не нужны, можно было бы как в питоне писать и все бы работало.
Все совсем не так. Большинство кода вообще не требует работы с generic. Именно там нам и дает выигрыш Go, как сильно типизированный язык.
Хотел давно задать вопрос, а почему мы сравниваем Го с языком 33 летней давности? Неужели с тех пор ничего полезного не изобрели? И да, этот VARIANT остается тем, чем я сказал, признанием в бессилии системы типов и переходом в динамику.
Мы сравниваем его с разными языками, в том числе и с C++, который еще более древний. А язык Delphi, как и C++ существовал и будет существовать еще длительное время.
Что же касается бессилия системы типов, то да, в некоторых случаях и дженерики не всегда могут помочь в решении проблемы. Например, в том же Delphi мы пишем предметно-ориентированную библиотеку для работы с той же математикой. Мы можем использовать тип Variant, который должен работать с комплексными числами, автоматическим приведением типов, а также с выводом результатов на экран. Ни один дженерик в этом нам помочь не сможет.
Попробуйте забыть обработку ошибки на примере раста.
Согласен, но вы забыли указать, что у большинства то языков нет таких встроенных механизмов.
И тут БАХ, и всех несогласных объявили «эгоистами-диванными-теортиками с низким IQ».
Вы немножко передернули. В статье же явно сказано
при условии, что мы измеряем ум именно этими критериями, а не коэффициентом IQ
По-хорошему есть кнопка "ответить" чтобы комментарии были структурированы, теперь же они будут висеть несвязными.
У каждой медали две стороны. Вы заняли пессимистическую позицию. Представьте ситуацию: токарь 30 лет работал, вытачивал одну и ту же деталь. Причем вытачивал в совершенстве. В один прекрасный момент пришел инженер изменил конструкцию так, что эта деталь стала не нужна. Вопрос: что от этого потерял мир? Так может лучше остановить технический прогресс вообще?
За аналогиями обычно пытаются скрыть отсутствие аргументации. Давайте прямо скажем, что за токари, на чем они писали, и кому они теперь не нужны? И что за риторический вопрос в конце, при чем тут мир? Мы вроде обсуждаем более приземленные вещи.
Язык Go хорош тем, что он легко читается даже непосвященным человеков (практически не тяжелее псевдокода).
Вам несколько человек сказали, что ваш код на Го труднее читать чем на D, при том что я ни тот, ни другой не знаю. И да, я набросал программку для сравнение, не поленитесь пожалуйста показать аналог на го. Хочется сравнить простоту и читаемость.
Любые элегантные абстракции возможны только на предметно-ориентированном языке. Так, ни в одном языке нет всей полноты математических выражений, встроенных в язык. За все в этом мире нужно платить, в том числе и за элегантные абстракции.
Programming Defeatism: No technique will remove all bugs, so let's go with what worked in the 70s.
Все совсем не так. Большинство кода вообще не требует работы с generic. Именно там нам и дает выигрыш Go, как сильно типизированный язык.
Статистику в студию, потому что мой личный опыт говорит о противоположенном. Я даже в прикладном коде часто подобные обобщения:
protected static async Task<TransactionReceipt> WrapTransactionAsync(
Func<Task<TransactionReceipt>> operation,
params (Func<Task<bool>> isBusinessRuleFailed, Func<Exception> businessExceptionFunc)[] checks)
{
try
{
return await operation();
}
catch (TransactionFailedException)
{
foreach (var (isBusinessRuleFailedAsync, businessExceptionFunc) in checks)
{
if (await isBusinessRuleFailedAsync())
{
throw businessExceptionFunc();
}
}
throw;
}
}Потому что после этого их очень легко переиспользовать:
public Task<TransactionReceipt> ValidateTransactionAsync(string transactionHash, RequestStatusUpdate requestStatusUpdate)
{
return WrapTransactionAsync(
() => Web3.Client.GetTransactionReceiptAsync(transactionHash),
(
() => IsNewRequestAsync(requestStatusUpdate.ServiceNumber),
() => new RequestNotFoundException(requestStatusUpdate.ServiceNumber)
),
(
async () => !await IsNewStatusAsync(requestStatusUpdate),
() => new StatusAlreadyExistsException(requestStatusUpdate)
));
}И тут мне или от обобщения отказываться, или идти копипастить в 100 местах одно и то же. Причем я к обобщению этому пришел, когда словил в очередной раз проклятие копипасты, когда я поправил баг в 99 местах, а в одном забыл.
Мы сравниваем его с разными языками, в том числе и с C++, который еще более древний. А язык Delphi, как и C++ существовал и будет существовать еще длительное время.
Что же касается бессилия системы типов, то да, в некоторых случаях и дженерики не всегда могут помочь в решении проблемы. Например, в том же Delphi мы пишем предметно-ориентированную библиотеку для работы с той же математикой. Мы можем использовать тип Variant, который должен работать с комплексными числами, автоматическим приведением типов, а также с выводом результатов на экран. Ни один дженерик в этом нам помочь не сможет.
Ну давайте сравним с Rust, благо он появился примерно в то же время. Давайте с C#/Kotlin, которые не менее "тырпрайзные" и приземленные, не в угоду ленивым теоретикам с низким IQ.
Согласен, но вы забыли указать, что у большинства то языков нет таких встроенных механизмов.
Но ведь это не повод делать в го неудобно.
Вы немножко передернули. В статье же явно сказано
Лично я цитату "они умные, но при условии, что мы измеряем ум именно этими критериями, а не коэффициентом IQ" как раз-таки как завуалированное сомнение в этих-самых способностях, иначе зачем эта часть в статье я вообще затрудняюсь сказать. Уверен, у большинства читающих сложилось то же впечатление.
За аналогиями обычно пытаются скрыть отсутствие аргументации. Давайте прямо скажем, что за токари, на чем они писали, и кому они теперь не нужны? И что за риторический вопрос в конце, при чем тут мир? Мы вроде обсуждаем более приземленные вещи.
Это можно назвать как прецедентом так и метафорой. В юридической системе обычно прецедент является веским аргументом.
Статистику в студию, потому что мой личный опыт говорит о противоположенном. Я даже в прикладном коде часто подобные обобщения:
Статистику привести не могу, поскольку не занимался этой проблемой, однако, можете сами посмотреть на github проекты и посмотреть составляющий их процент копипаста. Например, вы можете посмотреть мою ветку проекта Echo(http://github.com/adverax/echo). Да, там есть копипаст, однако процент его не так уж и велик. Существует множество языков без дженериков и все отлично обходятся без них. Однако, когда заходит речь о Go, почему-то 90% народа считают их краеугольным камнем.
как завуалированное сомнение
Сомнения — это домыслы каждого. Каждый судит в меру своей распущенности.
Ну давайте сравним с Rust, благо он появился примерно в то же время. Давайте с C#/Kotlin, которые не менее «тырпрайзные» и приземленные, не в угоду ленивым теоретикам с низким IQ.
Нет ни одного языка программирования, лишенного всех недостатков. Да, Rust, неплохая альтернатива, однако его экосистема оставляет желать лучшего.
Это можно назвать как прецедентом так и метафорой. В юридической системе обычно прецедент является веским аргументом.
Так где прецедент-то? В чем он заключался? Давайте факты.
Существует множество языков без дженериков и все отлично обходятся без них. Однако, когда заходит речь о Go, почему-то 90% народа считают их краеугольным камнем.
Ни один язык из двадцатки самых популярных, который был придуман за последние 10 лет не обходится без генериков. Кроме го. Причем и в го их скоро завезут. Наверное, не все так гладко с их отсутствием.
Сомнения — это домыслы каждого. Каждый судит в меру своей распущенности.
Ну давайте проясним тогда, что имелось ввиду? Мне очень интересно.
Нет ни одного языка программирования, лишенного всех недостатков. Да, Rust, неплохая альтернатива, однако его экосистема оставляет желать лучшего.
А не надо быть без недостатков, достаточно быть лучше, причем только в какой-то одной сфере, а в других просто быть не хуже. Это парето-оптимальность еще называется. Так вот ИМХО аргументы этой статьи не очень убедительны. Есть C# в котором ничуть не сложнее получить один исполняемый файл и иметь хорошую многопоточность и асинхронность. Есть котлин с теми же плюшками. Тонна других языков.
Если мы сравниваем время компиляцией с си, производительность с го а читаемость с перлом это конечно хорошо. Но не очень полезно.
Раньше разработчиков учили, на это тратилось время, но потом они могли писать хороший поддерживаемый код. Теперь разработчиков сажают сразу на манки работу, где сломанный компонент проще переписать заново, но так как программисты только из универа, они очень дешевые, и это получается выгодно. За чей счет банкет? За счет разработчиков. Кто в итоге в плюсе? Бедный-бедный гугл.
Вот я и привел вам аналогию с токарем. Если человек в совершенстве изучил одну операцию — это еще не повод монетизировать ее всю жизнь.
Ни один язык из двадцатки самых популярных, который был придуман за последние 10 лет не обходится без генериков.
К сожалению, Go уже перерос указанный возраст, так как разработка началась в 2007, а анонсировался он в ноябре 2009 года.
Ну давайте проясним тогда, что имелось ввиду? Мне очень интересно.
Ранее вы писали:
Лично я цитату «они умные, но при условии, что мы измеряем ум именно этими критериями, а не коэффициентом IQ» как раз-таки как завуалированное сомнение в этих-самых способностях, иначе зачем эта часть в статье я вообще затрудняюсь сказать. Уверен, у большинства читающих сложилось то же впечатление.
не надо быть без недостатков, достаточно быть лучше, причем только в какой-то одной сфере, а в других просто быть не хуже. Это парето-оптимальность еще называется.
Вот Go и хорош на 80%, причем на вопрос нужно смотреть шире: язык не только сам по себе достаточно хорош (в свое время я остановился на Rust), но его инфраструктура и выгоды для командной работы на текущий момент одни из лучших. Даже IDE для него от JetBrains одна из лучших.
Я вообще всегда считал, что чем ближе язык к динамическим, тем умнее надо быть чтобы на нем программировать.
Это правда, но если проводить аналогию с естественными языками, то тогда самые умные люди говорят исключительно на китайском языке.
Нет ни одного языка программирования, лишенного всех недостатков. Да, Rust, неплохая альтернатива, однако его экосистема оставляет желать лучшего.
А можно узнать, что нетак с экосистемой раста. Просто чтобы понимать.
* не было полнокачественной среды (только плагины).
* не было race detector.
* было ручное форматирование и документирование кода.
* было весьма немногочисленное комьюнити с относительно небольшим количеством библиотек.
Несмотря на то, что язык хорош, ему трудно состязаться с такими монстрами, как Google.
Тут подробнее.
Язык Go хорош тем, что он легко читается даже непосвященным человеков (практически не тяжелее псевдокода).
Нет. Он читается так себе, а из-за некоторых особенностей языка, в духе неявного импорта всего в пределах одной папки для непосвященного в этот факт не читается от слова совсем.
Мне интересно, откуда вы вообще берете какие-либо данные про читаемость языка? Вы проводили исследования, опросы?
Даже начинающие программисты начинают выдавать вполне приличный код спустя неделю-другую.
Если код начинающего программиста спустя неделю, который писал он сам, — оценивают как «приличный», то с наибольшей вероятностью оценивающий этот код как «приличный» — профнепригоден.
Ну или возможно язык, на котором пишут, такой плохой, что на нём просто технически невозможно писать «прилично». И какой-то кусок лютого хардкода уже расценивается как «приличный».
Но рано или поздно у многих ограниченных программистов возникает использовать старые методы на новом поприще. Действительно ли это так необходимо?
возникает использовать
«Ограниченных» программистов? Т.е. «ограниченность» — это когда тебе чего-то не хватает в технологии? С каждым новым абзацем сомневаюсь в компетентности автора всё больше и больше.
Многие начинающие программисты жалуются, что есть многие фичи, которых им недостает.
«Начинающие» программисты жалуются, что «есть многие фичи, которых им недостаёт»? Они точно начинающие, раз уже вообще знают о существовании целого множества фич, которых им вдруг стало не хватать, словно раньше они ими постоянно пользовались? Или вы просто клеймите всех «ограниченными» и «начинающими», кто не согласен что Go
Я правильно понял, что он плох и для умных и для неумных?
Прежде всего, синтаксис грамматических конструкций основывается на синтаксисе языка Си. Однако, существенное влияние оказал и язык DELPHI. Так, мы видим, что полностью убраны избыточные скобки, так сильно снижающие читаемость программы. Также язык содержит оператор ":=", присущий языку DELPHI.
На мой взгляд, значительно повлиял Oberon, хотя об этом говорят сильно меньше.
Структуры и методы, привязанные через ресиверы — это из Оберона.
Вообще, вся группа языков Н.Вирта оказала сильное влияние на Go. Впрочем, так же как и на Java, и на C#. Правда, джависты не признаются, за что Н.Вирт на них обижался. Он об этом говорил на своей лекции в Политехническом музее, когда приезжал в Москву.
существенное влияние оказал и язык DELPHI
язык содержит оператор ":=", присущий языку DELPHI
За основу пакетов была взята семантика языка DELPHI
Если бы вы были знакомы с языком Oberon или хотя бы заглянули в учебник Go Донавана & Кернигана (в котором на первых же страницах показана «генеалогия» Go), то поняли бы полную ошибочность вышеперечисленных предположений. Авторы Go ориентировались на куда белее совершенные, чем распухший и бесформенный Delphi, языки.
И семантика пакетов, и синтаксис методов однозначно указывают, что одним из первоисточников Go был именно Oberon.
модель не была изобретена авторами языка, а просто заимствована из старого доброго языка ADA.Нет, Ada тоже никакого отношения к Go не имеет. Хотя и в Ada, и в Go реализован механизм рандеву (называемый в Go каналами), но в Ada он основан на предварительной версии «Взаимодействующих последовательных процессов» Хоара, принципиально отличающейся от финальной редакции книги. И именно на финальный вариант — с безымянными отправителями/получателями и именованными каналами — опирается модель параллельности в Go.
>Eval64
>Eval32
ну очень обобщенно
вот что такое обобщенное программирование
REPL
Microsoft (R) F# Interactive version 10.2.3 for F# 4.5
> let inline add a b = a + b;;
val inline add :
a: ^a -> b: ^b -> ^c
when ( ^a or ^b) : (static member ( + ) : ^a * ^b -> ^c)
> add 2 3;;
val it : int = 5
> add System.Numerics.BigInteger.One System.Numerics.BigInteger.MinusOne;;
val it : System.Numerics.BigInteger = 0 {IsEven = true;
IsOne = false;
IsPowerOfTwo = false;
IsZero = true;
Sign = 0;}
> add "wat!!!?" "man";;
val it : string = "wat!!!?man"
парадигма программирования, заключающаяся в таком описании данных и алгоритмов, которое можно применять к различным типам данных, не меняя само это описание. В том или ином виде поддерживается разными языками программирования. Возможности обобщённого программирования впервые появились в виде дженериков (обобщённых функций) в 1970-х годах в языках Клу и Ада, затем в виде параметрического полиморфизма в ML и его потомках, а затем во многих объектно-ориентированных языках, таких как C++, Java, Object Pascal[1], D, Eiffel, языках для платформы .NET и других.
Таким образом, обобщенные функции можно писать, даже если параметрический полиморфизм явно не поддерживается языком.
Да, вы абсолютно правы, можно же ведь всегда свериться с источником.
А изначально была надежда, что наконец прочитаю статью о языке программирования, который на порядки будет легче понимать и возможно кодить в нем.
Сам я изучал основы программирования в ВУЗе, но мне не зашло, и больше чем общего понимания про программирование я не усвоил. Ну и надежда на новое открытие превратилась в крах. Для меня самым понятным языком так и остался Бейсик.
Например. Есть таблица с каким-то данными — цифры и символы. Найти нужную строку и столбец и соотвественно ячейку, визуально как в экселе — это любая бухгалтерша сделает. Но ни я ни бухгалтер не сможет поиграть с этими данными как Вы, программисты.
То есть мне было бы интересно, но блин, не смогу. В продолжение примера поясню. Да я понимаю что например функция «фор» или «иф» будет сортировать эти данные или селектить, и например я понимаю, что в таком-то языке синтаксис функции выражается так-то. Но слабый уровень Скила в математике накладывает ограничения — в моем случае. Другое дело рисовать кружочки в Бейсике.
Поэтому лично для меня было бы открытием познакомиться с таким языком, в котором я мог бы практически на «родном» языке написать:
{пройдись по таблице из этого файла:(имя файла);
{выведи на экран сумму (таких-то элементов);
}
}Что-то такое, а не все эти сложные математические конструкции.
Зачем мне тогда программирование? Сам не знаю, но хотелось бы увидеть такой язык, в котором бы все сложные конструкции отрабатывал компилятор что ли, а простым, почти человеческим языком задавал параметры и цели для исполнения, примерно как в том же экселе, но более низкий, что ли уровень. Не знаю как обьяснить…
{Программа, прочитай, затем занеси данные из такого-то <файла> в оперативную память;
Процессор, перемножь все числовые данные и сохрани результат(р) в память;
Графический процессор выведи (р) на экран;
}
Каждый раз, когда учу (или щупаю) новый язык, при возвращении обратно преследуют мысли "блин, вот эту бы фичу сюда", или "а вот это было удобней", или "как бы реализовать вот ту вкусняшку, которую я увидел".
После go осталось только одно послевкусие: "статический бинарник на выходе это офигенно". И это явно не заслуга самого языка.
Начать отличать критику инструмента от критики себя самого наверное первое, чему учится разработчик. Защищать бездумно свой инструмент потому что на него кто-то «напал» просто не самая умная стратегия. Вдруг люди правы? Но вы не узнаете, потому что просто обижаетесь на любую критику. Вам предложили несколько вариантов сравнения с другими языками, вы просто их отвергли. Люди, которые в ваших собственных вариантах сказали «код на Д читается проще» были признанны глупцами, которые не понимают Красоты Простоты.
P.S. Всё ещё жду реализацию на го задачки на парсинг массива строк в вектор чисел с обработкой ошибок. Вы не обещали её предоставить, но я всё же надеюсь увидеть превосходство го над всеми этими отстойными языками, которые он призван превзойти.
"… у статьи будет продолжение, применительно к более конкретным проблемам. Однако, за наличием отсутствия к теме интереса – продолжения скорее всего не будет"
Мне, например, тема интересна, хотелось бы и «продолжения»… с конкретными примерами, проблемами. Также интересно ваше мнение, — возможно ли использование языка для построения сайта-продаж, приложения уровня выше среднего, т.е. чтобы и web_server и работа с базой данных (например, postgresql) и бизнес-логика… аля_авито_розетка_возможна? Есть четкая грань, чего на go делать точно не разумно? Спасибо.
Что касается сайта продаж, то такие проекты (а также микросервисы) в основном и реализуются на Go. Причем реализуются весьма просто и элегантно. Многие используют для этого фреймворки, хотя best practics и не рекомендует это делать.
Что же касается продолжения статьи, то его скорей всего на Хабре не будет, поскольку в Recovery Mode я публиковать свои статьи не собираюсь (карма не позволяет). Возможно, продолжение просто выйдет на каком-нибудь другом сайте.
Нет дженериков. Если мы взглянем на статистику самых востребованных языков то заметим, что половину языков из верхней десятки не имеют дженериков. Преимущественно дженерики нужны только в контейнерах. Поэтому выигрыш от них не слишком большой.
Ох ну давайте взглянем на этот список.
JS — Динамический язык (я думаю нет смысла обяснять почему в нём нет дженериков)
SQL — Не назвал бы его языком программирования
1С — Сомневаюсь что они там в принципе нужны
PHP — Есть
Java — Есть
Python — Динамический
С# — Есть
С++ — Есть
PL\Sql — Тоже что и SQL
Go — Нет
Если брать языки только общего назначения (JS, PHP, Java, Python, С#, С++, Go) то только у го нет дженериков
Другие языки типа Rust много лучше (по крайней по номинациям сайта XXX). Опять же, если мы взглянем на статистику самых востребованных языков, то мы вообще не обнаружим язык Rust в списке или же он будет где-то внизу рейтинга. Лично мне, Rust нравится, но я выбрал Go
Зато полно других языков, Rust не попал только потому что статья прошлогодней давности и рассматривает данные только с HH, что уже является не слишком объективным анализом
Не достаточно выразительный. Согласен, на некоторых участах выразительность хромает, однако в целом это простой и непротиворечивый язык. Кроме того, из-за бедности языка, мы вынуждены большее внимание уделять архитектуре разрабатываемого приложения, что позитивно сказыввается на его гибкости.
Бедность выразительности позитивно сказывается на гибкость, ват? жизнь это смерть, свобода это рабство так что ли?
Вообще-то статья задумывалась не о синтаксических достоинствах языка Go, а, как краткий обзор о его достоинствах для командной работы и эффективной эволюции разрабатываемого проекта.
Но в итоге вышла статья является лишь вашим мнение, которое вы почем-то преподносите как объективную оценку.
К сожалению, апелляции к авторитетным источникам не дают никаких результатов.Да потому что в данном случае это ваша логическая ошибка. Тут в большинстве своём сидят не запуганные студентик первокурсники, которых можно легко продавить авторитетными источниками, тут сидит множество опытных программистов, для которых важны объективные утверждения.
Поэтому я прекращаю аргументированно отвечать на подобные голословные утверждения.Да вы и не начинали к сожалению.
PHP — ЕстьВ PHP нет механизмов обобщённого программирования. Для уменьшения дублирования кода в PHP есть типажи (trait). Но использовать их для эмуляции generic — это сознательно уменьшать надёжность кода: придётся отказаться от автоматической проверки типов параметров.
Я просто PHP уже лет 8 как не видел, но всё равно интересно узнать.
— мы уберем "{" чтобы меньше надо было печатать, но добавим ":" к каждому знаку "="
— мы придумали язык который удобно читать, но одна строчка на другом языке равно полотну текста на языке Go
Лично для меня Go не читаем абсолютно и я не понимаю почему Go должен быть понятнее для человека который никогда не программировал чем какой-нибудь C#.
Почему язык Go плох для НЕумных программистов