It's also why people turn to dynamic languages like JS, PHP, Python, etc etc etc. So that they can get stuff out the door in time with out fighting with the compiler all day.
(Errr, that is not one of my arguments for JS by the way)
Perhaps not by you, but slinging code out the door as fast as possible is the more common argument being made. You can also count on a conspicuous lack of unit tests among people with that philosophy.
Recently I decided to catch up with what is new in C++ with the C++11 standard.
I was gob smacked. They are trying really hard to make C++ into JavaScript !
For example:
auto - So that you don't have to write out types so much.
range based for loops - Because C style loops are so clunky.
unique_ptr, share_ptr - Because all that manual memory management is a
pain.
lambdas - Because , well, all the cool kids like JS have them
move semantics - Because, well its that memory management thing again.
initializer lists - That's a good JS idea, we'll have that.
Now, when you put all that together and write code with it, it's like using a totally new language, not like old and ugly C++ at all.
JS was a very good inspiration for the C++ committee
Who cares about type safety? In my favorite language, Perl, there are scalars, arrays, hashes, code, typeglobs, and references to the foregoing. Scalars can be integers, floating-point numbers, strings (including the empty string), or undef. If a string contains a number, it can be treated like a number -- hey, no problem! Or you can concatenate stuff to a number to make a string. What could be more natural?
But this thread isn't about Perl. I just wanted to point out a language that totally lacks type safety, yet enjoys considerable success and adherents like me who feel comfortable with messy, laissez faire languages.
Phil beat me to it. Perl will let you do just about anything you want to. I've written in Perl 3 in the past. Never kept up, but it felt a lot like SPIN does to me in that respect. Just simple, does what it says and it's up to you to make sure you ask it to do something that makes sense.
[hands Phil the bowl]
I think Perl is pure magic at times. For about a year, I worked with somebody who knew Perl inside and out. Frankly, they could knock out the most difficult and painful data transforms quickly... Say what you want, but that tool box is powerful, IMHO.
You never update your language or runtime in the middle of a project.
Yes. Agreed. But this is true, until it isn't. Sometimes external dependencies require this happen. Enterprise applications run into this mess all the time. And they are broken all the time too. Patch, after patch, after patch. Sysadmins all over the place doing more patching than administration. The vendor I work with has recently doubled up on regression testing as well as started unit testing. Secondly, they test on a battery of existing datasets. Much improved. Still patches, but now they have new stuff in them more than they have fixes.
For smaller things, I prefer loose languages. They are lean, you don't have to know as many things to get it done, and they are great for first pass, "intend to throw it all away" prototypes / tech validation kinds of things.
This discussion is making me want to go try Javascript. Hmmm... Yes Heater, it's on my list. Moving up.
True. I've used Perl in the past (still do once in a while) usually for quick little one-off things, and much of what Phil says is exactly right - which no doubt carries over to the JavaScript debate as well.
I'd argue against Perl, but I don't have a strong enough gag reflex to deal with the language for more than a few minutes at a time.
Heater, actually it sounds like they are borrowing from C# which has all of those things, but is still typesafe.
Another argument against JavaScript is that there's two types of people in your typical Web shop. The CSS HTML people who have often have a design background and a passion for how the product looks. They know JavaScript well enough to do event handlers and possibly XHR requests, but generally are not programmers. Then there are many programmers who know how to build databases, scale them, and write the code to pull the whole thing together. These are two very different skills and it's rare to find a person who cares about both.
But to management this looks like duplication of staffing, or at least a lack of ability to rotate staff flexibly. What they want is one person who can do things front to back and think a lack of a common language is the reason the HTML/CSS people can't do server work. It's not and using Node.js won't enable this, but they'll orphan their existing code base.
...actually it sounds like they are borrowing from C# which has all of those things, but is still typesafe.
Except of course whatever C# has it must have borrowed from JS as JS was there first!
Another argument against JavaScript is...
None of that people and management stuff is the fault of JS.
Personally I have tried to keep away from "web stuff" as much as possible. I mean all that HTTP, HTML, CSS, XML, DOM madness. Then throw in PHP, SQL. God it's a mess. I don't know how the guys who do that keep their sanity. I had the misfortune to work on such things for nearly a year last century. I decided life was too short for that.
A few years back it came up that we needed to get data out of remote units in the field and create visualizations, in "real time" in the browser, I went into a panic.
Luckily I soon discovered I could do all the graphical stuff in webgl, and pipe the data around with websockets. On the server end I could get the data out of our server processes (c++) as an XML stream and connected to the browsers websocket connections via a simple publish/subscribe mechanism implemented in node.js. Easy.
The thing was up and running in a month.
And hurray! I could leave all the HTML, CSS, PHP gunk to to some other shmucks in the company:)
They said I was crazy. "webgl and websockets don't work on IE", "they are too new", bla bla. "You need FLASH, and long polling" and all kind of other web garbage.
I insisted it goes my way or they find someone else. And by the way no one cares about IE any more. Luckily it all worked out.
Aside: They did even hire a FLASH expert to create the same visualizations because they did not trust I could do it. His version never worked and the budget for his contract ran out many weeks after after I finished the webgl version.
Since then the the JavaScript has moved down to the field units, they arm ARM based and can run node.js well enough. The XML streams have been replaced with JSON over websockets and the C++ server processes have been replaced with...node.js.
This whole show runs with about the same CPU loads and memory consumption as the old C++ stuff, and is ten times easier to work on.
Ah, you say, "it will all collapse when the code base gets too big and the project becomes unmanageable".
We shall see
Point of the story is, I owe my sanity to exactly that phenomena of having the same language in the browser, on the server and now in the field units. It means I can get my job done without having to tangle with PHP at least:)
I'm not about to give up my beloved C/C++. It is the other language you need. (How else would they write JS engines?)
I can't imagine working on JavaScript without jslint to check the thing over before I run it. That is not compile time type checking but it does at least something to keep you away from Javascripts traps and surprises.
alert a
-- 3
alert b
-- 3
alert a + b
-- WHAT APPEARS HERE?
If you answered either 6 or 33 you're wrong, because it could have been the other one. Typing this weak isn't useful, it is suicidally stupid and creates all sorts of problems that newbies are not really equipped to deal with, and learning to deal with those problems won't teach the n00bs real skills as far as understanding how actual computers work.
Agreed Phil it would be less of a problem if numeric addition and string concatenation didn't use the same operator, but there are other less gag-inducing instances where the weak typing still causes problems. BASIC was headed toward sanity in this area with & instead of + for concatenation but it tripped over a trillion lines of legacy code and something dot something net.
If you install node.js then you can use it's module manager to install jslint
$ nmp install jslint
http://nodejs.org/
However it's best to have jslint in your editor, then it highlights potential dangers on the fly as you edit.
my question for you is: "Is there an alternative language for client scripting in a browser on all platforms?"
Yes, C and C++.
You can compile C and C++ into JavaScript with Emscripten and run your programs in the browser. The fft_bench.c runs about a quarter native speed in firefox.
There are other languages especially designed to compile to JS offering better type safety etc if you like. Can't think what they are called now.
localroger,
Surprised nobody has brought this up yet....
I thought they did already.
Turns out that it's not actually a big problem in practice. It hardly ever happens and you know it soon enough when it does. It's a far less insidious problem than integer overflows or operator precedence mistakes in C++ for example.
I learned JavaScript back in September and have built up a pretty complex website since them. I'm using Node.js and Cassandra to work with large data sets (20 million points each) and it's working better than I could have hoped.
I've come to a good synergy. I have Node.js handle all of the web things, and have some Java applications deal with the data processing (the math intensive algorithms). This fits well because it offloads into a different process (and possibly server core) all the stuff that JavaScript doesn't excel at. Plus I'm a better Java programmer.
Even with all the math being done in Java, my experience with JavaScript has been nothing but good. I've been able to make a website that deals in big data, and make the website quickly and with a minimum of problems. In large part that's due to all the JavaScript based libraries out there, and the easy integration. I can pull in a library for everything from templating to time management to data display.
As far as the language itself I quite like it. The stupid "type" mistakes that I make almost always get caught the first time that I try the code. Personally, I'd prefer to have a compiler but the IDE lint tools are a good compromise.
And I really like callbacks. It makes the code easy to control (no more while(done == false){} type things).
@Heater, I Lol'd on those videos. I loved the line "Node.js, it's people like you who set human progress back 1000 years." and that the JavaScript programmer uses Google to solve their problems and was a professional wrestler.
@Jazzed, at the present time JavaScript is still the only game in town across browsers. But Microsoft's Typescript compiles to JavaScript so you can use it to address some of the problems I pointed out. It's basically a JSLint on steroids. Google has similar but incompatible technology.
Honestly, I can deal with JavaScript for small stuff in the browser, but spending six months with a team of ten people cranking out a large software system for Node.js is not something that I am looking forward to.
Aside: They did even hire a FLASH expert to create the same visualizations because they did not trust I could do it. His version never worked and the budget for his contract ran out many weeks after after I finished the webgl version.
That's about what happened to me. Except we hired a web guy to do the work, and 6 months later there was no usable product. I got tired of waiting so I took a few weeks and started what we have now. That's what I like about JS: I can pull in libraries from a number of sources to take care of the boring stuff. And they likely do a better job that I can.
When our boss decided we were to have real-time animated data visualization in the browser (I had already done it as an application in C++ and Qt) he hired a FLASH guru to do it. We said that was a great idea because we had exactly six weeks to get at least a demo version up for a big international exhibition and we no idea how to do it! Plus there was that still that old fashioned idea that you need to support IE. I really did not want to touch it.
Turned out I did not have much to do at the time so I started looking into HTML5 websockets, webgl etc. and node.js. As I said I managed to get the thing going in in time for the expo, server side and browser side.
The FLASH guy missed that deadline. He got the graphics looking fantastic but it was still not correct two months later.
Turned out, during many conference calls with him, he had a real hard time understanding mapping between coordinate systems or that translation and rotation operations were not commutative and so on. I was stunned, this was supposed to be a graphics guru and I am positively an amateur at it.
On top of that I had to do the communication part for him.
I would suggest that that project already has a high probability of failure no matter what language it is written in.
Nah, I've built large scale software systems for years, we'll make it work. The only question is how many squirrelly bugs we'll find along the way because we're using a language that isn't up to the task. Heck in the 80's I built stuff out of assembly on a large team.
He got the graphics looking fantastic but it was still not correct two months later.
Turned out, during many conference calls with him, he had a real hard time understanding mapping between coordinate systems or that translation and rotation operations were not commutative and so on. I was stunned, this was supposed to be a graphics guru and I am positively an amateur at it.
Most of the Flash gurus I've worked with usually don't come from a programming or engineering background. They usually are in the design side of the house and care more about fonts, colors, and fades than nuts and bolts stuff. That's fine for form based apps or charts. But if it requires domain knowledge it falls apart quickly.
After the Flash Cairngorm MVC framework came out, we got a write it in Flash requirement (I suspect a FastCompany article again). After much grumbling the team did a week of Flash training. The bottom line was that internally Flash uses ECMA Script, an XML based markup language, and a bunch of input and multimedia controls. Basically it was a Web browser with compilation.
After learning the tools, we realized that we didn't need the bells and whistles, but we got it working with some pain. Now the funny part happens. It turned out that an important customer used a screen scraper (why?!) on the prior product and wanted to do so again. But they couldn't get it working with a Flash UI. The I told you so was sweet.
Comments
Perhaps not by you, but slinging code out the door as fast as possible is the more common argument being made. You can also count on a conspicuous lack of unit tests among people with that philosophy.
I was gob smacked. They are trying really hard to make C++ into JavaScript !
For example:
auto - So that you don't have to write out types so much.
range based for loops - Because C style loops are so clunky.
unique_ptr, share_ptr - Because all that manual memory management is a
pain.
lambdas - Because , well, all the cool kids like JS have them
move semantics - Because, well its that memory management thing again.
initializer lists - That's a good JS idea, we'll have that.
Now, when you put all that together and write code with it, it's like using a totally new language, not like old and ugly C++ at all.
JS was a very good inspiration for the C++ committee
But this thread isn't about Perl. I just wanted to point out a language that totally lacks type safety, yet enjoys considerable success and adherents like me who feel comfortable with messy, laissez faire languages.
That is all. Now please pass the popcorn!
-Phil
Never thought I'd be glad to hear from a Perl monger
[hands Phil the bowl]
I think Perl is pure magic at times. For about a year, I worked with somebody who knew Perl inside and out. Frankly, they could knock out the most difficult and painful data transforms quickly... Say what you want, but that tool box is powerful, IMHO.
Yes. Agreed. But this is true, until it isn't. Sometimes external dependencies require this happen. Enterprise applications run into this mess all the time. And they are broken all the time too. Patch, after patch, after patch. Sysadmins all over the place doing more patching than administration. The vendor I work with has recently doubled up on regression testing as well as started unit testing. Secondly, they test on a battery of existing datasets. Much improved. Still patches, but now they have new stuff in them more than they have fixes.
For smaller things, I prefer loose languages. They are lean, you don't have to know as many things to get it done, and they are great for first pass, "intend to throw it all away" prototypes / tech validation kinds of things.
This discussion is making me want to go try Javascript. Hmmm... Yes Heater, it's on my list. Moving up.
Heater, actually it sounds like they are borrowing from C# which has all of those things, but is still typesafe.
Another argument against JavaScript is that there's two types of people in your typical Web shop. The CSS HTML people who have often have a design background and a passion for how the product looks. They know JavaScript well enough to do event handlers and possibly XHR requests, but generally are not programmers. Then there are many programmers who know how to build databases, scale them, and write the code to pull the whole thing together. These are two very different skills and it's rare to find a person who cares about both.
But to management this looks like duplication of staffing, or at least a lack of ability to rotate staff flexibly. What they want is one person who can do things front to back and think a lack of a common language is the reason the HTML/CSS people can't do server work. It's not and using Node.js won't enable this, but they'll orphan their existing code base.
Somehow it reminds me of Danny DeVito.
Python is easier to use ... once you learn it, like it or not.
Personally I have tried to keep away from "web stuff" as much as possible. I mean all that HTTP, HTML, CSS, XML, DOM madness. Then throw in PHP, SQL. God it's a mess. I don't know how the guys who do that keep their sanity. I had the misfortune to work on such things for nearly a year last century. I decided life was too short for that.
A few years back it came up that we needed to get data out of remote units in the field and create visualizations, in "real time" in the browser, I went into a panic.
Luckily I soon discovered I could do all the graphical stuff in webgl, and pipe the data around with websockets. On the server end I could get the data out of our server processes (c++) as an XML stream and connected to the browsers websocket connections via a simple publish/subscribe mechanism implemented in node.js. Easy.
The thing was up and running in a month.
And hurray! I could leave all the HTML, CSS, PHP gunk to to some other shmucks in the company:)
They said I was crazy. "webgl and websockets don't work on IE", "they are too new", bla bla. "You need FLASH, and long polling" and all kind of other web garbage.
I insisted it goes my way or they find someone else. And by the way no one cares about IE any more. Luckily it all worked out.
Aside: They did even hire a FLASH expert to create the same visualizations because they did not trust I could do it. His version never worked and the budget for his contract ran out many weeks after after I finished the webgl version.
Since then the the JavaScript has moved down to the field units, they arm ARM based and can run node.js well enough. The XML streams have been replaced with JSON over websockets and the C++ server processes have been replaced with...node.js.
This whole show runs with about the same CPU loads and memory consumption as the old C++ stuff, and is ten times easier to work on.
Ah, you say, "it will all collapse when the code base gets too big and the project becomes unmanageable".
We shall see
Point of the story is, I owe my sanity to exactly that phenomena of having the same language in the browser, on the server and now in the field units. It means I can get my job done without having to tangle with PHP at least:)
Ramble, ramble...
I haz failed.
@Heater, the management stuff is the reality I have to deal with. I'm one FastCompany article away from pure chaos and I don’t need more rope.
Well, Brendan Eich's any way.
And now for some confessions...
I'm not about to give up my beloved C/C++. It is the other language you need. (How else would they write JS engines?)
I can't imagine working on JavaScript without jslint to check the thing over before I run it. That is not compile time type checking but it does at least something to keep you away from Javascripts traps and surprises.
If you have 5 minutes here is a video showing how to really argue against Javascript and node,js.
https://www.youtube.com/watch?v=bzkRVzciAZg
Do watch it, it's hysterical, and quite a lot true.
Edit: Oh, whilst we are here, here is the C programmer https://www.youtube.com/watch?v=i2fhNVQPb5I
Edit: And Oh, is this what goes on in your company?https://www.youtube.com/watch?v=x1TsOHyJPpw
Edit: And and the poor JS guy https://www.youtube.com/watch?v=_AYyKAOdnSM
Sadly I cant find the cool Python dude video.
Edit: Found it. The Python Gangsta Rap : https://www.youtube.com/watch?v=FJ7QsEytQq4
Edit: And here is the case for Erlang https://www.youtube.com/watch?v=rRbY3TMUcgQ
Martin_H, I've written several JavaScript programs before, so don't count this one a "I haz failed."
Guess my question for you is: "Is there an alternative language for client scripting in a browser on all platforms?"
-Phil
If you answered either 6 or 33 you're wrong, because it could have been the other one. Typing this weak isn't useful, it is suicidally stupid and creates all sorts of problems that newbies are not really equipped to deal with, and learning to deal with those problems won't teach the n00bs real skills as far as understanding how actual computers work.
"123" + 4 == 127
"123" . 4 eq "1234"
-Phil
However it's best to have jslint in your editor, then it highlights potential dangers on the fly as you edit. Yes, C and C++.
You can compile C and C++ into JavaScript with Emscripten and run your programs in the browser. The fft_bench.c runs about a quarter native speed in firefox.
There are other languages especially designed to compile to JS offering better type safety etc if you like. Can't think what they are called now.
localroger, I thought they did already.
Turns out that it's not actually a big problem in practice. It hardly ever happens and you know it soon enough when it does. It's a far less insidious problem than integer overflows or operator precedence mistakes in C++ for example.
By the way Spin is just is even worse, what is:
str byte "Hello " + " world"
in a DAT section?
I've come to a good synergy. I have Node.js handle all of the web things, and have some Java applications deal with the data processing (the math intensive algorithms). This fits well because it offloads into a different process (and possibly server core) all the stuff that JavaScript doesn't excel at. Plus I'm a better Java programmer.
Even with all the math being done in Java, my experience with JavaScript has been nothing but good. I've been able to make a website that deals in big data, and make the website quickly and with a minimum of problems. In large part that's due to all the JavaScript based libraries out there, and the easy integration. I can pull in a library for everything from templating to time management to data display.
As far as the language itself I quite like it. The stupid "type" mistakes that I make almost always get caught the first time that I try the code. Personally, I'd prefer to have a compiler but the IDE lint tools are a good compromise.
And I really like callbacks. It makes the code easy to control (no more while(done == false){} type things).
JS on the browser and data pipes, Java for the heavy crunching. Sounds like you have his down to a tee.
@Jazzed, at the present time JavaScript is still the only game in town across browsers. But Microsoft's Typescript compiles to JavaScript so you can use it to address some of the problems I pointed out. It's basically a JSLint on steroids. Google has similar but incompatible technology.
Honestly, I can deal with JavaScript for small stuff in the browser, but spending six months with a team of ten people cranking out a large software system for Node.js is not something that I am looking forward to.
I installed Node.js before, but something about it wasn't workable on my computer (I don't recall), so ... zap!
I'll look again. I'll propably need some server-side stuff to make some connections in my project later anyway.
Do you know how to add jslint as a VIM extension?
Typescript? Ok, will look further. Thanks for the pointer Martin.
That's about what happened to me. Except we hired a web guy to do the work, and 6 months later there was no usable product. I got tired of waiting so I took a few weeks and started what we have now. That's what I like about JS: I can pull in libraries from a number of sources to take care of the boring stuff. And they likely do a better job that I can.
And we know there us at least one of the team members actively opposed to the whole idea.
It's doomed before it starts
@Jazzed,
Node.js has been developing quickly they are now pretty stable and running up to version 1.0. Do try and install it again. I think the best way to go is "sytastic" :
https://github.com/scrooloose/syntastic
@SRLM
When our boss decided we were to have real-time animated data visualization in the browser (I had already done it as an application in C++ and Qt) he hired a FLASH guru to do it. We said that was a great idea because we had exactly six weeks to get at least a demo version up for a big international exhibition and we no idea how to do it! Plus there was that still that old fashioned idea that you need to support IE. I really did not want to touch it.
Turned out I did not have much to do at the time so I started looking into HTML5 websockets, webgl etc. and node.js. As I said I managed to get the thing going in in time for the expo, server side and browser side.
The FLASH guy missed that deadline. He got the graphics looking fantastic but it was still not correct two months later.
Turned out, during many conference calls with him, he had a real hard time understanding mapping between coordinate systems or that translation and rotation operations were not commutative and so on. I was stunned, this was supposed to be a graphics guru and I am positively an amateur at it.
On top of that I had to do the communication part for him.
Those videos are great, the mere fact that they exist shows the lengths people will go to in the language wars
Nah, I've built large scale software systems for years, we'll make it work. The only question is how many squirrelly bugs we'll find along the way because we're using a language that isn't up to the task. Heck in the 80's I built stuff out of assembly on a large team.
Most of the Flash gurus I've worked with usually don't come from a programming or engineering background. They usually are in the design side of the house and care more about fonts, colors, and fades than nuts and bolts stuff. That's fine for form based apps or charts. But if it requires domain knowledge it falls apart quickly.
After the Flash Cairngorm MVC framework came out, we got a write it in Flash requirement (I suspect a FastCompany article again). After much grumbling the team did a week of Flash training. The bottom line was that internally Flash uses ECMA Script, an XML based markup language, and a bunch of input and multimedia controls. Basically it was a Web browser with compilation.
After learning the tools, we realized that we didn't need the bells and whistles, but we got it working with some pain. Now the funny part happens. It turned out that an important customer used a screen scraper (why?!) on the prior product and wanted to do so again. But they couldn't get it working with a Flash UI. The I told you so was sweet.