who's on it and what do you think? I am fullname + middle initial + lastname@googlewave.com. I'm kind of hating it so far. I love the idea of a new email-like protocol to replace email and various IM protocols, but am kind of hating the interface to it right now. I guess that is independent of the server portion though, so this could be improved and different options could become available. I just hate the whole shift+enter to add replies thing. this along with nesting replies and stuff becomes kind of confusing.
I've thought about downloading the wave protocol source (it's implemented as an xmpp extension) and trying to install it on my server, but haven't had the time/motivation yet.
I've thought about downloading the wave protocol source (it's implemented as an xmpp extension) and trying to install it on my server, but haven't had the time/motivation yet.
I'm not on it. :\
I don't think they gave me any invites :/. when my roommate signed up it gave him 8 supposedly but when he tried to invite someone it just said they had been "recommended" for receiving an invite, or something.
yeah takes time to come through.
also wave is html5 make sure you are using something that can handle it.
Invitation finally came through ... woo.
john.r.davis@googlewave.com
john.r.davis@googlewave.com
interesting extensions (and robots)
watexy@appspot.com - for LaTeX math on Wave :D
tweety-wave@appspot.com - Twitter on Wave
twiliobot@appspot.com - connect phone calls and record convo, pump back into Wave.
amazon-withwaves-com@appspot.com - use amazon product api to find items
posterous-robot@appspot.com - posterous robot
i found some of these bots listed in a pdf, and some on this site:
http://seekdroid.appspot.com/
watexy@appspot.com - for LaTeX math on Wave :D
tweety-wave@appspot.com - Twitter on Wave
twiliobot@appspot.com - connect phone calls and record convo, pump back into Wave.
amazon-withwaves-com@appspot.com - use amazon product api to find items
posterous-robot@appspot.com - posterous robot
i found some of these bots listed in a pdf, and some on this site:
http://seekdroid.appspot.com/
ms7373@googlewave.com :D
Did anyone here nominate me?
Did anyone here nominate me?
i'm not on it. i almost got one from a friend of a friend who worked at google but he never came through :(
You're invited now. :)
aaah, that was fast!
I am on a private wave of filesharing links to albums that people have uploaded. If you would like to be added/contribute to the wave, let me know and I'll add you to it!
i hate google wave
why can i be dragged into a conversation while i'm offline? fuck that noise, google
why can i be dragged into a conversation while i'm offline? fuck that noise, google
I dunno, you can get an email while you're offline too.
you can get an email while you're offline
point
e-mail sucks, too, but at least it's not as bad as google wave
I still don't get the google wave hate. I mean, I'm skeptical of it too, but an open protocol that aims to replicate the functionality of email/IM/forums/wikis with something more modern, distributed, and easily searchable has the potential to be pretty neat.
i suppose it's too early to pass judgment
however, i am a firm believe in the "plethora of dicks hypothesis."
the hypothesis goes like this: if it's possible to produce a dick in a certain medium, then dicks will be produced excessively in that medium
this was corroborated when, upon logging into wave for the second time ever, i was greeted with 3 distinct waves filled with nothing but dicks: drawn, typed, videoed, painted, screamed, and wiki'd
there were so many dicks that i could barely scroll through the wave as phalli were being loaded from the vast reaches of the internet. i dare not even log in again for fear of what manner of dickery may lay ahead
so, perhaps this is even a case of the "johnson corollary," wherein any medium that is used for excessive dick-drawing is more likely to be trivialized and rendered useless. only time will tell
however, i am a firm believe in the "plethora of dicks hypothesis."
the hypothesis goes like this: if it's possible to produce a dick in a certain medium, then dicks will be produced excessively in that medium
this was corroborated when, upon logging into wave for the second time ever, i was greeted with 3 distinct waves filled with nothing but dicks: drawn, typed, videoed, painted, screamed, and wiki'd
there were so many dicks that i could barely scroll through the wave as phalli were being loaded from the vast reaches of the internet. i dare not even log in again for fear of what manner of dickery may lay ahead
so, perhaps this is even a case of the "johnson corollary," wherein any medium that is used for excessive dick-drawing is more likely to be trivialized and rendered useless. only time will tell
ok
i don't like how it's a centralized service. can i setup my own wave server that will integrate with google wave?
i can do that with smtp and gmail.
i can do that with smtp and gmail.
> can i setup my own wave server that will integrate with google wave?
Yup: http://code.google.com/p/wave-protocol/wiki/Installation
Yup: http://code.google.com/p/wave-protocol/wiki/Installation
yeah, that's what I'm talking about with the server-to-server stuff. same concept as jabber or email.
i see
or irc.
or open napster.
or aim.
or icq.
or silc.
...
AIM? ICQ?
I realize server-to-server communication isn't something revolutionary in itself, but a big company like Google creating this whole new protocol with the aim of replicating the functionality of a bunch of other useful things and making it an open protocol, is pretty cool I think.
I realize server-to-server communication isn't something revolutionary in itself, but a big company like Google creating this whole new protocol with the aim of replicating the functionality of a bunch of other useful things and making it an open protocol, is pretty cool I think.
It was cool in 1992 when they did it. Now it's just rebranding web 2.0 attempting to do something it shouldn't.
> it's just rebranding web 2.0 attempting to do something it shouldn't
isn't this the definition of web 2.0?
isn't this the definition of web 2.0?
what did they do in '92?
web 2.0 is such a meaninglessly vague term that any response I make to that would probably be based on misinterpretation.
web 2.0 is such a meaninglessly vague term that any response I make to that would probably be based on misinterpretation.
okay... in more explicit terms... HTTP is not a sane protocol for client server interactivity. It's simply not built for it on the networks we have today. Nor is it a very good approach to application UI development. This is something we've known for years. Even google has come to the same conclusion and thus presented SPDY as an alternative protocol for generic internetwork interactions.
There are some benefits to http today over other solutions... the big one being a uniform and open protocol that is widely support across almost all networked devices.
My concern with wave is that google is attempting to play off of developers that use their web application experience as a crutch. Since the number of web developers, and barrier to entry into the field is so low, they can simply expect to gain widespread popular adoption. However that's flawed in design approach. Using web development popularity and learning curves as a crutch betrays the proper development of the protocol in favor of popularity.
This is the same problem hadoop suffers from ( though far more severely ).
If you don't get your core infrastructure setup properly you are doomed to failure... look at ruby, look at twitter. Popular yes, but now both synonymous with unstable.
For something as core as primary communication methodology, you should be building out a proper infrastructure, and a well thought our and forward thinking design path. Wave is not a well thought out and forward thinking design path. It clings to the decadent remains of http and html and yet tries to make itself into a core communication protocol.
It's a mistake. Plain and simple. Adoption surely isn't impossible, but it's not the first time we've all suffered due to poor protocol designs. Look at email... a truly flawed protocol... unfixable, and yet impossible to replace... wave could be another debacle like email was.
Just my thoughts.
There are some benefits to http today over other solutions... the big one being a uniform and open protocol that is widely support across almost all networked devices.
My concern with wave is that google is attempting to play off of developers that use their web application experience as a crutch. Since the number of web developers, and barrier to entry into the field is so low, they can simply expect to gain widespread popular adoption. However that's flawed in design approach. Using web development popularity and learning curves as a crutch betrays the proper development of the protocol in favor of popularity.
This is the same problem hadoop suffers from ( though far more severely ).
If you don't get your core infrastructure setup properly you are doomed to failure... look at ruby, look at twitter. Popular yes, but now both synonymous with unstable.
For something as core as primary communication methodology, you should be building out a proper infrastructure, and a well thought our and forward thinking design path. Wave is not a well thought out and forward thinking design path. It clings to the decadent remains of http and html and yet tries to make itself into a core communication protocol.
It's a mistake. Plain and simple. Adoption surely isn't impossible, but it's not the first time we've all suffered due to poor protocol designs. Look at email... a truly flawed protocol... unfixable, and yet impossible to replace... wave could be another debacle like email was.
Just my thoughts.
I may be mistaken, but I don't think that the wave protocol is inherently tied to HTML or HTTP. right now the protocol is available as an extension to the XMPP protocol and there are wave clients that run at the command line (granted I don't know what they are written in or how exactly they access a wave server).
granted again that the client virtually everyone is using right now is a web client. but my point is that the protocol itself is not tied to HTTP, if I am understanding it correctly.
granted again that the client virtually everyone is using right now is a web client. but my point is that the protocol itself is not tied to HTTP, if I am understanding it correctly.
yeah it's xmpp.... thus my statement earlier... may as well be irc. or icq. or aim... or a million other chat protocols.
I'm not sure if the plan is to keep it as an XMPP extension or not, but regardless, your issues with HTTP are not inherent to the wave protocol, they're just incidental problems because of the initial manner by which virtually everyone is using it.
> you are doomed to failure... look at ruby
could you explain this, nny?
could you explain this, nny?
sure, ruby simply doesn't scale ( or at least it didn't a year ago when I looked at it last ). twitter for instance was originally a ruby app. In the early days it collapsed pretty much constantly... as will pretty much any ruby app with dynamic content and more than a couple hundred simultaneous users (again, since I last checked ).
ruby on rails despite being one of the easiest development environments on earth fell flat on its face in the commercial market, and it's not like it never had a chance. everyone and their mother looked at it, some still are looking at it. but the environment simply isn't capable of scaling. you write an app in ruby, if it becomes popular, you have to rewrite it from scratch. that's bad. and of course there's the stigma... ruby is now synonymous with failure among IT people. That's very bad when you are looking for adoption, and the other side of the maintenance responsibility wants no part of it.
asemiskdkfj,
sure it's not a wave specific complaint, but it moots wave as a useful alternative to existing technology. there's no major benefits to the application ( yet )
ruby on rails despite being one of the easiest development environments on earth fell flat on its face in the commercial market, and it's not like it never had a chance. everyone and their mother looked at it, some still are looking at it. but the environment simply isn't capable of scaling. you write an app in ruby, if it becomes popular, you have to rewrite it from scratch. that's bad. and of course there's the stigma... ruby is now synonymous with failure among IT people. That's very bad when you are looking for adoption, and the other side of the maintenance responsibility wants no part of it.
asemiskdkfj,
sure it's not a wave specific complaint, but it moots wave as a useful alternative to existing technology. there's no major benefits to the application ( yet )
Twitter had an architecture design problem. They are a messaging application. They designed it like a traditional web/database app and surprise, it didn't work very well.
Saying "language X doesn't scale" is nonsense. It's a matter of architecture.
Saying "language X doesn't scale" is nonsense. It's a matter of architecture.
Okay some specifics of Ruby Architecture sucking...
It's byte code VM blows hard.
It has a byte code VM. No language on earth has successfully implemented one. And no... Java hasn't either. I still say Java is alpha ware and isn't production ready by a long shot.
Garbage collection in ruby makes it look like garbage collection in java works ( it doesn't in case you were wondering ).
attempts at risc execution in bytecode vm... lolz. nice try tho =P
Rails itself requires database re-scheming due to some incredibly poor design decisions... like reserving tables with the word "transaction" in them. good job guys! And that's just one of the many things that makes using rails impossible for most organizations.
Oh yes and before you ask, I am one of those guys who argued MySQL wasn't actually a database until MySQL 5. Because well... it wasn't. And it's still a steaming pile of poop and I have no clue why people use it. I hope oracle kills it. We'd all be better off.
Fun Links:
http://www.joelonsoftware.com/items/2006/09/12.html 2006 post about ruby sucking ( pre bytecode vm )... ref'd 10x-50x slower than java execution... dead last in language shoot out.
http://www.theregister.co.uk/2008/04/21/bray_ruby_rails/ 2008, byte code exists at this point... sun still referencing a 40x speed deficiency against java.... which is a lumbering beast in its own right.
and in 2003, you can look up slides of the creator of ruby discussing some of the core deficiencies in ruby.... heh... many of his solutions didn't fix any of them.
As I said earlier, I've not used it in a year...
supposedly 1.9 and above got much better in terms of speediness and stability.
they are comparing themselves to python... which is middle of the pack for the slow moving languages. probably still 20x slower than java in most enterprise deployments then by rough fermi math style estimates that I am literally pulling out of the ether of past experience. but I am pretty certain I am remembering some shoot out stats I read in sept or so that showed similar results.
that being said, I don't hate python because its slow. there's plenty of slow languages that serve their purpose. perl and python both have a place in back end administrative tasks and perl definitely in parsing txt file data. regex is perl's home turf, and it won't give it up without a fight. So maybe some day ruby will find a place to exist.... but it hasn't yet. And personally I think the java model of byte code interpreters is going to remain a design failure for a very long time.
But that's just my opinion.
It's byte code VM blows hard.
It has a byte code VM. No language on earth has successfully implemented one. And no... Java hasn't either. I still say Java is alpha ware and isn't production ready by a long shot.
Garbage collection in ruby makes it look like garbage collection in java works ( it doesn't in case you were wondering ).
attempts at risc execution in bytecode vm... lolz. nice try tho =P
Rails itself requires database re-scheming due to some incredibly poor design decisions... like reserving tables with the word "transaction" in them. good job guys! And that's just one of the many things that makes using rails impossible for most organizations.
Oh yes and before you ask, I am one of those guys who argued MySQL wasn't actually a database until MySQL 5. Because well... it wasn't. And it's still a steaming pile of poop and I have no clue why people use it. I hope oracle kills it. We'd all be better off.
Fun Links:
http://www.joelonsoftware.com/items/2006/09/12.html 2006 post about ruby sucking ( pre bytecode vm )... ref'd 10x-50x slower than java execution... dead last in language shoot out.
http://www.theregister.co.uk/2008/04/21/bray_ruby_rails/ 2008, byte code exists at this point... sun still referencing a 40x speed deficiency against java.... which is a lumbering beast in its own right.
and in 2003, you can look up slides of the creator of ruby discussing some of the core deficiencies in ruby.... heh... many of his solutions didn't fix any of them.
As I said earlier, I've not used it in a year...
supposedly 1.9 and above got much better in terms of speediness and stability.
they are comparing themselves to python... which is middle of the pack for the slow moving languages. probably still 20x slower than java in most enterprise deployments then by rough fermi math style estimates that I am literally pulling out of the ether of past experience. but I am pretty certain I am remembering some shoot out stats I read in sept or so that showed similar results.
that being said, I don't hate python because its slow. there's plenty of slow languages that serve their purpose. perl and python both have a place in back end administrative tasks and perl definitely in parsing txt file data. regex is perl's home turf, and it won't give it up without a fight. So maybe some day ruby will find a place to exist.... but it hasn't yet. And personally I think the java model of byte code interpreters is going to remain a design failure for a very long time.
But that's just my opinion.
Oh and look up stats on 1.8 ruby with db transactions... when you look at what twitter is... you realize pretty fast that ruby was NOT the right tool for the job.
Too dynamic a site.
Too dynamic a site.
> It's byte code VM blows hard.
> It has a byte code VM.
Wrong. Ruby 1.8 (which is what I assume twitter uses, since rails wasn't (isn't?) compatible with 1.9) has no bytecode VM.
> I still say Java is alpha ware and isn't production ready by a long shot.
I'll be the first to say java sucks but saying it's "alphaware"? Do you realize how many critical systems run on top of the jvm these days? Besides, the jvm is a good piece of technology (and seems to be becoming what parrot wanted to be, with all the j* implementations of various languages now).
Java is pretty slow if you consider VM initialization overhead. If you run the VM in server mode, it's actually quite fast.
Of course, I'm not arguing that ruby is fast. It's probably fast enough though, if you consider that in some domains you spend much more time doing I/O or waiting data from a network or using the database. Nobody is going to use an interpreted language for CPU-intensive tasks anyway.
From what I know, the VMs for ruby 1.9 and python are pretty similar in design. Do you think python sucks too?
> Rails itself requires database re-scheming due to some incredibly poor design decisions
That is completely irrelevant to the discussion. It has some conventions that you may or may not like but which have nothing to do with scaling.
Just our of curiosity, what languages do you like or consider to be good designs?
> It has a byte code VM.
Wrong. Ruby 1.8 (which is what I assume twitter uses, since rails wasn't (isn't?) compatible with 1.9) has no bytecode VM.
> I still say Java is alpha ware and isn't production ready by a long shot.
I'll be the first to say java sucks but saying it's "alphaware"? Do you realize how many critical systems run on top of the jvm these days? Besides, the jvm is a good piece of technology (and seems to be becoming what parrot wanted to be, with all the j* implementations of various languages now).
Java is pretty slow if you consider VM initialization overhead. If you run the VM in server mode, it's actually quite fast.
Of course, I'm not arguing that ruby is fast. It's probably fast enough though, if you consider that in some domains you spend much more time doing I/O or waiting data from a network or using the database. Nobody is going to use an interpreted language for CPU-intensive tasks anyway.
From what I know, the VMs for ruby 1.9 and python are pretty similar in design. Do you think python sucks too?
> Rails itself requires database re-scheming due to some incredibly poor design decisions
That is completely irrelevant to the discussion. It has some conventions that you may or may not like but which have nothing to do with scaling.
Just our of curiosity, what languages do you like or consider to be good designs?
> Wrong. Ruby 1.8 (which is what I assume twitter uses, since rails wasn't (isn't?) compatible with 1.9) has no bytecode VM.
Not sure what twitter uses for a VM. I am guessing.
> I'll be the first to say java sucks but saying it's "alphaware"? Do you realize how many critical systems run on top of the jvm these days?
I deal with stuff running truly critical systems on JVMs. And I say now more than ever, the people responsible for that should be fired. It was a mistake then, it's a mistake today.
> Besides, the jvm is a good piece of technology (and seems to be becoming what parrot wanted to be, with all the j* implementations of various languages now).
I disagree. I think the JVM was a good idea. In implementation though it has failed utterly every time it's been attempted. And with Sun now facing possible extinction under the ownership of Oracle... and that really is no a joke or sarcasm... major MAJOR accounts are dropping sun like its just gone full turd. I'd be very concerned about j anything. That's a whole nother can of worms.
> Java is pretty slow if you consider VM initialization overhead. If you run the VM in server mode, it's actually quite fast.
EJBs are fairly functional. And J2EE can be fairly fast when put together right. Problem is, there's a lot of bad Java devs out there.
> Of course, I'm not arguing that ruby is fast. It's probably fast enough though, if you consider that in some domains you spend much more time doing I/O or waiting data from a network or using the database. Nobody is going to use an interpreted language for CPU-intensive tasks anyway.
Problem is... Ruby is slow at DB transactions... and the level of slow has traditionally been below the threshold of adaptability. The hardware overhead is just too great. Which is saying a hell of a lot about speed. There's a zillion and one discussions and articles on this. Obviously a point of contention... but it being a point of contention says a lot.
> From what I know, the VMs for ruby 1.9 and python are pretty similar in design. Do you think python sucks too?
1. Yes.
2. But my hatred of Python is not relevant to the discussion at all. The things I hate about python seem to be very unique to python. Two biggest gripes... the language itself is a moving target, they are swapping core methods every release. Makes adoption of python a pain in the ass. Makes coding for heterogeneous python environments in policy strict environments... well... a nightmare. Also, python has some serious issues with lacking core posix support. When it was designed... it was designed by developers, and didn't have any that apparently knew jack shit about posix compliance.
That being said, as I alluded to before... python, like perl... is slow. But for what it does... it doesn't need to be fast. As a CGI I'd say using python or perl is just stupid as hell. But using python or perl to automate backend processes... and installation processes... is absolutely fine if not preferable. Both languages are very good for back end automation and administrative tasks. Run em in cron or manually... trigger them occasionally... they're great in that niche. It's a duct tape language.
Ruby isn't. Ruby is a front end web language. It's supposed to be able to take a pounding.
> Just our of curiosity, what languages do you like or consider to be good designs?
perl does regex well. damned well. it has a niche... and it rocks it.
shell ( bash, ksh, csh... ) for the time in which they came about they were amazing. still useful.
flex / sed / awk / ... specialty languages... some are damned fine.
c ... closest language to perfection to date.
c++ ... had some benefits over c, but really not enough to replace c. more often then not they work well in tandem.
c# / mono / objective c... a lot of these languages are developing and fighting off some bugs... but they are still doing an amazing job providing developers with the ability to quickly roll out stable, fairly speedy, and effective applications. Great stuff. Reminds me of QT... such a great windowing engine to work with.
In web languages...
j2ee sometimes works damned well.
php sometimes works damned well.
templating + c cgis or python / perl / ... ( augmented by compiled methods and modules ) can work very well.
flex and similar technologies are fun to watch grow. could be amazing stuff if done right.
but as I said earlier... I think HTTP is well past its prime. We need something new... and that's going to require some new languages and new ways of thinking about how people use the internet.
Not sure what twitter uses for a VM. I am guessing.
> I'll be the first to say java sucks but saying it's "alphaware"? Do you realize how many critical systems run on top of the jvm these days?
I deal with stuff running truly critical systems on JVMs. And I say now more than ever, the people responsible for that should be fired. It was a mistake then, it's a mistake today.
> Besides, the jvm is a good piece of technology (and seems to be becoming what parrot wanted to be, with all the j* implementations of various languages now).
I disagree. I think the JVM was a good idea. In implementation though it has failed utterly every time it's been attempted. And with Sun now facing possible extinction under the ownership of Oracle... and that really is no a joke or sarcasm... major MAJOR accounts are dropping sun like its just gone full turd. I'd be very concerned about j anything. That's a whole nother can of worms.
> Java is pretty slow if you consider VM initialization overhead. If you run the VM in server mode, it's actually quite fast.
EJBs are fairly functional. And J2EE can be fairly fast when put together right. Problem is, there's a lot of bad Java devs out there.
> Of course, I'm not arguing that ruby is fast. It's probably fast enough though, if you consider that in some domains you spend much more time doing I/O or waiting data from a network or using the database. Nobody is going to use an interpreted language for CPU-intensive tasks anyway.
Problem is... Ruby is slow at DB transactions... and the level of slow has traditionally been below the threshold of adaptability. The hardware overhead is just too great. Which is saying a hell of a lot about speed. There's a zillion and one discussions and articles on this. Obviously a point of contention... but it being a point of contention says a lot.
> From what I know, the VMs for ruby 1.9 and python are pretty similar in design. Do you think python sucks too?
1. Yes.
2. But my hatred of Python is not relevant to the discussion at all. The things I hate about python seem to be very unique to python. Two biggest gripes... the language itself is a moving target, they are swapping core methods every release. Makes adoption of python a pain in the ass. Makes coding for heterogeneous python environments in policy strict environments... well... a nightmare. Also, python has some serious issues with lacking core posix support. When it was designed... it was designed by developers, and didn't have any that apparently knew jack shit about posix compliance.
That being said, as I alluded to before... python, like perl... is slow. But for what it does... it doesn't need to be fast. As a CGI I'd say using python or perl is just stupid as hell. But using python or perl to automate backend processes... and installation processes... is absolutely fine if not preferable. Both languages are very good for back end automation and administrative tasks. Run em in cron or manually... trigger them occasionally... they're great in that niche. It's a duct tape language.
Ruby isn't. Ruby is a front end web language. It's supposed to be able to take a pounding.
> Just our of curiosity, what languages do you like or consider to be good designs?
perl does regex well. damned well. it has a niche... and it rocks it.
shell ( bash, ksh, csh... ) for the time in which they came about they were amazing. still useful.
flex / sed / awk / ... specialty languages... some are damned fine.
c ... closest language to perfection to date.
c++ ... had some benefits over c, but really not enough to replace c. more often then not they work well in tandem.
c# / mono / objective c... a lot of these languages are developing and fighting off some bugs... but they are still doing an amazing job providing developers with the ability to quickly roll out stable, fairly speedy, and effective applications. Great stuff. Reminds me of QT... such a great windowing engine to work with.
In web languages...
j2ee sometimes works damned well.
php sometimes works damned well.
templating + c cgis or python / perl / ... ( augmented by compiled methods and modules ) can work very well.
flex and similar technologies are fun to watch grow. could be amazing stuff if done right.
but as I said earlier... I think HTTP is well past its prime. We need something new... and that's going to require some new languages and new ways of thinking about how people use the internet.
I don't code lisp... but I have seen several talented friends convert... so I assume from that it's worth some looking at when time allows.
Well, I don't consider ruby to be a web language, as it predates Rails by many years. Rails just happens to be a nice library for Ruby (for some values of "nice"), so people use it for web development. Saying ruby is a web language is like saying python is a web language because of Django. For example, here at work, we've been using ruby for the sysadmin scripts for some time now. We've been slowly porting the old perl stuff, and writing new stuff in ruby. I don't think anyone here has regreted that move.
Web applications are becoming larger and more complex. I believe (or hope...) people will eventually notice that using dynamic languages for large applications is unfeasible because it's simply too easy to break stuff without noticing.
Now... C the closest language to perfection to date? Come on... I can appreciate the "cool" value that it has, and the speed, and everything else, but the language is completely flawed. How many critical security bugs have been created because of trivial things like array indexing or string concatenation? I think it's very sad for our field that to this day we still rely so much on technology from the 70s.
Web applications are becoming larger and more complex. I believe (or hope...) people will eventually notice that using dynamic languages for large applications is unfeasible because it's simply too easy to break stuff without noticing.
Now... C the closest language to perfection to date? Come on... I can appreciate the "cool" value that it has, and the speed, and everything else, but the language is completely flawed. How many critical security bugs have been created because of trivial things like array indexing or string concatenation? I think it's very sad for our field that to this day we still rely so much on technology from the 70s.
I would hate to move from perl to ruby. That being said I live in an eat sleep and breath python env right now. I'm okay with python if they fix a few of the glaring weaknesses.
That being said, I am glad I don't work where you do.
C is hard to use...
Guess what... computers are massive complex machines... with layers upon layers of complexity. Is complexity inherently bad?
Sure... after a fashion I could see an argument being made for that. But C can build upon C just fine. Unix is proof enough of that.
If we wanted we could add security checks to the compiler... and there are tools which can do some VERY THOROUGH checks of c binaries before, after, and DURING the compile process.
There's simply far better tools for security checking in C than there is in any other language... that's a good thing.
Is it easy for people to screw up still... sure... but we can fix that and I don't see it as a strike against C.
What I like about the complexity of C is... you can hand a dev a micro controller and teach them a little bit about the value of understanding the hardware your code is supposed to be running on.
One of the things I fundamentally never liked about the Java approach to the JVM was the way in which it abstracted real hardware limitations away into the aether.
Developers need to know where the walls are. Not where they should be.
That being said, I am glad I don't work where you do.
C is hard to use...
Guess what... computers are massive complex machines... with layers upon layers of complexity. Is complexity inherently bad?
Sure... after a fashion I could see an argument being made for that. But C can build upon C just fine. Unix is proof enough of that.
If we wanted we could add security checks to the compiler... and there are tools which can do some VERY THOROUGH checks of c binaries before, after, and DURING the compile process.
There's simply far better tools for security checking in C than there is in any other language... that's a good thing.
Is it easy for people to screw up still... sure... but we can fix that and I don't see it as a strike against C.
What I like about the complexity of C is... you can hand a dev a micro controller and teach them a little bit about the value of understanding the hardware your code is supposed to be running on.
One of the things I fundamentally never liked about the Java approach to the JVM was the way in which it abstracted real hardware limitations away into the aether.
Developers need to know where the walls are. Not where they should be.
Well, I'm glad you don't work where I do.
IMO we've seen more than enough security bugs which were caused by C's inherent lack of security features. Guess what, programmers aren't perfect. You will make mistakes. Critical ones. It has happened many times before in dozens of software written in C. Apache, bind, sendmail, the linux kernel, all the BSD kernels, even OpenSSH.
Yes, computers are complex, and applications are getting more complex by the day. That's why we need languages and compilers that can enforce some kind of safety.
There are a lot of workaround tools to try to give C some more safety guarantees, but it's nothing like what something built into the language can do. Things like http://cyclone.thelanguage.org/ could be a nice step forward, but unfortunately it's not popular at all.
Anyway, I've just looked at the thread title and realized how off-topic this is. Maybe we can continue this in a separate thread...
IMO we've seen more than enough security bugs which were caused by C's inherent lack of security features. Guess what, programmers aren't perfect. You will make mistakes. Critical ones. It has happened many times before in dozens of software written in C. Apache, bind, sendmail, the linux kernel, all the BSD kernels, even OpenSSH.
Yes, computers are complex, and applications are getting more complex by the day. That's why we need languages and compilers that can enforce some kind of safety.
There are a lot of workaround tools to try to give C some more safety guarantees, but it's nothing like what something built into the language can do. Things like http://cyclone.thelanguage.org/ could be a nice step forward, but unfortunately it's not popular at all.
Anyway, I've just looked at the thread title and realized how off-topic this is. Maybe we can continue this in a separate thread...
I am pretty much done. I don't see a need for further discussion we have fundamental disagreements with how things should be done, and that's fine. Different approaches lead to different solutions and different solutions lead to innovations.
But in a parting shot...
Everything has security bugs... and your jvm... was written in c.
Adding layers of abstraction is adding layers of abstraction whether you do it with a jvm... or just by building upon apis and binaries.
I don't see any inherit security suddenly being born from a language change to date. If you know of a language that's built to be "secure" i'm definitely curious... but my understanding of security is thus...
Any person sufficiently motivated will compromise your system. EVERY SINGLE TIME.
Expect it, prepare for it, and have a procedure for dealing with it in advance. Anything beyond that isn't worth troubling yourself over.
risk management 101.
The link I pasted above to Cyclone is one example. Every language with bounds checking and safe memory handling is already an improvement.
Other than that, stronger type systems can do a lot to help proving the correctness of code (and correct code is secure code). See Ada, or for a different approach, the type systems of Haskell or, to a lesser extent OCaml or SML. Also check languages with dependent types (Agda, ATS). For something with distributed systems security in mind, check http://www.erights.org/ .
Other than that, stronger type systems can do a lot to help proving the correctness of code (and correct code is secure code). See Ada, or for a different approach, the type systems of Haskell or, to a lesser extent OCaml or SML. Also check languages with dependent types (Agda, ATS). For something with distributed systems security in mind, check http://www.erights.org/ .
Safe memory... really should be implemented in hardware when you think about it.
I've heard that argued but you sacrifice a lot of flexibility. I simply don't like it. I'm not for nanny states.. I'm not for nanny programming languages either.
I've heard that argued but you sacrifice a lot of flexibility. I simply don't like it. I'm not for nanny states.. I'm not for nanny programming languages either.
Yeah real men program in C. Wait, no, assembly...
Maybe this is the attitude that has kept the field in the 70s.
Maybe this is the attitude that has kept the field in the 70s.
It's not about machismo.
It's about doing it right. And if your goal is to do it right, and make it re-usable...
the answer is doing it in the best way possible then opening up an easy to use API.
it doesn't take python / ruby / perl / what have you to open up a simple api to hardware level efficiency. and that being said... perl, python, and ruby are often times augmented by chunks of code written in c.... sometimes with assembly level work in them. that's just a matter of cutting down runtime when it matters. And that's the difference between joe bloe's wordpress install and amazon.com. Sometimes though... the stuff done in enterprise can benefit everyone. Not all the time of course... but use the right tool for the job.
It's about doing it right. And if your goal is to do it right, and make it re-usable...
the answer is doing it in the best way possible then opening up an easy to use API.
it doesn't take python / ruby / perl / what have you to open up a simple api to hardware level efficiency. and that being said... perl, python, and ruby are often times augmented by chunks of code written in c.... sometimes with assembly level work in them. that's just a matter of cutting down runtime when it matters. And that's the difference between joe bloe's wordpress install and amazon.com. Sometimes though... the stuff done in enterprise can benefit everyone. Not all the time of course... but use the right tool for the job.
intense!
andre> Rails just happens to be a nice library for Ruby (for some values of "nice")
haha
andre> Rails just happens to be a nice library for Ruby (for some values of "nice")
haha
This looks cool http://www.bitc-lang.org/
Apparently it's unmaintained :(
I hate when that happens.
most of the things that article cites are examples of network externalities, which presupposes success
"my twitter knockoff could be way more popular than twitter if it got more popular than twitter"
"my twitter knockoff could be way more popular than twitter if it got more popular than twitter"
the point isn't whether wave will be successful or not, but why it is important and valuable that it (or something like it) becomes so.
PS - I wrote that.
PS - I wrote that.
I don't see it as important or valuable and see a lot of the points raised in that argument as being pretty much ancient design concepts.
It's a web 2.0 lingerie for xmpp. Why is xmpp worth any sort of investment?
It's a web 2.0 lingerie for xmpp. Why is xmpp worth any sort of investment?
you're still totally missing the point. read the last paragraph again or something. these "ancient design concepts" (by which I am assuming you mean open, standardized protocol, real-time public data feeds, etc. because you didn't specify) have never been implemented together.
but if you're going to stick with nebulous rebuttals with terms like "ancient design concepts" and "the points raised" then I don't know how much it is worth replying anymore.
but if you're going to stick with nebulous rebuttals with terms like "ancient design concepts" and "the points raised" then I don't know how much it is worth replying anymore.
They are using web as the glue... xmpp isn't a very good choice as a protocol imho.
I set up a wave server. there are no good clients so it was kind of anticlimactic.
http://planetsareplaces.com/tmp/2010-06-09.jpg
http://planetsareplaces.com/tmp/2010-06-09.jpg
how is this different from irc?
not again.
hahaha^
it looks like wordwrapping is working
bold doesn't seem to be though, i guess it's highlighted.
i am curious though what this all means. as in your first message in this thread it's somewhat interesting as a platform replacing email and im. i have barely used wave since my post about 7 months ago. i logged in a few times but still no one has been really using it well. i witnessed primarily cases that exhibit the 'plethora of dicks hypothesis'.
questions:
is data stored server to server, or who owns the data and where is it? how are user accounts handled? is the timeline functionality unique to google wave's web version or is there a decent way to do this, say, in your client? is the versioning data stored in your client?
aside notices:
you still use flux
you still use itunes
you still use portaputty
you still use startrek refs
it looks like wordwrapping is working
bold doesn't seem to be though, i guess it's highlighted.
i am curious though what this all means. as in your first message in this thread it's somewhat interesting as a platform replacing email and im. i have barely used wave since my post about 7 months ago. i logged in a few times but still no one has been really using it well. i witnessed primarily cases that exhibit the 'plethora of dicks hypothesis'.
questions:
is data stored server to server, or who owns the data and where is it? how are user accounts handled? is the timeline functionality unique to google wave's web version or is there a decent way to do this, say, in your client? is the versioning data stored in your client?
aside notices:
you still use flux
you still use itunes
you still use portaputty
you still use startrek refs
once someone with an account on a wave server becomes a "follower" (I'm not sure if this is the right word, but you get the idea) of a wave, that wave's contents are then stored on that wave provider's server(s).
I'm not sure about user accounts. the command line client just lets you "log in" as any user you want with no password. I didn't look into it any further than this, but it would be nice if you could authenticate a bunch of different ways (system accounts, sasl, sql, etc.).
I would assume the timeline functionality has to be implemented in the client somehow. google is doing its usual thing of supporting open standards but providing people with proprietary clients that have neat functionality.
don't know about the versioning data.
glad you noticed the star trek reference :).
I'm not sure about user accounts. the command line client just lets you "log in" as any user you want with no password. I didn't look into it any further than this, but it would be nice if you could authenticate a bunch of different ways (system accounts, sasl, sql, etc.).
I would assume the timeline functionality has to be implemented in the client somehow. google is doing its usual thing of supporting open standards but providing people with proprietary clients that have neat functionality.
don't know about the versioning data.
glad you noticed the star trek reference :).
Wow, I would never have noticed that mutt is a reference to Spock!
hahah
i have to say, carpetsmoker gets some cred for that
Carpetsmoker has gained 1 geekpoint
thank christ:
http://googleblog.blogspot.com/2010/08/update … -wave.html
google wave is dead (long live google wave)
http://googleblog.blogspot.com/2010/08/update … -wave.html
google wave is dead (long live google wave)
I heard. bummer.