На что вы хотите обратить внимание языковых дизайнеров? [закрыто]

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

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

Пожалуйста, не пишите:

• Синтаксис пламенных войн. Посмотрим правде в глаза, у нас есть свои предпочтения, и синтаксис важен, поскольку он относится к языковому дизайну. Я просто хочу избежать эпических битв о природе emacs vs. VI (о которых сегодня многие ничего не знают).
• «Любой язык, у которого нет функции X, не заслуживает того, чтобы существовать», напишите комментарии. Существует как минимум одна причина существования всех языков программирования - хорошая или плохая.

Пожалуйста, сделайте пост:

• Философские идеи, которые языковые дизайнеры, похоже, упускают.
• Технические концепции, которые кажутся плохо реализованными чаще, чем нет. Пожалуйста, приведите пример боли, которую это вызывает, и если у вас есть идеи о том, как вы бы предпочли, чтобы он функционировал.
• Вещи, которые вы хотите, были в общей библиотеке платформы, но редко бывают. Один и тот же знак, вещи, которые обычно находятся в общей библиотеке, чего вы не хотели.
• Концептуальные функции, такие как встроенная поддержка тестирования / утверждения / контракта / обработки ошибок, которые вы хотите, чтобы все языки программирования реализовывали должным образом - и определяли правильно.

Я надеюсь, что это будет веселая и стимулирующая тема.

Изменить: Уточнил, что я имею в виду под синтаксисом Flame Wars. Я не пытаюсь избегать всех обсуждений синтаксиса, особенно потому, что синтаксис является фундаментальной частью дизайна языка программы.

Поддержка Unicode по умолчанию

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

У меня есть пара

• Generics / шаблоны. Например, дженерики Java являются мощными, но не обязательно гибкими. Кроме того, поскольку они используют стирание типов, я видел проблемы с их абстрактной реализацией, особенно в интерфейсах. И компилятор не должен предупреждать, когда используется неспецифический универсальный (например, Hashmapвместо Hashmap<String, int>). Я думаю, что они могут быть значительно улучшены. Хорошие шаблоны очень полезны, но часто ими пренебрегают.

• Хорошая дата поддержки в стандартной библиотеке. Я имею в виду возможность складывать и вычитать даты, часы и минуты и не иметь дело с количеством миллисекунд с 1 января 1970 года.

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

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

Когда выйдет новая версия языка или базовых библиотек, вещи, которые ранее были безопасными, могут перестать быть:

1. библиотеки могут стать более мощными: например, библиотека URL теперь поддерживает javascript:
2. могут быть новые способы преобразования строк или байтов в код: например, evalбиблиотеки десериализации
3. методы отражения языка могут стать более мощными: например, экспонирование локальных переменных

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

Поэтому, пожалуйста, подумайте о нас при разработке и создании версий языка. Ниже приведены несколько советов:

Определите несколько примитивов, на которые программа может быть разложена.

HTML5 особенно плох в этом смысле. Они, очевидно, много думают о безопасности и имеют очень умных людей, но вместо того, чтобы указывать новые элементы программы, например, <video>в терминах старых, или создавать общую абстракцию, в которой новые <video>и старые <img>оба могут быть указаны в терминах, <video>еще нет. еще один одноразовый элемент программы со своими собственными последствиями для безопасности.

Сделайте свой язык пригодным для статического анализа (даже если он не статически типизирован).

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

Должно быть очевидно, какие идентификаторы являются локальными переменными, а какие нет.

Например, не делайте ту же ошибку, что и в старых версиях JavaScript, из-за чего невозможно определить, xявляется ли ссылка на локальную переменную ниже (согласно буквальному прочтению старой версии спецификации):

if (Math.random() > 0.5) {
  Object.prototype.x = 0;
}

function f() {
  var x = 1;
  (function () {
    alert(x);  // Might alert 0, might alert 1.
  })();
}

Разрешить для разложимой безопасности

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

Должно быть возможно написать такое ядро ​​на вашем языке. Если одно из свойств безопасности вашего языка, это то, что когда-либо будет выбрано только определенное подмножество URL, могут ли разработчики ядра сделать что-то, чтобы направить всю выборку URL через их код? Или статические проверки сборки (например, просмотр импорта) могут выполнять ту же функцию.

Некоторые языки, такие как Newspeak, используют модель возможностей объекта. Это потрясающий и отличный способ получить разложимую безопасность.

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

Ограничить авторитет встроенных скриптовых языков

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

А встраивание языков сценариев может сделать систему намного более расширяемой.

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

Если вы решите разрешить встроенные языки сценариев, сделайте так, чтобы вызывающий мог ограничить свои возможности. Модель объектных возможностей (см. Комментарий к Newspeak выше) очень уместна здесь; поэтому при оценке кода на языке сценариев вызывающая сторона должна передать код для выполнения и все глобальные переменные для этого кода.

Рассматривать evalкак язык, внедряющий себя как язык сценариев

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

Используйте простую модель параллелизма

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

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

Одним из простых является параллелизм цикла событий, подобный тому, который есть в E, Verilog и JavaScript.

Не поощряйте цитирование путаницы

Некоторые языки - это склеенные языки, и они заканчивают тем, что имеют дело со строками на многих разных языках.

Например, JavaScript часто состоит из строк HTML, CSS, XML, JSON и даже JavaScript. Программистам очень трудно помнить, как правильно кодировать строки простого текста при их объединении в строки на других языках, поэтому неудивительно, что в программах JS возникают проблемы с запутыванием в кавычках: XSS - наихудший вариант.

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

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

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

Только 5-10% времени тратится на написание кода. Разработчики языка должны обращать внимание на трудности фактической работы программного обеспечения, что означает исправление ошибок и ошибок.

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

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

Что касается философских идей, которые актуальны там, это самые важные из дзен питона:

• Явное лучше, чем неявное.
• Читаемость имеет значение.
• Особые случаи не достаточно особенные, чтобы нарушать правила.
• Хотя практичность превосходит чистоту.
• Должен быть один - и желательно только один - очевидный способ сделать это.
• Если реализацию сложно объяснить, это плохая идея.
• Пространства имен - одна из отличных идей - давайте сделаем больше!

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

Единственная техническая особенность, которую я пропускаю в Python, - это оператор "before" (например, while, но не тестирующий выражение в первый раз). Кроме того, в стандартных библиотеках Python и других языков есть много вещей, которые можно улучшить, но это не только языки , так что это другой вопрос. :-)

Возможность изменить язык в соответствии с вашими потребностями очень важна для меня. Для Lisp это делается с помощью макросов, для Tcl с повышением уровня. В меньшей степени Ruby использует лямбды и тому подобное. Я просто хочу иметь возможность добавлять новые структуры управления, которые удовлетворяют данной проблеме, а не формировать мои проблемы вокруг доступных структур управления. В качестве простого примера, конструкция «do .. then», которая существует в некоторых языках, но не в другом, является более чистым способом обработки некоторых случаев, чем «while», возможность добавления новых структур для удовлетворения других случаев чрезвычайно полезна.

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

Самое главное, что ваш язык должен иметь «стиль». Например, я бы назвал C языком системного программирования на основе указателей. Я бы назвал Erlang высококонкурентным функциональным языком программирования. Некоторые другие языки (такие как C ++ и, возможно, Java) - это то, что Аллан Кей назвал «агглютинативными» языками: языки Франкенштейна состояли из множества связанных функций.

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

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

Спасибо за отличный вопрос. Вы получаете довольно хорошие ответы.

Не для того, чтобы застеклить глаза, но я смотрю на программиста как на информационный канал. Идеи / концепции / требования идут с одной стороны, а код - с другой.

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

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

Позвольте мне привести пример того, что я имею в виду. Что касается проблемы создания гибких диалоговых пользовательских интерфейсов, этот метод исключает необходимость писать обработчики событий, перемещение данных, большинство вещей, обычно выполняемых в пользовательском интерфейсе. Это также приводит к уменьшению исходного кода примерно на порядок. Мета-язык - это всего лишь несколько подпрограмм и макросов в C / C ++ / Lisp, и я также сделал это на языках без макросов.

Если выполнение требования может быть выполнено с 5-точечными правками в коде или с 10-ю, выполнение с 5-ю не только меньше кода, но и меньше шансов пропустить шаг и привести к ошибке. Таким образом, чем более специфичен домен для конкретного языка, тем меньше код, тем легче его обслуживать и тем более нет ошибок. Я думаю, что мы должны знать, как двигаться к этому. Это не означает, что код более читабелен, если только читатель не вложил средства в обучение, чтобы понять технику.

Ограниченные и различные целочисленные типы, такие как Паскаль и Ада. Честно говоря: как часто вам нужен полный диапазон любого целого числа? Я думаю, что в примитивных типах многое нужно улучшить, чтобы лучше представлять реальный мир.

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

Соглашения об именах (я смотрю на вас PHP)

Первоклассная интеграция со средами разработки.

В настоящее время кодирование выполняется в богатой среде. Для HTML / CSS / JS у нас есть Firebug и другие интерактивные инструменты. Для Java, Eclipse и IDEA и других истинных IDE. И так далее. Есть экология инструментов, начиная с редактора, но не заканчивая там:

• Организация кода внутри и между файлами
• Умное выделение
• Интеллектуальное завершение / интеллектуальная типизация
• Статическая отладка (пометка синтаксических, семантических и стилистических ошибок)
• Создание и использование шаблонов и макросов
• Контроль версий (управление версиями, слияние, ветвление, ...)
• Распределенная разработка с несколькими авторами (комментарии, встроенный документ, аннотации, ...)
• Отладка во время выполнения (трассировка стека, степпинг, часы, ...)
• Интерактивная «живая» отладка (например, Firebug - редактирование поведения живой системы)
• ... Я даже не знаю, что дальше.

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

Но в основном это взломанные вещи, например, использование $ Id $ в комментарии, чтобы источник, контролируемый CVS, мог содержать номер версии. Почему я не могу сделать что-то подобное из самого языка?

Распределенные вычисления

Бесплатный обед окончен. Сегодня нужны программы, которые работают на нескольких ядрах / нескольких процессорах (и в особых случаях на нескольких компьютерах).

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

Использование C ++ 0x в будущем , безусловно, интересно, несмотря на то, что оно представлено в виде библиотеки и не освобождает вас от актуальных проблем синхронизации (вы знаете, те, которые так просто решить ...)

Мне действительно нравится подход Go к этой проблеме: многопоточность встроена, а выбранный подход (каналы и программы) устанавливает гораздо более простое мышление, чем традиционные подходы семафор / мьютекс / блокировка. Хотя по-прежнему легко получить доступ к несинхронизированной структуре одновременно (в Go есть указатели) или к тупику (цикл ожидания на каналах ...)

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

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

Считай меня сумасшедшим, но одной из самых важных языковых возможностей для меня является наличие хорошего онлайн-справочника вместе с примерами. Я знаю, что могу найти хорошие результаты поиска для любого языка, но мне действительно нравится сайт API-интерфейсов MSDN и Java. Они значительно облегчают программирование для человека, который не имеет большого опыта работы с конкретным языком.

Больше возможностей помочь компилятору проверить ваш код.

Будучи программистом встраиваемых систем, я всегда использую C. Но мне всегда хотелось бы иметь больше / лучше способов сообщить компилятору, чего я ожидаю от своего кода, чтобы он мог это проверить.

Например, я могу иметь функцию

f(int x)

но я бы предпочел

f(int range[-5..25] x)

Например, я хотел бы иметь возможность писать утверждения о функциях, используя какой-то функциональный язык более высокого уровня, такой как Lisp или Haskell. Они не будут скомпилированы в код, но могут быть использованы для статического или динамического анализа.

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

Худший пример - Ада:

procedure Hello is
begin
  Put_Line("Hello World!");
end Hello;

Заполняющие слова как is, as, ... не имеют смысла для языков программирования.

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

Для меня Haskell - отличный пример того, что я имею в виду под «изучением языка» (хотя с годами его популярность и общая полезность также выросли). Отказ от привычного синтаксиса C и наличие обратных операторов композиции функций (например,(+2) . (*3) , это функция, которая умножает на 3, а затем добавляет 2), Haskell научил меня писать более короткие функции. Его беспощадная проверка типов помогла мне быстрее выучить язык и улучшила мою способность логически мыслить код. Оба эти преимущества распространяются на другие языки, даже на ассемблер.

Цели изучения языков и целей языков общего назначения часто противоречат друг другу. Изучаемый язык должен быть сложным и полезным для изучения и должен обеспечивать соблюдение определенного стиля, даже если этот стиль не является лучшим для многих приложений. Язык общего назначения должен быть хорош для выполнения работы, а использование абстракций должно быть тщательно измерено и «иметь смысл». Например, при исправлении сайта, узнав о монад было бы последним в голове программиста. С другой стороны, когда кто-то учится программировать, ему не нужно разбираться в бессмысленной чепухе, если он еще даже не узнал о функциях.

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

Так как мы в 2011 году,

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

• поддержка многопоточности; не только функции синхронизации (блокировки), но и языковые функции, которые делают многопоточность такой же простой, как написание цикла:

  все (o в myCollection) {o.someMethod ()}

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

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

Облегченные процессы

Я хотел бы иметь легкие процессы, как в Erlang. Это в основном проблема для времени выполнения. Это отсутствует в JVM и .NET CLR. LWP помогает создавать массово параллельное программное обеспечение. В идеале создание процесса не должно быть более дорогостоящим, как создание объекта на языке. Я хотел бы создать миллионы процессов в моих приложениях.

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

Поддержка хвостовой рекурсии

Я хотел бы получить поддержку хвостовой рекурсии. Это также может быть проблемой для среды выполнения. Например, JVM не поддерживает хвостовую рекурсию.

Простое распределенное программирование

Я хотел бы иметь поддержку для отправки ( ! ) И получения примитивов к частям приложения, работающим на других машинах с тем же сетевым словом, что и в Erlang. Это позволяет легко создавать масштабируемые приложения, например распределенные хранилища данных. Добавленная к этому встроенная в язык сериализация также очень полезна, как и в erlang. И не так, как на Java, я должен делать это вручную.

Облегчить метапрограммирование.

ограничить специальные формы

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

У нас действительно нужно for, foreach,while и т.п. каждый в своей особой форме. Как насчет одной циклической конструкции и некоторых макросов по умолчанию, чтобы обеспечить синтаксический сахар вариантов циклических форм.

метапрограммирование для специальных форм

form['if'](test-fn, body-fn)

Сетевые возможности

Язык, который поставляется без какой-либо сетевой поддержки, в современном мире довольно слабый.

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

• автоматическое обновление
• доступ к базе данных
• WebServices

Это также краеугольный камень поддержки распределенных / облачных вычислений.

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

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

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

Я понимаю, что иногда синтаксис языка должен мешать работать лучше на этапе компиляции / интерпретации, но иногда я чувствую, что разработчик языка передает эту работу разработчику. Например, многострочные строки в Java или Javascript.

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

• читабельность : чем меньше / меньше символов в грамматике, тем чище и лучше.
• Объектно-ориентированные типы : методы, а не функции.
• Понятность : встроенные беглые интерфейсы, полные и краткие имена для библиотечных классов / интерфейсов и их разновидностей.

Добавление функции в существующий язык программирования. Итак, новый язык B - это старый язык A с функцией X.

Существующие примеры:

1. C добавление классов => C ++
2. Java добавляет некоторые вещи => C #

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

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

Обновление: отправляю ссылку на такой язык LabView

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