Re:Favorite Language/Editor Features
by Zak on Sunday October 07, 2007 @03:48PM
(#64500)
1, 2. I think it would be nice if editor support made it easy to switch back and forth between math notation and standard syntax.
3. Lisp is nice, but the implementations have issues. I'm mostly satisfied with SBCL at the moment, but I keep writing utility functions to get around the warts in the language. Languages seem to be an instance of the "all X sucks - some just sucks less" pattern.
4. I think providing explicit support for state machines would be a Good Thing even without the visualizer.
5. Something that lets you look at an expression as you step through evaluation and substitution would be useful. Macroexpand does this at compile-time, but I want something similar at runtime for parts of the expression that aren't macros. I suspect something like this exists, but I haven't seen it yet. Slime's disassemble takes the name of a function and displays the corresponding assembly code in a buffer.
I agree that it's not practical at this point to try to completely prove the correctness of programs; I think it's more useful to prove specific aspects of a program as an alternative or supplement to tests. It's also useful to make assumptions about things you can't prove in the mathematical sense but can rely on when writing or running a program.
What's next? I've been meaning to download and try out Qi, a language that builds on top of Common Lisp and has a type system based on sequent calculus. It looks like Qi allows users to start with fairly general types and narrow them down as the program develops.
I didn't enjoy OCaml when I spent a couple days trying to learn it. The restrictions of the type system were frustrating, though I did get the feeling that it's a much better way to keep people from breaking stuff in a "software engineering" situation than using Blub.
3. Lisp is nice, but the implementations have issues. I'm mostly satisfied with SBCL at the moment, but I keep writing utility functions to get around the warts in the language. Languages seem to be an instance of the "all X sucks - some just sucks less" pattern.
4. I think providing explicit support for state machines would be a Good Thing even without the visualizer.
5. Something that lets you look at an expression as you step through evaluation and substitution would be useful. Macroexpand does this at compile-time, but I want something similar at runtime for parts of the expression that aren't macros. I suspect something like this exists, but I haven't seen it yet. Slime's disassemble takes the name of a function and displays the corresponding assembly code in a buffer.
I agree that it's not practical at this point to try to completely prove the correctness of programs; I think it's more useful to prove specific aspects of a program as an alternative or supplement to tests. It's also useful to make assumptions about things you can't prove in the mathematical sense but can rely on when writing or running a program.
What's next? I've been meaning to download and try out Qi, a language that builds on top of Common Lisp and has a type system based on sequent calculus. It looks like Qi allows users to start with fairly general types and narrow them down as the program develops.
I didn't enjoy OCaml when I spent a couple days trying to learn it. The restrictions of the type system were frustrating, though I did get the feeling that it's a much better way to keep people from breaking stuff in a "software engineering" situation than using Blub.