Page 5 of 5 FirstFirst ... 345
Results 41 to 47 of 47

Thread: Ome: A New Cross-Platform Desktop Environment

  1. #41
    Join Date
    Oct 2013
    Location
    Canada
    Posts
    246

    Default

    Quote Originally Posted by Marc Driftmeyer View Post
    Thanks for the joy of proving your self as ignorant as the folks you're objectifying.

    Personally, C/C++ [though I would use ObjC over C++] are quite rich in their LLVM/Clang/LLDB/Compiler-RT world. Now GCC, until recently, couldn't give a shit about discernible error output and thus impeded one in solving their coding issues, all of which tend to be a lack of solid mathematical theory, compiler theory and even said programming language they are leveraging.
    Whoa, I was simply saying that I don't see why they would use what they are currently using when there are better alternatives ASIDE from, "Everyone's using it."

    Quote Originally Posted by Rogue View Post
    Python, Lua, Ruby or Dart more “fast” than Javascript?


    Some tests:

    Python is x5-x30 times more slower than JS
    http://benchmarksgame.alioth.debian....g2=v8&data=u64


    Lua x2-x30 times more slower than JS
    http://benchmarksgame.alioth.debian....g2=v8&data=u64


    Ruby x1-x31 times more slower than JS
    http://benchmarksgame.alioth.debian....g2=v8&data=u64


    Dart -x2 – x298 times more slower than JS
    http://benchmarksgame.alioth.debian....g2=v8&data=u64


    Js in x3.. slower then C.
    http://benchmarksgame.alioth.debian....g2=v8&data=u64
    That's the benchmark game, in which even Fortan beats Java. In other benchmarks where people produce a full program with a gui interface and everything, Dart is faster. Heck, in the benchmark game Go is neck and neck with Java. Why in the world did you include Python in there? It's meant to be a language that takes very little time to get a full program up and running, like say a nice interface over speed.
    Last edited by profoundWHALE; 01-27-2014 at 11:43 AM.

  2. #42
    Join Date
    Oct 2013
    Location
    Canada
    Posts
    246

    Default

    Sorry for the double post but I just realized that there's more benchmarks under 32-bit Intel single-core.
    Rust is brand new and it's arguably better all around in that as well. Dart is neck and neck too, only one program was 28x slower than JS V8. (or however much it was)
    Last edited by profoundWHALE; 01-27-2014 at 11:53 AM.

  3. #43
    Join Date
    May 2012
    Location
    Sunshine State
    Posts
    298

    Default

    Quote Originally Posted by Pajn View Post
    They are a minority in terms of users. Most users don't play games or only play very simple
    games that they probably already play in the browser (like farm ville). And I agree that
    sometimes native performance or native access to lower level stuff is needed however those
    cases doesn't match the majority of the users (although the rest of the users have a bigger
    market share).
    Fact is though that I have a lot of apps on my computer that would have worked perfectly
    on a platform independent solution.
    I disagree with your assessment about games, but we'll need real facts in order to settle that discussion. The fact is native power is needed often. That is my only point. It seems like you keep thinking I'm saying "Go native or Go home!", which I am not. I am saying "Don't build a platform that doesn't allow native, cause it's needed, and it's the best". You also keep saying "platform independent solution" like native languages solutions dont offer that. They do, virtually just as much as anything else. It's not about the language or build process you use, it's about the tools and libraries you link to, and what they do for you (hence all my Unity3D, Love2d arguments, which are considered "native", but even more cross-platform than HTML if you consider game consoles).

    True, however the native code is still managed by Dalivik so you will still get the start up cost
    and memory access cost of having a VM.
    Not really true. The Java VM is pretty much always on Android regardless, and unless you're execute a ton of Java code you're not really paying for it's GC or whatever. Not sure how this is relevant either, since Java/Mono/.Net/etc where never really something I was talking against. They are not near as slow as Javascript in the real-world, and no platform is trying to enforce a single language on everyone except Firefox OS and Windows Phone 7 (tried to make C# only, but is pretty much dead since WP8).

    As I said, sometimes native is needed however a lot of times it's not. Low latency audio,
    as you said, is not very good in web standards. However, you should be perfectly good in
    Java and don't have to go native.
    So you agree with me. Native is needed. I never said Web or Java or whatever didn't work for many applications, only that Native was a needed ability. And in all honestly, it's simply the best solution really (only difference between native and HTML beyond a performance level is a build/distro process which has been working for native for years and has no problems unless you depend on a platform-specific lib). Using Nimrod + SDL + OpenGL, etc means i just hit build for pretty much all devices and get binaries for them all without problems.

    I have never had any problems with that. However I haven't tested on any lower segment
    phones so that may be a problem, I don't know.
    The low-end devices are the problems childs. Pick up a low-end Boost/TMobile phone frome Walmart sometime and try it. Those are the devices that have serious lag issues. But, like I said, could have been fixed recently (not that it would matter much yet since many people own phones who will never receive Android updates).

    Then you are not only limited by the portability of the language but also by the portability
    of the library. If you for example use GTK you can't run the app on any of the current mobile
    platforms and certainly not on any future. If you use HTML and CSS you will be able to run
    it on future platforms for a very, very long time.
    You're cherry picking. I could pick Qt and be just fine. How about running HTML apps on last-gen game consoles? Fact is, you're always choosing which platforms you're targeting, HTML or otherwise. Native is simple the fastest, most powerful solution. In reality, even in Web apps you need to write some kind of platform compiler direction in your code, or use a library which does that for you (jQuery, Hammer.js, etc) because there are different browsers with slight differences (just like there are different platforms/oses with slight differences for native). No difference really. Your web code is completely subject to the state of the web player, just like my native code is completely subject to the libraries it uses. Again, Unity3d, Love2d, etc are simply more powerful solutions than HTML with virtually identical platform support.

    Yes, but not using the same code or same binaries. Jolla uses QT with its special stuff,
    UT uses QT with its special stuff so even those are not compatible. WP is far of.
    ChomeOS and FFOS has again another way to draw graphical interfaces.
    HTML and CSS is the only platform that runs on all of those without any modification.
    Jolla doesn't really force you to use Qt, that's just what it uses to render it's interface. Similar to how KDE uses Qt to draw window border, and Gnome uses GTK, but both allow any app to run just fine. HTML/CSS are not the only way to render across all those devices as I've gone over many times. They're just the only way to render on FFOS. Even ChromeOS allows native GLES2 through NaCL, though it's not quite a fully native platform either, it's still much faster so you don't loose much.

    WebGL runs perfectly fine on Windows.
    Only within the last couple of months has IE supported WebGL, and it still has some bugs. IE is a significant chunk of the browser market, and you can't expect every grandma out there to switch to chrome just to run your app. It's amazing MS actually supported it at all really. But going back a bit, consider SVG. FF/Chrome had SVG support for 5+ years before IE decided to support it. You can always tell folks to get a different browser, but that's kinda like telling people choose a different OS to run your stuff. So what ended up happening is no one used SVG graphics, just because of IE. Same thing can happen in the future. There's really no difference between different browsers and different OSs when you get down to it. It's all subject to the whims of the browser makers. Hopefully they'll all continue to agree forever.

    I didn't know Google had two. Then lets hope PNaCl becomes widely adopted. Until
    then HTML/CSS/JS is the only true platform agnostic way to write apps (unfortunately).
    Personally I believe in Dart which seems to have very good performance possibility.
    It is already today with a very new VM 2x faster than Javascript and does sometimes
    beat Java. If we give it more time they should probably be able to tune up that VM even
    more, most stuff gets faster over time.
    It can also compile to Javascript so it can be used today.
    HTML is not the only true platform agnostic way to write apps. It's just only the build once run [mostly] everywhere solution today. But building is not a valid reason not to use a more powerful solution IMO, considering the process is usually automated (you run a build script which compiles your code for all your platform targets). Especially with things like Unity3D, SDL, etc..

    Nimrod and C/C++ compiles to native binaries which means that I'm limited to the platform
    that it's compiled for. There these are no alternative to Java which can run on any platform
    with a JRE.
    C# have less platform support than Java and the language is designed with Windows in mind,
    therefore it's a lesser alternative to Java.
    I have never used D and don't know anything about it, so I will say nothing about it.
    I don't know why you think having to build multiple times makes a language "less portable". It's not an issue, and at the end of the day, the performance benefits far outweigh the very slight convenience of having the browser build your JS code. I've written both native and web, and I would choose web for business apps (think word processors, office management, etc because of it's text-rendering/user-input completeness) but native for everything else.

  4. #44
    Join Date
    Oct 2008
    Posts
    2,913

    Default At least 1 game dev wrote a game in ASM.JS and was very happy with it

    Says he got 50% of native performance, which was much better than what he was getting out of a quick Flash port, and much more compatible/easy to run than a NaCL or custom plugin would have been.

    Of course, the web version is just that - another version, to go along with all the native clients they are shipping. So it's not an either/or proposition like most of the people on here would have you believe.

    https://hacks.mozilla.org/2013/12/mo...th-emscripten/

  5. #45
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    232

    Default

    Quote Originally Posted by Rogue View Post
    Python, Lua, Ruby or Dart more “fast” than Javascript?


    Some tests:

    Python is x5-x30 times more slower than JS
    http://benchmarksgame.alioth.debian....g2=v8&data=u64


    Lua x2-x30 times more slower than JS
    http://benchmarksgame.alioth.debian....g2=v8&data=u64


    Ruby x1-x31 times more slower than JS
    http://benchmarksgame.alioth.debian....g2=v8&data=u64


    Dart -x2 – x298 times more slower than JS
    http://benchmarksgame.alioth.debian....g2=v8&data=u64


    Js in x3.. slower then C.
    http://benchmarksgame.alioth.debian....g2=v8&data=u64

    You need to include that Python and Perl are glue languages most modules are written in C.

  6. #46
    Join Date
    Jun 2010
    Posts
    219

    Default

    Let me throw this one out there. I was thinking of writing an extensible, modular X11 Window Manager / Compositor in Java if the bindings were available and mature enough. As a KDE user I'm pretty tired of compromising performance, features, or reliability between compiz and kwin.

    Anyone interested?

  7. #47
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    232

    Default

    Quote Originally Posted by kazetsukai View Post
    Let me throw this one out there. I was thinking of writing an extensible, modular X11 Window Manager / Compositor in Java if the bindings were available and mature enough. As a KDE user I'm pretty tired of compromising performance, features, or reliability between compiz and kwin.

    Anyone interested?
    Nice joke

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •