ac

+2, and even the highest difficulty singleplayer is nothing compared to multiplayer. Beware, though, it has an extremely steep learning curve.

As Tyr42 has so astutely observed, I have meant that pattern matches in function declarations, let-bindings and list comprehensions are desugared into the case expression. Also, it would be kind of pointless to compare C switch and Haskell case. Especially, in your example Haskell, probably, 'wins' because primarilt because a more powerful type system and algebraic data-types (and absence of pointers, hehe). That said, it's not like you can't emulate the pattern matching (with placing nested values/subtrees in scope): https://gist.github.com/2832755 (it's in JavaScript, because I felt like it -- but I'm pretty sure you can devise something similar in C). Of course, it's plain ugly and doesn't carry any nice static guarantees that the Haskell type-system will give you (like warning about incomplete patterns)... but, hey, it works. Anyway, the point of my comment was that pattern-matching is hardly a feature characterizing and exclusive to Haskell (ML/OCaml/F#, Coq, Scheme have it, probably other functional languages too). Although, it's still the one I enjoy every day :)

> like exceptions (quite un-Haskell-like)

Haskell has exceptions [1].

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

I think it's quite misleading to list Haskell in the title: the only common thing between Loop and Haskell that I've found is pattern matching, and that's not even exclusive to Haskell -- other languages have it. Besides, it's not clear from the intro that Loop's pattern matching is as powerful as Haskell's (especially with all the extensions). Finally, pattern matching is really a syntactic sugar over the case/switch construct present in many, many languages. Although, I liked the type-patterns.

I mentioned earlier that I found the GHCI use-case extremely useful (see my root comment after EDIT). But I have an issue with the uses like turning off the typesystem and have the project compile just so that you could feel good about yourself. I don't believe that would help your bottom-line. But, as long as I don't have to work with you or your software, I don't care. And, large refactoring efforts are necessary in every complex and evolving system, irrespective of your language of choice -- but turning off your type checker or any other static guarantees isn't the way to go. Programming is hard enough even in the presence of type-checking and automated analyses -- why make it even harder? Anyway, I feel like I've made my point enough -- take it or leave it.

I wasn't talking about the bleeding edge GHC -- merely the stable releases available to download from the official web-page with both sources and binaries. If that's "bleeding edge", it should clearly be specified as such. Anyway, I don't even use HP -- which leaves cabal-install as the only viable option. And why do I even not want to use the GHC version which is not in HP? Well, surprise-surprise, it turns out that Hackage is more than content to use the "bleeding edge" compiler to build packages and will happily report all the compilation errors (instead of using the usable baseline version included in HP). Well, it's a sore topic to say the least. Anyway, sorry for the offtop, I think we should get back to discussing why would GHC want to become a Python interpreter.

Yes, things like changes to core library types are disastrous. But, if you have a core data-type that you know will change and you haven't isolated the impact of these changes by, say, using accessor functions, you're the one to blame. See my long-ish reply in the sibling thread for details. And, yeah, I've learned all this the hard way :(

GHC is a bit of a pathological case, which doesn't make it less valid. I wouldn't really dare to estimate how much refactoring you need to do if you change, say, one constructor of GenStgExpr, primarily, because I don't know the GHC codebase. In my work I have had instances when I had to change datatypes drastically and refactor the code accordingly. I'd say, in all cases the type system was helpful -- I just go to every error location (very easy with, e.g., ghc-mod), and it's invariably a pattern-matching case, so I fix a bit of code here and there (20 LoCs at most) and it all worked. But the thing is, of course, if you change your datatypes all the time even these kind of small changes will soon become tedious. But then if one programs in Haskell in a hacking mode ("meh, let's try throwing this thing in, maybe it will miraculously start working") -- it just won't work. Haskell requires one to think well, before programming -- that's why I love it. I think, in the end it saves time. Another problem might be that the datatype you are refactoring is fundamental to your program and is used in most modules -- I think it's just short-sighted design. GHC, for example, has several different program representations (Haskell, STG, Core, maybe some others), so a change to one representation would only affect a part of the compilation pipeline (namely, the translation to and from that rep and the associated optimisations/analyses). But if you really need such a fundamental mega-type that will change during the lifetime of the program, why not write an easier to manage interface to it? Either use the record syntax or write setter/getter functions by hand. Just $ my $0.02 where my=id

> Now you can update and test in batches without having to refactor 1000s of lines in one go.

If a change in a datatype forces you to update 1000s of LoCs, you are doing something wrong.

I don't buy it. Why have erroneous code that is not used anyway in your program? Why not comment it out? If you still need to have that code, there's an easier way to typecheck -- use 'error'. (I don't assume dons doesn't know that, though). There are so many good features one can add to haskell and the surrounding eco-system, but turning off the static type system is not one of them.

EDIT: Okay, I can see the point. The linked ticket http://hackage.haskell.org/trac/ghc/ticket/5624 gives a better motivation: being able to load a module that doesn't type check in GHCI and view inferred types, and, maybe, invoke some isolated functions. But why not just limit it to GHCI, though?

And, FFS, would SPJ and Co. please stop breaking core libraries and tools with minor releases? We had to wait for cabal-install to be ported for 7.2 and 7.4 for a couple of months, at least. Why have the bloody Haskell-Platform if you can't keep up with the compiler releases.

Never understood the Lisp-mania: how could you like a language where you won't get a type error until after you run the program?

A smarter way might be just implementing a new LLVM backend (gives us C via Clang, some other languages). However, even with C, the standard library probably won't leave much space for the user code itself -- so you might need something slimmer. Also, some kind of simple RTOS (www.freertos.org, maybe?) to run all these programs (I assume people would really want to run several programs at a time). I wonder if the 128k limitation was intentional, to make programming the computers more interesting. Anyway, I'm actually looking forward to seeing what kind of clever solutions the players come up with.

Type inference for higher-order dependent types is undecidable[1]. Going higher up the ladder of "polymorphism orders" one would eventually have to sacrifice Haskell's type inference -- which, I'm sure, few want to: otherwise, a lot more people would have programmed in Coq already.

[1] J. B. Wells. "Typability and type checking in the second-order lambda-calculus are equivalent and undecidable." In Proceedings of the 9th Annual IEEE Symposium on Logic in Computer Science (LICS), pages 176–185, 1994. (Shamelessly copied from Wikipedia)

I've been looking to switch from PowerPoint (OO Impress in fact) and LaTeX beamer to something else for some time, because none of them did everything I needed:

* I like LaTeX/beamer for the declarative style. If I need a two-column layout on my slide, I just type it in and it works. If I need to reveal parts of the slide step-by-step, I just type in \pause and it works. Also, I rarely need to adjust the font sizes etc.: the defaults are just sensible, if not outright beautiful. And, also, custom themes and goodies like the progress indicators are great (see the Singapore theme).

* I like Impress for the fact that I have a fine grained control over a layout, should I need a something that goes beyond a columns/rows layout. Also, I can import and resize graphics without pain (in LaTeX it takes time). Also, I have more choice of animations, but adding them is very time consuming. Finally, I don't need to rebuild the slides after the tiniest change as with LaTeX.

The HTML/SVG/CSS/JS seemed to have a potential to offer the best of both worlds, but the scaling problem (as described above) was throwing me back. In the process I've written down a list of features for my dream presentation tool:

* beautiful typography

* flexible layout: I should be able to specify the layout declaratively (e.g. two columns and a header, or a header, block of text and a table) with the tool figuring out the rest (font sizes, margins, etc) or fine-tune it manually where I can specify the font sizes and positions of every element

* themes and widgets (progress indicators, timers, slide numbers etc)

* should be easy to embed pictures and diagrams with scriptable animations (SVG+JS seems to be ideal for it, and I've used Inkscape for a while). The animations should be: rotation, translation, resizing, showing/hiding, change of color and zooming (the latter one being the only thing that I'm missing in both LaTeX and PowerPoint/Impress).

* being able to edit the presentation on the fly. I don't want to rebuild the slides every time I fix a typo.

That's good and I'll definitely try Chrome. But, wouldn't it be great if the library/framework just took care of that? In fact, one of the frameworks -- Shining -- referred from the other post has a JavaScript plug-in that seems to do the resizing for different resolutions (although it's implemented in the ugliest way possible, IMO).

> It looks beutiful and all. But does people actually do presentations like this for hand? (css and html).

Yep, I've used LaTeX/beamer for quite some time. It's great for some things (not only math, but really any advanced text formatting and layout and some simple animations) and awful for others (graphics, mostly). PowerPoint, on the other hand, allows you more fine-grained control over layout, and is more graphics/diagram-friendly -- but having to do everything with a mouse is kind of daunting. I'd rather type everything in, let the system lay it out for me and then correct what doesn't look good.

There's only one problem that's holding me back from switching to HTML/SVG/CSS/JS for my slides: the problem of monitor/projector resolution scale. Most projectors I've presented on had a low resolution: 640x480 or 800x600. Let's say my monitor has a 1600x900 resolution, so if I develop in that resolution, my presentation would break (or at least it wouldn't look as I expect it to). Presentation software and PDF viewers take care of that for me: what you see on the screen is what you would get on the projector (i.e. the text and graphics would have the same relative height&width as on the screen). Is there any reliable way to achieve that in HTML presentations as well?

No they didn't. And proving correctness of software isn't the same as solving the halting problem. You're confusing formal verification and static analysis (that doesn't mean that the latter doesn't work). Please, google Curry-Howard Isomorphism and Rice's Theorem, will ya?

I recommend Simon-Peyton Jones' classic "How to give a good research talk" http://research.microsoft.com/en-us/um/people/simonpj/papers...

And also some loose bits of advice from me:

* 10 minutes is not enough to present "all the material in your paper". 30 minutes is not enough either. So, don't even try. Even if you talk fast enough, the audience won't get it. I'd expect 10 minutes be enough for a high-level overview of the paper, but if you can include just one bit of technical information which you think is the most valuable bit, that would be brilliant.

* reading from slides is an atrocity, so don't.

* and having too much text on the slides isn't cool either (the same applies to bullet lists, unless you absolutely have to). If you do, expect many people not to listen to you while they are reading the slides. So, only include large bodies of text if it's some code. And even then, format it nicely (color helps, but don't rely on it to convey useful information).

* "pictures are worth a thousand words"... unless they are badly drawn. But a good picture is a great alternative to large bodies of text.

* practice your talk, especially if you haven't given many of them. That makes huge difference in how well you perform. And remember, a technical talk is still a performance.

* if you are worried that your mind would go blank once you take the stage, hard-script the beginning of your presentation and read from the paper. Eventually, you will warm up and won't need it anymore, but it's great to quickly overcome stage fright and the like (helped me a great deal).

I think that's very good that people still control the military drones. You don't want the drone dropping a bomb where it is not supposed to just because there was some suspicious movement there. No matter how well you can program the robot and how much elaborate heuristics you can give it, at this point it seems to me that humans are infinitely more flexible in making decisions. I wouldn't allow computers make life-and-death decisions any time soon.

Aquinas Router, anyone?...

The basic premise of the article is that a web application firewall can detect and deter all the attacks an internal mechanism can. Well, good luck with such an attitude!