A programming language is a similar emotional topic like an operating system,
and I know it is very hard to find a common agreement. Anyway nice to see that we have alomost all compiler developer here in this thread.

Here are some citeria you could messure a programming language semi-objectively:
(note: those criteria hold only for a general purpose language that is used
to develope small to large Software projects, not ultra small and not ultra large,
and no special purpose like evaluating mathematical equations or alike.)

1. Development must be as fast as possible.
This is the premisse all other cirieria try to support.
The time we can spend on a software project is limited and finite, especially on the Amiga "Market".
The faster the development is, the further the project can be pushed (and also the more fun it is).

2. Compiling must be fast during development.
Otherwise you waste your precious time. More than 10 secs are not acceptable, because you loose not only the compile time, you also loose the focus what you are thinking right now and you have to re-shuffle your mind before you continue developing.
However, if you create a release, compiling time (e.g. optimization) could take much longer, since during development you compile 1000 times, and 1 time for the release.
Obviously, the best is if the IDE compiles in the background and highlights errors while you type them. The earlier a mistake is discovered, the faster is the development. A bug found while typing cost you 2sec to correct, a bug during compile time cost you 20secs to corect, a bug during runtime can cost you 200secs up to infinite.

3. The language should not be closed.
This means the user should be capable ON HIS OWN to use system resources/libraries that have not been known the time the language was designed.
Obviously, this instantly destroys implicit portability.

4. Functions and constructs used at a high frequency should be expressed compact, and low frequently ones can grow large.
This is how ZIP works, this is how a natural language works, and this is how you can develop faster by simply typing less characters on average.

5. It should be able to compile for several platforms.
In the Amiga Scene, this should be OS3, OS4, MOS and AROS I guess. Doesn't hurt if Windows, Linux and MacOS are supported, though.

6. Inline Assembler should be available.
I was thinking about this a long time, because you loose re-targetable CPU
as soon as you use it. On the other hand, if there is no inline ASM, you can not maximize optimization in speed critical parts. It should be used rarely wisely, but sometimes we simply need this.

7. Exectuable speed should be close to C.
It does not need to match C, but 50-75% C speed should be achieved, otherwise
writing CPU heavy stuff (like Image Processing, Decrunching etc.) becomes too slow and the language is not an option anymore.
50% C speed should be fast enough for most everyday applications nowadays,
especiylle given that most time critical things happen in the OS anyway) and for really tight things there is Inline Assembler.

8. There must be a full grown runtime library.
This safes a lot of time. Obviously, loading an image must be implemented by using the datatypes and all the critical flags, there is no way to get around it.
But this should happen once, and this should happen in the runtime library by experts.
Re-Implementing the same thing for every application that loads an image is inefficient and a source for bugs. And probably, if not necessary, your app won't use images then, and therefore look worse.
If the runtime library is powerful enough, that your application can run only on it, the application is portable. Using datatypes is not portable (e.g to Windows).

9. The language should be as strict as neccessary and as lax as possbile.
Strictness prevents you from making stupid errors, laxness is preventing you from
typing unnecessary stuff. So what is the best? Several strictness levels for the compiler can help, and the output of warnings.
E.g. it doesnt make sense to error on every integer that is used in an expression that results in a float, the compiler could implicitly cast. But you should be able to search for those potential problems, if necessary.
Levels of pointer indirection and type safety for stucts are very important though.

10. Readability gives speed.
The source should not use obscure symbols or keywords that need deeper knowlege or guessing,
also unnecessary long code decreases readablity.
This is why the code should be as compact as possbile and use more or less intuitive symbols or symbols that have become quasi-standard over time (like marking a block of code with curly brackets).
To complex constructs that need the knowledge from several sourcecode files should be avoided. A nicly readable source code enables you to ask for advice from people that don't know the language.

11. The machine should do what the machine could do.
Why you should write a makefile or a headerfile while the machine could do this for you?
The machine is faster doing that.
Everytime you are typing something twice, you should ask yourself why you have to do that.
If you are using a function, it shouldn't matter in which line of the SAME souce code it
is actually defined. The compiler should be smart enough to look ahead and not complain that it doesn't know the function because it is defined 10 lines later.

12. Keep memory usage low.
And I don't mean the RAM of the machine, this is there to be used. I mean the short time memory of your brain. The memory usage during development is mostly a question of progamming style.
A good programming style needs low memory, leaving more space for more complex problems.
The programming language should encurrage and guide you to reduce memory usage, mainly by enforcing to keep discipline and avoid side effects.

13. Open Source and free.
If a language is not open source, your project dies if the language dies and technology moves on. You surely don't want that.
If the language is not free, there won't be many people using it on Amiga. And then the community will be small, and you/beginners will get small help.

Summary:
========
We need a language that is more or less portable (powerful runtime) but open (allow syscalls, ASM).
The syntax should not be cryptic (Perl) and not be lengthy (BASIC) but intuitive, encurraging good programming style.
The compiler should be fast (Amiblitz3) and the executables should be fast (Amiblitz3/C), for all Platforms (C).
Besides that, it should be easy to program (BASIC) without a lot of technical mumbo jumbo around (C).

I don't see such a language yet, that's why I think about "A". Feel free to correct me if I am wrong, add some more criteria or ask if i was not clear enough what it means.

Last edited by Wanderer on 15-Jun-2009 at 12:38 PM.
Last edited by Wanderer on 15-Jun-2009 at 12:36 PM.
Last edited by Wanderer on 15-Jun-2009 at 12:34 PM.
Last edited by Wanderer on 15-Jun-2009 at 12:33 PM.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

I agree with most of your points. Mattathias has some of the same goals except 6 and 7 will be combined in Mattathias in that it will allow some of the more advanced end-users to create extensions for the language. The machine language we are targeting is LLVM bitcode so this is possible and even practical. LLVM bitcode is at least as fast as C and probably faster than some of the old versions of C still in use on the Amiga.

Have you considered my posts about portability and the use of LLVM for all of the compiler projects? It seems that LLVM may be a gift to us from the other platforms since it can optimize as well as the latest versions of GCC but with less code.

@Samurai_Crow

I read about LLVM. But I don't understand how it works. It still looks pretty high-level to me. And i dont know were the Calling Conventions for specific Platforms come into play.
If I create LLVM code, how can I (and can I at all on AmigaOS3 ?) execute the code?
How can I debug it?

What makes you assume that it will be as fast as C? Who will generate the 68k code, does it have an AmigaOS 68K codegenerator?

Maybe this is something for A too, but I just don't get it.

On my plan there is "V", which seems to be something similar, just much much (MUCH!) simplier, in the hope that people, other than me, are able to write a codegenerators for it. Simplicity is crucial because we have not enough time, and we don't need 95% of the features of GCC during normal usage.

I did a V interpreter for 68K in 3 days. In LLVM (like in many huge projects), it seems like in 3 days I wont even make it through the manual.

Plus, how fast is it? What Environment does it need?
I dont want to make "A" rely on thousands of external files.

The current plan looks like

A (A Compiler that creates V binaries)
V (V Compiler, for debuging only)
VRun (V interpreter)
VGen (V Codegenerator for 68K, PPC, x86 ...)

Thats basically it. No more files, bins, libs blabla.
Abviously, If you want to compiler for a platoform, you will need its SDK. This will be generated out of the C SDK for AmigaOS3/4 MOS etc. and must be available during compile and interpret/codegen time.

Last edited by Wanderer on 15-Jun-2009 at 03:30 PM.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

Answers that were still missing:

@Mrodfr
> I think the official successor of amiblitz ???.
No.

@kas1e
> I am not so big lover of basic,
A/A++ is not a Basic. It is more like C/C++.
But an integral comonent are the A++ Libraries,
that make it as easy as Basic. I dont like Basic
syntax either.

@ChrisH
> It is a shame that "A" adds C++ style syntax onto the BASIC language,
A ist not a BASIC. And it does not really add wiered C++ syntax.
ItÄs much more straight forward and integrates smoother to the functional
approach.

> as IMHO that turns a nice readable language into an ugly unreadable one
Actually, OOP is intended to make the code more readable. What makes C++
really unreadable are complicated inheritance rules and templates.
This will not be part of A. I had a look at PortablE, but I dont like its
syntax (I can give good reasons for this if needed)
and it does not look like solid software engeneering.

@Samurai_Crow
> If you want A/A++ to ever be cross-platform, you'll need to rethink your implementation of macros because
Why macros? I don't understand this.
If you want to use various OS dependent functions, you need several virtual binaries that are compiled under different SDKs.

> I don't mind some of the syntax conventions of A/A++ but it doesn't look like it is being written from the ground up with cross-platform compatibility in mind. Is it supposed to be AmigaOS/AROS/MorphOS only?
Yes, if you use the OS API you are not implicitly portable. But to achive this, you must forbid access to the OS,
which is - after thinking about it - too restrictive to be able to implement serious stuff.
A reasonable powerful runtime library should keep your code as portable as possible, but you cannot
foresee all evetual issues in when programming the runtime.

> Since the AmiBlitz team seems to be experts in the generation of 68k code
=> Bernd Rösch.

> By the time your team would have finished with that, our team will have finished the parser generator so you could use the parser generator to write your A/A++ language with.
The idea is to have a lightweight language, fast and easy. I dont think this can be achived by a general purpose parser.
I also have a compiler half way finished.

What about Matthias or PortablE generating "V" code
Runs already interpreted on 68K.

Or maybe we agree on a common Runtime, for easy portability.

Last edited by Wanderer on 15-Jun-2009 at 04:42 PM.
Last edited by Wanderer on 15-Jun-2009 at 04:40 PM.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

To make LLVM work on Amiga68k, you'd have to have another machine that LLVM already runs on such as a Mac, Windows or Linux machine. But the good news is that once a code-generator has been written for the Amiga 68k, then not only will LLVM work on Amiga68k but also so will Clang, a C-language front-end for LLVM. This is the reason I know that LLVM will be as fast as C. LLVM-GCC and Clang use LLVM as a backend.

The calling conventions of AmigaOS 3 is to treat d0, d1, a0 and a1 as scratch registers and all of the rest must be preserved. When using VarArgs from C in this configuration, there are helper functions in Utility.library for this. The reason for having multiple calling conventions in LLVM is that most C compilers outside the Amiga community use the stack for all parameter passing which makes the compiled code very slow.

The reason I'm suggesting we use LLVM as an instruction set is that it does an incredible amount of optimization for you and, if you write the code correctly, will allow you to write one binary code that will install to any processor that uses the same operating system APIs.

The reason I'm suggesting not using preprocessor #define macros is that a proper optimizer can eliminate dead code that will never be accessed in the optimization stage and let you embed all of the operating-system specific codes in one file so you won't need multiple binaries. Likewise if the optimizer does aggressive inlining, you won't need normal macros either.

Consider AROS. It has an x86, x86_64, PPC, and soon an ARM version. They run most of the same source codes but require separate binaries for each processor. If we used LLVM bitcode and forced all of the operating-system specific codes to be embedded into the one binary stored on the install disk and used the final code generator from the installer, we would have much less headaches trying to keep track of what systems are supported and what systems aren't. All systems that have an LLVM code generator will work.

Is this making more sense now? I've been studying this for some time now and I think that we should share experiences to prevent each other from falling into the same pitfalls that we have already fallen into.

Last edited by Samurai_Crow on 15-Jun-2009 at 05:31 PM.

@Wanderer

#21
A programming language is a similar emotional topic like an operating system,
and I know it is very hard to find a common agreement...
Here are some citeria you could messure a programming language ...
1. Development must be as fast as possible.
This is the premisse all other criteria try to support...

The main reason i use SDLBasic is the syntax and vocabulary definitions list. I tried AmiBlitz and it's too difficult. It seemed to me, I had to know a lot of graphics engineering to do anything. I tried to translate a simple AB program to SDL and couldn't do it. Wow! OK, what assumption am i missing; what criterium is missing?

_________________

@Snuffy

Actually, the first draft of Mattathias is going to use the sdlBasic runtime. The syntax will be more like Amos though.

@Snuffy

You mean which criterium SDL Basic is violating?

I don't know SDL Basic, but probably 3,4,6,7,8,(9?) and 12.

Amiblitz3 is also violating a lot of the cirtieria, as well as C does.

However, depending on what you do, those violations wont hurt you. But in general, they do.

> I tried AmiBlitz and it's too difficult. It seemed to me, I had to know a lot of graphics engineering to do anything.
Amiblitz3 is so huge, that it is hard to say if it is difficult or not.

Example (again and again...)
[code]
image_Load{0,"DH0:pics/myImage.png"}

image_Blit{0,x,y}

image_Save{0,"DH0:pics/myImage.jpg",@"JPEG"}

End
[/code]

How can this be easier? Does this require a lot of graphics engeneering knowledge?
I could continue similar demos for Sounds, Doublebuffering, AREXX, Clipboard, GUI, Undo, TCP/IP, etc .etc. etc. etc.
The runtime library that comes as the "Includes" is huge and mostly documented.
Obviously, SLD will have much more examples out there since it is not restricted to Amiga. On the otherhand, the performance is much lower than Amiblitz3.

BTW, in A/A++, this would look like this

[code]
*myImage.image = New("DH0:pics/myImage.png")

myImage\Blit(x,y)

myImage\Save("DH0:pics/myImage.jpg",'JPEG')

End
[/code]



> The main reason i use SDLBasic is the syntax and vocabulary definitions list.
What is this?
Something like this:



> I tried to translate a simple AB program to SDL and couldn't do it. Wow!
Does Wow mean: SDL can't do what AB3 can do?
Or does it mean SDL is so difficult that I dont even get a simple Demo working?

Or did you expect that SDL Basic and AB3 are somewhat similar?

Last edited by Wanderer on 15-Jun-2009 at 07:36 PM.
Last edited by Wanderer on 15-Jun-2009 at 07:33 PM.
Last edited by Wanderer on 15-Jun-2009 at 07:23 PM.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@All:

Hi All,
I'm working on a project that will take times to reach its completion but it's something near to what you want.

Project development name is : "AmiDARK Engine"
It will be composed of 2 projects.

1. The first part of the project is to create a set of functions to simplify the life of an Amiga OS 4.x developer in game creation. The command set is similar to DarkGDK from TheGameCreators (http://gdk.thegamecreators.com/)
When this part of the project will be completed, I will release the first product as objects or library set to include when compiling.

2. The second part of the project is to create a BASIC LANGUAGE based on the command set of project part 1. This programing language will be near to DarkBASIC Professional from TheGameCreators (http://darkbasicpro.thegamecreators.com/) and will probably contain wrapping command for AmosPRO command set.

Concerning the Engine itself here is what is planed to :
- Use OpenGL/MiniGL
- Use AHI for Audio
- Use Datatypes for audio/graphics/video file formats
- Use a command set similar to native DarkBASIC Professional command set.

Actually, it already uses OpenGL/MiniGL for Images/textures.
I'm working on basic 3D objects support.
The project progress slowly due to the problems/bug that are actually present on Amiga OS 4 on Sam440flex motherboards...

I hope this info interest some of you ;)

Kindest Regards,
AmiDARK / Freddix

@Wanderer

I really like your philosophy for your Programming developer environment !

Thanks for all your hard work.

One of the rules I use to know if a programming language is powerful enough is:
Can it compile iteself.

If the IDE/compiler can compile itself it, it can grow with new commands, future proof.

I agree with the portability for Amiga OS3,4,MOS,AROS etc. This is for long term survival.

I also agree the compiler should find most errors and not break on a line that the real error was 5 functions

above it.

Your IDE is alot of work, so I suggest to get other ppl involved to add the capability of plugins to the IDE,

maybe lua script.

LUA is one of the best, underused scripts!, used in Tales Of Pirates MMO/ World of Warcraft, for easy game

creation GUI/AI/core, dynamic variable creation/allocation.

http://www.wowwiki.com/UI_beginner%27s_guide


Even Virtual Dub, the powerful assembler, video converter is using LUA scripts now.

Source can be seen when game is installed in TOPs :)


(like firefox plugins)

source code plugins(extensions) and IDE plugins

If someone can access the code/page before/after your compiler, in the IDE, they could add other checkers :


Language Tidy/ formatting / highlighting
API autodetect, auto complete, highlight
drawing tools like DOT language could draw functions / classes etc for documentation.
http://en.wikipedia.org/wiki/DOT_language


EG:
For example someone could write a spellchecker / Language parser.

GUI detect, autocomplete, convert to/from TUI/MUI, Feelin, Windows GUI

Any new command plugins could, not just have source, but formatting data, so new commands automatically have

their formatting defined to the ide and automatically added to the help system.

main core DDL/DTD + plugin DDLs/DTD available


Commands like:

MyWindow = New Window
MyWindow.SetDefault

PS: if your GUI is platform independant - no need to convert
PS: if your GUI in an application is script based, the gui can be changed without recompile

example TOP/PKO in game, dynamically created GUI script fragments that execute when game runs:

-- Creates the QQ minimum form
frmQQMin = UI_CreateForm(“frmQQMin”, FALSE, 146, 20, 0, 160, TRUE, FALSE)
--UI_FormSetHotKey(frmQQMin, ALT_KEY, HOTKEY_N)
UI_ShowForm(frmQQMin, FALSE)
UI_AddFormToTemplete(frmQQMin, 1)
UI_SetIsDrag(frmQQMin, TRUE)

--Loads the upward button
id = UI_GetScrollObj(scrollid, SCROLL_UP)
UI_LoadButtonImage(id, “texture/ui/PublicC.tga”, 11, 9, 166, 0, TRUE)
UI_SetSize(id, 11, 9)

-- Adds the menu
UI_MenuAddText(frndMouseRight, “Detailed Info”)
UI_MenuAddText(frndMouseRight, “Send message”)

labTitle = UI_CreateCompent(frmChat, LABELEX_TYPE, “labTitle”, 60, 14, 10, 4)
UI_SetCaption(labTitle, “Dialog”)
UI_SetTextColor(labTitle, COLOR_BLACK)
UI_SetLabelExFont(labTitle, DEFAULT_FONT, TRUE, COLOR_WHITE)

-- Create form, parameter order: Form name, form id, form width, height, X coordinates, Y coordinates, negative
to suppress shop display, negative to suppress shop title.
-- Return value: fail - 1, success return form ID

function UI_CreateForm(name, ismodal, w, h, x, y, isTitle, isShowFrame)
local id = CLU_Call(“UI_CreateForm”, name, ismodal, w, h, x, y, isTitle, isShowFrame)
if id==-1 then
return nil
end
return id
end

-- Create control: formID, controltype, controlname, width, height, X, Y
-- Type is: 1- button, 2- combo box, 3- text box, 4- picture, 5- text, 6- tabulation
-- Return value: The failure - 1, success returns th control ID

function UI_CreateCompent(formid, type, name, w, h, x, y)
local ret = CLU_Call(“UI_CreateCompent”, formid, type, name, w, h, x, y)
if ret==-1 then
return nil
end
return ret
end

function UI_FormSetHotKey(id, control_key, key)
CLU_Call(“UI_FormSetHotKey”, id, control_key, key)
end

function UI_SetButtonCheckBox(name, check)
CLU_Call(“UI_SetButtonCheckBox”, name, check)
end

function UI_SetImage(name, state, tx, ty, tw, th, scale_x, scale_y, texture)
CLU_Call(“UI_SetImage”, name, state, tx, ty, tw, th, scale_x, scale_y, texture)
end

Last edited by asymetrix on 15-Jun-2009 at 08:49 PM.

_________________

@asymetrix

How about LLVM-Lua? It is faster than regular Lua due to all of the advanced optimizations LLVM does.

@Wanderer

I think Snuffy was indicating that AmiBlitz has too many commands for a beginner to use.

@Freddix

Thanks for the heads-up. Your run-time library will probably be useful.

@asymetrix
> One of the rules I use to know if a programming language is powerful enough is:
> Can it compile iteself.
This is a bit populistic and not that important to my opinion.
And holds of course only for multi-purpose languages.
A scripting language does not need to implement a compiler.
"A" will be bootstraped in Amblitz3, and later ported to itself.

> I also agree the compiler should find most errors and not break on a line that the real error was 5 functions
above it.
I did not mean that. This would be a bug. What I meant is this:

[code]
void testA() {
testB();
}

void testB() {
...
}
[/code]

This would fail under C, because testB() is textually behind testA(), which is
to my optinion an insufficiency of the compiler and has no relevance to achive clean code.
It just makes you either

a) re-arrange your code => more work
b) write a header file => more work

The compiler could just look over your file and see that there is
actually a function called testB().
This refers to
"11. The machine should do what the machine could do."

The A compiler will be 2-pass: first it will collect all declarations and definitions,
and in the second pass generate the code.


@Samurai
> I think Snuffy was indicating that AmiBlitz has too many commands for a beginner to use.
I dont think that the amount of commands is in relation to the easieness of a language.
Thinking this way, Assembler must be trivial and PHP must be extremely complicated.
It is just a matter how you can find the command you need. In that case, the IDE is
important. I dont know all commands of Amiblitz3 eihter, but I dont need to. If you drive from A to B, you dont need to know how to get from C to D. Only if your map is a mess.

BTW, "A" would come with a GUI toolkit that is implemented in "A", called NTUI, which would be portable then (currently implemented in Amiblitz3).

Last edited by Wanderer on 16-Jun-2009 at 08:17 AM.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

I see that there are many software in the work: what about to join the forces to create a great rad basic development?

Would be great!

_________________
retired

@Wanderer Quote:

More than 10 secs are not acceptable, because ... you also loose the focus what you are thinking right now and you have to re-shuffle your mind before you continue developing.

Taking your quote out of context, I have to say that as long as I am not interrupted by other things (that involve much thought) I can easily remember what I was doing. I have even gone to sleep, and 8 hours later woke up & still remembered exactly what I was doing

_________________

@ChrisH

Of course you remember what you did yesterday or 10 min ago. (at least a very rough summarization)
But the difference is that you actually HAVE to remember. Things that are in the very short term memory are present in your mind, and don't require remembering. That's like the CPU cache, RAM and harddisk. They have different access speeds and you can only work with things that are currently in the CPU registers. If you wait for 10 secs, you very likely get a context switch by looking out of the windows or whatever. This costs you time and taking into respect that remembering is a LOSSY process, it degrades the quality of your code compared to what it potentially could have been.

Last edited by Wanderer on 16-Jun-2009 at 08:58 AM.
Last edited by Wanderer on 16-Jun-2009 at 08:56 AM.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer Quote:

E.g. it doesnt make sense to error on every integer that is used in an expression that results in a float, the compiler could implicitly cast. But you should be able to search for those potential problems, if necessary.

Excluding your odd example, I think this is a nice idea in principle, but not really achievable in practice for large projects. Here is why:

If you DON'T stop the user with errors, but instead allow compilation to continue with warnings that can be hidden, then you will end-up with code containing vast numbers of (hidden) warnings. Then as soon as you DO want to check a small bit of code for problems, you will get pages of warnings about code you are not interested in!

The only solution is to:
1. Tell the compiler to not generate a warning about something WHILE you are writing it. And this is actually the purpose of a "cast". It tells the compiler "I am doing something that looks bad here, but I've thought about it & it is really alright, so please ignore it" (and it also tells another reader of your code about assumptions you have made).

2. Stop the user at the point a warning would be created. And this is actually the purpose of an "error". It tells the user "this looks like something bad, so please deal with it or indicate it is not a mistake".


The REAL way to stop errors being annoying is to make the compiler more intelligent & less strict, which is what I have tried to do with PortablE (compared to C/C++). Although I do have an optional layer of checks, which can be disabled on a per module basis (in case you are interested, these checks prevent pointer manipulation/arithmetic until you disable them).

It also helps to have a properly designed language (hint: not like C/C++), where you are constantly having to fight the language (e.g. mixing value & reference semantics, as in C/C++). And it also helps to output as many errors as possible in one go, rather than stopping on the first error. (PortablE also tries to do both of these.)

_________________

@Wanderer Quote:

I don't see such a language yet

Since you say that, I hope you don't mind me listing how well I think PortablE matches-up to your ideals, even though it isn't a version of BASIC...

Quote:

1. Development must be as fast as possible.

Very subjective & vague, so difficult for me to say anything useful here. But developing using PortablE should be at least as fast as in C, probably faster since PortablE has some nice features & better design (IMHO) compared to C/C++, and I still want to improve it further.

Quote:

2. Compiling must be fast during development. ... More than 10 secs are not acceptable

I don't see how you can say "10 secs are not acceptable" when you don't specify the project size. That said, PortablE used to be rather slow. It is now much faster (14 times since the original release, and the next release will be even faster) - still not as fast as I would like, but IMHO it is now "acceptable". (Oh, and it goes like greased lightning on a Windows machine, all those GHz do help!)

Quote:

3. The language should not be closed.

This is something I made a very high priority for PortablE. Not only can the user add support for additional libraries (that have C headers available for them), but a clever enough user can even add support for additional *OSes*!

Quote:

4. Functions and constructs used at a high frequency should be expressed compact, and low frequently ones can grow large.

I think that PortablE does quite well here, although creating new strings is more verbose (but much faster) than in BASIC.

At some point I feel that compactness can actually hinder development, because ultra compact code can require a lot of thought to understand. Look at functional languages to see what I mean. I prefer procedural languages (e.g. C or BASIC), where you specify the exact steps the machine will perform, even if this is less compact.

Quote:

5. It should be able to compile for several platforms.

Pretty good here, and still improving. Currently Amiga OS3, OS4, AROS, MorphOS & basic support for Windows.

Quote:

6. Inline Assembler should be available.

Not available (unless the target language used by PortablE supports it). Nor do I see the point if you are targetting modern machines with hundreds of MHz. Oh, I'm sure it would be nice in 0.01% of cases, but GCC -O2 or -O3 should do a pretty good job in general.

Quote:

7. Exectuable speed should be close to C.

As PortablE generates C/C++ that closely matches the original E source code, I would expect 99% to 100% the speed of C/C++.

Quote:

8. There must be a full grown runtime library.

Still working on that, but there is at least access to most of AmigaOS & some 3rd party libraries.

Quote:

9. The language should be as strict as neccessary and as lax as possbile.

I think PortablE achieves nearly the perfect balance here, but of course I designed it according to my beliefs.

Quote:

10. Readability gives speed.

PortablE is *extremely* readable. In fact I would say that it is about as readable as BASIC, and perhaps even better in some cases.

Quote:

11. The machine should do what the machine could do.

PortablE does not require header files, nor makefiles. Modified modules are automatically recompiled (which was a big pain for me on AmigaE).

Quote:

12. Keep (human) memory usage low.

I would like to think that PortablE does quite well here, although this is obviously subjective. I have on-purposely avoided mixing different paradigmes (unlike C/C++), so there is less to worry about.

Quote:

13. Open Source and free.

PortablE is not open source, but if it did "die" then I would open source it - although this is unlikely to be needed, since PortablE is designed to be my personal "future proofed" language.

Also, PortablE works by translating E code into another language (usually C/C++), and keep as much of the original formatting & layout as possible. Therefore even in the absolute worst case you could continue working on your program in C/C++.

_________________

@Wanderer Quote:

the difference is that you actually HAVE to remember. Things that are in the very short term memory are present in your mind, and don't require remembering.

OK, you obviously aren't going to believe me, but I did actually mean that I went to sleep, and 8 hours later I still had picture perfect recall of the problem - as if I had done it a few seconds ago! I do not claim this happens all the time, but it has happened. Certainly I can remember perfectly what I was doing for more than 10 seconds (at least minutes, if not hours) - *as long as* I am not forced to heavily think about something unrelated.

Probably depends on how heavily (depth & length) I have been thinking about the problem, so the more heavily I have thought about it, the longer I can instantly recall what I was doing & the problem in detail. On the down side, it can take me quite some time to "get into" a problem in the first place - I need to immerse myself in the problem for a while before I can think through it well, at which point I am fairly useless at thinking about anything else (even simple non-programming stuff would likely make me look like an idiot, as it'd take me several minutes for my mind to change subject). I do not believe that I am unique here, althought maybe unusual.

_________________

@ChrisH

I think the point is that if program is compiled quickly it does not interrupt your work flow. You can quickly check if the project builds and continue typing. It is even better if you dont have to rebuild the whole project but only those bits (source code files) which have changed.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@ChrisH

Quote:

ChrisH wrote: Probably depends on how heavily (depth & length) I have been thinking about the problem, so the more heavily I have thought about it, the longer I can instantly recall what I was doing & the problem in detail. On the down side, it can take me quite some time to "get into" a problem in the first place - I need to immerse myself in the problem for a while before I can think through it well, at which point I am fairly useless at thinking about anything else (even simple non-programming stuff would likely make me look like an idiot, as it'd take me several minutes for my mind to change subject). I do not believe that I am unique here, althought maybe unusual.

Sounds like me! I find that I can't just jump into a problem, have to be surrounded by it for a while, but after a few hours of thinking "like" a computer, people give me odd looks when I can't put a sentence together properly without stopping to think about it Glad I'm not alone here!

Edit: I'll agree with itix here though, I much prefer not having to wait for a long time for a rebuild when I just want to check if a little thing I've changed still works. It happens to be in my job, where I program firmware. I have to rebuild the project and flash the chip to test it, and sometimes I lose my train of thought during the delay, even though it's only about 5 minutes...

Last edited by Daedalus on 16-Jun-2009 at 11:26 AM.

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X