Scala, programming language

начало

//0 - объявление синглентона. Один только экземпляр класса для одной запущенной виртуальной машины.А я слышал как - то, что синглентон, типа антипаттерн.

//6 - точка входа.

//2 - Как и //4 - псевдоимена для типов. Не макросы, конечно, мелочь, а приятно. type, стало быть, ключевое слово.

//6 - def - ключевое слово, предваряет определение функции, именование значений, мне показалось,
залог ленивых вычислений. Идентификатор аргумента, двоеточие, тип аргумента. Такая вот постфиксная запись типа. Затем, снова двоеточие, и тип возвращаемой функции. Unit - это {},
или какой ещё блок
{
// blah - не возвращает значение
...
// blah - не возвращает значение
} Лишь бы ничего не возвращал, отличного от Unit. Проще говоря, это аналог void.
Затем знак равенства и присвоение имени функции её тела.

//6 - Array[String] - так записываются массивы. Cтроки в Scala суть тоже, что java.lang.String, что System.String (type). А про реализацию остальных типов - пока лень писать.

//8 - val предваряет задание переменной. Тип переменной указывать не надо, если осуществляется присваивание. При чтении этой строки стоит вспомнить про алиасинг //4

//9 - реализация простенькой итерации. Отголосок куда более мощного _for-comprehension_.

//12
- самые интересные места. Здесь проявляется функциональная сущность языка.
//13

//16
... - простое рекурсивное определение степени полинома. Здесь момент следующий интересен.
//24
if - else не только позволяет управлять ходом программы, но и возвращать значения.
val stupid = if (2 * 2 == 5) true; else false; // stupid == false ?

Далее с //26 по //38 Проявляется императивная природа языка.
//32 - зачем, казалось бы, ведь и так при инициализации массива нули? Ответ - _autoboxing_, а причём он тут, ясно станет после фокуса - покуса.

//34
... - ещё один шаг к for-comprehension.
//35

//36 - Увы, Scala не позволяет +=. Есть над чем поработать.

//37 - тоже, что return res.

//40 - Функциональный язык, стало быть используются функции высшего класса. Вот здесь sum и есть пример функции высшего порядка
//41 функция func - это анонимная функция, передаваемая как параметр . Интересен и механизм реализации. Scala - чистый объектно - ориентированный язык, так - что все функции реализованы в качестве объектов от наследников класса Function.
В //13 в качестве func передаётся анонимная функция - возведение в квадрат.

ОК. Зачем это всё надо?
Попробуйте написать на си. А теперь представьте, что надо подсчитать число билетов
среди 666-значных
(Их кстати, если кому интересно
538079151326153145876812672
703682821787907087439114600
788208004293692163626037318
989889683811918801117259013
268437156410419913482851696
339359874967671641257893774
415926000547627887318126574
276450651556045762698825313
401252160655088090804344335
170937714013532330886003904
863390939174961501503535043
184246706293753992004579956
441943204515876597971007014
161553929197943243212253013
137281180213004803753046250
903339073468042217884460874
711688183880192496765650943
411152285323400206442042293
857601473239328901266495627
170021244534862169840600801
685774309618701631875006701
683932905251755249202790547
771834212513862982355467050
213263063303274885349835964
6207505459155000 штук ).
// Вглядитесь в цифры рассеянным взглядом, и вы увидите изображение манящей обнажённой женщины. Это сотона. Его проделки.
Итак, что делать с кодом на си?
А в случае scala?
В //2 меняю
type int_type = int на type int_type = BigInt
В // 12:
val happies3 = polynomeDegree(happies1, 3) на val happies3 = polynomeDegree(happies1, 333)
Фокус - покус.
А если, вдруг выяснится, что счастливые - это те из шестизнаков, у которых совпадает сумма цифр,имеющих
одно и то же значение порядкового номера по модулю три?
Звучит бредово, но надо же как внушать.
Я лишь меняю в // 12 на val happies3 = polynomeDegree(happies1, 2)
в // 13 Console.println(sum(x => x*x*x, happies3, 0)) - изменения. Bсего делов.
А вообще, _Джон Хьюз Сильные стороны функционального программирования softcraft.ru_

С java (.net?) всё ещё печальней
Даже, вроде как "оптимизированный" bruteforce код работает __неприлично__
долго. Гы, фактически и не работает. Уступая даже на шестизнаках scala коду.
~180 ms против 50 ms. Оно и понятно
Кривая встретившаяся Перу Гюнту, подозреваю, энто експонента.
На 666-знаках - обещанного три года ждать
(на самом деле больше: три года - оценка от выполнения for(int i = 0; i < 1000000; i++) if(i == 0);
в течении 10ms).

За .net не отвечаю, но в java хвостовая рекурсия не оптимизируется. Стало быть, при попытке реализовать что - то вроде как в scala, программа будет
тупить потихоньку будет. Если я сказал где глупость - прошу поправить ==. В любом случае, предлагаю ПАРИ на бутылку виноградного или гранатового сока
(я предпочитаю гранатовый ) что ни на java ни на...
* вспомнил, что .net не равно c#, задумался* .. ни на c# Вы не напишите код, быстрее, чем
приведённый на scala здесь. Я даже великодушно разрешаю переписать BigInt, или что там по необходимости, на более облегчённые классы, оставляя за собой право изменять sum. И сравниваемый код, конечно, должен запускаться на одной платформе.

Пока, scala без оптимизации выигрывает ~15000ms

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

А для чего же стоит использовать Scala - в следующий раз.

Это сообщение отредактировал Фома - 22.05.2006 - 18:31

Вести с фронтов.

Сижу. Голова посыпана пеплом.
Я как всякий неофит, неудержавшись - таки начал нести всякую блажь.
Скажем, java, действительно не оптимизирует хвостовую петлю (до версии 1.4 - точно),
но как ведёт себя scala, использующий java как платформу - вопрос. (Перевод ведётся )
Но не это самое печальное. Дело в том, что в конце предыдущего поста неявно подразумевалось,
что scala - де оптимизирует хвостовую рекурсию в алгоритме. Чёрта с два там хвостовая рекурсия!
Там его надо так "переписать", как ни один транcлятор не сможет.

в main :

Вот теперь - оптимизация может быть произведена.
Исполнение ~26199ms (запускал: java -Xmx256M -Xms32M test)
Поскольку BigInt, скорее всего, псевдоимя java.math.BigInteger, а в последнем умножение - не на основе быстрого по Тоому, то думаю, вызов можно дать и алгоритму на С++, но вообще,
я уже ни в чём не уверен.

Морально придавленный, ухожу созерцать пупок...

мда.....

Что скажешь,
Palu4

Давай более развёрнуто , что ли?
Если неинтересно, то почему?

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

Мой вариант.

Лучшего подхода не вижу.

тест
тест

Palu4
Ты хочешь поговорить об этом?

Давай, не стесняйся, я тут Элизу "подправил"

Простенький рецепт killer application, способного приятно удивить ваших друзей, и конкурентов тоже.
Возьмите программное обеспечение, _унаследованное_ от старых систем с их аппаратными ограничениями, старыми алгоритмами, вообще устаревшими подходами к использованию. Возьмите текущую ситуацию, современные требования. Устраните обнаруженные затруднения. Пряности из предыдущих технических решений, идей из сторонних областей - по вкусу.
По этому принципу, мне кажется, возник google, возникли пиринговые сети. Тривиальные соображения, да, но о них так легко забыть.

Что такое open source? В перспективе будущего, какое у него будущее? И какого чёрта люди извиняются за каламбуры и тавтологии?! Х. вам, а не извинения!!! Такой вот ход конём (жалко, не в центре текста). А никак по - другому. У нас, вообще, будущее не светлое, надо как - то скрашивать.
"За что бы не брался физик - в конечном счёте, всегда сделает бомбу. Что бы ни делал программист - у него получается платформа". Успешны не те проекты, которые используют открытые исходники, платформы, а те, что их поставляют.
Это не значит, что "перцепиенты" неуспешны, тут важны два момента: относительность - суть, в сравнении пользователей, и в пропорциях хороший/плохой продукт. Вот по этому, к примеру, тьма - тьмущая rss - агрегаторов уступает библиотеке libxml, или apr. Ну, хотя бы потому, что пользователей конкретного rss - агрегатора меньше, чем пользователей того же apr (разработчиков и пользователей соответствующих продуктов, в том числе, возможно, и этой нашей программки для rss).
Это тривиальная мысль: всегда делать выгоднее платформу. Возможна ещё разработка компонентов, но это будет ограничивать пользователей в некоторых случаях, а значит неприменимо. Сервисы, опять же. При современных тенденциях индустрии сервис для сервисов, вот чем _точно_ стоит заниматься. Вопрос: а кто будет разрабатывать интерфейсы программным агентам, web сервисам, а кто будет открывать структуру БД - для семантики работы - то? А не стоит ли признать, что старый подход к работе с данными не очень - то подходит для современного мира, со всё большей открытостью?
В самом деле, не публиковать же dump структуры БД?
Если кто не согласен в этом месте, сообщите пожалуйста, я проясню позицию.

А у open source, как и программирования вообще, будущего нет. Такие дела.

Вот, как обещал, мои взгляды.

Взять к примеру, следующее определение БД,

*База данных это*
* совокупность хранящихся с _отношениями_ между ними устойчивых (персистентных) данных, _отражающих знания_ о некоторой предметной области.
* при наличии такой минимальной избыточности, которая допускает их независимое использование оптимальным образом для одного или _нескольких_ приложений,
* при этом данные хранятся в таком виде, что они _независимы от программ их использующих_
* данные удовлетворяют условиям целостности и единым способам обработки.

При том взрывном росте сети, что происходил последние 15 лет, старый подход удачным не назовёшь. То что хорошо для уровня предприятия, в масштабах всего мира не потянет. Работать с данными, по определению, при таком подходе не возможно. Разумеется, они по прежнему будут хранится персистентно и в целостном виде и доступ к ним будет унифицирован... Вы посмотрите, к чему приводит эта пресловутая трёхзвенная архитектура. При нынешнем подходе для каждого серванта остальная сеть - всего - лишь _тонкий клиент_. Клиент, подсаженный на иглу api и размазанный по всей сети. Но Сеть - это не тонкий клиент. Имеем тупик, для интернет старый подход не годится. Я не про отрицание веб сервисов, а про сервисы с человеческим лицом.
Краткости ради, подчёркнуто то, что меня не устраивает.

_отношениями_

где реляции?!

Идеи реляционного исчисления в базах данных, в чистом виде, ни в чём не уступают семантическим сетям - такое моё впечатление от недавнего экскурса в область, и во всяком случае инструментарий работы и опыт использования побогаче имеют. Надо ли обосновывать тот факт, что данные по прежнему будут храниться в специальных хранилищах, и данные в xml документах/слаблструктурированые данные их не заменят. Но реляции давно похоронены под различными api (в лучшем случае) причём непонятно, почему клиент должен зависить от api, а не от данных, если даже не их семантики? Для возможности успешного взаимодействия и работы веб сервисов нужно грамотно описать данные, ими обрабатываемые, и через это, возможно, - сами правила работы.
При построении семантического веба также необходимо встроить имеющиеся даныые их в башню xml>rdf>(owl)

_отражающих знания_

Знание данных, отношения между ними, совершенно непрозрачны для клиента. Разработчики, впрочем, ещё могут договориться, в смысле понять друг друга, а вот обычный пользователь связан формой, которую ему сервер же и генерирует. Да, этот самый отвратительный из возможных интерфейсов при работе с данными, наиболее тяжело поддающийся автоматизации. Если из предлагающегося api ещё можно вытянуть информацию о семантике, то в последнем случае, образце массовго использования, для простого "соскабливания" информации требуется унизительная процедура реверсинга. Конечно, если бизнес серьёзный есть договорённости по протоколу например, через тот же SOAP, однако, я, или программа моя (программный агент) можем иметь запрос к данным заведомо более сложный, чем -навязывает- предлагает обслужить промежуточное звено. Это всё же транспорт, пусть и хорошо структурированный. Может быть, потребуется взаимодействие с данными из другого источника. Глобализация, требует усложнения связей в системе. При этом хотелось бы работать с данными, а не с "серым" ящиком, но, разумеется, глупо предполагать, что кто - то откроет структуру базы данных.
Верно и то, что более гибкое решение должно победить.

_нескольких_

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

_независимы от программ их использующих_

Итак, что имеем. Формально, всё верно и БД и их использование вписываются в схему из определения. На деле же оно не масштабируемо, в некотором смысле. Слабое место в том, что сами программы становятся зависимы не только от данных, но и от чего - то промежуточного.
Чем больше клиентов, тем разнообразнее их требования к данным. И хотелось бы, чтобы эти требования опирались на представления о структуре данных, на сами данные.
Такие дела.

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

По существу: Таких идей, в общем-то, в том или ином виде - миллион и маленькая тележка. Как насчет продемонстрировать преимущества подхода на практике?

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

Приходи обратно. Там есть и таких задач. Дело то пока что заморожено.

Вот недавно встретилось:

http://www.rod-linux.org/main/ideal.htm

http://www.rsdn.ru/article/mag/200505/singularity.xml

Вполне "в духе".

Фома
Ссылочки выглядят как Yet Another blah-blah-blah...
По первой сразу видно, что человек заблудился в целях и задачах, так что это вариант написания очередного текстового редактора или графической библиотеки (подставить по выбору). По второй ответ не так прост, просто ссылка неадекватна. В обоих случаях за деревьями не видно леса. Вопросы тут должны быть такие, как, впрочем, и всегда: Кому это надо; Зачем это им надо вместо того, что у них есть; Стоит ли овчинка выделки?

Да, вторая ссылка из кэша, не проверена.
Лучше http://research.microsoft.com/os/singularity/ как стартовая.

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