Favorite Language/Editor Features
8 comments
1. Didn't APL try something like this? Special characters sound like a win. Super/subscript notation sounds like a lose (syntactic regularity, readability).
2. The first part sounds like a win for readability, but I think this might be a net lose because it could be harder to navigate with the keyboard,but maybe I'm just not using my imagination. Worse is the addition of syntactic complexity, which makes metaprogramming harder. It wouldn't be a problem if it was just a macro that compiles down to regular syntax. I'm not sure what you're talking about in the second part - probably due to my lack of experience with Java and C#. Are you saying you want the editor to display these objects in a special way?
3.
4. Detecting and modeling arbitrary, informally specified state machines in code would be hard. Creating a library that provides a DSL for making state machines and displaying visual representations sounds fairly easy.
5. I'm not sure if you're asking for something like Common Lisp's macroexpand function, or Slime's disassemble command. I'm pretty sure it's one or the other - maybe both.
The notion of language support for provably correct programs (the type systems in ML and Haskell are a step in this direction) is very interesting to me, but I'm not sure it's ideal for a production language.
2. The first part sounds like a win for readability, but I think this might be a net lose because it could be harder to navigate with the keyboard,but maybe I'm just not using my imagination. Worse is the addition of syntactic complexity, which makes metaprogramming harder. It wouldn't be a problem if it was just a macro that compiles down to regular syntax. I'm not sure what you're talking about in the second part - probably due to my lack of experience with Java and C#. Are you saying you want the editor to display these objects in a special way?
3.
(set-macro-character #\~
#'(lambda (stream char)
(random (read stream t nil t))))
CL-USER> ~40
25
CL-USER> ~40
18
4. Detecting and modeling arbitrary, informally specified state machines in code would be hard. Creating a library that provides a DSL for making state machines and displaying visual representations sounds fairly easy.
5. I'm not sure if you're asking for something like Common Lisp's macroexpand function, or Slime's disassemble command. I'm pretty sure it's one or the other - maybe both.
The notion of language support for provably correct programs (the type systems in ML and Haskell are a step in this direction) is very interesting to me, but I'm not sure it's ideal for a production language.
Thanks for your comments! To continue the discussion:
1. A[i] and Ai (that should be subscript) seem pretty similar to me, but I like Ai more, it just seems cleaner. In C# we can write A[i,j,k] for multidimensional indexers, but tensor script seems cleaner still. Again, I think this really depends on background -- someone who actually deals with tensors might find my proposal more attractive. I'm just driven up the wall when I have to write A[i][j][k]. It's so wasteful.
2. I'm not sure if it would be harder to navigate with a keyboard -- it seems like something that you'd have to build first and get used to. The idea of implementing these things as macros which compile down to regular syntax really appeals to me, in fact it's what I had in mind. (C++ has awkward features to do this in the STL with templates, and numerous TopCoders include C macros to expand summation, product, or accumulator functions. If they're useful in the heat of the moment, why not in regular usage?)
3. Nice. Thanks. At some point I'll have to take on another big product in LISP, I haven't really touched it since I went into scientific computing, and I think my opinion of it was colored by the bare-bones Scheme I was using.
4. "Detecting... would be hard" -- it doesn't have to be perfect. I mean, if it was perfect, implicitly it would mean 'graphically model arbitrary code'. I'm thinking there are a collection of schemes which might find maybe 80% of what people would call state machines which aren't so bad. Maybe 80% isn't satisfying, but it's a start. Like bug catching codes in compilers, it won't work all of the time, but maybe it's not necessary.
It might be easier to reach at it via making a creation and display layer though, you're right.
5. It seems like macroexpand is basically what I'm looking for -- at least it's powerful enough to do what I want it to do without too much pain. I'm unfamiliar with Slime's disassemble command, and the first Google page was unhelpful...
As for language support for provably correct programs, they sound interesting to me, too. They should definitely not encompass the whole language though. To be honest I'm not really sure that the mathematics is where it needs to be. So many proofs rely on obvious things, not 'obvious' in the naive sense, but actually obvious, and it seems like such a pain to program these in that provably correct systems are impossible to use, at the moment. Yet, Doron Zeilberger seems to think otherwise.
I don't know how to escape the problem of infinite regress, or, set differently, Godel's incompleteness theorem. Any sufficiently powerful proving system we have is unable to prove it's own consistency, so, as someone who is admittedly unfamiliar with this territory, I don't see where the starting point is for so called provably correct programs.
What would you guess the next step in the right direction is?
1. A[i] and Ai (that should be subscript) seem pretty similar to me, but I like Ai more, it just seems cleaner. In C# we can write A[i,j,k] for multidimensional indexers, but tensor script seems cleaner still. Again, I think this really depends on background -- someone who actually deals with tensors might find my proposal more attractive. I'm just driven up the wall when I have to write A[i][j][k]. It's so wasteful.
2. I'm not sure if it would be harder to navigate with a keyboard -- it seems like something that you'd have to build first and get used to. The idea of implementing these things as macros which compile down to regular syntax really appeals to me, in fact it's what I had in mind. (C++ has awkward features to do this in the STL with templates, and numerous TopCoders include C macros to expand summation, product, or accumulator functions. If they're useful in the heat of the moment, why not in regular usage?)
3. Nice. Thanks. At some point I'll have to take on another big product in LISP, I haven't really touched it since I went into scientific computing, and I think my opinion of it was colored by the bare-bones Scheme I was using.
4. "Detecting... would be hard" -- it doesn't have to be perfect. I mean, if it was perfect, implicitly it would mean 'graphically model arbitrary code'. I'm thinking there are a collection of schemes which might find maybe 80% of what people would call state machines which aren't so bad. Maybe 80% isn't satisfying, but it's a start. Like bug catching codes in compilers, it won't work all of the time, but maybe it's not necessary.
It might be easier to reach at it via making a creation and display layer though, you're right.
5. It seems like macroexpand is basically what I'm looking for -- at least it's powerful enough to do what I want it to do without too much pain. I'm unfamiliar with Slime's disassemble command, and the first Google page was unhelpful...
As for language support for provably correct programs, they sound interesting to me, too. They should definitely not encompass the whole language though. To be honest I'm not really sure that the mathematics is where it needs to be. So many proofs rely on obvious things, not 'obvious' in the naive sense, but actually obvious, and it seems like such a pain to program these in that provably correct systems are impossible to use, at the moment. Yet, Doron Zeilberger seems to think otherwise.
I don't know how to escape the problem of infinite regress, or, set differently, Godel's incompleteness theorem. Any sufficiently powerful proving system we have is unable to prove it's own consistency, so, as someone who is admittedly unfamiliar with this territory, I don't see where the starting point is for so called provably correct programs.
What would you guess the next step in the right direction is?
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.
Graphical programming would be a 'killer app' for any language that can implement it first. Reasoning about code visually will not only make programming more accessible, but it will allow us to apply spatial reasoning skills to the task of writing applications. Flow-based programming seems to have the best chance of getting this sort of thing off the ground: http://www.jpaulmorrison.com/fbp/
Sorry to sour your future-casting, but this "killer app" has been a non-starter for many many years. Except for some niches where the flow of data is the primary thing you want to express, visual languages are too cumbersome. See http://en.wikipedia.org/wiki/Visual_programming_language
Domain specific graphical programming:
http://en.wikipedia.org/wiki/Max/Msp ;
http://en.wikipedia.org/wiki/Pure_Data
For a graphically based programming concept that webpage is curiously wanting of graphical examples...
Ideally I'd like something that one could insert into an existing language, so that it would gain usage quickly. (I'm betraying certain intentions already...)
Ideally I'd like something that one could insert into an existing language, so that it would gain usage quickly. (I'm betraying certain intentions already...)
My favorite feature is "i", followed by ":w".
What are your favorite language or editor features, or what would you love to be able to use?
Some of my favorites are closures, dynamic typing, mix-ins, and functions as first order objects. Originally these were just neat features, but I've found myself using them as the best way to express my ideas in code, even in a contest situation. Actually, C#'s anonymous delegates are the reason I use it in contests, despite generics being quite a bit weaker than templates (superficially they seemed as powerful, but as a scientist the first thing I would want to do is code numerical routines in a generic fashion, and guess what -- you can't even ensure that a certain class can use regular operators. This really bugs me.)
I'll also admit to being swayed by Paul Graham's Essays, and I'd love to try out some of the interesting macro hacks that he speaks of, but so far I haven't had many opportunities to do so.
There are a few dream features I'd love to use, even though I'm not sure if they'd be altogether useful. I've just never seen them before, and I figure that language/editor design is something fun enough that I'd like to throw them out there to see what people have to say.
There's a pattern running through most of these requests, namely that programming languages seemed to have evolved and entrenched themselves at a time when terminal capabilities enforced a text-only approach to programming. Now we have real-time 3D games producing life-like imagery, but for some reason, programming has only incorporated such features into a layer on top of the languages (like the facilities in ReSharper, which has made my programming much more enjoyable). I want to know how much farther you can push things.
1. Support for different fonts and symbols, native to the code, and extremely accessible to the editor.
This might just be my background in math, but I'd love to declare my variables using Greek letters, declare a function using a big beautiful, curly, math blackboard font F, write case statements using a curly brace { and conditionals on the right side, access array fields with subscript notation -- or tensors using super/subscript notation, and have all of that shown to me graphically.
Again, I'm not sure if it's just my background, but when I see people sketching out a program on a blackboard, or on scratch paper, or formatting it for publication, it doesn't look like code, but much more like formulas. They don't use massive variable names -- they declare these once, like in documentation, and then proceed to think using this extremely compressed language, with one letter identifiers and mathematical notation. I don't know why languages haven't done this yet. (Edit: actually this might be a good jumping off point. Scoped aliases, which would work like c-macros, not references, but they'd be scoped)
2. Support for mathematical notation like summation (the Sigma symbol), or products, or set operations, and so forth, in the code. I also think a facility to distinguish between enumerable, comparable, and hashable objects and data structures might be a win, but it seems quite heavy-weight.
3. Easy and straightforward access to random numbers and characters within a range, in the code. It's no secret that random numbers are useful for a wide range of problems. They're so useful that it seems silly that every time I want one, just any old random number, that I must declare a randomization object, then type Rand.Next(0,100) or whatever. Why can't I write ~(0,100) or something?
4. A graphical representation of state machines. Over and over again, state machines seem to drastically simplify a large number of otherwise difficult problems. We can work these out on paper, but then we can't ship them with the code. Or we can use some external program to draw things for us, and then ship the doc with the code, hoping that people will read it, and not let it get out of sync. Why not have simple facilities for writing or detecting state machines, and then graphical representations of them? With facilities like Yield, Iterators, and object wide booleans, we're halfway there.
5. Interactive compilation. I don't just mean like a regular interpreter, I mean something more like when in Mathematica or Maple, you type in a command, hit the enter button, and it produces something that the program compiles down to. "What's the derivative of some long expression?" Write it, take the derivative, and it tells me. I want to be able to ask, "What code is produced when I pass this closure to this function?" Write it, hit enter, and it should be able to say.
Do you guys have any other dream features? Anything so good that it would compel you to try a new language? Why?