AZ
А я скинул это в другой чат и меня спросили откуда, я сказал, что спрошу
Size: a a a
2020 January 24
R
я сравнивал конкурентов раста
R
а вообще хочешь быстро заработать лучше пхп
R
чем в большем дерьме ты копаешься тем быстрее заработаешь)))
AZ
я уже предлагал sap
R
я уже предлагал sap
1с уже, че уж там)))
AZ
1с уже, че уж там)))
сап дороже
DF
Кстати почему в России сап не взлетел?
DF
Ну типа могли же сделать версию для рф законов
R
Dollar Føølish
Ну типа могли же сделать версию для рф законов
кто будет это делать?)
1с - тяп ляп и готова)
1с - тяп ляп и готова)
P
Although I can’t give it the full treatment it deserves right now, I’d still like to touch on the idea briefly so that interested readers may be able to find other resources on the subject should they wish to do so. The key idea is that many dynamically typed languages idiomatically reuse simple data structures like hashmaps to represent what in statically-typed languages are often represented by bespoke datatypes (usually defined as classes or structs).
These two styles facilitate very different flavors of programming. A JavaScript or Clojure program may represent a record as a hashmap from string or symbol keys to values, written using object or hash literals and manipulated using ordinary functions from the standard library that manipulate keys and values in a generic way. This makes it straightforward to take two records and union their fields or to take an arbitrary (or even dynamic) subselection of fields from an existing record.
In contrast, most static type systems do not allow such free-form manipulation of records because records are not maps at all but unique types distinct from all other types. These types are uniquely identified by their (fully-qualified) name, hence the term nominal typing. If you wish to take a subselection of a struct’s fields, you must define an entirely new struct; doing this often creates an explosion of awkward boilerplate.
These two styles facilitate very different flavors of programming. A JavaScript or Clojure program may represent a record as a hashmap from string or symbol keys to values, written using object or hash literals and manipulated using ordinary functions from the standard library that manipulate keys and values in a generic way. This makes it straightforward to take two records and union their fields or to take an arbitrary (or even dynamic) subselection of fields from an existing record.
In contrast, most static type systems do not allow such free-form manipulation of records because records are not maps at all but unique types distinct from all other types. These types are uniquely identified by their (fully-qualified) name, hence the term nominal typing. If you wish to take a subselection of a struct’s fields, you must define an entirely new struct; doing this often creates an explosion of awkward boilerplate.
тайпскрипт, кстати, в этом хорошо преуспел, котлиновская рефлексия тоже
AZ
тайпскрипт, кстати, в этом хорошо преуспел, котлиновская рефлексия тоже
ну тайпскрипт явно движение в этом направлении. Но там всё упрощяется тем что под капотом жс. Но это не совсем полноценная система типов, как я уже говорил. Я не уверен что тот же io-ts схавает A & B & C
AZ
энивей рекомендую почитать всю статью целиком: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
P
ну тайпскрипт явно движение в этом направлении. Но там всё упрощяется тем что под капотом жс. Но это не совсем полноценная система типов, как я уже говорил. Я не уверен что тот же io-ts схавает A & B & C
ну, я про тайпскрипт и котлин упомянул как раз в разрезе формы данных, ты можешь в рантайме собирать их в кучу и разделять благодаря свойствам как объекта, которые доступны сразу, а не через рефлективный секс типа Class.getDeclaredMethods(), BeanUtils и т.п.
SP
энивей рекомендую почитать всю статью целиком: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
о в копилочку
AZ
ну, я про тайпскрипт и котлин упомянул как раз в разрезе формы данных, ты можешь в рантайме собирать их в кучу и разделять благодаря свойствам как объекта, которые доступны сразу, а не через рефлективный секс типа Class.getDeclaredMethods(), BeanUtils и т.п.
ну это едва ли можно считать решением
P
энивей рекомендую почитать всю статью целиком: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
читал целиком, но там про слабую связанность и входные данные, а тут больше про выходные данные
p
Ор
AZ
Кто тут за питон топил?