Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}]
Чтобы десериализовать(получить полезные данные) в F#, нужно либо использовать объединение типов
и использовать FSharp.SystemTextJson.
либо делать два независимых типа msg и room и десериализовать дважды.
Особый профит получаем от атрибута CLIMutable — теперь наш type Msg легко проглотит данные Room и наш клиент выпадет с NRE.
УРА!
При этом в clojure (ДиНаМиКа!!!!) все делается 3-мя строчками:
Здравствуйте, varenikAA, Вы писали:
AA>Так почему мы все еще используем типы?
Потому что они дают возможность устранения определенного класса ошибок в программе ценой некоторого неудобства
Иногда этот trade-off выгоден.
Здравствуйте, 0x7be, Вы писали:
0>Потому что они дают возможность устранения определенного класса ошибок в программе ценой некоторого неудобства 0>Иногда этот trade-off выгоден.
Здравствуйте, 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. Хотя программист не обязан использовать все параметры, тем не менее он это делает и считает язык сложным. Это язык программирования с "избыточными" возможностями.
Напротив, программист который изначально ограничен языком программирования считает, что уж здесь всё намного проще. Он может даже не знать, что проводит неявное преобразование типов. Вот здесь и рождаются вопросы, вроде — "Нужны ли нам типы?".
Ещё вспоминается сильная и слабая типизация, но в принципе ничто не мешает компенсировать то или иное решение заложенное в язык программирования библиотекой алгоритмов, то есть усилить или ослабить типизацию создав свои типы, которые преобразуются друг в друга более или менее явно.
Ещё и '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, там всё гораздо лучше.
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 будет намного проще. И где тогда строгая типизация?
Я не знаю, нужны ли вам типы, но вот разделения кода и данных тут точно нет. А ну как кто-то в динамике добавит 42794967295 элементов массива? Завилтся ваше приложение набок, а в случае с линакс
Здравствуйте, varenikAA, Вы писали:
AA>Так почему мы все еще используем типы?
AA>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}] AA>(filter (fn [e] (:room e)) js)
Хотя бы поэтому. Без них некоторые и трех строк корректно написать не могут. И такой простой баг может прожить довольно долго, пока будет найден.
Типы ты используешь всегда. Разница в том, когда эти типы проверяются — на этапе компиляции (статика) или в рантайме (динамика). Плюс целый спектр между этими двумя. Плюс soundness vs. unsoundness системы типов. Плюс строгая vs. слабая типизация. Плюс уровни сахара в реализации языка. Плюс сложность самого языка.
В итоге строгий статически типизированный язык с, например, автоматическим выводом типов, sum и intersection типами и плюшками типа pattern-matching может вполне себе зарулить по удобству динамически-типизированный язык. В теории.
Здравствуйте, varenikAA, Вы писали:
AA>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}] AA>При этом в clojure (ДиНаМиКа!!!!) все делается 3-мя строчками: AA>Так почему мы все еще используем типы?
Потому что мы не пишем 3-строчные ОнКлики на говностраничках?
Типы — они придуманы не ради гемороя, а для надёжности. Вот как раз для таких случаев: какой-то клоун передаёт тебе в сервис ахинею, а сервис просто отбрасывает "левые" объекты и работает только с регламентированными.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, varenikAA, Вы писали:
AA>>TDD избавляет от таких ошибок.
P>Так что, типы не нужны? TDD идет им на смену?
Возможно, но типы они такие — описывают теоретическую модель. А данные гораздо сложнее моделей.
Пример json-а вполне реальный — из api rocket.chat.
Т.е. имея два четко определенных типов, на все равно придется городить кастомную десериализацию.
Причем это сработает, только если у нас будет возможность их четко отсортировать по наличию каких-то сигнальных полей.
Ну или вообще хадкорно, 1 — это один тип, 2 — это другой.
Опять приходит к необходимости рекурсирвного обхода токенов вручную.
Я другого пути не вижу.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, varenikAA, Вы писали:
AA>>(def js (json/read-str "[{ \"msg\" : \"Привет\"}, { \"room\" : \"Курилка\"}]":key-fn keyword))
BFE>Я не знаю, нужны ли вам типы, но вот разделения кода и данных тут точно нет. А ну как кто-то в динамике добавит 42794967295 элементов массива? Завилтся ваше приложение набок, а в случае с линакс
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
AA>>Так почему мы все еще используем типы?
AA>>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}] AA>>(filter (fn [e] (:room e)) js)
DM>Хотя бы поэтому. Без них некоторые и трех строк корректно написать не могут. И такой простой баг может прожить довольно долго, пока будет найден.
Здравствуйте, ltc, Вы писали:
ltc>Здравствуйте, varenikAA, Вы писали:
AA>>Так почему мы все еще используем типы?
ltc>Моё мнение — типов нужно даже гораздо больше, чем есть сейчас. ltc>А ты делаешь какие-то глобальные выводы на примере решения очень частной задачки.
Малое или большое лишь размеры. Суть прежняя. Если в малом такие проблемы, то что мы получим в большой системе?
Еще большую сложность, которая не сущностная, а чисто техническая.
Здравствуйте, Mamut, Вы писали:
AA>>Так почему мы все еще используем типы?
M>Типы ты используешь всегда. Разница в том, когда эти типы проверяются — на этапе компиляции (статика) или в рантайме (динамика). Плюс целый спектр между этими двумя. Плюс soundness vs. unsoundness системы типов. Плюс строгая vs. слабая типизация. Плюс уровни сахара в реализации языка. Плюс сложность самого языка.
M>В итоге строгий статически типизированный язык с, например, автоматическим выводом типов, sum и intersection типами и плюшками типа pattern-matching может вполне себе зарулить по удобству динамически-типизированный язык. В теории.
M>На практике всё — говно.
Максимальный опыт у меня с C#. Строгую типизацию встретил в F#(проекты для дущи и мелкая автоматизация каких-то задач)
чуть позже Nemerle. C# в принципе умеет неявно приводить, а динамик вообще решает проблему десериализации.
Nemerle тоже умеет в ExpandObject, правда там приходится все приводить явно. Не уверен, что это хорошо. Возможно это просто иллюзия контроля над ситуацией.
Nemerle не говно, если выбирать статику. Но блин уже хочется dotnet core.
Clojure если динамику.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, varenikAA, Вы писали:
AA>>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}] AA>>При этом в clojure (ДиНаМиКа!!!!) все делается 3-мя строчками: AA>>Так почему мы все еще используем типы?
K>Потому что мы не пишем 3-строчные ОнКлики на говностраничках?
K>Типы — они придуманы не ради гемороя, а для надёжности. Вот как раз для таких случаев: какой-то клоун передаёт тебе в сервис ахинею, а сервис просто отбрасывает "левые" объекты и работает только с регламентированными.
В том то и дело, что не отбросил, и не упал, а передал дальше по цепочке вызовов не-инициализированную структуру с null-полями. Это кстати большой вопрос к F#. А может нет, Есть заточенные под F# сериализаторы. Скорее всего там с контролем получше. Но тогда зачем вводить CLIMutable? Чтобы обойти защиту F# типов? Приплыли.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, varenikAA, Вы писали:
AA>>Так почему мы все еще используем типы? S> А в F# нет динамиков?
Есть какое-то FSharp.Interop.Dynamic
Скорее всего просто пара функций для удобства работы с ExpandoObject
Ну, тогда зачем типы? Если таже кложа намного проще в работе с динамикой?
Да, даже в C# как-то проще, из-за меньшей строгости.
Здравствуйте, vsb, Вы писали:
P>>Классическое (JS): P>>
P>>'2'+3="23"
P>>'2'-3=-1
P>>
P>>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо...
vsb>Так типы тут никуда не девались. В Java тоже можно написать "2" + 3 = "23". Это просто идиотская философия JavaScript, пытаться исполнять код до последнего, они там напридумывали всяких имплиситных преобразований, потому и получается так. Возьми Lua, там всё гораздо лучше.
Самое интересное, что в Javascript реализациях это меняется — хотя по-человечески сделать всё равно не хотят.
Вот тут (оригинала что-то не видно), или тут:
Здравствуйте, Буравчик, Вы писали:
0>>Потому что они дают возможность устранения определенного класса ошибок в программе ценой некоторого неудобства 0>>Иногда этот trade-off выгоден. Б>Не иногда, а часто выгоден.
Не часто, а всегда. Попробуй показать пример, когда не выгоден.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, varenikAA, Вы писали: P>>Классическое (JS): P>>
P>>'2'+3="23"
P>>'2'-3=-1
P>>
P>>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо... AA>TDD избавляет от таких ошибок.
То есть ты предпочитаешь написать гору тестового кода вместо строгой типизации?
Молодец.
Здравствуйте, alexanderfedin, Вы писали:
A>Здравствуйте, varenikAA, Вы писали: P>>>Классическое (JS): P>>>
P>>>'2'+3="23"
P>>>'2'-3=-1
P>>>
P>>>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо... AA>>TDD избавляет от таких ошибок. A>То есть ты предпочитаешь написать гору тестового кода вместо строгой типизации? A>Молодец.
Разве тесты не являются своего рода спецификацией?
Когда пишется тест, то определяется "что", но не "как".
Типы это тоже самое тестирование только со стороны языка/компилятора.
Тут скорее вопрос в другом являются ли типы строго-типизированного языка
100% отражением структур данных которые подаются на вход?
Если писать интеграцию с системой вроде рокет-чата, то вариантов упасть из-за несоответствия типов будет больше
чем если изначально не надеятся на то, что структуры данных извне всегда будут строго соответствовать типам доменной модели.
и даже если мы в преобразовании на входе оборачиваем все в Option Some или None, то чем это лучше безтиповой проверки
let getUsername data =
match data.username with
| Some val -> val
| None -> "noname"
(or (:username data) "noname")
;или просто проверка на нуль:
(nil? (:username data))
Здравствуйте, varenikAA, Вы писали:
AA>Типы это тоже самое тестирование только со стороны языка/компилятора.
То же самое. Только для этого не надо тесты писать.
AA>Тут скорее вопрос в другом являются ли типы строго-типизированного языка AA>100% отражением структур данных которые подаются на вход?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, varenikAA, Вы писали:
AA>>Типы это тоже самое тестирование только со стороны языка/компилятора.
НС>То же самое. Только для этого не надо тесты писать.
Разница не только в подходах. TDD вроде в парах кодят — первым пишет код тестировщик,
вторым разраб. На типах наоборот. Но главное, типы определяют, чего мы ждем от внешнего мира.
В динамике мы лишь можем предположить что вот это нам сейчас придет, если нет выполнение можно продолжить без ошибок.
AA>>Тут скорее вопрос в другом являются ли типы строго-типизированного языка AA>>100% отражением структур данных которые подаются на вход?
НС>А они должны?
В том то и беда, что ООП очень сильно внушило мысль, что данные тождественно равны объектам.
Из-за этого появляются ненужные абстракции в приложении, которые вносят существенную сложность,
вопреки задачи — упростить решение.
Здравствуйте, varenikAA, Вы писали:
AA>Разница не только в подходах.
Разница тольков том, надо ли писать тесты на то что контролирует система типов, или нет.
AA>Но главное, типы определяют, чего мы ждем от внешнего мира.
Нет.
НС>>А они должны? AA>В том то и беда, что ООП очень сильно внушило мысль, что данные тождественно равны объектам.
Здравствуйте, varenikAA, Вы писали:
AA> Но главное, типы определяют, чего мы ждем от внешнего мира. AA>В динамике мы лишь можем предположить что вот это нам сейчас придет, если нет выполнение можно продолжить без ошибок.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
AA>> Но главное, типы определяют, чего мы ждем от внешнего мира. AA>>В динамике мы лишь можем предположить что вот это нам сейчас придет, если нет выполнение можно продолжить без ошибок.
DM>Вот на эту тему недавно подробная заметка была, много бурления вызвала: DM>https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
Не силен в английском, но хаскел читается намного тяжелее жаваскрипта, да и кода в разы больше.
Можно из этого сделать вывод, что хаскел круче жээса?
Здравствуйте, varenikAA, Вы писали:
AA>Есть какое-то FSharp.Interop.Dynamic AA>Скорее всего просто пара функций для удобства работы с ExpandoObject AA>Ну, тогда зачем типы? Если таже кложа намного проще в работе с динамикой? AA>Да, даже в C# как-то проще, из-за меньшей строгости.
Посмотрел и вспомнил старую книжку по дизайну на java, там всю книжку городили огород на типах,
а в конце сделали вывод, что свойства лучше хранить в словарях
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Serginio1, Вы писали:
S>> Большинство как раз и работает с типами. DynamicObject https://metanit.com/sharp/tutorial/9.2.php
AA>Посмотрел и вспомнил старую книжку по дизайну на java, там всю книжку городили огород на типах, AA>а в конце сделали вывод, что свойства лучше хранить в словарях
В шарпе с DynamicObject нет проблем. Только вот реального кода на DynamicObject раз, два и обчелся.
Тот же TypeScript с аннотацией типа предпочтительнее нетипизированного JS.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Тот же TypeScript с аннотацией типа предпочтительнее нетипизированного JS.
JS — динамически типизируемый вроде или нет?
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Serginio1, Вы писали:
S>>Тот же TypeScript с аннотацией типа предпочтительнее нетипизированного JS. AA>JS — динамически типизируемый вроде или нет?
Суть именно в статической типизации и интеллисенсом. В том же 1С есть вывод типов с использованием интеллисенса. И многие прибегают к условной компиляции для параметров методов с привоением тип (тз=Новый ТаблицаЗначений)
Просто это удобно и безопасно.
Да еще чем хороша аннотация типа, это тем, что можно прописать некую утиную типизацию. Там строгости типов то нет. Основное это интеллисенс и предупреждения
и солнце б утром не вставало, когда бы не было меня
ltc>Моё мнение — типов нужно даже гораздо больше, чем есть сейчас.
Их нужно не больше. Их нужно — грамотнее и проработаннее. С алгеброй, сопоставлением, автовыводом, типажами, трансформациями, хиндли-милнером и прочими плюшками:
1. Сокращающими, насколько возможно, необходимость явно давать имена всему, что не является сущностями предметной области. Не забываем шутку, которая нифига не шутка, про два "бича божьих" в разработке ПО: cache coherence, naming things
2. Выводящими "утиную типизацию" (если нечто ходит крякает как утка, то будем считать, что это утка) на уровень Джеки Чана: "холодное оружие бывает колющим, режущим и дробящим, но на крайний случай сгодится и табуретка".
Здравствуйте, varenikAA, Вы писали:
AA>Так почему мы все еще используем типы?
упаси бог писать чтото большое или с неясной окончательной архитектурой без статических типов
языки без типов по сути нерефектабельны, либо нада покрывать тестами на 100%
я тут проектом одним занимаюсь уже лет 10, если бы он был на языке с динамической типизацией я бы уже давно покончил с собой
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Privalov, Вы писали:
P>Типы нужны. Типизация должна быть 1) строгой, 2) статической. Со слабой типизацией еще в PL/1 наблюдались весьма забавные эффекты в его попытках автоматически исправлять ошибки программиста.
PL/1 существовал в условиях, когда от отдачи исходников (на бумажке) в перфораторскую до получения распечатки могло полдня пройти. В такой ситуации попытки выжать из программы хоть что-то вполне оправданы. Все равно, хуже не будет.
Здравствуйте, varenikAA, Вы писали:
AA>Возможно, но типы они такие — описывают теоретическую модель. А данные гораздо сложнее моделей.
Если у тебя данные по природе своей структурированы, они должны ложиться на какую-то статическую систему типов. Если твои данные представляют собой любые возможные сочетания строк, то и работай с ними, как со строками. Я только не представляю, что еще можно разумного сделать с неструктурированными данными, кроме как заархивировать их.
Здравствуйте, Pzz, Вы писали:
Pzz>PL/1 существовал в условиях, когда от отдачи исходников (на бумажке) в перфораторскую до получения распечатки могло полдня пройти. В такой ситуации попытки выжать из программы хоть что-то вполне оправданы. Все равно, хуже не будет.
В нашей глухомани замена ЭВМ на компьютеры шла с некоторой задержкой. Поэтому c PL/1 я успел столкнуться в самом начале карьеры. Идентификаторы на грузинском языке мне как раз в нем разбирать пришлось. Благо размер листинга был всего несколько метров. PRIMUS был несбыточной мечтой. Редактор текста — IEBUPDTE.
Компилятор с него — шедевр. Работал в 96 К памяти. Но сам язык — сильно так себе.
В Фортране тоже надо было полдня ждать от сдачи исходников до получения распечатки. Но там подобной ерунды не возникало. А вот в PL/1 эти незаметные преобразования и расширенный до предела аппарат умолчаний приводили к веcьма неожиданным эффектам.
Слава байту, мои старшие товарищи для своих целей выбрали Фортран.
Здравствуйте, Privalov, Вы писали:
P>Классическое (JS): P>
P>'2'+3="23"
P>'2'-3=-1
P>
P>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо...
Здесь проблема не в том, что нет типов, типы как раз есть. Здесь проблема в неявном преобразовании типов, например оператор минус явно работает с числами, и неявное преобразование строки в число, которое подгоняет типы операндов к тем, которые принимает оператор минус, и есть корень зла. То же самое с плюсом, он определён для строк как конкатенация, поэтому неявное преобразование второго операнда в строку даёт wtf-эффект.
Здравствуйте, Hobbes, Вы писали:
H>Здесь проблема не в том, что нет типов, типы как раз есть. Здесь проблема в неявном преобразовании типов, например оператор минус явно работает с числами, и неявное преобразование строки в число, которое подгоняет типы операндов к тем, которые принимает оператор минус, и есть корень зла. То же самое с плюсом, он определён для строк как конкатенация, поэтому неявное преобразование второго операнда в строку даёт wtf-эффект.
Ну да, слабая типизация во всей красе.
Такое впечатление, что JS сделан так, чтобы программы на нем никогда не падали. Это даже круче VB6, в котором, по крайней мере, надо было on error resume next писать.
В принципе, подобное и в шарпе прокатит. Но только в редких случаях. И если заменить + на — после строковой переменной, программа свалится. А если между 2 и 3, то отработает.
using System;
public class Program
{
public static void Main()
{
Console.WriteLine(2 + 3 + "a" + 8 + 5);
}
}
А JS в любом случае отработает. Боюсь себе представить, как он себя в более сложными, чем числа, объектами ведет.
Здравствуйте, Privalov, Вы писали:
P>Ну да, слабая типизация во всей красе. P>Такое впечатление, что JS сделан так, чтобы программы на нем никогда не падали. Это даже круче VB6, в котором, по крайней мере, надо было on error resume next писать.
... P>А JS в любом случае отработает. Боюсь себе представить, как он себя в более сложными, чем числа, объектами ведет.
Как напишешь, так и ведёт. Если ты пишешь хитромудрые конструкции, то любые ожидания будут неадекватными.
Нужно использовать оболочку навроде TypeScript для статической типизации и писать нормальный код без хитромудрых конструкций.
Часть этих хитромудрых конструкций действительно дает короткий и эффективный код. Но дизайн этих вещей никогда не был и не будет консистентным, фактически, их никто не проектировал. Соответственно, неосмотрительные эксперименты нежелательны.
Много способов получить ошибку на ровном месте, тем не менее, вагон и маленькая тележка получить читаемый код который соответствует ожиданиям.
Например, в C/С++ промахиваясь по массиву, ты затираешь чужую память. В шарпе или джаве — получаешь исключение. В жээсе память не затирается, в зависимости от кода можешь получить что угодно.
Фиксится лекго — просто добавляешь явную проверку на границы массива, если расширяешь массив, делаешь это явно и не абы каким числом и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Как напишешь, так и ведёт. Если ты пишешь хитромудрые конструкции, то любые ожидания будут неадекватными.
Я в JS не так чтобы полный гуманитарий, но все же теоретик. Питон при попытке прибавить число к строке кинул исключение, а JS — нет.
На JS мне только поправить кое-что несложное пришлось. Я старался быть проще.
I>Нужно использовать оболочку навроде TypeScript для статической типизации и писать нормальный код без хитромудрых конструкций.
Статическая — это, конечно, хорошо. А она у TypeScript сильная или слабая? Со слабой я еще в PL/1 наблюдал презабавные эффекты с преобразованием типов.
I>Часть этих хитромудрых конструкций действительно дает короткий и эффективный код. Но дизайн этих вещей никогда не был и не будет консистентным, фактически, их никто не проектировал. Соответственно, неосмотрительные эксперименты нежелательны.
Дак если теоретик, вроде бы и стараешься соломки расстелить, а все равно стреляет внезапно.
I>Например, в C/С++ промахиваясь по массиву, ты затираешь чужую память. В шарпе или джаве — получаешь исключение. В жээсе память не затирается, в зависимости от кода можешь получить что угодно.
Вот, а я не хочу что угодно. Обленился, привык, что исключение вылетает. В этом случае поправить бывает просто. А вот когда я в Фортране расстреливал память, а программа завершалась нормально, но на выходе, правда, был мусор, было весело. Как выяснилось, в MS DOS сегменты подбросили развлекуху. Тут дело не в Фортране, а в его реализации.
I>Фиксится лекго — просто добавляешь явную проверку на границы массива, если расширяешь массив, делаешь это явно и не абы каким числом и тд.
Здравствуйте, Privalov, Вы писали:
P>Статическая — это, конечно, хорошо. А она у TypeScript сильная или слабая? Со слабой я еще в PL/1 наблюдал презабавные эффекты с преобразованием типов.
Преобразование типов как в жээсе. Тайпскрипт только добавляет вывод типов, дженерики и тд. В рантайме всё тайпскриптовое стирается.
I>>Часть этих хитромудрых конструкций действительно дает короткий и эффективный код. Но дизайн этих вещей никогда не был и не будет консистентным, фактически, их никто не проектировал. Соответственно, неосмотрительные эксперименты нежелательны.
P>Дак если теоретик, вроде бы и стараешься соломки расстелить, а все равно стреляет внезапно.
Внезапно как раз не стреляет
I>>Например, в C/С++ промахиваясь по массиву, ты затираешь чужую память. В шарпе или джаве — получаешь исключение. В жээсе память не затирается, в зависимости от кода можешь получить что угодно.
I>>Фиксится лекго — просто добавляешь явную проверку на границы массива, если расширяешь массив, делаешь это явно и не абы каким числом и тд. P>Когда как. Легко — не значит просто.
Здравствуйте, Ikemefula, Вы писали:
I>Преобразование типов как в жээсе. Тайпскрипт только добавляет вывод типов, дженерики и тд. В рантайме всё тайпскриптовое стирается.
То есть, с точки зрения теоретика, все осталось, как было? Чтобы числа сортировать как таковые, все еще требуется компаратор писать? Иначе он числа как строки отсортирует?
I>Внезапно как раз не стреляет
Стреляет как раз внезапно. Иногда спустя годы. У меня недавно так беспорядочное использование dynamic-ов в Шарпе выстрелило. Лет 6 работало до этого. Еле починил.
P>>Когда как. Легко — не значит просто.
I>Не просто, но это вполне себе рабочий вариант.
Здравствуйте, Privalov, Вы писали:
I>>Преобразование типов как в жээсе. Тайпскрипт только добавляет вывод типов, дженерики и тд. В рантайме всё тайпскриптовое стирается.
P>То есть, с точки зрения теоретика, все осталось, как было? Чтобы числа сортировать как таковые, все еще требуется компаратор писать? Иначе он числа как строки отсортирует?
Именно. Зато если известен тип, то компилятор будет подсказывать где надо.
I>>Внезапно как раз не стреляет
P>Стреляет как раз внезапно. Иногда спустя годы. У меня недавно так беспорядочное использование dynamic-ов в Шарпе выстрелило. Лет 6 работало до этого. Еле починил.
Здравствуйте, varenikAA, Вы писали:
AA>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}] AA>[...] AA>Так почему мы все еще используем типы?
ты, дядя Вареник, неправильные выводы делаешь.
правильный такой: json не нужен.
как и весь javascript, впрочем.
приличные программисты до последнего отказываются на нём писать, придумывают всякие TypeScript/Dart, иначе совсем невмоготу.
Здравствуйте, LuciferSaratov, Вы писали:
LS>приличные программисты до последнего отказываются на нём писать, придумывают всякие TypeScript/Dart, иначе совсем невмоготу.
Ну, значит я неприличный, ведь не язык красит человека, а человек язык.
Мысль я думаю понятна.
Но честно скажу, все эти траспайлеры в js по большей части такая жопа.
Наиболее удачно смотрится clojurescript, но как раз благодаря полной динамики.
если не хотите json, дядя Хикки придумал вам edn. Попробуйте, это, ммммм-м, вкусно!
Здравствуйте, varenikAA, Вы писали:
AA>>>TDD избавляет от таких ошибок. Ops>>Значит ты наврал Ops>>... Ops>>и кроме 3 строчек надо еще 100 строчек тестов?
AA>Если все просто и понятно, то можно и не писать. Разрабу решать, что нужно тестить, а что нет.
Сложить А и Б, а потом отнять С — это просто или понятно? Можно не тестировать?
Подсчёт суммы всех элементов можно не тестировать? Нахождение среднего?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, varenikAA, Вы писали:
AA>>>>TDD избавляет от таких ошибок. Ops>>>Значит ты наврал Ops>>>... Ops>>>и кроме 3 строчек надо еще 100 строчек тестов?
AA>>Если все просто и понятно, то можно и не писать. Разрабу решать, что нужно тестить, а что нет.
Ф>Сложить А и Б, а потом отнять С — это просто или понятно? Можно не тестировать?
Ф>Подсчёт суммы всех элементов можно не тестировать? Нахождение среднего?
Если используем библиотечную функцию, например (reduce + '(1 2 3)), то конечно мы тестировать не будем, а если мы написали свою,
то естественно да:
(def lst '(1 2 3))
(= (reduce + lst) (sumlst lst))
Здравствуйте, varenikAA, Вы писали:
AA>>>>>TDD избавляет от таких ошибок. Ops>>>>Значит ты наврал Ops>>>>... Ops>>>>и кроме 3 строчек надо еще 100 строчек тестов?
AA>>>Если все просто и понятно, то можно и не писать. Разрабу решать, что нужно тестить, а что нет.
Ф>>Сложить А и Б, а потом отнять С — это просто или понятно? Можно не тестировать?
Ф>>Подсчёт суммы всех элементов можно не тестировать? Нахождение среднего?
AA>Если используем библиотечную функцию, например (reduce + '(1 2 3)), то конечно мы тестировать не будем, а если мы написали свою, AA>то естественно да: AA>(def lst '(1 2 3)) AA>(= (reduce + lst) (sumlst lst))
Т.е. значит всё-таки наврал, и три строчки никак не получается....
Всё сказанное выше — личное мнение, если не указано обратное.