I thought the Iron* moniker was conventionally reserved for things running on .net (It Runs On Net), like IronPython, IronRuby, IronLisp, IronScheme, etc?

Isn't using it for this project going to cause confusion?

I was going to make a snarky remark comparing it to the recent second usage of 'isomorphic' but, to be honest, people will figure it out. I'm putting all this stuff on my list of things not to waste blood pressure on.

I was honestly trying to be helpful, and was definitely not making a snide remark. Sure, people wondering if this is node running on .Net might click and discover they were wrong, and all is fine.

But if his project from name alone is perceived as being related to .NET, he may not reach out to the full audience of web-developers he may be aiming for. And that's a net loss for him.

If there's a time to reconsider the name, it's now before it gets bigger and more "known". I mean the repo only has around 10 commits at this point :)

Your concerns are justified.

When I read "IronNode" I immediately thought of "IronPython" and "IronRuby". Had I just skimmed the headlines and not paid attention to the full title, I would have ignored it.

I didn't think you were being snide, nor did I intent to be. Really don't understand the downvoting behaviour around here.

I don't think he was trying to be snarky. I thought the same thing when I first clicked on the link.

Given that the usage of isomorphic is perfectly correct (it's using the biological, not mathematical, definition) I don't know how you'd do that...

True, but you could make the same argument about terms like "transparent"[0] -- which still cause grief to no end.

[0]: In the intuitive sense: something you can see the insides or details of (e.g. Transparency International). In the CS sense: something that is invisible to the consumer (e.g. it's a bad idea to make critical network operations transparent to your persistence logic). In the design sense: something that has an alpha channel.

How does that cause grief? That's called "context" and language has it.

Isomorphic here is being used in the already existing biological sense. Just because the HN commenting user base is largely ignorant of non-mathmatics terms (a problem) doesn't make it wrong.

In fact it's very applicable. Fitting pretty much perfectly with what is going on.

Except contexts aren't as clear cut. As humans we tend to switch contexts all the time often even within the same conversation. We also frequently nest contexts, which works fine as long as the vocabulary of each context doesn't overlap too much.

Terms like "isomorphic" and "transparent" are ambiguous, especially if you're not familiar with their use in the active context, even more so if you're already familiar with their use in a different context and most definitely if you weren't aware you just switched contexts and the term has a defined meaning in the active context: "evolution is just a theory" comes to mind (the speaker obviously not being aware that "theory" in the context in which evolution is called one is something very different from the colloquial definition they are familiar with).

I'm not arguing we shouldn't use the term "isomorphic". The context in which "isomorphic" is used in the web sense and that in which it is used in the mathematical sense are unlikely to overlap as frequently as the most vocal opponents would claim.

I'm just pointing out that the ambiguity is real and that it will continue to be a problem until the definition in the context of web applications (or any environment-agnostic application, really) becomes widely enough known that programmers only familiar with the mathematical definition stop being confused and see it as what it is: a new piece of jargon they have to learn if they want to join the discussion.

> "I'm just pointing out that the ambiguity is real"

It's only ambiguous in the sense that science has been "ambiguously" using it correctly for decades. Somehow it's survived.

> "it will continue to be a problem until the definition in the context of web applications becomes widely enough known"

Which - outside of complaining about it in HN comments - it has. Hell there are entire startups and B2B companies that use it now.

Isomorphic has been used in this form for 5 years. Yes, maybe you could argue it was AirBnB that popularized it 2 years ago but that's still a damn long time of common usage.

That ship has sailed - long ago - any programmer who doesn't know what it means at this point just isn't paying attention.

How is this any different than: https://github.com/node-inspector/node-inspector

Node inspector has a lot of problems. Buggy as shit. And it's time consuming to use the -brk param to make ur app stop on the first line and then attach node inspector, and then switch back to having it not stop on line 1 when testing ongoing calls. That's why it is important what this guy built to automatically attach itself, even if all the other node inspector bugs still exist. It's particularly hard to find ur files in node inspector and with it refreshing ur always losing where u were, which is also a problem with chrome dev tools but to a lesser extent. I'm generally extremely surprised that node inspector is so shitty. Literally no node developers must debug server side code with a debugger. That's complete idiocy, ie resolving to just log calls throughout ur code. It's a statement of the lack of observability developers are willing to put up with because they know no better. I use node inspector constantly, but it's absolutely retarded how much bullshit I have to sift through. I have to reopen the files I'm working either every single time, drilling deep through file structures, if I don't already have a breakpoint on a file. It doesn't remember what files and folders were open.

Have you tried debugging with webstorm?

I have. I use Meteor, and for Meteor it doesn't support debugging Package code, so that's a no-go for me. But I was impressed by what they were going for in the situations I did get it to work. A few things I miss from the chrome style debugging, but a few new things that were quite useful. In general, debugging for Node needs to be fixed and addressed from the ground-up. It's an afterthought for everyone, which is why we see things happening like chrome dev tools being repurposed. I mean that's not a bad idea, but when the implementation is so clearly a half-assed hack job, it's clear a more foundation-first approach must be done.

It looks like it works by just reusing the devtools that are part of electron instead of shipping it's own (like node-inspector). That might make it more reliable than node-inspector for basic debugging. But that's only a guess after glancing over the code.

Good question, I can't tell. node-inspector's docs are much better too.

Incidentally I did something very similar with my private projects and I've been using it for the last weeks. It's basically Electron, with a few lines of code that runs the script you pass in the argument and opens Chrome's dev tools. It's awesome, and much, much better than node-inspector.

How can we make it work with meteor?

Can you set the debug port number or PID of the process you want to debug in case your program runs as a cluster of processes?

I agree that node-inspector is tedious to set up and often doesn't work initially - It does have support for debugging clusters though.

Anyone know how this compares to Theseus? https://github.com/adobe-research/theseus

If this actually works this is going to be awesome!!