Live data from Hacker News

Why Language-Oriented Programming? Why Racket?

beautifulracket.com

101–110 of 115 posts

Re: Why Language-Oriented Programming? Why Racket?

#101
post #100

Earlier quoted context omitted.

I'd add some caveats to GP's comment, but I think it's mostly spot on. >"Rust or Go or C++?" Does one of these make memory problems easier to avoid? >"Python or Ruby?" One of these prioritises having a single way to do most tasks, while the other prioritises programmer expressiveness (simple example: "unless" is absent in Python). Thus one is easier to onboard newbies with and have them relatively quickly be able to…

>the differences between Java and C# Not much.

Are you primarily targeting Microsoft platforms? If so, then C# might have the edge. Otherwise, you might prefer Java.

Re: Why Language-Oriented Programming? Why Racket?

#102
post #57

I was thinking recently about why I find programming languages so interesting. The answer I came up with was that programming languages allow you to create your own reality. You get to define how things work in this reality. Want functions to be values that can be arguments and return values? Sure! Want a lot of crazy symbols to do complicated math? Go for it! Want everything to be dynamic? Why not. The caveat that c…

The problem is that people often create languages that are basically the same as existing languages; no new concepts. New languages are usually a grab-bag of features found in C, Java, Lisp and/or Haskell.

> New languages are usually a grab-bag of features found in C, Java, Lisp and/or Haskell.

With different predecessors, that's also true of at least C and Java on that list.

OTOH, the particular "combination* of features in the grab bag can be quite significant in practice, even if none of three features are new individually.

Re: Why Language-Oriented Programming? Why Racket?

#103

Earlier quoted context omitted.

Ok, I think I read more into your first comment than you actually said. >many routes are just not focusing on the higher level design skills that I think are needed to make good libraries/frameworks/DSL's. I have observed that too. But I don't think this is about who is and isn't a computer scientist, whether self-taught or formally trained. I think it's more a change in the way people relate to programming languages…

He can view himself however he wants, but the man just wrote an article that competently covers Turing completeness, regular expressions, and Lindemeyer trees, among other things! He's definitely earned his comp sci merit badge, so to speak.

Computer science is a specific treatment of these topics that is based in formalism. Compare John McCarthy's "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I" and Paul Graham's "The Roots of Lisp". These papers cover exactly the same material. But only the first is computer science because it uses a formal language to express the ideas.

Re: Why Language-Oriented Programming? Why Racket?

#104
post #87

Earlier quoted context omitted.

This seems unsatisfying. Most of the modern languages are choosing pretty much the same sets of features. I've been using them for years (decades?), and I couldn't tell you significant differences between most of these languages. There's maybe 3 major islands of languages today. Within each island, they make essentially the same things easy. The answer to a question like "Python or Ruby?", "C# or Java?", or "Rust or…

I'd add some caveats to GP's comment, but I think it's mostly spot on. >"Rust or Go or C++?" Does one of these make memory problems easier to avoid? >"Python or Ruby?" One of these prioritises having a single way to do most tasks, while the other prioritises programmer expressiveness (simple example: "unless" is absent in Python). Thus one is easier to onboard newbies with and have them relatively quickly be able to…

> One of these prioritises having a single way to do most tasks, while the other prioritises programmer expressiveness

And yet, whatever they claim to prioritize, they aren't particularly different on those fronts.

OTOH, they have radically different features even if both are dynamic multiparadigm languages, though it's true that decisions between languages often turn on ecosystem rather than language features independent of how different the language features are, and that's also true of Ruby vs. Python.

Re: Why Language-Oriented Programming? Why Racket?

#105
post #89
post #75

Earlier quoted context omitted.

ok but then since lisp already has an extremely small syntax, why not simply define functions in the language rather than using the macro system ? Unless your goal is to be source compatible with another lisp variant, of course.

>why not simply define functions in the language rather than using the macro system? I don't know. Most examples I've seen from people extolling the virtues of lisp macros and metaprogramming wind up just generating more lisp code in the same language with the same syntax and semantics, so I don't know why you couldn't just use functions in that case. To be fair, I only have a surface understanding of one lisp varian…

Syntax is different from semantics. To give a concrete example, say you want a part of a program to use lazy constructs. In racket, you could use `#lang lazy` for that one module and then import and use that code within `#lang racket` modules.

Despite having the same syntax, `#lang lazy` and `#lang racket` behave differently:

    #lang lazy

    (define (say-hi _)
      (displayln "Hi!"))

    (say-hi (exit 1))


    $ racket lazy-example.rkt
    Hi!
    $ echo $?
    0
versus

    #lang racket

    (define (say-hi _)
      (displayln "Hi!"))

    (say-hi (exit 1))

    $ racket racket-example.rkt
    $ echo $?
    1
Exact same syntax, different semantics.

Re: Why Language-Oriented Programming? Why Racket?

#106
post #34

Earlier quoted context omitted.

Racket tends to be geared to writing lispy things because of the heavy reliance of the syntax parsing and macro transformation on s-expressions, so most/all being variants of lisp makes sense. Writing non-sexp languages in Racket tends to take a lot more work that's not batteries included. It also has an incredibly powerful inheritance system. In 3-5 lines I can inherit all the functionality from Racket and then add,…

> Writing non-sexp languages in Racket tends to take a lot more work that's not batteries included. No more work than any other language - Racket has reclusive descent, lex/yacc and PEG parsers generators. There is a whole section on parsers at http://docs.racket-lang.org/ including ‘Megaparsack’ based on higher-order parser combinators (like parsec for Haskell) Racket can also read ‘C’ yacc/bison grammars. It’s wort…

This looks like a nice topic for a blog post / single page tutorial. Perhaps show the rackety way and compare with version in Racket that use the usual parsers in other languages.

Re: Why Language-Oriented Programming? Why Racket?

#107
If I’m understanding the article correctly, it should be possible to create a Racket language that compiles to any other language. A quick google does reveal work has been done on C and Python, although it appears there are bugs and various work-arounds that precludes a full and clean integration. The Javascript integration appears dead (in terms of using the latest version of Racket)

Although using Racket for this wholesale integration appears impractical, it does suggests a killer-app: extending general programming languages. In other words, using Racket as a transpiler. I.e., a better Babel.js, but for any language.

I routinely use Python for machine learning tasks, but frequently am frustrated by the inflexibility of the language. Instead of solving the problem itself I have to first solve how to make the language do what I want (usually resulting in code that lacks expressiveness and brevity, and thus extensibility).

I’d love to use lisp to leverage ML work that can only be done effectively in Python (Tensorflow, PyTorch, etc).

Can Racket be an effective transpiler?

Re: Why Language-Oriented Programming? Why Racket?

#108

Earlier quoted context omitted.

He can view himself however he wants, but the man just wrote an article that competently covers Turing completeness, regular expressions, and Lindemeyer trees, among other things! He's definitely earned his comp sci merit badge, so to speak.

Computer science is a specific treatment of these topics that is based in formalism. Compare John McCarthy's "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I" and Paul Graham's "The Roots of Lisp". These papers cover exactly the same material. But only the first is computer science because it uses a formal language to express the ideas.

If that's the definition of CS we're using then my original post is a very egregious misnomer. I feel like that definition is way too restrictive though. CS can be formalized and informal, but both are still CS IMO.

Re: Why Language-Oriented Programming? Why Racket?

#109
post #89
post #75

Earlier quoted context omitted.

ok but then since lisp already has an extremely small syntax, why not simply define functions in the language rather than using the macro system ? Unless your goal is to be source compatible with another lisp variant, of course.

>why not simply define functions in the language rather than using the macro system? I don't know. Most examples I've seen from people extolling the virtues of lisp macros and metaprogramming wind up just generating more lisp code in the same language with the same syntax and semantics, so I don't know why you couldn't just use functions in that case. To be fair, I only have a surface understanding of one lisp varian…

A nice example is `match` that is one of the macros that comes by default in Racket.

  #lang racket
  
  (define (show x)
    (match x
      [(vector a b c)
       (display "It's a vector, total = ")
       (displayln (+ a b c))]
      [(list p q)
       (display "I's a list, average = ")
       (displayln (/ (+ p q) 2))]))
  
  (show (list 8 2))
  (show (vector 1 2 3))
(Playable version http://pasterack.org/pastes/75154 )

The idea is that `match` can analyze the value of the first argument (`x` in this case) and then it binds the variables (a,b,c or p,q in this case).

In this case I'm matching only a vector with 3 values or a list with 2 values, but you can match more complicated and nested pattern.

The interesting part is that inside match you have the full power of the language, you are not restricted to a few special hardcoded cases (like `display`). You can send an hppt request, play a sound, save a value to disk, calculate the prime factorization, transform the text to uppercase, anything that is available in the language is available inside match.

But `match is just a normal macro. Racket is implemented in layers. The bottom layer is implemented currently in C, but it doesn't define `match`. The bottom layer is almost hidden and it is used to define some libraries and an intermediate language that it is used to define some libraries and an intermediate language, ..., and after a few steps you get the official Racket language.

But if you like you can reimplement a macro like `match`, or a variant, or your own macro, with all the magic to define local variables and use all the power of the language inside it.

Re: Why Language-Oriented Programming? Why Racket?

#110

If I’m understanding the article correctly, it should be possible to create a Racket language that compiles to any other language. A quick google does reveal work has been done on C and Python, although it appears there are bugs and various work-arounds that precludes a full and clean integration. The Javascript integration appears dead (in terms of using the latest version of Racket) Although using Racket for this w…

IIUC Babel.js is essentially a fancy preprocessor for JS. So if by that analogy, you mean "can I use Racket to design my own notation that compiles to Python", yes of course.
Post reply on HN