Что имел в виду Линус Торвальдс под своей цитатой о переносимости? [закрыто]

В споре с Эндрю Таненбаумом по поводу архитектуры микроядра и монолитной операционной системы Линус Торвальдс сказал:

Портативность для людей, которые не могут писать новые программы.

Что он имел в виду под этим?

Как пишет Линус в дискуссии, это с языком в щеке (то есть не следует воспринимать слишком серьезно).

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

Конечно, это невозможно, если вы не можете писать новые программы и должны придерживаться оригинальной :)

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

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

Когда Linux впервые был написан, он использовал функции, доступные только на процессоре i386, который был довольно новым и дорогим в то время.

Это именно то, что делает Linux: он просто использует большее подмножество функций 386, чем другие ядра. Конечно, это делает ядро ​​непереносимым, но также делает его намного более простым. Приемлемый компромисс, и тот, который сделал Linux возможным в первую очередь.

Когда мы вступили в 21 век, функции, которые сделали i386 уникальным, стали полностью мейнстримом, что позволило Linux стать очень портативным.

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

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

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

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

Хотя некоторые люди считают / рассматривают переносимость, следование стандартам и т. Д. Как морально превосходящие или что-то в этом роде, на самом деле это сводится к экономике.

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

Непереносимый код требует затрат на перенос кода, если / если вы заботитесь о новой архитектуре, и (часто) отказываетесь от некоторых функций, которые недоступны (или не были) в исходной цели.

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

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

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

Таненбаум подчеркивает, что большая часть Linux написана немодульным способом, чтобы использовать процессор 386, современный на тот момент, вместо того, чтобы делать взаимодействие с процессором компонентом и, таким образом, очень легко заменяемым. Таненбаум, по сути, считает, что тот факт, что ядро ​​настолько монолитно и связано с процессором 386, делает его очень трудным,

• Сам порт Linux на другую платформу ЦП (очевидно, некорректно, AMD64, PowerPC и т. Д.)
• Порт Программы, написанные для Linux x86, на другую архитектуру ЦП (также неверно)

Лагерь Linux делает несколько моментов, среди которых:

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

Если вы хотите написать переносимый код, вы должны написать переносимый код.

Что я имею в виду под этим?

Дизайн должен отражать цель. Если язык, например, C, спроектируйте его так, чтобы минимальное количество строк кода нужно было изменить, чтобы он работал. Это часто означало бы отделение дисплея от вычислений, что в любом случае является хорошей философией дизайна (MVC). Большая часть кода на C может быть скомпилирована где угодно, если у вас есть доступ к хорошему компилятору. Используйте это и напишите как можно больше, чтобы быть универсальным.

Кстати, этот ответ будет применяться только для приложений. ОС и встраиваемые это совсем другое животное.

Толковать это утверждение «буквально» так, как оно есть.

В другой цитате Линуса он сказал: «C ++ пытается решить все неправильные проблемы. То, что C ++ решает, - это тривиальные вещи, почти чисто синтаксические расширения C, а не решение какой-то серьезной проблемы».

Также в своей биографии Линус «Просто для удовольствия», цитируя микроядра, сказал, что для задачи со сложностью «n», если вы разделите проблему на «1 / n» уникальные части ... тогда общая сложность разработки такой системы будет быть 'n!' это само по себе является достаточным фактором, чтобы не пытаться делать подобные вещи, и извлечение эффективности из такой сложной системы было бы очень затруднительным.

Вы должны принять во внимание тот факт, что во время этих дебатов Linux был очень новым и в основном был 386-й ОС. Я думаю, что если бы вы спросили Линуса сегодня, у него было бы другое мнение. Возможно, не такой экстремальный, как Танненбаумс, но он, вероятно, кивнет и скажет, что был прав в некоторых вещах.

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

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

Это менее одаренные программисты, которые хотят «импортировать» другие программы (переносимость) в текущую.