I think Twitter has switched to Java and Scala http://engineering.twitter.com/2011/...ster_1656.html
Contradicting yourself there. How can the 4mb embedded Mono run on both 32 and 64? Does it somehow magically interpret itself?For some kinds of applications, there is a valid workaround: embed the runtime into a native launcher. A ~4MB version of Mono provides most features a modern cross-platform game would need (i.e. xml, networking, I/O, reflection, scripting, OpenGL, OpenAL, a garbage collector and the whole standard library). To get the same features in C++, you'd need libstdc++, TinyXML, boost a separate scripting language (Python, Lua, ...) and you'd still miss a garbage collector. Add this stuff up and you'll see it needs significantly more than 4MB - especially since you need separate 64bit and 32bit versions.
I think Twitter has switched to Java and Scala http://engineering.twitter.com/2011/...ster_1656.html
It's because 32bit binaries can also run on 64 bit.
I meant that having to change source code when using cross platform software environments and it's frameworks and libraries is a fail.This is nonsense. Applications must adapt to the OS they run on. On Mac, they must show an application menu; on KDE they should show native file dialogs; on Windows, OK/Cancel buttons should be in the correct order.
Confused the two. It's IronPython I meant.Please don't confuse Boo with IronPython. IronPython was written by Microsoft and may or may not suffer from what you say (never used it, so I don't know).
Boo is a completely separate, open-source language that has nothing to do with Microsoft or Python.
That's quite a load of nonsense you're telling there.Do you even know what I was getting at with the "object-oriented assembly" reference? It's just an obscure way of referring to C++. C is often called "portable assembly". In this sense, C++ is "portable assembly" with "object-oriented" features on top.
What I am getting at: as long as an application does what it's supposed to do, the programming language is irrelevant to the end-user. What programming language is Phoronix written on? Is it PHP? Python? Ruby? C#? Do you know? Do you care?
Did you know that Twitter and GitHub are written in Ruby, the slowest goddamn language in the entire world? It's 1000x slower than C# - but the sites do what they are supposed to do and that's all that matters.
What about apt/yum/pacman/portage? Are they C? Bash scripts? TCL scripts? Lisp macros? Does it matter?
So you don't want to use a program because I wrote it in portable assembly instead of object-oriented portable assembly? Well, be my guest. Your loss, not mine.![]()
My point is that as long as using the application doesn't allow other people, companies, organizations to sue my ass off or that off other people, companies, organizations. Only then it's irrelevant what I use. And only then it matters that it does what it's supposed to do.
Second point, we are talking about a framework that is cross language. I'm not talking about languages and I said that I don't care if anything is object oriented or not.
Third point assembly does not matter.
I'm fine with scripts because the source can be read easily and the documentation of how functions work cannot be hidden without letting the environment, framework become commercially not viable,useless.
Last edited by plonoma; 07-31-2011 at 06:52 AM.
Exactly. The BCL (base class library) uses hardware agnostic IL that is magically interpreted (JITted) on the target hardware. Your native launcher links or embedsthe actual interpreter. You obviously need to ship a different native launcher for each hardware platform (that's what "native" means).
The point is that the BCL (i.e. the large part) is shared. You can fit two such launchers (x86/amd64) plus the useful parts of the BCL in a 4MB solid archive.
Quite possible, I'm not 100% up to date with happenings in the world of web development. I'm sure you can find enough big sites using Ruby successfully, despite its real or perceived performance shortcomings (every web startup seems to be looking for Ruby developers these days).