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

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

Алан Кей, автор SmallTalk, работает над экспериментальной системой STEPS – средой, которая способна заменить собой операционную систему и прикладные программы, при этом объём кода этой среды не должен превышать 20 000 (двадцать тысяч!) строк кода. Возможно, многие об этом уже слышали. Это одна из попыток воплощения мечты любого программиста: написать всё заново и красиво. Но возможно ли это?
Двадцать тысяч строк кода, которые потрясут мир?

Опять 640K

Если знаменитые 640K разделить на 20 тысяч строк кода, то получается по 32 байта на строку – это очень похоже на правду. Похоже, Алан Кей держит в уме именно этот ориентир, просто стесняется произнести вслух: «640K хватит всем».

Билл Гейтс об этом догадался ещё 3 десятка лет назад. Деньги его испортили потом, а поначалу он был правильным пацаном: его BASIC занимал всего 4К. Со временем он догадался приспособить закон Мура к размеру ПО и размеру своих доходов, и ему стало не до краткости.

В юности родители Билла даже водили его к психиатру, видя одержимость их отпрыска программированием. Но со временем Билл перестал программировать, потому что стал боссом. «Раньше я любил лето. Но когда вырос, то понял, что лето может быть круглый год, лишь бы были деньги. Теперь я люблю деньги».

Было бы наивно думать, что раздутый код пишется только в Редмонде. Даже Линус сокрушается, глядя на своё творение: «Ядро раздутое и огромное». С каждым новым релизом ядро Linux теряет порядка 2% производительности. И это неизбежно, считает могучий финн.

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

Грамотная, ювелирная декомпозиция способна творить чудеса, главное – это увидеть повторяющиеся фрагменты, выделять их в отдельные абстракции и затем упрощать. У Алана Кея это получается: код, реализующий протокол TCP/IP, занимает 160 строк. Не один он такой умный. Ховик Меликян приводит пример, когда программа из 80000 строк кода на Си++ и 55000 строк кода на VB заменялась 10 строками на шелл-скрипте.

Но возможно ли двадцатью тысячами строк кода заменить всё? Можно, но только если отказаться от многих стандартов. Например, веб-страницы, с точки зрения авторов STEPS, нужно заменить документами, используя гиперссылки. Т.е. «неправильные пчелы и неправильный мед» (http, html, css и проч.) заменяются на правильные. И так почти во всём.

Что там за такой волшебный код?

И что из себя будет представлять этот код? Хорошо, если бы он не был «помехами в телеграфной линии». Роберт Себеста о таком коде пишет: «Даниель Мак-Кракен однажды отметил, что чтение и анализ программы из четырёх строк, написанных на языке APL, заняли у него четыре часа».

В этой системе есть высокоуровневые языки OMeta и Nile, синтаксис которых смахивает на С и Python соответственно. Программы на них в конечном итоге транслируются в программы на низкоуровневом языке Nothing. Вот пример на OMeta: синтаксис калькулятора:
Двадцать тысяч строк кода, которые потрясут мир?
С виду – ничего волшебного, легко читается и понимается.

Почему это невозможно даже теоретически.

Чтобы помочь задумкам Алана Кея по завоеванию мирового господства, нам придётся приучить себя к аскетизму. Возьмём, к примеру, текстовый редактор. На дворе 21 век, но проверки орфографии в нём быть не должно. Почему? Да потому что она не впишется в эти 20 тысяч. Естественные языки сложны. Если для анализа текста на каком-то языке вдруг каким-то чудом хватит ста строк кода, то надо учесть, что число языков, вообще-то, измеряется тысячами. Но даже если число языков приравнять к числу государств, то эти сто строк надо умножить ещё на двести. Получаются те самые 20 тысяч…

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

Даже если предположить, что 20 % кода покроет 80 % потребностей пользователей, то окажется, что у каждого 20% неудовлетворённых потребностей окажутся разными. Кому-то будет нужен Фотошоп, кому-то – Автокад, а кому-то – и вовсе Дип Фриц. И так во многом.

Причины, по которым STEPS не «взлетит».



1) В разработку ПО по всему миру вложены триллионы долларов, большая часть из которых – вовсе не компаниями, с которыми потенциально конкурирует STEPS. Под неё нет даже компиляторов самых распространённых языков, поэтому пока нет даже намёка на возможность переноса наработанного.

2) Нет потребности в таком кратком коде. Ради экономии памяти? Память стоит копейки, её объём даже на простейших устройствах превышает те самые 640К. Может, программы будут выполняться быстрее? Да нет, все программы в этой системе сначала транслируются в программы на низкоуровневом языке Nothing, и только затем исполняются. По оценке самого Кея, его код примерно на 30% медленнее традиционного.

Это самые очевидные причины. Так что разработки Алана Кея и его команды не смогут вытеснить современные ОС, браузеры, офисные приложения.

А если STEPS вдруг станет популярной?

1) Тогда крупнейшие налогоплательщики типа Microsoft, Apple, Google, Adobe и прочих убедительно докажут домохозяйкам и правительствам, почему подходы Кея ошибочны. И вообще, они нарушают массу патентов. Под STEPS нет привычных приложений. Данные на компьютерах не защищены, безопасность не обеспечивается.

2) Против 20 тысяч строк кода, которые потрясут мир, выступит даже великий и ужасный Линус! Ибо чем ему заниматься? Перетаскиванием диванов? Даже у тайно симпатизирующих найдутся причины противиться такой перспективе.

3) Вирусописатели обнаружат, что система STEPS чрезвычайно к ним дружелюбна. А там и антивирусные компании подтянутся. Google популярно объяснит, что хранить данные на компьютере уже совсем не комильфо: пусть данные хранятся в облаке, а «корпорация добра» напишет для нас свои 20 тысяч строк кода.

Это далеко не всё…

Чем тогда станет STEPS?

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

Коментарии статьи на Habrahabr

k1b0rg

Создатели MenuetOS и KolibriOS с вами не согласятся.

yomayo

А с чем не согласятся? Интересные идеи? Очень. Имеет шанс потеснить существующее ПО? Очень малый, максимум — это какая-то ниша. Повлияет на существующие подходы в разработке ПО? Хотелось бы. Может, кто-то почерпнёт оттуда идеи, как когда-то у Xerox почерпнули идеи GUI, ими были Apple и MS.

africaunite

Правильно, отлично! Но для чего столько сарказма в статье?

HandleX

А вот кстати насчёт GUI. Как раз таки в Xerox PARC господин Алан Кей и родил GUI, используя Smalltalk в качестве OS — в то доброе старое время Smalltalk не использовал VM, а работал на реальном железе.

Окошки остались, про Smalltalk незаслуженно забыли. Алан Кей же до сих пор занимается тем, что ему нравится, с улыбкой смотря на сегодняшнее bloatware ))

mayorovp

Напротив, KolibriOS — наглядное свидетельство, что даже очень маленькая ОС не помещается в 20 000 строк кода.

yogev_erza

Ну, если OS будет совсем-совсем мало уметь, то в 20 тысяч строк она сможет поместиться. KolibriOS, при всех шутках о том, как мало она умеет, на самом деле умеет не так уж мало.

mayorovp

Но кому нужна такая ОС, которая умеет еще меньше, чем Колибри? Так ведь можно и интерпретатор Бэйсика поместить в 4Кб, и обозвать операционной системой. Да, когда-то это было круто. Да, кто-то до сих пор этим пользуется. Но на современный компьютер такое изделие ставить глупо.

yogev_erza

Тут ещё от языка программирования зависит. На каком-то языке можно и в 1 строчку всё вместить.

Kirhgoff

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

Shark

Я так понимаю, они не просто обыкновенную ОС хотят написать, но в 20 000 строк, а представить какую-то новую парадигму, по которой ОС в привычном виде будет вообще не нужна.

AterCattus

Интересно, что бы Никлаус Вирт сказал про данную систему и подход к ее созданию.

yomayo

Вообще-то взгляды Алана Кея и Николауса Вирта немного разнятся. Кей – автор термина «Объектно-ориентированное программирование». А Вирт (далее цитирую), говоря об ООП, неоднократно отмечал, что оно является достаточно тривиальным расширением того же структурного подхода, сдобренным новой терминологией, и вряд ли может претендовать на звание «революционной методологии программирования».

AterCattus

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

Я не подразумевал ООП в каком-либо виде. Минус не мой.

yomayo

ETH Zurich разрабатывает свою ОС А2 на Активном Обероне. Не знаю, какова там роль Вирта, но он работает в ETH Zurich и является идейным вдохновителем всех их разработок.

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

potan

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

sheknitrtch

Я глубоко уважаю Алана Кея, он всегда мыслил широко. Начиная с системы Smalltalk, первых GUI, проекта OLPC, а вот теперь и STEPS. Судя по списку публикаций STEPS развиваются с 2007 года. На Компьютерре была статья о STEPS. Даже если новая операционная система не выстрелит, уверен, что многие идеи перетекут конкурентам и станут мейнтсримом (как раньше ООП, метапрограммирование, JIT компиляция, GUI стали повсеместно распространены).

qxfusion

Идея отличная, но только в концепции вычислительного кластера на микроустройствах, например как Intel представила в формфакторе SD карты. Концепция хард архитектуры как Swarm и STEPS была бы очень кстати, нужно лишь добавить поддержку OpenMP

zaquest

Отличная идея. Только что-то про Nothing ничего найти не могу, кроме этого — The Nothing programming language. Может кто-нибудь поделится?

Goodkat

Поддерживаю идею!

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

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

Кому-то будет нужен Фотошоп

Можно сократить количество используемых цветов до 256 или лучше даже 16 — это заметно упростит графические редакторы типа Фотошопа позволив им вписаться в те 20000 строк и высвободит много ресурсов затрачиваемых сейчас на расчёт сложной графики! Фирма Apple, один из лидеров среди мобильных ОС уже начала воплощать это идею заменив свои красивые многоцветные объёмные иконки простыми векторными с минимумом цветов!

крупнейшие налогоплательщики типа Microsoft, Apple, Google, Adobe и прочих убедительно докажут домохозяйкам и правительствам, почему подходы Кея ошибочны

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

Вирусописатели обнаружат, что система STEPS чрезвычайно к ним дружелюбна. А там и антивирусные компании подтянутся.

Вирусам не останется никаких шансов — ведь в системе из 20000 строк будет уже всё необходимое, а значит запускать сторонние исполняемые программы будет ненужно! Удалив функцию запуска чужого кода можно сэкономить ещё несколько драгоценных строчек кода и одним махом решить проблемы с вредоносным ПО!

Она останется голубой мечтой поэта.

А вот это вы зря здесь написали — из-за вас Роснепотребнадзор может заблокировать Хабр за пропаганду и всё такое!

kekekeks

всего 16 правил без сключений

Ложь. Это в первоначальном варианте (на котором говорить толком нельзя) так было, в текущем виде язык оброс ещё кучей правил и исключениями.

utkorose

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

olekl

«Можно сократить количество используемых цветов до 256 или лучше даже 16» — Фотографам расскажите, ага. И производителям фотоаппаратов.

uSide

Все-таки юзеру Goodkat стоило добавить тег sarcasm

yul

Чтобы люди окончательно разучились определять сарказм? Нет уж.

1eqinfinity

Все эти языки следует заменить одним — эсперанто.

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

А, я только что понял, что это вы с сарказмом :)

Halt

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

leventov

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

John_Minority

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

Вся наука построена на абстракция, вся техника из них создана.

usefree

Думаю, не стоит воспринимать посыл Алана Кея буквально («20 000 строк кода»). Сокращение количества «дублирующегося»(выполняющего одинаковые цели) кода — это естественный процесс оптимизации, который можно в недалекой перспективе рассматривать как обязательный этап развития технологий с открытым кодом.

Shark

Нет потребности в таком кратком коде

Ага, конечно. Там чисто физически много ошибок не влезет :) А еще разработчикам гораздо проще держать в голове 20 000 строк кода, чем многие миллионы (которые, кстати, никто не держит, потому что не реально, и отчасти поэтому возникают эти самые ошибки). В общем, если взлетит, то надеюсь что оно будет феноменально стабильным, ведь с таким объемом его можно отлично отладить, вплоть до использования всяких научных штук вроде доказательного программирования.

potan

Кстати, я заметил за собой, что на знакомом языке (обычно Haskell или Scala, но верно и для C) читаю чужой код, написанный в компактном «безточечном» стиле, читаю быстрее, чем эквивалентный, на расписанный на много строк и с большим количеством переменных. В освоении APL я не справился с большим количеством стандартных функций, значки для которых надо выучить.

lostmsu

Удивительно! Как же это вы более короткий код читаете быстрее более длинного?

mayorovp

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

(конструкция взята с потолка как пример, я не знаю, что она означает и возможна ли, прошу за это не пинать)

potan

Конечно, до маразма доводить не стоит. Но когда заводят пермененную ровно на одно использование, читабельности это на мой вкус не прибавляет. Хотя знаю, что многие со мной не согласятся.

SerCe

Мне кажется это пересекается с идеей микроядра и Minix Таненбаума.

imwode

Я не программист, но…
Мне это напоминает архиватор, который пакует фильм в один байт.
20 тысяч строк кода? Я могу написать это за одну строчку.
Вопрос в том, какого размера будет компилятор и в какой машинный код скомпилируется эта одна строка.
Если у тебя анализ кода из 4-х строк занимает 4 часа, чем хорош такой код? Это же код, написанный на языке высокого уровня.

Хотел написать, что не указано на каком языке будут написаны эти 20 тысяч строк, но потом понял, что не знаю, что такое SmallTalk. Пошел, посмотрел, понял, что коммент мимо.

Но оставлю для истории.

neverman

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

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

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

Может время такое. Подсобрать что-то из раскиданного по разным песочницам.

gatoazul

Рекомендую еще посмотреть код Кея по разбору пакетов TCP. Красиво выглядит, черт побери.
blog.rafaelferreira.net/2008/04/couple-of-interesting-dsls.html

Halt

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

А за ссылку спасибо.

iroln

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

Cim

Вообще, интересно. Может быть в будущем STEPS, как и Smalltalk, на котором почти ничего не разрабатывается, но который стал вдохновением для множества отличных языков, станет системой из которой позаимствуют многие решения. Кто знает… Например, подход «всё — документ» мне очень нравится. Кажется, это действительно интересно.

Alesh

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

multik

Если изготовители устройств решат помочь Кею и будут хранить драйвера в самих устройствах, то «раздутое ПО» просто сменит место своего >хранения.

Тут вы не правы — в данном конкретном случае у меня будут хранится только драйвера тех устройств которые у меня имеются — а других не будет (даже на самих устройствах). Так что объём ПО драйверов будет значительно меньше.

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

Shark

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

potan

Можно было бы, если бы не желание повторно использовать код старого драйвера.

yshurik

Inferno OS близка к этой идее. Правда немного побольше 20К строк, но системя очень компактна и в ней очень просто разобраться да и читать там код одно удовольствие.

Lol4t0

программа из 80000 строк кода на Си++ и 55000 строк кода на VB заменялась 10 строками на шелл-скрипте.

Ничего удивительного. Замень 10 строчками на shell можно
* Браузер: wget ya.ru -O- | less

* Текстовый процессор, полностью совместимый с OpendDocument и OpenXML (gzip и vi к вашим услугам)

* Dropbox/GoogleDrive/etc (программы для копирования файлов)
и многое другое

kemsky

...55000 строк кода на VB заменялась 10 строками на шелл-скрипте.

очень хотелось бы посмотреть, если это не wget и тп.

Sild

Думаю тут расчет именно на вызовы ранее написанных программ.

Shark

Dropbox/GoogleDrive/etc

Самый обыкновенный rsync чего стоит. Ему лишь бы место куда копировать :)

Emin

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

zencd

Цена поддержки раздутого кода… Она велика.

Emin

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

С другой стороны, объём кода может расти и за счёт инфраструктуры. Т.е. можно тупо вшить настройки для частного случая в код самой программы. А можно создать менеджер настроек, который позволит разгружать настройки из конфигурационного файла. Более того, часто проще написать один компонент на все случай жизни, чем каждый раз подстраивать код под конкретного заказчика.

zencd

Раздутый код — это данность которую вы стали оправдывать низкой ценой поддержки (с чем я не согласился). Так что какая разница насколько криворук программист и что можно вынести в настройки…

mynameco

Пользователю все равно сколько строк кода в его OS (Но как программист я за унификацию).

sferrka

Какой то многословный язык. И вообще мерить нужно не только строчки кода языка, но в большей степени строчки кода компилятора. Иначе я могу написать все на свете одной строчкой на моем языке.
superSystem.start();
А уж компилятор сам знает, что с ней делать :-)

yshurik

Так будет в C++1x: auto auto(auto auto) { auto; } Всё остальное сделает компилатор.

sferrka

О чем и речь.

Doktor_Gradus

Главное, собрать с правильными ключами.

Alexey2005

Оптимизировать код по размеру имело смысл, когда объёмы кода и данных были хотя бы сравнимы. Сейчас же объёмы данных растут с чудовищной скоростью. Фильм 10Гб объёмом — давно не предел. Одна-единственная фотография в raw-формате занимает больше места, чем весь образ диска с Windows XP.

При таком раскладе уменьшение размера кода — это экономия на спичках, и дальше будет только хуже: восьмибитные фильмы ушли в прошлое, сейчас трудно найти что-либо меньше FullHD 10bit. А в перспективе уже маячит 4K-разрешение, ещё и в 3D (то есть вдвое больше весит), ещё и с повышенной частотой кадров (потому что какой-то маркетолог сказал, что так смотрится плавнее, хотя реально разницы не ощущается). На андроидофоны все стремятся заливать непременно loseless-музыку с супервысокой частотой дискретизации и шестиканальным звуком (чтобы потом слушать всё это через дешёвые китайские наушники). Ну и т.д.

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

sferrka

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

dozent

Простой пользователь может и не понимать как работает его система

bondbig

Одна-единственная фотография в raw-формате занимает больше места, чем весь образ диска с Windows XP

Это что ж за RAW такой? У меня сенсор 24 мегапиксела и raw получается ~30 мегабайт.

amarao

Судорожно пытаюсь представить код для драйверов в 20к строк. Мечты.
find /github/linux/drivers -type f -name "*.c"|xargs wc -l
2102036 total
ДВА МИЛЛИОНА СТРОК.

Для понимания:
find. -type f -name "*.c"|wc -l
13056
13 тысяч файлов. Средний драйвер — полторы строки.

Хаха. Уносите мечтателя.

potan

В драйверах очень много служебного кода, который связан не с логикой работы устройства, а с управлением памятью, стыковкой интерфейсов, встраиванием в ОС и тп. Если все это переложить на DSL, а драйверу оставить форматы регистров и потоки данных, то объем кода (и количество багов) сократится.

amarao

И код DSL, который сможет заменить собой 13 тысяч файлов на Си, будет сколько строк размером? Ладно, хрен с ним, с кодом. В том же каталоге:
egrep -r '".+"' *|wc -l
444493
444 тысячи строк кода, содержащих строковые константы. Их тоже DSL будет генерировать? Глупость и чушь, честное слово.

DarthVictor

Хаха. Уносите мечтателя.

Сдается мне Алану Кею это уже говорили не раз: когда он придумывал Smalltalk, когда он придумывал ноутбук, когда он придумывал графический интерфейс.

amarao

Ок, ок. Подождём. Я хочу посмотреть как он 13 тысяч устройств на 20 тысяч строк кода опишет.

Assimilator

Чтобы помочь задумкам Алана Кея по завоеванию мирового господства, нам придётся приучить себя к аскетизму. Возьмём, к примеру, текстовый редактор. На дворе 21 век, но проверки орфографии в нём быть не должно. Почему? Да потому что она не впишется в эти 20 тысяч. Естественные языки сложны. Если для анализа текста на каком-то языке вдруг каким-то чудом хватит ста строк кода, то надо учесть, что число языков, вообще-то, измеряется тысячами. Но даже если число языков приравнять к числу государств, то эти сто строк надо умножить ещё на двести. Получаются те самые 20 тысяч…

Ёзрпт… Для проверки орфографии языка именно что должна быть программа по проверке орфографии языка.

Во-первых, она будет работать везде, где нужно вводить текст, и нам не придётся наблюдать ошибки вроде вашего: «раздутый код пишется только Редмонде.»

Во-вторых, нам не придётся обновлять стопятьсот словарей на предмет нового слова.

Хочется руки нах отрывать за 400+ мегабайтные скачки «универсальных» драйверов, со встроенной рекламой и блоатварями. Автор, закрой браузер и иди доучивать ООП с инкапсуляцией.

iroln

На дворе 2014 год. Почему до сих пор каждый изобретает свой велосипед с проверкой орфографии? В MS Word одна, в Google Chrome другая, в Firefox третья, в iOS четвёртая и т. д. Ах да, забыл, в MS Excel и Skype её до сих пор нет, в текстовых редакторах вроде Notepad++ более-менее некостыльное решение появилось совсем недавно, SublimeText умеет только подсвечивать, но не исправлять. Можно привести ещё с десяток примеров велосипедов/костылей/отсутствия проверки орфографии в ПО. Когда же это закончится, вот что я хочу узнать. Когда будет единая система проверки орфографии и грамматики для всех мировых языков, чтобы словари и правила обновлялись автоматически, чтобы такая система была кроссплатформенной и могла быть использована в любом ПО, которое работает с текстом? Об этом Раскин уже давным-давно писал в своей книге, а бардак как был, так и есть, и никто не собирается это исправлять.

Borz

быть может вырву из контекста, но в вашей фразе есть неточность.

Ах да, забыл, в MS Excel и Skype её до сих пор нет

1) MS Excel (проверял в 2013 версии) прекрасно показывает проверку орфографии по F7. А «на лету» в табличном процессоре она и не требуется
2) в Skype for Mac проверка орфографии есть (если верить форумам). под Linux, насколько мне помнится, тоже работает на уровне ОС.

iroln

Да, признаю, что в Excel есть проверка по F7, но такая реализация неудобна, особенно если в книге несколько листов, т. к. разрывает контекст и распыляет внимание. В «табличном процессоре» выполняются не только расчёты, проверка орфографии «на лету» была бы полезна во многих случаях. Что мешает сделать её отключаемой?

Skype for Mac не пользовался, тут не могу знать, говорил только про версию для Windows. Просто вот в чём штука. Майкрософт давно внедрила проверку в Word, даже покупала модуль проверки у российской компании до 2013 версии (все помнят фейл с Word 2013?), но не сделала эту систему частью своей же ОС, чтобы она была доступна другим приложениям через win32 api. Возникает вполне естественный вопрос: а что мешало и мешает это сделать?

Lol4t0

Сделали вообще-то в win 8

intet

Подозреваю, что в Skype for Mac есть проверка орфографии ровно по той же причине, что и в почти всех приложениях под Mac Os — система предоставляет единую орфографическую систему и даже блокнот проверяет орфографию. В windows же такой возможности нет и нужно много костылей.

Borz

тоже работает на уровне ОС

хотя да, фраза была несколько двоякой.

godlin

Мне кажется, тут ответ очень простой: люди хотят денег.

Не понятно? Очевидно, что каждая такая система предъявляет свои особые требования, и если эти требования не реализованы в стандартном ПО, значит их надо реализовать. Чтобы их реализовать, надо вложить деньги. Если ты вложил деньги в разработку этого самого стандартного ПО, считай, что ты подарил их конкурентам (раз уж оно стандартное, значит все им будут пользоваться). Таким образом, каждый разработчик, который ориентирован в первую очередь на прибыль, предпочитает ковыряться в своей песочнице, а не щедро делиться с окружающими. Отсюда, кстати, и патентные войны — не дай бог кто из конкурентов научится делать так же как мы — они ж у нас деньги отнимут — давить гадов!

StreetStrider

Нужны статьи по OMeta и Nile.

gatoazul

Дык вот: глава 2
www.vpri.org/pdf/tr2008003_experimenting.pdf

qxfusion

Мне лично почему-то это чем-то напоминает смесь из Erlang и Inferno OS.

RusMikle

А какую нишу для своего продукта видит сам Кей?

seregamorph

IMHO, короткий код — не всегда более понятный код. Все зависит от контекста и от архитектуры ПО в целом. Может пример и не очень удачен, но в perl'е некоторые вещи можно записать весьма лаконичной конструкцией, которую потом хрен разберешь. Сортировка пузырьком записывается короче и понятнее, чем quicksort, но не стоит использовать первую только из-за этого.

Хороший понятный код — это который можно понять, прочитав пару раз, он зачастую даже в комментариях не нуждается (здесь не хочу раздувать священную войну про комментирование). За свою практику встречал программистов, способных писать так, крайне редко. Объем не первичен, но безусловно важны такие вещи как форматирование, единые нотации по оформлению кода по всему проекту, единообразие концепций, паттернов, технологий и пр. Если проект богат функциональностью, то малым числом строк не обойдешься, но зато можно это дело удачно разбить на модули, сделать хорошее API, при необходимости документировать. Как правило, весь проект знать нет особой нужды, но при соблюдении ряда условий освоение и расширение новой функциональности может быть достаточно тривиальным. Поддержка такого состояния в проекте — ответственность тимлидов и ведущих программистов, инструменты вроде ревью кода в помощь.

Quiensabe

OS для нанороботов))

udachnik

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

Unix-way же.

boblenin

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

Вообще-то речь шла о переиспользовании общих мест. А языки имеют не так уж много общих языковых групп.

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

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

В том, что вы написали я не вижу логического доказательства — только утверждения подкрепленные уверенностью в своей правоте. При этом я не знаю возможно ли реализовать идею Алана Кея, хотя бы потому что по вашей статье сложно понять что же конкретно он обещает — сделать. Или систему которая реализует функциональность ОС сегодняшнего дня (тогда причем тут фотошоп?), или сделать систему реализующую все-все-все… (тогда вряд ли он такое обещал)

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

Опять же спекуляция 80-20 выглядит правдоподобной, но совершенно ни из чего логически не следует.

А что вы хотели сказать своей статьей?

africaunite

статья полезна лишь ссылкой, от которой автор так непринужденно оттолкнулся в начале

dkukushkin

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

Не получится 20 тыс. Правила не нужно хардкодить — декларативность наше все. Делается движек, который умеет работать с основными правилами языков + 10 Мб. словарь и правила (можно XML-формат) для каждого языка.

mayorovp

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

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

dkukushkin

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

Все таки XML — это данные. Данные и программа — это разное.

godlin

Все таки XML — это данные. Данные и программа — это разное.

Скажи это Лиспу ;)

phoenixweiss

Сама идеология интересна, но в вакууме она никому не нужна. Как вариант — использовать неплохие идеи повторного использования кода, либо хотя бы использования единых механизмов. В этом плане мне нравится как реализован механизм нотификации в iOS и теперь уже в современных Mac OS X эпохи «пост-Growl» — наконец-то приложения перестали изобретать свои собственные механизмы, а пользуются единым и достаточно понятным, а заодно и довольно гибко настраиваемым. То же касается и подхода к интерфейсам в Mac OS X, хотя там дела обстоят и заметно хуже.

Так что реализовать идею STEPS на совсем низких уровнях сейчас невозможно, да и опоздал он с ней лет на 30-40, ведь в то время она могла изменить мир современного ПО, попади она в нужные руки. Однако, на более высоких уровнях взаимодействия, ее можно переложить на некоторые принципы взаимодействия компонентов ПО, а вот у этой идеи уже есть будущее. Будем надеяться что гиганты рынка хоть немного присмотрятся к такому подходу, и перестанут изобретать несчетное количество новых велосипедов.

lehha

Моя программа в одну строчку:
Button['Money'].Click()
должна преобразоваться в 100к строк кода по зарабатыванию денег на бирже.

oleg0xff

Скептикам скажу, что смысл в этом довольно большой. Чем больше объема кода тем сложней все удержать в голове одному человеку. Поэтому, стали популярны подходы когда софт разбиваться на разные группы объектов которые разрабатываются разными группами разработчиков и взаимодействуют между собой через какето жёсткие API. Большинство современного софта разбито как минимум на ядро ОС и пользовательское приложение. Предполагается что разработчик приложения не должен трогать ядро, а писать только ту часть которая работает в юзер-моде. Но при сколь либо сложной задачи как правило надо изменять и ядро. А посмотрите например на ядро того же линукса — там огромный объем кода, чтоб в нем разобраться надо потратить огромное количество времени. Плюс там еще постоянно изменения происходят. т.е. чтоб хорошо разбираться в ядре линукса надо посвятить этому практически все свое время. А разработчику еще же надо кроме этого надо не только в ядре разбираться а еще в какой-то предметной области иначе что же он будет программировать если ничего кроме ядра не знает? А когда объем кода небольшой в нем реально детально разобраться и тогда вообще деление на ядро и не ядро ненужно. Каждый программист сможет внести изменения в такие функции как управление памяти, планировшкики задач и п.р. чтобы обеспечить работу своей программы наилучшем образом. т.е. теоретически он может и счас это сделать с ядром линукса, но практически там огромный объем кода и внести нужные изменения бывает нелегко.

Blumfontein

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

Чего там сложного, DI Container написал, остальное в сервисы

alman

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

В принципе, весьма близка к этому была технология
Component Object Mode, особенно если исключить из неё технологию «позднего связывания». Т.е. инструмент для декомпозии всё же был (и никуда не делся), но он «вышел из моды» и оброс сверху множеством слоёв.

Впрочем, COM технология не единственный способ, пригодный для декомпозиции. Очень хороший и перспективный иинструмент — Inter-Process Communtications на основе сообщений микроядер. Если отбросить в сторону привычную парадигму построения систем, то от объектно-ориентированного программирования можно перейти к субъектно-ориентированному.

opencoder

Отличная идея, удачи Алану Кею в реализации.

Вообще, интересно, кто-нибудь проводил анализ «bicyclity» — «велосипедности кода», подобно тому, как делают частотный анализ текста, почему бы не взять тот же дистрибутив винды и провести в нём частотный анализ самых длинных бинарных сигнатур кода, чтобы увидеть в каких местах код повторяется, уверен, что их будет ОЧЕНЬ много. Так почему бы не сделать на основе этого некое подобие словаря часто используемых кусокв, и на его основе сделать соответствующие системные вызовы ОС. Получится такой runtime-архиватор, что-то наподобие upx, только ненужно паковать/распаковывать, а словарь уже встроен в ОС. Уверен за этим будущее.

Спасибо.

grechnik

Ха. В пределах одного бинарника может быть МНОГО повторяющегося кода — все методы std::vector, std::vector и std::vector<что_угодно*> в 32-битном коде бинарно идентичны, но различны с точки зрения компилятора. По бинарнику не всегда можно судить о «bicyclity» исходников. Хуже того, любую процедуру компилятор может попытаться встроить (inline) в вызывающий код. Если мест вызова много — получаем разбухание на ровном месте. Этот пример заодно демонстрирует,

почему бы не сделать на основе этого некое подобие словаря часто используемых кусокв, и на его основе сделать соответствующие системные вызовы ОС:

часто есть выбор скорость/размер кода, и компиляторы уже давно стремятся к скорости любой ценой. Системные вызовы ОС дают некоторые накладные расходы. А размер… что размер? Тормозит программа, из-за оптимизаций не влезающая в кэш процессора — возьмите новый процессор с большим кэшем и поставьте новое, более быстрое поколение памяти. Долго грузится система, читающая с диска десятки (если не сотни) мегабайт ядра, драйверов, системных данных, разнообразных программ с библиотеками — возьмите SSD. А оптимизация по размеру никого не интересует, совсем не интересует.

sumproxy

На самом деле «не взлетит» по одной причине — в массовом распространении такой системы не заинтересовано прежде всего государство (которое и контролирует Google, Microsoft, и прочий Linux), потому что в такую систему на порядок сложнее внедрить закладку (весь код легко обозревается) и уязвимость которой может быть в итоге сведена к минимуму не на словах а на деле. Так что смеяться над STEPS — все равно что смеяться над тем что за вами подглядывают.

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

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

vlivyur

Пока читал, возникала упорная ассоциация на STEPS — Haiku. Беглый гуглёж так и не прояснил причины такой ассоциации.

neverman

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

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

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

Последняя правка: 2018-02-21    20:08

Оцените

Написать отзыв

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

Авторизация

Регистрация

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

Карта сайта


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

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

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

Компилятор

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

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

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

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

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

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

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

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

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

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

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

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

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

Прочее

Последние комментарии

2018/05/03 11:51, kt
Русский язык и программирование

2018/04/30 14:03, Автор сайта
«Двухмерный» синтаксис Python

2018/04/25 19:21, Геннадий Тышов
Программирование без программистов — это медицина без врачей

2018/03/25 21:14, Денис Будяк
Энтузиасты-разработчики компиляторов и их проекты

2018/03/21 23:37, Marat
Почему обречён язык Форт

2018/02/24 14:51, Эникейщик
Русской операционной системой должна стать ReactOS

2017/12/12 13:32, Comdiv
Отечественные разработки

2017/11/05 17:26, rst256
Электроника без электронщиков