Hacker News Reader

l_dopaon How to Implement a Programming Language in JavaScript

Here's one way to write down the K lines example:

  let top_k chan k =
    let incr_count m l = 
      let n = try Map.find_exn m l with Not_found -> 0 in
      Map.add m ~key:l ~data:(n + 1)
    in
    In_channel.input_lines chan
    |> List.fold ~init:String.Map.empty ~f:incr_count
    |> Map.to_alist
    |> List.sort ~cmp:(fun (_,a) (_,b) -> compare b a)
    |> List.sub ~pos:0 ~len:k

You could probably code-golph it down to a couple of lines but I find the 'pipe' operator leads to very readable code.

l_dopaon How to Implement a Programming Language in JavaScript

Your comparison isn't really fair. With similar functions from Core's In_channel you can write something like:

  let sum_file filename =
    with_file filename 
      (fold_lines ~init:0 ~f:(fun a l -> a + int_of_string l))

"Using the right tool for the job" when it comes to functional vs. "mainstream" languages is a popular meme, but it doesn't hold up to scrutiny. You can always write your own higher-level code for a given domain with a reasonably expressive language. Adding a useful type system, ADTs, etc. to a language like Python is much, much harder (though that's exactly what Microsoft and Google are trying with Javascript).

l_dopaon Who Says C is Simple? (2010)

The example is written in a strange way. You're supposed to assume x is initialized ("for most values of x").

I think it's just pointing out the difference between '&' and '&&'.

l_dopaon Why are objects so hard to debug?

Objects are far from the only way to limit access to state. Modules, lexical scope and closures, even C's static storage class all predate the current crop of OO languages.

l_dopaon Object Oriented Programming is Inherently Harmful

You would pass in a function or datatype containing a function, which is exactly what the OO code does. No language features beyond first class functions necessary.

l_dopaon Parsing: The Solved Problem That Isn't (2011)

This approach might be why several ubiquitous languages have needlessly ambiguous grammars. Decades of writing tools to be bug-compatible with the original implementation is much harder than learning a tiny bit of theory.

l_dopaon Vellvm: Verifying the LLVM

It's a semantics for the intermediate representation used by most of the LLVM optimization passes defined in a theorem prover.

With it you can, for example, write your own LLVM pass in Coq's specification language and prove that it can't introduce bugs by changing the meaning of a program.

See also Compcert[1] and CakeML[2] for some other recent work in this area.

[1] http://compcert.inria.fr/ [2] https://cakeml.org/

l_dopaon Pissed off about functional programming (2005)

I think this is somewhat misleading. It's easy to give a semantics for a toy C-like imperative language. As far as I know, a semantics that is mostly faithful to the C standard becomes extremely complicated and requires modeling e.g. code layout in memory. The equational reasoning you get from that kind of semantics is terribly weak: essentially, only terms that have the same byte-for-byte effect on memory are really equivalent. So I wouldn't say that exploiting "referential transparency" in Haskell is somehow more obvious, but that it's useful at all.

l_dopaon Compiling with Continuations, Continued (2007) [pdf]

Sure, and Weeks is totally correct regarding tree vs. flat representations, but I think identifying CPS with the former and SSA with the latter is misleading. The scoping discipline (respectively, dominator tree) is part of the language whether you represent it as subtrees or leave it implicit.

It would be more accurate to say that SSA is a particularly efficient data structure for representing a subset of CPS terms.

l_dopaon Compiling with Continuations, Continued (2007) [pdf]

This is an area where the compiler and programming language communities often seem to be talking past each other. In the post you linked, Weeks is talking about CPS and SSA as the datastructures manipulated by optimization algorithms. CPS is interesting primarily as a language in the formal sense of assigning semantics to programs. Whether you choose to represent those programs naively as a tree structure or with an efficient graph representation as in SSA, you're still using CPS.

This paper is really good because, unlike a lot of compiler literature, it treats both semantics and term representation.

l_dopaon Summer of Programming Languages

Yes, this is what compelled me to comment in the first place: based on what I've read of his blog, that comparison (and his reputation in general) seems completely unjustified. There's a world of difference between this kind of spirited but productive debate and content-free holy wars between roughly identical languages that get the spotlight in the "mainstream" tech blog circuit.

In fact, his post on exceptions in Haskell and his criticism of monadic IO led me to work on some alternatives (algebraic effects) which, oddly enough, helped me understand Haskell's approach at a deeper level. I wouldn't have known about the issue if it was only on the bug tracker.

l_dopaon Summer of Programming Languages

That makes sense. If you view Haskell as a research platform, pointing out ugly corners of the type system is entirely appropriate and even helpful for people working on GHC. From the outside, for those of us that would like to see these ideas gain greater adoption, it can be frustrating or even seem petty to focus on them.

l_dopaon Summer of Programming Languages

> A lot of Harper's comments ( and many PL theorists ) seem to completely casually gloss over the gritty compiler engineering as if it's just beneath them, and that guys like SPJ and Simon Marlow are just wasting their time working on faster runtime systems and optimizations when he thinks they should be working on foundational "Holy Trinity" problems.

That's a tempting view to take regarding theory vs. practice but I don't think it holds up when you consider Harper's whole body of work and the substance of his criticisms of Haskell: He has published extensively on ML implementation and, as far as I know, has offered criticism of (GHC) Haskell's type system where it is unsound, never the (really cool) work being done on the RTS.

l_dopaon Objects, Identity, and Concept-formation (2008)

Well, you described parametric polymorphism (a generic Nth function) and then switched to talking about dispatching on tags at runtime. You are mistaken; those really are completely unrelated concepts.

l_dopaon Objects, Identity, and Concept-formation (2008)

You just described parametric polymorphism, which has nothing to do with objects or runtime type information.

l_dopaon White House Petition to End Software Patents Is a Hit

I was under the impression that algorithms are specifically not patentable

http://en.wikipedia.org/wiki/Patentable_subject_matter#The_a...

l_dopaon Guile 2.0.2: Building the Guildhall

If there was an actively-developed common lisp implementation that also ran elisp, I would be all for running emacs on that as well.

Emacs' sheer size (which you mentioned yourself) means you're not going to port it to a different language and have something comparably useful in less than a few years, assuming sustained interest and full-time development.

l_dopaon Guile 2.0.2: Building the Guildhall

By the time we have native compilation, I hope also our Elisp implementation will be significantly faster than the one in Emacs, so it will really become attractive to people to finish the work that we have done to make the switch there.

For an emacs user, that's pretty exciting.

l_dopaon [dead]

In the spirit of this brilliant experiment with direct democracy, Cantor should elect to crowdsource his next colonoscopy. We need the steady hand of the people on that endoscope, not some elitist Harvard doctor wasting taxpayer money! A weighted average of tweets containing a direction and velocity to #cantorsrectum would do just fine.

l_dopaon Our Banana Republic

Cute. If you look at the actual numbers, income distribution in the US looks a lot more like China than the EU, for example: http://en.wikipedia.org/wiki/List_of_countries_by_income_equ...

That's clearly not the whole picture, but it's a bit more interesting than automatically associating income equality with communism.

l_dopaon "Calling oneself a C Programmer is like saying you're a Hammer Carpenter"

This is an even worse analogy for so many reasons, not sure why it hasn't been voted down into oblivion. Must be all those people using that great new OS written in PHP.