3 ms·
https://www.youtube.com/watch?v=a9xAKttWgP4 https://www.youtube.com/watch?v=a9xAKttWgP4 that's a trick though - no one uses interpreters like that. for most pe
by ice109 9y ago
https://www.youtube.com/watch?v=a9xAKttWgP4 https://www.youtube.com/watch?v=a9xAKttWgP4
that's a trick though - no one uses interpreters like that. for most people they're for experimentation, which is exactly what i was saying i'm able to do with go.
- frou_dh 9y agoThe style I'm talking about, code isn't typed directly into the REPL/interpreter!! You work in your real text editor and it has a connection to a persistent session of the language runtime, over which you can send fragments, lines or whole files into. And receive data back if you wish. You can refine or replace as little or as much of the program as you want, while it is running. Say there's a power cut and your computer turns off. No big deal because you were working in your real text editor and saving source files to disk (but not necessarily sending all of their content into the session). It's not trivial or a novelty. I get that a traditional line-at-a-time interpreter inside a terminal à la /usr/bin/python isn't super compelling. That's not what I'm talking about. (I am also a happy user of Go FWIW. It's the C style of programming in a super-refined form (not surprising considering who 2 of its creators are!))
- ice109 9y ago>You work in your real text editor and it has a connection to a persistent session of the language runtime, over which you can send fragments, lines or whole files into. And receive data back if you wish. You can refine or replace as little or as much of the program as you want, while it is running. ...that's even closer to the style that fast compilation lends itself to
- frou_dh 9y agoAlright, I get it. You're not interested in the subject I brought up.