> I thought hyprsunset already changes the temperature automatically for you.
It seems it does now, when I wrote my thing there wasn't multiple profiles feature - it's a very recent feature that was added not too long ago. I guess I can remove my custom script now. But then again, if it just works, why bother?
> What is the difference between a "true" repl and one like python?
Like I said, all stages in R.E.P.L. do differ:
Read:
In Lisp, lexical analysis and tokenization keeps the forms as data - no need to do much here. In Python, this step produces private AST representation you cannot easily access and modify.
Eval:
In Lisp, the compiler just walks the forms freely - because they are already in the shape; in Python, parser-generated AST nodes get passed to compiler, AST is opaque to user code, it doesn't allow manipulation semantics, Macros in Python require AST manipulation libs - heavyweight, not first-class; This is fixed compile phase in Python - no runtime AST rewriting possible.
Print:
Serializes eval results back to readable representation. In Lisp - this is trivial because results already data structures in the right shape. In Python, you can't feed printed output back through eval and get meaningful metaprogramming.
Loop:
Reader directly consumes user input, they are just native forms, compiler sees the code like data, this allows transparent metaprogramming - you can easily write code that re-writes itself. In Python: string input first compiles then gets processed for execution; metaprogramming is pretty opaque - reconstructing the AST is much more difficult - not easy to write code that re-writes itself; eval/exec operate on bytecode, not source semantics.
In practice, what these seemingly unimportant differences make possible is:
first of all you get to write code as you are playing a video game - you just write shit and eval things, and immediately make things fly - find Figwheel demo video, Bruce Hauman there writes a clone of FlappyBird where he manipulates the physics directly from the editor - without any saving, reloading anything, without state changes, etc., he literally uses his editor like a joystick to move the effing bird around. And it's some darn old flick - there's nothing "revolutionary" about that technique - Lispers been doing shit like that for a long time. Or search up on YouTube "Clojure/Overtone DJ programming", where folks are playing music while manipulating some code in their editors, all in real-time. Or check this out - we run our services in k8s cluster. In staging env we maintain a REPL connection, so if we need to test something out, we just connect to it, change the code, eval and manipulate our entire pipeline directly from our editors.
These differences in REPL also open up metaprogramming otherwise much harder to achieve. Like for example, you can write code that says: "here's the server part, here's the client part" and then let the multi-phase eval figure out the semantics - sometimes, these semantics can mean that the server part actually executes in a different runtime - checkout Hyperfiddle/Electric demos - some of them are jaw dropping - you write code in one place but some of it executes on JVM, some in the browser - completely different runtime. Same code, unified logic, lives in one place - goes to run on different worlds.
It seems it does now, when I wrote my thing there wasn't multiple profiles feature - it's a very recent feature that was added not too long ago. I guess I can remove my custom script now. But then again, if it just works, why bother?
> What is the difference between a "true" repl and one like python?
Like I said, all stages in R.E.P.L. do differ:
Read: In Lisp, lexical analysis and tokenization keeps the forms as data - no need to do much here. In Python, this step produces private AST representation you cannot easily access and modify.
Eval: In Lisp, the compiler just walks the forms freely - because they are already in the shape; in Python, parser-generated AST nodes get passed to compiler, AST is opaque to user code, it doesn't allow manipulation semantics, Macros in Python require AST manipulation libs - heavyweight, not first-class; This is fixed compile phase in Python - no runtime AST rewriting possible.
Print: Serializes eval results back to readable representation. In Lisp - this is trivial because results already data structures in the right shape. In Python, you can't feed printed output back through eval and get meaningful metaprogramming.
Loop: Reader directly consumes user input, they are just native forms, compiler sees the code like data, this allows transparent metaprogramming - you can easily write code that re-writes itself. In Python: string input first compiles then gets processed for execution; metaprogramming is pretty opaque - reconstructing the AST is much more difficult - not easy to write code that re-writes itself; eval/exec operate on bytecode, not source semantics.
In practice, what these seemingly unimportant differences make possible is: first of all you get to write code as you are playing a video game - you just write shit and eval things, and immediately make things fly - find Figwheel demo video, Bruce Hauman there writes a clone of FlappyBird where he manipulates the physics directly from the editor - without any saving, reloading anything, without state changes, etc., he literally uses his editor like a joystick to move the effing bird around. And it's some darn old flick - there's nothing "revolutionary" about that technique - Lispers been doing shit like that for a long time. Or search up on YouTube "Clojure/Overtone DJ programming", where folks are playing music while manipulating some code in their editors, all in real-time. Or check this out - we run our services in k8s cluster. In staging env we maintain a REPL connection, so if we need to test something out, we just connect to it, change the code, eval and manipulate our entire pipeline directly from our editors.
These differences in REPL also open up metaprogramming otherwise much harder to achieve. Like for example, you can write code that says: "here's the server part, here's the client part" and then let the multi-phase eval figure out the semantics - sometimes, these semantics can mean that the server part actually executes in a different runtime - checkout Hyperfiddle/Electric demos - some of them are jaw dropping - you write code in one place but some of it executes on JVM, some in the browser - completely different runtime. Same code, unified logic, lives in one place - goes to run on different worlds.