Зачем нужна статическая типизация?, или Вы всё врете!

Ты не ответил на

Зачем нужна статическая типизация?, или Вы всё врете! (комментарий)

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

Ну и так пишут на Си специально, что бы 100 + 200 = 44.

А вы на языке, за который топите, так сможете?

Си максимально близок к логике работы процессора, а там такие операции допустимы и 44 это абсолютно правильный и единственный ответ. Если будет что-то другое, тогда это будет ошибкой.

Но, на сколько я понял, автор примера лишь топит за какой-то конкретный язык и ему пофиг на дискуссию по теме топикстартера.

var rules = {
  "1XXXX" : 100,
  "5XXXX" : 50,
  "111XX" : 1000,
  "AAAXX" : ({A})=>A * 100,
  "1111X" : 2000,
  "11111" : 4000,
  "12345" : 8000,
  "23456" : 8000,
  "AABBX" : 4000
}
var token = new Set(["A","B"]); //возможные токены
var tokenAny = "X"; //токен любая кость
var diceValues = new Set(["1","2","3","4","5","6"]); //значения костей
//TODO ruleset validator

var dice = (d)=> Math.floor(Math.random() * d) + 1; //not used
var dices = (n, d)=> Array(n).fill().map(v=>dice(d)); //not used
var numSort = (a, b) => a - b; //сортировка чисел
var different = (arr) => { //все значения в массиве разные
  arr.sort(numSort);
  var res = true;
  arr.forEach((v,i)=>{
    if (!i) return;
    if (v == arr[i - 1]) res = false;
  });
  return res;
}
var arrCount = (arr, what)=>{ //возвращает число вхождений в массив
  return arr.reduce((s, v)=>(s + ((v === what) ? 1 : 0)), 0);
}
var arrRemove = (arr, what, count = 1) => { //убирает count what элементов из массива
  for (let n = 0; n < count; n++) {
    var i = arr.indexOf(what);
    if (i == -1) return false;
    arr.splice(i, 1);
  }
  return true;
}
var join = (arr, stack = [], i = 0)=>{ //декартово произведение массивов
  if (!arr[i]) return stack;
  return arr[i].map(v=>join(arr, [v, ...stack], i + 1))
}

var profit = function(rules, hand) { //подсчёт профита
  if (!hand.length || hand.length != 6 || !hand.every(v=>diceValues.has(String(v))) throw("Type error in profit");
  //var hand = [ 1, 3, 6, 2, 1]

  var profits = Object.entries(rules).map(([rule, value])=>{
    //var rule = "AABBX", value = 4000;
    //rule - AABBX, 123XX, AA1111, value - number | function
    var ruleDice = rule.split("").filter(v=>v != tokenAny); //AABB, 123, AA111
    var tokens = new Set(ruleDice.filter(v=>token.has(v))); //AB, , A
    var tokenCount = ruleDice.reduce((s, v)=>{ //{A : 2, B : 2}, {}, {A : 2}
      s[v] = (s[v] || 0) + 1;
      return s;
    }, {})
    var handSet = new Set(hand);
    var variants = 
      join([...tokens].map(T=>[...handSet].map(D=>({[T] : D})))). //[ [ [ {A : 1}, {B : 1} ], [ {A : 1, B : 2} ], ...
      flat(tokens.size - 1). //[ [ {A : 1}, {B : 1} ], [{A : 1}, {B : 2}] ...
      filter(arr=>different(arr.map(v=>Object.values(v)[0]))). //[ [ {A : 1}, {B : 2} ], [{A : 1}, {B : 3}] ...
      map(rec=>rec.reduce((s, v)=>({...s, ...v}), {})). // [ {A : 1, B : 2}, {A : 1, B : 3} ...
      filter(v=>Object.entries(v).every(([T, D])=>tokenCount[T] <= arrCount(hand, D))) //[ { A : 1, B : 2 }, { A : 2, B : 1} ]
    var func = (typeof value == "function") ? value : ()=>value; //приведение к функции

    if (!variants.length && !tokens.size) {
      variants = [{}]; //в случае если в правиле нет токенов A/B добавить заглушку
    }

    var ret = variants.map(variant=>{
        var checkHand = [...hand];
        var ok = true;
        Object.values(variant).forEach(D=>{ //наличие нужного количества костей по токену правила
          if (!ok) return;
          var ok = arrRemove(checkHand, D, tokenConut[D]); //убираем из руки, если нашли что надо
        })
        if (!ok) return null;
        ok = ruleDice.filter(v=>diceValues.has(v)).every(D=>{
          var i = checkHand.indexOf(+D); //убираем кости по номеру в правилах
          if (i == -1) return false;
          checkHand.splice(i, 1);
          return true;
        });
        if (!ok) return null;
        return { hand, rule, variant, profit : func(variant) }
      }).filter(v=>v);
    return ret.reduce((max, v)=>{ //оставляем самый выигрышный вариант
      if (max.profit < v.profit) max = v;
      return max;
    }, {hand, rule, profit : 0})
  });
  var maxProfit = profits.reduce((max, v)=>{ //еще раз
      if (max.profit < v.profit) max = v;
      return max;
  }, { profit : 0 });
  return maxProfit;
}
profit(rules, [1, 3, 6, 2, 1]) //100 - 1XXXX
profit(rules, [1, 5, 6, 2, 1]) //100 - 1XXXX
profit(rules, [3, 5, 6, 2, 6]) //50  - 5XXXX
profit(rules, [1, 1, 1, 2, 6]) //1000 - 111XX
profit(rules, [2, 2, 2, 3, 6]) //200 - AAAXX
profit(rules, [3, 3, 3, 1, 6]) //300 - AAAXX
profit(rules, [4, 4, 4, 3, 6]) //400 - AAAXX
profit(rules, [5, 5, 5, 3, 6]) //500 - AAAXX
profit(rules, [1, 1, 1, 1, 4]) //2000 - 1111X
profit(rules, [1, 1, 1, 1, 1]) //4000 - 11111
profit(rules, [1, 2, 4, 3, 5]) //8000 - 12345
profit(rules, [2, 3, 4, 5, 6]) //8000 - 23456
profit(rules, [2, 2, 3, 3, 6]) //4000 - AABBX

Мда… У тебя получилось плюс минус столько же строк (возможно в статье на хабре не все написано, ну даже если даписать, по большому счету кода будет примерно столько же).

Только вот мне, как человеку, который изредка немного пишет на JS (кстати, я думал, что «var» уже устарел) короткие скрипты-помогаторы для Qml и как человеку, который не писал на C# никогда, так вот мне код с хабра на C# читать легче, чем твой, код там более прост, названия классов говорящие и т.п. У тебя там сам черт ногу сломит. И это как раз отличное доказательство моих утверждений: если язык позволяет писать лапшой и венегретом - то так и будут делать. И вот конечно же ты никогда не ошибешься и не обратишься к несуществующему методу или переменной-члену. А если такого кода 100k+ строк ? Тоже нет? Ну что же, ты исключение, но большинство программистов ошибутся. А когда через пару лет нужно будет разбираться в таком коде, что тогда?

Справедливости ради замечу, что наверное на JS можно было бы сделать более читабельнее, но это не исключает проблему того, что где-то может быть несоответствие типов/вызываемых методов.

Ну во первых в случае известных на этапе компиляции значений это в принципе реализуемо, а в случае, когда значения слагаемых будут известны только в момент выполнения? Что тогда по твоему должно быть? Может компилятор должен встроить проверку результата для всех цифровых типов в арифметические операторы и например бросать исключение, если результат выходит за границу типа? Так что ли? А что делать в случаях, когда мне не нужна эта проверка? Когда я хочу выжить максимальную производительность и оверхэд мне не нужен? Например в случае реализации какого нибудь алгоритма хэширования, где постоянно результат выходит за границу типа, но согласно стандарту компилятора С++ результат берется по модулю числа, которое на единицу больше, чем наибольшее значение, которое может быть представлено результирующим целочисленным типом без знака. Сюда тоже встроить проверку на каждой итерации? Чтобы все тормозило как этот ваш js ?

Компьютеры придумали, чтобы делать работу вместо человека. Но люди поняли, что если компьютер будет делать работу вместо них, то человека уволят. И сделали динамическую типизацию. Теперь человек делает работу вместо компьютера и получает зарплату. Здорово, чё.

А можно подробнее?

Я про сам подход, а не про реализацию. Если правильно помню, первым был Конрад Цузе в 1938м в Германии. Он для Z4 делал язык Планкалкюль и придумал концепцию выражения составных типов которую он называл «запись» (понятия объект еще не существовало). Также, если не ошибаюсь, он первый использовал циклы и вообще - массивы для создания этих «записей» где-то в 1942-43 годах.

Еще, попутно, он заложил базу процедурного программирования, но его влияние обычно не признавали что не удивительно, т.к. немцы проиграли вторую мировую. Тот же ALGOL 58 ZMMD (сделанный опять таки немцами для Z22 но быстро забытый и переделанный штатами уже у себя под «свои» компы) появившись через 20 лет взял часть идей у Цузе, но никогда не признавал этого. Вообще, большинство базовых концепций заложили немцы, американцы лишь утянули это себе вместе с работами по ракетам и прочему.

Цузе даже книгу написал, но ее не издали, а его работы сунули под сукно отказав в признании. И только через 30 лет, Алан Кей сказал что вот это вот - объект, а еще через 7 лет появилась Simula.

Welcome to the magical world of Turbo Pascal/Delphi

Может компилятор должен встроить проверку результата для всех цифровых типов в арифметические операторы и например бросать исключение, если результат выходит за границу типа?

{$R+}, {$Q+}

А что делать в случаях, когда мне не нужна эта проверка?

{$R-}, {$Q-}

Я про сам подход

Так не интересно.

Если правильно помню, первым был Конрад Цузе в 1938м в Германии.

Т.е. еще до появления ЭВМ как таковых?

Ну тогда непонятно, почему не начинать с Чарлза Бэббиджа и Ады Лавлейс.

И только через 30 лет, Алан Кей сказал что вот это вот - объект, а еще через 7 лет появилась Simula.

Простите, я в цифрах запутался. Simula появилась в 1967-ом году. Первый SmallTalk от Алана Кея – это, вроде бы, 1972-й. И еще вопрос насколько Smalltalk-72 похож на тот самый Smalltalk-80, который Smalltalk-ом то и считается.

Ну может быть это и было бы полезно в виде опции. Хотя, учитывая оверхед, применеие этого было бы самое широкое.

А сколько бы ты хотел?

Я бы хотел ошибку во время сборки.

Как интересно. А что еще он может отловить? Одно нихрена?

Система типов должна бить по рукам, а не втыкать нож в спину. С тем же успехом она может позволять складывать числа со строками, а потом усмехаться: „Ну, а фигли ты хотел, лопушок?“. Любой ответ на вопрос: „Сколько будет 100 + 200?“, кроме «300» является грубой арифметической ошибкой. Любая успешная попытка положить в переменную типа «число от 0 до 255» любое число вне этого диапазона является грубой ошибкой типизации. Люди, которые связывают себя типами по рукам и ногам, чтобы надёжно было, а потом легко принимают, что это их вообще не защитило от ошибки — странные люди, я вас не понимаю.

Зачем нужна статическая типизация?, или Вы всё врете! (комментарий)

Мда… У тебя получилось плюс минус столько же строк (возможно в статье на хабре не все написано, ну даже если даписать, по большому счету кода будет примерно столько же).

Там не написано меньше половины.

(кстати, я думал, что «var» уже устарел)

Ссылку на спеку, где такое написано.

И это как раз отличное доказательство моих утверждений

Хахахаха. ЛОЛ. Доказательство.

так вот мне код с хабра на C# читать легче

Теперь посчитай, сколько надо изменений в говнокод с хабра, чтобы сделать 111AA. Если ты собрался что-то там доказывать, давай, меряй объективными критериями. Свой «мне кажется» «мне легче читать» и прочие оценки сам знаешь куда можно засунуть.
Вот для затравки:

var rules = { "111AA" : 100500 };

class RuleГовна extends IГовно {
  private int profit = 100500;
  public RuleГовна(частные парамеры) {
    //
  }
  public eval() {
    //...частные проверки говна
    return profit;
  }
}
...+ где то где эти правила заводятся в коде
_rules.push(new RuleГовна(...))

если язык позволяет писать лапшой и венегретом

А многослойка из классов - это что? Рыба в шубе?

И вот конечно же ты никогда не ошибешься и не обратишься к несуществующему методу или переменной-члену.

Нет. Я не обращаюсь к свойствам хрен пойми чего. Если я обращаюсь, значит там точно функция. Это только вчерашние стшник так делают.

А если такого кода 100k+ строк ?

Обоже мой. И что же? А у меня же есть 100k+ строк. И что? Я в половину этой базы написал (еще когда не умел нихрена писать) и не трогаю. Есть интерфес, есть описание этого интерфейса, он делает хорошо свою маленькую работу и всё. Нахрена к нему лезть? Это у вас принято писать так, что весь код перевязан и по нему надо постоянно лазить вдоль и поперёк, а тем временем лет 50 назад придумали униксвей и модульность, да вам, как всегда, рассказать забыли.

Ну что же, ты исключение, но большинство программистов ошибутся

Ну так пусть валят писать классы на своём сисярпе. Я их заставляю как будто.

А когда через пару лет нужно будет разбираться в таком коде, что тогда?

Он покрывает столько кейсов, что скорее всего в него вообще не придётся залазить. Вся сложность и кастомное поведение выносится из такого кода во вне. Если что-то надо расширить, ну залазишь, разбираешься, да расширяешь. Как и везде. То, что ты не знаешь жс, тебе не понятно, ну так то твои проблемы, верно?

Си максимально близок к логике работы процессора, а там такие операции допустимы

А в чём тогда претензии к складыванию числа со строкой? У PHP тоже есть причины так делать и там такие операции допустимы.

44 это абсолютно правильный и единственный ответ.

Надеюсь у вашей учительницы математики нет пользователя на лоре.

А что еще он может отловить?

Действительно, а что еще… :-) как ты обесценил мастерски. Учитывая ту лапшу, что ты написал, это уже немало.

Эта лапша делает больше, чем недопроектик на сисярп с 10х кода. Не обидно вот так сливать лапше?

Т.е. еще до появления ЭВМ как таковых?

Первая Z1 создана Конрадом Цузе в 1938м в Германии. Он и ЭВМ делал и алгоритмическую базу под нее разрабатывал. Он смог сохранить Z4 во время войны, но Германии запретили свои ЭВМ делать после войны, все что было вывезли американцы и заявили что это они основы ООП сделали в MIT для PDP-1 в 60х.

Это как немцы сделали Фау-2, американцы вывезли вместе с фон Брауном и получилась американская космическая программа. Тоже самое с ЭВМ и языками программирования.

Ну тогда непонятно, почему не начинать с Чарлза Бэббиджа и Ады Лавлейс.

Потому что они закладывали основы вычислительных машин вообще, а не основы ООП как алгоритмического подхода. Мы же об ООП говорим, а не про ЭВМ вообще.

Простите, я в цифрах запутался. Simula появилась в 1967-ом году. Первый SmallTalk от Алана Кея – это, вроде бы, 1972-й.

Алан Кей писал программы для Burroughs 220 еще в 1959м. Но тогда он еще не знал о работах Цузе и в 1960м пытался создавать «модули» - микропрограммы которые несут в себе данные (объединял данные и код). В 1966г начал плотно заниматься именно этими «модулями», получил работы Цузе, изучил их и впоследствии назвал свои «модули» - объектами. Хотя его модули-объекты это доработанные по работам Цузе - «записи».

И еще вопрос насколько Smalltalk-72 похож на тот самый Smalltalk-80, который Smalltalk-ом то и считается.

Мне сложно судить о похожести т.к. я не вел активную разработку на этих языках. Насколько я могу судить, похож примерно также как ALGOL-58 похож на ALGOL который алголом и считается.

Заставь компухтер сделать выведение хоть чего-нибудь из представленной классовой иерархии на сисярпе. И вообще, научись свои выпады аргументировать хоть чем-нибудь, кроме своего ненужного ихмо. Удачи.

Алё, товарищ, ты все читал Зачем нужна статическая типизация?, или Вы всё врете! (комментарий)

???

Или нет. Если мы думаем над производительностью, то оверхеда много. И реализации некоторых алгоритмов будут избыточно усложнены.

а в случае, когда значения слагаемых будут известны только в момент выполнения?

Думайте. Защита статической типизации — ваша тема, не собираюсь вас никак ограничивать в возможных решениях.

Может компилятор должен встроить проверку результата

Может быть. А может — исходя из кода вывести систему ограничений на допустимые значения, так, что если есть c=a+b и a=200, то должно бытьb<55 или ошибка. Варианты есть.

но согласно стандарту компилятора С++

Жалкая отмазка. Все претензии к $ПлохойЯзык, тоже можно снимать возражением, что согласно его стандарту всё так и должно работать?

Эта лапша делает больше

Набор случайных ассемблерных команд тоже. Критерий хорошего кода/яп не только в том, что можно быстро нафигачить плохочитаемой лапши, которая что-то там делает.

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

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

А вы на языке, за который топите, так сможете?

Вроде что-то можно было в типизированных массивах. Только зачем, хз.

Жалкая отмазка. Все претензии к $ПлохойЯзык, тоже можно снимать возражением, что согласно его стандарту всё так и должно работать?

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

Критерий хорошего кода/яп не только в том, что можно быстро нафигачить плохочитаемой лапши, которая что-то там делает.

Давай, бомби критериями «хорошего кода». Ты не вывезешь.
Плохочитаемая - так это ты анскилл и проблемы тут исключительно твои. У кого глаз уже намётан, тем нормально всё читается.

Первая Z1 создана Конрадом Цузе в 1938м в Германии.

В Интернетах пишут, что Z1 – это механическая вычислительная машина. Не ЭВМ. («Э» в ЭВМ, вроде бы, расшифровывается как «Электронно»).

все что было вывезли американцы и заявили что это они основы ООП сделали в MIT для PDP-1 в 60х.

Но на самом деле все было не так. Ага, просто историю переписали победители.

Копаться в конспирологии и глубокой древности мне не интересно.

Обычный программист мог попробовать class-based OOP начиная с Simula67. Попробовать же prototype-based OOP можно было разве что с Self-а в конце 1980-х.

Но, конечно же, можно найти истоки ООП-шного подхода в математической теории множеств и на этом основании послать вдоль все, что было сделано в XX-ом веке.

Ну это ваши проблемы, что вы не можете выдержать изначального тезиса: „В случае СТ компилятор может проверить всё на этапе компиляции и избавить от ошибок“ и начинаете вилять тем местом, где спина утрачивает своё благородное название.

скорость некоторых алгоритмов ухудшится

Сделайте, чтоб не ухудшалась, либо признайте, что не можете гарантировать корректность результата вычислений. У вас два варианта, можете выбрать любой.

Свой «мне кажется» «мне легче читать» и прочие оценки сам знаешь куда можно засунуть.

Да, знаю, тебе в одно громкое место. По такой логике ты можешь сделать тоже самое со своими аргументами. Мы сейчас начинаем на личности переходить и оскробления писать?

Нет. Я не обращаюсь к свойствам хрен пойми чего. Если я обращаюсь, значит там точно функция. Это только вчерашние стшник так делают.

Ага, значит ты наш местный гений с психикой терминатора.

Обоже мой. И что же? А у меня же есть 100k+ строк. И что? Я в половину этой базы написал (еще когда не умел нихрена писать) и не трогаю

Нахрена к нему лезть?

Действительно нахрена старый код читать :-) Я даже добавлю: а нахрена его запускать :-)

Ну так пусть валят писать классы на своём сисярпе. Я их заставляю как будто.

Уверенность - это хорошо

Он покрывает столько кейсов, что скорее всего в него вообще не придётся залазить

На то и расчет у js-иков.

Ну это ваши проблемы, что вы не можете выдержать изначального тезиса: «В случае СТ компилятор может проверить всё на этапе компиляции и избавить от ошибок»

а можно ссылку на мое сообщение, где я писал «ВСЕ ОШИБКИ».

Плохочитаемая - так это ты анскилл и проблемы тут исключительно твои. У кого глаз уже намётан, тем нормально всё читается.

А можно поинтересоваться, ты работаешь в большой команде и сколько тебе лет?

Ты рассматриваешь 100u8 и 200u8 как целые числа, я их рассматриваю как числа из поля по модулю 256. А теперь обоснуй, почему твоя позиция единственно правильная. И ещё, действильно ли только динамическая типизация позволяет при возведении 2 в сотую степень получить 1267650600228229401496703205376.

В Интернетах пишут, что Z1 – это механическая вычислительная машина. Не ЭВМ. («Э» в ЭВМ, вроде бы, расшифровывается как «Электронно»).

Да, Z1 - первая ограниченно программируемая вычислительная машина немецкого инженера Конрада Цузе.

Как этот факт (механическая) влияет на разработку алгоритмический подхода? Второй раз напоминаю что мы говорим об основе ООП как алгоритмического подхода. Вы же снова скатываете обсуждение к ЭВМ.

Но на самом деле все было не так. Ага, просто историю переписали победители. Копаться в конспирологии и глубокой древности мне не интересно.

Если вам «не интересно», то на этом можно c вами закончить, у меня нет задачи кого-то переубеждать и ломать его веру в то что швятой барен, все сам изобрел и придумал. Лунную программу видимо тоже американцы сами сделали. Только штурмбаннфюрера СС Вернера фон Брауна лучше не гуглить, а то можно разрыв шаблона получить.

Как этот факт (механическая) влияет на разработку алгоритмический подхода?

А ООП – это алгоритмический подход?

Если так, то давайте тогда к теории множеств обратимся, где, емнип, есть понятие актуально бесконечных множеств, а способом анализа их свойств является оценка свойств объектов, помещаемых/изымаемых из этих самых множеств. Мне, например, доводилось читать о том, что истоки ООП именно в этом направлении лежат.

Второй раз напоминаю что мы говорим об основе ООП как алгоритмического подхода. Вы же снова скатываете обсуждение к ЭВМ.

А я вам намекаю, что пока не появились ЭВМ и люди не набили кучу шишек создавая программы для них, пока не появилась потребность в ЯП, пока не пришли к выводу, что должны быть ЯП высокого уровня, пока не убедились в том, что программы должны быть модульными, а инкапсуляция – это не пустой звук, ООП как такового не было. В практическом смысле этого слова.

Если вам «не интересно», то на этом можно c вами закончить, у меня нет задачи кого-то переубеждать и ломать его веру в то что швятой барен, все сам изобрел и придумал. Лунную программу видимо тоже американцы сами сделали. Только штурмбаннфюрера СС Вернера фон Брауна лучше не гуглить, а то можно разрыв шаблона получить.

А вот я не понимаю смысла искать глубокие истоки там, где речь идет сугубо о практике.

Так-то разговаривая о прокладке электропроводки в комнате можно уйти к рассуждениям о вкладе условного Шарля де Кулона. Хотя следовало бы ограничиться моментами появления на рынке пассатижей с изолированными рукоятками.

Оки-доки. Пока зафиксируем:

1. Сложные типы вроде «корректный IP» ваша система типов в принципе не способно описать.
2. На простых численных типах она тоже лажает.

Сложные типы вроде «корректный IP» ваша система типов в принципе не способно описать. На простых численных типах она тоже лажает.

Ну это, я бы сказал, не совсем объективные факты, это твое отношение к объективным фактам.

ip адрес вообще я бы представлял в виде класса, т.к. там постоянно нужно в/из строку/и перегонять и всякие проверки на принадлежность к подсети, например, и т.п. Но если ты хочешь простой тип (фундаметальный), ок, можешь взять uint32_t (елси мы про ipv4).

Ты сейчас тоже про невозможность представления результата сложения двух ip адресов скажешь? Только вот при маршрутизации арифметическая операция сложения не применяется, там битовые операции используют. И вот бы лепота какая была бы, если бы там на каждую операцию проверки были, ой, как бы быстро все работало-то.

Если так, то давайте тогда к теории множеств обратимся

Если бы мы обсуждали «теоретические основы», тогда да, можно было бы обратиться. Но мы говорим о разработке алгоритмического подхода который изначально подходил к решению практической задачи - как передать сформированные(вычисленные) данные с одной машины на другую в виде объединения кода и данных.

Я рассказал о том что первым этим занялся Конрад Цузе на своих Z1-Z4, затем Алан Кей на Datatron/Burroughs и только потом уже PDP-1 в MIT. Вы это отрицаете. Ок. О чем дальше тут говорить? Видимо, из меня плохой «объяснятор» т.к. я видимо не сумел донести свою мысль.

А вот я не понимаю смысла искать глубокие истоки там, где речь идет сугубо о практике.

Не знающий историю обречен на ее повторение. Я не хочу скатываться в лавсановщину про 90% идиотов - это не так, но оглянитесь вокруг - мы живем в эру СДВГ в ИТ и балом правит синдром Даннинга-Крюгера. Этот форум лишь одно из отражений текущей плачевной ситуации.

Другими словами, вы либо пытаетесь разобраться в вопросе, либо свайпаете т.к. ролик длиннее 8 секунд.

Сложные типы вроде «корректный IP» ваша система типов в принципе не способно описать.

Я так и не понял, откуда взялось это утверждение. К примеру, я сейчас использую математическую библиотеку, и у неё есть не менее сложный тип Unit<Vector3>, для которого есть гарантия нормальности. Что с этим типом не так?

Если бы мы обсуждали «теоретические основы», тогда да, можно было бы обратиться.

Раз мы не обсуждаем теоритические основы, то зачем вы опускаетесь вплоть до 1930-х годов, когда ЭВМ как таковой не было. Механические вычислители на роль ЭВМ не годятся, уж простите.

Но мы говорим о разработке алгоритмического подхода который изначально подходил к решению практической задачи - как передать сформированные(вычисленные) данные с одной машины на другую в виде объединения кода и данных.

История показывает, что это прекрасно делается посредством дырочек на перфоркатах и к ООП подобное объединение «кода и данных» не имеет отношения.

Не нравятся дырочки на перфоркартах – посмотрите на файловые системы на дискетах, например. Опять же к ООП это не имеет отношения.

Я рассказал о том что первым этим занялся Конрад Цузе на своих Z1-Z4, затем Алан Кей на Datatron/Burroughs и только потом уже PDP-1 в MIT. Вы это отрицаете. Ок.

Я это не отрицаю. Всего лишь говорю, что с точки зрения практики использования class-based OOP и prototype-based OOP столь глубокое погружение в историю не имеет смысла.

Раз мы не обсуждаем теоритические основы, то зачем вы опускаетесь вплоть до 1930-х годов, когда ЭВМ как таковой не было. Механические вычислители на роль ЭВМ не годятся, уж простите.

Вы считаете что механические вычислительные машины Z1-Z4 относятся к теории? 500кг чистой теории

Я это не отрицаю. Всего лишь говорю, что с точки зрения практики использования class-based OOP и prototype-based OOP столь глубокое погружение в историю не имеет смысла.

Изначально, я сказал что prototype-based появился раньше class-based. Вы попросили уточнить («А можно подробнее?»). Я уточнил рассказав о Конраде Цузе. На что вы заявили «Копаться в конспирологии и глубокой древности мне не интересно.». Все что я могу ответить на это - Ок.

Лечи кого-нибудь другого, я на Common Lisp 10 лет писал и прекрасно могу обходиться с динамической типизацией на практике. Равно как и на тикле писал. А сегодня так же спокойно пишу на Питоне. Даже на Окамле кое-как удаётся писать - там статическая типизация, но названия типов там, как правило, в исходнике отсутствуют. Без IDE, которая позволяет ткнуть в любое место и спросить «какого типа вот это?» писать на Окамле не нужно. При этом, естественно, написанная программа на окамле будет работать более надёжно, чем на Питоне. Да, линтеры в Питоне кое-что могут выводить, но поскольку это лишь линтеры, и стройной системы статической типизации там нет, они устраняют одни грабли и добавляют другие: ты веришь в аннотации типов, а они тебя обманывают. Однако я написал о том, какая польза от статической типизации. Да, она есть, невзирая на то, что ты там нафантазировал в своём виртуальном мире. То, что писатели на JS никогда не наступали на грабли из-за отсутствия в нём статической типизации - это сказка, которую хорошо рассказывать, но не мне. Возможно, они наступали не конкретно на 2+2=22, но на что-нибудь наступали обязательно. Ну если это конечно не Моцарты программирования. Но Моцартов единицы в столетие, они не делают рынок. Подводя итоги, тебе моё имхо не нужно, а мне твоё не нужно, равно как и твои возражения мне неинтересны, и я не буду даже тратить время на их чтение. До свидания.

А вы на языке, за который топите, так сможете?

Вроде что-то можно было в типизированных массивах. Только зачем, хз.

Это сложение по модулю, (100+200) mod 256 = 44

Как уже объяснял выше, такова природа процессора, он нативно умеет хранить/складывать целые числа только по модулю в зависимости от разрядной сетки операндов, поэтому и в Си точно так же.

Вы считаете что механические вычислительные машины Z1-Z4 относятся к теории?

Я считаю, что попытки отсылок возникновения prototype-based OOP к механическим вычислительным машинам Z1-Z4 – это теоретизирование чистой воды. С доказательствами из категории «может вы думаете, что американцы свою лунную программу сами осилили?»

Все что я могу ответить на это - Ок.

Ну так и я из ваших слов могу заключить разве что, что вы сумели найти разглядеть реализацию prototype-based OOP в Z1. И здесь остается разве что сказать: чего только людям не привидится.

Ну это вообще-то называется «воинствующее невежество».

Я считаю, что попытки отсылок возникновения prototype-based OOP к механическим вычислительным машинам Z1-Z4 – это теоретизирование чистой воды.

Z2 имела цифровой процессор на основе реле и электровакуумных ламп. 1940 год. Давайте наверное, закончим на этом. Слишком туго идут мои попытки что-то объяснить.

А есть ли преемственность между работами Цузе и английским «Колоссом»?

А ООП – это алгоритмический подход?

ООП - абсолютно алгоритмический! Причем не зависит от языка программирования. Можно на простои си и даже ассемблере делать ООП программы, потому что ООП сначала должно быть в голове и алгоритме.

А есть ли преемственность между работами Цузе и английским «Колоссом»?

Это мне неизвестно, я не так хорошо знаю историю как может показаться. Мое имхо - это сугубо английская разработка.

Ну это вообще-то называется «воинствующее невежество».

Да какие вообще проблемы?

Любой может нагуглить информацию о Simula67 и посмотреть, как выглядело class-based OOP в 1960-х.

Любой может нагуглить информацию о Self и посмотреть, как выглядело prototype-based OOP в 1980-х.

А вот рассмотреть prototype-based OOP в «программах» для Z1 могут не только лишь все.

Опровергнуть мое воинствующее невежество просто – дайте ссылку на какую-то «программу» для Z1, в которой будет видно применение этого самого prototype-based OOP.

Слишком туго идут мои попытки что-то объяснить.

А знаете почему? Потому что их нет.

Есть заявления из категории «верую»: вы верите в то, что идея prototype-based OOP появилась у Конрада Цузе, но потом она была украдена американцами и явлена миру лишь спустя 20 лет.