LINUX.ORG.RU
Ответ на: комментарий от anonymous

> Ты вообще сам хоть понял что написал?

А ты, я вижу, нет :(

> Поясни на примере, где setq будет "читабельнее" знака равенства.

речь идёт не он знаке равенства а об участке кода, построенном на зверинце из префиксных, инфиксных операторов, функций и ещё кучи всево, не подчиняющейся одним правилам, как в лиспе, где форма записи - одинаковое.

bugmaker ★★★★☆
()
Ответ на: комментарий от bugmaker

> речь идёт не он знаке равенства а об участке кода, построенном на зверинце из префиксных, инфиксных операторов, функций и ещё кучи всево, не подчиняющейся одним правилам, как в лиспе, где форма записи - одинаковое.

Это называется ставить "удобство" машины выше удобства человека. Точно также как все эти скобки и ";" в Цэ и прочие подобные маразмы.

anonymous
()
Ответ на: комментарий от yyk

> Вы "обсуждаете" не _применимость_ а _применяемость_, что есть совсем разные вещи... :)

Да, пожалуй соглашусь.

> А самому поискать? Или будем меряться - кто эффективнее использует google? :)

Я должен искать аргументы за своих оппонентов? Это что-то новое в искусстве ведения дискуссии...

> Ну вот - одну нашёл :)

Ну, типа да. Правда, у них web presentation layer на PHP, судя по схеме ;), и по масштабам это ни разу не гугль, но сойдет. Итак, на 1100-ом сообщении мы выяснили, что на CL таки можно писать программы ;).

anonymous
()
Ответ на: комментарий от bugmaker

> Давай. Только погодим, пока тот чел с с++/стл подтянецо. Я подозреваю он просто слил, но из вежливости погодим.

Давай C++ не ждать, или подожапть до середины завтра. Ничего принципиально нового по сравнению с питоном мы не увидим. То же ООП и метапрограммирование (в терминологии Страуструпа) что и в питоне, только без sqlalchemy и более многословно (но быстрее и typesafe, это чтобы не обижать фанатов C++)).

У меня такое предлодение:

1. Ты делаешь полный клон моей программы на лиспе и постишь сюда. В смысле клон по функциональности, используя макросы и прочие лисповые идиомы.

2. Ты постишь свой вариант, а я делаю его клон на питоне, т.е. таже функциональность, но с использованием ООП и т.д...

> винт давно почищено, это несложно было даже срецтвами баша сделать. А твоёй прогой на практике ИМХО пока не удасца пользовацо, там даже обхода дерева каталохов на фс нету, вручную файло нужно добавляти.

А это я Раймонда начитался. :-) Это же опенсорц. Ядро есть, осталось дописать ходилку по дереву, ГУЙ и можно зарабатвыать на саппорте...

redvasily
()
Ответ на: комментарий от tailgunner

>>>ИМХО, там дело было не в "узком месте", а в глючности редактора - для продакшена это было недопустимо :) Но это читая спекуляция. >>Домыслы пошли ?

>Ну, там написано "чистая спекуляция" (с опечаткой, правда), но >если вам больше нравится слово "домыслы" - пожалуйста :)

Причем тут предположения, он честно и пишет, что мол переписать на другом языке будет сложновато. Но где написано про глючность редактора ?

>> Вы тоже, я смотрю, довольно свободно оперируете терминами в свою >>пользу.

>Ээээ... примеры?

Берем фразу из статьи, добавляем домыслы и вот уже вроде на правду смахивает. Вот тут вывод просто потрясающий:

"Вроде Яху его переписали? Из чистой вредности, конечно. Но всё равно, получается, что продал Грэм прототип, не для "риального прадакшена" (C) (R) (TM)"

>Для протокола - мне понравилась статья, я скачал и начал читать >его "On Lisp".

Респект. По-моему, без всякого фанатизма будет сказано, это довольно интересная/познавательная книга и "ANSI CL" у Грэма тоже неплохая, особенно в бумажном виде. Но Practical Common Lisp Сабеля все же практичнее ;-)

>>> Сегодня бы на Лиспе скорее всего вообще все было написано

>Отвечу более развернуто - сослагательное наклонение здесь >неуместно. Если есть факты - поделитесьт

Ну производительность сегодняшних лиспов даже на бросовом железе достаточна чтобы выдержать нагрузки, которые раньше только Си выдерживал. SBCL и CMUCL имеют неплохие оптимизирующие компиляторы, поэтому препятствий писать вообще все на Лиспе теперь нет никаких. Кстати переписали они на плюсы и перл например. А завтра и мастера плюсов и перла повыведутся, будут переписывать на какую-нибудь решетку. Насколько я знаю в силу некоторой неторопливости изменения стандарта и т.д. программы на Лиспе оказываются довольно живучими, зачем так дергаться если все работает. Неужели Грэм там столько понаписал, что эти "гении" разобраться не смогли и им было проще переписать по новой. C++ в сопровождении IMHO посложнее Лиспа будет, если конечно код на Лиспе не полная лапша.

>С несколько меньшим. Глючные программы я лично видел куда чаще, чем >приступы даунизма у менеджеров

Ну не обязательно даунизма, может быть просто приступ страха, что мол все вон как делают, а я рискую, лучше сделаю как все, за это не увольняют. Это трудно отрицать.

Лисп вывел их на орбиту, обеспечил победу в гонке с конкурентами, а С++ для поддержки морально комфортнее получается, вроде как менеджменту чувства стабильности захотелось. Тогда это плюс и Лиспу и С++, каждый при деле.

anonymous
()
Ответ на: комментарий от redvasily

> Давай C++ не ждать, или подожапть до середины завтра.

ладно, давай. Я тоже думаю чё это был пустой трёп и он тут непоявицо больше.

> Ничего принципиально нового по сравнению с

Зато было бы презабавно

> У меня такое предлодение:

Поддерживаю, но как я упоминал ранее, давай как можно точнее определимся, чё она должна делать а чё - не. Ибо твой код выглядит как сильно выходящий за рамки предложенной мной задачи. Вопрос о применении дазы банных требует отдельного обсуждения. ИМХО, оно тут просто не нужно. Были ли утя какие-нть непонятные мне причины использовать, или сделал это только ради удобства создания проги?

Также, не желаеш ли создать код, соотвествующий первоначяльно предложенной, т.е. некая структура данных и функции добавления и поиска, или уже предложенное тобой можно щитать таковым? Опять, умя не было в планах привлекать для такой мизерной задачи дазу банных :D

bugmaker ★★★★☆
()
Ответ на: комментарий от anonymous

Вообще, я сильно подозреваю, что было переписато исключительно в целях вытягивания бабла. Потому что я наблюдал такое явление как переписывание с одного наречия на другое без всяких причин, кроме финансовых _многократно_. Насколько я знаю, причины, по которым переписывалось, так никогда и не были указаны руководством (это говорит в пользу моей догадки ИМХО). А раз достоверно ничё неизвесно, ИМХО обсуждение этого факта не очень продуктивно, хотя и положительно сказываецо на размерах топика.

bugmaker ★★★★☆
()
Ответ на: комментарий от bugmaker

> пипл, знакомый с програмёжем в основном по бейсику, более поймёт a=7 чем (setq a 7)

a=7 и к математической нотации ближе, так что человек, не знакомый с Бейсиом вообще, тоже более пойме a=7

>> Посмотри в словаре, что такое "рефакторинг".

>Я ужо. Только не могу понять, почему же он появилсо только в ООП? Или не-ООПнутых прог сравнительной сложности не было или они таки не нуждались в "рефакторинг"?

Были. Нуждались. Но _термин_ "рефакторинг" появился только недавно (лет 10). Сам процесс был, наверное, начиная с самых ранних дней. Только называли его разные люди по-разному, а теперь есть один общепринятый термин (ты уж прости за это ООП вообще и доктора Д.Шмидта в частности :)).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> к математической нотации ближе

факт, поймёт, причём неправильно. Потому что это не "а равно семи" как в мотематике, а "присвоить значение сем к перемнной а". На этом преимущества такой записи заканчиваюцо, и как только задачя выходит за рамки пощитать чё-то несложное, недостатки начинают торчять в полный рост. Не велика ли жертва, принесённая только ради того, чтобы догадки человека несведущего в прогамёже были бы ближе к истине?

> Были. Нуждались.

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

bugmaker ★★★★☆
()
Ответ на: комментарий от bugmaker

> Хм. Задачя: составить структуру данных для хранения информации о
> том, в каких директориях находицо файл. Одинаковый файл может
> храницо в нескольких. Файлы щитаецо одинаковым если совпадает и
> имя и размер. Создать код, который 1) поштучно добавляет
> информацию (имя файла, размер, директория) в структуру, 2)
> составляет отдельно списки имён файлов, которые есть в равном N
> количестве, больше или меньше. Для каждово имени нужно передать
> также информацию о том, в каких директориях он. Возмёшся? Потом
> присовокуплю код на лиспе. 

Ну, ээ. Задачка, конечно, странная - я б такое делал на шелле
 (find -printf+sort+join+grep+awk) - было бы строчек 10 вместе с
 собственно обходом директорий. Но ты просил на плюсах? Да держи.
 Правда, здесь только про "равное N количество" - поленился я три
 (почти) одинаковых функтора рисовать.

Да, "давно не брал я в руки шашек" (отмазываюсь).

#include <string>
#include <set>
#include <map>
#include <iostream>
#include <iterator>

using namespace std;

struct FileId {
    size_t size;
    string name;

    FileId(string name_, size_t size_) : name(name_), size(size_) {};

    struct Eq {
        bool operator()(const FileId &a, const FileId &b) {
            return a.name < b.name ||  a.size < b.size;
        }
    };
};


typedef map< FileId, set<string>, FileId::Eq > FileDist;

void add_file(FileDist &files, string name, string dir, size_t size) {
    const FileId key(name, size);
    FileDist::iterator duplicate = files.find(key);
    files[key].insert(dir);
};

struct not_file_has_locations {
    size_t n;
    not_file_has_locations(size_t N) : n(N) {};
    bool operator()(pair< FileId, set<string> > p) {
        return p.second.size() != n;
    }
};

int main() {
    FileDist files;
    add_file(files, "a", "/foo", 1);
    add_file(files, "a", "/bar", 1);
    add_file(files, "b", "/foo", 1);
    add_file(files, "b", "/bar", 1);
    add_file(files, "b", "/baz", 1);
    add_file(files, "b", "/fred", 2);
    add_file(files, "c", "/foo", 3);

    FileDist files_with_2_locs;

    remove_copy_if(files.begin(), files.end(),
                    insert_iterator<FileDist>(files_with_2_locs, files_with_2_locs.begin()),
                    not_file_has_locations(2));

    for (FileDist::const_iterator i = files_with_2_locs.begin(); i != files_with_2_locs.end(); ++i) {
        cout << i->first.name << ":" << i->first.size << " in ";
        copy(i->second.begin(), i->second.end(), ostream_iterator<string>(cout, " "));
        cout << endl;
    }
}

anonymous
()
Ответ на: комментарий от anonymous

>>Ну, там написано "чистая спекуляция" (с опечаткой, правда), но >если вам больше нравится слово "домыслы" - пожалуйста :)

>Причем тут предположения

Я ничуть не против слова "домысл" в данном случае - потому что мое предположение сделано в пику лисперам и не поддержано никаими фактами. Я думал, очевидно, что это ирония.

>Берем фразу из статьи, добавляем домыслы и вот уже вроде на правду смахивает. Вот тут вывод просто потрясающий:

> "Вроде Яху его переписали? Из чистой вредности, конечно. Но всё равно, получается, что продал Грэм прототип, не для "риального прадакшена" (C) (R) (TM)"

Это снова была попытка иронизировать :/ Я думал, по нарочито искаженным словам и дурацкому набору значков это видно. Если серьезно - я думаю, что Яху купила многообещеющую _технологию_, вполне агностичную по отношению к языку реализации (см. про куски на Перле и Си), а не кодовую базу на CL.

> Но Practical Common Lisp Сабеля все же практичнее

На сайте Грэма не было других :) Кроме того, как-то комфортнее читать практика, за плечами которого успешные проекты.

> Ну производительность сегодняшних лиспов даже на бросовом железе достаточна

Производительность - это отнюдь не всё. Вспомни, процесс переписывания завершился в 2003, железо того времени не сильно отличалось от сегодняшнего. К тому же на Лиспе был написан _редактор сайтов_ - не самое критичный к производительности компонент. Значит, не только (или не столько) в производительности дело. Как минимум - найти специалистов по Лиспу сложнее (значит, дольше и дороже).

> А завтра и мастера плюсов и перла повыведутся

Ну. это несерьезно.

> С++ для поддержки морально комфортнее получается, вроде как менеджменту чувства стабильности захотелось.

А вот про "моральный комфорт" и "вроде как чувства стабильности захотелось" - домыслы. У Грэма по этому поводу ничего нет, из Яху он ушел, и в каком состоянии была кодовая база, каково всё это было сопровождать - нам неведомо.

tailgunner ★★★★★
()
Ответ на: комментарий от bugmaker

> вчера выполз троль с c++/STL. Отлистай и прочти, иначе много потеряеш.

Я читал, правда, не увидел там особого троллинга. Человек говорил здравые вещи. Просто не старался быть политически корректным в формулировках.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Вторая строчка в функции add_file лишняя, осталось от мозгового штурма (давно, да и мало, писал я на плюсах - приходилось в доку по STL подглядывать, на тему "а какая у нас семантика map::operator[]").

anonymous
()
Ответ на: комментарий от tailgunner

> > вчера выполз троль с c++/STL. Отлистай и прочти, иначе много потеряеш.

> Я читал, правда, не увидел там особого троллинга. Человек говорил здравые вещи. Просто не старался быть политически корректным в формулировках.

10x за понимание ;)

anonymous
()
Ответ на: комментарий от bugmaker

> Потому что это не "а равно семи" как в мотематике, а "присвоить значение сем к перемнной а".

В голове психически здорового человека это одно и то же. Лиспоидов это понятное дело не касается.

anonymous
()
Ответ на: комментарий от anonymous

> Это называется ставить "удобство" машины выше удобства человека.

любой код рано или поздно возникает потребность обрабатывать автоматически -- и тогда занозой в яопе встает вопрос: а какого хрена в Си есть две конструкции для одного и того же: if() else; и ?:

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

> любой код рано или поздно возникает потребность обрабатывать автоматически -- и тогда занозой в яопе встает вопрос: а какого хрена в Си есть две конструкции для одного и того же: if() else; и ?:

Вообще-то, между ними существует огромная разница... Как синтаксическая, так и семантическая.

anonymous
()
Ответ на: комментарий от anonymous

> Я должен искать аргументы за своих оппонентов? Это что-то новое в искусстве ведения дискуссии...

Неа, не так. Если грамотно "дискутировать", то кто-то должен подавать и "гипотезу", и доказательства. А остальные оценивать/критиковать. А "базар" типа "А на Х есть то, то и то. А что у вас есть на У?" к дискуссии никакого отношения не имеет ;)

> Итак, на 1100-ом сообщении мы выяснили, что на CL таки можно писать программы ;).

И так, на 1100-ом сообщении таки кто-то не выдержал, и превёл прямой линк на готовую прогу, а кто-то другой, кто ленился искать сам, согласился, что такие проги есть... Каюсь, больше так не буду - плохо кормить рыбой, надо учить пользоваться удочкой ;)

yyk ★★★★★
()
Ответ на: комментарий от bugmaker

> речь идёт не он знаке равенства а об участке кода, построенном на зверинце из префиксных, инфиксных операторов, функций и ещё кучи всево, не подчиняющейся одним правилам, как в лиспе, где форма записи - одинаковое

Но-но-но, не зарывайтесь, лейтенант! Cтандартная математическая нотация - тоже зверинец из префиксных, инфиксных операторов, функций и ещё кучи всево, не подчиняющейся одним правилам, типа дробной черты или (ужас!) знака интеграла. Это плохо? :)

ero-sennin ★★
()
Ответ на: комментарий от ero-sennin

> Cтандартная математическая нотация - тоже зверинец из префиксных, инфиксных операторов, функций и ещё кучи всево, не подчиняющейся одним правилам, типа дробной черты или (ужас!) знака интеграла. Это плохо? :)

конечно плохо. Этой нотацией пользуются только придурки физики. Реальные Математики общаются телепотичецки.

dilmah ★★★★★
()
Ответ на: комментарий от tailgunner

Просто так. Цитата из Юкихиро Матсумото (Matz) -- создателя Ruby:

Ruby is a language designed in the following steps:

* take a simple lisp language (like one prior to CL). * remove macros, s-expression. * add simple object system (much simpler than CLOS). * add blocks, inspired by higher order functions. * add methods found in Smalltalk. * add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory. Let's call it MatzLisp from now on. ;-)

Zubok ★★★★★
()
Ответ на: комментарий от anonymous

на лиспе это выгледит так:

создание структуры для хранения:

(setq hash (make-hash-table :test #'equal))

в реальных прогах правда setq практически не используецо, вместо нево
 (let ((hash (make-hash-table :test #'equal)) 
 (...остальные переменные...)) ...код...), но для проверки
 в интерпретаторе так удобнее.

добавление файлов:

(push "/foo" (gethash (list "file.txt" 777) hash))
(push "/bar" (gethash (list "file.txt" 777) hash))
(push "/foobar" (gethash (list "file.txt" 777) hash))
(push "/bar" (gethash (list "file1.txt" 888) hash))
(push "/foo" (gethash (list "file1.txt" 888) hash))
(push "/foo" (gethash (list "file2.txt" 999) hash))

поиск и чепять фаела, который бывает ?N раз, и где находицо, функция:

(defun find-and-get (h &key (count 0) (cmp #'>))
  (let ((r nil))
    (maphash (lambda (k v)
      (when (funcall cmp (length v) count)(push (list k v) r))) h)
  r))

по умолчянию вызватое (find-and-get hash) выводит большее 0.
Вызватое как (find-and-get hash :count 2) выводит большее 2.
Вызватое как (find-and-get hash :count 2 :cmp #'<) выводит меншее 2.
Вызватое как (find-and-get hash :count 2 :cmp #'=) выводит равное 2.
итд.

Комментарии?

bugmaker ★★★★☆
()
Ответ на: комментарий от anonymous

Кстати, прошу извинить за напрасную худую мысль про тебя, я ашыбочьно подумал чё ты покинул нас ужо :(

bugmaker ★★★★☆
()
Ответ на: комментарий от tailgunner

> не увидел там особого троллинга. Человек говорил здравые вещи

ну, то, что на STL работать проще и легче чем на лиспе - вещ изумительно нездравая.

bugmaker ★★★★☆
()
Ответ на: комментарий от tailgunner

> Как минимум - найти специалистов по Лиспу сложнее (значит, дольше и дороже).

ИМХО плохой аргумент, очень плохой. Разница в продуктивности - на порядки, а в зарплате - в разы. Вдобаваок, быдлолиспокодер выдаст продукт намного более качественный, "в нагрузку".

bugmaker ★★★★☆
()
Ответ на: комментарий от anonymous

>> Потому что это не "а равно семи" как в мотематике, а "присвоить значение сем к перемнной а".

> В голове психически здорового человека это одно и то же. Лиспоидов это понятное дело не касается.

Конешно не касаецо, иначе с каких это делов для одново и тово же в сях и большинстве других наречий есь разные операторы = и == для одново и товоже?

bugmaker ★★★★☆
()
Ответ на: комментарий от anonymous

>> любой код рано или поздно возникает потребность обрабатывать автоматически -- и тогда занозой в яопе встает вопрос: а какого хрена в Си есть две конструкции для одного и того же: if() else; и ?:

> Вообще-то, между ними существует огромная разница... Как синтаксическая, так и семантическая.

а в лиспе if этих обеих заменяет, и без всяково неудобства...

bugmaker ★★★★☆
()
Ответ на: комментарий от ero-sennin

>> речь идёт не он знаке равенства а об участке кода, построенном на зверинце из префиксных, инфиксных операторов, функций и ещё кучи всево, не подчиняющейся одним правилам, как в лиспе, где форма записи - одинаковое

> Но-но-но, не зарывайтесь, лейтенант! Cтандартная математическая нотация - тоже зверинец из префиксных, инфиксных операторов, функций и ещё кучи всево, не подчиняющейся одним правилам, типа дробной черты или (ужас!) знака интеграла. Это плохо? :)

Я вобщем-то это тоже имел в виду, когда утверждал, чё плохо перетаскивать из математики. Это ужасно, когда такая нотация перетаскиваецо в области, мало связанные с вычислениями. Ибо, в математике для чисел одна нотация, для множеств - совсем другая (особенно печяльно что некоторые символы общие, но смысел совершенно разный), для векторов - третья, для... нунахъ, видиш, даже в пределах математики одна нотация неюзаецо. Если ещё учесть, что для записи формул технические возможности гораздо богаче всмысле всяких индексов и закорючек (нука, изобрази мне круговой интыграл от а до б от фи по пси в проге :P), то привлечение математической нотации в программирование - жалкие потуги. Я уж не говорю, что спектр понятий в программировании гораздо шире и не совпадает с математикой. Тово же присвоения в математике просто нету.

bugmaker ★★★★☆
()
Ответ на: комментарий от bugmaker

Но в математике такая запись используется не просто так. Она удобна для человека. Так уж человек устроен, что ему легче читать месиво из разных значков, чёрточек, крючочков, чем однообразные наслоения этих скобок. А лисповская запись удобна не для человека, а для машины. И не надо про макросы и метапрограммирование. В математике используются такие макросы, что закачаешься. :) И всякие DSLи там вполне используются, и никто ещё не говорил, что математическая запись для этого не подходит. :)

ero-sennin ★★
()
Ответ на: комментарий от bugmaker

#!/usr/bin/env python

class FileDb(dict):
    def push(self, name, size, dir):
        try:
            self[(name, size)].append(dir)
        except KeyError:
            self[(name, size)] = [dir]

filedb = FileDb()

# Меньше шума чем в "(push "/foo" (gethash (list "file2.txt" 999) 
# hash))". Нет таких лишних сущностей как gethash и list
filedb.push('file.txt', 777, '/foo')
filedb.push('file.txt', 777, '/foobar')
filedb.push('file1.txt', 888, '/bar')
filedb.push('file1.txt', 888, '/foo')
filedb.push('file2.txt', 999, '/foo')

def find_and_get(cond=lambda n: n > 0):
    for (f, s), dirs in filedb.iteritems():
        if cond(len(dirs)):
            for d in dirs:
                yield (f, s, d)

print list(find_and_get())
print list(find_and_get(lambda n: n > 1))
print list(find_and_get(lambda n: n != 2))

Теперь ждём лисповую версию с БД. 

А БД мне понадобилась за тем, что я точно знаю что на моём винте,
без БД не разберёшься :-)

redvasily
()
Ответ на: комментарий от redvasily

>Теперь ждём лисповую версию с БД.

А где тут БД ? Лисповая версия вроде тоже самое делала, только без лишних сущностей вроде наследования FileDb от словаря.

anonymous
()
Ответ на: комментарий от eugine_kosenko

> А два вменяемых лиспера, да еще и на одном диалекте -- это вообще непосильная задача :-)).

Ну я думаю, что поработать с полным набором Allegro CL никто не откажется :^)

А так - два более-менее вменяемых из свободных не так уж и сильно отличаются (я имею в виду CMUCL и SBCL).

Darkman ★★★
()
Ответ на: комментарий от Darkman

> А так - два более-менее вменяемых из свободных не так уж и сильно отличаются (я имею в виду CMUCL и SBCL).

Аха, и выбор одного из этих двух может застопорить любой процесс разработки :-).

eugine_kosenko ★★★
()
Ответ на: комментарий от bugmaker

> Тово же присвоения в математике просто нету.

Присвоение в математике -- это преобразователь предикатов.

eugine_kosenko ★★★
()
Ответ на: комментарий от eugine_kosenko

> Аха, и выбор одного из этих двух может застопорить любой процесс разработки :-).

Тут всё может зависеть от того какие библиотеки могут использоваться. Например OpenGL из cl-sdl у меня в SBCL не завёлся вообще а CMU пошёл влёт. Не сомневаюсь, что есть ситуации и наоборот - SBCL вроде Unicode лучше держит.

Darkman ★★★
()
Ответ на: комментарий от bugmaker

> Разница в продуктивности - на порядки,

"...но при этом такая фигня получается..." :-)

> а в зарплате - в разы.

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

У Хаксли как-то упоминался эксперимент по построению "общества альф". Которое просуществовало ровно неделю. О том же, кстати, пишет и Джоэль в своем "БигМаке против обнаженного повара". Так что, быдлокодеры тоже нужны. Без них пока никак.

Ну, разве что, наши гениальные лисперы таки научатся писать самопрограммирующиеся программы. Которые могут адаптироваться к предметной области, самоисправляться и самотестироваться без участия самих гениальных лисперов. Но это все пока что утопия...

eugine_kosenko ★★★
()
Ответ на: комментарий от Darkman

> Например OpenGL из cl-sdl у меня в SBCL не завёлся вообще а CMU пошёл влёт.

Ну, у меня примерно те же критерии. По которым быдлоламбдагтк было выбрано в ущерб правильному целлгтк.

> Не сомневаюсь, что есть ситуации и наоборот - SBCL вроде Unicode лучше держит.

А теперь представим проект, где есть обе ситуации. Гениальные лисперы, кажется, не привыкли рутино дотачивать недостающие возможности?..

eugine_kosenko ★★★
()
Ответ на: комментарий от anonymous

>>Теперь ждём лисповую версию с БД.

> А где тут БД ?

Ты с нами недавно? Почитай топик с начала - тебе понравится. А версия с БД была на пару страниц раньше.

> Лисповая версия вроде тоже самое делала, только без лишних сущностей вроде наследования FileDb от словаря.

Наследование от словаря - вопрос стиля (можно и без наследования). Насчет "лишних сущностей" - при желании таковыми можно объявить все ЯВУ. Да и ассемблеры - всё равно ЦП работает с кодами команд.

tailgunner ★★★★★
()

2 bugmaker

Итак, соревнование по использованию встроенных в язык (Лисп, Питон) или библиотечных (Си++) ассоциативных массивов закончено. Результаты?

tailgunner ★★★★★
()
Ответ на: комментарий от eugine_kosenko

Я бы назвал это "ничья :-E".

:)

Лисп-версия существенного преимущества перед Питоном не показала. Он заметно короче плюсовой версии, но у Си++ обычные преимущества статически типизированного компилируемого языка. Это _моё_ мнение, но не я же устроил соревнование.

tailgunner ★★★★★
()
Ответ на: комментарий от bugmaker

> Потому что это не "а равно семи" как в мотематике, а "присвоить значение сем к перемнной а"

Одно из (неформальных?) определений оператора присваивания "теперь а равно <значение>"

> Почему-то когда я слыхал про рефакторинг, он относился только к прогам на жабе/с++.

А я много раз слышал и читал в логах слово "рефакторинг" по отношению к коду на Си. И Питон, конечно.

tailgunner ★★★★★
()
Ответ на: комментарий от ero-sennin

> Так уж человек устроен, что ему легче читать месиво из разных значков, чёрточек, крючочков, чем однообразные наслоения этих скобок.

Яволь!

tailgunner ★★★★★
()
Ответ на: комментарий от eugine_kosenko

> А теперь представим проект, где есть обе ситуации. Гениальные лисперы, кажется, не привыкли рутино дотачивать недостающие возможности?..

Смайлик где, умник?

Таки нет, сидишь и "точишь" эти самые "недостающие возможности" :-Е

P.S. Не хотите помочь? Или гениальные кодеры на мэйнстриме привыкли всё получать из коробки, а если чего нет, то "в противогазе стоя в гамаке на лыжах"? :)

yyk ★★★★★
()
Ответ на: комментарий от tailgunner

> > Так уж человек устроен, что ему легче читать месиво из разных значков, чёрточек, крючочков, чем однообразные наслоения этих скобок.

> Яволь!

Человек не устроен читать вообще - иначе глазики бы не портились. А если именно вам легче читать "месиво из разных значков, чёрточек, крючочков", то изучайте китайский/японский.

Я к тому, что человек "устроен" ходить на двух ногах - да. А читать ему легче то, что он понимает (т.е. во многом - дело привычки). Так что не прикидывайтесь совсем уж полными идиотами - а то жалко становится "нелисперов" ;)

yyk ★★★★★
()
Ответ на: комментарий от yyk

> Человек не устроен читать вообще - иначе глазики бы не портились. А если именно вам легче читать "месиво из разных значков, чёрточек, крючочков", то изучайте китайский/японский

Уже изучаю. :)

А кроме шуток, я люблю Лисп, и сам на нём иногда пишу, и мне всегда казалось, что его синтаксис - очень небольшая плата за гибкость, но вот заявлять, что S-выражения читаются ЛЕГЧЕ, чем традиционная математическая нотация это блин уже фонатство и красноглазие. Или таки вы хотите сказать, что математическая запись - отстой, и надо её срочно привести к однородному виду: префиксная нотация, скобочки и ASCII-символы? :P

ero-sennin ★★
()
Ответ на: комментарий от yyk

>> Гениальные лисперы, кажется, не привыкли рутино дотачивать недостающие возможности?..

> Смайлик где, умник?

> Таки нет, сидишь и "точишь" эти самые "недостающие возможности" :-Е

Да не злись ты так. Мы знаем, что ты дотачиваешь.

tailgunner ★★★★★
()
Ответ на: комментарий от yyk

> Человек не устроен читать вообще - иначе глазики бы не портились.

Если читаешь в нормальных условиях - глаза не портятся. Ты еще скажи, что человек не устроен пить воду - если выпить слишком много _чистой_ воды, можно отравиться (или просто лопнуть).

Слушай, а жить человек устроен? А то он же умирает... 8)

tailgunner ★★★★★
()

Предлагаю соревнование

Есть такая пошаговая стратегия с веб-интерфейсом --- Разделяй и властвуй (the-game.ru)

Пусть лисперы, змеефилы и сиплюсплюсовцы напишут для неё по боту. Чей бот выиграет, того язык и лучший.

ugoday ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.