However I'd say he's directly responsible for the misery the most PHP development now is.
If he actually spent time reading about languages and designing his own, he would throw in function namespacing and function naming conventions and a good built-in abstraction for database access (with a strong bias against SQL injections and towards placeholders/variable binding from the day one), PHP would come out an okayish language and not an universal hate target.
There are some other blunders that he could just not make. And I'm not even dreaming about template system that makes sense now.
He didn't! Who the hell could do that if he wasn't going.
Maybe if people who spent time knowing a lot about good language design spent some time making their languages practical, we wouldn't be in this situation either;-)
I think Ruby and Python are reasonable examples of languages that make good compromises; they have some nice language features, but they are eminently usable for real world problems as well. Also, they are fairly approachable, even for people who are not CS majors.
Ramsus wanted to create a simple 'glue' language that was approachable and did the job done without any layers of abstraction that web framework like Zend and Symfony have. And he has stuck to his guns till today.
Therein lies one of my regrets: Tcl was out there and was already quite a nice 'simple glue language' that to this day remains more powerful and flexible than PHP in some ways. It's too bad the early Tcl/web systems were proprietary until too late:
I try hard not to say that somebody is 'wrong', believing that different opinions are important - but your ranting about PHP is ill-informed at best, and outright wrong at worst.
What Lerdorf developed was initially a collection of C macro's and functions to make repetitive tasks for web application development easier. If you were developing web applications at the time, which I can safely assume you were not, since your arguments are restrained to comparisons with dev platforms popularized in the past few years, you would realize why the initial popularity of PHP and how it was developed makes sense. It allowed a lot of developers (read: most) with a C background to easily churn out buzzy web applications.
The Zend engine, was not developed by Lerdorf. It was hackish, simple but extremely fast because of mod_php and a decent vm. Combine that with the C syntax and easy administration and you have the core reasons why PHP blew out to be a raging success. As much as one may or may not like something, you do have to recognize that most things become popular for very good reasons - and bitching about them usually means that you are either a) smarter than the collective intelligence of the rest of the world, or b) ignorant.
Now to your points, they are just wrong. PHP has no concept of routing, that is what a web server does. One PHP file per page is also not true, again you are confusing two different things. There is also no 'default templating', I can pipe to, or make PHP calls from the command line. A programming language doesn't need templating outside of 'include' (which isn't a language thing - its an interpreter thing, but lets not get too deep).
So chill out for a moment and appreciate that what Rasmus achieved with PHP is by most measures a success, has a very important place in the web and web history, and like BASIC, Pascal, etc. before it was an important impetus for a whole new generation of people picking up programming.
"most things become popular for very good reasons"
Sure. But those reasons are gone. Long gone. So please, wrap it out already.
"that is what a web server does"
Did. Most PHP apps don't use /some-article.php and /another-article.php with relevant PHP files under those names, that would be bizzare. There surely is A routing FRAMEWORK those days.
"One PHP file per page is also not true"
...if you're using A FRAMEWORK.
"There is also no 'default templating', I can pipe to, or make PHP calls from the command line"
So what? There's still default templating outside <? ?>
And that's what you use unless you've got A FRAMEWORK.
Do you see a pattern here? The pattern is that you didn't read my comment, you used regexes instead. Sadly.
But it still has 1000+ functions in the default namespace?
And every file still starts with <?
And if one of them doesn't, then your web app would fail epically because you were gzipping your output into your output stream (one and only one), and this extra space in one of files ruined your gzip.
To be fair, it's wonderful that complex PHP apps ever work. It's a complete surprise to me, I'd say they run-by-accident.
Whether you would be able to call methods on it depends on whether the Snarl author did some (trivial) code magic or not, but it's certainly doable too.
Still I have no idea why would you want javascript in ruby in the first place.
With a stub DOM and Javascript interpreter, you can pass generated output from web application views directly into your testing environment and make assertions about the resulting behavior, dynamically-generated DOM nodes, etc.
There are a number of projects similar to this one (for which, sadly, I cannot currently pull up any bookmarks) mostly intended for a similar set of tasks. Being able to bring RSpec or Cucumber to bear on a hairy JS testing job can make the process much more enjoyable.
As for using Javascript from Ruby, it might be quite nice as a language to let your users write extensions and plugins. It's a language where the implementations all have an emphasis on sandboxing.
Someone should build a social and pedagogical programming environment for kids on the web. The main problem here is the frustrating fact that one stupid browser doesn't support an HTML tag that's now 4 1/2 years old.
Yes, because every kid (at least in the 'developed' world) nowadays has web access but not every kid can install software on the machines they are allowed to use (for instance in school, the library or their parents' machine).
And, they can very easily show it to there friends, if it is in javascript. My niece loves designing webpages that she shares with her mates. Of course, getting her to program rather than put up pictures of twilight is another issue.
Scratch is definitely a cool introduction to the world of programming. But I worry that in its attempt to make programming accessible sets up kids for a rude awakening. Most "real" programming isn't like that at all. Yet the kind of code I wrote in the 80s in Apple BASIC isn't so different "in kind" from a lot of the code I write professionally today.
Sorry for posting so many comments: I'm a teacher so the issue of computers, programming, and education fascinates me to no end :)
Typing. The physicality of an interaction is not to be understated. I've seen wizards with specialized interfaces (Flash, PhotoShop, Final Cut, etc) struggle miserably with text based input.
Yes, but programming is about patterns, and, in my opinion, patterns are more simple to spot visually than with text.
It's maybe more important for a kid to learn that than learning about the "materiality" of programming.
Are there decent tools to debug and check JS for you, so that you don't have to rely on the browser built-in support (which is incredibly forgiving but also doesn't tell you what is going on)?
A massive advantage of BASIC was that it would tell you it was wrong as soon as you typed something with a syntax error in it, and it put a big flashing "?" (or similar) right there until you fixed it. Can JS be made to do that?
If I was the only person left claiming to be [insert group of people here], would that mean that being a [said group] would be defined by me? Just because there is only one thing claiming to be something doesn't mean you can leave behind actual ancestry.
I (or anyone else) can claim to be a lot of things. That doesn't make it so.
I'd agree with you if we were referring to political parties such as democrats or republicans. Those do (and have) changed over time, likely no longer standing in the same region of the political spectrum as they once did. I'd also agree with you on ambiguous terms like liberal and conservative, which are relative terms. Communism isn't that ambiguous or relative. It represents a fixed set of ideologies like laissez faire[1]. It may not work or it may be completely unattainable, but that isn't the point. If you call something a duck, it should walk like a duck and quack like a duck. If it doesn't, well, it probably isn't a duck.
1. Communism and laissez faire are obviously different ideologically, but they are still somewhat fixed ideologies.
"...the lack of trained and skilled workers as opposed to the surging numbers of graduates has led to the emergence of an abnormal trend where graduates are paid the same or even less than migrant laborers."
Everybody wants to talk and earn, nobody wants to actually work.
Sorry, but for programming language, popularity is everything. It's a social phenomenon, it grows superlinearly with number of users.
And languages become popular and unpopular for a reason.
For common lisp, those reasons are:
It's ancient.
Parties interested in it can't agree on anything so its development is stalled.
It claims to have a huge library which is tiny by 2009 standards, and doesn't have vital things like network i/o or unicode. Yes, implementations support those proprietarely, yet noone cares, because it's not in standard libs.
It has problems with reflection, which is doubly awful for a lisp.
CLOS is interesting, but for most uses smalltalkingly simple OO would be much more desirable.
You clearly haven't used the language on real world project. In CL world, there is enough people interested to develop actively several implementations.
Also, you (as others making opinion on language from blog posts) are for some reason fixated on the idea of stuff in standard library. When it's not in standard, it doesn't exist. Wrong.
You forgot that in CL, library developer has the same freedom as CL implementer. You are welcome to roll your own continuations, embedded compiler or transaction layer in your chosen popular blub for example.
All your reasons are superficial.
The "ancient" argument is not worth commenting.
Unicode has just about every CL already implemented.
You can emulate single-dispatch of Smalltalk OO in exactly 0% of wrapper code.
And tools, I hardly miss something when tracing, profiling, code completion, live upgrades, image snapshots are either solved by standard, implementation or SLIME.
Also you forgot to write that "LISP is interpreted and slow" once again.
"Also you forgot to write that"
Okay. You want to argue with yourself not with me, to the point when you start rewriting my claims.
So, you go and argue with yourself.
We can hardly argue about CL when you know nothing about it.
Your "arguments" seemed like common set of misconceptions about CL, the "LISP is slow" is such a folklore that I thought you forgot to write it, that's all.
And what you need, it is not a fancy representation (from a closed source program). What you actualy need is the information itself for your custom reporting needs.
May I ask if you can export all of this info (in a readable format)?
EDIT: answer of the above from the article:
Currently you can save diagrams as XPS files and it also possible to copy diagram or legend to clipboard as image
jpg is readable, but wasnt what I was looking for :(
Small languages may be interesting but we just don't have enough humans to speak them all, as humans don't want to study small languages unless they happen to be hobbysts or acquire that language as children.
