Только за последние 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 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов. Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности. Вместо языков, входящих и выходящих из моды, всегда есть некие фундаментальные вещи, заслуживающие постоянного переосмысления.
Комментарии (117)
DSolodukhin
03.12.2018 14:22+3create file /tmp/test.txt for input and output as test_file
Это же ужасно. Пример на С выглядит гораздо лучше и проще.
Если так уж хочется более «человечного» синтаксиса, то мне больше нравится Python:
with open("/tmp/test.txt", "w") as test_file: ...vintage
03.12.2018 15:07-2Я бы сделал так:
let test_file <=> File /tmp/test.txt
Двусторонняя стрелка делает эксклюзивный захват ресурса, позволяя читать и писать. Правосторонняя — только запись. Левосторонняя — только чтение. Равенство — просто ссылка без возможности читать/писать.
kAIST
03.12.2018 16:38+1А как же например стрелками записать «a+», «wb» и так далее?
le1ic
03.12.2018 22:30+2Все авторы новых языков считают предыдущих идиотами. Но только реальные языки со всеми их некрасивостями обкатывались на реальных задачах, а не на примере кода первого месяца курса введения в программирование.
vintage
04.12.2018 00:12-1А какое отношение эта криптография имеет к захвату ресурса? Хотите проверить, что файл уже есть — напишите if. Хотите очистить файл — сделайте clear. Хотите переместить указатель в начало/конец/середину — используйте seek.
mayorovp
04.12.2018 06:59Проверка файла на существование с помощью if подвержена гонкам.
vintage
04.12.2018 09:47Каким ещё гонкам? Захватить блокировку сможет лишь один процесс.
mayorovp
04.12.2018 09:49Да простым:
if (файл_существует()) { открыть_файл(); // упс, а его уже успели удалить } else { создать_файл(); // упс, а его уже кто-то создал... }vintage
04.12.2018 10:09#Захватили блокировку на запись 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 <= \
Обратите внимание, что мы просто не можем проверить файл на существование, не взяв блокировку.
mayorovp
04.12.2018 10:12То есть
<=>не создает нового файла? А как в таком случае создавать новые файлы?
le1ic
04.12.2018 10:19Вы не могли бы замэпить это все в системные вызовы, на каком шаге что происходит? А то опять какой-то сферический конь
vintage
04.12.2018 10:44-1Я не спец по системным вызовам. Вы не можете восстановить их по комментариям?
MikailBag
04.12.2018 13:15По-моему это трудно реализуемо без правок в ОС. Вы не можете залочить путь в ФС. Только файл. Т.е. функция File должна всегда пытаться создать файл с макс правами, чтобы в случае его отсутствия не возникло гонки. Но такое решение не работает с доступом на чтение.
В любом случае, имхо это непрозрачно и чужеродно.vintage
04.12.2018 13:37File структуру создаёт. Блокируют стрелочки.
И если для блокировки на запись ресурс должен существовать, то да, он должен быть создан и удалён при выходе из скоупа, если не было записей. В случае чтения ресурс и создавать не надо, так как чтение из несуществующего ресурса никакой гонки не создаёт.
Абстракция и не должна быть прозрачной, если низкоуровневое апи не удобно.mayorovp
04.12.2018 14:23То есть если две программы попробуют выполнить код выше одновременно, что первая выведет "Required file {path} isn't exists!", а вторая выведет "File {path} already opened by another program"?
Счастливой отладки, блин...
vintage
04.12.2018 17:47Если файл не существует, то первая создаст пустой файл, а вторая подвиснет в ожидании его освобождения, после чего упадёт. Если существует, то обе упадут с одинаковым сообщением. Не вижу тут никаких проблем с отладкой.
nafgne
03.12.2018 17:34+2Это немного переиначенный Basic ;)
В реальности это выглядело бы как
open "/tmp/test.txt" for output as #1mayorovp
03.12.2018 17:36Совсем не похоже на Basic, разве что слово
openобщее. У оператораwithв Питоне есть важная фича, которой не было в Basic: автоматическое закрытие файла.
Аналогом вашей строчки на Бейсике была бы вот такая строчка на Питоне:
_1 = open("/tmp/test.txt", "w")
shaukote
03.12.2018 23:07+1А мне больше напомнило AppleScript с его native-language конструкциями. %)
tell application "Finder" to open file "foobar"
werklop
04.12.2018 10:47-1Сами вы ужасный, со своими птичьими конструкциями. Программа должна быть легкочитаемой, а не семантически мифически-правильно написана(привет Rust! со своими восклицательными знаками!!!)
staticlab
04.12.2018 12:38Да-да, привет, Rust:
use std::fs::OpenOptions; let file = OpenOptions::new().write(true) .create_new(true) .open("foo.txt") .expect("Something went wrong opening the file");
Antervis
03.12.2018 14:31+2глаз цепляется за спец. символы, благодаря чему ты сразу читаешь именно ту часть строки которая интересует тебя в данный момент. Когда спец символов нет, читать строки надо полностью и внимательно, а это ужасно сказывается на производительности
fireSparrow
03.12.2018 16:46+1+1. Когда-то математические выкладки записывались тупо текстом. А потом появлялись знаки математических операций, скобки и т.п. И новые математики охотно использовали именно такую запись именно потому, что с ней математика становилась проще и яснее.
AndreySu
03.12.2018 14:33+1Давайте изобретать новые COBOL’ы до тех пор, пока в один прекрасный день солнце не начнет светить ярче, птицы не запоют громче
Зачем изобретать, посмотрите на язык ABAP, потомок того же COBOL'a и ужаснитесь.UnknownUser
04.12.2018 11:57+2Тоже хотел написать это автору. Если ему нравится COBOL, то благословенный ентерпрайз ждёт его в лице разработки для SAP систем )).
Я бы посмотрел что он скажет после года разработки.
YemSalat
05.12.2018 08:26Вы текст дальше то читали?
Давайте изобретать новые COBOL’ы до тех пор, пока в один прекрасный день солнце не начнет светить ярче, птицы не запоют громче, а Windows не начнет загружаться за 2 секунды.
Но, скорее всего, этот день никогда не настанет.
Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов.
Автор как раз и говорит что новые COBOL'ы изобретать не надо.
oisee
03.12.2018 15:08create file /tmp/test.txt for input and output as test_file
Но ведь уже есть AppleScript.
NumLock
03.12.2018 15:40Про COBOL хорошая шутка.
Шутки шутками, а идея программирования на основе АИ давно назрела. Что бы не писать прогу самому, а объяснить АИ концепт программы живым языком. Далее пусть он пыхтит, кодит. В принципе не ново. Та же диалоговая система, только на более высоком уровне.Dr_Faksov
04.12.2018 06:14Вы прямо про АЛМИР-65 вспомнили. Где не существовало понятия размерности, к примеру. Воистину говорю — число могло иметь ЛЮБОЙ размер, абы памяти хватило.
Для интересующихся: ВСЁ описание языка (умеющего строить таблицы, графики и брать интегралы) — 25 страниц!
elib.ict.nsc.ru/jspui/bitstream/ICT/544/1/MIR.pdf
UnknownUser
04.12.2018 11:59Ну, то есть, когда сейчас при разработке больших систем очень сложно разобраться в паутине легаси кода, теперь там будет нейросеть, которая вообще не пойми что делает?
staticlab
04.12.2018 12:42Что бы не писать прогу самому, а объяснить АИ концепт программы живым языком.
Тут живой заказчик не может иногда объяснить живому программисту, чего он хочет.
Далее пусть он пыхтит, кодит.
Проблему останова тоже пусть сам заодно решит?
turbotankist
03.12.2018 15:42Если весь код будет в форме лексических предложений, то будет ни капельки не легче.
Вот законы у нас написаны «обычным» языком, но правильно их читать и применять могут «не только лишь все, мало кто может это».
И замечу, что язык SQL придумали специально для менеджеров, чтоб они могли сами писать запросы в базы, а они всё равно туповаты, и теперь специальные люди пишут эти запросы.Alexsandr_SE
03.12.2018 18:15АИ уже сформирует код не из лексических предложений. Для многих целей подошел бы подход лексика к АИ и последний делает код (в т.ч. лексический для человека), но до такого еще думаю очень далеко.
third112
03.12.2018 21:17Идею с AI-кодером легко развить:
По известной формуле (Вирт): алгоритмы + структуры данных= программы,
где алгоритмы зачастую записывают на псевдо-коде. Если алгоритм описан на естественном языке, то его можно переписать на подходящем псевдо-коде. Аналогично со структурами данных — предложено много способов формального, но достаточно общего их описания. Далее наш инструмент получая на входе алгоритмы и структуры данных (в общем формальном описании) на выходе должен выдать программу на существующем или новом ЯП. В общем случае задача не кажется невыполнимой даже для нынешних технологий. Конечно, нужно учесть ряд деталей. Так описание алгоритма зачастую бывает недостаточно подробным. В этом случае ИМХО может быть применен диалоговый подход: наш инструмент может запросить уточнение.youngmysteriouslight
04.12.2018 02:02+2Далее наш инструмент получая на входе алгоритмы и структуры данных (в общем формальном описании) на выходе должен выдать программу на существующем или новом ЯП.
Взаимоисключающие параграфы же.
Если описание формальное, то оно делается на некотором формальном языке.
А если мы не используем ни один из существующих или новых ЯП, то как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально? Максимум, полуформально. А полуформальная запись всегда субъективна: если некое описание одна группа лиц считает полуформальным (т.е. они между собой убеждены, что способны описание переложить на любой известный ЯП), то третье лицо вполне может сказать, что это описание имеет не больше смысла, чем сепульки или глокая куздра.
P.S. статья и некоторые комментарии натолкнули меня на мысль, что все эти ЯП без синтаксиса и ИИ-кодеры могут иметь смысл, только если мы принципиально отказываемся от идеи программы с контролируемой известной логикой, т.е. разрешаем программе быть потенциально непредсказуемой: как человек всегда может (т.е. нет гарантии обратного) неправильно истолковать слова собеседника, так и программа всегда может сделать что-то принципиально отличающееся от того, что программист (по его мнению) написал. Без понятия, какой класс задач будет решаться эффективнее при таком подходе.Tangeman
04.12.2018 06:51А если мы не используем ни один из существующих или новых ЯП, то как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально?
Мы можем описать её функцию и интерфейс: «Нужна такая штука для создания заметок с голосовым вводом, чтобы их можно было приклеивать на десктоп». Далее можно сделать несколько итераций и уточнить, в итоге умный ИИ сообразит как это лучше сделать, оперируя ему известными алгоритмами, структурами данных и API для целевой системы.
Я надеюсь, в будущем (наверное, далеком, хотя хотелось бы и пораньше) именно так и будут создавать приложения, что решит массу проблем которыми сейчас кишит IT — потому что машина лучше всего справится с разработкой и не допустит ни ошибок, ни уязвимостей, ни быдлокода.
third112
04.12.2018 13:30Нпр., алгоритм Эратосфена из вики:
Для нахождения всех простых чисел не больше заданного числа n, следуя методу Эратосфена, нужно выполнить следующие шаги:
Где здесь ЯП? Всё однозначно без ИИ, итераций, интерфейсов и т.д.
Выписать подряд все целые числа от двух до n (2, 3, 4, …, n).
Пусть переменная p изначально равна двум — первому простому числу.
Зачеркнуть в списке числа от 2p до n считая шагами по p (это будут числа кратные p: 2p, 3p, 4p, …).
Найти первое незачёркнутое число в списке, большее чем p, и присвоить значению переменной p это число.
Повторять шаги 3 и 4, пока возможно.staticlab
04.12.2018 14:01Ок, ИИ делает программу, вы запускаете её, и она не выводит ничего :)
third112
04.12.2018 14:21и она не выводит ничего :)
Простите, не понял в чем шутка юмора: почему ничего не выводит?staticlab
04.12.2018 15:00Потому что нигде не сказано, какие именно значения алгоритм должен возвращать.
third112
04.12.2018 15:06ИМХО сказано:
Для нахождения всех простых чисел не больше заданного числа n
т.е. все простые числа не больше заданного числа n. Но это только мое «ИМХО», поэтому задайте вопрос на соответствующую страницу обсуждения статьи Википедии.staticlab
04.12.2018 15:11Да, но нигде в алгоритме не говорится, какие именно числа нужно добавлять в возвращаемое множество. Речь об этом.
third112
04.12.2018 15:20В самом начале сказано: «Выписать подряд все целые числа от двух до n», дальше нужно только зачеркивать.
staticlab
04.12.2018 15:23Это не очевидно. Я уже не говорю об алгоритмической эффективности операции зачёркивания и вообще её формализации.
third112
04.12.2018 15:34Это не очевидно.
Всем читателям и редакторам вики очевидно, а Вам не очевидно. Печально. Но попробуйте заменить слово «операции зачёркивания» на «операции удаления» — так понятнее? — Из ОЗУ или из файла можно удалять очень эффективно. BTW алгоритм был предложен, когда про ОЗУ, файл и комп никто не знал, а до сих пор является очень важным алгоритмом.staticlab
04.12.2018 15:44Из ОЗУ или из файла можно удалять очень эффективно.
Удаление элемента из середины массива требует сдвига всех последующих элементов.
michael_vostrikov
04.12.2018 15:36Ну он нашел и молодец. Про то, что он их должен пользователю показывать, или возвращать в место вызова, ничего не сказано.
third112
04.12.2018 15:44У Вас проблемы с русским языком? Не понятно написано «Для нахождения»? Сравните с рецептом приготовления чая: для приготовления чая нужно взять чайник, налить в него воды, поставить на огонь и т.д. В каком рецепте пишут кто что должен возвращать? ;)
PS Выше я уже советовал спросить в вики, т.к. это их текст, а я только цитировал.michael_vostrikov
04.12.2018 17:22Ну и? Он нашел же, они в оперативной памяти лежат. Или лежали, пока алгоритм работал. Пользователь их не видит, и использовать не может, так про него никто и не говорил. Не все так однозначно, просто вы додумываете недосказанности на основе жизненного опыта. Которого у компьютера нет.
а я только цитировал
Вы привели это в качестве примера для подтверждения своих слов. К Википедии у меня вопросов нет, вопросы только к вашим утверждениям.
В общем случае задача не кажется невыполнимой даже для нынешних технологий.
Всё однозначно без ИИ, итераций, интерфейсов и т.д.third112
04.12.2018 17:45просто вы додумываете недосказанности на основе жизненного опыта.
Нет, это Вы додумываете и профанируете принципы абстрактного алгоритма, навязывая ему дополнительную частную цель I/O. На самом деле цель "нахождение всех простых чисел не больше заданного числа n" и всё — точка. А что делать с найденными числами — это вопрос другого алгоритма, который м.б. скомпонован с данным. Алгоритм Эратосфена настолько общий, что работает не только на компе, но и на листе бумаги, нпр. Но и в компе, м.б. не нужно выводить все найденные числа из ОЗУ или из файла, м.б. передать область ОЗУ другому алгоритму для других вычислений, а в случае файла — просто не удалять этот файл, а потом читать другой программой при необходимости. Моим словам, на которые Вы указали, это никак не противоречит.michael_vostrikov
04.12.2018 18:35Так если вы все так подробно опишете, то это и будет программа на языке программирования. И даже строго в рамках того, что написано, есть неоднозначности. Какого размера числа использовать — 4-байтовые, 8-байтовые, произвольной точности? Что если мы захотим найти числа до 2^80? Надо сообщить о нехватке оперативной памяти, перенести сохранение на диск, или сразу на диск писать? И таких нюансов много, потому и не сделали еще с нынешними технологиями.
third112
04.12.2018 18:39Так если вы все так подробно опишете, то это и будет программа на языке программирования.
На каком ЯП? На C++ или на JS?michael_vostrikov
04.12.2018 18:52Ну смотря как запишете. Может это будет новый язык N++, а этот якобы AI будет просто компилятором этого языка. Как TypeScript, который компилируется в JS.
third112
04.12.2018 18:56Ну смотря как запишете.
Запишу очень просто. Нпр., Вы спросили:
Какого размера числа использовать — 4-байтовые
Отвечаю: для моей задачи хватит 4-х.
Повторяю вопрос: какой это ЯП?michael_vostrikov
04.12.2018 19:16А где обработчик, который поймет это предложение, чтобы выдать нужный код на C++ или JS? Пока на это способен только естественный интеллект, и то если прочитает предыдущие комменты. Вот если вы опишете принципы такого обработчика, формат как задавать ответы на все указанные вопросы, причем для произвольных задач, и назовете его «Система X», то правила составления этих ответов будут называться «язык программирования системы X».
third112
04.12.2018 20:00правила составления этих ответов будут называться «язык программирования системы X».
Нет. Это будет называтьсяязыкметод описания данных. Я начал с цитаты формулы:(Вирт): алгоритмы + структуры данных= программы
По конкретному вопросу: 4-байтовые или 8-байтовые? — Элементарно. По умолчанию положим 4-байтовые. Но в настройках можно изменить. А еще возможен диалог, списки переменных целевой программы с выбором их типов.michael_vostrikov
04.12.2018 20:46Это будет называться метод описания данных
Нам же надо в том числе и механизм ввода-вывода описывать, какие же это данные? Со всеми вытекающими — гонки, блокировки, файл не найден, файл уже существует… Список машинных команд с некоторой точки зрения тоже данные.
А еще возможен диалог, списки переменных целевой программы с выбором их типов.
И это тоже программирование. А раньше, говорят, тумблеры переключали. Чем сложнее программа, тем больше у вас будет переключателей в интерфейсе. Либо подробнее запись алгоритма.
То, что вы описываете — язык, приближенный к естественному, и куча настроек — похоже на SQL + СУБД. Это тоже программирование.
third112
04.12.2018 20:56С тем же успехом настройку Ворда или написание ТЗ для заказа фрилансеру можно назвать программированием.
third112
04.12.2018 13:22Взаимоисключающие параграфы же.
Нет. Всё четко: см., нпр., вики: отличая программы от алгоритма.
как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально?
Что такое формальное описание программы? Есть исходный код программы на ЯП — этого обычно достаточно. Формальное описание алгоритма — это, нпр., его запись на псевдокоде.
полуформальная запись всегда субъективна
Факты говорят иное: есть солидные научные журналы (по математике, CS и т.д.), которые публикуют новые алгоритмы так, что все читатели этих журналов (речь только о читателях, обладающих необходимой для чтения квалификацией) понимают эти алгоритмы совершенно однозначно.
YemSalat
05.12.2018 08:29Если весь код будет в форме лексических предложений, то будет ни капельки не легче.
С каждым разом все больше убеждаюсь что многие не читают статьи телеком. Увидят что-то в тексте, зацепятся и давай комментить.
Смысл статьи в том и есть, что новые COBOL'ы не нужны.turbotankist
05.12.2018 15:49С каждым разом убеждаюсь, что многие прочтут статью, лучше всех поймут главную идею статьи, увидят что-то в тексте, зацепятся и давай искать комментарии которые им срочно нужно прокомментить.
Смысл комментария не в том, что нужны новые COBOL'ы или не нужны.YemSalat
05.12.2018 19:27Не, не так. Мои личные ощущения — это как когда человек прокомментировал с сарказмом, а кто-то его нe понял и начинает серьезно ему отвечать. Только тут, к сожалению, таких комментов 90%. Возможно перевод не слишком удачный, я в оригинале читал, там как-то лучше воспринимается.
Скрин из оригинальной статьи
mayorovp
05.12.2018 21:21Ну отлично. Так что теперь, нужно для каждого поста на Хабре еще и оригинал читать в обязательном порядке? Ну и в чем в таком случае смысл переводов?
Предлагаю для Хабра новый формат: пост-ссылка на оригинал, под постом — комментарии на русском :-)YemSalat
05.12.2018 22:08Так что теперь, нужно для каждого поста на Хабре еще и оригинал читать в обязательном порядке?
По-моему достаточно прочитать статью до конца. А не первые 10% читаешь, потом нa искосок.
Предлагаю для Хабра новый формат: пост-ссылка на оригинал, под постом — комментарии на русском :-)
Раньше были посты ссылки кстати )mayorovp
05.12.2018 22:37Да нет, тут перевод настолько «качественный», что кажется будто автор предлагает переходить на COBOL. Это после второго внимательного прочтения…
multiprogramm
03.12.2018 15:44Я вообще не понял, с чем борется автор и как.
И это вовсе не парадокс, а образец абсолютно корректного следования всеми уважаемому стандарту IEEE 754.
Числа с плавающей запятой в интерпретации IEEE — вообще не числа. Математика требует ассоциативности от операции их сложения.
Математика не требует. Требуется то, что описано в стандарте. Т.к. это «вообще не числа», то и непротиворечивые правила можно вводить свои, которые, собственно, были введены в стандарте. Притом оно — неплохое приближение действительных чисел «с обеих сторон» в ограниченных условиях. Если на пальцах, то по своей сути оно ближе к сути действительных чисел: как в теории действительных чисел (см. матан) есть неопределённости, бесконечности и всякие стремления к нулю слева, так и в реализации стандарта они есть. Если реально нужны не действительные числа, а рациональные, то нужно использовать готовые/писать свои реализации приближения рациональных, а не натягивать сову.
Похожие особенности есть не только у чисел с плавающей запятой. Встроенные целые числа реализованы не лучше.
Ну потому что это тоже не совсем целые числа, а либо просто их конечное подмножество, либо кольцо вычетов по модулю, либо ещё что-нибудь в зависимости от интерпретации.
Чутье подсказывает, что переполнение даст 0x0000. Однако такой исход не задокументирован ни в одном мировом стандарте. В обработке этой операции все ориентируются на подход C и семейства процессоров x86.
Так получается, что подход C — один из мировых стандартов, где исход задокументирован.
В качестве альтернативных вариантов может получиться 0xFFFF или будет вызвано прерывание, или некий специальный, указывающий на переполнение бит будет сохранен в особом месте.
А это — другие стандарты.
Такие моменты вообще нигде не рассматриваются, и правила обработки подобных операций отличается от языка к языку.
И, собственно, главный вопрос: а как новый язык решит эту проблему? [Здесь комикс про универсальный стандарт]
overflowed 9999
underflowed 0
Что это вообще такое? Если состояния, то, собственно, чем оно лучше NaN и +Inf, когда мы получаем оспариваемое состояние? Если поведение, то чем оно лучше переполнения, когда мы получаем оспариваемое поведение? Да и, собственно, подобные обрезки точности можно просто реализовать на базовых типах в готовых языках, для этого не нужно изобретать ещё один язык, или они даже есть из коробки: тип DECIMAL(N,M) в SQL или currency в некоторых языках.
Разве такие вычисления не будут работать медленнее? Да, будут.
Минус пласт пользователей языка.
Насколько я могу судить, типичный программист 21 века нечасто решает дифференциальные уравнения.
Минус ещё один пласт пользователей языка.
Т.е. в итоге мы получаем ещё один язык 21 века, у которого другой синтаксис, который вводит новые костыли, новые стандарты и правила, но при этом не отказывается от костылей, стандартов и правил 20 века, и реализации на котором медленнее? Можно не надо?bogolt
04.12.2018 00:14Согласен. Людям не нужен еще один способ программы сообщения об ошибке — им нужно чтобы самой ошибки не было. А заменять одну ошибку на другую не больно то имеет смысл.
Alexeyslav
04.12.2018 17:27Язык языком, но поведение чисел при переполнении определяется в первую очередь железом, и если оно не обнуляет при целочисленной операции а выставляет признак переполнения в неком регистре и оставляет в переменной максимальное значение а другое железо оставляет и признак переполнения и даёт ноль — это в стандарт языка никак не внесёшь т.к. есть зависимость поведения от конкретного железа на котором будет выполняться программа написанная на языке. Речь идёт о достаточно низкоуровневых языках, где делать обработку события переполнения и переопределять результат чтобы он не зависел от железа довольно накладно. Речь идёт о разнице скоростей в 10 и более раз.
YemSalat
05.12.2018 08:31-1Блин, да дочитайте до конца статью!!!
Вы столько тут настрочили, а автор как раз и говорит об этом.
Последний абзац:
Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов. Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности. Вместо языков, входящих и выходящих из моды, всегда есть некие фундаментальные вещи, заслуживающие постоянного переосмысления.
maledog
03.12.2018 16:11Почему бы автору не
пороть чушьделать спорные заявления, а сесть и попытаться реализовать все его хотелки в собственном «языке программирования 21 века»? Уверен, что некоторые из его убеждений в процессе написания изменятся.
Разве такие вычисления не будут работать медленнее? Да, будут. Но спросите себя: как часто вам приходится программировать высокопроизводительные вычисления? Полагаю, что если вы не специалист в этой области, то очень редко. А если вы и занимаетесь подобными задачами, то пользуетесь для этих целей специализированным оборудованием и компиляторами. Насколько я могу судить, типичный программист 21 века нечасто решает дифференциальные уравнения.
Типичный программист 21 века делает так:
// performance project main.go package main func main() { for { } }
И съедает один поток процессора полностью. Но зачем оптимизировать, когда можно купить процессор мощнее?YemSalat
05.12.2018 08:34-1Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов. Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности. Вместо языков, входящих и выходящих из моды, всегда есть некие фундаментальные вещи, заслуживающие постоянного переосмысления.
LAutour
03.12.2018 16:27В свое время программисты не взлюбили Fortran и COBOL, потому изобрели C++ и Java
Что они изобрели после фортрана и кобола?
TargetSan
03.12.2018 16:34Я так и не увидел, какие проблемы должен решать новый язык.
Касательно же предложений из статьи
Долой синтаксис
А как автор планирует добавлять новые конструкции? Каждой функции по отдельному синтаксису? И всё впихнуть в стандарт? И, главное, как это потом читать? Формальный синтаксис имеет ту же цель, что и математические знаки — стандартизировать элементы и упростить чтение.
Долой встроенные типы
BigInt, Decimal, Rational etc. — уже давно придуманы. Просто использовать бесконечную точность везде крайне неэффективно.
Долой практику метаязыков
Так и не понял. Сначала автор против метапрограммирования. Потом автор против больших стандартов, которые закрывают эту проблему. При том, что оба постулата напрямую противоречат постулату "Долой синтаксис", который будет провоцировать свой синтаксис на каждый чих.
YemSalat
05.12.2018 08:35-1Прочитайте последний абзац.
TargetSan
05.12.2018 18:46Прочитал. Со статьёй он то ли не связан, то ли противоположен ей. Или это как в байке про Ландау:
(пропущено несколько страниц выкладок)
"… из чего очевидно следует, что ..."YemSalat
05.12.2018 19:30+1Новые COBOL'ы изобретать не надо.
Думаю перевод не слишком удачный. В оригинале там на странице есть интерактивный элемент, который позволяет лучше понять смысл.
Выше ответил более подробно: habr.com/company/wirex/blog/431558/#comment_19459040
Revertis
03.12.2018 16:41Автор пока еще не знает о том, что читать код приходится чаще, чем писать с нуля.
Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности.
Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности.
С одной стороны он хочет больше ответственности, то есть думать над тем, что пишешь (привет, Rust!), а с другой стороны он не хочет ни о чём думать, ахочет мурр-муррведь так не получится…
Автору просто надо написать много кода на паскале, с его begin...end, а потом пересесть на что-то менее многословное.geher
03.12.2018 22:02Автору просто надо написать много кода на паскале, с его begin...end, а потом пересесть на что-то менее многословное.
Вот за begin...end паскаль как раз и люблю. Мне так проще читать программу.
berez
03.12.2018 17:24Существуют замечательные языки, придуманные не для выполнения задач, а для создания языков, которые способны их выполнять. Racket, Rebol и Forth — лишь несколько примеров.
Щито, простите? Насчет рэкета и реболла — не в курсе, а вот Форт был придуман как раз для выполнения конкретных задач управления оборудованием (телескопом). То, что в форте можно вводить новые слова, которые будут выполнять новые действия — дык это… в С++ тоже можно. И даже в С можно функций наваять. Собственно, программирование на любом языке программирования можно с некой натяжкой назвать «созданием нового языка, способного выполнять поставленную задачу».
Пошто зверушку обижаете?
anonymous
03.12.2018 17:43+3-Товарищи мы ошиблись в самом начале пути!
-Нам нужно вернуться во времена перфокарт и все переосмыслить
-Быть может переосмыслив, мы сможем писать приложения Hello World на 2% быстрее и производительней аж на целых 3%
Блин народ,… просто пишите качественное и востребованное ПО и пофиг на каком стеке и языке. Че вы все меряетесь?AirLight
04.12.2018 04:33Технологические стеки не с неба падают, их тоже кто-то создает и им приходится думать над подобными вопросами, определять альтернативы.
geher
03.12.2018 22:16Числа с плавающей запятой в интерпретации IEEE — вообще не числа. Математика требует ассоциативности от операции их сложения.
Математика давно разделилась на два направления.
Первое — точные вычисления.
Второе — вычисления приближенные и быстрые.
Есть целые направления, которые занимаются упрощением задач, чтобы их можно было с приемлемой точностью обсчитать за приемлемое время на имеющихся средствах.
Зачем считать точно супер-пупер функцию, если ее можно разложить в ряд и отбросить длинный хвост. Зачем обсчитывать движение автомобиля с учетом всех факторов, включая встречный ветер, силу трения колес с конкретным дорожным покрытием и т.п., когда можно все свести к простой формуле.
IEEE как раз был предложен для быстрого вычисления операций для действительных чисел на электрическом вычислительном устройстве. А то, что результат плюс-минус лапоть, так оно так было задумано изначально. И если вычисляемая формула часто уже не точно отражает действительность, то что нам до погрешности таких вычислений.
А если вам нужна точность, как в аптеке, то просто используйте специально для этого разработанные инструменты. Но учтите, что они будут работать существенно медленнее.
maxzhurkin
03.12.2018 22:30'не' с глаголом, как известно, пишется раздельно, однако глагола 'взлюбили' не существует, так что 'невзлюбили' — исключение
vintage
04.12.2018 00:27+1возлюбили с беглой о.
maxzhurkin
04.12.2018 11:43тогда должно быть или 'не возлюбили', или 'невзлюбили'
vintage
04.12.2018 13:24-1Кому должно? В естественных языках логики нет.
michael_vostrikov
04.12.2018 20:47В естественных языках есть правила. В русском языке есть правило, по которому это слово пишется слитно. Вы можете придумать свой язык, где оно будет писаться раздельно, но это будет не русский язык.
vintage
04.12.2018 20:58Не путайте язык и орфографию. Вторая всегда отстаёт от первого. Нравится вам это или нет.
Но если уж говорить о правилах, то как раз таки по правилу писаться должно раздельно. А слитное написание — это исключение из правила. Не понятно зачем нужное. Ну то есть понятно, что исторически сложилось, но зачем запрещать писать по правилу — ума не приложу.
michael_vostrikov
04.12.2018 21:39Зачем их разделять, если орфография задает написание слов языка? Не хотите писать грамотно, не пишите. Грамотное написание это все равно то, которое соответствует правилам.
Если говорит о правилах, то есть правило «Пишутся слитно с не глаголы, которые без не не употребляются», и среди примеров таких слов приводится слово «невзлюбить».vintage
05.12.2018 03:04Правила постоянно меняются. Как выдумаете почему и как?
От того, что в правиле написано, что в нём есть исключения, они от этого меньшими исключениями не становятся.
Конкретно "невзлюбить" без "не" вполне употребляется, но используется другая форма той же самой приставки: http://www.drevoslov.ru/wordcreation/morphem/1010-voz-vozo-vz-vos-vs
michael_vostrikov
05.12.2018 07:24Вот "возлюбить" и надо писать раздельно с "не". Слово "взлюбить" не употребляется, потому и не должно появляться в предложении, неважно, какое слово идет перед ним.
Исключения — это не правило. Правило это то, что надо делать с исключениями из другого правила, ну или из другой части правила. Есть правило "не с глаголами пишется раздельно", есть исключения, где "не" пишется по-другому, есть правило "не с такими глаголами пишется слитно", а не через дефис например.
shuhray
03.12.2018 23:23Смутно вспоминаю язык GARF и команду «подставить Ю вместо Я в вещь Щ»
www.mediafire.com/?h303jm3czojl17x
bolknote.ru/all/4181
Kicker
04.12.2018 12:18Где-то я такое видел, не могу вспомнить…
точно 1С: предприятие… А-А-А-А!Neikist
04.12.2018 12:29Тоже думал автору предложить попробовать, но потом понял что даже в 1с получше все таки.
staticlab
04.12.2018 12:451С — это же Visual Basic на русском, не?
Revertis
04.12.2018 16:29Да вы что? Это объектный паскаль.
staticlab
05.12.2018 11:13По ключевым словам, в частности,
Процедура,КонецПроцедуры,Функция,КонецФункцииближе всё-таки VB (ср.Sub,End Sub,Function,End Function). Опять же операторы, в т.ч. присвоение через=, а не:=. Исключение составляют разве что точки с запятой — в VB их нет.
SergeyMax
04.12.2018 18:22а Windows не начнет загружаться за 2 секунды.
Но он очень, очень близко! Windows 8.1 у меня запускается ровно за 3 секунды, включая прохождение BIOS, так что вполне возможно, что сама операционка грузится за две!
Но, скорее всего, этот день никогда не настанет.maledog
04.12.2018 22:40Он не запускается за три секунды — он просто не полностью выключается см. «гибридный спящий режим». Когда ему нужно поставить обновления или вы выбираете «завершение работы» или аккумулятор в ноутбуке сел, то загружается он положенные десятки секунд, как и остальные системы.
SergeyMax
04.12.2018 22:55Нет, три секунды — это загрузка с нуля, без разницы, завершение ли это работы, или просто выдёргиваю провод питания (это не ноут, это MicroITX коробка). А десятки секунд пожалуй загрузка может идти только с HDD. Windows 10 на большом десктопе вместе с BIOS грузится за 5 секунд (и это долго).
Поправка: 5 секунд учёта без BIOS.
MonkAlex
Автор воды налил и поскользнулся.
myxo
я аж пошел проверять календарь, вдруг я до апреля проспал? 0_о
NeoCode
Мне показалось автор налил чего-то покрепче