Go on, fire up a cheap VPS somewhere like DigitalOcean and run "rm -rf / --no-preserve-root". Maybe I am too easily amused but as a long-time Linux user on the desktop this is one of those things I always wanted to try. After it runs, you can't even shut down or run anything else, you just kill the SSH session.
While static analysis can be quite a powerful tool, it doesn't magically fix everything. Some of the typical web-application vulnerabilities are shell/SQL injections, XSS, and CSRF. Also, passwords saved in a insufficiently hashed form, or even in plain-text. All of those are bugs on the architecture level, or "business logic bugs".
You can certainly prevent shell/SQL injection very easily with a good type system. Yesod, one of the Haskell web frameworks, certainly does this. Basically, you just give strings gotten from the user a different type than normal strings so that you can't use them without sanitizing or explicitly circumventing the sanitizer.
I don't know enough about web development to tell you if you can prevent XSS or CSRF, but I wouldn't be surprised if you could.
The important insight is that a good type system can fairly easily do much more than most people realize. Certainly far more than you can do with languages like Java!
Languages with good type systems (haskell, scala, ocaml) can certainly address these. I haven't been following liftweb (scala) closely but I give the author, DPP, credibility, when he says that he's addressed the first three.
The semantic diff is pretty cool. It will probably be pretty hard to apply that to C (cpp) and Lisp (macros, and especially the programmable readers in some Lisps). But maybe we don't actually need a solution for the general case and displaying "most" changes in a semantic way is enough.
I imagine these higher-level diffs could be especially useful for things where one doesn't have that much insight into the source code - for example, scanning for API changes between two versions of a Framework (where maybe even displaying only changes to public methods/exports would be enough). In any case, diffs on the AST level seem like a good, and quite under-explored, idea.
> It will probably be pretty hard to apply that to C (cpp) and Lisp (macros, and especially the programmable readers in some Lisps).
C is really hard to parse because of preprocessor. We built a prototype parser for it, and it mostly works, but it's not ready yet for the prime time.
Lisp must be a much simpler language to parse, though.
> scanning for API changes between two versions of a framework
Yes, we have this idea on the to-do list! Imagine that you are comparing two different branches of development, or two different tagged releases, and see high-level API changes between them.
Is this censored? There's nothing related to copyright infringement or porn in there. Also, the categories and trending/most-searched selection seems arbitrary. Every country has a different set of data.
I wouldn't be surprised if their result set was filtered on the same rules used for Google Suggest, which do filter out terms presumably linked to controversial file sharing websites (Pirate Bay) and adult entertainment.
I think it's funny that they censor pornstar names. I mean, it makes sense, but it's just funny how google instant quits working after a somewhat generic first name sometimes.
This was on /r/programming and now it's here - I'm sorry, but I don't really understand what this is all about. 600 lines doesn't seem ultra-small to me. And Lisp - well sure, not too common a language for games, but it's not as if this was written in a purely functional style or something. In fact, it looks like pretty standard imperative programming to me - it wouldn't look much different in C.
I wasn't trying to write it in less than 600 lines, that's just what the OP used for an interesting title, I guess.
It's just a fun project I did to learn a bit of CL. I translated the code from a Python game, so it's not in pure functional style. Now that you mention it, though, I feel like I should try that.
I'm not the parent, but I do web development - here's how I understand it:
> hard for end users to customise
I think, he means that a css-based ("modern") solution would allow end-users to just swap the css (a feature most web-browsers have as a built-in) to change the site's appearance - whereas you cannot change the way a <table> looks, for example. That is, you can't easily make <table> columns appear below each other, for example.
> works terribly in any other context than a desktop browser
The parent probably means modern non-desktop web browsers, i.e. ones with javascript and media-query support. Using media queries would allow automatically changing the site's appearance to something more usable for small-screen devices (for example) - by using bigger buttons/links/up-vote-triangles or something like that.
The problems you mentioned are orthogonal to that - mostly caused by devs that only target js-enabled modern browsers. That's bad, of course, but it's not part of "modern web development" per se - it's just bad web development.
> plays terribly with all other web tooling
If you use "modern" web-dev methods (that is, styling only per css), other (web-)services that display your site in different contexts (think google reader or desktop mail readers or something like that) can swap or remove the css and get the content (including semantics like "headline", "list" and so on) without the styling ("these are table columns", "this is centered"). In theory, at least.
I don't understand the rest of the points either, to be honest. <center> and <table> are very compact, compared to equivalent HTML/CSS solutions - that's part of the reason why people keep using them.
Ideally, there should be a feature that lets you see the personalized (that is, real) search results of others. Maybe divided into target groups ("programmers", "male users under 20", etc.). Of course, everyone's real search results will be slightly different, incorporating "+1"s of Google+ friends for example.
But, I assume, the bulk of the search ranks will be the same for people in the same (advertising) target group. (I have nothing to back up that assumption - it just would be the most sensible thing to do, I think.)
I wouldn't call that a "Haskell based browser". 1500 lines of Haskell against maybe 300 KLOC (guessed) of webkit alone. That's not "Haskell based", that's only using Haskell as a glue.
The same goes for uzbl, too, of course. Things like the Grail Browser [1] (a Python webbrowser, including the possibility to run client-side python-code - but sadly obsolete and not maintained anymore, as far as I can tell) are so much cooler than just tying webkit to GTK using $LANGUAGE.
I mean, it's not like HTML layout engines or JS-interpreters are somehow impossible to write from scratch.
You could have said the same thing about unix-like operating systems in 1991 - yet, somebody wrote one from scratch without a full-time team.
I'm not trying to put this little project here down, far from it. I think it's pretty neat. I can imagine even neater (if that's a word) things, though... :-)
>You could have said the same thing about unix-like operating systems in 1991 - yet, somebody wrote one from scratch without a full-time team
Err, at 1991 he just wrote a rudimentary OS from scratch. To make it more unix-like, stable and feature full took hundreds of people, including tens of full time company employees (IBM, RedHat, etc).
This is one of my fears with the complexity explosion called HTML5 / CSS3.
We are bequeathing the future a world where building new browsers is approximately an impossibility.
The Web is so much. Now all devices can consume the same files with comparable user experiences. There are reasonable standards. Javascript is a reasonably advanced and simple language (for the time being). But the web has failed much as well.
Hopefully the web will mature someday and someone will clean up the mess we are leaving them.
