Aer Language Specification

belliash commented

2018-07-17 14:40:06 +02:00

Owner

On our wiki I have prepared some draft version of Aer language specification

In this ticket, we will discuss the specification and syntax.
As the result of this ticket, the final version of Aer 1.0 specification should be done.

On our wiki I have prepared some draft version of [Aer language specification](https://git.codingworkshop.eu.org/AerScript/Aer/wiki/Aer-v1.0-Specification) In this ticket, we will discuss the specification and syntax. As the result of this ticket, the final version of Aer 1.0 specification should be done.

belliash self-assigned this 2018-07-17 14:40:06 +02:00

belliash added the

question

label 2018-07-17 14:40:06 +02:00

likoski added the

idea

label 2018-07-17 17:20:05 +02:00

likoski commented

2018-07-17 17:27:04 +02:00

Owner

I have read specification partially. Simple question I've got is why to support functional programming? I see just one disadvantage of abandoning it - potential developers will be disallowed of interlacing P# code with other data, like HTML or XML. They will be forced to use some architectural pattern, like MVC. But when I'm thinking about it, I'm starting to believe it would be however an advantage.

bernardobreder commented

2018-07-17 18:11:15 +02:00

First, I am understanding that the specification discussion should occur in parallel with the initial PH7 settings.

I do not know the group's opinion, but when PHP was specified, the understanding of web programming language is quite different from today. Today we have pages being created with Angular, Tomcat, React and others that greatly explore the separation between presentation layer, data model and controller. In addition, there is also the Passive View model which is a model similar to MVC, but very good for automated testing.

An important question we should answer: What kind of project would language like to specialize? Short projects, with rapid prototyping and difficult to maintain with growing OR projects with good life time, but not fast in prototyping? Should be closer to Java, PHP, Angular. Each language has a well-defined design ideology.

I do not know the group's opinion, but I classify PHP as being the first type of project. When the project begins to grow due to lack of programming language resources for modularization of the project, giving the responsibility for the developer to define patterns that cause this modularization, the project becomes increasingly difficult to maintain and grow.

I understand that the project has some assumptions already well defined that should not be ignored.

It's an interpreted language
The project can be installed in an embedded environment
The language should be developed in C
Initially, the PH7 virtual machine will be used

Initially, I can contribute with 3 points:

If it is an embedded language, I see no reason to have an interpreter at runtime. As the result of the project is to have few memory and code usage, it adds in the embedded set of interpretation code, which will rarely be used, I find a waste. I think that the code compilation should generate bytecodes (set of bytes) and I should put in the embedded only the virtual machine and bytecode, discarding all interpretation code (Parser, Lexer, Tokenalizer, Nodes, ...)
I have a lot of experience in creating virtual machine and I am studying the code PH7 to see the implications in this language when we specify. I see that using a non-100% OO virtual machine to emulate the OO features can cause a large overhead, since in each method call that overhead will be considered.
As the development environment of the PHP era has changed a lot, and since we have a strong competitor in web site creation, we could think of repagging the syntax of the language, not simply adding new features to PHP, being similar to an improved and oriented PHP to object.

First, I am understanding that the specification discussion should occur in parallel with the initial PH7 settings. I do not know the group's opinion, but when PHP was specified, the understanding of web programming language is quite different from today. Today we have pages being created with Angular, Tomcat, React and others that greatly explore the separation between presentation layer, data model and controller. In addition, there is also the Passive View model which is a model similar to MVC, but very good for automated testing. An important question we should answer: What kind of project would language like to specialize? Short projects, with rapid prototyping and difficult to maintain with growing OR projects with good life time, but not fast in prototyping? Should be closer to Java, PHP, Angular. Each language has a well-defined design ideology. I do not know the group's opinion, but I classify PHP as being the first type of project. When the project begins to grow due to lack of programming language resources for modularization of the project, giving the responsibility for the developer to define patterns that cause this modularization, the project becomes increasingly difficult to maintain and grow. I understand that the project has some assumptions already well defined that should not be ignored. - It's an interpreted language - The project can be installed in an embedded environment - The language should be developed in C - Initially, the PH7 virtual machine will be used Initially, I can contribute with 3 points: 1. If it is an embedded language, I see no reason to have an interpreter at runtime. As the result of the project is to have few memory and code usage, it adds in the embedded set of interpretation code, which will rarely be used, I find a waste. I think that the code compilation should generate bytecodes (set of bytes) and I should put in the embedded only the virtual machine and bytecode, discarding all interpretation code (Parser, Lexer, Tokenalizer, Nodes, ...) 2. I have a lot of experience in creating virtual machine and I am studying the code PH7 to see the implications in this language when we specify. I see that using a non-100% OO virtual machine to emulate the OO features can cause a large overhead, since in each method call that overhead will be considered. 3. As the development environment of the PHP era has changed a lot, and since we have a strong competitor in web site creation, we could think of repagging the syntax of the language, not simply adding new features to PHP, being similar to an improved and oriented PHP to object.

belliash commented

2018-07-17 19:14:50 +02:00

Author

Owner

I was thinking about fully OOP interpreted language, like Java or C#. This is still an option for me. In my opinion, if developer has to write some small script for any, especially embedded environment, he will probably use other scripting language - even bash. It is a powerful tool that allows to write a complex scripts, as well as websites. For example Gargoyle WebUI is written in bash with a haserl support. I think this is not what we want to achieve with P#.
On the other hand, having fully OOP language, does not cross out its usage for smaller scripts:

<%
    class Main() {
        void __construct() {
            print('Hello World!');
        }
    }
%>

I believe, that above code snippet cannot be considered as too long and a developer will not need to spend much more time to write simple hello world script.

I agree with Bernardo, that the understanding of web programming language is quite different nowadays. More and more web applications are using OOP and some kind of patterns to separate the presentation layer. Thus I would not worry about mixing P# with HTML. It is in general bad idea to do so, and many web developers does it, because they use PHP which allows them to. But IMHO its not a good practise. If P# would not allow for that, it will be just another advantage for it over old PHP.

I also would like to not limit the role of P# to websites development. In general, I see there at least 3 SAPIs: CLI, CGI, FastCGI allowing to develop a variety of scripts. While the last one would be most probably used for web development, the 2nd, old CGI SAPI can allow to code some interfaces for embedded devices. They usually don't have a power to host Apache or nGinx. But small uHTTPd can serve P#-coded site just via CGI. Finally, the CLI SAPI, that allows to write some scripts running from command line. And I don't see any limit here. PHP used to be a general-purpose language. There a lot of software written in PHP, even some IRC both or HTTP servers. This shows the power and ability of PHP, even it was designed originally for creating web sites.

Having all that said I think, we should compare P# to PHP with a combination of C#/Java syntax.

According to Bernardo points:

In my opinion, P# should work as a simple interpreter. Even the produced bytecode can be hardware-independent, I think this should be an option, sometime in the future. If we consider this in order to save a time and/or memory, then why not produce native binary? I think this is not the way. I'd like to divide the Interpreter into modules and give programmers ability to load them dynamically (like via dl() function in PHP). The difference is that, my idea assumes that all modules are available on a disk storage, but are loaded only from inside the script. In PHP it works a bit different, because there module can be automatically loaded, depending on php.ini configuration. Thus, even not used, will consume memory.
Finally, I don't know any other fully OOP interpreted language with well-known syntax.
I believe we want to base first version of our interpreter on PH7. In later versions we can think about replacing this component with something more robust, additionally allowing to skip some steps like lexer.
Actually the draft specification does not follow strictly PHP. It is rather a mix of PHP, C# and Java. Anyway, it is based on PHP for few reasons:

the C-family, Java and PHP are most popular languages, basing on them makes easier to switch,
PHP is easy language. It's syntax is not so complicated, as it does not have to be,
finally, we use PH7 Engine, which implements a subset of PHP - what gives us ability to reuse the code.
On the other side, PHP misses a lot of features, Id really like to see, like:
strict data typing,
multiple inheritance,
or method overloading

I think, that currently we should focus on the final syntax and features available in P# 1.0, while fixing bugs in PH7 and cleaning the code, to make it ready for customisation.

BTW: I have just added a chapter describing references in P#.
I am looking forward to hearing your opinions about the language construct.

Also +1 from me for full OOP, as in example above.

I was thinking about fully OOP interpreted language, like Java or C#. This is still an option for me. In my opinion, if developer has to write some small script for any, especially embedded environment, he will probably use other scripting language - even bash. It is a powerful tool that allows to write a complex scripts, as well as websites. For example Gargoyle WebUI is written in bash with a haserl support. I think this is not what we want to achieve with P#. On the other hand, having fully OOP language, does not cross out its usage for smaller scripts: <% class Main() { void __construct() { print('Hello World!'); } } %> I believe, that above code snippet cannot be considered as too long and a developer will not need to spend much more time to write simple hello world script. I agree with Bernardo, that the understanding of web programming language is quite different nowadays. More and more web applications are using OOP and some kind of patterns to separate the presentation layer. Thus I would not worry about mixing P# with HTML. It is in general bad idea to do so, and many web developers does it, because they use PHP which allows them to. But IMHO its not a good practise. If P# would not allow for that, it will be just another advantage for it over old PHP. I also would like to not limit the role of P# to websites development. In general, I see there at least 3 SAPIs: CLI, CGI, FastCGI allowing to develop a variety of scripts. While the last one would be most probably used for web development, the 2nd, old CGI SAPI can allow to code some interfaces for embedded devices. They usually don't have a power to host Apache or nGinx. But small uHTTPd can serve P#-coded site just via CGI. Finally, the CLI SAPI, that allows to write some scripts running from command line. And I don't see any limit here. PHP used to be a general-purpose language. There a lot of software written in PHP, even some IRC both or HTTP servers. This shows the power and ability of PHP, even it was designed originally for creating web sites. Having all that said I think, we should compare P# to PHP with a combination of C#/Java syntax. According to Bernardo points: 1. In my opinion, P# should work as a simple interpreter. Even the produced bytecode can be hardware-independent, I think this should be an option, sometime in the future. If we consider this in order to save a time and/or memory, then why not produce native binary? I think this is not the way. I'd like to divide the Interpreter into modules and give programmers ability to load them dynamically (like via dl() function in PHP). The difference is that, my idea assumes that all modules are available on a disk storage, but are loaded only from inside the script. In PHP it works a bit different, because there module can be automatically loaded, depending on php.ini configuration. Thus, even not used, will consume memory. Finally, I don't know any other fully OOP interpreted language with well-known syntax. 2. I believe we want to base first version of our interpreter on PH7. In later versions we can think about replacing this component with something more robust, additionally allowing to skip some steps like lexer. 3. Actually the draft specification does not follow strictly PHP. It is rather a mix of PHP, C# and Java. Anyway, it is based on PHP for few reasons: * the C-family, Java and PHP are most popular languages, basing on them makes easier to switch, * PHP is easy language. It's syntax is not so complicated, as it does not have to be, * finally, we use PH7 Engine, which implements a subset of PHP - what gives us ability to reuse the code. On the other side, PHP misses a lot of features, Id really like to see, like: * strict data typing, * multiple inheritance, * or method overloading I think, that currently we should focus on the final syntax and features available in P# 1.0, while fixing bugs in PH7 and cleaning the code, to make it ready for customisation. BTW: I have just added a chapter describing references in P#. I am looking forward to hearing your opinions about the language construct. Also +1 from me for full OOP, as in example above.

bernardobreder commented

2018-07-17 20:47:42 +02:00

I think P # could run snippers and build site. I agree that the P # language may have a lot of source code already installed on the disk itself. I agree that the language should be OOP and we can use the PH7 virtual machine to run. I have not yet studied how difficult this emulation is.
I also do not see problem in mixing P # code with Html, Css, as long as it is well modularized and separated into different file source. For example, in Angular a component has an Angular file, Html file and Css file. I think this separation makes clear the responsibilities. For me, PHP blends HTML code with PHP code, and I do not think it's good. But we're here to talk.
My biggest concern at this current stage is that we are defining a syntax similar to PHP just because we want to reuse the PH7 interpreter. The syntax represents the language and the syntax that is defined in the first version, will be the definitive one, since it will have several other tasks with priorities afterwards. For example, because we are using the PH7 interpreter, we will have to use a syntax <% ...%> to reference the P # code, where we only find this in PHP code. Do we need to limit ourselves to this?

I think we have important questions to answer:

Should we have a PHP base syntax in the P # language because of reuse of the PH7 code ? That to me is the biggest thread on this topic. Worth it ?
Building an interpreter is not a difficult task. Building a virtual machine is not extremely complicated. Being able to specify the syntax that we find most appropriate can have many benefits. I just wish you could think of the possibility.
It is an option, to have another parallel project of a virtual machine, another one of a compiler for the virtual machine and a third project for the construction of libraries for the language. I find this very interesting.

My goal is not to cause discordance. My goal is to show that we can specify a language as we think best. For example:

class Main {
  init() {
    log.print('hello')
  }
}

or

class Main {
  public string execute() {
    int a = 5
    return `
      <html>
        <body>${a}</body>
      </html>
    `
  }
}

- I think P # could run snippers and build site. I agree that the P # language may have a lot of source code already installed on the disk itself. I agree that the language should be OOP and we can use the PH7 virtual machine to run. I have not yet studied how difficult this emulation is. - I also do not see problem in mixing P # code with Html, Css, as long as it is well modularized and separated into different file source. For example, in Angular a component has an Angular file, Html file and Css file. I think this separation makes clear the responsibilities. For me, PHP blends HTML code with PHP code, and I do not think it's good. But we're here to talk. - My biggest concern at this current stage is that we are defining a syntax similar to PHP just because we want to reuse the PH7 interpreter. The syntax represents the language and the syntax that is defined in the first version, will be the definitive one, since it will have several other tasks with priorities afterwards. For example, because we are using the PH7 interpreter, we will have to use a syntax <% ...%> to reference the P # code, where we only find this in PHP code. Do we need to limit ourselves to this? I think we have important questions to answer: 1. Should we have a PHP base syntax in the P # language because of reuse of the PH7 code ? That to me is the biggest thread on this topic. Worth it ? 2. Building an interpreter is not a difficult task. Building a virtual machine is not extremely complicated. Being able to specify the syntax that we find most appropriate can have many benefits. I just wish you could think of the possibility. 3. It is an option, to have another parallel project of a virtual machine, another one of a compiler for the virtual machine and a third project for the construction of libraries for the language. I find this very interesting. My goal is not to cause discordance. My goal is to show that we can specify a language as we think best. For example: ``` class Main { init() { log.print('hello') } } ``` or ``` class Main { public string execute() { int a = 5 return ` <html> <body>${a}</body> </html> ` } } ```

BigDave commented

2018-07-17 20:50:56 +02:00

Ha i did this just 2 weeks ago using Microsoft/ChakraCore it took some doing i can tell ya but works awsome also added dll|so loading but got bored once i started working on psharp

but the code was like so

not the same but kindof close

es6/7 is pretty cool

Ha i did this just 2 weeks ago using [Microsoft/ChakraCore](https://github.com/Microsoft/ChakraCore) it took some doing i can tell ya but works awsome also added dll|so loading but got bored once i started working on psharp but the code was like so ![img](https://i.imgur.com/XZZaAaV.png) not the same but kindof close es6/7 is pretty cool

belliash commented

2018-07-18 06:28:53 +02:00

Author

Owner

Well, it's not true that we are defining a syntax similar to PHP just because we want to reuse the PH7 interpreter. For example the need to embed the code between <% and %> tags was dictated by functional programming. When I was preparing a draft specification, I thought it might be a good idea. But during this discussion I realized I was wrong. Especially, if we decide to implement only OOP paradigm, I see no further reason why to not strip this off from PH7. This should not be so hard task.

I based the syntax not only on PHP. The main idea was to create a language that could be to PHP, what C# is to C++. Thus it was a natural move for me, to base the syntax mostly on PHP. However, there are already modifications introduced, i.e:

virtual classes and methods instead of abstract
multi inheritance instead of traits
methods / functions overloading
etc...

I think currently it is a mix of PHP with C++. And I think this is good. Both are very popular and well-known. Both has some advantages and disadvantages we know and we can try to eliminate. C++ is criticized mostly due to it's complexity and for sure it is a complicated, but yet powerful programming language. But do we need that for interpreted language? Even yes, C++ and PHP due to their very common syntax ale similar somehow and easy to extend. Even we do not implement some functionality in first version of interpreter, I believe we can do that in next release.

For me the biggest concern right now is if P# will support both OOP and functional programming, or just OOP. This influents a lot on language syntax IMHO. When we make this clear, we can discuss other aspects of P# syntax.

Well, it's not true that we are defining a syntax similar to PHP just because we want to reuse the PH7 interpreter. For example the need to embed the code between <% and %> tags was dictated by functional programming. When I was preparing a draft specification, I thought it might be a good idea. But during this discussion I realized I was wrong. Especially, if we decide to implement only OOP paradigm, I see no further reason why to not strip this off from PH7. This should not be so hard task. I based the syntax not only on PHP. The main idea was to create a language that could be to PHP, what C# is to C++. Thus it was a natural move for me, to base the syntax mostly on PHP. However, there are already modifications introduced, i.e: * virtual classes and methods instead of abstract * multi inheritance instead of traits * methods / functions overloading * etc... I think currently it is a mix of PHP with C++. And I think this is good. Both are very popular and well-known. Both has some advantages and disadvantages we know and we can try to eliminate. C++ is criticized mostly due to it's complexity and for sure it is a complicated, but yet powerful programming language. But do we need that for interpreted language? Even yes, C++ and PHP due to their very common syntax ale similar somehow and easy to extend. Even we do not implement some functionality in first version of interpreter, I believe we can do that in next release. For me the biggest concern right now is if P# will support both OOP and functional programming, or just OOP. This influents a lot on language syntax IMHO. When we make this clear, we can discuss other aspects of P# syntax.

Ghost commented

2018-07-18 07:13:10 +02:00

My opinion is that inline code within HTML would be exceedingly beneficial. For example, just take the common for loop: easy HTML tables from whatever existing data. Do you really want to force every one to use stuff like angular? Inline code is likely one of the major use cases for embedded platforms especially since it is possible to call native C functions to communicate with some other functionality.

belliash commented

2018-07-18 08:01:22 +02:00

Author

Owner

LUCI (written in LUA) is used as OpenWrt WebUI. It is also embedded environment. LUCI authors has written a module for LUA for processing templates in C, thus its faster than when it would be written in LUA. Finally, they use MVC and do not mix together LUA with HTML. This is evil. I will repeat, it is not a good idea to have both P# and HTML/CSS/JS/whatever in single file. Templates are a way to go. And if we are thinking about embedded environments, we should also develop some native template parser as a module for P#. Everyone who would be willing to use it, will simply import:

import('chameleon');

@MDTech-us-MAN, do you see any other purpose of this functionality?

LUCI (written in LUA) is used as OpenWrt WebUI. It is also embedded environment. LUCI authors has written a module for LUA for processing templates in C, thus its faster than when it would be written in LUA. Finally, they use MVC and do not mix together LUA with HTML. This is evil. I will repeat, it is not a good idea to have both P# and HTML/CSS/JS/whatever in single file. Templates are a way to go. And if we are thinking about embedded environments, we should also develop some native template parser as a module for P#. Everyone who would be willing to use it, will simply import: import('chameleon'); @MDTech-us-MAN, do you see any other purpose of this functionality?

likoski commented

2018-07-18 10:35:00 +02:00

Owner

I think, P# should be strict OOP language. This has some pros and cons, but for sure will eliminate bad habits.

Actually 2 votes for strict OOP.

I think, P# should be strict OOP language. This has some pros and cons, but for sure will eliminate bad habits. Actually 2 votes for strict OOP.

devnexen commented

2018-07-18 18:21:47 +02:00

Member

I prefer OOP too (and I like the direction it takes mix of C++ and so on), but that all depends which "audience" P# is targetting/where it sets the entry bar.

bernardobreder commented

2018-07-18 18:35:06 +02:00

I think the discussion is good. My Timezone is -03: 00. So I take time to respond depending on the time.

Rafal, I like to see that you do not agree that we have a dependency on a syntax similar to Php just because we're using a Ph7 interpreter. I agree that you do not have this dependency.

I understand that the syntax is similar for the reason of wanting a gradual change from Php, as well as from C to C ++ and C ++ to C #. That was not clear to me.

Taking into account that P # will be a continuation of PHP (as C ++ was C and C # was C ++) adding new language features, using the PH7 as initial source code makes perfect sense. However, if we consider that P # can take another proposal direction, I think we should consider not using PH7 as the initial code because it was created for a purpose other than what we want.

Depending on the response from above, I just do not agree that using an existing interpreter might be more productive than building a new one. The Ph7 interpreter already has contextualized code optimizations and a well-applied architecture that may be difficult to adapt to a new syntax. I just want you to take that into account. For a new language, it may be a natural process to start with a built-in interpreter, with few optimizations for better maturation by all, and over time the interpreter will be optimized.

It has now become clear to me that Rafal would like a language that mixes Php's features with C ++. I see in the new trend of languages in moving away from strange syntax like __constructor. I also get quite annoyed with the <% token, because it already reminds me that it is possible to mix Php code with another type of code like Html. This mix is natural in PHP, but I do not like it. I think each file must have a single type of language. This is something I would like to explore further in the discussion. I agree 100% with the phrase "I will repeat, it is not a good idea to have both P # and HTML / CSS / JS / whatever in single file."

I'll respond more calmly in the other email on the subject: "
For me the biggest concern right now is if P # will support both OOP and functional programming, or just OOP. This influences a lot on language syntax IMHO. When we make this clear, we can discuss other aspects of P # syntax.

I think the discussion is good. My Timezone is -03: 00. So I take time to respond depending on the time. Rafal, I like to see that you do not agree that we have a dependency on a syntax similar to Php just because we're using a Ph7 interpreter. I agree that you do not have this dependency. I understand that the syntax is similar for the reason of wanting a gradual change from Php, as well as from C to C ++ and C ++ to C #. That was not clear to me. Taking into account that P # will be a continuation of PHP (as C ++ was C and C # was C ++) adding new language features, using the PH7 as initial source code makes perfect sense. However, if we consider that P # can take another proposal direction, I think we should consider not using PH7 as the initial code because it was created for a purpose other than what we want. Depending on the response from above, I just do not agree that using an existing interpreter might be more productive than building a new one. The Ph7 interpreter already has contextualized code optimizations and a well-applied architecture that may be difficult to adapt to a new syntax. I just want you to take that into account. For a new language, it may be a natural process to start with a built-in interpreter, with few optimizations for better maturation by all, and over time the interpreter will be optimized. It has now become clear to me that Rafal would like a language that mixes Php's features with C ++. I see in the new trend of languages in moving away from strange syntax like __constructor. I also get quite annoyed with the <% token, because it already reminds me that it is possible to mix Php code with another type of code like Html. This mix is natural in PHP, but I do not like it. I think each file must have a single type of language. This is something I would like to explore further in the discussion. I agree 100% with the phrase "I will repeat, it is not a good idea to have both P # and HTML / CSS / JS / whatever in single file." I'll respond more calmly in the other email on the subject: " For me the biggest concern right now is if P # will support both OOP and functional programming, or just OOP. This influences a lot on language syntax IMHO. When we make this clear, we can discuss other aspects of P # syntax.

belliash commented

2018-07-18 22:06:55 +02:00

Author

Owner

Already half of us agreed that we should abandon functional programming in P#, so I will update the specification soon.

Ghost commented

2018-07-19 04:19:25 +02:00

In one of my side projects, I use this method to create a simple, straightforward webpanel design. My entire purpose there is to make it incredibly simple to get data from the main application in to the web interface in a way that can be easily changed if anyone wants to change the specifics of how it looks or works. Creating an entire MVC system for this seems overkill and overly complicated if I just need some data here and there.

Ghost commented

2018-07-19 04:23:47 +02:00

In fact, even C++ has functional programming working perfectly fine alongside OOP.

ASP.NET Also demonstrates C# using functional programming.

Basically what I'm trying to say is that OOP can coexist with functional. For example, the ASP.Net way uses separate files for inline programming and OOP. This way both are actually optional. Technically, you can exclusively use C# within the HTML and completely ignore the OOP features. Or, you can do the opposite, exclusively use the OOP functionality and ignore the other method.

This way we don't have to exclude either audience.

In fact, even C++ has functional programming working perfectly fine alongside OOP. ASP.NET Also demonstrates C# using functional programming. Basically what I'm trying to say is that OOP can coexist with functional. For example, the ASP.Net way uses separate files for inline programming and OOP. This way both are actually optional. Technically, you can exclusively use C# within the HTML and completely ignore the OOP features. Or, you can do the opposite, exclusively use the OOP functionality and ignore the other method. This way we don't have to exclude either audience.

belliash commented

2018-07-19 06:00:22 +02:00

Author

Owner

@MDTech-us-MAN, thats all True. But Please don't forget that none from C++ and C# has the builtin templates support. So again to analogy to PHP... There are many templates systems like smarty or opt. But they are coded in PHP. This forces you to put more code. But if some of them was builtin i to PHP you would be able just to use it out of the box. If C# would give such library, i believe it would be used instead. First of all, native code is faster. Secondly, there is still no need to write much more code. You just need to separate the logi from presentation. Independent of how big project it is, you should separate them because:

file sizes become smaller. Nobody wants to open 4000 lines of logic mixed with HTML
You don’t have to worry too much about designers damaging the internal workings of your application. They can add design features without having to look at the business logic
It is much cleaner and easier on the eyes
Bugs are easier to hunt down
Your business logic will become easier to modify
It is easier to find certain parts of the application if know where everything is
Re-designs are much less of a hassle

I realize that putting everything i to single file is easier on the beginning, especially in small project. But it is harder in maintenance. If it will grow, you will get lost in your own code. If you come back to it after few months, you will start with analysis what is it really doing and where to add new HTML line. Having it separated, you would just add it in AN appropriate place with some variable defined, and ten define that variable in P# code.

@MDTech-us-MAN, thats all True. But Please don't forget that none from C++ and C# has the builtin templates support. So again to analogy to PHP... There are many templates systems like smarty or opt. But they are coded in PHP. This forces you to put more code. But if some of them was builtin i to PHP you would be able just to use it out of the box. If C# would give such library, i believe it would be used instead. First of all, native code is faster. Secondly, there is still no need to write much more code. You just need to separate the logi from presentation. Independent of how big project it is, you should separate them because: * file sizes become smaller. Nobody wants to open 4000 lines of logic mixed with HTML * You don’t have to worry too much about designers damaging the internal workings of your application. They can add design features without having to look at the business logic * It is much cleaner and easier on the eyes * Bugs are easier to hunt down * Your business logic will become easier to modify * It is easier to find certain parts of the application if know where everything is * Re-designs are much less of a hassle I realize that putting everything i to single file is easier on the beginning, especially in small project. But it is harder in maintenance. If it will grow, you will get lost in your own code. If you come back to it after few months, you will start with analysis what is it really doing and where to add new HTML line. Having it separated, you would just add it in AN appropriate place with some variable defined, and ten define that variable in P# code.

Ghost commented

2018-07-19 06:07:10 +02:00

@belliash It is unfortunate that you did not completely read my comment. I explicitly said that the logic doesn't have to be in the same file as HTML. I'm saying that the logic functions can be called from within the HTML the drop in the required data or dynamically show or exclude some elements.

Also, don't forget that ASP.Net has native MVC features.

@belliash It is unfortunate that you did not completely read my comment. I explicitly said that the logic doesn't have to be in the same file as HTML. I'm saying that the logic functions can be called from within the HTML the drop in the required data or dynamically show or exclude some elements. Also, don't forget that ASP.Net has native MVC features.

belliash commented

2018-07-19 06:23:00 +02:00

Author

Owner

@MDTech-us-MAN, I'm sorry if I misunderstood your comment. I sometimes reply from my mobile phone. I don't have access to computer around 6am.

I think you are talking about the <asp> tag. Is that right?
If yes then, for real (from what I know) it is calling some method, not a function. Correct me please, if I'm wrong. And because there is no such tag in HTML defined, this means that whole HTML code needs to go through compiler/interpreter?

I would also like to add, that both C# and Java are not suitable for embedded environments, because you need whole .NET platform or JVM. The second one also needs a lot of RAM and even you set a heap (-Xms -Xmx) to 64MB, you need at least twice of that available in OS, because Java can allocate it. Without that, kernel can fire up OOM killer and kill your whole java process to same RAM.
Also forgetting embedded environments, both .NET and Java are way too big to host some blog on it. They are like cannon for a mosquito...

@MDTech-us-MAN, I'm sorry if I misunderstood your comment. I sometimes reply from my mobile phone. I don't have access to computer around 6am. I think you are talking about the \<asp\> tag. Is that right? If yes then, for real (from what I know) it is calling some method, not a function. Correct me please, if I'm wrong. And because there is no such tag in HTML defined, this means that whole HTML code needs to go through compiler/interpreter? I would also like to add, that both C# and Java are not suitable for embedded environments, because you need whole .NET platform or JVM. The second one also needs a lot of RAM and even you set a heap (-Xms -Xmx) to 64MB, you need at least twice of that available in OS, because Java can allocate it. Without that, kernel can fire up OOM killer and kill your whole java process to same RAM. Also forgetting embedded environments, both .NET and Java are way too big to host some blog on it. They are like cannon for a mosquito...

devnexen commented

2018-07-19 07:39:11 +02:00

Member

If it was to produce bytecode then native code, might be a silly/irrelevant idea but what about LLVM ?

belliash commented

2018-07-19 10:10:10 +02:00

Author

Owner

I have updated the P# Specification. Looking for your opinions and further ideas. Do we need to change anything else?

@devnexen, I think, we should focus on the interpreter right now. Compiler is an optional, future feature IMHO.

I have updated the P# Specification. Looking for your opinions and further ideas. Do we need to change anything else? @devnexen, I think, we should focus on the interpreter right now. Compiler is an optional, future feature IMHO.

devnexen commented

2018-07-19 10:21:39 +02:00

Member

Should we use the same keyword extends for implementing a virtual class than extending a classic class ?

Should we use the same keyword `extends` for implementing a virtual class than extending a classic class ?

belliash commented

2018-07-19 10:39:12 +02:00

Author

Owner

Well, class is always extended, whether it is virtual class or not (it can, but doesn't have to contain fully-implemented methods), while interface is being implemented, as it contains just a method declarations (without body).

In C# there is single operator (:) for extending classes and implementing interfaces.
Java uses extends and implements keywords for that purpose, same as PHP.

In my opinion keywords are more human-readable than operator. But this is just my opinion.

Well, class is always extended, whether it is virtual class or not (it can, but doesn't have to contain fully-implemented methods), while interface is being implemented, as it contains just a method declarations (without body). In C# there is single operator (:) for extending classes and implementing interfaces. Java uses extends and implements keywords for that purpose, same as PHP. In my opinion keywords are more human-readable than operator. But this is just my opinion.

devnexen commented

2018-07-19 10:42:23 +02:00

Member

Sorry I was unclear in fact I was mentioning Java case implements/extends. Just wanted to have opinions about semantics. I like having just one keyword for both cases but again that is just personal opinion. Other than that I also agree not having functional programming.

Also I had one question, how resources supposed to be handled, let's say a database connection or simply a file descriptor. If the developer forget to close it explicitally how is it handled ?

Sorry I was unclear in fact I was mentioning Java case implements/extends. Just wanted to have opinions about semantics. I like having just one keyword for both cases but again that is just personal opinion. Other than that I also agree not having functional programming. Also I had one question, how resources supposed to be handled, let's say a database connection or simply a file descriptor. If the developer forget to close it explicitally how is it handled ?

belliash commented

2018-07-19 10:49:44 +02:00

Author

Owner

That's ok, @devnexen. I personally like the way it's done in Java.

My doubts about P# are:

CLI parameters - actually specification says that $argc and $argv[] are used. I am thinking if we should change that to one argument - string[]. Do we need $argc, when we can do sizeof on string[] argument?
entry point - In C# we can specify the entry point to the compiler. I believe we don't want to do that in P#. I think we would like to simply execute the script. Should it be hard-coded to constructor in class Main?

That's ok, @devnexen. I personally like the way it's done in Java. My doubts about P# are: * CLI parameters - actually specification says that $argc and $argv[] are used. I am thinking if we should change that to one argument - string[]. Do we need $argc, when we can do sizeof on string[] argument? * entry point - In C# we can specify the entry point to the compiler. I believe we don't want to do that in P#. I think we would like to simply execute the script. Should it be hard-coded to constructor in class Main?

belliash commented

2018-07-19 13:21:12 +02:00

Author

Owner

In the meantime, I have prepared a patch to PH7 which removes the need to embed the code into tags. Patch is attached to this comment.

In the meantime, I have prepared a patch to PH7 which removes the need to embed the code into <?php and ?> tags. Patch is attached to this comment.

strip_php_tag.patch

0 B

Ghost commented

2018-07-19 13:43:17 +02:00

The choice here is do you want to make it more flexible, or do you want to force all of your users into one "funnel".

ASP.Net also has <% %>, which behaves incredibly similar to PHP. Note that ASP.Net actually compiles the pure C# into a dll.

But don't forget that you don't have to copy any language. In fact, neither C++, Java, or C# are natively interpreted. They actually have a compile step that can use up any number of resources. P# doesn't have that liberty.

The choice here is do you want to make it more flexible, or do you want to force all of your users into one "funnel". ASP.Net also has `<% %>`, which behaves incredibly similar to PHP. Note that ASP.Net actually compiles the pure C# into a dll. But don't forget that you don't have to copy any language. In fact, neither C++, Java, or C# are natively interpreted. They actually have a compile step that can use up any number of resources. P# doesn't have that liberty.

devnexen commented

2018-07-19 13:57:54 +02:00

Member

@belliash about the arguments we do not have necessarily to follow the limitations of C, I would be ok to drop argc. Main or main or whatever as unique point is fine, I barely see a case we would need a custom entry point, at least at first glance.

belliash commented

2018-07-19 14:04:26 +02:00

Author

Owner

@MDTech-us-MAN, this is a code render block which has limited functionality and unlike ASP, in .NET it is invalid to declare a function or subroutine within this block. I think in P# it can be omitted. But I wonder what others think about it?

Ghost commented

2018-07-19 15:23:45 +02:00

Even something limited like that can be incredibly helpful.

likoski commented

2018-07-20 20:01:39 +02:00

Owner

But helpful for what? For obeying patterns?
The render block is useless even in C# at least since .NET 4.0, that introduced MVC3 along with Razor.

But helpful for what? For obeying patterns? The render block is useless even in C# at least since .NET 4.0, that introduced MVC3 along with Razor.

likoski commented

2018-07-20 20:07:35 +02:00

Owner

Seriously, at this moment, we should focus on modern programming (oop). If we finally manage to release first version of the language and we realize that this feature is missing, we can decide to bring it with next version.