LINUX.ORG.RU
ФорумTalks

Концепт языка программирования

 ,


0

2

Продолжаю свои эксперименты с языками программирования.

Вот плод моего больного воображения:

printf: (fmt: @(char const), ...) no_mangle;

main: (argc: int, argv: @(@(char))) -> int {
    i: int = 0;
    while (i < argc) {
        printf("%s\n", argv[i]);
        i += 1;
    }
    return 0;
};

ООП как-то так:

SomeClass: class {
    someFunc: (a: int) public {
        return a * 2;
    };
};

instanceOfSomeClass1: SomeClass;

Ну и массивы:

m: int[100];

Две основные идеи:

1) Обычно программист сначала придумывает название для сущности и только потом окончательно определяется с типом. Си заставляет писать сначала имя типа, а потом уже только потом название, что плохо. А уж всякие модификаторы (public, private, static, extern и т. д.) и подавно можно подобрать уже в самом конце определения.

2) Всякие фигурные скобочки придают коду наглядность куда лучше, чем паскалевский begin-end.

Но есть дополнительные вопросы:

1) Указатели. Как они должны определяться? В примере выше используется конструкция @(базовый тип). В том числе к ней можно применить модификаторы. Например, @(char const) volatile - изменчивый указатель на константный символ. Но можно было бы сделать что-то вроде Pointer(базовый тип), что было бы более наглядно, но и более многословно.

2) Опять указатели. Как следует выполнять разыменовывание указателей? C-style с помощью унарного *? Или может быть Pascal-style с помощью постфиксного ^? А может вообще считать указатели структурами с единственным полем value и делать разыменовывание как ptr->value (допустим, к полям структуры мы обращаемся через указатель через ->)?

3) И снова указатели. Как следует выполнять взятие адреса? C-style &? Или Pascal-style @? Или может неявно при присваивании указателю объекта?

4) Циклы. Классический сишный набор for-do-while с сишным же синтаксисом? Для for можно добавить for-each семантику. Какую? for (переменная: коллекция) или же for (переменная in коллекция)?

5) Шаблоны? Нужно ли? Если да, то какой синтаксис.

6) Алиасы для типов. Следуя основному стилю языка лучше сделать что-то вроде MyIntType: TypeAlias(int);, но это выглядит как введение ещё одного ключевого слова в язык. Может использовать какой-то символ? Какой?

7) ++ и --. Из-за этих операций возможны всякие странные вещи типа ++i + ++i. Так ли это плохо?

8) Преобразования типов. Варианты: сишный вариант (тип)значение. Паскалевский вариант тип(значение), C++ вариант reintepret_cast<тип>(значение). Что лучше?

Да, сам язык будет использовать концепцию модулей. Опрережающие определения не нужны - компилятор будет двухпроходным. Таким образом все определения из текущего модуля будут считаться объявленными в любой момент времени. Разумеется, циклы в иерархии наследования классов допускаться не будут. Подключение других модулей выполняется с помощью ключевого слова import some.module; Импорт возможен только до первой декларации. Взаимный импорт модулей должен корректно разруливаться компилятором (а не как в Python).

Весь код транслируется в Си. Причём язык позволяет закодировать любую сишную конструкцию (в том числе всякие грязные преобразования типов и т. д.). Более того, можно сделать что-то типа import «stdio.h». При этом компилятор с помощью libclang по-быстрому парсит подключенные заголовочные файлы, таким образом видит все сишные определения как свои (разве что с макросами печалька, но можно и этот момент частично разрулить).

Разумеется, помимо ООП и шаблонов должны быть лямбда-функции и асинхронное программирование.

UPD: Про псевдонимы типов придумал вариант синтаксиса получше.

NewType := OldType;

Логика простая - если вместо имени типа сразу идёт =, то это не обычное определение, а псевдоним типа (таким образом чисто технически между : и = может быть пробел).

★★★★★

Последнее исправление: KivApple (всего исправлений: 5)

яр, кодица, Даниллица

для оживления беседы ... cast Oreolek, den73, Dreamject

По теме: а как в твоём синтаксисе будет выполняться рефакторинг кода? Облегчена ли эта задача?

pacify ★★★★★
()

У тебя там просто плюсы с нескучным синтаксисом? И нафиг такой язык нужен?

theNamelessOne ★★★★★
()

Две основные идеи:

1) Обычно программист сначала придумывает название для сущности и только потом окончательно определяется с типом. Си заставляет писать сначала имя типа, а потом уже только потом название, что плохо. А уж всякие модификаторы (public, private, static, extern и т. д.) и подавно можно подобрать уже в самом конце определения.

Это всё настолько неважно, что я даже не знаю.

2) Всякие фигурные скобочки придают коду наглядность куда лучше, чем паскалевский begin-end

Во-первых, это спорное утверждение («фломастеры на вкус разные»), а во-вторых, это опять по сути неважно.

Итого, все твои «основные идеи» касаются незначительных нюансов синтаксиса.

theNamelessOne ★★★★★
()

Ничего нового и интересного не увидел. Лучше бы сделали что-то с поддержкой распределённого программирования. Чтобы, скажем, вместо классов были агенты, независимо крутящиеся в разных тредах или вообще на разных машинах (прозрачно), с простой синхронизацией и отладкой, а обмен и выборка данных штатно осуществлялась через полнофункциональную СУБД.

Sadler ★★★
()
Ответ на: комментарий от Sadler

Почти везде можно акторы с бекджеком вкорячить. Идея восхитительная, да только никому не нужная (эрланг и скаловская акка не в счёт ;) )

slaykovsky ★★★
()
Последнее исправление: slaykovsky (всего исправлений: 1)

Но есть дополнительные вопросы:

Опять почти все про синтаксис (кастовать типы как в Паскале или как в плюсах, лол). Что нового твой язык сможет предложить программисту?

theNamelessOne ★★★★★
()

лямбда-функции и асинхронное программирование

ЯННП. Все же уже есть в сях. Зачем еще одни си? На счет модулей - скоро в кресты завезут.

slaykovsky ★★★
()

Концепт языка программирования

Универсальный инструмент на все случаи жизни создать невозможно, например, даже молоток реализован в виде более 2-х десятков типов, а ЯП — сложнее...

Всякие фигурные скобочки придают коду наглядность куда лучше, чем паскалевский begin-end.

{ } — неэргономичны, колют глаза. Я бы их запретил навечно и заменил на наклонные

[ ].

quickquest ★★★★★
()

А смысл? Те же кресты, только вид сбоку. Посмотри в сторону функциональных и декларативных языков. Там указатели, циклы и явное указание типа вообще не нужно.

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от DNA_Seq

Динамическая типизация - привет просадки производительности. Для скриптовых языков ок, для чего-то низкроуровневого нет.

KivApple ★★★★★
() автор топика
Ответ на: комментарий от Sadler

Ты это предлагаешь человеку который только что открыл для себя анонимные функции (наверное потому что их пару лет назад в жабу добавили, не прошло и 20 лет).

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от KivApple

Зависит от задач. Если оперировать большими объектами (например матрицы на пару десятков мегабайт) динамическая типизация может и быстрее оказаться.

DNA_Seq ★★☆☆☆
()

@(@(char)))

отвратительное уродство и вообще.
в первом примере количество нажатий шифт почти равно другим символам. предлагаю язык назвать «шифт»

system-root ★★★★★
()
Последнее исправление: system-root (всего исправлений: 1)
Ответ на: комментарий от system-root

В Rust указатели объявляются с помощью ~ или @, в C с помощью *. Предполагаю что тебе не нравятся скобочки.

KivApple ★★★★★
() автор топика
Ответ на: комментарий от KivApple

я не хейтер вида скобочек, мне без разницы
проблема в том, что есть шаблоны мышления, которые трудно сломать
если я скажу: «хреново придумывать новый язык, в котом половина — это спецсимволы»
ты можешь парировать: «а вот в С..»
и всё, дальше хоть мульён комментов на тему UX, про импринтинг, шаблон сломать сложно.
не утверждаю, что у тебя шаблонное мышление, просто открываю все карты сразу

system-root ★★★★★
()
Ответ на: комментарий от KivApple

В Rust указатели объявляются с помощью ~ или @

У вас какой-то неправильный rust. Там нет ни ~, ни @ (когда-то было, да).

RazrFalcon ★★★★★
()

@(@(char))

Это более лучший си, да? Спасибо, но НЕТ.

bread
()
Ответ на: комментарий от KivApple

считаю более человекопонятными python и groovy
if sone in list или 8.times { println it }
это нормально, не прорыв, но нормально. делать хуже сейчас — сразу RIP
уже не шестидесятые, людям нужны удобные инструменты с минимальным уровнем вхождения, а не {$_ == $_[0]} @{$_[1]};
и главное, понимание, что завтра погромисты — это люди рожденные в 2000х, просто посмотри их уровень на любой JSConf, когда 40 минутный доклад про то, что ты ещё в школе наверное знал
но не они твое ЦА, все намного хуже.
твое ЦА ещё универ не закончило. вот и думай, кому из них нужно (argc: int, argv: @(@(char))) -> int

system-root ★★★★★
()
Ответ на: комментарий от system-root

а если считаешь, что простота, UX и уровень вхождения не важны, что нормальные ребята выбирают мощь и математику — сходи на могилку к Scala

system-root ★★★★★
()

Какое-то детское ненужно.

tailgunner ★★★★★
()
Ответ на: комментарий от slaykovsky

Вот было бы еще неплохо, если бы вывезли #include «file.c» и запретили тело функции в .h файлах помещать

cvs-255 ★★★★★
()
Последнее исправление: cvs-255 (всего исправлений: 1)

https://github.com/BSLang/BS

#define /^my (.*?) thing:$/class \1:/
my Greeter thing:
  public function __construct(€name)
      HALT_AND_CATCH_FIRE
    (unless €name !=== null);
    €this->name = €name;
    Delete €name;

  public function say(€thing isProbablyA String)
    echo €thing, « », €this->name, BS::EOL;
    Delete €thing;

https://skillsmatter.com/skillscasts/6088-the-worst-programming-language-ever

BS. Why? Because fuck you, that's why!

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 2)

плод моего больного воображения

пффф. ты APL видел? вот это плод реально больного воображения, на уровне Obfuscated Perl Contest если не хуже

upcFrost ★★★★★
()
Ответ на: комментарий от DNA_Seq

Не вариант.

Анонимные функции в джаве – это те же самые анонимные классы, только чуть более сахаристее, которые в джаве есть чёрт знает сколько лет.

mono ★★★★★
()

по большей части - фигня

надо определиться какую задачу кроме (вымышленного) синтаксического сахара язык будет решать

если смотреть на историю, то python, ruby, lua, etc не дали народу ничего нового и поэтому кроме модности («такая-то компания их применяет») смысла в их появлении нет. Отдельно тут стоит Perl: у него динамическая типизация, позволяет программисту меньше думать над глупостями.

из свежих новых языков: Go - оба вида многозадачности поддержанные прямо в языке. Это пример того что язык что-то (относительно) новое предлагает. Из за того что правда не доделан (нет ексепшенов и еще пары очень употребительных вещей) - пока слабо востребован.

Из старых - конечно LISP - кузница ВСЕХ IT технологий.

А какую задачу будет решать Ваш язык?

rsync ★★
()
Ответ на: комментарий от quickquest

молоток

Обычно используется один молоток для всего)

dormeur86 ★★★★
()
Ответ на: комментарий от KivApple

А при чём тут динамическая типизация?

Miguel ★★★★★
()
Ответ на: комментарий от system-root

В понедельник приду на работу, расскажу Скале, что она в могилке.

Miguel ★★★★★
()

А в общем да, менять синтаксис — последнее дело. Семантика нужна, а синтаксис приложится.

Miguel ★★★★★
()

А может вообще считать указатели структурами с единственным полем value и делать разыменовывание как ptr->value

всячески за. должно снизить порог входа

Как следует выполнять взятие адреса?

как часто это предполагается делать? Может быть тоже сделать у каждого объекта поле «адрес»? опять же должно снизить порог входа

Циклы. Классический сишный набор for-do-while с сишным же синтаксисом?

лучше перевести фокус на стримы, а в первом релизе не делать циклов вообще

array.forEach (arg: int -> { ... })

Из-за этих операций возможны всякие странные вещи типа ++i + ++i. Так ли это плохо?

в новом языке нет легаси совместимости - можно просто задать порядок для таких операций, чтобы не было UB

reintepret_cast<тип>(значение)

для русского человека название неблагозвучно

я за автоматические методы типа x.toInt

можно префикс .to в названии метода сделать «специальным», и при наличии в классе метода с названием типа stringToInt подхватывать его для конвертации

или проще, сделать у всех метод .to, у которого первый аргумент - название типа. x.to(Int), а метод-конвертер ищется аналогично

но если автор - мудак, и накодил прямо толстый слой кода с кастами, то без автокастинга выглядит громоздко. Может, по-умолчанию автокастинг выключить, но сделать хинт компилятору, который включает его только для отдельной строки или блока.

типа:

auto x = autocast {
    1 + "x" / 163 ++ + ++ + y # черт знает что такое, скопипастил со Stackoverflow
}
stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)
Ответ на: комментарий от system-root

Питон не очень красивый (тот же Руби логичнее), но согласен.

{$_ == $_[0]} @{$_[1]};
Вот говорят, фильм для дураков, а мне понравилось!

DNA_Seq ★★☆☆☆
()
Последнее исправление: DNA_Seq (всего исправлений: 1)
Ответ на: комментарий от system-root

просто посмотри их уровень на любой JSConf

Так это верстальщики, что по ним судить. Дальше формочек для сайта их не пустят все равно.

bread
()
Ответ на: комментарий от DNA_Seq

@{$_[1]};

Вот ТС явно вдохновлялся перловкой. Этот синтаксис дереференсинга я возненавидел сразу как увидел перл, а так то язык нормальный. Понятно, что ссылки к перлу сбоку прикрутили, от того такая бяка.

bread
()
Ответ на: комментарий от bread

В данном случае это скорее приведение к типу, но не суть важно. Это очень угребищно, и вообще кому нужны эти ваши указатели в 2017?

bread
()

Напоминает забаву времен моей юности - «писать 3д движок» или «онлайн 3д игру с нуля». Так же наивно и безрезультатно :)

CaptainFarrell
()

Господа, что вы думаете про оператор switch? То что он нужен у меня сомнений не вызывает. Но в каком виде?

C-style - синтаксис с метками и break.

Альтернатива:

switch (some_var) {
    0: printf("!!!");
    1, 2, 3: printf("???");
    10: {
        printf("?!");
        some_flag = true;
    }
    11 ... 20: {
        printf("???!!!");
    }
    default: printf(":-(");
}

Возможно, вместо : лучше использовать =>.

Так ли нужна возможность вместо выхода из switch перейти к следующему варианту?

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

То что он нужен у меня сомнений не вызывает

всё короче понятно. нахрен ооп, нахрен что-то интересное, нахрен дискуссию, у нас тут новейший язык погроммирования уровня:

#define и &&
#define или ||
#define чатко const
#define базарь cout<<
#define спроси cin>>
#define это =
#define сука ==
#define то )
#define иначе else

system-root ★★★★★
()
Ответ на: комментарий от system-root

На самом деле нет.

Например, я тут хорошенько подумал насчёт шаблонов и решил, что описываться они будут таким образом:

x: <T, i: T> (x: T) -> T {
    return x + i;
}
...
x(int, 10)(20)

Суть в том, что по семантике шаблон функции это функция, возвращающая функцию в качестве результата (но всё это происходит в compile-time).

Но я допускаю и вариант поинтереснее:

f: <i: int> -> int {
    i: int = 0;
    for (j: int = 0; j < i; j++) {
        i += j;
    }
    return j;
}
...
f(10)

Суть в том, что функция f будет полностью выполнена в compile-time (на неё будут наложены небольшие ограничения - она может вызывать только другие такие же функции, а также не может разыменовывать указатели).

Вообще, я бы хотел добавить в свой язык побольше всяких плюшек, касающихся мета-программирования. Должна быть возможность как можно больше всего делать в compile-time.

А вот в runtime не считая поддержки асинхронности (что-то типа resumable-функций из черновика стандарта C++) хочу оставить всё как есть. Чистая функциональщина имеет слишком высокий порог вхождения.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от KivApple

шаблон функции это функция, возвращающая функцию

http://groovyconsole.appspot.com/script/529001
def func = first makeFactors then duplicate then print
в сравнении с
x: <T, i: T> (x: T) -> T
как бы намекают на инновационность

касающихся мета-программирования

ага, switch взаместо каких нибудь рефлекшинов очень мета, очень ООП, очень функционально

ещё в самом начале говорил про рамки мышления, а ты опять про «стандарты C++»
так бы и написал в стартовом посте — хочу мол свой Си изобрести в 2017 году, с нескушными указателями и пофиг что с llvm можно супер высокоуровневый язык создать, вот считаю нужно быть ближе к земле, нужен Си
я бы вообще сюда не написал, ты ввёл мне в заблуждение.

system-root ★★★★★
()
Ответ на: комментарий от theNamelessOne

Надеюсь, что такие как ты никогда не будут участвовать в разработке языков программирования. Есть странные люди, которые за каким-то хреном пытаются делать языки высокого уровня для машин а не для человека. Хотя, ты же кот.

Xintrea ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.