> 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...
Of course not. I want to learn. And as I said, I dont like BASIC anway.

Quote:

1. Development must be as fast as possible. > Very subjective & vague,

No. Not subjective and not vague. It it pretty precise. If the language makes you loose time, it violates this criteria. All languages violate this criteria, the only question is how much.

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 is the whole point. 10 secs are too long. It doesn't matter how large the project is from the user point of view. Your brain looses focus and gets bored.
Amiblitz3 has never compiled longer than 10 secs, even for beasts like HD-Rec.

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*!

Nice. You almost convinced me

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.

Yes, i mean compactness while keeping the programming paradigm.
E.g. Perl can be ultra-compact, but you need 10min to figure out what is acutally going on.
What I mean is the following:

This is what you need to do if your language does not support OOP:

+----------------------------------------------------------------------------
|
| *mySprite.sprite = AllocMem(SizeOf(sprite),MEMF_ANY)
| If (*mySprite) {
| mySprite\x = 100
| mySprite\y = 100
| mySprite\image = LoadImage("Dh0:images/alien.png")
| If (mySprite\image==Null) {
| FreeMem(*mySprite,SizeOf(sprite))
| *mySprite = Null
| }
| }
|
| ...
|
| If (*mySprite) {
| If (mySprite\image) FreeImage(mySprite\image) : mySprite\image = Null
| FreeMem(*mySprite,SizeOf(sprite))
| *mySprite = Null
| }
|
+----------------------------------------------------------------------------

And this is what you need to do if your language supports OOP:

+----------------------------------------------------------------------------
|
| *mySprite.sprite = New("Dh0:images/alien.png",100,100)
|
| ...
|
| Delete(*mySprite)
|
+----------------------------------------------------------------------------

Both are "A" syntax, and everybody reading this thread understands them intuitively.
But the last one cost you 5 secs to understand, not 30 secs like the upper one.
This example is a little cheated of course, but it gives you an idea what I mean.

Another one:

AmiBlitz³: 6 lines, 93 chars
+----------------------------------------------------------------------------
|
| NewType.myType
| x.f
| y.f
| End Newtype
|
| *myVar.myType = AllocMem(SizeOf.myType,#MEMF_CLEAR)
| *myVar\x = 100,100
|
+----------------------------------------------------------------------------

C: 7 lines, 94 chars
+----------------------------------------------------------------------------
|
| struct myType {
| float x;
| float y;
| }
|
| struct myType *myVar = calloc(1,sizeof(myType));
| myVar->x = 100;
| myVar->y = 100;
|
+----------------------------------------------------------------------------

A: 6 lines, 52 chars
+----------------------------------------------------------------------------
|
| Struct myType {
| x.f
| y.f
| }
|
| *myVar.myType = New()
| myVar\x = 100,100
|
+----------------------------------------------------------------------------

"A" needs almost half the characters that C or Amiblitz3 need. This is simply faster
to type.

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.

That's cool. I agree.

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.

For x86 I agree. PPC I dunno. 68K should be definetly in. Sometime you simply need to perform some ASM stunts to get the trick done.

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++.

Yep, question is how the C/C++ code looks like.


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.

Access to the AmigaOS and 3rd Party libraries is not a runtime. That is acutally exactly what the runtime should replace, so that the code gets portable. C does this very rudimentary for fileI/O, this is why a CLI tool is ported in 5min while everything else (GUI etc.) is almost a re-write.

In "A" you will have a fullgrown runtime. Lets say SDL is comparable. So you can write your entire program only using the runtime. The runtime needs to be ported only once, and those apps will be ported implicitly. That the benefit of closed programming langugaes. But as I said, only the runtime is too limiting. You cannot pack all you ever need in it.

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.

Yep, this is one of the few slightly subjective criterias. If you make a mistake because the compiler allowed you this, it was too lax. If you need to write more code lines than you want, the compiler is to strict. Very difficult to get a ballance. C is surly too strict, BASIC is too lax.


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.

BASIC is only readable as long as you do "basic" stuff. On everything else the code will blow up in an unmaintainable monster.
C is good on larger projects, but waists far to many lines for technical things that are actually not solving the problem you
are working on rater the battle against the compiler.

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).

That's good.

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.

OOP saves memory usage, if done correctly, and it perfectly cooperates with the online-help. You type the variable name that you know because you just defined it or got it elswere, and you get a lost of methods you can do with it. On the other hand you can create terrible monsters with it, I know.
But it should be used in a modern language I think. At least as on offer, not mandatory. And it should go smooth,
this means that if you create an object, you should not be doomed to do everything OOP from now on. "A" can handle this quite nice I think,
because Classes are only Strcutures, the methods come seperate. No magic around it.


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.

Well, till then we are doomed to your personal taste and mood.



@ChrisH
I know you spend a lot in "E". I guess it will be impossbile that you contribute to "A", but that's ok.
My personal critics about "E" is the syntax, its awkward for me. E.g. no operator precedences is a no-go.
Nobody will understand your sourcecode if he is not an E user.
And if you are programming in your job, lets say C, you are likly to make many mistakes.
Also I disagree with many of the keyowrds you are using, they dont hit the point what they are actually doing.
In the documentation you are using inconsistent terminology, and you dont keep to the standards.
E.g. you call an Array a List. This is really confusing, since they are usually something different.

Anyway, this is the problem about joining forces. This means someone has to let his ideals go, and that
is demotivating. So everybody will keep up "his" baby. But we can still learn from each other.

Last edited by Wanderer on 16-Jun-2009 at 12:35 PM.
Last edited by Wanderer on 16-Jun-2009 at 12:34 PM.
Last edited by Wanderer on 16-Jun-2009 at 12:32 PM.
Last edited by Wanderer on 16-Jun-2009 at 12:28 PM.
Last edited by Wanderer on 16-Jun-2009 at 12:26 PM.
Last edited by Wanderer on 16-Jun-2009 at 12:25 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

Hmm a good general purpose language/compiler to me:

It should make as much things as possible possible, with minimum amount of work.
It should be invisible and as little as possible in the way of the programmer.

And a few obvious but important points:
Speed of compilation, reliability, code quality, resource efficiency.

And because this is not the 90'ies anymore where any new language automatically
gained hordes of new users, compatibility (in one way or another) with existing languages is also very important point.

_________________
Selur erutangis siht

Quote:

Wanderer: 10. Readability gives speed. 12. Keep (human) memory usage low. Quote: ChrisH: PortablE does not require header files, nor makefiles Wanderer: That's good.

My 2 cents here is that header files are almost a good thing. The argument is that the best way to achieve readability and put less strain on the brain is not to require that all the details of the software be grokked at once.

ie, the secret to controlling complexity is information hiding. Modular software separates the information needed to program using it from the information needed to understand all the details of how it works.

.h files, if carefully used, can contribute to this reduction in complexity when they make it unnecessary to plough through the .c files. Their flaw is that they are really only text includes; nothing enforces the exporting of functions and variables not residing in the .h file, and usually more information has to be exposed in the .h file than should be necessary for a good abstract data type.

Here I would go through your points one by one showing how my Yet Another OS4 Language Project is superior but instead I'll just point you to the PDF posted on my web page:
Aglet Modula-2.

Make files, on the other hand, I can't defend at all. It often seems to me that they take up about 50% of the effort of any C programming project.
If your language requires that any imported objects be declared in the source, then the compiling system can determine the dependency tree itself and make sure everything is consistent. (Here there is another advantage to keeping implementation and interface separate, since a well defined interface will be dependent on many fewer other modules than its implementation.)

regards,

Tom

@Samurai_Crow

LLVM-Lua is very interesting. I dont know much about ASM or how Lua binds in LLVM-Lua.

I need to read more on Lua bindings

@Wanderer

The main reason I ask to be compiled by itsef is so we dont get stuck with an IDE/compiler that cant be ported easily.

I agree that functions/subs/procedures should be detected from anywhere in code.
However, leaving these code blocks in the same place makes messy code.

I would prefer code blocks to be moved/hidden away of the same type, but allow a list to access, lookup the syntax easily. A good example of its usage is a must.

I hate writing GUIs for Amiga. Just simple GUIs take a alot of code.
Detecting events is another pain.

A simple GUI window with 2 gadgets, fully detected should be 5 - 10 lines code max.

Then adding each new gadget should be 1 to 2 lines of code.

Coders are not GUI designers and should not have to worry too much about how to create the GUI gadgets, and spend more time on the core functions of the application.

Regarding Warning messages, each warning type could be set to ignore/hide etc.

For larger projects it would help if we could group gadgets together, into gadget containers,
especially if using arrays of gadgets.

Then easily access the gadget eg

textbox = New TextBox

textbox.x = 0
textbox.y = 0
textbox.text = ""

or

GUIStruct Container{
tab1
tab1.Tab[0].new textbox
tab1.Tab[1].new button1
Containerbutton
}

Window1.Container1.tab1.Tab[0].textbox.x = 100,50,"Hello" ; textbox.x = 100, y = 50, text = "hello"
Window1.Container1.tab1.Tab[1].button1.text = "Button on tab 1"
Window1.Container1.Containerbutton.text = "Button on container"

array:
Window1[1].Container1[1].tab1[1].Tab[0].textbox[1].x = 100,50,"Hello" ; textbox.x = 100, y = 50, text = "hello"

window2 = New Window.Default or window2[1] = New Window.Default ' new default window, window array 1

window2.New Container2 = new container ; create container to new window

window2.Container2 = window1.Container1 or window2.Container2 = window1.Container1.Copy

print window2.Container2.tab1.Tab[0].textbox.x
100

window1.Container1.x = 500 ; move container and all gadgets attached

MyMove.x = new alias window1.Container1.x ; create a shortcut to Container.x

MyMove.x = 100 ; move Window1.Container1.x to coord 100, and all gadgets

_________________

@Wanderer

Quote:

Wanderer wrote: 10 secs are too long. It doesn't matter how large the project is from the user point of view. Your brain looses focus and gets bored. Amiblitz3 has never compiled longer than 10 secs, even for beasts like HD-Rec.

Mattathias is planning on using the LLVM JIT compiler for experimental development builds thus relieving most of the time needed to compile since the compiler has no need to optimize the code ahead of time. Of course this assumes that you have a JIT compiler or interpreter for every supported platform.

The final compile is another story. The final compile will be heavily optimized by the LLVM optimizer. This will probably take a long time to compile since it will be doing that much more to tune the code automatically.

This is necessary because inline Assembly is deprecated on some platforms and always a pain to have to work with for the programmer. Sometimes it is more error-prone than an automatic optimizer would be also.
Quote:

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. That's cool. I agree.

As do I.
Quote:

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. For x86 I agree. PPC I dunno. 68K should be definetly in. Sometime you simply need to perform some ASM stunts to get the trick done.

Inline Assembly is officially deprecated in AmigaOS 4.x by the Hyperion team with regards to keeping the code maintainable. If designing a compiler that supports native code generation, then they'll help us work with the code generation, but not the inline Assembly support.
Quote:

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++. Yep, question is how the C/C++ code looks like.

Since LLVM's optimizer is used by a couple of C compilers including the C++ compiler used at Cray Research, it shouldn't be difficult to get code that is as fast as C/C++.

Quote:

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. Access to the AmigaOS and 3rd Party libraries is not a runtime. That is acutally exactly what the runtime should replace, so that the code gets portable. C does this very rudimentary for fileI/O, this is why a CLI tool is ported in 5min while everything else (GUI etc.) is almost a re-write. In "A" you will have a fullgrown runtime. Lets say SDL is comparable. So you can write your entire program only using the runtime. The runtime needs to be ported only once, and those apps will be ported implicitly. That the benefit of closed programming langugaes. But as I said, only the runtime is too limiting. You cannot pack all you ever need in it.

At one time there was a project called the Amiga Foundation Classes intended for use with AmigaE and C++ in object-oriented code. It was abandoned because the E compiler couldn't do dead-code elimination as all modern C++ compilers can. Will A's optimizer be able to throw away any unused code?
Quote:

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. BASIC is only readable as long as you do "basic" stuff. On everything else the code will blow up in an unmaintainable monster. C is good on larger projects, but waists far to many lines for technical things that are actually not solving the problem you are working on rater the battle against the compiler.

Object oriented BASIC-like languages are fine as long as they are readable and can be easily typed. This is more of a requirement of the IDE's editor regarding Intellisense and other techniques for letting the computer write sections of code for you as you type.
Quote:

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. OOP saves memory usage, if done correctly, and it perfectly cooperates with the online-help. You type the variable name that you know because you just defined it or got it elswere, and you get a lost of methods you can do with it. On the other hand you can create terrible monsters with it, I know. But it should be used in a modern language I think. At least as on offer, not mandatory. And it should go smooth, this means that if you create an object, you should not be doomed to do everything OOP from now on. "A" can handle this quite nice I think, because Classes are only Strcutures, the methods come seperate. No magic around it.

See my remarks above regarding the Amiga Foundation Classes.
Quote:

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. Well, till then we are doomed to your personal taste and mood.

LLVM is Free and open-source with a BSD-like license. Mattathias is beiing designed under LGPL becuase that is the license of the sdlBasic runtime library. We used a parser generator written under the MIT license also.

Which license do you prefer?

Re: ChrisH's AmigaE implementation:
Personally I think more programming languages are better if they add more applications to the destination platforms. Since there are a lot of applications written for AmigaE that wouldn't run on AmigaOS 4.x or AROS without additional porting, I think it is worthwhile to have PortablE around.

Re: A/A++ vs. C/C++
I think A/A++ are new languages and whether they are good or not may not get much attention unless they add something useful above and beyond the feature set of C++ or deliver the same results with simpler syntax. As far as I can tell, it is delivering fewer results with syntax that isn't much simpler than C.

If there was a beginner looking to start programming I'd recommend something other than A/A++ or C/C++. I've been recommending Python on the non-Amiga forums I go to but it yields slower executables than C. C or C++ would be my next recommendation even though I hate C-like syntax. It's a pity there aren't more programmers that use Object Pascal (such as FreePascal on MorphOS and AmigaOS 4.x) since it has a much more usable syntax than C++.

Re:Parser generation
I'd recommend using a PEG parser generator of some sort to write the parser. That makes it easier to write backends on more than one platform. I'm looking at YARDparser for C++ as a backend to implement a way to "freeze" a parser by compiling it once it has reached a stable state. Although the C++ templates are a little more typing than the Mattathias PEG parser generator syntax, it generates simple and efficient parser code. All it needs now is a "map" function to speed up the string comparisons.

What are your thoughts on these?

@Samurai_Crow

A/A++ is simplier than C. But it is not intended to be a beginners language. It is very easy to learn fpr people who know programming. Anyway, beginners do not write valuable software, this is not the target of A.
See what people are using Hollywood and what they acutally did with it. There is not a single program that really makes sense. (of course, for presentations it's good).

A itself has no functionality. This is were A++ comes into play. A++ is the powerful runtime library written in A. Why the hell should I be able to do this better?
- because I was writing a runtime library for Amiblitz3 for over 10 years now. This runtime will be ported to A.

See this example: (unfortunately the code looks messy wihtout indenting)

[code]
img.Image = New(CLIArg[1])

win.Window = New( Tags(#WA_AutoAdjust,1, \
#WA_InnerWidth, img\width, \
#WA_InnerHeight, img\height, \
#WA_BackFill,#LAYERS_NOBACKFILL, \
#TAG_DONE))

img\Blit(0,0,win\RPort)

quit.B = False

While (!quit) {
Wait ($FFFFFFFF)
*msg.IntuiMessage = GetMsg(win\UserPort)
Select(*msg\Class) {
Case #IDCMP_CLOSEWINDOW : quit = True
}
}
win\CloseWindow()
img\Free()
End
[/code]

This is already a nice image viewer for WB.
This would be so much more code in C.
Of course, the most lenghty thing here is the message loop, that is still done by AmigaOS and not the runtime.

If you would use NTUI Toolkit, the whole thing would get portable across OSes:

[code]
;/* ======= create a new ntui engine ===== */
*engine.ntuiEngine = New("Pic Viewer")

;/* ======= create a new window ===== */
*win.ntuiWindow = engine\CreateWindow("Pic Viewer Window")
win\BeginVGroup()
win\Image(imagefile,#TUIF_Centered)
win\EndGroup()

win\Show()

;/* ========= Message Loop ========== */
quit.B = False
While (!quit) {
*event.ntuiEvent = engine\WaitEvent()
Select (event\Notify) { ; go for the notification value we got...
Case #NOTIFY_CLOSE
quit = True
}
}
}

;/* ========== CleanUp & Exit =========== */
Delete(engine) ;/* free the tui engine (and close all windows) */
End
[/code]

Last edited by Wanderer on 17-Jun-2009 at 11:11 AM.
Last edited by Wanderer on 17-Jun-2009 at 11:09 AM.
Last edited by Wanderer on 17-Jun-2009 at 11:08 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

Whatever happened with A/A++?

_________________
--
-=#Val#=-
Valiant@Camelot


Amiga 1000; Amiga 2000; Amiga 3000T; CD-TV; CD32;
AmigaOne-XE 800Mhz G4;Sam400ep 666Mhz;
AmigaOne X-1000 1.8Ghz PA6T-1682M

@Valiant

I have very high workload (kids, phd thesis, work, amiga projects like NTUI, AmegaOne, HD-Rec etc.). But A++ is progressing, even if slow. I have a compiler that spits out virtual code and a virtual machine to run it. Both are easily portable accross different architectures, endianess and 32/64/N bit width). It can already be used to write small scripts, however, some features are still unimplemented, like OOP style access to structs, as well as LLVM or plain C backend to produce native binaries.

If you want to use a Basic style language NOW (to be on topic), I recommend to use Ambilitz3.

Interessting thread though, totally forgot about it. Interessting to see how I thought 2009.

_________________
--
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

@tbreeden

GCC is pretty good at figuring out the dependencies between C files on its own, so the Makefile really doesn't need to contain a lot of stuff. And best of all, you don't even need to write it yourself, you can of course get help on this, making one perfect Makefile that'll last for as long as you live

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Wanderer

Thanks for the progress report. Ambilitz3 is one of the tools I'm looking at, although the ACE compiler is what I mostly continue to use. Also thank you for all you've done on HD-Rec. I only looked at it a little, but it's something I'd like to get into a lot more in the future.

_________________
--
-=#Val#=-
Valiant@Camelot


Amiga 1000; Amiga 2000; Amiga 3000T; CD-TV; CD32;
AmigaOne-XE 800Mhz G4;Sam400ep 666Mhz;
AmigaOne X-1000 1.8Ghz PA6T-1682M

@Wanderer

Quote:

Both are "A" syntax, and everybody reading this thread understands them intuitively. But the last one cost you 5 secs to understand, not 30 secs like the upper one.

Regarding "understanding", I don't think it's very fair that you are allowed to hide the constructor & destructor code from "OOP version"

It also seems to be rather extreme (when has been the last time you have really used a programming language, that doesn't support functions, that either take object to initialize as argument, or return a new (pointer to) object)? I mean, I have done "something like that" on 6502 assembly language (of course not using structs / objects, but per-value tables, as that's the most efficient way on that cpu)

In my opinion, object orientedness has less to do with programming language features, and more with the kind of style the programmer prefers.

Of course language features can make certain "right" things easier to do, and certain "wrong" things harder, but that's all it is - an (in)competent programmer will always find a way