4 ms·
I hope my comparison with Visual Basic didn't come out as derogatory. Because, at the risk of no sane programming talking to me ever again, I will admit that I
by weland 12y ago
I hope my comparison with Visual Basic didn't come out as derogatory. Because, at the risk of no sane programming talking to me ever again, I will admit that I really do admire it! It wasn't built in a period that would have allowed it to live on today (not without significant effort from Microsoft...) but hey, it was nice for its time.
I made this lengthy introduction because I really like LightTable. What you folks are doing is impressive! I'm not particularly fond of the tech stack behind it but it's the first significant, organized kick in the tools' butt I've seen for many years now that isn't confined to academia.
> There is an implicit assertion here that not having a debugger makes you a smarter programmer.
The implicit assumption I'm making if that I were a smart (and careful!) enough programmer, I wouldn't need a debugger :-).
So yeah, if I had the choice between being so good that I don't need a debugger and having a really, really good debugger, I'd pick the former any time. Sadly, that's not... quite a choice, so I'll grumpily let gdb tag along.
> The whole point of having a computer is that it can do some of the thinking for you.
This is something to be enthusiastic about, certainly! I was glancing over Moseley and Marks' paper (I read it a while ago, but not too carefully) and, now that I think about it, the mantra about writing simple programs is held in highest esteem by communities that traditionally had to struggle with their tools (Unix, because 1970s, and more recently the web folks, because they were building complex web applications long before JavaScript had anything that would even resemble a reasonable debugger). Much of this was done so as to eschew the limitations of the platforms themselves. PDP-11/20 had 64 KB of addressable RAM; the fact that you could write and compile programs on it alone was remarkable. Letting the computer take some of the thinking load was quite certainly impossible.
I'm still debating with myself whether allowing the computer to do some of the thinking for me would be good for the quality of my programs. I'm a very clingy father :).
> The goal is not for Anon to learn to program, it's to build lunch_app.
I don't wish to sound rude, but this sounds like a lump made by marketing types :-). Is lunch_app a program? If so, Anon has to learn at least the basics of programming, much like someone who builds a desk has to learn at least the basics of carpentry or someone who wants to learn to play a musical instrument has to learn at least the basics of music.
More helpful tools will definitely help Anon, but there are things no tools will, or should, do for him: he will still have to understand how web applications are served, how they are hosted on the same server along with other applications and so on. Not knowing these things will be a lot more detrimental to everyone using his application than spending a couple of weeks learning all this boring stuff will be to Anon.
- porker 12y ago> I don't wish to sound rude, but this sounds like a lump made by marketing types :-). Is lunch_app a program? If so, Anon has to learn at least the basics of programming, much like someone who builds a desk has to learn at least the basics of carpentry or someone who wants to learn to play a musical instrument has to learn at least the basics of music. Isn't this the destiny of most software☨, and another step along the craft to utility curve [0]? Software of this type is needed to do a chore, and honestly if the tools are in place, it could be re-created in an afternoon rather than extended when the time comes. I would use the analogy of printing; we used to need a typesetter and go to a printer; now we select a font, type and hit 'print' and - if the damned printer on our desk cooperates - we get our work back. Websites are reaching this level of utility; there's no reason simple web apps or desktop software won't too. [0] This graph http://1.bp.blogspot.com/-lrxB3ntRzKQ/U05ClSIXwGI/AAAAAAAAEyI/a9Qd-cl456w/s1600/Screen+Shot+2014-04-16+at+09.40.43.png http://1.bp.blogspot.com/-lrxB3ntRzKQ/U05ClSIXwGI/AAAAAAAAEy... taken from http://blog.gardeviance.org/2012/06/pioneers-settlers-and-town-planners.html http://blog.gardeviance.org/2012/06/pioneers-settlers-and-to.... The graph matches what I see in the web industry; his blog is a fun read ☨ Because thinking of all software ever written, including scripting for automation, the really complicated and large and needing well-engineered software is far less common than we sometimes think, and not what someone like Anon is considering building with these tools.
- weland 12y ago> Software of this type is needed to do a chore, and honestly if the tools are in place, it could be re-created in an afternoon rather than extended when the time comes. I agree that it's supposed to do a chore, so it should be as easy to churn it out as possible. However, if we were to follow your printer analogy, the proper way to do that with a printer would be to just build a machine that makes it very easy to create a custom printer that types out exactly what you want it to type out! What we have instead is a very general typesetter that can be convinced to print a particular picture (by feeding it an automatically-generated program in e.g. PS!). The application in question is pretty much a simple CRUD that generates a report in the end so that whoever is ordering knows what to order and from where. IMHO, just like printing doesn't require the user to know PS, this should not involve programming. It's not that programming should be easy, it's just that the CRUD model is so easily understood and so orthogonal that building one should not require anything more than a wizard asking you about the data it should collect.