Friday, January 22, 2010
Thursday, December 10, 2009
Giles Bowkett has a profound and entertaining blog-post, starting with some thought-provoking criticism of Joel Spolsky and Paul Graham; and then moving on to other questions of business models for blogging programmers.
Wednesday, December 09, 2009
Saturday, December 05, 2009
Another thing that I saw recently that looks pretty interesting : Fossil, a kind of source-control system with built in web-server and trac-like wiki and bug-tracking, all in a single executable file.
I've no time to play with this at the moment, but it looks very cute.
I've no time to play with this at the moment, but it looks very cute.
Wow! Dan Bricklin has still got it.
This is a really nice twist on the mobile notepad / todo list app. The UI looks brilliantly well thought through.
This is a really nice twist on the mobile notepad / todo list app. The UI looks brilliantly well thought through.
Thursday, December 03, 2009
Saturday, November 14, 2009
More of Joel Spolsky's smart understanding of "social software" as both social and software. Now StackOverflow evolves to become a smart online CV for recruiters.
Monday, October 19, 2009
Friday, October 02, 2009
Thursday, September 24, 2009
Wednesday, September 23, 2009
Saturday, September 19, 2009
Friday, September 18, 2009
To return to a theme I started many years ago, I commented on this excellent article about why web-site development has got so damned hard. (And remember when we all thought of web-apps as lighter and simpler than desktop apps? What happened?)
Anyway, here's my comment.
I think the problem is less the multiplicity of programming languages, than our insistence that we should always be separating our languages in different places.
This goes against the basic tenets of cohesion and coupling. We cluster unrelated activities together because they happen to have the same syntactic sugar, while separating tightly-coupled activities because half of them happen on the client and the other on the server. Why the hell should this implementation detail have to be reflected in our architecture?
What I'd like, controversially, is to be able to mix-and-match the languages within the same source file, grouping together the python, javascript, html and sql that actually has to work together in one place. I have no trouble dropping into regular expressions or similar DSLs from inside my main code, why should dropping into a layout or query language be different?
Anyway, here's my comment.
I think the problem is less the multiplicity of programming languages, than our insistence that we should always be separating our languages in different places.
This goes against the basic tenets of cohesion and coupling. We cluster unrelated activities together because they happen to have the same syntactic sugar, while separating tightly-coupled activities because half of them happen on the client and the other on the server. Why the hell should this implementation detail have to be reflected in our architecture?
What I'd like, controversially, is to be able to mix-and-match the languages within the same source file, grouping together the python, javascript, html and sql that actually has to work together in one place. I have no trouble dropping into regular expressions or similar DSLs from inside my main code, why should dropping into a layout or query language be different?
Monday, September 14, 2009
Saturday, September 12, 2009
This is an absolutely brilliant summary of the virtues of PHP.
The important point is that these virtues aren't going away. By comparison this seems to miss the point. In 2020 we won't be programming the web with an advanced Python framework (wonderful as python is). We'll have something which does what PHP did for CGI or Processing does Java, ie. wrap a purpose built, sophisticated back-end (something like Google Application Engine) in a light, domain-specific language. That language won't look like PHP. It would be nice if it looked like Python, but I suspect Javascript is a more likely model.
But it will retain the virtues of PHP : none of this fussy separation of presentation and logic; easy discoverability of where URLs go; fast iterative development; big built-in library etc.
(Hat-tip, BillSeitz for the links)
The important point is that these virtues aren't going away. By comparison this seems to miss the point. In 2020 we won't be programming the web with an advanced Python framework (wonderful as python is). We'll have something which does what PHP did for CGI or Processing does Java, ie. wrap a purpose built, sophisticated back-end (something like Google Application Engine) in a light, domain-specific language. That language won't look like PHP. It would be nice if it looked like Python, but I suspect Javascript is a more likely model.
But it will retain the virtues of PHP : none of this fussy separation of presentation and logic; easy discoverability of where URLs go; fast iterative development; big built-in library etc.
(Hat-tip, BillSeitz for the links)
Saturday, August 22, 2009
Sunday, August 09, 2009
A quick thought ... working with a lot of Django and Pinax at the moment, I'm seeing a lot of use of Python's varargs. Functions that just take *argv, **kwargs
I find I don't like this. I want to see argument lists as explicit as possible. I feel uncomfortable and a bit lost. I feel unprotected when the compiler can't even check the number of arguments I'm sending.
So I wonder if this is legitimate. Or isn't it analogous to the case of static typing? Varargs give more flexibility than fixed arguments. Much as dynamic typing is more flexible than static. So why shouldn't I prefer the power and flexibility over restriction and security in this case?
Update : Of course, this is the way that GeekWeaver works, where there's no explicit definition of the list of arguments passed to a reusable block. I've been unhappy with that there too. Thinking that I should add positional explicit named arguement lists. But if this kwargs thing is a trend, then GW should probably be left as it is.
I find I don't like this. I want to see argument lists as explicit as possible. I feel uncomfortable and a bit lost. I feel unprotected when the compiler can't even check the number of arguments I'm sending.
So I wonder if this is legitimate. Or isn't it analogous to the case of static typing? Varargs give more flexibility than fixed arguments. Much as dynamic typing is more flexible than static. So why shouldn't I prefer the power and flexibility over restriction and security in this case?
Update : Of course, this is the way that GeekWeaver works, where there's no explicit definition of the list of arguments passed to a reusable block. I've been unhappy with that there too. Thinking that I should add positional explicit named arguement lists. But if this kwargs thing is a trend, then GW should probably be left as it is.
Wednesday, July 29, 2009
Two links I need to read but haven't got to yet.
Martin Fowler on Illustrative Programming
Dion Almaer on coding in more than 2-D.
Martin Fowler on Illustrative Programming
Dion Almaer on coding in more than 2-D.
Subscribe to:
Comments (Atom)