Live data from Hacker News

IDEas: Tools for Coders

omegaortega.com

1–10 of 60 posts

Re: IDEas: Tools for Coders

#2
Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error analysis, and autofill. The other half is "makes coding pretty", "provides good shortcuts", and other UI considerations.

Now for the latter - that is great, and everyone has different strengths and weaknesses. And that is just a UX issue.

For the former however, I don't know why I need to use different IDEs for different languages, or even different IDEs for different transforms to the same codebase in the same language (again, for the automated bits).

It would be so much better for the world if there was some common protocol between user environment and code transformer. That way I could buy some of JetBrains awesome plugins and have my trusty Vim or Emacs environments use them. I could just keep using IntelliJ with MS' plugins for C# (and resharper of course). And so on.

For stuff that really needs a special UI, we are in the age of the web browser. Provide a localhost server in your tool and make the reports etc live in a browser window, big GUI IDEs can provide a webkit that can link back to their own editors, but text editor users could still get the useful output.

This "everyone does their own thing" without even pretending interoperability is getting old. We've been doing this coding thing for a little while now - we should be better at tooling that plays nice.

Re: IDEas: Tools for Coders

#3
I started implementing a few of these (and lots of others) ideas, and the issue isn't coming up with what to do, it's doing it intelligently. I have a small side project where I'm playing with AST rendering and the details are usually where you get tripped up.

Re: IDEas: Tools for Coders

#4

Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error analysis, and autofill. The other half is "makes coding pretty", "provides good shortcuts", and other UI considerations. Now for the latter - that is great, and everyone has different strengths and weaknesses. And that is just a UX issue. For the former howeve…

I'm with you on the interoperability, if anyone in the world should understand and be 100% completely behind that, it should be coders and makers of code tools. If we don't demand it and require it, then it's pretty hopeless for the rest of the tech world.

Re: IDEas: Tools for Coders

#5
post #3

I started implementing a few of these (and lots of others) ideas, and the issue isn't coming up with what to do, it's doing it intelligently. I have a small side project where I'm playing with AST rendering and the details are usually where you get tripped up.

If you want testers, let me know or drop a comment with a link in the post. Don't bother trying to get the details right yourself, let the masses help make the decisions for you.

Re: IDEas: Tools for Coders

#6

Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error analysis, and autofill. The other half is "makes coding pretty", "provides good shortcuts", and other UI considerations. Now for the latter - that is great, and everyone has different strengths and weaknesses. And that is just a UX issue. For the former howeve…

> create an industry standard plugin protocol.

I feel that Software Engineering/Science is lacking a body of knowledge: something which is basically required in other professional industries (architecture, medical, physics, electrical engineering), etc.

Software Engineering/Science is at a disadvantage because there is no limitation placed on us by nature: an EE can't simply change the brightness of the sun to meet a requirement. We can.

To create an industry standard plugin is really saying we need to create a common way to communicate information between systems and sub-systems in software. I feel we have not really figured out the best way to do this yet. Our industry is still young.

I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack.

> common protocol between user environment and code transformer

I feel that once we crack the problem of communication between software parts, this will come naturally.

Re: IDEas: Tools for Coders

#7
With regards to the idea that just the current function should be on screen: At one point I saw a reference to a study (though of course I cannot now dig up the link!) that suggested an inverse correlation between the amount of code visible on screen and the number of bugs written by programmers, with the conclusion that programmers should buy big screens, use slightly smaller fonts, and avoid using too much whitespace. It is exactly when you are thinking only about the few lines of code you're writing, and not about the context in which those lines are going to run, that you're most likely to introduce a bug.

In an ideal project, of course, your code be so beautiful--so loosely coupled, so free of side effects--that you could in fact focus on a function in perfect isolation. But few of us are lucky enough to live in such a world.

Re: IDEas: Tools for Coders

#8
For the nth time, I encourage people to look at flow-based DSP programming tools like Reaktor and Flowstone (or its earlier incarnation, Synthmaker) where many of these ideas have already been successfully implemented. For the life of me, I can't understand why IDEs don't come with flowchart generation/editing built in by default.

Re: IDEas: Tools for Coders

#10

Here's an idea: the world doesn't need more ideas, just more people implementing, so throwing out ideas as if they're original and have innate value is unhelpful.

Throwing ideas around is almost always helpful. Often when someone points out a solution to a problem or presents a good idea for something new, someone else, who hadn't thought of it themselves, will be inspired and go do the implementation. What's wrong with that?
Post reply on HN