Комментарии 36
С одной стороны, можно назвать эти мысли как "му#овые рыдания". А с другой - кае жажда познания мира. Ну и конечно...
Я вливаюсь туда с душой, а получаю негативный "отпор", что-ли... я хочу совершенствовать существующее и создавать невозможное, но я, будто, ограничен то ли своими амбициями, то ли своей расстроенностью.
Еще это можно назвать "неудачная сублимация", или "женщину тебе надо".
И кстати, на Питоне делают большие проекты только так. Молчу уже про big data и ML.
Но самый идеальный, это, конечно, Ассемблер с макросами. Вот где простая чистота, вот где раздолье! Хехе.
Си пережил все что можно, и всех кого мог, практически не поменяв синтаксис, не идеалиен ли этот язык? Ну указатели, ну стрельба по ногам, зато возможность сделать все что пожелаешь на каком угодно устройстве с нуля, без фреймворков, без IDE, без гаданий почему переменная ушла в GC, максимально близко к асму, просто набрав код в консоли и собрав его, опять же, из консоли. У меня создалось впечатление, что автор покопал один язык, не понравилось, второй - тоже не понравилось, третий, четвертый... Не достигнув плато Майерса, не увидишь насколько хорошо ты знаешь язык
У меня создалось впечатление, что автор покопал один язык, не понравилось, второй - тоже не понравилось, третий, четвертый...
Вы правы, будем откровенны. Я опробовал много языков за это время и не смог бы определиться, скорее всего, из-за одной простой причины - у меня нет реального опыта разработки, о чем я говорил в статье.
Сейчас, мне нравится простота использования языка. Через какое-то время, я снова буду недоволен простотой (возможно, уже из-за невыразительности синтаксических конструкций языка) и побегу вспоминать языки с очень богатой системой типов. Таков уж процесс познания :)
Из всех языков, что я бегло опробовал (если не брать в учет C), больше всех мне зашли OCaml и Zig, честно говоря. Я не говорю, что языки, перечисленные в статье, ужасны: они все хороши, особенно для своих целей. Я всего лишь новичок, и это - мои эмоции от разнообразного мира языков программирования.
Ох заставили же вы меня по некрокоментировать.
простоты использования языка
вот это важное замечание, у языка есть 3 "простоты":
простота семантики (малое число сущностей, логичные связи между ними),
простота использования
простота реализации, т.е. насколько люди ленились при создании компилятора/интерпретатора этого языка
Например язык Go упомянутый в статье прост только по третьему критерию, люди не осилили компилятор и семантика языка невероятно кривая, абстракции расходятся по швам, ничего не выводится интуицией, нужно заучить каждый костыль который поставили разработчики Go
"глубинки" программирования: матлогика, теория множеств, лямбда-исчисление, теория типов
это ловушка, всё перечисленное - умные слова, не значащие ничего(базворды). Если бы автор продолжал писать на С или С++, то никогда не пошёл бы с этим возиться. И эти базворды возникают в среде Rust программистов как раз от непонимания, ну надо же сказать что match это не абы что (сахарок над if), а целый паттерн матчинг! И кривая ||5 это не абы что с ужасным синтаксисом, а лямбда счисление!
Т.е. я не отрицаю что это теории и изучают они умное, но называть a && b матлогикой, ||5 лямбда счислением, а struct теорией типов - смешно
В действительности за этими словами в расте прячется невероятное количество лишних и запутывающих абстракций, которые не упрощают написание кода, а усложняют
Так по пунктам.
Pattern matching неразрывно идёт в комплекте с типами суммами, которые не просто сахар над объединениями, но и некоторая фундаментальная сущность, выражающая, кстати говоря, сложность реального мира. Это важная абстракция, которая существует во всех новых языках программирования и во всех новых IDL типа protobuf, openapi. Но которой нет в Си и нет и Си++. Это вот как жить без ноги, можно заменить ее костылями, но это заранее хуже решение.
Никто не говорит про лямбда исчисление в Расте, это ваши выдумки. Причём почему-то наличие лямбд в плюсах таких эмоций не вызывает.
Вся теория типов и прочее глубокие вещи подарили нам в итоге много полезных практичных вещей и хороших принципов. Которые везде используют, в том числе и в плюсах и си. Ту же идею про чистоту функций, их композируемость, про проблемы с общим мутабельным состоянием.
Я лично не понимаю ваше желание наезжать на Rust или Go. Оно выглядит глупо.
Это важная абстракция, которая существует во всех новых языках программирования и во всех новых IDL типа protobuf, openapi. Но которой нет в Си и нет и Си++
ну это очевидная ложь, во-первых ничего невероятно фундаментального в ней нет, во вторых в С лет так 40 уже есть union, а это и есть "сумтип", только дискриминатор в нём является не числом, а определяется тем как использован union, и это имеет большой смысл если посмотреть на то как union применяется
Про С++ говорить такое вообще абсурдно, т.к. там есть возможность написать свои сумтипы и в стандарте есть std::variant, который по возможностям обходит enum из раста, например у него есть настоящий паттерн матчинг на перегрузках/концептах, а не простые if
Причём почему-то наличие лямбд в плюсах таких эмоций не вызывает.
потому что никто в С++ не ставит их невероятным достижением, которое есть только в С++, при том что в плюсах они реализованы во многих отношениях лучше чем в расте (захват переменных, читаемее синтаксис, возможность создавать шаблонные лямбды, отсутствие костылей по типу трейтов которые реализуются через костыли, т.к. вариадик шаблонов в расте нет и тд)
Вся теория типов и прочее глубокие вещи подарили нам в итоге много полезных практичных вещей и хороших принципов
у меня нет претензий к теориям, я говорю о людях которые бездумно говорят умные слова без какого то смысла в них, а это происходит очень часто именно при общении с Rust программистами. Посмотрите на иссуи на гитхабе, все просят добавить какие нибудь там афинные, зависимые, алгебраические и прочие прочие типы, такой дискуссии просто нет в рамках С++, я связываю это с нашествием людей из экспериментальных языков типа haskel, которые никогда не предназначались для программирования, а лишь для пруф оф концептов каких то идей и дипломных работ студентов по направлению "языки программирования", которые навсегда потом в языке
Любой язык программирования - лишь вспомогательный инструмент для решения определённого круга задач. Разные задачи - разные инструменты. И не существует языка, одинаково подходящего для всего.
Тот же GC противопоказан только в системном программировании и в Real-Time. А в прикладном софте (которого несравнимо больше, чем системного софта и систем управления физическим процессами вместе взятых) GC - это безусловное увеличение надёжности кода.
Язык C - прекрасный инструмент для системного программирования. Но как язык прикладного программирования он обладает фатальным недостатком: вся ответственность перекладывается на кодера. В C-коде очень просто допустить ошибку и очень сложно её найти. Это инструмент для очень опытных разработчиков, но кодеры нижнего-среднего уровня мало того, что неизбежно будут ошибаться, так ещё и не смогут понять, что ошиблись. Microsoft по меньшей мере десятилетие активно вычищала баги из ядра Windows, написанного на C.
А ещё у C абсолютно ужасный синтаксис. Да, с появлением C++ многое в C причесали, но, например, кошмарное объявление типа как шаблона никуда не делось: https://habr.com/ru/articles/116255/. В этом отношении из всех известных мне C-style языков наиболее удачен Go (язык прикладного уровня) - в котором из C выбросили всё, что делает язык ненадёжным, и добавили ровно то, что реально необходимо, при этом максимально унифицировав и упростив синтаксис.
и добавили ровно то, что реально необходимо
Здесь стоит отметить, что добавили ровно то, что было нужно Google чтобы закрыть свои "боли". Если у вас болит там же - это отлично!
А вот если у вас болит немного ао другому и в другом месте, то Го вам доставит много головной боли.
Я из того поколения разработчиков, которых учили, что качественно спроектированный язык программирования должен быть ортогональным. И это одна из причин, почему Go нравится мне намного больше большинства актуальных императивных языков программирования, в которых почти одно и то же можно сделать десятком разных способов - лишь бы замученный своей тяжёлой долей разработчик не надорвался, нажав при наборе кода на несколько клавиш больше.
Golang весьма толковый инструмент: приятная модель concurrency (возможно одна из лучших, доступных искоробки), компилируется быстро, опять же бинарник один, тулинг достаточно приятный, неплохой набор батареек в комплекте.
Но качественно спроектированный язык программирования? Тут переменные объявляй так, здесь по-другому, тут new, там make. Вот так встроенным функциям делать можно, а программистам - нет. Интерполяция строк в 2024? Вот вам Sprintf. Generics вот завезли спустя 14 лет. Ну спасибо, ну праздник.
Не поймите меня неправильно, у этой ограниченности есть свои преимущества. Golang - хороший инструмент. Всякие терраформы с кубернетисами это только подтверждают.
Но как язык - он все что угодно, но не хорошо спроектированный ортогональный язык.
Тем временем любая кодовая база на го примерно на половину состоит из `if err != nil`. Из всех "болей" я вот этого больше всего понять не могу и не выношу, но видимо ребята из Гугла очень любят это писать. Стоило бы поучиться обработке ошибок у раста или зига.
Порекомендую искать не язык программирования, а интересную предметную область. Язык к этой области найдется, тем более вы уже многое перепробовали и перескочить на нужный не составит труда .
У меня в свое время (середина нулевых) проблема "на чем писать" разрешилась при решении более приземленной задачи "а вот найти бы работу". Для молодого студента в глубинке особого выбора не было на этот счёт. В итоге, первые семь лет проф деятельности были посвящены как раз Си )).
Я наверно относился ко всему этому как-то по другому. Я не искал ЯП на котором буду программировать. Выбора было мало и потому пользовался тем что дают.
На Спектруме сначала бейсик с последующим переходом на ассемблер.
На x86 стал использовать Turbo Pascal. Не знаю, повезло мне или нет, но с Turbo Pascal шла куча примеров и прямо в документации. Перепечатываешь и смотришь работу своей программы. А дальше уже сам составляешь программу. Здесь я на ассемблер не стал полностью переходить, но изучить его изучил.
Не могу сказать вообще что какой-то ЯП плохой (хотя сам больше за компилируемые ЯП), но от языка мало что зависит. Больше всего зависит от знаний человека: языка и наработок на данном языке, как своих, так и готовых библиотек.
Язык служит для выражения собственных мыслей. Если на каком-либо языке можно выражать лишь чужие мысли, то это не мой язык.
И кстати, задавая вопрос, какой язык учить, между языками надо ставить "и", а не "или". То есть вместо "какой язык учить С или Python" надо писать "какой язык учить С и Python ...". Тогда и вопрос отпадет сам собой, ведь язык выбирают исходя из его целесообразности, а не по принципу нравится/ненравится.
А кто-то берёт и пишет свой собственный идеальный ЯП.
Я захотел стать слесарем и начал выбирать себе инструмент настоящего слесаря. Сначала я взял молоток, его было удобно держать в руке, забивать им гвозди и бить им всякое. Но потом мне сказали, что молоток для лохов и я взял пассатижи. Не знаю, какой идиот их придумал такими болтающимися, я проболвал ими забивать гвозди и постоянно больно попадал себе по пальцам. Это всё не моё, подумал я и начал искать свой инструмент. Я пробовал зубила, тиски, кусачки и даже ножовку, но это всё было не то. Слесарем я так и не стал. Теперь я расстроен.
Отличная статья на тему того, зачем в ИТ высшее образование и как человек без оного вообще не понимает, что он делает, зачем и куда он вообще попал. Раньше шутили: купи фотоаппарат, фотографом станешь. Это вот всё об одном и том же.
Надо бы запомнить эту байку из первого абзаца. Спасибо за ваш комментарий.
Я не отрицаю написанного вами, вы по большей части правы. По правде говоря, я не искал работы в программировании до текущего момента - все началось в формате "мне интересно, что такое это ваше программирование?". Спустя год изучения оного, я поступил в университет именно по той специальности, которая меня интересовала - "Системное программирование". Если бы мне действительно было невтерпеж найти работу (что-то вроде "здесь и сейчас"), то я бы и не пытался поменять инструмент и просто шел бы туда, где больше платят или хотя бы интересно по первому взгляду.
Хотя, на сегодняшний день, я уже задумался о том, чтобы попробовать себя в реальной работе: отсюда и появилась идея написать краткое эссе о том, какие "переживания" можно ощутить в моей ситуации. Так сказать: "провести черту этапа и вступать в новый".
Потыкать всякие OCaml-и с Лиспами, да всякие Zig-и на первом курсе - очень правильное дело.
Но я таки оставлю полтора непрошенных совета:
хорошо бы найти какую-то современную джаву (Golang, Python, что там сейчас самое модное и не планирует умирать?), и разобраться с ней на должном уровне. Потому что рано или поздно захочется чтобы за программирование еще и платили. И вот нельзя исключить момента, что за OCaml где-то платят младшекурснику, но это очень много звезд должно сойтись.
я бы очень сильно рекомендовал поискать настоящую работу. Может даже на четверть ставки. Язык программирования в работе разработчика необходимая, но не достаточная штука. Есть взаимодействие с коллегами/начальниками/кастомерами, есть предметная область (по сравнению с некоторыми все эти брейнфаки, уайтспейсы и перл-уанлайнеры - образец читаемости, простоты и понятности), есть богатая россыпь тулинга от гитов с линтерами до кубернетисов с терраформами, и еще много всякого
это не значит, что то, что описано в статье - не важно. Важно. Но вот эти штуки выше они все это дело укладывают в достаточно реалистичную канву и кое как структурируют это дело
ну и пока молодой без кредитов, ипотек, машин квартир - меняй работу почаще. Увидишь побольше
C <3
Nim таковым является, синтаксис как у Python, скорость и размер исполняемого файла сравним с C, а кода приходится писать гораздо меньше, и не такой скучный как Go. Ещё и можно в JS транспилировать, то есть, занимает все ниши, включая и веб-разработку.
а теперь расскажите про его минусы
больно сладок фрукт с прочтения вашего комментария
Библиотек маловато по сравнению с тем же Python, где их очень много, но решается зачастую биндингами к сишным библиотекам. Есть некоторые проблемы с библиотекой std/asyncdispatch для асинхронного программирования в некоторых задачах, но есть альтернативы, закрывающие проблемы стандартных библиотек.
Язык пока что не идеальный, но ничего лучше ещё не видел, везде есть какие-либо проблемы, здесь они все решаются, кода реально пишешь мало, гибкая сборка бинарников, хоть статический, хоть с поддержкой старых версий glibc, и бинарник получается небольшого размера, почти на порядок меньше чем на Go, компиляция ещё медленнее чем у Go, но гораздо быстрее чем у Rust, и будет ещё быстрее.
Спасибо, интересно почитать). Тоже всегда были интересны "С, С++", но так и не хватает духу и времени попробовать писать на них), пока что выбрал С#, пробую в нём)
Мне показалось странным, что в статье написано о Rust как о языке, который позволяет не думать о вещах, о которых приходится думать, если используется язык C. По моему очень скромному опыту изучения этих языков, Rust просто заставляет думать о всём, о чём нужно думать в C, вечно требуя оправдываться перед компилятором о своих намерениях.
Кроме того в руководствах на каждый чих предлагается использовать вещи, определяемые в стандартной библиотеке или как элементы языка, что делает весьма трудным изучение языка отдельно от его стандартной библиотеки, а смешивая всё в кучу понимание ко мне никак не приходит.
Поэтому назрел вопрос. Чтобы не было больно, нужно найти какой-то правильный подход к изучению Rust?
Чтобы не было больно, нужно найти какой-то правильный подход к изучению Rust?
Я для себя в итоге выработал следующий подход в изучении Rust:
начинать с чего-то очень мелкого и использовать самые базовые конструкции с минимум зависимостей. Даже если приходится "велосипедить"
расширять функционал делая рефакторинг. Это, бывает, мучительно - да. Но мне дало понимание что/когда/зачем
постепенно подключать библиотеки смотреть как они внутри себя реализуют и сравнивать со своей "наивной" реализацией
открыть для себя профилирование и дивный мир неочевидных оптимизаций
По моему очень скромному опыту изучения этих языков, Rust просто заставляет думать о всём, о чём нужно думать в C, вечно требуя оправдываться перед компилятором о своих намерениях.
Не надо писать на Rust так, будто ты пишешь на C
Есть большая разница между не думать и получать ошибку компиляции и не думать и потом получать в лучшем случае сегфолт.
Тут я и начал свои скитания по разным языкам, в поисках различного интересного и идеального. Я успел опробовать
Странно, что в списке нет Lisp (или подобных языков). Lisp является идеальным языком программирования в том смысле, что в нём "нет синтаксиса" и программист задаёт непосредственно AST.
Насколько далеко Вы зашли в изучении Haskell (линзы, трансформеры и так далее)? Haskell является идеальным языком программирования в плане построения абстракций. Если в Си программист может выделить общий код в отдельные функции, то в Haskell у программист может пойти дальше и выделить общие идеи в отдельные абстракции. То есть, делить задачи на подзадачи (а в этом суть программирования) можно не только по содержанию (принцип единой ответственности), но и по сути ("природе" вычислений).
я ведь искал "идеальный" язык, а в эту категорию языки с GC не попадают,
Почему так важно самому управлять кучей? Может, тогда и кэшем процессора и регистрами нужно вручную управлять? Конечно, в некоторых приложениях необходима низкоуровневая оптимизация, но имхо так можно за деревьями не заметить леса.
Нет ничего лучше Си (причём, ANSI C, а не вся эта новомодная хрень). Конечно, улучшить си в мелочах можно, но это не стоит того чтобы отказываться от стандарта
В начале статьи смешиваются в кучу две разные сущности - язык для начала обучения программированию, и язык на котором предполагается работать.
Когда речь идет об обучении программированию, выбор между C и Python не должен стоять. В любом учебном заведении на специальностях связанных с программированием студенту будут преподаваться сразу несколько языков. Потому что одним языком все основные сущности просто не покрыть. При этом нет необходимости зазубривать эти языки до "production ready", достаточно основ (досягаемых буквально за неделю-две) покрывающих цель изучения языка.
Если бы я мог составить себе из 15-летнего прошлого список обязательных языков для ознакомления, он бы выглядел так:
Pascal; Ради переменных, типов, управляющих инструкций, функций, и прочих основ. Потому что он одновременно близок к псевдокоду, бьет по рукам, не дает стрелять в ногу, со статической строгой типизацией. А современный PascalABC покрывает вообще большую часть перечисленного далее.
С; Ради вездесущего C-подобного синтаксиса, удобства изучения голых указателей, побитовых операций, изучения алгоритмов и структур данных, всяких системных API и библиотек.
Один интерпретируемый язык из Lua, Python, JS. Я бы советовал Lua в реализации LuaJIT. Ради собственно знакомства с интрепретацией, JIT, GC, неявной слабой динамической типизацией, функциями первого порядка, корутинами, замыканиями, интернированием строк, встраиванием в C, биндингом к C, и т.д..
Один managed язык из C#, Java. Я бы советовал C#. Ради знакомства с ООП, дженериками, многопоточностью, рефлексией, и т.д.
Любой ассемблер. Да хоть TASM. Ради знакомства с тем во что превращается код высокоуровневых языков, чем там ворочает процессор, как он выполняет инструкции, с прерываниями, регистрами, и т.д. и т.п.
Собственно, примерно эти языки мне и преподавали, причем примерно в том же порядке. Только было еще много других - C++, VB6, PHP, 1C, и почему-то не было ничего из managed, с ними я уже сам позже ознакомился.
После обучения основам программирования по списку примерно как выше, у человека уже будет базовое представление о минимум о 2-3 "боевых" языках, в которые можно будет углубиться согласно собственным предпочтениям или обстоятельствам. При этом легко можно будет перешагивать основы других языков в рамках структурной и объектной парадигмах.
Попробуйте Clojure. Он может и не идеал но достаточно красивый язык. Вот видео для вдохновения от создателя Clojure. Видео будет полезно для всех. Там общие принципы.
Публикации
Новичковые скитания по поиску идеального языка программирования