Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

February 28, 2016

Dimpl: An Efficient and Expressive DSL for Discrete Mathematics

Filed under: Discrete Structures,DSL,Functional Programming,Haskell,Mathematics — Patrick Durusau @ 4:34 pm

Dimpl: An Efficient and Expressive DSL for Discrete Mathematics by Ronit Jha.

Abstract:

This paper describes the language DIMPL, a domain-specific language (DSL) for discrete mathematics. Based on Haskell, DIMPL carries all the advantages of a purely functional programming language. Besides containing a comprehensive library of types and efficient functions covering the areas of logic, set theory, combinatorics, graph theory, number theory and algebra, the DSL also has a notation akin to one used in these fields of study. This paper also demonstrates the benefits of DIMPL by comparing it with C, Fortran, MATLAB and Python &emdash; languages that are commonly used in mathematical programming.

From the comparison, solving simultaneous linear equations:

dimpl

Much more is promised in the future for DIMPL:

Future versions of DIMPL will have an extended library comprising of modules for lattices, groups, rings, monoids and other discrete structures. They will also contain additional functions for the existing modules such as Graph and Tree. Moreover, incorporating Haskell’s support for pure parallelism and explicit concurrency in the library functions could significantly improve the efficiency of some functions on multi-core machines.

Can you guess the one thing that Ronit left out of his paper?

You guessed it!

Discrete Mathematics Programming Language – A Domain-Specific Language for Discrete Mathematics.

The Github URL for the repository. 😉

You should check out his homepage as well.

I have only touched the edges of this paper but it looks important.

Comments/suggestions?

I first saw this in a tweet by José A. Alonso

February 17, 2016

27 Reasons to Attend Clojure/West 2016 + Twitter List

Filed under: Clojure,Conferences,Functional Programming — Patrick Durusau @ 3:11 pm

Clojure/West 2016 Speakers

I extracted the speaker list plus twitter accounts where available from the speakers list for Clojure/West 2016.

Now you have twenty-seven reasons to attend! Stack those up against any to not attend.

Register: April 15th-16th, Seattle Marriott Waterfront

April 15th is “tax day” in the United States.

Wouldn’t you rather be having fun with Clojure than grubbing around with smudged and/or lost receipts? I thought so. Register today!

Whether the government picks you pocket one day or the next makes little difference.

File early and attend while the tax hounds try to decide if Thai numerals printed in Braille are a legitimate tax return. 😉

  1. Matthias Felleisen Types are like the Weather, Type Systems are like Weathermen
  2. Alex Kehayias Functional Game Engine Design for the Web
  3. Allison Carter, From Fluxus to Functional: A Journey Through Interactive Art
  4. Amie Kuttruff, Deepen and Diversify the Clojure Community with Jr Engineers
  5. Aysylu Greenberg, (+ Loom (years 2))
  6. Bryce Covert, USE lisp WITH game – Making an Adventure Game with Clojure
  7. Christopher Small, Datalog all the way down
  8. Claire Alvis, Creating DSLs – a tale of spec-tacular success and failure
  9. Daniel Higginbotham, Parallel Programming, Fork/Join, and Reducers
  10. Devon Peticolas, One Million Clicks per Minute with Kafka and Clojure
  11. Donevan Dolby, Managing one of the world’s largest Clojure code bases
  12. Gerred Dillon, ClojureScript and Lambda: A Case Study
  13. Ghadi Shayban, Parsing Text with a Virtual Machine
  14. Jack Dubie, Fast full stack testing in om.next
  15. Jonathan Boston, Caleb Phillips, Building a Legal Data Service with Clojure
  16. Katherine Fellows, Anna Pawlicka, ClojureBridge in Practice
  17. Mario Aquino, The Age of Talkies
  18. Michael Drogalis, Inside Onyx
  19. Michał Marczyk, defrecord/deftype in Clojure and ClojureScript
  20. Mikaela Patella, Web Development is Distributed Systems Programming
  21. Nathan Marz, Specter: powerful and simple data structure manipulation
  22. Nathan Sorenson, Hybrid Automata and the Continuous Life
  23. Patrick O’Brien, Braid Chat: Reifying Online Group Conversations
  24. Paula Gearon, Production Rules in Datomic
  25. Peter Schuck Hash Maps: more room at the bottom
  26. Priyatam Mudivarti, Caching half a billion user transactions
  27. Stuart Sierra, The Joys and Perils of Interactive Development

PS: Be careful how you use the term “weathermen.” The professionally paranoid in government remember a different meaning that what you may intend. As do some of the rest of us.

February 13, 2016

Clojure for the Brave and True (Google Group)

Filed under: Clojure,Functional Programming,Programming — Patrick Durusau @ 5:02 pm

Clojure for the Brave and True (Google Group) by Daniel Higginbotham.

First there was the website: Clojure for the Brave and True.

Then there was the book: Clojure for the Brave and True.

But before the book there was Daniel’s twitter account: @nonrecursive.

There’s no truth to the rumor of a free print trade publication with the title: Clojure for the Brave and True so please direct your questions and answers to:

Clojure for the Brave and True (Google Group)

Enjoy!

February 11, 2016

Designing with Data (Clojure)

Filed under: Clojure,Design,Functional Programming — Patrick Durusau @ 9:00 pm

Designing with Data by Michael Dorgalis.

Slides from keynote at Clojure Remote 2016.

Without the video of the presentation, the usual difficulties of using slides in isolation obtain.

On the plus side, you have to work harder for the information and that may enhance your retention/comprehension.

Enjoy!

February 6, 2016

Clojure for Data Science [Caution: Danger of Buyer’s Regret]

Filed under: Clojure,Data Science,Functional Programming,Programming — Patrick Durusau @ 10:15 pm

Clojure for Data Science by Mike Anderson.

From the webpage:

Presentation given at the Jan 2016 Singapore Clojure Users’ Group

You will have to work at the presentation because there is no accompanying video, but the effort will be well spent.

Before you review these slides or pass them onto others, take fair warning that you may experience “buyer’s regret” with regard to your current programming language/paradigm (if not already Clojure).

However powerful and shiny your present language seems now, its luster will be dimmed after scanning over this slides.

Don’t say you weren’t warned ahead of time!

BTW, if you search for “clojure for data science” (with the quotes) you will find among other things:

Clojure for Data Science Progressing by Henry Garner (Packt)

Repositories for the Clojure for Data Science Processing book.

@cljds Clojure Data Science twitter feed (Henry Garner). VG!

Clojure for Data Science Some 151 slides by Henry Garner.

Plus:

Planet Clojure, a metablog that collects posts from other Clojure blogs.

As a close friend says from time to time, “clojure for data science,”

G*****s well.” 😉

Enjoy!

January 14, 2016

New Clojure website is up!

Filed under: Clojure,Functional Programming — Patrick Durusau @ 9:56 pm

Clojure

From the website:

Clojure is a robust, practical, and fast programming language with a set of useful features that together form a simple, coherent, and powerful tool.

The Clojure Programming Language

Clojure is a dynamic, general-purpose programming language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language, yet remains completely dynamic – every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

I hope you find Clojure’s combination of facilities elegant, powerful, practical and fun to use.

Rich Hickey
author of Clojure and CTO Cognitect

I think the green color scheme in the header was intended to tie in with the download link for Clojure 1.7.0. 😉

If you haven’t downloaded Clojure 1.7.0, what are you waiting for?

Enjoy!

January 5, 2016

Clojure Distilled

Filed under: Clojure,Functional Programming — Patrick Durusau @ 7:25 pm

Clojure Distilled by Dmitri Sotnikov.

From the post:

The difficulty in learning Clojure does not stem from its syntax, which happens to be extremely simple, but from having to learn new methods for solving problems. As such, we’ll focus on understanding the core concepts and how they can be combined to solve problems the functional way.

All the mainstream languages belong to the same family. Once you learn one of these languages there is very little effort involved in learning another. Generally, all you have to do is learn some syntax sugar and the useful functions in the standard library to become productive. There might be a new concept here and there, but most of your existing skills are easily transferable.

This is not the case with Clojure. Being a Lisp dialect, it comes from a different family of languages and requires learning new concepts in order to use effectively. There is no reason to be discouraged if the code appears hard to read at first. I assure you that the syntax is not inherently difficult to understand, and that with a bit of practice you might find it to be quite the opposite.

The goal of this guide is to provide an overview of the core concepts necessary to become productive with Clojure. Let’s start by examining some of the key advantages of the functional style and why you would want to learn a functional language in the first place.

Dmitri says near the end, “…we only touched on only a small portion of the overall language…,” but it is an impressive “…small portion…” and is very likely to leave you wanting to hear more.

The potential for immutable data structures in collaborative environments is vast. I’ll have something longer to post on that next week.

Enjoy!

November 28, 2015

Optimizing Hash-Array Mapped Tries…

Filed under: Clojure,Functional Programming,Hashing,Scala — Patrick Durusau @ 11:53 am

Optimizing Hash-Array Mapped Tries for Fast and Lean Immutable JVM Collections by Adrian Colyer.

Adrian’s review of Optimizing Hash-Array Mapped Tries for Fast and Lean Immutable JVM Collections by Steinforder & Vinju, 2015, starts this way:

You’d think that the collection classes in modern JVM-based languages would be highly efficient at this point in time – and indeed they are. But the wonderful thing is that there always seems to be room for improvement. Today’s paper examines immutable collections on the JVM – in particular, in Scala and Clojure – and highlights a new CHAMPion data structure that offers 1.3-6.7x faster iteration, and 3-25.4x faster equality checking.

CHAMP stands for Compressed Hash-Array Mapped Prefix-tree.

The use of immutable collections is on the rise…

Immutable collections are a specific area most relevant to functional/object-oriented programming such as practiced by Scala and Clojure programmers. With the advance of functional language constructs in Java 8 and functional APIs such as the stream processing API, immutable collections become more relevant to Java as well. Immutability for collections has a number of benefits: it implies referential transparency without giving up on sharing data; it satisfies safety requirements for having co-variant sub-types; it allows to safely share data in presence of concurrency.

Both Scala and Clojure use a Hash-Array Mapped Trie (HAMT) data structure for immutable collections. The HAMT data structure was originally developed by Bagwell in C/C++. It becomes less efficient when ported to the JVM due to the lack of control over memory layout and the extra indirection caused by arrays also being objects. This paper is all about the quest for an efficient JVM-based derivative of HAMTs.

Fine-tuning data structures for cache locality usually improves their runtime performance. However, HAMTs inherently feature many memory indirections due to their tree-based nature, notably when compared to array-based data structures such as hashtables. Therefore HAMTs presents an optimization challenge on the JVM. Our goal is to optimize HAMT-based data structures such that they become a strong competitor of their optimized array-based counterparts in terms of speed and memory footprints.

Adrian had me at: “a new CHAMPion data structure that offers 1.3-6.7x faster iteration, and 3-25.4x faster equality checking.”

If you want experience with the proposed data structures, the authors have implemented them in the Rascal Metaprogramming Language.

I first saw this in a tweet by Atabey Kaygun

November 18, 2015

Christopher Meiklejohn – Doctoral Thesis Proposal

Filed under: Distributed Computing,Functional Programming — Patrick Durusau @ 5:49 pm

Christopher Meiklejohn – Doctoral Thesis Proposal.

From the proposal:


The goal of this research is to provide a declarative way to design distributed, fault-tolerant applications that do not contain observable nondeterminism. These applications should be able to be placed at arbitrary locations in the network: mobile devices, “Internet of Things” hardware, or personal computers. Applications should be tolerant to arbitrary message delays, duplication and reordering: these are first-class requirements of distributed computations over unreliable networks. When writing these applications, developers should not have to use traditional concurrency control or synchronization mechanisms such as mutexes, semaphores, or monitors: the primitive operations for composition in the language should yield “deterministic-by-construction” applications.

Christopher is looking for comments on his doctoral thesis proposal.

His proposal is dated November 11, 2015, so time remains for you to review the proposal and make comments.

It would be really nice if the community that will benefit from Christopher’s work would contribute some comments on it.

November 15, 2015

Mutable Data Structures

Filed under: Data Structures,Functional Programming — Patrick Durusau @ 11:41 am

The best illustration of the dangers of mutable data structures I have found to date.

Mutable data structures and algorithms based upon them were necessary when computer memory was far more limited than it is today.*

Why are you still using mutable data structures and algorithms based on hardware that doesn’t exist anymore?

I first saw this in a tweet by the Software Exorcist.

* Granting there are cases, the CERN comes to mind, where the memory requirements for some applications exceed available memory. You aren’t working at the CERN are you?

November 1, 2015

Locked doors, headaches, and intellectual need (teaching monads)

Filed under: Education,Functional Programming,Teaching,Topic Maps — Patrick Durusau @ 8:34 pm

Locked doors, headaches, and intellectual need by Max Kreminski.

From the post:


I was first introduced to the idea of problem-solution ordering issues by Richard Lemarchand, one of my game design professors. The idea stuck with me, mostly because it provided a satisfying explanation for a certain confusing pattern of player behavior that I’d witnessed many times in the past.

Here’s the pattern. A new player jumps into your game and starts bouncing around your carefully crafted tutorial level. The level funnels them to the key, which they collect, and then on to the corresponding locked door, which they successfully open. Then, somewhere down the road, they encounter a second locked door… and are completely stumped. They’ve solved this problem once before – why are they having such a hard time solving it again?

What we have here is a problem-solution ordering issue. Because the player got the key in the first level before encountering the locked door, they never really formed an understanding of the causal link between “get key” and “open door”. They got the key, and then some other stuff happened, and then they reached the door, and were able to open it; but “acquiring the key” and “opening the door” were stored as two separate, disconnected events in the player’s mind.

If the player had encountered the locked door first, tried to open it, been unable to, and then found the key and used it to open the door, the causal link would be unmistakable. You use the key to open the locked door, because you can’t open the locked door without the key.

This problem becomes a lot more obvious when you don’t call the key a key, or when the door doesn’t look like a locked door. The “key/door” metaphor is widely understood and frequently used in video games, so many players will assume that you use a key to open a locked door even if your own game doesn’t do a great job of teaching them this fact. But if the “key” is really a thermal detonator and the “door” is really a power generator, a lot of players are going to wind up trying to destroy the second generator they encounter by whacking it ineffectually with a sword.

Max goes on to apply problem-solution ordering to teaching both math and monads.

I don’t recall seeing or writing any topic map materials that started with concrete problems that would be of interest to the average user.

Make no mistake, there were always lots of references to where semantic confusion was problematic but that isn’t the same as starting with problems a user is likely to encounter.

The examples and literature Max points to makes me interested in started with concrete problems topic maps are good at solving and then introducing topic map concepts as necessary.

Suggestions?

October 29, 2015

Concurrency, Specification & Programming (CS&P 2015)

Filed under: Concurrent Programming,Functional Programming,Programming — Patrick Durusau @ 9:38 am

Concurrency, Specification & Programming, volume 1, Zbigniew Suraj, Ludwik Czaja (Eds.)

Concurrency, Specification & Programming, volume 2, Zbigniew Suraj, Ludwik Czaja (Eds.)

From the preface:

This two-volume book contains the papers selected for presentation at the Concurrency, Specification and Programming (CS&P) Workshop. It is taking place from 28th to 30th September 2015 in Rzeszow, the biggest city in southeastern Poland. CS&P provides an international forum for exchanging scientific, research, and technological achievements in concurrency, programming, artificial intelligence, and related fields. In particular, major areas selected for CS&P 2015 include mathematical models of concurrency, data mining and applications, fuzzy computing, logic and probability in theory of computing, rough and granular computing, unconventional computing models. In addition, three plenary keynote talks were delivered.

Not for the faint of heart but if you are interested in the future of computing, these two volumes should be on your reading list.

October 21, 2015

Clojure for the Brave and True Update!

Filed under: Clojure,Functional Programming,Programming — Patrick Durusau @ 3:08 pm

Clojure for the Brave and True by Daniel Higginbotham.

From the webpage:

Clojure for the Brave and True is now available in print! You can use the coupon code ZOMBIEHUGS to get 30% off at No Starch (plus you’ll get a free sticker), or buy it from Amazon.

The web site has been updated, too! (Don’t forget to force refresh.) One of the reasons I went with No Starch as a publisher was that they supported the idea of keeping the entire book available for free online. It makes me super happy to release the professionally-edited, even better book for free. I hope it makes you laugh, cry, and give up on object-oriented programming forever.

Writing this book was one of the most ambitious projects of my life, and I appreciate all the support I’ve gotten from friends, family, and readers like you. Thank you from the bottom of my crusty heart!

[Update] I got asked for a list of the major differences. Here they are:

  • Illustrations!
  • Almost every chapter now has exercises
  • The first macro chapter, Read and Eval, is massively improved. I’m hoping this will gives readers an excellent conceptual foundation for working with macros
  • There’s now a joke about melting faces
  • There used to be two Emacs chapters (basic emacs and using Emacs for Clojure dev), now there’s just one
  • The concurrency chapter got split into two chapters
  • Appendices on Leiningen and Boot were added
  • The “Do Things” chapter is much friendlier
  • I spend a lot more time explaining some of the more obscure topics, like lazy sequences.
  • Many of the chapters got massive overhauls. The functional programming chapter, for example, was turned completely inside out, and the result is that it’s much, much clearer
  • Overall, everything should be clearer

Daniel has taken the plunge and quit his job to have more time for writing. If you can, buy a print copy and recommend Clojure for the Brave and True to a friend!

We need to encourage people like Daniel and publishers like No Starch. Vote with your feet and your pocket books.

Follow Daniel on twitter @nonrecursive

October 17, 2015

@SwiftLang “better, more valuable…than Haskell”?

Filed under: Functional Programming,Haskell — Patrick Durusau @ 2:02 pm

Erik Meijer tweeted:

At this point, @SwiftLang is probably a better, and more valuable, vehicle for learning functional programming than Haskell.

Given Erik’s deep experience and knowledge of functional programming, such a tweet has to give you pause.

Less daunting was the “67 retweets 56 favorites” by the known users of SwiftLang. 😉

A more accurate statement would be:

At this point, @SwiftLang is probably a better, and more valuable, vehicle for learning functional programming than Haskell, if you program for iOS, OS X, and watchOS.

Yes?

October 15, 2015

Clojure Remote February 11-12, 2016 — Online

Filed under: Clojure,Conferences,Functional Programming,Programming — Patrick Durusau @ 1:58 pm

Clojure Remote February 11-12, 2016 — Online

Important Dates:

  • Oct. 15 — Early-bird admission starts.
  • Oct. 30 — CFP opens, Regular admission rate begins
  • Dec. 31 — CFP closes
  • Jan. 15 — Schedule released
  • Feb. 11, 12 — The Conference!

From the webpage:

This Winter, Homegrown Labs presents Clojure Remote—Clojure’s first exclusively Remote conference. Join us anywhere; from your home, your office, or the coffee shop.

Over two days, you’ll join hundreds of other Clojurists online via crowdcast.io to enjoy up to two tracks of beginner to intermediate Clojure talks.

Clojure Remote will be held February 11th and 12th, 2016 from 2:00 PM UTC – 9:00 pm UTC.

The conference will be broadcast via crowdcast.io, where attendees can:

  • View talks live
  • Ask & up-vote questions
  • And chat with fellow attendees.

Clojure Remote attendees will miss:

  • Delays and frustrations of airport security and missed connections
  • Wedging themselves into grade school size airline seats
  • Taxi transportation where drivers speak every language but yours
  • Disease producing dry air in hotels
  • Expenses that could have gone towards new hardware or books

but, for virtual conferences to make progress, sacrifices have to be made. 😉

True, virtual conferences do lack some of the randomness and “press the flesh” opportunities of physical conferences but CS has been slow to take up the advantages of more frequent but shorter virtual or online conferences.

October 11, 2015

Learning FP the hard way:…

Filed under: Elm,Functional Programming,Programming — Patrick Durusau @ 2:44 pm

Learning FP the hard way: Experiences on the Elm language by Ossi Hanhinen.

From the webpage:

Foreward

A good friend of mine convinced me about the benefits of Reactive Programming not that long ago. It almost feels wrong not to write Functional Reactive Programming — apparently the functional methodology lends itself magnificently to complement reactive programming. How, I did not know. So I decided to learn this stuff.

Knowing myself, I soon realized I would only ever get in the mindset if I had to solve some actual problems using the techniques. Having written JavaScript for the past few years, I could have just gone for RxJS. But again, I knew myself and felt it would give me way too much room for “going against the grain”. I needed something that would enforce me to solve everything in a functional manner. This is where Elm comes in.

Elm? What’s that?

Elm is a programming language that compiles to HTML5: HTML, CSS and JavaScript. Depending on how you display your output, it may be a <canvas> with objects inside, or a more traditional web page. Let me repeat. Elm is a language, which compiles into the three languages used to build web apps. What’s more, it is a functional reactive programming language with strong types and immutable data structures.

Okay, so you may have gathered I am no expert in this field, but in case you’re lost, here are my short explanations on the terminology: Appendix: Glossary.

I can think of three reasons why you should read Ossi’s post:

#3 – You like functional programming languages.

#2 – Elm sounds like a great way to avoid writing HTML5: HTML, CSS and JavaScript.

And the #1 reason people will read Ossi’s post:

#1 It provides a base for writing a Space Invaders type game! 😉

I liked Space Invaders but my personal favorite was Missile Command. It was so bad, once upon a time, that I had a jar into which I had to put quarters for each game. Just to keep time spent playing to a reasonable amount.

Enjoy!

October 8, 2015

SICP Distilled Now Public

Filed under: Clojure,Functional Programming,Lisp,Scheme — Patrick Durusau @ 6:21 pm

SICP Distilled Now Public by Tom Hall.

From the post:

I have made the SICP Distilled site public.

It is now a year since the SICP Distilled Kickstarter was funded, I originally thought it would take 5 months to complete and had a slightly different vision for what it would look like, massive thanks to all of the supporters for their patience and understanding.

I originally thought an accompaniment to the original book but it has wound up being more like a rewrite, fortunately the original text is under a Creative Commons Attribution-ShareAlike 4.0 License so I can ‘remix’ it without getting into copyright issues if I have the same licence.

It is not complete yet, but I think I now have good explanations of:

Which really are (for me at least) the highlights of the book.

As a very minor supporter in the Kickstarter campaign I deeply appreciate all the effort that Tom has devoted to this effort.

Comment early and often!

October 7, 2015

NLP and Scala Resources

Filed under: Functional Programming,Natural Language Processing,Scala,ScalaNLP — Patrick Durusau @ 9:33 pm

Natural Language Processing and Scala Tutorials by Jason Baldridge.

An impressive collection of resources but in particular, the seventeen (17) Scala tutorials.

Unfortunately, given the state of search and indexing it isn’t possible to easily dedupe the content of these materials against others you may have already found.

September 25, 2015

Three Reasons You May Not Want to Learn Clojure [One of these reasons applies to XQuery]

Filed under: Clojure,Functional Programming,XQuery — Patrick Durusau @ 7:34 pm

Three Reasons You May Not Want to Learn Clojure by Mark Bastian.

From the post:

I’ve been coding in Clojure for over a year now and not everything is unicorns and rainbows. Whatever language you choose will affect how you think and work and Clojure is no different. Read on to see what some of these effects are and why you might want to reconsider learning Clojure.

If you are already coding in Clojure, you will find this amusing.

If you are not already coding in Clojure, you may find this compelling.

I won’t say which one of these reasons applies to XQuery, at least not today. Watch this blog on Monday of next week.

August 21, 2015

Parens of the Dead

Filed under: Clojure,ClojureScript,Functional Programming,Games,Programming — Patrick Durusau @ 7:43 pm

Parens of the Dead: A screencast series of zombie-themed games written with Clojure and ClojureScript.

Three episodes posted thus far:

Episode 1: Lying in the Ground

Starting with an empty folder, we’ll lay the technical groundwork for our game. We’ll get a Clojure web server up and running, compiling and sending ClojureScript to the browser.

Episode 2: Frontal Assualt

In this one, we create most of the front-end code. We take a look at the data structure that describes the game, using that to build up our UI.

Episode 3: What Lies Beneath

The player has only one action available; revealing a tile. We’ll start implementing the central ‘reveal-tile’ function on the backend, writing tests along the way.

Next episode? Follow @parensofthedead

Another innovative instruction technique!

Suggestions:

1) Have your volume control available because I found the sound in the screencasts to be very soft.

2) Be prepared to move very quickly as episode one, for example, is only eleven minutes long.

3) Download the code and walk through it at a slower pace.

Enjoy!

August 17, 2015

State of the Haskell ecosystem – August 2015

Filed under: Functional Programming,Haskell — Patrick Durusau @ 3:43 pm

State of the Haskell ecosystem – August 2015 by Gabriel Gonzalez.

From the webpage:

In this post I will describe the current state of the Haskell ecosystem to the best of my knowledge and its suitability for various programming domains and tasks. The purpose of this post is to discuss both the good and the bad by advertising where Haskell shines while highlighting where I believe there is room for improvement.

This post is grouped into two sections: the first section covers Haskell’s suitability for particular programming application domains (i.e. servers, games, or data science) and the second section covers Haskell’s suitability for common general-purpose programming needs (such as testing, IDEs, or concurrency).

The topics are roughly sorted from greatest strengths to greatest weaknesses. Each programming area will also be summarized by a single rating of either:

  • Best in class: the best experience in any language
  • Mature: suitable for most programmers
  • Immature: only acceptable for early-adopters
  • Bad: pretty unusable

The more positive the rating the more I will support the rating with success stories in the wild. The more negative the rating the more I will offer constructive advice for how to improve things.

There is nothing that provokes discussion more than a listing of items with quality rankings!

Enjoy!

August 10, 2015

Agda Tutorial

Filed under: Functional Programming,Programming — Patrick Durusau @ 7:53 pm

Agda Tutorial

Something to jump start your mental engine after pre-Republican Presidential candidate debate, Republican Presidential candidate debate and post-Republican Presidential candidate debate mental debilitation. 😉

From the Agda wiki:

Agda is a dependently typed functional programming language. It has inductive families, i.e., data types which depend on values, such as the type of vectors of a given length. It also has parametrised modules, mixfix operators, Unicode characters, and an interactive Emacs interface which can assist the programmer in writing the program.

Agda is a proof assistant. It is an interactive system for writing and checking proofs. Agda is based on intuitionistic type theory, a foundational system for constructive mathematics developed by the Swedish logician Per Martin-Löf. It has many similarities with other proof assistants based on dependent types, such as Coq, Epigram, Matita and NuPRL.

Agda is open-source and enjoys contributions from many authors. The center of the Agda development is the Programming Logic group at Chalmers and Gothenburg University; the main developers are Ulf Norell, Nils Anders Danielsson, and Andreas Abel.

Enjoy!

August 1, 2015

Lasp

Filed under: CRDT,Erlang,Functional Programming,Lasp — Patrick Durusau @ 8:01 pm

Lasp: A Language for Distributed, Eventually Consistent Computations by Christopher S. Meiklejohn and Peter Van Roy.

From the webpage:

Why Lasp?

Lasp is a new programming model designed to simplify large scale, fault-tolerant, distributed programming. Lasp is being developed as part of the SyncFree European research project. It leverages ideas from distributed dataflow extended with convergent replicated data types, or CRDTs. This supports computations where not all participants are online together at a given moment. The initial design supports synchronization-free programming by combining CRDTs together with primitives for composing them inspired by functional programming. This lets us write long-lived fault-tolerant distributed applications, including ones with nonmonotonic behavior, in a functional paradigm. The initial prototype is implemented as an Erlang library built on top of the Riak Core distributed systems infrastructure.

Interested?

Other resources include:

Lasp-dev, the mailing list for Lasp developers.

Lasp at Github.

I was reminded to post about Lasp by this post from Christopher Meiklejohn:

This post is a continuation of my first post about leaving Basho Technologies after almost 4 years.

It has been quite a long time in the making, but I’m finally happy to announce that I am the recipient of a Erasmus Mundus fellowship in their Joint Doctorate in Distribute Computing program. I will be pursuing a full-time Ph.D., with my thesis devoted to developing the Lasp programming language for distributed computing with the goals of simplifying deterministic, distributed, edge computation.

Starting in February 2016, I will be moving to Belgium to begin my first year of studies at the Université catholique de Louvain supervised by Peter Van Roy followed by a second year in Lisbon at IST supervised by Luís Rodrigues.

If you like this article, please consider supporting my writing on gittip.

Looks like exciting developments are ahead for Lash!

Congratulations to Christopher Meiklejohn!

July 26, 2015

Learning Data Science Using Functional Python

Filed under: Data Science,Functional Programming,Python — Patrick Durusau @ 8:14 pm

Learning Data Science Using Functional Python by Joel Grus.

Something fun to start the week off!

Apologies for the “lite” posting of late. I am munging some small but very ugly data for a report this coming week. The data sources range from spreadsheets to forms delivered in PDF, in no particular order and some without the original numbering. What fun!

Complaints about updating URLs that were redirects were meet with replies that “private redirects” weren’t of interest and they would continue to use the original URLs. Something tells me the responsible parties didn’t quite get what URL redirects are about.

Another day or so and I will be back at full force with more background on the Balisage presentation and more useful posts every day.

July 15, 2015

Clojure At Scale @WalmartLabs

Filed under: BigData,Clojure,Functional Programming — Patrick Durusau @ 3:41 pm

From the description:

There are many resources to help you build Clojure applications. Most however use trivial examples that rarely span more than one project. What if you need to build a big clojure application comprising many projects? Over the three years that we’ve been using Clojure at WalmartLabs, we’ve had to figure this stuff out. In this session, I’ll discuss some of the challenges we’ve faced scaling our team and code base as well as our experience using Clojure in the enterprise.

I first saw this mentioned by Marc Phillips in a post titled: Walmart Runs Clojure At Scale. Marc mentions a tweet from Anthony Marcar that reads:

Our Clojure system just handled its first Walmart black Friday and came out without a scratch.

Black Friday,” is the Friday after the Thanksgiving holiday in the United States. Since 2005, it has been the busiest shopping day of the year and in 2014, $50.9 billion was spend on that one day. (Yes, billions with a “b.”)

Great narrative of issues encountered as this system was built to scale.

July 7, 2015

What Lies Beneath: A Deep Dive into Clojure’s data structures

Filed under: Clojure,Functional Programming,Programming — Patrick Durusau @ 2:03 pm

What Lies Beneath: A Deep Dive into Clojure’s data structures by Mohit Thatte. (slides)

From the description:

Immutable, persistent data structures are at the heart of Clojure’s philosophy. It is instructive to see how these are implemented, to appreciate the trade-offs between persistence and performance. Lets explore the key ideas that led to effective, practical implementations of these data structures. There will be animations that should help clarify key concepts!

Video: Running time a little over thirty-five minutes (don’t leave for coffee).

Closes with a great reading list.

You may also want to review: Purely functional data structures demystified (slides).

Description:

I spoke about ‘Purely Functional Data structures’ at Functional Conference 2014 in Bangalore. These are my slides with an extra section on further study.

This talk is based on Chris Okasaki’s book title Purely Functional Data Structures. The gist is that immutable and persistent data structures can be designed without sacrificing performance.

Computer trivia question from the first video: Why are the colors red and black used for red and black trees?

June 16, 2015

Reasoned Programming

Filed under: Functional Programming,Programming,Reasoning — Patrick Durusau @ 7:24 pm

Reasoned Programming by Krysia Broda, Susan Eisenbach, Hessam Khoshnevisan, and, Steve Vickers.

From the preface:

How do you describe what a computer program does without getting bogged down in how it does it? If the program hasn’t been written yet we can ask the same question using a different tense and slightly different wording: How do you specify what a program should do without determining exactly how it should do it? Then we can add the question: When the program is written, how do you judge that it satisfi es its specifi cation?

In civil engineering, one can ask a very similar pair of questions: How can you specify what a bridge should do without determining its design? And, when it has been designed, how can you judge whether it does indeed do what it should?

This book is about these questions for software engineering, and its answers can usefully be compared with what happens in civil engineering. First, a speci fication is a different kind of thing from a design; the specifi cation of a bridge may talk about loadbearing capacity, deflection under high winds and resistance of piers to water erosion, while the design talks about quite different things such as structural components and their assembly. For software, too, speci fications talk about external matters and programs talk about internal matters.

The second of the two questions is about judging that one thing satisfi es another. The main message of the book and a vitally important one is that judgement relies upon understanding.  This is obviously true in the case of the bridge; the judgement that the bridge can bear the speci fied load rests on structural properties of components enshrined in engineering principles, which
in turn rest upon the science of materials. Thus the judgement rests upon a tower of understanding.

This tower is well-established for the older engineering disciplines; for software engineering it is still being built. (We may call it software science.’) The authors have undertaken to tell students in their fi rst or second year about the tower as it now stands, rather than dictate principles to them. This is refreshing in software engineering there has been a tendency to substitute formality for understanding. Since a program is written in a very formal language and the specifi cation is also often written in formal logical terms, it is natural to emphasize formality in making the judgement that one satifis es the other. But in teaching it is stultifying to formalize before understanding, and software science is no exception — even if the industrial signi ficance of a formal veri fication is increasingly being recognized.

This book is therefore very approachable. It makes the interplay between speci fication and programming into a human and flexible one, albeit guided by rigour. After a gentle introduction, it treats three or four good-sized examples, big enough to give con fidence that the approach will scale up to industrial software; at the same time, there is a spirit of scienti c enquiry. The authors have made the book self-contained by including an introduction to logic written in the same spirit. They have tempered their care for accuracy with a light style of writing and an enthusiasm which I believe will endear the book to students.

Apologies for the long quote but I like the style of the preface. 😉

As you may guess from the date, 1994, the authors focus on functional programming, Miranda, and Modula-2.

Great read and highly recommended.

I first saw this in a tweet by Computer Science.

May 8, 2015

Haskell by Example

Filed under: Functional Programming,Haskell — Patrick Durusau @ 8:43 pm

Haskell by Example

A port of Go by Example to Haskell.

Reading this will be less useful than starting from Go by Example and creating your own port to Haskell. Use this page to check your work.

You could use Go by Example to create ports to other languages as well.

Enjoy!

April 6, 2015

Down the Clojure Rabbit Hole

Filed under: Clojure,Functional Programming — Patrick Durusau @ 7:08 am

Down the Clojure Rabbit Hole by Christophe Grand.

From the description:

Christophe Grand tells Clojure stories full of immutability, data over behavior, relational programming, declarativity, incrementalism, parallelism, collapsing abstractions, harmful local state and more.

A personal journey down the Clojure rabbit hole.

Not an A to B type talk but with that understanding, it is entertaining and useful.

Slides and MP3 are available for download.

Enjoy!

March 9, 2015

Programs and Proofs: Mechanizing Mathematics with Dependent Types

Filed under: Coq,Functional Programming,Proof Theory,Software Engineering,Types — Patrick Durusau @ 3:49 pm

Programs and Proofs: Mechanizing Mathematics with Dependent Types by Ilya Sergey.

From the post:

coq-logo

The picture “Le coq mécanisé” is courtesy of Lilia Anisimova

These lecture notes are the result of the author’s personal experience of learning how to structure formal reasoning using the Coq proof assistant and employ Coq in large-scale research projects. The present manuscript offers a brief and practically-oriented introduction to the basic concepts of mechanized reasoning and interactive theorem proving.

The primary audience of the manuscript are the readers with expertise in software development and programming and knowledge of discrete mathematic disciplines on the level of an undergraduate university program. The high-level goal of the course is, therefore, to demonstrate how much the rigorous mathematical reasoning and development of robust and intellectually manageable programs have in common, and how understanding of common programming language concepts provides a solid background for building mathematical abstractions and proving theorems formally. The low-level goal of this course is to provide an overview of the Coq proof assistant, taken in its both incarnations: as an expressive functional programming language with dependent types and as a proof assistant providing support for mechanized interactive theorem proving.

By aiming these two goals, this manuscript is, thus, intended to provide a demonstration how the concepts familiar from the mainstream programming languages and serving as parts of good programming practices can provide illuminating insights about the nature of reasoning in Coq’s logical foundations and make it possible to reduce the burden of mechanical theorem proving. These insights will eventually give the reader a freedom to focus solely on the essential part of the formal development instead of fighting with the proof assistant in futile attempts to encode the “obvious” mathematical intuition.

One approach to change the current “it works, let’s ship” software development model. Users prefer software that works but in these security conscious times, having software that works and is to some degree secure, is even better.

Looking forward to software with a warranty as a major disruption of the software industry. Major vendors are organized around there being no warranty/liability for software failures. A startup, organized to account for warranty/liability, would be a powerful opponent.

Proof techniques are one way to enable the offering limited warranties for software products.

I first saw this in a tweet by Comp Sci Fact.

« Newer PostsOlder Posts »

Powered by WordPress