Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия.
А как думаете, ребята?
Здравствуйте, varenikAA, Вы писали:
AA>Не напрягает в строго типизированных ЯП все время изучать специфичный АПИ для знакомых вещей на подобие html? AA>F#(Fable): AA>clojure(hiccup): AA>Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия.
Здравствуйте, varenikAA, Вы писали:
AA>Не напрягает в строго типизированных ЯП все время изучать специфичный АПИ для знакомых вещей на подобие html?
Немножко оффтоп, но я бы предпочел, чтобы HTML был в обычных HTML-шаблонах, а не в коде.
Обычный HTML легче читать и писать. Это касается и программистов, и дизайнеров.
Здравствуйте, Буравчик, Вы писали:
Б>Немножко оффтоп, но я бы предпочел, чтобы HTML был в обычных HTML-шаблонах, а не в коде. Б>Обычный HTML легче читать и писать. Это касается и программистов, и дизайнеров.
Спорный момент. Всё основанное на синтаксисе XML так себе и для письма и для чтения. Но кому-то, возможно, уже привычно.
Просто можно сравнить, например, HTML и HAML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Myspace</title>
</head>
<body>
<h1>I am the international space station</h1>
<p>Sign my guestbook</p>
</body>
</html>
!!! XML
!!!
%html
%head
%title Myspace
%body
%h1 I am the international space station
%p Sign my guestbook
Здравствуйте, Буравчик, Вы писали:
Б>Обычный HTML легче читать и писать. Это касается и программистов, и дизайнеров.
Спорный вопрос. Одно дело чистый хтмл, другое дело генерация.
Оно конечно хорошо когда меньше слоев, но и знать придется правила движка, по сути еше один ЯП знать.
Тот же razor pages до чего гнусная штука. правила спутаные. то так надо то эдак.
после ифов перенос обязательно, да еще зачем-то расширение особое. из-за этого нормально кодить только в студии.
Опять же половина за шаблоны, половина за код(реактивщики, фпшники).
Здравствуйте, varenikAA, Вы писали:
AA>Не напрягает в строго типизированных ЯП все время изучать специфичный АПИ для знакомых вещей на подобие html?
Не напрягает. Принципы библиотек для генерирования html в языках общего назначения выглядят примерно одинаково (вложенное дерево, используя какие-то конструкции языка). Зная html и язык разработки достаточно просто разобраться с библиотекой — достаточно увидеть пример, как описывать теги и атрибуты.
Но перескакивать с языка на язык приходится достаточно редко. Поэтому такой проблемы нет.
Как бы то ни было, при генерации нужно четко разделять данные и шаблон. Иначе сложно тестировать и поддерживать. В представленном коде этого нет.
Здравствуйте, varenikAA, Вы писали:
AA>Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия. AA>А как думаете, ребята?
Я думаю, что кложа — говнище, сделанное для увеличения количества страданий.
Не, я всё понимаю, что проверки времени компиляции, которые делает любой статически типизированный язык, не заменяют тестов.
Но, во-первых, я вот сломал в одном углу сигнатуру функции — и у меня даже до компиляции красненьким подсвечены все места, которые мне нужно поменять.
А во-вторых, даже когда я потрудился написать исчерпывающий набор юнит-тестов на кложе (а это примено вдвое длиннее собственно исходника), то эти тесты не укажут мне, где именно проблема.
Просто что-то не удаётся привести к IF, и сиди гадай что именно и почему.
Отладка в кложе — адская боль: к примеру, невозможно просто понавтыкать в программу print-ов (про пошаговую отладку я уж и не заикаюсь!), потому что print returns null, и надо эти нуллы грамотно проигнорировать.
У меня не вызывает никакой радости возможность быстро написать нерабочий код. Опечатался ты в каком-нибудь :prewiew — и привет, минус час на поиск места среди сотен этих скобок, где оно упало.
Ну, и работает кложа поверх JVM, добавляя к чудовищной неэффективности джава-машины свою собственную тормознутость.
Это на корню убивает весь выигрыш от безтиповости.
Ну, вот к примеру, я хочу написать тип "дерево" на дотнете. Понятно, что он у меня будет generic, что-то типа Tree<T>.
Вот тут у меня возникают проблемы такого рода: даже если дерево-иммутабельное, то я не могу операцию Tree<Base> Add<Base, Derived>(this Tree<Derived>, Base element) where Derived: class, Base эффективной — потому, что Tree<T> состоит из Node<T>, а сделать Node<T> ковариантной я не могу.
А если я попробую обойти это через ковариантный интерфейс INode<out T>, то у меня упадёт производительность вообще всех операций — там везде будет indirection, никакого инлайнинга, и такое дерево будет работать в разы медленнее не-вариантного аналога.
В каком-нибудь С++ мне об этом беспокоится не надо — указатель он и есть указатель, я буду его кастить к тому, что мне потребуется, прямо по месту.
Вот такие вещи, конечно же, несколько раздражают.
Но их нормальный программист видит полтора раза в жизни, а в остальное время он просто пользуется коробочным System.Collections.Immutable, и в ус не дует.
При этом аналогичная фигня на той же кложе мало того, что запросто стрельнет в продакшн (как там, кстати, у кложи с code coverage reports?), так ещё и дерево на ней будет гарантированно медленнее не только С++, но и C#, даже в самом тупом и стрёмном его варианте с INode<out T> и рукопашными приведениями в стиле INode<T>[] SplitChild(INode<T> child) => (child is Leaf leaf)? BuildLeaves(Split((T[])leaf.Data)): BuildIndices(Split(((Index)child).Children));
Кстати, этот код читается не хуже его аналога на кложе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, varenikAA, Вы писали:
AA>Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия. AA>А как думаете, ребята?
А почему одно другому противопоставляется? Т.е. почему либо типизация, либо неудобный API? Взять тот же scalatags. Оно статически и строго типизировано, при этом код читается так же, как ваша closure. Первый же пример из документации:
html(
head(
script(src:="..."),
script(
"alert('Hello World')"
)
),
body(
div(
h1(id:="title", "This is a title"),
p("This is a big paragraph of text")
)
)
)
Проверки на несуществующие атрибуты (опечатки) проверяются, там в документации почти в самом началае картинки есть. И подсказка к атрибутам/методам тоже есть.
Если вдруг вашего любимого tag/attribute не оказалось в стандартной коробке — можно добавить, библиотека расширяемая.
Здравствуйте, anonymous, Вы писали:
A>Спорный момент. Всё основанное на синтаксисе XML так себе и для письма и для чтения. Но кому-то, возможно, уже привычно.
Безусловно. Зато это не только привычно, но и работает везде искаропки, без дополнительных приседаний.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, zverjuga, Вы писали:
A>>В F# нет аналога dynamic из C#? Z>нету. Z>с очень большой натяжкой к динамикам можно отнести анонимные записи, но здесь явно не тот случай.
А через type providers можно получить функциональность аналогичную dynamic? Или есть какие-то ограничения?
Здравствуйте, varenikAA, Вы писали:
AA>Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия. AA>А как думаете, ребята?
Кстати, почему строгая типизация сравнивается с динамической?
Здравствуйте, amironov79, Вы писали:
A>Интересная вещь. Насколько практичная? Легко ее сломать например неполными данными?
type-providers вещь прикольная, но вот СУБД плохо дружит,
сегодня я не смог запустить по .net core SQLProvider для MS SQL!!!
Зато пробовал например xsd, отлично пашет, MYSQL тоже заводится тяжело и непонятные ошибки на референсы при первом запуске скрипта в интерактив,
второй раз отрабатывает, будто библиотеки прогружаются в рантайм после загрузки кода.
ну и sqlite тоже чтобы завести надо попатеть.
html фуфло, точно не помню но при попытке заюзать он использовал радномный тэг для названия таблицы который менялся при каждом запросе )))
а метода обращения к таблице допустим по индексу не было.
вообщем, трахадром. я так понял большинство за даппер для БД. еще на днях была публикация, майнтеры EF приглашают в команду F# для лучшей поддержки в фшарпе.
Здравствуйте, varenikAA, Вы писали:
AA>type-providers вещь прикольная, но вот СУБД плохо дружит,
А как ее позиционируют? Пока для меня она представляется некой примочкой для repl. Для обычного написания программ не понятно, в чем преимущество над генераторами кода по схеме?
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, varenikAA, Вы писали:
AA>>type-providers вещь прикольная, но вот СУБД плохо дружит,
A>А как ее позиционируют? Пока для меня она представляется некой примочкой для repl. Для обычного написания программ не понятно, в чем преимущество над генераторами кода по схеме?
не преимущество, но просто интересная штука, что в F# интеллинс позволяет запускать куски кода вне основной программы и после работы тайп-провайдера у тебя становятся доступными свойства и методы возвращаемого объекта, которые можно посмотреть после ввода точки. то есть это получается не dynamic, а та же статическая типизация, но в рантайме. из unknown объекта на выходе ты имеешь вполне конкретный тип.
Здравствуйте, amironov79, Вы писали:
A>Кстати, почему строгая типизация сравнивается с динамической? Может потому что это тоже типизация?
В лиспах можно предусловием строго проверять тип. Да и методы выполняться только на строго определенном типе.
Там просто это не сразу заметно, т.к. отсутствует явное приведение типов.
Не так ли?
