Здравствуйте, Курилка, Вы писали:
К>тьфу, тут я запарил, там 2002 — первая новость (т.е. последняя, если читать "с конца") К>Последние этого года. (3 мая новую версию выкатили)
( В раздумьях ) Пощупать, что ли, Алису за тугое вымя ? На предмет новых фич, но в основном на предмет стабильности
К>Oz — другой язык, поэтому он не может "вместе существовать", а mozart — runtime система для него.
Ну как ! Это и есть сосуществование в советском смысле этого слова
К>Вот там чтот давно ничего не появлялось — год назад последний релиз был в июне прошлого года. К>Да и активности тож какой-то не видать
Я и говорю — помалу...На этом рантайме вроде бы какие-то другие языки собирались развивать — но ничего об этом пока не слышно
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>тьфу, тут я запарил, там 2002 — первая новость (т.е. последняя, если читать "с конца") К>>Последние этого года. (3 мая новую версию выкатили) G>( В раздумьях ) Пощупать, что ли, Алису за тугое вымя ? На предмет новых фич, но в основном на предмет стабильности
Вопрос вылезет — сильно ли многословней будет статическитипизированный вариант и насколько "лёгкая" там параллелизация. Было бы круто увидеть хотя бы какое-нибудь минимальное сравнение
Здравствуйте, Курилка, Вы писали:
К>Вопрос вылезет — сильно ли многословней будет статическитипизированный вариант и насколько "лёгкая" там параллелизация. Было бы круто увидеть хотя бы какое-нибудь минимальное сравнение
О компактности кода не скажу, а процессы, как утверждают на основании отдельных тестов, вполне сравнимы с ерланговскими. ( На небольшом количестве процессов )
Здравствуйте, gandalfgrey, Вы писали:
G>О компактности кода не скажу, а процессы, как утверждают на основании отдельных тестов, вполне сравнимы с ерланговскими. ( На небольшом количестве процессов )
Ну если так, то за счёт статической типизации можно получить ускорение на алгоритмах с "числодробительной" составляющей.
А где ты читал про "утверждают"?
Хотя небольшое количество — эт как-то "неспортивно", но вопрос — сколько именно?
Здравствуйте, gandalfgrey, Вы писали:
E>>То, что Flt генерируется при старте и затем в динамике выбирается версия, подходящая для определенных типов параметов, говорит лишь об удобстве ее использования и снижения трудозатрат на ее реализацию. В том же C++ можно делать аналогичные вещи, только они будут больше по объему. А вот степень надежности того и другого -- вопрос открытый.
G>При изменении структур данных ? Мне кажется, что убогая RTTI у ++ не позволит ничего подобного. Я же говорю о динамике типов — пока что в пределах сессии сервера, но никто не мешает нам сделать это в реалтайме. Все равно описания типов данных приходят извне.
Не очень понял, что понимается под изменением структуры данных.
Что до C++, то я сам делал реализацию фабрики объектов, которая использовала тип данных параметра метода create для определения типа создаваемого объекта. Причем типы объектов автоматически регистрировались в данной фабрике вместе с нужными им типами параметра во время работы программы. Что позволяло иметь разные наборы типов в фабрике при ручной загрузке/выгрузке DLL. И все это средствами штатного RTTI.
Нужно ли говорить, что существуют языки, та же Java, в которой при помощи рефлексии можно еще и не то делать.
G>Увеличение надежности здесь проявляется в том, что мы имеем всегда актуальный код для работы с разнородными данными, о котором НЕ надо заботиться : править его, переписывать...
Давайте разговаривать серьезно, все-таки.
Нельзя передать в программу объект совершенно произвольного типа и дожным образом его обработать. В программе должен быть код, который знает, что это за тип и что с ним делать. Соответственно этот код нужно править и переписывать.
Другое дело, что динамика легко позволяет во время работы системы догружать недостающие и просто новые фрагменты кода. Об этом здесь говорили.
E>>Я не думаю, что для подтверждения вашего тезиса о большей надежности динамически-типизированных программ над статически типизированными вообще нужно приводить фрагменты кода. Имхо, проще словами перечислить те факторы, которые по вашему мнению повышают надежность.
G>Динамическая типизация подразумевает возможность обработки прихода значений левого типа, и не на уровне исключений, а в рядовой логике функций.
Опять же, если в функции есть код, который знает, что делать с левым типом, то этот тип уже не левый. А поиметь такой код вполне можно динамической загрузкой кода в статически-типизированных языках.
E>>У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации. Действительно, C++ для сложной обработки данных сольет практически любому языку по объему кода, скорости его написания и времени на тестирования. Но все это имеет косвенное отношение к надежности.
G>Это все взамосвязанные вещи. Написав одну и ту же функциональность в несколько раз быстрее, чем на С++/Жаба/что-то еще, мы можем потратить больше времени на реализацию механизмов самовосстановления, к примеру
Я же и сказал, косвенное. На скорость разработки и на освобождение времени для других целей (в том числе и повышения надежности) влияет и множество других факторов: начиная от квалификации разработчика и имеющихся в наличии инструментов, заканчивая температурой воздуха в комнате в следствие нормальной/ненормальной работы кондиционера (или отсутствия оного).
Здесь найдутся несколько человек, которые совершенно серьезно будут утверждать, что Java+IDEA или C#+ReSharper позволяют им писать на статически-типизированном языке гораздо быстрее, чем на динамически-типизированном. И нет оснований им не верить. Так же как есть несколько человек, которые не менее серьезно будут говорить, что Ruby+VIM или Erlang+Emacs позволяют им писать быстрее, чем на статически типизированном языке. Люди таки разные.
Но к надежности, имхо, это не имеет прямого отношения. Гораздо важнее, является ли используемый язык сильно-типизированным или нет. Скажем отсутствие проблемы повисших указателей или прохода по чужой памяти может сделать программу на Ruby надежнее, чем C++. Но это отнюдь не аргумент в пользу надежности из-за динамики, т.к. Java или C# являются не менее сильно-типизированными.
G>Ну, порушить всю систему у нас сможет разве что сбой питания...Все остальное обработается корректно. Максимум, что мы можем потерять — текущий запрос от одного клиента. И даже если допустить, что мы внесли грубую ошибку в код прокси запросов — мы потеряем текущую сессию с клиентом. Которая, впрочем, тут же начнет восстанавливаться ( выкачивать актуальные справочные данныые и т.д. ).
Рад, что вы настолько уверенны в своей системе.
Хотя, основываясь на своем скромном опыте, мне это кажется в большей степени рекламным слоганом, ну или попыткой самоубеждения
E>>Так вот лично меня интересует ваше мнение по поводу того, как динамическая типизация обеспечивает большую надежность (именно в смысле сохранения программой работоспособности в непредвиденных условиях)?
G>Я бы выразился в том смысле, что это экспириенс, и не только мой личный, но и кучки знакомых разработчиков, которые используют языки с динамической типизацией для повышения надежности и живучести систем. Выделить какие-то формальные факторы, которые однозначно дают положительный эффект, я просто затрудняюсь — разве что их комплекс, причем разный для разных языков : для Ерланга один набор факторов, для Тикля другой и т.д.
У меня все сказанное вами оставляет впечатление, что вы говорите о большей надежности по сравнению с C++.
Тогда более правильно вести разговор о преимуществах сильной типизации (не важно, статической ли или динамической) перед слабой типизацией.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Я не думаю, что для подтверждения вашего тезиса о большей надежности динамически-типизированных программ над статически типизированными вообще нужно приводить фрагменты кода. Имхо, проще словами перечислить те факторы, которые по вашему мнению повышают надежность.
Есть примерно такие соображения про тип типизации:
Статическая типизация избавляет от ошибок типизации — это несомненный плюс.
Но она же заставляет согласовывать всё типы.
Т.е. Если мы в статическо-типизированном языке решили возвратить коллекцию, мы должны жестко зафиксировать тип этой коллекции. И согласовать с этим типом остальные интерфейсы.
Если потом, окажиться что выбранный тип коллекции нас не устраивает, мы становимся теред дилемой — либо добавлять в интерфейс нужный тип — и тем загрязнять его, либо менять старый тип на новый, что даже с поддержкой компилятора часто изрядно трудоёмко, как и любое нетривиальное изменение кода.
Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы.
Соответственно разработка обладает большей мобильностью.
Хотя, это вроде как призван решить вывод типов.
Насколько он это делает в том-же Haskell-е я не в курсе.
Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики.
P.S. Сейчас мы делаем проекты на Python + Qt.
Раньше на Delphi и С++
Пока, для нас, выигрышь очивиден.
Здравствуйте, Tonal-, Вы писали:
T>Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы. T>Соответственно разработка обладает большей мобильностью.
Опять же, речь не о мобильности, а о надежности.
Все же это разные вещи.
T>Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики.
Да ладно, стоит один раз нормально сделать , а потом использоваться без всяких заморочек.
T>P.S. Сейчас мы делаем проекты на Python + Qt. T>Раньше на Delphi и С++ T>Пока, для нас, выигрышь очивиден.
Я знаю об опытах перехода с Python+C++ на Java с не менее очевидным выигрышем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Mamut, Вы писали:
M>Извини Влад, но все это явный влейм и оффтоп.
Не хочется извинять.
M>
G>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
M>Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
M>Просьба ко всем не развязывать очередной флейм на эту тему.
M>Была просьба.
M>а) Пояснить, что имелось в виду M>б) Была просьба узнать мнение человека, который написал это M>в) Была просьба не развивать флейм
до более разумных. Понятие "надежность" потихоничку подменяется понятием "скорость разработки". Делается связь между надежностью исстемы и скоростью ее разработки. Тут уже есть о чем спорить. А исходная фраз — абстурд.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>А вот и примеры :
G>[code] G>% создает новый тупль по таблице имен и заполняет его полями G>fill_record_flds(Recname,Flds) when is_atom(Recname) -> G>... G>Кусочек очень простой, но он позволяет не держать в мозгу 2 РАЗНЫЕ функции, которые делают практически одно и тоже
Ну, а причем тут надежность то? Как ты понимашь этот термин?
Кстати, для сравки. Все тоже самое я могу делать на Nemerle с помощью макросов во время компиляции. Причем в отличии от тебя могу проконролировать надежноть произведя проверки еще во время компиляции и выдать соответствующую диагностику.
G>Варианты наращивались по мере усложнения системы, не затрагивая предыдущих случаев. То-есть ошибки привноситься в них просто НЕ могут
Ты говоришь о генерации кода. Она родимая никак не зависит от того является ли язык динамическим или нет. Я знаю людей которые генерируют C#-код из XML-описания на базе XSLT. Звучит как извращение, но по факту результат достигается такой же.
G>Есть и более сложные случаи, просто они несколько менее понятны с первого взгляда
Приводи, поглядим. Пока что ты твои примеры показвают, что ты весьма странно понимаешь термин "надежность".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>О том и речь ! Я не сравниваю со статической типизацией в Хаскеле — мне не нравится Хаскель, я на нем писал только маленькие примерчики, и не считаю себя достаточно компетентным для такового сравнения.
А не кажется ли тебе тогда, что если твоя компетенция в области статически-типизированных языков заканчивается на С++, то все же не стоит делать таких смелых заявлений по поводу надежности решений на динамических языках в сравнении с аналогами созданными на статических?
G> Жаба ? Я уже привел соотношение размеров кода — почти 2 порядка.
Ну, два порядка — это еще одно безответственное озаявление. Хотя согласен, что конечно код на динамическом языке с паттерн-мачингом по любому будет существенно меньше (если ваторы вменяемы).
Но прчем тут надежность? Больший по объему код еще не означет, что он мнее надежен. Ява — это типобезопасный язык, так что с точки зрения надежности решения будут идентичны (при одинаковом качестве рзработки и тестирования). Так что все упирается в грамотность проектирования и отладки. Соответственно все слова о приемуществе динамики не более чем заблуждения.
G> По оценкам писателей этой системы, во многом за счет статической типизации в Жабе
Эти слова уже вызвают сомнение в компетенции ваших Жабистов. Они просто не понимаю, что такое ФЯ и паттерн-мачинг, и насколько они согращают код реализации.
G>Немерль ? Я пока не считаю его пригодным для промышленного использования.
Ну, то что ты не считашь еще не значит, что это так на самом деле.
G>Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?
Скала еще. Ты конечно тоже что-то там не считашь. Это ясно.
Но вопрос то был не в том считаешь лыи ты какие-то языки зрелыми или нет. Вопрос был в заявлении о том, что якобы надежную систему можно создать только на динамике. Стало быть скажем на VB 1.0 надежную систему создать можно, а скажем на VB 9.0 или на C# 3.0 уже нельзя. Вот такие вот забавнешие выводы получаютя из твоих утверждений.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
E>>Object Pascal G>Мне это кажется несерьезным. Начиная с некоторого порога сложности системы начинается экспоненциальный рост сложности и обьема исходников.
На Дельфи создана масса сложнейших систем. И они уже давно работают. Уже этот факт подтверждает, что на ней точно можно это делать.
Тут разумно говорить о сложности разработки, а не о надежности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
до более разумных. Понятие "надежность" потихоничку подменяется понятием "скорость разработки". Делается связь между надежностью исстемы и скоростью ее разработки. Тут уже есть о чем спорить. А исходная фраз — абстурд.
Ну вот. В том-то все и дело. "Неосторожно брошенные слова".
M>>
G>>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
M>>Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
А ты серьезно хочешь получить обоснование для этого, брошенного в реламном пылу, лозунга?
Мужик просто заговорился. Со всеми бывает. Это конечно про то что касается надежных систем.
Флейм? Флейм.
А дальше головы полетели направо и налево:
EC>Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.
Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.
Причем тут фанатичность или хоть какой-то намек на логику таких осуждений (особенно в рамках просьбы к гандальфу), не понятно
И дальше топик скатился вообще непонятно куда (опять же к обсуждению статики и динамики). А казалось бы. Достаточно было дождаться ответа автора
Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить".
Все. И дальше можно обсуждать все, что угодно, применительно к проекту, создаваемому небольшим количеством человек, сложности и т.д. и т.п.
Хотя, например, не дождавшись ответа, eao197 осветил
то, что, как ему показалось, мог подразумевать gandalfgray. Причем информация там интересная. О таком аспекте я и не думал даже.
Более того, простой ответ в таком стиле:
Хм. Довольно спорное утверждение. Мой опыт показывает, что статика не только позволяет, но и помогает строить надежные системы. Быть может, автор это высказал в пылу спора или это как-то связано с его опытом в его проекте
А можно было ничего не писать Нетикет великая вещь (правда, сразу скажу, я сам не всегда ему следую)
E>У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации.
Имхо, главная мощь именно Эрланга, которая, возможно, имеет/не имеет отношения к чему-либо, будь то типизация или что иное, это его тривиальная сериализуемость и (частично как следствие, частично как причина) его тривиальная работа с сетью.
Будь в любом другом языке такое же, имхо, Эрланг курил бы в стороне и, возможно, вообще бы не появился
Возможность написать:
Pid ! {Любая, [структура, данных]}
это наигениальнейшая вещь.
Я как вспомню все эти пляски с бубном вокруг решений о том, что и как запаковывать/распаковывать и передавать по сети... Бррр.
Здравствуйте, Mamut, Вы писали:
E>>У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации.
M>Имхо, главная мощь именно Эрланга, которая, возможно, имеет/не имеет отношения к чему-либо, будь то типизация или что иное, это его тривиальная сериализуемость и (частично как следствие, частично как причина) его тривиальная работа с сетью.
M>Будь в любом другом языке такое же, имхо, Эрланг курил бы в стороне и, возможно, вообще бы не появился
M>Возможность написать: M>
M>Pid ! {Любая, [структура, данных]}
M>
M>это наигениальнейшая вещь.
M>Я как вспомню все эти пляски с бубном вокруг решений о том, что и как запаковывать/распаковывать и передавать по сети... Бррр.
Чесно говоря, восторг от возможности передачи сложных структур данных у меня очень быстро прошел в свое время. Из-за "проблемы второй версии"
M>Каким боком здесь динамика? А никаким
Если мне не отшибает память, то Sun когда-то давным давно приводила в качестве достоинства и конкурентного преимущества байт-кода Java что его можно легко передавать на удаленную сторону и исполнять там. Что, собственно, Java-апплеты и продемонстрировали. Хотя может я сейчас и не о том.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
EC>>И есть доказательство, что на динамически-типизированных ничего сложного создать нельзя?
VD>Важно то, что даже если на динамике можно создавать сложные приложения (т.е. я не прав в этом аспекте) — это никак не вылияет на возожность создавать сложные приложения на статике. Understand?
Это ты сейчас с кем споришь? Кто утверждал, что на статике создавать сложные приложения нельзя?
VD>Вообще это азы логики. Причем не какой-то там сложной матиматической, а примитивной человеческой логики. И мне казалось, что любой вменяемый человек должен это понимать.
После предыдущего пассажа это звучит особенно убедительно.
VD>В общем, извини, но разжевывание логики уровня детсада мне не нинтересно. Если ты тоже фанатик или просто не умешь мыслить логически, то это не ко мне. Для меня бредовость этого утверждения очевидно. И не только для меня.
Мощно.
Попробуй читать сообщение, на которое отвечаешь — сэкономишь кучу времени себе и другим подписчикам форума.
Я там вопрос задал максимально точно, зная любителей пофлеймить, причём человек его понял в отличие от...
Здравствуйте, eao197, Вы писали:
E>Чесно говоря, восторг от возможности передачи сложных структур данных у меня очень быстро прошел в свое время. Из-за "проблемы второй версии"
А конкретней? Где именно 2-я версия? Сообщений? Получателей?
M>>Каким боком здесь динамика? А никаким
Я думаю каким — типов сообщений у нас нет поэтому разбирать надо "на лету", поэтому можем разбирать в 2-й версии больше чем в 1-й.
Здравствуйте, Курилка, Вы писали:
E>>Чесно говоря, восторг от возможности передачи сложных структур данных у меня очень быстро прошел в свое время. Из-за "проблемы второй версии"
К>А конкретней? Где именно 2-я версия? Сообщений? Получателей?
Вторая версия протокола.
Наивно написанный протокол, к сожалению, не содержит возможности своего расшишения с сохранением совместимости с предыдущими версиями. Вплоть до таких детских ошибок, как отсутствие в протоколе метки его собственной версии.
M>>>Каким боком здесь динамика? А никаким К>Я думаю каким — типов сообщений у нас нет поэтому разбирать надо "на лету", поэтому можем разбирать в 2-й версии больше чем в 1-й.
Проблема в другом, в том, чтобы клиенты первой версии без проблем понимали вторую. Вот пример того, как это можно обеспечить (подсмотрено в Asn.1 ).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Проблема в другом, в том, чтобы клиенты первой версии без проблем понимали вторую. Вот пример того, как это можно обеспечить (подсмотрено в Asn.1 ).
Что-то вот какая-то непонятная задача, в смысле, что не видел ни одного подобного примера
По сути получается mediation, но примеров подобного на Erlang не встречал, думаю, что ПМ тут как раз был бы к месту. В принципе в стандартной библиотеке Эрланга есть некая "идиома", когда параметр есть список опций (расширяемый), тут тоже можно сделать нечто подобное. Причём вполне нетрудно.
Здравствуйте, Mamut, Вы писали:
M>*только не в бан, только не в бан*
Ладно. Рассмотреим пожелание.
M>Ну вот. В том-то все и дело. "Неосторожно брошенные слова".
Дело в том, что эта рихтовка производится уже после осбуждения. А не будь замечания многие бы проглатили исходное утверждение, а то еще хуже начали бы его расространять как истину не требующую доказательства.
M>Флейм? Флейм.
А может флэймом была сама исходная фраза?
M>Причем тут фанатичность или хоть какой-то намек на логику таких осуждений (особенно в рамках просьбы к гандальфу), не понятно
А ты почитай развитие ситации. Это именно фанатичные заявления. Альтернативы не пробовал, но выводы уже устоявшиеся.
M>И дальше топик скатился вообще непонятно куда
Да, никуда он не скатился. Просто к залихватской рекламной компании добавился разумный "разбор полетов".
Конструктивного, кстати, в подобных рекламных проспектах все равно ничего нет. Каждый кулик свое болото хвалит. Этой истине сто лет в обед.
Интересны не заявления "мы с помощью ххх порвали всех...", а рассказ о том, как и что было достигнуто. Ну, по крайней мере лично мне интереснее...
M>(опять же к обсуждению статики и динамики). А казалось бы. Достаточно было дождаться ответа автора
M>Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить".
Ну, и что этот ответ дал? Он мне очень напоминает анегдот:
В курилке один из сотруднико громко заявляет:
— Наш начальник полное говно!
Вдруг входит тот самый начальник...
— Ну, в хорошем смысле этого слова .
Из его слов лично мне стало ясно, что из статически типизированных языков он пробовал использовать только С++ и на его фоне ему показалось, что надежность действительно определяется динамикой Эрлэнга. В лучшем случае — это искренее заблуждение.
M>Все. И дальше можно обсуждать все, что угодно, применительно к проекту, создаваемому небольшим количеством человек, сложности и т.д. и т.п.
Дальше можно обсуждать только опыт и компетенцию, а это п. 5 по нашим правилам.
M>Более того, простой ответ в таком стиле: M>
M>Хм. Довольно спорное утверждение. Мой опыт показывает, что статика не только позволяет, но и помогает строить надежные системы. Быть может, автор это высказал в пылу спора или это как-то связано с его опытом в его проекте
Понимаешь ли в чем дело. Есть утверждения спорные и их можно понять. А есть абсурдные. Вот это было отнюдь не спорным.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
VD>>Важно то, что даже если на динамике можно создавать сложные приложения (т.е. я не прав в этом аспекте) — это никак не вылияет на возожность создавать сложные приложения на статике. Understand? EC>Это ты сейчас с кем споришь? Кто утверждал, что на статике создавать сложные приложения нельзя?
Это я не спорю, а разясняю основы дошкольной логики тем кто в этом нуждается.
EC>Попробуй читать сообщение, на которое отвечаешь — сэкономишь кучу времени себе и другим подписчикам форума.
Пробовал. У некоторых людей они действительно содержат интересную информацию. Но это не тот случай.
EC>Я там вопрос задал максимально точно, зная любителей пофлеймить, причём человек его понял в отличие от...
А в чем смысл твоег вопроса? Сказанное было без этого не очевидно? На заявление "Земля — это треугольник" ты тоже попросишь разяснений?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
(т.е. последняя, если читать "с конца")
