Comments 61
Это не направления, а всего-лишь инструменты. Облако ничем не отличается по сути от обычных методов хранения данных.
Параллельные вычисления используются далеко не везде и не везде нужны, да, тот же photoshop нужно прокачивать этим, но Word зачем?
Мобильные устройства, уже ближе, сюда же можно добавить планшеты
Параллельные вычисления используются далеко не везде и не везде нужны, да, тот же photoshop нужно прокачивать этим, но Word зачем?
Мобильные устройства, уже ближе, сюда же можно добавить планшеты
Там есть о планшетах.
Word, как приложение, которое при каждом нажатии кнопки юзером, вынужденное рендерить огромные куски документа — просто таки нуждается в многопоточности! Вот Notepad, наверное, останется однопоточным и через 10 лет :)
«Облако ничем не отличается по сути от обычных методов хранения данных.»
Вопрос не в методах хранения данных, а в методах потребления. И тут облако сильно отличается т.к. представляет собой сильно-централизованную модель.
Вопрос не в методах хранения данных, а в методах потребления. И тут облако сильно отличается т.к. представляет собой сильно-централизованную модель.
Насчет Word — не согласен ) Открываешь файлик страниц этак на 200, и все подвисает… Конечно, рост производительности это рано или поздно лечит, но не отменяет возможности параллелизации. Если удастся распараллелить хотя бы половину задач — втанет работать в полтора раза быстрее, и это будет очень и очень неплохо ) не так ли?
Параллельные вычисления не обязательно должны использоваться для повышения производительности какой-то отдельной операции. Их же используют еще и для асинхронного выполнения разных операций. Например, проверка правописания в ворде выполняется в отдельном потоке.
Представим облачный Microsoft Word
что из ниже перечисленного с ним ассоциируется
soap, json, rest, ASP.NET, JSP, Flex, Silverlight, Javascript, JQuery?
Облачный сервис это, прежде всего, мощный [распределенный, масштабируемый] back-end
А все перечисленные вами технологии — это просто UI/Front-end
что из ниже перечисленного с ним ассоциируется
soap, json, rest, ASP.NET, JSP, Flex, Silverlight, Javascript, JQuery?
Облачный сервис это, прежде всего, мощный [распределенный, масштабируемый] back-end
А все перечисленные вами технологии — это просто UI/Front-end
Попробую кинуть камень в огород параллельного программирования.
Параллельное программирование дает очень маленький выигрыш.
Это как переписывание кусков кода на ассемблере и оправдано только в редких критичных случаях.
На своем компьютере (4 ядра) я могу по пальцам пересчитать моменты, когда программа загружает свое ядро по максимуму: кодирование видео, архивирование, игры.
Много ли из Вас пишет свои кодеки, архиваторы, игровые движки?
Если вам предложат на выбор 2-е версии FireFox:
1 на 15% быстрее
2 с новым удобным, качественным интерфейсом
Но вы можете установить только одну, какую Вы поставите?
Параллельное программирование дает очень маленький выигрыш.
Это как переписывание кусков кода на ассемблере и оправдано только в редких критичных случаях.
На своем компьютере (4 ядра) я могу по пальцам пересчитать моменты, когда программа загружает свое ядро по максимуму: кодирование видео, архивирование, игры.
Много ли из Вас пишет свои кодеки, архиваторы, игровые движки?
Если вам предложат на выбор 2-е версии FireFox:
1 на 15% быстрее
2 с новым удобным, качественным интерфейсом
Но вы можете установить только одну, какую Вы поставите?
Да, я бы тоже выбрал Fx 4 (:
> На своем компьютере (4 ядра) я могу по пальцам пересчитать моменты, когда программа загружает свое ядро по максимуму: кодирование видео, архивирование, игры.
У Вас дома, я так понимаю, сервер решающий _сложные_ задачи и обрабатывающий многих клиентов?
> Много ли из Вас пишет свои кодеки, архиваторы, игровые движки?
Направлений к которых нужна многозадачность тьма, если честно, то в той или иной мере, это не нужно разве, что в однопроходных скриптах. Да и то, при активном их запуске о многозадачности надо думать (читай сайты).
<ирония>
> Если вам предложат на выбор 2-е версии FireFox:
естественно 1, т.к. второй пункт покрывается вимператором
</ирония>
У Вас дома, я так понимаю, сервер решающий _сложные_ задачи и обрабатывающий многих клиентов?
> Много ли из Вас пишет свои кодеки, архиваторы, игровые движки?
Направлений к которых нужна многозадачность тьма, если честно, то в той или иной мере, это не нужно разве, что в однопроходных скриптах. Да и то, при активном их запуске о многозадачности надо думать (читай сайты).
<ирония>
> Если вам предложат на выбор 2-е версии FireFox:
естественно 1, т.к. второй пункт покрывается вимператором
</ирония>
Думается мне, что не будет по 64 ядра на настольных системах.
Десктопное приложение, успешно использующее десятки ядер, ассоциируется у меня с книгой «Мифический человеко-месяц». Когда увеличение команды в 10 раз, совсем не означает увеличение в 10 раз производительности. Как раз наоборот.
Скорее ресурсоемкие вычисления будут вынесены в облака.
С графическими процессорами уже пробуют это сделать
(см. проект ru.wikipedia.org/wiki/OnLive)
Десктопное приложение, успешно использующее десятки ядер, ассоциируется у меня с книгой «Мифический человеко-месяц». Когда увеличение команды в 10 раз, совсем не означает увеличение в 10 раз производительности. Как раз наоборот.
Скорее ресурсоемкие вычисления будут вынесены в облака.
С графическими процессорами уже пробуют это сделать
(см. проект ru.wikipedia.org/wiki/OnLive)
Не уверен, что такие сервисы, как onLive потянут хотя бы сотен миллионов юзеров, играющих одновременно в Кризис, даже если они все сервера Гугла выкупят.
Узкое место как раз не мощность серверов, а ширина канала и пинг.
Вы свою графическую карту используйте на всю мощность часов 5 в день от силы. Т.е. 80% времени она простаивает.
Зачем покупать графическую карту за $300, если ее можно взять в аренду?
Вы свою графическую карту используйте на всю мощность часов 5 в день от силы. Т.е. 80% времени она простаивает.
Зачем покупать графическую карту за $300, если ее можно взять в аренду?
Многие задачки практически не распараллелить, то есть всякие офисные печатные машинки думаю дальше в эволюции уже не пойдут, только в сторону минитюаризации. Вот рендер в играх да, отлично параллелится, тут еще есть куда двигаться.
облачность и параллелизм — одно и то же, а чем «мобильное программирование» отличается от иного поимо платформы, я не представляю, более того, через те же самые пару лет мобильные устройства станут ближе к настольным пк по мощности, грани сотрутся
так что статья не про 3 пункта, а про 1
так что статья не про 3 пункта, а про 1
Параллелизм — это когда одна программа выполняется на нескольких ядрах. Облачность же — это технология прозрачной масштабируемости для сервисов с высокой нагрузкой.
Именно связка облачность + мобильные платформы, ИМХО, самая перспективная на сегодняшний день.
Мобильным платформам не хватает мощи — вынесем все вычисления на сервер.
Облачный сервер создан, чтобы обслуживать сотни тысяч клиентов — идеальный вариант для мобильных устройств.
Именно связка облачность + мобильные платформы, ИМХО, самая перспективная на сегодняшний день.
Мобильным платформам не хватает мощи — вынесем все вычисления на сервер.
Облачный сервер создан, чтобы обслуживать сотни тысяч клиентов — идеальный вариант для мобильных устройств.
С качеством и стоимостью мобильной связи что-то большое переносить на сервера? Ну ну…
А зачем туда переносить маленькое? Как раз большое и нужно. Другое дело, что для программы, генерирующей много трафика, ширина канала будет узким местом.
Опять же есть абсолютная мобильность. А есть мобильность поменьше: как лептоп или планшет. Есть Wi-Fi, Wi-Max — уйма вариантов, когда оно себя оправдывает.
Опять же есть абсолютная мобильность. А есть мобильность поменьше: как лептоп или планшет. Есть Wi-Fi, Wi-Max — уйма вариантов, когда оно себя оправдывает.
>программы выполняются на различных платформах или пишутся на новых языках программирования.
Вторая часть высказывания сильно смахивает на маркетоидный бред.
С развитием разработки ПО идут поиски «золотой пули», которая перевернет мир программирования. Тот же Брукс еще в 80х годах предсказывал, что до нового тысячелетия не будет найдено технологии, которая хотя бы в 2 раза ускорит темпы разработки. И оказался прав.
Что будут новые фреймворки, более удобные (и ресурсоемкие из-за универсальности) — бесспорно — но «новые языки программирования» — уже изъезженная песня с целью воздействия на неокрепшие умы.
Хотя м.б. я уже стар и излишне консервативен…
Вторая часть высказывания сильно смахивает на маркетоидный бред.
С развитием разработки ПО идут поиски «золотой пули», которая перевернет мир программирования. Тот же Брукс еще в 80х годах предсказывал, что до нового тысячелетия не будет найдено технологии, которая хотя бы в 2 раза ускорит темпы разработки. И оказался прав.
Что будут новые фреймворки, более удобные (и ресурсоемкие из-за универсальности) — бесспорно — но «новые языки программирования» — уже изъезженная песня с целью воздействия на неокрепшие умы.
Хотя м.б. я уже стар и излишне консервативен…
ищут серебряную пулю, золотая бесполезная из-за свойст данного метала, разве что для глориков.
Брукс был не прав, технологий ускоряющих разработку было придумана куча и в разных областях: delphi и компонентный подход, java с виртуальной машиной и кросплатформенностью, agile разработка… новых языков появилось так же достаточно, но становление занимает не один год.
Брукс был не прав, технологий ускоряющих разработку было придумана куча и в разных областях: delphi и компонентный подход, java с виртуальной машиной и кросплатформенностью, agile разработка… новых языков появилось так же достаточно, но становление занимает не один год.
блин, писАл-писАл — хром все съел. придется вновь.
пуля — конечно же — серебряная, благодарю. очепятался.
Брукс был прав и немного не свершились его прогнозы. В любом случае у него получилась отличная дискуссионная и доказанная статья — в отличие от автора оригинального пассажа.
Имхо, если рассматривать идеализированный вариант — то Брукс прав. Ни компонентный подход, ни верхнеуровневые языки — не являются универсальным средством и могут как помочь, так и помешать проекту.
Тоже самое — методологии разработки, их как и языков — стало больше, но как и 87 году, когда была написана статья — успех проекта зависит от исполнителя, ни одна методология не стала универсальной и никакая серьезно не увеличила шансы на успех.
В любом случае — Брукса читать полезно, хоть и нудновато, а автора оригинала — нет.
пуля — конечно же — серебряная, благодарю. очепятался.
Брукс был прав и немного не свершились его прогнозы. В любом случае у него получилась отличная дискуссионная и доказанная статья — в отличие от автора оригинального пассажа.
Имхо, если рассматривать идеализированный вариант — то Брукс прав. Ни компонентный подход, ни верхнеуровневые языки — не являются универсальным средством и могут как помочь, так и помешать проекту.
Тоже самое — методологии разработки, их как и языков — стало больше, но как и 87 году, когда была написана статья — успех проекта зависит от исполнителя, ни одна методология не стала универсальной и никакая серьезно не увеличила шансы на успех.
В любом случае — Брукса читать полезно, хоть и нудновато, а автора оригинала — нет.
любой, кто пытается делать прогнозы — уже ошибся.
я пишу на php, мой первый сайт был написан. когда я был знаком с языком максимум 3 месяца, с ООП 3 недели. но он до сих пор успешно работает. до этого я использовал delphi, который позволял мне быстро и без особых знаний достигнуть результатов о которых бруксу и не снилось, просто у меня инструменты на несколько порядков лучше.
поэтому не нужно сравнивать брукса и опусы автора из хабра, который уже давно не торт.
я пишу на php, мой первый сайт был написан. когда я был знаком с языком максимум 3 месяца, с ООП 3 недели. но он до сих пор успешно работает. до этого я использовал delphi, который позволял мне быстро и без особых знаний достигнуть результатов о которых бруксу и не снилось, просто у меня инструменты на несколько порядков лучше.
поэтому не нужно сравнивать брукса и опусы автора из хабра, который уже давно не торт.
Как-то аргументация Брукса и его примеры результативности проектов на десятки человеко-лет и: «я пишу на php, мой первый сайт» — плохо сочетаются в соседних комментах.
> до этого я использовал delphi, который позволял мне быстро и без особых знаний достигнуть результатов о которых бруксу и не снилось
Я уж не знаю, о каких результатах вы говорите, но «результат», достигаемый без «особых знаний» только насмешил бы руководителя разработки операционной системы (os/360) в IBM и лауреата премии Тюринга.
> до этого я использовал delphi, который позволял мне быстро и без особых знаний достигнуть результатов о которых бруксу и не снилось
Я уж не знаю, о каких результатах вы говорите, но «результат», достигаемый без «особых знаний» только насмешил бы руководителя разработки операционной системы (os/360) в IBM и лауреата премии Тюринга.
как-то факты лихих 90-х доказывают, что даже в аргументации великих людей бывают ошибки. вы верите аргументам о будущем или фактам о прошлом?
и, судя по самой известной его книге — брукс был бы ряд, что ошибался, и что домохозяйки смогли за пару часов делать то, на что раньше программистам нужны были месяцы. ведь это ПРОГРЕСС и если он опережает предположения — это восхитительно, а не смешно.
и, судя по самой известной его книге — брукс был бы ряд, что ошибался, и что домохозяйки смогли за пару часов делать то, на что раньше программистам нужны были месяцы. ведь это ПРОГРЕСС и если он опережает предположения — это восхитительно, а не смешно.
Сейчас корректнее говорить не о языке, а о платформе.
Именно набор фреймверков + язык — та платформа, на которой базируются успехи программирования в наше время.
Именно набор фреймверков + язык — та платформа, на которой базируются успехи программирования в наше время.
я бы все-таки про «успехи программирования» говорил бы с позиций команды разработки — грамотная команда получит результат и на «менее оптимальной» платформе (хотя какие критерии оптимальности будут в таком случае?).
А менее опытный и ответственный коллектив может завалить проект с «более продвинутой» платформой (Брукс прав?).
А менее опытный и ответственный коллектив может завалить проект с «более продвинутой» платформой (Брукс прав?).
>>А менее опытный и ответственный коллектив может завалить проект с «более продвинутой» платформой
хе. Возмём сферическую команду в вакууме средней криворукости и поставим перед ней одну и туже задачу 20 лет назад и сейчас. Как думаеш одинакова лив этих двух случаях вероятность, что команда завалит проэкт?
ИМХО очевидно, что в наше время вероятность гораздо меньше.
хе. Возмём сферическую команду в вакууме средней криворукости и поставим перед ней одну и туже задачу 20 лет назад и сейчас. Как думаеш одинакова лив этих двух случаях вероятность, что команда завалит проэкт?
ИМХО очевидно, что в наше время вероятность гораздо меньше.
>Тот же Брукс еще в 80х годах предсказывал, что до нового тысячелетия не будет найдено технологии, которая хотя бы в 2 раза ускорит темпы разработки. И оказался прав.
Серьезно?
Попробуйте написать серьезное web-приложение на C++/Win32 API и на .NET или Java — сильно удивитесь, два раза там и близко не стоят.
Серьезно?
Попробуйте написать серьезное web-приложение на C++/Win32 API и на .NET или Java — сильно удивитесь, два раза там и близко не стоят.
Все-таки он был прав… Брукс говорил про новое тысячелетие, и уложился в срок. .Net появился в 2002 году, Java чуть раньше, но не сильно. Как по предсказанию все началось именно с нового тысячилетия.
Если говорить про скорость разработки, то IDE влияет по моему мнению, чуть ли не самую главную роль, после мозгов конечно. И уже сейчас можно говорить о том, что код пишется со скоростью мысли, и от умственного процесса не отвлекает набор на клавиатуре странных буков и цифр. :-)
Если говорить про скорость разработки, то IDE влияет по моему мнению, чуть ли не самую главную роль, после мозгов конечно. И уже сейчас можно говорить о том, что код пишется со скоростью мысли, и от умственного процесса не отвлекает набор на клавиатуре странных буков и цифр. :-)
Современные скриптовые языки вроде Ruby или Python позволяют очень быстро прототипировать приложения, правда сложно сказать к какому именно тысячелетию их отнести.
На C++ это вполне реально, просто фреймворков маловато, будет нужный фреймворк так и вообще можно будет даже на С++ строгать веб аппликухи, а вот если именно на C++/Win32 API, то проще убиться.
Ну это не совсем правильный пример. Web-приложение — это специализированная задача, для которой нужен специализированный инструментарий. С тем же успехом можно сравнить отображение на экране JPG-рисунка с помощью Паскаля и Delphi. В первом случае надо писать свой анализатор JPEG (наверно, месяц работы), а во втором — шлёпнуть на форму элемент TPicture.
Брукс говорил, скорее, о чисто алгоритмических вещах. Скажем, запрограммировать алгоритм Дейкстры или какое-нибудь решение системы линейных уравнений почти одинаково сложно/просто.
Брукс говорил, скорее, о чисто алгоритмических вещах. Скажем, запрограммировать алгоритм Дейкстры или какое-нибудь решение системы линейных уравнений почти одинаково сложно/просто.
> изучать web-сервисы (soap, json, rest…)
У Вас перевод немного не корректный, надо добавить (основанных на soap, json...), т.к. перечисленное в скобках это стандарты, а не веб-сервисы.
У Вас перевод немного не корректный, надо добавить (основанных на soap, json...), т.к. перечисленное в скобках это стандарты, а не веб-сервисы.
будущее программирования в написании программы, способной ответить правильно на столь формальный вопрос:
«как мне без лишнего геморроя доехать до Перми?»
Вот это будущее, а мобильные приложения — это коддинг.
«как мне без лишнего геморроя доехать до Перми?»
Вот это будущее, а мобильные приложения — это коддинг.
Угу. Вот только, как уже написали, веб-приложения — это не облачные вычисления. А сами веб-приложения — это нифига не paradigm shift, им уже с десяток лет; осталось просто перенести их с внутренних серверов на внешние, вот и все.
А где игры?
Теоретически это различные виды mmo с толстыми и тонкими клиентами, игры для мобильных платформ с богатой графикой, по идее через год-другой должно быть новое поколение консолей и т.д.
Нового поколения консолей не будет ни через год, ни через два. PS3 ещё не до конца раскрыта, Wii обновление попросту не требуется, а Xbox360 хоть и упёрся в технический потолок, но вперёд других не полезет. В пользу того говорит и Kinect, и новый Xbox360 Slim. Что касается mmo и игр для мобильных платформ — это далеко не все игры. Лишь часть рынка, крупная, но не превалирующая. Однопользовательские игры и традиционный мультиплеер — вот что доминирует и будет доминировать. Продажи казуальных игр, римейков старых аркад, а также новые шутеры подтверждают это из года в год. Посмотрите на L4D2, Bad Company 2 и MW2. У той же BC2 игровая база почти 5 миллионов игроков (читай: 5 миллионов проданных коробок), достигнутая за 4 месяца + регулярные отчисления за аренду выделенных серверов. Сравните с World of Warcraft. Про успех MW2 и говорить нечего.
Полностью согласен, старые жанры и платформы с их продажами никуда не денутся, от спортивных игр и гонок до сюжетных шутеров и стратегий.
Но если говорить о свежих трендах, то это сервисы вроде onlive и адаптация игр под них, только зарождающаяся ниша realtime mmo браузерных игр.
Но если говорить о свежих трендах, то это сервисы вроде onlive и адаптация игр под них, только зарождающаяся ниша realtime mmo браузерных игр.
Onlive интересен только на первый взгляд. На деле же он будет работать только для однопользовательских игр: квестов, казуалок, пошаговых стратегий, может быть RTS, с трудом верится в FPS. Многопользовательские игры через Onlive изначально обречены, разве что сам Onlive будет предлагать серверную инфраструктуру внутри своей локальной сети. Иначе двойная задержка = смерть во всех MMO и FPS. Но для всяческих квестов, которые можно взять в аренду за доллар, это будет работать.
Realtime MMO в браузере выглядит привлекательно, с учётом WebSockets и WebGL, но до нормальной поддержки хотя бы в 2-3 браузерах надо ещё дожить :) И всё равно я не вижу особых преимуществ перед скачиваемым нативным клиентом, только мороки больше + медленный клиент: Javascript всё же гораздо медленнее C, даже с JIT. Вот если бы было что-то такое, чтобы пользователь сказал «охуенно» и сел играть именно в браузере, а не в LA2, невзирая на тормоза и прочие проблемы — тогда было бы круто. А пока такого нет. Опять же, нормальная графика потянет за собой весьма дохрена трафика.
В общем мутно всё в будущем игр :)
Realtime MMO в браузере выглядит привлекательно, с учётом WebSockets и WebGL, но до нормальной поддержки хотя бы в 2-3 браузерах надо ещё дожить :) И всё равно я не вижу особых преимуществ перед скачиваемым нативным клиентом, только мороки больше + медленный клиент: Javascript всё же гораздо медленнее C, даже с JIT. Вот если бы было что-то такое, чтобы пользователь сказал «охуенно» и сел играть именно в браузере, а не в LA2, невзирая на тормоза и прочие проблемы — тогда было бы круто. А пока такого нет. Опять же, нормальная графика потянет за собой весьма дохрена трафика.
В общем мутно всё в будущем игр :)
Я бы дописал в эту статью особый подвид параллельных вычислений средствами как обычных графических адаптеров, так и специализированного железа.
Там своя особенная кухня с построением приложений и распределением ресурсов.
В случае с цифровой обработкой сигналов, кодированием/декодированием, симулированием и прочими ресурсоемкими вычислительными задачами это очень серьезное новое направление.
Там своя особенная кухня с построением приложений и распределением ресурсов.
В случае с цифровой обработкой сигналов, кодированием/декодированием, симулированием и прочими ресурсоемкими вычислительными задачами это очень серьезное новое направление.
Если пришлют много хороших коментариев к статье, то думаю можно их опубликовать в виде отдельного поста.
Sign up to leave a comment.
Три основных направления разработки ПО в будущем