Здравствуйте, varenikAA, Вы писали:
AA>Не напрягает в строго типизированных ЯП все время изучать специфичный АПИ для знакомых вещей на подобие html?
Немножко оффтоп, но я бы предпочел, чтобы HTML был в обычных HTML-шаблонах, а не в коде.
Обычный HTML легче читать и писать. Это касается и программистов, и дизайнеров.
Здравствуйте, varenikAA, Вы писали:
AA>Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия. AA>А как думаете, ребята?
Кстати, почему строгая типизация сравнивается с динамической?
Здравствуйте, 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 не оказалось в стандартной коробке — можно добавить, библиотека расширяемая.
Здравствуйте, Буравчик, Вы писали:
Б>Немножко оффтоп, но я бы предпочел, чтобы 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
Здравствуйте, Ikemefula, Вы писали:
I>Никто же кроме тебя не скачет по всем языкам без разбора, потому и не напрягает.
"Мне кажется, чрезвычайно важно, чтобы мы, занимаясь информатикой, получали удовольствие от общения с компьютером. С самого начала это было громадным удовольствием. Конечно, время от времени появлялись заказчики, и через какое-то время мы стали серьезно относиться к их жалобам. Нам стало казаться, что мы вправду отвечаем за успешную и правильную работу компьютеров. Я не думаю, что это так. Я считаю, что мы отвечаем за то, чтобы их обучать, указывать им новые направления и поддерживать гармонию в доме. Я надеюсь, что информатика никогда не перестанет приносить удовольствие. Я надеюсь, что мы не станем миссионерами. Не надо чувствовать себя торговцами Библией. Таких в мире уже достаточно. То, что вы знаете о программировании, могут выучить и другие. Не думайте, что к успешной работе с компьютерами только в ваших руках ключ. Что у вас, как я думаю и надеюсь, есть — это логика: возможность увидеть в машине больше, чем вы видели, когда Вас впервые к ней подвели, увидеть, что вы можете сделать из ее нечто бoльшее."
Алан Перлис (Alan J Perlis)
Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия.
А как думаете, ребята?
Здравствуйте, varenikAA, Вы писали:
AA>Не напрягает в строго типизированных ЯП все время изучать специфичный АПИ для знакомых вещей на подобие html? AA>F#(Fable): AA>clojure(hiccup): AA>Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия.
Здравствуйте, Буравчик, Вы писали:
Б>Обычный HTML легче читать и писать. Это касается и программистов, и дизайнеров.
Спорный вопрос. Одно дело чистый хтмл, другое дело генерация.
Оно конечно хорошо когда меньше слоев, но и знать придется правила движка, по сути еше один ЯП знать.
Тот же razor pages до чего гнусная штука. правила спутаные. то так надо то эдак.
после ифов перенос обязательно, да еще зачем-то расширение особое. из-за этого нормально кодить только в студии.
Опять же половина за шаблоны, половина за код(реактивщики, фпшники).
Здравствуйте, varenikAA, Вы писали:
AA>Не напрягает в строго типизированных ЯП все время изучать специфичный АПИ для знакомых вещей на подобие html?
Не напрягает. Принципы библиотек для генерирования html в языках общего назначения выглядят примерно одинаково (вложенное дерево, используя какие-то конструкции языка). Зная html и язык разработки достаточно просто разобраться с библиотекой — достаточно увидеть пример, как описывать теги и атрибуты.
Но перескакивать с языка на язык приходится достаточно редко. Поэтому такой проблемы нет.
Как бы то ни было, при генерации нужно четко разделять данные и шаблон. Иначе сложно тестировать и поддерживать. В представленном коде этого нет.
Здравствуйте, anonymous, Вы писали:
A>Спорный момент. Всё основанное на синтаксисе XML так себе и для письма и для чтения. Но кому-то, возможно, уже привычно.
Безусловно. Зато это не только привычно, но и работает везде искаропки, без дополнительных приседаний.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, zverjuga, Вы писали:
A>>В F# нет аналога dynamic из C#? Z>нету. Z>с очень большой натяжкой к динамикам можно отнести анонимные записи, но здесь явно не тот случай.
А через type providers можно получить функциональность аналогичную dynamic? Или есть какие-то ограничения?
Здравствуйте, 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>Кстати, почему строгая типизация сравнивается с динамической? Может потому что это тоже типизация?
В лиспах можно предусловием строго проверять тип. Да и методы выполняться только на строго определенном типе.
Там просто это не сразу заметно, т.к. отсутствует явное приведение типов.
Не так ли?
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, varenikAA, Вы писали:
AA>>type-providers вещь прикольная, но вот СУБД плохо дружит,
A>А как ее позиционируют? Пока для меня она представляется некой примочкой для repl. Для обычного написания программ не понятно, в чем преимущество над генераторами кода по схеме?
Да, это как продвинутый генератор по сути, но вот из-за проблем с поиском сборок идея убивается частично.
типа настроил подключение и вот уже у тебя датаконтекст со всеми сущностями.
Плюс отсутствует "лишний" код, что тоже вроде не плохо. опять же, это бы отлично работало на скриптах.
Ну и еще до запуска кода типа знаешь схему.
у генератора в теории может иметься расхождение на момент запуска.
Здравствуйте, varenikAA, Вы писали:
AA>В лиспах можно предусловием строго проверять тип. Да и методы выполняться только на строго определенном типе. AA>Там просто это не сразу заметно, т.к. отсутствует явное приведение типов. AA>Не так ли?
Подпадает под описание языка со строгой (сильной) динамической типизацией.
Здравствуйте, varenikAA, Вы писали:
AA>Да, это как продвинутый генератор по сути, но вот из-за проблем с поиском сборок идея убивается частично. AA>типа настроил подключение и вот уже у тебя датаконтекст со всеми сущностями. AA>Плюс отсутствует "лишний" код, что тоже вроде не плохо. опять же, это бы отлично работало на скриптах.
Лишний код это только для скриптов, в реальном проекте лучше класть результат работы генератора в репозиторий.
AA>Ну и еще до запуска кода типа знаешь схему. AA>у генератора в теории может иметься расхождение на момент запуска.
Проблема в том, что у остального кода программы это расхождение тоже будет.
Никогда такой гадостью не пользуюсь, поэтому не напрягает.
Вообще единственный приемлемый синтаксис для HTML в языке придумали в JavaScript (React). Всё остальное — гадость. Поэтому весь HTML во внешние шаблоны и никак иначе.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, varenikAA, Вы писали:
AA>>Умом понимаю, что проверки типов и т.п. но почему-то приятно что можно просто кейвордами описать желаемый результат и он типизируется без моего участия. AA>>А как думаете, ребята?
M>А почему одно другому противопоставляется? Т.е. почему либо типизация, либо неудобный API? Взять тот же scalatags.
В Scala была же нормальная поддержка XML литералов. Зачем это?
Здравствуйте, vsb, Вы писали:
vsb>В Scala была же нормальная поддержка XML литералов. Зачем это?
Поддержка XML пока остается. В 3-й версии может на строковую интерполяцию переделают. А вообще проблема в том, что HTML — это не XML. Те же img и br элементы в HTML не имеют закрывающей пары. Или мой любимый атрибут checked, которому не нужно значение указывать в HTML.
Есть и другие приятные мелочи. Например, в scalatags вы не сможете опечатку в имени (общеупотребительного) тега или атрибута сделать, это проверяется на этапе компиляции. Есть сборка под scala-js. Причем эта сборка может оперировать сразу с узлами DOM, без промежуточного строкового представления. Та же интерполяция значений тоже лучше. В xml literal она делается через toString на значении. Даже для банальных Option[String] это приводит совсем не к тому, что хотел сказать автор. А вот в scalatags это делается через неявные преобразования и результат соответствует интуитивным представлениям (как минимум — это в нашей команде так, нам достаточно). А еще scalatags почти в два раза быстрее, чем scala-xml.
Ну а в целом никто же не заставляет пользоваться scalatags. Если для вас работает XML интерполяция — я рад за вас!
Здравствуйте, maxkar, Вы писали:
M>Поддержка XML пока остается. В 3-й версии может на строковую интерполяцию переделают. А вообще проблема в том, что HTML — это не XML. Те же img и br элементы в HTML не имеют закрывающей пары. Или мой любимый атрибут checked, которому не нужно значение указывать в HTML.
