Heat from FreeBasic

[marcov]

Hate it or not, the world has chosen C,

C syntax, not C. Very, very big difference.

the world has chosen curly braces because the victory of US based keyboard, it is short and easier to understand, especially if you are good at calculus, familiar with function defined by f(x) like most of people in the world. If German based keyboard was used international thing could be changed.

Total nonsense. C syntax being a success has nothing to do with syntactic merits of C, but rather by deep entrenchment in Unix, and via that in systems programming, and subsequent pushes by certain big vendors.

People were just too lazy to retrain, even to an obvious better solution than Pascal :-)

The real heat from FB I mentioned is it growing mature of RAD IDE.

Afaik most of the RAD efforts started last year, and more fixed IDEs with some codegeneration options rather than full RADs. There is no heat, and no maturing. That is at least 5 years away. Worse, most FBers seem to be stuck in toying with math problems and drawing them with dos-like graphic using macros to cover up language defects. A few make small games. Who is going to use them for more than basic IDE services?

Many are still discussing if multiple-source programs, project files and code reuse (rather than stuffing it in one big one) aren't  communist plots.

New people and often clueless look for the hype basic is easy and go to it, when they used to it they will not look for anything other. You see, they only change from basic dialect, powerbasic to freebasic, but not to freepascal. That is what I want to tell all of you.

Most of them won't change at all. The vibe that I get from most PBers and other commercial basics is that they are  relatively old, often retired people still dabbling in what they used to augment their working practice with (mortgage brokers and other small businesses). Most won't change to anything more modern, except maybe if it is a total blind drop-in. So even FB, let alone further like FPC/Lazarus.

And the few that change, need to get something done, and probably will get something polished. FPC/Lazarus cards are better than FB, but looking further to e.g. Java or so might also be a possibility
 

[munair]

The problem with curly braces as being used in C, C++ and also Go, is that they can be difficult to distinguish from parentheses and normal braces, which makes the code harder to read (some fonts are better in making them look different). Therefore I would prefer short words -- two or three letters at most -- to do the block markings. Fortunately the English language provides that possibility.

For example, in Go:

Code: [Select]

if operator == token.EQUAL {
  return nativeBoolToBooleanObject(left == right)
}
versus:

Code: [Select]

if operator == token.EQUAL do
  return nativeBoolToBooleanObject(left == right)
end
The second version makes the code instantly easier to read.

[munair]

Personally I would favour a compiler that produces byte code for a VM that can run on any system. Much easier to maintain with only some performance cost.

That sounds like Java.  Its "some performance cost" is a bit on the high side but, that doesn't seem to have hurt it much.

It also sounds like the .NET languages. MS could easily provide a .NET run-time for Linux, but they won't (for obvious reasons).

[marcov]

The problem with curly braces as being used in C, C++ and also Go, is that they can be difficult to distinguish from parentheses and normal braces, which makes the code harder to read (some fonts are better in making them look different).

(And might require moving your hand to type and require meta keys like shift or alt-gr, slowing your typing)

Therefore I would prefer short words -- two or three letters at most -- to do the block markings. Fortunately the English language provides that possibility.

Better, but I don't really see much reasons to wrangle yourself in strange twists to make it shorter than "then" . English doesn't have that many wellknown extreme short words, and IDEs can generate them using templates half of the time or more anyway. Better use a few longer ones, than reusing two letter words (in, do are the only ones that come to mind and already take in pascal) in multiplaces

Of course, the first thing to shave off in many non C curly branches language is the double =, since most of the languages don't subscribe to the paradigm that cause it in plain C.

[munair]

Better, but I don't really see much reasons to wrangle yourself in strange twists to make it shorter than "then" . English doesn't have that many wellknown extreme short words, and IDEs can generate them using templates half of the time or more anyway. Better use a few longer ones, than reusing two letter words (in, do are the only ones that come to mind and already take in pascal) in multiplaces.

There are no twists involved when developing a language that consistently uses DO..END as execution block markers. It avoids the need to parse unique markers for different constructs which would result in a more verbose language anyway. IF..THEN BEGIN..END or IF..DO..END, I prefer the latter. Likewise WHILE..DO BEGIN..END versus WHILE..DO..END.

Parsing IF statements without explicit THEN is rather simple:

Code: [Select]

exp := []*ast.TIfCondition { parseIfCondition() }
for peekTokenIs(token.ELSEIF) || peekTokenIs(token.ELSE) {
  nextToken()
  if curTokenIs(token.ELSE) {  // else
    stmt.Default = parseBlockStatement(ifBlock) // do..end
    break
  } else { // elseif (no need to parse "then")
    exp = append(exp, parseIfCondition())
  }
}
Next to DO and IN, there is OF, which can be used for definition blocks like TYPE .. OF..END. It makes it instantly recognizable as a definition or declaration.

In the early days of programming high level language development was geared towards mimicking human language constructs which is why it was thought that IF should be followed by THEN. Later languages stepped away from that and became more creative with "logical" constructs like IF..FI (sic).

(And might require moving your hand to type and require meta keys like shift or alt-gr, slowing your typing)

That is a very valid argument.

[ASBzone]

It also sounds like the .NET languages. MS could easily provide a .NET run-time for Linux, but they won't (for obvious reasons).

There is .NET Core...

[marcov]

Better, but I don't really see much reasons to wrangle yourself in strange twists to make it shorter than "then" . English doesn't have that many wellknown extreme short words, and IDEs can generate them using templates half of the time or more anyway. Better use a few longer ones, than reusing two letter words (in, do are the only ones that come to mind and already take in pascal) in multiplaces.

There are no twists involved when developing a language that consistently uses DO..END as execution block markers. It avoids the need to parse unique markers for different constructs which would result in a more verbose language anyway. IF..THEN BEGIN..END or IF..DO..END, I prefer the latter. Likewise WHILE..DO BEGIN..END versus WHILE..DO..END.

I love to skip begin too in a new language, but I don't see the need to change "then" to "do", and to only have do.

But indeed, if you have a robust block structure, so that nesting is less likely to hurt, it matters less, and goes into the realm of aesthetics and taste.

[BeniBela]

If you or anyone knows, how to make that work with any terminal (or with most terminals), then please let us know. We really like to implement this. But we currently have no information how to do this.

And it may be, that other projects have managed to do this. But unless we know how, this is not helping.

This should work:

Lazarus starts terminal for a wrapper .

The wrapper suspends itself, before execing the actual program.

The debugger attaches itself to the wrapper and unsuspends it, which then becomes the actual program



Alternatively, Lazarus could implement its own terminal.

[axisdj]

I am a VB6 fugitive just now trying to move to lazarus. Actually cheating a bit and having a company do part of the migration for me.

My dream solution would have been to have lazarus go into a mode where it can interrupt the vb6 code and then compile as it does now. I know it would not be perfect but ..

I have managed to maneuver the IDE to get it close to vb6 I was used to... changing languages after 20 years is tough for me, I am a master at vb6, but is is necessary.

[giahung1997]

If you or anyone knows, how to make that work with any terminal (or with most terminals), then please let us know. We really like to implement this. But we currently have no information how to do this.

And it may be, that other projects have managed to do this. But unless we know how, this is not helping.

This should work:

Lazarus starts terminal for a wrapper .

The wrapper suspends itself, before execing the actual program.

The debugger attaches itself to the wrapper and unsuspends it, which then becomes the actual program



Alternatively, Lazarus could implement its own terminal.

As I have told the devs but only to be boo-ed like Roman Reigns, that thing called libvte (virtual terminal) 

[giahung1997]

It also sounds like the .NET languages. MS could easily provide a .NET run-time for Linux, but they won't (for obvious reasons).

There is .NET Core...

That shite is Linux only, nowhere near to the cross platforms of Mono (now also MS owned). FreeBSD tried to port it but failed miserably.

[giahung1997]

^languages war: the closest thing to your syntax description is OpenDylan, as I know, but it IDE sucks.

[marcov]

My dream solution would have been to have lazarus go into a mode where it can interrupt the vb6 code and then compile as it does now. I know it would not be perfect but ..

The more a language is compiled, the harder this is. In short, this is simply not a realistic target for a multi-target compiler.

[marcov]

^languages war: the closest thing to your syntax description is OpenDylan, as I know, but it IDE sucks.

And in general, IMHO the total picture of a development system (language, compiler, library, IDE) is much more important than most language details.

[Martin_fr]

About the debugger stuff: https://forum.lazarus.freepascal.org/index.php?topic=45257