|
Leng Vang wrote: It is really like a double edge sword
Exactly, and most programmers end up on the sharp side and cut themselves. Not many people go as far as to learn about prototype, function order, hoisting, and function variables, method invocation using call and apply, learning what "this" really refers to, using objects as hash tables, testing for equality properly (===, not ==), truthy/falsey or even have the discipline to use loose types in a way that makes sense.
And working with a loosely typed language that's not documented is nothing short of impossible (and way too much of that code is undocumented). It's just a matter of invoking "something" on "something else" and then getting "a third something" 
There are a lot of sloppy and bad programmers out there and they can do harm in any language, but JavaScript just makes it way to easy. Hell, even good programmers have to thread lightly when using JavaScript!
I'll always take C# (or any strong typed language), and after that any other loosely typed language, over JavaScript.
|
|
|
|
|
I like it, and I find that ES2015 has eliminated many of the gripes I've had with it in the past. Having an actual module system is much nicer than just relying on libraries you need being available in the global namespace. Using const and let where I would have used var in the past gets rid of scoping and hoisting issues for the most part.
Using ES2015 makes it necessary to run your code through a build process to generate ES5 that will be compatible with all browsers. I find this to be a benefit, though. A decent amount of static analysis is possible even in a dynamically typed language like JavaScript, so tools like ESLink or Google's Closure compiler are able to find a decent numbers of errors and in the case of Closure, do lots of optimization and dead code elimination as well.
Source maps are generated as part of the process, so the original ES2015 code shows up in browser dev tools instead of the mangled and optimized ES5 generated by the compiler, and normal debugging tools like watches and breakpoints generally just work. I had some issues with source maps and browser debugging tools not working well in the past, but it's been about a year since I've encountered any problems there.
I know some people hate the idea of adding a compilation step to the JavaScript, but I figure if I'm not going to get angry at C# for having a build process, I shouldn't get too upset about using one for JS. The build isn't going to catch type errors in a dynamically typed language, of course, but it can catch plenty of errors you might otherwise miss.
As you've alluded to in some of your replies to other people, a lot of confusion happens because JavaScript looks a lot like C++ or Java, but the semantics are quite different. I approached JavaScript after toying around with Smalltalk, Scheme, and Common Lisp, so a lot of what I saw (first class functions, why this works the way it does, etc.) made sense. Although now even C++ will let you dome something like auto add = [](int a, int b) { return a + b }. You can use JavaScript's looseness to your advantage sometimes; if you understand the difference between == and ===, there are times when == provides exactly what you want.
Or if you're working a library that is a bit wonky (a phenomenon that certainly isn't unique to JS - I've encountered lots of the in the .NET and Java ecosystems too), you might want to perform a certain operation only if a value you get back is not null, or undefined, or zero. In that case, it's nice to be able to write
if (foo) { doSomething() } rather than
if (foo != null && typeof(foo) != 'undefined' && foo != "") { doSomething() }
I guess what it comes down to is that the language has quite a few pitfalls and some historical baggage. It's possible to avoid all of these and focus on the modern bits, and when I do that I find JS development quite pleasant. It's a non-trivial amount of work to learn all of that, though. Many developers use JS as a secondary language to occasionally add some interactivity to a web page, and for most of them there's not a huge ROI in becoming a JS expert.
Then there are those who just hate JS because it is dynamically typed. I often see people getting very worked up, writing passionately about why dynamic typing is the work of the devil. They often mix up static vs dynamic typing and strong vs weak typing, ignoring the reality that some languages are strongly typed and dynamically typed (like Python). I try to stay out of those flamewars because they often just boil down to the old liberal and conversative software engineering dichotomy where the respective see the other as degenerate hippies or something like this.
I've been on both sides of that debate at various points in time, so I'm sympathetic to both points of view. Now that TypeScript makes it easy to gradually add static typing to existing JS code, maybe the two sides can find a way to peacefully co-exist and prosper.  These days when I'm working on personal projects I tend to wander off in Clojure land, building apps from the ground up and then adding typing when it makes sense.
So at the end of the day, I completely understand why many people dislike JS. However, the question was about why I might vote for JS, not why anyone else should. Hopefully what I've written helps explain that. I like both C# and JS quite a bit, and couldn't decide which one to vote for. So I voted for Objective-C because it was looking pretty lonely in the poll results. 
|
|
|
|
|
You make some good points 
I'm still sticking to C# though 
By the way, what I liked about JS (MongoDB, Node, and front-end particularly) is that it's not trouble at all to work with the same objects throughout your stack (and then on the fly add some new ones). Only one language can do that 
|
|
|
|
|
C# is a good choice!
Have you ever tried Bridge.NET? It does a pretty good job of compiling C# to JS, so you can easily use C# for both back-end *and* front-end development.
|
|
|
|
|
That looks interesting, thanks!
|
|
|
|
|
Ya I rejected Javascript for many years. Until I was forced into it kicking and screaming. I found it is much easier to use, supports functional programming styles and is 100% compositional. It lacks LINQ which I really miss but other than that it's a good rugged general use language for novices as well as experts. With NODE getting stronger, who knows maybe someday it will rule the world more than it does today. Today I like Javascript and Typescript (imagine that?)
|
|
|
|
|
|
Over the years I've been migrating more towards functional styles anyway. LodAsh is very cool indeed. It was my work in Node that showed more functional style, in particular the callbacks. Whenever I return to C# which is often my code looks more like Javascript as I create functional extension methods instead of huge classes. I also honestly believe that over the years the payoff will be huge due to the fact that the functional support in my toolbox will cover 90% of what I need. I was never good at being a manager of thousands of classes all over the place in different projects. But now I have one dedicated project with only extensions. I take it with me to all new projects and it's supported 100% by intellisense. Yet C# will never have the open source libraries that javascript has and that's why I feel compelled to move towards Javascript! There's some excellent work out there like D3 to name just one!
|
|
|
|
|
There's definitely some good work going on the the JavaScript world. At a previous job I had, we used D3 to build visualizations that helped our customers catch a pretty significant amount of fraud.
I agree that a more functional style is very appropriate for a lot of the work a typical developer does today, especially when it comes to web development. At the end of the day, a large chunk of web and business app development just involves grabbing some data, piping it through a series of transformations, and then outputting the result.
When working in the .NET ecosystem, I've found F# very enjoyable for work like this. This little app ended up being quite a bit shorter than its C# equivalent. I especially like how easy it is to use the |> operator to pipe to output of one function into another. It makes it really easy to use the 'data pipeline' approach.
|
|
|
|
|
It's powerful, fast and does not need contorsions to get low level. Low level is usually not needed, except when you write real time systems, drivers, kernel pieces or painfully heavy but necessary algorithms (Image Processing, I'm accusing YOU!).
Since I develop for each of them (except kernel pieces, for now) I prefer C++. Maybe for business oriented or consumer application (NOT GAMES) I'd really think about C#, even if C++/CLI still appeals to me more than C#, even if those new symbols make me cringe looking at the code - I think it's a matter of habit.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
|
Webmaster forgot about these 2 GPGPU languages!
Cg, HLSL and GLSL shader language are also C based.
|
|
|
|
|
Turbo C, VAX C, DEC C, HP C, etc. -- but went with C#; it's just easier.
|
|
|
|
|
But i miss the native pointer mess from C++ a lot. 
And I hate the resource xaml sh*t. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
you can get your pointers just work 'unsafe'
|
|
|
|
|
I never use XAML; I write mostly backend, WinForms, and command-line utilities.
|
|
|
|
|
You can use pointers in C# just fine. I do it all the time.
|
|
|
|
|
It is all about our tastes...
|
|
|
|
|
...so paste a comment on your favourite one that's missing. There's only so much space on the homepage.
cheers
Chris Maunder
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
