Comments 65
По-моему ответ очевиден.
Капитан Очевидность в замешательстве
А что у ваз за браузер? Шрифты очень красивые. Похоже на сафари.
Жжоте уважаемый :)
Когда я голосовал было 0 / 100, по этому подумал что ответ для всех очевиден так-же, как и для меня :)
Простите.
Когда я голосовал было 0 / 100, по этому подумал что ответ для всех очевиден так-же, как и для меня :)
Простите.
Вы таки не поверите:
По-моему это не взаимоисключающие утверждения.
можно узнать, в чем смысл голосования?
Не успел написать коммент, а как в опрос добавить пояснение — не нашел.
nickmitin.habrahabr.ru/blog/62093/#comment_1709290
nickmitin.habrahabr.ru/blog/62093/#comment_1709290
Все чаще и чаще слышу вещи, что ООП и фреймворки — это, чуть-ли, не изобретение веб-программистов. Я начинал с классики и после прихода в веб не заметил что стал присать что-то принципиально по-другому. Таким образом, не понимаю в каком месте проходит граница между вебом и не-вебом.
Интересно мнение хабражителей.
Интересно мнение хабражителей.
Отличается, но не сильно :-) А еще многое зависит от специфики проекта (кто-то установил Wordpress и уже посчитал себя программистом).
Считаю.
Воздержался, т.к. вариантов ответа слишком мало.
Имхо веб-разработка — это такая же прикладная область, как, скажем, программирование под WinAPI или OpenGL и прочую хрень. Есть некоторые специфичные интерфейсы/библиотеки, которые нужно будет знать для достижения результата, и есть стандартная база — умение составлять алгоритмы, бить код на классы и т.д (это в Вашем понятии «классическое» программирование?). Предметная область и специфичные вещи требуют отдельного ознакомления, и чтобы получить экспертный эксп ее придется расковыривать очень глубоко — не стоит недооценивать сложность этого. С другой стороны, без знания базы прогера вообще нельзя назвать разработчиком, а для хорошего «классика» в любом проекте найдется место.
Имхо веб-разработка — это такая же прикладная область, как, скажем, программирование под WinAPI или OpenGL и прочую хрень. Есть некоторые специфичные интерфейсы/библиотеки, которые нужно будет знать для достижения результата, и есть стандартная база — умение составлять алгоритмы, бить код на классы и т.д (это в Вашем понятии «классическое» программирование?). Предметная область и специфичные вещи требуют отдельного ознакомления, и чтобы получить экспертный эксп ее придется расковыривать очень глубоко — не стоит недооценивать сложность этого. С другой стороны, без знания базы прогера вообще нельзя назвать разработчиком, а для хорошего «классика» в любом проекте найдется место.
Какой вариант ответа, по-вашему, стоит добавить?
Вы слишком резко провели грань, и к тому же оставили за кадром, что такое «классическое» программирование (моя первая мысль была про классический паскаль, который хорошо подходит для написания алгоритмов, но на нем почти нереально выпустить продукт). По-вашему выходит, что либо веб-программирование — это и есть «классическое», либо это в принципе что-то отличное от него (примерно на уровне отличий декларативных и императивных языков). Мне кажется, Вы на самом деле хотели спросить что-то другое :), например «Требует ли веб специальных знаний по сравнению с классическим».
веб-программисты отвечают нет, а не веб — да? :)
А где вариант «не считаю вэб-программирование» программированием?
Я создавал этот опрос не для того, чтобы поглумиться над веб-программированием.
Может, в другой раз.
Может, в другой раз.
Веб-программирование — это не только пхп-быдлокодинг.
Если сравнивать именно серьезную веб-разработку, а не визиткостроение, то обособленным не является.
А если говорить о построении крохотных сайтов, то это скорее бизнес (хотя тоже довольно интересная область с этой точки зрения).
А если говорить о построении крохотных сайтов, то это скорее бизнес (хотя тоже довольно интересная область с этой точки зрения).
А в чем отличие крохотных сайтов от серьезной веб-разработки?
Хорошее корпоративное веб-приложение на Tapestry + Spring + whatever, отличается от визитки на битриксе.
когда мы строим крохотные сайты, мы имеем основу, которую докручиваем, подкрашиваем, покрываем лаком и блестками. то что мы получим в итоге, может визуально разительно отличаться от той болванки, которую мы имели в начале. но это та же самая болванка в ярких одеждах. создание маленьких сайтов — это работа в первую очередь дизайнера и только потом — программирование. это если мы говорим о крохотных сайтах.
серьезные веб-проекты практически всегда строятся с нуля. это в первую очередь архитектура, потом программирование и только потом — дизайн. серьезный веб-проект невозможен без знаний ООП, паттернов, и прочих прелестей «классического» программирования.
серьезные веб-проекты практически всегда строятся с нуля. это в первую очередь архитектура, потом программирование и только потом — дизайн. серьезный веб-проект невозможен без знаний ООП, паттернов, и прочих прелестей «классического» программирования.
паритет сохраняется. мой ответ, нет не считаю
Если вопрос подразумевает «считаете ли вы настраивание цмсок на стоковых шаблонах обособленным видом быдлоразработки RAD-приложений на Вижуал Бейсике и шароварных компонентиках Делфи», с уверенностью отвечу — нет.
Я тоже не считаю, все зависит от сложности величины проектов
А как сложность влияет на «обособленность вида»?
На мой взгляд опрос странный, и что такое «обособленный вид» я тоже не понял.
Программирование само по себе, оно везде одинаковое, просто разная специфика, разное окружение, разный набор стандартных подходов для каждой области. Имхо, сейчас порог вхождения в веб-разработку, несколько ниже, чем например в системное программирование, это обусловлено и развитыми средствами для разработки, и популярностью. Но этот низкий порог дарит людей для которых паттерн MVC принесен веб-разработкой, и нигде больше не используется и подобных им.
На мой взгляд опрос странный, и что такое «обособленный вид» я тоже не понял.
Программирование само по себе, оно везде одинаковое, просто разная специфика, разное окружение, разный набор стандартных подходов для каждой области. Имхо, сейчас порог вхождения в веб-разработку, несколько ниже, чем например в системное программирование, это обусловлено и развитыми средствами для разработки, и популярностью. Но этот низкий порог дарит людей для которых паттерн MVC принесен веб-разработкой, и нигде больше не используется и подобных им.
Если считать классическим программированием то, которое предшествовало объектно-ориентированному, то ответ очевиден (первый, отрицательный).
Но даже и без того прототипное наследование джаваскрипта вносит заметную разницу по сравнению с классами C++ или Дельфи. А также замыкания и вообще интерпретируемость.
Но даже и без того прототипное наследование джаваскрипта вносит заметную разницу по сравнению с классами C++ или Дельфи. А также замыкания и вообще интерпретируемость.
> наследование джаваскрипта вносит заметную разницу по сравнению с классами C++ или Дельфи.
Это уже особенности языка. Помимо JS, есть еще много языков, которые поддерживают замыкания или интерпретируемы.
Кстати, JS уже дошел до необходимости компилироваться в OPCODE.
Это уже особенности языка. Помимо JS, есть еще много языков, которые поддерживают замыкания или интерпретируемы.
Кстати, JS уже дошел до необходимости компилироваться в OPCODE.
>Но даже и без того прототипное наследование джаваскрипта вносит заметную разницу по сравнению с классами C++ или Дельфи. А также замыкания и вообще интерпретируемость.
Из Вашего предложения можно сделать вывод, что JS первый массовый язык, который кардинально отличается от «классики» — C++/Delphi.
JS здесь далеко не первый. Дедушка lisp может похвастаться и замыканиями, и интроспекцей, и метапрограммированием.
А интерпритируемость она была в perl/tcl/forth — это навскидку.
Из Вашего предложения можно сделать вывод, что JS первый массовый язык, который кардинально отличается от «классики» — C++/Delphi.
JS здесь далеко не первый. Дедушка lisp может похвастаться и замыканиями, и интроспекцей, и метапрограммированием.
А интерпритируемость она была в perl/tcl/forth — это навскидку.
для меня разница заключается только в методах передачи данных и специфических областях действия объектов (сессии, запросы и т.п.)
Те, кто считают, что веб-приложения не компилируются, а десктопные компилируются — вспомните, что много десктопного софта написано на Python и на Ruby, да и на других «скриптовых» языках
Конечно, хотя бы потому что в веб программировании всё меньше и меньше учитывают ресурс памяти и вообще ресурсы.
Хотя большинство нынешних программ такие же. Прога собирает статистику с плеера и весит в памяти 11 метров(хотя это еще так сказать «легкий» пример.)
Зовите меня старомодным, но по мне все же лучше релизить программы хорошо оптимизированные и занимающие меньше ресурсов.
Тема довольно тяжелая.
Хотя большинство нынешних программ такие же. Прога собирает статистику с плеера и весит в памяти 11 метров(хотя это еще так сказать «легкий» пример.)
Зовите меня старомодным, но по мне все же лучше релизить программы хорошо оптимизированные и занимающие меньше ресурсов.
Тема довольно тяжелая.
Позвольте с вами не согласиться. Для веба ресурсоемкость очень важна. Так как один сервер обслуживает кучу пользователей.
Прикол такой, да?
Воздержался.
И дело вот в чем: с одной стороны, у Веб-программирования есть ряд своих, весьма существенных особенностей, которые не встречаются, или же встречаются крайне редко в «классическом программировании», как то:
— отсутствие постоянного соединения, запуск приложения каждый раз, когда пользователь совершает какое-либо действие, а в это входит соединение с БД, разбор файла конфига и т.п. В особенности сказывается при использовании паттерна Front Controller. Вы можете себе представить «классическую программу», которая считывает свои же конфиги по 10 раз в секунду? Нет, классически это будет выполнено в виде демона, который все необходимое постоянно хранит в памяти.
— отсутствие возможности сохранять данные на компьютере пользователя. Конечно, клиент-серверная архитектура, все дела, и т.д. и т.п. Но в большинстве классических программ можно сохранить файлы на своем компе, если сервер завис, а многие программы делают это автоматически. В веб же такого нет — закрыл браузер, потерял изменения. Увы, куки маловаты, да и кэш флэша невелик.
— другой масштаб быстродействия — отклик от сервера может быть долгим, яваскрипт работает очень медленно, и т.п. Приведу реальный пример из своей практики — разница в быстродействии алгоритма поиска пути на C и на Action script различается в сотни (!) раз. Как следствие — для РПГ скорости хватит, а вот для стратегии, когда нужны десятки юнитов, не получится. Причина банальна — в то время, как С программа спокойно пишет двумерные массивы в память, AS создает объекты массивов в объектах массивов. Лучший способ оптимизации этого алгоритма на С (прирост в 2-3 раза) не дает никакого эффекта на AS — оверхед на внутренние проблемы слишком велик.
— другое программирование — в веб нельзя работать напрямую с памятью или процессором (нет, конечно можно, но не принято =) ). Все выполняется интерпретаторами, в песочницах, и т.п.
Но ведь и схожего немало! Синтаксис очень даже С-подобный, тот же Питон с успехом применяется как в Веб, так и на десктопе. Паттерны и архитектурные проблемы — один в один те же. Ряд техник — тот же.
Мое мнение — 50/50. Веб — это свои проблемы и свои заморочки в той же степени, что и те же проблемы и те же заморочки.
И дело вот в чем: с одной стороны, у Веб-программирования есть ряд своих, весьма существенных особенностей, которые не встречаются, или же встречаются крайне редко в «классическом программировании», как то:
— отсутствие постоянного соединения, запуск приложения каждый раз, когда пользователь совершает какое-либо действие, а в это входит соединение с БД, разбор файла конфига и т.п. В особенности сказывается при использовании паттерна Front Controller. Вы можете себе представить «классическую программу», которая считывает свои же конфиги по 10 раз в секунду? Нет, классически это будет выполнено в виде демона, который все необходимое постоянно хранит в памяти.
— отсутствие возможности сохранять данные на компьютере пользователя. Конечно, клиент-серверная архитектура, все дела, и т.д. и т.п. Но в большинстве классических программ можно сохранить файлы на своем компе, если сервер завис, а многие программы делают это автоматически. В веб же такого нет — закрыл браузер, потерял изменения. Увы, куки маловаты, да и кэш флэша невелик.
— другой масштаб быстродействия — отклик от сервера может быть долгим, яваскрипт работает очень медленно, и т.п. Приведу реальный пример из своей практики — разница в быстродействии алгоритма поиска пути на C и на Action script различается в сотни (!) раз. Как следствие — для РПГ скорости хватит, а вот для стратегии, когда нужны десятки юнитов, не получится. Причина банальна — в то время, как С программа спокойно пишет двумерные массивы в память, AS создает объекты массивов в объектах массивов. Лучший способ оптимизации этого алгоритма на С (прирост в 2-3 раза) не дает никакого эффекта на AS — оверхед на внутренние проблемы слишком велик.
— другое программирование — в веб нельзя работать напрямую с памятью или процессором (нет, конечно можно, но не принято =) ). Все выполняется интерпретаторами, в песочницах, и т.п.
Но ведь и схожего немало! Синтаксис очень даже С-подобный, тот же Питон с успехом применяется как в Веб, так и на десктопе. Паттерны и архитектурные проблемы — один в один те же. Ряд техник — тот же.
Мое мнение — 50/50. Веб — это свои проблемы и свои заморочки в той же степени, что и те же проблемы и те же заморочки.
Sign up to leave a comment.
Считаете ли вы веб-программирование каким-то обособленным видом программирования?