Live data from Hacker News

It's 2023, so of course I'm learning Common Lisp

log.schemescape.com

131–140 of 346 posts

Re: It's 2023, so of course I'm learning Common Lisp

#131

Earlier quoted context omitted.

> “mathematica is a lisp”

http://xahlee.info/M/lisp_root_of_wolfram_lang.html http://xahlee.info/M/lisp_vs_WolframLang.html > WolframLang has all the characteristics of LISP: seems you either don't know what lisp is or you've never written mathematica

The content on the pages clearly explain the differences.

Mathematica is a symbolic language based on 'rewriting' There are other examples - Prolog would be an example, a logic language. Also most other computer algebra systems are in this category, similar to Mathematica: Macsyma/Maxima, Axiom, ...

> WolframLang has all the characteristics of LISP

It has many, but there are a lot of differences, too.

The big difference is the actual engine. Mathematica is based on a 'rewrite system'. It translates expressions by applying rewrite rules.

Lisp evaluates expressions either based on an interpreted evaluator or by evaluating compiled code. Lisp has macros, but those can be transformed before the code is compiled or running. The practical effect is that in many Lisp implementations usually all code is compiled, incl. user code. Mathematica uses C++ then. Most of the UI in Mathematica is implemented in C++, where many Lisp systems would implement that in native compiled Lisp.

Thus the computation is very different. Using a rewrite system for programming is quite clunky and inefficient under the hood. A simple example would be to look how lexical closures are implemented.

Another difference is that Mathematica does not expose the data representation of programs to the user all the time, where Lisp programs are also on the surface written as s-expressions (aka symbolic expressions) in text.

The linked page from the Mathematica book also claims that Mathematica is a higher level language. Which is true. Lisp is lower level and languages like the Wolfram Language can be implemented in it. That's one of its original purposes: it's an implementation language for other ('higher-level') languages. Sometimes it already comes with embedded higher-level languages. CLOS + MOP (the meta-object protocol) would be an example for that.

Re: It's 2023, so of course I'm learning Common Lisp

#132
post #131

Earlier quoted context omitted.

http://xahlee.info/M/lisp_root_of_wolfram_lang.html http://xahlee.info/M/lisp_vs_WolframLang.html > WolframLang has all the characteristics of LISP: seems you either don't know what lisp is or you've never written mathematica

The content on the pages clearly explain the differences. Mathematica is a symbolic language based on 'rewriting' There are other examples - Prolog would be an example, a logic language. Also most other computer algebra systems are in this category, similar to Mathematica: Macsyma/Maxima, Axiom, ... > WolframLang has all the characteristics of LISP It has many, but there are a lot of differences, too. The big differe…

> Another difference is that Mathematica does not expose the data representation of programs to the user all the time, where Lisp programs are also on the surface written as s-expressions (aka symbolic expressions) in text.

I have already addressed this: FullForm

https://reference.wolfram.com/language/tutorial/Expressions....

>Thus the computation is very different. Using a rewrite system for programming is quite clunky and inefficient under the hood. A simple example would be to look how lexical closures are implemented.

You're skimming a couple of paragraphs without actually knowing much about Mathematica. It's absolutely not the case that Mathematica is purely a redex system; it's just that it's very good at beta reduction because it has a strong focus on CAS features.

Re: It's 2023, so of course I'm learning Common Lisp

#133

Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so far: * The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts * REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for exam…

Small typo enusre => ensure

Re: It's 2023, so of course I'm learning Common Lisp

#134
I'd be interested in if you considered Guile first and what made you decide in favor of common lisp. Few years ago when I decided its finally time to learn lisp I looked at few variants and Guile seemed to have the benefit of: fairly vibrant(but somewhat hermetic) online community, a sizable manual that describes most frequently used APIs (you can learn the language itself very quickly, but it's the knowledge of the APIs you need to do anything in the "real world"), and being actively maintained and extended. So I chose Guile.

For those that don't know these terms Guile and common lisp are two implementations of the same scheme language (simplifying a lot).

Re: It's 2023, so of course I'm learning Common Lisp

#135
post #47
post #41

Earlier quoted context omitted.

Lots of languages that are not lisp have this ability.

examples please, because so far i have only seen this from common lisp and smalltalk. there is also pike where i can reload classes or objects at runtime, thus avoiding a full restart, but it's not as closely integrated as in smalltalk and you actually have to build your app in a way that allows you to do that.

JavaScript immediately comes to mind.

Re: It's 2023, so of course I'm learning Common Lisp

#136

Earlier quoted context omitted.

Not the OP but would somebody be able to summarize HOW are the lisp REPLs different then to me? I've written limited amount of clojure and common lisp just to play around and I don't recall any difference between Clojure REPL and the REPL I get for say Kotlin inside IntelliJ idea. Maybe the ability to send expression from the IDE into the REPL with one keybind but I cannot say it's not possible with the Kotlin one ri…

There's a person above saying that it's about being to able to mutate program state from the repl, which is a thing that's also possible in any repl for a language with managed memory.

Cl Condition system + repl = godmode. Your software crashes? Do you go back and set a breakpoint? No, because you’re already in the stacktrace in the repl exactly where the crash occurred. You fix the code, reload it, tell it to ether run where it left off, or restart from an earlier point.

Re: It's 2023, so of course I'm learning Common Lisp

#137

Earlier quoted context omitted.

> The repl driven workflow is amazing and the lisp images are rock solid and highly performant. do people not realize that basically everything vm/interpreted language has a repl these days? https://www.digitalocean.com/community/tutorials/java-repl-j... https://github.com/waf/CSharpRepl https://pub.dev/packages/interactive not to mention ruby, python, php, lua hell even c++ has a janky repl https://github.com/root-p…

Of course people "realise" this. But those REPLs are not actually REPLs. They are interactive language prompts. They aren't actually REPLs. As the joke goes, Python doesn't have a REPL: it lacks READ, EVAL, PRINT and LOOP. Being able to type in code and have it evaluated one line at a time isn't a REPL.

IMO, the downside with the term REPL is that if you don't understand the specific Lisp definitions of the terms, it sounds like any other interactive execution environment.

Re: It's 2023, so of course I'm learning Common Lisp

#138
post #19

Earlier quoted context omitted.

Eventually you need to work with other people, and using a common time-shared or multi user session is unlikely. Now consider that lisp images generally can't be easily diff'd or merged. And with that the edit-and-continue paradigm loses much of its value. If you have to commit changes to a shared source file anyhow then you'll be not much worse off with debugging a core dump.

I'm confused. Why aren't you all just working on your own machines?

The classic lisp way is to build a runtime image by editing the image while running it, then dumping a binary. You never specifically need to load a source file.

But you can't easily collaborate with that style of development.

Re: It's 2023, so of course I'm learning Common Lisp

#139
post #99

Earlier quoted context omitted.

It took me a while to grok monads, and the IO monad, and longer still to figure out how to compose them in safe ways, and manipulate execution order, etc. But: now I can write typesafe applications, and I produce fewer bugs when I work in non-FP languages (I get paid to write Java.) Lisp is a starting point. Haskell is where it's at. I recommend learning the style, even if you never produce production code in it.

Let’s say I want to do something simple but slightly beyond the scope of a traditional toy demonstration: * Read some environment variables and a local file * Start a monitoring thread that consumes from a channel or something similar, then every X s or X events writes to a local temp file and then sends a request batching some metrics to an external system * Configure and start an http server * Said server has a han…

I'll cover the Haskell side because I'm more familiar with its library ecosystem:

> Read some environment variables and a local file

    import System.Environment (getEnv)
    import System.FilePath (())
    main = do
      dir  "foo.txt")
      putStrLn ("Had " ++ show (length (lines data)) ++ " lines")
> Start a monitoring thread [...]

    import Control.Concurrent
    import Control.Concurrent.Chan
    import Network.HTTP
    -- also more stuff...

    monitoringThread :: Chan String -> IO ()
    monitoringThread chan = do
      file 
> Configure and start an http server

    import Network.Wai
    import Network.Wai.Handler.Warp

    main = run 8000 $ \req respond ->
      respond (responseLBS status200 [] "Hello, world!")
> Said server has [...]

Yeah, this is long. If you're just getting the current time with the timer, that's here[2]; synchronize across threads with MVars[3] or STM[4]; JSON is in aeson[5], which should feel broadly familiar if you know Rust's serde.

> server’s gotta be able to do concurrency > 1 with parallelism

Yep, GHC Haskell has _excellent_ concurrency support on top of a parallel runtime.

> On sigterm set the server to a state that rejects new requests, waits for existing requests to complete, then flushes the monitoring channel

I haven't personally tried this, but this[6] function sounds like... exactly this, actually, so I think its example should suffice?

On two separate notes:

- Common Lisp and Python 3 are a _lot_ closer than Common Lisp and Haskell, or even Python 3 and JavaScript; the Python 3 object model is very close to Common Lisp's, and Common Lisp is not particularly pure (setf isn't unidiomatic by a longshot), and supports a very non-functional style of programming (it has gotos!).

- "Haskell is worse at IO than other high-level languages" isn't particularly true. What _is_ true is that Haskell has the same "function coloring problem" as JavaScript (Haskell has the IO monad, JavaScript has the Promise monad); Haskell also has a "uses funny academic words" problem (well, debatably a problem...) which I think confuses the issue.

[0]: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/bloc...

[1]: Haskell has a spec, one "main" implementation (GHC), little spec-committee activity, and a respect for that implementation not superseding the spec; many improvements become language extensions (-X flags or {-# LANGUAGE #-} pragmas), so when you invoke GHC you're getting a by-the-spec implementation by default.

[2]: https://hackage.haskell.org/package/time-1.12.2/docs/Data-Ti...

[3]: https://hackage.haskell.org/package/base-4.18.0.0/docs/Contr...

[4]: https://hackage.haskell.org/package/stm-2.5.1.0/docs/Control...

[5]: https://hackage.haskell.org/package/aeson-2.2.0.0/docs/Data-...

[6]: https://hackage.haskell.org/package/warp-3.3.28/docs/Network...

Re: It's 2023, so of course I'm learning Common Lisp

#140
post #131

Earlier quoted context omitted.

The content on the pages clearly explain the differences. Mathematica is a symbolic language based on 'rewriting' There are other examples - Prolog would be an example, a logic language. Also most other computer algebra systems are in this category, similar to Mathematica: Macsyma/Maxima, Axiom, ... > WolframLang has all the characteristics of LISP It has many, but there are a lot of differences, too. The big differe…

> Another difference is that Mathematica does not expose the data representation of programs to the user all the time, where Lisp programs are also on the surface written as s-expressions (aka symbolic expressions) in text. I have already addressed this: FullForm https://reference.wolfram.com/language/tutorial/Expressions.... >Thus the computation is very different. Using a rewrite system for programming is quite clu…

> I have already addressed this: FullForm

No you haven't addressed it. The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation.

> it's just that it's very good at beta reduction

and not so good at compiling code...

https://reference.wolfram.com/language/ref/Compile.html

See "Details and Options"

Post reply on HN