Hi, I'm the author of Slash. I wasn't expecting Slash to show up here so soon - the website's pretty out of date and the language itself still needs a bit more polish before it's ready for use.
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.
Awesome job. I'm impressed how many interesting and complex open source projects you created / contributed to. And you are only 19! What age did you start coding? And how did you learn? By yourself? Early CS degree? I'm a bit envy.
Github hired you for a good reason probably.
Slash looks really interesting, will keep a watch on it. I have some constructive remarks but it was all said already in other comments. Are you using it somewhere in production? What is the runtime? How is concurrency handled? Do you have performance benchmarks?
Great stuff overall. Keep it up.
I wish this was top. There's merit in creating a new language, even if it's just for learning. I'm not saying we shouldn't constructively criticize the language itself. I'm just glad the merit is recognized as well.
If deployment is the key issue, you don't necessarily need to change the language. What you need is glue code that hooks Ruby (or Python, or whatever) into the web server at the same level as PHP hooks in, the way the ancient mod_perl does for Perl. (Which is also probably a bit less implementation work than doing a whole new language --- and also gives users the benefit of a much larger set of libraries right off the bat.)
EDIT: as pointed out below, mod_python for Apache already goes pretty far in this direction.
> What you need is glue code that hooks Ruby (or Python, or whatever) into the web server at the same level as PHP hooks in, the way the ancient mod_perl does for Perl.
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.
>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.
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.
PHP only works like that because Apache's default process model is process-per-request. Anything event based requires moving PHP in to multiple fcgi worker processes, and then you get limited by that.
A fast, non-shared interpreter could work very well in a threaded server, or a threaded backend to an event-based server.
Just for the record there are a huge differences between how mod_perl and mod_php work. One of the main reasons that PHP got so popular in the first place was that mod_perl was really boring and complicated to work with because it was keeping all the scripts and modules and globals loaded and shared between requests.
I second this. The language appears to be a Ruby with a slightly modified syntax, and most programmers won't be excited about keeping track of the differences. Use Ruby for this and everyone will benefit.
If you did a python/ruby/node-javascript that would capture the best features of PHP, instead of inventing a whole new language, I'd actually be tempted to use it.
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.
There is a lot more wrong with PHP than these (anti-)features.
It's loose comparisons for instance, with gems like 0 == "php" returning true, but 0 == "1" returning false [1] [4]
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".
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.
...yes, but these are also the features that led people to use and keep on using PHP. one man's poison is another's drug of choice ;)
(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 want the same language in my controllers, in my db code AND in my templates"
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 :)
Their complaint is valid imho. They can use PHP to learn the basics of programming, and after this, as the next logical step, learn to structure their code. PHP is a bad language to get started with to learn programming for a number of different reasons (much worse than Python or Javascript), and this is why it would be cool to have the "PHP way" but based on a different language.
...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?!" :)
He didn't say implementing those functions in the same code, but using the "same language". To me, PHP's use in templates is pretty much its core idea. I think it's a good idea, and basically defines what a ruby/python version would be like.
Unfortunately it also makes possible the abuse you note - hopefully there's better solutions than requiring a different language in those 3 places.
What is the actual benefit of slash, compared to python or ruby with a templating engine? Something like http://slim-lang.com/ which is ruby templateing for example.
The PHP approach seems kind of messy in jumbling together (1) a programming language and (2) plain HTML notation
I am PHP developer, but that first "Overview" example looks all sorts of wrong to me.
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:
No, not necessarily. What is a "C-style" language, anyway? Most imperative languages today are descendants from the ALGOL syntax, it's just that C modified some of the more inelegant aspects and made them more terse. Whereas Pascal stuck directly with ALGOL operators and blocks.
View/controller separation, view models and query abstraction are framework-level features. The author of this language is seeking to take the qualities of PHP that make it a 'hypertext preprocessor' and mixing in the no-frills syntax and vocabulary of ruby or python.
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?
I am a big supporter of building applications in consistent way, and the big part of that is being able to code components which do not know anything about the presentation layer. Building these components on hypertext preprocessor is exactly the thing I would not want and would avoid at all costs. We already have it with PHP, and we have learned to follow some practices to live with it.
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.
gets illegible and confusing very fast, even from 20 lines of HTML in between. And that isn't even that much. endif, endfor, endforeach etc. are much more noticeable, plus every editor/IDE worth their salt will highlight it properly.
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.
You can slap a script on a server and have it run because of PHP's ubiquity. This language has none of that.
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.
There are many cheap shared hosts that allow you a server to slap PHP scripts on without giving shell access. That is why PHP is popular. And setting up a secure shared environment is more work for the hosts than apt-get install php5.
I wish statically-typed multi-tier/stratified languages for the web like Opa (http://opalang.org/) and Ur/Web (http://www.impredicative.com/ur/) got more attention; they actually bring something new to the table.
'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'.
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...).
I'm glad it's so obvious to you. Here is a quick test:
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?"
TL;DR -- I generally fall in the category of counting graphemes, as per the second FAQ you linked -- when talking about user-facing text processing. I'm don't think it makes sense to try and have one api that tries to both appease (low level) programmers and end-users.
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).
The logic would be that the full sentence is treated as a sequence of words that's treated as a sequence of graphemes that are treated as a sequence of codepoints that's treated as a stream of bits...
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.
One valid point the intro makes is that PHP's "slap a script on a server and have it run" has made it the go-to web scripting language for a lot of folks whose goal is to just get something small, maybe a single page, up and running quickly. For larger projects, you will likely be better served by other languages, but I still find myself going back to PHP when I need to do something small, quick, and without much regard for performance or elegance.
In todays development world i dont see any reason why to use python/ruby instead of php (which was different when Rails came out), even for large projects. The frameworks are very mature and the community is huge.
I see a point in using JS on the server instead of PHP though, still the frameworks have some catching up todo.
Install python, mod_wsgi, and add two lines in the apache config.
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'm not a pythonista but would question your recommendation of mod_python - the (current) top post at https://news.ycombinator.com/item?id=6616550 (also on the front page right now) states that "mod_python has been dead for so long now that its death has gone from a liability to a potential asset".
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.
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
1. PHP's configuration isn't simpler in any way, it's just that the insecure method is already configured by default, so you don't have to set it up. Python doesn't have such an insecure method, so the (trivially easy) configuration is app-specific. And that's a good thing.
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>
I don't think that mixing view and model code in an example is a good idea. The reason is that it encourages mixing different concepts / abstraction levels which will result in confusion and maintainability issues in the long run.
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.
If this project used Ruby, it would be an approachable tool for back-end web development neophytes to learn with before moving on to Sinatra and Rails.
Why should I switch from PHP, a mature and stable language with an enormous support base, many libraries and an obvious career path? I need a more compelling reason than "it fixes PHP's idiosyncracies", most of which I have come to understand.
In your case you shouldn't. :) PHP is string manipulation language, it's really hard to do anything else with it. (binary manipulation, network programs, binary streams, long running apps...)
That isn't true. PHP is a general purpose programming language. Binary manipulation is done about as often with PHP as it is with ruby. PHP has pack and unpack functions. Binary data can be stored in a PHP string with little overhead.
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.
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.
You cant rely on long running processes with PHP because of its error system. And PHP threads are a joke. PHP is definetly not a multipurpose language ,it's a string processor ,otherwise you would not have to begin your scripts with <?php
Ha. PHP is a binary manipulation language, it's a bit more difficult to do unicode with it. Network, binary streams, and even long running apps are doable.
What do you mean with 'come to understand'? You can use them or you understand why they are there? Because I wouldn't call the former understanding per se and if it is the latter i'm interested to hear about it. If it is something else than 'the developer of x(a,b) was someone else than who implemented y(b,a) and he was lazy or somewhat opinionated, but just not enough to fix the other functions as well' that is.
I could have said "come to live with" instead. It works, it let's me do my job. PHP provides me with a good living (I primarily build boring CRUD apps, also using Python and Ruby).
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.
I don't understand how you switch from “wow, guy wrote a language I can use in my projects” to “why should I switch from PHP, I need a more compelling reason” and stuff.
And yeah, PHP sucks. And your career path is something you should not think about at all.
Node.js seems to be becoming a PHP successor. In regards of easy web development. With JavaScript you can both write for the front-end and the back-end. One language to rule them all. Very appealing to newcomers who want to learn webdev.
I agree, the one issue i have with node.js is handling security. PHP has had many years to become exploited and matured because of that. node.js don't have broad adoption yet and thus haven't attracted the same amount of hackers.
We could hope Node becomes such a ubiquitous solution, but the love HN is no great predictor of the future. Often it seems if the early adopters of HN love something, it is doomed. It's got to grab the middle of the bell curve's attention and drag the tail of the HN crowd to it kicking and screaming.
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 .
Nice. I wish it well. Sadly, it has one feature I hate from PHP (the ability to interweave PHP and HTML, instead of using the HTML as a template or generating it in code) and lacks one feature I absolutely need, which is all the code I've already written in PHP and can require_once and reuse whenever I want to start a new project.
But I hate PHP, even though it's the main thing I use now. So I want this to succeed. Good luck!
Definitely - but then, McDonalds Big Macs are more popular than hamburgers with beetroot and pineapple on them, and my tastes are again at odds with the mainstream. I can't help it - I'm a geek hipster (and a burger snob).
Why having this if you have Ruby, Python or even Node.js... and why having PHP at all! all I can think of is dinosaurs and extinction. Move on guys, PHP was cool several years ago, and I enjoyed it a lot, but now it should be buried already and you're trying to create a zombie here.
Ignoring Node for a moment, Ruby and Python currently have a noticeably higher barrier to entry for the kind of personal home page that PHP was named for. <html-stuff><html-otherstuff> <?php $todays-date ?php> <making-up-the-syntax-as-I-go-because-Ive-forgotten-it-all>
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.
What are you talking about? This is the problem of why PHP is still being used, because developers think that Ruby or Python don't allow you to do several stuff you actually can... look at this example (ERB lets you run Ruby code the same way):
Plus you still need to run PHP over a server (Apache, Nginx, or what so ever), so I don't see so much difference with Rails, Django or Express, except that PHP is an old and stinky language.
Really, the only reason Python and Ruby have the same "noticeably higher" barrier to entry is because most cheap hosting services don't support Python and Ruby the same way they do PHP. Python and Ruby are just as easy, if not easier, for a beginner to get into outside of web dev.
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.
The first (or second, maybe) line made me cringe...a specific object for MySQL, rather than a database-agnostic SQL engine, a la old-school ASP or middle-school JDBC.
Perhaps better:
db = DatabaseConnection.new("MySQL", "localhost", "my-user", "s3cr3t");
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).
> 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.
ODBC and JDBC are both older than that, and still alive and well and popular today.
Another reason I cringed is the implicit creation of the db variable. This is just asking for beginners to bang their head against the table in frustration trying to work out why their variable alongvariablename is equal to 0, even though they just assigned it to alonggvariablename to 7.
"Oh, it was just an extra g, and I've been stuck for hours because of that? I hate computers!"
And it's the one thing I really dislike about Ruby. The problem with this is that the interpreter can't tell the difference between declaring a new variable, and misspelling the name of an existing one --- which means that there's a very common class of simple errors which it can't automatically check. Even Perl (with -w) gets this right, and it doesn't really make the language more verbose; declarations are preceded with a 'my ' which is useful punctuation. (Humans also find it useful to see when a new variable is being introduced.)
And you could come up with ways to preserve the distinction while making it even less obtrusive --- ':=' instead of '=' in a declaration, for example.
It's the same in Python, and it's mostly solved by external static code analysis tools. The trick here is the assumption that misspelled variable will be used only once in a file - exactly where it got misspelled - and tools like pylint or pyflakes warn about such names. If you're running these tools sufficiently often and have them integrated with your editor (my Emacs runs pyflakes once in 3 seconds, after enter is pressed and on save, whichever comes first) this kind of error is essentially eliminated.
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 don't think it is beginner-friendly, except maybe for the first two lines of code they ever write. By the time they get to the third line there is a good chance they've mistyped their variable name...
Seeing the "yada-yada" operator reminded me of a language I saw once that was designed to actually let you say the equivalant of "yada yada" or "and so on", and it would actually try to figure out what you meant. It wasn't quite a general "do what I mean" language, and was a research project in progress. Does anyone remember in more detail what I'm talking about? I can't figure out how to search for it.
One thing PHP has going for it is its ubiquity. Despite all its problems, its an accessible, server side scripting language. Slash looks really cool for small, easy projects that PHP would be good for. In fact it looks better. But, it doesn't have PHP's ubiquity. I think it'd probably have to be 10x better to overcome the ubiquity problems. Maybe it is. How easy is it to install? (sorry if that was covered somewhere on the site)?
I don't see how this "language" would make it a better language, there is frameworks in every type of language - a quick look at frameworks like Yii makes this look similar and more powerful even as an abstraction layer, to this language described.
Also, a new language would not be compatible with current PHP modules... I think this is just not thought through.
The power of PHP isn't really the language but the way it integrates with Apache web server. If web server integration doesn't exist for your language, or doesn't exist on the level that PHP has it, you can design cool languages but it won't replace PHP ever.
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.
I know. I understand. The reason for the success of PHP is that it runs on cheap shared hosting. If you want to replace PHP you need to fill that gap first, or, make it at least as "convenient" as PHP.
Ruby is more Object Oriented than PHP will ever be. You dont need interfaces or abstract classes in a dynamic language. Unless you want to feel "safe" as a developper.
So you don't know what design by contract is? At least other Ruby and Python devs recognize this lack of features and try to solve it instead of ignoring it or making up excuses:
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.
By safe he probably means "enterprisy." OOP is pretty much a joke when your realize every "pattern" ends up being the singleton with a dozen levels of inheritance by the time a web app development team gets through with it. Every other pattern will fail by the times the marketing and executives get hold of it. It should be called the Fox & Tramp bowl of Singleton pattern. But I digress as I step on the enterprisy toes of team developers.
In Ruby everything is an object with methods and attributes.
In PHP object orientation is an after thought and not a very good one, PHP is so broken it is a joke.
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.
Again, you don't understand design by contract. You just pass objects around and pray that they will work.
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.
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.