LINUX.ORG.RU

итак, боремся с грустными смайликами

 , ,


2

5

В С любой оператор должен заканчиваться точкой с запятой. Это порождает грустные смайлики ");" и «};» и я попытаюсь от них избавиться. Я изначально сомневался, нужны ли точки с запятой, и вот теперь появился против них ещё серьёзный аргумент.

Практически я имел дело с двумя языками, где нет точек с запятой - это tcl/tk и язык определения макросов в C. Перенос на новую строку осуществляется с помощью «\». Это выглядит и ощущается как голимая кустарщина. И это неудобно.

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

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

Удачно ли golang обходится без точек с запятой? Удобно ли это, понятно ли? Стоит ли так делать в новом языке?

Ну или может быть есть ещё какие-то языки, где этот вопрос решён красиво.

Я пока придумал только одну вещь на замену «\». Сделать правило, что если в строке есть несбалансированная открывающая круглая скобка, то следующая строка является продолжением предыдущей, и так до тех пор, пока скобка не будет сбалансирована. Так, по сути, сделано в лиспе.

★★★★★

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

Удачно ли golang обходится без точек с запятой? Удобно ли это, понятно ли? Стоит ли так делать в новом языке?

да

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

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

А в голанге точка с запятой расставляется компилером. при этом если строка заканчивается запятой, то точка с запятой не ставится

Bad_ptr ★★★★★
()

Удачно ли golang обходится без точек с запятой?

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

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

при этом если строка заканчивается запятой,

в реальности когда списки очень длинные, удобнее начинать строчку запятой, а не заканчивать. Разница в удобстве довольно ощутима.

Жаль, если это окажется несовместимым с затеей авторов голанга.

Меня не устраивает ситуация с автоматически добавляемой точкой с запятой. Меня устраивает ситуация, когда её вовсе нет.

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

Я так понял, тебе не нравится. Сама идея навязанного стиля оформления кода мне нравится. Нет никакого смысла иметь несколько, это только мешает работе. Но удачен ли конкретный стиль golang - мне пока неясно.

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

Сама идея навязанного стиля оформления кода мне нравится.

большого успеха твоему язычку, лол.

навязанный стиль — это как северная корея, только много хуже.

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

Нет, мне все равно. За меня gofmt оформляет.

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

навязанный стиль — это как северная корея, только много хуже.

Не похоже, что это заметно мешает популярности Gо.

DarkEld3r ★★★★★
()

Поменяй местами скоьочки будет позитивнее {;

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

навязанный стиль — это как северная корея, только много хуже.

> Не похоже, что это заметно мешает популярности Gо.

Просто некоторые горе-программисты и python в глаза не видели и это для них тоже г-язык. Но поголдеть-то им требуется.. иначе ломка

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

Удачно ли golang обходится без точек с запятой?

Прекрасно, но они там всё же есть, если надо.

Удобно ли это, понятно ли?

Да, да.

Стоит ли так делать в новом языке?

Новые языки делать не стоит. ;)

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

Необходимость писать «\» выбешивает меня где-то меджу 3-й и 5-й строчками. Да и уродливо это выглядит. Кроме того, если после «\» есть пробел, то это уже не срабатывает.

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

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

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

Я пока не наблюдаю её. По вакансиям.

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

Новые языки делать не стоит. ;)

go тоже новый язык. Его тоже делать не стоило. Верно я мыслю?

den73 ★★★★★
() автор топика

Практически я имел дело с двумя языками, где нет точек с запятой

го самообразовываться, приходи после двадцати. языков и лет.

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

Спасибо. Годнота. Он понимает не только запятую, но и плюс в конце. И открывающую круглую скобку тоже. А многосточные строковые литералы не понимает почему-то. Странно.

Хорошо то, что информация о том, является ли эта строка последней, находится в самой строке. МОжно было бы сделать так:

f(

всё здесь до балансирующей скобки является списком аргументов

)

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

Вообще есть много людей, которые говорят, что голанг плох и в нём масса ошибок проектирования, что хипсторы, которые его изобрели, совсем тупые и т.п. Ты так не считаешь?

den73 ★★★★★
() автор топика

Это порождает грустные смайлики ");" и «};» и я попытаюсь от них избавиться.

сделай свой ЯП wiki-style - пустая строку разделяет операторы :-) транслятор в C со столь малыми отличиями можно сделать наверное за день

потом можно избавится например от значительной части {} заменив на закрывающий тег. получится «int foo() some code \foo», что кстати читается вполне ясно.

избавляесь от смайликов можно ещё заюзать # в операторах (она всё равно специфична), чтобы подавить «>=(» вот такую грусть, заменить на её например на «#GE(»

в итоге получится «Не-Хмурый С» без смайликов, но мало кому понятный :-)

PS) можно ещё активно использовать диграфы и триграфы, тогда С-программа просто-таки расцветает смайлами, остаётся коректной, но становится непонятной неофитам

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

в реальности когда списки очень длинные, удобнее начинать строчку запятой, а не заканчивать. Разница в удобстве довольно ощутима.

Внезапно некоторые языки позволяют оставить висящую последнюю запятую. Вот это удобно по настоящему.

anonymous
()

И вообще, давайте перестанем пинать автора за его неудачную поделку, как минимум ТС узнал много нового, а это хорошо.

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

потом можно избавится например от значительной части {} заменив на закрывающий тег. получится «int foo() some code \foo»

Конгениально! Вопрос лишь в нехватке значков. Использовать обратный слеш совсем не хочется. Прямой занят на разделение библиотеки от модуля. Перекинуть, что ли, точку с запятой на библиотеки?

Насчёт диграфа не понял. кн можно считать нео-диграфом или имеются в виду значки из utf-8?

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

Внезапно некоторые языки позволяют оставить висящую последнюю запятую. Вот это удобно по настоящему.

Не понял. Можешь пример кода привести?

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

Насчёт диграфа не понял?

в С/С++ исторически есть спец-последовательности символов, чтобы shift не растаптывать. Например ??> эквивалентно }

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

Валидный код на C (в современном gcc собирать с -trigraph, раньше было не нужно):

??=include "stdio.h"

main() ??< 
        puts("hello den73!");
??>

beastie ★★★★★
()

Практически я имел дело с двумя языками, где нет точек с запятой - это tcl/tk и язык определения макросов в C

А SQL?

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

SQL. В принципе, неплохой язык. Как он работает? Пункты разделяются ключевыми словами, точнее, начинаются с ключевых слов select from, inner join, having. Но это не ЯП общего назначения.

Хранимки. В Firebird есть точки с запятой.

В MS SQL их нет, но конец строки не имеет значения. Возможность обойтись без точек с запятой обусловлена прежде всего отсутствием операции присваивания - есть оператор присваивания set, но нельзя напиасать просто а=б.

Некоторое время я думал над этим, но мне казалось, что это слишком сильно сломает традицию. Хотя вроде ни у кого нет проблемы с освоением хранимок ms sql. Может быть потому, что в начале карьеры язык хранимок воспринимается как нечто вспомогательное и не думаешь, что на нём придётся писать много, а потом привыкаешь.

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

И ещё тогда вопрос - как перевести это на Русский. Если называть это словом присвоить, то получается перебор по многословию. Пусть не годится, оно для биндингов (let). Или опять надо вымучивать сокращения. Хотя можно сделать префиксную форму:

= a b // поместить в а значение б
Также нужно учитывать, что в MS SQL переменные выделяются собаками, @переменная. Мне это тоже всегда казалось кустарщиной. Если это правило выкинуть, вдруг может оказаться, что невозможно работать без точек с запятой - я не знаю, это только практика может показать.

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

незапно некоторые языки позволяют оставить висящую последнюю запятую. Вот это удобно по настоящему.

Наверное, я понял. Имеется в виду, что

a,b,c
и
a,b,c,
означают одно и то же?

Подобное я считаю большой ошибкой и никогда в свой язык такое не включу.

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

потом можно избавится например от значительной части {} заменив на закрывающий тег. получится «int foo() some code \foo», что кстати читается вполне ясно

И здесь мы радостно вспоминаем, что не занят примыкающий к слову // И получается

фун заё(а - цел32,конст; б) - // перенос как в golang
    тип_кортеж(в - цел32;г),  // то же
    чистая
  если/*м*/ (а яр.библиотека/велесова_книга:> б) то
    возврат кортеж(а
      ,б)  // возможность переноса обсусловлена небалансом скобок
  иначе/*м*/
    возврат кортеж(б,а)
  м//
заё// 
Что-то это выглядит слишком новаторским даже для автора...

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

Я не сказал бы, что язык со встроенной сборкой мусора может считаться продолжением линейки, включающей С. Можно говорить о дереве. Дерево даёт разные ветви. Некоторые отсохли. Некоторые можно прикрепить по-другому и вырастить в своём сознании дерево не так, как ты его вырастил. Например, я впервые слышу об Alef и Limbo, а Java ты не упомянул, хотя в ней сборка мусора есть и она тоже растёт от С.

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

Scala, Python, да даже на JS можно писать без точек с запятой

Scala не взлетела, Python мне не нравится, в JS и раньше было полно косяков типа сложения не тех типов.

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

Почему? В питоне, например, очень удобно:

APP_MODULES = (
    'app.foo.module',
    'app.foo.module2',
    'app.baz.module',
)
Избавляет от ошибок расширение кортежа, например.

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

Но из Явы уже ничего не растёт. ;)

Двое других, о которых ты не слышал, являются прямыми предшествинниками (из Plan9 — те же люди, продолжение тех же идей).

TL;DR:

  • Unix — C (Thompson, Ritchie)
  • Plan9 — Alef (Thompson, Pike)
  • Inferno — Limbo (Pike, Ritchie)
  • OS agnostic — Go (Thompson, Pike)

PS: по воводу имён — на 100% не претендую, там и другие люди были замешаны, но тенденция просматривается. :)

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

Какие проблемы с этим кодом? Прежде всего, при переименовании функции нужно переименовать и закрывающий таг. Во-вторых, таг в «если» не грепится.

Сделать так:

если%м а вк:> б то
  возврат цепь(а,а делить б)
иначе%м
  возврат цепь(б,б делить а)
/%м
Но это уже жертва значка.

Всё же, наверное, мы можем себе позволить только лишь

фун заё(а;б) - тип_кортеж(2), чистая
  если/*м*/ а вк:> б то
    возврат цепь(а,а делить б)
  иначе/*м*/
    возврат цепь(б,б делить а)
  кн/*м*/
заё//
Хотя получается конкретно больше букв. Но с «если» трудно поступить по-другому, ведь никто не обязывает, чтобы оно было именованным.

Хотя при неименованных условных конструкциях можно так:

фун заё(а;б) - тип_цепь(2), чистая
  если а вк:> б то
    возврат цепь(а,а делить б)
  иначе
    возврат цепь(б,б делить а)
  если//
заё//

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

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

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

И здесь мы радостно вспоминаем

что нужно выдыхать

PS/ откуда такое мерзкое импортное злово «кортеж» ? пусть путь «цуг» (от «лошади запряженные цугом»). А «фун» ?? должно быть «действо»

Гулять, так гулять:

действо СреднееИзДвух от число1 число2 это
  уполовинить (число1 прибавить число2)
\СреднееИзДвух

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

Kotlin 1.0.0 RC / February 4, 2016; 4 days ago

M'Kay. (В первый раз про него слышу).

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

Ответье мне лучше, кому вообще сдался язык не на ASCII? Может тогда уж лучше мандарин или канжи? Всёж аудитория будет больше, чем свидетелей koi-8.

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

Если интересно и есть опыт, можешь принять участие в разработке более плотно. Режим управления авторитарный, критерии качества туманны, денег не плачу :) Я не работал с многими языками, мне не хватает кругозора.

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

Я посмотрел на примеры синтаксиса scala вот здесь.

Мне не нравится

scala> greet()
...
scala> greet
...
Нет никакого смысла в такой неоднозначности. Например, как я в коде отличу переменную от метода без параметров? Далее:

var i = 0
while (i < args.length) 
{
  if (i != 0)
    print(" ")

  print(args(i))
  i += 1
}
println()

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

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

Вот нашёл страничку:

https://wiki.theory.org/YourLanguageSucks

Хотя довольно дурацкая, но лучше чем ничего. А вот про неоднозначности в scala (я ожидал, что их гораздо больше, но нашёл, как ни странно, только одну)

http://www.scala-lang.org/old/node/875.html

В общем, пока не готов разругать scala окончательно, но наверняка решение этой задачи существует.

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