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

38

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

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

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

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

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

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

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

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

Берин Лорич
источник
Сказать, что синтаксис - это просто деталь реализации, просто неправильно. Синтаксический дизайн является фундаментально важной частью проектирования языка. И многие из пунктов , которые вы действительно хотите , чтобы увидеть размещены на самом деле может включать в себя синтаксис. Жалость. Похоже, интересный вопрос.
Конрад Рудольф
Чего я хочу избежать - это пламенной войны. Если вы можете обсуждать синтаксис без начала пламенной войны, сделайте это.
Берин Лорич

Ответы:

49

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

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

Malfist
источник
2
+1 Фактически, сам язык должен позволять вам использовать любой символ для ваших идентификаторов. Мы не все англичане.
Берин Лорич
13
@ Берин: На ​​самом деле, хотя я и француз, я предпочитаю программы на английском языке. Проблема заключается в общении: если вы пишете программы с венгерскими, испанскими или португальскими идентификаторами, не ожидайте, что я когда-нибудь смогу в них вмешаться ... в контексте интернационализации чрезвычайно важно, чтобы разработчики могли общаться между собой и это подразумевает использование общего языка для идентификаторов, комментариев и документации. Английский является языком общения разработчиков.
Матье М.
11
Я бы добавил, что поддержка юникода должна быть естественной при использовании языка. Если возможно, не нужно предпринимать никаких дополнительных усилий, чтобы «добавить его», оно должно «просто работать» (где это разумно).
RHSeeger
4
Соответственно, язык должен проводить фундаментальное различие между текстовыми (последовательность символов) и двоичными (последовательность байтов) данными. C # получает это право с stringи byte[]. Как и Python 3.x с strи bytes. C (++) charделает это ужасно неправильно.
Ден04
1
@RHSeeger - действительно !!! Даже в Python вы должны печатать u'My Unicode Štring'. Я хотел бы, чтобы вы могли просто забыть, с каким типом строки вы имеете дело, и чертовски написать код.
orokusaki
25

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

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

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

Michael K
источник
2
«Хорошая поддержка свиданий» - довольно крутое требование! что это вообще значит? Я думаю, что даты и время - одна из тех вещей, где вы не можете получить все это хорошо. либо вы делаете это простым и неправильным, либо вы делаете это правильным и нечестиво сложным. ДЕЙСТВИТЕЛЬНО трудно достичь хорошего среднего уровня.
Сара
@kai Дело в том, что поддержка дат обычно довольно ужасна. У старого java.util.Dateесть почти все возможные ошибки и проблемы. Я знаю только часть нового java.time.*пакета, но он чистый, простой в использовании и без ошибок. Более продвинутые пользователи могут найти проблемы, но это огромное улучшение. +++ Проблема, кажется, в том, что это сложная проблема, и первая версия сорвана и сломана.
Maaartinus
24

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

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

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

  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, гигиенические макросы и встроенные языки шаблонов могут быть отличным способом сделать это, перенеся бремя правильного перехода на библиотеку или разработчиков языка и от конечного разработчика.

Майк Самуэль
источник
Красивый срыв.
Qix
23

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

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

оборота dan_waterworth
источник
4
Это может быть правдой в определенной степени. Однако, если вы никогда не слушаете своих пользователей, вы никогда не узнаете боль, которую вы им причиняете, когда они пытаются использовать ваш мозг ребенка. Не слыша / не чувствуя этой боли, вы никогда не придете к следующей великой идее, которая решает эту проблему и другие. Ни один человек не остров. Боль может быть отличным мотиватором для инноваций.
Берин Лорич
5
@ Берин: я не думаю, что дело в том, что вы никогда не должны слушать своих пользователей, но не слушайте пользователей, которые хотят использовать язык для чего-то, для чего он не предназначен. Если вы разработали язык для решения определенного набора или проблем, то вам следует ориентироваться на пользователей, которые также должны решать эти проблемы. Тем не менее, вы обращаетесь к крайностям, и иногда язык может найти свою нишу в новом домене, так что +1.
Джереми Хейлер
2
@ Джереми, да, это именно то, что я говорю, но я думаю, что язык не очень хорошо работает в области, для которой он не предназначен.
dan_waterworth
@dan_waterworth: Успешные языки обычно работают, часто хорошо, в областях, для которых они не предназначены.
Дэвид Торнли
8
Вместо «не слушайте пользователей» совет лучше сформулировать как «не слушайте пользователей, которых у вас нет».
Chrisaycock
16

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

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

как зовут
источник
2
+1. Отладка - это одно из мест, где некоторые языки лучше, чем другие, и некоторые IDE имеют все значение между используемым языком и тем, который мешает вам.
Берин Лорич
2
Я добавлю немного к этому и скажу, где это возможно, полезные следы стека. Если есть ошибка (или неперехваченное исключение или что-то еще, в зависимости от вашего языка), я хочу иметь возможность просматривать весь стек вызовов, который к нему поступил, а также значения используемых аргументов. Tcl делает это исключительно хорошо ... но, честно говоря, в Tcl все является строкой, так что вы можете вывести значение всего с относительной легкостью.
RHSeeger
1
Не просто отладка, а затруднение написания ошибок. Я был так счастлив, когда Java ввел автоматическую проверку границ для массивов ... но вот мы, 15 лет спустя, все еще делаем эти ошибки на других языках.
Алекс Фейнман
3
Не лучше ли иметь язык, который находит ошибки во время компиляции? Например, когда я использую Ada, я трачу значительно меньше времени в отладчике, чем когда я использую C или C ++.
Мартин
12

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

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

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

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

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

Леннарт Регебро
источник
4
Я считаю две другие вещи более важными, особенно на уровне разработки языка: «Особые случаи не настолько особенные, чтобы нарушать правила». потому что язык с тысячью особых случаев или тайных правил трудно использовать в сочетании с «Хотя практичность побеждает чистоту». потому что в противном случае вы дрейфуете в царство тьюпингов.
15
Если явный лучше, чем неявный, то почему вы не обязаны объявлять переменные? Когда простая опечатка может привести к трудным для отладки ошибкам (в отличие от ошибок, которые обнаруживаются во время компиляции, или ошибок времени выполнения, которые очевидны и легко отлаживаются), это является серьезным ударом по языку IMO.
Мейсон Уилер
4
@ Мейсон Уилер: Единственная причина, по которой вы должны объявлять переменные в других языках, это то, что вы должны указывать, какой тип они. Python является динамическим, поэтому объявление типа не требуется, и поэтому объявление не требуется. Я не понимаю, как это связано с неявным / явным. Типы в Python явные. Как и переменные. После десяти лет опечатка никогда не вызывала трудной ошибки отладки. На самом деле они тривиальны для отладки.
Леннарт Регебро
8
+1 для списка, -1 для фаната. Уделение внимания всем языкам, которые достигли значительного успеха, и попытка включить или хотя бы проанализировать применимость этих элементов кажется более прагматичным подходом.
Стивен Эверс
3
@ Леннарт: Я бы сказал, что хорошо (но не обязательно, см. Правило 4) явно указывать типы функций - это хорошо. Это похоже на дизайн по контракту. Это то, что я хочу сделать.
Тео Белер
11

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

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

RHSeeger
источник
Интересный. Хорошая поддержка метапрограммирования может быть трудной, но очень мощной. Я слышал от людей, которым нравится Lisp, что реализация Lisp - одна из лучших, но они говорят это обо всем в Lisp. Какие-нибудь примеры того, что вы думаете, метапрограммирование сделано правильно?
Берин Лорич
«Метапрограммирование сделано правильно» должно быть там, где просто делать правильно (ну, для разумной простой деятельности) и где конечный результат ощущается как естественная часть языка.
Донал Феллоуз
1
Не просто модифицируемая, но дешифруемая модификация. Если вы переназначили что-то на языке, я, как читатель, смогу быстро это выяснить. Аннотации или другие внешние маркеры могут помочь с этим.
Алекс Фейнман
Я думаю, что Mata-Lua или Template Haskell хорошо справляются с этой задачей. (Не так хорошо, как макросы Scheme, но это то, что вы платите за использование больше, чем паренов в языке)
Тео Белер
10

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

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

  1. Докажите, что это действительно необходимо.
  2. Докажите, что это не может быть сделано в библиотеке.
  3. Докажите, что оно принадлежит языку.
Джейсон Бейкер
источник
2
Другими словами, язык должен иметь один общий принцип проектирования, и язык должен соответствовать этому принципу. Комментарии об эволюции языка являются оправданными (я видел, что это испортилось несколько раз).
Берин Лорич
1
Напоминает мне мою любимую цитату C ++ ... Осьминог, сделанный, прибивая дополнительные ноги на собаку.
ocodo
4
Докажите, что это не может быть сделано в библиотеке . +1
Qix
2
Мне нравится библиотека Tidbit. Здорово, что в таких языках, как haskell, нет встроенных элементов управления потоками, таких как циклы, исключения или продолжения. их просто очень просто определить в языке, поддерживая синтаксис в чистоте и способствуя расширению и компоновке, создавая множество умных функций языка.
Сара
10

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

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

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

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

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

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

оборота Майк Данлавей
источник
9

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

Мартин
источник
2
Ограниченные целочисленные типы ala C, C ++, D, Java, C # и т. Д. Наверняка найдут свое место. Некоторые типы программирования не заботятся и просто нуждаются только в различении целого числа и числа с плавающей запятой. Даже тогда, может быть, нам просто нужен числовой тип и мы будем беспокоиться о его неотъемлемой части? Короче говоря, бизнес-программирование менее чувствительно к конкретному целочисленному типу, чем к факту, что число является целым числом. Когда вы внедряете протокол на низком уровне, правила резко меняются.
Берин Лорич
2
То, что я подумал, где, например, в Аде, где вы можете просто сказать type Date_Of_Month is 1 .. 31;и оставить решения, как 16 или 32 бит, оптимизатору. Но что еще более важно, присвоение 32 или 0 или -5 переменной типа дает вам RANGE_ERROR.
Мартин
Диапазоны хорошо работают для таких вещей, как Date_Of_Month(или Month_Of_Year), где есть очевидный диапазон для использования, но многие - вероятно, большинство - случаи нечеткие. type Persons_Age is 0..120? Что если кто-то побьет рекорд долголетия? type Year is 0..9999? Что делать, если вы египтолог?
Ден04
Если вы египтолог, вам не нужны type Egyptian_Year is -9999 .. 300;. По моему опыту вы можете найти полезные границы для целых чисел большую часть времени. В этом отношении вы должны учитывать, что type Scrolls_Found is array Egyptian_Year of Natural;вы не можете / не должны иметь неограниченный тип в качестве индекса массива. Это просто вектор атаки для хакера. Кстати: Ada позволяет рассчитывать границы диапазона во время выполнения.
Мартин
1
@kai никто не сказал, что эта особенность систем типов должна использоваться везде без исключений. Я уверен, что Ада также позволяет использовать «обычные» числовые типы. И ограниченные числовые типы, безусловно, полезны для некоторых (довольно распространенных) проблем.
Сардж Борщ
8

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

Ларри Коулман
источник
8

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

Malfist
источник
Меньше проблем с языковым дизайном. Конечно, вы всегда должны следить за тем, что входит в стандартную библиотеку, но разработчики языка не могут применять соглашения об именах;)
3
Вы можете для стандартной библиотеки.
Malfist
3
Даже не упоминайте PHP. Худший обычно используемый язык вокруг. Не созданный программистом, просто парень, который хотел шаблоны и стероиды были добавлены.
Keyo
@delnan: некоторые языки, такие как Mercury или Eiffel, налагают соглашения об именах (все имена заглавных классов, переменные, начинающиеся с заглавной буквы и т. д.), и они применяются компилятором. Фортран сказал, что переменные, начинающиеся с i, j, k, являются целочисленными (отсюда традиционное использование в качестве переменных цикла в большинстве языков ...). И так далее. Как-то раздражает, если вам не нравится соглашение, но хорошо для согласованности исходных кодов, по крайней мере.
PhiLho
@PhiLho: Это очень ограничено, хотя. Он не может навязать - только один пример - последовательное, значимое (для читателей-людей) использование заглавных букв или подчеркиваний (он мог бы попытаться, но рискнул бы здравомыслием программистов в процессе).
7

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

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

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

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

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

Алекс Фейнман
источник
Вы имеете в виду что-то вроде ASIS (ISO / IEC 15291: 1999 «Спецификация интерфейса семантики Ada»)? ASIS не охватывает все, что вы хотите, но довольно много. Я часто хотел что-то вроде ASIS для других языков программирования. См. Sigada.org/wg/asiswg для деталей.
Мартин
Некоторые из этих вещей относительно дешевы или бесплатны в вашей среде IDE: организация кода, подсветка синтаксиса, свертывание кода, контроль версий, шаблоны / макросы. Другие требуют гораздо больше усилий: отладка во время выполнения, статическая отладка, интеллектуальное завершение / предиктивная типизация, рефакторинг и т. Д. Несмотря на то, что проектирование согласованного языка часто игнорируется, гораздо сложнее, когда вам также приходится беспокоиться о плагинах IDE.
Берин Лорич
6

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

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

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

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

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

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

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

Матье М.
источник
Другим примером был бы Эрланг. Общая тема среди языков такого рода - это общий подход « ничего» , когда состояние по существу передается вместе с сообщением. Подход хорошо масштабируется.
Берин Лорич
@Berin: Вы правы, хотя я не процитировал Эрланга в сообщении, потому что мало что знаю, насколько я помню, он правильно реализует модель актера.
Матье М.
6

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

apoorv020
источник
JavaDoc, CppDoc, RubyDoc и т. Д. Были очень полезны для понимания стандартных библиотек, а также библиотек, которые вы создаете. Они не все созданы равными, и некоторые легче ориентироваться, чем другие.
Берин Лорич
Согласен, сайт Java API - отличный ресурс. Хорошо иметь стандартный формат для создания документации по API. Повышение производительности от использования IDE со встроенной поддержкой анализа JavaDoc (netbeans) поразительно. Хотя у меня ужасная память, так что, вероятно, она приносит мне больше пользы, чем другие.
toc777
6

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

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

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

f(int x)

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

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

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

Rocketmagnet
источник
По сути эффективный способ проверки границ? Это было бы довольно круто. Хотя, по крайней мере, я бы хотел, чтобы это было включено для проверки времени выполнения, а также проверки времени компиляции. Когда вы извлекаете информацию из базы данных или из пользовательского интерфейса, вы всегда гарантируете, что значение будет действительным. Если бы это была языковая функция, я бы хотел использовать ее и для этих целей.
Берин Лорич
3
Вы должны использовать Паскаль. Вы можете определить тип, который охватывает произвольный диапазон чисел, например -5..25, который компилятор может проверить во время компиляции. (Конечно, если вы только назначаете константы.)
Мейсон Уилер
1
@ Кугель: Что еще, кроме функции компилятора, утверждать? И модульный тест не будет проверять код в производстве. А не проверять производство - все равно что снимать живые лодки после первого рейса. Чтобы сэкономить топливо и сделать корабль быстрее.
Мартин
1
Я бы использовал Ada, за исключением того, что платформа, на которой я работаю, не имеет компилятора Ada. У него есть только компилятор C, так что в любом случае это все академично.
Ракетный магнит
1
Я уже использую множество утверждений, но было бы еще лучше, если бы это и другие вещи использовались в качестве языковых функций.
Ракетный магнит
5

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

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

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

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

Brainlag
источник
4
Я думаю, что худшим примером являются языки, на которых вы говорите public static void.
Джои Адамс
1
Идея не нова и уже реализована в форме SmallTalk, в которой вообще нет ключевых слов. Таким образом, вы должны были использовать SmallTalk в качестве положительного примера для вашей заявки. КСТАТИ: Если вы не знаете, для чего ISэто, то вы не понимаете Ada (вы когда-нибудь программировали Ada?): ISОтделяет объявление процедуры от объявления локальных переменных, а также отличает спецификацию от реализации. Конечно, вы могли бы заметить только при сравнении спецификации и реализации функции, чтобы увидеть, что она ISимеет смысл и не является наполнителем вообще.
Мартин
1
Забыл упомянуть: синтаксис SmallTalk также подходит к обратной стороне открытки. Так что это также выполнит ваше стремление к «малости». Конечно, большинство идей здесь уже реализованы где-то на каком-то языке, и большинство авторов здесь используют эти языки в качестве положительного примера вместо того, чтобы создавать ошибочный отрицательный пример. Я бы проголосовал за тебя, если бы у меня была достаточно репутации. Не потому, что ваша идея плохая - но для использования отрицательного примера.
Мартин
7
Слова-заполнители могут на самом деле служить цели, если они помогают устранить неоднозначность синтаксиса. Например, я предпочитаю , if x then …чтобы if (x) …. Мы обменяли пару скобок на контекстное ключевое слово. Это имеет смысл, потому что условие xможет быть сложным выражением со своими собственными скобками. Исключение самой внешней пары может значительно улучшить читаемость. Альтернатива, конечно, заключается в использовании здесь двоеточия, как в Python. На самом деле, я считаю, что большинство таких неоднозначных наполнителей можно заменить двоеточиями. Не уверен, какой метод я предпочитаю.
Конрад Рудольф
3
@ Конрад: если он устраняет неоднозначность синтаксиса, это не наполнитель. is Является наполнителем , потому что Ада могла позволили procedure Hello begin ... endбез какой - либо двусмысленности.
Ден04
4

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

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

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

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

Джои Адамс
источник
2
Как состав функций в Haskell каким-либо образом отстал? Это прямой перевод (f ∘ g)(x) = f(g(x)).
Джон Пурди
@Jon Purdy: Это означает, что вы должны написать функции в обратном порядке их применения. В обеих формах gсначала применяется аргумент, а затем f. Если вы хотите отсортировать список, сгруппировать его и получить первый элемент этих списков, вы должны написать (map head . group . sort) listили map head $ group $ sort listили map head (group (sort list)). Во всех случаях вы в конечном итоге записываете операции задом наперед. Кстати, импорт Control.Arrowпозволяет вам сказать (sort >>> group >>> map head) list, но >>>оператор выглядит довольно неловко и многословно для меня.
Джои Адамс
2
Я не знаю, я все еще думаю, что справа налево имеет смысл. (map head . group . sort) listчитается как «первый элемент каждой группы в некотором роде list», что вполне естественно - и, на мой взгляд, более функционально, чем (sort >>> group >>> map head) list, что читается довольно настоятельно и задом наперед как «сортировать затем группа, затем брать первый элемент каждой группы». .. list"
Джон Пурди,
@JoeyAdams - то >>>оператор выглядит довольно неуклюжие и многословным - Несколько более поздние функциональные языки начали использовать в |>качестве левого направо оператора цепным, что , возможно, немного легче на глазах ...
Жюль
4

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

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

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

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

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

user281377
источник
Я с вами на 100% для полной спецификации. Мультипарадигма и последовательность определенно будут уравновешивающим действием. Вы можете указать набор поведений для динамической парадигмы в качестве подмножества поведений для статической проверки - но я думаю, что эти два подхода могут использовать очень разные стили программирования. Они действительно должны быть отдельными языками на этом этапе. Возможно, вам нужна пара совместимых языков со 100% совместимостью?
Берин Лорич
Такие языки, как Scala (и, возможно, Haskell? Я недостаточно знаю), имеют сильную статическую систему типов и краткость, благодаря выводу типов и последствиям.
PhiLho
2
Архитектурно-зависимые функции хороши, когда язык позволяет программисту определять, что является или не важно. Что делает C ужасным, так это то, что нет способа объявить «числовой тип, который обертывает по модулю 65536»; даже если платформа реализует uint16_t, стандарт требует, чтобы некоторые реализации рассматривали разницу между двумя uint16_tзначениями как подписанные, а другие - как разницу без знака; это не дает программисту возможности указать, какое поведение желательно.
суперкат
Я не согласен с мультипарадигмой; это оставляет слишком много места для маневра для кодирования стилей сражений. Библиотека A написана с кучей динамических парадигм . Библиотека B написана с кучей статических парадигм . Что ж, теперь библиотеке А нужно поговорить с библиотекой Б; где середина? Если вам приходится писать клей между двумя частями кода на одном и том же языке, язык по своей сути является недостатком IMO.
Qix
3

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

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

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

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

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

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

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

Jonas
источник
Хвост-Рекурсия: c2.com/cgi/wiki?TailRecursion
Берин Лорич
Scala имеет рекурсию хвоста и компилируется в JVM. IBM Java-компилятор тоже может выполнять хвостовую рекурсию - иногда.
Мартин
3

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

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

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

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

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

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

оборота диетбудда
источник
В Ruby есть «специальные формы» для циклов, по крайней мере в том смысле, что итеративные объекты обычно имеют такой метод, eachкоторый принимает блок кода в качестве аргумента. (У Ruby также есть forи whileциклы, но ни один уважающий себя программист Ruby на самом деле их не использует.)
mipadi
@mipadi: я большой поклонник блоков Ruby и связанных с ними идиом.
dietbuddha
возможно, они думают: «Вы выстрелите в глаза». :) Полагаю, это была ассоциация всех вас мощных "Python" и "нет веских причин, почему". Тем не менее, метапрограммирование является допустимой проблемой языкового дизайна, которой часто пренебрегают. По этой причине я буду голосовать за это.
Берин Лорич
@Berin: я на самом деле использую, и я фанат Python, что делает его более забавным.
dietbuddha
Один тип цикла сделает поток кода неясным. Например, как выглядел бы do..whileцикл, если бы был один тип цикла, который имел оценку вверху? Это не будет похоже на цикл do.. while.
Qix
2

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

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

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

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

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

Матье М.
источник
8
Но это может быть просто функция стандартной библиотеки .
Donal Fellows
@Donal: Я никогда не говорил иначе (или, по крайней мере, так не думал), вопрос открыт как для языка, так и для библиотечных функций. Я просто хочу сказать, что если вы получите языковой пакет и у вас нет сетевых возможностей, вы скорее восполните боль, чем позже :)
Matthieu M.
3
Стандартная библиотека действительно является частью языкового опыта, и к ней следует относиться с той же осторожностью и уважением. Я также согласен с этим требованием для стандартной библиотеки.
Берин Лорич
1

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

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

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

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

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

OscarRyz
источник
Ортогональный означает, что каждая функция делает что-то свое. Посмотрите на инструменты, такие как grep или awk. Они делают одну вещь, хорошо. Затем вы подключаете их в разных порядках, чтобы сделать все, что вам нужно.
Тео Белер
1
  • читабельность : чем меньше / меньше символов в грамматике, тем чище и лучше.
  • Объектно-ориентированные типы : методы, а не функции.
  • Понятность : встроенные беглые интерфейсы, полные и краткие имена для библиотечных классов / интерфейсов и их разновидностей.
оборота dukeofgaming
источник
1
Извините, но я должен дать вам -1 за то, что вы совершенно не правы в этом. Краткость помогает писать код быстрее, но, безусловно, не делает код более читабельным, за пределами определенного минимума. Определенный уровень многословия делает код намного легче для чтения, потому что эти дополнительные слова и символы что-то значат и передают значимую информацию программисту, особенно если она изначально была написана кем-то другим, и у вас нет преимущества уже иметь умственный модель этого в вашей голове.
Мейсон Уилер
Для меня чистый код - это читаемый код. Я также сказал самое маленькое: наличие «:» вместо «=>» в массивах PHP или наличие «.» вместо "->", безусловно, будет улучшение (и я уже наслаждаюсь PHP).
dukeofgaming
4
@ Мейсон: Я и многие хорошие технические писатели (например, Уильям Зинссер) не согласны. Многословие - враг читабельности, а не краткости.
Конрад Рудольф
2
Я иду за форму краткости, которая определяется в терминах символов . Хотя я вполне доволен многосимвольными символами, если они являются вещами, которые читатель воспринимает как один символ (например, слово является символом).
Донал Феллоуз
1
Ваша первая точка зрения напрямую противоречит вашим последним двум.
Qix
1

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

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

  1. C добавление классов => C ++
  2. Java добавляет некоторые вещи => C #
umlcat
источник
2
Это огромное упрощение. Гораздо лучшим примером будет разница между C и Objective-C.
Джон Перди
0

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

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

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

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

Амир Резаи
источник
3
Компьютеры уже достаточно мощные, чтобы сделать это. Это просто не практично, так как по той или иной причине вам нужно будет углубиться в код .
Джереми Хейлер
2
Это все еще своего рода язык. Было сделано не одна попытка сделать это реальностью. Инструменты UML будут генерировать определенный объем кода, но когда модель достаточно детализирована для создания работающего продукта, ее больше нельзя использовать для понимания кода. Я считаю, что в среде Unix было что-то для графической разводки приложений, но для правильной работы потребовалось много настроек. Механизмы рабочих процессов используют этот метафора, чтобы позволить непрограммистам проектировать рабочий процесс.
Берин Лорич
1
Короче говоря, хотя я серьезно сомневаюсь в полезности этого подхода в общих чертах, есть конкретные приложения, где он в настоящее время используется и хорошо работает для этого приложения. Re: ваши очки ... 1. Компьютеры обладают вычислительной мощью, техническая сторона не проблема. 2. Проблема заключается в предоставлении визуального языка, который достаточно выразителен, чтобы выполнять работу в общем смысле, не теряясь в деталях. Вне нишевых приложений текст кажется гораздо более компактным представлением программы. Я сделал upvote, потому что это применимо к поставленному вопросу.
Берин Лорич
1
@ Амир: Тогда, пожалуйста, объясните, почему компьютеры должны быть более мощными, чтобы «графическое программирование» стимулировало разработку программного обеспечения?
Джереми Хейлер
7
@ Амир: Вы смешиваете техническое ограничение с более фундаментальным. Причина, по которой у нас не так много графических компьютерных языков, заключается в том, что мы не знаем, как их хорошо делать (и не знаем, можно ли их сделать хорошо). Я знаю о LabView и слышал достаточно скуки о том, как делать в ней сложные вещи или менять простые вещи. Нам также не нужны более мощные компьютеры для разработки такого языка, поэтому давайте попробуем набросать некоторые примеры программ на таком гипотетическом языке.
Дэвид Торнли