Comments 122
Автор воды налил и поскользнулся.
create file /tmp/test.txt for input and output as test_file
Это же ужасно. Пример на С выглядит гораздо лучше и проще.
Если так уж хочется более «человечного» синтаксиса, то мне больше нравится Python:
with open("/tmp/test.txt", "w") as test_file:
...
Я бы сделал так:
let test_file <=> File /tmp/test.txtДвусторонняя стрелка делает эксклюзивный захват ресурса, позволяя читать и писать. Правосторонняя — только запись. Левосторонняя — только чтение. Равенство — просто ссылка без возможности читать/писать.
А как же например стрелками записать «a+», «wb» и так далее?
+ — плюсиком и указывать. А b не нужен, это DOS'овский пережиток.
emoji, очевидно же =))
А какое отношение эта криптография имеет к захвату ресурса? Хотите проверить, что файл уже есть — напишите if. Хотите очистить файл — сделайте clear. Хотите переместить указатель в начало/конец/середину — используйте seek.
Проверка файла на существование с помощью if подвержена гонкам.
Каким ещё гонкам? Захватить блокировку сможет лишь один процесс.
Да простым:
if (файл_существует()) {
открыть_файл(); // упс, а его уже успели удалить
} else {
создать_файл(); // упс, а его уже кто-то создал...
}#Захватили блокировку на запись
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 <= \Обратите внимание, что мы просто не можем проверить файл на существование, не взяв блокировку.
То есть <=> не создает нового файла? А как в таком случае создавать новые файлы?
Я не спец по системным вызовам. Вы не можете восстановить их по комментариям?
По-моему это трудно реализуемо без правок в ОС. Вы не можете залочить путь в ФС. Только файл. Т.е. функция File должна всегда пытаться создать файл с макс правами, чтобы в случае его отсутствия не возникло гонки. Но такое решение не работает с доступом на чтение.
В любом случае, имхо это непрозрачно и чужеродно.
File структуру создаёт. Блокируют стрелочки.
И если для блокировки на запись ресурс должен существовать, то да, он должен быть создан и удалён при выходе из скоупа, если не было записей. В случае чтения ресурс и создавать не надо, так как чтение из несуществующего ресурса никакой гонки не создаёт.
Абстракция и не должна быть прозрачной, если низкоуровневое апи не удобно.
И если для блокировки на запись ресурс должен существовать, то да, он должен быть создан и удалён при выходе из скоупа, если не было записей. В случае чтения ресурс и создавать не надо, так как чтение из несуществующего ресурса никакой гонки не создаёт.
Абстракция и не должна быть прозрачной, если низкоуровневое апи не удобно.
let test<=>file <=> File test file.txtДосвиданья.
Совсем не похоже на Basic, разве что слово open общее. У оператора with в Питоне есть важная фича, которой не было в Basic: автоматическое закрытие файла.
Аналогом вашей строчки на Бейсике была бы вот такая строчка на Питоне:
_1 = open("/tmp/test.txt", "w")
А мне больше напомнило AppleScript с его native-language конструкциями. %)
tell application "Finder" to open file "foobar"
Сами вы ужасный, со своими птичьими конструкциями. Программа должна быть легкочитаемой, а не семантически мифически-правильно написана(привет Rust! со своими восклицательными знаками!!!)
глаз цепляется за спец. символы, благодаря чему ты сразу читаешь именно ту часть строки которая интересует тебя в данный момент. Когда спец символов нет, читать строки надо полностью и внимательно, а это ужасно сказывается на производительности
Давайте изобретать новые COBOL’ы до тех пор, пока в один прекрасный день солнце не начнет светить ярче, птицы не запоют громче
Зачем изобретать, посмотрите на язык ABAP, потомок того же COBOL'a и ужаснитесь.
Тоже хотел написать это автору. Если ему нравится COBOL, то благословенный ентерпрайз ждёт его в лице разработки для SAP систем )).
Я бы посмотрел что он скажет после года разработки.
Я бы посмотрел что он скажет после года разработки.
Вы текст дальше то читали?
Автор как раз и говорит что новые COBOL'ы изобретать не надо.
Давайте изобретать новые COBOL’ы до тех пор, пока в один прекрасный день солнце не начнет светить ярче, птицы не запоют громче, а Windows не начнет загружаться за 2 секунды.
Но, скорее всего, этот день никогда не настанет.
Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов.
Автор как раз и говорит что новые COBOL'ы изобретать не надо.
create file /tmp/test.txt for input and output as test_fileНо ведь уже есть AppleScript.
Про COBOL хорошая шутка.
Шутки шутками, а идея программирования на основе АИ давно назрела. Что бы не писать прогу самому, а объяснить АИ концепт программы живым языком. Далее пусть он пыхтит, кодит. В принципе не ново. Та же диалоговая система, только на более высоком уровне.
Шутки шутками, а идея программирования на основе АИ давно назрела. Что бы не писать прогу самому, а объяснить АИ концепт программы живым языком. Далее пусть он пыхтит, кодит. В принципе не ново. Та же диалоговая система, только на более высоком уровне.
С FrontPage в свое время получилось не очень.
Вы прямо про АЛМИР-65 вспомнили. Где не существовало понятия размерности, к примеру. Воистину говорю — число могло иметь ЛЮБОЙ размер, абы памяти хватило.
Для интересующихся: ВСЁ описание языка (умеющего строить таблицы, графики и брать интегралы) — 25 страниц!
elib.ict.nsc.ru/jspui/bitstream/ICT/544/1/MIR.pdf
Для интересующихся: ВСЁ описание языка (умеющего строить таблицы, графики и брать интегралы) — 25 страниц!
elib.ict.nsc.ru/jspui/bitstream/ICT/544/1/MIR.pdf
Ну, то есть, когда сейчас при разработке больших систем очень сложно разобраться в паутине легаси кода, теперь там будет нейросеть, которая вообще не пойми что делает?
Если весь код будет в форме лексических предложений, то будет ни капельки не легче.
Вот законы у нас написаны «обычным» языком, но правильно их читать и применять могут «не только лишь все, мало кто может это».
И замечу, что язык SQL придумали специально для менеджеров, чтоб они могли сами писать запросы в базы, а они всё равно туповаты, и теперь специальные люди пишут эти запросы.
Вот законы у нас написаны «обычным» языком, но правильно их читать и применять могут «не только лишь все, мало кто может это».
И замечу, что язык SQL придумали специально для менеджеров, чтоб они могли сами писать запросы в базы, а они всё равно туповаты, и теперь специальные люди пишут эти запросы.
АИ уже сформирует код не из лексических предложений. Для многих целей подошел бы подход лексика к АИ и последний делает код (в т.ч. лексический для человека), но до такого еще думаю очень далеко.
Идею с AI-кодером легко развить:
По известной формуле (Вирт): алгоритмы + структуры данных= программы,
где алгоритмы зачастую записывают на псевдо-коде. Если алгоритм описан на естественном языке, то его можно переписать на подходящем псевдо-коде. Аналогично со структурами данных — предложено много способов формального, но достаточно общего их описания. Далее наш инструмент получая на входе алгоритмы и структуры данных (в общем формальном описании) на выходе должен выдать программу на существующем или новом ЯП. В общем случае задача не кажется невыполнимой даже для нынешних технологий. Конечно, нужно учесть ряд деталей. Так описание алгоритма зачастую бывает недостаточно подробным. В этом случае ИМХО может быть применен диалоговый подход: наш инструмент может запросить уточнение.
По известной формуле (Вирт): алгоритмы + структуры данных= программы,
где алгоритмы зачастую записывают на псевдо-коде. Если алгоритм описан на естественном языке, то его можно переписать на подходящем псевдо-коде. Аналогично со структурами данных — предложено много способов формального, но достаточно общего их описания. Далее наш инструмент получая на входе алгоритмы и структуры данных (в общем формальном описании) на выходе должен выдать программу на существующем или новом ЯП. В общем случае задача не кажется невыполнимой даже для нынешних технологий. Конечно, нужно учесть ряд деталей. Так описание алгоритма зачастую бывает недостаточно подробным. В этом случае ИМХО может быть применен диалоговый подход: наш инструмент может запросить уточнение.
Далее наш инструмент получая на входе алгоритмы и структуры данных (в общем формальном описании) на выходе должен выдать программу на существующем или новом ЯП.Взаимоисключающие параграфы же.
Если описание формальное, то оно делается на некотором формальном языке.
А если мы не используем ни один из существующих или новых ЯП, то как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально? Максимум, полуформально. А полуформальная запись всегда субъективна: если некое описание одна группа лиц считает полуформальным (т.е. они между собой убеждены, что способны описание переложить на любой известный ЯП), то третье лицо вполне может сказать, что это описание имеет не больше смысла, чем сепульки или глокая куздра.
P.S. статья и некоторые комментарии натолкнули меня на мысль, что все эти ЯП без синтаксиса и ИИ-кодеры могут иметь смысл, только если мы принципиально отказываемся от идеи программы с контролируемой известной логикой, т.е. разрешаем программе быть потенциально непредсказуемой: как человек всегда может (т.е. нет гарантии обратного) неправильно истолковать слова собеседника, так и программа всегда может сделать что-то принципиально отличающееся от того, что программист (по его мнению) написал. Без понятия, какой класс задач будет решаться эффективнее при таком подходе.
А если мы не используем ни один из существующих или новых ЯП, то как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально?
Мы можем описать её функцию и интерфейс: «Нужна такая штука для создания заметок с голосовым вводом, чтобы их можно было приклеивать на десктоп». Далее можно сделать несколько итераций и уточнить, в итоге умный ИИ сообразит как это лучше сделать, оперируя ему известными алгоритмами, структурами данных и API для целевой системы.
Я надеюсь, в будущем (наверное, далеком, хотя хотелось бы и пораньше) именно так и будут создавать приложения, что решит массу проблем которыми сейчас кишит IT — потому что машина лучше всего справится с разработкой и не допустит ни ошибок, ни уязвимостей, ни быдлокода.
Нпр., алгоритм Эратосфена из вики:
Для нахождения всех простых чисел не больше заданного числа n, следуя методу Эратосфена, нужно выполнить следующие шаги:Где здесь ЯП? Всё однозначно без ИИ, итераций, интерфейсов и т.д.
Выписать подряд все целые числа от двух до n (2, 3, 4, …, n).
Пусть переменная p изначально равна двум — первому простому числу.
Зачеркнуть в списке числа от 2p до n считая шагами по p (это будут числа кратные p: 2p, 3p, 4p, …).
Найти первое незачёркнутое число в списке, большее чем p, и присвоить значению переменной p это число.
Повторять шаги 3 и 4, пока возможно.
и она не выводит ничего :)
Простите, не понял в чем шутка юмора: почему ничего не выводит?
ИМХО сказано:
т.е. все простые числа не больше заданного числа n. Но это только мое «ИМХО», поэтому задайте вопрос на соответствующую страницу обсуждения статьи Википедии.
Для нахождения всех простых чисел не больше заданного числа n
т.е. все простые числа не больше заданного числа n. Но это только мое «ИМХО», поэтому задайте вопрос на соответствующую страницу обсуждения статьи Википедии.
В самом начале сказано: «Выписать подряд все целые числа от двух до n», дальше нужно только зачеркивать.
Это не очевидно.Всем читателям и редакторам вики очевидно, а Вам не очевидно. Печально. Но попробуйте заменить слово «операции зачёркивания» на «операции удаления» — так понятнее? — Из ОЗУ или из файла можно удалять очень эффективно. BTW алгоритм был предложен, когда про ОЗУ, файл и комп никто не знал, а до сих пор является очень важным алгоритмом.
Ну он нашел и молодец. Про то, что он их должен пользователю показывать, или возвращать в место вызова, ничего не сказано.
У Вас проблемы с русским языком? Не понятно написано «Для нахождения»? Сравните с рецептом приготовления чая: для приготовления чая нужно взять чайник, налить в него воды, поставить на огонь и т.д. В каком рецепте пишут кто что должен возвращать? ;)
PS Выше я уже советовал спросить в вики, т.к. это их текст, а я только цитировал.
PS Выше я уже советовал спросить в вики, т.к. это их текст, а я только цитировал.
Ну и? Он нашел же, они в оперативной памяти лежат. Или лежали, пока алгоритм работал. Пользователь их не видит, и использовать не может, так про него никто и не говорил. Не все так однозначно, просто вы додумываете недосказанности на основе жизненного опыта. Которого у компьютера нет.
а я только цитировал
Вы привели это в качестве примера для подтверждения своих слов. К Википедии у меня вопросов нет, вопросы только к вашим утверждениям.
В общем случае задача не кажется невыполнимой даже для нынешних технологий.
Всё однозначно без ИИ, итераций, интерфейсов и т.д.
просто вы додумываете недосказанности на основе жизненного опыта.Нет, это Вы додумываете и профанируете принципы абстрактного алгоритма, навязывая ему дополнительную частную цель I/O. На самом деле цель "нахождение всех простых чисел не больше заданного числа n" и всё — точка. А что делать с найденными числами — это вопрос другого алгоритма, который м.б. скомпонован с данным. Алгоритм Эратосфена настолько общий, что работает не только на компе, но и на листе бумаги, нпр. Но и в компе, м.б. не нужно выводить все найденные числа из ОЗУ или из файла, м.б. передать область ОЗУ другому алгоритму для других вычислений, а в случае файла — просто не удалять этот файл, а потом читать другой программой при необходимости. Моим словам, на которые Вы указали, это никак не противоречит.
Так если вы все так подробно опишете, то это и будет программа на языке программирования. И даже строго в рамках того, что написано, есть неоднозначности. Какого размера числа использовать — 4-байтовые, 8-байтовые, произвольной точности? Что если мы захотим найти числа до 2^80? Надо сообщить о нехватке оперативной памяти, перенести сохранение на диск, или сразу на диск писать? И таких нюансов много, потому и не сделали еще с нынешними технологиями.
Так если вы все так подробно опишете, то это и будет программа на языке программирования.На каком ЯП? На C++ или на JS?
Ну смотря как запишете. Может это будет новый язык N++, а этот якобы AI будет просто компилятором этого языка. Как TypeScript, который компилируется в JS.
Ну смотря как запишете.
Запишу очень просто. Нпр., Вы спросили:
Какого размера числа использовать — 4-байтовые
Отвечаю: для моей задачи хватит 4-х.
Повторяю вопрос: какой это ЯП?
А где обработчик, который поймет это предложение, чтобы выдать нужный код на C++ или JS? Пока на это способен только естественный интеллект, и то если прочитает предыдущие комменты. Вот если вы опишете принципы такого обработчика, формат как задавать ответы на все указанные вопросы, причем для произвольных задач, и назовете его «Система X», то правила составления этих ответов будут называться «язык программирования системы X».
правила составления этих ответов будут называться «язык программирования системы X».Нет. Это будет называться
(Вирт): алгоритмы + структуры данных= программы
По конкретному вопросу: 4-байтовые или 8-байтовые? — Элементарно. По умолчанию положим 4-байтовые. Но в настройках можно изменить. А еще возможен диалог, списки переменных целевой программы с выбором их типов.
Это будет называться метод описания данных
Нам же надо в том числе и механизм ввода-вывода описывать, какие же это данные? Со всеми вытекающими — гонки, блокировки, файл не найден, файл уже существует… Список машинных команд с некоторой точки зрения тоже данные.
А еще возможен диалог, списки переменных целевой программы с выбором их типов.
И это тоже программирование. А раньше, говорят, тумблеры переключали. Чем сложнее программа, тем больше у вас будет переключателей в интерфейсе. Либо подробнее запись алгоритма.
То, что вы описываете — язык, приближенный к естественному, и куча настроек — похоже на SQL + СУБД. Это тоже программирование.
Нет, должна выводить 42 )).
Взаимоисключающие параграфы же.Нет. Всё четко: см., нпр., вики: отличая программы от алгоритма.
как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально?Что такое формальное описание программы? Есть исходный код программы на ЯП — этого обычно достаточно. Формальное описание алгоритма — это, нпр., его запись на псевдокоде.
полуформальная запись всегда субъективнаФакты говорят иное: есть солидные научные журналы (по математике, CS и т.д.), которые публикуют новые алгоритмы так, что все читатели этих журналов (речь только о читателях, обладающих необходимой для чтения квалификацией) понимают эти алгоритмы совершенно однозначно.
Если весь код будет в форме лексических предложений, то будет ни капельки не легче.
С каждым разом все больше убеждаюсь что многие не читают статьи телеком. Увидят что-то в тексте, зацепятся и давай комментить.
Смысл статьи в том и есть, что новые COBOL'ы не нужны.
С каждым разом убеждаюсь, что многие прочтут статью, лучше всех поймут главную идею статьи, увидят что-то в тексте, зацепятся и давай искать комментарии которые им срочно нужно прокомментить.
Смысл комментария не в том, что нужны новые COBOL'ы или не нужны.
Смысл комментария не в том, что нужны новые COBOL'ы или не нужны.
Не, не так. Мои личные ощущения — это как когда человек прокомментировал с сарказмом, а кто-то его нe понял и начинает серьезно ему отвечать. Только тут, к сожалению, таких комментов 90%. Возможно перевод не слишком удачный, я в оригинале читал, там как-то лучше воспринимается.
Смысл автора явно в том что не нужно изобретать новые языки акцентирующие свое внимание на «революции» в самом процессе написания кода. Лучше концентрировать свое внимание на процессе разработки, на том как код работает, и решать важные проблемы не акцентируя внимания на самом языке. Языков и так достаточно. Автор взял COBOL как пример, все описанные им пункты — были мотивацией для создания кобола, и где теперь кобол?
Скрин из оригинальной статьи
Смысл автора явно в том что не нужно изобретать новые языки акцентирующие свое внимание на «революции» в самом процессе написания кода. Лучше концентрировать свое внимание на процессе разработки, на том как код работает, и решать важные проблемы не акцентируя внимания на самом языке. Языков и так достаточно. Автор взял COBOL как пример, все описанные им пункты — были мотивацией для создания кобола, и где теперь кобол?
Ну отлично. Так что теперь, нужно для каждого поста на Хабре еще и оригинал читать в обязательном порядке? Ну и в чем в таком случае смысл переводов?
Предлагаю для Хабра новый формат: пост-ссылка на оригинал, под постом — комментарии на русском :-)
Предлагаю для Хабра новый формат: пост-ссылка на оригинал, под постом — комментарии на русском :-)
Так что теперь, нужно для каждого поста на Хабре еще и оригинал читать в обязательном порядке?
По-моему достаточно прочитать статью до конца. А не первые 10% читаешь, потом нa искосок.
Предлагаю для Хабра новый формат: пост-ссылка на оригинал, под постом — комментарии на русском :-)
Раньше были посты ссылки кстати )
Да нет, тут перевод настолько «качественный», что кажется будто автор предлагает переходить на COBOL. Это после второго внимательного прочтения…
Boomburum вот над чем надо думать для будущей мультиязычности на habr.com :)
Я вообще не понял, с чем борется автор и как.
Математика не требует. Требуется то, что описано в стандарте. Т.к. это «вообще не числа», то и непротиворечивые правила можно вводить свои, которые, собственно, были введены в стандарте. Притом оно — неплохое приближение действительных чисел «с обеих сторон» в ограниченных условиях. Если на пальцах, то по своей сути оно ближе к сути действительных чисел: как в теории действительных чисел (см. матан) есть неопределённости, бесконечности и всякие стремления к нулю слева, так и в реализации стандарта они есть. Если реально нужны не действительные числа, а рациональные, то нужно использовать готовые/писать свои реализации приближения рациональных, а не натягивать сову.
Ну потому что это тоже не совсем целые числа, а либо просто их конечное подмножество, либо кольцо вычетов по модулю, либо ещё что-нибудь в зависимости от интерпретации.
Так получается, что подход C — один из мировых стандартов, где исход задокументирован.
А это — другие стандарты.
И, собственно, главный вопрос: а как новый язык решит эту проблему? [Здесь комикс про универсальный стандарт]
Что это вообще такое? Если состояния, то, собственно, чем оно лучше NaN и +Inf, когда мы получаем оспариваемое состояние? Если поведение, то чем оно лучше переполнения, когда мы получаем оспариваемое поведение? Да и, собственно, подобные обрезки точности можно просто реализовать на базовых типах в готовых языках, для этого не нужно изобретать ещё один язык, или они даже есть из коробки: тип DECIMAL(N,M) в SQL или currency в некоторых языках.
Минус пласт пользователей языка.
Минус ещё один пласт пользователей языка.
Т.е. в итоге мы получаем ещё один язык 21 века, у которого другой синтаксис, который вводит новые костыли, новые стандарты и правила, но при этом не отказывается от костылей, стандартов и правил 20 века, и реализации на котором медленнее? Можно не надо?
И это вовсе не парадокс, а образец абсолютно корректного следования всеми уважаемому стандарту IEEE 754.
Числа с плавающей запятой в интерпретации IEEE — вообще не числа. Математика требует ассоциативности от операции их сложения.
Математика не требует. Требуется то, что описано в стандарте. Т.к. это «вообще не числа», то и непротиворечивые правила можно вводить свои, которые, собственно, были введены в стандарте. Притом оно — неплохое приближение действительных чисел «с обеих сторон» в ограниченных условиях. Если на пальцах, то по своей сути оно ближе к сути действительных чисел: как в теории действительных чисел (см. матан) есть неопределённости, бесконечности и всякие стремления к нулю слева, так и в реализации стандарта они есть. Если реально нужны не действительные числа, а рациональные, то нужно использовать готовые/писать свои реализации приближения рациональных, а не натягивать сову.
Похожие особенности есть не только у чисел с плавающей запятой. Встроенные целые числа реализованы не лучше.
Ну потому что это тоже не совсем целые числа, а либо просто их конечное подмножество, либо кольцо вычетов по модулю, либо ещё что-нибудь в зависимости от интерпретации.
Чутье подсказывает, что переполнение даст 0x0000. Однако такой исход не задокументирован ни в одном мировом стандарте. В обработке этой операции все ориентируются на подход C и семейства процессоров x86.
Так получается, что подход C — один из мировых стандартов, где исход задокументирован.
В качестве альтернативных вариантов может получиться 0xFFFF или будет вызвано прерывание, или некий специальный, указывающий на переполнение бит будет сохранен в особом месте.
А это — другие стандарты.
Такие моменты вообще нигде не рассматриваются, и правила обработки подобных операций отличается от языка к языку.
И, собственно, главный вопрос: а как новый язык решит эту проблему? [Здесь комикс про универсальный стандарт]
overflowed 9999
underflowed 0
Что это вообще такое? Если состояния, то, собственно, чем оно лучше NaN и +Inf, когда мы получаем оспариваемое состояние? Если поведение, то чем оно лучше переполнения, когда мы получаем оспариваемое поведение? Да и, собственно, подобные обрезки точности можно просто реализовать на базовых типах в готовых языках, для этого не нужно изобретать ещё один язык, или они даже есть из коробки: тип DECIMAL(N,M) в SQL или currency в некоторых языках.
Разве такие вычисления не будут работать медленнее? Да, будут.
Минус пласт пользователей языка.
Насколько я могу судить, типичный программист 21 века нечасто решает дифференциальные уравнения.
Минус ещё один пласт пользователей языка.
Т.е. в итоге мы получаем ещё один язык 21 века, у которого другой синтаксис, который вводит новые костыли, новые стандарты и правила, но при этом не отказывается от костылей, стандартов и правил 20 века, и реализации на котором медленнее? Можно не надо?
Согласен. Людям не нужен еще один способ программы сообщения об ошибке — им нужно чтобы самой ошибки не было. А заменять одну ошибку на другую не больно то имеет смысл.
Язык языком, но поведение чисел при переполнении определяется в первую очередь железом, и если оно не обнуляет при целочисленной операции а выставляет признак переполнения в неком регистре и оставляет в переменной максимальное значение а другое железо оставляет и признак переполнения и даёт ноль — это в стандарт языка никак не внесёшь т.к. есть зависимость поведения от конкретного железа на котором будет выполняться программа написанная на языке. Речь идёт о достаточно низкоуровневых языках, где делать обработку события переполнения и переопределять результат чтобы он не зависел от железа довольно накладно. Речь идёт о разнице скоростей в 10 и более раз.
Блин, да дочитайте до конца статью!!!
Вы столько тут настрочили, а автор как раз и говорит об этом.
Последний абзац:
Вы столько тут настрочили, а автор как раз и говорит об этом.
Последний абзац:
Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов. Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности. Вместо языков, входящих и выходящих из моды, всегда есть некие фундаментальные вещи, заслуживающие постоянного переосмысления.
Почему бы автору не пороть чушь делать спорные заявления, а сесть и попытаться реализовать все его хотелки в собственном «языке программирования 21 века»? Уверен, что некоторые из его убеждений в процессе написания изменятся.
Типичный программист 21 века делает так:
И съедает один поток процессора полностью. Но зачем оптимизировать, когда можно купить процессор мощнее?
Разве такие вычисления не будут работать медленнее? Да, будут. Но спросите себя: как часто вам приходится программировать высокопроизводительные вычисления? Полагаю, что если вы не специалист в этой области, то очень редко. А если вы и занимаетесь подобными задачами, то пользуетесь для этих целей специализированным оборудованием и компиляторами. Насколько я могу судить, типичный программист 21 века нечасто решает дифференциальные уравнения.
Типичный программист 21 века делает так:
// performance project main.go
package main
func main() {
for {
}
}И съедает один поток процессора полностью. Но зачем оптимизировать, когда можно купить процессор мощнее?
Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности. Или новый способ лучшего освоения имеющихся инструментов. Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности. Вместо языков, входящих и выходящих из моды, всегда есть некие фундаментальные вещи, заслуживающие постоянного переосмысления.
Я тоже много чего мог бы захотеть, но вот только существующие технологии накладывают на мои «хотелки» существенные ограничения. И я сознаю, что автор каждого языка программирования хотел написать самый удобный, легкий в изучении и быстрый язык программирования, но что из этого получилось мы хотя бы можем видеть. А тут у автора только мечтания и даже не намека на реализацию. Как у Кирилла.
В свое время программисты не взлюбили Fortran и COBOL, потому изобрели C++ и Java
Что они изобрели после фортрана и кобола?
Я так и не увидел, какие проблемы должен решать новый язык.
Касательно же предложений из статьи
Долой синтаксис
А как автор планирует добавлять новые конструкции? Каждой функции по отдельному синтаксису? И всё впихнуть в стандарт? И, главное, как это потом читать? Формальный синтаксис имеет ту же цель, что и математические знаки — стандартизировать элементы и упростить чтение.
Долой встроенные типы
BigInt, Decimal, Rational etc. — уже давно придуманы. Просто использовать бесконечную точность везде крайне неэффективно.
Долой практику метаязыков
Так и не понял. Сначала автор против метапрограммирования. Потом автор против больших стандартов, которые закрывают эту проблему. При том, что оба постулата напрямую противоречат постулату "Долой синтаксис", который будет провоцировать свой синтаксис на каждый чих.
Прочитайте последний абзац.
Прочитал. Со статьёй он то ли не связан, то ли противоположен ей. Или это как в байке про Ландау:
(пропущено несколько страниц выкладок)
"… из чего очевидно следует, что ..."
Новые COBOL'ы изобретать не надо.
Думаю перевод не слишком удачный. В оригинале там на странице есть интерактивный элемент, который позволяет лучше понять смысл.
Выше ответил более подробно: habr.com/company/wirex/blog/431558/#comment_19459040
Думаю перевод не слишком удачный. В оригинале там на странице есть интерактивный элемент, который позволяет лучше понять смысл.
Выше ответил более подробно: habr.com/company/wirex/blog/431558/#comment_19459040
Автор пока еще не знает о том, что читать код приходится чаще, чем писать с нуля.
хочет мурр-мурр ведь так не получится…
Автору просто надо написать много кода на паскале, с его begin...end, а потом пересесть на что-то менее многословное.
Поэтому, если бы я захотел изобрести язык программирования 21 века, вместо этого я попытался бы найти новый подход к ответственности.
Я бы попытался внимательнее относится к существенным деталям и беспощадно избавляться от любой излишней сложности.С одной стороны он хочет больше ответственности, то есть думать над тем, что пишешь (привет, Rust!), а с другой стороны он не хочет ни о чём думать, а
Автору просто надо написать много кода на паскале, с его begin...end, а потом пересесть на что-то менее многословное.
Существуют замечательные языки, придуманные не для выполнения задач, а для создания языков, которые способны их выполнять. Racket, Rebol и Forth — лишь несколько примеров.
Щито, простите? Насчет рэкета и реболла — не в курсе, а вот Форт был придуман как раз для выполнения конкретных задач управления оборудованием (телескопом). То, что в форте можно вводить новые слова, которые будут выполнять новые действия — дык это… в С++ тоже можно. И даже в С можно функций наваять. Собственно, программирование на любом языке программирования можно с некой натяжкой назвать «созданием нового языка, способного выполнять поставленную задачу».
Пошто зверушку обижаете?
Язык 21 века — это rust.
-Товарищи мы ошиблись в самом начале пути!
-Нам нужно вернуться во времена перфокарт и все переосмыслить
-Быть может переосмыслив, мы сможем писать приложения Hello World на 2% быстрее и производительней аж на целых 3%
Блин народ,… просто пишите качественное и востребованное ПО и пофиг на каком стеке и языке. Че вы все меряетесь?
-Нам нужно вернуться во времена перфокарт и все переосмыслить
-Быть может переосмыслив, мы сможем писать приложения Hello World на 2% быстрее и производительней аж на целых 3%
Блин народ,… просто пишите качественное и востребованное ПО и пофиг на каком стеке и языке. Че вы все меряетесь?
Числа с плавающей запятой в интерпретации IEEE — вообще не числа. Математика требует ассоциативности от операции их сложения.
Математика давно разделилась на два направления.
Первое — точные вычисления.
Второе — вычисления приближенные и быстрые.
Есть целые направления, которые занимаются упрощением задач, чтобы их можно было с приемлемой точностью обсчитать за приемлемое время на имеющихся средствах.
Зачем считать точно супер-пупер функцию, если ее можно разложить в ряд и отбросить длинный хвост. Зачем обсчитывать движение автомобиля с учетом всех факторов, включая встречный ветер, силу трения колес с конкретным дорожным покрытием и т.п., когда можно все свести к простой формуле.
IEEE как раз был предложен для быстрого вычисления операций для действительных чисел на электрическом вычислительном устройстве. А то, что результат плюс-минус лапоть, так оно так было задумано изначально. И если вычисляемая формула часто уже не точно отражает действительность, то что нам до погрешности таких вычислений.
А если вам нужна точность, как в аптеке, то просто используйте специально для этого разработанные инструменты. Но учтите, что они будут работать существенно медленнее.
'не' с глаголом, как известно, пишется раздельно, однако глагола 'взлюбили' не существует, так что 'невзлюбили' — исключение
возлюбили с беглой о.
тогда должно быть или 'не возлюбили', или 'невзлюбили'
Кому должно? В естественных языках логики нет.
Не до такой степени
В естественных языках есть правила. В русском языке есть правило, по которому это слово пишется слитно. Вы можете придумать свой язык, где оно будет писаться раздельно, но это будет не русский язык.
Не путайте язык и орфографию. Вторая всегда отстаёт от первого. Нравится вам это или нет.
Но если уж говорить о правилах, то как раз таки по правилу писаться должно раздельно. А слитное написание — это исключение из правила. Не понятно зачем нужное. Ну то есть понятно, что исторически сложилось, но зачем запрещать писать по правилу — ума не приложу.
Зачем их разделять, если орфография задает написание слов языка? Не хотите писать грамотно, не пишите. Грамотное написание это все равно то, которое соответствует правилам.
Если говорит о правилах, то есть правило «Пишутся слитно с не глаголы, которые без не не употребляются», и среди примеров таких слов приводится слово «невзлюбить».
Если говорит о правилах, то есть правило «Пишутся слитно с не глаголы, которые без не не употребляются», и среди примеров таких слов приводится слово «невзлюбить».
Правила постоянно меняются. Как выдумаете почему и как?
От того, что в правиле написано, что в нём есть исключения, они от этого меньшими исключениями не становятся.
Конкретно "невзлюбить" без "не" вполне употребляется, но используется другая форма той же самой приставки: http://www.drevoslov.ru/wordcreation/morphem/1010-voz-vozo-vz-vos-vs
Вот "возлюбить" и надо писать раздельно с "не". Слово "взлюбить" не употребляется, потому и не должно появляться в предложении, неважно, какое слово идет перед ним.
Исключения — это не правило. Правило это то, что надо делать с исключениями из другого правила, ну или из другой части правила. Есть правило "не с глаголами пишется раздельно", есть исключения, где "не" пишется по-другому, есть правило "не с такими глаголами пишется слитно", а не через дефис например.
Смутно вспоминаю язык GARF и команду «подставить Ю вместо Я в вещь Щ»
www.mediafire.com/?h303jm3czojl17x
bolknote.ru/all/4181
www.mediafire.com/?h303jm3czojl17x
bolknote.ru/all/4181
Где-то я такое видел, не могу вспомнить…
точно 1С: предприятие… А-А-А-А!
точно 1С: предприятие… А-А-А-А!
а Windows не начнет загружаться за 2 секунды.Но он очень, очень близко! Windows 8.1 у меня запускается ровно за 3 секунды, включая прохождение BIOS, так что вполне возможно, что сама операционка грузится за две!
Но, скорее всего, этот день никогда не настанет.
Он не запускается за три секунды — он просто не полностью выключается см. «гибридный спящий режим». Когда ему нужно поставить обновления или вы выбираете «завершение работы» или аккумулятор в ноутбуке сел, то загружается он положенные десятки секунд, как и остальные системы.
Нет, три секунды — это загрузка с нуля, без разницы, завершение ли это работы, или просто выдёргиваю провод питания (это не ноут, это MicroITX коробка). А десятки секунд пожалуй загрузка может идти только с HDD. Windows 10 на большом десктопе вместе с BIOS грузится за 5 секунд (и это долго).
Поправка: 5 секунд учёта без BIOS.
Поправка: 5 секунд учёта без BIOS.
Sign up to leave a comment.
Если изобрести язык программирования 21 века