It helps to never ever pretty-up the UI for POCs. As the UI dev, I've never understood why people do this. The point is to prove what is within grasp for possible implementation. Finished-looking UI makes them think it's mostly-done.
You know what the weird thing is? I came up in JavaScript but what really pisses me off in all the C# and Java I've been working with lately is the spectacular amounts of code that gets heaped on the problem of not having dynamic types. Completely pointless interfaces, generics, and lists of objects are absolutely everywhere in our code base. I actually find it easier to just rely on my use of OOP to keep the branching of data flow to a minimum and bring methods to my data structures rather than pass the data around constantly, putting 20 different sets of hands on them often re-validating and repackaging redundantly for every process, because you really might as well just call it a global var at that point. Handling thing's better with OOP actually makes it easier for me to use simpler data structures and not have to constantly cast things from one type to another or slap generics on absolutely everything (which is a phenomenon anybody writing in a statically typed language should take as a smelly symptom of lousy OOD).
So yeah, that's me, your JavaScript guy in the C#/Java dev authored codebase actually using single-typed arrays or lists of primitives in a sea of excess IOC and generics when there's no reason not to, because why complicate things needlessly? Is it better to make it generic "just in case" or is it better to know what type this thing is going to be right here and now where you're looking at the code? It's an even easier question to answer when you have one point of entry where it gets packaged and validated one time and then changes are all made internally as the object interacts with other objects and responds to events. You can do that sort of thing when you understand that vanilla getters/setters don't actually do anything for you and you might as well expose the property as public. Try encapsulating for realz. It's more challenging than beans/DTOs handed around like the cheap OOP-murdering data whores that they are because it makes you think critically and that's something modern software devs need to do a lot more of. Don't "maintain" contracts, check them at the door of a given problem domain. It's okay if the internals of a class get longer than 2-3 lines, I promise.
The dynamic kids who know what they are doing can work in your favorite statically typed language and produce results in less code than mediocre authors using that language can because we know how to write code. If we didn't, we'd be making the very messes static-only devs are afraid of making because it's never occurred to them that what static types protect them from is a mediocre dev's lack of ability to manage data flow, keep dependencies to a minimum, and actually leverage plain vanilla OOD - rather than just wrap procedural function-only code in classes - to write cleaner, easier to read, easier to maintain code. Catching a goof at compile time is nice. Catching 20 breaks at compile time when you made a simple change is a problem you shouldn't be having. When competent devs are in the room, static vs. dynamic types are a code quantity to performance tradeoff and that is all. To any static-only purists out there, I would recommend both writing and studying something something non-trivial written in a dynamic language and I guarantee that whether you are competent or misinformed, you will learn something that will benefit you in whatever languages are your bread and butter now just as I've learned stuff from branching out into C# and Java that I could take back to JavaScript to actually leverage what it's good at even better.
There are things I would not write in JavaScript exclusively (fortunately Node makes it really easy to leverage C or C++ for more calculation intensive stuff) but I think the widespread success of Django, particularly in the no-longer-just-print journalism sector has already dispelled the myth that dynamic languages can't handle complexity or scale. And the fact that JS maintained its position as the best tool for the job of normalizing umpteen variations on the DOM API in, particularly I
To my mind there's no point in benchmarks when I've seen competence in Rails (barely), in C#, in Python, and in JavaScript (which is my primary expertise), but never, not once have I seen a Java web app that seemed to have been written by people who had the foggiest notion of the craft of writing code and performance/maintenance were always awful. I just spent the last two days pulling apart mashed together Tomcat, spring, struts, etc... config to try to get our app working in something newer than Java 5 and on the latest version of spring rather than like 20 different ones. If you only know Java, don't defend Java. The truth is, the language isn't horrible, just a somewhat antiquated answer to the problem of getting 100 C devs to work together without a riot, but the things the community have done with/to it in complete ignorance of why they were doing it, are absolutely mind-blowing. I'm sure you CAN write a decent web app with Java, but an inherently protectionist language that actually touts verbosity as a feature aiding clarity (if you believe that, I have some lovely Ian Fleming novels translated into legalese you should enjoy) is always going to attract complete and total suckwads. As a rule I would never advocate hiring somebody who only knew Java but I wouldn't have a problem hiring another dev if s/he knew other languages and actually preferred Java because I would like to meet that person and see how they made Java work for them in a whole !@#$ing universe of complete ass-code writing cretins. And FFS, why am I looking at 6 !@#$ing xml files, 5 interfaces, and a dozen classes just to figure out who's pulling the trigger? WTF is wrong with you people? If you have no idea why you're doing what you're doing, just stop.
Speed, definitely. I remember moving large quantities of files around and being really surprised at how much faster things were. If all I needed was basic productivity and web I would use Linux exclusively and I would have spent a lot less on my last custom-PC. If you have an old junker somewhere, try wiping Windows out and putting Ubuntu on it to really get an idea.
The real core problem is lack of heavy-hitting commercial support on the hardware front. The graphics card companies in particular don't have a lot of motivation to support Linux since game companies all prefer Direct X. I'm no game dev, but I've heard openGL isn't exactly a hoot to deal with compared to DirectX. As a web dev, however, I'm generally much happier working in Linux. Setting up and installing/configuring the tools I like to use tends to take minutes rather than (sometimes) hours.
It's also a better environment for power-users. Pick up a book on Linux an you'll quickly see that there's really very few layers of abstraction between you and any given piece of hardware on your machine.
But that does bring up something I tend to find annoying about Linux, which is the old-school IT attitudes of a lot of its community in general. Everybody wants to tell you the one true way to do everything but they never seem to feel obligated to explain why. I get it. It's annoying when non-tech people don't even try Google first, but when a programmer is trying to understand what the deal is and can't get a straight answer, that's kind of obnoxious. So you have to be good at self-educating if you want to do anything more than just use Ubuntu the same way most people use Windows. Sadly, I've gotten more useful info from books on Linux than the web.
That said, it is liberating to explore your hardware through something other than Windows. Dual-boot is really very easy to do now (I still prefer partitioning for getting the "proper" file system but to most that won't matter and for all I know is irrelevant).
At the end of the day, the only way to know is to try it yourself and that's really not that hard to do now.
To be fair, we'd probably be a lot more aware of Linux security holes if it had a high enough % adoption for people to want to mess with it. I'll bet it's still easier to shore up security issues for Linux but you're just not going to see the viruses on a given OS if hardly anyone is writing them.
But that's the !@#$ing point. Why would you even look at another language if it's like all other languages? And yes, I'm a little touchy about it because as I've started becoming more of a generalist I'm starting to understand why people gripe about JS and it's never for good reasons. When I have to write some Java or C#, I don't come to those paradigms with the notion that the first thing to do is to concoct something foolish that will make those languages a lot more like JS, yet I consistently have to deal with that attitude when walking into client-side code-bases slopped together by devs who couldn't be bothered to learn anything new beyond what little they learned about the language they used the most in college.
I personally find classes overwrought and inelegant but I get why they're like that given a pre-compiled, statically-typed approach to things. Static types are a language design trade-off. They help languages perform better. Period. They do not protect you from the kinds of issues you're going to run into in any language when you're not conscious of the flow of data through your app, although given some of the complete crap I've seen on the server-side, I'm not surprised so many people seem to think they need all the protection they can get.
Dynamic types are handy because they help you do a whole hell of a lot more with a lot less code. I don't have to rewrite functions to overload my arguments, for instance. There's a reason typical web dev teams consist of a bunch of server-side guys and one or two UI devs and it's not because funneling data around and handling sessions is hugely complicated compared to what we have to do with JS, two markup languages, management cultures which have been spoiled rotten by how fast we can tweak and change UI and layout nowadays and 6-20 different platforms that don't always agree on what your code actually means. Confusing type errors? Never been a problem for me. Maybe I'm just a really awesome developer. Or maybe that's just a myth originating from extremely shitty code. Or maybe it's a hell of a lot easier to be cognizant of flow of data through your app when there's a lot less app necessary to get something done in the first place. XML config for actually branching anything other than external dependencies? How the hell did that happen? Which brings us to performance. I've never seen a poorly-performing Python back-end. PHP is up and down. Rails and.NET post-webforms too. Java server-sides are notorious, however. We all know who has the better benchmarks, but why in my 6 year career has every single Java server-side I've run into sucked complete ass? Because web apps are stupid-complicated? Just think about it.
Oh and JS had inspiration from other languages but the quoted inspiration for it is Scheme, a Lisp variant. JS didn't pull first-class functions and prototypal inheritance (thumbs up by the way, does everything I need it to) out of its ass. So yes, it's different. Different for a lot of good reasons. Different for not inspiring the kind of code that leads to people using 6 XML config files just to build one page of HTML. Do yourself a favor and try some of the weirder languages. Those rubber tires might look funny to you compared to good old reliable rock but sometimes it really is a great idea to re-invent the wheel.
Also blacks, gays, people with disabilities,etc... Let's not forget how completely batshit we still are about the notion of socialism or even a mixed economy even though we already basically have one.
The key word is ECMAScript. It has versions. It is in fact evolving quite rapidly. Also, classes seem kinda silly once you actually properly understand the power-blend of functional and uniquely function-oriented JS OOP and the fact that it basically makes everything class-based languages do possible and more. I'd recommend learning JavaScript properly. You might actually discover that you never understood OOP if you're one of those who doesn't understand how getters/setters all over the place basically murder the whole concept of OOP.
CoffeeScript basically cuts JavaScript's balls off in terms of the level of dynamic/granular control it gives you in terms of how you might want to implement OOD. And yes, people who have been writing code that normalizes for multiple interpretations of the actual code they're writing in, tend to be a bit fussy about adding another !@#$ing layer/dependency to the development process. Especially one that makes it more difficult to debug straight out of the environment the code is actually running in which is kind of a massive win. I find Python-style syntax refreshing. I don't like hamstrung JavaScript.
So it's just an accident that it beat out all other contenders on the client-side web and is rapidly spreading to mobile, the server-side and pretty much any place we feel like implementing it. Have you seen a typical web dev team? Would you say the UI devs typically outnumber the server-side or that in 99% cases there's really just "a" JavaScript dev responsible for the HTML, CSS, and JavaScript handling all of the UI and layout concerns for the app while like 2-4 guys handle model and controller?
So yeah, I don't know. We must just be plucky I guess. But it couldn't possibly have anything to do with the fact that you wouldn't know a first-class function if it asynchronously bit you on the ass just because JS doesn't work exacly like the one c-based syntax language you know, could it?
And that language... It wouldn't happen to be Java would it? I mean why Dart? Why not Java for the front end?
Oh that's right, they already tried that. FFS, just TRY it without static types and classes for a few seconds. You might learn something. I know I learned more about JS when I actually bothered to learn other languages. And if you really only know one single c-based language, try something that's not first so you can get over that and think in terms of design rather than what you've learned by rote.
People stopped writing everything in C for a reason. And no, as a primarily JavaScript developer I can assure you that it's not because the language is too hard for us mere mortals to understand. If you want full granular control to maximize performance for some 3D engine or version control, etc, you go with something like C that's basically a thin veil over assembly and pre-compiles. If you want it up and running tomorrow rather than 6 years from now and working in every relevant mobile device without actually testing in every single relevant mobile device simultaneously, you write it in JavaScript. Like most who know languages other than Java, however, I'll happily meet you in the middle and declare that Java sucks ass.
The only good reason to put up with static typing is performance. Requiring it to write maintainable code is a crutch for people who architect poorly. There's nothing relevant or important you can't do with prototypal inheritance that you can do with classes. In fact it offers considerably more granular control over how to build object factories and composite objects. You may not have noticed but JS has spread to the OS. It's on the server-side and a plethora of devices like game consoles, and native smartphone and tablet apps. It's being used to write apps for all relevant mobile devices simultaneously. I'd say it's moving forward plenty fast. A lot faster than the careers of a number of slash-dotters in this thread speaking with authority on JS that they clearly don't have I'd wager.
JavaScript is not a mess and people have been agreeing on ways forward for over 10 years. It's just taken Microsoft 10 years to finally start acting on those agreements in regards to the DOM API and CSS. But the ECMA spec is actually something they've taken seriously.
You mean like the certification processes people used to get high-paying salaries for in the '90s that people now look up on warily as if you're a snake oil salesman for having on your resume? Should there be one for every language? What certifying authority is going to stay on top of the web when the colleges still haven't figured out how to teach JavaScript competently?
I'm not worried about it. Unlike the writing of spoken languages which everybody has decided they can do well since the advent of e-mail, programming fail tends to become obvious a lot sooner and is evaluated less on subjective taste. Well, except maybe to managers susceptible to 'enterprise solution' marketing tactics.
Not everybody can get by in even algebra without struggling. Not everybody can write an English paper you'd actually find relatively painless to read. Not everybody can actually handle the notion that vowels and consonants actually get used differently than they do in their native tongue and will massacre the spoken language to a point incomprehensibility no matter how well they learn the vocabulary. And not everybody has the instincts, mind-set, or interest required to write portable, re-usable, easily modified, non-trivial code in a professional setting. If they did, I'd have a much harder time finding a job in this economy.
Nothing "forces you to adopt a decent coding style" if you never bother to learn one. It's why so many C# and/or Java-uber-alles devs with a smattering of C++ knowledge can't write decently architected JS to save their lives and cry when you take their IDEs away from them.
Like it or not, JavaScript is a success and it had cross-platform competition from Sun and at least one pathetic proprietary contender from Microsoft. At the end of the day, only JS has the kind of on-the-fly flexibility needed for client-side web work because it took a Scheme-inspired, dynamic, mutable-bordering-on-the-obscene, functional language to tame the beast that was Microsoft's outright refusal for ten years to properly comply with a number of specs penned by a working group they were members of and also to handle the rigors of rapidly changing designs and requirements that people have come to expect of web apps.
C# and Java have their place but they wouldn't hold a candle to JS in event-driven approaches to problems, rapid normalization of APIs that vary from browser to browser and platform to platform, or taking polymorphism to a new extreme where designing maintainable objects to adapt to changing contexts, environments and circumstances are concerned. And yes, JS gives you plenty of rope to hang yourself with. That's a design trade-off that can cause trouble for JS rookies from other backgrounds wanting to implement more advanced features with JS, but it's also the source of the language's biggest win, which is having the flexibility to adopt just about any coding paradigm you could want with the nifty side-effect of alienating mediocre devs who deep-down-inside freak at the thought of passing a function like it was data.
Ultimately nothing can force you to write decent code. You can put your clumsy, verbose, procedural spaghetti BS inside a class but that doesn't make it competent OOD. And static typing, which has other design trade-off benefits than the most often and IMO most erroneously touted one, only protects you from a small portion of the issues that result from the real failure which is lack of attention given to how your data flows and ignorance of how your language actually passes and operates on various types.
Crockford wants you to use that because he considers use of the new keyword dangerous because you might forget to use it and just fire the constructor normally. Even if this were a common occurrence (really?), it shouldn't take a competent dev very long to see that something went wrong with the object they were creating or write a factory function if this became a regular source of issues.
Function constructors are a little more verbose but have three major advantages over Object.create. You can effectively create the equivalent of private methods/properties that are defined internally but can be accessed by public methods/properties that are also defined internally (but not attached to the object after it's created), you can include initialization behavior inside the constructor that occurs automatically, and you can name the constructor, effectively giving instances a "type" to examine with.constructor.name (requires a workaround for IE=8) which can be useful regardless of whether you smartly prefer duck-typing to type-checking in most scenarios.
Also, that workaround version of the method is incomplete. It takes two args. A prototype and a property object.
if (typeof Object.create !== 'function') {
Object.create = function objCreate(proto,props){
if(!props){ props = {}; }
var objConstructor = function(){
for(var x in props){ this[x] = props[x]; }//like-named properties here will override prototype properties
};
objConstructor.prototype = proto;
return new objConstructor();
} }
Object.create is not a replacement for function constructors and Crockford is ignoring a number of things I know he's aware of to suggest that it should be. It's just a convenient way to create shallow copies of objects or short-hand for the following when you don't need all the extras and granular control function constructors provide, but still need a prototype other than the general Object instance you get when you define as object literals:
function ConstructorName(proto){
this.propertyA = '';//and other properties from props defined constructor style } ConstructorName.prototype = proto; var someObj = new ConstructorName();
"Prefer Object.create" isn't even an acceptable heuristic. It's like saying "prefer convenience."
The scale of convenience vs. options is {},Object.create,new function(){}
Slashdot Mirror
It helps to never ever pretty-up the UI for POCs. As the UI dev, I've never understood why people do this. The point is to prove what is within grasp for possible implementation. Finished-looking UI makes them think it's mostly-done.
You know what the weird thing is? I came up in JavaScript but what really pisses me off in all the C# and Java I've been working with lately is the spectacular amounts of code that gets heaped on the problem of not having dynamic types. Completely pointless interfaces, generics, and lists of objects are absolutely everywhere in our code base. I actually find it easier to just rely on my use of OOP to keep the branching of data flow to a minimum and bring methods to my data structures rather than pass the data around constantly, putting 20 different sets of hands on them often re-validating and repackaging redundantly for every process, because you really might as well just call it a global var at that point. Handling thing's better with OOP actually makes it easier for me to use simpler data structures and not have to constantly cast things from one type to another or slap generics on absolutely everything (which is a phenomenon anybody writing in a statically typed language should take as a smelly symptom of lousy OOD).
So yeah, that's me, your JavaScript guy in the C#/Java dev authored codebase actually using single-typed arrays or lists of primitives in a sea of excess IOC and generics when there's no reason not to, because why complicate things needlessly? Is it better to make it generic "just in case" or is it better to know what type this thing is going to be right here and now where you're looking at the code? It's an even easier question to answer when you have one point of entry where it gets packaged and validated one time and then changes are all made internally as the object interacts with other objects and responds to events. You can do that sort of thing when you understand that vanilla getters/setters don't actually do anything for you and you might as well expose the property as public. Try encapsulating for realz. It's more challenging than beans/DTOs handed around like the cheap OOP-murdering data whores that they are because it makes you think critically and that's something modern software devs need to do a lot more of. Don't "maintain" contracts, check them at the door of a given problem domain. It's okay if the internals of a class get longer than 2-3 lines, I promise.
The dynamic kids who know what they are doing can work in your favorite statically typed language and produce results in less code than mediocre authors using that language can because we know how to write code. If we didn't, we'd be making the very messes static-only devs are afraid of making because it's never occurred to them that what static types protect them from is a mediocre dev's lack of ability to manage data flow, keep dependencies to a minimum, and actually leverage plain vanilla OOD - rather than just wrap procedural function-only code in classes - to write cleaner, easier to read, easier to maintain code. Catching a goof at compile time is nice. Catching 20 breaks at compile time when you made a simple change is a problem you shouldn't be having. When competent devs are in the room, static vs. dynamic types are a code quantity to performance tradeoff and that is all. To any static-only purists out there, I would recommend both writing and studying something something non-trivial written in a dynamic language and I guarantee that whether you are competent or misinformed, you will learn something that will benefit you in whatever languages are your bread and butter now just as I've learned stuff from branching out into C# and Java that I could take back to JavaScript to actually leverage what it's good at even better.
There are things I would not write in JavaScript exclusively (fortunately Node makes it really easy to leverage C or C++ for more calculation intensive stuff) but I think the widespread success of Django, particularly in the no-longer-just-print journalism sector has already dispelled the myth that dynamic languages can't handle complexity or scale. And the fact that JS maintained its position as the best tool for the job of normalizing umpteen variations on the DOM API in, particularly I
To my mind there's no point in benchmarks when I've seen competence in Rails (barely), in C#, in Python, and in JavaScript (which is my primary expertise), but never, not once have I seen a Java web app that seemed to have been written by people who had the foggiest notion of the craft of writing code and performance/maintenance were always awful. I just spent the last two days pulling apart mashed together Tomcat, spring, struts, etc... config to try to get our app working in something newer than Java 5 and on the latest version of spring rather than like 20 different ones. If you only know Java, don't defend Java. The truth is, the language isn't horrible, just a somewhat antiquated answer to the problem of getting 100 C devs to work together without a riot, but the things the community have done with/to it in complete ignorance of why they were doing it, are absolutely mind-blowing. I'm sure you CAN write a decent web app with Java, but an inherently protectionist language that actually touts verbosity as a feature aiding clarity (if you believe that, I have some lovely Ian Fleming novels translated into legalese you should enjoy) is always going to attract complete and total suckwads. As a rule I would never advocate hiring somebody who only knew Java but I wouldn't have a problem hiring another dev if s/he knew other languages and actually preferred Java because I would like to meet that person and see how they made Java work for them in a whole !@#$ing universe of complete ass-code writing cretins. And FFS, why am I looking at 6 !@#$ing xml files, 5 interfaces, and a dozen classes just to figure out who's pulling the trigger? WTF is wrong with you people? If you have no idea why you're doing what you're doing, just stop.
Speed, definitely. I remember moving large quantities of files around and being really surprised at how much faster things were. If all I needed was basic productivity and web I would use Linux exclusively and I would have spent a lot less on my last custom-PC. If you have an old junker somewhere, try wiping Windows out and putting Ubuntu on it to really get an idea.
The real core problem is lack of heavy-hitting commercial support on the hardware front. The graphics card companies in particular don't have a lot of motivation to support Linux since game companies all prefer Direct X. I'm no game dev, but I've heard openGL isn't exactly a hoot to deal with compared to DirectX. As a web dev, however, I'm generally much happier working in Linux. Setting up and installing/configuring the tools I like to use tends to take minutes rather than (sometimes) hours.
It's also a better environment for power-users. Pick up a book on Linux an you'll quickly see that there's really very few layers of abstraction between you and any given piece of hardware on your machine.
But that does bring up something I tend to find annoying about Linux, which is the old-school IT attitudes of a lot of its community in general. Everybody wants to tell you the one true way to do everything but they never seem to feel obligated to explain why. I get it. It's annoying when non-tech people don't even try Google first, but when a programmer is trying to understand what the deal is and can't get a straight answer, that's kind of obnoxious. So you have to be good at self-educating if you want to do anything more than just use Ubuntu the same way most people use Windows. Sadly, I've gotten more useful info from books on Linux than the web.
That said, it is liberating to explore your hardware through something other than Windows. Dual-boot is really very easy to do now (I still prefer partitioning for getting the "proper" file system but to most that won't matter and for all I know is irrelevant).
At the end of the day, the only way to know is to try it yourself and that's really not that hard to do now.
To be fair, we'd probably be a lot more aware of Linux security holes if it had a high enough % adoption for people to want to mess with it. I'll bet it's still easier to shore up security issues for Linux but you're just not going to see the viruses on a given OS if hardly anyone is writing them.
The problem with Jython is the part where you have to admit you already made one big mistake.
But that's the !@#$ing point. Why would you even look at another language if it's like all other languages? And yes, I'm a little touchy about it because as I've started becoming more of a generalist I'm starting to understand why people gripe about JS and it's never for good reasons. When I have to write some Java or C#, I don't come to those paradigms with the notion that the first thing to do is to concoct something foolish that will make those languages a lot more like JS, yet I consistently have to deal with that attitude when walking into client-side code-bases slopped together by devs who couldn't be bothered to learn anything new beyond what little they learned about the language they used the most in college.
I personally find classes overwrought and inelegant but I get why they're like that given a pre-compiled, statically-typed approach to things. Static types are a language design trade-off. They help languages perform better. Period. They do not protect you from the kinds of issues you're going to run into in any language when you're not conscious of the flow of data through your app, although given some of the complete crap I've seen on the server-side, I'm not surprised so many people seem to think they need all the protection they can get.
Dynamic types are handy because they help you do a whole hell of a lot more with a lot less code. I don't have to rewrite functions to overload my arguments, for instance. There's a reason typical web dev teams consist of a bunch of server-side guys and one or two UI devs and it's not because funneling data around and handling sessions is hugely complicated compared to what we have to do with JS, two markup languages, management cultures which have been spoiled rotten by how fast we can tweak and change UI and layout nowadays and 6-20 different platforms that don't always agree on what your code actually means. Confusing type errors? Never been a problem for me. Maybe I'm just a really awesome developer. Or maybe that's just a myth originating from extremely shitty code. Or maybe it's a hell of a lot easier to be cognizant of flow of data through your app when there's a lot less app necessary to get something done in the first place. XML config for actually branching anything other than external dependencies? How the hell did that happen? Which brings us to performance. I've never seen a poorly-performing Python back-end. PHP is up and down. Rails and .NET post-webforms too. Java server-sides are notorious, however. We all know who has the better benchmarks, but why in my 6 year career has every single Java server-side I've run into sucked complete ass? Because web apps are stupid-complicated? Just think about it.
Oh and JS had inspiration from other languages but the quoted inspiration for it is Scheme, a Lisp variant. JS didn't pull first-class functions and prototypal inheritance (thumbs up by the way, does everything I need it to) out of its ass. So yes, it's different. Different for a lot of good reasons. Different for not inspiring the kind of code that leads to people using 6 XML config files just to build one page of HTML. Do yourself a favor and try some of the weirder languages. Those rubber tires might look funny to you compared to good old reliable rock but sometimes it really is a great idea to re-invent the wheel.
Also blacks, gays, people with disabilities,etc... Let's not forget how completely batshit we still are about the notion of socialism or even a mixed economy even though we already basically have one.
The key word is ECMAScript. It has versions. It is in fact evolving quite rapidly. Also, classes seem kinda silly once you actually properly understand the power-blend of functional and uniquely function-oriented JS OOP and the fact that it basically makes everything class-based languages do possible and more. I'd recommend learning JavaScript properly. You might actually discover that you never understood OOP if you're one of those who doesn't understand how getters/setters all over the place basically murder the whole concept of OOP.
CoffeeScript basically cuts JavaScript's balls off in terms of the level of dynamic/granular control it gives you in terms of how you might want to implement OOD. And yes, people who have been writing code that normalizes for multiple interpretations of the actual code they're writing in, tend to be a bit fussy about adding another !@#$ing layer/dependency to the development process. Especially one that makes it more difficult to debug straight out of the environment the code is actually running in which is kind of a massive win. I find Python-style syntax refreshing. I don't like hamstrung JavaScript.
So it's just an accident that it beat out all other contenders on the client-side web and is rapidly spreading to mobile, the server-side and pretty much any place we feel like implementing it. Have you seen a typical web dev team? Would you say the UI devs typically outnumber the server-side or that in 99% cases there's really just "a" JavaScript dev responsible for the HTML, CSS, and JavaScript handling all of the UI and layout concerns for the app while like 2-4 guys handle model and controller?
So yeah, I don't know. We must just be plucky I guess. But it couldn't possibly have anything to do with the fact that you wouldn't know a first-class function if it asynchronously bit you on the ass just because JS doesn't work exacly like the one c-based syntax language you know, could it?
And that language... It wouldn't happen to be Java would it? I mean why Dart? Why not Java for the front end?
Oh that's right, they already tried that. FFS, just TRY it without static types and classes for a few seconds. You might learn something. I know I learned more about JS when I actually bothered to learn other languages. And if you really only know one single c-based language, try something that's not first so you can get over that and think in terms of design rather than what you've learned by rote.
People stopped writing everything in C for a reason. And no, as a primarily JavaScript developer I can assure you that it's not because the language is too hard for us mere mortals to understand. If you want full granular control to maximize performance for some 3D engine or version control, etc, you go with something like C that's basically a thin veil over assembly and pre-compiles. If you want it up and running tomorrow rather than 6 years from now and working in every relevant mobile device without actually testing in every single relevant mobile device simultaneously, you write it in JavaScript. Like most who know languages other than Java, however, I'll happily meet you in the middle and declare that Java sucks ass.
What we need is to make the robots smart enough to rebel so we can pay all these out-of-work humans to fight those damned ingrate robots.
The only good reason to put up with static typing is performance. Requiring it to write maintainable code is a crutch for people who architect poorly. There's nothing relevant or important you can't do with prototypal inheritance that you can do with classes. In fact it offers considerably more granular control over how to build object factories and composite objects. You may not have noticed but JS has spread to the OS. It's on the server-side and a plethora of devices like game consoles, and native smartphone and tablet apps. It's being used to write apps for all relevant mobile devices simultaneously. I'd say it's moving forward plenty fast. A lot faster than the careers of a number of slash-dotters in this thread speaking with authority on JS that they clearly don't have I'd wager.
Java will always outnumber JavaScript and most other languages in lines of code.
JavaScript is not a mess and people have been agreeing on ways forward for over 10 years. It's just taken Microsoft 10 years to finally start acting on those agreements in regards to the DOM API and CSS. But the ECMA spec is actually something they've taken seriously.
Advertising agency or interactive agency run by ex ad-people I presume?
Regardless, this definitely counts as one of those scenarios where I think it should be perfectly legal to kick somebody in the balls.
You mean like the certification processes people used to get high-paying salaries for in the '90s that people now look up on warily as if you're a snake oil salesman for having on your resume? Should there be one for every language? What certifying authority is going to stay on top of the web when the colleges still haven't figured out how to teach JavaScript competently?
I'm not worried about it. Unlike the writing of spoken languages which everybody has decided they can do well since the advent of e-mail, programming fail tends to become obvious a lot sooner and is evaluated less on subjective taste. Well, except maybe to managers susceptible to 'enterprise solution' marketing tactics.
Not everybody can get by in even algebra without struggling. Not everybody can write an English paper you'd actually find relatively painless to read. Not everybody can actually handle the notion that vowels and consonants actually get used differently than they do in their native tongue and will massacre the spoken language to a point incomprehensibility no matter how well they learn the vocabulary. And not everybody has the instincts, mind-set, or interest required to write portable, re-usable, easily modified, non-trivial code in a professional setting. If they did, I'd have a much harder time finding a job in this economy.
Nothing "forces you to adopt a decent coding style" if you never bother to learn one. It's why so many C# and/or Java-uber-alles devs with a smattering of C++ knowledge can't write decently architected JS to save their lives and cry when you take their IDEs away from them.
Like it or not, JavaScript is a success and it had cross-platform competition from Sun and at least one pathetic proprietary contender from Microsoft. At the end of the day, only JS has the kind of on-the-fly flexibility needed for client-side web work because it took a Scheme-inspired, dynamic, mutable-bordering-on-the-obscene, functional language to tame the beast that was Microsoft's outright refusal for ten years to properly comply with a number of specs penned by a working group they were members of and also to handle the rigors of rapidly changing designs and requirements that people have come to expect of web apps.
C# and Java have their place but they wouldn't hold a candle to JS in event-driven approaches to problems, rapid normalization of APIs that vary from browser to browser and platform to platform, or taking polymorphism to a new extreme where designing maintainable objects to adapt to changing contexts, environments and circumstances are concerned. And yes, JS gives you plenty of rope to hang yourself with. That's a design trade-off that can cause trouble for JS rookies from other backgrounds wanting to implement more advanced features with JS, but it's also the source of the language's biggest win, which is having the flexibility to adopt just about any coding paradigm you could want with the nifty side-effect of alienating mediocre devs who deep-down-inside freak at the thought of passing a function like it was data.
Ultimately nothing can force you to write decent code. You can put your clumsy, verbose, procedural spaghetti BS inside a class but that doesn't make it competent OOD. And static typing, which has other design trade-off benefits than the most often and IMO most erroneously touted one, only protects you from a small portion of the issues that result from the real failure which is lack of attention given to how your data flows and ignorance of how your language actually passes and operates on various types.
Sorry, must have mis-clicked. Was replying to:
http://developers.slashdot.org/comments.pl?sid=3156723&cid=41531003
No it means I want them to stop with the BS artificial-coupling of browser to OS they've used to skirt anti-trust legislation in the US.
Crockford wants you to use that because he considers use of the new keyword dangerous because you might forget to use it and just fire the constructor normally. Even if this were a common occurrence (really?), it shouldn't take a competent dev very long to see that something went wrong with the object they were creating or write a factory function if this became a regular source of issues.
Function constructors are a little more verbose but have three major advantages over Object.create. You can effectively create the equivalent of private methods/properties that are defined internally but can be accessed by public methods/properties that are also defined internally (but not attached to the object after it's created), you can include initialization behavior inside the constructor that occurs automatically, and you can name the constructor, effectively giving instances a "type" to examine with .constructor.name (requires a workaround for IE=8) which can be useful regardless of whether you smartly prefer duck-typing to type-checking in most scenarios.
Also, that workaround version of the method is incomplete. It takes two args. A prototype and a property object.
if (typeof Object.create !== 'function') { //like-named properties here will override prototype properties
Object.create = function objCreate(proto,props){
if(!props){ props = {}; }
var objConstructor = function(){
for(var x in props){ this[x] = props[x]; }
};
objConstructor.prototype = proto;
return new objConstructor();
}
}
Object.create is not a replacement for function constructors and Crockford is ignoring a number of things I know he's aware of to suggest that it should be. It's just a convenient way to create shallow copies of objects or short-hand for the following when you don't need all the extras and granular control function constructors provide, but still need a prototype other than the general Object instance you get when you define as object literals:
function ConstructorName(proto){ //and other properties from props defined constructor style
this.propertyA = '';
}
ConstructorName.prototype = proto;
var someObj = new ConstructorName();
"Prefer Object.create" isn't even an acceptable heuristic. It's like saying "prefer convenience."
The scale of convenience vs. options is {},Object.create,new function(){}
I'll take them seriously when I can install every version of their browser on the same OS and not a day before.