Цель этого вопроса не состоит в том, чтобы собрать подробный список функций языка программирования, без которых вы не можете жить или хотите, чтобы ваш основной язык был выбран. Цель этого вопроса состоит в том, чтобы пролить свет на углы языкового дизайна, о которых большинство языковых дизайнеров может и не подумать. Таким образом, вместо того, чтобы думать о языковой особенности X, подумайте немного более философски.
Одно из моих предубеждений, и, возможно, это может быть спорным, заключается в том, что более мягкая сторона разработки - почему и зачем - во много раз важнее, чем более конкретная сторона. Например, Ruby был разработан с заявленной целью улучшения счастья разработчиков. Хотя ваше мнение может быть неоднозначным по поводу того, было ли оно достигнуто или нет, тот факт, что это была цель, означает, что эта философия повлияла на некоторые варианты языкового дизайна.
Пожалуйста, не пишите:
- Синтаксис пламенных войн. Посмотрим правде в глаза, у нас есть свои предпочтения, и синтаксис важен, поскольку он относится к языковому дизайну. Я просто хочу избежать эпических битв о природе emacs vs. VI (о которых сегодня многие ничего не знают).
- «Любой язык, у которого нет функции X, не заслуживает того, чтобы существовать», напишите комментарии. Существует как минимум одна причина существования всех языков программирования - хорошая или плохая.
Пожалуйста, сделайте пост:
- Философские идеи, которые языковые дизайнеры, похоже, упускают.
- Технические концепции, которые кажутся плохо реализованными чаще, чем нет. Пожалуйста, приведите пример боли, которую это вызывает, и если у вас есть идеи о том, как вы бы предпочли, чтобы он функционировал.
- Вещи, которые вы хотите, были в общей библиотеке платформы, но редко бывают. Один и тот же знак, вещи, которые обычно находятся в общей библиотеке, чего вы не хотели.
- Концептуальные функции, такие как встроенная поддержка тестирования / утверждения / контракта / обработки ошибок, которые вы хотите, чтобы все языки программирования реализовывали должным образом - и определяли правильно.
Я надеюсь, что это будет веселая и стимулирующая тема.
Изменить: Уточнил, что я имею в виду под синтаксисом Flame Wars. Я не пытаюсь избегать всех обсуждений синтаксиса, особенно потому, что синтаксис является фундаментальной частью дизайна языка программы.
источник
Ответы:
Поддержка Unicode по умолчанию
В наши дни программы разрабатываются для использования на международном уровне или при условии, что они могут быть использованы на международном уровне. Они должны обеспечить поддержку своих наборов символов или сделать программы, написанные на этом языке, бесполезными.
источник
string
иbyte[]
. Как и Python 3.x сstr
иbytes
. C (++)char
делает это ужасно неправильно.u'My Unicode Štring'
. Я хотел бы, чтобы вы могли просто забыть, с каким типом строки вы имеете дело, и чертовски написать код.У меня есть пара
Generics / шаблоны. Например, дженерики Java являются мощными, но не обязательно гибкими. Кроме того, поскольку они используют стирание типов, я видел проблемы с их абстрактной реализацией, особенно в интерфейсах. И компилятор не должен предупреждать, когда используется неспецифический универсальный (например,
Hashmap
вместоHashmap<String, int>
). Я думаю, что они могут быть значительно улучшены. Хорошие шаблоны очень полезны, но часто ими пренебрегают.Хорошая дата поддержки в стандартной библиотеке. Я имею в виду возможность складывать и вычитать даты, часы и минуты и не иметь дело с количеством миллисекунд с 1 января 1970 года.
источник
java.util.Date
есть почти все возможные ошибки и проблемы. Я знаю только часть новогоjava.time.*
пакета, но он чистый, простой в использовании и без ошибок. Более продвинутые пользователи могут найти проблемы, но это огромное улучшение. +++ Проблема, кажется, в том, что это сложная проблема, и первая версия сорвана и сломана.Пожалуйста, сделайте ваш язык анализируемым / проверяемым для людей, занимающихся компьютерной безопасностью.
Сотрудники службы безопасности должны быть в состоянии найти уязвимости в программе до ее отправки. В идеале, мы звоним раньше и можем комментировать кодовую базу по мере ее развития, но часто нет.
Когда выйдет новая версия языка или базовых библиотек, вещи, которые ранее были безопасными, могут перестать быть:
javascript:
eval
библиотеки десериализацииЛюбое из этих изменений может увеличить количество злоупотребляемых правами, которыми обладает программа, но, поскольку количество прав, которыми пользуется программа (при работе с не вредоносными клиентами), не изменилось, специалистам по безопасности трудно понять это без интенсивного повторный аудит.
Поэтому, пожалуйста, подумайте о нас при разработке и создании версий языка. Ниже приведены несколько советов:
Определите несколько примитивов, на которые программа может быть разложена.
HTML5 особенно плох в этом смысле. Они, очевидно, много думают о безопасности и имеют очень умных людей, но вместо того, чтобы указывать новые элементы программы, например,
<video>
в терминах старых, или создавать общую абстракцию, в которой новые<video>
и старые<img>
оба могут быть указаны в терминах,<video>
еще нет. еще один одноразовый элемент программы со своими собственными последствиями для безопасности.Сделайте свой язык пригодным для статического анализа (даже если он не статически типизирован).
Специалисты по безопасности часто используют статический анализ, чтобы найти шаблоны и попытаться исключить части программы, чтобы они могли сосредоточиться на действительно сложных моментах.
Должно быть очевидно, какие идентификаторы являются локальными переменными, а какие нет.
Например, не делайте ту же ошибку, что и в старых версиях JavaScript, из-за чего невозможно определить,
x
является ли ссылка на локальную переменную ниже (согласно буквальному прочтению старой версии спецификации):Разрешить для разложимой безопасности
Многие защищенные системы спроектированы вокруг безопасного ядра, которое сохраняет свойства безопасности, так что специалисты по безопасности могут сосредоточить свои усилия на анализе небольшого количества кода и избавлении большинства программистов от необходимости иметь дело с {раздражающими, педантичными, параноидальными} специалистами по безопасности ,
Должно быть возможно написать такое ядро на вашем языке. Если одно из свойств безопасности вашего языка, это то, что когда-либо будет выбрано только определенное подмножество 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) - это то, что Аллан Кей назвал «агглютинативными» языками: языки Франкенштейна состояли из множества связанных функций.
Следующим наиболее важным является то, что изменения самого языка должны быть последним средством. Даже самые доброкачественные звучания могут стать сложными в сочетании с другими особенностями языка. Я бы сказал, что для добавления новой функции в язык вам необходимо:
источник
Спасибо за отличный вопрос. Вы получаете довольно хорошие ответы.
Не для того, чтобы застеклить глаза, но я смотрю на программиста как на информационный канал. Идеи / концепции / требования идут с одной стороны, а код - с другой.
Если вы берете набор требований (независимо от того, как они указаны) и набор кода на огромной доске и рисуете линии, отображающие каждое требование в код, который его реализует, сложность этого графика будет зависеть от того, насколько хорошо код выражает требования. В идеале, оно должно быть довольно прямым и непосредственным, но на практике это трудно сделать.
Я измеряю предметную специфику языка как степень, в которой он упрощает этот граф. Это чрезвычайно желательное свойство, и к нему можно подходить любым количеством способов, начиная от определения правильных классов / процедур (существительных / глаголов) и заканчивая макросами, до написания собственного синтаксического анализатора и интерпретатора / компилятора.
Позвольте мне привести пример того, что я имею в виду. Что касается проблемы создания гибких диалоговых пользовательских интерфейсов, этот метод исключает необходимость писать обработчики событий, перемещение данных, большинство вещей, обычно выполняемых в пользовательском интерфейсе. Это также приводит к уменьшению исходного кода примерно на порядок. Мета-язык - это всего лишь несколько подпрограмм и макросов в C / C ++ / Lisp, и я также сделал это на языках без макросов.
Если выполнение требования может быть выполнено с 5-точечными правками в коде или с 10-ю, выполнение с 5-ю не только меньше кода, но и меньше шансов пропустить шаг и привести к ошибке. Таким образом, чем более специфичен домен для конкретного языка, тем меньше код, тем легче его обслуживать и тем более нет ошибок. Я думаю, что мы должны знать, как двигаться к этому. Это не означает, что код более читабелен, если только читатель не вложил средства в обучение, чтобы понять технику.
источник
Ограниченные и различные целочисленные типы, такие как Паскаль и Ада. Честно говоря: как часто вам нужен полный диапазон любого целого числа? Я думаю, что в примитивных типах многое нужно улучшить, чтобы лучше представлять реальный мир.
источник
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
? Что делать, если вы египтолог?type Egyptian_Year is -9999 .. 300;
. По моему опыту вы можете найти полезные границы для целых чисел большую часть времени. В этом отношении вы должны учитывать, чтоtype Scrolls_Found is array Egyptian_Year of Natural;
вы не можете / не должны иметь неограниченный тип в качестве индекса массива. Это просто вектор атаки для хакера. Кстати: Ada позволяет рассчитывать границы диапазона во время выполнения.Существуют функции, облегчающие использование языков программирования после их изучения, а также функции, облегчающие их изучение. Поскольку пользователи языка в идеале имеют долгосрочные отношения с ним, оптимизация для простоты использования лучше, чем оптимизация для простоты изучения. Не усложняйте вещи, чем это необходимо, но не жертвуйте выразительностью (способностью написать небольшой код, который много делает) для удобства чтения тем, кто не знаком с языком. С другой стороны, язык не должен читаться как шум строки людям, которые работают с ним годами; это было бы нелегко использовать или учить.
источник
Соглашения об именах (я смотрю на вас PHP)
источник
Первоклассная интеграция со средами разработки.
В настоящее время кодирование выполняется в богатой среде. Для HTML / CSS / JS у нас есть Firebug и другие интерактивные инструменты. Для Java, Eclipse и IDEA и других истинных IDE. И так далее. Есть экология инструментов, начиная с редактора, но не заканчивая там:
Языки должны быть построены, чтобы обеспечить поддержку этих действий. Некоторый прогресс был достигнут - например, аннотации на Java, чтобы помочь другим разработчикам понять смысл кода.
Но в основном это взломанные вещи, например, использование $ Id $ в комментарии, чтобы источник, контролируемый CVS, мог содержать номер версии. Почему я не могу сделать что-то подобное из самого языка?
источник
Распределенные вычисления
Бесплатный обед окончен. Сегодня нужны программы, которые работают на нескольких ядрах / нескольких процессорах (и в особых случаях на нескольких компьютерах).
К сожалению, написание многопоточного кода сложно с концептуальной точки зрения, поэтому нет необходимости добавлять язык в качестве барьера.
Использование C ++ 0x в будущем , безусловно, интересно, несмотря на то, что оно представлено в виде библиотеки и не освобождает вас от актуальных проблем синхронизации (вы знаете, те, которые так просто решить ...)
Мне действительно нравится подход Go к этой проблеме: многопоточность встроена, а выбранный подход (каналы и программы) устанавливает гораздо более простое мышление, чем традиционные подходы семафор / мьютекс / блокировка. Хотя по-прежнему легко получить доступ к несинхронизированной структуре одновременно (в Go есть указатели) или к тупику (цикл ожидания на каналах ...)
Я думаю, что языки, предпочитающие неизменность данных, как и функциональные языки, могут иметь на это право (хотя мне там нравится опыт).
Кроме того, модель Actor может быть нашей следующей целью. Он также предназначался для распределенных вычислений.
источник
Считай меня сумасшедшим, но одной из самых важных языковых возможностей для меня является наличие хорошего онлайн-справочника вместе с примерами. Я знаю, что могу найти хорошие результаты поиска для любого языка, но мне действительно нравится сайт API-интерфейсов MSDN и Java. Они значительно облегчают программирование для человека, который не имеет большого опыта работы с конкретным языком.
источник
Больше возможностей помочь компилятору проверить ваш код.
Будучи программистом встраиваемых систем, я всегда использую C. Но мне всегда хотелось бы иметь больше / лучше способов сообщить компилятору, чего я ожидаю от своего кода, чтобы он мог это проверить.
Например, я могу иметь функцию
но я бы предпочел
Например, я хотел бы иметь возможность писать утверждения о функциях, используя какой-то функциональный язык более высокого уровня, такой как Lisp или Haskell. Они не будут скомпилированы в код, но могут быть использованы для статического или динамического анализа.
источник
Небольшой синтаксис с минимальным количеством ключевых слов, так как подробный синтаксис сложен для изучения и не способствует удобочитаемости.
Худший пример - Ада:
Заполняющие слова как is, as, ... не имеют смысла для языков программирования.
источник
public static void
.IS
это, то вы не понимаете Ada (вы когда-нибудь программировали Ada?):IS
Отделяет объявление процедуры от объявления локальных переменных, а также отличает спецификацию от реализации. Конечно, вы могли бы заметить только при сравнении спецификации и реализации функции, чтобы увидеть, что онаIS
имеет смысл и не является наполнителем вообще.if x then …
чтобыif (x) …
. Мы обменяли пару скобок на контекстное ключевое слово. Это имеет смысл, потому что условиеx
может быть сложным выражением со своими собственными скобками. Исключение самой внешней пары может значительно улучшить читаемость. Альтернатива, конечно, заключается в использовании здесь двоеточия, как в Python. На самом деле, я считаю, что большинство таких неоднозначных наполнителей можно заменить двоеточиями. Не уверен, какой метод я предпочитаю.is
Является наполнителем , потому что Ада могла позволилиprocedure Hello begin ... end
без какой - либо двусмысленности.Я хотел бы видеть больше изучения языков . Не только языки для начинающих с более строгими ограничениями, как, например, требование пробела между каждым токеном , но и языки для людей, которые уже знают программирование и хотят изучать новые концепции или лучше программировать в целом.
Для меня Haskell - отличный пример того, что я имею в виду под «изучением языка» (хотя с годами его популярность и общая полезность также выросли). Отказ от привычного синтаксиса C и наличие обратных операторов композиции функций (например,
(+2) . (*3)
, это функция, которая умножает на 3, а затем добавляет 2), Haskell научил меня писать более короткие функции. Его беспощадная проверка типов помогла мне быстрее выучить язык и улучшила мою способность логически мыслить код. Оба эти преимущества распространяются на другие языки, даже на ассемблер.Цели изучения языков и целей языков общего назначения часто противоречат друг другу. Изучаемый язык должен быть сложным и полезным для изучения и должен обеспечивать соблюдение определенного стиля, даже если этот стиль не является лучшим для многих приложений. Язык общего назначения должен быть хорош для выполнения работы, а использование абстракций должно быть тщательно измерено и «иметь смысл». Например, при исправлении сайта, узнав о монад было бы последним в голове программиста. С другой стороны, когда кто-то учится программировать, ему не нужно разбираться в бессмысленной чепухе, если он еще даже не узнал о функциях.
Если вы дизайнер языка, пожалуйста, решите, является ли ваш язык языком обучения или прикладным языком. Это определит, в какой степени вы захотите использовать чистоту в вашем дизайне.
источник
(f ∘ g)(x) = f(g(x))
.g
сначала применяется аргумент, а затемf
. Если вы хотите отсортировать список, сгруппировать его и получить первый элемент этих списков, вы должны написать(map head . group . sort) list
илиmap head $ group $ sort list
илиmap head (group (sort list))
. Во всех случаях вы в конечном итоге записываете операции задом наперед. Кстати, импортControl.Arrow
позволяет вам сказать(sort >>> group >>> map head) list
, но>>>
оператор выглядит довольно неловко и многословно для меня.(map head . group . sort) list
читается как «первый элемент каждой группы в некотором родеlist
», что вполне естественно - и, на мой взгляд, более функционально, чем(sort >>> group >>> map head) list
, что читается довольно настоятельно и задом наперед как «сортировать затем группа, затем брать первый элемент каждой группы». ..list
">>>
оператор выглядит довольно неуклюжие и многословным - Несколько более поздние функциональные языки начали использовать в|>
качестве левого направо оператора цепным, что , возможно, немного легче на глазах ...Так как мы в 2011 году,
поддержка многопоточности; не только функции синхронизации (блокировки), но и языковые функции, которые делают многопоточность такой же простой, как написание цикла:
все (o в myCollection) {o.someMethod ()}
мульти-парадигмы; позвольте мне, программисту, решить, хочу ли я безопасность во время компиляции статического языка или краткость динамического языка, в зависимости от конкретного случая; дать мне объектно-ориентированные функции, функциональные возможности и т. д.
согласованность (я знаю, что это требует много как для согласованности и мультипарадигмы ...)
источник
uint16_t
значениями как подписанные, а другие - как разницу без знака; это не дает программисту возможности указать, какое поведение желательно.Облегченные процессы
Я хотел бы иметь легкие процессы, как в Erlang. Это в основном проблема для времени выполнения. Это отсутствует в JVM и .NET CLR. LWP помогает создавать массово параллельное программное обеспечение. В идеале создание процесса не должно быть более дорогостоящим, как создание объекта на языке. Я хотел бы создать миллионы процессов в моих приложениях.
Он реализован в виде пула потоков с предварительным планированием, поэтому одна задача не блокирует другую задачу, и задачи можно планировать на любом доступном ядре процессора.
Поддержка хвостовой рекурсии
Я хотел бы получить поддержку хвостовой рекурсии. Это также может быть проблемой для среды выполнения. Например, JVM не поддерживает хвостовую рекурсию.
Простое распределенное программирование
Я хотел бы иметь поддержку для отправки ( ! ) И получения примитивов к частям приложения, работающим на других машинах с тем же сетевым словом, что и в Erlang. Это позволяет легко создавать масштабируемые приложения, например распределенные хранилища данных. Добавленная к этому встроенная в язык сериализация также очень полезна, как и в erlang. И не так, как на Java, я должен делать это вручную.
источник
Облегчить метапрограммирование.
ограничить специальные формы
В Python нет веских причин, по которым печатать это не встроенная функция. Он выглядит и действует как функция, за исключением того, что не хочет иметь ничего общего с паренсом.
У нас действительно нужно
for
,foreach
,while
и т.п. каждый в своей особой форме. Как насчет одной циклической конструкции и некоторых макросов по умолчанию, чтобы обеспечить синтаксический сахар вариантов циклических форм.метапрограммирование для специальных форм
form['if'](test-fn, body-fn)
источник
each
который принимает блок кода в качестве аргумента. (У Ruby также естьfor
иwhile
циклы, но ни один уважающий себя программист Ruby на самом деле их не использует.)do..while
цикл, если бы был один тип цикла, который имел оценку вверху? Это не будет похоже на цикл do.. while.Сетевые возможности
Язык, который поставляется без какой-либо сетевой поддержки, в современном мире довольно слабый.
Большинство реальных приложений должны взаимодействовать через какую-то сеть:
Это также краеугольный камень поддержки распределенных / облачных вычислений.
источник
Мне нравится язык программирования, который легко выучить и легко комбинировать для создания новых вещей.
Например, хотя привлекательно иметь много способов написать что-то, я думаю, что лучше иметь только один или два способа написать это. Таким образом, программу легче поддерживать.
Язык, концепции которого могут применяться ко всем элементам, очень полезен (я думаю, это называется ортогональностью). Итак, в следующий раз, когда вы столкнетесь с новой функцией языка, вы сможете определить, как ее использовать.
Я понимаю, что иногда синтаксис языка должен мешать работать лучше на этапе компиляции / интерпретации, но иногда я чувствую, что разработчик языка передает эту работу разработчику. Например, многострочные строки в Java или Javascript.
Наконец, синтаксис языка - это его пользовательский интерфейс, и поэтому он должен быть понятным, лаконичным, интуитивно понятным, простым в использовании и должен уважать ваши привычки.
источник
источник
Добавление функции в существующий язык программирования. Итак, новый язык B - это старый язык A с функцией X.
Существующие примеры:
источник
Когда дело доходит до технологии / платформы / языка / базы данных и т. Д., В большинстве случаев это сводится к производительности. В будущем многие современные программы могут быть разработаны с использованием графического языка, поскольку мы обладаем более мощными вычислительными возможностями.
Я надеюсь на тот день, когда у нас будут вычислительные возможности и язык, на котором вы разрабатываете свое приложение, и вам не нужно беспокоиться о деталях языка .
Обновление: отправляю ссылку на такой язык LabView
Обновление: я должен объяснить больше, что я имею в виду под «вычислительной мощью». Производительность скомпилированного программного обеспечения может быть не такой высокой, как у скомпилированного программного обеспечения на основе синтаксического языка. Я думаю о графическом программировании как о более высоком уровне программирования, и там может быть больше накладных расходов. Современные компьютеры могут легко работать с графическими языками программирования.
источник