С принятием закона Мура, вы думаете, что может быть сдвиг в сторону от Frameworks?

Question

Фреймворки упрощают кодирование за счет скорости и запутанности ОС. С принятием закона Мура, вы думаете, что может произойти отход от Фреймворка?

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

В течение многих лет скорость процессора превосходила скорость программного обеспечения, поэтому новые платформы, которые добавляли слои обфускации и раздувания ОС, приносили мало вреда. Представьте себе, как быстро Windows 95 будет работать на современном оборудовании (учитывая несколько настроек памяти). Win2K и WinXP были отличными улучшениями, и мы могли бы жить с ними медленнее из-за более быстрых компьютеров.

Однако даже несколько лет назад я заметил, что программы, написанные на базовых классах MS, выглядели не такими четкими, как код, выполняющий то же самое, что написано непосредственно в API. Поскольку распространение таких сред, таких как .Net и другие, могло только усугубить эту ситуацию, возможно, мы обнаружим, что возможность писать код в «C» непосредственно в Win32 API (или аналог в других ОС) будет стать сильным конкурентным преимуществом, даже если это займет больше времени, чтобы написать? Или компромисс в более длительном времени разработки просто не будет того стоить?

Answer 1

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

Платформа Boost :: Gil, которая обрабатывает пиксели, представляет собой хорошую систему на основе шаблонов, которая сводится ко многим встроенным функциям - компилятор создает тот же вывод, что и при отсутствии оболочки для пикселей и непосредственного доступа к значениям.

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

Answer 2

Для многих программных продуктов производительность не проблема, пришло время выходить на рынок. Зачастую это «внутренний» случай, когда команда может гораздо больше заботиться о том, чтобы быстро получить начальную версию приложения перед пользователями, чем о том, насколько быстро (или даже насколько стабильно) оно работает. Добавьте к этому тот факт, что хорошо написанный фреймворк упростит разработку приложений, являющихся целью разработки фреймворка, и вы часто будете злиться, если НЕ будете использовать фреймворк, если таковой имеется. Конечно, вы берете на себя риск того, что структура позволит вам пройти 80% пути к вашей цели, а затем оставит вас в напряжении, но, как правило, вы можете смягчить это, работая вне структуры для этой последней 20%. Как и все хорошее в программном обеспечении, оно часто связано со слоями; сначала вы можете выбрать .Net в качестве «фреймворка», а затем принять решение об использовании определенной «.Net GUI» .Net для частей вашего приложения, а затем, возможно, «фреймворка» отдельного сокета для других частей. Или вы можете решить работать в C ++ и использовать boost в качестве фреймворка, или, возможно, выбрать более сфокусированный фреймворк, который предлагает вам больше абстракций и (надеюсь) большую скорость кодирования.

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

Answer 3

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

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

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

Answer 4

платформы существуют для инкапсуляции общей функциональности; это никогда не изменится

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

Answer 5

Разве WinRT не занимается именно этим, то есть попыткой съесть наш пирог и съесть его? Насколько я понимаю, WinRT должен дать нам взаимодействие на более высоком уровне, сохраняя при этом скорость, потому что это не дополнительный уровень, а замена C / C ++ OSI базового уровня для использования непосредственно .NET?

Answer 6

"Это слово слишком перегружено в нашей отрасли. Если вы имеете в виду что-то вроде MFC или .Net, то я думаю, что они здесь, чтобы остаться. Они не имеют никакого отношения к производительности во время выполнения. Они имеют все, что связано с повторным использованием кода , ремонтопригодность и разделение проблем. "

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

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

Answer 7

Что именно вы подразумеваете под "каркасами" . Это слово слишком перегружено в нашей отрасли. Если вы имеете в виду что-то вроде MFC или .Net, то я думаю, что они здесь, чтобы остаться. Они не имеют ничего общего с производительностью во время выполнения. Они имеют полное отношение к повторному использованию кода, удобству сопровождения и разделению задач.

Кстати, Vista не медленная, потому что она использует фреймворки; это медленно, потому что он использует много бесполезных фреймворков, таких как DRM . Он также может страдать от низкого качества, поскольку MS постепенно становится более бюрократической корпорацией - мое восприятие . Vista также страдает от недостатка цели. Это не приносит ничего, что стоит обновить. Попытка компенсировать замерзанием графического интерфейса.

Answer 8

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