Functional Geometry and the Traite ́ de Lutherie by Harry Mairson, Brandeis University.
We describe a functional programming approach to the design of outlines of eighteenth-century string instruments. The approach is based on the research described in Francois Denis’s book, Traite ́ de lutherie. The programming vernacular for Denis’s instructions, which we call functional geometry, is meant to reiterate the historically justified language and techniques of this musical instrument design. The programming metaphor is entirely Euclidean, involving straightedge and compass constructions, with few (if any) numbers, and no Cartesian equations or grid. As such, it is also an interesting approach to teaching programming and mathematics without numerical calculation or equational reasoning.
The advantage of this language-based, functional approach to lutherie is founded in the abstract characterization of common patterns in instrument design. These patterns include not only the abstraction of common straightedge and compass constructions, but of higher-order conceptualization of the instrument design process. We also discuss the role of arithmetic, geometric, harmonic, and subharmonic proportions, and the use of their rational approximants.
Quark Games was established in 2008 with the mission to create hardcore games for the mobile and tablet platforms. By focusing on making high quality, innovative, and engaging games, we aim to redefine mobile and tablet gaming as it exists today.
We seek to gather a group of individuals who are ambitious but humble professionals who are relentless in their pursuit of learning and sharing knowledge. We're looking for people who share our passion for games, aren’t afraid to try new and different things, and inspire and push each other to personal and professional success.
As a Server Game Developer, you’ll be responsible for implementing server related game features. You’ll be working closely with the server team to create scalable infrastructure as well as the client team for feature integration. You’ll have to break out of your toolset to push boundaries on technology to deliver the most robust back end to our users.
What you’ll do every day
- Develop and maintain features and systems necessary for the game
- Collaborate with team members to create and manage scalable architecture
- Work closely with Client developers
on feature integration
- Solve real time problems at a large
- Evaluate new technologies and products
What you can bring to the role
- Ability to get stuff done
- Desire to learn new technologies and design patterns
- Care about creating readable, reusable, well documented, and clean code
- Passion for designing and building systems to scale
- Excitement for building and playing games
Bonus points for
- Experience with a functional language (Erlang, Elixir, Haskell, Scala, Julia, Rust, etc..)
- Experience with a concurrent language (Erlang, Elixir, Clojure, Go, Scala, etc..)
- Being a polyglot programmer and having experience with a wide range of languages (Ruby, C#, and Objective-C)
- Experience with database integration and management for NoSQL systems (Riak, Couchbase, Redis, etc...)
- Experience with server operations, deployment, and with tools such as Chef or Puppet
- Experience with system administration
Get information on how to apply for this position.
This is just a quick follow-up to my previous post. We have now released Haddock 2.14.2 which contains few minor changes. The reason for this release is to get a few quick patches in. No fancy overview today, just quick mentions. Here is the relevant part of the changelog:
Changes in version 2.14.2
Always drop –split-objs GHC flag for performance reasons (#292)
Print kind signatures GADTs (#85)
Drop single leading whitespace when reasonable from @-style blocks (#201)
Fix crashes associated with exporting data family record selectors (#294)
#201 was the the annoying aesthetics bug I mentioned last time and that is now fixed.
#294 was a bug we’re glad to have gotten rid of now: it was only reported recently but I imagine more and more projects would have start to hit it.
#292 should improve performance considerably in some special cases, such as when Template Haskell is being used.
#85 was just a quick resolution of years old ticket, I think you’ll find it useful.
I predict that this is the version that will ship with GHC 7.8.1 and I don’t think we’ll have any more 2.14.x releases.
Ideally I’d like to get well under 100 open tickets for the next release (there are currently 117 open).
Some things I will be concentrating on next is splitting up Haddock into a few packages and working on the Hoogle back-end. The Hoogle back-end is incredibly broken which is a shame considering Hoogle is a very useful service. We want to make the maintainers life easier.
Splitting up Haddock into a few packages will be of great advantage to people wishing to use (parts of) Haddock as a library without adding a dependency on a specific version of GHC to their program. It should also become much easier to implement and maintain your own back-ends.
If you are interested in helping out with Haddock, we’d love to have you. Pop into #haddock on Freenode, make some noise and wait for someone to respond. Alternatively, contact me through other means.
PS: While I realise that some of my posts make it on reddit, I myself do not use it. You’re welcome to discuss these but if you leave questions or messages to me on reddit, I will almost certainly not see them. If you want my attention, please either use e-mail or IRC. Thanks!
Does anyone have a motivating example of why you would ever want or need object-oriented style classes in Haskell (such as OHaskell)? I haven't found the desire to use OO in Haskell.
I'm curious why the OCaml implementation of Caml is so popular (among Caml implementations) and yet the OO based Haskell efforts have died.submitted by milksteaksonthehouse
[link] [33 comments]