Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Additional programming languages

This thread is locked; no one can reply to it. rss feed Print
Additional programming languages
Tobias Dammers
Member #2,604
August 2002
avatar

axilmar said:

Thus, two major problem would be solved:

You'd also be introducing a security problem the size of Tokyo.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

axilmar
Member #1,204
April 2001

You'd also be introducing a security problem the size of Tokyo.

Why? please elaborate.

bamccaig
Member #7,536
July 2006
avatar

axilmar said:

The problem could be eliminated, if the actual rendering code was part of the code of the page itself...

...

Thus, two major problem would be solved:

1) rendering incompatibilities between browsers.
2) extension of the language with new tags.

Since the rendering code would be part of the page, the HTML would no longer be simply a markup language, but a fully fledged Turing-complete programming language.

That doesn't make any sense. That's still not a programming language; <h1> is a document header (data), not prompting the user, summing two numbers, or printing a string (instructions).

If the rendering code was part of the page itself that would be incredibly redundant, requiring enough code to actually render each element duplicated in each document. It would also be inaccessible.

The rendering code is shared between some browsers (e.g., WebKit), but it can't be shared by all of them. HTML describes a document structure, and CSS describes generically how to render it, but it's not possible to get 100% equivalence across all user agents. Some users are using a UNIX text-terminal, others don't have color, others have poor eyesight and require text to be enlarged. HTML is so successful because it is so accessible.

HTML is not and never will be a "programming language" and it doesn't even make sense for the HTML code itself to be the "rendering code". ::) It sort of used to be in a sense, back before CSS, but at most the language specification tells what <h1> should look like and each user agent vendor still has to implement code to render it. Even that was a horrible model, which is why we now have a separate styling language to describe how the document should look, leaving HTML to describe the semantic structure of the data.

You're beginning to sound like verthex. :-X Perhaps you're having trouble expressing your ideas in English? What you've said in this thread doesn't seem to make any sense whatsoever.

Specter Phoenix
Member #1,425
July 2001
avatar

Sorry bamccaig, I was just making that those remarks to be a smart @ss for what you said. Didn't expect it to go much further than my silly ramblings on it. Never thought anyone would have took it serious, hell I didn't even take it serious when I was arguing it.

Though it does make me wonder. HTML has text fields, in theory you could use one of those to get user input. Though it would require a SH!T LOAD of under the hood interpreting to even make HTML a fraction close to a programming language.

When I made my arguments I was doing it off a silly image I had in my head that I knew was wrong, but hard to pull arguments out of the air if you don't have an image in your head to base them off. What I was implying in examples was that they programmer would have to do a lot under the hood of the 'HTML Compiler' to make HTML a 'programming language' because he would have to design the compiler to look through the code and detect the tags, look for other operators within the tags, etc to even make my notion work.

I've not touched HTML for a year or two (don't have any web space to mess with it and not entirely sure what all I can setup locally to get back into web development things again). Think I have Apache/MySQL/PHP on Ubuntu, but outside that I don't have much anything else (and yes I do know HTML/CSS/JS work with Apache).

"Can't a man even talk to himself without being interrupted?" -Krull(1983)
"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix
"Programming == AWESOME the rest is just tools to accomplish it."
END OF LINE

bamccaig
Member #7,536
July 2006
avatar

HTML/CSS/JavaScript work entirely client-side. You don't need a Web server at all... :-X Just open an HTML file in your preferred Web browser.

Specter Phoenix
Member #1,425
July 2001
avatar

bamccaig said:

HTML/CSS/JavaScript work entirely client-side. You don't need a Web server at all... :-X Just open an HTML file in your preferred Web browser.

Well I meant in tangent with PHP/MySQL....though last time I did JS I botched something as it was just showing the JS code in the browser heh.

"Can't a man even talk to himself without being interrupted?" -Krull(1983)
"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix
"Programming == AWESOME the rest is just tools to accomplish it."
END OF LINE

axilmar
Member #1,204
April 2001

bamccaig said:

That doesn't make any sense. That's still not a programming language; <h1> is a document header (data), not prompting the user, summing two numbers, or printing a string (instructions).

Actually, 'h1' would be the name of the function which renders everything in it as a header.

Quote:

If the rendering code was part of the page itself that would be incredibly redundant, requiring enough code to actually render each element duplicated in each document.

Not if the rendering code was a module shared by all pages.

Quote:

It would also be inaccessible.

What do you mean?

Quote:

but it's not possible to get 100% equivalence across all user agents.

That's because the rendering code is not shared across all user agents.

Quote:

Some users are using a UNIX text-terminal, others don't have color, others have poor eyesight and require text to be enlarged.

These capabilities can be built into the rendering module.

Quote:

HTML is not and never will be a "programming language"

Personally, I don't see why.

Quote:

and it doesn't even make sense for the HTML code itself to be the "rendering code".

Why? please elaborate. I find it perfectly sensible.

Quote:

each user agent vendor still has to implement code to render it.

That's exactly the problem solved by my concept.

Quote:

Even that was a horrible model, which is why we now have a separate styling language to describe how the document should look, leaving HTML to describe the semantic structure of the data.

That's perfectly achievable with code. If there was a programming language instead of HTML+CSS, code would be used to style the data, just like CSS does. The only difference would be that the code would be common for all browsers, eliminating the rendering differences.

Quote:

Perhaps you're having trouble expressing your ideas in English? What you've said in this thread doesn't seem to make any sense whatsoever.

Perhaps the idea of what a browser should do is too deeply entrenched in people's minds, and they have a hard time understanding something different.

My idea is simple, really: instead of a markup language, use a programming language. Instead of tags, have functions, and let the content inside tags to be parameters to the functions. Simple, effective, and solves two major browser problems.

bamccaig
Member #7,536
July 2006
avatar

axilmar said:

My idea is simple, really: instead of a markup language, use a programming language. Instead of tags, have functions, and let the content inside tags to be parameters to the functions. Simple, effective, and solves two major browser problems.

You're not the first one to have this idea. Search the forums back a few years and you'll find a few threads where I proposed basically the same thing: a Web-based on software packages instead of Web sites. I was naive and inexperienced with Web technologies then. Now I am much more familiar with them and don't think that would be going in a useful direction. What we have is already pretty good. The languages can still be cleaned up, and redundancies and mixed concerns removed, but otherwise the client-side of the Web works quite well. It just requires a different way of thinking. Web applications should predominantly be done on the server-side, in whatever language you want. The client is merely a glorified input/output device.

Oscar Giner
Member #2,207
April 2002
avatar

axilmar said:

Not if the rendering code was a module shared by all pages.

Where would that module be stored? So my understanding is that someone must take care of implementing it for everyone else to use? That would be a big monopoly, very dangerous.

Tobias Dammers
Member #2,604
August 2002
avatar

Axilmar, you're not making much sense, sorry.

Either your language does exactly what HTML does, in which case it is completely pointless, and all you're doing is implement yet another user agent - which is fine, it's fun and a great learning experience; or it is a client-side web programming language, of which we already have enough, so it wouldn't solve any new problems.

About the security thing: look at Java and Flash, two technologies trying to do pretty much what you propose (only with a different syntax): Both are massively complex monoliths, with vulnerabilities popping up on a regular basis. These two alone probably account for more than half the internet's serious security threats. Worse yet, unlike the browser itself, they go unpatched on many people's systems for months or years.

Also, note that rendering differences are a good thing. The principle is called 'graceful degradation', and it means that user agents get to choose which features they implement and which ones they don't. Unfortunately, many web designers ignore this philosophy and try to bend HTML into a print-media mentality instead; their designs usually break horribly on non-mainstream user agents. That's not HTML's fault, though: if you want an exact design format, use PostScript, PDF, SVG, or something like that. HTML is for semantically-structured documents with presentational hints, and its strength is that a well-written document will work reasonably well on all compliant user agents, even if they're text-only, aural, tactile, small-screen, monochrome, or otherwise unusual. The user agents just assumes that the HTML makes sense semantically, and ignores anything it doesn't support, doing something 'sensible' instead.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

axilmar
Member #1,204
April 2001

bamccaig said:

You're not the first one to have this idea. Search the forums back a few years and you'll find a few threads where I proposed basically the same thing: a Web-based on software packages instead of Web sites.

But I am not proposing a Web based on software packages. My proposal still works with Web sites, a client and a server. What I am proposing is a better client.

Quote:

What we have is already pretty good. The languages can still be cleaned up, and redundancies and mixed concerns removed, but otherwise the client-side of the Web works quite well.

No, it does not. Not only we have rendering differences between browsers, but introducing new capabilities can take ages.

Quote:

It just requires a different way of thinking. Web applications should predominantly be done on the server-side, in whatever language you want.

Web applications are composed of two parts: the server side, and the client side. Why should the server side be as programmable as we want, but not the client side? it's stupid to not have equal programmability from both sides.

Quote:

The client is merely a glorified input/output device.

And that's what's wrong with it.

Where would that module be stored?

In the browser.

Quote:

So my understanding is that someone must take care of implementing it for everyone else to use? That would be a big monopoly, very dangerous.

There would be no monopoly. If a better rendering library comes across, the developers of the application would use that rendering library instead of the previous one. It would be no different than using different Java libraries or different C++ libraries that implement the same API.

Either your language does exactly what HTML does, in which case it is completely pointless, and all you're doing is implement yet another user agent - which is fine, it's fun and a great learning experience; or it is a client-side web programming language, of which we already have enough, so it wouldn't solve any new problems.

By moving the rendering of a web page from the browser to the client-side web programming language, more uniformity can be achieved.

Quote:

Both are massively complex monoliths with vulnerabilities popping up on a regular basis.

That's a matter of how they are designed, not because the idea is problematic.

Quote:

Worse yet, unlike the browser itself, they go unpatched on many people's systems for months or years.

How come? I get regular updates of both Flash and Java, as well as Firefox.

Quote:

Also, note that rendering differences are a good thing.

Only if they are intentional and not due to different ways of understanding the specifications or lack of resources.

Quote:

The principle is called 'graceful degradation', and it means that user agents get to choose which features they implement and which ones they don't.

Graceful degradation can easily be built in the system I am proposing and it would be better, actually, than the current system, because it would not depend on features programmed by the browser developers but on the host system's features.

Quote:

and its strength is that a well-written document will work reasonably well on all compliant user agents

With my proposal, a document will work a lot better and on more agents than before.

Quote:

The user agents just assumes that the HTML makes sense semantically, and ignores anything it doesn't support, doing something 'sensible' instead.

Nothing that it could not be built into a library.

Tobias Dammers
Member #2,604
August 2002
avatar

Axilmar, why don't you write a little prototype to demonstrate what you have in mind? I'd be glad to test it and review your code, as well as do a little inofficial pen-test.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Oscar Giner
Member #2,207
April 2002
avatar

Quote:

Where would that module be stored?

In the browser.

axilmar said:

There would be no monopoly. If a better rendering library comes across, the developers of the application would use that rendering library instead of the previous one.

So there will be several rendering libraries, and different browsers will choose what library to use?. So how is that different from what we have now? Different libraries will render things different, so you haven't solved anything.

bamccaig
Member #7,536
July 2006
avatar

Axilmar, why don't you write a little prototype to demonstrate what you have in mind? I'd be glad to test it and review your code, as well as do a little inofficial pen-test.

I'd settle for some pseudo-code to demonstrate what he means... I still can't figure out what he's talking about. The only thing I know about his replacement is that it's magically "better". :D

Tobias Dammers
Member #2,604
August 2002
avatar

bamccaig said:

I'd settle for some pseudo-code to demonstrate what he means...

A proper tech design would also do.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Dario ff
Member #10,065
August 2008
avatar

It seems this year I have to do comp sci in Uni, and Pascal will be the language to be used.

I've already read most of the syntax anyway, and I can't help but feel so restricted after coding in C for so long. :-/ It's understandable that it's an older language, but itself is not that much big of a problem, but how the teachers use it.

Still, it seems the course won't even cover pointers so I guess I don't need to worry much about the dynamic array restrictions and such. It would all be well and good if they didn't force me to use this as an IDE in 2012:
{"name":"FreePascal_IDE.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/2\/b2c4f1f2ddec902b97968d0569945296.jpg","w":650,"h":330,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/2\/b2c4f1f2ddec902b97968d0569945296"}FreePascal_IDE.jpg

Also the lack of case sensitive restrictions makes up for some pretty horrible naming conventions from the teachers. And typing spanish names into code just feels way too wrong(ñ í ó é ú á). It's almost a pain to see it. :([1]

References

  1. And it starts to make you doubt how much actual experience they have. ::)

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

Crazy Photon
Member #2,588
July 2002
avatar

Heh I used that one on my first semester at uni! although that was 13 years ago...

-----
Resistance is NEVER futile...

Specter Phoenix
Member #1,425
July 2001
avatar

I was told to learn Pascal, Ada, and Smalltalk or Java then C++ a few years back. Never found the tools for either so I stayed on C++. Learned assembler in college but not used it much so I don't remember it well.

"Can't a man even talk to himself without being interrupted?" -Krull(1983)
"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix
"Programming == AWESOME the rest is just tools to accomplish it."
END OF LINE

verthex
Member #11,340
September 2009
avatar

I was told to learn Pascal, Ada, and Smalltalk or Java then C++ a few years back. Never found the tools for either so I stayed on C++. Learned assembler in college but not used it much so I don't remember it well.

Why does anyone even need Pascal, is it somehow related to Delphi?

LennyLen
Member #5,313
December 2004
avatar

verthex said:

Why does anyone even need Pascal, is it somehow related to Delphi?

Delphi is an implementation of Pascal that comes with it's own tools.

As to why Pascal, it's a fairly good language for learning programming concepts. We used it in my high school programming class, though, that was 21 years ago. In my first uyear of university, we used it's "successor" - Modula-2.

Tobias Dammers
Member #2,604
August 2002
avatar

Delphi is a facelifted Pascal, brushed up to be suitable for what used to be 'modern' programming in the late 1990's.

Pascal itself isn't too bad, especially as a learning vehicle. I'd say man up and stop bitching around. If you're any good, you can complete the assignments single-handedly using nothing but notepad (or nano, if you're a *nix person) and a command-line toolchain. BTW, that screenshot looks suspiciously like TurboPascal; the IDE isn't that bad, really. It's kind of basic, you don't get any fancy features like code completion, and it's text-mode, but hey, it's supposed to be about the programming, not the tools.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Dario ff
Member #10,065
August 2008
avatar

If you're any good, you can complete the assignments single-handedly using nothing but notepad (or nano, if you're a *nix person) and a command-line toolchain.

I've already been doing that with Notepad++. As long as the compiler is the same I doubt I'll have any trouble with it.

Still, you'd think that in 2012 they'd give people a better introduction with an environment that actually supports most text-editting features and that its maximum window height isn't around 300 pixels. :P Just gives people a bad impression.

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

axilmar
Member #1,204
April 2001

Axilmar, why don't you write a little prototype to demonstrate what you have in mind? I'd be glad to test it and review your code, as well as do a little inofficial pen-test

Oh, how much I'd love to have the time to do so!

So there will be several rendering libraries, and different browsers will choose what library to use?. So how is that different from what we have now? Different libraries will render things different, so you haven't solved anything.

Having different rendering libraries is not the same as having different browsers. Libraries can be replaced and fixed very easily, unlike browsers. Libraries can also be enhanced and extended very easily.

bamccaig said:

I'd settle for some pseudo-code to demonstrate what he means... I still can't figure out what he's talking about. The only thing I know about his replacement is that it's magically "better".

Ok. In the current system, for example, a login page (username, password, submit button) would be something like this:

<html>
    <head>
        <title>Login</title>
    </head>
    <body>
        <form action="login.asp" method="get">
            Username: <input name="fname" type="text"><br>
            Password: <input name="lname" type="text"><br>
            <input value="Submit" type="submit">
        </form>
    </body>
</html>

The tags are instructions for the browser, which renders the page the way it wants.

What if, instead of the server transmitting html, it transmitted a program? for example:

    setTitle("Login");
    new Form(action = "login.asp", method = "get", [
        new Label(value = "Username"), new Input(type = "text"), br(),
        new Label(value = "Password"), new Input(type = "text"), br(),
        new Input(value = "Submit, type = "Submit")]);

Don't pay attention to the syntax, it could be S-expressions, for example:

    (title "Login")
    (form (action "login.asp") (method "get") '(
        (label (value "Username")) (input (type "text")) br
        (label (value "Password")) (input (type "text")) br
        (input (value submit) (type submit))
     ))

Or it could be XML:

     <title>login</title>
    <form action = "login.asp" method = "get">
        <label value="username"/> <input type="text"/> <br/>
        <label value="password"/> <input type="text"/> <br/>
        <input type="submit"/>
    </form>

The syntax does not really matter in my explanation. What matters is what happens underneath.

Now, when a browser receives an HTML document, it parses it, and translates the text to an internal representation, which then renders into the page. The rendering algorithm is hardcoded into the browser.

My idea goes like this: instead of the transmitted data being a document, it could be a program. The browser simply receives and executes the program. The program itself knows how to display itself on the browser window. The browser knows nothing about the presentation, except perhaps the options of the user regarding the presentation, which are passed to the program being executed.

I hope this explains my idea.

Oscar Giner
Member #2,207
April 2002
avatar

axilmar said:

Having different rendering libraries is not the same as having different browsers. Libraries can be replaced and fixed very easily, unlike browsers. Libraries can also be enhanced and extended very easily.

Be realist, what would happen in this scenario? Microsoft would still implement its own rendering library, that IE would use, and it would have been as non-standard compliant as IE has been. There's no difference.

Actually, it's pretty similar to how things are today. IE rendering engine is actually a library, that you can use to implement your own browser. And there's also Webkit.

bamccaig
Member #7,536
July 2006
avatar

axilmar said:

The tags are instructions for the browser, which renders the page the way it wants.

What if, instead of the server transmitting html, it transmitted a program? for example:

What does that program do? If I was to interpret that as a program, I would see it arbitrarily setting a global attribute and instantiating an object graph that is never used. Also, I'd like to note that as a rule your "program" is larger and busier than the HTML you provided, without including any more information.

axilmar said:

Or it could be XML...

Note that your XML example really is an HTML fragment. :P That would probably render and function quite similarly to the original HTML document in many browsers.

axilmar said:

The syntax does not really matter in my explanation. What matters is what happens underneath.

Which is exactly the part that you are failing to explain at all. You can have the greatest idea in the world, but if you can't communicate it to other people then you might as well have never had it.

axilmar said:

Now, when a browser receives an HTML document, it parses it, and translates the text to an internal representation, which then renders into the page. The rendering algorithm is hardcoded into the browser.

You don't know if it's hard-coded into the browser. Every browser is different, and the rendering algorithm can vary somewhat. Most browsers probably hook into a library to handle the rendering. For example, the WebKit layout engine.

axilmar said:

My idea goes like this: instead of the transmitted data being a document, it could be a program. The browser simply receives and executes the program. The program itself knows how to display itself on the browser window. The browser knows nothing about the presentation, except perhaps the options of the user regarding the presentation, which are passed to the program being executed.

The problem with this is that your example programs above don't contain any of this extra information. In fact, they're at best equivalent to the HTML, but you actually left out a couple of attributes. As a rule, though, their syntax is more verbose (it takes more text to represent the same idea), which is going in the wrong direction.

If the browser knew nothing about the presentation of these "programs" then no browser would be able to render them at all. Your programs don't describe how they should be rendered. The problem is that if they did, then your Web site authors would need to manually write code for every possible user agent they run on, because you can't render a Web site the same in all user agents. The environments differ.

axilmar said:

I hope this explains my idea.

It does not.

Append:

This is the only trace that I've been able to find about my ideas from years ago:

Personally, I hate today's Web languages and as a single example want to replace everything SGML based with something more programmer-friendly. I'm no fan of <anything that="looks" like="this" />. I am devising a replacement for Web development that I can only describe as an extensible, byte-coded, C-like language with explicitly defined static-typing, manual memory management (and out of scope backup garbage collection), and graphical concepts derived from full fledged 2D/3D graphic libraries, as well as Flash... It would be rendered in a single official 'browser' , or by a virtual machine or run-time. It would need a standard framework for defining common Web/GUI controls, graphical elements, and animation concepts; as well as for data management and access. From there you could extend it as required, and possibly implement binary libary concepts, etc. There would hopefully be an official IDE designed for it's development with graphical support and debugging, as well as optimizers, and automatically tracked application versioning for update management and ultimately, when you 'installed' an application the client's browser, virtual machine, or run-time would compile it natively for better performance...

I imagine there was some discussion in that thread after this post, but I'm too embarrassed to look. :P



Go to: