It seems to me that these are separate pursuits. I suppose that if the community is smart, they will pick reasonable programming articles as well, and the two can overlap harmlessly; my worry is that smart programming communities if not given an explicit focus (e.g. Lisp, Haskell) quickly deteriorate into non-smart programming communities (witness programming reddit). This may be true for startup news communities as well, but I haven't witnessed it yet.
Definitely a valid opinion but I think it's a submission that many of the readers here will enjoy. Remember that this forum caters to a largely technical audience, and an audience that enjoys hearing about different ways of developing their products.
True, its not startup news, but it is a moderately interesting article, and obviously the community loved it. Well, that or they were trying to suck up to pg. ;)
Not a bad explanation of macros. I'm not experienced enough here to really judge how good, but I grokked it at least. It does seem though that you an approach this type of power with some of the dynamic features of Python. Am I wrong here? I think it's likely I'm missing the subtlety of macros.
I'm rusty on my Python, but I'd have to guess that no, Python's dynamic features don't get you the kind of power that Pascal's talking about. The key thing to realize is that any particular feature that your language has doesn't necessarily matter. For example, Python may happend to have a built-in way of doing
(with-input-file (in "myfile.txt")
(do-something in))
In Python, this might look like
withInputFile in "myfile.txt":
doSomething(in)
(hey, I told you I was rusty on my Python...especially my totally made up Python!)
So maybe the feature came built-in to Python, in which case you're lucky--Guido happened to decide to implement this feature. But what if he hadn't? Well, just write your own abstraction. Obviously, Python can open files and do stuff with the file's contents. So it seems logical that you should be able to create an abstraction which saves you from writing the same boilerplate that you do every time you open an input file. Unfortunately, there are some abstractions that *you just can't write* in most languages (including Python). This file open example is a good one. Here's another example, in the form of a programming challenge:
In Python, create an abstraction called "debugExpr" that consumes an expression E, and then does two things:
1) prints "Expression E = V", where E is the given expression, and V is the value E evaluates to.
2) returns the value V.
For example,
%python% 6 * debugExpr(2+3)
Expression 2+3 = 5
30
I'm betting you can't implement debugExpr in Python. So assuming Guido didn't extend the language to implement this feature, you're pretty much SOL. It's a shame because debugExpr, I think, is pretty darn useful. It means that you can take any expression in your code and "inspect it", without worrying about adjusting the structure of your program, and without affecting its semantics. Without debugExpr, I'd have to change my example code to be something like this to get the same result:
Well actually Python does have an eval() that can be called on expressions in the form of strings. The problem is that any potential macro anything would be nowhere near as seamless as it in Lisp, since the parse tree isn't right there for everything. But with enough effort (and closing your eyes to avoid how horrible it would look), you could maybe make something.
I'm not sure. I think scoping would screw you up. First off, there's a small reason right away why it wouldn't work. You'd have to quote your argument to debugExpr, as in, say, debugExpr('2 times 3'). I did a little test at the Python prompt and the results didn't look good for faking this macro with eval:
def foo(x):
return 2 times (x + 3)
> foo(1)
8
(not a full version of debugExpr, but enough to test:)
def debugExpr(expr):
print "Expr is " + expr
return eval(expr)
def bar(x):
return 2 times debugExpr('x + 3')
> bar(1)
Expr is x + 3
Traceback (most recent call last):
File "", line 1, in ?
File "", line 2, in bar
File "", line 3, in debugExpr
File "", line 0, in ?
NameError: name 'x' is not defined
PS: I couldn't use the asterisk symbol in the post, so I used 'times' instead.
You CAN do it procedurally; in fact, you can do it in Brainfuck, since Brainfuck is Turing-complete. The point is, macros let you stop repetitively writing the same boilerplate code, and let you get down to the point.
