>>Понятно, что вопрос "где платят больше" их интересует.
> Я бы перефразировал бы - "Где меньше делаешь и больше получаешь", так
> вот я и акцентировал, идти нужно в предприниматели.

а чем это принципиально отличается от "выбора инструмента, который гарпнтиркет эффективность?"

>>И просто "программных архитекторов", во-первых, мало
> Их ровно столько сколько появилось фронтендеров)), помните времена когда бекенд и фронтенд
> был на одной шее?

Помню,-конечно, но а делу это не относится. Фронтэндер и проектирует, и код пишет, как и почти любой другой рпзрпботсик. И ссё - привязанное а совершенно конкретным условиям.

>>во-вторых - они тоже имеют свои языки/инструменты - UML и всё вокруг него, а отнюдь не блок-схемы на бумаге рисуют.
> все начинается с чистого листа (ц)

ну давай сначала ещё этот лист делать и алфавит изобретать? Хочешь эффективности - пользуйся инструментами и ограничивай контекст применения.

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

Не знаю, потому что джаваскрипт не знаю толком, тпм более современный. То, что я аидел с питоне, сильно зависит от объёма данных, причём как-то ломано и в доеументации про такое ничего нет. Я о том, что в любой сложной системе таких фокусов хватает, они важны
и совершенно не выводятся из "просто алгоритмики". И чем дальше - тем важнее, так каа сложность софта всё растёт.

> Приведу самый
> тупой пример из мира пхп, что "быстрее" строки обрамленные одинарными или
> двойными кавычками? ))))) Кто-то воскликнет про "спички" и т.д. (забыли про
> эту тему). А вот, что касается про данные (объем), то тут
> нужно обратится к асимптотике, оценке, и соглашусь, будут алгоритмы допустим "быстрые"
> (временная сложность), но "жручие" по памяти (пространственная сложность) и на оборот,
> "золотая середина" тоже есть, и собственно идеальные.

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

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

Ну так шестерёнку можно тоже по-разному реализовать. И с разных проектах размер у них сильно разный. От отдельной фунции через рефакторинг модуля к отдельгой утилите.

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

> Приведу пример, чтобы была ясна мысль, допустим я решил одним прекрасным днем
> написать собственную ОСь, так сел и начал думать, что я должен
> знать и сделать. Допустим надумал, что нужно знать "от и до"
> машинную архитектуру (хотя бы одну), продумать архитектуру ОС, придумать ЯП, и
> т.д. Потом прикинул сколько я затрачу на это сил и меня
> это отпугнуло, почему? Думаю ответ очевиден, - чего ради?
> 1) Бабло заработать? - не эффективно. Бабла ради, буду искать компромиссы, а
> ну нафиг свою ОСь писать, можно и существующую взять и заработать
> на ней. Так я быстрей заработаю. И это все относится только
> ко мне лично, я один обо всем думаю.

Если конечная цель - решение конкретной задачи то тоже лучше существующую взять, как правило. Со всеми компромиссами, так как самому всё сделать - никаких сил не хватит.

> 2) Если по фану, то - правильный ответ, этим должна заниматься группа.
> Разве Торвальдс не это имел ввиду?
> Думаете он начал писать ОСь ради бабла? Почему он не начал с
> создания ЯП, а сразу начал писать ОСь на Си, и то
> не сразу ОСь, а сначала с миниксом поигрался. Похоливарил с Э.
> Т.

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

>>Ну вот серьёзно - это ж всё совершенно очевидные вещи, неужели их надо разжёвывать?
> Человек идущий во всем на компромиссы, по вашему, очевидность? По мне, очевидно
> - человек стремящийся преодолевать трудности.

Мы всё ещё о мейнстримной (читай - коммерческой) разработке? Или о хобби?