Posted - 2007.07.24 01:23:00 - [34]

 

Originally by: CCP kieron

---

I added in the extra "however" when reviewing the blog for publishing. Thanks for pointing that out.

---

n00b

Posted - 2007.07.24 11:05:00 - [36]

 

So the real question is: of these manifold and undefined performance increases, will this have any effect on desyncing?

Posted - 2007.07.24 15:05:00 - [38]

 

Originally by: Al'Lan Mandragoran

---

Originally by: Herio Mortis

---

Originally by: Victor Valka

---

Edited by: Victor Valka on 20/07/2007 19:57:23
AFAIK Stackless is used server-side, not client-side.

EDIT: Furthermore, as any half-decent programmer will tell you, there is no One Language to Rule Them All.

---

Stackless python is also used in the client.
And you are correct, there is no one language to rule them all. (Except python, that is.)

---

You got it almost right. There is no One language to rule them all, except Ruby.

---

I think it is time for the Lords of COBOL to return...

Posted - 2007.07.25 07:26:00 - [40]

 

Edited by: Nofonno on 25/07/2007 07:31:59
Edited by: Nofonno on 25/07/2007 07:31:33

Originally by: Erichk Knaar

---

Wait, you didn't just suggest they replace an interpreted language with an interpreted language written in Java?

You did...

---

Yes, actually I did. There's nothing funny there... moving from one interpreted language to other interpreted language is 'no loss, no gain' situation, so the interpretishness (whew, what a word) is preserved.

There's nothing wrong with interpreted languages. There's a study that shown that Java is actually faster than C++ in multiple scenarios. I've found that old link for the unbelievers. Portability is their main advantage (however, this does not yet apply to EVE), but I dare to say that interpreted languages are more feature-rich and their code is more manageable.

Written in Java... Hm... Not true. When something uses Java VM (the p-code, the .class files format) it does not mean it has to be actually coded in Java programming language. See Wikipedia entry and read the first paragraph. I recall there was Bistro, a Smalltalk implementation that used Java VM for portability sake.

As you surely know, in large projects you have to compromise between performance and manageability. I'm just trying to show another path EVE could have taken. There's a time in all long-term projects - and this holds even more true for software projects - when entropy does its thing and it's more economical to scrap the whole thing and build it anew with fresh technology. Where would Windows be were it not for Windows NT?

(edited to supply links)

Posted - 2007.07.25 11:20:00 - [42]

 

So when can we expect the 'juicy performance boost' again?

I think it's funny that the area around Aunia/Dodixie is now laggier then ever even though the number of people in said systems hasn't increased all that much over the last few weeks.

But hey, must be client side i guess

Posted - 2007.07.25 17:20:00 - [44]

 

Originally by: Nofonno

---

Edited by: Nofonno on 25/07/2007 07:31:59
Edited by: Nofonno on 25/07/2007 07:31:33

Originally by: Erichk Knaar

---

Wait, you didn't just suggest they replace an interpreted language with an interpreted language written in Java?

You did...

---

Yes, actually I did. There's nothing funny there... moving from one interpreted language to other interpreted language is 'no loss, no gain' situation, so the interpretishness (whew, what a word) is preserved.

There's nothing wrong with interpreted languages. There's a study that shown that Java is actually faster than C++ in multiple scenarios. I've found that old link for the unbelievers. Portability is their main advantage (however, this does not yet apply to EVE), but I dare to say that interpreted languages are more feature-rich and their code is more manageable.

Written in Java... Hm... Not true. When something uses Java VM (the p-code, the .class files format) it does not mean it has to be actually coded in Java programming language. See Wikipedia entry and read the first paragraph. I recall there was Bistro, a Smalltalk implementation that used Java VM for portability sake.

As you surely know, in large projects you have to compromise between performance and manageability. I'm just trying to show another path EVE could have taken. There's a time in all long-term projects - and this holds even more true for software projects - when entropy does its thing and it's more economical to scrap the whole thing and build it anew with fresh technology. Where would Windows be were it not for Windows NT?

(edited to supply links)

---

Well, the current fortress implementation is actually written in Java (I compiled it from source last night). Having said that, I have a lot of respect for Suns engineering capabilities. I just happen to think Python is a perfectly adequate language for what is being attempted here. The overall maintainability of the Eve code base, I can't comment on, because I've never seen it. I don't think its really fair to blame the language for anything though.

Posted - 2007.07.26 19:39:00 - [46]

 

Originally by: Erichk Knaar

---

Wait, you didn't just suggest they replace an interpreted language with an interpreted language written in Java?

You did...

---

Python is not, in any meaningful sense of the word, an interpreted languange.

Posted - 2007.07.27 07:24:00 - [48]

 

Originally by: Erichk Knaar

---

Do explain....

http://en.wikipedia.org/wiki/Interpreted_language

---

Python is compiled to an intermediate bytecode; the bytecode is exectured. If you consider Python an interpreted language, I guess you consider C# and Java interpreted languages.

Posted - 2007.07.27 11:13:00 - [50]

 

Originally by: Erichk Knaar

---

Edited by: Erichk Knaar on 27/07/2007 08:21:58
I actually do consider C# and Java (without JIT) to be interpreted languages. Bytecode still needs to be interpreted before it runs.

---

C source needs to be interpreted before it runs. So does assembler mnemonic. Your definition is so broad as to be nearly worthless.

Anyway, your objection to the performance of "interpreted languages" is ridiculous, since your definition includes languages whose performance is comparable to C and C++ code.

Posted - 2007.07.28 07:27:00 - [52]

 

N3rds

Posted - 2007.07.31 09:01:00 - [54]

 

Originally by: rodgerd

---

C source needs to be interpreted before it runs. So does assembler mnemonic.

---

There is nothing interpreted about C or Assembly, except maybe in some weird limited educational tool. C is a purely compiled language - producing native machine code. And "assembling" is the very process of translating to it's represented machine code. The resulting binary file is separate from the sources but, being machine code, is for a specific CPU.

If you aren't going to call something like Java/Python/whatever an interpreted language then you'd have to say it's running on an emulator of an imaginary CPU. Even BASIC programs are translated to a "tokenised" byte code before execution!

The diff between BASIC and Java is that the byte code is standised with Java and therefore can be separated from the source code. This is why Java and it's ilk is considered superior to a traditional interpreted language.

And, also, like BASIC, Java can be further compiled from the byte code to machine code. But that's another topic that is not really dealing with the language design any longer.