http://www.simple-talk.com/opinion/opinion-pieces/a-sudden-move-one-developer%E2%80%99s-journey-from-c-to-javascript/

I'm not sure why you're referring to it as antiFUD, who is the FUD coming from?

38 minutes ago, brian.​shapiro wrote

I'm not sure why you're referring to it as antiFUD, who is the FUD coming from?

The whole world!

Using it on the server side is the ideal situation for web apps, IMO, since you can share a lot of code between the layers. It's also quite fast for a dynamic language, because of all the focus JS performance has gotten over the years and servers benefit from that too. With MongoDB you can have JS in the data layer as well. It's great stuff really, I'd like to see more JS on the server over time.

2 hours ago, brian.​shapiro wrote

I'm not sure why you're referring to it as antiFUD, who is the FUD coming from?

Good question! As JoshRoss says, it might really come from all over, but I cannot help but feel it's mostly Microsoft developers who lead the "HTML5 will be ready in 2022" charge. After dreaming of a C# future, they pray for Bill G to come back and show the world what E^3 (you know, embrace etc.) should look like

I also utterly don't understand why anyone would want to program in dynamic languages and lose the static type system. I mistype stuff all the time, and I really like the fact that my compiler will tell me I made a dumb mistake rather than finding out later during testing, or worse, via customer support.

3 minutes ago, exoteric wrote

This choice is more about a platform choice than a language choice. At the "lowest" level Javascript is still unavoidable (until multiple run-times are incorporated into browsers) but the programmer does not need to concern himself with it, if it does not want to.

On what planet is Javascript anywhere near to the "lowest level"?

1 hour ago, evildictait​or wrote

*snip*

On what planet is Javascript anywhere near to the "lowest level"?

One where people who hide javascript behind libraries think they're doing javascript, rather than jquery

5 hours ago, evildictait​or wrote

On what planet is Javascript anywhere near to the "lowest level"?

Earth.  People are building x86 emulators and Linux kernels written in JavaScript.  As Scott Hanselman has repeatedly pointed out in the last year or so, JavaScript is the assembly language of the web. 

If you haven't watched his presentation from build, you owe it yourself to do so.  Probably the best level-setting presentation about how things actually are in the 2010s I've seen. 

http://channel9.msdn.com/Events/Build/2012/3-027

14 hours ago, evildictait​or wrote

I also utterly don't understand why anyone would want to program in dynamic languages and lose the static type system. I mistype stuff all the time, and I really like the fact that my compiler will tell me I made a dumb mistake rather than finding out later during testing, or worse, via customer support.

I think what may have happened is that developers and tools got much better: developers got much better at designing and testing robust dynamic code (through working with server-side languages like Groovy and Ruby) and IDEs (I'm talking about Eclipse, NetBeans and IntelliJ) got much better at working with and debugging dynamic code. Overall this means that typos are less than they used to be and are much less likely to make it into customer hands.

The other reason is something that Warren touched on:

3 hours ago, warren wrote

*snip*

People are building x86 emulators and Linux kernels written in JavaScript.  As Scott Hanselman has repeatedly pointed out in the last year or so, JavaScript is the assembly language of the web.  

Javascript has evolved into some sort of JVM, which means languages are being developed that compile into Javascript for running on clients and servers. As well as the 'thin veneer' add-ons like Coffeescript, you've also got your full-on languages like Fantom and Kotlin, both of which are statically typed.

I think what may have happened is that developers and tools got much better: developers got much better at designing and testing robust dynamic code (through working with server-side languages like Groovy and Ruby) and IDEs (I'm talking about Eclipse, NetBeans and IntelliJ) got much better at working with and debugging dynamic code. Overall this means that typos are less than they used to be and are much less likely to make it into customer hands.

As someone who visits companies to tell them how to fix their software before releasing it, I can tell you categorically that this is not true.

Companies that produce code in dynamic languages like PHP, Ruby, Python compared with languages like C#, Java or even C++ tend to have lower quality formalized testing and lower quality overall software.

Even worse is the fact that languages where the distinction between code and data becomes blurry (such as whoever thought you should upload files and put source code to be executed both on the filesystem should be shot - as should the person who thought SQL ever being a string that you can glue together at runtime, or the guy who thought HTML should be uncompressed, unencrypted, human readable and have badly defined parsing rules) are vastly more likely to have critical security bugs.

I hate to say it, but when I review sites by equally crappy developers written in C#/.NET versus PHP, the ones written in dynamic languages tend to fall faster and harder with less effort on my part.

1 hour ago, evildictait​or wrote

*snip*

As someone who visits companies to tell them how to fix their software before releasing it, I can tell you categorically that this is not true.

Companies that produce code in dynamic languages like PHP, Ruby, Python compared with languages like C#, Java or even C++ tend to have lower quality formalized testing and lower quality overall software.

Then we clearly don't work for the same companies. The outfits I'm familiar use Groovy and Ruby based frameworks for front/back end testing and are dab hands with all kinds of mocking frameworks. They also use continuous integration and are pretty formal in much of the stuff they do. Bad practice is bad practice and has nothing to do whether the language is dynamic or not.

For me, it's a question of discipline.

Even worse is the fact that languages where the distinction between code and data becomes blurry (such as whoever thought you should upload files and put source code to be executed both on the filesystem should be shot - as should the person who thought SQL ever being a string that you can glue together at runtime, or the guy who thought HTML should be uncompressed, unencrypted, human readable and have badly defined parsing rules) are vastly more likely to have critical security bugs.

Not sure what any of that has to do with the price of bottled air to be honest.

Again, bad practice and nothing to do with the language itself. There's nothing to stop anyone doing the same sort of nonsense in statically typed languages. No one I know builds SQL strings on the fly; we've had ORM frameworks to do that kind of lifting for quite some time.

I hate to say it, but when I review sites by equally crappy developers written in C#/.NET versus PHP, the ones written in dynamic languages tend to fall faster and harder with less effort on my part.

Well that's where our experiences differ. Most website crashes I see are .NET related, usually database errors that haven't been caught. 

19 hours ago, warren wrote

Earth.  People are building x86 emulators and Linux kernels written in JavaScript.  As Scott Hanselman has repeatedly pointed out in the last year or so, JavaScript is the assembly language of the web. 

I've written x86 emulators in Haskell, but that doesn't make that a low level language by any stretch of the imagination.

I don't particularly want to get into a game of ideologues. I understand that it is possible to write insecure code in both. What I'm saying is that in my experience of working a security professional, companies that write dynamic code write code that is worse.

I don't even really care why they write worse code. The simple fact is just that they do.

Seriously - find me a pentester who will argue that websites written in PHP are generally more secure than those written in C#/.NET and I'll eat my hat. Or find me an industry leader who thinks that their next big product will be written in Python instead of Java.

If your company does use PHP and other dynamic languages and is very proud of their record of "no bugs - everything is safe", I would strongly encourage you to get an independent security test done. You have seriously no idea how many PHP programmers with "secure" and "thoroughly tested" websites I upset in any given week by showing them their client's data sitting in my database rather than theirs.

Let me put it this way. If SQL were precompiled, nobody would even think to glue attacker controlled strings and pass them to SQL and so SQLi wouldn't exist (when was the last time you wanted to glue LINQ expressions with a "+"?). If HTML wasn't a string, XSSes would be hard to introduce, not easy (when was the last time an XSS-type bug was found in a Silverlight pre-compiled app or a WinForms program?).

If eval() wasn't there, code injections in PHP would take really really dumb code to produce (like how it's deliberately hard to write an eval in C# - and it's pretty obvious your Doing It Wrong when you do), not just a half-assed attempt at a filter and a prayer next to that code injection bug. And if people didn't put their code on the filesystem next to their upload directory, they probably would have fewer code execution bugs on their website.

So anyway, I think the answer is just that it "just being a matter of discipline" is just wishful thinking. Developers don't have discipline, they have deadlines. And languages that make it easy to write critical bugs (say, by allowing you to glue strings together and call them SQL statements, or by including an eval function in your language) makes it easy to turned stressed out developers into critical bugs.

That's probably why languages where writing bad code takes longer than writing good code tend to do better in security reviews.

Quality is such a difficult term. Most of us will proclaim we are disciplined programmer and produce high quality code. And oohhhhh.... it passed all the unit tests for 1000 times. But, we are all human. Human write code and human write unit tests and human makes mistakes. So, IMO, the more hand holding from IDE and Compiler, the better, as long as it doesn't cost too much expressiveness to the language.

IMO, ASP .NET scared a lot of new comers because WebForm and MVC have high learning curve. But, have you guys tried Razor or free WebMatrix yet? Personally I think it is very good web platform mixing C#. Sure you still need JS on client, but, that's only because there is no other alternatives. The only downside is, you need to pay for web hosting 5 bucks a month instead of completely free. And usually school would teach class using free web hosting because 5 bucks per month is infinitely more expensive.

1 hour ago, Bass wrote

I don't think PHP is well designed. But people make great stuff in it. Any time someone brings up .NET vs PHP, it reminds me of MySpace vs Facebook. It proves that languages are ultimately kind of unimportant compared to having talented people and sane design.

The problem is that people often bring up that you can write insecure and secure code in both X and Y for all turing complete languages X and Y, which ultimately misses the point that X and Y are not then equally good languages.

For example, it's possible for an experts to write a lovely swisshy app entirely out of x86 assembly compiled with NASM. But it's a whole ton easier to just use WPF.

And shouting "yeah, but you can do a buffer overflow in C# too if you're really dumb, and you can write code with no buffer overflows or memory leaks in C as well" kind of misses the point. It's waay harder to write good C code with no buffer overflows or memory leaks than it is to write good C# code with no buffer overflows or memory leaks.

Just because it's possible to write crappy code in .NET and crappy code in PHP doesn't make them equal. Case in point:

<? include($_POST['folder'] . "/include.php") ?> 

<% Server.Execute(Request.Form["folder"] + "/include.aspx") %>

One of those is a root shell on your server. The other (probably) isn't.

<? 

$hash = $_POST["hashalg"];

$hash($_POST["password"]);

?>

<%

string hash = Request.Forms["hashalg"];

System.Security.Cryptography.HashAlgorithm.Create(hash).ComputeHash(hash);

%>

One of those is a root shell on your server. The other isn't.

<?

$sql = "SELECT * from foo WHERE name = " . str_replace("'", "''", $_GET["foo"]) . "'";

mysql_query($sql); // MySql

?>

<%

string sql = "SELECT * from foo WHERE name = '" + Request.Forms["foo"].Replace("'", "''") + "'";

MsSqlQuery(sql); // MS SQL

%>

One of those is a root shell on your server. The other isn't.

<? if($_POST["secret-password"] = "Aw3s0mE") { logged_in = true; } ?>

<% if(Request.Forms["secret-password"] = "Aw3s0mE") { logged_in = true; } %>

One of those is a authentication bypass. The other is a compile-time error.

The list goes on, but the point is that crappy code in PHP/MySql/Python/RoR is vastly more likely to turn critical than like-for-like stupid code in .NET/C#.

The point is that in a random sample of the thousands of companies that I've visited to audit their code everyone writes crappy code. Some experts write crappy code once a month. Some junior coders write crappy code every day of the week. But the point is that having a language that is there to encourage you to do it right and make it hard for you to do it wrong (without making it impossible to do it at all) means that people gravitate to doing it right when the deadlines are near, instead of writing shoddy code to get the product (and all too often, their user's credit card details) out of the door and onto the Internet.

I write bugs all of the time. But I kind of like the fact that 95% of them are caught by my compiler, 4.99% of them are found my unit tests, and of the 0.01% that are left to run on customer machines, Microsoft makes sure that only 0.000001% of those are actually exploitable.

That's better for my customers than finding 99% of the bugs with unit testing, and half of that 1% of bugs that get through being trivially exploitable by a hacker determined to get root on my server.

Sorry for the off-topic.

16 hours ago, evildictait​or wrote

One of those is a root shell on your server.

trivially exploitable by a hacker determined to get root on my server.

I don't think so. Even if you have the ability to execute arbitrary PHP on a server, your scripts can only execute with the rights of PHP interpreter. And depending on the server PHP is running on (eg: RHEL), that might not be many rights at all.