Здравствуйте, konstardiy, Вы писали:

A>>В статье нет аргументов.
K>В статье показан конкретный пример, к чему приводит чрезмерное увлечение Javascript/JQuery/Css, говносервисами и прочей жудью...

Чрезмерное увлечение чем угодно приводит к печальным последствиям. Дальше-то что? Где аргументы?

Здравствуйте, Mamut, Вы писали:

M>Второй вопрос:
M>Ткни в процитированном, где там речь про типизацию и, опять же, яваксрипт?
Типизация — есть мнение, что в сообщение об ошибке нааписсано, что на сервер было передано пустое сообщение. Скорее всего, пустой POST. Естественно попытка построить по нему xml-html для трансфлрмации закончилась наблюдаемым весельем.
А возможно это в первою очередь в результате использования языка где что null, что пустая строка, что ***, что....

Вот цитата из исходного сообщения:
What this shows is a broken arrivals computer system which has been completely over, and badly, engineered for the purpose of displaying information about the arrivals of buses to carry train passengers.

The designers/developers have chosen to build a browser based system with client-side Javascript pulling data asynchronously from a web service. Nothing wrong with that in principal, but for a non-interactive display-only, highly available message board system? I think not, as clearly demonstrated.

Дальше аффтар исходного сообщения перечесляет причины по его мнению приводящие к указанному фееризму, в частности:
Development and maintenance tool immaturity
На жабаскрипте не возможна в принципе tool maturity, имхо
Script-kiddie mentality and inexperience
говнокод в сочетании со скрипто-игрушечной метальностью, присущей всем скриптовым языкам (присвоил строковой переменной сумму числа и undefined — ляляля, не работает, давай ещё раз стопицот прогоним, если не заработает, пойдём играть в WoW...)
Вот здесь я разе что поспорю в некоторой степени —
Too much focus on web design at the expense of robustness and reliability
Менеджер и маркетолог мастурбируют на то что нарисовал дизайнер, это нармально — работа у него такая — эстетическое наслаждение дарить людям (шутка). А по серьёзному — да, дизайнера не должно интересовать, на чём именно пишется система, ему просто надо сразу сказать, что система позволяет это, это и это, а летающие стразики, гоняющиеся за курсором лучше убрать, ибо тормозит и отлекает юзера от юзабилиити.

Здравствуйте, Mamut, Вы писали:

M>Нет, он там не показан.

Цитата 1:
Whilst separating display logic from business logic is generally a good principle of software engineering, it is almost impossible to do using the current technologies favoured by the web software development industry today. Client-side code is being implemented in Javascript and is increasingly gaining more and more business logic because changing Javascript is easier that redesigning complex web services. This makes for very unreliable and unmaintainable software, and let us not forget that this business logic is available for all to see.

Цитата 2:
For almost thirty years, we have had highly graphical software development tools with more recently intellisense, edit-and-continue, source code analysis tools, memory checkers, garbage collectors etc.. We get almost none of this with Javascript, DOM and JQuery. Developing in these client-side web frameworks is like stepping back in time to a prehistoric age of software development.

Здравствуйте, konstardiy, Вы писали:

M>>Ткни в процитированном, где там речь про типизацию и, опять же, яваксрипт?
K>Типизация — есть мнение, что в сообщение об ошибке нааписсано, что на сервер было передано пустое сообщение. Скорее всего, пустой POST. Естественно попытка построить по нему xml-html для трансфлрмации закончилась наблюдаемым весельем.

А што, типизированный язык в этом случае сработает как-то по другому?

K>Дальше аффтар исходного сообщения перечесляет причины по его мнению приводящие к указанному фееризму, в частности:

Там, прости, основная причина — отсутствие банальной обработки исключений и прямой вывод системного сообщения об ошибке пользователю. Если бы там вместо этого было написано си-шарповское "Null pointer exception", или "Key not found exception", или там "Connection time out" — тебя бы это больше порадовало?

Здравствуйте, Hobot Bobot, Вы писали:

HB>А што, типизированный язык в этом случае сработает как-то по другому?

поскольку оно бы валилось ещё на клиенте, до отправки запроса, то больше шансов эта ошибка имела бы быть пойманой.

K>>Дальше аффтар исходного сообщения перечесляет причины по его мнению приводящие к указанному фееризму, в частности:

HB>Там, прости, основная причина — отсутствие банальной обработки исключений и прямой вывод системного сообщения об ошибке пользователю. Если бы там вместо этого было написано си-шарповское "Null pointer exception", или "Key not found exception", или там "Connection time out" — тебя бы это больше порадовало?

В Javascript частенько просто нет ошибок для компиялтора там где они есть. Ну передали в метод reqdata вместо reqData и зер с ним.
В нормальных языках эти виды насекомых отлавливается ещё на этапе компиляции. Если не на этапе AST (шутка).

Здравствуйте, konstardiy, Вы писали:

K>В Javascript частенько просто нет ошибок для компиялтора там где они есть. Ну передали в метод reqdata вместо reqData и зер с ним.
K>В нормальных языках эти виды насекомых отлавливается ещё на этапе компиляции. Если не на этапе AST (шутка).

Ага. Только в статье ни слова об этом, и картинка с расписанием автобусов не об этом, что мы тебе и пытаемся втолковать.

Здравствуйте, konstardiy, Вы писали:

K>Здравствуйте, Mamut, Вы писали:

M>>Нет, он там не показан.

K>Цитата 1:
K>Whilst separating display logic from business logic is generally a good principle of software engineering, it is almost impossible to do using the current technologies favoured by the web software development industry today. Client-side code is being implemented in Javascript and is increasingly gaining more and more business logic because changing Javascript is easier that redesigning complex web services. This makes for very unreliable and unmaintainable software, and let us not forget that this business logic is available for all to see.

Зжесь написана бредятина

K>Цитата 2:
K>For almost thirty years, we have had highly graphical software development tools with more recently intellisense, edit-and-continue, source code analysis tools, memory checkers, garbage collectors etc.. We get almost none of this with Javascript, DOM and JQuery. Developing in these client-side web frameworks is like stepping back in time to a prehistoric age of software development.

И здесь написана она же

M>>Второй вопрос:
M>>Ткни в процитированном, где там речь про типизацию и, опять же, яваксрипт?
K>Типизация — есть мнение, что в сообщение об ошибке нааписсано, что на сервер было передано пустое сообщение. Скорее всего, пустой POST. Естественно попытка построить по нему xml-html для трансфлрмации закончилась наблюдаемым весельем.
K>А возможно это в первою очередь в результате использования языка где что null, что пустая строка, что ***, что....

Ну да, зачем думать головой, в блоге — да еще по-английски! — все написано. Значит ошибаться он не может.

Дано: трехзвенная система:
— тонкий клиент (теоретически — брузер в kiosk mode).
— сервер, получающий данные со стороннего сервиса (тот самый transform.php).
— сторонний сервис (http://position.brighton-hove.gov.uk/datebroker), что видно из сообщения слева.

Сервер на php вылетел по банальной причине:
— сторонний сервис не отвечает (таймаут при коннекте, ошибка слева)
— сторонний сервис поднялся, но пока не завелся (ошибки получения данных с пустыми собщениями во всех остальных) и/или
— тупо ошибка в формировании отсылаемых на этот сервис данных (видно из стектрейсов)

Причина появления ошибкок?
— криворукий программист забыл поставить try catch с обработкой ошибок подсоединения
— криворукий программист не подумал, что данные могут приходить в нверном формате, и не поставил насчет этого никаких проверок

Вопросы:
1. Как проблему "забыть поставить try/catch" поможет исправить C#/C++/Java/Ruby/Python/Erlang/любой-другой-язык-на-выбор?
Ответ: Никак

2. Как проблему "забыть поставить валидацию данных" поможет исправить C#/C++/Java/Ruby/Python/Erlang/любой-другой-язык-на-выбор?
Ответ: Никак

3. Как эта ошибка относится непосредственно к выбранным языкам программирования?
Ответ: Никак

4. Как из этой ошибки можно сделать далеко идущие выводы об overengineering'е и прочей бредятине, отцитированной по всему топику?
Ответ (для нормальных людей): Никак
Ответ (для фанатиков, у которых пелена ненависти застилает все вокруг и не позволяет рационально думать): Легко, потому что проще слушать голоса в голове, они позволяют этой самой голове не думать.

K>Вот цитата из исходного сообщения:
K>What this shows is a broken arrivals computer system which has been completely over, and badly, engineered for the purpose of displaying information about the arrivals of buses to carry train passengers.

И эта цитата — бред


K>The designers/developers have chosen to build a browser based system with client-side Javascript pulling data asynchronously from a web service. Nothing wrong with that in principal, but for a non-interactive display-only, highly available message board system? I think not, as clearly demonstrated.

Тоже бред

K>Дальше аффтар исходного сообщения перечесляет причины по его мнению приводящие к указанному фееризму, в частности:

И дальше он выдает голословные утверждения (поскипанные), которые ни к описанной проблеме, ни к вебу к частности, не имеют никакого отношения.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, hardcase, Вы писали:

K>>>после прочтения этой новости чувствую себя бобладателем мощного аргумента за то

H>>Гы гы. А вот некоторые хотят вообще JS на сервере крутить

G>А некоторые, среди которых ebay, linked-in, и Yahoo, не только хотят, а крутят. И что?

Node.js is Cancer

Есть и такая версия )

Здравствуйте, 0xC0DE, Вы писали:

G>>А некоторые, среди которых ebay, linked-in, и Yahoo, не только хотят, а крутят. И что?

CDE>Node.js is Cancer

CDE>Есть и такая версия )

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

Node.js ставится за IIS или nginx. Ни к каким таким страшным непонятным проблемам, на наличие которых как бэ намекает автор статьи, это не приводит. И в сравнении с популярными сейчас скриптовыми веб-технологиями, вроде пыха или руби, node действительно быстрый, и это факт известный. Дополнительным удобством является использование одного языка на клиенте и сервере.

Учитывая это, на фоне существующих веб-технологий node смотрится вполне неплохо. Поэтому его и используют. Нет, это не говорит о том, что node хорош — меня лично от асинхронного стиля трясет. Это скорее характеризует состояние мэйнстрима в веб-разработке в целом. Убогий он.

Здравствуйте, Mamut, Вы писали:

M>1. Как проблему "забыть поставить try/catch" поможет исправить C#/C++/Java/Ruby/Python/Erlang/любой-другой-язык-на-выбор?
M>Ответ: Никак
Если обращение к сервису возвращает что-то типа

variant RequestResult[Value]
{
    | Result { value : Value }
    | Error  { ... }
}

То компилятор программу не скомпилирует, пока ошибку не обработаешь.

M>2. Как проблему "забыть поставить валидацию данных" поможет исправить C#/C++/Java/Ruby/Python/Erlang/любой-другой-язык-на-выбор?
M>Ответ: Никак
В нормальных языках данные описываются декларативно и сериализатор/десириализатор генерируются автоматически со всеми нужными валидациями.
Так что тут ну никак не забыть.

Пример я тебе уже раз 300 показывал.

M>3. Как эта ошибка относится непосредственно к выбранным языкам программирования?
M>Ответ: Никак
Наипрямейшим образом. Динамическая типизация сосет.
Кривая статика типа жабы и шарпа тоже.
Но с прямыми реализациями динамисты свои любимые языки сравнивать не хотят.
Ибо понимают, что шансов нет. Но признаться даже сами себе не могут.

M>4. Как из этой ошибки можно сделать далеко идущие выводы об overengineering'е и прочей бредятине, отцитированной по всему топику?
Если понять, как это можно на автомате исправить, эти выводы делаются автоматически.
Но фанам динамической типизации все пофиг.
У вас же прямые руки, железная дисциплина и вы все помните.
Причем даже в том метре кода, что писали не вы.
Ага, конечно.

Здравствуйте, konstardiy, Вы писали:

K>Я считаю, что Javascript (и PHP, но он немного лучше) не самыми удачными/лучшими веб-технологиями. Он слишком error-prone.

А мне кажется, сама задумка web с его HTML, CSS и DOM такова, что ее уже ничем не испортить

Все поскипано. Пришел Wolfhound и начал рассказывать сказки про нормальные языки

Здравствуйте, Mamut, Вы писали:

M>Все поскипано. Пришел Wolfhound и начал рассказывать сказки про нормальные языки
Как обычно отрицаешь факты.

M>>1. Как проблему "забыть поставить try/catch" поможет исправить C#/C++/Java/Ruby/Python/Erlang/любой-другой-язык-на-выбор?
M>>Ответ: Никак
WH>Если обращение к сервису возвращает что-то типа
WH>

WH>variant RequestResult[Value]
WH>{
WH>    | Result { value : Value }
WH>    | Error  { ... }
WH>}
WH>

WH>То компилятор программу не скомпилирует, пока ошибку не обработаешь.

Какой компилятор? Какого из языков, который существует в природе. Предлагаю на выбор: С/С++/Java/C#... Или имеется в виду некий компилятор несуществующих в природе (ну или хотя бы в коммерческой разработке) Nemerle/Ur?


M>>2. Как проблему "забыть поставить валидацию данных" поможет исправить C#/C++/Java/Ruby/Python/Erlang/любой-другой-язык-на-выбор?
M>>Ответ: Никак
WH>В нормальных языках данные описываются декларативно и сериализатор/десириализатор генерируются автоматически со всеми нужными валидациями.
WH>Так что тут ну никак не забыть.

WH>Пример я тебе уже раз 300 показывал.

Ну да, да. Ur. В стране эльфов, безусловно, этот пример имел бы смылс. Только, увы, страны эльфов не существует. Есть этот, как его, реальный мир, в котором ни Ur'а ни Nemerle не видно днем с огнем.

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


M>>3. Как эта ошибка относится непосредственно к выбранным языкам программирования?
M>>Ответ: Никак
WH>Наипрямейшим образом. Динамическая типизация сосет.
WH>Кривая статика типа жабы и шарпа тоже.
WH>Но с прямыми реализациями динамисты свои любимые языки сравнивать не хотят.
WH>Ибо понимают, что шансов нет. Но признаться даже сами себе не могут.

Ну да. Если я сейчас задам вопрос "дай пример языков с 'прямой реализацией'" все будет идти строго по описанному сценарию

Автор: Mamut
Дата: 13.05.11

. Сказочники такие сказочники.

M>>4. Как из этой ошибки можно сделать далеко идущие выводы об overengineering'е и прочей бредятине, отцитированной по всему топику?
WH>Если понять, как это можно на автомате исправить, эти выводы делаются автоматически.
WH>Но фанам динамической типизации все пофиг.

Фан(атик?) тут только один — ты. Ну и сказочник вдобавок. Тут обсуждается реальная жизнь, а ты постоянно лезешь с рассказами про страну эльфов. Да, Ur/Nemerle — это круто. Ктот-то спорит? Тлько круты они строго и сугубо в теории, которая никому, кроме фан(атик)ов не интересна.

WH>У вас же прямые руки, железная дисциплина и вы все помните.
WH>Причем даже в том метре кода, что писали не вы.
WH>Ага, конечно.

HB>Там, прости, основная причина — отсутствие банальной обработки исключений и прямой вывод системного сообщения об ошибке пользователю. Если бы там вместо этого было написано си-шарповское "Null pointer exception", или "Key not found exception", или там "Connection time out" — тебя бы это больше порадовало?

исключения в современных языках -- это дыра в статической типизации

Здравствуйте, Mystic, Вы писали:

M>А мне кажется, сама задумка web с его HTML, CSS и DOM такова, что ее уже ничем не испортить
Ну, вот это-то точно неверно. Т.к. вы говорите про три совершенно разные задумки, сделанные разными людьми и в разное время.

Здравствуйте, Mystic, Вы писали:

K>>Я считаю, что Javascript (и PHP, но он немного лучше) не самыми удачными/лучшими веб-технологиями. Он слишком error-prone.

M>А мне кажется, сама задумка web с его HTML, CSS и DOM такова, что ее уже ничем не испортить

А что вы имеете предложить взамен?

Здравствуйте, Mamut, Вы писали:

Развивать мысль не нужно.
Все что ты можешь это назвать работающий компилятор теорией.
Динамисты. Такие динамисты.

Здравствуйте, Lloyd, Вы писали:

L>А что вы имеете предложить взамен?

А предложить взамен можно много велосипедов. Как ещё более кривых, так и более прямых. Да-да, вокруг не одни криворукие идиоты. Наверняка найдётся гений, способный сделать аналог-конфетку. Но только всё равно ей пользоваться никто не будет, потому что есть для этого два препятствия. Первое — это долбанное консервативное сообщество т.н. "веб-программистов", которые завоют "а, ещё один велосипед, зачем нужен". Второе — это ещё более консервативное сообщество пользователей, у которых уже есть браузер, через который можно ходить в интернет (точнее, вконтактик). Думаю, что стоумовые парни, которые способны выкатить подобный велосипед, всё это понимают, потому и не выкатывают. Потому прямых (и непопулярных) альтернатив и нет. Некоторым хватает ума внедриться в стан врага и начать выпрямлять привычную связку.