> P.P.S. Вообще весь топик вырос из дискуссии где мне пытались объяснить что я ничего не понимаю в программировании и моё нежелание мириться с подобными, с позволения сказать, языками программирования свидетельствует о моей серости и убогости, а не о проблемах в языке.
> Я собственно потому и выбрал этот пример. То, что абстракции в JavaScript «протекают» — не делает этому языку чести.
Да «нет» там массивов, это абстрактное выделение. Здесь инварианты не уместны вообще (а уж тем более в ключе — «основа ООП»), поскольку все объекты mutable, и каждый объект может перегруппироваться в «массив».
> С какой стати действия имеют отношения к объектам? Они должны объединять объекты, а не принадлежать им! Рассмотрим четыре объекта: плоттер, монитор, круг и квадрат.
Опять утверждение. Ок, давайте тогда мне ссылку на «бумагу с печатью», где Вы подобные утверждения выискиваете. Насчет draw — что мешает сделать 4 своих метода для каждого объекта?
Ой, если я скажу, что и массивов в JS нет (ну, или более точно, что он мало чем отличается от любого другого объекта) и что .length (не зависимо от количества и сущности ключей и элементов) может возвращать не то, что Вы ожидаете, это только подкрепит Вашу «веру»? :) А если и в Ruby, например, так?
> А что такое абстрактный тип данных? Это набор действий сохраняющий набор инвариантов.
Это просто совокупность свойств для обособления. При этом, действия — тоже свойства. Возможно, сами свойства будут понятны не всем (не всем языкам мира), тогда делаются действия (описанные на понятном, общедоговореном языке), которые возвращают свойства.
Вы, пожалуйста, добавляйте к своим утверждениям фразы «ИМХО», «мне кажется», «я думаю», «я в большом сомнении», «я фантазирую», «я предполагаю» и т.д. (выберите потом).
Чтобы говорить на языке утверждений — надо: 1) — знать фундаментальную теорию, 2) обязательно знать локальную теорию конкретной технологии и 3) быть готовым подкрепить все это практикой по первой просьбе. При этом Вы пытаетесь (кидаетесь фразами, демагогируете) оперировать 1), не думая о 2), но говоря и о 3), поскольку иначе — «дерьмо» :)
Инварианты можно рассматривать лишь, как усиление типизации. Но не основу ООП.
Т.е. все-таки неинтутивный для Вас результат каких-то вычислений заставляет Вас записывать что-то в «дерьмо», так? При этом завязано это лишь на Ваши привычки/непривычки, как Вы сами соглашаетесь, так?
Все остальное в тексте — очередная бессмысленная демагогия. Я прошу Вас — не стоит утруждаться, я демагогию очень тонко чувствую и вижу. На всех остальных это тоже вряд ли повлияет. Поэтому не утруждайтесь, я уже понял стратегический принцип построения Ваших фраз. Половин я отсеиваю, поскольку смысловой нагрузки в них нет.
> Если вы в дизайне языка не учитываете тот факт, что человек делает ошибки — то вас следуют переквалифицировать в дворники.
Следите за речью. Иначе мы закончим разговор. Еще раз — говорите по существу.
> Хотите чтобы я тут вставил несколько тысяч строк jQuery или Prototype?
Опять демагогия.
> Ерунда.
Мне кажется, Вы не цените ни мое, ни свое время. Следите за речью, исключите демагогию, говорите по существу. Я много Вашей ерунды опроверг, — что-то Вы просто затыкаетесь в этих моментах, но, тем не менее, позволяете себе попусту кидаться словами.
> Errare humanum est
Никто за это Вас не винит. Надо просто глубже разбираться в теории, далее, в теории конкретных технологий и подкреплять практикой.
> Чем типизация в Python'е, Comon Lisp'е или Scheme так принципиально отличается от того, что имеется в недоязыках типа PHP или JavaScript?
Я, как отмечал, поверхностно знаю Comon Lisp'е, со Scheme — не знаком. С Python'ом знаком, но сейчас его под рукой нет. Напишите примеры (те же самые, со строками, числами, и т.д.) — посмотрим, что там происходит.
> А в рамках существующей науки и существующих программистов (а не уникально-сферически-непогрешных)
Спасибо, я «оценил» :)
> JavaScript и PHP — дерьмо.
Демагогия. Фальшь.
> И это не демагогия, а медицинский факт — подтверждается и теорией и практикой.
Усиленная демагогия, рассчитанная на то, что особо никто разбираться в этом трепе не будет.
> Ну если считать что половина математики и почти вся информатика
Туда же относится. Какая «половина математики» какая «вся информатика»? Хотите оперировать фундаментальными понятиями — учитывайте все факторы (на каких множествах происходят операции, есть ли оговорки и т.д.). Если технология делает оговорки и однозначность (типологическая) множества может варьировать — соответственно и отклонения в операциях так же будут присутствовать. А то, что их кто-то не понимает (или не желает понимать? :)) — дело десятое.
> Я всегда считал что объект — это как минимум набор инвариантов, связывающих биты, хранящиеся в этом объекте.
Примеры в студию. Инварианты — лишь часть (малая часть!) объектов и классов, чтобы ограничить объекты (да, я понял, инвариация Вас притягивает все из-за той же строгой типизации, вернее, вытекает, как следствие ).
> Если для вас объект что-то другое — скажите что.
Объетк — абстрактное представление (возможно физическое), что обладает своими свойствами. Применительно к программированию — всего лишь абстрактный тип данных, не более. (ага, инвариация — основа ООП :) простите, но это не так.)
> Если вы не можете даже сформулировать что такое объект — то о чём мы тут говорим?
Демагогия. Я в который раз отмечаю, что большая часть Вашего текста, демагогически направлена на личность (в данном случае мою). При этом, в реале — это не так. Говорите о предмете.
> Найти язык с худшим дизайном чем ранний JavaScript не так-то просто…
Демагогия.
К черту ранний JavaScript. Я Вам говорю о вполне адекватном понятии — «эволюция систем».
Что в нынешних версиях JS «дерьмового» кроме Ваших локальный привычек к строго типизации, кроме того, что Вы запутались в ==, ===, < и > и кроме того, что в каких-то реализациях вы не имеете __proto__ (хотя, стандарт говорит, что доступ к прототипу может быть дан в реализации)?
Что такое? Это полный субъективизм, выработанный привычкой к конкретной технологии. То, что не получается увидеть знакомое и калькировать в другой технологии, не дает Вам права называть что-то ненормальной работой.
> Дык эта, мы, в общем-то, про примеси говорим.
Дык, эта… :) Я Вам про них и говорю. Покажите мне точные алгоритмы примесей (и бумагу, где с печатью Всевышним написано «примеси реализуются так и не иначе» :)). Я Вам привел примеры реализаций.
> Да легко
И что легко? Не интуитивно? И кто Вас строки в ожидании чисел просит сравнивать? Приводите все к числам и сравнивайте. Перед этим почитайте об алгоритмах приведения и о том, как в данной технологии работаю операторы ==, ===, <, >.
Я понимаю, что Вы привыкли к строгой типизации. Здесь не так. Здесь не строгая динамическая. И работа вышеприведенных операторов — плата за это.
> с ужасом под названием JavaScript взвоют и проклянут таких улучшателей. Увы — в этом месте JavaScript дерьмом родился — дерьмом и умрёт (если умрёт). Ничего уже не поделаешь…
Демагогия. Фальшь.
> Разве что отказаться от идиотской идеи автоматического преобразования типов…
> Что его тогда отличает от ассоциативного массива, если у него никаких инвариантов нет?
Вы интересуетесь? Или даете мне помыслить, чтобы я пришел к какому-то ответу, который Вы, якобы, знаете?
Я отвечу: все эти понятия сверх-абстрактные и теоретические. Физически может вообще ничего не отличаться. Четких рамок вообще нет. Терминология — размыта, реализации — еще больше.
Поэтому объект от ассоциативного массива (который является лишь теоретической структурой данных; как, собственно, и объект) может ничем не отличаться.
> но это ж кем надо быть чтобы такие чудеса в язык вообще засунуть? Правильно: человеком, который разрабатывает не язык программирования, а так — поделку на скорую руку и у которого сроки поджимают…
Опять — почему? Возможно, в той версии, объект arguments был связующим звеном (я не в курсе, и спецификацию для 1.2 не читал).
> Правильно:
Да не правильно. Как реализовали, так — задумали. То, что Вы где-то увидели другое, вовсе не означает, что должно быть так же здесь.
Потом поправили, поскольку — снова, решили, что идеологически и технологически — так вернее. Это есть эволюция системы.
Да ладно, любой язык (любое творение) эволюционирует и развивается. Сейчас 1.5 / 1.6 / 1.7.
> если программа у вас не совсем тривиальна то сравнение переменных разных типов обозначает что вы что-то перепутали
Я не пойму, Вы как-то за меня, зачем-то, говорите, пытаясь приписать мне то, чего нет :) Говорите за себя. С чего бы это значило (да еще и в таком утвердительном ключе :)), что я что-то перепутал? Если Вы что-то перепутали (и привыкли к строгой типизации), это же не означает, что все остальные тоже перепутали, так? Или не так? :)
> iostream — просто умеет делать и то и другое.… хочется чтобы после доваление метода readline() в istream и writeln() в ostream они появились автоматом и в iostream()!
ах, вы об этом; все завесит от реализаций, и, смотря, в каком отношении изначально был iostream по отношению к istream и ostream. И что, что он «умеет делать и то и другое»? Главный вопрос в том, как это реализовано. Может там и было накопировано из обоих сущностей (так тогда и копируйте), если is и os были подмешены (пронаследованы) к ios, то это уже другая реализация.
> Но нет же! Вполне может быть так что a==b, b==c, но a!=c. Что за @!@^*#)(*!? А когда у вас a<b, b<c, но c<a — то что можно о таком языке сказать? Правильно: ничего хорошего.
Покажите мне примеры без NaN'ов, без сравнений {} и {} в JavaScript. Вероятно, все будет объяснимо, можно будет и в стандарте уточнить.
> Просто вся парадигма ООП построена на том что у объекта сохраняется некоторый набор инвариантов (иначе чем он отличается от простого ассоциативного массива?). Когда в этот механизм «грубо вмешиваются» создавая копию — получается маразм.
Почему? И почему обязательно объект обязательно должен иметь инваринты (да еще и для того, как Вы пишите, чтобы подпадать под парадигму ООП)?
А что Вы хотели показать и что ожидали увидеть? И формальные параметры и локальный var'ы (и function declaration) попадают в Variable (в новой редакции Environment) object. При этом одноименные var'ы и цифровые обращения к arguments взаимозаменяемы.
> Вы наверное не имели опыта работы с низкоуровневыми языками. Просто многие вещи становятся очевидными почему реализовано так, а не так.
Хорошо, хоть вы слово «наверное» вставляете. Я в курсе, почему передаются объекты по ссылке (кстати, понятие «ссылка» может означать в разных реализациях разное). Я лишь саркастически спрашиваю, «кто сказал, что должно быть так и не иначе»? Если какая-то реализация захочет сделать новую вещь, и это технологически и идеологически будет обосновано — там ресурсы будут второстепенны. Вы думаете Self в штыки не восприняли поначалу (под предлогом «Вы что, с ума сошли?! Столько памяти жрать?!»). Тем не менее.
Отвечая Вам: я знаю, почему объекты передаются по ссылке (при этом, повторю, понятие «ссылка» физически может содержать не то, что есть в Си или Асме; к примеру, JavaScript. Какая вам там ссылка из Си? Там внутренний тип Reference, который является объектом (в свою очередь, этот объект содержит базу и имя слота)). И — у меня был опыт с низкоуровневыми языками (смотря, что еще вы называете низкоуровневым, Асм — тоже высокуровневый, относительно hex-кодов).
Ну вот и снова пустая демагогия.
Да «нет» там массивов, это абстрактное выделение. Здесь инварианты не уместны вообще (а уж тем более в ключе — «основа ООП»), поскольку все объекты mutable, и каждый объект может перегруппироваться в «массив».
> С какой стати действия имеют отношения к объектам? Они должны объединять объекты, а не принадлежать им! Рассмотрим четыре объекта: плоттер, монитор, круг и квадрат.
Опять утверждение. Ок, давайте тогда мне ссылку на «бумагу с печатью», где Вы подобные утверждения выискиваете. Насчет draw — что мешает сделать 4 своих метода для каждого объекта?
Почитайте особенно пункт 3 и ниже, и все станет ясно.
> А сейчас замутим опрос :-) Посмотрим что скажет народ…
Только вы народу предисловие потом не забудьте показать, а не просто абстрактную фразу напишите :) Да, и пример, конечно.
P.S> я через 40 минут уезжаю, до инета доберусь через день, так что, если что — отвечу позже.
> А что такое абстрактный тип данных? Это набор действий сохраняющий набор инвариантов.
Это просто совокупность свойств для обособления. При этом, действия — тоже свойства. Возможно, сами свойства будут понятны не всем (не всем языкам мира), тогда делаются действия (описанные на понятном, общедоговореном языке), которые возвращают свойства.
Вы, пожалуйста, добавляйте к своим утверждениям фразы «ИМХО», «мне кажется», «я думаю», «я в большом сомнении», «я фантазирую», «я предполагаю» и т.д. (выберите потом).
Чтобы говорить на языке утверждений — надо: 1) — знать фундаментальную теорию, 2) обязательно знать локальную теорию конкретной технологии и 3) быть готовым подкрепить все это практикой по первой просьбе. При этом Вы пытаетесь (кидаетесь фразами, демагогируете) оперировать 1), не думая о 2), но говоря и о 3), поскольку иначе — «дерьмо» :)
Инварианты можно рассматривать лишь, как усиление типизации. Но не основу ООП.
Т.е. все-таки неинтутивный для Вас результат каких-то вычислений заставляет Вас записывать что-то в «дерьмо», так? При этом завязано это лишь на Ваши привычки/непривычки, как Вы сами соглашаетесь, так?
Все остальное в тексте — очередная бессмысленная демагогия. Я прошу Вас — не стоит утруждаться, я демагогию очень тонко чувствую и вижу. На всех остальных это тоже вряд ли повлияет. Поэтому не утруждайтесь, я уже понял стратегический принцип построения Ваших фраз. Половин я отсеиваю, поскольку смысловой нагрузки в них нет.
Следите за речью. Иначе мы закончим разговор. Еще раз — говорите по существу.
> Хотите чтобы я тут вставил несколько тысяч строк jQuery или Prototype?
Опять демагогия.
> Ерунда.
Мне кажется, Вы не цените ни мое, ни свое время. Следите за речью, исключите демагогию, говорите по существу. Я много Вашей ерунды опроверг, — что-то Вы просто затыкаетесь в этих моментах, но, тем не менее, позволяете себе попусту кидаться словами.
> Errare humanum est
Никто за это Вас не винит. Надо просто глубже разбираться в теории, далее, в теории конкретных технологий и подкреплять практикой.
> Чем типизация в Python'е, Comon Lisp'е или Scheme так принципиально отличается от того, что имеется в недоязыках типа PHP или JavaScript?
Я, как отмечал, поверхностно знаю Comon Lisp'е, со Scheme — не знаком. С Python'ом знаком, но сейчас его под рукой нет. Напишите примеры (те же самые, со строками, числами, и т.д.) — посмотрим, что там происходит.
> А в рамках существующей науки и существующих программистов (а не уникально-сферически-непогрешных)
Спасибо, я «оценил» :)
> JavaScript и PHP — дерьмо.
Демагогия. Фальшь.
> И это не демагогия, а медицинский факт — подтверждается и теорией и практикой.
Усиленная демагогия, рассчитанная на то, что особо никто разбираться в этом трепе не будет.
> Ну если считать что половина математики и почти вся информатика
Туда же относится. Какая «половина математики» какая «вся информатика»? Хотите оперировать фундаментальными понятиями — учитывайте все факторы (на каких множествах происходят операции, есть ли оговорки и т.д.). Если технология делает оговорки и однозначность (типологическая) множества может варьировать — соответственно и отклонения в операциях так же будут присутствовать. А то, что их кто-то не понимает (или не желает понимать? :)) — дело десятое.
Не технологии дерьмо :)
Примеры в студию. Инварианты — лишь часть (малая часть!) объектов и классов, чтобы ограничить объекты (да, я понял, инвариация Вас притягивает все из-за той же строгой типизации, вернее, вытекает, как следствие ).
> Если для вас объект что-то другое — скажите что.
Объетк — абстрактное представление (возможно физическое), что обладает своими свойствами. Применительно к программированию — всего лишь абстрактный тип данных, не более. (ага, инвариация — основа ООП :) простите, но это не так.)
> Если вы не можете даже сформулировать что такое объект — то о чём мы тут говорим?
Демагогия. Я в который раз отмечаю, что большая часть Вашего текста, демагогически направлена на личность (в данном случае мою). При этом, в реале — это не так. Говорите о предмете.
Демагогия.
К черту ранний JavaScript. Я Вам говорю о вполне адекватном понятии — «эволюция систем».
Что в нынешних версиях JS «дерьмового» кроме Ваших локальный привычек к строго типизации, кроме того, что Вы запутались в ==, ===, < и > и кроме того, что в каких-то реализациях вы не имеете __proto__ (хотя, стандарт говорит, что доступ к прототипу может быть дан в реализации)?
И пример не приводите.
> при нормальной работе
Что такое? Это полный субъективизм, выработанный привычкой к конкретной технологии. То, что не получается увидеть знакомое и калькировать в другой технологии, не дает Вам права называть что-то ненормальной работой.
> Дык эта, мы, в общем-то, про примеси говорим.
Дык, эта… :) Я Вам про них и говорю. Покажите мне точные алгоритмы примесей (и бумагу, где с печатью Всевышним написано «примеси реализуются так и не иначе» :)). Я Вам привел примеры реализаций.
> Да легко
И что легко? Не интуитивно? И кто Вас строки в ожидании чисел просит сравнивать? Приводите все к числам и сравнивайте. Перед этим почитайте об алгоритмах приведения и о том, как в данной технологии работаю операторы ==, ===, <, >.
Я понимаю, что Вы привыкли к строгой типизации. Здесь не так. Здесь не строгая динамическая. И работа вышеприведенных операторов — плата за это.
> с ужасом под названием JavaScript взвоют и проклянут таких улучшателей. Увы — в этом месте JavaScript дерьмом родился — дерьмом и умрёт (если умрёт). Ничего уже не поделаешь…
Демагогия. Фальшь.
> Разве что отказаться от идиотской идеи автоматического преобразования типов…
Локальная привычка. Мысль в локальной идеологии.
а Вы решили, что я буду понтоваться чем-то? :)
Вы интересуетесь? Или даете мне помыслить, чтобы я пришел к какому-то ответу, который Вы, якобы, знаете?
Я отвечу: все эти понятия сверх-абстрактные и теоретические. Физически может вообще ничего не отличаться. Четких рамок вообще нет. Терминология — размыта, реализации — еще больше.
Поэтому объект от ассоциативного массива (который является лишь теоретической структурой данных; как, собственно, и объект) может ничем не отличаться.
Опять — почему? Возможно, в той версии, объект arguments был связующим звеном (я не в курсе, и спецификацию для 1.2 не читал).
> Правильно:
Да не правильно. Как реализовали, так — задумали. То, что Вы где-то увидели другое, вовсе не означает, что должно быть так же здесь.
Потом поправили, поскольку — снова, решили, что идеологически и технологически — так вернее. Это есть эволюция системы.
Да ладно, любой язык (любое творение) эволюционирует и развивается. Сейчас 1.5 / 1.6 / 1.7.
> если программа у вас не совсем тривиальна то сравнение переменных разных типов обозначает что вы что-то перепутали
Я не пойму, Вы как-то за меня, зачем-то, говорите, пытаясь приписать мне то, чего нет :) Говорите за себя. С чего бы это значило (да еще и в таком утвердительном ключе :)), что я что-то перепутал? Если Вы что-то перепутали (и привыкли к строгой типизации), это же не означает, что все остальные тоже перепутали, так? Или не так? :)
> iostream — просто умеет делать и то и другое.… хочется чтобы после доваление метода readline() в istream и writeln() в ostream они появились автоматом и в iostream()!
ах, вы об этом; все завесит от реализаций, и, смотря, в каком отношении изначально был iostream по отношению к istream и ostream. И что, что он «умеет делать и то и другое»? Главный вопрос в том, как это реализовано. Может там и было накопировано из обоих сущностей (так тогда и копируйте), если is и os были подмешены (пронаследованы) к ios, то это уже другая реализация.
> Но нет же! Вполне может быть так что a==b, b==c, но a!=c. Что за @!@^*#)(*!? А когда у вас a<b, b<c, но c<a — то что можно о таком языке сказать? Правильно: ничего хорошего.
Покажите мне примеры без NaN'ов, без сравнений {} и {} в JavaScript. Вероятно, все будет объяснимо, можно будет и в стандарте уточнить.
Почему? И почему обязательно объект обязательно должен иметь инваринты (да еще и для того, как Вы пишите, чтобы подпадать под парадигму ООП)?
А что Вы хотели показать и что ожидали увидеть? И формальные параметры и локальный var'ы (и function declaration) попадают в Variable (в новой редакции Environment) object. При этом одноименные var'ы и цифровые обращения к arguments взаимозаменяемы.
Хорошо, хоть вы слово «наверное» вставляете. Я в курсе, почему передаются объекты по ссылке (кстати, понятие «ссылка» может означать в разных реализациях разное). Я лишь саркастически спрашиваю, «кто сказал, что должно быть так и не иначе»? Если какая-то реализация захочет сделать новую вещь, и это технологически и идеологически будет обосновано — там ресурсы будут второстепенны. Вы думаете Self в штыки не восприняли поначалу (под предлогом «Вы что, с ума сошли?! Столько памяти жрать?!»). Тем не менее.
Отвечая Вам: я знаю, почему объекты передаются по ссылке (при этом, повторю, понятие «ссылка» физически может содержать не то, что есть в Си или Асме; к примеру, JavaScript. Какая вам там ссылка из Си? Там внутренний тип Reference, который является объектом (в свою очередь, этот объект содержит базу и имя слота)). И — у меня был опыт с низкоуровневыми языками (смотря, что еще вы называете низкоуровневым, Асм — тоже высокуровневый, относительно hex-кодов).