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.
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.
HTTP?
It's not perfect, but it seems to be what our industry has settled on as the universal way for pieces of software to talk to each other.
If you are thinking in terms of the payload, JSON seems to be filling that role.
Wow, you can change the brightness of the sun to meet a requirement?
BTW, there are quite a few limitations placed on you by nature: uncomputable numbers, NP-completness, ...
Just what we need - now there will be N+1 incompatible protocols!
(shamelessly stolen from xkcd)
If you look at Xcode, it saw a significant improvement when it started using clang to build its indexes. That is purely a C, C++ and Objective-C front end to LLVM.
Xcode basically requires a significant portion of a compiler to provide a decent coding environment.
What you are suggesting is almost to create a compiler "protocol" that can handle all languages. I am not sure how much value you would get from such a protocol.
These ideas are all basically the first thing anyone comes up with when dreaming up a new IDE.
The big problem of IDEs is that they're a lot of work to make and polish very well. Most developer environments are either in a terminal, to get rid of the hard UI stuff, are an editor with good scriptability, to get rid of the hard IDE stuff, or are backed by huge slow moving corporations.
The one really big innovation that is going to blow life into innovative IDE development is scriptable GUI, aka Javascript+HTML. LightTable isn't the first and isn't going to be the last of awesome new IDE environments for which implementing ideas like this is going to be a piece of cake.
So hold on to your hats, we're definitely going there.
Indeed.
Use of icons was one of the topics in an April fools' joke from Bjarne Stroustrup [1, 2].
[1] http://www.stroustrup.com/whitespace98.pdf
[2] https://www.cct.lsu.edu/~hkaiser/spring_2012/exercises/week6...
This has been a neat-o feature which slowly became nice-to-have, but it is fast becoming a requirement. For example, the JetBrains products (Idea, Resharper, etc.), and also what Google is doing with clang to help them manage their large C/C++ codebase.
We already compile/interpret our languages. So we need to open up that "machine understanding" to programmatic access, which IDE's and other tools can then use to do all kinds of nice things.
But it has been on beta for almost 3 years I think. I wonder if it will ever go forward.
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.
I think that for now the best way for me, to continue developing my product, is to continue working isolated from the world. At this stage is probably still early, but if anyone is interested to know more, and think that can provide something, I am open to considering possible partnership. Unfortunately at this point, I am not willing to share online any of the progress done.
"Task context management in Mylyn is based on the idea that your interaction with a system can be transformed into a degree-of-interest model, where each element in the system is weighted according to its relevance to the task at hand. This degree-of-interest weighting forms the context of all the elements relevant to the task. The task context can then be used to focus the UI by highlighting the most important elements, filtering the unimportant ones, and allowing you to perform operations on elements of interest "
I use IntelliJ (or pycharm) myself but some people swear by Mylyn. Not having used Eclipse myself, the screenshot does't really tell much: http://www.eclipse.org/mylyn/images/mylyn-3.1-screenshot.png
This article can be boiled down to: Project idea: better IDEs.
It's in the same vein as comments like: Business idea: nuclear fusion.
They just aren't productive / valuable.
If say Henry Ford said: Project idea: Use energy from chambered oil combustion with pistons to convert direction of force into a spinning axis to create an horseless vehicle. (I'm obviously not a car expert) Then we would be talking about a valuable idea.
My viewpoint is simple: Ideas are not innately valuable, of all the ideas in the world, only a subset of them are valuable. Obviously you don't know what current ideas will be valuable in the future, but I have a heuristic: for an idea to be valuable, it must be a specific (implementation details included (batteries included)) idea.
I do agree that implementers are good though. As I mention in the post, I do have one more idea that I didn't share that I am going to build. I'll comment here again when I'm ready to announce it.
Actually, if that's a route worth taking I'd rather see LaTex than HTML.
Or just Markdown.
Computer programmers are one of the most dismal professionals on that planet. How many so called programmers/coders can even write a simple parser or a compiler? Less than one percent I suspect. I should know because I am one of them. After dabbling away with Aho and Ullman somewhere in the 80s or 90s I haven't approached the subject since.
Ever since Smalltalk came out it has been downhill all the way, and it is only now a lot of the current IDEs have caught up with it and in the last few years have begun to extend the concept.
I believe that:
1. Learning to understand and write parsers and interpreters should be one of the first things taught in computer science even before the whole gamut of data structures and algorithms have been studied.
2. Being able to develop IDEs should part of every computer science course. They may even be developed to help illustrate the data structures and algorithms mentioned above. Unlike most professions computer scientists are the ones most capable of building the tools for creating, analyzing and illustrating their work, so why are they the ones that as far as we can tell use the shittiest tools available to most professions? Honestly I blame Sun and IBM for this. The moment Java came out everything went down hill. Then the web came, then 'scripting' , then everybody decided that they could and should 'build' everything using Notepad, VIM or Textmate.
3. The tools are there, Smalltalk guys have been using and developing their own tools for ages, only the targetted graphical environments have been split up and the OS owners, Microsoft in particular keeps blowing hot and cold as to which one system developers should target. IDE and graphical tools development is so interactive that the idea of using traditional compiled languages to develop them is simply absurd unless you use very fast compilers and computers. It is time they went 3D as well may be using some Blender, Unity3D or some other gaming toolkit to bring them up to date. 2D text and graphics are boring.
4. The bottom line is IDEs should be something developers ought to create or collaborate to create themselves. The big corporations should stay out of that, ie the decisions shouldn't be commercial decisions. It seems that a sad immaturity of computer programming as a profession has led to development tools being dictated by clueless profit seeking corporate bosses. They should be the decisions of developers guilds which should not be linked with corporate interests of any kind. You know what you want, just do it yourselves.
5. What else? Yeah, get your parsing skills together, and don't develop it in Javascript unless you plan to develop your own version of Typescript or Dart later on when subtle bugs begin to creep into your cherished IDE.
PS. Sorry for the trolling at the top. I just couldn't help myself.
As a result, every developer wouldn't need to know how to write a parser/compiler, but rather would need to master the usage of the API the compiler-as-a-service offers. (For example, imagine JetBrains Idea for Java or Resharper for C# as a suite of open source, api-driven libraries).
Then, we could have IDE's with all kinds of features. In addition, we could write programs that transformed or modified our code bases.
This lets the "hard work" of compiler/parser building be centralized to a few developers, but spreads the benefits around to most everyone.
Since this is already happening in some languages (JetBrains, what Google is doing with clang for C/C++, and apparently Rosyln from Microsoft), it seems like only a matter of time before its power becomes apparent and it becomes a requirement for a language to be taken seriously.
I see no reason why Python and Ruby couldn't expose the compiler's AST as a service as well (obviously it would be limited by metaprogramming and dynamic typing ... perhaps in those cases we'd need "interpreter as a service" ... hmmm).
Oh no you are not wriggling out of that one. Every developer should know how to write a parser and a compiler, not full fledged ones, just enough to implement a small language. That is in essence what computing is about, composing and instantiating formulae, with a full grasp of its semantics. To call your self a computing professional without knowing about parsing is like calling yourself a medical professional without knowing anatomy. This can only happen in the world of computer programming. It is the very essence of what we do, and how such a situation exists is an indictment of the computing profession, its educationists and educators.
It is the very soul of computing.
We might get away with it in the eyes of the public who don't know better because we produce the results they want, internally we shouldn't kid ourselves.
