философия unix way
Да, я тоже хотел бы услышать, причем от .
Глеб, пожалуйста, не разводи демагогию. Давай узнаем что такое Unix way по общему определению. Без интерпретации через чье-либо частное субъективное мнение.
"And is Tao in low-latency patch?"
Я в другом треде приводил ссылки на "The Art or Unix Programming". Там есть несколько вариантов.
выделю понятие "классический unix-way", т.к. именно против этого я враждебно настроен
классический unix-way выделяют следующие черты:
1. Работа только с неструктурированным текстом (т.е. есть только текст, больше ничего нет
a) нет в явном виде, ни чисел, ни структур, ни коллекций, ни графов данных, ничего нет - а есть только текстовый поток
b)полностью отсутствуют такие активные сущности, как функция с состоянием (объект, монада и т.д. исключение, callback, делегат/функтор (кусок выполняемого кода, который можно передать другой функции)
2. текстовый UI
3. вся автоматизация приложений идет через командную строку ОС
4. командная строка по сути неструктурированная
классический unix-way выделяют следующие черты:
1. Работа только с неструктурированным текстом (т.е. есть только текст, больше ничего нет
a) нет в явном виде, ни чисел, ни структур, ни коллекций, ни графов данных, ничего нет - а есть только текстовый поток
b)полностью отсутствуют такие активные сущности, как функция с состоянием (объект, монада и т.д. исключение, callback, делегат/функтор (кусок выполняемого кода, который можно передать другой функции)
2. текстовый UI
3. вся автоматизация приложений идет через командную строку ОС
4. командная строка по сути неструктурированная
Пожалуйста, приведи их еще раз. Можно на английском. Я просто для себя разобраться хочу, заодно может быть и другим будет интересно, по крайней мере я постараюсь сделать, чтобы было интересно 
Лучше бы на вопрос ответил 
Хочу разобраться и понять.
I want to believe.
Хочу разобраться и понять.
I want to believe.
Спасибо большое.
Я выложу то, что там написано сюда.
Я выложу то, что там написано сюда.
Doug McIlroy, the inventor of Unix pipes:
(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
Rob Pike, who became one of the great masters of C:
Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.[9]
Rule 6. There is no Rule 6.
Looking at the whole, we can abstract the following ideas:
1. Rule of Modularity: Write simple parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Composition: Design programs to be connected to other programs.
4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
8. Rule of Robustness: Robustness is the child of transparency and simplicity.
9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
10. Rule of Least Surprise: In interface design, always do the least surprising thing.
11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16. Rule of Diversity: Distrust all claims for “one true way”.
17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.
Ты правда никогда раньше это не видел?
К чему я это все написал? А вот к чему.
Сначала пара замечаний.
Во-первых, привязка к текстовой информации, о которой так часто вспоминают, когда говорят о unix way встречается только тут: McIlroy, (ii требование "Avoid stringently columnar or binary input formats." Это требование вызвано отсутствием единых стандартов на описание данных во время написания этих принципов.
Вообще же говоря, в общем summary по Unix way philosophy такой привязки нет.
Во-вторых, слово "программа" не стоит понимать буквально. Программа не обязательно должна быть одним-выполняемым-файлом. Программой может являться компонент, или функция.
И все же к чему это я все? А к тому, что COM и DCOM - это пример технологий, великолепно укладывающихся в концепции Unix way, и замечательно с ними гармонирующие. Не верите? Прочитайте еще раз все пункты о которых идет речь, которые говорят о unix way идеологи движения.
Но и это еще не все. Как ни странно, самая unix-way система - это совсем не unix'ы, как многие привыкли считать. На самом деле, это Forth. Сама философия построения этого языка полностью следует всем идеям unix way. О Форте можно написать очень много, да и сам язык (система? операционная система?) весьма спорный и всегда вызывал много дискуссий. Но факт остается фактом. Форт безукоризненно следует ВСЕМ концепциям unix way. Чего не скажешь о многих современных unix-клонах.
Странные немного выводы, они мне сегодня ночью приснились. Кто что скажет?
Сначала пара замечаний.
Во-первых, привязка к текстовой информации, о которой так часто вспоминают, когда говорят о unix way встречается только тут: McIlroy, (ii требование "Avoid stringently columnar or binary input formats." Это требование вызвано отсутствием единых стандартов на описание данных во время написания этих принципов.
Вообще же говоря, в общем summary по Unix way philosophy такой привязки нет.
Во-вторых, слово "программа" не стоит понимать буквально. Программа не обязательно должна быть одним-выполняемым-файлом. Программой может являться компонент, или функция.
И все же к чему это я все? А к тому, что COM и DCOM - это пример технологий, великолепно укладывающихся в концепции Unix way, и замечательно с ними гармонирующие. Не верите? Прочитайте еще раз все пункты о которых идет речь, которые говорят о unix way идеологи движения.
Но и это еще не все. Как ни странно, самая unix-way система - это совсем не unix'ы, как многие привыкли считать. На самом деле, это Forth. Сама философия построения этого языка полностью следует всем идеям unix way. О Форте можно написать очень много, да и сам язык (система? операционная система?) весьма спорный и всегда вызывал много дискуссий. Но факт остается фактом. Форт безукоризненно следует ВСЕМ концепциям unix way. Чего не скажешь о многих современных unix-клонах.
Странные немного выводы, они мне сегодня ночью приснились. Кто что скажет?
видел. хотел еще раз увидеть, прежде чем делать спорные воводы.
Как ни странно, самая unix-way система - это совсем не unix'ы, как многие привыкли считать.Да, я тоже так думаю. Вот ещё.
Unix is absolutely the worst OS we have, except for all the others.
Про форт не надо.
Там требования заметно жёстче.
Особенно, если брать новую волну.
Кроме того, там отвергаются некоторые положения из списка.
---
VARIABLE 1
Там требования заметно жёстче.
Особенно, если брать новую волну.
Кроме того, там отвергаются некоторые положения из списка.
---
VARIABLE 1
Да, я тоже так думаю.Так не думать - мало. Лучше думать о том, что лучше подходит под эту концепцию. И вот тут-то и открывается самое интересное. COM это Unix way. Forth это unix way.
> Прочитайте еще раз все пункты о которых идет речь
Там нет ничего про UI.
А споры преимущественно вокруг этого.
Там нет ничего про UI.
А споры преимущественно вокруг этого.
Кроме того, там отвергаются некоторые положения из списка.Подробнее, пожалуйста.
Я скорее соглашусь с тем, что некоторые положения из списка там принимаются, но с определенными оговорками, вызваными конструкцией языка.
Положение 3 ("Rule of Composition") отвергается Муром.
Программа --- это законченное произведение, готовое к употреблению.
Если нужно делать что-то дополнительно, программа изменяется.
Положение 4 ("Rule of Separation") Муром не используется,
Фоксом подвергается сомнению, и если вдруг окажется признано,
то только как вспомогательное, само собой вытекающее из других.
Хотя по произведениям Фокса не скажешь, чтобы он его принял.
Положение 14 ("Rule of Generation") тоже вряд ли является независимым.
По крайней мере, оно не используется.
Хотя, надо сказать, положение 16 ("Rule of Diversity") новой
волной превозносится чуть ли не до основополагающего.
Положение 17 ("Rule of Extensibility" в лучшем случае,
не используется, а некоторыми отвергается.
См. положение 3.
Хотя в идеологической борьбе оно тоже пускается в ход,
но как свойство языка, а не способа разработки.
---
VARIABLE 1
Программа --- это законченное произведение, готовое к употреблению.
Если нужно делать что-то дополнительно, программа изменяется.
Положение 4 ("Rule of Separation") Муром не используется,
Фоксом подвергается сомнению, и если вдруг окажется признано,
то только как вспомогательное, само собой вытекающее из других.
Хотя по произведениям Фокса не скажешь, чтобы он его принял.
Положение 14 ("Rule of Generation") тоже вряд ли является независимым.
По крайней мере, оно не используется.
Хотя, надо сказать, положение 16 ("Rule of Diversity") новой
волной превозносится чуть ли не до основополагающего.
Положение 17 ("Rule of Extensibility" в лучшем случае,
не используется, а некоторыми отвергается.
См. положение 3.
Хотя в идеологической борьбе оно тоже пускается в ход,
но как свойство языка, а не способа разработки.
---
VARIABLE 1
Положение 3 ("Rule of Composition") отвергается Муром.Зависит от того, что считать программой.
Программа --- это законченное произведение, готовое к употреблению.
Если нужно делать что-то дополнительно, программа изменяется.
Если договориться, что слово форта может быть программой, то тогда как раз получаем один из основопологающих принципов - писать слова, которые могут быть использованы самостоятельно в других контекстах. Design programs to be connected to other programs.
По поводу положения 4, пожалуй, соглашусь с тобой.
Положение 14 - по-моему дух Форта весьма поощряет это положение. Просто оно реализуется в форте иначе, не буквально.
Положение 17 - опять же, вполне согласуется с тем, что я писал про положение 3.
Очень сложно считать отдельными программами слова наподобие
<# #S #> и прочих, использующих HOLD, или страшного DOES>.
Кроме того, особенно это заметно при построении новых
управляющих конструкций, слова настолько сильно переплетаются
по смыслу, что не могут использоваться раздельно.
Так что в общем случае считать отдельно взятое слово программой --- нельзя
Положение 14 не используется явно.
Несмотря на то, что можно найти замечательные примеры в его
пользу, последние не являются общим правилом.
Кроме того, новая волна отошла (или отходит) от использования DOES>.
По крайней мере, у них заметен отказ от выполнения сложных
действий в ходе компиляции.
Антистандартная волна не сказать, чтобы сильно (не в смысле
"часто," а в смысле "мощно") использовала DOES>.
Хотя за последнее не поручусь, поскольку она, всё-таки,
наименее представлена.
Приверженцы стандарта отказались от state-smart слов, а это
как-никак одна из мощных черт языка.
(Порой мне кажется, они вообще путаются в этих своих DOES> ---
излишне переусложнили.)
В общем, "Rule of Generation" очень спорно.
Против "Rule of Extensibility" играет то, что будущее настигает
фортера обычно раньше, чем он успевает что-либо разработать.
Оно, пожалуй, всё-таки не имеет самостоятельности.
Это свойство языка: на нём невозможно осмысленно писать,
не создавая DSL.
Кстати, недавно нашёл закладку с записью:
---
"Расширь своё сознание!"
<# #S #> и прочих, использующих HOLD, или страшного DOES>.
Кроме того, особенно это заметно при построении новых
управляющих конструкций, слова настолько сильно переплетаются
по смыслу, что не могут использоваться раздельно.
Так что в общем случае считать отдельно взятое слово программой --- нельзя
Положение 14 не используется явно.
Несмотря на то, что можно найти замечательные примеры в его
пользу, последние не являются общим правилом.
Кроме того, новая волна отошла (или отходит) от использования DOES>.
По крайней мере, у них заметен отказ от выполнения сложных
действий в ходе компиляции.
Антистандартная волна не сказать, чтобы сильно (не в смысле
"часто," а в смысле "мощно") использовала DOES>.
Хотя за последнее не поручусь, поскольку она, всё-таки,
наименее представлена.
Приверженцы стандарта отказались от state-smart слов, а это
как-никак одна из мощных черт языка.
(Порой мне кажется, они вообще путаются в этих своих DOES> ---
излишне переусложнили.)
В общем, "Rule of Generation" очень спорно.
Против "Rule of Extensibility" играет то, что будущее настигает
фортера обычно раньше, чем он успевает что-либо разработать.
Оно, пожалуй, всё-таки не имеет самостоятельности.
Это свойство языка: на нём невозможно осмысленно писать,
не создавая DSL.
Кстати, недавно нашёл закладку с записью:
fence off ( remove protection )
---
"Расширь своё сознание!"
Так не думать - мало. Лучше думать о том, что лучше подходит под эту концепцию. И вот тут-то и открывается самое интересное. COM это Unix way. Forth это unix way.Вот я и говорю, что во всех местных спорах под unix way имеют в виду то, что имеет в виду .
Вот я и говорю, что во всех местных спорах под unix way имеют в виду то, что имеет в виду .Тогда предложение: давайте не будем его называть unix way. Давайте его называть "мнение о unix".
Одна из целей заведения этого треда была в том числе вывести рафинированное определение, что есть unix way. Дабы не порождать пустых споров, вызванных чисто семантикой человеческого языка.
Ну давайте про пользовательский интерфейс ещё найдём что-нибудь.
Очень сложно считать отдельными программами слова наподобиеКонечно же нельзя, и я это и не предлагал. Я предлагал согласиться с тем, что некоторые слова (и совокупности зависимых слов) можно считать программами.
<# #S #> и прочих, использующих HOLD, или страшного DOES>.
Кроме того, особенно это заметно при построении новых
управляющих конструкций, слова настолько сильно переплетаются
по смыслу, что не могут использоваться раздельно.
Так что в общем случае считать отдельно взятое слово программой --- нельзя
Тоже сомнительно.
State-smart слова убивают это наповал.
Например, достандартный LITERAL.
Получается, что лишь очень узкое (хотя и рабочее) подмножество
слов ты сможешь назвать образующими в совокупности программу.
Кроме того, есть возможность вычислений такого рода:
тому подобного.
---
...Я работаю антинаучным аферистом...
State-smart слова убивают это наповал.
Например, достандартный LITERAL.
Получается, что лишь очень узкое (хотя и рабочее) подмножество
слов ты сможешь назвать образующими в совокупности программу.
Кроме того, есть возможность вычислений такого рода:
Причём со всеми вытекающими зависимостями от SET-PRECISION и
: C ... ; C forget C constant C
тому подобного.
---
...Я работаю антинаучным аферистом...
все равно незначительное возражение, я считаю.
Forth - это unix way в большей степени, чем любой из существующих unix'ов.
Forth - это unix way в большей степени, чем любой из существующих unix'ов.
Я бы не сказал.
Если рассуждать по-твоему, разницы microkernel---exokernel нет.
А с этим сложно согласиться.
---
...Я работаю антинаучным аферистом...
Если рассуждать по-твоему, разницы microkernel---exokernel нет.
А с этим сложно согласиться.
---
...Я работаю антинаучным аферистом...
Оставить комментарий
shlyumper
Пожалуйста, сформулируйте четкое определение, что такое unix way?