Если изобрести язык программирования 21 века

Original author: Oleksandr Kaleniuk
  • Translation
Автор материала рассуждает о проблемах современных языков программирования и о том, какими путями можно исправить недостатки.


Только за последние 18 лет люди придумали множество языков, среди которых, вероятно, самыми популярными стали Swift, Kotlin и Go. При этом отличительная черта языка программирования 21 века — это отсутствие каких-либо отличительных черт. Самое приятное в работе с такими языками — за изучением одного из них можно провести выходные и под конец заявить, что вам удалось освоить популярную новинку, по факту же не узнав ничего нового. В них действительно нет ничего нового. Все современные языки созданы на основе какой-либо правильной и проверенной формулы, имя которой, вероятнее всего, Objective-C, Java или C.

«Отсутствие новизны» можно считать ценной чертой, но подобная ситуация вызывает один вопрос. Действительно ли перед нами языки нового, 21 века, или все это — просто отражение плохих привычек программирования 20 века?

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

Долой синтаксис!


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

Ввод текста с клавиатуры уже не представляет сложностей. Мы не обязаны ставить себя в положение, когда необходимо угадывать значение синтаксиса. Штуки вроде (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#) — очень краткий и емкий формат записи (это, к слову, настоящий фрагмент кода в реальном языке), но он никаким образом не улучшает читабельность. И, что важнее, его сложно «прогуглить» или найти на stackoverflow.

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

Нечто вроде

FILE * test_file = fopen("/tmp/test.txt", "w+");

должно преобразиться в

create file /tmp/test.txt for input and output as test_file

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

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

Долой встроенные типы!


Вы наверняка знакомы с парадоксами JavaScript. Например, такими:

> 10.8 / 100
0.10800000000000001


Этот результат характерен не только для JavaScript. И это вовсе не парадокс, а образец абсолютно корректного следования всеми уважаемому стандарту IEEE 754. Подобная реализация чисел с плавающей запятой встречается практически во всех архитектурах. И она не так плоха, учитывая, что мы пытаемся втиснуть бесконечное множество вещественных чисел в 32, 64 или 256 бит.

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

Похожие особенности есть не только у чисел с плавающей запятой. Встроенные целые числа реализованы не лучше. Знаете ли вы, что произойдет, если попытаться сложить два таких 16-разрядных числа?

0xFFFF + 0x0001

Точного ответа не даст никто. Чутье подсказывает, что переполнение даст 0x0000. Однако такой исход не задокументирован ни в одном мировом стандарте. В обработке этой операции все ориентируются на подход C и семейства процессоров x86. В качестве альтернативных вариантов может получиться 0xFFFF или будет вызвано прерывание, или некий специальный, указывающий на переполнение бит будет сохранен в особом месте.

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

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

1.000 / 3.000 = 0.333
0001 + 9999 = overflowed 9999
0.001 / 2 = underflowed 0


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

Разве такие вычисления не будут работать медленнее? Да, будут. Но спросите себя: как часто вам приходится программировать высокопроизводительные вычисления? Полагаю, что если вы не специалист в этой области, то очень редко. А если вы и занимаетесь подобными задачами, то пользуетесь для этих целей специализированным оборудованием и компиляторами. Насколько я могу судить, типичный программист 21 века нечасто решает дифференциальные уравнения.

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

Долой практику метаязыков!


Существуют замечательные языки, придуманные не для выполнения задач, а для создания языков, которые способны их выполнять. Racket, Rebol и Forth — лишь несколько примеров. Они все мне нравятся, играть с ними — чистое удовольствие. Но, как вы наверное догадались, удовольствие, получаемое от работы с языком, — не главный критерий, делающий язык универсальным и популярным.

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

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

Ребята, пишущие на Lisp, прошли через это в 80-х. Они поняли, что чем больше прикладных элементов языка будут стандартизированы, тем лучше. Так на свет появился Common Lisp.

И он оказался огромен. Стандарт INCITS 226–1994 насчитывает 1153 страницы. Этот рекорд 17 лет спустя побил только C++ со стандартом ISO/IEC 14882:2011 (1338 страниц). С++ приходится тащить за собой неподъемный багаж наследия, хотя он не всегда был таким большим. Common Lisp был создан по большей части с нуля.

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

Конечно, поддерживать баланс между размерами и прикладной пригодностью непросто. Опыт C++ на практике показал как это трудно. Полагаю, чтобы достичь нужного равновесия, язык 21 века должен условно затачиваться под определенную прикладную область. Поскольку больше всего проблем сейчас возникает именно в области бизнес-приложений, языку, вероятно, следует ориентироваться на проблемы бизнеса, а не на разработку игр или веб-дизайн.

Итак...


Язык 21 века должен быть бизнес-ориентированным, использовать понятные языковые выражения и не зависеть от встроенных типов. Здорово, что такой язык уже существует! Как думаете, о чем идет речь?

Да, это COBOL.

Это один из первых высокоуровневых языков, сегодня по большей части забытый. Вынужден признаться, что я намеренно описал древние фичи COBOL’a как ультрасовременные и невероятно многообещающие. И сделал я это, чтобы показать одну вещь. Код пишут не языковые фичи. Это делаете вы.

Наивно думать, что язык отвечает за качество кода, и что добавление некоторых прибамбасов (или их удаление) может автоматически все улучшить. В свое время программисты не взлюбили Fortran и COBOL, потому изобрели C++ и Java, чтобы в итоге прийти к ситуации, когда 20 или 30 лет спустя они тоже всем разонравились.

По моим ощущениям, корень проблемы кроется где-то в области социологии и психологии, но не программирования. Действительно ли языки нам настолько не нравятся? И разве мы довольны окружением, в котором работаем? Windows уязвим, Visual Studio работает слишком медленно, из Vim’а невозможно выйти. На самом деле именно эти вещи вызывают недовольство, а не творческий процесс сам по себе.

Но ведь всегда надо найти виноватого. Будучи инженерами ПО, частично несущими ответственность за то, какими паршивыми бывают программы, мы не станем обвинять себя, верно? Поэтому ищем изъяны в инструментах. Давайте изобретать новые COBOL’ы до тех пор, пока в один прекрасный день солнце не начнет светить ярче, птицы не запоют громче, а Windows не начнет загружаться за 2 секунды.

Но, скорее всего, этот день никогда не настанет.

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

image
Wirex
38.42
Мобильный банкинг нового поколения
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 120

    +30
    Автор воды налил и поскользнулся.
      +2
      я аж пошел проверять календарь, вдруг я до апреля проспал? 0_о
        +1
        Мне показалось автор налил чего-то покрепче
        +11
        create file /tmp/test.txt for input and output as test_file

        Это же ужасно. Пример на С выглядит гораздо лучше и проще.
        Если так уж хочется более «человечного» синтаксиса, то мне больше нравится Python:
        with open("/tmp/test.txt", "w") as test_file:
        ...
        
          –8

          Я бы сделал так:


          let test_file <=> File /tmp/test.txt

          Двусторонняя стрелка делает эксклюзивный захват ресурса, позволяя читать и писать. Правосторонняя — только запись. Левосторонняя — только чтение. Равенство — просто ссылка без возможности читать/писать.

            +4
            А как же например стрелками записать «a+», «wb» и так далее?
              +3
              Все авторы новых языков считают предыдущих идиотами. Но только реальные языки со всеми их некрасивостями обкатывались на реальных задачах, а не на примере кода первого месяца курса введения в программирование.
                –2
                + — плюсиком и указывать. А b не нужен, это DOS'овский пережиток.
                  +1
                  emoji, очевидно же =))
                    +1
                    И stories, stories вставить в среду разработки
                    0
                    А какое отношение эта криптография имеет к захвату ресурса? Хотите проверить, что файл уже есть — напишите if. Хотите очистить файл — сделайте clear. Хотите переместить указатель в начало/конец/середину — используйте seek.
                      0
                      Проверка файла на существование с помощью if подвержена гонкам.
                        0
                        Каким ещё гонкам? Захватить блокировку сможет лишь один процесс.
                          0

                          Да простым:


                          if (файл_существует()) {
                              открыть_файл(); // упс, а его уже успели удалить
                          } else {
                              создать_файл(); // упс, а его уже кто-то создал...
                          }
                            0
                            #Захватили блокировку на запись
                            let test_file => File /tmp/test.txt
                            
                            # Если файл существует - громко ругнулись
                            switch
                                when not test_file exists
                                then panic \Required file {path} isn't exists!
                                    path <= test_file path
                            
                            # Записали в файл пустую строку, что приведёт к его созданию
                            test_file <= \

                            Обратите внимание, что мы просто не можем проверить файл на существование, не взяв блокировку.

                              0

                              То есть <=> не создает нового файла? А как в таком случае создавать новые файлы?

                                0
                                Вы не могли бы замэпить это все в системные вызовы, на каком шаге что происходит? А то опять какой-то сферический конь
                                  –3
                                  Я не спец по системным вызовам. Вы не можете восстановить их по комментариям?
                                    0

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

                                      –1
                                      File структуру создаёт. Блокируют стрелочки.

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

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

                                        То есть если две программы попробуют выполнить код выше одновременно, что первая выведет "Required file {path} isn't exists!", а вторая выведет "File {path} already opened by another program"?


                                        Счастливой отладки, блин...

                                          –2
                                          Если файл не существует, то первая создаст пустой файл, а вторая подвиснет в ожидании его освобождения, после чего упадёт. Если существует, то обе упадут с одинаковым сообщением. Не вижу тут никаких проблем с отладкой.
                      0
                      let test<=>file <=> File test file.txt

                      Досвиданья.
                        0
                        Может развернёте мысль?
                    • UFO just landed and posted this here
                        0

                        Совсем не похоже на Basic, разве что слово open общее. У оператора with в Питоне есть важная фича, которой не было в Basic: автоматическое закрытие файла.


                        Аналогом вашей строчки на Бейсике была бы вот такая строчка на Питоне:


                        _1 = open("/tmp/test.txt", "w")
                        • UFO just landed and posted this here
                          +1
                          А мне больше напомнило AppleScript с его native-language конструкциями. %)
                          tell application "Finder" to open file "foobar"
                          0
                          Сами вы ужасный, со своими птичьими конструкциями. Программа должна быть легкочитаемой, а не семантически мифически-правильно написана(привет Rust! со своими восклицательными знаками!!!)
                            0
                            Что именно в строке выше мешает читать программу?
                              0

                              Да-да, привет, Rust:


                              use std::fs::OpenOptions;
                              
                              let file = OpenOptions::new().write(true)
                                                           .create_new(true)
                                                           .open("foo.txt")
                                                           .expect("Something went wrong opening the file");
                            +15
                            глаз цепляется за спец. символы, благодаря чему ты сразу читаешь именно ту часть строки которая интересует тебя в данный момент. Когда спец символов нет, читать строки надо полностью и внимательно, а это ужасно сказывается на производительности
                              +5
                              +1. Когда-то математические выкладки записывались тупо текстом. А потом появлялись знаки математических операций, скобки и т.п. И новые математики охотно использовали именно такую запись именно потому, что с ней математика становилась проще и яснее.
                              +4
                              Давайте изобретать новые COBOL’ы до тех пор, пока в один прекрасный день солнце не начнет светить ярче, птицы не запоют громче

                              Зачем изобретать, посмотрите на язык ABAP, потомок того же COBOL'a и ужаснитесь.
                                +2
                                Тоже хотел написать это автору. Если ему нравится COBOL, то благословенный ентерпрайз ждёт его в лице разработки для SAP систем )).
                                Я бы посмотрел что он скажет после года разработки.
                                  –1
                                  Вы текст дальше то читали?
                                  Давайте изобретать новые COBOL’ы до тех пор, пока в один прекрасный день солнце не начнет светить ярче, птицы не запоют громче, а Windows не начнет загружаться за 2 секунды.

                                  Но, скорее всего, этот день никогда не настанет.

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

                                  Автор как раз и говорит что новые COBOL'ы изобретать не надо.
                                  +1
                                  create file /tmp/test.txt for input and output as test_file
                                  Но ведь уже есть AppleScript.
                                    0
                                    Про COBOL хорошая шутка.
                                    Шутки шутками, а идея программирования на основе АИ давно назрела. Что бы не писать прогу самому, а объяснить АИ концепт программы живым языком. Далее пусть он пыхтит, кодит. В принципе не ново. Та же диалоговая система, только на более высоком уровне.
                                      0

                                      С FrontPage в свое время получилось не очень.

                                        0
                                        Вы прямо про АЛМИР-65 вспомнили. Где не существовало понятия размерности, к примеру. Воистину говорю — число могло иметь ЛЮБОЙ размер, абы памяти хватило.
                                        Для интересующихся: ВСЁ описание языка (умеющего строить таблицы, графики и брать интегралы) — 25 страниц!
                                        elib.ict.nsc.ru/jspui/bitstream/ICT/544/1/MIR.pdf

                                          +1
                                          Ну, то есть, когда сейчас при разработке больших систем очень сложно разобраться в паутине легаси кода, теперь там будет нейросеть, которая вообще не пойми что делает?
                                            0
                                            Что бы не писать прогу самому, а объяснить АИ концепт программы живым языком.

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


                                            Далее пусть он пыхтит, кодит.

                                            Проблему останова тоже пусть сам заодно решит?

                                            +8
                                            Если весь код будет в форме лексических предложений, то будет ни капельки не легче.
                                            Вот законы у нас написаны «обычным» языком, но правильно их читать и применять могут «не только лишь все, мало кто может это».
                                            И замечу, что язык SQL придумали специально для менеджеров, чтоб они могли сами писать запросы в базы, а они всё равно туповаты, и теперь специальные люди пишут эти запросы.
                                              0

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

                                                0
                                                Идею с AI-кодером легко развить:
                                                По известной формуле (Вирт): алгоритмы + структуры данных= программы,
                                                где алгоритмы зачастую записывают на псевдо-коде. Если алгоритм описан на естественном языке, то его можно переписать на подходящем псевдо-коде. Аналогично со структурами данных — предложено много способов формального, но достаточно общего их описания. Далее наш инструмент получая на входе алгоритмы и структуры данных (в общем формальном описании) на выходе должен выдать программу на существующем или новом ЯП. В общем случае задача не кажется невыполнимой даже для нынешних технологий. Конечно, нужно учесть ряд деталей. Так описание алгоритма зачастую бывает недостаточно подробным. В этом случае ИМХО может быть применен диалоговый подход: наш инструмент может запросить уточнение.
                                                  +2
                                                  Далее наш инструмент получая на входе алгоритмы и структуры данных (в общем формальном описании) на выходе должен выдать программу на существующем или новом ЯП.
                                                  Взаимоисключающие параграфы же.
                                                  Если описание формальное, то оно делается на некотором формальном языке.
                                                  А если мы не используем ни один из существующих или новых ЯП, то как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально? Максимум, полуформально. А полуформальная запись всегда субъективна: если некое описание одна группа лиц считает полуформальным (т.е. они между собой убеждены, что способны описание переложить на любой известный ЯП), то третье лицо вполне может сказать, что это описание имеет не больше смысла, чем сепульки или глокая куздра.

                                                  P.S. статья и некоторые комментарии натолкнули меня на мысль, что все эти ЯП без синтаксиса и ИИ-кодеры могут иметь смысл, только если мы принципиально отказываемся от идеи программы с контролируемой известной логикой, т.е. разрешаем программе быть потенциально непредсказуемой: как человек всегда может (т.е. нет гарантии обратного) неправильно истолковать слова собеседника, так и программа всегда может сделать что-то принципиально отличающееся от того, что программист (по его мнению) написал. Без понятия, какой класс задач будет решаться эффективнее при таком подходе.
                                                    0
                                                    А если мы не используем ни один из существующих или новых ЯП, то как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально?

                                                    Мы можем описать её функцию и интерфейс: «Нужна такая штука для создания заметок с голосовым вводом, чтобы их можно было приклеивать на десктоп». Далее можно сделать несколько итераций и уточнить, в итоге умный ИИ сообразит как это лучше сделать, оперируя ему известными алгоритмами, структурами данных и API для целевой системы.

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

                                                      0
                                                      Нпр., алгоритм Эратосфена из вики:
                                                      Для нахождения всех простых чисел не больше заданного числа n, следуя методу Эратосфена, нужно выполнить следующие шаги:

                                                      Выписать подряд все целые числа от двух до n (2, 3, 4, …, n).
                                                      Пусть переменная p изначально равна двум — первому простому числу.
                                                      Зачеркнуть в списке числа от 2p до n считая шагами по p (это будут числа кратные p: 2p, 3p, 4p, …).
                                                      Найти первое незачёркнутое число в списке, большее чем p, и присвоить значению переменной p это число.
                                                      Повторять шаги 3 и 4, пока возможно.
                                                      Где здесь ЯП? Всё однозначно без ИИ, итераций, интерфейсов и т.д.
                                                        0

                                                        Ок, ИИ делает программу, вы запускаете её, и она не выводит ничего :)

                                                          0
                                                          и она не выводит ничего :)

                                                          Простите, не понял в чем шутка юмора: почему ничего не выводит?
                                                            –1

                                                            Потому что нигде не сказано, какие именно значения алгоритм должен возвращать.

                                                              0
                                                              ИМХО сказано:
                                                              Для нахождения всех простых чисел не больше заданного числа n

                                                              т.е. все простые числа не больше заданного числа n. Но это только мое «ИМХО», поэтому задайте вопрос на соответствующую страницу обсуждения статьи Википедии.
                                                                0

                                                                Да, но нигде в алгоритме не говорится, какие именно числа нужно добавлять в возвращаемое множество. Речь об этом.

                                                                  0
                                                                  В самом начале сказано: «Выписать подряд все целые числа от двух до n», дальше нужно только зачеркивать.
                                                                    0

                                                                    Это не очевидно. Я уже не говорю об алгоритмической эффективности операции зачёркивания и вообще её формализации.

                                                                      0
                                                                      Это не очевидно.
                                                                      Всем читателям и редакторам вики очевидно, а Вам не очевидно. Печально. Но попробуйте заменить слово «операции зачёркивания» на «операции удаления» — так понятнее? — Из ОЗУ или из файла можно удалять очень эффективно. BTW алгоритм был предложен, когда про ОЗУ, файл и комп никто не знал, а до сих пор является очень важным алгоритмом.
                                                                        0
                                                                        Из ОЗУ или из файла можно удалять очень эффективно.

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

                                                                          0
                                                                          Не обязательно. Нпр., обнуляю элемент и игнорирую нули. А потом кто сказал, что речь о массиве?
                                                                            0
                                                                            Угу, и теперь вместо прямого доступа по индексу за O(1) имею доступ за O(n), потому что надо же нули пропускать.

                                                                            Офигенно.
                                                                  –1
                                                                  Ну он нашел и молодец. Про то, что он их должен пользователю показывать, или возвращать в место вызова, ничего не сказано.
                                                                    0
                                                                    У Вас проблемы с русским языком? Не понятно написано «Для нахождения»? Сравните с рецептом приготовления чая: для приготовления чая нужно взять чайник, налить в него воды, поставить на огонь и т.д. В каком рецепте пишут кто что должен возвращать? ;)
                                                                    PS Выше я уже советовал спросить в вики, т.к. это их текст, а я только цитировал.
                                                                      0

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


                                                                      а я только цитировал

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


                                                                      В общем случае задача не кажется невыполнимой даже для нынешних технологий.
                                                                      Всё однозначно без ИИ, итераций, интерфейсов и т.д.
                                                                        –1
                                                                        просто вы додумываете недосказанности на основе жизненного опыта.
                                                                        Нет, это Вы додумываете и профанируете принципы абстрактного алгоритма, навязывая ему дополнительную частную цель I/O. На самом деле цель "нахождение всех простых чисел не больше заданного числа n" и всё — точка. А что делать с найденными числами — это вопрос другого алгоритма, который м.б. скомпонован с данным. Алгоритм Эратосфена настолько общий, что работает не только на компе, но и на листе бумаги, нпр. Но и в компе, м.б. не нужно выводить все найденные числа из ОЗУ или из файла, м.б. передать область ОЗУ другому алгоритму для других вычислений, а в случае файла — просто не удалять этот файл, а потом читать другой программой при необходимости. Моим словам, на которые Вы указали, это никак не противоречит.
                                                                          0

                                                                          Так если вы все так подробно опишете, то это и будет программа на языке программирования. И даже строго в рамках того, что написано, есть неоднозначности. Какого размера числа использовать — 4-байтовые, 8-байтовые, произвольной точности? Что если мы захотим найти числа до 2^80? Надо сообщить о нехватке оперативной памяти, перенести сохранение на диск, или сразу на диск писать? И таких нюансов много, потому и не сделали еще с нынешними технологиями.

                                                                            0
                                                                            Так если вы все так подробно опишете, то это и будет программа на языке программирования.
                                                                            На каком ЯП? На C++ или на JS?
                                                                              0
                                                                              Ну смотря как запишете. Может это будет новый язык N++, а этот якобы AI будет просто компилятором этого языка. Как TypeScript, который компилируется в JS.
                                                                                0
                                                                                Ну смотря как запишете.

                                                                                Запишу очень просто. Нпр., Вы спросили:
                                                                                Какого размера числа использовать — 4-байтовые

                                                                                Отвечаю: для моей задачи хватит 4-х.
                                                                                Повторяю вопрос: какой это ЯП?
                                                                                  0
                                                                                  А где обработчик, который поймет это предложение, чтобы выдать нужный код на C++ или JS? Пока на это способен только естественный интеллект, и то если прочитает предыдущие комменты. Вот если вы опишете принципы такого обработчика, формат как задавать ответы на все указанные вопросы, причем для произвольных задач, и назовете его «Система X», то правила составления этих ответов будут называться «язык программирования системы X».
                                                                                    0
                                                                                    правила составления этих ответов будут называться «язык программирования системы X».
                                                                                    Нет. Это будет называться язык метод описания данных. Я начал с цитаты формулы:
                                                                                    (Вирт): алгоритмы + структуры данных= программы


                                                                                    По конкретному вопросу: 4-байтовые или 8-байтовые? — Элементарно. По умолчанию положим 4-байтовые. Но в настройках можно изменить. А еще возможен диалог, списки переменных целевой программы с выбором их типов.
                                                                                      0
                                                                                      Это будет называться метод описания данных

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


                                                                                      А еще возможен диалог, списки переменных целевой программы с выбором их типов.

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


                                                                                      То, что вы описываете — язык, приближенный к естественному, и куча настроек — похоже на SQL + СУБД. Это тоже программирование.

                                                                                        0
                                                                                        С тем же успехом настройку Ворда или написание ТЗ для заказа фрилансеру можно назвать программированием.
                                                              0
                                                              Нет, должна выводить 42 )).
                                                          0
                                                          Взаимоисключающие параграфы же.
                                                          Нет. Всё четко: см., нпр., вики: отличая программы от алгоритма.
                                                          как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально?
                                                          Что такое формальное описание программы? Есть исходный код программы на ЯП — этого обычно достаточно. Формальное описание алгоритма — это, нпр., его запись на псевдокоде.
                                                          полуформальная запись всегда субъективна
                                                          Факты говорят иное: есть солидные научные журналы (по математике, CS и т.д.), которые публикуют новые алгоритмы так, что все читатели этих журналов (речь только о читателях, обладающих необходимой для чтения квалификацией) понимают эти алгоритмы совершенно однозначно.
                                                        +1
                                                        Если весь код будет в форме лексических предложений, то будет ни капельки не легче.

                                                        С каждым разом все больше убеждаюсь что многие не читают статьи телеком. Увидят что-то в тексте, зацепятся и давай комментить.
                                                        Смысл статьи в том и есть, что новые COBOL'ы не нужны.
                                                          0
                                                          С каждым разом убеждаюсь, что многие прочтут статью, лучше всех поймут главную идею статьи, увидят что-то в тексте, зацепятся и давай искать комментарии которые им срочно нужно прокомментить.
                                                          Смысл комментария не в том, что нужны новые COBOL'ы или не нужны.
                                                            +1
                                                            Не, не так. Мои личные ощущения — это как когда человек прокомментировал с сарказмом, а кто-то его нe понял и начинает серьезно ему отвечать. Только тут, к сожалению, таких комментов 90%. Возможно перевод не слишком удачный, я в оригинале читал, там как-то лучше воспринимается.

                                                            Скрин из оригинальной статьи



                                                            Смысл автора явно в том что не нужно изобретать новые языки акцентирующие свое внимание на «революции» в самом процессе написания кода. Лучше концентрировать свое внимание на процессе разработки, на том как код работает, и решать важные проблемы не акцентируя внимания на самом языке. Языков и так достаточно. Автор взял COBOL как пример, все описанные им пункты — были мотивацией для создания кобола, и где теперь кобол?
                                                              0
                                                              Ну отлично. Так что теперь, нужно для каждого поста на Хабре еще и оригинал читать в обязательном порядке? Ну и в чем в таком случае смысл переводов?

                                                              Предлагаю для Хабра новый формат: пост-ссылка на оригинал, под постом — комментарии на русском :-)
                                                                0
                                                                Так что теперь, нужно для каждого поста на Хабре еще и оригинал читать в обязательном порядке?

                                                                По-моему достаточно прочитать статью до конца. А не первые 10% читаешь, потом нa искосок.

                                                                Предлагаю для Хабра новый формат: пост-ссылка на оригинал, под постом — комментарии на русском :-)

                                                                Раньше были посты ссылки кстати )
                                                                  0
                                                                  Да нет, тут перевод настолько «качественный», что кажется будто автор предлагает переходить на COBOL. Это после второго внимательного прочтения…
                                                                    0
                                                                    Boomburum вот над чем надо думать для будущей мультиязычности на habr.com :)
                                                                      0
                                                                      Ну посты-ссылки вряд ли вернутся, остальное… да, собственно, на плечах пользователей тоже: одни пишут статьи или переводы, другие — читают и оценивают, обсуждают :)
                                                        +4
                                                        Я вообще не понял, с чем борется автор и как.

                                                        И это вовсе не парадокс, а образец абсолютно корректного следования всеми уважаемому стандарту IEEE 754.

                                                        Числа с плавающей запятой в интерпретации IEEE — вообще не числа. Математика требует ассоциативности от операции их сложения.

                                                        Математика не требует. Требуется то, что описано в стандарте. Т.к. это «вообще не числа», то и непротиворечивые правила можно вводить свои, которые, собственно, были введены в стандарте. Притом оно — неплохое приближение действительных чисел «с обеих сторон» в ограниченных условиях. Если на пальцах, то по своей сути оно ближе к сути действительных чисел: как в теории действительных чисел (см. матан) есть неопределённости, бесконечности и всякие стремления к нулю слева, так и в реализации стандарта они есть. Если реально нужны не действительные числа, а рациональные, то нужно использовать готовые/писать свои реализации приближения рациональных, а не натягивать сову.

                                                        Похожие особенности есть не только у чисел с плавающей запятой. Встроенные целые числа реализованы не лучше.

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

                                                        Чутье подсказывает, что переполнение даст 0x0000. Однако такой исход не задокументирован ни в одном мировом стандарте. В обработке этой операции все ориентируются на подход C и семейства процессоров x86.

                                                        Так получается, что подход C — один из мировых стандартов, где исход задокументирован.

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

                                                        А это — другие стандарты.

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

                                                        И, собственно, главный вопрос: а как новый язык решит эту проблему? [Здесь комикс про универсальный стандарт]

                                                        overflowed 9999
                                                        underflowed 0

                                                        Что это вообще такое? Если состояния, то, собственно, чем оно лучше NaN и +Inf, когда мы получаем оспариваемое состояние? Если поведение, то чем оно лучше переполнения, когда мы получаем оспариваемое поведение? Да и, собственно, подобные обрезки точности можно просто реализовать на базовых типах в готовых языках, для этого не нужно изобретать ещё один язык, или они даже есть из коробки: тип DECIMAL(N,M) в SQL или currency в некоторых языках.

                                                        Разве такие вычисления не будут работать медленнее? Да, будут.

                                                        Минус пласт пользователей языка.

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

                                                        Минус ещё один пласт пользователей языка.

                                                        Т.е. в итоге мы получаем ещё один язык 21 века, у которого другой синтаксис, который вводит новые костыли, новые стандарты и правила, но при этом не отказывается от костылей, стандартов и правил 20 века, и реализации на котором медленнее? Можно не надо?
                                                          0
                                                          Согласен. Людям не нужен еще один способ программы сообщения об ошибке — им нужно чтобы самой ошибки не было. А заменять одну ошибку на другую не больно то имеет смысл.
                                                            0
                                                            Язык языком, но поведение чисел при переполнении определяется в первую очередь железом, и если оно не обнуляет при целочисленной операции а выставляет признак переполнения в неком регистре и оставляет в переменной максимальное значение а другое железо оставляет и признак переполнения и даёт ноль — это в стандарт языка никак не внесёшь т.к. есть зависимость поведения от конкретного железа на котором будет выполняться программа написанная на языке. Речь идёт о достаточно низкоуровневых языках, где делать обработку события переполнения и переопределять результат чтобы он не зависел от железа довольно накладно. Речь идёт о разнице скоростей в 10 и более раз.
                                                              0
                                                              Блин, да дочитайте до конца статью!!!
                                                              Вы столько тут настрочили, а автор как раз и говорит об этом.
                                                              Последний абзац:
                                                              Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов. Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности. Вместо языков, входящих и выходящих из моды, всегда есть некие фундаментальные вещи, заслуживающие постоянного переосмысления.
                                                              0
                                                              Почему бы автору не пороть чушь делать спорные заявления, а сесть и попытаться реализовать все его хотелки в собственном «языке программирования 21 века»? Уверен, что некоторые из его убеждений в процессе написания изменятся.

                                                              Разве такие вычисления не будут работать медленнее? Да, будут. Но спросите себя: как часто вам приходится программировать высокопроизводительные вычисления? Полагаю, что если вы не специалист в этой области, то очень редко. А если вы и занимаетесь подобными задачами, то пользуетесь для этих целей специализированным оборудованием и компиляторами. Насколько я могу судить, типичный программист 21 века нечасто решает дифференциальные уравнения.

                                                              Типичный программист 21 века делает так:
                                                              // performance project main.go
                                                              package main
                                                              
                                                              func main() {
                                                              	for {
                                                              	}
                                                              }

                                                              И съедает один поток процессора полностью. Но зачем оптимизировать, когда можно купить процессор мощнее?
                                                                +1
                                                                Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов. Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности. Вместо языков, входящих и выходящих из моды, всегда есть некие фундаментальные вещи, заслуживающие постоянного переосмысления.
                                                                  0
                                                                  Я тоже много чего мог бы захотеть, но вот только существующие технологии накладывают на мои «хотелки» существенные ограничения. И я сознаю, что автор каждого языка программирования хотел написать самый удобный, легкий в изучении и быстрый язык программирования, но что из этого получилось мы хотя бы можем видеть. А тут у автора только мечтания и даже не намека на реализацию. Как у Кирилла.
                                                                0
                                                                В свое время программисты не взлюбили Fortran и COBOL, потому изобрели C++ и Java

                                                                Что они изобрели после фортрана и кобола?
                                                                  +2

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


                                                                  Долой синтаксис

                                                                  А как автор планирует добавлять новые конструкции? Каждой функции по отдельному синтаксису? И всё впихнуть в стандарт? И, главное, как это потом читать? Формальный синтаксис имеет ту же цель, что и математические знаки — стандартизировать элементы и упростить чтение.


                                                                  Долой встроенные типы

                                                                  BigInt, Decimal, Rational etc. — уже давно придуманы. Просто использовать бесконечную точность везде крайне неэффективно.


                                                                  Долой практику метаязыков

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

                                                                    +1
                                                                    Прочитайте последний абзац.
                                                                      0

                                                                      Прочитал. Со статьёй он то ли не связан, то ли противоположен ей. Или это как в байке про Ландау:


                                                                      (пропущено несколько страниц выкладок)
                                                                      "… из чего очевидно следует, что ..."
                                                                        +1
                                                                        Новые COBOL'ы изобретать не надо.
                                                                        Думаю перевод не слишком удачный. В оригинале там на странице есть интерактивный элемент, который позволяет лучше понять смысл.

                                                                        Выше ответил более подробно: habr.com/company/wirex/blog/431558/#comment_19459040
                                                                    +1
                                                                    Автор пока еще не знает о том, что читать код приходится чаще, чем писать с нуля.
                                                                    Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности.
                                                                    Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности.
                                                                    С одной стороны он хочет больше ответственности, то есть думать над тем, что пишешь (привет, Rust!), а с другой стороны он не хочет ни о чём думать, а хочет мурр-мурр ведь так не получится…

                                                                    Автору просто надо написать много кода на паскале, с его begin...end, а потом пересесть на что-то менее многословное.
                                                                      +1
                                                                      Автору просто надо написать много кода на паскале, с его begin...end, а потом пересесть на что-то менее многословное.

                                                                      Вот за begin...end паскаль как раз и люблю. Мне так проще читать программу.

                                                                      0
                                                                      Существуют замечательные языки, придуманные не для выполнения задач, а для создания языков, которые способны их выполнять. Racket, Rebol и Forth — лишь несколько примеров.

                                                                      Щито, простите? Насчет рэкета и реболла — не в курсе, а вот Форт был придуман как раз для выполнения конкретных задач управления оборудованием (телескопом). То, что в форте можно вводить новые слова, которые будут выполнять новые действия — дык это… в С++ тоже можно. И даже в С можно функций наваять. Собственно, программирование на любом языке программирования можно с некой натяжкой назвать «созданием нового языка, способного выполнять поставленную задачу».
                                                                      Пошто зверушку обижаете?
                                                                        –9
                                                                        Язык 21 века — это rust.
                                                                          +3
                                                                          -Товарищи мы ошиблись в самом начале пути!
                                                                          -Нам нужно вернуться во времена перфокарт и все переосмыслить
                                                                          -Быть может переосмыслив, мы сможем писать приложения Hello World на 2% быстрее и производительней аж на целых 3%

                                                                          Блин народ,… просто пишите качественное и востребованное ПО и пофиг на каком стеке и языке. Че вы все меряетесь?
                                                                            0

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

                                                                            +1
                                                                            Числа с плавающей запятой в интерпретации IEEE — вообще не числа. Математика требует ассоциативности от операции их сложения.

                                                                            Математика давно разделилась на два направления.
                                                                            Первое — точные вычисления.
                                                                            Второе — вычисления приближенные и быстрые.
                                                                            Есть целые направления, которые занимаются упрощением задач, чтобы их можно было с приемлемой точностью обсчитать за приемлемое время на имеющихся средствах.
                                                                            Зачем считать точно супер-пупер функцию, если ее можно разложить в ряд и отбросить длинный хвост. Зачем обсчитывать движение автомобиля с учетом всех факторов, включая встречный ветер, силу трения колес с конкретным дорожным покрытием и т.п., когда можно все свести к простой формуле.
                                                                            IEEE как раз был предложен для быстрого вычисления операций для действительных чисел на электрическом вычислительном устройстве. А то, что результат плюс-минус лапоть, так оно так было задумано изначально. И если вычисляемая формула часто уже не точно отражает действительность, то что нам до погрешности таких вычислений.
                                                                            А если вам нужна точность, как в аптеке, то просто используйте специально для этого разработанные инструменты. Но учтите, что они будут работать существенно медленнее.

                                                                              0
                                                                              'не' с глаголом, как известно, пишется раздельно, однако глагола 'взлюбили' не существует, так что 'невзлюбили' — исключение
                                                                                +1
                                                                                возлюбили с беглой о.
                                                                                  0
                                                                                  тогда должно быть или 'не возлюбили', или 'невзлюбили'
                                                                                    –3
                                                                                    Кому должно? В естественных языках логики нет.
                                                                                      0
                                                                                      Не до такой степени
                                                                                        0

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

                                                                                          0

                                                                                          Не путайте язык и орфографию. Вторая всегда отстаёт от первого. Нравится вам это или нет.


                                                                                          Но если уж говорить о правилах, то как раз таки по правилу писаться должно раздельно. А слитное написание — это исключение из правила. Не понятно зачем нужное. Ну то есть понятно, что исторически сложилось, но зачем запрещать писать по правилу — ума не приложу.

                                                                                            0
                                                                                            Зачем их разделять, если орфография задает написание слов языка? Не хотите писать грамотно, не пишите. Грамотное написание это все равно то, которое соответствует правилам.

                                                                                            Если говорит о правилах, то есть правило «Пишутся слитно с не глаголы, которые без не не употребляются», и среди примеров таких слов приводится слово «невзлюбить».
                                                                                              0

                                                                                              Правила постоянно меняются. Как выдумаете почему и как?


                                                                                              От того, что в правиле написано, что в нём есть исключения, они от этого меньшими исключениями не становятся.


                                                                                              Конкретно "невзлюбить" без "не" вполне употребляется, но используется другая форма той же самой приставки: http://www.drevoslov.ru/wordcreation/morphem/1010-voz-vozo-vz-vos-vs

                                                                                                0

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


                                                                                                Исключения — это не правило. Правило это то, что надо делать с исключениями из другого правила, ну или из другой части правила. Есть правило "не с глаголами пишется раздельно", есть исключения, где "не" пишется по-другому, есть правило "не с такими глаголами пишется слитно", а не через дефис например.

                                                                                  0
                                                                                  Смутно вспоминаю язык GARF и команду «подставить Ю вместо Я в вещь Щ»
                                                                                  www.mediafire.com/?h303jm3czojl17x
                                                                                  bolknote.ru/all/4181
                                                                                    0
                                                                                    Где-то я такое видел, не могу вспомнить…
                                                                                    точно 1С: предприятие… А-А-А-А!
                                                                                      0
                                                                                      Тоже думал автору предложить попробовать, но потом понял что даже в 1с получше все таки.
                                                                                        0

                                                                                        1С — это же Visual Basic на русском, не?

                                                                                          0
                                                                                          Да вы что? Это объектный паскаль.
                                                                                            +1

                                                                                            По ключевым словам, в частности, Процедура, КонецПроцедуры, Функция, КонецФункции ближе всё-таки VB (ср. Sub, End Sub, Function, End Function). Опять же операторы, в т.ч. присвоение через =, а не :=. Исключение составляют разве что точки с запятой — в VB их нет.

                                                                                              0
                                                                                              в ABAP то же похож, SQL похож, и ещё целый ворох языков… мода.
                                                                                        0
                                                                                        а Windows не начнет загружаться за 2 секунды.

                                                                                        Но, скорее всего, этот день никогда не настанет.
                                                                                        Но он очень, очень близко! Windows 8.1 у меня запускается ровно за 3 секунды, включая прохождение BIOS, так что вполне возможно, что сама операционка грузится за две!
                                                                                          0
                                                                                          Он не запускается за три секунды — он просто не полностью выключается см. «гибридный спящий режим». Когда ему нужно поставить обновления или вы выбираете «завершение работы» или аккумулятор в ноутбуке сел, то загружается он положенные десятки секунд, как и остальные системы.
                                                                                            0
                                                                                            Нет, три секунды — это загрузка с нуля, без разницы, завершение ли это работы, или просто выдёргиваю провод питания (это не ноут, это MicroITX коробка). А десятки секунд пожалуй загрузка может идти только с HDD. Windows 10 на большом десктопе вместе с BIOS грузится за 5 секунд (и это долго).
                                                                                            Поправка: 5 секунд учёта без BIOS.

                                                                                        Only users with full accounts can post comments. Log in, please.