we have a Web-based Windows PowerShell Console to do windowsy things.. that's more powerful in my opinion!

(plus we've had people emulate consoles in plugins (flash/Silverlight) before ..

.. anyway good stuff for Cloud9 BUT nothing new!

this is a collection of elements generated by a JITted scripting language on a load-balanced server which generates HTML and Javascript and pushes it over the Interwebs to a client which JITts the javascript to try and recover some of the speed lost by using a retarded language like javascript and using hardware acceleration in CSSv3 because GDI is slow, all using optimised AJAX/JSON in order to try and keep latency down between the server and the client over keep-alive HTTP in order to avoid the cost of restarting TCP connections...

... in order to render a console program that was invented in the 1980s?

FFS. Developers are stupid. Shouldn't we have swishy minority-report style GUIs now? Why do people still want vi? Have we really been running so fast just to keep still?

32 minutes ago, evildictait​or wrote

So let me get this straight...

this is a collection of elements generated by a JITted scripting language on a load-balanced server which generates HTML and Javascript and pushes it over the Interwebs to a client which JITts the javascript to try and recover some of the speed lost by using a retarded language like javascript and using hardware acceleration in CSSv3 because GDI is slow, all using optimised AJAX/JSON in order to try and keep latency down between the server and the client over keep-alive HTTP in order to avoid the cost of restarting TCP connections...

... in order to render a console program that was invented in the 1980s?

FFS. Developers are stupid. Shouldn't we have swishy minority-report style GUIs now? Why do people still want vi? Have we really been running so fast just to keep still?

+1 for the use of "to try and recover some of the speed lost by using a retarded language like javascript" alone.

Sadly I've yet to find a UI that is actually demonstratively better than the "a console program in the 1980s". Once you get past the learning curve Vim is an incredibly productive text editor.

4 minutes ago, Bass wrote

@evildictaitor:

Sadly I've yet to find a UI that is actually demonstratively better than the "a console program in the 1980s". Once you get past the learning curve Vim is an incredibly productive text editor.

Have you been keeping your eyes squeezed tight for the past thirty years?

Emacs is alright too, if that makes you feel better. I'm sure it can run on this web console too (ignoring XEmacs of course, heh).

29 minutes ago, Bass wrote

@evildictaitor:

Emacs is alright too, if that makes you feel better. I'm sure it can run on this web console too (ignoring XEmacs of course, heh).

Really? You think emacs is "alright"?

Why did you ever bother to move off DOS is CUIs are so great?

The whole reason why the web was invented was to give a graphical interface to information because the CUIs of the time were cumbersone and nasty and because CUIs are generally pretty crap at conveying information in a usable form to normal users.

Developers who have decided to take the power of their GUI and make it emulate a CUI are so far past the point of understanding normal users that they frankly should just retire and be done with it.

Ug, don't tell me you are some kind of hipster that wants to be "different" and use Nano.

Regardless, if I want a easy to access text editor I'm going to pick Vim. I will concede that Emacs might be more advanced in some areas, and the built in Lisp interpreter is a nice touch. But I think what really attracts me to what you might call the "Editor of the Beast" is that is just more available. I'm almost guaranteed to have access to it no matter what box I'm on. Emacs doesn't come close in this type of thing.

Obviously this also means I have more experience with Vim, so yes, I am far more productive using it vs Emacs. YMMV.

Exactly what does a command line interface, as integrated with a cloud-based development environment, and used by developers in that environment, have to do with normal users?

Should the Solution Explorer, watch window, and Object Browser be removed from Visual Studio because it's useless to "normal users"? 

I'm boggled by your post. Though I will refrain from commenting on your related contention that there's something inherently wrong with a command line interface in the first place.

6 hours ago, Bass wrote

@evildictaitor:

Ug, don't tell me you are some kind of hipster that wants to be "different" and use Nano.

What part of me obviously disliking CUIs makes you think I would prefer a different CUI to the one you first suggested?

What I use is GUI programs. GUI programs are way more responsive to users, give information in much more condensed and more useful forms and don't get overly encumbered by the retarded need to turn all information into text when other ways to convey the information are almost invariably better.

1 hour ago, Craig_​Matthews wrote

Should the Solution Explorer, watch window, and Object Browser be removed from Visual Studio because it's useless to "normal users"? 

On the contrary - they are great examples of where Visual Studio beats stuff like GCC precisely because it's a graphical representation of the code.

Nobody in their right mind develops code in Vim or Nano or Emacs. The world has moved on to (at the very least) Eclipse and Visual Studio - you know - programs that have intellisense and right-click refactoring and control-click jump-to-definitions, like how Emacs and Vim and Nano don't.

Terminals suck. A GUI always conveys information better, because in the limit, they can just output text in the same way - this thread is a case in point - Anything VI can do, by definition Google Chrome can do better - but as well as the text, GUIs can have menus and clicks and animations and side-bars that immerse you in the information in a way that CUIs simply can't. And another great thing about GUIs? They don't need a manpage or a freakishly good memory to remember how to use the damn thing.

GUIs just work. CUIs mainly exist to stroke the egos of the users who can be bothered to memorize their retarded command line syntax and to satisfy the laziness of their developers who can't be bothered to output information with anything more complicated than a printf.

The title of this thread is wrong. Instead of saying "The future is almost here", it should really read "The ghosts of bad user interaction design from the 1960s are still haunting us".

Using a browser to implement a terminal emulator is a clever hack, but sounds insanely wasteful. Can anybody explain why it's such a good idea?

Emacs and Vim certainly have GUI interfaces (for decades maybe), but I find that they really don't buy you anything. Some people might prefer it or find it useful, esp. those with less experience.

Anyway the 1960s were better - CLIs, free love and good music. All of which I take advantage of today in 2012 as well.

CLI is a way of life for a POSIX developer. When I'm doing development I always have terminals open. File management, source control, compilation, some kinds of refactoring, etc. are all via CLI commands. This is especially true for modern web frameworks (eg. using the "rails" command for project management and building). Cloud9 mostly focuses on web development so it's not surprising that terminal support was in high demand. It also lets you SSH into your hosts which is obviously not that unusual. Linux servers are usually headless and don't have Xlib available.

For example, something like generate create/alter SQL statement for changes... Now I have to look at multiple instances and hand-pick the changes from design view one by one. Can't imagine if I have to hand-pick in order to sync schemas across more instances...

Now the "next best" solution is to use a local instance of SQL server as master schema and do all the modifications here, then generate script to deploy to SQL Azure. It could work but is suboptimal I think.

16 minutes ago, Bass wrote

Emacs and Vim certainly have GUI interfaces (for decades maybe),

Cmd.exe has a right click menu, a scrollbar and a window that is painted by GDI, but that doesn't make it magically a GUI program.

The reason Emacs and Vim's GUI "don't buy you anything" is because they are developed with a CLI mindset, and no matter how much code someone adds to them, they are going to be permanently crippled by their own inability to see that CLIs suck and that they should just write a GUI version of their own program and it will be better.

Your claim that GUIs in general are for people with less experienced is astonishing. I sincerely hope you used something like wget to submit that comment to C9 and are manually grepping through HTML to read my response right now - if you used something like Firefox, IE or Chrome you'd be looking very hypocritical right now.

12 hours ago, evildictait​or wrote

So let me get this straight...

this is a collection of elements generated by a JITted scripting language on a load-balanced server which generates HTML and Javascript and pushes it over the Interwebs to a client which JITts the javascript to try and recover some of the speed lost by using a retarded language like javascript and using hardware acceleration in CSSv3 because GDI is slow, all using optimised AJAX/JSON in order to try and keep latency down between the server and the client over keep-alive HTTP in order to avoid the cost of restarting TCP connections...

... in order to render a console program that was invented in the 1980s?

FFS. Developers are stupid. Shouldn't we have swishy minority-report style GUIs now? Why do people still want vi? Have we really been running so fast just to keep still?

Community >> Technology (especially closed)

13 hours ago, Bas wrote

*snip*

 

+1 for the use of "to try and recover some of the speed lost by using a retarded language like javascript" alone.

The voices that FUD the web stack are getting softer and softer, so congratulations for being one of the last ones.

11 hours ago, Bass wrote

@evildictaitor:

Ug, don't tell me you are some kind of hipster that wants to be "different" and use Nano.

The irony of this made me laugh hard; using a command-line and calling someone else a hipster?

You made me think of this:

(http://jpegy.com/fail/youre-not-a-real-hispter-until-you-take-your-typewriter-to-the-park-11482)

Herbie

9 hours ago, Bass wrote

@Blue Ink

CLI is a way of life for a POSIX developer. When I'm doing development I always have terminals open. File management, source control, compilation, some kinds of refactoring, etc. are all via CLI commands. This is especially true for modern web frameworks (eg. using the "rails" command for project management and building). Cloud9 mostly focuses on web development so it's not surprising that terminal support was in high demand. It also lets you SSH into your hosts which is obviously not that unusual. Linux servers are usually headless and don't have Xlib available.

Yes, been there, done that. And I'm still using terminals, so I can relate.

My question was specifically why it would be such a good idea to use a browser to do the job of a terminal emulator; first off because from a power consumption point of view it's like going after a pimple with a fire axe; then it's a lot more complicated to develop and maintain; finally - and irrationally - it just feels wrong to stack protocols the other way around.

Again, I don't see the point. If there's a good reason that doesn't sound like "because we can", or  "because it's all running in a browser", I'd like to know what that is.

I'll tell you what is more pointless, the built-in terminal in Eclipse. If I have a thick-client IDE, I probably also have a thick-client terminal somewhere too. Now I ain't gonna unload a can of whoopass on the Eclipse developers because someone felt it was worth adding - maybe I'm not seeing some purpose that others have.

I'm sorry you can't see a purpose. But I know you can't promise that on a computer in a library I will have a terminal, you savvy? So if I want a terminal, well thanks Cloud9 for making one for me that doesn't require I install PuTTY or Cygwin if I'm on 'winders. That's purpose enough for me.

1 hour ago, Bass wrote

@Blue Ink:

I'll tell you what is more pointless, the built-in terminal in Eclipse. If I have a thick-client IDE, I probably also have a thick-client terminal somewhere too. Now I ain't gonna unload a can of whoopass on the Eclipse developers because someone felt it was worth adding - maybe I'm not seeing some purpose that others have.

Agreed; it's probably less wasteful than having it browser based, but it does feel like the proverbial kitchen sink.

I'm sorry you can't see a purpose. But I know you can't promise that on a computer in a library I will have a terminal, you savvy? So if I want a terminal, well thanks Cloud9 for making one for me that doesn't require I install PuTTY or Cygwin if I'm on 'winders. That's purpose enough for me.

For that matter, you cannot even promise that some random computer in the library will have a compliant browser (IE is not supported, for the record; there goes a good chunk of public computers).

That's not what I was discussing, though. I understand how convenience may sometime justify the drastic compromises; what I don't get is why this should be considered "the future" of development, as the OP seems to imply. Again, I don't see the point.

Regarding compliant browsers. Libraries and computer labs I frequent have Firefox so it's a non-issue. I find this wasn't the case maybe two-three years ago. Chrome doesn't seem to get the same love however.

22 hours ago, Bass wrote

It's the future in the sense that a lot of stuff is going to the web that was fat-client before. Notably for myself I'm a big Google Docs user and do my taxes from a web site, both things I used to do with fat clients.

In the future as in "does this progress us towards a technological singularity" kind of future, at least not directly. Centralizing data (also known as the "big data" movement) allows for data mining, which can drive machine learning and produce more intelligent (perhaps truly intelligent) software.

Regarding compliant browsers. Libraries and computer labs I frequent have Firefox so it's a non-issue. I find this wasn't the case maybe two-three years ago. Chrome doesn't seem to get the same love however.

Interesting. I see exactly the opposite trend: stuff that used to be web-based is now running on the client and, often enough, doing away with the browser completely. Cloud storage is the only aspect that I see consistently increasing, but that's hardly news.

There's a reason why we moved away from thin clients thirty years ago and those reasons haven't gone away just yet.

About compliant browsers; good for you. That doesn't change the fact that the solution is not 100% dependable, and that's not good enough for me.

About compliant browsers; good for you. That doesn't change the fact that the solution is not 100% dependable, and that's not good enough for me.

But it's more dependable. It becomes the difference between "I can sometimes/most_of_the_time do development on a computer that doesn't belong to me", to "I can never do development on a computer that doesn't belong to me".

Then there is the idea that this IDE might just be better.

Cloud9 supports code highlighting, autocomplete, quick deployment, source control, refactoring -basically the things I expect in an IDE (although really for me the first two matter the most, everything else is just random crap I can get from the command line just as easy if not easier).

So I get what is an awesome IDE, but I don't have to install anything and I can use it on FAR MORE computers than a fat client. Maybe not every computer, true. But this is still a great improvement.

There's a reason why we moved away from thin clients thirty years ago and those reasons haven't gone away just yet.

I think the pros outway the cons. I'll just leave these cheesy marketing videos essentially promoting the idea of thin clients here and say "I'm Bass and I approve this message."

Mobile apps are often "thin client" in that they expect some kind of connection for many important purposes. Some of them may even be written in HTML/CSS/JS, this is a perfectly valid way to write a mobile app that is accepted in pretty much any store, and one of the only cross-platform ways to do so.

1 hour ago, Bass wrote

*snip*

But it's more dependable. It becomes the difference between "I can sometimes/most_of_the_time do development on a computer that doesn't belong to me", to "I can never do development on a computer that doesn't belong to me".

The real question is "do I have to carry my computer with me?". As far as I cannot rely 100% on public computers, the answer will invariably be "yes".

Except that soon enough the question will become "can I make do with my tablet/ultraportable or do I need my laptop?". The whole concept of using computers that don't belong to us is going to be irrelevant.

So I get what is an awesome IDE, but I don't have to install anything and I can use it on FAR MORE computers than a fat client. Maybe not every computer, true. But this is still a great improvement

What you get is an IDE (awesome or otherwise) that only works when you have a good internet connection, which may be unavailable, unreliable, or just plain too expensive in the long run. It's a high price to pay for not having to install my tools once every one or two years; and at least to me, it doesn't seem an improvement at all.

Mobile apps are often "thin client" in that they expect some kind of connection for many important purposes. Some of them may even be written in HTML/CSS/JS, this is a perfectly valid way to write a mobile app that is accepted in pretty much any store, and one of the only cross-platform ways to do so.

The whole concept of "thin client/fat client" is not so clear cut nowadays. It is a rabbit hole I would rather leave alone at the moment.

The whole tablet/laptop duality thing just reinforces the usefulness of these projects, especially if you are an OS polyglot. Also, offline support / local storage in HTML5 would rectify connection problems.

I'm not going to sit here and shill for Cloud9 all day (esp. since they aren't paying me for the privilege), but I just encourage people to try it out and make decisions for themselves. Note that I don't think Niners with .NET/Windows experience are really the target market, but it is still worth trying IMO.

The real question is "do I have to carry my computer with me?". As far as I cannot rely 100% on public computers, the answer will invariably be "yes".

That problem is going in the other direction.

Rather than being "do I have to carry my computer on me", the question is rapidly turning into "is there any time when I won't have a high-powered computation device on my person"?

A few years ago, having a laptop was a luxury and poorer students might reasonably have wanted a computer at university that they could use. But now most people - at least in the first world - have tablets and phones which are perfectly capable of running quite powerful programs.

The web is less relevant than it was a few years ago - as custom "apps" continue to erode the need for applications to be run through the browser. The web still has a use for distributed computing and massive datasets, but it's entirely plausible that in the future those happen through web-services interacting with apps rather than through HTML and a browser.

But in any case, unless you intend to do all of your development on the cloud without ever authenticating via a login form, the "public computers" argument is always going to hold little water. Public computers can't be trusted not to have rootkits and keyloggers, and I think a mythical future time when they can be trusted is likely to be further off than a future in which everyone carries a smartphone powerful enough to plug into a dumb-screen and run all the apps they could ever want.