LINUX.ORG.RU

Создатель Python разочарован в Scala

 , ,


2

0

Гвидо ван Россум, создатель Python, в своем блоге делится впечатлениями от изучения языка Scala: "К сожалению, я полностью разочарован в этом языке". Причиной является слишком сложная система типов Scala: "Если такая система необходима для корректной обработки разных типов данных во время компиляции, я однозначно предпочту динамическую типизацию".

>>> пост

anonymous

Проверено: maxcom ()

Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> на Лисп почему-то до сих пор не написано СУБД, по своим качествам приближающихся к PostgreSQL.

Камрад, PostgreSQL изначально был написан именно на Лисп (для Genera, вроде бы, и назывался он Postgres) :) Потом его переписали на Си при переносе в Unix и назвали Postgres95.

tailgunner ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> А теперь не могли бы Вы в ответ привести пример такого же уровня, но написанный на Лисп? Позволю себе ответить за Вас: "нет, не могли бы", потому что на Лисп почему-то до сих пор не написано СУБД, по своим качествам приближающихся к PostgreSQL.

Ты неграмотный и глупый.

Про ITASCA (Orion) не слышал, ламер.

> А теперь попробуйте догадаться почему.

Менторский тон в устах недоумка неуместен. Поумней сначала.

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> каждый день пользуешься eval-ом при программировании ?

Да, каждый день. И каждый день пользуюсь defmacro. Напиши мне defmacro на сях.

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> Где компиляторы распространённых языков, написанные на Лисп?

Транслятор самого распростанённого в мире языка (VB6), переводящий его в VB.NET, написан на Лиспе.

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

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

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> Можешь догадаться, как мы на вас, серых, вообще смотрим. Радуйтесь, что вообще снисходим до общения.

Ты таакой толстый :) "Ты же лопнешь, деточка" (c)

Настолько ненавидишь Лисп, что готов дискредитировать его даже таким толстым троллингом?

tailgunner ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от tailgunner

Re: Создатель Python разочарован в Scala

> Настолько ненавидишь Лисп, что готов дискредитировать его даже таким толстым троллингом?

Не мешай человеку. Сейчас он напишет великую систему на лиспе, сходит на обед, и уж потом ответит на твой вопрос %)

mv ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от mv

Re: Создатель Python разочарован в Scala

> Это всё хорошо, но вы меняете не свой environment :) Возможно, для 
сишников стоило бы сначала объяснить, что в лиспе environment - это 
видимые symbols: переменные, функции. Таким образом, изменить 
environment в лиспе - это в самом лёгком случае будет изменение 
переменной (в си через extern очень приближённо можно сделать), а в 
более сложном - определение нового symbol.

Ммм... То есть необходимо объявить через eval новый symbol - переменную 
или функцию, которые будут доступны всей программе? Что-то наподобие этого?

Измененный sample.c:

#include <stdio.h>
#include <stdlib.h>

int test = 0; //This is our new symbol

int main(int argc, char *argv[])
{
	printf("Done! ;)\n");
	int x;
	scanf("%d",&x);
	printf("%d * %d = '%ld'\n", x, x, x*x);
	putenv("LIBEXECSTATE=DONE");
	test = x+x;
}

--------------------------------------------------

Измененные libexec.h + libexec.c:

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dlfcn.h>

#define OUTFILE "out"

#define ESCAPE_SIZE 4
char escape[ESCAPE_SIZE] = { '$', '\'', '"', '\\' };

typedef int (*exec_t)(int, char**);

int CExec(const char *code, size_t code_length, const char *cflags);
size_t cleanCode(char *dest, const char *src);

int CExec(const char *code, size_t code_length, const char *cflags)
{
    char *ccode = (char*) malloc(code_length*2+1);
    code_length = cleanCode(ccode, code);
    
    char *request = (char*) malloc(code_length+strlen(cflags)+
        40+sizeof(OUTFILE)+1);
    sprintf(request,
             "echo \"%s\" | gcc -shared -fPIC %s -x c -o " OUTFILE " -",
             ccode, cflags);
    free(ccode);
    
    int ret = system(request);
    free(request);
    
    if(ret)
    {
        printf("Compilation failed...\n");
        return -1;
    }
    
    dlerror(); //Freeing dlerror
    char *error;

    void *h = dlopen("./" OUTFILE, RTLD_NOW | RTLD_GLOBAL); //Openning our file
    
    if( (error=dlerror()) )
    {
        printf("Error occured: %s\n",error);
        return -1;
    }
    
    exec_t doe = dlsym(h, "main"); //Function, we'll use
    
    if( (error=dlerror()) ) //Checking for errors
    {
        printf("Error occured: %s\n",error);
        return -1;
    }
    
    ret = doe(0, NULL); //At last, starting!
    
    //dlclose(h); //Freeing now unnecessary library
    //Library is neccessary, 'cause it may define symbols, we need
    
    return ret;
}

size_t cleanCode(char *dest, const char *src)
{
    int i;
    char *original = dest;

    while(*src!='\0')
    {
        for(i=0;i<ESCAPE_SIZE && *src!=escape[i];i++);
        if(i!=ESCAPE_SIZE)
            *dest++ = '\\';
        *dest++=*src++;
    }
    *dest = '\0';

    return dest-original;
}

--------------------------------------------------

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <dlfcn.h>
#include <sys/stat.h>

int checkSymSet(void **dest, const char *symbol);
int loadFile(char **buffer, int fd);

#define READ_SIZE 1024

extern int CExec(char *code, size_t code_length, char *cflags);

int main(int argc, char *argv[])
{
    if(argc<2)
    {
        printf("You should use:\n\t%s {c-file-name}\n", argv[0]);
        return -1;
    }
    
    int fd = open(argv[1], O_RDONLY);

    if(fd==-1)
    {
        printf("Failed to open file...\n");
        return -1;
    }

    char *buffer;
    size_t sz = loadFile(&buffer, fd);

    close(fd);
    
    int *tst;
    if(checkSymSet((void**)&tst, "test"))
        printf("Symbol defined: %d\n", *tst);
    else
        printf("Symbol undefined\n");
    
    CExec(buffer, sz, "");
    
    free(buffer);
    
    if(checkSymSet((void**)&tst, "test"))
        printf("Symbol defined: %d\n", *tst);
    else
        printf("Symbol undefined\n");
    
    return 0;
}

int loadFile(char **buffer, int fd)
{
    struct stat st;
    fstat(fd, &st);

    *buffer = (char*) malloc(st.st_size+1);

    register int bread = 0;
    size_t sz=0;

    while( (bread = read(fd, *buffer+sz, READ_SIZE)) )
        sz+=bread;
    
    *(*buffer+sz) = '\0';
    
    return sz;
}

int checkSymSet(void **dest, const char *symbol)
{
    dlerror();

    void *h = dlopen(NULL, RTLD_LAZY);
    if( dlerror() ) return 0;

    void *sym = dlsym(h, symbol);
    if( dlerror() ) { dlclose(h); return 0; }

    *dest = (int*) sym;
    dlclose(h);
    
    return 1;
}

--------------------------------------------------

Результат:

$ bin/exec sample.c 
Symbol undefined
Done! ;)
12
12 * 12 = '144'
Symbol defined: 24

--------------------------------------------------

Но - предполагаю - в моем варианте могут возникнуть проблемы с памятью,
т.к. я держу в ней каждый результат CExec. Впрочем, можно предусмотреть
возможность очистки - удаления более не нужных "eval"-ов.

Ruth ★★ ()

Re: Создатель Python разочарован в Scala

Да, кстати, адепты, подскажите приличную лисп-систему под винду/линукс. А то я несколько отстал от жизни.

Macil ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от tailgunner

Re: Создатель Python разочарован в Scala

>Объектные БД умерли маленькими.

Ээээ - чето в нашем энтепрайзе последние пять лет - работают. Надо посмотреть - может зомби.

r ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от mv

Re: Создатель Python разочарован в Scala

>>Требовать возможностей метапрограммирования от Си - всё равно что требовать поддержки GOTO от Пролога или Эрланга.

>Позвольте, но от лиспа же в это треде требовали выполнить исключительно вычислительную задачу?


Требовали - в соответствии с заявленным Вами соответствием Лиспа этой задаче. "В реальных практических задачах лиспер ВСЕГДА уделывает сишника" - сказал Ваш анонимный коллега. Практика показала, что это мираж и фикция; разбор полётов смотрите ниже.

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

Ты дурак. В реальных практических вычислительных задачах, код на Лиспе (использующий Maxima для оптимизаций) сгенерит код на Фортране (или сразу на ассемблере), каковой и исполнит. Это - идиоматическое применение лиспа. Считать на самом Лиспе никто не станет.

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> В реальных практических вычислительных задачах, код на Лиспе (использующий Maxima для оптимизаций) сгенерит код на Фортране (или сразу на ассемблере), каковой и исполнит. Это - идиоматическое применение лиспа. Считать на самом Лиспе никто не станет.

А sbcl по твоему что генерит?

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от r

Re: Создатель Python разочарован в Scala

>> Объектные БД умерли маленькими.

> Ээээ - чето в нашем энтепрайзе последние пять лет - работают.

Я же поправился - "объектные СУБД общего назначения".

> Надо посмотреть - может зомби.

Зомби и есть.

tailgunner ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от mv

Re: Создатель Python разочарован в Scala

>Можете не возвращаться.

Хорошо. Давайте не будем возвращаться и подведём итоги.

Программисты на Си с первого раза привели вариант работающей программы. Тут я не углядел за действиями другого анонимного энтузиаста, который внёс некую сумятицу. (Предвосхищая Ваше "поди разберись в вас, анонимусах" попрошу Вас не паясничать, Вы прекрасно представляете, с кем ведёте диалог.) Дальнейшие коррективы вносились под давлением противоположной стороны, вызванной ложным пониманием задачи и претензиями к несущественным деталям. Результат см. здесь: http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3279466

Программисты на Лисп привели единственный вариант, который а) является неоптимальным, на что им было указано, б) обладает всеми недочётами первых вариантов на Си (вываливание в дебаггер при отсутствии файла или невыделении памяти, неоднозначности в арифметике). После указаний на недочёты программисты Лисп занялись не их исправлением, а поливанием оппонентов помоями, выискиванием "ошибок" в их программе (что, кстати, свидетельствует о глубоком непонимании сути задачи - примитивнейшего бенчмаркинга), цеплянием к абсолютно несущественным мелочам типа /dev/urandom, абсурдными требованиями "сперва реализовать eval и defmacro" в Си. Увлёкшись поиском соломинки, не приметили в собственном глазу бревна - аллокации лишнего массива. Исправленного варианта не поступило.

Итог. Вариант на Лисп работает медленнее сишного на 10-15%, и потребляет в три раза больше памяти, чем исходный массив, повторяю, при любом размере массива - проверьте это сами увеличением размера массива до 40 мегабайт и пронаблюдайте аллокацию 110 мегабайт рамы. Плюс общее (не)понимание лисперами сути задачи, отношение к оппонентам, общий уровень культуры.

Меня этот итог устраивает вполне.

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

>В реальных практических вычислительных задачах, код на Лиспе (использующий Maxima для оптимизаций) сгенерит код на Фортране (или сразу на ассемблере), каковой и исполнит. Это - идиоматическое применение лиспа. Считать на самом Лиспе никто не станет.

В таком случае, прошу Вас решить приведённую задачу указанным Вами правильным образом, дабы не быть голословным и продемонстрировать Правильное Решение на Лисп.

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> Вариант на Лисп работает медленнее сишного на 10-15%, и потребляет в три раза больше памяти, чем исходный массив

Уже вроде сделали вполне приличный вариант: http://www.linux.org.ru/jump-message.jsp?msgid=3277883&cid=3279889

tailgunner ★★★★★ ()

Re: Создатель Python разочарован в Scala

Что-то никто не сказал о встроенном XML, он его не критиковал?

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от Zenom

Re: Создатель Python разочарован в Scala

> Довольно сложно критиковать за наличие какой-либо фичи. Не?

А с каких пор хлам в синтаксисе языка стал считаться фичей?

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от Zenom

Re: Создатель Python разочарован в Scala

> А что, фичей считается только то, что аналитиками с ЛОРа признано оной?

Язык должен быть минималистичен. Сегодня XML есть, завтра его нет, кому-то вообще захочется YAML, а кому-то и s-expressions, все добавлять?

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

>Язык должен быть минималистичен. Сегодня XML есть, завтра его нет, кому-то вообще захочется YAML, а кому-то и s-expressions, все добавлять?

Чудака с ямлом послали. Про XML верно заметил мартин - он для вас лишний если он вам не нужен. Если он нужен - он совсем не лишний. e4X будет в следующих бравзерах AFAIK - увидите как изменится разработки под веб.

r ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от tailgunner

Re: Создатель Python разочарован в Scala

>Объектные БД умерли маленькими.

O'RLY? ТРИС ГИБДД сделана на объектно-реляционной СУБД Cache'

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

>Обьясните дураку, зачем прибивать гвоздями его в синтаксис?

Для работы с ним из синтаксиса. Альтернативные варианты?

r ★★★★★ ()

Re: Создатель Python разочарован в Scala

Пора подвести итоги дискуссии о Лисп.

В этом треде мы наблюдали порядочное количество самозванной лисп-"элиты". Давайте внимательнее рассмотрим их утверждения.

- хорошо читаемые, понятные, управляемые языки - для быдла ("обычного яппи-программиста - того который остваивает визуаль бейсик это напрягает." - о S-выражениях, http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3279444);
- удобная графическая отладка в исходных текстах - для быдла ("ползанье графическим дебаггером по исходному коду - это атрибут т.н. быдлокодеров", http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3279769);
- рефакторинг, профайлинг, тестирование - не нужны (там же);
- всего вышеперечисленного вам, быдлу, не понять в силу ограниченности (http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3277133 и хор голосов).

Создаётся впечатление, что, сознательно отказываясь от удобств разработки, ограничивая себя, создавая искусственные проблемы и решая их, лисперы начинают относить себя к так называемой "элите" мира IT. Это подмена понятий и смешение причины и следствия. Вы думаете, что, говоря о привычных вещах на сложном, непонятном большинству языке, вы становитесь элитой? Нет, вы останетесь кучкой чудаков, бормочущих на птичьем языке. Вы считаете, что, поселившись в бочке, можно автоматически стать Диогеном?

Я всегда был искренне уверен в том, что признаки элитности (в хорошем смысле слова) - глубоко внутренние.

Разносторонняя образованность. Широкий кругозор. Непредвзятые взгляды.
Адекватная оценка. Профессионализм.
Уважительное отношение к оппонентам.
Отсутствие пренебрежения к тем, кто слабее.

Культура.

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

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

>- хорошо читаемые, понятные, управляемые языки

Это ты С назвал понятным хорошо читаемым языком? 3 "ха" следующих за "муа". Техногенность характеристик - поражает.

>удобная графическая отладка в исходных текстах


Та не помниш расказик про русского программиста - сюжет про канадца? Ты уверен что "поинструкционное" хождение это вещь которая дожна быть в любого рода языках? Которая есть эффективный способ отладки в такого рода языках? Упомянутый здесь REPL - это вемсьма мощный инструмент - в общем случае значительно мощнее отладчика. Не надо думать что на лиспе или других отличных от С языка пишут так же как на С. Вон некоторым людям XSL-дебаггер надо. Я с XSL профессионально дела имею уже 7 лет - ниразу мне не нужен был отладчик. Потому что ценность наблюдения хождения по шаблонам XSL для меня нулевая.

>- рефакторинг, профайлинг, тестирование - не нужны (там же);


Кто вам сказал что для DSL нужен весьэтот бред который там перечислен? Привести пример живого DSL?

select active user where (name ~ 'aaa') order by name ascending offset 5 limit 6



Вот - компилится в постгресовский SQL с кучей регулярных выражений охрененной сложности. Результат исполнения - набор XML документов. Расскажете нахрена тут "рантайм дебаггер профайлер" и прочая фигня? Или вы просто не понимаете о чем говорите и тогда:

>- всего вышеперечисленного вам, быдлу, не понять в силу ограниченности


имеет под собой некоторые основания?

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

r ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> хорошо читаемые, понятные, управляемые языки - для быдла

Что может быть более читабельным и понятным, чем Лисп?

> удобная графическая отладка в исходных текстах - для быдла

Идиот, это впервые именно для Лиспов и появилось.

> рефакторинг, профайлинг, тестирование - не нужны

Опять же, удобнее чем в Лиспе нет нигде.

> всего вышеперечисленного вам, быдлу, не понять в силу ограниченности

Вам, быдлу, в силу ограниченности не понять вообще ничего. Потому что вы быдло, ага.

> сознательно отказываясь от удобств разработки

Это про жабакодерню, у которой даже замыканий и REPL нет? О какому "добстве", быдлятина, тут можно разговаривать?

> Отсутствие пренебрежения к тем, кто слабее.

Когда вы, слабые, ещё и наглые при этом, то без пренебрежения не обойтись, извините.

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> А теперь не могли бы Вы в ответ привести пример такого же уровня, но написанный на Лисп? Позволю себе ответить за Вас: "нет, не могли бы", потому что на Лисп почему-то до сих пор не написано СУБД, по своим качествам приближающихся к PostgreSQL.

Насколько мне известно, PostgreSQL как раз был изначально написан на лиспе. Это как-то исчезло из истории, но вот тут есть следы:

http://momjian.us/main/writings/pgsql/great_steps.pdf

А что за задачу тут решали, в которой лисп слил С? Может быть, я попробую сделать быстрее?

den73 ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от r

Re: Создатель Python разочарован в Scala

>Это ты С назвал понятным хорошо читаемым языком? 3 "ха" следующих за "муа". Техногенность характеристик - поражает.

Давайте сперва разберёмся в том, что такое "хорошая читаемость". Нам не обойтись без формализации этого, вообще говоря, субъективного термина. Я считаю, что это понятие складывается из трёх компонентов:

1) схожести с привычным человеческим языком;
2) схожести с привычной математической нотацией;
3) общей логичности построений.

То есть такое выражение на псевдоязыке: "let P(i,j) = sum (by k=1..n) of A(i,k)*B(k,j), where i,j=1..n" будет по всем параметрам более читаемым, чем аналог на Лиспе. (Кстати, приведите его.)

Во-первых, это напоминает человеческий язык: "присвоить такой-то переменной значение, равное тому-то, при параметрах, пробегающих то-то".
Во-вторых, близко к математической нотации, т.е. имитирует известную формулу.
В-третьих, абсолютно логично. Настолько же запись "a := b + c + d" логичнее и понятнее "(let (a (+ b c d)))".

>Я с XSL профессионально дела имею уже 7 лет - ниразу мне не нужен был отладчик.


Быть может, дело в примитивности решаемых Вами задач? XSLT-отладчик - хороший, мощный инструмент, ценность которого возрастает с ростом сложности задачи. (Впрочем, чересчур сложный XSL - признак того, что что-то подтухло в Датском королевстве.) То, что отладчик не понадобился конкретно Вам, не означает, что он не нужен вообще. Опять-таки, не зря создаются инструменты наподобие XQDT (http://www.xqdt.org) - IDE и отладчик для XQuery, классического DSL. Но ничто не мешает отрицать эти инструменты и джедайствовать в REPL-консоли, только тогда не надо говорить о баснословной производительности труда лиспера.

Кстати, все известные мне реализации XSLT и XQuery - это C++ и Java. Хотелось бы взглянуть на LISP-аналоги.

>Расскажете нахрена тут "рантайм дебаггер профайлер" и прочая фигня?


Пример (на DSL) примитивен. Если бы программа на DSL состояла хотя бы из десятка строчек, Вам рано или поздно стало бы интересно, в какой из этих строчек произошёл ексепшен, или какая из них выполняется дольше всего, и её (имплементацию) надо бы заоптимайзить.

>на примерах чтения из urandom делает далеко идущие выводы про DSL


Вы в который раз цепляетесь к несущественной детали (urandom) и подменяете понятия. Выводы делались не про DSL (с положительными сторонами этого подхода как такового никто не спорит), а касательно применимости LISP (языка, платформы) на определённом классе задач.

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

>1) схожести с привычным человеческим языком; >2) схожести с привычной математической нотацией;

Пункты 1 и 2 нифига не пересекаются.

> То есть такое выражение на псевдоязыке: "let P(i,j) = sum (by k=1..n) of A(i,k)*B(k,j), where i,j=1..n" будет по всем параметрам более читаемым, чем аналог на Лиспе. (Кстати, приведите его.)

Переведите это выражение с вашего псевдоязыка на человеческий или математический. Чтобы потом не возникло разночтений.

И, кстати, неплохо было бы, чтобы в ваших задачах стали появляться не только школьная арифметика.

mv ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> Что может быть более читабельным и понятным, чем Лисп?

Смотрите выше. Языки с привычной человеку структурой и семантикой. Код на лисп же представляет абсолютно чуждую "мешанину из овсянки и обрезков ногтей", как справедливо отметил один деятель.

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

Далее.

> Что может быть более читабельным и понятным, чем Лисп?

> Идиот, это впервые именно для Лиспов и появилось.

> Опять же, удобнее чем в Лиспе нет нигде.


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

>Потому что вы быдло, ага.

>быдлятина

>Идиот

>без пренебрежения не обойтись


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

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от mv

Re: Создатель Python разочарован в Scala

>Пункты 1 и 2 нифига не пересекаются.

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

>Переведите это выражение с вашего псевдоязыка на человеческий или математический. Чтобы потом не возникло разночтений.


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

Произведением квадратных матриц A и B (размером n) назовём квадратную матрицу P размера n, такую что элемент Pij равен сумме произведений Aik * Bkj, k пробегает диапазон от 1 до n, для любых i, j от 1 до n. Вычислить матрицу P.

Псевдокод (считаем, что матрицы аллокированы, и матрица p предварительно обнулена):

for (i = 0; i < n; i++)
for (j = 0; j < n; j++)
for (k = 0; k < n; k++)
p[i][j] += a[i][k] * b[k][j];

>И, кстати, неплохо было бы, чтобы в ваших задачах стали появляться не только школьная арифметика.


Вы уверены, что готовы к этому? Я готов. Приоткрою завесу. В реальной задаче (прототипом которой является подсчёт отклонений) присутствуют декодирование/декомпрессия данных, распараллеливание расчётов на кластере, специализированный GUI, использующий OpenGL, работа с SQL СУБД, веб-интерфейс, интеграция CORBA.

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

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> Смотрите выше. Языки с привычной человеку структурой и семантикой.

Правильно, Haskell и Erklang -- наше всё. Привычные математикам монады!

Я надеюсь, вы не Си имеет в виду? Нет, не Си, я уверен...

sv75 ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

>1) схожести с привычным человеческим языком;
>2) схожести с привычной математической нотацией;

>3) общей логичности построений.


Согласен только с последними двумя. Схожесть с человеческим языком вещь взятая с потолка. Контраргумент - японский - человеческий язык. Схожесть с ним ничего не даст.

>То есть такое выражение на псевдоязыке: "let P(i,j) = sum (by k=1..n) of A(i,k)*B(k,j), where i,j=1..n" будет по всем параметрам более читаемым, чем аналог на Лиспе


шикарно но в каком месте тут С? Этот как раз из тех примеров где С - это ужас.

>Во-первых, это напоминает человеческий язык


Это какой?

>Во-вторых, близко к математической нотации, т.е. имитирует известную формул


Шикарно.

>В-третьих, абсолютно логично. Настолько же запись "a := b + c + d" логичнее и понятнее "(let (a (+ b c d)))".


Нет уж стоп. Не надо сложную формулу с суммами доказывать инфиксными операциями. Давайте реализацию оной на С - и сравним ее с оригиналом.

И во вторых не разу это не логично. Это привычно с точки зрения обычной арифметики. А логично - это function application. Где '+' это функция, а "a b c" аргументы. Из этого проистекает много интересных следствий вроде:

#let f x y = x + y;;

1) Карринг:
val f : int -> int -> int = <fun>

2) Частичная аппликация:

#let fp = f 5;;
val fp : int -> int = <fun>

#fp 6;;

Вот все это и есть логика и математика. А не ваш перевод a + b до уровня арифметики.

>Быть может, дело в примитивности решаемых Вами задач?


Я думаю я в числе 5% людей у которых задачи для XSL не самые примитивные.

>XSLT-отладчик - хороший, мощный инструмент, ценность которого возрастает с ростом сложности задачи.


Нулевая у него ценность. XSL трансформация процесс автоматический делается трансформером. Управлять им нельзя. Пошаговое исполнение смысла не имеет - он работает и контролировать это нельзя. Шаблоны применяются - select и match в рантайме выглядит точно так же как и в исходных кодах - не применится они не могут. Переменных с состоянием там нет - изменение их остледивать незачем. Внимание вопрос - что там отлаживать? Единственная полезная вещь - это xpath evaluation на реальном документе. Для этого отладчик - не нужен. Если человек лезет в отладчик XSL - значит от просто не понимает, что пишет на XSL.

>IDE и отладчик для XQuery


XQuery - не XSL. То есть совершенно ниразу.

>Пример (на DSL) примитивен.


В чем же его примитивность?

>Если бы программа на DSL состояла хотя бы из десятка строчек, Вам рано или поздно стало бы интересно, в какой из этих строчек произошёл ексепшен, или какая из них выполняется дольше всего, и её (имплементацию) надо бы заоптимайзить.


Ага - наступает момент понимания наконец-то - следовательно нужен профайлер для хост-языка DSL, а не для DSL? Понятно обзее заблуждение упомянутого утверждения?

>Вы в который раз цепляетесь к несущественной детали (urandom) и подменяете понятия.


Это вы на примере чтения урандома делаете выводы про DSL, и демонстрируете наличием отладчика для XQuery (который по факту язык слодности окамла - и вполне канает на язык общего назначения со специализацией в XML) пытаетесь обосновать полезность отладчика для XSL. Так что это вы ввели эти понятия которые к тому же вообще никак не связаны друг с другом.

>а касательно применимости LISP (языка, платформы) на определённом классе задач.


Класс задач ограничивается пока снятием статистики с скуска памяти.

r ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

> Потому и дают на собеседовании задачи по нахождению детерминанта тезнора и другой интегральной ерунды, чтобы проветить, насколько стойко ты будешь переносить трудности наемной работы по разгребанию рутины. И тебе будут на уши вешать лапшу, что раз ты так много знаешь - значит ты крутой. И будешь ты этим гордиться. А девочка в отделе продаж проявив упорство в освоении тонкостей товаров всех двух десятков позиций в прескуранте и умение общаться через пол года выйдет на такой уровень дохода, который тебе не дадут 5 лет в универе +3 в аспирантуре + много в энтерпрайзе. И если работотадель решит, что он ей много платит, она не запариваясь пойдет в другую контору.

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

sv75 ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

>Языки с привычной человеку структурой и семантикой.

Японци и китайцы походу нелюди.


r ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от anonymous

Re: Создатель Python разочарован в Scala

>Если математической нотацией удобно описывать структуру и взаимоотношения между данными, то человеческим языком лучше описываются действия.

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

>Псевдокод (считаем, что матрицы аллокированы, и матрица p предварительно обнулена):


Нет уж не считаем. Это тоже абсолютно необходимый для реализации указанной формулы код. Потому что то что вы "посчитали" это 80% кода на С.

r ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от r

Re: Создатель Python разочарован в Scala

>>То есть такое выражение на псевдоязыке: "let P(i,j) = sum (by k=1..n) of A(i,k)*B(k,j), where i,j=1..n" будет по всем параметрам более читаемым, чем аналог на Лиспе
>шикарно но в каком месте тут С?


Читайте внимательнее, это был псевдокод.

>Во-первых, это напоминает человеческий язык

>Это какой?


Английский. Использованы термы "let" (присвоить), "sum" (сумма), "where" (в данном случае - "такой, что").
Элементы английского языка использованы в приведённом псевдоязыке в качестве семантических элементов.

>Давайте реализацию оной на С - и сравним ее с оригиналом.


См. несколькими постами выше.

>Вот все это и есть логика и математика. А не ваш перевод a + b до уровня арифметики.


Область применения программирования - это не только математика. К сожалению, класс задач, хорошо формализуемый на функциональном языке, крайне узок. (Заметьте, никто не отрицает математической и логической строгости этой парадигмы.) Увы, подавляющее большинство задач - это императивщина и ООП, лучшего человечество пока не придумало для их формализации.

>В чем же его примитивность?


В однострочности и небольшой глубине дерева разбора.

>следовательно нужен профайлер для хост-языка DSL


Неверно. Профайлер для хост-языка нужен в любом случае. Для самого DSL тоже нужен профайлер, потому что, профилируя хост-язык, Вы не сможете понять, какой области DSL (scope вызова + параметры + переменные + ...) соответствует найденный bottleneck. А это необходимо знать, поскольку лажа может крыться как в самом тексте на DSL, так и в имплементации на хост-языке.
Грубо говоря, профайлер должен выдать, сколько времени исполняется каждый стейтмент на DSL.

>Класс задач ограничивается пока снятием статистики с скуска памяти.


...и всем надмножеством этого класса.

По поводу реальной формулировки - см. выше (http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3281812)

anonymous ()
Ответ на: Re: Создатель Python разочарован в Scala от sv75

Re: Создатель Python разочарован в Scala

>> удобная графическая отладка в исходных текстах

> WTF? Шо это??

Это source-level GUI debugger, если вам так понятнее. Мы, простые быдлокодеры, будем вечно благодарны вменяемым лисперам из 70-х за это изобретение %)

tailgunner ★★★★★ ()
Ответ на: Re: Создатель Python разочарован в Scala от r

Re: Создатель Python разочарован в Scala

> императивным методом (описанием последовательности шагов) люди почти не общаются. Это противоестественно.

Понятное дело, что человек чаще объясняет, как надо сделать, а не что надо сделать. Но компьютеры - не человеки. Они умеют только сложить и в регистр покласть.

>Нет уж не считаем. Это тоже абсолютно необходимый для реализации указанной формулы код. Потому что то что вы "посчитали" это 80% кода на С.

Пожалуйста. Ради чистоты когда забудем на время про calloc(), хотя на практике будет использован именно он.

for (i = 0; i < n; i++) {
 for (j = 0; j < n; j++) {
  p[i][j] = 0;
  for (k = 0; k < n; k++)
   p[i][j] += a[i][k] * b[k][j];
 }
}

Очередная придирка будет рассмотрена как отказ привести соответствующую реализацию на Лисп.

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