Comments 110
Идеальный язык. В следующую версию добавьте, пожалуйста:
- родственные отношения
В обычных языках есть наследование, но оно ограничивается примитивным отношением "родитель-ребенок". Карейсик должен уметь создавать отношения вроде "богатый дядя-племянник", при завершении существования первого ресурсы передаются последнему, или "зять-тёща", увешанных взаимными промисами. - нетерпеливые функции, которые иногда могут и не дождаться await
- мутирующие по ходу их написания функции (это скорее к IDE, но пусть будет)
- блямбда-функции, облегчающие мат в документации
- логику на основе смайликов вместо булевой
:) = True, false => :(, ~_(°•°)_/~ = unpredictable behavior
Эти два выражения выглядят одинаково
А кто такой одинакий и за что они его выглядят?
Только когда дошёл до tryso вспомнил какое сегодня число
Хотел написать гневно возражение на счёт дифыеренциации tab и space, но потом перевернул календарь и все понял. Гениально, что сказать!
Вот вы смеётесь, а кто-то на хабре мне неиронически доказывал, что писать комменты маркдауном и эмбеддить в них рисунки — это не только нормально, а даже и вполне удобно.
Пробовали Wolfram Mathematica?
Хабр — самое злое сообщество по шуткам на первое апреля. Уже какой год единственным разумным решением является просто не читать хабр пару дней. Да я брюзга.
Кроме статической и динамической типизации в языке karasic также представлена типизация кинематическая.вы будете смеяться, но теперь я нашел имя тому поделию, которое видел 10 лет тому назад: оно умело присваивать любые структуры друг другу, присваивая только те части, которые были и в типе-источнике и в типе-получателе, (т.е. если у вас типы одинаковые — то это просто присваивание, а если это присваивание Point в Rect например — то только x и y). При этом еще умело строки в числа и обратно. В общем — все зависело от силы разработчика и энергии его желания что-то куда-то присвоить :)
А как оно в случае тех же Point и Rect поступало с недостающими в источнике полями? Оставляло имеющиеся? Если так, то это, конечно, не присваивание, но вообще-то полезная операция для всяких грязных низкоуровневых дел. Такой типа отдалённый аналог прототипного наследования, но используемый по необходимости, а не при генерации структуры (и поэтому не требующий думать о том, кто кому наследник и как это всё разрешается).
Если аналогичным образом определить операцию сложения, то те же виджеты композируются вообще красиво. Прототип виджета (стиль, логика) плюс точка (координаты), плюс пользовательская сессия (кодировка, локализация) плюс нечто, возвращённое базой данных (собственно содержимое) равно готовый элемент интерфейса. Можно ещё кидать исключение, когда несколько "родителей" имеют общие поля, тогда вообще целая парадигма получается.
Например: источники данных пробовали записать свои структуры в целевую, после чего она передавалась в метод «работаем», после чего структура результата пыталась присвоиться структурам разных отчетов, и если отчет видел что он получил что-то валидное — он о себе рапортовал. Там было много и других вариаций, но подход к присваиванию структур мне запомнился надолго %)
Не раскрыта тема "оступы vs скобочки". Карасик, как по-настоящему дружественный язык, должен принимать оба варианта.
a + b => cНе последовательно. Тогда уж: c => return
return c
a + b => c => return
Ну или для краткости return можно вообще опустить
fn foo(a,b) {
a + b => c =>
}
{ a + b => } fn foo(a,b)
a + b => fn foo(a,b)
Лучше так:
(a, b) => a + b => fn foo(a, b) => a + bУчитывая инновационный инвертированный порядок записи, я бы предложил:
a + b <= (a, b) => fn doo
Для сохранения целостности внутренней логики языка, необходимо изменить порядок следующим образом: }{. Это позволяет создать интуитивно понятное мнемоническое правило:
открывающая скобка "}" — карасик плывет вперед }<>
закрывающая скобка "{" — карасик закончил и развернулся хвостиком вперед <>{, довольно оглядывая функцию.
Еще, в статье ни слова про дебаггинг, что было бы крайне полезно, ведь язык только возник, и в карасик деве все априори будут новичками. Так что ждем дистрибутив с дебаггером jerliza и удобную графическую IDE Oparysh.
Чёрт, я повёлся.
Было бы забавно, если бы эта штука могла компилироваться в JavaScript.
Я считаю, что в язык нужно добавить оператор вероятностного присваивания. На дабл думает, на трипл присваивает.
<think 0.2>
a ?=> b
# На трипл ведёт себя как а => b
# На дабл ведёт себя как if random() <= 0.2 {a =>b}Более формально: значение присваивается с задаваемой пользователем вероятностью не выше 0.1 (всегда присваивает на дабл) и не ниже 0.01 (присваивает только на трипл). Вероятности ниже 0.01 не поддерживаются синтаксисом, т.к. настолько маловероятные события сложно покрыть юнит-тестами. Тем не менее, операции на квадрипл и меньшие вероятности могут быть импортированы из стандартной библиотеки. Распределение униформное, вероятность присваивания на дабл фиксированная для каждого пространства имён и задаётся оператором think <float>. Использование этого оператора несколько раз в одном пространстве имён является неопределённым поведением и кидает ворнинг.
Так как пользователю могут понадобиться значения из других распределений, они могут быть аппроксимированы:
# Распределение бернулли
<think P>
0 => b
1 ?=>> b
# На дабл/трипл ведёт себя как 1 =>> b (или устаревший синтаксис b+=1)
# Биномиальное распределение
<think P>
N => index
while index > 0
{
0 => a
1 ?=>> a
-1 =>> index
}Распределение Пуассона аппроксимируется биномиальным при достаточно высоком N. Аппроксимация нормального распределения выполняется с использованием алгоритмов метапрограммирования. Синтаксис этой аппроксимации слишком громоздок, чтобы поместиться в данном комменте. Но базовая идея состоит в том, что заданная пользователем операция многократно рекурсивно модифицируется таким образом, чтобы создать семейство различных распределений (по дефолту тысячу, но количество может быть определено аргументом компилятора). Затем из каждого распределения берётся по одному значению в том же диапазоне, что и исходная операция. Согласно Центральной предельной теореме, их среднее арифметическое распределено нормально.
Это называется анонимные функции алкоголиков или ай-да-функции!
:= — левое присваивание
=: — правое присваивание
:-)
Вообще хорошая первоапрельская статья получилась.
С Первым апреля! Улыбайтесь чаще!
Если везде указываем тип переменных, функций, то это позволяет компилятору оптимизировать код. Если нет — то код выполняется в рантайме Python.
fn foo(a,b)
{
a + b => c
return c
}В случаях, когда выразительности переносов не хватает, следует применять эвристику.
if a > b
b = a
a = b
Чем больше переносов строк, тем больше надо полагаться на анализатор ЯП, чем на сам код. Таким образом будет решена давняя проблема «выполняется не то, что хотел программист, а то, что он написал».
Однако, сразу можно найти проблему, что оценивать уровень программистов будут по количеству перенов строк в их коде, т.к. чем больше, тем лучше программист дает контекст для анализатора, что позволяет использовать более глубокий анализ, следовательно более оптимизированный и красивый код.
Также будет решены трудности тех безумцев, что поворачивают монитор на 90 градусов.
Предлагаю ввести панику (мне ее после GoLang не хватает) и поддерживаю логику на смайлах и вероятностное присваивание.
Соответственно название проапгрейдить до CarassiusAuratis.
порой бывает, что нужно вернуть значение, а потом его же вернуть из вызывающей функци а та, в свою очередь,… ну вы поняли.
так вот все эти долгие ретурны чтоб заменить на
value ===> return, чтоб длина стрелочки указывала, как далеко нужно возвращать значение.
/**
* функция возвращает такой кортеж (a, b),
* который удовлетворяет условию a + b = c и
* не приводит к фатальной ошибке исполнения
**/
fn foo(c)
{
c => a + b
return (a, b)
} 
В языке karasic табы и пробелы имеют разный смысл!
a + foo(b) => c // табы
a + foo(b) => c // пробелыНо ведь пробелы и так и там! :)
Почему никто не называет язык программирования "Помидор"?
Это же круто. Открываешь вакансии, а там требуется сеньор помидор.
Открываешь стэковерфлоу, пишешь проблему, а в ответ прилетает кусок помидора.
А нет ли версии этого шедевра на английском? Очень хочется коллег порадовать.
Ну и спасибище, конечно!
Обещать не могу, но если выдастся часок, я сделаю тогда.
Вы меня за кого принимаете? :)
Я не только почитать дам, я его вам высылаю для правки — и — если хотите — публикации где угодно. Я его всерьез не вычитывал, возможны описки и / или ляпы. Не обессудьте.
https://gist.github.com/am-kantox/4cb513a300e66762e30563898b5bc781
Исходник полностью годен для публикации в режиме маркдауна на хабре; опубликуйте в англоязычной версии, если не сложно. Ссылаться на меня не обязательно.
Я таки внесу пару мелких доработок и сразу же опубликую :).
Правильное присваивание мне особенно понравилось.
I need an accounting system
P.S. Жаль, что слово assingment в английком языке, как мне кажется, не несёт в себе того же подсмысла, что и в русском. Насколько я знаю, оно обычно в значении «воровать не употребляется». И двое из ларца оказываются не особенно в тему.
Прямо жаль что шутка, мне аж интересно стало посмотреть на результат)
Сравнение всегда обозначалось как >= — "больше или равно", а не символами =>. PHP, например, спокойно использует последние в определении массивов.
a => bзначение переменнойaприсваивается переменнойba >= bзначение переменнойaпереносится в переменнуюb, а переменнаяaстановится деинициализированнойa <= bзначение переменнойbприсваивается переменнойaa =< bзначение переменнойbпереносится в переменнуюa, а переменнаяbстановится деинициализированнойa := bссылка на переменнуюaприсваивается переменнойba =: bссылка на переменнуюbaприсваивается переменнойa
Кроме того, разрешаются
>=> <=< =>> <<= :=> :>= <=: =<: =>: >=:, выполняющие все эти действия разом.Как же тогда сравнивать на «больше или равно» и «меньше или равно»?
Ну, либо через
(a == b) & (a > b), либо через объединение операторов: a ==|> b или a ==+> b
Надо обязательно слоган
Don"t Panic
Язык программирования karasic