LINUX.ORG.RU
ФорумTalks

Есть ли сегодня литературное программирование?

 ,


0

2

Я раньше как-то не вникал, но по наивности своей думал, что Кнут под этим подразумевал именно код, который доступен, и легко читаем человеком.

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

Но, решив ознакомиться, я наткнулся на это

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

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

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

getSomeCoolThing = function(){//this function gets some cool thing

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

Перемещено Pinkbyte из development



Последнее исправление: callbackhell (всего исправлений: 2)

Ответ на: комментарий от stevejobs

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

buddhist ★★★★★
()

мы живем в эпоху развитого литературного программирования

А govnokod.ru это место, куда постят кодо-анекдоты, ага.

deep-purple ★★★★★
()
Ответ на: комментарий от aido

Какой смысл в ядре использовать ООП

В ядре используется ООП в полный рост. С добрым утром.

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

поэтому все стоны о том, что С «небезопасен», больше относятся к проблемам в головах.

Но больше половины всех существующих уязвимостей - результат buffer overflow в том или ином виде. Мб все-таки небезопасен?

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

нет. таки проблемы в головах, а не в С.

Как ты думаешь, какой из двух вариантов проще и дешевле:

  • Сделать инструмент, который просто не позволяет случайно допустить ошибки подобного типа.
  • Заставить 100500 миллионов программистов писать на C код без переполнений, висящих указателей, ошибочных преобразований и других милых вещей, и всё равно обосраться и наслаждаться падающим и текущим софтом.

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

Но больше половины всех существующих уязвимостей - результат buffer overflow в том или ином виде. Мб все-таки небезопасен?

а 98% уязвимостей - в софте вообще. Он не безопасен. Проблема именно там :-)

MKuznetsov ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Ты правда веришь, что язык без классов - это гарантия отсутствия говнокодеров?

hobbit ★★★★★
()
Ответ на: комментарий от hateyoufeel

И это если забыть про всякие лиспы (Symbolics), Ada или Forth

Ты правда считаешь Forth более годным для написания ОС, чем Си? O_o Ладно еще Lisp (можно сделать статически типизируемое подмножество), но Forth?

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

Не поможет. Психология настоящего мачо, вот это всё (хотя Iron_Bug и представляется женщиной).

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Ты правда считаешь Forth более годным для написания ОС, чем Си? O_o

ОС бывают разными. Для ОС общего пользования типа Linux или Windows он плохо подходит. Какой-нибудь узкоспециализированый embedded - почему бы и нет? У Розетты, вроде, прошивка как раз на Форте и была написана.

Да, я там не писал, что эти языки лучше подходят для написания ОС. Я писал, что написание ОС на них возможно и не представляет из себя какой-либо большой проблемы.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

проще и дешевле не набирать говнокодеров.
компилятор не «позволяет допустить ошибки». он просто позволяет выполнять любые операции, которые валидны с точки зрения компилятора. ни больше, ни меньше. и если я сознательно привожу типы или работаю с указателями, никакой компилятор не должен мне мешать это делать. а если кто-то решил прострелить себе ногу, то это проблемы не мои и не компилятора. это проблемы того, кто стреляет себе в ногу. компилятор тут ни при чём.

Iron_Bug ★★★★★
()
Ответ на: комментарий от hateyoufeel

Какой-нибудь узкоспециализированый embedded - почему бы и нет?

В таком emedded ОС практически нет.

Да, я там не писал, что эти языки лучше подходят для написания ОС

Писал:

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

Да что угодно, на самом деле. Начиная от C++ (ядро BeOS и драйвера в OS X) и заканчивая Haskell (HaLVM от Galois для создания работающих напрямую поверх xen приложений). И это если забыть про всякие лиспы (Symbolics), Ada или Forth

написание ОС на них возможно и не представляет из себя какой-либо большой проблемы.

Насчет Lisp реальность с тобой не согласна, насчет Ada сказать трудно - она слишком нишевая и обычно подразумевает ОС-подобную прокладку.

tailgunner ★★★★★
()
Ответ на: комментарий от MKuznetsov

а 98% уязвимостей - в софте вообще. Он не безопасен. Проблема именно там :-)

И поэтому не стоит делать его более безопасным?

kirk_johnson ★☆
()
Ответ на: комментарий от hobbit

нет. но существенно их отпугивает. они говорят ко-ко-ко, тут нет классов, компилятор не тычет меня носом в собственное гомнецо, ко-ко-ко, это плохой компилятор, это небезопасный язык, ко-ко-ко! и благополучно сваливают в жабу, на питоны или ещё куда. скатертью дорога.
те, кто умеет писать на С, неудобств не испытывают. кто хочет С с классами - есть и такие варианты. есть С++, в конце концов. в общем, вариантов масса. но не нужно это тащить в системное программирование. потому что системы пишутся не только под мэйнстримовые сервера, но и под мелкоконтроллеры. а там никто не будет писать компиляторы с блэкджеком, шлюхами и ООП.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

проще и дешевле не набирать говнокодеров.

Откуда такой максимализм?

но и под мелкоконтроллеры. а там никто не будет писать компиляторы с блэкджеком, шлюхами и ООП.

С ООП, наверное, действительно не будет, но вот блэкджек [1] и шлюхи [2] вполне присутствуют.

[1] http://hackage.haskell.org/package/copilot

[2] http://hackage.haskell.org/package/atom

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()

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

Например, в Java и C# я могу декомпилировать любую сборку вплоть до имен переменных и метаданных. Я даже могу пойти ещё дальше и посмотреть IL/JVM код, чтобы решить какие-то низкоуровневые вопросы. Отменяет ли это документацию? Очевидно, не отменяет.

Поскольку мейнстрим пошел не по пути Io

Путь Io - путь забвения и кучки фанатиков. Его путь и путь мейнстрима не пересекаются, смирись и хватит плакать об этом.

мы живем в эпоху развитого литературного программирования

Мы живем в эпоху, когда часто важнее знать, как использовать уже существующий код, чем уметь в реализацию. Интроспекция твоя на вопрос «как использовать этот код» не отвечает. Особенно с учетом отсутствия типизации в этом твоём IO.

nguseff
()
Ответ на: комментарий от Iron_Bug

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

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

kirk_johnson ★☆
()
Ответ на: комментарий от hobbit

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от kirk_johnson

я постоянно работаю с указателями. а ещё с указателями на указатели на указатели, с указателями на функции, которые возвращают массивы указателей и т.д. и не ощущаю проблем, один раз прочитав K&R году так в 1988-м, ещё учась в лицее. с тех пор указатели не стали сложнее ни на йоту. и всё то же, всё так же. про указатели нужно только знать, что это такое. и это элементарно. дальше - только понимание того, что ты хочешь написать и самоконтроль, чтобы не сделать очепяток.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

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

kirk_johnson ★☆
()
Ответ на: комментарий от hobbit

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

я постоянно работаю с указателями. а ещё с указателями на указатели на указатели, с указателями на функции, которые возвращают массивы указателей и т.д. и не ощущаю проблем, один раз прочитав K&R году так в 1988-м, ещё учась в лицее. с тех пор указатели не стали сложнее ни на йоту. и всё то же, всё так же. про указатели нужно только знать, что это такое. и это элементарно. дальше - только понимание того, что ты хочешь написать и самоконтроль, чтобы не сделать очепяток.

Всё ядро забито BUG_ON(ptr == NULL), введены механизмы slab и list poisoning'а, код регулярно прогоняется через coverity и прочие анализаторы но всё равно регулярно где-то кто-то умудряется облажаться.

kirk_johnson ★☆
()
Ответ на: комментарий от tailgunner

Писал:

Надо было поправить цитату, прошу прощения.

Насчет Lisp реальность с тобой не согласна

Почему? ОС на лиспе существовали и использовались когда-то давным давно. Тот факт, что они загнулись, как и лисп, ничего особо не меняет.

Мне кажется, у нас с тобой разные понятия об ОС в данном случае. Я имею ввиду как код в ring0, так и часть юзерспейса. Последнее особенно относится к микроядрам, где не нужно портировать рантайм языка в ring0.

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

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

Не, это называется бессмысленная мастурбация. Уж извини.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Эээ. Ядро - не только железо.

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

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

А что плохого в том, что компилятор проверяет, что я не наложал спьяну?

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

с помощью мозгов, как ни странно. мне даже статических гарантий не нужно.

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

А что плохого в том, что компилятор проверяет, что я не наложал спьяну?

Меньше элитизма.

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()

Потому что literate programming - костыль, компенсирующий недостаточную выразительность языка. Чем лучше язык, тем более оно ненужно.

HeipaVai1o
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

вообще, основная головная боль в системном программировании - это взаимодействие с железом

Разве что при написании драйверов, и даже в этом случае не всегда.

tailgunner ★★★★★
()
Ответ на: комментарий от hateyoufeel

Насчет Lisp реальность с тобой не согласна

Почему? ОС на лиспе существовали и использовались когда-то давным давно.

Да. Но они были сделаны для Lisp-машин. «Because we can» (ц). ЕМНИП, были ОС и на Фортране.

tailgunner ★★★★★
()
Ответ на: комментарий от hateyoufeel

А тот же Interlisp работал на PDP-10.

Специально посмотрел в Wiki - Interlisp работал поверх TENEX, Тейтелман говорит о TENEX и TOPS. Если ты о микрокодной реализации байткод-интерпретатора, то это опять же Lisp-машина.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.