SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    SitePoint Member
    Join Date
    Nov 2011
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    SMPL web programming language (based/built on PHP!)

    Hi, everybody.

    I'm going to talk in this thread, my first one here, about the web programming language which I designed, SMPL.
    But before I start, I would like to say that I really didn't know where to post this thread, I decided to post it in this forum as it was the closest one to the topic for me, as the language is it self written in PHP and based on it.
    --------------

    SMPL is a light, free, open source programming language, designed to add a mixture of simplicity, organization and flexibility to the task of programming for the web.

    SMPL is simple, easy and flexible! It is strong and dynamic typed, high organized and is characterized by high clarity, fixed naming patterns, easy debugging and supporting unicode from the core.

    SMPL, from the inside, is based on PHP. So it can work correctly on any web server that has PHP 5 installed, without reinventing the wheel, allowing anybody to install it as easy as installing any other application built using PHP, it's even easer, it needs no configuration (of DBs as an example).
    --------------


    SMPL Code Example:
    Code:
    <?smpl>
    
    show "Hello World! " * 3
    show "<br />"
    
    my_array= [1, 2, 3] + [4, 5, 6] // Like writing [1, 2, 3, 4, 5, 6]!
    
    show my_array * ' ' // Joining the elements of the array (the only implicit type casting in the language happens here, as it has no harms)!
    
    <!smpl?>
    Result (as it is viewed in a browser):
    Code:
    Hello World! Hello World! Hello World!
    1 2 3 4 5 6
    --------------


    PHP is a very useful, popular and widespread programming language.
    But:
    1. It is really has an inconsistent naming patterns (Like differences between these strings functions: 1- trim(), explode(). 2- strlen(), strpos(). 3- str_replace(), str_repeat(), 4- wordwrap().).
    2. Inconsistent parameters (Ex. Haystack first or Needle).
    3. Very strange function names (as in strnatcasecmp(), vfprintf(), strstr()).
    4. Wrong function names (as in addslashes() which addes back slashes and not slashes)!
    5. In function names: sometimes verb first and sometimes nouns first!
    6. It has no unicode support from the core (just some messy Multi-Byte functions which isn't enabled by default).
    7. Its typing if weaker a lot more than the acceptable. I wanted a more organized language, weak-typing is sometimes just trying to guess the programmer's intention!! Also the implicit casting in comparison looks very very random.
    8. I wanted a simpler, simpler not just easier, language which removes any additional non-needed parts.
    9. I wanted an easier and more powerful debugging methods.
    10. Many functions for nearly the same purpose: sort(), asort(), arsort(), ksort(), krsort(), natcasesort(), natsort(), rsort(), uasort(), usort(), uksort(), array_multisort(), array_shuffle() all of these are for arrays sorting! In SMPL you only need to use array_sort() with a parameter to choose the way you want.
    11. Some new concepts for databases in ArraysDB the database management system of SMPL. Which is powerful as the traditional SQL DBMS but it is not relational and uses functions instead of writing SQL (yes, also no injection of course), and treats the whole DB as an organized array, that is saved in a single small file!
    12. Also allowing any PHP programmer to edit the language, add extensions and make a lot of things with its core and functions!
    13. Other than all of that I wanted a lot of new features to the language it self, from the syntactic sugar to functions. For example you can see the allowing of adding, subtracting, multiplying, and even dividing non-numeric values. Summing two arrays merges them, subtracting them gives you their difference, dividing a string by another splits the first string into an array...

    --------------


    SMPL is a preprocessor, just like PHP. The whole process of browsing a web page written in SMPL can be summarized in:

    1. The web server receives the request from the browser, then passes the requested file to a file called smpl_translator.php.
    2. The file smpl_translator.php, after checking that the file can be reached by users, reads its contents then by transforms it into tokens, checks the correctness of the code, then generates the equivalent PHP code, the executes the code by eval(). Note: The generated code is cached and the cache is removed each 24 hours.
    3. PHP gets the code and processes it to its Byte-Code which is get executed by Zend Engine to get the result, which is returned to the browser.



    SMPL functions are PHP functions, and its variables are PHP variables also, but all of them have certain prefixes when they are written in PHP, but they don't have these prefixes when used in SMPL.

    SMPL is not the only language that uses a translator from it self to another high level language, Dart from Google, CoffeeScript, Pascal and Eiffel all uses "transcompilers" or translators.
    --------------


    SMPL's site wasn't originally in English, but in the last days I translated the main parts of the web site to English. Most of the site is translated (not really a lot) except the manual, only the downloading & Installation chapter is translated until now! I will try to translate more and more and write more soon.

    You can visit SMPL English Site or Download SMPL.


    I'm waiting for you responses, suggestions and comments about SMPL and its web site.

    Thanks.

  2. #2
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Interesting project, PHP has a legacy of very inconsistent naming and we all have to deal with it. However, PHP has very strong user base and very good support and it would be a very difficult task for any new language to achieve even a fraction of that. Even if you make a language that is somewhat better it is of no use if there are no existing libraries you can use and hardly anyone to ask for help. But a language needs to start somehow so good luck!

    Besides, my opinion is that if you want to make a better language that is based on PHP your efforts should focus on improving what needs to be improved and not trying to change something for the sake of change - for example, you use show instead of echo or print. Why? echo and print are used in many programming languages and to me coming up with some non-standard name makes no sense. It looks like the syntax is designed to be short - but this can backfire by being too mysterious or misleading - you use * as a substitute for str_repeat. * is a commonly accepted standard for multiplication in most languages and personally, I'd prefer to see str_repeat, which makes it obvious what is going on (escpecially to a novice user but not only). And I would prefer to see join(array) instead of a cryptic *. Your syntax requires anyone to look up the documentation to be able to understand what * means here. The array literals are nice but otherwise I believe the syntax should be somehow familiar to those who know other languages and not trying to invent new and completely foreign constructs. Clarity sometimes is more important than compactness.

    As to strong vs weak typing - I don't know, both have supporters and opponents and I believe both styles can be efficient.

    As for me, such a language would have to have some really compelling advantages in order for me to switch to it. For now, the excellent support, availability of libraries, frameworks, IDE's, etc. is much more important than inconsistent function naming and parameters. I'm also curious what others think.

  3. #3
    SitePoint Member
    Join Date
    Nov 2011
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi.
    Thank you for your reply.

    I know how is PHP popular and how is its user base and its community, but I'm sure that when PHP started Perl (PHP was first written in Perl) and C (then PHP was re-written in C) had a larger user base and C is still better in this point. Note that I know that the difference between C and PHP is larger than the difference between PHP and SMPL, that we can't even compare..

    But that doesn't prevent me from creating SMPL, as C and Perl didn't prevent the creation of PHP.

    Using 'show' is that for it is really related more to the web, these small things are important, it doesn't give an echo nor it prints in a printer! The multiply operator ('*') can be used in multiplying numbers, repeating strings, repeating arrays (merging it into it self by a number of times), and even joining an array. All of these uses (or maybe most of them?) exist in more than a language, for example Ruby and Python. It is not something new, it is just powerful.. No one would use a language without reading its basics!

    The arrays syntax is the same in Ruby and Python also, and in PHP the developers were discussing adding that way for PHP, they may added it in PHP 5.4!

    The problem isn't really the weak-typing, but the strange weak-typing of PHP..

    Anyway SMPL is still in the Alpha version 0.3, it could be now private but I preferred to publish it early. I'll try to develop the language more, develop an IDE (or a simple web-based editor), add libraries (the most easy thing) and complete the documentation soon.

    Thank you.

  4. #4
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Okay, so it looks like you are more creating a completely different language, not a language that is a PHP dialect. Personally, I don't find anything wrong with PHP syntax, operators, control structures, etc., but it can be a question of personal preference.

    One question though, how about performance? You said the translator uses eval on the generated php code - if that's the case then using smpl will have a huge performance penalty. If the php code is cached then I think it should be executed directly by php, then there will be no overhead. Or maybe I misunderstood something?

    Another question - if smpl is going to be run through php, will it be possible to mix smpl and php? Maybe not in one file, but will it be possible to write an smpl application that uses a php external library (like PHP Mailer)? If not, are you planning to make a tool that will translate a php library to smpl so that it can be used? I think these would be useful features.

    As to IDE's - maybe it would be better (and easier) to write plugins for existing IDE's like Netbeans, Eclipse? Writing a new one from scratch is a hell lot of work!

  5. #5
    SitePoint Member
    Join Date
    Nov 2011
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi.
    Thank you again for you reply and very good notes. Your notes are on the correct ideas and you are always right.

    First, I want to say that SMPL is still in the Alpha stage, so the language may be still weak or something, this is just trying to get ideas.

    PHP is alright. Being different that PHP is not meaning PHP is bad, nor it means it is good. The syntaxes of most languages are nearly the same, same thing for statements (What you named 'control structures', maybe my naming give a hint of another thing.), SMPL has 'if', 'elseif', 'else', 'while', 'for', 'function'. PHP and SMPL have 'break', 'true', 'false' and 'null'.. They both use curly braces.

    So for giving more power and features to SMPL, I'm working on way to write HTML without escaping from SMPL, do you know HAML? I don't know a lot about it, but this new feature to SMPL will allow you to 'safely' to mix HTML and the server-side code, without making it ugly or for 'read-only'! And that may make me remove the open and close tags completely.

    For the performance, it's bad in relatation to PHP, as expected! The most time of running the script (without PHP's SafeMode) is taken in processing the language files it self! Even with caching that only affects the translation process, but not calling all that needed files and libraries, If I could disable most of PHP's libraries maybe a big difference will appear.
    Anyway, depending on PHP can be temporary. A language is itself, build on Machine Language or PHP or even on paper (I mean standards with no official implementation).

    Mixing PHP and SMPL is currently not prevented, but it is very easy to prevent it (if that was better). Anyway mixing them is very discouraged, if someone wanted to add something to the language edit the core files (an extension for example), that's easy just a normal PHP function that starts with 'smpl_' and makes a certain type of checking on passed parameters values types, the left is a normal PHP code. And that's a big feature! So SMPL can easily do anything that PHP can do, except for the performance - until now!

    Maybe a simple editor is better? I myself use Notepad++ from a long time and can't really leave it to any other editor/IDE easily. Writing plugins/add-ons for Notepad++ is very very easy, most of the features can be added through a very simple GUI window, then the file can be exported then imported on users' computers..


    Thank you.

  6. #6
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sitesmaker View Post
    So for giving more power and features to SMPL, I'm working on way to write HTML without escaping from SMPL, do you know HAML? I don't know a lot about it, but this new feature to SMPL will allow you to 'safely' to mix HTML and the server-side code, without making it ugly or for 'read-only'! And that may make me remove the open and close tags completely.
    I know the basic concept of HAML but haven't used it. Definitely, I think PHP could be improved for template usage. PHP is a template language, if necessary, but its syntax is very ugly. That's why I sometimes still prefer Smarty's short {$var} syntax despite other disadvantages. If you can make smpl to be a clear and comfortable tool as a template language then that's something useful. I don't know if HAML will serve that purpose well but who knows?

    For the performance, it's bad in relatation to PHP, as expected! The most time of running the script (without PHP's SafeMode) is taken in processing the language files it self! Even with caching that only affects the translation process, but not calling all that needed files and libraries, If I could disable most of PHP's libraries maybe a big difference will appear.
    Anyway, depending on PHP can be temporary. A language is itself, build on Machine Language or PHP or even on paper (I mean standards with no official implementation).
    But do you have to use eval? If you manage to cache the translated PHP files and simply require or include them then you end up with only minimal overhead of checking if the source smpl file has changed. And this method will benefit from any opcode cache that can be available on the server.

    Mixing PHP and SMPL is currently not prevented, but it is very easy to prevent it (if that was better).
    What I meant was not preventing but allowing. If I find a PHP library I'd like to use it would be great if I could include it and call it from within an smpl application. For example, by using a construct like require_php.

    Maybe a simple editor is better? I myself use Notepad++ from a long time and can't really leave it to any other editor/IDE easily. Writing plugins/add-ons for Notepad++ is very very easy, most of the features can be added through a very simple GUI window, then the file can be exported then imported on users' computers...
    Notepad++ is a very nice editor but it's not an IDE. Many people will miss more advanced features that an IDE can provide. Maybe if smpl was more similar to PHP then it would be easy to take the source code of existing IDE PHP plugins and convert them to support SMPL. But if you are planning to have so much different syntax then this might not be that easy.

  7. #7
    SitePoint Member
    Join Date
    Nov 2011
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    It's not so much like HAML, after I've looked again at HAML it is a language, that replaces HTML and allows Ruby code to be inserted in. The new feature in SMPL is to make both SMPL and HTML a single language, or in another way to put HTML in SMPL and not to put SMPL in HTML!

    I started yesterday and I've got this syntax for a normal page in SMPL:

    Code:
    :'html', ['dir' => 'ltr', 'style' => ['font-weight' => 'bold']]
    {
    	:'body'
    	{
    		show '...'
    	}
    }

    SMPL, with the '<?smpl>' and '<!smpl?>' (open and close tags) where a template language, just like PHP. But if this new feature was added, the tags will be removed and I think it will not be a template language any more. I even think of adding an extension called '.smcss' for writing SMPL code that outputs css. Same thing may happen for JS. Maybe a single language for everything on the web! Anyway, all of these are still some ideas, not more.
    --------

    About 'eval', as much as I know it is faster than include/require. Include is an eval('?>' . file_get_contents($file)), which is slower that it reads the file, which also happens when caching, so there's no big difference! The only difference may exist if the server used an byte-code cache for PHP, so include will be a lot faster, as you said.

    But the performance will not differ a lot, SMPL still have to read all the libraries and files of the core! If the difference will be great, I may include the libraries dynamically only when used! The problem here is that SMPL functions are dependable on each other, but this can be solved. Maybe the non-development version of the language, will contain everything with no whitespace, no comments in a single file, that will raise the performance also.


    For the IDE plugin, I will try to do my best.


    Thanks.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •