Yeah they do. Having run a development team, I can venture a guess why: it's a burden maintaining team skills the lager the number of skills your project requires. And in a lot of projects, you have to include Javascript *somewhere*.
It's not so bad as it would sound though. Javascript was inspired by Scheme, and while it may not look much like Lisp it actually supports functional programming pretty well, and functional programming simplifies a lot of server-side problems.
Yeah they do. Having run a development team, I can venture a guess why: it's a burden maintaining team skills the lager the number of skills your project requires. And in a lot of projects, you have to include Javascript *somewhere*.
If the language matters, you're doing it wrong. When you know what you're doing, you're wiring in existing libraries. Every business problem has been solved somewhere. Anyone who tells you how much they love a language is bad at their job...especially if they're comparing one typed language to another. I suppose broad categories, like is it typed? do you have to manage memory? (like C), but beyond those broad considerations, a good programmers spends all day wiring in libraries...rarely writing "pure" c
The rest of your post only makes marginally sense, most is wrong. However you could tell us why JavaScript is "a poor language" - perhaps it makes us laugh a bit.
> For starters: JavaScript is not untyped.
Playing american lawyer are we ? Pretend this and that and avoid the big elephant that javascript code analysis is a disaster zone.
Does not change the fact that we have two orthogonal definitions about types: dynamic typed versus static typed, JavaScript is the former. And weakly typed versus strong typed, JavaScript tried to be the later, but with stupid type coercion rules they failed it. Then we have untyped... like assembly and forth.
It helps to know the differences. Also outside of academic circles:P
Actually javascript is not typed you will never get. class cast exception at runtime. It does not care about types it only cares if functions are found on the object or prototype chain when its time to dispatch.
Javascript is a shitty language because tools cant understand it properly, there i said it, javascript ides are basically text editors with a few extras like a built in debugger etc.
Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doing a text search/replace.
It does not care about types it only cares if functions are found on the object or prototype chain when its time to dispatch. Yepp, as you would expect from a dynamic typed language, facepalm.
Actually javascript is not typed Wrong. you will never get. class cast exception at runtime. As you would expect from a dynamic typed language, facepalm.
Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doing a text search/replace. Then get a better IDE?
> I'm not working with JavaScript - so no idea:P
You dont need to work with javascript to see why ides cant refactor, the problem is due to type information missing from the source.
>> Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doing a text search/replace.
>Then get a better IDE?
Like ?
I am, every single IDE has the same problem. This is very easy to verify pick any js IDE and check out their lack of refactoring options.
> The type information is usually deducted with "type interference".
Type inference does not work well the larger the scope. This is one primary reason why java limits the scope of var to just the method, because it becomes a disaster zone when the scope get larger.
> So all IDEs I use, as Eclipse and IntelliJ variants, refactor JavaScript just fine.
They are not refactoring they are search and replacing text. This is very easy to prove, go read cedric beust blog for an example and verify yourself
We have fine refactoring in Groovy. And AFAIK that works in JavaScript, too.
As long as you have the whole code in your project, the tools can infer types just fine (since > 30 years, because that "refactoring" term was invented for CLOS and other lisp dialects - long ago).
> We have fine refactoring in Groovy.
> And AFAIK that works in JavaScript, too.
What do you mean you think you know , you either do or dont ?
> As long as you have the whole code in your project, the tools can infer types just fine (since > 30 years, because that "refactoring" term was invented for CLOS and other lisp dialects - long ago).
Not discssing the origins.
-> https://www.beust.com/weblog/d... [beust.com]
server side JavaScript (Score:4, Insightful)
Re: (Score:5, Insightful)
Yeah they do. Having run a development team, I can venture a guess why: it's a burden maintaining team skills the lager the number of skills your project requires. And in a lot of projects, you have to include Javascript *somewhere*.
It's not so bad as it would sound though. Javascript was inspired by Scheme, and while it may not look much like Lisp it actually supports functional programming pretty well, and functional programming simplifies a lot of server-side problems.
UI code is much different than backend (Score:2)
Yeah they do. Having run a development team, I can venture a guess why: it's a burden maintaining team skills the lager the number of skills your project requires. And in a lot of projects, you have to include Javascript *somewhere*.
If the language matters, you're doing it wrong. When you know what you're doing, you're wiring in existing libraries. Every business problem has been solved somewhere. Anyone who tells you how much they love a language is bad at their job...especially if they're comparing one typed language to another. I suppose broad categories, like is it typed? do you have to manage memory? (like C), but beyond those broad considerations, a good programmers spends all day wiring in libraries...rarely writing "pure" c
Re: (Score:1)
For starters: JavaScript is not untyped.
The rest of your post only makes marginally sense, most is wrong. However you could tell us why JavaScript is "a poor language" - perhaps it makes us laugh a bit.
Re: (Score:2)
Playing american lawyer are we ? Pretend this and that and avoid the big elephant that javascript code analysis is a disaster zone.
Re: (Score:2)
Does not change the fact that we have two orthogonal definitions about types: dynamic typed versus static typed, JavaScript is the former. And weakly typed versus strong typed, JavaScript tried to be the later, but with stupid type coercion rules they failed it. Then we have untyped ... like assembly and forth.
It helps to know the differences. Also outside of academic circles :P
Re:UI code is much different than backend (Score:2)
Javascript is a shitty language because tools cant understand it properly, there i said it, javascript ides are basically text editors with a few extras like a built in debugger etc. Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doing a text search/replace.
Re: (Score:2)
It does not care about types it only cares if functions are found on the object or prototype chain when its time to dispatch.
Yepp, as you would expect from a dynamic typed language, facepalm.
Actually javascript is not typed Wrong.
you will never get. class cast exception at runtime. As you would expect from a dynamic typed language, facepalm.
Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doing a text search/replace.
Then get a better IDE?
I'
Re: (Score:2)
You dont need to work with javascript to see why ides cant refactor, the problem is due to type information missing from the source.
>> Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doing a text search/replace. >Then get a better IDE? Like ?
I am, every single IDE has the same problem. This is very easy to verify pick any js IDE and check out their lack of refactoring options.
Re: (Score:2)
You dont need to work with javascript to see why ides cant refactor, the problem is due to type information missing from the source.
The type information is usually deducted with "type interference". So all IDEs I use, as Eclipse and IntelliJ variants, refactor JavaScript just fine.
Re: (Score:2)
Type inference does not work well the larger the scope. This is one primary reason why java limits the scope of var to just the method, because it becomes a disaster zone when the scope get larger.
> So all IDEs I use, as Eclipse and IntelliJ variants, refactor JavaScript just fine.
They are not refactoring they are search and replacing text. This is very easy to prove, go read cedric beust blog for an example and verify yourself
Re: (Score:2)
We have fine refactoring in Groovy.
And AFAIK that works in JavaScript, too.
As long as you have the whole code in your project, the tools can infer types just fine (since > 30 years, because that "refactoring" term was invented for CLOS and other lisp dialects - long ago).
Re: (Score:2)
What do you mean you think you know , you either do or dont ?
> As long as you have the whole code in your project, the tools can infer types just fine (since > 30 years, because that "refactoring" term was invented for CLOS and other lisp dialects - long ago).
Not discssing the origins. -> https://www.beust.com/weblog/d... [beust.com]
Re: (Score:2)
http://www.informatik.uni-brem... [uni-bremen.de]
I suggest to follow the references :P
Re: (Score:2)