Live data from Hacker News

A Haskell Programmer Tries to Learn Racket

artyom.me

111–120 of 163 posts

Re: A Haskell Programmer Tries to Learn Racket

#111

Earlier quoted context omitted.

As a lisper, I can say that this insight is very true, but it is still just a simplification. Most lisps deal with it in different ways. In the scheme world, the way they deal with this is by wasting a decade on making decisions about the language that should have been done in the 80s. The result is that scheme essentially split into scheme and racket. Now we have an awesome language and a nice little ecosystem thats…

To me, "almost completely compatible" sounds similar to "just a tiny bit pregnant". In practice, either it is compatible, or it isn't.

Not necessarily.

Java 6 and 7 are "almost completely compatible".

Most programs written in Java 6 will run in Java 7, and vice versa. But not all.

Re: A Haskell Programmer Tries to Learn Racket

#112
post #105

I love Scheme. And I love Clojure, which is IMHO Scheme plus some great ideas from Haskell. I regret there's no Scheme or Clojure running on LLVM, which I think is a much better platform than the JVM. Julia, that resembles Dylan (another Lisp), is the perfect example.

I too wish there was such a thing as a JIT compiled Clojure on LLVM. The JVM is amazing but it only seems to be amazing for long running processes. LLVM, IMO, is far more versatile in its amazingness.

There was an attempt at it, https://github.com/halgari/clojure-metal

Re: A Haskell Programmer Tries to Learn Racket

#113
post #105

I love Scheme. And I love Clojure, which is IMHO Scheme plus some great ideas from Haskell. I regret there's no Scheme or Clojure running on LLVM, which I think is a much better platform than the JVM. Julia, that resembles Dylan (another Lisp), is the perfect example.

Not sure what Lisp family it compares to, but there is Hylas:

https://github.com/eudoxia0/Hylas-Lisp

Re: A Haskell Programmer Tries to Learn Racket

#114
post #101

Earlier quoted context omitted.

Yeah, nobody is ever going to agree about language statics. From each person's POV: "you either get it or you don't". But totally agree about the pragmatism of Lisp. It's clever self-interpreter is clever but not terrifically interesting as a proof of simplicity of language but instead a proof of simplicity of self-implementation.

It's not that I don't think that staticly typed code isn't advantageous. It's that it seems to often impede finding better abstractions by locking our thinking around local minima. 'a . 'b -> 'b Is a great place for a procedure to end up in production code. Yet, it's not necessarily a great place for me to start because I'm lazy and might try to force 'c . 'd -> 'd into working kludgetasticly simply because like most…

I think that personally that's the place that genericity and inference live. I never write types as concrete as

   'a . 'b -> 'b
but instead write code and let the inferencer tell me how general it might be then use that information to peel apart layers which don't need to be conflated.

This isn't tied to this example, of course. I think generally static types get misused the thought is that they don't let you experiment with code. I think that they don't let you experiment with code in the same way that dynamic types do, but I don't think they're at all impeded for that. It just takes investment into a different kind of experimentation.

Re: A Haskell Programmer Tries to Learn Racket

#115

Earlier quoted context omitted.

Straight from the horse's mouth: "Node is popular because it allows normal people to do high concurrency servers. It's not the fastest or leanest or even very well put together - but it makes good trade offs in terms of cognitive overhead, simplicity of implementation, and performance. I have a lot of problems with Node myself - but the single event loop per process is not one of them. I think that is a good programm…

Such a wonderfully confusing and self-contradictory quote. I love it.

Why do you think it's self-contradictory? I found it fairly stable.

I think the most important line for me is about wanting computers to be like lego blocks. I think that's an admirable goal and I think that if Node as a community of programmers and projects owned that more ("We're Mindstorms, not NASA, here!") it'd get a great deal of love from the rest of the community.

Sadly, that probably won't happen since Mindstorms sounds diminutive and no collection of people has an ego so in check.

Re: A Haskell Programmer Tries to Learn Racket

#116

Earlier quoted context omitted.

My question is, given the cons pair is not a meaningful primitive datatype to modern CPUs (can't fit in a register unless you're using 32 bit atoms on a 64 bit CPU, the individual cells cannot be meaningfully manipulated while packed into a single register even in that case...), is there a good reason to use an unrestricted pair/2-tuple/2 element vector for the sexp representation? Would it be "wrong" to remove dotte…

Going a little Abelson&Sussman, the utility of cons persists because it is a powerful abstraction. Fitting into registers was, as a scholastic might say, an as accidental feature as the input line voltage of a toaster [110 @ 60Hz makes things easier in this part of the world but isn't intrinsic to making crisp English muffins]. cons is useful for dealing with linked memory structures, including singlely linked lists…

> There ain't no synonyms for "caddr" and "cdddr" in English or Python.

In Python:

    x[1][1][0] # caddr
    x[1][1][1] # cdddr

Re: A Haskell Programmer Tries to Learn Racket

#117
post #100

Earlier quoted context omitted.

I dream of a modular language in which languages, or dialects , can be built from a small base language, which can then be extended, and so on. Of the languages that I've seen, Racket looks the most promising. Forth might be good for this, too, but to build large hierarchies of languages seems the antithesis of Forth - or at least, Chuck Moore's - philosophy. On the other hand, such a language might just end up as an…

It's ironic that Haskell is such a language: it grows from a tight, small core into larger and greater abilities as you learn it even without using its extensions. I agree that Common Lisp a very powerful language, but I can't live with all that power uncontrollably thrown on me. Common Lisp grossly lacks self-discipline and self-limitation when it's needed.

I suspect the parent thread was dreaming of a framework where languages with arbitrary syntax can be mixed and matched in user-defined ways.

Haskell isn't necessarily that language, partly because it still requires centralized coordination of development of these "extensions" to ensure they're interoperable - that is, there is only one parser for the language and its supported extensions, and many of them are build into the compiler rather than added as libraries, except those extensions which are done through quasi-quotation, such as with MetaHaskell, or some EDSL. Even that has it's own problems, and you'll have issues parsing if your quoted language happens to have delimiters which conflict with Haskell's quasiquoting delimiters `[| |]` - producing syntax which cannot be parsed unambiguously (perhaps very rare or unlikely though).

Perhaps the biggest hurdle of having a modular language is that we do not understand how unambiguously parse the combination of two or more syntaxes. We only know that composition of two CFGs results in another CFG, but with no guarantee of unambiguity, and other parsers such as PEG rely on ordered choice, where the computer can't decide which choice you really want.

What makes lisps great for composition of languages (or "EDSLs" in market speak), is that it bypasses the parsing problem by asking you to just write your language directly in terms of the syntax tree which a parser would generate - and perhaps use macros or other functions to simplify the use of that tree. Instead of a language being vocabulary+syntax, we create new vocabulary for what would be done through syntax in other languages - and we can thus refer to it unambiguously. Similar can be done in haskell too, through regular functions and quotation.

The parse problem is only really a problem because we're stuck with this silly model of "sequential text files" to describe code, and we're required to limit our languages such that a parser can take one of these text files and make sense of it. When we break out of this model, and use intelligent editors, we can reach the point where syntaxes can be composed arbitrarily, because we can indicate where each new syntax begins and ends. Diekmann and Tratt have demonstrated how this can be done while still appearing much like traditional text editing, which they call Language Boxes.[1][2]

Language Boxes only provide the means to compose syntaxes, but handling the semantic composition of languages is left to the authors of the languages which are being composed. Haskell is perhaps a good choice of language for providing the kind of glue needed here, where we can decide where languages can be composed based on the types returned by their parsers.

[1]:https://www.youtube.com/watch?v=LMzrTb22Ot8, [2]:http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_compos...

Re: A Haskell Programmer Tries to Learn Racket

#118
post #87

Earlier quoted context omitted.

As a lisper, I can say that this insight is very true, but it is still just a simplification. Most lisps deal with it in different ways. In the scheme world, the way they deal with this is by wasting a decade on making decisions about the language that should have been done in the 80s. The result is that scheme essentially split into scheme and racket. Now we have an awesome language and a nice little ecosystem thats…

At this point we can safely say that any programming language will be with us for many decades. Cobol ( http://en.wikipedia.org/wiki/Cobol#COBOL_20XX ), Fortran ( http://en.wikipedia.org/wiki/Fortran#Fortran_2015 ), Basic ( http://en.wikipedia.org/wiki/Visual_Basic_.NET#2013_.28VB_12... ) are still evolving. Heck, Python is already 23 years old and I don't see it going anywhere. I'm not even going to talk about the u…

I think you're just conveniently forgetting all the languages that didn't go anywhere. https://en.wikipedia.org/wiki/Timeline_of_programming_langua...

Re: A Haskell Programmer Tries to Learn Racket

#119
post #3

"...but nothing beyond that. As long as Node.js exists in this world, I can't truly hate anything else." I found this hilarious. I am also rather underwhelmed (to be nice) with Nodejs and a little bothered at its wide adoption. I have also been learning racket recently; my formal language and functional programming class uses it. I had some previous experience with common lisp but the raw nature of scheme still pleas…

I also hate NodeJS for its package manager, NPM. I don't understand the way it manages dependencies and their folder. What the hell is 'node_modules/express/node_modules/connect/node_modules/multiparty/node_modules/readable-stream/node_modules/debuglog/'. As a result, when updating dependencies with npm, a same dependency is downloaded multiple times.

It solves the nasty versioning issues that plague the other package managers like pip and rubygems.

Every package gets the correct versions for all of its dependancies at the cost of taking more hard drive space. Hard drive space is ridiculously cheap so it's a good trade off.

Re: A Haskell Programmer Tries to Learn Racket

#120

Earlier quoted context omitted.

To me, "almost completely compatible" sounds similar to "just a tiny bit pregnant". In practice, either it is compatible, or it isn't.

Not necessarily. Java 6 and 7 are "almost completely compatible". Most programs written in Java 6 will run in Java 7, and vice versa. But not all.

C++ is similar with regards to C code. They're compatible enough that a lot of people will write "C/C++", but they're still incompatible enough that you'll get yelled at by a lot of people if you write "C/C++".
Post reply on HN