Опа, пошли минусы ставить, ну вот за что в этом посте, а?
Объявление переменных без ключевых слов var/let/const
и так понятно. Мне например надоедает писать модификатор, потому что он может легко определяться автоматически.
Да импорты и приватность в питоне немного проседают нужен модификатор вроде private-set и импорт только модуля, да и много чего…
Зато настолько гибкий язык, что фактически в базу (ненадо никаких Flask) занесён функционал например шаблонов, json- подобного синтаксиса обьектов, легкой модифицируемости под свой домен-специфический язык. Суть в том что там это уже есть даже в базе языка и работает в обычных прогах, а чтоб это было в вебе, дуплицируя это придумали XHTML, XPATH, CSS, JS там node, react всякие и т.п. делая тупую работу и абсолютно нереюсабельный код.
не думаю что особо по сравнению с JS. К тому же это чисто фейл интерпретации и разных моментов питона. При нормальном интерпретаторе можно эквивалентом С сделать.
не знаю что такое TAL-0.
то на этом языке сразу что ли все писать будут?
скорее всего не начнут, там колоссальная инерция всякого уже написанного быдлокода. Никто ж не будет отменять node или react и т.п.
Коменты натолкнули на идею что интерпретатор языка может быть самостоятельным от браузера, и вы с удивлением увидите что коллосс веб дева не нужен. Например на машине стоит Питон, на нём же хоть и не обязательно написана тонкая оболочка браузера. Веб страница соответствует некой компонетне унаследованной например от TK если его взять для GUI. Текст веб страницы — это модель для GUI, просто исполняется функцией exec, и не нужны танцы с бубном для DI в код оболочки потому что в питоне всё DI. Можно и песочницу встроить.
Нет, они сделают 10 браузеров и 30 скрепящих огромными шестернями технологий с крутыми именами.
так я и о том, что рациональнее была бы консистентная технология. Ненадо один язык в другой компилить. Достаточен один язык с широкими интерпретационными возможностями. Предложил бы на базе Питона.
И ещё дикая идея. В очень хорошо структурированой технологии, не было бы разницы где запускать код в браузере или это как GUI.
потому что веб дев развивался несколько не следуя канонам софтваредизайна, как говорят истеорически, без реюзабельности и лиш бы работало, все равно что вырвиглаз и дуплицирование одних и тез же функций сто раз.
Мы намеренно хотим разделить эти вещи, потому что:
Код разработки хорош для разработчиков, но плох для пользователей
Код продакшна хорош для пользователей, но плох для разработчиков
если речь о генерации кода по модели, то упомянутое несколько некорректно так как код модели не
плох для пользователей
а предназначен для генерации кода, который не
плох для разработчиков
а не предназначен для чтения и редактирования человеком. А если подходить с умом то можно было бы давно удалить код продакшна из процесса (код модели -> код продакшна -> исполнение браузером) и использовать напрямую код модели-> исполнение браузером.
ну с учётом небольшой надбавки за доставку, и фактора что если количество меньше то стоит немного дороже, одна модель лопаты должна бы стоить почти одинакого. А кто продаёт с похмелья, пусть продаёт как хочет — на модель расчёта миллионов лопат мелкая хрень не влияет
Не нужен, контекст в постах товарища. Речь о том что физическое рассмотрение устройства на этапе анализа готового или раньше на этапе дизайна, с достаточно подробный учётом физ. характеристик может быть равно или лучше человеческому оцениванию. А доказать что что то нельзя делать очень легко.
и так понятно. Мне например надоедает писать модификатор, потому что он может легко определяться автоматически.
Да импорты и приватность в питоне немного проседают нужен модификатор вроде private-set и импорт только модуля, да и много чего…
Зато настолько гибкий язык, что фактически в базу (ненадо никаких Flask) занесён функционал например шаблонов, json- подобного синтаксиса обьектов, легкой модифицируемости под свой домен-специфический язык. Суть в том что там это уже есть даже в базе языка и работает в обычных прогах, а чтоб это было в вебе, дуплицируя это придумали XHTML, XPATH, CSS, JS там node, react всякие и т.п. делая тупую работу и абсолютно нереюсабельный код.
не думаю что особо по сравнению с JS. К тому же это чисто фейл интерпретации и разных моментов питона. При нормальном интерпретаторе можно эквивалентом С сделать.
не знаю что такое TAL-0.
скорее всего не начнут, там колоссальная инерция всякого уже написанного быдлокода. Никто ж не будет отменять node или react и т.п.
Коменты натолкнули на идею что интерпретатор языка может быть самостоятельным от браузера, и вы с удивлением увидите что коллосс веб дева не нужен. Например на машине стоит Питон, на нём же хоть и не обязательно написана тонкая оболочка браузера. Веб страница соответствует некой компонетне унаследованной например от TK если его взять для GUI. Текст веб страницы — это модель для GUI, просто исполняется функцией exec, и не нужны танцы с бубном для DI в код оболочки потому что в питоне всё DI. Можно и песочницу встроить.
Нет, они сделают 10 браузеров и 30 скрепящих огромными шестернями технологий с крутыми именами.
И ещё дикая идея. В очень хорошо структурированой технологии, не было бы разницы где запускать код в браузере или это как GUI.
потому что веб дев развивался несколько не следуя канонам софтваредизайна, как говорят ист
еорически, без реюзабельности и лиш бы работало, все равно что вырвиглаз и дуплицирование одних и тез же функций сто раз.если речь о генерации кода по модели, то упомянутое несколько некорректно так как код модели не а предназначен для генерации кода, который не а не предназначен для чтения и редактирования человеком. А если подходить с умом то можно было бы давно удалить код продакшна из процесса (код модели -> код продакшна -> исполнение браузером) и использовать напрямую код модели-> исполнение браузером.
чёрт, классный такой перс, жаль не вышло((