Earlier quoted context omitted.
I worked on a language once (now dead) which even had a syntactically valid form for parse errors, which allowed a structured editor to record a valid AST at all times. The "parse error" expression just raised a "parse error" exception at runtime, so you could even execute ill-formed expressions. It turns out to be fantastically empowering.
Which language?
Pretty Lisp
111–115 of 115 posts
Re: Pretty Lisp
#112Earlier quoted context omitted.
This sounds like the kind of work that most people I know would choose matlab for (image segmentation). I personally have never used either for such, but do you have any thoughts on the matter? Is Mathematica getting better at the things matlab used to be best at?
I think most people you are know are just ignorant of how much better Mathematica is. It's okay. People like to stick to what they know.
Being more of a software engineer than a mathematician, and having no MatLab experience, and more basic Mathematica experience. That is, in fact, the the impression that I get. But I still see people using MatLab what seems like more often, and have no weight to backup my claim. I suppose I could learn both and do research, but in general, that seems so less important than getting actual work done.
One aspect that seems to be brought up about MatLab often is the community, it's often claimed, especially in the co punter vision world, that if an algorithm exists, it has an available implementation in MatLab source. Which seems significant.
Re: Pretty Lisp
#113Earlier quoted context omitted.
> how visually distracting the parentheses are (and yes, experience Lisp hackers learn to tune them out; that doesn't change the fact that they are visually distracting I wouldn't call myself an experienced Lisp hacker, but I don't think the parentheses are visually distracting, any more than I think that the curly braces in C are distracting. The only problem that I can really see with the parentheses-based S-expres…
Parentheses highlighting is only a half-solution -- I don't know if there's a Vim equivalent, but you could check out Paredit for Emacs.
After spending time with Paredit, all other code editing always seems so woefully limited. Transpose, for instance becomes very powerful when we are talking about blocks of code rather than simple syntactical elements.
Re: Pretty Lisp
#114Huh. I wouldn't call this pretty. Why do you need a box around everything? One of the arguments about Lisp is how visually distracting the parentheses are (and yes, experience Lisp hackers learn to tune them out; that doesn't change the fact that they are visually distracting); the boxes are even more visually distracting. To use Tufte's terminology, this is decreasing the data-ink ratio, not increasing it. Take a lo…
> how visually distracting the parentheses are (and yes, experience Lisp hackers learn to tune them out; that doesn't change the fact that they are visually distracting I wouldn't call myself an experienced Lisp hacker, but I don't think the parentheses are visually distracting, any more than I think that the curly braces in C are distracting. The only problem that I can really see with the parentheses-based S-expres…
> Even in Lisp, some sacrifices have to be made.
This makes me smile. It points out the concept that while Lisp, is in fact a programming language in that way that most are. After spending lots of time in it, it really can feel infinite in a way.
Re: Pretty Lisp
#115Earlier quoted context omitted.
I don't know. I don't think it exists yet. But have you ever seen an expert using etags/search/debugger/etc to bounce around a large codebase? The location of the functions in the file hierarchy doesn't matter at all. The important graph --the important graphs -- are latent in the code itself.
Bingo.
It makes you wonder why we store code in linear text files, when something more similar to a database seems a bit more apt.