Category: наука

Category was added automatically. Read all entries about "наука".

glider

про ООП - 2

Я вот сейчас с ребе sorhed обсуждал и выяснил, что мне больше всего нравится в Скале. Ее система модулей основанная на объектах и миксинах. Объектно-ориентированная система.

Читал на днях недавнюю паперу First-Class Modules for Haskell, где рассказывается про то, как SPJ с товарищем добавляют Scala-like (ну, или ML-like, как кому приятнее) систему модулей в Хаскелл. Вслед за авторами сравнивал этот подход с Nested Types - основополагающей паперой Одерского.

Как я понял, все решают одну и ту же проблему. Как сделать так, чтобы: 1) был модуль Set с функциями empty, add и asList, 2) внутреннее представление множества (структуры данных, возвращаемой empty, и манипулируемой остальными функциями) было скрыто, 3) можно было писать s.add 1 s.empty и все тайпчекалось.

Это вполне можно сделать без объектов - как показывает практика ML и схема, описанная в папере про Хаскелл. Внутреннее представление скрывается за экзистенциальным типом (абстрактный тип в ML или экзистенциальный тип в расширенном Хаскелле), в язык добавляется конструкция, которая говорит, что у s.add и s.empty совместимые типы (manifest types в ML или open в расширенном Хаскелле) - все, готово, можно юзать.

Здорово то, как это сделано в Скале. Модули (они же objects ака singleton types) + абстрактные типы (они же abstract type members) + self-types или явные type refinements. Под капотом там тот же самый матан с экзистенциальными типами (чтобы убедиться, можно почитать вышеслинкованную паперу Nested Types), но выглядит это все как кейк паттерн на всем привычном.

Из ООП взята инкапсуляция как понимание того, что есть первоклассная сущность - модуль, он же объект - внутри которого находятся штучки (в данном случае, типы и термы). Взято наследование (ака subtyping) в плане того, что для абстрактных типов можно задавать upper bounds и в плане того, что сущности можно смешивать вместе при помощи миксин-композиции. Про полиморфизм можно много чего подогнать. Например то, что неважно, что именно под капотом абстрактного типа - главное, что все, кому надо, умеют с ним работать (через функции модуля или через функции из upper bound), поэтому подкапотное содержимое можно удобно заменять.

В итоге: ФП-шный матан теории типов скрестили с идеями из ООП - получилась Скала. Матан остался только под капотом, а фасад оказался "объектно-ориентированный", в результате чего получилась гибкая (наппример, на кейке без привлечения дополнительных языковых средств можно сделать виртуальные классы), но простая для восприятия система. upd. Хорошая иллюстрация к посту есть вот тут: http://maxim.livejournal.com/393915.html.
glider

имплициты

Недавно прошаривался в скале и нашел несколько интересных статей про имлициты:
* Can someone explain me implicit conversions in Scala? (материал для начального ознакомления с имплицитами)
* Where does Scala looks for implicits? (исчерпывающий материал по поводу видов имплицитов в скале и правил их поиска компилятором)
* Context and view bounds again (использование имплицитов для ограничения генерик-параметров - эмуляция тайпклассов Хаскелла. два подхода, каждый со своими плюсами и минусами)
* Implicit Parameters: Dynamic Scoping with Static Types (научная работа 2000 года, в ней Эрик Мейер с коллегами добавили неявные параметры в Хаскелл. интересно сравнить научное исследование и практическую реализацию, по сути, одной и той же идеи)

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

Во-первых, оператор пайплайна из F# (оригинальный пост):

implicit def toPipeLink[X](v: X): PipeLink[X] = new PipeLink[X](v)
class PipeLink[X](value: X) {
  def |>[Y](func: X => Y): Y = func(value)
}
Во-вторых, автоматическое каррирование (stackoverflow):

implicit def curryImplicitly[A,B,C](f: (A, B) => C) =
  (a: A) => (b: B) => f(a, b)
implicit def uncurryImplicitly[A,B,C](f: A => B => C) =
  (a: A, b: B) => f(a)(b)
В-третьих, вот способ попросить компилятор искать по всему графу неявных преобразований между типами, а не останавливаться на типах, непосредственно достижимых из текущего (тоже stackoverflow).

implicit def aToB(a: A): B = ... // will convert A to B
implicit def aToB[A1 <% A](a: A1): B = ... // will convert anything, that can be converted to A, to B
glider

убунта, часть 1: первый взгляд

часть 1: первый взгляд
часть 2: установка
часть 3: софт
часть 4: интероп с виндой
часть 5: обратно на винду

Решил снова попробовать убунту, и на этот раз она превзошла все ожидания. По сравнению с предыдущей попыткой, которая случилась прошлым летом, было гораздо легче подбирать софт, ибо (благодаря андроиду) много вещей, которые я юзаю, ушли в клауд. Но, в любом случае, случился прорыв в плане того, что я нашел замену тотал коммандеру.

Заметки по миграции:
1) Работают симлинки на NTFS (здесь особенно приятно то, что дропбокс на убунте с успехом хавает симлинк на виндовую папку дропбокса).
2) Опера абсолютно аналогична виндовой, причем запалили симлинки на конфиг-файлы оперы из винды; остальное синхронизировал через опера-линк.
3) Большая проблема в прошлогоднем экспириенсе с убунтой заключалась в отсутствии тотал коммандера. На текущий момент двухпанельный файл-менеджер с табами, который поддерживает инлайн чтение/запись архивов - это маст для моей продуктивности. Пробовал krusader, пробовал tuxcmd, пробовал mc - в итоге ни один из них не подошел. На этот раз посчастливилось найти double commander. Версия 0.4.5 оказалась столетней давности и даже не запустилась, но потом я случайно набрел на форум, на котором народ вовсю юзает найтли-билды 0.4.6, которые, на удивление, работают и поддерживают большую часть функционала тотала.
4) Для того, чтобы на каждом мониторе был свой таскбар, а также для быстрого переноса окон между мониторами, на винде я использую Ultramon. Под гномом первая часть получилась бесплатно (гномовский апплет window list, который можно вбросить на панельку сверху/снизу монитора, автоматом показывает лишь те окна, которые находятся на текущем мониторе). Вторую часть я реализовал несложным скриптом.
5) Эверноута для линукса нет и не планируется, но зато есть Nevernote. Он весьма медленно стартует + его интерфейс оставляет желать лучшего, но он работает, причем понимает не только плейн текст, но и рюшечки вроде чекбоксов.
6) На винде я часто пользуюсь мобипокетом для компиляции электронных книжек, которые потом читаю на телефоне с помощью fbreader или на компе тем же мобипокетом. К сожалению, мобипокета для линукса нет, но я нашел calibre (пока не протестировал как следует).
7) Для чатиков я заюзал прилаги, которые нашел в прошлом году - pidgin и skype. Тексты пишутся, звонки звонятся, нотификации можно настроить так, чтобы не лезли под руки (т.е. без попапов), но чтобы были заметными (отображались в трее убунты).
8) Порадовали средства для работы с картинками и документами. Evince поддерживает pdf, ps и djvu, причем не тормозит и рендерит ps-файлы шрифтами, которые можно читать без содрогания. Стандартный убунтовский просмотрщик картинок легковесный и удобный, вполне заменил мне irfanview.
9) Наконец, для просмотра видосов мне понравился smplayer. Поддерживается ускорение декодирования на CUDA (через libvdpau), можно настроить хоткеи аля kmplayer. Единственное, что расстроило - PgUp/PgDn открывают файлы только в пределах плейлиста, но не работают для навигации по файлам внутри папки (читай: для навигации по сериям).

Вопросы:
1) Нужна читалка для электронных книжек, которая поддерживает рендеринг текста в несколько колонок. Пробовал calibre, пробовал fbreader, пробовал coolreader - не умеют, к сожалению. Запускал mobipocket под вайном, но у него все шрифты получаются перекошенными.
2) Посоветуйте, пожалуйста, изящную прилагу для ведения заметок. Нужна поддержка (виртуальных или реальных) папок и рич-текста. Синхронизация с клаудом необязательна, ибо есть дропбокс. Клиент для андроида желателен.
3) Куда правильно ставить прилаги, которых нет в репозиториях (например, последние версии ЯП)? Я пока что ставлю в /usr/local, ибо это первая рекомендация, которую я увидел в инете. Есть еще опция ставить в /usr/share, /usr/lib и вбрасывать симлинки в /usr/bin. Также можно тупо ставить в /home/username. Непонятно, что выбрать.
glider

EPFL vs Google

С февраля я пытаюсь усидеть на двух стульях - параллельно подавать документы и в EPFL, и в Google.

До сегодняшнего дня это успешно удавалось, причем я ни одной из сторон про другую не рассказывал. Подготовка к собеседованию в гугл и сбор документов в Лозанну друг другу особо не мешали (разве что из-за тоефла пришлось немножко подвинуть гугл). Неделю назад прислали оффер из EPFL, но дедлайн ответа поставили на конец мая, поэтому письмо я более-менее спокойно заигнорил.

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

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

Уважаемые френды, что бы посоветовали вы?