Hacker News new | past | comments | ask | show | jobs | submit login
I'm working on ways to better convey the global structure of programs (2013) (akkartik.name)
16 points by jacquesm on Sept 16, 2014 | hide | past | favorite | 9 comments



This seems very vague. How would this be implemented?

Programming is definitely a specialized skill set but it is easily learned given time. Anything worthwhile takes time and effort. Technology can make it better but there is no substitute for skill and knowledge.

"a virtuous cycle where using a dependency gradually causes one to learn its internals". This is pretty much how it works when any programmer starts using a new code base. Isn't this also how learning any new skill happens? Why not just learn to program? It is increasingly becoming as important as the ability to read.

It takes a lot less time to learn to program than it takes a child to learn to speak his/her first language.


Author here. I know how to program, I've been doing it a long time. And yet learning a new codebase feels like learning a new language. And it doesn't help much in understanding the next new codebase. Maybe that's just how things have to be. I'd like to see if a better way is possible, if it's possible to learn faster by starting not with code but with scenarios that look like log files. "Welcome, newcomer. This is a text editor. Here's an edited sequence of events that happen when a key is pressed. Click on any line to locate it in the codebase, and to find some other scenarios that print it." Something like that, but easy enough for authors that such scenarios are actually created and kept updated. I have more details in a couple of the posts linked at the end: a) http://akkartik.name/post/wart-layers, and b) http://akkartik.name/post/tracing-tests. But yes, the article is a year old, and I hope to have something more concrete soon.


You're hinting at traceability. This might give you some ideas. http://worrydream.com/#!2/LadderOfAbstraction

Definitely watch his videos and read his other posts. I think it will be of interest to you.

I've had similar ideas but my philosophy is that we should store code as an annotated AST and that we should provide users with different editing techniques for each different programming task. If you think about how physical objects or buildings are constructed, they have multiple views (top down, wireframe, rendered, walk-thru, electrical, plumbing, etc) and can be manipulated at different levels. However with programming, it is pretty much 1 level (source code in raw text).


Yes, I'm very influenced by Bret Victor: http://akkartik.name/search_results?q=%22%26mdash%3B+bret+vi...

Yes, your goal is worthy as well. I'm interested to hear more about it, but maybe we should take it offline. My email is in my profile; feel free to get in touch.



I wasn't aware of MPS (thanks for the link), but I've spent some time thinking about DSLs. My previous project was about a DSL-friendly language: http://akkartik.name/post/wart. But I've since moved on to the view that you can't fix programming with just a new language.

I've read everything I could find about Simonyi's work, but it's hard to get a good feel for it without playing with an actual system. I worry that it will be good when it launches, but gradually degrade over time because there's just too much code and people gradually don't understand it.

We have fifty years of experience building good interfaces. But the implementations behind the interfaces have a way of gradually rotting as people leave and new implementors take their place. I'm focusing on the complementary problem of transmitting implementation knowledge more efficiently.


Author here. Maybe now people will tell me why this whole thing is ill-founded, and I can go work on something else :)


This is an excellent idea - you should spend at least one lifetime on it.


I think it's a super idea. The reading/writing comment you made the other day really clicked for me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: