Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Следующие 7000 языков программирования: заключение

Эволюционная теория неверна? В предыдущем разделе были рассмотрены три ситуации, когда языки имеют противоположные аспекты (гены). Мы наблюдаем, что это не является неожиданным; время и инерция также важны для перевода эволюционной пригодности в занятость ниши. Даже если вид или язык становятся менее пригодными, чем конкурент, его нынешнее доминирование может все же привести к тому, что он произведет больше семян, чем более приспособленный, но менее доминирующий конкурент, даже если эти семена по отдельности имеют меньшие шансы на успех. Таким образом, изменения в пригодности (например, повышение важности безопасности, влияющей на нашу воспринимаемую пригодность C), скорее всего, только изменят вторую производную процента занятости ниши. Кстати, последние данные, по-видимому, позволяют предположить, что динозавры находились в относительном сокращении по отношению к млекопитающим в течение примерно 50 миллионов лет до удара астероида Чиксулуб, который завершил эту задачу [39]. Мы одновременно утверждаем, что раздел 5 действительно правильно отражает занятость ниши сегодня, и в то же время в этом разделе предлагаются прогнозы будущей занятости ниши, основанные на современных представлениях о пригодности.

Воодушевленные успехом Ландина, мы теперь делаем некоторые прогнозы, начиная с «слонов в комнате» предыдущего раздела.

6.1 Замена для C/C ++?

Краткий ответ «Что заменит C/C ++ в свете его небезопасных возможностей?» - «ничто в краткосрочной перспективе». Одним из объяснений этого является то, что семейство языков C настолько тесно связано со всеми основными операционными системами, что его замена немыслима в краткосрочной перспективе. Одна из прагматических причин, помимо простой инерции, заключается в том, что большая часть цепочки инструментов системного программного обеспечения (компиляторы, отладчики, компоновщики и т.д.) либо непосредственно нацелена на C, либо предназначена для наиболее удобного использования в сочетании со стеком программного обеспечения C. Инвестиции, необходимые для переориентации этой цепочки инструментов, настолько велики, что есть веские экономические аргументы для продолжения использования C.

Принимая идею эволюционной инерции выше, ближайший ботанический аналог, возможно, звучит так: «Сколько времени потребуется для того, чтобы гигантские красные леса (секвойя) были вытеснены локально более приспособленными видами-конкурентами?», Отвечая «скорее, чем мхом, чтобы колонизировать влажный газон».

Тем не менее, есть инновации, незаметно срывающиеся с нынешним «нам просто придется мириться с ненадежностью C/C ++».

Одним из направлений являются такие языки, как Rust, которые предлагают лучшие гарантии безопасности через типы, а также безопасное подмножество C++, упомянутое в разделе 3.2.

Другим направлением является концепция Unikernel (или «библиотечная ОС»), примером которой является MirageOS [https://github.com/mirage]. MirageOS написана на языке управляемого функционального стиля OCaml и использует свою мощную модульную систему. Эксперименты показывают, что дополнительные затраты на управляемый язык (5 – 10% для драйверов низкого уровня) снижаются за счет уменьшения потребности в переключении контекста для защиты от арифметики указателей в небезопасных языках [26]. Может ли ядро Linux быть перекодировано аналогичным образом? Может ли компенсироваться немедленное снижение производительности под влиянием более гибких и высокоуровневых механизмов структурирования?

Второе направление - «давайте сделаем С безопасным». Сначала это кажется невозможным из-за арифметики указателей. Но использование дополнительного хранилища для представления метаданных указателя (например, base, limit и offset) во время выполнения может дать безопасную для указателя реализацию C; это может быть достигнуто с помощью толстых указателей, которые изменяют само представление указателя и, таким образом, нарушают совместимость с кодом, который не использует толстые указатели [19,44] [Тонкость заключается в том, что стандарт C в настоящее время требует, чтобы указатели больше не занимали пробел, чем целочисленный тип intptr t. Так часто жирные указатели должны использовать косвенную адресацию или методы упаковки на уровне битов, которые оба дороги в программном обеспечении], или с помощью методов инструментария во время компиляции, которые не изменяют представление указателей и, таким образом, облегчить интеграцию с неструктурированным кодом [16,32,37].

В любом случае, динамическая проверка границ уменьшает поверхность атаки в этом переполнении буфера, и подобное больше нельзя использовать для включения выполнения произвольного кода - короче говоря, результат не хуже (но не лучше) NullPointerException в Java. Недавняя работа абстрагирует жирные указатели на возможности и выполняет эту проверку на аппаратном уровне: проект Cheri, например. [6], имеет замену всей цепочки инструментов C (от аппаратного обеспечения на основе FPGA до компиляторов и отладчиков) для расширения возможностей, не зависящего от аппаратного обеспечения, созданного в виде MIPS-подобного набора команд. Стоимость выполнения этого порядка составляет порядка 1%.

Intel MPX [https://en.wikipedia.org/wiki/Intel MPX] (Memory Protection Extensions) имеет аналогичную цель, но данные об относительной производительности для целых операционных систем в MPX пока недоступны. Как обсуждено в разделе 5.1, Келл также приводит убедительные аргументы в пользу того, что безопасная и относительно производительная реализация C может быть осуществимой [18].

6.2 От динамического типа к статическому, к верифицированному ПО

Мы предполагаем, что постепенная типизация [1,43,46] будет становиться все более заметной в будущих языках, в результате чего статические типы могут постепенно добавляться в другие программы с динамической типизацией, так что полная статическая типизация будет включена при наличии достаточного количества типов с выводом типа алгоритмы, все еще позволяющие типы быть опущенными до некоторой степени. Это отражает «удобство для начинающих» и гибкость динамических типов, но способствует постепенному переходу к гарантиям, которые предоставляют статические типы. Идеи в этом направлении изучаются языком взлома Facebook, как обсуждалось в разделе 5.2. Такикава и соавторы недавно изучил производительность постепенной типизации в контексте Racket, при этом текущие результаты свидетельствуют о том, что необходима работа для сокращения накладных расходов на пересечение границы типизированного / нетипизированного во время выполнения, и что производительность имела тенденцию к падению, поскольку статические типы были введены в программы, если они не были введены везде [45]. Тем не менее, кажется, что такие проблемы производительности могут быть решены с помощью комбинации расширенного вывода типов и различных вариантов реализации, и, кроме того, типы дают много преимуществ помимо производительности, особенно в отношении рефакторинга.

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

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

Мы видим единое целое, где типы, тесты и спецификации дополняют друг друга и могут быть разработаны до, во время или после системы программного обеспечения (форма «постепенной проверки»). По мере развития системы требуемая степень проверки правильности также может изменяться, и мы предвидим события, которые делают переход по этому спектру естественным прогрессом в течение всей жизни системы. Документированным примером формальных требований к корректности, добавляемых в систему постфактум, является множитель с плавающей запятой Pentium 4 [17] (40000 строк HDL); совместная разработка программного обеспечения и спецификаций видна в проверенных компилятором проектах CompCert [23] и CakeML [21].

6.3 Увеличенная фрагментация поддержки параллелизма

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

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

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

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

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

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

6.4. Устойчивость к ошибкам

По мере роста систем и их большей распределенности, структурированные подходы к устойчивости к ошибкам (преодоление временных и постоянных ошибок) станут более важными. В разделе 3.2 была исследована модель Erlang fail-fast (терпите неудачу в непредвиденных ситуациях и ожидайте, что ваш владелец все исправит), а также предположение, что идемпотентность функционального стиля с большей вероятностью будет плодотворной в сильно распределенных системах, чем классическая контрольная точка императивного стиля и откат.

6.5. Поддержка лучших практик разработки программного обеспечения

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

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

Мы больше не можем редактировать отдельные строки кода, но кодировать и применять преобразования либо в форме рефакторингов (основанных на тех, которые в настоящее время поддерживаются сложными IDE для Java и C#), либо путем написания кода, который пишет (или редактирует) код, такой как те, которые разрабатываются Atomist [https://www.atomist.com/]. Это напоминает о возможности синтеза кода из спецификации с использованием методов ИИ, которые мы обсудим далее в разделе 6.6.

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

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

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

6.6. Синтез программы и ИИ

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

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

Кажется очевидным, что есть возможности для эффективного синтеза программ в соответствующих ограниченных областях, таких как разработка стандартных драйверов устройств [38]. Перспектива синтеза правильной реализации нетривиального класса с учетом точного определения его интерфейсов и набора модульных тестов, которые он должен пройти, кажется в ближайшем будущем недостижимой: недавняя работа по синтезированию программ из примеров ввода/вывода показывает обещание [2] и привлекла широкое внимание средств массовой информации [https://www.newscientist.com/article/mg23331144-500-ai-learns-to-write-its-own-code-by-stealing-from-other-programs/].

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

6.7. Не предсказание

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

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

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

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

Несколько заключительных слов

Хотя мы надеемся предоставить некоторые обновленные обсуждения и прогнозы после работы Лэндена полвека назад, они могут только отражать нынешнюю структуру языков, и эволюция продолжается. Интересно, что скажет последующая статья через 50 лет?

Выражение признательности. Мы благодарны Софии Дроссопулу, Стивену Келлу, Тому Стюарту, Джуст-Питеру Катоену, Флеммингу Нильсону и Бернхарду Штеффену за полезные отзывы о более раннем проекте этой работы.

Аластера Дональдсона поддержала Стипендия EPSRC по ранней карьере (EP/N026314/1).

Список литературы

1. Андерсон С., Дроссопулу С.: BabyJ: от объектно-ориентированного программирования к классам через типы. Электр. Отмечает Теор. Вычи. Sci. 82 (7), 53–81 (2003). https://doi.org/10.1016/S1571-0661(04)80802-8

2. Балог, М., Гонт, А.Л., Брокшмидт, М., Новозин, С., Тарлоу, Д .: DeepCoder: учимся писать программы. CoRR abs / 1611.01989 (2016). http://arxiv.org/abs/1611.01989

3. Бек, К .: Разработка через тестирование: на примере. Addison-Wesley Longman Publishing Co., Inc., Бостон (2002)

4. Бек, К., Андрес, С : Объяснение экстремального программирования: Embrace Change, 2nd edn. Аддисон-Уэсли Профессионал, Бостон (2004)

5. Брауэр В. (ред.): Gesellschaft f.ur Informatik e.V. LNCS, vol. 1. Springer, Гейдельберг (1973). https://doi.org/10.1007/978-3-642-80732-9. 3 Jahrestagung, Гамбург, Германия, 8–10 октября 1973 г.

6. Чисналл Д., Ротвелл С., Уотсон Р.Н., Вудрафф Дж., Вадера М., Мур С.В., Роу М., Дэвис Б., Нейман П.Г.: За рамками PDP-11: архитектурная поддержка абстрактной машины, безопасной для памяти. SIGARCH Comput. Archit. Новости 43 (1), 117–130 (2015). https://doi.org/10.1145/2786763.2694367

7. Claessen, K., Hughes, J .: QuickCheck: легкий инструмент для случайного тестирования программ на Haskell. В: Одерский, М., Уодлер, П. (ред.) Материалы пятой Международной конференции ACM SIGPLAN по функциональному программированию (ICFP 2000), 18–21 сентября 2000 г., Монреаль, Канада, с. 268–279. ACM (2000). https://doi.org/10.1145/351240.351266

8. Дин Дж., Гемават С .: MapReduce: гибкий инструмент обработки данных. Commun. ACM 53 (1), 72–77 (2010). https://doi.org/10.1145/1629175.1629198

9. Фостер Н., Гринберг М., Пирс Б.С. Виды, считающиеся вредными. Приглашенный доклад на Математические основы семантики программирования (MFPS) (2008). http://www.cis.upenn.edu/~bcpierce/papers/harmful-mfps.pdf

10. Фаулер М., Бек К .: Рефакторинг: улучшение дизайна существующего кода. Серия объектных технологий. Addison-Wesley Longman Publishing Co., Inc., Бостон (1999)

11. Габриэль Р.П .: Лисп: хорошие новости, плохие новости, как выиграть крупно (1991). HTTPS: //www.dreamsongs.com/WIB.html

12. Габриэль Р.П .: Образцы программного обеспечения: Рассказы от сообщества разработчиков программного обеспечения. Oxford University Press Inc., Нью-Йорк (1996)

13. Габриэль Р.П., Уайт Дж.Л., Боброу Д.Г .: CLOS: интеграция объектно-ориентированного и функционального программирования. Commun. ACM 34 (9), 29–38 (1991). https://doi.org/10.1145/114669.114671

14. Гарнер, С .: Снижение когнитивной нагрузки на начинающих программистов. В: Баркер П., Ребельский С. (ред.) Труды EdMedia: Всемирная конференция по образовательным медиа и технологии, с. 578–583. ЭРИК (2002)

15. Хатхорн, C., Эллисон, C., Rosu, G .: Определение неопределенности C. В: Grove, D., Blackburn, S. (eds.) Материалы 36-й конференции ACM SIGPLAN по разработке языков программирования и Реализация, 15–17 июня 2015 г., Портленд, Орегон, США, с. 336–345. ACM (2015). https://doi.org/10.1145/2737924.2737979

16. Jones, R.W.M., Kelly, P.H.J .: обратно-совместимая проверка границ для массивов и указателей в C-программах. В: AADEBUG, стр. 13–26 (1997). http://www.ep.liu.se/ecp/article.asp?issue=001&article=002

17. Кайвола Р., Нарасимхан Н .: Формальная проверка множителя Pentium R _ 4 с плавающей запятой. В: Материалы конференции по проектированию, автоматизации и испытаний в Европе, ДАТА 2002, стр. 20–27. IEEE Computer Society, Вашингтон, округ Колумбия (2002). http://dl.acm.org/citation.cfm?id=882452.874523

18. Келл, С .: Некоторые предназначались для Си: выносливость неуправляемого языка. В: Торлак Э., ван дер Шторм Т., Биддл Р. (ред.) Материалы Международного симпозиума ACM SIGPLAN 2017 года по новым идеям, новым парадигмам и размышлениям о программировании и программном обеспечении - вперед! 2017, 23–27 октября 2017, Ванкувер, Британская Колумбия, Канада, с. 229–245. ACM (2017). https://doi.org/10.1145/3133850.3133867

19. Kendall, A.S.C .: Bcc: проверка времени выполнения для C-программ. В кн .: Летняя конференция USENIX, с. 5–16. USENIX (1983)

20. Кеннеди К., Кельбель С., Зима Х.П .: Взлет и падение высокоэффективного Фортрана: исторический объектный урок. В: Ryder, B.G., Hailpern, B. (eds.) Труды Третьей конференции ACMSIGPLAN «История языков программирования» (HOPLIII), 9–10 июня 2007 г., Сан-Диего, Калифорния, США, стр. 1–22. ACM (2007). https://doi.org/10.1145/1238844.1238851

21. Кумар Р., Мирин М.О., Норриш М., Оуэнс С .: CakeML: проверенная реализация ML. В: Джаганнатан С., Сьюэлл П. (ред.) 41-й ежегодный симпозиум ACM SIGPLANSIGACT по принципам языков программирования, POPL 2014, 20–21 января 2014 г., Сан-Диего, Калифорния, США, с. 179–192. ACM (2014). https://doi.org/10.1145/2535838.2535841

22. Ландин П.Ж .: Следующие 700 языков программирования. Commun. ACM 9 (3), 157–166 (1966). https://doi.org/10.1145/365230.365257

23. Леруа Х .: Формальная проверка реалистичного компилятора. Commun. ACM 52 (7), 107–115 (2009). https://doi.org/10.1145/1538788.1538814

24. Лопес, CV, Maj, P., Martins, P., Saini, V., Yang, D., Zitny, J., Sajnani, H., Vitek, J .: D.jjavu: карта дубликаты кода на github. В: PACMPL, вып. 1, нет. OOPSLA, стр. 84: 1–84: 28 (2017). https://doi.org/10.1145/3133908

25. Макиннон, Т., Фриман, С., Крейг, П. Эндотестирование: модульное тестирование с использованием фиктивных объектов. В: Суччи Г., Маркези М. (ред.) Экстремальное программирование изучено, с. 287–301. Addison-Wesley Longman Publishing Co., Inc., Бостон (2001). http://dl.acm.org/citation.cfm?id=377517.377534

26. Мадхавапедди, А., Мортье, Р., Ротсос, С., Скотт, Д., Сингх, Б., Газанье, Т., Смит, С., Хэнд, С., Кроукрофт, Дж .: Unikernels: библиотека операционные системы для облака. В: Материалы восемнадцатой международной конференции по архитектурной поддержке языков программирования и операционных систем, ASPLOS 2013, с. 461–472. ACM, Нью-Йорк (2013). https://doi.org/10.1145/2451116.2451167

27. Марлоу С.: Параллельное и параллельное программирование на Хаскеле. O’Reilly, Севастополь (2013)

28. McCormick, J.W., Chapin, P.C .: Создание приложений с высокой степенью целостности с помощью SPARK. Издательство Кембриджского университета, Кембридж (2015)

29. Мемариан, К., Маттисен, Дж., Лингард, Дж., Ниенхуис, К., Чисналл, Д., Уотсон, Р.Н.М., Сьюэлл, П .: В глубины Си: разработка стандартов де-факто. В кн .: Кринц К., Бергер Е. (ред.) Материалы 37-й конференции ACM SIGPLAN по разработке и внедрению языков программирования, PLDI 2016, 13–17 июня

2016, Санта-Барбара, Калифорния, США, стр. 1–15. ACM (2016). https://doi.org/10.1145/2908080.2908081

30. Митчелл Дж. С. Концепции в языках программирования. Издательство Кембриджского университета, Кембридж, октябрь 2002

31. Murray, D.G., Schwarzkopf, M., Smowton, C., Smith, S., Madhavapeddy, A., Hand, S .: CIEL: универсальный механизм выполнения для распределенных вычислений потока данных. В: Материалы 8-й конференции USENIX по проектированию и внедрению сетевых систем, NSDI 2011, стр. 113–126. Ассоциация USENIX, Беркли (2011). http://dl.acm.org/citation.cfm?id=1972457.1972470

32. Нагаракатте, С., Чжао, Дж., Мартин, MMK, Zdancewic, S .: SoftBound: очень совместимая и полная безопасность пространственной памяти для C. В: Хинд, М., Диван, А. (ред.) Конференция ACM SIGPLAN 2009 года по программе разработки и внедрения языков программирования, PLDI 2009, 15–21 июня 2009 г., Дублин, Ирландия, с. 245–258. ACM (2009). https://doi.org/10.1145/1542476.1542504

33. Перес Ф., Грейнджер Б.Е., Хантер Дж.Д .: Питон: экосистема для научных вычислений. Comput. Sci. Eng. 13 (2), 13–21 (2011). https://doi.org/10.1109/MCSE.2010.119

34. Петричек Т., Гуэрра Г., Сайм Д .: Виды из данных: составление структурированных данных первоклассных граждан в F#. В кн .: Материалы 37-й конференции ACM SIGPLAN по разработке и внедрению языков программирования, PLDI 2016, с. 477–490. ACM, Нью-Йорк (2016). https://doi.org/10.1145/2908080.2908115

35. Ричи, Д .: Развитие языка Си. В: Lee, J.A.N., Sammet, J.E. (eds.) Конференция по истории языков программирования (HOPL-II), Препринты, 20–23 апреля 1993 года, Кембридж, Массачусетс, США, стр. 201–208. ACM (1993). https://doi.org/10.1145/154766.155580

36. Руби С., Коупленд Д.Б., Томас Д.: Agile Web Development с Rails 5.1. Прагматичная книжная полка, Роли (2017)

37. Ruwase, O., Lam, M.S .: Практический динамический детектор переполнения буфера. В: Материалы Симпозиума по безопасности сетей и распределенных систем, NDSS 2004, Сан-Диего, Калифорния, США. Интернет-общество (2004). http://www.isoc.org/isoc/conferences/ndss/04/proceedings/Papers/Ruwase.pdf

38. Рыжик Л., Уокер А., Кейс Дж., Легг А., Рагхунатх А., Штумм М., Видж М .: Синтез драйвера, управляемого пользователем. В: Flinn, J., Levy, H. (eds.) 11-й симпозиум USENIX по проектированию и внедрению операционных систем, OSDI 2014, 6–8 октября 2014 г., Broomfield, CO, USA, pp. 661–676. Ассоциация USENIX (2014). https://www.usenix.org/conference/osdi14/technical-sessions/presentation/ryzhyk

39. Сакамото М., Бентон М., Вендитти. С .: Динозавры погибли за десятки миллионов лет до своего окончательного вымирания. Proc. Natl. Акад. Sci. 113 (18), 5036–5040 (2016)

40. Sch.afer, М .: Инструменты рефакторинга для динамических языков. В: Материалы пятого семинара по инструментам рефакторинга, WRT 2012, стр. 59–62. ACM, Нью-Йорк (2012). https://doi.org/10.1145/2328876.2328885

41. Seibel, P .: Кодеры за работой, 1-е изд. Апресс, Беркли (2009)

42. Северанс, С.: Javascript: проектирование языка за 10 дней. Компьютер 45, 7–8 (2012)

43. Siek, J.G., Taha, W .: Постепенная типизация для функциональных языков. В: Материалы семинара по схеме и функциональному программированию, стр. 81–92 (2006)

44. Steffen, J.L .: Добавление проверки во время выполнения к переносимому C-компилятору. Softw. Практ. Exp. 22 (4), 305–348 (1992). https://doi.org/10.1002/spe.4380220403

45. Такикава, А., Фелтей, Д., Гринман, Б., Нью, М.С., Витек, Дж., Феллайзен, М .: Мертвая ли постепенная типизация? В: Бодик Р., Мажумдар Р. (ред.) Материалы 43-го ежегодного симпозиума ACM SIGPLAN-SIGACT по принципам языков программирования, 20–22 января 2016 г., POPL 2016, Санкт-Петербург, Флорида, США, С. 456–468. ACM (2016). https://doi.org/10.1145/2837614.2837630

46. Тобин-Хохштадт, С., Феллайзен, М .: Межъязыковая миграция: от сценариев к программам. В: Tarr, PL, Cook, WR (eds.), Компаньон для 21-й ежегодной конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям, OOPSLA 2006, 22–26 октября 2006, Портленд, Орегон, США, стр. 964–974. ACM (2006). https://doi.org/10.1145/1176617.1176755

47. Унгар Д., Чамберс К., Чанг Б.В. Хольцле У .: Организация программ без классов. Lisp Symb. Comput. 4 (3), 223–242 (1991). https://doi.org/10.1007/BF01806107.



Перевод: Д.Ю.Караваев. 14.11.2019

Опубликовано: 2019.11.25, последняя правка: 2019.11.25    21:57

Оцените

Отзывы

     2019/11/29 19:10, MihalNik          # 

Заключительная часть переведена ужасно. Ощущение как от гуглоперевода.
От себя: кто такой Ландин, наверное, сейчас никто не помнит или, скорее, вообще не слышал, а о едином универсальном языке вряд ли мечтает.
Шутку можно словить в 3-ей части:

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

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

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

     2019/12/03 22:45, Автор сайта          # 

Ощущение как от гуглоперевода

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

кто такой Ландин, наверное, сейчас никто не помнит

Наверное, это тот случай, когда у разных стран разные герои. Мы не знаем, чем знаменит Ландин, а они — чем известен Шура-Бура.

Добавить свой отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

●  Двадцать тысяч строк кода, которые потрясут мир?

●  Почему владение/заимствование в Rust такое сложное?

●  Масштабируемые архитектуры программ

●  Почему Хаскелл так мало используется в отрасли?

●  Программирование исчезнет. Будет дрессировка нейронных сетей

●  Бесплатный софт в мышеловке

●  Исповедь правового нигилиста

●  Русской операционной системой должна стать ReactOS

●  Почему обречён язык Форт

●  Программирование без программистов — это медицина без врачей

●  Электроника без электронщиков

●  Программисты-профессионалы и программирующие инженеры

●  Статьи Дмитрия Караваева

●●  Идеальный транслятор

●●  В защиту PL/1

●●  К вопросу о совершенствовании языка программирования

●●  О реализации метода оптимизации при компиляции

●●  О реализации метода распределения регистров при компиляции

●●  О распределении памяти при выполнении теста Кнута

●●  Опыты со стеком или «чемпионат по выполнению теста Кнута»

●●  О размещении переменных в стеке

●●  Сколько проходов должно быть у транслятора?

●●  Чтение лексем

●●  Экстракоды при синтезе программ

●●  Об исключенных командах или за что «списали» инструкцию INTO?

●●  Типы в инженерных задачах

●●  Непрерывное компилирование

●●  Об одной реализации специализированных операторов ввода-вывода

●●  Особенности реализации структурной обработки исключений в Win64

●●  О русском языке в программировании

●●  Формула расчета точности для умножения

●●  Права доступа к переменным

●●  Заметки о выходе из функции без значения и зеркальности get и put

●●  Модификация исполняемого кода как способ реализации массивов с изменяемыми границами

●●  Ошибка при отсутствии выполняемых действий

●●  Скорость в попугаях

●●  Крах операции «Инкогнито»

●●  Предопределённый результат

●  Следующие 7000 языков программирования

●●  Что нового с 1966 года?

●●  Наблюдаемая эволюция языка программирования

●●  Ряд важных языков в 2017 году

●●  Слоны в комнате

●●  Следующие 7000 языков программирования: заключение

Компьютерный юмор

Новости и прочее




Последние отзывы

2019/12/08 17:48 ••• Noname
Почему обречён язык Форт

2019/12/05 23:29 ••• Автор сайта
Слоны в комнате

2019/12/03 22:45 ••• Автор сайта
Следующие 7000 языков программирования: заключение

2019/12/03 22:36 ••• Автор сайта
Наблюдаемая эволюция языка программирования

2019/11/30 20:55 ••• Сергей
Каким должен быть язык программирования?

2019/11/09 21:27 ••• kt
Программирование без программистов — это медицина без врачей

2019/11/07 10:58 ••• kt
Признаки устаревшего языка

2019/10/28 23:55 ••• Автор сайта
Типы в инженерных задачах

2019/10/15 16:32 ••• kt
Модификация исполняемого кода как способ реализации массивов с изменяемыми границами

2019/10/07 14:15 ••• Автор сайта
О наименовании проекта и языка программирования

2019/09/19 15:23 ••• kt
Некошерный «goto»

2019/09/13 16:38 ••• Автор сайта
Программирование исчезнет. Будет дрессировка нейронных сетей