Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}]

Чтобы десериализовать(получить полезные данные) в F#, нужно либо использовать объединение типов
и использовать FSharp.SystemTextJson.
либо делать два независимых типа msg и room и десериализовать дважды.
Особый профит получаем от атрибута CLIMutable — теперь наш type Msg легко проглотит данные Room и наш клиент выпадет с NRE.
УРА!

При этом в clojure (ДиНаМиКа!!!!) все делается 3-мя строчками:

(def js (json/read-str  "[{ \"msg\" : \"Привет\"}, { \"room\" : \"Курилка\"}]":key-fn keyword))

; [{:msg "Привет"} {:room "Курилка"}]

(filter (fn [e] (:msg e)) js)

;({:msg "Привет"})

(filter (fn [e] (:room e)) js)

; ({:room "Курилка"})

Так почему мы все еще используем типы?

Здравствуйте, varenikAA, Вы писали:

AA>Так почему мы все еще используем типы?
Потому что они дают возможность устранения определенного класса ошибок в программе ценой некоторого неудобства
Иногда этот trade-off выгоден.

Здравствуйте, 0x7be, Вы писали:

0>Потому что они дают возможность устранения определенного класса ошибок в программе ценой некоторого неудобства
0>Иногда этот trade-off выгоден.

Не иногда, а часто выгоден.

Здравствуйте, varenikAA, Вы писали:

AA>Так почему мы все еще используем типы?

Классическое (JS):

'2'+3="23"
'2'-3=-1

Может, конечно, мои взгляды на жизнь устарели, и оно так и надо...

Здравствуйте, varenikAA, Вы писали:

AA>Чтобы десериализовать(получить полезные данные) в F#, нужно либо использовать объединение типов
AA> и использовать FSharp.SystemTextJson.
AA>либо делать два независимых типа msg и room и десериализовать дважды.
AA>Особый профит получаем от атрибута CLIMutable — теперь наш type Msg легко проглотит данные Room и наш клиент выпадет с NRE.
AA>УРА!

Это вопросы к конкретному языку F#, а не к типам.

AA>Так почему мы все еще используем типы?

Это у "вас" надо спрашивать. Не хотите — не используйте, всем пофиг.

Здравствуйте, varenikAA, Вы писали:

AA>Так почему мы все еще используем типы?

Может я не совсем понял тему, так как меня не интересуют вторичные языки программирования, но типы данных всегда существуют. И разница есть лишь в преобразовании типов, например, явном или неявном. Взаимодействие с внешними источниками данных это ещё одна большая тема.

Предположим у нас есть язык программирования и в нём для задания типа, функции или другой конструкции можно, хотя и не обязательно, определить параметры a, b, c, d, e, f, а в другом есть только a. Хотя программист не обязан использовать все параметры, тем не менее он это делает и считает язык сложным. Это язык программирования с "избыточными" возможностями.

Напротив, программист который изначально ограничен языком программирования считает, что уж здесь всё намного проще. Он может даже не знать, что проводит неявное преобразование типов. Вот здесь и рождаются вопросы, вроде — "Нужны ли нам типы?".

Ещё вспоминается сильная и слабая типизация, но в принципе ничто не мешает компенсировать то или иное решение заложенное в язык программирования библиотекой алгоритмов, то есть усилить или ослабить типизацию создав свои типы, которые преобразуются друг в друга более или менее явно.

Здравствуйте, Privalov, Вы писали:

P>

P>'2'+3="23"
P>'2'-3=-1
P>

Ещё и '2'-'3'=-1

P>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо...

Миллионы JS кодеров не могут ошибаться *LOL*. Впрочем, есть typescript для частичного решения этой задачи — при разработке типы есть и ловим ошибки, при работе типов уже нету и тут может происходить всё что угодно.

Здравствуйте, Privalov, Вы писали:

AA>>Так почему мы все еще используем типы?

P>Классическое (JS):
P>

P>'2'+3="23"
P>'2'-3=-1
P>

P>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо...

Так типы тут никуда не девались. В Java тоже можно написать "2" + 3 = "23". Это просто идиотская философия JavaScript, пытаться исполнять код до последнего, они там напридумывали всяких имплиситных преобразований, потому и получается так. Возьми Lua, там всё гораздо лучше.

Здравствуйте, velkin, Вы писали:


V>Ещё вспоминается сильная и слабая типизация, но в принципе ничто не мешает компенсировать то или иное решение заложенное в язык программирования библиотекой алгоритмов, то есть усилить или ослабить типизацию создав свои типы, которые преобразуются друг в друга более или менее явно.

Интересная статья:

Например, яркими примерами слабой системы типов являются те, что лежат в основе языков Си и C++. Их характерными атрибутами являются понятия приведения типов и каламбуров типизации. Эти операции поддерживаются на уровне компилятора и часто вызываются неявно. Операция reinterpret_cast в С++ позволяет представить элемент данных любого типа как принадлежащий любому другому типу при условии равенства длины их низкоуровневой реализации (битового представления) и изменить его состояние образом, недопустимым для исходного типа. Неосторожное использование таких операций нередко является источником крахов программ.

...

В теории программирования сильная типизация является непременным элементом обеспечения надёжности разрабатываемых программных средств. При правильном применении (подразумевающем, что в программе объявляются и используются отдельные типы данных для логически несовместимых значений) она защищает программиста от простых, но труднообнаруживаемых ошибок, связанных с совместным использованием логически несовместимых значений, возникающих иногда просто из-за элементарной опечатки.

Подобные ошибки выявляются ещё на этапе компиляции программы, тогда как при возможности неявного приведения практически любых типов друг к другу (как, например, в классическом языке Си) эти ошибки выявляются только при тестировании, причём не все и не сразу, что порой очень дорого обходится на этапе промышленной эксплуатации.

Python является одним из примеров языка с сильной динамической типизацией

Здравствуйте, vsb, Вы писали:

vsb>Так типы тут никуда не девались. В Java тоже можно написать "2" + 3 = "23". Это просто идиотская философия JavaScript, пытаться исполнять код до последнего, они там напридумывали всяких имплиситных преобразований, потому и получается так. Возьми Lua, там всё гораздо лучше.

Ясно, что не делись. Вопрос был: нужны ли. Разработчики JS решили, что не нужны. Результат: он данные трактует, как захочет. Я как-то пытался на нем массив чисел отсортировать. Оказалось, чтобы отсортировать числа как таковые, необходимо компаратор написать. По умолчанию сортируются строки в лексикографическом порядке.

Типы нужны. Типизация должна быть 1) строгой, 2) статической. Со слабой типизацией еще в PL/1 наблюдались весьма забавные эффекты в его попытках автоматически исправлять ошибки программиста.
Недавно я еще столкнулся с беспорядочным использованием dynamic в Шарпе. Несколько лет оно работало. Внезапно вылезло нечто. Справился, но предпочел бы это время потратить на что-нибудь более полезное. Повбывав бы.

Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, varenikAA, Вы писали:

AA>>Чтобы десериализовать(получить полезные данные) в F#, нужно либо использовать объединение типов
AA>> и использовать FSharp.SystemTextJson.
AA>>либо делать два независимых типа msg и room и десериализовать дважды.
AA>>Особый профит получаем от атрибута CLIMutable — теперь наш type Msg легко проглотит данные Room и наш клиент выпадет с NRE.
AA>>УРА!

ARK>Это вопросы к конкретному языку F#, а не к типам.

тут без разницы какой язык, все равно с dynamic будет намного проще. И где тогда строгая типизация?

Здравствуйте, Privalov, Вы писали:

P>Здравствуйте, varenikAA, Вы писали:

AA>>Так почему мы все еще используем типы?

P>Классическое (JS):
P>

P>'2'+3="23"
P>'2'-3=-1
P>

P>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо...

TDD избавляет от таких ошибок.

Здравствуйте, varenikAA, Вы писали:

AA>TDD избавляет от таких ошибок.

Так что, типы не нужны? TDD идет им на смену?

Здравствуйте, varenikAA, Вы писали:

AA>(def js (json/read-str "[{ \"msg\" : \"Привет\"}, { \"room\" : \"Курилка\"}]":key-fn keyword))

Я не знаю, нужны ли вам типы, но вот разделения кода и данных тут точно нет. А ну как кто-то в динамике добавит 42794967295 элементов массива? Завилтся ваше приложение набок, а в случае с линакс

Автор: Ваня Первачев
Дата: 20.01.20

ещё и систему с собой заберет.

Здравствуйте, varenikAA, Вы писали:

AA>Так почему мы все еще используем типы?

AA>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}]
AA>(filter (fn [e] (:room e)) js)

Хотя бы поэтому. Без них некоторые и трех строк корректно написать не могут. И такой простой баг может прожить довольно долго, пока будет найден.

Здравствуйте, varenikAA, Вы писали:

AA>TDD избавляет от таких ошибок.

Значит ты наврал

При этом в clojure (ДиНаМиКа!!!!) все делается 3-мя строчками:

и кроме 3 строчек надо еще 100 строчек тестов?

Здравствуйте, Ops, Вы писали:

Ops>и кроме 3 строчек надо еще 100 строчек тестов?

Тесты — это для слабаков! Мы сразу все пишем без ошибок! Тесты не нужны!

Здравствуйте, varenikAA, Вы писали:

AA>Так почему мы все еще используем типы?

Моё мнение — типов нужно даже гораздо больше, чем есть сейчас.
А ты делаешь какие-то глобальные выводы на примере решения очень частной задачки.

AA>Так почему мы все еще используем типы?

Типы ты используешь всегда. Разница в том, когда эти типы проверяются — на этапе компиляции (статика) или в рантайме (динамика). Плюс целый спектр между этими двумя. Плюс soundness vs. unsoundness системы типов. Плюс строгая vs. слабая типизация. Плюс уровни сахара в реализации языка. Плюс сложность самого языка.

В итоге строгий статически типизированный язык с, например, автоматическим выводом типов, sum и intersection типами и плюшками типа pattern-matching может вполне себе зарулить по удобству динамически-типизированный язык. В теории.

На практике всё — говно.

Здравствуйте, varenikAA, Вы писали:

AA>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}]
AA>При этом в clojure (ДиНаМиКа!!!!) все делается 3-мя строчками:
AA>Так почему мы все еще используем типы?

Потому что мы не пишем 3-строчные ОнКлики на говностраничках?

Типы — они придуманы не ради гемороя, а для надёжности. Вот как раз для таких случаев: какой-то клоун передаёт тебе в сервис ахинею, а сервис просто отбрасывает "левые" объекты и работает только с регламентированными.