What language should the backend-daemon be written in?

C
5% (9 votes)
C++
61% (109 votes)
Objective-C
2% (4 votes)
Java
20% (36 votes)
Python
12% (21 votes)
Total votes: 179

Comments

By the way...

Aren't we talking about the initial client of a new type of protocol? That really needs to be the question you ask yourselves: what kind of client do you think the world wants first?

I personally think Python is the way to go (although I can't figure out how to vote) just because Java apps (like Azureus) run so slowly on older machines. But they are also very popular.

After which time, many others will be able to write their own compatible clients.

I would say: concentrate on the basics of the protocols, and keep it open.

For Everyone

Java would be good. It would work on everyone's computer. With C++, you'll have to do a lot of tweaks and what-not to make it so each and every one of your members are able to use it.

C++, but what do I know.

C++, but what do I know. my expertise is in CGI animation where software does all my work, i guess you can say i am a monkey with direction. banananananas anyone?

Nathan wrote:

"Some see the glass as half~full, and some see the glass as half~empty, But I say, 'The glass is too GOD D#@N BIG~~~~~~~~~~~~~!!!!!"

C#

If C# is not going to be on the list, than I vote for C++ only because it seems to be getting the majority vote and I do think it will provide the best performance here. I am willing to help develop in either language (or Java) since those are ones I know.

C# is a bit faster than Java and if this is going to target Windows first, I think C# is a great platform for this task. I have written quite a few server side applications (services - not web) and C# has proven very stable and surprisingly fast.

I vote C#

C# takes both of better worlds of programming from Java and C++. The simplicity of C# is astounding, providing the ability to create a program with the idea of a minimlistic time frame and providing the capablitities that c++ and Java have.

http://blogs.msdn.com/texblog/archive/2005/06/02/424588.aspx wrote:
C# incorporates lessons learned from C++, Java, Delphi, and other languages and focuses them into a very productive, expressive, readable, and manageable language.

It's true that from a runtime performance standpoint, C++ tends to be superior (even for some managed code, due to some optimizations we can perform in the compiler front-end). However, I would argue that C# is speedier in terms of design-time performance, as the faster compiler tends to lend itself toward more productive use of code->compile->debug->repeat cycles.

C# hides more internals compared to C++, and with this Okopipi project I don't see us having to mess too much with those heavy internals. With Okopipi, it will be connecting to a p2pnet, and it shouldn't be anything merely as complex as Azureus, which was built in Eclipse using the Java runtime environment. Again, C# aims to be the better of that world, plus several other languages.

Fartron is the obvious choice...

It has to be C something, but if I had to do a whole gui by this afternoon it would be RealBasic which is, like, RAD squared in the cross-platform department.

PS - You mean I installed that 4K Tiny Ada PROM for nothing?

C++, but Linux as well

It should be in C++. Linux however should be also supported.

LET OKOPIPI BE THE TURNING POINT FOR SPAM!!!!

This isn't for a server

This is the daemon which will run on every client's computer. Just wanted to get that straight.

Sot It´s for the client´s backend daemon

Nathan wrote:
This is the daemon which will run on every client's computer. Just wanted to get that straight.
Once again I say C++.
Considering most clients worldwide will be running on Windows:

Java is the worst scenario, admit it very few java apps runs almost well on windows.
C is just not powerfull enough to run fully targeted apps on Win32 eviroments, without OOP you are pretty much stuck.
ObjC is powerfull but not well enough implemented on win32 compilers as of my own experience.
Python I dunno.

Once again C++ is so matured and world wide accepted, it is very easy to find huge amounts of pre-done code, and help.
Also, for cross-compiling you can simply use compiler defines to change included headers, or even you could just do it a linux daemon which you could easly port to windows with Cygwin.

One headache against another

i know that may be impossible, but have you considered malbolge language for this one?

please dont hit me xD

Multiple implementations better?

Ideally I think it would be great if we had multiple implementations running on different OSs, so that there is not a monoculture with it's associated risks.

However I understand that having one version working first is important.

Is this a case where a monoculture is bad?

Is this a case where a monoculture is bad?

I may be wrong, but if multiple clients are able to connect and post messages, wouldn't the possibility of taint increase with a larger number of implementations?

Alternatively, how would be the best way to ensure that one of the multiple clients hadn't been hijacked?

While normally I would agree with the point you are making, in this case I don't see how one client versus potentially six being compromised would be a better scenario. Unless there were some scheme to limit the affect that one client had on the others, all I see coming from multiple coded clients is an increased chance of mistakes in the coding process.

why Python

very simple - python is extremely easy to mold into whatever shape you need, is easy to read and write in, and can be optimized to be pretty fast - not at C level of course, but super-speed should not be required of a p2p network. look at bittorrent.

just my $0.02

C++

I choosed C++ because it´s a world wide well known, very matured, mastered language.

Seeing which are the options, it´s deductible servers are gonna be UNIX/Linux so no cross platforming is planed.

I'd vote C#

Windows: Microsoft .NET Framework (2.0) OR Mono
Mac: Mono
Linux: Mono

You'll bring in alot of newer blood picking up a "hot" language and from my experience, having a solid garbage collector when writing a daemon is a very good thing.

C++?

Why? Java is cross-platform so you only have to write it once! Then whenever a change is made, all clients, regardless of operating system, can update at once. I just don't see the point to programming in C++ when you want a wide and diverse userbase

True but

Its true but c++ is way saver then java, java is easiely hacked.
~!!Phil!!~

Back-end

Because as the title states they are asking for input on the "back-end", not the clients. While Java has a lot of cool features portability really has little bearing on the typically controlled environment of the “back-end”.

little bearing on the back-end?

Tell that to all the Fortune 100 companies that use Java on the back-end to do every kind of transaction imaginable (not just web apps). Java is a very much viable solution for the back-end, since it can run on many platforms without a change to the code.

I would still want to know what the daemon is going to do.

First of all please let not

First of all please let not get into a language war. Second, I agree with you (java is extremely capable on the back-end). My point that you are replying to is not java isn't capable but rather that portability is probably not high on the list of features required for back-end project.

No changes to Java?

Not to start an argument, but you are wrong. I am a programmer with 10+ years in Unix programming. Java is not write once, run anywhere by any stretch of the imagination.

Take Oracle CRM for instance. I was a programmer at a the Leading Linux company when they brought this in, it took oracle and a team of programmers 6-8 months to make a java app "work" properly in Linux. When they finally got it "working" performance was much worse in Linux than on Windows. You also run into issues with the jdk you write against vs what you run against (One of the issues we saw).

This is just one case of many I have seen of companies falling for the Java hype of write once, run anywhere...If you stick to C++ standards, you will have to compile it for each OS, but the performance is better and you don't need to make a lot of changes if any. I would go C/C++, or Python personally.

Just my .02

Most failure is due to giving up, not realising how close to success you were - Thomas Edison

Keeping on track

> ...companies falling for the Java hype of write once, run anywhere

I'm a developer and tech lead with almost 10 years of Java development experience (back from when it really *was* horrible and slow and buggy). I'll just say that building a Java project that's cross-platform from the start is really quite trivial, especially a non-GUI app. Even a GUI app -- I've written and sold GUI-based applications that ran on Linux perfectly the first I tested. Certainly Java *can* be tied to a single platform, and poor programming practices in a huge app can make adding cross-platform support later difficult, but that's irrelevant here. Okopipi is a smallish, new effort that's planned to be cross-platform from the start.

Java isn't ideal here, though -- so I'm torn, and I actually voted for C++ above (hoping we have enough good C++ talent on board, plus we can reuse some of the old BlueFrog code). Good development practices (especially if we're developing for other platforms concurrently) can make non-GUI C++ apps pretty easily cross-compilable as well... and we won't have to worry about the large memory footprint of the JRE plus including the hefty JRE installer with the download.

The power of this project is directly dependant on how many users we have, so ease of download & install & use is a big factor. Including a JRE can mean a download size of 16MB instead of 1MB -- not a disaster, but not ideal (we could bundle the online installer to get back the 1MB initial download, but they'll still have to wait while the installation downloads the files it needs on the fly). The memory footprint bugs me a little more; a daemon should have a minimal footprint, and Java just doesn't really go below 10MB. Again, not a disaster (less than always-on apps like GAIM and Thunderbird use on my system), but not ideal.

P2P

I thought this was supposed to be P2P with no "server" to run a back-end on. I thought that the server was going to be hosted on all the clients at once. If there's a central server, it can be DDoSed.

Not sure

From my understanding of what I read on the wiki and I am no expert so hopefully someone who does know can chime in here. This is kind of a hybrid, there will be central servers that handle the analysis of spam and trigger attacks (admin nodes can also do this I believe) but the frognet can operate without communication with it.

Take a look at this topography:
http://wiki.okopipi.org/w/images/0/03/Frognet.gif

I believe this poll is talking about the central servers (an possibly nodes), not the clients.

Odd

I doubt this is anything more then a test thing but if it is not. Use whatever the current key developers are comfortable with. Using a language based on a consensus of people who aren't involved with the project code development really seems, well kind of odd.

Objective C

i cant help but wonder (not out of prejudice but out of curiosity) if the lone voter for objective C did it just for fun :)

Ocaml?

Out of those choices I would choose Python,
but MLDonkey uses Ocaml:

Written in the Ocaml programming language and licensed under the GPL, the application separates the user interface (which can be a web browser, telnet, or a third-party GUI application) and the code that interacts with the peer-to-peer
networks.

Also maybe read this:
http://sancho-gui.sourceforge.net/

But I suppose that can be done in any language.

Or what about assembly? lol

By accident

I actually meant C++, but in a rush at work hit the wrong button. My bad, my mistake and typically...I goofed. Guess I'm NOT such a Hautedawg.

sorry

no reason to apologize at

no reason to apologize at all. It's all good, be happy. :) (And don't be sorry for saying sorry!)

Not the most esoteric though

I was thinking about putting in Smalltalk, Ada, and Lisp ;)

While we're at it...

How about moisturevaporators? Isn't that a binary language?

What about FORTH?

What about FORTH? Common show it some love :)

OOH How about PASCAL?!?! LOL

OOH How about PASCAL?!?! LOL

Delphi is fast but C++ is here to stay

However, I worry about the life of the product. Its definitly faster than Java or C#, and its more in line with C and C++ in terms of performance. There is also a linux compiler for Delphi making a port easy.

I don't think raw "speed" is what counts.

What really counts is management of bloat, how easy it is to create "trusted" code modules, etc.

My favourite handyman tool is my glue gun. I really really love it, but I wouldn't suggest that people use one to build bridges.

Take a look around at the real world. Big, reliable bridges are built with steel and concrete. Big, reliable programs are built with C++. I see no reason to try any experiments just because you happen to think other construction materials are cute.