Первая статья была такой многообещающей — видимо потому, что в ней с умным говорилось про очевидные в общем-то недостатки современного веб-стека…
А вот выводы, к которым пришли — какой-то разочарование.
Очевидно, что у автора катастрофически не хватает кругозора, понимания работы определённых вещей, зато нездоровая любовь к каким-то определённым реализациям каких-то конкретных решений, да ещё и в java мире.
Конечно же, от такой статьи ждёшь каких-то глобальных идей, не привязанных к реализации и языку. И выводом из этой статьи должен был стать тезис о неизбежности приближения ОС к браузеру, браузера к ОС и их сингулярного слияния в одну сущность в недалёком будущем.
На смотря на провал ChromeOS и отсутствия кардинального развития desktop os начиная с появления оконных интерфейсов, этот процесс идёт, будет идти и неизбежно нас к чему нибудь приведёт.
Возможно, Javascript в таком мире не найдёт себе место, но скорее он видоизменится так, что от него останется лишь название. Ибо уже сегодня видны тенденции к ухода от языка "разработки" к языку "assembly", который возможно в дальнейшем можно будет прозрачно для пользователей и безопасно очистить от всего накопившегося говнеца.
Но, уж извините, хаять SQL, заменяя его на какого-то потомка KV и Protobuf, говорить что серверы должны возвращать через RPC фьючерсы (насколько я понимаю, фьючерсов нету нигде кроме Java мира), строгая привязка этого NewWeb к ООП (не из-за java, а исходя из выводов статьи, потому что "новая ORM" и тыды), какие-то там IDE…
И ни слова о том, что действительно важно, то что превалирует в комментариях к предыдущей статье: замене HTML как языка гипертекста на другой markup lang, сэндбоксинг, сохранение многообразия технологи, а лучше и его увеличение....
Если Гугл в AndroidSDK в класс android.widget.Button влепит колбэк на отправку нажатия на кнопочку в Гугл — большинство андроид приложений будет всю свою статистику слать прямиком туда. Потому что никто свои виджеты не делат (разве что в играх на Unity каких нибудь).
А если будет слать через сокет а не через http-запрос — то раз в стопицот быстрее чем Google Analytics.
Так что не вижу принципиальной разницы.
Насчёт установки — я лично считаю что понятие операционная система в современных реалиях должна быть пересмотрена.
Например такие вещи как расширения файлов и древовидная файловая система кажутся очевидными, но это не так :)
Я бы не назвал Java платформой. Хотя, я конечно имею посредственное представление обо всех её возможностях, но это скорее ВМ в моём видении. Браузер унифицирует большее количество вещей, чем ВМ.
Вот Android SDK уже можно назвать такой платформой. Потому что унифицируется доступ к ресурсам ОС, файловой системе, взаимодействию между приложениям, забавушкам.
Вот только она не унифицирована :)
Если слить вместе Android, iOS и .NET стек (а не кросскомпилировать как в Xamarin), унифицировать его, плюс убрать слой абстракции между ОС и ВМ, которая несёт эти приложения — т.е. так, как сделано в мобилках и так как не сделано в десктопах — HTML+JS утонет в Лете.
Flash по сути не решает проблему из-за проприетарности и ограничений. Помоему флеш не умеет UDP, не умеет работать с файлами и тыды
Клиенты хотят запускать всё не из браузера, а из унифицированной платформы, которая на сегодняшний день имеет только одну реализацию — браузер.
Если бы существовала другая реализация унифицированной платформы, причём более быстрая (то есть использовала Sockets, Assembly и GL без приставки Web), то про браузер бы никто не вспоминал.
Об этой другой, воображаемой и желаемой реализации и ведёт речь автор этой статьи.
Зачем Использовать WebAssembly, WebSocket и WebGL, есл можно использовать Assembly, Socket и GL, чуть-чуть поменяв популяпные ОСи и добавив полслоя абстракции?
Я прошу прощения за вопрос, я совершенно ничего не знаю о graphql, но по беглому описанию возникает вопрос — зачем тогда вообще бэкэнд? В чём смысл проксировать SQL к SQL базе данных? Не легче ли уже тогда в принципе чуть модифицировать RDBS решения, и бэкэнд разработчики в принципе умрут как вид?
Или тут дело в том, что бэкэнд это не только КРУД?
На сегодняшний день blockchain db — это больше технология чем валюта. Денежки выступают как единица измерения криптографической сложности в таких системах, и несут далеко не первостепенное значение.
Так то ООП заносит ещё больше головной боли, как по мне.
Осталось только понять, как на нём писать. Я слишком молод, знаю только два подхода — либо ФП либо ООП. И ни один в Расте нормально почему-то не работает.
Ну программу я же как-то написал. Все "нефункциональные вещи" — это заменил рекурсию на луп изза отсутствия ТСО, да ещё в массив писал через переменную.
Какая в общем то разница, как оно там внутри работает?
Вся фишка и программы и этой статьи — "пишем максимально по феншую, авось заработает. Надеемся что ниразу не придётся ни мутить переменную, ни писать лайфтаймы, на имплементить трейты"
Но в функции же есть возврат — если аргумент равно нулю!
Другое дело, что до этого места никогда не доходит, но откуда об этом может знать компилятор?
Посмотрите пример с рандомом из соседней ветки — там даже есть реальный выход из функции, другое дело что переполнение стека по идее наступит раньше.
Я не эксперт, но на самом деле я понимаю TCO вот так: Видим, что функция возвращает вызов функции — не добавляем переход на эту функцию в стек вызовов.
И в этом случае что бы там не падало, или падало, или не важно — переполнения стека быть не может. Что угодно — но не это.
Возможно, я конечно ошибаюсь.
Первая статья была такой многообещающей — видимо потому, что в ней с умным говорилось про очевидные в общем-то недостатки современного веб-стека…
А вот выводы, к которым пришли — какой-то разочарование.
Очевидно, что у автора катастрофически не хватает кругозора, понимания работы определённых вещей, зато нездоровая любовь к каким-то определённым реализациям каких-то конкретных решений, да ещё и в java мире.
Конечно же, от такой статьи ждёшь каких-то глобальных идей, не привязанных к реализации и языку. И выводом из этой статьи должен был стать тезис о неизбежности приближения ОС к браузеру, браузера к ОС и их сингулярного слияния в одну сущность в недалёком будущем.
На смотря на провал ChromeOS и отсутствия кардинального развития desktop os начиная с появления оконных интерфейсов, этот процесс идёт, будет идти и неизбежно нас к чему нибудь приведёт.
Возможно, Javascript в таком мире не найдёт себе место, но скорее он видоизменится так, что от него останется лишь название. Ибо уже сегодня видны тенденции к ухода от языка "разработки" к языку "assembly", который возможно в дальнейшем можно будет прозрачно для пользователей и безопасно очистить от всего накопившегося говнеца.
Но, уж извините, хаять SQL, заменяя его на какого-то потомка KV и Protobuf, говорить что серверы должны возвращать через RPC фьючерсы (насколько я понимаю, фьючерсов нету нигде кроме Java мира), строгая привязка этого NewWeb к ООП (не из-за java, а исходя из выводов статьи, потому что "новая ORM" и тыды), какие-то там IDE…
И ни слова о том, что действительно важно, то что превалирует в комментариях к предыдущей статье: замене HTML как языка гипертекста на другой markup lang, сэндбоксинг, сохранение многообразия технологи, а лучше и его увеличение....
Эх, статья-статья. Грустно...
Если Гугл в AndroidSDK в класс
android.widget.Buttonвлепит колбэк на отправку нажатия на кнопочку в Гугл — большинство андроид приложений будет всю свою статистику слать прямиком туда. Потому что никто свои виджеты не делат (разве что в играх на Unity каких нибудь).А если будет слать через сокет а не через http-запрос — то раз в стопицот быстрее чем Google Analytics.
Так что не вижу принципиальной разницы.
Насчёт установки — я лично считаю что понятие операционная система в современных реалиях должна быть пересмотрена.
Например такие вещи как расширения файлов и древовидная файловая система кажутся очевидными, но это не так :)
Я бы не назвал Java платформой. Хотя, я конечно имею посредственное представление обо всех её возможностях, но это скорее ВМ в моём видении. Браузер унифицирует большее количество вещей, чем ВМ.
Вот Android SDK уже можно назвать такой платформой. Потому что унифицируется доступ к ресурсам ОС, файловой системе, взаимодействию между приложениям, забавушкам.
Вот только она не унифицирована :)
Если слить вместе Android, iOS и .NET стек (а не кросскомпилировать как в Xamarin), унифицировать его, плюс убрать слой абстракции между ОС и ВМ, которая несёт эти приложения — т.е. так, как сделано в мобилках и так как не сделано в десктопах — HTML+JS утонет в Лете.
Flash по сути не решает проблему из-за проприетарности и ограничений. Помоему флеш не умеет UDP, не умеет работать с файлами и тыды
Клиенты хотят запускать всё не из браузера, а из унифицированной платформы, которая на сегодняшний день имеет только одну реализацию — браузер.
Если бы существовала другая реализация унифицированной платформы, причём более быстрая (то есть использовала Sockets, Assembly и GL без приставки Web), то про браузер бы никто не вспоминал.
Об этой другой, воображаемой и желаемой реализации и ведёт речь автор этой статьи.
Зачем Использовать WebAssembly, WebSocket и WebGL, есл можно использовать Assembly, Socket и GL, чуть-чуть поменяв популяпные ОСи и добавив полслоя абстракции?
Сборка для IPhone только при подключению к макбуку
Я не пишу на Java, но
TelegramUpdateHandlerBeanPostProcessorэто шутка такая?Это набирать вообще реально? Или в Java это так и надо делать...
Я так и не понял, что тут динамического.
Я могу точно так же свой аватар менять, слушая всякие коллбэки
Я прошу прощения за вопрос, я совершенно ничего не знаю о graphql, но по беглому описанию возникает вопрос — зачем тогда вообще бэкэнд? В чём смысл проксировать SQL к SQL базе данных? Не легче ли уже тогда в принципе чуть модифицировать RDBS решения, и бэкэнд разработчики в принципе умрут как вид?
Или тут дело в том, что бэкэнд это не только КРУД?
Как то неожиданное оказалось… Фактически статья — реклама коммерческого продукта
На сегодняшний день blockchain db — это больше технология чем валюта. Денежки выступают как единица измерения криптографической сложности в таких системах, и несут далеко не первостепенное значение.
Походу гит в линухе на мержах и ребазах выкидывает по дефолту в вим.
Так что вам ещё предстоит им попользоваться)
F#, Erlang/Elixir, Elm — из тех на чём писал. Вроде все работает пока что.
Так то ООП заносит ещё больше головной боли, как по мне.
Осталось только понять, как на нём писать. Я слишком молод, знаю только два подхода — либо ФП либо ООП. И ни один в Расте нормально почему-то не работает.
Ну программу я же как-то написал. Все "нефункциональные вещи" — это заменил рекурсию на луп изза отсутствия ТСО, да ещё в массив писал через переменную.
Какая в общем то разница, как оно там внутри работает?
Вся фишка и программы и этой статьи — "пишем максимально по феншую, авось заработает. Надеемся что ниразу не придётся ни мутить переменную, ни писать лайфтаймы, на имплементить трейты"
Я не понял, при чём тут сборка мусора.
Но в любом случае задача была "сделать максимально по функциональному феншую"
Это не "пофункциональному". В некоторых языках if вообще нету
Так в результате, это уже работает, или ещё нет? А то баг висит, РФЦ висит, но никто ничего не мержит и не принимает… Хотя было бы круто
Но в функции же есть возврат — если аргумент равно нулю!
Другое дело, что до этого места никогда не доходит, но откуда об этом может знать компилятор?
Посмотрите пример с рандомом из соседней ветки — там даже есть реальный выход из функции, другое дело что переполнение стека по идее наступит раньше.
Я не эксперт, но на самом деле я понимаю TCO вот так:
Видим, что функция возвращает вызов функции — не добавляем переход на эту функцию в стек вызовов.
И в этом случае что бы там не падало, или падало, или не важно — переполнения стека быть не может. Что угодно — но не это.
Возможно, я конечно ошибаюсь.