@Heater, another problem with dynamic languages is security. The ability to eval JSON always carries a risk of malicious script injection and is a vector for attack. Compiled languages are less vulnerable because you need to know the underlying machine architecture to inject code via a buffer overflow attack. Plus the addition of the execute disable page protection and address space randomization has greatly reduced the efficacy of this attack. Google JSONP insecure or the BeEF Project for more information.
BTW if you ever develop an urge to become a professional wrestler and move to Brazil you'll know that it is time to lay off the Javascript. Meanwhile the MongoDB fan boys in my office are making me want to move to a pig farm.
You know, Loopy is right, I spend to much time posting here. My new years resolution was to cut down the amount of time I spend in Parallaxia, but that idea soon went out the window. It's just so tempting to correct peoples mistakes.
Your posts, here are irresistible as you have an amazing talent to pack so many false assertions into a single paragraph
So let us proceed with this mornings batch:
..another problem with dynamic languages is security.
This is just wrong. See below.
Having a Java supporter make an argument based on security makes me chuckle, given the number of vulnerabilities in Java that have been exposed in this last year or so.
The ability to eval JSON always carries a risk of malicious script injection and is a vector for attack.
True but..
1) The first thing a new JS programmer learns is that "eval is evil". My editor even highlights use of eval with a big red dot and uses that exact string as the error message! Just don't do that.
2) If you care one tiny little bit about security why are you tying to run any old untrusted code fetched from somewhere else? The problem here is not the language but the programmers.
3) Quite why browsers allow script tags to execute code from other than the origin domain is beyond me. So you have a point there. But again it's the creators of the web page making the problem not JS.
Compiled languages are less vulnerable because...bla bla.
Given the history of computer viruses and other exploits in the passed decades and the resulting wide spread use of virus scanning software today that statement is looking rather tenuous. Oh and did I mention those Java security vulnerabilities? And did you hear about the resent SSL security holes?
I might want to join you on the pig farm. There has been talk in our office recently of using Java and RPC...
1) The first thing a new JS programmer learns is that "eval is evil". My editor even highlights use of eval with a big red dot and uses that exact string as the error message! Just don't do that.
2) If you care one tiny little bit about security why are you tying to run any old untrusted code fetched from somewhere else? The problem here is not the language but the programmers.
3) Quite why browsers allow script tags to execute code from other than the origin domain is beyond me. So you have a point there. But again it's the creators of the web page making the problem not JS.
The problem is that evaluation, JSON, and JSONP are all tangled up in big ball of wibbly wobbly insecurity. It's not as simple as don't explicitly call eval, sometimes the eval is performed implicitly by a library and is intrinsic to the way JSONP works. Now you can say don't use JSONP, but Javascript's same origin policy can force you to use it. Client side mashups have become popular in recent years and sometimes to compete with other vendors you are forced to integrate such features. There's also the issue of including code via script tags from a CDN which is desirable for performance, but opens up your app to script injection if the CDN is compromised.
Given the history of computer viruses and other exploits in the passed decades and the resulting wide spread use of virus scanning software today that statement is looking rather tenuous. Oh and did I mention those Java security vulnerabilities? And did you hear about the resent SSL security holes?
Most of these flaws are problems with the implementation of the JVM, not the underlying language specification. Javascript's security problem is foundational and you can't release a patch to untangle the big ball of wibbly wobbly insecurity.
The problem is that evaluation, JSON, and JSONP are all tangled up in big ball of wibbly wobbly insecurity.
Yep. Web technology is a leaky bucket. HTTP and HTML were created as document sharing mechanism. They have been evolved way beyond that into an application delivery system. The security issues are very much different than originally envisioned and the Web standards and web browsers have not caught up. The web standards pretty much demand insecurity!
None of this is the fault of JavaScript the language. Or at least most of it is not.
Your example of JSON/JSONP is a good case in point. And one that has been bugging me for a long time.
Browser "security policy", if we can call it that, dictates that I cannot fetch data from some "foreign" server. However I may run scripts from foreign servers. As you said that could be library scripts I want to use, it may be "mashups", it may be to do with advertising or Facebook likes or Google analytics or whatever.
Why in God's name was that ever allowed? I mean ever?
When I, the surfer, go to your web site I have said "I want to go to Martin's web site". What I have not said is "Oh by the way browser, go ahead and fetch whatever from wherever and run any old code from any old backstreet server Martin points you at".
In my book this is all to do with the web standards and the way browsers work not JS the language itself.
eval may be evil but is also a powerful and useful feature when you need it. If you think about it it's is nothing special. Think about compiled code, say C++, here we can use dynamically loadable libraries. We can load code that we have never seen before on demand at run time and call it. Think "plugins". One could imagine that in the current web set up a browser could fetch a program from my site then fetch some library code from your site. BANG we are in the same situation as we are now. I guess the same can be done in Java.
It's just a bad idea to load and run untrusted code no matter if you do it at binary, bytecode, or source level.
Most of these flaws are problems with the implementation of the JVM, not the underlying language specification. Javascript's security problem is foundational and you can't release a patch to untangle the big ball of wibbly wobbly insecurity.
Hey, that's not fair. You are changing the rules of engagement in the war. Rules that you yourself made up.
When I suggested we discuss JavaScript the language as opposed to the crappy browser environment it often runs in you said that was not right as the browser is the predominant platform for JS.
Now you are separating Java, the language, from it's VM. Which way do you want it?
Makes no odds to me. Java is still a crappy language with no interesting features even when conceptually divorced from it's bloated and security hole ridden run time.
Yes it's a "wibbly wobbly" world. It's not the languages fault in either case.
Hey, that's not fair. You are changing the rules of engagement in the war. Rules that you yourself made up.
When I suggested we discuss JavaScript the language as opposed to the crappy browser environment it often runs in you said that was not right as the browser is the predominant platform for JS.
Now you are separating Java, the language, from it's VM. Which way do you want it?
Fair enough, I'm willing to conclude that they're both lousy languages. We should go back to native clients in C++ and ditch Web apps entirely.
I'm willing to conclude that they're both lousy languages
We are reaching enlightenment at last. Spend enough time living with any language and you begin to hate it. That's why programmers keep inventing YAFL. I'm still having an illicit affair with JS. If we ever get married things might change
Don't get me started on C++. That infinite fractal of complexity and broken features that not even its creator understands any more. Wish I could link you to the moment in one conference video where Bjarne is asking the presenter to explain how the piece of C++ on the screen does not work as it first might seem. Magic. I used to think it was me that was too stupid to hold the whole thing in my mind. Seems not to be so.
If you read Bjarne Stroustrup's books or watch his presentations he can explain very carefully and convincingly why every little feature is in the language and why it is the way it is. Every step of the way he can convince you that the whole thing makes perfect sense and that is the only way it could be.
However the final edifice is a tower of babel.
Still I will always return to my first love C and her daughter C++. They let me do anything.
After dodging the Node.js bullet on my last project, I was strong armed into using it on this project. My conclusion is that it represents a complete reinvention of the Java servlet ecosystem, only done poorly. The problem is that for every need you have (e.g. unit tests, http client) there are several options that almost work. This leads to the use of multiple packages for the areas where they do work.
Because JavaScript is not compiled, a good chunk of your unit tests are all about enforcement of the contract the code wants to create. But those unit tests need not be written at all with Java, so we have a much greater number of unit tests for roughly the same code coverage. It looks good on a dashboard showing the total number of unit tests, so it's got that going for it.
Any time saved by not compiling code and fast startup is lost running all the extra unit tests.
The lack of threads means all I/O is nonblocking, which means a liberal use of continuation functions. The result is really nasty looking code with nested layers of lambda functions.
Every time I see if (typeof x == "undefined" || x == null) I die a little.
The value of a common server side versus client side language is overblow because the problem domains are so different. Client side is usually worried about UI element manipulation and workflow. Server side code is all about request validation, data acquisition, and response formatting. There's almost no overlap with these concepts and your typical CSS Jockey could care less about the latter, while the server side programmer views CSS and DOM manipulation as the gross hacks that they are.
By default Node.js doesn't have an access log (I.e. an audit trail of all requests). Sure you can add logging, but this is something a server stack should do out of the box to be credible.
Node.js uses often uses patform specific packages that are pulled down and compiled for the OS variant you are on. This means that your build and packaging machine must be the same OS as your target runtime. Java already went through this nonsense and went with 100℅ pure Java because you often develop on small iron and run on big iron.
So my overall opinion is that it is not ready for primetime, but groupthink means we're stuck with it.
Oh goody the JS war is back on. It's been a bit of along lull:)
After dodging the Node.js bullet on my last project, I was strong armed into using it on this project.
Wow, that's great. Welcome on board. Let me see what I can do to help.
My conclusion is that it represents a complete reinvention of the Java servlet ecosystem, only done poorly.
I know nothing of the JavaServelet ecosystem so I can't comment on that. Except of course that Java is a language with no compelling features and no reason to exist. As for "done poorly", how can that be? it works very well for many.
The problem is that for every need you have (e.g. unit tests, http client) there are several options that almost work. This leads to the use of multiple packages for the areas where they do work.
This is not my experience. Pretty much all the packages we use work as advertised. We have occasionally stumbled into bugs, reported them to the package creators and seen them fixed in short order.
What packages are giving you trouble? An what problems exactly?
Because JavaScript is not compiled, a good chunk of your unit tests are all about enforcement of the contract the code wants to create. But those unit tests need not be written at all with Java, so we have a much greater number of unit tests for roughly the same code coverage.
In terms of code coverage I do not see how JS requires more unit tests than Java. Presumably there are a similar number of pathways though your code no matter which language. And you will be wanting to exercise all those pathways, right?
In fact I would wager that you have less pathways to cover with a JavaScript solution because I convinced you have to write less code to get the same job done a lot of the time.
Admittedly you may want more unit tests to cover the possibility of incorrect types being passed around. However normally you you only need those at API boundaries so it's only a small burden. You should be exercising you system for invalid inputs anyway.
Any time saved by not compiling code and fast startup is lost running all the extra unit tests.
How so? I don't know about you but I'm not running all my unit tests all the time. Certainly before pushing changes back to github. Then unit tests don't normally take very long.
The lack of threads means all I/O is nonblocking, which means a liberal use of continuation functions. The result is really nasty looking code with nested layers of lambda functions.
Ah yes, the dreaded "callback hell". In my experience most of the time there are not so many layers and it does not bother me. When they get too nested things get ugly as you say. That's easily fixed by using the async module or promises. Not much of a problem and preferable to threads anyway.
Every time I see if (typeof x == "undefined" || x == null) I die a little.
Sounds like you are doing some input validation there. Not much worse that the input validation you see in any other language or those "asserts" you see scattered around.
The value of a common server side versus client side language is overblow because the problem domains are so different. Client side is usually worried about UI element manipulation and workflow. Server side code is all about request validation, data acquisition, and response formatting. There's almost no overlap...
I disagree that problem domains are so different. In fact they are very similar.
What I'm seeing is that it's all about responding to events both on the server and in the browser.
On the server the events are requests or responses from databases queries or other data arriving that needs dealing with.
In the client the events are user input, mouse, keyboard, form submissions and so on. Not to mention responding to incoming data events from AJAX requests or web sockets etc.
It's all asynchronous processing at server and client. Conceptually the same.
with these concepts and your typical CSS Jockey could care less about the latter, while the server side programmer views CSS and DOM manipulation as the gross hacks that they are.
I agree, I hate CSS and DOM and even HTML. I try to avoid them as much as possible and try to get someone more enthusiastic about it to do it. Or make use of libraries and frameworks that make dealing with that Smile less painful.
But we are not here to discuss CSS/DOM/HTML.
By default Node.js doesn't have an access log (I.e. an audit trail of all requests)
That is a good thing. Node is a run time with some core functionality built in. Higher level functionality belongs in modules.
Sure you can add logging, but this is something a server stack should do out of the box to be credible.
Node is not a web server stack, despite having http built in. I presume you are using express for you web server stack. In which case logging is only a line of code away. It's all quite credible.
Node.js uses often uses platform specific packages that are pulled down and compiled for the OS variant you are on. This means that your build and packaging machine must be the same OS as your target runtime.
No.
Firstly I don't include the node_modules directory in my projects repository or any deliverable. As far as I'm concerned that is nuts because: a) It bloats out my repo with a ton of stuff I did not create. I don't expect my project to carry all it's dependencies around in other languages, why would I do it here. b) Those modules will not run without a rebuild on other platforms, ARM, MIPS etc.
If you have a package.json file when you ship your project a quick "npm install" will get you all the required modules at the specified versions.
If you really want to be sure you are shipping a running system package it all up in a container. Docker is great for this. Then you have something that is sure to work in any interesting place. It's a great idea whether using JS or anything else.
Java already went through this nonsense and went with 100℅ pure Java because you often develop on small iron and run on big iron.
No doubt.
So my overall opinion is that it is not ready for primetime,
There are some big players using JS and node on big projects. It's already hit prime time...
...but groupthink means we're stuck with it.
I don't know, JS and node saved my bacon when I discovered them a couple of years ago. I thought it was a crazy experiment but it worked out well. There was no "group" around me to push me along.
I'm sure the world will only be "stuck with it" until the next big fad silver bullet comes along:)
If you are feeling adventurous try out a recent node version and set the "harmony" flag on. Then you can use a lot of features from the new ES6 standard of JS. ES6 has a lot of features that address your concerns, like the callback hell for example.
Edit: Oh yeah. Don't forget to always use jslint on your code. I love to use the Sublime text editor with the jslint plugin. It highlights all kind of fopars as you type.
Don't complain that jslint hates your code formatting and use of white space. Just do what it says. Everybody on the project should.
Personally, Javascript is my favorite language, and I actually like the non-blocking callback aspect. In fact, it seems like most of your critiques are a direction of personal preference. And my preference goes the other way.
"Any time saved by not compiling code and fast startup is lost running all the extra unit tests." Why run all the tests anyway? Why not just run tests for the changed file, then save the rest for every 15 minutes or so?
Re stacks: I use Hapi.js for my Node server. It includes everything that I want, including built in logging, and it's more than "almost works". The much more popular Express also includes logging, as does Strongloop's loopback and Sails.js. Logging is not built into the language, but I don't see why it should be. Using a module is a seamless drop in.
For writing unit tests I don't bother with input type validation. Why? Because Hapi includes request query validation which ensures that all user inputs to the system are run through filters. So, it's the correct type anyway. And I've found in general that Javascript, despite being weakly typed, is remarkably forgiving of parameters. If a wrong type is given to a function I either find it immediately or it's not a problem.
Why have a build system at all? npm works fine wherever you are.
A common language is not overblown at all, especially for small companies. I do all the programming, and in one day I work on both the client side and sever side in tandem. It's incredibly helpful not to have to switch between languages or development environments when I program.
Martin has a very valid concern regarding deployment.
If you just ship your code there is a very real danger that whoever is deploying it will "npm install all required packages" and the resulting set up will contain different module versions than those that the code was developed and test against. This can be disastrous when newer packages with breaking changes get used.
Using a package.json file, which specifies specific module versions, cures most of these ills. With a package.json file whoever deploys the thing will get the same versions as the developer.
Ultimately the way to go, whether using node or Python or whatever is to package the running system into Docker containers. Then you have your app and everything it needs to run in a container that can then be deployed on Google cloud, AWS, MS Azure, Digital Ocean and many other places including your own servers.
With Docker the developer, the testers, the deployment are essentially always in the same environment.
What packages are giving you trouble? An what problems exactly?
One example is the high level HTTP Request class doesn't support POST with a query string even though it's something some legacy backends do. So we need to use both the low level HTTP class and the high level Request class.
In terms of code coverage I do not see how JS requires more unit tests than Java. Presumably there are a similar number of pathways though your code no matter which language.
This is not a correct assumption. For all functions you need to write unit tests to ensure that the required number of a parameters are passed and are of the correct types. You don't do that with Java because the compiler enforces that. So you automatically have more busy work unit tests to write with JavaScript.
Ah yes, the dreaded "callback hell". In my experience most of the time there are not so many layers and it does not bother me. When they get too nested things get ugly as you say. That's easily fixed by using the async module or promises. Not much of a problem and preferable to threads anyway.
On the server side aggregation is a common pattern. So you'll often query multiple backends in sequence (sometimes in parallel) and join the results. Blocking I/O makes this fairly trivial to code. Non-blocking I/O means having to figure out when all the I/O's are complete so you can join the results.
It's all asynchronous processing at server and client. Conceptually the same.
Client side processing is event based, but server side processing is more like a pipeline (at least in financial services). You gather and scrub inputs, query a database, possibly use the output as inputs to another query, then format a response. It's not event based at all.
Firstly I don't include the node_modules directory in my projects repository or any deliverable. As far as I'm concerned that is nuts because: a) It bloats out my repo with a ton of stuff I did not create. I don't expect my project to carry all it's dependencies around in other languages, why would I do it here. b) Those modules will not run without a rebuild on other platforms, ARM, MIPS etc.
If you have a package.json file when you ship your project a quick "npm install" will get you all the required modules at the specified versions.
In financial services there's always an assumption of mistrust between the various tiers of the organization. The security group assumes that developers are trying to slip a logic bomb into the production machines to allow them to compromise them. The production team assumes that developers must not touch a production machine or they'll slip a logic bomb onto it. This paranoia developed because these sort of events actually happened in the past.
The code development produces must be compiled into a sealed package that will be delivered to QA to be tested and unaltered in anyway after that point. Running an "npm install" on a production machine which pulled code from a repo (even an internal one) would violate this chain of mistrust. Honestly I expect someone to get fired the first time they run npm install on a production machine.
One example is the high level HTTP Request class doesn't support POST with a query string even though it's something some legacy backends do. So we need to use both the low level HTTP class and the high level Request class.
So you have no problem. One module does on thing and another module does another. Although I might be surprised to find there is no http request module that does everything you want. Which modules are you using exactly?
This is of course not exactly a JavaScript language issue.
For all functions you need to write unit tests to ensure that the required number of a parameters are passed and are of the correct types. You don't do that with Java because the compiler enforces that. So you automatically have more busy work unit tests to write with JavaScript.
No, why?
If functions/methods are getting parameter types they cannot handle the function is going to fail to produce the correct results. That failure should be picked up by the rest of your tests.
Similarly for incorrect number of parameters.
The only difference is that the error is detected at run time (test time) instead of compile time.
Given that you need to test your code comprehensively anyway having the compiler do the type and arity checking is kind of pointless.
On the server side aggregation is a common pattern. So you'll often query multiple backends in sequence (sometimes in parallel) and join the results. Blocking I/O makes this fairly trivial to code. Non-blocking I/O means having to figure out when all the I/O's are complete so you can join the results.
This can get hairy. Still, async or promises makes it trivial again. I'm not so sure about the parallel case having never had to do that much. But async seems to have it covered:
async.parallel([
function(){ ... }, // Make some DB query
function(){ ... } // Make some other DB query at the same time.
], callback);
Blocking I/O does not make this trivial unless you introduce threads. Then it's not trivial anymore:) Please show equivalent Java code to the above.
Client side processing is event based, but server side processing is more like a pipeline (at least in financial services). You gather and scrub inputs, query a database, possibly use the output as inputs to another query, then format a response. It's not event based at all.
So we have:
1) "gather...inputs." - That's events.
2) "query a database." - The responses from the DB are events.
3) "use the output as inputs to another query," - The responses are more events.
Looks like it's all event based to me.
In financial services there's always an assumption of mistrust between the various tiers of the organization. The security group assumes that developers are trying to slip a logic bomb into the production machines to allow them to compromise them.The production team assumes that developers must not touch a production machine or they'll slip a logic bomb onto it. This paranoia developed because these sort of events actually happened in the past.
The code development produces must be compiled into a sealed package that will be delivered to QA to be tested and unaltered in anyway after that point. Running an "npm install" on a production machine which pulled code from a repo (even an internal one) would violate this chain of mistrust.
Oh boy. Given that your organization is so paranoid (quite rightly) their entire system is back to front.
"The code development produces must be compiled into a sealed package that will be delivered to QA to be tested and unaltered in anyway after that point." So they have immediately set themselves up for the "logic bomb" they are trying to avoid.
I worked for many years in the aerospace industry. Guys building fly by wire systems, Boeing 777 for example, are very paranoid. I'm going to assume that a "logic bomb" is actually just a bug you don't want creeping into the system. Here was the deal:
1) As a developer I produce source code to some specification.
2) My code goes to review. At least two guys had to sign it of as meeting the spec.
3) Someone else would be writing the tests of my code. Again, test are derived from the spec.
4) Those tests go to review. At least two guys had to sign the of the tests as providing the correct coverage, expected results etc.
5) Somebody does the unit testing. Again a couple of sign offs.
6) Meanwhile, all the common libraries and stuff my code may depend on is produced and/or verified by similar processes, perhaps within a totally different group. Not by me.
7) Then of course there is the integration, integration testing and delivery phases. More like the above.
The reason I say your organization is inside out is that you, as a developer, should only be delivering the source code that you produce. Not a pile of random node modules that go with it.
It's up to the rest of the paranoid organization to acquire, create, verify, test every module and other component they will be using along with your code.
Honestly I expect someone to get fired the first time they run npm install on a production machine.
No why?
When they do that they should be fetching from the organizations own private npm repository that contains only code they have audited, verified, tested, approved.
When it comes to "sealed package that will be delivered to QA" it sounds like a Docker container would fit their bill just fine. (All be it a backward solution to the paranoia issue)
Built almost twice as fast [development] with fewer people
Written in 33% fewer lines of code
Constructed with 40% fewer files
Double the requests per second vs. the Java application.
35% decrease in the average response time
I've seen that presentation and it's what started the Node.is BS at my company. So how did PayPal compare it against Java? They built the same system twice, of course they could do it better the second time around. The second time around benefits from all the requirements gathering and understanding what you are building in the first pass. If they did it in JavaScript first and Java second they would have come to the opposite conclusion.
But my seeing that isn't the problem. A rather arrogant VP saw it and thinks he's discovered a silver bullet. Any negative feedback or pointing out the obvious fallacy in that presentation is perceived as a negative attitude or incompetence. Personally I'm hoping his arrogance gets him fired so he can spend more time with his family. Then we can undo all of his bad ideas, including Node.js, especially Node.js.
An npm install on a prod machine will get you fired because production reports to a different senior manager. Pulling code from a repo on to a production machine will get you fired because production reports to a different sent manager. It's that simple.
Edit: A logic bomb is a backdoor that could be exploited for financial fraud.
If they did it in JavaScript first and Java second they would have come to the opposite conclusion.
You have a valid point there.
I can only offer my own experience.
I had made a C++ server process that sucks up XML streams from multiple sources, filters that stream, sends some of it on it's way to a database, publishes the rest of it to anyone who subscribes to it. Not a big thing by any means but big enough for a comparison case.
So, I did the same thing in node. Whoah, a lot less code, a lot easier to write and test. And surprisingly about the same performance.
Much easier to maintain. That node version has since been twisted, bent and extended a great deal. I decided it would be much quicker and easier to do that than extend the original C++ version.
Given that experience I'm prepared to believe PayPal has a point. (OK I'm talking C++ not Java but that seems about equivalent to me. Except Java is worse.)
I do agree, if your VP, who presumably does not know assembler from BASIC is swayed by such presentations and cares not about the opinions of his engineers there something is deeply wrong. Hope his family gets to see him more.
On the other hand the engineers need to wise up as well:)
An npm install on a production machine should not be a problem. The repo it fetches from should be under the control of those same production guys. Like I said, you produce source code, they provide the environment that code runs in. After you deliver your source it's their ball. (Except of course that ball should pass through testing first). Really, how your organization uses your source should not be you problem.
A "logic bomb" is nothing more than a bug. All be it a bug that has been introduced by somebody intentionally. The companies review, testing, and traceability procedures should catch that like any other bug. Same as any other safety critical system.
The first web applications I built were in C++, and I didn't start using Java until late in the game. By that time a fairly robust web app ecosystem had developed that made web app development much simpler than C++. More to the point someone else put up with headaches and overtime dealing with platform bugs. For example the early Java garbage collectors were notoriously slow and CPU intensive, as were the initial JIT implementations.
Financial services are not like Twitter or Facebook. It's not important to keep up with the cutting edge. What is important is never having a second of downtime, losing track of money, and being perpetually risk adverse. Generally your customers complain when you make changes as they're older than the median age and hate changes, so it's smarter to take things slower than other industries.
I doubt that any high level programming language has such intrinsic advantages over another that it is worth platform instability. To switch platforms and take on such risk requires the advantages to be more clear cut than "I read a white paper by PayPal that said it was a good idea". If this switch goes poorly I will be working nights and weekends dealing with the fallout. But I won't hesitate to blame Node.js if it causes any production glitches, and that it's adoption was unwise given its novelty and lack of compelling advantages. I'm not the only one in my department that feels this way either.
In my personal opinion financial applications should still be written in COBOL. As a lot of them still are. COBOL is made for that.
Floating point is just not precise enough. The fact that 0.01 + 0.02 is not equal to 0.03 is simply a showstopper.
I did like the ride @heater talked me into using JavaScript for a web based editor/IDE. I had fun and learned a lot about features like functions returning functions, closures, lambda functions and all them goodies and cruelties JavaScript has.
But I could take him into a equal ride with features of COBOL I still miss in most other languages I was forced to learn over the decades. As a programmer you need to adapt to the problem domain and the workplace rules. Sometimes them decisions do not agree. But I as the guy programming the stuff have to use what I am told to use. Sometimes I was in a position to influence these decisions, sometimes not.
Is COBOL better than JavaScript? C better then C++ or C#? Java better the JavaScript or vice versa? ADA, Fortran, Modula2, Pascal, Perl, PHP better than whatever? I do not think so.
For me the language does not matter at all. After programming mainly in C# for 8+ years I had a job where VB.net was the language to use. Took a couple of days and some reading and I was fluent again. Last Basic I used was on a Atari 1040 STF in the eighty's. After not seeing any COBOL program since 1992 I had a short gig to dive into COBOL again last year. Helping out a friend of mine. Took me two days and I was back in COBOL mode, even remembered basic JCL commands...
It is always about what needs to be done. Then select the language best suited for the job. Or what the company wants ...
I doubt that any high level programming language has such intrinsic advantages over another that it is worth platform instability. To switch platforms and take on such risk requires the advantages to be more clear cut than "I read a white paper by PayPal that said it was a good idea"
msrobots
...select the language best suited for the job...
I do agree with you both. These are tediously sensible points of view that don't belong on a language war thread:) But out there in the real world we have to deal with the tedium of making things work correctly, reliably, maintainably etc.
Clearly swapping things out wholesale is asking for trouble. That of course is not what PayPal did. They built one little project in node as a trial. They covered their backs by developing the same thing in the old way with Java. It was an experiment. Had it failed it would not have been any kind of disaster for them. Just another development that did not work out.
Perhaps Martin's boss missed that detail of the PayPal node story.
Martin, I have the suspicion that your project is going to fail or be troublesome. You don't like the tools you are being forced to use. Your team feels the same way. The mere fact that it is being forced causes resentment and team discontent. There is no enthusiasm. Every feature of the new system is a "problem", nobody is looking at the positive side or even bothering to learn the language and it's ecosystem properly. It will drag on in a halfhearted manner until it falls over and dies.
At that point everyone involved will blame node, as you are already prepared to do before you even start. A self-fulfilling prophecy. They will say that in attempt to divert management's blame from them and the risk of all getting fired for incompetence. "If the PayPal and Walmart guys can do it how come you cannot" management will say "Please make your way directly to the exit"
If you're lucky the boss with the PayPal paper in his hand will be removed and you guys will be back to the old familiar grind.
Sorry to be so depressing, I do hope it's not really like that.
Seems to me we have strayed a long way from the subject of this thread. Recent discussion has not been about a language but many peripheral topics.
Choice of a programming language is rarely just about the actual language itself, the syntax and semantics. As pointed out above it's likely that many problems can be tackled with much the same level of difficulty in all manner of languages, C++, Java, C#, JS whatever. As far as the language itself goes.
There are so many other non-language considerations in making a platform decision:
Is the compiler/run time bug free?
Is it fast?
How much memory does it use?
Are there lot's of good dependable libraries for my problem domain available.
Is it a stable platform or are the API's changing every week?
Is the thing still supported? Is that support good?
Is there a thriving user base that can be called on for support and cross fertilization of ideas.
Is it easy to use?
Is it quick to develop with?
Does it cost money?
Is it open source?
Is it as cross-platform as is required.
Does it come from Oracle or Microsoft (Important to know so as to avoid such things)
What about licensing and patent encumbrances?
A lot of these considerations are more to do with marketing, politics, user community, personal preference, than actual language design. Although language design does impact a few of them like, is it possible to build a fast compiler for this language?, is it easy to use?
In short, if a node project fails it's quite likely nothing to do with poor old JavaScript the language as such:)
@msrobots
I look forward to your presentation on "Interesting features of COBOL". I guess it won't take long:) No seriously, I know nothing of COBOL.
Is COBOL better than JavaScript? C better then C++ ...For me the language does not matter at all
Up to a point. The languages you listed there are to a large extent all the same. Conceptual derivatives of FORTRAN and ALGOL. I could throw in similar languages I have used in the past, Coral 66, PL/M. They are all early block structured languages with variables and functions, constructs for decisions, loops and sequential statements. Some have an idea of types, some have an idea of objects.
Things get a bit tricky when looking to languages that emphasize very different programming styles. Lisp for list processing, Prolog for rule based systems, or the functional programming languages. Then, hopping from one to another is not just a case of adapting to a new syntax for basically the same concepts. It's a whole different mind set.
Aside: JS does not rightfully belong in the list you gave. It certainly has sophisticated features that only a few of them are starting to acquire recently.
Are some languages intrinsically better than others?
Well, we don't write in assembler much these days and nobody uses Smile or Forth. So I guess we can conclude some languages really are better.
If you want to do arithmetic on one thousand digit numbers then Python is clearly superior to most.
Floating point is just not precise enough. The fact that 0.01 + 0.02 is not equal to 0.03 is simply a showstopper.
Java has the BigDecimal class to address this need. In typical Nodes.js fashion it has four different ports of the class by J Random Developer which are not included in the base platform. This means we need to pick one, hope it works, get the code approved, and migrated to the internal repo to include it in the product. More red tape for something that should be built-in.
@Heater, add to your list. Does it come from an approved vendor so you can skip red tape, or for each feature you need will you need to fight red tape to use j random feature that should have been included with the base platform.
Update: here's a discussion if the use of the new operator is considered dangerous:
Ah, numbers. Well there is an actual language feature we can get our teeth into. Sadly the perilous state of numbers in computing today is more to do with the hardware than the languages and compilers.
As far as I can tell pretty much all languages have a completely brain damaged idea about handling numbers. Which is odd given that computers are supposed to compute with, well, numbers. You would think we got that right by now.
Firstly we have these crazy ideas about number types, 8 bit, 16 bit, 32 bit, 64 bit. signed or unsigned. Jeeze in a high level language that is all nonsense. Implementation details. At the high level what we want is numbers, if we are going to have types what we are interested in is the range of valid values of numbers.
Ada is the only language that I know that get's this right. There we have user defined number types with ranges. We have checks if a number is ever pushed out of range. We have checks when different number types are used together incorrectly.
Try adding 10 to INT_MAX in C, C++. C#, Java etc. Instant wrong answer, and worse still a silently wrong answer. That's nuts! So much for all that nice type checking your compiler does. It does not help.
The problem here of course is not the language design or compilers fault. It's that that is what the hardware does. Integer additions and other operations can overflow and there is no interrupt or trap generated to alert the running program or OS. (Except divide by zero for some reason). Putting overflow checks into the generated code would be a terrible performance hit.
For some reason processor designers prefer to use billions of transistors on caches, parallel execution and all kind of performance features but don't care to use a few transistors on helping with ensuring correct operation of the machine.
floating point - Well, floating point is plenty precise enough. The problem of 0.1 + 0.2 not equalling 0.3 is not a matter of precision. Rather it's a problem cause by the fact that you cannot represent decimal fractions perfectly in binary, no matter what precision you have.
It would be perfectly possible to build a floating point maths unit that worked in base 10. In fact IBM and others used to do that back in the day.
Again this is not the fault of languages and their compilers. The hardware designers just don't build base 10 math units.
Douglas Crockford (The Java Script guy) has a solution for this. He has defined a base 10 floating point number format, he calls it dec64, he is campaigning to have that adopted as a number type in some future version of JavaScript. Exactly so that JS plays nicely for the financial programmers. It's unlikely to happen I fear. You never know though, he did get the JSON format into the JS standard. http://dec64.org/ https://github.com/douglascrockford/DEC64
Martin,
You are very dismissive of J Random hacker. Luckily there are many of them and many of them do an excellent job. I imagine your Java code is compiled by a compiler and running in a JVM that are compiled by J Random hacker's GCC compiler. And the whole show runs on J Random hacker's Linux operating system.
I totally disagree that a bignum library should be included in a base run time. Did anyone in your company ever review, test, verify the BigDecimal class you have been using? If not why not?
Yes, approved vendor. As if that was a guarantee that the code is bug free and secure. I have to check the vendor to be sure it's not MS or Oracle or some other vendor in a foreign country whose machinations I'd rather not have to depend on.
The node.js bigdecimal.js module is actually Java code from Google compiled into JS.
How ironic.
Which makes me wonder, how about continuing to write all the financial calcs in Java, compile those modules to JS with GWT and drop them into the node application?
Heater, it's not a question of my liking or disliking J Random Hacker's code. It's not a question of an approved vendor's code being bug free, or even good. It's a question of my being able to use the code in question without a significant amount of red tape. If Linux wasn't supported by a contract from an approved vendor, I couldn't use that either.
Which makes me wonder, how about continuing to write all the financial calcs in Java, compile those modules to JS with GWT and drop them into the node application?
Why not keep using Java and avoid the GWT middleman.
I totally disagree that a bignum library should be included in a base run time. Did anyone in your company ever review, test, verify the BigDecimal class you have been using? If not why not?
I do get your point about approved vendors. It's just that that brings us to a world of non-technical reasons for deciding anything. Like does the vendors owner play golf with the customers owner?
Why not keep using Java and avoid the GWT middleman.
Because then you would miss out on all the node goodness:)
I start to wonder what is going on here.
The financial service industry is huge, banks, insurance, everything else, worldwide. It does nothing but deal with money. It's entire being is dependent on software now a days.
Aside: My friend used to get hand written statements of his account from Coutts Bank back in 1976. I wonder if they still do that for the royal families bank accounts?
So how come the finance industry has not created for itself a language that deals with the number type they like to use? Having to always use a library function to do simple addition seems totally primitive and dumb to me.
How come they have not pressured vendors into providing languages that support what they want?
They should be all over ECMA campaigning to get the dec64 format into JavaScript as a built in number type.
The world would thank them for getting Intel to put a base 10 maths unit into processors.
How come, with all their resources they have not gotten together and reviewed, tested, verified and approved a decimal number library for themselves?
Comments
Yeah. I should get a life.
Should I open a new thread to gather some new activity suggestions?
It looks like I have a lot of studying in GCC to do.. no time for JavaScript.
Asking for new activity suggestions is rather dangerous around here.
I would not bank on it.
Still, I know young kids today who can send huge numbers of texts in one medium or another every day. A 7.06 average is pretty paltry by comparison.
@Heater, another problem with dynamic languages is security. The ability to eval JSON always carries a risk of malicious script injection and is a vector for attack. Compiled languages are less vulnerable because you need to know the underlying machine architecture to inject code via a buffer overflow attack. Plus the addition of the execute disable page protection and address space randomization has greatly reduced the efficacy of this attack. Google JSONP insecure or the BeEF Project for more information.
BTW if you ever develop an urge to become a professional wrestler and move to Brazil you'll know that it is time to lay off the Javascript. Meanwhile the MongoDB fan boys in my office are making me want to move to a pig farm.
Your posts, here are irresistible as you have an amazing talent to pack so many false assertions into a single paragraph
So let us proceed with this mornings batch: This is just wrong. See below.
Having a Java supporter make an argument based on security makes me chuckle, given the number of vulnerabilities in Java that have been exposed in this last year or so. True but..
1) The first thing a new JS programmer learns is that "eval is evil". My editor even highlights use of eval with a big red dot and uses that exact string as the error message! Just don't do that.
2) If you care one tiny little bit about security why are you tying to run any old untrusted code fetched from somewhere else? The problem here is not the language but the programmers.
3) Quite why browsers allow script tags to execute code from other than the origin domain is beyond me. So you have a point there. But again it's the creators of the web page making the problem not JS.
4) If I really want to I can run any old code you give me in a safe way. https://github.com/NeilFraser/JS-Interpreter Given the history of computer viruses and other exploits in the passed decades and the resulting wide spread use of virus scanning software today that statement is looking rather tenuous. Oh and did I mention those Java security vulnerabilities? And did you hear about the resent SSL security holes?
I might want to join you on the pig farm. There has been talk in our office recently of using Java and RPC...
The problem is that evaluation, JSON, and JSONP are all tangled up in big ball of wibbly wobbly insecurity. It's not as simple as don't explicitly call eval, sometimes the eval is performed implicitly by a library and is intrinsic to the way JSONP works. Now you can say don't use JSONP, but Javascript's same origin policy can force you to use it. Client side mashups have become popular in recent years and sometimes to compete with other vendors you are forced to integrate such features. There's also the issue of including code via script tags from a CDN which is desirable for performance, but opens up your app to script injection if the CDN is compromised.
Most of these flaws are problems with the implementation of the JVM, not the underlying language specification. Javascript's security problem is foundational and you can't release a patch to untangle the big ball of wibbly wobbly insecurity.
None of this is the fault of JavaScript the language. Or at least most of it is not.
Your example of JSON/JSONP is a good case in point. And one that has been bugging me for a long time.
Browser "security policy", if we can call it that, dictates that I cannot fetch data from some "foreign" server. However I may run scripts from foreign servers. As you said that could be library scripts I want to use, it may be "mashups", it may be to do with advertising or Facebook likes or Google analytics or whatever.
Why in God's name was that ever allowed? I mean ever?
When I, the surfer, go to your web site I have said "I want to go to Martin's web site". What I have not said is "Oh by the way browser, go ahead and fetch whatever from wherever and run any old code from any old backstreet server Martin points you at".
In my book this is all to do with the web standards and the way browsers work not JS the language itself.
eval may be evil but is also a powerful and useful feature when you need it. If you think about it it's is nothing special. Think about compiled code, say C++, here we can use dynamically loadable libraries. We can load code that we have never seen before on demand at run time and call it. Think "plugins". One could imagine that in the current web set up a browser could fetch a program from my site then fetch some library code from your site. BANG we are in the same situation as we are now. I guess the same can be done in Java.
It's just a bad idea to load and run untrusted code no matter if you do it at binary, bytecode, or source level. Hey, that's not fair. You are changing the rules of engagement in the war. Rules that you yourself made up.
When I suggested we discuss JavaScript the language as opposed to the crappy browser environment it often runs in you said that was not right as the browser is the predominant platform for JS.
Now you are separating Java, the language, from it's VM. Which way do you want it?
Makes no odds to me. Java is still a crappy language with no interesting features even when conceptually divorced from it's bloated and security hole ridden run time.
Yes it's a "wibbly wobbly" world. It's not the languages fault in either case.
Good question. Web browsers as an application platform are really crude.
Fair enough, I'm willing to conclude that they're both lousy languages. We should go back to native clients in C++ and ditch Web apps entirely.
Don't get me started on C++. That infinite fractal of complexity and broken features that not even its creator understands any more. Wish I could link you to the moment in one conference video where Bjarne is asking the presenter to explain how the piece of C++ on the screen does not work as it first might seem. Magic. I used to think it was me that was too stupid to hold the whole thing in my mind. Seems not to be so.
If you read Bjarne Stroustrup's books or watch his presentations he can explain very carefully and convincingly why every little feature is in the language and why it is the way it is. Every step of the way he can convince you that the whole thing makes perfect sense and that is the only way it could be.
However the final edifice is a tower of babel.
Still I will always return to my first love C and her daughter C++. They let me do anything.
Because JavaScript is not compiled, a good chunk of your unit tests are all about enforcement of the contract the code wants to create. But those unit tests need not be written at all with Java, so we have a much greater number of unit tests for roughly the same code coverage. It looks good on a dashboard showing the total number of unit tests, so it's got that going for it.
Any time saved by not compiling code and fast startup is lost running all the extra unit tests.
The lack of threads means all I/O is nonblocking, which means a liberal use of continuation functions. The result is really nasty looking code with nested layers of lambda functions.
Every time I see if (typeof x == "undefined" || x == null) I die a little.
The value of a common server side versus client side language is overblow because the problem domains are so different. Client side is usually worried about UI element manipulation and workflow. Server side code is all about request validation, data acquisition, and response formatting. There's almost no overlap with these concepts and your typical CSS Jockey could care less about the latter, while the server side programmer views CSS and DOM manipulation as the gross hacks that they are.
By default Node.js doesn't have an access log (I.e. an audit trail of all requests). Sure you can add logging, but this is something a server stack should do out of the box to be credible.
Node.js uses often uses patform specific packages that are pulled down and compiled for the OS variant you are on. This means that your build and packaging machine must be the same OS as your target runtime. Java already went through this nonsense and went with 100℅ pure Java because you often develop on small iron and run on big iron.
So my overall opinion is that it is not ready for primetime, but groupthink means we're stuck with it.
Oh goody the JS war is back on. It's been a bit of along lull:) Wow, that's great. Welcome on board. Let me see what I can do to help. I know nothing of the JavaServelet ecosystem so I can't comment on that. Except of course that Java is a language with no compelling features and no reason to exist. As for "done poorly", how can that be? it works very well for many. This is not my experience. Pretty much all the packages we use work as advertised. We have occasionally stumbled into bugs, reported them to the package creators and seen them fixed in short order.
What packages are giving you trouble? An what problems exactly? In terms of code coverage I do not see how JS requires more unit tests than Java. Presumably there are a similar number of pathways though your code no matter which language. And you will be wanting to exercise all those pathways, right?
In fact I would wager that you have less pathways to cover with a JavaScript solution because I convinced you have to write less code to get the same job done a lot of the time.
Admittedly you may want more unit tests to cover the possibility of incorrect types being passed around. However normally you you only need those at API boundaries so it's only a small burden. You should be exercising you system for invalid inputs anyway. How so? I don't know about you but I'm not running all my unit tests all the time. Certainly before pushing changes back to github. Then unit tests don't normally take very long. Ah yes, the dreaded "callback hell". In my experience most of the time there are not so many layers and it does not bother me. When they get too nested things get ugly as you say. That's easily fixed by using the async module or promises. Not much of a problem and preferable to threads anyway. Sounds like you are doing some input validation there. Not much worse that the input validation you see in any other language or those "asserts" you see scattered around. I disagree that problem domains are so different. In fact they are very similar.
What I'm seeing is that it's all about responding to events both on the server and in the browser.
On the server the events are requests or responses from databases queries or other data arriving that needs dealing with.
In the client the events are user input, mouse, keyboard, form submissions and so on. Not to mention responding to incoming data events from AJAX requests or web sockets etc.
It's all asynchronous processing at server and client. Conceptually the same. I agree, I hate CSS and DOM and even HTML. I try to avoid them as much as possible and try to get someone more enthusiastic about it to do it. Or make use of libraries and frameworks that make dealing with that Smile less painful.
But we are not here to discuss CSS/DOM/HTML. That is a good thing. Node is a run time with some core functionality built in. Higher level functionality belongs in modules. Node is not a web server stack, despite having http built in. I presume you are using express for you web server stack. In which case logging is only a line of code away. It's all quite credible. No.
Firstly I don't include the node_modules directory in my projects repository or any deliverable. As far as I'm concerned that is nuts because: a) It bloats out my repo with a ton of stuff I did not create. I don't expect my project to carry all it's dependencies around in other languages, why would I do it here. b) Those modules will not run without a rebuild on other platforms, ARM, MIPS etc.
If you have a package.json file when you ship your project a quick "npm install" will get you all the required modules at the specified versions.
If you really want to be sure you are shipping a running system package it all up in a container. Docker is great for this. Then you have something that is sure to work in any interesting place. It's a great idea whether using JS or anything else. No doubt. There are some big players using JS and node on big projects. It's already hit prime time... I don't know, JS and node saved my bacon when I discovered them a couple of years ago. I thought it was a crazy experiment but it worked out well. There was no "group" around me to push me along.
I'm sure the world will only be "stuck with it" until the next big fad silver bullet comes along:)
If you are feeling adventurous try out a recent node version and set the "harmony" flag on. Then you can use a lot of features from the new ES6 standard of JS. ES6 has a lot of features that address your concerns, like the callback hell for example.
Edit: Oh yeah. Don't forget to always use jslint on your code. I love to use the Sublime text editor with the jslint plugin. It highlights all kind of fopars as you type.
Don't complain that jslint hates your code formatting and use of white space. Just do what it says. Everybody on the project should.
Wow. Lot's of points to respond to.
Personally, Javascript is my favorite language, and I actually like the non-blocking callback aspect. In fact, it seems like most of your critiques are a direction of personal preference. And my preference goes the other way.
"Any time saved by not compiling code and fast startup is lost running all the extra unit tests." Why run all the tests anyway? Why not just run tests for the changed file, then save the rest for every 15 minutes or so?
Re stacks: I use Hapi.js for my Node server. It includes everything that I want, including built in logging, and it's more than "almost works". The much more popular Express also includes logging, as does Strongloop's loopback and Sails.js. Logging is not built into the language, but I don't see why it should be. Using a module is a seamless drop in.
For writing unit tests I don't bother with input type validation. Why? Because Hapi includes request query validation which ensures that all user inputs to the system are run through filters. So, it's the correct type anyway. And I've found in general that Javascript, despite being weakly typed, is remarkably forgiving of parameters. If a wrong type is given to a function I either find it immediately or it's not a problem.
Why have a build system at all? npm works fine wherever you are.
A common language is not overblown at all, especially for small companies. I do all the programming, and in one day I work on both the client side and sever side in tandem. It's incredibly helpful not to have to switch between languages or development environments when I program.
If you just ship your code there is a very real danger that whoever is deploying it will "npm install all required packages" and the resulting set up will contain different module versions than those that the code was developed and test against. This can be disastrous when newer packages with breaking changes get used.
Using a package.json file, which specifies specific module versions, cures most of these ills. With a package.json file whoever deploys the thing will get the same versions as the developer.
This can still fail in some odd cases when module sub-dependencies go wrong. If this is a real worry it can be fixed with "shrinkwrap" http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/
Ultimately the way to go, whether using node or Python or whatever is to package the running system into Docker containers. Then you have your app and everything it needs to run in a container that can then be deployed on Google cloud, AWS, MS Azure, Digital Ocean and many other places including your own servers.
With Docker the developer, the testers, the deployment are essentially always in the same environment.
Here is some of it again:
var ﻝ = { ﺍ: function () { return ("Hello world!"); } } var msg = ﻝ.ﺍ(); console.log(msg);I'm sure a lot of fun can be had with this:)One example is the high level HTTP Request class doesn't support POST with a query string even though it's something some legacy backends do. So we need to use both the low level HTTP class and the high level Request class.
This is not a correct assumption. For all functions you need to write unit tests to ensure that the required number of a parameters are passed and are of the correct types. You don't do that with Java because the compiler enforces that. So you automatically have more busy work unit tests to write with JavaScript.
On the server side aggregation is a common pattern. So you'll often query multiple backends in sequence (sometimes in parallel) and join the results. Blocking I/O makes this fairly trivial to code. Non-blocking I/O means having to figure out when all the I/O's are complete so you can join the results.
Client side processing is event based, but server side processing is more like a pipeline (at least in financial services). You gather and scrub inputs, query a database, possibly use the output as inputs to another query, then format a response. It's not event based at all.
In financial services there's always an assumption of mistrust between the various tiers of the organization. The security group assumes that developers are trying to slip a logic bomb into the production machines to allow them to compromise them. The production team assumes that developers must not touch a production machine or they'll slip a logic bomb onto it. This paranoia developed because these sort of events actually happened in the past.
The code development produces must be compiled into a sealed package that will be delivered to QA to be tested and unaltered in anyway after that point. Running an "npm install" on a production machine which pulled code from a repo (even an internal one) would violate this chain of mistrust. Honestly I expect someone to get fired the first time they run npm install on a production machine.
This is of course not exactly a JavaScript language issue. No, why?
If functions/methods are getting parameter types they cannot handle the function is going to fail to produce the correct results. That failure should be picked up by the rest of your tests.
Similarly for incorrect number of parameters.
The only difference is that the error is detected at run time (test time) instead of compile time.
Given that you need to test your code comprehensively anyway having the compiler do the type and arity checking is kind of pointless. This can get hairy. Still, async or promises makes it trivial again. I'm not so sure about the parallel case having never had to do that much. But async seems to have it covered:
async.parallel([ function(){ ... }, // Make some DB query function(){ ... } // Make some other DB query at the same time. ], callback);Blocking I/O does not make this trivial unless you introduce threads. Then it's not trivial anymore:) Please show equivalent Java code to the above. So we have:1) "gather...inputs." - That's events.
2) "query a database." - The responses from the DB are events.
3) "use the output as inputs to another query," - The responses are more events.
Looks like it's all event based to me. Oh boy. Given that your organization is so paranoid (quite rightly) their entire system is back to front.
"The code development produces must be compiled into a sealed package that will be delivered to QA to be tested and unaltered in anyway after that point." So they have immediately set themselves up for the "logic bomb" they are trying to avoid.
I worked for many years in the aerospace industry. Guys building fly by wire systems, Boeing 777 for example, are very paranoid. I'm going to assume that a "logic bomb" is actually just a bug you don't want creeping into the system. Here was the deal:
1) As a developer I produce source code to some specification.
2) My code goes to review. At least two guys had to sign it of as meeting the spec.
3) Someone else would be writing the tests of my code. Again, test are derived from the spec.
4) Those tests go to review. At least two guys had to sign the of the tests as providing the correct coverage, expected results etc.
5) Somebody does the unit testing. Again a couple of sign offs.
6) Meanwhile, all the common libraries and stuff my code may depend on is produced and/or verified by similar processes, perhaps within a totally different group. Not by me.
7) Then of course there is the integration, integration testing and delivery phases. More like the above.
The reason I say your organization is inside out is that you, as a developer, should only be delivering the source code that you produce. Not a pile of random node modules that go with it.
It's up to the rest of the paranoid organization to acquire, create, verify, test every module and other component they will be using along with your code. No why?
When they do that they should be fetching from the organizations own private npm repository that contains only code they have audited, verified, tested, approved.
When it comes to "sealed package that will be delivered to QA" it sounds like a Docker container would fit their bill just fine. (All be it a backward solution to the paranoia issue)
You wouldn't happen to work for PayPal would you? A financial service company that seems to be very happy with node. https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
Do have a read. Here is the bottom line:
Built almost twice as fast [development] with fewer people
Written in 33% fewer lines of code
Constructed with 40% fewer files
Double the requests per second vs. the Java application.
35% decrease in the average response time
What's not to like?
But my seeing that isn't the problem. A rather arrogant VP saw it and thinks he's discovered a silver bullet. Any negative feedback or pointing out the obvious fallacy in that presentation is perceived as a negative attitude or incompetence. Personally I'm hoping his arrogance gets him fired so he can spend more time with his family. Then we can undo all of his bad ideas, including Node.js, especially Node.js.
An npm install on a prod machine will get you fired because production reports to a different senior manager. Pulling code from a repo on to a production machine will get you fired because production reports to a different sent manager. It's that simple.
Edit: A logic bomb is a backdoor that could be exploited for financial fraud.
I can only offer my own experience.
I had made a C++ server process that sucks up XML streams from multiple sources, filters that stream, sends some of it on it's way to a database, publishes the rest of it to anyone who subscribes to it. Not a big thing by any means but big enough for a comparison case.
So, I did the same thing in node. Whoah, a lot less code, a lot easier to write and test. And surprisingly about the same performance.
Much easier to maintain. That node version has since been twisted, bent and extended a great deal. I decided it would be much quicker and easier to do that than extend the original C++ version.
Given that experience I'm prepared to believe PayPal has a point. (OK I'm talking C++ not Java but that seems about equivalent to me. Except Java is worse.)
I do agree, if your VP, who presumably does not know assembler from BASIC is swayed by such presentations and cares not about the opinions of his engineers there something is deeply wrong. Hope his family gets to see him more.
On the other hand the engineers need to wise up as well:)
An npm install on a production machine should not be a problem. The repo it fetches from should be under the control of those same production guys. Like I said, you produce source code, they provide the environment that code runs in. After you deliver your source it's their ball. (Except of course that ball should pass through testing first). Really, how your organization uses your source should not be you problem.
A "logic bomb" is nothing more than a bug. All be it a bug that has been introduced by somebody intentionally. The companies review, testing, and traceability procedures should catch that like any other bug. Same as any other safety critical system.
Financial services are not like Twitter or Facebook. It's not important to keep up with the cutting edge. What is important is never having a second of downtime, losing track of money, and being perpetually risk adverse. Generally your customers complain when you make changes as they're older than the median age and hate changes, so it's smarter to take things slower than other industries.
I doubt that any high level programming language has such intrinsic advantages over another that it is worth platform instability. To switch platforms and take on such risk requires the advantages to be more clear cut than "I read a white paper by PayPal that said it was a good idea". If this switch goes poorly I will be working nights and weekends dealing with the fallout. But I won't hesitate to blame Node.js if it causes any production glitches, and that it's adoption was unwise given its novelty and lack of compelling advantages. I'm not the only one in my department that feels this way either.
Floating point is just not precise enough. The fact that 0.01 + 0.02 is not equal to 0.03 is simply a showstopper.
I did like the ride @heater talked me into using JavaScript for a web based editor/IDE. I had fun and learned a lot about features like functions returning functions, closures, lambda functions and all them goodies and cruelties JavaScript has.
But I could take him into a equal ride with features of COBOL I still miss in most other languages I was forced to learn over the decades. As a programmer you need to adapt to the problem domain and the workplace rules. Sometimes them decisions do not agree. But I as the guy programming the stuff have to use what I am told to use. Sometimes I was in a position to influence these decisions, sometimes not.
Is COBOL better than JavaScript? C better then C++ or C#? Java better the JavaScript or vice versa? ADA, Fortran, Modula2, Pascal, Perl, PHP better than whatever? I do not think so.
For me the language does not matter at all. After programming mainly in C# for 8+ years I had a job where VB.net was the language to use. Took a couple of days and some reading and I was fluent again. Last Basic I used was on a Atari 1040 STF in the eighty's. After not seeing any COBOL program since 1992 I had a short gig to dive into COBOL again last year. Helping out a friend of mine. Took me two days and I was back in COBOL mode, even remembered basic JCL commands...
It is always about what needs to be done. Then select the language best suited for the job. Or what the company wants ...
Enjoy!
Mike
Clearly swapping things out wholesale is asking for trouble. That of course is not what PayPal did. They built one little project in node as a trial. They covered their backs by developing the same thing in the old way with Java. It was an experiment. Had it failed it would not have been any kind of disaster for them. Just another development that did not work out.
Perhaps Martin's boss missed that detail of the PayPal node story.
Martin, I have the suspicion that your project is going to fail or be troublesome. You don't like the tools you are being forced to use. Your team feels the same way. The mere fact that it is being forced causes resentment and team discontent. There is no enthusiasm. Every feature of the new system is a "problem", nobody is looking at the positive side or even bothering to learn the language and it's ecosystem properly. It will drag on in a halfhearted manner until it falls over and dies.
At that point everyone involved will blame node, as you are already prepared to do before you even start. A self-fulfilling prophecy. They will say that in attempt to divert management's blame from them and the risk of all getting fired for incompetence. "If the PayPal and Walmart guys can do it how come you cannot" management will say "Please make your way directly to the exit"
If you're lucky the boss with the PayPal paper in his hand will be removed and you guys will be back to the old familiar grind.
Sorry to be so depressing, I do hope it's not really like that.
Choice of a programming language is rarely just about the actual language itself, the syntax and semantics. As pointed out above it's likely that many problems can be tackled with much the same level of difficulty in all manner of languages, C++, Java, C#, JS whatever. As far as the language itself goes.
There are so many other non-language considerations in making a platform decision:
Is the compiler/run time bug free?
Is it fast?
How much memory does it use?
Are there lot's of good dependable libraries for my problem domain available.
Is it a stable platform or are the API's changing every week?
Is the thing still supported? Is that support good?
Is there a thriving user base that can be called on for support and cross fertilization of ideas.
Is it easy to use?
Is it quick to develop with?
Does it cost money?
Is it open source?
Is it as cross-platform as is required.
Does it come from Oracle or Microsoft (Important to know so as to avoid such things)
What about licensing and patent encumbrances?
A lot of these considerations are more to do with marketing, politics, user community, personal preference, than actual language design. Although language design does impact a few of them like, is it possible to build a fast compiler for this language?, is it easy to use?
In short, if a node project fails it's quite likely nothing to do with poor old JavaScript the language as such:)
@msrobots
I look forward to your presentation on "Interesting features of COBOL". I guess it won't take long:) No seriously, I know nothing of COBOL. Up to a point. The languages you listed there are to a large extent all the same. Conceptual derivatives of FORTRAN and ALGOL. I could throw in similar languages I have used in the past, Coral 66, PL/M. They are all early block structured languages with variables and functions, constructs for decisions, loops and sequential statements. Some have an idea of types, some have an idea of objects.
Things get a bit tricky when looking to languages that emphasize very different programming styles. Lisp for list processing, Prolog for rule based systems, or the functional programming languages. Then, hopping from one to another is not just a case of adapting to a new syntax for basically the same concepts. It's a whole different mind set.
Aside: JS does not rightfully belong in the list you gave. It certainly has sophisticated features that only a few of them are starting to acquire recently.
Are some languages intrinsically better than others?
Well, we don't write in assembler much these days and nobody uses Smile or Forth. So I guess we can conclude some languages really are better.
If you want to do arithmetic on one thousand digit numbers then Python is clearly superior to most.
Horses for courses, as you said.
Java has the BigDecimal class to address this need. In typical Nodes.js fashion it has four different ports of the class by J Random Developer which are not included in the base platform. This means we need to pick one, hope it works, get the code approved, and migrated to the internal repo to include it in the product. More red tape for something that should be built-in.
@Heater, add to your list. Does it come from an approved vendor so you can skip red tape, or for each feature you need will you need to fight red tape to use j random feature that should have been included with the base platform.
Update: here's a discussion if the use of the new operator is considered dangerous:
http://stackoverflow.com/questions/383402/is-javascripts-new-keyword-considered-harmful
Can't make this stuff up. I guess the saying JavaScript is a terrible language with a bright future is true.
As far as I can tell pretty much all languages have a completely brain damaged idea about handling numbers. Which is odd given that computers are supposed to compute with, well, numbers. You would think we got that right by now.
Firstly we have these crazy ideas about number types, 8 bit, 16 bit, 32 bit, 64 bit. signed or unsigned. Jeeze in a high level language that is all nonsense. Implementation details. At the high level what we want is numbers, if we are going to have types what we are interested in is the range of valid values of numbers.
Ada is the only language that I know that get's this right. There we have user defined number types with ranges. We have checks if a number is ever pushed out of range. We have checks when different number types are used together incorrectly.
Try adding 10 to INT_MAX in C, C++. C#, Java etc. Instant wrong answer, and worse still a silently wrong answer. That's nuts! So much for all that nice type checking your compiler does. It does not help.
The problem here of course is not the language design or compilers fault. It's that that is what the hardware does. Integer additions and other operations can overflow and there is no interrupt or trap generated to alert the running program or OS. (Except divide by zero for some reason). Putting overflow checks into the generated code would be a terrible performance hit.
For some reason processor designers prefer to use billions of transistors on caches, parallel execution and all kind of performance features but don't care to use a few transistors on helping with ensuring correct operation of the machine.
floating point - Well, floating point is plenty precise enough. The problem of 0.1 + 0.2 not equalling 0.3 is not a matter of precision. Rather it's a problem cause by the fact that you cannot represent decimal fractions perfectly in binary, no matter what precision you have.
It would be perfectly possible to build a floating point maths unit that worked in base 10. In fact IBM and others used to do that back in the day.
Again this is not the fault of languages and their compilers. The hardware designers just don't build base 10 math units.
Douglas Crockford (The Java Script guy) has a solution for this. He has defined a base 10 floating point number format, he calls it dec64, he is campaigning to have that adopted as a number type in some future version of JavaScript. Exactly so that JS plays nicely for the financial programmers. It's unlikely to happen I fear. You never know though, he did get the JSON format into the JS standard.
http://dec64.org/
https://github.com/douglascrockford/DEC64
Martin,
You are very dismissive of J Random hacker. Luckily there are many of them and many of them do an excellent job. I imagine your Java code is compiled by a compiler and running in a JVM that are compiled by J Random hacker's GCC compiler. And the whole show runs on J Random hacker's Linux operating system.
I totally disagree that a bignum library should be included in a base run time. Did anyone in your company ever review, test, verify the BigDecimal class you have been using? If not why not?
Yes, approved vendor. As if that was a guarantee that the code is bug free and secure. I have to check the vendor to be sure it's not MS or Oracle or some other vendor in a foreign country whose machinations I'd rather not have to depend on.
Hey, I just found out who J Random Hacker is.
The node.js bigdecimal.js module is actually Java code from Google compiled into JS.
How ironic.
Which makes me wonder, how about continuing to write all the financial calcs in Java, compile those modules to JS with GWT and drop them into the node application?
Why not keep using Java and avoid the GWT middleman.
We did not. Sun and Oracle are approved vendors.
I do get your point about approved vendors. It's just that that brings us to a world of non-technical reasons for deciding anything. Like does the vendors owner play golf with the customers owner? Because then you would miss out on all the node goodness:)
I start to wonder what is going on here.
The financial service industry is huge, banks, insurance, everything else, worldwide. It does nothing but deal with money. It's entire being is dependent on software now a days.
Aside: My friend used to get hand written statements of his account from Coutts Bank back in 1976. I wonder if they still do that for the royal families bank accounts?
So how come the finance industry has not created for itself a language that deals with the number type they like to use? Having to always use a library function to do simple addition seems totally primitive and dumb to me.
How come they have not pressured vendors into providing languages that support what they want?
They should be all over ECMA campaigning to get the dec64 format into JavaScript as a built in number type.
The world would thank them for getting Intel to put a base 10 maths unit into processors.
How come, with all their resources they have not gotten together and reviewed, tested, verified and approved a decimal number library for themselves?