Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 136
Большое спасибо :)
Как раз хотел присмотреться к какому-нибудь неизвестному мне языку программирования, для повышения профессионального уровня. Похоже, этим языком программирования будет Io.
Как раз хотел присмотреться к какому-нибудь неизвестному мне языку программирования, для повышения профессионального уровня. Похоже, этим языком программирования будет Io.
Всегда пожалуйста (:
Вот только есть предложение не хвататься за Io, а схватиться за Lisp, например.
В Io желательно приходить уже зная, что могут дать метапрограммирование, лямбда-функции и прочее. К тому же пока по Io очень мало толковой документации, но мы работаем над этим (:
Вот только есть предложение не хвататься за Io, а схватиться за Lisp, например.
В Io желательно приходить уже зная, что могут дать метапрограммирование, лямбда-функции и прочее. К тому же пока по Io очень мало толковой документации, но мы работаем над этим (:
А я рубист, у нас тоже есть всякие вкусные высокоуровневые штуки. Так что вполне представляю, что и почем.
Правда, с Lisp'ом я знакомился один семестр на третьем курсе, и воспоминания не слишком приятные :)
Правда, с Lisp'ом я знакомился один семестр на третьем курсе, и воспоминания не слишком приятные :)
Академический лисп и лисп производственный это настолько разные вещи, что аж зубы сводит. Чаще всего в университетах даже lisp-код форматировать не умеют, не говоря уж о метапрограммировании (которое там совершенно офигенное).
Почитайте «On Lisp» Грэма или «Practical Common Lisp». Ну и «SICP», конечно.
Хотя да, рубистам в Io будет приятно и легко.
Почитайте «On Lisp» Грэма или «Practical Common Lisp». Ну и «SICP», конечно.
Хотя да, рубистам в Io будет приятно и легко.
А на тему метапрограммирования, лямбда-функций и прочего куда сунуться можно?
Эээ, вопрос интересный. Вообще лямбда-функции вытекают из лямбда-исчисления, это раздел математики (см. википедию). Про метапрограммирование можно почитать учебники по лиспу, например.
А если одним словом, все хорошо расписано в книжке «Структура и интерпретация компьютерных программ». Она вышла у нас на русском и есть в pdf в интернетах.
А если одним словом, все хорошо расписано в книжке «Структура и интерпретация компьютерных программ». Она вышла у нас на русском и есть в pdf в интернетах.
Дай ссылочку пожевать. И это, почему её до сих пор не задефунил?
http://newstar.rinet.ru/~goga/sicp/sicp.…
Ща задефуню.
Ща задефуню.
Попробуйте какой нибудь из диалектов Smalltalk, например Dolphin. Обещаю скучно вам не будет и уровень свой поднимите сильно.
Хорошо пишешь.
Синтаксис и вообще подход похож на ruby. я не помню есть ли в нем лямда функции :)
Между Io и Ruby очень много общего, например один из разработчиков (:
Ну и да, в Ruby есть lambda-функции, они называются блоки.
В общем-то в Io любое сообщение method — лямбда функция. Есть еще block, который еще более лямбда-функция, но про него я как-нибудь в следующий раз.
В общем-то в Io любое сообщение method — лямбда функция. Есть еще block, который еще более лямбда-функция, но про него я как-нибудь в следующий раз.
как можно программить на руби и не знать про лямда функции???
Очень просто: программировать на языке "ruby on rails" :)
не знать нельзя. а вот написать такое можно когда устал и болеешь.. не возмущайтесь тут :)
Там же своя терминология. Я подозреваю, многие из тех, кто пишет на C#, тоже не знают, что анонимные делегаты — это лямбда-функции. :)
лямбда-функции, делегаты.
это что-то вроде typedef int (*PFUNC) (int);
?
это что-то вроде typedef int (*PFUNC) (int);
?
да, делегат это объектно-ориентированная версия указателя на функцию, скажем так :)
Есть два важных отличия:
1. Каррированность (не знаю, как правильнее по-русски сказать). Есть не во всех ФП-языках, насколько я помню, но теоретические основы и практическая реализация заложены именно функциональщиками. Означает, что если у функции
есть N параметров, и мы установим значения для M из них, то у нас появляется новая функция с (N - M) параметрами.
Проще всего приводить пример с распространённой функцией map, которая на входе получает функцию с одним параметром и список, и применяет функцию ко всем параметрами. Получается что-то вроде такого:
map (+5) [2, 3, 4, 1, 17] — прибавляем 5 ко всем элементам списка
map (2^) [2, 3, 4, 1, 17] — получаем степень 2-ки для всех элементов списка
Это был Хаскелл. А вот Руби (удаление всех файлов с расширением .tmp из каталога C:\temp):
Dir.foreach("C:\\temp\\*.tmp", { |filename| File.delete(filename) }
2. При вызове лябда-функции в её теле доступны локальные переменные вызывающей функции. Тоже, вроде бы, не во всех
ФП-языках есть эти самые замыкания (closures), но в Руби и C# есть.
Например:
Time monthAgo = Time.now - 60 * 60 * 24 * 30;
Dir.foreach("C:\\temp\\*.tmp", { |filename| if(File.stat(filename).atime < monthAgo) File.delete(filename) }
Тут писал несколько по памяти, поэтому возможны синтаксические неточности, но смысл передан верно. Основное отличие
от императивных языков в том, что всё здесь делается in place, в одну строку. Теоретически, всё это можно и на C/C++
делать, но — всё вручную. Хочешь замыкание — пиши класс с состоянием. А функции каррируй вручную.
1. Каррированность (не знаю, как правильнее по-русски сказать). Есть не во всех ФП-языках, насколько я помню, но теоретические основы и практическая реализация заложены именно функциональщиками. Означает, что если у функции
есть N параметров, и мы установим значения для M из них, то у нас появляется новая функция с (N - M) параметрами.
Проще всего приводить пример с распространённой функцией map, которая на входе получает функцию с одним параметром и список, и применяет функцию ко всем параметрами. Получается что-то вроде такого:
map (+5) [2, 3, 4, 1, 17] — прибавляем 5 ко всем элементам списка
map (2^) [2, 3, 4, 1, 17] — получаем степень 2-ки для всех элементов списка
Это был Хаскелл. А вот Руби (удаление всех файлов с расширением .tmp из каталога C:\temp):
Dir.foreach("C:\\temp\\*.tmp", { |filename| File.delete(filename) }
2. При вызове лябда-функции в её теле доступны локальные переменные вызывающей функции. Тоже, вроде бы, не во всех
ФП-языках есть эти самые замыкания (closures), но в Руби и C# есть.
Например:
Time monthAgo = Time.now - 60 * 60 * 24 * 30;
Dir.foreach("C:\\temp\\*.tmp", { |filename| if(File.stat(filename).atime < monthAgo) File.delete(filename) }
Тут писал несколько по памяти, поэтому возможны синтаксические неточности, но смысл передан верно. Основное отличие
от императивных языков в том, что всё здесь делается in place, в одну строку. Теоретически, всё это можно и на C/C++
делать, но — всё вручную. Хочешь замыкание — пиши класс с состоянием. А функции каррируй вручную.
Ещё бы они не были похожи - и туда и туда они пришли из Smalltalk-а :-)
было бы еще лучше, если бы не было столько лишних переносов строк.
Проблема в том, что их там нет, это интервал в тэге pre. Меня тоже драконит
именно поэтому я пишу тексты для хабры в чистом штмле и не пользуюсь автоформатированием :)
В данном случае их можно заменить на blockquote
В данном случае их можно заменить на blockquote
Автоформатирование надо отключить, тогда <br /> после каждой строки вставляться не будет. Впрочем, это тоже геморрой. На хабре давно пора предусмотреть тег habrapre, чтобы внутри pre переносы строк не вставлялись. :)
Здорово, только пример с синглтоном к метапрограммированию как-то мне особо наглядным не показался. Не проникаешься сутью того, что обработчик сообщения может сделать со своими аргументами.
Про метапрограммирование я поподробнее напишу чуть позже, довольно тяжело объяснять систему метапрограммирования, когда она настолько тривиальна, как ни странно.
Из фишек на затравку, Io умеет:
Из фишек на затравку, Io умеет:
- На лету брать полную информацию о слотах объекта
- На лету «декомпилировать» слоты
- На лету изменять любой фрагмент кода в рантайме
Mushroom := Object clone
…
В этом фрагменте кода мы создаем класс Mushroom
Классов-то нет.
Тут все просто, главно понять, что в Io нет методов и свойств, есть слоты и сообщения.
И чем по-вашему метод «отличается» от «сообщения», а «свойство» от «слота»? По-моему ничем, если учесть что «метод — кусок кода, ассоциированный с объектом или классом».
Больше всего это напоминает мне JavaScript со стейтментами в стиле лисп (с лиспом не знаком).
Про класс мой косяк --- поправил, спасибо.
А про отличия: слот --- абстрактный контейней, который может содержать как значение, так и «метод». Все это в общем случае --- сообщения.
А про отличия: слот --- абстрактный контейней, который может содержать как значение, так и «метод». Все это в общем случае --- сообщения.
а, да, слоты отличаются
____
интересно, как в более-менее сложном коде предполагается создать два объекта одного типа в разных местах (где клонирование недоступно)… предполагаю, будет уже не так красиво
____
интересно, как в более-менее сложном коде предполагается создать два объекта одного типа в разных местах (где клонирование недоступно)… предполагаю, будет уже не так красиво
Вообще Io умеет асинхронные сообщения, через них можно получить доступ к любому месту системы, даже к сильно удаленному (другая нода кластера, например). Проблемы не вижу пока (:
Ну вот в JS я бы написал так:
Как в данном случае обойтись одним клонированием, мне не оч. понятно… Т. е. извернуться можно, но красиво пока не входит.
function Human(name, age, city) {
this.name = name
// что-нить сложное
}
fuction one() { new Human("Elsa", 19, "Hamburg") }
fuction two() { new Human("Egor", 32, "spb") }
Как в данном случае обойтись одним клонированием, мне не оч. понятно… Т. е. извернуться можно, но красиво пока не входит.
Эээ, а почему одним-то клонированием-то? У вас тут два new, значит два поколения, так же и там.
Human := Object clone
Human init := method(name, age, city,
self name := name
self age := age
self city := city
)
One := Human clone
One init("Elsa", 19, "Hamburg")
Two := Human clone
Two init("Egor", 32, "spb")
Собственно, new в JavaScript - это аналог clone в io.
"В Io нет понятия класс, только объект"
А мне кажется, что объект - это экземпляр класса. Класс — это тип, описывающий устройство объектов — экземпляров.
А мне кажется, что объект - это экземпляр класса. Класс — это тип, описывающий устройство объектов — экземпляров.
Про метод/сообщение: метод вызывается, а сообщение посылается. Разница хорошо видна, если попытаться вызвать несуществующий метод - в случае "вызова метода" либо среда исполнения сгенерирует исключение, либо просто всё упадёт, и мы сможем обработать эту ситуацию только в _вызывающем_ объекте, но не в _вызываемом_. При посылке же сообщения мы легко можем обработать ситуацию отсутствия соответствующего метода непосредственно в том объекте, которому посылается сообщение. Такое поведение периодически используется в зрелых динамически типизированных языках. Чем-то это похоже на кодогенерацию на лету, но даёт гораздо больше возможностей.
Введение в Io посредством примера, основанного на теории "Ленин - гриб (и радиоволна)" - это круто :)
название плохое, гуглить плохо +)
Вот блин спасибо!!! Узнал новое, посмеялся над туториалом. Пошло говоря, в рот мне щупальца!
Шикарные примеры =))
а как у него с юникодом? опять все плохо?
Да нет, вроде. Изначально разрабатывался с его поддержкой.
Вот конкретно в модуле Directory под винду есть косяки с юникодом, но только в этом модуле и только под винду.
Вот конкретно в модуле Directory под винду есть косяки с юникодом, но только в этом модуле и только под винду.
хм, молодцы, если так
просто у меня есть ощущение, что юникод не очень хорошо сочетается с маленькими встраиваемыми языками — там сложностей вроде бы много
да и пример работы со строкой, где по индексу возвращается число, а не символ, тоже усилил подозрения
просто у меня есть ощущение, что юникод не очень хорошо сочетается с маленькими встраиваемыми языками — там сложностей вроде бы много
да и пример работы со строкой, где по индексу возвращается число, а не символ, тоже усилил подозрения
У чисел есть метод asCharacter, насколько я помню, с его помощью можно сконвертить все куда угодно. Юникод же тоже числами кодируется.
весьма
даешь еще статей по ИО
даешь еще статей по ИО
Спасибо за материал. Я думал, на хабре поклонников ФП нет — как ни заикнусь, обязательно мне пишут, что это-де, пока всё очень академично. :)
подача хороша.
што то можно тут почитать http://www.myjavaserver.com/~livesystems/stor/IoProgrammingGuide.ru.html
там есть полноценные замыкания (с захватом контекста)?
Не программист, но прочитал с интересом. Блин, ну почему предки не купили мне компьютер, когда я учился в школе. Ну или хотя бы магнитофон к спектруму для записи кода. Аыыыыы (((
Язык весьма интересный. А что насичот производительности?
Вот тут что-то совсем нерадостно.
Вот тут что-то совсем нерадостно.
С производительностью у него пока беда: http://shootout.alioth.debian.org/gp4/be…
И это при условии, что MRI (Ruby 1.8) сам по себе достаточно медленный.
А вообще язык симпатичный.
И это при условии, что MRI (Ruby 1.8) сам по себе достаточно медленный.
А вообще язык симпатичный.
копетц.
> Совсем недавно, в 2002 году,
это всё было давно опубликовано в 1969 году в спецификации на forth
> Совсем недавно, в 2002 году,
это всё было давно опубликовано в 1969 году в спецификации на forth
Круто. Давно форт стал объектно ориентированным? А тем более Ъ-Объектно-ориентированным?
как и любой метаязык он позволяет создать такую объектную модель, которая больше нравится. труъ - у каждого своё.
вы знаете, вот чуть ниже вы хаете метаязыки. не странно ли вам?
на лиспе тоже можно реализовать что угодно. Кроме того у ТруЪ-ООП есть всего одно мерило --- smalltalk.
на лиспе тоже можно реализовать что угодно. Кроме того у ТруЪ-ООП есть всего одно мерило --- smalltalk.
ну, самый мощный метаязык - это ассемблер ;-) и многие из "простых, но мощных" языков типа лиспа, форта, хаскела - не слишком далеко от него ушли. всё-равно для написания более-менее крупного приложения придётся писать нефиговый "фреймворк" реализующий ту или иную парадигму.
а в смалтолк, хотя и замечательный ооп, но тоже не идеален. например, в нём нет интерфейсов, нет локальной перегрузки стандартных типов. ну и больше всего убивает - ориентированность на то, что пользователь работающий с программой и разработчик оной - одно лицо.
а в смалтолк, хотя и замечательный ооп, но тоже не идеален. например, в нём нет интерфейсов, нет локальной перегрузки стандартных типов. ну и больше всего убивает - ориентированность на то, что пользователь работающий с программой и разработчик оной - одно лицо.
Блин, пока не увидел ссылку, думал, что язык называется "Lo"
Полный вынос...
Я так и не понял, в чем его ценность.
Я так и не понял, в чем его ценность.
> "Hello world" print
принт куда? возможность "печатать" - это свойство принтера, а не бумаги.
лучше бы сделали так:
con.print( "Hello world" )
при этом метод print должен вызывать "Hello world".toString
это с точки зрения ооп.
с точки зрения синтаксиса, лучше подход цпп:
con все дерево кода доступно в рантайме
только не вздумайте его менять, иначе замучаетесь с отладкой.
два различных синтаксиса вызова методов (со скобочками и без) - это очень плохо.
есть ли возможность перегружать присваивания? например, когда я хочу генерировать ошибку при попытке изменения какого-либо слота (ридонли свойство).
принт куда? возможность "печатать" - это свойство принтера, а не бумаги.
лучше бы сделали так:
con.print( "Hello world" )
при этом метод print должен вызывать "Hello world".toString
это с точки зрения ооп.
с точки зрения синтаксиса, лучше подход цпп:
con все дерево кода доступно в рантайме
только не вздумайте его менять, иначе замучаетесь с отладкой.
два различных синтаксиса вызова методов (со скобочками и без) - это очень плохо.
есть ли возможность перегружать присваивания? например, когда я хочу генерировать ошибку при попытке изменения какого-либо слота (ридонли свойство).
ну вот что за придурки писали движок хабра? неужели кроме стриптэгс ничего умнее в голову не пришло?
цпп код: console
цпп код: console
console << "Hello World"
ну и далее у меня было написано что-то про то, что все эти новомодные языки по сути своей ущербны, ибо на них нельзя написать ядро ос и другие рилтайм приложения. для эффективного использования ресурсов остаются только цпп и ада. печально всё это =(
ну и далее у меня было написано что-то про то, что все эти новомодные языки по сути своей ущербны, ибо на них нельзя написать ядро ос и другие рилтайм приложения. для эффективного использования ресурсов остаются только цпп и ада. печально всё это =(
Наоборот, хорошо. Богу божье, цезарю всё остальное.
Ядерщиков сейчас доли процента. Из моих личных знакомых, вот только авторы sphinx (поисковой машины) пишут на C++, да я (2-й
раз за последние 3 года). Ну, ещё те бедолаги, которые поддерживают проект, начатый в 98-м. :)
Для прикладного программирования нужны прикладные же средства.
Ядерщиков сейчас доли процента. Из моих личных знакомых, вот только авторы sphinx (поисковой машины) пишут на C++, да я (2-й
раз за последние 3 года). Ну, ещё те бедолаги, которые поддерживают проект, начатый в 98-м. :)
Для прикладного программирования нужны прикладные же средства.
одно исключает другое? неужели существует какая-то принципиальная невозможность создания выразительного и в то же время эффективного языка?
ну вот взять, например, цпп. отрезать нафик указатели, шаблоны, сделать всё объектами, добавить возможность расширения синтаксиса (добавление своих операторов, например), отрезать типизацию, добавить интерфейсы, избавиться от "заканчивающихся нулём строк" и замечательный ведь язык получится. но нет, все лезут в метапрограммирование, рефлексию, полный динамизм, виртуальные машины, автоматические сборщики мусора... и огребают тормоза и повышенное потребление памяти. причём пользы от всего этого не слишком много. высокодинамичные программы сложно отлаживать. сборщик мусора работает не ахти как. байткод не учитывает специфику железа. итд итп
Польза появляется только тогда, когда начинаешь думать что ты делаешь, а не тогда, когда у тебя в руках быстрые костыли в виде плюсов. Высокоуровневый подход банально удобнее и выразительней, а производительности мне зачастую не жалко. А где жалко я напишу на C/Object C, но, упаси господи, не на C++.
угу, так в итоге и получается, что для комфортной работы нехватает гига памяти и всё тормозит. в то время как какая-нибудь миньетОС умещается на дискетку и летает.
Вы точно не путаете Энтерпрайз с динамическими языками со сверхвысокими абстракциями? Тормозят больше всего, почему-то, всякие энтерпрайз монстры написанные на C++.
тормозит всё, что угодно, когда разработчику "зачастую не жалко производительности"
Неправда. freearc быстре 7-zip и rar, хотя писан на Хаскелле. Вот авторам этих архиваторов
придётся изрядно потрудиться, чтобы на многоядерные процессоры пересесть. А в Хаскелле с этим
никаких проблем.
придётся изрядно потрудиться, чтобы на многоядерные процессоры пересесть. А в Хаскелле с этим
никаких проблем.
неправда. седьмой зип в зависимости от настроек либо быстрее либо лучше жмёт. только что замерил.
но это не самое главное. фишка в том, что потоковая обработка - это халява для функциональных языков. их бич - активная работа с памятью. например, наложение фильтров на изображение.
и не надо судить о многочности в императивных языках по одному лишь цпп, который до недавнего времени её вообще не поддерживал. в языке ада, например, с многопоточностью всё в порядке.
вообще, довольно глупо тянуть чисто математическую абстракцию на чисто императивную архитектуру компьютера. всё-равно интерпретатору приходится конвертировать функциональную программу к императивной форме.
особенно убивает реализация естественных для человека циклов через рекурсию и дальнейшие шаманства с "хвостовой оптимизацией"...
но это не самое главное. фишка в том, что потоковая обработка - это халява для функциональных языков. их бич - активная работа с памятью. например, наложение фильтров на изображение.
и не надо судить о многочности в императивных языках по одному лишь цпп, который до недавнего времени её вообще не поддерживал. в языке ада, например, с многопоточностью всё в порядке.
вообще, довольно глупо тянуть чисто математическую абстракцию на чисто императивную архитектуру компьютера. всё-равно интерпретатору приходится конвертировать функциональную программу к императивной форме.
особенно убивает реализация естественных для человека циклов через рекурсию и дальнейшие шаманства с "хвостовой оптимизацией"...
по первой фразе - имеется ввиду, что при прочих равных..
а вот винрар - да, хотя и быстрее обоих, но жмёт хуже.
а вот винрар - да, хотя и быстрее обоих, но жмёт хуже.
Вот независимые бенчмарки:
http://www.squeezechart.com/main.html
http://www.metacompressor.com/
http://maxcompress.narod.ru/
http://www.maximumcompression.com/data/s…
Freearc при сопоставимой степени сжатия работает быстрее. При сопоставимой скорости
сжимает лучше. С чем здесь спорить?
Даже если ФЯП не применимы во всех случаях, они прекрасно подходят для решения
некоторых классов задач. Архиваторы — неплохой пример. Пользовательские интерфейсы
тоже значительно удобнее описывать декларативно, чем императивно.
> вообще, довольно глупо тянуть чисто математическую абстракцию на чисто
> императивную архитектуру компьютера. всё-равно интерпретатору приходится
> конвертировать функциональную программу к императивной форме.
Машина должна работать, человек — думать. Функциональные языки повышают
производтельность программиста. Поэтому мне лично непонятно, почему "глупо" возложить
на железку задачу перевести высокоуровневые конструкции в низкоуровневые?
На C++ мне приходится делать это самостоятельно, и каждый раз ручками.
> особенно убивает реализация естественных для человека циклов через рекурсию и
> дальнейшие шаманства с "хвостовой оптимизацией"...
Зачем же так? Практическое программирование отличается от академического. Там, где в
ФП нужен цикл, программисты просто используют цикл.
http://www.squeezechart.com/main.html
http://www.metacompressor.com/
http://maxcompress.narod.ru/
http://www.maximumcompression.com/data/s…
Freearc при сопоставимой степени сжатия работает быстрее. При сопоставимой скорости
сжимает лучше. С чем здесь спорить?
Даже если ФЯП не применимы во всех случаях, они прекрасно подходят для решения
некоторых классов задач. Архиваторы — неплохой пример. Пользовательские интерфейсы
тоже значительно удобнее описывать декларативно, чем императивно.
> вообще, довольно глупо тянуть чисто математическую абстракцию на чисто
> императивную архитектуру компьютера. всё-равно интерпретатору приходится
> конвертировать функциональную программу к императивной форме.
Машина должна работать, человек — думать. Функциональные языки повышают
производтельность программиста. Поэтому мне лично непонятно, почему "глупо" возложить
на железку задачу перевести высокоуровневые конструкции в низкоуровневые?
На C++ мне приходится делать это самостоятельно, и каждый раз ручками.
> особенно убивает реализация естественных для человека циклов через рекурсию и
> дальнейшие шаманства с "хвостовой оптимизацией"...
Зачем же так? Практическое программирование отличается от академического. Там, где в
ФП нужен цикл, программисты просто используют цикл.
мне как-то нет дела до всяких "независимых бенчмарков". своим глазам я доверяю больше.
проблемы начинаются, когда нужно совместить несколько задач в одном приложении. тут и получается тормозящая химера.
не надо путать декларативные языки с функциональными. на чисто функциональном языке, например, невозможо сделать простой чекбокс на форме. чтобы изменить его состояние, нужно отправить всё окно на съедение автоматическому сборщику мусора и с нуля сгенерировать новое, но с другим состоянием чекбокса.
по этой причине чистый функциональный подход нигде и не применяется - только для отдельных вычислительных тасков.
в то же время декларативный подход вполне допускает динамическое изменение состояния.
например: <a href="javascript:this.innerHTML='yes'">no</a>
не надо судить об императивном программировании лишь по одному убогому, но крайне популярному представителю.
там, где программисты просто используют цикл - там уже нет ФП. это самый обычный императивный язык с функциями, где программа из проского списка комманд переписана через последовательность вызова этих самых функций.
проблемы начинаются, когда нужно совместить несколько задач в одном приложении. тут и получается тормозящая химера.
не надо путать декларативные языки с функциональными. на чисто функциональном языке, например, невозможо сделать простой чекбокс на форме. чтобы изменить его состояние, нужно отправить всё окно на съедение автоматическому сборщику мусора и с нуля сгенерировать новое, но с другим состоянием чекбокса.
по этой причине чистый функциональный подход нигде и не применяется - только для отдельных вычислительных тасков.
в то же время декларативный подход вполне допускает динамическое изменение состояния.
например: <a href="javascript:this.innerHTML='yes'">no</a>
не надо судить об императивном программировании лишь по одному убогому, но крайне популярному представителю.
там, где программисты просто используют цикл - там уже нет ФП. это самый обычный императивный язык с функциями, где программа из проского списка комманд переписана через последовательность вызова этих самых функций.
> мне как-то нет дела до всяких "независимых бенчмарков". своим глазам я доверяю больше.
Но я Вашим глазам не доверяю. Те ссылки,
которые я привёл выше, они от независимых
исследователей, имеющих вес. Про Вас мне
ничего не известно, так что я могу предполагать
подтасовку фактов, либо просто несостоятельность
в деле сравнения архиваторов. Извините.
> не надо путать декларативные языки с функциональными.
А я и не путаю. Декларативные языки — это
подмножество функциональных, предназначенные
для описания.
> на чисто функциональном языке, например, невозможо сделать простой чекбокс на форме. чтобы изменить его состояние, нужно отправить всё окно на съедение автоматическому сборщику мусора и с нуля сгенерировать новое, но с другим состоянием чекбокса.
Я себе сам процесс представляю по другому.
На входе мы имеем описание окна, которое
разворачивается в низкоуровневые (императивные)
инструкции. Вот это вот разворачивание
гораздо проще делать на ФПЯ.
> не надо судить об императивном
> программировании лишь по одному
> убогому, но крайне популярному
> представителю.
[ржОт]
Я на императивных языках пишу с 1988-го
года. А ФП изучаю, дай бог, года три, и то
не очень плотно. Уж если и могу о чём
судить, так об императивном
программировании. :)
> там, где программисты просто используют
> цикл - там уже нет ФП. это самый обычный
> императивный язык с функциями, где
> программа из проского списка комманд
> переписана через последовательность
> вызова этих самых функций.
Я никогда не рассматривал этот вопрос
с позиций или-или. И Руби, и Хаскель позволяют
писать и императивно, и функционально. Всегда
есть возможность выбрать подходящую парадигму.
А вот Си++ функционально писать позволяет
с большим трудом (я реализовывал нечёткую
логику на Си++, там слишком многословно
получается — т.е. можно, но непросто).
Но я Вашим глазам не доверяю. Те ссылки,
которые я привёл выше, они от независимых
исследователей, имеющих вес. Про Вас мне
ничего не известно, так что я могу предполагать
подтасовку фактов, либо просто несостоятельность
в деле сравнения архиваторов. Извините.
> не надо путать декларативные языки с функциональными.
А я и не путаю. Декларативные языки — это
подмножество функциональных, предназначенные
для описания.
> на чисто функциональном языке, например, невозможо сделать простой чекбокс на форме. чтобы изменить его состояние, нужно отправить всё окно на съедение автоматическому сборщику мусора и с нуля сгенерировать новое, но с другим состоянием чекбокса.
Я себе сам процесс представляю по другому.
На входе мы имеем описание окна, которое
разворачивается в низкоуровневые (императивные)
инструкции. Вот это вот разворачивание
гораздо проще делать на ФПЯ.
> не надо судить об императивном
> программировании лишь по одному
> убогому, но крайне популярному
> представителю.
[ржОт]
Я на императивных языках пишу с 1988-го
года. А ФП изучаю, дай бог, года три, и то
не очень плотно. Уж если и могу о чём
судить, так об императивном
программировании. :)
> там, где программисты просто используют
> цикл - там уже нет ФП. это самый обычный
> императивный язык с функциями, где
> программа из проского списка комманд
> переписана через последовательность
> вызова этих самых функций.
Я никогда не рассматривал этот вопрос
с позиций или-или. И Руби, и Хаскель позволяют
писать и императивно, и функционально. Всегда
есть возможность выбрать подходящую парадигму.
А вот Си++ функционально писать позволяет
с большим трудом (я реализовывал нечёткую
логику на Си++, там слишком многословно
получается — т.е. можно, но непросто).
1. сам-то замерял?
2. наоборот. ртфм.
3. и что, каждый раз при изменении окна разворачивать по новой?
4. конкретные языки назови.
5. кроме сипипи
2. наоборот. ртфм.
3. и что, каждый раз при изменении окна разворачивать по новой?
4. конкретные языки назови.
5. кроме сипипи
1. Мы уже на "ты"?
2. Да, это я поторопился написать.
Естественно, наоборот.
3. Нет. Один раз описать логику работы,
транслировать её в низкоуровневый код,
а он уже будет работать.
4. Языки, на которых писал? Язык
Ассемблера ZX Spectrum и x86/386,
Си, Паскаль, Фортран, Фоал, Бейсик,
Си++, Object Pascal, Perl, PHP,
Java, C#.
5. Реплики не понял.
2. Да, это я поторопился написать.
Естественно, наоборот.
3. Нет. Один раз описать логику работы,
транслировать её в низкоуровневый код,
а он уже будет работать.
4. Языки, на которых писал? Язык
Ассемблера ZX Spectrum и x86/386,
Си, Паскаль, Фортран, Фоал, Бейсик,
Си++, Object Pascal, Perl, PHP,
Java, C#.
5. Реплики не понял.
>естественных для человека циклов
То-то я смотрю у нас вся математик в циклах! Для человека циклы настолько же неестественны как и рекурсия, вощемто.
А рекурсия намного более выразительно в большинстве случаев. И довольно глупо тащить на процессор языки отличные от машинных комманд, все равно ведь компилятор их туда развернет.
То-то я смотрю у нас вся математик в циклах! Для человека циклы настолько же неестественны как и рекурсия, вощемто.
А рекурсия намного более выразительно в большинстве случаев. И довольно глупо тащить на процессор языки отличные от машинных комманд, все равно ведь компилятор их туда развернет.
И? Гигабайт памяти стоит сейчас меньше тысячи рублей. А через год будут стоить 500.
Вы на чём собираетесь экономить?
Зачем ОС, которая умещается на дискету, если удельная стоимость USB-диска на порядки ниже? То, чем
занимаются минуетные ребята, это 70-е годы программирования (уместить программу в 64К). Мы с Вами можем
решать другие задачи, те, про которые в 70-е даже не мечтали. Зачем себя ограничивать?
Вы на чём собираетесь экономить?
Зачем ОС, которая умещается на дискету, если удельная стоимость USB-диска на порядки ниже? То, чем
занимаются минуетные ребята, это 70-е годы программирования (уместить программу в 64К). Мы с Вами можем
решать другие задачи, те, про которые в 70-е даже не мечтали. Зачем себя ограничивать?
затем, что каждое приложение стремится заюзать всю свободную память. чем больше среднему пользователю доступно памяти, тем более развязно пишут свои программы разработчики. как не мог я пять лет назад запустить больше десяти средних приложений без риска угодить в своп, так не могу и сейчас.
затем, что в мой ноут больше гига не всунуть, а есть платформы в которых памяти и того меньше.
затем, что мне нужно тестировать свои программы в десяти различных средах и из-за их прожорливости приходится останавливать одну виртуальную машину, чтобы запустить другую.
затем, что на гигабайт usb-диска я лучше залью сотню-другую песен и буду наслаждаться разнообразием репертуара в дороге.
затем, что в мой ноут больше гига не всунуть, а есть платформы в которых памяти и того меньше.
затем, что мне нужно тестировать свои программы в десяти различных средах и из-за их прожорливости приходится останавливать одну виртуальную машину, чтобы запустить другую.
затем, что на гигабайт usb-диска я лучше залью сотню-другую песен и буду наслаждаться разнообразием репертуара в дороге.
> затем, что каждое приложение стремится заюзать всю свободную память.
Это не аргумент, это лозунг. Мы с Вами, как программисты, можем оперировать
тезисами и аргументами? Это же не митинг.
> чем больше среднему пользователю доступно памяти, тем более развязно пишут свои
> программы разработчики.
Моё личное мнение по этому вопросу с Вашим не совпадает. Я понмю времена, когда промышленные
программы писали на языке ассемблера. Потом их стали писать на C и на Паскале. Потом на C++.
Теперь на Java и C#.
И каждый раз находился кто-то, кто говорил: "Куда катится мир?" Каждый раз.
> затем, что в мой ноут больше гига не всунуть, а есть платформы в которых памяти и того меньше.
Да, есть микроконтроллеры, и там пишут на ассемблере и Си. Да, есть устаревшая техника, которую
жалко выбрасывать. Эти факты не отменяют существующей тенденции в мире ПК: памяти становится
больше, процессоры становятся многоядерными.
> затем, что мне нужно тестировать свои программы в десяти различных средах и из-за их
> прожорливости приходится останавливать одну виртуальную машину, чтобы запустить другую.
Да, одни компьютер не в состоянии заменить 10 компьютеров того же класса. С моей точки зрения,
здесь нет ничего удивительного.
> затем, что на гигабайт usb-диска я лучше залью сотню-другую песен и буду наслаждаться разнообразием репертуара в дороге.
А вот здесь я просто не понял. Поправьте меня, если я ошибаюсь: вы на флешку запишите музыку,
вместо того, чтобы хранить там переносимую ОС? А ОС запишите на дискету?
Это не аргумент, это лозунг. Мы с Вами, как программисты, можем оперировать
тезисами и аргументами? Это же не митинг.
> чем больше среднему пользователю доступно памяти, тем более развязно пишут свои
> программы разработчики.
Моё личное мнение по этому вопросу с Вашим не совпадает. Я понмю времена, когда промышленные
программы писали на языке ассемблера. Потом их стали писать на C и на Паскале. Потом на C++.
Теперь на Java и C#.
И каждый раз находился кто-то, кто говорил: "Куда катится мир?" Каждый раз.
> затем, что в мой ноут больше гига не всунуть, а есть платформы в которых памяти и того меньше.
Да, есть микроконтроллеры, и там пишут на ассемблере и Си. Да, есть устаревшая техника, которую
жалко выбрасывать. Эти факты не отменяют существующей тенденции в мире ПК: памяти становится
больше, процессоры становятся многоядерными.
> затем, что мне нужно тестировать свои программы в десяти различных средах и из-за их
> прожорливости приходится останавливать одну виртуальную машину, чтобы запустить другую.
Да, одни компьютер не в состоянии заменить 10 компьютеров того же класса. С моей точки зрения,
здесь нет ничего удивительного.
> затем, что на гигабайт usb-диска я лучше залью сотню-другую песен и буду наслаждаться разнообразием репертуара в дороге.
А вот здесь я просто не понял. Поправьте меня, если я ошибаюсь: вы на флешку запишите музыку,
вместо того, чтобы хранить там переносимую ОС? А ОС запишите на дискету?
Вопрос, на мой взгляд, слишком общий. С моей точки зрения, язык Си очень выразительный.
И вопрос эффективности очень многозначный. Через 2 года у народа массово будут стоять 2-4-8 ядерные машины.
Для Си++ программистов мультитредные приложения — это отдельный геморрой. А для функциональщиков — что-то такое,
о чём даже не стоит беспокоиться.
И вопрос эффективности очень многозначный. Через 2 года у народа массово будут стоять 2-4-8 ядерные машины.
Для Си++ программистов мультитредные приложения — это отдельный геморрой. А для функциональщиков — что-то такое,
о чём даже не стоит беспокоиться.
Прозреваю сиплюсплюсера. Никогда не упирались в потолок выразительности своего языка? Довольно безответсвенно заявлять о ущербности языка, потому что на нем нельзя написать ОС. Гуглить IoL4 до просветления.
Прозреваю очередного тролля, предпочитающего навешивать ярлыки.
l4 - это ядро, написанное на цпп. под ним запускается iovm - виртуальная машина ио, написанная на си. и уже под ней - приложения, написанные на io.
l4 - это ядро, написанное на цпп. под ним запускается iovm - виртуальная машина ио, написанная на си. и уже под ней - приложения, написанные на io.
Группа вконтакте, посвященная Ио:
http://vkontakte.ru/club3618361
http://vkontakte.ru/club3618361
Написал для прикола тоже самое на Python gist.github.com/911702
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Io programming language