Посмотрел и вспомнил старую книжку по дизайну на 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, иначе совсем невмоготу.
