Ulf Wiger has been experimenting with making Erlang indentation-senstive. He followed up with a Part 2 after comments.
For most people who start working in the Erlang language, the most annoying new concept is all the various line-terminators you have to know. Damien Katz sums this up nicely. All these explicit terminators might make other people's code easier to read but writing code should be easy too (they are equally important). Mue says just get over it but as a Python user I agree that Erlang would be way better off if it was indentation-based so this was an interesting experiment.
As for Python, I'm still shocked to hear people say "Python would be nice ... if it wasn't for that whitespace thing." Who is perpetuating this? I have no idea. The next time you hear someone say this, pass along Python: Myths about Indentation!
Re: Making Erlang indentation-sensitive
posted by Augie on Monday Apr 28th, 2008 at 8:22p.m.
WRT whitespace, it's not that it uses whitespace, it's that it doesn't use curly braces, at least for me. I still find that the blocks are clearer when doing a visual scan in C or Objective-C (those being my curly-brace languages of choice) than in Python, where I have to work a bit harder mentally.
And with the Erlang syntax, I actually did get used to it, and was wondering one day in Python where the commas and periods where. It actually helped my brain parse the code a little. Maybe I'm just crazy though.
Re: Making Erlang indentation-sensitive
posted by sapphirecat on Tuesday Apr 29th, 2008 at 9:11p.m.
The one real argument I can see against Python indentation is that you can't use vim's = command to autoindent a region, because vim doesn't know when you meant any of the blocks to end. So it looks clean, but it does require more fiddling than other languages.
Re: Making Erlang indentation-sensitive
posted by Kumar McMillan on Tuesday Apr 29th, 2008 at 10:46p.m.
I would be shocked and surprised if vim doesn't support autoindent for Python (every other editor I've used does: emacs, TextMate). A quick google search brought up this:
http://www.vex.net/~x/python_and_vim.html
Re: Making Erlang indentation-sensitive
posted by gömlek on Wednesday Nov 5th, 2008 at 6:57a.m.
Alex, fett covered the Circle/Eclipse issue pretty thoroughly, so I'll just add that your extension should be more of a Circle extends Shape, Eclipse extends Shape, if in fact there is a need for sub-classing at all.
The Observer I'll touch on though as it's an interesting pattern with a pretty tough call on when to use it. Observers and Visitors are actually very, very close in implementation, with one exception. The Observer implies that it needs updates on every change of the state of an object, while the Visitor only wants to be invoked on occasion. In the example above, publishing data, that qualifies as a do once event. To be true to the Observer pattern, every time the Event object's location changed, the registered Observer should be notified so it can determine whether it wants to do anything with the current state.
Assuming the ability to work with an Event at each step is desired, the Observer might be the better choice, but in the example above I would stick with the Visitor pattern as it answers a much more specific problem. I'll also venture a guess that a lot of the implementations of the Observer pattern would probably be better stated had they been expressed via a Visitor.
sapphirecat: yup... :-) What makes it even more fun is when you override the method to change functionality so now publishTo() doesn't even call the original publishTo() at all.
Re: Making Erlang indentation-sensitive
posted by toplist on Wednesday Nov 5th, 2008 at 6:57a.m.
Alex, fett covered the Circle/Eclipse issue pretty thoroughly, so I'll just add that your extension should be more of a Circle extends Shape, Eclipse extends Shape, if in fact there is a need for sub-classing at all.
The Observer I'll touch on though as it's an interesting pattern with a pretty tough call on when to use it. Observers and Visitors are actually very, very close in implementation, with one exception. The Observer implies that it needs updates on every change of the state of an object, while the Visitor only wants to be invoked on occasion. In the example above, publishing data, that qualifies as a do once event. To be true to the Observer pattern, every time the Event object's location changed, the registered Observer should be notified so it can determine whether it wants to do anything with the current state.
Assuming the ability to work with an Event at each step is desired, the Observer might be the better choice, but in the example above I would stick with the Visitor pattern as it answers a much more specific problem. I'll also venture a guess that a lot of the implementations of the Observer pattern would probably be better stated had they been expressed via a Visitor.
sapphirecat: yup... :-) What makes it even more fun is when you override the method to change functionality so now publishTo() doesn't even call the original publishTo() at all.