A simple new web (HTTP, HTML, JS) replacement based on s-expressions and lisp. It would be useful for things like file hosting, wikipedia/wikis, BBSs, online newpapers/blogs, imageboards, youtube/mediagoblin style video sites.
Instead of XML we use s-exp for markup. It will be a very simple functional markup language that could be defined in a page or two. We will not allow it to grow and grow horribly like the W3C to the point that it's impossible to implement from scratch.
Instead of javascript we use a simple lisp language (similar to R5RS without continuations) which is interpreted with strict resource and permission bounds, so it will never do anything you do not allow it including swamping your computer down like current js JIT systems.
For servers, instead of tools similar to PHP we will use systems inspired by type-checking that are able to statically ensure that no vulnerabilities in the class of XSS/SQL injection/... exist.
1. A first draft design needs to be created.
2. It should be easy to get something up and running quite fast by writing a proxy that translates all this s-exp stuff into HTML - just for the purpose of prototyping.
3. Reference implementations from scratch - focus on low memory usage and stability (using safe languages instead of C or C++).
Good idea, I think there has been discussion about something similar on /prog/ about half a year ago. EME and the inherent insecurity of a browser that has essentially evolved into a big clusterfuck of an OS (see /prog/1399299127 for an example) might even give this more than five users, although I'm not expecting or even wanting mainstream adoption.
Lisp as a scripting language is a nice idea for efficiency, simplicity and sanity reasons alone, yet I think we shouldn't focus too much on replicating what already exists. A big problem with WEB 3.0 ROCKSTAR APPS is that they abuse protocols to do things they weren't designed to do. A similar thing, if not as bad as Javashit, goes for HTML. It has a fair share of crap like the redundancy in having both semantical and formatting tags. There is no need to repeat the errors of the past; you have the chance to fix something horrible, don't waste it like Google did with Dart.
A focus on simplicity seems desirable, Project Xanadu (as mentioned in the discussions several months prior to this thread) might be worth looking into as well.
Restrictions on the servers used don't seem relevant however: In the end, everything that can talk the protocol can act as a server. If people want PHP and node.js, there is nothing you can do about it except call them out on being utter retards. As a general guideline, I'll give it the credit it deserves though.
Name:
Anonymous2014-05-15 14:15
Browsers allow unclosed tags and can handle many cases of broken HTML, which SEXPs wont allow.
It needs to be designed well first. This can be separated into parts which can be worked on by different groups:
* Layout and Presentation: Work out what layout primitives will be required for a wide range of presentations: How to layout different sorts of user input forms, how to display different types of threaded and tree based dialogues, how to display tabulated data, how to flow text around images, how to include media like images, equations, sound, video. * Layout Engines [depends on Layout and Presentation]: Produce implementations of the layout system. A simple proxy that turns sexp code into HTML might be a useful as a prototype initially. Real rendering engines should be carefully designed to minimize memory usage and put a limit on the CPU usage so that extremely complicated ASTs will be rejected rather DOSing the users browser/computer. * Scripting: Spec out the language as a simplification of R5RS. Work out what kind of API it will have access to and how permissions will be assigned to scripts. In a safe language implement an interpreter for it that carefully limits its resource usage. * Protocol: A replacement for HTTP/some kind of layer ontop of TCP is required for distributing and fetching pages. Decide how images and other media should be distributed, take inspiration from things that work nice and stable like bittorrent. * Security [linked with Protocol]: Work out how authentication, TLS and certificates should be integrated from the start: reject CAs in favor of something that gives users power like ssh style trust on first use or web of trust. * Servers: Study common security problems in the web, design a language with static analysis that makes compile time errors out of these problems when possible (as in injection/quotation problems). Make it safe and easy for people to create, operate and host their own sites. * Blind spots and Mistakes: Look for important things that haven't been considered and list them. Point out flaws and improvements. Look for things that work well and copy them.
Overall for coding and design: The highest priority is to make things as simple as possible, source code should be short and readable. Keep good documentation up to date that explains things like common use cases. it's important to use safe languages to avoid buffer overflows and other problems which can cause crashes and allow exploits.
Name:
Anonymous2014-05-16 20:09
>>4 have more than one type of delimiters for the s-operations
This is a pretty big task. I propose that we form committees and subcommittees to debate each detail and a governing body to democratically accept or reject each proposal's entry into the reference white paper and implementation.
Name:
Anonymous2014-05-16 21:26
>>9 both tcp and tls are not good for this job, we need sexpr replacements
Name:
Anonymous2014-05-16 23:55
ONE WORD. THE FORCED FRAGMENTATION OF THE SEXPR. THREAD OVER.
Name:
Anonymous2014-05-17 0:05
>>14 It amazes me how anyone thought this would think this is a good idea, and yet it is done over and over again.
Name:
Anonymous2014-05-17 0:07
>>17 It thinks to amaze thought I would, thinking is done amazingly and over again thought.
>>24 That's why it shouldn't allow sloppy work in the first place. Even the sloppiest one will at least work on something until it works as intended, and if it doesn't work, nobody will depend on it.
Name:
Anonymous2014-05-18 0:32
>>25 The web is smelly shit because of the people that built it.
>>26 The work is sloppy because the work is sloppy to begin with. Web coders mess up when serializing data. If the standard can't handle their errors, then the site is broken and it becomes your problem if you need to use it in some way. Just because a page is broken doesn't mean the page will be fixed. A perfect example was shiichan. Would you have boycotted old /prog/ until someone fixed the malformed html in a few of the posts there? That would be retarded. And wanting a specification that cripples the entire page when malformed expressions appear doesn't make any more sense.
Name:
Anonymous2014-05-18 0:40
Web coders mess up when serializing data.
Look, people mess up too when they write programs. Does that mean the compiler should be forgiving and create what it thinks the user means? No, this isn't Javashit's anally prolapsed type system.
If the standard can't handle their errors, then the site is broken and it becomes your problem if you need to use it in some way.
Then make sure your Sexp page actually makes sense before uploading it to your server? It's not that hard.
Would you have boycotted old /prog/ until someone fixed the malformed html in a few of the posts there?
Wasn't that what some people made with the <> thing in the title?
You seem to be under the wrong assumption this newly proposed web is targeted to epic Ruby ninjas. Incompetent brogrammers aren't supposed to make things for the new Lispweb.
Name:
Anonymous2014-05-18 1:00
>>28 There are posts on old /prog/ that contain non-nested tags, like <a><b></a></b>. See this is the thing, you never noticed this because your browser handled the error gracefully. Would you prefer a browser that says `parse error' and doesn't show any information in the page? Verification of static pages is trivial, but that doesn't mean there aren't static pages out there with malformed HTML. Dynamic pages are somewhat more understandable, but still, it's not like it's hard to balance tags.
Incompetent brogrammers aren't supposed to make things for the new Lispweb.
That's nice. I might need a thing or two provided by incompetent brogrammers though, so I'll keep using both webs.
There are posts on old /prog/ that contain non-nested tags
You're supposed to handle user input on the server side, which is easily doable by parsing the BBCode. and if there is a parse error return the raw user input with escaped characters.
If you fuck up a dynamically generated webpage as a developer, it's your fault and you shouldn't expect the anus-loose parsers to deal with your sloppiness.
>>29 No, because all </x> tags are replaced with closing parens.
Name:
Anonymous2014-05-18 2:16
>>32 ``should'' isn't an appropriate word. There is only what is. old /prog/ existed and used the software, shiichan, written by shii. Shii missed a case of some kind in his bbcode parser and some posters learned how to exploit it to get unintended effects like nested quoting. Shii is long gone and the development of the board software is frozen. You have two choices.
1. Use a browser that gracefully handles malformed HTML and enjoy the website. 2. Use a browser that refuses to display the page and wait for shii someone to fix it.
In one of these cases you get to use a website, and in the other case, you don't get to use it. Which do you prefer?
>>33 See >>31. It's not the same as (a niggers literally (b tongue) my anus), which would be <a>niggers literally <b>tongue</b> my anus</a>.
>>34 Should is a word used by those who have the power to will the world into what they want it to be. You clearly do not possess such power and will.
Name:
Anonymous2014-05-18 2:50
>>35 What are you going to do when you find a malformed expression in a webpage? Email the administrator and threaten to bomb their headquarters if they don't fix it within 5 working days? If the page displays properly on the common browsers nobody will give a fuck. The only way you would have the power to change this is if you compromised their servers and patched the source yourself. But given the web dev can't produce well formed HTML this is likely possible.
If there was some s-operations web which was by desing strict with erroneous operations in webpages code, and bypassing this in browsers was not trivial, so such capability was either imcomplete or missing in avalaible browsers, then wouldn't all webpages in this web not have erroneous operations?
>>35 No, english "should" often denotes rather some kind of morality. Should be, not shall.
Name:
Anonymous2014-05-18 3:19
/prog/ challenge #388473872
Compromise all servers and all client machines. Replace all servers and clients with implementations conforming to the lisp based web. They'll thank us later.
Name:
Anonymous2014-05-18 3:22
HTML is just a document markup language. Why do you all care about correctness so much? It isn't programming, and mistakes in the code are irrelevant as well as the page renders fine. Why are you trying to hold glorified typists up to the same standards as the guy who writes firmware for nuclear reactors? It is simply never going to happen. For all it's flaws, look at XHTML. Any browser that breaks on a missing tag is going to lose a user and wouldn't be around for long.
Please try to survey the reality of the situation, you hopeless autists.
>>37 Yes, Morality, Applied Power and Will to Annihilate All evil and amorality. You stupid atheist inferior. Us Superior Spirits Shall Should Shall as we Should Be.