Re:Javascript as a Virtual Machine Representation
on
Asm.js Gets Faster
·
· Score: 1
Agreed, the barriers are political, not technical. And yea, the DOM could be replaced as well.
Javascript as a Virtual Machine Representation
on
Asm.js Gets Faster
·
· Score: 5, Interesting
The idea of compiling to JavaScript has been done a lot. Microsoft Labs had a project to take CLR codes and compile down to JavaScript. It was abandoned as too slow. I'm sure improvements to the JavaScript engines have made it more feasible. But, as noted the lack of certain native types and immutable data types (i.e. DateTime) forces a ton of static analysis to be done just to figure out that hey, that variable could be an plain integer. And it has to be conservative. Much easier to just have integers and be done with it.
If there is such an insistence on making the web an application platform for everything, then I think at some point you just have to standardize on a VM. Yes, yet another one. So, you can use Dart, JavaScript, Scheme, C#, Java, whatever there's a compiler for. Treat the DOM as core API and enjoy.
Personally, I just hope people realize that operating systems have been doing this well for years, that sandboxing isn't unique to web browsers and that "native" applications are actually a good thing.
The mobile app thing gives me a bit of hope, but it's sad that people seem unwilling to download a installer from the web from a trusted source and install it. I find it a bit strange that people are turning to the web to solve a problem that the web greatly expanded the widespread propagation of viruses and other malware.
And what people are surprised by is a bit baffling as well. A web browser isn't magic. Being impressed that you can run Doom on a modern web browser is missing the forest for a tree. I could run Doom on my computer for ages now. Me having to visit a URL to do so isn't not a major actual change nor improvement, despite the technical accomplishments that went into it.
But, it's not a widespread commendation of the ACA law. In fact, as noted, there are significant enrollments by paper.
Also, there is a huge crunch on the backend to automate the purchasing process. Surprise, most health insurers are not set up to make it easy for people to purchase health plans online, much less handle large numbers of enrollments. Also, there is a lot of work around the small group marketplaces. The article and summary make it sound like 300 million was spent just on the web site. It's not even close. Granted the web site is just broken and heads are starting to roll.
Oh, and the main contractor for the project was Oracle, so, well, if anybody can make that much disappear they can.
Citation needed. This current economic situation seems directly tied to out of control market speculation, heavy accumulation of wealth at the top (now surpassing the levels seen right before the Great Depression) and a fragmented work force that is unable to organize in many areas thanks to focused efforts to weaken labor laws.
Also, given that tech people are so enamored of disruptive technologies, why do they think that couldn't organize in a effective way that avoids the worst problems but maintains the benefits? Create a disruptive union model that changes the game on both sides, perhaps?
The appearance of the Curator had my head scratching for a bit. I mean, how. We saw that regeneration, nothing weird about that. Seems like a bit of a problem. I don't care about canon, but what would the nerds think.
I forgot about the Watcher. Loophole; problem solved.
After all, it is a large enough company that you could make a career out of working there and not get too bored. I think there are some people that are tired of hopping from job to job just to get any advancement may find this appealing. And if the board makes a good pick for CEO, it could get really interesting. There always has been some talent lurking there, they have resources and a real R&D department and if they can cut through the management stagnation, we could see some neat stuff coming from Redmond.
At any rate, the fact that a major company has abandoned stack rating is great news. It's a terrible HR practice that needs to disappear for good.
It's to their credit that we as a culture see them as the gateway to health care, and they have done many, many things to insure that people don't interact directly with providers, but in the end, they are middlemen. Nothing more. They do not provide care. Doctors, nurses, clinics and hospitals do. And, given the current state of things, they have done nothing to control costs.
Big Data isn't destroying the US health system. It's the lack of coverage, for-profit insurance protecting their margins by charging everyone more and more to do less and less, to deny payment (and therefore care) so that people get so sick that they lose their jobs and their coverage, passing on the burden to providers and taxpayers that, by law, can not deny essential care. It's a system that only pays up when absolutely necessary, that does not to help people stay off of the doctor's office.
It's a culture that insists that chronic illness or disability is a moral failing and that it is the fault of the person for merely being ill. It's the insistence that health is a privilege, not a right. It's not some computing trend that insurance companies are using to discriminate. Insurance companies have been doing that forever.
Well, I missed the section that they added the relaxation for effectively final variables for inner classes as well, so yes, this is just syntactic sugaring.
I still argue that the concision of lambda syntax is still useful, even if you don't get full on closures.
True, they aren't true closures. This is a important distinction to make.
What I missed is that the relaxation to allow effectively final variable capture applies to lambdas and inner classes; so I agree that this is syntactic sugar.
And I agree that this syntax does lead to wider adoption of the newer streaming parts than would occur without it.
I am surprised at the backlash about adding lambdas and some associated features (default methods) that support a more functional programming style.
Firstly, lambdas aren't just anonymous class syntactic sugar, they work differently. Hence, new syntax, that just happens to be more concise. Lambdas and closures are as old as the hills, this isn't some trendy new language feature that hasn't been well thought out.
And, yes, for loops are enough, we know this. But conciseness can help. I have a list of orders, each order has a list of line items. I want to sum their prices up. Sure, the for loop version isn't too bad.
int price = 0; for (Order o : orders) { for (LineItem li in o.LineItems) { price += li.getPrice(); } }
And if we want to choose which orders and which lineItems, we add conditional statements.
But, as one codes more and more, you will write code like this a lot. At some point, one thinks about you could somehow capture this "pattern" more concisely? One could go to the GOF and talk about a Iterators, Strategy, etc. But, that's a lot of classes.
Functional programming does is give you a different, smaller set of building blocks to capture patterns like these. Let's do a LINQ version in C# of our Java code.
Now, this code is more dense, but if you look at it, it states what you want, not how to get it. I read this as "For all orders for a given customer, select all the line items for which the price is more than 10.0, and give me the sum of the price for those line items).
Now, imagine that the orders list is pretty big, and we want to see if a parallel version would do better. PLINQ makes that a breeze.
orders.AsParallel()...// same code as above.
Now, this isn't as efficient as a hand crafted parallel loop, nor it is magically going to work on a list of orders that can't even fit in one process, but with one change, we can see if we get a speedup, and if it is good enough, and if it isn't, then we can go for a handwritten version.
In the era of multicores and parallel programming, a basic understanding of functional programming is very useful as it gives one a different set of tools for how to think about a problem.
My apologies for the poor code formatting, but hopefully the ideas still come through.
It's not just syntactic convenience. Lambdas represent closures, which have different scoping rules and variable capture rules. For one, lambdas just use lexical scope and don't introduce a new scope (which anonymous classes do. Because they are classes).
They can capture certain variables in the scope that anonymous classes can't. It's a bit complex, but lambdas can capture variables that are effectively final, before, it has to be declared final.
Here's an example. Imagine you are in a method of class, you have an external list of other objects that you want to match based on a person's name. You can just use this lambda as filter:
This is a natural expression. Note, that this doesn't work in an anonymous class, because this refers to the anonymous class, not the outer class.
Moving on from this, the new lambdas and functional interfaces allow you create much more generic functional methods. So, you can now write things like
aList.filter(o->o.getLength() > 0) and bList.filter(o->o.getName > 0).
As a C# developer (and secret Schemer, err, Racketeer), functional style programming is really useful and has a big impact on productivity and expressiveness. Sadly, Java Generics and type erasures imposes some limits compared to the C# implementation, but that doesn't discount how useful this style of programming is.
Sure, you don't see that use of waffle much (the failure to make up one's mind), but I can't agree that they constitute a massive failure of composition. Certainly, its no more a failing than using a French phrase to give an air of erudition to a simple point that you don't think those words work well together.
This is an good point. Certainly, the reason C# has these features is to address those cases you describe with less code. As you noted, getting parity with advances in languages like Scala, Clojure is important.
I remember when C# and.Net first came out, it was noted that it was just borrowing (some said stealing) from Java. When C# first came out, I didn't see it as becoming a leader in new language features, but it is clearly is, as Java 8 addresses a lot of things that been part of C# for a while.
Streams: Similar to IEnumerable and parts of LINQ (LINQ to Objects). Of course, IEnumerables are less strict on multiple enumeration (it may work). Being a bit more strict on this as Streams isn't a bad idea. Functional Interfaces; The article was light on details, but it seems to address the use cases that extension methods in C# addresses. Interesting that the body of the method appear in the interface. The ability for a class to override this default is a new idea, it will be interesting to see how this plays out. Not a bad way to go about this at all. Lambdas:Well, it's -> versus =>. I can't imagine the discussions that occurred over which one to choose.
I'm not sure about the JavaScript in Java feature. But, I've always said being able to execute Scheme in.Net would be useful to me, so this something that MS may have to address down the road.
For me, Java still needs some catching up in terms of parallel programming versus the Task Parallel Library (and the Dataflow Extensions). This is especially true with C# 5.0. Async and await are powerful language features. Personally, I'm still prefer C#. I like having first class generics, the full LINQ library (Expressions) and libraries like Reactive Extensions and Code Contracts (plus the static verifier) are nice features. But, all this in Java 8lis a step in the right direction. I just hope it isn't a case of too little, too late.
Where to start. First of all, let me make a nod to (http://www.swig.org/) a tool that makes binding C and C++ to other languages easier. The technology to provide code to many languages is a largely solved problem. Write what you can in C and bind it to the world.
The notion that you can have an abstract programming language that just maps into a bunch of platforms is quite a ways off. The demand for it just doesn't exist. UML tried this in the late 90s, and it mostly failed (there was some traction in real time systems engineering).
The lack of code reuse is not due to a single language mindset, a unwillingness to share. Writing reusable code is just hard. It requires careful design and a lot of effort.
There no easy way around the lowest common denominator problem. Sure, it's easy to map printing a line to a console to a bunch of platforms. But, when you get past what the basic of the standard C library calls, you pretty much just end up creating yet another platform and language, compounding the problem. We just don't have the design experience or languages yet to express many programming tasks abstractly and effectively.
It is bad. Of note is how all of the new features in C# 5.0 are focused on enabling programmers to better make and consume non-blocking code, which is just a first step in addressing this issue.
I'm not claiming to be to a parallel programming guru by any stretch. I have done it, but it is not easy. It requires an order of magnitude more thinking and planning. Doing it well just requires years of experience and training. Reducing that is a massive challenge.
"Eclipse requires about 3 megabytes of memory (depending on what you're using it for)."
If you are using it for anything, I think it probably does use more memory than that. The only other thing I'd note is that the Python Tools for Visual Studio work with CPython, not just IronPython.
The rest of the article isn't that bad, but it does seem like a lot of words to say that both have advantages and disadvantages and are targeted towards different use cases and environments.
The whole exchange is actually an excellent example of the behavior she is calling out. She asks if this kind of discourse has a place on a kernel mailing list.
It's a fair question. Does Linus answer it? No. He dodges the whole thing by claiming her request to review the culture on the list is being equally oppressive. Seriously, if this kind of thing is being held up as excellent technical leadership, it's no wonder that our industry suffers from a complete lack of diversity in terms of women and minorities. I know some don't see this as a problem. Others do.
To make it more blunt, I'm sure there's plenty of people that don't mind working with this kind of posturing, macho bullshit that shows up from time to time on this and other lists. I'm not one of them. Maybe it means I'm less successful. But you know what, I happy with that.
Things like this will always lead to the question "what could have been" if Linux or other OSS projects had leadership that didn't need to resort to personal attacks and intimidation to protect "their creations". Egoless programming is way harder than it appears.
The responses to this, if any, could be provide some interesting insights. To be sure, it is easier to make things personal on the internet, but is that an excuse for doing so?
They may need to learn maintainability, but I'd wager that is an easier skill than producing the kind of efficient *and* correct solutions they come up with.
And I would disagree. It's a different skill, no "easier" than others and just as valuable, if not more so; maintaining code is part and parcel of all programming.
I'd admit that there is more focus on correctness and performance that met the eye, so I will concede those points. As for scale, the nature of the competition precludes the use of clusters, so while large scale implementations may differ, you can't get around that.
The thing about programming, sour grapes aren't that sour. I've managed to do okay without being on a world class programming team. I'm sure plenty that have are doing awesome as well.
Slashdot Mirror
Agreed, the barriers are political, not technical. And yea, the DOM could be replaced as well.
The idea of compiling to JavaScript has been done a lot. Microsoft Labs had a project to take CLR codes and compile down to JavaScript. It was abandoned as too slow. I'm sure improvements to the JavaScript engines have made it more feasible. But, as noted the lack of certain native types and immutable data types (i.e. DateTime) forces a ton of static analysis to be done just to figure out that hey, that variable could be an plain integer. And it has to be conservative. Much easier to just have integers and be done with it.
If there is such an insistence on making the web an application platform for everything, then I think at some point you just have to standardize on a VM. Yes, yet another one. So, you can use Dart, JavaScript, Scheme, C#, Java, whatever there's a compiler for. Treat the DOM as core API and enjoy.
Personally, I just hope people realize that operating systems have been doing this well for years, that sandboxing isn't unique to web browsers and that "native" applications are actually a good thing.
The mobile app thing gives me a bit of hope, but it's sad that people seem unwilling to download a installer from the web from a trusted source and install it. I find it a bit strange that people are turning to the web to solve a problem that the web greatly expanded the widespread propagation of viruses and other malware.
And what people are surprised by is a bit baffling as well. A web browser isn't magic. Being impressed that you can run Doom on a modern web browser is missing the forest for a tree. I could run Doom on my computer for ages now. Me having to visit a URL to do so isn't not a major actual change nor improvement, despite the technical accomplishments that went into it.
But, it's not a widespread commendation of the ACA law. In fact, as noted, there are significant enrollments by paper.
Also, there is a huge crunch on the backend to automate the purchasing process. Surprise, most health insurers are not set up to make it easy for people to purchase health plans online, much less handle large numbers of enrollments. Also, there is a lot of work around the small group marketplaces. The article and summary make it sound like 300 million was spent just on the web site. It's not even close. Granted the web site is just broken and heads are starting to roll.
Oh, and the main contractor for the project was Oracle, so, well, if anybody can make that much disappear they can.
Citation needed. This current economic situation seems directly tied to out of control market speculation, heavy accumulation of wealth at the top (now surpassing the levels seen right before the Great Depression) and a fragmented work force that is unable to organize in many areas thanks to focused efforts to weaken labor laws.
Also, given that tech people are so enamored of disruptive technologies, why do they think that couldn't organize in a effective way that avoids the worst problems but maintains the benefits? Create a disruptive union model that changes the game on both sides, perhaps?
The appearance of the Curator had my head scratching for a bit. I mean, how. We saw that regeneration, nothing weird about that. Seems like a bit of a problem. I don't care about canon, but what would the nerds think.
I forgot about the Watcher. Loophole; problem solved.
After all, it is a large enough company that you could make a career out of working there and not get too bored. I think there are some people that are tired of hopping from job to job just to get any advancement may find this appealing. And if the board makes a good pick for CEO, it could get really interesting. There always has been some talent lurking there, they have resources and a real R&D department and if they can cut through the management stagnation, we could see some neat stuff coming from Redmond.
At any rate, the fact that a major company has abandoned stack rating is great news. It's a terrible HR practice that needs to disappear for good.
s/off/out/g. I can't brain today.
It's to their credit that we as a culture see them as the gateway to health care, and they have done many, many things to insure that people don't interact directly with providers, but in the end, they are middlemen. Nothing more. They do not provide care. Doctors, nurses, clinics and hospitals do. And, given the current state of things, they have done nothing to control costs.
Big Data isn't destroying the US health system. It's the lack of coverage, for-profit insurance protecting their margins by charging everyone more and more to do less and less, to deny payment (and therefore care) so that people get so sick that they lose their jobs and their coverage, passing on the burden to providers and taxpayers that, by law, can not deny essential care. It's a system that only pays up when absolutely necessary, that does not to help people stay off of the doctor's office.
It's a culture that insists that chronic illness or disability is a moral failing and that it is the fault of the person for merely being ill. It's the insistence that health is a privilege, not a right. It's not some computing trend that insurance companies are using to discriminate. Insurance companies have been doing that forever.
Well, I missed the section that they added the relaxation for effectively final variables for inner classes as well, so yes, this is just syntactic sugaring.
I still argue that the concision of lambda syntax is still useful, even if you don't get full on closures.
True, they aren't true closures. This is a important distinction to make.
What I missed is that the relaxation to allow effectively final variable capture applies to lambdas and inner classes; so I agree that this is syntactic sugar.
And I agree that this syntax does lead to wider adoption of the newer streaming parts than would occur without it.
I am surprised at the backlash about adding lambdas and some associated features (default methods) that support a more functional programming style.
Firstly, lambdas aren't just anonymous class syntactic sugar, they work differently. Hence, new syntax, that just happens to be more concise. Lambdas and closures are as old as the hills, this isn't some trendy new language feature that hasn't been well thought out.
And, yes, for loops are enough, we know this. But conciseness can help. I have a list of orders, each order has a list of line items. I want to sum their prices up. Sure, the for loop version isn't too bad.
And if we want to choose which orders and which lineItems, we add conditional statements. But, as one codes more and more, you will write code like this a lot. At some point, one thinks about you could somehow capture this "pattern" more concisely? One could go to the GOF and talk about a Iterators, Strategy, etc. But, that's a lot of classes. Functional programming does is give you a different, smaller set of building blocks to capture patterns like these. Let's do a LINQ version in C# of our Java code.
Now, this code is more dense, but if you look at it, it states what you want, not how to get it. I read this as "For all orders for a given customer, select all the line items for which the price is more than 10.0, and give me the sum of the price for those line items). Now, imagine that the orders list is pretty big, and we want to see if a parallel version would do better. PLINQ makes that a breeze.
Now, this isn't as efficient as a hand crafted parallel loop, nor it is magically going to work on a list of orders that can't even fit in one process, but with one change, we can see if we get a speedup, and if it is good enough, and if it isn't, then we can go for a handwritten version. In the era of multicores and parallel programming, a basic understanding of functional programming is very useful as it gives one a different set of tools for how to think about a problem. My apologies for the poor code formatting, but hopefully the ideas still come through.
It's not just syntactic convenience. Lambdas represent closures, which have different scoping rules and variable capture rules. For one, lambdas just use lexical scope and don't introduce a new scope (which anonymous classes do. Because they are classes).
They can capture certain variables in the scope that anonymous classes can't. It's a bit complex, but lambdas can capture variables that are effectively final, before, it has to be declared final.
Here's an example. Imagine you are in a method of class, you have an external list of other objects that you want to match based on a person's name. You can just use this lambda as filter:
This is a natural expression. Note, that this doesn't work in an anonymous class, because this refers to the anonymous class, not the outer class.
Moving on from this, the new lambdas and functional interfaces allow you create much more generic functional methods. So, you can now write things like
As a C# developer (and secret Schemer, err, Racketeer), functional style programming is really useful and has a big impact on productivity and expressiveness. Sadly, Java Generics and type erasures imposes some limits compared to the C# implementation, but that doesn't discount how useful this style of programming is.
Sure, you don't see that use of waffle much (the failure to make up one's mind), but I can't agree that they constitute a massive failure of composition. Certainly, its no more a failing than using a French phrase to give an air of erudition to a simple point that you don't think those words work well together.
If Feingold ran, I'd vote for him in a second. The only Senator to vote against the Patriot Act. He saw this coming and was a lone voice against it.
Thanks for the clarification. The term really didn't make that much sense, but the default method does.
And, it's true that C# approach to generics makes this kind of programming interface much simpler versus the new streams API.
This is an good point. Certainly, the reason C# has these features is to address those cases you describe with less code. As you noted, getting parity with advances in languages like Scala, Clojure is important.
I remember when C# and .Net first came out, it was noted that it was just borrowing (some said stealing) from Java. When C# first came out, I didn't see it as becoming a leader in new language features, but it is clearly is, as Java 8 addresses a lot of things that been part of C# for a while.
Streams: Similar to IEnumerable and parts of LINQ (LINQ to Objects). Of course, IEnumerables are less strict on multiple enumeration (it may work). Being a bit more strict on this as Streams isn't a bad idea. Functional Interfaces; The article was light on details, but it seems to address the use cases that extension methods in C# addresses. Interesting that the body of the method appear in the interface. The ability for a class to override this default is a new idea, it will be interesting to see how this plays out. Not a bad way to go about this at all. Lambdas:Well, it's -> versus =>. I can't imagine the discussions that occurred over which one to choose.
I'm not sure about the JavaScript in Java feature. But, I've always said being able to execute Scheme in .Net would be useful to me, so this something that MS may have to address down the road.
For me, Java still needs some catching up in terms of parallel programming versus the Task Parallel Library (and the Dataflow Extensions). This is especially true with C# 5.0. Async and await are powerful language features. Personally, I'm still prefer C#. I like having first class generics, the full LINQ library (Expressions) and libraries like Reactive Extensions and Code Contracts (plus the static verifier) are nice features. But, all this in Java 8lis a step in the right direction. I just hope it isn't a case of too little, too late.
Where to start. First of all, let me make a nod to (http://www.swig.org/) a tool that makes binding C and C++ to other languages easier. The technology to provide code to many languages is a largely solved problem. Write what you can in C and bind it to the world.
The notion that you can have an abstract programming language that just maps into a bunch of platforms is quite a ways off. The demand for it just doesn't exist. UML tried this in the late 90s, and it mostly failed (there was some traction in real time systems engineering).
The lack of code reuse is not due to a single language mindset, a unwillingness to share. Writing reusable code is just hard. It requires careful design and a lot of effort.
There no easy way around the lowest common denominator problem. Sure, it's easy to map printing a line to a console to a bunch of platforms. But, when you get past what the basic of the standard C library calls, you pretty much just end up creating yet another platform and language, compounding the problem. We just don't have the design experience or languages yet to express many programming tasks abstractly and effectively.
http://en.wikipedia.org/wiki/Military_grid_reference_system
But, you know, we will use random combinations of three words instead of a structured id because that's better. Innovation at it's finest.
It is bad. Of note is how all of the new features in C# 5.0 are focused on enabling programmers to better make and consume non-blocking code, which is just a first step in addressing this issue.
I'm not claiming to be to a parallel programming guru by any stretch. I have done it, but it is not easy. It requires an order of magnitude more thinking and planning. Doing it well just requires years of experience and training. Reducing that is a massive challenge.
"Eclipse requires about 3 megabytes of memory (depending on what you're using it for)."
If you are using it for anything, I think it probably does use more memory than that. The only other thing I'd note is that the Python Tools for Visual Studio work with CPython, not just IronPython.
The rest of the article isn't that bad, but it does seem like a lot of words to say that both have advantages and disadvantages and are targeted towards different use cases and environments.
The whole exchange is actually an excellent example of the behavior she is calling out. She asks if this kind of discourse has a place on a kernel mailing list.
It's a fair question. Does Linus answer it? No. He dodges the whole thing by claiming her request to review the culture on the list is being equally oppressive. Seriously, if this kind of thing is being held up as excellent technical leadership, it's no wonder that our industry suffers from a complete lack of diversity in terms of women and minorities. I know some don't see this as a problem. Others do.
To make it more blunt, I'm sure there's plenty of people that don't mind working with this kind of posturing, macho bullshit that shows up from time to time on this and other lists. I'm not one of them. Maybe it means I'm less successful. But you know what, I happy with that.
Things like this will always lead to the question "what could have been" if Linux or other OSS projects had leadership that didn't need to resort to personal attacks and intimidation to protect "their creations". Egoless programming is way harder than it appears.
The responses to this, if any, could be provide some interesting insights. To be sure, it is easier to make things personal on the internet, but is that an excuse for doing so?
They may need to learn maintainability, but I'd wager that is an easier skill than producing the kind of efficient *and* correct solutions they come up with.
And I would disagree. It's a different skill, no "easier" than others and just as valuable, if not more so; maintaining code is part and parcel of all programming.
I'd admit that there is more focus on correctness and performance that met the eye, so I will concede those points. As for scale, the nature of the competition precludes the use of clusters, so while large scale implementations may differ, you can't get around that.
The thing about programming, sour grapes aren't that sour. I've managed to do okay without being on a world class programming team. I'm sure plenty that have are doing awesome as well.
Funny, I was thinking the same thing. Nature of the beast, I fear.