The Slash Programming Language
slash-lang.org
slash-lang.org
Slash is something I'm building out of personal need. I love Ruby, but there isn't much going on in the 'small web scripts' area. It's either frameworks like Rails or Sinatra that require app servers constantly running, or tools like Jekyll that can only do static websites. Slash is somewhere in between. It's not supposed to be a 'PHP successor' as much as it's supposed to be something that Python or Ruby fans can turn to when they just need to chuck a small script up on the web.
EDIT: as pointed out below, mod_python for Apache already goes pretty far in this direction.
The problem with this approach is that MRI Ruby has tonnes of global state, so unless you restart the interpreter for each request, you're going to end up with state leaking between requests.
Slash is designed so that many VMs can be quickly created in the same process without any shared global state. This way each request runs in its own isolated context and can't affect any other requests.
So what? That's how PHP works, and it's still pretty fast for most things. Would a mod_ruby be that much slower? Should still be faster than a CGI-style invocation.
A fast, non-shared interpreter could work very well in a threaded server, or a threaded backend to an event-based server.
The features (or what others would call anti-features, but one man's "bug" can be another's "features" so lets ignore the long talk) would simply be:
1. Ultra-Ease of deloyment - I want to be able to just:
- load a module for my webserver of choice (Apache, NGINX etc.)
- drop code in a folder via ftp and have it "just work"
- have a shared nothing app model with no long running processes, PHP style, because this way I can ignore 99% of security and performance problems, both as a provider of dirt-cheap shared hosting and as the developer of a web application that doesn't need to scale that much and isn't that much of a target for hackers either (so I can have the following mindset: "I don't need to care about scalability/performance or security, because by the time I'll need to care about these I'll be already making enough profit from it to be able to hire some very smart guys to rewrite everything from scratch the right way or I will have already sold the company and be enjoying my $ while others care about this")
2. Ultra-Eease of app/site setup:
- I want to just drop files in a folder and have it work, just like that, just like magic
3. "Don't make me think" style of development:
- I want the same language in my controllers, in my db code AND in my templates
- plus points if it's in the browser too
- have all the component I and other might need in "one pack", "batteries included" style
4. Almost non-existent learning curve:
- someone should be able to go from A - "poetry major with no knowledge of what computers are" to B - "expericenced full-stack developer" withouth feeling any learning curve: yeah, it will take time to get from A to B, the first 10% of the road should be made as easy as possible
...and to "kill" PHP you'd still need to add a killer extra feature. I can imagine something like an object persistence feature (Maglev/Gemstone style) baked into the language/library/framework that would allow you to simply persist objects without even thinking about a database (it could be implemented as a very smart ORM underneath, but it should be as opaque/black-boxed as possible and 99.99% of users shouldn't need to know how it works) - this imho would be the kind of thing really enjoyed by PHP developers.
Having a function like nl2br [2], which converts newlines to br tags. The only reason this function would be useful is when you want text to HTML. The problem is, this requires a lot more than just replacing newlines with br tags.
A function like intval [3], which according to the documentation when passed a string "will most likely return 0".
And just about anything on http://www.phpwtf.org/
My main point is, that PHP is not broken because of these features. PHP is broken because the language has been hacked together from the start and there is no way to guess what built in functions will do if you haven't looked up the full documentation for them first.
[1]: http://www.decontextualize.com/wp-content/uploads/2010/01/ph...
[2]: http://php.net/manual/en/function.nl2br.php
It's only popular because it's easy to setup shared apache+php hosts and deploy scripts via FTP on it.
(to be honest I'd love to see PHP dead and buried, but there's still no other tool that fills its niche, and I hope that when one such tool gets developed, it's actually based on a sane programming language - PHP as a language means nothing, it was just "something" that grew organically into a language to fill an empty niche, and the only other alternative for this niche back then would've been Perl).
I read that as "let me mix them together like a PHP spaghetti app". The original poster may not have meant that, but after 13 years of writing PHP, the common complaint I still hear from newbies is "but structuring my code/using a framework has such a steep learning curve!". I'd rather like separation of concern enforced at the language level :)
And no, I don't have a clue how that'd work ;)
...now, I first learned coding by solving algorithmic math problems in C, but if someone would've tried to make me learn C++ or Java and OOP at that point I would've had the same complaint your newbies are having about "why learn so much just to 'structure' my code?!" :)
Unfortunately it also makes possible the abuse you note - hopefully there's better solutions than requiring a different language in those 3 places.
This is essentially what Zed Shaw was working on for Python:
https://github.com/zedshaw/fuqit (https://news.ycombinator.com/item?id=6039146) and here's another for Node https://github.com/ricardobeat/fuqit
I'd love something like this fully fleshed out for Ruby. Some things PHP did "get right" like how it "just works."
See http://search.cpan.org/~jesse/perl-5.12.0/pod/perlop.pod#Yad...
And search for "yada" in the following links:
The PHP approach seems kind of messy in jumbling together (1) a programming language and (2) plain HTML notation
Also:
Are you just feeding through the HTML parts or are they parsed/validated/inspectable? Can one work with DOM nodes? (This is what I like about https://github.com/weavejester/hiccup/wiki/Syntax )
I know this is just an example, but programming without view/controller separation, view models, writing queries inside views, mixing business logic in views? No no no I saw so much horrbible stuff like this I can't unsee aaaah God help me...
:D
Ok, on serious note: I think this language looks interesting. But I do not like built-in templating, for various reasons. The fact that you have implicit "out" channel for printing stuff means clunky ways to control it, like "ob_start" and friends. In my humble opinion, templating should be turned on only explicitly. Then you could use the same language for views (excelent!), without a risk of outputing strings where you shouldn't.
Also "{" and "}" in templates are not very elegant. I know us programmers got used to them, but a designer would be much better with simple statements like "if", "else", "endif", like Twig templates do, or even like we used to do in php:
<?php if (x): ?>
<?php else: ?>
<?php endif; ?>
Just look at environments like Delphi and VB.
JavaScript uses curly braces. Any designer who knows anything about coding is going to have to learn JavaScript. How about one syntax?
<?php if($condition){ ?>
<?php } ?>
I don't understand why you wouldn't just use a framework like Sinatra. It's simple in every way that qualifies it to contend with a 'hypertext preprocessor'. Add it to your gem file, bundle, git commit, push to heroku, deployed! It even has inline templates[1].
You could argue it has a learning curve, but is resistance to learning a good argument against a solid & simple, versatile framework?
Well, you may say, this is just for small stuff to run some scripts easily. Well, the reason behind the PHP was the same. And look what it has become :)
Please don't assume I will not use Sinatra just to plug Sinatra here :). I might.
PHP is a great tool that is virtually unmatched in its domain - ie. ‘slap a script on a server and have it run’.
The problem is that PHP’s idiosyncrasies make it awkward and sometimes even painful to program in.
... [Slash] is a language that lets you achieve results quickly while being a joy to use.
It seems like a non sequitur to say "PHP is really easy to get started with ... but my language is cleaner!"
It could be said that PHP's biggest feature is its install base. Nothing is going to "succeed" it until it gets past that.
> sudo apt-get install php5
> *slap script on server*
> ???
> profitNO NO NO NO.
'length' is ... not right, and I don't want to know why it returns 4 for the above, because that's not right. If you want to provide a 'length' function for a Unicode string, you need to know what you are measuring: graphemes, codepoints, bytes? Whichever you decide to use, is inappropriate for 'length'.
As the correct answer is "that depends", neither answer gets to qualify as "length", especially given that traditionally, a string is a sequence of bytes, which gives a third thing that 'length' could mean.
To me it is rather obvious that a text-oriented language would treat any "string" as a) an atomic string and b) a sequence of the "next-lower" logical unit. I do just now realize that "An English sentence.".length could by this reasoning return 3 or 4 (3 words, one punctuation mark...).
What is "ö".length?
It's one grapheme, an o with a diaeresis. It's two codepoints, an o (0x006F) with a combining diaeresis (0x0308). It's several bytes, depending on encoding.
How about if you reverse it first, so that the diaeresis doesn't have anything to combine with, and you have a bare letter 'o'? What's the length now? If you answered _one_ to the above, you've got a string whose length doubles when you reverse it. Is that what you want?
Too easy for you?
Let's take the Thai consonant "ก", which is a sort of a g, sort of k sound. One grapheme, one codepoint. Sorted. We'll add a vowel to it: "กอ". Two codepoints, but how many graphemes? One or two? Let's say two, but then let's point out that there is no logical difference there between that and a different vowel: "กี". This is a little more complicated? What's the length now? Is that one or two graphemes? It's clear as day that that's a single consonant + a single vowel, but how long is the string? How about: "เกียะ"? That's still a single consonant + a combining single vowel, only this time it's a compound vowel. One consonant, one vowel, how many graphemes? Are you using vertical slicing to determine what is and isn't a grapheme? Is that right?
To see this taken to its logical end by The Masters of Unicode: http://www.unicode.org/faq/char_combmark.html - "How are characters counted when measuring the length or position of a character in a string?"
Perhaps I wasn't entirely clear - I certainly see that there are complications. I think you're overcomplicating your examples within the domain of text - I'd say composed characters counts as one, and reversing a string with a composed character, shouldn't reverse/destroy the compositon. The reverse of "õ" isn't "o~", but simply "õ" -- and the length of "o" and "õ" should both be one -- even if they aren't coded similarly.
Now, this won't work for lower level work on "computer language" strings -- so for your unicode-library or whatever you'd have to count differently. Obviously you have to do some magic when converting a multicode-encoded string from big-endian to little-endian and vice-versa -- but that's hardly the same operation as reversing a string.
I'm not familiar with thai, but to me it looks like your "กอ" and "กี" is equivalent to the Norwegian vowel "æ" which used to be written/typset as "ae" (and can still be considered a composition in some input locals). So the length of "ae" is 2, the length of "æ" is 1 as is the length of "a". That would mess up "ae" if reversed -- but I would consider that a "special/archaic" use-case. I'm not sure if that would be similar in Thai -- I don't know for example, if typewriters and computers have been wildly used for comparable time in Norway and Thailand (I'm guessing Thailand have a few thousand more years of printing/literacy).
As mentioned in my comment above, I also find it interesting that if we're taking length to mean "number of things in a sequence", the length of a sentence would be the number of words, the length of a word would be the number of graphemes and the length of a grapheme might either be the number of bit/bytes, or there might be a level in-between of composites.
So we might have:
"This is an example.".length => 4 (or 5 or 8 depending
on how we define spaces and punctuation)
"This".length => 4
"T".length => 1 byte,7 or 8 bits, or maybe even 2 in a
prefix-based encoding (capital-transform t).
I see a point in using JS on the server instead of PHP though, still the frameworks have some catching up todo.
Please tell me the deployment steps for a single-file python script.
With PHP, it's "install php mod_php, place files in directory" .
With Python it is... what?
The last step is just removed in PHP because of the "place files in directory" model, which is fundamentally broken and used by default. Application code shouldn't be in a place where the entire world can read it if for some reason your httpd doesn't parse it.
I totally agree that application code shouldn't be in a web-accessible directory - but that's a hosting/configuration problem, not a PHP (or even mod_php) problem. It's trivial to set up an index.php which bootstraps an application stored elsewhere on the server.
With regard to code location, I mentioned that because of Spidler's question.
1. WSGI configuration is more complicated than you make it sound
2. In your script you have to create a WSGI compliant app. Unlike PHP's quick and dirty method of spitting stdout on the webpage which is useful in making quick and dirty single file scripts
2. Yes, if quick and dirty is all you want, just use PHP, there's nothing wrong with using the right tool for the job. Personally I prefer quick and clean though, that's why I try to avoid PHP.
> In todays development world i dont see any reason why to use python/ruby instead of php
... would probably just be that for anyone with a taste of Python and Ruby, PHP the language and dev-environment is a bitter pill to swallow, no matter how good the frameworks are now. Laravel looks pretty ace to me if I must do PHP, but I'd much rather use Python or Ruby.
<ul>
<% for person in db.query("SELECT * FROM people") { %>
<li><%= person["name"] %></li>
<% } else { %>
<li><em>No people found!</em></li>
<% } %>
</ul>
For example if you happen to change the table name from people to humans you will have to change all code which uses people. It is not probable but it might happen.
If your language is not intended to be used for more than a few lines scripts then just ignore my comment.
No where is he writing "Okay, let's start with an example on how you should be coding."
HTML escaping by default
I think part of PHP's popularity is that it offers a good balance throughout a product lifecycle - prototyping (because of the number of libraries), production (because it runs on anything), maintenance (because it's stable and easy to hire for).
The best analogy I can give is like someone selling me a car. Right now, I'm driving a 20 year old Ford because I'm more interested in saving money than going quickly. If somebody wants me to get a new car, they need to show how I'm going to save money, not just how quick the other car is.
I guess 'Slash' could do that, but right now the copy is not focusing on the difficulties I have with PHP.
And yeah, PHP sucks. And your career path is something you should not think about at all.
Also in practice PHP has been weak at certain types of string manipulation, because the template language doesn't lend itself to capturing the output in order to filter it. Intermediate PHP developers know how to save buffered data, but it isn't as straightforward as manipulating output data with rack or wsgi middleware.
No no no no no no no. Nonono. No.
It's a web framework and template language built around a handful of C wrappers and awkward database interactions. It can't even represent unsigned 64 bit integers. Any complex math requires you to convert the numbers into strings.
PHP is an advanced template language for HTML.
PHP is a template language for HTML that's prone to CSRF.
And then watch it grow over the years into unmaintainable mess :)
1. For the love of god, don't allow a Nil value! Pattern matching is so much better (Maybe/Option type) 2. I didn't see anything about the runtime, but if you can optionally compile to something ubiquitous like php initially it will ease adoption. 3. even though you target small scale, so did javascript. I'd throw in some rudimentary namespace/package/module/version/dependency things .
But I hate PHP, even though it's the main thing I use now. So I want this to succeed. Good luck!
Which is arguably the one reason for PHP's popularity.
AFIAK, in either Ruby or Python the equivalent of that would be far harder. You'd need a program made of several separate files, have to grab Rails from somewhere, have some concept of responding to requests somewhere and a bunch of stuff other than the one time stamp above. Though I suppose you could use client-side JS here too.
$ cat test.erb
Hello there! Today = <%=Time.now%>
$ erb test.erb
Hello there! Today = Sat Oct 26 16:42:36 +0200 2013
There is your HTTP Server.
What a little more dynamic? Sure. Download Bottle. A single file! Then write something in a separate Python module and you can write raw html too in the bottle response. No jinja is needed.
Piece of cake. Lighter than what PHP would require you to setup.
Perhaps better:
db = DatabaseConnection.new("MySQL", "localhost", "my-user", "s3cr3t");"Oh, it was just an extra g, and I've been stuck for hours because of that? I hate computers!"
And you could come up with ways to preserve the distinction while making it even less obtrusive --- ':=' instead of '=' in a declaration, for example.
OTOH, having a language which doesn't need external tooling to eliminate such errors is an obvious win. Smalltalk, with it's code browsers, refactoring tools and similar does this really well, for example - if you use a new name inside a method definition you are asked if you want to declare new instance or block variable, or turn it into selector, or if you want to rename it (and then it gets renamed throughout the method) and so on. And that's at compile time!
I think pretending that there aren't massive and very specific differences between SQL implementations is pointless. I would far prefer a tight, concise DB specific object than an over-verbose generic one.
So in reality, what does it gain you?
I haven't heard anyone talking about DB agnosticism in web dev for years, it was an odd idea that popped up in the mid-2000s and died the pointless death it deserved. Not only that, you should invariably wrap any such driver in another object to cut the verbosity down, so what was the point? There are specific types of code base that need to be DB agnostic, and web apps is definitely not one of them.
I've migrated a non-trivial app (10,000-100,000 LOC) from MySQL to SQL Server in C#, the only SQL queries I didn't have to change were the basic SELECT statements. Took me about a week and it was actually super useful having DB specific objects as when I finally ripped out the MySQL library reference, I could be confident that I had migrated every path (although that obviously only worked because it was a statically typed language).
ODBC and JDBC are both older than that, and still alive and well and popular today.
<table>
$for i in range(10):
<tr>
for j in range(10):
<td>$(i*j + 1)</td>
</tr>
</table>
More information here: http://webpy.org/docs/0.3/templetor
I would also imagine it being a pleasure to represent html as Lisp lists.
Also, a new language would not be compatible with current PHP modules... I think this is just not thought through.
With tools such as Node.JS (or Python Bottle, Haskell Yesod, etc) you simply pull your code from git, run it, and it has its own webserver included that handles routing w/o looking at a filesystem and direct execution of code instead of passing a file; which all is nice for performance.
http://metabates.com/2011/02/07/building-interfaces-and-abst...
http://docs.python.org/2/library/abc.html
Learn some OOP and design patterns before filling your mouth talking about PHP.
Also, Clojure is a dynamic language too and yet it craves for explicit types:
http://www.indiegogo.com/projects/typed-clojure
But this is only for noobs who "want to feel safe", according to you. What a joke. You probably can't even get past an introductory tutorial of this subject.
There is a reason why modern web development was invented with ruby and why all modern web frameworks try to copy rails or sinatra. Because Ruby was designed the right way.
One doesnt need interfaces and abstract classes if one uses duck typing and message passing the right way.
If you stayed a bit up to date, you would realize that Rails is pretty dated already. For instance, take a look at Symfony2. It easily beats Rails in every aspect possible. You probably won't be able to appreciate it though, since you don't know the first thing about design patterns. You just use whatever you thought was "cool", easy, and you stayed for the syntactic sugar, which you confuse with being well designed.