vinodkd

I've been keeping journals for all my personal projects for quite some time now because I find it useful to "get context" when I go back to a particular project after some time. So something like this certainly piques my interest.

My journal is usually a journal.md at the root of the project, like so: [1]. It has a very simple format: datetime stamp, text. Sometimes I use bullets and indented text, but its usually prose or code.

Do you want to consider pulling journal updates directly from people's github as a feature? Of course, my kind of journal is a little too detailed - intended for me to pick up when I get back, but maybe a publicjournal.md which would be the author's ready-for-public-consumption version of the journal?

[1]https://github.com/vinodkd/halo/blob/master/journal.md

Also see http://concrete-editor.org/ (not my project, just linking to something I found cool)

Concrete does tree based editing with projections (a la Intellij Meta/ Simyoni's Intentional) so you can see visual layouts of state machines, etc that are just as editable as the textual ones.

#3 is why text still wins. text has high information density, which helps when you have lots of code to deal with.

That, and the fact that every environment has a text editor - especially terminal consoles.

You can overcome the second factor, but you cannot overcome the first one that easily.

There is an augmented programming group that discusses structured editing and alternate program creation environments; maybe that's a place to start?

https://groups.google.com/forum/#!forum/augmented-programmin...

disclaimer: i joined when the group started, but havent been active. i'm perennially interested in the structured editor concept, so cannot resist responding every time it surfaces on HN.

This is not half bad as structural interaction goes. Kudos! It took me a while to figure out how to add a new node, but once I did find the O command, it all made sense.

It still feels like a lot of work to get something written since you have to type "EscOPS<text>EscJT" to add "foo":true, instead of just cursor over to a place and just type exactly that string. However, I can see how one could get use to that much as how vim users are used to all those arcane keychords for basic navigation. Also, there's no reason a command string cannot be made into a macro.

Do you plan to open source this at all? Seems like a good start for someone to take and add on to.

Edit: found your github, nm.

this was strangely entirely grokkable, thanks.

i used word for a large project (undergrad project report of 100+ pages with 4 member team) in 1997 and even then word had features for most (if not all) of the items in your list:

* large docs can be handled by splitting them into master-child documents. You can format across all child documents from the master.

* figures can be edited in-place or embedded from original source.

* collaboration was possible then with child and shared docs, it should only be better now.

* citations and refs are supported, although I dont know if all styles of citations are.

* templates have been in word from a long time and imo are quite natural because they're prototype-based (ie, you can make any document AFTER you create it into a template. other documents that use that as a template inherit all styles and so forth)

* the visual "View changes"mode in word is quite natural and even allows for some offline discourse with your collaborators as each user's comments and changes are marked with a different color and comments are allowed.

*words symbol editor (which also existed pre-1997) is quite up to the task of most equations (again, imo; i've not done a lot of hairy equations)

word is just a better tool for large documents, and i say this asn ardent anti-ide guy. my preferred setup for code documentation is sublime text and markdown; but when you want to Just write a document, word it is.

J2EE is a monstrosity, but this also highlights the point that we should stop using Hello World as an example for everything.

Enterprise software is inherently about "big" systems - for some definition of big. Using Hello world as an exemplar only sets up a strawman ripe for ridicule.

That said, the J2EE community does have a somewhat larger commonly known sample app - the Petstore - which ended up being a way to beat up J2EE more or less.

i've done exactly that when i was in school. you can still do it. i believe turbo pascal/c is available even today and supports asm blocks directly, so you can do assembly programming in pascal/c.

Nice! I started on something like this a while ago: https://github.com/vinodkd/betterscript.

You have a slightly larger goal - a better js with some useful syntax from other languages/efforts. Mine was just a better javascript.

But: I did have a module syntax. No plug here, btw; feel free to borrow any/all syntax and kudos for getting it done:)

this looks awesome, but how do you deal with noise? If the use case is being able to process email when not explicitly doing that task, wouldnt it essentially be when you're waiting for the train or playing with kids or even around a noisy office?

I have a tough enough time with IVR systems today because of my kids talking in the background that I have to switch to touch tone mode.

How does this work in the real world?

True, such a feature should really be system-wide - something like OSX's Automator, maybe.

That doesnt take away from the point, however, that GUI actions can be stored in history, composed, etc.

Slightly off-topic, but the recent surge in responsive UI had me thinking thus: If we are now driven to merge UI logic across different graphical devices, can we think of apps that span both textual and graphical devices?

After all, the core functionality of the application remains the same. To use a simple example: when you search for a product online, get a search result list and then select one from the list, couldnt this flow be modeled just the same in both gui and text interfaces?

I'm thinking back to the turbo-pascal style applications of the past that produced full-blown IDEs in text, or the wordstars/wordperfects of yore: the UI model that sits behind those apps cannot be much different in principle from the modern day equivalents.

Even farther back, there was a time (and probably still is for college assignments) when cli applications had a prompt-read user input-respond cycle, replete with text-based choices to select from and so forth.

What if we were to merge the two worlds instead of trying to get one to confirm to the other?

well, not at that minute level, but every application worth its name has an undo log - and that's a pretty close functional equivalent, IMO.

And: applications that have Macro recorder features (Office and many text editors) allow you to actually record your actions - clicks or otherwise - into code that can be rerun.

My favorite bits from the video:

- Why should you think? Because it helps you do things.

- When should you think? Before you write any code.

- How should you think? By writing. "Writing is nature's way of letting you know how sloppy your thinking is". To think, you have to write. If you think without writing, you only think you're thinking.

- What to write? Write a specification. It can be simple or "mathematical prose" or a fully formal specification. A spec is simply whatever you write before coding.

- (00:44) Why write the spec? To be sure what the code should do before you write it.

- What code should you specify? Any code that someone else might use or modify. That someone could be future you.

He did talk about his TLA+ tool, but the points above were the thrust of this talk.

Here are some more:

1. http://slidetocode.com/

2. Thyrd: Which combines spreadsheet and infinite zooms in a very interesting way. http://thyrd.org/thyrd/. Some screenshots are at http://thyrd.org/thyrd/paper/, but the video works better to understand it.

i can attest to this. if you dont need to, please dont go down the path of building node-webkit.

Actually, its not so much node-webkit as chrome/webkit inside it. that took a few days to download correctly and then a few nights to build.

i did it when i was still on snow leopard and needed nw.

The real gem in lamdu compared to LT, Subtext,MPS etc is the integrated versioning, IMO. Far too long have we been doing snapshot-based development. I hope this is a language feature and not just an IDE feature, however, so that the evolution of the program is expressed within itself.

My takeaway from the article was exactly that: if you document anything, document the WHY, not the HOW. That way, when the HOW changes with time, the WHY will guide its new form.

Agreed on the quality of the article. As always, Rands manages to put the right perspective on the topic. I'm forwarding to quite a few process-averse folks I work with.

Previously on HN about 195 days ago : http://news.ycombinator.com/item?id=3877954

But why the repost - I ask? The last time it was arunoda, who seems to be a friend.

As somebody who'd love to post a pet project on HN sometime in the hopefully-not-too-distant future, I sorta get that you might want people to try your software and that maybe you'd like more eyeballs than you got the first time around; but couldn't you be explicit about it? I'm sure that something like "Guys, I know this has been posted before, but I'd like you look at it once again" would be more welcome and transparent.

Update: I read through the comments on that thread. THAT was a repost. This is the original: https://news.ycombinator.com/item?id=3862269 (199 days, poster: you)

Whats going on? Have you changed anything since then that you'd like to highlight?

this is an americanism, i think. not being one, when i first heard it, i found it confusing too.

what it means is that you put some money away for yourself (ie, pay yourself) before you spend it (ie, pay others).

if you're hearing it the first time, it sounds like the opposite of saving. i, for one, upon hearing it for the first time interpreted it as: "do something good for yourself, ie spend it on yourself" :)

Nice interface, although it took me a moment to figure out that the orange background was the caret.

One nit, however: although I'm a touch typist (having learnt typing on a typewriter), I've long since trained myself to type the braces together and then cursor-left to fill in the details. This I do for ()'s, {}'s, []'s and <>'s; as well as quotes. Similarly I type the C-style /* * / comments as the pair of /'s first, cursor-left, then two *'s, cursor left and finally the comment text. It started out in this mode only when I wrote code, but now I find myself doing the same even with normal text.

Not sure how many there are like me (a senior early in my novice days showed me the practice and it stuck), but it always seemed like a simple way to ensure no dangling parens (assuming you're using "just an editor" like I do).

Could you allow for cursor-lefts to correct instead of just backspace?

since nobody has posted it yet, here's the obligatory link to an old esquire article that takes this idea to the extreme. Presenting: "My life outsourced" http://www.esquire.com/features/ESQ0905OUTSOURCING_214

exactly. if only google didnt think they needed to capture the / for their search (in the main site, gmail etc), this extension wouldnt be required.

if you're interested in visual programming environments and try to look up prior efforts at all, you WILL find this sentiment to be true. It's somewhat depressing actually. You'll not just find all these cool sounding environments from the 80s that seemed light years ahead of today (or even something like Light Table), but you'll also find studies on the difficulties people faced with them and why they failed.

Text is not an easy thing to dislodge from the programmer's toolset.

My personal opinion keeps switching between "Text is basic and elemental, so it's the most natural way to represent code and therefore is the preferred" and "We havent built tools good enough or representations revolutionary enough (or scalable enough) and that's why text remains preferred".

I can see how someone who's built a non-textual programming environment can come to a "been there, done that" kind of attitude. Just take his enthusiasm at new attempts at the problem as a more pertinent response and ignore the rest.

but you could take the sign away and imo people would still open the door - simply because that seems to be the only thing they could do. plus with the whole door surface being available, why would you use just your hands? use your shoulder or even back (if you happen to be carrying stuff in both hands)!

seems to me like that would be more affordance.

> The community is full of MDA (model-driven-architecture) types: too often is the focus on increasing complexity (for ego boosting / job security) instead of simplicity and accessibility. > .. instead of locking it up for fun and "profit".

still, if you ignore the MDA and executable uml silliness, there's quite a few ideas that can be picked from that closed space, imo.

nice message with the real reason for the ashtrays.

one thing that bothered me however, was that push vs pull handle design. if you're really trying to provide affordance, why have a handle at all on a door that needs to be pushed? isnt it our natural tendency to pull on a door handle when provided with one?

all we'd need was a "Push" sign and we'd be done. The shape of the handle hinting how to use it seems subtler than providing the whole door surface as actionable; and if you had to unlock to open, we have well established pushable door designs already.

seconded. not to take anything away from LT, but i'd really like to see it deal with a large codebase.

No love for Textpad on HN? Its been running strong for ages and has the "just works" feel about it - always. Install it, switch to windows keybindings and you're good to go. And, it has editable macros.

I live in the knowledge that I'm going to hell for not paying for that awesome piece of software!