News aggregator

The Unlines

del.icio.us/haskell - Tue, 01/28/2014 - 12:33am
Categories: Offsite Blogs

Announcement - HGamer3D release candidate 0.3.0

haskell-cafe - Mon, 01/27/2014 - 11:54pm
Dear All, I'm happy to announce HGamer3D, version 0.3.0 as a release candidate on Github. Please look here: http://www.hgamer3d.org and https://github.com/urs-of-the-backwoods/HGamer3D . The new version features: - Linux ! (in addition to Windows) - HBind tool to generate and administrate bindings Of course I would be largely interested in feedback for the final release of 0.3.0. Best regards Peter Althainz _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

mightybyte: Ember.js is driving me crazy

Planet Haskell - Mon, 01/27/2014 - 11:52pm

For the past few months I've been working on a project with a fairly complex interactive web interface. This required me to venture into the wild and unpredictable jungle of Javascript development. I was totally unprepared for what I would find. Soon after starting the project it became clear that just using JQuery would not be sufficient for my project. I needed a higher level Javascript framework. After a doing a little research I settled on Ember.js.

The Zombie Code Apocalypse

Ember was definitely a big improvement over straight JQuery, and allowed me to get some fairly complex UI behavior working very quickly. But recently I've run into some problems. The other day I had a UI widget defined like this:

App.FooController = Ember.ObjectController.extend({ // ... }); App.FooView = Ember.View.extend({ // ... });

It was used somewhere on the page, but at some point I decided that the widget was no longer needed, so I commented out the widget's markup. I wasn't sure whether we would ultimately keep the widget or not, so I opted to keep the above javascript code for the controller and view around for awhile so it would be easily available if I later decided to re-enable that UI element.

Everything seemed to work fine until a few days later when I noticed that another one of my controls, Bar, was not being populated with data. After spending hours trying to figure out the problem, I finally happened to comment out the unused code for the Foo widget and the problem went away. WTF?!? Why should this have anything to do with the functioning of a completely unrelated widget? This makes absolutely no sense to me, and it completely violates the natural assumption that the controller and view for two completely unrelated controls would have no impact on each other. I would have liked to know the underlying cause, but I didn't want to waste time with it, so I just removed the code and moved on.

Spontaneously Changing Values

Maybe a week later I ran into another problem. Some data was changing when I didn't expect it to. I looked everywhere I could think of that might affect the data, but couldn't find anything. Again, I spent the better part of a day trying to track down the source of this problem. After awhile I was getting desperate, so I started putting print statements all over the place. I discovered that the data was changing in one particular function. I examined it carefully but couldn't find any hint of this data being impacted. Eventually I isolated the problem to the following snippet:

console.log(this.get('foo')); this.set('bar', ...); console.log(this.get('foo'));

The first log line showed foo with a value of 25. The second log line showed foo with a value of 0. This is utter madness! I set one field, and a completely different one gets changed! In what world does this make any shred of sense? This time, even when I actually figured out where the problem was happening I still couldn't figure out how to solve it. At least the first time I could just comment out the offending innocuous lines. Here I narrowed down the exact line that's causing the problem, but still couldn't figure out how to fix it. Finally I got on the #emberjs IRC channel and learned that Ember's set function has special behavior for values in the content field, which foo was a part of. I was able to fix this problem by initializing the bar field to null. WAT?!?

I was in shock. This seemed like one of the most absurd behaviors I've encountered in all my years of programming. Back in the C days you could see some crazy things, but at least you knew that array updates and pointer arithmetic could be dangerous and possibly overwrite other parts of memory. Here there's no hint. No dynamic index that might overflow. Just what we thought was a straightforward getter and setter for a static field in a data type.

Blaming Systems, Not People

Before you start jumping all over me for all the things I did wrong, hear me out. I'm not blaming the Ember developers or trying to disparage Ember. Ember.js is an amazing library and my application wouldn't exist without it or something like it. I'm just a feeble-minded Haskell programmer and not well-versed in the ways of Javascript. I'm sure I was doing things that contributed to the problem. But that's not the point. I've been around long enough to realize that there are probably good justifications for why the above behaviors exist. The Ember developers are clearly way better Javascript programmers than I will ever be. There's got to be a better explanation.

Peter Senge, in his book The Fifth Discipline, talks about the beer distribution game. It's a game that has been played thousands of times with diverse groups of people in management classes all over the world. The vast majority of people who play it perform very poorly. Peter points out that we're too quick to attribute a bad outcome to individual people when it should instead be attributed to the structure of the system in which those people were operating. This situation is no different.

Like the beer distribution game, Javascript is a complex system. The above anecdotes demonstrate how localized well-intentioned decisions by different players resulted in a bad outcome. The root of the problem is the system we were operating in: an impure programming language with weak dynamic typing. In a different system, say the one we get with Haskell, I can conclusively say that I never would have had these problems. Haskell's purity and strong static type system provide a level of safety that is simply unavailable in Javascript (or any other mainstream programming language for that matter).

The Godlike Refactoring

In fact, this same project gave us another anecdote supporting this claim. The project's back end is several thousand lines of Haskell code. I wrote all of the back end code, and since we have a pretty aggressive roadmap with ambitious deadlines the code isn't exactly all that pretty. There are a couple places with some pretty hairy logic. A few weeks ago we needed to do a major refactoring of the back end to support a new feature. I was too busy with other important features, so another member of the team worked on the refactoring. He had not touched a single line of the back end code before that point, but thanks to Haskell's purity and strong static type system he was able to pull off the entire refactoring single-handedly in a just a couple hours. And once he got it compiling, the application worked the first time. We are both convinced that this feat would have been impossible without strong static types.

Conclusion

I think there are a couple of interesting points worth thinking about here. First of all, the API chosen by Ember only hid the complexity, it didn't reduce it. What seemed to be a simple get() method was actually a more complex system with some special cases. The system was more complex than the API indicated. It's useful to think about the true complexity of a problem compared to the complexity of the exposed API.

The second point is that having the ability to make categorical statements about API behavior is very important. We use this kind of reasoning all the time, and the more of it we can do, the fewer the number of assumptions we will have to question when something isn't behaving as we expect. In this case, I made the seemingly reasonable categorical assumption that unused class definitions would have no effect on my program. But for some reason that I still don't understand, it was violated. I also made the categorical assumption that Ember's get() and set() methods worked like they would work in a map. But that assumption didn't hold up either. I encounter assumptions that don't hold up all the time. Every programmer does. But rarely are they so deeply and universally held as these.

So what can we learn from this? In The Fifth Discipline, Senge goes on to talk about the importance of thinking with a systems perspective; about how we need to stop blaming people and focus more on the systems involved. I think it's telling how in my 5 or 6 years of Haskell programming I've never seen a bug as crazy as these two that I encountered after working only a few months on a significant Javascript project. Haskell with it's purity and strong static type system allows me to make significantly more confident categorical statements about what my code can and cannot do. That allows me to more easily build better abstractions that actually reduce complexity for the end user instead of just hiding it away in a less frequented area.

Categories: Offsite Blogs

ajg/yocto · GitHub

del.icio.us/haskell - Mon, 01/27/2014 - 7:46pm
Categories: Offsite Blogs

ajg/yocto · GitHub

del.icio.us/haskell - Mon, 01/27/2014 - 7:46pm
Categories: Offsite Blogs

www.quora.com

del.icio.us/haskell - Mon, 01/27/2014 - 6:55pm
Categories: Offsite Blogs

www.quora.com

del.icio.us/haskell - Mon, 01/27/2014 - 6:55pm
Categories: Offsite Blogs

New version of Glome raytracer

Haskell on Reddit - Mon, 01/27/2014 - 5:07pm

Glome [1] is a raytracer I wrote about six years ago. It's been a long time since the last release; the new version 0.2 is mostly to get it working again with recent versions of GHC.

Glome supports a number of basic primitives including triangles, boxes, cylinders, cones, spheres, and planes and composite primitives including CSG difference and intersection. New types of primitives can be added easily just by defining new instances of the "solid" typeclass. It also uses a BIH-based acceleration structure to efficiently render large scenes.

Glome is split into three packages: GlomeVec [2], a vector library, GlomeTrace [3], a raytracing library, and a front-end viewer program called GlomeView [4]. GlomeView is new, and replaces glome-hs. (The main difference between the two is that GlomeView uses SDL instead of OpenGL.)

Most of the other changes were bug fixes -- there were a handful of bugs that caused CSG objects to render incorrectly.

Another big change is that Glome is now up on github [5], so it should be easier to collaborate if anyone else wants to work on it.

The typical way to use Glome is to edit the file TestScene.hs included with GlomeView, and then re-compile and run the application.

GlomeView does get a decent speedup on multi-core systems. I had hoped that in the time since I'd last worked on Glome that Moore's law (or should we start calling it "Moore's suggestion"?) had caught up to the point where I could render reasonably complex models at interactive framerates, and use Glome as an OpenGL replacement. We're not there yet, though -- I seem to be getting in the neighborhood of 1fps at 720x480 for the kinds of scenes I want to render (thousands of triangles).

[1] http://www.haskell.org/haskellwiki/Glome

[2] http://hackage.haskell.org/package/GlomeVec

[3] http://hackage.haskell.org/package/GlomeTrace

[4] http://hackage.haskell.org/package/GlomeView

[5] https://github.com/jimsnow/glome

submitted by elihu
[link] [4 comments]
Categories: Incoming News

Philip Wadler: Off the Beaten Track: False Starts

Planet Haskell - Mon, 01/27/2014 - 4:01pm

Saturday I had the pleasure to attend Off the Beaten Track, a workshop of POPL 2014.  Every single talk was introduced with the phrase 'And now for something completely different ...'

One talk, by Nada Amin and Tiark Rompf (delivered by Nada), argues that 'papers should expose the sausage-factory of designing calculi, and the minefields in the landscape'.

Ever since Euler (at least), papers in mathematics tend to present a polished solution at the cost of hiding the insights that led to the solution's discovery. Only rarely does one see papers that describe an approach that failed, even though, arguably, knowing what not to do can be as important as knowing what to do.

This leads me to make a suggestion. Every paper is expected to contain sections, where relevant, on
design, implementation, performance, theory, and related work. We should also include, where relevant, a section on 'false starts': research directions that failed to pan out. That is, 'false starts' should be on the checklist of what to cover when first organising a paper. Papers with such material exist, but they are rare; we should make them a common case.

What are your favourite papers that clearly explain a false start?


Categories: Offsite Blogs

Philip Wadler: Take a lawyer’s advice – visit the occupied territories

Planet Haskell - Mon, 01/27/2014 - 2:34pm
Even committed Zionists are beginning to understand that Israel is consistently violating fundamental human rights in Palestine. This article, by a lawyer, focusses on how Palestinian children fare. Spotted via JFJFP.
By David Middleburgh, Jewish Chronicle
January 17, 2014
I have just returned from a three-day tour of the West Bank and east Jerusalem, organised by the pro-Israel, pro-peace organisation, Yachad. The participants were all passionate Zionists and, were it not for some grey hairs and wrinkles, we could have been a youth group. In fact, we were all senior lawyers or individuals with a particular interest in the rule of law.The purpose: to understand the legal context to the occupation. The centrepiece, a unique visit to the IDF military courts that maintain law and order (for Palestinians only) in the West Bank, unique in that we were the first organised group of British Jews to visit the courts. In the course of the tour we met a very broad spectrum of people from representatives of Israeli NGOs, a senior employee of the Yesha Council, which represents settlers, and a senior adviser to Foreign Minister Avigdor Lieberman.
Arrest of childMy conclusions? First, there is no substitute for finding out what is really happening on the ground by visiting and asking difficult questions. I had made numerous assumptions from both Jewish and non-Jewish media, which were simply wrong.Secondly, those who consider that stories of systemic breaches of human rights under the occupation are an anti-Israel myth are deluding themselves.We spent a morning at the military courts observing young Palestinian boys, aged 13-17, being processed, and speaking to their mothers. It is clear that children are invariably arrested in night raids by the army at gunpoint, cuffed and blindfolded and held, often for hours, in that condition, denied access to food, water and toilet facilities, interrogated without being advised of their rights, without a lawyer and without their parents.
Boy arrested by IDF, Nabi Saleh, 2011Military Court Watch, an Israeli NGO, has carried out a detailed forensic review and they found over 50 per cent of children were arrested in night raids and 83 per cent of children blindfolded. All of the children we saw in court were in leg shackles.There was a shocking passivity of the Palestinians we observed at court. Parents and detained children smiled and joked with each other and we did not see a single case of anger. That’s not to say parents did not care that their children were being imprisoned.
Israeli occupation forces detain a Palestinian youth in the West Bank city of Hebron on 22 September 2013, during protests against road closures for the benefit of Jewish settlers. Photo by Mamoun Wazwaz / APA imagesBut conviction rates are 99.7 per cent. The passivity bespeaks a people who have become resigned to their reality. They recognise there is no longer any point in fighting for basic rights. I felt that the court system was clearly a figleaf for a system of arbitrary justice where the guilt of the child is beside the point. The courts are part of a system that effectively keeps Palestinian society in a state of constant fear and uncertainty.So why do the authorities bother with the expense of maintaining the pretence of justice? The answer is that without scrutiny it is possible to pretend that the system is fair. So, defendants are legally represented and proper rules of evidence apply.
Boy arrested on suspicion of throwing stones, Silwan, December 26, 2010. No further information
Arrest of boy, Silwan, 2011. No further information.
A much reproduced photo, for obvious reasons of a police swoop on young boys in Jerusalem, 2010. No further information.Scrape away the veneer, and the charade is exposed with convictions routinely obtained based upon forced confessions and defendants facing remand without bail pending trial for periods in excess of sentences when pleading guilty. No sane defendant would plead not guilty in this Catch 22 situation.I would argue that diaspora Jews who are true friends of Israel have a duty to visit the territories to understand the problem, and then to lobby friends in Israel to strive for a just end to this situation.If we do nothing, can we complain if we awake one day and Israel has sleepwalked into the status of a pariah country?David Middleburgh is a partner in the London firm of Gallant Maxwell solicitors
Categories: Offsite Blogs

New Functional Programming Job Opportunities

haskell-cafe - Mon, 01/27/2014 - 9:00am
Here are some functional programming job opportunities that were posted recently: Haskell Developer at Zalora http://functionaljobs.com/jobs/8678-haskell-developer-at-zalora Cheers, Sean Murphy FunctionalJobs.com
Categories: Offsite Discussion

[ANN]: arb-fft 0.1, Fast Fourier transform library

haskell-cafe - Mon, 01/27/2014 - 8:31am
Dear Cafe, I'm happy to announce the first release of arb-fft, a pure Haskell FFT implementation for arbitrary length vectors: http://hackage.haskell.org/package/arb-fft This is probably more of pedagogical interest than anything else, since there's a long series of blog articles describing the development of the package, indexed at http://skybluetrades.net/haskell-fft-index.html The package has some interesting features beyond the usual "textbook" powers-of-two FFT algorithm. In particular, it uses a mixed-radix decomposition of composite input lengths, uses Rader's algorithm for large prime factors and has an empirical benchmarking scheme using Criterion for FFT plan selection. The performance of arb-fft is within a factor of 10 of FFTW for most input sizes, which isn't too bad for a pure Haskell with only a relatively limited amount of work done on optimisation. Commentary is very welcome, as are offers to help with any of the tasks listed in the last blog article: http://skybluetrades.net/blog/post
Categories: Offsite Discussion