I think the language should be chosen last.
I think the language should be chosen last.
What did you vote for?
I don't see any reason to panic. The build system will most likely have some kind of scripting language built in. I don't know about bytecode...
The poll will close in approximately 12 hours.
If anybody is unhappy with how the voting process is going, please voice your concerns.
Me neither. I don't think I panicked. @whiteflags: That's my secret (hint: I voted for 5 thingies) ;-)
Besides, I consider untested code to be worthless with respect to production releases, and it's good to hear that I'm not the only one who likes unit tests.
As for the first choice, here's my current opinion: theoretically, it's pretty easy to implement a new language with all the parser/lexer generators available. The hard part is optimization, which reminds me of some nightmares involving static single assignment form, hot paths, dynamic runtime optimization, JIT compilation, flat binaries and so on.
IMO we should make a decision based on the abilities of the most unexperienced participant, not on the wishes of the most visionary.
That being said, I'm eager to actively participate in the winning project, whatever it may be.
I was, in a nice way, trying to gage how you cast your vote. Everyone knows there are two ways to vote: For things/people you like or against people/things you hate. Had I determined you were taking the latter approach, I would have probably been very upset but only wrote something like "that's not how democracy works" here.
>> IMO we should make a decision based on the abilities of the most unexperienced participant, not on the wishes of the most visionary.
This may backfire as I am sadistically interested in doing something I know nothing about, and you have no proof of my experience.
@whiteflags: Didn't want to blame you. sorry for that .
@Wraithan: Agree with you. The people with the least skills should also learn something. (Me)
Things like e.g. dynamic runtime optimization will be much harder if you're already having trouble implementing SSSP algorithms for graphs.
I'm not saying that nobody should have to learn new things during the process. I just want to make sure that everyone will be able to catch up in time. If the project turns out to be too easy, it will be done quickly and we can soon advance to more complex topics.
As someone who will certainly fall toward the bottom of the pile, I think you wizards should do want you want, but be willing to spend some time with us idiots. If you want to just put all your effort into producing piles of high quality code and ignore those beneath you, why partake in such a project (honestly)?
But I'm not worried. In the end, even if I can't contribute much, it will be at least nice to witness the mighty in motion, close up.
Anyway... Nobody should knock their own abilities. I haven't met any successful programmers who weren't confident. As long as you recognize your own boundaries (which should constantly be expanding), you should feel good about doing what you know you can do well.
Can someone with absolutely no foundation/background in the art of programming be useful for this project?
I would like to be a part of this project and may be learn something with respect to programming and if possible also contribute may be to a lesser extent.
I voted #1 but I don't totally agree with what the poll says though. Another small, limited scripting language really isn't needed. If the community project is going to be a new language, it should be a fully functional one. The only problem with that is there are many fully functional, good languages such as Python, Perl, or Ruby. The three of those languages really could suit most projects, but each has their own problems. To make this script different in my opinion, I think it should allow Unicode in scripts and have all keywords and standard library localized to many different languages. Parrot would be a good platform so it will be able to mix with Perl and eventually Python code.
The top three vote-winners are:
#1: A small scripting language, possibly using bytecode.
#2: A portable build system.
#3: An operating system.
How do folks feel about this layout?
From a timeline standpoint, what I'm seeing here is that we should first design and implement a simple scripting language, then leverage that language to implement a build system. (Then use that build system to compile an operating system?)
I'm not trying to just keep "my" project idea in the running -- honestly. But it did score #2, and I think there are so many good ideas here that we should try to tie them together with a common thread.
If we decide to toss the build system idea, and go with a stand-alone scripting language, we need to define its scope and general purpose. Purposeless projects don't seem to get far, even if they are fun to hack on.
Let's open up the floor to general commentary on the scripting language idea for 24 hours. Then I will produce the initial project definition (doc #1) and we can begin working on the initial requirements spec (doc #2).