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

Для утиной типизации основной смысл такой: ести плавает как утка, крякает как утка, значит это, наверное, утка. Т.е. идентификация по свойствам, фактически.

это частный случай сложения

Да с этим я не спорю, я спрашиваю, что такое нечеткая типизация.

А еще рюкзак внезапно - СОБИРАЮТ и УКЛАДЫВАЮ

молодец. И что дальше?

Но с темы съехал лихо, про ЯП он не говори, так какого ты сюда приперся, зеленый?

тоже обиженный? Ну зарегся, и заигнорь меня. Или иди жаловаться модераторам, пусть в правила пункт внесут, что «зелёным нельзя».

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

Для утиной типизации основной смысл такой: ести плавает как утка, крякает как утка, значит это, наверное, утка. Т.е. идентификация по свойствам, фактически.

я в курсе. Проблема в том, что как ты называешь утку — не играет роли. Роль играют свойства утки. Вот например staseg полагает, что «сложение всегда коммутативно», что приводит естественно к фэйлам, если это правило ломается. Вот он и не желает допускать того, что-бы его шаблон треснул, и какой-то emulek вдруг взял, и стал складывать строки.

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

что такое нечеткая типизация

это когда есть нечёткая система преобразования типов. Вроде как в php. Или в сишечке для базовых типов. Т.е. такая система, которая выбрана произвольно.

В отличие от этого, чоткая(дерзкая) система типов — это в C++. Там, если ты напишешь A+B, компилятор обзовёт тебя мудаком, и откажется компилировать, пока ты не соизволишь рассказать, что такое A::operator+(const &B).

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

Нормальный - это в смысле глупый?

Роль играют свойства утки.

Все верно, яоб этом и говорил в топике, если нам нужно от объекта в данный момент только «кря», нам вообще до п*ды, утка это или нет, это и есть гибкость ЯП, а типы мешают нам это сделать. В твоем примере, результат конкатенции мы могли бы интерпретировать и как строку и как число, в зависимости от нужд, но твоя хваленая сишечка бьет тебя по рукам за такое. А еще говорят, что си дает большую свободу программисту. Где тут свобода, если, мало того, приходится подстраиваться под систему типов, да еще и декларировать их явно. Чуть ли не хаскель получается, свобода, мля, да.

это когда есть нечёткая система преобразования типов.

ЯННП. Чем отличается

система преобразования типов

от твоей

нечёткая система преобразования типов

в чем нечеткость?

В отличие от этого, чоткая(дерзкая) система типов — это в C++. Там, если ты напишешь A+B, компилятор обзовёт тебя мудаком, и откажется компилировать, пока ты не соизволишь рассказать, что такое A::operator+(const &B).

Вместо истории об операторе компилятор устроит и сказка о легендарных «Конструкторах С Одним Аргументом Без Explicit». Если ему удастся подобрать цепочку из приведений типов, то он без проблем вызовет какой-нибудь operator+().

И вообще, это вроде бы называлось строгой/слабой типизацией.

Все, разобрался. Это ты что-то по-ходу попутал. Это то же самое, что и утиная. И она - частный случай динамической. Значит если в сишке это есть - значит разруливание происходит в рантайме компиляции.

http://ru.wikipedia.org/wiki/Утиная_типизация

Неявная типизация, латентная типизация или утиная типизация

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

Нормальный - это в смысле глупый?

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

Все верно, яоб этом и говорил в топике, если нам нужно от объекта в данный момент только «кря», нам вообще до п*ды, утка это или нет, это и есть гибкость ЯП, а типы мешают нам это сделать

проблема как раз в том и заключается, что «только кря» нужно исключительно в хэлловорлде. И в нём — да, типы только мешают. Но чем дальше ты отходишь от хэлловорлда, тем лучше ты понимаешь, что отсутствие типов только мешает, а никак не помогает.

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

нет, не бьёт. Сделай свою иерархию типов, как в пхп или как в баше. C++ это позволяет. Т.е. делаешь тип «NIL», и от него наследуешь все остальные типы. Строки, целые, и т.п. Коллекции можешь делать [], этот оператор тоже можно перезагрузить в C++.

Где тут свобода, если, мало того, приходится подстраиваться под систему типов, да еще и декларировать их явно

декларировать — да, надо. Но подстраиваться почти не нужно. («почти» например потому, что ты не можешь сделать например двухместную операцию ~, она всегда одноместная. Ну и ещё некоторые тонкости)

дай угадаю: php?

Любой приличный язык. В похапе плохо то, что словарь и списки — одна и та же сущность.

в чем нечеткость?

в том, что правила в нечёткой задаются от балды, и в них нет никакой логики. Ну например php преобразует "2" + "2" в числа(и даёт 4), а какой-нить другой ЯП выдаст тебе 22. Спорить, какой ЯП из этих двух лучше — бессмысленно. Оба говно.

Ну например php преобразует «2» + «2»

где ты тут нелогичность увидел? eval(«2»)===2. Привет старый лисп.

php

https://bugs.php.net/bug.php?id=54547 ☺

Евал в лиспе евалит не строки, а списки. Чтобы из строки получить список, используется сущность по имени reader.

а какой-нить другой ЯП выдаст тебе 22

С этой точки зрения, этопроблемы сахара. Я тоже против. Автор языка тут решил за тебя, как в общем случае должно интерпретироваться выражение. Я согласен, что это зло. Но это не имеет никакого отношения к тезису «все есть строка»(или список символов - пох)

Угадал автора по заголовку

Евал в лиспе евалит не строки, а списки. Чтобы из строки получить список, используется сущность по имени reader.

Да, это в современных мейнстримных лиспах. Это и привело к тому что выразительность их стала сравнима с каким нибудь С++. Раньше было не так.

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

ну это уж твоя проблема. Зачем ты делал эти приведения? Что-бы потом удивляться, что компилятор ими пользуется? Делай make функции, компилятор их не будет втыкать куда не следует.

И вообще, это вроде бы называлось строгой/слабой типизацией.

да. Но в C++ именно «чоткая/дерзкая», правила ты сам определяешь, как хочешь.

Раньше было не так.

[Источник?]

Можно глянуть Lisp1.5 user manual. Я че то там не помню никаких ридеров. Там код - это дата, в прямом смысле.

Значит если в сишке это есть - значит разруливание происходит в рантайме компиляции.

ну её нет, но ты можешь сделать. Говорю же: делай иерархию классов, а потом разруливай dynamic_cast'ом, если тебе оно надо именно в рантайме. Т.е. если ты попытаешься заставить крякать ворону, то получишь либо исключение(если это ссылка), либо нулевой указатель.

Но в C++ это вовсе не единственное решение. Это один из вариантов.

строгой/слабой типизацией.
Но в C++ именно «чоткая/дерзкая»

Ты ж говорил о явной/неявной. Соскакиваешь?:)

Любой приличный язык. В похапе плохо то, что словарь и списки — одна и та же сущность.

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

Ну например php преобразует «2» + «2»

где ты тут нелогичность увидел?

почему не «22»?

https://bugs.php.net/bug.php?id=54547 ☺

значит я угадал, да? (:

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

Если в языке нет структур данных, в API каждой библиотеки будут собственные словари и списки, это нехорошо.

Автор языка тут решил за тебя, как в общем случае должно интерпретироваться выражение. Я согласен, что это зло. Но это не имеет никакого отношения к тезису «все есть строка»(или список символов - пох)

это имеет самое прямое значение:

1. всё есть строка?

2. как считать 2+2?

3.1. надо преобразовать строки в числа

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

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

Моё мнение — ошибка в первом пункте. Преобразование типов == в 95% случаев ненужные костыли. А для 5% как раз и нужно использовать именно КОСТЫЛИ.

почему не «22»?

22 - это будет конкатенация. Все зависит от того, что автор языка определил, какое поведение данного оператора со строками. И это еще не самый хреновый вариант. Хуже, когда два выражения:

«2»+2

и

2+«2»

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

как считать

Как захочешь САМ. Разница между САМ и Автор_ЯП, надеюсь понятна?

Ты ж говорил о явной/неявной. Соскакиваешь?

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

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

по той простой причине, что их более одного. Т.е. например список бывает двусвязный, а бывает односвязный. Бывает циклический, а бывает с началом и с концом. Предлагаешь ввести в каждый ЯП по 4 вида разных списков? Ну хорошо, ладно. А что делать с Over9000 видами коллекций key=value?

Если в языке нет структур данных, в API каждой библиотеки будут собственные словари и списки, это нехорошо.

что мешает юзать одну и ту же? Как например STL? Если мне наплевать на всё, и надо просто написать cout<<"привет";, то почему-бы так и не сделать?

22 - это будет конкатенация. Все зависит от того, что автор языка определил, какое поведение данного оператора со строками.

ну я и говорю — от балды.

«2»+2 и 2+«2» имеют разный результат.

угу.

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

дык как мне получить 4 из 2+2? Если сабж??

Рюкзак + бутерброд

с какого перепуга? Школьник что-ли, и ничего кроме арифметики не знаешь? Ну дык ВНЕЗАПНО ты, школьник, ещё и рюкзак свой СКЛАДЫВАЕШЬ, или это по твоему «не сложение»?

Ок, раз мы придираемся к словам, идем еще дальше. Знак «+» обозначает математическую операцию сложения (и еще всякое-разное, не относящееся к теме). И да, рюкзак я «наполняю», числа «складываю», а строки — «объединяю» и «удлиняю».

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

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

а про языки я ничего и не говорил

Ах, ну тогда вообще разговор не имеет смысла, раз речь не о ЯП, а о разном толковании слов.

Как захочешь САМ. Разница между САМ и Автор_ЯП, надеюсь понятна?

нет, непонятна. В пхп есть правило: «всё есть число», а в каком-нить баше «всё есть строка». И там и там нужны хитромудрые костыли. Ну к примеру, в php рекомендуют сравнивать строки так: strcmp($s1, $s2)==0, ибо обычное $s1 == $s2 работает через жопу. Это по твоему «хорошо»? В других ЯП тоже есть аналогичные проблемы.

И таких говноязыков напридумали уже Over9000, хочешь ещё один сделать? Ну дерзай...

дык как мне получить 4 из

В «идеальных» языках както так:

(+ (eval '2) (eval '2)) или eval(«+»)eval(«2»)eval(«2») или concat(eval «2 + 2»).

Делай обвязки какие хочешь, вроде: for-each(lambda(x f) (f (eval x)))

В пхп есть правило: «всё есть число», а в каком-нить баше «всё есть строка»

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

Знак «+» обозначает математическую операцию сложения

ох... ПОЧЕМУ? В каких скрижалях ты это прочитал? Знак «+» обозначает только то, что мы задали и определили. Для чисел — да, сложение. Да и то не всегда. (указатели в сишке тоже числа, но их сумма эквивалентна делению на ноль)

С какого перепуга ты переносишь свойства «+» от натуральных чисел на строки? По твоему получается, что строки можно СКЛАДЫВАТЬ, но писать + почему-то нельзя. Почему нет?

И да, рюкзак я «наполняю», числа «складываю», а строки — «объединяю» и «удлиняю».

Угу. А пенис ты «периодично перемещаешь между половыми губами с целью эякуляции». А все остальные — идиоты, и просто трахаются.

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

потому что других нет. См. сабж.

Ах, ну тогда вообще разговор не имеет смысла, раз речь не о ЯП, а о разном толковании слов.

ага. А если мы всё же о ЯП, то тогда конкретизируй — о каком.

что мешает юзать одну и ту же? Как например STL?

Стандартная библиотека шаблонов потому и называется стандартной, потому что фактически она часть языка.

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

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

А ты забыл, что нюникс — операционная система, а не ЯП, и администрирование ОС не очень похоже на разработку ПО.

(+ (eval '2) (eval '2)) или eval(«+»)eval(«2»)eval(«2») или concat(eval «2 + 2»).

эти все записи не имеют никакого смысла, до тех пор, пока ты не объяснишь значения и свойства этих «2» и «+».

В пхп есть правило: «всё есть число», а в каком-нить баше «всё есть строка»

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

строки тут нужны лишь потому, что они никогда не меняются и инвариантны. Но если ты сделаешь всё в строках, то получится bash. Который люто тормозит. ИЧСХ, даже при операциях со строками. Попробуй например посчитать расстояние Левенштейна на bash, и сравни с любой реализацией на нормальном ЯП. А ведь это — типичная задача обработки строк.

Стандартная библиотека шаблонов потому и называется стандартной, потому что фактически она часть языка.

да. Но ничто не мешает тебе сделать свою коллекцию, если это нужно. А вот в питоне/пхп — увы. Жри что дают.

Насчёт пхп не знаю, но в питоне можно написать свою коллекцию. Причём такую, что будет работать list comprehension, map и прочие виды итерации, поскольку новая коллекция будет крякать как стандартная.

дык как мне получить 4 из 2+2? Если сабж??

BTW, для того чтоб получить это, тебе не нужна ни арифметика, ни числа, ни даже конкатенация (как сахар):

(define two '(()()))
(define get-num
  (lambda(l1 l2)
    (cond
      ((null? l1) '())
      (#t (cons (car l1) (cons (car l2) (get-num (cdr l1) l2)))))))
(define is-four (lambda(lst) (if (equal? lst '(()()()())) 'four 'false)))

(write (is-four (get-num two two)))


;--->four

Многие интерпретируемые ЯП, нпример тот же шелл, перл, декларируют красивый лозунг

bash — интерпретируемый
perl — компилируемый

Не стоит способ трансляции путать с типизацией.

ох... ПОЧЕМУ?

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

С какого перепуга ты переносишь свойства «+» от натуральных чисел на строки? По твоему получается, что строки можно СКЛАДЫВАТЬ, но писать + почему-то нельзя. Почему нет?

Потому что, как выявил наш анализ, значение слова «складывать» несколько шире традиционного толкования знака «+». Более того, это слово даже пытаются использовать там, где ему не место даже в повседневной жизни.

Угу. А пенис ты «периодично перемещаешь между половыми губами с целью эякуляции». А все остальные — идиоты, и просто трахаются.

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

потому что других нет. См. сабж.

Чего нет? Способов обозначить конкатенацию и сложение?

ага. А если мы всё же о ЯП, то тогда конкретизируй — о каком.

О любом, который перемешивает понятия сложения и конкатенации.

Ещё у одного похапе погромиста сорвало башню?

Да, всё жду, когда же в PHP разрешат в типах аргументов функций и методов указывать не только пользовательские классы, но и базовые типы :)

Причём такую, что будет работать list comprehension, map и прочие виды итерации, поскольку новая коллекция будет крякать как стандартная.

а как с производительностью? Мой шаблон для строк работает намного лучше «встроенной» std::string (потому что там нет ничего лишнего). С какой скоростью будет работать твоя левая коллекция в питоне?