Опубликован релиз языка программирования Crystal 1.5, разработчики которого пытаются совместить удобство разработки на языке Ruby с высокой производительностью приложений, свойственной языку Си. Синтаксис Crystal близок к языку Ruby, но не полностью совместим с ним, несмотря на то, что без переработки выполняются некоторые ruby-программы. Код компилятора написан на языке Crystal и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57549
Красивое
Кошмарное.
Самый емкий и самый информативный комментарий, наглядно показывающий всю спецификацию обсуждаемого языка.
Среднячок
Паскаль одним словом
Не, кристалл - это какой-то диалект инопланетян. А праскакаль - тёплый ламповый Вирт :)
> Кошмарноеэто даже кошмарнее раста
Миру программирования, каким мы его знали, приходит конец. Такая скорость выпуска новых япов похожа на конвульсии умирающего монстра... Наверное профессии программиста скоро не станет.
То ли дело, раньше, да? Один другого угрёбищнее, работает только на ~1 платформе… И новых не меньше всё равно, при этом, не понятно, куда бежать и что учить.
Можно подумать, что сейчас все эти поделия не угрёбищные. С вырвиглазным синтаксисом, с меняющимися с каждой версией API и отсутствием всякой совместимости между версиями
Rust решил все эти проблемы, возрадуйся, котик :3// b.
Раньше было чистое поле. Люди исследовали, искали. Сейчас все превращается в сумасшедший дом. Go, Dart, Rust, Zig, Swift, Crystal, Hare, Carbon - и все на замену C. Зачем? Для кого? Для чего? И главное деньги выделяются, посмотрел на сайте кристала - одна фирма выделила 130 т. недружественных бумажек. Может это просто отмывание денег?
А тебе то какая разница кто там на что деньги выделяет? Как будто у тебя сишку отнимают, пришли вахтеры опеннетовские разбухтелись опять
Это ты тут разбухтелся, завидев мой вполне закономерный вопрос. На эти языки явно должна обратить внимание налоговая.
Закономерный ответ: раз кто-то фандит значит кому-то надо, и налоги я уверен там уплачены (кстати, не тебе, расслабься). Реально как бабки у подъезда, все то их касается каким-то образом
>и налоги я уверен там уплаченыКого волнует в чём ты там уверен? Не надо свою веру преподносить как факт. Будут пруфы — тогда ок, а пока только трёп.
Спасибо за поддержку. Разработка этих бесполезных никчемных языков - это явное отмывание денег. Можно назвать эти языки - языки-порошки.
Раньше? Это в 80х?
Ты просто никчемный скудоумец. Всё есть рынок, а рынок без конкуренции - гниющий застойный картель. Да будь их хоть десятки тысяч, тебе это как мешает? Ты ни одного не разработал, только потребляешь.
Сразу видно отсутствие мозга в твоей черепной коробке. Сочувствую. Не знаю, сможешь ли ты что-то понять, но постораюсь объяснить попроще. Рынок - самое отвратное, до чего додумалось человечество. В рыночных условиях в погоне за прибылью люди расходуют огромные ресурсы впустую. Вместо того, чтобы объединить усилия и разработать один нормальный язык - люди распыляют усилия на кристалы, дарты, голанги, карбоны, расты. И все равно вся разработка идет на старичках С/С++ - пока самых адекватных языках. Голанг/Раст не смогли их заменить, хотя столько бабла было вложено, лучше бы эти деньги ушли на спасение белых медведей.
Ты только системщиков сюда не приплетай, а. Люди нормальные деньги получают за автоматизацию процессов на предприятии, а не за это ваше вшивое перекладывание байтиков. Несколько поколений разрабов уже выросло, в глаза не видевших крестов, но отлично знающих голанги, питоны, руби, sql, чего достаточно в провинциальном городе для закрытия ипотеки за двушку года за 3-4.
Взять так и попутать каких-то мифических программистов на экзотических языках с СНГ-шными 1С-никами,ну даёшь.
В провинциальном городе сишка и плюсы на предприятиях, пхп и жс для сайтов, жаба на интерпрайзе. для всего остального 1С. о каких голангах и руби ты вещаешь, лалка?
Ты ещё скажи что в офисе работаешь, а не на удаленке. Я живу в городе с населением в 150к человек, последние три года работал на Мск жабистом сидя в своей провинции.
> чего достаточно в провинциальном городе для закрытия ипотеки за двушку года за 3-4.Ахахах, разраб с IQ > 50 не будет брать "двушку в провинциальном городе"
У разраба могут быть разные жизненные ситуации, из-за которых переезжать несподручно.
> но отлично знающих голанги, питоны, руби, sql, чего достаточно в провинциальном
> городе для закрытия ипотеки за двушку года за 3-4.Это, типа, должно было сойти за счастье?
Не, это просто констатация сдеградировавшей толпы кодманки
> одна фирма выделила 130 т. недружественных бумажек.Ну, охренеть, какая-то контора целую годовую зарплату миддла выделила! Одну. Весьма среднюю. Для очень среднего по своей квалификации миддла.
> Может это просто отмывание денег?
Ох уж отмыли, так отмыли. Преступление века!
Ага. То, что MS сделала с VBA: x32 и x64 - совершенно разные языки.
Ты это Ричи покойному расскажи.
С подключением. Скорость появления новых языков, которые вызывают хоть сколько-нибудь видимую реакцию, никак не больше, чем ранее, скорее наоборот. А вот по значимости и охвату это всё, вообще , на уровне погрешности. То ли дело времена появления PHP, Python, Ruby, et cetera.
Питон и руби очень долгое время после появления были уделом маргиналов. Мейнстримом были с, с++ и джава. До этого алгол, фортран, асм. Языки исправляли наболевшие проблемы, решали задачи более удобным или дешевым способом, в этом и есть прогресс - такова эволюция. И кто это отрицает - становится динозавром.
Питон и руби долгое время после создания были не серьёзными игрушечными языками. Ну вот вроде как луа.
Все так - все должно настояться должным образом чтобы найти свою нишу
>Все так - все должно настояться должным образом чтобы найти свою нишуЧему там настаиваться у питона? Просто его стали проталкивать, вот и секрет «успеха». Очень успешный язык есть — VBA. Просто ему нет альтернатив в конкретной ситуации,и что, из этого следует что он настоялся в самый раз?
VBA потому и не взлетел, что изначально был прибит гвоздями к MS Office.
> VBA потому и не взлетел, что изначально был прибит гвоздями к MS Office.Не поэтому. Апотому что синтаксис васика угрёбищен. Ведь был ещё VBS, который не победил обычные cmd-шники.
>Просто его стали проталкивать, вот и секрет «успеха»абсолютно все языки проталкивают, но почему-то далеко не все становятся такими популярными. нужно много уссердного труда и чепотка везения. питону помогло несколько факторов: открытость, грамотное проектирование для дальнейшего расширения и очень качественное сочетание минимального набора фич(которые со временем есесна разростались, но пытались придерживаться философии, с некоторыми оговорками)
Какое везение? Его тупо проталкивали как единственный скриптовый язык дополнений в кучу проектов. Те же блендер, инкскейп тянут именно питон. Где там альтернатива и конкуренция? И где везение, когда всё ограничивается политикой?
это уже следствие
> это уже следствиеСледствие маркетинга, а не качества.
Кроме стандартной библиотеки, которая позволяла сделать многое для "повседневных" скриптов, у Питона всегда была хорошая документация в комплекте: полное описание стандартной библиотеки, способы включения в программы на Си, синтаксиса языка и туториал для тех кто его впервые видит.
В комплекте, а не где-то там в интернетах.
Многие только только к этому приходят.
Именно поэтому их всех сейчас игого и выпиливает на свалку истории в вебне. А больше они нигде себя особо и не проявили, кому нужны куски наколенщины с достоинством "зато кодер не напрягался".Давайте так жратву готовить? Вывалить вам хавч в корыто, погреть слегка строительной горелкой - хавайте, дескать. Зато повар не напрягался!
Голанг выпиливает пыху и пихтону на свалку истории? А ты смешной шиз.
> Голанг выпиливает пыху и пихтону на свалку истории? А ты смешной шиз.Да это не я, это гугол. Который уже большую часть питонопрожектов у себя на игогоху переписал. И за ним еще эн корпораций так то. Ну вон дропбокс - проследовал тем же курсом. Правда, им зашло и они на хруст потом переписывать начали, этак еще и си++ освоят ненароком, но тренд таки имеет место быть. Да их много уже. Знакомые вебхомяки на игогоху посваливали довольно основательно.
Примитивнейший язык. состоящий из одного бойлерплейта с синтаксисом Эллочки-людоедки, отвратительной обработкой ошибок еще и с наличием null в системе типо - это "выпиливает на свалку истории"? Маня, подмойся.
>Примитивнейший языкЯ хоть и растаман, но за Go заступлюсь. Никоим образом это не примитивный язык: компилируемый без посредничества LLVM, статическая типизация, относительно компактный рантайм с развитой поддержкой конкурентности, рефлексия...
>состоящий из одного бойлерплейта
Это сознательное решение: меньше магии -> проще компилятор, быстрее сборка, низкий порог вхождения для новичков.
>с синтаксисом Эллочки-людоедки
Привычный Си-like, этой претензии вообще не понял.
>отвратительной обработкой ошибок
На самом деле одно из лучших дизайн-решений языка. Исключения - зло. По бойлерплейту обработки см. выше.
>с наличием null в системе типов
Вот тут соглашусь, в новом языке 21-го века это странно. Но null позволяет более кратко записывать отсутствие состояния, чем тип-сумма.
> компактный рантайм с развитой поддержкой конкурентности, рефлексия...Прикольное название для хелловорлдов 6 мегов весом :). А то что он код генерит офигенно, да еще с GC неотключаемым - уж не из-за этого ли dropbox на хруст свалил?
С момента написания yacc и lexx и первого выпуска книги Ахо "Компиляторы" прошло больше тридцати лет, и каждый уважающий себя студент третьего курса программистского факультета за эти все годы считал своим долгом написать свой язычок программирования - ничего не изменилось, нет поводов для беспокойства - очередной N+1 ЯП - просто раньше интернеты были не так распространены :)
Видимо так оно и есть.
Если студент не пишет на третьем курсе свой "язычок" с обязательной компиляцией в машинные коды как курсовую работу - это профнепригодность.
Fyjybv имел в виду, что технология популярна с года 1979 примерно, когда студент пишет свой язык это похвально но не более того.
Но для реально полезных или интересных программ, хотя бы того же stellarium, нужно какие-то ещё другие книги почитать - оттого люди предпочитают полировать нечто навроде темы этого обсуждения.
Совершенно верно. Это как с фотографией. Камера нынче у каждого первого, но гениальных фото не стало больше.
>и первого выпуска книги Ахо "Компиляторы" прошло больше тридцати лета вот и нет, написано же, что хотели авторы
"""
разработчики которого пытаются совместить удобство разработки на языке Ruby с высокой производительностью приложений, свойственной языку Си
"""это попытка скрестить ежа с ужом, в книге такой ереси нет.
Резонно предположить, что уважаемый Ахо лишь дал в руки хороший инструмент, а использовать его можно в меру фантазии - ... Заставь дурака богу молиться.. (С) народная мудрость
>что уважаемый Ахо лишь дал в руки хороший инструментон дал описание инструмента, лично у меня не возникало желания написать ЯП после прочтения, но академическое желание есть у каждого, но это не повод плодить ЯП и продвигать в массы, не разобравшись с кучей проблем связанных с формальными языками ака ЯП.
Зачем так утруждаться? Наделайте в Си с помощью #define разных штук типа { - начнем пожалуй, } - на этом и кончим, return - завтра докуём. Всё, новый модный язык готов.
самый красивый go. только модули у него ужасно криво сделаны. вот его можно сделать заменой с++
Синтаксис Go просто ужасен и неприятен. Для тех, кто программировал на C,C++, Java, C#
это ложь
Согласен. Ваще непонятно, какие извращенцы хейтят синтаксис Go, тем более с точки зрения сишника. Чистый, лаконичный, не ломающий привычки. Народ реально зажрался.
Тех, кто программировал на С, С++, Java и C# уже не вылечить.
А стоит ли? Надо ещё разобраться, кого тут надо лечить. С одного края: паскаль, бейсик и лисп; и со второго: си, плюсы, жава, скала, сишарп и лисп.
Lisp с обоих краёв?
> Lisp с обоих краёв?Конечно, он не превзойдён в своих возможностях и все его должны хотя бы поизучать, без этого трудно осознавать многие серьёзные концепции других языков программирования. Но он не универсален, к сожалению. Хотя именно по этой причине, он, скорее всего, не свернёт мозги на бок.
>Lisp с обоих краёв?Прямо как я ...
Не могу согласиться. На самом деле Си и всё остальное (внимания не заслуживающее).
Да он вообще не программист, не понял о чём написал.
Почему он, а не он, ведь, очевидно, что он? Потому что про си это абсолютный бред. Может, чувак ничего дальше МК не видел в жизни, но всё равно не серьёзно как-то.
Да, бред.
Что так? Я и коллеги много пишем на C и С++, и давно пишем, когда C# ещё не придумали, но и C# используем, более того, лично мне он нравится.
Хотя, при этом Яву недолюбливаю, и добровольно не использую, хотя, по сравнению с с C# не велика разница, что в стиле, что в производительности. Чисто дело вкуса.
Разница между ними конская. В C# куча фич и нет проблем с дропом обратной совместимости, если оно нужно. Поэтому например нет такого позорища, как в джаве с дженериками.
У C# есть одна проблема - его автор.
ты про одного из крупнейших донора опенсорса? ну зачем так грубо))
А в жаву главный коммитер оракл, который вообще корпорастическая помойка хуже MS
> А в жаву главный коммитер оракл, который вообще корпорастическая помойка хуже MSВ этом месте было что-то про жабу и гадюку...
> Разница между ними конская.По отдельности, вроде бы все мелочи. А в сумме набирает критическую массу, влияющую на предпочтения.
Это же относится и к другим языкам. Как бы он не был удобен хоть для каких нибудь задач, но если язык не удобный, светлая ему память.
Синтаксис Go просто ужасен и неприятен. Для тех, кто программировал, хоть на перфокартах.
Абсолютно нормальный синтаксис, и простой как палка. Язык можно не учить, а сразу программировать.
Решения в дизайне нестандартные, но это и к лучшему - новые концепции дают программисту развитие.
Тем, кто замшел в своих плюсцах, не понять. Вдолбили себе в голову, что можно выучить и всю жизнь на нем, непонятно главное с чего.
Плюсы каждые три года - новый язык с другими парадигмами.
>Язык можно не учить, а сразу программировать.О, го-макака в треде. Даже разговорный родной язык и тот учить надо. А оно вещает что можно ЯП не учить.
Некоторые языки можно "не учить", подразумевая их очень быстрое освоение, особенно когда "учишь" не первый и второй язык, а не разбираясь с библиотеками, можно только матерясь заниматься велосипедостроением, и публиковать поделки на govnokod.ru.
Не учить можно те языки. чей синтаксис похож на то, что вы уже учили. И всё равно язык придётся учить,чтобы не гoвнокодить на нём.а эффективно использовать внутренние конструкции, которые отличают его от других языков.
Присоединяюсь к мнению. Но не могу не добавить, что простота Go обманчива: для успешного развития надо изучать много паттернов (оборотная сторона минимализма, в некоторых языках паттерны встроены ценой усложнения). В качестве примера приведу книгу "Concurrency in Go", которая обязательна к изучению каждым вдумчивым гофером, и потребует месяцев для "прохождения". То есть, как и с любым нетривиальным языком программирования, для достижения профессионального уровня самостоятельного разработчика требуется как минимум год изучения и практики.
Синтаксис не играет особой роли, дело пары месяцев привычки. Даже тот же cmake с каждым вторым словом капсом, через какое-то время регулярной работы с ним уже не так выбешивает.А вот убогая система типов Го, отсутвие иммутабельности, раздражает намного дольше. Как, впрочем, и строки-списки в cmake.
Чтоб не раздражаться, нужно снизить ожидания. Да, Go не Хаскель в смысле силы типизации, но имеет всё-таки достаточно мощную систему типов для того, чтобы переход с Питона, Руби, Джавы и подобного дал эффект лучшего качества развития и сопровождения больших сложных проектов.
> вот его можно сделать заменой с++С неотключаемым GC - без шансов. Поэтому в ряде мест его хруст теснит, там, видите ли нет такого подарка в обязаловку.
Деды, Пайк с этим, как его, каутским, хорошо стебанули гугл выкатив такую "красоту". Никто даже не врубился.
Удивляют люди которые из года в год повторяют эту мантру насчет замены C++ на go даже не удосужившись поинтересоваться назначением go и его возможностями.
Мантру насчет замены C++ повторяют о всех ЯП, неосиляторы плюсов так себя успокаивают
Заменой C++ он никогда не станет, но у него есть шанс стать "C++ для веба"
Что за мода на вырвиглазный синтаксис ? На фига все эти def, end ?
Это из Ruby. Автор - японец, поэтому для него такие имена булевых функций лучше читались, чем IsSomething().
А вы кто? В каком месте begin и end - булевские функции?!
Я про вопросительный знак. В чем критика def вообще не понял. Почти во всех языках есть что-то подобное, просто где-то это fun, где-то function, где-то fn и т.п.
Разработку этих языков заказывают офтальмологические фирмы.
У вас синдром утёнка, уважаемый. Что вам не так в использовании слов вместо иерографического письма C и плюсов, а то вообще их полного отсутствия?
Слова нужны для обозначений переменных, но никак начала и конца функций. Это противоречит человеческому естеству. Поэтому С взлетел, а паскаль и ныне там.
Ну да, ну да. Вот они, те - кому смайликами удобнее)) многое объясняет, да.
Замени в своём комментарии знаки препинания на слова и оцени читабельность.
Печатать меньше и логические блоки подсвечивать эстетичнее в силу симметрии открытия-закрытия. Бешеному принтеру RSI не болезнь?
>У вас синдром утёнка, уважаемый.Когда выучил модное выражение, то потрудись ещё его правильно применять. Синдром утёнка ту не причём. Границы блоков должны обозначаться знаками, а не словами, ибо когда операторная скобка выглядит как оператор, то это бред. Такойже бред, как логические функции записывать словами. А если не бред, то тогда надо быть последовательным до конца и записывать арифметические операции словами: plus, minus итд.
>А если не бред, то тогда надо быть последовательным до конца и записывать арифметические операции словами: plus, minus итд.add(a, b) - норм ведь
> add(a, b) - норм ведьНо a+b короче разика так в ТРИ... :)
> Но a+b короче разика так в ТРИ... :)ну эта же "коротизна" она на уровне формального языка, не машинной инструкции, где как не крути есть допустимый минимум кодирования той или иной операции. a+b или add(a,b) одинаково будет представленно (закодировано) в виде КОП (код операции) в зависимости от архитектуры. Отсюда не вижу принципиальной разницы "коротизны" для формального языка. Да мы экономим размер исходного кода, но не машинного. А "коротизна" машинного кода, думаю важнее. Я вообще не сторонник всех этих формальных языков, допускаю только один формальный язык, мнемонический язык машины. Такой язык лучше с точки зрения понимания машины (архитектуры), ибо зная как работает машина, можно оптимально писать под нее программы.
Оптимизировать надо под людей, поддерживающих системы. Машина железная, пережуёт.
> Оптимизировать надо под людей, поддерживающих системы.приведу аналогию, чтобы избежать тряски и дискомфорта при езде по неровной дороге, лучше поставить мягкое сидение.
> Машина железная, пережуёт.
раз поставили мягкое сидение, амортизаторы можно не использовать, машина поедет.
Правильный ход мыслей?
Автомеханикам не место в ИТ.
> Автомеханикам не место в ИТ.айтишники не должны создавать автопилот для машин они же не механики :)
> айтишники не должны создавать автопилот для машин они же не механики :)А чего такого механического в автопилоте, уж пардон? Это прежде всего порграммная конструкция. Большая часть всего остального, кроме, разве что может привода руля, и так уже было и управлялось софтом. Так что автопилоту оставалось лишь осилить общую координацию всего этого не угробив владельца, по большому то счету. А вот с этим таки есть некоторые проблемы до сих пор.
> А чего такого механического в автопилоте, уж пардон?ага смузихлеб будет программировать бортовую систему не зная механики машины.
> ага смузихлеб будет программировать бортовую систему не зная механики машины.Ну все же не смузихлеб, а некто умеющий в очень специфичную область high-reliability кодинга, там так то довольно крутые типажи обычно. Но вот именно механику им знать все же ни к чему. Общие свойства объекта, лимиты всякие и проч.
Там тоже разделение труда. И на абстрактном уровне что в fly by wire что в авто по шине полетит условное "мотор дай 50", как оно там это унутрях обеспечивает интересно только его локальному ECU, или как оно там у кого компьютер при движке называется, где-то там унутрях его собственной фирмвари, с чем вообще совсем другие кодеры разбирались, не имевшие никакого отношения к автопилоту.
> Оптимизировать надо под людей, поддерживающих системы. Машина железная, пережуёт.Да как сказать? Или не пережует. Когда вон там на едва живой мобильной конекции 2 мега либ на яваскрипте грузится чтобы прочекать два долбаные поля в тривиальной форме - таких кодеров почему-то очень хочется увидеть в бассейне с голодными акулами. В роли завтрака.
> ну эта же "коротизна" она на уровне формального языка, не машинной инструкции,Угу, она на уровне инструкций к моим пальцам. Которые совсем не рады этому.
> где как не крути есть допустимый минимум кодирования той или иной
> операции. a+b или add(a,b) одинаково будет представленно (закодировано) в виде КОП
> (код операции) в зависимости от архитектуры.Зато моим пальцам сильно предпочтительнее первый вариант. По тем же причинам {} лучше чем begin/end.
> Отсюда не вижу принципиальной разницы "коротизны" для формального языка.
Зато видят мои пальцы, на которые нагрузка утроилась. RSI никогда не ощущали? :)
> сторонник всех этих формальных языков, допускаю только один формальный язык, мнемонический
> язык машины. Такой язык лучше с точки зрения понимания машины (архитектуры),
> ибо зная как работает машина, можно оптимально писать под нее программы.Как бы это сказать? У ассемблера есть одна маленькая проблемка: он вообще паршиво поддается структурированию. Процессору оно похрен, он железный, а вот человеку длинный однообразный неструктурированный список - в сколь нибудь большом проекте не дает отстроить глобальную картину происходяшего.
Локальное понимание работает в пределах единиц килобайтов кода. Потом сущностей для трекинга становится слишком много и ничего хорошего на асме вот так - уже не получается. Я видел большие проекты на асме, и это пожалуй самый жуткий код который вообще можно придумать. Поддерживать, менять и расширять такой проект становится невозможно вообще.
В этом месте мы начниаем догадываться почему программы делят на логические части, желательно независимые и реюзабельные (e.g. либы), делают некие абстракции чтобы вот тут только имплементация, а вооон там ее многочисленные детали, в которые можно и не смотреть если это не меняем, и так далее. Это конечно несколько нагибает локальное понимание происходящего, зато позволяет вертеть сильно более масштабным проектом, более-менее удерживая его в голове. В случае неструктурированного списка команд это, конечно, было бы совершенно без шансов.
> Угу, она на уровне инструкций к моим пальцам. Которые совсем не рады
> этому.жаль, что машины так не могут, а то переваривают всякий гамнокод.
> Зато видят мои пальцы, на которые нагрузка утроилась. RSI никогда не ощущали?
> :)автокомплит, в помощь
> Как бы это сказать? У ассемблера есть одна маленькая проблемка: он вообще
> паршиво поддается структурированию.кек, структура в мозгу у человека, гамнокодить можно на любом формальном языке. Что асм запрещает раскидать куски кода по разным файлам, потом их инклюдить?
> Я видел большие проекты на асме, и это
> пожалуй самый жуткий код который вообще можно придумать. Поддерживать, менять и
> расширять такой проект становится невозможно вообще.а чем код ядра линукса лучше? один человек способен его разжевать как вы говорить? На то и создают команды, где каждый ведет свой участок кода.
> Это конечно несколько нагибает локальное понимание происходящего, зато позволяет вертеть
> сильно более масштабным проектом, более-менее удерживая его в голове.в этом то и проблема, держать все в одной голове.
> В случае неструктурированного списка команд это, конечно, было бы совершенно без шансов.
в смысле не структурированного? асм это последовательность инструкций, детерминизм никто не отменял.
> жаль, что машины так не могут, а то переваривают всякий гамнокод.Да почему? Тормозят и глючат просто изумительно. Особенно если гамнокодом накормить.
> автокомплит, в помощь
С 1 ноты это не очень хорошо работает и в целом тычков кнопок в разы больше. В этом месте сиобразные яп получают свой пойнт. Все же системщиков всегда парила эффективность кодинга, в отличие от концептуалов всяких.
> кек, структура в мозгу у человека, гамнокодить можно на любом формальном языке.
В ассемблере нет штатных средств декларирования намерений, нормальной типизации, средств организации структур данных и проч. Проблема в том что
1) Это не наглядно и нет хорошей декларации структуры которая у меня в мозгу.
2) Остальные не телепаты чтобы все это знать.
3) На большом проекте я и сам full view не удержу в голове, да и не надо это, только "общую картину" и "что активно кодится сейчас". Не следование данному паттерну сильно нагибает максимальный размер и уровень сложности проекта который реально своротить. А иногда хочется и вещи посложнее хелловорлдов делать.
4) Никакой верификации что фактические действия совпадают с намерениями - нет. Это ведет к багам на манер яваскриптеров, когда можно в принципе замесить бананы, гвозди, яблоки и что-то еще, сразу может даже и не упадет, а откуда оно потом вон тот бред через полчаса счета берет - поди догадайся вообще. Все тулсы для формальной верификации в жестком пролете.> Что асм запрещает раскидать куски кода по разным файлам, потом их инклюдить?
1) Это не описывает допустим прототип функции и что я его правильно вызываю.
2) Это не описывает истинный характер данных.
3) И кстати это все не портабельно а писать код каждый раз с ноля под разные процы мне таки лениво.
4) И кстати на том же сишке вполне реально затестить сишный алго на компе, с мощной инструментацией, типа ubsan/asan/etc под fuzzer'ом, и 1 в 1 его на МК какой перетащить потом, будучи более-менее уверенным в этом блоке кода, что он способен пережить взаимодействие с враждебным внешним миром, получая оттуда любую мыслимую труху.> а чем код ядра линукса лучше?
Я в нем достаточно нормально навигирую. А благодаря требованием Торвальца "чтоб лезло на экран" я с снайперской точностью гашу баги штуками типа git bisect'а. Я могу даже вообще не знать этот код и подсистему, но при этом за весьма обозримое время локализовать проблему, всех причастных к ее созданию, а в половине случаев даже и экстренный патч себе скроить, просто посмотрев как оно было, что поменяли и прикинув почему это отъехало.
...а еще я билдую ядро линуха под штук пять разных архитектур. На асме я бы зассал кодить пять раз одно и то же, скажем прямо.
> один человек способен его разжевать как вы говорить? На то и создают команды,
> где каждый ведет свой участок кода.Есть глобальная навигация, есть локальная. Я в это умею, поэтому при возникновении проблем, я вполне себе осознаю сначала грубо из какой подсистемы трабл, а потом уже более детально изучаю так или как и почему это там образовалось.
> в этом то и проблема, держать все в одной голове.
На сях и более высокоуровневых ЯП это обходят структурированием, разделением на части и взаимодействием с ними через оговоренные публичные интерфейсы к оным. У асма самого по себе практически нет средств для этого. А уж сделать на нем что-то типа хотя-бы сишного struct вообще не особо вариант.
> в смысле не структурированного? асм это последовательность инструкций, детерминизм никто
> не отменял.Я про структурированность программы и данных с которыми она работает. В ассемблере для этого практически нет средств.
// NB я умею прогать на штуках 5 разных асмах, правда x86 знаю весьма базово, ибо мерзость
> Да почему? Тормозят и глючат просто изумительно. Особенно если гамнокодом накормить.ответ на этот вопрос дает замечательный мультик, https://www.youtube.com/watch?v=vIZVWVJ4_9M
Эйййй, двое из ларца .... :))))))))) загибайте
> В ассемблере нет штатных средств декларирования намерений, нормальной типизации, средств
> организации структур данных и проч.типы, структуры это же формальные понятия, а машина работает с понятием плоской последовательностью. Что значить создать массив из N элементов с точки зрения асм или любую другую структуру? Что из себя представляет тот же C++-ный код в асм листинге? Что мешает писать на асм так же как и генерит компилятор? Компилятор лучше сделает? - не согласен.
> Проблема в том что
> 1) Это не наглядно и нет хорошей декларации структуры которая у меня
> в мозгу.Так для наглядности я могу нарисовать квадратиков прямоугольников, стрелочки указать, подписать блоки и т.д. куда нагляднее будет, чем сидеть и вчитываться в код какого-то непонятного мне формального языка. Да, все что вы говорите легче псевдокодом описать, а дальше сесть и написать инструкции к исполнению.
> 2) Остальные не телепаты чтобы все это знать.
Допустим, человек умеет читать код (знаком с синтаксисом), но не знает предметную область, поможет ли ему "читабельность" кода? Промолчу про то, что "читабельный" код якобы не нуждается в комментариях.
> 3) А иногда хочется и
> вещи посложнее хелловорлдов делать.Так сначала надо предметную область изучить, чтоб потом кодить. К вопросу "читабельности", всякая ли прочитанная книжка нам ясна с первого прочтения? Но не поняв прочитанного, мы грешим на автора. Усердие надо прикладывать, поэтому рекомендую программистам в первую очередь заниматься обратной разработкой, а после программировать на формальных языках.
> 4) Никакой верификации что фактические действия совпадают с намерениями - нет. Это
> ведет к багам на манер яваскриптеров, когда можно в принципе замесить
> бананы, гвозди, яблоки и что-то еще, сразу может даже и не
> упадет, а откуда оно потом вон тот бред через полчаса счета
> берет - поди догадайся вообще. Все тулсы для формальной верификации в
> жестком пролете.исполнение и отладка, формальные языки вообще отвергают понятие отладки, хотя у них есть понятие "покрытие тестами".
> 1) Это не описывает допустим прототип функции и что я его правильно
> вызываю.прототипы, соглашение об вызовах все это формальные понятия.
> 2) Это не описывает истинный характер данных.
плоская модель памяти, конечная, вон Тьюринг описывал бесконечную ленту, что по вашему мне мешает реализовать алгоритм с понятием о бесконечной ленте?
> 3) И кстати это все не портабельно а писать код каждый раз
> с ноля под разные процы мне таки лениво.Лениво? а как же усердие? Знаете почему когда берут в ученики в Шаолиньский монастырь первые пол года ученик с метлой в руках подметает дворы, носит воду и т.д.? То что код должен быть написан под все архитектуры это очевидность, а то что код должен быть написан на всех языках - маразм?
> 4) И кстати на том же сишке вполне реально затестить сишный алго
> на компе, с мощной инструментацией, типа ubsan/asan/etc под fuzzer'ом, и 1
> в 1 его на МК какой перетащить потом, будучи более-менее уверенным
> в этом блоке кода, что он способен пережить взаимодействие с враждебным
> внешним миром, получая оттуда любую мыслимую труху.баловался с МК на сях и ручками выставлял биты в регистрах, спрашивается зачем мне С, если тоже самое я делаю на асм?
> Я могу даже вообще не знать этот код и подсистему,
> но при этом за весьма обозримое время локализовать проблемуа с проблемой ведь сталкиваемся не при прочтении "читабельного" кода, так ведь?
> ...а еще я билдую ядро линуха под штук пять разных архитектур. На
> асме я бы зассал кодить пять раз одно и то же,
> скажем прямо.я тоже может и зассу с 5-ю на улице драться, а есть же люди которые четверых по углам раскидает, а пятый сам себе угол искать будет. Необходимо усердие, плохой я программист когда отказываюсь писать под ту или иную архитектуру? Должен ли я писать код под архитектуру которую слабо знаю?
> Есть глобальная навигация, есть локальная. Я в это умею, поэтому при возникновении
> проблем, я вполне себе осознаю сначала грубо из какой подсистемы трабл,
> а потом уже более детально изучаю так или как и почему
> это там образовалось.почему навигация? описанный вами процесс - отладка (пусконаладка), ну и не стоит забывать про профилирование, ибо внесенные изменения после обнаружения трабла могут регрессивно повлиять.
> А уж сделать на нем что-то типа хотя-бы сишного struct вообще не особо
> вариант.а что представляет из себя struct в плоской памяти?
> Я про структурированность программы и данных с которыми она работает. В ассемблере
> для этого практически нет средств.в асм есть работа с плоской памятью, ваши структуры на сях представлены так же в плоской памяти. а вот в С++ в структурах есть методы, классы какие-то, а в сях нет и т.д. Все это смахивает на один анекдот, Вася готовится к экзамену по зоологии и выучил только раздел про вшей, приходит на экзамен и попадается билет про рыб. Начинает рассказывать про рыб, делая резкий переход на тему вшей, "а если бы у рыб была бы шерсть, то у них бы завелись вши, а вши это ......"
> // NB я умею прогать на штуках 5 разных асмах, правда x86
> знаю весьма базово, ибо мерзостьлично для меня всякие макро асмы мерзость, и попытка сделать их подобием формальных языков высокого уровня. Да легче на формальном языке высокого уровня писать, чем на асм кишащий макросами и всеми конструкциями которые реально не отражены в архитектуре.
> Эйййй, двое из ларца .... :))))))))) загибайтеЕсли их заапгрейдить как следует - нормальненько получается.
> типы, структуры это же формальные понятия,
И это хорошо. Помогает мне помнить что я имел в виду, чем оперирую, помогает другим въехать в код. А еще декларация намерений в том числе и машине (компилеру, анализаторам, ...). Чтобы очевидные грубые несоответствия - отловить на этапе компиляции, а не когда программа сделает волшебный хренакс и (в случае управляюшей фирмвари) что-то $%нет, спасибо если никого не убив. Не хочешь на самолете полетать где fly by wire по твоим принципам сделан?
> а машина работает с понятием плоской последовательностью.
Вот прям все? B-деревья в "ненужно" запишем? Такой ли плоский uint32_t points[10][20][30]? Можно и N-мерный.
Более того. Даже С сделает корректный код для итерирования через массив struct'ов по индексу. Ну вот смотри, есть условное меню. Может на дисплее, консольке, еще где, в принципе не важно. Меню состоит из нескольких пунктов. Может быть какой-то хоткей для быстрого вызова конкретного пункта, ну и функция вызываемая когда пункт активирован. При помощи struct и макросни даже на сишке легко сделать (массив struct-ов) заполняемый типа
ITEM('l', "Go Left", go_left()),
ITEM('r', "Go Right", go_right()),
ITEM('f', "Go Forward", go_forward()),
...
и даже код для парсинга array-я struct'ов скроеного таким способом будет корркетный и читаемый, достаточно итерировать массив как обычно. А терь сделай это линейно в культурном виде, м? Могу представить себе какой трэш будет в коде и декларировании и сколько багов там можно будет выкусить. Это в принципе уже не так далеко от ООПшных фокусов, но еще не оно, ибо ничего оопшного, только struct, массивы да указатели на функции, которые ассемблерщика уж точно смущать не должны. Идея не моя, вольное цитирование по памяти мануала GCC, чтоли.У плюсеров и т.п. есть и штуки даже покруче - итераторы.
> Что значить создать массив из N элементов с точки зрения асм или любую другую структуру?
Ну вон см. выше. Это конечно будет всего лишь генерацией одной большой константы, можно даже наглухо readonly в принципе (rodata). И конечно у нее есть sizeof Но вот ручками ее как плоский регион памяти парсить... придется сперва все абстракции самому запилить, потом, конечно, распарсится :)
> Что из себя представляет тот же C++-ный код в асм листинге? Что мешает писать на асм так
> же как и генерит компилятор?То что в асме нет вон тех понятий.
> Компилятор лучше сделает? - не согласен.
А таки сделает. Если есть где развернуться. В мелком локальном закоулке обставить компилера можно, но сделать какой-нибудь LTO в более крупном коде да удачи. Он в отличие от - видит всю программу, может ДОКАЗАТЬ что та подветка никогда не вызывается и выпилить ее код совсем, заскипает перегрузки регистров, помня что кило назад уже была потребная константа от которой можно оттанцевать, и так далее. А на современных процах "удобной константой" к тому же может быть адресация вида [Rx+N] где в команду кодируется только (маленькое) N. Для человека же пачка смещений от базы не особо читаема.
> Так для наглядности я могу нарисовать квадратиков прямоугольников, стрелочки указать,
> подписать блоки и т.д. куда нагляднее будет,Это сильно отдельная возня и к тому же отдельно от программы. Надо еще и переключаться между задачами. Неудобно. В продвинутых прогерских редакторах есть переход к определению. Так что если я забыл что такое wtf_data_t - ну, ок, после 1 хоткея я освежу свой склероз. Быстрее чем задачи переключать.
> чем сидеть и вчитываться в код какого-то непонятного мне формального языка. Да, все что вы
> говорите легче псевдокодом описать, а дальше сесть и написать инструкции к исполнению.Я бы не сказал что это легче. Особенно под 5 разных архитектур. А чего ради я должен быть прибит на гвозди к одной?
> Допустим, человек умеет читать код (знаком с синтаксисом), но не знает предметную
> область, поможет ли ему "читабельность" кода? Промолчу про то, что "читабельный"
> код якобы не нуждается в комментариях.Для вызова чужой библиотечной функции вообще не обязательно знать ее реализацию и быть вхожим в ту математику, надо знать лишь что на вход, что на выход и границы применимости. Это называется разделение труда. Это называется "разделение труда". И опять же позволяет реюз кода а также масштабирование далеко за пределы того что сможете лично вы. Можно не быть криптографом, но вызвать вон ту функцию писаную криптографом и она таки сделает все как надо. Более того, если я полезу выписывать это сам, 95% что наломаю дров неочевидным образом, область специфичная довольно. И если ей плотно не заниматься, легко облажаться. Вы наверное даже проверку пароля грамотно не сможете сделать так сразу.
Ну вот покажите псевдокод если есть password[30] который ввел юзер и const correct_password[30] с которым сравниваем, как вы проверите что юзер ввел верный пароль?
> Так сначала надо предметную область изучить, чтоб потом кодить.
Знание предметной области не отменяет того факта что допустим 3-мерное пространство будет удобно адресовать как 3 числа-координаты, а вовсе и не линейным регионом.
> К вопросу "читабельности", всякая ли прочитанная книжка нам ясна с первого прочтения? Но не
> поняв прочитанного, мы грешим на автора.В случае программ - в идеале код должен быть понятен даже идиоту. Это гарантирует что менее глупые кодеры его поймут именно так как задумано и не облажаются, сделав глупые баги из-за непонимания работы этого кода.
> Усердие надо прикладывать, поэтому рекомендую программистам в первую очередь
> заниматься обратной разработкой, а после программировать на формальных языках.Не по адресу ремарка. Да и вон то лишь понимание что задумал програмер. Это проще смотреть все же в сорце, увы и ах. Там структура сразу видна и коменты в лучшем случае есть.
> исполнение и отладка, формальные языки вообще отвергают понятие отладки, хотя у них
Вообще, я довольно редко юзаю дебагер. Если не валять дурака, потом все просто работает. Но что за правило без исключения прилетевшего в тыкву...
> есть понятие "покрытие тестами".
Это несколько другое на самом деле, хоть и связано. И да мне это нравится, для понимания правильно ли я вообще логику вон того блока кода оформил и не отъехало ли оно при рефакторе.
> прототипы, соглашение об вызовах все это формальные понятия.
И очень хорошо если это будет описано для компилера и анализатора, что он проверит что все и правда так как задумано. Это спасет от кучи дурных багов.
> плоская модель памяти, конечная, вон Тьюринг описывал бесконечную ленту, что по вашему
> мне мешает реализовать алгоритм с понятием о бесконечной ленте?Конечность ресурсов? А вообще из одних абстракций неплохо делаются другие, с тем или иным приближением. Ну вон у AVR нет MMU - но некто накодил эмулятор ARMv5 + MMU и все же бутанул на этом убунту. Это проще чем допатчить убунту под AVR как оно есть, абстракции вот так слишком далеки.
> Лениво? а как же усердие? Знаете почему когда берут в ученики в
> Шаолиньский монастырь первые пол года ученик с метлой в руках подметает
> дворы, носит воду и т.д.?Ну вот шаолиньским монахам и флаг в руки. Особенно если они заодно МакЛауды. А у меня одна жизня и делать 1 работу 5 раз я не хочу. Тем более что сделать 1 раз и 4 раза основательно улучшить - результат скорее всего будет лучше. Не всегда сразу понятен наилучший путь, иногда надо зарубуться с проблемой вплотную чтобы увидеть лучшее решение.
> То что код должен быть написан под все архитектуры это очевидность, а то что код
> должен быть написан на всех языках - маразм?Я и не собираюсь ВСЕ языки использовать. А вот выписывать на все архитектуры мне не охота, кроме каких-то сильно некоторых случаев когда такой трах окупается.
> баловался с МК на сях и ручками выставлял биты в регистрах, спрашивается
> зачем мне С, если тоже самое я делаю на асм?На сях это можно делать ничуть не хуже. Более того - с препроцессором можно даже компилтайм все делать, precomputed константами и даже compile-time проверками. Когда просто не получится загнать число 22 в 3-битное поле регистра, которое может быть только 0..7 и компилер меня сразу отлупит при попытке это сделать. И я вижу что лажа вышла. Удачи так на асме... там недостаточно аннотации намерений для такого развлечения.
> а с проблемой ведь сталкиваемся не при прочтении "читабельного" кода, так ведь?
Читабельный код является хорошим бонусом. Вооон те господа получили эвон какие баги, по сути на грани вулнов, а все потому что код был тривиален в чтении и я понял что акелла облажался даже не будучи экспертом в кодовой базе.
> я тоже может и зассу с 5-ю на улице драться, а есть
> же люди которые четверых по углам раскидает, а пятый сам себе угол искать будет.На асме это не очень хорошо работает. У мозга есть определенные лимиты на число сущностей которые он может удерживать резидентно. Отсюда необходимость оффлоада и партиционирования знания.
> Необходимо усердие, плохой я программист когда отказываюсь писать
> под ту или иную архитектуру? Должен ли я писать код под
> архитектуру которую слабо знаю?Как бы мой сишный код соберется и будет работать даже на процах про которые я не был в курсе на момент написания проги. Что как бы фича. Все что от них требуется это сишный компилер, и сейчас вообще довольно трудно найти платформу где его не будет.
> почему навигация? описанный вами процесс - отладка (пусконаладка),
Это разные понятия. Обзор кода и его понимание может быть как-то связан с вон тем а может не быть. Может быть и патчингом поведения, реализацией какой-то фичи или чего еще.
> ну и не стоит забывать про профилирование, ибо внесенные изменения после
> обнаружения трабла могут регрессивно повлиять.Есть случаи когда это важно. А есть случаи когда это просто пофигу. Скажем если юзеру надо 0.2 секунды чтобы вообще нажать кнопку, никто не заметит 100 микросекунд я на это реагировал или аж целые 200. Другое дело если это тугой цикл и куча данных...
> а что представляет из себя struct в плоской памяти?
Да в общем то куча байтов в памяти. Однако нельзя взять да скормить его тому кто не готов это сожрать - надо явно декларить входной тип something_t такой же как вооооон там, так я декларирую что готов понимать именно вот это вот на вход в вон той функции.
Более того - это дает некие проверки. Если скажем при рефакторе выпилили определенное поле решив что оно не так уж надо, а какой-то код попытается его юзать - на асме у вас будут трацыбацки. А тут просто компил завалится с "struct something doesn't haves member something_else". Какой код поддерживать лучше - думаю понятно.
> в асм есть работа с плоской памятью, ваши структуры на сях представлены
> так же в плоской памяти.Спасибо кэп. Просто это не самая удобная абстракция.
> а вот в С++ в структурах есть методы, классы какие-то, а в сях нет и т.д.
И это как бы некая фича плюсов относительно сей. Но это сильно больше абстракций и побочных эффектов от них. Си в этом смысле куда более тонкая прослойка между мной и железом, там грань очень прозрачна, я могу почти побитово рулить происходящим лишь немного хуже асма. И знаю как арену с ноля собрать. В случае какого нибудь класса все может стать заметно сложнее.
А таки хорошо заходит в геймдеве, допустим. Там понятие объектов весьма недурно маппится на происходящее. Да и в некоторых других вещахю тоже.
> лично для меня всякие макро асмы мерзость, и попытка сделать их подобием
> формальных языков высокого уровня.Я так то умею в hexspeak, но вот именно прогать так всерьез нафиг надо. Так, поприкалываться немного, скажем "а попробуйте, вообще перетереть мой копирайт вот тут, умники".
> Да легче на формальном языке высокого уровня писать, чем на асм кишащий
> макросами и всеми конструкциями которые реально не отражены в архитектуре.Тем не менее, я и макроассемблеры встречал и на крупных штуках макросня делала код все же несколько менее мерзотным чем он мог бы быть. Но это не решает вопрос с структурированием данных и т.п. вещей (верификация намерений vs реализация например).
> add(a, b) - норм ведьНет. Это снижает удобство чтения кода. Так же, как снижают его бегин и енд. Тогда и точку с запятой надо заменить на какой нибудь enf of instruction. По вашей логике (из следующих комментов) это равнозначно.
>Тогда и точку с запятой надо заменить на какой
> нибудь enf of instruction. По вашей логике (из следующих комментов) это
> равнозначно.кек, вашему парсеру без разницы какой символ будет разделителем инструкций, вон в асм каждая инструкция на новой строке (разделитель - символ новой строки) , но ничто не мешает вам добавить символ разделителя и писать все в одну строку визуально. Итог один для машины - одна последовательность инструкций. Поэтому и говорю, что с точки зрения формальных языков для меня без разницы писать add(a, b) или a+b.
>кек, вашему парсеру без разницы какой символ будет разделителем инструкцийЯ о людях говорю.
>Поэтому и говорю.
Хню говоришь. Чем лаконичнее запись, тем она понятнее. Если в качестве разделителя исполшьзовать не знак, а фразу, то читаемость глазом падает.
>что с точки зрения формальных языков для меня без разницы писать add(a, b) или a+b.
Тоже ложь. Если использовать выражение на десяток операторов, то читаемость падает в разы. особенно если это добротно приправлено скобками. А дополнительные скобки от add() ещё убавляют читабельности.
Стандарты кодирования не зря принимают.
> Я о людях говорю.люди разные от природы.
> Хню говоришь. Чем лаконичнее запись, тем она понятнее. Если в качестве разделителя
> исполшьзовать не знак, а фразу, то читаемость глазом падает.я не люблю Канта, потому что стиль изложения мыслей слишком многословен, так что ли? Вы читаете ради чтения?
> Тоже ложь. Если использовать выражение на десяток операторов, то читаемость падает в
> разы. особенно если это добротно приправлено скобками. А дополнительные скобки от
> add() ещё убавляют читабельности.читабельность :) сначала нужно понять для чего необходим тот или иной символ в формальном языке, то есть изучить его алфавит.
> Стандарты кодирования не зря принимают.
кодирование бывает разное, о каком кодирование речь? и не путайте с понятием сжатия.
> люди разные от природы.И тем не менее большинству более читабелен код, гденет лишних слов. Отдельные альтернативно мыслящие являются интеллектуальными инвалидами и подстраивать под них синтаксис — бред. Это мир большинства, се ля ви.
> я не люблю Канта, потому что стиль изложения мыслей слишком многословен, так что ли? Вы читаете ради чтения?
Ради понимания. А ты?
> читабельность :) сначала нужно понять для чего необходим тот или иной символ в формальном языке, то есть изучить его алфавит.
Это называется абстракцией. Чем выше уровень абстракции, тем выше порог вхождения, но проще использование. Это как с азбукой: да, пиктографическая письменность гораздо проще для понимания её принципов, но азбучная письменность проще в применении.
Тем более что всякие begin, end, or, and интуитивно не понятны и требуют понимания иностранного языка.
> кодирование бывает разное, о каком кодирование речь? и не путайте с понятием сжатия.
Стандарт кодирования — свод правил по оформлению кода на определённом языке, чтобы все участники проекта придерживались одного стиля оформления. Нужен для того, чтобы всякие умники не портили читаемость кода.
>add() ещё убавляют читабельности.я посмотрю как вы читать будете когда ваш формальный язык позволяет перегружать операторы, a+b оказывается не арифметическое сложение.
> я посмотрю как вы читать будете когда ваш формальный язык позволяет перегружать
> операторы, a+b оказывается не арифметическое сложение.Тут да, можно откушать если кодил долбоклюй. Зато можно и довольно эстетично сделать для каких-нибудь расширенных типов. Ну, допустим, можно вектора или комплексные числа складывать в красивой записи всего этого, зная что будет посчитано корректно (если имплементация действа не лажает). В общем-то не бывает так что энное решение идет с одними минусами или одними плюсами, обычно это по факту tradeoff.
> Тут да, можно откушать если кодил долбоклюй.ну язык ведь не запрещает, и не требует - мол оператор + перегружай всегда если он несет логически понятие сложения. Вы же так же будете считать долбоклюем того кто именует функции "нечитабельными" названиями, хотя это не запрещено. Хотя разобраться, что на самом деле делает та или иная функция возможно только если прочесть ее код, а не именование. Картинка мем есть такая про функцию fn random () { return 4; }
Ну вот есть название, функция рандома, а на самом деле это разве функция рандома? :)> Ну, допустим, можно вектора или комплексные
> числа складывать в красивой записи всего этого, зная что будет посчитано
> корректно (если имплементация действа не лажает).конечно можно, согласен, но я заранее об этом должен знать как-то.
> В общем-то не бывает так
> что энное решение идет с одними минусами или одними плюсами, обычно
> это по факту tradeoff.ну тогда и не нужно быть в этом вопросе принципиальным, повторюсь, мне лично все равно писать add(a,b) или a+b, в языке так определили - значить так тому и быть. Имею ли я право говорить, вот китайский язык такой плохой, а мой родной такой лаконичный? - нет.
> ну язык ведь не запрещает, и не требует - мол оператор +
> перегружай всегда если он несет логически понятие сложения.Power comes with responsibility...
> Ну вот есть название, функция рандома, а на самом деле это разве
> функция рандома? :)Так можно на чем угодно облажаться и вот тут мы начинаем догадываться зачем существуют тесты. Эти уже могут более продвинуто прозвонить что то что random выдает хотя-бы похоже на рандом. Или если это детерминированный PRNG, что тестовые вектора правильные с вон тем seed'ом.
> конечно можно, согласен, но я заранее об этом должен знать как-то.
Тут возможно есть некое поле для улучшений.
> лично все равно писать add(a,b) или a+b, в языке так определили
> - значить так тому и быть.Для меня это повод обойти сторонкой яп или софт где меня заставляют писать в 3 раза длиннее на ровном месте. Как извинение я согласен разве что если это для сложных типов, в ограниченном объеме. Но ни в коем разе не постоянно так писать. Иначе это намек что инструмент не подошел к задаче.
> Имею ли я право говорить, вот китайский язык такой плохой, а мой родной
> такой лаконичный? - нет.Ну я со своей стороны просто не буду учить китайский, а если китайцу от меня что-то надо, пусть на инглише шпрехает. Для нас обоих он общий знаменатель как раз и потому что выучить его китайцу было проще чем русский, да и мне проще чем китайский. Поэтому он и используется в глобальных крупных проектах.
> ну тогда и не нужно быть в этом вопросе принципиальным, повторюсь, мне лично все равно писать add(a,b) или a+b, в языке так определили - значить так тому и быть.Это ложь, уже обсуждалось. Ты просто проигнорировал эту мою часть аргументации, но я повторю:
>Если использовать выражение на десяток операторов, то читаемость падает в разы. особенно если это добротно приправлено скобками.
И разработчики языков это знают, ибо для парсинга проще использовать польскую запись: она кодится проще в разы. Но оставляют именно человеческую запись, ибо так понятнее.
>Имею ли я право говорить, вот китайский язык такой плохой, а мой родной такой лаконичный? - нет.Про плохой — нет. А вот про сложный — да. Тут объективный критерий — наличие костылей. В китайском невозможно прочесть незнакомое слово в принципе, ибо иероглифы не несут звуковой информации. А вот азбукой можно. Причём одна из самых простых азбук — кириллица, ибо у нас не звуков, которые обозначаются двумя буквами.
>>add() ещё убавляют читабельности.
> я посмотрю как вы читать будете когда ваш формальный язык позволяет перегружать операторы, a+b оказывается не арифметическое сложение.Ну если писать жёппой, то да, читаемость убьётся нах. Но это вопрос к адекватности того, кто пишет код. Пример явно высосан из пальца.
На самом деле такая проблема есть, иногда "+" при перегрузке могут реально заменить на WTF какой-то. Типа конкатенации строк и тому подобного, порой весьма контринтуитивного относительно логики этого действа. Скажем если (a+b) != (b+a) это не очень то ожидаемо большинством кодеров. Круто же когда типа-сложение вдруг не коммутативно. Известный способ прострела пяток плюсерами, однако.
> На самом деле такая проблема есть, иногда "+" при перегрузке могут реально заменить на WTF какой-то.Разумеется. Каки имя функции не зависит от её содержания. Но это вопрос адекватности кодера.
> Типа конкатенации строк и тому подобного, порой весьма контринтуитивного относительно логики этого действа. Скажем если (a+b) != (b+a) это не очень то ожидаемо большинством кодеров. Круто же когда типа-сложение вдруг не коммутативно. Известный способ прострела пяток плюсерами, однако.Ну всё же сложение строк весьма ожидаемо и коммуникативности от неё мало кто ждёт.
потому что основано на руби
В общем, суффиксы ?!= это просто допустимая часть имени метода. То как они применяются, определяется соглашением об именовании. Вот тут можно подробнее почитать: https://docs.ruby-lang.org/en/master/syntax/methods_rdoc.htm...
Elixir лучше /discuss
Лучше чтобы што? Всегда определите компаратор - в каком контексте сравниваете, для каких задач
> Лучше чтобы што? Всегда определите компаратор - в каком контексте сравниваете, для
> каких задачЭти два языка имеют схожий синтаксис и задачи, не придуривайся.
Нуу, кроме того что у эликсира вм и в любом случае функциональшина с упором на микросервисы, и сабж эдакие статически типизированные компилируемые руби.
Наличие ключевых слов def и end - это ещё не "схожий синтаксис".
По умолчанию Rust :)
В принципе да, сейчас Rust - язык по умолчанию для новых проектов, если разработчики думающие, конечно.
Если хочешь мысленно возвыситься над другими, но объективных причин для этого нет - просто объяви себя "думающим", подразумевая, что твои оппоненты думать не умеют.
Просто сопровождение и развитие большого проекта упрощаются настолько, что многократно оправдывают затраты на обучение. Rust — просто очень эргономичный инструмент, в него вложено много квалифицированного труда и мысли.
> Просто сопровождение и развитие большого проекта упрощаются настолько, что многократно
> оправдывают затраты на обучение. Rust — просто очень эргономичный инструмент, в
> него вложено много квалифицированного труда и мысли.А почему тогда в каждой версии куча костылей? Сразу нельзя было немного подумать над архитектурой? До того как подрываться фигачить?
Ты бы хоть одну книжку про архитектуру прочитал, прежде чем такие перлы выдавать. BDUF для атомной электростанции нужен, но никак не для программного обеспечения.
> Ты бы хоть одну книжку про архитектуру прочитал, прежде чем такие перлы
> выдавать. BDUF для атомной электростанции нужен, но никак не для программного
> обеспечения.А кто сказал что я это не сделал? Более того - я посмотрел как это живые архитекты делают. И почему-то не увидел этот процесс в нормальном виде в хрусте, когда его приволокли в линукскернел. Оказалось что там постоянно надо все на проволоку и скотч донавешивать, и уже в ночнушке вот-вот-почти-искорежили синтаксис под это в очередной раз. Про модульность, опциональность, расширяемость и контроль над происходящим в типа-системном яп не подумали. Зато подумали о каких-то баззвордах и хайпе. А лучше б наоборот. По странным закорюкам оно уже плюсы спокойно может заспорить.
Впрочем, если сравнивать с САБЖЕМ - у хруста, пожалуй, не такой уж и плохой синтаксис :)))
> А кто сказал что я это не сделал?Ты сам. Написав после этого предложения много хрени с умным видом.
> Более того - я
> посмотрел как это живые архитекты делают. И почему-то не увидел этот
> процесс в нормальном виде в хрусте, когда его приволокли в линукскернел.
> Оказалось что там постоянно надо все на проволоку и скотч донавешивать,
> и уже в ночнушке вот-вот-почти-искорежили синтаксис под это в очередной раз.
> Про модульность, опциональность, расширяемость и контроль над происходящим в типа-системном яп не подумали. <<--- [хрень]Можно начать с того, что синтаксис никто не менял ... и на этом закончить, т.к. виден очередной опеннетный эксперт-по-всему.
>> Про модульность, опциональность, расширяемость и контроль над происходящим в типа-системном яп не подумали. <<--- [хрень]
> Можно начать с того, что синтаксис никто не менял ... и на
> этом закончить, т.к. виден очередной опеннетный эксперт-по-всему.Если бы вон то было хренью, я бы не видел тот позор с откровенныым костылированием хруста в рассылке ядра и кивание что потребные вещи дескать вот-вот-почти-уже-в-ночнушках.
Если бы там было хоть какое-то подобие архитектуры - это выглядело бы сильно менее позорно, имхо. Как-то так мы и узнаем "в поле" лохом был архитект или нет. Ну или вон там в новости был пример про something, сделали какую-то совсем уж странную хрень с диковатым синтаксисом. Задвинув любых плюсеров к хренам.
для новых провальных проектов
>для новых провальных проектовЗерно истины в это выхлопе есть... Знаю проекты, которые не смогли развиваться по банальной причине: не нашли достаточно квалифицированных Rust-програмистов, а обучать джунов не захотели...
> Всегда определите компаратор - в каком контексте сравниваете, для каких задач#define comparator //и чего должно было случиться? :)
> Elixir лучше /discussА за яп такой - /discuss? :)
Эскобара теорема. /thread
Этанол ещё лучше.
Многопоточность (нормальную, а не на зелёных потоках) так и не завезли. Жаль.
Я давно предлагал компилировать Crystal в Go :). А как-нибудь потом сделать свой переносимый ассемблер :).
Кстати, вот этот переносимый ассемблер Go — одна из тех штук, которая завораживает своей гениальной сверхэффективностью. Портирование на новую архитектуру как нефиг делать, и не нужно зависеть от монстра LLVM.Обилие обсуждения Go в новости про Crystal наводит на определённые выводы... :)
Уже ничто не сможет стать лучше, чем C++20. Пора бы вам всем уже смириться с этим положением вещей.
Zig передаёт тебе привет.Он УЖЕ лучше чем С++20.
На подходе C++23, у зига нет шансов выстоять в таком зигзаге его печальной судьбы
Он там уже съел, наконец, эту свою русалку?
Надеюсь, ты шутишь. Zig лишь немногим лучше C.
Полностью согласен. С++20 - это венец творческой мысли яподелов, Страуструп можно смело уходить на заслуженный отдых. С++20 - это конец истории, больше никаких япов не должно быть, даже С++23 не нужен.
Это ещё далеко не конец! C++20 привносит новые техники, опережающие своё время: концепты, корутины, новые шаблонные техники с выполнением многих вещей в compile-time, что открывает перед нами чуть ли не принципиально иные парадигмы программирования!
Вообще...
1) Корутины умеет даже LWAN на лысом си так то. Игого вроде тоже умеет. Так что инновация все же врядли инновационная - корутины известны со времен царя гороха.
2) Извините но zig показал всем как compile time вычисления делать правильно: стандартным синтаксисом ЯП без горбатых костылей. Си++ это, имхо, слабо будет в нормальном виде, груз совместимости мешает.
Ну что же, тогда ждём stage3 и берём на вооружение вместе с C++, благо zig несёт в себе компилятор оного, и становимся просто непобедимым гуру в мире программирования. Допустим, мне что-то возразит по поводу C++ знакомый Rust'оман, а ему такой лихо показываю код на Zig, но не называя языка программирования, и он успокаивается. Красота! Буду уважать и изучать Zig. Спасибо!
> Ну что же, тогда ждём stage3 и берём на вооружение вместе с
> C++, благо zig несёт в себе компилятор оного, и становимся просто
> непобедимым гуру в мире программирования.Да мне нафиг не надо быть непобедимым гуру в программировании - скорее разруливать свои задачи, желательно достигая задуманных свойств. Желательно чтобы это не выглядело как свалка костылей и хаков и не ломалось хипстерами каждые цать минут. Zig вроде нащупал дорожку как это делать правильно для compile time вычислений, чем и любопытен.
> Допустим, мне что-то возразит по поводу C++ знакомый Rust'оман, а ему такой лихо
> показываю код на Zig, но не называя языка программирования, и он успокаивается.
> Красота! Буду уважать и изучать Zig. Спасибо!На самом деле тут его кто-то подраскритиковал, местами даже за дело. В основном за баги. Но идея юзануть именно основной синтаксис для compile time вычислений - настолько логичная что вызывает вопрос: #%$, а почему остальные так же не делают?!
корутины появились около 30 лет назад, или даже раньше.Новые техники программирования, аха-ха-ха-ха
Зато у нас есть стандарт языка! И вообще с++ начал слишком быстро развиваться!
*старческий бубнеж*
Для них - новые
Закостенелые крестовики пытаются угнаться за хипстерами.
Две стопки кристалла этому господину!
>удобство разработки на языке Ruby/0
Поделить на ноль означает выразить безграничную поддержку :)
Всегда так забавно смотреть как эпичные неосиляторы нормальных сей или плюсов пытаются оправдать свою безграмотность, лень и неосиляторство придумкой всё новых и новых языков.Уже каждый бездерь по языку убийце плюсов и сей написал.
Ох, истина, если б ты знала, что каждый настоящий знаток C++, заглянувший в его глубины и ужаснувшийся, неизбежно приходит к отрицанию этого великого, но ставшего теперь тормозом прогресса языка.
>придумкой всё новых и новых языковC++11
C++14
C++17
C++20
...
Пробовал я как-то скомпилять этот Кристал - нифига не получилось, очередная жуткая смузи-муть...
Вот придумали как-то люди гвоздь. И ему на замену больше ничего не выдумывали. Умные ведь раньше были люди. В 90-е и 00-е уже придуманы все нужные для человечества япы. Сейчас не о языках программирования надо думать, а о том, что завтра жрать будем - еды уже на всех не хватает, господа.
Ты давно мебель собирал в последний раз? Там тоже гвозди кругом или всё-таки есть "нюансы"?
Виляй дальше, но ты первый без жратвы останешься, и начнешь скулить
Твой кристал вместе голангом на хлеб не мажешь. А вот на С++ можно было бы написать программу, которая смогла бы рассчитать генотип сорта пшеницы, могущей расти в пустыне или на морском дне!
Как программист на досуге докладываю. При сборке мебели гвозди находят очень ограниченное применение - разве что при монтаже задней стенки. А в силовых креплениях лучше использовать винты "конфирматы".
> Вот придумали как-то люди гвоздь. И ему на замену больше ничего не выдумывали.А как же клей и саморезы?! Основательно потеснили местами гвозди так то.
> еды уже на всех не хватает, господа.
При том ты кажется будешь в первых рядах кто это ощутит.
Буду в первых рядах смотреть как ты со знаниями тысячи и одного языка программирования будешь искать работу посудомойщика
> Буду в первых рядах смотреть как ты со знаниями тысячи и одного
> языка программирования будешь искать работу посудомойщикаДа я столько не знаю, лол. К тому же оснвоной фокус моих интересов ближе к управляющим системам и проч. Если без 95% вебмакакятины можно пережить, то без вон того добра человечеству станет довольно душно и это будет сразу и резко откат куда-то в 60-70 прошлого века. Поэтому кмк мне найдется занятий и поинтереснее.
Типичный сишник-фанатик. Ясно же, о чём идёт речь во фразе "все нужные для человечества япы". Так а зачем ты в Интернете сидишь? О еде лучше думай. Зачем вообще компьютером пользуешься? О еде лучше думай. А о еде зачем думаешь? Есть же гвозди.
Ржавоглазый, уже виден ржавый закат твоего недоязыка, а эти гвозди тебе пригодятся для плота, на котором ты уплывешь в одиночное ржавое плавание
cringe level over 9000
К прочтению https://www.opennet.dev/opennews/art.shtml?num=57569#14
Когда выпустят champagne?
С, С++, java, python, c#, rust, ada, haskell, javascript - эти языки можно оставить человечеству, а остальные в топку вместе с модераторами опеннета!
Зачем они все нужны когда есть lisp!
Модераторы вообще не нужны, что с lisp'ом, что без.
Просто нужно запретить постинг из-под тор, и все проблемы решены.
и PL/1
Эти языки можно оставить человечеству разве что как пример несовершенства технологий. Среди них нет ни одного идеального, а значит, прогресс неизбежен.
Smirnoff лучше.
да пусть уже сразу предложат "YazikInZhopa" типа современный, безопасный. Или вот еще как вам идея - язык "GeyPorn" он модный и позволяет избежать 1000 ошибок. А что, здорово же не жить этой жизнью а постоянно читать новости про новые языки ПО в которых пытаются создать бритвенный станок с плавающей головкой, повторяющие контуры лица ) Такая тупость все это современное )) люди реально вроде умные с виду, но по факту такие беспомощные )). Мир вашему дому ) чаще встречайте закаты, рассветы, наслаждайтесь природой ) вытащите голову из земли, оглянитесь. Думаю тогда будет понимание на чем писать и стоит ли вообще заморачиваться про всякую дичь типа безопасный и модный )) как говорят , еще больше вкуса!, еще больше аромата!, теперь в новой упаковке!, купи два и третий в подарок! сникерсни!, радуга новых ощущений! засущиекопейки! да да )) а вы что думали, мир очкариков остался без внимания маркетологов? ))
Тебя заменят нейросети, бубни себе дальше.
Все эти новые языки вносят сумятицу и неразбериху в неокрепший мозг новичка. Вот примерный ход развития нового программиста - итак, с чего бы начать, с/с++ это старье, люди их ругают, надо писать симейки километровые, начнука я с голанга - современный, легкий, никаких симейков, go и вперёд, проходит время - нет что-то не то, надоели эти микросервисы, больше ничего и не сделаешь, давайка на раст перейду - тоже легкий, вон и в ядро его хотят, ура!, вот он язык моей мечты! проходит время - нее, надоели эти лайфтаймы, надо что-то попроще - о функциональный хаскель, как хорошо! проходит время - опять не то, кругом одни функции, надоели, о вот кристал привезли - ну-ка посмотрим, о как хорошо, нет скобок, нет точек с запятыми, проходит время... карбон... проходит время... окамл... проходит время.... а времени прошло очень много, новичок совсем не новичок, а седовласый сороколетний мужик, ни жены, ни детей... одни языки вокруг, а с языками программирования не потрахаешься, детей не сделаешь... эх, лучше бы в 20 лет изучил С/С++, ну может джаву еще на всякий случай. С/С++, джава, питон - вот языки на все случаи жизни, и не надо ломать жизни людям!
Этот комментарий нужно читать голосом Евгения Гришковца, а на фоне включить песню группы "Альянс" - "На заре".
>новичок совсем не новичок, а седовласый сороколетний мужик, ни жены, ни детейВ принципе, ты точно описал удавшуюся жизнь :). Человек проводит время в творческой атмосфере поиска и освоения нового, не отвлекаясь на муторную супружескую жизнь и воспитание детей, которые всё равно его возненавидели бы :).
За 20 лет сознательной жизни такой программист мог бы 7300 раз заняться сексом как минимум, но вся сперма ушла ему в голову - представляю себе какой у него там к 40 годам образуется компостер.
Но ведь мастурбация тоже секс.
>давайка на раст перейду - тоже легкий,однако местные иксперты все никак не могут понять его основную идею и из статьи в статью пишут что-то про смузихлебов
Кстати, а что плохого в смузи? Недавно купил во "Вкусвилле" — обычный фруктовый сок с мякотью.
Да ничего плохого, особенно если с сельдереем.
> Кстати, а что плохого в смузи? Недавно купил во "Вкусвилле" — обычный
> фруктовый сок с мякотью.Небось еще и на гироскутере подкатил, да? :)
>Небось еще и на гироскутере подкатил, да? :)Я-то не хипстер и не смузихлёб. И "Вкусвилл" в соседнем подъезде, никуда катить не надо. А вообще предпочитаю горный велосипед для физических активностей.
> Я-то не хипстер и не смузихлёб. И "Вкусвилл" в соседнем подъезде, никуда
> катить не надо. А вообще предпочитаю горный велосипед для физических активностей.Вы таки исключение из правил.
Ничего плохого, если в меру. Питание должно быть полноценным - мясо, яйца, овощи и немного фруктов. А на одних смузи можно заехать в реанимацию.
Раст - всего лишь обертка над байткодом llvm. Ему до С/С++ как таракану до луны. Кстати, llvm написан на C/C++.
Так C/плюсы - тоже обёртка над llvm
А Rust кроме LLVM можно компилировать через Cranelift (написан на Rust)
Сranelift официально не признается стабильным бекэндом для раста. На сайте rust-lang.org нет ни одного слова про cranelift - ни в буке, ни в номиконе, ни в референсе. Если он написан на расте, словечко должно быть замолвлено на официальном-то сайте. И версия у него ниже единицы. И вообще он сейчас часть вазмтайма. Мутно как-то с ним все. Нет доверия.
> Сranelift официально не признается стабильным бекэндом для раста.Что есть признание? Он есть в репе, и rustc можно собрать с его поддержкой, при этом он стабильнее чем gcc бекенд
> На сайте rust-lang.org нет ни одного слова про cranelift - ни в буке,
И не должно, rustbook про реализацию ничего не говорит, про LLVM там тоже ни слова
> ни в номиконе,
Как и про LLVM, там есть лишь пара ссылок, что некоторые вещи в Rust имеют семантику аналогичную LLVM
> ни в референсе.
Аналогично, там только указание на отдельные детали реализации
> Если он написан на расте, словечко должно быть замолвлено на официальном-то сайте
Зачем?
> И вообще он сейчас часть вазмтайма.
Потому что изначально он разрабатывался как JIT для WASM, но кто мешает то его использовать как бекенд для других вещей?
Признание - наличие крейнлифта по умолчанию. То есть, когда запускаешь rustup, он должен устанавливаться по умолчанию или должен предоставляться выбор - или ллвм или крейнлифт. Этого нет. Если у вас есть опыт использования крейнлифта - расскажите про него, пожалуйста.
Раст - всего лишь обертка над байткодом llvm. Ему до С/С++ как таракану до луны. Кстати, llvm написан на C/C++.
Ого, мой термин прижился, неожиданно.
Как разработки двигаются? linux освоил?
А я с лиспа начал. И на нём же закончил. Всё остальное после лиспа выглядит как поломанный лисп. Стал сисадмином короче в итоге. И платят лучше, и работа легче, и никто не бубнит, мол, язык не тот выбрал — сам себе пишу скрипты на SBCL и иногда Clojure, мне удобно и слава богу.
>Всё остальное после лиспа выглядит как поломанный лисп.Я так в мире разочаровался.
А я нет. Как можно разочароваться в мире, в котором можно прогать на Лиспе?
>Как можно разочароваться в мире, в котором можно прогать на Лиспе?И в котором заставляют прогать не на Лиспе, да ещё жрут и нахваливают сам-знаешь-что, шизофренично предавая кредо сам-знаешь-чего. Только кодинг на лиспе дома и спасает.
Если для тебя Lisp - верх совершенства среди всех доступных ЯП, я рад, что ты на этом закончил программирование. Впрочем, у нас и так целый Опеннет фанатиков, повёрнутых на одном ЯП, что говорит об их ограниченном кругозоре и общей ограниченности, так что твой уход, увы, мало что изменит.
> а времени прошло очень много, новичок совсем не новичок, а седовласый сороколетний мужикК 40 годам страсть к профессии и желание кодить исчезают так как-будто их никогда и небыло, и тогда можно пожалеть только о том что не стал миллионером, чтоб красиво уйти в закат.
> джава, питон - вот языки на все случаи жизни
Жаба 20 лет назад считалась хипсетрсиким менистримом, её любили и ненавидели, прямо как сейчас GO и Python вместе взятые.
> К 40 годам страсть к профессии и желание кодить исчезают так как-будто
> их никогда и небыло, и тогда можно пожалеть только о том
> что не стал миллионером, чтоб красиво уйти в закат.Странно, а я видел кадров которые и в 60+ жгут напалмом. При том имеючи немеряный опыт они могут обставить любого как котенка.
> Жаба 20 лет назад считалась хипсетрсиким менистримом, её любили и ненавидели, прямо
> как сейчас GO и Python вместе взятые.Тем не менее, реально она только в энтерпрайзе возымела какое-то хождение.
информирую: кристал этот не умеет в goto и в выходи из вложенных циклов.. D - лучше :-/
D опоздал. Трудно соперничать с таким эффективным убийцей, как Rust.
> D опоздал. Трудно соперничать с таким эффективным убийцей, как Rust.В D фирмочка долговато жабой насчет компилера душилась. А проприетарные тулчейны в современном мире - ну вы поняли...
Не профессионалы думают, что супер язык решит все проблемы.
Это чисто ДЕЛИТАНСКОЕ "мнение".
> Это чисто ДЕЛИТАНСКОЕ "мнение".Еще и выделил капсом! Да, блин, НеДилетант не палится...
Контрол альт делитантское
Очередной убийца С++. Ну-ну.
Обсуждения Crystal 1.5 как такового нет, зато xxx МНОГО!Вместо xxx подставьте то, что вам по душе.
с++
Ну фиг знает, если хочется питоноподобного синтаксиса, но чтобы было быстрое и компилировалось, можно просто писать сразу на cython, вместо изобретения нового языка.
разработчики которого пытаются... тупо сжечь время своей жизни без результата
Ну не знаю... всё лучше, чем с пивом у мусорки зависать и прохожих пугать.
Других способов тратить время ты не знаешь?
>Опубликован релиз языка
>релиз языка
>языкаПроблему увидели?
Обсуждение читали?
Что меня неприятно удивило, так это существующая возможность не объявлять тип аргумента метода. Методы - часть интерфейса, внутреннего или внешнего (API). И в чём смысл интерфейса, который не даёт даже минимальной информации?
> Что меня неприятно удивило, так это существующая возможность не объявлять тип аргумента
> метода. Методы - часть интерфейса, внутреннего или внешнего (API). И в
> чём смысл интерфейса, который не даёт даже минимальной информации?МОЖНО ГРАБИТЬ КОРОВАНЫ^W^W ВЕБМАКАЧИТЬ!
На мой вкус, идея позаимствовать синтаксические конструкции у ruby(python или php) и сделать честный компилятор очень забавна. Можно ли сделать подобный компилятор эффективным никто не знает. Пока это никому не удалось. К сожалению, золотая эпоха для разработчиков ЯП осталась в прошлом.
Ну а раз нет нормального финансирования, то, боюсь, что ожидать каких-то заметных результатов не стоит.