In addition to C and C++, what languages do you find useful on a regular or niche basis in your life as a programmer, and why?

perl, vbscript, and VB.NET.

We found perl useful at work because it's a cross platform scripting language, it's complex, fast, and has lots of features. We were able to rip through gigabytes of data with a single perl script in just minutes.

As for vbscript, well for some of our other developers it's easy to learn and if used correctly can be powerful. Also our main application we support uses a variation of vbscript for automating some of the tasks. For more complex tasks I use C++ with the same application.

VB.Net, same thing with our main support application through COM only now we can add forms. VB.Net isn't that bad and for RAD tools it's pretty decent if you want to get out a quick application that looks good. Also if you want to get more complicated, you always have the option of LoadLibrary and delegates, for calling C++ libraries

Lua when making games in C/C++. Seriously, using Lua over C/C++ in less speed-critical parts of the game makes it so much easier to program. Very little to worry about (e.g., dangling pointers) because of the great way Lua is programmed.

C# when doing anything, really, outside of embedded work. This is the nicest language I have worked with so far.

python is the modern perl (glue code / semi-serious projects).

java is a reasonable language for making serious things, mostly due to the jvm. well java sort of sucks but scala is a reasonable jvm language (although its still somewhat unstable).

• Perl: very powerful text processing, very terse syntax, very flexible language. It's very fast to hack up working programs of all kinds in Perl.

• Java or C#: modern, high-level, statically-typed, "enterprise-y". These are good if you want things to be a bit more hard-structured.

• [Common] Lisp: I don't really have enough experience with it to say yet, but it seems to be one of those special languages that is really simple, but really powerful, and not taken seriously by others, meaning that your knowledge with it will give you an edge.

I use Python on a regular basis. It's easy to extend (ctypes and cython), has an extensive standard library, and I find it to be a fun language to use.

Hm..

I use Perl a lot for system administration type stuff. People have already stated pretty good reasons why. Also because its the first language I learned.

I use Java for android stuff. Thats about the only reason I use java. Similar with ObjC, only use that for iOS.

I use D2 in lieu of C/C++. Although it has lots of nice features, my day to day hacking in it is made pleasant due to the following subset of them:

1. Nested functions with lexical access to the outer scope:

void main()
{
  int a;
  void stuff()
  {
    a = 5;
  }
  stuff(); // a is now 5
}

It cleans up my code to no end.

2. Advanced array syntax:

auto a = new float[](1000);
auto b = new float[](1000);
auto c = a[0..$/2]; // Get a slice (view) of an array
b[0..$/2] -= c[]; // Perform an elementwise subtraction of c from the first half of b

I need to do a lot of array manipulation and these bits just help make things cleaner.

3. Native performance:

It's just nice to be able to write code in a clean way and be able to say with confidence that it is as fast as the equivalent C code. Sometimes I don't want to think about how to write my code in a vectorized/functional fashion, I just want to write a brain-dead for-loop. It's nice not to be punished for that (as you are in scripting languages).

I've seen more job interviews for my VB.NET than any other language. I'm also afraid to admit that MS Access is used too much where I live and everything needs a freaking rewrite from old school VB. These are real jobs, no one here recommends knowing C++, only Java and C# which are the same but these people don't care. They are very specific. If they need 3 years C# then they need C# and it couldn't matter if you had worked with C++ for a decade.

Other than C/C++, Java is what I've used to do useful things.

My boss would have fired us for even mentioning MS Access :-)

That is how you know you are working for the right guy. Most companies I have talked to that use MS products say the same thing, "We use them because it is powerful and fast to develop on and with." Always sounded dumb to me to be honest.

That reminds me of the company that is a town over from me. Background: I applied to them and they only used C# nothing else. Then last year I read in the newspaper that they had to fire and hire all new staff because apparently most the staff new C# well but and never touched any other languages. The company shut down last year around the holidays (November/December) but never said the reason. I'm guessing it is because they wanted to expand to other things that required other languages. I find it hard to believe they hired all those programmers out of college and none of them knew more than C#.

I program in Malbolge. When I want something quick and simple, I use binary.

If you want to program games on the browser -> JavaScript

Pascal and Object Pascal. There are a lot of IDE/Compilers (Delphi, Lazarus, OP4JS, Morphix...) and niches (desktop, computer games, web development [including HTML5 and Flash]... ).

I like it because it's much less cryptic than C, Java and such, so it's more readable specially if you never used Pascal before. It's also easy to write cross-platform applications (same program would compile and run in a lot of OS without any change if you use Free Pascal).

Also it was claimed as Best Programming Language by The Code Project in 2010 and 2011 (actually they said "Delphi" but there are a lot of people that thinks "Delphi" is the language name... including Borland themselves! )

And, finally, Apple used it to program MacOS from 1 to 9 (curiously they decided to use a C-style language at the same time they decided to move the architecture to Intel... ).

I use a standard LAMP stack at work (no longer working at KFC).

I'm finding that JavaScript is really powerful, especially now that I'm starting to understand the practicalities of closures (Look at the D example above; same thing). It is a hugely misunderstood language, and it doesn't help that most people using it have no programming background at all. I use JavaScript for a lot of demo type work.

EDIT: Oh, right... bbcode no more...

HTML & variables. But I'm not sure if HTML is a language.

Well I've been told that any scripting language can be a programming language and any programming language can be a scripting language, just takes a person making the interpreter and compiler for each language. With HTML I suppose it could be, but don't think it would be very powerful by itself and without a overhaul.

Let's see. I have sampled and sniffed quite a bunch of languages, but the ones that I still use seriously are:

• PHP for web programming, anything ranging from a quick-and-dirty single page script to a full-blown MVC or three-tier web application.

• Python also for web programming; the language is somewhat saner than PHP, definitely more consistent and has much less obscure edge cases; but for some reason, I don't quite like the flavor of it.

• Haskell for all sorts of programming; the language shines particularly when complex logic is involved (lazy evaluation and purity are excellent tools if you can play their strengths), as well as doing mathy things and, perhaps its strongest point, implementing parsers and domain-specific languages.

• Shell script (usually bash, zsh if I can be sure it's available) to glue various little tools together.

• Javascript for anything client-side - there's not much choice anyway, and with jQuery and the right functional-programming mindset, the language isn't that bad really.

• C# if I have to program for Windows (which is rare these days, but used to be my bread and butter).

Apart from that, the usual range of data, document and markup languages.

"Programming language" and "scripting language" are basically the same thing these days; the difference is more conceptual than anything. HTML is not a scripting language though: it is a document language, purely descriptive and without any means of expressing operations or algorithms. HTML could never be used for actual scripting or programming without changing its core semantics, which would turn it into something completely different.

I rarely if ever touch C/C++ nowadays (good riddance! At least to C++ ). Mostly ActionScript 3 (it's my job) and javascript. Also a bit of C#, Ruby and java for private projects.

So you just basically said what I said with more "keywords" than I did:

Though, the compilers and interpreters go through the code and find the calls to convert to machine language. So in theory you could write a compiler or interpreter that detected HTML tags and other things to make it execute them like a program. Not something you would want to do due to waste of time but still possible.

Been having some fun programming in NodeJS.

What you don't understand is that HTML describes the structure of a document. There's no actual program instructions in pure HTML (think of a computer program as a recipe, with a set of ingredients, processing steps, and result). You can use SGML or XML to write a program and some dialects might even exist, but that's not the same as HTML.

I make fun of myself, why would I care what someone else said about me? You could make an HTML Compiler that reads say "<H1>This is a string!</H1>" and the compiler has been told to interpret H1 as the instruction output string between <H1></H1> at <terminal font + 3 or something. HTML isn't instructions, but if you made a compiler you could (under the hood) tell it to interpret the tags as instructions. Variables? Name = "" where 'name' could be interpreted as a variable and the data in "" could be placed in memory. This is what I meant by anything can be turned into a programming language because if the person is bored enough and has the know how they could make a compiler that does most the work under the hood and turn a structure of documents into a programming language. (Does this prove I don't care how crazy people think I am (or stupid for that matter)?)

Just replace MS access with "case of the mondays".

Well, jobs I mention for C# and Java are all short term contract jobs (max 6 months), usually pay 40k for each contract and they don't spend time training folks obviously because its temporary. I'd say 85% of the jobs I see on craigslist aren't permanent.

The MS access/ VB jobs are mostly in the service industry which are longer term but the skills aquired from them isn't stellar. Its just customer/client shit.

Oh, I also use PHP. But only because I'm being paid fairly well for it.

If HTML was a programming language, we wouldn't need any javascript.

I used to write Z80 Assembler some 20 years ago. It was great fun. I thought of picking up that again. I could use it on my son's TI calculator, which probably will be useless now, when he finishes high school.

Indeed. I've been saying this for years now. Not only we wouldn't need Javascript, we wouldn't also need to wait for the WWW consortium to extend the standard, and we wouldn't have these big differences between how browsers render HTML, because the rendering would be the result of running the HTML program rather than its conversion to another internal form.

Of course then it wouldn't be HTML, nor a Markup Language. And then you'd have a hard time separating your presentation layer from your control logic.

You'd still have a document structure language, not a programming language; the expressivity would still be limited to describing a document structure. The fact that you have produced a program that can turn HTML into a native executable which, when run, displays a rendering of the original document, doesn't change that a bit, just like the fact that you can pre-compile sprites into machine instruction doesn't magically turn PNG into a programming language. You still won't be able to implement anything that requires a quasi-Turing-complete language in it without severely extending HTML or giving radically new meaning to its tags and attributes.

Dammers, the point of my remark was to show bamccaig I didn't care if people made fun of me so I made off the wall remarks about turning HTML into a programming language. Let me take it one step further. A Game Maker like app that takes each tag and has predefined things in it that turns each one into a game aspect, lists can be the menu, H# tags can correspond to menu items (1 is title, 2 is start item, 3 load, 4 options, 5 high score, 6 quit), title is app title bar name, marquee can be movement, etc. Crazy enough for you yet?

I don't think that's important, is it?

Not really. The same HTML documents we have now could work as programs, unaltered. Separating the presentation from the control logic is a matter of designing the API correctly, it has nothing to do with if the language is markup or programming.

Well, in the case HTML was a programming language, the tag 'H1' would be a function that it would render its sub-elements with a specific font. The H1 function itself would use code of a Turing-complete language. Something along this:

    function h1(list of elements) {
        Font font = get_font(points = 150);
        for(element : elements) {
            draw_element_with_font(element, font);
        }
    }

Let's see you persuade HTML to list the first ten Fibonacci numbers without listing them explicitly. Even BASIC can do that.

Sure it does. You just turned HTML into PHP by making it a programming language. and look what that did to the programming world.

You can do that in CSS (probably?). \o/

That doesn't prove anything. Of course you can implement a non-Turing-complete language in a Turing-complete language. Just because you can implement language A in language B doesn't mean that B being Turing complete makes A Turing-complete as well. The other way around, however, does hold: if A is Turing-complete, and can be implemented in B, then B is also Turing-complete.

HTML is quite obviously not Turing-complete; as long as you retain its meaning, writing an HTML interpreter, compiler, renderer or similar thing in a Turing-complete language doesn't make HTML Turing-complete.

Reinterpreting HTML, however, so that tags are symbols for operations, can make HTML Turing-complete. For example, the <em> tag could be interpreted as an assignment (the id attribute indicating the variable name and the content the value), <a> could mean addition (add the value you get from evaluating the tag content to the variable referred to by the tag's id); <div> could mean print; etc. With just a handful of definitions, Turing completeness can be achieved. But this new language, even though its source code would also be valid HTML, would not be HTML anymore - it would be some sort of imperative Turing-complete programming language with a syntax that coincidentally looks exactly like HTML.

Let's use C as an example to look at it from a different angle. I assume you are familiar with the International Obfuscated C Code Contest (http://ioccc.org/); many of the winning entries are not only valid C code, they also qualify as ASCII art. The source code is 'valid' as either: it compiles and does something (so it is valid C, source code in a Turing-complete language), but it can also be displayed in a text editor or on a terminal, and humans will be able to identify it as an image of something (so it is also image data, that is, static data in a purely presentational format without any chance of being Turing-complete). The source code is valid as both, but that doesn't make ASCII art a Turing-complete language, even though the ascii art in the ioccc entries happens to be valid C.

Going back to HTML / H# (lacking a better name for the hypothetical programming language), if you implemented H# such that all valid HTML documents were also valid H#, and vv., and H# would be Turing-complete, then HTML would still be non-Turing-complete, even though every valid HTML document would also happen to coincide with a valid program in a Turing-complete language. This is the same as if you were to design a C dialect that is extremely forgiving, treating all invalid syntax as comments (like the satirical programming language INTERCAL does). Let's call this hypothetical C dialect C/F (C Forgiving). Let's also broaden our definition of 'valid' ASCII art, such that everything you can view in a text editor would qualify - if in doubt, we'll assume it's some kind of abstract or experimental art. Given these two languages, we'd have the same situation as with HTML vs. H#: anything valid in one is also valid in the other, yet one of them is Turing-complete and the other not.

You failed to mention why turning HTML into a programming language is a bad thing.

Proving that HTML is Turing-complete was not the purpose of my comment. I just wanted to show that it would be viable to have a programming language instead of a markup language while retaining the markup language properties.

Should we turn jpeg into a programming language too?

I think you ignored his point. You didn't turn HTML into a programming language. You just implemented a new renderer for it.

I don't see why people are assuming that this hypothetical HTML "programming language" (or H#, as Tobias dubbed it) would render a document. That doesn't make sense. If it's a programming language then it's going to do whatever the program does! Prompt the user for a number, calculate a sum, print "Hello, World" on the standard output device. Whatever. That said, it would no longer be HTML, as Tobias said, it would be something that just happens to also be (different) HTML.

There are no requirements for interactivity on a jpeg image.

I did ignore his point, because what I discussed is not what he discussed. I agree with him, I didn't turn HTML into a programming language. That was not my purpose. What I wanted to show is that there could be a programming language, that its programs looks like markup, and still be a fully-fledged programming language.

Exactly. And one use of it would be to output a gui within a browser.

XSLT pretty much shows this already. If you load the right functions into the XSLT processor to hook into the host environment, you can do pretty much anything with it.

I was originally arguing about this statement:

The point being that HTML is neither a scripting language nor a programming language, and the fact that you can write a compiler that compiles HTML into machine code doesn't change a bit about the expressivity of the original language (that is, if it cannot be expressed in HTML, then the HTML-to-machine-code compiler cannot produce it either).

Except you didn't show that. And IMO a markup language and a programing language are mutually exclusive. And for good reason. Why in the love of god would you want to write a complex program in xml? It makes no sense. Simple template logic is different, but a full program? You'd have to be insane.

XQuery and friends are probably better suited for that. XSLT is a horrible horrible HORRIBLE thing.

XSLT is a tool for transforming XML, isn't it? I am talking about a programming language. Perhaps XSLT is Turing-complete, but I've read somewhere that's difficult and awkward to use as a general-purpose programming language.

Agreed.

Please reread my post carefully. I presented an example of how the tag H1 actually represented a function in a library that made the output present headers in big font style.

They are not mutually exclusive. A markup language has the advantage of easy parsing, and if it's a programming language, then the presentation can be specified in terms of the language itself. The big advantage is that the rendering will be the SAME in all browsers, and also maintaining the advantage for web designers.

You know, or you could use CSS. I really don't see the point in tying it to a library.

HTML already does what you show. It renders specific text and objects given various markup. Add in some CSS, and you get EVERYTHING you wanted. Why this pointless discussion?

Yes, you did. It doesn't show your point though. If the compiled code behaves like a user agent would if fed the original HTML, then you haven't changed the language itself a bit. You have merely implemented a way to produce a self-rendering machine-code representation of it.

It is a tool for transforming XML into other XML, or HTML, or arbitrary text, yes. And you are right, it is terribly verbose and uncomfortable. The interesting point, however, is that it is both a Turing-complete programming language AND a valid subset of XML. You can feed it to any XSLT-agnostic generic XML tool, and it will process it without problems (in fact, you can use XSLT to process XSLT source); but you can also run it as XSLT, in which case it is just another interpreted programming language. Taken to the extreme, any source code format would work, since they're all valid text files, but I picked XSLT because its XML-based source code is closely related to HTML.

The only reason I can think of would be when you have to deploy the HTML to a system that is both severely crippled (in terms of hardware resources) and lacks a useable HTML user agent. These days, I'd be hard pressed to find such an environment.

Perhaps some math savvy individual could manipulate a rendered HTML-file to solve geometrical problems, in the kind of fashion the ancient Greeks did

TeX is Turning complete, so is PostScript. I realise that neither of those is eactly what you were thinking of and I wouldn't try writing complicated programs in either of them, but it's still clear that the distinction is not necessarily as clear-cut as you might think if you're comparing HTML and PHP (say).

I wouldn't say either of those are pure markup

When you can use PostScript to infect your printer with a virus/trojan, its not really just markup

It seems my point was completely missed. So, here it is again, this time with examples:

Right now, the situation is like this:

In other words, each browser has its own rendering engine, making pages render differently on each browser.

Not only that, but extending the markup with new tags takes a huge amount of time.

The problem could be eliminated, if the actual rendering code was part of the code of the page itself. Then, every browser would run this:

//this code is in the page itself, it's not in the browser.
void render_H1(Context &context) {
    ...
}

The function 'render_H1' would be called by the browser when the tag 'h1' was found during parsing.

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.

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

Why? please elaborate.

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. 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.

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).

HTML/CSS/JavaScript work entirely client-side. You don't need a Web server at all... 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.

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

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

What do you mean?

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

These capabilities can be built into the rendering module.

Personally, I don't see why.

Why? please elaborate. I find it perfectly sensible.

That's exactly the problem solved by my concept.

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.

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.

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.

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.

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.

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.

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

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.

And that's what's wrong with it.

In the browser.

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.

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

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

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

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

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.

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

Nothing that it could not be built into a library.

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.

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.

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".

A proper tech design would also do.

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"}

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]

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

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?

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.

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.

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. Just gives people a bad impression.

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

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.

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.

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.

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.

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

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.

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.

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.

It does not.

Append:

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

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

Just got an email from a guy I know in CS department of IU. Made me laugh with his list he told me to learn to be viable. Told me to learn Assembler, ADA, Pascal, Java, C, C++, C#, PHP, MySQL, Javascript, CSS, XML, HTML, ASP.NET, Perl, Python, and LUA. Then told me that would also give me plenty of understanding to use D if I wanted. He is always teasing me about learning a ridiculous amount of languages (at one point I think he told me to learn like 40 or so languages. I just tell him "I don't know where to get half the tools for those languages " and wait for his next list of languages. He has done this for years now, ever since we met (he worked at Gamestop in the mall). Thought he had grown tired of it because I hadn't received anything for a few months and he just started up again.

I just sit around reading here lately. Right now I have grown bored with the net and today I picked up and started reading C++ Primer. I've had it for years now and not even opened it. Just something for me to do when I'm sitting here while son is at school and I have my chores done.

Honestly, a programming language is a programming language. If you know one it's not hard to pick up another. From that list, I've used x86 assembly ("assembler" isn't really a programming language), Pascal, C, C++, PHP, Javascript, Perl and Python. HTML and CSS are not programming languages, but I've used both. In addition I use FORTRAN regularly and I've done Bash shell scripting in the past. I've also done some programming with Maple. Oh, and I started out with BASIC (GW-BASIC, then QuickBASIC, played with but didn't like VisualBASIC).

Bottom line: listing a dozen programming languages that you "know" may look impressive, but it's meaningless. What you need to do is learn one well enough that you can use it comfortably, after that you can quickly and easily pick up another one if you have to. You will not be an expert immediately, but you can use it and will learn about the peculiarities quickly enough. A third language will come even easier. If you try to learn too many similar languages at the same time everything will just be confusing.

What you really want to learn and implement is algorithms and design patterns. You'll just have to learn the programming language as a means to an end, don't focus on the learning the language itself.

Don't pick a language feature and then find a problem to solve with it. Pick a problem and then find the tools needed to solve it.

I only learned Lua because I had a specific problem. I needed scripting and I'd heard good things about Lua so I went there.
Later I thought it was a big bother having to switch between Lua and C++ and I made Allua so I could do everything using only Lua. I learned a lot about Lua doing this, I wouldn't have found the motivation to learn Lua without having a problem motivating me in the first place.

I also learned some Python because I needed to export a Blender model in a format that made sense to me. But since then I haven't had any problems that led me to use Python for anything else, so I didn't learn much of that language.

Don't listen to that guy. I know people who are programmers at Walmart??? Its like who are they kidding and what do they really use it for in the real world. Then again if that guy could show you a demo with all those languages that does blow your socks off then maybe you should listen to him but otherwise its the case of the blind leading the blind, go deaf on him and tell him to learn every math book from calculus to topology and see where that gets him.

For my strategy project i use LUA, based on the Blitzkrieg dialect mixed with Sudden Strike commands i create my own. The complete c Allegro program is controlled by LUA scripts.

No. the rendering library would be imported via an import statement.

It creates a gui.

I wanted to stress the fact that a programming language source can also serve as markup.

It creates a set of widgets, and then runs an event loop on those widgets.

Exactly. The rendering library is hardcoded, in respect to the code running with it.

That's exactly what I intended to do: I wanted to show that programs can be equally short, like markup.

The extra information is hidden in the instantiated objects, which contain the gui code. For example, a Label class, an Input class, etc.

Exactly. The rendering would be the task of the imported library.

No, the rendering library would take the differences into account.

I think you are stuck in a specific mindset, and that's why you cannot understand what I am saying.

It's very easy actually: instead of rendering the page with an external library, render the page with the same programming language the page is written into. Like, for example, downloading a Java Swing source and running it.

He was the manager of Gamestop several years ago, which is how I met him because of getting games there. They closed it the start of this year though so I have to go to EB now instead (don't know why they had two stores in the same mall that were owned by one company). He is now one of the heads in the CS department at IU.

Second, same can be said about every one here. A person can come across as knowledgeable and not know much at all (like me). Also, having a mind blowing demo again doesn't show their ability (I made pong 3 times but the code was basically handed to me all 3 times, but every time I attempt it without help I hit the same snag, collision detection).

I enjoy reading tech books, but I've come to accept that I'll never be a programmer because I just don't get something about it.

From where? You said earlier the rendering library would ship with the browser:

So what forbids Microsoft (or any other company) to use their own (possibly non-standard compliant) library?

So it's not just a render library, it handles all user interaction as well. And how will the library look and feel appropriately for the OS (feel like a native app)?

Have you though about the security problems that involves? I have Java disabled in all browsers for a reason .

I think I agree with Bam in one thing: you're not capable of explaining your idea. Reading all your answers I see contradictions in it, not making much sense in what exactly are you proposing.

Yeah, he never said programming languages in his emails. He stays general and just says languages.

I was always told in college that Assembler was the language and x86 x64 and such was the instruction set used. Which made sense to me at the time because most tech positions I looked at requirements said assembler experience was a good thing.

Never have a problem that I need to solve, which is why I normally just pound out rehashed programs all the time.

I agree.

I have to admit axilmar's idea is tempting. More strict CSS/HTML regulations would do the same thing, I guess (and suffer from the same weaknesses).
I have used Javascript and PHP, but I'm completely out of it. I like C(++) because it's so damn straight-forward, and C++ has the don't-pay-for-what-you-don't-use attitude. You hardly ever have to worry about obscure things happening at runtime.
Javascript is nice, because it has direct access to a text and image 'canvas'. PHP is nice because you can slowly inject it into pages, making them gradually more dynamic.

The stupid things I'm doing when I find something new that I wasn't taught in my college course for C++.

When you write code in assembly, you write code targeting specific hardware, using mnemonics and operands specific to that hardware. That's what I meant when I said it's not really a programming language: despite the name x86 assembly language has very little to do with, say, PowerPC assembly language (or perhaps more relevant: ARM assembly language).

It's still worthwhile to know, because it helps you understand what the machine is doing and how it's doing it (and you can look at the assembly translation from the compiler if you ever need to figure out what exactly the compiler is doing to your code), but the details are only relevant to particular architectures.

We briefly touched assembly. We used Emu8086 but I remember almost nothing that I learned.

I played around with z80 assembly. Never made anything useful, besides a program to reset the high score list on zTetris.

Some times I think about trying to relearn assembly.

First assembly I learnt was some custom assembly for a virtual machine I started writing for an old-old-old speedhack. Worked reasonably well.

Second assembly I learnt was PIC18 assembly. Annoying as fuck, but can be fun. Trying to do anything on an 8 bit micro with 2k memory or less is incredibly painful. Especially when its something complex like BCM (Binary Coded Modulation) or Software PWM (Pulse Width Modulation) on 8-64 separate ports at once. The code in C is somewhat ok, but sane code would want to branch and loop. A LOT. And a lot of branching and looping in assembler is quite hard to follow. Especially since I have a hard time with following more complex setups (like complex conditionals and loops in assembler).

A friend of mine did his without a lot of branching or looping. A lot of his code was automatically generated using macros. Bloated the final code up a lot, but it was easier to follow at least at the upper layer. Trying to actually follow his fancy math was something else.

Ironically my entire programming "career" started with assembler. It began around 1999 when I wanted to get into programming graphics. My friend insisted I would use C++ and he used BASIC to show me a simple demo of a sine wave changing colors as a random function. Then someone at a used software computer store explained to me about assembler and I was immediately amazed by it. Later this other guy (who worked with me) gave me a copy of Jeff Duntemanns assembly language step by step 1st edition (where he also mentions the use of assembly language as an in between for programmers but not the end all and getting to use it for low level parts of coding are horrendously difficult).

The point I'm trying to make is that programming with assembler is possible to learn from but one of the things I realized more recently is that the richness of a modern programming language is just not there with assembler. And I'm thinking of python or C++. All the time spent dealing with low level architecture is just not as important to the actual code and C++ hides those parts. I'm not saying that assembler is useless because I have seen some optimizations on the X86 that work and those are simd instructions, but to deal with that level of coding at a non-expert level is too painful and should be left to people who have already learned all the basics and even the advanced parts of assembler.

Or like, for example, an Android or iOS app? Because that's what you get when you go the other way. And there's your security problem - the number of sploits published for Android is hilarious (considering the amount of money that went into the project, the rock-solid kernel it is based on, and the experience found in the company that backs it), and the only reason iOS scores any better is that the platform is ridiculously closed. Oh, and did I mention that Java, in the role you describe, has failed utterly? People write traditional desktop applications in it, and web applications, and custom information systems, but I haven't seen a distributed end-user Java application in a decade, if ever.

No, I said it will be stored in the browser, not shipped with the browser. The library will be downloaded at the first time and any time it is updated, and then cached locally somewhere in the filesystem controlled by the browser.

Today, html controls do not look like anything like native controls, do they?

Please, do tell me the security problems that involves.

Ok, here is a simple explanation: instead of downloading a document, clients download a program.

How about sandboxing? that would work, wouldn't it?

I am well aware about the reasons Java failed, and so my proposal is anything but Java. I am not proposing to do something radically different, just to replace the document with a program. Programs will still be downloaded as pages, have links in them, etc. It's just that what the code of the page will do will be defined by the program and the included libraries, not by the browser.

Android and Chrome both have a pretty solid Sandbox. Chrome was unbeaten till recently, but this last pwn2own thing (or whatever it was called) there was three major exploits.

It wasn't so solid after all, was it? :-)

Of course they do. Even on Opera, which is a browser that has always used its own controls have now a native look and feel since a few versions ago. The text box where I'm typing this is 100% native.

Well, one easy to think about, and that can't be solved with sandboxing, since it's not something you can sandbox in this scenario: since the program is responsible for rendering, it'll need full access to the GPU, for performance reasons. Anyone could for example write a program that uses all your GPU power for computing (bitcoin mining for example).

Javascript, which is a quite limited (limited in the sense of access to the hardware) language has security problems, imagine a language like yours that need to expose much more.

Edit:
What you describe actually reminds me of ActiveX

So there is no problem to use native controls, is it?

Modern O/Ses do not provide direct and full access to the GPU; everything goes through a driver. Drivers can easily be sandboxed.

Everything can be sandboxed.

I am not talking about downloading executable components.

Of course through a driver or API . That doesn't change anything. Being sandboxed doesn't solve the problem I described either. Are you being picky on purpose to avoid answering certain questions? (I've seen you do this to several ones, not just this).

I asked how would you do it, but instead of answering that, you told native controls are not used. Now you say native controls are not a problem. Make up you mind! (and answer the question)

Also:

Actually, no, the first time you said the library would be in the browser. You didn't say anything about being downloaded from somewhere. My question is, where's this somewhere? If I understand you correctly, web pages will include a line similar to import url_to_render_library. What happens if, after some time and a lot of webpages use it, that library goes off-line (forever)? Half the internet stops working? Not a good idea having to rely on a centralized thing.

This seems relevant:

Previous years it didn't have any. Where as IE and Mozilla did. Every year. Chrome just happens to have the best one. And it gets tighter every year. It helps that both that event and google itself are giving out a lot of money to try and attract people that can find holes in even the most stable stuff. Google itself has put in 1 million dollars (total) this year to give out to people finding security bugs in Chrome.

I'm going back and relearning assembly. Using Emu8086 to do it (seeing as I bought the license during my college time). Like I forgot that the registers were AX, BX, CX, DX, AH, AL, BL, BH, CH, CL, DH, DL, DI, SI, BP, SP and SReg are DS, ES, SS, AND CS(as second operand only). Well back to learning.

[REVISION]
I need to learn to set it up in Ubuntu so I can do assembly there instead of being in Vista for it.

[REVISION 2]
Wine, amazingly runs Emu8086 just fine under Ubuntu.

Not to say you shouldn't fo that if you're doing it for fun, but the question is: why?

By all means learn the principles, but don't get hung up on the details. Modern CPUs are very different from the old 16-bit 8086.

My answer to 'why' will never be good enough for anyone's expected why. When I learned C++ I was told "Don't bother. Learn Perl, Java, C#, C, everything but C++". Same for any other language, when I started messing with Perl I was told to learn Python, started with Python was told to learn Ruby, started with Ruby was told to learn Haskell.

Though your previous post and this one seems contradicting.

That is exactly why I quit asking questions because every answer I got was to learn a language to let me see how other languages do it, then get asked why I was wasting my time learning it. I still program in C++ and even have took up reading a book written by Josee Lajoie (who at the time of the print was the chair of the core language working group for ANSI/ISO C++ Standard Committee). I've come to realize that almost all books and tutorials on C++ are a waste as they only scratch the surface of what the language has or even can do. That is why I also have ordered the C++ The Programming Language Special Edition today. Figured his book would be even more beneficial than some book wrote by a guy looking to make a buck off the popularity of C++.

You said: "Anyone could for example write a program that uses all your GPU power for computing (bitcoin mining for example)".

How is that a problem? since programs are being downloaded, one could download a program which uses all the available CPU power too. So, it is not a security problem. Even now, a Javascript program can have an infinite loop in it. I do not see how it is a security problem, if right now it is not a security problem for the current technology.

Not at all. You will get all your answers, do not worry. Please don't fall into the "axilmar avoids answering certain questions" trap, which has been laid primarily by the owner of allegro.cc because he regularly had his arguments beaten by me.

I am using Firefox on a daily basis, and I see native and non-native controls all the time. I am not avoiding the question, I wanted you to see that the problem is already solved. But since you asked, here is the answer: through the proper abstraction of the underlying GUI system, which will be an API the downloaded programs can call to interact with native controls. Actually, the abstraction layer between the O/S and the downloaded program will cover not only GUI, but anything else necessary for writing interesting applications.

Nope. I said "stored in the browser". The question was "where would the library be stored?", and my reply was "in the browser". Putting the two together, it says "stored in the browser", which is totally irrelevant to being shipped with the browser.

You do understand me correctly. See? It's not that I cannot explain my ideas! :-)

The library would already be cached locally by the browser. A solution for this problem would be to have browsers ship with a standard library, which will be chosen in case the computer is offline and the imported library is not cached locally. The imported library would have priority over the one shipped with the browser, i.e. if the imported library is cached locally, it would be the one to be used.

Furthermore, there would certainly be different implementations, so, unless they all go offline simultaneously, there wouldn't be a problem. URLs can be redirected at DNS level.

A disclaimer about security: I am not implying I have all the security problems solved by what I am saying in these pages. These ideas rely on evolutions, which come from discussions by many people. My opinion is that a security "system" must be "invented" that covers all the possible security breaches, so as that we should be free to develop interesting applications and not worry about security. Perhaps it's not possible to do so, but thinking about it does no harm.

axilmar, I still fail to see any difference between your proposal versus what we currently have. Probably because I still fail to understand what your proposal even is, aside from replacing markup languages and stylesheets with programming instructions. Basically the same idea I had 4 or 5 years ago because I didn't want to learn how to use markup languages and stylesheets. Your pseudo-code was basically HTML, and amazingly did exactly what the HTML does.

Though I guess stylesheets raise an interesting question. The current Web is easily styleable, not only by Web authors, targeting specific devices (i.e., multiple stylesheets depending on the context of use); but also by end users within the user agent that want to change things around. A properly structured HTML document is easy to style differently, and in fact you can change the look of the entire Web page without touching a bit of markup or code if you're good enough. There's also the argument for MVC, or similar concepts, where the "view" or UI is separated from the logic and data. Are you familiar with MVC concepts? Do you disagree with them?

It's not important. What is important is that you have a reason to do what you do, that you've thought about what you're doing and know why you're doing it.

But that's not what I meant: why are you using an emulator to learn about assembly language for an obsolete architecture?

There are good and valid reasons for doing that, but be sure that your reason is one of those. If you want to learn something that you can directly use to program in assembly language on modern hardware on a modern operating system then this is the wrong way to go.

Largely irrelevant. Those languages are all very similar and it doesn't matter much which one you pick up first. Though I wouldn't start with C++ myself, that may just be because I didn't.

So the question is: why are you trying to learn a particular language? I picked up Perl not for the heck of it, but because I wanted to post-process lots of data stored in text files and was getting sick of using a mix of bash shell scripting, sed and awk. Let alone writing custom C (or FORTRAN) programs to do it. Perl is a much better tool for that job.

Python is a more modern language that could do the same thing, and I did try both Perl and Python and found that I prefer Perl (in fact, I tried Python first). I'm sure I could have done it in Ruby if I wanted to, but it doesn't have the userbase and community that Perl and Python do.

Bottom line: it comes down to why are you learning a particular language? It doesn't matter so much which one you pick, but make sure you know why.

Are you sure you understood the questions?

Never heard of him. Doesn't matter who he is either, since the position he holds doesn't say anything about his ability to write a good book about a language (but it looks good in the blurb on the back cover).

You should ask yourself why they do this.

Ultimately you learn a programming language by using it, and you learn more as you go along. You do not learn to use C++ by using about all the different ways in which it can do the same thing in a book.

Why?

The languages I use most are C, FORTRAN and Perl. I own one book on Perl, the introductory one (the "llama"), if I have use of a more advanced feature I use google or perldoc. I own one book on FORTRAN that I only ever open to remind myself of the edit descriptors. I have two books on C, but I hardly ever use either of them. I have them mainly because I like having a hardcopy reference if I ever need it. Again, you do not learn a programming language by reading about it in a book.

So once again, by all means do what you want to do, but make sure you have a sense of why you're doing it.

Fortran is ugly, what do you need it for?

Work, what else? A significant fraction of academic production software is written in FORTRAN.

FORTRAN 90 isn't that bad. Ofcourse a lot of code you find is written in FORTRAN 77 with coding conventions that date back to the 70s...

Instead of downloading data like this:

<html>
hello world
</html>

Clients will download, compile and run data like this:

import foo.bar;

int main() {
    print("hello world");
}

I don't think I can make it any clearer for you: instead of documents, clients will download programs.

All the desktop applications I've coded the last few years are based on the MVC model.

Let's call it Coffee!

But those registers are the same for 8,16,32, and even 64 bits (the only difference is the operator name with an e for 32 bit and r for 64, 16 bits are broken into low and high for all the data registers). Only the simd instructions are different. And AT&T is backwards.

Is there anything that you do with that that could be useful for entertainment purposes?

What?!!??! You can use any register for a data pointer, you can multiply immediates and any register, you can use (simple) multiplication within an offset expression, you can push/pop all the registers at once, I'll stop now.

It's not what you're used to. I'm not used to it either, but "move <this> (to) that" is just as logical as "let (this) equal (that)".

I use GCC inline assembler a lot now (that is at&t right?). It was headspinning at first but the worst part of it is understanding the clobber list and remember things like this:

%%EAX ;register
$1 ;value

it makes masm look beautiful.

The clobber list is to tell GCC which registers you're "clobbering", it's not strictly assembler at all. MASM simply saves everything (or lets your code crash) instead of trying to be efficient about it.

Well you can't put return values on the stack with gcc inline assembler so thats the reason I could imagine having one (clobber list), but with straight assembler you're supposed to push all the affected registers on the stack and pop them back after the operation is done (not like you didn't know that).

But you don't know if a particular register needs to be saved or not, so you're possibly wasting cycles etc. The clobber list says "I need this, this and that, do whatever optimizations you can while honoring this".

Only if you use the volatile keyword. I'm not sure how gcc compiles inline assembler without it and your assembly code might become more complex if the compiler is an idiot.

Basically your code without volatile might not even resemble what you coded.

{"name":"Q5MlQ.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/b\/0bcc3605e17e942320de8f6c0592c726.gif","w":320,"h":233,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/b\/0bcc3605e17e942320de8f6c0592c726"}

I love how the guy stands there and stares at it until it goes off .

Flat memory model.
Protected mode vs. real mode.
Extra registers.
Different number of cycles used for instructions.
Pairing of instructions for concurrent execution.
Not to mention, simd instructions are rather relevant to programming on modern hardware.

Sure, some of those you don't necessarily need to know immediately, but it still means you'll need to watch out for picking up bad habits.

Not that I know of. I don't work on entertainment.

What you haven't made clear yet is what you consider the difference.
Let's recap what you propose:

• the client makes a request to the server

• the server responds with program source code

• the client runs the source code through a compiler and executes the result in a sandbox

Now let's see what we currently have:

• the client makes a request to the server

• the server responds with HTML, CSS, image data, or Javascript

• the client does whatever it takes to display and/or execute what the server sent; usually, this means compiling HTML into a DOM tree, compiling Javascript into something executable, and then running the compiled Javascript in a sandbox to manipulate the DOM tree.

The web application in question can be implemented so that everything is done in Javascript except one line (<script type="text/javascript" src="the_program.js"></script>); if you do that, you end up with:

• the client makes a request to the server

• the server responds with a stub HTML document, which causes the following steps

• the client makes a request to the server

• the server responds with program source code

• the client runs the source code through a compiler and executes the result in a sandbox

However, the current web stack is much more flexible than that: instead of doing everything in one programming language, things like document structure, layout, images, fonts, etc., can be expressed in more suitable formats.

So what exactly are you complaining about? How is your approach anything but a limited subset of what we already have? The only real difference I can spot is the syntax, but you have stated yourself that the syntax details are irrelevant. Everything else is already there. You can render your own controls in Javascript (either by generating CSS on the fly, or by using canvas, svg, or webgl); you can even do your own font rendering if you have masochist tendencies; you can include libraries; you can get limited access to the underlying OS and filesystem (at least since HTML5); you can make HTTP requests back to the server; honestly, what else do you want except a different syntax?

The difference is that the browser will provide a much lower level API to the downloaded program, allowing much more versatility and expandability that the current model.

More flexible? it's not more flexible. Try to make the world accept a new tag, and it would be years before it is adopted.

What we have now is a lot less flexible than what we could have.

A programming language can support those more suitable formats by providing the appropriate literal forms.

I already told you: a) incompatibilities between browsers, and b) the slow development of the standards.

What I propose is a subset of what we currently have, but it's a more powerful one, allowing more and better abstractions to be built. Those abstractions are not possible with the current model.

Not all browsers support those things though. And there it goes: the incompatibilities between browsers mean a lot of extra work to make your web application available to the masses.

Exactly. With my idea, one could do his own font rendering without being masochist.

You can, but with hacks. The javascript import statement imports names, properties, objects and functions of another script, but javascript does not have a module loading system.

I want a proper API for my downloaded application. As it is right now, js programs cannot even write to a file without using custom browsers extensions.

With canvas + JavaScript you can do anything you want within the sandbox that the browser provides. You can complain about what that sandbox provides, but your solution is the same thing... just using slightly different tools.

(And, by the way, compiling source code can lead to incompatibilities ... look at gcc vs Visual C++. You're just trading one set of problems for a similar set.)

Of course, I would agree with you in that JavaScript has some fundamental flaws (e.g., lack of modularity), but I don't see how anything you are suggesting is a major upgrade from what we already have.

For fucking good reason. When I visit your Web site it better not affect my computer in any fucking way.

Beyond that, what if the device has no file system? How do you write an application with super privileges without any idea of what platform you are targeting?

With source code (that is to be compiled), you have a messy set of conditional #ifdef blocks and you generally only target a few platforms like OS X 10.6+ or Windows.

The current HTML5 sandbox already solves these problems. Regarding files, you can save to local key/value storage, local databases, and config (cookies). Of course you cannot specify a specific path, but that concept is not portable.

So you end up needing to build a sandbox for your new language that does the same thing, and...

... you still end up with those two problems. Not every sandbox will be the same (some people will enhance theirs, or leave features out), and new APIs will be slow to be developed.

Wow, that debate has gone on longer than I thought it would. Figured he would have gave up on his point by now about it being a programming language. I know it isn't a programming language (otherwise it would be HTPL instead of HTML), but never knew someone would actually argue making something fairly simple and completely useless in programming into a programming language .

But you can write to file. I think it's called cookies...

I much rather have the website store everything serverside though, until I actively choose to download it.

The only information from a website that should be stored on my computer automatically should be a session id. And even that should be deleted when I close the browser.

Really, why should cookies even need to exist? I think the browser could just store session ids in memory instead.

• They allow you to store site specific settings without a user account or login.

• They allow logins to persist for unlimited amounts of time, across reboots and shutdowns.

Session cookies aren't saved to disk.

Most browsers have this option. Enjoy logging in 200 times per day!

I only restart my browser when it breaks down too badly. So I'd only have to log in like once a week or thereabouts.

I searched Firefox and couldn't find any option to only allow storage of session cookie.

network.cookie.lifetimePolicy=2

I use the CookieSafe to control the lifetimes of my cookies (websites that I trust can place long term cookies... everbody else either gets no cookies at all, or those that get deleted at the end of a session).

I set the firefox to store the cookies until I close firefox and clear everything when I exit firefox. I would like to type login information everytime.

These days I find myself using only C#, G-code and RAPID. And the occasional Visual Basic.

I have messed with tons of languages over the years (some programming, some scripting, and some web dev). C, C++, C#, Java, Python, Perl, Ruby, Visual Basic, PHP, HTML, CSS, Javascript, BASIC, Assembly, Haskell, Erlang, J#(think that was it), Scheme, Common Lisp, ASP.NET, D, and God knows what else I've played with in the past that I may have forgot.

[REVISION]
Bored and playing with XML and CSS right now. http://twitpic.com/8y3t1y (added)

Canvas + Javascript is a very inefficient solution. That's why someone earlier said that doing your own font rendering engine is for masochists.

No, my solution is not the same thing at all, because the API the browser would provide would be more lower-level than what it currently has. And a more lower level API would open for more possibilities.

Not if the language is well-defined.

That's what the sandbox is for. The web page you download already affects your computer anyway.

There are no devices that I know of that have no filesystem. Care to show us one?

Why should you need to write a web application with super privileges? that's not part of the discussion we are having anyway.

That concerns C and C++. If you make the downloaded code in C or C++, then you deserve to get that.

But there are other possibilities out there. Even (*gasp*) new programming languages.

My proposal did not introduce those problems anyway.

If you are talking about web storage, that's very limited and inefficient (due to storing strings only), and not yet a standard.

Nope. Not part of the web specification, as far as I know.

>, and config (cookies).

Terrible solution.

A better sandbox that opens new capabilities.

Not if the browser API contains better primitives than it currently supports.

It's not the same to provide, let's say, a text box, and the means to implement said text box. The former is fixed functionality, the latter is not. There is a great difference.

VMWare recently announced a real time remote desktop over HTML5 with canvas. WebGL gives you 3D support.

Semantics. When there is a paper that standardizes something and all the major players adapt it, I consider it a feature. On the contrary, you can publish your superior work as a final standard, but nobody will implement it. De facto standards are all that ever have mattered on the web.

I don't really care to reply point-by-point. I'll just leave it as I agree that the current web technologies are sloppy, but I don't think anything you are suggesting is at best anything but minor, incremental improvements.

We will see how it goes, and which browsers run it in good speed.

That's valid if all players adopt it. Otherwise, one has to account for the players that have not adopted it yet.

By all means, let's hear your suggestions.

If you're talking about practical suggestions given the current state of things, then I don't really think there are many.

The main problem has always been getting companies (Microsoft, Google, Apple, etc) to work together to implement the same things at the same time, and to get end users to stay up-to-date. Java was well defined (and similar to what you are describing), yet that didn't stop Microsoft from doing its own thing.

Anyone notice how the op of this thread has not once chimed in...

Well the OP did say:

Guess it didn't apply to him as he never answered.

Maybe deathwish is up to his old ways again.

What? Huh? Who? Maybe Chris just wanted to get everyone's take on other languages to give him an idea on what to do next? Just guessing though. Could just be he made a 'what the hell' thread in that he did it just to get forum activity up more?

I've been addicted to Lua for the past 9 months or so.

LuaJIT's ffi bindings and native C callbacks is what really sold it for me. Not to mention that LuaJIT is blazing fast. The argument of "Use Lua, but write performance critical code in C/C++" holds a lot less water these days.

I've looked into LUA and Python but never messed with C++/LUA or C++/Python together.

That's the beauty of the ffi bindings. You don't have to write bindings. LuaJIT can call functions directly from a library. All you need to do is let Lua know which library you want to use, and what the function signature is.

local some_defs = "unsigned int My_Long_Ass_C_Function_That_Does_everything( int are_you_awesome );"

ffi.cdef( some_defs )

local my_library = ffi.load( "my_library.dll" or "my_library.so", etc )

print( my_library.My_Long_Ass_C_Function_That_Does_everything( true ) )

Any library out there that's written in C is instantly usable, so long as you provide the header file (i.e., function signatures) to Lua. Imagine the possibilities!

Can't even remember if I have LUA installed in Ubuntu. I know I have a butt load of languages installed on my Vista box, but lately I only boot to it for games. I stay under Ubuntu for coding (whatever I get bored and decide to kick out).

[REVISION]
Waiting for my book to come. Was supposed to be here today, but think it will be here tomorrow.

It's not LUA. It's Lua. It's not PERL. It's Perl.

It honestly doesn't matter. I can type them a lua/LUA/LuA/lUa or Perl/PERL/PeRl/pErL/pERl and anyone that knows what I'm talking about will know what they are. I can type Lua and you will still find someone that thinks you are talking about (Limited User Account or some other acronym). I've read what they said on the LUA site and still don't care. I type them both ways LUA and Lua as well as PERL and Perl and even RUBY and Ruby. I'd be really worried if someone thought I mean Limited User Account in a programming language discussion.

Psst! Aren't you allegedly ignoring me?

Yeah man, like, I can type IDIOT, iDIot or idiOT and everyone knows I mean Specter.

Don't know, could be hiding that you mean yourself since you keep trying to get a rise out of me and failing. All I can do is laugh at your failed attempts. You mean squat to me so your attempts mean even less. Now if Tomasu, bamccaig, Sevalecan, or Elias had your attitude it might have worked, though that is doubtful too. You see, even though I know they are fed up with me, I could never get mad at them as I consider them friends on here despite what they could say (and have said) about me. There are others on here I consider friends too, 23yrold3yrold, DHarmon, and of course ML.

My whining and complaining is annoying, but harmless (as I'm sure Matthew knows). Yet you are sitting there trying to start a flame war (which is against Matthew's policy) after I had told you that bamccaig made an ignore script and ML has an ignore feature on the forums, which you obviously have opted out of as you have posted remarks trying to (pardon the pun) egg me on in two or three threads now. My complaining may be annoying, but it is completely harmless to anyone on the forums (I'm only hurting myself with it).

You're right.

And you're an idiot.

Don't worry Specter:

Careful, I'm sure your IQ is dropping with every post you make toward me. It will start effecting your music for the worse.

I don't think that is possible.

Hah!

Don't get too cocky. That line is normally used to imply it isn't possible because it is already terrible to begin with.

...and there was me thinking it was a...compliment...err, earth to idiot?

Either way, not much of a compliment. If you were good then it would be possible to get worse therefore if it is a compliment then you aren't good enough to get worse.

/me grabs popcorn only to find it's bland and tasteless... <sigh>

Salt and butter, or caramel (depending on your preference) . Saying that made me remember when I went to watch X-Men in theaters, a guy four seats from me pulled out a chocolate syrup bottle and poured it on the movie theater's salted and buttered popcorn .

Looks like this one feature suddenly turns Lua into an actual programming language in one gentle swoop... nice.

You should seriously consider purchasing an industrial-strength sarcasm detector.

Yes you can, and people will know what you're talking about, but you'll look like an idiot. Getting the spelling of a programming language wrong in such obvious ways means you don't care much about details, which means you're probably not going to be a good programmer until you change this, which in turn means you are not worthy of a true hacker's time, which in turn means you will receive less help from any community (even a.cc). Also, each spelling mistake causes a slight disruption to the reader, more noticable the faster you scan a piece of text. More disruptions means more annoyance, and again, a lower chance of you getting help from said reader.

The language is called Lua, and it is named after the Portuguese word for "moon", which you can read on the project's website (http://www.lua.org/about.html). Specifically:

In the case of Perl, it matters even more: the terms "Perl" and "perl" are used to distinguish the programming language, Perl, from its compiler / interpreter, perl.

Aaaaaaaanyway, let's get this thread back off the rails please.

Cue 100 posts of people arguing that they don't think it's a problem and whoever does find that it causes text to be harder to read is either lying, doesn't put in enough effort or is just a pedantic arsehole.

At least that's what happened the last time that point was raised.

So... no Ruby?

Nope, won't make a difference. I replied knowing it was sarcasm. It being sarcastic makes no difference to me, I always reply to it and put my two cents in.

As opposed to what I look like now?

So all the programmers that call C++ Cpp don't care for details? I've met some programmers that capitalize ever language name for emphasis to make it stand out in text (LUA/ASSEMBLY/C++/C/JAVA/etc) so according to your assessment, they don't care for detail. I pay attention to detail, just don't care one way or the other how I type the language name, sometimes I may do LUA and others I may do lua or even do it like the site says to do it and type Lua, but they all mean the same to me.

If I cared what anyone thought of me, I would never have admitted I was part of A.cc or used allegro. Cplusplus.com, cprogramming.com, gamedev.net, and jharbour.com (just to name a few sites) all have said basically the same thing. Here is a quote from GD.net:

I disagree with that point of view, which is why I am still around. If I had agreed with it I would have moved on to one of the other libraries that existed back in 2001 or 2002. God, I could fill up several pages with Harbour's dislike and opinion for Allegro. Only thing I ever voiced about Allegro is that I wish it had built in networking like the newer libraries out there.

Thta's a different scenario from getting it wrong due to lack of care to detail. If you're deliberately doing it wrong for emphasis, than you're a twat.

No I just don't care as I consider them the same no matter the where the capitalization is. Not caring for detail is a person who, does all left aligned source code and when asked just gives the answer of "Because". Speaking of care for detail the start of the line should be "That's". If I didn't care for detail I would never bother posting more than one word responses to every topic. I could stop caring for detail and just start replying to every thread with "Damn!" off and on every few posts and nothing else.

I know what not caring for detail is. I was saying that deliberately doing something for emphasis and doing something wrong because you don't know/don't care are two different things. I wasn't talking about you, but rather about the "some programmers" you were referring to.

I was just messing with you on that one. Everyone is entitled to their view on things and entitled to type how they want. I prefer using caps on names and don't care. As I also don't care who likes it. Though I have also typed them in the proper spelling too. Just depends on what my hands do at the time (just like your hands spelled That's earlier as Thta's). I seldom proof read my posts, but I seldom worry too much about grammar as long as I get my point across.

Everyone knows my music is amazing:

I know, but it was the only thing I knew about you to remark on. I remember I told you I liked several of yours (the Robocop one was one that I think I first heard before listening to your others). Still don't think I've listened to them all yet.