vinodkd

Please do reconsider adding a visual indicator. Direct manipulation is a powerful UI technique and helps retain user focus. It could be something as simple as the mouse pointer changing when hovering over a component that can be drilled down into.

Do you mean something like Netflix Vizceral[1]? The problem with using data is that there's usually too much of it, and at that point you do end up with a graph that only something like graphviz can layout.

I know what you mean though; but it has to be IMO just enough data, that can then be tweaked by a human to help with the key purpose of such diagrams - human understanding.

1: https://github.com/Netflix/vizceral

Fascinating journey through various parsing techniques, aside from describing glush itelf. bookmarked!

Can you share a sample of code, its equivalent sequence diagram, and how one is converted to the other please? I see that the samples have caller->method() style code, but how is this a sequence diagram? And where's the actual bidi mapping?

To be clear: I'm not critical; its good that ballerina attempts to bridge the visualization and the implementation. I'd like to see an actual sample, though.

Edit: Never mind, found the other poster who discovered your IDE plugin that shows the sequence diagram equivalent. Not sure how this is part of the language, though.

Always happy to see another language being born, especially one that's put together like this - assuming all of it works (have not yet downloaded or played with it, this is based on reading your website)

That said:

1. This is bikeshedding, but you cannot make a statement like "diagram is the code, code is the diagram" and not show how to actually do that. The home page even has a sequence diagram. If you meant that the written code looks like a sequence diagram if you squint, then say that.

2. What makes this a Perlis language? I knew every term in the by example summary [1]. Is it annotating functions as services with metadata, or in-language support for xml/json, websockets/http2, etc? How is that different from other batteries-included languages like wolfram, for example?

3. Related: the problem with a batteries included language is that it gets bigger and bigger over time; hence the idea of "small language, large library base". What will you do with the language when its usage pivots over time - add more batteries as standard?

4. Minor: Many links to GH on the community guide page [2] end in 404s.

[1] https://v1-0.ballerina.io/learn/by-example/ [2] https://v1-0.ballerina.io/community/

I think OP meant the part about showing up at the gym - that nobody but you can do. Once you're there, however, having an instructor helps you not having to think about what to do.

Multi-level visualization of a tech stack with perspectives and semantic zoom.Nice!

Two questions: 1. How do you plan to handle the scale of real-world applications, ie really deep hierarchies, really long "call stacks"? 2. Will you support actual graphs with loops at some point, or will ilographs be trees?

I dont know why you're being downvoted, since the core of your idea is valid from a usability perspective.

F0-X,think about the way Google Maps (or any other map app for that matter) "corrects" you vs other programs/apps that throw up an error message. When you make a wrong turn, the map software re-routes you based on that choice instead of telling you you're not following its instructions. It assumes your choice is not mistake and goes with it, while still trying to get you to you destination.

Now imagine your compiler (and by extension, IDE) doing that, and you get what I think jodrelblank is getting at.

Two problems, however:

1. Our interaction with language interpreters/compilers is less conversational and more episodic: we submit what we think is "cooked" code, and it tells us where it isnt. If instead it were a conversation, then we'd see more of an "I think you meant this, not that" type of error message. Go and other newer languages are trying to do this with more descriptive error messages that propose alternatives, as are features like incremental compilation.

2. We really cannot specify the goal with a general program. How do you translate "I want an app that plays sudoku" into something a compiler can understand and guide you with? Or even something seemingly simple like "Convert celsius to fahrenheit"? Since the problem space is unbounded, language tools use the bounds setup by their syntax.

The vast majority of users will forever be beginners - they'll learn a few techniques and wont bother with the rest - simply because that's not the only thing they do. For such users, a canned, ready-to-understand UI that looks like paper is pragmatically better than providing the capability to do whatever they want at the cost of becoming a power user in word processing.

People use spaces for tabs and newlines instead of page breaks despite there being solutions for them even on mechanical typewriters. As long as it works for them, that's ok.

Maybe some people actually like a graphical UI that does not require learning arcane syntax or keyboard shortcuts, provides a passing simile to actual paper and allows them to be productive (if not proficient)?

As for "anything significant", even OP shows one file per chapter. That's very likely what most users of word processors do, I'd imagine, even though Word (for example) had master/child documents support in the late nineties.

Yes, I was heading in that direction, while having misgivings about using terms like area. The advantage is that its a familiar term, the disadvantage is that its really not the same physics (if there is one to be found). Thanks for the links

Weekend reading material found, thanks!

While not as well-thought out and presented, I've been working on a similar project for the past 6-8 years. I called it the "Grand unified theory of software" (after its physical equivalent) [1] and the attempt was to define, describe and quantify code, how its created, and changed.

The best exposition of my thoughts is probably this mindmap:[2], but the TLDR version is:

* Software has size. Sequences of code adds height, modules add width; together giving area

* Software has weight, like page weight or memory weight.

* Forces act on software to change it, and they could be design constraints, organizational will, etc

* Code is data REALIZED, data is code ABSTRACTED

* and so forth

There is also a book (not mine) called the "Grand Unified Theory of Software Engineering"[3] which takes into consideration not just what software is, but the processes and organizations that cause it to be created and explores justifications for statements like "you ship your organization", for example.

We need more such exploration and discussion, IMO. Since software is largely an abstract thing, having models to help thinking about it in ways analogous to concrete things is useful, if not precise.

1: https://github.com/vinodkd/guts

2: Mindmap flash version: http://vinodkd.github.com/guts/mmap/full/guts.html

Mindmap non-flash version (look below diagram for complete text): http://www.vinodkd.org/guts/mmap/basic/guts.html

3: GUTSE: https://books.google.com/books/about/The_grand_unified_theor...

I do quite a few interviews and find that its easier to record exactly what was said mechanically because at another level, I'm also understanding and responding to it. This way, I keep a record of what happened for later without much thought to summarizing it at that time, and instead am able to take the conversation where i want it to. later, i look at the raw notes and re-visualize the conversation and THEN draw conclusions.

So yes, IMO, there's place for exact notes when you're both the scribe and active participant.

I dont know about Gregg, but in Pitman shorthand, the position of the consonant's outline (as the symbol is called) relative to the line dictates its associated vowel. Above the the line is "ah", on the line is "eh", below is "ee", and so forth. You can adorn the whole outline with dots and/or dashes for vowel sounds on all consonant outlines, especially since its written cursively (ie a whole word is writtent together). However, in practice, you get what the word is from context and experience. My father who was a stenographer made me learn it when i was a kid and to this day I remember the outlines of words quite easily, even though I've never used it professionally.

Edit: A more appropriate question to the part of the article you referred to would be: How do you differentiate between "cot" and "got", for example, because it would be the same outline for c(ie k) and g. The official answer is that you wrote one thinner and the other thicker (which is possible when you use a pencil, which was what was used to write pitman shorthand, anyway). The practical answer is that you get it from context - not all sentences could have both those words equally viable.

The article got the numbers wrong, but that course was especially active when I took it, and I was taking it the second time it was offered. Still the best course in the OMSCS program that I've taken. Very lively, helpful and deep discussions, some of which had individual responses going into thousands of words.

The course itself was very innovative in its directions and tests because it asked questions that compared and contrasted human and artificial intelligence. That not just got people's creative juices going, but also made it relatable. More than one person related the artificial learning we were imparting to the code with our own learning processes - or that of our children.

The instructors (Dr.Goel and Dr.Joyner) also used it as a chance to compare the online vs on-campus versions of the course with some interesting results (tldr: the online version was OOM better due to student participation, which was likely due to self-selection of early adopters of the OMSCS program, but still worthwhile).

IIRC there was nothing specific to java or python, except for using opencv for the last exercise to visually solve ravens matrices. You could do the same with nodejs, I'd presume. It might be easier too, considering most of the code involved manipulating dynamic data structures.

Thanks for the response. This is the confusing part for me: I've been talking in terms of Feature toggles as described by Martin Fowler: http://martinfowler.com/articles/feature-toggles.html, but it looks like LD is focusing on the AB testing piece primarily, with some parts of the base toggle functionality included by default.

Can there be a feature switch that is configured not based on users, but on owner/admin's choice alone?

More importantly, how do the LD SDKs help with the issues mentioned in the "Implementation Techniques" section of Fowler's essay - things like avoiding conditionals, DI, etc?

So how exactly does launchdarkly help with feature flags becoming a junk drawer/tech debt? I can see how the intuitive ui would help in general, but what I was really expecting to see was:

* A way to manage dependent feature flags, because god knows once those non-technical(and technical) users have switches they can throw, they're going to ask for/build features that are dependent on each other in subtle ways

* A distinction between a true feature flag and what I call a "release" flag, ie, a feature that's not yet fully built, but that will not be optional once fully built and released, so its flag goes away at some point.

Also, btw, do you have an API for the flag creation itself, not its use, ie a addFlag()/removeFlag() API?

Thanks for this well thought out response. [4] is the killer clearly. My naive response as I read yours was: "Well, just have two rates, the medicare one and the regular one". But if laws prevent that...well then that's played straight into the insurance companies hand.

This is true. The big "chain" hospitals do have pushy tactics, doctors with lab prescription quotas etc. Similarly, but at the other end of the spectrum, there are hospitals in smaller towns that mistreat you or send you off with painkillers.

Clearly, your mileage will vary, so you have to do research, ie, talk to people you trust, much like everything else in India :)

I know the article and the discussion is about access to drugs, but I must call out that part of the success of medical tourism in India is the lack of stranglehold control over medical care by insurance companies. In India, I can:

- Get an estimate for service before it happens, and plan for it therefore.

- Pay for the service at the time of discharge with/without insurance

- decide by myself if i want to get a specific procedure done or not - no fuss of "does the insurance cover it?". Of course, this is one area where the costs of service being inherently low helps.

- get all my medical records in my hand

These are basic patient freedoms, IMO, that the insurance industry in the US has taken away.

I dont know the history of how it came to be this way in the US, but as it stands, the situation is very geared towards getting mystery service - you dont know what you're allowed until you're refused, you dont know how much the service cost you until months later and even then in multiple bills from various hosiptals, doctors practices and specialists, and you have to ask for your records because you cannot keep them safe!

I have all my records from every treatment in India, but not one coherent,collated record of my last physical checkup in the US. There's something broken there.

Will do. And yes, I did read your rationale. The intent is not bad, the names probably are.

Things I really liked:

+ recording runs as tests

+ one library for all layers of abstraction

+ building in assembler to avoid the big runtime.

+ using literate programming techniques to manage coding in assembly.

+ scenario, "screen-should-contain" and "assume-keyboard". awesome.

+ spaces: nice primitive of the closure and similar concepts

+ attributes for meta programs. again, awesome.

+ labels and using [,] as labels. genius.

Suggestions:

* If there's a valid reason to call them recipes, go ahead. If they're actully just functions, please stick with what everyone knows and gets. Same thing with "reagents","reply", "ingredients" and "products". Update: I did read your blog post about this. still think the regular names are better in the long run.

* I dont know where you're going to with multiple types of the "number:list" kind, but if so, the map must look the same, not lispy.

In all, I really like where you're going with this. Kudos! I find a lot of resonance of ideas I've had for a long time now.

Would you care to write a "behind the scenes" blog post about them? These are awesome.

TPF, if you're one of the 3-4k people worldwide who still know it, pays very well. Yes, they will be small teams, but in the largest travel companies.

Disclaimer: I could be wrong about the number above, but afaik its in the ballpark.

Thanks for this link. I was going to say that graphviz covers it, but blockdiag is much simpler (and with extra features)

dont think that will work - that's an aspirational email address that i hope to setup one day (you see how far the rabbit hole of procrastination goes :)).

edit: followed you on twitter. follow me back and i can pm you my email.

Sure. just followed you on github if that's sufficient. i'm not much of a social media person, so let me know if you want to connect via email.

btw, another project idea of mine is to create a stream-of-consciousness editor: you create the content (code, meta-information about the code, whatever) as it "comes to you" and then figure out a place for it later. this is obviously the opposite of how our current file-based editors work, but in its simplest form its not that different in its implementation (autosave untitled files and allow them to be renamed, for example). What would be really cool is to have chunks of content belong to multiple documents, or being able to copy-n-paste by linking and so forth. Again, nothing that hypertext itself isnt already, just a concrete implementation in an editor context.

one more for "when I get to it" :)

To counter this, I actually wrote a "Dont break the chain" app[1] that pulled contributions from all my local projects (since i have some that are not yet on github, some on bitbucket, etc)

The idea was that I'd be happy if I made progress on at least one of them in general. Of course, I didnt finish that one either :)

[1]https://github.com/vinodkd/dbtc

Two reasons: UX and intent

UX: My next comment usually involves looking at my previous ones and keeping that flow. sometimes my journal has todos that i'm tracking; things like that.So having it all in one place is useful and the git log experience breaks that into two pieces: one to view the log to date and another to add a new log entry.There's probably an opportunity for a shell script that loads up the log in an editor, allows me to add an entry, diffs it on exit and auto commits.

Sometimes i'll enter the same text in both my commit message and journal; and some other times my commit message essentially says "look at the journal, too detailed to list here".

Intent: Sometimes I use the journal to track not just what i am doing but also what I should be doing. Alternate paths I want to try, philosophical sidebars on why I'm doing what I'm doing, etc. These entries explain to my future self why the project is in the state that I come back to it :). I'm not sure how I could put that into anything other than prose - since its not fully fleshed out code yet. I've tried design docs and that works sometimes, but usually I just want to jot down my thoughts in a stream-of-consciousness mode rather than figure out the right document to put the thought in. The journal works best for this. Later, I'll pull things from the journal into a design doc.