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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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