Автор Тема: Идеальный ЯП  (Прочитано 40975 раз)

DIzer

  • Гость
Re:Идеальный ЯП
« Ответ #30 : Март 01, 2011, 04:26:09 pm »
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
Вот-вот.
Осталось только сделать для него возможность менять синтаксис так, как будет удобно для решаемой задачи, не теряя при этом возможности удобной манипуляций с AST...
 Но много систем довольно удобно описываются с помощью сущностей которые я привел выше... о (они взяты ведь не из балды - чисто формальный анализ сущностей возникающих при анализе понятия и свойств алгоритма )
« Последнее редактирование: Март 01, 2011, 04:29:45 pm от DIzer »

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Идеальный ЯП
« Ответ #31 : Март 02, 2011, 03:27:37 pm »
Осталось только сделать для него возможность менять синтаксис так, как будет удобно для решаемой задачи, не теряя при этом возможности удобной манипуляций с AST...

И каждый начнёт громоздить свою нотацию. И каждому надо будет разбираться и привыкать к чужой.

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

И так сейчас каждый самоделкин изобретает свой скриптовый язычок. С которым потом мучаться другим. Дать орудие "комбинаторного клепания" - будет опять такая лавина... изобретательства... И опять "тормоз прогресса" - вместо тенденции к унификации компонентов инженерного процесса будет очередной взрыв "кустарной раздробленности".

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

Peter Almazov

  • Sr. Member
  • ****
  • Сообщений: 482
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #32 : Март 02, 2011, 03:42:39 pm »
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
Так под каждую задачу/систему (или класс задач) и так пишется свой DSL, с помощью штатных средств языка программирования. В этом сущность программирования.
Маниакальное желание менять синтаксис языка мне тоже непонятно.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #33 : Март 02, 2011, 05:44:41 pm »
И каждый начнёт громоздить свою нотацию. И каждому надо будет разбираться и привыкать к чужой.
Естественно, ведь идеала нет, а значит нет и удобной для всех нотации.

Если над проектом работает одиночка или тесная команда единомышленников, то проблемы с таким разнообразием не будет -- договорятся в конце концов.
Ну а если проект большой, то внутрифирменный стандарт будет установлен начальством.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #34 : Март 05, 2011, 05:18:04 am »
Хочу поделиться с записями, сделанными на начало прошлого года и содержащими идеи на тему, какими фичами должен обладать ЯП, условно приближенный к идеальному.
-) Все входные аргументы подпрограмм подлежат обязательной проверке assert-подобным выражением.

Чем это принципиально отличается от просто ASSERT'ов? Ну или если не принципиально, то чем это сильно удобнее, чтобы быть в языке в качестве сахара?

-) Именованные параметры.
При вызове подпрограммы должны указываться пары: имя параметра ":" значение.

Можно показать, какие проблемы решает подобный экстримизм?

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

Это частный случай параметров по умолчанию, если в языке есть OPTIONAL (а он должен быть, если вы хотите optional поля).

-) Обязательное присвоение значений переменным при объявлении с необязательной охраной.

Аналогично - непонятно чем не устраивает ASSERT.

-) Соглашения.

Аналогично - непонятно чем не устраивает обычная функция с ASSERT'ом.

Валерий Лаптев

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #35 : Март 06, 2011, 04:32:07 am »
Ключевое слово - "обязательный". То же самое, что Ткачев для отступов попросил сделать: обязательные. Иначе - ошибка трансляции.
Простой assert можно просто полениться написать. Особенно, если чел не очень опытный... А обязательный - не пропустишь никак... :)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #36 : Март 06, 2011, 05:29:38 am »
Ключевое слово - "обязательный". То же самое, что Ткачев для отступов попросил сделать: обязательные. Иначе - ошибка трансляции.
Простой assert можно просто полениться написать. Особенно, если чел не очень опытный... А обязательный - не пропустишь никак... :)

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

Peter Almazov

  • Sr. Member
  • ****
  • Сообщений: 482
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #37 : Март 11, 2011, 08:43:03 am »
Ключевые слова в верхнем регистре (убежден, что это следствие возрастной дальнозоркости Вирта) народу не нравятся. А кто как видит синтаксис идеального ЯП? На что он должен быть похож, уж наверно не на С. На Аду?
Я, хоть и не люблю сишный синтаксис, открыл в нем и положительные стороны, когда разбирался с этим плагином: http://forum.oberoncore.ru/viewtopic.php?p=51289#p51289
Сильно упрощается разбор текста программы: все, что между { } выделяется скобкой. Сюда, кроме всего  прочего относятся секции инициализации и лямбда-выражения.
Какие кому нравятся  альтенативы, скажем, для лямбда-выражений?

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #38 : Март 11, 2011, 03:16:15 pm »
Ключевые слова в верхнем регистре (убежден, что это следствие возрастной дальнозоркости Вирта) народу не нравятся. А кто как видит синтаксис идеального ЯП? На что он должен быть похож, уж наверно не на С. На Аду?

На питон. Однозначно :) Ну допилить, может, немного... Тут еще про хаскель говорили, но по мне - он ближе к птичьему :) Хотя привычка, конечно, сильно влияет. А вот питоновский синтаксис - и без привычки нормально смотрится :)

P.S. Кстати, по поводу капса в обероне. Тут вот от Алексея пробегала интересная ссылка: http://www.ethistory.ethz.ch/rueckblicke/departemente/dinfk/bilder/1981_lilith-windows_EN.jpg?hires

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #39 : Март 11, 2011, 03:40:43 pm »
Ключевые слова в верхнем регистре (убежден, что это следствие возрастной дальнозоркости Вирта) народу не нравятся. А кто как видит синтаксис идеального ЯП? На что он должен быть похож, уж наверно не на С. На Аду?
Мне очень нравится Ада и стиль кодирования там принятый. В частности там не принято в VAR-секции лепить пачку разнотипных переменных в одну строку, как например это бывает в исходниках ББ:
VAR c: TextControllers.Controller; r: TextModels.Reader; beg, end, i: INTEGER; stat: ARRAY 1024 OF CHAR;
Вообще там не принято в одну строчку много всего лепить. Ну и исходники читабельны, да.

Питон… Не знаю. Может быть и да, может быть и нет. Нужно смотреть. Вообще мне представляется, что например присваивание не должно быть таким:
a := bили таким:
a = bмне таки кажется, что оно должно быть таким:
a ← bТехническая возможность сейчас для этого есть.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Идеальный ЯП
« Ответ #40 : Март 11, 2011, 03:53:55 pm »
Не забывайте, что большая часть исходников ББ создавалась в первой половине 90-х.
На те мониторы хотелось вместить побольше строчек на экран. И VAR-ами вполне разумно было жертвовать.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #41 : Март 11, 2011, 04:02:48 pm »
Я таки заметил что число строчек кода на мониторе у меня не зависит практически от монитора. Как и лет 15 назад у меня на мониторе порядка 40-50 строк кода. При этом что сейчас монитор 19", а был когда-то 14".

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

Сергей Прохоренко

  • Newbie
  • *
  • Сообщений: 16
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #42 : Март 11, 2011, 05:52:24 pm »
Вообще мне представляется, что например присваивание ... должно быть таким:
a ← bТехническая возможность сейчас для этого есть.

А мне представляется иначе: https://sites.google.com/site/purebuilder/#TOC-24

Валерий Лаптев

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #43 : Март 17, 2011, 05:26:04 am »
Присваивание слева-направо - это естественная математическая запись y = f(x)

igor

  • Sr. Member
  • ****
  • Сообщений: 438
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #44 : Март 17, 2011, 07:16:08 am »
Присваивание слева-направо - это естественная математическая запись y = f(x)
В математике запись y = f(x) -- это не присваивание.
Доказательство: y = f(x) равносильно f(x) = y.
Если хотите со мной поспорить, то включите в список своих оппонентов и Никлауса Вирта  ;) (см. статью "Хорошие идеи, взгляд из зазеркалья")