Earlier quoted context omitted.
How do Lisp developers deal with XML and JSON? Convert it to s-expressions. As a common lisp developer, that is only very vaguely true for me. The mapping I prefer for json Lisp is: true: t false: nil null: :null [] #() {} (make-hash-table :test #'equal) This falls out of my desire for the mapping to be bijective: - The only built-in type that is unambiguously a mapping type is hash-tabe. - nil is the only value that…
In Kernel I would use something like this: true #t false #f null () [...] (& ...) "k" : v (: k v) {...} (@ ...) Where &, :, @ are defined as: ($define! & ($lambda args (cons list args))) ($define! : ($vau (key value) env (list key (eval value env)))) ($define! @ (wrap ($vau kvpairs env (eval (list* $bindings->environment kvpairs) env)))) Using the "person" example from the JSON/syntax section on Wikipedia: ($define!…
Why I still reach for Lisp and Scheme instead of Haskell
81–90 of 172 posts
Re: Why I still reach for Lisp and Scheme instead of Haskell
#82> You can pause, inspect objects, change values, and even redefine a broken function on the fly to test a fix in any environment (yes even in production, while running). I see this mentioned often, and it sounds amazingly useful (especially the part about fixing in production!). But how truly widespread is it among the Lisp dialects to be able to connect to a running program, debug, and hotfix it? I understand Common…
I use it a lot for my one man projects; it is really fantastic in that setting. I use SBCL exclusively; it is very fast and robust and has image based development. I have my own versioning toolkit so I don't go insane.
It is obvious why it is not really used or recommended as it really falls flat in a team setting, mostly even when 2 people are involved. But fixing bugs live as they happen and then spitting out a new .exe for clients is still a lot faster than modern alternatives. Far more dangerous too.
Re: Why I still reach for Lisp and Scheme instead of Haskell
#83(In Haskell) > just adding a simple print somewhere is not going to work without refactor Interesting. How do people cope with this in practice? Does it mean you can't really use log() -statements for debugging?
There is always `trace`.
Re: Why I still reach for Lisp and Scheme instead of Haskell
#84(In Haskell) > just adding a simple print somewhere is not going to work without refactor Interesting. How do people cope with this in practice? Does it mean you can't really use log() -statements for debugging?
You could wrap it in an unsafeIO function to make it return `()` again.
However, I’ve had very little use of printing for debugging. In Haskell you write small (ish) and pure functions that you can test extensively with property based testing. The types already help a lot as well.
So basically the only place where you deal with unexpected input is at the communication boundaries of the app where you are in some form of IO already and printing just available.
Re: Why I still reach for Lisp and Scheme instead of Haskell
#85(In Haskell) > just adding a simple print somewhere is not going to work without refactor Interesting. How do people cope with this in practice? Does it mean you can't really use log() -statements for debugging?
You just add `trace`. It's not hard.
Re: Why I still reach for Lisp and Scheme instead of Haskell
#86> You can pause, inspect objects, change values, and even redefine a broken function on the fly to test a fix in any environment (yes even in production, while running). I see this mentioned often, and it sounds amazingly useful (especially the part about fixing in production!). But how truly widespread is it among the Lisp dialects to be able to connect to a running program, debug, and hotfix it? I understand Common…
Have had to do this live in a production MtG card management application. It worked well. The owner kept their MtG card money. Lisp saved the day.
Re: Why I still reach for Lisp and Scheme instead of Haskell
#87(In Haskell) > just adding a simple print somewhere is not going to work without refactor Interesting. How do people cope with this in practice? Does it mean you can't really use log() -statements for debugging?
There is always `trace`. https://wiki.haskell.org/Debugging#Printf_and_friends
Whoa you were faster than me!
Re: Why I still reach for Lisp and Scheme instead of Haskell
#88Re: Why I still reach for Lisp and Scheme instead of Haskell
#89Earlier quoted context omitted.
For what it's worth, anytime I have written a macro it's usually not because it's needed, but just because I think it'll be fun :)
When I learned Scheme, I liked the language but strongly disliked macros and quotation. I'd only been using it a short while and when I searched for solutions to a few problems these "fexpr" things kept appearing up, which i didn't understand, and this "Kernel" language. I decided to learn it since "fexprs" were apparently the solution to several of my problems. This wasn't easy at first - I had to read the Kernel Re…
Think of macros as what you want when you want to perform computation at compile time rather than run time.
An example: building the equivalent of a switch statement, but that compares (via string equality) with a set of strings. The macro would translate this into code that would do something like a decision tree on string length or particular characters at particular positions.
Basically anything that's done with a preprocessor in another language can be done with macros in Lisp family languages.
Re: Why I still reach for Lisp and Scheme instead of Haskell
#90> You can pause, inspect objects, change values, and even redefine a broken function on the fly to test a fix in any environment (yes even in production, while running). I see this mentioned often, and it sounds amazingly useful (especially the part about fixing in production!). But how truly widespread is it among the Lisp dialects to be able to connect to a running program, debug, and hotfix it? I understand Common…
People do it in Clojure all the time in the dev setup. And you technically can do in your customer environments too, but it's of course a bit of a cowboy thing to do there.