Ну почему люди используют столь отстойные языки?!

nsav, напиши статью о том, почему английский хуже чем лисп, а русский хуже чем хаскель. Мы все с огромным удовольствием почитаем.

опередил:)

LoveFactory lf = LoveFactory().newInstance();
Couple c = lf.makeCouple("Маша", "Вася");
c.makeLove(); // result ignored

>Поясняю. Запись 2+2 мне более понятна, чем + 2 2.Я не одинок, так как на заборах пишут коля + оля = Л и никак иначе ;)

Ну давайте еще на заборных писак ориентироваться...

Нет, все-таки на здравый смысл, зачатками которого заборные писатели таки обладают.

> Запись 2+2 мне более понятна, чем + 2 2

Кстати, придираться к префиксной записи в лиспе имхо неразумно. Подумайте часто ли вы используете функции, которые более привычны в суффиксной записи (+ - / * степень, и возможно ещё парочку), ясно что не часто, особенно в более высокоуровневых языках. А все остальные функии используются в такой же префиксной форме как в других языках. Так что эта проблема надумана. К тому же можно сделать макрос для работы с арифм. функциями в суффиксной форме...

Вот сейчас специально проверил: в коде одной моей прожки 4К строк кода. арифмитических операций - 5.

> ага. скоро будут писать (defmacro Л '(+, коля, оля))

Я недавно видел, как сопливый шкет рисовал триграмматон на заборе через трафарет. Очевидно, тоже книг про Лисп обчитался и решил всё макрами делать.

Вот тут вынужден возразить: http://www.cliki.net/infix

> часто ли вы используете функции, которые более привычны в суффиксной записи

Ага, ага, а хаскеллисты оченно любят запись (операнд `функция` операнд). Наверное тоже от большой любви к префиксной нотации, да? Специально себе геморрой придумывали, да?

> ЗЫ: я все еще жду эквивалента Parsec на C.

Не Си, но Си++ - смотреть на Boost, там есть. И гораздо читабельнее, чем этот маловнятный Parsec. И быстрее, конечно же, хоть и тоже рекурсивным спуском делается.

А где же аффтар ? аффтара потеряли ?!!!

приблизительно необходимость языка можно вывести анализируя рынок труда.. как отношения вакансий на этом языке / общему числу вакансий..(можно добавить весовые коэф. по оплате)

Необходимость haskel в россии - исчезающе малая величина, lisp держится за счёт автокада и если autolisp lisp`ом не считать - то примерно равен хаскелю..На западе - будут ТЕЖЕ относительные цифры. Дык что haskel,lisp,etc изучаются ради вентилятора.

Хочешь быть дворником ? забей на C/C++/pascal/java..

Вы, сударь, неверно мыслите. Не видите, куда ветер дует-с.

На C/C++ и уж тем более Pascal забить можно и нужно. Java - это будущее программирования. Всё остальное неизбежно вымрет.

> На C/C++ и уж тем более Pascal забить можно и нужно. Java - это будущее программирования. Всё остальное неизбежно вымрет

на чём-же будет писаться jvm ? системо-зависимые и real-time вещи ?? нее сударь, у старичка С хрен побольше чем у java ;-) Его не пере@#@бёшь.

> на чём-же будет писаться jvm ?

Ну вы тут все як дитяты малые...

http://sourceforge.net/projects/joeq

Никто вообще не мешает забутстрапить JVM через JVM. И никакие C для этого не нужны.

> На C/C++ и уж тем более Pascal забить можно и нужно. Java - это будущее программирования. Всё остальное неизбежно вымрет.

Не. Это противоречит здравому смыслу. Все равно что сказать лучший текстовый редактор - Ворд, все остальное либо уже сдохло, либо скоро сдохнет.

Наличие нескольких мейнстримовских языков программирования есть необходимое условие баланса в области средств разработки. Гигантоманские монстры с большим наследием за плечами вроде Си++, Си шарп и Джава со временем вымирают, на их место приходят новые более прогрессивные языки и т.д.

Всё верно. Вымирают. Вот Си и Си++ и вымирают, а молодая Java остаётся.

Насчет Си++ - согласен, вымрет, уже начал разваливаться под собственной тяжестью. Си маловероятно что вымрет. Слишком многим нужен кроссплатформенный ассемблер. В худшем случае уступит свои позиции в области клепания уевого хлама, например, той же жабе или си шарпу, за отсутсвием реальных альтернатив.

> Слишком многим нужен кроссплатформенный ассемблер.

JVM - давно уже lingua franca для переноса между платформами.

Низкоуровневое программирование на Java - не проблема.

> А еще и говорят, что на С даже ногу можно прострелить... :/ А каком простреле ноги может идти речь, если даже с элементарными задачами язык справится не может?

Вы определитесь сначала, кто из вас не может посчитать минимум: Вы или язык Си.

> Низкоуровневое программирование на Java - не проблема.

Я конечно не являюсь глубоким знактоком джава, но насколько я представляю в этом языке было сделано все чтобы уйти от ассемблероподоности Си/Си++. В частности отсутсвие указателей, только ссылки. GC опять таки. Полагаю все это не очень хорошо сказывается на особенностях джавы как низкоуровневого языка. Си при таком раскладе всяко лучше.

Parsec нечитаем? Да у вас Haskell-офобия какая-то, или вообще FP-фобия.

Spirit - вешь хорошая, но кстати на Java (языке будущего) она не возвможна.

Да? А как насчет программирования AVR-ок на Java?

Избавление от ассемблероподобности - это переход к декларативному программированию. В Жабе ничего похожего (кроме автоматического управления памятью) нет. С++ и то ближе к функциональному программированию, чем жаба - см. упоминавшийся уже Spirit.

Жаба - КОБОЛ 90-х - 2000-х - так распространена и так же убога.

> Полагаю все это не очень хорошо сказывается на особенностях джавы как низкоуровневого языка. Си при таком раскладе всяко лучше.

Вы неверно полагаете. J2ME - вполне неплохо живёт в весьма ограниченных по ресурсам условиях. GC - не помеха, а благо. От указателей - толку всё равно никакого, один вред.

> Parsec нечитаем?

Конечно же! Код с использованием Parsec сильно похож на EBNF? Ни разу не похож! Фпечку его! Говорим "парсер" - подразумеваем EBNF. Всё, что от этой нотации отличается - лишняя сущность, которая пойдёт под бритву имени Оккамского.

> Spirit - вешь хорошая, но кстати на Java (языке будущего) она не возвможна.

Нас и ANTLR неплохо кормит, благо, с такими мощными системами сборки, как ant, нас нисколечко не напряжет дополнительный проход препроцессоров перед компиляцией, нет нужды объединять компилятор с макропроцессором.

А если вдруг для каких целей, отличных от понятных, нужных и благородных задач АОП нам и потребуется шибко умный макропроцессор, то мы просто возьмём вот его:

http://www.kimbly.com/code/jatha/

> Да у вас Haskell-офобия какая-то, или вообще FP-фобия.

Нет, у меня всего лишь дуракофобия и фанатикофобия. Я - рационалист. Глупые технологии меня не привлекают нисколько.

> В Жабе ничего похожего (кроме автоматического управления памятью) нет.

Пусть тот, кто первым осмелится сказать, что описания из http://www.hibernate.org/ не декларативны, смело бросит в меня томик CLTL2.

> С++ и то ближе к функциональному программированию

О, теперь уже функциональное = декларативное. Офигеть можно!

Оно нам надо? У нас есть ARM, есть JavaCard.

> От указателей - толку всё равно никакого, один вред.

Не вред, а бред. Указатели предоставляют мощный инструмент для работы с памятью. Можете указать на сходную по возможностям альтернативу ?

железка на ARM обойдется раз в десять дороже железки на AVR. Разные весовые категории.

Ты видишь в языке Java указатели? Нет их там. И не надо. И почему-то никто не плачет по ним.

Мы же про не очень отдалённое, но будущее говорим. Когда процессор, тянущий Java, будет такой же дешевой грязью, как сейчас всякие PIC-и да AVR-ы. Да и сейчас эту грязь лучше на Форте программировать, чем на Си.

Ясно что их там нет. Жаба не является ассемблер-реплейсемнтом. Редко у какого жаба программера встанет задача скопировать буфер размером N байт в видеопамять которая меппится на аресное простанство процессора начиная с физического адреса X. ССылки хороши для того чтобы ссылаться на отдельные структуры данных, указатели хороши для того чтобы адресовать какие угодно куски памяти, бегать по ним туда сюда и по мере необходимости чихать на всякие условности вроде типов данных. Железка типы данных не понимает. Она понимает только биты и байты. На этом языке с ней и разговаривают.

Разуммется все это сказано в контексте низкоуровневого программинга для пипетошных железок. Программист на x86, разрабатывающий софт функционир. под управлением нормальной ОС такими вопросами как пересылка буферов заниматься не будет. Ему нужны более высокоуровневые абстракции. Жабы, перлы, питоны и прочая ...

> Мы же про не очень отдалённое, но будущее говорим. Когда процессор, тянущий Java, будет такой же дешевой грязью, как сейчас всякие PIC-и да AVR-ы.

Не думаю, что этот рынок будет сильно развиваться в сторону увеличения архитектурной сложности микроконтроллеров. С момента выхода классического Intel 8051 сколько времени прошло? а воз и ныне там. только Atmel произвел действительно революционный ход переведя свои контроллеры с CISC системы комманд от Intel 8051 на собственную RISC. Пожалуй и все. Технологии меняются, размеры уменьшаются, а класс пипетошных микроконтроллеров до сих пор рулит и уходить со сцены не собирается. К ним отношение другое, не такое как к настольным ПК. К ним относятся как к гайке или как болту в какой-нибудь машине, работает ну и ладно. Часто придумывают новые типы гаек или болтов ?

Зачем в контроллер который рулит датчиком давления в колесе какой-нибудь бехи вставлять аппаратную или программную жаба машину ?

Ладно, убедил. Такое будем на Форте программировать. Си не нужен.

Картина маслом и сыром - дрова видюхи на жабе, перле и питоне...

Речь шла именно о разнице между высокоуровневым программенгом и низкоуровневым. Разумеется всякие драйверы опять таки пишутся на сях а не на жабах.

Дрова видюхи на Форте я легко могу себе представить. На Java - в принципе тоже можно, при наличии соответствующего процессора и чуть-чуть кодогенерации во время выполнения (чем всякие любители Лиспа хвастаются обычно, забыв, что в Java это в разы легче достаётся). Перл и Питон никак не проканают, ибо динамические и принципиально в силу этого интерпретируемые.

А надо не на сях писать, об что и спич идёт.

Все таки не во время выполнения, а во время компиляции (defmacro), хотя у eval тоже своя область применения есть. В любом случае кодогенерация на Lisp проще чем на Java - в Java AFAIK quasiquote нет.

И не надо нам вашего backquote. Мы так напишем:

code.emit(Instr.PUSH, env.var("X")).emit(Instr.PUSH, env.var("Y")).emit(Instr.ADD).finish();

Во-во, на асме - изврат. Не то что eval.

Вообще-то много чего не надо (в принципе). Так почему же программы не писать для машины Тьюринга?

> Во-во, на асме - изврат.

Совершенно аналогично всё делается и для языков сколь угодно более высокого уровня, включаяя саму Java (самый высокоуровневый язык из существующих в природе).

Не отрицаю этого. Но лично мне больше нравится `(defun ,fname () ...), чем FunDef(fname).params(nil).body(...)

> самый высокоуровневый язык из существующих в природе

Вот с этим категорически не согласен

Разница исключительно в синтаксисе, а не в семантике. Не серьёзно.

Приведите пример более высокоуровневого языка, который при этом не был бы узкоспециализированным. Да, конечно же SQL, или даже полноценный язык Mathematica - более высокоуровневые и абстрактные. Но они - узкоспециализированные. А из языков общего назначения Java - выше всех.

1. Если компилятор Java входит в JRE, тогда разница только в синтаксисе.

2. Вы будете крайне удивлены, но OCaml, Common Lisp и Haskell очень даже не узкоспециализированные языки. Диалекты этих языков компилируются в байткод JVM и CLR, что позволяюет использовать в них библиотеки Java и .NET (соответсвенно).