Comments 107
UFO just landed and posted this here
А с чем не согласятся? Интересные идеи? Очень. Имеет шанс потеснить существующее ПО? Очень малый, максимум — это какая-то ниша. Повлияет на существующие подходы в разработке ПО? Хотелось бы. Может, кто-то почерпнёт оттуда идеи, как когда-то у Xerox почерпнули идеи GUI, ими были Apple и MS.
Правильно, отлично!
Но для чего столько сарказма в статье?
Но для чего столько сарказма в статье?
А вот кстати насчёт GUI. Как раз таки в Xerox PARC господин Алан Кей и родил GUI, используя Smalltalk в качестве OS — в то доброе старое время Smalltalk не использовал VM, а работал на реальном железе.
Окошки остались, про Smalltalk незаслуженно забыли. Алан Кей же до сих пор занимается тем, что ему нравится, с улыбкой смотря на сегодняшнее bloatware ))
Окошки остались, про Smalltalk незаслуженно забыли. Алан Кей же до сих пор занимается тем, что ему нравится, с улыбкой смотря на сегодняшнее bloatware ))
Напротив, KolibriOS — наглядное свидетельство, что даже очень маленькая ОС не помещается в 20 000 строк кода.
Ну, если OS будет совсем-совсем мало уметь, то в 20 тысяч строк она сможет поместиться. KolibriOS, при всех шутках о том, как мало она умеет, на самом деле умеет не так уж мало.
Но кому нужна такая ОС, которая умеет еще меньше, чем Колибри? Так ведь можно и интерпретатор Бэйсика поместить в 4Кб, и обозвать операционной системой. Да, когда-то это было круто. Да, кто-то до сих пор этим пользуется. Но на современный компьютер такое изделие ставить глупо.
Тут ещё от языка программирования зависит. На каком-то языке можно и в 1 строчку всё вместить: habrahabr.ru/post/208474/#comment_7177988
Я так понимаю, они не просто обыкновенную ОС хотят написать, но в 20 000 строк, а представить какую-то новую парадигму, по которой ОС в привычном виде будет вообще не нужна.
Интересно, что бы Никлаус Вирт сказал про данную систему и подход к ее созданию.
Вообще-то взгляды Алана Кея и Николауса Вирта немного разнятся. Кей – автор термина «Объектно-ориентированное программирование». А Вирт (далее цитирую), говоря об ООП, неоднократно отмечал, что оно является достаточно тривиальным расширением того же структурного подхода, сдобренным новой терминологией, и вряд ли может претендовать на звание «революционной методологии программирования».
Вирт сторонник простых и лаконичных, но не чрезмерно упрощенных, решений. Соотвественно, мне интересно, как бы он со своей позиции оценил подобную систему.
Я не подразумевал ООП в каком-либо виде. Минус не мой.
Я не подразумевал ООП в каком-либо виде. Минус не мой.
ETH Zurich разрабатывает свою ОС А2 на Активном Обероне. Не знаю, какова там роль Вирта, но он работает в ETH Zurich и является идейным вдохновителем всех их разработок.
Так что это в каком-то смысле конкурирующая разработка. И тоже декларируется минималистичность, мощность и гибкость.
Так что это в каком-то смысле конкурирующая разработка. И тоже декларируется минималистичность, мощность и гибкость.
Редко кто объявит себя стороником усложненных, многословных, но примитивных решений.
Однако привязанность Вирта к чисто императивному стилю, игнорирую и ООП, и функциональное, и метапрограммирование, по моему носит религиозный характер.
Однако привязанность Вирта к чисто императивному стилю, игнорирую и ООП, и функциональное, и метапрограммирование, по моему носит религиозный характер.
Я глубоко уважаю Алана Кея, он всегда мыслил широко. Начиная с системы Smalltalk, первых GUI, проекта OLPC, а вот теперь и STEPS. Судя по списку публикаций STEPS развиваются с 2007 года. На Компьютерре была статья о STEPS.
Даже если новая операционная система не выстрелит, уверен, что многие идеи перетекут конкурентам и станут мейнтсримом (как раньше ООП, метапрограммирование, JIT компиляция, GUI стали повсеместно распространены).
Даже если новая операционная система не выстрелит, уверен, что многие идеи перетекут конкурентам и станут мейнтсримом (как раньше ООП, метапрограммирование, JIT компиляция, GUI стали повсеместно распространены).
Отличная идея. Только что-то про Nothing ничего найти не могу, кроме этого — The Nothing programming language. Может кто-нибудь поделится?
Поддерживаю идею!
Естественные языки сложны. Если для анализа текста на каком-то языке вдруг каким-то чудом хватит ста строк кода, то надо учесть, что число языков, вообще-то, измеряется тысячами.Все эти языки следует заменить одним — эсперанто. Очень простой язык, несложная грамматика из всего 16 правил без сключений, фонематическое письмо и т.п. и т.д! Переход на один общий язык упростит общение людей, мы будем лучше понимать друг друга, в мире станет меньше войн!
Кому-то будет нужен ФотошопМожно сократить количество используемых цветов до 256 или лучше даже 16 — это заметно упростит графические редакторы типа Фотошопа позволив им вписаться в те 20000 строк и высвободит много ресурсов затрачиваемых сейчас на расчёт сложной графики! Фирма Apple, один из лидеров среди мобильных ОС уже начала воплощать это идею заменив свои красивые многоцветные объёмные иконки простыми векторными с минимумом цветов!
крупнейшие налогоплательщики типа Microsoft, Apple, Google, Adobe и прочих убедительно докажут домохозяйкам и правительствам, почему подходы Кея ошибочныНаоборот! Все эти компании содержат огромный штат проргаммистов, которые станут просто ненужны! Сократив разработчиков они смогут сэкономить значительную часть своих расходов, а значит увеличить прибыль!
Вирусописатели обнаружат, что система STEPS чрезвычайно к ним дружелюбна. А там и антивирусные компании подтянутся.Вирусам не останется никаких шансов — ведь в системе из 20000 строк будет уже всё необходимое, а значит запускать сторонние исполняемые программы будет ненужно! Удалив функцию запуска чужого кода можно сэкономить ещё несколько драгоценных строчек кода и одним махом решить проблемы с вредоносным ПО!
Она останется голубой мечтой поэта.А вот это вы зря здесь написали — из-за вас Роснепотребнадзор может заблокировать Хабр за пропаганду и всё такое!
всего 16 правил без сключенийЛожь. Это в первоначальном варианте (на котором говорить толком нельзя) так было, в текущем виде язык оброс ещё кучей правил и исключениями.
Дополнительные правила дописали уже профессионалы, этих 16ти не хватало. Ну, создатель вообще не лингвистом был, а врачом, так что не удивительно. А вот насчёт исключений — можно ссылку? В выдаче только информация про отстствие исключений. Нашёл это — но это исключение спорное.
«Можно сократить количество используемых цветов до 256 или лучше даже 16» — Фотографам расскажите, ага. И производителям фотоаппаратов.
Все эти языки следует заменить одним — эсперанто.
Это в принципе невозможно. Язык определяется мышлением и мышление — языком.
Даже если волшебным образом уничтожить все, кроме одного лингва франка, за несколько десятилетий он обрастет диалектами, носители которых будут с трудом понимать друг друга.
А, я только что понял, что это вы с сарказмом :)
Самодостаточная компьютерная среда в 20К строк прекрасно, но проблема в том, что абстракции текут. Даже если дойти идее выбрасывания легаси до абсолюта, вообразить аппратную платформу, которая будет исполнять Nothing, абсолютно совместимое оборудование и т. д., найдется еще примерно 20 тысяч мест, в которых придется раздувать код, чтобы решить реальную задачу.
Думаю, не стоит воспринимать посыл Алана Кея буквально («20 000 строк кода»).
Сокращение количества «дублирующегося»(выполняющего одинаковые цели) кода — это естественный процесс оптимизации, который можно в недалекой перспективе рассматривать как обязательный этап развития технологий с открытым кодом.
Сокращение количества «дублирующегося»(выполняющего одинаковые цели) кода — это естественный процесс оптимизации, который можно в недалекой перспективе рассматривать как обязательный этап развития технологий с открытым кодом.
Нет потребности в таком кратком кодеАга, конечно. Там чисто физически много ошибок не влезет :) А еще разработчикам гораздо проще держать в голове 20 000 строк кода, чем многие миллионы (которые, кстати, никто не держит, потому что не реально, и отчасти поэтому возникают эти самые ошибки). В общем, если взлетит, то надеюсь что оно будет феноменально стабильным, ведь с таким объемом его можно отлично отладить, вплоть до использования всяких научных штук вроде доказательного программирования.
Кстати, я заметил за собой, что на знакомом языке (обычно Haskell или Scala, но верно и для C) читаю чужей код, написанный в компактном «безточечном» стиле, читаю быстрее, чем эквивалентный, на расписанный на много строк и с большим количеством переменных. В освоении APL я не справился с большим количеством стандартных функций, значки для которых надо выучить.
UFO just landed and posted this here
Компактный безточечный стиль применим только для тривиальных конструкций. Если у функции хотя бы три аргумента — то лучше уж дополнительные переменные, нежели читать эти ((.).(.).(.))
(конструкция взята с потолка как пример, я не знаю, что она означает и возможна ли, прошу за это не пинать)
(конструкция взята с потолка как пример, я не знаю, что она означает и возможна ли, прошу за это не пинать)
Мне кажется это пересекается с идеей микроядра и Minix Таненбаума.
Я не программист, но…
Мне это напоминает архиватор, который пакует фильм в один байт.
20 тысяч строк кода? Я могу написать это за одну строчку.
Вопрос в том, какого размера будет компилятор и в какой машинный код скомпилируется эта одна строка.
Если у тебя анализ кода из 4-х строк занимает 4 часа, чем хорош такой код? Это же код, написанный на языке высокого уровня.
Хотел написать, что не указано на каком языке будут написаны эти 20 тысяч строк, но потом понял, что не знаю, что такое SmallTalk. Пошел, посмотрел, понял, что коммент мимо.
Но оставлю для истории.
Мне это напоминает архиватор, который пакует фильм в один байт.
20 тысяч строк кода? Я могу написать это за одну строчку.
Вопрос в том, какого размера будет компилятор и в какой машинный код скомпилируется эта одна строка.
Если у тебя анализ кода из 4-х строк занимает 4 часа, чем хорош такой код? Это же код, написанный на языке высокого уровня.
Хотел написать, что не указано на каком языке будут написаны эти 20 тысяч строк, но потом понял, что не знаю, что такое SmallTalk. Пошел, посмотрел, понял, что коммент мимо.
Но оставлю для истории.
Попытка красивая и совсем не пустая. Возможно откроет новые горизонты и что-то вернет из доброго-старого…
Если вдуматься — это просто очень хорошее направление исследования. Интересно, что из этого получится вообще и по частям. А полностью или не полностью — это уже к адептам абсолютной четкости. С ними все равно вечно разговаривать, так не важно тогда о чем.
В рамках такого эксперимента очень логично пытаться «отменить» некоторые устоявшиеся стандарты в пользу более логичных и компактных. Если они таковыми получаться. А попытка поддержать все, что наработано тяжелым трудом человечества, под гнетом неуемного маркетинга — кому угодно пупок развяжет на вагоны гигабайтов.
И это движение, в направлении понимания, что можно аннигилировать из лишних и размноженно-распухших технологий, часто не лучшим образом дублирующих по сути одну и туже функциональность. Ведь это тот мусор, что питается вниманием (временем и силами).
Может время такое. Подсобрать что-то из раскиданного по разным песочницам.
Если вдуматься — это просто очень хорошее направление исследования. Интересно, что из этого получится вообще и по частям. А полностью или не полностью — это уже к адептам абсолютной четкости. С ними все равно вечно разговаривать, так не важно тогда о чем.
В рамках такого эксперимента очень логично пытаться «отменить» некоторые устоявшиеся стандарты в пользу более логичных и компактных. Если они таковыми получаться. А попытка поддержать все, что наработано тяжелым трудом человечества, под гнетом неуемного маркетинга — кому угодно пупок развяжет на вагоны гигабайтов.
И это движение, в направлении понимания, что можно аннигилировать из лишних и размноженно-распухших технологий, часто не лучшим образом дублирующих по сути одну и туже функциональность. Ведь это тот мусор, что питается вниманием (временем и силами).
Может время такое. Подсобрать что-то из раскиданного по разным песочницам.
Рекомендую еще посмотреть код Кея по разбору пакетов TCP. Красиво выглядит, черт побери.
blog.rafaelferreira.net/2008/04/couple-of-interesting-dsls.html
blog.rafaelferreira.net/2008/04/couple-of-interesting-dsls.html
О боже, мои глаза. Ну что за мода, писать статьи на рулоне туалетной бумаги? А потом читать на широкоформатном мониторе эту колбасу. Не подскажете, нет ли плагинов, делающих из подобных западных сайтов нормальные резиновые?
А за ссылку спасибо.
А за ссылку спасибо.
Идея в том, что чем уже столбец текста, тем быстрее он читается, т. к. меньше приходится бегать глазами туда-сюда. Когда-то кто-то из юзабилити-гуру сказал, что так должно, что это readable, поэтому сейчас так делают и там где надо, и там где не надо. Соглашусь, что бывает удобно, но иногда перегибают.
Не подскажете, нет ли плагинов, делающих из подобных западных сайтов нормальные резиновые?
Легко. monosnap.com/image/jXWWv8Rl1qz1ozLCpiCuFkUsI
Кстати, я эту идею в своих задачах применял.
Текстовая табличка не требует никаких пояснений для пользователей, самостоятельно ими правится и в то же время служит самым настоящим конфигом для программы. Особенно удобно для бизнес-приложений, где полно таких таблиц.
Сюда же можно естественно добавить всякие условия типа ">5"
Текстовая табличка не требует никаких пояснений для пользователей, самостоятельно ими правится и в то же время служит самым настоящим конфигом для программы. Особенно удобно для бизнес-приложений, где полно таких таблиц.
-------------------------
| Количество | Цена |
-------------------------
| 1 | 100 |
| 2 | 190 |
-------------------------
Сюда же можно естественно добавить всякие условия типа ">5"
UFO just landed and posted this here
По моему это баян, Вирт уже делал подобное, называлось это, сорри могу ошибиться но кажется, Active Oberon. В принципе и неплохо это всё крутилось в виртуалке.
>Если изготовители устройств решат помочь Кею и будут хранить драйвера в самих устройствах, то «раздутое ПО» просто сменит место своего >хранения.
Тут вы не правы — в данном конкретном случае у меня будут хранится только драйвера тех устройств которые у меня имеются — а других не будет (даже на самих устройствах). Так что объём ПО драйверов будет значительно меньше.
Я здесь совсем не рассматриваю целесообразность практическую выгоду сложность и прочее — просто указываю на вашу логическую ошибку, надеюсь, неосознанную.
Тут вы не правы — в данном конкретном случае у меня будут хранится только драйвера тех устройств которые у меня имеются — а других не будет (даже на самих устройствах). Так что объём ПО драйверов будет значительно меньше.
Я здесь совсем не рассматриваю целесообразность практическую выгоду сложность и прочее — просто указываю на вашу логическую ошибку, надеюсь, неосознанную.
UFO just landed and posted this here
программа из 80000 строк кода на Си++ и 55000 строк кода на VB заменялась 10 строками на шелл-скрипте.Ничего удивительного. Замень 10 строчками на shell можно
* Браузер: wget ya.ru -O- | less
* Текстовый процессор, полностью совместимый с OpendDocument и OpenXML (gzip и vi к вашим услугам)
* Dropbox/GoogleDrive/etc (программы для копирования файлов)
и многое другое
Не совсем понял суть предложения. Раздутый код — это следствие экономических требований. Сейчас важнее скорость разработки и цена поддержки, а не эффективность программы. Думаю, что в армии и космосе приоритеты другие, и там стараются писать краткий код. Но за это довольно щедро платит государство.
Цена поддержки раздутого кода… Она велика.
Объём кода может расти за счёт криворукости программиста. Тогда поддержка стоит дорого. Но, как я понял, в статье не про этот случай.
С другой стороны, объём кода может расти и за счёт инфраструктуры. Т.е. можно тупо вшить настройки для частного случая в код самой программы. А можно создать менеджер настроек, который позволит разгружать настройки из конфигурационного файла. Более того, часто проще написать один компонент на все случай жизни, чем каждый раз подстраивать код под конкретного заказчика.
С другой стороны, объём кода может расти и за счёт инфраструктуры. Т.е. можно тупо вшить настройки для частного случая в код самой программы. А можно создать менеджер настроек, который позволит разгружать настройки из конфигурационного файла. Более того, часто проще написать один компонент на все случай жизни, чем каждый раз подстраивать код под конкретного заказчика.
Пользователю все равно сколько строк кода в его OS (Но как программист я за унификацию).
Какой то многословный язык. И вообще мерить нужно не только строчки кода языка, но в большей степени строчки кода компилятора.
Иначе я могу написать все на свете одной строчкой на моем языке.
А уж компилятор сам знает, что с ней делать :-)
Иначе я могу написать все на свете одной строчкой на моем языке.
superSystem.start();А уж компилятор сам знает, что с ней делать :-)
Оптимизировать код по размеру имело смысл, когда объёмы кода и данных были хотя бы сравнимы. Сейчас же объёмы данных растут с чудовищной скоростью. Фильм 10Гб объёмом — давно не предел. Одна-единственная фотография в raw-формате занимает больше места, чем весь образ диска с Windows XP.
При таком раскладе уменьшение размера кода — это экономия на спичках, и дальше будет только хуже: восьмибитные фильмы ушли в прошлое, сейчас трудно найти что-либо меньше FullHD 10bit. А в перспективе уже маячит 4K-разрешение, ещё и в 3D (то есть вдвое больше весит), ещё и с повышенной частотой кадров (потому что какой-то маркетолог сказал, что так смотрится плавнее, хотя реально разницы не ощущается). На андроидофоны все стремятся заливать непременно loseless-музыку с супервысокой частотой дискретизации и шестиканальным звуком (чтобы потом слушать всё это через дешёвые китайские наушники). Ну и т.д.
Потому чем вылизывать код по размеру, лучше бы придумал новый алгоритм сжатия данных. Выиграв хотя бы 2%, он сэкономил бы куда больше места.
При таком раскладе уменьшение размера кода — это экономия на спичках, и дальше будет только хуже: восьмибитные фильмы ушли в прошлое, сейчас трудно найти что-либо меньше FullHD 10bit. А в перспективе уже маячит 4K-разрешение, ещё и в 3D (то есть вдвое больше весит), ещё и с повышенной частотой кадров (потому что какой-то маркетолог сказал, что так смотрится плавнее, хотя реально разницы не ощущается). На андроидофоны все стремятся заливать непременно loseless-музыку с супервысокой частотой дискретизации и шестиканальным звуком (чтобы потом слушать всё это через дешёвые китайские наушники). Ну и т.д.
Потому чем вылизывать код по размеру, лучше бы придумал новый алгоритм сжатия данных. Выиграв хотя бы 2%, он сэкономил бы куда больше места.
Так речь и не идет об экономии жестких дисков, речь о минимизации количества логических ходов и, как следствие, упрощение понимания системы.
Одна-единственная фотография в raw-формате занимает больше места, чем весь образ диска с Windows XPЭто что ж за RAW такой? У меня сенсор 24 мегапиксела и raw получается ~30 мегабайт.
Судорожно пытаюсь представить код для драйверов в 20к строк. Мечты.
find /github/linux/drivers -type f -name "*.c"|xargs wc -l
2102036 total
ДВА МИЛЛИОНА СТРОК.
Для понимания:
find. -type f -name "*.c"|wc -l
13056
13 тысяч файлов. Средний драйвер — полторы строки.
Хаха. Уносите мечтателя.
find /github/linux/drivers -type f -name "*.c"|xargs wc -l
2102036 total
ДВА МИЛЛИОНА СТРОК.
Для понимания:
find. -type f -name "*.c"|wc -l
13056
13 тысяч файлов. Средний драйвер — полторы строки.
Хаха. Уносите мечтателя.
В драйверах очень много служебного кода, который связан не с логикой работы устройства, а с управлением памятью, стыковкой интерфейсов, встраиванием в ОС и тп. Если все это переложить на DSL, а драйверу оставить форматы регистров и потоки данных, то объем кода (и количество багов) сократится.
Хаха. Уносите мечтателя.
Сдается мне Алану Кею это уже говорили не раз: когда он придумывал Smalltalk, когда он придумывал ноутбук, когда он придумывал графический интерфейс.
Чтобы помочь задумкам Алана Кея по завоеванию мирового господства, нам придётся приучить себя к аскетизму. Возьмём, к примеру, текстовый редактор. На дворе 21 век, но проверки орфографии в нём быть не должно. Почему? Да потому что она не впишется в эти 20 тысяч. Естественные языки сложны. Если для анализа текста на каком-то языке вдруг каким-то чудом хватит ста строк кода, то надо учесть, что число языков, вообще-то, измеряется тысячами. Но даже если число языков приравнять к числу государств, то эти сто строк надо умножить ещё на двести. Получаются те самые 20 тысяч…
Ёзрпт…
Для проверки орфографии языка именно что должна быть программа по проверке орфографии языка.
> Во-первых, она будет работать везде, где нужно вводить текст, и нам не придётся наблюдать ошибки вроде вашего: «раздутый код пишется только Редмонде.»
> Во-вторых, нам не придётся обновлять стопятьсот словарей на предмет нового слова.
Хочется руки нах отрывать за 400+ мегабайтные скачки «универсальных» драйверов, со встроенной рекламой и блоатварями.
Автор, закрой браузер и иди доучивать ООП с инкапсуляцией.
На дворе 2014 год. Почему до сих пор каждый изобретает свой велосипед с проверкой орфографии? В MS Word одна, в Google Chrome другая, в Firefox третья, в iOS четвёртая и т. д. Ах да, забыл, в MS Excel и Skype её до сих пор нет, в текстовых редакторах вроде Notepad++ более-менее некостыльное решение появилось совсем недавно, SublimeText умеет только подсвечивать, но не исправлять. Можно привести ещё с десяток примеров велосипедов/костылей/отсутствия проверки орфографии в ПО. Когда же это закончится, вот что я хочу узнать. Когда будет единая система проверки орфографии и грамматики для всех мировых языков, чтобы словари и правила обновлялись автоматически, чтобы такая система была кроссплатформенной и могла быть использована в любом ПО, которое работает с текстом? Об этом Раскин уже давным-давно писал в своей книге, а бардак как был, так и есть, и никто не собирается это исправлять.
быть может вырву из контекста, но в вашей фразе есть неточность.
1) MS Excel (проверял в 2013 версии) прекрасно показывает проверку орфографии по F7. А «на лету» в табличном процессоре она и не требуется
2) в Skype for Mac проверка орфографии есть (если верить форумам). под Linux, насколько мне помнится, тоже работает на уровне ОС.
Ах да, забыл, в MS Excel и Skype её до сих пор нет
1) MS Excel (проверял в 2013 версии) прекрасно показывает проверку орфографии по F7. А «на лету» в табличном процессоре она и не требуется
2) в Skype for Mac проверка орфографии есть (если верить форумам). под Linux, насколько мне помнится, тоже работает на уровне ОС.
Да, признаю, что в Excel есть проверка по F7, но такая реализация неудобна, особенно если в книге несколько листов, т. к. разрывает контекст и распыляет внимание. В «табличном процессоре» выполняются не только расчёты, проверка орфографии «на лету» была бы полезна во многих случаях. Что мешает сделать её отключаемой?
Skype for Mac не пользовался, тут не могу знать, говорил только про версию для Windows. Просто вот в чём штука. Майкрософт давно внедрила проверку в Word, даже покупала модуль проверки у российской компании до 2013 версии (все помнят фейл с Word 2013?), но не сделала эту систему частью своей же ОС, чтобы она была доступна другим приложениям через win32 api. Возникает вполне естественный вопрос: а что мешало и мешает это сделать?
Skype for Mac не пользовался, тут не могу знать, говорил только про версию для Windows. Просто вот в чём штука. Майкрософт давно внедрила проверку в Word, даже покупала модуль проверки у российской компании до 2013 версии (все помнят фейл с Word 2013?), но не сделала эту систему частью своей же ОС, чтобы она была доступна другим приложениям через win32 api. Возникает вполне естественный вопрос: а что мешало и мешает это сделать?
Подозреваю, что в Skype for Mac есть проверка орфографии ровно по той же причине, что и в почти всех приложениях под Mac Os — система предоставляет единую орфографическую систему и даже блокнот проверяет орфографию. В windows же такой возможности нет и нужно много костылей.
Мне кажется, тут ответ очень простой: люди хотят денег.
Не понятно? Очевидно, что каждая такая система предъявляет свои особые требования, и если эти требования не реализованы в стандартном ПО, значит их надо реализовать. Чтобы их реализовать, надо вложить деньги. Если ты вложил деньги в разработку этого самого стандартного ПО, считай, что ты подарил их конкурентам (раз уж оно стандартное, значит все им будут пользоваться). Таким образом, каждый разработчик, который ориентирован в первую очередь на прибыль, предпочитает ковыряться в своей песочнице, а не щедро делиться с окружающими. Отсюда, кстати, и патентные войны — не дай бог кто из конкурентов научится делать так же как мы — они ж у нас деньги отнимут — давить гадов!
Не понятно? Очевидно, что каждая такая система предъявляет свои особые требования, и если эти требования не реализованы в стандартном ПО, значит их надо реализовать. Чтобы их реализовать, надо вложить деньги. Если ты вложил деньги в разработку этого самого стандартного ПО, считай, что ты подарил их конкурентам (раз уж оно стандартное, значит все им будут пользоваться). Таким образом, каждый разработчик, который ориентирован в первую очередь на прибыль, предпочитает ковыряться в своей песочнице, а не щедро делиться с окружающими. Отсюда, кстати, и патентные войны — не дай бог кто из конкурентов научится делать так же как мы — они ж у нас деньги отнимут — давить гадов!
Нужны статьи по OMeta и Nile.
Мне лично почему-то это чем-то напоминает смесь из Erlang и Inferno OS.
А какую нишу для своего продукта видит сам Кей?
IMHO, короткий код — не всегда более понятный код. Все зависит от контекста и от архитектуры ПО в целом.
Может пример и не очень удачен, но в perl'е некоторые вещи можно записать весьма лаконичной конструкцией, которую потом хрен разберешь.
Сортировка пузырьком записывается короче и понятнее, чем quicksort, но не стоит использовать первую только из-за этого.
Хороший понятный код — это который можно понять, прочитав пару раз, он зачастую даже в комментариях не нуждается (здесь не хочу раздувать священную войну про комментирование). За свою практику встречал программистов, способных писать так, крайне редко.
Объем не первичен, но безусловно важны такие вещи как форматирование, единые нотации по оформлению кода по всему проекту, единообразие концепций, паттернов, технологий и пр.
Если проект богат функциональностью, то малым числом строк не обойдешься, но зато можно это дело удачно разбить на модули, сделать хорошее API, при необходимости документировать. Как правило, весь проект знать нет особой нужды, но при соблюдении ряда условий освоение и расширение новой функциональности может быть достаточно тривиальным. Поддержка такого состояния в проекте — ответственность тимлидов и ведущих программистов, инструменты вроде ревью кода в помощь.
Может пример и не очень удачен, но в perl'е некоторые вещи можно записать весьма лаконичной конструкцией, которую потом хрен разберешь.
Сортировка пузырьком записывается короче и понятнее, чем quicksort, но не стоит использовать первую только из-за этого.
Хороший понятный код — это который можно понять, прочитав пару раз, он зачастую даже в комментариях не нуждается (здесь не хочу раздувать священную войну про комментирование). За свою практику встречал программистов, способных писать так, крайне редко.
Объем не первичен, но безусловно важны такие вещи как форматирование, единые нотации по оформлению кода по всему проекту, единообразие концепций, паттернов, технологий и пр.
Если проект богат функциональностью, то малым числом строк не обойдешься, но зато можно это дело удачно разбить на модули, сделать хорошее API, при необходимости документировать. Как правило, весь проект знать нет особой нужды, но при соблюдении ряда условий освоение и расширение новой функциональности может быть достаточно тривиальным. Поддержка такого состояния в проекте — ответственность тимлидов и ведущих программистов, инструменты вроде ревью кода в помощь.
OS для нанороботов))
Давайте подумаем, можно объём ПО сократить, причём значительно? Возьмём, к примеру, любой текстовый редактор. Для реализации заявленной функциональности автор применяет, например, некий алгоритм поиска. Но в коде установленного на компьютере браузера тоже есть поиск, и, возможно, с таким же алгоритмом. Он же есть и в офисном пакете, и в играх, и в ОС, поверх которой всё это работает. Было бы логично этот поиск реализовать единожды, а дальше только им пользоваться. При глубоком анализе можно выявить массу повторяющихся вещей.
Unix-way же.
Да потому что она не впишется в эти 20 тысяч. Естественные языки сложны. Если для анализа текста на каком-то языке вдруг каким-то чудом хватит ста строк кода, то надо учесть, что число языков, вообще-то, измеряется тысячами.
Вообще-то речь шла о переиспользовании общих мест. А языки имеют не так уж много общих языковых групп.
А драйвера? Если одному типу устройств хватит тех же 100 строк, то типов устройств куда больше, чем число языков и государств.
Вообще-то устройств не так уж и много и опять же идея в том что общие места будут описаны только единожды.
В том, что вы написали я не вижу логического доказательства — только утверждения подкрепленные уверенностью в своей правоте.
При этом я не знаю возможно ли реализовать идею Алана Кея, хотя бы потому что по вашей статье сложно понять что же конкретно он обещает — сделать. Или систему которая реализует функциональность ОС сегодняшнего дня (тогда причем тут фотошоп?), или сделать систему реализующую все-все-все… (тогда вряд ли он такое обещал)
Даже если предположить, что 20 % кода покроет 80 % потребностей пользователей, то окажется, что у каждого 20% неудовлетворённых потребностей окажутся разными.
Опять же спекуляция 80-20 выглядит правдоподобной, но совершенно ни из чего логически не следует.
А что вы хотели сказать своей статьей?
Естественные языки сложны. Если для анализа текста на каком-то языке вдруг каким-то чудом хватит ста строк кода, то надо учесть, что число языков, вообще-то, измеряется тысячами. Но даже если число языков приравнять к числу государств, то эти сто строк надо умножить ещё на двести. Получаются те самые 20 тысяч…
Не получится 20 тыс. Правила не нужно хардкодить — декларативность наше все. Делается движек, который умеет работать с основными правилами языков + 10 Мб. словарь и правила (можно XML-формат) для каждого языка.
Сама идеология интересна, но в вакууме она никому не нужна.
Как вариант — использовать неплохие идеи повторного использования кода, либо хотя бы использования единых механизмов.
В этом плане мне нравится как реализован механизм нотификации в iOS и теперь уже в современных Mac OS X эпохи «пост-Growl» — наконец-то приложения перестали изобретать свои собственные механизмы, а пользуются единым и достаточно понятным, а заодно и довольно гибко настраиваемым. То же касается и подхода к интерфейсам в Mac OS X, хотя там дела обстоят и заметно хуже.
Так что реализовать идею STEPS на совсем низких уровнях сейчас невозможно, да и опоздал он с ней лет на 30-40, ведь в то время она могла изменить мир современного ПО, попади она в нужные руки. Однако, на более высоких уровнях взаимодействия, ее можно переложить на некоторые принципы взаимодействия компонентов ПО, а вот у этой идеи уже есть будущее. Будем надеяться что гиганты рынка хоть немного присмотрятся к такому подходу, и перестанут изобретать несчетное количество новых велосипедов.
Как вариант — использовать неплохие идеи повторного использования кода, либо хотя бы использования единых механизмов.
В этом плане мне нравится как реализован механизм нотификации в iOS и теперь уже в современных Mac OS X эпохи «пост-Growl» — наконец-то приложения перестали изобретать свои собственные механизмы, а пользуются единым и достаточно понятным, а заодно и довольно гибко настраиваемым. То же касается и подхода к интерфейсам в Mac OS X, хотя там дела обстоят и заметно хуже.
Так что реализовать идею STEPS на совсем низких уровнях сейчас невозможно, да и опоздал он с ней лет на 30-40, ведь в то время она могла изменить мир современного ПО, попади она в нужные руки. Однако, на более высоких уровнях взаимодействия, ее можно переложить на некоторые принципы взаимодействия компонентов ПО, а вот у этой идеи уже есть будущее. Будем надеяться что гиганты рынка хоть немного присмотрятся к такому подходу, и перестанут изобретать несчетное количество новых велосипедов.
Моя программа в одну строчку:
Button['Money'].Click()
должна преобразоваться в 100к строк кода по зарабатыванию денег на бирже.
Button['Money'].Click()
должна преобразоваться в 100к строк кода по зарабатыванию денег на бирже.
Вероятно имелось ввиду «держит в уме», а не «дежит в уме»? )
Скептикам скажу, что смысл в этом довольно большой. Чем больше объема кода тем сложней все удержать в голове одному человеку. Поэтому, стали популярны подходы когда софт разбиваться на разные группы объектов которые разрабатываются разными группами разработчиков и взаимодействуют между собой через какето жёсткие API. Большинство современного софта разбито как минимум на ядро ОС и пользовательское приложение. Предполагается что разработчик приложения не должен трогать ядро, а писать только ту часть которая работает в юзер-моде. Но при сколь либо сложной задачи как правило надо изменять и ядро. А посмотрите например на ядро того же линукса — там огромный объем кода, чтоб в нем разобраться надо потратить огромное количество времени. Плюс там еще постоянно изменения происходят. т.е. чтоб хорошо разбираться в ядре линукса надо посвятить этому практически все свое время. А разработчику еще же надо кроме этого надо не только в ядре разбираться а еще в какой-то предметной области иначе что же он будет программировать если ничего кроме ядра не знает? А когда объем кода небольшой в нем реально детально разобраться и тогда вообще деление на ядро и не ядро ненужно. Каждый программист сможет внести изменения в такие функции как управление памяти, планировшкики задач и п.р. чтобы обеспечить работу своей программы наилучшем образом. т.е. теоретически он может и счас это сделать с ядром линукса, но практически там огромный объем кода и внести нужные изменения бывает нелегко.
Двадцать тысяч строк кода, которые потрясут мир?
Чего там сложного, DI Container написал, остальное в сервисы
Грамотная, ювелирная декомпозиция способна творить чудеса, главное – это увидеть повторяющиеся фрагменты, выделять их в отдельные абстракции и затем упрощать.
В принципе, весьма близка к этому была технология Component Object Mode, особенно если исключить из неё технологию «позднего связывания». Т.е. инструмент для декомпозии всё же был (и никуда не делся), но он «вышел из моды» и оброс сверху множеством слоёв.
Впрочем, COM технология не единственный способ, пригодный для декомпозиции. Очень хороший и перспективный иинструмент — Inter-Process Communtications на основе сообщений микроядер. Если отбросить в сторону привычную парадигму построения систем, то от объектно-ориентированного программирования можно перейти к субъектно-ориентированному.
Отличная идея, удачи Алану Кею в реализации.
Вообще, интересно, кто-нибудь проводил анализ «bicyclity» — «велосипедности кода», подобно тому, как делают частотный анализ текста, почему бы не взять тот же дистрибутив винды и провести в нём частотный анализ самых длинных бинарных сигнатур кода, чтобы увидеть в каких местах код повторяется, уверен, что их будет ОЧЕНЬ много. Так почему бы не сделать на основе этого некое подобие словаря часто используемых кусокв, и на его основе сделать соответствующие системные вызовы ОС.
Получится такой runtime-архиватор, что-то наподобие upx, только ненужно паковать/распаковывать, а словарь уже встроен в ОС. Уверен за этим будущее.
Спасибо.
Вообще, интересно, кто-нибудь проводил анализ «bicyclity» — «велосипедности кода», подобно тому, как делают частотный анализ текста, почему бы не взять тот же дистрибутив винды и провести в нём частотный анализ самых длинных бинарных сигнатур кода, чтобы увидеть в каких местах код повторяется, уверен, что их будет ОЧЕНЬ много. Так почему бы не сделать на основе этого некое подобие словаря часто используемых кусокв, и на его основе сделать соответствующие системные вызовы ОС.
Получится такой runtime-архиватор, что-то наподобие upx, только ненужно паковать/распаковывать, а словарь уже встроен в ОС. Уверен за этим будущее.
Спасибо.
Ха. В пределах одного бинарника может быть МНОГО повторяющегося кода — все методы
Хуже того, любую процедуру компилятор может попытаться встроить (inline) в вызывающий код. Если мест вызова много — получаем разбухание на ровном месте. Этот пример заодно демонстрирует,
std::vector<int>, std::vector<unsigned> и std::vector<что_угодно*> в 32-битном коде бинарно идентичны, но различны с точки зрения компилятора. По бинарнику не всегда можно судить о «bicyclity» исходников.Хуже того, любую процедуру компилятор может попытаться встроить (inline) в вызывающий код. Если мест вызова много — получаем разбухание на ровном месте. Этот пример заодно демонстрирует,
почему бы не сделать на основе этого некое подобие словаря часто используемых кусокв, и на его основе сделать соответствующие системные вызовы ОС:часто есть выбор скорость/размер кода, и компиляторы уже давно стремятся к скорости любой ценой. Системные вызовы ОС дают некоторые накладные расходы. А размер… что размер? Тормозит программа, из-за оптимизаций не влезающая в кэш процессора — возьмите новый процессор с большим кэшем и поставьте новое, более быстрое поколение памяти. Долго грузится система, читающая с диска десятки (если не сотни) мегабайт ядра, драйверов, системных данных, разнообразных программ с библиотеками — возьмите SSD. А оптимизация по размеру никого не интересует, совсем не интересует.
На самом деле «не взлетит» по одной причине — в массовом распространении такой системы не заинтересовано прежде всего государство (которое и контролирует Google, Microsoft, и прочий Linux), потому что в такую систему на порядок сложнее внедрить закладку (весь код легко обозревается) и уязвимость которой может быть в итоге сведена к минимуму не на словах а на деле. Так что смеяться над STEPS — все равно что смеяться над тем что за вами подглядывают.
UFO just landed and posted this here
Подавляющее большинство инициатив реализуются либо при молчаливом согласии либо при прямой поддержке государств. И ИТ отрасль не исключение. То что вредно либо опасно увязнет в проблемах и государству не составит трудностей их устроить. Как не составит трудностей поддержать альтернативу, создать нужный образ в обществе путем манипуляций. А на поверхности вы увидите те самые «более важные в статье».
Пока читал, возникала упорная ассоциация на STEPS — Haiku. Беглый гуглёж так и не прояснил причины такой ассоциации.
Мне кажется, можно просто отдать должное инициативе и наблюдать.
Критика — да, но это же совсем не школьники себе занятие на лето придумали…
Вероятность весьма отлична от нуля для полной реализации задуманного. Там нет нереальной декларации — угодить всем.
Имхо — отрицательные прогнозы в данном случае имеют неоправданно надменное звучание.
И вообще… Перерегулирование — это способ поставить что-то на место. Не возникает же сомнений? Что текущие дистибутивы программ и объем занимаемой ими памяти(при работе) — можно уменьшить в разы. Ну а как сформировать такую тенденцию?
Такая инициатива — это пример, из которого может быть подхвачено то, что заработает хорошо. Подхвачено индустрией из того же страха — упустить некие конкурентные преимущества.
То есть Алан Кей-я можно подозревать и в более далеко идущих замыслах, и в по хорошему хитром маркетинге.
Критика — да, но это же совсем не школьники себе занятие на лето придумали…
Вероятность весьма отлична от нуля для полной реализации задуманного. Там нет нереальной декларации — угодить всем.
Имхо — отрицательные прогнозы в данном случае имеют неоправданно надменное звучание.
И вообще… Перерегулирование — это способ поставить что-то на место. Не возникает же сомнений? Что текущие дистибутивы программ и объем занимаемой ими памяти(при работе) — можно уменьшить в разы. Ну а как сформировать такую тенденцию?
Такая инициатива — это пример, из которого может быть подхвачено то, что заработает хорошо. Подхвачено индустрией из того же страха — упустить некие конкурентные преимущества.
То есть Алан Кей-я можно подозревать и в более далеко идущих замыслах, и в по хорошему хитром маркетинге.
Sign up to leave a comment.
Двадцать тысяч строк кода, которые потрясут мир?