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

Ок. Теперь понял. Просто для меня union достаочно низкоуровневая вещь. В хаскелле это кстати один тип с разными конструкторами. И если я уж его одним способом создал - то по другому пользовать и не могу. Что мне кажется больше похоже по сути.

>а кем вытесняются, если не секрет? уж явно не erlang'ом...

Как правило - именно ним

> Просто для меня union достаочно низкоуровневая вещь.

Да и сам Си - невысокого уровня

> В хаскелле это кстати один тип с разными конструкторами.

Это и в Си один тип :) Конечно, конструкторов в Си нет.

Зх, не получилось толкового флейма... /me ушел спать голодным.

>Как правило - именно ним

какие-то у вас ну очень уникальные проекты...
по крайней мере в россии спецов по ерлангу - единицы

>> в адрес Хаскеля (100% академического языка, не справляющегося с элементарными практическими задачками)
>anonymous 100% idiot?

Отнюдь. Вот вам примитивная задачка из практики. (Кстати, я её недавно задавал местным горе-лисперам в лице Sun-ch сотоварищи, и они пока не справились.)

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

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

Что сделать конкретно надо?

1) считать из /dev/urandom 10 мегабайт мусора (пусть это Xn, n=1..10M) в память;
2) посчитать среднее (M=sum(Xn), n=1..10M) и отклонения Dn=|Xn-M|
3) сплюнуть отклонения в файл, в результате должно получиться ещё 10 мегабайт мусора
4*) задача со звёздочкой, олимпиадная, самая сложная :) не задавать вопросов типа "а зачем так, а ведь можно по-другому" и тому подобных. Задача сформулиролирована как минимальная из класса задач на вычисления на больших массивах, не решаемых в один проход (в режиме потока). Реальные задачи сложнее, я всего лишь берегу ваши силы.
5) запустить получившуюся программу под valgrind, чтобы померять выделение оперативной памяти.

Благодарю за проявленный интерес.

> Что когда я говорю "множество", я не говорю чего? 

Тебе таки придется сказать "чего", иначе ты получить парадоксы
 наивной теории множетств :-)

> Говорите, но кто сказал что это "чего" соответствует статическому
 типу данных? К примеру, откуда взялись union в С -- ведь они ни
 чёрта не статические по сути? 

union в плюсах -- это способ *быстро* объяснить компилятору, что ты
 *лучше* него понимаешь, в чем дело. 

Смотри один из немногих стоящих примеров юзания юнион, который *не
 нарушает* типизацию:


// g++ union_test.cxx && ./a.out
#include <iostream>

struct Point {int x; int y; };

struct Rect { union {
    struct {
        Point top_left;
        Point bottom_right;
    } point;
    struct {
        int left;
        int top;
        int right;
        int bottom;
    } coord;
};};

int main(int argc, char** argv) {
    Point a; a.x=1; a.y=2;
    Point b; b.x=3; b.y=4;
    Rect r;

    // Ява-прогерам смотреть эти две строки:
    r.point.top_left=a; r.point.bottom_right=b;
    std::cout << r.coord.left << r.coord.top << r.coord.right << r.coord.bottom << "\n" ;

    return 0;
}

> 5) запустить получившуюся программу под valgrind, чтобы померять выделение оперативной памяти. Анонимус, тут ты меряешь не язык, а программера :-)

> Можете привести _нормальный_ пример где действительно нужны union?

Да, смотри мой ответ sv75.

Кстати, как *это* делается на других языках? :-)

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

>и где там написано, что appengine не на питоне ?

Ага жабские и перловые биндинги к аппэжнжайн были к питону - да?

>какие-то у вас ну очень уникальные проекты...

Разные

>по крайней мере в россии спецов по ерлангу - единицы

Да, с кадрами напряг. Но толковые программисты быстро учатся.

>Там в основе Django.

Нету там в основе джанги - джанга там установлена по умолчанию а фрейм офрк они не ограничивают.

>Естественно, на другом фреймворке.

Мы наверное разное подразумеваем под энжайн. Аппэнджайн это хрень которая позволяет хостить апликейшены - питон это всего лишь фронтэнд.

> То есть ты утверждаешь, что четкая статическая структура есть не всегда? O_O ПРЕДАТЕЛЬ

Иногда проще плюнуть на четкую статическую структуру.

Например: целое_число и целое_ненулевое_число это два разных типа данных, но в 99% случаев их никто не будет пытаться реализовывавать *отдельно*.

Впрочем, может быть хорошая система типов такое и позволила бы.

>Примеры: unix shell как DSL, языки описания сценариев игр (для небанальных случаев проще взять питон, что и делается).

Это не DSL ни разу. Не надо путать DSL и скриптинг.

>не стать скале следующией java в первую очередь из-за сложности. Вот groovy вторым языком может стать, это да.

Динамически типизированный язык? Не смешите мои тапки. Жаба - это не только мордны типа CRUD на вебе ваять.

>Например: целое_число и целое_ненулевое_число это два разных типа данных, но в 99% случаев их никто не будет пытаться реализовывавать *отдельно*.

По причине того что нету выразительных средств языка (AFAIR в ada они были).

>По причине того что нету выразительных средств языка (AFAIR в ada они были).

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

type positive = int(0..)
i : positive

то это поломается

f (x: positive, y: positive): positive = x - y

i = f (5,10)

И никакой компилятор этого не проверит.

Максимум - можно вставить TypeException.

То есть подобные вези не особенно прижились именно по причине практической малоприменимости.

Что-то неладно с Java community на ЛОРе.
Такого количества озабоченных и комлексующих психов я на програмерских форумах давно не видел.

Да, я не сторонник Питона. Да, я программирую на Java.
Но, господа, умалищённые фанатики, вы ведь и в подмётки не годитесь Гвидо.

Оно,понятно, ЛОРовские аналитеги никогда не отличались наличием ума, но как-то от сторонников Java я такого психоза не ожидал :(

Есть пара неадекватных личностей, но к ним все привыкли и не обращают внимания но такой наплыв!

Весьма печально.

> По причине того что нету выразительных средств языка (AFAIR в ada они были).

Речь шла именно о целых числах -- т.е.

А. ..., -3, -2, -1, 0, 1, 2, 3, ...

Б. ..., -3, -2, -1, 1, 2, 3, ...

Компилятору надо проверить, что в результате x-y мы получаем не ноль. Это возможно, но таки бывает часто очень сложно :-)

> Это возможно, но таки бывает часто очень сложно :-)

В общем случае это конечно невозможно, да, я знаю.

> Ну, тогда решай свои задачи горами тестов и часами отладки.

Ох-хо-хо... Примерно так и приходится. Основной язык программирования в данный момент - C++. Как только сложность программы переваливает за некоторый рубеж без тестов (и юнит- и интегральных, с точки зрения пользователя) всё одно не обойтись, независимо от языка программирования.

>В общем случае это конечно невозможно, да, я знаю.

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

> Компилятору надо проверить, что в результате x-y мы получаем не ноль. Это возможно, но таки бывает часто очень сложно :-)

Ты хочешь чего-то странного. Это нетипичный use case. А если все-таки приспичило, то просто сразу после вычисления x-y проверяешь на нуль и кидаешь эксепшн в случае чего. Что может быть проще?

> Это не DSL ни разу. Не надо путать DSL и скриптинг.

Язык описания данных для игр по-моему сложно отделить от скриптинга. А DSL там же есть, потому что есть domain.

> Вы считаете С++ или пусть даже Java в тестах хотя бы с полным покрытием кода не нуждаются?

Я не считаю их нормально типизированными языками :-)

А создатель Scala разочарован в Python. Счет 1:1 :)

> Я не считаю их нормально типизированными языками :-)

Нормально типизированный (это haskell? ) не будет нуждаться в тестировании? Не верю.

> А создатель Scala разочарован в Python. Счет 1:1 :)

Это вряд ли. Иначе бы он сидел спокойно кодил на яве.

самое забавное -- ведь действительно нафиг не нужна. вот засада-то.

хорошо, что ты не работаешь программистом.

много однообразной математики.

/fixed/

как я и сказал — гвидо ниасилило прочитать книжко.

а чо тебя кормить-то? ну, писал на Forth. потом на LISP. потом на C. потом на C++. теперь на LISP и C++. на LISP удобней писать, на C++ — отлаживать. %-)

собственно, весь ваш stl — хуита.

>языки описания сценариев игр (для небанальных случаев проще взять питон, что и делается).

для небанальных случаев проще взять Lua, что и делается.

/fixed/

> самое забавное -- ведь действительно нафиг не нужна. вот засада-то.

Если под математикой понимается матан с линейкой -- то да, если только вы не моделируете что-то, хорошо описываемой матаном или линейкой.

Но математика -- это не матан ;)

> для небанальных случаев проще взять Lua, что и делается.

Это с точки зрения спора не важно.

неверное потому, что они не нужны в больших количествах.

>вы ведь и в подмётки не годитесь Гвидо.

да, мы не придумывали язык, вдохновляясь примером whitespace.

это я саммоню луафагов и луахэйтеров, для фана.

> да, мы не придумывали язык, вдохновляясь примером whitespace.

whitespace на 1 лет моложе.

Ви таки что-то имеете против форматирования? Неужто анонимус озабочён сложностью кодогенерации на питоне?

На 12 лет.

> Ви таки что-то имеете против прибитого гвоздями форматирования?

fixed

Да

>Динамически типизированный язык? Не смешите мои тапки. Жаба - это не только мордны типа CRUD на вебе ваять.

вот потому я и сказал "вторым"

> Да

А в чём ваша проблема? Если это не кодогенерация -- то, как я смутно подозреваю, вы вряд ли придерживаетесь какого-либо coding style и в других языках.

Ссылку, ссылку в студию, сестра!

> Но математика -- это не матан ;)

Полностью соглашусь с тобой. Есть еще логика, теория предикатов, теория алгоритмов и прочее. Например, постановщик задачи должен мыслить математически. Это не значит, что он должен иметь диплом математика. Он просто должен так мыслить. Внутренняя непротиворечивость или корректность постановки задачи. Правильное определение основных use cases. Да и много всего остального наберется. Для все этого нужны навыки математического мышления.

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

Да, математика гораздо шире.

Еще вы тут спорите о том, кем должен быть настоящий супер-пупер программист. Математиком или филологом? На этот вопрос уже давно отвели. Как основные открытия делаются на стыке наук, так и классный специалист должен разбираться во многих вещах. Мыслить как математик, чувствовать красивый и некрасивый код как эстет. Иметь превосходную интуицию. Чтобы развить в себе эти качества нужны годы обучения как гуманитарным так и естественным наукам. (sv75, или это опять overkill?)

В общем, узкие специалисты имеют свой предел. И так в любой области.