UWP — это про windows 10 и windows 10 mobile. Пожалуйста, спуститесь на землю и оцените соотношение пользователей XP/7/8 и 10 прежде чем навязывать кому-то UWP.
Что касается WPF, предлагаю Вам сравнить насыщенные видимыми контролами приложения WPF и Win forms по потреблению ресурсов перед тем, как предлагать кому-то WPF
== и что происходит, когда добавляется новый язык? Он попадает в CustomLang?
смотря что проще — внести его в конфиг, либо рассматривать как «особый случай»
== смысл тогда первые три значения вводить?
для упрощения обработки «особых случаев», которые по мнению автора не нужны. В предметной области описания ЯП их немерено.
type Language with
// F# - наличие провайдеров типа
static member hasTypeProviders = function
| FSharp -> true
| _ -> false
// SQL, Clojure - наличие транзакций
static member hasTransactions = function
| TSQL | MySQL | Clojure -> true
| _ -> false
Глупо добавлять эти опции в LangInfo в данном случае, иначе этот тип рискует разрастись до абсурдных размеров.
Фреймворк, интерфейс, провайдер — унылое императивное ООП. Не надо этого. В F#-пе я использую примерно такой подход:
type Language =
| Java
| CSharp
| TSQL
| CustomLang of LangInfo
static member info = function
| Java -> LangInfo.new' "java" true "bean.svg"
| CSharp -> LangInfo.new' "cs" true "cs.svg"
| TSQL -> LangInfo.new' "sql" false "tsql.svg"
| CustomLang x -> x
module Helpers =
let langConfig : LangInfo list =
// взять конфигурацию из внешнего источника
...
type Language with
static member values =
[ Java; CSharp; TSQL ] @ (List.map CustomLang Helpers.langConfig )
ой, не смешите мои тапки. Плагины для браузеров писать — да в рот им ноги! «конкуренция» — что за блаженные глупости, где вы видели конкуренцию? :-) При малейшей возможности с js бы сбежали все, кроме геев и даунов, неспособных изучить второй ЯП из за умственной ограниченности. Хоть в джаву или С#.
Потому что https://www.reddit.com/r/programming/comments/4eh9qc/why_javascript_development_is_crazy/
Вкратце: примитивный язык, примитивный тулинг, примитивная рефлексия, смехотворно крошечная стандартная библиотека, поле невидимых граблей, хаков и шамантва и так далее. Унылый ЯП, который распространился благодаря монопольному положению в веб-стеке, реактивно набирающем популярность.
Или не будет. Или будет, но не так как надо и не долго. Билды ломаются — рандомно. И рандомно же чинятся со второго-третьего-четвертого запуска npm install и npm dedupe.
Решение из коробки в js в принципе нет, Реакт в этом ничуть не хуже Ангуляра. Если надо — берите Elm.
проблемное место Ангуляра — это любая чуть более чем тривиальная директива на нём. Это становится очевидно, если сравнить идентичный (именно идентичный, а не аналогичный) по функциональности код на Ангуляре и Реакте.
Чтобы реакт начал быть похож более менее на фреймворк то туда нужно воткнуть flux или redux
да ни фига.
В Реакте неизменяемый стэйт, что важно для многопоточных приложений.
Чтобы нормально писать jsx, достаточно знать html, а в Ангуляре надо учить очередной шаблонный движок и гей-синтаксис его шизофреничных директив + html. Все шаблонные движки сами по себе следствие ущербности языка. Собственно то, что есть jsx, в нормальных ЯП реализована на уровне языка в виде списковых включений.
В Реакте есть гуманная система оповещения об ошибках времени выполнения. В Ангуляре в этом смысле почти ноль
Впечатление, что дизайнили какие-то шизофреники — плотность дебильных eDSL, замаскированных хаков и неочевидного на квадратный сантиметр зашкаливает. Ну и пропертибиндинг — это в корне ущербная парадигма. Как и мутабельный VDOM.
А без разницы на чём писать Хелуволд. Но на чистом js проще чем на Ангуляре. React бесит навязыванием хакерских примочек, но сам по себе он не плох. А Ангуляр — это наихудший факиншэт из всех альтернатив.
Трудно найти более дебильный ЯП нежели чем JS, но гуглофейсбуку этого показалось мало — они дополнили его перечисленными автором хакерскими примочками. Да ещё и TypeScript изобрели, который не имеет даже банальных мапов, зато требует ещё больше примочек. Казалось бы — пиши себе на НОРМАЛЬНОМ языке с адекватными инструментами (ClojureScript, Elm, F#, PureScript ), используй js/css/html в качестве целевой платформы покуда не придумали что-то лучше. Но не тут то было:
Палка в заднице у левого зайца как-бы символизирует webpack
Прошу учесть, что Atom — отстойная пионэрская поделка, которую по хорошему надо сжечь и закопать. Вместо него следует использовать VS Code либо Emacs в зависимости от задач.
Особенности реализации сигналов в Purescript малоинтересны, поскольку в Elm 0.17 их выкинули за ненадобностью. А как на счёт реализации Elm Architecture в Purescript, она там есть? встроенная поддержка WebGL, чтобы компилятор мог распарсить текст шейдеров на GLSL и проверить согласованность используемых типов между шейдерами и основной программой?
О каких альтернативных подходах идёт речь и зачем их использовать?
"язык слабее Хаскеля" — тут не помешало бы пояснить, что вы имеете ввиду. Как по мне, так упрощение языка снизило порог вхождения и улучшило читаемость исходного кода.
В настоящее время Elixir в основном используется для создания веб-приложений с использованием как Cowboy (низкоуровневый HTTP-сервер), так и Phoenix (полнофункциональный фреймворк для разработки веб-приложений). Кроме того, Elixir пробивается в нишу встраиваемых систем благодаря фреймворку Nerves.
Так вот это полная ерунда в сравнении со сферой применении Erlang, на котором написан софт, обрабатывающий 50% всего сотового трафика.
Elm уникален и определённо имеет шанс взлететь, поскольку ориентирован на самую востребованную платформу, и предстовляет собой очень простой язык без хаскелизмов. Он собственно уже частично взлетел, так как React и Redux — это не что иное как кривой порт Elm для js
Elixir тоже наверно хорошо, если его кто-то действительно будет применять в телекоммуникациях, а не только в веб.
Что касается WPF, предлагаю Вам сравнить насыщенные видимыми контролами приложения WPF и Win forms по потреблению ресурсов перед тем, как предлагать кому-то WPF
Если код написан как у меня с дефолтным кэйсом , то вообще ничего. Иначе компилятор выдаст варнинг, что в этом месте данный кэйс не учтён.
нет исключений, не надо явно прописывать все варианты, легко сопровождаем, можно масштабировать. например, можно заменить
на
без тяжёлой атлетики
смотря что проще — внести его в конфиг, либо рассматривать как «особый случай»
== смысл тогда первые три значения вводить?
для упрощения обработки «особых случаев», которые по мнению автора не нужны. В предметной области описания ЯП их немерено.
Глупо добавлять эти опции в LangInfo в данном случае, иначе этот тип рискует разрастись до абсурдных размеров.
брэйнфаке и асм ещё проще
==. Да и не настолько он примитивный, это примитивный взгляд. :)
дв вы шо?? и что же там есть не примитивного? кроме хитрых граблей конечно
== ПО ссылке какая-то ерунда, не относящаяся к языку: DOM, jquery, html, Windows. Ну и оно на бусурманском. :)
это называется не читал но осуждаю :-)
== Стандартная библиотека унылая из-за того, что он использовался только в браузерах. :)
никакой логической связи
== Грабли, хаки, шаманство — это проблемы DOMа в IE как правило. :)
а new / this в js — это что?
Вкратце: примитивный язык, примитивный тулинг, примитивная рефлексия, смехотворно крошечная стандартная библиотека, поле невидимых граблей, хаков и шамантва и так далее. Унылый ЯП, который распространился благодаря монопольному положению в веб-стеке, реактивно набирающем популярность.
проблемное место Ангуляра — это любая чуть более чем тривиальная директива на нём. Это становится очевидно, если сравнить идентичный (именно идентичный, а не аналогичный) по функциональности код на Ангуляре и Реакте.
да ни фига.
В Реакте неизменяемый стэйт, что важно для многопоточных приложений.
Чтобы нормально писать jsx, достаточно знать html, а в Ангуляре надо учить очередной шаблонный движок и гей-синтаксис его шизофреничных директив + html. Все шаблонные движки сами по себе следствие ущербности языка. Собственно то, что есть jsx, в нормальных ЯП реализована на уровне языка в виде списковых включений.
В Реакте есть гуманная система оповещения об ошибках времени выполнения. В Ангуляре в этом смысле почти ноль
Особенно мне нравится часть про «click: '&', icon: '@'».
Для сравнения тоже самое на React+Typescript:
Трудно найти более дебильный ЯП нежели чем JS, но гуглофейсбуку этого показалось мало — они дополнили его перечисленными автором хакерскими примочками. Да ещё и TypeScript изобрели, который не имеет даже банальных мапов, зато требует ещё больше примочек. Казалось бы — пиши себе на НОРМАЛЬНОМ языке с адекватными инструментами (ClojureScript, Elm, F#, PureScript ), используй js/css/html в качестве целевой платформы покуда не придумали что-то лучше. Но не тут то было:
Палка в заднице у левого зайца как-бы символизирует webpack
Прошу учесть, что Atom — отстойная пионэрская поделка, которую по хорошему надо сжечь и закопать. Вместо него следует использовать VS Code либо Emacs в зависимости от задач.
Особенности реализации сигналов в Purescript малоинтересны, поскольку в Elm 0.17 их выкинули за ненадобностью. А как на счёт реализации Elm Architecture в Purescript, она там есть? встроенная поддержка WebGL, чтобы компилятор мог распарсить текст шейдеров на GLSL и проверить согласованность используемых типов между шейдерами и основной программой?
О каких альтернативных подходах идёт речь и зачем их использовать?
"язык слабее Хаскеля" — тут не помешало бы пояснить, что вы имеете ввиду. Как по мне, так упрощение языка снизило порог вхождения и улучшило читаемость исходного кода.
Ваша мысль ушла не туда. Я про то, что
Так вот это полная ерунда в сравнении со сферой применении Erlang, на котором написан софт, обрабатывающий 50% всего сотового трафика.
Elixir тоже наверно хорошо, если его кто-то действительно будет применять в телекоммуникациях, а не только в веб.
В последнем предложении опечатка — R"xyz()")xyz"
это утверждение не верное. Авторы стандартов С++ не допустят, что-бы всё было так просто.
Выражение R")" не компилируется из-за отсутствия открывающей скобки внутри необработанной строки.
Серьёзно?! R"xyz()xyz" представляет строку )" если что.