Generalizing programming language patterns in CodeBlocks

[beqroson]

Hello everybody,

Congrats to the development of the CodeBlocks application, which I partly admire (I could create a list of admirations and things that still lack  , but I will not). I am a newcomer and I respect that fact. However, there has been an idea bugging my mind for at least a year now. I would like to present this idea in this topic on this forum as I believe it would be appropriate. For all ideas, there is "someone" that must "do it". Now, that may be solved, possibly, by me contributing my share to the codeblocks application, if the idea takes off.

The general idea is to enable that any programming language should be possible to use with very little preparation in the codeblocks IDE. I am not talking about just C++, but ANY language. By this I mean compiling, code-completion, hightlightning, everything that a developer needs. Now, the IDE already supports many languages, but that is not the point. Any language could also, by customizing the IDE, be implemented, but that is neither the point.

Now, my idea is more specific than the general idea, but let us come back to the specific idea when some opinions about the concept above has been let out. I know that there can be issues about implementing and so forth, but let us take one opinion at a time.

/Beqroson

[beqroson]

I am responding myself to my post. I was content this is the right forum tab for this subject. Now I was less sure, moderator, if you find another forum tab better, feel free to move it.

Thanks

[ToApolytoXaos]

I'm really interested in reading your idea as soon as you share it in this forum. Even though expanding an IDE to support multiple languages create extra problems, I would say that supporting only 2 or 3 the most is the ideal thing.

If I am not mistaken, they are in the process to add Python support too, which is more than awesome IMO (because I use it myself), but supporting multiple languages? That would be very challenging to keep up to date and maintainable.

Let's see how things will evolve in the meantime.

[beqroson]

I would say that supporting only 2 or 3 the most is the ideal thing.

How come? I mean, let us suppose an IDE that is targeted at supporting those 2-3 languages, but which has the bonus of being able to support ANY language with only a little extra cost? I am not guaranteeing it is implementable, but then again, I see no obstacle. Although, why do you want to "cripple" the IDE to only support those 2-3 languages and no more? Any specific reason?

[oBFusCATed]

Although, why do you want to "cripple" the IDE to only support those 2-3 languages and no more? Any specific reason?

Because we use a single language in our day work and we don't care for the others much. Is this enough for a reason?

If you have a favourite language that is not supported you can:
1. look at the C::B's code
2. start making changes, so the support is improved or possible.
3. post a patch or better series of patches
4. fix reported problems and don't be afraid of criticism

Expecting that we'll start doing changes to our SDK (without a specific requirements) in order to support random/every language is optimistic.

On the other hand: we're working on better SDK for CC plugins, so in the future it will be possible to CC for any language there is a plugin written.
But the internal build system is tightly coupled with the C/C++ way of building projects and I don't see this changing soon.
Of course we have custom makefile support, so C::B could build anything make could build.

[dmoore]

This sounds a little like Fermat's last theorem. "I have a proof for this, but there's not quite enough room in the margin of this notepad..." And it was finally solved using what can only be described as a brute force approach.

I think we are open to having the IDE support multiple languages (but the developers certainly vary in their level of interest), and we've taken many steps in that direction. The editor syntax highlighting works for whatever languages Scintilla supports, the build system is very flexible and can be configured to support a wide range of compilers and languages. We have a pretty flexible API for supporting debugging via plugins (I have written a debugger plugin for python using it) and we are well on the way to doing the same for code completion (I have a partially working plugin for python). But that still leaves a LOT of work to write all of the interfaces for language you would hope to support. So you really need to tell us more about what you have in mind ...

[Alpha]

On the other hand: we're working on better SDK for CC plugins, so in the future it will be possible to CC for any language there is a plugin written.

If you are curious, this thread contains some details.

[beqroson]

First off, thanks for the response. I know your time is limited between all the forum posts.

Because we use a single language in our day work and we don't care for the others much. Is this enough for a reason?

Yes, it is reason, more than enough reason in fact.

Expecting that we'll start doing changes to our SDK (without a specific requirements) in order to support random/every language is optimistic.

At the moment I am just handling the idea. As for my self I havent invested in any expectation at all for your part. However, I am already starting to visualize how to implement it. The difference may be sutble, but I apologize if I sound or read as arrogant.

If you have a favourite language that is not supported you can:
1. look at the C::B's code
2. start making changes, so the support is improved or possible.
3. post a patch or better series of patches
4. fix reported problems and don't be afraid of criticism

Yes, I can agree to that being a proper way to proceed. Unless the idea is a little different than that. I am not talking about adding one language at a time, but to add ANY language in one single step. I want to synchronize with you all about this. But I am not going to do anything if my idea is not supported, right? However, I am willing to create all of the low level code for this, how does that sound? But, you are the core developers. I must know that once the low level code is created, that you will implement it somehow, by way of a single plugin or two or in any way. If there is no relatively covering consensus about this, the question is if I really should go about on this.

Sure, when I say in one single step, I am talking pretty big strides.

Do you think that it would be possible to do something like:
5. Create some of the "low level" code as a showcase to give you the idea of the concept?

Not that I am on my way to do any such horrendously stupid thing yet... 
But if that be an option to proceed?

[beqroson]

This sounds a little like Fermat's last theorem. "I have a proof for this, but there's not quite enough room in the margin of this notepad..." And it was finally solved using what can only be described as a brute force approach.

I think we are open to having the IDE support multiple languages (but the developers certainly vary in their level of interest), and we've taken many steps in that direction. The editor syntax highlighting works for whatever languages Scintilla supports, the build system is very flexible and can be configured to support a wide range of compilers and languages. We have a pretty flexible API for supporting debugging via plugins (I have written a debugger plugin for python using it) and we are well on the way to doing the same for code completion (I have a partially working plugin for python). But that still leaves a LOT of work to write all of the interfaces for language you would hope to support. So you really need to tell us more about what you have in mind ...

Sure, I will be more specific. And I will not keep you on your toes. I will present any information until the idea is proven wrong, which happens most of the time, just as you pointed out.

Many of the steps that you have taken covers most of the usage out there. It even covers a lot of my general idea of supporting any language. But it will lack some space in order to support my specific idea.

[beqroson]

On the other hand: we're working on better SDK for CC plugins, so in the future it will be possible to CC for any language there is a plugin written.

If you are curious, this thread contains some details.

I will surely look into all the current work and streamline any solution of an implementation to make use of as much as possible of the current implementations.

[beqroson]

Ok, I have a couple of responses about the general idea. Thus I can present the specific idea.

The specific idea is to support not only any programming language that the code may be written in, but...
to also support ANY natural language that the code may be written in. By just adding this support in the IDE!

[stahta01]

Ok, I have a couple of responses about the general idea. Thus I can present the specific idea.

The specific idea is to support not only any programming language that the code may be written in, but...
to also support ANY natural language that the code may be written in. By just adding this support in the IDE!

You do realize you are coming off as a person who knows nothing about programming!

Tim S.

[beqroson]

Ok, I have a couple of responses about the general idea. Thus I can present the specific idea.

The specific idea is to support not only any programming language that the code may be written in, but...
to also support ANY natural language that the code may be written in. By just adding this support in the IDE!

You do realize you are coming off as a person who knows nothing about programming!

Tim S.

Either know nothing... or too much! No, just kidding. Sorry if I have trouble to make myself clear and understandable among all those enthusisastic traits of me. For the record, I am not new to programming. More like moderately advanced in C++, knowledge about a few other languages, computer theory, the psychology of language, some about ergonomy...

Dont get fooled by me though. I can be too enthusiastic. Better safe than sorry.

[oBFusCATed]

It sounds like you want to do YAGKBS (yet another generic killer build system) and then you want us to make a C::B plugin for it. Am I correct?

[beqroson]

It sounds like you want to do YAGKBS (yet another generic killer build system) and then you want us to make a C::B plugin for it. Am I correct?

Hmm, you got me thinking there. Damn, a long time since I used my brain. 
Well, now that you mention it, I realize that I am thinking about some kind of quick cheat that may not cover corner cases about programming. No, I am very content about the YAGKBS that codeblocks already have. The quick cheat I am referring to is to use something like a preprocessor that will work on top of a source (as if preprocessors worked in some other way). I mean, just look on GCC that cannot support other than ASCII set of characters. However, when referring to the the implementation of support for natural language (and parts to programming language) a preprocessor may be what really is needed.

I am thinking about some showcase implementation. I hope to be able to scramble something together rather quickly. Just to convince myself that it is workable. And for you to see more clearly what I intend. I dont think it is correct for me to give you details here. Or? Do you want me to go into details? If you are that curious/or want to finish this discussion rather quickly?