If you want to bookmark this thread and have it always jump to the newest post add the following link to your bookmarks. Don't click it and then bookmark it otherwise you won't get the right results.
Sounds good. We can think up syntax until then. I start school soon and I don't know how much time I will be able to contribute to this. Aren't you still in school Jake?
Do we want a VB style IDE? Where you place items on a form then write code for them?
How does C++ (and other languages) have forms (buttons, etc) without a VB type interface? Do you define a X and Y and width and height or what? I've never done anything except VB and JavaScript (which has HTML as its visual counterpart).
I was about to go and all, even registered for my classes, but I didn't obtain my drivers licence on time to where I can drive to college since my parents are no longer taking me. Got it a week after the payment deadline passed. So I had to skip another term again.
I'm thinking of doing a syntax so simplified, that a baby could use it. But at the same time it'll execute at warp speed. I'm thinking as fast as C++, if we can make it go that fast. I noticed a pattern in all of these programming languages, that there are many things that are not needed, like the semicolons for example ';'. In the long run, it can save a lot of coding time by not pressing that key alone, not to mention it can make it more readable.
Actually maybe I could help. I could write (or help write) the IDE in VB. That wouldn't affect the speed if the compiler was written in ASM. The IDE has to be able to do syntax checking etc and we could provide nice error messages when people mess up and syntax coloring. MMMMM. I like it.
When VB creates us a form it is basically simplifying the use of the MFC (Microsoft Foundation Classes) which C++ developers tend to use. This translation can be costly to our application. In C++ it is taken that the MFC shouldn't always be used in time critical programs; the same can be applied to us, but with something extra. Because VB translates everything for us it will take a little while for this translation to take place; which could be a little extra speed for our program. As well as this translation we are also using the MFC - effectively two potential slowdowns.
It had nothing to do with DirectX. And I am talking about using IDE, only not makingthe mistake that Microsoft made with VB. They did the MFC method, and that was bad for speed. We need to do the Win32 method for IDE mode. Getting it now?
Ok, I don't see how the IDE has anything to do with the speed of our program.
So you are suggesting using Win32 (and VB) to make our IDE.
Or are you suggesting that our compiler creates windows with Win32? Plus won't win32 be outdated when Vista (64) comes along?
I'm headed out for tonight. I might be able to post at the persons house I am going to hang out at, but probably not. Reply to all the questions I asked and I'll be on tommorow.
Also try finding a random name generator and see what you can come up with.
Also see if you can PM some of the long-time members and see if you can find any other interest in the project.
Ok, I don't see how the IDE has anything to do with the speed of our program.
So you are suggesting using Win32 (and VB) to make our IDE.
Or are you suggesting that our compiler creates windows with Win32? Plus won't win32 be outdated when Vista (64) comes along?
... And ASM for our compiler?
No. We are gonna use ASM to use Win32 to make our IDE. I have the assembly source code to do this. As a matter of fact, we will be making the compiler in Assembly. You and I can learn it together. Shouldn't be that hard.
Also, we will allow uses to have a choice between IDE mode or directly compiling it into an EXE.
I don't have time these days (until November) to put into much code, but I had the idea to do it myself a fair while back, so maybe I could get something out of this
I know how to do Win32 forms and controls (the theory anyway, never done it in practice). You need to use CreateWindowEx(), RegisterClassName, etc.
I'm learning ASM at the moment. the syntax can be learnt in about 10 minutes, but all the instructions take forever. It would be easier to apply it with a compiler because you only need to think of the right instruction to use once (and put it into the compiler), as opposed to every time you code a routine using it.
You can also use FASM (Flat Assembler) to generate opcodes from any ASM instructions, which is very useful for inline ASM situations, and precompiled ASM in VB using byte arrays.
Also, personally, I actually like the semi-colon ; to separate instructions, because it gives you a lot of freedom with code placement, and it is easier for the compiler
I personally think it's not needed. Anything can replace that semicolon, even CrLf. The only difference between us and MS is that we are gonna focus more on speed. Hence the name, Light Fusion.
Here's a simple "Hello World" Win32 app using MASM. Notice that the code is somewhat similar to C++'s method in the Project.asm file. Open it with wordpad to see the code.
And yes Penagate it will be OO, but it will not be 100% OOP, like the .NET languages are. It's gonna be somewhat similar to C++.
I don't think that is either, it has "advanced coding instructions" whatever that means... However it's only an issue if you care that it supports more than just pure x86 instructions. Maybe I should have said, that example you posted wasn't pure assembly. It had invoke's to call APIs, and a Switch block, and bunch of other things. In pure ASM you would do that using push/call (APIs) and cmp/conditional jump (Switch). You could rewrite teh whole thing in pure ASM and still compile it in MASM I suppose. Don't sweat
First, all of you project members should learn straight C coding, or perhaps straight C++ coding. Higher-level languages tend to distract from what a language actually is. (As this thread makes evident.)
Second, forget Windows for now. Focus on the language: what should it do, what shouldn't it do. Do you want full OOP-support? What features? Any other programming style? What makes your language actually different from existing ones, where are the advantages? What will you give up in exchange?
Third, get a copy of "The Design and Evolution of C++" by Bjarne Stroustrup and read it. Find out what influenced one of the most popular programming languages ever. Then rethink your work from #2. Are the decisions you made rational? Have you considered the pros and cons of each? Is the resulting language actually useful for what you want it, or has it become a feature creep? (I see a strong danger of this here.)
Admittedly, I'm very sceptical about this. It sounds as if you a) are completely planless and b) will at best create a language that is basically VB, C or something in that direction with just a slightly different syntax - and with much worse compilers, because obviously you still have a lot to learn, while the competition has years and even decades of experience.
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
Well we are focusing on one thing at a time. Right now we are trying to come up with a name. Lightfusion seems to be good though in my opinion. Secondly, it's gonna have to be done on assembly and not C++, because the syntax will be easy to use (Like VB is), only it will run very fast (Like programs that run on C++). But we will focus one thing at a time. We might have a beta version made on C++ as a start until we master working with assembly. After we finally decide on a name, we will work out the syntax.
The point of the language that I wanted to make, and it's been brewing for several months now, was to combine the terse syntax of C, with the RAD nature of VB, the raw power of C/C++/ASM, and modern innovations such as XML, etc. Plus, a rapid turnover time for new features to be added to the language.
So what's actually the point of this Lightfusion language, apart from the cool name? Combine your favourite programming languages? They'll always be the best tool for the job, and you want to watch that you don't end up with the jack of all trades. Speed? That comes later, with rule-based compiler optimisations. The syntax doesn't affect teh speed
CornedBee is right, you need to think about what exactly you will use this language for. Not what it will be like, but where and how you will use it, and then figure out the best way for it to tackle those situations. Only once you've done that, you can add more features, to approach more situations. Am I making sense?
Secondly, it's gonna have to be done on assembly and not C++, because the syntax will be easy to use (Like VB is), only it will run very fast (Like programs that run on C++).
Sorry, but that's nonsense. A VB program is slow because it's interpreted (always up to 5.0, and in test mode in 6.0), and there's huge overheads from the runtime. But the runtime is written in C and C++, perhaps even a bit assembly. That doesn't help the overhead - it comes from the way VB works.
C++ is complied to native code. There's no overhead at all. That's why it's fast. With some libraries, such as MFC, you introduce something of an overhead and gain ease-of-use. Usually, these two hold a balance - the more you simplify, the greater the overhead. (That's not a hard rule.)
You have to decide whether your language gets compiled to native code or is interpreted. Interpreted is slow. Compilation is complicated. On the other hand, even the most modern versions of Cfront, Bjarne Stroustrup's own C++ compiler, emits C code that is then further processed by a C compiler.
But even more, you have to differ between the runtime of your language (what it gets compiled to, the core libraries) and the support structure (compiler, linker, ...). The compiler and linker can be in Perl and it wouldn't affect runtime performance, only compilation time.
You'll want to compile to native code. As I said, you could emit C code and let that compiler handle it. This way, you can save yourself much work. Or you could emit Assembly, but then you get practically no low-level optimizations. Or you could emit machine code directly. But nobody does that.
The core libraries can be in pretty much any language, as long as they can be called from yours. Except for some very fundamental parts, they'll probably be written in your own language. Some C++ implementations, for examples, have nearly ALL of their libraries written in C++. One example is the MS one, which only very rarely calls into the C runtime (a library written in C) or the WinAPI (also a library, in a way, written in C, Assembly and C++, mostly.)
But my point about learning C/C++ wasn't that you should compile your language to either of those, or implement your toolchain in them (although I think you should do both), but that you understand existing languages that do approximately what you want - in other words, that are fast. Yes, C can be tricky to learn, and yes, the features of C++ can be confusing. But those are the languages whose speed you want to match, so you should understand why they are that fast. It'll help you make a better language.
A name is unimportant. The name C++ wasn't invented by the language's inventor.
Edited to answer Penagate.
Yes, you are making sense. Find the application area for your language, and then think about everything else.
But don't forget this: the RAD capabilities are a big part of what makes VB so slow. The RAD is supported by a framework that hides complexity, prevents mistakes, and so on. All of these things take time. RAD and speed have never yet been seen together, except perhaps in Delphi.
The innovations like XML, though? That's what libraries are for. It doesn't make much sense to make these things part of the core language. A better idea is to offer features that make it possible to write libraries that seem like a part of the language - C++'s operator overloading and templates are an example. The Spirit library lets you create recursive descent parsers nearly as if it was a language feature.
Last edited by CornedBee; Sep 3rd, 2005 at 12:34 PM.
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
But don't forget this: the RAD capabilities are a big part of what makes VB so slow. The RAD is supported by a framework that hides complexity, prevents mistakes, and so on. All of these things take time.
Indeed, however it is possible to combine speed and RAD if you support multiple levels of complexity in your language. The lower level language features give you more power and scope for manual optimisation. The higher level features enable RAD development, which you can later optimise using the lower level features.
Originally Posted by CornedBee
The innovations like XML, though? That's what libraries are for. It doesn't make much sense to make these things part of the core language.
I dunno. What about C-omega's inline XML descriptors for controls? I really liked that. In some places XML does have a use and that is where it can describe things much more neatly than the general syntax of your language.
Thanks a lot for all your advice. If either of you feel you have the time to actually participate in this, then you are more than welcome to join.
Once again, I have to consider the fact that I go back to school next week. I agree with CornedBee that (if we are trying to out-speed C++) we should C/C++. But, for me, this means an even bigger time commitment, which I don't think I can afford. I will stay on board with this as long as I can and even start learning ASM or C/C++, but I can't say wether that will be a month or 4 days or what.
I definitely want to help contribute to the syntax and general development if I can find the time though.
I love this idea, but we need to get a couple more members on board and then make a solid plan (and take what CornedBee and Penagate have to say into consideration while making that plan).
On a side note, I was also thinking we should focus on getting this language to run on the command line before we worry about Win32 windows and stuff.
EDIT: Can you guys make sure to hit "Reply" instead of quote with reply so the title of your replies changed to RE: LigthFusion™ instead of QB#++.NET
Thanks.
Last edited by eyeRmonkey; Sep 3rd, 2005 at 01:14 PM.
But, for me, this means an even bigger time commitment, which I don't think I can afford.
Well, designing a language takes longer than learning one by orders of multitude, if not magnitude, so I really see no problem there. It's a huge time investment either way.
I'll be here if you have any questions, but I won't actively participate in the project. I have my own ideas of how my ideal language would look (at lot like C++), and it's not this.
Anyway, LightFusion seems pretty safe as name. Google didn't turn up anything relevant, only some UK company with a completely dysfunctional website.
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
I have my own ideas of how my ideal language would look (at lot like C++), and it's not this.
That actually reminds me of an interesting point. The more I tinker in my spare time with creating a syntax, the more it becomes like C++, and the more I start to understand C++ properly. You learn a lot by messing around on your own, and I find that sort of learning sticks with you a lot better than something you find in a book, or tutorial. Then you can back it up from a reference to make sure your facts are all straight.
Edit: eyeRmonkey the first post still reads QB#++.NET (in the post body).
for starters it's a great thing for easy reading code, and secondly it would make your life alot easier too, be alot easier for your compiler to interpret if lines end with ; and linebreaks are ignored
AntRush - Real-Time Strategy game, based around ants!
Make a compiler (and programs to run fromt he command line)
I hope you guys understand a compiler isn't just 50 lines of code I've been reading an online tutorial about creating one for quite some time now. It took the guy 10 years to write the tutorial. I think its called "Lets create a compiler", and it was about 60 chapters (all well beyond a suitable text limit IE should be able to contain). Perhaps a scripting engine with the ability to create Gooeys is more achievable (which is something I began in VB, but can't finish it due to my lack of a computer atm)
I've written a very simple compiler for a very simple language in about 1000 lines of code. Of course, that one didn't have any optimizing and could barely handle functions. Oh, and it could only handle integers. The thing emitted Alpha assembly.
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
Reply With Quote
Mark Thread Resolved
Originally Posted by eyeRmonkey
CornedBee
Multi-Clipboard
I've been reading an online tutorial about creating one for quite some time now. It took the guy 10 years to write the tutorial. I think its called "Lets create a compiler", and it was about 60 chapters (all well beyond a suitable text limit IE should be able to contain). Perhaps a scripting engine with the ability to create Gooeys is more achievable (which is something I began in VB, but can't finish it due to my lack of a computer atm) 