Live data from Hacker News

Why Racket? Why Lisp?

practicaltypography.com

221–230 of 295 posts

Re: Why Racket? Why Lisp?

#221

I tried somewhat Pollen and it's kind of fantastic, the only thing is getting to work with a new project in a language that I don't know very well is difficult for me. That's why I started a similar project in Python, watch https://warehouse.python.org/project if you interested /azoufzouf/

I just pushed the code. You can have a look at it @ http://amirouche.github.io/azoufzouf/ there is all you need to know and ⵣcode{pip install azoufzouf}.

With that markup, it's easy to plug any function you want. That's right. It's not nested and is inspired from unix philosophy, I dare to say. I tried several time Sphinx, docutils alone and other markups they don't deliver as much as this one (sofar).

Re: Why Racket? Why Lisp?

#222
post #209

Earlier quoted context omitted.

That sounds like a feature that would both be awesome, and annoy the crap out of me. Are there examples where this actually leads to clearer code in the wild?

Several common typeclasses in Haskell have methods that are polymorphic in the return type, and I find it extremely useful. The bounds of a bounded type: minBound :: Bounded a => a maxBound :: Bounded a => a Converting an integer to an enumerated type: toEnum :: Enum a => Int -> a Casting between numeric types: fromIntegral :: (Integral a, Num b) -> a -> b Parsing a string into a value: read :: Read a => String -> a…

Sadly, my own deficiencies in being able to read Haskel are keeping that from being a compelling argument. I do intend on visiting it more later. Just, right now, I prefer the dead simple to parse lisp over this.

Re: Why Racket? Why Lisp?

#223
post #9

Earlier quoted context omitted.

As someone who writes Lisp (well, Clojure) every day and does not particularly enjoy it, I find the common complaint about parentheses to be a non-issue. In fact, I'm not sure I've heard of anyone who wrote any significant amount of lisp code and came away talking about parentheses. This seems to be mostly a reaction from people who've read a bit of Lisp without using it. Then again, I just noticed that I type ( and…

I would assume it'd be the same as people complaining about significant whitespace in python. No one who actually programs in python complains about the whitespace.

I program in Python for a living and I curse significant whitespace every single work day. Especially when I try to copy paste some code into the shell. It's one of the worst misfeatures of the language, and it wouldn't even be necessary if there was an "end" keyword.

Re: Why Racket? Why Lisp?

#224

Earlier quoted context omitted.

Lisp was considered a functional programming language before ML existed. Lisps generally don't have as strong and exclusive support for the functional paradigm as some newer languages (and pretty much anything else still in use is newer than lisp), but then C++ is known as an OOPL despite having less strong and exclusive support for the OO paradigm than many older languages, so there's that.

Lisp was considered a functional programming language before ML existed. That was then and this is now. Today, functional programming means side-effect-free with a strong type system, and efficient use of higher-order abstractions over functions, including things like typeclasses to define entire morphisms given a few functions which establish relationships between objects. Lisp doesn't really support this effectivel…

I'm not sure I see what having "a strong type system" has to do with whether or not a language can be considered functional. It seems like it's just a way to say that Haskell and the MLs are the only languages that qualify. And that sounds more like PR than a formal definition.

It's also not really historically accurate. People were referring to languages based on the untyped lambda calculus as "functional" before things like Hindley-Milner appeared (in the 70s). Were they (and I'm talking about PL researchers) all speaking incorrectly?

Re: Why Racket? Why Lisp?

#225

Earlier quoted context omitted.

Lisp was considered a functional programming language before ML existed. Lisps generally don't have as strong and exclusive support for the functional paradigm as some newer languages (and pretty much anything else still in use is newer than lisp), but then C++ is known as an OOPL despite having less strong and exclusive support for the OO paradigm than many older languages, so there's that.

Lisp was considered a functional programming language before ML existed. That was then and this is now. Today, functional programming means side-effect-free with a strong type system, and efficient use of higher-order abstractions over functions, including things like typeclasses to define entire morphisms given a few functions which establish relationships between objects. Lisp doesn't really support this effectivel…

> Today, functional programming means side-effect-free with a strong type system

Functional programming has always meant the style or paradigm of programming that prefers side-effect-free declarative code that can be modelled in the substitution model; type systems have always been (and remain) orthogonal concerns. A functional language is one that supports the functional paradigm, but it has never been most commonly used for languages that exclusively support that paradigm. Pure functional code is the term that has been used for code that is exclusively in that style, and pure functional language is the term that is generally used for a language that has exclusive support for that style.

Re: Why Racket? Why Lisp?

#226
post #222

Earlier quoted context omitted.

Several common typeclasses in Haskell have methods that are polymorphic in the return type, and I find it extremely useful. The bounds of a bounded type: minBound :: Bounded a => a maxBound :: Bounded a => a Converting an integer to an enumerated type: toEnum :: Enum a => Int -> a Casting between numeric types: fromIntegral :: (Integral a, Num b) -> a -> b Parsing a string into a value: read :: Read a => String -> a…

Sadly, my own deficiencies in being able to read Haskel are keeping that from being a compelling argument. I do intend on visiting it more later. Just, right now, I prefer the dead simple to parse lisp over this.

Translating, with some minimal explanation:

    name :: constraints_for_type => type_of_name
says "Thing named 'name' has type 'type_of_name' with constraints 'constraints_for_type'"

So,

    minBound :: Bounded a => a
    maxBound :: Bounded a => a
"minBound has type 'a' for any 'a', so long as 'a' is an instance of Bounded"

These two are more values than functions, but the polymorphism happens the same way. If you use them where some particular bounded type is expected, that's the type they evaluate to. If you use them where an unbounded type is expected, you'll get a compile error.

----

    toEnum :: Enum a => Int -> a
"toEnum has type 'Int -> a' (that is, a function from 'Int' to 'a') for any type 'a', provided that 'a' is an instance of Enum"

i.e., Convert an int to the Enum type that the context is asking for.

----

    fromIntegral :: (Integral a, Num b) => a -> b
"fromIntegral has type 'a -> b' (that is, a function from 'a' to 'b') for any types 'a' and 'b' where 'a' is an integral type and 'b' is a numeric type"

The tuple syntax just means that all these constraints need to apply. I'm not actually certain why the syntax requires it.

----

    read :: Read a => String -> a
"read has type 'String -> a' for any type 'a', provided that 'a' is an instance of Read"

----

    mempty :: Monoid m => m
"mempty has type 'm' for any type 'm' (different letter is just stylistic - m for monoid), provided that 'm' is an instance of Monoid"

This is particularly interesting when you start doing polymorphic things with fold and friends.

----

    return :: Monad m => a -> m a
"return has type 'a -> m a', so long as 'm' is a Monad"

Here we see a "higher-kinded type" - m is a function at the type level that takes a type argument and produces another type, like a C++ template.

e.g. List parameterized by Integer gives us a List of Integers (List is spelled [] in Haskell)

----

    mconcat :: Monoid m => [m] -> m
"mconcat is a function from any 'list of m' to a single 'm', provided 'm' is an instance of Monoid"

    mconcat = foldr mappend mempty
"we define mconcat to be the right fold of mappend over the list, using mempty as our initial value"

Re: Why Racket? Why Lisp?

#227

Earlier quoted context omitted.

Lisp was considered a functional programming language before ML existed. Lisps generally don't have as strong and exclusive support for the functional paradigm as some newer languages (and pretty much anything else still in use is newer than lisp), but then C++ is known as an OOPL despite having less strong and exclusive support for the OO paradigm than many older languages, so there's that.

Lisp was considered a functional programming language before ML existed. That was then and this is now. Today, functional programming means side-effect-free with a strong type system, and efficient use of higher-order abstractions over functions, including things like typeclasses to define entire morphisms given a few functions which establish relationships between objects. Lisp doesn't really support this effectivel…

That's a very precise definition of the class of functional languages. Unfortunately in the real world the definition tends to be much more varied. ;)

Re: Why Racket? Why Lisp?

#228

Earlier quoted context omitted.

> As for the idea of Lisps, well, it sure seems neat. But I've literally never run across a situation where I needed my code to edit itself. I've never run across a situation where the lack of an everything-is-an-expression-is-a-list feature prevented me from doing what I wanted to do. This is classic Blub paradox. You don't feel like you need a feature until you start using it, at which point you start wondering how…

OK, but I've been aware of Lisp macros for a while, and still never seen a situation where I needed them. A couple weeks ago, though, I found myself in a situation where the user needed to be able to specify a filter, and the filter was going to be a tree of expressions, and the program had to take what the user specified and turn it into something the program could execute... and the filter tree looks a lot like an…

Everyone here is hoping their favorite language feature will added to Java 9, Python 3, C++14, Javascript, etc. Whatever feature that is, Lisp programmers would add it with a macro and move on. There is no central governing body deciding what I can or can't do with the language syntax. That's why macros are useful.

Re: Why Racket? Why Lisp?

#229
post #155

Re 1. everything is an expression benefit, condition example: C-like languages often have the ternary operator, cond?exp1:exp2 , that is exactly this. I feel clever using it, but I consider it a hack, because it's (usually) less clear. A microcosm of lisp, clever but unclear.

I think it mostly seems unclear in C because of the syntax. If you could write this in C, would it still seem unclear? int x = if (y == 0) then 7 else 10; As opposed to one of these: int x; if (y == 0) x = 7; else x = 10; or int x = 10; if (y == 0) x = 7; It makes everything local, and in my opinion reduces cognitive load.

(speaking for myself only): I find the ?: syntax clearer... probably because I've known it for so many years. It's the doing several things at once that, for me, makes it unclear.

Of your examples, I find the very last one the clearest. Arguably, it's a hack, because it assigns values twice to x - but it feels like the syntax embodies the semantic truth of y==0 being an exception. A pattern matching solution (with a specific and then a general rule) would also embody this, but to me, having the general rule first, with a following exception, seems more intuitive.

Disclaimer: "intuitive" is all very subjective, and it's certainly possible that with experience, my intuition could change. But for better or worse, the above is my opinion today!

PS: I do think your first example is cool, neat and clever. I understand and feel that aspect of the appeal.

Re: Why Racket? Why Lisp?

#230
post #206

It seems most people here have never used (and not tried) racket. I decided to use racket for my little sides projects, as replacement for scala and clojure. I choose it because it was clear for me i can't stand limitations other language impose to me in way of style and boilerplate, the racket macro (aka syntax transformer) system is the most advanced i know to reduce the boilerplate to a minimum and so just write w…

I'm glad you like Racket, and you're right about some of the weaknesses, especially in providing guidance and examples for how to do things. I have questions about points 3 and 4. For 3, do you mean it's hard to figure out how the implementation of something works, especially when that something is a complex macro? If so, I can't disagree. For 4, if you just run Racket programs at the command line, you should get sta…

For 4 if i run from the command line (racket 5.93) i just get the contract violation message, which don't provide positional informations, it's not usefull when you have a list contract error with dozen of uses in a file.

For 3 i mean the words like 'visiting', 'instantiated', the phases, the syntax transformer there are many things to grasp. For instance i used to believe that phase 1 bindings where the functions executed by the expander instead of the one defined by define-syntax.

For complex macro i just expand it that's fine.

Other point the continuation is hard to grasp, i really understand when i see http://www.infoq.com/presentations/continuations-web-os, the key point that help me is the fact he mentions continuation capture also the exit.

Another flaws i didn't mention is messages of typed/racket could be hard to understand especially one involving parametric function, this problem occur time to time in the mailing list. I know you take this kind of problems seriously.

A point why i like racket is because it's lexical scoped but also let me precise the portion i want more dynamism in with parameters or with eval + namespace.

Racket also miss some tooling the one come in mind is coding standard checker and formater, it could be done with free-identifier=? and have some rules. New macro could write their associated rule as metadata in a submodule. Is it doable, i mean technically not the fact to expect macro writer will write such rules?

Post reply on HN