Comments 12
Не очень понял смысл предложения, а точнее, его второй части: Для того, чтобы пользоваться персональным компьютером, вы вынуждены изучить намного больше, чем вообще хотите знать что происходит внутри него.
Можно увидеть эту фразу в оригинале?
Можно увидеть эту фразу в оригинале?
0
Вряд ли оригинал фразы добавит что-то, что могло бы прояснить смысл. На самом деле, всё и так понятно. Нормальному пользователю совершенно не хочется знать, например, о том, что в компьютере есть оперативная память, а есть диск. Или о том, что любая информация на диске сохраняется в каких-то файлах. Гораздо естественней просто создавать в компьютере документы, не придумывая при этом никаких дополнительных названий для файлов, и не размышляя о том, в какой директории их сохранить. Ему хочется просто вводить текст в компьютер, а потом распечатать или отправить по почте. Или если пользователь нашёл/купил в сети музыку, то ему не хочется думать о том, что её нужно сначала скачать, затем найти место, куда она скачалась, после чего перелить на плеер. Ему хочется просто нажать кнопку «отправить на плеер» прямо там, где он нашёл музыку.
-1
Конечно, можно :)
The Other Road Ahead
When you own a desktop computer, you end up learning a lot more than you wanted to know about what's happening inside it.
The Other Road Ahead
0
>Java-апплеты рассматривались как технология, которую все будут использовать для разработки серверных приложений.
Апплеты всегда были, и рассматривались как технология разработки клиентских приложений. И только их. И кстати, в оригинале server-based, и это не тоже самое.
Апплеты всегда были, и рассматривались как технология разработки клиентских приложений. И только их. И кстати, в оригинале server-based, и это не тоже самое.
0
Расшифруйте, пожалуйста.
Потому что я помню как они появились, и как тогда на русский их переводили как «приложеньица», потому что были очень легковесными — читай использовались как лёгкий фронтенд для технологии «клиент-сервер».
Смысл в том, что они должны были применяться только как интерфейс к серверным приложениям (в отрыве от них не имеют смысла — не считая всяких анимированных часиков и прочих поделок).
Так что апплеты — технология для [клиент-]серверных приложений.
Это совсем не означает, что они работают именно на сервере, а означает, что они не предназначены для разработки standalone приложений.
Потому что я помню как они появились, и как тогда на русский их переводили как «приложеньица», потому что были очень легковесными — читай использовались как лёгкий фронтенд для технологии «клиент-сервер».
Смысл в том, что они должны были применяться только как интерфейс к серверным приложениям (в отрыве от них не имеют смысла — не считая всяких анимированных часиков и прочих поделок).
Так что апплеты — технология для [клиент-]серверных приложений.
Это совсем не означает, что они работают именно на сервере, а означает, что они не предназначены для разработки standalone приложений.
+1
Апплеты никогда не были легковесными сами по себе. Единственное, чем они отличаются от обычного приложения — это запуск в браузерной песочнице. С ограничениями в правах. И с загрузкой jar как правило с сервера — т.е. технология доставки клиенту обновлений кода такая же, как для клиентских javascript приложений.
Да, именно server-based или клиент-серверных (причем это не одно и тоже), а не серверных — и это тоже две большие разницы. Они работают только на клиенте. И совершенно не обязаны с сервером общаться.
standalone? Почему бы и нет? Не предназначены — но могут в таком виде вполне использоваться.
Вспомните, что речь примерно про 1995, и скажите себе честно — а что, где-то еще была нормальная интерактивная 2D графика? canvas не было, WebGL и SVG насколько я помню — тоже. И File API еще не появился. И web socket не было тоже. И webworker тоже не было — javascript программы только недавно стали многопоточными.
Поэтому апплеты были (да и сейчас еще в значительной степени остаются) единственным средством разработки во многих случаях: когда нужна графика, когда нужен доступ к файлам клиента, когда нужен доступ к clipboard, когда нужно например шифрование — потому что шифрование на javascript это нонсенс, особенно 20 лет назад. Почему клиент-банки во множестве на апплетах? Потому что шифрование и электронная подпись.
А теперь перечитайте фразу Грэма про апплеты, и вдумайтесь, чем он хвастает? Тем что клиент-серверных приложений у них не было, а были только серверные. Вот вы серьезно думаете, что это достижение? По-моему, это просто глупость.
Да, именно server-based или клиент-серверных (причем это не одно и тоже), а не серверных — и это тоже две большие разницы. Они работают только на клиенте. И совершенно не обязаны с сервером общаться.
standalone? Почему бы и нет? Не предназначены — но могут в таком виде вполне использоваться.
Вспомните, что речь примерно про 1995, и скажите себе честно — а что, где-то еще была нормальная интерактивная 2D графика? canvas не было, WebGL и SVG насколько я помню — тоже. И File API еще не появился. И web socket не было тоже. И webworker тоже не было — javascript программы только недавно стали многопоточными.
Поэтому апплеты были (да и сейчас еще в значительной степени остаются) единственным средством разработки во многих случаях: когда нужна графика, когда нужен доступ к файлам клиента, когда нужен доступ к clipboard, когда нужно например шифрование — потому что шифрование на javascript это нонсенс, особенно 20 лет назад. Почему клиент-банки во множестве на апплетах? Потому что шифрование и электронная подпись.
А теперь перечитайте фразу Грэма про апплеты, и вдумайтесь, чем он хвастает? Тем что клиент-серверных приложений у них не было, а были только серверные. Вот вы серьезно думаете, что это достижение? По-моему, это просто глупость.
0
Перечитал.
Server-based — это синоним «клиент-серверные с тонким клиентом».
Java-апплеты были придуманы для клиента потолще, но всё равно в клиент-серверной парадигме.
Иначе проще скачать приложение (любым способом и протоколом) и запустить как обычное Java-приложение.
Апплеты за очень редким исключением запускались из браузера и из его процесса, что было их недостатком в случае апплета с собственным окном — пользователи закрывали браузер после запуска апплета, и апплет закрывался вместе с ним.
В этой статье Грэм продвигает Server-based computing в противопоставление standalone приложениям. Из всех его доводов это прозрачно видно. Что касается апплетов в этом разрезе, то история с практической стороны показала какое место они получили в компьютерной индустрии.
Server-based — это синоним «клиент-серверные с тонким клиентом».
Java-апплеты были придуманы для клиента потолще, но всё равно в клиент-серверной парадигме.
Иначе проще скачать приложение (любым способом и протоколом) и запустить как обычное Java-приложение.
Апплеты за очень редким исключением запускались из браузера и из его процесса, что было их недостатком в случае апплета с собственным окном — пользователи закрывали браузер после запуска апплета, и апплет закрывался вместе с ним.
В этой статье Грэм продвигает Server-based computing в противопоставление standalone приложениям. Из всех его доводов это прозрачно видно. Что касается апплетов в этом разрезе, то история с практической стороны показала какое место они получили в компьютерной индустрии.
+1
История с практической стороны показала, что даже сейчас, в 2016, те вещи, которые я перечислил, вызывают большие проблемы при разработке в стандартной web-парадигме. А тогда реальных альтернатив не было вообще (если не считать flash).
>Грэм продвигает Server-based computing в противопоставление standalone приложениям
И при этом несет чушь о технологиях, которые знает плохо. Это его не извиняет ни разу. «Проще дойти до логического конца и запускать программы на сервере» — проще по сравнению с чем? Понимаете, если вы скажем гугль, и пишете поисковик — то вам и javascript-то не особо нужен. У вас серверное приложение by design.
А если вы банк, и вам скажем нужна на клиенте ЭЦП, то у вас и сегодня, 20 лет спустя, будет очень немного реальных альтернатив тем же апплетам.
>Грэм продвигает Server-based computing в противопоставление standalone приложениям
И при этом несет чушь о технологиях, которые знает плохо. Это его не извиняет ни разу. «Проще дойти до логического конца и запускать программы на сервере» — проще по сравнению с чем? Понимаете, если вы скажем гугль, и пишете поисковик — то вам и javascript-то не особо нужен. У вас серверное приложение by design.
А если вы банк, и вам скажем нужна на клиенте ЭЦП, то у вас и сегодня, 20 лет спустя, будет очень немного реальных альтернатив тем же апплетам.
+1
Разве Вы читали не внимательно?
Грэм как раз не делал ненужных обобщений — он явно указал, что есть приложения, которые не стоит делать server-based.
А чего Вы так за апплеты-то переживаете?
О них он вроде бы тоже ничего крамольного не сказал.
Грэм как раз не делал ненужных обобщений — он явно указал, что есть приложения, которые не стоит делать server-based.
А чего Вы так за апплеты-то переживаете?
О них он вроде бы тоже ничего крамольного не сказал.
0
А может это вы читали невнимательно? У меня как раз создается (субъективное, разумеется, но вполне устойчивое впечатление), что он сплошь и рядом делает ненужные обобщения. А пытаясь критиковать альтернативные решения, допускает явные ляпы. Вот, обратите внимание:
>С приложением на сервере вы можете делать доработки почти так же, как в программе, которую вы пишете для себя. Вы >выпускаете версии как последовательность поэтапных изменений вместо внезапного большого взрыва. Обычно компания, >производящая десктопное ПО, может выпустить одну или две версии за год. Для Viaweb мы часто делали три-пять версий в день.
Что, простите? При чем тут сервер vs desktop? Во-первых, на сегодня это давно устарело, потому что многие вполне настольные приложения легко обновляются с любой частотой. А во-вторых, возможность выпуска версий часто и понемногу — вовсе не особенность серверных приложений. Это особенность бизнеса компании. Опять же — если вы гугль или yahoo, и выпускаете десять версий своего поисковика или карт в день — это никого не волнует, в первую очередь потому, что вы никому ничего не обязаны. Вы как раз и пишете «как для себя». Только это не ваше достижение ни разу, и хвастаться тут нечем.
Ничего крамольного про апплеты? Да он написал так, как будто серверные и клиент-серверные приложения взаимозаменяемы, и мы можем выбрать что захотим. Что совсем не так. Это и есть еще одно ненужное и неправильное обобщение.
>С приложением на сервере вы можете делать доработки почти так же, как в программе, которую вы пишете для себя. Вы >выпускаете версии как последовательность поэтапных изменений вместо внезапного большого взрыва. Обычно компания, >производящая десктопное ПО, может выпустить одну или две версии за год. Для Viaweb мы часто делали три-пять версий в день.
Что, простите? При чем тут сервер vs desktop? Во-первых, на сегодня это давно устарело, потому что многие вполне настольные приложения легко обновляются с любой частотой. А во-вторых, возможность выпуска версий часто и понемногу — вовсе не особенность серверных приложений. Это особенность бизнеса компании. Опять же — если вы гугль или yahoo, и выпускаете десять версий своего поисковика или карт в день — это никого не волнует, в первую очередь потому, что вы никому ничего не обязаны. Вы как раз и пишете «как для себя». Только это не ваше достижение ни разу, и хвастаться тут нечем.
Ничего крамольного про апплеты? Да он написал так, как будто серверные и клиент-серверные приложения взаимозаменяемы, и мы можем выбрать что захотим. Что совсем не так. Это и есть еще одно ненужное и неправильное обобщение.
+1
Скажите, пожалуйста, что такое, в Вашем понимании, серверное приложение?
И чем оно отличается от клиент-серверного.
И чем оно отличается от клиент-серверного.
+1
А вам с какой целью нужна эта классификация? Что вас в моих формулировках смущает?
Я вполне явные примеры приводил — вот если вы пишете интернет банк, как вы собрались делать его чисто серверным? Без логики и кода на клиенте, без ЭЦП на клиенте, без доступа к файлам клиента?
Когда в качестве примера того, к чему нужно стремиться, приводится почта, мне становится смешно. Это текст 2001 года? Так прошло уже лет 15, а покажите мне сегодня, хотя бы две нормальные реализации веб почты, где есть нормальное вменяемое шифрование end-to-end?
>Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус
Да-да. Слыхали. Опять же, сегодня в 2016 году это выглядит смешно. На сегодня браузер является как раз одной из основных дыр в системе безопасности любой ОС. Потому что практика показала, что чисто серверные приложения, без логики на клиенте, без javascript, java или flash, почти никому не нужны. А когда все это появляется — браузер становится плохо защищенным.
Я вполне явные примеры приводил — вот если вы пишете интернет банк, как вы собрались делать его чисто серверным? Без логики и кода на клиенте, без ЭЦП на клиенте, без доступа к файлам клиента?
Когда в качестве примера того, к чему нужно стремиться, приводится почта, мне становится смешно. Это текст 2001 года? Так прошло уже лет 15, а покажите мне сегодня, хотя бы две нормальные реализации веб почты, где есть нормальное вменяемое шифрование end-to-end?
>Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус
Да-да. Слыхали. Опять же, сегодня в 2016 году это выглядит смешно. На сегодня браузер является как раз одной из основных дыр в системе безопасности любой ОС. Потому что практика показала, что чисто серверные приложения, без логики на клиенте, без javascript, java или flash, почти никому не нужны. А когда все это появляется — браузер становится плохо защищенным.
+2
Sign up to leave a comment.
Пол Грэм: «The Other Road Ahead», часть 1