Какие плюсы у динамической типизации в сравнении со стачиеской типизации? Какие задачи с помощью динамически типизированного языка реализуются легче? Приведите плз примеры кода для сравнения?
Здравствуйте, Adopt, Вы писали:
A>Какие плюсы у динамической типизации в сравнении со стачиеской типизации? Какие задачи с помощью динамически типизированного языка реализуются легче? Приведите плз примеры кода для сравнения?
Здравствуйте, Adopt, Вы писали:
A>Какие плюсы у динамической типизации в сравнении со стачиеской типизации? Какие задачи с помощью динамически типизированного языка реализуются легче? Приведите плз примеры кода для сравнения?
Ну что, сразу в Священные войны поедем или здесь еще помучаемся?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ArtDenis, Вы писали:
>> Ну что, сразу в Священные войны поедем или здесь еще помучаемся?
AD>Пускай сначала люди свои умные мысли выскажут...
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>позволяет кешировать любую функцию:
IT>А зачем нужно кешировать функцию?
А зачем вообще нужна функция?
Смысл твоего вопроса от меня ускользает, или тебе нужно разъяснять зачем вообще может понадобится кеширование?
Просто человек просил привести пример я привел.
Здравствуйте, eao197, Вы писали:
E>А еще лучше, самому взять динамически типизированный язык и сделать на нем что-нибудь.
Вот это точно бесполезно, если прям сразу. Потому что человек, привыкший к статически типизованным языкам, поначалу, а особенно — без дополнительной теоретической подготовки — будет писать на динамически типизованном в точности так же, как на статически типизованном и при этом только мучаться — что неудобно.
По себе знаю
Уж как я изначально писал на javascript — это нечто. Далеко не сразу и только хорошо почитав про динамические языки, я понял насколько это можно было сделать лучше. При переписывании иногда целые страницы запутанного кода (который я с баальшим трудом писал и олаживал) — заменялись на несколько строчек простого и понятного кода
В каких случаях что лучше/хуже я судить не возьмусь (к тому же у меня с динамическими языками опыта все же мало), но точно скажу — что нужно осознать и освоиться с тем и с другим, чтобы реально это использовать. В смысле человек, привыкший к статике, далеко не сразу поймет прелесть динамики и наоборот. Должен быть некий перелом в сознании для удобного и эффективного использования. В статике человек привыкает использовать контроль компилятора, в динамике — привыкает к большей свободе — и переход от одного к другому не так-то и прост.
Здравствуйте, IT, Вы писали:
IT>А зачем нужно кешировать функцию?
Если функция вычисляется долго и сложно, но дает гарантированно однозначный результат для каждого уникального набора параметров (как приведенные в примере числа Фиббоначи), и при этом в программе высока вероятность частого использования функции с несколькими заранее неизвестными наборами параметров, то использование кэширования может оказаться очень эффективным.
Может так же оказаться очень полезным для рекурсивно вычисляемых функций.
Такая вот теория.
Самому ни разу пока не пришлось применить
Здравствуйте, fmiracle, Вы писали:
F>В каких случаях что лучше/хуже я судить не возьмусь (к тому же у меня с динамическими языками опыта все же мало), но точно скажу — что нужно осознать и освоиться с тем и с другим, чтобы реально это использовать. В смысле человек, привыкший к статике, далеко не сразу поймет прелесть динамики и наоборот. Должен быть некий перелом в сознании для удобного и эффективного использования. В статике человек привыкает использовать контроль компилятора, в динамике — привыкает к большей свободе — и переход от одного к другому не так-то и прост.
Не прост, подтверждаю.
Но и читать споры философов, пытаясь выделить из них крупицы рациональности, еще более бесполезное дело. Нельзя научиться кататься на велосипеде в теории. Так и здесь
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Не прост, подтверждаю. E>Но и читать споры философов, пытаясь выделить из них крупицы рациональности, еще более бесполезное дело. Нельзя научиться кататься на велосипеде в теории. Так и здесь
Особенно философов написавших за свою жизнь пару строчек на динамике, и потом кричащих что писали и знают что это такое, но при этом замечающих только недостатки
Здравствуйте, fmiracle, Вы писали:
F>Если функция вычисляется долго и сложно, но дает гарантированно однозначный результат для каждого уникального набора параметров (как приведенные в примере числа Фиббоначи), и при этом в программе высока вероятность частого использования функции с несколькими заранее неизвестными наборами параметров, то использование кэширования может оказаться очень эффективным.
Вот в Немерле, языке отнюдь не динамичесоком, есть такой стандартный макрос — Memoize. Доастаочно добавить его к свойству или методу и его значение будет закэшировано после первого использования. Так что почти все что достижимо динамической типизации можно реализовать на макросах. А то что зависит от информации доступной исключительно в рантайме можно решить с помощью динамической кодогенерации. Обычно такие решения получаются значительно более быстрыми. Ну, а сложность зависит от возможностей языка и фрэймворков.
F>Может так же оказаться очень полезным для рекурсивно вычисляемых функций.
При рекурсии более полезны акамуляторы в стеке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, fmiracle, Вы писали:
F>По себе знаю F>Уж как я изначально писал на javascript — это нечто. Далеко не сразу и только хорошо почитав про динамические языки, я понял насколько это можно было сделать лучше. При переписывании иногда целые страницы запутанного кода (который я с баальшим трудом писал и олаживал) — заменялись на несколько строчек простого и понятного кода
можете привести парку кусков кода?
F>В каких случаях что лучше/хуже я судить не возьмусь (к тому же у меня с динамическими языками опыта все же мало), но точно скажу — что нужно осознать и освоиться с тем и с другим, чтобы реально это использовать. В смысле человек, привыкший к статике, далеко не сразу поймет прелесть динамики и наоборот. Должен быть некий перелом в сознании для удобного и эффективного использования. В статике человек привыкает использовать контроль компилятора, в динамике — привыкает к большей свободе — и переход от одного к другому не так-то и прост.
где можно найти материал помогающий перейти? туториал... по принципу делаем сначала как привыкли, а потом пример на динамически типизированном языке
Здравствуйте, FR, Вы писали:
FR>А зачем вообще нужна функция?
Функция нужна, что бы её вызывать. Ы?
FR>Смысл твоего вопроса от меня ускользает, или тебе нужно разъяснять зачем вообще может понадобится кеширование?
Зачем нужно кеширование я могу попытаться догадаться или в крайнем случае погуглить и почитать. Зачем нужно кешировать, ВНИМАНИЕ!, функцию не может ответить даже гугль
FR>Просто человек просил привести пример я привел.
Боюсь, что человек, задавший подобный вопрос, находится после твоего ответа в таком же недоумении как и я.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, fmiracle, Вы писали:
IT>>А зачем нужно кешировать функцию?
F>Если функция вычисляется долго и сложно, но дает гарантированно однозначный результат для каждого уникального набора параметров (как приведенные в примере числа Фиббоначи), и при этом в программе высока вероятность частого использования функции с несколькими заранее неизвестными наборами параметров, то использование кэширования может оказаться очень эффективным.
Вот теперь понятно. Т.е. речь идёт не о кешировании функции, а о кешировании результата её вызова.
To FR: Функция для меня, человека погрязжего в управляемом коде и гарбач-коллекторах, тем не менее всё ещё представляется как указатель на блок кода, который можно вызвать ассемблерной инстукцией call или jmp. Зачем нужно кешировать, не запоминать для косвенного вызова, а именно кешировать этот указатель я не понимаю
F>Такая вот теория. F>Самому ни разу пока не пришлось применить
На самом деле довольно полезная штука. Я иногда использую в DAL для кеширования результатов вызова сохранённых процедур. Код реализации, конечно не такой компакнтный как у FR, но написан один раз и есть больше не просит. При этом настройка параметров кеширования производится декларативно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
FR>>Смысл твоего вопроса от меня ускользает, или тебе нужно разъяснять зачем вообще может понадобится кеширование?
IT>Зачем нужно кеширование я могу попытаться догадаться или в крайнем случае погуглить и почитать. Зачем нужно кешировать, ВНИМАНИЕ!, функцию не может ответить даже гугль
Понятно просто тебе охота поспорить, и поэтому решил прикопатся к терминологии. Хороший способ можно долго спорить ни о чем.
FR>>Просто человек просил привести пример я привел.
IT>Боюсь, что человек, задавший подобный вопрос, находится после твоего ответа в таком же недоумении как и я.
Боюсь у него нет такого горячего желания пофлеймить как у тебя.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, fmiracle, Вы писали:
F>>В статике человек привыкает использовать контроль компилятора, в динамике — привыкает к большей свободе...
IT>К свободе менять типы переменных исполняемой средой как ей вздумается, привыкнуть невозможно
Здравствуйте, IT, Вы писали:
IT>Вот теперь понятно. Т.е. речь идёт не о кешировании функции, а о кешировании результата её вызова.
IT>To FR: Функция для меня, человека погрязжего в управляемом коде и гарбач-коллекторах, тем не менее всё ещё представляется как указатель на блок кода, который можно вызвать ассемблерной инстукцией call или jmp. Зачем нужно кешировать, не запоминать для косвенного вызова, а именно кешировать этот указатель я не понимаю
Ты просто привык к тому что функции не первоклассные объекты, по этому и думаешт о них как как об указателях. Можно и функцию "кешировать". В функциональщине те же замыкания и карринг и есть в принципе "кеширование" функции. Кстати в моем примере это тоже есть так как присутствует замыкание.
F>>Такая вот теория. F>>Самому ни разу пока не пришлось применить
IT>На самом деле довольно полезная штука. Я иногда использую в DAL для кеширования результатов вызова сохранённых процедур. Код реализации, конечно не такой компакнтный как у FR, но написан один раз и есть больше не просит. При этом настройка параметров кеширования производится декларативно.
Здравствуйте, FR, Вы писали:
IT>>К свободе менять типы переменных исполняемой средой как ей вздумается, привыкнуть невозможно
FR>Еще одна легенда.
Что значит легенда? На "javascript parseint" гугль выдаёт больше миллиона ссылок. Это легенда? Отсутствие нормальной типизиации было основной мотивацией переписвания этого сайта с ASP на ASP.NET. Это тоже легенда?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
FR>>Еще одна легенда.
IT>Что значит легенда? На "javascript parseint" гугль выдаёт больше миллиона ссылок. Это легенда? Отсутствие нормальной типизиации было основной мотивацией переписвания этого сайта с ASP на ASP.NET. Это тоже легенда?
Это проблема языков со слабой типизацией, к динамике отношения не имеет, динамические языки с сильной типизацией не позволяют фокусы вроде x = 2 + "3".
Здравствуйте, FR, Вы писали:
FR>Ты просто привык к тому что функции не первоклассные объекты, по этому и думаешт о них как как об указателях. Можно и функцию "кешировать". В функциональщине те же замыкания и карринг и есть в принципе "кеширование" функции. Кстати в моем примере это тоже есть так как присутствует замыкание.
С функциями у меня всё в порядке. Единственное новое что я о них узнал из функциональщины, это то, что их там принято называть первоклассными объектами. Всё остальное так или иначе знал со времён баловства с дековским ассемблером на PDP-11.
IT>>На самом деле довольно полезная штука. Я иногда использую в DAL для кеширования результатов вызова сохранённых процедур. Код реализации, конечно не такой компакнтный как у FR, но написан один раз и есть больше не просит. При этом настройка параметров кеширования производится декларативно.
FR>Интересно бы посмотреть для сравнения.
Здравствуйте, FR, Вы писали:
FR>Это проблема языков со слабой типизацией, к динамике отношения не имеет, динамические языки с сильной типизацией не позволяют фокусы вроде x = 2 + "3".
А такое позволяют:
y = 2;
x = y + "3"
?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>Это проблема языков со слабой типизацией, к динамике отношения не имеет, динамические языки с сильной типизацией не позволяют фокусы вроде x = 2 + "3".
IT>А такое позволяют:
IT>y = 2; IT>x = y + "3"
IT>?
нет
>>> y = 2
>>> x = y + "3"
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Здравствуйте, FR, Вы писали:
IT>>А такое позволяют:
IT>>y = 2; IT>>x = y + "3"
IT>>?
FR>нет FR>
>>>> y = 2
>>>> x = y + "3"
FR>Traceback (most recent call last):
FR> File "<stdin>", line 1, in ?
FR>TypeError: unsupported operand type(s) for +: 'int' and 'str'
FR>
А так?
fun(y)
{
x = y + "3";
}
y = 1;
fun(y)
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>Ты просто привык к тому что функции не первоклассные объекты, по этому и думаешт о них как как об указателях. Можно и функцию "кешировать". В функциональщине те же замыкания и карринг и есть в принципе "кеширование" функции. Кстати в моем примере это тоже есть так как присутствует замыкание.
IT>С функциями у меня всё в порядке. Единственное новое что я о них узнал из функциональщины, это то, что их там принято называть первоклассными объектами. Всё остальное так или иначе знал со времён баловства с дековским ассемблером на PDP-11.
То есть на том ассемблере были и замыкания и карринг?
IT>>>На самом деле довольно полезная штука. Я иногда использую в DAL для кеширования результатов вызова сохранённых процедур. Код реализации, конечно не такой компакнтный как у FR, но написан один раз и есть больше не просит. При этом настройка параметров кеширования производится декларативно.
FR>>Интересно бы посмотреть для сравнения.
IT>AOP interceptors
IT>А так?
IT>fun(y) IT>{ IT> x = y + "3"; IT>}
IT>y = 1; IT>fun(y)
тоже нет:
def fun(y):
x = y + "3";
y = 1
fun(y)
Traceback (most recent call last):
File "tst00.py", line 5, in ?
fun(y)
File "tst00.py", line 2, in fun
x = y + "3";
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Здравствуйте, FR, Вы писали:
FR>Понятно просто тебе охота поспорить, и поэтому решил прикопатся к терминологии. Хороший способ можно долго спорить ни о чем.
Нет, дело не в поспорить. К сожалению, терминология такая штука, которая нас в основном разъединяет и большинство споров у нас носят терминологический характер. Было бы лучше, если бы все это понимали и старались говорить на одном языке. Или хотя бы расшифровывали то, что понимают под используемыми терминами.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote: > С функциями у меня всё в порядке. Единственное новое что я о них узнал > из функциональщины, это то, что их там принято называть первоклассными > объектами. Всё остальное так или иначе знал со времён баловства с > дековским ассемблером на PDP-11.
А лямбды? А ленивость?
Здравствуйте, Cyberax, Вы писали:
C>А лямбды? А ленивость?
На поверку лямбда оказалась всего лишь короткой формой записи локальной функции. Ленивость я не знаю что такое. Если объяснишь, то наверняка можно будет поискать аналог и в нефункциональном мире.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>А такое позволяют:
IT>>>y = 2; IT>>>x = y + "3"
IT>>>?
FR>>нет FR>>
>>>>> y = 2
>>>>> x = y + "3"
FR>>Traceback (most recent call last):
FR>> File "<stdin>", line 1, in ?
FR>>TypeError: unsupported operand type(s) for +: 'int' and 'str'
FR>>
IT>А так?
IT>fun(y) IT>{ IT> x = y + "3"; IT>}
IT>y = 1; IT>fun(y)
Еще в копилку:
irb(main):001:0> y=2
=> 2
irb(main):002:0> x=y+"3"
TypeError: String can't be coerced into Fixnum
from (irb):2:in `+'
from (irb):2
irb(main):003:0> def fun(y); x = y + "3"; end
=> nil
irb(main):004:0> y=1
=> 1
irb(main):005:0> fun(y)
TypeError: String can't be coerced into Fixnum
from (irb):3:in `+'
from (irb):3:in `fun'
from (irb):5
irb(main):006:0>
Осталось только кого нибудь из Smalltalk-еров подождать
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Cyberax, Вы писали:
C>>А лямбды? А ленивость?
IT>На поверку лямбда оказалась всего лишь короткой формой записи локальной функции. Ленивость я не знаю что такое. Если объяснишь, то наверняка можно будет поискать аналог и в нефункциональном мире.
Здравствуйте, Adopt, Вы писали:
A>Какие плюсы у динамической типизации в сравнении со стачиеской типизации?
A>Какие задачи с помощью динамически типизированного языка реализуются легче?
Most of GoF design patterns invisible or simple in dynamic languages.
A>Приведите плз примеры кода для сравнения?
Еще можно глянуть на мой пример конечного автомата — без атомов, которые трактуются в качестве имени функции (динамической типизации) так красиво бы (весь "паттерн" — в одну строку) не получилось. http://rsdn.ru/Forum/Message.aspx?mid=2073832&only=1
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, ArtDenis, Вы писали:
>>> Ну что, сразу в Священные войны поедем или здесь еще помучаемся?
AD>>Пускай сначала люди свои умные мысли выскажут...
E>Эти мысли высказывались уже не понятно сколько раз. Вместо провоцирования нового витка лучше почитать ранее написанное. Например, вот здесь: E>DynamicTyping E>BenefitsOfDynamicTyping E>IsDynamicTypingSufficientlyEfficient E>и далее по ссылочками.
Ну, еще свой мегапост на эту тему приведу, чтоли. Тоже лень повторяться. Но он, правда, посвящен вопросам производительности и "опасности" языков с динамической типизацией.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Cyberax, Вы писали:
C>>А лямбды? А ленивость?
IT>На поверку лямбда оказалась всего лишь короткой формой записи локальной функции.
funct( X, Y, Container ) ->
Z = X + Y,
map( fun( X ) -> X + Z end, Container ).
Код понятен? Просьба записать то же самое через локальные функции — на поверку.
Здравствуйте, FR, Вы писали:
IT>>На поверку лямбда оказалась всего лишь короткой формой записи локальной функции. Ленивость я не знаю что такое. Если объяснишь, то наверняка можно будет поискать аналог и в нефункциональном мире.
FR>Аналог итераторы, ну и плюс сахар в виде yield
Ерунда. Итераторы позволяют кое-как сымитировать ленивые списки, но ни разу не помогут в ситуации, как бы объяснить попроще... Вы знаете, что такое RS-триггер? Это два элемента 2и-не, объединенных вот так:
a = 2nand( b, R );
b = 2nand( a, S );
Чтобы на самом деле прочувствовать разницу между строгим и ленивым языком, попробуйте промоделировать правильную работу этой схемы на строгом языке. В ленивом языке — сами понимаете, программа будет в целом похожа на то, что я написал — не сильно сложнее.
Gaperton wrote: > Чтобы на самом деле прочувствовать разницу между строгим и ленивым > языком, попробуйте промоделировать правильную работу этой схемы на > строгом языке.
SystemC
Хотя получается очень некрасиво и неудобно.
> В ленивом языке — сами понимаете, программа будет в целом > похожа на то, что я написал — не сильно сложнее.
Угу. Кстати, как ваши эксперименты с Эрлангом? Насколько удобнее он чем
SystemC?
Здравствуйте, Cyberax, Вы писали:
>> В ленивом языке — сами понимаете, программа будет в целом >> похожа на то, что я написал — не сильно сложнее. C>Угу. Кстати, как ваши эксперименты с Эрлангом? Насколько удобнее он чем C>SystemC?
Кратко — пока не знаю.
В целом, если говорить об общей логике построении системы — получается очень похоже. В SystemC по одному треду на модуль — в Эрланге один процесс. Конечно, в Эрланге писанины меньше — там не надо деклараций делать, плюс — бит синтакс реально рулит со страшной силой (код гораздо литературнее получается).
Чтобы проверить, насколько Эрланг в этом рулит на самом деле, надо сделать на нем мало-мальски большой пример. А времени делать это самому у меня одного не очень много. Пока я сделал только тест производительности, но не нашел времени его запустить .
Насчет Эрланга план такой. Скоро выдам задание сделать на нем что-нибудь реальное, но простое. Если время будет. Плюс, попытаемся прикинуть, как будет выглядеть интерфейс между Эрлангом и SystemC. Если все пройдет хорошо — получится неплохая связка, в которой критичные по скорости выполнения узлы (вроде памяти) будут писаться на SystemC, в то время как вся система в целом будет описана на Erlang. Впоследствии, надо будет решить, как все это привязать к ModelSim — вроде проблем особых нет.
В данный момент у нас де-факто применяется для поведенческого моделирования Хаскель. В принципе — это хорошо, но есть проблема. Надо выяснить, смогут ли его читать наши аппаратчики. Скоро это выяснится. Насчет Хаскеля — первые результаты его применения необычайно хороши. (5 человеко-недель на aльфу поведенческой модели проца MIPS). Его будем стыковать с остальным так же, через ModelSim.
FR>>Аналог итераторы, ну и плюс сахар в виде yield
G>Ерунда. Итераторы позволяют кое-как сымитировать ленивые списки, но ни разу не помогут в ситуации, как бы объяснить попроще...
Триггер моделировать не буду
Я просто привел ближайший аналог ленивости. Вообще с итераторами и генераторами тоже можно много интересных и красивых штучек сделать, например как тут: List/Generator Monad Combinators
Здравствуйте, IT, Вы писали:
IT>К свободе менять типы переменных исполняемой средой как ей вздумается, привыкнуть невозможно
Думаю все же возможно — человек существо с очень сильной приспособляемостью
Я тоже не могу принять непроизвольную смену типов, но встречал людей, которые наоборот говорили, что это просто замечательно и удобно. Думаю, тут дело в начальном обучении — с чего начинал обучаться — к тому и более привыкший... Возможно, так же сказываются какие-то особенности характера
Здравствуйте, IT, Вы писали:
IT>Не очень. Что такое end? Конец лямбды?
Да.
IT>
IT>def funct(X, Y, Container)
IT>{
IT> def Z = X + Y;
IT> def fmap(X)
IT> {
IT> X + Z
IT> }
IT> map(fmap, Container);
IT>}
IT>
IT>Код на шарпе с анонимными делегатами приводить?
У тебя тут не просто "локальные функции". Чтобы это заработало — нужны еще и лексические замыкания (lexical closures). Если они поддержаны (я не знаю, как на самом деле работает твой код), и есть "сокращенная форма определения функции", то она называется "лямбда-функцией". Термин такой. Твой анонимный делегат на поверку может оказаться лямбдой.
Здравствуйте, Gaperton, Вы писали:
G>У тебя тут не просто "локальные функции". Чтобы это заработало — нужны еще и лексические замыкания (lexical closures). Если они поддержаны (я не знаю, как на самом деле работает твой код), и есть "сокращенная форма определения функции", то она называется "лямбда-функцией". Термин такой. Твой анонимный делегат на поверку может оказаться лямбдой.
Вообще-то, если бы ты был повнимательне, то понял бы, что IT это и говорил.
На поверку лямбда оказалась всего лишь короткой формой записи локальной функции.
Просто у тех кто развивает ФЯ (точнее развивал раньше) нехватало умения доступно донести до окружающих в общем-то простые понятия. Тот математический бред (другого слова подобрать не могу) только запутывал большинство людей и они думали, что функциональное программирование это очень сложно. Объяснить же концепции лямбды или замыкания ничего не стоит если приводить примеры известные программистам по практике. Замыкания элементарно сравниваются со сылками на поля классов и глобальные переменные, а лямбды с локальными функциями.
Кстати, локальные фунции в Паскеле, если мне не изменяет память были замкнуты на параметры внешней функции. Так что с натяжкой и их можно назвать замыканиями.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, локальные фунции в Паскеле, если мне не изменяет память были замкнуты на параметры внешней функции. Так что с натяжкой и их можно назвать замыканиями.
Здравствуйте, Gaperton, Вы писали:
IT>>Не очень. Что такое end? Конец лямбды? G>Да.
OK, буду знать
IT>>Код на шарпе с анонимными делегатами приводить? G>У тебя тут не просто "локальные функции". Чтобы это заработало — нужны еще и лексические замыкания (lexical closures).
Я же говорю, нас в основном разделяет терминология. Этот термин используется в Немерле для обозначения м... локальных функций.
G>Если они поддержаны (я не знаю, как на самом деле работает твой код), и есть "сокращенная форма определения функции", то она называется "лямбда-функцией". Термин такой. Твой анонимный делегат на поверку может оказаться лямбдой.
Полноценные лямбды будут введены только в C# 3.0. Там они даже называются так. В 2.0 они называются анонимные делегаты, но замыкания уже вовсю пользуют, не используя при этом термин замыкание
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
G>funct( X, Y, Container ) ->
G> Z = X + Y,
G> map( fun( X ) -> X + Z end, Container ).
G>
G>Код понятен? Просьба записать то же самое через локальные функции — на поверку.
function funct( X, Y:integer; Container:TContainer) :TContainer;
var Z:integer;
function local(X:integer):integer;
begin
local:= X + Z
end;
begin
Z := X + Y;
funct:= map(local, Container)
end
Здравствуйте, IT, Вы писали:
IT>Ленивость я не знаю что такое. Если объяснишь, то наверняка можно будет поискать аналог и в нефункциональном мире.
В нефункциональном мире это называется call by name и call by need.
IT>>>Единственное новое что я о них узнал из функциональщины, это то, что их там принято называть первоклассными объектами.
Ради этого не стоило лезть в функциональщину. Впервые функции были объявлены первоклассными объектами в CPL — предшественнике BCPL и, следовательно, С.
Здравствуйте, IT, Вы писали:
IT>Полноценные лямбды будут введены только в C# 3.0. Там они даже называются так. В 2.0 они называются анонимные делегаты, но замыкания уже вовсю пользуют, не используя при этом термин замыкание
На самом деле то что ты называешь "анонимные делегаты" реально называется анонимными методами и на 101% подходит под опрделение лямбды. Просто они имеют неуклюжий синтаксис и обязаны содержать staetments. В C# 3.0 же просто введут упрощенный синтаксис (не в последнюю очередь за счет вывода типов) и возможность создавать аномимные методы содержащие expression. То есть по сути это не более чем синтаксический сахар.
А вот что действительно плохо в C# — это то, что к анонимным методам и лямдбам приходится обращаться через делегаты. Это и неудобно, и медленно, и потенциально опасно (ведь делегаты бывают составными).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
G>>funct( X, Y, Container ) ->
G>> Z = X + Y,
G>> map( fun( X ) -> X + Z end, Container ).
G>>
G>>Код понятен? Просьба записать то же самое через локальные функции — на поверку.
Т>
Т>function funct( X, Y:integer; Container:TContainer) :TContainer;
Т> var Z:integer;
Т> function local(X:integer):integer;
Т> begin
Т> local:= X + Z
Т> end;
Т>begin
Т> Z := X + Y;
Т> funct:= map(local, Container)
Т>end
Т>
Кстати, где Губанов? С удовольствием послушал бы его мнение про синтаксический оверхэд.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>На самом деле то что ты называешь "анонимные делегаты" реально называется анонимными методами и на 101% подходит под опрделение лямбды.
Кто-то мне, кажется из наших MVP, как-то объяснял, что лямбды это как раз то, что введут в C# 3.0. Впрочем, мне без разницы как оно называется на самом деле, лишь бы было удобно. Те же анонимные методы я использую во всю уже около года, с момента выхода C# 2.0, и как-то особенно не задумывался над названием.
VD>То есть по сути это не более чем синтаксический сахар.
Анонимные методы тоже не более чем синтаксических сахар, т.е. следуя логике лямбда — это синтаксических сахар даже не по отношению к анонимным методам, а вообще ещё к C# 1.0. Т.е. опять же просто более удобная запись, на самом деле ничего военного.
Если нам не помогут, то мы тоже никого не пощадим.
VD>Кстати, локальные фунции в Паскеле, если мне не изменяет память были замкнуты на параметры внешней функции. Так что с натяжкой и их можно назвать замыканиями.
IT>Анонимные методы тоже не более чем синтаксических сахар, т.е. следуя логике лямбда — это синтаксических сахар даже не по отношению к анонимным методам, а вообще ещё к C# 1.0. Т.е. опять же просто более удобная запись, на самом деле ничего военного.
Здравствуйте, Трурль, Вы писали:
IT>>Ленивость я не знаю что такое. Если объяснишь, то наверняка можно будет поискать аналог и в нефункциональном мире. Т>В нефункциональном мире это называется call by name и call by need.
Понятно. Честно говоря, пока кроме итераторов даже не могу придумать другого достойного применения.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, FR, Вы писали:
IT>>Анонимные методы тоже не более чем синтаксических сахар, т.е. следуя логике лямбда — это синтаксических сахар даже не по отношению к анонимным методам, а вообще ещё к C# 1.0. Т.е. опять же просто более удобная запись, на самом деле ничего военного.
FR>Опять забываешь про замыкания.
Ни в коем случае. И что значит опять? Замыкания в C# 2.0 — это тоже сахар. Достаточно глянуть рефлектором как они реализуются. Результирующий код не использует ничего из того, чего не было в CLR 1.0 и появилось в CLR 2.0. Это просто сахар.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
FR>>Опять забываешь про замыкания.
IT>Ни в коем случае. И что значит опять? Замыкания в C# 2.0 — это тоже сахар. Достаточно глянуть рефлектором как они реализуются. Результирующий код не использует ничего из того, чего не было в CLR 1.0 и появилось в CLR 2.0. Это просто сахар.
Совершенно согласен, я вот тоже смотрел дизассемлером как классы реализуются в C++, результирующий год не использует ничего из того, чего нельзя сделать в процедурном стиле, так что весь ООП это это просто сахар.
Здравствуйте, IT, Вы писали:
IT>Анонимные методы тоже не более чем синтаксических сахар, т.е. следуя логике лямбда — это синтаксических сахар даже не по отношению к анонимным методам, а вообще ещё к C# 1.0. Т.е. опять же просто более удобная запись, на самом деле ничего военного.
При некоторой общности — да. Но реально в лямбдах имнно подправлен синтаксис, а анонимные методы потребовали серьезной доработки компилятора.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Совершенно согласен, я вот тоже смотрел дизассемлером как классы реализуются в C++, результирующий год не использует ничего из того, чего нельзя сделать в процедурном стиле, так что весь ООП это это просто сахар.
Самое смешное, что на некотором уровне общьности — да.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Опять забываешь про замыкания.
VD>По большому счету они эмулируются классами и методами. Так в общем-то в C# и сделано.
А класссы тоже легко эмулируются через замыкания. В Clisp'е в общем так и сделано
Здравствуйте, FR, Вы писали:
FR>Совершенно согласен, я вот тоже смотрел дизассемлером как классы реализуются в C++, результирующий год не использует ничего из того, чего нельзя сделать в процедурном стиле, так что весь ООП это это просто сахар.
Верно. Я всегда говорил, что ООП — это просто набор удобных паттернов.
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote: > FR>Совершенно согласен, я вот тоже смотрел дизассемлером как классы > реализуются в C++, результирующий год не использует ничего из того, чего > нельзя сделать в процедурном стиле, так что весь ООП это это просто сахар. > Верно. Я всегда говорил, что ООП — это просто набор удобных паттернов.
Осторожно! В этой ветке Gaprton и VladD2, которые оба несогласны с таким
мнением.
Здравствуйте, Cyberax, Вы писали:
>> Верно. Я всегда говорил, что ООП — это просто набор удобных паттернов. C>Осторожно! В этой ветке Gaprton и VladD2, которые оба несогласны с таким мнением.
Если отвечать на твоё замечание в стиле Влада, то получается, что его несогласие не может повлиять на то, что ООП — это просто набор удобных паттернов
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>... IT>Анонимные методы тоже не более чем синтаксических сахар, т.е. следуя логике лямбда — это синтаксических сахар даже не по отношению к анонимным методам, а вообще ещё к C# 1.0. Т.е. опять же просто более удобная запись, на самом деле ничего военного.
Ну вот она основная разница между функциональными языками и не. В функциональном лямбда это самая низкоуровненвая конструкция. И с помощью сахара и комбинаторов эти лямбды стараются запрятать подальше. Но в результате все в эту одну большую лямбду и разворачивается. А в нефункциональных языках лямбда — это сахар.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
G>>
G>>funct( X, Y, Container ) ->
G>> Z = X + Y,
G>> map( fun( X ) -> X + Z end, Container ).
G>>
G>>Код понятен? Просьба записать то же самое через локальные функции — на поверку.
Т>
Т>function funct( X, Y:integer; Container:TContainer) :TContainer;
Т> var Z:integer;
Т> function local(X:integer):integer;
Т> begin
Т> local:= X + Z
Т> end;
Т>begin
Т> Z := X + Y;
Т> funct:= map(local, Container)
Т>end
Т>
Хм. Не защитываем. А вернуть такую "лямбду" в качестве результата функции у тебя тоже получится (опускаем вызов map)?
Здравствуйте, Gaperton, Вы писали:
G>Хм. Не защитываем. А вернуть такую "лямбду" в качестве результата функции у тебя тоже получится (опускаем вызов map)?
А про вернуть ничего не было.