CBoard Community Project: Poll #1

This is a discussion on CBoard Community Project: Poll #1 within the Projects and Job Recruitment forums, part of the Community Boards category; Originally Posted by Brafil
Ok, you're right - but we should support this automatically for common things like debugging symbols, ...

Ok, you're right - but we should support this automatically for common things like debugging symbols, optimization and profiling.

How do you propose we do that? Which compilers do we choose to support? Just MS and gcc? Which version(s) do you suggest we support? What do we do for the NEXT version of compiler, where it has changed some feature?

One solution would be to have a level of indirection for the compiler settings, so that you do something like:

and this will result in an error if "very-strange-compiler" is being used in a version < 999.999, since it didn't support profiling.
Of course there are some problems like detecting the correct version etc. but it would be more portable and easy-to-use.

As for the language, I suggest an object-oriented approach with as few types as possible. With respect to the build system, a good type seems to be "set of files". I'll give an example rather than explaining it in detail, trusting on your ability to figure out what I mean:

And I think you should drop @fs.set. Just set @fs.optimize/debug/profile to true/false. (Or an integer for optimization, like 0 (no optimization, automatically set by debug), 1 (not much), or 2 (sharply optimized))

As for the language, I suggest an object-oriented approach with as few types as possible.

Originally Posted by Brafil

We should analyse the pros and cons of existing languages. Then we should decide the paradigms (procedural, functional, object-oriented, imperative etc.), after that we can move on to syntax. Later on, will it be bytecode-compiled or not? Extensions? Garbage-collector? At last we should bring everything together with a standard library. Voila, a basic language. Then we could add libraries to extend it into a build-system language.

Here's a few cents from my current study of ruby, where everything is an object, including numbers. I thought that was silly until I saw this

Code:

5.times { puts "hello" }

which really does seem 1) simple 2) elegant. Also, there are no functions -- just method calls. This starts to seem very clever in an "embedded in html" context.

So since we are performing a specialist task, I think we could do a little more thinking about that task in relation to the fundamentals of the language than just saying it can be dealt with in a library. Maybe so, but this could be the difference between something that is phenomenally great and something that could be, at best, just "well done". AFAIK ruby was not (quite) designed intentionally to be embedded, but it lent itself to this very well and so got picked up for the task. Point being, it is still a very good general purpose language a la perl.

I can't say what this would mean in the built tool context, which I've never had to give much thought to. Just hoping to spark some weird idea in one of you geniuses. Also, the "everything is an object, no functions just methods" is a potential model.

Yes. Either this or we used a startup file including default compilers. Great idea, huh? xD

But it is hardly a novel concept. Regular makefiles already do this to a greater or lesser degree depending on the needs, intentions and imagination of the author. Your autoconf case doesn't fail because autoconf isn't able to do this, it fails because the author of the SPECIFIC autoconf script didn't supply enough flexibility to allow a switch from gcc to MSVC or vice versa.

Well - I personally hat that aspect of ruby ("x.times", "x.each do |i|"). It's a matter of personal preference.

And I think functions and methods should be seperated, e.g. a module shouldn't have methods, just contents, which can be functions (not like in python).

My point was NO IT IS NOT A MATTER OF PERSONAL PREFERENCE. By coming up with concrete reasons related to the concrete task rather than just making it a matter of off the cuff personal preference, you will be far more likely to come up with something insightful and dynamic in context.

Otherwise you are just saying, "every time I make a language, it will be more or less the same because of my personal preferences". If you use those preferences instead of the context, you are selling yourself short.

For example:

And I think functions and methods should be seperated, e.g. a module shouldn't have methods, just contents, which can be functions (not like in python).

Being only passingly familiar with GNU make (and totally unfamiliar with any technical description of the language it uses*), I would say this is kind of like a set of function calls:

But would probably be better seen as a set of object methods.** That said, you do not actually need functions (again: ruby is fully functional but does not use them). So yeah, I am advancing the idea that this would be a good way to go here too. Snafuist points out something similar earlier in the thread altho he may not agree with going to such an apparent extreme.

It would be easy to change my mind, of course, but not just by saying "I would prefer it such and such a way" without any in context justification. Otherwise you might end up doing the entire project yourself

*I guess I could do some research...
**really I suppose this is just straight imperative "methodology"

Just to clarify: we are basically settling on designing and implementing a small scripting language followed by a portable build system, right? What I am not clear about is if we intend to design this scripting language specifically for writing build scripts, or if we are designing it more generally, and then using it as the language for the build system's scripts.

EDIT:

Originally Posted by MK27

So, having functions *and* methods might just be an unnecessary complication.

Yes, yet functions can come in pretty handy as an alternative to static member functions when you want to extend a class without using inheritance or composition.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

Yes, yet functions can come in pretty handy as an alternative to static member functions when you want to extend a class without using inheritance or composition.

Could you provide a short pseudo code example of such a situation, and maybe elaborate slightly? It seems to me you could always use a method call from a predefined base/top level class (class class or class object or something) to circumvent a more specific inheritance model.