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