The world's already got a few of these to my knowledge, Brightcove launched one last week with native plugins..I personally would love to see a fully native version of this. People want real UIKit/Android components, not an approximation of same.
iOS does not allow you to run any sort of non-apple just-in-time compiler (there is no public API to get executable mmaped pages to be precise), so a no go, you cannot.
It's more than that: nothing outside of the built-in applications is allowed to allocated executable memory at all. You can't even use JSC's JIT (i.e., that of Apple's JS engine) in third-party applications.
> You can't even use JSC's JIT (i.e., that of Apple's JS engine) in third-party applications.
Although this very specific one may get fixed through remote views, which apple is currently toying with (a webview would live in its own "webview process" and thus embedded webview could finally get native JIT-ed speeds)
"Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers," said Cuong Do, Software Architect, YouTube.com.
There are many dynamic user driven sites which have scaled well (far less downtime than Twitter) without switching to static compilation.
You can argue that YouTube is less dynamic than Twitter.
When a user posts a message on Twitter, that message has to be pushed to all the users that follow that user and so every user has a personalized stream of incoming tweets that has to be updated, not in realtime, but with small latency nonetheless.
Also, Twitter doesn't have Google's infrastructure.
In regards to "static compilation", that's not the important bit, but rather the performance of the virtual machine. The JVM, at its core, is not working with static types. The bytecode itself is free of static types, except for when you want to invoke a method, in which case you need a concrete name for the type for which you invoke that method ... this is because the actual method that gets called is not known, being dispatched based on "this", so you need some kind of lookup strategy and therefore the conventions that Java uses for that lookup are hardcoded in the bytecode. However, invokeDynamic from JDK 7 allows the developer to override that lookup strategy, allowing one complete dynamic freedom at the bytecode level, with good performance characteristics.
The real issue is the JVM versus the reference implementations of Ruby/Python. The JVM is the most advanced mainstream VM (for server-side loads at least).
Unfortunately for Facebook, they didn't have a Charles Oliver Nutter to implement a kickass PHP implementation on top of the JVM - not that it's something feasible, because PHP as a language depends a lot on a multitude of C-based extensions. The more pure a language is (in common usage), the easier it is to port to other platforms. Alternative Python implementations (read Jython, IronPython) have failed because if you want to port Python, you also have to port popular libraries such as NumPy. Which is why the PyPy project is allocating good resources towards that, because otherwise nobody would use it.
> The JVM, at its core, is not working with static types. The bytecode itself is free of static types, except for when you want to invoke a method, in which case you need a concrete name for the type for which you invoke that method ...
Not sure what gave you this impression, as the majority of Java bytecode instructions are typed. For example, the add instruction comes in typed variants: iadd (for ints), ladd (for longs), dadd (for doubles), fadd (floats), etc.
The same is true for most other instructions: the other arithmetic instructions (div, sub, etc.), the comparison instructions (*cmp), pushing constants on the stack, setting and loading local variables, returning values from methods, etc.
InvokeDynamic, as you point it out, was added to make implementing dynamic languages on the JVM easier, because the JVM was too statically typed at its core.
Arithmetic operations on numbers are not polymorphic, but polymorphism has nothing to do with static typing per se. You're being confused here by the special treatment the JVM gives to primitives, special treatment that was needed to avoid the boxing/unboxing costs, but that's a separate discussion and note that hidden boxing/unboxing costs can also happen in Scala, which treats numbers as Objects.
Disregarding primitives, the JVM doesn't give a crap about what types you push/pop the stack or what values you return.
invokeDynamic is nothing more than an invokeVirtual or maybe an invokeInterface, with the difference that the actual method lookup logic (specific to the Java language) is overridden by your own logic, otherwise it's subject to the same optimizations that the JVM is able to perform on virtual method calls, like code inlining:
> ... because the JVM was too statically typed at its core
Nice hand-waving of an argument, by throwing a useless Wikipedia link in there as some kind of appeal to authority.
I can do that too ... the core of the JVM (the HotSpot introduced in 1.4) is actually based on Strongtalk, a Smaltalk implementation that used optional-typing for type-safety, but not for performance:
> Nice hand-waving of an argument, by throwing a useless Wikipedia link in there as some kind of appeal to authority
No need to get agressive over this :) I disagreed with your first comment regarding the dynamic nature of the JVM, and replied trying to explain why.
I posted the wikipedia link not as kind of an "appeal to authority", but to give the readers a full listing of bytecode instructions, so that they can check what I was saying for themselves.
> Disregarding primitives, the JVM doesn't give a crap about what types you push/pop the stack or what values you return.
It depends how you see things: the JVM can't possibly provide instructions for every possible user type, so apart from primitives, the other object types are passed around as pointers or references, but whenever you try to do something other than storing/loading them on the stack, the type checking kicks in, ensuring that the reference being manipulated has the right types.
For instance, the putfield instruction doesn't just take the field name where the top of the stack is going to get stored. It also takes the type of the field as a parameter, to ensure that the types are compatible.
Constrast this to Python's bytecode, where the equivalent STORE_NAME (or the other variants) doesn't ask you to provide type informations.
But then again, we might be splitting hairs here: since this type checking is happening at runtime (when the JVM is running your code), you could indeed question calling it "static typing", which is usually performed at compile time (an is partially performed by the java compiler for example).
I don't think pushing tweets to every user is a scalable approach. It would seem more sensible to read rather than push tweets associated with a user. I don't know about Twitter's infrastructure, but storing more than 1 copy of the same data wouldn't make that much sense.
> I don't think pushing tweets to every user is a scalable approach. It would seem more sensible to read rather than push tweets associated with a user. I don't know about Twitter's infrastructure, but storing more than 1 copy of the same data wouldn't make that much sense.
Suppose I have 5000 followers. How do you propose to get the timeline? Since you said "single copy of data", I assume you would do something like this:
When a user posts a video it gets published in the subscription feed of every user subscribed(maybe not with the ajax like twitter does); plus they tell you which videos have you already watched. Plus the search feature is probably more used than in Twitter.
I am not sure about the motivation for this project but this article helps explain why some folks are interested in type systems as detachable (pluggable) components, separate from languages:
I've read a few of Gilad's papers - I just don't see how they can be practical in a world of third-party libraries (e.g. author A hates types, I like type-safety but I have to settle for none when I use that library).
This paper demonstrates an effective way of interfacing between typed and untyped code such that type errors can only happen at the boundaries - not within typed code.
I guess, but this seems like something that could become a best practice for library authors, and it'd be fairly trivial to retrofit or fork existing libs with annotations.
They're implemented using the same data structure and given the language semantics (keys can be any scalar type intermingled horribly), how would you improve that?
This is simply unfair, should the language maintainers be held accountable for user behaviour?
A more interesting and fairer topic is whether PHPs count() is considerably slower than python's len()
This guy is a hacker in the truest sense, I read a blog post over a year ago about him tinkering away on this. It didn't seem he'd take it this far. It's a great achievement and I'm glad he's been insightful enough to keep it free.
I used Impact two years ago on something and I was so impressed with the API simplicity and power (not to mention the fact that it ran very well). This guy does great work.
Dominic is amazing at what he does. ImpactJS is such a powerful but simple tool. I love that every release is NOT bloatware, but carefully thought out feature enhacements.
Yup Rubymotion isn't interpreted, it's compiled file by file to LLVM bytecode, this negatively effects development speed but it means it runs (roughly) as fast as pure obj-c (or so they claim on the rubymotion site).
We're using it at the moment to develop an app, it's great at keeping code DRY, debuggability on device kinda sucks atm though.
I found Mashape via google as I was looking for a simple way to monetize our API (and get some exposure) about a year ago. We posted our Whois API (http://www.mashape.com/nametoolkit/name-toolkit) on Mashape.
In the early days it was quiet but I liked the auto-generated clients. It's really been picking up in the last few months and the hassle-free billing, documentation is great. Augusto is great, he is still personally answering mails when there are issues.
What could be improved on: Better stats for the admin interface, .NET support (I'm aware this has been on their roadmap but customers have repeatedly asked me for this), more payout options like bank transfer would be awesome too.
Not to rain on your parade, but to anyone looking to try this I just wasted 30 minutes getting setup and trying it to find out that Godaddy, for example, returns next to no results through this service so it's no solution to WHOIS woes.
Firstly, yes our whois parser needs work, whois is a dirty protocol with lots of inconsistency and we haven't spent enough time dealing with parsing ALL the data out.
Oddly enough it has already proved useful to some customers and some fields are consistently parsed well. What's your use case and which fields are you interested in that we failed to parse?
The client libraries already parse the returned JSON response. Or you can still consume the API without client libraries and get the raw JSON response.
