Комментарии 96
/Фреймворк же сковывает вас, привязывая к себе. Каждый из них имеет собственную выстроенную логику работы, которую не всегда можно запросто уловить. И при переходе с одного языка на другой/из одной, команды в другую вам приходится зачастую тратить несколько дней, чтобы понять, как использовать новый фреймворк. И при переносе проекта, вам, по сути, приходится заново создавать весь свой продукт. Если бы вы использовали голый язык, то с такой проблемой столкнуться не пришлось бы. Язык он и есть язык и новому разработчику в команде не пришлось бы тратить столько времени на понимание фреймворка, он бы сразу смог работать./
Если не использовать фреймворк, то первое, чем вы будете заниматься в новом проекте — писать свой фреймворк (роутинг, контроллеры, шаблоны...).
Чтобы не усложнять разработку изучением все новых и новых фреймворков, на сегодняшний день доступны микрофреймворки, которые фактически содержат в себе все необходимое. Да и сами они настолько похожи (к примеру Slim, Silex, Flight, Lumen), что изучать придется только один, скорее даже не фреймворк, а подход идеалогии микрофреймворков.
Если не использовать фреймворк, то первое, чем вы будете заниматься в новом проекте — писать свой фреймворк (роутинг, контроллеры, шаблоны...).
Чтобы не усложнять разработку изучением все новых и новых фреймворков, на сегодняшний день доступны микрофреймворки, которые фактически содержат в себе все необходимое. Да и сами они настолько похожи (к примеру Slim, Silex, Flight, Lumen), что изучать придется только один, скорее даже не фреймворк, а подход идеалогии микрофреймворков.
Если не использовать фреймворк, то первое, чем вы будете заниматься в новом проекте — писать свой фреймворк (роутинг, контроллеры, шаблоны...).
В лучшем случае это будет именно так и из-за нехватки времени выйдет плохо и будут проблемы с производительностью В худжем по итогу мы будем иметь лапшу которую невозможно поддерживать.
Фреймворки — всего лишь новый слой абстракции, считайте их новыми языками программирования, вот и все. И да, у вас всегда остается возможность находиться на любом уровне абстракции. А каждый новый слой родит нам еще кучу новых веток.
Суть описываемой вами проблемы в другом — количество инструментов разработки в IT просто зашкаливает. Это и языки программирования, и утилиты, и фреймворки, и языки разметки, и шаблоны проектирования и т.д. и т.п. Да и собственно задачи все усложняются.
Так что, не воюйте с мельницами, энтропию можно остановить только в своем собственном мире/окружении.
Суть описываемой вами проблемы в другом — количество инструментов разработки в IT просто зашкаливает. Это и языки программирования, и утилиты, и фреймворки, и языки разметки, и шаблоны проектирования и т.д. и т.п. Да и собственно задачи все усложняются.
Так что, не воюйте с мельницами, энтропию можно остановить только в своем собственном мире/окружении.
И как, простите, доедать этот слоеный пирог тому, кому вы его оставите?
Как мы уже его едим? Я вот звездочки на гитхабе считаю… А в будущем надеюсь на ИИ.
Я не знаю, поэтому и вас спрашиваю. Если у вас есть слой для… кхм, в виде
Звездочки считать — это элементарная математика. Куда интереснее и сложнее — посмотреть кто их ставит.
magic("Hello world"), то человеку не испорченному этой ерундой придется открывать документацию к фреймворку и смотреть что там за magic, что там за appepie, что такое easyRequestBlabla и далее по аналогии.Звездочки считать — это элементарная математика. Куда интереснее и сложнее — посмотреть кто их ставит.
Слоеные торты доедать удобно, по слоям. Один ест один слой, другой второй, третий — тот что между ними и связывает их вместе. Это не графские развалины где все в кучу.
Уже была статья про фреймворки.
Собственно выскажу свое мнение и здесь: в плане JS я не вижу ничего плохого в том, чтобы использовать фреймворки, ибо это JS.
А вот в плане других языков программирования — категорически против.
Собственно выскажу свое мнение и здесь: в плане JS я не вижу ничего плохого в том, чтобы использовать фреймворки, ибо это JS.
А вот в плане других языков программирования — категорически против.
Ну то есть вы против использования ASP.net MVC при разработке веб-приложений на C#?
Это мода такая?) Задавать вопросы оппоненту по темам, с которыми он не работает (в профиле отсуствует информация о C#)?
Сейчас я попробую вспомнить… лет 13 назад был (и есть) C и C++. Был борландовый AWL (awl?), и была косметика VCL.
Еще был microsoft… я помню громадный MFC и книжку, которой можно было убить.
Ответил ли я на ваш вопрос? Что вы хотелиуслышать увидеть?
Сейчас я попробую вспомнить… лет 13 назад был (и есть) C и C++. Был борландовый AWL (awl?), и была косметика VCL.
Еще был microsoft… я помню громадный MFC и книжку, которой можно было убить.
Ответил ли я на ваш вопрос? Что вы хотели
Вы же зачем-то говорите про другие языки программирования? Вот есть C# — язык программирования. Вот есть .net framework, в котором он работает. Вот есть asp.net mvc, который тоже фреймворк, только уровнем выше и с конкретной специализацией.
Вы категорически против использовать этот фреймворк при разработке? Или C# — не язык программирования? Или asp.net mvc — не фреймворк? Или что-то еще?
Вы категорически против использовать этот фреймворк при разработке? Или C# — не язык программирования? Или asp.net mvc — не фреймворк? Или что-то еще?
Вот:
Сейчас что имеем? Имеет огромную «ВО!» которая работает с «ВОО!». За 13 лет обсосана и обросла гуще чем борода.
Мое категоричное мнение заключается в том, что громадных динозавров времен 2000х одели в модные костюмы, все это съели и на волне начала XXI века съели. А текущие фреймворки как приблуда к костюмам, мол напиши костюм-синий и все. Про подкладку и строчку — не парься. И ладно бы — они поражали деталями. Лет через 5 при должном развитии уже «ныть про это» будет не модно и неверно. Сейчас еще можно.
- Вышли они почти одновременно (C#'2000ые & .NET 2002 по вики)
- 2015 год — конечно стоит!
- 2005 год — чуть-чуть и 3 года!!! Зачем???
Сейчас что имеем? Имеет огромную «ВО!» которая работает с «ВОО!». За 13 лет обсосана и обросла гуще чем борода.
Мое категоричное мнение заключается в том, что громадных динозавров времен 2000х одели в модные костюмы, все это съели и на волне начала XXI века съели. А текущие фреймворки как приблуда к костюмам, мол напиши костюм-синий и все. Про подкладку и строчку — не парься. И ладно бы — они поражали деталями. Лет через 5 при должном развитии уже «ныть про это» будет не модно и неверно. Сейчас еще можно.
Я, вроде бы, задал конкретные вопросы. Использовать, или нет? К любому ответу сразу прилагается вопрос «почему».
Даже целых два. Но ответы так и не прочитали, внимательно.
Вы, к сожалению, не ответили на мои вопросы.
Что же вы так невнимательно:
2015 год — конечно стоит!
А по теме Java работаете? Вот тогда вопрос про Java-фреймворки: отбросим всякие спринги, и чисто веб-фреймворки (play, spark и т.д.). Уберём JSF и другие фронтенд-фреймворки. Оставим только JavaEE API. Реализации некоторых его частей сами по-себе являются фреймворками: Jersey/Resteasy реализуют JAX-RS, Hibernate/EclipseLink/etc реализуют JPA и т.д.
Останутся по-сути, голые сервлеты. На них писать все веб-приложения?
Останутся по-сути, голые сервлеты. На них писать все веб-приложения?
веб-фреймворки (play, spark и т.д.)WUT?! Он чуток побигдатее… Видимо, вы имели ввиду spring mvc.
Останутся по-сути, голые сервлеты.Которые тоже, по сути, фреймворк, т. к. навязывает структуру программы и семантику обработки запросов. Без фреймворков — java.net.Socket.
Я про этот spark. А что с ним не так?
Да, точно. В принципе, на любом языке это сведётся к либо к работе с http протоколом напрямую, либо вообще к сокетам.
Которые тоже, по сути, фреймворк,
Да, точно. В принципе, на любом языке это сведётся к либо к работе с http протоколом напрямую, либо вообще к сокетам.
Понятно, совпадение имени)) Я подумал про Apache Spark (ну и trademark Spark принадлежит ASF). Сказывается предметная область.
Если проект маленький, то фреймворк тащить нет никакого смысла, да.
Но стоит ему перевалить за пару тысяч строк кода, как начинает появляться фреймворк, самописный и часто кривой, зачастую похожий на существующие. Смысл терять время, нервы и деньги, если можно просто взять готовое.
Что касается подходов — большинство специализированных фреймворков в основе имеют принятые для решаемых задач подходы, большинство, но не все, а значит любители извращений так же не останутся в обиде.
Так что фреймворки это хорошо, а если вы упоротый и считаете необходимым вручную реализовывать простейшие вещи, то не надо тереть тут о программировании, ок?
Но стоит ему перевалить за пару тысяч строк кода, как начинает появляться фреймворк, самописный и часто кривой, зачастую похожий на существующие. Смысл терять время, нервы и деньги, если можно просто взять готовое.
Что касается подходов — большинство специализированных фреймворков в основе имеют принятые для решаемых задач подходы, большинство, но не все, а значит любители извращений так же не останутся в обиде.
Так что фреймворки это хорошо, а если вы упоротый и считаете необходимым вручную реализовывать простейшие вещи, то не надо тереть тут о программировании, ок?
По-моему в 95 процентах случаев хороший фрейворк закрывает все необходимые задачи.
Для остальных 5% имеет смысл описанное в статье. Большинство разработчиков с этими 5% никогда не столкнутся, так что фреймворки имеют право на жизнь.
Для остальных 5% имеет смысл описанное в статье. Большинство разработчиков с этими 5% никогда не столкнутся, так что фреймворки имеют право на жизнь.
Фреймворк, помимо всего вышеперечисленного, обязан решать еще одну задачу, о которой часто забывают.
Не допускать написания говнокода. Просто сделать это невозможным физически.
Почему Yii — плохой фреймворк, например? Потому что в шаблонах, написанных на нативном PHP ничто не мешает сделать 100500 запросов к БД в цикле.
Многие так и делают, к сожалению.
Или взять и результат работы контроллера Abc отрендерить в шаблоне Xyz. Счастливой отладки! (с)
Сумбурно, но основная мысль, надеюсь понятна. Фреймворк должен служить мощным ограничителем неразумных «хотелок» разработчика.
Не допускать написания говнокода. Просто сделать это невозможным физически.
Почему Yii — плохой фреймворк, например? Потому что в шаблонах, написанных на нативном PHP ничто не мешает сделать 100500 запросов к БД в цикле.
Многие так и делают, к сожалению.
Или взять и результат работы контроллера Abc отрендерить в шаблоне Xyz. Счастливой отладки! (с)
Сумбурно, но основная мысль, надеюсь понятна. Фреймворк должен служить мощным ограничителем неразумных «хотелок» разработчика.
Сумбурно, но основная мысль, надеюсь понятна. Фреймворк должен служить мощным ограничителем неразумных «хотелок» разработчика.
Что бы отказываться от фреймворка нужно четко понимать зачем это делается и в чем менно вас ограничивают и почему. То есть начинающие разработчики обязательно должны быть в ежевых рукавицах фреймворка. А далее можно уже ограничения постепенно упразднять. Тут можно еще вставить про сюхари.
Не допускать написания говнокода. Просто сделать это невозможным физически.
Тогда как это делает фреймворк, написанный физически людьми?)
- Что мешает открыть и посмотреть как устроено, перенять себе?
- Что мешает использовать поиск в случае проблем с реализацией?
нативном PHP ничто не мешает сделать 100500 запросов к БД в цикле
А что мешает немного подумать самостоятельно и написать не 100500 запросов в цикле, а сколько конкретная функция требует?
Я очень надеюсь, что сайты вида «вопрос-ответ» и персональные блоги придушат таки интерес к фреймворкам в сторону чистого кода.
На самом деле можно писать на ассемблере, нафиг нам эти высокоуровневые языки, согласитесь, столько теряем используя их. А ведь можно подумать головой и написать чистый код на ассемблере.
Почва спора про JS фреймворки жиденькая, так как компилятором выступают движки в браузере и в ней вязнет мой аргумент про то, что фреймворки всего лишь фреймворки, без полноценного компилятора.
Зато ваше сравнение фреймворка и языка высокого уровня, как неба и земля. Фреймворк тут, внизу, как дрель замотанная скотчем, а ЯВУ они там, парят в небе. Вашей картинке не хватает пикселей.
Зато ваше сравнение фреймворка и языка высокого уровня, как неба и земля. Фреймворк тут, внизу, как дрель замотанная скотчем, а ЯВУ они там, парят в небе. Вашей картинке не хватает пикселей.
… я ни слова не понял… как-то все смешано в кучу… браузеры… java… при том что и js и java выполняются в виртуальной машине, и там и там идет трансляция… хз…
Тогда как это делает фреймворк, написанный физически людьми?)
Что мешает открыть и посмотреть как устроено, перенять себе?
Что мешает использовать поиск в случае проблем с реализацией?
Собственно то что вы написали это вполне себе нормально. Перенимать практики и т.д. Именно по этому начинающие разработчики должны использовать подобные вещи что бы не писать ужасные вещи самостоятельно и учиться на чем-то. А когда они уже начнут осозновать почему так а не иначе — тогда уже можно думать, оптимизировать инструменты под себя или использовать как учат старшие.
А что мешает немного подумать самостоятельно и написать не 100500 запросов в цикле, а сколько конкретная функция требует?
Клиенту глубоко плевать, что вы используете и какого качества у вас код, пока это не влияет на его прибыль или сроки деливери фич. Если качество кода начинает влиять на этот параметр то беда. А фреймворки нужны что бы разработчики не писали велосипедов для вещей, которые определенно понадобятся (логирование, управление зависимостями в коде и тд., базовый каркас) и вообще не занимать себя лишней работой а сосредоточиться на бизнес логике.
В технике уже давно существует тенденция перехода на все более сложные «стройматериалы».
Если раньше электронщики проектировали свои схемы с использованием дискретных элементов (резисторов, конденсаторов, транзисторов) — то уже в 60-70гг прошлого века основным «строительным кубиком» стала микросхема. Она тоже несколько сужает свободу разработчика, так как содержит фиксированный набор функций, который не всегда идеально приспособлен для конкретных задач. Но зато ее использование значительно проще, а еще она занимает меньше места и потребляет меньше электричества.
В дальнейшем микросхемы усложнялись, и сейчас мало того, что без микросхем вообще почти ничего интересного сделать нельзя, так еще и количество функций, которые они вбирают в себя, возрасло многократно. Скажем, если вам требуется АЦП — то правильный на сегодняшний день способ его реализовать — это поставить микросхему-АЦП или даже микроконтроллер со встроенным АЦП. При этом вам не нужно вникать в детали того, как этот АЦП реализован, а просто подключить его так, как указано в инструкции. Раньше же микросхемы АЦП были малочисленны и дороги, поэтому во многих проектах имелись «самодельные» АЦП. Но сама функция-то остается той же самой. Какая разница, сделаете вы АЦП сами или поставите готовый — АЦП как правило не является самоцелью, а служит реализации другой цели, ради которой проектируется прибор. И время, сэкономленное на разработке АЦП, можно направить на разработку других, уникальных функций всего прибора.
То же и в программировании. До сих пор сохраняется возможность работать на «голом железе» без ОС. Но этим сегодня занимаются разве только разработчики ОС или других узкоспециализированных программ. Большинство же программ работают на готовой ОС и пользуются ее ресурсами как «кирпичами». Фреймворк — это просто еще одно усложнение «деталей», с которыми работает программист. Если ему не нравятся готовые детали — он может разработать свои. Но с готовыми деталями, как правило, можно быстрее собрать продукт с нужными функциями.
Негативный побочный эффект усложнения «деталей» — это необходимость изучать их, что при большом разнообразии таких деталей является трудной задачей. Если раньше достаточно было понять, как работает резистор, конденсатор и транзистор, то сегодня электронщик должен знать, какие бывают микросхемы, что они делают и как ими пользоваться — и это сотни и тысячи наименований. Но что делать, прогресс идет вперед.
Если раньше электронщики проектировали свои схемы с использованием дискретных элементов (резисторов, конденсаторов, транзисторов) — то уже в 60-70гг прошлого века основным «строительным кубиком» стала микросхема. Она тоже несколько сужает свободу разработчика, так как содержит фиксированный набор функций, который не всегда идеально приспособлен для конкретных задач. Но зато ее использование значительно проще, а еще она занимает меньше места и потребляет меньше электричества.
В дальнейшем микросхемы усложнялись, и сейчас мало того, что без микросхем вообще почти ничего интересного сделать нельзя, так еще и количество функций, которые они вбирают в себя, возрасло многократно. Скажем, если вам требуется АЦП — то правильный на сегодняшний день способ его реализовать — это поставить микросхему-АЦП или даже микроконтроллер со встроенным АЦП. При этом вам не нужно вникать в детали того, как этот АЦП реализован, а просто подключить его так, как указано в инструкции. Раньше же микросхемы АЦП были малочисленны и дороги, поэтому во многих проектах имелись «самодельные» АЦП. Но сама функция-то остается той же самой. Какая разница, сделаете вы АЦП сами или поставите готовый — АЦП как правило не является самоцелью, а служит реализации другой цели, ради которой проектируется прибор. И время, сэкономленное на разработке АЦП, можно направить на разработку других, уникальных функций всего прибора.
То же и в программировании. До сих пор сохраняется возможность работать на «голом железе» без ОС. Но этим сегодня занимаются разве только разработчики ОС или других узкоспециализированных программ. Большинство же программ работают на готовой ОС и пользуются ее ресурсами как «кирпичами». Фреймворк — это просто еще одно усложнение «деталей», с которыми работает программист. Если ему не нравятся готовые детали — он может разработать свои. Но с готовыми деталями, как правило, можно быстрее собрать продукт с нужными функциями.
Негативный побочный эффект усложнения «деталей» — это необходимость изучать их, что при большом разнообразии таких деталей является трудной задачей. Если раньше достаточно было понять, как работает резистор, конденсатор и транзистор, то сегодня электронщик должен знать, какие бывают микросхемы, что они делают и как ими пользоваться — и это сотни и тысячи наименований. Но что делать, прогресс идет вперед.
Вообще, it depends. Если проект небольшой, то фреймворк может нет смысла тащить. Если уж сабж про JS… То для какой-нибудь landing page может и не стоит тянут громоздские фреймворки. С другой стороны, писать на чистом JS… скажем так, малоприятно.
Если же область пошире взять, то, безусловно, от языка и специфики зависит. Да, поначалу они могут быть непонятны. Да, это дополнительные слои абстракции. Но в целом я за фрейморки, ибо они очень сильно упрощают рутинные вещи, тем самым ускоряя разработку, как минимум. Если же говорить про тот же jQuery, то он довольно прост (конечно, если не заглядывать внутрь).
Если же область пошире взять, то, безусловно, от языка и специфики зависит. Да, поначалу они могут быть непонятны. Да, это дополнительные слои абстракции. Но в целом я за фрейморки, ибо они очень сильно упрощают рутинные вещи, тем самым ускоряя разработку, как минимум. Если же говорить про тот же jQuery, то он довольно прост (конечно, если не заглядывать внутрь).
Фреймворки портят не разработку, а разработчиков, причём далеко не всех.
Думаю, проблема в том что их слишком много:)
В С++ как таковых «фреймворков» сравнительно мало — boost, qt, mfc (ну можно вспомнить еще gtk, wxwidgets и vcl из builder'а). Мне, как программисту С++, хочется иногда изучить javascript — язык весьма красивый и интересный, но если изучать — то делать что-то практическое… Но вот беда, все эти фрейморки которые чуть ли не каждый день появляются… напрочь отбивают желание что-либо изучать:)
В С++ как таковых «фреймворков» сравнительно мало — boost, qt, mfc (ну можно вспомнить еще gtk, wxwidgets и vcl из builder'а). Мне, как программисту С++, хочется иногда изучить javascript — язык весьма красивый и интересный, но если изучать — то делать что-то практическое… Но вот беда, все эти фрейморки которые чуть ли не каждый день появляются… напрочь отбивают желание что-либо изучать:)
Дайте угадаю, автор недавно закончил универ и практически не писал достаточно больших приложений?) Просто у меня пару раз тоже такие мысли возникали. Давно когда-то…
(достаточно больших — это хотя бы несколько разработчиков и несколько десятков тысяч строк кода)
(достаточно больших — это хотя бы несколько разработчиков и несколько десятков тысяч строк кода)
Какой профит мне писать что то самому если уже есть то что написано и работает скорее всего лучше того поделия что я умудрюсь написать?
Если работать над этим каждый день и ставить своей целью написать фреймворк то да там можно поработать, но если цель сделать продукт в установленные сроки то сори, я выберу фреймворк.
Если работать над этим каждый день и ставить своей целью написать фреймворк то да там можно поработать, но если цель сделать продукт в установленные сроки то сори, я выберу фреймворк.
Если бы вы использовали голый язык, то с такой проблемой столкнуться не пришлось бы. Язык он и есть язык и новому разработчику в команде не пришлось бы тратить столько времени на понимание фреймворка, он бы сразу смог работать.
Судя по личному опыту — это утопия которой к сожалению никогда не быть даже при использовании таких догматичных фреймворков как рельсы или эмбер. Погружение в обширные проекты занимает от 2-3 месяцев до года.
А еще меня поражает истерика которая в последнее время возникает около фреймворков. Вот допустим вы с другом решили написать абстрактный код. И договорились что файлы с кодом, название которых начинается на «А» вы сложите в одну папку, а файлы название которых начинается на «Б» вы сложите в другую папку. И сами того не ведая вы только что создали новый фреймворк! Пусть у него нет имени, красивого сайта и документации, но это уже фреймворк. Вы испортили вашу разработку? Думаю что нет.
НЛО прилетело и опубликовало эту надпись здесь
Если бы вы использовали голый язык, то с такой проблемой столкнуться не пришлось бы. Язык он и есть язык и новому разработчику в команде не пришлось бы тратить столько времени на понимание фреймворка, он бы сразу смог работать.
Только вот в любом сколько-нибудь сложном проекте всегда будет какая-то структура, классы, интерфейсы, функции, и пришлось бы тратить время на понимание всего этого, скорее всего без толковой документации. А фреймворки мало того, что имеют документацию, так еще обычно и довольно хорошо спроектированы, имеют большой функционал, и вероятность того, что попадешь в команду, использующую изученный тобой фреймворк, не так уж и мала.
Многие путают фреймворк и библиотеку. Это принципиально разные вещи. Отличие состоит в том, что библиотека расширяет возможности языка, тогда как фреймворк наоборот, ограничивает возможности написания кода установленными парадигмами.
Как правило фреймворк не имеет технической возможности не дать пользователю использовать «некорректные» для этого фреймворка конструкции. Поэтому фреймворк устанавливает ряд соглашений или спецификаций: типа так можно делать, а так нельзя. Спецификации всегда неполны и оставляют за кадром львиную долю неясностей и неопределенностей. Поэтому поведение большинства фреймворков описательно недетерминированно: в отличие от языка программирования, пользуясь только спецификацией, нельзя определить конечное поведение программы. Чтобы что-то написать, приходится изучать все тонкости внутренней имплементации фреймворка.
Каждый фреймворк предлагает набор шаблонов как «правильно» будет сделать ту или иную задачу. Типичные задачи решаются просто при помощи «магии»: декларативных конструкций фреймворка. Если фреймворк где-то не покрывает требуемый функционал, то найти обходное решение будет весьма сложным делом. Я видел проект, где функционал на 50% состоит из всевозможных подпорок и work-around-ов.
Фреймворки очень плохо интегрируются друг с другом, если эта интеграция не предусмотрена функционалом. В отличие от библиотек, каждая из которых ориентирована на конкретную задачу, и которые без проблем могут использоваться вместе в одном проекте, фреймворки вынуждены пухнуть и вмещать в себя сразу весь требуемый функционал.
Как правило фреймворк не имеет технической возможности не дать пользователю использовать «некорректные» для этого фреймворка конструкции. Поэтому фреймворк устанавливает ряд соглашений или спецификаций: типа так можно делать, а так нельзя. Спецификации всегда неполны и оставляют за кадром львиную долю неясностей и неопределенностей. Поэтому поведение большинства фреймворков описательно недетерминированно: в отличие от языка программирования, пользуясь только спецификацией, нельзя определить конечное поведение программы. Чтобы что-то написать, приходится изучать все тонкости внутренней имплементации фреймворка.
Каждый фреймворк предлагает набор шаблонов как «правильно» будет сделать ту или иную задачу. Типичные задачи решаются просто при помощи «магии»: декларативных конструкций фреймворка. Если фреймворк где-то не покрывает требуемый функционал, то найти обходное решение будет весьма сложным делом. Я видел проект, где функционал на 50% состоит из всевозможных подпорок и work-around-ов.
Фреймворки очень плохо интегрируются друг с другом, если эта интеграция не предусмотрена функционалом. В отличие от библиотек, каждая из которых ориентирована на конкретную задачу, и которые без проблем могут использоваться вместе в одном проекте, фреймворки вынуждены пухнуть и вмещать в себя сразу весь требуемый функционал.
>Фреймворки очень плохо интегрируются друг с другом, если эта интеграция не предусмотрена функционалом…
Это и есть главный минус фреймворков.
Это и есть главный минус фреймворков.
Ну на самом деле эта ситуация сейчас потихоньку начинает исправляться. Angular2 вот вроде будет все же пачкой компонентов. Вообще идея фреймворка как набора библлиотек сдобренного бойлерплейтом для связывания всего этого вместе — не такая уж и плохая идея.
Не согласен. Это скорей не цель, а вынужденная необходимость. Из мира Java есть хороший пример — Spring. Тоже начинался как простенький IoC + MVC и очень быстро опух до неудобоваримого состояния. Для интеграции фреймворк определяет рудиментарные прослойки, которые сильно ограничивают и усложняют использование. То есть надо знать и саму низлежашую технологию, и прослойку, и как ее обойти при необходимости. Плюс, следуя сомнительной идее как можно больше бойлерплейта замести «под ковер», фреймворк определяет кучу неявных преобразований, умолчаний и деклараций: у фреймворка появляется магия и заклинания для вызова демонов. Очень быстро начинаешь понимать, что фреймворк концентрирует на себе, а не на решаемой задаче: решение из понятного «просто решить задачу» превращается в сложную и неопределенную «решить задачу с помощью фреймворка». Такое впечатление, что единственный оптимизируемый ресурс — это строки кода, которые сделаны из золота.
P.S. апофеоз «рамочной» инженерной мысли: Spring Batch с документацией в 250 страниц о том как написать скрипт для загрузки файла в базу данных.
P.S. апофеоз «рамочной» инженерной мысли: Spring Batch с документацией в 250 страниц о том как написать скрипт для загрузки файла в базу данных.
«просто решить задачу» превращается в сложную и неопределенную «решить задачу с помощью фреймворка»
Нет никакого «просто решить задачу», в этом вся проблема. Без контекста — задача не существует. Решить задачу:
1. С помощью x86/x64 (а скорее под обе).
2. С помощью языка программирования, вот этого вот компилятора.
3. На этой ОС
4. В этом браузере (или под каждый).
5. Вот с этой по эту версию Android.
Просто языки программирования и нюансы ОС многие уже выучили, теперь пора учить языки фреймворков.
P.S. Полное описание загрузки файлов (да еще и в базу данных) на любом языке займет более 250 страниц.
Надо признать, что некоторые решения спринга сложноваты, но по факту выходит, что смотришь на спринг и думаешь: ишчиво наворотили, кому это надо? Начинаешь свой велосипед пилить, и сам себя хвалишь, вот ведь я хитрец, всех переиграл, сейчас простенькое решение накидаю, без всех этих абстракций — только то, что мне нужно, а через какое-то время смотришь, а ты делаешь тоже самое, что уже в спринге написано, только там уже решены многие проблемы, с которыми ты сталкивался и часто довольно неплохо. И это я не говорю о бесспорно крутых продуктах вроде IoC.
Плохо, что Spring стал своего рода стандартом де-факто. Его лепят везде, даже не задумываясь о целесообразности. В большинстве проектов, которые я видел, Spring рудиментарен и проще и лучше было бы обойтись без него, чем с ним, заменяя легковесными библиотеками с целевым функционалом. Велосипеды легче вести, контролировать и кастомизировать. Они всегда более предсказуемые и легко отлаживаемое. Сколько раз приходилось биться в истерике, когда логически вроде бы все должно работать, но фреймворк либо кидает несколько страниц страшного эксепшна, либо еще хуже — просто игнорирует написаное или работает не как ожидалось? Это бич всех фреймворщиков.
Насчет неплохого решения с архитектурной точки зрения я мог бы долго спорить. Тут и проблемы изначальной заточки только под разработку веб через MVC, и сомнительность самой парадигмы IoC, и куча совершенно ненужных прослоек, типа Spring Data, и тупо неудобство многих вещей, etc…
Насчет неплохого решения с архитектурной точки зрения я мог бы долго спорить. Тут и проблемы изначальной заточки только под разработку веб через MVC, и сомнительность самой парадигмы IoC, и куча совершенно ненужных прослоек, типа Spring Data, и тупо неудобство многих вещей, etc…
Плохо, что Spring стал своего рода стандартом де-факто. Его лепят везде, даже не задумываясь о целесообразности.
Действительно плохо, если люди не думают, когда выбирают средства для разработки.
В большинстве проектов, которые я видел, Spring рудиментарен и проще и лучше было бы обойтись без него, чем с ним, заменяя легковесными библиотеками с целевым функционалом.
Просто интересно, какие именно части спринга вы имеете ввиду и о каких легковесных библиотеках вы говорите? Каким таким критериям они удовлетворяют, что делает их легковесными и отличает от спринга?
Велосипеды легче вести, контролировать и кастомизировать. Сколько раз приходилось биться в истерике, когда логически вроде бы все должно работать, но фреймворк либо кидает несколько страниц страшного эксепшна, либо еще хуже — просто игнорирует написаное или работает не как ожидалось? Это бич всех фреймворщиков
В целом, с этим я соглашусь, но эта сентенция скорее верна для случаев, когда нужно специфичное решение и фреймворк не достаточно хорошо расширяется. Если же от фреймворка требуется типичное применение или он достаточно хорошо конфигурируется как спринговый ioc (например), то для меня в общем случае проще использовать его для решения моей задачи, чем писать своё решение или не использовать инструмента вообще.
Насчет неплохого решения с архитектурной точки зрения я мог бы долго спорить. Тут и проблемы изначальной заточки только под разработку веб через MVC, и сомнительность самой парадигмы IoC, и куча совершенно ненужных прослоек, типа Spring Data, и тупо неудобство многих вещей, etc…
Не совсем понял, что означает «заточка веб тольк очерез mvc» — если вы о web-mvc-фреймворке, то он на то и mvc-фреймворк, чтобы быть завязанным на mvc. Но и в остальном — о чем тут спорить? Во-первых, вам никто не навязывает то или иное решение от спринга, он достаточно модульный, чтобы не заставлять использовать все свои решения и даже общую схему приложения не навязывает. Во-вторых, я уже говорил, что некоторые их продукты сложноваты, но это не значит, что они не эффективны для решения тех задач для которых создавались.
Ну и конечно использовать IoC или нет — это вопрос вкусовщины и в целом восприятия архитектуры, о котором бессмысленно спорить.
> Просто интересно, какие именно части спринга вы имеете ввиду
Как я уже сказал, IoC — с точки зрения архитектуры концепт достаточно сомнительный. Организация архитектуры более традиционными способами имеет преимущества. Если все же нужен IoC, возьмите Guice — это мелкий IoC контейнер с отличной конфигурацией через DSL. Затем, в реальном проекте очень быстро понимаешь, что и в нем нет необходимости: связать пару бинов можно и ручками.
Затем идет пресловутый Spring MVC. Благодаря Struts и куче выросших на нем кодописунов, он быстро проник в массы и стал стандартом де-факто. Идея была понятна, но совершенно непроработана. В итоге, использование MVC на порядки усложнило разработку. Кроме того, MVC легко позволяет делать плохо, что в неумелых руках ведет к полной дезорганизации. Могу сказать, что в 90% сайтов хватит Servlet + JSP + JSTL, про которые все как-то очень быстро забыли.
Для справки, Apache Tapestry — гораздо более проработанный и организованный фреймворк, нежели Spring MVC.
Spring Data — совершенно рудиментарен. Запросы к базе данных в реальном приложении — это нечто более, чем найти объект в таблице по полям. Repository-per-entity — совершенно глупый концепт, который заставляет пользователя делать JOIN вручную, увеличивая в N раз число запросов к БД.
Spring Hateoas — искусственный концепт экспортировать Spring Data через Rest. Те же проблемы, только еще с участием HTTP.
Т.о. большинство концептов Spring-а искусственны и годны только в теории и для демок.
> Не совсем понял, что означает «заточка веб тольк очерез mvc»
Я об IoC и его scopes. В spring определен request scope, который сохраняет состояние объектов во время запроса. Однако его использование ограничено исключительно MVC контейнером. Когда запросы приходят, например, через JMS или RMI, придется разрабатывать и интегрировать свой scope. Сделать абстрактный request scope для всех endpoint-ов разработчики не догадались. Кроме того, MVC включено в Core Spring Framework, а не существует как отдельный проект, что вместе с другими технологиями делает понятным целевое использование фреймворка.
Вообще согласен, спорить особо не о чем. Spring предлагает большой инструментарий для разработки и интеграции. При хорошем владении и умелом использовании можно достичь хорошего качества продукта.
Как я уже сказал, IoC — с точки зрения архитектуры концепт достаточно сомнительный. Организация архитектуры более традиционными способами имеет преимущества. Если все же нужен IoC, возьмите Guice — это мелкий IoC контейнер с отличной конфигурацией через DSL. Затем, в реальном проекте очень быстро понимаешь, что и в нем нет необходимости: связать пару бинов можно и ручками.
Затем идет пресловутый Spring MVC. Благодаря Struts и куче выросших на нем кодописунов, он быстро проник в массы и стал стандартом де-факто. Идея была понятна, но совершенно непроработана. В итоге, использование MVC на порядки усложнило разработку. Кроме того, MVC легко позволяет делать плохо, что в неумелых руках ведет к полной дезорганизации. Могу сказать, что в 90% сайтов хватит Servlet + JSP + JSTL, про которые все как-то очень быстро забыли.
Для справки, Apache Tapestry — гораздо более проработанный и организованный фреймворк, нежели Spring MVC.
Spring Data — совершенно рудиментарен. Запросы к базе данных в реальном приложении — это нечто более, чем найти объект в таблице по полям. Repository-per-entity — совершенно глупый концепт, который заставляет пользователя делать JOIN вручную, увеличивая в N раз число запросов к БД.
Spring Hateoas — искусственный концепт экспортировать Spring Data через Rest. Те же проблемы, только еще с участием HTTP.
Т.о. большинство концептов Spring-а искусственны и годны только в теории и для демок.
> Не совсем понял, что означает «заточка веб тольк очерез mvc»
Я об IoC и его scopes. В spring определен request scope, который сохраняет состояние объектов во время запроса. Однако его использование ограничено исключительно MVC контейнером. Когда запросы приходят, например, через JMS или RMI, придется разрабатывать и интегрировать свой scope. Сделать абстрактный request scope для всех endpoint-ов разработчики не догадались. Кроме того, MVC включено в Core Spring Framework, а не существует как отдельный проект, что вместе с другими технологиями делает понятным целевое использование фреймворка.
Вообще согласен, спорить особо не о чем. Spring предлагает большой инструментарий для разработки и интеграции. При хорошем владении и умелом использовании можно достичь хорошего качества продукта.
Как я уже сказал, IoC — с точки зрения архитектуры концепт достаточно сомнительный.
Что именно вы находите в нем сомнительного?
Как я уже сказал, IoC — с точки зрения архитектуры концепт достаточно сомнительный. Организация архитектуры более традиционными способами имеет преимущества.
Если выбираешь IoC осознанно и принимаешь нюансы его использования, то это очень мощное архитектурное решение. Конечно не лишенное проблем, но дающее большУю гибкость, инкапсуляцию и простоту использования.
Если все же нужен IoC, возьмите Guice — это мелкий IoC контейнер с отличной конфигурацией через DSL.
Не очень понимаю, по каким криетриям он «мелкий»? По быстродействию? По потребленю памяти? По размеру jar-ника? Абсолютно ничего не имею против Guice, просто не вижу причин для любой задачи предпочитать его спрингу. У спринга, к слову, тоже есть отличные джава-конфиги аля-дсл.
Затем, в реальном проекте очень быстро понимаешь, что и в нем нет необходимости: связать пару бинов можно и ручками.
Думаю, в проекте на пару бинов, можно и без IoC обойтись, согласен.
Затем идет пресловутый Spring MVC. Благодаря Struts и куче выросших на нем кодописунов, он быстро проник в массы и стал стандартом де-факто. Идея была понятна, но совершенно непроработана.
Да, у второго struts-а было очень много проблем, но он резко улучшал структуру, упрощал рутинные операции и был достаточно гибок, чтобы не сильно стеснять за что ему огромное спасибо.
В итоге, использование MVC на порядки усложнило разработку.
Кому именно он её усложнил? Именно вам стало хуже? Лично я был очень рад его использовать — в то время это было очень достойное решение акутальных проблем. Из ваших слов можно сделать вывод, что mvc как подход в разработке под web усложнил разработку, что выглядит очень сомнительным заявлением.
Кроме того, MVC легко позволяет делать плохо, что в неумелых руках ведет к полной дезорганизации. Могу сказать, что в 90% сайтов хватит Servlet + JSP + JSTL, про которые все как-то очень быстро забыли.
Видимо, вы никогда не видели как «плохо» можно сделать используя Servlet + JSP + JSTL. В свою очередь, spring web-mvc дает неплохую струтуру для проектов, что на мой взгляд делает проекты на нем в среднем чуть лучше, чем стандртный стек.
Для справки, Apache Tapestry — гораздо более проработанный и организованный фреймворк, нежели Spring MVC.
Тапестри это компонентный фреймворк и было бы глупо сравнивать spring web-mvc с ним, подходы совершенно разные. Если смотреть на классические mvc фреймворки для веба, то на мой взгляд у спринга одно из лучших решений. И да, тапестри очень достойное решение, но так же как и любой другой большой фреймворк имеет массу подводных камней и узких мест. Что в очередьной раз подтверждает тезис, что каждой задаче свой инструмент.
Spring Data — совершенно рудиментарен. Запросы к базе данных в реальном приложении — это нечто более, чем найти объект в таблице по полям. Repository-per-entity — совершенно глупый концепт, который заставляет пользователя делать JOIN вручную, увеличивая в N раз число запросов к БД.
Джоины руками, серьезно!? Вас же никто не заставляет все запросы делать исключительно декларативно. Наверное вы имеете ввиду spring data jpa, котоый по большому счету набор инструментов для работы с jpa-провайдерами вроде hibernate. Orm это вообще холиварный вопрос и явно не для этой статьи.
Spring Hateoas — искусственный концепт экспортировать Spring Data через Rest. Те же проблемы, только еще с участием HTTP.
Hateoas — никак со spring data не связан, не понимаю, откуда вы вообще информацию берете? Придумываете?
Т.о. большинство концептов Spring-а искусственны и годны только в теории и для демок.
С любым инструментом нужно учиться работать, исследовать возможности. Пока не умеешь, любой даже самый хороший инструмент будет искусственным концептом.
Я об IoC и его scopes. В spring определен request scope, который сохраняет состояние объектов во время запроса. Однако его использование ограничено исключительно MVC контейнером. Когда запросы приходят, например, через JMS или RMI, придется разрабатывать и интегрировать свой scope. Сделать абстрактный request scope для всех endpoint-ов разработчики не догадались.
Не очень понимаю претензий, если фреймворк из коробки чего-то не умеет — совсем не значит, что это плохой инструмент, тем более, что создатели предумсотрели возможность для расширения в этом месте.
Кроме того, MVC включено в Core Spring Framework, а не существует как отдельный проект, что вместе с другими технологиями делает понятным целевое использование фреймворка.
web-mvc заявлен как часть фреймворка, но не является его обязательной частью.
Фреймоворки нужно сравнивать с библиотеками — какие сравнительные достоинства и недостатки. Кто-нибудь может быстренько накидать сравнительную таблицу?
Я считаю, что для каждого конкретного проекта нужно смотреть отдельно. Да, фреймворки отчасти спутывают руки, но если они помогают достичь цели, пусть и со связанными руками, то тут следует подумать, что для данного проекта приоритетнее: удобство разработки + единообразие мышления членов команды(пусть и навязанное фреймворком), или же сложности разработки функций, не предусмотренных фреймворком, заставляют писать «через» фреймворк, и тогда уже будет легче обойтись без фреймворка/написать свой. Поправьте, если ошибаюсь.
Размер проекта по моему ощущению прямо пропорционален количеству использованных фреймворков. Не использовать же фреймворки вообще — это утопия, ведь любая абстракция дающая нам какую-то структуру для разработки это уже фреймворк.
3- 7 лет и многое из написанного становится бессмысленным набором кода.
Конкретный пример PHP и ООП.
Конкретный пример PHP и ООП.
Версии PHP, версии Mysql. Вы сейчас начнете спорить… Я сразу отвечу, я смотрю на примеры из жизни. Тут кто-нибудь помнит, что такое php-nuke?
Или недавний пример с форума, человек пришел с проблемой, нашел Free-cms на хостинге не работает — ошибок лезет куча, cms-ке три года…
При этом, чем сложнее система и навороченнее, тем больше вероятности, что после забрасывания проекта (а это 90% процентов случаев) — система через 3 года полетит в помойку… А как жаль, там же ООП, гениальные реализации, добрая сотня классов.
Или недавний пример с форума, человек пришел с проблемой, нашел Free-cms на хостинге не работает — ошибок лезет куча, cms-ке три года…
При этом, чем сложнее система и навороченнее, тем больше вероятности, что после забрасывания проекта (а это 90% процентов случаев) — система через 3 года полетит в помойку… А как жаль, там же ООП, гениальные реализации, добрая сотня классов.
Конечно начну спорить, ведь никто не просит их обновлять. А то, что хостинг самовольно меняет версию ПО никак не связано с тремя годами или PHP или ООП. И никуда не летит) Да и если говорить про PHP, что из обратной совместимости, кроме ereg (и еще парочки редчайще используемых возможностей) вообще могло вызвать ошибки?
Версии PHP, версии Mysql.
А еще есть версии Python, версии Ruby, Java… Все меняется и это довольно нормальное течение вещей.
Тут кто-нибудь помнит, что такое php-nuke?
В последний раз я видел оный лет так 9 назад. И больше не хочу видеть.
Или недавний пример с форума, человек пришел с проблемой, нашел Free-cms на хостинге не работает — ошибок лезет куча, cms-ке три года…
Так может проблема в том что разработчики CMS забили на ее разработку?
что после забрасывания проекта (а это 90% процентов случаев) — система через 3 года полетит в помойку…
Вы же понимаете что для чего-то серьезного брать инструмент с высокой вероятностью того, что ее забросят, это как минимум глупо.
А как жаль, там же ООП, гениальные реализации, добрая сотня классов.
Для вас ООП и гениальность как-то коррелируется с количеством классов?
Для меня коррелируются силы и время, потраченные на разработку 100 мегабайтного пакета, который решает одну задачу — Интернет-Магазин. И все ради призрачной масштабируемости и еще более иллюзорного удобства пользователя — нажал и загрузилось, аж без перезагрузки страницы и не слева, и не справа, а на плывом из глубины монитора :) с рюшечками и шашечками… + целый мегаадптер с 10 классами, который решает одну задачу — установку cms с помощью нажатия next, но при этом пользователь (бизнес-пользователь) даже для этого дела приглашает специалиста.
Я бы не стал относить ООП к фундаментальным аспектам общей информатики. Это надстройка, она ее была, ею и останется. Согласитесь, есть большая разница между проектированием автомобиля и гаражным тюнингом.
Я бы не стал относить ООП к фундаментальным аспектам общей информатики. Это надстройка, она ее была, ею и останется. Согласитесь, есть большая разница между проектированием автомобиля и гаражным тюнингом.
Там с 4 по 5 изменений довольно много, думаю, что zend за этот коротки период — 7-10 лет (а это очень короткий период) сильно переработана. И все будто бы имеет обратную совместимость, но то тут, то там всплывают приятные неожиданности.
Фреймворки портят разработку
Почти точно сформулировано. Только фреймворки портят, скорее, разработчика. Точно так же как упор на структуры данных, ООП, функционал, уводят от разработки фендаментальных вещей…
Фреймворки портят разработку
Почти точно сформулировано. Только фреймворки портят, скорее, разработчика. Точно так же как упор на структуры данных, ООП, функционал, уводят от разработки фендаментальных вещей…
за этот коротки период — 7-10 лет
ничего себе короткий период. Даже по меркам жизни человека это не такой уж и короткий период, не говоря уж о индустркии, которой от силы лет 40.
И все будто бы имеет обратную совместимость, но то тут, то там всплывают приятные неожиданности.
Вы вообще-то говорите о PHP, который имеет свои особенность в плане развистия. Обычно языки проектируют, а с PHP вышел стихийный взрыв. Только начиная с 5-ой версии что-то начали менять и воспринимать язык серьезно можно только с версии 5.3.
Только фреймворки портят, скорее, разработчика.
Проблема не в технологиях а в головах. Я уверен что если что угодно дать новичку и оставить его с этой новой штукой на годи, он наваяет тонны неподдерживаемых решений.
Точно так же как упор на структуры данных, ООП, функционал, уводят от разработки фендаментальных вещей…
Не могли бы поделиться? Ибо то что вы перечислили для меня является фундаментальными вещами, которые помогают решать задачи бизнеса эффективнее, а ведь это главная цель программистов. make the client happy.
Автомобили вредят здоровью! Раньше пешком все ходили и здоровыми были, а теперь разъездились все!
Не аргумент — а демагогия.
ну так и сам пост это демагогия. Чего уж там. Скорость разработки никто не отменял. И если с фреймворками скорость падает — это конечно же повод задуматься. А если увеличивается и остается линейной — то почему бы и да? Все остальное это дело вкуса и личное мнение людей, на которое в общем-то всем плевать.
Демагогия в основном в тексте поста. Разработку портят не инструменты, а неумение ими обращаться, или использование не к месту и далее по списку.
Таки да — вредят здоровью. Пойдите на природу, куда народ съехался на шашлыки, разделся и загорает. И поглядите, сколько среди автовладельцев толстяков — практически поголовно.
решать задачи бизнеса эффективнее, а ведь это главная цель программистов.
Ваши субъективное право относится к программированию как составляющей бизнеса.
Ваши субъективное право относится к программированию как составляющей бизнеса.
Ваши субъективное право относится к программированию как составляющей бизнеса.
Ок, а тогда как к нему относиться еще? Так или иначе программисты решают задачи бизнеса. Тот же интернет-магазин — автоматизация и уменьшение расходов (не нужен физический магазин, можно улучшить логистику и т.д. лучше и проще отчетность). Или там Вася пупкин, который для души выпустил продукт и хочет что бы его использовали. И для этого он принимает решения которые позволяют ему развивать проект максимально эффективным образом и выкатывать новые фичи, которые требуют пользователи или которые могут нести им какую-то ценность (или себе) как можно быстрее пока конкуренты не сделали этого.
Или это все просто так и для души, и платят программистам просто так.
Если Вам расскажут, зачем вообще все это надо, Вы все равно не поверите и будете стоять на своем…
Тем более, почему в России так активно продивагаются всякие «технологии»… типа JS, Ajax и всякая лабудень, но это уже мы уходим в политику.
Про ООП, ООП — это не программирование — это оперирование стуктурами, или данных или набором уже готовых логических схем.
Обратите внимание, как много и часто у нас затравливают системщиков, тех же сишников, чуть ли не единственных, которые вообще что-то понимают.
Обсуждать какой-то там бизнес, и то, что нужно какому-то там заказчику мне не интересно, для этого есть фриланс.
Тем более, почему в России так активно продивагаются всякие «технологии»… типа JS, Ajax и всякая лабудень, но это уже мы уходим в политику.
Про ООП, ООП — это не программирование — это оперирование стуктурами, или данных или набором уже готовых логических схем.
Обратите внимание, как много и часто у нас затравливают системщиков, тех же сишников, чуть ли не единственных, которые вообще что-то понимают.
Обсуждать какой-то там бизнес, и то, что нужно какому-то там заказчику мне не интересно, для этого есть фриланс.
Srsly? А формально доказать возьметесь?
А что, реальные доказательства не интересны?
А что, реальные доказательства не интересны?
Учим мат часть.
В целом предлагаю закрыть тему, так как народ тут не может определиться в разнице между «кодером» и «программистом», а вы тут поднимаете холивары на уровень выше.
В целом предлагаю закрыть тему, так как народ тут не может определиться в разнице между «кодером» и «программистом», а вы тут поднимаете холивары на уровень выше.
>народ тут не может определиться в разнице между «кодером» и «программистом»
Срач системные архитекторы с опухшим ЧСВ против всех остальных?
В реальной жизни программист обычно и за архитектора и за кодера — в одном лице! А не так что «Его Божественность Системный Архитектор написанием кода ручки не марает, весь код — индусы за еду пишут».
Срач системные архитекторы с опухшим ЧСВ против всех остальных?
В реальной жизни программист обычно и за архитектора и за кодера — в одном лице! А не так что «Его Божественность Системный Архитектор написанием кода ручки не марает, весь код — индусы за еду пишут».
Fesor, идите и учите, если Вам нужно. И избавьтесь от императивности в тоне…
Я никаких холиваров не поднимаю, есть выводы, сделанные на основе длительного наблюдения.
Кратко и конкретно: программисты ( «чем ниже уровень» ) почему-то у нас начиная с 90-х затравливались, массово.
«Пишу на С++ за еду» — и т.д.
Вот к этим словам автора, которым почему-то я верю, хотелось бы добавить
«Фреймворк же сковывает вас, привязывая к себе. Каждый из них имеет собственную выстроенную логику работы, которую не всегда можно запросто уловить. И при переходе с одного языка на другой/из одной, команды в другую вам приходится зачастую тратить несколько дней, чтобы понять, как использовать новый фреймворк».
Вот это:
И в общей массе уводит в сторону талантливых людей от фундаментальных разработок, вместо этого они бегут получать сертификаты от Микрософт, Хренософт, чтобы потом писать кнопочки для разных мелкокоммерческих сайтов.
" А формально доказать возьметесь? "
Формальным доказательством на 2015 год является почти полное отсутствие системного программирования в России.
P.S. Покажите мне российскую операционную систему, чтоб при загрузке там не торчало Ванилья Соурс и тогда можно переходить к формальным доказтельствам.
В целом предлагаю закрыть тему, Вот не надо ничего закрывать, не нравится тема, не читайте, места в Интернете много, хостинг штука резиновая… И, кстати, формально у нас в стране демократия =)
Я никаких холиваров не поднимаю, есть выводы, сделанные на основе длительного наблюдения.
Кратко и конкретно: программисты ( «чем ниже уровень» ) почему-то у нас начиная с 90-х затравливались, массово.
«Пишу на С++ за еду» — и т.д.
Вот к этим словам автора, которым почему-то я верю, хотелось бы добавить
«Фреймворк же сковывает вас, привязывая к себе. Каждый из них имеет собственную выстроенную логику работы, которую не всегда можно запросто уловить. И при переходе с одного языка на другой/из одной, команды в другую вам приходится зачастую тратить несколько дней, чтобы понять, как использовать новый фреймворк».
Вот это:
И в общей массе уводит в сторону талантливых людей от фундаментальных разработок, вместо этого они бегут получать сертификаты от Микрософт, Хренософт, чтобы потом писать кнопочки для разных мелкокоммерческих сайтов.
" А формально доказать возьметесь? "
Формальным доказательством на 2015 год является почти полное отсутствие системного программирования в России.
P.S. Покажите мне российскую операционную систему, чтоб при загрузке там не торчало Ванилья Соурс и тогда можно переходить к формальным доказтельствам.
В целом предлагаю закрыть тему, Вот не надо ничего закрывать, не нравится тема, не читайте, места в Интернете много, хостинг штука резиновая… И, кстати, формально у нас в стране демократия =)
есть выводы, сделанные на основе длительного наблюдения.
Сколько лет вы в профессии?
Кратко и конкретно: программисты ( «чем ниже уровень» ) почему-то у нас начиная с 90-х затравливались,
У кого «у вас»? «У нас» не затравливались, и училось много, и работы было достаточно.
Формальным доказательством на 2015 год является почти полное отсутствие системного программирования в России.
Как это доказывает тезис «ООП — это не программирование»?
Ясно. Вы представляете сколько нужно человеко-лет для реализации операционной системы? А теперь скажите зачем? Потешить себя мыслью о национальной операционной системе? Да, операционку сложности DOS написать один человек более чем способен в адекватные сроки. Но кому сейчас нужен еще один DOS? Более того, кому сейчас нужна еще одна операционная система? По сути еще одна платформа, их и так уже слишком много.
ReactOS например. Хотя опять же, ограничивать себя рамками национальной идеи как-то глупо когда разговор идет о настолько масштабном проекте.
Не знаю как там в России, а в Беларуси с этим вроде как все хорошо. Другой вопрос что в системщики идут 2-4 человека из 100, но каков спрос таково и предложение.
я знаю массу людей которые уходили после ВУЗа в аспирантуру как раз таки что бы заниматься фундаментальными разработками. И где-то через пол года они расстраивались. И причем тут фреймворки и ООП?
p.s. Там есть кнопочка «ответить», в которую вы почему-то не попадаете.
P.S. Покажите мне российскую операционную систему, чтоб при загрузке там не торчало Ванилья Соурс и тогда можно переходить к формальным доказтельствам.
ReactOS например. Хотя опять же, ограничивать себя рамками национальной идеи как-то глупо когда разговор идет о настолько масштабном проекте.
является почти полное отсутствие системного программирования в России.
Не знаю как там в России, а в Беларуси с этим вроде как все хорошо. Другой вопрос что в системщики идут 2-4 человека из 100, но каков спрос таково и предложение.
И в общей массе уводит в сторону талантливых людей от фундаментальных разработок
я знаю массу людей которые уходили после ВУЗа в аспирантуру как раз таки что бы заниматься фундаментальными разработками. И где-то через пол года они расстраивались. И причем тут фреймворки и ООП?
p.s. Там есть кнопочка «ответить», в которую вы почему-то не попадаете.
Вы сравнили — Беларусь и Россию. У вас порядка больше на порядок, а может на 2, а может на n.
Я не знаю, как сейчас обстоят дела с информатикой в школе в России (так как это фундамент того, что будет 10-20 лет), в 90-х преподавалась настолько безобразно, что складывать ощущение будто это делается просто нарочно.
Я не знаю, как сейчас обстоят дела с информатикой в школе в России (так как это фундамент того, что будет 10-20 лет), в 90-х преподавалась настолько безобразно, что складывать ощущение будто это делается просто нарочно.
У вас порядка больше на порядок, а может на 2, а может на n.
Вот давайте вы поживете у нас и «понаблюдаете» годика 4 хотя бы. Порядок у нас граничит с маразмом и имитацией бурной деятельности и только. У каждой страны свои проблемы. Я думаю у вас что-то похожее только со своими нюансами.
в 90-х преподавалась настолько безобразно, что складывать ощущение будто это делается просто нарочно.
Я боюсь что с этим все плохо и тут как повезет с преподавателями. Сейчас и физику/математику в школах безграмотно преподают. Да и в ВУЗах частенько тоже начитывают бред. У всего есть причина и следствие — работать преподавателем не профитно ни по деньгам ни по статусу. Большинсто либо просто не смогли выйти дальше либо работают ради идеи, коих меньшинство.
Ну вот, Вы сами это признаете. Вдобавок, есть некоторые причины считать, что сворачивание разработок в области и IT — как железо, так и программы — осуществлялось намеренно. И вместо фундаментальных знаний/занятий подбрасываются фреймворки (готовые решения, под капот почти не надо залезать), это почти на уровне пропаганды «Построй свой сайт легко и просто с такой-то системой 10 щелчками мыши».
готовые решения, под капот почти не надо залезать
Мне нравится думать что человек должен понимать как устроено то что он использует хотя бы на один уровень абстракции ниже.
Построй свой сайт легко и просто с такой-то системой 10 щелчками мыши
Оукей, давайте вспомним начало 20-ого века.Было штучное производство автомобилей и бац, Форд придумал конвеерную сборку. В итоге все потихоньку начали автоматизировать производство в угоду бизнесу и потребителям. В то же время штучная сборка на заказ осталась. И для этой сборки часть деталей заказывается, часть делается вручную…
За последние лет 20 потребность в простых решениях увеличилась, так как потребителей стало невообразимо больше, в то же время вырастить сильных разработчиков как было сложно так и осталось. Вывод — уменьшение сложности и добавить армию роботяг, которые штампуют сотнями сайты в угоду бизнесу. Штучное производство осталось, его гораздо меньше но и людей которые могут его себе позволить не так много (относительно).
Статья www.geektimes.ru/post/249972 «Инфляция программного обеспечения с точки зрения ресурсов процессора — почему новые версии приложения порой гораздо медленнее старых?» — про последствия моды на фреймворки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фреймворки портят разработку