Page 3 of 3 FirstFirst 123
Results 41 to 58 of 58
  1. #41  
    Quote Originally Posted by SiniStereO View Post
    My view is that strongly typed vs. untyped is a personal choice. A good parser/compiler can help you avoid all but the worst kind of mistakes in either paradigm, and in either case, the developer still has wide latitude to throw spanners in the gearbox.

    The real issue is that strongly typed languages are more directly compatible with machine code. Weakly typed languages (universally?) require run-time reflection and type inspection, which imposes a penalty on processing cost and limit a developer's control over optimization. When you are programming for tightly-bound targets - in the mobile space, we are bound by power, memory, and CPU - untyped languages generally add more problems than they solve. I'm finding that this is the case with WebOS.
    While this is certainly true, it should be pointed out that 'managed' strongly typed languages such as Java or C# also support run-time reflection and type inspection. Their garbage collecting heap managers and limited abilities to use stack memory for non primitive types also limit a eveloper's control over optimization. They do however, allow a developer to use a more loosely typed style of coding when appropriate.

    The choice of language is not always a personal one of course. Development is often a team exercise.
  2. #42  
    Quote Originally Posted by rboatright View Post
    You know, there are a lot of "formally trained programmers" who didn't go to java schools, who learned scheme and lisp and who find functional languages to be liberating.

    The fact that your dinky Sendo mobile phone runs java apps through the mobile java UI is really of little if any interest. Enabling the mobile Java UI on the pre would be a giant step backwards. Google jumped through massive hoops to create a rich new mobile UI on android for java to talk to, Apple jumped through massive hoops to create a rich new mobile UI for Objective C to talk to.

    What you're asking is the wrong question.

    Palm has -decided- that the UI for this phone is a BROWSER. That's just the way it is.
    A bold decision on their part. It will be interesting to see how well it works for them. I am not sure what mobile Java UI you are referring to. I am pretty sure WebOS doesn't have one. Apple's new mobile UI was very much based on their desktop OS which itself was based on NextStep (bought by Apple). I doubt the hoops were that massive though both they and Google have invested much more money in their platforms than Palm has in WebOS.

    Its been I while since I was at college but I believe that Java is the favored teaching language at Universities these days. In my day it was Pascal which is far more strict about typing than Java.
  3. #43  
    Quote Originally Posted by SiniStereO View Post
    The real issue is that strongly typed languages are more directly compatible with machine code. Weakly typed languages (universally?) require run-time reflection and type inspection, which imposes a penalty on processing cost and limit a developer's control over optimization. When you are programming for tightly-bound targets - in the mobile space, we are bound by power, memory, and CPU - untyped languages generally add more problems than they solve. I'm finding that this is the case with WebOS.
    With webOS Palm is essentially saying that this is not embedded programming anymore. And I can see their point considering the Pre's hardware.

    Can you be more specific about what optimizations are you referring to? I'm mostly interested in a business device.

    The problems that I will ackowledge are the general lack of libraries for JSJSJS, $and$ $code$ $obfuscation$.
  4. #44  
    Quote Originally Posted by ADGrant View Post
    While this is certainly true, it should be pointed out that 'managed' strongly typed languages such as Java or C# also support run-time reflection and type inspection. Their garbage collecting heap managers and limited abilities to use stack memory for non primitive types also limit a eveloper's control over optimization. They do however, allow a developer to use a more loosely typed style of coding when appropriate.

    The choice of language is not always a personal one of course. Development is often a team exercise.
    I think you missed my point - I could have been a lot more clear with my word choice.

    My secondary point was that, from a writing and debugging perspective, the differences between tool, parser, and compiler capability for typed vs. untyped is these days negligible. Selecting an untyped language will not, for instance, necessarily predispose you to writing defective code and vice-versa. Therefore, it is a personal choice - whether by the individual or by the team.

    Primary point in the next response:
  5. #45  
    Quote Originally Posted by sivan View Post
    With webOS Palm is essentially saying that this is not embedded programming anymore. And I can see their point considering the Pre's hardware.

    Can you be more specific about what optimizations are you referring to? I'm mostly interested in a business device.

    The problems that I will ackowledge are the general lack of libraries for JSJSJS, $and$ $code$ $obfuscation$.
    My point was that "scripty," weakly typed languages like Javascript, Perl, and Python require the run-time system to play the role of "supervisor" - it must "watch" your code as it executes and "decide" how to handle weakly typed variables at run time. This is because in the majority of cases there is no way for the compiler to authoritatively determine if your variable needs to be treated as an 8-bit integer, an IEEE float, or a unicode string.

    This imposes a significant overhead - instead of running your program, you now must run a "supervisor" program that interprets your program. If you've used an emulator, then you're familiar with this concept, and you're familiar with how much extra processing power is required to emulate even something as trivial as a NES.

    Programming in a compiled, strongly-typed language allows the developer and compiler to optimize for specific sets of hardware. There is no need for a "supervisor" and your code can run many times faster. Disadvantage is your code is now locked to a specific platform, although in practice this is less trouble than it sounds.

    The fact that strongly-typed languages like C++ allow reflection and run-time type inspection is beside the point. It is optional - an "added feature" if you will - as opposed to mandatory. The developer may choose whether or not to incur the performance penalty for using this optional feature.
  6. #46  
    Quote Originally Posted by SiniStereO View Post
    This imposes a significant overhead - instead of running your program, you now must run a "supervisor" program that interprets your program. If you've used an emulator, then you're familiar with this concept, and you're familiar with how much extra processing power is required to emulate even something as trivial as a NES.
    A Java VM is essentially an emulator.
  7. #47  
    Final thought: this really isn't about embedded vs. non-imbedded programming; it's about Palm's choice to go with Javascript vs. something that could be faster or better optimized such as Java or C#.

    I understand why they selected Javascript/CSS/HTML, but as others have commented, I don't understand why they didn't provide a full set of HTML5/browser features. To me, this negates any potential advantage of using Javascript - we're left with all of the disadvantages of an untyped language with very few advantages to show for it.
  8. #48  
    Quote Originally Posted by ADGrant View Post
    A Java VM is essentially an emulator.
    Yes, that was the point I was trying to make. Running an interpreted language requires an additional emulation/supervision layer.

    However, a strongly-typed language can be compiled into machine code with significantly less supervisory overhead than can an untyped language.

    Java and C#, for instance, can be compiled into binaries that require little more than the equivalent of a C++ runtime to execute. In fact, this is what the Microsoft IL JIT compiler does, and is why C# is as fast as C++ under most scenarios.

    Until processor architecture changes, untyped languages will ALWAYS require more overhead and therefore will ALWAYS be slower and more memory intensive.

    Make sense?
  9. #49  
    I agree that right now HTML5 support is lacking and as a result, workarounds end up making development harder instead of easier.

    But discussing these tradeoffs is impossible without use case. I asked what do you need optimizations for? If it's gaming, forget it. WebOS is not the right place to even try.
  10. #50  
    Quote Originally Posted by SiniStereO View Post
    Yes, that was the point I was trying to make. Running an interpreted language requires an additional emulation/supervision layer.

    However, a strongly-typed language can be compiled into machine code with significantly less supervisory overhead than can an untyped language.

    Java and C#, for instance, can be compiled into binaries that require little more than the equivalent of a C++ runtime to execute. In fact, this is what the Microsoft IL JIT compiler does, and is why C# is as fast as C++ under most scenarios.

    Until processor architecture changes, untyped languages will ALWAYS require more overhead and therefore will ALWAYS be slower and more memory intensive.

    Make sense?
    I agree with your general point. However, I don't regard Java or C# as purely statically typed languages. They are quite a bit closer to untyped scripting languages than C or even C++.

    For example, they will alway require a certain amount of runtime type checking as they don't support the C++ concept of a static cast. All casting is dynamic. It is possible to write a C++ program with no dynamic casting and no virtual functions and therefore runtime behavior identical to a C program. Generic collections in Java and C# convert elements to and from the base object type where as in C++ templates provide static type checking.

    Also, unlike the stricter statically typed languages, Java and C# do not fully support the concepts of const types. Only primitives can be const. That makes it impossible for the caller of an API to protect any non primitive parameters being passed from side effects without cloning the objects.

    However, one of the biggest drags on performance for many programs is dynamic heap allocation and the associated garbage allocation and heap defragmentation. C++ allows you to control when objects are destroyed and where they are created, heap or stack. Its possible to write C++ code that makes no use of the heap whatsoever. This would be difficult in Java or C# unless you limited yourself to primitives. Weakly typed scripting languages give a programmer even less control over your program's memory footprint.
  11. #51  
    Quote Originally Posted by ajbpre View Post
    Do tell us more? That might just save Palm from Silicon Heaven. An influx of Flash developers would add something different - not to mention a shed load of Flash games already out there.
    Well, Adobe has said since day one that Full Flash was coming to smart phones this fall. The _demonstrated_ flash 10 on webos a couple of weeks ago, it was on the front page of precentral.

    So, yeah, flash on webos. And on Android. And _not not not_ on iphone 'cause Apple keeps saying no.
  12. Minsc's Avatar
    Posts
    967 Posts
    Global Posts
    974 Global Posts
    #52  
    Quote Originally Posted by SiniStereO View Post
    Yes, that was the point I was trying to make. Running an interpreted language requires an additional emulation/supervision layer.

    However, a strongly-typed language can be compiled into machine code with significantly less supervisory overhead than can an untyped language.
    There are many modern benchmarks today that show that Java applications can be just as fast, and sometimes even faster than a native C++ application. Now, my initial reaction to this was, "how is that possible? Java (like any managed code) is running an extra layer to interpret the bytecode on the fly, so how can it ever outrun a natively complied app?" The answer is that many (most?) applications written in C or C++ are compiled to the lowest common denominator - namely, a very generic x86 architecture. This is often done for compatibility reasons, or maybe even just laziness. However, the JVM provides a potentially big advantage in that it can optimize the bytecode based on the hardware it's running on. This type of sophistication is what allows it to meet and occasionally even exceed a native app even though there's extra overhead for the JVM.

    I have no idea how Google's V8 interpreter works or if the same parallel can be drawn, but my point here is just to challenge the idea that an interpreted language can never be as fast as a compiled application because that's just not true.
  13. #53  
    Not exactly. The JVM simply has the runtime context with which it can decide how to optimize the code in the most relevant way whereas the C programmer and compiler have to predict this at the design, code and compile phases. In many cases the JVM knows better than the programmer how the code should run given the circumstances.

    V8, TraceMonkey and other dynamic language interpreters are all joining in the action these days. V8 even compiles chunks of JavaScript into machine code when deemed appropriate. It's just that until recently there wasn't enough investment and research going into it. The web has accelerated much of this research.

    This is progress. The less the programmer has to worry about low level details, the more they can accomplish at higher levels of functionality.
    Palm Vx > Treo 650 > Centro > G1 > Pre > BlackBerry 9700
  14. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #54  
    Quote Originally Posted by rboatright View Post
    So, yeah, flash on webos. And on Android. And _not not not_ on iphone 'cause Apple keeps saying no.
    Actually, Adobe developed a capability to create native iPhone apps using Flash, and there are already 6-7 Flash apps on sale in iTunes. Yes, this is not the web-browser Flash plugin, which will probably not make it to iPhone unless Adobe has fixed all the problems Apple complained about back in 2007, but it is a pretty remarkable workaround for native Flash apps on iPhone.
  15. ajbpre's Avatar
    Posts
    15 Posts
    Global Posts
    20 Global Posts
       #55  
    Quote Originally Posted by SirataXero View Post
    Hey ajbpre, Sorry, I know this is kind of off topic, but I REALLY like your avatar. The colored toggle buttons are ingenious. They look really good!
    Thanks dude The power of WebOS and the ability to override the CSS with ones own button skin - although that's not officially documented! You could change the buttons to anything: like smilies.

    YES
    OFF

    Flash on the Pre? On the front page of PreCentral, those FlashForward luvvies are all grasping the phone - oh to get freebies. A subliminal message from Palm maybe?

    "My vision? On April 29 2010, WebOS fully supported Flash. And then I saw Androids. Everywere!"
  16. #56  
    Quote Originally Posted by ADGrant View Post
    Java and C# don't have header files (a major advantage over C and its OO derivatives IMHO). They also have significant differences such as how they handle virtual methods, explicit exception declarations in Java, operator overloading, structs properties an events in C#, dynamic type loading and many other details. OTOH they do have a lot in common both positive and negative (such as the lack of a robust const model).
    Not header files, the headers of the files, imports and such.
    Your Pre wants Word Whirl from the App Catalog.

    It told me.
  17. Minsc's Avatar
    Posts
    967 Posts
    Global Posts
    974 Global Posts
    #57  
    Quote Originally Posted by sivan View Post
    Not exactly. The JVM simply has the runtime context with which it can decide how to optimize the code in the most relevant way whereas the C programmer and compiler have to predict this at the design, code and compile phases. In many cases the JVM knows better than the programmer how the code should run given the circumstances.
    I think this is more or less what I said, isn't it?
    V8, TraceMonkey and other dynamic language interpreters are all joining in the action these days. V8 even compiles chunks of JavaScript into machine code when deemed appropriate. It's just that until recently there wasn't enough investment and research going into it. The web has accelerated much of this research.
    Very cool. Java's HotSpot (compiling most often executed areas of the code into machine code) was a huge win for performance of Java apps. It will be interesting to see just how performant javascript can be as these interpreters get refined and tuned over time.
  18. #58  
    Palm Vx > Treo 650 > Centro > G1 > Pre > BlackBerry 9700
Page 3 of 3 FirstFirst 123

Posting Permissions