LINUX.ORG.RU
ФорумTalks

Почему современные яп делают удобными для парсеров, а не для людей?

 ,


1

2

Все эти fn, fun, func, val, var и паскалевское указание типа...

Очевидно, что подобное замусоревание синтаксиса делают ради того, чтобы упростить парсинг исходников. Но неужели программисты менее ценны?

★★★★★

Последнее исправление: ya-betmen (всего исправлений: 1)

поэтому на любом языке пишутся фреймворки, устраняющие недостатки самого языка, на котором они написаны.

Spoofing ★★★★★
()

Нет, парсинг это всё не упрощает. Скорее их делают удобными для инопланетян, которые и придумывают эти новые языки. Просто забей, они каждые 2 года новые появляются и исчезают, можно не обращать внимание.

паскалевское указание типа...

А в этом ничего плохого не вижу.

firkax ★★★★★
()

версия: создатели очередного убийцы С ЯП сами настолько не верят в свое детище, что им лень и не хочется инвестировать в парсер. сверхзадача - заморочить неокрепшие головы смузихлебов потребителей, затестить на широких массах свои (дурацкие) идеи, сделать строчку в резюме и свалить в закат. а, ну да. после того, как склепал собственный ЯП можно говорить «я и Дональд Кнут считаем, что…»

olelookoe ★★★
()

Не спрашивал бы такое, если бы прогал на ПасКале с его бесконечными begin end. После этого хочецца лаконичности.

Psilocybe ★★★★
()

Все эти fn, fun, func, val,

Что это? У меня в c# такого нет. var - полезная, в общем-то, штука.

tiinn ★★★★★
()

Такой глупый вопрос может быть только от сишника вылезшего из vim =)
В современных IDE статические анализаторы для нормальных языков работают практически в real-time. Т.е. не нужно ждать комплияцию или запускать отдельную службу статической проверки на CI, а можно получать нотификаци прямо во время написания.

Все эти fn, fun, func

Вспомни как в сях выглядит возврат из функции указателя на функцию. Человек такое сразу не переварит, не то что парсеры, афигеть удобно.

и паскалевское указание типа

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

Aber ★★★★★
()

В противовес си, для которого придумали утилиты вроде cdecl, потому что он очень человекочитаемый, и в котором чтобы вызвать функцию определённую ниже по тексту, нужно продублировать её сигнатуру выше по тексту.

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

Это си и его потомки c++-джава-джаваскрипт-цщарп скорее с некоторыми странными синтаксическими решениями, которые они друг у друга позаимствовали. Тип вперёд названия переменной — одно из них.

PolarFox ★★★★★
()

Можете предложить пример синтаксиса удобного для людей по вашему мнению?

X512 ★★★★★
()
Ответ на: комментарий от ya-betmen

На работе кодишь без статских анализаторов?

Я видел два подхода, статический анализатор только на CI, когда коммит хуками подхватывается и тестируется (юнит тестами и статическими анализаторами). И другой подход, когда статический анализ происходит прямо в редакторе, а на CI все те-же правила и потому код валидный в IDE проходит вальвацию и на CI.
При первом подходе я кучу раз попадал в ситуацию когда код проваливался на статическом анализе, я делал правку в но все проваливалось в том же месте, потому как какие там правила по codestyle забиты неизвестно, и тратишь по 15-30 минут на проблему которой нету (прохождения всех тестов и затем статического анализа).

Aber ★★★★★
()

грамматика должна быть класса LL1. все остальное ложно. сишная таковой не является. следуя этому нехитрому знанию про LL1 и пишут всякие fun, var, type, class и тепе.

(c) alysnix

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

чтобы вызвать функцию определённую ниже по тексту, нужно продублировать её сигнатуру выше по тексту

С точки зрения человека это довольно логично. Чтобы работать с термином, надо сначала дать ему определение. Это классический книжный подход, если уж на то пошло.

Другой вопрос, что в программировании он себя не оправдывает, т.к. чаще приходится начинать с абстракций, а уже потом уточнять отдельные термины. И обработчик языка может метнуться туда-сюда по тексту пару раз, не развалится, это не в книге выискивать что за переменную M вдруг придумали в формуле, например.

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

странными … решениями…

Тип вперёд названия переменной — одно из них.

«странное решение», а не «решение странное», не так ли?

сначала прилагательное, затем существительное.

сначала «какое», затем «что».

«int abcd», «целое абцд».

странно как раз таки то, что Вы пишете не так, как того требуете. )

olelookoe ★★★
()

Длина ключевых слов едва ли влияет на сложность парсера. Скорее всего авторы хотят ускорить время набора ключевых слов на клавиатуре. Насчёт указания типа переменной после её имени - мои ощущения при программировании таковы, что мне так проще. Я обычно сначала придумываю ЧТО я храню, а потом уже соображаю какого типа это будет. И вот возможность записать сначала имя, а потом думать о типе мне ценна. В C-like языках мне приходится делать микро-усилие, чтобы удержать в памяти придуманное имя переменной, пока вспоминаю какого она должна быть типа.

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

Я не программирую на сях, помню его только по универу, пример из инета могу кинуть:

int (*(*f2)(double))(float);
        f2                   -- f2
       *f2                   -- is a pointer
      (*f2)(      )          -- to a function
      (*f2)(double)          --   taking a double parameter
     *(*f2)(double)          --   returning a pointer
    (*(*f2)(double))(     )  --   to a function
    (*(*f2)(double))(float)  --     taking a float parameter
int (*(*f2)(double))(float)  --     returning int

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

В современных языках с постфиксной записью типа приведенный мной пример выглядел бы как-то так:

let f2: (double)->(float)->int

Неужели этот код хуже читается чем

int (*(*f2)(double))(float);

?

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

Неужели этот код хуже читается чем

Думаю, примерно одинаково: оба интуитивно непонятны. Только вот в Си никто так не пишет, там делают typedef-ы для указателей на функции. Запись как ты написал это, считай, предкомпилированный вид прототипа, присутствует он, в норме, только внутри компилятора.

typedef int (*fn_somename)(float);
fn_somename (*f2)(double);

А вот так читается идеально.

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

Не хуже не означает «лучше» в этом случае. На деле же — аргументация тупоконечника против аргументации остроконечника.

imul ★★★★★
()

О, коллега, тоже коробит синтаксис большинства ЯП. Я понимаю, что на них прекрасно пишут, и тд и тп, но выглядит отвратно и противно как-то парсер ублажать в ущерб человеку, всеми этими скобочками, ";" в конце, $ перед переменными. Из актуальных ЯП мне разве что Ruby-без-рельсов нравится. Няшный, читабельный, лаконичный.

Голая сишечка тоже чем-то приятна, но там как linux-way «ты можешь настроить всё, и ты БУДЕШЬ настраивать всё» :)

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

Тут вопрос не в длине, а в том, что ставят ключевое слово fn перед именем функции, хотя человек прекрасно видит, что это объявление функции.

Или варианты навроде let value: Type = Smth;, человек глазами прекрасно парсит такое без лишних let и двоеточий.

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

Я когда вижу let сразу про бейсик вспоминаю. Возможно все эти новомодные языки им вдохновлялись.

firkax ★★★★★
()
Ответ на: комментарий от ya-betmen

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

Вот например @olelookoe дал пример кода, да его код читается хорошо, но декларацию typedef нужно будет искать либо где-то ближе к заголовку, либо в header файле, т.е. как минимум в IDE нужно сделать переход на декларацию чтоб его прочитать, потом нажать шоткат возвращающий в место использования. Вроде мелочи но наверное они тоже что-то экономят, т.е. я могу себе этим самым доказать что постфиксная запись формально работает лучше - я сразу вижу сигнатуру, любой алиас как минимум потребует знания того что за ним стоит.

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

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

во-вторых вспоминаем про typedef. нет никакой практической нужды заталкивать в одну строку все, что в душе накопилось.

в-третьих, и, пожалуй, в основных. эта лабуда тааак редко встречается на практике, что можно и забить. это не то, что ежеминутно застревает в зубах, как, например, какое-нибудь «fn». а что, еклмн, автоматически невозможно определить, что это fn, нет? уж на что в сях a b(c) вызывает контекстно-зависимые затруднения, но и ничего, справились как-то. что может делать машина пусть делает машина, нет?

olelookoe ★★★
()
Ответ на: комментарий от ya-betmen

Или варианты навроде let value: Type = Smth;

Если компилятор может вывести тип то он позволит опустить его явную запись, получится:

let value = Smth;

Ключевое соло let не только несет информацию о том что тут декларируется переменная, но и то что эта переменная не мутабельна, эквивалент какому-нибудь int const

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

как минимум в IDE нужно сделать переход на декларацию чтоб его прочитать

в IDE у тебя подсказочка с определением всплывет. волшебным образом. никаких туда-сюда.

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

Так синтаксис читается проще

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

Всякий вывод типов и тому подобное, что невозможно читать без ИДЕ такое же зло, когда его пихают везде подряд. Тот же auto внутри for'а вполне юзабелен, но когда всё через него пишут - читать невозможно.

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

Ну наверное да, хорошие IDE никто не отменял.

Aber ★★★★★
()

fn, fun, func, val, var

замусоревание синтаксиса

Как условный func замусоривает синтаксис, не могу понять?

CryNet ★★★★★
()
Ответ на: комментарий от ya-betmen

Человеку? А если ещё объявление переменных дропнуть, то как он всё это будет парсить и отличать одно от другого?

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

Да, сорри, я человек, я могу воспринимать срочку текста целиком, у меня в голове нет конечного автомата, которому нужен четкий порядок токенов.

ya-betmen ★★★★★
() автор топика
Ответ на: комментарий от olelookoe

во-первых это дело привычки, натренироваться такое читать

Да понятно, я просто пытался ТС донести почему в своевременных языках выбирают постфиксную запись. Лично я к любому новшество подхожу с позиции - а могу ли я себе объяснить в чем его преимущество.
Я понимаю почему такой синтаксис начинает доминировать, несмотря на то что я 15 лет кодил на Java я принял новые языки и их подходы, можно увидеть плюсы в таком декларировании типов если отказаться от своего предыдущего опыта.

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

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

с автовыводом типов, в принципе, та же хурма. грабли то там то сям. но в принципе человек ко всему привыкает.

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

так-то ничто не мешает компилятору вывести и что value неизменяема

Там let не для компилятора, а для человека, типа если человек готовит что переменная не должна поменяться, но вдруг где-то в коде в нее вновь присваивают новое значение компилятор должен сказать человеку - «смотри, тута кто-то хотел её поменять вопреки твоей воли!» и ошибки в run-time не случилось.

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

Нет, парсинг это всё не упрощает. Скорее их делают удобными для инопланетян, которые и придумывают эти новые языки.

паскалевское указание типа...

А в этом ничего плохого не вижу.

С какой ты планеты?

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

Как условный func замусоривает синтаксис, не могу понять?

А какая в нём необходимость, кстати? Слово лишнее зачем человеку вбивать? Чем может быть, например, запись «int abc(int a, int b,...) {код}», кроме как функцией?

А, моё любимое «я не понимаю». Щас шитшторм будет, воздуха в грудь наберите(с)...

Какая необходимость в «==» для сравнения? Внутри условия ифа дать возможность присвоение делать? Под какими веществами это может понадобиться?

yu-boot ★★★★★
()
Ответ на: комментарий от EXL

Есть перегибы на местах, да :) Ещё == под ифом.

Ближе руби к английскому языку без клинописи(с) имхо только бейсик, но он как-то после VB6 умер совсем. Я знаю про гамбас, freebasic, powerbasic - ощущение что ими только старые фанаты пользуются, он даже из обучения кодингу везде исчез.

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