[jnbiche]

Lisp is not typically a low-level programming language, but rather extremely high-level (high level of abstraction)[0].

The "dialect language of Lisp" quote just means that it's a variation of Lisp, but running in a Python environment.

The term "domain-specific languages" refers to programming languages created for a specific, often one-of, task. If you look at this repo, you'll see various languages used to create diagrams and graphs in this library. These are all examples of DSLs (note, they're in many places, this is just an example):

https://github.com/francoislaberge/diagrams

Regarding Hy specifically, it's basically Python that uses a different syntax, or skin, of sorts. Instead of white-spaces and colons, you get parentheses and...parentheses. It's more complex than that, but it's basically just a way to write Python for people that like Lisps.

0. Yes, there are some examples of low-level lisps without features like memory management, but they're pretty unusual.

[AdamSC1]

So, if I was to boil it down, its like "Hey, use Python, but with a different writing style you are used to."?

[stan_rogers]

Sort of. It's more a case of having all of the flexibility of a Lisp - the ability to program with wishful thinking and fill in the details later - and all of the "batteries included" of Python.

It would genuinely be worth your while to watch the SICP lectures with Gerry Sussman and Hal Abelson [1] to get an inkling of an idea of what "your program is just more data" can mean. Lisp is more about brining the language up to the level of the problem than bringing the problem down to the level of the language, and it's difficult to appreciate what that means until you've seen it. By the time you get to the end of lecture 3B, it should click.

[1] https://ocw.mit.edu/courses/electrical-engineering-and-compu...

[jhbadger]

There's also the Common Lisp package "burgled batteries"[1] which allows you to call Python from Lisp. Unfortunately, the original author no longer maintains it and it hasn't been updated to Python 3.

[1] https://github.com/pinterface/burgled-batteries

[ruricolist]

There is a fork that supports Python 3:

https://github.com/snmsts/burgled-batteries3

[AdamSC1]

Thanks - appreciate that and I'll double check the link.

Because I'm still a bit confused at what Lisp is!

[invalidOrTaken]

>Because I'm still a bit confused at what Lisp is!

You're in for a treat!

http://www.paulgraham.com/avg.html

[alexanderdmitri]

How does Hy manage recursion given the limitations there in Python?

[gilch]

It doesn't. Or does the same way as Python: imperative loops. TCO is a key feature of Scheme, but not of Lisps in general. Clojure doesn't have it. You can always trampoline like Clojure's loop does.

[alexanderdmitri]

10-4, thank you!

[jedimastert]

What kind of limitations are you referring to?

[zaro]

> Lisp is not typically a low-level programming language,

For most practical reasons is pretty low level. You don't really write in a language you write in AST directly, which while powerful IMO is not very high level.

[lispm]

One writes in a hierarchical data structure: s-expressions. Since Lisp has built-in macro expressions, on top of s-expressions, one can represent code independent from 'ASTs' and make it executable:

For example the LOOP macro introduces a non-prefix syntax:

  (loop
        for i below 100
        for j = (random 100)

        sum j into s

        while (< s 1000)

        finally (return i))

This is actually pretty powerful and high-level (the user being able to extend or change the syntax in complex ways in portions of a program). The LOOP implementation as a macro is actually an integrated sublanguage and the user can add arbitrary (and even extensible) complex macros like that...

Generally Lisp is low to mid level as a programming language, with a bunch of features which can be considered high-level: extensive macro system, Common Lisp Object System, extensive error handling, ...

[jnbiche]

> Generally Lisp is low to mid level as a programming language,

I believe that no programming language with automatic memory management can be considered "low-level".

That aside, why would you call Lisp "low- to mid-level"? Commonly-used implementations are at about the same level of abstraction as Ruby or Python.

[lispm]

> I believe that no programming language with automatic memory management can be considered "low-level".

That's a view of a whole language and its implementation. Still it may have a range of features which are low level.

Lisp for example has Foreign Function Interfaces (FFI) with low-level interfaces and manual memory management.

Example: http://www.sbcl.org/manual/#Foreign-Function-Interface

Basic Lisp stuff like CAR and CDR were (almost) instructions on a CPU ( https://en.wikipedia.org/wiki/CAR_and_CDR ).

Something like a cons cell (the building block for lists) is basically a two-element vector. Lists were made by chaining them together via a CONS operator, which creates such a two-element vector.

Such a linked list data structure is pretty low-level and the typical mark&sweep GC of the early days is also relatively basic.

There is not much magic to it.

Many other programming languages have much more complex basic data structures (see object-oriented programming in Java with classes and instances, inheritance, interfaces, namespaces, ...). Compared to that the basic linked list in Lisp is primitive.

> I believe that no programming language with automatic memory management can be considered "low-level".

See the standards for Scheme or Common Lisp. There is not a word about automatic memory management in the specifications. Automatic memory management is a feature of an implementation, just like foreign function interfaces. Most implementations have a kind of garbage collector. But most implementations also have manual memory management.

People even write operating systems in Lisp sometimes: https://github.com/froggey/Mezzano

[tripzilch]

Sounds like lisp is doing the low level stuff for you, so really like a mid/high level language. Most languages have statements that correspond to a single cpu instruction. And it sounds like this cons cell is in fact an abstraction away from bytes and memory. Which is more of an abstraction than, say, a byte string.