Category: it

Category was added automatically. Read all entries about "it".

pony, django

Picat - новый язык программирования, основанный на логике

Недавно автор B-Prolog, профессор City University of New York Neng-Fa Zhou, придумал новый язык программирования - Picat (Pattern-matching, Imperative, Constraints, Actors, Tabling).

Язык во многом похож на B-Prolog (и реализация Picat внутри использует B-Brolog), но с элементами современных функциональных и императивных языков: функции в добавок к предикатам, циклы (которые транслируются в рекурсивные вызовы), опциональное деструктивное присваивание (компилируется при помощи дополнительных переменных), детерминизм по умолчанию, сопоставление с образцом вместо унификации при вызове предикатов...

Язык достаточно интересный. Официальный сайт - http://picat-lang.org/ - содержит большое количество примеров и документации. Я написал несколько блог-постов про Picat (на английском) - http://sdymchenko.com/tags/picat/ (на один из них, про декларативное решение задач планирования на Picat, разместили ссылку в меню официального сайте).

С официального сайта можно скачать версии Picat для Linux, MacOS и Windows.
Исходный код доступен под Mozilla Public License.
vacation photo
  • alexott

Вакансия engineering manager (Haskell/OCaml) в Германии

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

Одна компания занимающаяся информационной безопасностью (я не имею к ней никакого отношения) ищет менеджера для группы разработки которая занимается применением formal methods для задач инф. безопасности. Разработка ведется на Haskell/OCaml. Позиция в Дрездене, Германия. Компания вроде обеспечивает визу и т.п.

Кому интересно - пишите на почту alexott gmail...
Book

Haskell vs Prolog

Неожиданно пришёл развёрнутый ответ на мой старый (неумный, так что нет смысла приводить его здесь) пост о Haskell vs Prolog. Возражений 2: а) хаскелл не равноценная замена Прологу б) не надоть нам ентих абстракций.

> Хаскел не сложнее Пролога. Но он

возражаю. именно что "мощнее" (более широкого применения), но и сложнее на пару порядков. в понимании и применении.

1) любая претендующая на универсальность механика сложнее специализированной и оптимизированной под конкретный тип задач.

2) реализовать на Хаскеле или другом языке типа МЛ механику примитивного варианта пролога конечно можно. очень просто. несколько строк. но эта реализация будет годна лишь для простых задач. она _не будет конкурентоспособна_ и сравнима по эффективности с нормальными развитыми реализациями пролога, на более-менее крупных реальных проблемах. ни по скорости поиска решения. ни по обьему потребляемой памяти. ни по эффективности доступа к памяти (в том числе излишняя нагрузка на GC). не будет в ней и новых логических разработок типа constraints. которые дают во многих реальных задачах много порядков _алгоритмического_ преимущества перед примитивным старым движком пролога.

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

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

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

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

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

с уважением, 4KCheshireCat
китайский пазл, фиолетовый, игрушка, бегемот, lilo
  • beroal

экономический аспект

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

[Update 2014-11-05. «Украинки открыли охоту на женихов-программистов».]

[Update 2014-11-23. Когда будут популярны обычные статистики?]

1. Прикладная наука питается от промышленности. Информатика является теорией программирования. Поскольку программисты являются богачами, и информатикам должно что-то перепадать. Почему мы не наблюдаем перетока денег из программирования в информатику?
китайский пазл, фиолетовый, игрушка, бегемот, lilo
  • beroal

компилятор должен сохранять семантику

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

Пример 0. Арифметика. Чтобы учесть, что процессор оперирует с числами с ограниченной длиной, информатик задаёт следующую семантику для сложения в ЯП высокого уровня: «Если нет переполнения, то результат сложения равен результату математического сложения, иначе не определён». Формально a0 +h a1 := let b := a0+a1 in if b<limit then {b} else ℕ, то есть +h : ℕ×ℕ → P ℕ. Как композить операции такого типа, очевидно. Процессор, однако, считает по модулю limit или по методу saturated, во всех случаях ∀a0, a1. a0 +p a1 ⊆ a0 +h a1 (+p — сложение процессора). Я считаю, что компилятор имеет моральное право просто транслировать +h в +p. Таким образом, компилятор обязан «сужать» семантику.

Пример 0. Завершение программы. Я считаю, что компилятору достаточно подчиняться следующему правилу: если программа на ЯП высокого уровня завершается, то скомпилированная программа завершается. Не обязательно подчиняться обратной импликации.
hog
  • raydac

еще один Prolog для Java

по запросу японца одного, достал с полки пылившиеся сырцы моего движка Prolog для юзания вместе с JVM и сделал опенсоурс проект. Движок неочень мощный (зато маленький и весь в одном юберджарнике со всеми библиотеками), разрабатывался скорее для изучения языка и изучения разных механизмов взаимодействия с явой, но так позволяет писать несложное и смотреть как выполняется. Проект опубликован под Apache License 2.0 и доступен на https://code.google.com/p/jprol/
  • inv2004

q-sql

Оригинал тут: http://inv2004.livejournal.com/154388.html

Возникла необходимость выбрать новый тарифный план для сотового. Провозившить минут 30 с excel и google-docs стало понятно, что ничего толкового из этого не выйдет и без db тут не обойтись.

Чуть подумав рука сама набрала "q", так как это было единсвенное доступное на компьютере здесь и сейчас. Что про него знал, что первый и последний раз запускал год назад, минут на 30, для задачки nponeccop.

Дальше будет много q, а именно гибрида APL'а (а именно k k kx) и sql.

C:\Users\unknown\Dropbox\j>q
KDB+ 3.0 2013.02.06 Copyright (C) 1993-2013 Kx Systems
w32/ 2()core 2972MB unknown win-d2om7les24v 192.168.1.2 PLAY 2013.05.07


Collapse )
black
  • iamphet

Обработка исключений в Haskell

А как нынче модно обрабатывать исключения? Есть некое API, из большинства функций точит IO, но есть и чистые функциии.
Для последних самым подходящим решением кажется возврат Either: как-то глупо кидаться Control.Exception из чистого кода, ибо пользователю придётся лезть в IO для обработки.
Правда, тогда становится непонятно, что делать с IO функциями. Использование Control.Exception выглядит как-то несогласованно по сравнению с чистыми функциями, а натягивание Either поверх IO кажется негуманным по отношению к пользователям и самому себе. Или переживём?
светлое будущее
  • potan

Вакансии на Haskell (I-Teco, Москва)

Старший программист
Просто Программист
И Веб - программист

Первые две предполагают разработку на Haskell.
Третья может быть и без Haskell, но разработка web-интерфейса на чем-то отличным от js будет кстати ;-).

Это разработка новых приложений, бремя совместимости минимально.
китайский пазл, фиолетовый, игрушка, бегемот, lilo
  • beroal

группировка соседних элементов списка

Из списка нужно выбрать элементы, удовлетворяющие заданному предикату (аналогично base.Data.List.filter), и при этом сгруппировать соседние элементы.
? :: (a -> Bool) -> [a] -> [[a]]
Меня не столько интересует конкретная функция, сколько как вы представляете себе DSL, на котором удобно выразить такую функцию. (Здесь для конкретности я выбрал Haskell.)

(И ещё у меня такой вопрос: как понять метку «potan», которая есть в данном сообществе? :) )

[Update 2012-11-25. Признаюсь, что вопрос действительно является невнятным. Сомнительно выводить новый язык запросов из одного запроса. Считайте это мозговым штурмом.]